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.