[WASC-WAFEC] WAFEC v2 Step 1

Mark Kraynak mark at imperva.com
Fri Feb 18 20:41:20 EST 2011


Few comments related to the below

2. - 3.  Should a third party, such as http://www.nsslabs.com/, http://www.dsd.gov.au/infosec/aisep/providers.htm, etc, be endorsed to provide independence assurance of the claims made by various WAF vendors?

The ICSA already has a WAF certification program.  I think working with them to include some part of this in their process would be an easier (and maybe more cost effective) solution.

  b. Should it advocate as a long term strategy code review over WAF i.e. "virtual patching" should be considered short term?

This is a tried and true topic for endless debate.  In my experience, organizations for the most part fail at patching effectively and those that don't do the "short term" virtual patching get ineffective protection in the long term as their patching never happens or happens incorrectly.  Regardless, I think the spec for a WAF evaluation should be one step removed from taking a side in this issue.  If we could agree that virtual patching is a function to be expected of a WAF and that there are characteristics of how well a WAF does this that can be evaluated as a part of WAFEC, can we leave alone providing advice on what an organization's overall patching strategy should be?


From: wasc-wafec-bounces at lists.webappsec.org [mailto:wasc-wafec-bounces at lists.webappsec.org] On Behalf Of Christian Heinrich
Sent: Friday, February 18, 2011 5:35 PM
To: Wujek Thorsten [STEIN-IT GmbH]
Cc: wasc-wafec at lists.webappsec.org
Subject: Re: [WASC-WAFEC] WAFEC v2 Step 1

Wujek,

I would like to extend the thoughts from Ryan which I have quoted below:
On Fri, Feb 11, 2011 at 4:54 AM, Ryan Barnett <rcbarnett at gmail.com<mailto:rcbarnett at gmail.com>> wrote:
I will make these comments very brief (we can discuss them later in detail) -

 1.  WAFEC is primarily used as an RFP document for end users so we should focus on this from a data sharing perspective and come up with a different method (i.e - no more spreadsheets please...)
 2.  We need to have a minimum capabilities requirements section so end users know whether or not they should also be considering Palo Alto or TippingPoint.  What features are unique to WAF.
 3.  It would be great to have a decision tree type of interface where, depending on the end users main concern, they can get a customized view of data.  For instance - when they choose the deployment mode (out of line vs. reverse proxy vs. bridge), then the remaining sections are applicable (reference the deployment method capabilities matrix that Ivan linked to).  We could also expand this to cover use-case scenarios.  Basically, we could remove many "N/A" responses by simply removing it entirely from the view.
 4.  We should think about the structure of the document to see if there is a better order of topics.  As was already mentioned by Ivan - we should probably start with Use-Cases.  Why is the user interested in WAF?  PCI?  Recently Hacked?  These scenarios will dictate items such as deployment modes and blocking capabilities.

1. was the predominate use of how it was communicated to the Australian public i.e. http://www.computerworld.com.au/article/148671/web_application_firewalls_prime_integrators/

2. - 3.  Should a third party, such as http://www.nsslabs.com/, http://www.dsd.gov.au/infosec/aisep/providers.htm, etc, be endorsed to provide independence assurance of the claims made by various WAF vendors?

4. Specific to PCI 6.6 i.e. https://www.pcisecuritystandards.org/documents/infosupp_6_6_applicationfirewalls_codereviews.pdf -
  a. Would v2 be able to provide more indepth technical examples of "virtual patching" and ROI?
  b. Should it advocate as a long term strategy code review over WAF i.e. "virtual patching" should be considered short term?


--
Regards,
Christian Heinrich

http://www.linkedin.com/in/ChristianHeinrich

Mobile: +61 433 510 532 (AEST +10 GMT/UTC)
SkypeID: cmlh.id.au<http://cmlh.id.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/wasc-wafec_lists.webappsec.org/attachments/20110218/efb8a14b/attachment-0003.html>


More information about the wasc-wafec mailing list