Christian Strache cs at strache-it.de
Fri Oct 9 03:15:20 EDT 2015

  Dear Tony,

your explanations sound reasonable.
But, when you created your requirement catalogue and try to compare 
different products, many 'big players' (i.e. Gartner listed WAFs) offer 
the same set of features.
So, for example using the WAFEC to find a suitable product for a 
customer with few requirements often ends up with a drawn in the 
I guess if try to find out what features an AWS WAF offers, 
Blacklisting, Whitelisting, Signatures, regular updates etcetera the AWS 
WAF will fulfill those features. The quality and the customization 
features however may differ from the once you get with other 'on 
premise' products.

Do you think it may be possible to add a criteria to the WAFEC to 
distinguish between:
- yes, product offers feature XYZ
- yes, product offers feature XYZ based on a GUI/requires manual adaption
- yes, product offers features XYZ but only allows restricted adaption 
requiering operating system level changes.

Kind regards,

*Von:*wasc-wafec [mailto:wasc-wafec-bounces at lists.webappsec.org] *Im 
Auftrag von *Tony Turner
*Gesendet:* Donnerstag, 8. Oktober 2015 21:20
*An:* Anton Chuvakin <anton at chuvakin.org>
*Cc:* wasc-wafec at lists.webappsec.org
*Betreff:* Re: [WASC-WAFEC] AWS WAF

Anton, A WAF is just a tool, it's all in how it's used. How can the tool 
be extended through additional extrinsic features? This is where the top 
players in the space (no I won't name names, we are all friends here) 
really start to shine and where they differentiate themselves from the 
competition. Ease of use, centralized management, threat feeds, load 
balancing, etc. Does that mean if you don't have those things you can't 
use the tools effectively? Does it make it an inferior product? What if 
I don't need an ADC-based WAF because I'm happy with my existing load 
balancer? Does that mean my WAF can't still perform its core functions 
to detect and mitigate web app attacks?

I do understand the direction you are going in here, and yes this will 
likely be misused by compliance minded entities. I think it's important 
to remember that any 2 WAF consumers may have vastly different 
requirements. The objective here is to define the core of what a WAF is 
and should be capable of, but what exactly are we talking about here? 
Many (but not all) of these extrinsic criteria are dependent upon 
deployment architectures. We aren't always comparing reverse proxy to 
reverse proxy here, and in fact the customer may not even want to 
architect the solution that way. This makes WAF a more complex product 
to develop criteria for because implementations are frequently not very 
cookie-cutter. Then when you start talking about framework filters and 
RASP, the conversation gets even more confusing for a lot of people.

I think when you take the typical Gartner-centric view of a solution 
space you are looking at a product category very generically. How can we 
evaluate vendors in a way that fits as many scenarios as possible with 
the greatest amount of options for consumers? That's great, and has 
substantial value. But that doesn't always map to real world requirements.

Instead I think it makes sense to create a core framework for WAF 
criteria and provide a modular approach we can leverage when we develop 
the WAFEC Response Matrix that identifies those extrinsic criteria only 
when they are mapped to actual customer requirements. The criteria will 
be broken up into categories such that if you need SSL offload, or a 
cloud deployment we will have a set of criteria that map to that 
requirement. If you don't, why would you care about those capabilities?

Lastly, there's really 2 audiences for WAFEC. Firstly, are the vendors 
that make WAFs and organizations like Gartner seeking to evaluate the 
product space. Secondly, are consumers who likely have very specific 
needs. They may not care about cloud deployments or DLP capabilities or 
how friendly the support staff are that they never need to call or 
<insert extrinsic capability>. I honestly think with this approach you 
can be as inclusive or exclusive as you want to when utilizing the 
framework for evaluation. So if you are a vendor or Gartner, or you have 
not identified all your requirements and you want to see who has the 
shiniest toys, you just check all the boxes. If you have more selective 
requirements, you can just build your menu and evaluate based on those 


On Thu, Oct 8, 2015 at 2:37 PM, Anton Chuvakin 
<<mailto:anton at chuvakin.org>anton at chuvakin.org> wrote:

So, assuming this WAF would be "a basic WAF", do you guys think that a 
basic WAF is actually useful for anything apart from compliance? When 
was the last time somebody used a generic SQLi (like so 
<https://xkcd.com/327/>https://xkcd.com/327/) to attack an app? 

On Wed, Oct 7, 2015 at 9:23 PM, Christian Heinrich 
<<mailto:christian.heinrich at cmlh.id.au>christian.heinrich at cmlh.id.au> wrote:


are the slides of the WAF Product from Amazon Web Services:

I would assume that the AWS partner/vendor integration is via

Christian Heinrich


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


Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Twitter: @anton_chuvakin<https://twitter.com/anton_chuvakin>


Tony Turner
OWASP Orlando Chapter Founder/Co-Leader

WAFEC Project Leader

STING Game Project Leader
tony.turner at owasp.org<mailto:tony.turner at owasp.org>


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

More information about the wasc-wafec mailing list