Rachel and the Three States of Data

Data Is Everywhere. None of It Is Encrypted.

The HIPAA audit report was blunt: patient data at HealthData Systems existed in three states — at rest on servers, in motion across the network, and in databases — and almost none of it was encrypted. Rachel had 90 days to fix this before regulators returned.

"Let's start with the hard drives," she told her team.

Full Disk Encryption: Everything or Nothing

Data at rest meant data stored on drives, SSDs, USB sticks, laptops. If a hard drive was stolen, could someone pull it out, connect it to another machine, and read the files? Without encryption: yes.

Rachel deployed BitLocker across all Windows servers and workstations — full volume encryption. When a drive was removed from a BitLocker machine and connected elsewhere, it was unreadable garbage without the decryption key (stored in the TPM). On Mac systems, FileVault provided the same protection.

"Full disk encryption is all-or-nothing," she explained. "Every bit on the volume is encrypted. But sometimes that's overkill — if you have a file server with public documents and a few sensitive contracts, you don't need to encrypt the whole volume. You just need to encrypt the contracts."

For individual file-level encryption on Windows, the team used EFS — the Encrypting File System built into NTFS. Right-click a file, Advanced Attributes, "Encrypt contents to secure data." Simple. File-specific.

The Database: Not All Columns Are Equal

The patient database was more complex. It contained a mix of data: benign (employee IDs, first names, appointment dates) and sensitive (Social Security Numbers, diagnosis codes, billing information).

"We could encrypt the entire database with a symmetric key," Rachel told the DBA. "Transparent encryption. Everything in, everything out — all encrypted."

"But then every query decrypts everything. Our search performance would tank."

"Exactly. So let's think about column-level encryption. Encrypt just the SSN column and the diagnosis column. Leave first name, appointment date, and employee ID in plaintext. Searching by name or date? Instant. Accessing SSNs? Decrypt just that column or that row."

The DBA nodded. "We only pay the decryption overhead when we need the sensitive data."

"And if an attacker somehow dumps the database, they get plaintext names and dates but encrypted SSNs. The most sensitive data is protected even if the rest isn't."

Data in Motion: HTTPS and VPNs

Data in transit meant anything moving across the network — between the application server and the browser, between offices, between API partners. In plaintext, network traffic could be intercepted and read by anyone with access to the network path.

The web-facing patient portal was already using HTTPS — TLS encryption on the browser connection. Any data entered in the portal (login credentials, appointment details, billing info) was encrypted in transit.

For the connection between HealthData's main datacenter and its remote clinics, Rachel configured a site-to-site VPN using IPsec. All traffic between the two sites flowed through an encrypted tunnel — even if someone tapped the link, they'd see encrypted packets.

For remote workers, a client VPN using SSL/TLS allowed employees to connect from home and have their traffic encrypted back to the datacenter.

"The algorithm on both sides must match," Rachel emphasized. "A server using AES-256 can't decrypt data encrypted with DES. Both sides agree on the algorithm before the session starts."

The Algorithm Is Public. The Key Is Secret.

An analyst asked: "If everyone knows how AES works, can't attackers just reverse-engineer the encryption?"

Rachel had a good analogy. "Think of a door lock. Everyone knows how door locks work. You can look up the patent. You can take one apart. But knowing how a lock works doesn't unlock a door. You need the key."

"Same with encryption. AES is published — the math is open source, everyone can read it. But without the key, you can't decrypt the data. The key is the secret. The algorithm is just the mechanism."

The implication: always keep private keys private. If an attacker gets your key, they can use the published algorithm to decrypt everything.

And keys could be brute-forced — trying every possible combination. The defense: make the key very long. A 128-bit symmetric key has 2^128 possible values. Even with supercomputers, brute force is infeasible. For asymmetric keys, 3072-bit or larger was the current standard.

One extra technique: key stretching (or key strengthening) — hashing a password multiple times before using it as a key. An attacker trying to brute-force must apply the same hashing chain for every attempt, multiplying their computation time.