Threat Modelling for Security Architects: Identifying and Mitigating Risks Before They Happen

As security architects, we’re responsible for laying the secure foundation for entire systems, encompassing software, hardware, networks, and critical processes.

Our architectural decisions ripple throughout the system’s lifecycle, profoundly impacting not just performance, scalability, and maintainability, but, most importantly, the system’s inherent security. In today’s increasingly sophisticated digital landscape, building secure systems is no longer a luxury; it’s a fundamental necessity. This is precisely where threat modelling comes in. It is a proactive, structured approach to identifying and mitigating potential security risks long before they escalate into costly breaches.

Why Threat Modelling Belongs in Architecture

Too often, security is treated as an afterthought, a separate phase of testing tacked on at the end of a system’s deployment. This “fix it later” approach is inefficient, expensive, and often ineffective. Integrating threat modelling into the architectural phase offers significant advantages:

• Early Risk Identification: Catching vulnerabilities at the design stage is far cheaper and easier than remediating them in deployed components or live systems.
• Proactive Mitigation: Design security controls directly into the system’s architecture, rather than patching them in retrospect.
• Informed Decision Making: Understand the security implications of different architectural choices.
• Improved Communication: Foster a shared understanding of security risks among development, operations, security teams, and the wider business.
• Compliance & Due Diligence: Demonstrate a commitment to security and aid in meeting regulatory requirements, such as Cyber Essentials for baseline UK cybersecurity certification, ISO 27001 for a comprehensive Information Security Management System (ISMS), the NIST Cybersecurity Framework (CSF) for a risk based approach to cybersecurity management, or IEC 62443 for industrial control systems and operational technology.

The Practical Guide: Integrating Threat Modelling into Your Architectural Process

While there are various methodologies (STRIDE, DREAD, PASTA, etc.) and domain specific standards like IEC 62443 for Industrial Control Systems, the core principles remain consistent. For security architects, a fundamental starting point before any threat identification is to truly understand the system’s inherent value by identifying its mission critical assets. This understanding guides all subsequent security efforts. A highly effective and rigorous methodology for this is MITRE’s Crown Jewels Analysis (CJA), which provides a structured, mission decomposition approach to uncover vital mission dependencies and ensure the resilience needed to “fight through” advanced persistent threats. Here’s a practical, four step approach you can adapt:

Step 1: Deconstruct Your Architecture

As security architects, our role extends beyond mapping technical components; it demands a profound understanding of the business value and, crucially, the mission criticality embedded within every part of the system. This approach is underpinned by the principle of Secure by Design, where security considerations are proactively integrated throughout the lifetime of the project, especially at its very beginning, rather than being an afterthought. Therefore, to effectively identify and mitigate threats, your initial step must be to develop a deep understanding of your system’s architecture, critically including the identification of its most vital components. These aren’t merely important assets; guided by methodologies like CJA, they are the core mission dependencies the data, processes, or capabilities that, if compromised, would directly impede or catastrophically damage the organisation’s ability to accomplish its mission (leading to significant financial, reputational, operational, or legal impact). This upfront prioritisation, deeply informed by a mission decomposition approach, isn’t just a best practice; it’s the strategic compass that ensures your security efforts are precisely focused where they matter most, safeguarding the very essence of the business and ensuring operational resilience.

