3 Steps to Prepare Your AWS Environment for Escalating Cyber Attacks
There’s a lot of discussion on the internet today about a possible increase in cyberattack activity on the heels of the tragic events in Ukraine. While we certainly hope none of that materializes, this is probably a pretty good day to ensure that you’ve got the basics covered for protecting your AWS environments.
Here are 3 essential things you can do today to improve your protection against cyber threats to your AWS environment.
#1 Turn on MFA – Everywhere
Everyone understands that multi-factor authentication is the best defense against a broad range of attacks that leverage a legitimate user’s credentials to illegitimately access an environment. We’re constantly surprised, though, by how many people we see accessing their AWS environments without the benefit of MFA. This is table stakes for protecting your environment.
You should turn on MFA in 3 locations:
- Root User – every AWS account has a “root user,” whose login is an email address provided when the account was created. This user has full permission within your AWS account.
You should not be using this user for day-to-day activities in your account (although we do see a lot of that), and you should be enabling MFA here first. - Console Users – your team members frequently access AWS via a web browser, though the AWS console. They may login directly to the AWS console as an IAM user, or they may login through an SSO solution as an IAM role.
If logging in directly, have your team members log into the console, find their user in IAM, and add an MFA device to their IAM user.
If using SSO, follow the instructions from your SSO provider for enabling MFA for the application that accesses your AWS environment. - Access Tokens – most devops engineers access AWS through scripts and tools that leverage access tokens, generated by AWS, for authentication. This almost always means they’re accessing with the tokens for a specific IAM user.
Turning on MFA for the IAM user does not add a requirement that they provide their second factor when they authenticate with those tokens. This is major hole – engineers typically store their tokens in a well-known location on their workstations, and an attacker or malware that compromises their workstation knows exactly where to look for them.
Turning on MFA for access tokens is a separate step, that is harder than it should be. We have a blog post to describe how it’s done (and how you enforce it).
#2 Enable Security Alerting
It’s pretty obvious that you’d want to get notified if a bad actor compromises your environment. Unfortunately, basic security monitoring isn’t turned on by default in AWS. You can invest a lot of money in acquiring security tools to help here, but the first step is simply to follow the guidance that AWS provides around enabling monitoring and alerting on CloudTrail events.
AWS provides a pretty thorough set of CloudTrail alarms that can be easily setup in your account with a single CloudFormation template. You should install this template today. You may need to pair down some of the alarms if the operations they flag are actually part of your day-to-day activities (the only thing worse than no alerting is noisy alerting). But make sure you retain the alarms around AccessDenied* and *UnauthorizedOperation error codes – those errors should not be a normal part of your operations.
#3 Back-up Data Outside of Your Production Accounts
Most companies focus their backup and DR efforts on accidental data loss and platform outage scenarios. But the most critical disasters to protect from are malicious, like ransomware. If that happens, you could be out lots of bitcoin to recover, or you may not be able to recover at all.
The essential best practice around backups is to store them “air-gapped” so that a bad actor cannot delete them and undermine your recoverability. In a physical environment, you might do that by completely disconnecting them from your network. In an AWS environment, the common practice is to store them in a second AWS account. This account is your “bunker” – nobody is granted access to it, and the attack vectors that allow access to your production environment do not exist here. It’s your last line of defense if it get compromised.
In a perfect world, you’d never need this advice. But as we’re certainly reminded this week, we live in a very imperfect world. Please be safe, and please protect your AWS environments.
About us
Arpio is a leader in automated disaster recovery solutions for Amazon Web Services (AWS) cloud workloads.
