Applied ThreadFix®: Security Teams Collaborating With Development Teams

Modern enterprises are distributed. Most ThreadFix deployments have stakeholders spanning development and security teams, and those team members are spread around the globe. To support these distributed organizations, ThreadFix has a number of collaboration features that make teams more efficient working across different stakeholder teams, as well as across geographies and time zones.

Getting security teams and developers communicating with one another is at the heart of the reason we built the ThreadFix platform in the first place. We saw so many communication antipatterns – mostly centered around security teams sending PDF documents to developers and (a) expecting developers to understand what they’d just received and (b) expecting them to care given the variety of other concerns on developers’ plates. Security testers did their thing – running scanners, doing manual testing – and then bundled up a bunch of data on vulnerabilities and then tossed them over the fence to development teams and were then shocked when developers ignored them. The problem wasn’t that developers didn’t care about security. I’ve had the opportunity to train lots of developers, and the “developer who doesn’t care about security” is largely a myth propagated by security curmudgeons. Rather, the developers had a bunch of data tossed in their laps without context by a group that seemed to have no concept of how developers do their jobs.

So what do successful security teams do when they want development – and now DevOps – teams to work with them to fix vulnerabilities? They need to communicate and collaborate better. This typically involves:

• Providing developers with better context about the vulnerabilities – why are they important, and how should they fix them?
• Communicate with the developers in the tools they’re already using – this means defect trackers like JIRA, not Excel or Adobe Acrobat.

This is a message we’ve been preaching for over 10 years – here are the slides from a talk I gave at OWASP DC in August 2009:

Vulnerability Management In An Application Security World from Denim Group

The reason we’ve been talking about this for so long is because we saw via our consulting practice that it works. And when the process gets run through ThreadFix it works even better, reducing the mean time to fix (MTTF) for vulnerabilities by up to 44%.

So what does this collaboration typically look like? First, the security team needs to get things started by culling false positives, reprioritizing vulnerabilities where appropriate, and capturing sufficient history, so auditors can understand what has transpired. Once they have a clean set of vulnerabilities, they need to determine which ones they actually need the development teams to fix. In a perfect world, the developers would fix them all. (Actually, in a truly perfect world, developers wouldn’t introduce the vulnerabilities in the first place; as an industry we’re not quite there yet. But maybe targeted training can make them better.) This isn’t a perfect world, and developers have a lot of work on their plates other than fixing security vulnerabilities. Trivial stuff like writing the new features and functions their business units are addicted to, fixing non-security-related bugs, and so on. Security teams have to be judicious in what they ask for.

Once you know what vulnerabilities you want to get fixed, you have to bundle them up into software defects – because defect trackers are the tools that development and DevOps teams use to manage their workload. Creating a new software defect for every vulnerability typically isn’t a great idea. This has the potential to overwhelm the development team with a flood of new defects. For many vulnerability types – especially technical vulnerabilities like those found by SAST, DAST, and IAST tools, that can be fixed with a small code change – you run the risk that it takes longer to administer the defect than it does to actually fix the code. So it pays to be friendly to developers and bundle the vulnerabilities in a manner that will make them easy to understand and fix, while minimizing the administrative workload.

ThreadFix allows you to bundle vulnerabilities in a number of different ways. The Pivot option in the Filters section allows you to display vulnerabilities grouped via a couple of options.

From there, you need to select the vulnerabilities to include in the defect to be created. One common strategy is to bundle a number of vulnerabilities of the same type together such that it makes a sensible task for a developer to tackle. Using the pivots and the Check All checkbox makes this configuration easy. Individual vulnerabilities can be checked to add them to a bundle as well.

Once vulnerabilities have been selected to bundle into a defect, ThreadFix reads the configuration from the attached defect tracker to import the critical configurations and customizations that the development teams have made to their tracking tools. This ensures that defects created from ThreadFix contain all the necessary fields for the defect type being created, so the defect can be seamlessly injected into the development team’s workflow. In addition, ThreadFix allows security analysts to provide additional information and more specific direction to developers as they understand the vulnerabilities and have prescriptive instructions on how to address the vulnerabilities. ThreadFix also allows you to customize the template used to craft the defect text and set defaults – the value of this being to allow for the most effective communication with a minimum amount of effort on the part of the security analyst.

With ThreadFix, this communication channel is bidirectional. ThreadFix maintains a link to the issue created in the external defect tracking system, allowing security analysts to navigate into the developers’ tools to see their progress in assigning and discussing the bug in their tool set. In addition, ThreadFix periodically checks the status of associated defects and updates that status in ThreadFix so that when development teams close out defects, security analysts can see that the developers believe them to be fixed.

In addition, filtering can be used to identify vulnerabilities in certain interesting statuses:

• Needs Scan – Vulnerabilities that have their associated defects marked as fixed, but where a scan that would confirm that the vulnerability had been addressed has not yet been run.
• Remediation Failure – Vulnerabilities that have their associated defects marked as fixed, but where a scan that should have confirmed that the vulnerability was fixed actually still found the vulnerability.
• Needs Verification – Vulnerabilities that have been closed out by a scanner, but where the associated defect is still open for some reason.

These filter options help streamline communications between security and development teams. Rather than security analysts being required to chase down different development team leaders to ask for status updates and confirm planned remediation schedules, they can centrally monitor progress from within ThreadFix and run filters to search for exceptional cases that may require attention.

One of the core reasons we built the ThreadFix platform was to get security teams and development teams working more effectively together. Contact us to get your teams collaborating like they should.

[Info regarding acrobats photo]