Prioritizing Vulnerabilities by Financial Loss

Hi, everyone. " A little bit old home week today. I'm happy to have two of my friends from the, way before we called it cybersecurity, from the InfoSec world, joining us.

Well, if you watched them here before, you know who they are. Jeremiah Grossman, Robert Hanson, and of course, they are now with their company they co-founded, Root Evidence. Jeremiah, Robert, it's great to see you.

Hope all is well with you both. Always great to be here, John. Thank you.

So Robert, does anyone call you RSnake anymore, or are we too old for that? Yeah. No, I'd say about half the people I know still call me RSnake.

And even people I meet now call me RSnake, so it's just like- Well, they're just by reputation. They're just by reputation. No.

There's just too many Roberts, so it's just easier to say RSnake. Yes, there is that. There is.

There's really very few Jeremiahs. There's the bullfrog. Of course.

The funny bullfrog. What you don't know is, it is actually my handle. Really?

Mm-hmm. There you go. So guys, all kidding aside, both of you have very storied careers in cybersecurity.

Jeremiah, at a very, very young tender age, was the head of Yahoo Security back when Yahoo was the shizzle. Yeah. And left there to really help define the AppSec industry with White Hat Security.

Robert, or as RSnake as a lot of people know him, he's probably one of the most famous, for lack of a better word, hackers, c******s, security people in the industry. I've known Robert also, I think since around 2005, something like that. Yeah, I think so.

That sounds about right. Long time. Yeah.

Mm-hmm. Long time. Jeremiah as well.

And you guys have worked on other companies before, right? Wasn't there a company, Tenable? Sorry.

Yeah. We've certainly been found Tenable, one of our other startups. No, but Tenable acquired one of your companies.

Oh, yeah. We were at- I know Rahul did Tenable. Yeah.

We've interviewed you, as we were talking offline, I first interviewed you around Root Evidence a little over a year ago. Mm-hmm. And then I think we caught up around Black Hat time this year.

But for those maybe, not everyone watches every "Techstrong TV," as much as I hate to admit it. Let's say they haven't heard about Root Evidence. What would you tell them?

We are in the vulnerability management space, but we do it very differently. Our focus is on financial loss, not necessarily finding and fixing as many vulnerabilities as possible. So what we do is we look at what vulnerabilities the adversaries not only use, but that lead to financial loss, and we get that data directly from the cyber insurance carriers because they have the best data in the world as far as actuarials.

We get that data from them in terms of CVEs. Those are the vulnerabilities that we focus on, scanning companies, so we'll scan the entire perimeter, every single asset that they own every single day. And the idea is that if they only just fix those, which is not something that everybody has done yet, but they should, the odds of having a breach and financial loss as a result of a vulnerability is slim to none.

Agreed. Well, easy for me to agree, but I think it's still something that is contentious in the industry, right? We've been trained in what I call Yellow Pages vulnerabilities, right?

Where you got your vulnerability report, and, well, half the people out here don't remember what a phone book looks like. They weren't around when a phone book was out. But your vulnerability report used to look like a phone book, and it was really thick, and they judged the quality of your scanning by how big a phone book you had.

And at some level, I guess it was job security. But guys, Mythos, AI, whatever you want to call it, has changed the game here a little bit. Because clearly, we now have the ability to find even more potential so-called vulnerabilities than ever before.

And I was actually talking about this on "Techstrong Gang" today. We never caught up to the amount of vulnerabilities we had before Mythos. Many plus.

Yeah. What makes you think we're going to catch up now? Actually- That's really...

Go ahead, Robert. Yeah, I was going to say, there's something important here that I think a lot of people are totally just missing the boat on. So Jer's going to talk about one aspect of it, but I want to talk about a different one first.

When you say it's finding a lot of vulnerabilities, people have no idea how many vulnerabilities it's finding. They're not even in the right ballpark of how many it's finding. The estimates I'm hearing from people who have access to it, it's finding on any given project that they throw at it, between 500 and 1,000 times more vulnerabilities than they'd ever found on those projects using all the other source code analysis or whatever they were previously running.

