Zombies have been a mainstay of the horror movie genre for many years, both delighting and terrifying loyal fans. However, while they might be appreciated on the big screen, they’re much less welcome when it comes to the security of application programming interfaces (APIs).
The challenge of ‘zombie APIs’ was highlighted in the recent State of API Security Q1, 2023 report1 issued by US-based Salt Labs. The report paints a grim picture of the climate surrounding API security in most enterprises, with ‘zombie APIs’ a key factor behind API-related cyberattacks surging by 400% compared with the previous six-month period.
This is a disturbing consequence of widespread API use, especially as it relates to expanding an organisation’s attack surface. It shows APIs are the new low-hanging fruit for attackers looking for quick wins.
The Rise of Zombie APIs
Most companies have multiple business cases that require the use of APIs, with software integrations increasingly essential for dispersed workforces. However, it’s not widely known that the average organization has more than 15,000 in place. In large enterprises, the number can top 25,000.
The problem is that, while these APIs might be in place, that’s quite different from them all being in active use. Often, once an initial project or use case has reached its conclusion, the API might be forgotten about, forever banished to the background.
This wouldn’t be an issue except that they are, by design, configured to be very chatty with other applications and often left wide open – from an authentication perspective – for functionality and ease of use.
If an obsolete (or, zombie) API is not properly decommissioned, it’s potentially a gap through which a cybercriminal can gain access to an organisation’s IT infrastructure. If there are hundreds – or even thousands – of these APIs lying dormant it becomes a huge headache for ill-equipped developers to manage on their own.
Barriers to API Security
Within many organisations, there is a monolithic barrier blocking better API security outcomes, and that is the distinct lack of ownership surrounding them. They are a perpetual hot potato, tossed between development teams and security personnel, and this cannot continue if better control is to be achieved.
According to a recent study2 by Traceable AI, respondents identified several different departments that potentially had ownership of API security. Of those surveyed, 38% claimed the CISO is ultimately responsible, while 25% said it should be the realm of the development team. Worryingly, 24% of those surveyed simply didn’t know to whom responsibility should be assigned.
Typically, it is developers who spend the most time creating and maintaining APIs. Therefore, it makes sense that they should be in the best position to uphold security best practices from the implementation stage.
However, this clearly hasn’t worked to date for a number of different reasons. These include:
A Lack of Training
It’s unrealistic to expect developers with little exposure to API security, or assessable levels of overall security education, to meaningfully take control of API security best practices. They need to be enabled in a way that makes sense in their world, with the tools and agile learning pathways that actually result in vulnerability reduction where it is needed most. Upskilling opportunities should be worked into their schedule with efficiency, adequate time allocated and, ideally, a hyper-relevant microlearning approach that results in contextual
awareness. We need to do more to get them to care about security, and work towards repairing what is often a fraught relationship with the AppSec team.
Poor Ownership Structures
Organisations with a low-security maturity may not have a lot of intricate processes documented. However, ultimately, every security process must have an ownership structure. With APIs such a potent threat, assigning this should be formalised and communicated from the executive level, not just an isolated meeting and a couple of wayward emails.
A Lack of Documentation
With an increasing emphasis on comprehensive and well-maintained Software Bill of Materials (SBOMs) inside every enterprise, any APIs in use should be documented and, when no longer needed, adequately decommissioned. We cannot expect even a mature, security-skilled development team to contend with thousands of zombie APIs and blame them if a threat actor takes advantage of them.
APIs will remain an important resource for organisations of all sizes. Those that keep security top of mind throughout their lifecycle will be best placed to gain value without increasing risks.
References
1 https://salt.security/api-security-trends
2 https://www.helpnetsecurity.com/2023/05/23/api-security-concern/
