Domain 7 - Security Operations

About this note

This is the expanded reference version of my original CISSP exam notes. The bullet-point original is preserved in Domain 7 - Security Operations (Original-Stichpunkte) for comparison. Written for readers with several years of hands-on security and networking experience. Domain 7 is the operational domain — forensics, incident response, resilience, and continuity — and overlaps heavily with the BCP/BIA groundwork laid in Domain 1.

Administrative Personnel Security Controls

Administrative security provides the means to control people’s operational access to data — the process layer wrapped around the technical controls. The familiar principles from earlier domains reappear here in their operational form:

• Least privilege and need-to-know — the pairing from Domain 1, now enforced day to day: even holding access rights, if you don’t need to know for the current task, you don’t access. The distinction stays sharp: privilege limits what you can do, need-to-know limits what you should see.
• Job rotation — rotating people through positions serves two purposes: it detects errors and fraud (the successor inherits the predecessor’s books — long-running manipulation requires an accomplice or gets discovered), and it builds the skill redundancy the continuity section below depends on.
• Separation of duties — no single person completes a sensitive process alone; Clark-Wilson (Domain 3) as HR policy.
• Privilege monitoring — elevated access gets elevated scrutiny: admin actions logged and reviewed, because the accounts that can do the most damage warrant the most attention.
• NDAs and background checks — the hiring-practice controls from Domain 1, operationally maintained (checks proportionate to role sensitivity, and repeated for role changes into sensitive positions, not just at hire).

Digital Forensics

Digital forensics focuses on the recovery and investigation of digital evidence — with the constant, non-negotiable companion requirement of provable evidence integrity, because findings that can’t survive courtroom scrutiny are just notes. NIST SP 800-86 — the Guide to Integrating Forensic Techniques into Incident Response — is the reference for the whole section.

The high-level flow:

flowchart LR
	process-->identify-->aquire-->analyze-->make_report

The evidence quality bar is the same five-adjective set from Domain 1’s evidence section, extended by admissibility: evidence must be accurate, complete, authentic, convincing — and admissible. The first four are quality; the fifth is legal survivability, and it’s earned through the process below, not asserted afterwards.

The Forensic Process

Identification — recognize and identify what constitutes evidence: which systems, which media, which data are relevant to the incident.

Preservation — document everything and hash the evidence immediately (the Domain 1 pattern: hash original, work on copies, hash again after — matching hashes prove nothing was altered). This is where the chain of custody begins, and it must be unbroken from this moment forward.

Collection — again: document everything, and handle the evidence as little as possible — every interaction is a potential alteration and a defense attorney’s opening. The technical discipline: work from most volatile to least volatile — RAM before disk. Memory contents, network connections, and running processes evaporate on power-off; disk contents survive. (The full order of volatility: registers/cache → RAM → network state → running processes → disk → backups/archival media.) Collection runs under the incident response plan and includes Legal and HR — because employee rights, privacy law, and (in the US framing) Fourth Amendment considerations determine what may be collected and how. Evidence collected illegally is evidence lost.

Examination — the systematic pass through the collected material: find facts, document them. Extraction and filtering — what’s in this image, this log, this capture.

Analysis — one level up: look at the data for meaning — reconstruct the timeline, establish reason and cause, connect facts into a narrative of what happened.

Presentation in court — findings are presented; the quality of documentation in every prior step determines whether the testimony stands.

Decision — the court rules. Outside the forensic team’s control, but shaped entirely by the rigor of everything before.

Real Evidence and Chain of Custody

Real evidence — the tangible physical objects: the drive, the laptop, the phone (Domain 1’s evidence taxonomy applies in full here). The chain of custody answers, without gaps, for the entire lifetime of the evidence: Who handled it? When did they handle it? What did they do with it? Where did they do it? One undocumented weekend in an unlocked drawer, and everything downstream becomes contestable.

Network Forensics

Network forensics deals with the most volatile and dynamic evidence there is — traffic that exists only in transit. Two operational uses: feeding IDS/IPS (detection in real time) and capturing traffic for law enforcement (evidence in retrospect).

