Cryptographic use cases: data at rest, in transit and in use

Why this matters

Objective 3.4 is about applying cryptography to requirements, and this first lesson establishes the frame the other two use: map the requirement to a state of data, then to a control, then to a product — in that order, and never starting at the end.

The reason the order matters is that "encrypt the data" is not a requirement. It is four different controls depending on which state is being protected and which adversary is being excluded, and choosing the wrong one produces a design that is genuinely encrypted and does not address the threat. Full-disk encryption on a running server does nothing about a compromised application; TLS does nothing about a database administrator reading a table.

CAS-005 tests this directly. Scenarios describe an adversary and a requirement, and offer several encryption options that are all real. The correct one is the one whose protection boundary excludes the named adversary.

The lesson

Full disk, filesystem, database and field-level encryption, and what each defends against

Four layers of encryption at rest, in increasing granularity and decreasing convenience. The question that separates them is: when is the data in plaintext, and to whom?

Full-disk encryption. The whole volume is encrypted; the key is released at boot. Once the system is running, everything that can read the filesystem reads plaintext.

• Defends against: a stolen device, a disposed drive, a removed disk. This is a real and important threat for endpoints and for decommissioning.
• Does not defend against: anything on a running system. An attacker with a shell, a malicious administrator, or a compromised application all see plaintext.

Filesystem or volume-level encryption. Individual directories or volumes encrypted with separate keys, potentially released at different times or to different principals.

• Adds: separation, so one compromise does not necessarily yield everything.
• Still: plaintext to anyone with access to the mounted, unlocked filesystem.

Database encryption — transparent encryption. The database engine encrypts its files. Convenient, no application change.

• Defends against: theft of database files and backups, which is a genuine and common exposure path.
• Does not defend against: any query. A user or application with database access reads plaintext, and so does an administrator. This is the layer most often deployed and most often believed to do more than it does.

Field or column-level encryption. Specific fields encrypted, with keys held by the application or a key service rather than by the database.

• Defends against: the database administrator, a compromise of the database itself, and a query-level compromise, because the engine holds only ciphertext.
• Costs: the application must handle encryption and keys; searching, sorting and indexing on encrypted fields is limited or impossible; and it is substantially more work to implement and maintain.

Application-level encryption goes further: the application encrypts before the data reaches any storage, so nothing in the storage path ever holds plaintext.

The selection rule to carry: encrypt at a layer above the adversary you are excluding. If the adversary is a thief with the disk, full-disk suffices. If it is the database administrator, the key must live above the database. If it is your cloud provider, the key must live outside their control — which is lesson seventeen's conclusion arriving from the other direction.

Transport security done properly: versions, cipher suites, and certificate validation

Data in transit is the best-solved of the three states, and the failures are consistent enough to enumerate.

Protocol version. Use current versions and disable obsolete ones. The substantive reasons rather than version-number preference: older versions permit weak cipher suites, are vulnerable to known downgrade and padding attacks, and do not require forward secrecy. Current versions remove those by construction — which is the actual argument, and the one a scenario expects.

Cipher suites. Prefer authenticated encryption modes, require forward secrecy, and disable suites with known weaknesses. The operational point is that the default configuration of many servers and libraries is more permissive than your standard, so this is a configuration item to specify, deploy and verify — not a property you inherit.

Certificate validation is where most real failures live, and they are overwhelmingly on the client side:

• Validation disabled entirely, usually added during development to get past a self-signed certificate and never removed. This is the single most common TLS defect in internal applications, and it reduces the connection to encryption without authentication, which any intercepting attacker defeats.
• Hostname not checked, so any valid certificate from any trusted issuer is accepted.
• Chain and expiry not checked, or errors caught and ignored.
• Revocation not checked, which is genuinely difficult in practice and is why short certificate lifetimes have become the preferred answer.

The examinable framing: encryption without authentication is not confidentiality. A connection encrypted to an attacker is private between you and the attacker, and a scenario describing an intercepted connection with "TLS enabled" is describing exactly this.

Two further points. Internal traffic needs this too — the assumption that the internal network is trusted is the assumption lesson twenty-one dismantled, and unencrypted internal traffic is what lateral movement reads. And the certificate lifecycle is an availability obligation: an expired certificate is an outage, which is why automation and monitoring of expiry belong with the control rather than beside it.

