Ransomware-resistant backups
Page 2 of 3
Principles for ransomware-resistant on premises backups
On this page
- Principle 1: Make it possible to isolate your backup solution
- Principle 2: Update your backup solution
- Principle 3: Backups should be resilient to destructive actions
- Principle 4: Restoration from an earlier backup is possible, even if later versions become corrupted.
- Principle 5: Have in place robust key management for data-at-rest protection
- Principle 6: Alerts are triggered if significant changes are made, or privileged actions attempted
Principle 1: Make it possible to isolate your backup solution
Threat: Leaving a backup solution open for access to both users and devices beyond what is necessary makes it more likely that an attacker can pivot from a compromised device to gain access to backups.
It should be possible to isolate a backup as far as is reasonably practical to reduce the attack surface.
Suggested implementations
-
Put in place network segregation.
By making sure the management interfaces of a backup solution are only accessible from locations where access is controlled, it becomes more difficult for an attacker to locate, access and destroy the media on it. A backup solution should allow the management interface to be separate from the interface used to ingress backup data. Using privilege access workstations firewalls will help achieve this.
-
Air gap.
Storing physically disconnected backup media separately, off the network, makes it more difficult for an attacker to access backups. This can be achieved through both ‘hot’ and ‘cold’ backups where in both cases, backup disks are routinely written on durable media such as magnetic tapes and stored somewhere safe and not connected to a network. When thinking about safe locations, also consider natural disasters such as floods and fires.
-
Apply the principle of least privilege.
To minimise the risk of unauthorised access as a result of changes to staffing and roles, an organisation should regularly review who has physical access to your backup solution, as well as the level of access they have. Do the same for backup media – namely the physical storage device on which the backups are stored.
-
Isolate credentials.
In a ransomware attack, it's common for attackers to discover and then gain access to enterprise admin accounts, allowing them to move laterally through a network. Make sure a backup solution uses admin accounts and credentials that are separate from those used to administer the rest of your network, or for non-admin duties, such as user productivity.
-
Mandate multi-factor authentication (MFA) for requests to alter or destroy data.
Putting in place MFA adds an extra layer of security and means that even if an administrator account is compromised, it still won’t be possible to carry out destructive actions.
Principle 2: Update your backup solution
Threat: On-premises backup appliances and solutions that do not have the latest security updates installed may be vulnerable to attack and undermine security features.
On-premises backups can include both physical appliances and software, both of which offer various security features and functionalities. As with all software, security flaws and vulnerabilities may be present, and vendors have a responsibility to provide timely security updates and mitigations for known vulnerabilities. Your organisation is responsible for ensuring that security updates are installed in a timely manner to prevent exploitation of known vulnerabilities. The NCSC has guidance on vulnerability management, that includes best-practice timescales for applying security updates and updating when exploitation is rife.
You should also consider the underlying operating systems of your backup appliances and software. For a backup appliance, you will need to reassure yourself that the vendor is applying security updates. For backup software installed across the enterprise, it is your responsibility to ensure that the operating system has security updates installed.
Suggested implementations
-
Choose solutions with a support period that meets your requirements.
It should be clear how long a vendor will support a backup solution. Vendors provide security updates and mitigations for products that are still actively supported, as well as best-practice guidance on how to use the product securely.
-
Bring your backup solution under your current patching regime.
Ensuring that your backup solution is up to date with the latest security patches, minimises opportunities for an attacker to compromise them.
Principle 3: Backups should be resilient to destructive actions
Threat: To prevent or slow down recovery from an attack, ransomware attackers may look to destroy backups. A backup solution should therefore be resilient to attempts to destroy the data on it. Backup data should also be protected from malicious editing, overwriting or deleting.
Suggested implementations
-
Block deletion or alteration requests on a backup.
If it’s not possible to alter or delete a backup in any way, an attacker won’t be able to delete data stored on it. Using storage media that is ‘write once, read many’ (or WORM) is one way to achieve this. In practice, backup data can’t be stored forever, so system owners should be able to set policies in advance that specify how long a backup should be kept. This should align with your backup schedule, and may be different for different types of data.
-
Offer ‘soft delete’ by default.
A ‘soft delete’ mechanism flags data as inaccessible, meaning the wider system behaves as if the data has been permanently deleted, while in fact it is still recoverable for a certain period (the ‘retention period'), perhaps in a separate storage area reserved for this purpose. Users and administrators should not be able to delete or overwrite data from the storage area where ‘soft deleted’ data is held.
For this to be effective, it’s important for a system owner to monitor the overall health of the backup system because if an attacker can soft-delete all backup data and the system owner doesn’t notice until after the retention period has ended, this mitigation is not effective.
-
Delay any deletion or alteration requests.
This should be for a pre-agreed time period, depending on your monitoring schedule as system owner. This will only be effective if an alert is also raised, and the system owner is confident that that alert will be successfully delivered, even if the infrastructure is compromised.
Principle 4: Restoration from an earlier backup is possible, even if later versions become corrupted.
Threat: If an attacker can flood a backup store with corrupted backup data, they won’t need to delete the data to make the backup unusable.
The backup solution should therefore allow customers to store backups for a retention period in line with their risk appetite, and system owners should monitor and test the state of their backups regularly. By storing according to a retention period, instead of storing a fixed number of backups, an attacker can't simply overwrite all of your backups with corrupted data by backing up multiple times. It also allows you to back to a backup in time before the attack took place.
Suggested implementations
-
Vendors should provide on-demand ways for system owners to test backups,
including testing whether backup data is corrupted. For this to be effective, a system owner needs to test this as part of a regular monitoring process.
-
Store backup data according to a fixed time period, rather than a fixed number of backups.
This prevents an attacker overwriting the backup store with a series of corrupted backups in quick succession.
-
Create and retain a version history so that a system owner can restore from a version of their choice.
-
Offer flexible storage policies so that a system owner can decide how many backups to keep for different periods of time, according to risk appetite.
For example, this could be keeping daily backups for a month, and monthly backups for a year.
-
Offer alerts and flexible configuration options when approaching storage capacity limits.
To prevent an attacker pushing vast amounts of data to a backup to overwrite ‘good’ data, vendors should offer an option to alert when storage is near or at capacity. This allows a system owner to choose what actions to take once storage limits are reached.
Principle 5: Have in place robust key management for data-at-rest protection
Threat: If data on a backup is encrypted while at rest, it may be easier for an attacker to delete or modify an encryption key, rather than attempt to delete the data on a backup. This makes it important to secure keys used to encrypt data at rest.
Suggested implementations
-
Follow the NCSC
-
Offer an out-of-band key backup option,
such as committing a master key to paper in human-friendly text encoding, or as a QR code, so it can be stored in a secure location.
Principle 6: Alerts are triggered if significant changes are made, or privileged actions attempted
Threat: As targeting a backup system can be a precursor to an attack on an organisation’s main system, an attacker hopes that attempts to compromise a backup won’t be detected.
If an attacker attempts to make changes to an on-premises backup, it should trigger an alert, which then initiates follow-on actions. Alerts are only effective if once triggered, it initiates a follow-on incident management process. The backup solution should offer different ways to deliver alerts so they aren’t affected, even if an organisation's infrastructure is compromised. Changes could include (but aren’t limited to): requests to mass-delete, changes to global retention periods or encryption policies, changes to admin account details, or any other unexpected changes. An alert should be raised whether the attempt is successful or not.
Attackers may carry out their actions during out-of-office hours to reduce the chance of action following an alert. This is why it is important to delay deletion or alteration requests, as principle 3 lays out.
Suggested implementations
-
The backup solution offers a wide range of customisable alerts
for different activities that could impact a backup. For a larger organisation, a security operations centre (SOC) might ingest alerts while for smaller organisations, it could be an automated email to a monitored group mailbox. Alerts for significant changes should be switched on as default.
-
Mandate extra authorisation, such as MFA, for significant changes to a backup.
They should automatically initiate additional protective monitoring. The NCSC guidance on logging and auditing administration activities may be helpful here.
