CISSP Incident Response: Detection, Patching, and Change Management

Introduction

CISSP incident response connects detection, containment, vulnerability management, and controlled change. This lesson continues Domain 7, Security Operations (13% of the exam, ISC2 exam outline effective 15 April 2024). It covers tasks 7.6 to 7.9: conduct incident management, operate and maintain detective and preventative measures, implement and support patch and vulnerability management, and understand and participate in change management processes. Build on investigations, logging, and configuration management and then connect response decisions to disaster recovery and business continuity.

Incident management is where the whole security program is tested under pressure. Detective and preventive tools decide how early you find out. Patching decides how many doors are open. Change management decides whether your own fixes break the business. A strong candidate sees these four topics as one loop: prevent, detect, respond, improve, with change control keeping every step safe and traceable.

Learning objectives

After this lesson you can:

1. Order the incident response phases and state what happens in each, including who decides and who communicates.
2. Distinguish an event from an incident, and triage by impact and urgency.
3. Select and place firewalls, IDS/IPS, sandboxes, honeypots, and anti-malware tools, and explain their limits.
4. Explain how machine-learning based detection helps and where it fails.
5. Run a vulnerability and patch management cycle with risk-based prioritization and emergency handling.
6. Apply change management: request, assessment, approval, testing, implementation, rollback, and review.
7. Choose between allowlists and denylists, and manage externally provided security services (MDR, SOC as a service, threat feeds).

1. Incident management

1.1 Event, alert, and incident

• An event is any observable occurrence in a system or network (a login, a firewall drop, a file change).
• An alert is a notification that something matched a detection rule.
• An incident is an event, or set of events, that actually or potentially violates security policy or threatens confidentiality, integrity, or availability.

Most events are noise; some alerts are false positives; a few become incidents. The skill the exam tests is triage: decide quickly, with evidence, what deserves the incident process.

1.2 The phases on the exam

The ISC2 outline lists the incident management activities: detection, response, mitigation, reporting, recovery, remediation, and lessons learned. Preparation is a prerequisite that makes all of them possible. This is an outline of topics, not a universally required chronological workflow. Activities overlap and repeat: reporting starts as required, containment can be immediate, and root causes must be addressed before restored assets return to production. Choose the next action from the scenario, the response plan, and the need to protect people and services.

NIST update worth knowing. In April 2025 NIST published SP 800-61 Revision 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, which supersedes Revision 2. Instead of a stand-alone four-phase lifecycle (preparation; detection and analysis; containment, eradication and recovery; post-incident activity), it maps incident response onto the six CSF 2.0 functions: Govern, Identify, and Protect cover preparation and improvement, while Detect, Respond, and Recover cover the incident itself. For the CISSP, understand each activity in the ISC2 list and recognize that the sequence depends on the situation. NIST treats incident response as part of overall risk management.

1.3 Containment, eradication, and recovery in practice

Containment limits impact. The right choice depends on the business: pulling a production database server offline stops the attacker but also stops revenue. Factors include the value of the asset, the need to preserve evidence, how long containment will take, and whether the attacker will notice and react. Short-term containment (network isolation, disabling an account) buys time; long-term containment (temporary clean systems, tightened segmentation) keeps operations running while you rebuild.

Eradication/remediation removes the root cause and the attacker's footholds: malware, backdoors, rogue accounts, scheduled tasks, stolen credentials. Rotating credentials and keys is part of it. If you cannot prove a system is clean, rebuild from a trusted image.

Recovery restores service from known-good sources, then validates integrity and monitors for reinfection. Restoring a backup taken after the compromise only reinstalls the problem, so validate restoration assets for compromise and corruption before use. An older copy is not automatically clean; determine an appropriate recovery point from available evidence and reconcile legitimate transactions where necessary.

1.4 Roles and communication

