Stephen De Vries - Threat Modeling With Architectural Risk Patterns

### Overview In this presentation, Stephen De Vries, founder of Continuum Security, addresses the bottlenecks of traditional manual threat modeling in fast-paced DevOps and agile environments. Threat modeling is typically a time-consuming, manual thinking exercise (such as STRIDE or PASTA) requiring scarce security expertise. Because the time-versus-accuracy curve exhibits diminishing returns—where basic architectural threats are identified rapidly while nuanced edge cases take significant time—De Vries proposes automating and accelerating the "easy bits" using architectural risk patterns, templates, and rules engines. This approach allows organizations to scale secure design and empower developers with self-service threat modeling.

### Key Topics - **The Bottleneck of Manual Threat Modeling**: Industry data from the BSIMM6 study reveals that while 85% of firms review security features, only 37% conduct application threat modeling, and only 28% have security teams involved. In fast deployment environments, requiring cross-functional teams to spend hours manually analyzing every component creates friction. - **Evolution of Building Blocks**: - *Architecture-Wide Templates*: Using checklists or baseline standards like OWASP ASVS (Application Security Verification Standard), extracting inherent threats and countermeasures. However, single large templates risk being either overwhelming with irrelevant items or insufficiently detailed. - *Component- and Use-Case-Based Templates*: Breaking architectures down into modular components (e.g., HTML web UI, SQL DB, web services) and common use cases (e.g., authentication), though this approach introduces maintenance overhead and duplicate entries. - *Architectural Risk Patterns*: Deconstructing threats and countermeasures into smaller, highly reusable units mapped to components, use cases, or combinations of both. - **Inheritance and Overriding in Risk Patterns**: Structuring risk patterns hierarchically in an object-oriented manner. General service or client threats (e.g., sensitive client storage) can be inherited and overridden with component-specific advice (e.g., using the iOS Keychain instead of generic encryption advice).

### Technical Details - **Automating Selection via Rules Engines**: Rather than forcing developers to manually select low-level patterns, De Vries demonstrates using a rules engine (such as JBoss Drools or Python scripts). Developers answer simple high-level questions about their architecture (e.g., selecting a JSON service or username/password authentication). The rules engine infers dependencies (e.g., a JSON service is an HTTP service, which is a generic service), derives contextual properties (such as sensitive data in transit or stateful sessions), and automatically injects the corresponding threat patterns and countermeasures. - **Trade-offs and Limitations**: Pattern-based threat modeling deliberately bypasses detailed data flows and trust boundaries, which can generate some false positives or omit nuanced contextual risks. It also risks encouraging checklist mentalities if used blindly. However, it can serve as a rapid first-pass baseline, followed by manual deep-dive analysis where needed.

### Takeaways Architectural risk patterns codify security team expertise into reusable organizational assets, ensuring consistency regardless of individual analyst skill or fatigue. To keep threat models relevant over time, resulting countermeasures must be integrated directly into development backlogs (e.g., JIRA tickets). This methodology enables organizations with high developer-to-security ratios to achieve scalable, developer-driven threat modeling while reserving scarce manual security expertise for complex, high-risk systems.