Apigee Sense Protection: Act on Threats to Your APIs
Our customers expose critical business function via APIs, so API security is a significant concern. They want the ability to take action without delay when APIs are abused. Apigee Sense collects, analyzes, detects, and provides a dashboard showing abuse of APIs managed using Apigee Edge.
The Sense Protection feature completes the “CAVA” (collect, analyze, visualize, and act) lifecycle. It enables an Apigee Sense customer to act on detected abuse and to selectively stop abusive API traffic.
Why did we do this?
The protection feature represents significant progress within the Apigee API platform, and an important step in our effort to deliver data-driven API management. It shortens the lifespan of an attack and decreases the operational cost of dealing with one. Consequently, it reduces any economic incentive to mount automated attacks on APIs.
How did we do this?
As part of this feature, we added the ability to trap and shape API traffic to Apigee Edge. As a Sense customer, you’ll now see an “Act” button whenever an attack is detected. Clicking on it will bring you to a quick workflow that will enable you to block traffic from the identified attacker, and, if you choose, other similar bots.
Every API call passes through a pre-proxy Apigee Sense layer. The logic checks whether the call originates from a host that’s been blocked. If this is the case, then the rest of the chain is aborted and an HTTP 403 response is returned. Otherwise, the call continues on to the normal execution path.
In addition to blocking, we also offer the capability to flag API calls. A flagged call is passed on to the back-end system with an additional header field.
The challenge is in keeping the large blacklist across all the orgs that we service updated and current across our distributed API serving infrastructure. To ensure that we don’t add any significant latency to the API call path, this blacklist check has to be done in an entirely “local” way.
To do this, we cache (and actively refresh) a segment of the blacklist on every message processor. The choice of the segment is coordinated with the routing infrastructure so that each segment of the blacklist is available where it will be needed and only where it will be needed.
We have also built an internal service that maintains and serves the blacklist segments to the API gateway. It’s our intention that over time, this service will provide the additional context necessary for each API call. For example, it provides the state machine for slowly switching traffic from one version of logic to the next during a deployment cycle while continually monitoring availability data.
Our vision is that eventually a lot of system change and the context for managing API calls will become data-driven and be mediated by the services we’ve built to enable Sense and Sense Protection.
This means that Sense Protection activity takes place in a separate path, outside of the proxy handling workflow of Apigee Edge. The deployment for protection is independent of that of the API proxy. Therefore, any change to the API proxy doesn’t compromise the ability to act against any attacker, and a change to the protection logic will not change the essential behavior of the API proxy.
Finally, blocked traffic never hits critical logic in the API handling path and, nor does it cause any back-end load. Because of this, any customer with blocked robot traffic will see an improvement in performance both at the API and, more importantly, within their back-end systems due to the reduction in traffic that had been generated by those abusing the API.
Learn more about Apigee Sense. —Harish Deshmukh, Prithpal Bhogill, and Vibhor Sonpar contributed to this post.