Security Operations

Security Operations carries 13% of the exam (tied with Security Architecture & Engineering, Communication & Network Security, and Identity & Access Management) yet holds 15 subtopics, the largest subtopic count of any domain, because it is where the program designed elsewhere is actually operated. Sort the 15 into four jobs and the domain stops feeling like a grab-bag. The foundational concepts set the rules of access (least privilege, need-to-know, separation of duties, privileged-account control, SLAs) in Security Operations Concepts and protect the things operations runs in Resource Protection. The detect-and-respond chain turns activity into action: Logging & Monitoring and Detective & Preventive Controls produce the signal, Incident Management runs the response lifecycle, and Investigations preserves the evidence. The keep-it-stable controls hold systems in a known, governed state: Configuration Management, Change Management, and Patch & Vulnerability Management. The resilience cluster keeps the business alive through disruption: Recovery Strategies, Disaster Recovery, DR Testing, Business Continuity Planning, Physical Security, and Personnel Safety. Knowing which of the four jobs a question is in usually narrows it to two or three subtopics before you read the options.

Almost every operational control is a way of enforcing one of two foundational principles, so name them first. Least privilege grants each person, process, or service only the access an assigned task requires; need-to-know is that same principle narrowed to specific information (the clearance is the ceiling, need-to-know is the gate), and privileged-access management is least privilege applied to the admin, root, service, and break-glass accounts that can override every other control. Separation of duties (SoD) splits a sensitive task so no single person can complete and conceal it (fraud becomes possible only with collusion) and it is operationalized by dual control, M-of-N, and split knowledge, while job rotation and mandatory vacation are the detective controls that surface an abuse someone is actively hiding. These two ideas reappear far outside Operations Concepts: the rule that whoever administers access controls must not also administer the audit logs is SoD; the extra scrutiny on privileged sessions is least privilege; the contractual SLA carrying a third party's security obligation is least privilege made enforceable when you cannot configure the system yourself.

The detect-and-respond subtopics form one pipeline with a recurring lesson: logging records events, monitoring is the review that turns them into detection, and an organization that logs exhaustively but reviews nothing detects nothing. Centralize logs off the generating host (a compromised host's local logs are erased by the attacker) and synchronize every clock with NTP, or the SIEM cannot correlate or order the attack. Detection methods split cleanly into signature-based (precise for known threats, blind to anything novel) and anomaly/behavior-based (catches the unknown at the cost of false positives), and that split decides device questions too: an IDS observes a copy of traffic and only alerts (detective), while an IPS sits inline and can block (preventive). Once an event is classified as an incident (a violation or imminent threat to confidentiality, integrity, or availability, the narrow subset of all observable events) the exam-correct first action on an active compromise is almost always containment, not eradication: stop the spread before you clean up, then eradicate and recover. Prioritize incidents by business impact and recoverability, never first-come-first-served, and never skip the Lessons Learned step that feeds the fix back into preparation.

The three keep-it-stable subtopics are constantly confused, so fix the boundary before the detail. Configuration management owns the technical fact of what a system is configured to be: the formally approved secure baseline, the inventory of configuration items, and the continuous detection of drift away from that baseline. Change management owns the governance process by which a proposed modification reaches production (requested, security-impact-analyzed, approved by a Change (or Configuration) Control Board, tested, scheduled, and given a back-out plan) and it answers whether a change is allowed, never what the system is. They interlock because the only sanctioned way to alter an approved baseline is through change control. Patch & vulnerability management sits inside both: a patch is preventive maintenance rather than firefighting, prioritized by risk to the organization (exploitability and asset criticality) rather than by raw CVSS severity, tested through phased canary deployment with a back-out ready, and pushed to production through that same change-control process, with an expedited, retroactively-documented path for an actively-exploited emergency. An accurate, continuously-maintained asset inventory is the shared substrate all three read from.

The resilience cluster answers one question, how the organization survives a disruption, at descending altitude, and the pieces nest rather than compete. Business continuity is the umbrella that keeps the whole mission running (payroll, customer service, with or without IT); disaster recovery is its information-system subset that restores technology, typically after a physical disaster forces relocation to an alternate site; DR testing proves the recovery plan works before a real event does. Recovery strategy is the spend you commit in advance so recovery fits inside the Recovery Time Objective (RTO) and loses no more data than the Recovery Point Objective (RPO) allows, and those targets are set earlier by the Business Impact Analysis (BIA), so this domain spends to meet them rather than re-deriving them. RTO drives the alternate-site choice along a single cost-versus-speed axis (cold cheap and slow, warm in between, hot expensive and instant); RPO drives backup cadence, with the 3-2-1 rule and an offsite copy as the load-bearing defense. When systems are recovered, they come back in BIA-priority order, most-critical first and bottom-up within a system. The cluster's overriding rule, shared with Physical Security and Personnel Safety, is that human life and safety outranks every asset: a life-safety egress door fails open even though an access-control door fails closed, and no one re-enters a dangerous building to retrieve a backup tape.