• Define the Scope: What parts of the system are you modelling? A single microservice, an entire application, or an enterprise wide system? Ensure your scope adequately covers all potential mission critical assets and their direct access pathways.
• Identify Key Components and Their Value: With this overarching goal of protecting the organisation’s mission accomplishment in mind, the deconstruction begins by meticulously identifying each component and its true significance. List all major components, services, databases, external dependencies, and user types. As you identify each, simultaneously delve into its business and mission context and assess its criticality. This context is essential for prioritising risks later.
  • Business Purpose/Mission Function: For each component, consider its core business function and, more importantly, its contribution to the overarching mission. What processes does it enable or automate (e.g., customer billing, inventory management, command and control operations, sensor data processing)?
  • Data Classification: What type of data will it store and process? Classify it: is it public, sensitive internal, customer PII, financial records, regulated health information, or mission critical operational data?
  • Assess Mission/Business Impact (CIA Triad): For the data and processes associated with each component, evaluate the specific mission and business impact of a security failure across Confidentiality, Integrity, and Availability. This assessment, as emphasised by CJA, should encompass mission level impacts and granular task and function level impacts. Critically, it must also consider the potential impact on human safety or environmental well being:
    • Confidentiality Breach: What happens if this data is stolen or exposed (e.g., regulatory fines, reputational damage, loss of competitive advantage, compromise of mission planning or operational intelligence)?
    • Integrity Failure: What happens if this data is illicitly modified (e.g., incorrect financial reporting, flawed business decisions, fraudulent transactions, corrupted sensor data leading to erroneous decisions, compromised control signals)?
    • Availability Loss: What happens if this system goes down (e.g., direct revenue loss per hour, operational stoppage, customer churn, interruption of critical military operations, failure to deliver essential public services)? This comprehensive assessment will help you identify what truly constitutes a mission critical asset thinking broadly beyond just data to include unique algorithms, essential operational processes, critical hardware, or highly privileged accounts. Consider these component types during your assessment:
  • Data Stores: Databases, caches, file systems (e.g., sensitive customer data, intellectual property, financial records, mission planning data, intelligence reports).
  • Processes: Application servers, APIs, background jobs, operational workflows (e.g., core revenue generation, regulatory compliance, critical command and control functions, data fusion pipelines, industrial process control sequences, or emergency shutdown procedures).
  • External Entities: Users, third party services, other applications, physical access points (e.g., privileged user accounts, critical vendors, physical infrastructure, external mission partners, vital supply chain elements).
  • Data Flows: How information moves between components. Pay attention to flows involving mission critical data.
• Create Data Flow Diagrams (DFDs) or Architectural Diagrams: Visual representations are incredibly powerful. DFDs (Context, Level 1, etc.) are particularly useful as they highlight data flows, trust boundaries, and interactions. If you’re using other architectural diagrams, ensure they clearly depict these elements and explicitly call out or highlight the mission critical assets and the critical pathways leading to them.
• Establish Trust Boundaries: Where do different levels of trust exist? Network perimeters, different security zones, distinct user roles, and even different microservices often represent trust boundaries. Physical locations, hardware enclaves, and managed vs. unmanaged devices also define critical trust boundaries. Crossing these boundaries, especially those protecting or leading to your mission critical assets, usually warrants extra scrutiny.

Step 2: Identify Threats (Brainstorming Potential Attacks)

Now that you understand your system and its mission critical assets, it’s time to put on your attacker’s hat. This step involves brainstorming potential threats against each identified component and data flow, with a particular focus on those critical assets.

A popular and highly effective framework for this is STRIDE:

• S – Spoofing Identity: Can an attacker impersonate a legitimate user or system? (e.g., forged credentials, session hijacking, impersonating a hardware device or a process).
• T – Tampering with Data: Can an attacker modify data in transit or at rest? (e.g., altering database records, manipulating API requests, modifying hardware configurations or firmware).
• R – Repudiation: Can an attacker deny performing an action? (e.g., unlogged transactions, lack of audit trails, denying physical access or configuration changes).
• I – Information Disclosure: Can an attacker gain access to sensitive information they shouldn’t have? (e.g., unencrypted data, vulnerable APIs revealing too much, physical data exfiltration from devices).
• D – Denial of Service (DoS): Can an attacker prevent legitimate users from accessing the system or its resources? (e.g., resource exhaustion, SYN floods, physical destruction of hardware, network jamming).
• E – Elevation of Privilege: Can an attacker gain higher level permissions than they are authorised for? (e.g., privilege escalation bugs, insecure configurations, exploiting physical access to gain administrative control).

Enhancing Threat Identification with MITRE ATT&CK

While frameworks like STRIDE provide a powerful starting point for brainstorming generic threats, for architects seeking a deeper, more realistic understanding of how adversaries operate, the MITRE ATT&CK framework is invaluable.

