Secure Engineering – Threat Modeling

Categories: SecurityTechnology

In my previous post, “Security Training for the Development Team,” I shared the experience of building a security training program for the development team. 

In this part of my Secure Engineering blog series, you’ll learn about another essential step of securing engineering: threat modeling. This blog provides an overview of threat modeling. It’s an important method, and some companies use its basic approaches to secure platforms and applications.

More recommended reading on Secure Engineering: 

Threat modeling is a process of identifying and mitigating potential threats. You can apply it to software, networks, business processes, and real-life situations. In the context of software security, it not only ensures security while developing the software but also develops the security culture and mindset of the team. 

Traditionally, threat modeling is a complicated and time-consuming process that is document-centric and manual, which is why most teams try to avoid threat modeling. But understanding and mitigating threats are becoming a critical part of the software development process and can no longer be avoided. Furthermore, if executed correctly, threat modeling pays for itself by reducing the number of security bugs, security patch releases, and attack possibilities. 

Teams should iteratively complete threat modeling during the design phase, although there isn’t a perfect threat model; threat modeling is never “done.” The team must find the right balance for threat modeling according to the security requirements and threat environment to create a ‘good’ threat model. 

A team can start threat modeling as soon as the basic design is ready. Generally, threat modeling has five steps (DCTMD):

  1. Define scope 

The team should first define the scope of threat modeling. Teams can use threat modeling for the entire platform, product, sub-system, or a single module or feature. Our recommendation is to start at the single module or feature level as the team does the detail designing because completing threat modeling for the complete platform or product can be overwhelming. Teams can use module or feature level threat models to easily build the platform or product threat model. 

  1. Create DFD

The data flow diagram will help the team visualize data flow and trust boundaries. Without a good DFD, it is difficult to understand all threats, and the team can miss some crucial threats. DFD details and complexity can be dependent on the security requirements and risks.

  1. Threat Analysis

Once a team has DFD(s), they can start with identifying and analyzing threats. There are many different threat modeling methods. Some of the most used include: 

  • STRIDE 
  • PASTA
  • LINDDUN
  • CVSS
  • Attack Trees
  • Persona non Grata

We recommend using STRIDE as it is easy to use, most mature, and focuses on identifying mitigation techniques and threats. 

Category Definition  Applicability
Spoofing Pretend to be someone or something else to gain access or trust. Identity and Process
Tampering Deliberately modifying data. Process, Data storage and Data flow
Repudiation Not able to track users’ actions. Identity, Process and Data storage
Information Disclosure Leakage of private and confidential information. Process, Data storage and Data flow
Denial of Service Making system or information not available Process, Data storage and Data flow
Elevation of Privilege Elevate the system access Process

 

Not all threats are equal, so a team needs to prioritize them. We recommend using likelihood and impact for this:

  • High Priority Threats = High Likelihood and High Impact
  • Medium Priority Threats = Medium Likelihood and Low Impact
  • Low Priority Threats = Low Likelihood and Low Impact

  1. Mitigation 

Once a team identifies all threats, the next step is to mitigate each valid threat. A simple STRIDE table can help a team with it.

Category Control
Spoofing Strong Authentication (like MFA) 
Tampering Encryption of Data at Rest, Data at Motion and Data at Use
Repudiation Logging, Tracing and Monitoring
Information Disclosure Encryption
Denial of Service Site Reliability
Elevation of Privilege Authorization

 

  1. Documentation 

Documentation is the last step of effective threat modeling. A team doesn’t need to create extensive documentation, but a team should create documentation they can refer to in future threat modeling or during design changes. Without good documentation, a team may need to complete another round of threat modeling. We recommend documenting the following:

  • Valid threats
  • Test cases for valid threats 
  • Mitigation details

Threat modeling is a specialized area, but the above details can help a team to have a basic understanding of what’s involved and begin the threat modeling process. Please feel free to contact us if you would like assistance with threat modeling.

Author

Author

Kulbhushan Bhardwaj

AVP Engineering and Global Security Practice Head

View all Articles

Top Insights

Innovators and Laggards: The Technology Landscape of 2019

Innovators and Laggards: The Technology Landscape of 2019

Digital TransformationPerspectiveAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology

Top Authors

Sonal Padole

Sonal Padole

Senior Project Manager

Vimal Dhale

Vimal Dhale

Senior Consultant Engineering

Arti Gupta

Arti Gupta

Sr. Manager, Engineering

Siddhi Thakkar

Siddhi Thakkar

Manager, Engineering

Neven Dimač

Neven Dimač

Software Engineer

Blog Categories

  • URL copied!