Prisma Cloud delivers web application security combining visibility, protection and governance for APIs. This blog highlights best practices and requirements.
Microservices and APIs Overview
Two of the key tenets of cloud native applications are loosely coupled microservices and application programming interfaces (APIs). These two principles are tied together and allow programmers to develop complex applications rapidly and with ease. APIs are the way for microservices to talk to each other using a standardized message format. Oftentimes, APIs will use REST over HTTP(s) to send and receive data such as JSON or XML content, and in other times, more complex message formats and protocols may be used (e.g. GraphQL or gRPC).
In more mature organizations, developers will create an API specification file, usually in OpenAPI format. The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.
In layman terms, the OpenAPI specification file defines the different API endpoints, what each API expects in terms of incoming message format, and what response should be expected by the consumer. When defined accurately, the specification can later be used for API message validation by intermediary security devices such as API gateways or web application firewalls (WAFs).
In essence, modern cloud native applications use dozens or even hundreds of loosely coupled microservices, all talking to each other using APIs - and this is why many consider API messages to be the new network layer.
In many modern applications, a single client’s web request (i.e., north-south traffic) that hits your Kubernetes cluster, can spawn dozens or even hundreds of API calls between internal microservices (i.e., east-west traffic). This is why it is not enough to secure the front-end web interface of your cloud-native application - you must also apply rigorous application layer protections on your cloud-native APIs.
API Risks
The OWASP API Security Top 10 Project lists the following top risks to APIs:
- Broken Object Level Authorization
- Broken User Authentication
- Excessive Data Exposure
- Lack of Resources & Rate Limiting
- Broken Function Level Authorization
- Mass Assignment
- Security Misconfiguration
- Injection Flaws
- Improper Assets Management
- Insufficient Logging & Monitoring
While each of these risks are critical and should always be considered when developing and deploying APIs, I’d like to focus in this blog post on the last two: improper asset management and insufficient logging and monitoring.
Control and Governance Over APIs
In a perfect world, each API would be registered and monitored, and for each API an accurate OpenAPI specification file would be created. In addition, obsolete microservices and APIs would be decommissioned. However, the fast pace in which organizations develop APIs these days, and the dynamic nature of modern applications, oftentimes leads to slip-ups.
As more and more cloud-native applications are developed and deployed, the amount of microservices and in turn, the number of exposed APIs grows. Pretty quickly, it becomes extremely difficult to keep track of the inventory. Without governance and visibility into the microservices and their respective APIs, it becomes impossible to secure an application, after all - you cannot secure what you don’t know exists.
Securing Cloud Native APIs with Prisma Cloud Web Application and API Security
The Prisma Cloud Web Application and API Security (WAAS) module contains a wide range of capabilities to help customers secure cloud-native applications, microservices and more specifically APIs. In the following section, we will highlight some of the capabilities, specifically geared for API security.
Automated Detection of Unprotected Web Apps and APIs
Periodically, the WAAS module will analyze your applications both statically and dynamically to discover containers or hosts that expose a web application or an API that have yet to be protected by WAAS. Once an unprotected web application or an API will be discovered, they will be flagged in the Radar view, so customers can quickly create a WAAS protection policy for them, with ease. In addition to the Radar view, a more structured report of all unprotected web applications, including container image names, ports and number of executed containers is also available in the Console.
Defining and Protecting APIs Using OpenAPI Specification Files
WAAS offers two methods for defining APIs to be protected - the first is by manually defining the API endpoints, and their respective HTTP methods and parameters:
Using this method, customers can manually define each and every API endpoint using the endpoint’s HTTP request path, the allowed HTTP methods, as well as message parameters. For each parameter, users can define its location, the value type, format and expected ranges. Once all of this information is defined, WAAS will provide positive security through validation of API message format.
However, manually defining API endpoints can become a very tedious process. This is why WAAS also provides the ability to load an OpenAPI specification file, which will automatically be parsed and used to populate all API definitions automatically.
As mentioned earlier, and regardless of the method you use to onboard and define application APIs, WAAS will then use this definition to provide the following positive security enforcement of API messages:
- Only allow API calls to endpoints that were defined in the configuration
- Only allow specified HTTP methods
- Only allow specified API message parameters
- Enforce parameter value format, data types and ranges
- Enforce the existence of “required” parameters
Any attempt to call an undefined API will result in WAAS taking the pre-defined action (i.e., Alert and log, Block or Ban).
Automated API Discovery and API Profiling
Since modern cloud-native applications tend to be dynamic and change often, you may end up with APIs that are either obsolete, or simply not documented anywhere. Visibility and governance over APIs are critical steps on the way to applying robust security. This is why WAAS provides an automated API discovery capability, which uses automated machine learning analysis.
When API discovery is enabled, deployed Defender agents will inspect API traffic routed to the protected application. Defenders learn the endpoints in your API by analyzing incoming requests and generating a tree of API paths. Periodically, Defenders send the Console a diff of what it has learned since its last update. The console merges the update with what it already knows about the API. The API discovery subsystem attempts to ignore all HTTP traffic that doesn’t resemble an API call and applies an intelligent criteria for identifying which requests to inspect.
Once APIs are discovered and profiled, WAAS provides users with an API discovery report, as well as the ability to export the data as an OpenAPI specification, which can then be used to define APIs for protection.
Application Layer Protections
One of the key capabilities of WAAS is its highly accurate web application firewall (WAF), which provides application layer protections against attacks such as: SQL Injection, Cross-Site Scripting, OS Command Injection, Local File Inclusion, and many other attack categories. These protections can be enabled both for standard web applications, as well as for API endpoints.
It should be noted that when the application firewall is enabled, it will protect against application layer attacks on any HTTP-enabled URL that is defined in the policy, including API endpoints. This means that APIs do not have to be explicitly defined through the API protection configuration in order to be protected against such attacks, as long as application firewall policy covers their URLs. The process of defining API endpoints is strictly used for providing the highest level of security through API message validation.
API Access Control and DoS Protections
In addition to API message validation, automated discovery and application layer protection, WAAS provides the ability to enforce access controls over APIs. Access to API endpoints can be enforced by using IP addresses, IP CIDR blocks and network lists which can be programmatically updated when needed. In addition, Geo-based access controls can also be set, as well as enforcement of HTTP headers such as API key, and so forth.
Application layer DoS protection, can also be used in order to deny clients from flooding or abusing API endpoints. Users can set the burst rate limit, which is intended to prevent spikes in traffic coming from a client, or the longer-period (average) rate. Additional criteria for rate accounting can be used such as specific file extensions, HTTP response codes and HTTP methods.
Virtual Patching and Custom Rules
As explained in this previous blog post, virtual patching is the process of creating one or more detection rules that prevent malicious exploitation attempts against a vulnerability before an official patch is available. Prisma Cloud can deploy these virtual patching rules within minutes after a vulnerability is discovered, and users can keep them in place until the official patch is applied. When critical vulnerabilities for relevant cloud-native application technologies are publicly reported, the Prisma Cloud Labs team may release updated WAAS rules and automatically push them to all customers, who would then be able to choose whether to apply them. But because each application is unique, customers may want to create their own rules to meet the specific requirements of their own application. In such cases, new custom rules are easily created through the editor in the Defend > Custom Configurations screen.
Summary
With the rapid adoption of cloud-native application development, we see a proliferation of APIs, some might be publicly exposed - through north-south traffic, but many can get invoked as a result of incoming traffic to your application’s front-end interface (east-west traffic between microservices).
Given their direct access to sensitive back-end systems and microservices, APIs are quickly becoming the prime target for abuse by malicious users. This is why regardless of their direct exposure, all API endpoints in your applications should be closely monitored, and rigorous application layer protections should be applied.
In addition to the protections provided by the WAAS, web application security module, which are mentioned in this blog post, Prisma Cloud customers also benefit from many other key capabilities provided by Prisma Cloud Compute - i.e., security posture of cloud native APIs throughout the stack with a comprehensive holistic view of vulnerabilities, runtime issues and application layer exploitation attempts.
To learn more about WAAS, please visit: /prisma/cloud/web-application-API-security