Security engineering fundamentals

Confidentiality, integrity and availability: information is seen only by those who should see it, is not altered without detection, and is accessible when it is needed. It is not a checklist because the three routinely conflict rather than stack — encrypting everything at rest strengthens confidentiality while adding latency that works against availability, and a system hardened against unauthorised change by locking everything down can become unusable by the people who legitimately need it. A security decision is almost always a trade among the three, not an attempt to maximise all of them, and naming which one you are prioritising and why is the actual skill.

A vulnerability is a weakness in a system — an unpatched library, a missing authorisation check. A threat is a potential actor or event that could exploit that weakness — a specific attacker group, or an untrained employee clicking a link. Risk is the combination: the likelihood of a threat exploiting a vulnerability, multiplied by the impact if it succeeds. Conflating them produces bad prioritisation, because a severe vulnerability with no realistic threat actor and no path to serious impact is lower risk than a moderate vulnerability sitting on an internet-facing endpoint that every automated scanner on the internet will find within days.

Multiple independent layers of control, so that a failure in one does not become a full compromise. A firewall, an authentication check, an authorisation check, input validation and encryption at rest are each individually imperfect, but an attacker who bypasses one still has to beat the next. The design consequence is that no single control gets to be the only thing standing between an attacker and the data — which is why "we have a WAF" is never a complete answer to "how is this protected."

Every user, service and credential holds only the access it needs for its specific task, and nothing more. A service account that can read a database and one that also happens to have delete rights it never uses is a bigger blast radius the moment either the account or the service is compromised, even though the extra privilege was never exercised legitimately. The practical failure mode is privilege that accumulates over time — someone was granted broad access for a one-off migration and it was never revoked — which is why least privilege is a process of continual pruning, not a one-time grant decision.

Hiding how a system works is sometimes a genuine layer, but it fails as the primary control because it cannot survive the mechanism becoming known, and mechanisms leak.

Assumption: attacker does not know our API uses sequential numeric ids.

Day 1    Ids look random-ish in the demo. Feels safe.
Day 40   A support ticket screenshot shows two consecutive ids.
Day 41   Every id from 1 to the current max is now guessable.
Day 41   The actual control that was supposed to stop this
         — an authorisation check per id — was never written,
         because the numbering "obscurity" felt like enough.

The lesson is not that obscurity is worthless — not advertising your internal architecture is reasonable hygiene — but that it must never be the control an attacker actually has to defeat. Kerckhoffs's principle states this precisely for cryptography: a system should remain secure even if everything about it except the key is public, and the same logic generalises to application design. If revealing your mechanism breaks your security, the mechanism was the vulnerability, not the disclosure.

Authentication establishes who is making the request. Authorisation decides whether that specific identity may perform this specific action on this specific resource. They are evaluated at different points and with different information, and the most common serious defect in real systems is implementing the first correctly and treating the second as implied by it — checking that a token is valid, then fetching whatever resource id the request asked for without checking that the authenticated identity actually owns it.

A point in a system where data or a request crosses from one level of trust to another — a network perimeter, a process boundary, the line between user input and application code, the handoff from one service to another. Every trust boundary is a place validation must happen, because whatever crosses it can no longer be assumed to be what it claims. Threat modeling is largely the discipline of finding every trust boundary in a system and asking what happens at each one when the assumption fails.

Injection happens when untrusted input is interpreted as code or command syntax rather than as data, because the application concatenated it into a query, a shell command or a template rather than keeping it separate. SQL injection is the canonical case, but the same shape recurs in command injection, LDAP injection and template injection — anywhere a string built from user input is handed to an interpreter. It persists on every list not because the fix is unknown but because the unsafe pattern — string concatenation — is the naive first thing anyone writes, and the safe pattern — a parameterised query, an escaped shell argument — requires knowing to reach for it.

The vulnerable version treats the user's input as part of the SQL syntax itself, not as a value.

// Vulnerable: the input can close the string and add its own SQL.
String query = "SELECT * FROM users WHERE username = '" + input + "'";
// input = "' OR '1'='1"  ->  WHERE username = '' OR '1'='1'
// returns every row in the table

// Fixed: the placeholder is bound as a value, never parsed as syntax.
PreparedStatement stmt = conn.prepareStatement(
    "SELECT * FROM users WHERE username = ?");
stmt.setString(1, input);

The reason parameterisation actually fixes this rather than merely making it harder is structural, not a matter of degree: the database driver sends the query text and the parameter value as two separate things over the wire, so the value is never parsed as SQL syntax at all, regardless of what characters it contains. Escaping special characters is a fallback for contexts where parameterisation genuinely isn't available, and it is strictly weaker, because it depends on the escaping logic covering every dialect quirk of the specific database and every encoding an attacker might try.

Injecting a script into a page viewed by another user, so it executes with that user's session and privileges. Reflected XSS returns the attacker's input directly in the response to a single request, usually via a crafted link. Stored XSS persists the malicious script in the application's data — a comment field, a profile bio — so every subsequent viewer executes it without clicking anything. DOM-based XSS never touches the server at all; it happens when client-side JavaScript takes a value from the URL or another client-controlled source and writes it into the page unsafely. The fix common to all three is contextual output encoding: escape for HTML, for a URL, or for a JavaScript string context specifically, because escaping for the wrong context leaves the injection open.

Because it is both the most common finding across real audits and the hardest to catch mechanically. Injection and XSS have recognisable syntactic signatures a scanner can pattern-match; a broken access control flaw is often a request that is syntactically perfect and returns a 200 — the endpoint works exactly as designed, except the design forgot to check whether this specific caller should be allowed to touch this specific resource. That makes it largely invisible to SAST and DAST alike, and it survives code review because the happy path looks identical to the vulnerable one.

The vulnerability is one missing clause, and the request that exploits it looks completely ordinary.

GET /api/invoices/8841          <- returns invoice 8841 to whoever asks

// Vulnerable: fetches by id with no ownership check.
Invoice invoice = invoiceRepo.findById(invoiceId);
return invoice;

// Fixed: the query itself is scoped to the caller, so there is no
// code path that can return someone else's invoice.
Invoice invoice = invoiceRepo.findByIdAndCustomerId(invoiceId, currentUser.getCustomerId());
if (invoice == null) return notFound();

The fix matters in the second version's shape as much as its content: scoping the lookup at the query level means the only invoice this code can ever return belongs to the caller, whereas fetching first and checking ownership afterwards in a separate if is exactly as reliable as every future developer remembering to write that check on every new endpoint.

A vulnerability where an attacker gets the server itself to make a request to a destination the attacker chooses, typically by supplying a URL that the server then fetches — an image-import feature, a webhook validator, a PDF generator that loads a remote resource. Because the request originates from the server, it can reach internal-only endpoints and cloud metadata services that are unreachable from the public internet, turning what looks like an image-fetching bug into a path to internal infrastructure. It earned its own OWASP category as cloud deployments made the internal-metadata-endpoint attack devastating and common enough to be a distinct, high-impact pattern rather than a variant of something else.

Constructing an object from untrusted data can, in languages and libraries where deserialisation can trigger arbitrary code as a side effect, hand an attacker code execution rather than merely a malformed object. The safe default is to treat deserialisation of untrusted input as inherently dangerous: prefer data formats with no executable semantics, such as JSON with a strict schema, over formats that support arbitrary object graphs and constructor side effects, and where a rich format is unavoidable, validate against an allow-list of expected types rather than deserialising whatever the payload claims to be.

It covers an unusually wide range of causes that share one symptom: a default, an unremoved feature, or an unset flag left in a state nobody deliberately chose.

Category                What it looks like
-----------------------------------------------------------------
Default credentials     Admin console still on admin/admin
Verbose errors           Stack trace with file paths shown to the user
Directory listing        /uploads/ returns a browsable file index
Unnecessary features     Debug endpoint left enabled in production
Missing headers          No Content-Security-Policy, no X-Frame-Options
Overly permissive CORS   Access-Control-Allow-Origin: *  on an
                         authenticated endpoint

None of these is exotic, and none requires the attacker to find a novel flaw — every one of them is a documented default that someone simply never changed. That is precisely why it is the second most impactful category on the current list despite being, individually, the least interesting: it is nearly always present somewhere in a large system, and it costs an attacker almost nothing to find.

