[WEB SECURITY] Are there any disadvantage of Application Security SaaS offering?

Jeremiah Grossman jeremiah at whitehatsec.com
Tue Jul 21 18:55:07 EDT 2009

Hey Raf,

Thanks for the clarification and explanation, but as far as those  
things go, they often lead to needing more of the same.

comments inline:

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...  
> doesn't
> 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  
> them
> "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  
> issues
> such as filling up state tables, and setting off alerts of clogging  
> precious
> 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...  
> right?

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  
> has
> already been broken :)
> Cheers.
> __
> 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  
> outside-
> 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
> example.
> Regards,
> Jeremiah Grossman
> Chief Technology Officer
> WhiteHat Security, Inc.
> http://www.whitehatsec.com/
> 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 mailing list