[Rule Tuning] AWS IAM Assume Role Policy Update

[imays11]

Pull Request

Issue link(s):

• https://github.com/elastic/ia-trade-team/issues/616

Summary - What I changed

Roles are identities in AWS that are granted a set of permissions and can then be assumed by various users across many different sessions. Each of these sessions is given a session name which is attached to the end of the role's aws.cloudtrail.user_identity.arn. This means that each time a Role is assumed, there is a unique aws.cloudtrail.user_identity.arn created.

This rule is meant to capture new instances of the Role updating role policies. Right now it's analyzing each session used with the Role, resulting in false positives. To capture the role itself we can use the user.name field. cloud.account.id has been added to the new_terms fields to account for organizations with multiple AWS account ids, which may reuse certain user.names across accounts.

• changed time window to have only 1 minute lookback
• changed the new terms field to look at combination of cloud.account.id, user.name, and roleName. (This is to account for the problem with using aws.cloudtrail.user_identity.arn for AssumedRoles.)
• added investigation fields
• updated mitre techniques

This will improve performance and detection accuracy especially in environments where there are many users assuming the same role and updating it's trust policy as a part of normal operations.

How To Test

You can use this script to test this rule against both IAM user and Assumed Role Identity types.

For manual testing use an existing user or role to update a new policy (to trigger new_terms combination)

aws iam update-assume-role-policy \
    --role-name Test-Role \
    --policy-document file://Test-Role-Trust-Policy.json

[github-actions]

Rule: Tuning - Guidelines

These guidelines serve as a reminder set of considerations when tuning an existing rule.

Documentation and Context

• Detailed description of the suggested changes.
• Provide example JSON data or screenshots.
• Provide evidence of reducing benign events mistakenly identified as threats (False Positives).
• Provide evidence of enhancing detection of true threats that were previously missed (False Negatives).
• Provide evidence of optimizing resource consumption and execution time of detection rules (Performance).
• Provide evidence of specific environment factors influencing customized rule tuning (Contextual Tuning).
• Provide evidence of improvements made by modifying sensitivity by changing alert triggering thresholds (Threshold Adjustments).
• Provide evidence of refining rules to better detect deviations from typical behavior (Behavioral Tuning).
• Provide evidence of improvements of adjusting rules based on time-based patterns (Temporal Tuning).
• Provide reasoning of adjusting priority or severity levels of alerts (Severity Tuning).
• Provide evidence of improving quality integrity of our data used by detection rules (Data Quality).
• Ensure the tuning includes necessary updates to the release documentation and versioning.

Rule Metadata Checks

• updated_date matches the date of tuning PR merged.
• min_stack_version should support the widest stack versions.
• name and description should be descriptive and not include typos.
• query should be inclusive, not overly exclusive. Review to ensure the original intent of the rule is maintained.

Testing and Validation

• Validate that the tuned rule's performance is satisfactory and does not negatively impact the stack.
• Ensure that the tuned rule has a low false positive rate.

[Aegrah]

LGTM!

[terrancedejesus]

@imays11 - It looks like the session ID persists in user.name if it's an assumed role, from what I can tell. Does user.id make more sense? It captures the principal ID and the name of the principal, but does not include the session ID. Regarding cloud.account.id, this is valid if we are concerned with isolating these signals to a single tenant if multi-tenancy is setup. If not, I don't think it would be worth the extra performance.

[imays11]

@terrancedejesus If you look below, session names are persisted in user.id but only the role name itself persists in user.name. If you also look at that session.id field at the end of the image, you can see that it also only shows the role name but this field is only included for AssumedRoles.

Regarding cloud.account.id, this is valid if we are concerned with isolating these signals to a single tenant if multi-tenancy is setup.

Yes we want to isolate this to each individual user, for organizations ingesting cloudtrail logs for multiple accounts we need to distinguish between the same user names across accounts so that's why I included the cloud.account.id