Threat Modeling

Threat modeling identifies how a system can be abused before attackers, incidents, or auditors find the gaps. Keep it practical and tied to architecture decisions.

When to threat model

Run a threat model when a change introduces or modifies:

• Public ingress or authentication flows.
• Sensitive data storage or movement.
• Privileged administrative capabilities.
• Third-party integrations.
• Cross-account, cross-region, or hybrid connectivity.
• New runtime platforms or shared infrastructure.

Lightweight flow

Questions

Ask:

• What are we protecting?
• Who can access it?
• Where does trust change?
• What happens if this dependency is compromised?
• What data leaves the boundary?
• What privileged action could cause customer impact?
• How would abuse be detected?

Outputs

A useful threat model produces:

• System boundary and data-flow notes.
• Top threats and abuse cases.
• Existing controls.
• Missing controls and owners.
• Accepted risks with expiry or review trigger.
• Follow-up backlog items.

Watchouts

• Do not turn threat modeling into a giant meeting with no decisions.
• Do not require perfect diagrams before discussing risk.
• Do not accept "private network" as a complete security control.
• Revisit the model when architecture, data, or exposure changes.