Fans of the hit comic and TV series The Walking Dead might be pleased to see plenty of spinoff shows planned, despite the original series ending. As thrilling as it is to see hordes of zombies wreaking havoc on the last lines of defense of the human race, I can’t say the same sentiment is particularly appealing when discussing APIs.
The State of API Security Q1 2023 report from Salt Labs paints a grim picture of the climate surrounding API security in most enterprises, with “zombie APIs” a key factor in API-related cyberattacks surging by 400% compared to the previous six-month period. This is a harrowing consequence of widespread API use, especially as it relates to expanding an organization’s attack surface. It’s the new paydirt, the low-hanging fruit for attackers looking for quick wins that could pay off big time.
But let’s get back to zombies.
What is a zombie API, and why should they scare us?
Most companies have multiple business cases that necessitate the use of APIs, with software integrations essential to increasingly dispersed workforces. However, it’s not common knowledge that the average organization has over 15,000 in place – and if we’re talking large enterprises, make that over 25,000.
The problem is, though, that while these APIs might be in place, that’s quite different from them all being in active use. Often, once the initial project or use case for its existence 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 window of opportunity for a threat actor to crawl through and start accessing multiple parts of a system, usually undetected thanks to broken access control protocols. Now imagine there are hundreds - or thousands - of these, lying dormant and just waiting to be exploited. It’s the stuff of nightmares for a security leader, and a huge headache for ill-equipped developers to manage on their own.
APIs: Small, mighty, and inherently risky.
An API is a tiny, powerful software interface that truly accelerates our ability to innovate, connect our world, and share data in convenient, streamlined ways. They are indispensable, but we are kidding ourselves if we ignore the inherent risk that is part of their use. We’ve become accustomed to ignoring API security best practices in favor of seamless testing and functionality.
There have been some devastating, large-scale breaches in the past year alone that can be attributed to API security failures, with TechWire Asia estimating that API vulnerabilities cost businesses up to $75 billion annually. That is an enormous cost for successful exploits that rarely take a mastermind to execute if we’re being honest. If we insisted on prioritizing secure development in general - not to mention educating developers accordingly - there would be far fewer opportunities for attackers to make a mockery of enterprise systems.
As an industry, we have a lot more work to do in prioritizing API threat detection and remediation. Low visibility over APIs - including record-keeping and how they have been built - is a considerable concern, and it’s something that should be demanded as part of security best practices.
Navigating developer enablement and API security ownership.
There is a monolithic barrier blocking most organizations from achieving 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 we seek to control this expansive element of the attack surface.
One Traceable AI study saw respondents identify several separate departments as having ownership over API security: 38% claimed the CISO is ultimately responsible, while 25% responded that it should be the realm of the development team. Worryingly, 24% of those surveyed simply don’t know to whom responsibility should be assigned.
Typically, it is developers who spend the most time creating and maintaining APIs, and it makes sense that they should be in the best position to uphold security best practices from the implementation stage. It seems so obvious, yet it clearly hasn’t worked to date. However, before we write off the development cohort and throw it to the AppSec team as yet another plate for them to spin, let’s examine why it hasn’t worked:
● No training, no responsibility: Just like we wouldn’t expect an untrained nurse to be left in charge of patient rounds and administering medications, we can’t 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. Any 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. Remember: we have set developers up for failure, in a lot of ways, with inadequate courses and little emphasis on secure coding and configuration as a measure of quality.
● Assign ownership: Organizations with low-security maturity may not have a lot of intricate processes documented, but ultimately, every security process must have an ownership structure. With APIs such a potent threat, assigning this should be formalized and communicated from the executive level, not just an isolated meeting and a couple of wayward emails.
● Document APIs (and slay the zombies): With increasing emphasis on comprehensive and well-maintained Sofware 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 one.
Even an organization with the most stringent security measures can find itself undone by an API that is published and working outside of the company's security controls. It is more important than ever to ask where an API has come from, who maintains it, and what information it is accessing.
