Hello! π When developing complex software systems today, security is not an option, but a necessity. However, simply writing ‘bug-free code’ is not enough. What’s truly important is to consider in advance, “How can an attacker compromise our service?”
The systematic methodology for finding the answer to this very question is ‘Threat Modeling’. Today, based on the threat modeling process presented on the OWASP community page, we will explore a 4-step guide to make your service even more secure! π
π€ Why is Threat Modeling Necessary?
Threat modeling is a structured approach to analyzing a system from the perspective of a potential attacker, rather than a defender, to identify, quantify, and find solutions for security risks.
It’s like “before building a house, reflecting in the blueprint where a thief might break in or where to evacuate in case of fire.” ποΈ It prevents unnecessary waste of cost and time and is central to the ‘Shift-Left’ concept of considering security from the early stages of development.
πΊοΈ 4-Step Threat Modeling Process
OWASP presents the threat modeling process in the following four key steps:
Step 1: Scope your work π
First, this step involves clearly understanding “what to protect” and defining the scope of analysis. In this step, you find answers to the following questions:
- Draw Diagrams: Visually represent how the system works and how data flows. Data Flow Diagrams (DFDs) are commonly used, clearly showing system components, data stores, processes, data flows, and trust boundaries.
- Key Elements of DFDs:
- External Entities: Users or other systems interacting from outside the system.
- Processes: System functions that process data or perform tasks.
- Data Stores: Where data is stored (e.g., databases).
- Data Flows: Paths data travels within the system.
- Trust Boundaries: Points where the level of trust changes as data flows (important!).
- Identify Entry Points: Identify all points where an attacker can interact with the application or input data (e.g., web pages, API endpoints, input fields).
- Identify Assets: Define everything valuable that needs protection (e.g., user personal information, financial data, service availability, company reputation).
- Identify Trust Levels: Define and document the level of access privileges the system grants to external entities (anonymous users, authenticated users, administrators, etc.).
|π‘ Key: This is a mapping exercise to draw the overall picture of the system and understand where an attacker might enter and what they might target.
Step 2: Determine Threats π΅οΈββοΈ
Once you understand how the system works, this step involves systematically identifying what types of threats can compromise the system. Threat classification frameworks like STRIDE are very useful here.
STRIDE Model (Microsoft’s Powerful Threat Classification Framework)
STRIDE helps identify threats by categorizing attacker goals into 6 types:
- Spoofing (μ€νΈν) π§βπ€βπ§: Attacks that involve impersonating someone else. (e.g., user account theft)
- Defense: Authentication
- Tampering (ν νΌλ§) π: Attacks that involve manipulating data or the system. (e.g., database alteration)
- Defense: Integrity
- Repudiation (λΆμΈ) π ββοΈ: Attacks where one denies having performed an action. (e.g., manipulating transaction history and then denying it)
- Defense: Non-Repudiation
- Information Disclosure (μ 보 λ ΈμΆ) π€«: Attacks where sensitive information is exposed. (e.g., personal information leakage)
- Defense: Confidentiality
- Denial of Service (μλΉμ€ κ±°λΆ) π«: Attacks that prevent system usage. (e.g., server downtime)
- Defense: Availability
- Elevation of Privilege (κΆν μμΉ) π: Attacks where lower privileges are used to gain higher privileges. (e.g., a regular user gaining administrator privileges)
- Defense: Authorization
In this step, for each element identified in the DFD (data stores, processes, etc.), apply STRIDE threat types by asking questions like “Is this part vulnerable to spoofing?”, “Can this data be tampered with?” and compile a list of threats.
Threat Analysis and Prioritization: Identified threats are deeply analyzed through a Threat Tree to understand how an attack might occur, and then ranked as ‘High’, ‘Medium’, or ‘Low’ by considering Risk Factors (e.g., ease of attack, scope of impact, potential damage). This helps prioritize which threats to address first.
|π‘ Key: Imagine and record all possible attack scenarios and types for our system from an attacker’s perspective.
Step 3: Determine Countermeasures and Mitigation π‘οΈ
Now, this step involves deciding how to defend against the identified and prioritized threats. A countermeasure is a protective action that prevents a threat from materializing or reduces its impact.
Risk Mitigation Strategies:
- Accept: Decide to accept the risk and document that decision. (Very rare and requires caution)
- Eliminate: Completely remove the system component causing the risk.
- Mitigate: Add security controls to reduce the likelihood or impact of the risk. (Most common strategy)
- Transfer: Transfer the risk to a third party, such as through insurance.
Develop an implementation plan by considering various mitigation techniques appropriate for each STRIDE threat type (e.g., encryption, authentication, authorization, filtering, throttling).
Create Threat Profile: Through this step, you can create a threat profile that clearly distinguishes whether each threat is ‘fully mitigated’, ‘partially mitigated’, or ‘still an unmitigated vulnerability’.
|π‘ Key: Decide which defenses to apply to the identified threats and develop an implementation plan for the most effective solutions.
Step 4: Assess your work β
Finally, this step involves verifying that the performed threat modeling work is complete and accurate. This step primarily consists of the following questions:
- Is there a diagram visually showing the system’s structure and data flow?
- Is a clear threat list compiled, including all identified threats?
- Is an appropriate list of security controls (countermeasures) defined for each threat?
- Is the documentation thorough?
If all these elements are satisfied, the threat modeling process can be considered successfully completed.
Synergy of Threat Modeling and Code Review: Threat modeling does not replace code review but complements it. By identifying and documenting system vulnerabilities early in development through threat modeling, code reviewers gain clear guidance on where to focus. This enables efficient and in-depth secure code reviews. π€
β¨ Conclusion
Threat modeling is not a one-time task. It is a continuous process that must be performed repeatedly as the system evolves and new features are added. By adopting the habit of looking at the system from an attacker’s perspective from the early stages of development and making threat modeling a routine, you will be able to create more robust and secure software.
We hope that all our services become as strong as a solid castle, and that today’s post has been helpful! π°β¨
Tags: OWASP, Threat Modeling, SDLC, STRIDE, Security Design, Secure Coding, ShiftLeft, DFD, Security Process
Leave a Reply