Making sure you don’t CoP a packet – Managing third-party admins in the TSA

This is my next (albeit belated) article in my series of eight articles on the Telecoms Security Framework (TSA in common vernacular). If you’ve read “PAM in the TSA – whose definition is it anyway?” you’ll know that managing privileged access isn’t just about technology – it’s about control.

In my previous article, “PAM in the TSA – who’s definition is it anyway?”, we explored how the TSA’s requirements around Privileged Access Management (PAM) are rooted in the classic Zero Trust model of ‘Never trust, always verify’ using Authentication, Authorisation, and Accounting. We looked at access over the management plane, the use of individual accounts, and the application of secure configuration and monitoring.

This follow-on article expands that lens, applying those same principles to the broader issue of how providers manage third party administrators – not just in terms of technical access, but across operational resilience, supplier governance, architectural control, and supply chain assurance.

The regulatory regime from the TSF (Regulation 11(b)) requires that a number of risks are reviewed annually, with three being especially relevant here:

• The risks of unauthorised activities of privileged users of the PECN/PECS causing security compromises (Regulation 10(4)).
• The risks of security compromises occurring as a result of monitoring and analysis tools being stored on equipment located outside of the United Kingdom (Regulation 5(2)).
• The risks of activities of third-party suppliers causing security compromises to the PECN/PECS, either deliberately or accidentally (Regulation 7(1)).

Security compromises of course are defined as being defined in section 105A(2) of the Communications Act 2003 as:

anything that compromises the availability, performance or functionality of networks and services, and anything that causes signals conveyed by means of the network or service to be lost

This means that this includes the availability of the PECN/PECS as well as the confidentiality and integrity of it.

I have shortened the exact wording of those regulations, but this gives you the gist of what you are required to deliver in terms of governance of your third-party administrators (3PA in the terminology of the CoP). The groups of 3PA users are defined in the code as being:

Managed service providers, provider group functions, or external support for third party supplier equipment (e.g. third‑line support function)

This article will review what is required to show that you are managing the 3PA risks, and will build on the previous article (this will focus on the areas specific to the use of 3PAs).

The overview of the activities to be taken specifically taken for 3PAs is shown below in figure 1 and figure 2 (for Tier 1 and Tier 2 providers respectively).

As you can see, there is a lot of requirements to be met and the time to evidence some of them has already passed.

Getting the structure right – governance for 3PAs

We’ve already discussed the management of risks, so let’s delve into the governance required for your 3PAs.

We’ve previously talked about the risks that require reviewing annually, but there are other key areas to consider (where they are relevant to the support and operation of you own PECN/PECS).

You are required to ensure that supplier’s compliance to the obligations for 3PA access is reviewed, including:

• Reviewing data protection controls.
• Assessing the assurance you have in the 3PA systems, considering areas such as Trojan horse threats.
• Undertake security audits and assessments.
• Flowing down your own security standards into the supply chain – where they apply.
• Confirming that security testing is equivalent to that of your own regime, including where TBEST testing is appropriate.

When sharing data with 3PAs, you need to ensure that data required to operate/maintain the PECN/PECS is managed appropriately, so that:

• Data shared with third parties must be authorised, encrypted, and deleted irreversibly once no longer needed.
• You can show you retain full oversight and control of the data which 3PAs can access.
• If the data is offshore, you know where it is held.
• If data is offshore, you should also consider the risks from local data protection laws are considered and managed.

It’s also not just about the security of 3PA access, you also need to ensure that 3PAs are competent to conduct their role and that:

• 3PA personnel persons are competent, resourced, and understand your network.
• They can evaluate advice from you – not just follow it blindly.
• They ensure that secure configurations are applied, tested, and deviations are recorded.

Of course, there is no point using 3PAs unless you can ensure that sufficient in-house resources are available to operate the in-scope services to:

• Oversee infrastructure managed by third parties.
• Maintain visibility over who has access, what they’re doing, and how the system is being run.
• Allow you to move away from the 3PAs if needed (which is covered in the resilience section later on).

It’s crucial that these areas are underpinned, ensuring that formal agreements exist with 3PA suppliers that:

• Require suppliers to identify, disclose and reduce security risks.
• Allow you to monitor all activity conducted by 3PAs our your PECN/PECS.
• Mandate sharing of security failings related to the ability to manage the protection, changes and availability of the 3PA service (including the environment it operates from).
• Define and enforce the mechanisms to allow cooperation during incidents.
• Define and enforce the level of security which the 3PA provides.
• Include break clauses if risks aren’t resolved.
• Allow you to control who can have access to your PECN/PECS.

• Ensure the 3PA prevents any one customer’s network from affecting another.
• Require customer environments – including data and admin access – to be fully separated by the 3PA.
• Require the 3PA to enforce logically-segregated ‘browse-down’ architectures for each customer.
• Keep management systems used by the 3PA to access your network distinct from those used for others.
• Enforce technical boundaries between the 3PA and your PECN/PECS.
• Prohibit shared logins, access tools or devices from the 3PA between customers.

Authorisation – defining what privileged users can do

This section expands directly on the ‘Authorisation’ themes introduced in the previous PAM article.

Previously, we looked at how privileged access must be clearly defined and securely granted – using individual accounts and MFA.

Here, we broaden that into how 3PAs are to be managed specifically – contractually, operationally, and technically.

You must ensure that what privileged users can do is defined and limited to the minimum required by:

• Defining and regularly review privileged access policies.
• Only granting third parties access to the information they need to fulfil their function.
• Avoiding transferring full control of systems or data unless absolutely necessary.
• Defining and implementing process to grant 3PAs access to user and/or network data (you should have already documented what the user and network data is in your first regulatory submission)
• Retaining the right to manage accounts and permissions.
• Keeping the contractual rights to approve which 3PAs can access your PECN/PECS
• Maintaining a list of 3PA staff with access, their roles, and usage frequency.

You should then enforce this by ensuring that technical architectures are used to control privileged access to reduce the potential impact from a compromise of the 3PA on it’s customers, including:

• Enforcing boundary controls between the 3PA network and your network
• Using secure mediation points – not direct equipment access.
• Deploying ‘browse down’ architectures (which will be Privileged Access Workstations (PAWs) at some point, but this is still being worked on) segregated by provider.
• Segregating management planes by supplier and network zone.
• Ensuring monitoring tools cannot be accessed from countries listed in the Schedule or prohibited countries in the regulations.

Accounting – what they did

This section builds on the previous article’s focus on Accounting for audit and visibility.

There, we introduced the need for privileged actions to be tracked and attributed.

Here, we apply that expectation across 3PAs – ensuring you not only record their actions, but can monitor, investigate, and respond.

You are expected to ensure that the activities of privileged users are recorded, by:

• Logging and recording all third party administrator access into your networks.
• Contractually requiring logs from the third party’s environment where access relates to your network.

You are also expected to ensure that the activities of privileged users are monitored, by:

• Ensuring third parties monitor and audit their own staff.

• Ensuring that the activities of privileged users are monitored using skilled analysts to understand and respond to security-related activity (which can be by another third-party who adheres to the rules)

Ensuring resilience – can you operate securely without your 3PAs?

It’s one thing to have reliable 3PAs to help operate your PECN/PECS, but it’s clear that ongoing threats to international links via subsea cables and supply chain attacks can cause real issues, which might require you to operate these activities yourselves. Cyber Risks mentioned within regulation 11(b) are certainly one area of note, but it’s also crucial that the risks to resilience in section 1.3 of the Network and Service Resilience Guidance for Communications Providers are also considered in addition to the areas highlighted from the Code of Practice.

The key point of note from that guidance here is:

Over recent years, it has become increasingly common for communications providers to outsource operation of parts of their networks to third parties, sometimes referred to as managed service providers or managed service partners. <…> In these cases, there is a risk that communications providers relying on third party services lose a degree of control over their network design and oversight, which could impact network or service resilience.

It’s therefore crucial to ensure that sufficient resources are available to operate the in-scope services, by:

• Writing and regularly reviewing exit and transition plans for operating without 3PAs
• Maintaining a record of third party suppliers and critical components
• The ability to bring services back in-house or transfer them to UK control if needed

But there might come a time when connectivity from 3PAs is disrupted for a longer period of time, or goes out of business, so you must ensure that sufficient in-house resources are available to operate the in-scope services.

This is expected to undertake by ensuring that you:

• Can identify risks without reliance on external people, equipment, or data.
• Have the capability to re-tender services or resume control as required.
• Maintain a plan for moving services back in-house or switching suppliers.

So, are you in control of your 3PAs?

How would you answer that question if asked, and could you prove it? The next regulatory return from Ofcom is going to place a sharp lens on this, as you have to show that you are able to implement this now for new contracts and pull it into alignment for existing ones within two years.

This sounds like a long time, but with 19 areas of M10.x being related to the provider and nothing to do with the suppliers it requires careful consideration.

If your answer isn’t a confident yes – and demonstrable through designs, plans, contracts, controls, and logs – now’s the time to fix it.

I’d recommend reading the previous article which touches on the needs of documented access paths to determine where you need to control access.

If you are a 3PA supplier, document your scope and work out how the Code of Practice impacts you.

Do feel free to reach out to us for a free 30 mins chat to discuss the thinking behind this article.