I’ve Got 99 Problems and API Visibility Ain’t One of ‘Em

by Subbu Iyer on July 13, 2020

Getting a handle on API Proliferation for the benefit of the broader organization

API proliferation is an issue we hear about from our enterprise customers more and more. For security teams, this is a real problem. Without visibility and access to the APIs developed and deployed across the organization, it is impossible to ensure the security and privacy of the data communicated through the APIs.

Like most things in business, the use of APIs started small and was relatively manageable. I’m guessing there are spreadsheets in every organization’s SharePoint or Google Drive instance tracking the APIs implemented. But with the number of API growing fast and updates frequently happening, tracking eventually goes by the wayside.

How did we end up with so many APIs?

Many APIs start with targeted problem statements of exposing certain business functionality to their target audiences. For example, a product team might expose a few targeted endpoints to another internal team for certain business functionality, like fetching information about product inventory or pricing. Soon after, a business need will emerge to avail the same functionality externally as well, such as from a mobile app or from a business partner app. Then many business partners express the need to access the same API, and soon the API is converted to a formal OpenAPI specification exposed to all interested clients. So, what started off as a tactical API effort expands organically to meet the needs of several internal and external stakeholders.

Now imagine this process repeating across multiple product teams, and you suddenly have an API proliferation problem that is amplified at enterprise scale. When multiple teams are creating APIs for their individual needs, functionality often tends to get overlapped across APIs published from multiple teams. Most common reasons for this are the following:

Developers don’t know what already exists, so they write new APIs. Even in small organizations, and especially in large ones, it’s a challenge to keep up with all of the new APIs and technologies implemented. Without an easy way to catalog APIs and share that information across the organization and with partners, most developers will assume that the API doesn’t exist and will write a new one to complete their project. Unfortunately, without a process for cataloging and tracking API management, many shadow APIs end up in use without clarity about who’s managing them or ensuring their security and compliance.
Developers don’t want to (or can’t) fix what’s broken, so they write new APIs. When security uncovers vulnerabilities or bugs in APIs, a developer might decide that it’s too hard to work with what they’ve got, and their best course of action is to start from scratch. In some cases, maybe in many cases, this is the absolute right thing to do. The problems arise when the old APIs aren’t appropriately deprecated, and the insecure API is allowed to continue to exist and pose a risk to the organization.
Developers don’t want to relinquish control, so they write new APIs. While we were all taught at a young age that we should share everything, some still have a hard time with this notion. In an effort not to lose control over the API, or perhaps to avoid communicating with others, some developers will choose to write their version of an API to ensure they can make all the decisions about the specification, parameters, headers, and documentation. The result is that the enterprise ends up with redundant APIs – possibly with conflicting implementations (e.g., one is on gRPC, another is REST), or overlapping functionality.

To get a handle on your API landscape and stop unnecessary API proliferation organizations must implement a process for API management and security. Even small organizations with just dozens of APIs in use (and especially large organizations with thousands) can benefit from automated runtime discovery of its APIs. Cequence has built an enterprise security product called API Sentinel, which can automate the API discovery process for you and delivers critical capabilities needed to understand your API security posture, including:

Sponsorships Available

Runtime API Catalog: Automatic discovery of all your APIs, including those you’ve published knowingly to 3rd parties and shadow APIs. API Sentinel integrates with your existing API Gateway and proxy deployments to rapidly provide this visibility.
API Usage Analysis: Analysis of the usage of each API endpoint, including the countries, IP Addresses, and organizations from where usage is detected. Included are insights into headers, parameters, and response codes found in real-time usage, available with time-based filtering capability.
Continuous Risk Scoring: A dynamic assessment of each endpoint’s risk posture, determined based on multiple factors, including the strength of access control mechanism used, detection of sensitive PCI or PII data, unencrypted communication, or non-conformance to the published OpenAPI definition.
Shadow API Discovery: API Sentinel uncovers shadow APIs — those published out of process — and the usage of hidden methods, headers, parameters or response codes.

Having the ability to catalog and share APIs across teams will help reduce the overhead of API proliferation across your dev, ops, security, and compliance teams. Of all the challenges you’ve got in your work life, getting visibility into your API landscape doesn’t need to be one of the problems you’re juggling.

If you’d like to get a complete API catalog of your own, get in touch and we’ll get you started.

The post I’ve Got 99 Problems and API Visibility Ain’t One of ‘Em appeared first on Cequence.