CVSS is Just the Beginning
The Buck Starts Here When it comes to discussing vulnerabilities, you can’t avoid CVSS, the Common Vulnerability Scoring System. CVSS provides a convenient way to (for the most part) objectively analyze a vulnerability, and summarize it using a standard vector format, which then translates to a score on a 0-10 scale. The cybersecurity industry has further reduced this scale to four categories – Low, Medium, High, and Critical – as so: CVSS score Severity of vulnerability 9.0 - 10.0 Critical 7.0 - 8.9 High 4.0 - 6.9 Medium 0.1-3.9 Low Obviously, a score of 0 would be not vulnerable. CVSS has evolved over the years, and we’re currently on CVSS v3.1. There are easy-to-use calculators, it is found in almost every CVE published, NIST provides their CVSS score for every vulnerability in the National Vulnerability Database (NVD), and you’ll find CVSS scores in security advisories from nearly every vendor – including F5. CVSS is nigh-ubiquitous. However, this ubiquity isn’t always a good thing. For one, familiarity breeds contempt. There has been a bit of a backlash against CVSS in some circles. Personally, I think this is overblown and mostly unwarranted, but I also understand what drives it. CVSS is not perfect – but that’s why it has continued to evolve, and why CVSS 4.0 is currently in Public Preview. I’m not on that working group myself, for lack of time, but one of my F5 SIRT colleagues is. However, you don’t throw out the baby with the bath water, as they say, and CVSS is a useful tool, warts and all. The real problem is that, to use another metaphor, when all you have is a hammer, everything looks like a nail. CVSS is everywhere, so people are using it for everything – even things it is not good at or wasn’t designed to do. Or they’re using it for things it was designed for, but not using it appropriately. Let’s start there. All your base are belong to us I’m not going to do a full CVSS tutorial here, maybe another time. If you’re reading this, I’m presuming you have some familiarity with it and, if not, the documentation is well written. As the User Guide states early on: The CVSS Specification Document has been updated to emphasize and clarify the fact that CVSS is designed to measure the severity of a vulnerability and should not be used alone to assess risk. Concerns have been raised that the CVSS Base Score is being used in situations where a comprehensive assessment of risk is more appropriate. The CVSS v3.1 Specification Document now clearly states that the CVSS Base Score represents only the intrinsic characteristics of a vulnerability which are constant over time and across user environments. The CVSS Base Score should be supplemented with a contextual analysis of the environment, and with attributes that may change over time by leveraging CVSS Temporal and Environmental Metrics. More appropriately, a comprehensive risk assessment system should be employed that considers more factors than simply the CVSS Base Score. Such systems typically also consider factors outside the scope of CVSS such as exposure and threat. Take the time to read that and internalize it. That is a vitally important point. One of the biggest mistakes we see, over and over, is the use of a CVSS base score as the deciding factor on whether to address a vulnerability. In the F5 SIRT we see this all the time with customers, and we also see it internally when working to address our own vulnerabilities. How many of you have heard it, or done it, yourself? “Oh, that’s only a Medium, we don’t need to deal with that right now.” Or “That’s a Critical – drop everything and patch that immediately!” CVSS scores drive everything from IT response to press coverage, often massively out of proportion to the actual issue. Especially when the score provided by a vendor is the base score, which is basically a theoretical score of the vulnerability of the issue in a vacuum. A vendor’s 10.0 Critical may be a 0.0 if you don’t have that functionality enabled at all. Or their 5.9 Medium may be a critical issue if it is in a key bit of mission-critical kit exposed to the public Internet, and there is a known exploit in the wild. The problem isn’t CVSS. The problem is that too much weight is being placed on the CVSS base score as the end-all and be-all factor in evaluating a vulnerability, or, more specifically, risk. Expanding Your Base An easy place to start is with the rest of CVSS. That’s right, there’s more! Vendors provide the Base Metric Group, or base score. This mix of exploitability and impact metrics are universal and apply to all environments. As I said above, it is an evaluation of the vulnerability in a vacuum. Vendors don’t have visibility into each customer’s network – but you do. At least your own network. If you have visibility into all networks… Setec Astronomy, right? There are two more groups available – the Temporal Metric Group and the Environmental Metric Group. As the name implies, the temporal metrics cover characteristics that may change over time, such as the publication of exploit code or the release of a patch or mitigation. While the environmental metrics allow you to consider factors unique to your environment which may affect the score. As the base vector is nigh-universally available, making evaluation of the two additional vectors part of your vulnerability analysis process is a reasonable place to start. This would produce a CVSS score adjusted for your environment, which would be a start for use in existing prioritization systems you may have. It would be an improvement over the generic base scores, but it really is just a start. Strike That. Reverse It. As a step beyond CVSS in your vulnerability analysis, might consider Stakeholder-Specific Vulnerability Categorization (SSVC). Yes, that’s CVSS backwards; never let it be said geeks don’t have a sense of humor. SSVC was created by Carnegie Mellon University's Software Engineering Institute, in collaboration with the Cybersecurity & Infrastructure Security Agency (CISA). The concept behind SSVC is a decision-tree model which results in three basic end states for the issue. As very, very brief summary which does not do it justice: Track – no action required at this time. Attend – requires attention from higher levels and further analysis. Act – needs high level attention and immediate action. SSVC is, as made very clear by the name, stakeholder specific. It is something each end consumer can use to evaluate the impact of an issue on their network, to help them prioritize their response. Part of your complete vulnerability response plan, as it were. It is a fairly simple system, and CISA provides a PDF guide, a YouTube training video, and a simple online calculator to make it easy. I recommend checking it out. You may find that SSVC helps you better prioritize allocation of your limited IT resources. How do I know they’re limited? Is water wet? Just My Type Another factor you may want to consider in your risk assessment is the type of vulnerability. Is this a DoS vector or unauthorized access? Not all CVSS 7.5 vulnerabilities are created equal. And that’s where the Common Weakness Enumeration (CWE) can help. CWE provides a standardized way to categorize a vulnerability to, well, enumerate the type of weakness it is. Many vendors, F5 being one, include CWEs in their security advisories. It isn’t as widespread as CVE, but it is not uncommon. And, in the cases where the vendor doesn’t provide it, NVD has NIST’s evaluation of the appropriate CWE for each entry. The type of vulnerability can be another input into your risk assessment. A DoS is bad, but not as bad as data exfiltration. It goes beyond the score and helps foster a deeper understanding of the issue. What You Don’t Know Can Hurt You Which poses a greater risk to your network; a vulnerability CVSS 8.9 High which was found internally by the vendor and has never been seen in the wild, or a CVSS 5.8 Medium which has several known exploit scripts and active exploitation reported? Now, answer honestly to yourself, which one is likely to get more attention from your own vulnerability response policies? What if the first issue was a 9.9 Critical with the same characteristics? Too often, the policies we see are “Bigger Number First”. We’ve seen policies where anything less than a 7.0 is basically ignored. If it isn’t a High or a Critical, it doesn’t matter. That boggles my mind. We’ve seen so many exploits where a Medium, or even a Low, severity vulnerability was used as part of a chain of exploits to completely own a network. Any vulnerability is still a vulnerability. And, to repeat the important point, CVSS base score is not a comprehensive risk assessment. It should not be used as such. OK, so how can we include what is being exploited in our evaluations? How can we know? Well, we consult the Known Exploited Vulnerabilities Catalog (KEV), of course. OK, this is just one of many resources available, but it is a free service provided by CISA for all to take advantage of. There are many commercial tools out there as well, of course, and I’m not going to get into those. Knowing that a vulnerability is being actively exploited would certainly factor into my risk assessment, I’m just saying. Minority Reporting Wouldn’t it be nice if you knew which vulnerabilities were the most likely to be exploited, and therefore the highest priority to patch? That’s the goal of the Exploit Prediction Scoring System (EPSS). EPSS is an effort to develop a data-driven model to predict which vulnerabilities are most likely to be exploited. Its first public release was in early 2021, so it is still a relatively young effort, but it is certainly interesting. EPSS is available for all to use. You can browse some of the data online, as well as download it. There is an API, User Guide, etc. All the usual good stuff. I’m not quite comfortable recommending making this part of a production risk assessment system just yet, but it wouldn’t hurt to be something to evaluate and see how it correlates with what you’re doing. I find the idea promising. I don’t see it even being a perfect prediction engine, but I can see it highlighting higher risk vulnerabilities that might otherwise be overlooked. Time will tell. Risky Business The key point is that you need to evaluate the risk of a given vulnerability to your business. No one else can do that for you, and there is no one-size-fits-all solution. CVSS is not bad, it just isn’t meant for that task. My personal view is that anyone writing articles or giving talks about how ‘CVSS is dead’ is just doing it for the clickbait – and probably looking to sell an alternative. But the arguments generally come down to what I said right at the top – vendors provide the CVSS base vector and score, and that was never intended to be some kind of triage trigger on what gets addressed. As I mentioned in my previous articles on CVE, F5’s role as a vendor is to inform our customers. But we’re limited to providing general information on vulnerabilities, we cannot perform risk assessments for customer networks. We do our best to provide the data, but the rest is up to you. Keep using CVSS but use it as part of a balanced risk assessment system. It should be one input, not the deciding factor. I presented a few options above, but this is hardly an exhaustive list. If you have other suggestions, please leave a comment – DevCentral is a community. It doesn’t have to be a free resource, if there is a commercial tool you can’t live without, by all means recommend it. I tried to remain neutral on that front as an F5 employee, but you don’t have to. Until next time! P.S. Check out the other articles from the F5 SIRT.90 Seconds of Security: What is CVE and CVSS?
Security researchers at F5 monitor web traffic 24/7 at locations around the world and the F5 Security Incident Response Team (SIRT) helps customers tackle incident response in real time. And when they find a new vulnerability, it’ll often get a Common Vulnerability & Exposures number like CVE-2019-1105 for the ‘Outlook for Android Spoofing Vulnerability’. Created in 1999, the CVE provides definitions for all publicly knowncybersecurity vulnerabilitiesandexposures. So, gimmie 90 Seconds to understand a little bit about the Common Vulnerability & Exposures. Now that we’ve looked at how vulnerabilities become CVEs, let’s explain how a CVE gets scored. The Common Vulnerability Scoring System or CVSS was introduced in 2005 as an open framework for communicating the characteristics and severity of software vulnerabilities. It consists of three metric groups: Base, Temporal, and Environmental. Once again, let’s start the clock to understand a little bit about the Common Vulnerability Scoring System. Hope that was helpful and you can catch the entire 90 Seconds Series on F5's YouTube Channel. psManaging Your Vulnerabilities
I recently recovered from ACDF surgery where they remove a herniated or degenerative disc in the neck and fuse the cervical bones above and below the disk. My body had a huge vulnerability where one good shove or fender bender could have ruptured my spinal cord. I had some items removed and added some hardware and now my risk of injury is greatly reduced. Breaches are occurring at a record pace, botnets are consuming IoT devices and bandwidth, and the cloud is becoming a de-facto standard for many companies. Vulnerabilities are often found at the intersection of all three of these trends, so vulnerability and risk management has never been a greater or more critical challenge for organizations. Vulnerabilities come in all shapes and sizes but one thing that stays constant – at least in computer security - is that a vulnerability is a weakness which allows an attacker to reduce a system’s information assurance. It is the intersection where a system is susceptible to a flaw; whether an attacker can access that flaw; and whether an attacker can exploit that flaw within the system. For F5, it means an issue that results in a confidentiality, integrity, or availability impact of an F5 device by an unauthorized source. Something that affects the critical F5 system functions - like passing traffic. You may be familiar with CVE or Common Vulnerabilities and Exposures. This is a dictionary of publicly known information security vulnerabilities and exposures. Each vulnerability or exposure gets a name or CVE ID and allows organizations to reference it in a public way. It enables data exchange between security products and provides a baseline index point for evaluating coverage of tools and services. MITRE is the organization that assigns CVEs. There are also CVE Numbering Authorities (CNA). Instead of sending a vulnerability to MITRE for numbering, a CNA gets a block of numbers and can assign IDs as needed. The total CVE IDs is around 79,398. Most organizations are concerned about CVEs and the potential risk if one is present in their environment. This is obviously growing with the daily barrage of hacks, breaches and information leaks. Organizations can uncover vulnerabilities from scanner results; from media coverage like Heartbleed, Shellshock, Poodle and others; or from the various security related standards, compliance or internal processes. The key is that scanning results need to be verified for false positives, hyped vulnerabilities might not be as critical as the headline claims and what the CVE might mean for your compliance or internal management. For F5, we keep a close eye on any 3 rd party code that might be used in our systems. OpenSSL, BIND or MySQL are examples. For any software, there may be bugs or researcher’s reports or even non-CVE vulnerabilities that could compromise the system. Organizations need to understand the applicability, impact and mitigation available. Simply put: Am I affected? How bad is it? What can I do? With Applicability, research typically determines if an organization should care about the vulnerability. Things like, is the version of software noted and are you running it. Are you running the vulnerable function within the software? Sometimes older or non-supported versions might be vulnerable but you’ve upgraded to the latest supported code or you are simply not using the vulnerable function at all. The context is also important. Is it being used in default, standard or recommended mode? For instance, many people don’t change the default password of their Wi-Fi device and certain functionality is vulnerable. It gets compromised and becomes part of a botnet. But if the password was changed, as recommended, and it becomes compromised some other way, then that is a different situation to address. For Impact, there are a couple ways to decide how bad it is. First, you can look at the severity of the vulnerability - is it low, medium, high or critical. You can also see if there is a Common Vulnerability Scoring System (CVSS) score tied to the vulnerability. The CVSS score can give you a gauge to the overall risk. To go a bit deeper, you can look at the CVSS Vector. There are 3 sections to the CVSS. There are the constant base metrics covering the exploitability of the issue, the impact that it may have and the scope that it is in. There are the temporal metrics, which may change over time, giving the color commentary of the issue. And there are the environmental metrics which look at the specific, individual environment and how that is impacted. Areas explored here include things like the attack vector and complexity; whether elevated privileges are required or any user interaction along with the scope and how it affects the confidentiality, integrity and availability of the system. One can use the CVSS calculator to help determine a vector score. With a few selections you can get a base, temporal and environmental score to get an overall view of the severity. With this, you can get an understanding as to how to handle the vulnerability. Every organization has different levels of risk based on their unique situation. The vulnerability base score may have a critical listing yet based on your environmental score, the severity and risk may be nil. Lastly, the Mitigation taken is not an exact science and truly depends on the issue and the organization’s situation. Mitigation is not necessarily prevention. For example, compensating controls, such as restricting root level access might mean that a vulnerability simply isn’t exploitable without a privileged account. Vulnerability management and information security is about managing risk. Risk analysis, risk management, risk mitigation and what that risk means to the business. Patching a vulnerability can introduce other risks, so the old refrain of “patch your $#!+” is not the panacea we’re often led to believe. Risk is not limited to the severity of the vulnerability alone, but also to the required vector for exploiting that vulnerability where it exists within a specific organization’s infrastructure. It’s important to understand your risk and focus on the important pieces. ps
