SECURITYATLAS✳

✳ Misconception M7 / F6

A backup on a writable share is not a restore plan

A nightly backup written to a storage target that the production service identity can also overwrite or delete is a second victim of the same intrusion, not a recovery plan.

Wrong claim

Why it feels true

Seeing a green 'Nightly Backup Succeeded at 02:00 UTC' notification makes operators assume the system can survive ransomware.

Precise correction

NIST CSF 2.0 (CSWP 29, final 26 February 2024) defines the Recover function around the outcome of restoring impaired assets and operations with verified integrity, not merely running a copy script.

If an attacker compromises a production workload identity that holds write or delete permissions on the backup destination, ransomware will encrypt or purge the backups right alongside live data.

A real recovery plan requires an immutable (WORM) or cross-account isolated backup that production credentials cannot alter, a named recovery owner, and dated restore drills proving the team can meet its Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

NIST CSWP 29: The NIST Cybersecurity Framework (CSF) 2.0, final 2024-02-26 ↗

MINI-CHECK

Ransomware hits the cloud staging bucket where Meridian's nightly telemetry archive lands. Satellite pass schedules are generated from those archives. Historical archives sit under the same bucket prefix, and the compromised export service account has s3:PutObject and s3:DeleteObject across the entire bucket. Engineer Devon claims recovery is simple because the 02:00 UTC backup job succeeded before the alert. How should Priya Nair and Maya assess the state?

Go deeper

Find your next idea.

Tip: press / to open search. Escape closes this window.