Is Your API Security Vendor Making You Insecure?

Harish Nataraj
August 14, 2022 · 4 min read

Is your API security vendor making you insecure?
Buyer beware! The API Security solution you are considering investing $$$$ on will most likely increase your risk of a data breach — and lead to a compliance violation.
API Security Vendors Tout XDR-like Capabilities for APIs

The Whole Philosophy is Riddled with Pitfalls
API behavioral anomaly detection is modeled after Behavioral WAFs that F5 and Imperva developed for web applications as a precursor.
We will explore the typical vendor’s architecture and examine the various pitfalls that lead to increased security/compliance risks.

There are three main components in the typical API Security solution.
- Agents/Sidecar Proxies: Raw API traces are collected in production environments using a combination of in-app agents (RASP-like), sidecar proxies, and SDKs. These are sent to the PII Redacter running in the customer VPC.
- PII Redactor: The primary purpose of this component is to redact PII/PSI data present in raw API traces (via regex). Redacted API traces (sans PII) are then transmitted to the vendor’s cloud.
- Vendor Cloud: Redacted API traces are baseline, and anomaly detection algorithms identify potentially malicious API activity. Security analysts review potentially malicious activities for further action (block the threat actor, file a vulnerability report, etc.)
Pitfall 1 — Instrumentation is Not Bulletproof

Collection of API traffic is done via in-app agents and sidecar proxies. Unlike host-level (always on) security instrumentation, the agents/sidecars can easily be disabled by development teams to facilitate debugging, etc.
Since API anomaly detection depends on the proper collection of API traffic, there is no strong guarantee that the solution will always work.
Pitfall 2 — Does Not Scale in High Traffic Environments

Unlike XDR solutions that rely on a few high-quality signals (that drive anomaly detection), API anomaly detection requires the entire request/response payload of all API calls (north-south and east-west).
This makes sampling of API traffic a nonstarter, leading to scalability issues in high-traffic environments.
Pitfall 3— High Risk of Compliance Violations (PII Leakage)

You will almost certainly leak your PII/PSI data into the vendor’s cloud. This is a compliance nightmare waiting to happen!
Vendors will claim that all PII is redacted before sending API traces to their cloud. PII redaction is on a best-effort basis via the use of regular expressions.
It is tough to guarantee that PII data will not leak into the vendor cloud. This is even harder when sensitive data is of custom formats.
Pitfall 4— Data Redaction Impairs Detection Capabilities

Pitfall 5— Costs Grow Linearly with API Traffic

Pricing is based on the amount of API traffic being processed. This makes the costs exorbitantly high. In addition, you will need to bear the egress networking costs in sending API traces to the vendor’s cloud.
Pitfall 6— On-Premises Solutions — Hard to Manage

Some vendors offer an on-premises solution to circumvent data privacy and compliance issues. Modern anomaly detection platforms are complex and require dedicated staff to manage and maintain SLAs.
API Security Needs Reimagination
What is currently being touted as API security is an evolution of the behavioral WAF with added protection for APIs. Gartner defines this evolved product category as WAAP.
Dr. Chase Cunningham (aka Dr. Zero Trust) wrote an excellent article titled — WAF Must Die Like the Password and VPNs.
“Managing WAF deployments are complex and time-consuming, requiring an average of 2.5 security administrators who spend 45 hours per week processing WAF alerts ….”