You own all the risk
Amazon Web Services was first released in 2006, that’s 17 years ago. Yet people a still failing to secure the AWS root account. Some of the biggest offenders are tech companies and personal accounts created by engineers.
At this point, it’s just incompetence. AWS has provided guidance, the industry has shouted endlessly about it, but people keep failing to do the basics.
An Amazon Web Services account can be a critical risk for both personal and business account owners. Some obvious risks are:
You are accountable for the AWS bill
Even if the account was breached. You might not have started the bitcoin farm, but you will have to pay for it.
You are responsible for what is done with your account
Spam, DDOS, proxies etc. Whatever the attacker uses the service for, falls on you.
Some people just want to see the world burn
A breached account is vulnerable to being purged of its services and data. This can happen in minutes and will be all over before you realised it even started. All those EBS snapshots will be for nought if the attacker uses aws-nuke to flush your account.
You can find the AWS Best Practice guide for root credentials here: https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html
It covers the “right” way to do it, but there are additional things you should consider. Have a read below for more details.
Don't be one of these people
Account Details
Before you jump in and update credentials, double-check your account details. If things go to shit, you need these details to be accurate.
I see too many accounts with email contacts set to ex employees or mailboxes that nobody ever checks. Don’t be one of those people.
Personal accounts
- Don’t use your day to day email address for this. If your email account is compromised, it exposes your AWS account to a reset.
- Create another email, dedicated to your AWS accounts
Business Accounts
- Don’t use a staff member’s account. Staff come and go, your AWS account bill is forever.
- Don’t use the CIO/CTO email address. They are busy at offsite’s and will miss critical emails.
- Do create a dedicated email address for each AWS account.
- Do make that email address a distribution list (365 List, Google Group etc) and then add recipients such as the service desk, accounts, security, and engineering teams.
If you want to get fancy, you can create separate distribution lists for the three Alternate Contacts (Billing, Operations Contact, Security Contact)
Phone Number
Make sure the phone number is valid and has a country code. This didn’t use to be mandatory, but it is now.
Personal accounts
Your mobile, not much else to say.
If you change numbers, make sure this is kept up to date.
Business Accounts
Don’t let the tech person/team use their number here. Use either the company landline or senior managers’ mobile etc. You don’t want staff leaving the business and still being the primary contact.
Enable IAM Billing Access
Make sure that you enable IAM user access to billing information. Otherwise, the root account will be required, and that’s what we need to prevent.
You can find the setting towards the bottom of the account details page https://us-east-1.console.aws.amazon.com/billing/home#/account
Budget
Now that you’ve cleaned up the account details, it’s critical to create a budget for each AWS account or the consolidated billing account.
A spike in billing is likely to be the first indicator that your account has been compromised.
If you know you don’t have a budget already, you can click here to create one: https://us-east-1.console.aws.amazon.com/billing/home#/budgets/create
Rather than the default monthly budget, create a custom budget that tracks daily usage. Set the budget amount 50% above your typical daily use and the alert threshold to be 100% of the budgeted amount.
Add multiple people into the email recipient window.
Personal accounts
Add your day to day email and someone else’s if you can. This can help ensure you get the alert.
Business Accounts
Create a distribution list and add the service desk, CISO, CTO etc.
Accounts
Now we have billing alerts, it’s time to lock down the root account
IAM Admin User
If you don’t have one already, create an IAM user who has full admin and billing access. This is the new admin you’ll use to manage the account.
Personal accounts
- Name this whatever you like
- Set a long, complex, randomised password
- Store this password in a password manager
- Ensure the account has MFA enabled
Business Accounts
It is likely a larger business will have some sort of SSO / centralised auth in place, and that’s too complex for this doc. For everyone else:
- Name using the email address of the first admin
Once the user logs in for the first time, ensure they;
- Set a long, complex, randomised password
- Store this password in a password manager
- Enable MFA enabled
Credential policies can add additional security, but that’s a much longer story.
Root Credentials
With at least one IAM admin in place, we can get this root account out of the way.
- Set a new password, a long, complex, random one.
- Store the password in a password manager
- Delete any Access Keys the root account already has
- Enable MFA on the account
- Never use this account again!
Personal accounts
- The easiest MFA option is to use an app on your phone. Make sure whatever app you use has the option to back up onto another device/service.
Business Accounts
- Buy a physical MFA key. Don’t use an MFA app on a staff member’s phone.
- Store the MFA device in a safe or deposit box etc
And you’re done.
Final Thoughts
The fact is, AWS could do more to secure accounts. I suspect the reason they don’t, is because it would inconvenience customers and deter adoption.
The following simple changes would greatly improve security:
- Mandatory MFA on root accounts. Just make it happen, regardless of complaints.
- The root account should have access denied for everything except:
- Billing data
- Set account details
- Create / reset a single IAM user that has full admin and billing access.