Microservices and Kubernetes As the Driving Factor
[caption id="attachment_1686" align="alignright" width="300"]
Topic map based on standard clustering of the 631 API-related CVE records from Jan 1 to October 30, 2021.[/caption]
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
[caption id="attachment_1689" align="alignright" width="300"]
Topic Map based on all 10,911 CVE records related to cloud native applications.[/caption]
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.
EMA Perspective
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.