Amazon SCS-C02: Logging, Audit & Forensics — Study Guide

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Part of the AWS Security Specialty SCS-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.

Amazon GuardDuty Findings and Remediation

GuardDuty is a managed threat-detection service that continuously ingests three telemetry streams behind the scenes: CloudTrail management (and optionally S3 data) events, VPC Flow Logs, and Route 53 DNS query logs. You do not need to enable, deliver, or pay for those log sources separately for GuardDuty to consume them — the service reads a duplicate stream directly. This is why GuardDuty can be turned on with a single API call and begin generating findings within minutes, without any log-pipeline engineering.

Findings carry a severity value between 0.1 and 8.9, mapped to Low (0.1–3.9), Medium (4.0–6.9), and High (7.0–8.9). Typical actionable findings include UnauthorizedAccess:EC2/SSHBruteForce, Backdoor:EC2/C&CActivity.B!DNS, CryptoCurrency:EC2/BitcoinTool.B, and Recon:IAMUser/MaliciousIPCaller. Remediation patterns vary by finding: an EC2-based compromise generally warrants isolating the instance with a quarantine security group, snapshotting volumes for forensics, and terminating; an IAM-based finding requires rotating access keys and reviewing the principal’s recent CloudTrail activity.

For multi-account estates, enable GuardDuty via AWS Organizations and designate a delegated administrator account (commonly the Security Tooling account). The delegated admin can auto-enable GuardDuty in every existing and new member account across every Region where the service is turned on. Without the delegated admin configuration, per-account GuardDuty findings stay isolated in each member — enabling detectors individually does not aggregate them centrally.

AWS Security Hub and Cross-Account Aggregation

Security Hub is the normalization and aggregation layer. It ingests findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config, and dozens of partner products, converting them to AWS Security Finding Format (ASFF). It also runs its own controls against standards such as CIS AWS Foundations, AWS Foundational Security Best Practices, PCI DSS, and NIST 800-53.

Cross-account, cross-Region aggregation works the same way as GuardDuty: register Security Hub with the Organizations delegated administrator, then designate an aggregation Region so findings from other Regions replicate into that single pane. A common mistake is to enable Security Hub in each account and expect a consolidated view — without the delegated admin plus aggregation Region, each account still only sees its own findings.

Security Hub does not itself send emails. Notifications and automations are built by matching Security Hub finding events on the default EventBridge bus and forwarding them to SNS, Lambda, Step Functions, or Systems Manager Automation documents.

CloudTrail: Management vs Data Events

CloudTrail records two categories of activity, and confusing them is the single most common gap in detection coverage.

• Management events: control-plane operations — RunInstances, CreateBucket, AttachRolePolicy, PutBucketAcl. Enabled by default on any new trail.

• Data events: high-volume, resource-level operations — S3 object-level calls (GetObject, PutObject, DeleteObject, PutObjectAcl), Lambda Invoke, DynamoDB item-level API calls. Disabled by default and billed separately.

If a security requirement is “detect when someone makes an S3 object public via PutObjectAcl,” a plain management-event trail will not capture it because ACL changes on individual objects are data events. Similarly, GetObject egress from a sensitive bucket is invisible without data events. PutBucketAcl (bucket-level) is a management event and would be logged; PutObjectAcl (object-level) is not.

Use an organization trail created in the management or delegated admin account so every member account’s events are captured in a single S3 bucket, and cannot be disabled by member account principals. Protect the trail with:

• SSE-KMS encryption on the destination bucket, with a KMS key policy that denies unauthorized decrypt.

• A bucket policy that denies s3:PutObject without the CloudTrail service principal and denies deletion.

• Log file integrity validation enabled, which produces hourly digest files signed with SHA-256 so tampering can be proven.

Example creation:

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name central-ct-logs \
  --is-organization-trail \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

aws cloudtrail put-event-selectors \
  --trail-name org-trail \
  --event-selectors '[{"ReadWriteType":"All","IncludeManagementEvents":true,
                       "DataResources":[{"Type":"AWS::S3::Object",
                                         "Values":["arn:aws:s3:::sensitive-bucket/"]}]}]'

EventBridge and SNS Alerting