A dependency is vulnerable when a known flaw exists in a version you're running, whether or not you've noticed. Writing everything yourself does not remove this risk, it moves it: your own code becomes the thing with unknown flaws instead of known ones, and you lose the benefit of a wider community finding and disclosing issues. The realistic answer is not zero dependencies but managed ones — an inventory of what you depend on, automated checks against vulnerability databases, and a process for updating promptly when a fix ships, which is a discipline problem more than a technology one.

The sentence hides which context the sanitisation was written for, and sanitisation that is correct for one context is often wrong for another. Input sanitised to be safe as HTML is not automatically safe as a SQL parameter, a shell argument, or a URL component, because each context has different characters that matter and different escaping rules. A single sanitisation function applied everywhere produces the appearance of safety while leaving every context except the one it was designed for exposed, which is why the safer framing is encoding output correctly for the specific context it will be used in, rather than sanitising input once and trusting it everywhere downstream.

A session stores state on the server — a session id in a cookie references a record the server looks up on every request — so revoking access means deleting that record, and the server holds the state. A token, typically a JWT, carries its own claims and is validated by signature rather than by a server-side lookup, so the server can be stateless, but revoking a single token before its expiry is genuinely harder, because there is no central record to delete. The trade is between revocation ease and scalability, and most real systems land on short-lived tokens plus a refresh mechanism specifically to bound how long a compromised token or a token that should be revoked but wasn't can be used.

A user wants to let one application access their data on another. The client redirects the user to the authorisation server, the user authenticates there and consents, and the authorisation server redirects back with a short-lived authorization code rather than a token directly. The client then exchanges that code, along with a client secret, for an access token via a server-to-server call the user's browser never sees.

sequenceDiagram
    participant U as User's browser
    participant C as Client app
    participant A as Authorisation server
    U->>C: Wants to connect account
    C->>A: Redirect to login and consent
    A-->>U: Authorization code
    U->>C: Code delivered via redirect
    C->>A: Exchange code plus secret for token
    A-->>C: Access token

The step worth noticing is that the code, not the token, ever touches the user's browser. That indirection exists because a browser redirect is visible in history and referrer headers, so putting the access token there directly would expose it; the code is single-use and short-lived, and only the confidential client, holding a secret the browser never sees, can redeem it.

OAuth 2.0 is an authorisation protocol — it governs what a client may do on a resource owner's behalf — and says nothing formally about who the user is. OpenID Connect adds an identity layer on top of the same flow, introducing the ID token, a signed JWT asserting who the user is, alongside the access token that governs what the client may do. Conflating the two is a common and consequential mistake: using an OAuth access token as a proof of identity, when it was only ever designed as a capability to call an API, skips validation that OIDC's ID token was specifically built to provide.

Every one of these looks like the token is being checked, and none of them actually verifies what the developer assumed.

// Wrong 1: trusting the algorithm the token itself claims to use.
// If the header says "alg: none" or a symmetric algorithm where an
// asymmetric one was expected, and the code honours that claim,
// an attacker can forge a token with no valid signature at all.
Jwts.parser().parse(token);   // uses whatever alg the header names

// Right: pin the expected algorithm explicitly, never read it from the token.
Jwts.parser().verifyWith(knownPublicKey)
    .build().parseSignedClaims(token);   // rejects anything not signed
                                          // with exactly this key

The second common failure is skipping the audience claim — verifying the signature is valid without checking the token was actually issued for this service, which lets a token legitimately issued for one API be replayed against another that trusts the same issuer. The third is not checking expiry server-side at all, relying on a client that could simply not enforce it, which turns a short-lived token into a long-lived one the moment an attacker controls the client behaviour. All three share the same root cause: validating that a token is well-formed and signed by someone is not the same as validating it was issued for this call, by the issuer you expect, and is still within its lifetime.

