Product

Vulnerability Management Isn't About Finding Issues — It's About Fixing Them in Context

Daniel Miessler

,

Founder of Unsupervised Learning. Building AI applications and infrastructure that upgrade humans.

,

Originally posted on LinkedIn here

I think a lot about Vulnerability Management because I think it's a proxy for a lot that's wrong with Cybersecurity. Plus I've spent a long time doing it in various forms, culminating in building and running the VM program for Robinhood a while back.

The question I get asked most about the VM space is, "Why is it so hard?", or, "Why haven't we solved this yet?".

I think I have an answer, and it's going to tie into a lot of different stuff, including AI, so strap in.

The problem

Fundamentally, VM is about three main things:

  1. Finding vulnerabilities
  2. Prioritizing them
  3. Fixing them

There's lots of other pieces, but they roughly fall into those buckets.

Well our problem isn't with #1. I've yet to find a security team or customer who was like, "Yeah, so here's the thing...we've just fixed everything! We just need more vulnerabilities. Every time we find them, we fix them. So we need more."

That's happened zero times. Yet solution providers continue to talk about how good they are at finding issues, and how many issues they find, etc, etc.

Anyway, the next challenge is prioritizing them. We've done a decent job of this—as an industry—but it's only been a partial win, for a reason we'll talk about. The approach we've taken is to learn as much as possible about the vulnerability itself, and whether it's being actively exploited.

All good stuff, but it's missing the biggest part, which is how relevant the issue is to the company. We take stabs at that by having a static list of technologies we use, or some other partial method, and that gets us somewhere, but it's not quite it. We still don't know how many servers it applies to, where on the server, where in the app, who owns that app, how that team they're on makes changes to code, using what systems, at what cadence, using which workflows, and using which tools.

Oh, and keep in mind the people on the team change all the time. They leave, get hired, change managers, and the organization changes. Plus the tools, and the workflows. So it's all constantly in flux.

And that brings us to fixing them. It's really hard to fix things when it's near impossible to find the people in charge of actually fixing them.

I was at ground zero during log4j, and the entire game there was this problem described above. It was the same for everyone, everywhere.

  • Find all the instances of the issue
  • Ok, but where are they?
  • Ok, but is that a server? A container? A pod?
  • Who owns it?
  • Are they still here?
  • What list did we get that from?
  • Oh, it's 14 months old?
  • Oh, half those people don't work here anymore?
  • Oh that person moved departments?
  • What about the version of the software? Is it vulnerable?
  • How do we check?
  • Who's the person with access who can check?
  • How do we get specific remediation advice for their context?
  • What about mitigations?
  • Which versions aren't vulnerable?
  • Did that change with the update that just came out?
  • Who do I send this fix to?
  • What tool do I send it in?

Etc. Etc. That is the Vulnerability Management problem. Not "finding vulnerabilities". It's knowing exactly where, in precisely what piece of software, in what configuration, owned by what person, and getting it to them in the way that they work.

And doing that fluidly, in a constantly changing company.

The obvious solution that's really hard

The good news is there's a solution that's coming, which will be enabled by a lot of different AI and AI-adjacent stuff. The bad news is that it's hard, and it will take some time.

It's inevitable—like the future—but like the future it will be unevenly distributed.

The answer is context. Continuously. Updated. Context.

The answer is to always know the state of these things. Think Asset Management, but for everything that matters to IT and to the business overall.

  • People, their org structure, their tools they use
  • Software, how it's deployed, by which team, using what tools and processes
  • Applications, which software, on which boxes, owned by which teams, with which POCs
  • Vulnerabilities, in which software (see above)
  • Servers
  • Teams
  • Open ports
  • Listening APIs
  • Etc.

Everything, everywhere, all at once.

There is software that does this pretty well for cloud environments. But that's because it's new tech that's largely centralized by its very nature. That's not the case for teams, and org structures, and traditional server environments, and networks, and applications, and projects, and documentation, and all the stuff that makes up a functioning business.

And that's where AI comes in. Well not AI itself, but AI platforms that use AI Agents to continuously crawl, scrape, parse, and organize all this into single, cohesive, and queryable STATE.

That STATE is the context in which everything else will be accomplished. That STATE and CONTEXT is how things like Vulnerability Management will go from intractable to expected and normal.

And that same context will solve a lot more in the business than just Vulnerability Management. It's project management, communication, planning, strategy, and all sorts of activities that are essential to the business.

Summary

So basically it comes down to this.

  • We continue to struggle with VM because VM's problem isn't finding vulnerabilities, it's figuring out what matters and how to actually fix them
  • And this requires that we know the state of the organization and very deep level, which has not been possible and still isn't quite possible
  • But soon it will be, because of continuous monitoring and contextualization of the organization's state using AI Agents and AI platforms
  • This is the missing piece that will make it possible to know exactly what needs fixing, at what priority, and how to actually make that happen in way that doesn't make engineering hate security

I can't wait.

The good news is that I’m starting to see some light from a few companies who are getting these points.

When I explained all this to my friend who just started working at Dazz , for example, he jumped out of his chair because this all sounded like their approach.

So I’m excited to see what they and others are building that’s focused more on the remediation context problem and less on the stuff we’re already doing well.

There is hope.

See Dazz for  yourself.

Get a demo