From Blueprint to Fortress: Securing System Design with Threat Modeling

From Blueprint to Fortress: Securing System Design with Threat Modeling

Speakers: Hadley Westover, Cyber Engineer, Space Dynamics Laboratory

Conference: SAINTCON

YouTube: https://www.youtube.com/watch?v=jZrOzj9a6Yw

Overview

In the rapidly evolving landscape of cybersecurity, the adage "an ounce of prevention is worth a pound of cure" has never been more relevant. Hadley Westover, a Cyber Engineer at the Space Dynamics Laboratory, delivered a compelling talk at SAINTCON, titled "From Blueprint to Fortress: Securing System Design with Threat Modeling," advocating for the proactive integration of security into the very fabric of system design. Her presentation underscored that security should not be an afterthought, but a fundamental consideration from the project's inception.

Westover's talk champions threat modeling as an indispensable tool for identifying, understanding, and mitigating potential vulnerabilities early in the development lifecycle. She posits that by embedding security considerations at the design phase, organizations can dramatically reduce costs, shorten timelines, and ultimately build more resilient systems. The central message is clear: while no single process is a panacea for all security woes, threat modeling is a highly effective methodology that, when applied diligently, transforms system blueprints into formidable fortresses.

The importance of this topic resonates deeply within an industry frequently plagued by late-stage vulnerability discoveries, which can lead to catastrophic financial losses, reputational damage, and erosion of customer trust. Westover's insights are crucial for any organization striving to move beyond reactive security measures towards a truly proactive and integrated approach, ensuring that security is a design feature, not a bolt-on accessory.

Background

▶ Watch: Introduction and importance of threat modeling (0:00)

The pervasive problem that threat modeling seeks to address stems from a common organizational pitfall: prioritizing speed-to-market and feature development over robust security design. This "fix it later" mentality often leads to critical vulnerabilities being discovered deep into the development cycle, or worse, after a product has already launched. The speaker illustrated this with a cautionary tale of "Innovate Co.," a fictional company that rushed a groundbreaking smart home device to market, only to face devastating consequences when a critical architectural flaw was exposed by a security researcher. This flaw, deeply embedded in the system's design, required a costly and disruptive overhaul, transforming a market leader into a cautionary tale overnight.

Threat modeling emerged as a discipline to counteract this reactive stance, promoting a "shift left" security paradigm. Its core purpose is to identify, understand, and mitigate security weaknesses proactively, before significant investments are made in vulnerable designs. By scrutinizing system architecture and data flows early on, developers and security professionals can pinpoint potential attack vectors when changes are still relatively inexpensive and straightforward to implement. This approach is not about predicting every possible attack but about systematically analyzing a system from an attacker's perspective to build in resilience from the ground up.

The concept of threat modeling builds upon established security engineering principles and leverages various frameworks developed over the years. These methodologies provide structured approaches to analyze systems for potential threats. Westover highlighted several prominent examples, including STRIDE, DREAD, PASTA, TRIKE, VAST, and MITRE ATT&CK. While each framework offers a unique lens for analysis, they all share the common goal of systematizing the identification and assessment of security risks. The speaker primarily focused on STRIDE, given her extensive experience with it, as a robust and widely adopted framework for categorizing threats.

Key Findings

▶ Watch: Cautionary tale: The costly mistake of Innovate Co. (2:40)

The central finding presented by Hadley Westover is that threat modeling is a practical and highly effective tool for proactive security design, capable of transforming system development by embedding security from the outset. It's not a magical solution, but a disciplined process that yields significant benefits.

The talk meticulously breaks down threat modeling into six core steps, which represent the key findings for implementing this methodology effectively:

