Three Simultaneous Findings, Two Change Slots

Rank by exposure × exploitability × blast radius.

1. The VPN appliance. It is internet-facing, sits outside the WAF and segmentation, has public exploit code, is KEV-listed, and terminates sessions for 2,400 users - the only finding with a realistic path to perimeter compromise. Book the earliest CAB slot and publish the five-day notice immediately. In the interim, reduce exposure: geo-restrict where business allows, enforce MFA at the appliance, disable unused portals or features, and alert on exploitation attempts in the appliance logs.

2. The domain controller LDAP finding. At 7.5 it looks like the least urgent, but a DC is the highest-value asset in the estate and the schema blocker means exposure persists a full quarter. That combination - high asset value plus long dwell - outranks a higher CVSS on a narrow-reachability host. Treat it as active risk management now, not a next-quarter ticket.

3. The reporting server. CVSS 8.1 but reachable only through a jump host and holding no regulated data; the realistic attack path requires an attacker who already has a foothold. Schedule it in the next routine window.

Use the second CAB slot for the VPN follow-up validation or the reporting server; do not spend both on the same asset class.

Controls first: restrict LDAP and LDAPS at the host firewall to the specific application servers that need it, so the exposed surface is an enumerated list rather than the server VLAN. Enforce LDAP signing and channel binding, require LDAPS, and disable anonymous binds if they are still enabled. Add monitoring for anomalous bind patterns - high-volume failed binds, binds from unexpected source subnets, and enumeration of directory objects - since exploitation of directory services usually looks like unusual query volume rather than a crash.

Governance: a formal risk acceptance signed by the CISO with an explicit expiry date, not an open-ended exception. The acceptance should name the blocker (schema change), the vendor position in writing, the compensating controls, and the review trigger: publication of exploit code, a KEV addition, or the quarterly change, whichever comes first. Put the schema change on the change calendar now with an owner, because 'next quarter' items without a booked change slot slip indefinitely.

One caution: an accepted exception that renews silently is how a 7.5 becomes a permanent 9.8. Require the exception to expire and to be re-argued rather than auto-renewed.

Board language should be about exposure and consequence, not scores. Something like: 'One perimeter system has a known, actively exploited vulnerability. It is being patched on a named date with interim access restrictions. One directory service finding cannot be patched before Q3 due to a vendor schema dependency; it is under compensating controls with a time-limited, CISO-accepted residual risk.' Boards act on named dates, named systems, and named owners.

The metric that keeps it honest is the count of KEV-listed vulnerabilities on internet-facing assets plus mean time to remediate against SLA - reported as a trend, not a point value. Supplement with exception count and average exception age, because that is where risk hides. Avoid a single 'percentage patched' figure; it is dominated by low-risk endpoints and hides the fifteen hosts that matter.

Also report the VPN outage commitment as a business item, not a technical one: it needs the remote-access user base to be notified and the service desk briefed, and that coordination is usually the real reason perimeter patches slip past their SLA.