APIs are the cornerstone of modern software, yet many organizations don’t know what they’re dealing with when it comes to the APIs they create and consume.
That’s a problem, said Jessica Marie, product marketing manager and security evangelist at Traceable AI, during “API Catalog: The First Step in Protecting your APIs,” a presentation at the DevOps Connect virtual conference: 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 outward facing or inward facing?” Marie asked. simply don’t have visibility into how many APIs they have, where those APIs are located, and what those APIs are actually doing, which brings a huge amount of risk to the organization.”
Marie’s logic goes something like this: software has eaten the world. APIs ate software. Because the business is API-based software, to protect the business, IT needs to know what’s happening with the APIs going in and out of it. And it 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 starts with the ability to automatically catalog and track changes to those APIs, as well as their distributed interactions in real time.”
Security issues require more than simple API discovery; 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 across multiple clouds, and they’re all growing at a rapid pace.”
Security issues created by APIs
There are several reasons why APIs deserve a second look when it comes to security, according to Marie.
First, APIs evolve rapidly, in part thanks to development teams using multiple tools to rapidly build and update APIs. Practices such as continuous integration and continuous deployment or delivery (CI/CD) create frequent API changes, she said. This means organizations aren’t always able to see unknown or phantom APIs released to production, or even APIs that are updated without notifying the security team.
“These frequent API updates can lead to version and documentation issues,” she warned. “Beyond that, we all know that APIs are prone to fraud and malicious behavior.”
Internal APIs should be monitored for compromise, but organizations should also monitor external APIs and validate those for trust, she added. There have been examples of APIs being used to allow attackers to access critical infrastructure, she added.
API gateways, sidecar proxies and ingress controllers are not enough to handle the proliferation of intra-cluster API architecture, she argued.
Second, APIs are used to transmit data, and often sensitive data. Data exposure is listed as one of the top threats to API traffic by the Open Web Application Security Project (OWASP), Marie said.
“The increase in the number of APIs, along with the increase in API traffic, makes this a huge problem for security and GRC (governance, risk, and compliance) teams to address, like yesterday,” he said. she declared. “So knowing the flow of data and understanding your overall security posture is very important.”
3 steps to catalog APIs
First, start with a solution that can be that single source of truth that tracks all APIs and provides proper auto-discovery, versioning, and documentation, Marie advised. This should help you assess API-to-API connectivity and ensure uniform API reliability monitoring, she added.
“You need to have an accurate inventory of your web assets that belong to the organization and protect them accordingly,” she said. “You should automatically discover all your API endpoints [and] group your APIs by application service domains, so [that] your security teams can analyze information and make better security decisions.
However, this discovery process is easier suggested than accomplished, as there are many places APIs can be deployed, from on-premises deployments to hybrid deployments to cloud deployments. Microservices architecture also complicates knowledge of APIs because it makes applications highly distributed, she added. Finally, agile releases with multiple releases per week complicate the picture, she said.
Once APIs are discovered, organizations should categorize those APIs 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 automatically generate risk scores for APIs, he said. That’s one thing that separates an API catalog from an API discovery tool, she added – API discovery tools usually don’t do this or if they do, it has 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 assess the vulnerability of endpoints using your business logic. This is, again, a non-negotiable ability.
By increasing API risk, organizations can also prioritize and then mitigate those risks, she added.
An API catalog will also benefit a broader cross-section of the IT organization, from security to DevOps to compliance, by enabling them to address API security concerns, she said. For DevOps, that means making sure their CI/CD integrations allow them to address security issues early in production and non-production environments, she said.
Third, use an open API specification, she said. An open standard allows producers and consumers of APIs to communicate in the same language, she added. Open specifications allow the organization to answer questions such as whether APIs are used securely as intended by the developer, and do APIs expose unknown parameters? Open specifications are also essential for portability between security tools, she explained.
“You will immediately have that single source of truth that you need that benefits different teams and partners,” she said. “You will benefit from portability between different security tools and it will be much easier to identify which APIs are exposing sensitive data and where.”