AWS RDS Security Group Creation

 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 creation of an Amazon Relational Database Service (RDS) Security group."
10false_positives = [
11    """
12    An RDS security group may be created by a system or network administrator. Verify whether the user identity, user
13    agent, and/or hostname should be making changes in your environment. Security group creations by unfamiliar users or
14    hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
15    """,
16]
17from = "now-60m"
18index = ["filebeat-*", "logs-aws.cloudtrail-*"]
19interval = "10m"
20language = "kuery"
21license = "Elastic License v2"
22name = "AWS RDS Security Group Creation"
23note = """## Triage and analysis
24
25> **Disclaimer**:
26> 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.
27
28### Investigating AWS RDS Security Group Creation
29
30Amazon RDS Security Groups control access to RDS instances, acting as virtual firewalls. Adversaries may exploit this by creating unauthorized security groups to maintain persistence or exfiltrate data. The detection rule monitors successful creation events of RDS security groups, flagging potential misuse by correlating specific AWS CloudTrail logs, thus aiding in identifying unauthorized access attempts.
31
32### Possible investigation steps
33
34- Review the AWS CloudTrail logs for the event.action:CreateDBSecurityGroup to identify the user or role responsible for the creation of the RDS security group.
35- Check the event.provider:rds.amazonaws.com logs to gather additional context about the RDS instance associated with the newly created security group.
36- Investigate the event.outcome:success logs to confirm the successful creation and assess if it aligns with expected administrative activities.
37- Analyze the associated AWS account and user activity to determine if there are any anomalies or unauthorized access patterns.
38- Cross-reference the security group details with existing security policies to ensure compliance and identify any deviations.
39- Evaluate the permissions and rules associated with the new security group to assess potential risks or exposure to sensitive data.
40
41### False positive analysis
42
43- Routine administrative tasks may trigger the rule when authorized personnel create new RDS security groups for legitimate purposes. To manage this, establish a list of known IP addresses or user accounts that frequently perform these tasks and create exceptions for them.
44- Automated deployment tools or scripts that create RDS security groups as part of infrastructure provisioning can lead to false positives. Identify these tools and their associated accounts, then configure the rule to exclude these specific actions.
45- Scheduled maintenance or updates that involve creating new security groups might be flagged. Document these scheduled activities and adjust the rule to recognize and exclude them during the specified time frames.
46- Testing environments where security groups are frequently created and deleted for development purposes can generate alerts. Implement tagging or naming conventions for test environments and exclude these from the rule's scope.
47
48### Response and remediation
49
50- Immediately review the AWS CloudTrail logs to confirm the unauthorized creation of the RDS security group and identify the source IP and user account involved in the action.
51- Revoke any unauthorized security group rules associated with the newly created RDS security group to prevent further unauthorized access or data exfiltration.
52- Temporarily disable or delete the unauthorized RDS security group to contain the threat and prevent persistence.
53- Conduct a thorough audit of all AWS IAM roles and permissions to ensure that only authorized users have the ability to create or modify RDS security groups.
54- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised.
55- Implement additional monitoring and alerting for any future RDS security group creation events to quickly detect and respond to similar threats.
56- Review and update AWS security policies and access controls to prevent unauthorized security group creation, ensuring alignment with best practices for least privilege.
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_CreateDBSecurityGroup.html"]
62risk_score = 21
63rule_id = "378f9024-8a0c-46a5-aa08-ce147ac73a4e"
64severity = "low"
65tags = [
66    "Domain: Cloud",
67    "Data Source: AWS",
68    "Data Source: Amazon Web Services",
69    "Data Source: AWS RDS",
70    "Tactic: Persistence",
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:CreateDBSecurityGroup and event.outcome:success
78'''
79
80
81[[rule.threat]]
82framework = "MITRE ATT&CK"
83[[rule.threat.technique]]
84id = "T1136"
85name = "Create Account"
86reference = "https://attack.mitre.org/techniques/T1136/"
87[[rule.threat.technique.subtechnique]]
88id = "T1136.003"
89name = "Cloud Account"
90reference = "https://attack.mitre.org/techniques/T1136/003/"
91
92
93
94[rule.threat.tactic]
95id = "TA0003"
96name = "Persistence"
97reference = "https://attack.mitre.org/tactics/TA0003/"