Detection services: GuardDuty, Inspector and Security Hub

Three weeks into the project, Dr. Simone Kaur asked Gwen a question that every medical director asks eventually. "If something bad happens in AWS at three in the morning, how will we even know?" In the old server room, the honest answer had been that they probably would not, until something broke. Gwen's answer this time was a diagram.

Prevention, the subject of lessons 2 to 8, makes bad things less likely. Detection makes sure that when something does happen, someone finds out quickly. This lesson covers the services AWS provides for detection: the logs and records that capture what happened, and the services that analyze them and raise findings. The exam guide names three of these in its examples, Amazon GuardDuty, Amazon Inspector and AWS Security Hub, and expects candidates to know where security logs are captured.

The record of what happened: CloudTrail

AWS CloudTrail records API activity in an AWS account: who made a request, when, from where, to which service, and whether it succeeded. Because almost everything in AWS, from launching an instance to changing a policy to signing in to the console, is an API call, CloudTrail is the foundation of security investigation and auditing.

CloudTrail keeps a 90-day event history of management events in each account automatically, viewable in the console at no extra charge. For longer retention and more detail, the customer creates a trail, which delivers log files to an S3 bucket, or uses CloudTrail Lake for queryable storage. Gwen created an organization trail that records every account in every Region and delivers the logs to a bucket in the separate security account, with the bucket protected so that nobody in the production accounts can delete them. "If an attacker gets into production," she said, "the first thing they will want to do is erase their tracks. The logs must live somewhere they cannot reach."

The record of settings: AWS Config

AWS Config records the configuration of resources over time and evaluates them against rules. Where CloudTrail answers who did what, Config answers what the setting is now, what it was before, and whether it complies with policy. Config rules can check, for example, that every EBS volume is encrypted, that no security group allows SSH from anywhere, that S3 buckets block public access, or that access keys are rotated. AWS provides many managed rules and the customer can write custom ones. Non-compliant resources appear as findings, and Config can trigger automatic remediation for some of them.

Config also keeps a timeline for each resource. When Hannah needed to know whether the imaging bucket had ever been public, even briefly, Config's history showed every configuration change since recording began, alongside the CloudTrail event that caused each one.

Monitoring with CloudWatch

Amazon CloudWatch collects metrics and logs from AWS services and applications and raises alarms when thresholds are crossed. It is mainly an operations tool, but it supports security too: a metric filter can count failed console sign-ins in CloudTrail logs and raise an alarm, and application logs from BookVet can reveal suspicious patterns such as a burst of failed logins from one address. The exam guide lists CloudWatch under monitoring for governance and compliance.

Amazon GuardDuty

Amazon GuardDuty is a threat detection service. Once turned on, it continuously analyses data sources such as CloudTrail management events, VPC Flow Logs and DNS query logs, using threat intelligence and machine learning to spot suspicious activity. It needs no agents or appliances for these foundational sources, and optional protection plans extend it to S3 data events, EKS, RDS sign-in activity, Lambda network activity, malware scanning of EBS volumes and more.

GuardDuty findings describe what looks wrong, how severe it is, and which resource is involved. Typical examples include an EC2 instance communicating with a known malicious address, unusual API calls from an identity that has never made them before, an access key used from an unusual location, or signs that an instance is mining cryptocurrency. GuardDuty only reads and analyses; it does not change resources, so it is safe to enable everywhere. Gwen turned it on across all accounts with the security account as the delegated administrator, so every finding lands in one place.

Amazon Inspector

Amazon Inspector finds software vulnerabilities and unintended network exposure in workloads. It automatically discovers EC2 instances, container images in Amazon ECR and Lambda functions, scans them for known vulnerabilities (published as CVEs) in operating system packages and application libraries, and checks network reachability. It rescans when new vulnerabilities are published or when software changes. Each finding comes with a risk score that considers how severe the vulnerability is and whether the resource is reachable.

For Mateo, who used to patch the old servers on a best-effort basis, Inspector was a revelation. On its first day it listed every Windows Server update missing on the VetLedger application instances and an outdated library in BookVet's code. He could finally answer the question "are we patched?" with a list rather than a shrug.

