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?

ASC Products are "Production Ready"

A recent blog post from Jeremiah Grossman caused a bit of discussion this past week. Jeremiah was trying to create a much needed chart showing all the different vendors who have an application scanning offering be it SaaS or a product, and be it dynamic scanning or static/source scanning. WAF vendors were not included. He rated each offering against a set of criteria. One criteria "Production Safe" struck me as a vague metric. Certainly scanning production systems has additional challenges that scanning internal test systems do not. How easily a product can be configured to overcome these challenges is critical. However, there was no clarification about how the chart defined "Production Safe."

In the comments of the post, Jeremiah stated:

Adjusting scan speed, simultaneous thread, and ensuring the tests themselves do not have active payloads is most common. Also very important is having a person mark forms as safe for testing. I'd argue though that these steps are function of people/process and not a feature of the scanner itself. Hence, no check mark.

This last sentence concerned me. It seemed to imply that scanners are not "production safe"... it's the people that use them that make them "production safe" or not. So I emailed Jeremiah for clarification.


I want to make sure I understand. Does your benchmark that "these steps are function of people/process and not a feature of the scanner itself" require a human driven SaaS offering to receive a checkbox under "Production Safe?" In other words by your criteria is it impossible for a product to be "production safe?"


I want to be careful as not to suggest my definition is set is stone. Im open to a better or more refined one. Having said that, I'd say if a scanner is testing forms blindly (for example / some links too) without human decision making, then this is inherently dangerous. As is injection executable code.  If however the forms are custom configured by "someone", then the tool can in theory run reasonably safely. This combo can be delivered by a service (SaaS/Consultant) in a package, but to the best of my knowledge products don't ship with enough AI to do it autonomously. I guess this is the crux of my distinction.

I responded:

Software is never going to, out of the box, "know" what it should and should not audit. It requires intelligence to properly configure and launch. Whether that intelligence is provided by the customer who is using the product or a man-behind-the-curtain using technology inside of  a SaaS offering should not matter. However you are making that  distinction.


I think the distinction matters a great deal from the customer perspective. The solution is production-safe upon pressing "Go" or  it isn't. Or maybe "production-safe" should have a qualifier like   ready-to-go production-safe or something.

Jeremiah later emailed me saying he was going round and round on his opinion and might have a few things wrong. Admittedly it is a tough point to articulate. Hopefully he will publicly clarify what "product safe" means. Regardless, the "how do you properly scan a production application" is an important discussion that the industry needs to have.

So let me state ASC's position: A scanner should be considered "production safe" if what it can and cannot crawl or audit can be configured and controlled by an informed user. We say unequivocally that HP's Application Security Center products are "Production Safe" as we provide a diverse group of settings that allow a user to:

  • Record macros to whitelist parts of the application to test

  • Step the product through a business process to focus the scanner to specific areas of your application

  • Use regexs to define what urls should or should not be crawled and/or audited.

  • Use regexs to define what HTML Forms should or should not be submitted or audited

  • Configure the number of threads used to crawl or audit the web server

  • Manually control speed through our proxy tool

  • Define file extensions or Mime-types to discard should the product inadvertently encounter them

  • Turn on/off execution of various technologies like Flash, JavaScript, etc.

Furthermore, from a customer experience point of view, we do everything we can to ensure our customers know how to use our products properly. We have a comprehensive 2 day training course that is included in nearly every product sale and additional training available. We have countless online videos, tutorials, and support documentation. We even offer a managed SaaS offering for ASC products. In short, we have multiple different efforts to ensure that our customers know how to use our products effectively from Day 1.

Remember: Scanning products should never be considered "fire and forget" tools. Care should always be used when configuring and launching a security assessment. This rule apples to application security scanners just as it applies to network security scanners and other security auditing tools. Any vendor who characterizes their products in a purely "fire and forget" fashion is irresponsible at best and flat out lying at worst.

The bottom line is as long as a tool has a diverse number of settings that allow you to easily control what it can and cannot be assessed, the tool can be used against production systems. An informed user, and not some animated piece of code makes something "Production Ready." Make sure you check for features to control the scope of the security assessment when evaluating any security tool.


HP Application Security Center on Twitter

You can now follow the HP Application Security Center on Twitter....we'll have frequent updates about a wide range of web application security topics and happenings. Join us at: 


Join the ASC groups on LinkedIn and Facebook

We'd like to invite you to join the new ASC groups on LinkedIn and Facebook. We’ll be posting videos, whitepapers, press releases, articles and other things there of interest to the security community.    


LinkedIn: http://www.linkedin.com/groups?viewMembers=&gid=1851238&sik=1237318704088


Facebook: http://www.facebook.com/home.php?#/group.php?gid=57440939557&ref=nf


HP’s Application Security Center helps protect businesses from malicious hackers through a full suite of application security software and services that enables customers to find, fix and prevent security vulnerabilities across the application life cycle. We are dedicated to researching, innovating, educating and improving our products and services to address the latest application security threats, trends and issues.


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.