So if you'd find a million vulnerabilities before, now you're finding a billion. Like wildly larger numbers, you know what I mean? And I have noticed, because we're tracking the CVEs over time, it's not going up by 500 or 1,000 times, which means the vast majority of the vulnerabilities are not turning into CVEs.

Now, is that because they are not CVE-quality vulnerabilities? I don't think so, because that's not how CVE works. I think what's happening is they're bundling a whole bunch of vulnerabilities, and they want a CVE, is one thing that's happening, or they're waiting for the vulnerability to be patched, and they don't want to tell anybody about it.

It's fair enough. A lot of people do that. But I think the scariest one is that people are putting it as part of an update pack as opposed to a patch for something, a patch pack.

So if you don't download the upgrades to give you cool emojis on your phone or whatever, you're not getting all the updates that are going to patch you from all those vulnerabilities. So I think that basically everybody who has access to Mythos is lying through their teeth. I think they're finding wildly more CVEs, or things that should become CVEs, than anyone realizes.

So we haven't even begun to see what the real damage associated with this thing is. I mean, in terms of workload, and processing, and what customers have to do downstream associated with the things that it's finding. We're just seeing the very smallest tip of the iceberg.

It's grown by whatever, 30, 40% since last year. That is not 500 to 1,000 times more, which is what it should be. I agree.

I think there's a couple reasons. I think you hit on some of them. And I'm not going to get into the whole political thing, but we've kind of kneecapped our processes and infrastructure that we had around, like with MITRE- Oh, sure ...

and NIST and all of the things around- But that's not a problem. I mean, I know these guys. You think that's not it?

No, they could easily create the CVE placeholder. They're not doing it. I think they're just not being submitted.

Right. I know they're not. So Jer- That's scary.

It's scary. Jeremiah, what do you think? Yeah.

One thing to keep in mind is that we had the backlog for a long time, and as you mentioned earlier, we're just going to have a bigger backlog. What seems to be the case, and there's two lists to look after. One is the KEV list, the known exploited list.

One from CISA KEV, VulnCheck we're big fans of. And if you notice, the list of exploited vulnerabilities remains flat over time in terms of total numbers, but the percentage of vulnerabilities that are being exploited is actually falling. It's just a denominator problem.

So that means the problem we had of prioritization before remains and gets worse over time. Which ones do we actually fix? It ends up being two problems.

We're not going to be able to scan for every vulnerability anymore. There's just way too many. And we're not going to be able to clearly not be able to fix every one.

So now we are in a world where we have to very efficiently figure out which ones to scan for, to even look for, and then even more narrow which ones to fix. And that's the problem that Root Evidence, and that we're laser focused on that one. Because we don't see the adversary scaling up, innovating in terms of exploitation.

We see them scaling on the what they're already exploiting. I get it. I think it calls another question into discussion as well.

When you say fix, what does fix mean? Yeah. You could say fix is remediate, remediate is fix, but what does it mean?

Are we patching software? Are we insulating things? Are we blocking something?

There's a lot of ways to skin this cat, but what does it really mean? " It could mean patch, like you say. It could mean remove the vulnerability from the internet.

What I'm trying to get after is anything that prevents the adversary from actually exploiting stuff. It could be remove the box, patch, reconfigure, remove the app, or whatever the case may be. It's all game to keep the bad guy out.

What about what I call, and I don't want to use the word, but the half-assed kind of fixes, where, well, let me just isolate it now until I can get to it. Yeah, I guess you could, in a case of a web application firewall, you could Band-Aid it like that with a web application firewall. All those are fine.

We don't take a real strong position on is temporary okay, how long is temporary for us, how you remediate, how fast. It ends up being business decisions at the end of the day. So yeah.

So let me bring it back to the money, because it always comes back to the money, right? Well, it should anyway. We said it in the beginning.

Jeremiah, I think you said it, right? That Rude Evidence is kind of prioritizing vulnerabilities based upon financial loss- Yeah ... or potential financial loss.

