[Tuning] First Time AWS Cloudformation Stack Creation by User

[imays11]

Pull Request

Issue link(s):

• https://github.com/elastic/ia-trade-team/issues/616
• [Typo] First Time AWS Cloudformation Stack Creation by User #4941

Summary - What I changed

AWS CloudFormation is an infrastructure-as-code service that lets you define resources (EC2, IAM, RDS, S3, etc.) in a template and then deploy them as stacks. For the proper execution of this rule, the key distinction is between APIs that create resources vs those that just define or stage configuration.

CreateStack → Provisions a single stack in the current account/Region. The template is executed immediately, and resources are created.

CreateStackSet → Defines a blueprint for multi-account or multi-Region deployments. By itself, it does not create any resources; it’s just a container until instances are launched.

CreateStackInstances → Uses an existing StackSet to provision stacks in target accounts/Regions. This is the point at which resources are actually created in those environments.

This rule logic had an error, as it was only meant to capture the actual creation of resources (stacks) for the first time by a user or a role, but instead it also captured the configuration building API CreateStackSet. Because of this I've replaced CreateStackSet API with CreateStackInstances API, and kept CreateStack API.

Another important note is that CreateStackInstances API when called triggers a series of events including AssumeRole of a trusted and established CloudFormation role and then that role executes CreateStack across the different regions or accounts. This is a new_terms rule so it would ideally only trigger for that first time occurance of CreateStackInstances by the user, but not the CreateStack by the role (assuming it's an established role in the environment which is dedicated for Cloudformation usage). You can see this behavior captured in the screenshot below.

For this tuning:

• corrected a creation_date error
• corrected Cloudformation → CloudFormation
• Removed CreateStackSet API call as this only creates a blueprint for creating stack instances but does not actually create the resources
• Added CreateStackInstances API call which is used to create resources defined in the StackSet
• removed user from rule name as this also triggers for roles
• edited description and investigation guide to address typos
• added Mitre technique
• added highlighted fields

How To Test

You can use this script for testing. It runs through a lot more CloudFormation API calls than just the ones that trigger this rule as I plan to use this same script for additional API activity I'll be adding coverage for. To manually test you can follow AWS documentation for CreateStack which is the simplest, or CreateStackSet + CreateStackInstances which is a bit more complex. My script covers both these scenarios.

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