WAFEC,

I just wanted to let everyone know that I after some offline
"argy-bargy" :) with F5 in September to define the requirement as to
what an end user would be seeking from WAFEC that I believe there
would be some value in their (F5) suggestion (discussed within the
"[WASC-WAFEC] What should we change in WAFEC 2.0?" thread) with the
following caveats:

1. F5 would have to publish their list and therefore their IP to the
   mailing list were I will confirm if that is either a) the list that I
   also reviewed or b) note the differences (it might have been updated
   since September).  I would like to highlight that F5 did not
   requirement me to sign an NDA so this requirement, i.e. publication to
   this mailing list, was specified by me (not F5).

2. The list could be divided into two sections, those entries that are
   related to security and therefore WAFEC and those that aren't which
   could be recorded in an annexure or supplement to the next release of
   WAFEC (v2?).  The roadmap would be to integrate this supplement or
   annexure into the release following the next release of WAFEC (v3?) to
   ease the transition of a major change of WAFEC.

3. It should be endorsed by the various testing labs, e.g.
   https://www.icsalabs.com/, http://www.nsslabs.com/, etc, so that other
   WAF vendors do not claim that the results are skewed for F5.  From my
   own viewpoint as an end user I don't believe this to be case but I
   want to be as fair as possible to other WAF vendors (within reason).

I also would like to thank both Kenneth and Ido from F5 and look
forward to the publication of their list for discussion.

On Tue, Jun 26, 2012 at 6:46 AM, Kenneth Salchow k.salchow@f5.com wrote:

--
Regards,
Christian Heinrich

http://cmlh.id.au/contact

Christian,

I think that F5, like any other interested party (or actually anyone for
that matter), is welcomed to suggest specific criteria to WAFEC 2 and be
considered by the group. It would not be beneficial to the acceptance of
WAFEC if a large chunk (whether a chapter or an appendix) from s single
party, and an interested party at that.

To that end, I urge F5 to share their criteria with the list.

~ Ofer

-----Original Message-----
From: wasc-wafec [mailto:wasc-wafec-bounces@lists.webappsec.org] On Behalf
Of Christian Heinrich
Sent: Monday, October 15, 2012 8:19 AM
To: wasc-wafec@lists.webappsec.org
Subject: Re: [WASC-WAFEC] Annexure or Supplement Proposed by F5

WAFEC,

I just wanted to let everyone know that I after some offline "argy-bargy" :)
with F5 in September to define the requirement as to what an end user would
be seeking from WAFEC that I believe there would be some value in their (F5)
suggestion (discussed within the "[WASC-WAFEC] What should we change in
WAFEC 2.0?" thread) with the following caveats:

1. F5 would have to publish their list and therefore their IP to the mailing
   list were I will confirm if that is either a) the list that I also reviewed
   or b) note the differences (it might have been updated since September).  I
   would like to highlight that F5 did not requirement me to sign an NDA so
   this requirement, i.e. publication to this mailing list, was specified by me
   (not F5).

2. The list could be divided into two sections, those entries that are
   related to security and therefore WAFEC and those that aren't which could be
   recorded in an annexure or supplement to the next release of WAFEC (v2?).
   The roadmap would be to integrate this supplement or annexure into the
   release following the next release of WAFEC (v3?) to ease the transition of
   a major change of WAFEC.

3. It should be endorsed by the various testing labs, e.g.
   https://www.icsalabs.com/, http://www.nsslabs.com/, etc, so that other
   WAF vendors do not claim that the results are skewed for F5.  From my
   own viewpoint as an end user I don't believe this to be case but I want to
   be as fair as possible to other WAF vendors (within reason).

I also would like to thank both Kenneth and Ido from F5 and look forward to
the publication of their list for discussion.

On Tue, Jun 26, 2012 at 6:46 AM, Kenneth Salchow k.salchow@f5.com wrote:

requirements of items that complement a WAF and then have this endorsed by
end user(s) for inclusion or; as a supplement to WAFEC.

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.

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?

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.

--
Regards,
Christian Heinrich

http://cmlh.id.au/contact

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

Hi,
Our perception of WAFEC is that its main purpose is to help a customer choose the right WAF for his environment, as we all know, in real life, when selecting a network security product, there are lots of other considerations in addition to (and most important) the security feature checklist. A good security person needs to interact with his network peers, business owners peers, application peers and unless he demonstrates good knowledge in mitigating their concerns while showing them the business value, his ability to "sell" a solution internally is significantly impacted.

The list below includes questions and points of considerations that will surely pop up from various departments while considering a WAF.
As Christian and Ofer suggested, it may be a good idea to include this list as a annexure. I am sure the list below can be improved.

1.  Load Balancers considerations:
   

   a.        Is it required to add new pools/nodes for the WAF?
   b.        Is it required to deploy, manage and secure SSL certificates on the WAF and the load balancer?
   c.        From performance perspective, how much latency is added when the requests that passes the load balancer need to pass another bump on the wire (go all the way up to Layer 7 and then down again to layer 2)
   d.        Is adding A WAF means that the traffic from the WAF goes back to the load balancer and then being distributed to the web servers? (if yes, it multiplies the throughput through the load balancer, if not what functionality of load balancing can't used ?)
   e.        Can a single WAF supports the multiple VLANs that typically a load balancer is connected to ?
   f.        Does the WAF require the load balancer to load balance the traffic with session stickiness at layer 7 or L4 if any?
   g.        How does the WAF deals with connection pooling (most load balancers use connection pooling to reduce the load from the servers behind them) from session management perspective?
   h.        If the WAF is blocking by sending a RST packet, what would be the affect to connection pooling? (probably kills the TCP connection and dropping all other browser session that are multiplexed on it)
   i.        How to setup high availability WAF architecture when it is being deployed in an environment with a load balancer?

2.  Reverse proxy caching consideration
   

   a.        How to prevent the cache from caching blocking response pages of the WAF ?
   b.        How to clean the cache when the WAF policy is changed? Can this be scripted/ automated?
   c.        How to test the cache against cache poisoning scenario?
   d.        If a cache is used , does it mean that SSL certificates need to deployed secured and managed on the load balancer And the cache proxy And the WAF?
   e.        Should the WAF be deployed in front or behind the cache? (advantages/disadvantages)

3.  Identity management solutions (SSL VPN belongs to this category and we have many customers who use them in concert BTW) considerations:
   

   a.        If the WAF includes end user application reporting, can it pool the username from the identity management solution or it means that this WAF feature won't be available?
   b.        Can the WAF protect the login page of the identity management solution against DOS/Brute Force?
   c.        Where to deploy the WAF? In front or behind the IM solution?
   d.        SSL certificates... manage secure them on the LB, cache proxy, WAF AND the IM solution?

4.  Firewalls/Other security devices
   

   a.        Any integration between the WAF and the firewall to block offending IPs?
   b.        Where to place the WAF? In front or behind the firewall? Advantages/disadvantages ?
   c.        Is it mandatory to use a firewall in front of the WAF?
   d.        Can the WAF integrate with a database firewall? If yes, with who?

General:

•   How much power and rack space is needed to add a WAF to the datacenter?
  

Kind Regards,
Ido Breger

-----Original Message-----
From: wasc-wafec [mailto:wasc-wafec-bounces@lists.webappsec.org] On Behalf Of Ofer Shezaf
Sent: Monday, October 15, 2012 8:49 AM
To: 'Christian Heinrich'
Cc: wasc-wafec@lists.webappsec.org
Subject: Re: [WASC-WAFEC] Annexure or Supplement Proposed by F5

Christian,

I think that F5, like any other interested party (or actually anyone for that matter), is welcomed to suggest specific criteria to WAFEC 2 and be considered by the group. It would not be beneficial to the acceptance of WAFEC if a large chunk (whether a chapter or an appendix) from s single party, and an interested party at that.

To that end, I urge F5 to share their criteria with the list.

~ Ofer

-----Original Message-----
From: wasc-wafec [mailto:wasc-wafec-bounces@lists.webappsec.org]mailto:[mailto:wasc-wafec-bounces@lists.webappsec.org] On Behalf Of Christian Heinrich
Sent: Monday, October 15, 2012 8:19 AM
To: wasc-wafec@lists.webappsec.orgmailto:wasc-wafec@lists.webappsec.org
Subject: Re: [WASC-WAFEC] Annexure or Supplement Proposed by F5

WAFEC,

I just wanted to let everyone know that I after some offline "argy-bargy" :) with F5 in September to define the requirement as to what an end user would be seeking from WAFEC that I believe there would be some value in their (F5) suggestion (discussed within the "[WASC-WAFEC] What should we change in WAFEC 2.0?" thread) with the following caveats:

1. F5 would have to publish their list and therefore their IP to the mailing list were I will confirm if that is either a) the list that I also reviewed or b) note the differences (it might have been updated since September).  I would like to highlight that F5 did not requirement me to sign an NDA so this requirement, i.e. publication to this mailing list, was specified by me (not F5).

2. The list could be divided into two sections, those entries that are related to security and therefore WAFEC and those that aren't which could be recorded in an annexure or supplement to the next release of WAFEC (v2?).
   The roadmap would be to integrate this supplement or annexure into the release following the next release of WAFEC (v3?) to ease the transition of a major change of WAFEC.

3. It should be endorsed by the various testing labs, e.g.
   https://www.icsalabs.com/, http://www.nsslabs.com/, etc, so that other
   WAF vendors do not claim that the results are skewed for F5.  From my
   own viewpoint as an end user I don't believe this to be case but I want to be as fair as possible to other WAF vendors (within reason).

I also would like to thank both Kenneth and Ido from F5 and look forward to the publication of their list for discussion.

On Tue, Jun 26, 2012 at 6:46 AM, Kenneth Salchow <k.salchow@f5.commailto:k.salchow@f5.com> wrote:

requirements of items that complement a WAF and then have this endorsed by end user(s) for inclusion or; as a supplement to WAFEC.

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.

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?

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.

--
Regards,
Christian Heinrich

http://cmlh.id.au/contact

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

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

Hi Ido, all,

as I agree with your list i.g., I disagree partially for the the purpose of WAFEC.
WAFEC's "main purpose is to help a customer choose the right WAF" as you say. In this process all infrastructure and network topics need to be considered too, but
WAFEC solely should focus on the WAF capabilities, not the other ones.
This, and some more considerations, are already coverd in the holistic view
of (biased link):
https://www.owasp.org/index.php/Best_Practices:_Web_Application_Firewalls

Hence I'll mark the items below, which are not core WAFEC, IMHO.
Hope this helps to keep the focus on WAF - Web Application Firewall.

Cheers,
Achim

Am 21.10.2012 10:16, schrieb Ido Breger:

not a WAF problem

not a WAF problem as the end note seen from the internet, which acts as reverse
proxy, always has to do this

not a WAF problem (latency will always decrease if such systems are packed on same
device  :)

hmm, probably I miss some understanding here, but I'd simply say that this describes
a poor configuration

not a WAF problem

this is a good point, but we can omit the comparsion with load balancers

interesting point: depends on where in the network the WAF is located

related to 2.a.

not a WAF problem, except the WAF itself caches (is there any which does this?)

not a WAF problem

not a WAF but general infrastructre problem

i.g. not a WAF problem, but I agree that there are some WAFs which have valuable
authentication mechanisms, I'd suggest that this be a special chapter (adendum for
misc. features) of WAFEC

not a WAF but general infrastructre problem (WAF behind IM with HTTP/HTML
authentication is useless, somehow)

not a WAF but general infrastructre problem (see 1.b. above)

not a WAF but general infrastructre problem

yes ;-)

If we talk about WAFs working on HTTP(S) application layer, then no unless the
database is accessed on HTTP too (which then is some kind of web server).
The WAF may inform DB servers about detected attacks, like it does for the
firewall.

not a WAF problem

Achim,

I would like to highlight the second point from my recent e-mail i.e.
http://lists.webappsec.org/pipermail/wasc-wafec_lists.webappsec.org/2012-October/000110.html

"2. The list could be divided into two sections, those entries that are
related to security and therefore WAFEC and those that aren't which
could be recorded in an annexure or supplement to the next release of
WAFEC (v2?).  The roadmap would be to integrate this supplement or
annexure into the release following the next release of WAFEC (v3?) to
ease the transition of a major change of WAFEC."

On Sun, Oct 21, 2012 at 9:49 PM, Achim Hoffmann websec10@sic-sec.org wrote:

--
Regards,
Christian Heinrich

http://cmlh.id.au/contact

Thanks Ido for sharing the list. I think all are important issues that need
to find their place either in the body of the document or in the Appendix
dedicated to none core WAF feature.

I would like however to comment on those as criteria, especially as I am
going shortly (for real now) ask your help in actually writing WAFEC 2:

.        Questions vs. criteria: Those are questions and not criteria. To
fit WAFEC they need to be specified as criteria which implies providing
specific options and also making the judgment as to if any why one is
better, generally or for a specific use case.

.        Functional requirements vs. Implementation: in most cases criteria
should focus on functional requirements and not specific implementation
allowing each product to implement differently. Quality is determined by
implemented and therefore for each criterion the answer should include
explanation of the implementation method and not just a yes/no.

o  An example is your questions: "Does the WAF require a load balancer.").
A functional criteria would be require a WAF to provide load balancing. A
load balancer is an implantation method. This also implies that this is a
core WAF requirement by the way.

o  All your "how to" questions fall into this category as well.

.        Generalize: We must try to address all use cases and variants. We
all tend to think about what's close to home. For example. , keep in mind
that a large part of the issues you mention do not apply, at least as
written, to host based WAFs. Making them into a criteria rather than an
implementation question may help. Otherwise they may need to be qualified.

.        With respect to the criteria themselves:

o  Many are valid WAF criteria, Load Balancer or not.

o  You put a lot  of emphasis on the advantage of integrating multiple
functions into a single solution. I think it is a worth criterion as part of
the core of the document, but as a single criterion (level of integration of
something along those lines). Moreover, keep in mind there are good reasons
also for not having multiple functions in a single solution (separation of
duty, management flexibility to name two).

~ Ofer

From: Ido Breger [mailto:I.Breger@F5.com]
Sent: Sunday, October 21, 2012 10:17 AM
To: Ofer Shezaf; 'Christian Heinrich'
Cc: wasc-wafec@lists.webappsec.org
Subject: RE: [WASC-WAFEC] Annexure or Supplement Proposed by F5

Hi,

Our perception of WAFEC is that its main purpose is to help a customer
choose the right WAF for his environment, as we all know, in real life, when
selecting a network security product, there are lots of other considerations
in addition to (and most important) the security feature checklist. A good
security person needs to interact with his network peers, business owners
peers, application peers and unless he demonstrates good knowledge in
mitigating their concerns while showing them the business value, his ability
to "sell" a solution internally is significantly impacted.

The list below includes questions and points of considerations that will
surely pop up from various departments while considering a WAF.

As Christian and Ofer suggested, it may be a good idea to include this list
as a annexure. I am sure the list below can be improved.

1.  Load Balancers considerations:
   

a.      Is it required to add new pools/nodes for the WAF?

b.      Is it required to deploy, manage and secure SSL certificates on the
WAF and the load balancer?

c.      From performance perspective, how much latency is added when the
requests that passes the load balancer need to pass another bump on the wire
(go all the way up to Layer 7 and then down again to layer 2)

d.      Is adding A WAF means that the traffic from the WAF goes back to the
load balancer and then being distributed to the web servers? (if yes, it
multiplies the throughput through the load balancer, if not what
functionality of load balancing can't used ?)

e.      Can a single WAF supports the multiple VLANs that typically a load
balancer is connected to ?

f.      Does the WAF require the load balancer to load balance the traffic
with session stickiness at layer 7 or L4 if any?

g.      How does the WAF deals with connection pooling (most load balancers
use connection pooling to reduce the load from the servers behind them) from
session management perspective?

h.      If the WAF is blocking by sending a RST packet, what would be the
affect to connection pooling? (probably kills the TCP connection and
dropping all other browser session that are multiplexed on it)

i.      How to setup high availability WAF architecture when it is being
deployed in an environment with a load balancer?

2.  Reverse proxy caching consideration 
   

a.      How to prevent the cache from caching blocking response pages of the
WAF ?

b.      How to clean the cache when the WAF policy is changed? Can this be
scripted/ automated?

c.      How to test the cache against cache poisoning scenario?

d.      If a cache is used , does it mean that SSL certificates need to
deployed secured and managed on the load balancer And the cache proxy And
the WAF?

e.      Should the WAF be deployed in front or behind the cache?
(advantages/disadvantages)

3.  Identity management solutions (SSL VPN belongs to this category and
   

we have many customers who use them in concert BTW) considerations:

a.      If the WAF includes end user application reporting, can it pool the
username from the identity management solution or it means that this WAF
feature won't be available?

b.      Can the WAF protect the login page of the identity management
solution against DOS/Brute Force?

c.      Where to deploy the WAF? In front or behind the IM solution?

d.      SSL certificates. manage secure them on the LB, cache proxy, WAF AND
the IM solution?

4.  Firewalls/Other security devices
   

a.      Any integration between the WAF and the firewall to block offending
IPs?

b.      Where to place the WAF? In front or behind the firewall?
Advantages/disadvantages ?

c.      Is it mandatory to use a firewall in front of the WAF?

d.      Can the WAF integrate with a database firewall? If yes, with who?

General:

.      How much power and rack space is needed to add a WAF to the
datacenter?

Kind Regards,

Ido Breger

-----Original Message-----
From: wasc-wafec [mailto:wasc-wafec-bounces@lists.webappsec.org] On Behalf
Of Ofer Shezaf
Sent: Monday, October 15, 2012 8:49 AM
To: 'Christian Heinrich'
Cc: wasc-wafec@lists.webappsec.org
Subject: Re: [WASC-WAFEC] Annexure or Supplement Proposed by F5

Christian,

I think that F5, like any other interested party (or actually anyone for
that matter), is welcomed to suggest specific criteria to WAFEC 2 and be
considered by the group. It would not be beneficial to the acceptance of
WAFEC if a large chunk (whether a chapter or an appendix) from s single
party, and an interested party at that.

To that end, I urge F5 to share their criteria with the list.

~ Ofer

-----Original Message-----

From: wasc-wafec [mailto:wasc-wafec-bounces@lists.webappsec.org] On Behalf
Of Christian Heinrich

Sent: Monday, October 15, 2012 8:19 AM

To: wasc-wafec@lists.webappsec.org

Subject: Re: [WASC-WAFEC] Annexure or Supplement Proposed by F5

WAFEC,

I just wanted to let everyone know that I after some offline "argy-bargy" :)
with F5 in September to define the requirement as to what an end user would
be seeking from WAFEC that I believe there would be some value in their (F5)
suggestion (discussed within the "[WASC-WAFEC] What should we change in
WAFEC 2.0?" thread) with the following caveats:

1. F5 would have to publish their list and therefore their IP to the mailing
   list were I will confirm if that is either a) the list that I also reviewed
   or b) note the differences (it might have been updated since September).  I
   would like to highlight that F5 did not requirement me to sign an NDA so
   this requirement, i.e. publication to this mailing list, was specified by me
   (not F5).

2. The list could be divided into two sections, those entries that are
   related to security and therefore WAFEC and those that aren't which could be
   recorded in an annexure or supplement to the next release of WAFEC (v2?).

The roadmap would be to integrate this supplement or annexure into the
release following the next release of WAFEC (v3?) to ease the transition of
a major change of WAFEC.

3. It should be endorsed by the various testing labs, e.g.

https://www.icsalabs.com/, http://www.nsslabs.com/, etc, so that other

WAF vendors do not claim that the results are skewed for F5.  From my

own viewpoint as an end user I don't believe this to be case but I want to
be as fair as possible to other WAF vendors (within reason).

I also would like to thank both Kenneth and Ido from F5 and look forward to
the publication of their list for discussion.

On Tue, Jun 26, 2012 at 6:46 AM, Kenneth Salchow k.salchow@f5.com wrote:

requirements of items that complement a WAF and then have this endorsed by
end user(s) for inclusion or; as a supplement to WAFEC.

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.

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?

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.

--

Regards,

Christian Heinrich

http://cmlh.id.au/contact

wasc-wafec mailing list

wasc-wafec@lists.webappsec.org

http://lists.webappsec.org/mailman/listinfo/wasc-wafec_lists.webappsec.org

wasc-wafec mailing list

wasc-wafec@lists.webappsec.org

http://lists.webappsec.org/mailman/listinfo/wasc-wafec_lists.webappsec.org

Ido,

Have F5 published their answers to this criteria yet and if so can it
be downloaded from a public URL?

On Sun, Oct 21, 2012 at 7:16 PM, Ido Breger I.Breger@f5.com wrote:

--
Regards,
Christian Heinrich

http://cmlh.id.au/contact