[WEB SECURITY] Are there any disadvantage of Application Security SaaS offering?
jeremiah at whitehatsec.com
Tue Jul 21 18:55:07 EDT 2009
Thanks for the clarification and explanation, but as far as those
things go, they often lead to needing more of the same.
On Jul 21, 2009, at 11:10 AM, Rafal @ IsHackingYou.com wrote:
> Actually... if I may throw in an HP vendor-response here... that's not
> entirely the case!
> Our [HP's] "SaaS" offering employs and extends our sensor/
> controller model
> wherein there is a "Controller" (AMP Server) which lives at the SaaS
> hosted-center; while your "sensors" live where ever you would like
> them to
> live. This can be internal, external, or in the SaaS environment...
> matter- for us it's all in the implementation.
With SaaS a key benefit is an organization does not have to purchase/
manage any hardware/software. In your description the customer "buys"
sensor appliances and has them hosted at HP, sort of like an ISP.
Alternately the sensors can be put inside their own data center, where
presumably they must manage them. A true SaaS platform is where all
functional code is centrally managed in a single-instance by the SaaS
> Our customers typically utilize the sensors so that they can place
> "inside the data center" closest to their applications so as not to
> have to
> scan across IPS/IDS, firewalls and other network devices for a
> "clean" scan.
> These sensors are commonly deployed internally as well where the
> sensor and
> controller only need to communicate via https... and only on scan
> initialization (controller sends comment to sensor) and completion
> of the
> scan (sensor sends back findings).
Interestingly, most customers usually start out wanting testing
performed across/through all of their compensating controls, network,
WAF, IPS, etc. This is because they usually believe their compensating
controls (with the exception of WAFs) provide value or protection. 99%
of the time they provide no value or protection for websites. Anyone
on the list have a similar experience?
> We've utilized this model in order to cut down on the volume of
> traffic we
> have to send when crossing customer equipment for internal scans (even
> exterior-facing scans cross firewalls) as this can cause customers
> such as filling up state tables, and setting off alerts of clogging
> bandwidth. Also, this makes more certain that a 'scan' is cleared
> of any
> network-generated false-positives/false-negatives.
If I read your comment correctly, your scanning technology produces
traffic volumes (or types) that adversely affect production websites /
networks with enough frequency that it necessitates the non-preferable
aforementioned deployment model. At the risk of causing a vendor
dispute, we're not seeing anything like "filling up state tables, and
setting off alerts of clogging precious bandwidth" as an issue. Finely
tuned non-destructive checks and a sane well-vetted testing
methodology solves most problems in our experience.
> Think about it... if an
> attack is sent and captured on your IPS/IDS and never makes it to
> your app
> (and your app is vulnerable to the attack) you still want to know...
For what its worth we typically have to convince organizations that
they really should get the "clean" version of the assessment. Some
customers have us set up both "clean" and "dirty" network channels.
They may both be over the internet, or sometimes the "clean" path is
via a appliance proxy.
> Sorry for the vendor response but I figured I'd jump in as the ice
> already been broken :)
> Rafal M. Los
> Security & IT Risk Strategist
> - Blog: http://preachsecurity.blogspot.com
> - LinkedIn: http://www.linkedin.com/in/rmlos
> - Twitter: http://twitter.com/RafalLos
> From: "Jeremiah Grossman" <jeremiah at whitehatsec.com>
> Sent: Tuesday, July 21, 2009 12:35 PM
> To: <websecurity at webappsec.org>
> Subject: Re: [WEB SECURITY] Are there any disadvantage of Application
> Security SaaS offering?
> On Jul 21, 2009, at 10:15 AM, Bil Corry wrote:
>> Jeremiah Grossman wrote on 7/21/2009 10:59 AM:
>>> At the same time, anything offered as SaaS have
>>> common disadvantages and website VA is no different.
>> Would a product such as yours still work when the target system is
>> inaccessible from the internet?
> Maybe I should have listed the potential disadvantage of SaaS as it
> would appears the external position only allows it to scan Internet-
> facing websites. There are SaaS-based website VA offerings, WhiteHat
> Sentinel included, capable of supporting non-Internet-facing systems
> such as in development and staging environments. This is achieved in
> two possible ways.
> 1) Allow the SaaS offering IP-ranges through the firewall and/or route
> them to the eventual destination.
> 2) Appliance proxy. Install a device behind the firewall, which then
> connects out to the SaaS infrastructure thereby establishing a
> inside traffic conduit. Whatever the proxy is allowed to access, so
> can the SaaS offering.
> Both options are already fairly common in the managed security
> services markets, IDS/IPS and network vulnerability scanning for
> Jeremiah Grossman
> Chief Technology Officer
> WhiteHat Security, Inc.
> Blog: http://jeremiahgrossman.blogspot.com/
> Twitter: jeremiahg
Join us on IRC: irc.freenode.net #webappsec
Have a question? Search The Web Security Mailing List Archives:
Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
Join WASC on LinkedIn
More information about the websecurity