Cool, awesome.
Go ahead and get started.
First off, you know, thank you very much for having me at CypherCon.
It's my first time here, first time in the city, and first time in the state.
And it has been lovely, even with the rain and snow.
So thank you very much for a warm welcome.
I really appreciate being able to hang out the last couple days.
Meet all the speakers, meet the organizers.
It's been a great time.
So I really appreciate the hospitality.
Test, test, test.
Okay, it's a little bit low there.
I may have to eat the mic on this.
Just saying I appreciate the warm hospitality.
It's been a wonderful time.
It's my first time here in Milwaukee, first time here in Wisconsin.
So I don't know how I managed to make it my old age with that being true.
But it's no longer true.
So I'm very happy about that.
So the talk today is really about Vuln management, and more about Vuln mismanagement.
Just for kind of background, I've been putting around with something related to either scanning or writing exploit tools since like 1997.
Back when it was like gross Perl scripts and Visual Basic, and that eventually turned into what I worked on for 15 years, which is Metasploit.
And then between those was working on various products, doing consulting, doing pen desk work, and then building products again.
So this is a long old man rant, basically.
But hopefully there's some useful parts here.
And the end goal is for you to say, wow, my Vuln management sucks, let's make it better.
Because that's how I feel about the state of the world today.
So as I mentioned before, my name is H.G.
Moore, CEO, cofounder of Runzero, previously ran Metasploit forever, recovering a pen tester.
I still like doing gigs here and there where I can, because it's fun to see what the world still looks like out there.
These days I mostly get my visibility by working with customers and seeing what they're struggling with, which is a great way to get there.
You can find me on email.
So feel free to reach out afterwards if you have any questions on stuff.
Feedback is always great.
So what I want to talk about today is first, like, where are we today?
What do we consider Vuln management?
What's the state of the world?
You probably already know a lot of the stuff if you spend all your day doing this.
But maybe a little bit old hat.
But I think there's at least some surprising parts that have come out of this.
Then I want to talk about, like, how did Vuln management become enterprise software?
Because it's one thing to have a set of hacker tools that help you find Vuln abilities, and managing it like some day job.
It's a very big gap.
How did we get there?
What does it look like?
What happened?
I want to talk a little bit about what the near future looks like.
As we're seeing, the tooling, the market, the industry, everything kind of evolving the last few years.
What's it going to look like this year and next year and so on?
And then how do we make that better?
What do we do that's actually a better outcome than where we're going today by default?
Anyone here ever used Cybercop?
It used to be called Ballista back in the day.
One of the really early commercial Vulnability scanners.
Anyone else used ISS's scanner back then?
Before Real Secure and Black Ice, but they had a Vuln scanner back then, too.
There were very few products back then that were like commercial Vuln scanners.
Something that's really cool is the old Cybercop scanner actually had a 3D city view.
You could fly through space to see all your host and Vuln abilities.
We've never gotten back to that peak.
We're still striving to get better, you know, flying through city space, hacker views of Vuln management.
This is what the tools looked like in 1999.
On the left side, I think it's ISS.
Right side, I believe, is Cybercop.
And you've got some charts.
You say, you know, number of Vuln abilities by severity.
A list of operating systems.
And you can tell these are old, because the OS's here are things like HP Unix, you know, Baytech, all the old crunchy stuff, like NT351, all the fun things we used to shout all day long back then.
What's actually interesting, though, is the variety of operating systems is pretty unique.
You don't see this variety anymore.
Now you've got three.
You used to have 35.
It was amazing.
Hackers could do a little bit of everything and still own everything.
Now you have to get at least one of them to really keep up.
So it's been 25 years.
What do Vulnability Management products look like in 2024 as of like last night?
Number of Vuln abilities by severity.
Again, I don't want to, like, get sued by any Vuln management vendors, but we haven't gone very far.
We're presenting the same data the same way in the same charts.
We're using the same libraries, the same representation, the same everything.
Like, these are actually modern products you can buy for lots and lots of money right now.
And, you know, there's only three big vendors these days.
Why do the products look the same as they did in 1999?
So that's kind of what I want to dig into a little bit here.
How come things haven't changed?
Why does everything look so dated and crunchy?
And, like, where are we going?
So you talk about Vuln management, you're usually talking about four parts of a life cycle.
You start off saying, hey, go find some stuff I need to care about, whether it's missing patches, configuration problems, unknown asset, whatever it happens to be, go find the thing that I care about.
Prioritize it to the things that I think are most important, because I can't do everything.
Try to remediate it.
Try to, like, either open a ticket, make someone else remediate it.
I love it when people talk about opening tickets as remediation.
Because, like, you're not remediating it.
The poor sucker on the other end of the ticket, they're remediating it.
And then you're coming back trying to verify it and say, yes, you actually did a good job of remediating it.
But it's hilarious when you talk to Vuln management vendors and they say, we have remediation in the product.
So you create a ticket to make someone else do it.
Like, yes, okay.
Is that remediation or just making it someone else's problem?
So the challenge of this cycle is that every step through this path gets more difficult.
For every thousand vulnerabilities you look at that you identify, you maybe fix one of them and validate one of them.
It's just a really tight funnel.
You're not really gonna get to the validation stage of most things that you ask your team to go look into.
It's a lot of work.
So we've really been focusing our time not on identification anymore.
Like, we don't necessarily care how good the identification is because you can't keep up in the first place.
We've really been focusing our time on prioritization and trying to figure out how to make remediation and validation faster.
But if you look at where most of the investments go into Vuln management today, we're really focused on prioritization.
Which is kind of a weird thing to work on.
Why would you want to take a big list of things that a tool will give you and throw most of them away?
And that's what we're doing by focusing on prioritization.
So we know it's difficult.
We know it's problematic.
This is why we're here.
Because this is the challenge.
This is why I'm talking about it.
Just to kind of make that clear.
You almost never get to the validation phase for most of the vulnerabilities you find.
So what are we doing with them?
Well, then a team gets asked, well, how are you performing as a Vuln management team?
Like, you know, your porny-haired bosses come by and they say, well, why are we spending this much money on the tooling and on this team and these things if we're only fixing this microscopic percentage of total vulnerabilities?
Well, then you think back and say, well, here's our time to detect or time to remediate or time to verify.
Here's the absolute Vuln counts.
Here's our absolute risk score.
Here's our adjusted risk score model through this particular algorithm.
Here's the prioritization view from this other product that sits on top of my first product.
Here's my coverage ratio of assets.
Here's the number of exceptions reopens.
We come up with all these funky metrics to talk about how well the program is performing because we can't show what we want to show, which is we have no more vulnerabilities.
We just aren't going to get there.
And we've decided we're not going to get there.
So instead we have to try to demonstrate all these other metrics and kind of somewhat numerology around it, saying, here's things that show that we're doing good work.
Now, that's the boss's view.
Personally, if you're on a Vuln management team, you're busting your butt.
You're doing everything you possibly can to work hard.
But how do you show that?
And that's really been the challenge for a lot of teams.
How do you show that in a way that actually makes a difference to whether you get owned or not?
So if you look at the scan and patch cycle, your standard Vuln management, Vuln scanner cycle, it really fell apart in 2005.
And if you look at this chart on the bottom, this is the number of CVEs by year.
And you get a sense for why it fell apart.
We had decent number of consistent vulnerabilities going through mid-2000s.
Then you get to 2005, and it almost triples.
Then you get to 2019 here.
And it's almost ten times what it was before.
We had something like 20,000 CVEs reported last year.
And a lot of folks are aware that NVD is now kind of struggling to keep up with all of it.
And they haven't even looked at or triaged any of these vulnerabilities.
They're way, way, way behind the display.
And now you know why.
Because there's so many CVEs being created.
Whether this is a good thing or bad thing really depends on how credible you think CVE is in the first place.
How many vulnerabilities don't have a CVE in the first place?
We're now seeing alternate sources of vulnerability tracking.
Things like the GitHub database, the advisor database, that have absolutely nothing to do with CVE.
They're just putting a unique identifier on some new badness that you can track.
So, CVE is not even the whole story.
And it's already spiraling out of our control and our ability to keep up.
So, if you look at how we've been doing scan and patch, as we started to roll out things like Windows XP SP3, which is a big change, every endpoint started having a firewall enabled by default.
Well, now you can no longer connect to WMI.
Now you can't connect to SMB.
You can't do authenticated scans of these devices because you can't talk to them anymore.
There's no port to go query to see what has a patch installed.
So, all the scan and patch stuff really started to hit a wall around 2005.
And that's when things started to break down.
And, of course, you have your segmentation, your cloud, all these other things that make it more difficult to just, like, point a scanner at your network and tell it to go find badness.
Similarly, the amount of work that goes into writing an unauthenticated vulnerability check is equivalent to writing a fully working exploit.
And I say that, like, I've done both, and they're just as difficult.
It's not harder to write the vulnerability check.
You're working on a really tricky heap exploit.
You have to massage the heap and do a thing and flip some bits and do all that kind of stuff, prepare it all, and then you finally get a shell, maybe.
Like, a vulnerability check is harder.
Because you have to do the exact same thing, but not crash the process.
And you have to leak it back in a certain way.
And you have to cover future compatibility and previous compatibility and every possible thing under the sun.
And the hardest thing about vulnerability checks is that it's not just you and the target you're talking to.
You're also talking to everything else between you and the target.
So you're often going through a firewall, a WAF, a proxy, some other kind of defensive tooling.
And those things have bugs and they fall over.
Like, one of my favorite vulnerabilities of all time, which is probably a friend of mine's least favorite vulnerability, because it was in his product, was the RealIce stack overflow back in 2006, something like that.
If this device was designed to RealIce eventually got acquired by ISS, which became real secure.
But if this device saw a packet, it would shell your IDS.
Now your IDS is controlled by the attacker.
And it didn't matter where the packet came from.
You could spray it across the network.
That's one of the examples of where unrelated products are impacted by doing vulnerability scanning or other types of network work.
So all of this kind of came together.
And we started saying authenticated scans really are the standard.
You can no longer do unauthenticated scans.
You can't afford to write an unauth checked for anything.
It just takes too much research time.
We've seen teams that used to be, you know, either 7525 research to patch to basically authenticated local checks.
Turned to really 2575 the other way.
Where there's a very small team doing unauthenticated bone check work now.
It's really just a bigger team.
We'll go into more detail here on that.
But some of these vendors are now shipping over 100,000 checks in their product.
That's a lot of checks.
And you can't stop checking for something.
If you're a vulnerability management product, you can never get away with not checking for NT351 vulnerability.
That may be 30 years old, but you still have it in your product.
You're constantly creating stuff on top of your product.
You're creating more work.
You're adding more checks.
There's ways you can slice and dice that and get rid of some of that stuff.
But you can't get rid of all of it.
Especially if it's a web server.
Let's say it's a web server you don't know anything about.
What do you check on it?
Do you check everything?
Do you check hundreds of thousands of requests to find every possible web app that could be running on it under every particular sub path?
Or you just say, hey, it's running Apache.
And that's actually a checkbox in a lot of vulnerability scanning products.
Because it massively increases the amount of time and resources it takes to finish the job.
So that's kind of the challenges we're looking at going forward.
You have to always check for old stuff.
You can't just drop that.
You have to be perfect every time.
You don't have a pre-auth vulnerability check team that's particularly big anymore because they're so hard to write and so difficult.
It's kind of a lost art in a lot of ways.
So what have we done instead?
Well, we moved to agents.
So most vulnerability management vendors now have an agent.
The agent is responsible for doing all that hard work on the device.
So you don't have to jump through firewall hoops.
You don't have to go figure out is it reachable?
Is it pre-auth?
You just say, is the check installed or not?
And there's still problems with that.
Some of these agent-based checks, they say, great, we installed the patch, we're good.
And of course, the question is, well, did you reboot?
If not, well, that bug's still there, right?
You have to actually reboot the device, especially for the SMB2 vulnerabilities, the internal blue, stuff like that.
Unless you reboot the box, the patch didn't actually apply.
So folks would say, hey, great, my agent says we're applied everywhere, but it didn't really matter because the machine hasn't been rebooted in two years.
You know, back in the early days of internet yore, Unix admins would flex about their uptime.
So someone would say, my machine hasn't been rebooted in five years.
Congrats, how many vulnerabilities do you have in your kernel right now?
We got a little bit better with that with some of the live kernel patching stuff, but it's not great.
Generally, the longer your machine's been online, probably the least it's been updated.
So I'd actually look at uptime as a negative indicator for vulnerabilities these days, in that sense.
So the challenges with agent-based vulnerability reporting is that you don't have the network context anymore.
You don't know whether an attacker can actually reach that thing.
You just know that it's present.
So if you're looking for something like, okay, I found a log4j, I found the Java log4j jar file on disk, and I know it's out of date.
Great.
What does it actually mean?
Is it exposed to the network?
Is it part of a web app?
Is it just sitting there, but it's part of some gooey, thick client that doesn't go anywhere?
You have no context anymore for whether that thing's actually exploitable.
So you lose a lot of the valuable insight into the risk and the exposure.
So it's really difficult to prioritize vulnerabilities when they're found through an agent-based scan, because you don't know whether they're reachable.
You don't know what their impact is anymore.
You just know that the CVE is there.
So if you look at some of the EDR products that have now been shipping vulnerable management data, they just give you a giant list of CVEs.
It's like, well, what am I going to do with that?
Which ones matter?
Why should I care about it?
Give me more context.
I need more to make a decision about it.
Anyway, so the challenges.
If you look at the breakdown of vulnerability checks by category for a couple of the major products, right?
I don't want to pick any particular vendor or get sued, but here's an example of one particular vendor.
Local checks are the blue.
And everything else is basically, you know, Windows checks, Cisco, web, miscellaneous.
The pre-authenticated checks there are probably less than 1% of that pie.
That's just the relative ratios.
Now, take a different approach on it.
Let's look at a different vendor and say, how many of your checks every year have been remote unauthenticated checks?
Is it unauthenticated or not?
Well, that bright purple line, that's the percentage of unauthenticated checks in 1999, 2000, 2001, 2002, 2003, 2004.
And then you see it collapse around 2005.
The percentage of checks they write that are pre-authenticated, they just gave up and said, nope, we're just doing local checks from now on.
We're gonna do a really, really small number.
And that number keeps getting smaller as a percentage of the whole.
So let's flip around and look at as the absolute numbers.
So the absolute numbers are actually not that different.
So you can see that, you know, hey, in 1999, we had something like, you know, 300 or 400 vulnerability checks.
2002, we had about 700.
As we got down to 2023, we still have about 700 pre-auth vulnerability checks.
But look at how many other checks are out there.
And these are almost all Unix-authenticated checks.
These are ones that, like, every time there's a vulnerability in some Linux platform, they then duplicate that vulnerability check for every OS and distribution.
So you have your version, you have your Red Hat version, you'll have your Rail version, you'll have your Ubuntu version, your Debian version, and so on.
So it ends up padding the numbers quite a bit.
So when vendors tell you that they've got 200,000 vulnerability checks, what they're really telling you is they're writing about 300 or 400 pre-auth checks per year.
So vulnerability management is now falling behind quite a bit.
Like, not only are you struggling to figure out what to prioritize, but it's really difficult to get things fixed, to get validated, and so on.
You're also not really getting good data in the first place.
A lot of these checks are just not checking the thing that you actually care about that second.
Oftentimes because the vulnerabilities are being exploited faster than you can scan them.
And faster than the vendor can push an update to go scan them.
So, you know, great examples there, like Moveit.
It's a product that most people didn't hear about until a few months ago.
It's made by Progress Software, it makes lots of other exploitable stuff.
And, you know, if you are waiting for your vulnerability scanner to give you an update, to go look for Moveit, and then you have to wait for a scan cycle, and then run that scan cycle, and then report back up, like, you already have a ransomware notice in your email.
You've already been out.
Like, it's been two weeks.
We've seen the time between discovery of vulnerability in the wild and the response by vendors stretching out to weeks and months at this point.
One of the recent of antibugs, there was literally no patch for it for two weeks.
Another good example was the Cisco IOS XE vulnerability.
If you're old school and you remember the old slash level 15 hack in Cisco IOS, you just go to Cisco IOS web interface and put slash little 15 in your God mode and you logged in.
It was great.
That happened all over again, with Cisco IOS XE.
And by the time Cisco was able to notify everybody about it, as part of the advisory, they said, one, we don't have a patch.
Two, you've already been hit by a state actor.
Here's the IOCs to look for.
Three, good luck.
That's where we are these days.
Our exposure is so wide.
Vendors are so underwater.
By the time they tell you about it, they don't have a patch available for you at this point.
They're just telling you, you need to start digging for incidents.
You need to trigger a response.
So, because the scanner is mostly authenticated patch checkers, all your unmanaged stuff is not being left behind.
Because, of course, you can't do an agent based or an authenticated enumeration of this random virtual appliance or whatever the junk is of the network that's not part of your managed infrastructure.
So, you start figuring out, okay, anything on my network that doesn't have an agent or that I can't log into, that's not a dark spot.
That's something I don't know anything about that I have a really big challenge getting ahead of.
Sometimes those virtual appliances, and we've seen attackers, on one hand, the shift in attacks over the last probably eight months or so has been hardening, because we're no longer seeing as many phishing attempts, kind of like, you know, end user targeting stuff,
because we've actually gotten pretty good with our EDRs and our agents and our firewalls and our filters and all that kind of junk.
So, instead, the attackers went after the next softest link, which is all the crap of the edge.
So, your edge firewalls, your routers, your VPT, your VPNs, your file transfer systems, all that stuff hanging out there, right at the edge of the network.
That's really been the juicy spot for attackers.
But they have to go a lot deeper.
It's a lot harder work to do.
But it's just kind of fun seeing, like, the commodity of exploitation shift from internal kind of phishing attacks now to the edge again, after it went back the other direction, back and forth a few times over the last few years.
So, prioritization has now become its entire own market.
Because prioritization is such the key piece of getting ahead of your vulnerable management strategy at this point, you now see products that all they do is sit on top of another product and filter out stuff and give you less garbage.
Now, it blows me away that you buy a product that sits on top of another product just to give you less data from it.
But that's what we got.
And, you know, the truth of it is the vendors who are making those tools are also trying to catch up and make prioritization easier.
But in the meantime, there's this great market selling into that anyway, saying, okay, they're not doing it fast enough.
Here's what you need instead.
All right.
So, how do we get from cool hacker stuff to this thing that we're dealing with today?
This big pile of slow-moving, authenticated agent-based loan checks?
Well, in the beginning, there were hackers, right?
Lots of soft targets, almost no detection.
We just all ran around hacking things left and right.
It was great.
No one would catch us unless you're really, really stupid or you ragged a lot.
As long as you didn't rag about things too loudly online or forget to use a proxy or something like that, you could just tear through the network back in the 90s and no one would be the wiser.
Now, if you want to hack things faster, you write a scanner for it.
You say, here's the thing I want to break into.
Here's a cool technique I have, you know, download passwords or all those other cool techniques back in the day.
PHF attack, all that stuff.
Early on in the world.
Scanners, really quick, really easy and really fast.
So, it got to the point that there are so many hackers hacking all this stuff, business started to say, hey, this sucks, let's not make this happen anymore.
How do we keep people out of our systems?
This is getting messy and our vendors aren't really caring and responding quick enough.
So, they hired consultants.
They said, great, we're going to hire consultants to do an assessment and find the bad stuff and tell us what to lock down and make sure it doesn't happen again.
The hackers said, great, we're going to be consultants.
That's how I got in this industry.
Internet hoodlum in my teens and decided, wow, these customers are really struggling with this thing I write all day.
Let's go be a consultant.
Consultants then built tools, which are not that different from the original scanners.
Those tools eventually evolved into a product of some sort and those products became these big platforms where there's multiple parts to it.
So, if you look at the maturation, if you will, like, what we're selling in the volume management world is typically a hacker's view of the organization delivered to some sort of software, whether it's SaaS or on-prem or some combination.
You really want to show someone, like, here's the juicy spot in your network that you need to go fix now.
That's generally the goal.
How do you prioritize remediation of the thing that someone's going to take advantage of, the most likely to take advantage of in your particular environment?
The customers need more than a vuln scanner.
They don't want to be given one giant list of problems to go fix, they also want to be able to show their boss that they're doing lots of work and show trends over time.
So, now you've seen that the original vuln scan model has been kind of warped a little bit and now folks are having to say, well, we need dashboards, we need reporting, we need light circle management, we need a remediation button that bothers the IT people each time I want them to fix something.
And the competition really kind of started heating up because there's a lot of money in this.
It became kind of a big industry.
Back around 2005 or so, there's probably almost like seven or eight really big players in volume management all kind of fighting it out.
You know, end circle, quite a lot of other names that kind of got lost to the history books or acquired multiple times since then.
These days there's about three, right?
There's only about three big vendors left.
And there's other folks trying to come back into the market and join it, but they're a little bit different.
They're not really the same type of product.
So, there's so much money tied to volume management that folks really started competing not just on how good they were at detecting stuff, but all the other features.
All the dashboarding, all the other junk you could do.
How great to make your team look.
All the other features that are tied to it, not necessarily about doing a good job of volume management itself.
So, what also made it worse is that the regulatory environment really pushed for commoditization.
They stopped caring whether your volume data was good.
They just cared that you did it and then you did certain things with it.
They said, okay, well, if you find a high or critical vulnerability in your PCI environment, that must remediate within this period of time.
But they don't care what tool you use for it.
They don't care how accurate that tool is.
They don't care whether that tool is actually correct and whether it's reporting as a high or a critical.
Like, the value has gone away.
Instead, they're just saying, you must do this thing, but we don't really care how.
So, volume management alone wasn't really enough for other folks.
You couldn't really make money in volume management alone once you got to a certain size, because there's only a certain number of customers that want this stuff, and the commodification of volume scanners meant that customers didn't really care anymore if they were good anymore,
just that you had one.
And so, it really sucked the life out of being able to build good products to find exposures, because people weren't being paid for anymore.
You're getting paid for doing this other stuff.
We're also deploying, you know, an EDR agent for deploying UBA, like, user behavior analysis stuff.
Like, you've watched these vendors who came in from the pure volume management side, now shift gears to cover everything else in the security spectrum.
Like, we've now seen EDR companies ship volume management.
We've seen volume management companies now ship EDRs.
Like, it's getting all kind of topsy-turvy these days.
In the meantime, like, the scanners had to keep adding more checks.
Again, you never get to stop checking for something.
You have to always keep adding and keep adding more stuff.
So, these things just got bigger and heavier and slower, because you had to keep adding more things on top of it, but the growth behind the business wasn't there to really innovate and make it faster and better.
So, the innovation really kind of stalled.
So, one regulatory regime I like to look at a lot is PCI, just because they tend to kind of point where the rest of the industry is going to go, especially for general commercial.
If you look at... so, PCI has a few requirements, and they just changed recently, again, with DSS-4 that is now mandatory as of, like, two days ago, I think.
But one thing you'll notice is that they have really two components to vulnerability scanning.
They've got your external scan that has to be done quarterly and an internal scan that has to be done quarterly.
On the external scan side, they say you must use an ASV, an approved scanning vendor.
The approved scanning vendors used to be in the hundreds, like, 200, 300 vendors.
There's about 77 right now.
Like, that number has been whittled down over time.
There's actually a much smaller number of vendors involved as ASVs these days than there used to be.
And if you look at some of these names on the right side, like, how many of these companies actually build a vulnerability scanning product?
How many are just services that package up somebody else's stuff?
It's a pretty small number of the companies there, these websites, that actually build a vuln scanner.
The rest are effectively just packaging up multiple products, pointing at you, and delivering, like, a service.
So the number of unique vuln scanners out there is probably around four or five right now.
It's actually a pretty small number across the board, even with these 77 ASVs.
Now, what's different, though, is that on the internal side, PCI DSS says you must do a quarterly internal scan.
You need to mitigate all critical and high severity vulnerabilities.
There's absolutely no requirement about what tool you use.
So you need to download and use either an open source tool, literally purchase product A or product B, because those are the only two products that are ASV certified, or use your ASV for internal scans as well, sort of like, you know, on-prem, proxy, things like that.
But there's absolutely no requirement about how good those tools are.
Like, whether external ASVs at least have to meet some sort of, like, certification criteria and get tested to be part of the program, there's no such criteria internally.
You can literally write a shell script that says good, bad, and run on your network, and you've now been qualified for PCI internal scans.
It's terrible.
So that's the challenge.
It's like, in a market where there is no value for having a good product for internal assessments, like, who's gonna go build those tools if you can't sell it?
There's no money to be made.
There's no requirement.
There's no hard edge there.
So instead, all you get are folks who really care about security, who are trying to find a product, and then struggling to find something that's actually accurate and good, because there's no market, you know, reward for it.
And that's really what's led us to where we are today.
So if you look at kind of where things are going right now, it's not great.
We're seeing kind of a big shift between vulnerability management and attack service management, all the different variants of that, like, chasm, e-chasm, you name it, and they're doing very different things for different reasons, but they're about to collide,
and that's kind of what this next section is about.
It's talking about kind of what the near term looks like between chasm and vulnerability management.
So, you know, it's not security unless you put the word cyber in front of it, unfortunately.
I still kind of grimace, because cyber still means something very different to me.
You know, growing up in the 90s, it's been killing me having to use the word cyber at work.
So vulnerability management is not preventing incidents, and I think everyone knows why, right?
You're getting a ton of data, you're having to prioritize it, you'll only be able to fix a small portion of it, and if the cycle is so slow to get an update to scan before you can mitigate it, it doesn't really matter.
It's not relevant anymore to preventing a breach.
It's just there to show you're doing the basics in the background and keeping the lid on things.
But security response has to be faster than ever.
You have a negative time now from when you hear about a vulnerability to when you're going to get a ransomware letter, or you're going to have someone in your network or extorting your customers.
The timelines have gone negative across the board, especially in the last eight months or so.
It's been pretty brutal for everybody.
I think there's a talk later today about what is like a hot exploit summer or hot zero day summer to stretch all the way into the spring again, guys.
We haven't slowed down anytime soon and we're not about to.
So while all this has been simmering in the background, there's a thing called Chasm that Gardner, Gardner being the analyst group, has decided to call it Chasm, which is cyber attack asset service management.
They're focused on enabling security and IT teams to find all your stuff and then basically mitigate vulnerabilities, continuously monitor, and so on and so on.
So the idea is that instead of just doing all management, finding vulnerabilities, putting them onto the factory floor, and then going through all the various conveyor belts of your internal order to get them fixed, instead we want to say, look at everything,
let's pick the things that are most relevant for your exposure right now, and let's focus on monitoring and reducing that exposure as quickly as we can.
So it's more of like a practical approach, if you will.
You're never going to fix all your problems, but you need to know what you have and you need to know what people are about to exploit before they exploit them.
And it's much more of like a practical, kind of faster approach to this.
But the key building block behind any of these Chasm, Asm, Easm, whatever products is knowing what we have in the first place.
So you've probably been bludgeoned to death with marketing around asset inventory and things like that for the last couple years.
This is why, is that you can't really deliver on any of these promises unless you know about all your stuff.
And finding all your stuff is hard.
It's not just hard to find it externally, it's hard to find internally and everywhere else.
There's lots of stuff just kind of hiding in the corners of your network.
So my current job, I started this company when I was doing Pentest work.
I left Rapid7 after the IPO, you know, went and spent some time back on the field again, helping startups, but also went back and did Pentest work.
Worked for Traders Partners for a couple years, or three years, almost four years.
And we went to the various, like, banks and retail and things like that and just hacked everything all day long, and it was great.
Also lots of IoT and turning apart hardware and things like that.
So really fun job.
One thing we noticed, though, is every org, especially when you're going to the same merchant bank every single quarter, and every single quarter you're doing the same test and you're getting in again, but you have to get in again through a totally different way because the team is really trying to keep you out again.
They're basically closing every door you find.
So if you're doing this for, like, 18 months at the same customer and you're coming back in for, the same org you know so well, it's like, what's left?
We know everything about your environment.
We've already gone from here to here.
We know where their servers live.
You know your structure, your monitoring, everything about it.
You have to get really creative.
So we found all kinds of funny ways to kind of bypass that stuff.
Like, what we ended up doing in the middle of that cycle was taking over the security controls.
So we found, like, a SolarWinds box that's multi-home inside the network that was connected to the CDE and the non-CDE.
And, of course, they did that because licensing is expensive.
You don't want to have two servers.
So you have a box sitting between the two of them.
So we popped that one machine, used the SMTP credential that we sniffed out the wire from one of the machines.
As you heard about SMTP and enter ID, it's still a thing.
So we used that credential to get into another machine as a local user, did all the fun escalation stuff, and used that to take over all the infrastructure equipment.
So even though we didn't have access to the CDE hardware, we didn't break into a particular CDE device at that point, we were able to cut holes in the firewall outside and let ourselves in.
So at that point, we're just pushing configurations out to the firewalls and opening doors for our own IPs, going directly into the CDE that way.
So attackers are going to find any way in, including rerouting your infrastructure, changing your firewalls, backdooring everything you have around your systems.
The great thing about tools like SolarWinds or Ryan2, not only are they juicy targets running on Windows, but they contain all of your credentials for all your other gear.
So you pop that one box, and now it passes for all your other stuff, which is great from attacker's standpoint.
Similar though, fast forward another six or eight months, we're starting to pull our hair out again.
Okay, nothing left.
They moved the SolarWinds box off.
They locked these things down.
We can't talk to any management interface.
The segmentation is amazing.
Then we started scanning subnets they didn't even know they had.
We basically started looking for random 10x networks.
We basically did a full RFC 1918 scan.
Let's go cover every possible privately routable IP range within this point of the presence of the environment that we had access to.
And we started finding all kinds of other crap they didn't realize they had, like building access controls, like the thing to actually open and close the doors downstairs in the building, like the access box.
That was great.
You find like weird DSL routers hanging up in like the telecom closet that wasn't part of anyone's network map.
You find VLANs that they didn't even realize were there anymore.
You also find cases where VLANs overlap with each other, where you have like a secure network and a non-secure network, but they're actually sharing the same physical media.
All you need is to sniff the network and realize you've got a different VLAN coming across the same wire because they misconfigured a switch someplace.
So all that stuff became kind of the next step for our kind of, you know, pentest of this type of org, where they're already particularly hardened and they're already, you know, they've been trying very hard keeps out for many years.
And that's really where the genesis for what I work on now came from, is like, wow, people need to go find their stuff.
And that's really what Chasm is about, is going and finding your stuff in the first place and then using that new data to get you there.
You know, end of the day, if your customer or your company that really cares about your security, like if you know about it, hopefully you've got a good handle on it.
So what's really going to bite you is the stuff you don't know about.
And that's where I think the industry is now refocused, is helping you find all that stuff.
So the typical model for Chasm products, or Chasm, you know, tools, products, whatever combination you want to call, is that what they do is they connect all your existing data sources with credentials.
And they say, let's go talk to your DHB server, your DNS server, your cloud backend, your intro ID background, et cetera.
Let's take all the data, glue it all together and say, here's, let's mush all the assets together and match them up and say, now, here's your stuff.
So there's lots of vendors that do this.
Some do it better than others.
But the challenge is that each of these data sources has a very different view of the same asset.
Sometimes like, you know, I'll call one product out.
CrowdStrike loves to tell you an IP address and a MAC address that has nothing to do with what's on the network.
So it'll just, the default MAC and IP it gives you is not one that's typically the one that's present on the network.
It may give you a random Wi-Fi MAC.
It may give you a random virtual MAC.
I've seen cases where CrowdStrike data came in and we had three assets reported to us as online at the same time, having the same IP and the same MAC and the same network.
It's like, two of y'all are lying.
Like, I don't know who it is, but two of y'all are lying.
And so there's lots of reasons that can happen.
Like, you can have double deployments, you can have VDI, you can have all this stuff.
So I'm not saying, like, I'm picking on CrowdStrike because they're a good example of this particular case, but every product has challenges.
Every product has duplicates, has gaps in their coverage.
So you start trying to pull data in from all these different third parties.
You say, okay, is it the same asset?
Is it a different asset?
Has it changed?
Has it been re-imaged?
The ones that are probably hardest, when you have like a school system where every time the student logs in, it re-images the machine and they get basically a unique install for their EDR and you get E for everything, but on the same physical hardware.
Another way that throws these products off is when you have docs at all your, you know, desktops in your business, like a bank, but everyone's moving the laptop between docs, but all the docs have their own unique MAC addresses.
So if you're doing a correlation based on MAC addresses, you're attaching random MACs to random machines randomly across the entire org, and it makes no sense.
If you try to correlate a MAC, it blows it all up.
So those are challenges to see that happen.
You also get really different details.
Sometimes you get the host name in the IP address.
You also get really different timelines.
Like if you take a scan of your network from today, but you take your, you know, the passive discovery from yesterday, then you take a intra -ID or connector or CrowdStrike, some of the EDR back in from the day before, and you put them in the wrong order,
what happens?
Well, you know, if you've got a lot of DTP churn or machines moving between networks, like you've now miscorrelated stuff because the timelines are all weird.
So you really have to take into account like the time horizon when you're merging all the stuff together and it's really difficult.
But what's going to make this most difficult of all is that the vendors who are involved, who are providing all this data to these CASM vendors, don't want to be integrated.
Like everyone wants to integrate, no one wants to get integrated.
Like everyone wants to be your single pane of glass.
So they will do all kinds of silly, shady things to prevent other third-party products from getting access to their data.
We've seen vendors pushing their customers to put IP controls in place so that the SAS-based connectors or the third-party competitors can't talk to them.
We've seen vendors who are significantly rate-limiting connections coming from certain parts of the network, but not others.
So for example, Microsoft Graph API, you'll see that they have a much lower rate limit when the connection is coming in from EC2, but much higher when it's coming from the customer's network.
And we know why they're doing that, so they can break all the vendors connecting to the Graph API.
But still, it's annoying.
Folks are not playing fair right now in the field.
So you're going to see a lot of fighting in that sense.
We also see vendors who have like hundreds of integrations, but they still miss really important stuff.
That happens because none of those integrations know about a device unless it's managed by something else, right?
If you can talk to a machine that has DHB or IPAM or DNS logs, great.
What about the network?
You can't do that, too.
So unless you're actually actively gathering data about your environment, you're actually running scans, doing passive capture, you're putting a node everywhere, you're kind of generally actively discovering all your stuff, even these SAS robotics can't find a large portion of your assets.
Typically, if you look at just what's available through integrations only versus doing a live network scan, you're missing 25% of stuff doing just integrations, which is a pretty big number, especially when those are now holes in your map that you can't secure.
So that's my mini ransom chasm.
It's hard.
So being a vendor in this space, it's really difficult to get it right, but we're also seeing a consolidation across the board.
Every product in the world now sells you inventory as a side effect.
Because they've got a list of stuff, right?
So, oh, you want inventory?
Sure, we've got a list of your managed agents, we've got a list of your endpoints over here, a list of the machines running this agent here, but they're all incomplete as a result.
But these vendors are saying, well, we're close enough.
We already have enough of your stuff.
Let's go and sell you ASM and Vuln management, too.
We've already got EDR in your box.
Let's now look for Vulns and say, now you can do Vuln management, you can pass your, yes, I've done a Vuln management scan because I have my agents everywhere.
And we can then use that to give you a sense of your attack surface, too.
But again, it's such an incomplete view that it's really hard to rely on it.
You have so many gaps right now if you're taking that approach.
But now that we're seeing Vuln management vendors selling EDRs and SIEM, it's just turning into one big mess at this point.
So, you're going to see a lot of consolidation across the board.
Generally, everyone's going to be selling you something tied to cloud security and everyone's going to be selling your product tied to visibility.
But this is what the ecosystem for security looks like right now.
And this is last year.
It's actually gotten a different sense.
This is a company called Momentum Cyber.
They do investment banking and dealmaking in the cyberspace.
And this is definitely in our charts.
You probably
heard about a third of them if you squint and look at them.
A lot of folks are in multiple categories.
But even on this graph here, if I spent 20 minutes drawing circles between things, I could probably point to 50 acquisitions in the last year.
So, the amount of rollups happening right now is ridiculous.
We're seeing a huge consolidation across all the security vendors because everyone's fighting for the same dollars.
The economic market is much harder.
We're seeing people do layoffs and not rehiring back.
Generally, everyone is struggling to pay their bills and generally grow.
And they do it any way they can, which often requires, you know, acquiring other companies, splitting up different business units.
And unfortunately, when that happens, you generally don't get good products.
You just get much more shallow products.
So, all the big platforms have gotten a lot bigger.
They've been using all the standard big platform tricks to undercut competitors, lock users into the platform.
If you're part of, you know, the Microsoft ecosystem, they're gonna give you all the defenders for, you know, your toaster, your defender for your whatever.
They have lots of defender products.
They're gonna sell you all of them.
Here at AWS, they do the exact same thing.
So, depending on what bucket you're in, that ecosystem is gonna try to buy, try to sell you everything else that they have, right?
They want you to buy all their stuff.
This is really being driven right now by economics and kind of the hype cycle.
We're kind of at the bottom of the hype cycle in a lot of categories.
Economics are a lot tougher right now with the federal interest rate.
So, you know, I can rant about the economic side forever, but effectively, like, when the federal interest rate goes up, that means startups are now that percent less valuable per year.
It's that... you have a much safer investment.
You can get 5% by doing nothing right now.
That's 5% coming out of starting up more innovative companies, doing more innovative product stuff, experimental stuff.
And it means all the way down.
People are investing less in the business.
They'd rather keep their money in cash than actually invest in the business because you have that 5% buffer already.
So, long story short, any time you see the federal interest rate rise really high, you're gonna see a big cut into startup ecosystem innovation over the next few years as a result.
And it just happens.
It's kind of part of the cycle.
So, one of the really surprising things about all this kind of roll-up and buyers and private equity and merging stuff is you end up with these really surprising combinations of products.
You know, is anyone here familiar with Progress Software and their line of products?
Okay, well, a lot of folks are familiar with the vulnerabilities in these products.
For example, like, Flowmon vulnerability came out two days ago.
All the WSFDP, all of the Moveit stuff, all the WhatsApp stuff, like, put them all together, put them under the same banner, and just try to make as much money as they can out of them, but they don't necessarily have a lot of time to make any of those individual products amazing.
Like, they're no longer in growth mode.
They're now in kind of maintenance inducing mode.
And that's just kind of the nature of private equity after your roll-ups.
Avanti, same thing.
Avanti has never made anything as a company.
Avanti has just merged together multiple companies together and then sold those mushed together products back to you.
And so, you have, like, the Pulse Secure product, which I think used to be the NetScreen product, that's just repeatedly getting hammered as an exploitable endpoint in the network.
And, therefore, it's the door into your environment.
And, you know, a little bit surprising here is a company called Fortra, which was also known as Help Systems before they spun out the cybersecurity division as Fortra.
And they've got a pretty strange bucket of companies.
Like, I've started one of these companies and I competed against many of these companies in my life.
Like, the same company that made Cobalt Strike is not the same company that owns Core Security and Core Impact.
That also owns my first company that I started back in 2000.
So, it's a really bizarre mix-up where you now have, like, all these different unrelated security companies got put under the same banner, under the same roof.
And they also...
the funny part here is they actually all got merged into other things like file transfer products.
So, now you've got Core Impact and Cobalt Strike in the same, like, corporate overlord, if you will, as the go-anywhere MFT product that just had, like, a zero-day, you know, going around the internet, right?
So, yeah.
It's kind of terrible that we've ended up with all of our assessment products under the same banner as some of the most vulnerable products you're supposed to be assessing.
So, as you start consolidating stuff, of course, you know, it makes lots of wide investments, but lots of shallow investments.
You're not going to see really deep products anymore.
You're going to see people trying to cover every part of the map they can, say, great, we've got these 10 pieces via our platform.
You can kind of hit all these checkboxes.
So, very much, you know, checkbox-driven acquisitions at this point.
Very few vendors are trying to make their data better.
No one's trying to say my bone scanner is now more accurate, or I give you more data about assets than anyone else at this point.
That's just not something that people can sell.
They can't really compete that way anymore.
They're really trying to give you a much broader chunk of your business.
So, it's really hard to specialize.
It's really hard to, you know, have a pure security company anymore.
Every security company is now just a software company.
And under the same rules as any other software company.
You have to grow at a certain rate.
You have certain things you have to do.
Certain targets you have to meet.
Volume data is still treated as a commodity.
So, no one cares how good your volumes are.
They just care that you have them and that you do certain things with them based on what they say.
And in some cases, like the internal requirements of PCI, they don't even care what the tool is, right?
They just care that it calls itself a bone scanner and you do certain things with alpha.
And of course, everyone wants to sell you a single pane of glass, but there's so many single panes of glass, what do you do, right?
So, the short version of this is we can do better.
This is where we are.
This is where we're going.
And it's not great, but we can definitely turn things around with a little bit of work.
So, if we want to build a better path, what do we do?
Well, we already have lots of good data.
So, we have some data.
It's not the best data.
But we've got lots of data.
We've got third parties we can pull from.
We've got our EDR logs.
We've got our sims.
We've got our bone scanners.
We can mush them all together and do things with it.
But end of the day, what we're trying to do is not manage vulnerabilities.
We're trying to minimize attacker opportunities.
So, if you're familiar with the equation of risk, right?
Risk is the impact times likelihood.
Well, we know what the impact is.
The impact is all of our customer data goes out the window and we get extortion or bad things happen or we get sued or all this other fun stuff.
The likelihood, though, we don't have a lot of control over.
It's someone else hacking our stuff.
I saw Oliver's talk yesterday.
Unless you only deploy your products on certain days on a holiday, you don't control their schedule, right?
They're just going to hack you no matter what.
So, because we don't really control the likelihood part of the risk equation, we don't control our risk.
Flat out.
We have no way to adjust our risk because we don't control the likelihood.
All we can do is minimize opportunities for attackers to do things to our environment.
And the way to do that is to make a list of all of our stuff.
Like, what is our stuff?
How many assets do we have?
Where are they?
Where do they live?
What are they connected to?
How are they managed?
When there's a new emerging threat of some sort, whether it's another Cisco bug, another Progress software bug, how do we get ahead of it as fast as we possibly can?
How do we get that thing off the internet within seconds?
As opposed to waiting for an update in the scan cycle and a push and a remediation and the next meeting to come up to figure out which ones we prioritize.
So, we need to track technologies, not vulnerabilities.
We don't really care anymore whether something is vulnerable or not.
We care whether it has that software or that hardware or that end of life status.
We care about knowing about the technology now.
We don't care about knowing whether it's vulnerable.
Because by definition, if you care about this technology this second, that means that there's probably no patch for it.
It's probably being exploited right now.
You don't get a chance to wait.
You don't get a chance to wait for a scan cycle.
You need to get that thing fixed this second.
So, we moved ahead.
We've kind of gone to the left a little bit and said, okay, you know what?
We can't really depend on vulnerability management to keep us from getting hacked.
What we can't do is keep track of our entire infrastructure and entire state.
And if we see an emerging threat in one of these categories, we go find everything that can possibly apply to it and we mitigate it then, right that second.
But how do you do that, right?
So, that's the idea.
We want to be able to kind of maintain a living model of our entire infrastructure with all the data we already have.
So, you're based on assumptions.
Like, if you look at the modern world, things are basically managed or they're not managed.
If it's managed, you've got patch management, you've got auto updates.
Your managed assets almost always have an agent these days.
Just because every EDR is effectively an agent, you have an EDR in almost everything you can manage.
Like, you know, in a lot of ways, you've got kind of two categories of assets in your environment.
You've got hot dog and not hot dog, right?
If anyone saw Silicon Valley, there's only two things you really care about .
Like, it's got an agent on it and I can get all this great data from it or I don't.
And so, we're going to focus on not hot dog.
So, if you have a machine that's unmanaged, you have no way to really do authentication to it because it's a vendor appliance, it's an IoT switch, it's some other doodad you don't have direct control over.
It could be part of your OT, your ICS work.
You need to be able to pull data from different sources to tell you about that asset anyways.
So, how do you get, like, a triangulated perspective about what that thing is?
Like, hardware model, firmware versions, anything you can possibly do to talk about it.
You know, the chasm tools out there, they correlate data from multiple sources.
You can do the same thing, too.
You can go through and dump your CrowdStrike inventory directly into whatever your elastic or sim of choice is and dump in your data and dump in something else.
And then when you say, great, show me everything about this particular IP address, you've got at least something.
You can say, well, this thing thought it was A and this thing thought it was B.
I can at least work with that a little bit.
That's actually a pretty reasonable approach, though, for where we are.
So, on the external tax service management side, there's lots of great tools out there.
Things that scan your domain and find new assets, look what they belong to you, copyright footers in the pages, all kinds of cool EASM stuff.
That's great.
But the internal side is still really tough.
Trying to identify, do I have this printer, do I have this device, do I have a Huawei camera someplace, all this other junk that's out there that you don't have a direct line of sight through an agent or a managed scan.
Vuln scanners are really good at telling you about vulnerabilities.
What they're not good at telling you about is asset information.
They don't tell you what the hardware is.
They don't tell you what the software is very well.
They don't tell you what the exact OS version is.
I can't tell you how many times I've gone and seen a Vuln report and all you get is a list of, oh, this is a Linux device.
Great.
Is it a Roku streaming device?
Is it a smart TV?
Is it a switch?
Is it a router?
Is it a server?
You don't get that distinction.
Instead, we get a list of vulnerabilities.
So doing the internal side of this is probably the most difficult part of getting ahead of your environment.
How do you get a list of all the stuff running all your things?
So if you have an EDR that gives you software inventory, that's great.
You can dump the software inventory directly from the export side, either do an API or just do a manual export, throw that into your sim, be able to quickly search for it and say, do I have it go anywhere, do I have this particular technology installed anywhere,
so that you have it handy when things hit the fan.
The flip side, though, is you can then use the network for the rest of it.
You can use your span port, you can put Zeek, you can get data from Zeek flows out of it, you can do anything else you can do for active scanning, you can throw in that data, ZMAP, mass scan, et cetera, commercial scanners, lots of great ones out there as well,
and tape all the data and throw them in the same place and correlate it all together.
So other kind of great tips for where to get data to make good decisions are your info and vulnerabilities are actually the most valuable part of your vulnerability scanner.
I can't tell you how many times I've gone into a report, and the thing I really cared about for that assessment was all the things that were info level.
Sometimes info vulnerabilities are ones that are actually critical vulnerabilities that just weren't marked the right way.
Like an example that I run into a lot is Zookeeper, of all the weirdest things.
Anyone know what Zookeeper is?
Okay.
So there's a few folks who work with distributed computing stuff where Zookeeper is kind of like a hash core vault demon.
It's basically like a secret server, like an NCB type thing.
But typically Zookeeper, if you see it exposed to the network, it's full of passwords.
It's full of all your credentials.
It has your RSA signing keys.
I ran across a telco the other day out of China that had all their RSA signing keys, all their app keys, everything just sitting out there on the internet in the Zookeeper service.
I was curious, what do vulnerable products do with this product?
Well, one particular vendor reports Zookeeper as like, oh, you've got Zookeeper, it's info level vulnerability.
I'm like, thanks, y'all.
All my passwords are hanging out in the info level.
So don't discount info level stuff.
That tends to be where a lot of the meat stuff is.
Those are cases where the protocol, the application is less understood by the vulnerability management vendor.
They don't really know a lot about the time.
But if you're trying to quickly respond to every instance of that technology, you need to know about your Zookeepers really quickly.
So that kind of applies across the board.
You want to be able to get as much detailed information about your assets as possible.
The challenge, though, is a lot of these products, what they really want to do is only tell you about the criticals and the highs, because getting all your infos and lows is actually a lot of data.
You're pulling out gigs and gigs and gigs of data.
One of our customers, when they do a tenable export, it's something like 80 gigs of data.
And they go back to us and say, hey, it's taking a long time to get this data out.
Yeah, we're waiting on Tenable to give us the data.
That's how it works.
It's 80 gigs of raw data.
And that's compressed.
Decompress is 230 gigs of text.
So it's a lot of data coming out of it, but it's really valuable once you have it, because you can do a quick wrap-on and say, great, find me everything running Zookeeper, find me whatever happens to be.
Whatever happens to be.
If you can just dump the cache of all your network devices, or even your printers, they'll actually tell you about... they'll snitch on all their friends.
They'll snitch about everything else in the network.
You can get a list of, like, do I have a Huawei device anywhere in my environment?
Even if you don't see it directly, you can see it in the cache of a neighboring switch and say, yeah, there's a Huawei box over there.
I can see the Mac prefix over there.
That tends to be a really useful technique as well.
Another one of my favorite tricks is Google Workspace.
It has this concept of endpoints.
And you would think, oh, manage endpoints, et cetera, Chrome OS.
No, no.
Anytime you log into a browser and log into Google, it creates an endpoint for that browser login.
Anytime you install the Google Drive software, it actually does all kinds of cool stuff.
It actually uploads your serial number from your machine, all kinds of information about your assets.
Almost like an MDM in that sense.
Just by installing the Google Drive software.
So, if you're running Google Workspace, go dump your endpoint data.
You actually get a lot of really valuable stuff.
You can say, are any of my employees running Google Drive in a machine that we don't support?
Does this inventory in the serial numbers in my Google Drive export also match my CrowdStrike serial number inventory?
Where do I have gaps in my inventory as a result?
So, that's been really helpful as well.
Of course, DHB, DNS, anything on the network side that gives you a list of MACs and IPs that you can cross correlate and say, am I bone scanning this?
Is it part of any of my mitigation programs?
Is it part of my security controls?
And then there's some really less obvious stuff that's hard to find.
You have to build your own tooling for it to get it out or use the things we wrote.
But these tend to be indicators of use.
So, there's a really cool feature, I guess, in SMB2 related to the session ID.
So, unlike SMB1, when you negotiate SMB2 or SMB3 session, you negotiate the session ID.
It's like a 64-bit value.
On Windows, and actually Windows, Samba, and even the SMBD on macOS, it's basically sequentially incremental.
macOS used to leak the kernel base value as well from it.
And there's a bunch of other related security vulnerabilities around this stuff.
But the really interesting thing for me was not only can you hijack other people's sessions on Windows and disconnect them.
So, you can break a file transfer just by guessing someone else's SMB2 session ID and then trying to hijack it.
You can't actually hijack it, but you can cause other systems to fail to finish whatever it's doing.
But anyways, that's a bit of a tangent.
The cool thing you can do about it, though, you can see whether anyone else talked to that SMB service since you talked to it last.
You can get kind of a rough counter out of it.
So, if you're trying to scan the network and say, okay, do I have any Windows machines that are hanging out there that no one's actually logged into in some period of time, you can actually look at the SMB session ID from Nessus scan one, Nessus scan two.
If the number hasn't changed very much, you know you have an idle box.
It's changing a lot, and this one's really logging into a lot.
So, same thing with the SMB counter.
You can look at your switch port counter and say, has this been talking very frequently?
Is it actually involved with the network traffic or not?
And there's a thing called DCRPC RPM, which has all kinds of great things you can dump out of it.
The endpoint mapper has a list of, you know, does the machine have a Wi-Fi card installed?
Is it running McAfee?
You can get all kinds of cool stuff unauthenticated on DCRPC.
So anyway, let's skip ahead because we're a little bit short on time here, but the short version is you want to take all this data, use it to build a detailed model of everything in your inventory, aggregate it all together based on IP, MAC, whatever you possibly can,
host name.
Don't worry about it too much, just get it someplace.
Get into a sim of some sort, get into Elastic, get into a local database, even just a big CSV file you can grab.
Those are all great things.
You want to track, like, what type of data is on the device?
Who's the owner of the device?
What hardware is it running?
What subnet is it part of?
What host name is it part of?
Like, all really useful stuff for when things hit the fan.
And then typically, if you are not currently in the middle of a crisis, you want to go shake out all the easy stuff.
Go find all the things that are... it's a managed asset, but it's not running one of your MDMs or EDRs.
That's pretty straightforward.
Okay, it's a machine that's on my domain, but it doesn't have CrowdShark installed.
Let's go fix that.
That's straightforward.
You can also look for, do I have any assets anywhere in my estate that are not part of my vulnerability scope?
That is surprisingly common.
And oftentimes, when you, you know, you're a brand-new employee, you go into an organization, they say, hey, we want you to run a vulnerability management program, here's a spreadsheet of our subnets.
That's all you get.
You have to either trust that or go find your own subnets, right?
And if you just stick with what IT gives you, they're gonna be missing lots and lots and lots of stuff.
And it's really common for your vulnerability management to be missing, like, 40% plus of your infrastructure.
And that is not even an exaggeration.
It's pretty common.
Find all your end-of-life stuff.
You've still got XP out there somewhere.
You've got Windows 7.
You've got some HMIs hanging out.
Figure out where they are.
Another great one is you can generally ask a Windows machine what domain it's part of.
And if it says it's not part of your main domain, well, you know it's unmanaged.
So a really straight way to do that.
Lastly, outliers.
So finding the weird stuff.
Like, a really quick way to do this is just sort your list of things, whatever your things are, coming from CrowdStrike, from your bone scanner, whatever it is.
Sort it based on OS or hardware or something else.
And look at the bottom of that list.
Look at the long tail of it.
And typically the long tail will be indicative of risk as well.
We've got a research report coming out in a couple weeks here that talks about...
we've looked at 680,000 assets.
We took in bone management data from, you know, all the big bone scanners.
We also looked at how different those devices were from their peers within the same site.
We found there's a direct correlation from how weird it is to how risky it is.
So typically the less of a thing you have or the more different a device looks like compared to its peers in the same network segment, the higher risk it has.
And it's really predictive and a really strong correlation.
So we'll talk more about that in a few weeks once we release the report.
But we thought those were really interesting.
So generally anything you see a one-off of or only a couple of in your environment, you typically want to go like pour gasoline on and burn it down or at least put it off in its own little network and keep it separate.
Those things tend to be unmanaged.
They also tend to be really expensive and really valuable.
So, you know, you only have so many AS400s and they'll stick out like a sore thumb pretty quick if you look at your list of OSs.
So the goal of all this is you want to be able to quickly respond to emerging threat.
You want to say, hey, there's an actually exploited vulnerability in some product.
I want to go find all the things that have that technology installed.
That is the goal here.
How quickly can you find all the things that are affected by some new emerging thing?
The quicker you can answer that question, the less chance you're gonna be affected by a breach.
That's just it.
So here's an example of like policy secure, connect secure for the more recent Avante, Pulse secure VPN endpoints.
Secondly, okay, something did happen.
Like you want to figure out what was the blast radius.
So in this particular environment, what could they talk to, what's exposed, what's available, what's like you need to know a lot about the environment to figure out what the blast radius was of a breach .
And the more data you have beforehand, the better you are to respond.
And that's pretty straightforward .
It also makes it really easy to kind of manage your exposure in general.
So the idea is you want to take whatever your favorite database or similar choices, Elastic and FileBeat, Neo4j , Postgres, Splunk, you name it, shove all your data into it.
It doesn't have to be particularly structured in a particular way.
As long as you can correlate it and scan it or grep for it, that's great.
Own it by your security teams.
Your team should own managing the data.
But give everyone else access to it.
Make sure the IT team, make sure your networking team, everyone else can query this data and have them rely on the data for their own day-to-day stuff.
Because that's going to give you a lot of ammo when it comes to maintaining it and getting information and help from them.
So, of course, you can build your own thing, you can buy your own thing.
Most products that you buy are really turnkey if you're small to medium size.
If you're a large organization, you're always going to have some mix of buy and build.
I can't tell you, almost every major bank I've talked to, they've already got a massive internal version of this.
They've already got their basic internal show din running.
That's a conglomeration of a bunch of commercial products and internal stuff that open source that they mush all together to be able to do this exact process.
So, this is actually a really common model that's already in place today.
And typically you're going to buy stuff and build stuff and that's kind of how things are.
So, of course, doing all this is tricky.
If you have ever set up an Elasticsearch cluster, the key thing to remember is it's going to fall over automatically in about two weeks.
That's just guaranteed.
So, you got to make sure you have sharding in place and you drop your indexes in a certain interval no matter what.
Otherwise, it's just a time bomb for the next person to do it.
So, make sure you kind of structure all this stuff to have the right size for your scale.
And, of course, share your data.
Monitor the ingestion.
Make sure you're actually pulling stuff in and it's not falling apart.
Give dashboards for the teams.
And it's pretty easy to be the hero for exposure management in your org just by building this out with data you probably already have.
Lots of cool stuff out there.
You know, I work on a product and we've got a free version, of course.
You can sign up for that.
We've got like 30,000 people using it for their home labs at this point.
It's a lot of fun.
So, that's run zero.
You can also get similar things from a lot of your bone management vendors these days that typically have something.
And then the open source side, lots of cool tools.
So, CISA actually has their own tool called Crossfeed, which basically takes data from like dozens and dozens of different sources and puts it all in one place, which is really cool.
So, I really like that CISA's been sponsoring that.
Jupyter One is a commercial product for doing cloud security.
Semi-competitive with us, but they also have an open source tool called Starbase, which is the way to take all the data from your environment and throw it into a Neo4j graphs database and search that.
Ivray is really cool as well from Droids Corporation.
And Axiom is also a really neat tool for kind of building your own attack service management tooling around this stuff.
So, these are some pointers for it.
If you ever want to build your own stuff and want to chat about it, please reach out.
I love talking about this stuff and I'll talk about it all day long.
But yeah, thank you very much for your time and we're going to have a minute or two for questions.
Okay.
Yeah, question was, what's your hot take on the XE backdoor?
That's what I spent all last weekend on, so it's a lot of fun.
They got really close to owning almost every Linux distribution and even Linux kernel.
They were like days away from getting code into shipping into major distributions.
We just got really, really, really lucky with it.
Unfortunately, like, it's not just like one little component that holds the entire stack.
It's about 1,500 components hold the entire stack.
And as the debbing maintainer said, there's thousands of people out there who have no oversight who can put code into the distribution at any given point in time.
That's just how the world works for open source.
So, I wish there was a better answer for it.
That one was a particularly difficult one to scan for as well, given how it was implemented.
It wasn't like a straight backdoor, network socket opener, things like that.
Cool.
Awesome.
Well, good on stage here.
Thanks again.
Have a good day.