AWS RDS Security Group Deletion

 1[metadata]
 2creation_date = "2021/06/05"
 3integration = ["aws"]
 4maturity = "production"
 5updated_date = "2025/01/15"
 6
 7[rule]
 8author = ["Elastic", "Austin Songer"]
 9description = "Identifies the deletion of an Amazon Relational Database Service (RDS) Security group."
10false_positives = [
11    """
12    An RDS security group deletion may be done by a system or network administrator. Verify whether the user identity,
13    user agent, and/or hostname should be making changes in your environment. Security group deletions by unfamiliar
14    users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the
15    rule.
16    """,
17]
18from = "now-60m"
19index = ["filebeat-*", "logs-aws.cloudtrail-*"]
20interval = "10m"
21language = "kuery"
22license = "Elastic License v2"
23name = "AWS RDS Security Group Deletion"
24note = """## Triage and analysis
25
26> **Disclaimer**:
27> 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.
28
29### Investigating AWS RDS Security Group Deletion
30
31Amazon RDS Security Groups control access to RDS instances, acting as a virtual firewall. Adversaries may delete these groups to disrupt database access or cover their tracks. The detection rule monitors AWS CloudTrail logs for successful deletion events of RDS Security Groups, signaling potential unauthorized activity. This helps security analysts quickly identify and respond to suspicious deletions.
32
33### Possible investigation steps
34
35- Review the AWS CloudTrail logs to confirm the event details, focusing on the event.provider:rds.amazonaws.com and event.action:DeleteDBSecurityGroup fields to ensure the deletion event is accurately captured.
36- Identify the user or role associated with the event by examining the user identity information in the CloudTrail logs to determine if the action was performed by an authorized entity.
37- Check the event time and correlate it with other security events or alerts to identify any suspicious activity patterns or sequences that might indicate a broader attack.
38- Investigate the context of the deletion by reviewing recent changes or activities in the AWS account, such as modifications to IAM policies or unusual login attempts, to assess if the deletion is part of a larger unauthorized access attempt.
39- Contact the relevant database or cloud infrastructure team to verify if the deletion was intentional and authorized, ensuring that it aligns with any ongoing maintenance or decommissioning activities.
40
41### False positive analysis
42
43- Routine maintenance activities by authorized personnel may trigger the rule. To manage this, create exceptions for known maintenance windows or specific user accounts that regularly perform these tasks.
44- Automated scripts or tools used for infrastructure management might delete security groups as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or tags.
45- Changes in security group configurations during scheduled updates or migrations can result in deletions. Document these events and adjust the detection rule to ignore deletions during these planned activities.
46- Testing environments often involve frequent creation and deletion of resources, including security groups. Exclude these environments from monitoring by using environment-specific tags or identifiers.
47
48### Response and remediation
49
50- Immediately isolate the affected RDS instance by modifying its security group settings to restrict all inbound and outbound traffic, preventing further unauthorized access.
51- Review AWS CloudTrail logs to identify the source of the deletion request, including the IAM user or role involved, and assess whether the credentials have been compromised.
52- Recreate the deleted RDS Security Group with the appropriate rules and reassign it to the affected RDS instance to restore normal operations.
53- Conduct a thorough audit of IAM permissions to ensure that only authorized personnel have the ability to delete RDS Security Groups, and revoke any unnecessary permissions.
54- Implement multi-factor authentication (MFA) for all IAM users with permissions to modify RDS Security Groups to enhance security and prevent unauthorized changes.
55- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.
56- Update incident response plans and security policies based on the findings to prevent similar incidents in the future and improve overall cloud security posture.
57
58## Setup
59
60The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
61references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBSecurityGroup.html"]
62risk_score = 21
63rule_id = "863cdf31-7fd3-41cf-a185-681237ea277b"
64severity = "low"
65tags = [
66    "Domain: Cloud",
67    "Data Source: AWS",
68    "Data Source: Amazon Web Services",
69    "Data Source: AWS RDS",
70    "Tactic: Impact",
71    "Resources: Investigation Guide",
72]
73timestamp_override = "event.ingested"
74type = "query"
75
76query = '''
77event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:DeleteDBSecurityGroup and event.outcome:success
78'''
79
80
81[[rule.threat]]
82framework = "MITRE ATT&CK"
83[[rule.threat.technique]]
84id = "T1531"
85name = "Account Access Removal"
86reference = "https://attack.mitre.org/techniques/T1531/"
87
88
89[rule.threat.tactic]
90id = "TA0040"
91name = "Impact"
92reference = "https://attack.mitre.org/tactics/TA0040/"