Adam Dudley: Hello, and welcome back to Nucleus Short Cuts. You can find all the episodes on our blog at nucleussec.com/blog and on the YouTube channel, just search for Nucleus Security. Be sure to follow us on LinkedIn and Twitter, we’re @nucleussec, and subscribe to our email newsletter. I’m your host, Adam Dudley. Our topic today is, What the Heck is a CVSS? And today’s expert on the topic is Dave Farquhar. Dave is a regular here, he’s a solutions architect and someone with vast knowledge of vulnerability management. I learn from him all the time. Always excited him to have him back. So welcome back, Dave.

Dave Farquhar: Thanks, Adam. And I want to assure everyone I have never held any political office, even though I’m about to both sides, CVSS in a way that would just make the both sides politician proud.

Adam Dudley: I’m excited, Dave. All right. So did you want to say anything else about yourself or your background for the folks at home?

Dave Farquhar: I’ve been chasing these things for 20 years. No, not quite 20, because CVSS hasn’t existed for exactly 20, but that’ll help us to see what the problem it solved, so.

Adam Dudley: Great. So thanks for being here again. To get us started, would you kick us off with a brief take on what the heck is a CVSS, and give us a light dose of historical context along with it.

Dave Farquhar: Yeah. So CVSS stands for common vulnerability scoring system, and current version is 3.1. You will find versions 2.0 and 3.0 still in use sometimes. Version 4 is due to land at the end of this year, and I’m excited about version 4 because that will solve some of the problems, or at least that’s what they’re hoping, that it will solve some of the problems with the current versions.

CVSS rates of vulnerability on a scale of one to 10, with one being the most minor, 10 being, this things on fire, fix it immediately. And it defines as ranges within that one to 10 as low, medium, high, and critical. So that’s where that four severities came from, was from CVSS.

Adam Dudley: Got it.

Dave Farquhar: So you can think of this as the industry standard method for scoring vulnerabilities. The industry standard. It may or may not be the best, but it provides the standard.

So it was launched in February 2005. So I’ve been chasing these for 17 years, not 20.

Adam Dudley: Okay. Close enough.

Dave Farquhar: Well, yeah, yeah, round numbers. So if it did nothing else for us, it gave us that standard scoring methodology. So you could compare the results from different scanners, and it would make sense. So prior to CVSS, every scanner vendor had to invent their own scoring method. And some of them used a scale of one to three, or a scale of one to five, they didn’t always say high, medium, low. They were very bad about using medium as the starting point, and medium should be in the middle, not at the beginning. And what’s worse, severe or critical? Because they both sound pretty bad. So CVSS at least fixed all of that.

But CVSS has a tendency to evoke very strong reactions from people. If I want to start an argument, my three best bets just bring up politics, religion, or CVSS. So now the that’s the reason that I have mixed feelings on it is I don’t like getting into these religious debates, especially about security issues, but it solved a real problem for us, where it was hard to compare results from different scanners, but it created other problems. It’s the standard, but a startlingly high percentage of people, including myself, who have used it ended up having to find ways to work around its limitations or even create a replacement for it. And I’ve had very mixed success using it in my career.

So I’m really looking forward to version four, to see if it solves those problems that led me to go and create my own replacement for it. And can version four replace all these other replacements that are out there, because it definitely bugs a lot of people that they don’t use the standard.

Adam Dudley: Got it. Got it. So what I’m really hearing, Dave, is that this is another standard that we have in cyber security. It’s a method for scoring vulnerabilities, and it can be controversial and comes with its own challenges and limitations. Sounds like people love to debate its validity and how to use it, and when to use it and those types of things. So sounds like a hot button issue.

Dave Farquhar: Yeah.

Adam Dudley: Gotcha. So getting into the meat of the topic, why does CVSS matter in the context of a vulnerability management program?

Dave Farquhar: So you may very well be using it and not realize it. That was my case, or initially, was here I am in 2005, I’m getting notices from a security analyst that I need to get an update deployed, and has a due date attached. Where was that due date coming from? My boss speculated, is there some VP or VP equivalent throwing darts on a dartboard? And I think that he actually asked that. But the results, I learned later, the due dates were coming from the CVSS scores. Now I didn’t care about the CVSS score nearly as much as I cared about the due date, because that’s what I was being held to is, hey, is it done yet? Am my past due or not? I think that the first time that I really cared about CVSS was when I took my security plus test, and then I cared about it just long enough to get my passing score on the test.

So it didn’t matter to me so much what was driving the due dates as, am I hitting those due dates? Now those due dates were intended to help me to prioritize. And I appreciated that on some level, but it didn’t help me terribly much, because the overwhelming majority, and talking more than half of them had a 30 day deadline attached. Now, my second most common deadline was something like 21 days, or something like that. Can’t remember if it was, it was three weeks or thereabouts. Only occasionally, maybe 20% of the time, did I see deadlines that were longer than 30 days, like 45 or 60 days or something like that. Those were my mediums and my lows.

