Threat Modeling Process: Basics and Purpose

Introduction

Threat Modeling is one of the disciplines that can lift your risk management program and make it excellent. Threat modeling process (Figure 1) requires a repeatable approach; it can be done of any time during the life cycle of application/system but will provide a maximum return of design time. 

Process

(Figure 1)

When building an effective threat modeling process to identify specific risks and prioritize how you will handle them, you need to consider the following steps:

1. Define general security objectives and scope

• Know your assets/data (not just physical).
• Ensure security is included in your business requirements.
• Identify your objective concisely.
• Collect data such as existing documentation, policy, framework, guideline, DB, users stories, errors …etc.
• Check the accuracy of the collected data.
• Gather security requirements already defined for you via compliance, government regulations, and industry standards.
• Identify how you can address security and implement security requirements from a regulatory/data privacy perspective.

2. Decompose

• Know your organization connectivity models. Ensure that no elements have been forgotten by identifying sub-components, dependencies and interaction points.
• Identify assets an attacker might be interested in, who should be allowed to access each area, and how access is controlled.
• Break up your application/system into conceptual entry points, components, and boundaries where an attacker might interact with it.
• Mark all untrusted data inputs. In my view, all data is untrusted, unless you can verify it is only your own. 
• Diagram how data flows through the application/system using data flow diagrams (DFDs). DFD will represent how data moves between processes, storage, and external systems/services (figure 2).

3. Identify and rank threats

• List all threats categories as possible, e.g., reconnaissance, social engineering, systems hacking, web-based threats, malware, hijacking and impersonation, denial of service Mobile-based threats, cloud-based threats, etc.
• Existing threats should be identified before controls are listed for each threat, but the ranking of those threats will determine which controls will be implemented. Ranking threats is a key because the likelihood or impact of a threat may be so low that performing a control is not worth the cost. 
• Think like an attacker. It is terrible to crash, but it is worse to have wrong information and not even know about it. Examine your application and identify where threats exist such as checking return codes, errors, level of access, data sharing and all input if possible. 
• Ensure security requirements flow into test cases. Use a variety of testing methods.
• Use vulnerability scanner tools to identify weaknesses, these tools are helpful to add a level of trust, but it does not replace planning, design and manual testing.
• Use root cause analysis.
• Use methodology like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Escalation of Privileges) to help you identify and rank threats.
• If you are using third-party components, libraries and services consider and include their own threat models.

4. Counter each threat

• Follow security design patterns to deal with specific types of threats.
• Provide countermeasures for each threat you need to address.
• Respect your limits and have a Subject Matter Expert (SME) present.
• Establish ongoing monitoring to identify when new security issues arise over time.
• Test the mitigation, in case threats not mitigated become security bugs in your bug repository.
• Find a good threat model and keep the model in constant updating.

(Figure 2)

Methodology

The following methodology could be used to analyze potential exploits and countermeasures: 

• DREAD (Damage, Reproducibility, Exploitability, Affected Users, and Discovery) is a Microsoft qualitative threat ranking model. 
• STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Escalation of Privileges) is a Microsoft tool used to classify various types of exploits or security threats. 
• PASTA (Process for Attack Simulation and Threat Analysis) is a seven-step process to help a developer to view assets from an attacker point of view. 
• VAST (Visual, Agile and Simple Threat modeling) is an agile software development methodology.
• OWASP (Open Web Application Security Project) has specialized resources, including in-depth documentation on various attack types and security techniques for Web applications and Internet of Things (IoT).
• CVSS (Common Vulnerability Scoring System) is a risk management approach to quantifying vulnerability data and then taking into account the degree of risk to different types of systems or information. CVSS shall be used as a guide and organizations should consider how specific vulnerability impacts them.

You could also investigate other threat modeling methods, such as CORAS Risk Assessment, Trike, OCTAVE, SeaMonster and AS/NZS 4360.

Conclusions

Threat Modeling is the method used to document and illustrate a solution for identifying, understanding, mitigating, and remediating risk. It is recommended you adopt an established threat modeling methodology and adapt to organizations processes. 

References

• https://adam.shostack.org/blog/category/threat-modeling/
• https://www.sans.org/reading-room/whitepapers/securecode/paper/1646