{{announcement.body}}
{{announcement.title}}

Threat Modelling Tools Analysis 101 – OWASP THREAT DRAGON

DZone 's Guide to

Threat Modelling 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.

· DevOps Zone ·
Free Resource

Abstract 

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

threat modeling

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.

IoT Data Flow

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.

edit threat

diagram list

If you are aware of the Vulnerabilities, Threats, and their consequences, then you can fill the threat analysis yourself.

edit threat

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

  1. Drawing a Diagram Quickly — The drag and drop elements provides a quick way to add elements to the data model.
  2. 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.
  3. The Choice for Encryption – The ability to add protocol and choose whether a transaction is encrypted or not is a good feature.

Pitfalls

  1. No integration with CI/CD Pipeline.
  2. There is a cloud version that provides CI/CD integration only with GitHub projects.
  3. No guidance on threat mitigation or remediation.
  4. 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.

Topics:
devops, devops adoption, devops and cloud, devops and microservices, devsecops, information security, secure application training, secure apps, security, threat modeling

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}