Mark Kraynak mark at imperva.com
Wed Feb 23 03:40:08 EST 2011

The first set of links (attrition.org) is indeed pretty old.  In my work with the ICSA I've found them to be at least as competent/authentic/etc as NSS (whom I've interacted with much less).  I don't have any experience with AISEF. As with anything YMMV. The problem I would foresee with independent testing is that to get it right, and more importantly to secure the cooperation of vendors, there needs to be a process by which the vendor can respond to any configuration errors that might result in their offering testing less well that it should. ICSA has a process for this that seems to work in getting vendor cooperation.  I haven't seen this from either of the other organizations you cite (though, again, I've worked with them less/none at all).

On the other point, I'm confused. Are you saying that the WAF's ability to perform input/output validations should not be a part of the WAFEC?

-----Original Message-----
From: Christian Heinrich [mailto:christian.heinrich at cmlh.id.au] 
Sent: Saturday, February 19, 2011 2:10 PM
To: Mark Kraynak
Cc: wasc-wafec at lists.webappsec.org
Subject: Re: [WASC-WAFEC] WAFEC v2 Step 1


On Sat, Feb 19, 2011 at 12:41 PM, Mark Kraynak <mark at imperva.com> wrote:
> 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.

I would prefer to avoid ICSA due to their lack of creditability based
on http://attrition.org/errata/charlatan/icsa_labs/ and more recently
the non-event that was http://www.antievasion.com/

On Sat, Feb 19, 2011 at 12:41 PM, Mark Kraynak <mark at imperva.com> wrote:
> 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?

To clarify, I wasn't referring to the patching strategy, rather that a
WAF isn't the solution for poor coding, such as input/output

Ultimately, if this body of work is to be accepted by the community
and not met with skepticism then it must address the root cause.

Christian Heinrich


Mobile: +61 433 510 532 (AEST +10 GMT/UTC)
SkypeID: cmlh.id.au

More information about the wasc-wafec mailing list