Does your organization have backups? Many may quickly respond with an affirmative response, but they may subscribe to myths about backups. One may say that their critical infrastructure is backed up, check that box, and move on. There are many considerations when it comes to choosing a backup solution, method, and configuration; you want to be sure you are making the important considerations.
Who has access to your backups? 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 to help paint the picture.
An organization you work for, we will name it “Ready2B Pwned”, has a single server that stores all critical company data; let’s call it CRITICALSERVER. Your backup solution operates like so: You login to CRITICALSERVER, launch the backup software, and manage the backups for CRITICALSERVER. 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?
As you may have guessed, things are about to go south for you and the entire company at Ready2B Pwned. Let’s continue where we left off:
WRONG!
What you didn’t know is that an attacker has gained access to your network via CRITICALSERVER 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.
Ready2B Pwned 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 Ready2B 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, “CRITIALSERVER” 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.