I only had one maintenance window a month. So what I ended up having to do was just look at my shortest due date, this was how I worked around the problem. So is my shortest due date 21 days, or is it 30 days? And I used that to move my maintenance window based on how early in the month do I need to start. Now it’s not like I wasn’t doing anything, if my shortest due date was 30 days, it stayed in testing longer. So the question was really, how long am I going to test?

So if prioritizing based on the score really ended up adding work for me, it was just trading paperwork for system administrator work. In my case, system administrator work was more interesting, so I just skipped the paperwork and worked hard as a system administrator. But if you’d rather do paperwork, then I guess CVSS could help you. Prioritizing by CVSS could help sometimes.

But getting back to the knock on CVSS, prior to version four, 70 to 80% of your vulnerabilities have those super short due dates. As in, you got to fix it this month. Question is, how early in the month do you have to fix it? And it’s the inverse of the classic 80/20 rule. And it’s not realistic or sustainable.

And it gets worse. So even though it is overstating, probably 60% of the time by default, depending on whether you’re a proponent of the 80/20 or the 90/10 rule, it still misses things. Heartbleed is the most notorious example. It’s a CVSS five, the medium, because all it does is leak information. Problem is, it was leaking information that’s supposed to be encrypted. It broke credit card transactions for any server that had it. So even though it was a CVSS five, all of us who were processing credit cards at the time that it came out knew that we were out of business until we updated this thing. So the cynical take was that CVSS punished Heartbleed for not making attackers work hard enough before giving up the crown jewels.

And in theory, there’s room in the current versions of CVSS to factor in asset context and whether active exploitation is going on, but it doesn’t weigh those factors heavily enough. So there is no path to turn Heartbleed into a critical within the CVSS model. If it’s close enough to one of the borders, I can use those two things to push it over the nearest border. So I can either push it up to a high, just barely over the edge to a high, or just barely over the edge to a low, but there isn’t enough wiggle room in the math to be able to go, to be able to go both directions, let alone go all the way up to a critical, because hey, I’m out of business because of this thing.

Adam Dudley: So really CVSS alone isn’t sufficient. You really need other context and other dimensions to look at the problem through. Got it. And so that’s why something like Heartbleed is underrated, so to speak.

Dave Farquhar: Right. And Heartbleed, it’s the exception. And it’s almost cliche to bring it up, it comes up in every single discussion of CVSS. But it’s by far the most notoriously understated.

Adam Dudley: Got it. And I’m curious, Dave, are there any difference in how CVSSs are used in network scanners versus application or cloud scanners?

Dave Farquhar: I’m going to both sides you again. It seems like it should be an easy question. So like we talked about last time, the major difference between network scanning and cloud and app scanning is the type of vulnerabilities you’re dealing with. So network scanning is mostly CVEs, and where cloud and application scanning may be CVEs, it may be CWEs, it may be a combination of the two.

Adam Dudley: Okay.

Dave Farquhar: Now, it’s super tempting to associate CVE and CVSS is inseparable, because Hey look, half the letters are the same. And they were intended to sound like they go together. But you can totally apply CVSS to a CWE or your non CVE finding that you came up with. Because it’s just a really big math problem. It’s a math problem the size of a tax return, but it is a math problem. And if you’ve got all the variables to plug in, you can plug it in and get a score.

Adam Dudley: Gotcha.

Dave Farquhar: So from that point of view, there isn’t a huge difference. So the reason that I’m going to be difficult and say, yes, there is a difference is because when you’re dealing with CVEs, you got all kinds of alternatives to CVSS to fall back on when you run up against the limitations of CVSS. Application scanning, CVSS is probably all you got if you’re dealing with CWEs.

Adam Dudley: Got it. Thanks for clarifying that. So Dave, would you mind showing the folks at home just quickly, how CVSS shows up in Nucleus, and how customers use the information in our programs?

Dave Farquhar: Sure. So let’s go and share my screen. Let’s see. Helps if I click the share button.

Adam Dudley: I can see it.

Dave Farquhar: Excellent. So when you go into Nucleus, you’ll go into vulnerabilities, and you’ll go active. So now we have a list of vulnerabilities in our demo project here. CVSS is one of the major columns right here. So you can see it in there plain as day, and you can sort on it. So if you want to sort low to high, you can do that. And you’ll notice a fairly close association with the severity.

Adam Dudley: Yep.

Dave Farquhar: So CVSS 9.8 would expect that to be a critical by default, and from most scanners that is what it will report.

When you see an exception here, this is the criticality that we get from the scanner. So if you are using one of the scanners that had their standard that predated it, you will may see that. So talking Qualys, Rapid7, we will map whatever theirs is to low, medium and high as close as we can. What they came up with prior to CVSS was surprisingly close to what the earliest version of CVSS looked like.

