Introduction

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.  

What Is Threat Modelling and Why Is It Important?

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:

• What assets require protection?
• What vectors could an attacker use to gain access?
• What vulnerabilities exist that could be exploited?
• What is the potential impact of a compromise?
• How can identified risks be mitigated or reduced?

Overview of the Threat Modelling Process

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.

Key Goals and Benefits of Threat Modelling

The overarching goals of threat modelling are to:

• Discover and address security gaps early when fixes are cheaper.
• Increase visibility into real risks based on impact and likelihood.
• Enable informed decisions on appropriate security investments.
• Build more secure software by design through proactive threat analysis.

Additional benefits beyond securing systems include:

• Risk management support - Threat modelling provides vital input for risk assessments.
• Cost reduction - Addressing threats early greatly reduces remediation costs.
• Auditing and compliance - Threat models provide evidence of security due diligence.
• Stakeholder communication - Models facilitate discussions with teams and leaders.
• Process integration - Threat modelling aligns with development methodologies like Agile.

Overall, threat modelling is a pivotal part of building security into applications by design.

Pinpointing Key Assets, Data Flows and Entry Points

The first step in analysing security threats is to comprehensively identify key assets, data flows and access points.

Assets that may require protection include:

• Sensitive user data - Personally identifiable information (PII), credentials, messages, transaction details.
• Intellectual property - Proprietary algorithms, trade secrets, restricted content.
• Configuration and metadata - Settings, logs, descriptors, access control lists.
• Underlying infrastructure - Cloud resources, containers, virtual machines, servers.

Data flows that warrant attention:

• System inputs - External data entering via forms, uploads, APIs, UIs.
• Data processing - Flows between application layers like business logic.
• Data storage - Repositories like databases and file shares.
• Outputs - Reports, messages and other data leaving the application.

Entry points should be documented at locations where external entities can interact with the system:

• User interfaces - Web pages, mobile apps, desktop clients.
• API access points - REST APIs, RPC interfaces, microservices.
• External service integrations - Third-party code interactions.
• Configuration and admin consoles.
• Background processing services - Batch jobs, message queues, workflows.

This asset and access analysis informs downstream threat modelling activities.

Visualizing the System with Context Diagrams

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:

• Textual - Tables and lists documenting components, connections and trust levels.
• Informal drawings - Whiteboard sketches sufficient for discussion.
• Formal modelling - Rigorous diagramming with architectural modelling tools.

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.

Breaking the System into Manageable Subsystems

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:

• Focused analysis - Evaluate specific components in greater depth.
• Division of labour - Subsystems can be modelled by different teams.
• Abstraction - Hide internal details of subsystems.
• Reusability - Common subsystems or services can be modelled once.

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.

Discovering Threats with the STRIDE Model

The STRIDE threat classification scheme is a useful model for discovering security design flaws. STRIDE represents six threat categories:

• Spoofing - Impersonating users or components.
• Tampering - Malicious data modification.
• Repudiation - Denying actions committed.
• Information disclosure - Exposing sensitive data.
• Denial of service - Disrupting system availability.
• Elevation of privilege - Gaining higher-level permissions.

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.

Rating Risks to Prioritize Security

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:

• Vulnerability severity - How difficult is the weakness to detect and exploit? Consider remediation costs.
• Threat capability - Technical expertise and resources required to successfully compromise the system.
• Threat motivation - Incentives for targeting the vulnerability like financial gain or disruption.
• Likelihood - Probability of a threat occurrence based on capability and motivation.
• Impact - Magnitude of damage if a vulnerability is exploited. Loss of life, IP, finances?
• Asset value - How critical or sensitive are the impacted resources?

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.

Mitigating Threats through Secure Design and Coding

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:

• Compartmentalize sensitive components into trust zones with minimal privileges.
• Encrypt sensitive data flows end-to-end.
• Validate all inputs on trust boundaries.
• Audit critical security events like access control changes.
• Rotate cryptographic keys, credentials and secrets regularly.

Lower risks can potentially be mitigated at the code level. Secure coding best practices from OWASP and others give excellent guidance including:

• Input validation and sanitization
• Parameterized queries to prevent SQL injection
• Access control checking in controllers
• Encrypting sensitive data at rest
• Logging exceptions and failures

Tradeoffs inevitably exist between security and other factors like usability, performance and development costs. Analyze alternatives to select appropriate mitigations.

Validating the Model through Testing and Reviews

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:

• Verification of mitigations - Ensure countermeasures were applied and configured correctly.
• Discovery of additional threats - Fresh eyes may reveal overlooked risks.
• Assumptions and external dependencies - Validate security of integrations and third-party code.

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.

Integrating Threat Modelling into Development 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:

• Early detection of flaws - Find threats during design rather than testing.
• Cost savings - Estimates improve when threats are known upfront.
• Awareness and ownership - Cross-team collaboration on security.

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.

Automating Threat Modelling with Tools

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:

• Model generation - Automated diagramming of components, data flows and trust levels.
• Threat library integration - Identify common weaknesses like injection flaws.
• Reporting - Produce threat model documents for stakeholders.
• Code integration - Incorporate threat analysis into CI/CD pipelines.
• Cloud infrastructure analysis - Identity risks associated with cloud architectures.

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.

Best Practices for Effective Threat Modelling

Follow these tips for maximizing the effectiveness of your threat modelling initiatives:

• Start early during design processes and update models periodically.
• Decompose complex systems carefully for focused analysis.
• Prioritize high value and high risk assets.
• Rate risks quantitatively if possible.
• Reuse models for common components and flows.
• Validate with redundancy using reviews and testing.
• Integrate threat analysis with development and operations.
• Automate where it accelerates the process.
• Collaborate across teams to build security knowledge.

Adopting threat modelling drives better security design. Integrating it proactively into your development lifecycle leads to higher quality, more resilient software.

Frequently Asked Questions

When should threat modelling occur during software development?

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.

What level of detail is appropriate for diagrams and documentation?

Focus detail on high value assets and privileged components. Capturing excessive detail becomes counterproductive. Prioritize succinctly communicating key risks and context required for mitigation.

How often should threat modelling be repeated on a project?

At minimum, refresh threat models after major design changes, upgrades or integrations. On long projects, periodic reviews help spot emerging risks.

What skills are required to perform threat modelling effectively?

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