Enterprise Vulnerability Metrics, The Plan and Data Points

January 20th, 2009 | by wadew |

Some time back I posted about designing and implementing the processes and tools which would enable me to track vulnerabilities affecting the enterprise throughout their security life cycle (identification to mitigation validation). In addition to providing a central repository for all enterprise vulnerabilities, I also wanted to make sure that we could use the metrics derived from this data to support investments in other areas of IT Security. My target was to have everything ready to start tracking vulnerabilities on the first day of business in 2009.

The data points I decided to track were primarily aimed at providing visibility into how vulnerabilities were identified, who was responsible for them, establishing an enterprise risk profile, and categorizing vulnerabilities according to risk factors. The following is a more detailed list of the metrics I’m tracking and their intended purpose.

The Data Points

Report Source – Tracking where the vulnerability reports are originating from. As options, I decided on direct report, findings from automated scanning, and all relevant existing security processes (security assurance, incident response investigation, etc) as sources.

System Type – Tracking the type of system affected by the vulnerability. As options, web applications, desktop applications, hosts/networks/operating systems, and web platforms seem to encompass all major system types.

Vulnerability Class – Being able to abstract individual vulnerabilities into something that is digestible by a non-technical audience is critical in this field. The National Vulnerability Database (NVD) has adopted a cross section of the Common Weakness Enumeration (CWE) hierarchy that is broad enough for the diversity of vulnerabilities most enterprises would encounter. For more information, checkout the CWE page on the NVD website, http://nvd.nist.gov/cwe.cfm.

Impact Ratings - Giving us a smart way to answer the “how bad is it?” question. The NVD has developed a framework (Common Vulnerability Scoring System – CVSS) where the characteristics of the vulnerability are supplied and the high, medium, low ratings for risk, severity, and impact are derived mathematically based on the supplied characteristics. The mathematical formula for the computation is available in the CVSS documentation, but I had a different idea for computing the h/m/l ratings. First, here are a few of the characteristics, their ratings, and descriptions:

Access Vector (AV)

Local - vulnerability can only be exploited from the local system.
LAN - vulnerability can only be exploited from the local area network.
Network - vulnerability can be exploited from the internet.

Authentication (AU)

User - User level authentication is required to exploit the vulnerability.
Admin/Root – Administrator/root level authentication is required to exploit the vulnerability.
None - No authentication is required to exploit the vulnerability.

Remediation Level (R)

Official Fix – The vulnerability has been fully remidiated and tested according to guidance given by security staff.
Temporary Fix – The vulnerability has been mitigated temporarily while a permanent solution is devised.
Workaround – A workaround exists to circumvent the vulnerability.
Unavailable – No remidiation is available for the vulnerability.
Not Defined – Remediation for the vulnerability is unknown.

Additional impact ratings include Access Complexity (AC), Confidentiality Impact (C), Integrity Impact (I), Availability Impact (A), Exploitability (E), and Report Confidence (RC). Each of the values associated with the impact ratings is assigned a whole integer from 1 – 3. For impact ratings where there are more then 3 options, I found that in each case, 2 of the options were close enough to be assigned the same value. For determining which value I would assign to each impact rating, I assumed the greater the value of the impact rating, the more serious the vulnerability for the given impact. For example, for Authentication, User is assigned a value of 2, Admin/Root a value of 1, and None a value of 3. I then weighted each impact rating based on the importance attributed to the impact. For example Access Vector (weight of 2) is much more of a factor when determning risk than Report Confidence (weight of 1). To further clarify the impact of a vulnerability, I wanted to produce ratings for risk, severity and probability which are determined with the following equations:

Risk: (2*(av) + 2*(ac) + 2*(au) + c + i + a + 2*(e) + 4*(r) + rc)/15.
Severity: (c + i + a + 2*(e) + rc)/6.
Probability: (2*(av) + 2*(ac) + 2*(au) + 4*(r))/10.

Once the risk, severity and probability have been determined, I use the following ranges to assign high, medium, and low:

High: >= 2.00.
Medium: >= 1.00 and <= 1.99.
Low: >= 0 and <= .99.

Contact Information – Tracking who is reporting the issues, and who is responsible for fixing them. For each contact entered into the system, I wanted to capture their name, contact information, business unit (only for enterprise contacts), and their manager (again, only for enterprise contacts). The purpose of the contact information data points is to be able to determine which group within the enterprise we can target for education regarding specific topics in security. For example if we find that product team X has an abnormally high number of input validation vulnerabilities, we could justify investing in some XSS and SQLi training and know that it will be beneficial.

URL – I wanted to be able to present the data by fully qualified domain name (FQDN) to easily present the data to site owners.

Other - In addition to the data points mentioned above, I’ve also provided inputs for tracking of CVE numbers and internal ticket tracking system numbers. While this isn’t particularly relevant to vulnerability tracking, it will give my management a tie in to existing processes.

Provided that the data entered into the vulnerability tracking system is reliable and up to date, answering the “What’s wrong?“, “How widespread?“, “Who’s responsible“, “What’s the exposure?“, “What if we don’t fix it?“, “Where should we invest resources?“, and “How’s the security?” questions should be no problem from here on out.

Tags: , , , , ,

blog comments powered by Disqus