It’s a new year and the first returns have been sent, but are there things that are likely to be hampering your TSA programme that you may not be aware of?
In my experience of not just delivering compliance with CAS(T), HSCN but now the Telecommunications Security Framework (also called the TSA) there are five things that I see a lot within organisations both large and small that will cause issues if not addressed.
Addressing these will ensure that organisations and professionals alike are aligned in the level of understanding required to move forward to achieve compliance.
#1 – only reading the technical guidance measures.
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.
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 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)).
What’s the impact?
If you are not treating the entire code of practice with equal weight, then you will miss important things such as:
- The definition of “existing” contracts (defined within the Key Concepts)
- The key risks to be reviewed annually (detailed within the Regulation 11(b))
- All the activities to be undertaken for Security Critical Functions (many of which are within the Indicators of Good Practice (IGPs) in Annex C due to text at the beginning of that Annex)
In essence, important context will be lost as we will discuss in terms of compliance below.
I’m also seeing projects create definitions to be met for encryption etc. which are not mentioned in the code of practice, which only serves to create a false baseline which isn’t intended by the security framework.
What can you do about it?
Ensure that your mapping of technical guidance measures doesn’t just rely on the ones within the Code of Practice, there are mappings to be had from the Regulations to the Key Concepts, and the Key Concepts to the IGPs. Once you have conducted the mapping, then it’s crucial to identify where existing policy and standards can assist with the outcomes to be met where specific detail is missing.
#2 – fearing fines rather than managing risk
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 outcomes are primarily held within the specific security measures in the regulations
- Technical guidance measures are the primary mechanism to check if the legal outcomes have been achieved
- The relevant Indicators of Good Practice (IGPs) of the Cyber Assessment Framework (relevant CAF) in Annex C need to be 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.
What’s the impact?
Whilst it is tempting to influence the organisation by saying ‘if we don’t do X by Y then we will be fined’, it makes it difficult to focus on what is important and implement the culture change required to implement the governance which will make it easier to respond to the governance questions from Ofcom. This should’ve become clear from the first tranche of requests, where the governance which underpins the delivery of the outcome was requested, along with what is being done regarding the gaps.
What can you do about it?
Within the mapping of the specific security measures to the key concepts, technical guidance measures and IGPs, extract the relevant areas for implementing the risk management regime which the code of practice details. I’ve detailed these areas within one of my articles which details the governance requirements.
#3 – letting the next compliance date drive your requirements
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.
What’s the impact?
The real challenge with this approach is that there is a tendency to focus on the first set of items which are grouped by their implementation date, then the second etc.
This means that important context can be lost, with a useful example being persistent and non-persistent credentials. Within security, a non-persistent credential (mentioned in M6.01) is usually one which doesn’t stay static (e.g. ephemeral keys), but it’s only when you review the technical guidance measure M11.02 that you realise what is meant in this context is a credential which is subject to normal account governance (e.g. password changes, ageing etc.).
It also means which that solutions could be developed which meet an earlier outcome, based on associated detailed analysis, which result in the latter outcomes either requiring a different solution or a costly addition.
What can be can be done about it?
Whilst there is a recurring theme of aligning your analysis of outcomes to the measures, key concepts etc., the key item here is to group your analysis into common areas which have similar characteristics and review everything at the same time, prioritising the more recent dates with an eye to the later ones.
Don’t be tempted to try and state that everything needs to be done now, as the requirement remains for everything to be done by the end state and not at the beginning.
Do, however, ensure that you highlight what is required for the future as it may be that a future project/programme in the business could be influenced in its direction.
An example of how this could be achieved is within the HSCN Compliance Operating Model, where I assisted NHS Digital in creating the HSCN Compliance Addendum Annex A.
#4 – struggling to understand key asset types
There is an understandable misunderstanding of the current security critical functions (SCFs), 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.
In addition, network oversight functions (NOFs) have specific obligations within the Code of Practice which will mean that some intended deployments (i.e. into areas of lower assurance such a Public Cloud) would be difficult to assure. NOFs are more related to the security and management of SCFs, but definitions of NOFs in the code of practice include audit and monitoring systems (including network quality monitoring of speech and data).
I’m seeing organisations which are looking at the technical guidance measure M16.07 (which has an evidenced by date of Q1 2027) and thinking this point doesn’t matter until then, but for the reasons earlier in this article that is an unwise distinction to make as the definition above is in the definitions of the code of practice itself.
What’s the impact?
Failing to understand the proper definitions will result in not only an incorrect scope, but will also fail to deliver the resilience requirements that Ofcom require as a result of the uplift to the Communications Act.
What can I do about it?
Thankfully, there is already a detailed glossary within the Code of Practice as well as a lot of detail within Section 1 of the Code of Practice itself.
There is a detailed discussion on the types of assets to be captured in a dedicated article in the series I am writing on the Telecommunications Security Framework.
#5 – worrying how to manage Cloud services
There is a perception that public Cloud services or open-source software within them 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 and/or open-source software components are utilised, that the risk of using these services is assessed both in terms of cyber security and resilience.
What’s the impact?
As we head towards a more Cloud-centric architecture for telecommunications, the delivery of these services very much mirrors that of public Cloud and the components used within the containerised network functions (CNFs) are often open-source in nature. Failing to address the challenges of Cloud and open-source will likely result in components being delivered in a state that is hard to maintain and assure.
It is common for open-source components not to have all the security features enabled, and commercial services can be reliant on the community to provide fixes for operational/security issues. You could also be in the scenario where NOFs could be placed in Cloud in a manner that are much harder to assure (e.g. monitoring solutions or key controls being delivered as SaaS).
What can you do about it?
It’s important that organisations understand both where Cloud architectures are used, and the components within them. The use cases for Cloud services need to be understood to manage the risks, and the components need to be understood in terms of how they can be configured securely and maintained in line with your policies.
It may well be the case that components are used deep within the delivery of the service which are not visible to usual testing techniques, and this is where the Vendor Security Assessment within the code of practice can assist you. Other areas to assist with assessment are the OWASP Top 10 CI/CD Security Risks and the Cloud security shared responsibility model from the NCSC.
Looking at the shared responsibility model allows us to adapt it for the challenges of Cloud-native services within telecommunications as well, which allows us to align governance and control areas as shown below.
In summary, read what’s written and not what’s heard
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 likely be the sole arbiter in the event of legal challenge.
The devil is very much in the detail regarding the approach to be taken and the interdependence in items within the code of practice.
Don’t get caught out using bad advice to plan your compliance, and feel free to message me if you have further questions.