Making sure you don't CoP a packet - demystifying the Telecommunications Security Framework - overview

I've been involved in many compliance frameworks, predominantly within the Telecommunications industry over the past decade, and the most recent one in Telecommunications (the Telecommunications Security Framework) is getting a lot of visibility - maybe because it has big financial penalties being mentioned and the security industry likes a big penalty to get the attention of the board.

This article will form part of a series of articles which will cover:

• An overview of the security framework itself (this article)
• Addressing common myths
• What needs to be understood in terms of assets
• Considerations for governance
• How to manage privileged access
• Managing Third Party Admins (3PA)
• The requirements for being resilient
• Things to consider when using Cloud services

TSR/TSA/CoP - what is it?

• The?Telecommunications Security Act 2021?which is where the common term of TSA comes from. The TSA is the piece of legislation which defines the duties, roles and powers – including?amending duties within?sections 105a-d within the Communications Act 2003?and creating new duties within sections 105I-K of the Communications Act – this came into force on the 17th November 2021.
• The?Electronic Communications (Security Measures) Regulations 2022?define the specific security measures (also called 'the requirements') to be undertaken by providers of Public Electronic Communications Networks (PECN) and Public Electronic Communications Services (PECS) – this came into force on the 1st October 2022 (this date is very important as we shall discuss later on).
• The?Telecommunications Security Code of Practice?(CoP) provides detailed technical guidance to providers of PECN and PECS on the measures to be taken under sections 105A to 105D of the Communications Act, with the development, compliance and maintenance of the CoP being defined within sections 105E-I?of the Communications Act – this came into force on the 1st December 2022.

What about TSR, I keep hearing that term - is that the same as the TSA or the security framework?

The Telecommunications Security Requirements were the pre-cursor to the Technical Guidance Measures in the Code of Practice, and were the first evolution in moving away from the legacy CESG Assured Service (Telecommunications) regime (also called CAS(T)) which was the compliance regime for telecommunications providers which was retired in 2020 but still lives on in the HSCN Compliance Operating Model in a revised format.

Effectively, TSRs were designed to look at managing communications which were deemed part of Critical National Infrastructure (CNI) and were discussed in the Security analysis for the UK telecoms sector which was published by the National Cyber Security Centre (NCSC) pre-pandemic in January 2020.

However, understanding the TSRs allows us to understand some of the misunderstandings that those within the security community who were involved then are making now. The definition of security critical functions in the TSRs said that "Operators use security critical functions to enforce security controls in their networks and mitigate risk", yet that definition has totally changed within the Code of Practice.

Another common misunderstanding is the level of importance given to the 258 technical guidance measures, which have a direct lineage to the legacy TSRs. A key quote from the Code of Practice itself reinforces this point.

Section 2 explains the key concepts that need to be understood by all providers when applying the specific security measures contained within the Electronic Communications (Security Measures) Regulations 2022 (hereafter referred to as ‘the regulations’) and by providers when applying the technical guidance measures within Section 3 of the code of practice

How the Code of Practice has evolved since the TSRs

The Telecommunications Security Framework changed focus from CNI towards the Public Electronic Communications Networks (PECN) and the Public Electronic Communications Services (PECS) within the Act and the Regulations; and added not only the key concepts within section 2, but also areas of the Cyber Assessment Framework (CAF) that were deemed necessary to operate governance of the technical guidance measures and their associated key concepts.

Technical guidance measure M5.01 actually links out to 70 Indicators of Good Practice (IGPs) which are to be met to show that the objectives within the relevant areas of the CAF (which I call the relevant CAF) are met. For the reasons above, some people are missing the importance of the IGPs - which given the start of Annex C which contains them states that 'Any references in this Annex to ‘essential functions’ should be considered as ‘security critical functions’ for the purpose of this code of practice.' would be misguided.

Key assets types within the Code of Practice

There are four main types of assets to be considered within the Code of Practice, PECN and PECS, the revised Security Critical Function (SCF) and the Network Oversight Function (NOF).

The PECN is defined within the Communications Act 2003 as being:

An electronic communications network provided wholly or mainly for the purpose of making electronic communications services available to members of the public.

The PECS is defined within the Communications Act 2003 as being:

Any electronic communications service that is provided so as to be available for use by members of the public

An electronic communications service is defined within the Communications Act as:

A service consisting in, or having as its principal feature, the conveyance by means of an electronic communications network of signals, except insofar as it is a content service.

The definition of the SCF is important to understand:

A ‘security critical function’ in relation to a public electronic communications network or service means “any function of the network or service whose operation is likely to have a material impact on the proper operation of the entire network or service or a material part of it

The SCF is now not related to cyber security, but the operation of the PECN and PECS, and given the requirement to apply governance from the relevant CAF to them, these are important assets to understand.

NOFs on the other hand are more regarding the management and operation of controls for the operation and security of the PECN and PECS themselves and:

Network oversight functions are the components of the network that oversee and control the security critical functions, which make them vitally important in overall network security. They are essential for the network provider to understand the network, secure the network, or to recover the network.

It is vitally important to read the key concepts and technical guidance measures carefully as assets can become NOFs due to the function they perform. A notable one is M16.07 which states:

Systems that collect and process logging and monitoring data shall be treated as network oversight functions.

When does this all apply?

Regulations 3(1)(a) and 3(1)(b) define some important concepts:

3(1)(a) A network provider must take such measures as are appropriate and proportionate to ensure except in relation to an existing part of the public electronic communications network, that the network is designed and constructed in a manner which reduces the risks of security compromises occurring

3(1)(b) A network provider must take such measures as are appropriate and proportionate to ensure in relation to an existing part of the public electronic communications network, that the part is redesigned and developed in a manner which reduces the risks of security compromises occurring

But what is existing I hear you cry? Well we need to look at regulation 3(2):

For the purposes of paragraph (1), an existing part of a public electronic communications network is a part that was brought into operation before the coming into force of these Regulations.

Remember the date when the regulations came into force? This applies within regulation 3(2). So, this now means that:

