63 lines
3.6 KiB
Markdown
63 lines
3.6 KiB
Markdown
# Vulnerability & Patch Management Policy
|
||
|
||
**Document owner:** [Owner/Role]
|
||
**Approved by:** [Steering Committee / CISO]
|
||
**Effective date:** [YYYY-MM-DD]
|
||
**Review cadence:** [Annually]
|
||
|
||
---
|
||
|
||
## 1. Purpose & Scope
|
||
This policy establishes mandatory requirements for identifying, prioritizing, and remediating vulnerabilities across [Organization]'s IT, cloud, and OT/IoT assets. It applies to all systems, including those managed by third parties per the [Vendor & Third-Party Risk Management Policy](vendor_risk_management_policy.md).
|
||
|
||
---
|
||
|
||
## 2. Policy Statements
|
||
|
||
### 2.1 Vulnerability Scanning
|
||
- Internet-facing assets **must** be scanned at least **weekly**; internal assets **must** be scanned at least **monthly**.
|
||
- Authenticated scanning **should** be used where supported for accuracy.
|
||
- Kill-chain systems (per [Authentication Policy §2.1](authentication_policy.md)) **must** be scanned continuously where tooling supports it.
|
||
|
||
### 2.2 Patch SLA by Severity
|
||
| Severity | SLA |
|
||
|---|---|
|
||
| **CISA KEV-listed** (actively exploited) | ≤ 15 days, kill-chain systems ≤ 72 hours |
|
||
| **Critical (CVSS ≥9.0)** | ≤ 15 days |
|
||
| **High (CVSS 7.0–8.9)** | ≤ 30 days |
|
||
| **Medium (CVSS 4.0–6.9)** | ≤ 90 days |
|
||
| **Low (CVSS <4.0)** | Next scheduled maintenance window |
|
||
|
||
### 2.3 Emergency Patching
|
||
- A confirmed zero-day or actively exploited vulnerability affecting a kill-chain system **must** trigger emergency change process — patch or compensating control (e.g., network isolation) within the SLA above regardless of standard change windows.
|
||
|
||
### 2.4 Exceptions
|
||
- Missed SLAs **must** be documented with compensating controls and CISO approval, with a review date not exceeding 90 days.
|
||
- Unpatchable legacy systems **must** be isolated (network segmentation) as a compensating control, not left exposed by default.
|
||
|
||
### 2.5 Kill-Chain Priority (Barbell Principle)
|
||
- Vulnerability remediation effort **must** be concentrated disproportionately on kill-chain systems and internet-facing assets; low-criticality internal systems on the standard SLA table do not warrant equivalent urgency.
|
||
|
||
### 2.6 Enforcement
|
||
- Repeated SLA misses without an approved exception **must** be escalated to the CISO and tracked as a recurring finding per [Authentication Policy §2.12](authentication_policy.md) structural learning process.
|
||
|
||
---
|
||
|
||
## 3. Antifragility Alignment
|
||
This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**.
|
||
|
||
| Pillar | Applied In | How |
|
||
|---|---|---|
|
||
| **1. Structural Decoupling** | §2.4 | Network isolation as a compensating control means one unpatchable legacy system doesn't become a standing risk to everything else |
|
||
| **2. Optionality Preservation** | §2.4 | Isolation preserves the option to keep a legacy system running without accepting its full risk |
|
||
| **3. Stress-to-Signal Conversion** | §2.6 | Repeated SLA misses feed the structural post-mortem process rather than becoming permanent exceptions |
|
||
| **4. Sovereign Intelligence** | §2.4 | Exceptions and compensating controls documented and owned, with a forced review date |
|
||
| **5. Asymmetric Payoff Design (Barbell)** | §2.2, §2.5 | Tight SLA (≤72h) concentrated on kill-chain + KEV-listed vulnerabilities; low severity gets the lean next-cycle treatment |
|
||
|
||
---
|
||
|
||
## 4. References
|
||
- **[NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning](https://csrc.nist.gov/pubs/sp/800/40/r4/final)**
|
||
- **[CISA Known Exploited Vulnerabilities (KEV) Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)**
|
||
- **[CIS Controls v8.1 (Control 7)](https://www.cisecurity.org/controls/v8-1)**
|