AWS Detection, Logging & Response Services

#Logging Architecture — Where Every Log Should Land

#What is this?

AWS produces many separate logs: CloudTrail records API calls, VPC Flow Logs record network connections, Route 53 Resolver query logs record DNS lookups, and applications write their own logs. A logging architecture decides which of these you switch on, where they are stored, who can delete them, and how you query them.

#Why it matters

An investigation can only answer questions the logs can answer. The most common failure in a cloud incident is not a missing detection, it is discovering that data events, DNS logs or the affected region were never logged. Attackers who get admin also try to delete logs, so where logs live matters as much as whether they exist.

#How it works

The standard multi-account pattern:

 Member accounts (prod, dev, …)                  Log Archive account (Security OU)
 ┌───────────────────────────────┐               ┌──────────────────────────────────┐
 │ Organisation CloudTrail ──────┼──────────────►│ S3 bucket: Object Lock, KMS,     │
 │ VPC Flow Logs ────────────────┼──────────────►│ bucket policy denies delete,     │
 │ Route 53 Resolver query logs ─┼──────────────►│ only the org trail may write     │
 │ CloudWatch Logs (apps, agent) ┼─ subscription►│ (via Firehose)                   │
 └───────────────────────────────┘               └──────────────┬───────────────────┘
                                                                │ read-only access
                                                 Security Tooling account (delegated
                                                 admin: GuardDuty, Security Hub,
                                                 Detective, Security Lake, Athena)

Key log sources and what each is for:

#Amazon Security Lake

Security Lake is a managed data lake that collects AWS and third-party security logs from every account and region, converts them to OCSF (Open Cybersecurity Schema Framework), and stores them as Parquet in S3 in a delegated admin account.

• Native sources include CloudTrail management and data events, VPC Flow Logs, Route 53 Resolver query logs, Security Hub findings, EKS audit logs and WAF logs; custom sources can write OCSF too.
• Subscribers (your SIEM, Athena, OpenSearch, a third-party tool) get either query access through Lake Formation or a notification when new objects land.
• Why OCSF matters: a field like "source IP" has the same name whatever product produced it, so one detection query works across sources. See SIEM normalisation.

#Querying logs

• CloudWatch Logs Insights — interactive queries over CloudWatch log groups:

fields @timestamp, userIdentity.arn, eventName, sourceIPAddress
| filter eventSource = "iam.amazonaws.com" and eventName like /Create|Attach|Put/
| stats count(*) as calls by userIdentity.arn, bin(1h)
| sort calls desc
| limit 20

In practiceWhat reconnaissance with a stolen key looks like in CloudTrail — the event most cloud investigations start from:

{ "eventTime": "2026-10-03T02:14:09Z", "eventSource": "iam.amazonaws.com", "eventName": "ListAttachedUserPolicies",
  "userIdentity": { "type": "IAMUser", "userName": "ci-deploy", "accessKeyId": "AKIA4EXAMPLE7Q" },   ← long-lived key
  "sourceIPAddress": "185.220.101.44",          ← not the CI runner this user normally calls from
  "userAgent": "aws-cli/2.15.0 Python/3.11 Linux/6.5",
  "errorCode": "AccessDenied" }                  ← recon often shows as a burst of denied calls

🎯

On the job. The highest-value CloudTrail alerts are cheap: root sign-in, StopLogging/DeleteTrail/PutEventSelectors, new access keys for existing users, CreateUser outside your identity pipeline, and bursts of AccessDenied from one principal. GuardDuty's Stealth:IAMUser/CloudTrailLoggingDisabled finding covers the most important one.

#Security angle

• Protect the log bucket from the people being logged: separate account, Object Lock, deny s3:DeleteObject and PutBucketPolicy to everyone but a break-glass role, and an SCP denying cloudtrail:StopLogging, DeleteTrail and UpdateTrail.
• Turn on CloudTrail log file integrity validation so you can prove logs were not altered (SHA-256 digests signed hourly).
• Log all regions, including ones you "don't use"; attackers launch miners in the regions nobody watches.

#Troubleshooting Missing Logs

#What is this?

A checklist for the common exam and real-world scenario: "logging is configured, but nothing arrives."

#Why it matters

Silent logging failures are worse than no logging, because everyone believes coverage exists. Detection engineers treat pipeline health as a detection in its own right (see pipeline health).