The two capture philosophies, as the field names them:

• Catch-it-as-you-can — capture everything passing a chokepoint, analyze later. Complete, storage-hungry, and the model behind full-packet-capture appliances; retention becomes the limiting factor.
• Stop, look and listen — analyze in flight, store only what matters. Lighter on storage, but what wasn’t deemed interesting at capture time is gone forever.

The modern middle path is flow data (NetFlow/IPFIX): metadata about every connection, cheap to retain for months — no payloads, but often enough to reconstruct who talked to whom, when, how much, which answers most investigative questions.

Software analysis rounds out the forensic toolbox: comparing and reverse-engineering software — malware analysis, determining what a binary actually does versus what it claims.

Incident Management

First, the severity vocabulary — the exam wants these distinctions crisp, and they matter operationally because each tier triggers different plans:

• Event — any observable change in state. Neutral; millions per day.
• Alert — a triggered warning when a defined event occurs.
• Incident — multiple adverse events; something is actually wrong.
• Problem — an incident without a known cause (the ITIL borrowing: incidents get resolved, problems get root-caused).
• Inconvenience (non-disaster) — a non-disruptive failure: a disk dies in a RAID set, a redundant PSU fails. Handled by fault tolerance, not by plans.
• Emergency (crisis) — urgent, with potential for loss of life or property. People-first rules apply immediately.
• Disaster — the entire facility is unusable for 24 hours or more: the DRP’s activation threshold.
• Catastrophe — the facility is destroyed; rebuild-or-relocate territory.

The Incident Response Lifecycle (7+1 Steps)

stateDiagram-v2
     Response: Response (Containment)
     Detection: Detection (Identification)
     Mitigation: Mitigation (Eradication)
     LessonsLearned: Lessons Learned (Post-incident Activity, Post Mortem, Reporting)
     state Lifecycle {
           [*] --> Preparation
           Preparation --> Detection 
           Detection --> Response
           Response --> Mitigation
           Mitigation --> Detection
           Mitigation --> Reporting
           Reporting --> Recovery
           Recovery --> Remediation
           Remediation --> LessonsLearned
           LessonsLearned --> Preparation
     }

The “+1” is Preparation — everything done before any incident: plans, playbooks, tooling, training, and the response capability itself. It’s listed outside the seven because it’s not a response step; it’s what determines whether the seven steps are executed or improvised. (NIST SP 800-61r2 — the Computer Security Incident Handling Guide — is the canonical reference for this lifecycle.)

• Detection (Identification) — events are analyzed and the determination is made: is this an incident? Detection quality is a direct function of the logging and SIEM investment below — you cannot respond to what you cannot see.
• Response (Containment) — first hands-on interaction with the affected systems, with one goal: stop the spread. Isolate hosts, disable accounts, block traffic. The classic tension: containment often destroys volatile evidence, which is why the forensic order of volatility belongs in the containment playbook — capture RAM before pulling the plug, when the situation allows.
• Mitigation (Eradication) — remove the cause: clean or rebuild from backup/restore, eliminate the attacker’s foothold. Note the loop back to Detection in the diagram — after eradication you verify the environment is actually clean, because attackers plant secondary access precisely for this moment.
• Reporting — runs with two audiences in parallel: technical and non-technical. The SOC needs IOCs and timelines; management needs impact, status, and decisions required. Regulatory clocks (GDPR’s 72 hours, from Domain 1) run in this phase too.
• Recovery — carefully restore systems to production: staged, monitored, with heightened watchfulness — restored systems are re-attack targets if the initial vector survived.
• Remediation — generalize the fix: patch every other system vulnerable to the same vector, rotate the credential class that was compromised, close the gap fleet-wide, not just on the victim.
• Lessons Learned — the root-cause analysis and report to senior management: what happened, what worked, what didn’t, what changes. Blameless in culture, concrete in output — its action items feed directly back into Preparation, closing the cycle. The phase most often skipped, and the only one that makes the next incident cheaper.

