To Protect Cloud-Native APIs, Avoid Overly Permissive States
APIs are now foundational to how modern applications are built: Using microservices and containers and running on platforms like Kubernetes. They’re the standard mechanism to integrate internal components or expose functionality to partners. APIs have also risen in ubiquity alongside microservices architecture, providing a common way to incrementally develop, scale and reuse specialized cloud-native functionality.
But along with this newfound ubiquity, API attacks are surging. Malicious API traffic saw a staggering 117% increase in the past year, according to Salt Labs’ State of API Security Report, Q3 2022. This is partly due to the sheer number of APIs being produced. While some of these encompass public products, the majority are internal-facing services, the 2022 Postman State of the API Report finds.
I recently chatted with John Morello, VP of product, Palo Alto Networks, to gather insights on how to best protect cloud-native applications and APIs. According to Morello, APIs are prone to data overexposure and require more modern analysis techniques to validate traffic. Furthermore, he believes IT security requires unified management across clouds—more holistic visibility and control can help correlate issues across various toolsets.
Lock Down Permissions to Secure APIs
To protect APIs, the number-one action item organizations should take is to ensure the HTTP traffic that hits APIs is valid, says Morello. API owners must prevent bad actors from retrieving data from an endpoint that they shouldn’t have access to. For example, if an API endpoint /userdata only has read access via HTTP GET calls, a system shouldn’t allow data to be pushed to that endpoint. Filters are also required to avoid actions that may overwhelm endpoints with traffic or manipulate methods with malicious behavior.
Ensuring traffic always fits the appropriate actions is a prime example of where shift-left thinking can be used, says Morello. Engineers could take an OpenAPI Specification file, which describes the API’s method in detail, and create security policies over it that match the intended behaviors.
Morello shared some further recommendations on how to best protect applications and APIs:
Go beyond WAFs. Many organizations deploy a web application firewall (WAF) to protect their web applications. But, it should be clear that WAF is insufficient for protecting web APIs. “WAF was really designed to desired to protect web apps,” explains Morello. “While they go hand-in-hand, they’re fundamentally different.” Whereas web apps have a limited input source, APIs are highly programmable. Security software must thus understand these nuances to be aligned with the proper use case.
Be aware of the underlying API design style. Although REST is still the dominant player, there are many other API design styles in use, like GraphQL, gRPCÂ and asynchronous event-based styles. Any good API security platform must understand and adapt to the fundamental differences between these types.
Follow the rule of least privilege. Where APIs are concerned, things can quickly become overly permissioned. The same goes for service-to-service communication, as well. Whether it’s an external caller or an internal microservice, entities should be limited to only what’s required to function. To trace permissions, APIs require robust authorization and identity and access management (IAM).
The State of Cloud-Native Application Security
A few years ago, the cybersecurity market was full of niche point solutions aimed at covering very particular areas, such as container security and posture management, says Morello. This led to a complex array of specialized utilities designed for specific cloud-native functions. As a response, he now notices that security operators desire a more unified set of capabilities delivered by a central platform.
The idea is that through more unification, one part can inform and protect other components in other environments. For example, scanning in production might detect new vulnerabilities and correlate that to the code repository and a specific Docker image file. By combining knowledge from multiple environments, says Morello, you can link security information across the entire life cycle to produce more actionable insights.
Historically, security teams weren’t involved until deployment. But, nowadays, a shift left approach is far more common. In this world, you can discover vulnerabilities before deployment—shift left tools could even force developers to fix an issue before committing code.
Defense-in-Depth for Cloud-Native APIs
In the past, web APIs were primarily consumed as external products. But with the rise of microservices, organizations are now developing their own APIs. Cloud infrastructure for hosting workloads often has exposed APIs too, which may harbor insecure default settings.
The problem is that, historically, cybersecurity WAF tools didn’t account for the API-first trend. Thus, API owners must evolve their cybersecurity postures by adding modern technologies to prevent misuse and ensure that overly permissive states are locked down. As Morello describes, organizations require more encompassing layers for a holistic defense-in-depth posture.
Moreover, he argues that cloud-native security solutions require an integrated context of the entire development life cycle, from the Git repository to the cloud. By unifying environments and empowering security solutions with more information, security checks can be less generic and more reliable. “Over time, people will expect API security to be integrated with the overall cloud security platform.”