Coming Changes to the Cisco Vulnerability Disclosure Process
Have you ever watched a movie called “The Abyss?” Near the end of the movie there’s a scene that I think is particularly relevant to this post. Our hero has to go 17,000 feet under the sea to disarm a nuclear bomb (watch the movie and you’ll know how the bomb ended up there and why our hero has the unenviable task of disarming it). And when he gets to the bomb, he’s instructed to “cut the blue wire with a white stripe — not the black wire with a yellow stripe” in order to disable it.
Easy enough, right? The problem is that our hero is using a glow stick as a light source, and under its yellowish light he can’t accurately determine which wire is which; they both look exactly the same. So after a bit of indecision, preparing to cut one but changing his mind, he goes ahead and cuts a wire. Lucky for him, it was the right one.
While here at the Cisco PSIRT we do not have to deal with such explosive situations (well, maybe not in a physical sense), we do, however, think that making security decisions based on incomplete data is certainly not a good approach. And this is why our vulnerability disclosure process keeps evolving over time.
Here are some of the changes we have implemented over the years, in order to provide our customers with more data on which to base their security decisions:
- The inclusion of CVSS (Common Vulnerability Scoring System) scores on our security advisories. CVSS is a vendor-neutral industry standard that conveys vulnerability severity and helps determine urgency and priority of response. It solves the problem of multiple, incompatible scoring systems and is usable and understandable by anyone.
- The inclusion of CVE (Common Vulnerabilities and Exposures) identifiers in our security advisories. CVE is a dictionary of common names (i.e., CVE IDs) for publicly known information security vulnerabilities. CVE IDs make it easier to share data across separate network security databases and tools, and provide a baseline for evaluating the coverage of an organization’s security tools.
- The bi-annual Cisco IOS Software advisory bundle — on the fourth Wednesday in March and September.
Based on our own analysis of the current security landscape, and feedback from our customers and partners, we think there is the need for another change to our process: an evolution that will provide our customers with additional data on which to base their security decisions when it comes to Cisco products.
Starting on January 2011, any bug that has been reported to the Cisco PSIRT but will not be disclosed as part of a Cisco Security Advisory will include a “PSIRT Evaluation” section within its Release Note. The Release Note Evaluation (RNE) section will include, where appropriate and relevant, base and temporal CVSS scores and one or more CVE IDs. However, not all bugs will include a CVSS score or a CVE ID.
The inclusion of a CVSS score will assist our customers in performing their triage and risk assessment, allowing them to better identify mitigations and corrective actions, if and when needed. In addition, including CVE IDs allows for easier correlation with external databases and other network and security management tools.
But why is it that some bugs will not get a CVSS score or a CVE ID? There are cases in which something is reported to us for evaluation but it isn’t an actual vulnerability. Such examples include (but are not limited to):
- Bugs that affect the confidentiality, integrity or availability of a product, but can not be forced to trigger by a third party
- New product features or options that may have an impact on device security
In these cases, we will still include a “PSIRT Evaluation” as part of this process change, but the bug will not be assigned a CVSS score or a CVE ID.
And last, but not least: I’m sorry but at this time we won’t provide wire cutters, glow sticks, diving gear or instructions on which wire to cut.Tags: