BSidesROC 2024 - Styrofoam in a Landfill - Jack Hatwick

I'm gonna introduce somebody who has I think now four handles that I'm aware of. Um, we have OJ, which I'm aware of. We have Jack, which I'm aware of. And now I have Odd Job as well, which is absolutely freaking fantastic. That is one that I actually didn't know, but I always had OJ. So, let's just say he's been creeping around this industry not quite as long as as a couple of us, but he's getting close to the gay head side of the world as well, which I'm actually very happy about. um and currently doing a ton of work in Fortune 500, 14,000, Fortune something lots, let's just say a bloody big company out there. So pay

attention because it's all about the vulnerability management side of things. Um a personal friend and somebody I've known for numerous years. So please please put your hands together for Odd Job OJ and Jack. [Applause] Awesome. How's everybody doing here? First Bides Rochester. Anybody? Yeah. All right. Cool. First Bides ever. All right. Fantastic. Well, welcome to the family. Uh, and you've got a bsides almost anywhere you want to go. Uh, you know, you can pick a destination. You probably get to do a B-side somewhere. Uh, it's um, you know, this is one of probably six or eight conferences I go to personally. I take personal time off to make sure I can come to some of these conferences. uh

work does not pay for this and work doesn't own my opinions here. These are mine. Um but when I was trying to come up with an idea for the the title of this talk, uh one thing that I was just kind of talking with someone about was, you know, CVSS scores and vulnerabilities and, you know, the the everchanging nature of what threat actors are doing out there as far as what they choose to use to get in. Um, and one of the things I noticed was that, you know, a CVSS score once assigned pretty much never changes. And as a means of prioritization, therefore makes it actually really hard to determine whether that score is valid anymore

because see uh vulnerabilities go through uh a bit of change over their lifetime. So you have to re-evaluate them and it's almost like it just kind of goes into a landfill and lives forever and gets forgotten. It's styrofoam. So styrofoam in a landfill. CVS never changes. So uh a bit of a who am I classic uh little who am I there. Uh as as um Chris said, you know, it's Jack Hatwick. It's not my real name. My government name is something different. Uh, I use that one to just get around the marketing and uh, legal uh, folks at work. Uh, when I want to talk about things that I don't want to attribute to them. Uh, but Odd Job ZeroJ OJ, you can

call me different things, but uh, Odd Job is the uh, the handle of choice. Uh, and then of course I've been a hacker for like 11 probably more years. Uh, did this talk at Queen City Con, so uh, probably needs to go to a 12 at this point. Uh, I also host a YouTube channel called Glass of ZeroJ. Um, not an OJ, ZeroJ. And yes, I do drink a glass of orange juice, uh, every episode. Maybe a small one, maybe a big one. Um, but I talk about infosc, talk about, um, things that are going on or concepts or even some legal cases, some of the SEC stuff. Anybody following the SEC with uh, Solar Winds? Um, there's also some

interesting Defcon lawsuits going on. Uh, I go into those. I'm not a lawyer by any stretch of that word. I'm not a parallegal. Uh, and I make that quite clear. If you take your if you if you look to YouTube for legal advice, you're an idiot. Um, but I do at least read through the documents because a lot of what we deal with uh gets into those documents when we start talking about information security. So, I at least talk about what's probably going on based on what they put in those documents. Um, I'm a senior director of detect and response for a health company. Um, so not a huge company anymore, uh, I work for, but it is still

pretty sizable, uh, person in that industry. Uh, and then I also brew me. So, oh, we got some fans in the back. All right. So, so if you ever want secrets, uh, they're not really secrets. Uh it's mead's probably the worstkept secret because we it's been around for thousands of years. Uh by accident we discovered how to ferment honey uh just by leaving it out in the wild and getting it wet. So uh you know yeast kind of has has that effect on things. So and we've just been crafting it ever since. So uh it's really fun and it takes about a month. So uh and then you can find me on the socials. You'll see

those later as well. Um so a little bit of talking about today. We're not going to be trash talking CVSS. CVS has a purpose. CVS is misused and we're going to talk about that. But we're going to talk about the history of CVSS. It predates me in the industry by uh by a bit. Uh and how we deal with vulnerabilities predates me in this industry by a lot. Um we're going to talk about just the the drawbacks of CVSS, but how especially how we've been using them. uh and a new way to prioritize vulnerabilities, how you can start doing it without fancy tools, and there's some other considerations that I've actually added because of conversations I've had at this con. It's

always good by going last you have conversations with people and then you get to update your slides because you always find new information. But, you know, vulnerabilities, you know, back in the day, we just had we just had all kinds of uh issues with code. code at the end of the day. A vulnerability in code for instance, it's just a bug. It's a bug where and a bug is basically this this this software is not behaving the way we want it to behave. It's behaving unexpectedly. And of course, a bug that behaves in a way that uh compromises the security of that system or that that software. We call that a vulnerability. Uh and well, you know, people have been

