Deploying AWS Backup

tl;dr - here is a link to the scripts

What Ransomware in AWS looks like

In a typical ransomware attack, a threat actor will attempt to encrypt files on critical machines belonging to the victim. In exchange for a cryptocurrency payment, the threat actor will provide the decryption key and software to the victim, who then has to go through the arduous process of restoring their machines. The encrypted data is typically lost forever if the victim refuses to pay the ransom.

Typical ransomware incidents leverage a known attack pattern. The threat actor is typically financially motivated and scans the internet for likely targets. Once a foothold has been established in the victim’s network, Microsoft Active Directory spreads the ransomware software via domain admin privileges.

Cloud-based Ransomware attacks tend to follow a different attack pattern. Active Directory is not typically deployed in AWS. Compute workloads are ephemeral and easy to recreate. Critical data services are often decoupled from the compute workloads and kept in cloud-provider-managed services like S3 and RDS. There have been no instances of ransomware compromising a cloud providers’ systems that store and service customer data.

Typical cloud ransomware attacks follow a pattern similar to the CodeSpaces attack in 2014. An attacker gains access to AWS credentials in some fashion. The credentials either already have the necessary permissions or are used to find other credentials with the necessary permissions. At that point, the threat actor can commence its attack. Re-encryption is seldom used because it is time-consuming and noticeable to the victim. Instead, the threat actor downloads the data (or lies about downloading the data), deletes your copy, and then demands a ransom to get the copy back.

How to protect yourself

A ransom attack on AWS typically involves an attacker getting credentials, maybe exfiltration, and then deleting critical data. The two mitigations are 1) don’t allow credentials to be leaked and 2) don’t allow the leaked credentials to delete all copies of the data. This post focuses on the latter solution.

Enter AWS Backup

AWS Backup is a cost-effective, fully managed, policy-based service that simplifies data protection at scale.

Backup Policies instruct the service to store copies of critical data in Backup Vaults. The Backup Policies can leverage tags to determine what to back up, how often, the retention period, and which vault to place it in. For extra redundancy, these backups (called Restore Points) can be copied to a second region for an additional cost.

AWS Backup Policies can be applied via AWS Organizations, ensuring a backup policy applies to the entire organization.

AWS Backup supports the following resource types:

• EBS & EC2
• RDS & Aurora
• S3 (See caution below)
• DynamoDB
• Elastic File System (EFS)
• Amazon FSx
• Redshift
• Timestream
• DocumentDB
• Neptune

AWS Backup for Amazon S3 makes an entirely separate copy of the data, incurring duplicate charges for the data. I don’t recommend doing this; there are other protections for critical S3 data.

Each resource type must be enabled for it to be backed up. You can do that in the AWS Console for the AWS Organizations Management Account. Per AWS:

If a member account’s backup plan was created by an Organizations-level backup policy (with an ID starting orgs-), the AWS Backup opt-in settings for the Organizations management account will override the opt-in settings in that member account, but only for that backup plan.

This means you can prevent accidental backup of AWS S3 (and the double cost) by only opting in the key resource types you want to protect. Note - You must do this in all regions.

Enter the pht-awsbackup-management solution

The pht-awsbackup-management repo contains a handful of automations to quickly deploy an organization-wide backup schema that is generally ransomware-resistant. This solution leverages three aspects to provide a “paved road” experience for protected backups. The solution consists of:

1. AWS Backup Policies (as terraform).
2. An AWS Service Control Policy (as terraform) to protect the Restore Points and Vaults.
3. A CloudFormation StackSet to deploy the backup vaults the backup policies expect.

Once deployed, all a user needs to do is tag their resources, and they’ll be backed up with the appropriate frequency, redundancy, and retention.

The Backup Vaults are created with Vault Lock enabled in governance mode, so you are not obligated_ to retain the backups for the entire retention period. Service Control Policies are in place to prevent the alteration of the vaults or deletion of the restore points.

Using Cloudformation Stacksets, AWS Backup backup vaults are created in every account in the protected regions. These vaults have a Vault Lock enabled to prevent the deletion of backups before their expiration date.

AWS Backup policies are applied to all member accounts via the Organizations Management Account. These policies align with the four BCP tiers defined below. Additionally, a Service Control Policy is applied to all accounts that prevent the alteration of the Vault Lock settings or deletion of the backups in each of these vaults.

To delete a backup (known as a recovery point), the SCP would need to be disabled by an organization’s management account administrator. This would require an attacker to compromise multiple accounts to delete your data.

How to leverage this solution

The automated backup and protection of critical data is based on simple tagging. If the tag aws_backup_bcp_tier is applied to a database or EBS volume, it will be automatically backed up based on the tag’s value.

none is also an option. The resource is not backed up, but the resource has been reviewed.

Cost Implications

AWS Backup uses incremental backups for each recovery point. This means that while you might back up a 100 GB database 24 times a day, the incremental cost of each backup is the amount of data that has changed over the course of a day, not 2.4TB.