How to think like a security engineer
Security is not a checklist. It is a way of reading any system: what is valuable, who can reach it, where trust changes hands and what happens when a control fails.
01The three questions
- Read any architecture through assets, entry points and trust boundaries
- Use STRIDE per boundary instead of brainstorming random attacks
- Tell prevent, detect and respond controls apart and why you need all three
- Explain defence in depth without hand-waving
Every security engineer, whether reviewing a design doc or sitting in an interview, runs the same three questions in their head. What are we protecting? (assets: customer data, signing keys, the ability to deploy). Who can reach it, and from where? (entry points: public APIs, admin consoles, CI runners, laptops). Where does trust change hands? (boundaries: internet to edge, edge to service, service to database, human to machine).
Attackers do not care about your org chart. They look for the cheapest path from an entry point to an asset. Your job is to make every cheap path expensive, and to know when someone is walking down one anyway.
- EDGE
- SERVICE
- DATA
- CONTROL
- THREAT
- Live flow
- Lookup / async
Interviewers rarely ask "what is threat modelling". They hand you a diagram and watch whether you find the boundaries unprompted. The strongest signal is naming which boundary a given control protects, not listing tools.
02STRIDE, boundary by boundary
STRIDE is a memory aid for the six things that go wrong at a trust boundary. Apply it to one boundary at a time; applying it to a whole system at once produces noise.
| Threat | Question to ask | Typical control |
|---|---|---|
| Spoofing | Can the caller pretend to be someone else? | Strong authn, mTLS, signed tokens |
| Tampering | Can data be changed in flight or at rest? | TLS, integrity checks, signed artifacts |
| Repudiation | Can someone deny they did it? | Append-only audit logs with identity |
| Information disclosure | Can data leak to the wrong party? | Encryption, authz, data minimisation |
| Denial of service | Can the boundary be overwhelmed? | Rate limits, quotas, scrubbing, autoscale |
| Elevation of privilege | Can a low-trust caller gain high trust? | Least privilege, input validation, sandboxing |
Walk a boundary: browser to API. Spoofing: stolen session cookie, so bind sessions to device signals and keep them short. Tampering: a proxy edits the body, so TLS everywhere. Repudiation: a user disputes an order, so log who, what, when with the request ID. Disclosure: an IDOR returns another tenant's record, so authorise every object read. DoS: credential stuffing, so rate limit by IP and account. Elevation: a role field in the request body is trusted, so never take authz inputs from the client.
"I'll go boundary by boundary. At the internet-to-edge boundary the main threats are spoofing and DoS, so I put TLS termination, bot detection and rate limiting there. At the service-to-database boundary the threat is elevation through injection and disclosure through over-broad credentials, so I use parameterised queries and one database role per service with only the tables it needs."
03Prevent, detect, respond
A control that only prevents is a single point of failure. Mature systems assume prevention will fail some of the time and invest in detection (you find out quickly) and response (you can contain without heroics).
- EDGE
- SERVICE
- DATA
- STREAM
- THREAT
- Live flow
- Lookup / async
- Prevent: MFA, input validation, least privilege IAM, network policy, encryption.
- Detect: authentication anomalies, EDR alerts, cloud audit log rules, canary tokens.
- Respond: session revocation, host isolation, credential rotation, feature kill switches.
Two controls that fail the same way are one control. A WAF and an API gateway that both key off the same IP allow-list give you no extra depth. Depth means independent failure modes.
04Talking about risk like an engineer
Risk is likelihood times impact, but in a design review you need something more concrete. Use exposure (how reachable is the weakness), exploitability (does a working exploit exist, is it automated) and blast radius (what does the attacker get). A critical CVE in a service that only listens on localhost behind mTLS is lower risk than a medium in your public login flow.
Say the trade-off out loud. "We are accepting that the internal metrics endpoint has no authn because it is only reachable from the service mesh, and we alert if it ever appears in the ingress logs." That sentence is a risk decision with a compensating detection and an owner. It is what good security engineering sounds like.
A payments service stores card tokens. Which boundary deserves the first STRIDE pass?
Q1What is the difference between a vulnerability and a threat?+
A threat is something that could go wrong (a spoofed caller). A vulnerability is a weakness that makes it possible (session cookies without the Secure flag). Risk is the combination with likelihood and impact.
Q2How do you keep a threat model from going stale?+
Attach it to the architecture, not a document: re-run it when a new entry point, data store or trust boundary is added, and make that a checkbox in the design review template.
Q3Is zero trust just defence in depth?+
Zero trust is a specific stance: no implicit trust from network location, every request authenticated and authorised with identity and device context. It is one way to add depth at the identity boundary, not a replacement for the others.