Comparing Scanning Tools

[gunnar at arctecgroup.net (Gunnar Peterson)]

Hi James,

The point is going back to your original question --  "I wonder if budgets
and the tools themselves are really causing more harm than helping in that
enterprises will now think about trading off such tools vs the expense they
cost." -- the economic comparison needs to take into account the tradeoff
not just the expense of the tool, developer productivity, and bug
remediation early v. late, but also the breach itself has a cost when those
bugs that are not dealt are eventually exercised. So I don't care if you
don't like the Gartner numbers, you can use others to weigh the cost of the
breach (Ponemon's are higher actually), but whatever number you choose to
use should be factored in to your model to account for this. It may not be
helpful if not scrubbing in allows your surgeons to operate on more patients
if they are killing them faster due to infections they cause.

-gp


On 6/8/06 9:15 AM, "McGovern, James F (HTSC, IT)"
<James.McGovern at thehartford.com> wrote:

> Several thoughts:
>
> 1. I love it when industry analysts are perceived as being credible by
> throwing out financial costs for things they really don't have visibility
> into.
>
> 2. The VA lost data not do secure coding techniques but an employee not
> following the rules on what data to take out of the building.
>
> 3. No industry analyst has ever attempted to quantify cost vs benefit of
> secure coding when compared to other constraints. The quantification to date
> has only been the cliche: it is cheaper to fix X earlier in the lifecycle
> rather than later in which X could be pretty much any system quality.
>
>
>
> -----Original Message-----
> From: Gunnar Peterson [mailto:gunnar at arctecgroup.net]
> Sent: Thursday, June 08, 2006 9:28 AM
> To: McGovern, James F (HTSC, IT)
> Cc: Secure Mailing List
> Subject: Re: [SC-L] Comparing Scanning Tools
>
>
> Hi James,
>
> I think you are right to look at it as economic issue, but the other factor
> to add into your model is not just the short term impact to developer
> productivity (which is non-trivial), but also the long term effects of
> making decisions *not* to deal with finding bugs.
>
> "Cleaning up data breach costs more than encryption
>
> Protecting customer records is a much less expensive than paying for
> cleanup after a data breach or massive records loss, research company
> Gartner said. Gartner analyst Avivah Litan testified on identity theft
> at a Senate hearing held after the Department of Veterans Affairs lost
> 26.5 million vet identities. "A company with at least 10,000 accounts to
> protect can spend, in the first year, as little as $6 per customer
> account for just data encryption, or as much as $16 per customer account
> for data encryption, host-based intrusion prevention, and strong
> security audits combined," Litan said. "Compare [that] with an
> expenditure of at least $90 per customer account when data is
> compromised or exposed during a breach," she added. Litan recommended
> encryption as the first step enterprises and government agencies should
> take to protect customer/citizen data. If that's not feasible,
> organizations should deploy host-based intrusion prevention systems, she
> said, and/or conduct security audits to validate that the company or
> agency has satisfactory controls in place."
> http://www.techweb.com/wire/security/188702019
>
> Or, Brian Chess once pointed out:
> " My favorite historical analogy this month is from medicine: it took
> *decades* between the time that researchers knew that fewer people died if
> surgeons washed their hands and the time that antisepsis was common in the
> medical community.  That lag was entirely due to social factors: if it's
> 1840 you've been successfully practicing medicine for decades, why would you
> want to change your routine?  And yet imagine a modern day surgeon who says
> "I'm really busy today, so I'm going to save time by not scrubbing in before
> I start the operation."  It's simply unthinkable.  Hopefully software
> development is headed in the same direction, but on an accelerated
> timetable."
>
> -gp
>
>
> *************************************************************************
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited.  If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *************************************************************************
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php