Home > Blogs > VMware Telco Cloud Blog > Tag Archives: Security

Tag Archives: Security

To Take Full Advantage of 5G Investments, We Need to Think Differently about Network Security

The potential market for new 5G services is enormous and is estimated to exceed USD 400 Billion by 2027. Services like autonomous transportation, low latency healthcare apps, reliable communication for first responders turn 5G networks into national security and critical infrastructure that cannot be allowed to fail.  

The challenge is that in a modern communication service provider (CSP) environment migrating to 5G, there is an increasing number of moving parts to protect, and that complicates 5-9s requirements. There’s a way to stay ahead of the threat, however.  If we’re going to get there as an industry, we need to start thinking very differently about network security. That starts with recognizing that we can’t just delegate it to the security team.  

Security is now a team sport—and should be part of every decision that gets made about your 5G network.    

New Innovations Bring New Challenges 

A couple decades ago, attackers may have been mostly lone operators seeking to cause mischief. Today, they’re highly organized, well-funded criminal operations, sometimes with state backing, with the time and resources to mount sophisticated long-term attacks. The new threats they’re developing are evolving more quickly than our strategies to combat them.  

Major industry groups have, of course, made efforts to protect operator networks, but wireless security standards remain inconsistent and incomplete. For example, 3GPP continues to do important work securing the signaling plane between services and inter-function communication, but many of these measures are optional and implemented differently by different vendors. They also only address the areas where 3GPP traditionally operates—not the underlying cloud architectures that many CSPs are now adopting. 

Today, as CSPs advance their 5G rollouts, these problems are growing more urgent.  

As we build out next-generation networks, we inevitably create new potential inroads for new threats, both from outside and within the network. Externally, the sheer density of subscribers, devices, and applications is reaching a level unlike anything we’ve dealt with before. But it’s the potential internal vulnerabilities that can be even more pernicious and that don’t seem to be on people’s radars.  

When your network gets heavily disaggregated, previously monolithic functions get broken up into many smaller pieces, in some cases, from multiple vendors. You can’t protect all those pieces, and the interconnections between them, using legacy approaches. Building proper security into the architecture from the beginning is easier than trying to overlay it later and thus savvy CSPs will consider this from the start.  

In response to the fact that these increasingly complex 5G networks are being considered to support aspects of national security and critical infrastructure, the government oversight that has already begun in the UK (and is sure to follow around the world) will soon regulate the security requirements for these networks. Exactly what the regulation will be in each country will vary but looking at the UK should provide a pretty good level of guidance because the UK’s telecom security requirements are ahead of the curve.  

Take Concrete Steps to Protect Your Architecture 

We absolutely can improve security for a 5G world, but that process starts with accepting reality: threats will continue growing more powerful, networks will continue getting more complex, and defenses will likely always be playing catchup. In this environment, you can’t rely only on fulfilling the requirements of regulations to protect you or your customers. Instead, we need to think differently—and more holistically—about how we’re designing and protecting our networks. That includes steps like: 

  • Thinking through security implications of cloud-native 5G infrastructure: As we develop and deploy containerized network functions (CNFs) for 5G, we need to be thinking about security across the container lifecycle in heterogeneous, often multi-cloud environments. That includes steps like securing CNFs through CI/CD pipelines, using trusted container image repositories with strict access control, and tightly controlling communication between CNFs and microservices.  
  • Reducing the blast radius: If you accept that breaches are going to happen, then the wise move is to design and deploy systems to minimize the damage when they do. For example, if you only use cryptographic authorization and encryption in the cloud, and attackers discover a vulnerability in those systems, you now have a huge potential attack vector. However, if you pair encryption with micro-segmentation—isolating every layer in the stack with virtual firewalling and strict network access policies—you greatly restrict what even a successful attack can do. 
  • Embracing opennessIt can sound counterintuitive, but using open standards and open, virtualized systems across your environment allows for stronger security than closed, proprietary technologies. Using a vendor’s vertically integrated system can seem more secure, but the reality is, you’re now completely reliant on that vendor to protect you. Effectively, you’ve got a “black box” in your environment, with no way to know what’s happening inside. Alternatively, if you’re using open, virtualized systems, you can inspect every layer of the stack. You also now have the freedom to quickly remove and replace any component that’s found to be insecure—including switching to another vendor’s product.  
  • Protecting your orchestration tools, as well as the things they’re orchestrating: In a world where more parts of your operations are getting automated, it’s essential to identify security-critical systems within management, automation, and orchestration tools. More than ever, we need to lock down management and operational access to network components and meticulously track any changes made.  
  • Think through security at every level of the network: Even as networks have gotten more virtualized, we still tend to think about security in a hardware-centric, box-by-box way. But while disaggregation means there are more pieces to secure, it should now be simpler to secure them. If you’ve implemented your next-generation architecture properly, you should be able to use uniform policies for everything and manage and enforce them centrally.  

Stay Ahead of the Threat 

For all the innovative things we can do with the next generation of service provider networks, 5G and beyond, it would be foolhardy to overlook the new security concerns that come with them. But while the threats are real, they don’t have to disrupt your customers (or even your weekend).  

