Amazon Web Services (AWS) recently announced that it was making the AWS Trusted Advisor S3 Bucket Permission Check free for all AWS users, regardless of their support subscription. While this announcement generated quite a bit of buzz in blogs and the Twitter-sphere, this capability has been free to use in AWS Config’s Public Read Rule for quite some time. However, the Trusted Advisor checks are only one of many tools and practices you should use to secure your AWS environment.
This blog post outlines some best practices you should use to ensure that your AWS accounts and resources are secure. Some are so basic that you may assume that they’re already in use or being done in your environment, but we recommend you do yourself a favor and double check.
Enabling CloudTrail
CloudTrail is basically an audit log of all API activity in a particular AWS account and region. Since AWS is built with an “API first” strategy, this includes all actions performed in the console, command line, and via the API. Examples include adding a user to a group, creating an EC2 instance, and changing the permissions on an S3 bucket. You can immediately see the value in capturing this information. Without CloudTrail enabled, these audit records are pretty much gone.
When you sign-up or create a new account, AWS does not enable this by default, although they should. Regardless, enabling CloudTrail should be the very first thing you do when you create a new account. Make sure that this is done across all regions. If you have existing AWS accounts, confirm that CloudTrail is enabled and if not, do so immediately.
Concerning the multi-region CloudTrail: one thing I frequently hear is, “We only use us-east-1 and us-west-1, so we don’t need to collect logging on that.” While that may be the case, the other “unused” regions are exactly what a bad actor with access to your account is seeking. Ever heard of bitcoin mining?
Um, so what?
Now let’s discuss why CloudTrail is so very important to securing your AWS environment. If nothing else, having the logs and storing them for a period of time in S3 (e.g., one year) really makes a difference if you ever have to go back and research in case of a suspected breach. There is nothing worse than telling an outside party, such as an incidence response consultant, that there are no logs during a particular timeframe simply because no one knew or anticipated that they needed to be enabled. Also, if you’re in a regulated industry, or if you have sensitive data or even customer information, it is a requirement to enable logging. If you are using AWS, this logging requirement means CloudTrail.
CloudTrail logs can also be used to perform near real-time analytics intended to find security anomalies and elevated risk security events. There are various home-grown solutions and vendor-based solutions that monitor CloudTrail events and raise alarms. Our ActiveEye Cloud solution will verify CloudTrail logging is enabled, along with 100+ additional security best practices that are continuously monitored. By the way, ActiveEye Cloud can also detect that nefarious bitcoin mining in unused regions for you by monitoring those logs.
Summary
Enabling CloudTrail in your AWS account is one of the easiest and most important steps to securing your AWS environment. It’s really a no brainer with very little cost. If you don’t need to refer to the logs in the future, awesome. However, if you need them and don’t already have CloudTrail enabled, too late. If you think you might have it enabled but aren’t sure, verify it or ask someone to and see how far back the logs are kept. While you’re at it, make sure the retention period matches corporate policy. If your organization uses multiple AWS accounts, all accounts should be checked and have CloudTrail enabled across all regions.
In the next posting, I will touch on AWS Identity and Access Management (IAM), what to do, and more importantly, what not to do.