Flashpoint’s Brian Martin on Finding and Identifying Hidden Vulnerabilities

This is Textron tv. Hey everyone. Welcome back here to techron tv.

You know, I'm really happy to have this next gentleman on, uh, on our show today. He is, uh, well, he's of an age where, you know, I, I came up in security over the last 25 years, and there was a group of us that kind of hung together through those years. And, you know, many of 'em would've done great things.

And, and this guy, heres one of 'em I want to introduce you to. Brian Martin. Brian is a, the vulnerability historian at Flashpoint.

So Brian, welcome to Tech Drunk tv. It's great to have you on. Thank you.

Great to be here. So, Brian, I, I'll, I'll confess I've never interviewed a vulnerability historian before. How does one, how does one become that?

Um, yeah, I'm, I'm probably the only one in the world. It's a, uh, title taken on pretty much by myself with support from Flashpoint. And, uh, the more you describe it, the more it makes sense.

And basically with any database where you're aggregating information, vulnerabilities, in our case, uh, you are recording the history of those disclosures, right? So, yes, very simply, vulnerability historian, it kind of speaks to that. But it also, uh, gives a sense of age, which I am, I began collecting vulnerabilities in one form or another in 1993.

So I've got a good amount of tenure doing this. And over half of that was running, uh, formal vulnerability databases. So between all that experience, I think it kind of speaks to that title.

Absolutely. And, and we're gonna jump into the history of vulnerability and vulnerability databases. 'cause I'm old enough to remember before we had CVEs and Criticalities and all of that stuff.

Right. But while we're talking, you mentioned, you, you're with Flashpoint. Flashpoint is a, I think, a firm company that, uh, our audience is somewhat familiar with.

But, you know, let's not make assumptions. Just, if you don't mind, give them a little flashpoint kind of background. Sure.

Uh, flashpoint is basically a best in class threat intelligence firm, uh, with some recent acquisitions. That portfolio of intelligence has broadened considerably so that they brought in vulnerability, uh, data breach, history, tracking, physical security on top of all the regular ones that you're familiar with, malware, you know, IOCs, IP threat actors, and all of that. So it really is kind of a great blend and compliments each other.

And with our new portal, it really brings it all together so it's all consolidated and easier to go through and navigate that information. Absolutely. Very cool.

io Io, excuse me. Yep. Excellent.

All right. We've got that out of the way. So, Brian, I, I mentioned, you know, when I first started still secure was 2001, 2002.

Before that, I was with a company called Interline. We had managed firewalls and stuff like that, but we didn't really have, I mean, MITRE was around, right? And, and nist, the idea, I mean, a lot of people were grading criticality of vulnerabilities kind of on their own.

And it wasn't necessarily, I mean, I was gonna say, was it a bad system? Yeah, it was a bad system, I guess in retrospect. But what was nice about it is you got to make the call on how critical a vulnerability was based upon your own environment and your own needs and your own risk tolerance, right?

I, I think a lot of us lost that when we went to the, the, you know, CVE criteria, uh, you know, for critical, major, minor, all that stuff. And, you know, and all of a sudden everything that was critical was critical across the board. When sometimes critical is not critical.

Why don't, if you don't mind, we're going to pick your brain as a vulnerability historian here and go back before there was that kind of uniform, uh, grading system and so forth, Right? So, uh, people that maintained a list of vulnerabilities go back into the eighties, uh, predate Mitre and CBE, which was 1999, and it wasn't until years later where NVD started providing the CVSS scores. Yep.

Um, so yeah, along that way, excuse me. Along that way, we, uh, basically had to go from, well, there's a handful of vulnerabilities. We can manage that, and the risk and everything to that every increasing amount, right?

And every year that, that amount went up by thousands or tens of thousands, right? We need a more formal system. CVSS came in then, as people noted, it's like, well, these scores don't apply to me.

Okay, we'll give you temporal, we'll give you environmental, which is more specific to you. Um, but then now organizations are, they expected to actually do their own environmental scoring on almost 100 new vulnerabilities a day, right? Right.

So it becomes very time prohibitive, um, to try to use those systems. And we are desperately in need of something that looks at it a little better than that. I, I agree.

