1. Who Should be Responsible for Software Security? A Comparative Analysis of Liability Policies in Network Environments Terrence August Rady School of Management, UCSD ( Joint with Tunay I. Tunca – Univ. of Maryland ) NSF Grant: 0954234

3. Microsoft Class Action Lawsuit (2003)  Complaints  A flaw in the software enabled identify theft  Reliance on software patching hasn’t worked  Microsoft has a responsibility to provide secure software  Defense  Microsoft contends it is making substantial investments in security  Why should Microsoft be held liable for the criminal acts of others? Motivation

4. Impact of Security Attacks  SQL Slammer  Ohio’s David-Besse nuclear power plant Safety Parameter Display System (SPDS) crashed for 5 hours  Sasser  Delta Air Lines cancels flights  Sampo bank temporarily closes 130 offices  Lund University Hospital X-ray machines disabled

5. Code Red  Worm that attacks web servers running IIS  Installs back door and propagates 100 times over per infection  Patch issued by Microsoft on June 18, 2001  Struck on July 19, 2001

6. WormDate Vulnerability Notice Code Red7.19.20011 month Slammer1.25.20036 months Blaster8.11.20031 month Sasser5.1.20042 weeks Zotob8.13.20054 days

7. WormDate Vulnerability Notice Estimated Cost ($) Code Red7.19.20011 month2.75 Billion Slammer1.25.20036 months1.5 Billion Blaster8.11.20031 month750 Million Sasser5.1.20042 weeks14.8 Billion Zotob8.13.20054 days$98K/company (on average)

8. Zero-day Attacks Security attacks that occur on vulnerabilities for which no patch is available yet  Code Red  More than 360,000 vulnerable unpatched systems  Zero-day scenario: +$700MM in damages (Moore et al. 2002)  IE7, IE 8 Beta 2 zero-day attack (Dec, 2008)  Downloads Trojan to machine (full compromise)  ActiveX based security holes in MS Office/IE (July 7&13, 2009)  Stuxnet worm: “A working and fearsome prototype of a cyber- weapon that will lead to the creation of a new arms race in the world” (Kaspersky Lab) (Oct, 2010)

9. “… protecting our IT systems and networks has to be a partnership in which all of us have to bear our share of responsibility.” - Department of Homeland Security (2008) Role of Government National Strategy to Secure Cyberspace “Reduce national vulnerability to cyber attacks” “Minimize damage and recovery time from cyber attacks that do occur”

10. Making a Case for Software Liability “The money we spend on security is to deal with the effects of insecure software. And that's the problem. We're not paying to improve the security of the underlying software. We're paying to deal with the problem rather than to fix it… Today, the costs of insecure software aren’t borne by the vendors that produce the software… If we expect corporations to spend significant resources on their own network security -- especially the security of their customers -- it also needs to be in their financial best interests. Liability law is a way to make it in those organizations’ best interests.” Bruce Schneier

11. Views on Software Liability  Proponents of vendor liability (e.g., Schneier 2008)  Products have excessive vulnerabilities  Existence of negative externalities  Firms lack incentives to invest in security  Liability can provide those incentives  Alternative view (e.g., Ho 2009)  Vendors generally release patches  Stifles innovation  Hackers are the true culprits – why punish vendors?  Increased prices  Creating market entry barriers

12. Research questions 1.In the short run, when the security level of a software product is fixed, what role should software liability play? What form of liability is most effective? 2.Given significant negative externalities associated with software patching and security attacks, what shapes vendor incentives to invest in software security? 3.In the long run, with vendor investment, can security liability be effective? If so, what is the best approach to vendor liability?

13. Literature Review Software Patching Beattie et al. (2002) August and Tunca (2006) Arora et al. (2006) Choi et al. (2007) Vulnerability Disclosure Cavusoglu et al. (2007) Arora et al. (2008a, 2008b) Ransbotham and Mitra (2009) Software Liability Kim et al. (2008a, 2008b) Explore the impact of liability on software security Analyze case where government specifies the level of risk-sharing Cavusoglu et al. (2008) Investigate the timing of vendor (firm) patch release (update) Establish that cost-sharing and liability are separately effective August and Tunca (2006) Clarify the effect of both vendor-offered and government specified rebates on patching costs

14.  Consumer valuation space:  Security losses:  Cost of patching:  Money and effort exerted to verify, test, and roll-out patched versions of existing systems  Probability of security attack on patchable vulnerability:  Probability of security attack on zero-day vulnerability: Model

16. Timing (short run) Policy t = 1 t = 2 Vendor sets price, p. Customers make purchase decisions. Vulnerabil ity Announceme nt/ Patching Decisions. Zero Day attack realization. Potential losses incurred by all users. Attack realization. Potential losses incurred by unpatched users.

17.  Consumer Strategy  Buy / Not Buy Patch / Not Patch  Analysis will be carried out for high security breach losses under  Low zero-day risk environments  High zero-day risk environments

18. Population of potential users

19. Non-users Patched users Unpatched users Don’t contribute to unpatched or zero-day security risk Contribute to both unpatched and zero-day security risk Contribute only to zero-day security risk

20. Consumer’s Problem where:

21. Analysis Region 1: (Low price) Unpatched purchasers Patched purchasersNon-users Region 2: (High price)

22. Equilibrium Equations Patchable riskZero-day risk

23. Equilibrium Equations Patchable riskZero-day risk

24. Equilibrium Equations Patchable risk

25. Equilibrium Equations

26. Loss Liability Liability Mechanisms Vendor is responsible for a share of the losses Effective zero-day likelihood

27. Loss Liability Vendor’s Problem

28. Patch Liability Vendor is responsible for a share of the patching costs Effective patching costs

29. Patch Liability Vendor’s Problem

30. Regulator’s Problem

31. Short-Run Liability Policy Proposition (loss liability) Counteracting forces: increase Price increase Direct effect: Lower Increase in usage can increase welfare

32. Proposition (patch liability)  Low patching costs  clear incentives to patch  High zero-day risk  small user population  small unpatched population  lower incentive to patch  If this latter effect is strong, proportion of population who patches can be small; liability can help  High patching costs  requires high liability share

33. Proposition (patch liability)

34. Unpatched purchasers Patched purchasers Non-users

35. Short-Run Policy Recommendations

36. Questions:  If a software vendor adapts its investment in security, would zero-day or patch liability prove useful?  How does security risk affect the vendor’s incentives to invest in product security? How about the Long Run?

37. Investment Cost Long Run – Investment By investing in security, the likelihood of a security attack is reduced by a factor:

38. Regulator’s Problem

39. Proposition Zero-Day Loss Liability

40. Proposition (ctd.)

41. Patch Liability Proposition

42. Patch Liability Proposition

43. Patch Liability Summary Low patching costs and investment cost convexity High patching costs and investment cost convexity

44. Policy Objective Security Standards Directly enforce checking and removal of common vulnerabilities:  buffer overflow, unvalidated input, insecure file operations, secure storage and encryption Capability Maturity Model National Cyber Security Taskforce: Produce Secure Software: Towards more Secure Software DHS: Secure Software Development Life Cycle Processes

45. Regulator’s Problem

46. Policy Comparisons Proposition Loss liability is a strictly dominated policy for most software security environments

47. Policy Comparisons Proposition

48. Summary of Policy Recommendations

49. Summary  Model of software liability that captures:  Patching incentives  Network security externalities stemming from both usage and unpatched usage  Vendor’s investment in security  Liability on security costs  Clarified the appropriate role for liability in both short-run and long-run settings, focusing on the incentives for security investment in the latter one