Threat modeling is becoming a viable method for better understanding an organization’s attack surface, its security threats and security requirements. When comparing ThreatModeler to Microsoft Threat Modeling Tool (TMT), it is important to understand the differences in threat modeling methodologies and functional designs of each solution. Here you will find a comparison matrix to highlight the many disparities.
Increasingly, Organizations are Focusing on Security
In recent years, there has been an increases in the volume and severity of enterprise security breaches. Automated and freely available exploit tools are also on the rise, making what was previously considered complex attacks relatively simple. Executives are responding by boosting security budgets to fund enhanced security activities. As a result, technology safeguards, processes, and strategies have substantially improved.
This ongoing maturation of security tools helps explain why the use of threat modeling is rapidly gaining momentum. Developing secure applications from the ground up is also being viewed as a “must-have” versus a “nice-to-have.” Integrating security into the SDLC early – also known as shifting security left – not only reduces the time and costs linked to fixing production vulnerabilities, but also minimizes application risk exposure enterprise-wide.
In short, the comparison that follows is intended to provide security professionals with an objective analysis of the Microsoft Threat Modeling Tool and ThreatModeler.
Microsoft Threat Modeling Tool (TMT)
For reference, Microsoft threat modeling tool is a replacement for its predecessor, Microsoft SDL (Secure Development Lifecycle), which was made available in August of 2011. For several years prior to the introduction of ThreatModeler, Microsoft’s public domain products were the most widely used threat modeling tools. Users of Microsoft TMT or SDL are required to create threat models using Data Flow Diagrams (DFDs) in order to represent applications and to perform threat modeling and as such, users of the Microsoft threat modeling tool are limited to this approach.
Assessment: Microsoft Threat Modeling Tool vs. ThreatModeler
To compare the tools, we used the following criteria: functionality, collaboration, reporting and other features. We not only conducted our own comparison, but we also had an independent source provide us with their findings, which have been incorporated below.
List of Criteria used to Compare MS-TMT with ThreatModeler
| Feature | Definition |
| Component-Based Design | Ability to build a threat model based on the components (web services, database services, ports, and protocols, etc.) |
Reports |
Ability to automatically generate reports that identify threats and their current status. |
| Built-in Threat Library | Pre-developed repository of common threats based on industry standards and best security practices. |
| Customizable Threat Library | Ability to add industry or organization-specific threats into the threat library. |
| Threat Management Dashboard | Dashboard that provides an at-a-glance current status of identified threats. |
| Customizable Data Elements, Widgets, Protocols, etc. | Ability to customize components according to enterprise application architecture. |
| Threat Library Updates | The frequency for updating threat libraries update with the latest threat data. |
| Web-based, Accessible by Browser | Ability for users to access the tool. |
| Enterprise Level Scalability | Ability to build and maintain 100s or even 1000s of enterprise-wide applications that reside on different infrastructure stacks. |
| Real-time Collaboration | Ability for multiple stakeholders to access the tool and make changes at the same time, in real time. |
| Role Based Access Control for Different Stakeholders | Ability to assign access and permissions based on assigned roles and responsibilities. |
| Integration Add-ons and APIs | Ability to provide bi-directional integration with other tools, technologies, and applications. |
| Actionable Output | Ability to provide specific guidelines for different stakeholders. |
| Re-usability and Repeatability | Ability to embed or reuse application threat model components for similar or related threat models, as well as the ability to interrelate individual threat models with an overarching threat model. |
| Organization-wide Security Policy Enforcement | Ability to use a centralized library to link threats to application components enterprise-wide and to be able to apply new threats to all existing threat models automatically. |
| Mapping Threats to Security Controls | Ability to define specific security controls and automatically correlate them with specific threats. |
| Secure Coding Guidelines | Ability to provide developers with the most relevant secure coding mitigation steps for each threat model component. |
| Network Component Hardening Guidelines | Ability to automatically provide hardening guidelines to secure different network components. |
| Threat Comparison and Trend Analysis | Ability to view trends across multiple releases of the same application or compare trends across multiple applications. |
| Technical Support | Product support for operational or functional assistance. |
| Time/Resources Needed to Build a Threat Model | Average time for one person to build a threat model for a mid-sized application. |
| Platform Independence | Ability for users to access the tool across all platforms. |
Comparison Results
|
Feature |
Microsoft threat modeling tool |
ThreatModeler |
| Component-Based Design | Yes | Yes |
| Reports | Yes | Yes |
| Built-in Threat Library | Yes | Yes |
| Customizable Threat Library | Yes | Yes |
| Threat Management Dashboard | Yes | Yes |
| Customizable Data Elements, Widgets, Protocols, etc. | Limited | Yes |
| Threat Library Updates | Limited | Monthly |
| Web-based, Accessible by Browser | No | Yes |
| Automated Threat Modeling for Live Cloud Environments | No | Yes |
| Enterprise Level Scalability | No | Yes |
| Real-time Collaboration | No | Yes |
| Group Based Access Control for Different Stakeholders | No | Yes |
| Integration Add-ons and APIs | No | Yes |
| Actionable Output | Limited | Yes |
| Repeatability and Re-usability | No | Yes |
| Organization-wide Security Policy Enforcement | No | Yes |
| Mapping Threats to Security Controls | No | Yes |
| Secure Coding Guidelines | No | Yes |
| Network Component Hardening Guidelines | No | Yes |
| Threat Comparison and Trend Analysis | No | Yes |
| Technical Support | No | Yes |
| Time/Resources Needed to Build a Threat Model* | 100 – 120 hours | 16 – 24 hours |
| Platform Independence | No (Windows-based) | Yes (Web-based) |
* Time/Resources needed to build a threat model for a medium-sized application were supplied by an independent source, who documented the time spent by using both products to build a threat model for the exact same application.
ThreatModeler’s web-based platform allows for easy accessibility and platform independence. Compared to Microsoft’s threat modeling tool, ThreatModeler offers more features for analytics, threat comparison, coding guidelines, re-usable models, real-time collaboration, and more.
The biggest selling point by far is the time it takes to build a threat model. Even without a security background, decision-makers and developers can create threat models quickly and easily understand what security next steps need to be taken.
Have questions regarding how the Microsoft threat modeling tool compares to ThreatModeler? Contact us and let us show you the difference.