Lesson 239 · AWS Learning Path

AWS 239: GuardDuty, Inspector, Security Hub, and Macie operational findings

· Published · 14 min read

Labelled process diagram for AWS 239: Security telemetry to Service finding to Central triage and correlation to Containment, remediation, and closure evidence, with decision, proof and rejection evidence.

Why this lesson matters

AWS security services produce findings for different reasons. GuardDuty detects threat behavior. Amazon Inspector reports vulnerabilities and exposure. Security Hub CSPM evaluates controls and normalizes findings from many providers. Amazon Macie identifies S3 policy risk and sensitive data. A shared severity label does not make these signals equivalent.

An operator must first prove detector and scan coverage, then preserve evidence, understand the native finding, correlate it with identity/network/workload/data events, assess business impact, contain safely, remediate root cause, and verify closure at the source. Suppression and workflow labels reduce noise; they do not remove malware, patch a package or protect an S3 object.

Outcomes

You will be able to:

  • distinguish threat, vulnerability, posture-control and sensitive-data findings;
  • prove accounts, Regions, telemetry, resource scanning and discovery coverage;
  • interpret GuardDuty finding type, resource, actor, action, count and lifecycle;
  • prioritize Inspector findings with reachability, exploit, EPSS, fix and runtime use;
  • read Security Hub's AWS Security Finding Format (ASFF) and aggregation behavior;
  • separate provider RecordState from analyst Workflow.Status;
  • distinguish Macie policy and sensitive-data findings, jobs and sampled discovery;
  • normalize evidence without discarding service-specific fields;
  • design deduplication, correlation, triage SLA, containment and root-cause repair;
  • explain archive/suppression effects on EventBridge and downstream systems;
  • close a case from rescan/detection/data evidence rather than a status dropdown;
  • calculate service, ingestion, automation, storage and response costs.

Safety boundary and workbook

  • This lesson is read-only. Do not enable/disable services, generate sample

findings, archive/suppress/update findings, start scans/jobs or change resources.

  • Do not retrieve Macie sensitive-data samples, download suspicious objects, run

malware, exploit a CVE or connect to a suspected compromised host.

  • Preserve raw finding JSON, CloudTrail/log evidence and UTC time before containment.
  • Containment can destroy volatile evidence or interrupt customers. It needs the

incident commander, resource owner, security owner and rollback plan.

  • Redact account IDs, ARNs, IPs, DNS names, object keys, package/image names,

credentials, sensitive-data values and customer information.

Download the security finding triage workbook or complete archive.

Four services, four questions

ServicePrimary questionTypical evidenceNot proved by a finding
GuardDutydoes telemetry resemble malicious/anomalous behavior?API, DNS, flow, runtime, malware and protection-plan contextcompromise with certainty or complete scope
Inspectoris a covered resource vulnerable/exposed?package/CVE, image/function/code, reachability and fix intelligenceactive exploitation or safe patch deployment
Security Hub CSPMwhich control/provider findings need centralized workflow?ASFF controls, integrations, aggregation and automationsource remediation merely from workflow status
Maciedoes S3 posture or analyzed object data create privacy risk?bucket policy/configuration or sensitive-data classificationall objects scanned or legal impact by severity alone

Begin every investigation with two questions:

  1. Was the relevant account, Region, resource and telemetry covered at that time?
  2. What exactly does this native finding type assert and omit?

A zero count without coverage evidence is “unknown,” not secure.

Common operating workflow

coverage/health -> native finding preserved -> canonical case ID
      -> validate asset owner and service-specific evidence
      -> correlate identity + network + workload + data timeline
      -> business risk and incident/SLA decision
      -> approved preserve/contain/eradicate/recover actions
      -> source rescan or new telemetry verifies root-cause removal
      -> reconcile downstream status, exception, retention and lessons learned

