Question
Besides classic request filtering, which additional functions are WAFs often extended with?
Answer
Bot detection, handling of DDoS attacks, and overload protection / load balancing. Modern combined solutions also integrate with further components of the cloud provider, such as load balancers, caching frameworks, content routing, DNS and content-delivery frameworks.
* Because all traffic passes through the WAF anyway, it is the natural place to add more functions. *
These additions follow from the WAF's position: it already terminates every request to the application, so it can count, classify and steer them. Bot detection separates automated clients (scrapers, credential-stuffing tools) from humans. DDoS handling absorbs or drops floods of requests before they reach the servers. Overload protection and load balancing spread legitimate load over several servers. In a cloud, the WAF then becomes one part of a larger delivery chain together with DNS, CDN and caching.
Go deeper:
Introduction to Azure Web Application Firewall — Microsoft Learn — a WAF integrated into Application Gateway and Front Door, with bot protection.- Google Cloud Armor — Preconfigured WAF rules overview — a cloud WAF's rule sets and sensitivity levels.
- DDoS mitigation — Wikipedia — how floods are detected and absorbed in front of a service.
Note saved — thanks!
Question
Which three areas are the classic hard cases for cyber security, and what makes each of them hard?
Answer
OT, legacy IT and cloud services — the first two are stuck in an earlier era whose isolation has since been broken open, and the third was built for a different model entirely.
* None of the three is careless — each is doing what it was designed for in a world that changed around it. *
| OT — operational technology | Legacy IT (on-premises) | Cloud service | |
|---|---|---|---|
| What it is | Networked cyber systems that control production plants | Grown on-premises IT running the core business | A service "as it is", designed to appeal to as many customer groups as possible |
| Technology era | Early perimeter security or before | The era of perimeter security | Its own — the technology is as it is, take it or leave it |
| What broke | Isolation opened up by business demands for interconnectivity | Network security broken open by manifold interactions | Nothing broke — it was never designed for your perimeter |
| Why security is hard | Insufficient hardware performance for security payload; compliance with production regulations, operational safety, Rückwirkungsfreiheit (no reaction back onto the controlled process) | Pronounced attack surface; the design never anticipated interconnectivity in public environments | Not compatible with perimeter security; public back doors such as admin portals and public-only services; security is not the primary selling point |
The unifying insight: none of the three is hard because someone was careless. Each is a system doing exactly what it was designed to do, in a world that changed the assumptions underneath it. OT was isolated and then connected; legacy IT was bounded and then interconnected; cloud was designed for many tenants and then asked to sit inside one company's border.
Tip: the OT constraint that surprises IT people most is Rückwirkungsfreiheit — a security measure must not act back on the controlled process. An agent that pauses a server for a scan is an inconvenience in IT and a safety event in a plant.
Go deeper:
- Wikipedia — Operational technology — the OT column in depth, including the isolation that business demands broke open.
Note saved — thanks!