How to Use CloudTrail to See Who Modified a Security Group

Use AWS CloudTrail to determine who modified a security group by locating specific API events in CloudTrail logs. When a security group is changed, CloudTrail records the identity of the caller, the time of the event, and the exact API action performed. This guide explains which CloudTrail events indicate a security group modification, where to search in the CloudTrail console and CLI, and how to connect related logs to build an accurate timeline. The approach is framed for ongoing compliance and incident response so you can reliably answer who changed what and when.

Key CloudTrail Events for Security Group Changes

CloudTrail captures management events for security group operations. The most common events indicating a modification include:

• ModifySecurityGroupRules
• AuthorizeSecurityGroupIngress
• AuthorizeSecurityGroupEgress
• RevokeSecurityGroupIngress
• RevokeSecurityGroupEgress
• CreateSecurityGroup and DeleteSecurityGroup for lifecycle changes

These events appear in the CloudTrail event history for your account and include the user identity, source IP, and request parameters. You can filter by event name and time range to narrow your search.

Where CloudTrail Stores Security Group Modification Logs

CloudTrail logs are stored in an S3 bucket you designate when you enable CloudTrail. Each log file contains a JSON structure with one or more records for each API call. To find who modified a security group:

For long-term analysis, you can stream CloudTrail logs to a CloudWatch Logs group and use metric filters or subscription filters to alert on specific events.

Practical Investigation Steps

Follow these steps to identify the actor and scope of a security group change:

Repeat this workflow across all applicable regions if you use multi-region security groups. Document findings and preserve the CloudTrail log files for audit purposes.

Using the AWS CLI to Query Security Group Changes

The AWS CLI provides powerful options to search CloudTrail logs stored in S3. You can use aws cloudtrail lookup-events for recent events or query historical logs with aws cloudtrail select-event or Athena if you store logs in Amazon S3 and use Amazon Athena to query them. Common CLI patterns include filtering by:

• Event name: ModifySecurityGroupRules, AuthorizeSecurityGroupIngress, RevokeSecurityGroupIngress, etc.
• Resource type or IDs to narrow to specific security groups.
• Time range using --start-time and --end-time.
• Caller identity fields to locate specific users or roles.

Example (conceptual): aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=ModifySecurityGroupRules --start-time YYYY-MM-DDTHH:MM:SSZ --region region. Adjust attributes to match the event and filter by security group ID in the output JSON. For advanced analysis, export logs to Amazon Athena and use SQL queries to join multiple events and users.

Interpreting CloudTrail Event Details for Security Groups

A CloudTrail event includes detailed metadata you can use to understand the scope and impact of a security group change. Key fields to review include:

Review these fields to confirm whether the change was expected. If the source IP is unfamiliar, consider additional investigation steps such as VPC Flow Logs or GuardDuty findings.

Best Practices for Ongoing Monitoring

To reliably answer who modified a security group over time, enable CloudTrail in all regions, log data events for S3 objects if needed, and ensure logs are delivered to a centralized, immutable S3 bucket with encryption and MFA delete enabled. Use AWS Config rules to detect security group changes and trigger investigations. Integrate CloudTrail with a SIEM or Security Orchestration, Automation, and Response (SOAR) platform to streamline alerting and response. Retain logs per your compliance requirements and regularly test your ability to reconstruct the chain of events from identity to change.

Limitations and Considerations

CloudTrail records management events; data events (such as traffic sent to a security group) are not captured by default and require separate configuration. If changes occur via EC2 classic networks, the resource IDs and event shapes may differ slightly. Cross-account activity may involve different identities and external IDs, so follow the trail of assumed roles. Ensure your IAM policies grant read access to CloudTrail and the security group resources for investigators.

Summary Workflow

To find who modified a security group with CloudTrail:

This workflow supports repeatable investigations and strengthens your security posture by making identity-related changes to security groups transparent and auditable.