Ryan,

On Thu, Jun 7, 2012 at 11:18 PM, Ryan Barnett rcbarnett@gmail.com wrote:

As far as I am aware (i.e. I might be incorrect) Mike Boberski (former
OWASP Project Leader) based on the ASVS "Levels" on
http://www.commoncriteriaportal.org/ based on my reading of
http://www.linkedin.com/in/boberski

I can assist with an introduction to
http://www.dsd.gov.au/infosec/aisep/providers.htm but due to the
timezone difference with Australia it might be worth liaising with
those more locally in North America.

--
Regards,
Christian Heinrich

http://cmlh.id.au/contact

Thank you all for the great input. I am going to a week's vacation today and
will summarize all said, define draft goal and action plan when I am back.

Thanks!
~ Ofer

-----Original Message-----
From: Christian Heinrich [mailto:christian.heinrich@cmlh.id.au]
Sent: Friday, June 08, 2012 3:08 AM
To: Ryan Barnett
Cc: Ofer Shezaf; wasc-wafec@lists.webappsec.org
Subject: Re: [WASC-WAFEC] What should we change in WAFEC 2.0?

Ryan,

On Thu, Jun 7, 2012 at 11:18 PM, Ryan Barnett rcbarnett@gmail.com wrote:

As far as I am aware (i.e. I might be incorrect) Mike Boberski (former OWASP
Project Leader) based on the ASVS "Levels" on
http://www.commoncriteriaportal.org/ based on my reading of
http://www.linkedin.com/in/boberski

I can assist with an introduction to
http://www.dsd.gov.au/infosec/aisep/providers.htm but due to the timezone
difference with Australia it might be worth liaising with those more locally
in North America.

--
Regards,
Christian Heinrich

http://cmlh.id.au/contact

Ofer,

On Wed, Jun 6, 2012 at 9:39 PM, Ofer Shezaf ofer@shezaf.com wrote:

I am also willing to review and confirm that any perceived conflict of
interest was removed from this section with consideration to
http://blog.modsecurity.org/2010/10/modsecurity-user-survey-results-released.html

--
Regards,
Christian Heinrich

http://cmlh.id.au/contact

Ofer,

On Wed, Jun 6, 2012 at 9:39 PM, Ofer Shezaf ofer@shezaf.com wrote:

To follow on from
http://lists.webappsec.org/pipermail/wasc-wafec_lists.webappsec.org/2012-June/000084.html,
we should also add http://www.commoncriteriaportal.org/labs/ to 6.

--
Regards,
Christian Heinrich

http://cmlh.id.au/contact

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@lists.webappsec.org [mailto:wasc-wafec-bounces@lists.webappsec.org] Im Auftrag von Kenneth Salchow
Gesendet: Donnerstag, 7. Juni 2012 18:16
An: Kit Wetzler; wasc-wafec@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.comhttp://www.f5.com/

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

From: wasc-wafec-bounces@lists.webappsec.orgmailto:wasc-wafec-bounces@lists.webappsec.org [mailto:wasc-wafec-bounces@lists.webappsec.org]mailto:[mailto:wasc-wafec-bounces@lists.webappsec.org] On Behalf Of Kit Wetzler
Sent: Wednesday, June 06, 2012 4:10 PM
To: wasc-wafec@lists.webappsec.orgmailto:wasc-wafec@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@citrix.commailto:kit.wetzler@citrix.com

From: wasc-wafec-bounces@lists.webappsec.orgmailto:wasc-wafec-bounces@lists.webappsec.org [mailto:wasc-wafec-bounces@lists.webappsec.org]mailto:[mailto:wasc-wafec-bounces@lists.webappsec.org] On Behalf Of Mark Kraynak
Sent: Wednesday, June 06, 2012 1:54 PM
To: Ofer Shezaf; wasc-wafec@lists.webappsec.orgmailto:wasc-wafec@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@lists.webappsec.orgmailto:wasc-wafec-bounces@lists.webappsec.org [mailto:wasc-wafec-bounces@lists.webappsec.org]mailto:[mailto:wasc-wafec-bounces@lists.webappsec.org] On Behalf Of Ofer Shezaf
Sent: Wednesday, June 06, 2012 4:39 AM
To: wasc-wafec@lists.webappsec.orgmailto:wasc-wafec@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@shezaf.com]
Sent: Thursday, May 31, 2012 1:45 PM
To: wasc-wafec@lists.webappsec.orgmailto:wasc-wafec@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.
   

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@shezaf.commailto:ofer@shezaf.com, www.shezaf.comhttp://www.shezaf.com]

One subject that I wonder whether we can touch in a better way, is the rate of FP.

I think it would be great if we can find a structured method to measure the rate of FP of a WAF and combine that with the tools the WAF support in order to deal with the FP. It sum up to the time a customer need to invest to make the WAF usable in a given environment.

Doron.

