L01 · The CIA Triad

Module 1: Security Foundations · ~20 min · Lesson 1 of 71

🎯 What you'll learn

• The three goals every security control serves: confidentiality, integrity, and availability
• How to tell which of the three failed in a real incident
• Two extra properties that matter a lot in finance: authenticity and non-repudiation

🔥 Why this matters

Picture three bad mornings. On the first, customer records turn up on a hacker forum. On the second, a policy's beneficiary has been quietly changed to a stranger's name. On the third, your API returns 503 to every caller for four hours. All three are security incidents, but each one breaks something different, and each one needs a different fix. The CIA triad is the vocabulary for telling them apart.

1. The three goals

Every piece of data you protect has to meet three goals at once:

• Confidentiality means only the people and systems who should read the data can read it.
• Integrity means the data is accurate and hasn't been changed, by accident or on purpose, except by someone who is allowed to change it.
• Availability means the data and systems are there, and fast enough, when they're needed.

                    CONFIDENTIALITY
                "only the right people
                     can read it"
                          /\
                         /  \
                        /    \
                       / YOUR \
                      /  DATA  \
                     /__________\
          INTEGRITY                AVAILABILITY
     "it's correct and         "it's there when
      unchanged unless          it's needed"
      allowed"

An analogy: think of a bank's safe deposit box. Confidentiality is that only you have the key. Integrity is that what you put in is still exactly what's there. Availability is that the bank is open when you need to get it. In technical terms, confidentiality comes from access control and encryption, integrity from hashes, signatures, validation, and change control, and availability from redundancy, capacity, and backups.

2. What each failure looks like in real life

Confidentiality failure: Capital One, 2019. An attacker abused a misconfigured web application firewall to get cloud credentials and copied data on about 100 million people out of S3 storage. Nothing was changed or deleted. The data was simply read by someone who shouldn't have read it. (You'll study this one in detail in L47.)

Integrity failure: Bangladesh Bank, 2016. Attackers got into the bank's SWIFT payment system and sent fraudulent payment instructions to the New York Fed. They tried to move nearly $1 billion; most was blocked, but $81 million got away. Their malware even tampered with the bank's printed transaction confirmations to hide what was happening. The core problem: messages and records were changed or forged.

Availability failure: CrowdStrike, July 2024. A faulty update to a security product crashed about 8.5 million Windows machines, grounding flights and taking banks and hospitals offline. Nobody attacked anything, which teaches an important point: availability failures don't need an attacker. Bad deploys, expired certificates, and full disks count too. The classic malicious version is a DDoS (distributed denial-of-service) attack, where thousands of machines flood a service with traffic until it falls over.

Typical threats and controls for each goal:

One incident can hit more than one goal. Modern ransomware typically encrypts your systems (availability) and steals a copy first to threaten a leak (confidentiality).

3. Beyond the triad: authenticity and non-repudiation

Two more properties come up all the time in financial systems:

• Authenticity means the data or request really came from who it claims to come from. Integrity asks "was this changed?"; authenticity asks "who actually sent it?"
• Non-repudiation means someone can't later deny an action they took, because there's trustworthy evidence. It usually comes from digital signatures plus tamper-resistant logs.

Example: a customer calls and says, "I never authorized that $40,000 withdrawal." Non-repudiation is what lets the company answer, "This request was signed in from your enrolled device after an MFA challenge at 14:02, and here is the tamper-evident log." Without that evidence, it's their word against yours.

The goals pull against each other

Security is a balancing act, because strengthening one goal can weaken another:

Good design means choosing the balance on purpose, per system. A payments ledger leans hard toward integrity. A public status page leans toward availability.

🧪 Worked example: diagnosing incidents from API logs

