Security+ SY0-801 Incident Response: Process, Forensics, Containment and Reporting

The incident response process is the ordered set of activities an organization follows to prepare for, detect, investigate, contain, remove and learn from a security incident. CompTIA Security+ objective 4.7 lists them as preparation, identification, investigation, containment, negotiation, eradication/recovery, notification/external reporting and post-incident work.

The order matters more than the names. Each activity depends on the one before it:

1. Preparation happens before any incident: training, testing, playbooks and defined roles.
2. Identification establishes that an incident is happening and what it affects. Nothing can be contained until it has been identified.
3. Investigation collects and analyses evidence. It starts as soon as the incident is identified and runs alongside containment, which is why evidence handling shapes how you contain.
4. Containment stops the damage from spreading while evidence is kept.
5. Eradication removes the attacker's foothold and the cause that let them in.
6. Recovery returns cleaned systems to service and confirms they stay clean.
7. Post-incident work (lessons learned, root cause analysis, the post-incident report) feeds improvements back into preparation.

Negotiation (for ransomware and extortion) and notification/external reporting are not steps in a single line; they run in parallel once the impact is known and must be handled within the response, not after it.

Two ordering rules carry most scenario questions:

• Contain before you eradicate. Cleaning one host while the attacker can still move or re-infect it wastes the cleanup and alerts the attacker.
• Eradicate before you recover. Restoring a system to service while the malware, persistence or vulnerability is still present puts a compromised system back into production.

Each activity has an exit condition that opens the next: containment is done when the threat can no longer spread, eradication is done when nothing the attacker left behind remains, and recovery is done when restored systems have been watched long enough to show they stay clean.

Preparation is everything done before an incident so that the response is fast, consistent and authorised: training staff, assigning roles, writing playbooks and testing the plan.

Training comes before testing

When a plan gives people duties they have never performed, the first step is to train them on those duties. Exercises test how well trained people apply the plan; running one with untrained staff only shows they do not know their roles.

Roles: one owner for every task

A plan names roles so that each decision and each task has exactly one owner:

The principle is single ownership: public and media questions are routed to the communications lead whoever happens to receive them, and conflicts between teams are escalated to the incident commander instead of being settled by whichever team acts first.

Plan, policy and playbook

Playbooks exist for consistency. A business email compromise playbook, for example, might fix the order as: preserve the mailbox, revoke the user's sessions, reset credentials, search for forwarding rules, then check whether payments were redirected. Because the steps and their order are written down, the outcome no longer depends on who is on duty.

Testing the plan: tabletop exercises versus simulations

A tabletop exercise is a discussion-based walkthrough of a scenario in which participants talk through their responses without touching any system; a simulation has responders actually perform the actions with real tools against a scenario, normally in a non-production environment. Both are ways of testing the plan.

Choose by what must be demonstrated: decisions, coordination and communication call for a tabletop; the ability to carry out actions calls for a simulation. Because a simulation uses real tools, it is normally run where it cannot disrupt production. A test program can use both formats for different groups.

Tabletops and simulations exercise people carrying out the plan. Technical tests of systems, such as penetration testing or failover testing, belong to other objectives and assess infrastructure rather than the response.

Identification is recognising that an incident is happening and establishing what it affects, from automated detection, advisories or proactive threat hunting.

• Detection is an alert from the organization's own tools, such as a SIEM, EDR or IDS, or a report from a user.
• External advisory: a bulletin from an outside body, such as a vendor, a national cybersecurity agency or an ISAC (information sharing and analysis center), describing a threat or an exploited flaw, often with indicators of compromise.
• Internal advisory: a notice written and issued by the organization's own security team to its own staff, for example a notice warning employees about a phishing campaign aimed at the company.

Classify an advisory by its issuer: one published by a body outside the organization is external, and one issued by the organization's own team is internal, whatever material it draws on.

Threat hunting