patching those things and releasing new software, releasing little fixes from time to time. And so, you know, for a while we've just basically said, you know, hey, you don't want to get you don't want to get exploited. We'll just patch all the things. We patch all the things. You can't be exploited. You're all good. How many people in here can actually patch all the things? Okay. Sometimes in bigger audiences I get one person who raises their hand and it's because they've got some very interesting uh very niche setup to where they can actually uh you know uh essentially push code or pu redeploy their environment you know every day. So they're always updating they're always making micro changes to

their environment anyway. Um most of us don't live in those environments. Most of us don't work in those environments. We work in environments that are aged, not like fine wine or cheese, but they smell nonetheless. Uh, but it sounds easy, but can you keep up with change requests? Can you keep up with QA testing? How about applications breaking? How about all the limited people hours you have? Right? Especially if you're a global operation, you only have so many people in different time zones at different times who can do this work. and they have to prioritize and figure out do I push that new server today or do I go and fix another server's vulnerability. Um you have uh

you know endless reporting metrics. So while you're doing all this you're also reporting on all of the vulnerabilities and reporting on all this work as well. So you've got to take time from prioritizing and pushing out these vulnerability management requests to then say let's measure let's put all these reports together. Let's put a presentation on for people who have se levels next to their names and make them feel scared about everything that's going on in their environment. So that's security, right? We make people scared about their environment. Um, so you know, we we kind of just worked to patch all the things. Someone just released new software. We're going to patch it. Someone did this. We're going to upgrade

it. Well, we couldn't do that. Well, CVSS came in and saved us kind of, but it really didn't age well. That's a bad joke. Um, so what is CVSS? Common vulnerability scoring system. Um, and it's basically a vendor's sec uh severity assessment of a product's weakness. And that's how it started out. That started out as a vendor's opinion about how this issue with our code affects this system. and it may give you some insight as to how it might affect your system in your environment, but it's purely that vendor's opinion about their code and the way they see their system. Um, first of all, CVSS was developed in 2003 by the National Infrastructure Advisory Council, NYAK,

uh, back in 2003. Prior to 2003, uh, in CVSS, we didn't really have any scoring system that was uniform. You know, every company kind of had its own thing. A lot of people tried to keep this all secret. A lot of people tried to keep the fact they had vulnerabilities secret. We don't want to talk about this. We don't want to publish it. Sometimes we do. Um and so this one's a critical one, but this person says it's critical. Well, is one more critical than the other? Does does one measure it one way and it really should be a medium and this one that measured this a low should be a high? How do we know? we don't have

common ways of being able to interact with this and tell people here's how bad we think this is for our environment so or our system that we're developing with you. Um so NYAX basically uh NYAK created CVSS and launched it in uh uh or created in 2003 and launched it in 2005 with the forum of in uh incident response um security teams. So first, which first is who currently has CVSS as well. They maintain this. They keep it up to date and as you can see uh CVSS needed a little bit of an upgrade uh because um you know the the the vendors were kind of looking at this and as they were scoring they were saying you know

we really probably ought to bring some other considerations into this. So as the vendor adoption grew they started giving opinions as to how CVSS should score. Well, in 2007, while I was still in high school, uh they released uh CVSS 2.0. So, now we have some more reliable scoring. But back in 2015, I believe, is when it was either it was either 2.0, I've forgotten, but it was either 2.0 or 3.0 where they started introducing a threepart scoring system. You have the base score. Was it 3.0? All right. So, in 3.0, they released a base score, which is what we all know and love from from the vendor, but then you've got a temporal score and an environmental

score, and we're going to go into that. Uh, and 4.0 kind of keeps some of that and changes it uh as well. And that was launched back in November 1st, 2023. But there's other scorings that you have to do, and that's not done by the vendor, that's done by you. We're going to talk about that here in a bit because how does CVS work? Well, uh, it's broken down as you can see into a base score, temporal score, environmental score. Uh, you have the access vector. So, how how is an attacker actually able to get at this vulnerability? Does it require internet access? Um, you know, what do they need? How about the access complexity? Complexity is an interesting

thing because that's a bit subjective, isn't it? You know, this isn't an objective marker you can put on this. This is a little bit of this is going to be feeling or a little bit up to the vendor to determine what they think is complex versus not. Uh authentication, you know, does this require someone to have administrator privileges? Does it require anonymous access, meaning anybody? Um confidentiality, integrity, availability, you know, uh is this a DOS vulnerability? Well, it's probably not going to be a risk or a a a consideration as far as keeping things secret, making sure things don't change. it's going to be an availability vulnerability, right? So, they'll they'll score that part higher. Um, user

