Liability for Software Vulnerabilities

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

2. Vulnerability Defined • A vulnerability is a feature one can exploit to gain unauthorized access. • Claims: • The law’s ability to decrease vulnerabilities in software is limited. • We have to rely on market solutions.

3. 1. Inherently Complex (Daedal) • It is impossible to write complex software without creating vulnerabilities. • But there can be different rates of error. • Errors reduced by good engineering procedures and practices. • There is a line between reasonably programmed and unreasonably programmed software. • But a blurry line.

4. 2. System Designers Make Mistakes • As in any profession, programmers differ in skill. • A grandmaster chess player may easily find a vulnerability in a defense that a master overlooks. • Relatively unskilled programmers still get jobs.

5. 3. The Error Correction Problem • Bridge building: an engineer discovers that the value of an important variable is not correct. • Typically, the correction will typically not make the approximation to correctness worse. • Software: Error correction is discrete: A “0” replaces a “1” or vice versa. • Error correction may make matters worse.

6. 4. Network Complexity • 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.

8. Possible Legal Responses • (1) Products liability • (2) Negligence • (3) Certification or licensing regime • (1) and (2) treat with considerable deference cases in which socially useful activities create unavoidable harm.

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

10. Problems • Difficulties in defining what counts as defective. • Where as practical matter impossible to create a non-defective produce, the law is reluctant to impose products liability. • Small losses for any one plaintiff. • Slowness of the process to bring about change. • Causation problems • “It wasn’t my software; it was your implementation.”

11. Negligence • Standard of reasonableness • Industry norms reasonable unclear unreasonable

12. An Initial Hurdle to Tort Liability • The economic loss rule: without a physical impact, there is no tort recovery for purely economic loss. • Rationales: • to limit losses to a bearable amount. • to allocate responsibility for the loss in an efficient manner.

13. Extent of physical impact Tort Economic impact

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

15. Would Negligence Liability Really Help? The Hacker Wins the Race • 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. • See the SANS http://www.sans.org/top25-programming-errors/.

16. Applications: Legacy Systems • Old systems can be difficult or expensive to update. • Many systems run outdated, insecure software. • As Ross Anderson notes. • What counts as negligence where the industry standard is to run outdated, “insecure” programs? • Scare quotes because “insecure” here is a normative conclusion: not as secure as it should be.

17. Patching • When is it negligent not to patch? • Home machines versus business networks. • The patching decision in a complex network can be a very difficult technological and business call. • Verizon case. • But this is an extreme.

18. What Counts as Negligence When Documentation is Inadequate? • 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.

19. Unclarity Problems • 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.”

20. Contractual Protections for Vendors • Even if we instituted a negligence regime of some robustness, vendors contractual disclaim liability. • A typical example follows.

21. In re America Online Inc. Version 5.0 Software Litigation • In In re America Online Inc. Version 5.0 Software Litigation, 168 F.Supp.2d 1359, America Online (AOL) distributed software that cut off non-AOL Internet access, disrupted local area networks, and interfered with other applications and thereby causing computers to crash. AOL distributed the software accompanied by a clickwrap Terms of Service (TOS) agreement. The court noted that the

22. The Disclaimer • The court noted that the TOS Agreement stated: • “[M]ember expressly agrees that the use of AOL, AOL software, and the Internet is at member's sole risk." . . . With respect to disputes relating to the software, the TOS Agreement provides, "AOL's entire liability and your exclusive remedy ... shall be the replacement of any AOL software found to be defective." . . .”

23. The Disclaimer • “If the consumers have any other dispute, "[Y]our sole and exclusive remedy ... is the cancellation of your account." . . . The TOS Agreement also purports to limit AOL's liability for consequential damages. . . . According to AOL, . . . these provisions prevent the consumers from seeking punitive damages, compensatory damages, disgorgement, injunctive relief, and attorneys' fees.” • 168 F.Supp.2d 1359, 1361 (S.D. Florida 2001).

24. The Law’s Attitude • The law generally enforces such disclaimers in the defective product context, where the vendor is unaware, and should not have been aware, of the defect. • The risk of loss from the defect shifts to the buyer.

25. In Favor of the Shift • Assume (for now) that the vendor has a sufficient market incentive to make a reasonable effort to produce a non-defective product. • What happens if we do not allow the vendor to shift the risk of loss onto the buyer? • The cost of the product rises. • Defects are inevitable, and the seller will be liable. • So the seller takes the expected legal loss into account in setting the price. • Low-risk buyers subsidize high-risk buyers.

26. In Favor of the Shift • What happens if we allow the vendor to shift the risk? • The cost does not rise. • Buyers who wish to insure against the risk of loss. • Low-risk buyers do not subsidize high-risk buyers. • But this analysis assumes sufficient market pressure to make a reasonable effort to produce non-defective software. Is this true?

27. 4. Market Pressures • Network effects • It is critical to be first to market where network effects are strong, as in software. • Insufficient testing and debugging. • Changes in specifications after project begun • Buyers insistence on usability. • Buyers insist on usability. • Security often reduces usability, but • Buyers undervalue security. • It is difficult for buyers to evaluate security features.

28. 5. 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. • 1999 Mars mission • Use of old code • Ariane 5

29. Security software: Lemons market? • In a lemons market, bad may drive out good. The idea: • 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.

30. Security software: Lemons market? • Bruce Schneier claims this happens in the computer security market. • You may not be aware failures in your security. • Buyers cannot tell good from bad products.

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

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

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

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

35. Market Solutions: Many Minds and Money Where Your Mouth Is • A market solution relies primarily on monetary, non-legal incentives to achieve a desired result. • There are three market solutions.

36. First Market Solution: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

37. Open Source Economics • Open source software works best when it is • Based on non-proprietary techniques • No “blends” of open source and proprietary code. • Subject to network effects • The application is sensitive to failure • Verification requires peer review • Sufficiently important (business critical) that people will cooperate to find bugs • 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. • Prohibitions on reverse engineering in End User License Agreements.

38. Second Market Solution: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.

39. First Possibility: 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.

40. iDefense

41. Second Possibility:CERT-type Organizations • 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 costlessly available. This ignores precisely that at which markets excel. • Available on SSRN.

42. Third Possibility:Consortium Mechanism • Those concerned to gain information about vulnerabilities form a consortium. • Members may share information for free. • Examples • Information Sharing Analysis Centers (ISACs) • Annual fees in the $10,000’s. • Similar to CERT-type organizations with the added complexity of conflicting business motives.

43. Fourth Possibility: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 costlessly available.

44. Third Market Solution: Prediction Markets • A prediction market would accomplish the purpose. • In the market, investors buy futures in which the speculate on which products will have this or that type of vulnerability. • Such markets have proven remarkably accurate in predicting a wide variety of events. • The prediction markets might work well where there are active disclosure markets which reveal the existence of vulnerabilities.

45. An Example • Why not set up a prediction market in which investors by futures on when vulnerabilities will be discovered. • Investors could speculate on the time, number, and rank order in the list. • The activity in the market could guide purchase decisions prior to discovery of the vulnerability.