Vulnerabilities

From The Secure Arc Wiki

The ability to trace full circle between the classification of an Information Asset to the threats that face the systems that protect them and the resulting impact of a breach is key to being able to select and justify the selection of the Security Controls applied to a solution.

CVSS is used as the basis for the vulnerability assessment, which focuses on vulnerabilities on Infrastructure Assets. This could be a buffer overflow bug in a web server or it could be a cross site scripting vulnerability in a custom built application.

The primary benefit behind using CVSS as opposed to other alternatives, such as STRIDE & DREAD, is that it is a very quantitative model. There is a low likelihood of two separate people coming up with a different rating for the same vulnerability. Where there are discrepencies, there should only be one correct answer.

Common Vulnerability Scoring System (CVSS)

Please refer to the CVSS Guide for the full CVSS specification, including the formulas used to calculate the scores. This section is intended to provide a relatively high-level overview of CVSS and explain how it fits in with the rest of the Secure Arc Reference Architecture. The content from the CVSS Guide that is replicated below is identified as such and used in accordance with the completely free and open standard position put forward by it's custodians.

CVSS is broken down into the following three separate assessment areas, each one contributing different parts of the overall score.

Base Score

Temporal Score

Environmental Score

Base Score

The Base Score is a measure of the vulnerability itself, completely independently of how easy it is to fix and how it impacts any specific organisation or project.

It is broken down into two main areas

Exploitability

Impact

Exploitability

The Exploitability section asks for a rating of three key areas

Access Vector

Access Complexity

Authentication

Access Vector

The Access Vector provides an indication as to how 'close' an attacker needs to get to the vulnerable system in order to exploit the exposure. A cross site scripting problem with an application, for example, may be exploitable from anywhere on the internet. Conversely, a permissions problem with an executable on a database server may only be exploitable if someone has local shell access to the host itself, which isn't exposed to the internet. In the latter case, the Access Vector would either be Local or Adjacent Network.

The available selections for the Access Vector are defined in the table to the right.

Access Complexity

The Access Complexity provides an indication as to how difficult it is to get to the vulnerable system and exploit the exposure. For example, if a web server accessible directly from the internet has an unpatched system service with a known vulnerability, it may require the attacker to get shell access with a valid username, password or private key before the vulnerability can be exploited. If all it takes is a large or malicious payload in a URL in a web browser, the Access Complexity will be Low.

The available selections for the Access Complexity are defined in the following table.

Authentication

The Authentication metric indicates how many times the attacker needs to authenticate to exploit the vulnerability. The strength of the authentication is not considered when performing this assessment.

The available selections for Authentication are defined in the table to the right.

Impact

In addition to the effort the attacker needs to make in order to exploit the vulnerability, part of the Base Score also measures the impact in terms of the CIA Triad of fundamental security principles:

Confidentiality

Integrity and

Availability

Be aware that this impact is solely based on whether someone can see, change or inhibit access to your Information Assets. It is explicitly not related to how valuable those assets are or the losses you will encounter if they are exposed. Those details come later in the Environment section.

Confidentiality Impact

This is a measure of how many or how much of an organization's Information Assets may be accessible to unauthorized users as a result of this vulnerability being exploited.

For example, if a custom built system allows SQL injection via one of the fields presented in a query form it may result in any of the following scenarios:

The injected SQL query will be executed such that

any and all tables and their data will be displayed to the attacker

only a specific subset of tables can be accessed by the injected SQL

the vulnerability does not display any data as a result of a successful SQL injection

The available selections for Confidentiality Impact are defined in the table to the right.

Integrity Impact

This is a measure of how many or how much of an organization's Information Assets may be modified by unauthorized users as a result of this vulnerability being exploited.

Taking the SQL injection example again, the Integrity Impact resulting from the vulnerability being exploited may take the form of one of the following scenarios:

The injected SQL query will be executed such that

any and all tables and their data can be modified or destroyed

only a specific subset of tables can be modified or destroyed by the injected SQL

the vulnerability does not allow any data to be modified or destroyed as a result of a successful SQL injection

The available selections for Integrity Impact are defined in the table to the right.

The kind of Value at Risk associated with Availability can include Service Level Agreements, online sales and transactions to customers, partners and suppliers. For organisations such as banks and other financial institutions, this can reach billions of dollars a day.

Taking up the SQL injection example again, the Availability Impact resulting from the vulnerability being exploited may take the form of one of the following scenarios:

The injected SQL query will be executed such that