interaction, does it require a user to even be there? Hands- on keyboard to click something, a UAC prompt, enable macros in Excel, you know, what is the user's part in this um the privileges required and the scope and as well as if this has some kind of physical impact. Um, that's all that goes into the base score of CVS. So, when you see someone say, "This is a CVSS 10. Microsoft, you know, releases Windows a patch on patch Tuesday and says it's a 10." That's what they did to arrive at that 10 score. Okay, there's still more that has to be done. So, there's a temporal score and Microsoft can't do this part. Or I guess they could maybe,

but they don't. Nobody does. Um, basically this is provided by the end user organization. What's the exploitability of this particular vulnerability? Um, what's the remediation level? And this is no longer in CVSS4 by the way. Um, what's your report confidence? That's also not in CVSS4 anymore. Uh, do you believe that the reports about this vulnerability are accurate? Um, you know, one interesting thing is when Google, for instance, releases, oh, this is a zero day. uh you know something with our browser is is bad and people are attacking it. You need to go patch right now. Stop everything you're doing. And I go and I read and they won't give more details about what's actually going on with the

browser. Well, what is it? What part of your browser is causing an issue? What is the way in which this gets exploited so I know whether this is actually a true risk for my organization or not that I actually need to go and fix? if you don't give me enough information, that's a bad report. Whereas, you go back to some Cisco vulnerabilities that were reported and attacked back in the October, September, or August uh time frame last year. Talos gave you a full lowdown on here's the sample code uh that we're seeing attackers use. Here's how they're getting in. Here's how to determine whether you've already been popped, and here's steps to take to remediate. They went through and did a

really good job a line by line. here's here's everything to reproduce these these issues almost to the point where it's like okay that's too much but um it's that was a really good report and helped a lot of people in being able to determine whether need they need to address this now later or maybe it's already happened to them and they need to go find and and remediate this and figure out if further access has been brought in but that used to be part of temporal score temporal score these things can change over time you can get better reports about a vulnerability and what's going on with it you can get Oh, it's exploited. Or maybe there's a proof of

concept out there because Will Dorman decided to put, you know, some PowerShell script out there on Twitter and sure enough, you know, that you can with the right conditions, you know, get domain admin to something. Um, and someone then weaponizes that, goes from proof of concept and now this is something that's being used live in in the real world repeatedly in just scripted into malware to where now I don't even really have to pay too much attention to this. It's a very commodity, right? So, there's different levels of exploitation or exploitability and weaponization that's that's involved there. But that's temporal scoring. That's something you're supposed to be doing, by the way, when you receive those because as you change the temporal

score, that can bring a 10 down to a nine, can bring a seven up to a nine or an eight or a 9.5. Uh, same thing with the environmental score. Now this really gets into how does this vulnerability look in your environment. Uh again provided by the end user organization. Microsoft does not know every single environment out there and where this is going to be used. They don't know that you don't have SQL server exposed directly to the internet uh in the same subnet as you know other other critical systems like your maybe your AS400 or something. Uh you know what's the collateral damage potential? what's sitting around this thing? Uh what does this have access to

immediately on the network that it can get to? Um you know, probably domain admin if it's a Windows machine. Everyone's going to go for some kind of domain control. Uh target distribution, right? How much of this system exists? What's your footprint? What's your exposure to this? This is just one system on the internet, 12 systems internally. Uh you know, what is the target distribution there? Uh impact subcore modifier. Now we've jumped into Dungeons and Dragons, you know. Ah, your bird is going to sing. You must roll for charisma you know. So, uh, but basically that's based on the security, uh, requirements of the systems that are vulnerable. Is this a system we actually do need to keep up

all the time? It's availability system. Well, this isn't a DDoS vulnerability and I don't care about the confidentiality of the system or the integrity of the system for that matter. then maybe this doesn't actually matter as a vulnerability for that particular system. You may have other systems in your exposure you want to go chase, but maybe that system is not. So you can get scores for your environment. You can get scores for specific systems in your environment that go all over the place because you're supposed to be going through the temporal score and the environmental score. Now, how many of you knew you actually could or needed to rescore CVSS? One, two, kind of knew there was

some more to it, but didn't really dig too much into it. Yeah, most people don't know there's more work to do. Who's got time for all of this? Nobody's got time for all that. No, nobody got time for that. Uh, and then again, you know, like temporal score, that stuff changes all the time. You know, when's the last time Microsoft, which I'm sure they probably did it like maybe last month, they've been having a lot of problems with Russia, it seems. Uh, but I think uh I think Atlassian was the last one I really remember back in fall last year. Uh where right after they released some really bad Jira or there were some other really bad

