Authoritative Time Source

Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.3.7.Source

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

1. [a]

   internal system clocks are used to generate time stamps for audit records;

   1 example covers this

2. [b]

   an authoritative source with which to compare and synchronize internal system clocks is specified; and

   1 example covers this

3. [c]

   internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source.

   1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

• addresses[a][b][c]

  AU.L2-3.3.7 · Authoritative Time Source

  Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.

  • [a]

    internal system clocks are used to generate time stamps for audit records;

  • [b]

    an authoritative source with which to compare and synchronize internal system clocks is specified; and

  • [c]

    internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source.

  Two internal stratum-2 servers as the only time source; drift over 500 ms opens a ticket

  CCControlVerdict Corpus@cv-corpusOSCJul 31, 2026

  Community is just starting — add yours. No verdicts yet.

  Implementation

  AO coverage. Addresses all three Authoritative Time Source objectives: internal clocks generate the timestamps, an authoritative source is specified, and clocks are compared and synchronized to it.

  Timestamps [a]. Every audit source stamps records from its own system clock; the analytics platform stores the original timestamp alongside its ingest time so a skewed source is visible rather than silently corrected. All storage and display is UTC — local time appears nowhere in the audit path.

  Specified source [b]. Two internal servers are the only sanctioned upstream for the enclave. They synchronize to a documented external time service, and the pair exists so that one can be patched without leaving the fleet unsynchronized. The specification is written in the baseline: domain members follow the domain hierarchy rooted on those servers, Linux hosts use chrony pointed at both, and network devices and appliances are configured to the same two addresses.

  Synchronization and verification [c]. Egress firewall rules block outbound NTP from enclave subnets to anything except the two internal servers, so a device that ignores its configuration cannot quietly reach a public pool. Monitoring polls the offset of every enclave host; offset above 500 ms for more than 15 minutes opens a ticket, and above 5 seconds pages the on-call because it breaks correlation. Authenticated NTP is used on the devices that support it.

  Maintenance. Weekly offset report across the fleet. After any appliance firmware upgrade, re-check the time configuration — that is exactly how the two appliances ended up on public pools the first time. Annual review of the upstream service choice and of the drift thresholds.

  Accepted gap. One test instrument has a manually set clock with no NTP client at all. It generates no audit records used for investigation; its outputs are timestamped by the host that collects them, and it sits on an isolated VLAN.

  What the evidence looks like

  • Baseline documenting the two internal servers and their upstream
  • Time configuration exports from a domain member, a Linux host, and a network device
  • Firewall rule restricting outbound NTP from enclave subnets
  • Weekly clock offset report and a ticket from the last drift finding
  • Firmware upgrade checklist line item covering time configuration

  Environment

  Mixed fleet: Windows domain, Linux hosts, switches and firewalls, plus two appliances that shipped pointing at public NTP pools.

  Tools

  • NTP

  Edit history

  · No edits yet