• The incident response team (CSIRT/CIRT) includes security analysts, IT operations, legal, HR, communications, and an executive sponsor. Authority to take systems offline must be decided before the incident.
• Communication follows the plan: only designated spokespeople talk to the press or customers. Use out-of-band channels if the attacker may be reading email.
• Legal and regulatory reporting can be tightly timed. Examples include GDPR controller notification to the supervisory authority without undue delay and, where feasible, within 72 hours of awareness unless the breach is unlikely to risk people’s rights and freedoms; processors notify the controller without undue delay. Covered U.S. domestic public issuers generally file material incidents under Form 8-K Item 1.05 within four business days of determining materiality, subject to applicable exceptions or authorized delays. Other regimes, such as HIPAA, have their own triggers. The exam expects you to involve legal counsel and follow the legal obligations, not to recite every deadline.
• Chain of custody and evidence handling from the previous lesson apply during the response: document every action and preserve evidence before it is destroyed.

1.5 Worked example: ransomware at a regional hospital group

Scenario. At 02:10 a SIEM alert fires: 300 file servers show mass file renames and a ransom note. The hospital group has 12 sites, a tested incident response plan, immutable offline backups taken nightly, and a cyber insurance policy that requires notifying the insurer promptly.

Step by step.

1. Detection and triage. Confirm the alert is real (file hashes changing, note present). Classify as severity 1 because patient care systems are affected. Open an incident record with timestamps.
2. Response. Activate the CIRT per plan. Notify the incident commander, legal counsel, and the insurer's breach hotline. Start a separate out-of-band chat because email may be compromised.
3. Mitigation. Isolate the affected network segments at the switch and firewall. Disable the compromised service account that spread the malware. Preserve available evidence, including representative memory captures and EDR logs, when safe. If network isolation is impossible and harm continues, the incident commander may need to authorize shutdown, recording the loss of volatile evidence. Patient safety and effective containment take priority.
4. Reporting. Legal assesses regulatory duties: patient data may have been exfiltrated (double extortion), so the privacy office and counsel prepare breach notifications; law enforcement is contacted.
5. Eradication and remediation. Investigation identifies an unpatched internet-facing VPN appliance and reused domain administrator credentials. Remove persistence, patch the entry point, revoke compromised credentials and sessions, and restrict administrative access before reconnecting rebuilt assets.
6. Recovery. Rebuild from trusted images and restore from validated backups selected using the investigation timeline. Check for compromise and data corruption, test functionality, reconcile affected transactions, and maintain heightened monitoring. Reporting continues in parallel.
7. Lessons learned. Review timeline, update runbooks (the on-call roster was out of date), set risk-based backup retest intervals, and present metrics (time to detect, contain, recover) to the board.

2. Detective and preventative measures

2.1 Preventive versus detective

A preventive control stops an event (firewall rule, MFA, patch). A detective control identifies it (IDS, SIEM alert, log review). A layered design uses both because no preventive control is perfect, which is the reason detection exists.

2.2 Firewalls

Good rules: default deny, rules ordered according to the product’s evaluation semantics (often first match), with explicit exceptions and denies reviewed, documented business justification, regular rule review to remove stale entries. Place a firewall at network boundaries and between internal zones. A DMZ (screened subnet) holds public-facing servers so that a compromise does not give direct access to the internal network.

Egress filtering blocks outbound traffic that is not required, limiting data exfiltration and command-and-control. Ingress filtering drops inbound packets with spoofed internal source addresses.

2.3 IDS and IPS

• IDS (intrusion detection system) monitors and alerts; it is passive and usually receives a copy of traffic (SPAN port or network tap).
• IPS (intrusion prevention system) sits inline and can block traffic; it is active. If it fails closed it blocks traffic, if it fails open it passes traffic, so the choice matters for availability.
• Network-based (NIDS/NIPS) sees traffic on a segment; host-based (HIDS/HIPS) sees activity on one system, including encrypted traffic after decryption and local file or registry changes.

Detection methods:

Terms: false positive (alert on harmless activity), false negative (missed real attack), true positive, true negative. Tuning reduces false positives, but over-tuning raises false negatives. Encrypted traffic is a blind spot unless TLS inspection or endpoint visibility is added.

2.4 Sandboxing

A sandbox executes untrusted files or links in an isolated environment and observes behavior (network calls, file writes, process creation) before delivering them to users. It is common in email security and web gateways. Limits: malware may detect virtual environments and stay dormant, wait for user interaction, or use delayed execution. Sandboxing complements, but does not replace, signatures and endpoint controls.

2.5 Honeypots, honeynets, and deception

