[Rule Tunings] AWS Multiple API Calls ESQL rules

[imays11]

Pull Request

Issue link(s):

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

Summary - What I changed

AWS EC2 Multi-Region DescribeInstances API Calls
Over 2,000 alerts in the last 24 hours. This is a very noisy rule, by design it is alerting on quite normal behavior. There is not much in-the-wild threat behavior that justifies keeping this rule as a standalone alert. As a threat indicator, this is best used as a hunting rule or in correlation with another rule, for example: (GetCallerIdentity new terms + multi region DescribeInstances by same principal) or (Multiple Discovery API calls + multi region DescribeInstances by same principal) or (multi region DescribeInstances + snapshot/AMI activity by same principal). However, on its own it’s not adding much value over the noise.

• I’m keeping this as ESQL rule but converting it to a BBR
• keeping more fields for further context
• Changing investigation guide to be more relevant for hunting/correlation rule

AWS Discovery API Calls via CLI from a Single Resource
This rule is alerting as expected with low telemetry. It has to remain an ESQL rule as no other rule types can truncate the time window to 10 sec looking for a threshold of unique API calls coming from a single user.

• Keeping as ESQL rule
• Reduced execution window
• Keeping more fields for further context
• Adding highlighted fields
• Updated Investigation guide
• Changed the toml file name to be more accurate as this rule does not only look at ec2 service discovery

How To Test

Plenty of data in our test stack to run queries against. Script for the AWS Discovery API Calls rule. It is very extensive in the API calls it makes, I wanted this script to be a bit more realistic and trigger across many different services.

Screenshots for AWS Discovery API Calls via CLI from a Single Resource

Expected Alert with very little context

New Working Query with additional context

New Expected Alert with additional context

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

[terrancedejesus]

Should we add Cloudtrail as a data source to be consistent?

[imays11]

Mmm yea I should do that with all the AWS rules, it's something I'll look at doing later.

[terrancedejesus]

May want to double check these. We do a keep and then stats which will table only by what we aggregate on so the alert doc may not have some of the original AWS fields.

[imays11]

Oop nice catch I need to go back in and add these fields to the stats with VALUES()