Threat Modeling Tools Analysis 101 – OWASP THREAT DRAGON
Key DevSecOps solutions available and their benefits and pitfalls through a series of evaluating different tools for Technical Architects and Engineering Teams.
Join the DZone community and get the full member experience.
Join For FreeAbstract
An interconnected world with an increasing number of systems, products, and services relying on the availability, confidentiality, and integrity of sensitive information is vulnerable to attacks and incidents. Unfortunately, the threat landscape expands and new threats, threat agents, and attack vectors emerge at all times. Defending against these threats requires that organizations are aware of such threats and threat agents. Threat modeling can be used as part of security risk analysis to systematically iterate over possible threat scenarios.
The motivation for this research came from the constantly growing need to acquire better tools to tackle the broad and expanding threat landscape present. One such tool to help to categorize and systematically evaluate the security of a system, product, or service, is threat modeling.
Problems With Shifting Left in Designing Secure Applications
It is believed that security systems are a corollary indicator of high-quality systems and hence it adds value to catch these defects early in the system design and development stages. However, every Engineering team and Technical Architect is always trying to find a solution to implement threat modeling into their existing DevOps Ecosystem.
The key challenge is finding ways to adopt a security framework for designing robust enterprise applications, as it is becoming difficult to stay updated with ever-changing attack surfaces and threats and vulnerabilities.
Available Solutions, Benefits, Pitfalls, and Recommendations
As a DevSecOps practitioner and Security Architect, I will like to share some of the key solutions available and their benefits and pitfalls through this series of evaluating different tools. We used a parameterized technical analysis and rating system for this evaluation. The key factors considered in this analysis are given in the table below.
Our in-depth analysis and recommendation are going to be useful for teams who are planning or in the process of shifting left in their organizations or projects towards DevSecOps. The Key Audience for this report is Developers, Technical Architects, Business Analysts, IT, and Operations Teams of different experience levels.
Parameters |
Score 3 |
Score 2 |
Score 1 |
Learning Curve and time to create a model |
If the learning curve is small and time to create a model is less than an hour it is user friendly for the majority of the target audience. |
It is learning curve is medium and time to create a model is more than 1 Hr. but less than 3 Hrs. and it can be used by 30-40% of the target audience. |
If it is difficult to learn and time to create a model is exponentially large use by the target audience. |
Ease of creating Threat Model (UX) |
If the user experience is high and it is easy to create and understand the threat models created by another team |
If the UX is okay, but different teams can understand the design created by the other team. |
If created by someone but the threat model is difficult to understand |
Provision for pre-built templates |
If many templates are available |
If a few templates are available |
If no templates are available |
No. of Threat Modelling Frameworks Supported |
More than 3 Frameworks |
1 0r 2 Two frameworks |
No Framework support |
Design View |
Availability of stencils and option to add stencils or upgrade stencils |
Availability of stencils but no option or difficult to customize |
Standard Stencil |
Available Documentation |
Available and continuously updated documentation |
Available documentation but hard to follow through |
Zero Documentation or basic documentation. |
Analysis View |
Thorough Analysis with remediation. |
The analysis only with no suggested remediation |
No Analysis of only Design |
Regular Updates |
Continuous and Frequent Updates |
Regular or Periodic updates but large intervals |
No Updates since in the last 6 months |
Cost |
Open Source/ Pay-Per-Use/ User-based Licensing |
Open Source/User Licensing/Paid (another model) |
Paid |
Integration in CI/CD Pipeline |
Possible and plugins available |
Possible but hard to integrate |
Not Possible |
OWASP Threat Dragon
In continuation of my previous article on the assessment of Microsofts Threat Modelling Tool, we proceeded further with evaluating OWASP Threat Dragon. In this series, I am presenting my opinion on OWASP Threat Dragon. I tried to develop and execute the same use case of an IoT Data Flow to study the usability to identify the Threats, Vulnerabilities, and Remediation proposed by these tools below.
If you want to see an analysis of my previous assessment on Microsoft Threat Modelling tool do not forget to view the article on DZone – Threat Modelling 101
I tried to create the data flow using OWASP Threat Dragon and below is my finding and opinion on the benefits and pitfalls of using the tool.
OWASP Threat Dragon uses the same STRIDE Modelling Framework as a baseline for its Threat Modelling; however, it provides you the option to add your threats but does not provide you to change the framework. However, the source code is available on Github, if you want to contribute towards embedding other frameworks like ATTACK TREES, TRIKE, or PASTA.
The OWASP TD provides a standard DFD stencil for model creation which is simplistic for visualizing system components, data flows, and security boundaries.
The tool provides a design view to add models and a small toolbar for analysis. You can use the sidebar to click on the stenciled element for them to appear on the canvas. Then you can drag them anywhere. Working with solid elements like processes and data stores is easy. However, editing the line elements and flows is a tedious effort. I found Microsoft user experience is better than OWASP TD.
However, it shines on one aspect of drawing threat boundaries, which was a good experience than drawing the same on MSTM. However, it doesn’t provide any additional value.
There are no additional stencils available in default download and you cannot add stencils in the application.
Analysis of the threats is a tedious task as the same is partially automated. It is not as comprehensive as MSTM analysis. View the below screenshots for comparison.
OWASP provided the functionality to add threats and one thing which I liked was adding and modifying threats was easier, but if you are a Junior Developer, who is not trained or aware of Threats then the OWASP TD is not of any use wherein MSTM can still be used by a Junior Developer or IT Team member as it provides generic threats and suggests remediation.
OWASP Automated Threat Modelling has very limited availability of common threats and they are generic with no remediation. However, I liked the process of evaluating the risks one by one which tends to finish threat modeling within a specified time. The overall Threat Analysis tool almost an hour but the output is way below the output of the Microsoft Threat Modelling tool.
If you are aware of the Vulnerabilities, Threats, and their consequences, then you can fill the threat analysis yourself.
However, it does not provide a single view to view all the threats detected. You have to click on each element to view and analyze the threats. This is where Microsoft Threat Modelling Tool outshines the output and user experience and adds more value.
It also fails in providing any report sharing capabilities.
I found the following benefits of using the tool.
Key Benefits
- Drawing a Diagram Quickly — The drag and drop elements provides a quick way to add elements to the data model.
- Marking Out of Scope — The ability to mark certain elements out of scope adds value for incremental threat analysis or when different teams are involved in Threat Modelling. Teams can choose their area of scope.
- The Choice for Encryption – The ability to add protocol and choose whether a transaction is encrypted or not is a good feature.
Pitfalls
- No integration with CI/CD Pipeline.
- There is a cloud version that provides CI/CD integration only with GitHub projects.
- No guidance on threat mitigation or remediation.
- No ability to provide comprehensive easily understandable reports.
Here is my Scoring for the OWASP THREAT DRAGON.
Parameters |
Highly Rated |
Good To Use |
No Value Add |
Learning Curve |
X |
||
Ease of creating Threat Model (UX) |
X |
||
Provision for pre-built templates |
X |
||
No. of Threat Modelling Frameworks Supported |
X |
||
Design View |
X |
||
Available Documentation |
X |
||
Analysis View |
X |
||
Regular Updates |
X |
||
Cost |
X |
||
Integration in CI/CD Pipeline |
X |
My conclusion, OWASP Threat Modelling Tool is at a very nascent stage of development and might not add any value for the engineering, IT, or R&D teams to add this to their DevSecOps adoption.
We continue to focus and strive to build solutions for the most critical development and operations for the product and engineering teams and will continue to bring you across the next set of tools and their assessments for the engineering and R&D teams to evaluate which tools can be utilized and fit into their R&D activities.
Opinions expressed by DZone contributors are their own.
Comments