A honeypot is a decoy system that has no legitimate production use, so any interaction is suspicious. A honeynet is a network of honeypots. Honeytokens are fake credentials, records, or files that trigger an alert when used. Benefits: early warning, attacker technique collection, low false positives. Risks: a poorly isolated honeypot becomes a pivot point into production. Deception deployments need authorized scope, isolation, privacy review, and counsel’s guidance. Do not assume that “enticement” makes a deployment lawful; entrapment is a jurisdiction-dependent legal doctrine rather than a technical property of a honeypot.

2.6 Anti-malware and endpoint tools

• Signature-based antivirus detects known samples.
• Heuristic and behavioral analysis looks for suspicious actions such as encrypting many files quickly.
• EDR (endpoint detection and response) records endpoint telemetry, supports hunting, and lets analysts isolate hosts remotely. XDR correlates telemetry across endpoint, network, email, and cloud. MDR is a managed detection and response service that may use EDR, XDR, SIEM, and other telemetry; its scope and response authority are contractual.
• Application allowlisting, host firewalls, disk encryption, and device control (blocking unknown USB storage) are preventive layers.

2.7 Machine learning and AI-based detection

Machine-learning tools classify files or behavior, flag anomalies in user and network activity (UEBA), and prioritize alerts. Strengths: they scale, can notice patterns humans miss, and can detect never-seen variants. Weaknesses to know for the exam:

• False positives and drift: models trained on old behavior become inaccurate when the business changes.
• Training data quality and poisoning: an attacker who influences the training data can teach the model to ignore malicious behavior.
• Evasion: attackers craft inputs that models misclassify (adversarial examples).
• Explainability: analysts need to understand why an alert fired so they can verify and justify actions.
• Privacy and bias: monitoring user behavior must follow policy and law.

Treat ML output as one input to human decision-making, with validation, tuning, and metrics.

2.8 Worked example: choosing controls for a retailer's web store

Scenario. An online retailer runs a legacy shopping cart application with a known SQL injection flaw. The vendor patch will take six weeks to certify. The SIEM shows probing from many IP addresses. The security manager wants fast risk reduction without taking the store offline.

Solution.

1. Deploy a WAF in front of the application with rules for SQL injection and rate limiting (virtual patching), starting in detect mode and moving to block after tuning.
2. Restrict the database account used by the application to least privilege and block outbound database traffic to the internet (egress filtering) to reduce some out-of-band exfiltration paths. Injection may still return data through the application response or use allowed channels; these controls do not fix the query flaw.
3. Enable detailed application and database logging forwarded to the SIEM, with alerts for unusual query errors.
4. Plan the vendor patch through change management, with testing in staging.

Why other choices are weaker. A network packet filter cannot understand SQL injection payloads in HTTP bodies. An IDS alone only detects. Temporary isolation or disabling the vulnerable function may be necessary if compensating controls cannot reduce the risk sufficiently. Antivirus is not a reliable fix for SQL injection.

3. Patch and vulnerability management

3.1 The cycle

1. Discover assets (you cannot patch what you do not know about; use the inventory and CMDB).
2. Scan for vulnerabilities (authenticated scans give more accurate results than unauthenticated ones).
3. Prioritize by risk: severity score, exploitability, asset value, exposure, and compensating controls.
4. Test patches in a representative environment.
5. Deploy according to change management, in rings (pilot, then broad).
6. Verify with a rescan and record exceptions.
7. Report metrics and repeat continuously.

3.2 Prioritization

• CVE identifies a publicly disclosed vulnerability. CVSS scores severity from 0.0 to 10.0 (Critical is 9.0 to 10.0). CVSS alone is not risk; combine it with known exploited status (for example the CISA Known Exploited Vulnerabilities catalog), EPSS exploit probability, asset criticality, and exposure (internet-facing or internal).
• Zero-day vulnerability: a flaw unknown to, or not yet addressed by, the responsible vendor when discovered or exploited. An unpatched known vulnerability is not automatically a zero-day. When no patch is available, use compensating controls: virtual patching (IPS/WAF), disabling the vulnerable feature, network segmentation, increased monitoring.
• Emergency patching follows an expedited change path with after-the-fact review, not a skipped process.

3.3 Practical considerations

