ExaGrid Retention Time-Lock for Ransomware Recovery

Ransomware attacks are on the rise, becoming disruptive and potentially very costly to businesses. No matter how meticulously an organization follows best practices to protect valuable data, the attackers seem to stay one step ahead. They maliciously encrypt primary data, take control of the backup application and delete the backup data.

The challenge is how to protect the backup data from being deleted while at the same time allowing for backup retention to be purged when retention points are hit. If you retention lock all of the data, you cannot delete the retention points and the storage costs become untenable. If you allow retention points to be deleted to save storage, you leave the system open for hackers to delete all data. ExaGrid’s unique approach is called Retention Time-Lock. It prevents the hackers from deleting the backups and allows for retention points to be purged. The result is a strong data protection and recovery solution at a very low additional cost of ExaGrid storage.

ExaGrid is Tiered Backup Storage with a front-end disk-cache Landing Zone and separate Repository Tier containing all retention data. Backups are written directly to the “network-facing” (tiered air gap) ExaGrid disk-cache Landing Zone for fast backup performance. The most recent backups are kept in their full undeduplicated form for fast restores.

Once the data is committed to the Landing Zone, it is tiered into a “non-network-facing” (tiered air gap) long-term retention repository where the data is adaptively deduplicated and stored as deduplicated data objects to reduce the storage costs of long-term retention data. As data is tiered to the Repository Tier, it is deduplicated and stored in a series of objects and metadata. As with other object storage systems, the ExaGrid system objects and metadata are never changed or modified which makes them immutable, allowing only for the creation of new objects or deletion of old objects when retention is reached. The backups in the Repository Tier can be any number of days, weeks, months, or years that is required. There are no limits to the number versions or length of time backups can be kept. Many organizations keep 12 weeklies, 36 monthlies, and 7 yearlies, or even sometimes, retention” forever”.

ExaGrid’s Retention Time-Lock for Ransomware Recovery is in addition to the long term-retention of backup data and utilizes 3 distinct functions:

• Immutable data deduplication objects
• Non-network-facing tier (tiered air gap)
• Delayed delete requests

ExaGrid’s approach to ransomware allows organizations to set up a time-lock period that delays the processing of any delete requests in the Repository Tier as that tier is not network facing and not accessible to hackers. The combination of a non-network-facing tier, a delayed deletion for a period of time and immutable objects that cannot be changed or modified are the elements of the ExaGrid Retention Time-Lock solution. For example, if the time-lock period for the Repository Tier is set to 10 days, then when delete requests are sent to the ExaGrid from a backup application that has been compromised, or from a hacked CIFS, or other communications protocols, the entire long-term retention data (weeks/months/years) is all intact. This provides organizations days and week to identify that they have an issue and restore.

Data is time-locked for a policy set number of days against any deletion. This is separate and distinct from the long-term retention storage that could be kept for years. The data in the Landing Zone will be deleted or encrypted, however, the Repository Tier data is not deleted upon an external request for the configured period of time – it is time-locked for a policy set number of days against any deletion. When a ransomware attack is identified, simply put the ExaGrid system into a new recover mode and then restore any and all backup data to primary storage.

The solution provides a retention lock, but only for an adjustable period of time as it delays the deletes. ExaGrid chose not to implement Retention Time-Lock forever because the cost of the storage would be unmanageable. With the ExaGrid approach, all that is needed is up to an additional 10% more repository storage to hold the delay for the deletes. ExaGrid allows the delay of deletes to be set via a policy.

Deletion Protection of Backup Data on ExGrid

Data is deleted in the ExaGrid disk-cache Landing Zone via the backup application or by hacking the communication protocol. Since the Repository Tier data has a delayed delete time-lock, the objects are still intact and available to restore. When the ransomware event is detected, simply put the ExaGrid in a new recover mode and restore. You have as much time to detect the ransomware attack as the time-lock was set for on the ExaGrid. If you had the time-lock set for 10 days, then you have 10 days to detect the ransomware attack (during which time all backup retention is protected) to put the ExaGrid system in the new recover mode for restoring data.

Encryption Protection of Backup Data on ExGrid

Data is encrypted in the ExaGrid Disk-cache Landing Zone or is encrypted on the primary storage and backed up to ExaGrid such that ExaGrid has encrypted data in the Landing Zone and deduplicates it into the Repository Tier. The data in the Landing Zone is encrypted. However, all previously deduplicated data objects never change (immutable), so they are never impacted by the newly arrived encrypted data. ExaGrid has all previous backups before the ransomware attack that can be restored immediately. In addition to being able to recover from the most recent deduplicated backup, the system still retains all the backup data according to the retention requirements.