Ranking Four Findings When the Board Says Fix All Criticals
Halden Pay has 2,300 public IP addresses, 61 registered domains, and a configuration database listing 1,400 assets. After deploying external attack surface management, the team discovers 3,900 exposed assets, including 210 forgotten development subdomains, an internet-facing Jenkins server with no authentication, and a storage bucket holding 14 GB of sandbox test data. Four findings are on the table: a CVSS 9.8 flaw in an internal-only service protected by mutual TLS; a CVSS 6.5 vulnerability in the remote-access VPN gateway that has a public proof of concept and appears on the known-exploited list; an API key for the payments sandbox committed to a public repository eleven days ago; and 40 expired TLS certificates on marketing microsites. The security team has three engineers, the board has ordered all criticals fixed within 30 days, and the payments team says the internal service cannot be patched before the quarter ends.
1. Rank the four findings and write the two paragraphs you would give the board to explain why the ranking is not the same as their severity numbers.
Read the worked answer
Ranking:
- Exposed API key, same day. It is a working credential, it has been public for eleven days, and sandbox-to-production pivots are common when teams reuse secrets. Revoke and rotate first, then investigate access logs for the eleven days. Rotation is minutes of work, so there is no reason to sequence it later.
- VPN gateway, within 72 hours. A public proof of concept plus confirmed exploitation in the wild on an internet-facing remote-access device is the classic initial-access path into a payments environment. Patch, or if the vendor patch is not ready, restrict access to managed devices and known ranges while monitoring for exploitation attempts.
- The 9.8 internal service, this quarter with a compensating control now. Mutual TLS means there is no unauthenticated external path; the score describes the flaw, not the reachability. Confirm who can obtain a client certificate, restrict that list, and alert on certificate issuance. Patching in the quarter is defensible with those controls; saying so in writing is not the same as ignoring it.
- Expired certificates, routine. Real user-visible harm and reputational noise, not a breach vector. Automate renewal.
To the board: the score measures worst-case impact if an attacker can reach the flaw. Two of these are reachable today and one already has a working key. We are reporting reachability, and we will show you the exposure trend rather than a count of criticals.
2. 3,900 discovered assets against 1,400 known ones. How do you bring the unknown estate under control without stopping the remediation work?
Read the worked answer
The 2,500-asset gap is itself the finding; every future vulnerability number is unreliable until it closes.
Working method:
- Deduplicate and cluster by network range, certificate subject, and TLS fingerprint before anyone emails a list. A raw export of 3,900 rows will be ignored, and rightly so.
- Classify into three buckets by decision, not by owner: decommission, onboard, or investigate. The 210 development subdomains are usually the first bucket. Wildcard DNS and shared infrastructure hide them; fixing the DNS and deployment pattern prevents them returning.
- For orphan assets, ownership is discovered through certificates, cloud account tags, and the last deploying commit author, not through a broadcast email. Give each orphan a named interim owner on the security team so it cannot fall between teams, with a 14-day deadline to find a permanent one.
- Jenkins with no authentication and an open bucket are immediate actions regardless of inventory state: put authentication in front, delete or restrict the bucket, and check access logs. These take hours and should not wait for the inventory project.
Process to prevent recurrence:
- Require a DNS and cloud change feed into the attack surface tool so new exposures appear in hours, not in the next quarterly scan.
- Make a CMDB entry mandatory in the deployment pipeline for anything internet-facing.
- Report both counts: assets with a named owner, and the time since discovery for unowned assets. A shrinking backlog of unowned assets is the number that matters.
3. Design the prioritisation rule the team will use next quarter, replacing CVSS-only triage, and define the metrics that will actually tell the board whether exposure is falling.
Read the worked answer
Rule, applied in order, with reasoning recorded for each step:
- Is there evidence of exploitation (known-exploited list, exploit kit, observed attempts in our logs)? Escalate to emergency.
- Is the asset reachable from the internet, and does it hold or grant access to regulated data or production credentials? Reachability plus impact beats raw score.
- Is there a compensating control verified in the last 30 days? If the control is documented but untested, treat it as absent.
- Business criticality and blast radius, supplied by the asset owner, not guessed by the security team.
- Only then, severity score as a tiebreaker.
Service tiers: internet-facing with regulated data at 72 hours for exploited issues and 14 days otherwise; internal but credential-bearing at 30 days; everything else at 90 days with an automated scan to confirm.
Metrics, chosen because they resist gaming:
- Median time from discovery to remediation, by tier, with the count still open past SLA.
- Percentage of internet-facing assets with a named owner and a known patch path. Coverage, not counts.
- Reopen rate: how many findings reappear within 30 days, which exposes patching that did not stick.
- Number of exposures discovered by the attack surface tool before any internal team reported them, trending to zero.
Avoid presenting vulnerability totals; they move with scan frequency and teach the board nothing.