EventBridge is the routing fabric that connects findings to human and automated responders. Every GuardDuty finding, every Security Hub finding update, and every CloudTrail-derived event lands on the default event bus. Rules use JSON event patterns to filter, then fan out to one or more targets (SNS, Lambda, SQS, Kinesis Data Firehose, Step Functions, Systems Manager).

A canonical pattern for high-severity GuardDuty findings, forwarded to both an SNS topic for email and a Firehose delivery stream feeding OpenSearch for analytics:

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

For Security Hub CRITICAL findings routed to email:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["CRITICAL"] },
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

The email endpoint is a simple SNS subscription; the subscriber must confirm via the emailed link before delivery starts. A single rule can carry up to five targets, so alerting and downstream analytics do not require duplicate rules.

When authoring patterns, remember that CloudTrail management events arrive with "detail-type": "AWS API Call via CloudTrail", whereas data events do not appear on the default bus unless you configure a trail that publishes to CloudWatch Logs and use a metric filter or subscribe via EventBridge’s CloudTrail data-event integration. Writing an EventBridge rule matching "eventName": "PutObjectAcl" on the default bus without enabling data events yields zero matches.

CloudWatch Logs, Insights, Metric Filters, and Alarms

Sending CloudTrail (and VPC Flow Logs, and application logs) to CloudWatch Logs enables near-real-time detection. Metric filters scan every incoming log event against a pattern and increment a custom CloudWatch metric; a CloudWatch alarm on that metric triggers SNS.

Example: alarm on repeated console sign-in failures.

aws logs put-metric-filter \
  --log-group-name /aws/cloudtrail/org \
  --filter-name ConsoleSignInFailures \
  --filter-pattern '{ ($.eventName = "ConsoleLogin") && ($.errorMessage = "Failed authentication") }' \
  --metric-transformations metricName=ConsoleLoginFailures,metricNamespace=Security,metricValue=1

CloudWatch Logs Insights provides ad-hoc querying using a purpose-built query language, useful for incident response after an alarm fires:

fields @timestamp, userIdentity.arn, sourceIPAddress, eventName

Common Traps

• Missing S3 object-level activity: PutObjectAcl, GetObject, and DeleteObject are data events. A default trail captures only management events; you must add data-event selectors, or the finding, alarm, or EventBridge rule targeting those API names will silently never fire.

• Central visibility without delegated admin: enabling GuardDuty or Security Hub in every account does not aggregate results. Findings pool centrally only after registering a delegated administrator in AWS Organizations and, for Security Hub, choosing an aggregation Region. Cross-account invitations work for small estates but do not scale and require per-account acceptance.

• Management vs data confusion in filters: PutBucketAcl (bucket) is a management event and works in any standard EventBridge or metric filter; PutObjectAcl (object) does not, regardless of how well-crafted the pattern is, unless data events are enabled and delivered to the same pipeline.

Practical Problem: Use-Case Scenario

Scenario: Meridian Financial runs a multi-account AWS Organization with a dedicated security account and a centralized logging account. Their estate includes customer PII in S3, transactional APIs on EC2/Lambda, and CloudTrail already writing management events to a central S3 bucket; teams want faster detection and coordinated response across accounts.

Challenge: Security engineers detected a sudden spike in S3 GETs and related GuardDuty findings suggesting potential data exfiltration, but alerts are noisy and lack correlated CloudTrail context and automated containment across accounts.

Recommended Approach:

1. Enable Amazon GuardDuty in every member account and designate the security account as the GuardDuty delegated administrator; enable S3 data-event protection so findings include object-level access anomalies.
2. Configure CloudTrail per-account to deliver management events to the central S3 for retention and to forward selected high-value data events (S3 GetObject/PutObject/DeleteObject and Lambda Invoke) to CloudWatch Logs in the security account for low-latency inspection.
3. Turn on AWS Security Hub in the security account and enable cross-account aggregation with member accounts so GuardDuty findings, CloudTrail-derived findings, and Config/Inspector results are centralized and normalized.
4. Create EventBridge rules that match high-severity GuardDuty and Security Hub findings and route them to SNS for pager notifications and to a remediation Lambda which uses CloudTrail context to take containment actions (revoke API keys, remove IAM session, isolate EC2 ENI).
5. Add CloudWatch Logs metric filters for abnormal s3:GetObject rates scoped by IAM principal and an alarm that triggers the same EventBridge/SNS/Lambda pipeline; use CloudWatch Logs Insights queries in the security account to enrich alerts with correlated CloudTrail events for incident triage.

