As we discussed previously in The Trouble with WAFs, there are many reasons WAFs frustrate both security and application developers. But thanks to the ‘gift’ of PCI, many organizations have a WAF in-house, and now they want to use it (more) effectively. Which is a good thing, by the way. We also pointed out that many of the WAF issues our research has discovered were not problems with technology. There is entirely too much failure to effectively manage WAF.

So your friends at Securosis will map out a clear and pragmatic 3-phase approach to WAF management. Now for the caveats. There are no silver bullets. Not profiling apps. Not integration with vulnerability reporting and intelligence services. Not anything. Effectively managing your WAF requires an ongoing and significant commitment. In every aspect of the process, you will see the need to revisit everything, over and over again. We live in a dynamic world – which means a static ruleset won’t cut it. The sooner you accept that, the sooner you can achieve a singularity with your WAF. We will stop preaching now.

Manage Policies

At a high level you need to think of the WAF policy/rule base as a living, breathing entity. Applications evolve and change – typically on a daily basis – so WAF rules also need to evolve and change in lockstep. But before you can worry about evolving your rule base, you need to build it in the first place. We have identified 3 steps for doing that:

  1. Baseline Application Traffic: The first step in deploying a WAF is usually to let it observe your application traffic during a training period, so it can develop a reference baseline of ‘normal’ application behavior for all the applications on your network. This initial discovery process and associated baseline provides the basis for the initial ruleset, basically a whitelist of acceptable actions for each application.
  2. Understand the Application: The baseline represents the first draft of your rules. Then you apply a large dose of common sense to see which rules don’t make sense and what’s missing. You can do this by building threat models for dangerous edge cases and other situations to ensure nothing is missed.
  3. Protect against Attacks: Finally you will want to address typical attack patterns. This is similar to how an Intrusion Prevention System works at the network layer. This will block common but dangerous attacks such as SQLi and XSS.

Now you have your initial rule set, but it’s not time for Tetris yet. This milestone is only the beginning. We will going into detail on the issues and tradeoffs of policy management later in this series – for now we just want to capture the high-level approach. You need to constantly revisit the ruleset – both to deal with new attacks (based on what you get from your vendor’s research team and public vulnerability reporting organizations such as CERT), and to handle application changes. Which makes a good segue to the next step.

Application Lifecycle Integration

Let’s be candid – developers don’t like security folks, and vice-versa. Sure that’s a generalization, but it’s generally true. Worse, developers don’t like security tools that barrage them with huge amounts of stuff they’re supposed to fix – especially when the ‘spam’ includes many noisy inconsequential issues and/or totally bogus results. The security guy wielding a WAF is an outsider, and his reports are full of indigestible data, so they are likely to get stored in the circular file. It’s not that developers don’t believe there are issues – they know there’s tons of stuff that ought to be fixed, because they have been asked many times to take shortcuts to deliver code on deadline. And they know the backlog of functional stuff they would like to fix – over and above the threats reported by the WAF, dynamic app scans, and pen testers – is simply to large to deal with. Web-borne threat? Take a number.

Security folks wonder why the developers can’t build secure code, and developers feel security folks have no appreciation of their process or the pressure to ship working code. We said “working code” – not necessarily secure code, which is a big part of the problem. Now add Operations into the mix – they are responsible for making sure the systems run smoothly, and they really don’t want yet another system to manage on their network. They worry about performance, failover, ease of management and – at least as much as developers do – user experience.

This next step in the WAF management process involves collaboration between the proverbial irresistible force and immovable object to protect applications. Communication between groups is a starting point – providing filtered, prioritized, and digestible information to dev-ops is another hurdle to address. Further complicating matters are evolving development processes, various new development tools, and application deployment practices, which WAF products need to integrate with. Obviously you work with the developers to identify and eliminate security defects as early in the process as possible. But the security team needs to be realistic – adversely impacting a developer’s work process can have a dramatic negative impact on the quality and amount of code that gets shipped. And nobody likes that.

