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
I nfor m at i on Secur i t y R i sk ( I SR )
U
U ser s
S1
S2
G2
Soft war e
Fir ms
G over nm ent
G1
Legend
G1: Soft ware liabilit y, open source development subsidies, regulat ions on soft ware development securit y
pract ices, and t ax penalt ies on soft ware wit h poor securit y
G2: Soft ware liabilit y, t axes on soft ware usage, incent ive rebat es for pat ching, and subsidies for usage of
open source soft ware and/ or SaaS offerings
S1: Design of soft ware offering (on-premises vs. SaaS), and invest ment in soft ware product securit y
S2: Design of soft ware offering, source code st rat egy (open source or propriet ary), incent ive rebat es for
pat ching, invest ment in soft ware product securit y, and product pricing
U: Consumer usage and pat ching behavior
I SR: Measured by t he likelihood of successful securit y at t acks and expect ed aggregat e securit y losses
Motivation
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?
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
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
Worm
Date
Vulnerability
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 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 cyberweapon that will lead to the creation of a new arms race in the
world” (Kaspersky Lab) (Oct, 2010)
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”
“… 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)
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
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
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?
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
Model
 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:
¼wa
1-¼v
V ulnerabilit y
does not arise
¼w
Discovered by
whit e hat
(pat ch released)
1-¼wa
¼v
V ulnerabilit y
arises
1-¼w-¼b
A t t ack occurs on
pat chable
vulnerabilit y
No at t ack occurs
Not discovered
¼ba
Zero-day at t ack
occurs
1-¼ba
No at t ack occurs
¼b
Discovered by
black hat
Timing (short run)
Vendor sets
price, p.
Customers
make
purchase
decisions.
Policy
t =
1
Vulnerabil
ity
Announceme
nt/
Patching
Decisions.
t =
Zero Day
attack
realization.
Potential
losses
incurred by
all users.
2
Attack
realization.
Potential
losses
incurred by
unpatched
users.
 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
Population of
potential users
Population of
potential users
Non-users
Patched users
Don’t contribute to
Contribute
only to
unpatched
orUnpatched
zero-day
users
zero-day
security
risk
Contribute
to
both
security risk
unpatched and zero-day
security risk
Consumer’s Problem
where:
Analysis
Region 1:
(Low price)
Non-users
Region 2:
(High price)
Unpatched purchasers
Patched purchasers
Equilibrium Equations
Patchable risk
Zero-day risk
Equilibrium Equations
Patchable risk
Zero-day risk
Equilibrium Equations
Patchable risk
Equilibrium Equations
Liability Mechanisms
Loss Liability
Vendor is responsible for a share
of the losses
Effective zero-day likelihood
Vendor’s Problem
Loss Liability
Patch Liability
Vendor is responsible for a share
of the patching costs
Effective patching costs
Vendor’s Problem
Patch Liability
Regulator’s Problem
Short-Run Liability Policy
Proposition (loss liability)
Direct effect: Lower
Increase in usage can increase welfare
Counteracting forces:
•
increase
• Price increase
•
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)
Proposition (patch liability)
Non-users
Unpatched purchasers
Patched purchasers
Short-Run Policy Recommendations
How about the Long Run?
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?
Long Run – Investment
Investment Cost
By investing in security, the likelihood of a security attack is
reduced by a factor:
Regulator’s Problem
Zero-Day Loss Liability
Proposition
Zero-Day Loss Liability
Proposition (ctd.)
Patch Liability
Proposition
Patch Liability
Proposition
Patch Liability Summary
Low patching costs and
investment cost convexity
High patching costs and
investment cost convexity
Security Standards
Policy Objective
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
Regulator’s Problem
Policy Comparisons
Proposition
Proposition
Loss liability is a strictly dominated policy for most
software security environments
Policy Comparisons
Proposition
Summary of Policy Recommendations
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