Preventive and Detective Controls

IDS / IPS

The taxonomy along two axes — placement and method:

• Network-based (NIDS/NIPS) — watching traffic at chokepoints; broad view, blind inside encrypted flows and on host internals.
• Host-based (HIDS/HIPS) — on the endpoint itself: sees process behavior, file changes, local logs — what network sensors can’t.
• Signature-based — matching known patterns: precise on known threats, blind to novel ones by construction.
• Heuristic/behavior-based — modeling normal and flagging deviation: can catch the novel, pays in false positives.

The IDS-evasion catalog attackers use:

• Fragmentation — splitting attacks across packet fragments so no single packet matches a signature; reassembly-order tricks against sensors that reassemble differently than the target.
• Avoiding defaults — running attacks on non-standard ports and channels, escaping port-based assumptions.
• Low-bandwidth coordinated attacks — slow, distributed activity spread thin across sources and time to stay under thresholds.
• Spoofing / proxying — obscuring true origin so attribution and blocking chase ghosts.
• Pattern-change evasion — polymorphism and encoding-shuffling so signatures never match twice.

And the four detection outcomes — the confusion matrix the exam loves: true positive (attack, alarm — correct), true negative (no attack, no alarm — correct), false positive (no attack, alarm — the noise that erodes analyst trust and buries real alerts), false negative (attack, no alarm — the silent, dangerous one). Tuning is the art of trading the last two against each other.

SIEM

The holistic view: gathering logs from everywhere, centralizing storage and interpretation — correlation across sources is what turns isolated events into detected incidents (one failed login is noise; the same account failing across ten systems in a minute is a pattern). The SIEM is Domain 6’s centralized logging plus a correlation and alerting brain — and it’s only as good as what feeds it: log source coverage and parsing quality decide everything downstream. The strategic frame around it is NIST SP 800-137 — Information Security Continuous Monitoring (ISCM): security posture assessed as an ongoing feed rather than a periodic audit snapshot.

Application Whitelisting

Only approved software executes — whitelisted by trusted digital certificate, known hash, or path and name (in descending order of strength: a signature survives updates, a hash pins one exact binary, a path trusts a location — and path rules are the bypassable one). The default-deny inversion of antivirus: instead of enumerating bad, enumerate good. Operationally demanding, extremely effective against commodity malware and unauthorized tools.

Removable Media Controls

Lock down USB, optical drives, memory cards — the Domain 3 mobile-policy item as ongoing operations. Removable media is bidirectional risk: malware in (the parking-lot USB stick remains a reliable pentest win) and data out (Domain 2’s walking remanence problem).

Honeypots / Honeynets

Systems built to look real and exist only to be attacked — deployable internally and externally. Internally they’re tripwires of rare quality: no legitimate user has any reason to touch them, so every interaction is a true positive — the inverse of the false-positive-plagued IDS. The governance note from the original stands: approval is required — this is Domain 1’s enticement/entrapment line, and legal should sign off on the design.

Configuration Management

Every device gets a managed configuration: build from standard images (golden images encode the hardening baseline from Domain 1’s policy hierarchy — every deviation from baseline is visible as drift), and run vulnerability scans before production — the gate that catches misconfiguration while it’s still cheap. Unmanaged configuration is how “temporary” test settings become permanent attack surface.

Patch Management

The unglamorous control that prevents more breaches than any product: keeping the fleet current, via platforms like SCCM/WSUS (today: Intune and friends — your daily bread). The operational discipline: inventory (you patch what you know about), prioritization (exposure × exploitability, not just CVSS), testing (patches break things; rings exist for a reason), and verification (deployed ≠ installed ≠ rebooted).

Change Management

The formalized process with full documentation — the flow:

stateDiagram-v2
     state Change-Flow {
     [*] --> Identify
     Identify --> Propose 
     Propose --> Assess
     Assess --> Provision
     Provision --> Testing
     Testing --> Schedule
     Schedule --> Notification
     Notification --> Implementation
     Implementation --> Report
     Report --> [*]
     }

