In our 5G security projections for the future series, we introduced the idea of 5G OWASP for networks, envisioning how the 5G OWASP will look from a telecommunication core network perspective in 2028. Therefore, this week we will turn towards the interface between industrial and mobile core networks i.e. vertical industry security.

5G Vertical industry security risks

Nowadays, we see that 5G is marketed often as an enabler for the connected industry and a large range of vertical use cases e.g. automotive, smart city, health, and others. Included in the term "industry" also are the small network providers that link their systems to a larger mobile network operator. 

Industry 4.0, connected automotive, smart city, smart health, enhanced entertainment, etc. We all have probably seen the 5G use cases, but now let’s think about what does this mean in terms of 5G security risks.

Where are the potential weak spots that we should take into consideration and what might be the 5G OWASP concerning the industry connectivity in 2028? Let’s start with the most obvious ones:


1. Broken Access Control (Verticals)

Integration of verticals into 5G networks using Multi-Access Edge Computing (MEC) and sometimes Common API Exposure Function (CAPIF) has led to a range of breaches and now we see it reflected in the 2028 5G OWASP.

The vertical access control enables network or third-party APIs to be used by external vertical entities like factories, automotive, health or entertainment. The verticals have often their independent ecosystem and developer community e.g. entertainment, which has access to the network APIs via the MEC platform. Also, the verticals receive data from the mobile operator network.

In our 2028 projection, we see that many operators have a quite broad service APIs to avoid fine-tuning the APIs for each vertical and for easy management. As the access control for those service APIs is API and not information element-specific, the external vertical had access to much more information than intended, and sensitive user information was leaked.

Example - Lack of input parameter validation attack

Figure 1: Mobile Edge Computing (MEC)

2. Malware Injection via Industry Interface

Multi-Access Edge Computing (MEC) applications are very popular for entertainment and gaming purposes and commonly developed by third-party developers. The application developers register their MEC application (e.g. an entertainment video extension) with the MEC provider platform. The MEC platform provider also offers the APIs for network-related information like location, bandwidth or traffic routing, so that the developer and the MEC application know when to enhance the user traffic and have access to it for their application. In simple terms, it adds items to the user’s data traffic.

The security screening of those applications and the trustworthiness screening of the developing parties are very challenging tasks for the MEC platform providers, and from app stores, we know that this kind of screening doesn’t mean full protection.

In our envisioned future in 2028, we see many MEC applications that were not sufficiently screened and were compromised and injected malware, ransomware software and spam into the traffic going to the user.


3. Improper Assets and Interface Management

In the 5G Service Based Architecture, functions (aka network nodes) expose their APIs to all end-points in the same network and through the Security Edge Protection Proxy (SEPP) to all entities on the IPX roaming network i.e. partner operators, value-added service providers and IPX service providers. Assets and interfaces need to be updated and maintained.

5G has great potential for virtualisation, but that is a two-sided sword. Virtualisation needs also a secure asset and instance management. Latest threat intelligence and analytics were commonly not used and deployed quickly to rules and deployed in firewalls, which led to data extraction for an extended period of time.

The usage of different versions of APIs and no cleaning up of unused instances allowed in some cases attackers to gain access using a deprecated API version or unused instances. This asset and interface management risk does not only affect the IPX related interfaces, but also the industrial APIs.

Example - Lack of input parameter validation attack

Figure 2: Non-blocked insecure legacy version risk


4. Parameter Tampering and Slice Theft

Industrial connectivity applications are expected to run in isolated virtualised slices connected by secure channels. But depending on the architectural model, there are still some shared elements with the “hosting” operator.

Tampering of information in API requests has revealed hidden information and led to session hijacking. Also, the tampering of information elements e.g., slice identity inside the message may lead to information exposure in some occurrences (also known as failed slice isolation) and the hijacking of another network slice could be possible.

In many cases, the randomly generated identities were supposed to be unique and the implementations generated identities that were no longer that random. That led to successful brute force attacks against the identities. A misshaped request has also caused undesired side effects when it is parsed at the receiving end. It also caused a constant reboot of a key database node at one operator, which resulted in a partial network outage.


5. Denial of Service

The Service Based Architecture (SBA) has to carry many different information elements and requests to different core network APIs. In 2028, we see that there will often be no restriction on the size or frequency of the number of resources that a REST API consumer can request.

The integration of new network types exposed core network functions and industrial slice containing nodes to external parties. This caused in some cases an impact to the API providing core network nodes and led to a Denial of Service (DoS). In some rare cases, the lack of rate limiting was used by attackers to brute force authorisation tokens.



For a top-10 5G OWASP starter, I think you would agree the list is quite intimidating. The implications are amplified when you consider the global lack of skills and knowledge. If there was ever a time for core network security teams and their opposite numbers in IT security to put old feuds behind them, it is now.

All those 5G OWASP are predictions and hopefully, they will not happen. We always say we want to learn from the past, we can at least try and avoid some potholes and if we cannot fully avoid them, let’s be able to handle them safely.

The general approaches for telco APIs are not that much different to the IT sector. To whom do you want to expose what and how? Monitor & log, that you are as secure as you hope you are. Stay on your toes and up-to-date with the latest threats….

The previous post is the last one from a series of 3: