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

Jim Manico jim at manico.net
Wed Jul 22 18:15:12 EDT 2009


Regarding an AppSec SaaS OWASP Podcast:

Brian Chess (from Fortify), Rafal Los (from HP), Trey Ford (from WHS) have 
agreed to participate so far. This should be fun.

Is anyone from Veracode is listening in, please drop me a line at 
podcast at owasp.org.

Do you recommend anyone else to invite from the AppSec SaaS world?

Thanks all,
- Jim Manico
OWASP Podcast Host
podcast at owasp.org

----- Original Message ----- 
From: "Martin, Christopher" <chrismartin at firstam.com>
To: "Jim Manico" <jim at manico.net>; "Rafal M. Los" <rafal at ishackingyou.com>; 
<websecurity at webappsec.org>
Sent: Wednesday, July 22, 2009 7:12 AM
Subject: RE: [WEB SECURITY] Are there any disadvantage of Application 
Security SaaS offering?


Lol, I second the motion!


Christopher A. Martin
Manager, CITG Information Security Risk Management
First American Corporation
1 First American Way
Westlake, Texas 76262
Office: (817) 699-4309
http://www.firstam.com
**********************************************************************
This message contains confidential information intended only for the use
of the addressee(s) named above and may contain information that is
legally privileged. If you are not the addressee, or the person
responsible for delivering it to the addressee, you are hereby notified
that reading, disseminating, distributing or copying this message is
strictly prohibited. If you have received this message by mistake,
please immediately notify us by replying to the message and delete the
original message immediately thereafter.
Thank you.
FADLD Tag
**********************************************************************


-----Original Message-----
From: Jim Manico [mailto:jim at manico.net]
Sent: Tuesday, July 21, 2009 7:47 PM
To: Rafal M. Los; websecurity at webappsec.org
Subject: Re: [WEB SECURITY] Are there any disadvantage of Application
Security SaaS offering?

AppSec SaaS roundtable/smackdown for the OWASP Podcast Series?


Anyone in?

- Jim

----- Original Message -----
From: "Rafal M. Los" <rafal at ishackingyou.com>
To: <websecurity at webappsec.org>
Sent: Tuesday, July 21, 2009 2:41 PM
Subject: Re: [WEB SECURITY] Are there any disadvantage of Application
Security SaaS offering?


> Hey Jeremiah (and everyone else) - not wishing to turn this into a
> vendor clash, so here's my in-line responses.... (below)... Let's
> continue our vendor-specific conversations offline if you'd like?
>
> Cheers!
>
> __
> Rafal M. Los
> Security & IT Risk Strategist
>
> E-mail:  rafal at ishackingyou.com
> Direct:  +1 (765) 24-RAFAL
> - 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 5:55 PM
> To: <websecurity at webappsec.org>
> Subject: Re: [WEB SECURITY] Are there any disadvantage of Application
> Security SaaS offering?
>
> 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 provider.
>
> With HP's offering the customer has the *flexibility* to do what ever
> they please, buying a "sensor" is neither necessary not customary.
> Those sensors are simply "dropped" in their data centers as they
> request - remember that placing a sensor at the customer premise is
> simply a value-add, and not a necessity... many of our SaaS customers
> are happy enough to conduct scans from the hosted SaaS platform far
> away in our data-center.
>
>>  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?
>
> The customer experiences I've had prefer to assume their network-based

> defenses aren't going to protect them (WAF excluded, of course)... as
> our sales-force makes it a point to educate them of that... now,
> granted this isn't an easily accepted point :)
>
>>  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.
>
> Not at all... We simply offer this model in order to *reduce the risk*

> or even the appearance or possibility of that risk to our customers.
> They typically have a hard-enough time getting security in to 'scan'
> applications
> in production - so we make sure we minimize even the appearance of
> that risk.  It's not about causing adverse reactions - however - it's
> more along the lines of minimizing the risks... real of perceived
> -because both matter.
>
>
>> 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.
>
> This is hit and miss... it depends heavily on the maturity of the
> organization that we're dealing with.  There are those who just want
> to scan and don't have much due care for whether it's clean or
> dirty... and then there are those who are terrified to scan production

> systems (often rightfully so... many stories here)... so in the end
> it's a mix of the two and heavily depends on what the customer wants.

> We do our best to educate, but sometimes you can't fight years of
> mis-information.
>
>
>>  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:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>
> ----------------------------------------------------------------------
> ------ Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>


------------------------------------------------------------------------
----
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



******************************************************************************************
This message may contain confidential or proprietary information intended 
only for the use of the
addressee(s) named above or may contain information that is legally 
privileged. If you are
not the intended addressee, or the person responsible for delivering it to 
the intended addressee,
you are hereby notified that reading, disseminating, distributing or copying 
this message is strictly
prohibited. If you have received this message by mistake, please immediately 
notify us by
replying to the message and delete the original message and any copies 
immediately thereafter.

Thank you.
******************************************************************************************
FACLD



----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



More information about the websecurity mailing list