Who Should be Responsible for Software Security? A Comparative Analysis of Liability Policies in Network Environments

Terrence August and Tunay Tunca

Management Science, May, 2011, 57(5), 934-959

Research Questions

If Microsoft were held liable for a portion of the economic losses associated with security vulnerabilities in its software, would the software products become more secure? Would society be better off? Many liability advocates believe that software vendors are selling products with excessive security vulnerabilities and need to be held accountable in order to control high social costs that are caused by these vulnerabilities. On the other hand, there is also support against vendor liability as some experts feel that such impositions would unduly punish vendors when hackers are the true culprits and potentially stifle innovation. In the current network environment, there are serious incentive problems among various actors whose decisions impact the overall security of the cyber infrastructure; the risks associated with attacks on this infrastructure are growing in number and potential impact; and the importance of the role of regulation is increasingly understood and debated. However, answering how regulation can actuate a shift toward preferable outcomes, such as an increasingly secure cyber infrastructure and higher social surplus associated with these public resources, is not well understood and requires formal analysis. In this paper, our purpose is to begin exploring this important question by analyzing a model that captures both security interdependence and the primary underlying incentives of actors.

We investigate how liability policies can be used to increase Internet security considering the effects of interconnectivity and the resulting interdependence of users' security actions on one another. We begin by studying the economics of the network environment in a short-run setting, where the security level of the software is taken as given. In the long run, the role of liability on increasing Internet security also impacts the incentives of software providers to adjust the security quality of their products at the design and development stage. Therefore, we subsequently study a long-run setting where vendors can invest in security quality in response to policy. We analyze and contrast three classes of security liability policies, namely (i) Loss Liability Policies, where the software vendor is liable to partially or fully compensate users' losses incurred in case of a zero-day attack; (ii) Patch Liability Policies, where the software vendor is held liable to compensate patching costs incurred by users if a vulnerability is discovered before it is exploited; and (iii) Security Standards Policies, where regulation enforces a certain standard of security to be achieved by the vendor during software development to mitigate security vulnerabilities. The former two policies can be applicable in both short-run and long-run settings, while the last one is only applicable in the long run. We explore the role of zero-day attacks by studying and comparing these policies in two security environments, with low and high zero-day attack likelihood respectively. For each class of policies and each zero-day environment, we characterize the optimal policy and study its effectiveness. We then compare and contrast their effectiveness and generate policy recommendations based on our analysis. Our goal is to answer the question whether vendor security liability can be an effective method to improve security and the net social value generated by software, and, if so, how.

Findings

In the paper, we focus on a region where the security loss factor is sufficiently high that some users are patching their software installations when vulnerabilities arise; this setting is the most realistic one, as evidenced by actual users’ patching behavior in the face of ongoing security attacks. Under a reasonably high security loss factor, we can then divide our results into a 2 x 2 matrix of low / high patching costs and low / high zero-day risk. For the first categorization, client-side software applications tend to have relatively lower patching costs than enterprise software applications since the latter typically require significantly more effort. For the second categorization, we leveraged publicly available vulnerability and attack information for various classes of software as well as specific packages to determine what types of software are exposed to higher absolute zero-day risk. Using these available data and statistics, we have composed a list in Table 1 of the typical software packages that would fall into each of the four relevant categories presented in our policy summary (IBM 2008, Hewlett-Packard 2010).



Table 1: Examples of software products for various security landscapes

In Table 2, we summarize the policy recommendations stemming from our model for each of these different classes of software. As can be seen in the table, an important takeaway from our analysis is that social planners should steer away from the use of loss liability on software with interdependent risks. We find that whether or not software vendors have the opportunity to invest in security in response to loss liability makes little difference in the net impact of such a policy: welfare mostly decreases. On the surface, one may think that holding the vendor liable for a portion of consumers’ losses would provide increased incentives for the vendor to improve security, and, in some cases, the vendor’s optimal investment indeed rises. However, even if investments positively respond, the vendor tends to restrict usage through pricing to limit its exposure to liability on these losses. Hence, loss liability is an inefficient policy to apply in the software industry. On the other hand, we find that both patch liability and security standards should play an important role in software policy although, in certain cases, no liability is necessary.


 


Table 2: Recommended policy for various security landscapes and investment scenarios

Panel (a) of Table 2 presents our policy recommendations for short-run settings where investments are fixed. First, we consider software products that exhibit low patching costs and high zero-day risk (see Table 1). According to IBM X-Force, in recent years, the client software applications facing the highest zero-day risk include web browsers, dynamic web content enabling engines, and document readers (IBM 2008). Typical examples include products such as Microsoft Internet Explorer and Office. In this setting, we find that the application of patch liability would be beneficial to welfare. That is, software vendors should be held liable for a portion of the users’ patching costs in order to increase software security and, consequently, welfare. On the other hand, when both patching costs and zero-day risk are low, we find that liability is unnecessary since users and software vendors are already making fairly efficient decisions from the welfare point of view. Examples of client-side software with low zero-day risk include text editors, anti-virus tools, some media players, and lower profile operating system software. Listed in Table 1, we provide some examples of these software packages, including WinEdt, Symantec Anti-Virus, and Apple OSX.

Similarly, when both patching costs are high, as it is with enterprise software, and zero-day risk is substantial, then there is again no need for liability in a short-run setting. Data suggest that the more risky enterprise software packages are geared for the web, including web server software and some database management systems. Notable examples of software in this category include Microsoft IIS, SQL Server, and Oracle Secure Backup (Hewlett-Packard 2010). Finally, when enterprise software faces low zero-day security risk, patch liability on software vendors is once again optimal. Products with less zero-day risk include many enterprise application software packages including IBM Lotus Notes, Oracle E-Business Suite, and Novell Groupwise. As is summarized in panel (a) of Table 2, in some cases, no additional software security responsibility should be imposed on the software vendor, and the users should be held responsible for their own security patching costs. However, in other cases, the vendor certainly needs to become more responsible, and this responsibility should take the form of patch liability.