At VMware, we’ve long argued that security can’t be a bolt-on feature that gets added after the fact. Rather, sound security needs to be built into every aspect of how you design and operate your architecture. We’ve also long argued that virtualization makes this job easier—and it should be easier still with next-generation 5G networks. When you have a horizontal, end-to-end abstraction layer overlaying your infrastructure, it becomes much easier to both monitor your environment and to enforce policy in a uniform, holistic way. Data privacy, ingress-egress inspection, micro-segmentation—all these things are now just policies you define at the software layer. And they can now be applied in the same way, everywhere, across even the most complex heterogeneous multi-vendor architectures.  

Want to learn more about the steps VMware is taking to secure operator environments for 5G and beyond? Download our Intrinsic Security for Telco Clouds overview. And, for an in-depth technical exploration of this topic, see the VMware white paper Intrinsic Security for Telco Clouds at the Dawn of 5G.  

Evolution in Principle: Emerging Wireless Security Threats and the State of Cybersecurity

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.

Adapting to a Changing Landscape and Shifting Requirements with Built-in Security

Adapting to Emerging Security Requirements

It’s easy to forget the role of security and compliance in delivering an excellent customer experience — consumers rightfully dread the thought of interrupted communications, breached personal data, or hacked credit card numbers. A highly secure network contributes to a differentiated and distinguished service that attracts and retains customers, but sometimes it’s hard to remember that fact because the value of security lies in the absence of attention: For CSPs and customers alike, no news is good news.

With the shift toward 5G, however, some security standards for CSPs have gone out of date. In the U.K., for instance, the NCSC’s previous telecoms assurance standard known as CAS(T) is done. The NCSC formally closed CAS(T) on Jan. 31, 2020, saying that the “technical aspects of the standard do not align to the evolving telecommunications landscape and will quickly become out-of-date, without NCSC maintenance. Therefore, whilst it will remain available on the NCSC website for historic purposes, the NCSC does not recommend its continued use.”

CAS(T) is being replaced in part by the NCSC’s new telecommunications security requirements, or TSRs, which are focused on improving network security. Based on a framework of contemporary security principles, the requirements provide extensive implementation guidance for technology that is critically important as CSPs shift their networks, equipment, operations, services, and business models to 5G. Software-defined networking, cloud native network functions, containerized applications, orchestration, and the virtualization plane take center stage.

“The potential economic and social benefits of 5G and full-fibre digital connectivity,” the NCSC’s report says, “can only be realized if we have confidence in the security and resilience of the underpinning infrastructure.”

The Benefits of Built-in Security

When security is an intrinsic part of the technology from start to finish — that is, when security is built into the software and infrastructure from the beginning instead of bolted on as an afterthought — it empowers you to quickly, effectively, and economically capitalize on the new market opportunities of 5G without undermining the security of the virtualized network or its management.

Why? Because intrinsic security improves your ability adapt to changes. The VMware model, for example, helps you more easily and quickly make changes to security settings, network policies, and even the network topology itself to meet emerging telecommunications security requirements, such as those that the United Kingdom’s National Cyber Security Centre is working on.


The Shifting Security Landscape

Here in the United States, NIST has also shelved at least one of its old telecommunications guidelines, and a replacement hasn’t been forthcoming yet. The previous guidelines, Telecommunications Security Guidelines for Telecommunications Management Network, SP 800-13, was withdrawn as outdated on August 1, 2018. Meantime, NIST and the National Cybersecurity Center of Excellence are working on a project for 5G security titled Preparing a Secure Evolution to 5G ; so far, however, only the project description has been published, which makes taking concrete action difficult.

VMware has published two new white papers to discuss the security challenges that CSPs are facing as they evolve their network architectures to 5G and how VMware is addressing these security challenges with our existing products and solutions:

Intrinsic Security for Telco Clouds at the Dawn of 5G. 



This technical white paper summarizes the security risks and requirements that CSPs face as they transition to 5G networks and increasingly rely on virtualization, containers, and cloud computing. The paper illustrates how VMware technology protects telecom networks with an array of built-in security measures, many of which can be automated.


Intrinsic Security for Telco Clouds: Protect infrastructure with built-in measures

This short paper explains how the VMware Telco Cloud emphasizes intrinsic security—integrated with the software and infrastructure so that security is programmable, automated, adaptive, and context-aware.

With the VMware Telco Cloud, security is built into the software and infrastructure, which improves visibility, reduces complexity, and enables CSPs to focus their defenses by applying automated security measures like micro-segmentation in the right place.

Micro-segmentation is a pertinent example. It divides a virtual data center and its workloads into logical segments, each of which contain a single workload. You can then apply security controls to each segment, restricting an attacker’s ability to move to another segment or workload. This approach reduces the risk of attack, limits the possible damage from an attack, and improves your overall security posture.

 Isolating and Automating Security with the VMware Telco Cloud

The NCSC’s TSRs, then, seem to be prescient — they furnish an early government-driven perspective on security and compliance for CSPs as they roll out 5G networks and services.

The security measures that are built into the VMware Telco Cloud help you readily adapt to the NCSC’s key high-level security imperatives for virtualized networks, such as isolating the management network, segmenting traffic, and automating administration.