Telecoms API security: the good, the bad, and the uglyTelecoms API security: the good, the bad, and the ugly

Application programming interfaces (APIs) are a set of tools and rules that allow access and use of platform resources, enabling applications, services, and other support tasks to be performed. In layperson’s words, as pieces of software they allow apps and services to interact and talk to each other.

Advancements in network and API exposure are further opening telecom networks to developers and third-parties. This provides them with information at the network level and enables different systems to interact and share data and functionalities without the need for sharing software codes.

But while industry initiatives such as CAMARA – the open-source API project driven by the Linux Foundation in collaboration with the GSMA – are more recent programmes driving network and API exposure, APIs have long been part of telecom infrastructures as interfaces for telcos to provide a host of microservices and support to their customers.

For instance, in telecom BSS (business support systems), customer and service management APIs enable telecom operators to activate services, bill customers, and provide payment support.

Today, large organisations are likely hosting and using hundreds, if not thousands, of their own and third-party APIs for both their internal and external microservices. From a security perspective, this increased API dependence makes the attack surface significantly more expansive.

According to a report by Edward Amoroso, CEO at TAG, “An important consideration in the context of API security for telecoms is the degree to which their infrastructure has shifted toward a more software-defined approach.” In the 5G era, this highly software-defined architecture gives further precedent to the use of APIs for telecom operators to interact with their customers and the wider telecom infrastructure including other telcos and cloud and SaaS providers.

Experts also argue that APIs are generally low hanging fruit for hackers’ picking. Targeting API endpoints opens access to resources, data manipulation, launch of automated attacks such as Distributed Denial of Service (DDoS) attacks against companies, and disruption of service operations causing downtime.

Against this background, and with hackers increasingly and specifically targeting the industry (the second most targeted industry by cyberattacks), API security in telecoms is rightly growing in significance.

Key API security risks

Data breaches are a common API security risk

Hackers can gain access to user accounts and their sensitive data, potentially enabling unauthorised purchases and theft of personal information, leaving organisations and their customers vulnerable to fraud.

To be able to serve their customers, telecom organisations hold sensitive information, including personal identifiable information (PII; e.g. full name, address, date of birth, passport details, etc.), and other information such as location data or billing information. Such data is typically protected under data and privacy acts such as the EU’s GDPR, which has been adopted beyond the borders of the union. Security breaches involving customer data are therefore also a regulatory compliance issue.

Network level APIs create additional layer of security risk

With API and network exposure being increasingly touted to help monetise 5G services, exposing network APIs is gaining traction among service providers. These give the developer community easy and direct access to advanced 5G network capabilities (including locations, connectivity, and other sensitive network insights) to improve and innovate. 

But the same benefits that network APIs can provide developers could work against a telco. “The implications of a network API breach are varied and depend entirely on the API which is subverted. As the use cases for network APIs expand, including a greater degree of network visibility, network control, and network security use cases than ever before, so too do the range of potential impacts of a breach.” explains Georgia Cooke, digital security research analyst at ABI Research.

In addition to the risks of PII exposure by APIs handling customer data, other APIs control varying features across the network, adds Cooke: “Others may control security features – the exploitation or disabling of which could result in the enablement of much more far ranging attacks.

“We are at the early stages of API penetration through the full network, particularly if APIs are the mechanism of choice to enable AI tools, so the implications of an API breach are expanding quickly.

“If an attacker is able to inject themselves into the design or implementation of an API, the implications could be further ranging still, with the potential to include harmful behaviours affecting network availability or data confidentiality in APIs – particularly if their behaviour once in production is inadequately monitored.”

Adversaries may use telcos as a ‘gateway’ into other industries

As CSPs also typically have a significantly large customer base, made up of both individuals and enterprises, the potential cyberattack surface further multiplies.

Serving many B2B customers in other industries with connectivity and related services, telcos can act as a gateway for an attackers. This means an attack against a telecom operator may open Pandora’s box to many other organisations across a host of industries through the APIs that connect the CSP with its customers, as illustrated by the figure below.

Source: TAG Infosphere Inc

Security risks are further compounded by human errors, lack of awareness, and the use of third-party APIs

Some industry experts believe APIs to constitute a cyber nightmare for operators. Others state “Many CSPs don’t even know they have exposed APIs within their infrastructure.” The 2022 Optus data breach case (discussed further below) exemplifies this point on human error exactly.

As Cooke flags "The weak links are, as throughout the security industry, frequently a result of human error. Misconfiguration, poor or ignored API security policy, and simple mistakes such as failing to disable test API access are often the source of easy access. These issues will only become more exploitable as attackers automate further, supported by AI, the reconnaissance phase of attacks, allowing them to identify these incidental vulnerabilities."

Organisations also often rely on third-party APIs to provide access and services and to interact with their customers. In that, APIs are designed to not only communicate with other APIs internal to an organisation but also externally (e.g. a telco billing related API may invoke a banking authentication API customer payment purposes).

This means, beyond the known risks of first-party APIs, risks are further heightened when third-party APIs are invoked, as explained by Omdia Cybersecurity Senior Principal Analyst Rik Turner. As the interaction chain between third-party APIs and yet other external APIs grows, further unknown risks are introduced, also referred to as the ‘unknown unknowns’ based on the Rumsfeld matrix.

