Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

How do we…

How do we decide what to fix first when the scanner shows thousands of findings?

12 decision pointsThe pack behind this answer: Vulnerability & Exposure Management

Add to board memo

The short answer

Recommendation
Stop ranking by the scanner's severity score alone. Rate each finding on whether it is being exploited, whether it is reachable from the internet, how severe it is and how critical the system is, then work to the deadline of the priority that gives.
Reasoning
The volume is not the problem. Ranking by the score alone is, because the score measures a weakness in isolation: it does not know whether attackers use it or whether anyone can reach the system. Evidence of real attacks outranks severity, and so does public exploit code for a High or Critical weakness on an internet-facing system. Where exposure, criticality or severity is not known, the more urgent value applies, so gaps in your asset inventory cost the people who can close them. The four priorities each carry a deadline counted from the clock start: the earlier of first detection and the vendor's release of the fix (with no fix, first detection).
Considerations
  • The priorities and deadlines are the defaults in the CISO Times vulnerability pack. Your own standard may set different ones. The order of the questions matters more than the numbers.
  • Making a finding more urgent needs no approval. Making it less urgent needs the standard owner, a recorded reason and an accepted control that changes one of the four inputs.
  • If a finding may already have been used against you, treat it as an incident instead of waiting for the fix.

The decision, step by step

Select any step for the reasoning behind it and where the pack covers it.

  • Start
  • Step
  • Decision
  • Outcome
  • Loop back
StartThe scan returns thousands of findingsStepCount one finding per weakness per systemStepRecord the four inputs and the clock startDecisionIs the weakness being used in real attacks?DecisionIs the system internet-facing, or rated Critical?DecisionHow severe is the weakness technically?DecisionCan it be reached from the internet?DecisionIs exploit code public for it, or not known?DecisionIs the system rated Critical?DecisionCan it be reached from the internet?DecisionIs the system rated Critical?DecisionIs the system rated Critical?OutcomePriority 1 — EmergencyOutcomePriority 2 — HighOutcomePriority 3 — MediumOutcomePriority 4 — LowDecisionDoes anything justify changing the priority?StepRaise it, and record whyStepLower it only if a control changes an inputStepWork the queue in orderDecisionAt this week's triage, has any input changed?DecisionWill the fix be made by the deadline?OutcomeRequest an exception before the deadlineOutcomeFixed, then confirmed by a rescan

Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.

Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one. A code beside a source, such as RR-17, is the number of a rule in that pack document; the document lists its rules.

Read as text

