Data Protection and Encryption at Rest

Enable-BitLocker -MountPoint "C:" -TpmProtector -RecoveryPasswordProtector

- LUKS (Linux): Create an encrypted partition:

cryptsetup luksFormat /dev/sdb1
  cryptsetup open /dev/sdb1 myencrypted
  mkfs.ext4 /dev/mapper/myencrypted

- OpenSSL (File-Level): Encrypt a file with AES-256:

openssl enc -aes-256-cbc -salt -in plain.txt -out encrypted.enc

- SQL Server TDE: Enable TDE:

CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
  ALTER DATABASE MyDB SET ENCRYPTION ON;

Scenario 1: Laptop Theft at a Healthcare Organization A nurse's laptop containing patient records (PHI) is stolen from a car. The laptop has BitLocker FDE enabled with TPM and a recovery key stored in Active Directory. The SOC receives an alert that the laptop has not checked in for 24 hours. The incident response team confirms the theft. Because the drive is encrypted, the risk of a data breach is minimal. The team revokes the recovery key in Active Directory to prevent any unauthorized use. The common mistake here would be if the laptop did not have FDE enabled, or if the recovery key was stored on the same drive, allowing the attacker to decrypt it. The correct response is to confirm encryption status via Microsoft Endpoint Manager and document the incident with no breach notification required.

Scenario 2: Cloud Storage Misconfiguration A company uses AWS S3 for backup data. An administrator mistakenly sets a bucket to public. The SOC sees an alert for public bucket access. The data is encrypted at rest using SSE-S3 (server-side encryption with Amazon S3 managed keys). Even though the bucket is public, the data is encrypted and cannot be read without the decryption key. However, the keys are managed by AWS, so if the bucket is public, an attacker could still download the encrypted data and potentially brute-force the key if weak. The correct response is to immediately block public access and rotate the encryption key. The common mistake is assuming that encryption alone makes data safe in a public bucket; encryption at rest does not protect against unauthorized access if the keys are also exposed.

Scenario 3: Database Breach via SQL Injection An attacker exploits a SQL injection vulnerability to dump a database. The database uses TDE, so the data files are encrypted. However, TDE automatically decrypts data when queried, so the attacker can read all data through the SQL injection. TDE protects only against physical theft of the database files, not against application-level attacks. The SOC sees unusual queries in database logs. The correct response is to patch the SQL injection vulnerability and implement additional column-level encryption for sensitive columns. The common mistake is believing TDE prevents data exfiltration via SQL injection. Encryption at rest must be complemented by other controls like input validation and database firewall.