Skip to content

[Rule Tunings] AWS Group Creation, User Added to Group, Group Deletion #5269

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

[Rule Tunings] AWS Group Creation, User Added to Group, Group Deletion #5269

wants to merge 4 commits into from
+175 −96

Conversation

@imays11
Copy link
Contributor

@imays11 imays11 commented Oct 31, 2025

Pull Request

Issue link(s):

Summary - What I changed

All 3 rules are showing extremely low telemetry volume as expected. No major changes needed to these queries.

  • updated the descriptions, investigation guides and false positive sections
  • reduced execution window
  • added highlighted fields

How To Test

These are all pretty simple to test manually however these 2 scripts will test all 3 rules as well. There is also data in our test stack to run the queries against.

Screenshot of expected alerts for all 3 rules post running these scripts.

Screenshot 2025-10-30 at 10 25 42 PM

@imays11
[Rule Tuning][New Rule] AWS S3 Bucket Policy Added to Share with Exte…
776d748 
…rnal Account/ to Allow Public Access

AWS S3 Bucket Policy Added to Share with External Account
Low telemetry volume overall, however false positives were seen for cloudfront identity and service accounts being given access to a bucket
- Reduced the scope of this rule to only analyze policy that include account ids or account ARNs (which include an account ID). This eliminates the false positives triggered by sharing buckets with a service account (i.e. cloudtrail.amazonaws.com)
- Excluded cloudfront identity, which should be treated the same way service accounts are being treated and be excluded as they do not include account IDs in their ARN
- This rule wasn't explicitly capturing the use of `Principal: *` which is a public sharing method, often accompanied by a Condition statement (i.e. aws.SourceAccount =  OR aws.PrincipalAccount= OR ip.address = ....). The new query will capture Condition statements that include an account id. However there is still a gap for Policies that have explicit `Principal:*` with or without a condition, so another rule was created that will account for these scenarios.
- added highlighted fields
- updated investigation guide and description
- updated Mitre tactics and tags
- `event.type` used in place of `event.category` field

### AWS S3 Bucket Policy Added to Allow Public Access
Rule added to cover gap in public bucket policy added which includes an `Effect=Allow` and `Principal: *`. While an additional condition might be added to this policy which would exclude public access, cases where the condition is not included mean the bucket is publicly accessible. Both cases need to be verified, because even the condition could be giving access to an attacker owned account. There is also the chance that an `Effect=Deny` for `Principal:*` will trigger a false positive for this rule if the same policy also includes an `Effect=Allow` statement. We call this out in the description, false positive and investigation guide sections of the rule.
@imays11
[Rule Tunings] AWS Group Creation, User Added to Group, Group Deletion
c66a4f1 
All 3 rules are showing extremely low telemetry volume as expected. No major changes needed to these queries.
- updated the descriptions, investigation guides and false positive sections
- reduced execution window
- added highlighted fields
@imays11
slight edit to description
7c98d60
@imays11
Revert "[Rule Tuning][New Rule] AWS S3 Bucket Policy Added to Share w…
4f7873a 
…ith External Account/ to Allow Public Access"

This reverts commit 776d748.
@imays11 imays11 self-assigned this Oct 31, 2025
@imays11 imays11 added Integration: AWS AWS related rules Rule: Tuning tweaking or tuning an existing rule Team: TRADE Domain: Cloud labels Oct 31, 2025
@github-actions
Copy link
Contributor

github-actions bot commented Oct 31, 2025

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
terrancedejesus reviewed Oct 31, 2025
View reviewed changes
rules/integrations/aws/persistence_iam_group_creation.toml
- After group creation, watch for data-access or configuration changes (e.g., S3 policy updates, KMS key policy changes)
### Response and remediation
### False positive analysis:
Copy link
Contributor

@terrancedejesus terrancedejesus Oct 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: No need for :, not used in headers for other rules

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@terrancedejesus terrancedejesus terrancedejesus approved these changes

@w0rk3r w0rk3r Awaiting requested review from w0rk3r

@Aegrah Aegrah Awaiting requested review from Aegrah

@shashank-elastic shashank-elastic Awaiting requested review from shashank-elastic

At least 2 approving reviews are required to merge this pull request.

Assignees

@imays11 imays11

Labels

backport: auto Domain: Cloud Integration: AWS AWS related rules Rule: Tuning tweaking or tuning an existing rule Team: TRADE

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@imays11 @terrancedejesus