21 — Data Protection and Backups

Level: Intermediate · Time: ~18 min · Prerequisites: Lesson 20 — Identity and Access Defence

Why this matters

Every control in this module exists to protect data, and this is the lesson where the data itself is the subject. Two facts make it the most practically important lesson in the defence module. First, ransomware does not steal your file server — it encrypts it, and the only control that reliably decides whether the business survives is whether a clean copy exists somewhere the attacker cannot reach. Second, most organisations believe they have backups and discover during an incident that they have backup jobs: jobs that stopped alerting months ago, jobs whose keys are lost, and restores nobody has ever performed. This lesson is about the difference between those two states.

The mental model: you cannot protect what you have not sorted

Classification comes first, because every later control — encryption, access, DLP, retention — needs to know what it is dealing with. Four levels are enough for almost any organisation, and the level must imply a handling rule or nobody will ever apply it.

Level	Example	Handling rule the label implies
Public	published marketing, press releases	no restriction; can be shared freely
Internal	meeting notes, internal procedures	staff only; no external sharing without agreement
Confidential	contracts, customer lists, HR records	named recipients, encrypted in transit and at rest, access logged
Restricted	credentials, payment data, health data, source code	least privilege, MFA required, encryption mandatory, access reviewed

[!TIP] A label with no rule attached is decoration. The test is simple: if a new employee read the label and could not say what they are allowed to do with the file, the scheme is not finished.

Encryption: at rest, in transit, and what it does not do

Where	What it protects	Typical implementations
At rest — full disk	a lost or stolen device, a decommissioned disk	BitLocker with a TPM, LUKS under Linux, FileVault on macOS
At rest — database or volume	the storage underneath a running system; a stolen backup tape or snapshot	transparent data encryption at the database level, encrypted volumes, storage-level encryption
At rest — file level	specific sensitive files inside an otherwise ordinary share	encrypted archives, encrypted documents, encrypted containers
In transit — external	everything crossing the internet	TLS for web and APIs, VPN or a modern tunnel for remote access, SSH for administration
In transit — internal	traffic between your own servers	internal TLS, encrypted database connections, encrypted replication

Two honest statements that most vendor material skips:

Internal cleartext is still a finding. "It is only on our own network" was acceptable when the network was trusted, and Lesson 16 explained why it is not: once an attacker is inside, plaintext internal traffic is free data. Enabling TLS between internal services is unglamorous and one of the better value-for-effort changes available.
Encryption does nothing against ransomware encrypting your live files. A user's session decrypts data transparently, so the malware inherits that access. Encryption protects confidentiality of data that has left your control; it is not a defence against an operation running as a legitimate user. That job belongs to allowlisting, least privilege (Lesson 19) and backups.

Key management

Keys are the whole of encryption, and the whole of key management is separation.

Discipline	The failure it prevents
Keys stored apart from the data they protect	a stolen disk image contains both the ciphertext and, in the worst case, the key
Rotate on a schedule and on suspicion	keys are long-lived secrets; when one leaks, the blast radius is everything it ever encrypted
Escrow and recovery designed before you need it	the documented classic: the only person holding the recovery key has left, or the key is on the machine that died
Keys in a managed store	KMS, an HSM, or a hardware token rather than a text file on a shared drive or in application source

The pattern to internalise: encryption without a tested recovery path is a way of losing data on purpose. Before you enable encryption on anything, answer who can decrypt it, where the key lives, how it is backed up, and how you would recover if the primary holder disappeared.

Data loss prevention and its more reliable alternatives

DLP is a category with a real core and a lot of marketing. What it can do reasonably well, and where it falls over:

DLP can	DLP generally cannot
discover where sensitive data is, including forgotten copies	know what a person intends when they copy a file they legitimately need
block the crudest exfiltration paths — a personal USB stick, uploading to a personal cloud drive	stop a user who is allowed to see the data and can re-type, screenshot or re-word it
alert on bulk copy, mass download or unusual volume	inspect encrypted archives, or content inside a personal encrypted channel
enforce a policy on a managed device	protect data on a device or account you do not control

Two practical conclusions. First, deploy DLP for discovery before blocking — knowing where the restricted data actually sits is worth more than a rule that annoys everyone. Second, access control plus egress monitoring is more reliable than content inspection: if the data is only reachable by the twelve people who need it, the exfiltration question is much smaller, and monitoring what leaves your network (Lesson 44) catches the removal regardless of the method.

Backups: the control that decides whether ransomware ends the business

The rules that matter

3        copies of the data            (the original plus two backups, so one failure is survivable)
2        different media or platforms  (not two folders on the same failing array)
1        copy offsite                  (fire, flood, theft, and one building-wide incident)
+ 1      copy offline or immutable     (ransomware cannot delete what it cannot reach or overwrite)
+ 0      verified errors               (a restore you have never tested is a hope, not a backup)

The original 3-2-1 rule predates ransomware and assumed accidents. The later additions exist because modern ransomware is deliberate: a skilled attacker will look for your backups and delete them before encrypting.

Separate the backup credentials from the production domain. This is the single most common catastrophic mistake. If the backup server trusts the same directory as the file server, then the administrator account the attacker just took over can log into the backup server and delete the backups. Backups should be a separate trust domain: their own accounts, their own service credentials, ideally reachable only from a hardened management host, with deletion permissions held by as few people as possible.

What people back up	What they forget
user files and shared drives	configuration of servers, network devices and applications
databases	identity and directory data — users, groups, policies
—	mailboxes and shared calendars
—	encryption keys and certificate authorities, without which restores are unusable
—	documentation: runbooks, licences, contact lists, this course's checklists

Frequency, retention, RPO and RTO in plain terms

Term	Plain meaning	Decided by
RPO — recovery point objective	how much data you can afford to lose, expressed in time	the backup frequency: hourly backups mean at most an hour of work disappears
RTO — recovery time objective	how long the business can tolerate the service being down	the restore method and how fast your hardware or cloud can be brought up
Retention	how far back you can go	legal requirements, business need, and the cost of storage

Have that conversation in business terms: "we can lose an hour of orders, and we need to be selling again within four hours" is a specification. "We back up nightly" is not.

Application-consistent backups matter for anything with a database or an open file. A raw copy of a running database may restore into an inconsistent state; a database-aware backup or a snapshot coordinated with the application restores cleanly. Use the tool the platform provides — pg_basebackup for PostgreSQL, mysqldump --single-transaction or mariadb-dump for MySQL, native backup tooling on other platforms — rather than copying the data directory of a live service.

Cloud and SaaS data

The shared-responsibility trap is worth stating explicitly: your provider protects the platform, not your data. Deleted mailboxes, accidental overwrites, ransomware inside a synced folder, and an outright mistake by an administrator are your problem. If a business runs on a cloud file service or a SaaS suite, those need their own backup destination outside that provider — and note that a synchronised folder is not a backup, because a deletion or encryption propagates to every replica within seconds.

Restoration is the only test that counts

A backup is only real once you have restored from it. Run a restore drill on a calendar, at three levels of ambition:

Drill	What you do	What it proves
One file	pick a random file from a random user, restore it, note the time	the pipeline works and someone knows how
One service	restore a database or application into an isolated environment and start it	the backup is application-consistent and usable
One machine	restore a full host, including configuration, and bring it back into service	the RTO is real, and you have everything you need

Record the elapsed time, and record what was missing. Typical discoveries on the first drill: a backup job that had been failing silently for months, a target with no free space, a key held only by a person who is on holiday, a service that cannot start because its configuration was never backed up, and steps that exist only in someone's head.

Retention, secure deletion and the EU dimension

Keeping data forever is a liability with a storage bill. Retention limits reduce both: what is not retained cannot be breached, subpoenaed or leaked, and does not need reviewing. Define a retention period per data class, apply it automatically, and document the exceptions.

