Cloud security is often the weakest link in modern 5G networks according to our red team hacking assessments. Telcos have an opportunity now to embrace cloud security best practices and make 5G networks much more hacking resilient.
5G standards have improved on known security and privacy issues found in previous network generations, but also open new hacking frontiers. Specifically, virtualization and other cloud security becomes the next weakest link in modern 5G networks according to our red team hacking assessments, but only if the telco cloud infrastructure is not configured to industry best practices.
5G is the first generation of standard that is designed to be micro-service based and cloud native. Modern 5G telcos leverage cloud technology, specially dockerization, to reach scalability and flexibility. Cloud technologies can also provide a cost advantage, as advocated in Open RAN, where hardware and software are de-coupled. For these reasons, most future 5G networks will include some level of cloudification along with unavoidable cloud-specific security challenges.
The security question in any cloud environment becomes: Can a hacker break out of one container/tenant to compromise other containers/tenants or even compromise the underlying infrastructure?
Our red team assessments on 5G telcos and other cloud-native infrastructures regularly come across configuration settings for Docker containers running on Kubernetes that allow precisely this: Breaking out of a container and taking over the entire Kubernetes cluster.
Figure 1 illustrates the insecure configuration setting we encounter most commonly. Some of these settings look benign but can have significant security impact ranging from data theft to ransomware to taking down critical infrastructures.
Fortunately, mitigating the configuration issues is relatively straightforward, and can even be done automatically for entire Kubernetes clusters. The secure choices are well documented. However, secure configuration settings might break some telco applications that previously existed as virtual machines and were ‘lifted and shifted’ into Docker containers.
Each of these non-cloud-native applications needs to be adapted, for example to use the networking capabilities of a Docker container, which differ from the ‘network bridges’ that virtual machines often use to access the network. Relatively small effort, well invested into hacking resistance of critical infrastructure.
Once configured well, the security configuration for any cloud needs to be monitored continuously to prevent lapses. Telco environments are increasingly complex and dynamic. Therefore, the classical bottom-up security assurance, where each network element is pentested before deployment, does no longer capture a network’s hacking issues. Instead, two new testing strategies are needed for 5G telcos, both well-known from cloud-native industries:
1. Automatic testing in pipeline. Software and configuration are checked with a range of automated tools in their respective development and deployment pipelines. Insecure configurations – including the Docker issues listed above – are blocked from deploying into production.
2. End-to-end hacking assurance. Top-down testing (aka red teaming) on the entire network spots remaining issues and provides feedback on gaps in the automated tests pipeline. Red teaming provides a learning opportunity on security design, configuration, operations, and assurance. Red team exercises typically run for 4-6 weeks, once or twice per year. Illustrative red team results of SRLabs assessments of 5G telcos are shown in Figure 2.
Our digital societies are built on mobile networks. We are now facing an opportunity to make 5G networks the most secure network generation built to date by adopting security strategies from cloud-native industries, including cloud baseline configuration and regular red teaming. As a community we share a responsibility to keep mobile networks hacking resilient.
[1] Additional details on security in 5G, illustrated with Open RAN, in our MCH2022 talk (video, slides).
[2] Further Docker container breakout examples at Bishop Fox Blog.
