7 Must-Do Security Best Practices for your AWS Account

Security is like a diet: you always say you're gonna start on Monday, and you never do. Today is the day you start (security, not your diet). And we'll start with that AWS account where you run your whole company but you never bothered to improve security.

You created your AWS account and started building. You got your MVP running, got some paying customers, and things are going well. You always said you'd eventually come back to improve your security, but figuring out how to do it is harder than you thought, and there's always a new feature to add to your product, so you end up saying you'll get on it next week, and next week, and next week.

Today is the day you finally secure your AWS account.

We're going to use the following AWS services:

• AWS Identity and Access Management (IAM): This is where you create users and assign permissions.

• Amazon CloudTrail: Logs everything that happens in your account.

• Amazon GuardDuty: Analyzes the above logs for suspicious activity.

• AWS Billing: Where you see how much money you're spending.

Note: These are for a single AWS account. If you're using an Organization, stay tuned, I'll post a guide for you in the next few weeks

Create a Password Policy for your AWS Account

Passwords can be brute forced. No news there. Yet some people still think they're safe with a 10-digit password that's all numbers. Set up a password policy to prevent IAM users from entering insecure passwords, with a minimum of 16 characters. Here's how:

1. Log in to your AWS account and go to the IAM console.

2. Choose Account settings on the left.

3. In the Password policy section, choose Change password policy.

4. Check your options and click Save.

Create AWS IAM Users

The root user can do everything. If you lose access to it, you're done. So don't share it, and don't even use it! Instead, create an IAM User for every person that needs access to AWS, and only use the root in case of emergencies. You'll be tempted to give Administrator permissions to everyone. Instead of that, check out these example policies by AWS and these policies by asecurecloud and take 5 minutes to build something a bit more restrictive.

