3.3.7 — Sync the Clocks

The One-Liner

If your server says 2:00 PM and your firewall says 2:07 PM, your log correlation is broken — and your evidence may not hold up.

What It Says

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

What It Actually Means

Every system clock in your CUI environment must synchronize to the same authoritative time source — typically a stratum 1 or stratum 2 NTP server. Servers, workstations, firewalls, switches, cloud services — all of them.

Three things the assessor checks:

1. Time stamps are used for audit records. The internal system clocks are what generate the timestamps in your logs. If a system’s clock is wrong, every log entry from that system has a wrong timestamp.

2. An authoritative time source is specified. You’ve documented which NTP server(s) your systems synchronize to. This can be a public NTP pool (time.windows.com, time.nist.gov), a domain controller acting as the NTP source, or an internal NTP server — but it must be documented and authoritative.

3. Clocks are actually synchronized. NTP is configured and working. Drift is minimal (under 1 second is the standard). Systems synchronize on a regular frequency — not just at boot.

This sounds trivial, but it’s foundational for log correlation (3.3.5). If your firewall logs an event at 14:00 and your AD server logs a related event at 14:07, those two events won’t correlate properly. Seven minutes of drift means you can’t build a reliable timeline — and forensic investigators and courts both care about timestamp accuracy.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Do internal system clocks generate time stamps for audit records?	Audit records show timestamps from the local system clock
2	Is an authoritative time source specified?	Documented NTP source: pool.ntp.org, time.windows.com, domain controller, or internal NTP server
3	Are internal clocks compared and synchronized to the authoritative source?	NTP configured on all systems, drift under 1 second, synchronization verified

---

What to Have Ready on Assessment Day

Documents they’ll review: Audit and accountability policy; procedures addressing time stamp generation; system security plan; system configuration settings showing NTP configuration; documentation of the authoritative time source

People they’ll talk to: Information security personnel; system or network administrators; anyone responsible for NTP configuration

Live demos they’ll ask for: “Show me the NTP configuration on this server.” “Show me the time source your domain controller synchronizes to.” “Show me the current drift on this system.” “Are all systems pointing to the same source?”

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “What is your authoritative time source? Show me the documentation.”
• “Show me the NTP configuration on a CUI server.”
• “What’s the current time drift on this system?”
• “Do all systems — servers, workstations, network devices — synchronize to the same source?”
• “How often do systems synchronize? Only at boot, or on a regular interval?”
• “Are your timestamps in UTC or local time? How do you normalize across time zones in your SIEM?”

Real-World Example

A defense contractor’s domain controller (PDC emulator) synchronizes to time.nist.gov as the external stratum 1 source. All domain-joined Windows servers and workstations inherit NTP from the domain hierarchy — no manual configuration required. Network devices (Palo Alto firewall, Cisco switches) are configured to point to the PDC emulator as their NTP source. The SIEM (Sentinel) normalizes all timestamps to UTC. Drift on any system is under 500 milliseconds. During the assessment, the IT admin runs w32tm /query /status on a server and shows synchronization with the domain controller, then shows the firewall NTP config pointing to the same source. The assessor checks a log entry from the firewall and a log entry from a server for the same event — timestamps match within one second.

---

Where Companies Trip Up

No NTP configured. Systems using their internal hardware clocks with no synchronization. Timestamps drift minutes or hours over weeks. Configure NTP on every system.

Different time sources. Some systems point to time.windows.com, others to pool.ntp.org, the firewall uses its own setting. While both are valid NTP sources, mixing them can introduce small inconsistencies. Standardize on one authoritative source — typically the domain controller for domain-joined systems and a documented NTP pool for non-domain devices.

Network devices forgotten. Windows systems synchronize via the domain, but firewalls, switches, and appliances are never configured for NTP. These devices generate critical boundary logs — their timestamps must be accurate too.

Time zone confusion. Logs from different systems in different time zones without UTC normalization. Your firewall logs in EST, your server logs in UTC, and your cloud logs in PST. Normalize everything to UTC in your SIEM.

---

How to Talk About This

To a CEO or Board

All system clocks are synchronized to the same authoritative time source. Timestamps across our entire environment are accurate and consistent, so our log evidence is forensically reliable.

To an Engineering Team

PDC emulator syncs to time.nist.gov. All domain-joined systems inherit via AD hierarchy. Network devices point to PDC. UTC normalization in SIEM. Drift alerting if any system exceeds 1 second. NTP config verified quarterly as part of logging review.

---

Connected Requirements

Requirement	Why it matters here
3.3.1 — Log Everything	Generates the audit records whose timestamps depend on synchronized clocks
3.3.5 — Connect the Dots	Cross-source log correlation fails without consistent timestamps
3.3.2 — Trace Every Action	Tracing actions to users requires accurate “when” alongside “who”
3.4.2 — Harden Everything	NTP configuration is part of your security baseline for every system type

---

Implementation

🔒

Step-by-step guides for Microsoft 365, AWS, Azure, and GCP are available to Ancitus clients.

Start a conversation →

---

CMMC Practice ID: AU.L2-3.3.7 | SPRS Weight: 1 point | POA&M Eligible: Yes