By Dan Cornell, CTO, Denim Group

I had the opportunity to lead a Peer2Peer session at RSAC 2016 that asked attendees to talk about how they do vulnerability management for different types of vulnerabilities. In particular, what I wanted to discuss were the similarities and differences in how organizations deal with network and infrastructure vulnerabilities versus application-level vulnerabilities. 

Who Attended? 

We had a capacity crowd at the session, and a couple of folks actually couldn’t make it into the room because we ran out of seats. So popular! The group was pretty diverse representing industries including high-tech, healthcare, government, and retail. They came from companies of all sizes, from well-funded startups to some of the world’s largest companies. This was great because we got to hear from folks with a wide-ranging set of perspectives.

Major Themes and Takeaways

Relative Maturity – Infrastructure/Network versus Application Vulnerability Management: As expected, most organizations had their network and infrastructure testing pretty well squared away, and many said that their scanning program basically ran continuously—finishing up coverage of their IP range and then starting over again immediately. Identified vulnerabilities get communicated to some sort of operations team to be addressed and, in general, most issues can be addressed. Application testing programs tended to be a lot less mature. Testing was not done as frequently and the resolution pathway for the identified vulnerabilities wasn’t as well-defined. In a handful of organizations, application vulnerabilities are being pushed to developer defect trackers. I view this as a “table stakes” requirement to start making headway in an application vulnerability management program. But overall the testing programs and vulnerability management protocols weren’t as mature for applications when compared with infrastructure and network vulnerabilities. Also it was more common to have a more centralized server operations team, versus application teams that were segmented off in different business units, making communication with those teams more challenging.

Product Vulnerabilities Versus Service Vulnerabilities: One point that came up early in the discussion was that organizations hosting and managing their own applications had materially different vulnerability-management workflows than organizations that shipped products to end-users to install. This is because in-house application vulnerabilities are “fixed” once you’ve deployed the updated code and configuration in your own environment, and vulnerabilities in products provided to end-users aren’t really “fixed” until your end-users have deployed the updates and fixes you’ve provided. So, vulnerability management for product vendors also includes additional steps to notify end-users of vulnerabilities and available updates, as well as providing support to get those updates deployed in the end-user environments. 

Bug Bounties Have Their Place: One participant related a number of interesting points about how their organization had made effective use of a public bug bounty program. They conceded that they received a lot of junk submissions, but, overall, found the quality of submissions was better than what they saw from automated scanning tools (“At least with a bug bounty submission, a human sent it in hoping that they’d get paid for it.”) Another piece of advice on using bug bounties was to triage the results and pay bug bounties quickly. This helps to maintain a good relationship with submitters and makes your program more attractive when compared to other available bug bounty programs. The participant did indicate that their bug bounty program was really only possible because they had a “giant website” and didn’t think they would have experienced the same success if they had a significant need to test internal-facing, partner-facing, or non-web applications. (I might suggest that public-facing mobile applications could benefit from bug bounty programs as well.)

How to Handle “Unpatchable” Vulnerabilities: A common lamentation from the group was that there were situations where:

• Certain supporting packages—like Java—had vulnerabilities identified in them too frequently to realistically be able to patch server-based systems requiring them, and
• Operating systems had been end-of-lifed in situations where systems requiring them unfortunately couldn’t be upgraded.

The folks suffering from the second situation seemed to be centered in the healthcare and government sectors, and everyone had problems with the first. The typical approach in these situations was to get “the business” to sign off on those vulnerabilities that can’t be fixed, to help share the responsibility for the risk being accepted. There was some great discussion on how to best talk about this risk. I think that we, as a profession, need to do a better job of knowing what to say and, possibly more important, knowing what not to say when communicating about risk with management and executives.

How To Apply This Knowledge?

As always, I think the best way to apply this knowledge is to take one or two points that resonate with challenge you’re facing in your job, and try them out. It might be looking at trying out a bug bounty program. Or it could be working to get a formal risk-acceptance signoff process put in place for vulnerabilities that are exceptionally hard to patch or fix. Whatever it is—go out and make a change. The real value of the RSA Conference in general, and the Peer2Peer sessions specifically, is the opportunity to hear from peers and not-quite-peers, see what they’ve found to be effective in their environments, and look to try those things out in your own. Do it!

Conclusions

I had a great time at this Peer2Peer session and I want to thank the folks at the RSA Conference for giving me the opportunity to facilitate. Even more so I want to thank the folks who participated in the session. We had great participation and a variety of opinions and experiences that were shared.

A globally recognized application security expert, Dan Cornell holds over 15 years of experience architecting, developing and securing web-based software systems. As Chief Technology Officer and Principal at Denim Group, Ltd., he leads the technology team to help Fortune 500 companies and government organizations integrate security throughout the development process. Cornell is an active member of the development community and a sought-after speaker on topics of web application security, speaking at international conferences including RSA Conference, OWASP AppSec USA and EU, and Black Hat Arsenal.