<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
---
name: security-architecture
description: >-
  Security architecture design, threat modeling (STRIDE, DREAD, PASTA), zero trust
  architecture, defense-in-depth, blast radius analysis, network segmentation,
  microsegmentation, cloud security reference architectures, identity fabric design,
  and security design reviews. Use when asked about architecture, threat models,
  trust boundaries, DFD, compensating controls, or design review.
domain: cybersecurity
subdomain: security-architecture
tags:
  - threat-modeling
  - zero-trust
  - defense-in-depth
  - stride
  - dread
  - pasta
  - network-segmentation
  - microsegmentation
  - cloud-architecture
  - identity-fabric
  - blast-radius
version: "1.1"
author: defconxt
license: AGPL-3.0
compatibility: Designed for Claude Code, GitHub Copilot, OpenAI Codex, Cursor, Gemini CLI, and any agentskills.io-compatible agent.
metadata:
  mitre-attack: ["T1190", "T1078", "T1021", "T1557"]
  nist-csf: ["ID.AM", "ID.RA", "PR.AC", "PR.DS", "PR.IP", "PR.PT"]
  frameworks: ["NIST SP 800-207", "AWS Well-Architected", "CIS Controls"]
---

# Security Architecture & Threat Modeling

## When to Use

- Security architecture design and review
- Threat modeling with STRIDE, DREAD, or PASTA methodology
- Zero trust architecture planning (NIST SP 800-207)
- Defense-in-depth layering and control mapping
- Network segmentation and microsegmentation design
- Cloud security reference architectures (AWS, Azure, GCP, Kubernetes)
- Identity fabric design (SSO, PAM, service identities, FIDO2)
- Blast radius analysis for proposed changes or vulnerabilities
- Security design review checklists

## Prerequisites

- Architecture diagrams or DFD of the system under review
- `pytm` for programmatic threat models: `pip install pytm`
- OWASP Threat Dragon for collaborative DFD + STRIDE
- ATT&CK and CAPEC for threat enumeration

## Quick Reference

| Task | Approach |
|------|----------|
| STRIDE per element | Spoofing, Tampering, Repudiation, Info Disclosure, DoS, EoP |
| DREAD scoring | Damage, Reproducibility, Exploitability, Affected Users, Discoverability (1-10) |
| PASTA | 7-stage: objectives → DFD → threat analysis → vuln analysis → attack modeling → risk → countermeasures |
| pytm DFD | `python3 tm.py --dfd \| dot -Tpng -o dfd.png` |
| Trust boundary | Every arrow crossing needs authn, authz, input validation, encryption |
| Attack surface | `sum(entry_points × privilege_level × protocol_complexity)` |

## Workflow

### 1. Threat Modeling

1. Choose methodology: STRIDE (per-element), PASTA (risk-centric), or hybrid
2. Draw DFD: external entities, processes, data stores, data flows, trust boundaries
3. For each element crossing a trust boundary, enumerate STRIDE threats
4. Score threats: DREAD (1-10 per dimension) or CVSS
5. Map mitigations to each threat; assign owner and priority

**STRIDE per element type:**

| Element | Applicable Threats |
|---------|-------------------|
| External Entity | Spoofing |
| Process | All six (S, T, R, I, D, E) |
| Data Store | Tampering, Info Disclosure, DoS |
| Data Flow | Tampering, Info Disclosure, DoS |

### 2. Architecture Design

Design defensible systems using zero trust and defense-in-depth principles:

1. Define trust zones and boundaries
2. Apply zero trust: identity-verified access at every layer
3. Layer defenses: perimeter → network → endpoint → application → data → identity → operations
4. Map controls: preventive, detective, corrective, deterrent per layer

Read `references/architecture-patterns.md` for zero trust implementation layers, defense-in-depth control mapping, network segmentation patterns, cloud reference architectures, and identity fabric design.

### 3. Blast Radius Analysis

For any proposed change or identified vulnerability:
1. **Scope**: What systems are directly affected?
2. **Lateral reach**: What else can the attacker reach from here?
3. **Data exposure**: What data becomes accessible? Classification level?
4. **Privilege level**: What permissions does the attacker gain?
5. **Detection likelihood**: Would current monitoring catch this?
6. **Recovery cost**: How hard to restore to known-good state?

Mitigation: compartmentalize with hard boundaries (separate accounts, networks, identities).

### 4. Security Design Review

```
[ ] Authentication — MFA? Phishing-resistant?
[ ] Authorization — Least privilege? RBAC/ABAC? Reviewed regularly?
[ ] Data protection — Classified? Encrypted at rest + transit? Key rotation?
[ ] Network controls — Segmented? Microsegmented? East-west inspection?
[ ] Secrets management — Vault/KMS? Rotation? No hardcoded secrets?
[ ] Logging and monitoring — All components? Centralized? Alerting?
[ ] Incident response — Runbooks? Tested? Escalation paths?
[ ] Supply chain — Dependencies scanned? SBOM? Signed artifacts?
[ ] Availability — Redundancy? Failover? Backup tested? RTO/RPO?
[ ] Compliance — Regulatory requirements mapped? Controls documented?
```

## Verification

- Threat model covers all DFD elements crossing trust boundaries
- Every HIGH/CRITICAL threat has a documented mitigation with owner
- Architecture follows least-privilege and deny-by-default at each layer
- Network segmentation validated with actual traffic flow testing
- Design review checklist completed with no unmitigated gaps
