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" <noloa...@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 <g...@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 _______________________________________________