vulnerabilities they had that were getting exploited in the wild. When they originally released it, I think they were released it at like like a 9 or maybe an 8.6 six or something and then once it started getting exploited they raised it up to like 9.8 or 10, right? But that was like a few weeks after or a month after at most. So that's really the window you're going to see uh you know anybody even someone as big as Microsoft really care about going back and rescoring their base score um inside we uh I think it was open was it open SSL that kind of had an almost a nothing burger of a hey we're going to release a

vulnerability and you you guys are going to want to be ready for this you got to wait a week though you got to wait a week and we'll tell you about this vulnerability and we're just about to patch here it's it's it's going to be wild but we can't tell you about it that. So now we're all sitting around bracing for impact. Every ISAC is having, you know, speculative briefings on, oh, here's something that it could be. We got to be ready. Go ahead and start inventorying and figuring out how you're going to patch this thing. And then when they come out and say, okay, by the way, we're downgrading this from a 9 like an 8.2 because we turns out the

configuration we're actually worried about is super uncommon in people's environments. So unless you have this very uncommon configuration and and and and have this feature enabled, it's no worry for you. And then we're just like, do you have confidence in that reporting, right? Uh OpenSSL lost a lot of street cred for that. And next time they blow the whistle, people are going to be like, we sure? You sure? Uh and that and that and that could be bad. But again, who has time for this? How can we actually how can we actually uh you know work with this? So CVSS did try to come to save us. And so what did we do with this? So

we got all this wonderful scoring. You know, we got this fancy scoring here. What did we do? We said, well, patch all the CVSS 9 through10s, right? Those are the criticals, the 9 through10s. You know, vendors saying that this is critical. We're going to patch it first. We're going to patch it urgently. That makes the most sense. But again, did you go back and do any of the temporal environmental scoring? Maybe some of those criticals were nothing burgers. Maybe some of the things that you thought were nothing burgers are criticals because the opposite can happen. You go from critical to a low. Maybe not so bad as a low, but I've seen criticals go to medium and I've seen

mediums go to critical when you modify those scores. Um, nobody does that. But then yet, that's all we seem to do. And even not just in vulnerability management in patch management itself these are two different two different processes in patch management I hear a lot where you know when you get into a patch meeting they go like that's patch Tuesday are there any critical you know vulnerabilities in Windows oh yeah there were two critical okay apply those too and it's like no please apply all the the the patches to the to the system we're going to discover why I want them to apply all the patches to the system. It's part of regular maintenance. Keep

your regular maintenance up. That's patching. Don't worry about the CVSS 9 through10s or or whatever. I'll tell you when something's severe enough, you should break your cycle. Um, but you should be just carrying on with that basic cycle. But yeah, we got so focused on those 9 to10s, we thought we were taking care of what was the most threatening to us. But that's not necessarily true. The problem really just comes down to CVSS never changes because we never go back and rescore it. So, this is an I chart and I'm so sorry. Um, what this is is this is data that I get by virtue of buying one of those fancy tools you can buy and there's

several fancy tools out there. Um, but they come with a a knowledge base of vulnerabilities and they come with uh different uh different characteristics about the vulnerability. Is it a part of ransomware? Does it have malware? Blah blah blah. So, I went ahead and said, "Well, here's here's an interesting thing. Let's take a look at the CVSS scoring and let's let's break out vulnerabilities that exist today." I actually was in the speaker lounge and uh so this is good as of today, the data that's in their database. Um how many critical high, medium, and low vulnerabilities do we have out there? And we have 34, let's see. Yeah, 34,414 critical vulnerabilities exist uh today that we know of that have been

reported via the uh CV. However, there are eight uh 84,700 highs. There's 101,000 uh mediums, there's 8,100 lows, and yes, there's even someformationals. uh you know there's like domain uh some kind of like NX domain exchange uh one that's a vulnerability and it's actually the only one that can that we know is exploitable today. So that's why it gets a one down in the next row. So then I said well that's interesting. Let me just go ahead and take a look and see the vulnerabilities that have some known exploit to them. This will be in exploit DB part of the CISA KEV. Uh it was a zero day. We know this has been used in

um in attacks in the past or there are published um exploits available for this. There's malware available for this. We know this is weaponized right through a very through a variety of means. Well, only 6472 of the known critical vulnerabilities according to CVSS actually have an exploit associated with them. Meanwhile, 19,000 of the highs are exploitable, 16,000 of the mediums are exploitable, and 888 of the lows. And then, of course, that one little cuteformational. Isn't it adorable all by itself? Well, that's an interesting thing. The uh the the the highs and mediums are starting to really outpace and outnumber the criticals here. Let's go one step further. What am I going to get with a particular exploit? Right?

Right? Because I can get different things, you know, whether it's a memory side channel attack, I can get buffer overflow, I can get remote code execution, privilege escalation. Those are two very hot button ones that everyone probably cares about. So, let's go there. Well, there's only 2,531 critical vulnerabilities that'll get you rcep out of the 34,000 vulnerabilities that are considered critical. Interesting. Now, of course, you know, if I wanted to, I could probably look and see which ones have DOS. If you care about DOS, you could also plug this kind of information in. But there are 5,557 highs that have RC, 3,900 that have RC on the mediums. Again, we're greatly outpacing now things that are exploitable and have