APIs are also implemented for the interaction between CSPs and IoT developers making the latter yet another area that can further add to API security risks as IoT end points create many entry points for attackers.

Impact of an API breach on business and customers

One example of a cyber-attack due to an API breach concerns Australian telecom operator Optus in 2022. This breach has been the result of a coding error having gone unnoticed for four years, leaving an Optus target domain vulnerable for as long.

This domain’s function was to segregate certain content from a main domain which allowed authenticated Optus customers access their PII. The breach to such sensitive data resulted in the company suffering reputational as well as financial damages.

The breach exposed the records of more than 9.5 million former and current customers, equating to about 36% of the Australian population, according to the federal court filing. Of the exposed, at least 3.6 million were active subscribers. The breach led the parent company Singtel to write off US$1.48 billion of its Optus business in the financial year ending in March 2024.

Errors such as these in the Optus case seem to be so frequent that the industry sees them as deserving of their own title, namely ‘Zombie’ APIs.

Another example is T-Mobile US, whose latest API breach took place in November 2022 but was only discovered by the operator in the following January.  A poor API configuration is broadly being blamed for making the breach possible. There is little information on the type of API exploited or why it took the CSP such a long time to spot the breach. Another example of an API breach at T-Mobile US took place in 2017.

This breach exposed sensitive data of 37 million T-Mobile customers which led to several targeted campaigns towards unsuspecting subscribers. The operator agreed to a US$15.75 million settlement with the US federal communications commission (FCC) which covered the 2023 breach alongside two other T-Mobile data breaches.

There are also examples of telecom API flaws that get discovered by independent security researches who report the vulnerability to the telcos, such as in the Airtel India case from 2019. In this case customer data, including mobile number and IMEI numbers, of around 300 million Airtel customers was potentially exposed.

API breaches are not unique to telecoms and there are examples of such incidents also occurring in the wider technology sector, affecting tech giants such as Microsoft, Facebook, and Dell. But the telecom industry is a highly regulated industry and operators harvest a host of their customers’ sensitive data / PII, making the impact likely more consequential.

Forward looking thoughts and recommendations

While APIs have been the source of some large-scale breaches, if implemented well they can also act as security measures themselves. According to a GSMA report, the most prevalent use cases deployed among its Open Gateway initiative in the second half of 2024 have been focused on security measures, most prominently on anti-fraud. Especially for enterprise buyers, the report claims, security and anti-fraud are a priority.

Examples of such use cases include Singtel’s SingVerify which uses the API to enable an application to carry out an authentication process, and French operators Bouygues Telecom, Free, Orange, and SFR teaming up to launch two network APIs, namely KYC Match and SIM Swap.

But the GSMA also admits that the focus of its Open Gateway projects is shifting as deployments are beginning to branch out to other areas. The use of APIs for edge computing, other network related functions, and payments, it says, are also growing.

It is clear that API security should be a significant component of a telco’s overall network and service security. To avoid reputational and financial damage as well as regulatory and compliance breaches, it is imperative for CSPs to secure APIs, both those they create and use, and those they expose for developers and third-parties to use.

According to Cooke, "the [API] ecosystem has diverse stakeholders, and the potential returns could be considerable – but there are key security concerns which must be addressed early in the process."

Research and analyst house Omdia predicts telecom network API revenues to reach US$8.7 billion by 2029. Meanwhile, research and analyst firm ABI forecasts suggest that security-focused APIs alone could be worth more than $5 billion by 2028, totalling to more than the entire 5G security software market.

Further, organisations such as telecom operators use APIs cross-functionally, (i.e., several different divisions may use the same API) but accountability over those APIs make not necessarily be shared. This makes cross-functional planning strategies such as taking API ownership and ensuring effective communication across different departments even more important.

To that end, experts suggest that API security needs to go beyond just turning on transport-level encryption. As such, it is recommended that API security should be treated as a strategic effort spanning across several teams and technologies.

Among other advice from security experts is the maintenance of an API inventory as well as adherence to industry standards such as those offered by CAMARA and Open Gateway. The Open Web Application Security Project (OWASP) API Security Project is another effort in this space, compiling a list of top 10 API security risks.

Cooke adds that “Network operators should draw from the standard best practices applied in cyber, with the need for Zero Trust Network Architectures and robust, enforced policy in API usage and development.

“Rigorous CI/CD is not only best practice for quality software, but also an important aspect of security, with any potential vulnerabilities being patched quickly and the development deployment pipeline providing a natural security gate to prohibit the injection of malicious API behaviour.

“Finally, automated monitoring of APIs is essential to detect misconfiguration – such as APIs which have been left live, or connected unnecessarily to the internet – and misbehaviour – simply put, APIs should only be able to perform network functions required for their strategic purpose, and security analysts should be warned when they start doing things they shouldn’t – such as exfiltrating data or issuing suspicious requests.”

As we enter the second half of this decade and the second quarter of this century, perhaps these combined efforts will finally plug any weak links (including human errors) in operator and other internet-based organisations’ infrastructures, protect our sensitive data from devastating exposure, and allow us to fully embrace the network API opportunity.