The move to 5G for wireless networks has brought about a fundamental shift in how we view and manage the core of the network where all the network functions (NFs) reside. Moving from bare metal and virtual machines (VMs) to micro services is a huge paradigm shift, requiring a new architecture. For 5G networks this new architecture where NFs communicate with each other is called the “Service Based Architecture” (SBA). This service-based paradigm means new risks and requires new approaches to cyber security.
To enable effective 5G security in a new SBA world, operators and enterprises will need to leverage cloud native tools that were made to work with cloud native applications.
Deployment models will vary, so the ability to secure infrastructure, applications, data, and entitlements in massive deployments over thousands of nodes in public, private and hybrid environments will be critical. Key capabilities for effective 5G security include:
- Vulnerability management for comprehensive coverage and monitoring, identifying, and preventing risks to all the hosts, images, and functions in your environment.
- Layer 7 visibility and security for web applications and APIs on any cloud native architecture.
- Powerful runtime defenses that apply automated protection against unwanted activity and threats.
- Compliance enforcement with pre-built compliance checks for centrally viewing and enforcing your own or industry compliance standards.
- Shift left security with CI/CD, repository, registry, and Open Policy Agent integrations to secure workloads across the Software Development Life Cycle (SDLC).
Without these key features, significant gaps in visibility and security of your 5G network will exist. While it may seem overwhelming, I’m here to let you know that it doesn’t have to be. In this blog and others, we’ll start to look at practical ways we can begin to secure our 5G core, leveraging some of the features above. Specifically, we will look at how we can address the risks below using the corresponding remedies listed.
| Risk | Remedy |
| 5G NF images (e.g., AMF, SMF, etc.) with libraries containing vulnerabilities | Vulnerability management of container images to catch images with high-risk libraries before they are deployed in production |
| API abuse of 5G service-based interfaces (SBIs) | Web application and API security to ensure valid API calls and prevent DoS attacks |
| Anomalous activity of containers, including potential “low and slow” reconnaissance after a breach | Autonomous learning every time a new image is detected in an environment. Detection and/or prevention of activity outside the learned model of a running container. |
Let’s take a few of these many features and apply them now to a 5G Service Based Architecture (SBA). The remainder of this blog post will focus on vulnerability management and how we can use it to detect vulnerabilities in container images. Subsequent blogs will look at API security and runtime defense.
Vulnerability Insights
Understanding the risks and potential vulnerabilities within a container or host image is paramount to 5G security. The last thing any operator or enterprise wants to do is deploy a 5G microservice that has a critical CVE associated with it. With Prisma Cloud, you can quickly gain insight into what risks images, running and not yet running, pose to your network.
If you were to deploy Prisma Cloud after you had a 5G network already up and running, one of the first things you would want to do is see the Radar view of your environment. Radar is showing you what is up and running in your network through a simple and intuitive interface. With the Radar view, we are able to see all the images, their network communication, running container counts and relevant namespaces in one screen. Below is what we see for an open source 5G core I have running based on the Open Air Interface project.
Using this view, we can quickly ascertain which running images have risks associated with them, which microservices have web interfaces and whether those web interfaces are unprotected. See below for a cheat sheet of the icons shown.
If we want to know more about any of the risks associated with any 5G NF we can click on the image icon. This gives us additional information about that image, including vulnerabilities and compliance alert summaries. For example, if we click on the network repository function (NRF) image, below is what we see.
The vulnerabilities are ordered from the most critical risk to low risk, helping you prioritize risk. The green icons show no current runtime or WAAS issues. Under the risk summary we can see that Prisma Cloud has detected an unprotected web application (e.g., the SBI interface) and is encouraging us to enable WAAS rules for this container, which we will discuss in a later blog.
To get more information about this high-risk vulnerability, we can simply click on the “High Risk” text to get more details on what these risks are.
On the next screen there is quite a bit of information about the risk. We can see what the CVE is, what version library the risk exists in, and when it is fixed. At the time of writing this, we can see that this openssl vulnerability is very new (only 2 days old). Furthermore, Prisma Cloud provides details describing the nature of the vulnerability and what the specific risks are.
The other high severity vulnerability for cyrus-sasl2 is a bit older, and does have a fix for it, which Prisma Cloud gives you details around. This is significant since the operator or enterprise can now go back to the developer of the NF and point out specifically what the issue is, and which version they’d like the developer to use instead.
Remember, Radar is showing us issues for already deployed containers. What if we wanted to detect these earlier, before the container was deployed? Suppose we had a new version of the NRF from a vendor and wanted to understand the risk associated with deploying it. Fortunately, this is possible as well. To do so we would simply need to point Prisma Cloud to our registry (in my case it is in Amazon’s Elastic Container Registry) and then view its findings. If I filter on the NRF container image, which is what I was viewing in Radar, below is what I see. From here, just as in Radar, I can click on the line item to get additional information.
Getting this information before an image is deployed is critical in keeping the 5G core free from insecure containers, or, at the very least, understanding what risks they pose before they are deployed.
With an ever-changing environment where containers are frequently spun up and spun down, this sort of visibility is crucial to running a secure 5G core. With this information, operators and enterprises can understand the risk associated with each 5G NF running in their network and take appropriate actions to mitigate or eliminate that risk.
In upcoming blogs on securing the 5G SBA, we’ll look at API security and runtime defense.