dire consequences to your environment. the mediums and the highs by themselves outpace the criticals and together they definitely uh overwhelm the criticals. So when we say we're going to patch CVS 9 through 10, you're missing these. Now how many have been used in the last 30 days? whether it's been used in an incident we know about. New malware has been developed. A proof of concept code showed up on GitHub. Will Dorman posted something on Twitter? There's been talking to dark web. 47. Oh wow. Critical now pops back up to the top. 47 of them uh actually do have some kind of recency to them. 17 highs and six mediums and no lows, no infos. Sometimes there's some lows, but

usually there's not. So, this is interesting. Why? Why do I bring all this up? This is why CVSS is not good enough. This is why paying attention to the nines and tens is not good enough. Because that number, well, let me get it. That number never changes as far as where we rate those on a CVSs. These down here always are changing. And these down here are always increasing. But if you never address these up here, then you're never getting these guys down here. Now, obviously, this isn't going to be a proper distribution for your environment because you don't have all the vulnerabilities known to the world in your environment. Hopefully not. If so, your licensing uh cost for

all the different software is really high and your procurement probably wants to talk to you. Um, some other information that's interesting is uh there was a Carnegie Melon study back in 2020 and they were looking at vulnerabilities that were published that year and they were looking at exploitation. What did attackers go after? What they found was interesting that within 30 365 days of publish back in 2020 or maybe it was 2019 they were looking back at only 4% of the CVS even got an exploit. Most of them were the highs and mediums. Something to think about is that when an attacker is looking at your environment, they're not running a Nessa scan. Well, they maybe are, but they're

not running a Nessa scan and saying like, "Oh, dang. I don't see a CVSS9 and 10, so I can just move on. That's the lowhanging fruit, right? No, they're saying, "Hey, cool. I've got some vulnerabilities here. Do any of them give me what I want? I want to get remote control of this system. Does anything give me remote code execution?" They don't care if it's a critical high, medium, low, or anformational. They just want to achieve their goals. And so, we've got to start thinking like an attacker because we're trying to attack the threat, right? we're trying to defend against the threat or we're trying to reduce opportunity for threats in our environment. And that's what

vulnerabilities really do uh amount to is an opportunity for a threat to take action in your environment um and take hold. So you know um sorry go back to my train. Yeah, you need to think like a tech because they're not looking at the CVSS scoring. They're looking at what does this give me? What are the outcomes that I'm going to take? These are tactics, right? These aren't numbers. These aren't scores. So, CVSS is not good enough. There's a better way. And we've already kind of charted out the better way to look at this or a better way. And there's also another way that I'll talk about here in a bit uh that first actually came up with which is called

exploit um prediction scoring system. So they have a lot of data on vulnerabilities, the characteristics of them, and what seems to be exploited more quickly than others regardless of their CVSS scores. Um, and so there's actually a bit of a movement to start moving towards EPSS for uh, you know, predicting, hey, you know, this this medium for Microsoft isn't, you know, exploited now, but you know, maybe in 60 days it will. So, we're going to give the score and vendors are joining uh folks like Rapid 7, Nessus, the rest of them are joining to try and keep those EPSS scores going to constantly change them. That could that could do something really good, I think. But right now, I

think we can still play this a little more simply, not have a bunch of math to do, and I think we can categorize our vulnerabilities a little better. Think about it. Is a VM without an exploit a threat to you at this time? Right? Because it could change later. Right now, it's probably not that much of a threat. A VM that doesn't give the attacker remote code executioner privileesque is that as big a threat as ones that do. Obviously, if you're care about DDoS on a system, then think about things that do or don't have DOS. Do those necessarily pose as big a threat as ones that don't? Are vones under recent exploit development and attacker usage more of a

threat than any of the above factors? Probably because that means activity at in your environment is probably more imminent, right? Not a surefire guarantee, but likely more likely. So, this is my new prioritization. I say it's mine. It's not mine. Uh there's an entire vulnerability risk management industry that's coming out there. I think they've now I think Gartner's now renamed them to CEM continuous thread exposure management. Regardless, it's just thinking about our vulnerabilities and our exposure in a different way. So my criticals now that I look at are those that are exploitable remote code execution privilege escalation have a recency around last 30 days. So again that malware that just got developed well with this new vulner with this