all data is destroyed or inaccessible and the system is inoperable

only a specific subset of data is destroyed or inaccessible and therefore only part of the system will not work properly

the vulnerability does not have any impact on the availability of the system as a result of a successful SQL injection

The available selections for Availability Impact are defined in the table to the right.

Temporal Score

Once the Base Score for a vulnerability is calculated, there should be no circumstances under which it is modified unless actions are taken to address the vulnerability. The Temporal Score, however, explicitly covers properties of the vulnerability that do change over time. As a general rule, the Temporal Score helps to prioritize what vulnerabilities should be addressed first based on whether exploits are currently in the wild, how easy it is to fix and how confident you are of the source of these details.

The three temporal metrics that need to be assessed include:

Exploitability

Remediation Level

Report Confidence

Exploitability

This provides an indication as to the current state of the exploit in the wild, specifically in relation to whether there are known attacks being used and whether the knowledge or tools required to exploit the vulnerability are widely distributed. The assessment of this property is a moving target.

When the vulnerability is first discovered, there may be no attacks in the wild, but as time goes by and the vulnerability remains unpatched, attacks may have become widespread. As the state of the vulnerability's Exploitability changes, the value should be adjusted accordingly.

Building on the SQL injection example, if this was found in a custom built application, the Exploitability assessment would potentially come up in one of the following scenarios:

the problem was discovered as part of a security code review and there are no known attacks in the wild

as above, however in addition to being discovered in the code an example attack has demonstrated it's ligitimacy

the vulnerability is already known to be exploited by attackers in the wild and is usually successful

the vulnerability is able to be exploited automatically by a script, virus or worm or code is widely available for others to replicate the attack manually

The available selections for Exploitability are defined in the table to the right.

Remediation Level

Put simply, this is an indication of how 'fixable' the vulnerability is. When dealing with a vulnerability in a vendor supplied piece of software, the general process that is typically followed is to quickly implement a workaround solution that may mitigate the risk. Later a temporary patch may be provided by the vendor before eventually they deliver an official fix for the problem. To quote directly from the CVSS v2 Guide: "The less official and permanent a fix, the higher the vulnerability score is."

As the vulnerability moves through this 'lifecycle' the Temporal Score will be reduced.

The available selections for the Remediation Level are defined in the table to the right.

Report Confidence

Often vulnerabilities are reported in the media, but aren't confirmed until some time later. Depending on how trusted the source of the vulnerability report is, this will impact the score. As with the other Temporal Metrics, this value may change over time as the reported vulnerability is assessed further and confirmed or denied.

The available selections for the Remediation Level are defined in the table to the right.

Temporal Score Example

As an example, you have a system that has been up and running for some time, has millions of registered users. It handles and stores a reasonable amount of their personal details and credit card numbers. This system is served up by the Apache web server, version 2.0.17.

As this is clearly a real and very serious issue, you decide you had better act immediately. In this particular case, the CVSS score has already been completed on the CVE Entry, so only the Temporal and Environmental score is to be completed.

Based on the reliability of the vulnerability sources outlined above, the Report Confidence can be immediately set to "Confirmed."

The CERT Bulletin indicates that an official fix from Apache is available in the form of Apache version 2.0.39, as a result the Remediation Level can be set to "Official Fix"

A brief search on Google reveals a product called CoreImpact that automates the exploitation of this particular vulnerability, leading to a "High" Exploitability rating.

Environmental Score

This is where the magic is.

CVSS defines the Environmental Score as being the only part of the Vulnerability assessment that indicates how big a deal the vulnerability is to your particular organization, business unit or project. Without the Environmental Score, the Base Score and Temporal Scores are unable to answer the 'so what?' question on their own.

The magic in this case, is that we don't have to assess the ratings for the Environmental metrics. Instead, we refer back to the Infrastructure Asset definitions and Information Asset Classifications we've performed already and from there we can derive the ratings. Even better, the actual vulnerabilities themselves could simply be generated by a tool like Open VAS, which reports it's findings in accordance with the CVSS spec. In addition, it will indicate what the Infrastructure Asset is that it found the vulnerability on.

The first step to perform when initiating the Environmental Score assessment is to determine what Infrastructure Assets the vulnerability applies to. If the vulnerability is on the CRM Application Server, for example, we can immediately see that the CRM Database may also be vulnerable as it is a dependent Infrastructure Asset. A SQL injection vulnerability in the CRM Application may expose data stored in the CRM Database.

