The future of telecoms in the UK

Telecoms networks have evolved in an organic way over the last 20 years. 5G is just another evolution of that set of technologies, although sometimes it’s been imbued with mystical qualities that seem, at least to me, to defy the laws of physics and common sense. There are lots of statements made about 5G implementations that make it sound scary. I want to highlight three here:

Claim 1. 5G swaps hardware for software

This is implausible. A basestation is a computer with an aerial. Just as your laptop hardware can’t do anything without software, neither can the basestation hardware. A 4G basestation contains huge amounts of software where the source code can be anything from 20 million to over 200 million lines of code. Sure, it runs on specialised, vendor-specific hardware that can’t do much else and has some very specific flashy lights, but by any measure, that’s a big chunk of software. And that’s still true in 5G.

It’s probable that the hardware will become commoditised – much more like your laptop at home – but the fact is it’s still the software running on an execution engine of some sort (microprocessor like your laptop, or a Digital Signal Processor and so on) that does the hard work.

The move to commodity hardware and virtualisation does, though, change the deployment and servicing models for the software. But even in the most extreme circumstances, no operator in the UK will update or patch their software like you patch your home devices or an enterprise network. Software updates in any national scale network bring risks and those risks have to be managed properly.

Claim 2. There’s no distinction between core and edge in 5G

This is covered in the previous blog, so I’m not going to delve into huge detail here, but it remains untrue. In previous networks, sensitive functions were grouped together in a couple of locations we called 'core'. In 5G they are spread out a bit more, but sensitive functions are still sensitive functions and you can put your arms round them - for example, we list them in the guidance published today. Remember, in 5G you need lots of smaller basestations as well as big ones, and the small ones will be on lampposts, bus shelters and other places that aren’t secure from physical interference by bad guys.

So, if your network design means that you need to run really sensitive functions processing really sensitive data (i.e. core functions) on an edge access device on top of a bus stop, your choice of vendor is the least of your worries and you probably shouldn’t be designing critical national infrastructure. The international standards that define what a 5G network actually allowed you to do all sorts of things, and some of those things could lead to security or operational risks that can’t be mitigated. That doesn’t mean you have to do them.

Claim 3. In a ‘mature’ 5G network, mobile edge compute (MEC) will be right at the edge and then your high risk vendor strategy fails

This could be correct, but isn’t in the UK. We’ve said that we believe that MEC on UK networks won’t need to be pushed right out to the edge, and we can manage it all sensibly for all practical applications. But what if we’re wrong? In the end it is a commercial decision where to put your MEC so there may be some super cool application that we’ve not thought of that needs MEC actually running in particular edge access sites. Well, that’s OK. The MEC is virtualisation and we’ve said the virtualisation can’t be provided by a high risk vendor, both back in February 2019 and in the guidance today. So, whether we’re right or wrong on how far MEC goes towards the edge over time, the UK networks stay equivalently safe.

The technical summary we’re publishing explains a bit more about how we’ve approached the security analysis and what sorts of things we should be doing to mitigate security problems. The thing to take away is that the NCSC really does understand how these networks will work, the limits of how they can evolve and what we need to do to protect them properly. We have also worked for years with many of the major vendors of telecoms kit in the UK, so really understand the state of security in the market.

One of the biggest problems we have is one alluded to in the previous blog; telecoms security doesn’t pay. That’s true of the basic network security and business processes that support it. But it’s also true of the enhanced mitigations we ask operators to – voluntarily – do when using a high risk vendor such as Huawei.

In the last couple of years, the operators’ commercial drivers have come into direct conflict with the NCSC’s security advice. Those operators who chose to follow our advice and requests were putting themselves at a commercial disadvantage. That’s unsustainable. So, the government decision to significantly uplift the baseline telecoms security and formalise the handling of high risk vendors putting it all on a robust footing is very welcome. It provides clarity for operators and transparency about what we expect for the security of our national networks. Externalising the security costs of particular choices (including vendor) will help operators make better security risk management decisions.

