How and Why to Use APIs to Strengthen Your AppSec Strategy

APIs are at the heart of modern applications and have quickly become a favorite target of attackers. And for good reason – they expose a wealth of functionality and attack surface that is often poorly defended. In our previous article we introduced the key building blocks of API security that can help ensure your APIs get the same level of protection as the web front-end of your application.

However, we would be doing ourselves a disservice if we stopped there. The application platforms that modern apps are built upon, such as Kubernetes, OpenStack, and others, are built on massively rich APIs. These APIs not only provide a great place to see and stop threats, but they also open up entirely new and powerful security policies that go beyond what we could do with more traditional security.

APIs Are the Fabric of Application Platforms

While it’s easy to think of securing individual applications, many organizations have begun to standardize on particular application platforms and underlying components. Kubernetes, OpenStack, NGINX Plus, and Elasticsearch are all great examples that have become very popular in enterprises. And because these elements all need to interact with other diverse elements, they have virtually become defined by their APIs. Kubernetes puts it quite succinctly when introducing their API documentation:

Sponsorships Available

Sponsorships Available

Sponsorships Available

“The REST API is the fundamental fabric of Kubernetes. All operations and communications between components, and external user commands are REST API calls that the API Server handles…”

This is true for most other application platforms and components that need to interoperate with one another. RESTful APIs and JSON have become the lingua franca that makes it all work together. And this can be a somewhat subtle but very important point. We open up an entirely new set of possibilities when we stop thinking of APIs as something bolted on to a specific application, and start realizing that they are the very fabric of our application control planes and delivery platforms.

These platforms also often present natural insertion points for security. As we’ve discussed previously, Kubernetes sidecar deployments allow security to be easily designed into a pod. Alternatively, load balancers within OpenStack or NGINX deployments make great options as well. The particulars will obviously vary from solution to solution, but the value remains compelling in each case.

Detecting and Stopping API Abuses

We mentioned this in the previous blog, but it’s worth reiterating here. Given that REST APIs and JSON are so fundamental to modern application fabrics, security teams must be able to analyze for threats within JSON payloads. Without this ability, teams will be unable to perform fundamental security functions, such as detecting injection attacks or performing input validation for their critical traffic. This is a capability that the ThreatX NG-WAF provides natively.

Similarly, by plugging into these platforms we can detect a whole host of additional threats, and report them in the context of the kill-chain. For example, we can easily see unauthenticated requests, Layer 7 DoS attacks, API scanning, enumeration, brute force, and more.

Platform-Specific Policies

While the previous examples may seem familiar, the real fun begins when we start to build policies based on the specific behaviors of the application platform itself. Using OpenStack as an example, here are just some of the policies that we could create:

• Track requests with missing or malformed request ID’s
• Track POST, PUT, and DELETE requests, or even tarpit them
• Track sensitive calls like ‘resetNetwork’, ‘changeAdminPassword’, etc.
• Track 400 error codes
• Tarpit expensive calls, like ‘createImage’
• Track incorrect version use

Of course, this is really just the tip of the iceberg. The screenshot below shows a high-level of the ThreatX rule builder. By using this rule builder, we can:

1. Define a wide variety of behaviors and responses based on the unique issues and challenges of a particular application or the enterprise as a whole.
2. Align policies to the behaviors that consume the most resources or generate the most tickets.
3. Build responses that deceive or frustrate attackers.

And this quickly becomes very empowering. Instead of thinking of APIs as yet another unwieldy attack surface to be addressed, we can actually start to use the flexibility of these APIs to drive better security that aligns with the mission of the application and the business.

If you’d like to learn more, check out this eBook, Designing AppSec in the Age of APIs and Microservices, for a breakdown of the role of APIs and microservices in modern security and ways to take the next step toward securing these elements.