Making sure you don't CoP a packet - demystifying the Telecommunications Security Framework - addressing common myths

Building on from my previous article giving an overview of the Telecommunications Security Framework, I'm now going to look at some of the myths that have arisen around the subject which need addressing to ensure that organisations and professionals alike are aligned in the level of understanding required to more forward to achieve compliance.

Myth one - the 258 technical guidance measures are the sole compliance target

This is a common one, and essentially driven from those who were involved in the legacy Telecommunications Security Requirements (TSRs), as that is the precursor to the 258 technical guidance measures within Section 3 of the?Telecommunications Security Code of Practice.

This isn't true and it is important to understand that the code of practice is intended to provide the key activities that require assessment to meet both the security duties that the?Telecommunications Security Act 2021 amended within?sections 105a-d within the Communications Act 2003 and the specific security measures (also called 'the requirements') from the Electronic Communications (Security Measures) Regulations 2022.

The technical guidance measures need to be read in conjunction with the key concepts from the code of practice, the relevant areas of the Cyber Assessment Framework and the specific security measures from the regulations in order to understand the full objectives to be met.

They also need to be reviewed against the assets that are deemed within the scope of compliance (Public Electronic Communications Networks (PECN), Public Electronic Communications Services (PECS), Security Critical Functions (SCF) and Network Oversight Functions (NOF)).

This is crucial as, otherwise, important context will be lost as we will discuss in terms of compliance below.

Myth two - if we don't implement the activities within the Code of Practice we will be fined

This myth is being heavily perpetuated by the consultancy community engaged with delivering these activities - that if you don't implement the technical guidance measures by the due date then a penalty will be levied.

This is simply not the case, the key is that you have reviewed the compliance target detailed above and have identified for the assets within scope:

• Your ability to meet the measure by the due date, to the level detailed within any relevant key concept and/or specific security measure
• Your ability to meet the related specific security measure by the due date, in the event that you are unable to meet the technical guidance measure
• Any robust alternate mitigation, subject to risk treatment, which is linked to the technical guidance measure/specific security measure you are trying to comply with

Think of it this way:

• The legal obligations for security are primarily held within the specific security measures in the regulations
• Technical guidance measures are the primary mechanism to check if the legal obligations have been met
• The relevant Indicators of Good Practice (IGPs) of the Cyber Assessment Framework (relevant CAF) in Annex C need to met to meet the governance requirements within M5.01
• The key concepts are intended to be reviewed to ensure that you can evidence that the technical guidance measures have been assessed in alignment with the requirements of the regulation
• In the event that you cannot meet the technical guidance measures, you will be expected to revert to the specific security measures for your assessment

In the event that you cannot show that you have reviewed any of the above, then you will be unable to show Ofcom that you have taken steps to comply with the legal obligation, as detailed in the code of practice itself:

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.?

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.

Myth three - we don't need to be compliant until the due date

Another common misconception, as the regulation is clear that any new PECN (including the key functions related to it, including PECS) brought into operation after the 1st October 2022 needs to show that it is considering the code of practice within its design and governance processes.

The dates within the code of practice are implemented by dates, which means that the intent is that you have either implemented the technical guidance measure, something equivalent (which will require discussion with Ofcom) or implemented a robust alternate mitigation (which will require discussion with Ofcom) by that date. The clock is ticking and some of these activities will need to be started now to meet the dates.

Of note is that tier two providers will be thinking that they have lots of time as their first implemented by dates are a year later than tier one providers. Please be aware that the second tranche of measures has not been delayed so thinking you have an extra year will only serve to double the effort rather than starting now.

Myth four - security critical functions are related to security

There is an understandable misunderstanding of the current security critical functions, which change from a previous definition from the TSRs of 'Operators use security critical functions to enforce security controls in their networks and mitigate risk' the current one below in the code of practice of:

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”

Given that all references essentials in the governance requirements from the relevant CAF are to be read as security critical functions, it's crucial to understand the revised concept of the key asset type.

Myth five - public Cloud services are not allowed

There is a perception that public Cloud services cannot be used within PECN/PECS, but this is not the case.

The code of practice makes it clear in technical guidance measure M2.06 that:

The infrastructure used to support a provider’s network shall be the responsibility of the provider, or another entity that adheres to the regulations, measures and oversight as they apply to the provider (such as a third party supplier with whom the provider has a contractual relationship). Where the provider or other entity adhering to the regulations has responsibility, this responsibility shall include retaining oversight of the management of that infrastructure (including sight of management activities, personnel granted management access, and management processes).

This is bolstered by key concept 6.7 which makes it clear that:

It should also be noted that public telecoms providers are ultimately responsible for the security of their networks and cannot outsource this responsibility to third parties. Where providers do outsource aspects of operations to a third party, responsibility to comply with the obligations contained within new sections 105A-D of the Communications Act 2003, and the obligations set out in the regulations, remain with the provider. The provider therefore needs to have sufficient internal capacity to meet those obligations.

The key here is to ensure that where public Cloud services are utilised, that the risk of using these services is assessed both in terms of cyber security and resilience. I will be discussing how to adopt Cloud services in a future article.

In summary, read what's written and not what's heard

There are other myths, but these are the key ones I'm seeing now.

It's really important that anyone who is advising on these areas is reading what it actually written rather than what has been heard in side conversations that hasn't made it into the components of the Telecommunications Security Framework.

These are components with legal weight, and the text within them will be the sole arbiter in the even of legal challenge.

Don't get caught out using bad advice to plan your compliance, and feel free to message me on here if you have further questions.