Opening up on API security: how to secure networks while exposing them

Application programming interfaces (APIs) are playing an ever more important role when it comes to increasing the usefulness of telecom networks and support for new differentiated services. APIs act as crucial connection points that enable communication between functions within the network, or between the network functions and external applications. In our post on APIs and network security (the second episode in this 5G security blog series), we introduced the types of APIs – external exposure APIs and internal network APIs – and looked at some key lessons from the enterprise space that can help guide communications service providers (CSPs) and other industry players when it comes to network API security.

In this post, we take the next step – asking and answering some of the more in-depth questions around external exposure API security. How do you secure APIs at the same time as exposing them? And what are the different roles and responsibilities at play, as we open up APIs to new and more numerous players in the telecom ecosystem?

Why do networks need exposure?

To unlock new services and monetization opportunities in the competitive telecom industry and enable CSPs to deliver new services on a global scale at speed, networks need to become more exposed – a pattern we’ll only see more of as digital transformation progresses. Many innovative emerging 5G use cases, services and monetization opportunities use capabilities that draw on specific information or functions existing in the network – meaning information such as data and network services need to be made easily available to external entities. This information could be from functions of the network itself, or from a subscriber or device.

Hear Orange, Telefonica, and Vodafone, in collaboration with Ericsson and Vonage, explaining their demonstrations of how 5G network functionality can be exposed via APIs and made easily consumable by the global developer community.

One such example is the use of APIs and network exposure for connected drones in industrial applications. In this use case, information can be shared via APIs between a user, the network and a drone to authenticate and authorize user access, change Quality-of-Service (QoS) on demand to improve video quality from the drone, and even optimize flight patterns according to network coverage or dynamically switch data traffic to a low latency network slice when necessary to enable remote control.

Network exposure can similarly be used to boost connectivity on demand for other use cases like mobile gaming that require low latency, or to verify that a subscriber is located where they claim to be – and flag potential suspicious activity if they aren’t. None of these services would be possible without exposure APIs, sharing the necessary information to be used by other external applications. But opening up pathways to enable external access to information doesn’t come without risks.

Network API security – staying secure when exposed

Naturally, the safest way of using APIs in telecom networks is to keep them contained within one’s own internal network environment. As with the internal network APIs we focused on in our earlier episode, risks can immediately be reduced by taking measures to ensure that the API and network information isn’t accessible at all outside of the network. Authentication and authorization checks are crucial to ensure only those authorized can use the required resources – and that they can only access those resources intended for sharing. Several tools exist to check what is visible from outside of the network, as a precaution against anything unwittingly being exposed.

But to achieve the advantages we mentioned before, this isn’t always possible – APIs must be exposed externally. When exposing APIs beyond your own network, you’re entering a space where you inherently have less control. Of course, you can still control who can use the API via access controls or similar authorizations – those are extremely important. But as a CSP, you’re making these APIs available to your customer and potentially their customers in turn, which means a wider range of entities that can make requests and induce actions – and an API end consumer that could potentially be unknown or untrusted. This also offers more opportunities for vulnerabilities to be introduced – often accidentally – which can be exploited.

According to insights from 451 Research’s 2022 API Security Trends Report featured in Security Magazine, 41 percent of the global companies surveyed suffered API security incidents in 2021, and recent events have shown that the telecom industry also has not been spared. These incidents clearly demonstrate that this rapidly evolving area should be a core priority for telecom players when it comes to ensuring security.

Sharing the responsibility for network API security

This broader inclusion of ecosystem players with access to exposure APIs means that security is transformed into a shared responsibility. Protecting your network and its valuable information is now reliant on collaboration between various stakeholders, meaning partnership and alignment is imperative. If a CSP is exposing an API to aggregators (telecom service resellers), for example, part of the security responsibility falls on the aggregator. Part also falls to the application developer – as the consumer of the API, they must also have good security hygiene in their application so security can be ensured end-to-end.

In all this, the CSP faces the challenge of balancing the risk of exposing network functions on one hand, and providing APIs that give value for the aggregators and their customers on the other - all without knowing exactly how the end consumers will be using these APIs.

