Protecting Web Applications and APIs in a Distributed World

Enterprise applications and workloads are more heavily distributed than ever, residing in multiple private and public cloud environments. Meanwhile, users are also increasingly distributed and expect to consume applications from anywhere. 

With access patterns today vastly different from how they were even five years ago, it is time to rethink how and where web applications should be protected from malicious exploits and abuses. 

In the classic model depicted below, a Web Application Firewall (WAF) is placed co-adjacent to the application/s it protects. 

An enterprise typically has a legacy physical WAF appliance deployed in its private data centers. As the need arose to protect applications in centralized cloud platforms, the enterprise may have deployed in the cloud a virtual appliance from their physical WAF appliance vendor (as depicted in cloud 1) or a WAF service from the centralized cloud provider itself (as shown in cloud 2 and 3). 

An appliance-based WAF—whether physical or virtual or deployed in a private or public cloud—has limitations:

• The enterprise is responsible for deploying and managing the appliances, including the initial deployment and ongoing maintenance, across multiple cloud environments.
• An appliance-based model requires software upgrades to get the latest and greatest features and sometimes even bug fixes, upgrades that require certification cycles, and maintenance windows that will happen infrequently. 
• The attack is mitigated within the enterprise’s infrastructure, while the ideal mitigation point is outside the perimeter.
• Virtual appliance form factors are often close cousins of legacy physical appliances and not rearchitected to take advantage of modern microservices architectures. 

A WAF service from a centralized cloud provider has limitations, too:

• It will work to protect only the applications hosted in that provider’s cloud. For an enterprise with a multi-cloud strategy, the enterprise must deal with WAF offerings native to each cloud provider. This can lead to inconsistencies in policy enforcement across clouds and an increased overhead to operationalize.
• It may not be a best-of-breed offering.
• Like the appliance approach, the attack is still mitigated from within the enterprise’s infrastructure.

A multi-cloud world requires a different approach, as depicted below. 

This model leverages a WAF service distributed across the internet’s edge in StackPath locations worldwide. Let’s refer to it as an edge WAF.

An edge WAF has the following benefits:

• Web exploits are thwarted closer to users. An attack originating from New York is mitigated at an edge location in New York. This prevents the attack from making its way into the enterprise’s infrastructure.
• A single WAF deployment protects the entire multi-cloud infrastructure encompassing applications in private and public cloud environments. A unified dashboard provides visibility into attacks across the entire spectrum of applications used by the enterprise.
• Since the WAF sees traffic from multiple domains, it can protect applications in Domain A based on attacks seen in Domain B.
• There are no appliances to manage, physical or virtual. The edge cloud provider offers a managed service, taking responsibility for the deployment and ongoing maintenance of the WAF service. 
• New features and bug fixes are available to consume as soon as the cloud vendor releases them.
• Not encumbered by legacy products, the solutions are typically built using microservices architectures designed to be highly resilient and fault tolerant. 

StackPath WAF offers all of the above benefits and is the way forward in a multi-cloud world. The StackPath WAF can be deployed in the following deployment models:

Model 1

StackPath CDN + StackPath WAF

StackPath offers a CDN service in addition to WAF. An enterprise can leverage our CDN caching capabilities to cache static content while leveraging our WAF to protect origin calls.

Model 2

StackPath CDN + StackPath Origin Shield + StackPath WAF

A variation of Model 1, this deployment model takes advantage of Origin Shield to reduce the number of original calls that need to be made. A downstream caching cluster closest to the origin acts as an Origin Shield consolidating missed-cache requests from multiple upstream caching clusters closer to the users. The WAF sits between the Origin Shield and the origin.

Model 3

StackPath WAF Only

The StackPath edge cloud WAF can also be deployed standalone, not taking advantage of any caching capabilities. All user requests are policed and then sent to the origin.

Model 4

External CDN + StackPath WAF

We would love to have everyone use our CDN caching services, but in situations where that is not practical, the StackPath WAF can also sit between an external CDN and the origin.

We invite you to take advantage of the flexible deployment options of our cloud WAF to protect your web applications and APIs. For more information on our WAF Packages, check out our WAF page.