Case Study 1: Encrypting the Cardholder Data Environment at Meridian

"Encrypting the data was the easy part. Deciding who could hold the key — that took three meetings and a lawyer." — Sam Whitfield, Security Engineer, Meridian Regional Bank (constructed)

Executive Summary

With a Payment Card Industry Data Security Standard (PCI-DSS) assessment approaching, Meridian Regional Bank had to answer a deceptively simple question: how is stored cardholder data actually protected, and who can decrypt it? This case study follows security engineer Sam Whitfield and GRC analyst Elena Vasquez as they design the encryption that protects the bank's cardholder data environment (CDE) at rest — and discover, as every team eventually does, that the hard problem is not the cipher but the key management around it. You will see the chapter's concepts become decisions: AES-256 versus alternatives, authenticated mode versus not, where the key lives, who can decrypt, and how the whole design holds up against the §4.7 failure catalog. This is a design and governance exercise — the build-heavy companion to the analysis-heavy Case Study 2. The scenario, configurations, and all values are constructed for teaching (Tier 3), and every value shown (keys, hashes, identifiers) is a documentation placeholder, not a real secret.

Skills applied: choosing symmetric algorithms/modes for data at rest; distinguishing what encryption does and does not protect (§4.1); designing key storage separate from data; reasoning about key access as blast radius; tokenization as an alternative to encryption; writing an encryption standard an auditor can test; mapping a control to PCI-DSS data-protection obligations.

Background

