cloudthinker-ai Threat Model
Phase 1: System Decomposition
Define the system boundaries and components.
- System description and purpose
- Architecture diagram with trust boundaries
- Identify all entry points (APIs, UIs, message queues, file inputs)
- Identify all data stores
- Identify all external dependencies
- Identify all user roles and privilege levels
Trust Boundaries:
| Boundary | Components Inside | Components Outside | Data Crossing |
|---|---|---|---|
Assets:
| Asset | Sensitivity | Confidentiality | Integrity | Availability |
|---|---|---|---|---|
| High/Med/Low | Required Y/N | Required Y/N | Required Y/N |
Phase 2: Threat Identification (STRIDE)
For each component and data flow, evaluate STRIDE threats.
| Component/Flow | Spoofing | Tampering | Repudiation | Info Disclosure | Denial of Service | Elevation of Privilege |
|---|---|---|---|---|---|---|
| Y/N | Y/N | Y/N | Y/N | Y/N | Y/N |
Detailed Threat Catalog:
| ID | Threat | STRIDE Category | Component | Attack Vector | Likelihood | Impact | Risk Score |
|---|---|---|---|---|---|---|---|
| T1 |
Likelihood Scale: 1 (Very Low) - 5 (Very High) Impact Scale: 1 (Negligible) - 5 (Critical) Risk Score: Likelihood x Impact
Phase 3: Risk Assessment
Risk Matrix:
| Impact: 1 | Impact: 2 | Impact: 3 | Impact: 4 | Impact: 5 | |
|---|---|---|---|---|---|
| Likelihood: 5 | Medium | High | High | Critical | Critical |
| Likelihood: 4 | Medium | Medium | High | High | Critical |
| Likelihood: 3 | Low | Medium | Medium | High | High |
| Likelihood: 2 | Low | Low | Medium | Medium | High |
| Likelihood: 1 | Low | Low | Low | Medium | Medium |
Phase 4: Mitigation Planning
For each threat with risk score >= Medium:
| Threat ID | Mitigation Strategy | Control Type | Status | Owner | Priority |
|---|---|---|---|---|---|
| Accept / Mitigate / Transfer / Avoid | Preventive / Detective / Corrective |
Mitigation Details:
For each mitigation:
- Describe the control
- Implementation effort estimate
- Residual risk after mitigation
- Verification method
Phase 5: Validation
- All entry points have been analyzed
- All data stores have been analyzed
- All trust boundaries have been identified
- All high/critical risks have mitigations
- Mitigations are testable and verifiable
- Model reviewed by security team
Counter-Rationalizations
| Shortcut | Counter | Why |
|---|---|---|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |
Output Format
Summary
- System: ___
- Threats identified: ___
- Critical risks: ___
- High risks: ___
- Mitigations defined: ___
- Residual risk assessment: Acceptable / Needs Attention / Unacceptable
Action Items
- Implement all Critical risk mitigations before launch
- Implement High risk mitigations within first sprint post-launch
- Schedule penetration test to validate mitigations
- Update threat model when architecture changes
- Review threat model annually at minimum