CySA+ Incident Response Techniques: Triage, Evidence and Recovery (CS0-004 3.3)

The incident response plan sets up the whole response program: what counts as an incident, the severity levels, who is on the team, what authority the team has (for example to take a production system offline) and when incidents are reported to senior management. The communication plan sets who says what, to whom, when and over which channel: internal staff, executives, customers, regulators, law enforcement and the media, with approved spokespeople for each.

A communication plan also has to assume that some normal channels cannot be trusted:

• Out-of-band communication. Any channel that authenticates through a compromised system is potentially visible to the attacker. The plan should name a pre-arranged alternative that does not depend on the production environment, for example phones or a separately hosted service with its own accounts, and test it before it is needed.
• Need-to-know handling. Some cases (an insider suspect, a sensitive executive matter) must be hidden from people who would normally see them. Access controls inside a system are only as strong as its administrators, so the plan should provide a separate, restricted channel and case store outside the reach of anyone involved.

A playbook is an ordered, step-by-step procedure for one incident type (lost laptop, ransomware on a workstation, impossible-travel sign-in) with explicit decision points. Its purpose is consistency: whoever picks up the case handles it the same way, with the same checks in the same order.

Order matters inside a playbook: contain, preserve, scope, then clean. A step that wipes a system before volatile evidence is captured destroys what later steps need, and a step that delays containment lets the incident keep spreading. In automated (SOAR) playbooks, keep the fast automatic action for the common case and add a human decision point only where the action itself carries a high business cost, so protection stays in place while judgment is applied where a mistake would hurt most.

Defining roles means naming who decides, not only who works. Decision authority has to be assigned before an incident, not negotiated during one. Typical roles:

• Incident commander (incident manager): coordinates the response and holds decision authority, such as approving containment that causes an outage.
• Deputies: trained alternates holding the same delegated authority, so decisions continue when the primary is unavailable. Any role held by one person is a single point of failure.
• Technical leads (forensics, containment, recovery): collect evidence, contain and restore.
• Legal counsel: notification duties, liability, litigation and legal holds; reviews external statements.
• Communications / public relations lead: drafts and delivers statements to customers and media after legal review.
• Management, HR, privacy and third parties as the plan requires.

Training comes in two forms in this objective:

Choose by what you need to prove: that people make sound decisions together (tabletop) or that they can perform the work (simulation). Both exercise your own team and procedures; they are training, not assessments of your defences.

Collect logs off the host as they are written. A log that exists only on a compromised machine is under the attacker's control: with administrator rights they can clear or edit it (on Windows, clearing the Security log records event ID 1102, "The audit log was cleared"). The protection comes from a copy reaching a system the attacker cannot touch before they can act, so any delay between writing and collection is a window for tampering. Local log size and retention settings govern rollover, not tampering.

Correlation links events from different sources into one sequence, and it depends on time:

• Synchronize clocks on every source to one authoritative time source (NTP) to remove drift.
• Normalize timestamps to UTC at ingestion so sources that log local time line up. A constant offset of a whole number of hours usually means a time-zone setting rather than drift. Fixing a clock affects only future entries; existing entries must be converted.
• Use each event's own timestamp, not the SIEM's receipt time, which adds forwarding lag.

Attributing activity to a person often means following a chain of address mappings, and each mapping is only true at one moment. Work the chain from the outside in, matching on the exact time at every step: any address translation at the edge first, then internal address to device (DHCP), then device to user (authentication or directory logs). Where many internal hosts share one public address (port address translation), the translation device's log is the only record that separates them, using the session details it keeps for each connection.

Log augmentation and enrichment

Enrichment adds context to an event automatically so analysts do not look it up by hand: the user and asset behind an internal address, the asset's owner and criticality from the CMDB, and the reputation of an external address or domain from threat intelligence. It speeds up triage because the context is already on the alert, and it suppresses nothing.

• Internal addresses (RFC 1918 private space: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16): enrich from your own sources, such as the CMDB, asset inventory, DHCP and directory. Public registries and geolocation services hold nothing meaningful about private space.
• External addresses and domains: threat-intelligence reputation, WHOIS and geolocation are useful.

Enrich volatile context at ingestion time and store it with the event. Leases, VPN sessions and logged-on users change, so any lookup made later answers the question for the wrong moment, however current its source is.

Route alerts by severity: critical alerts go to an interruptive channel (page the on-call analyst), with acknowledgement and escalation if nobody acknowledges in time; lower severities go to the work queue. Routing has to fit urgency in both directions: a channel that is too slow lets critical alerts wait, and interrupting people for everything produces alert fatigue, so real alerts get ignored.

Tune noise at its source without losing detection elsewhere:

Triage validates an alert before anyone acts on it: is it a true positive, and if so, did it succeed? Check the related logs (web, database, EDR, authentication) first; containment, executive notification or root cause analysis on an unvalidated alert acts too early. Keep two questions apart:

• Did it happen? If the logs show the malicious activity really occurred, the detection was not a false positive.
• Did it work? Compare the attack with the target. An exploit for software the target does not run, or a request the target rejected, is a real but unsuccessful attempt.

Legitimate explanations must be proven, not assumed. An approved change explains an alert only when the recorded details of the change match the observed activity; matching timing alone proves nothing, because an attacker using a legitimate account looks the same on a clock.

Severity and impact are commonly rated on three factors described in NIST SP 800-61 Rev. 2. Rev. 2 was withdrawn in April 2025 and replaced by Rev. 3, which is organized around the NIST Cybersecurity Framework 2.0 and no longer includes these tables, but the three factors remain a widely used severity model and the one CySA+ scenarios rely on:

