ThreadFix is currently optimized to help with vulnerability management – importing vulnerability data from various sources, performing triage on the imported vulnerabilities, and then communicating the triaged vulnerabilities to the tools that developers use for resolution. Some organizations have also been using ThreadFix to help track their threat modeling programs. By using some of ThreadFix’s capabilities in a slightly different way it is possible to centralize both threat and vulnerability tracking inside of ThreadFix.
Most of the organizations we work with using ThreadFix to track threats and threat models are using some variant of the Microsoft-style of threat modeling that relies on Yourdon-DeMarco data flow diagrams and the STRIDE threat classification taxonomy. Some of them are even using Microsoft’s Threat Modeling Tool. Other less formal efforts often use whiteboards and text documents to capture the assets, data flows, and identified threats.
The goals for these teams are typically:
- Have a centralized repository where they can store the artifacts from these threat modeling efforts
- Be able to track selected threats and their mitigations through the lifecycle of identification and resolution by the development team
The remainder of this article will look at how using the existing capabilities of ThreadFix can support these aims.
Tracking the Threats and Threat Models
To begin, we assume that the team has conducted their threat modeling exercise for an application, either resulting in an informal model:
Or a more formal one:
To track these raw threat models, teams can use ThreadFix’s ability to store files with an application. Analysts can upload these files from the Files tab on the Application page:
Image files can be viewed in the browser, and the files can also be downloaded for later user and editing. This isn’t fancy, but it allows for teams to store and track the threat models alongside all of the vulnerability data being managed inside of ThreadFix. Teams can refer back to the model and upload new ones as the application evolves.
Managing Threats and Mitigations
In addition to tracking the raw results of threat modeling activities, individual threats can be tracked in ThreadFix, assigned to development teams, and then the developers’ progress addressing these threats with mitigations can be tracked. This allows security teams to maintain lists of threats alongside vulnerabilities and keep tabs on the current security state of systems in development as well as in maintenance.
As mentioned before, ThreadFix is currently optimized for tracking vulnerabilities, so to track threats we have to characterize them as vulnerabilities so we have a place to store them. This is a little goofy but not a completely unreasonable thing to do. Using ThreadFix’s ability to track manually identified findings from penetration tests usually provides the best fit. Threats can be entered like this:
This will require the threat to be associated with a CWE type and something needs to be entered for either the URL or parameter field. Once that is done, the entry is tracked alongside the results of any vulnerability testing that might have been done against the system. To help highlight these items as threats, ThreadFix’s vulnerability tagging can be used. This allows analysts to filter and report specifically on items that have been created to track threats.
Creating a “threat” tag for items can be handled on the Customize -> Tag tag management page:
Then this “threat” tag can be applied to the items created as threats on the Vulnerability Details page:
After tagging these entries as threats, they can then be viewed on the main application page:
And can reported on via the vulnerability tag filter capability:
Now that individual threats have been entered in the system, they can be communicated to development teams via their defect tracking systems. This assumes that a defect tracker has been configured in ThreadFix and associated with the application for which we are tracking threats. The online defect tracker documentation outlines how to accomplish this.
To communicate the threat and recommended countermeasures to the development team, select it on the Application page and use the Action menu to Create Defect:
Then you can select the appropriate Issue Type for the issue tracker, and the form will be updated with the appropriate metadata from the defect trackers. This is an opportunity for security and development to create a custom template in the defect tracker that is specific to addressing issues identified during threat modeling. Based on the requirements of the selected issue type, the analyst can provide the appropriate data and submit the defect to the defect tracking system:
Now the threat and recommended countermeasures exists in the development team’s issue tracking system:
Development teams can then work through whatever process they have for assigning tasks to individual developers. When the task is marked completed in the defect tracking system, ThreadFix will update the status of the threat so security analysts can check the developer’s work and manually mark the threat as closed when they are satisfied with the outcome:
This approach provides:
- A centralized repository for storing threat and threat modeling content alongside vulnerability data,
- The ability to track specific threats through their lifecycle – from introduction by the security team, through communication to the development team, and finally to resolution, and
- The ability to use vulnerability tags to report specifically on the threats that are being tracked in the system.
- This is somewhat of a misuse of the vulnerability tracking capabilities of ThreadFix. For the developers reading this post, let’s call it a “function overload.” For the security folks, let’s call it a bit of a hack.
So there you have it – tracking threat models and threats inside of ThreadFix alongside vulnerabilities found by various types of testing. There are a couple of hoops to jump through, but it gives teams a “single pane of glass” and traceability throughout the threat identification and mitigation lifecycle.