CISSP Security Operations: Investigations, Logging, and Configuration Management

Introduction

CISSP security operations combines forensic readiness, protected logging, configuration management, and resource protection. This lesson opens Domain 7, Security Operations (13% of the exam, ISC2 exam outline effective 15 April 2024). It covers tasks 7.1 to 7.5: understand and comply with investigations, conduct logging and monitoring activities, perform configuration management, apply foundational security operations concepts, and apply resource protection. The lesson on incident management, detection, patching, and change control continues with tasks 7.6 to 7.9; the lesson after covers recovery, continuity, and physical security.

Operations is where policy meets daily reality. When something goes wrong, the quality of your investigation, the completeness of your logs, the accuracy of your configuration records, and the discipline of your operational controls decide whether you can understand the event, prove what happened, and recover with confidence.

Learning objectives

After this lesson you can:

1. Describe the types of investigations and the steps of a forensically sound process, including evidence handling and chain of custody.
2. Explain admissible evidence, the digital forensics order of volatility, and the role of legal counsel.
3. Design logging and monitoring: sources, centralization, SIEM, SOAR, UEBA, egress monitoring, and log protection.
4. Use threat intelligence and threat hunting to improve detection.
5. Apply configuration management: baselines, inventory, automation, and drift control.
6. Apply foundational operations concepts: need to know, least privilege, separation of duties, privileged account management, job rotation, service level agreements.
7. Protect resources: media, information, and assets across their life, and apply secure provisioning.

1. Understanding and complying with investigations

1.1 Types of investigations

The proof standards above are U.S. examples, not rules for every jurisdiction. Preserve evidence rigorously in every investigation; the burden for a court decision does not determine whether an operational collection can be careless. Always involve legal counsel and, when appropriate, law enforcement early: counsel advises on privilege, privacy, and notification duties, and on whether to preserve evidence for litigation (a legal hold).

1.2 The investigation process

The following operational workflow incorporates forensic preservation and incident response. NIST SP 800-86 describes collection, examination, analysis, and reporting; eDiscovery has its own overlapping legal workflow.

1. Preparation: policies, trained staff, tools, and appropriate authority and lawful grounds to investigate and monitor. Acceptable use policies and banners support notice but do not by themselves override privacy law.
2. Detection and identification: recognize that an event of interest occurred and decide whether to investigate.
3. Containment and preservation: balance ongoing harm and evidence preservation under the response plan. Preserve volatile data first where safe and feasible, documenting unavoidable changes.
4. Collection: acquire data using validated methods, with documentation.
5. Examination and analysis: analyze verified working copies where feasible and preserve the master acquisition; reconstruct a timeline and identify indicators. Live collection necessarily interacts with the source, so document its effects.
6. Reporting and presentation: factual, reproducible, neutral report; expert testimony if needed.
7. Review and improvement: lessons learned.

1.3 Evidence

Evidence types:

Admissibility depends on the applicable jurisdiction and proceeding. Relevance, authenticity, reliable handling, and lawful collection matter, but no checklist guarantees admission. Law-enforcement search authority can arise from a warrant or a recognized exception; private workplace collection has different limits. Ask counsel to confirm authority and scope. The evidence-type labels above, including hearsay exceptions, are teaching examples rather than universal rules.

Best evidence rule: rules concerning proof of a record's contents vary. For example, U.S. Federal Rule of Evidence 1003 generally permits duplicates unless authenticity is genuinely disputed or admission would be unfair. Matching hashes support integrity; they do not alone establish lawful collection, authorship, or admissibility.

1.4 Chain of custody and integrity

Chain of custody records who handled evidence, when, where, why, and how it was stored, from collection to presentation. Gaps allow challenge. Typical practices:

• Label and photograph evidence, record serial numbers.
• Use tamper-evident bags and locked storage with access logs.
• Compute approved cryptographic hashes, such as SHA-256, for acquired images and verify working copies against the recorded master hash. Preserve the hash records separately; a hash stored beside mutable evidence can be replaced too.
• Use validated write blockers for supported offline media acquisition. A write blocker does not prevent changes caused by collecting RAM on a running machine; document live-acquisition tools and side effects.
• Document every action in contemporaneous notes.

1.5 Order of volatility

Collect the most volatile relevant data first where practicable. This traditional example order, described in RFC 3227, must be adapted to the system:

