Transcript
Hi Mike Matchett with Small World Big Data. We are back talking with Spektion today. We are going to look a little bit deeper under the hood at what's going on with vulnerability management. There's a lot to really dig into here, especially as the world evolves from a kind of a static perspective of let's look at our vulnerabilities from a scan ad to a dynamic, more runtime kind of a discipline where we're looking for vulnerabilities as they emerge from the behavior of all our new AI written software. Just hang on a second and we'll get right into it. Hey, Joe. Welcome back. Uh, we it wasn't too long ago we just talked, uh, but, uh, you know, tell us a little bit about, uh, again, just to remind folks what Spektion kind of does at the high level. What what are we talking about? What's what? Vulnerability management software. Bill materials just set the stage for us. Sure. Yeah. So Spektion , you know, a runtime vulnerability management platform, which means rather than just relying on CVS and derivative like intelligence to understand the vulnerability risk of software, we're actually looking at the runtime behavior of software as it executes mapping that to insecure behavior. And, you know, attack vectors as defined by CWI and miter attack. And then using that as a more comprehensive view that's upstream of CDs and then enriching with CVS when you know some when it's applicable. Okay. So the traditional just just we've got some folks here who are not necessarily all security experts. We talk about CVEs. Those are the critical vulnerability exception reports, blah, blah, blah, where people have documented that there's something that needs to be patched generally, that there's some problem in either a well known software or open source software or operating system and state of the art, up until, you know, recently has been get the list of I don't know how many of those are out there. Thousands, tens of thousands. Hundreds. Hundreds of thousands. It's always, always been a best effort. It's essentially, Mike, when you know, a security researcher or the vendor themselves, or a lot of times for the most consequential vulnerabilities, an attacker actually discovers an exploitable flaw in software, right? I mean, if you think about some of the most notorious ones, uh, it's because they were being successfully exploited. And, you know, there's a public breach reporting about it. Right? So, so generally, people have tools and solutions that can access these lists of published CVEs, and then they go and they do an inventory of all the software they have in their environment or think they have in their environment. Uh, and look for uh, overlap. Right. I've got the software bill of materials, and I go N levels deep into all the packages and uh, and say, here's, here's all the CVEs that would apply. Uh, and then what does that come up with that comes up with, like what? You know, a list of patches that someone has to make or most of. You described it pretty accurately. Mike. It's a correlation exercise between any of the tools that are doing this. They will look at the software they see installed, which sometimes maybe won't be all the software. Given that there's a lot of software that runs that isn't installed, but then they'll say they fingerprint it by version, they'll map it to CV, right? Which is like, you know, it's from the government from NIST, right? It's the common vulnerability enumerator. And they'll say, oh, okay. And then it'll output a list. This system with this software has these CVEs. Uh, they'll typically use cvss, the common vulnerability scoring system. Uh, they'll they'll ascribe severity to it. And then there's other layers of enrichment around how likely it is to be exploited or whether or not it's already been exploited. But essentially starting with software, going to CVEs and then triaging based on various measures of severity. All right. So in the security team at a decent sized enterprise, there's somebody who's doing vulnerability management or vulnerability risk assessment. And they're looking at these lists of CVEs that apply to them. Uh, how many, how many? How big is their list and how how dynamic is that changing? I mean, at a at a large enterprise, it's in the tens of hundreds of thousands. Of CVEs that apply to them. Of CDs that apply to that organization. Yes. Everything running on their systems. And then that team will, you know, they'll work to prioritize. There's going to be various system and application owners. Sometimes it's a job in and of itself just to find out who the application owner is that's responsible for addressing the CVEs. And they'll provide some form of prioritized patching guidance. And most of them, whether externally imposed by regulators or just internally imposed through their own policies, they'll have like an SLA. Hey, for this severity of vulnerability, we need to be patching this within this amount of time. And that could also be informed by other factors like system criticality. But the base, uh, not The base factor is the CTE severity is defined by the common vulnerability scoring system. And people run an awful lot of software. I mean, even if they wanted to patch it, they just can't. It's just not good. They're managing patches for it, right? It's just if we could patch our way to security at scale. I don't think that third party software would still be one of the top causes of breaches. All right, so let's call this hole deep and getting deeper. All right. And so you come along and you said, oh we got to take a more dynamic or aggressive approach to this. We'll get into that a little bit. Uh, and it's it's a runtime kind of perspective. How do you approach doing risk management at runtime? Yeah. So I mean, from a technical perspective, it requires you to one understand everything that's actually running on systems and then actually looking at the behavior as it executes, not just so that you can see more than what would maybe downstream be captured in a CV. Insecure behavior that's exploitable or if not exploitable itself, would increase the blast radius and impact of exploitation, but then also identifying what doesn't matter. You know, a lot of software is, for lack of a better word, kind of bloated with a lot of components that have vulnerable functions. Uh, they have CVE software inherits those CVEs, but the vulnerable but the the vulnerable functions that the CVS refer to may never be called in the software. Right? So it creates a kind of FUD. And it can also kind of it can kind of create like invalidate or maybe make less credible the vulnerability management teams reporting to technology teams where they're like, hey, this is never even used, but it's still being reported, right. This vulnerable component. So, you know, if you want to be more comprehensive, but you also have to be incredibly accurate. And so taking a look at the execution behavior of software is how you do that. Because it's going to be all signals because you've actually seen it doing this in the environment. And so when we look at specs, when you are looking at the actual operating behavior of the application. You're you're you're observing really what it's doing. It's saying you're calling out what are some of the things that might call out just to give an example. Things like, hey, um, you know, overly permissive access to credentials, insecure certificate management, um, insecure memory management of software, things like that, things that are commonly attributed to, you know, some of like the, I would say, more notorious vulnerabilities that get reported. Right. So it's kind of like it's kind of like a detective standing there going, you know, you, you know, hey, it didn't write the permissions properly or it didn't, it didn't do the right communication or it didn't set the right security bits. And so we got to call that out and maybe we got to do something. Okay. Uh, so this this thing, this is running, but this is also, I mean, just naively, I'm going to think this is going to create also potentially tens of thousands of runtime things that need that could be addressed. How do you what do you how does that help the person go from a list of CDs Yeah. Otherwise it's just more problems. I would. Probably. Say that the teams were trying to help. Uh, don't need to know about more problems. So if you think about right now, all these teams have too many problems because they have more CDs, uh, than they can actually prioritize and push out and and then balance that with prudent risk management. So what we do by going upstream is a couple of things. One. We're actually showing you risks that are, you know, uh, that if you address them are going to scale to maybe addressing multiple risks, uh, multiple CVEs. Um, but we are also providing scalable mitigations. So there's insecure behavior that could result in a CV that can be prevented from being exploited by certain controls. So we'll provide configurations, we'll integrate with their existing security tools, uh, and IT tools to provide configuration changes that would prevent the exploit ability of the risk. So now you can say, hey, we don't we'll patch of course, because we still have to patch typically because there's a compliance burden. But this specific risk has been nullified by preventive controls that we've implemented. And in some cases where preventive controls can't be applied for whatever reason, will provide detective controls that can integrate into your EDR sim. So you say, okay, well, at least we can shift left in our detection and response capabilities, right? All right. So so this is this is a kind of a decent point. So if you can't if you can't if the the team can't fix or address the problem. So it doesn't happen, you guys can recommend a way that their, their existing security tooling can detect that it's being something's being exploited. Right. You can mitigate it proactively. Right. This is this is like okay okay. That's right. That's how you actually get proactive. Right. Um, and a lot of these controls can scale. I mean, if you think about it from an attacker perspective, you know, if you're the CIO, you know, you're you're the latency. And your patching cycle is my opportunity to successfully exploit you. Right. So we you know, if you're going to if it's going to take you two weeks to patch, you want to be able to mitigate as much as possible in those prior two weeks and do that at scale in a scalable way. Right. You can't do it like on a one off. And just being told that the problem still exists. The problem? That's not useful. You actually want to say, is that problem being exploited while I have it right? What's the exploit ability? Yeah. Yeah, exactly. I mean, because otherwise all you're hearing about is the thousands of vulnerabilities that aren't yet fixed, and you feel like you're living like, like under some sort of Damocles. Yeah. Yeah. Well. That's interesting. Um, so, uh, tell me a little bit about, um, you know, the, the approach you're taking because I grew up in a, in a world of system management where we do a lot of monitoring, we do a lot of and we often considered monitoring to be kind of reactive. Uh, and, and even though we're looking for that, looking for exploitation starts to get proactive. Uh, but, um, how how do you. How did you guys come to that perspective and how do you really aggressively tackle that? Yeah, I mean, well, we came to the perspective because we actually dealt with multiple third party security breaches from our time working in enterprise security. So third party software was a vector we had dealt with a few times. Uh, we recognized that the traditional vulnerability scanning approaches were just too little, too late for us when it when the CVEs actually mattered. But my co-founders, you know, are hardcore red teamers and, you know, recognize that theoretically, how would you get ahead of this problem? Well, you would red team or really purple team software at scale, right, to include things that are outside the scope of CD discovery. And so that's how we built the technology to essentially take a look at the behavior of software such that if I gave it to a red team, they would feel like I just gave them a cheat code to exploitation, uh, of the system where the software is running. Right. I think that's that's really an interesting shift to taking that perspective, just at a large scale from from being sort of a reactive monitoring, looking for things that are going wrong. To saying no, I'm proactively an automated automatically going to attack my own system in so many ways and look and really take that approach. I think that's. We see that with a lot of there's, there's, you know, you're starting to see kind of pentesting as a service and a lot of things that are doing it at the perimeter. What we're not seeing are things that are doing it at the software layer. Okay. As a more meaningful representation of like the vulnerability risk. And that's what we're doing. Right. So really, uh, providing, uh, almost threat level kinds of views of what's going on. Um, let me ask let me ask you sort of a question on, uh, deployment of this and effort to get this going. What is it? What does it take to start to, to do this, this kind of active? I it's a sensor based technology. So it has to be deployed on systems, uh, with the software that you want to monitor or the software you don't know you have, but the system you want to monitor, uh, for, you know, typically the thing that, you know, bites you is the thing you don't may not even realize you're running. Um, but it's a passive sensor. It doesn't change state on the machine. It doesn't require any configurations. So it's essentially, you know, like on windows or, you know, just it's an inting job or some some of our customers deploy it through their EDR sensor deploys. It sees all the software installed as well as all the software running that's not installed lists it. It listens. Think of it almost like a span rather than a tap from a network perspective. Except it's on the endpoint. So it's you know, we've we've seen, you know, you know, deployments, you know, in the many thousands that, you know, 15 minutes and customers are up and running okay. If someone wants to then uh, Joe was sort of getting down here, uh, dive a little bit better, a little bit deeper, look a little bit under the hood as to what you guys are doing. Uh, doing more research. Uh, what would you recommend? What kind of learning path would you. Yeah, I mean, I highly recommend going to our website Spektion.com. Uh, there's a number of good resources there that explain what runtime vulnerability management is not as an alternative to seed based vulnerability management, but is kind of a, you know, a larger in scope way to do it, but yet with more efficacy. And then if they're interested in learning more, they can reach out to us through the website. Of course, they're welcome to reach out to me through LinkedIn, um, and learn more about the company there. All right. All right. So I think this is really interesting. I think this has, uh, some, uh, future here. I think, you know, people who are doing the as we might have mentioned, off screen, you know, sort of the GRC kinds of activities are going to say, hey, why aren't you doing why aren't you doing this? Why aren't you being more proactive? Why aren't you being more aggressive in looking for your vulnerabilities instead of waiting for things to go get hacked and exploited, right? So I think that's got a future. Um, so check it out. I think I think there's a lot going on here, that section. And, uh. Uh. Thanks, Joe. Thanks, Mike. Always great talking with you.