That itself has proven problematic over the years. How do you put a dollar, what's the blast radius in terms of what's it going to cost? It was harder before, because you imagine vulnerability management came out of a world of a lot of guessing.

We didn't know who the adversaries were. We didn't know what they were targeting. We didn't know their skill set.

We didn't know what vulnerabilities they were using. We didn't know anything. So the only thing we could think to do at the time was scan everything for everything and patch everything.

That's where vuln management came from. Over time, we got more telemetry data. We started getting breach and incident data from the carriers.

We have a general sense of who the adversaries are, how they monetize, what vulnerabilities they would use. So we actually have the data to be more narrowly focused. So if we say, "This vulnerability here seems to go after the retail sector, the healthcare sector, and when there's a breach, the average loss is this amount," we can actually start tying very particular vulns to loss amounts.

That's the loss amount. What we don't know how to do yet, that's just going to be more on a case-by-case basis, is that when we report that to a customer, how much does it cost them to fix this vulnerability? It could be $10, it could be $10 million.

Maybe it costs downtime. That's not something a third party can know. What we can help them go is, "This vulnerability here has a high likely of causing, in your business, a $5 million loss.

If it costs you $100,000 to fix it, that's probably something you should consider doing. " So for us, it's enabling the customer to make those dollars and cents decisions rather than us making it for them. Like the CVSS scores, the red, orange, yellows, those don't work anymore.

It's just dollars and cents. Not that they really did ever before. I was just going to say, Robert, I think the whole orange, yellow, red thing was a little kids game.

Yeah. Right? Red light, green light.

Yeah. And it was totally inofficial. And it sounds like that in the boardroom too, if you think about it.

Can you imagine being a CISO and walking up and talking about your grades, or red light, green light? Like, oof. Yeah, but you want to know- In the same conversation, they're talking to sales and marketing, who have return on marketing investment, what KPI is around sales, and we're walking in with letter grades.

Like, oof. That's bad, man. So let me play devil's advocate.

The flip side always was, well, the board doesn't want to get into the bits and bytes of security, right? Yeah. That's correct.

No. They want an economic risk. Yeah.

That's right. And so red, yellow, green, or orange, yellow, red, or whatever was... I once did a panel on this at RSAC.

Do we need to dumb down our security for the board? It's not- Right? Mike Rothman was on that with me, I remember.

Mm-hmm. I think it's the other way around. We're not dumbing it down.

We're actually putting it in business terms, finally. They don't care what the CV number is. They don't care if it's in Linux.

They don't care about any of those things. How much is it going to cost me, and what do I get for it? That's not dumbing it down.

That's actually making it relevant in a business decision context. Right. Return on security investment.

I mean, it's like- "So this vulnerability here, or this set of them, if these were breached, and these vulnerabilities have been used to breach others in our sector," says this insurance carriers, "If we fix those, it would retire 5 million, 10 million, whatever million dollars at risk, and it's going to cost us three days and 100 grand to do it. " And we can do that now. The data exists.

I agree with you. I've been working with another cyber company who actually is a similar kind of-- They're looking at blast radius in terms of financial damage. Mm-hmm.

Right? And they look at it in terms of containment and stuff like that. But a similar mindset, which is this is what the board understands.

Right? What's my exposure in terms of dollars? Not what if somebody- And anything other than that means you're effectively guessing.

Yeah. And the bad news is there's a lot of areas we're going to have to keep guessing for a while, just because the data doesn't exist yet. It's not like we can fix the entire industry all at once.

Unfortunately, we can only tackle what we can tackle. But I think this is a trend line that we have to start building. " We're going to have to come to grips with the fact that the board doesn't understand any of this stuff, and we're relegated to the little kids table.

I was at a conference, I don't know, a couple months back or something. " And most of them said 10 minutes once or twice a year. It's like, what are you talking about?

Either you matter or you don't matter. And basically, what the board is saying is you don't matter. They're voting with their attention.

I agree with you. If that's the only time you're getting on board time... Look, I've been a part of executive teams in the past, right, and I know this quarter we're focusing on sales.