1. Define Scope and Objectives: Clearly delineate what system, feature, or component is being analyzed, its boundaries, and the resources available.
2. Decompose the System: Break down the system into its constituent parts, processes, and data flows using diagrams to understand its internal workings and interactions. This step is critical for identifying potential trust boundaries.
3. Identify Threats: Systematically brainstorm and categorize potential threats using established frameworks, such as STRIDE, at each trust boundary.
4. Determine and Prioritize Risk: Assess the likelihood and impact of identified threats, verifying their existence within the design and prioritizing those that pose the greatest risk.
5. Identify and Implement Countermeasures and Mitigations: Develop and apply appropriate security controls, design changes, or operational procedures to address the prioritized risks, favoring industry standards over homegrown solutions.
6. Validate and Iterate: Review the implemented mitigations to ensure they effectively resolve vulnerabilities, and plan for continuous threat modeling as the system evolves and new features are introduced.

These steps collectively form a robust framework for shifting security left in the development lifecycle. Westover emphasizes that the earlier vulnerabilities are identified, the more dramatic the reduction in costs and timelines, preventing the expensive and disruptive late-stage fixes exemplified by the Innovate Co. story. This proactive stance ensures that security becomes an inherent quality of the system, rather than an afterthought.

Technical Deep Dive

▶ Watch: The true cost of late-stage vulnerability discovery (6:10)

The technical core of Westover's presentation lies in the detailed exposition of the six threat modeling steps, particularly the decomposition of systems and the application of the STRIDE threat categorization framework.

Step 1: Defining the Scope

This initial phase involves clearly demarcating the boundaries of the threat modeling exercise. For Innovate Co., this meant focusing on their smart home device and its supporting server infrastructure. Key considerations include identifying internal and external interactions (e.g., customer app, web browser, customer network), assets to be protected, and project timelines and resources. A precise scope ensures the threat modeling effort remains focused and manageable.

Step 2: Decomposing the System

Effective decomposition is paramount for understanding the system's architecture and data flow. Data Flow Diagrams (DFDs) are the primary tool here, visually representing internal components, external entities, interactions, data movement, and data storage. Crucially, this step focuses on identifying trust boundaries—points where data or control passes between different levels of trust or components. These boundaries are prime locations for potential exploits. The process starts with a high-level context diagram showing the system's external interactions, then progresses to more detailed level one, two, and three diagrams as needed, drilling down into specific components like the smart home device's hardware, sensors, and internal communications. The goal is sufficient detail to understand the system without over-complicating it.

Step 3: Identifying Threats

Once the system is decomposed, potential threats are identified using structured methodologies. Westover listed several popular frameworks: STRIDE, DREAD, PASTA, TRIKE, VAST, and MITRE ATT&CK. She focused on STRIDE due to its widespread use and comprehensiveness. STRIDE is an acronym for:

• Spoofing: An attacker impersonates a trusted source. Example: Innovate Co. device having default admin credentials that are never changed, allowing an attacker to impersonate an administrator.
• Tampering: An attacker modifies data, code, or other aspects of the device or system. Example: Malicious software installed on a smart home device, which then sends tampered data to company servers that inherently trust the device.
• Repudiation: An attacker can deny having performed an action. Example: Lack of comprehensive logging means an attacker's actions on the device or server cannot be definitively traced or proven.
• Information Disclosure: An attacker gains unauthorized access to sensitive data or information. Example: A SQL injection vulnerability in the backend database allows an attacker to exfiltrate customer data from deployed smart home devices.
• Denial of Service (DoS): An attacker disrupts the normal functioning of the system. Example: A flood of traffic or malformed requests targeting the Innovate Co. server infrastructure, preventing legitimate smart home devices from connecting.
• Elevation of Privilege: An attacker gains higher permissions than they are authorized for. Example: A normal user account exploits a weak API authentication mechanism in the web interface to access administrative pages and resources.

A critical nuance in applying STRIDE is understanding which threat categories apply to different system components:

• Processes (internal, controllable components): All STRIDE categories (Spoofing, Tampering, Repudiation, Information Disclosure, DoS, Elevation of Privilege) apply.
• Data Flows (data in transit) and Data Stores (data at rest): Tampering, Information Disclosure, and Denial of Service are the primary concerns. Spoofing is less relevant here as it pertains to the identity of the communicating entities, not the data itself.
• External Entities (e.g., customer machines, third-party systems): Spoofing and Repudiation are key, as the focus is on verifying identity and tracking actions on our system, while direct control over their internal security is limited.

