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

Wujek, Thorsten [STEIN-IT GmbH] Thorsten.Wujek at stein-edv.de
Wed Jun 13 12:33:44 EDT 2012


Hi,

sorry for the delayed response, but I was on holiday. So I hope I am "just in time" :)

Here are my 5 cent about what Ofer has put together:

At first I would like to inspire to think about 2 versions of WAFEC. One covering an abstract perspective (normally the customers view) to answer question like 'is the WAF "safe" ' or is it 'fault tolerant' and a more technical view for consultants. I am using WAFEC 1.0 often, but only as template. It is not presentable to a customer without customization. These 2 views can be integrated in one document or be separated. Maybe these could lead to another discussion.


1.)    WAFEC should be rely on the WAF part of solutions, but for a customer or consultant it is necessary to validate and mostly weight integrative possibilities.
Therefore WAFEC should  include a reference to what could be or is integrated in the considered WAFs.

2.)    From a maintenance perspective this section will be a nightmare if you try to keep it up to date in an acceptable timeframe. Here I think we should discuss what are the base or minimum threats and attack vectors  which should be covered by a WAF if you use WAFEC 2.0 (maybe we can weight those functionalities on a green, yellow, red base) and we should add a reference to actual threats or attack vectors. This list can be cultivated by WAFEC or other orgs. This will keep the maintenance frequency low which is necessary for an open project.

3.)     Use cases are necessary if you take into account the different infrastructure solutions. Factors are: size of customer, placement (on-premise, off-premise, hosted and maybe cloud) to name a few. My brother and I have worked on that, maybe it is of interest.

4.)    At this point an abstract view would be helpful. The question is, what are the customers or consultants main questions and factors. It is important to know this otherwise we will develop something apart off requirements. If we are able to evaluate this we can discuss how granular we would like to go in WAFEC which has a direct effect on maintenance.

5.)    This is an "integrative" aspect, so from my point of view refers to 1.

6.)    I agree to what people stated before.

I am looking forward to further discussions.

Regards

Thorsten


Mit freundlichen Grüßen
STEIN-IT GmbH
Thorsten Wujek
technischer Geschäftsführer
technical CEO

MCT,MCA,MASE,CITA-P














Von: wasc-wafec-bounces at lists.webappsec.org [mailto:wasc-wafec-bounces at lists.webappsec.org] Im Auftrag von Kenneth Salchow
Gesendet: Donnerstag, 7. Juni 2012 18:16
An: Kit Wetzler; wasc-wafec at lists.webappsec.org
Betreff: Re: [WASC-WAFEC] What should we change in WAFEC 2.0?

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/>

[cid:image001.png at 01CD498E.71B196E0]




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 Kit Wetzler
Sent: Wednesday, June 06, 2012 4:10 PM
To: 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?


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 :)

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/20120613/6ba31df4/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 14036 bytes
Desc: image001.png
URL: <http://lists.webappsec.org/pipermail/wasc-wafec_lists.webappsec.org/attachments/20120613/6ba31df4/attachment.png>


More information about the wasc-wafec mailing list