Liability for Software Vulnerabilities

1. Liability for Software Vulnerabilities Richard Warner Chicago-Kent College of Law rwarner@kentlaw.edu

2. My Conclusions • Flaws in software—”vulnerabilties”—facilitate unauthorized access computers and networks. • The law’s ability to decrease vulnerabilities in software is limited. • We have to rely on market solutions.

3. Vulnerability Defined • A vulnerability is a feature one can exploit to gain unauthorized access. • Organization of Internet Safety: “A security vulnerability is a flaw within a software system that can cause it to work contrary to its documented design and could be exploited to cause the system to violate its documented security policy.” • www.osisafety.org

4. The Difficulty of Defense • If the software has 100 vulnerabilities, you need to find all, or at least most, of them to be secure against unauthorized access. • The hacker just needs to find one that you have not yet found. • In the race with the hacker, the hacker will almost certainly win.

5. A Snapshot of the Problem • 2006 IBM Internet Security Systems report. • Detected vulnerabilities increased 39% in 2006. • Because of better detection tools. • The top 10: Microsoft, Oracle, Apple, Mozilla, IBM, Linux Kernal Organization, Sun, Cisco, HP, Adobe Systems. • Sans Institute 2006 list of the top 20 security attack targets. • http://www.sans.org/top20

6. Operating systems • Internet Explorer • Windows Libraries • Microsoft Office • Windows Services • Windows Configuration Weaknesses • Mac OS X • UNIX Configuration Weaknesses

7. Cross-Platform Applications • Web Applications • Database Software • P2P File Sharing Applications • Instant Messaging • Media Players • DNS Servers • Backup Software • Security, Enterprise, and Directory Management Servers

8. Network Devices • VoIP Servers and Phones • Network and Other Devices Common Configuration Weaknesses

9. The Question • Why is software so buggy? • There are at six reasons which apply to all software. • In addition, there are special concerns about • Operating systems • Applications • Security software

10. 1. Complexity • It is impossible to write complex software without creating vulnerabilities. • Compare • Prescription drugs. • It is often impossible to achieve therapeutic effects with out the risk of undesirable side effects. • Inherently dangerous but useful activities such as the use of explosives.

11. 2. Lack of Skill • As in any other profession, programmers differ in skill. • A grandmaster chess player may easily find a vulnerability in a defense that a master overlooks. • Demand for programmers means that many unskilled programmers still get jobs.

12. 3. Group Programming • Complex software cannot be built by a single person. It is programmed by a group. • The programming process suffers from the communication and coordination problems inherent in groups.

13. 4. Programming Languages • Some programming languages are more secure than others. That is, it is easier in some than others to make mistakes that create vulnerabilities.

14. 5. Discrete Versus Continuous • Bridge building: an engineer discovers that the value of an important variable varies by a small amount ε from the correct value. • Typically, a small error in one value produces only small errors in other values. • The correct value will be δ(ε) (where δ is some reasonable function). • Software • A small error can produce catastrophic results. • Error correction is discrete: A “0” replaces a “1” or vice versa.

15. 6. Market Pressures • Network effects • It is critical to be first to market where network effects are strong, as in software. • Buyers insistence on usability. • Buyers insist on usability. • Security often reduces usability, but • Buyers—irrationally?—undervalue security. • It is difficult for buyers to evaluate security features.

16. Operating Systems • Operating systems raise special concerns because of the lack of competition. • Compare the Windows family to Unix (Linux and Mac OS X). • Microsoft’s dominate position allows it to persist in marketing an insecure operating system along with other insecure bundled products.

17. Applications • Applications raises special issues when they are implemented on Internet accessible systems. • Software which seems secure when tested in a stand-alone environment may contain or create vulnerabilities in the environment in which it is actually used. • It can be extraordinarily difficult to predict what software will do when it is embedded in a complex network. • The following diagram—a very small part of one corporate network—illustrates the degree of complexity involved.

19. Applications: Legacy Systems • Old systems can be difficult or expensive to update. • Many systems run outdated, insecure software. • As Ross Anderson notes.