I mean, I don't wanna let the cat outta the bit 'cause it's your story to talk about these hidden vulnerabilities you've uncovered. But I mean, I, I think that the, just the sheer number of vulnerabilities is, first of all, it's very hard for people who aren't in this space to get their head around how many vulnerabilities we're talking about. Number two, it's even harder if you're sitting at a desk trying to figure out how the heck can I do environmental grades?

How the heck do I stay on top of a hundred new vulnerabilities a day if I have, you know, somewhat decent sized, uh, network and how many nodes and so forth. Um, you know, you wanna talk about big data and automation being needed, this, this, this cries out for it. 'cause how the heck are we supposed to stay on top of these things, Right?

So with that many vulnerabilities coming across your desk, you really do need some kind of filtering system on the client side, unfortunately. And that's where they basically say, well, of these 100, only 50 pertain to our organization. Well, there's your first step in triage, right?

And I know it sounds real simple the way I describe it, and I know it's a lot more complicated on the organization side. But number two, then you have to say, well, these 50, which of those are critical? And you can start with the CVSS score, but unfortunately, one of the things a lot of people don't realize is that part of the CVSS specifications say that if you don't know the impact of the vulnerability, you score it for the highest.

And that actually causes vendors to give more grief to their customers. 8 for V three, right? And now that official, and it wastes more time.

So it goes back to that traditional, you know, 30 plus year, uh, debate about vulnerability disclosure. How much do you disclose? Well, if a vendor's not gonna disclose the impact A-C-V-S-S string will do.

Now that actually gives us the impact. And it gives us some of the, you know, attributes of it. But it allows us to oftentimes put the risk where it really belongs, right?

Because if they just come across as well, we've fixed the vulnerability. Well, if it's a cross-site scripting versus remote code execution, big difference. Right?

So yeah, A great, it still boggles my mind, you know, 'cause I, I'm going and still secure. We rolled out VM at, I think it was 2003. I'm trying to remember how many known.

I think if I said a hundred thousand at that time. Do you think that sounds about right? Back in 2002, 2003.

Much, much lower by that point. By that point, we were probably talking 10 to 20 at most. Uh, because cv, well, at least according to CVE, right?

Right. CVE was only around for two years, and they didn't, that's true. They did backfill prior, but basically only for certain advisories and specific vendor advisories.

Right? So there's an incomplete view before their start point, and then you have two years of them working. And that was primarily off of the big disclosure points at the time, which was bug track, right?

Right. Yeah. Yeah.

That's right. Yeah. Now the synapse is a firing.

I haven't heard that name in a while. It's crazy. Brian.

Let, let's jump into to really the topic of discussion today is that you recently put a blog up on the Flashpoint blog, uh, that you know, the company, and I'm gonna imagine it's, you know, you heading this, uh, project has found, identified over a hundred thousand hidden vulnerabilities beyond, you know, that don't have CVE numbers per se, or, you know, beyond what CVE reports tell me. It's not true. Well, it is, and worse, they're not act they're not actually hidden either.

These are all publicly disclosed. So they're out there somewhere and part of the job of a company like ours is to go out and find them. Right?

And that simple approach, you're, you're probably thinking, Hey, that's logical. However, CBE does the inverse. They wait for people to go to them.

So you have to be aware of the program. You have to either be a CNA or a researcher interested in getting a CBE e ID to, you know, affect change on their database. So using that difference in approach over, at this point, almost 20 years, uh, over a hundred thousand, right?

Wow. And we've got even, uh, right now it's actually over 101,000, um, maybe have just topped 102, but we know of a lot more and we're working on the resources to go out and find them. So I, I guess I gotta ask if a tree falls in the forest question, right?

Okay, you found all these vulnerabilities. Number one, which ones, how do we know which ones we should worry about? Number two, why don't they have CVE reports for these or CVE numbers?

And number three, what, what, what, what, what's a person to do? What's an org to do? Right?

So, uh, part of it is that someone has to know about the CVE program or care about it. And because of past issues with, uh, MITT and C cbe e some developers are just adamant they don't care about a CBE EID, they don't respect it. So you're always gonna have that blind spot, right?

