Closed imays11 closed 2 months ago
These guidelines serve as a reminder set of considerations when proposing a new rule.
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.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.
Issue link(s):
Summary - What I changed
This rule detects the first time a principal calls AWS Cloudwatch
CreateStack
orCreateStackSet
API. Cloudformation is used to create a single collection of cloud resources called a stack, via a defined template file. An attacker with the appropriate privileges could leverage Cloudformation to create specific resources needed to further exploit the environment. This is a new terms rule that looks for the first instance of this behavior in the last 10 days for a role or IAM user within a particular account.--
The fields chosen for new_terms is very intentional here. I needed to account for both Roles and IAM user types. The problem with Roles and new_terms is that there is a
session_name
attached to therole_name
which is different every time a new session is created using that particular role. This means for fields likeuser.id
oraws.cloudtrail.user_identity.arn
, we can't isolate the role name itself, instead we are capturing the role name and the session name which will mean lots of false positives because everyrole.name+session.name
combination will appear to be "new". I could utilizeaws.cloudtrail.user_identity.session_context.session_issuer.arn
if I were only concerned with capturing events fromAssumedRoles
, but since I want to capture events for long-term IAM users as well, this field won't work as it's only created when Roles are assumed. This leaves us withuser.name
field. The only problem here was that in an "Organization" there can be several different accounts with differentcloud.account.ids
all being monitored through the same Cloudtrail logs. IAM User and Role names can be duplicated across different accounts, which might create false positives if those logs are being ingested together. To correct for this I am using bothuser.name
andcloud.account.id
as thenew_terms_fields
value so that ideally this rule will trigger for the first time occurance of a uniquerole/user name + cloud.account.id
combination.Checklist
bug
,enhancement
,schema
,Rule: New
,Rule: Deprecation
,Rule: Tuning
,Hunt: New
, orHunt: Tuning
so guidelines can be generated