DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DataOps
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • Techstrong.tv Podcast
    • Techstrong.tv Video Podcast
    • Techstrong.tv - Twitch
    • DevOps Unbound
  • Webinars
    • Upcoming
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • On-Demand Events
  • Sponsored Content
  • Related Sites
    • Techstrong Group
    • Container Journal
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Techstrong TV
    • Techstrong.tv Podcast
    • Techstrong.tv Video Podcast
    • Techstrong.tv - Twitch
  • Media Kit
  • About
  • Sponsor
  • AI
  • Cloud
  • Continuous Delivery
  • Continuous Testing
  • DataOps
  • DevSecOps
  • DevOps Onramp
  • Platform Engineering
  • Low-Code/No-Code
  • IT as Code
  • More
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps
    • ROELBOB

Home » Blogs » DevSecOps » Threat Modeling: The Why, How, When and Which Tools

Threat Modeling: The Why, How, When and Which Tools

Avatar photoBy: Debarghya Pandit on July 25, 2018 7 Comments

You may have heard of threat modeling as a structured activity for identifying and managing threats. Threat modeling can be applied to a wide range of things, including software, applications, systems, networks, IOTs and business processes.

Recent Posts By Debarghya Pandit
  • DevOps and Security: Be Ready to Shield Your Application
Avatar photo More from Debarghya Pandit
Related Posts
  • Threat Modeling: The Why, How, When and Which Tools
  • Threat Modeling as a DevSecOps Practice
  • Prioritizing Product Security With DevSecOps
    Related Categories
  • Blogs
  • DevOps Practice
  • DevSecOps
    Related Topics
  • development
  • security
  • threat modeling
Show more
Show less

Threat modeling’s motto should be, “The earlier the better, but not too late and never ignore.” Without threat modeling, your security is a gamble—and in today’s business environment,  you’re sure to lose.

TechStrong Con 2023Sponsorships Available

When you design an application, you will face several security issues during different phases of the software development life cycle (SDLC), and so having threat modeling in the SDLC from the beginning can help to safeguard that applications are being developed, with security built in.

Simply put, threat modeling is a procedure to identify threats and vulnerabilities in the earliest stage of the development life cycle to identify gaps and mitigate risk, which guarantees that a secure application is being built, saving both revenue and time.

Why Threat Modeling?

  • It is better to find security flaws when there is time to fix them.
  • It can save time, revenue and the reputation of your company.
  • To build a secure application.
  • To bridge the gap between developers and security.
  • It provides a document of all the identified threats and rated threats.
  • It offers knowledge and awareness of the latest risks and vulnerabilities.

How To Do Threat Modeling

Many people think only security engineers can do threat modeling. That’s not true. Anyone, from developer to software project manager, can threat-model. In fact, I would suggest they should also know a little bit of threat modeling as part of their work.

Let’s look at the elements of threat modeling:

Assets: What valuable data and equipment should be secured?

Threats: What the attacker can do to the system?

Vulnerabilities: What are the flaws in the system that can allow an attacker to realize a threat?

Steps to Threat Modeling

Step 1: Identify the assets (database server, file servers, data lake stores, Active Directory, REST calls, configuration screens, Azure portal, authenticated and anonymous web user, Azure AAD client apps, database users, DB administrators)

Step 2: Outline details of architecture on which the valuable asset is being processed. It may include the software framework, version and other architectural details (ASP.net web application connection to cloud data stores and third-party services using JWT tokens).

Step 3: Break down the application regarding its process, including all the sub-processes that are running the application. We create a data flow diagram (DFD).

Step 4: List identify threats in a descriptive way to review to process further.

Step 5: Classify the threats with parallel instances so that threats can be identified in the application in a structured and repeatable manner.

Step 6: Rate the severity of the threat.

Threat Modelling Methodologies

STRIDE (Uses application-centric approach)

  • Spoofing of user identity
  • Tampering
  • Repudiation
  • Information disclosure (privacy breach or data leak)
  • Denial of service (DoS)
  • Elevation of privilege

PASTA (risk-centric approach): Process for Attack Simulation and Threat Analysis

TRIKE (risk-based approach with unique implementation and risk-modeling process)

VAST (Visual, Agile and Simple Threat modelling)

OCTAVE (focused on assessing organizational (non-technical) risks that may result from breached information assets.)

When to use Threat Modeling

