Incident Investigation and Evaluation

Incident Investigation and Evaluation

Once an event is detected, the CSIRT must triage it: confirm it is a real incident, classify its type (malware, data breach, denial of service, insider misuse, unauthorized access), and prioritize it by severity. CISM stresses that severity is driven by business impact and asset criticality, not by how clever or rare the attack is. A ransomware hit on a non-critical test server outranks an exotic exploit on a sandbox only if the business consequence is greater.

Severity classification

A repeatable severity scheme lets the manager allocate response resources and decide escalation. A common scheme:

Evidence integrity and chain of custody

If an incident may lead to prosecution, litigation, or insurance claims, the manager must ensure evidence is forensically sound from first response. Three exam anchors:

• Chain of custody — a documented record of who handled each item, when, and why. A break in the chain can make evidence inadmissible.
• Integrity verification — compute and record a cryptographic hash (e.g., SHA-256) of images and use write-blockers so originals are never altered. Analyze a copy, never the original.
• Order of volatility — collect the most perishable data first: CPU registers/cache, then RAM and running processes/network connections, then disk, then archival/backup media. Pulling the plug to "preserve" a machine destroys volatile memory that may hold malware or keys.

Manager-level traps

A frequent CISM scenario: an analyst, eager to clean a system, reimages an infected host. The trap is that this destroys evidence and root cause. The manager-level priority — when legal exposure exists — is to preserve evidence and isolate, not to rush eradication. Another trap pits "restore service immediately" against "investigate." The defensible answer balances RTO against legal/regulatory duties; if a breach of regulated data is suspected, preservation and notification obligations can outweigh speed.

Declaration and scoping

Before any deep investigation, someone with authority must formally declare the incident, which starts the response clock and notification obligations. CISM expects this authority to be pre-assigned in the IRP so that a junior analyst is not deciding alone whether a Sev 1 exists. After declaration, the team scopes the incident: which systems, accounts, and data are affected, when the compromise began (the "patient zero" and initial access vector), and whether it is still active.

Scoping prevents the two opposite errors the exam tests — under-scoping (cleaning one host while the attacker persists elsewhere) and over-reacting (shutting down unaffected business units). Indicators of compromise gathered here feed both containment and threat-intelligence sharing.

Linking impact to the business

Evaluation translates technical findings into business impact: regulated data exposed, financial loss, safety, contractual penalties, and reputational harm. This is what justifies escalation and resourcing to executives. A breach involving cardholder data invokes PCI DSS obligations; protected health information invokes HIPAA; EU personal data invokes the GDPR. The manager records these exposures during evaluation because they drive notification deadlines downstream. An exam answer that evaluates an incident purely by packet counts, while ignoring the regulated data at stake, is reading like an analyst rather than a manager.

Root-cause analysis

Evaluation closes with root-cause analysis (RCA). Suppressing a symptom (blocking one IP, killing one process) without finding the underlying control failure invites recurrence. The manager wants the answer to the question, "What control gap allowed this, and who owns fixing it?" — feeding lessons learned back into the program. RCA techniques include the 5 Whys and fishbone (Ishikawa) diagrams, but on the exam the testable point is that RCA produces an owned, tracked corrective action, not merely a closed ticket.

RCA also distinguishes the proximate cause (the exploited vulnerability) from systemic causes (missing patch process, weak monitoring), and the manager prioritizes fixing the systemic gap so a whole class of incidents is prevented, not just the one that occurred.

False positives, attribution, and overreaction

Evaluation also guards against two costly errors. The first is acting on a false positive — declaring an incident and disrupting the business over a benign anomaly; mature triage confirms an event is real before escalation. The second is over-investing in attribution (naming the specific threat actor) when the business decision does not require it. CISM consistently favors the action that protects the organization over the action that satisfies curiosity: knowing who attacked is rarely the manager's priority compared with knowing what was accessed and what must be remediated.

A defensible evaluation answer confirms scope and impact, preserves evidence, and escalates per severity, while resisting the urge to chase technical detail that does not change the response. When a stem offers "identify the nation-state behind the attack" versus "determine which records were exposed," the records-exposure option wins because it drives notification and remediation duties.