Severity measures the damage to the organization. Facts about the attacker are useful for intelligence and scoping, but they are not impact.

Prioritization chooses what to work first. Activity that succeeded and is still unmitigated outranks activity a control already stopped, even when the stopped activity aimed at a more important asset. Severity is not fixed: when new evidence changes the impact, re-rate the incident and follow the new rating's escalation path.

A timeline is a single, time-normalized sequence of what happened, built from every reliable source. Three judgments decide its quality:

• Retention edges. If the earliest evidence in a source sits right at that source's retention limit, you may have found the edge of your data, not the start of the attack. Look further back in sources that keep data longer before you fix the start date.
• Source reliability. When clocks are verified in sync but sources disagree, prefer the source the attacker could not alter over one stored where they had control, and record the reason in the timeline.
• Defined intervals. Initial compromise is when the attacker first acted, not when the first alert fired. Dwell time runs from the first attacker activity to detection; time to contain runs from detection to containment.

Evidence gathering has four parts in this objective: chain of custody, data integrity validation, preservation and legal hold. Each answers a different challenge.

Custody versus integrity. A hash shows the content did not change; it says nothing about who handled the item. Custody is shown only by a continuous record of each transfer between identified people. A gap in custody of an original is harder to repair than a missing hash of a copy, because a copy can be re-imaged and re-hashed from a verified original.

When a hash check fails, the copy has changed, and nothing done afterwards makes it trustworthy again. Return to the preserved original, verify it against its recorded acquisition hash, make a new verified image and redo the analysis on that. Only recomputing the same algorithm and comparing proves content is unchanged.

Memory is the exception to "hashes must match". Running RAM changes constantly, so two captures minutes apart never hash the same; that is expected, not tampering. The capture file's hash at acquisition is the baseline that copies are verified against.

Order of volatility (RFC 3227) puts CPU registers and cache, then memory and running state (processes, network connections, ARP and routing tables), ahead of temporary files, disk, remote logs and archived backups. Capture RAM first, especially when malware may live only in memory or the disks use full-disk encryption: the active encryption key is held in memory and is lost with power. Attach seized drives through a hardware write blocker, which enforces read-only access independently of the analysis machine's operating system, and take a full bit-for-bit image, which captures deleted data and slack space as well as files.

Legal hold applies when litigation is pending or reasonably anticipated. It overrides the retention policy only for the relevant data (the named custodians' mail, chat, files and logs). It is ongoing: notify each custodian in writing and suspend automatic deletion until counsel lifts it, so it covers data created after the hold starts as well as what exists today.

Isolation stops a compromised system reaching anything else while keeping what the investigation and the business need. The rule: close every path except the ones responders and essential operations genuinely require, and do not lose volatile evidence or your own access in the process. Common methods:

Measures that close only one path (a single account, a single address, one direction of traffic) leave others open, and measures that cut all connectivity or power can cost you remote access or volatile data.

Escalation follows criteria written in advance, and each trigger has its own path:

• Technical scope: an incident beyond a tier's defined scope goes to the responder tier the escalation criteria name for it.
• Severity change: new evidence that raises severity changes the escalation path immediately.
• Data exposure: likely exposure of regulated or personal data goes to the incident manager at once, who brings in legal and privacy. Notification decisions, which can carry strict legal deadlines, belong to them, not to the analyst who found the exposure, and actions outside the organization wait for their direction.

Remediation removes the cause on every affected asset; verification proves it worked by testing the systems themselves. Records of what was planned or approved show intent, not results.

• Test each affected host directly (for example with authenticated scans) and sweep the environment for the incident's indicators.
• Check persistence locations (scheduled tasks, services, run keys, startup items) and watch network traffic for callbacks over time, since some persistence acts only on a schedule.
• A password reset does not always end existing sessions: if sign-in logs show an already-issued token still in use, revoke active sessions and refresh tokens.
• After a golden-ticket attack, domain controllers accept tickets signed with the current or the previous krbtgt key, so reset the krbtgt password twice, letting the first reset replicate (Microsoft also advises waiting out the maximum ticket lifetime) before the second.

Release from isolation needs three things: the host is verified clean, every credential exposed on it has been reset, and the environment it rejoins no longer contains active attacker footholds. Release it under heightened monitoring for the incident's indicators so reinfection or missed persistence is caught early.

Restoration brings services back safely:

• Dependency order: identity and name resolution (directory, DNS) first, then data stores, then the applications on top.
• Pre-compromise backups: the timeline sets the restore point. Restore from the last backup taken before the attacker's first activity, because anything later may already contain their changes, and close the entry point before reconnecting.
• Immutable and offline copies: after ransomware, restore from object-locked (immutable) or air-gapped backups. Any copy reachable from the compromised environment may have been encrypted or deleted along with production.

Root cause analysis separates the underlying condition that let an incident happen from the proximate trigger. The trigger is the event that started it (a click, an exploited flaw, a missed detection); the root cause is the control, policy or process gap that let the trigger succeed and will let it happen again, for example a temporary firewall rule nobody was responsible for removing, or a service account excluded from password rotation because no one owned it. Keep asking why past the trigger: what control should have stopped it, and why was that control missing? Scoping questions (how far, how many, which tool) measure the incident; they do not explain it.

Corrective actions fix the process that failed; remediation fixes the instance. Compare:

Extra detective or compensating controls can be worthwhile, but they do not remove the cause. Every corrective action needs an owner, a due date and a measurable check that it worked; a lessons-learned item without them is an intention, not an action.