[WASC-WAFEC] What should we change in WAFEC 2.0?

Kit Wetzler Kit.Wetzler at citrix.com
Wed Jun 6 17:09:38 EDT 2012


1.       speaking on behalf of Citrix, I actually agree with Mark.  I'd like our WAF to be evaluated on it's own merits.  Yes, it integrates into the NetScaler ADC, but that shouldn't in the WAFEC.   The WAFEC should be criteria to choose a WAF, not an entire ecosystem, as most WAF customers already have an ADC infrastructure of some sort.

2.        Yes, cross site request forgery, etc (and many other threats) would be helpful.

3.       From a use case perspective, it would be helpful to distinguish different products - proxying vs SPAN port vs transparent, and the level of blocking - RSTs, buffering and proxying the request, or just logging/alerting, etc.  (all valid deployment models going towards different goals)

4.       I'd like to see the list categorized into security features, logging/alerting, etc.  This would help users of the list identify what is important and not important (which will vary quite a bit between use cases)

5.       Agreed.  It's up to the consumer to decide whether or not to fix code, and not the job of the WAFEC to decide that.

6.       Agreed with Mark.  The more we can make this a list that consumers can use to decide which solution to use, the more it will be used.

--
Kit Wetzler
Sr. Manager, Sales Engineering - West Region
Citrix Systems, Inc
Networking and Cloud Product Group (NetScaler, Branch Repeater and Access Gateway)
408.892.1424
kit.wetzler at citrix.com<mailto:kit.wetzler at citrix.com>

From: wasc-wafec-bounces at lists.webappsec.org [mailto:wasc-wafec-bounces at lists.webappsec.org] On Behalf Of Mark Kraynak
Sent: Wednesday, June 06, 2012 1:54 PM
To: Ofer Shezaf; wasc-wafec at lists.webappsec.org
Subject: Re: [WASC-WAFEC] What should we change in WAFEC 2.0?

My thoughts are:

1 - I agree with Ofer to remove the non WAF related criteria.  I realize this will come down to the camp of those that focus on those things (e.g., Ido&F5) and those that don't (e.g., me&Imperva).  Perhaps a compromise would be to have a section for "related capabilities" outside of the main flow.

2 - we need to have some sort of update on threats.  This normally turns into a complicated discussion of the ontology of threat classification.  Is there a way to avoid that?

3 - I think the issue that came up here was that the usage of the document and the content of it were at odds.  In particular, when used as a template evaluation tool without any processing (which it often is), it results in conflicting "requirements" to evaluate against, especially with regard to deployment mode. I'd suggest taking a middle ground and keeping the deployment modes section, but changing the nature of the content to better explain and lend itself to a non-conflicting evaluation, but also to include customer goals / use cases as a section.

I also think that the use cases section could help us solve #2.

4 - my opinion would be to keep a flat list, but to provide a tool that let's the customer adjust importance based on their needs.

5 - I would leave this out of the criteria (since WAFs don't fix code it doesn't make sense to have fixing code as an evaluation element).  IMO, this is a better topic for a different kind of forum...this tool is supposed to be a tool to evaluate WAFs.

6 - I think really orienting the criteria to be useable framework for an actual evaluation will make this simpler.

From: wasc-wafec-bounces at lists.webappsec.org<mailto:wasc-wafec-bounces at lists.webappsec.org> [mailto:wasc-wafec-bounces at lists.webappsec.org]<mailto:[mailto:wasc-wafec-bounces at lists.webappsec.org]> On Behalf Of Ofer Shezaf
Sent: Wednesday, June 06, 2012 4:39 AM
To: wasc-wafec at lists.webappsec.org<mailto:wasc-wafec at lists.webappsec.org>
Subject: [WASC-WAFEC] What should we change in WAFEC 2.0?


Since you are all very quiet, I understand that WAFEC 2 will solve my pain and needs only :)

To that end, let me start with summarizing issues raised in the previous discussions on the mailing list (which I actually went and read...).

No specific order intended. This is what you wrote, though I must say I think it captures well the issues I am aware of and that generally speaking I agree with most.


1.       Remove non WAF related criteria for example around application delivery.

*         While integrating a WAF with other solutions is compelling to the client, it is not directly about WAFs and is also unbounded. This does present the challenge deciding what is relevant to a WAF in border cases such as an SSO functionality

2.       Update the list of threats covered

3.       Focus on customer use cases rather than how a WAF operates

*         I think there was some hidden controversy here as I read opinions to focus on "technical" which I take to be opposite. I personally very much agree with this comment.

4.       Not just a laundry list -

*         Classify the importance of requirements. I believe that a minimal approach specifying several levels, for example: "mandatory", "important", "nice to have" and "site specific".

*         Another complementing idea is to classify requirements as "security"/"functionality"/"performance" etc. letting the user determine if he prefers security over functionality etc.

*         This would also provide the minimum requirements for a solution to be a WAF - the "mandatory" requirements.

*         Regarding site specific requirements, it should be easy to the user to determine his own requirements, for example using a decision tree.

5.       The "ethical" questions:

*         How to address alternative solutions such as fixing the code?

6.       Outreach - beyond the document

*         Approaching NSS, ICSA and the likes to use WAFEC

*         Release process, PR etc.

*         Managing a list of public references to WAFEC

*         Promote actual evaluations data sharing - No more spreadsheets.

7.       Specific notes on V1, I have collected for further work.

A major question raised with opinions on both sides was a re-write vs. an update. I do think that understanding the requirements should direct that. Some issues raised which directly relate to that are:

1.       Is the order of sections correct?

2.       Incorporating the German OWASP chapter work on the same subject: http://www.owasp.org/index.php/Best_Practices:_Web_Application_Firewalls

~ Ofer

From: Ofer Shezaf [mailto:ofer at shezaf.com]
Sent: Thursday, May 31, 2012 1:45 PM
To: wasc-wafec at lists.webappsec.org<mailto:wasc-wafec at lists.webappsec.org>
Subject: WAFEC 2.0 phase 1: exploratory discussion (deadline: June 14th)

Thanks to all who volunteered to contribute to this project going forward (and those who didn't - you still can!)

I would like to boot up the project with a short exploratory phase identifying why we need a new release and therefore what we need in it.

To guide the discussion, I think that the reasons we need v2 fall into two categories:
1.      Things that have changed - new (or obsolete) deployment modes, techniques, attacks, or even something new altogether.
2.      Issues we discovered in WAFEC over the years. Some issues I encountered are identifying specific requirements and sorting out what's important and what's not.

>From this discussion I hope to derive a mission statement, a tasks list and therefore a schedule for the V2 project. All those will be the next phase.

I would give this phase two weeks (until June 14th), however I am on vacation from the 9th, so would accept input but not join the discussion on the last few days.

I would also want to thank Thorsten and Mirko for leading the project until now. I do hope that I will get from you all more cooperation than they did! I would also want to extend a personal apology to Thorsten and Mirko as the leader switch was not well coordinated. Thorsten and I discussed this over the last week and he gracefully agreed to let me give a try to leading this project forward.

Thank you all!
~ Ofer

Ofer Shezaf
[+972-54-4431119; ofer at shezaf.com<mailto:ofer at shezaf.com>, www.shezaf.com<http://www.shezaf.com>]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/wasc-wafec_lists.webappsec.org/attachments/20120606/14c069ef/attachment-0003.html>


More information about the wasc-wafec mailing list