Threat Modeling & Architectural Defense
Threat modeling is the practice of systematically identifying potential security vulnerabilities, threat agents, and attack vectors in a system architecture before code is written. Fixing architectural flaws on whiteboard diagrams costs up to 100x less than resolving vulnerabilities in production.
1. Why Threat Model Early? Proactive Risk Elimination
Over 50% of software security vulnerabilities originate in architectural design flaws (missing encryption boundaries, broken trust assumptions) rather than simple syntax bugs. Threat modeling answers four fundamental engineering questions:
1. What are we building?
Deconstruct architecture into Data Flow Diagrams (DFDs) identifying processes, data stores, and trust boundaries.
2. What can go wrong?
Apply the STRIDE framework to uncover spoofing, tampering, repudiation, and privilege escalation risks.
3. What will we do about it?
Design concrete architectural mitigations (encryption, mTLS, tokenization) and record them in the Threat Register.
4. Did we do a good job?
Validate mitigations through automated SAST/DAST tests and formal QA verification protocols.
2. The Microsoft STRIDE Threat Modeling Matrix
STRIDE categorizes every cyber threat against its opposing desired security property. Select any STRIDE category to inspect its definition and standard mitigation pattern:
Spoofing Identity (S)
Opposing Property: AuthenticationThreat Definition: An attacker pretends to be another user, system component, or third-party service.
3. Data Flow Diagrams (DFD) & Trust Boundaries
Threat modeling decomposes architecture into 5 standard DFD elements. The single most critical concept is the Trust Boundary — where data crosses from an untrusted zone into a trusted zone:
Patients, clinical clinicians, third-party labs, or payment processors interacting with the system.
Web servers, API gateways, background workers, and lambda functions executing business logic.
PostgreSQL databases, S3 object storage buckets, Redis cache clusters holding sensitive data.
Dotted lines representing perimeter switches (e.g. Internet ➡️ DMZ, or DMZ ➡️ Clinical DB VPC).
4. Auditable DHF Threat Risk Register Template
All identified threats must be recorded in an auditable Threat Register with unique IDs, CVSS severity scores, design mitigations, and automated verification tests:
| Threat ID | STRIDE Type | Identified Threat Description | Architectural Mitigation | Verification Test |
|---|---|---|---|---|
| THR-101 | Spoofing | Attacker forges JWT session token to access patient chart | RS256 asymmetric signature verification with HSM private key | test_jwt_tampered_signature() |
| THR-102 | Info Disclosure | Unencrypted database backup exfiltrated from S3 bucket | Enforced AWS KMS AES-256 bucket encryption policy | test_s3_bucket_encryption_policy() |
Community Discussion & Feedback
Attributed peer feedback and official Netspective architecture notes.