Implement and test backups
After an incident, restoring your data from backups is often the best way to return to business as usual. Performing and testing backups often will help prevent the loss of data in the event of an incident.
CERT NZ had over 80 reports of malware incidents and over 50 reports of ransomware incidents in 2017. Some popular campaigns, like WannaCry, affected many people around the world.
Even with other security controls in place, sometimes incidents still happen. Malware is always evolving, and it could take advantage of a gap in your security to infect your devices. If a device is infected, an effective way to recover is to restore from a backup.
There are several important factors in creating effective backups. These include automatically running them to a schedule, testing them, and storing them offline in a secured location.
Organisations have effective backups available when they’re needed. As a result of implementing this control, their backups:
- include all of their datasets
- are done at a frequency that suits their business needs
- are able to be restored within the limits decided by the business needs
- are tested regularly.
How often your data is backed up, what kind of data is backed up and where back-ups should be stored depends on your organisation. 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.
- Backups are performed automatically and regularly. The schedule is 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 backup takeaways
Are an effective control for recovering from an incident. A backup strategy needs to be done 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 that data you can afford to recreate. This determines how frequently the backup for that set of data needs to be done. Decide 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. This retention policy will vary for each data set.
Test backups frequently and in different ways. We recommend restoring a single file often, and a full system restoration every couple of months. During an incident is not the time you want to find out that your backups are out of date or that the file is corrupted.
Follow the 3-2-1-1 backup strategy. Have three copies of the data, keep them on two different formats, store one offsite, and store one offline.