August 27, 2024 - Content Release

This release reverts a change to our AWS CloudTrail default (catch all) mapper for how user_username is mapped. This is being reverted due to reports of breaking rule tuning and missing user context for some AssumedRole events.

AWS AssumedRole events can contain service and user role assumptions. Oftentimes service role assumptions will contain a dynamic session identifier instead of a static user identifer which contains the originating identity. Prior to the change we are now reverting, this was causing certain services to generate user entities from these sessions, creating false positives. This behavior changed with the August 5th, 2024 content release to handle role assumptions to instead map the role as user to prevent false positives from dynamic service sessions. While this decreased the number of false positives from dynamic service sessions, it also eliminated visibility into user role assumptions, creating potential for false negatives.

AWS best practices suggest defining sourceIdentity to allow for the originating user for a role assumption to be identifiable. This is the best path to avoid false positive generation, as our mapper will favor sourceIdentity if it is present in CloudTrail logs. If it is not present, then userIdentity.arn will be used and the resource-id will be mapped to user_username, creating potential for false positives from dynamic session identifiers. See Viewing source identity in CloudTrail in the AWS documentation for more information.

Alternatively, known service accounts which generate dynamic sessions identifers can be tuned out from signals using rule tuning expressions, Field Extraction Rules (FERs), or at the CloudTrail parser to reduce potential for false positive signals.

Log Mappers

• [Updated] CloudTrail Default Mapping