Role-based access control grants permissions to a role — admin, editor, viewer — and assigns users to roles, which is simple to reason about and audit but coarse: it struggles to express "an editor may edit their own posts but not someone else's" without inventing a role per condition. Attribute-based access control evaluates a policy against attributes of the user, the resource and the context at request time — department, resource owner, time of day, sensitivity label — which expresses fine-grained rules naturally but is harder to audit exhaustively, because the effective permission set is computed rather than listed. Most real systems use roles for coarse structure and layer attribute checks, especially resource ownership, on top for the fine-grained decisions roles cannot express.

Because each factor category defends against a different failure of the others, and MFA's actual value is in combining independent factor types — something you know, something you have, something you are — not in stacking more of the same type. A password plus a security question is two things you know, and both are defeated by the same phishing page; a password plus a hardware key is a knowledge factor plus a possession factor, and a phishing page that captures the password still doesn't get the physical key. The design question worth asking is which specific factor combination resists the specific attack you're worried about, not simply how many factors are in play.

An access token is deliberately short-lived and used on every API call; a refresh token is longer-lived and used only to obtain new access tokens, so it is presented far less often and typically stored more durably. That asymmetry makes it more valuable to an attacker: stealing an access token buys a short window of impersonation, while stealing a refresh token buys the ability to mint fresh access tokens indefinitely until the refresh token itself is revoked or expires. The mitigation set treats them accordingly — refresh tokens are stored in the most protected location available (an httpOnly cookie or secure storage, never accessible to JavaScript), rotated on each use so a stolen one becomes useless the moment the legitimate client uses it again, and revocable server-side even though the tokens themselves are otherwise stateless.

The endpoint is authenticated correctly. The authorisation check is simply absent.

DELETE /api/documents/4471

Server verifies: is the caller logged in?           yes
Server does NOT verify: does the caller own 4471?    (never asked)

Any authenticated user can delete any document by guessing or
enumerating ids. Nothing in the request looks malformed.

// Missing the ownership check entirely
documentRepo.deleteById(documentId);

// Fixed
Document doc = documentRepo.findById(documentId);
if (doc == null || !doc.getOwnerId().equals(currentUser.getId())) {
    return forbidden();
}
documentRepo.delete(doc);

The reason this specific bug is worth memorising rather than filing under "remember to check ownership" is that it is invisible to every purely mechanical detection method: the request is well-formed, the response code is exactly what a legitimate request would get, and no scanner signature matches "logically missing check." It is found by asking, for every endpoint that touches a specific resource, "what stops a different authenticated user from supplying this same id" — a question a checklist prompts but no tool asks automatically.

Encryption is reversible with a key: you can decrypt what you encrypted, and it exists to keep data confidential from anyone without that key. Hashing is one-way by design: you cannot recover the input from a hash, and it exists to verify integrity or to store something like a password without ever holding the original. Encoding — Base64 is the common example — has no security purpose at all; it is a reversible transformation for representing data in a different format, and confusing it with encryption is a real and recurring mistake, because Base64-encoded data looks unreadable to a casual glance while being trivially decoded by anyone who tries.

Because an attacker who steals the hash database can precompute hashes for a huge dictionary of common passwords once and compare against every stolen hash instantly — a rainbow table attack — and identical passwords across different users produce identical hashes, revealing who shares a password with whom. Salting adds a unique random value per user before hashing, so precomputation no longer transfers across users and identical passwords no longer look identical. A password-specific hash function such as bcrypt or Argon2 goes further, deliberately making each computation slow and memory-intensive, so that even with salts, brute-forcing a single password is expensive per guess rather than the sub-microsecond cost of a general-purpose hash function like SHA-256.

The two solve different problems, and most real systems that look like they use "encryption" are actually using both together.

Symmetric (e.g. AES)                Asymmetric (e.g. RSA, ECC)
------------------------------      ------------------------------------
One key, shared by both parties     A key pair: public key encrypts,
                                     private key decrypts (or the reverse
                                     for signing)
Fast, suited to bulk data           Slow, suited to small payloads
Problem: how do both parties get    Problem solved: no shared secret
the same key without it leaking     needs to travel anywhere in advance

TLS is the everyday example of combining them: the asymmetric handshake, using the server's public/private key pair, establishes a shared symmetric key between client and server without that key ever travelling over the network in the clear, and then all the actual bulk data for the rest of the connection is encrypted with the fast symmetric cipher. Neither algorithm alone solves the whole problem — asymmetric solves key exchange, symmetric solves bulk throughput — which is why "TLS uses RSA" and "TLS uses AES" are both true and both incomplete on their own.

