So we are now at the half-way point in an eight part series on the Telecommunications Security Framework which is intended to allow providers of public electronics communications networks and services (PECN and PECS) to understand the key activities they need to assess to show compliance with the duties and specific security measures under law in the UK.
A bit of a mouthful that, but the reality is that many undertaking this journey are still looking at the technical guidance measures and failing to read the entirety of the telecoms security code of practice from cover to cover. In a governance context, this is going to result in a fair few being lacking when their compliance is measured. You see, the compliance reporting regimes are essentially looking for two things:
- Do you understand what you have in terms of services, assets and interdependence between them? Covered in my last article.
- Do you understand what controls you have in place, why those controls meet your duties and specific security requirements and where they aren’t applied (including what mitigations you have implemented). (The purpose of this article BTW)
Getting the structure right – the relevant CAF
The one thing that many are getting confused about is how to implement effective governance within the security framework, and that is where technical guidance measure M5.01 comes in to create a governance structure using relevant objectives from the Cyber Assessment Framework (relevant CAF).
It should be noted that the Indicators of Good Practice (IGPs) in achieved within Annex C of the code of practice could technically be undermined by IGPs that are within the not achieved or partially achieved sections, but it’s safe to assume that you should be looking to baseline against the 70 IGPs at achieved to meet M5.01.
The categories of IGPs at achieved are shown in Fig.1 below and need to be meet by 31st March 2024 for tier one providers of PECN and PECS and 31st March 2025 for tier two providers of PECN and PECS.
It should be noted that Annex C within the code of practice also requires that any reference to essential functions within the IGPs should be read as security critical functions.
This gives further credence to the notion that this should be the first activity on your compliance journey, especially given that I’m often asked by clients how to interpret the term ‘appropriate and proportionate’ within the specific security measures detailed within the regulations – the simple answer is that you have to have a functioning governance structure to undertake the risk assessments in order to determine what is appropriate and proportionate.
Risk management – setting the foundations
Risk management in the code of practice is very detailed, but you need to read carefully. Fig.2 and fig.3 show the spread of risk management with both tier one and two providers
The reason why I say that you have to read carefully is that you have to review risks in the following areas at least annually:
- the risk of security compromises in the network and its functions
- the risks relating to storing monitoring and network tools in proscribed countries
- the risks of anomalous activity causing security compromises
- the risks of security compromises happening due to activities of third parties
- the risks of security compromises occurring due to the unauthorised activities from staff involved with maintaining the PECN/PECS
Now if you are only looking the technical guidance measures, then this isn’t mentioned but it is within regulation 11(b) and key concepts 4.6 and 10.3.
Not only that, but that same regulation requires that the results of reviews of controls for PECN/PECS must be reviewed annually along with any audits conducted and any other relevant information.
What is any other information is relevant you ask? Key concept 10.3 details more.
This latter category of information may include, for example, ‘event correlation analysis’ where relevant. This is where security incidents have been identified by providers which may not have amounted to security compromises, but showed similar root causes and can be classified as near misses. These security incidents are important in assessing the risks of security compromises going forward and should therefore be integrated into the reviews process.
It’s therefore important to ensure that your approach to risk has the correct inputs throughout the business to ensure that review activities are informed by what is occurring within the organisation.
Inputs into the risk management process
The following are expected to be understood within the risk management process:
- how signalling enters and leaves the network
- the network equipment that can be impacted by malicious signalling
- the network and user data that can be compromised by malicious signalling
- connections with other organisations used for communicating signalling traffic
- any network equipment used for sending and processing external signalling
- any site where the provider cannot guarantee the security of the physical site itself
- any key security, audit or monitoring activities that are undertaken outside of the UK
- any key operational activities that are undertaken outside of the UK
- any key services (e.g. fixed/mobile data, mobile voice, text-based mobile messaging) that are reliant on key activities that are undertaken outside of the UK
- any insecure access paths used for privileged access
- any administrators that have multiple privileged roles assigned to a single account
- any systemic faults within the software/firmware of equipment
- the capabilities of suppliers to deliver secure equipment
- any vulnerabilities that are only mitigated and not patched
- any large amounts of subscriber data (over 100,000 records) stored outside of the UK
- any near misses from reported incidents
- any recent changes to could require a review of the risk assessments
- the threats that can impact the security critical functions and the telecommunications sector in general
- the vulnerabilities in the networks and information systems supporting the security critical functions taking into account the items above
- the risk appetite within the organisation
- the adverse impacts relating to your security critical functions, and when looking at these impacts, bear the following in mind:
The risk assessment that these providers must carry out as a part of the reviews process under Regulation 11 should be looking at not only the risks to the provider’s business and network, but also the risks to end users. This includes, but is not limited to, the risks of loss of availability and of personal data leaks.
There’s a lot in there, and a lot of is (understandably) linked to your understanding of the security critical and network oversight functions and their interdependence. Not only that, there is a need to understand how privileged access is undertaken (both in terms of internal staff and third-party administrators (3PAs)).
How to manage the risks
Note within this article I will not provide a risk assessment methodology, as it is very much a process that divides many and ranges from the qualitative (less proscription and more flexibility) to the quantitative (much more detail and less flexibility).
The areas for consideration above include a need to understand the threats, vulnerabilities and impacts that form the cornerstone of most risk assessments, whether that is simply a combination of impact and likelihood or the expansion of likelihood into the threats and associated vulnerabilities that influence it.
A good starting point for starting on the right path is the Cybersecurity Toolkit for Boards which discusses indicators for risk management.
I will, however, discuss how the code of practice requires risk assessment to be structured and considered. The code of practice requires a range of activities, including:
- the risk management approach policy to be owned at board level
- that a board member is accountable for the security of networks and information systems
- the risk management processes to be documented
- that roles and responsibilities of the security of the networks and information systems supporting the security critical functions are defined and reviewed
- that the board has visibility of the key risk decisions made within the organisation
- that mechanisms exist for risks to be raised directly to the board without dilution
- that risk decisions within the organisation shall be taken quickly and in mind of the risk appetite
- that risk decisions are delegated to those who have the authority, skills, knowledge and tools to do so
- that risk management decisions that have been made are subject to periodic review (at least annually in light of regulation 11(b))
- that records are maintained of risk decisions
- that risk decisions result in clear treatment activities
- that risk treatment activities will endure for the life of the networks and functions
- that control performance metrics are defined to measure performance
- that the assurance processes used to assess the performance of risk processes is reviewed
- that any deficiencies in the risk process or treatments are identified
- that improvements for deficiencies are assess, prioritised and remediated
What are the key risk decisions?
Whilst key risk decisions will ultimately arise from the risk assessment and inputs above, using the risk assessment framework form the relevant CAF, there are key decisions that are expressly mentioned within the code of practice such as:
- any PECN, PECS or functions that are assessed as being out of scope
- any technical guidance measure, key concept, IGP or specific security measure that cannot be complied with, including how these are mitigated by other means
- any reliance on offshore resources to maintain/operate the PECN, PECS or functions in scope
- any reliance with other providers (up or downstream)
- any use of insecure communications for admin access
- the risks related to storing customer/network data offshore
- the level of hardening for network oversight functions
- the effectiveness of mitigations for vulnerabilities where patches cannot be deployed
- the risks of changes impacting the operation or management of the network
- any security updates that are deemed to reduce security or lead to an increased likelihood of compromise
- risk assessments relating to storing of monitoring and/or analysis tools outside of the UK
- any variations from recommended secure builds supplied by suppliers
- risks relating to systemic failure due to software/firmware faults which impact multiple suppliers
- risks relating to large number of equipment bought from suppliers with poor ability to identify/address known flaws
- risks relating to the suppliers ability to continue to support networks and functions provided by them
- the risk of near misses reported in incidents in raising the likelihood of a reported risk
- any deficient risk management activities/controls which will not be remediated
The following are key risk decisions in the event the virtualisation is used, or the provider operates a mobile network (respectively):
- the risk of compromise of a virtual function impacting its host
- the risk of SIM data compromise (for mobile operators)
What are the records?
Of course, it’s not just the governance structures and risk management but also the maintaining of records required to evidence that governance is occurring. Figures 4 and 5 below show all the areas of the code practice that discuss the requirements for records management. Some (marked as records management) are expressly just for maintaining records, whilst others have an element of records management within them.
Examples of the types of records that are required include:
- the risk management process used by the provider
- asset registers owned by the provider
- the type, location, software and hardware information and identifiers of security critical functions of the PECN and PECS
- all externally-facing networks and functions
- the externally-routable addresses used within the provider for its networks and functions
- any user, network or other sensitive data that isn’t protected by encryption, including how it is protected
- assessments relating to the risk of the network and its functions to security compromise, which are required to be recorded at least annually and retained for 3 years
- assessments of the extent to which the PECN is exposed to incoming signals, which are to be maintained for 3 years
- interfaces and addresses of external interfaces which are used to hide internal network addressing
- all abnormal signalling messages that are not blocked, including the justification for this
- all unauthorised SIM OTA messages sent to SIMs of mobile operators
- risk assessments relating security compromises occurring due to the unauthorised activities from staff involved with maintaining the PECN/PECS
- all people who have elevated access to the PECN/PECS (i.e. not just end-users of the service)
- all access to security critical functions for the PECN/PECS, including who obtained access
- risk assessments relating to anomalous activity causing security compromises
- all unsuccessful access to security critical functions for the PECN/PECS
- all unencrypted administrator access, including risk assessments and treatment decisions
- the risk of security compromises in the network and its functions
- all privileged access sessions to networks and functions
- all risk assessments of third party administrators and users from suppliers the provider has a contractual agreement with
- all third party administrator access into the networks and functions of the provider
- any vulnerability that cannot be patched within defined timescales, and a increased risk of compromise is deemed likely due to insufficient mitigations
- risk management plans for equipment that is out of mainline support/end of life
- risk assessments relating to the ability of the suppliers to continue to support networks and functions provided by them
- dependencies on physical assets to support the PECN/PECS
- risks relating to the failure of networks, functions or supporting assets
- recovery scenarios required to maintain the operation of networks, functions or supporting assets
- tests of the scenarios to maintain the operation of networks, functions or supporting assets
- improvements made to response plans for the operation of networks, functions or supporting assets in light of tests
- risk assessments relating to the storing of large amounts of data (over 100,000 records) of customers outside of the UK
- risk assessments relating to storing of monitoring and/or analysis tools outside of the UK
- the approach to monitoring the PECN/PECS, and the justification for that approach
- logs of security critical functions, to be retained for 13 months
Governance matters
The reality is the all of the above is significant piece of work, but it allows you to detail how your activities are appropriate and proportionate to the regulator. In short, the risk management process structure is fairly standard and I would recommend the following structure to get started to assimilate the remainder of the detail:
- determine your assets, including their dependencies and CIA impacts (start somewhere and improve). Include the records within the assets
- start with the risks that require review from regulation 11(b) and ensure that you include them within the risk assessment
- detail the threats that apply to those risks. and the vulnerabilities that could cause the threat to result in causing a CIA impact to the assets
- determine your appetite and which assets fall below your appetite
- use your appetite to focus your priorities on the risks that require management first
- select how you will manage these risks and how you will measure them
When you then find that you are unable to comply with a technical guidance measure, key concept, IGP or specific security measure you then use the risk process you have created to link to these activities to show how you are managing the risks.
I’m increasingly seeing providers failing to recognise the requirements for risk assessment and how basic security activities apply throughout the life of the networks and functions. Whilst the risk process is not detailed within the code of practice, it is important to understand that the governance artefacts are.
It’s equally important to understand the compliance with the code of practice is highlight dependent on the effectiveness of your governance process to show the working behind any decisions you have taken that are not in strict accordance with the technical guidance measures, key concepts, IGPs or specific security measures.
As ever, I am more than happy to discuss further on a DM if you need more information.