In simple words, at the early stages of the SDLC, perform threat modeling:

  • Every time there is a change in the system’s architecture.
  • After a security incident has occurred or new vulnerabilities are introduced.
  • As soon as the architecture is ready.

It is not a mandate to perform threat modeling at the early stages of the SDLC; you can still pick up threat modeling at any stages even if it is close to deployment.

Threat models are continuously changing, and the models you prepared today may not be efficient tomorrow. And it is difficult to say that you are covered from all the threats. But if you have performed threat modeling and done whatever it takes to minimize your exposure to security risks, at least the impact of something very bad happening will be manageable (again, hopefully, but not a guarantee).

Tools to Perform Threat Modeling

I have used two tools for threat modeling, both of which are free to use.

  1. OWASP Threat Dragon
  2. Microsoft Threat Modelling Tool 2016.

Let’s take a look at both the tools:

 

Microsoft Threat Modelling Tool 2016        OWASP Threat Dragon

 

Full version available for free (as of now)Alpha version available, flaws are still there. It is an OWASP incubator project, so it is at its early stage.
Installable desktop application available.The tool comes in two variants: an online web application for GitHub and second an installable desktop application.
Documentation easily available on Microsoft website. Default threat template is available.You have to search, default threat template is present
I found the UX better, unique methodology available, the user can understand threats better. Guidance and feedback in drawing a model.Good UX. Fun and engaging user experience.
Presently using this tool for threat modelling.Maybe I will use. I think will continue to improve.
End-user documentation is available.End-user documentation is also available. Automated threats.
Threat Grid, Template editor, Mitigating existing DFDs.Mitigating existing DFDs. Powerful threat mitigation. Rules have not yet been coded as it is the Alpha stage.
Comes with a base set of threat definitions using STRIDE categories.Even in its current stage (alpha), you can create threats from those STRIDE categories.

 

— Debarghya Pandit

Filed Under: Blogs, DevOps Practice, DevSecOps Tagged With: development, security, threat modeling

« DevOps Security: 3 Privileged Access Management Best Practices
Compuware Adds Testing Tools to DevOps for Mainframe Portfolio »

Techstrong TV – Live

Click full-screen to enable volume control
Watch latest episodes and shows

Upcoming Webinars

Evolution of Transactional Databases
Monday, January 30, 2023 - 3:00 pm EST
Moving Beyond SBOMs to Secure the Software Supply Chain
Tuesday, January 31, 2023 - 11:00 am EST
Achieving Complete Visibility in IT Operations, Analytics, and Security
Wednesday, February 1, 2023 - 11:00 am EST

Sponsored Content

The Google Cloud DevOps Awards: Apply Now!

January 10, 2023 | Brenna Washington

Codenotary Extends Dynamic SBOM Reach to Serverless Computing Platforms

December 9, 2022 | Mike Vizard

Why a Low-Code Platform Should Have Pro-Code Capabilities

March 24, 2021 | Andrew Manby

AWS Well-Architected Framework Elevates Agility

December 17, 2020 | JT Giri

Practical Approaches to Long-Term Cloud-Native Security

December 5, 2019 | Chris Tozzi

Latest from DevOps.com

Stream Big, Think Bigger: Analyze Streaming Data at Scale
January 27, 2023 | Julia Brouillette
What’s Ahead for the Future of Data Streaming?
January 27, 2023 | Danica Fine
The Strategic Product Backlog: Lead, Follow, Watch and Explore
January 26, 2023 | Chad Sands
Atlassian Extends Automation Framework’s Reach
January 26, 2023 | Mike Vizard
Software Supply Chain Security Debt is Increasing: Here’s How To Pay It Off
January 26, 2023 | Bill Doerrfeld

TSTV Podcast

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays

GET THE TOP STORIES OF THE WEEK

Most Read on DevOps.com

What DevOps Needs to Know About ChatGPT
January 24, 2023 | John Willis
Microsoft Outage Outrage: Was it BGP or DNS?
January 25, 2023 | Richi Jennings
Five Great DevOps Job Opportunities
January 23, 2023 | Mike Vizard
Optimizing Cloud Costs for DevOps With AI-Assisted Orchestra...
January 24, 2023 | Marc Hornbeek
A DevSecOps Process for Node.js Projects
January 23, 2023 | Gilad David Maayan
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

© 2023 ·Techstrong Group, Inc.All rights reserved.