Threat hunting is a proactive, hypothesis-driven search of the organization's own telemetry for attackers who have not triggered any detection. A hunt usually starts from an idea, often taken from intelligence ("this group moves laterally with legitimate remote administration tools"), and then queries endpoint, network and log data for evidence of it.

Hunting looks for behaviours (tactics, techniques and procedures), not only known indicators. Indicators such as IP addresses and file hashes are cheap for attackers to change, and some groups use new infrastructure for every victim. Finding no known indicators is therefore weak evidence that an attacker is absent; searching for the behaviours a threat is known to use is the stronger test.

Digital forensics is the acquisition and analysis of digital evidence in a way that preserves its integrity, so that what happened can be reconstructed and, if needed, proven in court.

Order of volatility

Collect evidence from the most volatile source to the least volatile, because volatile data changes or disappears first: CPU registers and cache, then memory (RAM) and running processes and network connections, then temporary file systems (CompTIA material commonly groups swap and page files here), then disk, then remote logs and archives or backups. Memory comes before disk. Memory-resident (fileless) malware may exist only in RAM, so powering a system off, even cleanly, destroys the best evidence.

Order of volatility shapes containment too: cutting a system off from the network ends the attacker's access while the system keeps running, so memory can still be captured, whereas any action that powers the system down trades that evidence away.

Write blockers and hashes

Investigators normally work on a forensic image, never the original. Integrity is demonstrated only by comparing a fresh hash against the value recorded at acquisition; controls that protect confidentiality or availability are useful but answer different questions.

Detailed analysis of specific log types, packet captures and memory dumps belongs to objective 4.8 (using data sources to support an investigation); this objective covers the concepts that make evidence usable.

Chain of custody is the documented record of every person who handled a piece of evidence, when, and for what purpose, from seizure to court. It is kept on a chain-of-custody form that both parties sign at every hand-off, for example when a responder checks a removed hard drive into the evidence locker.

Integrity and custody are separate claims. A hash proves the image has not changed; only the custody log proves who held the evidence and what was done with it. Evidence can pass every hash check and still be challenged if the custody record has an undocumented period, because the challenge is then to who had access, not to whether the bits changed.

Preservation

Preservation means keeping evidence unchanged and available until it is needed. The right tool depends on what threatens the evidence:

The duty to preserve starts when litigation or an investigation is reasonably expected, not when the incident is over, so a legal hold is issued as early as possible and applies to the live systems where routine deletion would otherwise continue. Legal hold also appears under legal compliance in objective 5.4; here it is a preservation tool.

E-discovery

E-discovery (electronic discovery) is the legal process of identifying, preserving, collecting, reviewing and producing electronically stored information, such as email and documents, for a lawsuit or investigation. It differs from forensics in purpose: forensics reconstructs what happened technically; e-discovery locates and hands over relevant records to the other party. Preservation comes early in e-discovery, and production (handing data over) comes after review.

Containment limits the spread and impact of an incident, usually by quarantining or isolating affected hosts and accounts, while keeping the evidence the investigation needs. Typical containment actions include quarantining a host in an isolated network segment, blocking malicious destinations at the network edge and disabling compromised accounts; the affected system is cut off, not yet cleaned (eradication) or returned to service (recovery).

Isolate the host, not one path

Containment has to cover every route the threat uses. Devices often have several network paths, so an action that closes one channel can leave others open. EDR network isolation blocks all of the endpoint's traffic except its management channel while the device stays powered on, so it covers every path and preserves memory. When comparing containment actions, ask two questions: does it stop every path the threat can use, and does it keep the evidence the investigation still needs?

When to contain, and how fast

The default is to contain as soon as harm is ongoing: encryption spreading, data leaving, an attacker on a sensitive system. But containment also tells the attacker they have been seen. If the intrusion's full scope is unknown and the known activity is not yet causing serious harm, containing piecemeal can push the attacker to footholds nobody has found. Responders may then observe briefly while they scope, and contain every affected system together. Containment should also be proportionate: a measure far broader than the threat disrupts the business without improving the outcome. Delaying containment is a risk decision owned by the incident commander, not something analysts drift into.