vulnerability well that's now a critical uh I I assign those roughly around 7 to 14 days to get fixed generally a sprint maybe two sprints if you're talking applications uh we can fix those they are also great candidates for emergency vulnerabilities actually and you should when you're prioritizing these types of vulnerabilities you should think do I need to make a big deal about this wake people up and fix this now rather than wait for the seven days. That's a great opportunity um above the other ones because again that recency gives it more imminence that it could uh be impactful. Uh again highs 30 days are exploitable rce um this is your normal patch cycles usually anyway is 30 days. uh in a lot

of systems, you know, you'll have a dev, a staging, a production environment. So, you're going to go one week, another week, another week, maybe a grace period in between, unless it's February because then you lose a date. I don't know how that works, but timing you usually goes that way. Um, so it gives you time to address those. So the way I usually do it is it's March. So what I would have done is I would have looked and seen, hey, did February what what do what do vulnerabilities that should have been taken care of in February look like? You know, just by normal patch cycle cuz I'm not going to go patch Tuesday and go, oh

my god, you know, crit fix now. Well, let them work their process. They have a normal patch cadence. So unless something's an emergency, I'm not probably going to bother them at that time. Um, I'm going to let their patch cycle go through. Okay, they missed their patch cycle and we're detecting that. Or maybe a patch just fails. Patches fail sometimes. Sometimes it updates the Windows will update its registry key and say, "I patched everything was fine." And then when you look at the version number or you look at the hash of the binaries that should have changed where the vulnerable code actually was, it's the same. Hey, if the hash is the same, the binary is the

same. It didn't update anything. Um, well, at least not the thing that mattered. So you need to go back and fix that. Secondly, do your vulnerability scans actually detect that kind of stuff? Some of them do. Some of the Qualis and Nessus ones do. Some of them just look for the registry key. So you might want to educate yourself on how your vulnerability scanner is actually checking to see if that code issue actually exists. Um but yeah, sometimes things fail for human reasons and technology reasons. So we go back and fix those. Medium. So these are just the ones that are exploitable. Um, you know, they're probably not remote code execution. Uh, there are other matters

that could end up with some memory leakage. Um, you know, heart bleed everyone said was really bad. I think nowadays it's probably not considered too terribly bad just because of how hard it is to really exploit that. Um, but we have seen actually some incidents from that. So, it is possible to uh to to mess with that. Um, but you know, we're going to give this 60 to 90 days. Now, the interesting thing here is think about a lot of the fixes for the criticals, especially among your more pervasive things like Windows, Adobe, Chrome. If you fix a critical, what's the fix for it? usually usually upgrading or setting up to the latest patch. There's going to be a cascade

effect when you start prioritizing work this way because there's going to be a cascade effect of apply this fix and now you'll have less highs, mediums, and you'll also have a lot less lows as well. So, it's almost kind of like this water this this pyramid waterfall where where you do a little bit of work up here and you start finding the work below disappearing. Um, so that's also kind of a a benefit of this. Now you can also do other considerations. You can say we're going to upgrade medium to a high if it's public facing because we just can't tolerate a public facing system having something we may not even give them remote shell. We still can't

tolerate that on the on the public facing. Um maybe the maybe the system houses confidential data and so even internally we don't want this uh to have uh you know these types of vulnerabilities on it. Uh think about the recovery time object of that system. How fast do you need to get that system back up if it does get hosed? Those you'll probably want to make sure get taken care of because there there's there's more risk to mitigate there. there's more there's more to maintain there from a resiliency standpoint. Um so those those factors could elevate a vol. You could also say this isn't internetf facing maybe we downgrade this because it's in an area

of our environment where we have other mitigations. We have other counter measures to help us offset this this risk score even further. So we'll downgrade it that way. It's really your pleasure. You can define how you really want to take this and add these other considerations and other dynamics to bring that score down or up as much as you want. And this is just a revisualization. So we go from here where we're just taking care of the criticals and then we may get around to highs, mediums, and lows to now saying these are my criticals. Now that's interesting. Now let's say you had all the vulnerabilities in your environment to work with. Now, instead of saying you have 34,000

issues to fix, I'm saying you have 80. That's a lot less work to have to do in two weeks. Now, you may get around to patching all the things because you're managing your work better. So you might go into your environment and you might find a lot of systems haven't been upgraded, patched 2 years, 3 years, four years, maybe can't be patched because they're 2008, you know, whatever. Um, but how do you how do you how do you get them back? Well, let's start here and let's take care of those systems and then we might get to the point where we're really keeping this up to date and we're keeping this down. Let's come back here

and really focus on the highs now. Oh wow, we're doing really well on this. Let's make sure we're prioritizing these mediums, too, and chasing after them. You're going to find this goes down, the backlog goes down, and you've got better hopefully patch. You're driving better patching processes via that way, too, because it's not just about the tech, it's about the process as well. You're going to find that you're going to have a lot better time keeping up with vulnerabilities themselves, which quite frankly, this has just wasted so much of our time and energy and investment and money when vulnerability isn't necessarily the thing you should be chasing in security. And we'll talk about that in a

