Detection and incident response
By the end of this module you will be able to:
- Apply the NIST SP 800-61 incident response phases to a described incident scenario
- Distinguish IOCs and IOAs and explain why IOA-based detection is more resilient to attacker evasion
- Map observed attacker behaviour to MITRE ATT&CK tactics and techniques
- Describe the SANS PICERL process and the key decisions at each step
NotPetya global attack, 27 June 2017
NotPetya and Maersk: 45,000 PCs, 4,000 servers, $300 million in 10 days
On 27 June 2017, the NotPetya malware began spreading from Ukraine across global networks. Within hours it had reached Maersk, the Danish shipping conglomerate responsible for approximately 20% of global container shipping. Maersk's entire global IT infrastructure, across 45,000 PCs, 4,000 servers, and 2,500 applications in 130 countries, was rendered non-functional. The company rebuilt its IT estate in 10 days, installing 45,000 new PCs and 4,000 new servers. Maersk estimated the financial impact at $300 million.
NotPetya used the EternalBlue SMB exploit and the Mimikatz credential-dumping tool. Organisations with signature-based IOC detection that had not updated signatures for EternalBlue missed the initial infection. Organisations with behaviour-based IOA detection monitoring for LSASS memory access followed by lateral movement via PsExec or WMI could have detected NotPetya's propagation pattern regardless of whether the specific binary hashes were known.
By the time signature updates were available, the infection had already reached global scale. Maersk was collateral damage from an attack on Ukraine's financial system, not a targeted attack. This is the scale of incident that a mature IR programme must be designed to handle.
NIST SP 800-61 incident response phases
NIST SP 800-61r2 (2012) established the four-phase incident response lifecycle that remains the most widely taught and operationally used model. SP 800-61r3 (published April 2025) reframes incident response as a CSF 2.0 Community Profile mapped to the six CSF functions, but the underlying activities remain consistent. The four phases are:
- Preparation. The most important phase; teams that invest in preparation handle incidents faster with better evidence and less damage. Key activities: an IR plan approved by leadership defining decision authority and escalation thresholds; pre-drafted communication templates for internal escalation, customer notification, and regulatory notification (UK GDPR requires ICO notification within 72 hours of becoming aware of a breach); forensic tooling (FTK Imager, WinPmem, LiME); and an IR retainer with a pre-contracted external IR firm (Mandiant, CrowdStrike Services, NCC Group) deployable within hours.
- Detection and Analysis. Receiving and triaging alerts from SIEM, EDR, network IDS, and external sources. Analysis requires UTC timestamps (local time introduces ambiguity during cross-timezone incidents), scope determination, incident type classification (data breach, ransomware, insider threat, DDoS), and severity assignment that determines escalation path.
- Containment, Eradication, and Recovery. Containment is incident-dependent. For active ransomware: network isolation of affected segments. For data exfiltration: preserve volatile evidence first before containing. For insider threat: covert monitoring may precede containment to gather evidence. Eradication must be complete before recovery begins; recovering systems with remnant backdoors restores the attacker's access. Recovery involves restoring from verified clean backups, patching the exploited vulnerability, and monitoring closely for re-compromise during the first 30 days post-recovery.
- Post-Incident Activity. The lessons-learned review should occur within two weeks of incident closure. It produces specific remediation actions with owners and deadlines, not general recommendations.
With an understanding of nist sp 800-61 incident response phases in place, the discussion can now turn to sans picerl and iocs versus ioas, which builds directly on these foundations.
SANS PICERL and IOCs versus IOAs
The SANS PICERL framework (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned) maps closely to the NIST SP 800-61 phases and is widely used operationally. The two frameworks are complementary: many organisations use PICERL operationally and NIST 800-61 for documentation and compliance alignment.
IOCs (Indicators of Compromise) are artefacts indicating a system may have been compromised: file hashes of known malware, malicious IP addresses, C2 domain names, registry keys created by malware families. IOCs are reactive: they are derived from known attacks and do not detect novel threats. Attackers routinely repack malware binaries to change hashes and rotate infrastructure to change IPs.
IOAs (Indicators of Attack) are behavioural patterns indicating an attack is in progress regardless of specific tooling: LSASS memory access by a non-system process, followed by SMB connections to previously uncontacted internal servers, followed by WMI remote execution. IOAs are more resilient to evasion because attackers can change tools but not the fundamental behaviours required to achieve their objectives (credential dumping, lateral movement, data staging). NotPetya's EternalBlue/Mimikatz chain would have triggered IOA-based detections regardless of whether the specific binary hashes were in any signature database.
With an understanding of sans picerl and iocs versus ioas in place, the discussion can now turn to mitre att&ck and detection engineering, which builds directly on these foundations.
“Organizations should focus on detecting attack behaviors rather than solely on detecting known attack tools and malware, as behavioral indicators are more resilient to attacker evasion and can detect novel threats using familiar techniques.”
NIST SP 800-61r3 (April 2025), Detect function recommendations
“ATT&CK is designed to be used as a tool to systematically categorize and describe adversary behavior with the goal of allowing defenders to understand and detect such behavior in their environments. By understanding adversary behavior, defenders can make better-informed decisions about where to invest in detections.”
MITRE ATT&CK Design and Philosophy (2018), Section 1.1: Purpose and Motivation - Tactic: Initial Access
MITRE ATT&CK and detection engineering
MITRE ATT&CK (Enterprise Matrix, current release v18.1 as of November 2025) is a globally accessible knowledge base of adversary tactics and techniques based on real-world observations. It contains 14 tactics and over 600 techniques. The 14 Enterprise tactics in order of a typical attack lifecycle: Reconnaissance (TA0043), Resource Development (TA0042), Initial Access (TA0001), Execution (TA0002), Persistence (TA0003), Privilege Escalation (TA0004), Defence Evasion (TA0005), Credential Access (TA0006), Discovery (TA0007), Lateral Movement (TA0008), Collection (TA0009), Command and Control (TA0011), Exfiltration (TA0010), and Impact (TA0040).
The NotPetya chain maps to: Execution (EternalBlue SMB exploit, TA0002), Credential Access (Mimikatz LSASS dump, TA0006, T1003.001), and Lateral Movement (PsExec/WMI, TA0008, T1021.002/T1047). Detection engineering using ATT&CK identifies which techniques are prevalent in your threat landscape, maps them to specific log sources, and writes Sigma detection rules targeting those patterns.
A mature detection engineering process: hypothesis generation (what techniques are threat actors in our industry using?), log source mapping (which log contains the signal?), Sigma rule development, testing against historical logs and a controlled test environment, deployment with defined alert priority and response playbook, and maintenance when attacker tooling changes. Rules must be tested against real attack patterns; an untested rule may have a syntax error, reference the wrong log field, or require data that is not actually collected.
Common misconception
“Having an incident response plan on file means your organisation is prepared to respond to a major incident.”
An IR plan that has never been exercised is a document, not a capability. When a real incident occurs, responders under pressure will revert to instinct rather than a plan they have never practised. Effective preparation requires tabletop exercises at least annually, including a realistic scenario with timed decision points, communication role-play, and a specific question for every named decision authority: do you know what triggers require your approval? Organisations that exercised before NotPetya-scale events contained blast radius significantly faster than those relying on untested plans.
During a tabletop exercise, a ransomware scenario describes encrypted files on a file server now spreading laterally via compromised service account credentials. The team debates immediately isolating the affected file server. What is the primary risk of immediate isolation, and which NIST SP 800-61 phase guides the decision?
A threat analyst reviews EDR alerts and observes: LSASS memory access from a non-system process, followed by new SMB connections to three internal servers the workstation had never contacted, followed by WMI remote execution on those servers. Which MITRE ATT&CK tactics are represented, and is this detection IOC-based or IOA-based?
After recovering from a ransomware incident, your CISO asks for three specific improvements to the detection capability before the next board meeting. Your current state: Splunk SIEM deployed but rules only alerting on known ransomware hashes; no EDR; Windows event logging enabled on all servers but Sysmon not deployed. Which three improvements provide the greatest detection coverage increase for the next ransomware-style attack?
Key takeaways
- NIST SP 800-61r2 defines the IR lifecycle as Preparation, Detection and Analysis, Containment/Eradication/Recovery, and Post-Incident Activity. SP 800-61r3 (April 2025) reframes these as CSF 2.0 function mappings, but the underlying activities remain the same. Preparation is the phase that determines how well all subsequent phases execute.
- SANS PICERL (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned) maps closely to the NIST SP 800-61 phases and is widely used operationally. Both frameworks are complementary; use PICERL operationally and NIST for compliance documentation.
- IOAs (behavioural patterns) are more resilient to attacker evasion than IOCs (known-bad artefacts). Attackers change tools; they cannot change the fundamental behaviour required to achieve their objectives. NotPetya would have triggered IOA detection regardless of hash-based signatures.
- MITRE ATT&CK provides 14 tactics and over 600 techniques. Use it to identify detection coverage gaps prioritised by threat actors relevant to your industry, not as an exhaustive checklist.
- Detection rules must be tested against real attack patterns. An untested rule that references the wrong log field or requires data that is not collected provides false assurance of detection capability. Run purple team exercises to validate deployed rules.
You can now detect and respond to incidents. But security decisions do not exist in a vacuum - they interact with privacy law, ethical obligations, and audit requirements. How do you balance security controls with individual rights and organisational accountability? Module 23 covers privacy, ethics, and auditability.
Standards and sources cited in this module
NIST SP 800-61r3: Incident Response Recommendations and Considerations (April 2025)
Four-phase IR lifecycle: Preparation, Detection and Analysis, Containment/Eradication/Recovery, Post-Incident Activity. Section 3.3: evidence preservation versus containment.
MITRE ATT&CK Enterprise Matrix
14 tactics (TA0001-TA0043) and over 600 techniques with detection and mitigation guidance. ATT&CK Navigator for coverage gap analysis.
SANS Incident Handler's Handbook
PICERL methodology: six-step incident handling process with decision guidance at each step.
NotPetya technical analysis (ESET and Cisco Talos, 2017)
EternalBlue/Mimikatz attack chain, propagation mechanism, and IOA versus IOC detection implications.
WIRED: The Untold Story of NotPetya (2018)
Maersk incident account: 45,000 PCs, 4,000 servers, $300 million impact, 10-day recovery.