Last updated at Wed, 15 May 2019 14:57:09 GMT

A common question I’ve received over many years in the tech industry is why we can’t just “figure out” all those pesky attackers and stop them once and for all. Part of the challenge, of course, is that we keep inventing new stuff. In 2002, I used my phone to … make phone calls, and play the occasional game of Snake. I now carry around a chunk of touch-screen glass, and I am pretty sure I spend most of my time reading on it.

Inventing new things requires protecting them, and the story of most technologies is one of evolution. As a result, there are many variations on the theme of “security is a continuous effort.” Here’s a collection of a few of them:

Because security is a continuous process, I thought it would be worthwhile to take a look back at the history of application security in a blog series to help describe where we have come from.

In the beginning, there was the firewall. This is almost pre-history, at least in “Internet time,” to use a horribly late 1990s phrase (for an amusing take, see this Harvard Business Review article). Early firewalls were not commercial products, and often involved some level of custom work. I was first introduced to the concept through Chapman & Zwicky’s 1995 classic, Building Internet Firewalls. Early firewalls were simple devices, and looked at network information like IP addresses and TCP port numbers. This was effective protection when every application had its own port number, and vulnerabilities used simple attack vectors, like the Morris worm.

Nothing has yet managed to kill the network firewall, but it was designed for a simpler era when applications self-identified by port number. Once applications migrated to the web and started using the same handful of ports, the network firewall ceased to be the main component of an application security strategy.

 

“Is this a firewall?”

First Generation Web App Firewalls: the Stateless WAF

Network firewalls restrict traffic by IP address and port number. Once applications migrated to the web, pretty much every application needed to keep port 80 open to the world for HTTP. (Well, make it two ports if you also count 443 for HTTPS.) Once applications all crowded together on just a few ports, all the action from a security perspective moved up the stack. (Although it is a joke, the Hypertext Coffee Pot Control Protocol, an Internet standard published on April 1, 1998, gently poked fun at the many ways — some inappropriate — that HTTP was extended.) To provide security, firewalls had to dig deeper. Cracking open the HTTP traffic itself to inspect content became the core task of what was named a Web Application Firewall, or WAF.

Early WAFs were “stateless,” and applied a filter to either the input to an application or the output from it. The filters were essentially complex pattern matches using regular expressions. Just as a network firewall matched port numbers, a WAF was matching textual patterns. Each expression was called a signature, often composed of several regular expressions that matched a particular attack.

Stateless signatures have several advantages. They are evaluated reasonably quickly because there is no need to keep complex state between invocations. When attacks are detected, it is possible to write an expression that catches the attack quickly, or perhaps completely blocks the attacker.

The major challenge of stateless signatures is that individual expressions are incredibly specific, so signatures can quickly become unmanageable. If a signature depended on a particular attack structure, it was usually possible to find an alternative formulation that was slightly different to avoid getting caught by the signature. This led to a cat-and-mouse game of the form:

  1. Attackers find a vulnerability
  2. You detect the vulnerability, and write a signature rule to stop the attack
  3. Attackers change the attack to evade the signature
  4. You add the new attack behavior into the signature to catch the revised attack
  5. Attackers change the attack to evade the signature
  6. You add the new attack behavior into the signature …
  7. …

And so on, until either the attackers or you give up. At this point, it was clear that the WAF needed a re-think to end the cat-and-mouse game. Next up in this series: the second generation of WAFs, and how we added state to make them much more manageable.