AWS CloudTrail is an critical service for organizations using AWS, providing visibility into the actions performed in your AWS accounts. This visibility and monitoring of actions is vital to improving the security and compliance of your cloud. At Symmetry, an AWS Security Competency Partner, we use AWS CloudTrail to:

• get visibility into a subset of data events or actions,
• as well as monitor data events or actions on the logs in the AWS CloudTrails themselves.

As a result, we are in a unique position to see the Common AWS CloudTrail Mistakes that organizations make when setting up their CloudTrail. All from within the security of their own environment.

In this blog post, we will show some of these common mistakes, particularly mistakes that increase the cost of CloudTrail or reduce the effectiveness of CloudTrail. By understanding these mistakes and following some of our best practices, you can ensure a cost CloudTrail implementation that provides comprehensive monitoring and logging of data events within your environment, without wasting money unnecessarily.

What are the most Common CloudTrail Mistakes?

Fragmented AWS CloudTrail Architecture 

There is no limit to the number of CloudTrails that an organization can enable, but the first CloudTrail is free and each extra CloudTrail comes at a cost. This optionality is useful to support different use cases and reduce the sensitivity of logs shared with third parties. However it often leads to a fragmented AWS CloudTrail architecture – one of the most common AWS CloudTrail mistakes we see. 

Most organizations use multiple AWS accounts within their architecture and this can lead to fragmented CloudTrail configurations per account. This architecture makes it hard to track and analyze events across the organization. Unfortunately it can also result in gaps in the logging. In this type of architecture, engineers need to enable CloudTrails on a per account basis. Rather than relying on an organization wide CloudTrail. 

In addition to CloudTrails per AWS account, organizations often create CloudTrails for each third party cloud security service they have enabled. We often see separate CloudTrails for CIEMs, CSPMs and other DSPM’s we have replaced. The configuration is effective in reducing the amount of confidential data logs available to third parties. On further inspection, the same logs are written to multiple CloudTrails with no differentiation, just increased cost. 

Implementing an organization-wide CloudTrail is relatively easy and allows organization-wide visibility. The visibility helps identify cross account threat activity that might not be possible when looking at accounts in isolation. When providing access to these CloudTrails to external third parties, the sensitivity and classification of information should also be considered.

Orphaned Amazon S3 buckets

For every CloudTrail, an organization sets the storage location in Amazon S3 for the CloudTrail logs. The optionality to create multiple CloudTrails per project or service often leads to the proliferation of CloudTrail buckets. This in itself is not a huge problem on its own. However the allocation and governance of CloudTrail S3 buckets is also left to adhoc management by the customer. Organizations adopt a variety of means to govern these buckets. Most typically through organizational tagging and naming conventions. This allows them to be distinguished from other Amazon S3 buckets, but not much else.

We discover at least one orphaned Amazon S3 bucket in a typical customer. These orphaned buckets may have been used to initially used to test an AWS CloudTrail configuration or for a pilot of a new security tool. Regardless of the root cause, it is one of the most common AWS CloudTrail mistakes we see.

These orphaned buckets not only waste storage resources but also introduce security risks by potentially leaving sensitive and valuable log data both unmonitored and unsecured. Organizations need to develop processes for identifying and managing the use and security of all CloudTrail buckets within their organization. Data Security Posture Management tools solve this problem easily. 

Lack of Logging Strategy for Data

Security professionals are more like data hoarders than we realize. We often log everything and then try to figure out whether it tells us anything. A preferred approach is to identify the events of interest strategically – based on what we are trying to prevent, detect and respond to. 

Setting up CloudTrails with a default configuration is the equivalent of a modern data hoarder. That might make sense when it doesn’t come with a cost. Or worse – impact your ability to find what you need to. The approach to log everything, everywhere, invariably leads to a large volume of unnecessary data. This comes with unnecessary costs and problems in analysis. Good luck in finding the needle in the modern data (hay)stack. You can optimize the CloudTrail logs by selectively logging specific services, specific types of activity and resources. 