Patch every layer: operating systems, applications, firmware, libraries, network devices, and container images (rebuild images instead of patching running containers). Unsupported systems may no longer receive vendor security fixes; confirm available support, apply justified mitigations, and plan replacement rather than assuming ongoing patch availability. OT systems need vendor approval and maintenance windows. Always test and keep a rollback plan.

3.4 Worked example: prioritizing a patch backlog

Scenario. A weekly scan reports 4,200 findings. The team can patch roughly 200 items per week. Three examples: (a) CVSS 9.8 remote code execution on an internal print server, no known exploitation, no sensitive data; (b) CVSS 7.5 on an internet-facing VPN gateway, listed as actively exploited; (c) CVSS 5.3 information disclosure on a development server.

Reasoning.

1. Item (b) is first: internet-facing, actively exploited, and the gateway is an entry point for the whole network. Use emergency change handling.
2. Item (a) still needs urgent assessment: internal placement does not prove low exposure or value. Check internal reachability, privileged accounts, lateral movement, and available segmentation before choosing its patch deadline.
3. Item (c) goes to routine cycle, or is accepted with approval if the server is going to be decommissioned.

Why not sort strictly by CVSS? It ignores exposure and exploitation. A pure CVSS sort would put (a) first and leave the actively exploited gateway exposed.

4. Change management

4.1 Purpose

Change management makes changes deliberate, approved, tested, and documented, with a recovery path. Its security purpose is to prevent unauthorized changes and to prevent well-meant changes from causing outages or introducing vulnerabilities. It supports availability and integrity.

4.2 The process

1. Request (a change request records what, why, who, when, and impact).
2. Impact and risk assessment, including security review and dependencies.
3. Approval by a change advisory board (CAB) or delegated authority, according to change type.
4. Testing in a non-production environment.
5. Scheduling with communication to stakeholders.
6. Implementation by authorized people following documented steps.
7. Verification and monitoring after the change.
8. Rollback if the change fails, using a prepared back-out plan.
9. Documentation and closure, including updating configuration records and baselines.

4.3 Change types

4.4 Security considerations

• Separate duties: the person who requests a change should not be the only one who approves and implements it.
• Link changes to configuration management: after an approved change, update relevant configuration records and approved baselines. Investigate unexpected drift rather than redefining the baseline to match any observed state.
• Include security testing and, for software, code review and pipeline controls.
• Log all changes for audit and incident reconstruction (an incident often begins with "what changed recently?").
• In DevOps, changes flow through pipelines with automated tests and approvals; the principle (traceable, tested, approved, with recovery planned) remains the same.

4.5 Emergency change

When an active exploit forces a firewall change on Saturday night, use the emergency change path: on-call approval, minimal change, recorded rule and rollback, then retrospective CAB review. Waiting for Tuesday leaves the exploit running; changing without a record breaks traceability and creates drift.

5. Allowlists, denylists, and externally provided security services

5.1 Allowlists and denylists

Use allowlisting on high-value, stable systems (servers, kiosks, industrial controllers). Use denylisting where flexibility matters, but combine with other controls. Keep lists reviewed and automate updates through trusted sources. Allowlisting is typically implemented by publisher certificate, path, or file hash, according to the needed granularity. A hash identifies a specific binary, while a publisher rule may allow many versions or products; restrict publisher scope and protect writable paths. Signed or allowlisted software can still be vulnerable or malicious.

5.2 Third-party and externally provided security services

Organizations buy detection and response (MDR), SOC as a service, managed firewalls, threat intelligence feeds, DDoS scrubbing, email security gateways, penetration testing, and incident response retainers. Security responsibilities remain with the organization even when operations are outsourced (accountability cannot be outsourced). Manage them with:

• Clear service level agreements (alert response times, escalation, reporting) and right to audit or independent assurance reports (SOC 2).
• Data protection: what logs and data the provider sees, where they are stored, and breach notification duties.
• Integration and access control: least privilege for the provider's accounts, MFA, monitoring of provider activity.
• Exit planning: ability to retrieve data and transition providers.
• Defined responsibilities (a shared responsibility matrix) so gaps do not appear between internal staff and the provider.

6. Pitfalls and exam tips

• Follow the response plan, protect people and critical services, and investigate and contain in parallel where needed. Preserve evidence when safe, involve counsel for legal obligations, and address root causes before reconnecting restored assets.
• IDS detects, IPS blocks (inline). Assess the impact of both: a missed attack is serious, while a false-positive block can also disrupt critical operations.
• A WAF protects web applications; a packet filter cannot read application payloads.
• Prioritize patches by risk (exploited, exposed, valuable), not CVSS alone. If no patch exists, use compensating controls and document risk acceptance.
• Emergency change is an expedited process with retrospective review, never no process. Prepare rollback before implementing.
• Accountability for security cannot be outsourced to an MSSP or MDR provider.

7. Mini case study: the missed alert and the unreviewed change

A logistics company closed an IDS alert (outbound connections from a warehouse server) as a false positive. Two weeks later ransomware hit. The server ran an exposed component with a known exploited flaw (CVSS 7.8, low-priority queue); a firewall port opened "temporarily" for a vendor had no change ticket; backups sat on a share that was also encrypted.

Commented solution.

1. Detection: the alert was closed without validation. A server that should not initiate outbound connections warranted correlation and escalation, which would have started the incident process.
2. Patching: prioritization used CVSS only. Known-exploited and reachable means emergency patch or isolation.
3. Change: the undocumented port bypassed review. Require tickets with expiry, periodic rule review, and drift detection.
4. Recovery: isolate, preserve evidence, rebuild from trusted images, restore from offline backups predating the intrusion, rotate credentials, meet legal reporting duties.
5. Improvements: alert validation criteria, exploited-vulnerability fast track, egress filtering for servers, isolated backups with restore tests.

Use security assessment and testing methods to verify detection coverage, patch effectiveness, and the evidence retained for change approvals.

Key terms

• Event / alert / incident: an observable occurrence / a rule notification / a policy-violating or threatening event.
• Containment, eradication (remediation), recovery: limit spread, remove the cause, restore service.
• CSIRT: computer security incident response team.
• NGFW / WAF: next-generation firewall / web application firewall.
• IDS / IPS: detect and alert / inline and block.
• False positive / false negative: harmless flagged / attack missed.
• Sandbox: isolated environment for analyzing untrusted code.
• Honeypot / honeytoken: decoy system / decoy credential or data.
• EDR / XDR / MDR: endpoint detection and response / extended / managed.
• CVE / CVSS / EPSS / KEV: vulnerability identifier / severity score / exploit probability / known exploited catalog.
• Virtual patching: blocking exploitation with WAF/IPS before a code patch.
• CAB: change advisory board.
• Rollback: back-out plan to restore the previous state.
• Allowlist / denylist: default deny / default allow with blocks.

Summary checklist

• I can explain the incident activities and choose a justified sequence, including remediation before restored assets return to production.
• I can triage events and decide when to involve legal counsel and regulators.
• I can choose between packet filter, stateful, proxy, NGFW, and WAF for a requirement.
• I can explain IDS versus IPS, signature versus anomaly detection, and false positives versus false negatives.
• I can explain sandboxes, honeypots, EDR/XDR/MDR, and the limits of machine-learning detection.
• I can run a risk-based patch cycle, including emergency patches and compensating controls.
• I can describe the change process, change types, and rollback.
• I can choose allowlisting or denylisting and manage outsourced security services with SLAs.

Official sources

• ISC2 CISSP exam outline: https://www.isc2.org/certifications/cissp/cissp-certification-exam-outline (opens in a new tab)
• NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r3.pdf (opens in a new tab)
• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning: https://csrc.nist.gov/pubs/sp/800/40/r4/final (opens in a new tab)
• NIST SP 800-94, Guide to Intrusion Detection and Prevention Systems: https://csrc.nist.gov/pubs/sp/800/94/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)
• CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (opens in a new tab)
• FIRST CVSS: https://www.first.org/cvss/ (opens in a new tab)
• Microsoft, application control rule conditions: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/applocker/understanding-the-publisher-rule-condition-in-applocker (opens in a new tab)
• European Commission, data breach notification: https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/obligations_en (opens in a new tab)
• SEC cybersecurity disclosure rule: https://www.sec.gov/files/rules/final/2023/33-11216.pdf (opens in a new tab)