By Henrik Oberg, VMware Telco Cloud Specialist, and Steve Hoenisch, VMware Technical Marketing Manager
The evolution of security threats is outpacing the transformation of telecom networks. Given the current state of telecom networks and their shift to 5G architectures, the rapid emergence of new security threats and attack vectors demands new principles and new approaches to protect telecom network security.
Part of the problem lies not in the changing security landscape but in the evolution of telecommunications networks themselves. Initially, 1G and 2G wireless cellular networks were considered additional networks that didn’t require the same security measures as fixed-line PSTN networks. As the importance of the wireless networks grew and 3G became the standard, the importance of security requirements ballooned. With the first generations of mobile networks before 3G, the number of connections was growing quickly, and poor security meant that phone calls and their mobile networks could be easily compromised. With 3G, however, telecom standards organizations began to mandate better security.
But the security requirements of PSTN networks were largely superimposed on 3G networks, despite their differences. 3G networks carried similar requirements to PSTN networks, and similar security measures were implemented.
3GPP standards for security have evolved, and with 4G and then 5G the standards improved security for existing attack vectors on the signaling plane between services, for example, but many of these measures are optional and open to interpretation in a multi-vendor environment. In addition, 3GPP standards are only applicable on the 3GPP level and do not consider the underlying new cloud architecture being implemented for 5G solutions. Some of the critical use cases for 5G being promoted, such as low-latency communications for autonomous vehicles and super-low-latency health care applications, elevate 5G networks to national security infrastructure.
Publish and Perish
Hackers were, of course, considered the main threat. To defend against them, most operators implemented an early 21st-century approach. It entailed building security controls to fulfill security requirements for every component, both hardware and software, and then using third party automated testing tools to test the implementation.
Such an approach, however, brings with it a problem that plagues telco network security to this day: The security system is only reactive to known threats. As new threats and exploits emerge, they render the security requirements of the underlying compliance regulations obsolete. For many security standards and published guidelines from government bodies and industry-agency partnerships, the end result can all too often be summarized as publish and perish.
The Co-evolution of Security Requirements and Network Hackers
As soon as a set of security requirements, certifications, or compliance guidelines are published, organizations begin implementing security measures to meet them and the tests to prove it. When the guidelines are published, however, hackers start looking for gaps they can exploit. Since the testing tools that are often used to validate a security implementation will not unearth holes or attack vectors that are not in the implementation of the guidelines, fulfilling the guidelines does not mean that a platform or network is in fact secure. Hackers, unfortunately, find a way to infiltrate the networks and systems built with these published guidelines.
There are several related problems that stem from this kind of regulation-driven approach to cybersecurity:
- As the main threat moves from hackers to organized groups of hackers protected by nation states, the less effective a regulation-driven security model becomes. Organized hackers have the time and resources to mount long-term, coordinated attacks at various levels.
- Some regulations do not adequately single out security-sensitive parts of a network, nor do such regulations typically limit the blast radius if a system or network element is compromised.
- A regulation-driven approach does not identify how configuration errors should be avoided. Manual configuration errors are always a possibility, and they have been at the core of some highly publicized recent attacks. What’s more, there can be a divergence between automated testing and human misconfiguration and error. Many organizations should strive to automate as much configuration as possible to help eliminate us error-prone humans from the equation. Still, there will always be a balance here because it is, after all, us humans who build the automation.
Shifting the Focus from Requirements to Principles
A modern security approach should ensure that security is built into products and operations based on a set of principles and policies that recognize the need to continuously evolve security to protect against known, new, and unknown threats.
Principles and policies can be found in some emerging security guidelines, such as new telecom security requirements (TSRs) from the United Kingdom’s National Cyber Security Centre. Examples include the principle of least privilege, not only for administrators but also for connections across systems and services. Isolation and segmentation provide additional examples: Both are key because they force you to identify sensitive systems and to limit the blast radius if there is a breach. Proper network segmentation ensures that only components that should be able to communicate can communicate.
Here are a few more key principles and policies:
- Automate as much as possible of both deployment and operations to minimize human errors.
- Ensure that there is a properly secured system for management and operations access to the network components. This type of access, which is typically through what is sometimes called a privileged access workstation, should include secure access for required third-party personnel.
- Identify security critical systems in relation systems management, automation, and orchestration tools.
- Test early and often with tests that continuously evolve at multiple points in system, network, and service chains, including unexpected possibilities; example: system changes necessitate both new and modified tests.
- Monitor both components and human behavior for changes by, for instance, using a tool like VMware Carbon Black. Carbon Black is a cloud native endpoint and workload protection platform that combines system hardening and behavioral prevention to keep emerging threats at bay. By analyzing security events, Carbon Black proactively uncovers attackers’ behavioral patterns and empowers you to detect and stop emerging attacks.
- Assume you will be or already are compromised. The implication here to plan and deploy systems in a way that limits damage. For example, it can be a problem in the cloud if you use only cryptographic authorization and encryption — a hole that emerges with the authorization or encryption that creates a large attack vector. To protect against the inevitable, you must be able to isolate every level in the stack with virtual firewalling and other means, such as network access policies. Encryption should be accompanied by micro-segmentation.
Extending Protection Principles to CNFs
Similar principles apply to containerized network functions (CNFs). As you work to package and deploy networking code in containers for 5G, you should consider how to secure the container lifecycle and address the following principles and policies, conceivably in a multi-cloud environment, a context often overlooked, at least in a detailed way, by telecom security standards:
- Protect CNFs as they move through a continuous integration and deployment (CI/CD) pipeline.
- Implement a trusted container image registry with role-based access control and vulnerability scanning.
- Test containers to eliminate privileged access or execution.
- Inspect containers against security benchmarks.
- Automate security patching of containers.
- Isolate, protect, and monitor the communications of CNFs and microservices.
- Enforce policies governing CNF connectivity.
- Protect your CNF supply chain by establishing end-to-end security from code provenance to CNFs running in production, preferably by using DevSecOps.
Continuously Evolve
On a final note, embracing DevSecOps and continuously applying new security principles can help address emerging threats and to help evolve security so it keeps pace with emerging threats. In future posts, we will elaborate on not only the principles and policies we mentioned but also on how to implement a 5G network with security that’s built into the stack.