Step 4: Prioritizing Risk

After identifying potential threats, each must be verified to determine if it truly exists in the current design. Risks are then assessed based on their potential impact and likelihood, allowing for prioritization. This ensures resources are focused on the most critical vulnerabilities.

Step 5: Identifying and Implementing Countermeasures and Mitigations

Mitigation strategies should leverage established security standards and frameworks, rather than bespoke, unproven solutions. Westover outlined three types of mitigations, emphasizing a clear hierarchy of preference:

1. Design Change (Most Preferred): Modifying the system's architecture to inherently remove the vulnerability. Example: For spoofing via default admin credentials, a design change would mandate that users must change default credentials upon device setup.
2. Security Controls: Adding protective layers or features. Example: For tampering, implementing code signatures on software updates to ensure only authorized, untampered code can run on the device. For DoS, deploying load balancers to distribute traffic and absorb attacks.
3. Operational Procedures: Relying on human actions or administrative tasks. Example: For repudiation, ensuring audit logs are periodically generated, sent, and analyzed to track actions and detect anomalies. For information disclosure, enforcing proper input validation and sanitizing SQL calls to prevent injection attacks. For elevation of privilege, using cryptographically secure session tokens for admin access to prevent spoofing or guessing.

Step 6: Validating and Iterating

The final step involves verifying that the implemented mitigations effectively address the identified vulnerabilities and enhance the system's overall security posture. This is an iterative process; as the system evolves with new features or design changes, a new round of threat modeling should be initiated to continuously maintain its security.

Demo / Proof of Concept

▶ Watch: Overview of the six main steps of threat modeling (8:00)

While Hadley Westover's talk did not feature a live technical demonstration or a proof of concept of an exploit, she extensively discussed the practical tools and methodologies that facilitate the threat modeling process. The session focused on conveying the strategic and technical steps involved, rather than showcasing a specific vulnerability or its exploitation.

Westover highlighted the enduring value of low-tech solutions like whiteboards, emphasizing the importance of collaborative discussions and visual mapping of systems in a shared physical space. For digital diagramming, she mentioned common tools such as Draw.io and Visio, which are essential for creating the detailed Data Flow Diagrams (DFDs) crucial for system decomposition.

Beyond general diagramming, she introduced several threat modeling-specific tools:

• Microsoft Threat Modeling Tool: A free, widely used application that guides users through the STRIDE process and helps generate DFDs and identify potential threats.
• OWASP Threat Dragon: An open-source, web-based tool that supports various threat modeling approaches, including STRIDE, and allows for interactive diagramming and threat identification.
• StrideGPT: A particularly interesting, emerging tool available on GitHub. StrideGPT integrates with Large Language Models (LLMs) like ChatGPT. It provides optimized prompts and queries, allowing users to upload system diagrams and documentation. The LLM then assists in identifying potential STRIDE vulnerabilities, significantly speeding up the threat identification phase. This innovation represents a glimpse into the future of automated assistance in threat modeling, leveraging AI to enhance efficiency and comprehensiveness.

These tools, though not demonstrated live, form the practical backbone for conducting the technical deep dive steps outlined in the presentation, enabling teams to systematically analyze, identify, and mitigate threats.

Defensive Implications

▶ Watch: Step 1: Defining the scope and objectives (9:00)

The defensive implications of Hadley Westover's talk are profound and advocate for a fundamental paradigm shift in how organizations approach cybersecurity. The core message is to move from a reactive "fix it later" stance to a proactive "secure by design" philosophy.