Uncertainty over cost of Data Events 

Enabling logging of data events in CloudTrail allows you to capture detailed information about actions performed on your data. Enabling data events does incur charges (currently $0.10 per 100,000 data events delivered above the free tier). However it provides valuable insights into activity that every organization should care about – what is happening to my data! This log data allows greater visibility into security threats and compliance violations. 

Still we find that many organizations are unsure on this setting. Citing concerns about the perceived increased costs – particularly given the high frequency of these events.  

The cost of enabling data events is minor – especially given the security benefit and size of the environment. Enabling data events is relatively easy and allows organization-wide visibility, also providing insight into the encryption status of your data stores.  

You can further reduce the cost of data event logs by selectively logging specific services, specific types of activity and data buckets. We often recommend excluding read events on public sites, or excluding large batch jobs that are not critical for auditing or security purposes.

Ignoring the Security and Privacy of CloudTrails

CloudTrail is an invaluable audit trail that aids in compliance, troubleshooting, and incident response, but if left unsecured, can also become a target. Given the essential role that CloudTrail plays in incident response, perhaps the worst mistake that one can make is not monitoring changes made to your CloudTrail settings. Organization’s are so reliant on the logs that without them, they can be in the dark.

It is therefore important to take steps to ensure the immutability and integrity of CloudTrail logs. The ability to prove the integrity of logs is important for any security logs, but surprisingly commonly forgotten when setting up CloudTrails. At a minimum, organizations need to enforce and monitor the implementation of encryption for CloudTrail logs,  using AWS-managed keys (KMS) and access controls on their CloudTrail buckets. In addition, we recommend that organizations enable log file validation to verify log integrity and prove authenticity of the logs. 

The personal information that can be gleaned from logs can also be surprising. Naming conventions often disclose personal information, user agent information, and device details. The nature of the logs themselves may also be personal information in conjunction with other information.  Reviewing the contents of each logs to determine whether it may contain sensitive information such as customer IP addresses, metadata, or per-user directories is essential before giving access to CloudTrails. 

Opaque view of Role assumption in CloudTrails

Too often, we find organizations have misconfigured their cloud trails in the accounting of Role assumptions. Role assumptions allows an identity to assume another role. However if logging is configured incorrectly, only the temporary id being assumed by the identity will be shown in the CloudTrail logs. This leaves organizations temporarily blind to who did what, until they can retrospectively determine who assumed that role to perform an activity. 

Organizations can enhance the transparency of their AWS role assumptions process by logging the session identifier and source ID  in their AWS CloudTrail logs. By enabling this configuration, organizations gain visibility into the service account responsible for  each role assumption, allowing for improved traceability and auditing capabilities. This increased transparency not only enhances security and compliance efforts but also provides valuable insights for incident response, troubleshooting, and overall governance of AWS resources.

DSPM’s role in addressing Common AWS CloudTrail Mistakes

CloudTrail is crucial in enhancing your cloud security and compliance. Hopefully the knowledge of these common issues and best practices will help establish a robust CloudTrail configuration. Ultimately a comprehensive logging and monitoring strategy will allow you to improve the security posture of your cloud environment, but you really need more.

If you’re struggling to get a grasp of the cloud trails in your environment, a data security posture management (DSPM) solution can be an immense help in understanding the current state of your AWS CloudTrail and orphaned Amazon S3 buckets. 

To learn more about DSPM or see a DSPM solution in action, please reach out. We’d love to show you how Symmetry can help you make the most of AWS CloudTrail.

The post Six Common AWS CloudTrail Mistakes You Need to Avoid appeared first on Symmetry Systems.

*** This is a Security Bloggers Network syndicated blog from Symmetry Systems authored by claude.mandy. Read the original post at: https://www.symmetry-systems.com/blog/common-aws-cloudtrail-mistakes/