Proper security configuration and vulnerability monitoring of AWS accounts is vital in today’s world. By making sure that you have configured CloudTrail successfully, ingesting the logs, and attaching actionable alerting and monitoring, you are able to leverage it to dramatically improve your security posture.
This second post of the series (see Part 1) will describe how to verify your CloudTrail configuration and how to monitor your CloudTrail using CloudCheckr. The third post in the series discusses using CloudTrail to alert upon and investigate suspicious activity.
CloudTrail provides activity monitoring capability for the AWS management plane. CloudTrail records every call into the AWS API. Everything done in AWS is accomplished using the API, including when tools such as the AWS Management Console are used. So you can be confident that activities taken in AWS are recorded into the CloudTrail logs.
CloudTrail logs are written into an S3 bucket as JSON files. A separate file is written every five minutes. Additionally, a different file is created for each AWS account and each region. Realistically, looking directly into the CloudTrail files is not a practical task. You need to use a tool to consume and understand what is contained in these files. The CloudTrail UI provides basic functionality to look up events for up to seven days, but undoubtedly you will require access to events from prior periods or more powerful search capabilities.
The first task for security professionals is ensuring CloudTrail is enabled properly. This means ensure it is enabled in all AWS accounts and all regions within those accounts. Note: there is a small marginal cost of using CloudTrail, namely the cost of the storage. You can setup lifecycle rules on the S3 5 bucket to archive to Glacier or delete CloudTrail logs after a period of time to limit these charges. Rarely do these charges exceed a few dollars per month.
It is common for AWS users to setup CloudTrail configuration but enable it ONLY in the regions they are using. It is highly recommended you enable it in every region, whether it is actively used or not. The purpose of auditing is to capture activity including any that is unusual or suspicious. By failing to enable CloudTrail in unused regions, you leave an opportunity for unmonitored activity to occur. There is near zero cost and minimal effort to enable CloudTrail across all regions in an AWS account. As such, it is highly recommended you do so.
Using Best Practice Checks to Verify CloudTrail Configuration
One of the easiest ways to keep track of your CloudTrail configuration is by using the CloudCheckr Best Practice checks. The following are a small sample of CloudCheckr’s pre-built, automated checks:
CloudTrail Not Enabled: Critical. This check will identify if CloudTrail is not enabled at all in an account.
Regions without CloudTrail Enabled: Critical. This determines if one or more regions in an AWS account has not enabled CloudTrail. It is strongly recommended that you enable CloudTrail in every region.
CloudTrail Delivery Failing: Critical. If CloudTrail is enabled, but for some reason it cannot write the file into the S3 bucket, you will not have audit logs. This can happen because of permissions on the S3 bucket, because the bucket is deleted or moved, etc… If you find this anywhere, investigate and fix. Delivery failing is no better than not enabling CloudTrail.
CloudTrail Global Service Events: Critical. You should register one and only one CloudTrail to receive what are called Global Service Events. These are events that are not associated with a specific region. For instance, IAM activity is not regional and needs to be written into a one of the regional CloudTrail logs. If you find an AWS account that has no region configured to write Global Service Events you are missing many critical security events. If you find AWS accounts that have multiple regions with Global Service Events enabled, you will see duplicate events.
CloudTrail Disabled: Critical. This identifies when someone disables CloudTrail. Anytime you see this, you should review who disabled it and ensure it was re-enabled. Disabling CloudTrail is often a hacker’s first action.
Once you have CloudTrail enabled properly, you need to begin monitoring it. CloudTrail logs are valuable for forensic purposes, but it is even more importance to monitor the logs to know when something unusual or suspicious happens.
In order to monitor CloudTrail, you will need to translate the API events into meaningful terms. As you see in the following example, one of the hardest parts of effective monitoring is understanding what to monitor and what it means. AWS often offers multiple events that, from a user’s perspective, have very similar appearing outcomes.
For example, to monitor for security group changes you need to look for 18 individual AWS API events:
CloudTrail Configuration Dos and Don’ts
CloudTrail can require a lot of work to maintain, monitor, and use properly. This is true if you are just beginning with AWS or are a long-time expert user. By using CloudCheckr to provide automated configuration checks and alerts you will save time and avoid the human error aspect of constant manual checks. This still only scratches the surface of how CloudCheckr can help you manage the security of your AWS Environment. Our next post will dig deeper into leveraging CloudTrail for forensic uses and activity alerts.
As always, if you want to experience first-hand all of the features we are talking about, schedule a demo and see how much easier managing your security can be.