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 - Stanford GSB ) WEIS 2011 - George Mason University

2. 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

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

5. 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)

6. “… 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”

7. 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?

8.  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

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

11. Population of potential users

12. 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

13. Consumer’s Problem where:

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

15. Equilibrium Equations Patchable riskZero-day risk

16. Equilibrium Equations Patchable riskZero-day risk

17. Equilibrium Equations Patchable risk

18. Equilibrium Equations

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

20. Loss Liability Vendor’s Problem

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

22. Regulator’s Problem

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

24. 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

25. Proposition (patch liability) Unpatched purchasers Patched purchasers Non-users

26. Short-Run Policy Recommendations

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

28. Proposition Zero-Day Loss Liability

29. Proposition (ctd.)

30. Patch Liability Proposition

31. Patch Liability Proposition

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

33. 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

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

35. Policy Comparisons Proposition

36. Summary of Policy Recommendations