As some of you may know, I've been working on the portable web application firewall (WAF) rule format for ages. I really believe the concept has potential so I keep coming back to it, making it a little bit better on every visit. At the same time I am closely listening to the WAF market, hoping to jump in with the format just at the right time. Although I can (and will) implement the format in ModSecurity, what I really want is to get as many WAF vendors on board to support the format. That may not be the easiest thing to do so the timing is of real importance.
The idea behind the project is to design a portable WAF rule format capable of "fixing" the known security issues in web applications. While the only proper solution is always to fix the root cause of a security issue, we must acknowledge that the fix can not be implemented straight away (for all sorts of reasons, some legal, some technical, some practical). It is all about minimising the window of opportunity - we want to be able to prevent exploitation of a vulnerability practically as soon as it is discovered.
There are four usage scenarious (I am using the term recipe to refer to a unit of knowledge that contains enough information to prevent vulnerability from being exploited):
- Vendor-provided recipes; While vendors may very well provide prompt upgrades and patches, not everyone can upgrade swiftly. Vendors may come to recognise this and decide to release protection recipes at the same time with the upgrades.
- Third-party recipes; Providing there is strong demand, third-parties may decide to offer protection recipes, for free or for a fee.
- Recipes written by hand; Larger environments may have many different brands of protection devices on their networks. Promoting a single format would enable knowledge to be shared in such environments.
- Automated recipe generation; It is sometimes not feasible nor practical to manually assess security in web applications. It is possible to get assessment tools to talk directly to protection devices. A web vulnerability scanner that discovers a problem is likely to know enough about it to be able to create a recipe as a temporary measure. Such recipe could be installed manually, or after it is review by the system administrator or the application developer.
Several big improvements were made to the format in the last iteration:
- Specification formalised; Unlike before, when one had to rely on my notes to understand the specifics of the project, this time you will be presented with a formal specification (in draft, of course). The specification explains the motivation behind the effort and the technical aspects.
- Metadata included; The format was expanded to include recipe metadata. While the metadata is not very important for those who write recipes by hand, it is very important to allow for automation.
- Communication protocols added; A whole new section was added introducing recipe publishing, repositories, and the corresponding communication protocols.
To conclude, the project is now close to its first official release. Allowing some time for feedback from the interested parties, in the next step a "release candidate" specification will be released at the same time as the Java-based reference implementation.
