80% of orgs that paid the ransom were hit again

Re:80% of orgs that paid the ransom were hit again by failwhaleshark on Friday June 18, 2021 @08:59PM (#27556816)

Untested backups and DR/BCP procedures aren't backups.

Snapshots aren't backups.

Backups that aren't physically-isolated, typically offsite, aren't backups.

[ Parent | on HN ]

Re:80% of orgs that paid the ransom were hit again by bottled_poe on Friday June 18, 2021 @11:11PM (#27557396)

Well then, It’s starting to sound like backups aren’t what a business needs.

[ Parent | on HN ]

Re:80% of orgs that paid the ransom were hit again by des1nderlase on Saturday June 19, 2021 @02:30AM (#27558289)

Backups are there to provide a business continuity in wide range of disruptions. What you want to protect your business from is up to you, but typically you need protection from all things OP mentioned.

[ Parent | on HN ]

Re:80% of orgs that paid the ransom were hit again by VendorManager on Sunday June 20, 2021 @02:06AM (#27567567)

Backups and disaster recovery sites are definitely important from business continuity perspective, but there is a bigger risk of leaking PII and other sensitive information such as SIN / Social security numbers if the software vendor has access to it. Your business might be able to recover from backup if the hacker has not encrypted it, but the hacker for sure will be maliciously using the PII information to send phishing emails.

[ Parent | on HN ]

Re:80% of orgs that paid the ransom were hit again by failwhaleshark on Monday June 21, 2021 @12:14AM (#27576260)

These are somewhat orthogonal issues.

1. Test and encrypt backups.

2. Don't get hacked. Defense-in-depth philosophy and rigorous, routine social-engineering training/testing. If you get hacked, it's usually game over. Defend systems like the business depends on it because it does.

3. Limit exfil: extra security for PII, exfil detection, and [HN]I[DP]S.

[ Parent | on HN ]

Re:80% of orgs that paid the ransom were hit again by arendtio on Sunday June 20, 2021 @02:54PM (#27572893)

Please define snapshot.

I suspect you mean filesystem snapshots and as long as the snapshot lives on the same physical media you are correct. But when you take the snapshot and transfer it to a physically separate location where it cannot be altered it sounds like a backup to me.

[ Parent | on HN ]

Re:80% of orgs that paid the ransom were hit again by failwhaleshark on Sunday June 20, 2021 @11:51PM (#27576143)

Physically-separate location or not snapshots that can be added, updated, culled, or deleted by local systems aren't backups, they're replication. Replication replicates problems.

Vaulted offsite on at-rest storage media is the only valid way to store backups. Every other "convenient" "backup" service or snapshot replication process is a liability businesses must avoid. Lose all your data, 50%+ you're out of business, and The End.

[ Parent | on HN ]

Re:80% of orgs that paid the ransom were hit again by etherael on Saturday June 19, 2021 @01:37AM (#27558071)

Why are offsite write only continuously incremental snapshots from a full start not backups?

[ Parent | on HN ]

Re:80% of orgs that paid the ransom were hit again by des1nderlase on Saturday June 19, 2021 @02:27AM (#27558274)

"Off-site write only continuously incremental snapshots from a full start", that can be interpreted as a backup strategy (i.e. a DB would do something like that with full/diff/log backups), but you just changed what snapshots means.

What OP tried to demonstrate that backups need to protect from bad changes, on physical, logical, and business layer, from data corruptions to 'oops' scenarios (i.e. drop table). Standard snapshots for sure don't protect from all those.

Also for a good backup strategy, you need - "a full start" once in a while, because corruption in "full backup" will invalid all incremental snapshots - regular restore of a backup for e2e validation

[ Parent | on HN ]

Re:80% of orgs that paid the ransom were hit again by etherael on Saturday June 19, 2021 @05:44AM (#27559179)

Alright, was curious as this is how I have been handling my third layer of backups for quite a while now, regular incremental encrypted zfs snapshots to an offsite storage provider using API keys that only have write priveleges. Wanted to make sure it wasn't something about "snapshots" which made this a bad idea in a way I hadn't thought of. Doesn't seem that's the case.

[ Parent | on HN ]