Skip to main content

GuardDuty

Amazon GuardDuty in Prism centralizes threat detection across every AWS account in your organization. From a single interface, you can view active threats by severity, browse and archive findings, manage which accounts are enrolled, and control the protection plans that run in every region.

What is GuardDuty?​

Amazon GuardDuty is a threat detection service that continuously monitors your AWS accounts and workloads for malicious activity. Prism deploys GuardDuty centrally by designating one account as the administrator. That account owns the aggregating detector in every linked region and receives findings from all enrolled member accounts, eliminating the need to configure GuardDuty in each account individually.

Invitation model, not an Organizations delegated administrator

Prism enrolls members through GuardDuty's invitation model: the administrator account creates and invites each member, and Prism then accepts that invitation from inside the member account using its own access role. Prism never registers an AWS Organizations delegated administrator, because it has no route into your management account.

The UI and this documentation call the chosen account the delegated administrator because that is the role it plays in the deployment. The practical consequence is on the Emails step: an invitation is addressed to an account's real AWS root email, so enrollment needs that address for every member.

Key capabilities include:

  • Centralized threat detection, One administrator account receives findings from all enrolled members across every linked region
  • Severity-based dashboard, Four severity cards (Critical, High, Medium, Low) summarize your active non-archived threat count at a glance with a drill-down to matching findings
  • Top threat types, See the ten GuardDuty finding types generating the most detections across your organization, and filter to those findings with one click
  • Per-account breakdown, Identify which accounts have the most active threats and jump directly to their findings
  • Six protection plans, Enable or disable S3 Protection (data events), EKS Protection (audit logs), Malware Protection (EBS), RDS Protection (login events), Lambda Protection (network logs), and Runtime Monitoring independently
  • Archive workflow, Archive findings to remove them from your active threat count; unarchive at any time to restore them. Both actions call AWS directly, so the AWS GuardDuty console stays in step

The GuardDuty section is accessible from the Security Hub sidebar under GuardDuty, which expands into four rows:

Sidebar rowPageDescription
ThreatsThreat DashboardSeverity cards, top threat types, and per-account threat counts
FindingsFindingsBrowse, filter, and archive GuardDuty findings
EnrollmentEnrollmentAdd, remove, and retry member accounts
SettingsSettingsUpdate protection plans, regions, and disable GuardDuty

The setup wizard has no row of its own. Every one of those rows is a page in its own right except the wizard, which is one of the things the GuardDuty landing route (/securityhub/guardduty — the Threats row once GuardDuty is live) can render. What that route shows depends on the configuration's status:

Configuration statusWhat the landing route renders
No configuration, disabled, or failedThe setup wizard
in_progressA progress screen with a live progress bar, which polls until the job finishes
enabled or partial_failureThe Threat Dashboard

While GuardDuty has not been configured, the sidebar shows a single greyed-out Enable GuardDuty row in place of the four above; clicking it opens the wizard. While an enable, update, or disable job is running the four rows stay in place, because an in_progress deployment still counts as enabled for the sidebar.

The Capability Card​

GuardDuty also appears as a capability card on the Capabilities tab of the Configuration page. The card is titled Threat detection, sourced from Amazon GuardDuty, and reads "Continuous threat detection across accounts and workloads." with three bullets:

  • EC2/EKS/S3/Lambda/RDS threat detection
  • Malware Protection
  • Runtime Monitoring

Its button reads Enable when GuardDuty is off and Configure when it is already on (alongside an Enabled marker). Either way it lands on the GuardDuty section: the setup wizard when GuardDuty is off, the Threat Dashboard when it is on.

On the Security Hub Overview page GuardDuty gets a different, smaller tile: the total finding count, a subtitle joining the configuration status to the admin account and home region (for example enabled • 123456789012 • us-east-1), and a per-severity strip. Clicking the tile opens the GuardDuty section. While GuardDuty is not enabled, that tile shows a dash, the words "Not enabled", and its own Enable button.

info

GuardDuty enrollment uses invitation-based member association, which requires the real AWS root email address of each member account. Prism resolves most root emails automatically through its ops service; for accounts where auto-resolution fails, you enter the address manually.

A wrong address is not rejected at submit time. It is accepted, and the enrollment fails later in AWS with EmailVerificationFailed, which surfaces as a failed account on the Enrollment page. See Security Hub Issues for details.

Prerequisites​

Before using GuardDuty, ensure the following:

  • Your organization has been onboarded to Prism by CloudKeeper
  • Security Hub has been enabled for your organization as a beta feature by CloudKeeper
  • Security Hub access enabled for your account by an Admin in Preferences > Admin Management
  • At least one AWS account is onboarded in Prism to serve as the GuardDuty administrator