[Rule Tuning] AWS KMS Customer Managed Key Disabled or Scheduled for Deletion

rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml

@@ -2,68 +2,124 @@
 creation_date = "2022/09/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/12/05"
 
 [rule]
 author = ["Xavier Pich"]
 description = """
-Identifies attempts to disable or schedule the deletion of an AWS KMS Customer Managed Key (CMK). Deleting an AWS KMS
-key is destructive and potentially dangerous. It deletes the key material and all metadata associated with the KMS key
-and is irreversible. After a KMS key is deleted, the data that was encrypted under that KMS key can no longer be
-decrypted, which means that data becomes unrecoverable.
+Identifies attempts to disable or schedule the deletion of an AWS customer managed KMS Key. Disabling or scheduling a
+KMS key for deletion removes the ability to decrypt data encrypted under that key and can permanently destroy access to
+critical resources. Adversaries may use these operations to cause irreversible data loss, disrupt business operations,
+impede incident response, or hide evidence of prior activity. Because KMS keys often protect sensitive or regulated
+data, any modification to their lifecycle should be considered highly sensitive and investigated promptly.
 """
 false_positives = [
     """
-    A KMS customer managed key may be disabled or scheduled for deletion by a system administrator. Verify whether the
+    A customer managed KMS key may be disabled or scheduled for deletion by a system administrator. Verify whether the
     user identity, user agent, and/or hostname should be making changes in your environment. Key deletions by unfamiliar
     users should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
     """,
 ]
-from = "now-60m"
+from = "now-6m"
 index = ["filebeat-*", "logs-aws.cloudtrail-*"]
-interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS KMS Customer Managed Key Disabled or Scheduled for Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. 
+> While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 
 ### Investigating AWS KMS Customer Managed Key Disabled or Scheduled for Deletion
 
-AWS Key Management Service (KMS) allows users to create and manage cryptographic keys for data encryption. Customer Managed Keys (CMKs) are crucial for securing sensitive data. Adversaries may disable or schedule deletion of CMKs to render encrypted data inaccessible, causing data loss. The detection rule monitors successful disablement or deletion attempts, alerting analysts to potential data destruction activities.
+AWS KMS keys underpin encryption for S3, EBS, RDS, Secrets Manager, Lambda, and numerous other AWS services. Disabling a KMS key or scheduling its deletion immediately disrupts encryption and decryption workflows, and, once deleted, renders all data encrypted with that key unrecoverable.
 
-### Possible investigation steps
+Because these operations are rare, highly privileged, and tightly controlled in mature environments, they should be treated as high-risk, destructive actions when performed unexpectedly. Adversaries may disable or delete KMS keys to sabotage recovery, impede forensic analysis, or destroy evidence after exfiltration.
 
-- Review the CloudTrail logs for the specific event.dataset:aws.cloudtrail entries to identify the user or role that initiated the DisableKey or ScheduleKeyDeletion action.
-- Check the event.provider:kms.amazonaws.com logs to gather additional context about the KMS key involved, including its key ID and any associated metadata.
-- Investigate the event.action:("DisableKey" or "ScheduleKeyDeletion") to determine if the action was authorized and aligns with recent changes or requests within the organization.
-- Analyze the event.outcome:success to confirm the success of the action and assess the potential impact on encrypted data.
-- Cross-reference the timing of the event with any known incidents or maintenance activities to rule out false positives or expected behavior.
-- Contact the user or team responsible for the action to verify the intent and ensure it was a legitimate operation.
+
+#### Possible investigation steps
+
+- **Identify the actor and authentication context**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine the caller.
+  - Check `source.ip`, `source.geo` fields, and `user_agent.original` to determine whether the action originated from an expected network path or automation platform.
+  - Compare the actor and access key to historical usage patterns.
+
+- **Determine what key was affected and its criticality**
+  - Inspect `aws.cloudtrail.resources.arn` to identify the KMS key.
+  - Determine:
+    - The services and data protected by the key (e.g., RDS, EBS, S3, Secrets Manager).
+    - The environment (prod vs. dev).
+    - Owner or application team.
+
+- **Understand the scope and intent of the change**
+  - For `DisableKey`, determine whether a dependent service immediately began failing or experienced decryption errors.
+  - For `ScheduleKeyDeletion`, examine the `PendingWindowInDays` value within `aws.cloudtrail.request_parameters`.
+  - Check whether the key was previously rotated, enabled/disabled, or had its policy recently modified.
+
+- **Correlate with surrounding events**
+  - Look for:
+    - IAM policy changes granting new KMS privileges.
+    - Access anomalies involving the same principal.
+    - File system, database, or backup deletions near the same timeframe.
+    - S3, EBS, or RDS resources showing encryption failures.
+  - Determine whether other keys were modified in the same window (possible broader sabotage attempt).
+
+- **Validate intent with owners**
+  - Confirm with the application, data, or security owners:
+    - Whether deactivation or scheduled deletion was requested.
+    - Whether the key was being replaced, migrated, or retired.
 
 ### False positive analysis
 
