NNEON//FORGE← Vault
SECURITY / ADVANCED / +250 XP

Threat modeling your morning routine

A field guide to thinking like an attacker before the attacker arrives.

Threat modeling is not a workshop. It is a habit. The field guide to thinking like an attacker is not a framework — it is a routine. Every morning, before you open the terminal, ask: what am I protecting, who is trying to get it, and what are they willing to do?

The best security engineers do not think about security as a feature. They think about it as a lens. Every system, every process, every decision has a security dimension. The question is not "is this secure?" — it is "what does this make possible for an attacker?"

THE DEEP DIVE

The STRIDE Model as a Daily Practice

STRIDE is not a checklist. It is a way of thinking. For every component in your system, ask: what Spoofing is possible? What Tampering can occur? What Repudiation is possible? What Information can be leaked? What Denial of Service is possible? What Elevation of privilege is possible?

// Threat model for a webhook endpoint
//
// Spoofing: Can an attacker impersonate the webhook source?
//   -> Check HMAC signature on incoming requests
//   -> Rotate signing keys regularly
//
// Tampering: Can an attacker modify the payload?
//   -> HMAC covers payload integrity
//   -> But what about replay attacks? Add timestamp + nonce
//
// Repudiation: Can the caller deny sending the webhook?
//   -> Log the full request with timestamp
//   -> Store the HMAC for audit
//
// Information Disclosure: Does the error message leak info?
//   -> Return generic 400 for all validation failures
//   -> Log detailed errors server-side only
//
// Denial of Service: Can an attacker flood the endpoint?
//   -> Rate limit by source IP
//   -> Queue payloads, process asynchronously
//
// Elevation of Privilege: Can the webhook trigger admin actions?
//   -> Webhook payloads have limited scope
//   -> Require separate auth for destructive actions

PRINCIPLES

  1. Every system has an attacker model. If you cannot name the attacker, you do not understand the system.
  2. The most dangerous vulnerabilities are the ones that are not in the threat model.
  3. Security is not a binary state. It is a cost-benefit analysis. The question is not 'is it secure?' but 'is it secure enough?'
  4. The threat model must be a living document. It changes when the system changes.
  5. The most effective security control is the one that fails safely. Design for failure.

IN PRACTICE

Webhook Threat Model

A payment webhook endpoint. The attacker wants to fake a payment confirmation. The defense: HMAC signature verification, timestamp validation, nonce tracking, and rate limiting. Each layer catches a different attack vector.

API Threat Model

A REST API with JWT authentication. The attacker wants to escalate privileges. The defense: token validation, scope checking, rate limiting, and audit logging. The token is signed but not encrypted — the payload is visible to anyone who intercepts it.

LIVE SIGNALS

These items surfaced from the intelligence pipeline at generation time.

  • CVE-1999-0095 — The debug command in Sendmail is enabled, allowing attackers to execute commands as root. (NVD / CVE)
  • CVE-1999-1471 — Buffer overflow in passwd in BSD based operating systems 4.3 and earlier allows local users to gain root privileges by specifying a long shell or GECOS field. (NVD / CVE)
  • CVE-1999-1122 — Vulnerability in restore in SunOS 4.0.3 and earlier allows local users to gain privileges. (NVD / CVE)
  • CVE-1999-1506 — Vulnerability in SMI Sendmail 4.0 and earlier, on SunOS up to 4.0.3, allows remote attackers to access user bin. (NVD / CVE)
  • CVE-1999-0084 — Certain NFS servers allow users to use mknod to gain privileges by creating a writable kmem device and setting the UID to 0. (NVD / CVE)

ANTIPATTERNS

  • Threat modeling once and never updating it. The threat landscape changes constantly.
  • Focusing on external threats and ignoring insider threats. The most dangerous attacker has credentials.
  • Implementing security controls without testing them. A security control that has not been tested is a security theater.
  • Assuming that encryption solves everything. Encryption does not protect against authorized access.

CHECKLIST

  • Every component has a threat model entry
  • The threat model is updated when the component changes
  • Each threat has a documented mitigation
  • The mitigations are tested regularly
  • The threat model is accessible to the entire team

YOUR MOVE

Pick one endpoint in your system. Write a STRIDE analysis for it. Document the threats and mitigations. Review it with a teammate.