Backup Redesign After a Ransomware Near-Miss at a Charity
An 80-person charity runs an 18 TB file server on-premises. A nightly full backup copies everything to a NAS in the same rack over 1 Gbps; the window is 22:00-06:00 and the job takes about 5 hours 20 minutes. Fourteen daily copies are kept, there is no offsite copy, and restores are never tested. The backup job authenticates with a domain administrator account, and the NAS share is mounted read-write on the file server. NAS administration uses a shared local password with no MFA. The agreed RTO is 8 hours and the RPO is 24 hours. Last month a user opened a malicious attachment; EDR blocked an SMB lateral-movement attempt against the file server, and forensics found the backup account's cached credentials on the infected workstation. Nothing was encrypted, but leadership now wants a written redesign. In the same week a volunteer asked whether the annual accounts are covered by the backup at all.
1. Assess the current design against the 3-2-1-1-0 rule and the stated RTO and RPO.
Read the worked answer
Copies: one production plus one on the NAS, so two copies, both on site, both in the same rack - fire, flood or theft loses both, and a same-room NAS is precisely what ransomware reaches first. The NAS is mounted read-write from the file server under a domain admin account whose credentials were already found cached on a compromised workstation, so an intruder on that host could have deleted the backups before encrypting anything. None of the fourteen daily copies is offline or immutable; all are reachable and deletable at once. Restores are untested, so the 24-hour RPO is an assumption rather than a fact. The 8-hour RTO also fails on arithmetic: 18 TB at a full 1 Gbps is about 40 hours, and realistically longer from a single NAS on a full-only chain.
2. Design a replacement architecture that meets the objectives, and state what must change in the RTO and RPO conversation.
Read the worked answer
Target: daily incrementals with a weekly synthetic full into a hardened on-site repository, replicated off site, plus a monthly offline or immutable copy - that satisfies 3-2-1-1-0. Practical changes: a dedicated backup service account with no domain admin rights, scoped to the file server only and never cached on workstations; MFA on NAS administration on a separate management network; the backup target not mounted on production, so data is pushed through an append-only repository rather than pulled over a writable share; object lock or immutability with a 30-day retention window; a cloud copy of at least the most critical 2 TB; and a quarterly restore test with recorded timing. Then the conversation: 8 hours is achievable for finance and payroll data - tier roughly 1.5 TB first - but not for all 18 TB. Either the long-tail RTO becomes 48-72 hours, or the restore path needs deduplicated incrementals and a warm standby.
3. What are the first 60 minutes if EDR reports ransomware detonation on the file server?
Read the worked answer
Contain before investigating: isolate the server at the switch or with EDR network containment rather than only disabling an account, and stop the backup job so it does not replicate encrypted files over good copies. Take the NAS and any USB media offline physically. Disable the implicated domain admin account, reset its password twice, then audit domain admin membership and scheduled tasks. Preserve evidence - memory capture and EDR telemetry - before any rebuild. Notify per the incident plan, including the relevant regulator if personal data is involved, and engage the cyber insurer's response line early because it usually supplies forensics. Then restore the last known-good copy to an isolated host and prove it works before touching production. The most damaging mistake in this window is bringing the backup target back online and letting the still-running job overwrite clean data.