Skip to main content

NHS Network Time Protocol guidance

The NHS Network Time Protocol (NTP) guidance describes the standards that NHS organisations should use to implement their NTP. This guidance will ensure they select and configure an appropriate NTP implementation based against their use cases and requirements.

This guidance is intended for IT managers and staff responsible for the IT systems, computers and devices within health or social care organisations.

Supporting information on NTP can be found on the Network Time Foundation's NTP pages.

Background   

NTP is a networking protocol for clock synchronisation between computer systems over packet-switched, variable-latency data networks. Find background information on NTP.

Currently NHS Digital has a contract with BT to provide an NTP service for Transition Network (TN) and HSCN   consumers. When the TN (previously known as N3) ceases, so will the NTP service provided by BT. It will not be replaced with a central service. 

NHS Digital require all organisations to reconfigure their time sources from the NTP service provided by BT on the TN, to a set of new sources.

This document provides:

  • guidance on why we should use NTP (policy statements)
  • a set of requirements and aspects that should be considered when selecting the right NTP services to use
  • standards and best practice guides on NTP implementations
  • a categorisation of some types of providers that could be used to provide an NTP service

NHS organisations must carry out their own risk assessment to determine clinical and operational requirements for their NTP solution.

Identifying devices utilising NTP service

You can identify which of your devices are utilising this service by analysing your firewall or router logs for traffic destined for the legacy NTP service. 

The destination IP address will operate on port 123 and be one of the following:

  • 194.72.7.137
  • 194.72.7.142
  • 155.231.231.1
  • 155.231.231.2
  • 155.231.231.3
  • 155.231.231.4

End of central HSCN NTP service

NTP will no longer be delivered as a central technical service and will be ceased on 31 August 2020 as part of the decommissioning of the BT Transition Network.

NHS Digital has concluded that free and open source services can fulfil the original NTP service requirement.

Migrating to a replacement service

In readiness for your migration to a local NTP source you must reconfigure your service to use alternative source addresses.

We recommend that local risk assessments and testing of the new time sources are carried out to ensure that you can receive NTP responses from the new source addresses. Your firewall policy will also need to be updated with the new time sources and BT TN legacy RIPE (European IP Networks) addresses removed. 

Why we should use NTP

All organisations connected to HSCN, or who deal with health and social care services within the UK, should ensure they configure a time synchronisation service with at least four diverse sources, of stratum three or better (the hierarchical layers of time sources used in the NTP are known as strata). This ensures that constant time is used across all their systems and devices.

Below are policy statements for the NHS and health and social care organisations within the UK. These have been produced by NHS Digital and the National Cyber Security Centre (NCSC).

NHS Digital recommend that NTP is implemented within an organisation/service consistently, in accordance with the recommended implementation requirements.

 

NHS Digital's Protective Monitoring Controls. This includes references to the NCSC’s GPG13 and ISO27001/27003 standards.

 

NCSC Security monitoring Guidance and logging for Security purposes.

Recommended implementation requirements

Recommended implementation requirements for NTP diagram

The services you synchronise with should be appropriate for your organisation’s needs and use cases.

The NHS Digital recommended implementation requirements are:

Use reliable time sources

All systems and services within an organisation or security boundary, are kept in synchronisation and ultimately synchronise from the same reliable time sources. A reliable time source is achieved by using multiple diverse sources which, when combined, provide a service that meets the availability and stratum levels required by your organisation

Have “seed” devices from which the internal clients synchronise

To limit the security perimeter, any site or implementation should have “seed” devices which the internal clients use to synchronise from. The “seed” devices synchronise to the external sources. These seed devices should have access control lists (ACLs) so they only receive NTP information from the chosen sources. For Distributed Denial of Service (DDoS) mitigations see BCP38 -Network Ingress Filtering.

Share a common approach to leap seconds

The majority of the sources used should share a common approach to leap seconds (a one-second adjustment that is occasionally applied to keep it close to Co-ordinated Universal Time).

Use four or more diverse sources

Using four or more diverse sources enhances the accuracy and availability of the time obtained. We recommend that trusted or assessed suppliers are used to provide these services.

If no external internet access is available, then the number of sources used could be reduced. Your organisation should carry out a risk assessment of the number of sources to use.

Use a stratum 3, or higher, time source

NTP uses a hierarchical system of clock strata, however stratum is not always an indication of quality or reliability. As a source for your organisations time it is a requirement to use Stratum 3 or better. This indicates the distance of the server in an NTP network from an external time source. A stratum 1 device has an external source, a stratum 2 device uses a stratum 1 device as the time reference, and so on. The last stratum level is 16; a stratum 16 device is not considered as synchronised within an NTP hierarchy.

