nldcsc-elastic-rules 0.0.8__py3-none-any.whl → 0.0.16__py3-none-any.whl

nldcsc_elastic_rules/rules/integrations/aws/impact_efs_filesystem_deleted.toml

@@ -0,0 +1,174 @@
+[metadata]
+creation_date = "2021/08/27"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/11/26"
+
+[rule]
+author = ["Austin Songer", "Elastic"]
+description = """
+Identifies the deletion of an Amazon EFS file system using the "DeleteFileSystem" API operation. Deleting an EFS file
+system permanently removes all stored data and cannot be reversed. This action is rare in most environments and
+typically limited to controlled teardown workflows. Adversaries with sufficient permissions may delete a file system to
+destroy evidence, disrupt workloads, or impede recovery efforts.
+"""
+false_positives = [
+    """
+    Legitimate teardown or environment decommissioning processes may delete EFS file systems. Verify whether the calling
+    user, role, automation system, or CI/CD workflow is expected to perform destructive actions in the affected account.
+    File system deletions by unfamiliar identities, from unusual IP addresses, or occurring outside approved change
+    windows should be carefully reviewed. If known automation routinely deletes ephemeral test file systems, consider
+    adding scoped exceptions.
+    """,
+]
+from = "now-6m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "AWS EFS File System Deleted"
+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, validate and adapt it to suit your operational needs.
+
+### Investigating AWS EFS File System Deleted
+
+Amazon Elastic File System (EFS) provides scalable, shared file storage used by EC2, container workloads, analytics jobs, and other persistent applications. Deleting an EFS file system (`DeleteFileSystem`) permanently removes all stored data and cannot be recovered. Mount targets must already be deleted, but those operations are common and do not themselves indicate malicious behavior. This rule focuses exclusively on the irreversible destructive event, which may signal intentional data destruction, ransomware preparation, or a post-compromise cleanup effort.
+
+#### Possible investigation steps
+
+- **Identify the actor and calling context**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.
+  - Check `source.ip`, `user_agent.original`, and whether the call originated via console, IAM role, STS session, or long-lived IAM key.
+  - Verify whether this principal typically manages EFS resources or teardown activities.
+
+- **Determine what was deleted**
+  - Inspect `aws.cloudtrail.request_parameters` to identify the deleted file system ID.
+  - Map the resource to:
+    - Application or owner team
+    - Environment classification (prod / dev / test)
+    - Dependency surfaces (EC2 instances, ECS tasks, Lambda, analytics pipelines)
+
+- **Reconstruct timeline and intent**
+  - Use `@timestamp` to correlate with:
+    - Recent `UpdateFileSystem` events (e.g., deletion protection, lifecycle policies)
+    - IAM policy or trust policy changes
+    - EC2 or container runtime disruption shortly before deletion
+    - Unexpected regional activity or off-hours execution
+  - Determine if mount target deletions occurred immediately beforehand (expected lifecycle) or unexpectedly earlier (possibly suspicious when paired with other anomalies).
+
+- **Correlate with broader account activity**
+  - Pivot in CloudTrail on:
+    - The same access key or session
+    - The same EFS file system ID
+  - Look for:
+    - Privilege escalation (new policy attachments, role assumptions)
+    - Lateral movement (SSM sessions, unusual EC2 access)
+    - Signs of cleanup or anti-forensics (CloudWatch log group deletions, RDS snapshot deletions)
+    - Network isolation actions (security-group or NACL updates)
+
+- **Validate with owners**
+  - Confirm with application or infrastructure teams:
+    - Whether the deletion was planned, approved, or part of an environment teardown
+    - Whether a migration or infrastructure rotation is in progress
+    - Whether the deleted file system contained production or sensitive workloads
+
+### False positive analysis
+
+- **Expected teardown activity**
+  - Some pipelines (Terraform, CloudFormation, CDK, custom IaC) delete file systems as part of environment rotation or decommissioning.
+  - Add exceptions for known automation roles or environment tags (e.g., `Environment=Dev`).
+
+- **Ephemeral test environments**
+  - Development, QA, or integration test accounts may routinely create and destroy EFS file systems.
+  - Suppress events for non-production accounts where destructive operations are normal.
+
+- **Automated housekeeping**
+  - Internal tooling or lifecycle processes may remove unused EFS resources.
+  - Identify automation roles and use exceptions based on `aws.cloudtrail.user_identity.arn` or `user_agent.original`.
+
+### Response and remediation
+
+- **Contain and secure**
+  - If unauthorized, revoke or disable the credentials used for the deletion.
+  - Review CloudTrail for additional destructive or privilege-escalating operations from the same actor.
+  - Validate whether any associated compute workloads (EC2, ECS, Lambda) show compromise indicators.
+
+- **Assess impact**
+  - Identify workloads impacted by the file system deletion.
+  - Determine whether alternate backups exist (EFS-to-EFS Backup, AWS Backup vaults).
+  - Evaluate operational disruption and data-loss implications, especially for compliance-bound data.
+
+- **Recover (if possible)**
+  - Restore from AWS Backup if a protected resource existed.
+  - Rebuild infrastructure dependencies that relied on the deleted file system.
+
+- **Hardening and prevention**
+  - Restrict use of `elasticfilesystem:DeleteFileSystem` to tightly controlled IAM roles.
+  - Use IAM conditions (e.g., `aws:PrincipalArn`, `aws:SourceIp`, `aws:RequestedRegion`) to limit destructive operations.
+  - Ensure AWS Backup policies include EFS resources with sufficient retention.
+  - Use AWS Config or Security Hub controls to detect:
+    - EFS file systems without backup plans
+    - Unexpected changes to file system policies
+
+### 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/efs/latest/ug/API_DeleteFileSystem.html",
+    "https://docs.aws.amazon.com/efs/latest/ug/API_DeleteMountTarget.html",
+]
+risk_score = 47
+rule_id = "536997f7-ae73-447d-a12d-bff1e8f5f0a0"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS EFS",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset: "aws.cloudtrail" 
+    and event.provider: "elasticfilesystem.amazonaws.com" 
+    and event.action: "DeleteFileSystem" 
+    and event.outcome: "success"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1485"
+name = "Data Destruction"
+reference = "https://attack.mitre.org/techniques/T1485/"
+
+
+[rule.threat.tactic]
+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",
+    "target.entity.id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters"
+]