• What it is: MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a globally accessible knowledge base of real world adversary tactics, techniques, and procedures (TTPs) based on observed attacks. It organises these TTPs into matrices (e.g., Enterprise, Mobile, ICS), mapping out the entire lifecycle of an attack.
  • Tactics: The high level goals of an adversary (e.g., Initial Access, Execution, Persistence, Lateral Movement, Exfiltration, Impact).
  • Techniques: Specific ways an adversary achieves a tactic (e.g., “Phishing” for “Initial Access,” “Credential Dumping” for “Credential Access”).
  • Sub techniques: More granular descriptions of techniques (e.g., “LSASS Memory” as a sub technique for “Credential Dumping”).
  • Procedures: Specific implementations of techniques by threat groups or malware.

Why it’s useful for Architects in Threat Modelling:

• Threat Informed Perspective: ATT&CK shifts the focus from theoretical vulnerabilities to actual adversary behaviour. Architects can use it to understand the likely attack paths against their specific system components, rather than just abstract threats.
• Granular Attack Details: While STRIDE identifies “Information Disclosure,” ATT&CK provides concrete techniques like “Data from Local System,” “Screen Capture,” or “Browser Session Hijacking,” giving architects specific attack vectors to consider and design defences against. It also covers techniques related to firmware manipulation, supply chain compromise, and physical access, which are crucial for “entire system” security.
• Prioritisation based on Real World Threats: By mapping potential attacks to ATT&CK, architects can prioritise mitigations based on techniques known to be used by relevant threat groups or prevalent in their industry.
• Gap Analysis: After brainstorming threats with STRIDE, architects can use ATT&CK to perform a more detailed gap analysis. For example, if your system involves user authentication, you might review ATT&CK’s “Credential Access” tactics and techniques to ensure your design addresses common methods like “Brute Force,” “Credential Dumping,” or “Keylogging.”
• Informing Control Selection: For each ATT&CK technique, the framework often provides “Mitigations.” Architects can use these suggested mitigations as direct input for designing security controls into their system. For example, if “Phishing” (Initial Access) is a threat, mitigations like “Multifactor Authentication” or “User Training” inform design choices.
• Red Team/Blue Team Alignment: It provides a common language for security teams, ensuring that red team exercises (simulating attacks) and blue team defences (building and monitoring) are aligned with real world adversary behaviours.

Integrating ATT&CK into Your Threat Modelling Steps: You can seamlessly integrate ATT&CK, especially within Step 2 (Identify Threats) and Step 3 (Mitigate and Document Risks).

• During Threat Identification (Step 2): After deconstructing your architecture and identifying trust boundaries, use STRIDE to get the high level threat categories. Then, for each component or data flow, pivot to the MITRE ATT&CK matrix. Ask: “How would an attacker achieve Spoofing, Tampering, etc., using specific ATT&CK tactics and techniques against this component?” For instance, if a microservice handles sensitive user data, consider “Collection” tactics (e.g., “Data from Local System,” “Automated Collection”) and “Exfiltration” techniques (e.g., “Exfiltration Over C2 Channel,” “Data Compressed”). For a hardware component, consider “Firmware Modification” or “Hardware Additions.”
• During Mitigation Design (Step 3): Once you’ve identified specific ATT&CK techniques relevant to your system, use the “Mitigations” associated with those techniques within the ATT&CK framework itself, or brainstorm architectural controls that specifically counter them. For example, if “Lateral Movement: Remote Services” is a concern, architectural mitigations might include network segmentation, strong host based firewalls, or strict access controls between services.

Example Use Case (SaaS E-commerce Platform): During the threat modelling of the SaaS e-commerce platform, the process would begin by identifying mission critical assets using a structured approach akin to CJA. For this platform, customer data (including PII, financial records, and purchase history) would be identified as a paramount mission critical asset due to its direct impact on customer trust, regulatory compliance, and business operations.

After identifying “Information Disclosure” as a high level STRIDE threat against this critical customer data:

Architect uses ATT&CK: They might explore “Collection” and “Exfiltration” tactics. Specific ATT&CK techniques considered:

