Detection, response and security operations

NIST SP 800-61 Rev. 3, published in April 2025, is the current NIST incident response publication. It aligns incident response recommendations with CSF 2.0 risk management activities rather than presenting the old Rev. 2 lifecycle as the primary model. The older four-phase lifecycle remains useful operational vocabulary, but it should be labelled as legacy shorthand. The work still has four practical activity groups:

1. 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.
2. 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.
3. 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.
4. 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.

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.

MITRE ATT&CK Enterprise, current release v19.1 as of 28 April 2026, 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 among the adversaries targeting your sector, 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.

ATT&CK is versioned, and recent releases changed how it expresses detection. Version 18, in October 2025, retired the loose per-technique detection notes and replaced them with structured Detection Strategies and Analytics objects, so a technique now points to named, reusable detection logic rather than a paragraph of prose. Version 19, in April 2026, split the old Defence Evasion tactic into Stealth and Defence Impairment and added industrial control system sub-techniques. Pin the version you map coverage against: a claim built on v17 does not line up cleanly with the v19 structure.

Reading a Detection Strategy is now a core skill. Each one names the behaviour it targets, lists the Analytics that implement it, and states the log sources and platforms each Analytic needs. To read one, start from the technique it defends, confirm you actually collect the data sources its Analytics require, then check that the Analytic logic matches how the behaviour shows up in your own telemetry. A strategy you cannot feed with data is a coverage gap you have not admitted to yet, the same failure as an untested rule.

A detection is a small program: it takes telemetry as input and decides whether a behaviour is present. Treating detections that way is the discipline called detection as code, and it exists because detections rot the way any software rots. Log schemas change, a field gets renamed, an endpoint agent updates its event format, and a rule that fired correctly last quarter now silently matches nothing. A rule written and tuned only inside a console has no history, no review and no test, so nobody notices the rot until an intrusion walks straight past it.

Detection as code puts the rule set in Git and runs it through the same lifecycle as application code. An analyst authors the rule as a Sigma file; a peer reviews the change; a continuous integration job tests it against recorded true-positive and known-benign telemetry, so a broken field reference or an over-broad match fails the build; the rule deploys to production; the team tunes it as false positives appear; and it is retired when the behaviour or the data source it depends on goes away. A failed test returns the change to the author rather than to production, exactly as a failing unit test would. The figure traces that cycle.

A security operations centre is a capability, not a room full of screens, and its tooling has converged enough that the acronyms need pinning down once. A SIEM collects and correlates logs from across the estate and runs the detection rules against them. SOAR, security orchestration, automation and response, adds the playbooks that act on an alert, enriching it, opening a case or isolating a host without waiting for a human to click through consoles. XDR, extended detection and response, is the vendor-integrated bundle of endpoint, identity and network telemetry with detection and response built in. The three overlap heavily now, so the useful question is not which label a product wears but whether collection, correlation, automation and response are each covered somewhere.

Running that capability around the clock is the sourcing decision. An in-house SOC buys deep knowledge of your own environment and direct control, at the cost of hiring and retaining analysts for night and weekend cover. Managed detection and response, or MDR, buys a provider’s trained analysts and around-the-clock coverage on day one, at the cost of their shallower knowledge of your systems and a dependence on how well you integrate with them. The factors that decide it are the maturity of your telemetry, whether you can recruit and keep the staff, your tolerance for a third party inside your incident response, and the rules on where your data and monitoring may sit. Many organisations run a hybrid: MDR for round-the-clock triage, and a small in-house team for detection engineering and the incidents that need context only they hold.

None of this improves on its own. Purple teaming is the feedback loop that keeps it honest: the offensive side runs a known technique, the defensive side checks whether the telemetry captured it and the rule fired, and each gap becomes a specific detection to build or a data source to start collecting. Threat hunting works the other way round, starting from a hypothesis about an adversary already inside and searching the data for it, and each hunt that finds a repeatable signal becomes a new detection. Both turn one-off effort into durable coverage.

Feeding all of it is cyber threat intelligence, which is a discipline rather than a feed you buy. It starts from intelligence requirements, the actual questions the organisation needs answered, such as which groups target our sector and how they gain initial access. The CTI lifecycle then runs from those requirements through collection, processing, analysis and dissemination, and back to the people who act on it. Sharing is governed by the Traffic Light Protocol, which marks how far a piece of intelligence may travel, from TLP:RED for named recipients only to TLP:CLEAR for public release. Information Sharing and Analysis Centres, the sector bodies where organisations pool indicators and warnings, are where much of that exchange happens, so a bank sees what other banks are facing before the same campaign reaches it.