Everyone accepts that society is increasingly dependent on telecoms and, if we’re honest, the level of security in our networks needs to be improved as our reliance on these networks increases. For this to happen, operators need to know what’s expected in terms of security so that Ofcom, the regulator, can assess how well they're doing. This is where the Telecoms Security Requirements (TSR), announced in July 2019, come in; once new legislation is in place they will provide Ofcom with something tangible to check the operators against.

Security isn’t like a light switch; it's not something you can simply switch on or off. You need to know what you care about the most and who you’re defending it against to judge how much effort to put into your various security controls, more like a dimmer switch you can dial up and down in different areas. Normally, that’s done using a threat model. The threat model for UK telecoms operators ranges from hostile states (for example, the attack by the Russian state-sponsored cyber actors targeting network infrastructure devices) through to organised crime and petty fraudsters. In order to know what you need to defend, you need to know how the networks can be attacked. A good way of codifying that is an ‘attack tree’, also known as a ‘threat tree’.

An attack tree is not that complex, at least in concept. You have a goal at the root of the tree and then each path to the leaves of the tree is a route to attain that goal. A simplified example is shown below:

^{(For those who are interested, social engineering with a $5 wrench is explained here.)}

As part of the DCMS review, NCSC led the security strand and we’ve done this by creating a set of attack trees for telecoms networks. We think all the attacks come down to one of four classes of attack namely:

• Espionage - stealing or corrupting data in the network
• Disruption - stopping service on part or all of a network
• Pre-positioning - quietly getting a foothold in the network administrative systems to use later
• National dependence - being dependent on a third party for some critical part of the design, procurement, operation, support or incident management of UK’s networks.

We’ve worked out the ways we can conceive that an attack could proceed and that lets us generate a set of attack vectors (a vector is the method an attacker uses to do bad stuff). Then, for each vector, we look at:
 

• where it could happen on a network
• how it could be mitigated (protected against)
• how you’d make sure the mitigation was working.

We ended up with about 140 different attack vectors and they’re not all equal. So we also need to score these attack vectors, in order to treat the highest priority issues first. Here’s a real example of this, but with a reduced set of principles and controls (in reality these would be pages long).

So, for each attack vector, we end up with a description of the risk, a set of principles to guide our defences, a list of expected controls, a ‘default’ implementation to guide the operator, and what we expect in terms of constant monitoring of those security controls. This is a fundamentally new way of approaching telecoms security, and we believe it will lead to much more robust security across the sector. This is the framing of the TSRs – principles, requirements and tests for the most important things we need operators to do to protect their network, regardless of vendors used.

What’s interesting about this approach is that, as a side benefit, our risks and mitigations are not determined by the concepts of ‘core’ and ‘edge’; these have always been convenient labels to hide complexity. Instead, through properly identifying the attack vectors, we can work out the sensitivity (in terms of impact on availability of the network, for example) of specific functions and assets and apply appropriate controls and mitigations. Again, details really matter here, but what we end up with is a set of baseline security requirements and a way of making sure they’re implemented properly that will make operators much more secure than today, regardless of the vendors they choose.

The analysis tells us the areas of highest risk are:

• Management plane
• Signalling plane
• Virtualisation plane
• Supply chain
• National capability to operate networks

The TSRs give detailed advice and guidance as to how best to mitigate these risks in the UK’s national context. We know the TSRs don’t cover everything today, but they do cover the highest risk issues. We expect the TSRs to be a living document with periodic updates as the threat, the market and the technology change.

The other thing that is being introduced is a testing regime, TBEST, run by the regulator Ofcom. The idea is that trusted penetration testers will regularly attack the live networks like a real attacker but in a controlled way, so we don’t accidentally break anything. Testing security controls is important and, while we expect operators to be testing themselves, independent testing is more likely to expose deficiencies or errors. The results of these tests will give operators information to help them better secure their networks.

GCHQ has been dealing with Huawei in the UK telecoms sector since 2003, first through CESG and now through the NCSC. We’ve always treated them as a ‘high risk vendor’ and have worked to limit their use in the UK and put extra mitigations around their equipment and services. We’ve never ‘trusted’ Huawei and the artefacts you can see (like the Huawei Cyber Security Evaluation Centre (HCSEC) and the oversight board reports) exist because we treat them differently to other vendors.