From: wasc-wafec-bounces@lists.webappsec.org [mailto:wasc-wafec-bounces@lists.webappsec.org] On Behalf Of Wujek, Thorsten [STEIN-IT GmbH]
Sent: Wednesday, June 13, 2012 7:34 PM
To: wasc-wafec@lists.webappsec.org
Subject: Re: [WASC-WAFEC] What should we change in WAFEC 2.0?

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@lists.webappsec.orgmailto:wasc-wafec-bounces@lists.webappsec.org [mailto:wasc-wafec-bounces@lists.webappsec.org]mailto:[mailto:wasc-wafec-bounces@lists.webappsec.org] Im Auftrag von Kenneth Salchow
Gesendet: Donnerstag, 7. Juni 2012 18:16
An: Kit Wetzler; wasc-wafec@lists.webappsec.orgmailto:wasc-wafec@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.comhttp://www.f5.com/

[cid:image001.png@01CD4A2D.BCE461C0]

From: wasc-wafec-bounces@lists.webappsec.orgmailto:wasc-wafec-bounces@lists.webappsec.org [mailto:wasc-wafec-bounces@lists.webappsec.org]mailto:[mailto:wasc-wafec-bounces@lists.webappsec.org] On Behalf Of Kit Wetzler
Sent: Wednesday, June 06, 2012 4:10 PM
To: wasc-wafec@lists.webappsec.orgmailto:wasc-wafec@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@citrix.commailto:kit.wetzler@citrix.com

From: wasc-wafec-bounces@lists.webappsec.orgmailto:wasc-wafec-bounces@lists.webappsec.org [mailto:wasc-wafec-bounces@lists.webappsec.org]mailto:[mailto:wasc-wafec-bounces@lists.webappsec.org] On Behalf Of Mark Kraynak
Sent: Wednesday, June 06, 2012 1:54 PM
To: Ofer Shezaf; wasc-wafec@lists.webappsec.orgmailto:wasc-wafec@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@lists.webappsec.orgmailto:wasc-wafec-bounces@lists.webappsec.org [mailto:wasc-wafec-bounces@lists.webappsec.org]mailto:[mailto:wasc-wafec-bounces@lists.webappsec.org] On Behalf Of Ofer Shezaf
Sent: Wednesday, June 06, 2012 4:39 AM
To: wasc-wafec@lists.webappsec.orgmailto:wasc-wafec@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@shezaf.com]
Sent: Thursday, May 31, 2012 1:45 PM
To: wasc-wafec@lists.webappsec.orgmailto:wasc-wafec@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.
   

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@shezaf.commailto:ofer@shezaf.com, www.shezaf.comhttp://www.shezaf.com]

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

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:

--
Alexander Meisel (VP Sec Products) - alexander.meisel@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

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@lists.webappsec.org
[mailto:wasc-wafec-bounces@lists.webappsec.org] On Behalf Of Alexander
Meisel
Sent: Monday, June 18, 2012 2:12 PM
To: wasc-wafec@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:

classification.

as a section.

read…).

--
Alexander Meisel (VP Sec Products) - alexander.meisel@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@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/wasc-wafec_lists.webappsec.org

Alex,

On Mon, Jun 18, 2012 at 9:11 PM, Alexander Meisel
alexander.meisel@artofdefence.com wrote:

I would be willing to support this if Ken could provide a number of
supporting references from F5 customers (I am not expecting Ken to
have to post these to a public mailing list) based on his "As a
customer" quote below (I know Ken isn't a customer BTW) i.e.

The resulting draft section could be then voted on for
inclusion/exclusion in the upcoming release of WAFEC?

--
Regards,
Christian Heinrich

http://cmlh.id.au/contact

I'm not sure what you are asking for Christian ... are you looking for customer references that state that customers have other solutions (SSO, SSL-VPN, UTM, Firewall, etc) that they will be deploying alongside WAF?  I kind of thought that we could all agree that customers weren't installing WAF devices all by themselves; that would be kind of simplistic if you ask me.

Further, yes, I do think we should mention all the regional certifications related to power consumption or other implementation issues.  As a customer (and while I'm not one now ... I was one once) those are ALL important things to me.  Why would I bother to investigate a solution that I would not be able to actually deploy because it doesn't meet the requirements of my environment?

However, if everyone thinks it is of no value to customers to know this kind of information ... then that's fine by me.  I just personally think you are doing a disservice to the end customer to simply dismiss these items.  Today's networks are far too complex to simply ignore how devices interact with each other.

From: Christian Heinrich [christian.heinrich@cmlh.id.au]
Sent: Tuesday, June 19, 2012 2:08 AM
To: Alexander Meisel
Cc: wasc-wafec@lists.webappsec.org; Kenneth Salchow
Subject: Re: [WASC-WAFEC] What should we change in WAFEC 2.0?

Alex,

On Mon, Jun 18, 2012 at 9:11 PM, Alexander Meisel
alexander.meisel@artofdefence.com wrote:

I would be willing to support this if Ken could provide a number of
supporting references from F5 customers (I am not expecting Ken to
have to post these to a public mailing list) based on his "As a
customer" quote below (I know Ken isn't a customer BTW) i.e.

The resulting draft section could be then voted on for
inclusion/exclusion in the upcoming release of WAFEC?

--
Regards,
Christian Heinrich

http://cmlh.id.au/contact