Beyond the Edge: Complementing WAAP with Always-On API Security

To create effective API security policies, organizations must first uncover the full scope of their API estate and create a comprehensive inventory. 

One thing that sets API security apart from other security domains is that most security teams don’t have a complete understanding of the size and scope of the problem. APIs often originate from many different development teams within a typical organization. 

Although some organizations have attempted to consolidate these functions into centralized tools like API gateways, security teams are still consistently shocked by the amount of previously unknown APIs we discover for them.

This typically includes a blend of:

• Shadow APIs that may serve a legitimate purpose but were deployed outside of formal processes, often without appropriate security reviews and documentation

• Zombie APIs that are no longer being used but remain active as potential attack vectors

• Rogue APIs created by third-party developers who access the data through a backdoor without the knowledge or approval of the company that owns the data

In our experience, it's common that these unseen APIs represent approximately 40% of a typical organization’s overall API estate. This is an eye-opener for many security teams, and drives home the point that a sound API security strategy must include a method of discovering all API in use and a way of maintaining an up-to-date API inventory at all times. Only then will the security team be able to implement effective protections for all sanctioned APIs and to decommission APIs that should not be providing access to company resources.

WAAP platforms are security solutions that focus on distributed denial-of-service (DDoS) protection, bot management, web application firewall (WAF), and base API protection. Through tactics like DDoS mitigation and bot protection, they help organizations by:

• Safeguarding web apps and APIs from a range of cyberattacks, including DDoS attacks, cross-site scripting (XSS) attacks, and SQL injections

• Addressing the OWASP Top 10 web application security vulnerabilities

But, on their own, these platforms aren’t foolproof when it comes to API traffic authentication or modern API threats — meaning sensitive data remains vulnerable to other types of cyberattacks, including API data scraping.

Although data captured by WAAPs is a useful source of API activity information, it’s far from comprehensive. Rogue, shadow, and zombie APIs can easily bypass the WAAP or other tools like the API gateway. In addition, sanctioned APIs are often designed for internal use only and may not be implemented with protection from external cyberthreats in mind. Unfortunately, an internal API being accidentally exposed to the internet is an all too common occurrence.

Akamai API Security addresses this challenge by ingesting data from a wide range of possible sources, including WAAPs, content delivery network (CDN) infrastructure, API gateways, reverse proxies, cloud platforms, container/mesh orchestration tools, centralized log management systems, and more. This ensures that sanctioned and unsanctioned APIs are discovered and inventoried continuously in real time.

Another key reason that API security must extend beyond the WAAP is that API abuse is much harder to distinguish from legitimate use than other types of API threats. In many scenarios, a malicious API request and a legitimate API request, viewed individually by a WAAP, look nearly identical. In addition, the business logic and data accessible through APIs vary greatly from one application to the next, leaving WAAPs without the necessary context to detect many types of API security threats.

So, while WAAPs can detect and stop API threats with telltale characteristics, many more sophisticated API threats will likely blend in with the large volume of legitimate use and proceed undetected. This opens the door for potentially devastating attacks like Broken Object Level Authorization (BOLA), unauthenticated resource access attempts, abnormal JSON property, path parameter fuzzing attempts, impossible time travel, and API data scraping.

Akamai API Security fills this protection gap in two critical ways: contextualizing API activity and using behavioral analytics to detect API abuse.

Although the collection of comprehensive data about API activity is critical, it’s only the first step. The next challenge is to reveal the stories that are hiding within this data. This starts with identifying the entities involved — including the parties or systems that initiate the action, as well as the business processes that are accessible through APIs. 

Partners who are granted API access to certain systems are an example of a potential API actor entity, and API-accessible invoicing functionality is an example of a business process entity. Most organizations have countless examples of actors and business process entities. Identifying them and putting their activity in context makes it possible to distinguish between sanctioned and unsanctioned API use, even if the specific API requests look identical.

Once you’ve contextualized data about your API activity, the next step is analyzing it for signs of API abuse. Akamai API Security uses machine learning and behavioral analytics to:

• Create baselines of normal API use

• Detect anomalies that represent likely API abuse

Unlike a WAAP, which can only analyze very small samples of point-in-time API requests, Akamai API Security takes a much broader view. This makes it possible to spot API abuse and malicious traffic that would otherwise blend in with authorized activity.

For example, imagine that a hotel chain is granting travel booking sites API access to pricing and room availability information. Individual API requests for pricing from a booking site wouldn’t attract attention from a WAAP, since this is expected behavior. 

But if one travel booking site’s overall volume of pricing requests is orders of magnitude higher than all similar travel booking sites — and their own historical volume levels — this may indicate that the site is abusing their API access to exfiltrate data at scale and gain a competitive advantage.

From a WAAP’s perspective, all of these API requests are identical. But Akamai API Security can tell the difference by spotting the anomaly. Although this is a very simple example, it illustrates the power of context and visibility that extends beyond individual API requests.

Akamai API Security is already transforming how organizations understand and secure their API estates globally. The following are two notable examples.

One of Akamai’s existing CDN customers, a large European consumer electronics retailer, experienced a rapid expansion of API use without a centralized management and security strategy in place. APIs were implemented regularly by multiple development teams, often using multiple API gateways, creating an unwieldy level of API sprawl.

This presented a challenge for the single individual responsible for API security at the organization. They had no visibility into the full scope of the organization’s API use. And they had a limited ability to implement security controls for the APIs that they knew about.

Because the retailer was already operating on Akamai’s CDN infrastructure, we were able to activate Akamai API Security for their key applications with a few mouse clicks for a proof of concept. Soon after, we produced a contextualized inventory of their API estate. We also quickly detected some notable security issues in their API security posture and runtime activity, which they were able to act on immediately.

Based on these initial successes, the retailer proceeded to a full-scale deployment of Akamai API Security, and we’re now analyzing billions of API requests for them each month.

One of the largest credit unions in the United States made a strategic decision to implement an API-first strategy for their application infrastructure to achieve greater flexibility and scalability. But, as they began their journey, they realized they needed a continuous discovery and inventory management approach for their growing API estate. They purchased an analytics tool for this purpose, but found it to be unreliable and prone to false-positive alerts.

The organization already had an existing relationship with Akamai, so they decided to evaluate Akamai API Security to address this critical need. Akamai’s zero-touch implementation capabilities made it easy to collect data quickly, easily, and cost-effectively.

The Akamai team also worked alongside the customer to integrate Akamai API Security with other core elements of their API management and security stack, including their MuleSoft API gateway and Splunk security information and event management (SIEM) platform. During this process, Akamai took a number of steps to set the credit union up for success, including:

• Expertly tuning threat detection and implementing automation of custom protections to minimize false positives 

• Customizing naming conventions to match their internal approach

• Incorporating metadata from MuleSoft to simplify threat response and troubleshooting

• Directing information-rich API security alerts directly into their Splunk implementation

Based on the success of this collaboration, the credit union adopted Akamai API Security as its ongoing model for API discovery and threat detection.