Unofficial thoughts on liability

1. Unofficial thoughts on liability Herb Lin hlin@nas.edu, 202-334-3191 The viewgraphs following this presentation do not represent the views of any organization with which Herb Lin is affiliated, and in particular they do not represent the views of the CSTB, the National Research Council, or the National Academies.

2. Thoughts on Liability • CSTB/NRC report (Cybersecurity: Pay Now or Pay Later) did NOT endorse liability for software vendors. It said: • “Policy makers should consider legislative responses to the failure of existing incentives to cause the market to respond adequately to the security challenge. Possible options include steps that would increase the exposure of software and system vendors and system operators to liability for system breaches and mandated reporting of security breaches that could threaten critical societal functions.”

3. The broad outline • Market forces have failed to provide an environment in which vendors and users have sufficient incentives to provide for security. • Inadequate information about consequences of breaches. • Society often captures benefits of security investments (social needs greater than corporate needs) • Deregulation forces more competitive pressures

4. Possible Responses to Market Failures • Mandate behavioral changes • Shift the economic calculus • carrots • yearly award for cybersecurity from Ofc of Homeland Security and the President • Malcom Baldridge Quality Award • ISO certification? • Immunity for early reporting? (like FAA) • Possible sticks • Liability • red team results into public documents • accounting standards to include cybersecurity assessments

5. Issues raised by liability • differentiating between infrastructure and end user for liability purposes (e.g., my program works on your operating system - how to allocate liability?) • holding infrastructure providers liable for economic damage is hard under current case law • uncorrelated damages mean that insurance model won’t work

6. Issues (continued) • reducing incentives to disseminate information or to allow forensics or to provide fixes • holding vendors responsible for something they don't know how to do (e.g., how do deal with loss of functionality from security patch, which doesn't always work properly)

7. Issues (continued) • establishing standards of care (best practices? certification?) • hard for lay people to understand security breaches - how to decide on liability • good methodology to establish extent of liability

8. Losses due to deliberate action (hence no actuarial basis) (terrorists are not a probability distribution) No metrics for security Fundamental science of cybersecurity is not known Damage is often invisible Technical standardization can be similar to monoculture; weak in face of correlated threat Impact of fix often impossible to be localized Losses largely due to accident (harder to insure against arson than lightening) Fire resistance can be quantified (sort of) Fundamental science of fireproofing and structural engineering is known Damage is visible Standardization is advantageous when failures can be uncorrelated Impact of fixes can be localized Fire vs Cyberhack Prevention