PCI DSS v3.2.1, section 10.4 requires all critical assets to be synchronized for time and recommends using one of the authoritative time sources such as ntp. That requirement, however, only begins to scratch the surface of what actually controls time in a computing environment.
There are several other aspects that need to be considered when determining time. In the simplest networked environment, there are only two notions of time: the originating device and the final destination. But during credit card data processing, there could be many other devices in the overall chain having different notions of time due to crossing time zones, spanning Daylight Savings Time (DST) and non-DST observant regions, different transition dates between DST and non-DST in the differing regions, and operator settings on the card capturing device. There are also plenty of other sources of contention when different systems disagree on the exact time due to so-called "drift."
Why does it matter? The standard requires all significant events to be auditable in regards to who performed them and when. This is not just for administrative events; it could be for physical access, re-configuration of network controllers or firewalls, turning on or off the audit trails themselves, or a number of other factors and specific occurrences.
You may be asking, "Does it ever matter to the cardholder?" Well, it might if the cardholder was attempting to repudiate a transaction because their card was discovered missing at 13:50 and reported missing at 16:00, but a transaction occurred at 15:15.
Let us consider a web-based application taking cardholder data from the user's browser for a national business.
The user has their machine completely up to date for software patches, and the clock was originally set manually to the Pacific Time Zone with automated updates for Daylight Savings Time. The user (and his or her computer) knows it is 14:00 PDT on March 19, 2015.
The web form is being served by a computer in Chicago which knows it is 17:00 EDT. The payment processor is in Las Cruces, NM whose server knows it is 15:00 MT, but their storage system came from a site in New Jersey which is still set for EDT because the disaster recovery process did not say to check or correct the time zone after relocation of the asset. To further complicate the issue, that storage system has a ten year-old version of the time zone database in which the transition between wintertime and DST was calculated using a different algorithm from the current year's mandate; in this hypothetical, it is using the first Sunday in April, rather than the current standard of the second Sunday in March.
The cameras on the data center doors have no inherent notion of time, so they rely on the data capture algorithm on their control device for their concept of it. No one has looked at that since the original installation. The logging algorithm for the card readers used to open the data center doors stores its data on the same storage device as the Cardholder Data (CHD) transaction, but in a different partition.
What time is it?
As we've shown, each different part of the system has a different notion of the current time, and there can be some very odd effects around the transition times for daylight savings.
IANA is the authoritative world-wide source for time zone definition files. Linux systems may not update the installed version of that database on a regular basis, so you need a process to do so for every system in your CDE.
Software and embedded systems developers could do themselves a favor by automatically updating their release mechanisms to capture any changes to the time zone definition database regularly. Preferably, they would not distribute the time zone database at all and declare that they are relying on the underlying operating system to have the correct version in their release notes.
To comply with PCI, systems administrators need to be aware of how each device, system, and application they track actually records the time at which any security-related event occurs. The easiest way to achieve this is to set all devices within the CDE to use Universal Time Code (UTC) without attempting to give any time-based localization to any events, except within the user's browser or their application.
After a breach, forensics investigators will need to look at the entire chain of time settings to ensure they are looking at a consistent set of events.