[WASC-WAFEC] Annexure or Supplement Proposed by F5

Achim Hoffmann websec10 at sic-sec.org
Sun Oct 21 06:49:25 EDT 2012

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):

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.


Am 21.10.2012 10:16, schrieb Ido Breger:
> 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?

not a WAF problem

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

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

>       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)

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

>       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 ?)

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

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

not a WAF problem

>       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?

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

>       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 ?

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

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

related to 2.a.

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

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

>       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?

not a WAF problem

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

not a WAF but general infrastructre problem

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

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

>       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?

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

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

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

> 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 ?

not a WAF but general infrastructre problem

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

yes ;-)

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

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 

> General:
> *       How much power and rack space is needed to add a WAF to the datacenter?

not a WAF problem

> 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
> 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 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.
> --
> Regards,
> Christian Heinrich

More information about the wasc-wafec mailing list