EventBridge
Routing your Amazon EventBridge data to Panther for advanced monitoring and detection
Last updated
Was this helpful?
Routing your Amazon EventBridge data to Panther for advanced monitoring and detection
Last updated
Was this helpful?
is a serverless event bus that lets you receive, filter, transform, route, and deliver events. Within your environment, you may already be using EventBridge, as it supports receiving data from AWS services, custom applications, SaaS applications, and microservices.
EventBridge supports many Panther may plug into, including SNS topics, SQS queues, Firehose delivery streams, S3 buckets, and more. This enables many possible workflows. For example:
Okta -> EventBridge -> AWS SNS Topic -> Panther SQS
By default, EventBridge nests the logs within a detail
object. You will need to use EventBridge transformations to take advantage of Panther's native Okta schema. See on how to create transformations.
Custom Application -> EventBridge -> Firehose delivery stream -> S3 -> Panther
AWS GuardDuty -> EventBridge -> AWS SNS Topic -> Panther SQS
See the example below for instructions on .
See the steps below for a generally applicable workflow.
For a specific example using EventBridge to send GuardDuty findings to Panther, see .
Log in to your AWS Console and navigate to Amazon SNS > Topics. Click Create Topic.
If you already have an SNS topic created, skip to Step 2.
Fill out the Details:
Type: Select Standard
.
Name: panther-eventbridge-guard-duty
Click Create topic.
Copy the ARN value and store it in a secure location, as you will need it in the next steps.
Example ARN: arn:aws:sns:region:accountid:topic
Click SQS Queue ARN to copy the ARN of the SQS queue. Save it in a secure location, as you will need it in the next step.
In the Protocol field, enter Amazon SQS
.
In AWS, navigate to EventBridge.
Navigate to Events > Rules then click Create rule.
Define rule detail.
Provide a name, description, event bus and rule type.
Build event pattern.
Choose the source of data and pattern to match against
Select target(s).
Choose where to route the data that has been matched
Configure tags (optional).
Choose to add a label to this AWS resource
On the "Review and Create" page, click Create rule.
In AWS, navigate to Events > Rules then click the rule you want to modify.
Click into the Targets tab and click Edit.
Click Add another target.
Use "AWS Service" as the Target type, "SNS topic" as the target, and then select the SNS topic you added the Panther Managed SQS to in the previous steps.
Click Next, click Next, then click Update rule.
Now that the data pipeline is complete, you will start seeing log events land in your Panther Console where you can adjust your Schema and create Detections that may trigger Alerts.
The steps below are aimed at helping you quickly configure the necessary AWS resources to be used within EventBridge to allow you to perform advanced monitoring on your AWS GuardDuty data.
The steps below walk through the following data pipeline:
GuardDuty -> EventBridge -> AWS SNS Topic -> Panther SQS
Log in to your AWS Console and navigate to Amazon SNS > Topics. Click Create Topic.
If you already have an SNS topic created, skip to Step 2.
Fill out the Details:
Type: Select Standard
.
Name: panther-eventbridge-guard-duty
Click Create topic.
Copy the ARN value and store it in a secure location, as you will need it in the next steps.
Example ARN: arn:aws:sns:region:accountid:topic
Click SQS Queue ARN to copy the ARN of the SQS queue. Save it in a secure location, as you will need it in the next step.
In the Protocol field, enter Amazon SQS
.
These steps demonstrate how you can send GuardDuty findings to Panther through EventBridge. There is also an option to generate sample GuardDuty findings or write a rule to alert when someone assumes a role from TOR.
In your AWS console, navigate to GuardDuty to ensure it is enabled.
Navigate to EventBridge, then go to Events > Rules.
Click Create rule.
Fill in the rule detail section:
Name: Enter a descriptive name.
Description: Enter a description (e.g., Filtering events from GuardDuty and sending them to Panther Managed SQS
)
Event bus: Set the dropdown menu to default
.
Enable the rule on the selected event bus: Click the toggle to enable this setting.
Click Next.
On the "Build the event pattern" page, fill in the following:
Event source: Select AWS events or EventBridge partner events
.
Event pattern:
Event source: Select AWS services
.
AWS Service: Select GuardDuty
.
Click Next.
On the "Select target(s)" page, fill in the form for Target 1:
Target types: Select AWS service
.
Select a target: Select SNS topic
from the dropdown menu.
Topic: Enter the topic you created in Step 1 (panther-eventbridge-guard-duty
).
Under "Additional Settings":
Configure target input: Select Part of the matched event
.
Specify the part of the matched event: Select $.detail
Retry policy: Leave the defaults for Retry options.
Dead-letter queue: Leave the default option.
Click Next.
Optionally configure tags.
Click Next.
On the "Review and Create" page, click Create rule.
Now, when GuardDuty outlines a finding, that event will route to Panther where we can write a Detection to Alert us.
Since GuardDuty allows you to generate sample findings, you may use those to test end-to-end.
In GuardDuty, navigate to Settings > Sample Findings.
Click Generate Sample Findings to test.
An example rule within Panther might look like the following if I wanted to know when someone accessed AWS via TOR:
Follow .
In the Allowed Source ARNs field, enter the ARN of the SNS topic you created in .
Follow .
Select the topic you create in .
In the Endpoint field, use the ARN of the SQS queue you created in .
Note that Panther has separate instead.
Follow .
In the Allowed Source ARNs field, enter the ARN of the SNS topic you created in .
Follow .
Select the topic you create in .
In the Endpoint field, use the ARN of the SQS queue you created in .
Rule type: Select Rule with an event pattern
.
Event type: Select GuardDuty Finding
.
Note that there is an opportunity to add additional targets here or layer Panther in!
After your log source is configured, you can search ingested data using or .