[Rule Tuning] AWS Access Token Used from Multiple Addresses

[imays11]

Pull Request

Issue link(s):

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

Summary - What I changed

Tuning changes to reduce noise and improve fidelity for the AWS Access Token Used from Multiple Addresses rule. After several tuning this rule is still producing ~2000 alerts/day

• Added aws.cloudtrail.session_credential_from_console exclusion to filter out legitimate console login sessions
• Added Esql.event_provider_count_distinct > 1 condition requiring activity across multiple AWS services to reduce single-service noise
• Removed query time window since from settings control this
• Added min_stack_version = "9.2.0" for the new console credential field (AWS integration 4.6.0+)

Rational

• Console login sessions generate temporary credentials that can appear from multiple IPs during VPN/network transitions
• Requiring activity across multiple AWS service providers increases confidence that the token is being used for broader reconnaissance rather than normal single-service operations

How To Test

run query in stack and prod telemetry cluster

[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.

[eric-forte-elastic]

Manual review, reviewed telemetry tuning makes sense and looks good 👍

[terrancedejesus]

Maybe make interval window 31m since aggregation ESQL queries have no deduplication upstream?

[imays11]

I did have it set this way but Samir make a good note that this will delay detection, I think I'll go in the middle with 15 minutes to reduce some of the chance for duplication

[terrancedejesus]

good thinking here, makes sense that the behavior after acquiring the token (if stolen) differs by provider or action.