We can also see immediately what Information Assets are processed and transferred by the CRM Application and its dependents. In this case the only Information Assets transferred and stored by these two Infrastructure Assets is the Personal Data Information Asset. We can also see that there are 300,000 customers that may be exposed at either point in this scenario.

From here, we can derive the ratings in the following Environmental Score sections:

Collateral Damage Potential

The Collateral Damage Potential is all about what the impact to the organization is if the vulnerability is exploited. To distinguish this from the Base Score Exploitability and Impact, this is entirely related to what it means to this particular organisation and environment. The Base Score will indicate how easily exploitable it is and what kind of actions a successful attacker can perform, however if the target Infrastructure Asset is not responsible for anything of value, then the severity of the Base Score needs to be weighted down.

At this point we know what Information Assets are exposed and we know how many of them. We have already performed the Information Asset Classification that indicates what the rating is for that volume of those specific Information Assets being exposed and so we can just map the appropriate rating from the Classification table to the Collateral Damage Potential.

Where multiple Information Assets are potentially exposed, the Collateral Damage Potential takes the rating from the highest rated Information Asset.

The CVSS spec explicitly defines the available ratings for the Collateral Damage Potential, however as we are deriving them from the Asset Classification phase we will not have to make any selections here.

Target Distribution

The Target Distribution indicates how many of the servers in a given environment are exposed by this vulnerability. At the beginning of the Environmental Score assessment phase, we have already associated the vulnerability with one or more Infrastructure Assets and back at the Asset Definition phase we identified all of the Infrastructure Assets. At this point a simple division will give us the percentage of impacted servers, however we also have dependency information between Infrastructure Assets, so we can expand that to include servers that are indirectly exposed to the vulnerability as well.

Once that is performed, we have a simple percentage of Infrastructure Assets that are exposed to or by this vulnerability and we can then simply slot that into the CVSS definition ratings based on the following table:

Security Requirements

This is very distinct from the Base Score Impact defined earlier. The earlier assessment was in regard to whether Confidentiality, Integrity and/or Availability will be compromised if the vulnerability is exploited. This section is specifically in regard to whether each of those actually matters in the context of the system or business in question.

More specifically, whether it is important in the context of the exposed Information Assets.

In relation to CVSS, the Security Requirements in the Environmental Score provide a weighting to the Impact ratings in the Base Score. If the Confidentiality Impact is large and the Confidentiality Requirement is Low, then the Environmental score is reduced. If the Confidentiality Requirement is also high, the Environmental Score will reflect that as well.

The Security Requirements are broken down into the following

Confidentiality Requirement

Integrity Requirement

Availability Requirement

As before, these values are simply taken as the highest rated Security Requirements for the exposed Information Assets as identified above.

Vulnerability Definition

Once the assessment of a vulnerability is completed, we will have some concrete values to work from in order to make decisions on what should or shouldn't be fixed, how and when.

The diagrams to the right represent the CVSS metric selections for a specific Vulnerability. Note that the Environmental Score selections are grayed out as they are derived from the associated Assets rather than selected directly. The diagram below shows the resulting CVSS scores and Vectors.

You'll also notice that the Vulnerability Definition has a reference to a Defect ID. This is so that each Vulnerability can be mapped into your issue tracking system to allow it to be managed alongside all other defects. In many cases, security issues, particularly those in infrastructure, are left on a separate 'security to do list' that is not subject to the same kinds of rigors and processes as a typical defect management process.

With many Vulnerabilities to address and a finite amount of time and resources, the best way to present these is in the form of a bubble chart.

The vertical axis is tied to the Base Score, The horizontal axis is for the Temporal Score and the size of the Bubble indicates the Environmental score, or more succinctly, how big a deal it is to this organization. With this chart you can see, at a glance, all of the identified vulnerabilities with a simple means to compare them.

The higher and further to the right, the more urgently they should be fixed and the bigger the bubble the bigger the impact on the organization if the vulnerability is exploited. In the example chart to the right, the left most Vulnerability is less severe and easier to fix, but if it were exploited would have a much bigger impact on the organization.

Up Next

Up to this point we have only had to deal with quantitative numbers that can be easily tracked down, such as how many particular pieces of data are stored in a database, and from this we have derived the Environmental Impact, in line with the CVSS spec, of this particular vulnerability. What we don't have yet is how much it is going to cost. This is always the hard part because it is so difficult to map a potential exposure to potential lost revenue.

The Impact to the organization in business terms is handled in the next section.