Mutual TLS between services, and the certificate lifecycle it commits you to

Mutual TLS authenticates both ends: the client presents a certificate too, so the server knows what is connecting rather than only the client knowing what it reached.

Why it matters for service-to-service communication: it gives each workload a cryptographic identity, which is the precondition for the identity-based policy lesson twenty described and the subject-object relationships of lesson twenty-five. A service mesh's value rests largely on this.

What it commits you to, and this is the part organisations underestimate:

• Issuing a certificate to every workload, including ephemeral ones that exist for minutes.
• Renewing before expiry, automatically, everywhere, forever.
• Revoking when a workload is compromised or retired, with a mechanism that actually takes effect.
• Operating a certificate authority for internal identities, with its root protected as lesson thirty-five described, and its own availability requirements — a CA that is down means new workloads cannot start.
• Rotating the CA itself eventually, which requires a trust-distribution mechanism planned in advance rather than improvised.

The property that makes this tractable at scale is short lifetimes. Certificates measured in hours, issued automatically to attested workloads, remove revocation as a practical problem — a compromised identity expires before revocation would have propagated — and force the automation to be correct, because anything manual fails immediately rather than in a year. The counter-intuitive conclusion worth carrying: shorter lifetimes are operationally easier than long ones, because they make failure immediate and visible instead of rare and catastrophic.

Data in use, and why it is the state most designs ignore

The third state, covered in mechanism in lesson thirty-four and placed here as a design question.

Almost every architecture diagram shows encryption at rest and in transit and is silent about processing. The silence is not an oversight so much as an inherited assumption: the host is trusted, therefore plaintext in its memory is acceptable. Three changes make that assumption worth re-examining.

• The host is frequently not yours. In cloud, the hypervisor and the operator are outside your control, and "the provider could read our memory" is a true statement that most designs simply do not address.
• Memory is extractable. Crash dumps, swap, snapshots, hibernation files and debugging interfaces all persist what was supposed to be transient — and each is a copy that the storage-layer controls from earlier in this lesson may not cover.
• Compromise of the process yields everything it can read, which is the entire point of field-level encryption above and is undone if the process holds the plaintext of every record anyway.

Practical mitigations short of confidential computing, and each is cheap enough to be a default:

• Minimise plaintext lifetime. Decrypt the fields needed for the operation, not the whole record; hold them for the operation, not the request.
• Disable core dumps on processes handling sensitive data, and exclude swap and hibernation, or encrypt them.
• Keep secrets out of environment variables and command lines, which are readable by other processes and captured by logging.
• Prevent snapshots of sensitive workloads from being taken casually, because a memory snapshot is a plaintext copy of everything.
• Use confidential computing where the operator is genuinely part of the threat model.

The examinable point: a scenario naming the platform operator, a hypervisor compromise, or memory extraction as the threat is asking about data in use, and answers about at-rest or in-transit encryption — however strong — do not address it.

Mapping a requirement to a state of data instead of to a product

The closing method, which is the lesson's purpose.

Work in four steps, and scenarios in this objective are decidable when you do:

One: identify the state. Is the data being stored, moved, or processed at the moment the threat applies? A requirement about backups is at rest. A requirement about interception is in transit. A requirement about the operator or a compromised process is in use.

Two: identify the adversary to exclude. Someone with the media, someone on the network, a database administrator, an application compromise, the platform operator, a third party with a legal demand. This is the step that most often goes unstated and most often decides the answer.

Three: choose the layer above that adversary. The control must place the key or the boundary beyond the adversary's reach. This single rule resolves most of the lesson: field-level above the DBA, application-level above the storage platform, customer-managed keys above the provider's routine access, external key store above the provider entirely.

Four: state the cost. Searchability lost, key lifecycle acquired, latency added, availability dependency created. An answer without its cost is incomplete, and on this exam proportionality is part of correctness.

Two closing cautions. Encryption does not address authorisation. A system where everyone who needs the data can decrypt it has protected it against outsiders and not at all against misuse, and a scenario describing an insider reading records they can legitimately decrypt is an access control question wearing a cryptography costume. And encryption moves the problem to the key — which is not a criticism, because a small well-protected secret is easier to defend than a large data set, but it does mean the key management from lesson seventeen is where the design's strength actually lies.