Security operations, monitoring and response
This domain is about running security as a repeatable service rather than a series of heroic acts. Questions target process ownership, change control and the operational metrics that show the programme is working.
The operational machine
A SOC works from documented runbooks and defined escalation paths. Asset inventory is the foundation - you cannot protect, patch or monitor what you have not recorded, including cloud instances and shadow IT. Configuration management keeps hosts on the approved baseline and detects drift. Patch management follows a cycle: inventory, assess, test, deploy, verify, report.
Change and problem management
Changes follow the organization’s approved, risk-proportionate authorization path with impact analysis, recovery planning and suitable test evidence; a CAB is one possible arrangement rather than a mandatory gate for every change. Emergency changes may be pre-approved but must be documented retrospectively within a defined window. Problem management removes root causes so the same incident does not recur. Separation of duties means the person who builds a change is not the only one who approves and deploys it.
Logging and operational metrics
Centralise logs in a SIEM, set retention to match legal and evidentiary needs, protect log integrity, and synchronise clocks with NTP so correlation works. Monitor the monitoring: a log source that stops sending is itself an alert. Track outcomes such as mean time to detect, mean time to respond, patch compliance percentage and EDR coverage, not just the number of alerts raised.
Worked example
A team needs an inbound firewall rule for a vendor. The correct path is a change request naming source, destination, port, business justification and expiry date; risk review; CAB approval; implementation in a change window; verification by test; documentation; and a scheduled review to remove the rule when the contract ends. Permanent rules with no owner are a recurring audit finding.
Traps
- Treating documentation as optional for emergency changes.
- Measuring activity (alert counts) instead of outcomes (detection and response times).
- Letting one person request, approve and implement a change.
- Forgetting to decommission accounts, rules and access when a project or vendor ends.
This domain tests detection engineering and the incident response lifecycle. Questions ask what to do first, what evidence to preserve, and which phase a given action belongs to.
Detection
Sources include firewall and proxy logs, DNS queries, authentication logs, EDR telemetry, application logs, cloud audit trails and threat-intelligence feeds. A SIEM correlates events into use cases: impossible travel, brute force followed by success, new service creation, mass file encryption. Tune rules to reduce false positives, because an ignored alert is worse than no alert. Indicators of compromise (hashes, IPs, domains) are cheap and perishable; behaviour-based detection survives infrastructure changes.
Historical lifecycle model (NIST SP 800-61 Revision 2)
- Preparation - plans, contacts, tooling, playbooks, training.
- Detection and analysis - validate, scope, classify severity.
- Containment, eradication and recovery - short-term containment (isolate, block), long-term containment (rebuild), remove the root cause, restore from clean backups.
- Post-incident activity - lessons learned, control improvements, formal report.
Evidence handling
Capture volatile data first: memory, network connections, running processes, then disk. Work on copies, hash images with SHA-256, and record the chain of custody. Do not power off a suspected host before memory is captured unless containment demands it. Maintain an incident log recording times, actors and decisions.
Worked example
A workstation shows ransomware notes and encrypted shares. First, isolate the host through EDR without shutting it down (containment). Second, capture memory and preserve logs. Third, find the entry point and check file servers for lateral movement. Fourth, restore data from an offline backup taken before encryption. Finally, patch the entry vector and rehearse the updated playbook, then record lessons learned.
Traps
- Jumping to eradication before containment, letting the attacker keep access.
- Shutting down or reimaging the only evidence.
- Waiting for perfect information instead of containing and then investigating.
- Waiting until final resolution to consider reporting duties; determine the actual applicable triggers, deadlines, roles and authority without inventing a universal period.
Current NIST SP 800-61 Revision 3 supersedes Revision 2 and integrates incident response with the broader CSF 2.0 risk-management context. A historical phase mnemonic can still organize a classroom scenario, but it should not be claimed as the complete current standard. In practice, preserve safety and containment while gathering evidence; volatile-memory collection is not a reason to permit continuing harm or to exceed authority.