Identify the need, propose, assess (risk and impact — including rollback planning), provision, test, schedule (maintenance windows), notify stakeholders, implement, report. Change control monitors the change closely through execution. The security relevance is double: uncontrolled change is a leading cause of outages and exposures, and the change record is the baseline that makes unauthorized change detectable — config drift outside an approved change is either a mistake or an intruder, and both need finding.

Zero-Day Attacks

Exploits not known or used before — no signature exists because no one has seen it. The sobering arithmetic from the original: roughly 1% of code has errors, so the supply of undiscovered vulnerabilities is structural, not incidental. The defensive consequence: signature-based tools are blind here by definition; behavior-based IDS/IPS might detect the abnormality — not the exploit itself, but its effects (a word processor spawning shells, a service beaconing out). Zero-day defense is the sum of everything else in this domain: least privilege limits what the exploit can do, segmentation limits where it can go, and behavioral detection notices what it does.

Backups

Fault tolerance framing first: internal SLAs define required availability, met with as much redundancy and resiliency as makes sense — the Domain 1 cost-benefit calculus applied to uptime — and it requires a plan, because redundancy without documented recovery procedures is expensive decoration.

The backup types, defined by their relationship to the archive bit (the classic Windows-world mechanic the exam tests):

• Full backup — backs up everything, clears all archive bits. The anchor of every scheme.
• Incremental — backs up everything changed since the last full or incremental, clears the archive bits. Fastest to take, slowest to restore: recovery needs the full plus every incremental since, in order — and every link in that chain must be intact.
• Differential — backs up everything changed since the last full, does not clear the archive bit — so each differential grows until the next full. Slower to take than incrementals, faster to restore: full plus the latest differential, two pieces, done.
• Copy backup — a full backup on demand that doesn’t touch archive bits — for ad-hoc copies (before a risky change) without disturbing the rotation schedule.

The trade triangle: incrementals optimize backup time, differentials optimize restore time, and the choice should be driven by the RPO/RTO values from the BIA below — plus the rule the exam won’t state but operations learns painfully: an untested backup is a hope, not a control. Restore tests are the only proof. (And in the ransomware era: at least one copy offline or immutable, because attackers delete backups first — the 3-2-1 rule earns its keep.)

RAID

• Disk mirroring (RAID 1) — the same data written to multiple disks: straightforward redundancy, write overhead, requires 2+ disks, and capacity efficiency of 50%.
• Disk striping (RAID 0 / with parity RAID 5) — data written simultaneously across disks for higher speed: without parity, 2+ disks and zero redundancy (RAID 0 multiplies failure probability — one disk dies, everything dies); with parity, 3+ disks (RAID 5), surviving one disk failure while keeping most of the speed.

The operational footnote every NAS owner internalizes eventually: RAID is availability, not backup. It survives disk failure; it faithfully replicates deletion, corruption, and ransomware to every member disk. The backup section above is not made redundant by the RAID section.

Continuity of Operations

Redundancy

The layer-by-layer inventory: disk → RAID, power → UPS and multiple PSUs (feeding the Domain 3 power chain: surge protection → UPS → generator → PDU), network → port teaming/link aggregation, load balancing, and multiple servers — eliminating single points of failure tier by tier, to the depth the BIA justifies.

System Redundancy

Data-level continuity: database shadowing (a live-updated copy at a second location), e-vaulting (electronic transfer of backups to an off-site vault), and classic off-site backup shipping. All three implement the same Domain 2 storage principle: the copy must not share the fate of the original — geographic separation is the point.

BCP — Business Continuity Plan

The long-term, strategic plan — written ahead of time and continually improved — containing the policies and procedures for continued operation after a disruptive event. The umbrella structure (extending Domain 1’s version):