• T1005 Data from Local System: Could an attacker access the database directly?
• T1074 Data Staged: Could data be gathered in a temporary location before exfiltration?
• T1041 Exfiltration Over C2 Channel: Could sensitive data leave the system disguised as normal traffic?
• T1195.002 Supply Chain Compromise: Hardware: Could a compromised hardware component (e.g., a network card in a server) introduce a backdoor?

Developing Attack Trees: Building upon these identified ATT&CK techniques, an architect would then construct attack trees. For instance, an attack tree aiming to achieve “Exfiltrate Customer Data” might have sub goals like “Gain Database Access” (which could branch into “Exploit SQL Injection” OR “Steal Database Credentials”) AND “Stage Data” (using T1074) AND “Establish Exfiltration Channel” (using T1041). This systematic breakdown would provide a comprehensive visual map of potential attack paths.

Architectural Mitigations (informed by ATT&CK and Attack Tree Analysis):

• Implement strict network segmentation to limit direct database access.
• Ensure all data staging areas are highly secured and ephemeral.
• Design robust egress filtering rules and integrate deep packet inspection for unusual outbound traffic patterns, even on encrypted channels.
• Mandate least privilege for all service accounts accessing data.
• Implement hardware root of trust, secure boot, and provenance checks for critical hardware components.

Practical Tips for Threat Identification:

• Collaborate: Involve business owners, developers, security specialists, operations teams, and even physical security personnel if applicable. Diverse perspectives lead to better threat identification.
• Focus on Trust Boundaries: Attacks often occur when data crosses trust boundaries.
• Consider Data At Rest, In Transit, and In Use: Threats can apply to data in any state.
• Think About the “Least Privilege” Principle: Where could a component or user have more access than truly needed?
• Use Checklists/Templates: Leverage common attack patterns and vulnerability types relevant to your technology stack (e.g., OWASP Top 10, CWEs relevant to hardware/firmware).
• Prioritise based on Criticality: Give the highest attention and deepest analysis to threats directly targeting your identified mission critical assets and the critical pathways leading to them.

Once high level threats are identified and enriched with frameworks like STRIDE and MITRE ATT&CK, security architects often need to delve deeper into how an attacker might achieve a specific objective. This is where attack trees become an invaluable supplementary tool. An attack tree systematically breaks down an attacker’s goal (e.g., “Compromise Customer Data”) into hierarchical sub goals and specific methods, connected by logical “AND” or “OR” conditions. Each “leaf” node represents a concrete attack step, often mapping directly to MITRE ATT&CK techniques. This powerful visualisation helps to uncover complete attack paths, revealing all possible sequences of actions an attacker might take against a system.

Step 3: Mitigate and Document Risks (Designing Security Controls)

Once threats are identified, the next step is to propose and design architectural and technical controls to mitigate them. The detailed attack paths visualised with attack trees can directly inform these mitigation strategies by helping to:

• Identify Critical Control Points: By understanding the “AND” (all steps required) and “OR” (any one step sufficient) logic within an attack tree, you can pinpoint the most effective places to deploy defences that break multiple attack chains or block the easiest entry points.
• Estimate Attacker Effort: Assigning a “cost” or “difficulty” to each leaf node in an attack tree allows for a more nuanced prioritisation of mitigations, focusing on making the attacker’s path too expensive or difficult.
• Brainstorm Countermeasures: For each identified threat, and informed by detailed attack paths, consider how you can prevent, detect, or recover from it.
  • Prevention: Remove the vulnerability entirely (e.g., input validation, secure hardware design, robust physical access controls).
  • Detection: Identify when an attack is occurring (e.g., logging, monitoring, hardware integrity checks, environmental monitoring).
  • Recovery: Restore the system to a secure state after an attack (e.g., backups, incident response plan, hardware replacement procedures, operational continuity plans).
• Prioritise Mitigations: Not all threats are equal. Mitigations for threats against your mission critical assets and their critical pathways should always receive the highest priority and the most robust controls. When assessing likelihood and impact, consider using a four tier risk rating system (e.g., Low, Medium, High, Critical). This approach intentionally removes a neutral “middle” option, compelling assessors to make a more definitive judgment on whether the likelihood or impact leans towards a lower or higher extreme. This design promotes more decisive and less ambiguous risk assessments, preventing the default to a non committal central choice, thereby ensuring your mitigation efforts are sharply focused where they matter most.
• Design Security Controls into the Architecture:
  • Authentication & Authorisation: How will users and systems be verified and granted appropriate access? (e.g., OAuth 2.0, JWTs, Role Based Access Control, device authentication).
  • Input Validation & Output Encoding: Protect against injection attacks.
  • Encryption: Secure data at rest and in transit (TLS, AES-256, hardware level encryption).
  • Logging & Monitoring: Detecting suspicious activity.
  • Least Privilege: Ensure components and users only have the permissions they absolutely need.
  • Secure Configuration Management: Harden servers, databases, applications, network devices, and IoT endpoints.
  • API Security: Rate limiting, authentication, authorisation, input validation.
  • Network Segmentation: Isolate critical components.
  • Physical Security Controls: Implement access control to data centres, server racks, and critical hardware; ensure environmental controls and surveillance.
  • Supply Chain Security: Vet hardware and software suppliers; implement integrity checks during procurement and deployment; ensure secure handling of components.
• Document Everything: Create a threat model document that includes:
  • System Overview (DFDs/Architectural Diagrams)
  • Identified Threats (using STRIDE, MITRE ATT&CK, or similar)
  • Proposed Mitigations
  • Risk Prioritisation
  • Open Issues/Decisions

Step 4: Validate and Iterate (Continuous Improvement)

Threat modelling isn’t a one time activity. It’s an ongoing process that evolves with your architecture.

• Review and Validate: Present your threat model to relevant stakeholders (security, development, product owners, operations, and compliance teams) for feedback and validation. Are there any missed threats? Are the proposed mitigations practical and effective?
• Integrate into SDLC: Make threat modelling a mandatory step in your architectural review process.
• Revisit with Changes: Whenever your architecture significantly changes, new attack tree features are added, new technologies are introduced, or new hardware/infrastructure is deployed, revisit your threat model.
• Learn from Incidents: If a security incident occurs, analyse it and update your threat model to prevent similar issues in the future.

Tools to Assist Your Threat Modelling Journey

While you can start with whiteboards and spreadsheets, several tools can streamline the process:

• Microsoft Threat Modelling Tool: A popular, free, and intuitive tool based on STRIDE.
• OWASP Threat Dragon: An open source, web based threat modelling tool.
• IriusRisk: A commercial platform offering advanced features, automation, and reporting.
• Lucidchart/Draw.io/Miro: Excellent for creating DFDs and architectural diagrams.
• MITRE ATT&CK Navigator: While not a threat modelling tool itself, it’s excellent for visualising and filtering ATT&CK techniques, which can be immensely helpful during the threat identification and mitigation phases.
• Attack Tree Diagramming Tools: General diagramming tools like Lucidchart and Draw.io can be used for manual attack tree creation. For more advanced analysis or automated features, specialised security modelling platforms may offer attack tree capabilities.

Conclusion

Integrating threat modelling into your architectural process is a powerful shift towards building inherently more secure systems. By proactively identifying and mitigating risks, you not only reduce the likelihood of costly breaches but also foster a culture of security awareness throughout your organisation. Embrace threat modelling as an essential architectural discipline, and you’ll be well on your way to building resilient, secure, and future proof applications.

At Airbus Protect, we understand that building secure and resilient systems in today’s complex landscape requires specialised expertise and a proactive approach. Our team of seasoned security architects and cybersecurity experts are ideally positioned to support your organisation throughout every stage of integrating threat modelling into your architectural processes. This includes leveraging our advanced proprietary tools like FENCE, a comprehensive cybersecurity risk assessment and management software that simplifies risk and compliance assessments and facilitates risk tracking. By partnering with us, you gain a trusted ally committed to embedding security from the ground up, allowing you to focus on innovation while building systems that are inherently resilient against evolving cyber threats.

To understand how Airbus Protect can support your security architecture and design activities, visit https://www.protect.airbus.com/cybersecurity/architecture-design/ 

• Share