This rule detects unauthorized or risky additions of ingress rules to AWS RDS security groups by monitoring CloudTrail for AuthorizeDBSecurityGroupIngress events. It flags when a new ingress rule is created that could expose an RDS instance to external networks, especially when the CIDR IP (requestParameters.cIDRIP) is overly permissive (for example, 0.0.0.0/0) or when the same CIDR has been previously authorized by the same user within the last 24 hours. The rule correlates the actor (userIdentity) and the target security group (requestParameters:dBSecurityGroupName) with the action (eventName AuthorizeDBSecurityGroupIngress) to identify potential account manipulation or firewall policy tampering. A DedupPeriodMinutes of 60 prevents duplicate alerts for the same activity, and a Threshold of 1 means a single matching event will generate an alert. The Runbook calls for: (1) checking all security group ingress authorizations by the user ARN in the past 24 hours, (2) verifying if the CIDR range is overly permissive or previously used by that user, and (3) monitoring for external database connection attempts within 6 hours after the rule is added. The rule aligns with MITRE ATT&CK techniques TA0003:T1098 (Account Manipulation) and TA0005:T1562.007 (Impair Defenses: Modify Cloud Firewall). Tests illustrate various scenarios: Ingress Authorized from a specific CIDR (expected true), Ingress Authorized from public internet (0.0.0.0/0) (expected true/critical), Ingress Authorized from an EC2 security group (expected true), Authorization Failed (expected false), and a different RDS event (expected false). This rule relies on AWS CloudTrail logs (AWS.CloudTrail) to detect changes to RDS security group ingress rules and to trigger investigations into potential persistence, lateral movement, or data exposure opportunities. Practical impact: high-risk when permissive rules are introduced; false positives may occur for legitimate administrative tasks that require temporary broad access. Operators should validate with the Runbook and follow up with monitoring for anomalous connection attempts and broader access patterns._