Rationale: Centralizing findings (GuardDuty + Security Hub) and sending targeted CloudTrail data events to CloudWatch enables low-latency correlation, alerting, and automated containment via EventBridge/SNS/Lambda—aligning with AWS best practices for detection, cross-account aggregation, and automated response.

Centralized CloudTrail and Log Integrity

CloudTrail is the authoritative record of AWS API activity, and the foundation of any audit architecture is a single multi-Region trail that delivers to one centralized S3 bucket, ideally in a dedicated log-archive account within AWS Organizations. A multi-Region trail automatically captures management events in every current Region and any Region AWS launches later — a single-Region trail creates blind spots the moment a workload spins up elsewhere, which is the classic completeness failure during audits. When applied at the organization level, the trail also captures every member account’s events, so a new account joining the organization is covered without any per-account configuration.

Enable log file validation on the trail. CloudTrail then delivers a signed digest file every hour to the same S3 bucket, containing SHA-256 hashes of the delivered log files. The aws cloudtrail validate-logs command walks the digest chain and detects tampering, deletion, or gaps. Without validation, a defender cannot prove logs were not altered post-incident, which invalidates them as forensic evidence.

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name corp-audit-logs \
  --is-multi-region-trail \
  --is-organization-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...
aws cloudtrail start-logging --name org-trail

Delivery failures are almost always downstream permissions problems, not CloudTrail bugs. The S3 bucket must exist before the trail is created, its bucket policy must grant s3:PutObject to cloudtrail.amazonaws.com with an aws:SourceArn condition matching the trail, and the object owner must be the bucket owner (bucket-owner-full-control). If the trail uses SSE-KMS, the CMK policy must allow kms:GenerateDataKey* for the CloudTrail service principal, and every consumer (Athena, security engineers, Lambda parsers) must have kms:Decrypt on that key. A common outage mode: logs are delivered fine, but Athena queries return “AccessDenied” because the query role lacks Decrypt on the log-encryption CMK. Fix it on the key policy, not by disabling encryption.

CloudWatch Logs, Metric Filters, and Real-Time Alarming

CloudTrail delivers to S3 in 5-to-15-minute batches — adequate for retrospective audit but too slow for real-time detection. To alarm on sensitive events, stream the trail to CloudWatch Logs (a trail option) or route specific events via EventBridge. CloudWatch Logs approach uses metric filters that pattern-match JSON events and increment a CloudWatch metric, which then drives a CloudWatch Alarm and SNS notification. The canonical example is root console sign-in:

{ $.eventName = "ConsoleLogin" && $.userIdentity.type = "Root" }

EventBridge is often better for narrow, well-known events (KMS key disablement, IAM policy changes) because rules can trigger Lambda or Step Functions directly without any Logs cost. Use metric filters when you need aggregated counts or dashboarding.

Retention on CloudWatch Logs defaults to Never Expire, which is expensive and rarely correct. Set explicit retention per log group (aws logs put-retention-policy) aligned with the compliance regime — commonly 90 days hot in CloudWatch with long-term archive in S3 through a subscription filter or Kinesis Data Firehose.

For sensitive data hygiene, apply CloudWatch Logs data protection policies at the account level. These use managed data identifiers (credit card numbers, AWS secret keys, SSNs) to mask matching strings on ingestion. Crucially, unmasking requires logs:Unmask; grant it only to a break-glass role. Users who can read the log group but lack Unmask see only asterisks. An account-wide policy applies to all current and future log groups, which is the correct control — per-group policies drift as new services create new groups.

Log Query at Scale: Insights and Athena

Two query engines address different tiers of data.

• CloudWatch Logs Insights queries data already in CloudWatch Logs using a purpose-built query language. Ideal for recent operational data (Lambda logs, VPC Flow Logs in Logs, application logs). Fast, no schema setup, but constrained by CloudWatch retention and cost per GB scanned.

• Amazon Athena runs Presto/Trino SQL against data in S3. Ideal for large-scale forensic queries over CloudTrail, ALB access logs, VPC Flow Logs stored in S3, and CloudFront logs. Costs $5 per TB scanned; use partition projection or Glue partitions on date/Region to slash scan cost.