Keep up to date with industry and vendor best practice

NTP services and technology should be kept in line with industry and vendor best practice, including vulnerability notification against the NTP protocol and versions. See the Internet Engineering Task Force (IETF) standards and best practices for NTP service provision. Reputable and trusted providers should maintain their services infrastructure to these standards. Examples include IETF definition of the NTP format within RFC 5905 and Network Time Security.

Follow IETF standards

Consumers of NTP services should also follow IETF standards for their implementations, including, but not limited to Network Time Protocol Best Current Practices and Network Ingress Filtering Best Practice BCP38.

Review configuration logs regularly

Regular reviews of the configuration logs should ensure you maintain connection to “reliable” services. Any mis-behaving services should be removed, and alternatives selected.  

Check provider complies with stated standards

Review the potential provider's compliance with the standards they claim to adhere to and review any certifications they claim to have achieved. These may indicate the level of maturity of the organisation's service processes and provide a degree of reassurance of their reliability and security. This allows selection of the most suitable and reliable sources.

Manage how you consume and provide NTP appropriately

Monitor for downtime and incidents if your chosen NTP provider doesn’t already give notification of these. You should alert upon failed synchronisation attempts or any large offset values as described in the best practice guides and industry standards. 

Synchronise at intervals that suit your organisation

Synchronise on a period/cycle/routine suitable for your organisation, and requirements. When using public sources, you should avoid excessive query frequencies.

Future selection criteria

NHS organisations must carry out their own risk assessment to determine the required resilience of their NTP solution, based on local operational and clinical requirements. For example, systems (clinical or otherwise) that depend on accurate time may require a more secure/robust solution.

Organisations should complete regular reviews of the configuration and NTP logs to ensure a reliable connection to the services is maintained. You should check any compliance certification (such as ISO27001:2013). This could indicate a level of maturity in the way the organisation provides services, offering reassurance of its reliability and security.

Check against your requirements and the guidance available to ensure you continue to utilise suitable services. 

The current NTP service provided on the TN and HSCN is not an authenticated service. Any future requirements for authenticated NTP services would need to be assessed at the time, as authenticated services generally have an associated cost attached.

Potential NTP service providers

Options available for NTP sources include:

Open source

Open source or “internet based” time services are available for free of charge over the internet. However, these have no service-level agreements (SLAs) and no guarantee of how these services are configured or maintained.

That doesn’t mean all internet based NTP providers are not building to IETF standards or are a reliable provider.

Using internet searches, it is possible to find several open source, free UK-based time service providers accessible directly from the internet. However, no formal assessment or continued assessment has been performed on any potential services.  

The reputation and certification/compliance of NTP provider organisations could indicate of a level of maturity in the way it handles and provides services, offering reassurances of its reliability and security. This allows you to select the most suitable reliable sources.

Public and private cloud hosted environments

The public cloud is defined as computing services offered by third-party providers over the public internet, making them available to anyone who wants to use or purchase them. Private cloud refers to IT services provided over private IT infrastructure for the use of a single organisation.

Global public cloud providers such as AWS, Azure and Google implement DDoS protection for their own cloud infrastructure and production services. These mechanisms will ensure no single service can overwhelm the shared infrastructure (for example, NTP is a shared infrastructure resource).

Top tier global cloud providers (such as Amazon, Azure, Google) are compliant, standards driven suppliers. They are trusted to provide global infrastructure, services and platforms for any consumer, at multiple different security levels, depending upon the relevant customer needs. Evidence for this comes from the compliance and certification their infrastructure has been assessed to. Private cloud providers may also have similar certification but that should be checked on an organisation by organisation basis.

Global cloud providers offer the time service without needing to connect the infrastructure to the internet. Therefore, we recommend you use public cloud services where appropriate as no external connectivity would be required, reducing security perimeters. If your system doesn’t require connectivity to the internet for any other reason, then you may want to reduce the number of NTP sources used. This applies if the cloud provider is a trusted provider with up-to-date compliance certification including ISO27001/2013.  

Global cloud providers such as Azure, AWS and Google Cloud meet a broad set of international and industry-specific compliance standards, such as:

  • General Data Protection Regulation (GDPR)
  • ISO 27001:2013
  • Health Insurance Portability and Accountability Act (HIPAA)
  • Federal Risk and Authorization Management Program (FedRAMP)
  • System and Organization Controls (SOC) 1
  • SOC 2

This is in addition to country-specific standards that include Australia IRAP, UK G-Cloud, and Singapore MTCS. 