1. CPU registers and cache
2. Memory (RAM), running processes, network connections, routing tables, ARP cache
3. Temporary file systems (swap or page-file persistence depends on the platform)
4. Disk (files, logs, deleted files)
5. Remote logs and monitoring data
6. Physical configuration and network topology
7. Archival media and backups

A common exam trap: pulling the plug loses volatile memory, potentially including keys, malware, and connections. Capture memory before shutdown when justified and safe. Cloud logs with short retention or expiring container storage may need parallel preservation; the list is not a rule to postpone every remote source.

1.6 Digital forensics techniques

• Imaging: bit-for-bit copy (forensic image), not just a file copy.
• Live acquisition for memory and active systems versus dead acquisition for powered-off media.
• Timeline analysis correlating file system times, logs, and network records.
• Network forensics: packet captures and flow records; media analysis: recovering deleted data and slack space; software forensics: analyzing malware or code; embedded and mobile device forensics: specific tools.
• Anti-forensics (encryption, wiping, timestamp manipulation) may require specialized skills.
• Cloud forensics is limited by shared responsibility: rely on provider logs, snapshots, and contractual access. Plan evidence access before an incident.

1.7 Electronic discovery (eDiscovery)

In civil litigation, parties must identify, preserve, collect, process, review, and produce electronically stored information (ESI) relevant to the case. A legal hold suspends normal deletion of relevant data. Destroying data after a hold applies (spoliation) can lead to severe penalties. Good data classification, retention schedules, and an up-to-date data map make eDiscovery cheaper and more accurate.

1.8 Worked example: handling a suspected insider theft

Scenario. Ardent Engineering suspects that a departing engineer copied proprietary designs to a personal cloud account. The security manager proposes to log into the engineer's laptop, browse through files, and then wipe it for reuse.

Reasoning, step by step.

1. Contact legal counsel and HR first. They confirm authority to inspect company assets under policy and any employee-privacy laws that apply, and decide on a legal hold.
2. Preserve: if the laptop is running and safe to retain, isolate it under the response plan and have a trained examiner capture volatile data. Do not power on an already-off device just to follow this example. Arrange offline imaging with a validated write blocker where supported, preserving the master image and acquisition hashes.
3. Start the chain of custody form. Store the original in a secure locker.
4. Analyze only the copy: browser history, cloud sync client logs, USB device history, and DLP and proxy logs. Build a timeline.
5. Report facts and avoid conclusions about intent. If the evidence points to a crime, counsel decides whether to involve law enforcement.
6. Reuse only after counsel releases the hold and all other investigation, retention, and sanitization requirements have been satisfied.

Why not the manager's plan? Browsing the live system alters timestamps and may overwrite evidence, wiping destroys the only original, and acting without counsel risks legal and privacy exposure.

2. Conducting logging and monitoring activities

2.1 Why log

Logs support detection, investigation, accountability, compliance, and capacity planning. They are only useful if they are complete, accurate, protected, and actually reviewed.

2.2 What to log

Logs should record who, what, when, where, and from where, with synchronized trusted time and explicit time-zone or UTC information. Record source time and collection time where possible, and monitor clock drift and ingestion gaps.

2.3 Protecting logs

• Send logs in near real time to a central log server with write-once or append-only controls, to reduce the ability of a source-system attacker or administrator to erase collected records. This cannot recover events suppressed or falsified before forwarding.
• Restrict access; separate duties between those who administer systems and those who manage logs.
• Protect transport, collector access, and storage integrity. Hashes support change detection only if the reference values are protected; signing and immutable storage strengthen evidence when correctly managed. Protect confidentiality because logs may contain sensitive data.
• Define retention according to applicable law, contracts, and investigative need; suspend relevant deletion for a legal hold. Test storage capacity and deletion rules.
• Avoid logging secrets such as passwords or full card numbers.

2.4 Security information and event management (SIEM)

A SIEM collects, normalizes, correlates, and alerts on log data, with dashboards and retention for compliance. Capabilities and challenges:

• Correlation rules link events (for example, a failed login series followed by a success from a new country, then a bulk download).
• Tuning: untuned systems create alert fatigue. Tune rules to reduce false positives and gaps.
• Use cases: map detections to threats, such as ATT&CK techniques, and review coverage regularly.
• Scale and cost: decide what to ingest and for how long.

