By Dan Hopkins, VP of Engineering at StackHawk
IT modernization and digital transformation initiatives, combined with faster software deployment lifecycles, has caused an exponential increase in the size and scale of API ecosystems within organizations. Designed to rapidly and seamlessly connect consumers and businesses to vital data and services, APIs power modern enterprises and applications. APIs are constantly in action, working in the background for when consumers finally book that dream vacation or place an online takeout order after a long workday. With API usage so widespread, touching every industry, and the vast treasure troves of sensitive data they boast access to, it comes as no surprise that cyber criminals are increasingly exploiting and abusing APIs to execute malicious attacks.
The velocity and scale of API attacks has caused many to question the strength of their API security posture and deeply analyze where most API-centric risks persist. That brings us to Zombies, Zombie APIs that is. If the name alone doesn’t initially spark fear, Zombie APIs are APIs that have become abandoned, outdated or forgotten by an organization. Similar to a Zombie who revives from the dead in a horror movie, Zombie APIs should be deceased but continue to lurk in the shadows within corporate environments. Recent research from Salt Security revealed that 54% of security leaders categorize Zombie APIs as their greatest concern when it comes to API security. Up from 42% in the previous report.
As Zombie APIs are essentially forgotten and out of mind, there is no regular patching or updates being made in either a functional or security capacity. Therefore, Zombie APIs boast the power to become an incremental security risk. They are removed from API documentation and security testing programs, leaving them to rot over time and expose new vulnerabilities.
While Zombie APIs pose significant threats to cyber resilience, there is one other great cause for concern within API security – the presence of Shadow APIs. Shadow APIs can be defined as third-party APIs that exist outside of an organization’s official API ecosystem, remaining invisible to most and void of security controls. Oftentimes, these types of APIs are created and deployed by well-meaning developers on a time crunch to meet business and application innovation demands. Despite no ill-intent from a developer, these unmanaged, non restricted APIs have the potential to cause severe vulnerabilities. Shadow APIs often fail to adhere to correct API governance standards, may not meet security best practices such as those outlined in the OWASP API Security Top 10, and may also expose sensitive data.
The presence of Zombie and Shadow APIs remains widespread across organizations, which in turn creates many opportunities for sly and sneaky bad actors to execute an attack. The root cause of both is simple: Broken and siloed communication between developers and security teams. Developers and engineering teams are rapidly creating APIs to keep pace with innovation, and security personnel are willfully trying to protect and manage them. But both play a significant role in securing the API ecosystem. Particularly in relation to API documentation and inventory management. As the saying goes, “you cannot protect what you cannot see”.
Developers and engineers not only have a duty of care to keep a robust catalog of the APIs created and deployed, but also to brief the appropriate parties about deprecated APIs no longer being utilized. This intel should be continually shared with security teams to ensure API inventories remain complete, make certain appropriate patching and testing initiatives are carried out and allow the complete removal of expired APIs.
Mitigating the volume of Zombie APIs requires developer and security teams to liaise with one another to comprehensively define and articulate robust API retirement policies and procedures and determine who is responsible for executing such activity. This practice will ensure that inactive APIs are formally taken out of an ecosystem and avoid future attacker retaliation.
Similarly, alleviating the threat of Shadow APIs also calls for deep synergy and collaboration amongst teams and strong DevSecOps practices. Security teams must work with engineers and developers to define and enforce governance policies for APIs being created. These policies should clearly describe which individuals can create new APIs, how they should be designed, deployed and utilized, and offer insight into the required testing mechanisms new APIs must undergo prior to being pushed into production.
The existence and proliferation of Zombie and Shadow APIs ultimately comes down to two factors: broken communication and human error. Breaking down the barriers of communication and solid collaboration amongst developers and security teams will significantly improve API documentation, inventory management and help enforce security best practices. Without it, organizations will continue to be plagued with API risk, and remain unsuspecting of possible threats and unprotected against exploits.
About the Author
Dan Hopkins is VP of Engineering at StackHawk. He has been a software engineer for 20 years, working at high growth startups such as VictorOps and LivingSocial and at large high-tech companies such as Splunk. For the last 10 years, he has focused on building tools for progressive engineering teams adopting DevOps and DevSecOps practices.