• COOP — Continuity of Operations Plan: essential functions at an alternate site.
• Crisis Communication Plan — external and internal communication, including call trees: activation runs bottom-up (the incident reports upward) and then top-down (leadership cascades instructions) — preferably automated, because manual call trees fail at 3 a.m.
• Critical Infrastructure Protection Plan — the supporting infrastructure.
• Cyber Incident Response Plan — the lifecycle above, as a formal plan document.
• DRP — Disaster Recovery Plan: the short-term, tactical counterpart to the BCP’s strategy — how to get systems back, site by site.
• ISCP — Information System Contingency Plan: per-system recovery procedures.
• Occupant Emergency Plan — the evacuation plan; people first, always.

Disaster Categories

• Natural — nature-caused: devastating but infrequent. Regional by nature, which is what drives geographic separation requirements for recovery sites.
• Human — intentional or unintentional: errors and omissions, warfare, terror, sabotage, ideologically or financially motivated attacks. Two facts worth their exam weight: the most common source of disruptive events is internal employees, and human-caused events are typically lower-impact and easier to mitigate than natural ones — frequent small versus rare catastrophic.
• Environmental — the facility systems: power problems, heat, pressure, humidity — Domain 3’s HVAC and electrical section, viewed as a threat category.

DRP Basics

The three questions every DRP must answer: What is the objective and purpose? Who are the people and teams responsible when disruption happens? What will these people do when the disaster hits? A plan that doesn’t answer all three for every scenario is documentation, not capability.

The continuous cycle:

stateDiagram-v2
s1: Education, Plans, Processes, Training
	s1 --> Preparation
	Preparation --> Response
	note left of Response: DR / BCP / EOP 
	Response --> Recovery
	note left of Recovery: post-disaster recovery plan
	Recovery --> Mitigation
	note left of Mitigation: pre-disaster mitigation plan
	Mitigation --> Preparation

• Response — how we react: assess the incident (scope, severity, which plans activate) and notify (the call trees above). Assessment quality here determines everything after — under-assessing burns hours, over-assessing burns credibility.
• Recovery — reestablish basic functionality, with all key stakeholders involved, acting on the assessment. Basic functionality first, full restoration after — priorities come straight from the BIA’s criticality rankings.
• Mitigation — the pre-disaster half: what’s changed before the next event to reduce its impact — feeding back into Preparation.

Developing the BCP and DRP

The eight steps — the same project structure as Domain 1, now with the operational emphases:

1. Project Initiation
2. Scope the project
3. Business Impact Analysis
4. Identify Preventive Controls
5. Recovery Strategy
6. Plan Design and Development
7. Implementation, Training and Testing
8. BCP/DRP Maintenance

Senior management must be on board — at minimum at initiation and final approval — because they are responsible (the non-delegable accountability from Domain 1), continuity requires top-down commitment, and serious disasters pull in the legal team (contractual obligations, liability, notification duties).

The BCP team structure, mapped to the recovery phases: the Rescue Team handles activation and notification (and immediate response), the Recovery Team executes the failover to the alternate site, and the Salvage Team manages the failback — restoring and returning to the primary site. Salvage is the underrated one: failing back is a full migration of a now-production workload, often riskier than the failover was.

BIA — Business Impact Analysis

The BIA identifies critical and non-critical functions — critical meaning disruption is not acceptable. Covered in depth in Domain 1; the operational recap of the values assigned per critical system:

• RPO — Recovery Point Objective: the amount of data loss that is acceptable — drives backup frequency and replication design.
• RTO — Recovery Time Objective: time to restore the system (hardware/platform).
• WRT — Work Recovery Time: time to reconfigure and validate the recovered system into a working business function.
• MTD — Maximum Tolerable Downtime, with the governing inequality: MTD ≥ RTO + WRT. If the sum exceeds the MTD, the recovery strategy is inadequate by definition.
• Supporting metrics: MTBF (mean time between failures), MTTR (mean time to repair), MOR (minimum operating requirements — what an alternate site must actually provide).

Supply and Infrastructure Redundancy

