Who Should be Responsible for Software Security? A Comparative Analysis of Liability Policies in Network Environments Terrence August Rady School of Management,

Who Should be Responsible for Software Security? A Comparative Analysis of

Liability Policies in Network Environments

Terrence AugustRady School of Management, UCSD

( Joint with Tunay I. Tunca - Stanford GSB )

WEIS 2011 - George Mason University

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

G1

Software Security R isk

Users

Software F irms

Government

G1: Software liability, open source development subsidies, regulations on software development security practices, and tax penalties on software with poor security

S1

U

G2: Software liability, taxes on software usage, incentive rebates for patching, and subsidies for usage of open source software and/ or SaaS offerings

S1: Design of software offering (on-premises vs. SaaS), and investment in software product security

S2: Design of software offering, source code strategy (open source or proprietary), incentive rebates for patching, investment in software product security, and product pricing

U: Consumer usage and patching behavior

ISR: Measured by the likelihood of successful security attacks and expected aggregate security losses

Legend

S2 G2

Worm DateVulnerability

Notice

Code Red 7.19.2001 1 month

Slammer 1.25.2003 6 months

Blaster 8.11.2003 1 month

Sasser 5.1.2004 2 weeks

Zotob 8.13.2005 4 days

Zero-day AttacksSecurity 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)

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

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?

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

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.

Population of potential users

Population of potential users

Non-users

Patched users

Unpatched users

Don’t contribute to unpatched or zero-day security riskContribute to both

unpatched and zero-day security risk

Contribute only to zero-day security risk

Consumer’s Problem

where:

Analysis

Region 1:(Low price)

Unpatched purchasers Patched purchasersNon-users

Region 2:(High price)

Equilibrium Equations

Patchable risk Zero-day risk

Equilibrium Equations

Patchable risk Zero-day risk

Equilibrium Equations

Patchable risk

Equilibrium Equations

Loss Liability

Liability Mechanisms

Vendor is responsible for a share of the losses

Effective zero-day likelihood

Loss Liability

Vendor’s Problem

Patch Liability

Vendor is responsible for a share of the patching costs

Effective patching costs

Regulator’s Problem

Short-Run Liability Policy

Proposition (loss liability)

Counteracting forces:

• increase

• Price increase

•

Direct effect: Lower

Increase in usage can increase welfare

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

Proposition (patch liability)

Unpatched purchasers Patched purchasersNon-users

Short-Run Policy Recommendations

Investment Cost

Long Run – Investment

By investing in security, the likelihood of a security attack is

reduced by a factor:

PropositionZero-Day Loss Liability

Zero-Day Loss Liability

Proposition (ctd.)

Patch Liability

Proposition

Patch LiabilityProposition

Patch Liability Summary

Low patching costs and investment cost convexity

High patching costs and investment cost convexity

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

Policy Comparisons

Proposition

Proposition

Loss liability is a strictly dominated policy for most software security environments

Policy Comparisons

Proposition

Summary of Policy Recommendations