Negotiation is the controlled communication with an extortionist, most often a ransomware group, to gain time, information or a decryptor, and it is a business and legal decision rather than a technical one. Executives decide, advised by legal counsel and often a specialist negotiator; responders do not open talks on their own.

• Legal checks come first. Before any payment is authorised, counsel confirms the recipients are not sanctioned parties: paying a sanctioned person or group can itself break sanctions law (in the US, OFAC rules). Agencies such as the FBI and CISA generally advise against paying; the decision and its legal risk stay with the victim organization.
• Payment buys a promise, not an outcome. Recovery through a criminal's tooling is unreliable, and any promise about stolen data cannot be checked. Paying also leaves the organization's legal duties, such as breach notification, exactly where they were.
• Double extortion combines encryption with theft: the attackers copy data out before encrypting it and threaten to publish it. Good backups defeat the encryption, but they do nothing about the stolen copy. Data exfiltration before encryption is its hallmark, and the publication threat is why extortion keeps its leverage even over an organization that can restore everything.

Negotiation never replaces the rest of the response: containment, eradication, recovery from clean backups and notification all continue whether or not the organization talks to the attackers.

Eradication removes the attacker's foothold and the cause that let them in; recovery restores systems from known-good sources and returns them to service only once that cause is fixed.

Eradication is more than deleting malware

The foothold includes everything that would let the attacker return:

• malware and its persistence (scheduled tasks, services, web shells, new accounts);
• credentials the attacker obtained: dumped password hashes, stolen tokens and keys must be reset or revoked, because they work from anywhere, even after the server is rebuilt;
• the vulnerability or misconfiguration used for initial access, which must be patched or corrected.

Recovery: restore clean, fix, then reconnect

Two rules decide recovery questions:

1. Restore from a point before the first compromise. The investigation's timeline of first compromise decides which backups can be trusted; anything taken after that point may carry the attacker's persistence and must be checked and cleaned before use.
2. Fix the entry point before reconnecting. Restoring brings back the system as it was, weakness included, so the patch or configuration fix is applied before the system rejoins the network.

Recovery then returns the system to production in a controlled way and watches it closely for signs of re-infection before the incident is closed. Recovery from backups and the RTO/RPO targets that size them are covered in the resilience lesson (objective 3.4).

Notification and external reporting means telling the right parties about an incident: internal stakeholders, affected customers, law enforcement and, where the law requires it, regulators within a set deadline. The communications lead and legal counsel own this work.

Mandatory reporting is the report the law requires, usually within a deadline. Anything not required by law, regulation or contract is voluntary, however useful it is: a courtesy email to business partners or a public blog post about the attack, for example. Each audience serves its own purpose, so one notification does not stand in for another. Prosecution runs through law enforcement and depends on evidence preserved with an intact chain of custody; regulators enforce obligations on the organization itself.

Deadlines run from awareness

Reporting deadlines start when the organization becomes aware of the breach, not when the investigation ends. Under the EU GDPR, a controller must notify the supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it, and may provide the information in phases when not all of it is available yet. So the right move near a deadline is to report what is known now and supplement it later, not to wait for the root cause.

Post-incident activities turn an incident into improvements: a lessons-learned review of how the response performed, a root cause analysis of why the incident happened, and a post-incident report (PIR) that records it all.

Finding the real root cause

The root cause is the underlying condition whose correction prevents recurrence, not the immediate trigger. If ransomware entered through an internet-facing server that was missing a patch, the exploit is the trigger; if the server was absent from the asset inventory, so patching never reached it, that gap is the root cause, and correcting it prevents a repeat on other forgotten systems. Findings about how quickly the incident was detected or handled describe the response, so they belong to lessons learned rather than to the root cause.

Keep the documents in their place in time: the plan and playbooks are written before incidents; the chain-of-custody form is filled in during them; the PIR is produced afterwards. A lessons-learned meeting reviews a real incident after it closes; a tabletop rehearses a hypothetical one before it happens.