A software vendor publishes a security advisory stating that its remote access product was exploited and listing indicators of compromise, including file hashes and attacker IP addresses. The organization runs that product. Which incident response activity should this advisory MOST directly support?
Select an answer to reveal the explanation.
Short Explanation
An outside advisory is a tip-off: somebody's telling you exactly what the burglar's footprints look like. Your job is to go check your own floor for those footprints - that's identification. Jumping to reimaging or customer notices before you've found anything is the trap.
Full Explanation
External advisories from vendors, government agencies, or information-sharing groups are inputs to the identification phase. When an advisory lists indicators of compromise, such as file hashes, attacker IP addresses, or domains, responders search logs, endpoint telemetry, and network records for matches to determine whether the organization's instance of the product was exploited. Results establish whether an incident exists and its scope, which then drives containment and later phases. Reimaging every host before any search jumps to eradication without evidence, destroys forensic data that would show what happened, and may not even address the actual compromise path if attackers moved elsewhere. Treating the advisory as material for lessons learned misreads it; the organization runs the affected product, so the immediate question is whether it is compromised, not what can be learned from someone else's breach later. Notifying customers before any indicator is found is premature; notification obligations follow from a confirmed incident and its scope. Exam caveat: identification also draws on internal advisories, such as notices from the organization's own security team. Operational check: load the advisory's indicators into the SIEM and endpoint tools, run a retrospective search over the full retention window, and record the result.