Time Synchronisation

[Anonymous user]

📖 Home  Back  

Purpose

Geo SCADA uses external applications for time synchronisation to ensure:

• All Geo SCADA servers are using the same time, providing accurate data readings and correlation of logging

• Where the protocol supports the functionality, ensuring the remote devices' clocks are correct for timestamped data

For more information on what happens when the clocks drift between Geo SCADA servers refer to Effects of Considerable Server Time Changes, Setting System Clock Backwards Causes Logic to Stop Executing and Effects of RTU Clock Changes on Kingfisher Driver.

Ideally Geo SCADA servers should be in sync within a few milliseconds to avoid any problems. The same is true for the other components of the SCADA system for example client workstations, switches, firewalls and IDS/IPS devices.

Keeping Time in Sync

Windows comes with an inbuilt time service, w32time, which is used to keep a workstation and domain member server's time in sync with a domain controller, or if the workstation or server are not in a domain with an external general time source. However, as documented at http://support.microsoft.com/en-us/kb/939322, this time sync is NOT suitable for systems which require a high degree of time accuracy, such as SCADA systems.

As such it is recommend that Windows Time/w32time is disabled and an alternative suitable solution as detailed below is used.

Solution

An external time synchronisation client should be used, for example NTP for Windows, which can keep server hardware clocks in sync better than Microsoft's implementation of Windows Time.

With some software solutions, such as NTP, multiple servers can be defined as a time source providing reliability in case of a time source failure. The current time for any time sync application should be sourced from a suitable external time source such as a GPS device or an Internet time source, typically SCADA systems should not directly connect to the Internet and so a intermediary time source device should be used, such as a firewall or server within a DMZ environment.

Defining where different time sources can connect to is important to ensure that suitable time synchronisation can occur at all times and system security is easy to manage, for example:

• All Geo SCADA servers connect to the one or two provided external time sources

• All machines acting as ViewX client connect only to the time synchronisation process running on the Geo SCADA servers for their time, which servers may depend on where these ViewX clients can connect to

• One of the primary Geo SCADA servers is configured to use its local time as a valid time source (where the software allows it) so that should the SCADA system become isolated then time synchronisation can be maintained, even if the time is inaccurate, until such time as the more accurate time sources are available

• Any application servers should either connect to the Geo SCADA servers for their source of time or an alternative time source, depending on how the application server resides within the network

• Servers located within a DMZ should NOT source their data from the primary Geo SCADA servers to minimise surface area of attack

Ensure that any third party time software is kept up to date and suitable ACLs are configured in both network and host based applications to minimise the exposure of any time software to attack. Time synchronization products are a common attack vector for computer systems.

Ensure that any application that is used for time synchronisation has the minimum required permissions, this typically includes:

• Ability to change a server's time

• Network access permissions

• Run as a service

Whilst an administrator or power user may have the required permissions, best practice is to create a new user and specifically assign the relevant permissions, with additional policies applied to the user to restrict other permissions such as the ability to log in at a console.

Go: Home Back