Clifford Chance

Introduction

To bolster the protection of the UK's public telecoms networks and services (PECN/S) against security compromises, the government introduced the Telecommunications (Security) Act 2021 (the Act). The Act provides a framework for the introduction of new regulations and codes of practice that place specific security obligations on providers of PECN/S (Providers).

First cab off the rank under the Act is the draft Electronic Communications (Security Measures) Regulations (Regulations) and associated Code of Practice (Code), for which the government's ten-week consultation has now closed, and consultation outcomes recently provided (the Act, Regulations and Code are referred to together in this article as the Security Requirements). The Security Requirements have been developed in conjunction with the National Cyber Security Centre (NCSC), Ofcom and industry. Unsurprisingly, Ofcom will take on new responsibilities for monitoring and enforcing compliance with the Security Requirements.

The consultation sought views on the:

• proposed measures for securing PECN/S;
• tiering system to ensure the measures are implemented proportionally for Providers;
• approach to phasing-in the measures and implementation timeframes; and
• application of the measures to legacy equipment.

The government's response to the consultation feedback

The government's response was helpfully structured along the lines of the four points outlined above, and we summarise the most important points below.

Securing PECN/S

Terminology

Clarification was sought by respondents on the meaning of certain key terminology used in the Security Requirements, such as 'security critical functions', 'network oversight functions' and 'operational support systems'. Clarification was also sought for the precise application of the perennially challenging terms under the Communications Act 2003 (CA03) – 'PECN' and 'PECS'.

The government provided further clarification for certain definitions, including the relationship between 'security critical functions', 'network oversight functions' and 'operational support systems'. However, noting that 'security critical functions' needs to remain a flexible concept to apply to various operational models used in the telecoms sector, the government declined to alter the definition of this term. Likewise, CA03 terminology will remain unchanged, with the government inviting Providers of PECN/S to make their own judgments in this regard.

Private networks remain outside the scope of the Security Requirements.

National resilience

Proposed measures for maintaining national resilience when offshoring network security functions were subject to a significant level of feedback. Some respondents suggested the outright removal of measures requiring the Providers to operate PECN/S without any reliance on overseas staff, equipment or data. Others requested that the Security Requirements specify the types of services that Providers would need to run within the UK in the event of a loss of international connectivity.

The government has been consistent in voicing its concerns over the implications of relying on overseas capabilities. Should such capabilities become inaccessible, there will be a serious risk to UK critical national infrastructure. Nevertheless, given the level of feedback, a softening of the requirements within the Security Requirements has been proposed by the government. In particular, only 'appropriate and proportionate measures' would have to be adopted by Providers. The Security Requirements now also specify the types of scenarios where there should be less reliance on non-UK security capabilities.

Management plane

The government has provided further clarity on the role of the management plane in securing PECN/S (e.g. through 2FA). Here the government has clarified that Providers have the flexibility to achieve the overarching aim (of segmenting disruptive events) in a manner that allows the use of the latest technologies, and helps ensure Providers are able to adopt an appropriate and proportionate approach.

Virtualised network functions

Respondents noted the difficulty in implementing specific measures under the Security Requirements where network functions are deployed on virtual environments – such as those provided by public cloud service providers (AWS, Microsoft, Google et al). Noting that the Security Requirements are designed to be technology agnostic, the government clarified that, where certain functions are contracted with third party suppliers (including cloud services), Providers must take appropriate and proportionate steps to hold those third parties accountable.

Privileged access workstations

Consistent feedback was received concerning the challenge that would be faced in implementing the proposed Security Requirements for privileged access workstations. Respondents submitted that relevant suppliers may not be able to remotely connect to their networks to make critical changes, hence undermining practical security efforts. However, the government confirmed that the Security Requirements do not prohibit Providers (or their suppliers) from accessing networks remotely. Secure remote connections are permitted, as long as the additional protections are implemented. Providers have been encouraged to engage with the NCSC to further clarify these technical solutions.

Customer premise equipment

A particularly curious requirement of the Security Requirements would have seen Providers (at their cost) having to replace customer premises equipment (CPE) once that equipment had gone out of support (and this would extend to business customers). Unsurprisingly this was not favourably received by respondents, and the government has now removed this requirement. 

CPE has also been excluded from the requirement for testing PECNs every two years given the likely impact this would have on customer connectivity.

Joint ventures exemption

Given the current trend in adopting joint ventures for deployment of capital-intensive PECNs (such as FTTP deployments), it is a shame that the government has declined to exempt JVs from the definition of third-party suppliers where the JV is supplying a JV-controlling party.

Supply chain negotiations

