Skip to main content

​
Overview

The AWS GuardDuty integration (INT-023) ingests GuardDuty findings into CaseBender, enriches them with MITRE ATT&CK mapping and attack categorization, and turns them into alerts (and optionally cases).

Automatic polling (pull)

CaseBender pulls new findings directly from your AWS account on a schedule using IAM credentials — no EventBridge rule required.

EventBridge webhook (push)

Alternatively, an EventBridge rule forwards findings to the CaseBender ingestion endpoint.
Recommended: enable Automatic polling. It requires only a read-only IAM key and no inbound endpoint. See Automatic polling.
Polling uses the official AWS SDK against the GuardDuty API (ListDetectors, ListFindings, GetFindings).

​
Capabilities

​
Prerequisites

1

Enable GuardDuty

GuardDuty must be enabled in the AWS region(s) you want to monitor.
2

Create an IAM user / access key

Create an IAM principal with a policy allowing guardduty:ListDetectors, guardduty:ListFindings, and guardduty:GetFindings. Generate an access key ID + secret.
3

Network egress

The CaseBender poller must reach the GuardDuty API endpoint for your region (guardduty.<region>.amazonaws.com).

​
Configure the integration in CaseBender

1

Open the integration catalog

Go to Settings → Integrations → Create, then choose AWS GuardDuty from the Cloud Security category.
2

Enter AWS credentials

3

Enable automatic polling (recommended)

4

Configure auto-case creation

​
Inbound (automatic polling, recommended)

1

Scheduled pull

On each interval, CaseBender lists finding IDs updated since the last cursor (optionally filtered by minimum severity), then fetches the full findings. On first run, findings updated within pollingInitialLookbackHours are imported.
2

Cursor + deduplication

CaseBender advances the cursor to the newest updatedAt. Findings are deduplicated by finding ID, so overlapping windows never create duplicates.
3

Normalization

Each finding is normalized into a CaseBender alert with observables, MITRE tactics, attack category, and remediation guidance.
Polling runs in CaseBender’s background poller service. For multi-region coverage, create one GuardDuty integration per region.

​
Inbound (EventBridge webhook / push)

As an alternative, an EventBridge rule (with an API destination) can POST findings to:
Requests are authenticated with the integration API key in the x-api-key header. Both the raw finding and the EventBridge { "detail": { ... } } envelope are accepted.

​
Security considerations

  • Least privilege — grant only the three read-only GuardDuty actions listed above.
  • Secret handling — rotate the IAM access key on your organization’s schedule; prefer keys scoped to a dedicated integration user.
  • Network — restrict egress to the GuardDuty regional endpoint.

​
Troubleshooting

Confirm GuardDuty is enabled in the configured region, or set the Detector ID explicitly.
Verify the IAM key has ListDetectors, ListFindings, and GetFindings. Check the region and that findings exist newer than the cursor. On first run only findings within pollingInitialLookbackHours are imported.Make sure all CaseBender services are running — with Docker, docker compose ps should show the worker and misp-processor services Up.
The IAM policy is missing one of the required actions, or the key belongs to a different account/region than expected.

​
Related documentation