Vulnerability Reports Don't Reduce Risk

The vulnerability scan crisis is now a month in the rear view mirror, and at a team meeting you’ve had time to decompress. Now it’s time to debrief and prepare for the next iteration.

The first thing you come to realize is that while the exercise created a lot of activity, and urgency, the real question remains:

Is the environment any safer?

No one can answer that.

Sleep was lost, weekends were sacrificed, and boxes were checked. We patched the telnet-server. The service was disabled, but the package was still present.

It showed up as a “High,” and a lot of emphasis was placed on Highs, so we patched a service that wasn’t even running. The actual risk was pretty low given that the service was disabled, the server is logged in excruciating detail and our SOC had really good content to detect the steps necessary to re-activate and use the service, but trying to explain that fell deep in the “too hard to do” column. Patching was the fastest path of least resistance.

It would have been removed, had time permitted.

In retrospect, it’s pretty clear that risk reduction wasn’t the goal. We were trying to achieve a number that no one could define except to say, “lower”.

In a manner of speaking, what matters most is what comes next. The executive edict has been made crystal clear. Prayer, or not, patching will take place.

In most environments, that turns into a familiar pattern:

- teams chase severity scores instead of actual risk exposure

- patches get applied in a blind effort to chase findings

- issues show up again and again in scan after scan

- people get spread thin

Everything looks equally important, so everything gets treated the same.

And when everything is treated the same, very little actually improves.

Reducing risk requires something different.

It requires deciding what matters.

What’s called for is:

• an environmentally aware approach to findings that represent real risk exposure

• a hierarchy of remediations

• grouping work by “bang-for-the-buck”, focusing on changes that measurably reduce risk

• acceptance that some findings can wait without consequence

No scan report alone helps with that.

They list everything. They assign severity, which is a start, but then they stop.

The real work starts after that.

If you’ve worked through more than one scan cycle, you’ve probably seen the pattern.

Activity goes up, and scan results change, but associating that with risk is a bit more unclear.

That’s not a tooling problem. It’s not a skills problem. It’s an interpretation problem.

If the output isn’t turned into a focused plan, it just becomes another list to manage.

And another report to revisit next cycle.