The same flow written out: each step, its reasoning and where the pack covers it. 24 steps.

  1. Start

    The scan returns thousands of findings

    A large backlog is normal, especially after a first authenticated scan or a new cloud account. The volume is not the problem. Ranking it by CVSS score alone is, because the score measures the weakness in isolation. It does not know whether attackers use it or whether anyone can reach the system.

    In the pack

  2. Step

    Count one finding per weakness per system

    The same vulnerability on twenty systems is twenty findings, and each may end with a different priority. A web server and a test box with the same flaw are not the same risk. Drop informational results with a score of 0.0: they are not findings.

    In the pack

  3. Step

    Record the four inputs and the clock start

    Record exploitation evidence, exposure, technical severity and asset criticality. Also record the date the finding was first detected on that system and, where the vendor has a fix, the date it released it. Every deadline counts from the earlier of the two; with no fix, from first detection. When exposure or criticality is unknown, take the more urgent value: unknown exposure counts as internet-facing, and unknown criticality as Critical. Gaps in the asset inventory then cost the people who can close them. Unknown exploitation counts as not known exploited, and is checked again at the next weekly triage.

    In the pack

  4. Decision

    Is the weakness being used in real attacks?

    Yes when there is reliable evidence of exploitation anywhere: the CISA Known Exploited Vulnerabilities catalogue, a vendor advisory saying so, a national CSIRT or sector feed, or an incident of your own. Public exploit code is checked further on: for a High or Critical weakness on an internet-facing system it makes a Priority 1, and otherwise it is an early-warning signal. If you don't know whether it is exploited, treat it as not exploited and check again at the next weekly triage.

    In the pack

  5. Decision

    Is the system internet-facing, or rated Critical?

    Internet-facing includes anything reachable from networks you do not fully control, such as partner links and guest Wi-Fi, not only the public internet. Critical means failure or compromise would stop a core business service or expose highly sensitive data. If either is unknown, answer yes.

    In the pack

  6. Decision

    How severe is the weakness technically?

    Take the severity the scanner reports, or the vendor's rating where the scanner gives none. With neither, treat it as High. The bands follow FIRST's CVSS ratings: Critical 9.0–10.0, High 7.0–8.9, Medium 4.0–6.9, Low 0.1–3.9. Rescoring a finding by hand to a lower severity is a lowering, and needs the same approval as any other.

    In the pack

  7. Decision

    Can it be reached from the internet?

    An attacker who can reach the service from outside needs one step. One who must first get inside your network needs two. A laptop counts as internal unless a vulnerable service on it accepts connections from the internet. Browser and email-client flaws are attacked through the user, and the exploitation question catches them when they are used.

    In the pack

  8. Decision

    Is exploit code public for it, or not known?

    Working exploit code, or a proof of concept that attacks the weakness, published where anyone can get it, such as a code repository, an exploit database or an attack framework, and that works against the version you run. For a High or Critical weakness on an internet-facing system it makes the finding Priority 1, whatever the criticality of the system. If you do not know whether such code exists, treat it as if it does until the standard owner records the answer.

    In the pack

  9. Decision

    Is the system rated Critical?

    A Critical system raises a finding by one priority level, but never to Priority 1. Priority 1 comes only from evidence of real attacks, or from public exploit code for a High or Critical weakness on an internet-facing system. High-criticality systems do not raise the priority; they decide the order of work within it.

    In the pack

  10. Decision

    Can it be reached from the internet?

    The same test as for severe weaknesses. A Medium flaw that anyone on the internet can reach is more urgent than the same flaw behind your network defences.

    In the pack

  11. Decision

    Is the system rated Critical?

    A Critical system raises the finding one level, from Priority 3 to Priority 2.

    In the pack

  12. Decision

    Is the system rated Critical?

    A Critical system raises the finding one level, from Priority 4 to Priority 3. This is how a modest flaw in the database behind your customer records gets a 30-day deadline instead of 90.

    In the pack

  13. Outcome

    Priority 1 — Emergency

    Exploited, and reachable from the internet or on a Critical system; or public exploit code for a High or Critical weakness on an internet-facing system. In the pack's defaults: mitigate within 72 hours of detection (or of the re-rating that made it Priority 1), fix within 7 days of the clock start, and tell the standard owner at once. Treat it as a possible incident. If there is any sign the weakness has already been used against you, follow “If a vulnerability affects a business-critical service, what happens next?” instead of waiting for the fix.

    In the pack

    See also

  14. Outcome

    Priority 2 — High

    Exploited on an internal, non-critical system; severe and internet-facing with no public exploit code; or raised because the system is Critical. The pack's default deadline is 14 days, with escalation to the asset owner's manager if the finding is still open on day 10.

    In the pack

  15. Outcome

    Priority 3 — Medium

    Severe but internal, or Medium and internet-facing. A Medium flaw on an internal Critical system is also raised here from Priority 4. The pack's default deadline is 30 days. Where the payment card standard applies, it sets its own clock as well: it counts its one-month period for critical patches from the patch's release. The pack's own clock also starts at the vendor's release when that is earlier than detection. Check the exact wording in your PCI DSS version with your assessor.

    In the pack

  16. Outcome

    Priority 4 — Low

    Low severity anywhere, or Medium on an internal, non-critical system. The pack's default is 90 days, usually met through the normal patch cycle. These can be tracked in bulk, but still carry the deadline.

    In the pack

  17. Decision

    Does anything justify changing the priority?

    Two things can, and they are treated differently on purpose. Making a finding more urgent never needs approval, because it only makes the rule stricter. Making it less urgent needs the standard owner, a recorded reason, and a control that actually changes one of the four inputs.

    In the pack

  18. Step

    Raise it, and record why

    Early-warning signals can justify a raise before exploitation is confirmed: public exploit code where it does not already make Priority 1 (on an internal system, or for a Medium or Low weakness), a high EPSS score (FIRST's estimate of the chance of exploitation in the next 30 days), a vendor marking the flaw 'exploitation more likely', or reports of ransomware groups using it. The triage chair decides and records the reason.

    In the pack

  19. Step

    Lower it only if a control changes an input

    Taking the service off the internet, confirmed by an external scan, changes exposure, so it qualifies. So does disabling the vulnerable feature, or isolating the system to named management hosts. 'The web application firewall should block it', 'it is monitored' and 'the patch is scheduled' change nothing, and do not qualify. Re-read the priority with the changed input. The clock does not restart. A lowering is never made to rescue a missed deadline.

    In the pack

  20. Step

    Work the queue in order

    Within a priority, fix in this order: earliest deadline first, then exploited before not exploited, then Critical, High and Standard systems, then stronger early-warning signals. This is how thousands of findings become a list a team can start on this week.

    In the pack

  21. Decision

    At this week's triage, has any input changed?

    Check open findings against the exploitation sources, and internet-facing findings against the public exploit sources, every week. When a finding becomes more urgent, for example because it has just been added to the Known Exploited Vulnerabilities catalogue, re-rate it that week. Its new deadline is the earlier of its old deadline and the date the change became known plus the new priority's period. If a control you relied on to lower a priority stops working, the finding returns at once to its original priority and deadline.

    In the pack

  22. Decision

    Will the fix be made by the deadline?

    Deadlines are calendar days from the clock start: the earlier of first detection and the vendor's release of the fix (with no fix, first detection). Ask before the deadline, not after: once it has passed, the finding is overdue and escalates, first to the asset owner's manager, then to the approver.

    In the pack

  23. Outcome

    Request an exception before the deadline

    If the fix genuinely cannot be made in time, request an exception while the finding is still in date. Controls that do not qualify for a lowering, such as a firewall rule or extra monitoring, still count as evidence in the request. The exception is time-limited and has its own approver.

    In the pack

    See also

  24. Outcome

    Fixed, then confirmed by a rescan

    A finding is closed when the fix is verified, normally by a rescan that no longer finds it, not when the ticket says 'patched'. Keep the closure evidence with the finding: an auditor typically picks a handful of findings and asks for each one's detection date, owner, deadline and the scan that proved it fixed.

    In the pack

    See also

Practical checklist

  1. Count one finding per weakness per system.
  2. Record the four inputs, the date each finding was first detected and the date the vendor released the fix, where there is one.
  3. Use the more urgent value where exposure, criticality or severity is not known. Treat unknown exploitation as not known exploited, and check it again at the next weekly triage.
  4. Read off the priority, and set its deadline from the clock start.
  5. Work each priority in order: earliest deadline, then exploited before not exploited, then the more critical systems, then stronger early-warning signals.
  6. At each weekly triage, re-rate any finding whose inputs have changed.
  7. Request an exception before the deadline if a fix cannot be made in time.

Evidence to have ready

  • For each finding: the first-detection date, the vendor release date where there is a fix, the four inputs, the priority, the owner and the deadline.
  • The recorded reason for any finding you raised, and the standard owner's approval and reason for any you lowered.
  • The closure evidence for each fixed finding, normally the rescan that no longer finds it.

Assumptions

  • You have a scanner or other source producing findings, and an asset inventory, even an incomplete one.
  • The priorities and deadlines shown are the defaults in the CISO Times vulnerability pack. Your own standard may set different ones. The order of the questions matters more than the numbers.

Not covered here