Most industrial and public infrastructures (transport, medical, etc.) have a time server. Its role is to distribute a common time reference to all equipment: PLCs, supervision tools, network peripherals, computers, medical imaging devices, etc. They all rely on a time server to timestamp the exchanges and events in their logs. This dependence is critical. If the time server is no longer working or is unavailable, timestamping will be incorrect across the whole system. It then becomes impossible to analyse the chains of events impacting the different components. Traceability becomes uncertain and the regulatory compliance that depends on it is no longer guaranteed. If not properly secured, the time server can also open the door to cyberattacks (e.g. DDoS attacks, invalidation of certificates or log “obfuscation”).
From isolation to exposure
The exposure of industrial systems to this type of attack is a fast-growing problem. Not that long ago, operational networks were physically separated from corporate IT networks. That way, they benefited from some sort of protection, as this equipment could not be reached from the outside, making it naturally resilient to remote attacks.
The gradual connection of industrial systems, known as OT (Operational Technology), to global IT networks, enables remote supervision and robust cloud storage. However, this development opens the door to numerous cyberattacks. Industrial systems are therefore now vulnerable to the same threats as traditional computing, without having being designed to withstand them. Securing network equipment, including time servers, is becoming essential.
Reliable synchronisation, even under constraints
Secure your time infrastructure via stable and redundant synchronisation, suitable for critical networks.
Standard IEC 62443
This standard, which is made up of several parts, establishes the cybersecurity measures for Industrial Automation and Control Systems (IACS). IEC 62443 was produced by the International Electrotechnical Commission (IEC) in partnership with the International Society of Automation (ISA). Part 4-2, published in 2019. It establishes the technical security requirements applicable to the components of this kind of system.
The regulations themselves legitimise this standard. Indeed, the NIS2 (Network and Information Security, version 2) European Directive lays down precise cybersecurity objectives for many essential sectors, but without explaining what technical means should be deployed to meet them.
Standard IEC 62443 satisfies this requirement. It defines the specific framework needed to meet the objectives of the NIS2 Directive. Furthermore, the future European certification scheme for industrial infrastructures is expected to refer to this text. In addition, NIS2 requires each company to secure its supply chain, i.e. its suppliers, which means that the equipment itself needs to comply with the standard. It therefore becomes mandatory to have only compliant equipment in the network.
The operating principle of standard IEC 62443 is fairly simple. This standard divides a system into zones. A zone is a group of equipment with the same security needs. These zones communicate through conduits. A target security level is assigned to each zone. The target security level (SL-T) ranges from SL1 to SL4 depending on the level of sophistication of the attacks you want to protect against.
This level is estimated by quantifying the level of seven fundamental requirements of the standard, namely authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and finally resource availability.
A system component will be characterised by its ability to reach the target security level, the Capability Security Level (SL-C). For a zone to reach the target, its components must all have an SL-C at least equal to the SL-T for each requirement.
The time server, a network component that needs securing
Part 4-2 of standard IEC 62443 distinguishes between four categories of components: embedded devices, host devices, software applications and network devices.
A time server belongs to the network devices category. It must meet the requirements of its category and the level of the zone it is in.
For the authentication and use control requirements, this means, for example, that administrator accounts need to be identified individually and that actions need to be restricted according to each person’s role in these administrator accounts. For system integrity, it is essential to verify the microsoftware and the time server updates. The time server also needs to log its own security events. It is important to note that a time server that can be administered by a shared account and with no traceability will still have a low SL-C and will reduce the level of its entire host zone.
In the list of fundamental requirements mentioned above, one of them calls for special attention: resource availability.
In corporate IT, it is often said that confidentiality is the most important requirement, but in OT, availability is. Indeed, an industrial control system must always continue to function. The resource availability requirement therefore demands that a component withstand a denial-of-service attack and maintain its essential functions, no matter what. For a time server, this availability depends on two mechanisms. First, its time source: if the GNSS (satellite) signal is lost, the internal oscillator takes over time distribution until the signal returns to ensure service continuity. This is what is known as holdover. Secondly, redundancy: if the server itself crashes, a redundant architecture (with a second time server) prevents interruption of reference time distribution.
CR 2.11 Timestamps
The time server is not just another system component. It fulfils a very specific mission specified by standard IEC 62443. Indeed, this standard calls for each piece of equipment to timestamp its logs under CR 2.11 (Component Requirement 2.11). This requirement consists of two essential prerequisites: time synchronisation inside the network, and protection of the integrity of its reference time source.
A system component cannot, on its own, satisfy either. For this, an internal time source is necessary. This role is fulfilled by a local time server integrated into the network infrastructure, as opposed to a public time server. Furthermore, to improve the integrity of its time signal, the time server can use secure protocols such as the NTS (Network Time Security) protocol, defined by RFC 8915. The presence of a time server in the network is therefore a condition essential to compliance with CR 2.11.
Choosing a compliant time server
Compliance with standard IEC 62443-4-2 can be declared by the manufacturer or verified by a third party. The former only involves a declaration. For the latter, the ISA Secure CSA (Component Security Assurance) scheme vouches that a component has been assessed, for a certain security level, by an independent third party.
Independent certification guarantees regulatory compliance. It comes into its own when the company is itself subject to a compliance obligation. It must then ensure that the equipment it installs is also compliant. Compliance verified by a third party is much stronger than a simple manufacturer declaration. In a zone with a high expected security level, this distinction becomes an important selection criterion.
It should also be noted that the choice of a time server is based on two criteria. The first is the intrinsic quality of the time signal distribution. A number of questions are raised. Which time reference does the GNSS antenna refer to? What oscillator quality and what level of holdover precision will ensure continuous time availability in the event that the satellite signal is lost? And lastly, which protocol is used for time distribution in the network: PTP, NTP or NTS? The latter adds extra protection against tampering.
The second criterion is robustness to cyberattacks, ensuring that the server requires users to be authenticated individually. It must be able to manage permissions depending on each person’s role, verify its own integrity, log security events, withstand attempted denial-of-service attacks and guarantee the declared security level.