-- Routine key management activities by authorized personnel can trigger alerts. Regularly review and document key management procedures to differentiate between legitimate and suspicious activities.
-- Automated scripts or tools used for key rotation or lifecycle management might disable or schedule deletion of keys as part of their process. Identify and whitelist these scripts or tools to prevent unnecessary alerts.
-- Testing environments where keys are frequently created and deleted for development purposes can generate false positives. Exclude these environments from monitoring or adjust the rule to focus on production environments.
-- Scheduled maintenance or compliance audits may involve disabling keys temporarily. Coordinate with relevant teams to schedule these activities and temporarily adjust monitoring rules to avoid false alerts.
-- Misconfigured alerts due to incorrect tagging or categorization of keys can lead to false positives. Ensure that all keys are correctly tagged and categorized to align with monitoring rules.
+- **Planned key lifecycle activities**
+  - Some organizations disable KMS keys before rotation, migration, or decommissioning.
+  - Scheduled deletion during infrastructure teardown may be expected in CI/CD-driven ephemeral environments.
 
-### Response and remediation
+- **Configuration errors**
+  - Misapplied tags or incorrect CloudFormation teardown workflows can unintentionally disable or schedule deletion of KMS keys.
 
-- Immediately verify the legitimacy of the disablement or deletion action by contacting the key owner or relevant stakeholders to confirm if the action was intentional.
-- If the action was unauthorized, revoke any access credentials or permissions associated with the user or service that performed the action to prevent further unauthorized activities.
-- Restore access to encrypted data by identifying any backup keys or data recovery options available, and initiate data recovery procedures if possible.
-- Escalate the incident to the security operations team and relevant management to assess the impact and coordinate a broader response if necessary.
-- Implement additional monitoring and alerting for any further attempts to disable or delete KMS keys, ensuring that alerts are sent to the appropriate personnel for rapid response.
-- Review and tighten IAM policies and permissions related to KMS key management to ensure that only authorized personnel have the ability to disable or delete keys.
-- Conduct a post-incident review to identify any gaps in the current security posture and update incident response plans to address similar threats in the future.
+If any of the above conditions apply, consider adjusting rule exceptions based on IAM principal, environment tag, or automation role.
 
-## Setup
+### Response and remediation
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+- **Contain and validate**
+  - Immediately confirm whether the key disablement or deletion schedule was intentional.
+  - If unauthorized, cancel scheduled deletion (`CancelKeyDeletion`) and re-enable the key (`EnableKey`) as appropriate.
+  - Rotate credentials or access keys used by the actor if compromise is suspected.
+
+- **Assess impact**
+  - Identify all AWS services and data encrypted with the affected KMS key.
+  - Review logs and service metrics for failures involving:
+    - EBS volume attachments
+    - RDS instance decryption
+    - S3 object access
+    - Secrets Manager retrieval
+    - Lambda environment variable decryption
+
+- **Investigate for compromise**
+  - Review CloudTrail activity for the principal:
+    - Permission escalations
+    - Unusual STS role assumptions
+    - S3, EC2, RDS destructive behavior
+  - Look for preceding data access or exfiltration attempts.
+
+- **Strengthen controls**
+  - Restrict AWS KMS lifecycle permissions (`kms:DisableKey`, `kms:ScheduleKeyDeletion`) to a very small privileged set.
+  - Use AWS Organizations SCPs to prevent KMS key deletion in production accounts.
+  - Enable AWS Config rules for KMS key state monitoring.
+  - Require MFA for administrators capable of key management.
+
+- **Post-incident improvement**
+  - Update runbooks to include KMS lifecycle change approvals.
+  - Implement tagging standards to designate high-risk keys.
+  - Enhance monitoring for key policy modifications or changes to principal permissions.
+
+### Additional information
+- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
+- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
+- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
+"""
 references = [
     "https://docs.aws.amazon.com/cli/latest/reference/kms/disable-key.html",
     "https://docs.aws.amazon.com/cli/latest/reference/kms/schedule-key-deletion.html",
@@ -84,7 +140,10 @@ timestamp_override = "event.ingested"
 type = "query"
 
 query = '''
-event.dataset:aws.cloudtrail and event.provider:kms.amazonaws.com and event.action:("DisableKey" or "ScheduleKeyDeletion") and event.outcome:success
+event.dataset: "aws.cloudtrail"
+    and event.provider: "kms.amazonaws.com" 
+    and event.action: ("DisableKey" or "ScheduleKeyDeletion") 
+    and event.outcome: "success"
 '''
 
 
@@ -101,3 +160,22 @@ id = "TA0040"
 name = "Impact"
 reference = "https://attack.mitre.org/tactics/TA0040/"
 
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
+    "aws.cloudtrail.user_identity.access_key_id",
+    "aws.cloudtrail.resources.arn",
+    "aws.cloudtrail.resources.type",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements",
+]
+