An Alternative Approach to WAAP Architecture

Over the last few months, I’ve had many conversations with customers about securing their APIs and some common challenges they face. Many of them already have revenue-generating applications consumed by their customers and now they are starting an API program. Old monolith applications are being broken into micro-services, orchestrated in flexible and elastic service-mesh architecture. The question most enterprises grapple with is – how to combine application security designed for web apps with APIs and API security?

To answer that question, first, let’s look at the state of web application security today. Many of these customers have chosen the all-in-one approach (WAAP) where the key features are bundled as either a cloud WAF, or as a WAF within a CDN, as shown in the image below:

Most CDN vendors looking to offset their declining margins in the CDN business, offer WAAP or Cloud WAF security solutions, and this model is also recommended by leading industry analysts. There are clearly some benefits to putting application security at the CDN layer.

• Reduced Infrastructure Cost – Stopping volumetric threats at the edge means reduction hosting and bandwidth cost.
• Improved Performance – Single-pass architecture reduces multiple hops necessary for different security solutions, thereby improving the performance and latency characteristics of the apps.
• Reduced Sec-ops Workload – most WAAP or Cloud WAF solutions are offered as managed security solutions, thereby helping the already struggling sec-ops staff.

The reality is that despite hype created by CDN marketing teams, enterprises have found that CDN-based WAAP and Cloud WAF security models are inadequate for the following reasons:

• Poor Efficacy – The same analysts that recommend the WAAP / Cloud WAF approach, have rated all the vendors in the category, poorly based on their efficacy. Customers are realizing that the JavaScript integrated into every application can be evaded easily, and cannot support APIs with the same protections.
• Weak Bot Mitigation – CDNs offer very basic generation bot mitigation features which can stop simple bot attacks. They rely heavily on network intelligence and TLS/SSL signals from the client-side to stop bots. Advanced bot tools which rely on real browsers, real mobile applications and crowdsourcing to easily bypass through CDN based bot mitigation.

As a result, enterprises are moving towards an application security architecture that looks more like this:

Or like this:

In both cases, bot mitigation is handled by a best-in-class solution capable of handling advanced bot attacks, like Cequence API Spartan.

As enterprises deploy more APIs to support their business initiatives, the architecture becomes a bit more complicated, with added API management components. The first thing enterprises look to deploy when start an API Management program is an API Gateway. API Gateways manage the entire API lifecycle along with usage monitoring and control. Some API Gateway vendors offer security functions like authentication, authorization, DDoS prevention as add-ons to their core offering. Using API Gateway as a service and routing API traffic through a CDN and best in class bot mitigation may force an architecture that looks like this:

In this architecture, your API traffic may traverse 3 different SaaS vendors before it reaches your APIs. The disadvantages of such a spaghetti architecture are:

• Latency Impact – APIs, which are supposed to be low latency, experience slowness bouncing across the various SaaS environments.
• DevOps Challenges – APIs which are typically developed and deployed at a fast-paced using modern dev-ops processes, don’t achieve their potential. Dev-ops people do not have access to CDN or API Spartan environments to make changes in sync with API changes.
• Increased Cost – API traffic is forced to traverse through a CDN, which increases the cost of the API program. Typically, API traffic does not require content caching and therefore should not be routed through a CDN.

Best-in-Class WAAP

An alternative approach is to eliminate the multi-vendor/multi-hop approach and simplify your application architecture with the Cequence Application Security Platform.

In this architecture, web application traffic hits the CDN, where caching and DDoS are applied, then Cequence API Spartan and Cequence App Firewall policies are applied to prevent bot attacks and vulnerability exploits.

API traffic hits the API gateway as it would normally, then the PAAS infrastructure where Cequence API Sentinel performs a runtime inventory and usage map, assesses the API risks, confirms specification conformance and blocks automated threats.

The result is a more efficient and effective WAAP security stack that analyzes and inspects traffic in a single pass. I’ve summarized how our platform addresses the core WAAP requirements.

SaaS, Cloud Hybrid or On-Prem – the Choice is Yours

As defined by Gartner, WAAP architectures are commonly SaaS or Cloud, but there are cases where customer requirements dictate an alternative approach. Our Application Security Platform has you covered here too. We’ve built the platform as a modern, Kubernetes-based application that is available now as a SaaS, where you manage policy and we manage everything else. Alternatively, our managed service option takes most of the policy decision making effort away from your over-worked team, yet still provides you with full access for reporting and analysis. The ASP can also be deployed on AWS, Azure, GCP or in your data center and the modular architecture means your hybrid requirements easily addressed.