[Rule Tunings] AWS EC2 EBS Snapshot and Encryption Rules

[imays11]

Pull Request

Issue link(s):

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

Summary - What I changed

AWS EC2 Encryption Disabled
rule performance is good, telemetry looks low as expected. No major changed needed

• additional context to description to emphasize the security concern and purpose of the rule
• updated investigation guide
• added highlighted fields
• reduced execution window

AWS EC2 EBS Snapshot Access Removed
rule alerts as expected, telemetry volume is low as expected. however, this rule can be accomplished using EQL so I've changed the rule type

• changed rule type to eql
• added index
• updated IG
• added highlighted fields note: I have to use any for the query since there is no event.category defined for event.action: ModifySnapshotAttribute

AWS EC2 EBS Snapshot Shared or Made Public
Converted to EQL. As an ESQL rule the primary benefit was being able to definitely exclude instances where a user adds their own account id when calling the ModifySnapshotAttribute instead of an external account id. This is a redundant action as the snapshot when created is automatically shared with the account it's created in. But this could be a false positive if it's done by mistake. Instead of keeping this as an ESQL rule, I still think there is more value to converting this to EQL for both customer alert context and telemetry. When looking at production data, I saw no instances where the owning account id was added in this way. Its a rare mistake that shouldn't happen often enough to support keeping this as an ESQL rule.

• converted to EQL
• added index
• updated IG
• updated description
• added highlighted fields

How To Test

There is test data in our stack that each of the queries can be run against. You can find scripts for testing each rule here:

• https://github.com/elastic/elastic-aws-ruleset-testing/blob/main/EC2/trigger_impact_ec2_disable_ebs_encryption.py
• https://github.com/elastic/elastic-aws-ruleset-testing/blob/main/EC2/trigger_impact_ec2_ebs_snapshot_access_removed.py
• https://github.com/elastic/elastic-aws-ruleset-testing/blob/main/EC2/trigger_exfiltration_ec2_ebs_snapshot_shared_with_another_account.py

Screenshot of AWS EC2 Encryption Disabled expected alert

Screenshot of AWS EC2 EBS Snapshot Access Removed

Screenshot of AWS EC2 EBS Snapshot Shared or Made Public

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

nit: Response and Remediation -> Response and remediation to stay consistent with other rules. Same for FP analysis and investigation steps.

[imays11]

Thank you!

[terrancedejesus]

Noticed we dont have an ECS event.category for the docs but aws.cloudtrail.event_category exists. I wonder if we can get these mapped and cover more categories that way. Just a thought

[Mikaayenson]

Here's an example of what @terrancedejesus has done in the past. Although im not sure why he added an override matching the default. 🤔

[terrancedejesus]

I don’t recall much beyond a suggestion to override it: #3278 (comment)

Okta categories will be fixed here: elastic/integrations#15235

In my opinion, overriding with the provider does remove the need to use any, but it also changes the query’s context. Instead of saying event type WHERE, we’re now effectively saying service WHERE. I could be mistaken, but my understanding is that the override functionality was introduced to allow specifying a different field from the integration’s data stream that categorizes events.

While event.provider works well and is consistent in AWS, that may not be the case for other CSP audit logs, so this approach might make sense in some cases but could introduce inconsistency overall. Ideally, this should be solved at the data source level rather than in the rule itself.

[imays11]

@terrancedejesus I do agree with the ultimate changes being made at the data source level. When I'm finished with the audit I will create an Integrations request that consolidates all the API calls that we currently use in our ruleset that don't have a defined category. However, if performance is an issue, we may want to just implement a solution that we can control for now. It's probably worth putting some thought into normalizing what "backup" fields we should use. I chose event.provider simply because it's a way to group all the events associated with a single AWS service, which we always include in the AWS queries any way. But I'm open to suggestions for a better field.

[terrancedejesus]

Nice changes!

[imays11]

cc: @terrancedejesus After doing some testing in the stack with @Mikaayenson, I changed the EQL queries to rely on event.provider instead of event.category field. Our OOTB rules do support this change. Below are screenshots of a working query and a created rule with the Event category field changed. This is a work around to improve rule performance since the event.action == "ModifySnapshotAttribute" has not yet been categorized via the AWS Integration to populate event.category field, we would otherwise have to use any in the query.

[imays11]

unit tests failing on the EQL queries but this is valid syntax