And if there's no incentive for them to go get the cde EID, they're not. Um, so it really kind of speaks to, again, that methodology and that difference, uh, between the two that determine how complete that database is. And one of the questions that I get asked almost every single time is, well, of those 102,000, how many do we care about?

Not all of them, but we have over 350 vulnerabilities that were identified as being exploited in the wild at time of discovery, right? In our database. That's not in CVE or not in csec kev, right?

Um, so again, that kind of discrepancy, even if it's only 300 you care about, right? But it's not, we actually have the considerable amount of vulnerabilities in Cisco, Microsoft, Oracle, Adobe, apple, all the big vendors, right? Some of them not so severe.

Others, oh, very severe nine point threes context, uh, dependent or user assisted code execution, sometimes remote code execution. There are vulnerabilities that every organ, uh, organization needs to be aware of. And then as far as what they're to do, that's where we're kind of in this dark ages of vulnerability triage and response.

Because there is overwhelming information and there's not consistent, usable and programmatic, uh, ways to manage that risk on a per vulnerability basis and then line it up with all the assets in the organization, right? It's hard enough for these organizations to even gather an asset inventory of 20 or 25% of what they have. So to take all that vulnerability data, uh, data and map it, that is a great solution, but it's extremely challenging as well.

So don't throw anything at me, but can we use AI to help with this? Um, that's a fun question because if you asked me, say six to 12 months ago, I'd be very optimistic. Oh, look at all the gpt, look at how fancy, right.

And then cost Of LLMs and all that good stuff. Exactly. And within 12 months, what are we doing?

We're linking each other memes about how bad they failed or how they disclosed private information or how one, uh, GPT all it did was query another to get its training data, right? Um, is it possible, maybe I am professionally a skeptic though, if we are going to use it. I don't think it's gonna be tomorrow, right?

I think there's gonna be a significant time before you can reliably use it. Um, I would love to be wrong on that. And I do believe that with a proper data and training set and methodology to train the GPT, right?

Sure. I think that, so-called ai. I, I don't like the term, um, you know, spicy auto complete, but I wish that it would, uh, be that focused.

And then I do think that they will, uh, Alan just disclosed this vulnerability. It scans, it looks for keywords, it looks for context, uh, it examines any code snippets, right? POCs, all of that, and comes back with not only a summary, but kind of a confidence report.

Like, wait a minute, this POC, it's not gonna do anything related to the, you know, vulnerable function that he called out. There's something going on here, right? Right.

Um, where right now it's just more institutional knowledge on our side about which researchers, which vendors we can trust more than the others. Uh, learning their quirky little languages, uh, that basically kind of say, well, we fixed a vulnerability, but the wording's real fuzzy. You could interpret a lot of ways, right?

Over time, we get to learn all of those, right? And so that gives the first, first level of kind of helping add clarity and, uh, perspective to a disclosure for someone who doesn't look at 'em every single day. com and, and my time at Security Security Boulevard, I don't see how without some sort of automation or AI kind of, you know, motion, I just don't see how, forget the average organization.

I don't see how any organization can stay on top of this, especially at the rate of new vulnerabilities coming out, Right? And, uh, one of the things we do is we track data breaches. Right?

Now, not all data breaches are caused by external hacks, right? Uh, there's internal, there's accidental, whatever, but there's a considerable amount and we see 'em in the news every single day, right? New organization, pop, how many millions of records lost?

What are those records? Oh, this is bad, right? Um, with the increase in organizations getting compromised and then also determining, wow, they've been in our network for two years, right?

Uh, it's certainly a challenge. Um, I think that we really have to kind of shift left, so to speak, and go back to the developers and companies writing software need to incentivize them to write secure code, not just get features out faster and faster, right? More and more companies, more just regular citizens.

We're caring about security now. So that should become a marketing point. Yes, we do have secure coding techniques.

We do follow these standards, right? Um, but I think if the developers were given more time and allowance to audit their own code to use more automated code scanners, any other tools like that, then absolutely. That's where we're gonna start seeing more secure software.

Um, yep. com is, the reason I first got involved with DevOps is I thought it would be a better way for security. Um, but you know, you learn interesting things in practice that sound good on the drawing board.

