Hi, this is Art Manion, the Vulnerability Analysis team lead at the CERT Coordination Center (CERT/CC). For our first blog entry, I'd like to briefly explain our efforts to reduce software vulnerabilities.

One approach is to remove known vulnerabilities from deployed software (from another angle, this means reducing the amount of time that software contains a particular vulnerability). We consider this "traditional" vulnerability analysis and coordination:

1. find out about a vulnerability, whether from a public source, private report, or internal discovery
2. analyze the vulnerability and consider threat scenarios
3. identify and securely contact vendors that may be affected
4. coordinate disclosure to private and public audiences

Summarized neatly, this all sounds easy enough. In practice, though, things aren't so simple:

• There are a lot of vulnerabilities. Which ones are the most severe? What do I consider severe? What do you consider severe?
• How should I expend effort to get the most out of my limited vulnerability analysis and response resources?
• Which vendors produce, maintain, or distribute the vulnerable software? How do I contact those vendors and communicate securely with them?
• If I find a vulnerability, how do I report it, and are there any risks associated with reporting?
• Which disclosure practice do I follow? How much and what kind of information should go into an advisory?

The CERT/CC works closely with US-CERT (part of the Department of Homeland Security) on vulnerability analysis and coordination. For us, public vulnerability disclosure typically results in a US-CERT Technical Alert or Vulnerability Note.

Experience suggests that we will be dealing with vulnerabilities for years to come. Responding to vulnerability reports, as either a software producer or a consumer, should not be treated as an emergency or "one-off" event. Both software producers (vendors) and consumers (users) should develop vulnerability management capabilities that are built into normal business processes. For vendors, vulnerability management includes advertising ways to receive vulnerability reports, coordinating among internal business units and with external parties, being familiar with coordination and disclosure practices, and delivering vulnerability information and fixed software. For users, vulnerability management involves the following: awareness of new vulnerability information, inventory and patch management, risk assessment, configuration and change control, and consideration of procurement and support contract language.

Thinking about the subjective question about the severity of a given vulnerability has led us to research ways to make better decisions about how to respond to vulnerabilities. But that is a story for another entry.

What I've described above is focused on responding to vulnerabilities in already deployed software. We are also taking a more proactive approach to reduce the number of newly introduced vulnerabilities. This effort, which falls under the CERT Secure Coding Initiative, involves training developers, improving source-code analysis tools, and developing secure coding standards.

An administrative note--our blog is not going to have comments enabled, at least for now. If you'd like to provide feedback, please send us email using the link in the right sidebar. We'll consider updating entries based on feedback we receive.