• Anything deemed to be a PECN that came into operation after the 1st October 2022 must now use the Code of Practice for its design process
• Anything deemed to be a PECN that existed prior to the 1st October 2022 must be redesigned (i.e. when you look through the Code of Practice this actually means ensuring it's either compliant or segregated from new PECNs).

Note - the above only mentions networks, it doesn't mention services. However, regulation 3(3)(a) requires that everything running on the PECN must also manage risks (which will require using the technical guidance measures and key concepts within the Code of Practice), so you really should read PECN in this instance as being PECN and PECS both having to comply from the 1st October 2022.

I can't do all of that now, what do I do?

The security framework has already considered the complexity of implementing activities in a wholesale manner and has used the tiering mechanism from Ofcom (which is linked to revenue) to determine the implementation timescales for both PECN and PECS according to one of the three tiers below:

• Tier 1 providers (with relevant turnover in the relevant period of ￡1bn or more) must map their compliance in different areas between the 31st March 2024 through to the 31st March 2028 (as shown below in Fig.1)

The grouping of the themes from the Code of Practice for tier 1 providers are shown in Fig.2 below:

Key activities for consideration for tier 1 providers (including the specific security measures from the regulations) are below in Fig.3:

• Tier 2 providers (with relevant turnover in the relevant period of more than or equal to ￡50m but less than ￡1bn) must map their compliance in different areas between the 31st March 2025 through to the 31st March 2028 (as shown below in Fig.4). Note how the activities from 2024 merely collapse into 2025, so whilst the time for initial evidence of implementation is greater, the effort for both tier 1 and 2 providers for evidence of implementation is the same by 2025.

The grouping of the themes from the Code of Practice for tier 2 providers are shown in Fig.5 below:

Key activities for consideration for tier 2 providers (including the specific security measures from the regulations) are below in Fig.6:

• Tier 3 providers (whose relevant turnover in the relevant period is less than ￡50m, but who are not micro?entities) are not expected to map their compliance but are still expected to comply to the duties and regulations in an appropriate and proportionate manner. It should be noted that it is very likely that the tier 1 and 2 providers that use their services will expect a level of adherence to their own obligations.

These are the timeframes by which providers would be expected to have taken relevant measures set out in the code of practice, whilst recognising that due to the existing threat environment, the quicker providers are able to implement measures the better.

What do you mean when you say 'map their compliance'?

I said at the beginning that the big penalties within the Act and Regulation are getting visibility within the board and security professionals who are now wrestling with their respective compliance programmes. The simple fact is that failure to implement the technical guidance measures, the related key concepts and the relevant CAF by the required date doesn't necessarily equate to the penalties which I will discuss in a minute being levied.

The key here is to ensure that the providers can provide evidence that they have reviewed all the technical guidance measures, key concepts and relevant CAF and determined their ability to either meet the measures or the specific security measures, as detailed below:

The guidance set out in this code of practice is not the only way for providers to comply with the new security duties and specific security requirements that have been placed into law. We appreciate that where the regulations require public telecoms providers to take ‘appropriate and proportionate’ measures, what is appropriate and proportionate will depend on the particular circumstances of the provider.

Section 105H(1) in the Telecommunications Security Act 2021 (which now resides in the amended Communications Act 2003) also reinforces this point, stating that

A failure by the provider of a public electronic communications network or a public electronic communications service to act in accordance with a provision of a code of practice does not of itself make the provider liable to legal proceedings before a court or tribunal.

In addition to this, the process of what will be considered in the event that something in the code of practice is part of legal procedures against a provider of PECN/PECS is detailed within section 105H(2).

In any legal proceedings before a court or tribunal, the court or tribunal must take into account a provision of a code of practice in determining any question arising in the proceedings if—

(a) the question relates to a time when the provision was in force; and

(b) the provision appears to the court or tribunal to be relevant to the question.

So what are the penalties then?

The penalties are twofold, the initial contravention is a maximum 10% of relevant turnover of the public communications provider’s relevant business for the relevant period (e.g. in the event of a mobile PECN, then the relevant turnover of the mobile business for the accounting period).

For continuing contraventions, then a penalty of ￡100,000 per day up to a maximum of ￡10,000,000 can be levied.

OK, so how likely is this going to happen?

The simple answer is that no-one really knows but we can look at the previous penalty levied by Ofcom on O2 in 2021 for some key pointers.

Although levied for the billing failures and not cyber security, the key aspects of relevance within the confirmation decision were in the failures of governance and the impact to customers. The key statement within the confirmation decision that applies here is:

As set out in our Penalty Guidelines, the central objective of imposing a penalty is deterrence. The level of the penalty must be sufficient, having regard to the relevant turnover, to have a material impact on the regulated body so that it is incentivised to bring itself into compliance and avoid recurrences of the contraventions in future. It is also important that the penalty imposed serves to deter the wider industry from contravening regulatory requirements.

I've highlighted the link to the Ofcom penalty guidelines above to make a point that the above phrase exists within the guidelines themselves which were published in December 2015.

The key point here is that your governance will be reviewed in the event of a contravention along with the impact to customers, and the mechanism exists within the Act and Regulations for providers to discuss where they believe they are not fully compliant with a measure and what steps they are taking to not only address the gap but deploy a robust alternate mitigation in the interim.

So, despite what many may tell people regarding the big penalties, it's more important to understand that failing to meet the technical guidance measures (including the key concepts or relevant CAF) or the specific security measures will not automatically result in a penalty as shown below from another extract within the Code of Practice.

A public telecoms provider may choose to comply with those new security duties and specific security requirements by adopting different technical solutions or approaches to those specified in the code of practice. When they do so, Ofcom may require the provider to explain the reasons why they are not acting in accordance with the provisions of the code of practice in order to assess whether they are still meeting their legal obligations under the security framework.?

If you fail to review the gaps and cannot show effective governance however, then expect a penalty to be more likely.

If you need help understanding this further, then reach out on LinkedIn. Otherwise stay tuned until my next article on addressing the common myths!