[Rule Tunings] AWS RDS Rules

[imays11]

Pull Request

Issue link(s):

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

Summary - What I changed

All of these RDS rules are triggering as expected. Only AWS RDS Snapshot Deleted had clear false positive in telemetry which has been excluded from the rule. Below is a summary of each rule change and screenshots of each rule triggering with additional screenshots of the new working queries for the eql rules using event.type as event_category_override

AWS RDS DB Instance Made Public

• updated description and investigation guide
• added highlighted fields

AWS RDS DB Instance or Cluster Deletion Protection Disabled

• updated description and investigation guide
• added highlighted fields

AWS RDS Snapshot Deleted

• excluded backup.amazonaws.com as this is expected behavior. This exclusion reduces noise in telemetry by ~77%
• updated description and investigation guide
• added highlighted fields

AWS Deletion of RDS Instance or Cluster > AWS RDS DB Instance or Cluster Deleted

• reduced execution window
• slight name change to align with other rules
• updated description and investigation guide
• added highlighted fields

AWS RDS DB Instance Restored

• changed rule type from eql to kql since there's no reason for using eql for this rule query
• updated description and investigation guide
• added highlighted fields

AWS RDS DB Instance or Cluster Password Modified

• event.type used for event_category_override because event.category is not mapped for these API calls
• updated description and investigation guide
• added highlighted fields

AWS RDS Snapshot Export

• reduced execution window
• updated mitre mapping
• updated description and investigation guide
• added highlighted fields

How To Test

There is plenty of data to run these queries against in our test stack and a set of scripts can be found here: RDS

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