25 August 2023
Threat modelling is a structured approach for identifying and mitigating security risks in applications and systems. It allows developers to proactively build in security during design and development, rather than tackling vulnerabilities reactively after deployment. This article provides a comprehensive overview of threat modelling techniques, steps, and best practices. JBI Training can train, and help you or your team develop a complete solution by customising a Threat Modelling Course for you.
Threat modelling refers to the practice of methodically evaluating an application or system to identify potential security threats and vulnerabilities. The goal is to understand how an adversary could compromise assets and then make appropriate design changes to mitigate these risks.
Threat modelling provides a way to think like an attacker and uncover flaws or gaps in security architecture. It involves breaking a system down to analyse the attack surface from an adversary’s perspective.
The importance of threat modelling stems from the fact that designing for security is much more effective than attempting to retrofit it later. It’s far cheaper to address threats during development compared to after deployment. Threat modelling improves cost efficiency and reduces risk.
Proactive threat analysis during design allows security to be considered alongside other quality attributes like functionality, scalability and usability. Threat modelling helps answer important risk management questions like:
Threat modelling follows a structured approach to risk analysis and mitigation. Though specific methodologies vary, the key high-level steps are:
1. Identify assets, data flows and entry points. The first step is to document components, connections and pathways into the system. This provides an understanding of what needs to be protected.
2. Create a system overview. A visual representation highlights trust boundaries, access points, data flows and connections between components.
3. Decompose the application. Break the application down into manageable pieces to analyse threats at an appropriate resolution.
4. Identify threats. Analyse each component to identify potential security weaknesses, prioritizing assets with high privilege levels.
5. Rate risks. Assess the likelihood and impact of identified threats to estimate overall risk priority.
6. Mitigate threats. Redesign components and systems to reduce risk, based on the threat analysis.
7. Validate the model. Perform testing and reviews to verify completeness and accuracy.
8. Document results. Record all details from assets and threats to mitigation decisions and risk ratings.
Repeating threat modelling at periodic intervals, such as when significant design changes occur, ensures the maintenance of a robust security posture over time.
The overarching goals of threat modelling are to:
Additional benefits beyond securing systems include:
Overall, threat modelling is a pivotal part of building security into applications by design.
The first step in analysing security threats is to comprehensively identify key assets, data flows and access points.
Assets that may require protection include:
Data flows that warrant attention:
Entry points should be documented at locations where external entities can interact with the system:
This asset and access analysis informs downstream threat modelling activities.
A context diagram visually illustrates the scope, boundaries and connections in a software system. Icons represent elements like users, interfaces and data stores. Data flow lines map the movement of information between components.
Context diagrams aid threat modelling in two key ways:
1. They provide an abstract overview of components, connections and trust levels.
2. They help identify security-critical assets, entry points and data flows.
For example, flows of sensitive customer data might be highlighted for further inspection. Trust boundaries between privilege levels may be shown using different icon types.
Context diagrams enable assessing whether components handle data appropriately for their trust level. For example, an Internet-facing web server should not directly access an internal database.
The diagram should provide the right level of detail to visualize the attack surface and highlight significant security-relevant elements. Overly complex diagrams become difficult to comprehend.
There are various approaches to creating a context diagram:
The approach depends on the stage of development and level of detail required. The key is creating a contextual overview sufficient to inform threat analysis.
Large, complex applications are challenging to threat model as an atomic entity. It's more effective to decompose the system into smaller interconnected subsystems or services.
This subsystem approach provides several advantages:
Decomposition into subsystems allows selectively zooming in on particular areas of interest. For example, components handling sensitive data deserve extra attention.
High privilege components such as authentication systems or back-end admin consoles are also candidates for deeper analysis. These pose greater risk if compromised.
Too much decomposition can result in losing sight of bigger picture data flows and trust relationships. Balance decomposition granularity against modelling overhead.
The STRIDE threat classification scheme is a useful model for discovering security design flaws. STRIDE represents six threat categories:
Analysing components against STRIDE results in concrete threats related to trust, access control, data exposure, DoS and other concerns.
For example, an Internet-facing web server may enable spoofing attacks by not properly authenticating users. A data storage layer might allow tampering of records or information disclosure through weak access controls.
Prioritizing components that handle sensitive data or have high privileges guards against insider threats and lateral movement. These pose greater damage if compromised.
Evaluating threats within the context of protected assets also highlights potentially serious impacts. For example, tampering with audit logs or PII data carries higher consequence than transient denial of service.
Not all threats are equal. Performing risk ratings allows appropriately prioritizing security efforts and spend.
Threat modelling methodologies use qualitative or quantitative approaches to estimating risk levels.
Factors that influence ratings include:
Quantitative methods assign numeric scores or ratings which allow risk ordering. Qualitative assessment uses subjective judgement to gauge priority.
Iteratively remediating high likelihood, high impact risks provides the greatest security ROI.
The goal of threat modelling is to provide actionable mitigation guidance.
Vulnerabilities allow threats to be realized. Mitigations block specific vulnerabilities or restrict damage through containment.
Mitigations should be prioritized based on risk rating. For the highest risks, mitigate at the architecture and design level where changes are cheaper. Some examples:
Lower risks can potentially be mitigated at the code level. Secure coding best practices from OWASP and others give excellent guidance including:
Tradeoffs inevitably exist between security and other factors like usability, performance and development costs. Analyze alternatives to select appropriate mitigations.
Independent review by experts helps validate threat model completeness and accuracy. Pairwise testing against known weaknesses provides further assurance.
Reviews and testing should focus on:
Any issues uncovered during validation feed back into the threat modelling process for remediation.
For threats deemed valid but not fully mitigated, enumerate as accepted risks. Capture them in operational risk management documentation and processes.
To realize the full benefits of threat modelling, integrate it into your development processes. Include threat modelling steps directly in requirements definitions, design reviews and change management flows.
Integrating threat modelling improves:
Hold sessions focused on threat analysis. Make threat models and mitigation recommendations available to developers implementing systems.
Schedule periodic threat modelling health checks on long-running projects to catch emerging risks. Seek feedback from operations teams on how threat models match reality after systems are live.
Most importantly, ensure threat analysis occurs continuously alongside feature development rather than as a one-off compliance activity. This allows threat modelling to achieve its maximum return.
Manually mapping out complex systems with many subcomponents can become arduous. Threat modelling tools automate parts of the process for efficiency.
Some examples of tasks tools assist with:
Lightweight threat modelling tools require minimal effort to get started. Enterprise-grade tools allow managed governance of threat models over time.
When evaluating tools, consider whether automation provides worthwhile time savings versus effort. The highest value tools enhance, rather than replace, skilled human judgement.
Follow these tips for maximizing the effectiveness of your threat modelling initiatives:
Adopting threat modelling drives better security design. Integrating it proactively into your development lifecycle leads to higher quality, more resilient software.
The most effective time to perform threat modelling is during design processes, before implementation begins. Threats identified at this stage can influence architecture and design decisions before significant rework is required.
Focus detail on high value assets and privileged components. Capturing excessive detail becomes counterproductive. Prioritize succinctly communicating key risks and context required for mitigation.
At minimum, refresh threat models after major design changes, upgrades or integrations. On long projects, periodic reviews help spot emerging risks.
A mix of security knowledge, software engineering and risk analysis skills. Technical leaders and architects normally drive the process.
If you enjoyed this article why not read Security Code Review: Best Practices and Processes