Forrester dubbed API Insecurity “the lurking threat in your software.” Understanding API security-specific risks is key to protecting your API. New ways of thinking about API security are emerging.
Using external services through APIs is routinely done to speed up development cycles in today’s microservices architecture. Unfortunately, this potentially creates additional exposure for the application. When calling external services or data from an enterprise application, penetration vectors cloaked in these external sources might expose databases or the application back-end to attacks. API security is the process of securing the application against importing vulnerabilities from external services through REST calls, REST, OpenAPI, gRPC, graphQL, and ad-hoc interfaces. Regardless of the architecture used, Gartner identifies API security as a new attack surface potentially leading to data breaches. So, in this post, we will focus on API security across all platforms, and not on Kubernetes as we usually do.
Tackling API security risks requires an understanding of what the specific security challenges they face are. Here are six OSWAP most critical challenges, listed in order of decreasing importance:
Accessing external resources or services through third-party APIs generates a risk of exposing critical information through these external providers’ APIs’ vulnerability. These might provide entry vectors for malicious actors to infiltrate the application, leading to potential information leaks or application service disruption.
Currently API security is rigid, with a one directional hierarchical flow that lets developers use whatever API is most convenient to them.. As feature development high velocity is a core requirement for developers, they tend to focus more on delivering fast than on dwelling on security aspects. To make matters worse, API qualifications are often unclear, further diminishing the odds that developers will take the time to fully understand the API security implications of the feature they are developing. So, API security is more of an afterthought, taken into account only when SecOps enters the picture and try to assess if the APIs used by the developer are high or low risk. This is a highly manual process, both time consuming and prone to error. Hidden and/or zombie APIs are often missed and image libraries with vulnerabilities are overlooked. CISOs are responsible for all the applications in your environment. They need visibility and this system does not offer it.
We will discuss further API security developments shortly, but in the interim implementing the recommended best practices below is a good starting point.
API vulnerabilities are complex to spot as they might originate in application logic flaws, so it is critical to take into account the entire API’s lifecycle and identify the insecure parts. Vulnerabilities need to be identified both for internal and external APIs. Internal APIs connect an organization’s disparate backend system to enable seamless communication for individual lines of business needing access to specific data silos. Identifying and closing vulnerabilities in internal APIs is key to prevent lateral escalation in case of breach. External APIs are the interface between the application and external clients, providing services or data.As applications are increasingly assembled with these externa services and data, and the quality and security of remote services and database is oftentimes unknown, the organization’s customer data might be at risk when using a third-party service. Identifying vulnerabilities from third=party providers might be tricky, especially as telemetry API security evaluation is typically not available before runtime, complicating the identification of vulnerability from external services during the CI/CD cycle. With the absence of full control on vulnerability identification for external APIs, the additional methods listed below are especially critical.
Use methods such as TLS (Transport Layer Security) to encrypt data and require signature from a privileged few authorized to decrypt and modify data. This is particularly crucial for PIDs.
API keys provide both project identification and authorization. As such, they are useful to block anonymous traffic and to control and monitor calls to your API, but not to secure traffic to and from your API as they can easily be stolen. To avoid unwanted use of API keys, use secret keys with unique temporary access tokens. Maintain a strict credential discipline to prevent exposing secret/password both to client and server.
Segmentation is key to prevent lateral escalation. Validate parameters
This requires creating a strict schema establishing what are the system’s permissible incoming data. All incoming data need to be validated before gaining entry, limiting the odds that they might be harmful.
Log all traffic information and monitor API traffic and consumption.
API security best practices provide increased security, but existing methods are still inefficient in evaluating vulnerabilities inherited from third-party service providers in real-time and provide an automated response to changing third-party service provider risk factor.
Forrester’s October 2020 report on API Insecurity identified the shift away from SOAP APIs to OpenAPI and gRPC, graphQL, and ad-hoc interfaces as one of the current API security exposure sources. Instead of access through two-way connection to SOAP APIs, REST APIs, OpenAPI,gRPC, graphQL, and ad-hoc interfaces are typically accessed through mobile apps or browsers. This opens applications to easy-to-obtain hacking tools and client-side inspection.
Requirement for rapid development cycles makes it virtually impossible to eschew reliance on third-party providers.
What is needed is an oracle that speaks to the risks enterprise applications run when interacting with such services. With an oracle capturing those risks in a “reputation score”, developers, SecOps (or a combination thereof), and CISOs can enable connectivity policies for interactions between the enterprise application and the third party service. The policies can reduce the exposure to API risks for enterprises using third party API services.
To address API reputation scoring and the implications for enterprise applications and their security when using such services, a scoring mechanism for the API service reputation is necessary. This scoring mechanism needs to be able to be used in a DevSecOps environment when developing and hosting applications.
Such a scoring system requires:
A scoring system like the above would enable developers to evaluate the cost/risk-benefit of including a third-party API and adapting cybersecurity insurance costs to rise and fall in parallel to the third-party APIs scores.
An integrated development system including scoring would also offer visibility to both SecOps and CISOs as to the APIs the developers are using and their risk levels. The security persona receives a list of dependencies with easy visibility into whether all of the used assets are high or low risk. It allows for compliance reports to be generated by a CISO quickly and easily. The CISO can then approach the customer with a list of vulnerabilities and a plan for a solution. There is continuous visibility and risk mitigation is simple by quarantining those API calls quickly and efficiently.
Be in touch with Portshift, a Cisco company to learn more about integrated development solutions.
An integrated development system is the way forward. Best practices are invaluable guardrails, but unfortunately, mistakes happen during development so, even if all recommendations are applied, monitoring your application for runtime vulnerabilities still remains critical to ensure ongoing API security. Get in touch with Portshift, a Cisco company to learn how to get started with an integrated development system.
Come learn how we have evolved Portshift/Cisco Panoptica via API Security