Security orchestration, automation, and response (SOAR) automates repetitive actions through playbooks: enrich an alert, query threat intelligence, isolate a host, open a ticket. Keep human approval for high-impact actions.

User and entity behavior analytics (UEBA) builds baselines of normal behavior and flags deviations such as impossible travel or unusual data access volumes.

2.5 Continuous monitoring

Continuous monitoring provides ongoing awareness of vulnerabilities, threats, and control status (NIST SP 800-137). Examples: network traffic analysis, endpoint detection and response (EDR), and cloud posture monitoring.

2.6 Egress monitoring and data loss prevention

Egress monitoring inspects traffic leaving the organization to detect exfiltration, command-and-control, and policy violations. Techniques include DLP (content inspection and fingerprinting of sensitive data), proxy and DNS monitoring, and watermarking/tagging. Steganography and encrypted channels can hide exfiltration, so combine content controls with behavior and volume analysis.

2.7 Log management and the audit trail

Distinguish logging (record events), monitoring (watching in real time for threats), and auditing (examining records against criteria). A protected audit trail supports event reconstruction and accountability; logs alone do not guarantee nonrepudiation or identify the person behind a stolen account. Sampling and alert thresholds reduce processing noise, but preserve security-relevant raw events according to policy: a threshold of three failed logins should not silently discard the first two.

2.8 Threat intelligence and threat hunting

• Threat intelligence is analyzed information about adversaries and threats: strategic (trends for leaders), operational (campaigns), tactical (TTPs), and technical (indicators of compromise such as hashes, IPs, domains). Sources include information sharing and analysis centers (ISACs), vendors, government, and open sources. Use standards such as STIX and TAXII to exchange it.
• Threat hunting is a proactive, hypothesis-driven search for threats that automated tools have missed, for example "an attacker abusing remote management tools would create unusual parent-child process patterns". Hunts produce new detections.
• Indicators of compromise (IoCs) are artifacts of an incident; indicators of attack (IoAs) focus on behaviors and intent, which survive changes of tools.

2.9 Worked example: investigating an alert chain

Scenario. At Orion Retail, the SIEM raises three low-priority alerts within two hours: (1) a user account failed to log in 12 times from a foreign IP; (2) the same account then logged in successfully; (3) the account queried 40,000 customer records, ten times its daily average. Analysts have been closing similar alerts one by one as noise.

Reasoning.

1. Individually, each alert is inconclusive; together they justify urgent investigation of possible account compromise and data collection. Failed logins alone do not prove credential stuffing or identify an attacker.
2. Correlation across the sequence raises confidence and severity.
3. UEBA shows that the data volume is a deviation from the user's baseline.
4. Escalate as a suspected incident under the response plan: preserve logs, contain account access as appropriate, revoke sessions and tokens, check egress for exfiltration, and notify designated responders. A password reset alone may leave issued sessions usable.
5. Improvement: write a correlation rule for this sequence and require MFA for external logins.

Why not close the alerts? Handling alerts in isolation hides the pattern. Tuning is a good practice, but it must not remove detections of sequences with high impact.

3. Performing configuration management

3.1 Why configuration management matters

Unmanaged changes create vulnerabilities and outages. Configuration management (CM) establishes and maintains the integrity of systems by controlling their configuration through the lifecycle.

3.2 Core elements

3.3 Provisioning and automation

• Infrastructure as code (IaC) defines environments in version-controlled files; reviews, tests, and pipelines apply them consistently. Scan templates for misconfigurations before deployment.
• Immutable infrastructure: replace systems rather than patching in place, reducing drift.
• Configuration drift is detected by comparing the current state with the baseline, then either corrected automatically or investigated as a possible compromise.
• Secure baselines disable unneeded services, apply least functionality, set secure defaults, and remove default credentials.

3.4 Roles

A configuration manager keeps records; a change advisory board (CAB) reviews changes; system owners approve deployment; security validates baselines. Separation of duties prevents one person from altering production configuration without review.

3.5 Worked example: drift in a web server farm

Scenario. Kestrel Media runs 60 web servers from a hardened image. A scan finds that eleven servers have an extra open management port and an old TLS version enabled. Administrators say they changed them "temporarily during an outage."

Reasoning.