Next quarter's marketing, next quarter's engineering, right? So I get that piece of it. But I think security's risen to the point where if I'm a board member, I want to get a risk exposure security reading at every meeting.

Mm-hmm. I would. Right.

Am I making progress or losing ground, right? If I could just start there, it would be a good start even, and dig in from there. Not the least of which because cyber insurance has become compulsory for every business now.

You must get it. And you don't want to be put in a position where you had a breach where you can't get insurance, or the premiums go way up. That's going to be a business ender.

Imagine not being able to get cyber insurance and trying to get a deal done. That's not where you want to be. No.

I don't even want to go there. I could tell you stories. But that being said, let's return to Rude Evidence, guys, because we're over time, and I got to bring this home.

Sure. First of all, for people who want to get more information about Rude Evidence, where do they go? com or on LinkedIn.

Just look for Rude Evidence, and we post a ton of content all the time, and it will be very different content than the rest of the industry. So I follow you both on LinkedIn Have for a long time. So I do.

I'm up on what you've been, at least what you post on LinkedIn. Mm-hmm. Secondly, I know you guys are working really closely with cyber insurance carriers, but for companies out here, they got to go check what cyber insurance carrier they have before they work with Root Evidence.

You don't really need to. You could just go to Root Evidence. Yeah.

More importantly is you're getting information from the cyber carriers. That's right? Yeah.

We're getting actuarial data. We want to know what actually works. We don't find a lot of value in finding and fixing vulnerabilities that the adversary doesn't care about.

We want to solve a problem here. Just fixing a bunch of vulnerabilities that no one cares about is not value. That's something else entirely.

We want to start solving problem management already. Let's talk dollars and cents. People out here want it.

So how do you charge? We used to charge how many nodes I scanned, how many active- Yeah ... vulnerabilities.

We do it on a per asset basis. Yeah. So it's asset based.

Yeah. And then we have different levels of a warranty that you can purchase, and so it just depends on what level you want and the price goes up a little bit. Let's talk about that because- Yeah ...

guys, that's something I know we spoke about, I think it was this past August for Black Hat. Seems like it was a year ago. It was months ago.

You guys offer this warranty. There's real dollars behind the warranty. Tell the audience a bit about that.

Yeah. So I'll take the first pass, and then I'll hand it to Jer. But yeah, it's $1, 3, and $5 million warranty, depending on which level you feel like you need.

We wanted that number higher, actually, but there's some board-level things that need to be done on the cyber insurance side, not on our side. The advantage of doing it this particular way is we basically have a feedback loop with the insurance providers. So now we actually get faster data than waiting for the insurance provider to give us information, if that makes sense.

So, it can be a handful of days have gone by in a vulnerability, and we'll get the information as opposed to it being like, whatever, weeks or months potentially. So it's a really nice feedback loop, and some people may not want to trigger their insurance policy for a variety of reasons, but they will trigger us, so we'll get better telemetry than the insurance providers. Go ahead, Jer.

I know you wanted to dig another one. No, you nail it. Well, what I thought Jer was going to say is, the reason we can do this at all is because it's the insurance provider's data.

Yeah. If you think about it, they're not backing us. They're backing their own data.

Obviously, if you really understand how warranties work, they're always a bad bet. Like they're always a guaranteed bad bet, because otherwise, why would you take the bet? Like you know where the risk is, and so you bet against the risk, right?

And who better than insurance companies? Right. You don't see many of them going out of business because they make bad bets.

Right. Well, unless you're in Florida, here where I live, but that's another story. Right.

And to quickly wrap here, and so the choice from the customer perspective is do you prioritize on the basis of red, orange, green on some mystical model from some vendor, or you prioritize on the ones that cause actual losses from someone that's actually paying out on these claims? Which one do you want to believe? That's why we went down this road.

I love it. Jeremiah, Robert, I got to end it up. Thank you so much.

You have an open invite whenever you'd like to come on and talk. For those of us out here, though, watching, hey, if you haven't checked out Root Evidence, go check it out. This is a different take for a different time of vulnerability management.

We're going to take a break on Textron TV. We'll be back in a bit.