Keep the native finding ID and, when imported, Security Hub ProductArn + Id. Deduplicate repeated updates, but do not merge unrelated occurrences simply because title, CVE or resource is similar. One asset can have several independent causes and one attack can span many assets.

GuardDuty: threat detection

GuardDuty's foundational detection analyzes CloudTrail management activity, VPC Flow Logs and Route 53 Resolver DNS query logs directly from AWS sources. You do not need to create those logs for GuardDuty's service analysis. Protection plans add coverage such as S3 data events, EKS audit/runtime, EC2 runtime/malware, RDS, Lambda, S3/backup malware and AI workloads according to current Region support.

Enabling a detector in one Region does not prove all Regions/accounts or plans are covered. Record delegated administrator, member status, detector ID/status, auto- enable policy, every protection plan, runtime agent/coverage health, excluded resources and estimated usage.

Read a GuardDuty finding

Trace:

  • finding type/category, severity, confidence-relevant details and description;
  • account/Region, resource role (target or actor), instance/container/database/

identity/S3/Lambda attributes and tags;

  • action, remote/local actor, IP/domain/port/API, user agent and access-key details;
  • createdAt, updatedAt, finding count and service archived state;
  • data source/protection plan, malware/runtime scan and extended attack-sequence

relationship where present;

  • recommended response and related CloudTrail, DNS, flow, EDR and workload logs.

GuardDuty aggregates repeated occurrences of the same finding ID and updates its count/time. New findings reach EventBridge near real time; subsequent occurrence notifications use a configured frequency (default can be six hours). Do not infer the attack ended from fewer notifications.

GuardDuty retains findings for 90 days. Export to encrypted S3/EventBridge/SIEM when longer evidence is required. Manual archive hides a finding from the default view but later occurrences can still be exported. A suppression rule auto-archives matching findings and prevents delivery to Security Hub CSPM, S3, Detective and EventBridge; it can also prevent a suppressed trigger from initiating a malware scan. Only the multi-account administrator controls suppression organization-wide.

Treat suppression as a detection-engine change with peer review, tests, expiry and compensating visibility - not a ticket-closing shortcut.

Amazon Inspector: vulnerability management

Inspector continually assesses enabled, eligible EC2 instances, ECR container images, Lambda functions and supported code repositories/scanning modes. Coverage depends on service enablement, account/Region, resource eligibility, agentless or SSM/agent status, image scan configuration/age, function/code mode and scan health.

Finding types include package vulnerability, code vulnerability and network reachability. A finding normally contains resource, package/component, CVE or rule, source severity/CVSS, Inspector score/vector, remediation, exploit/fix availability and exposure details where applicable.

Prioritize beyond CVSS:

  • internet/VPC/Direct Connect/peering reachability and path;
  • known exploit and exploit prediction (EPSS) context;
  • fix availability and vendor-specific severity;
  • whether image/function/package is deployed, invoked or business critical;
  • privilege, reachable data, compensating controls and attack correlation;
  • patch compatibility, maintenance window, rollback and immutable-image rebuild.

Statuses are Active, Suppressed and Closed. Suppression filters hide findings but do not remediate them; delegated administrators/standalone accounts manage rules, and applying them can take time. Inspector closes after remediation or loss of scan eligibility. Resource deletion closes findings but does not prove root-cause repair. Closed findings are retained for limited periods depending on reason, and a remediated issue can reopen if it reappears shortly after closure.

Strong closure evidence is a patched/rebuilt deployment plus Inspector rescan, package/image/function identity, application test and no active equivalent finding.

Security Hub CSPM: normalization and workflow

Security Hub CSPM receives control findings, AWS service/partner integrations and custom findings, normalizing them into AWS Security Finding Format (ASFF). Cross-Region aggregation can copy new/updated findings from linked Regions into a chosen aggregation Region. Central configuration governs standards/controls and member accounts, but coverage still requires account/Region/status proof.

