Re: SearchSecurity: Cyber Security and the Law

[Iván Arce <ivan.w.arce () gmail com>]

I think that BOTH incentives and dis-incentives (in the form of
liabilities) may be a good approach to the problem of broken software.
If nothing else, at least they would be a different approach and that,
by itself, could be positive since current alternatives, mostly founded
on US national security concerns, do not seem to be meeting the
expectation of fostering improvements in software security.

There's been a lot of debate and discussion about this topic over at
least a decade and it always ended nowhere. I think the failure hinged
more on political stances than on an actual need for technically precise
definitions about "good engineering".

In any case, a good start would be to address the ridiculous terms of
almost every software EULA: 'This software is provided "as is", without
warranty of any kind, express or implied..." either forbidding govt
purchase of sw with that or similar clauses, imposing a premium for it
or directly forbidding it with regards to security issues.

The lack of a "get out of jail free" clause could motivate software
vendors to seek risk mitigation/transfer options of which "good
engineering" is just one of them.

I don't think tax incentives alone would suffice to improve software
security. Let's suppose the incentive takes the form of lowering
business income tax on the basis of verifiable deployment of some kind
of SDL. The cost of setting up and running a software security
initiative would be offset by the benefit of a lower effective income
tax rate which is nonetheless bounded. The sum could even be positive
but the whole effort could be perceived as detrimental to a much more
rewarding increase in the top line revenue which is *comparatively*
unbounded, so why bother if there's no downside?

Even if some businesses do bother, deployment of any type of SDL
provides no concrete evidence of improvement and in most cases it is a
forward-looking endeavor that does little about the software base that
is already deployed. This in turn leads inevitably to an eternal debate
about security metrics and how to effectively measure software security
progress in terms of actual benefit to a real world nation's society or
business ecosystem. Getting hung on defining good security metrics for
the purpose is likely to lead into a non-halting process, so in my
opinion it is better to just start with something and build from that.

For example, vulnerability count is something usable if combined with a
handful of other variables like "time to issue patch" (TIP, in days) and
"size of vulnerable user base" (VUB, in sw units). SW companies (at
least public ones) could be required to disclose not just security vulns
in their software but also when they were discovered and how long it
took them to issue a patch, they could then be either liable, benefited
or penalized for k*(threshold-TIP)*SUB dollars, with K a constant set
appropriately arbitrarily depending on ranges of "SUB" or type of
industry where the SW is installed. Companies that consistently beat
industry average could be additionally benefited with tax breaks,
companies that consistently under-perform before some 2nd threshold
could face exponentially increasing tax penalties (up to an upper
limit). Companies that continue to sell software using the ignominious
warranty-less EULA or that are caught cheating could be subjected to a
SW security sales tax for a fixed period of time and *not* a one time
penalty which is subject to "arbitrage"

Insurance against software security related losses could be a viable way
to mitigate risk of outliers in the process (or/and class action suits).

I realize all of these are just far fetched ideas but I believe the only
reasonable way to address the software security issue is to approach it
from an economy and trade perspective rather than national security or
consumer's right problems.

... and those are my 2 regulatory pesos

-ivan

On 8/2/12 4:13 PM, Greg Beeley wrote:
> How would we recognize good engineering?
>
> It seems to me like the very same problem faced by the idea of software
> liability law - that it is hard to define good engineering for software
> security - would be faced by an incentive program.  If "good
> engineering" is fuzzy enough to give a big corporate legal dept the
> upper hand against an individual, wouldn't it be similarly fuzzy enough
> to counter the fairness of a tax incentive?
>
> Tax breaks are a big deal - I doubt the government is going to want to
> issue tax breaks to a company because the company claims they have
> achieved level X in a CMM -- think about the economic cost in
> demonstrating something like that to the point where it is fair and
> worth something.  I also doubt that a metric based on vulnerability
> counts will work -- that will just encourage companies to hide
> vulnerabilities, fixing them silently and/or with great delay, instead
> of disclosing them.
>
> Not that I think that incentives inherently wouldn't work -- rather I'd
> be interested in seeing some discussion here on some of the above issues.
>
> One alternative that has worked well in many other areas of
> manufacturing -- encourage some kind of limited warranty, at least in
> certain industries.  For consumer mobile devices, it might be something
> as simple as, "if your device's security is ever compromised due to a
> flaw in the bundled device software, we'll repair it free of charge".
> The big challenges are 1) getting customers to care about their device's
> security, and 2) making a vendor's commitment to security recognizable
> by the customer.  By no means ideal, but at least a talking point.
>
> - Greg
>
> Gary McGraw wrote, On 08/02/2012 08:40 AM:
> > Hi Jeff,
> >
> > I'm afraid I disagree.  The hyperbolic way to state this is, imagine YOUR
> > lawyer faced down by Microsoft's army of lawyers. You lose.
> >
> > Software liability is not the way to go in my opinion.  Instead, I would
> > like to see the government develop incentives for good engineering.
> >
> > gem
> >
> > On 8/2/12 10:26 AM, "Jeffrey Walton" <noloader () gmail com> wrote:
> >
> > > Hi Dr. McGraw,
> > >
> > > > Cyber Intelligence Sharing and Protection Act (CISPA) passed by
> > > > there House in April) has very little to say about building security in.
> > > I'm convinced (in the US) that users/consumers need a comprehensive
> > > set of software liability laws. Consider the number of mobile devices
> > > that are vulnerable because OEMs stopped providing (or never provided)
> > > patches for vulnerabilities. The equation [risk analysis] needs to be
> > > unbalanced just a bit to get manufacturers to act (do nothing is cost
> > > effective at the moment).
> > >
> > > Jeff
> > >
> > > On Wed, Aug 1, 2012 at 10:28 AM, Gary McGraw <gem () cigital com> wrote:
> > > > hi sc-l,
> > > >
> > > > This month's [in]security article takes on Cyber Law as its topic.  The
> > > > US Congress has been debating a cyber security bill this session and is
> > > > close to passing something.  Sadly, the Cybersecurity and Internet
> > > > Freedom Act currently being considered in the Senate (as an answer to
> > > > the problematic  Cyber Intelligence Sharing and Protection Act (CISPA)
> > > > passed by there House in April) has very little to say about building
> > > > security in.
> > > >
> > > > Though cyber law has always lagged technical reality by several years,
> > > > ignoring the notion of building security in is a fundamental flaw.
> > > >
> > > >
> > > > http://searchsecurity.techtarget.com/opinion/Congress-should-encourage-bu
> > > > g-fixes-reward-secure-systems
> > > >
> > > > Please read this month's article and pass it on far and wide.  Send a
> > > > copy to your representatives in all branches of government.  It is high
> > > > time for the government to tune in to cyber security properly.
> >
> >
> > _______________________________________________
> > Secure Coding mailing list (SC-L) SC-L () securecoding org
> > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> > List charter available at - http://www.securecoding.org/list/charter.php
> > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> > as a free, non-commercial service to the software security community.
> > Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
> > _______________________________________________
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L () securecoding org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
> _______________________________________________

_______________________________________________
Secure Coding mailing list (SC-L) SC-L () securecoding org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
_______________________________________________