Certified: The GIAC GSLC Audio Course

In this episode, we focus on protecting stored data so that theft does not automatically become disclosure, because that is the real goal of encryption at rest. People sometimes talk about encryption as if it is a single switch you flip, but in practice it is a relationship between where data lives, how it is protected, and who can turn protection into readable content. Data at rest is everywhere in modern environments, from laptops and virtual disks to managed databases, backups, and long-lived snapshots that quietly accumulate in the background. Attackers understand that stored data is valuable because it can be copied, moved, and analyzed at their leisure, especially when the theft event is fast and the investigation is slow. A disciplined approach treats encryption as necessary but not sufficient, because encryption without key custody discipline and access pattern controls can devolve into theater. When you combine strong encryption with controlled key access and tight permissions, you create a system where losing the storage medium is not the same as losing the data. That is the mindset we are going to build in a way that is practical, defensible, and scalable.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

To begin, it helps to define what we mean by data at rest, because the term spans more than just a hard drive sitting in a laptop. Data at rest includes files on endpoints, virtual machine disks, database storage, object storage, and also the artifacts people forget, like backups, snapshots, replicas, and exported datasets used for analytics. It includes log archives, crash dumps, and even temporary staging areas created during processing pipelines. The common feature is that the data is stored and can be accessed without needing to intercept a live network flow, which changes the threat model. When data is at rest, an attacker can attempt to steal the storage medium, access it through compromised credentials, or obtain copies from misconfigured backup systems. The impact can be amplified because at-rest stores often represent aggregated data, meaning one compromise yields many records rather than a single transaction. That aggregation is why backups and snapshots deserve special attention, because they often contain the most complete and least monitored copy of sensitive content. If you protect only the primary database but ignore its replicas and backup chain, you leave a quiet side door open.

Once you have a clear inventory of at-rest locations, the next step is choosing the right encryption scope, because encryption can happen at multiple layers with different tradeoffs. Volume-level encryption protects an entire disk or storage volume, which is excellent for protecting against physical theft and certain classes of unauthorized access to the underlying storage. File-level encryption protects specific files or directories, which can provide finer control and may be useful when multiple datasets share the same volume. Application-layer encryption protects data inside the application or service before it is written to storage, which can be especially valuable when you want to limit who can decrypt even if they have database access. The point is not to declare one layer universally best, but to match the layer to the threat you are trying to reduce. Volume encryption can be strong, but if the system is running and an attacker has obtained privileged access, the volume is already unlocked. Application-layer encryption can limit that exposure, but it can also complicate search, indexing, and operations if it is designed poorly. A mature design often uses layered encryption, because layered approaches reduce single points of failure.

The choice of encryption scope also depends on operational realities, because controls that cannot be maintained reliably tend to fail at the worst possible moment. Volume encryption is often the easiest to deploy consistently across fleets and is supported by many platforms by default, but you still need to confirm it is actually enabled and not optional. File-level encryption can create policy complexity if teams are expected to decide file by file, which can lead to inconsistent protection and accidental gaps. Application-layer encryption can provide stronger separation of duties, but it pushes responsibility into the software lifecycle, which means design reviews, key handling logic, and failure modes must be engineered carefully. You also have to consider how data moves through the system, because data that is encrypted at rest may be decrypted into memory and written to logs or caches in plaintext if application behavior is sloppy. That is why encryption scope should be discussed in the context of data flows and access patterns, not merely storage technology. A strong approach asks where the sensitive data is created, where it is processed, where it is stored, and where it is copied. Encryption decisions should follow that path rather than focusing on only one component.

Key custody is where encryption becomes meaningful protection, because keys are the capability that turns ciphertext into readable data. Key custody means deciding who holds the keys, where they are stored, and which identities are allowed to use them for decryption operations. This includes both human identities and service identities, because most decryption at scale is performed by services on behalf of users or workloads. A useful way to think about custody is that storage access and key access should not automatically be the same permission, because collapsing them into one boundary defeats the point of encryption in many scenarios. If anyone who can read the storage can also use the keys, then encryption adds little resistance beyond preventing casual access. Custody decisions also include how keys are generated, how they are protected from extraction, and how access to key usage is logged and reviewed. In well-run environments, keys are treated like high-value assets, not like configuration trivia. When keys are protected and tightly controlled, encryption becomes a real barrier that can change breach outcomes.

A common pitfall is encrypting data while leaving keys broadly accessible, which creates a false sense of security and an oversized blast radius. Broad key access often emerges from convenience-driven design, where teams grant decryption permissions widely to avoid operational friction. Over time, that broad access may extend to administrators who do not need it, to automation roles that were copied from older templates, or to third-party tooling that requires access for monitoring. The problem with broad key access is that it turns a compromise of any one of those identities into a compromise of the encrypted dataset. It also undermines separation of duties, because the same actor can retrieve ciphertext and decrypt it without additional approvals or checks. In incident response, broad key access makes containment harder because you have more identities to investigate and more potential abuse paths. It also complicates compliance narratives because you cannot credibly claim that encryption limits disclosure if decryption rights are ubiquitous. If you want encryption to change outcomes, key access must be narrower than data access, at least for the most sensitive datasets.

A quick win with strong impact is to separate data access from key access wherever possible, because this single design choice forces an attacker to cross two distinct barriers. Separation can be achieved by designing roles so that some identities can read data but cannot decrypt it, while other identities can decrypt but only within controlled service contexts. In practice, this often means that applications perform decryption on behalf of users, while users and administrators do not directly hold decryption capabilities. It also means that operational tooling can observe and manage storage without needing the ability to decrypt the contents. Separation is not about distrusting everyone; it is about reducing the number of paths that lead to full disclosure. When key access is constrained, you can also apply stronger monitoring to a smaller set of identities, which improves the signal-to-noise ratio in detection. Separation supports better incident response because you can revoke or constrain key usage without necessarily revoking all data access immediately. In other words, separation gives you more containment levers, and containment levers are what you want when the situation changes suddenly.

To make this concrete, consider a scenario where a laptop is stolen, and encryption plus key custody choices limit the damage. If the laptop’s storage is encrypted and the keys are protected in a way that requires user authentication and device integrity, then physical possession alone does not yield readable data. Even if an attacker removes the disk or attempts offline analysis, the encrypted content remains unreadable without the keys. The scenario becomes more interesting when you think about what else might be on that laptop, such as cached credentials, tokens, synced files, or local database replicas used for development. Strong at-rest encryption reduces the risk of direct data disclosure, but it does not eliminate the risk of credential theft if secrets are stored insecurely. That is why key custody and access patterns matter, because a stolen device should not grant the ability to decrypt cloud-stored datasets or access sensitive backups. When encryption and key custody are designed well, the incident response becomes focused on account and token hygiene rather than scrambling to explain why local data was readable. The stolen device is still a security event, but it is not automatically a data breach.

Least privilege is the next layer, because encryption is not meant to replace access control, it is meant to reinforce it. Least privilege means only the roles that truly need decryption rights can perform decryption, and those rights should be scoped to the minimum dataset and the minimum context. In practice, this means that developers may have access to test datasets but not production keys, that operations staff may manage infrastructure but not decrypt regulated data, and that application workloads have narrowly scoped key usage permissions limited to their own data. Least privilege also helps prevent accidental misuse, because broad permissions make it easy for well-meaning staff to access data out of curiosity or convenience. When permissions are narrow, routine work encourages safer paths, such as using approved services that enforce auditing and policy. Least privilege becomes especially important when you consider backups and snapshots, because these often inherit broader access patterns than primary systems. If you lock down decryption rights consistently across primary and secondary stores, you reduce the chance that an attacker will simply pivot to the easiest copy.

Monitoring decryption events is one of the most underused capabilities in at-rest protection, and it is also one of the most valuable because it provides high-quality signals. Decryption is an action with clear security meaning, especially when decryption rights are tightly controlled. If you see unusual decryption patterns, such as decryption at unusual times, from unusual locations, by unexpected identities, or at volumes inconsistent with normal workload behavior, you may be seeing misuse or compromise. Monitoring also helps detect operational mistakes, such as an application suddenly decrypting far more data due to a bug, which can signal data handling risks and potential leakage. The key is to define what normal looks like for each sensitive dataset and then alert on deviation with context. If you monitor everything without thoughtful baselines, you will drown in noise, but if you monitor key usage with narrow custody, you can achieve a strong signal-to-noise ratio. Decryption monitoring also supports audit and compliance narratives because it shows that the organization not only encrypts data but also watches the rare, high-impact actions that make data readable. That is the kind of evidence that withstands scrutiny.

