The need for web application firewalls
If you don’t perfectly see the difference between a firewall and a web application firewall, I recommend you read this article we published a few weeks ago, explaining the differences: Traditional Firewalls or Web Application Firewalls?
The reality of threats makes web application firewalls a real complementary approach to secure coding practices and security testing.
Global protection against known (and unknown) attacks, virtual patching and security events reporting are real added values.
An evolving market
The WAF market landscape is constantly changing, and regularly welcomes newcomers. It includes different types of vendors: WAF pure players, cloud service providers, open source softwares, general security vendors, ADC vendors…
We have also seen recent mergers and acquisitions between these actors, highlighting the dynamic evolution of the market.
Actually the WAF market is evolving as much as the threat landscape does. WAF products have to move quickly to remain efficient and provide an effective protection to web applications.
Considering this context, it is obvious that organizations must understand the characteristics of available WAF offers, before determining the product that fits their needs.
For instance, some web app firewalls are designed to meet the highest demands of very big companies, whereas some others are less powerful and efficient, but much cheaper (some open source WAF are even free). Some web application firewalls ship with a full package of services like optimization features and identity management modules: is it something you need?
How to choose your WAF?
Adding a WAF to your IT infrastructure is a real project that must be managed properly in order to avoid mistakes and wrong choices.
Involve the right people
Having the right people in your WAF project is a key success criteria.
Do some of your colleagues have a previous experience in web app firewalls?
You should obviously involve people managing the web apps you need to protect and people involved in the global security strategy of your company.
Now that you have the right people, what will be their respective roles and responsibilities? Essential points to be discussed are:
- Who will participate in the initial setup of the WAF
- Who will be responsible for the maintenance and fine tuning. Web applications folks certainly have their role here, but security teams too.
Gather and validate the requirements
You may have come to this idea of adding a WAF to your infrastructure for a public-facing website. But what about protecting your internal apps or other partner/private applications?
You should also consider your future needs in terms of protection and anticipate infrastructure evolution needs. If you have an additional website to put under the protection scope of the WAF at a later stage, will it be easy to do so?
Choose an adequate deployment option
Deployment options are not very numerous, but are still numerous enough for the question to be raised.
A web application firewall can be:
- An endpoint on the web server itself
- A hardware appliance of software application (virtual machine)
- A software module hosted on an ADC (Application Delivery Controller)
- A cloud service
Which one is the most suitable to your existing infrastructure?
The configuration type can also vary. The first two options are the most common.
- inline (reverse proxy)
- transparent proxy
- network bridge
- out-of-band (working on a copy of the traffic)
Each deployment type and configuration type comes with its list of challenges and constraints and there is a clear need for an analysis before implementing any of them.
Compare WAF offers
That’s the most challenging part of the project.
Reading through the commercial ads, videos and datasheets is not enough if you want to ensure the WAF will cover all your needs.
As an example, most WAF vendors say their product protects you against SQL injections and more globally against the OWASP Top 10. But this simple statement does actually hide discrepancies between WAF in the way they detect and handle this type of attack. SQL injection can be quite different from one to another, and less or more difficult to detect.
Attackers look at this point in terms of “evasion”: One specific WAF = specific evasion techniques to go through the WAF without being caught.
The same kind of question arises when it comes to other threat types, exceptions management, updates, signatures management, to name a few.
Some questions to be asked:
- Is the WAF offer a dedicated and main product in the vendor’s portfolio? Or is it just an additional feature sold as a module within a global network/infrastructure offer?
- How does the vendor assess the efficiency of its protections?
- How does the vendor’s technology handle known evasion techniques, and anticipate future variants?
- What commercial model does the WAF provider use (pricing)?
- How quickly does the vendor push updates to its product to cover new types of attacks?
In conclusion, choosing a WAF is a real project with high stakes, requiring a rigorous approach. Do not hesitate to get in touch with experts if you wish to be accompanied.