Risk and CVSS (Post 1)

I recently stumbled across the CVSS v2 vulnerability scoring method – as I was writing a post about risk vernacular. Per the CVSS v2 complete guide, “The Common Vulnerability Scoring System (CVSS) provides an open framework for communicating the characteristics and impact of IT vulnerabilities.”  As I started highlighting parts of the guide that were thought provoking from a risk perspective, I realized this would probably result in at least two posts – maybe three. So off we go…

I would encourage anyone reading this to perform their own review of CVSS and how it can possibly augment their own risk assessments efforts. In my opinion, there are some really useful “metric vectors” that provide a simple yet powerful way to analyze a vulnerability. In addition, I really like how they have a simple “scoring vector” – essentially a shorthand representation of all the individual “metric vectors”. I could see how this could be really useful for archiving / documenting purposes but for also being to programmatically manipulating for other purposes.

Thought 1: One of the first things that stood out to me as I started reading the CVSS guide was on page three, where they talk about “prioritized risk”. While I agree that their vulnerability score can be considered contextual and be used to compare variance in multiple vulnerabilities– I do not agree that it is representative of the actual risk to the organization.

Here is why.

No where in CVSS is there a metric for gauging how often assets within your environment – that have the vulnerability being analyzed- are being attacked let alone compromised. Now, I am not implying that the authors and maintainers of CVSS are trying to mislead security professionals – but I think this underscores a problem within our industry about knowing what risk is, the elements that make up risk, and risk vernacular.

Let’s talk about vulnerability for a minute. Generally speaking, it can be something (noun, a weakness) or a state / condition (adjective, my application is highly vulnerable to x). It would appear that CVSS accounts for both because you use CVSS to determine how vulnerable you are to vulnerability. Sounds confusing – but not all is lost.

FAIR – the risk assessment methodology I use – accounts for vulnerability as a condition. Within FAIR, vulnerability is derived from “threat capability” (the percentage of my threat community that can overcome control resistance) and “control resistance” (the percentage of control resistance I have against the “threat population” as a whole; for FAIR, threat community is a subset of threat population). When you have and can leverage a methodology and risk taxonomy like FAIR – you can see how easy it is to not take for granted what I would call risk term generalizations – using terms without truly understanding how they should be properly used or not knowing what they really mean. Just to reiterate – vulnerability is an element of risk – not risk itself.

Thought 2: On page 6, section 1.7 of the guide “Quick Definitions”, “threat” is defined as the “likelihood or frequency of a harmful event occurring”. This is the closest to “threat event frequency” or “loss event frequency” that CVSS comes close to touching. Threat can be both a noun and verb – but I have yet to see a dictionary that includes likelihood in its definition. It may sound like I am splitting hairs on definitions and picking on the CVSS folks – this is not my intention; but some of the concepts being discussed are foundational to understanding risk.

To wrap this first post about CVSS, I would offer the following:

1.    That the CVSS-SOG consider participating in the The Open Group; specifically in the “Risk Management and Analysis Taxonomy” forum.
2.    Do not discount the useful of CVSS in analyzing a vulnerability or a state of vulnerability. Just because there may be some risk term short comings does not mean their metric vectors cannot be effectively used.

In the next CVSS related post, I will focus more on the CVSS Metric Groups and how these have forced me to take a step back and evaluate the rigor and consistency I apply to risk assessments.

Advertisements

4 Responses to Risk and CVSS (Post 1)

  1. Ben says:

    fwiw, PCI uses CVSS for scoring criteria in patch mgmt requirements. That’s when I first encountered it in my consulting, after a client started asking questions about it in order to implement a compliant patch mgmt program.

  2. Chris Hayes says:

    Yep, PCI QSAs are using CVSS for vulnerability scoring. However, some of the vendors are not educating the PCI merchant about the portion of CVSS called the “environmental metric group” vectors which can have an impact on the overall CVSS score. As a matter of fact, the CVSS documentation implies that the environmental metrics are not something the vendor(s) can score – because they do not understand each and every organization’s environment. Granted, the environmental vectors are “optional” according to CVSS – but PCI QSAa should provide some value add and educate their clients about assigning the vulnerability in the context of their environment. For PCI gaps, one should separate risk due to the vulnerability itself vs. risk with not being compliant.

    Also, some PCI QSAs do not even perform the CVSS method themselves, they just go to the National Vulnerability Database and grab the CVSS score / vector from there. How original is that? High reuse, less work, more profit – less value-add.

  3. HyunChul says:

    The main goal of CVSS is to standardize software related vulnerabilities mainly , so that we can make it sure that when we say vulnerability A, it is not the same one with vulnerability B among the people.
    Also, it can prioritize severity of vulnerabilities. It can help for the administrators which one should be first to be cure. Of course, as you said, it should not be panacea, but still it provides a tremendous services, especially for quantitative software risk analyzes.

  4. HyunChul says:

    By the way, a vulnerability in CVSS is defined as a software defect which can be exploited by malicious users so that it can potentially cause negative impact.

%d bloggers like this: