Adam Dudley:
Hey everyone and welcome back to Nucleus Short Cuts. If you missed earlier episodes, not to worry, you can find them on our blog at nucleussec.com/blog and on our YouTube channel, you can find that just by searching Nucleus Security on YouTube. Also on LinkedIn and Twitter at Nucleus Sec. So we’d love to have you follow us over there. And I’m your host, Adam Dudley, and our topic today is what the heck is a CVE? And today as the expert on the topic is my old friend, Dave. And Dave is a regular here on Nucleus Short Cuts. And he’s a solutions architect, someone with a vast background in vulnerability management. I have personally learned so much from him and always excited to have him on the show to enlighten us. So welcome, Dave. Do you want to introduce yourself any further than I did?

Dave Farguhar:
Yeah, thanks Adam. My name is Dave Farquhar and I’ve fixed 800,000 CVEs in my career as a system administrator and I didn’t even get a lousy t-shirt. Now, I’m also not sure that I knew what a CVE was at the time while I was doing that, believe it or not, but I’ve learned since then.

Adam Dudley:
Absolutely, I know that’s true. And we still need to get you that t-shirt, Dave. I think I’ve got to put it on my list and we need to make that happen. So thanks for being here as always. And would you please kick us off just with a brief take on what the heck a CVE is and maybe with a light dose of historical context.

Dave Farguhar:
Sure. As opposed to a heavy dose of historical context?

Adam Dudley:
Yeah.

Dave Farguhar:
So CVE stands for common vulnerabilities and exposures. And if it sounds like a job interview question that’s because it is a fairly common job interview question. Think of it like an industry standard tracking number for vulnerabilities and off the shelf software products. So it was a standard that came into being in September of 1999 and if it did nothing else for us, it provided us a standard way to track the vulnerabilities that all of these scanners that were coming onto the market at the time were finding and it made it possible to compare their results.

Dave Farguhar:
So it takes the form of CVE followed by the year, followed by a four or a five digit number. So for example, CVE 2020-1472. So you can estimate a vulnerabilities age from the CVE number, so you’ve got the year of the issue and the lower the number is the earlier it probably came out in the year. More importantly, it means that every time I see that CVE in scan results, no matter what scanner somebody used, I know that we’re talking about the same vulnerability. One other thing to keep in mind, this sounds grade school-ish but we’ll get back to this in a minute, all CVEs have vulnerabilities but not all vulnerabilities have CVEs and that can be important sometimes.

Adam Dudley:
All right. Good to know. So CVE is basically a standardized method for tracking vulnerabilities. And one thing I was very curious about, and if you know, is who came up with CVE? Or what organization?

Dave Farguhar:
So was a consortium that included like the US government, government agencies, Mitre Corporation ended up administering it,

Adam Dudley:
Okay. Got it. And so without this standardized method, really you just had a bunch of raw data on, disorganized and really no way to correlate it with anything, right?

Dave Farguhar:
It was anarchy. So the scanners that were there at the time, they each tried to invent their own tracking number.

Adam Dudley:
Got it, that’s a mess.

Dave Farguhar:
You see that like Qualis and Nessus, or any Tenable product. Qualis has their QID, that was their tracking number that they came up with because they didn’t have CVE to use yet. Tenable uses plugin IDs because they didn’t have CVE to use yet. So they continued to report those numbers but they also report the CVE [inaudible 00:04:30].

Adam Dudley:
Got it, all clear, great. So thanks for that. So getting into the meat of the topic now, why do CVEs matter in the context of vulnerability management programs?

Dave Farguhar:
So the majority of the data that your network scanners are producing have CVEs attached to them. And depending on the scanner that you use, some of them use the CVE as their primary tracking number. Some of them even put the CVE in the title. So like CrowdStrike, Rapid7, those are two examples that they include the CVE right there in the title. Qualis and Tenable, like I mentioned before, they have their own tracking numbers because they didn’t have CVE when they were starting out. So they’ll report both. Now some scanners will bundle related CVEs together in one signature because it’s faster to check for all those CVEs at once, for whatever reason. Both Qualis and Tenable use that trick. But they will report all of the CVEs that they were looking for. And so if you’re looking in Nucleus and you see findings that have multiple CVEs, that’s why, it came from one of those scanners that was looking for CVEs in bundles.

Adam Dudley:
Okay. Got it. Got it. Yeah, so most of the scanners are attaching CVEs to the vulnerabilities. Sometimes if they’re a legacy scanner like Qualis or Tenable, they’re going to have their own nomenclature for vulnerabilities as well. So are there any difference really, you mentioned most vulnerabilities coming out of the network scanners have CVEs but what about our application or our cloud scanners or even OT scanners? Are those scanners producing vulnerabilities with CVE correlation as well?

Dave Farguhar:
It depends. So network scanners, that’s where they make their money, is in CVEs. OT, generally the same thing. Now the way that they go about getting them, the way they go about scanning could be a little bit different because of the sensitivity of the environment, that’s the major difference between an OT scanner and a network scanner is the methodology. Now an application scanner, primarily what they’re concerned with or CWEs rather than CVEs. CWE are more generic. CWE stands for common weakness enumeration. So some examples of those are things like cross-site scripting, SQL injection.

