Frontend Labs
⋯

Part 1 — Foundations

Chapter 1 — What "security" actually means

In one sentence

Security is keeping a system doing what it's supposed to do, for the people it's supposed to serve, and nothing else — for anybody else.

The problem

"Make it secure" is not a requirement. Secure against whom? Doing what? At what cost? Without answering those, you buy expensive controls that stop nothing.

The three properties (the CIA triad)

Almost every security requirement is one of these three:

   +-------------------+---------------------------------------------+
   | CONFIDENTIALITY   | Only the right people can READ it.           |
   |                   | Broken by: data breach, eavesdropping,       |
   |                   |            a misconfigured S3 bucket         |
   +-------------------+---------------------------------------------+
   | INTEGRITY         | Only the right people can CHANGE it, and    |
   |                   | you can TELL if it changed.                  |
   |                   | Broken by: tampering, a corrupted update,    |
   |                   |            a modified bank transfer           |
   +-------------------+---------------------------------------------+
   | AVAILABILITY      | The right people can actually USE it.        |
   |                   | Broken by: DDoS, ransomware, a deleted        |
   |                   |            database, an expired certificate   |
   +-------------------+---------------------------------------------+

Two more that matter in practice:

  • Authenticity — the message really came from who it claims. (Often folded into integrity.)
  • Non-repudiation — the sender can't later deny sending it. This is what digital signatures give you and MACs do not (Chapter 21).

The trade-off nobody tells beginners

Security always costs something, and usually it costs availability or usability.

   Perfect confidentiality:  turn the server off. Nobody can read it.
   Perfect availability:     no authentication. Everybody gets in.

   Every real system sits somewhere between, deliberately.

Examples you'll recognise:

  • Requiring MFA reduces account takeover and locks out users who lose their phone.
  • Short session timeouts reduce stolen-session risk and annoy everyone.
  • Rate limiting stops brute force and breaks a legitimate bulk import.

A security engineer's actual job is choosing these trade-offs deliberately, not maximising one axis.

Defence in depth

No single control works. Assume each one fails and ask "what's next?"

   An attacker wants your customer database.

   Layer 1  network:      firewall blocks direct DB access from the internet
   Layer 2  application:  parameterised queries prevent SQL injection
   Layer 3  authn:        the app authenticates to the DB with a scoped account
   Layer 4  authz:        that account can read orders, not payment details
   Layer 5  data:         card numbers are encrypted at rest with a KMS key
   Layer 6  detection:    unusual query volume raises an alert
   Layer 7  response:     credentials rotate automatically on alert

   The attacker must beat ALL of them. You must not lose ALL of them.

This is why "we have a firewall" is not a security posture.

Real-world example: the 2017 credit-bureau breach

A single unpatched web framework vulnerability exposed ~147 million people's data. The failures were layered, and every layer is one you can control:

  1. A known vulnerability went unpatched for months (patching).
  2. Network segmentation was poor, so one web server reached many databases (segmentation).
  3. Data was not encrypted in a way that helped (data protection).
  4. An expired certificate on a monitoring device meant traffic inspection was blind for 19 months (availability of a control).
  5. Exfiltration ran undetected for 76 days (detection).

The lesson isn't "patch faster." It's that the breach required five independent failures — and they had five independent chances to stop it.

Practice (15 min, no code)

Pick a system you know (your company's app, your home network, your bank's website). In notes.md write:

  1. What would an attacker want from it? (Money? Data? Disruption? Reputation?)
  2. For each of C, I, A — what would "broken" look like specifically?
  3. Name three layers of defence that exist today.
  4. Which single failure would be worst, and what's the layer beneath it?

Keep this. You'll refine it in Chapter 52.

Common confusions

  • "Security is a feature you add." It's a property of the whole system. You can't bolt it on at the end any more than you can bolt on "fast".
  • "We're too small to be a target." Most attacks are automated and indiscriminate. Your server was port-scanned several times while you read this chapter.
  • "Compliance means secure." Compliance is a floor, often an outdated one. Plenty of breached companies were compliant.

Check yourself

  1. Name the three properties of the CIA triad, and one way each breaks.
  2. What does security usually cost, and give an example.
  3. What does "defence in depth" mean?
  4. Why is "we have a firewall" an insufficient answer?

(Answers: Appendix F.)

Further reading

  • Book: Security Engineering (3rd ed.) — Ross Anderson. Free online. The definitive book on the field, and unusually readable. Chapter 1 is a perfect companion to this chapter.
  • Article: NIST's definition of the CIA triad in FIPS 199 — short and authoritative.
  • Video: Professor Messer's Security+ series, "CIA Triad" — free, ~8 min.

Generated from real-life-guide.md · 8 Oct 2026 16:36