AWS Config compliance results proving continuous security monitoring is switched on account-wide — GuardDuty threat detection enabled (optionally centralized to a delegated admin) and Security Hub aggregating control findings
The API supplies the facts, but a human judgement against a documented baseline turns them into evidence.
Fetch
$ aws configservice get-compliance-details-by-config-rule --config-rule-name guardduty-enabled-centralized --compliance-types NON_COMPLIANT$ aws configservice get-compliance-details-by-config-rule --config-rule-name securityhub-enabled --compliance-types NON_COMPLIANT$ aws configservice describe-configuration-recorder-status$ aws configservice describe-config-rule-evaluation-status --config-rule-names guardduty-enabled-centralized$ aws configservice describe-config-rule-evaluation-status --config-rule-names securityhub-enabled$ aws ec2 describe-regions --query 'Regions[].RegionName' --output text$ aws organizations list-accounts --query 'Accounts[].Id' --output textExpected output
Two EvaluationResults arrays; empty NON_COMPLIANT sets mean GuardDuty is enabled in the account/Region (and results land in the CentralMonitoringAccount if you set one) and Security Hub is enabled. Managed rule identifiers: GUARDDUTY_ENABLED_CENTRALIZED, SECURITYHUB_ENABLED Plus describe-configuration-recorder-status showing recording=true and, per rule, describe-config-rule-evaluation-status showing FirstEvaluationStarted=true with a LastSuccessfulEvaluationTime — the proof the empty set was produced by a check that ran.
Assertions — what makes it a pass
| Field | Must be | For | Proves |
|---|---|---|---|
| guardduty-enabled-centralized.EvaluationResults | count_eq 0GuardDuty is enabled in the account and Region, or in the CentralMonitoringAccount when one is named — the parameter moves where the rule looks; it does not prove this account reports anywhere. | every row | SI-04 |
| securityhub-enabled.EvaluationResults | count_eq 0Security Hub is enabled and aggregating control findings. | every row | SI-04 |
| configuration-recorder-status.ConfigurationRecordersStatus[].recording | eq trueThe configuration recorder is on — without it an empty NON_COMPLIANT set is indistinguishable from a recorder that never ran. | every row | SI-04 |
| guardduty-enabled-centralized-evaluation-status.ConfigRulesEvaluationStatus[].FirstEvaluationStarted | eq trueguardduty-enabled-centralized has evaluated at least once; a deployed-but-never-evaluated rule also returns an empty result. | every row | SI-04 |
| guardduty-enabled-centralized-evaluation-status.ConfigRulesEvaluationStatus[].LastSuccessfulEvaluationTime | existsguardduty-enabled-centralized has a successful evaluation on record. | every row | SI-04 |
| securityhub-enabled-evaluation-status.ConfigRulesEvaluationStatus[].FirstEvaluationStarted | eq truesecurityhub-enabled has evaluated at least once; a deployed-but-never-evaluated rule also returns an empty result. | every row | SI-04 |
| securityhub-enabled-evaluation-status.ConfigRulesEvaluationStatus[].LastSuccessfulEvaluationTime | existssecurityhub-enabled has a successful evaluation on record. | every row | SI-04 |
Authored opinion, like the commands. Units live in the operator name — max-age-days is days, and nothing here is converted for you.
Map — what it proves
- recipe1
- recipe— an authored recipe collects evidence for this control
- KSI only— a Key Security Indicator reaches it, but no recipe is authored yet
- orphan— no Key Security Indicator reaches it — a person writes it up instead
What else these families can fetch:SI 10/35 →
GovCloud
AWS Config, GuardDuty, and Security Hub are available in AWS GovCloud (US); detector and hub ARNs use partition arn:aws-us-gov
Notes & assertions
This proves the monitoring capability is ON, which is the automatable half of SI-04. Whether findings are triaged and acted on within your SLA is the review workflow — surface that with the GuardDuty finding-plus-response recipe (see guardduty-suspicious-iam-activity-response) and AU-06 log review. Set CentralMonitoringAccount to your delegated-administrator account id in a multi-account org so member accounts are evaluated against the aggregation point. Both rules are evaluated per Region, so GuardDuty disabled in any Region other than the one queried is invisible; and whether findings are analyzed and acted on — SI-04(a), (b), (d) — is a human workflow. Partial for both reasons.
References
- AWS Config managed rule: guardduty-enabled-centralized https://docs.aws.amazon.com/config/latest/developerguide/guardduty-enabled-centralized.html
- AWS Config managed rule: securityhub-enabled https://docs.aws.amazon.com/config/latest/developerguide/securityhub-enabled.html
This AWS mapping is authored opinion (overlay v3.0.0), versioned separately from the dataset and written against ruleset 2026.07.14.01. The upstream FedRAMP dataset names none of these tools.
The Monitoring, Logging, and Auditing run (7)
- automatable
- partial — needs judgement
- narrative — no API proves this
Every authored recipe filed under MLA, in the order the plan works them. The mark says how much of the evidence the command produces on its own.
- partialAWS Config compliance results proving the audit trail exists and is protected — CloudTrail enabled and multi-region so management events are captured account-wide, log-file validation on so records are tamper-evident, and SSE-KMS encryption on so the logs themselves are protected at restcontinuousconfig-cloudtrail-audit-loggingAWS Config · AWS CloudTrail · AWS KMS
- partialAWS Config compliance results proving continuous security monitoring is switched on account-wide — GuardDuty threat detection enabled (optionally centralized to a delegated admin) and Security Hub aggregating control findingsyou are herecontinuousconfig-threat-monitoring-enabledAWS Config · Amazon GuardDuty · AWS Security Hub
- partialThe metric filters that turn audit log events into metrics, the alarms built on them, and Config's confirmation that those alarms actually notify someone — the automated-mechanism half of audit reviewweeklycloudwatch-log-review-alertingAmazon CloudWatch Logs · Amazon CloudWatch · AWS Config
- partialHow long audit records are kept, how much space they occupy, and whether the pipeline that delivers them is currently failing — retention settings on every log group and log bucket, the storage they consume, and the trail's own delivery-error fieldsdailyaudit-log-retention-and-delivery-failureAmazon CloudWatch Logs · Amazon S3 · AWS CloudTrail · AWS Config · Amazon CloudWatch
- partialWhat each instance's clock is actually locked to and how far off it is right now — the chrony daemon's reference source, offset and leap status collected fleet-wide through Run Command — together with the configured time source in chrony.conf and the UTC time stamps CloudTrail already writes on every audit recorddailyclock-synchronization-and-timestampsAmazon EC2 · AWS Systems Manager · AWS CloudTrail
- partialA demonstration run against the live log estate that audit records can be reduced, sorted and searched on demand by event criteria — the standing saved queries, the query that ran, and the report it returnedquarterlyaudit-reduction-and-report-generationAmazon CloudWatch Logs · AWS CloudTrail · Amazon Athena · Amazon S3
- partialFor each artifact actually running in the boundary, the cryptographic answer to whether it came from the build this provider claims built it: the signed provenance statement, the certificate identifying the workflow that produced it, and the transparency-log timestamps that make the signature checkable later. Collected alongside the two things that decide whether that answer can be trusted at all — the version of the verifying client, and the record of which deployed artifacts were submitted for verification in the first place.on-changebuild-provenance-attestation-verificationGitHub artifact attestations