On the second Tuesday of every month, the Microsoft Security Response Center (MSRC) releases security bulletins to notify customers that security updates are available to help protect against vulnerabilities in Microsoft software.  In addition to notifying customers that security updates are available, Microsoft security bulletins also serve to provide customers with information about the security updates that customers can use for their risk assessment, testing and deployment of security updates, and verification that security updates were successfully deployed.

Security Bulletins and Severity Rating System

One important piece of information that the security bulletins provide to help with risk assessment is the Severity Rating system. The Severity Rating is based on an analysis of the technical fundamentals of the vulnerability itself and indicates the worst possible impact if an attacker were always able to successfully levy an attack against the vulnerability. It is important to keep in mind that the Severity Rating is focused solely on the technical elements of the vulnerability itself, the Severity Rating system presents an assessment that assumes that all vulnerabilities discussed can be successfully exploited all the time: it doesn’t assess environmental factors such as the overall threat environment or the level of effort required by an attacker to successfully attack a system. The Severity Rating system is intended to provide customers with an initial, baseline assessment of the severity of the vulnerability based on our analysis of the technical details of the vulnerability. Customers can use this information to help in their own risk assessment process to prioritize the testing and deployment of security updates.

In addition to the individual security bulletins, as part of the regular monthly release, the MSRC also provides a security bulletin summary that provides an overview of all the month’s security bulletins. The bulletin summary lists the bulletins' executive summaries and affected software, providing an overall and comparative view of the month's release. For an example, see this Microsoft Security Bulletin Summary.

Integrating Exploitability Index with Severity Ratings System

On Oct. 14, 2008, Microsoft added another piece of information to the bulletin summary to better help customers with their risk assessment process: the Exploitability Index. This section is a brief overview to explain how customers can integrate the Exploitability Index with the Severity Rating system into their own risk assessment process.

The Exploitability Index makes an assessment on the likelihood that code will be released that exploits the vulnerability or vulnerabilities addressed in a security bulletin within the first 30 days after that bulletin’s release. While the bulletin Severity Ratings assumes that all vulnerabilities discussed can be successfully exploited all the time, the Exploitability Index focuses on the potential likelihood that a successful exploitation of the vulnerabilities in the bulletin could occur based on currently known exploitation techniques.

In order to make this assessment, the Exploitability Index uses a number system along with a short description to denote likelihood of exploitation:

• 1 – Consistent Exploit Code Likely
  • This rating means that our analysis has shown that exploit code could be created in such a way that an attacker could consistently exploit the vulnerability.  For example, an exploit would be able to cause remote code execution of that attacker's code repeatedly, and in a way that an attacker could consistently expect the same results. This would make it an attractive target for attackers, and therefore more likely that exploit code would be created.  As such, customers who have reviewed the security bulletin and determined its applicability within their environment could treat this with a higher priority.
• 2 – Inconsistent Exploit Code Likely
  • This rating means that our analysis has shown that exploit code could be created, but an attacker would likely experience inconsistent results, even when targeting the affected product.  For example, an exploit would be able to cause remote code execution, but may only work 1 out of 10 times, or 1 out of 100 times, depending on the state of the system being targeted and the quality of the exploit code. While an attacker may be able to increase the consistency of their results by having better understanding and control of the target environment, the unreliable nature of this attack makes it a less attractive target for attackers.  Therefore, it is likely that exploit code will be created, but it is unlikely that attacks will be as effective as other, more consistently exploitable, vulnerabilities. As such, customers who have reviewed the security bulletin and determined its applicability within their environment should treat this as a material update, but if prioritizing against other highly exploitable vulnerabilities, could rank this lower in their deployment priority.
• 3 – Functioning Exploit Code Unlikely
  • This rating means that our analysis has shown that exploit code that functions successfully is unlikely to be released. This means that it might be possible for exploit code to be released that could trigger the vulnerability and cause abnormal behavior, but it is unlikely that an attacker would be able to create an exploit that could successfully exercise the full impact of the vulnerability. Given that vulnerabilities of this type would require significant investment by attackers to be useful, the risk of exploit code being creating and used is much lower. Therefore, customers who have reviewed the security bulletin to determine its applicability within their environment could prioritize this update below other vulnerabilities within a release.

The Exploitability Index is intended to be used in conjunction with the existing Severity Rating system to help customers better prioritize the testing and deployment of security updates and ultimately to more efficiently and effectively protect their environments.

Risk Assessment without Exploitability Index

For example, suppose that in one month, the MSRC releases five new security bulletins with the following severity ratings:

Based on this information, a customer may prioritize these security updates like this:

1. Immediate Testing and Deployment:
   • MS0X-001
   • MS0X-002
   • MS0X-005
2. Testing and Deployment within one week:
   • MS0X-003
3. Testing and Deployment within one month:
   • MS0X-004

In general, this prioritization reflects the Severity Rating system. All security updates rated as “Critical” receive top priority, and the non-critical updates receive lower priority.

Exploitability Index Combined with Severity Ratings

Now, taking these same hypothetical bulletins, we give them the following ratings on the Exploitability Index:

Taking this additional information into account in the risk assessment, a customer may choose a different prioritization:

1. Immediate Testing and Deployment:
   • MS0X-001
   • MS0X-002
   • MS0X-003
2. Testing and Deployment within a longer timeframe:
   • MS0X-004
   • MS0X-005

What has changed is that where before MS0X-005 was given immediate priority because it was rated as critical, it has now been reprioritized downward. Conversely, while MS0X-003 was given lower priority before, its priority has been increased. In both cases, these changes reflect the additional information provided by the Exploitability Index. Even though MS0X-003 is of lower severity than MS0X-005 (Important versus Critical), the fact that MS0X-003 is deemed likely to have consistent exploit code increases its overall priority. Conversely, the fact that MS0X-005 is deemed unlikely to have consistent exploit code decreases its overall priority.

Exploitability Index in Summary

Because the Exploitability Index is an estimate of possible future occurrences, it can and will at times be inaccurate. However, it does represent a good faith estimation based on the latest information and the experience of the MSRC. It can and should be used in conjunction with the severity rating system to help determine the priority of testing and deployment for security updates. Like the Severity Rating system, however, it is not meant to obviate or replace a customer’s own assessment and analysis of the security updates based on their own policies and procedures. It is meant to be a recommendation that supplements a customer’s own security assessment and remediation processes.