Here's where each goal gets protected along a typical request path in an API stack like the one in these examples:

 Client
   │  request over HTTPS
   │    TLS .................. [C] nobody can read it in transit
   │                           [I] nobody can alter it in transit
   ▼
 Kong gateway
   │    token check .......... [C] only authenticated callers pass
   │    rate limit ........... [A] one noisy client can't starve others
   │  request forwarded (mTLS)
   ▼
 policy-service
   │    authorization check .. [C] "may agent-77 see PL-100245?"
   │    input validation ..... [I] reject malformed or oversized data
   │    audit log ............ [NR] who did what, and when
   │  query
   ▼
 MongoDB (replica set)
        3 replicas ........... [A] survives losing a node
        encryption at rest ... [C] a stolen disk is unreadable
        backups .............. [A][I] restore after corruption

Now three (made-up) log lines from a bad day. Which goal failed in each?

09:14:02 GET   /v1/policies/PL-100245  caller=agent-77  status=200
         note: agent-77 is not assigned to PL-100245

Diagnosis: confidentiality. The request succeeded and the data went back, but this caller shouldn't have seen it. The gateway checked who the caller was but nobody checked whether they were allowed to see this record. Fix: an object-level authorization check in the service. (This bug has a name, IDOR, which is covered in L34.)

09:20:11 PATCH /v1/policies/PL-100245  caller=svc-batch  status=200
         field=beneficiary  old="J. Rivera"  new="K. Moss"  ticket=none

Diagnosis: integrity. Data was changed by an identity that shouldn't have been changing beneficiaries, with no approved change behind it. Fix: give the batch service only the permissions it needs (least privilege, L04), require approval for sensitive fields, and alert on beneficiary changes. Notice that this audit log line is the only reason anyone found the change.

