Home › Modules › Module 10

🛡️ Module 10 · Security Components, GuardDuty, Inspector & WAF

Security Components, Understanding GuardDuty, Understanding AWS Inspector, Understanding AWS WAF

6 hours11 practice questions 5 sections

🎯 By the end of this module you should be able to…

Classify a control as preventive, detective or responsive.
Place the AWS security services onto a defence-in-depth diagram.
Explain what GuardDuty watches, what it costs, and what a finding means.
Explain what Inspector scans and why its risk score differs from a raw CVSS score.
State clearly the difference between GuardDuty and Inspector.
Explain what AWS WAF protects, what a web ACL contains, and how rules are evaluated.
Choose the right service for a given attack scenario.

Security components

Every security control does one of three jobs. Naming which one is the fastest way to see the gaps in an architecture.

🛡️ Preventive

Stops the bad thing happening at all.

IAM policies, security groups, NACLs, encryption, AWS WAF, MFA, SCPs.

👁️ Detective

Tells you it happened, or that it is happening now.

CloudTrail, Config, VPC Flow Logs, GuardDuty, Inspector, Security Hub, Macie.

🔧 Responsive

Does something about it.

EventBridge rules, Lambda remediation, Systems Manager Automation, AWS Backup, incident response runbooks.

Why you need all three

Prevention eventually fails — a credential leaks, a patch is missed. Detection is what tells you, and response is what limits the damage. An architecture with only preventive controls is an architecture that assumes it is perfect.

Defence in depth — read it from the outside in

Amazon GuardDuty

GuardDuty is a threat detection service. It continuously analyses account and network activity for signs that something malicious is happening, using threat intelligence and machine learning. It is agentless, it does not sit in the path of your traffic, and enabling it changes nothing about how your workloads run.

The three foundational data sources

📜 CloudTrail management events

Who called which API, from where. Catches "an IAM user in a country you have never used just created twenty instances".

🌐 VPC Flow Logs

Accepted and rejected connections. Catches port scanning, and traffic to a known command-and-control address.

🔎 DNS logs

What your instances looked up. Catches malware phoning home to a domain generated by an algorithm.

Those three cost nothing extra

GuardDuty reads them directly — you do not have to enable, store or pay for CloudTrail, Flow Logs or DNS logging separately for GuardDuty to use them. You pay for GuardDuty's analysis, based on volume.

Protection plans — the optional, chargeable extras

Plan	What it adds
S3 Protection	Analyses S3 data events — unusual access patterns and possible exfiltration
EKS Protection	Kubernetes audit logs — suspicious activity in your clusters
Runtime Monitoring	An agent on EC2, ECS and EKS watching process and file activity as it happens
Malware Protection	Scans EBS volumes, newly uploaded S3 objects and backups for malware
RDS Protection	Login activity on Aurora — brute force and anomalous access
Lambda Protection	Network activity from Lambda functions

Findings and severity

Severity	Score	What it usually means
🔴 Critical	9.0 – 10.0	Act now. Strong evidence of compromise.
🟠 High	7.0 – 8.9	A resource is likely compromised. Investigate immediately.
🟡 Medium	4.0 – 6.9	Suspicious. Worth a look in normal working hours.
🔵 Low	1.0 – 3.9	An attempt that was blocked, or reconnaissance.

A finding name reads ThreatPurpose:ResourceType/ThreatFamilyName, for example CryptoCurrency:EC2/BitcoinTool.B!DNS — an EC2 instance resolving a known mining pool domain, which almost always means it is compromised.

A finding nobody acts on has achieved nothing

The maturity ladder: checking findings by hand → emailing high-severity findings through EventBridge and SNS → automatically raising a ticket and isolating the resource. Route findings to where work actually happens.

Amazon Inspector

Inspector is a vulnerability management service. It continuously scans your workloads for known software vulnerabilities and unintended network exposure. Where GuardDuty watches behaviour, Inspector examines what you have.

Where the findings come from

A flaw is found It is published as a Inspector matches it The score is adjusted in some software ──▶ CVE with a CVSS ──▶ against what you ──▶ for YOUR environment base score, in the NVD are actually running → Inspector risk score

🆔CVE Common Vulnerabilities and Exposures — a unique identifier for one published flaw.
📊CVSS The industry-standard score for how severe that flaw is, from 0 to 10.
🗄️NVD The National Vulnerability Database, where both live. These are industry standards, not AWS ones.

The Inspector risk score is the useful part

Inspector takes the public CVSS base score and adjusts it for your actual situation. A vulnerability that is exploitable over the network scores lower on an instance with no route from the internet — because in your environment it really is less dangerous. That contextual scoring is what turns a list of thousands of CVEs into a short list you can act on.

What it scans

🖥️EC2 instancesOperating system and installed package vulnerabilities, plus network reachability

📦ECR container imagesScanned on push and rescanned as new CVEs are published

λLambda functionsDependencies, and optionally the function code itself

💻Code securityRepositories, for vulnerable dependencies and leaked secrets

Agent-based and agentless

Inspector uses the SSM agent where one is present, and falls back to agentless scanning of an EBS snapshot where it is not. Hybrid is the default, so coverage does not depend on every instance being perfectly managed. Gaps in coverage are the usual reason a real vulnerability is missed — check coverage, not just findings, because an unscanned instance reports zero vulnerabilities.

GuardDuty versus Inspector

	GuardDuty	Inspector
