wasc-wafec@lists.webappsec.org
WASC Web Application Firewall Evaluation Criteria Project Mailing List
View all threadsWAFEC v2 Step 1
Mark,
On Sat, Feb 19, 2011 at 12:41 PM, Mark Kraynak mark@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@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
validation.
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.
--
Regards,
Christian Heinrich
http://www.linkedin.com/in/ChristianHeinrich
Mobile: +61 433 510 532 (AEST +10 GMT/UTC)
SkypeID: cmlh.id.au
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@cmlh.id.au]
Sent: Saturday, February 19, 2011 2:10 PM
To: Mark Kraynak
Cc: wasc-wafec@lists.webappsec.org
Subject: Re: [WASC-WAFEC] WAFEC v2 Step 1
Mark,
On Sat, Feb 19, 2011 at 12:41 PM, Mark Kraynak mark@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@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
validation.
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.
--
Regards,
Christian Heinrich
http://www.linkedin.com/in/ChristianHeinrich
Mobile: +61 433 510 532 (AEST +10 GMT/UTC)
SkypeID: cmlh.id.au
Hi Christian,
I think that Mark described accurately how customers are using WAFs, eventually, fixing a vulnerability at the code level in addition to WAF (or some will say instead of WAF) is strictly a business decision, I am not sure that educating customers on how to perform risk assessment falls into the scope of WAFEC, this is just a too heavy subject, In addition, because it is a business decision and every business is different, there isn't a right or wrong here. I do believe that the audience that WAFEC is speaking to, understands it.
-----Original Message-----
From: wasc-wafec-bounces@lists.webappsec.org [mailto:wasc-wafec-bounces@lists.webappsec.org] On Behalf Of Christian Heinrich
Sent: Sunday, February 20, 2011 12:10 AM
To: Mark Kraynak
Cc: wasc-wafec@lists.webappsec.org
Subject: Re: [WASC-WAFEC] WAFEC v2 Step 1
Mark,
On Sat, Feb 19, 2011 at 12:41 PM, Mark Kraynak mark@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@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 validation.
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.
--
Regards,
Christian Heinrich
http://www.linkedin.com/in/ChristianHeinrich
Mobile: +61 433 510 532 (AEST +10 GMT/UTC)
SkypeID: cmlh.id.au
wasc-wafec mailing list
wasc-wafec@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/wasc-wafec_lists.webappsec.org
Am 23.02.2011 11:18, schrieb Ido Breger:
Hi Christian,
I think that Mark described accurately how customers are using WAFs, eventually, fixing a vulnerability at the code level in addition to WAF (or some will say instead of WAF) is strictly a business decision, I am not sure that educating customers on how to perform risk assessment falls into the scope of WAFEC, this is just a too heavy subject, In addition, because it is a business decision and every business is different, there isn't a right or wrong here. I do believe that the audience that WAFEC is speaking to, understands it.
The "business decission" is covered (at least partially) in
http://www.owasp.org/index.php/Best_Practices:_Web_Application_Firewalls
(as I already explained in an earlyer mail)
I suggest that the members of this list or the maintainer) makes a decission about
the scope and borders of what WAFEC v2 should describe.
Achim
Mark,
On Wed, Feb 23, 2011 at 7:40 PM, Mark Kraynak mark@imperva.com wrote:
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).
My experience with ICSA is rather dated i.e. when ICSA was referred to
as "National" i.e. NCSA
I believe a more recent comparison of the creditability of ICSA vs NSS
could be http://seclists.org/dailydave/2010/q4/10
That stated, we should leverage your contacts within ICSA to assist
with the creation of a methodology for evaluating WAF that is
repeatable by the end user?
I can also extend an invitation to
http://www.dsd.gov.au/infosec/aisep/providers.htm if needed?
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?
To clarify, I was stating that input/output validation (as an example)
could be performed by a WAF until the controls are within the web app
in which case they could co-exist as "defense in depth".
That stated, I believe that input/output validation should be
specified as a requirement during procurement in which to be built-in
to the web application.
--
Regards,
Christian Heinrich
http://www.linkedin.com/in/ChristianHeinrich
Mobile: +61 433 510 532 (AEST +10 GMT/UTC)
SkypeID: cmlh.id.au
Ido,
On Wed, Feb 23, 2011 at 9:18 PM, Ido Breger I.Breger@f5.com wrote:
Hi Christian,
I think that Mark described accurately how customers are using WAFs, eventually, fixing a vulnerability at the code level in addition to WAF (or some will say instead of WAF) is strictly a business decision, I am not sure that educating customers on how to perform risk assessment falls into the scope of WAFEC, this is just a too heavy subject, In addition, because it is a business decision and every business is different, there isn't a right or wrong here. I do believe that the audience that WAFEC is speaking to, understands it.
Economics would indicate that a "business" would accept the inherit
risk of poor web application security controls as the residual risk
can be mitigated by a WAF.
I am not expecting the WAFEC v2 to address this in detail, rather my
expectation would be a paragraph or two which mentions references for
further information towards the first few pages of the document.
--
Regards,
Christian Heinrich
http://www.linkedin.com/in/ChristianHeinrich
Mobile: +61 433 510 532 (AEST +10 GMT/UTC)
SkypeID: cmlh.id.au
Mark,
On Thu, Feb 24, 2011 at 10:08 AM, Christian Heinrich
christian.heinrich@cmlh.id.au wrote:
I believe a more recent comparison of the creditability of ICSA vs NSS
could be http://seclists.org/dailydave/2010/q4/10
Bob Walder (NSS) did contribute to WAFEC v1.0
He is with http://www.gartner.com/AnalystBiography?authorId=36989 now
- does anyone have his contact information @gartner?
--
Regards,
Christian Heinrich
http://www.linkedin.com/in/ChristianHeinrich
Mobile: +61 433 510 532 (AEST +10 GMT/UTC)
SkypeID: cmlh.id.au