The 540% increase in the number of API-related security vulnerabilities recorded in the CVE (common vulnerabilities and exposures) database (https://cve.mitre.org/) between 2015 and 2021 compared to an increase of 280% of overall vulnerabilities in the same timeframe demonstrates the importance of tightening API security and governance. The topic chart generated from the 631 API-related CVE records from 2021 shows unauthenticated access for hackers (1) and the subsequent remote retrieval of sensitive information (3) through externally available REST APIs (2) as critical topics. Older API versions that were deprecated but never turned off constitute another popular entry point for unauthorized access to enterprise systems (4) including file servers (6).
Microservices and Kubernetes As the Driving Factor
The rapid adoption of distributed cloud native applications, typically on top of the Kubernetes container orchestration platform, was the driving factor behind these API challenges. Unsurprisingly, we find “API”, right at the center of the topic map of all 2021 CVE records, as cloud native applications consist of numerous loosely coupled microservices, all communicating through their own APIs to access the internal and external code functions and data elements required to provide a seamless user experience. This new distributed architecture has caused a tremendous increase in network traffic between individual containerized microservices that could be located within the same or separate Kubernetes clusters in the data center or public cloud. As long as all microservices, internal and external, publish their specifications that describe which access rights and functional capabilities they provide to different user groups, APIs of distributed applications can become part of the organization’s central governance, compliance, and security frameworks.
EMA Research Facts
- 540% – Increase in API related security vulnerabilities (CVE records) between 2015 and 2021.
- 68% – Increase in API-related software development topics on Stackoverflow.
- 250 – Number of monthly changes in APIs by AWS, Azure, and GCP
Shifting Left API Governance Is Critical
Due to the complex and dynamic nature of cloud native applications there is no viable alternative to “shifting left” the creation and governance of API specifications. This requires the automatic generation and audit of API specifications as part of today’s software release process. The new APIClarity open source project creates the foundation for addressing this challenge by automatically surfacing APIs that are currently not visible to the organization. Without creating standard specifications for these formerly under-the-radar APIs, the organization will load up on unknown quantities of security risk. APIClarity alerts human operators of these unspecified APIs and enables them to verify and complete an automatically created API specification. APIClarity creates this specification based on the OpenAPI 3.1 standard to allow easy ingestions for the corporation’s higher level cloud native security platforms.
Deprecating and removing APIs is a standard process within most enterprises, but there are situations when deprecated APIs are not removed after the agreed upon time period or even more interesting, sometimes these APIs or parts of them, come back as Zombie APIs. All it takes is a small mixup by a single developer in his or her source code repository, and an already phased out API is back.
In today’s scale-out world, all an attacker needs to create devastating damage is one successful portscan leading to a misconfigured API endpoint that provides access to a Kubernetes container cluster. From there, the malware can spread in a cascading manner to similarly configured Kubernetes clusters that were inaccessible from the outside, affecting numerous applications. Attackers then try to connect to unsecured Kubernetes admin tools and APIs to ultimately pull off anything from scraping public cloud access keys, data theft and ransomware attacks.
The APIClarity open source project enables organizations to bring rogue APIs under the umbrella of corporate security and governance platforms, simply by listening to Kubernetes service mesh traffic. This is an easy and necessary way for organizations to minimize security blindspots and optimally manage operational risk.