AwsCLI icon
If icon
SlackIncomingWebhook icon
Log icon
Schedule icon

AWS GuardDuty High Severity Threat Finding Sentinel

Poll AWS GuardDuty for high-severity threat findings and alert Slack with finding types and resource details.

Categories
CloudInfrastructure

This sentinel runs on a schedule to detect high-severity security threats reported by AWS GuardDuty. It enumerates all active GuardDuty detectors, queries findings above a configurable severity threshold (default 7.0), and sends a Slack alert listing the finding types and affected resources when any high-severity finding exists.

How it works

  1. io.kestra.plugin.aws.cli.AwsCLI calls aws guardduty list-detectors to retrieve all detector IDs in the target region.
  2. For each detector, aws guardduty list-findings is called with a severity filter using Gte (greater than or equal to) the configured severity_threshold input.
  3. If finding IDs are returned, aws guardduty get-findings retrieves the full finding details. The finding types are de-duplicated and collected with the detector ID and count.
  4. io.kestra.plugin.core.flow.If branches on high_severity_found. When true, a Slack alert is sent with the total count, finding types, and detector summary. When false, the flow logs a clean result.
  5. A top-level errors block fires a Slack alert on any unhandled exception.

What you get

  • Automated polling of all GuardDuty detectors for high-severity findings every 15 minutes.
  • Slack alerts with finding count, types, and detector-level summary.
  • A configurable severity threshold input so teams can tune alert sensitivity.
  • Full Kestra execution history for every sentinel check.

Who it's for

  • Security operations engineers triaging active threat findings.
  • Cloud security teams running continuous threat detection across AWS accounts.
  • Incident response teams needing immediate Slack notifications for high-severity events.

Why orchestrate this with Kestra

GuardDuty has native EventBridge integration, but it requires configuring rules, targets, and SNS topics separately. Kestra consolidates the detector enumeration, findings query, severity filtering, and Slack alert into one declarative flow with retries, execution history, and namespace-scoped secrets, no EventBridge or SNS setup needed.

Prerequisites

  • An AWS IAM identity with guardduty:ListDetectors, guardduty:ListFindings, and guardduty:GetFindings permissions.
  • GuardDuty enabled in the target region.
  • A Slack incoming webhook.

Secrets

  • AWS_ACCESS_KEY_ID: AWS access key ID.
  • AWS_SECRET_ACCESS_KEY: AWS secret access key.
  • SLACK_WEBHOOK: Slack incoming webhook URL.

Quick start

  1. Add AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and SLACK_WEBHOOK to your Kestra namespace secrets.
  2. Set aws_region to the region where GuardDuty is enabled.
  3. Adjust severity_threshold (default: 7.0) to match your alerting policy.
  4. Enable the schedule trigger or execute manually.

How to extend

  • Loop over multiple regions by using Kestra ForEach with a list of region inputs.
  • Add an automated response step that isolates an EC2 instance when a specific finding type is detected.
  • Route findings to PagerDuty for on-call escalation alongside the Slack alert.
  • Persist finding details to S3 or a SIEM for long-term threat analysis.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.