Hey Security Teams: Developers Don’t Speak PDF

Hey security teams developers don't speak_Willy Wonka_11202012
Be honest – how many times have you seen interactions between security and development teams that essentially went like this:
Security Analyst: We did a security assessment of your application.
Developer: Really? Did you find anything?
Security Analyst: Oh yeah – all sorts of stuff; you guys are really bad at security. You can find a list of the results in this 300 page PDF document. I emailed it to you and printed out a copy for your convenience. There’s a color pie chart on the first page – pretty snazzy, right?
Developer: Yikes! Which of these things do we actually have to fix? We’ve got some big deadlines we’re working toward right now and my team doesn’t have a lot of free cycles.
Security Analyst: All of them. Because security is the most important thing in the world.
Developer: Riiiiight; I’ll go talk to my manager about that. Moving on – how do we actually fix all these different types of vulnerabilities? Some of my team knows about this stuff but not everybody.
Security Analyst: Well I’m not a developer, but I’m pretty sure they talk about that in the Appendix of the report…
Developer: Well I must say I’ve really enjoyed our interaction today and I look forward to these productive discussions in the future [places printed PDF document in a bottom desk drawer to be ignored]
Sound familiar? Hopefully not, but we see these types of interactions all too frequently so I suspect most readers have seen something like this at least once or twice. Giant PDF blobs are a horrible way to communicate with development teams, but this seems to be the default way that security folks reach out.
Ultimately, these interaction issues come from a mismatch between what security teams typically care about and what development teams care about as well as a misunderstanding about how developers often manage their workload. Security sees the world in terms of vulnerabilities and risk and developers see the world in terms of features and software defects. You have to be able to translate between these if you expect your software vulnerability remediation efforts to be successful. Also, asking developers to work their way through a giant PDF document is a huge inconvenience if they are used to managing their workload in a defect tracking system like Bugzilla or JIRA.
This is an area where we’ve been working with organizations for quite some time. Here’s a presentation we did at OWASP AppSecDC in 2009 titled “Vulnerability Management in an Application Security World”

And here’s another related presentation we did at SANS What Works In AppSec 2010 titled “Treating Security Vulnerabilities as Software Defects”

The second presentation really gets to the core issue – the results of the security team’s scanning and testing activities have to make the transition from being vulnerabilities (that security folks care about) to being software defects (that development teams care about) And the vulnerability data needs to be packaged in a way that makes sense to the developers and imported directly into their defect tracking systems.
Working with customers putting systems and processes in place to help bridge this gap was the inspiration for the defect tracker integration capabilities we built into the open source ThreadFix vulnerability management system. ThreadFix lets you pull the results of the various static and dynamic scanning activities as well as manual code review, threat modeling and penetration testing activities into a single database. From there you can connect to various defect tracking systems, package the vulnerabilities in a way that make sense to the developers who will be making the code changes, and then export them directly into the defect trackers. Once they are there, ThreadFix periodically pulls status updates from the trackers to notify security analysts when developers think they’ve successfully addressed the underlying issues. Then re-scans or re-tests can be scheduled.
Here’s what the process looks like:
1: Set up one or more defect trackers inside of ThreadFix. Several are supported out of the box, and it is easy to write plugins to support additional defect trackers.
Hey security teams developers don't speak_pdf1_11202012
2. Connect the application inside of ThreadFix to the user account you want to access the defect tracker. You can use different accounts (and different defect trackers) on a per application basis.
Hey security teams developers don't speak_pdf2_11202012
3. Filter through the list of vulnerabilities to determine which ones you want in a specific defect. In this case we’re grouping all of the cross-site scripting (XSS) vulnerabilities in the application into a single defect, but you can slice and dice the vulnerability data however you want. This is a great time to sit down with the development team lead to talk about what they will actually fix and when as well as how to best package the vulnerabilities so that they will be most easily addressed by the developers.
Hey security teams developers don't speak_pdf3_11202012
4. Continue the process until you have all of the vulnerabilities to be fixed consolidated into defects and sent over to the developers.
Hey security teams developers don't speak_pdf4_11202012
5. Now inside of ThreadFix you can see which vulnerabilities are mapped to specific defects as well as the current status.
Hey security teams developers don't speak_pdf5_11202012
6. Developers get to see the vulnerability data packaged up into defects inside of the tracking system they are already using – no need to refer to external PDF reports. You can also include links to external resources with information about how the developers should fix these vulnerabilities.
Hey security teams developers don't speak_pdf6_11022012
7. The developer makes the code changes to address the vulnerabilities and marks them as resolved in the defect tracking system.
Hey security teams developers don't speak_pdf7_11202012
8. ThreadFix periodically polls the defect trackers and identifies when issues have been marked as resolved by the development team so that the security team can schedule re-scans or re-tests.
Hey security teams developers don't speak_pdf8_11202012
Developers don’t speak PDF and if you ask them to as a prerequisite for fixing security vulnerabilities you are going to have a much harder time getting them to take action. Understanding the tools developers use and how they use them to do their work will help you reduce the friction involved getting code changes made to address security vulnerabilities.
dan _at_ denimgroup.com

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

Leave a Reply

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