Does your organization have off-line backups?
There are many considerations when it comes to choosing a secure offline backup solution, method, and configuration; you want to be sure you are making these important considerations.
Where are your backups accessed from?
Who/What can change your backup configurations or schedules? Who/What can delete backups?
These questions spawn an important fundamental foundation of backups:
Separation between the control of the systems being backed up and the actual backups themselves.
What does this mean?
Here is an example:
An organization you work for, we will name it “ReadyB2B”, has a single server that stores all critical company data; let’s call it THESERVER. Your backup solution operates like so: You login to THESERVER, launch the backup software, and manage the backups for THESERVER. From here, you can configure your backup schedule, what volumes are getting backed up, set the scheduling of when the backups should run / how frequently, among other administrative tasks. It’s very convenient (foreshadowing… security does not equal convenience)! You even have a recurring task on your calendar each week to go check that backups are running successfully. Backups are running, the backup software confirms successful completion of backups during your weekly checks – you are ready to restore quickly and effectively for any incident that an attacker may throw your way – Right?
WRONG!
What you didn’t know is that an attacker has gained access to your network via THESERVER weeks ago and has been lurking, performing recon, and planning an attack. One critical thing that the attacker has done during this time is effectively make your backups useless to you. “But I check them every week and the backup software has consistently reported successful backups!” The attacker has changed the encryption key used to store your backups. This means that backups are still running successfully but if you were to try to restore the backups, you would no longer have the correct encryption key to perform any restoration. You effectively have zero backups and, guess what, the attacker just deployed the payload… RANSOMWARE! You get the alert, you run through your incident response plan, access your disaster recovery plan, and find that you have no backups – the only option for restoration is to pay the ransom.
ReadyB2B is in a very serious situation now – the company may not survive. Not only that, but they must consider the morality of their only remaining option to restore operations; paying the ransom which funds further terrorism. Don’t be like ReadyB2B Pwned; consider this critically important aspect of backups.
To recap, what exactly was wrong with this company’s backup configuration?
The backup solution did not separate command and control of the server from command and control of the backups themselves. Basically, the moment the server, “THESERVER” in our example, was compromised by an attacker, so were the backups for that very same server. Your backup solution should include separation of these functions.
Bottom line: When you make a backup of your critical infrastructure, and enterprise level systems, you must backup all of your databases, and sensitive and personal information, employee information, and scripts, code, assets, etc. and all technologies, into separate backup folders, thus making it easy to backup all of your data, into an offline hard drive, that is not actually connected to the internet. Or your server, or system. This way in the event of any malicious attacks, you can easily and quickly recover your business and processes back to usual.