But there wasn’t quite 100%. They couldn’t predict the future. Can’t blame them for not predicting the future. So that’s why you won’t necessarily see, Hey, why is this coming? Why is this finding that came from Qualys or that came from Rapid7? Why does this look like it should be a critical, but it doesn’t match CVSS? That’s the reason why.

Now, the other important place where CVSS comes up is in the automations. So if I go into automation and I go into finding processing, a whole bunch of rules in here, but we’re just going to go and make a new one. So we will make one. Set due date on CVSS critical. So we’ll set a criteria, vulnerability, and we will go down here to CVSS score, and you can pick greater than, less than, equal to, or a range. So range is helpful when you’re dealing with highs and mediums.

Adam Dudley: Sure.

Dave Farquhar: You can go greater than and less than to deal with criticals and highs. So 8.9 is the cutoff for a CVSS critical. So I’m going to say my CVSS score is greater than 8.9. [inaudible 00:16:59] do next. We’re going to set a due date, and we’ll go with the example I gave earlier of 21 days. And we can say from now or from when my scanner said that I find it. [inaudible 00:17:13] prefer to say from now that’s a little bit more fair, I think, but flip a coin on that one, 50% of security professionals agree with me on that, 50% say, no, you’ve got to go by when the scanner found it. But regardless, you do that, click save and finish. And now all of my CVSS 8.9s and higher, or well, 9.0 and higher will have a due date 21 days from now.

Adam Dudley: Nice. And we can take a lot of other actions as well, as we saw on the previous.

Dave Farquhar: Right. Yeah, let’s say I want to normalize based on CVSS, because Hey, I’ve got a mixture of Qualys and Rapid7 and Tenable and CrowdStrike data, data from a lot of different sources and I won normalize across all of that and use CVSS as my standard, because I’ve got network scanning, application scanning, cloud data and everything. So CVSS is the one standard that I know that applies to everything that I have. So I can do that too. So going by an 8.9, so I can go and add that to the rule as well. Pro tip for Nucleus, when you have that option to set both a due date and a severity in a single rule, go and do that. One rule that does two things runs faster than two rule each doing one thing. So just a nuance as to how Nucleus works.

Adam Dudley: Yeah, thanks, Dave. Thanks for covering that. And so before we wrap this episode, is there any one takeaway you’d you’d want to give people to walk away with?

Dave Farquhar: Yeah. I mean, it’s possible to be productive in this space without knowing or caring too much about CVSS because there are some good alternatives available. But with it being the industry standard, you probably can’t avoid it your entire career. If nothing else, it’s going to come up in a job interview from time to time. You may need to use it as a job interview question, because that may be the only thing that the candidate you’re talking to is, if you’re interviewing a candidate, maybe that’s what they used. So at least having a familiarity so you can speak their language is helpful.

Now, if you’ve got designs on moving beyond a security analyst job title, you’re going to need to know the pros and cons of CVSS so you can evaluate whether it’s the right standard for your organization to be using, based on what it is, the types of data that you’re processing, and also what are the pros and cons. And if you don’t have a lot of backlog, CVSS probably is fine. I mean, I did, that was the standard that I was using when I was fixing those 800,000 vulnerabilities that I talk about fixing over four years. CVSS was all we had at the time. But I didn’t start out with much of a backlog, so I didn’t really need to prioritize.

And the other thing to keep in mind is that if you are interviewing for a VM director role, and that role is open, you’re going to inherit a backlog. And you’re not going to find out how large that backlog is until you’re actually on the job, because people interviewing you, they may not know. But if they do know, they don’t want to talk about that until you’re actually an employee, because they consider that the most sensitive of data. They’re going to be very reluctant, they’re going to be cagey about that. And I’ve seen that in, when I’ve interviewed for VM positions, everybody’s always cagey about their backlog. Or they downplay their backlog. Then you get on the job and you find out, oh yeah, this isn’t… Did I come to the right place?

There was a saying in the 80s and 90s that nobody ever got fired for buying IBM. And the reason for that was because they were considered the industry standard. They were the safe choice. Now, the safe choice probably won’t get you fired, but it isn’t automatically going to make you effective, either. And so I’ll apologize in advance for stealing your thunder, but that’ll be the next thing that we talk about on the next episode, is one of those alternatives to CVSS that gets you closer to not just the 80/20 rule, but even the 90/10 rule.

Adam Dudley: All right. Thanks for teasing the next episode, Dave.

Dave Farquhar: Yeah. [inaudible 00:22:19]

Adam Dudley: That’s a wrap for this one. You can steal my thunder any time. Thanks for joining us again on Short Cuts, and we’ll see you next time. Thanks, Dave.

Dave Farquhar: Thanks, Adam. It’s always a pleasure.