WAF Is Not a Four Letter Word (Web Application Firewalls Don't Totally Suck!)

Let's start this conversation by postulating 3 immutable Laws of Application Security Testing (LAST):

 

1) No static application security testing tool (SAST) can catch 100% of software vulnerabilities during development (though tools like HP's Fortify SCA  do an extremely thorough job);

 

2) No black box testing/DAST tool can find 100% of the application vulnerabilities in live applications (though HP WebInspect identifies hard-to-find vulnerabilities, undetectable by traditional scanners, in the world of Web 2.0 and increasingly complex web apps);

 

3) #1 and #2 are always true even  if, as Voltaire's Dr. Pangloss erroneously states in Candide, we live in the "best of all possible worlds." In security, even the most forward-thinking organizations are riddled with strategy shortfalls, cost/benefit sacrifices, staffing holes, faulty implementations, and plain old human error. 

 

Application security purists, both inside and outside HP, often consider WAFs (Web Application Firewalls) to be crude, suboptimal tools used by the clumsy or lazy organizations that are not nimble, visionary, or skilled enough to implement static application security testing in the development lifecyle and dynamic application security testing for applications in production.

 

One of my most brilliant, esteemed colleagues recently dismissed the WAF as merely "a hack".

 

Conceptually, the purists are correct.

 

Unfortunately, entropy is an unavoidable fact in today's enterprises.

 

Consider this situation:

 

You're a typical large enterprise with hundreds of untested web applications, many of which capture critical sensitive data like credit card numbers and partner information. Today you decide to initiate a testing program, implementing both SAST (development code testing) and DAST (black box testing for live apps). Penetration tests are easier to start running first as your development organization gets comfortable with source code analysis, so you start there.

 

As you run penetration tests against your most sensitive applications, you begin finding vulnerabilities in payment system applications that put customers, partners, and your reputation at risk. The development organization has a long pipeline, and changing the code will take months. Taking the application down will cripple your cash flow, so that's a non-starter. Meanwhile, there's a chance that the detected vulnerabilities will remain unexploited, but that's a risk none of your senior managers are willing to take for ethical, compliance, legal, and marketing reasons.

 

What to do?   

 

Being able to implement a quick response to prevent a potential attack is critical. WAFs can quickly implement new policy settings to protect business-critical application until the source code fixes are live.

 

In addition, in the best of all possible worlds DAST tools would share intelligence with a WAF, providing vulnerability data to make the WAF more effective.

 

Again, some smart organizations (many of which are HP customers) are moving toward a "test everything in development and in production" model; however in cases where, for example, an application is out of support or the vendor provider is defunct, getting continued access to source code is problematic.

 

WAF is not a panacea. WAFs makes sense in some cases, not in others. A WAF is never a silver bullet substitute for secure coding/dynamic testing

 

"Test it and fix it" is always the correct optimal answer. "Shield it as it is waiting to be fixed" is the part of the answer - in certain use cases - that application security Panglosses don't want to hear.

 

I'm interested in what others think of the need for WAFs (and for DAST/WAF information sharing in certain real-world use cases. Am I out to lunch?

Comments
oreoshake | ‎11-17-2010 06:34 AM

That just comes down to the fundamental flaw of being a purist.  Anyone against WAFs in all situations has not been exposed to enough environments.  Of course, it's a terrible solution for some.  I've seen a WAF deployed VERY successfully and a WAF is the perfect solution at a given time for some organizations.

 

The sharing of data between these tools is a must.   Ryan Barnett had a good write up on the synergistic relationship between WAFs and DAST.  Virtual patching is crucial in a rapidly developing appsec program.  Metrics are good too :smileyhappy:  Over time, the number of alerts from your WAF and DAST decline in parallel.

 

And yes, a WAF is only temporary.  At the same time, I've seen organizations start with a WAF for the right reasons but the WAF turns into an excuse not to focus on other countermeasures.  Just  be smart, choose the right tool for the job at the time, and who knows, a WAF may be in your future.

 

And in the case of a set of highly business critical sight that is full of vulnerabilities...what...should we just take them down?  It's going to take a while to fix everything, even with a billion cooks in the kitchen.  I see only a few options: WAFs, hiring a very expensive consulting firm, or halting business. 

Adam_Hils | ‎11-17-2010 07:45 AM

@Oreoshake - I agree with almost everything you state here; it is true that, as information security programs within organizations become more mature, vulnerabilities and successful exploitations of those vulnerabilities become less frequent.

 

However, detecting vulnerabilities at every phase of the lifecycle, and mitigating them, must remain part of even the most advanced security approach. So long as humans write code, there will be vulnerabilities; so long as those vulnerabilities present bad guys an opportunity to make money, they will exploit the vulns. For mature organizations, black box testing becomes more streamlined, with less noise, and the results more easily expose critical vulnerabilities.

| ‎11-17-2010 06:49 PM

It's important to be clear about how a WAF should be used, and how a WAF shouldn't be used.

 

Should be used:

- to TEMPORARILY mitigate a problem (vulnerability, logic flaw, etc), buying time for developers to HASTILY implement a QUALITY solution in code/configuration.

 

Should not be used:

- to implement LONG TERM "solutions" to problems.

 

Also, I rekon that "as long as humans are looking for vulnerabilitieis, vulnerabilitieis will be found".

 

I've seen many cases where organisations don't even know who developed the systems they used...WAF also buys time for such horrendous blunders in management.

oreoshake | ‎11-19-2010 09:06 AM

One of the reasons I think WAFs must be temporary is there is a diminishing rate of return.  Of course, having another layer of security is nice, but at what cost?  WAFs take time to maintain, tune, etc.  I think there is a point at which dealing with false positives (if you have it in full blocking mode) becomes a bigger hastle than letting the application handle the attack (hopefully the WAF has "bought" you the time to mitigate the vulnerabilities).  So if a WAF is to stay around forver in an organization, I sure hope the scope is very limited.

 

Of course, having a WAF does make PCI compliance a little easier :smileywink:

Adam_Hils | ‎12-17-2010 09:27 AM

@whips04r - you are mostly right - but I submit that WAFs are useful on an ongoing basis as they become smarter as a component of a much larger security architecture.

 

@oreoshake re: PCI - yes, but dynamic application scanners are much better!

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation