CySA+ Incident Response Process: Preparation to Post-Incident (CS0-004 3.2)

The CySA+ incident response process has seven phases: preparation, detection, analysis, containment, eradication, recovery and post-incident activity. Each phase has one job, and the order matters: you cannot contain what you have not scoped, you should not clean what is still spreading, and you must not return a system to service while the attacker can still reach it.

The phases follow the incident handling lifecycle in NIST SP 800-61, which groups detection and analysis together and treats containment, eradication and recovery as one connected stage. (NIST published Revision 3 in April 2025, which reorganizes its guidance around the Cybersecurity Framework 2.0 functions; the CySA+ objective keeps the seven named phases.)

The process is cyclical, not a one-way line. Whenever new evidence appears in a later phase (a host nobody knew was affected, or a supposedly clean system showing the incident's indicators again), the team goes back to analysis and containment for that system and widens the scope before carrying on. Post-incident findings loop back to preparation in the same way.

Preparation is everything an organization puts in place before an incident so that the response is fast and the analysis is possible. If the work happens before any incident and makes a future response quicker or better informed, it is preparation.

Readiness: people, tools and contacts

• Plans and authority agreed in advance, so responders know who decides and what they may do. (Writing the plan, playbooks, roles and training are covered in the objective 3.3 lesson.)
• A maintained contact list: internal escalation, legal counsel, the ISP, key vendors and regulators, each with an out-of-hours route. Searching for the right person in the middle of an incident is time the attacker gets for free.
• A jump kit (response toolkit) ready to go: a dedicated forensic analysis laptop with current tools, write blockers, blank media, cables and adapters, and the contact list. It is inventoried and updated on a schedule, not assembled once an incident has started.
• Out-of-band communication: a pre-arranged channel, on separate devices and accounts, that does not depend on the systems an attacker is likely to compromise. When the identity system itself may be compromised, any channel that signs in through it is exposed, however well it is encrypted; the channel has to sit outside that identity system.

Making analysis possible: baselines, logging and time

• Baselines: a recorded known-good picture of each critical host (expected services, listening ports, accounts, scheduled tasks, software) and of normal network behaviour. Without one, an analyst has nothing to compare against and cannot say whether what they see on a server belongs there.
• Logging and retention: the right sources (endpoints, DNS, proxy, firewall, identity, cloud) collected centrally and kept long enough to cover realistic dwell times.
• Time synchronization: every device synchronized to a common, trusted time source (for example NTP). Correlating firewall, proxy, identity and endpoint logs into one timeline only works if their clocks agree; when they do not, events appear in an impossible order. Converting timestamps to a single time zone in the SIEM solves a different problem: it cannot correct a device whose clock has drifted, which only synchronization at the source prevents.

Detection is the phase in which the organization notices that something may be wrong, through alerts, log review, user reports, partner warnings and threat intelligence. Two pairs of terms (from NIST SP 800-61) decide how a detection is treated.

Event versus incident

An event is any observable occurrence in a system or network: a sign-in, a file being opened, a blocked connection, a scheduled job running. An incident is an event that violates, or imminently threatens to violate, security policy, acceptable use policy or standard security practice. Every incident is an event, but most events are not incidents.

• Routine, expected activity is an event: an employee signing in from their normal office during working hours, a nightly patch job, an approved data transfer running on schedule.
• A control doing its job is also an event: an intrusion prevention system dropping exploit traffic, or a mail gateway quarantining malware nobody opened. Nothing was violated.
• Context turns the same action into an incident. A file server uploading engineering drawings to a personal file-sharing account is an incident; the same files reaching the contracted design partner through the approved transfer service are not.
• A policy violation is an incident even without malware or an outside attacker. An engineer emailing design files to a personal address, against a policy forbidding company intellectual property in personal accounts, is an incident. Permission to access data is not permission to move it, and classifying the activity does not wait for proof of harm or intent.

Precursor versus indicator

Precursors are valuable because they let the team act early, but they are not proof of compromise. A warning about attacks on a product you use, with no sign of that activity in your own logs, is a precursor: check whether you are exposed and close the gap while there is still time.

Analysis confirms that a detection is a real incident and then works out how big it is and how it started. Detection raises the flag; analysis explains it and measures it.

1. Validate the alert: true positive or false positive?
2. Scope it: which other hosts show the same indicators, which accounts are involved, which data was touched. Once one machine is confirmed, the next question is where else the same signs appear, because you can only contain what you know is affected.
3. Identify the initial access vector: the phishing attachment, exposed service, stolen credential or vulnerable plugin the attacker used.

Phases are defined by the work being done, not by how much the team knows. Until responders act to limit the damage, validating, tracing and counting affected systems is still analysis.

Finding the vector matters because eradication must close it. When cleaned systems keep getting compromised again, the usual cause is an entry point that was never found, so the attacker simply returns the same way. (Detailed triage, timelines and severity scoring are techniques of objective 3.3.)

Containment stops the incident from causing more damage, and the right strategy is the most proportionate one: it cuts off the attacker's path or the source of the damage with the least collateral impact on the business. NIST lists the criteria for choosing: potential damage and theft of resources, the need to preserve evidence, service availability, the time and resources needed, how effective the strategy is, and how long it must last.

• Contain the source, not the victim, when the victim must stay in service. If one infected workstation is corrupting records through a shared business application, disconnecting that workstation stops the damage; taking the application offline stops every user. Disabling the user's account is slower than it looks, because connections and tickets already established can keep working for a while after the account is disabled.
• Cut the attacker's path, not the whole business process, when the two can be separated. A compromised build server sending source code to an external host can have its outbound internet access blocked at the perimeter while its internal pipeline jobs carry on.
• When it is spreading, contain first. Self-propagating malware is stopped at the network, by blocking the protocol it spreads over between segments; cleanup and investigation of individual hosts follow once the spread has stopped.

Short-term and long-term containment

Short-term containment is the immediate action: isolate, block, disconnect. Long-term containment is a set of temporary controls that let a system return to service safely until the permanent fix exists: a virtual patch (a WAF or IPS rule that blocks the exploit), tighter segmentation, restricted access and extra monitoring. For example, a remote-access appliance waiting for a firmware fix might run with the vulnerable feature turned off and access limited to known addresses. It balances the availability requirement against a weakness that is still open.

Where isolation is enforced

Isolation must be enforced outside the compromised host: a network switch, VLAN, firewall or the EDR platform's isolation feature. Controls configured on the compromised system itself can be changed by an attacker who controls it.

Isolate a suspect host from the network but keep it powered on, so that volatile evidence (running processes, network connections, memory-resident malware, encryption keys) survives containment. The same rule applies to users: anyone who suspects their machine is compromised should disconnect it from the network, leave it running and change nothing else until responders take over.

For a suspected memory-resident threat, capture a memory image with a trusted acquisition tool and apply network isolation that keeps the host running. EDR isolation is designed for this: it cuts the host off from the network but keeps the agent's link to the security service, so the team can keep investigating. How evidence is then handled, labelled and preserved is an objective 3.3 technique.

Delaying containment to observe the attacker

Delaying containment to observe an attacker is acceptable only when the attacker is confined to an isolated, monitored environment where nothing of value is at risk. Watching an intruder can reveal their tools and objectives, but every hour they stay is an hour they can do damage, so the decision is deliberate and approved.

Observation is acceptable only when all of these hold:

• the system holds nothing of value and gives no route to anything that does;
• it can be moved to an isolated, monitored segment, enforced outside the host, from which the attacker cannot reach the rest of the estate;
• management has approved it.

If any condition fails (sensitive data is exposed, or the system cannot be isolated without alerting the attacker), contain now in a way that preserves evidence, and learn about the attacker from that evidence instead. Watching from a production network, even with some attacker addresses blocked, leaves the damage running.

Containing a credential compromise means invalidating the compromised credential itself, quickly and, where possible, reversibly, rather than chasing what the attacker did with it.

• Leaked programmatic access key (for example a cloud API key exposed in code): deactivate the key first. That cuts off every use of it at once, keeps the identity and its logs for analysis, and can be reversed. An access key is a separate credential from the identity's console password, so each one has to be dealt with on its own.
• Password reset is not enough on its own. Existing sessions, access tokens and some refresh tokens can outlive a reset, depending on the provider. Activity that continues after a reset with no matching new sign-in is the sign of a surviving session. Containment means resetting the password and explicitly revoking the account's sign-in sessions and tokens.
• Service accounts: when an application depends on the stolen credential, rotate the secret and update every system that stores it in one coordinated change, so the attacker's copy stops working and the application keeps running.

Eradication removes every component of the incident from the environment after containment: malware, every persistence mechanism, attacker-created accounts, stolen secrets the attacker can still use, and the weakness that let them in. Containment stops the spread; eradication removes what the attacker left.

• Persistence comes in many forms: Run keys, services, scheduled tasks, web shells, startup items and fileless mechanisms. A WMI event subscription stored in the WMI repository can relaunch a payload held in the registry or in WMI itself and run it in memory, so no malware file ever returns to disk. Deleting the file you found is therefore no proof that persistence is gone: if a cleaned host shows the incident's activity again, check the less visible mechanisms before anything else.
• Stolen credentials are persistence too. After an attacker extracts the KRBTGT account's password hash, they can forge Kerberos tickets (golden tickets) for as long as that hash is valid. Eradication resets the KRBTGT password twice, allowing replication between the two resets, because Active Directory still accepts tickets signed with the previous password.
• Remove attacker-created accounts and other access they set up, such as mail forwarding rules or added application credentials.
• Close the entry point found in analysis (patch, reconfigure, remove the exposed service), or the attacker returns the same way.

Recovery returns affected systems to normal operation from a known-good state, closes the weakness before reconnection, and confirms with heightened monitoring that eradication worked. Recovery means back in service, and watched.

Restore from a known-good state

A backup is only clean if it was taken before the attacker arrived. When the dwell time exceeds the backup history (say the attacker has been present for ten weeks, but daily backups go back two weeks and monthlies a year), every recent full-system backup can carry the attacker's persistence back in, while restoring the whole system from before their arrival throws away weeks of data. The approach that solves both is to rebuild the system from a trusted image and restore only scanned, validated data from the most recent backup taken before the damage.

A restore also brings back whatever weakness existed when that backup was taken. Apply the missing patches and hardening and validate the system's state before reconnecting it; a clean malware scan says nothing about whether the hole is closed.

Monitor closely after go-live

• Watch restored hosts specifically for the incident's own indicators (its command-and-control domains, file hashes, registry keys), not just with routine scans.
• Monitoring must outlast how the threat behaves. If analysis shows an implant contacts its operator only once a month, two quiet weeks prove nothing; keep heightened monitoring for at least one full cycle.
• If monitoring finds the indicators again, the process loops back to analysis and containment.

The post-incident phase turns the case into better preparation: a lessons-learned meeting, a final report, evidence retention and owned improvements to plans, playbooks and detections.

• Lessons-learned meeting: held soon after closure with everyone involved, to review what happened, what worked, and which gaps slowed the team down. It looks back at a real incident, which is what separates it from a tabletop exercise (a rehearsal of a hypothetical one).
• Final report: what happened, the timeline, the impact, and what is changing.
• Evidence retention under the organization's retention policy (and any legal requirements).
• Owned improvements: each finding becomes a task with an owner and a due date, such as extending EDR to servers that lacked it or tuning a detection rule that missed the attack. A finding that is only written down changes nothing.

Anything that still removes attacker access or restores data belongs to containment, eradication or recovery, not post-incident. Root cause analysis and corrective-action techniques are covered in the objective 3.3 lesson.