We ask operators to use Huawei in a limited way so we can collectively manage the risk and NCSC put in place a wider mitigation strategy, of which HCSEC is the most visible part. Even before HCSEC was set up in 2010, we were doing similar work but through a different mechanism. Technology has obviously evolved since that time and our security mitigation strategy, both generally and vendor specific, has had to evolve with it. The move to 5G is another evolution of the technology and our security mitigations need to evolve again.

The government’s decision today talks about high risk vendors (HRVs). The NCSC considers Huawei to be a high risk vendor, but not the only one. The HRV framework explains, broadly speaking, how we determine whether a vendor is high risk. This includes things like how the vendor builds its products, the location and legal regime in which they operate (and for Huawei the Chinese intelligence law comes into play here) and certain characteristics of their market activity.

It is worth noting that this is about managing risk. Nothing we do can entirely remove risk in any telecoms network with any vendor and so our intent is to get the risk down to an acceptable level in all the different networks using all the different vendors. Basically, with a set of controls and other measures, can we reduce the risk of using an HRV to broadly the same as a ‘lower-risk’ vendor? The restrictions and controls we detail in the high risk vendors framework give us a way of minimising the risk of using a high risk vendor like Huawei.

If we determine a vendor to be high risk vendor, a number of things become necessary:

• Firstly, we ban them from being used in any of the sensitive functions that we need a network to have – things we’ve previously labelled as ‘core’, but it also includes other sensitive things like the legal intercept system and so on. We also continue to restrict their use in other critical infrastructure sectors, safety related and safety critical system and sensitive government, military and intelligence systems.
• Secondly, we put a cap on the amount of the access network a high risk vendor can provide equipment for. The cap balances two different security and resiliency risks; the first is the risk associated with high risk vendors and the second is the need for diversity of supply. The cap at 35% ensures the UK will not become nationally dependent on a high risk vendor while retaining competition in the market and allowing operators to continue to use two Radio Access Network (RAN) vendors. The calculation of 35% is also interesting. We’ve been quite subtle about how we calculate that – it’s important to make sure it can’t be easily gamed, for example by using an HRV’s basestations in all the cities and a non-HRV’s products in the countryside.
• That starts to constrain any high risk vendor, but we also need to put in place a bespoke mitigation strategy for each high risk vendor. That requires things that only an agency like NCSC can do. For Huawei, this will be an evolution of the existing mitigation strategy, including but not limited to HCSEC (‘the cell’) which does things for us.
• Finally, we also need to make sure that those operators who choose to use high risk vendors like Huawei understand the risks properly and design their networks, support and operational systems and processes to manage those risks. That means we’ll have to help them. NCSC has a mandate from government as the UK’s national technical authority for cyber security, responsibility for the long-standing Huawei mitigation strategy, knowledge of other vendor practices, access to national intelligence machinery, a world class vulnerability research team, international partnerships and the data, skills and capabilities to inform how the risks can be sensibly managed.

The approach we’ve come up with for the UK is specific to the UK context. Others shouldn’t assume they’re getting the same level of protection for modern networks if they do similar things without performing their own analysis.

Firstly, our model to manage HRVs requires a really robust regulatory system and something like our TSRs which together give a platform which raises security standards generally and allows for enhanced HRV risk management.

You need to have engaged and expert government and regulatory oversight of how the operators are building and running their network. In the UK, that’s DCMS, NCSC and Ofcom.

You need an end-to-end mitigation strategy for your HRV including something like HCSEC that generates independent engineering and security artefacts. Remember HCSEC is not a ‘transparency centre’; it does much more than that and, in general, transparency centres don’t really help with HRV mitigation. For example, if you don’t trust the vendor, why would you believe the code they show you in the transparency centre is the code you’re running??

HCSEC is also directed by NCSC, so you need an expert government oversight function for the HRV mitigation as well.

And it’s continuous, long term work. Although it’d be better than nothing, we don’t get to say ‘no core, 35% access, home in time for tea!’. There’s lots of ongoing work to make sure our networks stay safe and that's one of the reasons the UK model isn't easily replicated.