20. Applications: Inadequate documentation • Most products do not clearly document • their out-of-the-box security configuration • security assumptions • security capabilities, • recommended practices. • The tech support issue: • “Vendors are naturally inclined to hold out until users pay for support and to provide minimal documentation so as to increase the number of support paid support calls. Vendors claim that they have to pay their support costs, but making effective user interfaces and completely documenting software can nearly eliminate support calls.” • Strebe and Perkins, Network Address Translation • There are price discrimination efficiencies from this approach.

21. Security software: Lemons market • In a lemons market, bad drives out good. • Consumers cannot pre-purchase tell the difference between a good product and a lemon; so • the price drops (the expected value of the purchase is reduced by the expected value of getting a lemon); and • good products disappear from the market. • Bruce Schneier claims this happens in the computer security market. • You may not be aware failures in your security.

22. What Costs Do Vulnerabilities Impose? • There are no reliable estimates of the total loss, although there is a lot of guess work. • The guess work puts the losses in the several billions. • Some statistics follow from the 2005 FBI Computer Crime Report • Complied by surveying businesses with a yearly revenue of $1,000,000 or over. • Losses discussed are losses to the business, not to third parties.

23. Business’s Losses Per Intrusion (2005 FBI Computer Crime Report)

24. Losses In Order of Magnitude (2005 FBI Computer Crime Report) • Viruses, worms, Trojans • Spyware • Port scans • Sabotage of data • Laptop/PDA theft • Insider abuse • Denial of service attack • Network intrusion • Financial fraud

25. Assumption • The current level of software vulnerabilities is inefficient. • Inefficient in the sense that, if software manufacturers invested more in preventing vulnerabilities than they currently do, we—all of us affected by software vulnerabilities—would save more than the total they spent. • Software would cost more and be less usable, but those costs would be more than offset by the savings.

26. Possible Solutions • Legal • FDA-like Approval • Negligence • Products liability • Certification of manufacturers • Licensing of software engineers • Market • Open source software • Market for software vulnerability disclosure • Prediction markets

27. A Point To Remember • Innovation is critical. • It drives economic development. • It drives it most effectively when considerable flexibility is allowed in business models, research, and design. • A question to bear in mind: Which of the approaches to software vulnerabilities allows the most flexibility?

28. An FDA-Like System? • Software is similar to prescription drugs in that both are essential and both have unavoidable “side effects.” • We regulate drugs through a complex system of FDA approvals, licensing requirements, and legal liability. • FDA-like approval will not work for software. The approval process is very slow, and we need to develop software much more quickly than it would allow.

29. An Initial Hurdle to Tort Liability • The economic loss rule: without a physical impact, there is no tort recovery for purely economic loss. • Rationale: to limit losses to a bearable amount.

30. Extent of physical impact Tort Economic impact

31. Drop the Economic Loss Rule? • To apply tort liability to software, we would have to drop the economic loss rule in those cases. • Would the resulting liability be excessive?

32. Negligence • Standard of reasonableness • Industry norms reasonable unclear unreasonable • Efficiency

33. Negligence • Unclarity in the standard could • fail to deal adequately with market pressures. • inhibit innovation. • be too lenient in regard to legacy systems. • inhibit price discrimination in selling tech support. • Causation problems • “It wasn’t my software; it was your implementation.”

34. Products Liability • The manufacturer is liable for the foreseeable damage caused by a defect in a product. • No requirement of negligence. • A defect is a tendency to cause physical harm beyond that • contemplated by an ordinary user • whose knowledge of the product’s characteristics consists of what is • commonly known by foreseeable users of the product.

35. Problems • Small losses for any one plaintiff. • Slowness of the process to bring about change. • Difficulties in defining what counts as defective. • Unclarity could • fail to deal adequately with market pressures. • inhibit innovation. • be too lenient in regard to legacy systems. • inhibit price discrimination in selling tech support. • Causation problems • “It wasn’t my software; it was your implementation.”

36. Certification As A Solution • The National Security Telecommunications Advisory Committee, Internet Security/Architecture Task Force Report calls for certification. • Create by statute an organization that • promulgates manufacturing standards and certifies that manufacturers follow them, where • violators are fined (liability for actual or foreseeable damage would be excessive).

37. Is Certification Feasible? • Problem: The software industry changes so fast that substantive standards are difficult to formulate. • Solution: Require security testing and documentation of security features and risks. • Problem: What counts as adequate security testing and documentation? • Overall: certification lacks a convincing record of success.

38. Licensing Requirements • We license many professionals. • Why not network administrators? And, perhaps, programmers? • Licensing requirements impose professional duties that constrain the exercise of professional judgment.

39. Assessment of Negligence and Products Liability • Negligence and products liability may work in “egregious” cases: • Lack of reasonableness, or existence of defect clear • AOL 5.0 and Sony. • Causation clear. • Monetary loss to others is foreseeable, and a reasonable person, who was aware of the risk, would take steps to avoid imposing that loss on others. • Creates an exception to the economic loss rule. • Generally, however, these approaches will be ineffective.

40. Assessment of Certification and Licensing • Evidence form other areas suggests that these approaches have limited value. • Ross Anderson on the Common Criteria. • We may want to pursue these options, but we cannot rely on them as a complete solution.

41. Market Solutions • A market solution relies primarily on monetary, non-legal incentives to achieve a desired result. • There are three market solutions.

42. Open Source Software • Software is “open source” if its source code is publicly available. • Open source software may be the product of many programmers, scattered all over the world, who contribute to the source code. • Open source software has advantages. • Fewer defects • No proprietary problems. • Legal issues: • Liability for intellectual property violations • Sco Group v. IBM

43. Open Source Economics • Open source software works best when it is • Based on non-proprietary techniques • Sensitive to failure • Verification requires peer review • Sufficiently important (business critical) that people will cooperate to find bugs • Subject to network effects • Eric Raymond, The Magic Cauldron • Security has all the above features (Anderson). • Many software vendors pursue an anti-interoperability strategy incompatible with open source software.

44. Vulnerability Disclosure Markets • A vulnerability disclosure market provides a mechanism for those who discover vulnerabilities to communicate them to software manufacturers/vendors. • There four possibilities.

45. Market Based • A business—like iDefense—pays for information about the existence of vulnerabilities and communicates this information to its clients. • Markets are generally very successful in aggregating dispersed information. • They are accurate and efficient. • Unless precautions are taken, clients could be hackers. This is true also in all following cases.

46. iDefense Vulnerability Challenge • This challenge sets the bar quite high, focusing on core Internet technologies likely to be in use in corporate enterprises. Because of this, we are merging Q2 and Q3 challenges into one, effectively extending the research time. The following technologies are the focus of this challenge: • Apache httpd • Berkeley Internet Name Domain (BIND) daemon • Sendmail SMTP daemon • OpenSSH sshd • Microsoft Internet Information (IIS) Server • Microsoft Exchange Server • iDefense will pay $16,000 for each submitted vulnerability that demonstrates the execution of arbitrary code.

47. CERT-type Organizations • No money is paid to those who discover vulnerabilities. • No money is charged for the disclosure of the vulnerability. • One would expect this not to perform as well as a market mechanism. • Kannan, Telang, and Xu, Economic Analysis of the Market for Software Vulnerability Disclosure, contend CERT-type organizations sometimes outperform market mechanisms, but they assume that relevant information is costless available. This ignores precisely that at which markets excel. • Available on SSRN.

48. Consortium Mechanism • Those concerned to gain information about vulnerabilities form a consortium. • The consortium pays for information about vulnerabilities. • Members may share information for free. • Examples • Information Sharing Analysis Centers (ISACs) • Governmental. • Does not yet deal with vulnerabilities in the above way. • Industry consortiums. • Similar to CERT-type organizations with the added complexity of conflicting business motives.

49. Federally Funded Centers • This does not exist. • The center would pay for the discovery of vulnerabilities, but • Would not charge for the disclosure of the information. • Kannan, Telang, and Xu, Economic Analysis of the Market for Software Vulnerability Disclosure, contend this type of approach performs best, but again they assume that relevant information is costless available.

50. Lemon Markets and Their Solution • Nothing we have said so far addresses the lemon markets problem. • The basic lemon markets’ mechanism: • Consumers cannot pre-purchase tell the difference between a good product and a lemon; so • the price drops (the expected value of the purchase is reduced by the expected value of getting a lemon); and • good products disappear from the market. • Solution: Get information to buyers before they purchase.