1.2 Amazon GuardDuty Architecture & Finding Types

1.2 Amazon GuardDuty Architecture & Finding Types

Amazon GuardDuty is a managed threat detection service that continuously monitors AWS accounts, workloads, and data for malicious activity and unauthorized behavior. Rather than relying solely on static rule sets, GuardDuty combines machine learning, anomaly detection, behavioral modeling, and integrated threat intelligence (including AWS Security Intelligence and third-party feeds such as Proofpoint and CrowdStrike) to identify indicators of compromise (IoCs).

Understanding GuardDuty's architectural foundations, out-of-band telemetry processing, specialized protection plans, finding format, and multi-account administration is essential for the AWS Certified Security – Specialty exam.

---

GuardDuty Core Architecture & Out-of-Band Telemetry Ingestion

A defining architectural characteristic of GuardDuty is its out-of-band, serverless operation. Enabling GuardDuty does not deploy software agents on EC2 instances (for foundational features), does not proxy network traffic, and does not introduce latency or resource overhead to production workloads.

Loading diagram...

Foundational Data Sources

When GuardDuty is enabled, it automatically begins consuming three foundational data sources (CloudTrail management events, VPC Flow Logs, and Route 53 Resolver DNS query logs) without requiring the customer to create or configure them. Items 2 and 5 below are analyzed only when their optional protection plans are turned on:

1. AWS CloudTrail Management Events: Tracks API calls across all AWS services, identifying reconnaissance (e.g., automated Describe* sweeps), unauthorized IAM policy changes, and credential access.
2. CloudTrail S3 Data Events (S3 Protection plan): Analyzes object-level operations (GetObject, PutObject, DeleteObject) to detect anomalous data access patterns and mass downloads.
3. VPC Flow Logs: Analyzes IP traffic metadata to and from EC2 network interfaces. Critical Exam Fact: GuardDuty consumes VPC Flow Log telemetry through an independent, duplicated stream that AWS manages. The customer does not need to enable VPC Flow Logs in their VPC to use GuardDuty, nor do they pay CloudWatch Logs ingestion or storage fees for GuardDuty's internal consumption.
4. Route 53 DNS Query Logs: Analyzes DNS queries sent to the default AWS Route 53 Resolver (the VPC +2 address). Detects compromised instances querying known Command-and-Control (C2) domains, dynamic DNS services, or domain generation algorithms (DGA).
5. Kubernetes (EKS) Audit Logs (EKS Protection plan): Consumes audit logs directly from the managed Amazon EKS control plane to detect cluster role binding escalations, anonymous API requests, and unauthorized pod launches.

---

Specialized & Advanced Protection Plans

Beyond foundational log analysis, GuardDuty provides specialized protection features that target specific workload vectors. These features can be enabled independently within the GuardDuty console or via the UpdateDetector API.

Deep Dive: GuardDuty Runtime Monitoring & eBPF Architecture

While foundational GuardDuty relies on external network and control plane logs, GuardDuty Runtime Monitoring provides deep in-guest operating system visibility. It supports Amazon EKS, Amazon ECS (including AWS Fargate), and Amazon EC2.

Runtime Monitoring operates using an extended Berkeley Packet Filter (eBPF) security agent:

• Automated Agent Management: When enabled for EKS, GuardDuty can automatically deploy and update the security agent daemonset (aws-guardduty-agent) across cluster worker nodes.
• Kernel-Level Telemetry: The eBPF agent intercepts operating system system calls (execve, connect, open) in kernel space without modifying application source code.
• Process Context: Identifies the specific Linux process name, parent process ID, container ID, and command-line arguments responsible for malicious outbound connections or file modifications.

Deep Dive: Malware Protection Mechanics

When GuardDuty generates a compute-based finding (such as an EC2 instance beaconing to a known C2 server), GuardDuty Malware Protection can automatically initiate an agentless scan:

1. GuardDuty creates a point-in-time Amazon EBS snapshot of the target instance's root and attached volumes.
2. GuardDuty shares the snapshot with an isolated AWS-managed service account in the same Region.
3. An ephemeral scanning instance in the service account restores the snapshot to an encrypted EBS volume and performs signature and heuristic malware scanning.
4. When scanning completes, GuardDuty automatically deletes the restored volume and snapshot (retention can optionally be enabled for forensic examination).

---

GuardDuty Finding Taxonomy & Severity Scoring

GuardDuty findings represent potential security incidents formatted as structured JSON payloads. Every finding follows a standardized three-part naming hierarchy:

[ThreatFamily]:[TargetResource]/[ThreatSubfamily].[Artifact]

Finding Taxonomy Components

