EXPOSURE MANAGEMENT PROCEDURE

From Scanner Observation to Managed Risk · Six-Step Model · Patch Hygiene

Table of Contents

1. Purpose and Philosophy
2. The Exposure State Model
3. Roles and Responsibilities
4. Step 1 — Collect Observations
5. Step 2 — Validate Asset and Condition
6. Step 3 — Validate Exposure Path
7. Step 4 — Classify
8. Step 5 — Select Treatment
9. Step 6 — Verify Closure
10. Patch Hygiene
11. Risk Acceptance and Exceptions
12. Adversarial Validation
13. Reporting and Metrics
14. Regulatory and Framework Alignment
15. Procedure Control

1. Purpose and Philosophy

This procedure establishes CERG’s exposure management program — the discipline of understanding which weaknesses actually threaten the organization, not which ones a scanner reports.

1.1 The Operating Premise

A scanner report is inventory data. It is not the exposure management program.

CERG does not measure its security posture by how many vulnerabilities a scanner finds. It measures posture by confirmed reachable exposure, by how quickly observations are triaged into decisions, and by whether treatment actually closes the exposure path. A program that reduces total findings while leaving Internet-exposed critical exposures open is not improving — it is reorganizing failure.

This procedure operationalizes Principle 5 of CERG-POL-001 through a fundamentally different lens than traditional scanner-driven vulnerability programs. The program does not start with “scan, score, SLA, patch/accept.” It starts with the observation that most scanner output is noise, and the signal worth acting on is confirmed reachable exposure.

1.2 What This Procedure Replaces

This is version 2.0 of CERG-PRC-VM-001. The move to Exposure Management is deliberate. The core model has shifted from:

1.3 Scope

This procedure governs all in-scope assets: enterprise IT, cloud, SaaS, OT, CUI environments. Environment-specific overlays implement operational-safety adaptations for OT and evidence requirements for regulated environments.

2. The Exposure State Model

Every observation moves through a defined state pipeline. Progress between states is gated by explicit validation, not by elapsed time.

2.1 State Definitions

2.2 The Apache Example

A CVSS 9.9 Apache finding on a host where Apache is not running, ports 80/443 are blocked, and no reachable service path exists is not a material vulnerability. It is a scanner observation until exposure is confirmed.

A scanner can be technically correct — Apache 2.4.51 is installed, and CVE-2024-XXXX applies to that version — and still not identify exploitable exposure. The word “false positive” is the wrong bucket for many of these cases. The scanner was right about the software version. It was wrong about the risk.

Use states, not a binary “real/false” toggle.

2.3 The “False Positive” Problem

A finding classed as a “false positive” in a traditional VM program may actually be:

Each of these has different operational and audit implications. Collapsing them all into “false positive” loses the signal that distinguishes “this is fine” from “this isn’t fine but we have a control.”

3. Roles and Responsibilities

4. Step 1 — Collect Observations

Observations arrive from many sources. They are aggregated into a single pipeline but are NOT called “findings” until validated. An observation is a signal that requires triage; it is not yet a fact.

4.1 Observation Sources

4.2 Observation Intake

All observations enter the pipeline with source metadata, a timestamp, and the raw severity/score reported by the tool. No SLA clock starts at this point. The clock starts at confirmation (Step 4).

4.3 External Reports and Supply Chain

External researcher reports and supply-chain advisories follow the same pipeline. See Sections 3.1 and 3.2 of the prior version for detailed intake workflows — those processes are unchanged and remain in force as operational sub-procedures.

5. Step 2 — Validate Asset and Condition

Before asking “is this dangerous,” ask “is this real?”

5.1 Validation Criteria

5.2 Validation Timing

6. Step 3 — Validate Exposure Path

A validated condition is not automatically an exposure. This step asks: can an attacker actually reach this?

6.1 Exposure Path Assessment

6.2 KEV Acceleration

If the observation matches a CISA Known Exploited Vulnerabilities (KEV) entry and the asset is confirmed real, the exposure path assessment is accelerated regardless of CVSS score. A KEV entry means active exploitation exists in the wild — the assessment shifts from “is this exploitable” to “is this already being exploited against us.”

7. Step 4 — Classify

After validation and reachability assessment, every observation is classified into exactly one category. This classification drives treatment priority, not CVSS score.

7.1 Classification Taxonomy

