[WASC-WAFEC] Annexure or Supplement Proposed by F5

Ido Breger I.Breger at F5.com
Sun Oct 21 04:16:56 EDT 2012

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?

*       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 at lists.webappsec.org] On Behalf Of Ofer Shezaf
Sent: Monday, October 15, 2012 8:49 AM
To: 'Christian Heinrich'
Cc: wasc-wafec at lists.webappsec.org
Subject: Re: [WASC-WAFEC] Annexure or Supplement Proposed by F5


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 at lists.webappsec.org]<mailto:[mailto:wasc-wafec-bounces at lists.webappsec.org]> On Behalf Of Christian Heinrich
Sent: Monday, October 15, 2012 8:19 AM
To: wasc-wafec at lists.webappsec.org<mailto:wasc-wafec at lists.webappsec.org>
Subject: Re: [WASC-WAFEC] Annexure or Supplement Proposed by F5


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 at f5.com<mailto:k.salchow at f5.com>> wrote:
> Sounds like a reasonable, well-founded plan.
> KJ (Ken) Salchow, Jr. | Program Manager, Technical Certification D
> 651.423.1133 M 612.868.1258 P 206.272.5555 F 206.272.5555 www.f5.com<http://www.f5.com>
> -----Original Message-----
> From: Christian Heinrich [mailto:christian.heinrich at cmlh.id.au]<mailto:[mailto:christian.heinrich at cmlh.id.au]>
> Sent: Tuesday, June 19, 2012 4:52 PM
> To: Kenneth Salchow
> Cc: Alexander Meisel; wasc-wafec at lists.webappsec.org<mailto:wasc-wafec at lists.webappsec.org>
> Subject: Re: [WASC-WAFEC] What should we change in WAFEC 2.0?
> Ken,
> My recommendation would be to produce a high level draft of customer
requirements of items that complement a WAF and then have this endorsed by end user(s) for inclusion or; as a supplement to WAFEC.
> On Wed, Jun 20, 2012 at 3:08 AM, Kenneth Salchow <k.salchow at f5.com<mailto:k.salchow at f5.com>> wrote:
>> 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.

Christian Heinrich


wasc-wafec mailing list
wasc-wafec at lists.webappsec.org<mailto:wasc-wafec at lists.webappsec.org>

wasc-wafec mailing list
wasc-wafec at lists.webappsec.org<mailto:wasc-wafec at lists.webappsec.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/wasc-wafec_lists.webappsec.org/attachments/20121021/cde7a10f/attachment-0003.html>

More information about the wasc-wafec mailing list