Addressing Software Security, Economic, and Liability Issues

Slide Note
Embed
Share

In the realm of software security, economic considerations often lead to negligence in addressing vulnerabilities, resulting in billions of dollars wasted annually due to exploits by hackers. The focus is on the prevalence of vulnerabilities, limited sources of security issues, and the need for a shift in both developers' and buyers' behavior towards prioritizing secure software development and procurement.


Uploaded on Sep 20, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. Software Security: Economics, and liability issues Richard Warner

  2. Two Questions You would not waste billions of dollars a year if you could avoid it. So why do we do precisely that with software defects that are exploited by hackers? And, what should we do about it?

  3. Preliminary: Vulnerability Defined A software vulnerability is a property of the software a hacker can exploit to gain unauthorized access to a computer or network. Currently, software (some software) is riddled with vulnerabilities.

  4. Most Vulnerabilities limited set of sources Security issues arise heavily from small group of programs Windows Flash players Adobe PDF readers/writers Web Browsers (4?), Microsoft Office, Email Clients (3?), Media players (5?), Backup Security: Anti-virus and firewall Server-side stuff (including all server OS!)

  5. Software can be less vulnerable Lists published each year of top vulnerabilities in non-web software (SANS list) and web-app (Open Web Application Security project OWASP). Buffer overflow still in top 3 on SANS list; SQL injection still in top 3 in OWASP list Both: Attack is well known; defense straightforward; attack can be devastating. Neither likely to be found negligent!

  6. The Standard Answer Businesses are profit-making ventures, so they make decisions based on both short- and long-term profitability. Bruce Schneier, Information Security and Externalities Buyers demand low-priced, early-to-market software even when it is vulnerability-ridden. Note: low-priced is not low-cost. The cost runs in the billions. Reducing vulnerabilities requires a longer and more costly development process and may yield software less easy to use.

  7. Two Ways To Respond Change software developers behavior So they develop and offer for sale only secure software. Change software buyers behavior So they demand and buy only secure software The first option is the usual choice, and negligence liability is the usual proposal.

  8. The Problem With Negligence A software developer is liable in negligence for losses resulting from a vulnerability only if the vulnerability was a foreseeable result of the developer s failure to act as a reasonable developer would. The problem: this will not reduce vulnerabilities enough. Reasonable Unclear Unreasonable We need to reduce vulnerabilities in this area

  9. A Disanalogy: The T. J. Hooper A tug, the T. J. Hooper, encountered a storm and sank along with the barges it was towing. It did not have a shortwave radio. With one, it would have received weather reports, and stopped to avoid the storm. Shortwave radios were new, and tugs did not normally have one. The court held that the tug was negligently because it lacked shortwave radios.

  10. Two Key Points The cost of shortwave radios was relatively small. An adequate receiving set . . can now be got at small cost . . . obviously it is a source of great protection to their tows. The cost did not put a barge owner at a competitive disadvantage. Barge owners could easily compare the cost of the radio and the losses avoided by its use. Storms are difficult to predict, but their occurrence from time to time is certain and the losses can be very large.

  11. Software is Different The cost of developing secure software is high enough to put the developer at a competitive disadvantage against those who sell insecure software. Special cases aside, software developers cannot get the information they need to make precise enough estimates of the damage to third-parties. The information is typically distributed over millions of people. If interested in this problem, follow the development of liability insurance for data breaches.

  12. Negligence Liability Is A Bad Idea It is a bad idea to impose a standard for legal liability for the purpose of increasing investment when those who are to make the investment cannot figure out how much they need to spend to avoid liability, so People will spend too much or too little now, too little because big investments will put them at a competitive disadvantage So: we can we change software buyers behavior to make them demand and buy only secure software?

  13. Other Liability Options Strict liability (products liability, but it has negligence elements in it). Liability for defective design (has the same problem as negligence there must be a hypothetically economically feasible alternative). Statutes built around negligence, strict liability, defective design ideas.

  14. Strict Liability Strict liability: Liability for losses you cause even if the loss is not your fault. Software differs in an important way from classic examples of strict liability. Animals and explosives: the more precautions one takes, the more the risk of harm decreases. (Can approach zero) But Software: some vulnerabilities are inevitable.

  15. Too Much Liability Suppose no matter how hard you tried, the animals still escaped once a month, or once a month bystanders were harmed by your explosions. How many people would keep animals or blast with explosives if they faced once-a- month liability? We should not put such a roadblock in the way of innovation and distribution.

  16. Coordination Norms A social norm is a behavioral regularity in a group where the regularity exists at least in part because almost everyone believes he or she should conform to the regularity. A coordination norm is a behavioral regularity in a group where the regularity exists at least in part because almost everyone believes he or she should conform to the regularity as long as (almost) everyone else does. Driving on the right is a classic example.

  17. The Elevator Norm You enter a crowed elevator. Where do you stand? You maximize the distance from your nearest neighbor (while maintaining peripheral eye contact with at least one other person). Three person distribution

  18. The Consumers Problem A mass-market seller s only respond to demands from enough consumers. So a single buyer, or a small group of buyers, cannot unilaterally ensure that sellers will offer what they want. Enough consumers have to coordinate to demand the same thing to get it. How do they do that?

  19. Markets and Coordination Norms Coordination norms unify buyers demands. Norms of the form, Buyers demand products of type X. Profit-motive driven sellers respond to the collective demand (in sufficiently competitive markets).

  20. A Suboptimal Norm The Pre-1979 NHL No Helmet Norm: Not wearing a helmet was a behavioral regularity that existed in part because each player thought he ought to conform, as long as all the others did. Two advantages to not wearing helmet: Appear weak/soft if you re one of few wearing helmets (major) Slightly better peripheral vision without helmet (minor) One disadvantage to no helmet: Very large risk of significant head injuries.

  21. The Players did not wear helmets All the players regarded the alternative in which they all wore helmets as better justified. Because of the value they placed on avoiding head injury The players remained trapped in the no helmet norm until the league mandated the wearing of helmets in 1979.

  22. Coordination Game Connection Row Player 1 s payoff in blue; Column Player 2 s payoff in red Players choose at the same time without knowing what the other will choose. Wear a helmet Do not wear a helmet 8, 8 0, 6 Wear a helmet Do not wear a helmet 6, 0 5, 5 Trapped here

  23. Value-Optimal Norms A normisvalue-optimalwhen, in light of the values of all (or almost all) members of the group in which the norm obtains, the norm is at least as well justified as any alternative. It is the at least as well justified as any alternative that make the norm optimal; it means one cannot improve by choosing a better justified norm.

  24. Recall: Norms and Market Transactions A mass-market buyer cannot unilaterally ensure that sellers will conform to his or her requirements. Coordination norms unify mass-market buyers demands. Norms of the form, Buyers demand products of type X. Profit-motive driven sellers respond to the collective demand (in sufficiently competitive markets).

  25. Product-Risk Norms Product-risk norms are social norms that govern the sale of products. When functioning optimally, they ensure that the design and manufacture of products impose only acceptable risks on buyers. But they can function sub-optimally.

  26. Ordinary Products And Norms When my water heater breaks, I shop for new one on price, capacity, and maybe how fast it will get installed and/or energy consumption. I get a contract, but do not read it. I may have no idea if my warranty is 6 years or 9 years. The system works well. Why? Product risk norms ensure acceptable terms and make consent informed. They also ensure consent is free.

  27. Vulnerable Software = Bare Heads Consumers are playing coordination game to unify their demands for software. Currently locked in everybody demands (low- priced, fast to market) vulnerable software norm Playing software without a helmet

  28. Do We Need Legal Regulation? Won t the market will eventually take care of things on its own? There is increasing public concern about unauthorized online access and increasing awareness that vulnerable software is one key cause. Once buyers realize that collectively they will be better off with more secure software, they will demand it, and profit-motive driven developers will meet that demand.

  29. Legal Regulation is Necessary The final step in the argument is wrong. Even if buyers realize that they will be better off with more secure software, they are unlikely to demand it. Buyers are trapped in a norm (or if you prefer, Nash equilibrium of a game) that ensures that they will continue to demand insecure software. Legal regulation is needed as a remedy.

  30. The Suboptimal Software Norm The norm is that buyers demand low-priced, early-to-market software. What the costs show: There is a better justified alternative that shifts a good part of the risk of loss from vulnerabilities on to software developers. So the low-priced norm is not value-optimal.

  31. Our Proposed New Legal Regulation Statute that identifies best practices and requires software developers follow them. Or demonstrate the reasonableness of their alternative practices. Goal: Constrain developers significantly less than strict liability, more than current custom. To avoid excessively inhibiting innovation, statute must be implemented in a way that allows developers reasonable flexibility in their choice of development methodologies.

  32. Best practices: What are they? Best practices has become an overused, underdeveloped catchphrase employed by industries and professions to signal an often unsubstantiated superiority in a given field. I. P Robbins, Best Practices on Best Practices : Legal Education and Beyond, Clinical Law Review 16 (2009): 271.

  33. Best practices: our definition There is widespread agreement that: 1. it is desirable that the goals (here reducing software vulnerabilities) be achieved. 2. tradeoffs implemented by following the practices are at least as well justified as any alternative. 3. practices are a sufficiently reliable, sufficiently detailed means of meeting goals.

  34. Who defines? An agency. Probably of federal government, though could be delegated to private agency such as ANSI or IEEE or ACM. Regulatory captureis a possible problem. (Typically worse with private organizations.)

  35. Law as mover to new norm Goal is brief period of legal enforcement, which makes new norm of demanding best practices software the norm, and then legal enforcement fades into background.

  36. Other applications of norms ideas Many private companies information processing practices today in US another suboptimal coordination norm/game equilibrium, with unified consumer demand (information aggregators, credit cards, direct marketers, etc.) Also: Malware defense (beyond reducing vulnerabilities) left heavily to home users as opposed to forcing some on ISPs.

  37. Hope for developing norms? (and even laws?) Of course you are right about Privacy and Public Opinion. All law is a dead letter without public opinion behind it. But law and public opinion interact and they are both capable of being made. Louis Brandeis (letter), 1890

Related