EventBridge Security Automation

EventBridge Security Automation uses Amazon EventBridge as the backbone for event-driven security response. Security services emit events that trigger automated remediation.

Security Event Sources

• GuardDuty: threat findings (compromised instance, malicious IP, crypto mining)
• Security Hub: compliance findings and imported findings from all security services
• IAM Access Analyzer: external access findings
• Config: non-compliant resource events
• Inspector: vulnerability findings
• Macie: sensitive data discovery findings

Automation Patterns

• Auto-remediate: Lambda function disables compromised access key when GuardDuty detects credential abuse
• Notify: SNS to Slack or PagerDuty when a high-severity finding is detected
• Quarantine: Lambda applies restrictive security group to compromised EC2 instance
• Enrich and Ticket: Step Functions workflow that enriches findings and creates Jira tickets

Understanding Delivery Timing

Timing matters when you build response automation. GuardDuty publishes newly generated findings to EventBridge in near real time, but subsequent occurrences of the same finding are aggregated: by default GuardDuty batches repeat occurrences into a single event every 6 hours, and an administrator account can tighten that to 1 hour or 15 minutes. If your playbook assumes it will see every repeat occurrence immediately, it will not. Also note that findings archived automatically by GuardDuty suppression rules are never sent to EventBridge at all, so a badly scoped suppression rule silently blinds your automation. GuardDuty itself retains findings for 90 days; EventBridge is the standard way to ship them to longer-term storage.

How It Goes Wrong in Practice

The most common failure is the rule that matches nothing. Event patterns are exact-match JSON: if you write a pattern against detail-type of "GuardDuty finding" instead of "GuardDuty Finding", or filter severity with values that do not match the numeric format GuardDuty emits, the rule sits enabled and green in the console while every finding sails past it. Because a non-matching rule produces no errors, teams discover this months later during an actual incident. The fix is boring but essential: generate sample findings and confirm the target actually fires before you trust the pipeline.

The second pattern is missing permissions on the target. An EventBridge rule needs permission to invoke its target; for Lambda that means a resource-based policy statement allowing events.amazonaws.com to call the function. Rules created in the console get this wired automatically, but rules created via CLI or IaC without the corresponding aws lambda add-permission call will match events and then fail delivery. Configure a dead-letter queue on the target so failed deliveries are visible instead of silently dropped.

Finally, remember that response automation is itself an attack surface: a remediation Lambda that can modify security groups and disable IAM keys is a privilege escalation target. Scope its execution role tightly and alert on changes to the rules themselves, since disabling an EventBridge rule is a documented defense evasion step.

Practical Check: Create a High-Severity Alert Rule

This is the AWS-documented pattern for routing GuardDuty findings, filtered by severity, into your response tooling:

aws events put-rule --name guardduty-high-sev --event-pattern "{"source":["aws.guardduty"],"detail-type":["GuardDuty Finding"],"detail":{"severity":[5,8]}}"

Then attach the target and grant EventBridge permission to invoke it:

aws events put-targets --rule guardduty-high-sev --targets Id=1,Arn=arn:aws:lambda:eu-west-1:111122223333:function:respond

aws lambda add-permission --function-name respond --statement-id 1 --action 'lambda:InvokeFunction' --principal events.amazonaws.com

The --state parameter of put-rule accepts ENABLED, DISABLED, or ENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTS, and event patterns are capped at 4096 characters.

Frequently Asked Questions

Do I need a rule in every account, or just the security account?

With a delegated GuardDuty administrator account, findings from member accounts trigger EventBridge rules in the administrator account, so one set of rules there covers the organization. The originating account is available in the accountId field of the finding detail, which you can also use to build per-account rules.

Is EventBridge the same as CloudWatch Events?

Yes, they are the same underlying service and API, and the event schema for security findings is identical. EventBridge added SaaS and custom event bus features on top.

Why did my automation not fire on a repeat finding?

Most likely aggregation: repeat occurrences of an existing finding are batched, by default every 6 hours, and only the administrator account can change that frequency (options are 15 minutes, 1 hour, or 6 hours). If the finding was auto-archived by a suppression rule, it was never published to EventBridge at all.