I remember when I first learned about Web application firewall technology. It seemed like magic to me: A device that could compensate for bad coding or unexpected/unintended web application functionality. It could do this by learning expected application behavior and then enforcing said behavior, even if the application itself was capable of allowing the unwanted behavior. The business case for such a technology is easily recognizable even more so today than it was in the mid- to early 2000’s when it first came out: the ability to have a device compensate for human error.
The potential cost savings of this type of technology either in physical costs or brand protection is easily explainable. Consider for one second the cost a particular adult dating site has incurred; not due to actual funds being stolen but due to PR expenditures and legal fees associated with the hack. At the end of the day, we are all just human and yes we can fix errors when we find them, but sometimes things aren’t even exploitable until they are. It is easy to see the value of a technology that can protect against this unknown risk.
To illustrate this unintended functionality risk let’s describe a simple SQL injection in the context of a story:
The year is 2003 and I have decided I want to break into your bank account. I don’t know anything about you other than your name, your wealth, that you portray yourself as tech savvy and you bank at Wealthy Man Bank. So I open an account at Wealthy Man Bank too. I get online account access (if you’re tech savvy you’ll be doing online banking) so I can see the syntax for the user name (now I know what your user name is). For argument’s sake, let’s say it was first initial, last name. Knowing a user name doesn’t get me in though, so nothing to worry about, right? Well, not quite true. I happen to be a budding SQL developer and I know that in the coding world 1=1 or a=a or 2=2 etc. means true. So in other words, I substitute this basic SQL statement for the for the password in the password field and voila! I’m in, and all your money is gone (note this type of SQL attack would likely not work today because developers are generally smarter than that now).
In the above example the hacker tricked the application into doing something it wasn’t programmed to do. This type of breach was recognized early on by the likes of the PCI-DSS council who decided to make secure code review and/or a WAF a requirement of credit card compliance in order to prevent it. Most organizations eventually chose to go the route of a WAF because although secure code review should be part of a best practice, it is usually a point-in-time static check… and almost all code today is dynamic and ever changing. It doesn’t help that we are human and we make mistakes. A true WAF, configured and managed correctly, solves that problem by enforcing only known good behavior. It has to have a positive and a negative enforcement architecture to truly achieve this.
Today we are spoiled for choices when it comes to WAF. We have multiple options for on-prem or in the cloud WAF, and we also have several other devices like next-gen firewalls and some Proxy technologies that say they protect against the OWASP top 10 risks. What makes some stand apart from others and why do you still need a real WAF?
First, let’s discuss what makes a WAF a WAF and where technology comes from. In the early days when companies like Terros first espoused this type of technology, our friends at Gartner labeled it as an IDS. The key thing that eventually differentiated it from and IDS/IPS with targeted OWASP signatures and still does is the ability to do positive application enforcement (enforce known good behaviors and block everything else). The WAF can and does have signatures, but the magic is in learning and enforcing the expected behavior. This official differentiation happened around the year 2006. The PCI-DSS council made their compliance requirement almost at the same time.
The problem with a WAF then as it is now and has always been is that it is a very interactive product. Most other security devices are to some extent set and forget, but a WAF is always high touch. Every time the application changes I have to touch the WAF to avoid false positive “blocks.” To illustrate what I mean, if I add a new feature to an application, the WAF will block it if it hasn’t seen it before and it should. A new feature would be unexpected behavior, a divergence from the baseline, so to speak. The only way to solve this is constant care and feeding. The problem is further exacerbated by the fact that the work or security team that runs the WAF don’t actually write the application code. They have to see the error or false positive, then get hold of the development team, etc. Due to this complexity of management, we found the adoption of WAF outside of the PCI compliance realm rather stunted and the success rate of people using the WAF for more than a checkmark mixed.
Over the past few years several changes have taken place in the WAF space. The biggest change has been the move to WAF as a service, both as a full SAAS offering and as a fully managed service. This change has been a boon for adoption as the complex setup and management has been greatly reduced. However, all is not as it seems. Remember the functionality that differentiated a WAF from an IPS or for that matter a next generation firewall, the ability to learn the application and enforce known good behavior? Well that doesn’t exist in most Cloud WAFs. I would contend that in fact there are only two WAF-as-a-service companies that actually offer a true cloud “WAF.” Remember folks, just because you call something by a particular name doesn’t make it so. What you get from the cloud hosting providers is often not a WAF, and what you get from anyone not offering positive enforcement capabilities is not a WAF.
Compounding this obvious problem is the fact that most large enterprises are stuck in a hybrid architectural scenario, with some of the assets protected behind hard-to-manage on-prem devices and some in the cloud behind a service. Most players in this space offer either an appliance or a service, not both. Worse, when they do offer both it’s not the same technology. Most on-prem solution are to a greater or lesser extent a WAF. Most cloud WAFs are in fact IPSs with a signature set tuned to protect against the OWASP top 10 threats. The limitation of signatures is not the only problem. It’s the fact that you will have to manage two different systems, pull reports form two different systems, etc. and not have a single point of contact from a support and management perspective.
The next-gen solutions that have come out over the past year have answered this challenge by offering a true WAF in the cloud that uses the same universal management and reporting console. On top of this, at least one Israeli-based organization offers a full managed services solution stack that covers both their physical appliances and their cloud SAAS offering. This allows organizations either transitioning to the cloud or who have a hybrid architecture to have a seamless experience. It also empowers organizations to now harness the full capabilities of a WAF, which were previously unattainable because of the high-touch, high-skill requirements.
In today’s world where web attacks are becoming ever more common and the cost of these attacks when successful ever higher, it is not worth selecting a solution for its substance rather than its name. Especially when the solution is roughly the same price and globally available, and unmistakably alone in answering the customer’s true needs.