You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An important part of the DevSecOps initiative is Threat Modeling. Threat Modeling is a structured activity of risk identification and management. So in this part, we want to take look more into this topic.
2
+
Threat modeling is a crucial component of the DevSecOps approach, focused on identifying and managing risks in a structured way. Here’s a more detailed look at this topic:
3
3
4
4
### What is Threat Modeling?
5
-
This is a process of listing all the potential ways in which one can attack your application. The output of the process is a list of threat scenarios together with their mitigations.
5
+
Threat modeling involves enumerating all potential attack vectors on an application, producing a list of threat scenarios along with mitigations. This holistic and collaborative process ensures comprehensive coverage of potential threats.
6
6
7
-
Our approach should be holistic to cover all threats. To realize this, we should not focus only on a specific part of an application.
7
+
Another important note is that Threat Modeling is a **Collaborative** and **Repeatable** process and it is a process **NOT** a project!
8
8
9
-
Another important note is that Threat Modeling is a **Collaborative** and **Repeatable** process.
10
-
11
-
#### Process Outputs:
12
-
+ Diagrams
13
-
+ Security requirements
14
-
+ Non-requirements
15
-
+ List of threats / vulnerabilities and its mitigation
9
+
#### Key Outputs:
10
+
+**System Diagrams:** Detailed representations of the architecture and data flows.
11
+
+**Security Requirements:** Specific criteria for safeguarding the system.
12
+
+**Threat List:** Catalog of potential threats with mitigation strategies.
16
13
17
14
#### Terms:
18
-
+ Weakness
19
-
- A software defect or bug. (Ex: missing user email validation)
20
-
+ Vulnerability
21
-
- A weakness that can be exploited. (Ex: we can abuse the user email field to insert SQL statements)
22
-
+ Attack
23
-
- Target: the value of an attack
24
-
- Attack Vector: the path that the attacker can take to exploit a vulnerability
25
-
- Threat Actor: threat source.
26
-
+ Attack Surface
27
-
- Anything that can be obtained, used, or attacked by a threat actor.
28
-
+ Risk
29
-
- Risk = Impact * Likelihood
30
-
- Impact: Size of negative consequences that each risk brings.
31
-
- Likelihood: Probability of a risk to happen.
32
-
+ Approach
33
-
- Describes how one could start with the process.
34
-
+ Methodology
35
-
- Describes the process itself.
15
+
+**Weakness:** A software defect or bug. (e.g., input validation errors, missing user email validation)
16
+
+**Vulnerability:** A weakness that can be exploited. (Ex: we can abuse the user email field to insert SQL statements)
17
+
+**Attack:** Exploitation of vulnerabilities.
18
+
-**Target:** The objective of the attack (e.g., sensitive data).
19
+
-**Attack Vector:** The path that the attacker can take to exploit a vulnerability (e.g., web interface).
20
+
-**Threat Actor:** The threat source (e.g., hacker, insider).
21
+
+**Attack Surface:** Anything that can be obtained, used, or attacked by a threat actor.
22
+
+**Risk:** Impact and likelihood of a threat being exploited (Risk = Impact x Likelihood).
23
+
-**Impact:** Size of negative consequences that each risk brings.
24
+
-**Likelihood:** Probability of a risk to happen.
25
+
+**Approach:** Describes how one could start with the process.
26
+
+**Methodology:** Describes the process itself.
36
27
37
28
### Why Threat Modeling?
38
-
As the main reasons for using threat modeling, we can say:
39
-
+Pro-active approach to finding threats
40
-
+Increasing efficiency by reducing cost
41
-
+A better prioritization based on bugs and a mitigation plan
42
-
+A better understanding of the system
29
+
As benefits ofthreat modeling, we can say:
30
+
+**Proactive Threat Identification:** Early discovery of potential security issues.
31
+
+**Cost Efficiency:** Mitigating threats early reduces remediation costs.
32
+
+**Prioritization:** Focus on the most critical vulnerabilities.
33
+
+**System Understanding:** Better comprehension of system interactions and data flows.
43
34
44
35
45
36
### Who should be involved in the threat modeling?
46
-
+ Architect - knows how the application has been designed and how data flows across.
47
-
+Developer - knows how the application was built, and the interactions between components.
48
-
+ Tester - knows the requirements, and what the application is supposed to do.
49
-
+ Security expert - knows about specific attack factors and vulnerabilities.
37
+
+**Architect:** Knows how the application has been designed and how data flows across to ensure proper design and flow.
38
+
+**Developer:** Knows how the application was built, and the interactions between components to provide insight into code and interactions.
39
+
+**Tester:** Knows the requirements, and what the application is supposed to do, to validate requirements and behavior.
40
+
+**Security expert:** Knows about specific attack factors and vulnerabilities to identify and assess security risks.
50
41
51
42
But, the best answer to this question is, **it depends on the organization**.
52
43
@@ -56,35 +47,100 @@ Ideally, Threat Modeling should be performed early in the software design proces
56
47
In an Agile environment, Threat Modeling should be done during each sprint. But, we do not have to start from scratch each time. Each sprint only requires an iteration of the previous threat model output.
57
48
58
49
## Selecting the Right Approach & Methodology
59
-
### Methodology
50
+
### Common Methodologies
60
51
Common Threat Modeling methodologies are:
61
-
+ PASTA
62
-
+ Microsoft Threat Modeling
63
-
+ OCTAVE
64
-
+ TRIKE
65
-
+ VAST
52
+
+**PASTA (Process for Attack Simulation and Threat Analysis):** Focuses on business impact.
53
+
+**Microsoft Threat Modeling:** Uses data flow diagrams (DFDs) to identify threats.
- Categorize actors by their access level and intent.
85
+
2. Attacker Profiling:
86
+
- Understand attackers’ goals and capabilities.
87
+
- Use threat intelligence sources to gather information about typical attack methods.
88
+
3. Threat Enumeration:
89
+
- List potential attack scenarios.
90
+
- Use attack trees to map out how an attacker might exploit vulnerabilities.
91
+
4. Threat Mitigation:
92
+
- Implement defenses like intrusion detection systems, access controls, and encryption.
93
+
- Regularly update threat profiles and defenses based on new intelligence.
94
+
95
+
#### Application-Centric
96
+
1. Application Diagramming:
97
+
- Create detailed architecture diagrams.
98
+
- Include data flows, components, and interactions.
99
+
2. Threat Identification:
100
+
- Apply models like STRIDE or OWASP Top 10 to each component.
101
+
- Identify threats such as spoofing, tampering, and data breaches.
102
+
3. Risk Assessment:
103
+
- Use the DREAD model to evaluate threats.
104
+
- Rank threats based on their potential impact and exploitability.
105
+
4. Threat Mitigation:
106
+
- Develop countermeasures for high-risk threats.
107
+
- Implement secure coding practices and conduct regular security reviews.
108
+
109
+
110
+
### What is DREAD?
111
+
DREAD is a risk assessment model used in cybersecurity to evaluate and prioritize potential threats. The acronym stands for:
112
+
-**Damage potential:** Assessing the potential damage that could result from a successful exploit.
113
+
-**Reproducibility:** Evaluating how easily the exploit can be replicated.
114
+
-**Exploitability:** Determining the ease with which the vulnerability can be exploited.
115
+
-**Affected users:** Identifying the number of users or systems affected by the vulnerability.
116
+
-**Discoverability:** Assessing how easily the vulnerability can be discovered.
117
+
118
+
Each of these factors is typically scored on a scale, often from 0 to 10, with higher scores indicating a greater level of risk.
119
+
120
+
121
+
## Practical Steps for Threat Modeling:
122
+
1.**Define Scope:** Identify boundaries of the system and critical assets.
123
+
2.**Create Diagrams:** Develop DFDs and architecture diagrams.
124
+
3.**Identify Threats:** Use methodologies like STRIDE to discover potential threats.
125
+
4.**Analyze Threats:** Assess risk using models like DREAD.
126
+
5.**Develop Mitigations:** Define strategies to mitigate identified threats.
127
+
6.**Review and Iterate:** Regularly update the threat model throughout the development lifecycle.
128
+
129
+
130
+
---
131
+
## Tools:
132
+
-#### Open-source:
133
+
+[OWASP Threat Dragon](https://owasp.org/www-project-threat-dragon/) - An open-source tool for creating threat model diagrams and managing threats.
134
+
+[Microsoft Threat Modeling Tool](https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool) - A tool for creating data flow diagrams and identifying threats using STRIDE.
135
+
+[CAIRIS](https://cairis.org/): A tool for building models and conducting risk assessments based on these models.
136
+
+[threat-composer](https://github.com/awslabs/threat-composer?tab=readme-ov-file) - A simple threat modeling tool to help humans to reduce time-to-value when threat modeling.
137
+
138
+
-#### Commercial:
139
+
+[ThreatModeler](https://threatmodeler.com/) - An enterprise-grade tool for automated threat modeling, integrating with CI/CD pipelines.
140
+
+[IriusRisk](https://www.iriusrisk.com/threat-modeling-platform) - A platform for automated threat modeling and risk management.
0 commit comments