Chaining low-severity findings into something your board will fund

There is a particular kind of report that does real damage: forty findings, none of them rated above medium, delivered to a team who reasonably conclude that they are in decent shape. Six months later somebody strings four of those findings together and the company has an incident.

The problem is that severity is nearly always scored per finding, in isolation, as though an attacker would use exactly one. No attacker does. The work of an intrusion is almost entirely composition.

What a chain actually looks like

Here is a composite drawn from several engagements, with the details changed. Each step, scored alone, would sit at low or informational on most scales.

1. 1A verbose error page on a marketing subdomain disclosed the internal hostname convention. Informational.
2. 2A staging environment used the same convention and was reachable from the internet without a network control. Low, because staging holds no production data.
3. 3Staging shared a container registry with production, and its deployment credentials were readable by anyone who could run a job in it. Medium at most, in isolation.
4. 4The production registry pull credentials had never been scoped, so they also permitted push.

Individually: a leak of naming, an exposed test environment, an over-broad credential and a permissions oversight. Together: the ability to place an image into a registry that production pulls from. That is not a medium.

How we build chains during an engagement

The method is deliberate rather than opportunistic. We agree the objective during scoping, usually phrased as a sentence: reach customer records, obtain persistent access to the production cluster, or move from a single compromised laptop to the payroll system.

• Everything discovered goes into a graph rather than a list. Nodes are assets and identities, edges are the ways one can reach another.
• Anything that yields information, however dull, is recorded as an edge. Naming conventions, employee lists, error verbosity and forgotten subdomains are all edges.
• We look for the shortest path to the objective, then look for the second shortest, because the second one usually survives the first fix.
• When a path completes, we stop and report it immediately rather than continuing to collect findings.

Why this changes the conversation internally

A list of forty findings creates a triage problem and a demoralised team. One demonstrated path from the public internet to the thing that would end the company creates a decision. Boards fund decisions. They rarely fund backlogs.

It also changes what you fix. Faced with the chain above, the instinct is to fix the exposed staging environment, because it is the most obviously wrong. The higher-value fix is scoping the registry credential, because that single change breaks this path and several others that we had not walked yet.

What to ask of your next report

• Ask for at least one narrated path from an external starting position to a business-critical asset.
• Ask which single remediation removes the most paths, rather than which finding is rated highest.
• Ask what the tester could not reach, and why. The controls that held are worth knowing about.
• Ask for the graph, not only the table. If your testers did not build one, they were probably making a list.

None of this makes individual findings unimportant. It makes them legible. A low severity finding is a low severity finding until it is the second step in a route to your customer database, and the only way to know which one it is happens to be the work of walking the path.