# Threat Modeling
Domain: Threat Intelligence & Defense (TID), Vulnerability & Secure Design (VSD), Risk Governance & Assurance (RGA)
---
Threat modeling is a structured process for identifying, quantifying, and prioritizing potential threats to a system, application, or organization. It answers four fundamental questions: What are we building? What can go wrong? What are we going to do about it? Did we do a good enough job?
The practice exists because reactive security fails at scale. Organizations that wait for penetration tests, bug bounties, or production incidents to discover security flaws are addressing symptoms, not causes. Design-level vulnerabilities identified during development cost hundreds of times less to remediate than the same issues discovered post-deployment. A trust boundary misunderstanding that requires a two-hour architecture discussion in the design phase becomes a month-long refactoring effort once the application is in production.
Threat modeling fits into the broader security ecosystem as the bridge between abstract security principles and concrete implementation decisions. It transforms general guidance like "implement defense in depth" into specific controls mapped to identified attack vectors. Where security policies describe what must be done, threat models describe why it must be done and exactly where it must be applied.
Established methodologies include STRIDE (Microsoft), which categorizes threats into Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. PASTA (Process for Attack Simulation and Threat Analysis) focuses on business context and compliance requirements. LINDDUN addresses privacy-specific threats like linkability, identifiability, and detectability. Attack trees decompose complex attack scenarios into component steps, making it easier to identify where defensive controls should be placed.
The practice is most effective when integrated early in the software development lifecycle, ideally during the architecture and design phases when foundational security decisions are made.
Threat modeling begins with system decomposition. The analyst breaks down the target system into its fundamental components: processes, data stores, external entities, and the data flows connecting them. This decomposition is typically represented in a data flow diagram (DFD), which serves as the foundation for all subsequent analysis.
Trust boundaries are the most critical element to identify correctly. These represent points where data changes privilege levels, crosses security controls, or moves between different levels of trust. Common trust boundaries include the perimeter between internet and internal network, the boundary between application tiers, and the separation between user space and kernel space. Each trust boundary represents a potential attack vector that requires specific defensive controls.
Entry points catalog how external entities can interact with the system. For a web application, entry points include HTTP endpoints, database connections, file uploads, and API calls. Each entry point represents potential attack surface that must be analyzed for relevant threat categories.
Assets are the valuable resources the system processes, stores, or controls. These include sensitive data like personally identifiable information or financial records, but also include system availability, configuration integrity, and business logic correctness. Understanding assets helps prioritize threats based on potential business impact rather than just technical severity.
The analysis phase applies a systematic methodology to evaluate each system component. Using STRIDE as an example, analysts examine each process, data store, and data flow for potential spoofing attacks (can an attacker impersonate a legitimate user or system component?), tampering attacks (can data or code be modified in transit or at rest?), repudiation issues (can actions be performed without attribution?), information disclosure vulnerabilities (can sensitive data be accessed by unauthorized parties?), denial of service vectors (can system availability be disrupted?), and elevation of privilege paths (can attackers gain higher access levels than intended?).
Each identified threat receives a risk rating that combines likelihood and impact. DREAD scoring evaluates Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability. CVSS provides a standardized approach using base metrics (attack vector, attack complexity, privileges required, user interaction), temporal metrics (exploit code maturity, remediation level, report confidence), and environmental metrics (confidentiality, integrity, and availability requirements).
Mitigation mapping connects specific defensive controls to identified threats. Authentication controls address spoofing. Input validation and output encoding prevent tampering and injection attacks. Comprehensive logging and non-repudiation controls address repudiation threats. Encryption and access controls protect against information disclosure. Rate limiting, resource management, and redundancy address denial of service. Principle of least privilege and defense in depth prevent elevation of privilege.
The process is iterative. Threat models are living documents that evolve as system architecture changes, new threats emerge, or business requirements shift. Regular reviews ensure that security assumptions remain valid and that new features or integrations are properly analyzed.
Consider a specific example: an e-commerce application with web front-end, application server, and database tiers. The trust boundary between the web server and application server might be threatened by SQL injection attacks if user input is not properly validated. The threat model would identify this data flow, categorize SQL injection as a tampering threat, rate it as high severity due to potential data breach impact, and specify input validation and parameterized queries as mitigations. The model would also identify information disclosure threats if the database connection uses unencrypted transport and specify TLS encryption as a mitigation.
Threat modeling prevents the most expensive category of security failure: architectural vulnerabilities that require fundamental design changes to address. A privilege escalation vulnerability that stems from incorrect trust boundary assumptions cannot be fixed with a patch. It requires architectural redesign, often affecting multiple system components and integration points.
The business impact extends beyond direct security benefits. Threat models produce documentation that satisfies regulatory and compliance requirements for risk assessment. SOC 2 Type II audits require evidence that security risks have been systematically identified and addressed. ISO 27001 certification requires documented risk assessment processes. FedRAMP authorization requires comprehensive security architecture documentation. Threat models provide this evidence in a format that auditors can evaluate and that demonstrates systematic rather than ad hoc security analysis.
For development organizations, threat modeling creates shared understanding between security and engineering teams. Instead of security being perceived as a compliance burden imposed after development decisions are made, it becomes an integral part of the design process. Developers gain insight into why specific security controls are required and how they fit into the broader security architecture. Security teams gain detailed understanding of system architecture that enables more targeted and effective security guidance.
The failure consequences of inadequate threat modeling are severe and often invisible until exploitation occurs. Systems deployed without systematic threat analysis contain unknown attack vectors that adversaries will eventually discover and exploit. The time gap between deployment and discovery creates a false sense of security that ends abruptly when incidents occur.
A common misconception is that threat modeling is only relevant for high-security environments or applications that handle sensitive data. In practice, every system that connects to a network or processes user input has attack surface that benefits from systematic analysis. Another misconception is that threat modeling is primarily a documentation exercise. Effective threat modeling changes design decisions, not just documents them. If a threat model does not result in architectural or implementation changes, it was either applied to a system that was already well-designed from a security perspective, or it was not conducted with sufficient rigor.
Organizations often underestimate the cascading effects of architectural security flaws. A single trust boundary error can create multiple attack vectors across different threat categories. Fixing these issues post-deployment often requires extensive regression testing, security review, and coordination across multiple development teams.
CDA approaches threat modeling through the lens of Predictive Defense Intelligence (PDI): "See the threat before it sees you." This shifts threat modeling from a reactive design exercise to a proactive intelligence operation that anticipates adversary behavior and builds defensive capabilities accordingly.
The Threat Intelligence & Defense (TID) domain owns the methodology and maintains the threat landscape intelligence that informs threat model assumptions. However, threat modeling execution spans multiple domains. Vulnerability & Secure Design (VSD) applies threat modeling to system architecture and implementation decisions. Risk Governance & Assurance (RGA) ensures that threat modeling outputs feed into broader risk management processes and compliance frameworks.
CDA's approach differs from conventional threat modeling in several key aspects. First, we integrate current adversary tactics, techniques, and procedures (TTPs) into threat model assumptions rather than relying on generic threat categories. STRIDE provides a useful framework, but real adversaries do not attack in STRIDE categories. They follow specific attack patterns that can be anticipated and defended against.
Second, we treat threat modeling as an intelligence collection activity, not just a design activity. Each threat model provides insight into how adversaries might approach similar systems. This intelligence feeds back into our broader threat landscape understanding and improves future threat modeling efforts across all client engagements.
Third, we emphasize defensive capability building over vulnerability cataloging. Conventional threat modeling often produces long lists of theoretical threats with generic mitigation guidance. CDA's approach focuses on building specific defensive capabilities that address the highest-probability attack vectors based on current adversary behavior and the specific threat environment facing each organization.
The PDI methodology requires that threat models incorporate environmental context. A financial services organization faces different adversaries with different capabilities and motivations than a construction company or healthcare provider. Generic threat models that ignore this context miss the most relevant threats while over-emphasizing less likely scenarios.
We also integrate threat modeling into operational security processes rather than treating it as a point-in-time design activity. Threat models inform security monitoring requirements, incident response procedures, and threat hunting activities. This operational integration ensures that theoretical threat analysis translates into practical defensive capability.
• Threat modeling prevents architectural security flaws that cost 100-1000x more to fix post-deployment than during design phase • Effective threat modeling changes system design decisions, not just documents them; if no design changes result, the analysis was insufficient • Trust boundaries are the most critical element to identify correctly, as each represents a potential privilege escalation vector requiring specific controls • Threat models must incorporate current adversary TTPs and environmental context rather than relying on generic threat categories to be operationally relevant • The practice spans multiple security domains: TID provides threat intelligence, VSD applies it to design decisions, and RGA ensures integration with risk management processes
• Attack Surface Management • Security Architecture Review • Risk Assessment Methodologies • Vulnerability Management Programs • Security Requirements Engineering
• NIST Special Publication 800-154, "Guide to Data-Centric System Threat Modeling" • Microsoft Security Development Lifecycle, "Threat Modeling" • OWASP Application Threat Modeling • ISO/IEC 27005:2018, "Information Security Risk Management" • MITRE ATT&CK Framework for Enterprise