We have identified a set of critical success factors for integrating with the DLC (development lifecycle):

  1. Executive Sponsorship: If a developer can say ‘no’ to the security team, at some point they will. Either security is important or it isn’t. To move past a compliance WAF, security folks need the CIO or CEO to agree that the velocity of feature evolution must give way to addressing critical security flaws. Once management has made that commitment, developers can justify improving security as part of their job.
  2. Establish Expectations: Agree on what makes a critical issue, and how critical issues will be addressed among the pile of competing critical requirements. Set guidelines in advance so there are no arguments when issues arise.
  3. Security/Developer Integration Points: There need to be logical (and documented) steps within the application lifecycle for security checks, assessments, etc. This includes design and development integration points, as well as pre-launch validation steps with operations. Without formally security involvement, inevitably these steps will be skipped – especially at crunch time. Go back to point 1 above.
  4. Automation: Even with executive sponsorship and clearly documented integration points, without sufficient automation of security functions (scanning, testing, regression, etc.), inevitably things will get skipped, especially at crunch time. Are you seeing a pattern here? The person managing the WAF needs to filter out the noise before it gets to the development team, and provide actionable information.
  5. Feedback Loops: Finally, you need to be able to adapt both the application and the process based on feedback at all points in the collaboration. Nothing turns off either side faster than feeling unappreciated. Sure, that’s soft and straight out of a new-age success manual, but it’s still true.

If you find yourself lacking in any of those aspects, your likelihood of keeping your WAF current and effective is remote.

Securing the WAF

As we described in the series overview, the third part of the WAF Management process is to actually protect the WAF. We are talking both about setting up the device properly, and setting it up to thwart evasion techniques and avoid information leakage. Keep these security considerations in mind:

  1. Securing the Device: Unplug the device and bad things happen, right? Obviously controlling physical access is a must – as with any computing device. Increasingly you will also need to protect the WAF against a variety of denial of service (DoS) tactics that can render it useless.
  2. Provisioning/Managing Entitlements: Once the device is secure you need to ensure that only authorized folks can mess around with the ruleset and manage the device. You could look at technology like Privileged User Monitoring or just aggressively manage entitlements to the devices, but you need to ensure a savvy attacker cannot slip an ‘any-to-any’ rule into your device.
  3. Preventing Evasion: You need to pay attention to network architecture to ensure an attacker can’t just bypass the WAF to get a direct pipe into the application. WAF evasion is an emerging area of interest for security researchers, which means you need to stay abreast of new tactics to ensure your WAF has the opportunity to do its job.
  4. Rule Obscurity: Yes, security folks grimace when they hear the term ‘obscurity’, but know that sophisticated attackers will poke and prod your applications before trying to break in. They will use all sorts of tactics to learn as much about your WAF as they can, so they can understand how to evade it.

This isn’t an exhaustive list but it’s a start, with a few of the considerations for securing a WAF. But it doesn’t touch on the importance of WAF deployment architecture to all of the above. For example, implementing a managed WAF service takes the DoS attack out of play. Actually, it doesn’t eliminate the risk – but it becomes the service provider’s problem. There are also differences in performance characteristics and the provisioning process, depending on whether the device is on-premise or hosted by a service provider.

Another key to securing the WAF is ongoing testing to ensure that nothing changes unexpectedly. Just as the applications you protect are dynamic, so is the product used to protect it. Part of this process must be an ongoing commitment to penetration testing both the application and WAF. We will touch on all this in detail later in this series.

As you can see from the illustration, each step in the process spawns other ongoing processes. How better to build a process to protect applications than with nested loops and recursion? Okay, we’re kidding, but the end result is the same – every aspect of managing WAFs is an ongoing process. This is totally the antithesis of set it and forget it technology. And that is really the point of this series. To get optimal value from your WAF, you need to go in with your collective eyes open to the amount of effort required to both get and keep the WAF running.

Our next post will dig into the first step in the process: Manage Policies.