3 Ways API Catalogs Can Help DevOps Security
APIs are the building block of modern software, and yet, many organizations don’t know what they’re dealing when it comes to the APIs they create and consume.
That’s a problem, said Jessica Marie, product marketing leader and security evangelist at Traceable AI, during ”API Catalog: The First Step in Protecting your APIs,” a presentation at the virtual conference DevOps Connect: DevSecOps Con sponsored by TechStrong.
“Do you know how many APIs you have in your organization? Do you know which APIs have been recently introduced, and which APIs are external facing versus internal facing?” Marie asked. “Most companies simply don’t have visibility into how many APIs they have, where those APIs reside, and what those APIs are actually doing and this brings a huge amount of risk to the organization.”
Marie’s logic goes something like this: Software ate the world. APIs ate the software. Because business is API-based software, to protect the business IT has to know what’s going on with the APIs that flow in and out of it. And that starts with API catalogs.
“To secure our software business, we need to secure the APIs to which software is accessed, both internally and externally,” Marie said. “API security begins with being able to automatically catalog and track changes to those APIs, and their distributed interactions in real time.”
Security concerns requires more than just discovering APIs; securing APIs requires an actionable catalog of APIs.
“Basically, you need an API catalog, because APIs connect everything — literally everything,” she said. “You have thousands of APIs running on multiple clouds, and they’re all growing at a rapid pace.”
The Security Problems Created by APIs
There are several reasons why APIs deserve a second look when it comes to security concerns, according to Marie.
First, APIs are evolving rapidly, thanks in part to development teams that use multiple tools to rapidly build and update APIs. Practices like continuous integration and continuous deployment or delivery (CI/CD) create frequent changes to APIs, she said. That means organizations are not able to always see unknown or shadow APIs being released in production, or even APIs that are being updated without informing the security team.
“Those frequent updates to APIs can result in versioning and documentation issues,” she cautioned. “Beyond that, we all know that APIs are prone to fraud and malicious behavior.”
Internal APIs should be monitored against compromise, but organizations should also be monitoring external APIs and validating those for trust, she added. There have been examples of APIs being used to give attackers access to critical infrastructures, she added.
API gateways, sidecar proxies and Ingress controllers aren’t sufficient when it comes to managing intra-cluster API architecture sprawl, she contended.
Second, APIs are being used to transmit data, and often sensitive data. Data exposure is listed as one of the top threats for API traffic by the Open Web Application Security Project (OWASP), Marie said.
“The increase in the number of APIs, as well as the increase in API traffic, make this a huge problem that security and GRC (governance, risk and compliance) teams need to solve, like yesterday,”she said. “So it’s very important to know the data flow and to understand your overall security posture.”
3 Steps to Cataloging APIs
First, start with a solution that can be that single source of truth that tracks all APIs, and provides automatic discovery, proper versioning and documentation, advised Marie. It should help you assess API-to-API connectivity and have uniform monitoring of API reliability, she added.
“You have to have an accurate inventory of your web assets that belong to the organization and protect them accordingly,” she said. ”You need to automatically discover all of your API endpoints [and] group your APIs by apps services domains, so [that] your security teams can analyze information and make better security decisions.”
That discovery process is easier suggested than accomplished, however, because there are so many places APIs might be deployed, from on-premise, to hybrid deployments to cloud deployments. Microservices architecture also complicate API awareness, because it’s made applications highly distributed, she added. Finally, agile releases with multiple releases per week complicate the picture, she said.
After the APIs are discovered, organizations should classify those APIs either as external, internal or third-party. The API catalog should also automate the process of cataloging new APIs and updates to existing APIs.
Second, the API catalog should auto-generate risk scores for APIs,s he said. That’s one thing that separates an API catalog from an API discovery tool, she added — API discovery tools typically don’t do that or if they do, it tends to be a more manual process, she said.
“Risk scoring is a non-negotiable capability,” she said. “It’s important to have the ability to generate risk scores that proactively identify vulnerable APIs, those API risk scores that evaluates the vulnerability of AP’s using your business logic. This is, again, non-negotiable capability.”
By elevating API risks, organizations can also prioritize and then mitigate those risks, she added.
An API catalog will also benefit a broader swatch of the IT organization, from security to DevOps to compliance, by empowering them to respond to API security issues, she said. For DevOps, that means ensuring their CI/CD integrations allow them to address security issues early in the production and non-production environments, she said.
Third, use an an open API specification, she said. An open standard lets producers and consumers of APIs communicate in the same language, she added. Open specs allow the organization to answer questions such as whether APIs being consumed securely as the developer intended, and are the APIs exposing any unknown parameters? Open specs are also key to portability between security tools, she explained.
“You will immediately have that single source of truth that you need, and which benefits different teams and partners,” she said. “You’ll have portability between different security tools and it’s much easier to identify which APIs expose sensitive data and where.”
