The cybersecurity of an information system depends on many different mechanisms. But almost all of them have one thing in common: they need a correct and precise vision of the time. Logs are timestamped, certificates have validity dates, authentication tickets expire, one-time codes have a short lifespan. As long as the server and computer clocks match, everything works fine. But as soon as there is any divergence, the mechanisms go wrong one by one: logs cannot be correlated, authentications are rejected, certificates are wrongly considered to have expired. Security is therefore compromised.
Worse still, in the event of a successful attack, the traceability allowing what has happened to be determined is often lost in the absence of time synchronisation.
This synchronisation is therefore essential for security, but also for compliance frameworks.
A service originally designed without security
Time synchronisation is one of the oldest Internet services. The NTP (Network Time Protocol), which distributes time between machines, dates back to the 1980s. It was designed at a time when the network connected laboratories that trusted each other: exchanges were neither authenticated nor encrypted, and any machine could connect to any server. The design is still robust in terms of precision, but much less so from a security standpoint. For decades, no one was worried: time was a background service of no interest to attackers. As security mechanisms started to rely on time synchronisation, time became a target.
Keep control over your time network
Supervise and control your synchronisation from a centralised, user-friendly interface.
The importance of log timestamping
The most obvious and most critical impact of time synchronisation is on logs. Each component of an IT system logs its internal events (connections, errors, alerts, etc.). Taken in isolation, these logs tell the machine’s “life story”.
Comparing the logs of all the machines in the same system lets you see the bigger picture. In particular, by comparing logs, attacks can be detected. A special type of tool, known as SIEM (Security Information and Event Management), collects the logs of hundreds of machines to look for suspect sequences.
But to compare the events of different machines, you need to be able to put them in order, and you can only do this if all the machines use the same time to stamp their logs. A difference of a few seconds between two servers is enough to reverse the apparent order of two events, leading, for example, to an incorrect conclusion being drawn about the sequences of these events.
The problem is even more apparent after an incident. Forensic analysis (following an attack) involves reconstructing the sequence of events using the logs of dozens of machines: how did the attackers get in? When? What did they do? If the clocks differ, this timeline is useless. And the issue goes beyond the technical side of things: the timeline of an incident can be presented to an insurer or a judge, and the reliability of the time source underpinning it is what makes it valuable.
This is why ANSSI, in its logging recommendations, emphasises that an event is only useful if it can be situated in time.
Time and authentication systems
There is another, less visible, reason why time synchronisation is so important. It’s important to know that some security mechanisms use time as a component. This is the case, for example, with Kerberos, the authentication protocol at the heart of business directories such as Active Directory, which timestamps its exchanges to prevent attackers intercepting them and replaying them later.
Another example is the certificates that secure encrypted connections. They have a start and end date, so a machine that has a clock that is fast will reject a valid certificate, while a machine that is very behind will accept an expired certificate.
Lastly, the one-time codes of authentication applications, based on the TOTP (Time-based One-Time Password) algorithm, are calculated from the current time, every 30 seconds: if the server’s clock is wrong, legitimate codes are rejected.
In all of these cases, the logic is the same. The time is used to prove freshness, and the wrong time transforms a protection mechanisms into a failure or opens the door to attackers.
Time: a target and a weapon
As so many things depend on time, putting a clock forward or back becomes an attack in itself. An attacker who can change a machine’s clock can interfere with its logs, cause its certificates to expire or prolong the life of expired secrets, without touching the rest of the system.
The NTP lends itself to this: since its communications are not authenticated, an attacker on their path can alter the time distributed. This is known as a man-in-the-middle attack. But there is a defence: the NTS (Network Time Security) protocol, specified by RFC 8915, authenticates the time server and protects exchanges against tampering.
Time can also be used as a weapon against third parties. In 2013, an administration function of NTP, the monlist command, was hijacked: a small query, sent with a spoofed source address, triggered a response that was around two hundred times larger, targeted directly at the victim. Thousands of incorrectly configured time servers thus served as amplifiers for denial-of-service attacks. This vulnerability, with reference CVE-2013-5211, taught us a simple lesson: an incorrectly configured time server not only poses a risk for its owner, but it can be used to attack others.
Regulatory compliance
Over time, because of the three reasons mentioned above, time synchronisation has become a compliance requirement. The PCI-DSS standard, which sets guidelines for bank card data, calls for internal time servers in its requirement 10.4. In France, ANSSI’s logging recommendations make it a prerequisite for logs to be usable. The NIS2 (Network and Information Security) European Directive requires incidents to be reported quickly, which in practice assumes that a reliable timeline can be quickly established. For security officers, the consequence is direct: they need to check that their system’s time architecture meets the expectations of their frameworks.
Where to start?
There aren’t many things that need to be done, but they are all important. First, a controlled internal time server, i.e. a dedicated time server, is needed.
Next, this source needs to be made the synchronisation point of all the equipment, so that the consistency of the timestamping is guaranteed by design.
Finally, depending on the use, the authentication provided by the NTS protocol may be recommended in order to improve system security.
Remember that the time server itself can be considered a piece of security equipment, with some of them complying with standard IEC 62-443.
