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

Ido Breger I.Breger at F5.com
Wed Jun 6 10:27:01 EDT 2012


Hi Ofer,
I tend to agree with all but the first one. I think that the WAFEC should help customers to choose the right WAF for their environment. If we neglect options like integration with other network devices/ security solutions or capabilities that effect the performance of a WAF or the application behind a WAF then we will damage the original goal.

Over the recent years, WAFs pretty much stopped being another point solution in the network and most toady offer additional services and features that contribute to their adoption.

Let me give you an example that we see all the time: Security team asks for a WAF, business owners and the network team say that a WAF will hurt the customer experience as it will add latency, at that point, if the security team claims that the WAF has a built in fast cache that actually offloads work from the web server and contributes to the user experience then they may be able to persuade the network team and business owners and get a WAF installed.

By hiding these "non-WAF" related features from WAFEC we make WAFEC less attractive as it will require much more additional research to find the right solution to a specific environment/ problem.

Cheers,
Ido

From: wasc-wafec-bounces at lists.webappsec.org [mailto:wasc-wafec-bounces at lists.webappsec.org] On Behalf Of Ofer Shezaf
Sent: Wednesday, June 06, 2012 2:39 PM
To: 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]<mailto:[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/f4a8302d/attachment-0003.html>


More information about the wasc-wafec mailing list