Meridian processes card payments for its 2.5 million customers and therefore stores, in places, primary account numbers (PANs) — the long card numbers — along with related cardholder data. Under PCI-DSS, the systems that store, process, or transmit this data form the cardholder data environment (CDE), and the standard imposes specific obligations: render stored PANs unreadable (Requirement 3, broadly), and protect cardholder data in transit over open networks (Requirement 4). (We map Meridian's full compliance picture, including the exact requirement structure, in Chapter 28; here we focus on the cryptographic design that those requirements demand.)

Before this initiative, Meridian's CDE was a patchwork. Some systems encrypted PANs; some stored them in plaintext in older tables "temporarily" for a reconciliation job that had run for six years; one analytics export wrote PANs to a CSV on a file share that, the team would learn, was backed up to a second location nobody had inventoried. CISO Dana Okafor framed the work in one sentence at the kickoff: "Assume the network fails and an attacker reaches these systems — Chapter 1's whole premise. When they exfiltrate the CDE, what do they get?" The goal was that the answer be "ciphertext they cannot use," everywhere, with no exceptions hiding in a forgotten table.

Sam and Elena split the work the way the discipline splits: Sam owns the cryptographic design (algorithms, modes, where keys live), and Elena owns the standard and its mapping to PCI-DSS, so the bank can prove the control to an assessor. Neither can succeed alone — a perfect cipher with no documented standard fails the audit, and a beautiful policy that engineers cannot implement protects nothing.

The Analysis

Phase 1 — What are we actually protecting, and from whom?

Sam's first move is the one §4.1 insists on: be precise about what encryption does and does not do here, because over-trusting it produces a false sense of security that an assessor (and an attacker) will puncture. He writes the threat model on a whiteboard:

   WHAT ENCRYPTING THE CDE AT REST PROTECTS AGAINST:
     - attacker exfiltrates the database files / backups        -> gets ciphertext  ✓
     - stolen/lost backup tape or disk                          -> gets ciphertext  ✓
     - attacker reads the raw storage from a compromised host   -> gets ciphertext  ✓

   WHAT IT DOES *NOT* PROTECT AGAINST (do not pretend otherwise):
     - attacker compromises an ACCOUNT authorized to decrypt    -> app decrypts for them ✗
     - data IN USE: PAN sits in app memory as plaintext         -> memory scraping ✗
     - someone with legitimate key access misuses it (insider)  -> ✗
     - SQL injection that asks the app to return decrypted data -> ✗  (see Ch.13)

🔗 Connection: This is the §4.1 lesson made concrete. Encryption at rest defends against theft of the ciphertext, not against theft of the access that decrypts it. That single distinction shapes every later decision: it is why key management and access control matter more than algorithm choice, and why Sam's design will spend most of its effort on the key, not the cipher. It also tells Elena which other controls the encryption standard must reference — authentication (Chapter 16), application security (Chapter 13) — so the bank does not claim encryption solves problems it cannot.

This framing immediately reshapes the project. "Encrypt the CDE" is not one control; it is encryption plus tight control over who and what can decrypt. Sam annotates the model: the real security target is to make the decryption capability as scarce and as guarded as the data is valuable.

Phase 2 — Choosing the algorithm and mode (the easy part, done right)

With the threat model clear, the cipher choice is, as Sam predicted, the easy part — if you follow the chapter's rules. He documents the decisions and, crucially, the reasons, so a future engineer (or auditor) understands not just what was chosen but why alternatives were rejected:

Sam also resolves a breadth-versus-depth question that real teams face. There are two layers at which the CDE can be encrypted:

• Transparent encryption (full-disk or transparent database encryption, TDE) encrypts everything on the storage automatically. It is broad and easy and protects against stolen disks/backups, but the database itself sees plaintext, so it does nothing against an attacker who reaches the running database through an authorized path.
• Field-level (application-layer) encryption encrypts the most sensitive elements — the full PAN — inside the application before they ever reach the database, so even a database compromise yields ciphertext for those fields.

Sam's design uses both, defense in depth (Theme 4): TDE for breadth across the CDE storage, and field-level AES-256-GCM for the PAN specifically, so the crown-jewel field is protected even if the broader layer is bypassed. A short, hand-traced illustration of the shape of the field-level call (schematic — the real code calls the KMS/library, and every value here is a documentation placeholder):

   STORE a PAN (field-level, authenticated)
     dek      = data-encryption key for the CDE  (NOT in code; fetched from KMS)
     nonce    = csprng(12 bytes)                 -> "a1b2c3d4e5f6a1b2c3d4e5f6" (illustrative)
     ct, tag  = AES_256_GCM_encrypt(dek, nonce, pan="4111111111111111")
     store row: { token_ref, nonce, ct, tag }    # plaintext PAN never written

   READ a PAN (only for an authorized, audited operation)
     dek          = fetch from KMS (access-controlled, logged)
     plaintext    = AES_256_GCM_decrypt(dek, nonce, ct, tag)   # tag MUST verify
     # if the stored ct/tag was altered, the tag check FAILS and decryption is refused

Figure CS4.1 — Field-level authenticated encryption of the PAN. The data-encryption key is never in code; the GCM tag means tampering is detected, not silently decrypted. All values shown are illustrative placeholders.

⚠️ Common Pitfall: Stopping here and declaring victory. Many teams choose AES-256-GCM, write it into a slide, and move on — leaving the key sitting in a config file three feet from the data it protects. The cipher decision is perhaps 20% of the security and 80% of the comfort. The next phase — where the key lives and who can use it — is the reverse, and it is the phase that distinguishes real protection from compliance theater.

Phase 3 — Key management: where defenders actually win or lose

Now the hard part. Encryption, Sam reminds the team, does not solve the problem of protecting the data — it transforms it into the problem of protecting the key. If you do not then protect the key, you have moved the problem, not solved it (§4.7). So the team designs the key management explicitly, against the failure catalog:

Key hierarchy. Rather than one key for everything, Sam uses a hierarchy (a standard pattern that the bank's cloud KMS supports natively):

                 ┌─────────────────────────────┐
                 │  KEY-ENCRYPTION KEY (KEK)    │  lives ONLY in the KMS / HSM-backed;
                 │  never leaves the KMS        │  never exported to an application
                 └──────────────┬──────────────┘
                                │ wraps (encrypts)
                 ┌──────────────▼──────────────┐
                 │  DATA-ENCRYPTION KEYS (DEKs) │  encrypt the actual CDE fields;
                 │  stored only in WRAPPED form │  fetched + unwrapped at runtime by
                 └──────────────┬──────────────┘  authorized services only
                                │ encrypts
                       ┌────────▼────────┐
                       │  CARDHOLDER DATA │  the PANs at rest (ciphertext)
                       └─────────────────┘

Figure CS4.2 — A key hierarchy. The key-encryption key never leaves protected storage; data-encryption keys are only ever stored wrapped. Compromising the encrypted data, or even a wrapped DEK, does not by itself yield plaintext.

The team walks each §4.7 key-management failure and shows how the design avoids it:

• No keys in source code or config. DEKs are fetched from the KMS at runtime; the KEK never leaves it. This directly forecloses the most common real leak — a key committed to the Git repository (the very scenario Meridian will hunt for in Chapter 20's secrets-scanning work).
• Keys stored separately from the data. The CDE database and the KMS are different systems with different access controls. Stealing the database does not steal the key. The encrypted backup that nobody had inventoried (from the Background) is now genuinely safe even if it leaks again — provided the KMS access is sound.
• Defined rotation. The standard mandates periodic key rotation and rotation on suspected compromise, so a single key exposure does not expose an unbounded history of data.
• Least-privilege access to keys (the blast-radius decision). This is the meeting that took three sessions and a lawyer. Who and what can call the KMS to decrypt? The team's answer: only specific service identities, for specific operations, with every decryption logged. A human analyst cannot pull the DEK; even most application paths cannot. This is least privilege (Chapter 3, §3.4) applied to the decryption capability, and its purpose is to shrink the blast radius — so that one compromised account or service decrypts only what it was narrowly entitled to, not the whole estate.

🛡️ Defender's Lens: Notice that the team's hardest, highest-value work was not cryptographic at all — it was access control over the key and logging of every decryption. That is Theme 1 in action: security here is not a product (the cipher) but a process (key governance, rotation, audited access). An attacker who exfiltrates the encrypted CDE gets ciphertext; an attacker who wants the plaintext must now compromise a specific service identity and will generate decryption logs while doing it — which is exactly the kind of evidence the SOC (Chapters 21–22) can alert on. The encryption did not just protect the data; it turned "read the data" into a noisy, narrow, detectable action.

🔗 Connection: The phrase "hardware-protected key storage" hovers over this design — the KEK being "HSM-backed." A hardware security module (HSM) and the full certificate-and-key lifecycle are introduced and operated in Chapter 5, and secrets management at scale (vaults, dynamic secrets) is Chapter 20. This case study deliberately stops at the principles — keys separate from data, wrapped, least-privilege, rotated, logged — and hands the operational machinery to those chapters. Recognizing where a design's principles end and another team's operations begin is itself a senior skill.

Phase 4 — An alternative the assessor will ask about: tokenization

Elena raises a question PCI assessors love: could Meridian avoid storing PANs at all? The strongest way to protect cardholder data is to not have it. Tokenization replaces a PAN with a meaningless surrogate value (a "token") and stores the real PAN only in one tightly controlled vault (often a third-party service); systems that merely need to reference a card — analytics, reconciliation, customer service — use the token, which is worthless to a thief.

For Meridian, the team adopts a hybrid posture. The six-year-old reconciliation job that started this whole mess does not actually need the real PAN — it needs a stable identifier to match records. So that job is migrated to tokens, removing real PANs from the analytics environment entirely and shrinking the CDE (which, pleasingly, also shrinks PCI scope — fewer systems "touch" cardholder data, so fewer systems must be assessed). The systems that genuinely must process the real PAN (the payment path) keep the field-level AES-256-GCM encryption from Phase 2. The principle Elena writes into the standard: prefer to eliminate sensitive data (tokenize) over protecting it (encrypt); encrypt what you cannot eliminate.

💡 Intuition: The cheapest data to secure is the data you do not store. Encryption protects a secret you are holding; tokenization lets you stop holding it. Whenever a design proposes to encrypt a pile of sensitive data, a good defender first asks the prior question — do we need to keep this at all, or can we replace it with a worthless reference? Reducing what you hold reduces both risk and scope.

Phase 5 — Writing the standard and proving it

Cryptography that cannot be demonstrated fails the audit, so Elena turns the design into a testable encryption standard — the program increment this chapter contributes. The standard is short and specific by design, so engineers cannot drift and assessors can check it line by line:

   MERIDIAN ENCRYPTION STANDARD (excerpt — data at rest)
   1. Stored PANs in the CDE SHALL be rendered unreadable using AES-256 in an
      authenticated mode (GCM). Field-level encryption REQUIRED for full PANs;
      transparent storage encryption REQUIRED beneath it (defense in depth).
   2. Where a PAN is not required, it SHALL be tokenized; the real PAN SHALL exist
      only in the controlled token vault. Prefer elimination over encryption.
   3. Keys SHALL NOT appear in source code, configuration, or logs. Data-encryption
      keys SHALL be stored only in wrapped form; the key-encryption key SHALL NOT
      leave protected (HSM-backed) storage. (Lifecycle: see the Ch.5 key standard.)
   4. Access to decrypt SHALL be limited to named service identities for named
      operations, and every decryption SHALL be logged.
   5. Keys SHALL be rotated on a defined schedule and upon suspected compromise.
   6. Hashing for integrity SHALL use SHA-256 or SHA-3; MD5 and SHA-1 are PROHIBITED
      for security use. Randomness SHALL come from a CSPRNG.
   7. Prohibited everywhere: ECB mode; DES/3DES/RC4; RSA-1024; custom cryptography.

For each clause, Elena notes the evidence an assessor would request: a configuration showing AES-256-GCM; KMS access policies showing least-privilege decryption; decryption logs; a key-rotation record; a code-scan report showing no hard-coded keys (Chapter 20). The standard is now not a wish but a control with proof behind it — and it maps cleanly to the PCI-DSS expectation that stored cardholder data be rendered unreadable and that cryptographic keys be protected and access-restricted. (The precise requirement-by- requirement crosswalk is Chapter 28's job; the standard is built to satisfy it.)

🔄 Check Your Understanding: The standard requires that every decryption be logged (clause 4). This is not, strictly, a cryptographic control at all. Why did the team put a logging requirement in an encryption standard, and which of the four guarantees from §4.1 does logging help with that encryption alone cannot? (Hint: think about the one threat encryption explicitly does not stop — an authorized account misusing its access — and how you would ever detect it.)

Discussion Questions

1. Sam spent roughly 20% of the effort on the cipher and 80% on key management and access. Defend this allocation to a skeptical manager who thinks "we chose AES-256, we're done." What concretely is left undone after the cipher is chosen?
2. The team used both transparent encryption and field-level encryption for the PAN. What does each layer protect against that the other does not, and is the added complexity of two layers justified for a bank?
3. Tokenization removed real PANs from the analytics environment and shrank PCI scope. Is "reduce what you store" always preferable to "protect what you store"? Name a situation where you cannot tokenize and must encrypt.
4. The hardest decision (Phase 3) was who and what can decrypt. Propose a concrete least-privilege rule for decryption access and explain how it limits the blast radius of one compromised service account.
5. Encryption at rest does nothing against an attacker who compromises an authorized account or who reads data in use from memory. Given that, why is encrypting the CDE still worth doing? What attacks does it genuinely defeat?

Your Turn

Take a small organization (real or invented) that stores one category of sensitive data — health records, customer PII, employee bank details. Produce a one-page encryption-at-rest design: (1) write the §4.1-style threat model of what encryption will and will not protect against here; (2) choose algorithm, key size, and mode with justification; (3) decide where the key lives and who/what can decrypt, stated as a least-privilege rule; (4) decide whether any of the data can be eliminated (tokenized or simply not stored) rather than encrypted; and (5) write three testable standard clauses an auditor could verify, and for each name the evidence you would show. If you cannot name the evidence for a clause, the clause is a wish, not a control — note what you would need to make it real.

Key Takeaways

• Encryption transforms the problem, it does not solve it: it converts "protect the data" into "protect the key," and a design that does not then protect the key has moved the problem, not solved it.
• For data at rest, the cipher choice is the easy part — AES-256 in an authenticated mode (GCM), never ECB, with a CSPRNG and unique IVs — and roughly 80% of real security lives in key management.
• Keep keys separate from the data, never in code/config, store data-encryption keys only wrapped, rotate them, and apply least privilege to decryption so one compromised identity has a small blast radius.
• Logging every decryption turns the one threat encryption cannot stop (authorized-access misuse) into a detectable event — security as a process, not just a cipher.
• Prefer elimination to encryption: tokenize or simply do not store sensitive data you do not need; this reduces both risk and compliance scope. Encrypt what you cannot eliminate.
• A cryptographic control is only as good as the standard and evidence behind it: an auditor (and an attacker) tests how you encrypted, not whether you said you did.