Creating A Secure 5G Service Based Architecture: Part 2 － API Security

In our previous blog on 5G SBA security, we looked at the key capabilities for effective 5G security and examined what this means for vulnerability management. In this blog, we’ll look at Web Application and API Security (WAAS)  to repel service based interface (SBI) abuse.

As a reminder, in the first blog, we identified the key capabilities for effective 5G security, which include:

1. Vulnerability management for comprehensive coverage and monitoring, identifying, and preventing risks to all the hosts, images, and functions in your environment.
2. Layer 7 visibility and security for web applications and APIs on any cloud native architecture.
3. Powerful runtime defenses that apply automated protection against unwanted activity and threats.
4. Compliance enforcement with pre-built compliance checks for centrally viewing and enforcing your own or industry compliance standards.
5. Shift left security with CI/CD, repository, registry, and Open Policy Agent integrations to secure workloads across the Software Development Life Cycle (SDLC).

With the advent of 5G (3GPP Release 15), the service based architecture (SBA) has been introduced, and with it numerous HTTP based APIs.  There are quite a few SBIs in the SBA, but we’ll start by looking at one that resides on the Network Repository Function (NRF), a critical element for helping NFs find and communicate with each other.

The NRF has a Nnrf_NFDisovery service/API which we’ll look to secure in this blog.  This interface is described in detail in 3GPP TS 29.510 which can be downloaded here.  3GPP has taken the helpful step of providing OpenAPI files for each SBI.  This means that tools like Prisma Cloud, which can import the API definition files, are able to create accurate API policies as well as greatly reduce the provisioning time to configure the appropriate rules.

In Prisma Cloud, we will create a new Web Application and API Security (WAAS) rule to secure this specific service.  Prisma Cloud supports “Collections,” which are a powerful way to filter workloads.  We can filter based on the image, namespace, cluster, etc.  In this example we filtered based on the image name and namespace.

Our WAAS policy will reference this Collection, which means that the policy will only apply to the workloads that match the criteria in the collection (e.g., the NRF containers).  We wouldn’t want to apply a policy for a NRF interface on a SMF instance!

As part of our WAAS rule we’ll define the application. Instead of typing everything in, I imported the definition from the 3GPP OpenAPI file, which auto populated all the values for us. The only value we will manually change is the port, since the NRF in my test environment has its HTTP/2 interface on port 9090.

In the API Protection tab we can see more of the details around the specific API we are securing.  Again, these values are dictated by the 3GPP OpenAPI yaml file I imported. Here we enable alerts for any parameter violations, invalid paths, etc.

We also want to go ahead and enable some security measures to ensure that any of the OWASP top 10 techniques used are identified and alerted (we could block these instead, but for now we’ll just alert on them).

DoS Protection is another important feature we want to enable. This will ensure the NRF is not overwhelmed with malicious or misbehaving containers running in the cluster. For now, we will set the alert threshold to 20 messages a second and start dropping requests at 50 per second (this is a lab environment, and in production these would likely be higher).

Once everything is configured, let’s test our policy to see if it's working.  Remember, we are in alert mode, so if we send an invalid URL to the NRF, the WAAS module will let it through, but we should see an alert.  Using a tool called nghttp I’ll send an invalid request from another container running in my cluster.

nghttp -v http://10.100.52.115:9090/nnrf-disc/v1/invalid

The verbose setting lets me see the HTTP2 traffic parameters, as well as the response received.

                              ; Open new stream

                              :method: GET

                              :path: /nnrf-disc/v1/invalid

                              :scheme: http

                              :authority: 10.100.52.115:9090

                               accept: */*

                               accept-encoding: gzip, deflate

                               user-agent: nghttp2/1.30.0

…

[  0.004] recv (stream_id=13) :status: 404

[  0.004] recv (stream_id=13) content-type: text/html; charset=utf-8

[  0.004] recv (stream_id=13) date: Mon, 11 Apr 2022 17:17:34 GMT

[  0.004] recv (stream_id=13) x-frame-options: SAMEORIGIN

[  0.004] recv (stream_id=13) x-prisma-event-id: 1c74ed9b-23a7-2e80-334f-1a140197f1ed

[  0.004] recv (stream_id=13) content-length: 101

If I navigate to the WAAS related events in Prisma Cloud, I see a list of potential WAAS security event types.

I click API protection and see the invalid path at the top of the list of events.

Clicking on it I get details into the rule, container involved, the API path, the response code, etc.  Using API security, we have detected (and could have prevented if our policy was set to do so) invalid API calls to my NRF.

At this point we have significantly shored up the security of the NRF.  To recap, we have configured the HTTP endpoint for the NRF service, protection for the specific SBI API and enabled DoS protection for that API.  This will ensure that communication to the Nnrf_NFDiscovery API/service will be valid communication, and any deviations will be logged (or prevented if we want to).  While we have focused on this single NRF SBI interface, we could (and should) extend this sort of security to our other 5G Service Based Interfaces as well.

What happens though in the situation where an intruder gets access to our cluster, and possibly even a running container?  Image scanning, while important won’t detect this, API security while necessary for the SBA won’t help either.  To detect this, we will need Runtime defense enabled.

We’ll look at runtime defense in our next blog.