The dependency questions beyond your own walls: if an earthquake hits, can suppliers still deliver? How long can we operate without water? — fuel for generators, replacement hardware lead times, staffing access to the site. A perfectly redundant data center with a single-source diesel contract has a hidden SPoF; the BIA’s dependency mapping has to extend into the supply chain.

Disaster Recovery Sites

The site hierarchy, in descending readiness (and cost):

• Redundant site — a complete identical facility with staff on site: effectively a second production site. Near-zero failover time, double the cost.
• Hot site — houses the critical applications and systems, powered and current (or near-current) on data: failover in minutes to hours.
• Warm site — infrastructure and connectivity in place, but systems are typically restored from backups and traffic is failed over manually: hours to days.
• Cold site — the data center shell without hardware: power, cooling, space. Weeks to become operational; cheapest to keep.
• Reciprocal agreement site — a contract with another organization promising space in their facility — or its modern relatives: promised capacity, cloud recovery regions, mobile sites (containerized data centers). Reciprocal agreements are cheap and fragile: in a regional disaster, both parties need the capacity simultaneously, and the promise meets its first real test during the event itself.

The selection logic closes the loop to the BIA: the site tier is dictated by the MTD/RTO of the workloads it must carry — a cold site cannot honor a four-hour RTO, and paying for a redundant site to protect a two-week MTD is Domain 1’s safeguard math failing.

Employee Redundancy

The continuity blind spot: hardware gets redundancy, people often don’t. The controls: off-site copies of plans (a plan locked in the burning building is no plan), a designated EOC (Emergency Operations Center) — the temporary coordination point, MOU/MOA (memoranda of understanding/agreement) formalizing assistance arrangements, and a deliberate plan for key-person unavailability: skilled employee redundancy to the same degree as critical hardware, built through training and job rotation — the same rotation that detects fraud also ensures more than one person can run the payroll system when it matters.

Testing the Plans

An untested plan is a hypothesis. The test ladder, ascending in realism and risk:

Simulated tests (no production impact):

• DRP review — the involved team members review the plan itself.
• Read-through (checklist) — participants verify their checklist components: completeness check.
• Walk/talk-through — managers and critical personnel walk the scenario together at the table: the cheapest way to find the gaps between team A’s assumptions and team B’s.
• Simulation test — a scenario is played out realistically, decisions and communications exercised, systems untouched.

Physical tests (real systems involved):

• Parallel processing — the recovery site runs the workload alongside production: proves the site works without betting production on it.
• Parallel interruption / full interruption — production is actually failed over (partially, then fully). The only test that proves the plan end to end — and a test that can itself cause the disaster it rehearses, which is why full-interruption tests need the same senior-management sign-off as the plans themselves.

Maintenance: plans are continually updated — an iterative process; every major organizational change triggers an update, and old plan versions are archived, never deleted (the audit trail of what the plan said at the time matters legally and for learning).

The three verification flavors, distinguished: Testing ensures the plan is accurate, complete, and effective; drills are walkthroughs focused on training the staff; auditing brings a third party to verify the plan is understood, followed, current, and effective — the Domain 6 principle that self-assessment has limits.

After a Disruption — Common Mistakes

The failure catalog, each one a post-mortem cliché for good reason: lack of senior leadership support (the plan starves), lack of business unit involvement (IT recovers systems nobody prioritized correctly), lack of critical staff prioritization, too narrow scope, inadequate telecommunications and supply chain management (the site is up, nobody can reach it, parts can’t arrive), lack of testing, lack of training and awareness, and failing to keep the BCP/DRP current — or keeping no version control on the plans. Reading the list backwards is a decent maturity checklist.

Guidelines

The reference shelf: NIST SP 800-34r1 (contingency planning), ISO 22301 (the certifiable business continuity management standard), ISO/IEC 27031 (ICT readiness for business continuity, bridging the 27000 family to BC), and the Business Continuity Institute’s Good Practice Guidelines.

---

Erstellt: 2026-07-08 — ausformulierte Fassung der Original-Stichpunkte, siehe Domain 7 - Security Operations (Original-Stichpunkte)