[Rule Tunings] AWS SNS New Terms Rules

[imays11]

Pull Request

Issue link(s):

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

Summary - What I changed

AWS SNS is a pub/sub style service where users can subscribe to a topic and receive messages published to that topic. Below is a screenshot of the different protocols a user could subscribe with and the various endpoints that could be associated with those protocols.

AWS SNS Email Subscription by Rare User --> AWS SNS Rare Protocol Subscription by User (not a new rule)

• changed the scope of the rule to capture the first time a user/role subscribes to a topic via a particular protocol (ie. email, http, lambda, mobile). Subscribing to an SNS topic via email is a rather normal behavior and it would be normal for each user to subscribe this way "for the first time" making this rule not as valuable as it was intended to be.
• reduced execution window
• added real-world threat references
• added additional MITRE technique and Impact tag
• small edits to IG and Description
• edited highlighted fields
  note: I had to use the flattened field added to non-ecs file as there is no other way of capturing the subscription protocol

AWS SNS Topic Message Publish by Rare User

• added AWS to name for consistency -changed new terms fields to use a combination of cloud.account.id and user.name against the topic itself aws.cloudtrail.resources.arn. So that instead of simply evaluating the first time a user/role publishes a message to ANY topic, this rule now looks for the first time a user/role publishes a message to a particular topic. We want to make this distinction to capture the case where an identity responsible for publishing to a particular topic A suddenly starts publishing to another topic B, which indicates behavior that should be verified.
• reduced new terms window
• added setup notes as Data events are necessary for capturing the Publish API call
• reduced execution window
• added real-world threat references
• added additional MITRE technique and Impact tag
• small edits to IG and Description
• edited highlighted fields

AWS SNS Topic Created by Rare User

• removed the AssumedRole and *-i* parameters from the query as this narrowed the query to only alert on behavior from EC2 instance roles. We ideally want to evaluate this behavior for all users and roles.
• reduced execution window
• added real-world threat references
• added additional MITRE technique and Impact tag
• small edits to IG and Description
• edited highlighted fields

How To Test

Each query can be run in our shared stack against existing test data. You can use one of these scripts to trigger the rules, this one triggers all 3 rules using an email protocol subscription , this one does not publish a message but uses a lambda protocol subscription method

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