• ThreatFamily: The broad category of threat or attacker motivation (e.g., CryptoCurrency, UnauthorizedAccess, Recon, Stealth, Trojan, PrivilegeEscalation, Impact).
• TargetResource: The AWS resource targeted or compromised (e.g., EC2, IAMUser, S3, Kubernetes, RDS, Lambda, Runtime).
• ThreatSubfamily: The specific attack technique, malware family, or anomalous behavior (e.g., SSHBruteForce, BitcoinTool.B, TorIPCaller, DNSDataExfiltration, UnusualDoHTraffic).
• Artifact: Optional detail describing the data source or communication channel through which the threat was detected (e.g., !DNS, !VPC).

Example Finding: CryptoCurrency:EC2/BitcoinTool.B!DNS denotes that an EC2 instance was detected querying known cryptocurrency mining pool endpoints via DNS.

Severity Scoring System

GuardDuty assigns every finding a numeric severity value between 1.0 and 10.0. Findings fall into four operational bands:

Exam Tip: The GuardDuty severity scale now runs to 10.0; Critical (9.0–10.0) findings come from Extended Threat Detection attack sequences. An EventBridge condition of "severity": [{"numeric": [">=", 7]}] therefore captures both High and Critical findings.

---

Suppression Rules & Finding Lifecycle

In enterprise environments, authorized activities can trigger false-positive findings. Examples include authorized penetration testing, vulnerability scanning appliances, internal CI/CD pipelines deploying ephemeral nodes, and third-party SaaS management tools.

How Suppression Rules Function

Rather than disabling detection rules globally, security engineers configure Suppression Rules:

• Suppression rules define precise filter criteria based on finding attributes (such as type, resource.tag, service.action.awsApiCallAction.remoteIpDetails.ipAddressV4, or accountId).
• When a finding matches an active suppression rule, GuardDuty automatically sets the finding's RecordState to ARCHIVED upon generation.
• Audit Preservation: Suppressed findings are not discarded. They are stored in the GuardDuty repository for 90 days, where they can be queried via the console or CLI by filtering for archived findings. However, suppressed findings are not sent to Security Hub CSPM, the S3 findings export, Amazon Detective, or Amazon EventBridge, and they do not start Malware Protection for EC2 scans. A suppression rule is therefore also a routing decision: write it narrowly.

---

Multi-Account Governance via AWS Organizations

Managing GuardDuty across hundreds of AWS accounts requires centralized governance. AWS Organizations enables a Delegated Administrator model that separates security operations from the AWS Organizations management account.

Loading diagram...

Delegated Administrator Capabilities & Constraints

1. Designation: The Organizations management account calls EnableOrganizationAdminAccount designating a dedicated security tooling account as the GuardDuty Delegated Administrator.
2. Auto-Enablement: The delegated administrator enables GuardDuty across all existing member accounts with a single operation and activates Auto-Enable, ensuring that any newly created or joined accounts in the organization immediately have GuardDuty and specialized protection features activated.
3. Centralized Visibility: The delegated administrator views, searches, and manages findings across all member accounts from a single pane of glass.
4. Member Account Restrictions: Member accounts cannot disable GuardDuty, cannot remove themselves from the organization detector, and cannot alter suppression rules published by the delegated administrator.
5. Long-Term Export: GuardDuty findings can be exported to a central Amazon S3 bucket located in the security tooling account. The export destination requires an S3 bucket policy granting guardduty.amazonaws.com permission to put objects and a KMS Key Policy granting GuardDuty permission to use a customer-managed key (CMK) for envelope encryption.

---

Specialty Exam Pitfalls & Threat Detection Scenarios

1. The VPC Flow Log Requirement Myth: A frequent exam trap suggests that a customer must create a CloudWatch VPC Flow Log subscription before GuardDuty can analyze network traffic. This is false: GuardDuty taps internal AWS network telemetry independently. Enabling or disabling customer VPC Flow Logs has zero impact on GuardDuty's operational coverage.
2. KMS Permissions for Finding Export: When configuring GuardDuty finding export to an S3 bucket, using the AWS-managed key aws/s3 will fail. GuardDuty requires a customer-managed KMS key (CMK) because the GuardDuty service principal must be granted explicit kms:GenerateDataKey permissions via the KMS key policy.
3. Regional Isolation: GuardDuty is a Regional service. Enabling GuardDuty in us-east-1 provides zero threat detection for workloads operating in eu-west-1 or ap-southeast-1. To protect an enterprise, GuardDuty must be enabled in all active and inactive AWS Regions (to detect unauthorized resource creation in unused Regions).
4. Suppression Rules vs EventBridge Filters: Suppression rules archive findings within the GuardDuty service itself, preventing them from cluttering the console or feeding default Security Hub compliance checks. If you only filter events in EventBridge, the findings still remain active in the GuardDuty console and generate alerts in integrated downstream services.