Skip to content

Keyboard shortcuts

Go

  • Scope — the control cataloggm
  • Plan — your last certification classgp
  • Collect — the recipe indexgc
  • The control you are workinggw
  • Startgh

Move

  • Next rowj
  • Previous rowk
  • Previous in this run[
  • Next in this run]
  • Filter this page's list/
  • Search everythingK

Act

  • Copy this page's permalinky
  • Toggle dark moded
  • This sheet?

Rows are whatever the current page lists — controls on Scope, recipes on Plan and Collect.

Control index

What 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 record

The API supplies the facts, but a human judgement against a documented baseline turns them into evidence.

partial — needs judgementclidailyAmazon EC2AWS Systems ManagerAWS CloudTrail

Fetch

$ aws ssm send-command --document-name AWS-RunShellScript --targets Key=tag:Environment,Values=<ENVIRONMENT_TAG> --parameters 'commands=["chronyc tracking","chronyc sources -v | grep -F ^*","grep -E \"^(server|pool|refclock)\" /etc/chrony.conf"]' --output-s3-bucket-name <EVIDENCE_BUCKET> --output-s3-key-prefix au-08
$ aws ssm list-command-invocations --command-id 11111111-2222-3333-4444-555555555555 --details --query 'CommandInvocations[].{Instance:InstanceId,Status:Status,Output:CommandPlugins[].Output}'
$ aws cloudtrail lookup-events --max-results 5 --query 'Events[].{Name:EventName,Time:EventTime,Source:EventSource}'

Expected output

For every managed instance, a chronyc tracking block whose Reference ID is A9FEA97B (169.254.169.123) — the local Amazon Time Sync Service — with System time within your documented granularity of NTP time (microseconds on a healthy instance), a small RMS offset, and Leap status Normal; a chronyc sources line beginning ^*, which marks the preferred source, pointing at 169.254.169.123 (or fd00:ec2::123 on a Nitro instance using the IPv6 endpoint); and a chrony.conf that names that endpoint and no unapproved public NTP pool. Every invocation should come back Status Success — an instance that returns nothing is an instance whose clock you have not evidenced. From CloudTrail, EventTime values in UTC, which is what the record format guarantees: eventTime is documented as 'the date and time the request was completed, in coordinated universal time (UTC)'.

Map — what it proves

  • recipe1
Key Security Indicators
NIST 800-53 controls
  • recipean authored recipe collects evidence for this control
  • KSI onlya Key Security Indicator reaches it, but no recipe is authored yet
  • orphanno Key Security Indicator reaches it — a person writes it up instead

What else these families can fetch:AU 11/27

GovCloud

The local Amazon Time Sync Service is reachable from any AWS Region, GovCloud included, at the link-local addresses 169.254.169.123 (IPv4) and fd00:ec2::123 (IPv6, Nitro instances only), and Systems Manager and CloudTrail are both available in AWS GovCloud (US); instance, document and trail ARNs use partition arn:aws-us-gov. One difference to plan around: precision time placement groups — the route to the enhanced Amazon Time Sync Service and the PTP hardware clock — are documented as available in all AWS Commercial Regions, so expect NTP-level accuracy rather than microsecond PHC accuracy in GovCloud

Notes & assertions

The clock is telemetry; the mapping and the granularity are not. AU-8 wants time stamps for audit records that use an internal clock mapped to UTC and meet a granularity you defined — chrony proves the host clock is disciplined to an authoritative UTC source and by how much it is off, and CloudTrail's eventTime is UTC by contract, so the AWS-generated half of your audit trail satisfies the mapping without any work of yours. What no command proves is that your own application writes its records from that clock in UTC: chrony can be flawless while code stamps local time or truncates to the second, and comparing the measured offset against your defined granularity is a judgement against a policy number. Scope honesty matters here too — this is a point-in-time sample of the instances Run Command could reach, so an unmanaged, stopped or unreachable instance is silently absent; join the results against your managed-instance inventory before calling the fleet covered, and remember containers and serverless compute have no chrony to query. If you claim sub-millisecond granularity, note that a PTP hardware clock passes no error bound to chrony (chrony then assumes an error bound of 0): read /sys/bus/pci/devices/<pci-slot>/phc_error_bound and add it, or run ClockBound. Leap seconds are smeared on the NTP endpoints but not on the PHC, so do not configure both smeared and non-smeared sources. Substitute your real targets, bucket and command id; send-command returns the CommandId that the second call consumes, and plugin Output is truncated at 2500 characters, which is why the S3 output bucket is worth setting.

References

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.