The backups had run every night
for three years.
They were monitored.
Somebody had actually restored one,
on purpose, to check.
None of that helped,
because the copies were deleted
eleven minutes before
anything else happened.
Think about who can remove them.
The job that writes your backup
holds a credential.
That credential can almost always
list the copies,
overwrite them,
and delete them,
because that is how retention
was implemented.
So the thing protecting you
is reachable from the thing
you are protecting yourself against.
This is not bad luck.
It is the first move.
Nobody encrypts a company
that can restore by lunchtime.
The copies go first,
then the demand arrives,
and the order of those two events
is the entire business model.
Now count your blast radius honestly.
The snapshots sit in the same account.
The console that manages them
is behind the same sign on
that was just taken.
The second region is a different building
and the same identity.
The documentation for restoring
lives in the system
that is currently encrypted.
One compromise reaches all of it,
and you had drawn it in your head
as several separate things.
So make one copy
that your own infrastructure
cannot reach backwards.
A separate account,
with credentials that exist
nowhere in your pipeline.
Write once, and mean it.
Object lock, or an appliance,
or a disk somebody carries,
with a retention window
that cannot be shortened
by anyone who is logged in today.
Different identity provider,
so the same stolen session
does not open both doors.
Then rehearse the bad version.
Not the restore you have practised,
where you have your laptop,
your password manager,
and a working network.
The one where your identity provider
is the thing that is gone,
and you need to know
who holds the credential,
where it is written down,
and how long the copy takes to come back.
A backup you can delete
from the machine that got taken
is not a backup.
It is a copy,
sitting inside the same fire.
– Serguey Asael Shinder
Top comments (0)