[Rule Tuning][New Rule] AWS S3 Bucket Policy Added to Share with External Account/ to Allow Public Access

[imays11]

Pull Request

Issue link(s):

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

Summary - What I changed

(TUNE) 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

(NEW) 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.

Note: Unfortunately there will be duplicate alerts between these rules for the case where both a Principal Wildcard is included AND a reference to an Account Id is included. I could not think of a way to eliminate this chance without compromising the intent of either of the rules, open to suggestions if you have any.

How To Test

Scripts for Testing each rule:

• trigger_exfiltration_s3_bucket_policy_added_for_external_account_access.py
• trigger_exfiltration_s3_bucket_policy_added_for_public_access.py

Test data in the stack for running the queries and screenshots below

AWS S3 Bucket Policy Added to Share with External Account

For this rule I tested 3 different scenarios that should trigger an alert and 3 scenarios that shouldn't

 1) Principal="*" + Condition aws:PrincipalAccount=<external> [should alert]
 2) Service principal + Condition aws:SourceAccount=<external> [should alert]
 3) External AWS principal ARN (arn:aws:iam::<external>:root) [should alert]
 4) Allow a common service principal (CloudTrail) with no account condition  [exclusion test]
 5) Allow CloudFront OAI-style IAM ARN (false positive found in telemetry) [exclusion test]
 6) Public Principal="*" with NO conditions  (public exposure that should be missed)  [expected miss]

Screenshots of scenario 1, 2, and 3 being captured by rule query

Screenshot of scenario 5 Cloudfront being captured before exclusions added

Screenshot of exclusions added which no longer capture Cloudfront or Service Principal shares

AWS S3 Bucket Policy Added to Allow Public Access

Screenshot of New Rule Query For Capturing scenario 1 and 6, Principal Wildcard (both with and without a condition)

[github-actions]

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

• Detailed description of the rule.
• List any new fields required in ECS/data sources.
• Link related issues or PRs.
• Include references.

Rule Metadata Checks

• creation_date matches the date of creation PR initially 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, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
• min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
• index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
• integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
• setup should include the necessary steps to configure the integration.
• note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
• tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
• threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

• building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
• bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

• Provide evidence of testing and detecting the expected threat.
• Check for existence of coverage to prevent duplication.

[github-actions]

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

• Detailed description of the rule.
• List any new fields required in ECS/data sources.
• Link related issues or PRs.
• Include references.

Rule Metadata Checks

• creation_date matches the date of creation PR initially 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, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
• min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
• index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
• integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
• setup should include the necessary steps to configure the integration.
• note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
• tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
• threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

• building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
• bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

• Provide evidence of testing and detecting the expected threat.
• Check for existence of coverage to prevent duplication.

[terrancedejesus]

Very nice work!