Protecting APIs from Cyber Attack
First mention of an application programming interface (API) appeared in Roy Fielding’s now-famous PhD thesis at UC Irvine in 2000. Soon after, we all watched as Salesforce, eBay, and later Amazon, took advantage of the new construct to extend the scale, interoperability, and automation of their fledgling websites. (This is a humbling narrative, by the way, for those of us who’ve completed doctoral thesis projects noticed by no one.)
Before APIs, programs communicated with other programs through a maze of inter-process communication (IPC), shared memory, and other ad hoc means. Today, the modern API powers introduction of new capabilities and expansion in social media and across the web. One cannot underestimate the transformative effect of data and functionality being exposed by one group of programmers to another through standard service interfaces.
With all new ideas, however, comes the usual security issues. Different types of API abuse have emerged including data theft, fraud, account takeovers, and denial of service. These attacks generally occur by exposing business logic flaws due to software bugs. Every new or modified feature thus introduces a potentially new attack vector. Since services are being modified and enhanced continuously, the API attack surface becomes infinite.
To learn more about this emerging challenge of handling API security risk, I spent some productive time with one of the experts working in this area. Simon Sorrell from imVision Technologies was kind enough to take me through the relevant technical and platform issues related to modern API usage, and the attendant cyber security risks. Here’s a summary of what I learned:
To protect an API requires three functional capabilities: First, basic visibility into the APIs within the domain is required. That is, you can’t protect what you can’t see. Second, advanced detection capabilities are required to identify abnormal functional behaviors or abnormal consumption patterns. Finally, preventive controls are required to support the need for corrective action against abnormal API transactions in real time.
The imVision platform supports these capabilities via their API Anomaly Management Platform (API AMP). “Our platform currently monitors over ten billion API calls per month for over seven hundred business partners (API consumers) covering over one hundred million end-users,” Sorrell said. “This coverage, combined with our advanced technology, gives us the reach necessary to support security protections that scale across different API attack vectors.”
The API AMP platform includes support for security discovery and risk scoring of API endpoints to provide visibility. It also includes detection of API anomalies which impact API functionality or consumption patterns, using machine learning to detect API attacks with zero configuration. API AMP can be run in monitoring mode or with auto protection enabled. “Our goal is to ensure that early detection and prevention of API-based attacks will allow enterprise teams to reduce their overall cyber security risk,” Sorrell explained.
From a TAG Cyber analysis perspective, note first that APIs today are managed by various management systems provided by a long list of vendors such as IBM (API Connect), Google (Apigee), Salesforce (Mulesoft), and Amazon (API Gateway), as well as some open source platforms like KONG. One would expect platforms such as API AMP to be soon offered in the context of an integrated package with API Management.
More generally, it’s good to see increased emphasis from commercial vendors on securing APIs. Early application security efforts appeared to have a blind spot to this aspect of web functionality, which perhaps helps to explain the frequency of data theft across so many industry sectors. With capable vendors now offering solutions, one would expect to see the incidence of such familiar breaches start to recede – at least, one would hope.
I’d recommend checking out what Sorrell and his team have to offer. They are spread out geographically across Tel Aviv, Dallas, and Hong Kong, which doesn’t seem like much fun to manage – but which does increase the likelihood that you can arrange a face-to-face with one of the principals. As always, please be sure to share back with all of us what you learn after you contact the company for a briefing. I look forward to hearing from you.
Ed... interesting background and current uses of API’s....I’m really dating myself .... but even though first mentioned in the PhD thesis you referenced.....first uses of API’s goes back to the late 1960’s and early 1970’s when we were forced to design programs and use system overlay programs and libraries and other system resources due primarily to lack of memory resources.