A typical forensic use case: identifying who disabled a KMS key. Because CloudTrail JSON is nested, the CloudTrail-created Athena table exposes userIdentity as a struct:

SELECT eventTime,
       userIdentity.arn                                         AS principal,
       userIdentity.sessionContext.sessionIssuer.arn            AS assumed_role,
       userIdentity.sessionContext.attributes.mfaAuthenticated  AS mfa,
       sourceIPAddress,
       requestParameters
FROM   cloudtrail_logs
WHERE  eventName = 'DisableKey'
  AND  eventTime BETWEEN '2024-05-01T03:00:00Z' AND '2024-05-01T03:30:00Z';

For ALB bot analysis, enable ALB access logs to S3, define an Athena table over the log prefix, then join against a table of known-bad IPs and visualize the aggregation in QuickSight. QuickSight reads from Athena, so the pipeline is: ALB → S3 → Athena → QuickSight. Sending ALB logs to CloudWatch Logs Insights is not a supported native path — ALB logs to S3 only.

VPC Flow Logs can go to either destination: pick Logs for tactical filter dstPort=3389 and action="REJECT" type investigations, and S3 (Parquet, partitioned) for month-scale trend queries.

Audit Manager Evidence Collection

AWS Audit Manager automates continuous evidence collection mapped to frameworks such as PCI DSS, HIPAA, SOC 2, and CIS. It pulls evidence from Config rules, Security Hub findings, CloudTrail events, and resource inventory, and packages it under control assessments. When enabled in the Organizations management or delegated administrator account, it collects across all member accounts, producing an assessment report — a zipped bundle of evidence with a manifest — that auditors accept in lieu of manual screenshots. This is the correct answer whenever a scenario asks for continuous, multi-account, framework-aligned evidence: Config alone gives you resource compliance but no framework mapping; Security Hub gives findings but no assessment packaging; a homegrown Athena report is not continuous.

Trap Recap

• Blaming CloudTrail for missing logs is usually wrong: the bucket may not exist, the bucket policy may reject the CloudTrail principal, or object ownership may be misconfigured. Check S3 first.

• A single-Region trail seems cheaper but produces incomplete audit history; multi-Region is the default correct answer for organization-wide coverage.

• SSE-KMS encrypted logs are invisible to Athena, Lambda parsers, or engineers unless the CMK policy grants kms:Decrypt to those principals — disabling encryption is not the fix; correcting the key policy is.

Practical Problem: Use-Case Scenario

Scenario: Meridian Financial runs a multi-account AWS Organization with production, staging, and a dedicated logging account. Their environment hosts customer-facing APIs, analytics, and IAM-administered secrets, and they need centralized, tamper-evident logging plus fast investigation tools to support incident response and compliance requests.

Challenge: A recent suspicious sequence of console logins and IAM policy changes went unnoticed for hours and there is concern that log integrity and timely alerting are inadequate for forensic reconstruction and Audit Manager evidence collection.

Recommended Approach:

1. Enable an AWS Organizations CloudTrail (organization trail) in all regions, turn on CloudTrail log file integrity validation, deliver logs and digest files to a centralized S3 bucket encrypted with a KMS CMK whose key policy restricts decryption to a small security team, and enable S3 access logging and versioning.
2. Configure CloudTrail to stream management and selected data events to CloudWatch Logs, then create CloudWatch Logs metric filters for high-risk patterns (console sign-in failures from new IPs, CreateUser, PutRolePolicy) and attach CloudWatch Alarms to SNS topics for paging and an automated Lambda playbook.
3. Deploy CloudWatch Logs Insights dashboards for interactive investigation of recent events and set retention and lifecycle rules in the logging account to retain evidence per policy.
4. Catalog CloudTrail S3 objects with AWS Glue and run Athena queries (partitioned by region/date/service) for large-scale retrospective analysis and to produce CSV evidence exports for investigators.
5. Create an AWS Audit Manager assessment that automatically collects CloudTrail, AWS Config, and IAM evidence into an evidence folder and schedules periodic exports for compliance reviewers.

Rationale: Centralizing and validating CloudTrail, streaming to CloudWatch for real-time metric filters and alarms, and using Athena/Logs Insights for scalable queries follow AWS best practices for detection, immutable logging, and forensic readiness, while Audit Manager automates evidence collection for audits.

← Threat Detection · All domains · Encryption →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Amazon →