A signature, produced by encrypting a hash of the message with the signer's private key, proves that whoever holds that private key produced this exact signature over this exact content — verifiable by anyone with the corresponding public key, because if a single byte of the message changes, the hash changes and the signature no longer verifies. It proves authenticity and integrity of the message relative to that key. It does not, on its own, prove the key belongs to the person or organisation you think it does — that binding is what a certificate and a certificate authority exist to establish — and it says nothing about confidentiality, since a signed message is not thereby encrypted.

Because TLS provides integrity as well as confidentiality, and integrity matters even for public, non-sensitive content: without it, any network intermediary — a compromised router, a hostile Wi-Fi access point — can modify the response in transit, injecting a script into an otherwise harmless page or altering a downloaded file. The confidentiality argument gets the attention, but the tampering-prevention argument applies even to content with no secrets in it at all, which is the actual reason plain HTTP is now treated as unacceptable for essentially all traffic rather than only for logins and payments.

In transit protects data while it moves across a network, defending against an intermediary reading or altering traffic; at rest protects data while it is stored, defending against someone who gains access to the storage medium itself — a stolen disk, a misconfigured backup, an insider with filesystem access but no network position. Neither substitutes for the other: data can be perfectly encrypted crossing the network and sit as plaintext on disk at the other end, or vice versa, and a full data-protection story requires naming both explicitly rather than assuming "we use HTTPS" answers a question about what happens to the data once it lands.

Hardcoding which certificate or public key a client should trust for a given server, rather than trusting any certificate signed by any certificate authority the operating system trusts. It defends specifically against a compromised or coerced certificate authority issuing a fraudulent certificate for your domain, which the normal trust chain would otherwise accept. The cost is operational fragility: when you legitimately rotate your certificate, every client with the old one pinned breaks until it's updated, which is why pinning is used selectively — mobile apps with controlled release cycles, high-value API clients — rather than as a universal default.

Because encryption without a sound key management story just relocates the point of failure rather than removing it: if the encryption key sits in the same place as the encrypted data, or in a config file checked into the same repository, an attacker who reaches one reaches both, and the encryption bought nothing. Real key management separates keys from the data they protect, rotates them on a schedule and after any suspected exposure, and restricts who and what can request a key to decrypt rather than who can read the ciphertext. A system that answers "yes, everything's encrypted" but cannot answer "where do the keys live and who can retrieve them" has described a feature, not a security posture.

Spoofing asks whether an actor can convincingly claim to be someone or something they are not. Tampering asks whether data can be modified without detection, in transit or at rest. Repudiation asks whether an actor can plausibly deny having performed an action the system needs to be able to attribute. Information disclosure asks whether data reaches someone who should not see it. Denial of service asks whether the system's availability can be degraded or removed. Elevation of privilege asks whether an actor can gain capability beyond what they were granted. Each is a question applied to a specific component or, more usefully, a specific boundary a request crosses — not a property of the system in the abstract.

An attack tree starts from a specific attacker goal at the root — "exfiltrate customer payment data" — and branches downward into the concrete ways that goal could be achieved, each branch further decomposed until it reaches a specific, checkable step. STRIDE is exhaustive by category across a boundary but goal-agnostic; an attack tree is goal-directed and can go arbitrarily deep on the paths that matter for one specific outcome but says nothing about outcomes nobody thought to root a tree at. They are complementary rather than competing: STRIDE surfaces the categories of threat systematically, and an attack tree takes the highest-value ones and works out the actual path an attacker would walk.

The interesting part of an attack tree is rarely the leaves — it's which branch is realistically cheapest for an attacker, because that's the one worth defending first.

