The Common Vulnerability Reporting Framework (CVRF) is a security automation standard intended to make your life easier by offering a common language to exchange traditional security and vulnerability bulletins, reports, and advisories. You can read more about it on the official ICASI CVRF 1.1 page, in my CVRF 1.1 Missing Manual blog series, or in the cvrfparse instructional blog. CVRF 1.1 has been available to the public for almost a year and we would like to know how its helped and how we can improve it. Please take a moment to take the poll and please feel free to share it with any interested parties. Comments are encouraged and welcomed. The more feedback we get, the more we can improve CVRF.
Wow! We just published our tenth bundle of Cisco IOS Software Security Advisories and what a ride it’s been!! Way back when in the fall of 2008 when we produced our first Cisco IOS Software Security Advisory bundle, we had no idea of the impact that this delivery format would have on us internally and, more importantly, on you -- our customers!! The decision to deliver the biannual (on the fourth Wednesday of every March and September) Cisco IOS Software Security Advisory Bundled Publication brought with it many challenges, process changes, and—in the end—a format for Cisco Vulnerability Disclosure that we hope addresses at least some of your concerns. This format was modeled after the scheduled monthly release used by Microsoft for years, known affectionately as “Microsoft Tuesday” and based on requests we heard through discussions with many of our customers.
“A security advisory was just published! Should I hurry and upgrade all my Cisco devices now?”
This is a question that I am being asked by customers on a regular basis. In fact, I am also asked why there are so many security vulnerability advisories. To start with the second question: Cisco is committed to protecting customers by sharing critical security-related information in a very transparent way. Even if security vulnerabilities are found internally, the Cisco Product Security Incident Response Team (PSIRT) – which is my team – investigates, drives to resolution, and discloses such vulnerabilities. To quickly answer the first question, don’t panic, as you may not have to immediately upgrade your device. However, in this article I will discuss some of the guidelines and best practices for responding to Cisco security vulnerability reports.
It’s that time of year again, folks. On Wednesday of next week, the Cisco Product Security Incident Response Team (PSIRT) will release the first Cisco IOS Software Security Advisory Bundled Publication of 2013. As a reminder, Cisco releases bundles of Cisco IOS Software Security Advisories on the fourth Wednesday of March and September each calendar year. As is the case with the vast majority of our security advisories, vulnerabilities scheduled for disclosure in the upcoming bundle will normally have a Common Vulnerability Scoring System (CVSS) Base Score from 7.0 to 10.0.
Cisco SecCon 2012 brought together hundreds of engineers, live and virtually, from Cisco offices around the globe with one common goal: to share their knowledge and learn best practices about how to increase the overall security posture of Cisco products.
It is amazing to see how many definitions the word “hack” has out on the Internet. Just look at Wikipedia: http://en.wikipedia.org/wiki/Hack. In short, the word “hack” does not always mean a “bad” or “malicious” action.
I’ve had the opportunity and honor to present at SecCon several times, 2012 being my fourth year. My session this year was titled “Cisco PSIRT Vulnerability Analysis: What Has Changed Since Last SecCon”. As you probably already know (or might have guessed), I’m part of Cisco’s Product Security Incident Response Team (PSIRT). During my talk I went over an analysis of the vulnerabilities that were discovered, driven to resolution, and disclosed during this past year, as well as lessons learned from them. I also highlighted several key accomplishments Cisco has achieved during the last few years. For example, Cisco now has the ability to correlate and patch third-party software vulnerabilities. Additionally, we have grown Cisco’s Secure Development Lifecycle (CSDL) into a robust, repeatable and measurable process. As Graham Holmes mentioned in a recent blog post:
Our development processes leverage product security baseline requirements, threat modeling in design or static analysis and fuzzing in validation, and registration of third-party software to better address vulnerabilities when they are disclosed. In the innermost layer of our products, security is built-in to devices in both silicon and software. The use of runtime assurance and protection capabilities such as Address Space Layout Randomization (ASLR), Object Size Checking, and execution space protections coupled with secure boot, image signing, and common crypto modules are leading to even more resilient products in an increasingly threatening environment. Read More »