Monitoring and Managing Security Vulnerabilities

The Microsoft Security Response Center (MSRC) identifies, monitors, resolves, and responds to Microsoft software security vulnerabilities.

• MSRC staffers monitor the secure@microsoft.com e-mail address 24 hours a day, seven days a week, and release monthly security bulletins that address new security vulnerabilities.
• Because security researchers post information about software vulnerabilities on security news lists and other public forums such as Bugtraq, the MSRC closely monitors these sites.
• The MSRC also tracks other potential sources of information to detect and respond to threats before they become worldwide incidents.

Working with Vulnerability Reports

When the MSRC receives information about a potential threat, it immediately:

1. Evaluates the possible impact of the threat on customers.
2. Gathers enough information to reproduce the vulnerability and determine which products might be affected.
3. Rates each vulnerability according to severity and the likelihood that it will be exploited.
4. Prioritizes how it will deal with the vulnerability.

After the MSRC verifies that a vulnerability exists, an MSRC program manager widens the investigation by contacting the product teams for affected products. While the product teams assess the vulnerability's scope and severity, members of the MSRC conduct a separate, parallel investigation. The researchers compare findings, and MSRC decides whether to fix the root cause immediately with an update, or to resolve the issue in a future service pack or new product version.

Creating a Security Update

If the severity of a vulnerability warrants an update, MSRC works with the product team to ensure the update is produced quickly and meets the MSRC quality bar.

MSRC also investigates other ways that customers and IT professionals can help protect themselves while they are evaluating the update for deployment. Meanwhile, MSRC Engineering team investigates the surrounding code and design and searches for other variants that could affect customers.

Testing Security Updates Internally

Product teams generally create updates quickly. Testing is the longest stage in the vulnerability management process. MSRC will not release an update until the update meets strict quality standards designed to ensure that the update will not interfere with software operation.

MSRC applies several levels of testing to scrutinize updates and tests various products in multiple ways. For example, a product like Internet Explorer®, which Microsoft supports in multiple versions across seven different operating systems over 20 languages, entails far more extensive testing than one with fewer interdependencies.

One hundred or more people might be required to work for many weeks to test a substantial update. Each team performs a test pass, sometimes referred to as "depth testing," which covers affected code as well as any dependent, related, or possibly affected areas of code.

Depth testing includes:

• Application compatibility testing.
• Testing of the actual component that the update addresses.
• Setup and install testing.
• Other usage scenarios that might be affected.

The teams also review test cases they draw from other areas of code, and they sometimes create new test cases to ensure the quality of a release. The teams then perform broader sets of tests that include deployment, detection, and partner testing, in which other teams and product groups at Microsoft test the update against their software. The teams also test updates against Microsoft line-of-business (LOB) applications to try to include scenarios that Microsoft customers might encounter in their own environments.

MSRC constantly reviews testing procedures and revises testing processes by adding new test cases and additional scenarios.

Testing the Security Updates Externally

Before the updates are made generally available, Microsoft also makes security updates available to a limited group of customers who can test them in a broad range of configurations and environments.

In its effort to achieve quality for Microsoft customers, the MSRC constantly reviews its testing procedures and revises its testing processes by adding new test cases and additional scenarios. For example, with the first monthly update of 2005, Microsoft formally implemented a closed beta program for testing security updates. The Security Update Validation Program seeks to ensure the quality of security updates by testing these security updates in environments, in configurations, and against applications that Microsoft cannot easily duplicate. As part of this quality control program, Microsoft makes security updates available to a limited group of customers who can test them in a broad range of configurations and environments before the updates are made generally available. Participants provide feedback based on their deployment experience to help identify potential compatibility problems before the MSRC releases the updates to the public.

Participants provide feedback based on their experience to help identify potential compatibility problems before MSRC releases the updates to the public.

This program provides only the security updates to participants. Participants are not given any information about the underlying vulnerabilities, the area of code being updated, or how to exploit the vulnerabilities. The program has reduced compatibility issues and helps enhance the quality of security updates significantly, making it easier for customers to deploy updates more quickly.