3 ms·

> The only thing that “saves” you from paying the ransom is good backups. But if a group is fairly competent, they’ll encrypt your backups too. So it needs to b

> The only thing that “saves” you from paying the ransom is good backups. But if a group is fairly competent, they’ll encrypt your backups too. So it needs to be offline. This is the part I’ve never understood. Surely you should be backing up in an append only fashion initiated from the backup server? My best guess is that this gets managed from AD as well, so they find it and take over?

viraptor 6y ago
This is definitely doable, but it's harder than the naive solution so often it's not done. Same as log storage for example, or any other incremental data. Related - see how many examples of S3 policies split access into read and write rather than read, append, write. It doesn't even matter where the logic lives - only whether the storage service allows you to delete anything.
- user5994461 6y ago
  S3 is easy to handle but not intuitive. S3 always get write access from production systems because gotta be able to send the backup (anything strategy that aims to prevent writing to S3 is doomed). The trick is to get another S3 account (or any large storage really), to download everything from that bucket periodically. The "replication" needs read-only access to the first bucket. The second account doesn't need to be accessed by anything or anybody so it is relatively safe.
  - viraptor 6y ago
    Versioned buckets and denying delete gives you an equivalent of an append-only backup. (As long as your backup tool supports that)
    - user5994461 6y ago
      Until the next developer/sysadmin comes along and update the bucket permissions to be able to send backups from yet another production system. :D
halfcat 6y ago
> Surely you should be backing up in an append only fashion initiated from the backup server The key idea is assuming everything is compromised. Whether you use append or whatever, is not helpful if the functionality to change that configuration exists, because that gets changed, backup server is gone, backup storage is gone, etc. You have to design a system where even a rogue IT admin with full access to everything can’t screw you. Usually that involves third parties where there is no mechanism for a rogue IT person or other attacker to delete your offline backups. So some people have Iron Mountain pick up disks in a lock box daily, or use an online backup service that specifically has features for this, where they keep extra copies of your backups completely offline and provide no mechanism for the customer to delete them.
- rectang 6y ago
  > You have to design a system where even a rogue IT admin with full access to everything can’t screw you. OK, brilliant — this is a nice articulation of a fundamental principle. Do you know of any books that describe how to design such systems? Guaranteeing that offline backups exist is a great start, but if the backups contain backdoors, restoring could be extremely laborious and yet unsuccessful.
- scott_w 6y ago
  I never considered the rogue sysadmin perspective but it’s a good point! I do wonder if some of my misunderstanding is because my experience is mostly SaaS companies, so paying external providers is more “natural” vs a company that makes its money selling units.

viraptor 6y ago

This is definitely doable, but it's harder than the naive solution so often it's not done. Same as log storage for example, or any other incremental data. Related - see how many examples of S3 policies split access into read and write rather than read, append, write. It doesn't even matter where the logic lives - only whether the storage service allows you to delete anything.

user5994461 6y ago
S3 is easy to handle but not intuitive. S3 always get write access from production systems because gotta be able to send the backup (anything strategy that aims to prevent writing to S3 is doomed). The trick is to get another S3 account (or any large storage really), to download everything from that bucket periodically. The "replication" needs read-only access to the first bucket. The second account doesn't need to be accessed by anything or anybody so it is relatively safe.
- viraptor 6y ago
  Versioned buckets and denying delete gives you an equivalent of an append-only backup. (As long as your backup tool supports that)
  - user5994461 6y ago
    Until the next developer/sysadmin comes along and update the bucket permissions to be able to send backups from yet another production system. :D

halfcat 6y ago

> Surely you should be backing up in an append only fashion initiated from the backup server The key idea is assuming everything is compromised. Whether you use append or whatever, is not helpful if the functionality to change that configuration exists, because that gets changed, backup server is gone, backup storage is gone, etc. You have to design a system where even a rogue IT admin with full access to everything can’t screw you. Usually that involves third parties where there is no mechanism for a rogue IT person or other attacker to delete your offline backups. So some people have Iron Mountain pick up disks in a lock box daily, or use an online backup service that specifically has features for this, where they keep extra copies of your backups completely offline and provide no mechanism for the customer to delete them.

rectang 6y ago
> You have to design a system where even a rogue IT admin with full access to everything can’t screw you. OK, brilliant — this is a nice articulation of a fundamental principle. Do you know of any books that describe how to design such systems? Guaranteeing that offline backups exist is a great start, but if the backups contain backdoors, restoring could be extremely laborious and yet unsuccessful.
scott_w 6y ago
I never considered the rogue sysadmin perspective but it’s a good point! I do wonder if some of my misunderstanding is because my experience is mostly SaaS companies, so paying external providers is more “natural” vs a company that makes its money selling units.