Authority lesson · 826 words
Security Architecture and Threat Modeling
Threat modelling begins with the system you actually have
Start with assets and outcomes: customer data, money, credentials, service availability, reputation, safety, and the integrity of decisions. Draw how data enters, where it is transformed, stored, displayed, queued, and sent to third parties. Mark trust boundaries where identity, privilege, organisation, process, network, or provider responsibility changes. A diagram of boxes without data and trust is decoration, not a threat model.
Include administrators, support staff, CI, background workers, exports, backups, and recovery tools. Internal does not mean trusted. Ask how a compromised account, malicious input, mistaken staff action, stolen secret, vulnerable dependency, or unavailable provider affects each asset. Use realistic capabilities rather than movie villains.
Turn threats into testable requirements
For each boundary, ask what could be spoofed, altered, exposed, denied, or performed without accountability. Then write requirements: webhook signatures must be verified against the raw body; report downloads must be tenant-scoped; audit URLs must reject private-network targets; privileged changes require recent MFA; secrets must not appear in logs; uploads must be type-checked and stored outside executable paths. A control that cannot be tested or observed is difficult to trust.
Prefer preventive design: minimise data, narrow privileges, isolate workloads, use safe framework defaults, and make dangerous actions explicit. Add detection and recovery because prevention will not be perfect. Record which risk is accepted, by whom, for how long, and what evidence would trigger review.
Abuse cases expose product risks
Security reviews often focus on malformed requests while missing legitimate features used harmfully. A free audit can be abused to scan private infrastructure. A message system can harass recipients. A support export can become bulk data exfiltration. A teen-safety form can invite disclosure of exploitative content. Write abuse cases from the actor’s objective and add limits, consent, moderation, rate controls, retention, and escalation appropriate to the harm.
Do not collect sensitive detail merely because a form can. Ask for the minimum information required to route help. Provide clear warnings about what must not be uploaded. For high-risk content, direct users to qualified official reporting routes rather than storing material your organisation is not equipped to protect or investigate.
Review change and verify controls continuously
Threat models are living records. Revisit them when adding a provider, role, upload, public endpoint, queue, AI feature, or new data class. Link threats to tests, configuration checks, monitoring, and incident runbooks. Include security review in migration and deployment plans because a safe design can be undermined by permissive production settings or copied secrets.
Use independent review for high-risk systems, but do not outsource ownership. Track findings through remediation, evidence, and closure. Test negative paths, cross-tenant access, signature failure, rate limits, token expiry, restore access, and staff privilege. A completed diagram is not the outcome; reduced and observable risk is.
Scenario
A website audit becomes a server-side request-forgery tool
A public form accepts any URL and the worker follows redirects. An attacker submits a public URL that redirects to a cloud metadata endpoint or private administration panel. The feature’s normal purpose is legitimate, but the boundary allows the server to reach systems the user cannot. Resolve and validate every target and redirect, block private and special ranges, limit schemes, ports, size, time, and pages, and avoid sending internal credentials.
- Model every redirect as a new boundary
- Validate resolved IPs immediately before connection
- Limit schemes, ports, size, time, and depth
- Log safe evidence and alert on repeated blocked attempts
Worked example
Threat-model a report-download feature
- List assets: report content, tenant identity, storage credentials, audit trail, and availability.
- Draw browser, web app, database, object storage, and support access.
- Identify threats: guessed IDs, cross-tenant query, leaked public URL, malicious filename, excessive export, and staff misuse.
- Define controls and tests for scoped queries, short-lived access, safe headers, limits, and audit events.
- Assign accepted residual risks and a review trigger.
Checklist
Use this before acting
- Name assets and harmful outcomes
- Draw data flows and trust boundaries
- Include staff, CI, workers, backups, and providers
- Write abuse cases as well as technical attacks
- Convert threats into testable requirements
- Minimise data and privilege
- Link controls to monitoring and incident response
- Review models after meaningful change
Common mistakes
Failure patterns to avoid
- Starting with a generic threat list before understanding data flow
- Treating internal actors and networks as trusted
- Ignoring legitimate-feature abuse
- Adding controls without tests or signals
- Collecting sensitive content without operational capacity
- Closing findings without verification evidence
Practical exercise
Threat-model one public feature
Draw the data flow for a form, upload, webhook, audit, or download. Identify assets, actors, boundaries, at least ten threats or abuses, current controls, missing tests, residual risk owner, and incident signals.
Deliverable: A reviewed data-flow diagram, threat register, and linked verification plan.
Sources and further reading
Primary and official references
Topic-specific takeaway
Threat modelling is useful when it changes requirements, boundaries, tests, monitoring, and recovery before an attacker or accident does.
