Protecting public web services with WAF - things to watch

A Web Application Firewall (WAF) solution has been traditionally sitting in a data center close to the application server, usually also offering load balancing capabilities.

Several factors are changing the way WAF operates and its functionalities:

• the locations where apps are located are multiplying: co-location servers at hosting providers, public cloud workloads, ephemeral containers in Kubernetes clusters are just some ways applications are deployed nowadays. This distributed environment also changes the WAF placement.

• APIs (mostly JSON formatted objects) are becoming the default method for exchanging data between web users and servers and also between various server components. For ex. modern smartphone apps contain all the user interface elements as part of the app, while servers provide data via APIs to "fill in" the user interface. Protecting APIs against API specific vulnerabilities therefore becomes imperative.

• Security issues are escalating: vulnerabilities are being exploited even before publicly disclosed by vendors (see here and here). Public facing web services are a critical asset in the organization attack surface. Yet managing a public facing service on your own (including patching), as opposed to consuming it as SaaS service, becomes increasingly difficult - the attack surface and exposure proves to be much larger, and the threat hunting effort much costlier.

What's included in a modern WAF?

Therefore, things to watch when purchasing a WAF solution are:

1. Technical support - this one might not be obvious, but when things stop working (especially if dealing with a SaaS-like solution), you want to be able to talk with real people with brains. Enterprise applications are often generating revenue for the company, so any interruption cannot rely on chat bots or other waiting queues.

2. The devil is in the details - many functionalities might be missing from default plans. Things to pay attention are: visibility into web app logs and end-to-end observability (for troubleshooting and SIEM integration), limitations with regard to traffic volume or number of requests, dedicated public IP addresses, DDoS protection limitations for particularly dynamic bots, web API detection and protection against excessive data exfiltration, web scraping protection, etc.

3. Simplify as much as possible - make it SaaS - as mentioned earlier, having a managed offering from the vendor (delivered as SaaS) gives you a much better chance to withstand security attacks, especially emerging vulnerability exploit attacks. Plus it will also address the costly on-premise disaster recovery and redundancy requirements.

4. Deployment flexibility - a WAF solution should provide multiple "form factors": from hardware, over virtual machines in your data center, to a completely managed offering (SaaS) in the cloud. Your use cases and regulatory regime might require different locations and therefore multiple ways to deploy, on-premise or in the cloud.

5. Multiple way to interconnect applications and publish them securely. The typical method is to route incoming web traffic destined for your apps through the WAF first (typically, DNS redirection). However, this option typically requires coordination with your firewall solution to open incoming ports, additional management overhead, and can even by bypassed if configured incorrectly. A better approach is to connect backend apps via IPsec based SD-WAN enabled at specific points - for ex. a Vmware data center or public cloud IaaS (see image below).

Connecting backend apps via SD-WAN - a better approach

Explore F5 Networks' Distributed Cloud WAF, a solution designed to seamlessly handle complex enterprise deployments, which addresses all the above requirements. With its user-friendly SaaS-like experience, you can effortlessly publish and secure backend applications distributed across multiple locations, including on-premises, co-location servers, and public cloud environments.