With so many more stakeholders involved in this lifecycle, it’s vital that the industry players all have a clear understanding of the different roles and responsibilities at play in this ecosystem. What must they understand and do to play their part in ensuring security? What do they need to ensure their partners understand and act on?

Two things are of importance here. Firstly, to deliver new, high-performance and secure solutions at scale and speed, players need to build stronger relationships and partnerships where they can share responsibility with confidence, taking collaboration to a whole new level. Secondly, a common framework among partners is required to steer the API security requirements and design choices – and it’s here we see Zero Trust Architecture (ZTA) playing an important role.

Secure 5G network exposure: applying a zero trust approach

The foundations of the zero trust architecture and security models are already well-established in the telecom industry, as conventional perimeter-oriented approaches to network security proved insufficient to protect the ever more heterogeneous nature of 5G mobile network infrastructure. A zero trust model operates under the assumption that an attacker is already inside the network. It focuses on enhancing security by blocking unauthorized access to network resources and preventing internal lateral movement by an attacker. In a zero trust approach, no entity is implicitly trusted based on where it is (for example, inside the network perimeter). Instead, authorization – and potentially additional proof of trust – is required whenever a new request is made. This zero trust principle can be seen in the internal API security of the Service-Based Architecture (SBA), using authorization tokens for API use and the protection of tokens by mutual transport layer security (mTLS).

At Ericsson, for example, we generally apply zero trust principles both to our networks and for the different use cases these networks are used for – meaning network products also have to follow zero trust architecture in the same way. In our approach, zero trust architecture represents a holistic active defense strategy for managing risk, ensuring control both vertically and horizontally and complementing existing state-of the-art information security practices.

Logically, for a holistic defense strategy to operate effectively across multiple responsible partners, they all need to be aligned and committed to adopt this zero trust approach and extend it across the board – from the development of network products, APIs and applications to the deployment and runtime operation of these solutions. Zero trust also necessitates that proper management, authentication and authorization of application end users are carried out.

Key players, roles and responsibilities

In order for key players to understand where they stand in this chain, it’s important to clarify the roles and responsibilities when it comes to ensuring exposure API security. We also complement each summary with some expert insights into best practices – tips on what these players can do to strengthen network API security.

Before we dive in, it’s worth noting that enterprises can either take the role of 5G application providers; be 5G CSPs themselves (in the case where they deploy private 5G) or be consumers of third-party 5G applications. Similarly, CSPs or network vendors can in some cases play the role of API aggregators as well. With this in mind, we note that the measures identified below are based on general role classifications of participants in this ecosystem. These suggestions for security controls and their implementation may need to be adapted to the particulars of the exposure deployment in question and the nature of the relationships between the players participating in the process of exposure.

Key players in the network API Eco-system and relationships between them. Relationships in the figure are illustrative only

Vendors

Telecom vendors like Ericsson sell telecom infrastructure products and solutions, including network APIs, such as through Ericsson’s Cloud Core Exposure Server (CCES), either to CSPs or aggregators. Vendors are responsible for providing security assurance for their products, including having secure product development guidelines in place, such as our Ericsson Security Reliability Model (SRM) and implementing a zero trust architecture for their products, as mentioned previously.

Vendors are the ones safeguarding the network infrastructure and, as such, should strictly adhere to rigorous global security standards in their solutions and technologies. Schemes such as the GSMA Network Equipment Security Assurance Scheme (NESAS) audit and test network equipment vendors, and their products, against a well-recognized security baseline. Vendors should consider becoming NESAS compliant to be able to demonstrate to CSPs that they are conforming to the desired security standards, as defined by industry experts through Global System for Mobile Communications (GSMA) and 3GPP.

Given the evolving nature of the API security landscape, and network security in general, vendors should also ideally be participating in activities to proactively develop better security controls, and be actively involved with the wider ecosystem and organizations such as GSMA to help inform the standards governing the telecom industry.

Communication Service Providers (CSPs)

CSPs operate the networks and sell connectivity solutions and services to their customers. CSPs in general have a large share of responsibility for ensuring secure operation and maintenance of deployed network infrastructure. Their responsibilities when it comes to API security centers around complementing and building upon the holistic zero trust approach introduced by the vendors with their technology. Specifically, CSPs are responsible for the secure deployment and operation of the technology including services for authentication, authorization & consent management for external API consumers.  