1. This is configuration drift caused by unmanaged changes.
2. Compare each server with the approved baseline; determine whether the changes were authorized or are signs of compromise.
3. Restore the baseline (redeploy from the image or run the configuration management tool in enforcement mode).
4. Ensure emergency changes are documented afterwards through an emergency change process.
5. Add continuous drift detection and alerting, and reduce direct administrative access in favor of pipeline-based deployment.

Why not simply close the ports manually? It fixes the symptom on eleven machines, but without baseline enforcement and monitoring, the drift will return, and manual work may miss other deviations.

4. Applying foundational security operations concepts

4.1 Core principles

4.2 Information lifecycle in operations

Operations implement the data lifecycle, retention, and security controls across creation, use, storage, sharing, archiving, and destruction. Operational controls include secure transfer, encrypted storage, access reviews, and verified sanitization.

4.3 Monitoring privileged use

Administrators must be accountable. Require individual accounts, log all privileged commands, review sessions for high-risk systems, and separate monitoring staff from those being monitored.

4.4 Worked example: preventing single-person fraud

Scenario. At Maple Credit Union, one operations analyst can create new payees, approve payment batches, and reconcile bank statements. An audit asks how to reduce fraud risk without hiring many new staff.

Reasoning.

1. The analyst controls the entire payment process, so there is no check.
2. Introduce separation of duties: one person creates payees, another approves batches, a third reconciles.
3. Add dual control for payments above a threshold.
4. Use job rotation and mandatory vacation to expose irregularities during absences.
5. Log and review payee changes (detective control).

Solution: layered preventive and detective controls matched to the risk, using existing staff in different roles.

5. Applying resource protection

5.1 Media management

Media includes disks, tapes, USB drives, paper, and cloud storage. Controls cover marking according to classification, access control, secure storage, tracking, transport protection, and sanitization at end of life (clear, purge, or destroy under NIST SP 800-88 Rev. 2, final September 2025). Cryptographic erase is a technique that may achieve purge when its prerequisites are met, not a fourth method.

5.2 Media protection techniques

• Encrypt portable media and backups; protect keys separately.
• Keep a library or inventory of removable media with check-in/check-out records.
• Protect backups with the same classification rules as the original data; store copies off-site or in a separate logical domain.
• Control mobile devices and removable media with technical restrictions (disable USB ports where justified).

5.3 Asset protection and secure provisioning

Resource protection also covers the provisioning of hardware, software, services, and cloud resources: authorized request, secure baseline, inventory registration, ownership assignment, and decommissioning with data removal. In cloud environments, apply the shared responsibility model: the customer protects data, identities, and configuration even though the provider secures the infrastructure.

5.4 Worked example: retiring a fleet of laptops

Scenario. Brightwater Legal retires 300 laptops that held client documents. Some use full-disk encryption, others do not. An employee proposes to donate them to a school after deleting the files.

Reasoning.

1. Deleting files only removes pointers; data remains recoverable.
2. Choose clear, purge, or destroy from the classification, intended reuse, device capabilities, and approved policy. Cryptographic erase may achieve purge only if suitable encryption covered the target data and all necessary keys and recoverable copies can be sanitized. Encryption enabled late or surviving recovery keys can defeat that assumption. For other drives, use an approved device-appropriate technique or destroy them if effective sanitization cannot be assured.
3. Document the sanitization (certificate of destruction or verification record) and update the asset inventory.
4. Because the data are client confidential, follow the classification-based policy and contract obligations.

Solution: apply NIST SP 800-88 Rev. 2: verify the operation completed, validate that the result is adequate for the data and disposition, and record the decision before approved donation. This distinguishes tool success from an acceptable sanitization outcome.

6. Mini case study

Scenario. Helios Energy detects that a contractor's account was used to copy engineering files at 3 a.m. The responding administrator immediately powers off the server and wipes it to "clean the infection," then asks HR to dismiss the contractor. Later, the contractor claims innocence, and the company cannot prove who used the account. In the review it is found that logs are stored only on the same server, clocks differ by 11 minutes across systems, the contractor account had administrator rights, and there is no baseline for the server.

Task. Identify the failures and propose improvements.

Commented solution.