#How it works

Almost every case is a permission, a setting that was never switched on, or a network path:

In practiceTwo commands answer "is the trail actually working?":

$ aws cloudtrail get-trail-status --name org-trail --query "{logging:IsLogging,lastDelivery:LatestDeliveryTime,error:LatestDeliveryError}"
{ "logging": true, "lastDelivery": "2026-10-11T09:55:02Z", "error": "AccessDenied" }   ← "on", but delivery is failing
$ aws cloudtrail validate-logs --trail-arn arn:aws:cloudtrail:…:trail/org-trail --start-time 2026-10-10T00:00:00Z
Results: 24/24 digest files valid, 1302/1302 log files valid                             ← no tampering

#Security angle

An attacker with enough permissions may change a bucket policy or key policy rather than stop the trail, so logging breaks without a StopLogging event. Alert on gaps: no CloudTrail delivery for N minutes, PutBucketPolicy or PutKeyPolicy on logging resources, and CloudWatch agent heartbeat loss.

#Investigation — Amazon Detective

#What is this?

Detective is an investigation tool. It builds a behaviour graph from CloudTrail, VPC Flow Logs, GuardDuty findings and EKS audit logs, keeping up to a year of history, and lets you pivot: "this role → which IPs used it → what else those IPs touched → what the baseline for this role looks like."

#Why it matters

GuardDuty tells you something happened; Detective helps answer how far it went and what is normal for this entity. The exam phrase "root cause analysis" or "scope of an event" usually points to Detective.

#How it works

1. A GuardDuty finding fires, for example credential use from an unusual IP.
2. From the finding, open Detective: it shows the role's API volume over time, new geolocations, and new user agents.
3. Pivot to the IP: which other principals and instances it interacted with.
4. Detective finding groups cluster related findings into one incident, so a single attack sequence is not triaged as ten tickets.

Detective requires GuardDuty to be enabled and is managed through a delegated admin account.

🎯

On the job. A good Detective session answers three questions you'll write in the incident report: what is normal for this role or instance (the baseline), when did behaviour first deviate (the start of the incident), and what else did the same IPs or sessions touch (the scope).

#Security angle

Detective does not detect or block anything; it is for analysts. For automated cross-signal correlation, GuardDuty Extended Threat Detection produces "attack sequence" findings across multiple events.

#Incident Response Preparation, Automation and Testing

#What is this?

The services that turn a written IR plan into something that runs: runbooks that execute steps, workflows that chain them, fault-injection to rehearse, and backups to recover from.

#Why it matters

SCS-C03 domain 2 asks you to design and test a plan, not just respond. Interviewers ask "how would you make this repeatable?": the answer is automation with a human approval step for destructive actions.

#How it works

GuardDuty / Security Hub finding
        │
        ▼
EventBridge rule (match finding type + severity)
        │
        ├──► SNS / chat alert to on-call
        │
        └──► Step Functions workflow  (or Systems Manager Automation runbook)
                ├─ 1. tag the resource "under-investigation"
                ├─ 2. snapshot EBS volumes, capture memory (forensics account)
                ├─ 3. swap security group to an isolation SG (no inbound/outbound)
                ├─ 4. detach instance profile / revoke role sessions
                └─ 5. open an OpsItem / ticket with evidence links

Preparation that pays off at 3 a.m.: pre-provisioned IR roles in every account (assumable only from the security account), a forensics account with a pre-shared KMS key, an isolation security group template, Shield Advanced proactive engagement for internet-facing apps, and game days that run the playbooks for real.

In practiceThe EventBridge rule that wires a finding to automation:

{ "source": ["aws.guardduty"], "detail-type": ["GuardDuty Finding"],
  "detail": { "type": [ { "prefix": "UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration" } ],
              "severity": [ { "numeric": [">=", 7] } ] } }

Its target is a Step Functions workflow that snapshots, captures memory, isolates and opens a ticket, with a manual approval before anything destructive.

#Security angle

• Automation runs with powerful roles; scope them to the minimum (tag, snapshot, change security group) and protect who can edit runbooks.
• Auto-containment can tip off an attacker or destroy volatile evidence. Capture memory before isolation or termination, and require approval for destructive steps. See analyst OPSEC.