Important ASFF fields include AwsAccountId, Region, ProductArn, Id, Types, Title, Description, Resources, Severity, FirstObservedAt, LastObservedAt, CreatedAt, UpdatedAt, Compliance, FindingProviderFields, ProductFields, RecordState, Workflow, RelatedFindings and remediation data. Normalization can lose native detail; always retain and query the source finding.

Record state is not workflow status

FieldOwner/purposeValues
RecordStatefinding provider says record is currentACTIVE, ARCHIVED
Workflow.Statusanalyst tracks investigationNEW, NOTIFIED, RESOLVED, SUPPRESSED
Compliance.Statuscontrol check result where applicablePASSED, FAILED, WARNING, NOT_AVAILABLE

Analysts use workflow - not provider record state - to track response. Marking RESOLVED does not stop a provider from creating/updating a finding. A finding can return to NEW when record/compliance becomes active/failing again; a workflow-suppressed finding behaves differently and can remain suppressed.

Automation rules update/suppress ASFF findings in near real time. They run before EventBridge receives the finding, so downstream automation sees modified fields. Use stable control/product IDs instead of mutable titles. EventBridge response can invoke powerful containment workflows; require idempotency, dry-run/canary, approval for destructive actions, current-state checks and rollback.

If a control is irrelevant, centrally disable it with documented rationale rather than suppressing every result and paying for unnecessary checks. Do not resolve a Security Hub copy until the native source and root cause are verified.

Amazon Macie: S3 security and sensitive data

Macie continuously inventories/evaluates S3 general purpose bucket security and can discover sensitive data through daily automated sampling or targeted one-time/ scheduled jobs. A policy finding reports a bucket policy/privacy posture issue. A sensitive-data finding reports identifiers detected in an analyzed object.

Severity reflects finding characteristics - not asset/business criticality. Policy severity depends on issue type; sensitive-data severity depends on identifier type and occurrence count. Validate bucket owner, public/external access, encryption, object/data owner, identifier accuracy, regulatory context and real exposure.

Automated discovery samples representative objects; it does not scan every object. Targeted jobs provide explicit scope but can skip unsupported formats/classes, objects without permission or failures. Every analyzed/attempted object produces a separate discovery result, including no-match/error cases, while sensitive-data findings exist only for detected data. Repeated discovery of the same object creates a new unique sensitive-data finding.

Macie retains findings and discovery results for 90 days. Discovery results are not directly available through the console/API; configure a Regional SSE-KMS S3 repository for long retention/query. Results contain locations - not the sensitive values. Revealing samples extracts actual data under additional permissions/KMS controls and is prohibited in this lesson; use privacy-approved validation.

Macie suppression auto-archives matching findings and stops EventBridge/Security Hub publishing, while discovery results continue. Organization administrator and member authority differs for policy versus job findings. Review filters, owner, expiry and downstream blind spots before suppressing.

Risk triage and correlation

Native severity is one input. Re-rank with asset criticality, exposure, privilege, active exploitation, exploit/fix maturity, sensitive-data type/volume, persistence, lateral movement, customer impact, confidence and compensating controls.

Example correlations:

  • GuardDuty credential anomaly + CloudTrail role changes + Macie public sensitive

object is a possible incident chain, not three unrelated tickets;

  • Inspector critical CVE on an unreachable stopped development image may rank

below a high finding on an internet-facing production path with active exploit;

  • Security Hub failed S3 control + Macie sensitive-data finding needs both posture

correction and privacy/data-owner response;

  • a Macie secret-key finding should trigger credential investigation/rotation,

not only object encryption.

Correlate by resource/identity, account/Region, source/destination, finding times, CloudTrail, DNS/flow/runtime/application logs, deployment history and data access. Preserve alternative explanations and confidence; a detector signal is not proof of attacker intent.

Response and closure

  1. preserve raw findings and volatile evidence;
  2. classify incident, vulnerability or privacy case and set SLA/commander;
  3. contain the smallest safe scope - credentials, network, workload or object access;
  4. eradicate root cause: revoke persistence, patch/rebuild, correct policy, remove