nldcsc_elastic_rules/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",
+]
+

nldcsc_elastic_rules/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml

@@ -2,71 +2,137 @@
 creation_date = "2020/05/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/11/24"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the deletion of an Amazon Relational Database Service (RDS) Aurora database cluster, global database cluster,
-or database instance.
+Identifies the deletion of an Amazon RDS DB instance, Aurora cluster, or global database cluster. Deleting these
+resources permanently destroys stored data and can cause major service disruption. Adversaries with sufficient
+permissions may delete RDS resources to impede recovery, destroy evidence, or inflict operational impact on the
+environment.
 """
 false_positives = [
     """
-    Clusters or instances may be deleted by a system administrator. Verify whether the user identity, user agent, and/or
-    hostname should be making changes in your environment. Cluster or instance deletions by unfamiliar users or hosts
-    should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    RDS instances or clusters may be intentionally deleted by database administrators or during planned decommissioning
+    activities. Verify the user identity, source IP, and change context to ensure the deletion is expected.
+    CloudFormation stack removals and automated cleanup workflows may also trigger these events and can be exempted if
+    known and authorized.
     """,
 ]
-from = "now-60m"
+from = "now-6m"
 index = ["filebeat-*", "logs-aws.cloudtrail-*"]
-interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
-name = "AWS Deletion of RDS Instance or Cluster"
+name = "AWS RDS DB Instance or Cluster Deleted"
 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.
-
-### Investigating AWS Deletion of RDS Instance or Cluster
-
-Amazon RDS simplifies database management by automating tasks like setup and scaling. However, adversaries can exploit this by deleting RDS instances or clusters, causing data loss and service disruption. The detection rule monitors AWS CloudTrail logs for successful deletion actions, alerting security teams to potential malicious activity aimed at data destruction.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to confirm the event details, focusing on the event.provider as rds.amazonaws.com and event.action values such as DeleteDBCluster, DeleteGlobalCluster, or DeleteDBInstance.
-- Identify the user or role responsible for the deletion by examining the user identity information in the CloudTrail logs, and verify if the action aligns with their typical behavior or responsibilities.
-- Check the event time and correlate it with any other suspicious activities or alerts in the AWS environment to determine if the deletion is part of a broader attack pattern.
-- Investigate the context of the deletion by reviewing recent changes or activities in the AWS account, such as IAM policy changes or unusual login attempts, to assess if the account may have been compromised.
-- Assess the impact of the deletion by identifying the specific RDS instance or cluster affected and determining the potential data loss or service disruption caused by the action.
-- Contact the responsible team or individual to verify if the deletion was intentional and authorized, and if not, initiate incident response procedures to mitigate further risk.
+> 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, validate and adapt it to suit your operational needs.
+
+### Investigating AWS RDS DB Instance or Cluster Deleted
+
+This rule detects the deletion of an RDS DB instance, Aurora DB cluster, or global database cluster. These operations permanently remove stored data and backups unless final snapshots are explicitly retained. Adversaries may delete RDS resources as part of a destructive attack, to eliminate forensic evidence, or to disrupt critical workloads. Because deletions are irreversible without backups, immediate review is required to determine whether the action was authorized and assess potential data loss.
+
+#### Possible investigation steps
+
+**Identify the Actor**
+- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who performed the action.
+- Validate:
+  - Is this user/role authorized to delete DB instances or clusters?
+  - Does this action align with past behavior?
+
+**Review the Deletion Event**
+- Confirm which action was invoked: `DeleteDBInstance`, `DeleteDBCluster` or `DeleteGlobalCluster`
+- Examine `aws.cloudtrail.request_parameters` and `target.entity.id`. Identify which resource was deleted and whether a final snapshot was created before deletion.
+
+**Analyze Source and Access Context**
+- Check `source.ip`, `source.geo` fields and `user_agent.original`
+- Validate whether:
+  - The request originated from a known network or VPN.
+  - The user normally logs in from this location.
+  - The call was made via AWS Console vs CLI vs SDK.
+
+**Correlate Surrounding Activity**
+Search CloudTrail for:
+- Recent IAM role or policy changes.
+- Privilege escalation events (STS AssumeRole, CreateAccessKey, AttachUserPolicy).
+- Disablement of related safety controls:
+  - deletionProtection modified to `false`
+  - backupRetentionPeriod set to `0`
+- Suspicious sequencing:
+  - Snapshots deleted before the instance/cluster deletion.
+  - Network security group modifications enabling broader access before deletion.
+
+**Validate Organizational Intent**
+- Contact the service owner or DB administrator to confirm whether the deletion is expected.
+
+**Assess Impact and Data Recovery Path**
+- Identify which DB instance or cluster was deleted (`target.entity.id`)
+- Evaluate:
+  - Whether automated backups existed.
+  - Whether point-in-time recovery is still possible.
+  - Whether a final snapshot was created.
 
 ### False positive analysis
 
-- Routine maintenance activities by database administrators can trigger alerts when they intentionally delete RDS instances or clusters. To manage this, create exceptions for known maintenance windows or specific administrator actions.
-- Automated scripts or tools used for testing and development purposes might delete RDS resources as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user or role identifiers.
-- Scheduled decommissioning of outdated or unused RDS instances can also result in false positives. Maintain an updated list of decommissioning schedules and exclude these from the detection rule.
-- CloudFormation stack deletions that include RDS resources can lead to alerts. Monitor CloudFormation activities and correlate them with RDS deletions to differentiate between legitimate and suspicious actions.
+- **Planned decommissioning**:  
+  - Confirm if this action aligns with a scheduled removal or environment cleanup.
+- **CloudFormation stack deletion**:  
+  - Stack teardown often deletes RDS resources; confirm if this occurred.
+- **Automated testing or ephemeral environments**:  
+  - Test/dev pipelines may frequently create and delete clusters.
+- **Infrastructure-as-code workflows**:  
+  - Terraform destroys or GitOps cleanup jobs can generate legitimate deletion events.
 
 ### Response and remediation
 
-- Immediately isolate the affected AWS account to prevent further unauthorized actions. This can be done by revoking access keys and disabling any suspicious IAM user accounts or roles involved in the deletion.
-- Initiate a recovery process for the deleted RDS instance or cluster using available backups or snapshots. Ensure that the restoration is performed in a secure environment to prevent further compromise.
-- Conduct a thorough review of AWS CloudTrail logs to identify any unauthorized access patterns or anomalies leading up to the deletion event. This will help in understanding the scope of the breach and identifying potential entry points.
-- Escalate the incident to the organization's security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data were affected.
-- Implement enhanced monitoring and alerting for AWS RDS and other critical resources to detect similar deletion attempts in the future. This includes setting up alerts for any unauthorized changes to IAM policies or roles.
-- Review and strengthen IAM policies to ensure the principle of least privilege is enforced, reducing the risk of unauthorized deletions by limiting permissions to only those necessary for specific roles.
-- Communicate with stakeholders and affected parties about the incident, outlining the steps taken for recovery and measures implemented to prevent future occurrences.
-
-## Setup
-
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+**If the deletion was unauthorized:**
+**Immediately restrict the actor**
+   - Disable or revoke the user’s access keys.
+   - Revoke active session tokens.
+
+**Attempt recovery**
+   - Restore from:
+     - Final snapshot (if created)
+     - Automated backups
+   - Rebuild cluster/instance configurations based on IaC or documented templates.
+
+**Perform full log review**
+   - CloudTrail, RDS Enhanced Monitoring, and VPC Flow Logs
+   - Identify lateral movement or privilege escalation preceding the deletion.
+
+**Scope and contain the incident**
+   - Determine whether:
+     - Additional RDS resources were targeted
+     - IAM permissions were modified
+     - Other destructive API calls were made
+
+**Hardening actions**
+   - Enable deletionProtection on all critical instances/clusters.
+   - Require final snapshot creation for all deletion operations.
+   - Enforce MFA for IAM users with RDS privileges.
+   - Limit RDS modification/deletion permissions to specific IAM roles.
+
+**Documentation and Follow-Up**
+   - Update incident response runbooks.
+   - Communicate with service owners and leadership.
+   - Add enhanced monitoring rules around:
+     - Snapshot deletions
+     - Backup retention modifications
+     - RDS role changes
+     - DeletionProtection disable events
+
+### 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://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/delete-db-cluster.html",
     "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBCluster.html",
-    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/delete-global-cluster.html",
     "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteGlobalCluster.html",
-    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/delete-db-instance.html",
     "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBInstance.html",
 ]
 risk_score = 47
@@ -85,8 +151,10 @@ timestamp_override = "event.ingested"
 type = "query"
 
 query = '''
-event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:(DeleteDBCluster or DeleteGlobalCluster or DeleteDBInstance)
-and event.outcome:success
+event.dataset: aws.cloudtrail 
+    and event.provider: rds.amazonaws.com 
+    and event.action: (DeleteDBCluster or DeleteGlobalCluster or DeleteDBInstance)
+    and event.outcome: success
 '''
 
 
@@ -103,3 +171,21 @@ 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",
+    "target.entity.id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements",
+]
+