# Prioritize sample Inspector-style findings: severity first, then internet exposure.
findings = [
    {"resource": "vetledger-app-1", "cve": "CVE-EXAMPLE-0001", "score": 9.8, "reachable": False},
    {"resource": "bookvet-web-2",   "cve": "CVE-EXAMPLE-0002", "score": 7.5, "reachable": True},
    {"resource": "bookvet-web-2",   "cve": "CVE-EXAMPLE-0003", "score": 5.3, "reachable": True},
    {"resource": "build-runner",    "cve": "CVE-EXAMPLE-0004", "score": 4.0, "reachable": False},
]
def band(score):
    return "CRITICAL" if score >= 9 else "HIGH" if score >= 7 else "MEDIUM" if score >= 4 else "LOW"
for f in sorted(findings, key=lambda f: (f["score"] + (1.0 if f["reachable"] else 0)), reverse=True):
    exposure = "internet-reachable" if f["reachable"] else "internal"
    print(f"{band(f['score']):8} {f['score']:>4} {exposure:18} {f['resource']}")

CRITICAL  9.8 internal           vetledger-app-1
HIGH      7.5 internet-reachable bookvet-web-2
MEDIUM    5.3 internet-reachable bookvet-web-2
MEDIUM    4.0 internal           build-runner

The sample ranks findings the way Inspector's risk score does in spirit: severity matters most, and reachability from the internet makes a finding more urgent. The real scoring is more detailed, and the CVE identifiers here are placeholders.

AWS Security Hub

With CloudTrail, Config, GuardDuty and Inspector all producing information, someone needs one place to look. AWS Security Hub collects and prioritizes security findings from AWS services such as GuardDuty, Inspector, Config and Macie, and from many partner products, in a standard format across accounts and Regions. It also runs automated checks against security standards, such as the AWS Foundational Security Best Practices standard and the CIS AWS Foundations Benchmark, and gives a security score. Findings can be routed to ticketing systems or to automatic responses through Amazon EventBridge.

Gwen set Security Hub to aggregate findings from every account and Region into the security account. Each morning, Hannah opens one dashboard instead of five consoles. High-severity findings also go straight to the on-call phone, which answered Dr. Kaur's original question: if something bad happens at three in the morning, the on-call person gets a message within minutes, with the resource and the reason attached.

Other detection and analysis services

A few more services round out the picture and may appear as distractors or answers on the exam.

The exam guide specifically mentions AWS Trusted Advisor as a service for identifying security issues. Its security checks are among the checks available to all customers, while the full set of checks depends on the AWS Support plan. It is a good first look for a new account, and many of its findings overlap with Security Hub's.

Detection is a process, not a product

Turning services on is the easy part. Gwen insisted on three habits so that findings lead to action. Every finding type has an owner, so nothing sits in a queue that nobody watches. High-severity findings page someone; lower ones go into a weekly review. And every investigation ends with a question: what change would have prevented this, or detected it sooner? Over the first month, that question produced a Config rule for security groups, a tighter role for the build server and a new alarm on root sign-ins.

Lorraine asked what all this cost. The answer was that most of these services are priced by the volume of data they analyze or the number of resources they scan, so a company Cascade Ridge's size pays a modest monthly amount, and each service offers a free trial period on first activation. Gwen set budget alerts for them, as AWS-104 will explain, and noted that the cost of one undetected incident would dwarf a year of detection.

Protecting the logs themselves

Logs are only useful if they can be trusted. An attacker who gains administrative access often tries to delete or alter logs to hide what they did. Gwen applied several layers of protection to Cascade Ridge's log archive. The bucket lives in a separate security account that very few people can access. A service control policy denies stopping or deleting the organization trail. The bucket has versioning and S3 Object Lock in governance mode, so log files cannot be overwritten or deleted during the retention period without special permission. And CloudTrail log file integrity validation is turned on: CloudTrail writes signed digest files that allow anyone to check later that a log file has not been changed or removed since delivery.

Retention is a policy decision. Hannah chose to keep CloudTrail logs for seven years, matching the company's records retention rules for clinical and financial records, with lifecycle rules moving older logs to cheaper storage classes. Logs from VPC Flow Logs and application logs are kept for shorter periods, because they are larger and their value fades faster.

Responding to a finding

A finding is the start of work, not the end. Cascade Ridge's response runbook for a high-severity GuardDuty finding has five short steps: confirm the finding is genuine by checking the resource and the activity in CloudTrail; contain the problem, for example by moving an instance into an isolated security group or deactivating a key; collect evidence, such as an EBS snapshot of the affected instance; fix the root cause; and record what happened and what changed. Several of these steps can be automated with Amazon EventBridge rules that react to findings, but Gwen preferred to start with a human in the loop until the team had seen what normal findings looked like.