The tension is legal hold: when litigation or an investigation is foreseeable, deletion must stop for the relevant material, and that override needs to be written down in advance rather than improvised. Under EU rules, personal data must be kept only as long as necessary, and individuals have rights over it — so retention is not only a security preference, it is a compliance requirement. Personal data on backup media is the awkward case: it is technically hard to erase a single person's record from an immutable archive, which is another reason to keep retention windows short and documented.

Secure deletion deserves one sentence of honesty: overwriting tools that work on magnetic disks do not reliably erase files on SSDs or copy-on-write filesystems, where the storage controller may keep the old blocks. The dependable approaches are encryption with key destruction (crypto-shredding) and the device's own secure-erase facility.

A ten-item backup checklist you can run this month

List every system, dataset and cloud service, and mark which ones the business could not survive losing for a day.
For each, write down the frequency and confirm it matches the RPO the business actually stated.
Confirm three copies, on two media or platforms, with one offsite.
Confirm at least one copy is offline or immutable, or in a separate trust domain with different credentials.
Confirm the backup accounts are not the same accounts that administer production, and that they require MFA.
Confirm backups are encrypted, and locate where the keys live and who else can use them.
Confirm every job alerts on failure — and test that the alert fires by failing one deliberately.
Restore one file and time it. Write the time down.
Restore one service into an isolated environment and confirm it starts and holds data.
Write the restore procedure into a runbook a colleague could follow without you, and diarise the next drill.

Failure modes, and what they cost at restore time

Mistake	What happens at restore time
Jobs never monitored	months of silent failure discovered exactly when you need the data
Backup credentials in the production domain	the attacker deletes the backups with the admin account they just took
Everything on the same platform or in one building	one incident removes the original and every copy
Keys not escrowed or not backed up	the data is intact and permanently unreadable
Untested restores	procedure gaps, missing configuration, and a much longer outage than promised
A sync folder treated as a backup	deletion or encryption propagates to every replica in minutes
Only files backed up, not configuration	a restored server that cannot actually run
No documented procedure	recovery depends on one person's memory, and that person is asleep

Attack it / Defend it

The attack	How it works	The control that stops it
Ransomware encryption	encrypts live data using a legitimate user's access	allowlisting, least privilege, immutable or offline backups
Backup destruction	uses stolen admin credentials to delete the backup repository	separate trust domain, separate credentials, immutability
Data exfiltration	copies restricted data out over an allowed channel	least privilege, egress monitoring, DLP for the crude paths
Internal cleartext capture	reads unencrypted traffic between internal systems	internal TLS, encrypted database and replication links
Stolen unencrypted device or disk	reads the media offline	full-disk encryption with escrowed recovery keys
Lost recovery key	not an attack, but the same outcome: unrecoverable data	key escrow, tested decryption, documented recovery path
Exfiltration disguised as sync	uploads data through a sanctioned cloud service	classification plus egress control, monitoring bulk uploads
Deleted cloud or SaaS data	accidental or malicious deletion inside a hosted service	backups of SaaS data held outside the provider
Old data resurfacing	data retained far beyond its purpose is found and abused later	retention limits applied automatically, with a documented legal hold override

Key takeaways

Classification first, or nothing else works. A label that does not imply a handling rule will not be applied, and every later control depends on it.
Encryption protects confidentiality, not availability. It saves you from a stolen disk and does nothing about ransomware encrypting your live files.
Ransomware defeats backups by deleting them, not by encrypting them. Separate credentials, immutability — an offline copy is the one the attacker cannot touch.
The RPO and RTO conversation is a business conversation. Ask how much data and how much time, then design backwards to the backup frequency.
Only a restore is evidence. Until someone has restored a file, a service and a machine and written down the time, you have backup jobs, not backups.

Check yourself

Why does full-disk encryption not prevent ransomware from encrypting the files on that disk?
An attacker takes over a domain administrator account. What decides whether they can also destroy your backups, and what should you have configured in advance?
Your stated RPO is one hour and your backups run nightly. What is the actual business impact, and what are your two options?
Give three things organisations routinely forget to back up besides user files.
You are asked to prove the backups work. Describe what you would do and what you would record.