Harish Nataraj
August 14, 2022 · 4 min read
.svg)
.svg)
Like NDR, XDR, and UEBA security solutions, vendors baseline API behavior in production environments and then detect behavioral anomalies that indicate malicious API activity.
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.
1. 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.
2. 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.
3. 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.)
Instrumentation can be easily disabled.
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.
Not scalable 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.
Compliance and privacy violations
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.
If the threat is embedded in the redacted JSON field, anomaly detection will be impaired, and the threat will not be detected.
Costs grow linearly with your 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.
On-prem is quite hard to manage and maintain SLAs.
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 ….”
Dr. Cunningham advocates a declarative and positive security model for securing APIs. Stay tuned for more information on how brownfield environments with many legacy APIs can transition to a positive security model with zero trust underpinnings
.png){kind=logo}
.svg)
