Are You Haunted by Zombie, Shadow and Ghost APIs?

Beware The Ghoulish Offspring of API Sprawl

Halloween is not the only time Zombies, Shadows, and Ghosts come to life. Unbeknownst to many, these abominations live year round inside many organizations, haunting the most experienced application security professionals and threat hunters. You won’t find them lurking in closets, or basements, or under desks. Instead, they hide in plain sight as APIs in your infrastructure, quietly extending your attack surface, nestled in next to other published and exposed APIs, patiently waiting to be called upon by some black hat and wreak havoc.  

Before you go ahead and start lighting some sage, it is important to realize that the existence of these frightening API entities does not derive from a curse or supernatural phenomenon.  Zombie APIs, Shadow APIs, and Ghost APIs are byproducts of a larger, more terrifying challenge that enterprises are struggling to tackle today: API Sprawl.

As companies seek to maximize the business value associated with APIs, APIs have proliferated. Digital transformation initiatives, cloud migration, app modernization to API-first app architectures, partner enablement, and advancements in rapid continuous software deployment methods have fueled the high velocity, exponential growth of the number of APIs created and in use by organizations. API Sprawl manifests itself far and wide in an organization as a result of this rapid API production, which occurs across multiple teams, multiple technology platforms (legacy, Kubernetes, VMs, etc.), and multiple distributed infrastructures  (on-premise data centers, multiple public clouds, etc.). Unwanted and ghoulish API entities such as Zombies, Shadows, and Ghosts sprawl into existence, and become threats when organizations do not have proper API visibility, governance and lifecycle strategies in place.

Zombie APIs Linger as the Walking Dead

Simply put, a Zombie API is an exposed API or an API endpoint that has become abandoned, outdated or forgotten. At one point, the API served a purpose or function. However, that purpose or function may no longer be needed, or the API has been replaced/updated with a newer version, or moved to a different distributed infrastructure location. When an organization does not have proper controls in place around versioning, migrating, deprecating and sunsetting old APIs, those APIs may linger on to an everlasting undead existence – hence, the term Zombie.

Because they are essentially forgotten and out of mind, there is no ongoing patching or maintenance or updates being made in any functional or security capacity, and therefore the Zombie APIs become a security risk. In fact, Salt Security State of API Security research has shown Zombie APIs as the number one API security concern for organizations over the past four surveys.

Beware What Lurks in the API Shadows

A Shadow API is an exposed API or an API endpoint whose creation and deployment was done "under the radar."  These ominous APIs are sometimes published from the hollows of Shadow IT, and come to existence outside of an organization's official API governance, visibility, and security controls. There are a number of well-intended motivating factors on why a developer or app team would want to circumvent controls to deploy an API or endpoint more quickly (critical patch, time sensitive business driver, internal API now needed externally, etc.). Regardless of the motivation, the ending result typically takes the form of a Shadow API. Other times, in the absence of any adopted API strategy, these unwanted entities will naturally appear as developers have the ungated ability to publish APIs in any manner they choose.

Consequently, when API production evades standard design, scanning, testing, documentation, and inventory controls, they can pose a wide variety of security risks, including:

• The Shadow API may not have proper authentication and authorization gates in place.
• The Shadow API may be exposing sensitive data improperly.
• The Shadow API may not be adhering to best practices from a security standpoint, making it vulnerable to many of the OWASP API Security Top 10 attack threats.

Ghosts are Everywhere

Organizations don’t always write all of their own APIs. API Sprawl extends beyond in-house developed APIs. The notion of a Ghost API refers to 3rd party developed (or ghostwritten) APIs that are exposed and in use in production environments. These ghastly souls can be exposed anywhere: packaged applications (commercial and open-source), SaaS-based services, on-premise and cloud based infrastructure components (such as an admin API on a virtual appliance), and more.

Many organizations intentionally expose and rely on the use of 3rd party developed APIs in their extended infrastructure as part of their functional digital supply chains and daily infrastructure management. However, sometimes 3rd Party APIs get unintentionally exposed as part of a packaged application or appliance rollout.  In either case, organizations exert no influence over how the APIs are developed and must trust that outside developers followed API security best practices.

Moreover, because the 3rd party developed APIs are published outside the typical devops cycle that an internally developed API flushes through, they frequently have not been properly inventoried, governed, tested, monitored, and maintained. This poses a large array of security risks to an application and its underlying infrastructure.

Protect Yourself from the Horrors and Havoc of API Sprawl

A first step to slaying the Zombies, Shadows, and Ghosts of API Sprawl is to flush them out of hiding. Organizations must get visibility and security coverage into all APIs already running within their infrastructure today. Continuous API discovery guarantees that you have proper inventorying capability of all of your APIs in place to manage risk and exposure. Given the proliferation of API production across teams, technologies, and distributed infrastructures, manual processes no longer suffice when it comes to discovering all of the APIs that exist within a given organization. Additionally, API discovery should do more than just let you know that an API exists. You need to understand how it is structured, its usage, the types of data it ingests and exposes, and the security posture of the API (is it adhering to security best practices - encryption, authentication, data handling, etc.).

After they are discovered and their initial security posture understood, APIs should be monitored and protected with proper API runtime protection. This provides immediate protection to all known and previously unknown APIs. By monitoring APIs in runtime, organizations gain an understanding about normal API usage versus abnormal API usage behaviors in their environment, allowing them to quickly spot potential abuses. With these insights, you can more quickly spot attackers that are poking around for business logic holes and weak points in your APIs to attack. Only runtime protection, with accurate behavioral anomaly detection, can find the “low and slow” patterns of API attacks. To prevent these types of threats, organizations also need visibility over time. API abuse reconnaissance can take days, weeks, and even months.

Last but not least, revisit or implement an API governance strategy that standardizes how future APIs are built and deployed in your organization, including consideration to 3rd party developed APIs.  Any API lifecycle strategy should look to standardize as much as possible (such as an API Gateway) and include policies and procedures around API design, documentation, versioning, testing, deployment, operations, monitoring and security. To ensure no new unwanted spawning of Zombie and Shadow and Ghost APIs, a strict API Governance strategy must be in place to enforce controls over how and when an API gets deployed regardless of who developed it and why.

Zombie, Shadow, and Ghost APIs belong in the graveyard – not in your infrastructure where they can wreak havoc and become prey for cyber mischief. The Salt Security API Protection Platform provides the elixir you need to discover all of your APIs, build and maintain an accurate inventory, and continuously monitor APIs in runtime, so you can quickly spot and cast out potential cyber attackers. To learn about our award-winning API security platform and keep your environment phantom-free, contact Salt Security, or sign up for a personalized demo.