You have a secure development lifecycle, and you do perform a pen-test before going live, or rolling out an application in production; then why do you need a Web Application Firewall? At the end, it is one more security product where ROI is difficult to prove.
This is one of the most common question I have been asked when talking about application security. People are still conservative when it comes to buying a good WAF and implementing it across all applications. Common queries that are receive are,
- What's the use of WAF when my application is secure?
- What if the rules generate False Positive and my user/customers or business get locked out?
- I am using SSL; is WAF of any use?
- What's the different between a cheap vs. expensive WAF apropos features?
Most of the clients talk about following secure software development lifecycle (SSDLC). It is definitely good, and is required for strong code base. When they say SSDLC; it usually means performing all kinds of due-diligence before rolling the application to users.
If you are building a secure application with all the right ingredients then you must have acknowledged the importance of secure development. So, kudos to that. Now let's see if I can convince you the importance of WAF in the production environment.
What's the use of WAF when my application is secure?
A secure application is a very subjective term; it depends on the tools and technologies that supported you to reach this argument. It can be the SDLC framework you followed, or the continuous testing you performed with tools like Burp, AppScan, Checkmarx etc. Or, it can be the OWASP guidelines and requirements you implemented. But, everything is a moment of time. When you last performed the scan; the application was healthy, but after the launch a new bug has been reported in a framework/ library that can be exploited.
All the scans and assessments performed, even if done with perfection; are valid for a very short period when we have a fast changing threat landscape! The scans performed on v2.4 of a library with a tool like Fortify or Checkmarx might have detected 0 issues; but it may detect some next week or further down the line. Now, may be, you can have scheduled scans but again how about the delay between a 0day and scanning tools adding it to their repository? The delay can be days, months or even years depending how close guarded 0day it is.
So, in order to prevent you from any attacks you can be restrictive and proactive with the use of WAF and here's a real case where the 'unpatched' server was attacked, and protected with WAF
What if the rules generate False Positive and my user/customers or business gets locked out?
Good point. Yes, the WAF or the heuristic scanners of any sort have a tendency to go over the top depending on how lenient your rules are. Now, to avoid such scenario it is very important to provide custom rules instead of rulesets provided by firms (or products) or for discussion sake OWASP CRS. I don't have anything against these rulesets specially the OWASP Modsecurity CRS but if you want to be control; take the steering wheel and write your own rules depending on the crown jewels, application datasets, architecture and traffic expectations.
It takes time and efforts to write custom rules; or you can as well hire a consultant or a vendor firm to provide such MSS (managed security services). The approach is to go through the application and understand,
- Application architecture
- Features and flows
- Expected inputs for the data sets
- Database schema; what the custom can provide, or what an integrated component can process.
- Threat modelling (to understand what are you preventing, and what's the likelihood)
Once you have all this information, it can enable the consultant to write better rules and take decisions. The rules can just be for logging, or detect attack (probable for further investigation) or if you have a confirmed attack, a prevention rule! Act wisely, and keep a check.
I am using SSL; is WAF of any use?
That's a technical question and you should discuss with your solution/ technical architect. To answer this in simple terms - instead of terminating your SSL @ webserver; you will have to provide private key to the WAF to inspect the traffic. The WAF will behave as MITM (man in the middle) to have a look on the traffic, and allow, modify or drop it.
I wouldn’t suggest terminating the SSL connection at the perimeter (proxy or load balancer) as the traffic internally will be clear text which can be problematic as the internal attacks are much more prevalent than you tend to believe.
What's the different between a cheap vs. expensive WAF apropos features?
Finally, the cost, the ROI, the purchasing part. I understand it's always difficult to put a $$ value on security, but ask your risk guy - "What's the dollar amount if this this attack is successful" Multiply that will all the applications and add all the attacks - that's your ROI with an effective WAF.
I know the WAF is a tough call, especially the complexity it may require to setup and configure one good WAF; but it's all worth it. I would recommend taking it slowly. Start with a simple WAF; for example - if your applications are in the cloud like AWS, you are in luck. AWS has it's WAF which is simple to configure, straightforward to scale and protect all your applications.
Then there are complex WAF like Modsecurity (supported by OWASP) which is free, very well supported, maintained and can perform pretty much all complex tasks that your application traffic may ever need. Amazon WAF is like the application version of Network Firewall. It can accept, deny the traffic as per your needs. But remember, the WAF technology can not only inspect but modify the traffic as well (mind blown!!). It can modify the HTTP_REQUEST as well as the HTTP_RESPONSE depending on your rules.
So, I would say if you are new to the world of WAF, take it easy; start with something simple and easy just to get the hang of it. Then, scale it or ever buy a licensed one and hire some MSS wizards to work the magic! But do invest in WAF technology; it's worth it.
Thanks for the read, and do leave comments. If you want to reach me feel free to follow me on Twitter.
Cheers and stay safe.