Adam Dudley:
Okay.

Dave Farguhar:
They’re a generic problem that happens in various products or in your own software as well. So looking for those things generically rather than specifically. You can map a CVE to a CWE but not the other way around because it’s not a one-to-one or even a many to one relationship. So that’s the main reason that I said that all CVEs are vulnerabilities but not all vulnerabilities have CVEs.

Adam Dudley:
Got it.

Dave Farguhar:
Now, depending on how the application scanner works, if you’re loading third party libraries that are written by somebody else then those third party libraries probably have CVEs and the application scanner may be able to find them. So they may report CWEs that are happening in your own code and CVEs that are in the code that you embedded in.

Adam Dudley:
Okay.

Dave Farguhar:
And a cloud scanner, it may return CVEs, CWEs, or both just depending on what it is that it’s scanning. So like cloud scanning and application scanning, all of them have their own kind of specialties. And so that’s why a lot of organizations don’t have just one application scanner, they’ll probably have one network scanner and they may have five or six application scanners because each of them do like one thing really, really well and I wouldn’t even try it on some other thing they care about. They buy another solution that takes care of that other thing and to fill in those gaps.

Adam Dudley:
Got it.

Dave Farguhar:
Now, getting back to CVEs, there is one other difference. You may handle them a bit differently depending on the scanner that found them and where the scanner found them. And the reason for that is, it’d be a different person’s responsibility to fix it and the way that they fix it. So if a network scanner finds it, a system administrator fixes it probably by installing an update from the software vendor. It’s what I did 800,000… Well, not 800,000 times, but the effect was 800,000. Now if an application scanner finds it’s more likely that a developer is going to fix it by updating the third party library they embedded in the code and then they do a new release. If a cloud scanner finds it, probably going to update an image and then spin up new servers with that image and then spin down your old servers. So if you ever wondered why our finding processing rules and our ticketing rules can get really, really complicated, this is why.

Adam Dudley:
Right. Right. So many nuances to how the different scanners stay on the different parts of the environment.

Dave Farguhar:
Right.

Adam Dudley:
So thanks very much for that walkthrough, Dave. So how about we do a quick demo and show the folks how CVEs show up in Nucleus and how customers are using the information to build better vulnerability management programs.

Dave Farguhar:
Sure. So if we share my screen here.

Adam Dudley:
All right, I can see your screen.

Dave Farguhar:
Oops. Do I have the wrong screen up?

Adam Dudley:
Nope, I see Nucleus.

Dave Farguhar:
You see Nucleus? Perfect.

Adam Dudley:
Yep, we’re all good?

Dave Farguhar:
Okay. So the first place you want to go is go to vulnerabilities and go to active. And we have a nice column over here called CVEs, that’s plural, reason why it’s plural is because it may have more than one in here. So most of these findings came from CrowdStrike and that’s just what happens to come up when I pull this Nucleus instance up. And so they report one CVE per finding, it’s just the way that they work. And you see that they have the CVE in the title as well.

Adam Dudley:
Yes, you mentioned that previously, that they do that. Yep.

Dave Farguhar:
Now, if we keep going here, here’s sneak, that’s an application scanner. And you see that when I hover over the CVEs column I see a CVE and I see a CWE. So in that case this is a CVE, it maps to this other CWE and it’s in an off the shelf product. And so they give you that information.

Adam Dudley:
If I understand what you said earlier about CWE, you’re really not going to see the CWEs coming in from a network scanner, correct?

Dave Farguhar:
Correct, it would be unusual to see it from there. It makes more sense to be reporting that to a developer than it does to a system administrator.

Adam Dudley:
Oh, clear.

Dave Farguhar:
As a system administrator, I don’t care. I just want to… Where’s the vendor link so I can fix it?

Adam Dudley:
Sure.

Dave Farguhar:
So the other place that you can go and you can use this to get more information is… Well, you’ll see it in the reference information over here, the CVE or CWE associated with it. And if you click on the vulnerability intelligence tab within the finding, then you look over here to the right, and you can see all of the wonderful analysis from our good friends Mandiant. Including like, “Hey, how do I go and fix it? Why should I fix it?” And the famous chart, the closer it is to the top right, the more urgent it is to go and fix it.

Adam Dudley:
Everything you wanted to know about this vulnerability and more, right?

Dave Farguhar:
Right. Now this detail, the CVE number can be useful in troubleshooting as well. There’ll be times when I’ll get a question, “Why do I have duplicate findings in my vulnerability scan results?” Well, when that happens one of the first things to do is look at the CVE. And what you’re usually going to find, and I’m going to say more than 90% of the time, you’re going to find that the vulnerabilities have similar or identical titles, but the CVE is different. So that’s why you have the duplicate. And now are they related? Well, you can look at the analysis and figure out, okay, are they related or is one older than the other? Things like that.

Adam Dudley:
Got it.

Dave Farguhar:
Now something else to keep in mind is that even though security professionals live and die by CVE at the beginning here when I was talking, I said that I fixed 800,000 of them without even knowing or caring what a CVE was. And the reason for that was because my patching tools didn’t track CVEs. When a software vendor releases an update they put their own tracking number on it. Now you can go to their website and you can see what CVEs the update fixes, they disclose that information, but they don’t put that in the title or anything else.

Dave Farguhar:
Now, some of the more modern patch deployment tools will cross reference the CVE number. And you may even be able to enter a CVE number and they’ll tell you, “Oh yeah, here’s the patch for that.” But the older ones don’t. The ones that I was using, they don’t. And they still don’t. So this is a major opportunity for teams to talk past each other. And I’ve seen this happen way too many times. Let’s say I scan my network, I have 10,000 computers and each of those computers has 10 CVEs on it. According to my network scanner I have a hundred thousand vulnerabilities.

Adam Dudley:
Right.

Dave Farguhar:
Now the system administrator goes and scans the same network with their patching system and they find that there’s one missing update. Now that’s a little bit contrived but that shows one of the reasons that vulnerability management is difficult. We’ve got two teams trying to work together and they measure their data very differently.

Adam Dudley:
Clearly, I can see the cause for confusion and difficulty communicating there.

Dave Farguhar:
Right.

Adam Dudley:
One has one and the other has a hundred thousand, yeah.

Dave Farguhar:
Right, yeah. And I’ve seen it so many times. Now this is one of the reasons why when you go to the trends section in Nucleus, why we report unique vulnerabilities and we report total vulnerabilities. So what you’ll see here, these numbers are different. This one’s a little bit lower than what you’re going to see in a commercial environment but this… You could very well see a number like 20 or something like that and a huge number down here like a million or a couple of million.

Adam Dudley:
Right, right.

Dave Farguhar:
And so when you see that really big difference, then that tells you you need to be paying attention to both. This is the one that you use to estimate the workload. This is the one that you use to estimate the risk.

Adam Dudley:
I see, work versus risk.

Dave Farguhar:
Right. And this number probably isn’t going to match what’s in the patch management system either but it’s going to be much closer. So just to give a non-technical example of this, a story to kind of relate the mindset that we run into. I have an acquaintance, he used to work in a music shop and he tells a story about how he would get a phone call a week, he swears up and down, he would get a phone call a week asking if he can appraise a Stradivarius violin, it’s a family heirloom. They’re expecting it to be worth 3 million dollars. And he tells them, “Well, yeah, I can tell you all about it. It’s a reproduction, it’s about 150 years old and it’s worth a couple hundred bucks.” And their hopes and dreams are dashed there because they think that their millionaires and now, what you’ve got is… Hey, he sees one every week, it’s worth a couple hundred bucks. It’s not worthless but an order of magnitude different. Now it’s one thing when you have that conversation once in your life, it’s another when you have that conversation with that kind of asymmetry every single month. You can’t manage expectations that way.

Adam Dudley:
No kidding. So really we’re talking about helping to solve a communication problem here between the vulnerability analyst or the security engineer and the patch or remediation teams that are not speaking the same language and seeing things very differently.

Dave Farguhar:
Totally.

Adam Dudley:
So we’re trying to give the analyst or an engineer a view here that helps them think more, see things more accurately and communicate more effectively with their counterparts. Is that right?

Dave Farguhar:
Right. Exactly. There’s always a, “Well, who’s right? Which tool do I believe?” “Well, they’re both right. They’re looking at it very differently.”

Adam Dudley:
Yep. Yep. Different lenses, got it. Great, Dave. Well, thanks so much for that demo. And so in your view what’s the most important things for folks to take away here from what we’ve talked about so far?

Dave Farguhar:
So there’s that difference between knowledge and wisdom and I think that really kind of applies here. So knowing what a CVE is matters but where you’re going to get the results is from how you measure them. Because, let’s face it, if I scan the network and I find a hundred thousand CVEs, a mediator looks in their patch management system, they see they’re missing one update, their natural reaction is there’s no way that I have a hundred thousand vulnerabilities. And that is a very extreme example but I have seen real world examples where a company could fix a million CVEs by deploying like nine updates.

Dave Farguhar:
So these extreme cases can and do happen sometimes. So knowing things like to use the unique vulnerability count to estimate work that’s related to CVEs and use the total to estimate risk, that’s how you get things done. I can map CVEs to CWEs and make myself sound smart but I’m useless. So if I want to make my network more secure, knowing which counts resonate with which teams is going to be much more useful and motivating to the teams who are doing the remediation.

Adam Dudley:
Great. Great points, Dave, thank you so much and thanks for the education today. Thanks for joining us as always. And we’ll share any relevant links in the show notes, including how you can take a demo of Nucleus or get a free trial. And we’ll see you soon on the next Nucleus Short Cuts. Bye-bye

Dave Farguhar:
Thanks, Adam.