HP Security Products Blog
From applications to infrastructure, enterprises and governments alike face a constant barrage of digital attacks designed to steal data, cripple networks, damage brands, and perform a host of other malicious intents. HP Enterprise Security Products offers products and services that help organizations meet the security demands of a rapidly changing and more dangerous world. HP ESP enables businesses and institutions to take a proactive approach to security that integrates information correlation, deep application analysis and network-level defense mechanisms—unifying the components of a complete security program and reducing risk across your enterprise. In this blog, we will announce the latest offerings from HP ESP, discuss current trends in vulnerability research and technology, reveal new HP ESP security initiatives and promote our upcoming appearances and speaking engagements.

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?

Showing results for 
Search instead for 
Do you mean 
About the Author(s)
HP Blog

HP Software Solutions Blog


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.