1. Embrace "Shift Left" Security: The most significant implication is the necessity of integrating security professionals and threat modeling into the earliest stages of system design and development. By identifying and addressing vulnerabilities in the blueprint phase, organizations can prevent costly redesigns, emergency patches, and reputational damage later on. This proactive approach dramatically reduces the overall cost and effort associated with securing systems.
2. Reduce Costs and Timelines: Proactive threat modeling directly translates into significant cost savings. Discovering and fixing a design flaw before code is written is exponentially cheaper than remediating it in a deployed product. It also prevents project delays that arise from late-stage security overhauls.
3. Enhance Compliance: Threat modeling can be a powerful tool for achieving and maintaining regulatory compliance. By systematically analyzing potential risks against compliance standards (e.g., NIST, ISO 27001, GDPR), organizations can design systems that inherently meet these requirements, avoiding frantic last-minute efforts to retrofit compliance.
4. Foster Cross-Team Collaboration: Effective threat modeling necessitates collaboration across various departments. Security engineers must work hand-in-hand with software developers, system architects, QA testers, and product owners. This interdisciplinary approach not only improves security outcomes but also breaks down silos, leading to better information sharing and a more holistic understanding of system risks. Developers gain a security-aware mindset, while security teams gain deeper insight into system functionality.
5. Prioritize and Manage Risk Effectively: Threat modeling provides a structured way to identify and prioritize risks based on their potential impact and likelihood. This allows defenders to allocate resources strategically, focusing on the most critical vulnerabilities that, if exploited, would cause the most harm. It also provides a clear understanding of residual risks that might remain due to business constraints.
6. Implement Robust Mitigations: The talk emphasizes using industry-standard security controls and favoring design changes over operational procedures for mitigation. Defenders should prioritize making systems inherently secure through architectural choices (e.g., mandating strong authentication, secure communication protocols) rather than relying solely on human vigilance or add-on security features. Specific mitigations discussed, such as code signing for tampering, periodic audit logs for repudiation, input validation/SQL sanitization for information disclosure, load balancers for DoS, and cryptographically secure session tokens for elevation of privilege, provide concrete actions for defenders.
7. Continuous Security Improvement: Threat modeling is not a one-time activity but an iterative process. Defenders must establish mechanisms to re-evaluate threats as systems evolve, new features are added, or the threat landscape changes. This ensures that the "fortress" remains strong against emerging threats.

By adopting these defensive implications, organizations can build systems that are not just patched against known threats but are fundamentally resilient, designed to withstand attacks from the ground up.

Key Takeaways

• Threat modeling is a critical, proactive security tool that helps identify, understand, and mitigate vulnerabilities early in the system design and development lifecycle, preventing costly late-stage discoveries.
• Adopting a "shift left" security approach by integrating threat modeling saves significant time and money compared to fixing architectural flaws after a product has been built or deployed.
• System decomposition using Data Flow Diagrams (DFDs) and identifying trust boundaries are fundamental steps to thoroughly understand a system's architecture and pinpoint potential attack surfaces.
• The STRIDE framework (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) provides a comprehensive methodology for categorizing and identifying diverse threats across different system components (processes, data flows, data stores, external entities).
• Prioritize design changes as the most effective form of mitigation, followed by security controls and operational procedures, always leveraging industry standards and proven frameworks rather than homegrown solutions.
• Successful threat modeling requires cross-team collaboration involving security engineers, developers, architects, QA, and product owners to ensure a holistic and integrated approach to security.
• Tools like Microsoft Threat Modeling Tool, OWASP Threat Dragon, and the emerging StrideGPT (leveraging LLMs) can significantly aid and accelerate the threat modeling process, making it more efficient and thorough.

About the Speaker(s)

Hadley Westover is a Cyber Engineer at the Space Dynamics Laboratory (SDL) in Logan, Utah. SDL is a university-affiliated research center associated with Utah State University, where the government approaches them with complex problems requiring solutions within SDL's core competencies. Hadley has dedicated the last seven years of her career to SDL. She began her tenure as a software test engineer for a couple of years before transitioning into her current role as a cyber engineer after completing her master's degree.

Hadley earned her undergraduate degree from Utah State University and subsequently obtained her master's degree in cybersecurity from Western Governors University. In her capacity as a cyber engineer at SDL, she was instrumental in developing the company's internal threat modeling process, tailoring it to fit their unique systems and existing workflows. She regularly teaches threat modeling classes within SDL, raising awareness and educating colleagues across the company on its effective application. Her practical experience includes working with various government organizations on embedded systems, custom hardware, firmware, and software, often assisting them in designing and assessing system security.