terrancedejesus commented 2 months ago

Pull Request

Issue link(s):

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

Summary - What I changed

Per conversation with @aarju, the following AWS OOTB rules had room for improvement.

AWS Security Token Service (STS) AssumeRole Usage -> AWS STS Temporary Credentials via AssumeRole
AWS SAML Activity -> AWS IAM SAML Provider Updated

For AWS Security Token Service (STS) AssumeRole Usage, we changed this rule from a custom KQL query to New Terms. The new terms values will focus solely on user.id and aws.cloudtrail.flattened.request_parameters.roleArn for uniqueness. It was pointed out that false-positives may occur for environments with third-party IdPs. This remains true for automation workflows as well. New terms should ignore common benign temporary creds retrieved for specific users and roles that are commonly assumed. Additionally, rather than separate AssumeRole and AssumeRoleWithSAML, we added * to account for any assumed role activity. Based on global alert telemetry, we have assumed role activity from various sources (SAML via IdP, web identity, pod identity, etc.) With user.id: * added to the query, this field must exist but only exists for assumed role activity where an IAM user is involved, thus ignoring some automated workflows.

For AWS SAML Activity, this rule originally seemed to capture multiple SAML authentication workflow activity that may or may not have been related to each other, based on the API calls reported in event.action. As a result, AssumeRoleWithSAML will be covered in AWS STS Temporary Credentials via AssumeRole. This rule now only detects when the IAM SAML provider has had metadata modification. We also increased the risk score associated with this as the result of a true-positive could have higher consequences. Note that this update reduces alerts to ~82 within the last 4 months globally.

Additional Information:

Updated authors
Updated false-positive notes for each rule
Re-formatted queries
Added aws.cloudtrail.flattened.request_parameters.roleArn to non-ecs.json as it does not exist in AWS schema we build locally
Renamed rules to align more with detection logic
Renamed files accordingly

How To Test

AWS IAM SAML Provider Updated

AWS STS Temporary Credentials via AssumeRole

This is more difficult to test as it is new terms. Instead, knowing that the user ID is used for New Terms regarding AWS IAM and STS events, we can confidently assume lower alert volume or false-positives. There are ~502 unique user.ids for global telemetry from ~8000 alerts in the last 120 days, therefore, this should reduce these.

Checklist

[x] Added a label for the type of pr: bug, enhancement, Rule: New, Rule: Deprecation, Rule: Promote, Rule: Tuning, Hunt: New, or Hunt: Tuning so guidelines can be generated
[ ] Added the meta:rapid-merge label if planning to merge within 24 hours
[x] Secret and sensitive material has been managed correctly
[x] Automated testing was updated or added to match the most common scenarios
[ ] Documentation and comments were added for features that require explanation

Contributor checklist

Have you signed the contributor license agreement?
Have you followed the contributor guidelines?

protectionsmachine commented 2 months ago

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

[x] creation_date matches the date of creation PR initially merged.
[x] min_stack_version should support the widest stack versions.
[x] name and description should be descriptive and not include typos.
[x] 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.
[x] 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).
[x] integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
[x] 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).
[x] tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
[x] 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.