Cloud Container Security Summit

To protect cloud-native APIs, avoid overly permissive states

APIs are now the foundation for building modern applications: using microservices and containers and running on platforms like Kubernetes. They are standard mechanisms for integrating internal components or exposing functionality to partners. APIs have also grown in popularity with the popularity of microservices architectures, providing a common way to incrementally develop, extend, and reuse specialized cloud-native functionality.

But with this newfound ubiquity, so too has API attacks. According to Salt Labs’ Q3 2022 State of API Security Report, malicious API traffic has grown by a staggering 117% over the past year. This is partly due to the sheer number of APIs generated. The API report found that while some of these contained public products, most were internal-facing services.

I recently spoke with Palo Alto Networks VP of Product John Morello to gather insights on how to best secure cloud-native applications and APIs. According to Morello, APIs are prone to data overexposure, requiring more modern analytics techniques to validate traffic. Additionally, he believes that IT security requires unified management across clouds—more comprehensive visibility and control can help correlate issues across various toolsets.

Lock down permissions for secure APIs

To secure an API, Morello said, the first action an organization should take is to ensure that the HTTP traffic accessing the API is valid. API owners must prevent bad actors from retrieving data from endpoints they should not be able to access.For example, if the API endpoint /userdata Only read access via HTTP GET call, the system should not allow data push to that endpoint. Filters are also required to avoid actions that could overwhelm endpoints with traffic or manipulate methods with malicious behavior.

Ensuring that traffic is always appropriate for appropriate action is a prime example of where left-shift thinking can be used, Morello said. Engineers can obtain an OpenAPI specification file that details the API’s methods and creates security policies on it that match the expected behavior.

Morello shared some further advice on how to best secure applications and APIs:

Beyond WAF. Many organizations deploy Web Application Firewalls (WAFs) to protect their Web applications. However, it should be clear that WAFs are not sufficient to secure web APIs. “WAFs are designed from the ground up to protect web applications,” Morello explained. “While they go hand in hand, they are fundamentally different.” Web applications have limited input sources, and APIs are highly programmable. Therefore, security software must understand these nuances in order to align with the correct use case.

Pay attention to the underlying API design style. While REST is still the dominant one, there are many other API design styles in use, such as GraphQL, gRPC, and the event-based async style. Any good API security platform must understand and adapt to the fundamental differences between these types.

Follow the rule of least privilege. As far as APIs go, things can get overly permissive very quickly. The same goes for service-to-service communication. Whether external callers or internal microservices, entities should be limited to what is needed to run. To track permissions, the API requires strong authorization and identity and access management (IAM).

The State of Cloud-Native Application Security

A few years ago, Morello said, the cybersecurity market was filled with niche solutions targeting specific areas, such as container security and state management. This has resulted in a complex series of specialized utilities designed for specific cloud-native capabilities. In response, he now notes that security operators want a more unified set of capabilities from a central platform.

The idea is that with more unification, one part can inform and protect other components in other environments. For example, scanning in a production environment might detect new vulnerabilities and associate them with code repositories and specific Docker image files. By combining knowledge from multiple contexts, you can connect security information across the lifecycle, resulting in more actionable insights, Morello said.

Historically, security teams were not involved until deployment. However, these days, the shift-left approach is more common. In a world where you can find bugs before deploying — shift-left tools can even force developers to fix problems before committing to code.

Defense-in-depth for cloud-native APIs

In the past, Web APIs were primarily used as external products. But with the rise of microservices, organizations are now developing their own APIs. Cloud infrastructure used to host workloads also often exposes APIs that may contain insecure defaults.

The problem is that historically, web security WAF tools have not taken into account the API-first trend. Therefore, API owners must improve their cybersecurity posture by adding modern techniques to prevent abuse and ensure an overly permissive state of locking. As Morello describes, organizations need more layers of inclusion to achieve a comprehensive defense-in-depth posture.

Additionally, he believes that cloud-native security solutions require an integrated context across the entire development lifecycle, from Git repositories to the cloud. By unifying the environment and providing more information to security solutions, security checks can be less generic and more reliable. “Over time, people will expect API security to integrate with the entire cloud security platform.”

Leave a Comment

Your email address will not be published.