(tip for Organizations: Don't use IAM, instead use IAM Identity Center to let one user access all your accounts)

Here's how to set up users:

1. Log in to your AWS account and go to the IAM console.

2. If you decided to set up your own IAM policies (or use the ones from AWS or Asecurecloud), click Policies on the left and click Create policy.

3. Click on the JSON tab, paste your JSON. Click Next: Tags.

4. If you want, enter a tag for your policy. Click Next: Review.

5. Enter a Name and a Description. Click Create policy. Repeat this for all the policies you want to create.

6. Next we're going to create groups for our users You'll want to group them by roles or access levels, for example you could have a Developers group and an Infrastructure group. To do that, click User groups on the left and click Create group.

7. Enter the name, scroll down, and select the policies you want to add (you can use the search box to filter them). Click Create group.

8. Now we're ready for our users. Click Users on the left and click Add user.

9. Enter the user name. If they need access to the visual console (the one where you're doing this), check Enable console access. Most people will need it.

10. If you checked Enable console access, choose either an autogenerated password or enter your own custom password. In either case, check Users must create a new password at next sign-in. Click Next.

11. Select the group or groups (you can pick more than one) to which you want to add this user. If you pick more than one group, the user's permissions will be a combination of both groups. Click Next and click Create user.

12. Copy the Console sign-in URL and send it together with your password to the person this user is for. You can also click the button to Email sign-in instructions.

13. If the user needs programmatic access, on the list of users click on that user, click on the Security credentials tab, scroll down to Access keys and click Create access key.

14. Select your use case, read the alternatives presented by AWS, check that you understand and click Next.

15. Enter a Description and click Create access key.

16. Repeat the user creation process for as many people as you want to give access to your AWS account. Remember, one user per person.

Add Multi-Factor Authentication (MFA) to AWS IAM Users

Multi-Factor Authentication means any agent of evil will need to compromise two authentication methods to gain access to your account. For example, your password and your mobile phone (where you install an app that generates a code needed to sign in). Remember to do this for the root user as well!!

(tip for Organizations: do this for all IAM Identity Center users and for the root of each account)

1. Sign in to the AWS Console

2. Go to the IAM Console

3. On the menu on the left, click "Users"

4. Click on your IAM User

5. Navigate to the "Security credentials" tab

6. In the "Multi-factor authentication" section, you'll see the MFA status. Click on the "Edit" button next to it.

7. Select "Virtual MFA device" and click "Next"

8. Open the virtual MFA app on your phone

9. Choose the option to add a new account (the "+" sign or something similar)

10. Scan the QR code displayed on the AWS console using the MFA app

11. Enter the first code into the "Authentication code 1" field on the AWS console

12. Wait for the MFA app to generate the next code

13. Enter the second code into the "Authentication code 2" field

14. Click "Activate" in the AWS console. You'll see the MFA status change to "Enabled".

From now on, when the IAM user logs into AWS, they'll be required to provide the MFA code from the virtual MFA app in addition to their password.

Enable AWS CloudTrail in your AWS Account

Logs are a record of what happens in a system. AWS happens to be a system. There's this service called CloudTrail that records every action that is taken at your AWS account. Launched an EC2 instance? It's logged here. Changed a security group? Logged here. Logged in with your user from an unknown IP range? Logged here, and you can get notified (more on that next). Event history is automatically enabled for the past 90 days.

(tip for Organizations: You'll want to collect the logs from all accounts and move them to a single account. I'll update this with a guide for that in the coming weeks)

Let's see how to keep those logs forever in an S3 bucket:

1. Log in to your AWS account and go to CloudTrail. Click Create trail.

2. Enter the trail name, such as "all events".

3. For Storage location, choose Create new S3 bucket to create a bucket.

4. For Log file SSE-KMS encryption, choose Enabled, and on AWS KMS alias enter a new name for your KMS key.

5. In Additional settings, for Log file validation, choose Enabled.

6. Optionally, choose Enabled in CloudWatch Logs to have CloudTrail send the logs to CloudWatch Logs.

7. On the Choose log events page, you need to decide what events to log. I recommend the following:

   1. Check Management events and Insights events.

   2. In Management events, for API activity, choose both Read and Write. If you're very short on money choose Exclude AWS KMS events.

   3. In Insights events, choose API call rate and API error rate.

8. Click Next and click Create trail.

Set Up a Distribution List as your AWS Email Address

You know that email address you used to create the account? Probably the CEO's or the CTO's. Turns out AWS sends useful info there. What happens if that person is not available? Create a distribution list (which is an address that is automatically forwarded to many addresses) and add addresses there. Here's how:

1. On Google Worskpaces, go to Directory → Groups.

2. Click on Create Group and enter name, email and description. Click Next.

3. For Access type you probably want to set Restricted, but any will do, so long as External can “contact group owners” (i.e. send emails to that address). Click Create Group.

4. Back on AWS, log in with the root user and go to Account Settings.

5. Change your contact information to a group you just created, and click Save.

6. Warning: If you change the root email address to that of a group, anyone with access to the group can recover the password. This is actually a good idea, but be careful with whom you add to that group.

Configure Amazon GuardDuty

GuardDuty basically scans your CloudTrail events and warns you when there's unusual activity. Cool, right? It's $4 per million events scanned. And you need to enable it in all regions.

Here's how to configure it:

1. Go to the GuardDuty console. Click Get started and click Enable. That's it! Let's explore it a bit.

2. On the left, go to Settings and click Generate sample findings.

3. Go back to Findings on the menu on the left, and check out the [SAMPLE] findings generated. That's what you can expect from GuardDuty (though hopefully not that many!)

4. So, do I need to check GuardDuty every day to see if there's something new? Absolutely not. Let's set it up to notify you on an SNS topic to which you can subscribe a phone number, an email address, etc (I recommend one of the email addresses for a distribution list, created on the recommendation above):

5. First we'll create the SNS topic. Go to the SNS console, click Topics on the left and Create topic.

6. For the Type select Standard. Enter a name such as GuardDutyFindings, and click Create topic.

7. Next we'll subscribe our email or phone to the topic. Click Create subscription, for protocol select either email, enter the email address of one of the distribution lists created above (or create a new one for this) and click Create subscription.

8. Finally we'll need an EventBridge rule to post GuardDuty findings to the SNS topic. To do that, go to the EventBridge console, click Rules on the left and click Create rule.

9. Enter a name such as GuardDutyToSNS, leave event bus as “default” and Rule type as Rule with an event pattern. Click Next.

10. For Event source, choose AWS events. For Creation method, choose Use pattern form. For Event source, choose AWS services. For AWS service, choose GuardDuty. For Event Type, choose GuardDuty Finding. Click Next.

11. For Target types, choose AWS service. On Select a target, choose SNS topic, and for Topic, choose the name of the SNS topic you created 5 steps ago. Open Additional settings.

12. In the Additional settings section, for Configure target input, choose Input transformer and click Configure input transformer.

13. Scroll down to the Target input transformer section, and for Input path, paste the following code:

14. { "severity": "$.detail.severity", "Finding_ID": "$.detail.id", "Finding_Type": "$.detail.type", "region": "$.region", "Finding_description": "$.detail.description" }

15. Scroll down. For Template, paste the following code (tune it if you want):

16. "Heads up! You have a severity GuardDuty finding of type in the region." "Finding Description:" ". " "Check it out on the GuardDuty console: https://console.aws.amazon.com/guardduty/home?region=#/findings?search=id%3D"

17. Click Confirm. Click Next. Click Next. Click Create rule. To test it, re-generate the sample findings from step 2 and you should get an email for each.

18. Go grab a glass of water, a cup of tea or a beer. That was a long one!

Create a Budget in AWS

There's no way to limit your billing on AWS, but there is a way to get notified if your current spending or forecasted spending for the month exceed a threshold. If you're spending $200/month and suddenly you're on track to spending $500 for that month, you'd like to know ASAP so you can delete those EC2 instances that you forgot you launched!

I'd give you a step by step, but I'll do you one better: Here's an in-console tutorial by AWS. Tip: Set a number above your typical spending (including peaks). You don't want to be deleting 10 emails a month, because you'll get used to ignoring them.

Conclusion

Do I need to do all of that? Yes. It's easy (with this guide), it's either super cheap or free, and it's important. You know it's important, or you wouldn't have read this far.

Do I need to do all of that right now? Now That is a good question. The answer is no, you don't. But you've been postponing this for how long? Tell you what, let's compromise: Take each best practice, create a Jira ticket (or Trello, Todoist or whatever you're using to manage tasks), paste the step by step there, and schedule it for some time in this sprint or the next. At least now you know what to do and how to do it.

Recommended Tools and Resources

Wanna get AWS Certified? Adrian Cantrill's courses are the best for that. Wanna learn? Adrian Cantrill's courses are the best for that as well!