second. So, how do you get started without fancy tooling? So um you can actually utilize PowerBI to collect all your scan results. You can also use Excel. Um I would use Excel more as a uh proof of concept just to kind of prove that this this renegotiation of criticality shows an impact. Um but what you're going to want to do is you're going to want to enrich your vulnerability data with information sources you have of you have uh your something you can get your hands on. You may not be able to afford mandate, you know, threat intelligence or, you know, some other things to enrich your data with. That's fine because we do have at

least some bare minimums like the CISKEV. We do have exploit DB. We do have metas-ploit, right? If there's a metas-ploit module for something, it can be exploited, right? It's probably also got an exploit DB um entry as well. But if it's on the CIC, it's not necessarily also in cool. So, what I would do is I would enrich that vulnerability information. So, that way you've already got your CVSS in there. You've already got your vulnerability, but now you at least know something's weaponized. And inside one of these, you'll also see whether this is actually a remote code execution or not. So, you can search for rce, you can search for privilege escalation, and you can have

another column next to each vulnerability that's basically a yes or a no. Is this a remote code execution or DOS, whatever you whatever you actually care about? And then recency, you know, the enrichment of this data. How recent was this? You know, did this just get added to the CISA KEV? Did this just get added to exploit DB? Did you know is how fresh is this information? Uh has it has it been posted? And so that can give you a start to recency. Again, this is without fancy tools. You don't have an entire team to do threat research and everything on the back end to really hone in on every single one of these. But other companies that operate the

fancy tools have that team. They have those things. Um, and it requires some work and skill at automation, but it really is worth it. But you can do it. So I would say Excel if you just want to prove the concept, but you can automation all automate it all up in PowerBI to where you can have a scan kickoff. You can feed that in PowerBI. populates, it enriches and now you know the you know the vulnerabilities you should probably be going after but you can buy the fancy tools too things like uh Ivanti neurons for riskbased vulnerability management where I got this information you can go to Kenna you can go to knapsack there's plenty plenty plenty of these tools out

there um I have one of them but I uh I I I don't I don't sell any of them so I don't make any money off of pushing it either Um, so another consideration, you're probably going to have to convince auditors this is okay because there's a lot of auditors, Mr. PCI in the room, uh, who will go, "Whoa, you've got a CVSS9 through 10 here. Uh, why haven't you patched that?" Like, that's not okay. Well, it might be okay according to your policy, according to the way in which you've said you're going to fix these issues. Um, and I find that conversations with auditors go well when you're not just doing this, but you've

also put it into your policy. You've got a clearly stated standard or process that is being followed, and you can show evidence of it being followed, and you can show the results of what's going on. You're going to be 90% of the way there to convincing an auditor that this is okay. It took a while when EDR came out, LLM be uh based EDR to replace signaturebased AV. It took a while to tell the auditor, "No, it's okay. We don't keep our AV up to date because there's nothing to keep up to date. There's no daily definition list. There's no there's no none of this. we have now, you know, the ability to, you know, look at a file and know based on

an LLM model whether it is actually uh malicious or not. It took a while to convince auditors of that, but it is possible and you're going to have to do something similar here. Uh CVEes aren't the only vulnerabilities. Those are just software bugs that are getting tracked by vendors. Uh you've got misconfigurations, maybe even mal configurations. Maybe someone's popped a back door in your environment. You don't know because they wanted to work one day uh from home uh and they didn't like uh your bosses didn't like that. But CVS aren't the only vulnerabilities. There's misconfigurations, just insecure configurations out there. Once a attacker gets in, they're usually I won't say they're usually, but they're not a lot of times popping CVES the rest

of the way in. They're usually taking advantage of the fact that, you know, you you have overly permissive user accounts. you have uh the ability to uh you know work in um uh you've have you have cached creds of a domain admin on the system. So they're taking advantage of those types of weaknesses in your environment. And we get so stuck on just the vulnerabilities that are CVEEs that we're not reducing risk in those other ways by hardening. So just this this level of effort helps it to where you can start taking care of those other issues. And Jeff Man actually reminded me that risk is vans plus threats or vulnerability plus threats minus countermeasures which he says is

security. And I I tend to agree with him. You can reduce risk two ways here because you guess what? You don't get to probably reduce threat unless you just completely get out of some kinds of business. There's really no way to reduce your threat. You're just going to have threats. They're going to come after you. All you can do is reduce your vulnerability or increase your countermeasures. Those are the two things you get to change. We have thrown so much at just following the CVSS 9 through10. We've been throwing so much at that to try and reduce our risk. We've not been doing a very good job of it. I think this gives us a better way

