Does your organization have backups? Many may quickly respond with an affirmative response, but they may subscribe to myths about backups. Someone may say, “Back up their critical infrastructure, check that box, and move on.” When choosing a backup solution, method, and configuration, it’s crucial to make the right considerations.
Critical Foundation: Separation of Control
Who possesses the authority to access your backup data? From which location is your backup data accessible? Who or what has the ability to modify your backup settings or timelines? Who or what could delete backup data?
These questions highlight a significant issue with backups. The systems and backups should be managed independently. However, what does this mean? Here’s an illustration to better visualize the concept.
Illustrative Scenario: Ready2B Hacked
Your workplace, called “Ready2B Hacked”, has one server, named CRITICAL SERVER, which holds all important company information. Your backup solution operates like so:
You login to CRITICAL SERVER, launch the backup software, and manage the backups for CRITICAL SERVER. You can customize your backup schedule, select the volumes to back up, and determine the frequency and timing of the backups. Additionally, you have the ability to perform various administrative tasks and it’s very convenient… for now!
You even have a recurring task on your calendar each week to go check that backups are running successfully. Are your backups running? Does the backup software confirm successful completion during your weekly checks? Are you prepared to restore quickly and effectively for any incident an attacker may cause?
What you didn’t know is that an attacker has gained access to your network via CRITICAL SERVER 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.
The attacker has changed the encryption key used to store your backups. Backups are working, but you can’t restore them because you don’t have the right encryption key anymore.
You effectively have zero backups and, guess what, the attacker just deployed the payload… RANSOMWARE! You receive a warning, follow your plan, check your recovery plan, and realize you have no backups. The only choice is to pay the ransom to restore everything.
Ready2B Hacked is in a very serious situation now – the company may not survive. They need to consider the morality of their only option to resolve the situation: paying the ransom. This act of paying the ransom contributes to the support of ransomware.
Myth Debunked: Sync Solutions ≠ Backup
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. When the attacker hacked the server “CRITIAL SERVER”, they also gained access to the backups for that server. Your backup solution should include separation of these functions.
We discussed separating backup control from system control for better management. Now we will look at services that say they have backups or use the word “backup” too loosely.
File Sync vs. True Backup
File sync and share solutions are not backup solutions. Having your files stored in the cloud does not automatically equal having backups. Furthermore, your file sync and share solution that labels some of its functions as “backups” may also not truly equal backups.
If you’re utilizing a cloud file sync and share solution such as Dropbox, Box, OneDrive, or SharePoint, you may falsely believe your files are stored in the cloud and, therefore, are backed up.
It is very easy to confuse the concept of sync/share solutions with the concept of backup solutions. Even so, two very distinct purposes created them. File sync and share solutions sync files between devices, allow access from multiple devices, and enable collaboration and sharing easily. Backup solutions protect and store data, making it possible to recover and restore it when needed.
Syncing is a process where multiple devices and users exchange changes to files. The sync software ensures that these files stay updated and consistent across all devices and users. When syncing, any unwanted changes will sync to the cloud and other devices which includes files being encrypted by ransomware. This can actually help the ransomware spread.
Backups are like a one-way process. Backups are a one-way process. They take data from a certain time and save it somewhere else. This allows the data to be used for recovery in the future.
Input is not being taken from multiple locations. It has a single source of authority for the data it is protecting and makes a copy/duplicate of that data to a separate location. If files are encrypted by ransomware, those files simply get backed up as well, the previous backups of the data are not affected.
Harmonizing Sync and Backup Strategies
A cloud file sync and share solution can help you restore a file to its previous state in certain situations. For instance, if a colleague recently edited an Excel spreadsheet, the complex formulas may not work correctly anymore. The following day, you notice the issue. You then utilize your sync/share solution to revert to the previous version of the file.
You may be thinking “that sounds a lot like a backup, doesn’t it?” Yes, it sounds like that, but it’s mainly because of versioning, not a proper backup and recovery system.
Using a sync and share solution for data recovery in a real incident response scenario takes more time and effort. This is in comparison to using a backup solution specifically designed for restoring data in such situations. Versioning has its limitations.
Given their differences, file sync and share solutions pair well with backup solutions and can live together in harmony. You have set up file syncing and sharing for everyday tasks and occasional version reverting.
You can store and sync your data to the cloud and back it up with a dedicated service. This makes it easier and faster to restore your data if something bad happens. Just remember that important backup rule we talked about: keeping the control of backups separate from the control of the systems being backed up.
Lastly, depending on your cyber insurance policy or carrier, you may not truly meet the expectations of the carrier by checking the “yes” box next to the “Do you have a backups of your data?” question; potentially opening your organization to risk by way of the carrier denying your claim after finding that you only had versioning capabilities through your file and sync solution but not any true “backup” solution.
One of the most devastating positions to be in is one in which you are reliant upon your cyber insurance kicking in to offset the cyber incident costs only to find out that the claim has been denied due to an incorrect answer within your attestation/application.
Backup and Disaster Recovery Planning
Now we take a step back into the backup planning phase and cover two critically important aspects of your backup plan: RTO and RPO
RTO stands for Recovery Time Objective and is a measure of how quickly after an outage a service must be available again. This is basically an indication of how quickly we should be able to get services/operations back online after a disaster event/incident.
RPO stands for Recovery Point Objective and refers to how much data loss your service(s) can tolerate. This is an indication of how frequently you can backup data.
An easy way to think of these two components is on a timeline – see below.
It’s easy to fall into the trap of simply stating that your RTO is 15 minutes and your RPO is 10 minutes (those are pretty extreme values, by the way). Everyone wants to be able to restore as quickly as possible (RTO) with as little data loss as possible (RPO) but for most organizations that’s not nearly specific enough, not realistic, and is also not economical. You must list out your critical services and put thought into each service and determine what the objectives for each truly are; there should be an RPO and RTO target set for each service listed.
Two major factors that play into these decisions include costs and risk tolerance. For each service you must categorize criticality and make decisions involving how much risk your organization is willing to tolerate as it relates to downtime and data loss. You need to determine how often you will conduct disaster recovery testing and the scope of those tests. The lower you set RTO/RPO targets and the more frequently you perform testing, the more expensive your backup and recovery solution becomes. Below you can see a diagram that outlines this principle; the closer you get to the center, the more expensive your solution becomes.