exposed data/secret, and fix deployment/governance path;

  1. recover service/data with owner validation and monitoring;
  2. rescan/requery the native source, search related indicators and verify new

configuration/runtime/data evidence;

  1. update Security Hub workflow and downstream tickets only after source proof;
  2. time-bound accepted risk/suppression and assign preventive actions.

Never delete an instance or object solely from one finding. Snapshot/isolate only when forensically and operationally approved. Rotate exposed credentials even if the object is later made private; copying/deleting does not revoke a secret.

Read-only Console walkthrough

  1. Confirm account/Region and delegated administrator/member relationship in each

service. Record complete enabled/coverage/health status before viewing counts.

  1. In GuardDuty, inspect detector, protection plans, usage and one owned historical

finding's resource/action/count/times; review suppression filters without edits.

  1. In Inspector, inspect account/resource coverage and an active finding's package,

CVSS/Inspector score, exploit/fix/reachability and scan time.

  1. In Security Hub CSPM, inspect central/cross-Region configuration and the ASFF

copy. Compare provider record state, workflow, compliance, automation history and native source finding.

  1. In Macie, inspect account/bucket/discovery coverage, job status, result repository

configuration and one redacted policy/sensitive finding. Do not reveal samples.

  1. Build one UTC correlation timeline and prove no status/configuration changed.

Read-only CLI inventory

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --output json

aws guardduty list-detectors --output json
aws inspector2 batch-get-account-status --account-ids "replace-with-owned-account-id" --output json
aws inspector2 list-coverage --max-results 50 --output json
aws inspector2 list-findings --max-results 50 --output json
aws securityhub describe-hub --output json
aws securityhub get-findings --max-results 50 --output json
aws macie2 get-macie-session --output json
aws macie2 get-automated-discovery-configuration --output json
aws macie2 get-classification-export-configuration --output json
aws macie2 list-findings --max-results 50 --output json

For redacted owned IDs:

export DETECTOR_ID="replace-with-detector-id"
aws guardduty get-detector --detector-id "$DETECTOR_ID" --output json
aws guardduty list-findings --detector-id "$DETECTOR_ID" --max-results 50 --output json
aws guardduty get-findings --detector-id "$DETECTOR_ID" \
  --finding-ids "replace-with-finding-id" --output json

aws inspector2 batch-get-account-status --output json
aws inspector2 list-coverage-statistics --output json
aws macie2 get-findings --finding-ids "replace-with-finding-id" --output json

List APIs often return IDs/summaries, while get returns native detail. Follow pagination, repeat every governed Region, and redact before sharing. Commands that update/archive findings, filters, automations, membership or service status are excluded from this lesson.

Troubleshooting from service-specific evidence

SymptomLikely causeEvidence/response
zero findingsdisabled account/Region/plan, unsupported resource, telemetry/agent gapservice coverage/health and source freshness
Security Hub copy differsnormalization, automation rule or update/aggregation delayASFF history, rule order and native JSON
archived signal absent downstreamsuppression prevents export/integrationsource suppression rule and archived query
GuardDuty count rises without new ticketrecurring occurrences aggregated under same ID/frequencycount, first/last update and EventBridge archive
Inspector finding closes after deletionresource ineligible/deleted, not necessarily patcheddeployment/image lineage and replacement rescan
critical CVE has no fixvendor status; mitigation/containment neededexploit/reachability/runtime and exception owner
Macie found nothingsampling/scope/format/storage class/permission/job errordiscovery result and job statistics, not finding count
Macie result unavailableno/incorrect Regional S3/KMS repository or expired 90 daysexport configuration, bucket/KMS and retention
resolved workflow becomes NEWprovider record/compliance became active/failingASFF history and native source recurrence
automation contained wrong assettitle/severity-only filter, stale state or non-idempotent actionrule criteria, event payload, execution and rollback

