Securing CloudTrail
Last updated
Last updated
Enabling a trail in your AWS account is a significant first step toward improving observability, but ensuring you have configured it securely is vital. AWS provides several tools to ensure your logging isn’t at risk:
You can enable log file validation on trails to ensure you're confident that logs have not been tampered with after generation. This will allow you to remove elements of uncertainty and help prevent non-repudiation when teams carry out investigations after security incidents.
Logging across all regions will mean you don’t miss any activity in your account. While you and your team may only work in one or two different regions, attackers are likely to disperse their activity across all regions to avoid detection.
AWS automatically encrypts your log files with Amazon server-side encryption. If you want more direct control over the encryption, you can use customer-managed keys with AWS KMS.
Access to the trail, the buckets that store the logs, and any KMS keys you use for encryption should be restricted. Your IAM policies should follow the principle of least privilege, and only those that require access for their roles should be able to view logs.
Searching “CloudTrail” in the top search bar of the console will let you navigate to the CloudTrail console home, where you can select the dashboard (as seen in the image above). If you struggle to view the images, right-click on them and select Open image in a new tab.
From here, you can see the trails currently running in the account for the region you've selected. You should be in the eu-west-1 region for this series, unless otherwise specified. As mentioned in the introduction lab, you will not have access to the event history for this series.
Clicking on a trail will allow you to see its configuration options. This is where you can see various security options for the trail such as:
If the trail is recording multi-region data
Enabling log file validation
Configuring SSE-KMS encryption
Trail log location (S3 bucket used to store the logs)
Clicking on the Edit button will allow you to change these settings.
This is also where you can manage the trail’s functionality by stopping logging, which will stop the trail from delivering logs to the specified location, or deleting the trail, which will remove it from your account altogether. Deleting a trail will not delete log files that are stored in an S3 bucket.
Selecting Create trail from the dashboard will take you through several screens where you can choose the options for a new trail. The first section is General details, as shown in the image above.
You'll need to give your new trail a name. For Storage location, you can either choose to create a new S3 bucket that CloudTrail will set up for you or use an existing S3 bucket. If you choose an existing bucket, you'll need to ensure it has a suitable bucket policy.
CloudTrail will automatically create a path structure in your bucket with prefixes for regions and dates, but you can also add your own prefix. This is useful if you wish to log multiple trails to the same S3 bucket.
You can also enable log-file encryption using AWS’s Key Management Service (KMS). CloudTrail can create a key automatically, or you can specify an existing KMS key that will require a valid key policy for CloudTrail to use.
In this section, you can also turn on log-file validation and Simple Notification System (SNS) notifications.
Trails created via the console are automatically set to be multi-region.
Clicking Next will take you to the Choose log events page. Here you can specify the type of events you want this trail to monitor. There are three options:
Management Events – these are events that occur to your cloud resources. Examples include users creating S3 buckets, a lambda function creating an IAM user, and someone launching an EC2 instance.
Data Events – these are events that occur within specific resources. Only certain services are available as sources for this event type. As an example, for the S3 service, data events would be object-level API activity.
Insight Events – these are events where CloudTrail has determined unusual write API activity for management events.
You can choose a trail to log one, all, or a combination of these options. A comparison of management and data events is available on the AWS Support page
For Management events, you can choose to record either Read or Write events, or both. You can also choose to exclude certain services.
For Data events, you'll need to select the AWS service that will act as the source of these events. You will have various options for each service to refine the exact kinds of events you want to capture. This set of rules for what to capture is known as an event selector. You can name your event selector and have multiple selectors for one trail.
Clicking on Next will take you to the final page, where you can review your settings for the trail and confirm them by selecting Create trail.
Once you have a trail up and running, you can retrieve your log files by navigating to the S3 bucket set as that trail’s log location. Inside the log bucket, the logs use the following file structure:
AWSLogs/<AccountNumber>/CloudTrail/<Region>/<Year>/<Month>/<Day>/<LogFiles>
CloudTrail events can be viewed in the Event history section of the CloudTrail console or within log files retrieved from S3 (in addition to standard CLI, API, and SDK methods). Identifying pertinent information in an event is useful in incident response and investigations to determine user activity.
Event logs are simply JSON-formatted data containing information about a certain instance of user activity. Fields can differ across CloudTrail events, especially within the requestParameters array, because this contains action-specific request parameters. However, there are some core fields present in almost every CloudTrail event that you should recognize and use to extract useful information:
userIdentity: this field contains information on the principal making the API call. This can include:
type: usually an IAMUser or AssumedRole
arn: the ARN of the principal, which is a globally unique identifier for the principal
accountId: the account the principal originates from
eventTime: when the action occurred
eventSource: usually which API the event was generated from, for example ec2.amazonaws.com
eventName: the API call made, such as StartLogging for CloudTrail
sourceIpAddress: the source IPv4 address of the request to the API
userAgent: the agent used to make the request, such as a specific browser, or the AWS CLI
requestParameters: provided parameters, specific to the API call. For example, the ID of the EC2 instance to stop
You can see a truncated example of this below from the AWS CloudTrail user guide:
This api call is requesting “StopInstances”
Creating a new trail Created a new trail in the eu-west-1 region. Caledl it metrolio-s3-trail. Set the log location to be the existing S3 bucket called metrolio-log-bucket-s3-actions-8bb83f2a. Encrypt the trail using the metrolio-log-key-daca2753 and enable log file validation.
On the next page, Deselected management events and selected data events. Chose the data event type in S3 and in the log selector template drop down, I selected Log writeOnly events and call the event selectir s3-write-selector
This is the S3 buckets storing the log files from the management trails. The file extension for these logs are json.gz