Since patching costs exist and furthermore they are sufficiently large that a non-trivial portion of software users do not patch and incur losses when security attacks occur, it is important to understand the impact of policies that can help induce users to perform proper patch maintenance. The policy we study is for the vendor to assume a share of these costs. By holding the vendor responsible for part of the patching costs, a larger consumer population can be induced to patch, and the risk level of the network can decrease, particularly in the face of high zero-day risk. There are many ways to implement the essence of such a policy. One way to implement it is to simply have software vendors offer customers who agree to adhere to an appropriate patching strategy with a price discount. In the context of our model, this mechanism is equivalent to having the vendor be liable for a portion of the patching costs. Further, patching behavior is verifiable since, in an interconnected environment with risk, the vendor can use the interconnectedness for communicating patching status (see, e.g., August and Tunca 2006 for more on this point). Also, schemes such as rebates or other means that reduce well-behaved users’ costs can all work to some extent. The primary challenge of implementing patch liability are privacy concerns. There may be a portion of the consumer base that prefers not to permit the software vendor with a means of verifying patching status since it requires the passing of information out of firewall protected servers. Implementation of this type of change to the security policies of a user firm may be against its current practices, and, therefore, encounter organizational resistance. However, the net impact of patch liability on welfare is substantial which can help drive change.

Turning attention to long-run settings where the vendor can adapt its investment in security, under high zero-day risk and low patching costs, we find that patch liability continues to be the most effective policy to improve welfare. Our results for this setting are summarized in panel (b) of Table 2. However, under low zero-day risk / low patching cost and high zero-day risk / high patching cost, social welfare can now benefit from the application of liability on the software vendor. For these two corners of the table, in contrast to the recommended absence of liability in the short run, we find that it is best to directly target the software vendor’s investment through the use of software security standards. In the case of low zero-day risk and high patching costs, the recommended policy shifts from patch liability to security standards as well. The main implication here is that under the sets of conditions that span these three categories, there are insufficient incentives for software vendors to produce software that is sufficiently secure. Since this software runs in networked environments and its users generate negative externalities on one another, government may need to ensure that producers are developing software that meets some predetermined minimum standards. Thus, in such cases, the entity who most needs to be responsible for software security is the software vendor, and the policy recommendation is direct regulation of security investment through standards.

Implementation of standards is a common function of the government. For example, the U.S. Department of Labor’s Occupational Safety and Health Administration (OSHA) agency enforces regulations to maintain workplace safety and health, and the U.S. Department of Transportation’s National Highway Traffic Safety Administration (NHTSA) agency writes and enforces standards for motor vehicles (Bennett 2010, Berzon 2010). For the case of software causing security risk across networks, an agency such as the Department of Homeland Security (DHS) would need to work with security experts to generate guidelines for software producers to adhere to in developing software. The primary challenge of implementation is that checking compliance and enforcing the standards can be quite costly and will require the support of both government and taxpayers. However, as software continues to become increasingly pervasive in all industries and drive critical functions (e.g., software now controls automobiles, planes, and even the smart grid), peoples’ lives are becoming more at risk. Similar to OSHA and NHTSA, the enforcement of software security standards is likely to become a necessity in the near future.

Our findings have significant implications on software policy design, software litigation, and software producers’ development strategies. In terms of software policy, Tables 1 and 2 provide specific guidance to policy makers, highlighting how policy should be applied differently to existing software products and future releases. Our results suggest that it may be socially more efficient for courts to continue to not hold software vendors liable for the economic losses associated with their products. Instead, efforts should be taken to determine the best way to develop security standards that the producers of software should adhere to going forward. Finally, it would be in the major software producers best interest to immediately begin taking a more rigorous approach toward assuring that their software meets stringent security standards rather than continuing with the release and patch approach that characterizes the status quo. Doing so proactively may help to reduce the need for regulation, which unfortunately comes with additional compliance costs that can be avoided.


 


Figure 1: Policy comparison of security investment and welfare.

References

   August, T. and T. I. Tunca (2006). Network software security and user incentives. Management Science 52(11), 1703–1720.

   Bennett, J. (2010, Apr). NHTSA to test Lexus SUV for rollover. The Wall Street Journal.

   Berzon, A. (2010, Mar). OSHA boosts oversight of state safety agencies. The Wall Street Journal.

   Hewlett-Packard (2010). HP TippingPoint zero day initiative.

   IBM (2008). IBM internet security systems X-Force 2008 mid-year trend statistics. IBM Global Technology Services.

Invited Talks and Conferences

  • Foster School of Business, University of Washington, Seattle, June 1, 2012
  • NYU Stern School of Business, April 26, 2012
  • INFORMS Annual Meeting 2011, Charlotte, NC, November 16, 2011
  • Graduate School of Business, Stanford University, October 19, 2011
  • Naveen Jindal School of Management, University of Texas at Dallas, October 14, 2011
  • Workshop on Economics of Information Security 2011 (WEIS), George Mason University, Fairfax, VA, June 15, 2011
  • Paul Merage School of Business, University of California, Irvine, April 14, 2011
  • Krannert School of Management, Purdue University, April 8, 2011
  • Faculty Brown Bag Seminar, Rady School of Management, University of California, San Diego, November 29, 2010

Posters

  • NSF Secure and Trustworthy Cyberspace Inaugural Principal Investigator Meeting, National Harbor, MD, November 27-29, 2012. Poster
  • Science of Security Community Meeting, National Harbor, MD, November 29-30, 2012. Poster

Paper

Proofs

Presentation Slides