Key rotation planning is what prepares you for the moment when key compromise risk changes suddenly, because that moment can arrive without warning. Rotation is often discussed as a routine hygiene practice, but the more critical scenario is emergency rotation when you suspect keys have been exposed. A suspected compromise can come from a leaked credential, a misconfigured permission that granted key usage too broadly, or an incident involving an endpoint that had access to keys. When that happens, you need the ability to rotate keys and re-encrypt data without bringing the business to a halt. That requires designing systems to tolerate key changes, testing the process, and understanding which datasets and services depend on which keys. Rotation planning also requires you to think about rollback and recovery, because a failed rotation can become an outage if applications cannot decrypt data they need. A mature environment treats key rotation as a practiced procedure rather than an improvised response. When rotation is planned and rehearsed, you can respond decisively to increased risk without being forced into unsafe choices. The ability to rotate keys safely is not just a security feature, it is an operational capability.

A helpful memory anchor is that encryption plus custody plus access equals protection, because it keeps you from overvaluing any one component. Encryption without custody is weak because keys are the real power. Custody without access control is weak because broad permissions create too many paths to misuse. Access control without encryption is weak because physical theft, storage-level compromise, and copy-based attacks can bypass application controls. When all three are combined, you get layered defense that changes breach outcomes. This anchor also helps in design discussions, because it gives you a simple way to test whether a proposal is complete. If someone proposes encrypting a dataset, you can ask who can decrypt and how that is controlled. If someone proposes limiting access, you can ask whether storage copies and backups are protected if controls fail. If someone proposes a key management approach, you can ask whether decryption events are visible and whether rotation is feasible. The anchor keeps the conversation grounded in outcome, which is preventing disclosure even when parts of the system fail.

It is also essential to confirm that encryption is enabled across environments and not optional, because inconsistent deployment is a common and avoidable gap. Many organizations have strong encryption in production but weaker controls in development, test, or staging environments, even when those environments contain real data. That inconsistency creates a convenient target because attackers look for the weakest place that still holds valuable content. Confirming encryption means verifying configuration across the fleet, not assuming defaults are consistent. It also means ensuring that teams cannot disable encryption casually to solve a short-term performance or compatibility issue. When encryption is optional, it will eventually be turned off somewhere, usually during an urgent moment, and it will be forgotten until an incident forces everyone to remember. A better approach is to treat encryption as a baseline requirement for at-rest stores that hold sensitive data, and to build exceptions as explicit, time-bound decisions with compensating controls. Consistency is what makes protection dependable, and dependability is what matters in real incidents.

For a mini-review, keep three common at-rest stores and their controls clear so you can reason quickly in reviews. Disks and volumes on endpoints or servers should be protected with strong at-rest encryption, tied to authentication and device integrity so physical theft does not yield readable content. Databases and managed storage systems should be encrypted at rest and paired with tight key custody so administrators and broad roles cannot decrypt simply by accessing the storage layer. Backups and snapshots should be treated as high sensitivity, encrypted, and access-controlled with the same discipline as primary systems, because they often contain the most complete dataset. Across all three, least privilege for decryption rights and monitoring of key usage provide the accountability and detection needed to make the controls real. The most common failure is protecting one store and ignoring the others, especially backups. The second most common failure is encrypting everything but allowing decryption to be broadly available. When you keep these stores and controls in mind, you can spot gaps faster.

To conclude, identify one sensitive dataset that needs stronger at-rest controls and use it as a practical starting point for improving the system. Choose a dataset that has clear business impact if disclosed, such as regulated personal data, intellectual property, authentication data, or critical operational records. Then assess it through the lens of encryption scope, key custody, and access patterns, because that combination will reveal where protection is strong and where it is fragile. You might discover encryption is enabled but key access is too broad, or that backups are protected differently than the primary store, or that decryption events are not monitored at all. Each of those findings points to a concrete improvement that can change outcomes in a real incident. By working one dataset deeply, you also create a repeatable approach that can be applied to other datasets without reinventing the logic. Over time, this becomes a discipline where stored data remains protected even when devices are lost, credentials are abused, or storage copies are exposed. That is the true measure of at-rest protection: not that encryption exists, but that theft does not equal disclosure.