to reduce those those vulnerabilities so we can focus on the countermeasures. And by the way, hardening is not a necessarily a countermeasure. So there's other things we're doing in detection response and IDS, IPS, you know, that we're doing to try and uh thwart the bad guy once they're in, right? So focus on those counter measures so we can deal with those threats and reduce our overall risk. So those are some key considerations, but basically what I want you to take away from this is just that CVSS is no longer appropriate. It was actually never and first is the first to say it. It was never a prioritization mechanism. It's never meant to be that way. The base score was

never meant to be that way, but that's how it's been abused over the past 10 or so years. Uh, take a threat-based approach to examining your exploitability. Uh, roll your own prioritization automation. It may actually convince some people to invest in a commercial tool if needed. Uh, and I think your IT op folks will probably love you because you're not throwing so many issues at them at once to get fixed immediately. uh and you're making the work more uh doable for them while focusing on the things that actually matter to your business, not just kind of a score we've been leaning on as a crutch. Do I have questions? And I know I'm probably exhausted that last five

minutes. You're talking about scans being able to be imported into some of these other enrichment. What scans exactly are you talking? So it would be like a qualice, a tenable, a rapid 7. You could even do open vast things like that. What you would do is you would have like an Azure function as a service uh function that would call an API call to that scan tool and it would then pull and organize that data into a PowerBI. Could you use like say you wanted to do it manually? Mhm. You you if you wanted to, you could download like an a CSV of your vulnerabilities and you could upload them up through PowerBI like that or

just keep them Excel and and do it that way manually. You can it's maybe a great exercise to learn some automation skills, but uh you can do it. I I recommend the manual only kind of as a couple times to really prove the concept. Uh because it takes time. It takes time to do manual things. I I'll check on my too obviously, but do you know if there's any uh uh when you're working for the government upon information like this necessarily into another tool. You'll have to check with your your folks specifically going. Um you may have another thing that's not PowerBI that's actually in your environment. I just say PowerBI as an example. It's something

very supportable and out there. It talks well with other things. Uh you may have something locally more a data lake more local data lake or some kind of thing that you can put things into more securely. Uh, and vulnerator, right? Yeah. It's not giving information like you're talking. Um, I've never heard of vulnerator actually. Yeah. Well, it it spits out stuff like STS and cat, cats file, makes it look pretty. Gotcha. And narrow down like you're talking. Yeah. Yeah. Yeah. Yeah. Kind of focus on maybe the more important ones. Yeah. Okay. Yeah. But no, I mean, as far as storing it, you'll probably have to rely on your own automation technology to be able to organize this data uh in a

way. And you could probably automate it into Excel as well. Like I'm sure there's a way to just go and grab it, run a cron job at the very least somewhere and have it go into a CSV and enrich it that way. So sometimes you um let me know if this is outside the scope of this talk. Sometimes you have vulnerabilities that are not patchable. It's either because of like the environment you're in that there's some for some really weird business need. Um sometimes it's because the vendor doesn't you know it's not the budget's not there for a new product or whatever. So in those cases like you can secure that stuff sometimes through other ways

of like protecting things isolate them or whatever. Do you have like a favorite way of managing those exceptions and documenting them and managing them? Your GRC team is going to be your friend there. uh they probably already have risk registers and things. Maybe you are the GRC team. I don't know. But your GRC team, if you have one, could be helped. Uh there usually there's a risk register of we can't do this. That is according to our policy. Um so we're going to have to do something else to make up for that. And that's where that risk equation comes in, right? So we can't patch that. We can't reduce that vulnerability. So we can't reduce that

part of the equation. We're going to have to increase countermeasures. Yeah. and and you're going to have to and if no one wants to increase counter measures, you might need a risk exception, right? To say then you're accepting the fact that this threat is able to use this vulnerability without counter measures, you know, you need we need to we need to have that and we need annual consent to that. You know, someone needs to own that and it's not a manager, it's probably a VP or higher. Very good. Someone someone who can authorize that level of monetary loss. If you can't write the check for that loss, you probably shouldn't be accepting risk. Jeff Man, the man

himself. I want to blow your mind a little bit. All right. Blow my mind. Vulnerability rankings. Ah, interesting. So, regardless of what method you use, they require a vulnerability ranking. Anyway, it's rarely taken advantage of because most organizations just go right. Gotcha. They don't have to. Right. So PCI is really open to different concepts to rank vulnerabilities. Exactly what you've been saying since 2010. Organizations could have been chase. Yeah.

Very good. Yeah, these things have been a while. This Intel has been available for a while. It's been years that this at least six or seven years we've been able to probably do this stuff. It's only in the last five or so years that this industry is even popped this part of the industry's popped up, which is why I know about it. So, I'm saying here's how you can roll your own. But anyway, I think they're beginning to open doors to tell me shut up, you're done. I'm going to get the hook in a bit. Thank you so much for your kind attention. Hope everybody enjoyed