Threat Modeling

Threat modeling asks what needs protection, what could go wrong, how serious the consequences would be, and how the design will prevent or detect those outcomes. Its output is an actionable set of attack scenarios, security requirements, and accepted residual risks. It is not simply a vulnerability scan: a fully patched application can still expose sensitive information through excessive permissions, broken authorization, or an unsafe integration.

Begin by describing the workload and its business purpose. Identify sensitive data, privileged identities, public endpoints, administrative interfaces, external dependencies, and availability requirements. Map data flows and trust boundaries, such as the transition from an internet client to an API, from application code to a database, or from one cloud account to another. Include deployment pipelines and management APIs because attackers do not have to enter through the application’s public interface.

For each boundary and asset, describe plausible abuse. An attacker might steal a workload credential, change a storage policy, exploit an injection flaw, exhaust an endpoint, or access another customer’s records. Frameworks such as STRIDE help structure this analysis, but using a framework does not replace understanding application behavior. Prioritize scenarios using likelihood, business impact, exposure, and existing safeguards rather than treating every hypothetical attack as equally urgent.

Translate each important scenario into monitoring requirements. For stolen credentials, relevant evidence might include identity-provider sign-ins, role assumptions, unusual API activity, permission changes, and sensitive data access. For data exfiltration, combine application authorization logs, storage access events, and network telemetry where appropriate. Cloud audit logs do not automatically capture every data-plane operation; for example, relevant AWS CloudTrail data events must be explicitly configured. Network flow logs describe traffic metadata, not application request bodies or definitive proof of data theft.

Define what each alert means, who receives it, and what action follows. An alert for disabling audit logging should have a different priority and response from an isolated rejected web request. In a multi-account environment, plan account and Region coverage, centralized collection, retention, restricted access, and protection against log modification or deletion. Validate that a controlled test produces the expected evidence and notification. Logging without a detection rule, an accountable responder, or sufficient investigation context is not a complete detection strategy.

At the network edge, choose controls according to the anticipated attack and protocol. HTTP injection attempts and abusive request patterns call for application-layer inspection and appropriate rate-based rules. Volumetric or transport-layer denial-of-service attacks require DDoS protections and a resilient ingress architecture. CDN delivery can reduce origin load, but caching alone does not protect dynamic endpoints or prevent direct access to an exposed origin. Restrict origin access using mechanisms appropriate to the origin type, and retain application authentication and authorization even when edge filtering is present.

Every choice has trade-offs. Detailed logging increases cost and may capture sensitive information; aggressive filtering can block legitimate customers; rate limits can penalize users behind shared addresses. Tune controls against realistic traffic, record assumptions, and test failure modes. Threat modeling is not a guarantee of security or a one-time compliance document. Revisit it when architectures, identities, data sensitivity, dependencies, or attacker behavior change, and use incident findings to improve both controls and monitoring.