When a vulnerability is being exploited before the vendor has a fix, the normal answer of "patch it" is not available, and every hour spent waiting is an hour the attacker may already be inside. This template gives [Organisation] a playbook for actively exploited vulnerabilities with no patch, or with a patch that arrived after exploitation began. It covers the decisions that matter in that window: how exposed you are, which vendor mitigations and compensating controls to apply, when to take a service offline, how to hunt for prior compromise, and which secrets to treat as burned. It is written for security operations, vulnerability management, infrastructure owners and the managers who approve service-affecting changes. Replace every [bracketed] placeholder before adoption.
How to use this template
- Use it for exploited flaws, not every CVE: routine remediation belongs in the Patch Management Policy Template. This playbook starts when there is credible evidence of exploitation in the wild.
- Assume compromise until hunted: on internet-facing products, exploitation often predates disclosure. Ivanti Connect Secure (CVE-2023-46805, CVE-2024-21887) was exploited from early December 2023, before disclosure on 10 January 2024, and CitrixBleed (CVE-2023-4966) from late August 2023, before disclosure in October.
- Use public directives as a benchmark: CISA emergency directives for federal agencies are a useful, public example of what "urgent" looks like, even if [Organisation] is not bound by them.
- Keep a decision log: every choice to leave a vulnerable service running is a recorded risk acceptance by a named senior owner, as the NCSC vulnerability management guidance recommends.
- Owner and review: [Head of Security Operations], reviewed every [12] months and after each activation.
1. Scope and triggers
1.1 This playbook covers vulnerabilities in software, appliances and services used by [Organisation] where exploitation is confirmed or highly likely and no complete fix is available or applied. It applies to on-premises products, edge devices (VPN, firewalls, load balancers, file transfer), and SaaS where the provider has disclosed exploitation.
1.2 Triggers:
- Vendor advisory: states exploitation in the wild, or "limited targeted attacks", for a product [Organisation] runs.
- KEV entry: a product you run is added to the CISA Known Exploited Vulnerabilities catalogue. Inclusion requires a CVE ID, reliable evidence of active exploitation and a clear remediation action, which CISA says may be a temporary workaround until a patch exists.
- Government action: a CISA emergency directive, NCSC alert or national CERT advisory.
- Internal detection: unexplained process, file or configuration change on an exposed system that does not match a known vulnerability (T1190 Exploit Public-Facing Application).
- Threat intelligence or peer report: credible sharing group report of exploitation against your sector.
2. Roles and contacts
| Role | Named owner | Responsibilities |
|---|---|---|
| Incident Lead | [SOC Manager] | Declares, runs the decision log, sets the update cadence |
| Vulnerability Lead | [Vulnerability Management Lead] | Exposure assessment, tracking vendor advisories and mitigation versions |
| Product Owner | [Owner of the affected platform] | Applies mitigations, judges service impact, runs rebuilds |
| Threat Hunt Lead | [Hunt Lead or retainer] | Compromise assessment, indicator searches, forensic capture |
| Identity and Secrets Lead | [IAM Lead] | Session revocation, credential, key and certificate rotation |
| Risk Owner | [CISO or delegated executive] | Approves taking services offline or accepting residual risk |
| Legal and Communications | [General Counsel, Head of Comms] | Regulator, customer and vendor communications |
2.1 Vendor contact sheet: for each critical product record the support portal, priority case process, account ID, the security advisory feed URL and the named technical account manager. Subscribe the Vulnerability Lead's shared mailbox to every feed.
3. Detection and triage
- Exposure assessment (target [4] hours): from the asset inventory and external attack surface scans, list every instance of the product, its exact version, whether the vulnerable component or feature is enabled, and whether it is reachable from the internet. Do not rely on the CMDB alone; check external scans and the vendor's own version checker where one exists.
- Rate the exposure:
| Rating | Condition | Default action |
|---|---|---|
| Critical | Vulnerable, internet-reachable, exploitation confirmed in the wild | Mitigate or disconnect within [24] hours; start the hunt now |
| High | Vulnerable, reachable only internally or by partners | Mitigate within [72] hours; restrict access paths |
| Medium | Vulnerable component present but disabled, or behind strong compensating controls | Verify the control, monitor, patch when available |
| Not exposed | Version not affected or product absent | Record the evidence and close |
3.3 Decision point A: mitigate in place or take offline? Take a Critical system offline when the vendor offers no mitigation, when the mitigation cannot be verified, or when the device holds credentials to Tier 0 systems. The Risk Owner decides; record the decision and its review time.
3.4 Evidence to preserve before mitigating: mitigations, integrity checks and reboots can overwrite traces. Capture device configuration exports, system and web logs, a memory or core dump where the vendor supports it, and a disk image for virtual appliances. In ED 25-03, CISA required agencies to collect core dumps from Cisco ASA devices and, if compromise was found, to disconnect the device without powering it off.
4. Containment
4.1 Apply the vendor mitigation exactly. Vendor mitigations can degrade features: in ED 24-01, CISA warned that the Ivanti mitigation XML could cause outages if imported incorrectly. Test on one device where you have more than one, then apply to the rest.
4.2 Compensating controls while no patch exists:
| Control | Use when | Limitation |
|---|---|---|
| Restrict the management or vulnerable interface to named source IPs | The flaw is in an admin portal or API | Does not help if the user-facing interface is vulnerable |
| Disable the vulnerable feature or module | The vendor confirms the feature is the attack path | Business impact; confirm it is really disabled |
| WAF or IPS rule from the vendor or provider | Exploit traffic is distinguishable at layer 7 | Easy to bypass with variants; treat as a speed bump |
| Move users to an alternative access path | A second VPN, ZTNA or a different product is available | Capacity and support load |
| Disconnect from the network | No mitigation exists or compromise is likely | Service outage; Risk Owner approval |
4.3 Segment the device so that, if already compromised, it cannot reach domain controllers, vaults or management networks beyond what it needs (T1210 Exploitation of Remote Services follows quickly after edge compromise).
4.4 Decision point B: if the hunt in section 5 finds compromise, stop treating this as a vulnerability and run the Incident Response Plan Template with the hunt findings as the starting scope.
5. Eradication
5.1 Hunt for prior compromise back to at least [30] days before the earliest exploitation date the vendor or government partners report. Look for web shells and modified files (T1505.003), new admin accounts, configuration changes, unexpected outbound connections from the device, logins from the device's IP into internal systems, and use of credentials stored on it (T1078). Vendor integrity tools help but are not sufficient: the NHI Mgmt Group analysis of the Ivanti Connect Secure exploitation notes CISA found the integrity checker missed compromise and that persistence could survive a factory reset. See the Threat Hunting Guide.
5.2 Rebuild compromised devices: following the ED 24-01 pattern, export configuration, factory reset or redeploy, upgrade to a fixed version once available, re-import only reviewed configuration, and remove temporary mitigations as the vendor directs.
5.3 Rotate every secret the device held or saw. Treat them as burned, whether or not the hunt finds proof of theft. The same applies to supply chain attacks, as in the Bitwarden CLI npm compromise, where an install-time stealer took CI tokens, SSH keys and cloud secrets:
| Secret | Action |
|---|---|
| Local admin and enable passwords | Reset to new unique values in the vault |
| Directory bind and authentication server service accounts | Rotate; reduce to read-only scope; domain accounts tied to the device reset twice with Kerberos tickets revoked, as ED 24-01 required |
| Stored API keys and integration tokens | Revoke and reissue; update consuming systems |
| TLS certificates and private keys on the device | Revoke and reissue |
| User sessions and cookies issued by the device | Terminate all active and persistent sessions after patching |
| Passwords of users who signed in during the exposure window | Force reset where a credential harvester or memory leak is possible; revoke cloud tokens in hybrid estates |
5.4 Session revocation is not optional. In the CitrixBleed incidents, stolen session cookies stayed valid after upgrade and bypassed MFA, which is why Citrix told customers to terminate sessions after patching. Use the Secrets Rotation Runbook Template for the mechanics.
6. Recovery
- Apply the vendor fix as soon as it is released and validated on one instance; CISA's ED 24-01 required federal agencies to apply updates within 48 hours of release, a useful benchmark.
- Remove temporary compensating controls in stages, one at a time, watching for exploitation attempts in the logs.
- Restore normal access paths only after the device passes an integrity check, is on a fixed version and all secrets in 5.3 are rotated.
- Keep enhanced monitoring for [30] days: alerts on new admin accounts, configuration changes and logins using the rotated service accounts from unexpected sources.
- Close the incident only when the Risk Owner signs off the hunt results and the residual risk.
7. Communication and notification
| Audience | When | Owner | Content |
|---|---|---|---|
| Vendor | At activation; immediately for suspected compromise | Vulnerability Lead | Priority case, versions, indicators found, request for mitigation and fix timeline |
| Executives | Within [2] hours for Critical | Incident Lead | Exposure, decisions needed, service impact of mitigations |
| Users | Before service-affecting changes | Communications | Alternative access, expected duration, forced password reset instructions |
| National CERT or CISA | When indicators of compromise are found | Incident Lead | Indicators and timeline, to help others |
| Regulators and data protection authority | Within statutory deadlines if personal data or essential services are affected, for example 72 hours under GDPR Article 33 or the NIS2 early warning | Legal | Notification per the applicable regime |
| Customers and partners | Per contract, or if their credentials or sessions transited the device | Legal and Communications | What happened, what they should rotate |
7.1 Do not publish technical detail that would help others exploit an unpatched flaw. Use the Incident Communication Plan Template for message approval.
8. Post-incident review
8.1 Within [10] business days, review: time from public disclosure to exposure confirmed; time to mitigation; whether the asset inventory was complete; whether the vendor mitigation caused outages; hunt findings and earliest evidence of exploitation; secrets rotated against secrets held.
8.2 Ask whether the device needed to hold those secrets at all, and whether an end-of-support product should be replaced. Update this playbook and the risk register.
Implementation guidance
- Build the inventory first: versions, owners and exposure of every edge device and internet-facing application. Without it, step 3.1 takes days.
- Inventory the secrets on each device: bind accounts, API keys and certificates with owners and a tested rotation procedure. See the Service Account Inventory Template.
- Forward device logs off-box so a compromised device cannot erase its own history.
- Pre-approve the offline decision for named Critical services, so the Risk Owner is not found at 2am.
- Exercise: a tabletop where a VPN vendor discloses exploitation with no patch; time the exposure assessment and rotation.
Small vs large organisations: a small organisation may have one edge device and no hunt team; it should agree a retainer and rely on vendor and CERT indicators, and favour disconnection over complex compensating controls. A large organisation needs per-product owners, automation to query versions across estates, and pre-built hunt queries.
Metrics: median hours from KEV addition to exposure confirmed; percentage of edge devices with a named owner and current version recorded; hours to mitigation for Critical exposures; percentage of device-held secrets with a tested rotation procedure; number of activations where the hunt found compromise.
| Framework | References |
|---|---|
| NIST CSF 2.0 | ID.RA-01, ID.RA-08, DE.CM-09, RS.MI-01, RS.MI-02, RS.AN-03, RS.CO-02, PR.PS-02 |
| NIST SP 800-53 Rev. 5 | SI-2 Flaw Remediation, SI-5 Security Alerts, Advisories, and Directives, RA-5 Vulnerability Monitoring and Scanning, IR-4 Incident Handling, IR-6 Incident Reporting, IA-5 Authenticator Management |
| MITRE ATT&CK v20 | T1190, T1133 External Remote Services, T1505.003, T1078, T1210 |
See the Zero-Day and Exploited Vulnerabilities Guide and the Edge Device Security Guide for prevention.
Standards and references
- CISA: Known Exploited Vulnerabilities
- CISA: ED 24-01 Mitigate Ivanti Connect Secure and Ivanti Policy Secure Vulnerabilities
- CISA: ED 25-03 Identify and Mitigate Potential Compromise of Cisco Devices
- NCSC: Vulnerability management
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- MITRE ATT&CK: T1190 Exploit Public-Facing Application
Related NHI Mgmt Group resources: Zero-Day and Exploited Vulnerabilities Guide · Edge Device Security Guide · Vulnerability Prioritisation Guide · Incident Response Guide