Threat Modeling & Zero-Trust Architecture

Threat modeling and zero-trust are complementary

The two skills here are complementary: threat modeling is how you reason about attackers before you build, and zero-trust is the architecture you arrive at when you take the conclusions seriously.

Threat modeling with STRIDE

You draw a data-flow diagram with trust boundaries (where data crosses from less-trusted to more-trusted, for example browser to API, API to database, your service to a third-party processor), then walk each element and each boundary crossing against the STRIDE categories:

  S  Spoofing               pretending to be another identity        -> authentication
  T  Tampering              modifying data or code in transit/rest    -> integrity (signing, hashes, TLS)
  R  Repudiation            denying an action you took                -> audit logging, non-repudiation
  I  Information disclosure  leaking data                             -> encryption, access control
  D  Denial of service      degrading availability                    -> rate limits, quotas, redundancy
  E  Elevation of privilege gaining rights you should not have        -> authorization, least privilege

Each STRIDE category maps to a defense property, so the exercise systematically surfaces gaps instead of relying on whoever remembers to think about security. You prioritize the resulting threats (likelihood x impact, or DREAD) and only mitigate what matters.

Secure-design principles

The principles you apply to the mitigations: least privilege (each component gets the minimum access it needs), defense in depth (layered controls so one failure is not fatal), fail secure (on error, deny rather than allow), complete mediation (check authorization on every access, not once at the start), secure defaults (safe out of the box, opt into risk), and assume breach (design as if the attacker is already inside).

Zero-trust

The old model was a hard perimeter with a soft interior: get past the VPN/firewall and the internal network trusts you. That fails because one phished laptop or one compromised service inside the perimeter can then talk freely to everything (lateral movement), and the blast radius is the whole network. Zero-trust, popularized by Google's BeyondCorp, flips it: never trust, always verify. There is no privileged network location. Every request, including internal east-west service-to-service traffic, is authenticated and authorized on its own merits.

Concretely for microservices: give every workload a cryptographic identity (SPIFFE/SPIRE, or cloud IAM roles), and enforce mTLS for all service-to-service calls via a service mesh (Istio, Linkerd, Consul) so both sides prove who they are and traffic is encrypted and its identity is verified. Replace the VPN with an identity-aware proxy (BeyondCorp-style, or Cloudflare Access / Google IAP) that authenticates the user and device on every request to internal apps. Add micro-segmentation: default-deny network policy so service A can reach only the specific services it needs, not the whole subnet.

Zero-trust redesign: verify every hop, contain the blast radius

Step 1 / 4

Stage 1 of 4: Start with the perimeter model's failure: one phished laptop behind the VPN was implicitly trusted, so lateral movement reached the whole flat network.

The payoff is blast-radius containment. If one service is compromised, it holds a narrowly scoped identity, can reach only its explicit dependencies, and every call it tries is authenticated and logged, so lateral movement is slow, loud, and bounded instead of instant and silent.

Interview nuance: the classic wrong turn is bolting security on at the end ("we will add auth before launch"). Threat modeling is valuable precisely because it is done at design time, when changing a trust boundary is a diagram edit rather than a rewrite. And the classic zero-trust misconception is that it is a product you buy; it is an architecture principle (verify every request, no implicit network trust) that mTLS, identity-aware proxies, and micro-segmentation implement.

Recap: STRIDE walks a data-flow diagram's trust boundaries to surface spoofing/tampering/repudiation/info-disclosure/DoS/elevation threats, each mapping to a defense; apply least privilege, defense in depth, fail secure, complete mediation, secure defaults, and assume-breach; and implement zero-trust (never trust, always verify) with workload identity, mTLS via a service mesh, identity-aware proxies replacing VPNs, and micro-segmentation to contain lateral movement and blast radius.