Diagnose coverage → native finding → export/integration → ASFF automation → case correlation → response execution → native verification. Do not “fix” disagreement by suppressing or manually resolving it.

Cost and retention

  • GuardDuty bills by analyzed foundational event/log volume and enabled protection-

plan units such as events, vCPU/resource/runtime or scanned data depending on plan.

  • Inspector pricing varies by average covered EC2 instances, ECR images, Lambda

functions/code and repository scanning mode/Region.

  • Security Hub CSPM bills security checks, finding ingestion events and automation-

rule evaluations, with current free/tier rules; Config dependencies can add cost.

  • Macie bills bucket inventory/monitoring, objects monitored for automated discovery,

and bytes inspected by automated/targeted discovery; jobs also incur S3 requests.

Each service has trial details and exceptions. Free trials end automatically into paid use. Add EventBridge, Lambda/Step Functions, Detective, CloudTrail data events, SIEM, S3, KMS, logs, data transfer, snapshots and response capacity. Estimate by account and Region from actual usage pages and current pricing.

This lesson creates nothing. Preserve evidence to policy, remove only temporary local unredacted copies, and prove detector/scanner/hub/Macie settings plus finding states are unchanged. Never disable coverage or delete evidence as “cleanup.”

Practical triage

Use supplied sanitized course findings and complete one workbook row per service.

  1. Prove detection/scan/discovery/aggregation coverage and list every blind spot.
  2. Preserve native ID/JSON and map the Security Hub product ARN/ID where present.
  3. Interpret native details without copying severity; calculate business priority.
  4. Correlate all four signals in one UTC identity/network/workload/data timeline.
  5. Define false-positive alternatives and the evidence that would distinguish them.
  6. Design preserve, contain, remediate, recover and source-verification actions.
  7. Compare manual archive, source suppression and Security Hub workflow suppression,

including what disappears from EventBridge/downstream integrations.

  1. Define closure, accepted-risk expiry, cost and exact no-create proof.

Knowledge check

  1. Does high native severity always mean highest business priority?

No; exposure, asset/data value, exploit activity, confidence and controls matter.

  1. Does GuardDuty require customers to enable VPC Flow Logs for foundational use?

No; GuardDuty consumes the underlying AWS data source directly for its analysis.

  1. What does an Inspector suppression rule do?

Hides matching findings; it does not patch or close them.

  1. What is the difference between ASFF record state and workflow?

Provider currency (ACTIVE/ARCHIVED) versus analyst investigation status.

  1. Do Security Hub automation rules run before EventBridge rules?

Yes; EventBridge sees the finding after automation-rule updates.

  1. Does Macie automated discovery scan every object?

No; it uses daily sampling. Targeted jobs define deeper explicit scope.

  1. Does a Macie discovery result contain the sensitive value?

No; it records analysis/location metadata. Sample retrieval is a separate control.

  1. What can source suppression remove from downstream visibility?

Depending on service, EventBridge, Security Hub, S3/Detective and malware triggers.

  1. When is a case ready for RESOLVED?

After root-cause remediation and native rescan/telemetry plus business validation.

  1. What must precede interpreting zero findings?

Complete account/Region/resource/telemetry coverage and service-health proof.

Lesson acceptance

The learner submits:

  • complete four-service coverage/administrator/Region/health matrix;
  • native finding records and correct ASFF identity/status mapping;
  • service-specific evidence and a justified business-priority assessment;
  • correlated UTC timeline with alternative explanations;
  • approved preserve/contain/remediate/recover and rollback design;
  • source rescan/detection/data closure evidence plan;
  • suppression/archive/workflow comparison with downstream effects and expiry;
  • current cost dimensions, retention and no-create proof;
  • no secrets, full account IDs, internal assets, vulnerable component identifiers or

sensitive/customer data.

Official sources

Advertisement