APIs and network security: three key lessons from enterprise
- The exposure of advanced 5G functionality through common APIs will enable innovation of new services on a global scale with speed.
- The richness of 5G comes with greater complexity and new security risks need to be appropriately addressed
- The telecom industry can, and does, benefit from API security lessons already learned in the enterprise space.
- Explore the use of APIs in networks, plus key lessons on standardization, security and the tools and partnerships to help CSPs on their 5G journey.
As we move to 5G and beyond, new technologies and capabilities are emerging, and telecom networks need to evolve in-line with these developments. To leverage these new capabilities and enable more differentiated or personalized services, our networks are moving towards a horizontal architecture – one that is split into a range of smaller parts with specialized functions and greater flexibility. But the breaking up of these functions also means connections are needed to communicate important information between them – which is where application programming interfaces (APIs) come into play.
Simply put, an API is a type of software that acts as an interface or connection point, enabling two different applications or functions to communicate with each other. Given the intricate, open nature of the multi-vendor ecosystems our networks are transitioning to with 5G, it's crucial to establish these connections while ensuring they are both standardized (compatible across vendors or products), secure and flexible. But, as we discussed in our first post in this 5G security blog series, the threat landscape around telecom networks is also changing – and since adding new interfaces inherently expands the attack surface, those threats must be appropriately countered to avoid increasing risks.
APIs within and beyond the network
Depending on what they are connecting, APIs can primarily be categorized into two types: external exposure APIs and internal network APIs. External exposure APIs are those that act as a connection between the network and external applications or partners. This could include sharing some specific information about a subscriber or device. Location information could be shared for parcel delivery, for example, or to track the movements of a robot or vehicle. It could even be used for security purposes, to verify a subscriber is located where they are supposed to be – or to flag any suspicious activity from unexpected locations.
External APIs, such as the Quality of Service on Demand (QoD) API, can also be used to boost connectivity on demand and significantly enhance user experience for use cases like real-time gaming and high-density video streaming or conferencing, as showcased at Mobile World Congress earlier this year. Due to their external-facing nature and openness, these exposure APIs pose unique security challenges, which we will explore in more detail later in this 5G Security blog series.
Internal network APIs are those used within the network, to connect functions in the 5G Core network within a 5G Service-Based Architecture, for example. These network functions each serve a specific purpose, such as authenticating a user, handling user data or controlling how certain data or messages are transferred throughout the network. The service APIs that connect these enable them to communicate and coordinate through requests and responses.
Both internal and external-facing APIs are built on the same technical foundation (Representational State Transfer, or REST) and share similar access controls and common security considerations (such as mutual authentication, authorization and encryption). These shared characteristics also enable a standardized way to open up interfaces and accelerate development of 5G services. Despite the similarities, internal network APIs generally have lower risk, as there is no reason for them to be accessible from outside the network.
Ensuring security in network APIs
While the utility and agility benefits of APIs for 5G networks are clear, they must be adopted with care to ensure the accompanying security risks are being mitigated as much as possible. Fortunately, we don't need to forge an entirely new path ahead – many lessons in API security have already been learned from advancements in enterprise IT.
Let’s take a look at three of the key takeaways and best practices we’ve observed from enterprise that can help communication service providers (CSPs) and others in the telecom space move forward with confidence.
1. Best practices and standards paving the path to success
APIs have existed in the enterprise world for some time already. In fact, there are several companies with products centered entirely around cloud-based services that expose APIs and allow integrations between software and applications. This kind of prior experience in API exposure and integration and the associated operational pitfalls these enterprises have encountered over the years can be highly informative for the telecom industry, particularly in the security sense, when it comes to identifying the most likely vulnerabilities and high-risk factors for API adoption.
The Open Web Application Security Project (OWASP) API security project represents a leading effort in this space. This project compiles a list of the top ten risky API security issues sourced from community surveys, exploit data and vulnerability databases. Not only is this kind of information helpful when it comes to building awareness of API security issues within the broader ecosystem, it can also be informative for the development and testing of telco APIs, giving us some idea of what API attacks might look like.
It’s important to remember, however, that while this list offers a great place to start, it’s not comprehensive on its own. It’s also worth noting that many of these issues are already being addressed in current telecom standards. Of the top ten list for 2023, six of the most common issues identified (and all of the top five) are already covered (at least to some extent) by the 3GPP standards and Common API Framework (CAPIF) for mobile networks.
To complement standardization efforts and to have a holistic approach to security, we should secure APIs across all relevant phases including standardization, product development, deployment and operations. Together, securing these four areas contributes towards creating a secure, trusted platform – and an ideal foundation on which rapid innovation can happen.
|OWASP API Security Top 10 Risks and Vulnerabilities
|Lead role for prevention (standardization, development, deployment, operations)
|API1:2023 - Broken Object Level Authorization
|Standardization, controls defined in 3GPP. API authorization. (Work ongoing on finer granularity authorization for exposure)
|API2:2023 - Broken Authentication
|Standardization, controls defined in 3GPP. API authentication.
|API3:2023 - Broken Object Property Level Authorization
|Standardization, controls defined in 3GPP. (Work ongoing on finer granularity for exposure)
|API4:2023-Unrestricted Resource Consumption
|Standardization, controls defined in 3GPP.Rate limiting
|API5:2023-Broken Function Level Authorization
|Standardization, controls defined in 3GPP. API authentication. (Work ongoing on finer granularity authorization for exposure)
|API6:2023-Unrestricted Access to Sensitive Business Flows
|Operations. Can be handle with runtime protection mechanism, e.g. device fingerprinting, bot detection, IP blocking
|API7:2023 - Server Side Request Forgery
|Product development. This is handled with proper input sanitization. This is dependent on having a secure software development cycle.
|API8:2023 - Security Misconfiguration
|Standardization, controls defined in 3GPP. Request inspection and audit logging. Operations. Proactive security posture management
|API9:2023 - Improper Inventory Management
|Product development. This is handled with secure software development and documentation practices. Operations "Runtime API discovery"
|API10:2023 - Unsafe Consumption of APIs
|Standardization, controls defined in 3GPP. TLS. Product development - input data sanitization
Security standards have a crucial role to play in 5G, as highlighted in another recent post. But standards can be challenging when it comes to APIs, as it’s really about finding a delicate balance between mitigating risk from increasing the attack surface and exposing useful functionality. Openness and flexibility in the implementation of different functions in different ways and from different vendors will be crucial for the realization of future services and solutions.
2. Security across the API lifecycle
The experience and processes developed to date for enterprise APIs has also given us a great deal of valuable guidance when it comes to best practice. In the development process (and not just in telecom) it can be easy to get caught up focusing on the features you want, your business goals – what it is you’re trying to implement, and how to deliver it. Of course, that’s vital, but it’s also important not to forget to incorporate security considerations from the very beginning – and along every step of the way. At Ericsson, for example, right from the planning stage we are already taking a secure-by-design approach when it comes to API development or adoption. This expands on our Ericsson Security Reliability Model (SRM). But what does it mean in practice?
It might involve, for example, having a workgroup of security experts involved from the start of the project, considering the security and privacy aspects of what we’re trying to do and making recommendations. As security is always evolving and new types of attacks emerging, trusting that whatever measures were put in place in the last development will be sufficient simply isn’t enough. Security must be implemented into each API project across the design process, utilizing the latest knowledge and taking into account the specific requirements, environment and other factors for this particular use case. Experts can identify weak points that others might miss – a key advantage, given vulnerabilities often sneak through where you’d least expect it.
One attack in the telecom industry was reputed to be caused due to an API being exposed to what the developers thought was an internal lab testing environment – but somehow a vulnerability was exploited enabling access to other systems where subscriber information could be accessed. API security is also not a ‘one and done’ solution, limited to the development phase. Back in 2019, a large breach at a leading Indian search engine was allegedly caused by an old and unprotected API being exploited. Even though the API endpoint was no longer in use (and the current APIs were adequately protected using authentication measures), the old API had been forgotten and left on the server – vulnerable to attack and the resultant leaking of over 100 million users' personally identifiable information.
With these examples, it’s clear that security in the design process isn’t enough on its own – the whole API lifecycle must be considered to protect the network and its users. APIs need to be well documented, complete with categorization of what is being exposed, and to who. This documentation can also support testing at various stages in the design, pre-launch and deployment to ensure that no unauthorized access or exposure occurs.
3. Tools and partners at the ready
This process may seem intimidating, with a lot to consider, but another advantage of the advancements in the enterprise space is that you definitely aren’t alone in this battle for secure networks.
Firstly, particularly if you’re less experienced in the security space, ensure you’re partnering with experienced suppliers and vendors so you can be confident that security assurances are at a high level. At Ericsson, for example, we have thorough product design guidelines in place for security (our Ericsson SRM). We contribute to safeguarding the integrity and resilience of network infrastructure through a comprehensive approach, strictly adhering to rigorous global security standards solutions and technologies.
Secondly, where additional security measures are needed to support, evaluate and update API security over the lifecycle, plenty of tools and solutions are already available to help make life easier. The API security space is extremely active, with incumbent vendors moving in and a vibrant startup scene growing rapidly with strong venture capital support. During the API lifecycle’s design phase, tools are available to aid in discovery (the documentation of APIs, as mentioned earlier), code checking during development and testing. In the runtime stage (during and after deployment) tools can help with additional runtime discovery and testing as well as threat protection. Examples of such tools can be found in the API protection tools and companies and ratings by Gartner ® Peer Insights™.
Secure exposure for the next generation
As we look ahead, we can only expect that openness, exposure and APIs will continue to be important – maybe even more than ever – and that the threats targeting these technologies and solutions will also continue the fight to get ahead of the curve. So far, each generation of mobile network has taken security to a whole new level, and we expect no less for 6G when it comes.
Ericsson has long contributed to safeguarding the integrity and resilience of network infrastructure through a comprehensive approach, strictly adhering to rigorous global security standards. We’re already undertaking security research activities to learn and develop better security controls for the networks of tomorrow, and to inform the standards that will govern them.
Later in this blog series, we’ll be exploring further into the world of external exposure APIs and the risks and solutions at play, so be sure to sign up to be notified so you don’t miss out!
To continue this journey and stay one step ahead of the threats, we encourage everyone from across the telecom landscape to get involved and up to speed. Learn what you can from the experiences of our enterprise counterparts, get the right partners and tools on board to protect your valuable assets and customers and get engaged now in the discussions and development of standards and regulations that will help shape the security scene of the future.
The authors would like to emphasize that any tools and companies mentioned in this blog post are referenced as examples only and should not be considered as recommendations or endorsements.
Gartner, How to Respond to the 2023 Cyberthreat Landscape, By Jeremy D'Hoinne, John Watts, Paul Furtado, Evgeny Mirolyubov, Ravisha Chugh, Akif Khan, Dionisio Zumerle, Katell Thielemann, Wam Voster, Andrew Walls, Deepti Gopal, Avivah Litan, Charlie Winckless, James Hoover, Nahim Fazal, Ant Allan, Pete Shoard, 11 April 2023
GARTNER is a registered trademark and service mark, and PEER INSIGHTS is a trademark and service mark, of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved.
Explore the other posts in our 5G security blog series.
Learn more about securing 5G networks in our Ericsson Mobility Report article.
Find out more about telecom security for a connected world.
Read more about GSMA baseline security controls.
Explore the 3GPP specification details below:
Like what you’re reading? Please sign up for email updates on your favorite topics.Subscribe now
At the Ericsson Blog, we provide insight to make complex ideas on technology, innovation and business simple.