You Just Got An AWS Security Audit… Now What?

You Just Got An AWS Security Audit… Now What?

So, you successfully ran Trusted Advisor, Scout2, Access Advisor, or hired an external firm to audit your AWS accounts. You found that the co-founder is still logging in using root keys and that you have security groups allowing 0.0.0.0/0 access from the internet. Not to mention the 20 developers offshore that are sharing the same IAM user and access keys. Oops! Now what?

The obvious answer is to remediate those items. Great, we’re done!

Uhh… not quite. Knowing is half the battle. Fixing is 10%. Making sure it doesn’t happen again is the other half of the battle(aka Security Maturity).

And it’s sometimes a real battle for sure. It’s about disseminating a culture that it’s not OK to share accounts. It’s about educating your users on WHY and what THEIR role in security is.

So back to your AWS accounts. What can you do to prevent such findings in the future?

IAM, IAM, IAM

There are several things you can do to improve the security posture of your company. In fact, here’s a list for you to follow of preventative controls designed to stop bad things from happening. Following it will arguably make your security 50% better in terms of cloud security!

Lock down on who has access to IAM

In the cloud, the front door is not the network, but IAM. Limiting who has access to create users and keys will decrease the likelihood of rogue access. It is also important to educate those who have IAM access to prevent abuse or any issues from occurring.

Every person should have a separate IAM user account

If they have a heartbeat, they should have their own account and password that only they know. You may be tempted to make separate accounts with the same password, but avoid doing that, too. Shared passwords are bad in and of themselves. Read my article on why shared passwords are bad here.

Enable 2FA for everyone.

Yes, everyone. Start with your admins. AWS now supports Yubikey. If you need a software that will help you out, check out auth0. Here’s my friend Corey Quinn‘s take on it too.

Get rid of the root account

Enable 2FA, delete any access keys, and lock the creds in a safe. Some argue to delete the account altogether, especially if you have enterprise support. Here are the only tasks that require a root key.

Onboarding and Offboarding Hygiene.

Make sure that when users leave, their accounts and keys are disabled. Utilize SSO for console and CLI access if you can to centralize access. There are so many 3rd party options in this space these days; we’re quite lucky. HashiCorp Vault is one of them.

Utilize role-based access for EC2

This reduces the need to issue access keys for services running on EC2.

Logging

Next (or first depending on your situation) is to find out all the “unknown unknowns.” You can’t fix what you don’t know is broken. You can’t justify your actions if you don’t have data to prove it. Also, you need to have enough logs to find out the Who, What, Where, and How of a security incident should it ever happen to you.

Here is a list of things to help you out:

• Consolidate your CloudTrails. Create an AWS account for logs and security tools with access limited to a few security folks. Create an S3 bucket for your CloudTrails and point all of them to this bucket and start sifting.
• VPC Flow Logs. Back in the day (like a few months ago!), it was complicated to get flow logs to an S3 bucket. Now, it’s ridiculously easy. Create a bucket in your security account and point all your flow logs there. Starting mapping.

Continue adding and centralizing your logs and find a SIEM or log aggregator you’re comfortable with to ingest the data. This is the detection part of security: knowing what is going on in your environment.

Automated Security

Once you have some security maturity and hygiene to your cloud accounts, you can start automating some tasks. This may be considered advanced by some, but I encourage you to tackle this sooner than later as it will pay dividends right away!

• Remove unauthorized security groups. Did someone create an unauthorized 0.0.0.0/0 security group? Delete it.
• Remove unauthorized access keys. Not expecting to have long term access keys in your environment? Remove them!
• EC2 Instances without roles attached to them? You got it: terminate them!

These are corrective controls that will fix bad things before they become worse. If you’re interested in a tool to help you out, Cloud Custodian by Capital One is an open-source tool that can help automate some of these tasks.

Conclusion

These are just a few ways to dramatically improve your AWS Security Posture. Implementing all of the above will require a culture change. It will require hand holding, guidance, and good bedside manners (emotional intelligence). Take small steps and get some wins behind you, and build momentum from there! For more information and a comprehensive list of controls, refer to the CIS Benchmark on AWS or other online resources.

If you’re feeling overwhelmed in securing your AWS environments, contact me at ayman@cloudsecuritylabs.io.

Cloud Responsibly!

This article first appeared on LinkedIn on October 17, 2018.

If this article was helpful to you, consider subscribing to my weekly newsletter, where I share my latest commentary as a vCISO for high growth startups.

Check out how we help startups accelerate and level up their security programs through vCISO (CISO As A Service).