Risk and CVSS (Post 2)

Just before I published “Risk and CVSS (Post 1)” a week or so ago, there was some email strands on the SecurityMetrics.Org mailing list about the scoring methodology that CVSS uses. I had planned on commenting on the scoring as part of this series – but am only going to say that one should be very cautious about how they use such a score – especially in determining a risk rating or quantifying. I have seen multiple risk scenarios where the vulnerability is very high, but the loss event frequency is so low or the impact is low enough that the overall risk is pretty much nothing.

Another noteworthy comment from Risk and CVSS (Post 1) – would be surrounding PCI QSA’s that apparently think that they are providing value-add to PCI merchants by including CVSS vectors and partial scores (directly from the National Vulnerability Database) in their reports but not educating the merchant on how the CVSS “Environmental Metrics” can significantly lower the score that only represents the Base and Temporal metrics. From my perspective, this is where “value add” should come into play from a professional services contractor. If you are paying for consulting firms to assess your compliance or risk posture – do not hesitate to ask them their methodology for scoring or rating risk – you may not be getting your money’s worth.

Back to Post 2….

Despite a problematic scoring model and the suggestion that the CVSS vulnerability score is representative of the actual risk to an organization – the CVSS framework does allow one to consistently and quickly analyze a vulnerability. Yes – consistently and quickly.

After three weeks of analyzing CVSS, I believe that the components of the frame work that make up the three metric groups (base, temporal, and environmental) are great contributing factors (details or facts that influence or factor into risk elements) to the FAIR methodology. Below, I will attempt to quickly cover all three CVSS metric groups and how they map as contributing factors to FAIR. I think this exercise should also result in better understanding the elements that make an information security risk and their relationship with each other.

In CVSS, the “Base Metric” group ‘captures the characteristics of a vulnerability that are constant with time and across user environments’. Specifically, how the vulnerability is exploited (access vector), the complexity of the attack required to exploit the vulnerability (access complexity), number of times an attacker must authenticate pre-attack (authentication), the confidentiality impact to the asset that is vulnerable (confidentiality), the integrity impact to the asset that is vulnerable (integrity) and the availability impact to the asset that is vulnerable (availability).

FAIR & CVSS "Base Metrics" Mapping.


In FAIR, there is a risk taxonomy diagram (see above) that visually depicts risk and the elements that make up risk. With risk being at the top, it splits off into two branches: “loss event frequency” and “probable loss magnitude”; both of which are broken down further. The CVSS “Base Metrics” can be mapped to FAIR.

Access Vector – CVSS suggests this represents how the vulnerability is exploited: local (system) access, adjacent network, or network. You can read the CVSS documentation for details. In FAIR, I think this vector is a great contributing factor to the “Contact” and “Threat Capability” taxonomy elements. Contact – how often do I expect a threat agent to come in contact (not necessarily attack) a vulnerable system. “Threat Capability” – what percentage of the threat community do I think is capable of overcoming the security resistance present on the asset – let alone get access to it?

Access Complexity – CVSS suggests this measures the complexity of the attack required to exploit the vulnerability once an attacker has gained access to the target system. Metric values include: HIGH, very hard to exploit; MEDIUM, not easily exploited; LOW, easy to exploit. This CVSS metric maps to three different FAIR taxonomy elements: “Action”, “Threat Capability” and “Control Resistance”.
Action – How often will the threat agent attempt to attack my asset after it comes into contact with it? Threat Capability – what percentage of the threat community do I think is capable of overcoming the security resistance present on the asset? Control Resistance – My security controls are effective against what percentage of the threat population?

Authentication – In CVSS, this is the number of times the attacker must authenticate to a target in order to exploit a vulnerability; Multiple – two or more authentication instances, Single – one authentication instance, None – no authentication. Within FAIR, I have mapped this to “Control Resistance”.

The three other “base metrics” – confidentiality impact, integrity impact, and “availability impact” are all contributing factors to the “probable loss magnitude” branch of the FAIR taxonomy diagram. The metric values for each of these three impacts are – None, no impact; Partial, some impact, and Complete, total loss. Keep in mind that the three metrics are probably more reflective of state versus actual loss. So, the real impact can really only be measured or estimated by someone more familiar with the vulnerable system (its role in a business process and the amount of data on the system).

Since this is running into a long post, I will go ahead and wrap-up. We still have the “temporal” and “environmental” metric groups to look at. Another thought that came to mind while typing this was how access exploit methods can change over time. So any given CVSS score is reflective of the circumstances at that point of time. Thus, these scores should not be blindly used with no additional review of the metrics that make them up.

Finally, I want to start introducing risk scenarios on this blog. To do so, I need to create a fictitious company profile that will be referenced in all of the scenarios. Hopefully in the next few weeks I can get this profile created and published. Once it is done, I think there will be a strong enough foundation from an information standpoint to start publishing risk scenarios and having what I am sure is to be contested – yet meaningful – dialogue.


3 Responses to Risk and CVSS (Post 2)

  1. […] Hayes is taking me to town in terms of risk content with his last two posts on Risk & CVSS.  I told you his blog was going to be a good […]

  2. Walt Williams says:

    This is all for the good in determining a company neutral evaluation of the relative risk for CVSS issues, but any evaluation must be placed within the context of the system you’re protecting. XSS may be a larger issue for company X than for company Y based upon their business model.

    On a similar basis, SQL injection may be a smaller issue for company Y than for company X due to a lack of use of SQL databases under their web application.

    However the CVSS scoring will flag SQL Injection issues as more critical than XSS for both companies.

    Creating relative risk metrics from CVSS scoring won’t reflect the business model, the assets present, nor the real impact to the organization. As such, any effort to assign risk from CVSS scoring is doomed to be an inadequate model for analyzing risk.

  3. […] Risk and CVSS (Post 2) « Risktical Ramblings. […]

%d bloggers like this: