WASC Web Application Firewall Evaluation Criteria Project Mailing List
View all threadsFolks,
I apologize for this late email but I'm on holiday in Japan and trying
to catch up with email as rarely as possible. Also, I'd like to further
apologize for entering this discussion while being mostly a silent
lurker here.
My impression is that there is no consensus in this community to join
another project such as OWASP, which entails a huge change we cannot
probably completely understand.
Also, my understanding is that OWASP at the moment has its own internal
issues which I already see reverberating here negatively.
My impression is that WASC and WAFEC have little, if anything to gain
from such a move, and much to lose.
My 2c.
--
Cordiali saluti,
Stefano Zanero
Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. +39 02 2399-4017
Fax. +39 02 2399-3411
E-mail: zanero@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
Hi Stefano,
I don't understand your remark:
"Also, my understanding is that OWASP at the moment has its own internal
issues which I already see reverberating here negatively."
OWASP currently hosts 150+ projects with lot's of them making a serious
impact on the state of web application security.
don't let the voice (albeit loud) of one mailing list member negatively
impact the success of WAFEC.
--seba
On Sat, Nov 17, 2012 at 1:06 PM, Stefano Zanero zanero@elet.polimi.itwrote:
Folks,
I apologize for this late email but I'm on holiday in Japan and trying
to catch up with email as rarely as possible. Also, I'd like to further
apologize for entering this discussion while being mostly a silent
lurker here.
My impression is that there is no consensus in this community to join
another project such as OWASP, which entails a huge change we cannot
probably completely understand.
Also, my understanding is that OWASP at the moment has its own internal
issues which I already see reverberating here negatively.
My impression is that WASC and WAFEC have little, if anything to gain
from such a move, and much to lose.
My 2c.
--
Cordiali saluti,
Stefano Zanero
Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. +39 02 2399-4017
Fax. +39 02 2399-3411
E-mail: zanero@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
wasc-wafec mailing list
wasc-wafec@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/wasc-wafec_lists.webappsec.org
Hi all,
Sorry for my late answer.
WASC is doing WAFEC and OWASP is also doing good job on WAF subject too. But
merging project is imho not a good idea because its not driven the same
way, WASC and OWASP are totally different organizations.
WASC is providing documents about web application security and stay vendors
neutral. OWASP get vendors sponsorship and is also providing tools like
vendors
Im involved in WASC but I was also in OWASP French chapter, not for the
same goal and the same actions.
Then, to see so much discussion on this topic during the latest 2 weeks and
only 3 emails on the WAFEC 2 content, I would like to end this OWASP/WASC
topic and work on the real subject as soon as possible J
WAFEC 1 is well known not because of vendors inside, but because of the
content and how its used by people evaluating WAF.
Speaking as a vendor, more than 50% of people evaluating our product are
using WAFEC based document. They need something updated.
Speaking as an Opensource guy, my only goal Is make WAFEC 2 up to date with
new security criteria we are now dealing with to make people doing the
GOOD choice on what they need.
If others project want to use it as a referral, thats a good thing. We will
also be able to point on others projects in WAFEC.
But a common project is imho not a good idea, the final cut must stay to the
WAFEC project leader. We dont have enough community rules to drive it with
votes. Too complex, endless
Just look at this endless discussion on only one topic, what will happen on
each technical point ? We will release WAFEC 2 in 2016
I would prefer to start serious discussion with OWASP to see how we could
promote together our work.
So I vote to NO.
Matthieu
De : wasc-wafec [mailto:wasc-wafec-bounces@lists.webappsec.org] De la part
de Ofer Shezaf
Envoyé : lundi 12 novembre 2012 11:18
À : wasc-wafec@lists.webappsec.org
Objet : [WASC-WAFEC] Vote on making WAFEC a WASC/OWASP project
Hi All,
As promised I am opening the vote for making WAFEC a joined WASC and OWASP
project.
The proposed guidelines for this more are (updated based on comments from
the group and WASC officers):
· The name, when affiliation is used, would be "The WASC/OWASP Web
Application Firewall Evaluation Criteria".
· Governance would be mutual, i.e. any decision about the project
which is not within the project team itself has to be agreed upon by the
OWASP GPC (i.e. Project Committee) and by the WASC officers. The project
leader is the arbitrator in case of a conflict (this change is based on a
request by Jeremiah Grossman, WASC founder).
· Participation is open for all and does not require being an OWASP
or a WASC member.
Vote Yes/No. Voting is open until Nov 19th EOD (American Samoa, that is
UTC-11, time zone)
Now for my voting pitch:
I think the change is important and would benefit WAFEC tremendously. I
would go a step further it is needed to ensure we actually succeed:
Why?
· Making it happen we need more people. I now have two chapter
assigned and many are still waiting. Joining hands with OWASP will make
joining the project appealing to many more people.
· Outreach people in the application security community have heard
about OWASP, and joining hands with OWASP would enable leveraging this to
reach more people. This includes chapters outreach (from Khartoum, The Sudan
to Omaha, Nebraska) as well as an official room in local and global
conferences.
· Vendor image - WASC is perceived as a "vendors' organization" and
the list of participants in WAFEC certainly proves that. Affiliation with
OWASP will
help popularize WAFEC also with customers, which I think is very good for
the project.
I must say I think it would be hard for me to complete the project
successfully otherwise.
~ Ofer
Ofer Shezaf
[+972-54-4431119; ofer@shezaf.com, www.shezaf.com]
Interesting thread; can you help me understand with clarification on two of your statements;
1 - "But merging project is imho not a good idea because it’s not driven the same way, WASC and OWASP are totally different organizations."
Explain this; both are non-profits (OWASP had the same question that is happening here and this was approved on our side) what is different about the focus with the builder, breaker and defender buckets at OWASP it has a little something for everyone these days focused on software security in all forms.
2 - "OWASP get vendors sponsorship and is also providing tools like vendors…"
You mean supporters that include Boeing, UPS, FedEx, Best Buy, Mozilla, US DHS, and 40+ Universities and industry providers is bad for the platform? Or are you referring to OWASP investing in its core projects on behalf of our mission https://www.owasp.org/index.php/Projects_Reboot_2012
Perception is reality so if we (OWASP Hat) are not doing a good job on the public image I'm all ears/eyes I'll bring it to our board meetings were OPEN
https://www.owasp.org/index.php/OWASP_Board_Meetings
The core community is so small working together as a professionals is important to awareness regardless of the association flag and occasional troll to the independant missions.
Obviously as a long time list(s) member I support this regardless of who I work for (Disclaimer; Trustwave SpiderLabs the caretaker of the Apache licensed Mod_Security and elected by membership OWASP volunteer)
Feel free to take this off-list if you want but others may also be interested.
Enjoy the weekend.
Tom Brennan
973-202-0122
On Nov 17, 2012, at 9:14 AM, "Matthieu Estrade" <mestrade@apache.orgmailto:mestrade@apache.org> wrote:
Hi all,
Sorry for my late answer.
WASC is doing WAFEC and OWASP is also doing good job on WAF subject too. But merging project is imho not a good idea because it’s not driven the same way, WASC and OWASP are totally different organizations.
WASC is providing documents about web application security and stay vendors neutral. OWASP get vendors sponsorship and is also providing tools like vendors…
I’m involved in WASC but I was also in OWASP French chapter, not for the same goal and the same actions.
Then, to see so much discussion on this topic during the latest 2 weeks and only 3 emails on the WAFEC 2 content, I would like to end this OWASP/WASC topic and work on the real subject as soon as possible :)
WAFEC 1 is well known not because of vendors inside, but because of the content and how it’s used by people evaluating WAF.
Speaking as a vendor, more than 50% of people evaluating our product are using WAFEC based document. They need something updated.
Speaking as an Opensource guy, my only goal Is make WAFEC 2 up to date with new security criteria we are now dealing with to make people doing the GOOD choice on what they need.
If others project want to use it as a referral, that’s a good thing. We will also be able to point on others projects in WAFEC.
But a common project is imho not a good idea, the final cut must stay to the WAFEC project leader. We don’t have enough community rules to drive it with votes. Too complex, endless…
Just look at this endless discussion on only one topic, what will happen on each technical point ? We will release WAFEC 2 in 2016…
I would prefer to start serious discussion with OWASP to see how we could promote together our work.
So I vote to NO.
Matthieu
De : wasc-wafec [mailto:wasc-wafec-bounces@lists.webappsec.org] De la part de Ofer Shezaf
Envoyé : lundi 12 novembre 2012 11:18
À : wasc-wafec@lists.webappsec.orgmailto:wasc-wafec@lists.webappsec.org
Objet : [WASC-WAFEC] Vote on making WAFEC a WASC/OWASP project
Hi All,
As promised I am opening the vote for making WAFEC a joined WASC and OWASP project.
The proposed guidelines for this more are (updated based on comments from the group and WASC officers):
• The name, when affiliation is used, would be "The WASC/OWASP Web Application Firewall Evaluation Criteria".
• Governance would be mutual, i.e. any decision about the project which is not within the project team itself has to be agreed upon by the OWASP GPC (i.e. Project Committee) and by the WASC officers. The project leader is the arbitrator in case of a conflict (this change is based on a request by Jeremiah Grossman, WASC founder).
• Participation is open for all and does not require being an OWASP or a WASC member.
Vote Yes/No. Voting is open until Nov 19th EOD (American Samoa, that is UTC-11, time zone)
Now for my voting pitch:
I think the change is important and would benefit WAFEC tremendously. I would go a step further it is needed to ensure we actually succeed:
Why?
• Making it happen – we need more people. I now have two chapter assigned and many are still waiting. Joining hands with OWASP will make joining the project appealing to many more people.
• Outreach – people in the application security community have heard about OWASP, and joining hands with OWASP would enable leveraging this to reach more people. This includes chapters outreach (from Khartoum, The Sudan to Omaha, Nebraska) as well as an official room in local and global conferences.
• Vendor image - WASC is perceived as a "vendors' organization" and the list of participants in WAFEC certainly proves that. Affiliation with OWASP will
help popularize WAFEC also with customers, which I think is very good for the project.
I must say I think it would be hard for me to complete the project successfully otherwise.
~ Ofer
Ofer Shezaf
[+972-54-4431119; ofer@shezaf.commailto:ofer@shezaf.com, www.shezaf.comhttp://www.shezaf.com]
wasc-wafec mailing list
wasc-wafec@lists.webappsec.orgmailto:wasc-wafec@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/wasc-wafec_lists.webappsec.org
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.
Thanks Tom, I personally agree with you and does not fully understand
Matthieu and Stefano remarks. One statement Stefano made that does require
addressing is about lack of Consensus: it is a vote and I did not seek
consensus. That said, up to now I listed 14 Yes voters, and until today
nobody apart from Christian opposed (and even he never said no, though one
may surmise that at this point).
One area I do agree with Matthieu on is that I want to move to actual work.
To that end: please try to limit your participation in this discussion to
voting (Yes or No). Note that I did not interpret opinions as votes, so if
you did not explicitly vote I did not list you here:
http://projects.webappsec.org/w/page/60986202/WAFEC%20WASC-OWASP%20vote.
~ Ofer
From: Thomas Brennan [mailto:TBrennan@trustwave.com]
Sent: Saturday, November 17, 2012 6:02 PM
To: Matthieu Estrade
Cc: Ofer Shezaf; wasc-wafec@lists.webappsec.org
Subject: Re: [WASC-WAFEC] Vote on making WAFEC a WASC/OWASP project
Interesting thread; can you help me understand with clarification on two of
your statements;
1 - "But merging project is imho not a good idea because its not driven the
same way, WASC and OWASP are totally different organizations."
Explain this; both are non-profits (OWASP had the same question that is
happening here and this was approved on our side) what is different about
the focus with the builder, breaker and defender buckets at OWASP it has a
little something for everyone these days focused on software security in all
forms.
2 - "OWASP get vendors sponsorship and is also providing tools like
vendors
"
You mean supporters that include Boeing, UPS, FedEx, Best Buy, Mozilla, US
DHS, and 40+ Universities and industry providers is bad for the platform? Or
are you referring to OWASP investing in its core projects on behalf of our
mission https://www.owasp.org/index.php/Projects_Reboot_2012
Perception is reality so if we (OWASP Hat) are not doing a good job on the
public image I'm all ears/eyes I'll bring it to our board meetings were OPEN
https://www.owasp.org/index.php/OWASP_Board_Meetings
The core community is so small working together as a professionals is
important to awareness regardless of the association flag and occasional
troll to the independant missions.
Obviously as a long time list(s) member I support this regardless of who I
work for (Disclaimer; Trustwave SpiderLabs the caretaker of the Apache
licensed Mod_Security and elected by membership OWASP volunteer)
Feel free to take this off-list if you want but others may also be
interested.
Enjoy the weekend.
Tom Brennan
973-202-0122
On Nov 17, 2012, at 9:14 AM, "Matthieu Estrade" <mestrade@apache.org
mailto:mestrade@apache.org > wrote:
Hi all,
Sorry for my late answer.
WASC is doing WAFEC and OWASP is also doing good job on WAF subject too. But
merging project is imho not a good idea because its not driven the same
way, WASC and OWASP are totally different organizations.
WASC is providing documents about web application security and stay vendors
neutral. OWASP get vendors sponsorship and is also providing tools like
vendors
Im involved in WASC but I was also in OWASP French chapter, not for the
same goal and the same actions.
Then, to see so much discussion on this topic during the latest 2 weeks and
only 3 emails on the WAFEC 2 content, I would like to end this OWASP/WASC
topic and work on the real subject as soon as possible :)
WAFEC 1 is well known not because of vendors inside, but because of the
content and how its used by people evaluating WAF.
Speaking as a vendor, more than 50% of people evaluating our product are
using WAFEC based document. They need something updated.
Speaking as an Opensource guy, my only goal Is make WAFEC 2 up to date with
new security criteria we are now dealing with to make people doing the
GOOD choice on what they need.
If others project want to use it as a referral, thats a good thing. We will
also be able to point on others projects in WAFEC.
But a common project is imho not a good idea, the final cut must stay to the
WAFEC project leader. We dont have enough community rules to drive it with
votes. Too complex, endless
Just look at this endless discussion on only one topic, what will happen on
each technical point ? We will release WAFEC 2 in 2016
I would prefer to start serious discussion with OWASP to see how we could
promote together our work.
So I vote to NO.
Matthieu
De : wasc-wafec [mailto:wasc-wafec-bounces@lists.webappsec.org] De la part
de Ofer Shezaf
Envoyé : lundi 12 novembre 2012 11:18
À : wasc-wafec@lists.webappsec.org mailto:wasc-wafec@lists.webappsec.org
Objet : [WASC-WAFEC] Vote on making WAFEC a WASC/OWASP project
Hi All,
As promised I am opening the vote for making WAFEC a joined WASC and OWASP
project.
The proposed guidelines for this more are (updated based on comments from
the group and WASC officers):
The name, when affiliation is used, would be "The WASC/OWASP Web
Application Firewall Evaluation Criteria".
Governance would be mutual, i.e. any decision about the project
which is not within the project team itself has to be agreed upon by the
OWASP GPC (i.e. Project Committee) and by the WASC officers. The project
leader is the arbitrator in case of a conflict (this change is based on a
request by Jeremiah Grossman, WASC founder).
Participation is open for all and does not require being an OWASP
or a WASC member.
Vote Yes/No. Voting is open until Nov 19th EOD (American Samoa, that is
UTC-11, time zone)
Now for my voting pitch:
I think the change is important and would benefit WAFEC tremendously. I
would go a step further it is needed to ensure we actually succeed:
Why?
Making it happen we need more people. I now have two chapter
assigned and many are still waiting. Joining hands with OWASP will make
joining the project appealing to many more people.
Outreach people in the application security community have heard
about OWASP, and joining hands with OWASP would enable leveraging this to
reach more people. This includes chapters outreach (from Khartoum, The Sudan
to Omaha, Nebraska) as well as an official room in local and global
conferences.
Vendor image - WASC is perceived as a "vendors' organization" and
the list of participants in WAFEC certainly proves that. Affiliation with
OWASP will
help popularize WAFEC also with customers, which I think is very good for
the project.
I must say I think it would be hard for me to complete the project
successfully otherwise.
~ Ofer
Ofer Shezaf
[+972-54-4431119; ofer@shezaf.com mailto:ofer@shezaf.com , www.shezaf.com
http://www.shezaf.com ]
wasc-wafec mailing list
wasc-wafec@lists.webappsec.org mailto:wasc-wafec@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/wasc-wafec_lists.webappsec.org
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 Thom, list J
Im not sure (my English is bad) but I never said, or I wouldnt like to
said that OWASP was doing bad job in my previous email.
About OWASP/WASC, my first point was you cant compare an organization like
WASC, focused on providing documents about web app security products, with a
big organization like OWASP with board elections, internal process,
sponsorship program, chapters all over the world doing events, providing
documents, tools etc. And for me, two differents organizations driving a
common project can introduce some leading problem.
What is important for me is to keep WAFEC simple, as the v1 was, and not
transform it in a bigger and more complex document.
So a team working on improving content, using the mailing list, driven by
Ofer is for me a good deal.
Keeping it in WASC only is for me the way to keep the WASC spirit on WAFEC.
Here again, not because OWASP is doing bad job, just to limit side-effect of
two organizations driving a project.
Hope I was more clear J if not, feel free to answer.
Matthieu
De : Thomas Brennan [mailto:TBrennan@trustwave.com]
Envoyé : samedi 17 novembre 2012 17:02
À : Matthieu Estrade
Cc : Ofer Shezaf; wasc-wafec@lists.webappsec.org
Objet : Re: [WASC-WAFEC] Vote on making WAFEC a WASC/OWASP project
Interesting thread; can you help me understand with clarification on two of
your statements;
1 - "But merging project is imho not a good idea because its not driven the
same way, WASC and OWASP are totally different organizations."
Explain this; both are non-profits (OWASP had the same question that is
happening here and this was approved on our side) what is different about
the focus with the builder, breaker and defender buckets at OWASP it has a
little something for everyone these days focused on software security in all
forms.
Size is totally different, internal process, decisions, elections etc.
2 - "OWASP get vendors sponsorship and is also providing tools like
vendors
"
You mean supporters that include Boeing, UPS, FedEx, Best Buy, Mozilla, US
DHS, and 40+ Universities and industry providers is bad for the platform? Or
are you referring to OWASP investing in its core projects on behalf of our
mission https://www.owasp.org/index.php/Projects_Reboot_2012
Perception is reality so if we (OWASP Hat) are not doing a good job on the
public image I'm all ears/eyes I'll bring it to our board meetings were OPEN
https://www.owasp.org/index.php/OWASP_Board_Meetings
The core community is so small working together as a professionals is
important to awareness regardless of the association flag and occasional
troll to the independant missions.
Obviously as a long time list(s) member I support this regardless of who I
work for (Disclaimer; Trustwave SpiderLabs the caretaker of the Apache
licensed Mod_Security and elected by membership OWASP volunteer)
Feel free to take this off-list if you want but others may also be
interested.
Enjoy the weekend.
Tom Brennan
973-202-0122
On Nov 17, 2012, at 9:14 AM, "Matthieu Estrade" mestrade@apache.org wrote:
Hi all,
Sorry for my late answer.
WASC is doing WAFEC and OWASP is also doing good job on WAF subject too. But
merging project is imho not a good idea because its not driven the same
way, WASC and OWASP are totally different organizations.
WASC is providing documents about web application security and stay vendors
neutral. OWASP get vendors sponsorship and is also providing tools like
vendors
Im involved in WASC but I was also in OWASP French chapter, not for the
same goal and the same actions.
Then, to see so much discussion on this topic during the latest 2 weeks and
only 3 emails on the WAFEC 2 content, I would like to end this OWASP/WASC
topic and work on the real subject as soon as possible J
WAFEC 1 is well known not because of vendors inside, but because of the
content and how its used by people evaluating WAF.
Speaking as a vendor, more than 50% of people evaluating our product are
using WAFEC based document. They need something updated.
Speaking as an Opensource guy, my only goal Is make WAFEC 2 up to date with
new security criteria we are now dealing with to make people doing the
GOOD choice on what they need.
If others project want to use it as a referral, thats a good thing. We will
also be able to point on others projects in WAFEC.
But a common project is imho not a good idea, the final cut must stay to the
WAFEC project leader. We dont have enough community rules to drive it with
votes. Too complex, endless
Just look at this endless discussion on only one topic, what will happen on
each technical point ? We will release WAFEC 2 in 2016
I would prefer to start serious discussion with OWASP to see how we could
promote together our work.
So I vote to NO.
Matthieu
De : wasc-wafec [mailto:wasc-wafec-bounces@lists.webappsec.org] De la part
de Ofer Shezaf
Envoyé : lundi 12 novembre 2012 11:18
À : wasc-wafec@lists.webappsec.org
Objet : [WASC-WAFEC] Vote on making WAFEC a WASC/OWASP project
Hi All,
As promised I am opening the vote for making WAFEC a joined WASC and OWASP
project.
The proposed guidelines for this more are (updated based on comments from
the group and WASC officers):
· The name, when affiliation is used, would be "The WASC/OWASP Web
Application Firewall Evaluation Criteria".
· Governance would be mutual, i.e. any decision about the project
which is not within the project team itself has to be agreed upon by the
OWASP GPC (i.e. Project Committee) and by the WASC officers. The project
leader is the arbitrator in case of a conflict (this change is based on a
request by Jeremiah Grossman, WASC founder).
· Participation is open for all and does not require being an OWASP
or a WASC member.
Vote Yes/No. Voting is open until Nov 19th EOD (American Samoa, that is
UTC-11, time zone)
Now for my voting pitch:
I think the change is important and would benefit WAFEC tremendously. I
would go a step further it is needed to ensure we actually succeed:
Why?
· Making it happen we need more people. I now have two chapter
assigned and many are still waiting. Joining hands with OWASP will make
joining the project appealing to many more people.
· Outreach people in the application security community have heard
about OWASP, and joining hands with OWASP would enable leveraging this to
reach more people. This includes chapters outreach (from Khartoum, The Sudan
to Omaha, Nebraska) as well as an official room in local and global
conferences.
· Vendor image - WASC is perceived as a "vendors' organization" and
the list of participants in WAFEC certainly proves that. Affiliation with
OWASP will
help popularize WAFEC also with customers, which I think is very good for
the project.
I must say I think it would be hard for me to complete the project
successfully otherwise.
~ Ofer
Ofer Shezaf
[+972-54-4431119; ofer@shezaf.com, www.shezaf.com]
wasc-wafec mailing list
wasc-wafec@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/wasc-wafec_lists.webappsec.org
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.
I agree with you comment on section 6.1 - it tries to get too much into one box - and split it to two, calling the new section "Integrated Related Features". Updated outline uploaded (with revision marks in the Word version).
Not fair to pick my espresso machine example :-). IPSs were more on my mind. My experience is that definitions tend to be fuzzy and open to interpretation. Identifying the criteria from WAFEC that if missing would disqualify a product from being a WAF would clear such ambiguity. That said, let's see how the definition section evolves. The minimum list is just picking up criteria so it is easy to create (though open to a lot of discussion).
As to use cases: my list is an opening salvo, I did not right the section. I agree that in light of our selection of threats and techniques in section 3, we may need to amend the use case chapter.
Lastly, I have listed you to "Integrated Related Features" and "non-technical criteria". Thanks!!! Before diving into your e-mail I volunteered for "Alternative solutions" if this is OK with you. Let me tackle the other two sections you asked about in a different e-mail (I need more time...).
~ Ofer
-----Original Message-----
From: Erwin Huber [mailto:erwin.huber@ergon.ch]
Sent: Friday, November 16, 2012 2:44 PM
To: Ofer Shezaf
Cc: wasc-wafec@lists.webappsec.org
Subject: Re: WAFEC 2 outline
Hi Ofer
Thank you for your explanations.
I understand the neutrality vs. vendor conflict - I think there is no "real" objective view. Anyone has its own use cases and own solutions in mind - whether he is a vendor, a user of some concrete implementations or a consultant which likes some concepts and dislikes others.
When I have a look at the use cases ("Logging and Troubleshooting", "Attack Detection", "Attack Mitigation" and "Virtual Patching") then I think: why is "Virtual Patching" a use case for its own? Isn't it a specialized attack mitigation? The difference in virtual patching is, that you know exactly what vulnerability the application has. In general mitigation you don't have to know that. In my eyes Authentication is a real "other" security use case not just a specialized use case. I won't insist on that - just my thoughts.
I see the argumentation of "minimum requirements" - yes an Espresso Machine must not be mistaken as a WAF ;-) Good argumentation. I think the differenciation should go into the "2.1 Definition". I understand a "definition" as more specific than minimal requirements. What would be written in one paragraph what doesn't fit in the other? There is a risk of writing twice the same in different words.
OK, security features are placed i n3.3 - other features in 6.1. The outline draft mentions "6.1 Non-Technical Criteria". The non-technical criteria are important - I would not skip that. So there is another 6.1 chapter? Since features are a technical criteria.
I volunteer to write the appendix "Additional Features", "Alternative and Complementary Solutions", "Non-technical criteria". In the moment I can't estimate "Testing Framework" and "Suggested Weighting Schemes". Maybe it's also possible for me to do - can you explain the ideas?
erwin
----- Original Message -----
From: "Ofer Shezaf" ofer@shezaf.com
To: "Erwin Huber" erwin.huber@ergon.ch
Cc: wasc-wafec@lists.webappsec.org
Sent: Thursday, November 15, 2012 9:21:38 PM
Subject: RE: WAFEC 2 outline
Hi Erwin,
The document I shared is only an outline. I included some text to make the sections intention more clear but there are in no way comprehensive. The people volunteering to write the different sections will fill them in and I am sure would take into consideration your input.
To that end: do you want to take one of the remaining chapters to write? Should I list you on the contributors page (http://projects.webappsec.org/w/page/54150727/WAFEC%202)
I do have a few of your remarks outside of the context of a specific chapter:
We regard to your additions to the use cases chapter: we had a discussion about what to include in the definition and use cases for a WAF . This is not an easy subject and also prone to vendor bias (for each vendor the functionality they provide is a WAF). The decision was to be restrictive to application protection as described in chapter 3 (which itself is still not written). As other features can be very beneficial to the customer as well, even for security, we decided to include all those in an appendix (6.1, "Integrated functionality"). In this framework, each of the additional features you suggest (Authorization and Authentication, DLP, Architecture masking, load balancing and application monitoring are those I notices) should find their place in either section 3.3 if they offer a protection technique or in section 6.1 if they are complementary and of value but do not cover a threat.
Minimum requirements is indeed a challenging section, however I think it is important. Otherwise you will find that any IPS or network firewall can be labeled as a WAF (or an Espresso Machine :-))
Section 4.3 address compatibility with web applications rather than addition features for application delivery.
~ Ofer
-----Original Message-----
From: Erwin Huber [mailto:erwin.huber@ergon.ch]
Sent: Thursday, November 15, 2012 11:58 AM
To: Ofer Shezaf
Cc: wasc-wafec@lists.webappsec.org
Subject: WAFEC 2 outline
Dear WAFEC readers and contributors
I'm Erwin Huber - Head of R&D Web Application Security at Ergon Informatik AG.
Ergon is the vendor of the web application firewall Airlock. WAFs have been the core of my professional life for the last 10 years.
My post comes in the last minute - since I didn't realize, that wafec 2 was growing. Sorry for that.
I appreciate the new approach for the document a lot. To focus on benefits rather than internas is a userfriendly approach.
In chapter 2.2 I suggest the following new Use Cases:
2.2.5 Authorization and Authentication
2.2.6 Architecture Masking
2.2.7 Data Leakage Prevention
Authorization and authentication is a relevant part of the "swiss-style" WAFs.
This is not only Airlock but also Nevis Proxy from Adnovum and Secure Entry Server from United Security Providers. Its a good filtering technique to check the users first if you know that only well known users are allowed on a system.
Airport security does the same thing.
Architecture masking is a benefit that reverse proxy are bringing. There is no information about what logic is implemented on which back-end system.
Today's WAFs (including Airlock) are not good in Data Leakage Prevention. But I think an organisation has an interest in defining types of data which must not leave the perimeter (e.g. unmasked credit card numbers).
Web applications are not the only path infromation can leave a system - so I'm not sure but it's at least worth discussing the issue.
2.3 Minimum Requirement
I don't think this is very useful. The minimum highly depends on the needs and the use case. As a common minium I see "do something more than a traditional firewll on http/https checks". I just don't see the point.
3.3.1 Positive Security
What is the meaning of "URL rewrite and REST interface support"?
I propose as additional content in the paragraph "generic positive security" - this might include automated general protection techniques such as cookie protection, form parameter signatures, url encyrption/signing (workflow binding, anti forceful browsing, anti csrf), declarative whitelisting (the back-end application defines characteristics of parameters - such as pattern in web forms 2.0).
3.3.5 Session Tracking
I propose the additional content "client fingerprinting".
I propose the additional paragraphs:
3.3.6 Content Modification
for DLP, hiding of error pages, ...
3.3.7 Upstream Authentication
4.3.2 Authentication Support
I'm astonished about the mention of NTLM. For me its a bug not a feature to allow NTLM authentication on a public accessible server. NTLM relaying is a known real problem for more than 10 years. Even MS says "do not use NTLM".
Zack Fasel presented his "ZackAttack" Tool on BlackHat 2012:
https://github.com/zfasel/ZackAttack
A good WAF must have the ability to prevent NTLM authentication - not allow it.
I propose the additional paragraphs:
4.3.3 Application Monitoring and Load Balancing Monitor the health state of a back-end server and take measurements (display not-available page, switch to another server instance, ...)
Defining more than one back-end host providing the same content allows an SSL endpoint (such as reverse proxy) session-aware load balancing. All requests for the same user session are reliable on the same back-end system.
5.1 Managment
Why is there no mention for "web interface"?
6.1 Non-technical Criteria
(just a typo in the title)
I'd be more than happy to provide content for the additional sections I propose above.
Any thougths / comments on my propositions?
best regards
erwin