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 »

Tags: Cisco Security, cisco-seccon-2012, CSDL, intellishield, product security, psirt, SecCon, security, third party software

The practice of using Open Source Software (OSS) and other third-party software (TPS) to build products and services is well established. Not only can it create tremendous efficiency--why build an operating system or web server if you don’t need to?--it also allows individual products to leverage best-of-breed functionality. This best-of-breed functionality can be critical on today’s Internet as security and scalability are often difficult or even patently ignored until it is too late.

The use of TPS to build things has been so successful and is so widespread that many products may even be assembled from a majority of software written by unknown third parties. This practice is not without its challenges. One of those challenges is security.

How does the security of a product’s constituent TPS affect its own security? How does the creator of the product learn of, manage and ultimately resolve security issues that originate in the relevant TPS packages?

These are the types of questions I attempted to address during a recent presentation at O’Reilly OSCON 2012. During that session I touched on seven challenges and offered five tools that I believe can make a difference.

Our friends on the Cisco Security Marketing team have posted the slides from that presentation online at slideshare.net.

Is this an area of concern for you? If it is, I’d like to know how you are tackling it. What is working well? What is working not-so well?

Tags: open source, product security, security, third party software