Numerous respondents outlined the practical difficulty in implementing certain Security Requirements where complex contractual renegotiations – often with large (and potentially ill-informed) multinational suppliers – would be involved. The government has gone some way to addressing these concerns for 'Tier 1' Providers (see below) by revising implementation timeframes. The government is also establishing a UK Telecoms Lab, which will be tasked with focusing on supplier diversification, security research and security testing. The government has declined to adopt model security clauses in this area, noting the bespoke nature of these contractual arrangements.

Implementing patches

Unsurprisingly, the government has softened its proposed approach that would have seen Providers being required to implement patches within a 14-day period, or alternatively record in writing why they have not done so. The Security Requirements will be updated to clearly reflect a risk-based approach for this requirement.

Tiering system

The government proposed that application of the Security Requirements should consider the size and criticality of Providers' PECN/S through the use of a tiered system.

Providers will fall under one of the following 3 Tiers:

• Tier 1 - Providers would be the largest organisations (annual relevant turnover, within the relevant period, of £1bn or more).
• Tier 2 - Providers of medium-sized companies (annual relevant turnover, within the relevant period, of more than or equal to £50m but less than £1 bn).
• Tier 3 - Providers would be the smallest companies in the market, but are not micro-entities (annual relevant turnover, within the relevant period, of less than £50m).

The measures proposed in the Security Requirements apply, in particular, to the Tier 1 and Tier 2 Providers. Tier 3 Providers may adopt the measures if relevant to their PECN/S. Also, it should be noted that the tiering system is applicable to all Providers of PECN/S, apart from micro-entities (as defined under the Companies Act 2006).

The government has considered the various submissions put forward in relation to the tiering system. However, the government confirmed its belief that the turnover of the Providers is the best way of measuring the importance of the network or service provided. This would help in assessing the ability of the Providers to meet the financial burden of applying the Security Requirements. Alternative metrics, such as security risk levels and criticality of a network or service may not be practical. They would require exposure to sensitive security information that may not be divulgeable to interested stakeholders.

Implementation timeframes

The Security Requirements contained a phased approach to implementation. It was proposed for Tier 1 Providers to comply with the following timeframes:

• The most straightforward and least resource intensive measures – to be implemented by 31 March 2023.
• The more complex and resource intensive measures – to be implemented by 31 March 2025.
• The most complex and resource intensive measures – to be implemented by 31 March 2026.

Tier 2 Providers have been given an extra two years to implement the measures beyond each of the aforementioned timeframes for Tier 1.

Many respondents expressed their concerns on the implications of these timeframes. They mentioned that they are likely to result in high costs and would potentially create new security vulnerabilities in their networks. Further, Providers would not have sufficient time to test and securely deploy the proposed new measures.

Therefore, the government has amended the timeframes for Tier 1 Providers in the Security Requirements. The timeframes have been changed to align with the Tier 2 timeframes, i.e. by adding an extra two years to the initially proposed timeframes. However, the most straightforward and least resource intensive measures will need to be implemented by 31 March 2024.

Legacy networks and services

Numerous Providers still use older technologies in their infrastructure. There is a need to ensure that all PECN/S are secure. Therefore, the Security Requirements have proposed measures to ensure the provision of lifetime support to maintain the security of such PECN/S. However, investing in new security processes to protect such equipment may require significant costs. Providers would need to scrutinise carefully any new Security Requirements to make sure that it is compatible with their legacy networks.

The government has added some guidance to the Security Requirements clarifying that Providers would be required to ensure compliance with their security duties through the implementation of the proportionate measures and to take alternative measures as necessary, based on a detailed risk assessment. They would need to collaborate with Ofcom to ensure that applying this risk-based approach delivers the expected security outcomes.

What's next?

On 5 September 2022, the amended Regulations and the Code were laid before Parliament for scrutiny. The Regulations are intended to come into force on 1 October 2022. If the two Houses of Parliament do not have any objections against the Code within 40 sitting days, the Code will be issued and published in final form.

As the responsible regulator for monitoring Providers' compliance with the Security Requirements, Ofcom's draft procedural guidance, which has also been subject to consultation, elaborates on how the regulator will exercise the new power bestowed on it.

Providers are advised to carefully consider the government's response to identify updates to the Security Requirements that they will need to implement (and by when). They will need to start testing the compatibility of their legacy systems, calculating the cost that they will incur, familiarising their teams with the upcoming changes and commence supplier contractual renegotiations.

Note to the reader:

Please note that in setting out our analysis and summary in this article, we have assumed that the reader of this article is familiar with the Security Requirements, CA03, along with the existing consultation process and papers.