AWS CloudTrail Best Practices [Checklist] [Cheat Sheet]

Are you following CloudTrail best practices? Here’s a simple checklist ✅

Under the hood, AWS Security Hub service is looking for these best practices:

✅ [CloudTrail.1] CloudTrail should be enabled and configured with at least one multi-Region trail that includes read and write management events

🟠 Severity: High

📌 Why:
– Helps detect unexpected activity, even in unused Regions
– Ensures that AWS global services events are logged

🔐 Remediation:
– Create a new trail / update an existing trail
– In Management Events, for API activity, make sure Read & Write are selected

✅ [CloudTrail.2] CloudTrail should have encryption at-rest enabled

🟤 Severity: Medium

📌 Why:
– Checks whether CloudTrail is using SSE AWS KMS key encryption
– An added layer of security for sensitive log files

🔐 Remediation:
– Enable server-side encryption with AWS KMS keys (SSE-KMS) for encryption at rest

✅ [CloudTrail.3] CloudTrail should be enabled

🟠 Severity: High

📌 Why:
– Without visibility, you don’t have security
– CloudTrail is one of the most critical AWS services to enable observability

🔐 Remediation:
– Create a CloudTrail trail
– Understand what’s enabled by default at account creation
– Understand the difference between Management Events, Data Events, and Insights Events

✅ [CloudTrail.4] CloudTrail log file validation should be enabled

⚪️ Severity: Low

📌Why:
– Log file validation creates a digitally signed digest file with a hash of each log that CloudTrail writes to Amazon S3
– If someone deletes or changes log files, log file validation will tell you

🔐 Remediation:
– Enable log file validation on all trails

✅ [CloudTrail.5] CloudTrail trails should be integrated with Amazon CloudWatch Logs

⚪️ Severity: Low

📌Why:
– CloudTrail stores log files to S3, but those files aren’t actionable on their own. You need to download them and sift through or feed into another tool
– Sending to CloudWatch will help with monitoring/alerting, and both near real-time & historical analysis through simple searches and Logs Insights

🔐 Remediation:
– Create a Logs Group and send CloudTrail logs to CloudWatch Logs

✅ [CloudTrail.6] Ensure the S3 bucket used to store CloudTrail logs is not publicly accessible

🔴 Severity: Critical

📌Why:
– Since CloudTrail sends log files to S3 with all sorts of API and non-API activity, that bucket will contain sensitive information

🔐 Remediation:
– Ensure the S3 bucket blocks public access to the logs

✅ [CloudTrail.7] Ensure S3 bucket access logging is enabled on the CloudTrail S3 bucket

⚪️ Severity: Low

📌Why:
– S3 bucket access logging creates a log with access records for every request made to that S3 bucket
– Those access logs contain details about the request type, the resources accessed, and date/time of the request
– This can be useful for incident response and to keep an eye on your CloudTrail logs

🔐 Remediation:
– Enable S3 bucket logging

✅ [CloudTrail.9] CloudTrail trails should be tagged

(We’re following AWS nomenclature and they skip .8-this is not a mistake)

⚪️ Severity: Low

📌Why:
– Tagging is a general good practice as it helps keep track of your resources (ie: for cost and ownership tracking)
– Tags can also be used for access control by enabling the use of ABAC policies

🔐 Remediation:
– Deploy tags (key/value pairs) for all of your trails that follow AWS requirements using your IaC tool of choice
– You can also optionally set requiredTagKeys in which case it’ll check the tags against those values