-
-
-
-
URL copied!
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:
- Secure Development Lifecycle: Importance & Learning
- Security Training for the Development Team
- Security Requirements For The Development Team
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):
- 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.
- 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.
- 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
- 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 |
- 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.
Top Insights
Best practices for selecting a software engineering partner
SecurityDigital TransformationDevOpsCloudMediaMy Intro to the Amazing Partnership Between the...
Experience DesignPerspectiveCommunicationsMediaTechnologyAdaptive and Intuitive Design: Disrupting Sports Broadcasting
Experience DesignSecurityMobilityDigital TransformationCloudBig Data & AnalyticsMediaLet’s Work Together
Related Content
The Chromatic Symphony: Unveiling the Palette of Productivity
We observe how color affects our ability to capture information quickly, laying the groundwork for understanding the importance of color in our environment. The blog concludes by posing intriguing questions about the prevalence of specific colors in corporate branding and its connection to the psychology of color theory.
Learn More
A Lakehouse Implementation using Delta Lake
A data lake is a centralized repository that enables a cost–effective storage of large volumes of data that provides a single source of truth (SOT). However, organizations face numerous challenges when using data lakes built on top of cloud-native storage solutions.
Learn More
Luxury Fashion Industry
This blog is an attempt to understand the difference in approach that a technology partner like GlobalLogic should consider while providing tech solutions to Luxury fashion customers. Let us first understand the Global market, challenges and opportunities for this market segment.
Learn More
Outsystems App Development : Best Practices Using The 3 Layer Architecture Canvas
The Architecture Canvas in Out Systems is a visual tool that helps software architects and developers to define and communicate the architecture of their applications effectively. It provides a structured way to capture key architectural decisions, components, and relationships in a single canvas or diagram
Learn More
Edge-Computing Paradigm: Survey and Analysis on Security Threats
The commencement of extensive applications of IoT devices in the world of information technology are generating massive amount of data. The deployment of various IoT devices/sensors within the complex interconnected networks give rise to raw data from sensors, processed and controlled data, decision making data providing intelligent solution etc. IoT provide a common platform (called IoT cloud) for all the networks and devices connected to those networks so that the analytics can be performed on data and valuable information can be extracted.
Learn More
Share this page:
-
-
-
-
URL copied!