The underlying problem in all this is that the market is broken.

Already, we ask all mobile operators to use two vendors in their Radio Access Network (RAN) for resiliency reasons. There are only three scale suppliers of 5G RAN kit that can currently be used in the UK: Nokia, Ericsson and Huawei. That’s crazy, so we need to diversify the market significantly in the UK so that we have a more robust supply base to enable the long term security of the UK networks and to ensure we do not end up nationally dependent on any vendor.

Being nationally dependent on any vendor would be bad, but it would be particularly bad when that’s a high risk vendor. We’re not nationally dependent on anyone now and the measures the government has announced today ensure that won’t happen in the UK in the future, regardless of the commercial drivers.

The reasons the supply market has consolidated so much include:

• Low margins – it’s hard to make a lot of money selling telecoms kit, because it’s hard for operators to make a lot of money.
• High R&D requirements – telecoms infrastructure is extremely complex and bespoke. A significant investment in Research & Development is required to both enter the market and keep up with the pace of development.
• Patents – telecoms technology is built on standards where companies contributing have patented key technologies. There’s a significant cost on new entrants to the market to pay for licences for these key technologies (called Standard Essential Patents).
• Spectrum & regional requirements – frequency usage and preferred radio technology vary around the world. This means that vendors often have to have slightly different products for different markets, which further adds to expense.
• Operator confidence – Operators are cautious by nature, given their business is built upon minimising outage. As a result, vendors have to prove they can be reliable, which puts new entrants to the market at a significant disadvantage. This also means you need a local engineering force, support structures and logistics for spares which can make it hard for existing vendors to enter a new regional market.
• Interoperability – while equipment is built on standards, there are often gaps or inconsistencies which mean that equipment will not talk to each other ‘out of the box’, giving the incumbent vendor a stranglehold. There’s no incentive for vendors to interoperate with smaller vendors as it would make competition better.
• A one-stop shop – creating a telecoms network requires building equipment, integrating equipment and operating the equipment. There’s a division of effort between operator and vendor and, when something goes wrong, it’s easier for the operator to have one person to shout at.
• Scale of delivery – Finally, selling to a major operator requires the vendor to be able to deliver a very large quantity of equipment in a short timeframe to meet the operator’s expectations for network rollout. Any business could grow to accommodate these demands, but such growth takes time.

The need for diversification was announced in the July SCR report. Our plan for doing so tries to address each of the underlying issues through supporting, coordinating or sometimes leading the following types of action:

• Industry-led action. For example, the Telecom Infra Project has groups to help build interoperability (vRAN Fronthaul/F1 interface), cut some of the high R&D costs (OpenCellular and OpenRAN) and remove some of the operator costs for custom hardware (OpenRAN).
• Combined action. For example, fix the weird situations where a vendor operates brilliantly in one geography and really can’t be used in another.
• Government-led action. For example, the UK national telecoms lab we intend to build with DCMS will help de-risk new entrants to the market by providing a standard test bed, allow us to test and force better interoperability between vendors and ensure security is getting better. We’re looking at interesting hybrid models with established public cloud providers with good security records to see if they can provide some of the mobile edge compute infrastructure. Work around spectrum and intellectual property will need an international approach.

Some of this work has been going on for a while in the UK; some will need new effort. Now, we need concerted efforts from governments and industry around the world to ensure we never end up in this position again.

We will all increasingly rely on our telecoms networks for our daily lives in ways we can’t yet imagine, so they deserve the highest practical levels of security. ‘Practical’ is important here. The operators are all commercial entities and so government has to be realistic about what we ask for, and users of the networks need to be realistic about what the networks can and can’t do.

We believe the totality of the measures announced today will ensure the UK’s telecoms networks are appropriately secure into the future regardless of the vendors used. While every country will have its own definition of a high risk vendor, we need to make sure that the UK does not have to rely on a high risk vendor and certainly that we don’t become nationally dependent. That needs a plan to diversify the market along with actions to improve product security across all vendors, improve operator security and create a framework to manage vendors of different risk profiles over the coming years.

That’s what the DCMS review has delivered for the UK.