[Rule Tuning] AWS IAM Virtual MFA Device Rules

[imays11]

Pull Request

Issue link(s):

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

Summary - What I changed

AWS IAM Virtual MFA Device Registration Attempt with Session Token

• rule change kql to eql so that I could use startsWith function instead of wildcard for the ASIA*, temporary session determination.
• there is a known false positive for rules like this. When you login to the AWS console, a temporary session token is created in the back-end so in cloudtrail the token id looks the same (ASIA*) as temporary session tokens created by actions like GetSessionToken or AssumeRole, which is what this rule meant to capture. Our current data source does now allow us to distinguigh between these type of events. However, cloudtrail does provide a field sessionCredentialFromConsole:true that I am putting in a request for Integrations to include. This would allow us to exclude Console login sessions from rules like this that look for temporary token abuse.
• reduced execution window
• updated description, FP and IG
• update MITRE mapping
• added highlighted fields

AWS IAM Deactivation of MFA Device

• removed DeleteVirtualMFADevice from the scope of this rule. When Deleting an MFA device you must deactivate it first if it is associated with a user. You can also Create an MFA device and then Delete it without it being activated for a particular user. By capturing both Deactivation and Deletion events we have duplicate alerts for the same activity (This duplication of events is seen in telemetry.) We also capture benign instances where un-used MFA devices are deleted (which is a clean-up best practice). By reducing the scope to only DeactivateMFADevice actions, we capture the most threat-centric behavior which should be investigated.
• reduced execution window
• updated Description, FP and IG
• added highlighted fields

How To Test

Test data in our stack for running the queries against.
Scripts for testing:
trigger_impact_iam_deactivate_mfa_device.py
trigger_persistence_aws_attempt_to_register_virtual_mfa_device.py

Screenshot of new working query for temp token MFA device creation

Screenshots of Delete + Deactivate MFA events vs Deactivate-only working query

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