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

Ofer Shezaf ofer at shezaf.com
Mon Jun 18 08:49:54 EDT 2012


Hi All, 

Thanks for a very lively and sincere discussion. In the next couple of days
I will summarize and build a draft mission statement which should address
the issues at hand. If we will find areas in which opinions are too divided
I will suggest a resolution process.

Thanks! 
~ Ofer

-----Original Message-----
From: wasc-wafec-bounces at lists.webappsec.org
[mailto:wasc-wafec-bounces at lists.webappsec.org] On Behalf Of Alexander
Meisel
Sent: Monday, June 18, 2012 2:12 PM
To: wasc-wafec at lists.webappsec.org
Subject: Re: [WASC-WAFEC] What should we change in WAFEC 2.0?

Hi Kenneth,

I disagree with your take on this ...
SSLvpn has nothing to do with WAF so it should not even be mentioned.
Whatever your device does aside from WAF should not be part of the WAFec.
Your devices consumes power as well. So should you mention all regional
certifications in WAFec as well (it complies to; like TÜV, FCC etc.) ...
probably not.

	Alex



On 07.06.12 18:15, Kenneth Salchow wrote:
> On #1:
> 
>  
> 
> I think it is beneficial to at least make the ease with which a WAF
> **does** integrate with other solutions or a list of solutions that 
> the WAF has documented integration with a criterion for a WAF.  No one 
> is ever going to buy a WAF and deploy it by itself without anything 
> else around it.
> 
>  
> 
> As a customer, I probably already have a number of other solutions and 
> it would be extremely valuable for me to know if any given WAF 
> innately integrates with those other solutions or has an easy, 
> documented ability to do so.  I might also be looking at other 
> solutions at the same time I am deploying a WAF and knowing what all 
> my option are is also extremely valuable.
> 
>  
> 
> So 
 we don’t have to compare WAFs by saying “oh, we have SSL VPN and 
> yours doesn’t” as that is not a specific WAF criterion, but it **is** 
> very relevant and important to a customer who is evaluating these 
> devices to know if the solution will integrate with their existing VPN 
> or has options available to integrate with one down the road. (and I 
> just picked SSL VPN off the top of my head, it could be SSO or whatever).
> 
>  
> 
>  
> 
> *KJ (Ken) Salchow, Jr.*| Program Manager, Technical Certification
> 
> *D 651.423.1133*
> 
> 	
> 
> *M 612.868.1258*
> 
> 	
> 
> *P 206.272.5555*
> 
> 	
> 
> *F 206.272.5555*
> 
> 	
> 
> *www.f5.com <http://www.f5.com/>*
> 
> Description: Description: F5_Logo-TechCert_TM_042312sm
> 
>  
> 
>  
> 
>  
> 
> *From:*wasc-wafec-bounces at lists.webappsec.org
> [mailto:wasc-wafec-bounces at lists.webappsec.org] *On Behalf Of *Kit 
> Wetzler
> *Sent:* Wednesday, June 06, 2012 4:10 PM
> *To:* wasc-wafec at lists.webappsec.org
> *Subject:* Re: [WASC-WAFEC] What should we change in WAFEC 2.0?
> 
>  
> 
> 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>
> [mailto:wasc-wafec-bounces at lists.webappsec.org]
> <mailto:[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 
> <mailto: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 J
> 
>  
> 
> 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_Firewal
> ls
> 
>  
> 
> ~ 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 14^th ), however I am 
> on vacation from the 9^th , 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>]
> 
>  
> 
> 
> 
> _______________________________________________
> wasc-wafec mailing list
> wasc-wafec at lists.webappsec.org
> http://lists.webappsec.org/mailman/listinfo/wasc-wafec_lists.webappsec
> .org


--
Alexander Meisel (VP Sec Products) - alexander.meisel at artofdefence.com
T:+49 941 604 889 28  M:+49 160 9644 1812  F:+49 941 604 889 837 Zeus
Technology GmbH, Bruderwöhrdstr. 15b, 93055 Regensburg, Germany

_______________________________________________
wasc-wafec mailing list
wasc-wafec at lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/wasc-wafec_lists.webappsec.org





More information about the wasc-wafec mailing list