5G core security, tested before subscribers moved
A modern 5G network runs much of its core as software on cloud platforms. That brings familiar cloud risks into the heart of a telecom network, where subscriber data and service availability are at stake. This carrier wanted its new core tested before any customer moved onto it, and service could not be interrupted.
Background
The carrier was launching 5G standalone (SA), a 5G network with its own dedicated 5G core rather than one that leans on 4G equipment. Its network functions ran as containers on Kubernetes. These are known as cloud-native network functions (CNFs).
The main concern was container escape. That is when an attacker breaks out of one network function onto the host server underneath, and from there reaches subscriber data.
How we tested
We scoped external, internal and cloud testing specifically around the carrier’s CNFs. Our testers searched by hand for container escape routes and misconfigurations. They found a service account with far more privileges than it needed, which made an escape possible.
We also checked configurations against the relevant CIS benchmarks and reviewed network segmentation, the separation between parts of the network. All of this took place in the staging environment, so live service was never at risk.
Afterwards
The carrier closed the escape path, and our retest confirmed the fix. The rollout went ahead as planned. The carrier now has a hardening baseline for the next CNF version, and it runs continuous testing on each CNF release through FOCTOS, a Snipeyes company.
A note for telecom leaders
Cloud-native cores need testers who understand both containers and telecom network functions. Testing in a staging environment lets them explore findings in depth without asking for a maintenance window.