RSA 2012 Peer2Peer: Why Aren’t We Fixing Vulnerabilities?

 rsa image001

 At RSA 2012 last week I ran a Peer2Peer session titled “Why Aren’t We Fixing Vulnerabilities?” We had a full house and lots of great discussion about why organizations don’t fix vulnerabilities as well as strategies some folks have used to accelerate progress. Some of the highlights:

  •  Across the board attendees were frustrated at how long it took their organizations to address vulnerabilities – both for infrastructure vulnerabilities as well as application vulnerabilities. I suppose that shouldn’t be surprising given the subject of the session…
  • Compliance was an often-used tool to spur action toward addressing vulnerabilities. Most organizations reported success in using compliance to get their firms to undertake some vulnerability identification and remediation activities. However this also often resulted in somewhat distorted priorities – systems out-of-scope for PCI were ignored and issues that were potentially riskier but not related to compliance were given less priority than activities required for a checklist approach to compliance.
  • One organization was preparing to roll out a program to publish data about the relative rates of vulnerability incidence between teams with the goal being to shame teams into improving their security. I thought this was an interesting way to “manage down” into the development teams and create some competition.
  • Several organizations also reported success using data transparency with management to “manage up” and better inform line-of-business owners about risks to the systems they relied on in an attempt to get them to require that vulnerabilities get fixed.
  • ·         Lots of folks had WAFs. Almost nobody was using them in blocking mode. One firm was using “virtual patching” to address vulnerabilities in 3rd party code that vendors wouldn’t or couldn’t fix.
  • One organization used financial incentives for system administrators and developers with a sort of internal “bug bounty” program. Vulnerabilities that had been identified were risk-ranked and bonuses were given to team members who addressed these vulnerabilities. All updates had to be run through the normal change management and validation processes for independent confirmation and they reported that this hadn’t so far resulted in any crazy externalities  such as people creating vulnerabilities just to get paid to fix them. There was a lot of interest in this approach and its potential to essentially create a risk-driven remediation economy within the business, but a huge sticking point was that getting the balance of the “remediation budget” versus the “features budget” was crucial to a successful program.

I always love these sort of free-form discussions and this Peer2Peer was no different. At the very least folks get to commiserate with others in similar challenging positions. And, if we’re lucky, everyone comes away with at least one or two ideas they can apply when they get back to work. Hopefully this session delivered on both counts.

Contact us for help managing your software security vulnerabilities.

–Dan

dan _at_ denimgroup.com

@danielcornell

Posted via email from Denim Group’s Posterous

About Dan Cornell

A globally recognized application security expert, Dan Cornell holds over 15 years of experience architecting, developing and securing web-based software systems. As the Chief Technology Officer and a Principal at Denim Group, Ltd., he leads the technology team to help Fortune 500 companies and government organizations integrate security throughout the development process. He is also the original creator of ThreadFix, Denim Group's industry leading application vulnerability management platform.
More Posts by Dan Cornell

Categories: Remediation

Leave a Reply

Your email address will not be published. Required fields are marked *