Question it answers	Is something bad happening?	What weaknesses do I have?
Looks at	Behaviour — logs, network, DNS, runtime	State — installed software and reachability
Finding is	An event, happening now	A vulnerability, sitting there
Typical output	"This instance is talking to a mining pool"	"This instance runs OpenSSL with CVE-2024-xxxx"
Fix	Contain, investigate, rebuild	Patch, rebuild the image, redeploy

The analogy that makes it stick

Inspector notices the unlocked window. GuardDuty notices someone climbing through it.

AWS WAF

Security groups and NACLs work at Layers 3 and 4 — they see an IP address and a port. They cannot see that the request body contains ' OR 1=1--. That is what a web application firewall is for.

A request a security group would happily allow

GET /products?id=5' OR '1'='1 HTTP/1.1
Host: shop.example.com

Source IP   198.51.100.24   → allowed
Port        443             → allowed
Payload     SQL injection   → the security group cannot see this at all

What WAF can protect

🌐CloudFrontProtects at the edge, before traffic reaches your Region

⚖️Application Load BalancerThe common choice for an app inside a VPC

🔗API GatewayREST APIs

📊AppSyncGraphQL APIs

👤Cognito user poolsProtects the sign-in endpoint itself

🏃App RunnerContainer services

Anatomy of a web ACL

WEB ACL — evaluated in priority order, top to bottom 1 Block requests from this IP set BLOCK 2 AWS managed rule group — common threats BLOCK 3 Rate limit: more than 2,000 requests in 5 minutes BLOCK 4 Allow requests from our office range ALLOW ──────────────────────────────────────────────────── DEFAULT ACTION — everything that matched no rule above ALLOW

Order matters, and so does the default

The first rule that matches decides — later rules are not consulted. A default action of Allow blocks only what you named; a default of Block allows only what you named. A public website normally defaults to Allow; an internal admin API normally defaults to Block.

Rule actions

Action	What happens
Allow	The request goes through and no further rules are evaluated.
Block	The request is refused; you can customise the response.
Count	Record the match but let the request through. This is how you test a rule safely.
CAPTCHA	Ask for a puzzle — stops most bots without stopping people.
Challenge	A silent browser challenge — no user interaction at all.

Count is the one people forget

Deploy any new rule in Count mode first, watch for a week, and only then switch it to Block. Turning on a managed rule group straight into Block is how you accidentally block your own customers on a Friday afternoon.

Managed rule groups and rate-based rules

AWS publishes managed rule groups that are maintained for you: a core rule set based on the OWASP Top 10, known bad inputs, SQL database protection, Linux and PHP specific rules, IP reputation lists, bot control and account-takeover prevention. Marketplace vendors publish their own. A rate-based rule counts requests per source IP over a five-minute window and blocks the ones above your limit — the simplest effective defence against brute force and scraping.

A sensible starting web ACL

Core rule set, known-bad-inputs rule set, a rate-based rule and an IP block list — in Count mode for a week, then Block. That covers a large share of real attack traffic.

WAF and its neighbours

Service	Operates at	Stops
Security group	Layer 3/4, instance	Traffic from the wrong IP or to the wrong port
Network ACL	Layer 3/4, subnet	The same, plus explicit deny, at the subnet edge
AWS WAF	Layer 7, HTTP	Malicious requests — injection, XSS, bots, floods
Shield Standard	Layer 3/4	Common DDoS. Free and always on.
Shield Advanced	Layer 3/4/7	Large DDoS, with a response team and cost protection. Paid.
Network Firewall	Layer 3–7, VPC	Traffic in and out of the whole VPC, with deep packet inspection

One attack, three services

Stage	What the attacker does	Which service sees it
1	Scrapes the site and probes for SQL injection	WAF — blocked by the core rule set
2	Floods the login page with credential stuffing	WAF — blocked by the rate-based rule
3	Exploits an unpatched library on an EC2 instance	Inspector — had already reported that CVE
4	The instance starts talking to a command-and-control host	GuardDuty — finding from DNS and Flow Logs
5	Steals the instance role credentials and calls the AWS API from elsewhere	GuardDuty — `UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration`
6	Tries to copy an S3 bucket out	GuardDuty S3 Protection — exfiltration finding

Read the table twice

WAF stopped stages 1 and 2. Inspector would have prevented stage 3 if anyone had acted on its finding. GuardDuty caught everything after. That is exactly why you need preventive, detective and responsive controls rather than any one of them.

Bringing findings together — AWS Security Hub

Three services producing findings separately is three places to look. Security Hub normalises them into one format and one prioritised list, across every account and Region in the organisation, and adds its own automated checks against standards such as the CIS benchmarks. For an organisation with more than a couple of accounts, this is how security is actually operated.

Key takeaways

✅Every control is preventive, detective or responsive — and you need all three.
✅GuardDuty = threat detection from CloudTrail, VPC Flow Logs and DNS logs. Agentless, no extra charge for those three sources.
✅Inspector = vulnerability management. CVE and CVSS from the NVD, adjusted into an environment-specific risk score.
✅GuardDuty watches behaviour; Inspector examines what you have.
✅WAF works at Layer 7 and sees the HTTP request itself — security groups cannot.
✅A web ACL is evaluated in priority order; the first match decides; the default action covers the rest.
✅Deploy new WAF rules in Count mode first.
✅Security Hub aggregates and normalises findings across accounts and Regions.