Regardless, some might find it interesting
electrospaces wrote:Here's an interesting and detailed article about #Huawei systems and the risks for the #UK's telecoms networks:
Blog post
Security, complexity and Huawei; protecting the UK's telecoms networks
Created: 20 Feb 2019
Updated: 20 Feb 2019
Author: Ian Levy
Part of: Government strategy, Digital services
UK communications
We all rely on our telecoms services more than we realise. We expect fast connectivity everywhere we go, something that would have looked like magic only 50 years ago. Ubiquitous connectivity has enabled new ways for people to interact, the apps we use every day, and new ways of building systems. However, very few people know how these telecoms services work, or how they’re built. So as we start talking about 5G and the next generation of fixed and mobile connectivity, I thought it’d be useful to explain how UK operators, regulators and government works to protect these critical services.
This blog is supposed to be accessible, but it inevitably contains some scary-sounding terminology. However, as is often the case with cyber security, the concepts behind them are quite straightforward. For example, there's some really clever technologies involved in sending as much data as possible down fibre, one of which is ‘dense wave division multiplex’. This is a techy way of saying that we can use different colours of light for different streams of data down the same fibre. We can guarantee they won’t interfere with each other in the fibre and then we can split them out at the other end using (effectively) a prism like you did in physics lessons at school. So, you can use one physical glass fibre for lots of different data streams, and keep them separate.
Most people should be able to understand most of the concepts involved in this blog, even if not the deep detail. Where the technical details are unavoidable, I'll explain what they mean, so please keep reading. It's also worth remembering that this blog deals almost exclusively with data, because in modern networks, voice is really transported as data.
--
Firstly, it’s worth talking about security. There are no absolutes in cyber security, and there’s no such thing as a 100% secure system. In the end, cyber security is all about risk management, judgement, and trying to make your adversaries’ lives harder.
For telecom services, think of it like this. Nationally, we set a bar at a particular height, and if the adversary can jump over the bar undetected, they get to do what they want - whether that’s 'disrupt a service' or 'snoop on calls'. The NCSC looks for attackers successfully jumping over the bar to help manage risk in the UK. It’s for ministers to set the height of the bar, and then for operators overseen by Ofcom and DCMS (and helped by NCSC) to try to make the networks meet that expectation. We know that the bar isn’t currently met in some places in the UK, and there’s a long-term piece of work already running to try to fix that. You can’t just patch a national telecoms network like you can your home PC; when you’re talking about national scale systems, changes take time.
Architecture and amorphous blobs
It’s also worth laying out how a telecoms network is structured. It's not just a set of amorphous blobs; there’s a lot of architecture behind it, with different layers within it all performing separate (but related) tasks.
The first is the transport layer. This is the physical wires and fibres (and sometimes other technologies like microwave) that move the bits we need between two points. There’s some really clever technology involved here in getting as much data as possible down a particular link. But basically, the job of the transport layer is to push the bits between two fixed points (or nodes) as fast as possible in the most reliable way possible. This layer doesn't know much about the traffic it’s passing, and it certainly doesn’t look at content - it's much too busy pushing the bits around. Transport nodes only care about the directly adjacent nodes that they’re physically connected to.
The next important bit is the routing and switching. This takes the node-to-node links in the transport layer and links them together in an intelligent way. So, you can ask for bits to go from London to Leeds, and this layer will use the transport links in the most efficient way possible at that moment to make that happen. If someone puts a digger through a bundle of fibre, that’s not a problem, because this layer will sort out an alternative route for your data. It knows a bit more about the context of the data it’s passing, and the ways to get around the network. It can look at the content, but generally speaking doesn’t need to.
The access layer is how customers access the network. The access layer is sometimes called the ‘edge’, because it forms the edge of the providers' network where they interface with their customers. The access layer knows something about who’s accessing the network and (by definition) has access to the data that’s sent to (and from) the customer that’s connected to it.
Fixed and mobile access
When domestic broadband users, businesses and data centres connect to the internet, it's known as fixed access. Think of this as the kit between your local telephone exchange and your home router. There are obviously many different types of fixed access, but they all work in broadly the same way:
package up bits from the customer in a well-understood way
tag them with some service information
shove them into the network for processing
Fixed access networks are pretty simple - relatively speaking - as each customer has their own physical link with known characteristics. For example, the copper wires that go into people’s homes can get about 40Mbps speed. You know roughly when that link is likely to be used, and roughly how busy it’ll be at different times, and exactly where it is so you can plan capacity.
For mobile, it’s much more complicated. Mobile access has to cope with many more devices per geographic area, doing very different things. The physics that allows millions of people, all moving around (and all trying to share the same bit of radio spectrum) is really complex. People demand higher and higher data rates which pushes the envelope of both the physics and the technology. In terms of infrastructure, this consists of the radio antennae, the base stations (which work out what to transmit and receive) and the things that control them. Mobile access infrastructure knows quite a bit extra about users of the network (where they are and what device they’re using, for example).
Services and management
Once you’re in the network, something needs to decide where your bits are going to go, what services you’re going to get, work out who you are, and ensure you’re billed properly. Generically, that’s called the core, although the actual things in the core are very different between different mobile systems, and between mobile and fixed.
Then you’ve got the things that users really care about: the services. These could be as simple as your voice service or text messages, or as complex as using a catch-up service to watch your favourite sports channel on your mobile whilst on the train. There’s also a bunch of services that help keep the network running and provide other functions that users hardly ever see, but are really important.
Sitting on top of all this is something called the management plane. This is the stuff that the operator uses to make sure all this works together as intended, alerts them to faults, and allows them to manage and optimise their network. These networks are incredibly complicated and subject to random events such as JCBs digging through fibre ducts, fires in exchanges, and people nicking copper wire out of the ground. Oh, and cyber attacks. So these networks need daily loving care to make sure they’re working at their best, and so problems can be found and fixed quickly.
Running resilient networks
Obviously, it’s going to be important how you build and run all this stuff. There are three big sets of things we care about.
The first is vendor selection, or who makes the equipment you use to build your network. Equipment – regardless of who makes it – will always have vulnerabilities because hardware and software are complex systems built by people, and people make mistakes. So, it’s a sensible design principle to:
Assume that every box in your network will fail in the worst possible way.
Design the system so that it’s not the end of the whole network when it does.
Of course, you still want to have defence in depth, so you should prefer vendors who have a track record of minimising:
the vulnerabilities they have through a secure development life-cycle
the impact of any vulnerabilities that remain through good product design
the harm caused through a predictable and well-practised patching process
That brings us onto architecture, or how you connect these different things together to build a functional telecoms network. You can have the most secure boxes in the world, but if your management plane is connected to the internet, you’re still stuffed.
If you design your network to be completely flat so that a compromise anywhere gets the attacker full access to everything, you’re stuffed. So, we try to design networks so that a single failure (be that accidental or deliberate exploitation of a vulnerability) isn’t the end of the whole system. One of the other ways we try to manage systemic risk is by trying to have multiple vendors in each bit of the network, so that a vendor-specific vulnerability doesn’t easily propagate across the whole network. It’s not always possible for all cases, but it’s a good principle to aspire to.
Finally, how you run the network really matters.
If your passwords are all system defaults, it doesn’t matter whose kit you use, you’re stuffed.
If you don’t monitor the system for changes, you’re stuffed.
If you don’t manage privilege properly, you’re stuffed.
If you allow a third party to run your network and have no in-house capability to audit what they’re doing, you’re stuffed.
Large scale telecoms networks need to be actively managed and monitored by competent people. Different operators have different approaches to security, but they’re all expected to meet some standards set by Ofcom. There’s actually very little incentive for operators to do more security than is strictly necessary. For example, have you ever considered the security of the provider when you buy broadband? Would you ever think ‘Hmmm, I’ll pay an extra fiver a month because that provider’s MPLS network has well secured P-nodes' ? No, didn’t think so. To be fair, neither do I.
Last year, the NCSC publicly attributed some attacks on UK networks, including telecoms networks, to Russia. As far as we know, those networks didn’t have any Russian kit in them, anywhere. The techniques the Russians used to target those networks were looking for weaknesses in how they were architected and run. This shows why the bar for security needs to be raised on our networks to make them more resilient, regardless of whose equipment is used in the network.
5G networks and security challenges
As you’ll probably have heard, there’s a new technology for mobiles coming soon, called 5G. In the future, 5G networks will enable lots of new and interesting use cases because of four characteristics:
It can push more data over the airwaves to terminals (so mobile phones, tablets and driverless cars).
It can support many more terminals in any given area.
It can support very low latency communications.
You can ‘slice’ a 5G network into chunks that don’t interact with each other.
Together, these characteristics enable a whole host of new uses like smart cities, autonomous vehicles, telemedicine, and other things we’ve not even thought of yet. But it’s not fundamentally different to existing technology, and it’s certainly not some sort of magic that undermines all the cyber security knowledge and techniques we have at our disposal. 5G networks are still divided up into roughly the same chunks as described previously, but there are some differences. For a start, they use more modern architecture, based on more commodity technology. The most obvious change is the radio protocols which push bits over the air much more efficiently to enable higher speeds.
One thing that does change, is the scale of the mobile access layer. Current mobile systems are broadly based around a relatively small number of macrocells which each cover a relatively big area of the country; anything up to a few tens of miles in rural areas, but obviously much smaller in densely populated areas. To cover mainland UK, you need about 25,000 cell sites today. Now, as you increase the data rates, you need to push more power into the radio signal and you need a *lot* of power to increase data rates over those distances because of the inverse square law. Also, each operator has a specific set of frequencies that they’ve bought from Ofcom, and so each cell can serve a limited number of devices because it has to divide those frequencies into chunks for each device to use.
So, 5G uses many, many more cells, each with a much smaller coverage radius. These small cells end up in weird places, like on the top of lampposts, in buildings and even in some home set top boxes. So, we can’t assume that all base stations are physically secure. That’s a change, but we've been going down this route for a while (with things like in-building 4G coverage using small cells), so it's not completely new.
Then there’s the core. The biggest change here is that it moves from being big, shiny, proprietary boxes to being software called Virtual Network Functions (VNFs), running in virtualised infrastructure, called the Network Function Virtualisation Infrastructure (NFVI). The NFVI is managed by the Management and Network Orchestration function (MANO). The NFVI and MANO, together with some supporting stuff, is often called the virtualisation layer. That's a lot of jargon, so think of it as moving from old mainframes to running stuff in the cloud.
It’s important to note that the ‘cloudy infrastructure’ here is physically in the operator’s network, and is controlled by them. We’re not into running national networks in public cloud quite yet, and it’s certainly not true that your 5G equipment vendor runs your virtual core in their data centre. A positive here is that the cyber security community knows a lot about how to secure virtualised platforms, and how to provide good separation of things running in there. Also, there are lots of tools available for this commodity technology. The flipside of this, is that there are many capable security researchers who know about these technologies. So, we're likely to see skilled researchers probing systems because they have much more experience with this sort of technology. Operators are going to have to train in this new area, and be ever more vigilant in their running of the networks.
The other difference with 5G concerns architecture. Today, architecture is defined by where you physically plug wires in. In a virtualised core, it’s the configuration on the vSwitch (think of it as virtual wiring) in the virtualisation layer that defines architecture. So, if you’re using architecture to contain impact from risky vendors, it follows logically that none of those vendors can supply your virtualisation layer or the thing that orchestrates it while running. We're looking at controls around the supply of the NFVI and MANO in the supply chain review. In other words, with 5G, some equipment needs to be more trustworthy than ever, but probably not all.
With 5G, the interfaces between the core and other parts of the network are different. It becomes a modern, service-based architecture which provides both opportunities and challenges for security. Again, the community knows a lot about how to secure a service-based architecture because that’s how many of the modern internet services are built. There’s also the possibility of having ‘one core to rule them all’, converging your fixed and wireless cores into a single set of services. Done well, that could be really positive for security.
Close to the edge
Earlier I mentioned very low latency communications, which is critical to some of the more advanced use cases that 5G makes possible. The system latencies that we’re talking about put some very tight constraints on the time it takes to communicate between individual bits of the system - in the order of a couple of microseconds. At this level, the speed of light matters and starts to limit the physical distance between key bits of kit. That means that geography starts to have an effect on where you put various bits of stuff. You need to move some of the core services closer to the edge, so those messages can get around quickly enough.
Of course, when you push core services closer to the edge, you can also push out the security services that support and protect them. This is the ‘mobile edge compute’ part of 5G. Now, in theory, you could push those services to the very edge of the network (that is, to each individual base station). That would be utterly crazy though, since it would be a massive pain to run the network, you couldn’t secure it properly and - more importantly - there’s no use case currently anticipated that would require it. In the UK, we currently reckon that we’ll push core services out maybe as far as large metropolitan areas. Securing those should be broadly the same as the way we secure things today, you just have to do it more often. So, again, 5G changes things in interesting ways from the way we do things today, but not in a way that fundamentally breaks all our current security principles and paradigms.
It’s also worth talking about the different ways to build a 5G network. There’s two deployment models; standalone (SA) and non-standalone (NSA - a poor choice of acronym). An SA deployment is as it sounds; it’s a separate network that may share transport and routing and switching with the existing networks, but you’re effectively doing a green field deployment. The NSA deployment model means you piggy-back the 5G stack on top of your existing 4G stack. Despite the standards existing for interoperability, it’s much easier to stick with your 4G vendor for your initial 5G roll-out for NSA deployments. This somewhat constrains deployments in the UK, so we’re working in the supply chain review to understand what the long-term network split looks like. What happens over the next year or two is important to this long-term architecture, but taking some short-term pain to get the long-term architecture right for the country may be necessary.
No-one currently buys telecoms services based on how secure they are
The final thing to think about is the various market dynamics involved. All the UK operators are commercial companies that exist to provide a service and make money. So, they’re going to prefer cheaper kit if it helps them provide the service they need (absent of any other considerations). No-one currently buys telecoms services based on how secure they are, so a company wouldn’t get rewarded if they invested more than their competitors in making a more secure service. That leads to a weird situation where you don’t get rewarded for doing the right thing, which makes it hard to do, long term.
The government's supply chain review, led by DCMS, intends to really understand the market to make sure we have better cyber security in the equipment and software used, and can continue to have a diverse and vibrant vendor base in telecoms equipment supply. It's also looking at how we could set objective security characteristics for UK telecoms operators, and ensure a higher priority is placed on security in decision making processes. There’s a lot to do here to make sure we get the security we need in the future networks, as we begin to rely on them more and more.
The laws of physics still apply to attackers
Now let me take you from the future of communications back to 2003.
In 2003, most people connected to the internet by letting a modem squeal down their home phone line, getting (if they were lucky) about 56kbps, which is roughly 1/150th of an average broadband connection speed today. The really lucky couple of million could get ‘basic broadband’ (which gave them 128kbps), and fewer still could get ‘high speed broadband' (256kbps). And you paid £23 a month, on average, for basic broadband.
It was around this time that BT started planning for the biggest ever network upgrade in history (21st Century Network) to set the foundations for the services we enjoy today. They were consulting with government and happened to mention they wanted to use a Chinese company called Huawei as part of the build out. We already had a definition of 'risky vendors' (not just based on country), and a framework in which to manage them. Cabinet Office coordinated a cross Whitehall response to look at the options available, which ranged from do nothing, through to mitigating the risk, to a full ban. In the end, the decision was taken to mitigate the risk.
In mitigating, we were talking about harmonising risk, regardless of vendor. Remember the metaphorical bar we talked about earlier? Well, the idea is to try to make the bar broadly the same height for the Chinese state, irrespective of whether we use Huawei kit in the UK. And yes, we assumed in the decision process that the Chinese state:
could compel anyone in China to do anything (which they’ve now codified in their National Intelligence Law)
would carry out cyber attacks against the UK at some point (which we’ve recently publicly confirmed)
Remember, no attackers are omnipotent and omniscient; the laws of physics still apply to them. The mitigation formed a set of principles that BT still follow to this day, although they’ve evolved a bit as technology matures. They include things like:
every chunk of the network should have multiple vendors, noting there'll be exceptions due to practicalities
keep more risky vendors out of sensitive functions (like some of those in the core and anything to do with lawful intercept)
architect the networks to be tolerant to exploitation of any device (regardless of vendor)
have enhanced monitoring
no use of the equipment in sensitive networks
BT and CESG (one of NCSC’s precursors) also had a joint team to research the equipment from risky vendors, which would feed back into the risk management carried out by BT on their network.
This was going fine until about 2008, when other operators wanted to use Huawei. It made no sense to try to get every operator to replicate the work BT had done, so we came up with a different model, which expanded the principles a little and required the establishment of the Huawei Cyber Security Evaluation Centre (HCSEC). HCSEC is a common security team created to analyse and give information to operators to help them do their risk management well when using Huawei kit.
The way we engage with a vendor is based on risk and potential impact, so there are obviously differences. We don’t have an equivalent of HCSEC for any other vendor, but we do have relationships with all the major ones, and understand their kit in a similar way. Negotiation with Huawei happened and then the whole thing was launched in 2010, including the opening of HCSEC. In 2012, the Intelligence and Security Committee (ISC) was worried about the arrangements and asked the National Security Adviser (NSA) to look into them. He published his review in late 2013 and recommended some enhanced oversight. We then created the Huawei Oversight Board in early 2014, chaired by NCSC CEO Ciaran Martin, which has to report each year to the NSA, the ISC, parliament and the public.
That model has worked pretty well for the past 8 years. It’s not perfect; not every operator that uses Huawei kit follows the principles or uses HCSEC to get information, but most of the big ones do. Last year’s Oversight Board report raised some serious concerns about Huawei’s software engineering and cyber security capabilities. This year’s report will expand on that but, because of this mitigation model, the UK operators that use HCSEC have unparalleled information to help them manage the risk of using Huawei kit. However, this long-term risk management of Huawei’s poor security and engineering takes sustained effort over the life of the system, and is only possible if supported by strong architecture and operational management. Management of the national security risks takes sustained effort as well.
How Huawei (and other vendors) are used in the UK’s 5G build out will be determined by the government's telecoms supply chain review, which is gathering evidence at the moment and will report to ministers in spring. That review is the only policy vehicle for making decisions on how future telecoms networks in the UK will be built and run, in line with strong security principles.
The devil really is in the detail
The idea behind publishing this blog is to help people understand the steps we take to protect telecoms networks in the UK, even though there’s a lot of complexity and subtlety in telecoms network security. That’s true of any technology, but especially true in the 5G networks we’re just starting to build, as potential impacts of something going wrong in 5G warrant more attention. These new networks will evolve over time as the standards mature and the new uses come online, but there are some principles we can see are already necessary.
An approach that ignores the detail of how these networks actually function won't work. The details are very important and security implications of certain decisions will be different across different countries, and even different networks in the same country. One thing is for sure, though. If 5G is going to be the engine of growth and change for the UK economy that people expect, we need our implementations to be secure enough to enable that. That will need many things, not least a diverse and sustainable supply base, better cyber security in the equipment and software used, and uplifting the basic security of the networks we have today as they evolve to support a safe, digital future.
Ian Levy
Technical Director, NCSC
Topics
Government strategy
Digital services
2 comments
Kay Walsh - 25 Feb 2019
This was an excellent blog, written so well that someone at my non-technical level could understand. It also gave me a good feeling that someone has my back.
reply
Michael Bowyer - 06 Mar 2019
Ian this is a seriously thought provoking article and I don't disagree with many of the points you raised. Perhaps it's time certainly for certain deployed infrastructure we looked again at how the end to end system is assured. I for one would support that and would be happy to contribute.
Its good to se this level of debate from NCSC and you have engaged my interest.
reply
If nothing else, you'll at least now know why your phone bill is so high in the future.