09:31:40 GET   /v1/policies/*  status=503  count=12,400 in 60s
         source: 1 client id

Diagnosis: availability. One client is flooding the API and real users get errors. Fix: per-client rate limiting at the gateway, plus autoscaling with sensible limits.

🛠 Try it (optional, ~5 min)

Part A. Name the goal (or goals) that failed in each headline:

1. "Ransomware encrypts hospital systems; ambulances diverted, patient data posted online"
2. "Fraudsters alter bank details in a vendor's invoice email; company wires $2M to the wrong account"
3. "Misconfigured storage bucket exposes 3 million customer records"
4. "Cloud region outage takes banking apps offline for six hours"
5. "Trader edits audit logs to hide unauthorized trades"

Part B. Pick one service you work on. Write one sentence each: what would a confidentiality, an integrity, and an availability failure look like for that service? Which one would hurt the company most?

Answers to Part A, don't peek: 1 = availability + confidentiality · 2 = integrity (and authenticity: the email wasn't really from the vendor) · 3 = confidentiality · 4 = availability · 5 = integrity (and it destroys non-repudiation).

🧠 Key takeaways

• Every security control protects confidentiality, integrity, availability, or a mix of them.
• Confidentiality is about who can read, integrity about who can change, and availability about whether it works when needed.
• Availability failures don't need an attacker: outages and bad deploys count.
• In finance, authenticity ("who sent this?") and non-repudiation ("they can't deny it") matter as much as the triad.
• The goals trade off against each other, so choose the balance per system on purpose.

📖 Words to know

⏭ Next time

L02: threats, vulnerabilities, and risk. Why "we have a vulnerability" and "we have a risk" are not the same sentence, and how to read a CVE score.

The trap

Many engineers think "it's encrypted, so nobody can tamper with it." That's wrong. Encryption on its own guarantees confidentiality: nobody can read the data. It doesn't automatically guarantee integrity: depending on how it's encrypted, someone may still be able to change the data in a predictable way without ever knowing the key. (This is the same confusion as quiz question 1.)

An analogy: tinted car windows stop anyone seeing inside, but they don't stop someone keying the door. Technically, many encryption modes are malleable: a change to the ciphertext produces a matching, predictable change in the decrypted plaintext.

How it works: bit-flipping in AES-CTR

AES-CTR (counter mode) turns AES into a stream cipher. It generates a stream of random-looking bytes from the key, called the keystream, and XORs it with your message. XOR has a property attackers love: if you flip a bit in the ciphertext, exactly the same bit flips in the plaintext.

 1. ENCRYPT (sender has the key)
      plaintext   P A Y   b o b   $  5  0  0 . 0 0
                                     │ 0x35 ('5')
      keystream   ── XOR ────────────┤
                                     ▼
      ciphertext  37 00 4a ... ...  [c9] ...       ──▶ sent

 2. TAMPER (attacker has NO key)
      attacker knows the message layout, so position 9 is the
      first digit of the amount. XOR that byte with 0x0C:
      ciphertext  37 00 4a ... ...  [c9 ⊕ 0C] ...  ──▶ forwarded

 3. DECRYPT (receiver has the key)
      plaintext   P A Y   b o b   $  9  0  0 . 0 0
                                     │
            '5' (0x35) ⊕ 0x0C = '9' (0x39)  ✔ decrypts "fine"

The receiver decrypts without any error and pays $900 instead of $500. Confidentiality held the whole time, because the attacker never read the message, but integrity was destroyed. The same class of trick has been used against encrypted session cookies to change a stored role or user ID.

The fix: authenticated encryption (AEAD)

AEAD (authenticated encryption with associated data) encrypts the data and attaches a cryptographic authentication tag, a short checksum that only the key holder can produce. On decryption, the tag is checked first. If even one bit was changed, decryption fails instead of returning tampered data.

  without AEAD:  ciphertext ──tampered──▶ decrypt ──▶ "$900.00"  ✗ silently wrong
  with AEAD:     ciphertext+tag ──tampered──▶ decrypt ──▶ ERROR  ✔ tamper detected

Common AEAD choices are AES-GCM and ChaCha20-Poly1305. Where this shows up in the example stack:

• TLS 1.3 (HTTPS, and mTLS behind a gateway such as Kong) only allows AEAD cipher suites, so a modern TLS connection gives you confidentiality and integrity together.
• MongoDB client-side field-level encryption uses an AEAD algorithm (AEAD_AES_256_CBC_HMAC_SHA_512) for the same reason.
• When you encrypt something yourself (a token, a cookie, a field in a database), use a library's AEAD mode (for example AES/GCM/NoPadding in Java, or AESGCM in Python's cryptography package). Never use plain CTR or CBC without a MAC. Module 3 covers this in depth.

An attacker in the middle can break any goal

Being "in the middle" of a connection doesn't by itself tell you which goal was broken. Look at what the attacker did:

🛠 Try it: tamper with encrypted data without the key (~3 min, runs only on your machine)

mkdir -p /tmp/flipdemo && cd /tmp/flipdemo
printf 'PAY bob $500.00' > msg.txt
KEY=$(openssl rand -hex 32); IV=$(openssl rand -hex 16)

# Encrypt with AES-256-CTR (no integrity protection)
openssl enc -aes-256-ctr -K $KEY -iv $IV -in msg.txt -out msg.enc
xxd msg.enc                       # unreadable ciphertext

# "Attacker": flip bits in byte 9 without using the key
python3 -c "d=bytearray(open('msg.enc','rb').read()); d[9]^=0x0C; open('msg.enc','wb').write(d)"

# Receiver decrypts with the real key
openssl enc -d -aes-256-ctr -K $KEY -iv $IV -in msg.enc; echo
# → PAY bob $900.00

What to notice: the decryption succeeds without any error. That's the whole problem. (openssl enc doesn't support GCM, so to see AEAD reject a tampered message you'd use a library such as Python's cryptography, which is covered in L15.)

🧠 Extra takeaways

• Encryption ≠ integrity. Unauthenticated encryption can be tampered with predictably.
• Use AEAD (AES-GCM, ChaCha20-Poly1305) whenever you encrypt something yourself.
• When an attacker is in the middle, the goal that broke depends on what they did: read, change, block, or impersonate.

Not all data deserves the same protection

Say a team at an insurer owns three things: a public "find an advisor" page, the policy API, and the payments ledger. Protecting all three like the ledger wastes money and slows everyone down. Protecting all three like the advisor page invites disaster. Security teams solve this by rating each system's impact: how bad it would be if each CIA goal failed.

The best-known method is FIPS 199, a US government standard published by NIST in 2004. Federal agencies must use it. Private companies, including financial firms, usually run their own version of the same idea under names like data classification and criticality tiers. Once you know FIPS 199, you'll recognize every variant.

Three levels, asked three times

For each goal, ask: "If this failed, what's the worst realistic outcome?"

 LOW ........... limited harm      minor loss or inconvenience;
                                   the business still runs
 MODERATE ...... serious harm      significant financial loss,
                                   damage, or disruption
 HIGH .......... severe or         major financial loss, legal
                 catastrophic      action, harm to people; the
                                   business can't function

You write the result in a compact notation called a security category:

SC(policy-api) = { (confidentiality, HIGH),
                   (integrity,       HIGH),
                   (availability,    MODERATE) }

One special rule: confidentiality can be rated not applicable for information that's meant to be public. Only confidentiality gets that option; public data can still be tampered with or go offline.

The highest rating wins

To decide how much protection a whole system needs, take the highest of its three ratings. This is called the high-water mark. The overall rating then selects a control baseline, a standard set of required controls (in government, the Low, Moderate, or High baselines of NIST SP 800-53).

 policy-api        impact if this goal fails
   C  ███████████████  HIGH       customer PII exposed
   I  ███████████████  HIGH       beneficiary silently changed
   A  ██████████       MODERATE   agents wait an hour, no lasting harm
                       │
                       └──▶ overall = HIGH (highest wins)

The consequence: one high-impact component pulls the whole system up. If the public advisor directory shares a service and database with policy data, the directory inherits HIGH and all its cost. Split them, and only the part that needs heavy protection pays for it. (This is the same idea as reducing PCI DSS "scope" for card data, covered in L68.)

🧪 Worked example: rating three systems

Reasonable people will rate some cells differently. What matters is that the reasoning is written down and agreed on, because the ratings drive real decisions:

🛠 Try it (~5 min)

Rate a service you work on. For each goal, write one line: the worst realistic outcome, then LOW, MODERATE, or HIGH. Take the high-water mark. Then ask: is there a piece of this service that could be split off so it doesn't inherit the highest rating?

🧠 Extra takeaways

• Impact ratings decide how much protection each system gets, separately for C, I, and A.
• Three levels: limited, serious, and severe or catastrophic harm.
• The overall rating is the highest of the three (the high-water mark), so keep high-impact data contained in as few systems as possible.
• Company data classification schemes and criticality tiers are the same idea under other names.

"Highly available" means nothing without a number

Every team says its API must be "highly available." That sentence can't be tested, budgeted, or designed for. Engineers and security teams turn availability into numbers in two ways: how much downtime is acceptable in normal operation, and how fast you must recover, and how much data you may lose, after a disaster.

SLI, SLO, SLA

• An SLI (service level indicator) is what you measure. For example: the percentage of requests that return a non-5xx response in under 1 second.
• An SLO (service level objective) is your internal target for that measure. For example: 99.9% over a rolling 30 days.
• An SLA (service level agreement) is a promise to a customer, with consequences such as refunds or service credits if you miss it. Teams set their SLO stricter than the SLA so they get warned before they break a contract.

What the nines really allow

Each extra nine costs roughly ten times more effort. At 99.99%, a single slow manual rollback uses up the whole month. The allowed downtime is called the error budget: while you have budget left, you can ship risky changes; once it's spent, you slow down and fix reliability.

Dependencies multiply, redundancy divides

If a request must pass through several components in series, their availabilities multiply:

 client ─▶ Kong ─▶ policy-service ─▶ MongoDB
          99.9%       99.9%           99.9%

 overall = 0.999 × 0.999 × 0.999 = 99.7%
         ≈ 2.2 hours of downtime a month, not 43 minutes

Running components in parallel, where any one copy can serve, works the other way:

          ┌─▶ pod A  99% ─┐
 request ─┤               ├─▶ fails only if BOTH are down
          └─▶ pod B  99% ─┘
 overall = 1 − (0.01 × 0.01) = 99.99%

The caveat: that maths assumes the copies fail independently. Two pods in the same availability zone, running the same bad release, fail together. That's why redundancy spreads across zones, and why bad deploys get rolled out gradually.

RTO and RPO: recovering from a disaster

SLOs cover normal days. For the bad day (a region outage, ransomware, a corrupted database), two other numbers matter:

• RTO (recovery time objective): the longest the service may be down before it's restored.
• RPO (recovery point objective): the most data you may lose, measured in time. An RPO of 15 minutes means your last good copy may be at most 15 minutes old.

   last good          disaster           service
   copy                strikes           restored
     │◀───── RPO ─────▶│◀───── RTO ─────▶│
 ────●─────────────────✖─────────────────●──────▶ time
     data written here      users wait
     is lost                here

RPO decides how often you copy data: a nightly backup means up to 24 hours of lost writes, while continuous replication gets you seconds. RTO decides how you recover: restoring from backup takes hours, a warm standby takes minutes, and active-active setups take close to zero.

Why backups protect integrity, not just availability

A MongoDB replica set copies every write to the other nodes within milliseconds. That's great when a node dies, and terrible when a buggy batch job deletes half a collection, because the replicas faithfully copy the deletion too. Replication protects availability. Only a backup with point-in-time restore lets you go back to before the bad change, which protects integrity.

Ransomware gangs know this and try to delete or encrypt backups first. That's why modern guidance is the 3-2-1-1-0 rule: 3 copies of the data, on 2 different kinds of storage, 1 off-site, 1 immutable (it can't be changed or deleted, even by an admin), and 0 errors when you test a restore. A backup you've never restored is a hope, not a plan.

🧪 Worked example: the policy API and the payments ledger

writeConcern: "majority" is a real MongoDB setting worth knowing: with it, an acknowledged write survives the primary failing, because a majority of nodes already hold it.

🛠 Try it (~3 min)

Check the series maths yourself: python3 -c "print(0.999**3, (1-0.999**3)*43830, 'min/month')". Then find out, for one service you work on: what's its SLO? Its RTO and RPO? When was a restore last tested? If nobody knows, that's a finding.

🧠 Extra takeaways

• Availability only becomes real when it's a number: SLIs are measured, SLOs are targets, SLAs are promises.
• Components in series multiply their downtime; independent redundancy divides it.
• RTO is how long recovery may take; RPO is how much data you may lose.
• Replication isn't backup: replicas copy mistakes and deletions instantly.
• Keep at least one immutable backup and test restores.

When the CIA labels feel wrong

A laptop with full-disk encryption is stolen from a car. Was confidentiality breached? Probably not, because the thief can't read it. Was integrity or availability hurt? Not really, since you have backups. Yet it clearly is an incident. The CIA triad struggles to name what went wrong.

In 1998, security researcher Donn Parker proposed the Parkerian hexad: six properties instead of three, to describe cases like this.

Six properties, in three pairs

   ┌──────────────────┬──────────────────┬──────────────────┐
   │ CONFIDENTIALITY  │ INTEGRITY        │ AVAILABILITY     │
   │ who can read it  │ is it unchanged  │ can I get to it  │
   ├──────────────────┼──────────────────┼──────────────────┤
   │ POSSESSION       │ AUTHENTICITY     │ UTILITY          │
   │ who holds it,    │ did it really    │ is it still      │
   │ even unread      │ come from them   │ usable           │
   └──────────────────┴──────────────────┴──────────────────┘
      top row = the CIA triad · bottom row = Parker's additions

• Possession (or control): whether you still control the data, even if nobody has read it. The stolen encrypted laptop is a loss of possession without a loss of confidentiality.
• Authenticity: whether the data or message really comes from its claimed source. You met this in the main lesson.
• Utility: whether the data is still useful. It can be present, unchanged, and secret, and still worthless to you.

Utility: the one that bites engineers

The classic utility failure is losing the encryption key. Imagine all your S3 backups are encrypted with one AWS KMS key, and an attacker with admin access schedules that key for deletion. The backups are still there (available), unchanged (integrity), and unreadable by anyone (confidentiality), and completely useless. AWS forces a 7 to 30 day waiting period before a KMS key is actually deleted, for exactly this reason, and alerting on ScheduleKeyDeletion events is a common detection.

Other utility failures: data in a format no remaining system can read, or a backup of the database without the schema or the application version needed to load it.

🧪 Worked example: naming the right property

This matters beyond labels. Many US breach notification laws include an encryption safe harbor: if stolen data was properly encrypted and the key wasn't taken too, notification may not be required. That legal line is the difference between possession and confidentiality.

Should you use it?

The CIA triad is still the standard vocabulary in frameworks, certifications, and day-to-day security work. Use CIA by default. Keep the hexad as a thinking tool for edge cases, especially for asking "if we lost the keys, or lost control of a copy, what would happen?"

🛠 Try it (~3 min)

For one system you work on, answer: if the encryption key behind its data or backups disappeared tomorrow, could you still recover? Who can delete that key, and would anyone get an alert?

🧠 Extra takeaways

• The Parkerian hexad adds possession, authenticity, and utility to the CIA triad.
• Possession can be lost without confidentiality being lost (stolen but encrypted data).
• Utility can be lost while everything else holds, most often through a lost or deleted key.
• Use CIA day to day; use the hexad when an incident doesn't fit the three labels.

The basic idea is right: the sender computes a check value, and the receiver recomputes it and compares. Three details are different:

1. It's a keyed MAC, not a plain hash. Anyone can compute SHA-256, so an attacker who changes the message just recomputes the hash too. Only someone with the key can compute the tag. Even an encrypted plain hash fails: WEP Wi-Fi put a CRC-32 checksum inside RC4 encryption, and attackers flipped bits in the message and fixed up the checksum without the key.
2. In AES-GCM the tag is computed over the ciphertext (plus any associated data), not over the plaintext before encryption. This order is called encrypt-then-MAC.
3. The receiver checks the tag before decrypting. If it doesn't match, decryption fails and no plaintext is ever returned, so tampered data never reaches your code.

 SENDER                                   RECEIVER
 plaintext ─encrypt(key)─▶ ciphertext     ciphertext + tag + AAD
 ciphertext + AAD ─MAC(key)─▶ tag            │
        │                                    ├─ recompute tag(key)
        └── ciphertext + tag + AAD ─────────▶├─ match?  no ─▶ ERROR, stop
                                             └─ yes ─▶ decrypt ─▶ plaintext

AEAD is the name of the whole scheme (encryption plus authentication in one step); the tag is what travels with the message. Libraries do all of this in a single call, for example AESGCM(key).decrypt(nonce, data, aad) in Python raises InvalidTag if anything was changed.

No public key is involved. AEAD is symmetric: sender and receiver hold the same secret key. The receiver recomputes the tag over the ciphertext and associated data it received, using that shared key, and compares the result with the tag that arrived. If they match, the data is unchanged and was produced by someone who has the key. Libraries do the comparison in constant time so the timing doesn't leak how many bytes matched.

Where the shared key comes from (TLS): public keys are used once, during the handshake. The server proves its identity with its certificate and a signature, and both sides run an ECDHE key exchange to agree on fresh session keys. After that, every record is protected with AEAD using the shared keys.

 HANDSHAKE (asymmetric)                  DATA (symmetric)
 cert + signature ──▶ "it's really       each record:
                       the server"        AES-GCM(shared key)
 ECDHE key exchange ─▶ both sides now ──▶ encrypt + tag ──▶ verify tag
                       hold same key

MAC vs digital signature:

The last row links back to the main lesson: a MAC proves the message wasn't changed by an outsider, but it can't prove which of the key holders created it. For non-repudiation you need a signature.

Real MAC example: GitHub webhooks send an X-Hub-Signature-256 header, which is an HMAC-SHA256 of the body using a secret you share with GitHub. Your server recomputes it and compares. Despite the header's name, it's a MAC, not a signature. (L17 covers HMAC and signatures in depth.)