flowchart TD
    G[Goal: read another user's private messages] --> A[Steal a valid session token]
    G --> B[Exploit missing authorisation check<br/>on message endpoint]
    G --> C[Compromise the database directly]
    A --> A1[Phishing]
    A --> A2[XSS on a page that reads the session]
    B --> B1[Change message id in the request]
    C --> C1[Credential leaked in a repo]

Branch B, exploiting a missing authorisation check by simply changing an id, requires no social engineering, no malware and no privileged access — it is the cheapest path by a wide margin if that check is actually missing. A threat model that spends its energy hardening against branch A's phishing while B sits open has protected against the expensive attack and left the free one available, which is precisely the prioritisation mistake attack trees are built to prevent: cost to the attacker, not novelty to the defender, decides what to fix first.

A diagram marking every point where data crosses from one trust level to another — client to server, service to service, application to database — drawn before enumerating any specific threats. Its value is that STRIDE or an attack tree applied without first fixing the boundaries tends to drift into vague, whole-system statements, whereas a boundary diagram forces the threat model to ask "what happens right here, at this specific crossing" for every crossing that exists, which is both more tractable and catches boundaries that get silently assumed away, such as an "internal" network that later turns out to be reachable from a partner integration nobody flagged as external.

Because the cost of fixing a design flaw grows sharply the further it travels through the lifecycle: a boundary drawn wrong in a design review is a diagram edit; the same flaw found in code review is a rewrite of a component; found in a penetration test before launch, it's a scramble under deadline pressure; found in production by an attacker, it's an incident with a blast radius that already happened. Threat modeling done at design time is cheap specifically because nothing has been built yet to unwind, which is the actual argument for doing it early rather than a general preference for planning.

Designing as though an attacker has already gained a foothold somewhere in the system, rather than designing purely to prevent the foothold in the first place. It changes concrete decisions: instead of one perimeter firewall being the entire defence, every internal service also authenticates its callers; instead of a flat internal network, segments limit how far a compromised host can reach; instead of broad standing credentials, short-lived, narrowly scoped ones limit what a stolen credential is worth. The mindset does not abandon perimeter defence, it stops treating the perimeter as sufficient, on the reasoning that a sufficiently motivated or lucky attacker eventually gets past any single layer, and the system needs to survive that.

Scope omitted silently is indistinguishable, to everyone reading the document later, from a threat that was considered and judged low-risk — and that ambiguity is exactly where gaps hide.

Threat model for: Order service <-> Payments service boundary

In scope:
  - Spoofing, tampering, DoS between these two services
  - Credential scope held by the order service

Explicitly out of scope, and why:
  - Payments service's internal fraud-detection logic
    (owned and modelled separately by the payments team)
  - Physical security of the data centre
    (covered by a separate compliance control, not this review)

Without the second section, a reader six months later cannot tell whether fraud detection was considered and excluded deliberately or simply never occurred to anyone in the room, and that distinction matters enormously when deciding whether a gap found later represents a process failure or an accepted, documented trade-off.

Preparation, detection and analysis, containment, eradication, recovery, and lessons learned. Naming them precisely is not bureaucratic box-ticking: an incident under real pressure produces a strong urge to jump straight to eradication — delete the malware, patch the hole — before containment and analysis are done, and doing so both destroys evidence needed to understand the full scope and risks missing a second foothold the attacker planted as a fallback. The phases exist to slow down the instinct to act immediately long enough to act correctly.

Because removing the visible artefact of a compromise before understanding its full scope can destroy the evidence needed to find everything else the attacker did, and can also tip off a sophisticated attacker that they've been detected, triggering a faster, more destructive next move before you're ready to respond to it. Containment — isolating the affected system, revoking the compromised credential, blocking the identified command-and-control address — stops the bleeding without necessarily alerting the attacker or losing the forensic trail, buying time to establish the full extent of the compromise before committing to a cleanup that assumes you already know it.

The difference is almost never volume. It's whether the specific fields an investigator will actually need are present.

Unhelpful:
  2026-08-10 14:02:11 ERROR Login failed

Helpful:
  2026-08-10 14:02:11 WARN auth.login.failed
    user_id=8841 source_ip=203.0.113.44 attempt_number=6
    reason=invalid_password session_id=none
    request_id=b7e2-9a41

The unhelpful line tells you a failure happened and nothing else — not who, not from where, not whether this was attempt one or attempt sixty. The helpful line lets an investigator immediately answer the questions that actually drive a response: is this one user having trouble, or one IP address hitting many accounts; is this the sixth attempt in a pattern that should have triggered a lockout already; and the request_id lets this line be correlated with every other log line touching the same request across every service it passed through. Structured, correlated fields are what make a log searchable during an incident rather than merely present in the file.

An intrusion detection system inspects traffic or host activity in real time looking for a known-bad signature or an anomalous pattern, and it is a detection mechanism, not a repository. A security information and event management system ingests logs and alerts from many sources — IDS alerts among them, but also application logs, authentication logs, cloud audit trails — and correlates across all of them, because a single suspicious login is noise but the same login pattern followed by an unusual data export three minutes later is a story. The IDS answers "is this one thing suspicious"; the SIEM answers "what is the pattern across everything," and an organisation typically needs both, feeding one into the other.

Because the damage an attacker does is roughly proportional to the time they have undetected access, and a fast response to a compromise detected three weeks late still means three weeks of unrestricted access already happened. Detection speed is bounded by what you're actually watching and how well the signal is separated from noise — an environment generating ten thousand low-quality alerts a day trains its own responders to ignore alerts, which is a slower detection time than having no alerting at all in terms of practical outcome, even though it looks more instrumented on paper.

The branch point that matters is rarely the moment of compromise — it's the gap before anyone notices, because that gap is where the actual decision about severity gets made too late.

sequenceDiagram
    participant Attacker
    participant System
    participant SIEM
    participant Responder
    Attacker->>System: Initial compromise
    Note over System,SIEM: Undetected for days or weeks
    System->>SIEM: Anomalous pattern logged
    SIEM->>Responder: Alert fires
    Responder->>System: Contain, then investigate scope
    Responder->>System: Eradicate and recover

The gap between the first line and the alert firing is where nearly all of the actual damage occurs, and it's the phase least visible in a tabletop exercise, because exercises tend to start from "the alert has fired," skipping past the much larger question of whether the detection would have fired at all against this specific attack pattern.

A predefined, specific set of steps for responding to a known category of incident — a credential leak, a ransomware indicator, a DDoS pattern — written before the incident, not improvised during it. Without one, the first real decisions during an incident are made under the worst possible conditions for good judgement: high stress, incomplete information, and often the middle of the night, and the same organisation that would calmly follow a sound plan on a whiteboard makes visibly worse calls live. A runbook doesn't remove judgement from the response, it removes the need to invent the first ten minutes of structure while the clock is already running.

It is not about avoiding accountability, it's about not suppressing the information the review needs to be useful. If naming that an engineer disabled an alert threshold under deadline pressure results in that engineer being punished, the next review's participants learn to omit the details that would let the organisation actually fix the underlying condition, and the review degrades into a sanitised narrative that repeats the same failure differently next time. The blameless framing focuses the review on the system and process conditions that made the failure likely — an alert threshold that was too easy to disable, no second reviewer required for that specific change — rather than on which individual made the visible mistake.

Cloud providers secure the infrastructure — physical data centres, the hypervisor, the network fabric below the customer's control — while the customer is responsible for what they configure on top of it: identity permissions, network rules, data exposure settings, patching within their own instances. Most real cloud security incidents happen firmly on the customer's side of that line — a storage bucket left publicly readable, an overly permissive identity role, a security group open to the entire internet — not because the provider's infrastructure failed, but because the model shifts a large amount of genuinely new configuration responsibility onto the customer and that responsibility is easy to underestimate.

The default that made this common was rarely malicious — it was a bucket set to public for a demo or a one-off file share, and then never reverted.

# Vulnerable: any authenticated AWS user, or with certain settings, anyone,
# can read every object in the bucket.
{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::company-backups/*"
}

# Fixed: scoped to a specific role that needs it, nothing else.
{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::123456789012:role/backup-reader"},
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::company-backups/*"
}

The pattern behind nearly every one of these incidents is the same: a permission is widened temporarily to solve an immediate problem, and nothing in the process forces it to be narrowed again once the problem is solved. The durable fix is less about the specific policy syntax than about a scanning process that continuously checks for exactly this shape — public access on a resource that should never have it — because relying on someone remembering to revert a temporary change is the same failure mode as relying on a developer remembering a secure-coding rule.

Cloud providers expose an internal-only HTTP endpoint on every instance that serves that instance's own credentials and configuration, reachable only from the instance itself under the assumption that nothing outside the instance's own code would ever request it. Server-side request forgery breaks that assumption: if an attacker can get the server to make an arbitrary outbound request, pointing it at the metadata endpoint's address hands them the instance's own cloud credentials, often with far more privilege than the original vulnerable feature ever needed. It's a specific, high-impact example of why SSRF earned its own OWASP category — the target reachable through it is not just internal, it's the credentials to everything else the instance can do.

A security group is a stateful, instance-level firewall rule governing what traffic may reach a resource, and opening a port to 0.0.0.0/0 — any address on the internet — to unblock a debugging session or a one-off integration test is a common shortcut that, left in place, exposes the service to every automated scanner on the internet indefinitely. The specific damage compounds because these rules are rarely audited on a schedule; they're set once during a task and then simply persist, invisible in day-to-day operation, until either a security review finds them or an attacker does.

Because it makes infrastructure changes reviewable, versioned and auditable in the same way application code already is, rather than a click in a console that leaves no diff and no reviewer. A security group opened by hand in a web console leaves no record of who did it or why beyond a provider audit log most teams never check; the same change expressed as a pull request against a Terraform file gets a reviewer's eyes on it before it takes effect, and a permanent record of it afterwards. The security value is specifically in forcing the same review discipline onto infrastructure changes that code changes already get, closing the gap where a console click bypasses every process built around code review.

Centralised, access-controlled, auditable storage for credentials, with the ability to rotate a secret without redeploying every service that uses it and a record of exactly which service retrieved which secret and when. An environment variable baked into a config file or a deployment manifest is durable in exactly the wrong sense: it sits in version history, in build artefacts and in deployment logs indefinitely, and rotating it means finding and updating every place it was copied to. A secrets manager makes retrieval an explicit, logged API call at runtime rather than a value that was ever written down anywhere durable, which is the actual difference — not that the string itself is somehow harder to guess.

The old model assumed everything inside the perimeter could trust everything else inside it. Cloud environments break that assumption structurally, not just as a matter of discipline.

Traditional assumption:
  Outside perimeter = untrusted    Inside perimeter = trusted

Cloud reality:
  - Services scale up and down; "inside" is not a fixed set of machines
  - Third-party SaaS integrations sit logically "inside" your trust
    boundary while running on infrastructure you don't control
  - A compromised container can often reach any other service on the
    same flat internal network with no further check

Zero-trust architecture is the response: no request is trusted by virtue of its network origin alone, so every service authenticates and authorises every caller — including other internal services — the same way it would treat a request arriving from the public internet. This isn't a rejection of network controls, it's an acknowledgement that in a cloud environment "inside the perimeter" no longer reliably means "safe," so the check has to move to the request itself rather than staying at the network boundary.

Not whether you produce the specific threats they had in mind — most interviewers accept several different, defensible threat models for the same system. What they're testing is your process: whether you identify the trust boundaries before naming threats, whether you work through categories systematically rather than free-associating a few dramatic-sounding attacks, and whether you can say concretely what mitigates each threat you name rather than stopping at identifying it. A candidate who methodically works one boundary at a time and names a mitigation for each threat reads as stronger than one who names ten scattered threats with no structure, even if the second list happens to include a more exotic finding.

Ground every answer in the specific system in front of you rather than a general list. "I'd try SQL injection" is a memorised line; "this login form takes a username, and if it's concatenated into a query rather than parameterised, I'd try closing the string with a quote to see how the error response changes" demonstrates you understand the mechanism, not just the vocabulary, and it naturally leads into what evidence would confirm or rule out the guess — which is closer to what a real assessment looks like than a list of category names ever is.

"What is the actual impact if this is exploited, and who is the realistic attacker?" A weak answer stops at naming a vulnerability class — "this is vulnerable to injection" — as though naming it were the whole task. A strong answer continues into what an attacker who found it could actually do with it, how far that reaches, and whether the realistic threat actor has the position and motive to find and use it at all, because prioritisation in real security work is entirely about that continuation, not about the initial spotting.