7.2 Treatment SLAs (Canonical)

SLAs are measured from classification to verified closure. The SLA tier is driven by classification and exposure context, not by raw CVSS.

7.3 Environment Overlays

7.4 OT/BES Patch Deferral Routing

OT patch deferral is a routing decision, not a blanket waiver from exposure treatment. Use the table below when a vendor-tested patch, operational maintenance window, safety constraint, or reliability concern prevents treatment within the governing SLA.

For every OT deferral, document why a non-patch treatment (path block, segmentation, configuration change, monitoring, vendor isolation, or service removal) cannot close the exposure sooner. Deferral does not close the finding; closure requires verified treatment or a valid, reviewed risk/exception posture.

8. Step 5 — Select Treatment

Treatment is chosen based on the most effective path to close confirmed exposure, not the most familiar one. Patching is one tool among many.

8.1 Treatment Options

8.2 Patching Is Not the Center

Patching is important. It is not the same as risk reduction.

A program that patches everything on schedule but leaves an Internet-exposed, unauthenticated API on a crown jewel is failing. A program that cannot patch a legacy OT controller but has verified that the controller is air-gapped, monitored, and on a replacement roadmap is succeeding.

Measure outcomes, not activity.

9. Step 6 — Verify Closure

A treatment is not complete until independently verified.

9.1 Verification Methods

9.2 Verification Timing

Verification must occur within 5 business days of treatment completion. Unverified treatments are treated as open exposures. A treatment that passes verification but the exposure re-appears within 90 days triggers a root-cause review.

10. Patch Hygiene

Patch hygiene is a distinct discipline from exposure management. It is necessary. It is not sufficient.

10.1 What Patch Hygiene Is

Patch hygiene keeps platforms supportable, reduces configuration drift, prevents known-weakness accumulation, and satisfies compliance requirements that mandate currency. It is a maintenance function — like oil changes for a vehicle. It prevents future problems; it does not fix today’s exposures.

10.2 Patch Hygiene Cadence

10.3 Patch Hygiene Metrics

These are reported separately from exposure management metrics. Conflating patch hygiene with exposure reduction produces vanity metrics.

11. Risk Acceptance and Exceptions

11.1 Policy Exception vs. Risk Acceptance

These are different things and follow different paths.

Governance owns the exception workflow. Risk owns residual risk analysis. Business owns the consequence. Security does not own the business consequence.

11.2 Risk Acceptance Process

When treatment cannot meet SLA, the owning team requests risk acceptance through CERG-PRC-RM-001. Documentation must include:

• Observation identifier, asset, environment, classification
• Reason treatment is not feasible within SLA
• Compensating controls in place and their verified status
• Risk owner (business) and approver
• Expiration date and re-evaluation triggers

PPR-tier exposures are not eligible for ordinary risk acceptance. The only exception is OT operational windowing under §7.4. For BES Cyber Systems, the CIP deviation / mitigation route is mandatory when compliance is impacted and cannot be replaced by a generic acceptance memo.

12. Adversarial Validation

Scanning identifies what is misconfigured or unpatched. Adversarial validation tests whether controls actually function under attack. Findings from adversarial engagements enter the observation pipeline at Step 1 and follow the full state model.

13. Reporting and Metrics

13.1 Exposure Management Metrics (Primary)

These metrics measure exposure reduction, not scanner activity.

13.2 Patch Hygiene Metrics (Secondary)

13.3 Reporting Cadence

13.4 Escalation Triggers

Immediate escalation to CISO:

• Active exploitation observed against an in-scope asset (auto-promotes to Material Risk — PPR)
• Any PPR-tier exposure open beyond its SLA
• A confirmed exposure on a BES Cyber System that risks NERC-CIP non-compliance
• A confirmed exposure in a CUI environment that materially affects SSP posture
• Adversarial validation finding demonstrating a successful path to Restricted-tier data or operational disruption

14. Regulatory and Framework Alignment Summary

15. Procedure Control

Revision History

Review Triggers

Annual review or upon: material tooling change, regulatory SLA change, internal audit finding, CISO direction, or significant change to asset tiering.

Related Documents

A scanner report is inventory data. Confirmed exposure is what matters.

CERG-PRC-VM-001 · Version 2.02 · PUBLIC

Source: procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md · Download .md · View on GitHub