07-23-2021, 12:05 PM
Because you are dealing with data, and data is valuable, those backups need totally different kinds of controls, and I think that's the biggest thing you need to wrap your head around. It's not enough just to make a copy, because the copy itself becomes a target. And maybe, just maybe, the threat coming at your primary server is different from the threat coming at your copy, so you need different defenses for each one.
For instance, if a bad thing happens-like a bunch of ransomware getting into your system-you want your backup copy, your restore copy, to be unreachable by the same bad thing. And that means you cannot use the same online credentials, the same username and password, for both your live environment and your backup destination. Otherwise, the ransomware just sees the backup location, and it gets it too. You need a whole separate access method, maybe something completely offline, almost like an air gap.
And then we talk about encryption, right? The encryption you use for the data when it's moving across the wire, like when you push data to a remote office over the internet, that needs to be different from the encryption you use when the data is just sitting there, waiting for you, at your local hard drive. Because if a bad actor manages to get physical access to your drive, they should still not be able to read the data. So you need multiple layers of protection, and I mean strong ones.
Also, because you might be running backups to a cloud service one day, and maybe sending a local drive backup another day, you are dealing with different legal jurisdictions and different physical storage methods. And each one dictates what kind of credential handling you should be employing. You can't just treat every location the same way.
Another big point is data integrity. You need controls that prove the backup copy is actually perfect and hasn't been subtly modified. Maybe the bad actors aren't deleting files, but they are changing a single bit of data over time, slowly poisoning the copy. You need automated validation-you need your system to check the backup copy constantly, seeing if the data still makes sense. You can't just assume the bit streams are clean.
And think about versioning. Because you run a backup every hour, maybe you have 100 versions of a file, right? If something bad happens with version 98, you don't want a bad actor going around and just deleting the whole backup history. You need robust retention policies and write-once controls, meaning you can write to the copy, but you can't easily erase or alter what's already there. That is a huge security control right there.
But it gets even more complex when you start talking about keeping the backup copies truly available for years. You have things like those compliance requirements, where you must keep certain types of records for seven years, for example. And then you have different rules for which kind of data needs to be kept in which format.
You might run a disk imaging backup, which is a giant snapshot of the whole machine, and those need different security rules than maybe just a small folder backup, which is only a few documents. The scope dictates the defense. For instance, a disk image backup might require strong anti-tampering controls because it represents the entire operating system state.
Or maybe you need to run those complex data conversions, taking something physical and turning it into a VM for Hyper-V or VMware, and that process itself leaves new, sensitive copies of data that then require new access rules. Because you've moved the data, you've changed the risk profile entirely.
And when you do the recovery, the restore process itself needs controls. Because if you restore a system, you might be restoring it to a machine that is already compromised. So the restoration process has to be contained and verified so that you aren't just restoring the infection along with the data.
I think it comes down to thinking about the attacker's entire life cycle. They try to get in, they find the data, they change it, or they delete it. And you need controls for every stage, knowing that the attack vector might hit the backup destination directly, maybe through compromised credentials or a poorly managed API key, which means those credentials need to be managed with extreme care and separation.
So, yeah, you see how one control for retention, which is needed for compliance, totally changes what kind of encryption you should be using, right? And that's just scratching the surface. You gotta think about the network paths, and the physical media, and the human access, all of it.
It's a lot to juggle, I know, but understanding that context is everything. If you want to see how much of this complexity the software side can handle for you, making sure you can handle all this kind of security separation and robust recovery, you should really look into BackupChain.