1. Evidence destruction: powering off lost volatile data and wiping destroyed the original. Prepare a forensic readiness procedure: capture volatile data where safe, preserve images and logs, and involve legal counsel before disciplinary action.
2. Log protection: logs on the same server could be altered or lost. Forward them to a central, protected log platform with limited access.
3. Time synchronization: an unaccounted-for 11-minute offset can mislead a timeline. Preserve original timestamps and recorded offsets, correlate with independent sources, and maintain trusted time synchronization.
4. Least privilege and accountability: contractor administrator rights and the possibility of account sharing prevented attribution. Remove excess rights, use MFA and individual accounts, and monitor privileged sessions.
5. Configuration management: without a baseline, nobody could tell what had changed. Create baselines and drift detection.
6. Process: do not take disciplinary action before facts are established through a defensible investigation.

7. Common pitfalls and exam tips

• Exam tip: protect people and critical operations, preserve evidence, and confirm authority with counsel. Analyze working copies where feasible and document unavoidable live-system changes.
• Exam tip: order of volatility starts with memory and running processes, and ends with archival media.
• Pitfall: treating a hash as optional. Hashes demonstrate integrity of copies and strengthen chain of custody.
• Exam tip: many U.S. civil claims use preponderance of the evidence; U.S. criminal convictions require proof beyond a reasonable doubt. Check the jurisdiction and proceeding.
• Exam tip: logs must be centralized, protected from the systems they describe, time-synchronized, and retained as required.
• Pitfall: deploying a SIEM and not tuning or staffing it. A tool without people and use cases generates noise.
• Exam tip: configuration baselines plus drift detection plus change control form the CM answer.
• Exam tip: two-person control, split knowledge, and separation of duties make fraud harder (collusion is then required); job rotation and mandatory vacations detect it.
• Exam tip: the sanitization methods are clear, purge, and destroy. Cryptographic erase is a technique whose suitability depends on encryption and key-sanitization prerequisites.
• Pitfall: assuming deletion or formatting sanitizes media.

Key terms

• Chain of custody: documented history of evidence handling.
• Order of volatility: sequence for collecting evidence from the most to the least volatile.
• Legal hold / eDiscovery: preservation and production of relevant electronic data in litigation.
• SIEM / SOAR / UEBA: log correlation, automated response, and behavior analytics.
• Threat hunting / IoC / IoA: proactive search for threats, indicators of compromise, and indicators of attack.
• Baseline / drift: approved configuration and deviation from it.
• CMDB: configuration management database.
• IaC: infrastructure as code.
• Dual control / split knowledge: multiple authorized people must participate; no single custodian has sufficient secret information.
• Sanitization: rendering access to target data infeasible through clear, purge, or destroy methods.

Validate the effectiveness of these operational controls through security assessments, testing, and audits.

Summary checklist

• I can match investigation types to standards of proof and involve legal counsel at the right time.
• I can explain admissible evidence, chain of custody, hashing, and write blockers.
• I can apply the order of volatility to a live compromised system.
• I can design protected, centralized, time-synchronized logging.
• I can explain SIEM, SOAR, UEBA, egress monitoring, and threat hunting.
• I can describe baselines, inventories, IaC, and drift detection.
• I can apply separation of duties, dual control, split knowledge, and job rotation.
• I can choose a media sanitization method based on classification and media type.

Official sources

• ISC2 CISSP exam outline: https://www.isc2.org/certifications/cissp/cissp-certification-exam-outline (opens in a new tab)
• NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response: https://csrc.nist.gov/pubs/sp/800/86/final (opens in a new tab)
• NIST SP 800-92, Guide to Computer Security Log Management: https://csrc.nist.gov/pubs/sp/800/92/final (opens in a new tab)
• NIST SP 800-128, Guide for Security-Focused Configuration Management: https://csrc.nist.gov/pubs/sp/800/128/final (opens in a new tab)
• NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization: https://csrc.nist.gov/pubs/sp/800/88/r2/final (opens in a new tab)
• NIST log management project (Revision 1 status): https://csrc.nist.gov/projects/log-management (opens in a new tab)
• IETF RFC 3227, evidence collection and archiving: https://www.rfc-editor.org/rfc/rfc3227.html (opens in a new tab)
• U.S. Courts, proof standards illustrated: https://www.uscourts.gov/court-programs/jury-service/types-juries (opens in a new tab)
• U.S. Federal Rule of Evidence 1003, duplicates: https://uscode.house.gov/view.xhtml?edition=prelim&num=0&req=granuleid%3AUSC-prelim-title28a-node232-article10-rule1003 (opens in a new tab)
• CIS Benchmarks: https://www.cisecurity.org/cis-benchmarks (opens in a new tab)