This is what Google Search had to say when I searched for ‘WAF’…
Obviously, this didn’t satisfy me at all. So, deciding to try something less ambiguous, I typed in: ‘What is a web application firewall?’ and got back:
(OWASP)
‘Appliance, server plugin, or filter that applies a set of rules to an HTTP conversation’ Not something you would find on your average website owner’s wish-list. This cold and obscure definition doesn’t really hit home with me, and I’m sure that is also doesn’t provide much value to the average consumer, as it simply fails to explain the real value that WAF technology can offer.
So why did these security experts fail in defining what a WAF really is? Being part of this industry for the past nine years, I can safely say that the reason is this: there is a gap between what most Web Application Security providers think web application security is about, and what the majority of websites owners think they need in a web security product.
And so, while most WAF literature talks about things like the technicalities of the different flavors of SQL Injection, the majority of website owners are dealing with practical day-to-day issues. Those issues may include preventing spam on their product comments page, trying to find a backdoor (planted via some vulnerable WP plugin) or hitting their shared hosting bandwidth quota just because somebody invented a search engine that just has to crawl every website five times a day
These are all real-world issues, issues that deserve serious, real-world solutions. Still, most WAF vendors (even new ones) will not try to solve or even acknowledge them – focusing instead on developing yet another signature-based SQL Injection and Cross Site Scripting filter. This is the gap I’m talking about: WAF vendors on one side, and customer needs on the other.
Why does this gap exist? Well, for starters, I guess you could call it ‘tradition’ Up until recently, WAF technology was marketed only to very large enterprises. Such companies had their own unique requirements for security, regulation and integration. These requirements, which shaped the first commercial web applications firewals, still continue to influence the world views of modern-day mass market WAF providers, who are simply failing to keep pace with the changes in their target audiences.
Another reason for the existence of the gap is the multitude of groups that have taken on themselves the important mission of educating the world about web application security. Such groups are mostly dominated by people from the scanning, pen testing, and secure coding industries, and their point of view is somewhat distant from the average Joe, who is just trying to build a Joomla ecommerce site. Like the industry they aim to represent, these experts mostly fail to look beyond the code and see the full spectrum of real-life security issues.
5 Steps for Closing the Gap
The good news is that things are changing, and they are changing fast.
New web application security services are blooming, and they now bridge between the security industry and practical customer needs. These services offer a simple, easy-to-use solution to practical, real-world security issues. By doing so, they create a domino effect in the industry – as a result of which basic WAF requirements must adapt and evolve. Although it is still too early to say what the WAF will eventually transform into, there are some key concepts that should be adopted as new standards for this new emerging breed of WAFs, namely:
1. Security as a Service
First and foremost, modern web application security solutions should be a packaged and self-contained service. After all, unless you have the means to build and fund your own dedicated security team, you won’t be able to deal with constant maintenance required by old school security solutions. Moreover, even those who can afford the extra budget and manpower, still shouldn’t waste it unnecessarily – not when there are better, more self-reliant solutions out there. Even as we speak, some security vendors (like Incapsula) can already offer great self-contained SaaS solutions, and I have no doubt that more and more companies will choose to rely on such services, instead of spending additional funds on less efficient in-house security products.
2. Hit the Ground Running
All WAFs have to work out of the box. No excuses. This means default settings that can provide zero false negatives and zero to none false positives. And why am I accepting no excuses? Well because we, as an industry, had more than 10 years to play around and now it’s our turn to deliver. As strange as it may seem, non-enterprise companies have the same (if not higher) standards for security as the big guys. For these guys EVERY sale counts, and in today’s extremely competitive online market anything less than a bullet-proof WAF just won’t do.
3. Think outside of OWASP
Website problems don’t start and end with SQL Injection and Cross Site Scripting. Who’s job is it to stop those comment spammers? Who’s going to prevent your entire price list from being scraped directly from your website? And who’s going to make sure that no one guesses your administrator password? I don’t believe that people should have to use different security solutions to deal with all these problems. Why would they? The WAF is your bouncer and the WAF should kick out any troublemakers, no matter their category.
4. See Beyond Code , Understand Interactions
WAF’s point of view should change. Instead of viewing the world as a series of HTTP requests it should see it for what it really is: people and bots in meaningful interactions with the website. WAFs have to monitor these interactions and be able to understand them. This means they should be able to precisely identify website visitors, track their reputation and behavior, and understand their motives and actions. Such ability can provide much greater flexibility, accuracy and efficiency when encountering new, yet to be identified, threats. The old and stiff method of ‘see a threat – block a threat’ is defunct. The new thinking should be: see a visitor, understand that visitor.
5. Spill all the Beans
Finally, a WAF should be your go-to guy, when it comes to monitoring and traffic analysis. Your WAF should be the one to tell you everything your application and analytics tools won’t. It should tell you about those smarty-pants GoogleBot impersonators searching for sensitive content and slipping under your radar. It should tell you about that botnet mimicking real user interaction but really filling your forums with spam comments (leaving you awake at night to moderate) and it should also inform you about that backdoor you have on your site, which is now being used to launch DDoS attacks on other websites. Why should the WAF do all that you ask? Well, because it can – and thus, it should.
What’s next?
Going back to my original question, for me a WAF is the bouncer at your website’s door step – a big and bulky fella who understands his job better than anybody else, has a good eye for troublemakers and is always in the know. To put it simply, a WAF keeps bad guys out and lets the good guys in, while telling you what’s happening on the premises.
This broad definition should be the basis for higher expectations from WAFs and for new technologies like Client Based Access Control, Collaborative Security and Visitor Reputation – which, I believe, will become part of the new standard for WAFs. As 2013 dawns, it is definitely an interesting time to be involved in the web application security domain.
Stay Safe
Eldad Chai,Director of Product Management
Try Imperva for Free
Protect your business for 30 days on Imperva.
