Understand the data in your environment
Even with other security controls in place, sometimes incidents still happen. If malware manages to get through and a device is infected, an effective way to recover is to restore from a backup.
Incidents can also be caused by hardware failure, data corruption, user error (deleting files), or natural disasters.
You need to make sure your backups cover all the different systems, databases, and data sets your organisation holds. It is important to note that:
- some of your data will be updated and used more frequently than others,
- some data will be business-critical and can’t be lost, and
- some data will be annoying to recreate if it’s lost.
Deciding the different characteristics of your data will affect the decisions you make about how it’s backed up. How often your data is backed up, what kind of data is backed up and where backups should be stored depends on your organisation.
Begin by reviewing all the different data your organisation has and set backup objectives. A good starting point is to identify the different data types you have. Examples could be:
- customer or staff provided, such as personal details for your employees or customers, or customer account credentials,
- organisation generated, like your financials, operational data, documentation and manuals, or
system based, configuration, system, and log files.
You need to know exactly how important each set of data is and what it’s used for. Find out:
- where the data is generated,
- how often it’s generated or updated,
- where it’s stored, and
- who in the organisation is responsible for it.
The data owner needs to decide how important the data is, and how difficult it would be to recreate it if it was lost. These decisions help set two time-based objectives around recovery, called recovery point objective and recovery time objective.
Recovery point objective
The recovery point objective (RPO) is the time between when the last backup was made and when an incident happens. It’s based on how often the data changes, and how hard it is to recreate it.
The RPO is about how much data you’re willing to risk losing. It helps determine how frequently you perform backups.
Each data set will have a different RPO based on the kind of data it is. For example, the settings in your VOIP system probably don’t change very often. If you needed to remap the phone numbers for each staff member it would be inconvenient but not particularly hard, so you may set a longer RPO. A common default RPO would be one day (24 hours).
If you’re an online sales business, your sales data is very important. If you experience a security incident, you don’t want to have to contact your customers and ask them what they purchased from you. So, that data will have a much shorter RPO. A common default RPO may be too long and you may need one that’s only a few hours.
Recovery time objective
The other objective you need to set is the recovery time objective (RTO). The RTO is the amount of time it takes to get back up and running after restoring data from a backup. It’s used to make a lot of different disaster recovery decisions. For backups, the RTO determines where they’re stored and which media they’re stored on. It also influences what backup model is used.
You will have a shorter RTO for data sets:
- in business-critical systems, or
- around the tasks that you urgently need to do to get your business running again.
Keep multiple backups for this data and include a local copy, for example, in your locked server room. Storing backups offsite, or in the cloud, adds more time to the restoration process. Consideration to different types of backup media should also be given. For example, restoring data from solid state drives will be much quicker than restoring from tape backups.
How to configure backups
Configure your backups based on the data objectives. There are a few settings to consider when configuring your backups:
- Frequency – how often your backups run.
- Type – how much data is backed up (meaning full, incremental, or differential).
- Retention – how long you keep the backups. This may be decided by laws or other regulatory requirements.
- Media – what the data is stored on (such as tape, optical drives, hard drives, or flash drives). Make sure the media you use is designed to meet your retention requirements as storage lifespan varies on different media types .
- Location – where the backup media is stored. This may be on the network, offline and in a locked room, or in cloud storage. Consider the environmental dangers for these locations, like earthquakes.
Be careful of logs that capture sensitive content, like access tokens and personal information. Check to see if you need to record that content. If so, make sure you protect the logs from unauthorised access. Logs produce copies of this information – these should be protected in the same way as the original.
We recommend mixing the components up to follow a 3-2-1-1 model.
- Make three copies of your backup.
- Store them on two different media types (for example, a magnetic tape and an external hard drive).
- Store one copy offsite.
- Store at least one copy offline.
There are different types of media options for storing backups. Choose a media type that considers the longevity of the physical media.
Make sure you’ll continue to have hardware that can access that media, and software that will support the backup format. You’ll need this for as long as you retain that backup.
Some backups are big, and the bandwidth required to perform them on your network may be quite large. If you have frequent, large backups, the backups may overlap. This is where a second backup triggers before the first one finishes. If this happens, discuss it with the data owner so that you can make different decisions about the configurations.
It’s a balancing act between resources available and allowable data loss. Calculate the time, money, and resources required for each backup configuration. You may have to reassess the objectives and configurations to find the right balance. If so, make sure you discuss the RPO and RTO with the data owner.
Processes should be in place to identify and incorporate new systems and data within the backup strategy.
Protect and manage your backups
Some processes and configurations need to be set for backups, regardless of how they’re stored or how often they’re run.
If you need to save time, money, or resources, reconsider the sections above. A failed backup or a backup in the wrong hands can be much worse than a little more downtime when restoring.
Testing
Test your backups so you know you can successfully restore your data. Run multiple types of tests regularly. They should mimic the kind of scenarios your organisation might run into. A few common use cases are:
- a simple file restore – where an employee accidentally deletes a file,
- an application restore – where an application was unsuccessfully upgraded, and needs to be rolled back,
- a database restore – after a database server failure,
- an operating system restore – where an operating system upgrade went wrong, and
- an identity and access system restore – where changes are accidently made to large groups of users and need to be reversed.
Some of these use cases will need to be tested together, like an application restore that also requires a database rollback, for example. This helps you check that the current configurations allow you to meet your objectives.
Protection
Your backups need to be protected from unauthorised access. You can achieve this through a combination of encryption and physical protection.
Encryption
Backups contain copies of your data in several locations, so it’s important to secure them. Backups should be encrypted at rest using a strong encryption algorithm, with a long and unique password. Standard setting bodies, such as the National Institute of Standards and Technology in the United States (NIST), recommend the Advanced Encryption Standard (AES) encryption algorithm and 256-bit keys.
National Institute of Standards and Technology External Link
Physical protection
Just like you protect physical files, you need to store backup devices somewhere safe. Keep them protected from environmental dangers and unauthorised access. Make sure the devices are kept in a secure room or cabinet and protected from dangers like water or heat damage. Heat can lead to increased media degradation. Access to backup devices and data should be restricted to personnel who support the function.
Automation
Configure backups to a schedule so they can run automatically. Automate the entire backup process as much as possible to make sure it happens when you need it to. This could include creating and storing the backups and sending notifications when they start and finish.
Logging and alerts
Alerting on backup logs will help you make sure your backups are running as expected. You can enable an alert when:
- an issue happens during the backup process,
- when backup configurations change, or
- when backup servers are accessed on the network.
These notifications shouldn't happen often. Make sure that an alert initiates an incident response process.
How to measure success
For every organisation the goals are the same.
- The data owner needs to make decisions around the importance of the data and recovery times – these are called recovery objectives. The IT team needs to provide advice on these objectives.
- Perform backups automatically and regularly, on a schedule based on the organisation’s recovery objectives.
- Send alerts for any backup failures to the people responsible for backups and the owners of the data.
- Regularly test the backups using different use cases. For example, test restoring a single file at least once a quarter, and test a full restoration at least once a year.
Key takeaways
- Backups are an effective control for recovering from an incident. You need to have a backup strategy prepared before an incident happens.
- Grouping your data together into types and assigning a data owner can help when making decisions on how you should handle your backups. Decide:
- how much of the data you can afford to recreate. This determines how often the backup for that set of data needs to be done
- how quickly the data needs to be available after an incident. This will determine how and where you store your backups.
- You need to consider how long you want to retain your backups. The retention policy will vary for each data set.
- Test your backups frequently and in different ways. We recommend restoring a single file often and completing a full system restoration every couple of months. You don’t want to find that your backups are out of date or that your files are corrupted during an incident.
- Follow the 3-2-1-1 backup strategy. Have three copies of the data, keep them on two different formats, and store one offsite, and one offline.