CSPs also have to ensure they encrypt communication flows through APIs and take active measures to ensure runtime protection at the API gateway level (such as deploying third-party security solutions). They have a delicate balance to maintain when making decisions. They want to make the exposed APIs as easily consumable, transparent and as seamless as possible for developers and applications. At the same time, they must be judicious in what data and functions get exposed, to ensure a distinct separation between what is exposed and what is not – for example, ensuring internal APIs or sensitive information are not exposed. CSPs have many choices to make, and these may include dealing with conflicting demands.

It is important to note that CSPs handle private user data and play the role of ‘data controllers’ from the General Data Protection Regulation (GDPR) perspective. Therefore, they have strict compliance requirements for protecting the privacy and rights of network subscribers and for controlling how subscriber data is used/consumed via APIs.  As part of fulfilling these responsibilities, CSPs should take proactive measures to check for security relevant misconfigurations in exposure, e.g., unauthenticated and undocumented API endpoints being exposed externally.

Aggregators

While they generally do not own infrastructure themselves, aggregators are suppliers who build partnerships with multiple CSPs to package, expand on and/or resell communication services and solutions to customers. They therefore may, depending on the services provided by CSPs, need to take on responsibility for the authentication and authorization of users that the external API is being exposed to. They may need to be compliant with certifications (such as Payment Card Industry Data Security Standard (PCI DSS) and System and Organization Controls (SOC), for example, and in adherence with GDPR and other privacy regulations.

Aggregators hold a special position in that they interact with multiple CSPs and hence need to be careful while onboarding users. They should perform appropriate Know-Your-Customer (KYC) checks and set requirements for strong user credentials when onboarding new consumers or application service providers, and would also benefit from having proactive mechanisms to prevent account abuse, phishing or other types of fraud. Given the close relationships they have with CSPs, aggregators tend to take their security responsibilities seriously (as Ericsson’s Vonage do, for example), as any breach as a result of negligence would likely significantly damage their business relationships.

Application service providers (ASPs)

These are companies who own or develop an application that uses network exposure APIs in order to provide a service. ASPs are first and foremost responsible for making sure that they develop their applications securely. Similar to the API development and lifecycle process we discussed in our last API security post, there are secure development and coding practices they should follow. These include best practices for security hygiene such as not storing plaintext keys to the API within your application, not leaving default developer credentials checked in and using memory-safe languages when possible.

In addition, ASPs are responsible for doing proper consent capture from the user, to be able to access the required data over the APIs. This can be done through a one-time password (OTP) driven flow or via a redirect towards a CSP-managed consent capture page.

API security moving forward – one step at a time

Exposure through APIs does pose challenges – building and managing numerous relationships, having to deal with conflicting needs – it can seem overwhelming. As with all such tasks, the wisest approach is to break the process down into steps. As each new API is created, we need to keep in mind that security is a process where each party must evaluate the risks involved – both in their own parts, and in the areas where those parts intersect – and jointly work to mitigate them in an iterative fashion.

5G networks, and the capabilities they are enabling, are truly causing transformative change across the telecom ecosystem. We are in the midst of an evolution into a new, more mature era of communication services where we must all work together more closely than ever before if we are to realize the promises of a truly connected future – and protect ourselves and our critical systems and data at the same time.

Thank you for joining us for this, our second post on network API security – we hope you found it helpful and engaging. In the next and final episode in this 5G security blog series, our experts will turn their attention to enterprise, focused on how security can go from being an essential foundation to a business enabler – be sure to sign up so you don’t miss out!

The authors would like to emphasize that any tools or companies mentioned in this blog post are referenced as examples only and should not be considered as recommendations or endorsements.

Learn more

Explore the other posts in our 5G security blog series.

Learn more about securing 5G networks in our Ericsson Mobility Report article.

Discover how 5G has adopted zero trust principles in the Ericsson Technical Review article Zero trust and 5G – realizing zero trust in networks.

Find out more about telecom security for a connected world.