wasc-wafec@lists.webappsec.org

WASC Web Application Firewall Evaluation Criteria Project Mailing List

View all threads

AWS WAF

CH
Christian Heinrich
Thu, Oct 8, 2015 4:23 AM

Tony,

http://www.slideshare.net/AmazonWebServices/sec323-new-securing-web-applications-with-aws-waf
are the slides of the WAF Product from Amazon Web Services:

I would assume that the AWS partner/vendor integration is via
http://docs.aws.amazon.com/waf/latest/APIReference/Welcome.html

--
Regards,
Christian Heinrich

http://cmlh.id.au/contact

Tony, http://www.slideshare.net/AmazonWebServices/sec323-new-securing-web-applications-with-aws-waf are the slides of the WAF Product from Amazon Web Services: I would assume that the AWS partner/vendor integration is via http://docs.aws.amazon.com/waf/latest/APIReference/Welcome.html -- Regards, Christian Heinrich http://cmlh.id.au/contact
AC
Anton Chuvakin
Thu, Oct 8, 2015 6:37 PM

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/)
to attack an app?    #just_wondering

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

--
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Twitter: @anton_chuvakin https://twitter.com/anton_chuvakin
Work: http://www.linkedin.com/in/chuvakin

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/) to attack an app? #just_wondering On Wed, Oct 7, 2015 at 9:23 PM, Christian Heinrich < christian.heinrich@cmlh.id.au> wrote: > Tony, > > > http://www.slideshare.net/AmazonWebServices/sec323-new-securing-web-applications-with-aws-waf > are the slides of the WAF Product from Amazon Web Services: > > I would assume that the AWS partner/vendor integration is via > http://docs.aws.amazon.com/waf/latest/APIReference/Welcome.html > > > -- > 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 > -- Dr. Anton Chuvakin Site: http://www.chuvakin.org Twitter: @anton_chuvakin <https://twitter.com/anton_chuvakin> Work: http://www.linkedin.com/in/chuvakin
TT
Tony Turner
Thu, Oct 8, 2015 7:19 PM

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 criteria.

-Tony

On Thu, Oct 8, 2015 at 2:37 PM, Anton Chuvakin anton@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/)
to attack an app?    #just_wondering

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

--
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Twitter: @anton_chuvakin https://twitter.com/anton_chuvakin
Work: http://www.linkedin.com/in/chuvakin

--
Tony Turner
OWASP Orlando Chapter Founder/Co-Leader
WAFEC Project Leader
STING Game Project Leader
tony.turner@owasp.org
https://www.owasp.org/index.php/Orlando

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 criteria. -Tony On Thu, Oct 8, 2015 at 2:37 PM, Anton Chuvakin <anton@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/) > to attack an app? #just_wondering > > On Wed, Oct 7, 2015 at 9:23 PM, Christian Heinrich < > christian.heinrich@cmlh.id.au> wrote: > >> Tony, >> >> >> http://www.slideshare.net/AmazonWebServices/sec323-new-securing-web-applications-with-aws-waf >> are the slides of the WAF Product from Amazon Web Services: >> >> I would assume that the AWS partner/vendor integration is via >> http://docs.aws.amazon.com/waf/latest/APIReference/Welcome.html >> >> >> -- >> 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 >> > > > > -- > Dr. Anton Chuvakin > Site: http://www.chuvakin.org > Twitter: @anton_chuvakin <https://twitter.com/anton_chuvakin> > Work: http://www.linkedin.com/in/chuvakin > -- Tony Turner OWASP Orlando Chapter Founder/Co-Leader WAFEC Project Leader STING Game Project Leader tony.turner@owasp.org https://www.owasp.org/index.php/Orlando