Transcript
of the Product Talk Podcast. Just Steph and I today on the pod have a really exciting topic for you all though. We're gonna be talking a little bit about some of the history of vulnerability research and data dissemination and how that's changing moving forward with kind of the struggle of NIST and what we're doing about it on the Audamox side of things. So it should be a great discussion today. Welcome Steph. Hi guys. Excellent. So Steph while being the co-host of our podcast is also one of the primary people kind of running the show with this project. So should be a great discussion today. Let's go ahead and jump in. So current state, I wanna just roll kind of set the stage here before we jump into the actual product discussion. So for most of you IT and security folks listening you probably pretty familiar with CVE and what it is, right? It is essentially a number-based categorization to discuss different vulnerabilities and it's typically a piece of software when we're talking about it from Audamox's perspective, right? Like one of our capabilities as a product is to patch and remediate configuration and software-based vulnerabilities. So CVEs for us and the folks that use Audamox are typically specific vulnerabilities with a score associated to them that talks about how severe that vulnerability actually is, right? There's a lot of different stuff. I would recommend reading up on CVEs if you've never heard of them before. It's a very common term used across IT and security. If we dove into it today, there's quite a bit there actually. But for the discussion today at the highest level CVEs are really just a way to categorize and bucket specific vulnerabilities typically on a piece of software for our context, right? So those get a number typically CVE dash and then the year and then another dash with another number and they get a score associated with them. And that score is essentially a benchmark of a lot of different factors but ultimately what it boils down to is what's the likelihood of this being exploited? How easy is it to exploit? And how bad would it be if it was exploited successfully, right? Something like a CVE that allows you to remotely execute code on a piece of software or device is a lot worse than a piece of, or a CVE that maybe causes a denial of service when it's exploited, which obviously both are bad but remotely executed code can be a lot worse especially if it's on a crown jewel device like your Active Directory server or a business critical database. So that is the foundation for the discussion today or CVEs. Anything you want to add there, Steph? No. That I missed? You covered it. Sweet. So as you know today, if you're an AutoMox user, right? Like a lot of how people patch and remediate vulnerabilities is based on kind of a combination of things, right? In AutoMox, a lot of folks are using CVEs along with any other component of their vulnerability management program to prioritize and then remediate a patch or configuration based vulnerabilities on their system softwares on the operating system software or within specific like third-party applications, for example. So for these, you can think of things like Chrome or Adobe, et cetera. That is a decent method, right? A lot of people are trying to remediate these critical vulnerabilities within 24 hours or less. And then ones that are maybe less critical or a score below like a three out of 10, they may remediate within 30 to 60 days, maybe even longer, depends on the organization. Having as much of this data available is really important because when you're using your automation to actually go and fix that stuff for you, a lot of the time you're dictating kind of those automation policies based on the severity of vulnerabilities. So when that's missing or when it's incomplete, you're typically probably missing that stuff if you don't have a really comprehensive patch policy set up to kind of catch all at the end. Automox has pretty much always had severity data for operating systems that we cover. And relatively recently, we've been adding data for third-party software applications. So, you know, Chrome, Adobe, Oracle, stuff like that. We've really, I think we've covered less than 10 for a few months now, but as you may know, if you're a user of Automox, we patch, we can patch over 500 applications with Automox. So it's a pretty large delta. We, you know, grand reveal here, but we're doing a lot of work to bridge that cache now with vulnerability data for, I think, the majority of those applications, correct, Steph? Yep. Yeah, what we're working on will provide coverage for all of our third-party supported apps, which is, you know, 500 plus. Nice. Yeah, so I didn't do the math beforehand, but, you know, 10 or so applications up to 500, that is a lot of percents of improvement. So really exciting there. But I think where the story gets even more interesting is how the vulnerability reporting and data landscape. So a lot of the stuff that helps us to number and then understand the severity score and disseminate that severity score out to pretty much the entire US and beyond relies on this. It's really changed over the last couple of years. What I'm alluding to here is NIST, right? They are, for a variety of reasons, very, very far behind in their vulnerability classification and scoring. I don't know if you know how many years behind they are, but it's a significant backlog. Yeah, yeah. And that's part of, you know, they've struggled with, you know, reduction in force, struggling to keep staff. And as a result, they've just gotten more and more behind. And the longer that happens, you know, the more uncertain, that's who everybody has relied on, right? For a really, really long time. And I think companies like ourselves as part of our strategy when we're looking at this, how do we continue to provide this vulnerability data, but you don't need to know about a critical vulnerability six months, you know, you don't need to know about this kind of stuff after the fact. How do we keep our data as current as possible? And how do we look to sources outside of NIST that I think a lot of folks are going to given the current landscape and how much they've struggled to keep up with the volume of data? Well, Peter, I'm just going to go into it. That kind of brings us to Audimox's kind of strategy as a whole, right? And like I said, how do we overcome these challenges? And what we have kind of decided to do is to partner with Von Check. And the reason for that is it's more than just more real time, maybe CVE data. And we're moving to more vulnerability-based checks because they give us more data and how to evaluate real risk in the real world, right? So it's more than just, here's the CVE, here's the scoring associated. We're going to get all this other metadata that follows in more real time, right? That's their whole job. That's what they're staying up on. And we can start exposing things like Kev data. Is this exploitable in the wild? All while tying that for Audimox to your specific device and what you have installed right now and what you need to install, right? So we'll be able to tell you, hey, on this particular device, you are vulnerable to these CVEs. And if you installed this patch, here's what you would remediate. Here's the criticality behind that. And then we can start introducing even more, like I said, metadata that accompanies that. Like, is this on the Kev list, right? To help you prioritize and make sure you're taking care of the most critical things. And then with Audimox, you do that in an automated fashion, right? You go with your policy and either a severity policy or one that targets by severity. And so you set that up, you have a data source that is complete and up-to-date and you have these policies. It really helps you keep a handle on those critical and high vulnerabilities without being a time suck on your end. 100%. And there's a lot to unpack there. I think the first thing is if you've used Audimox before or if you haven't, like getting this information, even if it's just the score is big, if you have a basic vulnerability management program or if you have no vulnerability management program. But I think the additional metadata fields that will be coming in will be really important. The first one that I wanna focus on is actually Kev. Cause I think that's, you know, compared to when I started at Audimox, probably almost five years ago now, like Kev was a concept really, I don't think it even existed or it wasn't popular at least. And it's become, as we talk with customers, like a pretty big focus for a lot of leadership teams is understanding, do we have Kev vulnerabilities? And if we do, how quickly are we fixing them? So could you just give us a quick overview of what Kev is and like where it comes from and why it matters? Yeah. So Kev, it was stands for known exploitable vulnerabilities and it's a list that's published by CISA and it tracks vulnerabilities that are confirmed to be actively exploited in the real world, right? So it helps you, you can have a vulnerability that exists that is, you know, severe or critical, but this takes it a step further to say like, there's actively people out there exploiting this, right? Like this is something that you really need to pay attention to and take care of as soon as you can. 100%. And it's sent, I mean, it essentially represents like your probably most pertinent stuff to go out and fix since there are known exploitations in the wild, but it's also actively being, probably quite actively being searched for, especially now that, you know, many real threat actors are utilizing like AI tools. They're probably reducing their time to kind of scan by quite a bit relative to what it was maybe three or four years ago. It moves the CVE from like, this could be bad to attackers are using this today and exploiting this today. Excellent. So that will eventually, I assume, lead to our ability to perhaps have some more nuanced automation policies within AutoMox around this stuff. But talk about, you know, we cover 15, 20 plus operating systems and distributions of Linux. What, obviously we're starting with third parties here to kind of bridge the most critical gap, but what is our plan for operating those operating systems that we cover today? Yep. So like we said, we're going to start with the third party and then we'll start moving our operating systems over to using the Vauncheck as the data source. So we'll go into Mac next. You know, Mac is something that NVD is always behind with Mac, right? Like it takes them a long time to have those vulnerabilities. So we're going to focus on getting Vauncheck hooked up for our Mac OS. Then we'll focus on Windows. Vauncheck also helps with the supersedence issue, right? Like it does a really good job of tracking that. So we'll be able to more cleanly say this patch, you know, supersedes this one and tracking which vulnerabilities are actually being remediated by the patch that you're installing. And then we will move on to targeted Linux distros, right? To kind of round out and make sure that we are holistically supporting our customer base no matter what they have installed on their end points. Awesome. And I know that, you know, I'm assuming we've kind of run some numbers on what things will look like once we have this in place for third parties. What kind, for those folks that are listening that maybe are active AutoMox customers or have used us before, what sorts of improvements in coverage should we anticipate from this change? Yeah, so we actually have run the numbers and we are looking at getting from this first pass with a third party 70% coverage across our supported apps. And coverage will be greatest, right? For your more modern CVEs. So CVEs from the last five years will have greater coverage than these older ones. And that's partly due to, like I said, the source Voluntech and the data that they support. But something that I think is really important that we're doing is, okay, we get out this first round, right? We get 70% coverage, which is really good across that many apps. And what you will see is we're going to build in some auto sampling of our data, right? So we can go and look and see, if say we don't have coverage for something, why is that? You know, where is it breaking and how can we improve on that? So we're setting up a system that's going to improve over time, right? So we have this big 70% splash and then quietly behind the scenes and proactively without customers reporting, hey, you know, I don't see this missing data. We'll be able to improve that over time. Awesome. And probably a million dollar question that I'm sure many will ask is when should we expect to start seeing this rolling out to folks? February 25th. Wow, awesome. So if you're listening to this after the release, let us know how it's going. Let us know, you know, what you're seeing and how it's helped you. Obviously this'll, I imagine, flow through into all of our reporting as well. So there should be a lot richer data on the reporting side of things from a third party perspective. Excellent. Super exciting. Thank you so much for joining us today, Steph, and we will talk to you all in March. ♪♪♪