But so here, here's things. I think we have an industry, at least in what we call DevSecOps have learned there. I don't believe there's a developer out there who raises their hand and says, I like to write crappy code.

I like to write insecure code. They all wanna write quality code given, but, you know, they all face realities, deadlines and everything else. But the biggest lesson, and I think a lot of the early DevSecOps companies learn this, is you can't expect a developer to be your security guy and by guy, it could be a gal or whatever you want to be.

I'm not playing that game, right? But you can't expect the developer to be the security person. They could be a security champion.

They could give a crap about security, they could do what's best, but we need to give them tools that are not written for the security person per se, but that are written for a developer to use, right? In their IDE running automated scans and trying to correct stuff at, at that spot right there, right at the time it's committed to a, a repo GID or whatever, right? And, and correcting it right there.

Obviously we wanna get as many bites at the Apple to try to find crappy code to find vulnerability, vulnerable code prior to deployment. But the developers are oftentimes the highest paid people in the it, you know, kingdom we're throwing automated testing at them, development doing, you know, shorter times security. Now, I just, I don't know how realistic it is to think that they're going to be security, more security conscious or as security conscious as we need them to be.

Right? And that's where I say the organization needs to give incentive and they need to give training. They need to give them the proper tooling of course.

But then basically some way to say, Hey, we acknowledge that in the past 12 months you have written code that's had no public vulnerabilities disclosed against it, right? Here's a bonus. Right?

Something. Well, that, that's, I mean, that's market driven, right? Real capitalism at its best, best.

We'd like to see it, you know, you'd like to see it. I think the other thing is, you've gotta remember that so much of what we consider developers coding today is developers playing Dr. Frankenstein and putting together body parts Yep.

Third party libraries. And that's, uh, honestly, another deficiency. Um, in CBE for example, uh, there's just a lot of developers that don't even know about the program, right?

And so they don't know to reach out and their users don't necessarily, um, or oftentimes the users, all they care about is getting the security fix, damn the rest of the world, right? I only care about me. Yep.

So, um, yeah, it that kind of blind spot. Um, and that's actually where kind of the, uh, a large chunk of the data or the, the drive was early on is we actually read through the SBOs of major tools, um, the license agreements that, uh, you have to publish, like, uh, in Adobe Reader, for example. And at the time, that was over 125 libraries, and that was back in 2011, right?

So if there's vulnerability in those and Adobe's not aware of it, it could impact them. And yet you have that obvious chain. So you're right, a hundred percent, um, need to focus there, but also be aware of all the actual threats, not just that limited picture.

Agreed, man. Agreed. Brian, we're probably over time, I, I apologize for monopolizing your time here on this, but all Good.

I appreciate it. I, I appreciate it and I think our audience appreciates it. What could we leave 'em with, right?

Leave them with something on the upswing. What could they do? How could they interact with you guys?

How could they be better? Um, for organizations out there, you have a lot of influence with your vendors. You're giving them a lot of money and you're getting great product.

I understand. But when vulnerabilities come out and they aren't patched or not patched quickly enough, you need to go to the vendor and say, Hey, I'm an unhappy customer. And tell 'em why.

Give those vendors more incentive to be more responsive, to have proper triage. A proper P cert team stood up. Um, be willing to interface with security researchers, right?

Help get them in the right mindset that all of this works for the greater good. And it starts with that pressure that a vulnerability researcher doesn't have that we don't have because we are kind of a third party player in that system, right? But the organization that's paying them, you can start to make those changes.

Cool. Brian, thank you so much for coming on today and kinda talking vulnerabilities with us. And keep up the great work.

Come back and visit us again. Right. Anytime you'd like, come on and, uh, you know, we could talk more about this.

It's, it's interesting. Yeah, I'd be happy. A lot of great stories.

Yeah. Oh yeah, there is. I'm sure, you know, maybe we could put together a little panel maybe and really kinda go through this stuff.

Alrighty. Brian Martin, vulnerability historian at Flashpoint here on Text Drunk tv. Thank you, Brian.

We're gonna take a break and we'll be back in a moment with some more information and news.