Rigorous third-party audits, such as those done by the British Standards Institute, verify adherence to the strict security controls these standards mandate. The control requirements for ISO27001:2013 require the provider to ensure:

  • accurate time
  • that clock synchronisation is across all devices and systems
  • that any vulnerability in the time service technologies (such as the NTP protocol) are actively looked at and alerts responded to appropriately

This allows us to treat these cloud providers as a trusted source when using its own time infrastructure for customers.

Examples include:

Time synchronization for financial services in Azure
AWS Compliance Programs
Google Cloud - Standards, regulations & certifications

The NTP services provided by these global public cloud providers are deemed trustworthy, accurate and reliable, and can be used if your organisation has deployments already within these cloud providers’ infrastructures.

ISP or CNSP provided service

Your internet service provider (ISP) or consumer network service provider (HSCN access provider) may also offer a service which may be included within the cost of your HSCN connectivity. Their routers/devices could themselves be used to provide a source for your organisation. You should consult your supplier for further information.

Typical use cases of NTP

NTP is an important aspect of networking and digital communications and is crucial to successful auditing and cyber forensics. It ensures consistent time between log files and auditing systems over all devices and systems if they are all synchronised to the same ultimate time source.

The following use cases for NTP have been identified.

NTP in authentication

Authentication systems rely on accurate time between the device submitting the authentication request and the authenticating system.

Kerberos (v5) requires time to be within 5 minutes between client and server. Default value can be adjusted manually as Active Directory global Group Policy Object (GPO) setting.

Time-based one-time password (TOTP) algorithm - the code is only valid for a set amount of time, usually 30 seconds.

Other access authentication includes: 

  • Terminal Access Controller Access-Control System Plus (TACACS+) 
  • Remote Authentication Dial-In User Service (RADIUS) 
  • Lightweight Directory Access Protocol (LDAP) 

NTP in audit logging and cyber forensics

Log files and audit reports enable the assessment of activities over the network/devices. These logs are a combination of files obtained from multiple different hosts. Therefore, accurate timestamping between these systems is essential to ensure the correct order of the events can be identified. Consistent and accurate timestamps make combined data from these systems/devices meaningful and provides the forensic evidence should any investigations be performed.

NTP in encryption

The Microsoft Certificate Authority software ("AD Certificate Services") emits certificates ten minutes in the past.

Transport Layer Security (TLS) 1.2 (IETF) Clocks are not required to be set correctly by the basic TLS protocol; higher-level or application protocols may define additional requirements. The NCSC provides guidance on using TLS

In Secure Socket Layer (SSL), clocks are used for certificate validation. Validation involves verifying multiple aspects. For example:

  • the server's certificate (and all involved Certificate Authority certificates) must include the present time in their validity time range 
  • the revocation status of each certificate - by obtaining (and validating) a CRL (Certificate Revocation List) from the appropriate issuers (the Certificate Authority

NTP in transaction generation

In systems that rely on ordered events occurring at specific times or logging of events, inaccurate time between systems can be a problem. Transactions generated by a computer with a system time significantly different to another device may log the transaction as being received before another device’s even though it hasn’t.

NTP in scheduled tasks/events

Automatic processes such as archiving, directory synchronization, and cron jobs (time-based scheduled jobs) will execute and alter files based on these timestamps. If these jobs are scheduled from different systems and interact or rely on outputs from other systems, then the running order could be affected.

NTP in fault diagnostics

To diagnose faults and trace issues through a network you must be able to correlate events and network traffic across multiple devices using the audit data and logs generated by those devices. Consistent and accurate timestamps allow the combined data from these systems/devices to be meaningful should any investigations be performed.

You must evaluate your business needs to ensure your organisation chooses the correct NTP service provider.

Other considerations

Platform as a service and software as a service 

Platform as a service (PaaS) or software as a service (SAAS) are cloud computing models in which a third-party provider delivers hardware and software tools over the internet. These platforms have their own predefined time synchronisation configuration and cannot be changed.

The more accurate and consistent the time is across services, platforms and environments the better. Time services from the public cloud providers will better align with PAAS and SAAS components as their time settings are issued by the cloud providers systems. This also increases security by removing the need for internet facing cloud deployments to have HSCN connectivity just for time services.

Mobile and tablet devices

Some mobile devices are configured to synchronise time from the supplier’s systems. For example, Apple devices obtain time from Apple’s global NTP service.

Mobile or tablet device logs may be timestamped using a source such as Apple time service for example.

You should consider if that source can be included in any sources used for other infrastructure to help create a consistent time across all devices and systems within your organisation.

Geographical location

You should consider the geographical location of NTP sources. The latency of the network traffic has an impact on the accuracy of the timestamp obtained. Since NTP is a User Datagram Protocol, this communication will be somewhat unreliable, especially over large network topologies.

Last edited: 20 March 2020 5:14 pm