[Tuning] AWS Access Token Used from Multiple Addresses

[imays11]

Pull Request

Issue link(s):

• https://github.com/elastic/ia-trade-team/issues/616
• [New Rule] Adding Coverage for AWS Temporary User Session Token Used from Multiple Addresses #4624 (initial PR with more details around the rule intent and background research)

Summary - What I changed

Tuning was triggered by a community member

• fixes wildcard and Pulumi typos to exclude common IaC tools
• adds exclusion for source.as.organization.name == "AMAZON-02" and aws.cloudtrail.event_category == "Data" to exclude the noisy multi-IP traffic coming from Amazon-02 networks performing high-throughput data-plane operations. I didn't exclude this network completely because this network can also indicate user-triggered events that are important to keep in the alert.
• added additional high noise service providers that may be more indicative of console browsing
• added a field for pairing source.ip & network values
• added highlighted fields

How To Test

There's a saved timeline in our test stack which captures this query results over the last year, it includes the ByBit threat behavior this rule was initally meant to capture.

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

Just making sure: are these backticks supported in ES|QL pipeline?

[imays11]

Yes and they used to be necessary for any field with as in the name since that means something in ESQL. We used to get errors when including this field without the backticks but I actually just tried it again without the backticks and am not getting those errors anymore so something might have changed with the language ability to recognize fields like this. I'm going to keep the backticks though as they are still supported.

[terrancedejesus]

I don't know if we have used dynamic fields in timelines before and what the implications are. With the best practices and guidelines being followed, key:value pairs like Esql.source_ip_values may show up in timelines whereas Esql.activity_fidelity_score is likely unique to this rule. That would only be for alerts too, not raw telemetry and may not be valuable to pivoting and triaging.

[imays11]

Good point, they seem to be supported in the UI when modifying the rule, but I agree we should double check before merging.

[terrancedejesus]

We should consider https://github.com/elastic/detection-rules/pull/5055/files#r2322658965 and make a decision before merging. I'd caution on not including them for ESQL rules with dynamic fields. Happy to consider other thoughts.

[imays11]

We should consider https://github.com/elastic/detection-rules/pull/5055/files#r2322658965 and make a decision before merging. I'd caution on not including them for ESQL rules with dynamic fields. Happy to consider other thoughts.

Based on the docs we shouldn't have a problem here https://www.elastic.co/docs/solutions/security/detect-and-alert/create-detection-rule#custom-highlighted-esql-fields

When configuring an ES|QL rule’s Custom highlighted fields, you can specify any fields that the rule’s aggregating or non-aggregating query return. This can help ensure that returned fields are visible in the alert details flyout while you’re investigating alerts.