Advanced Search
MyIDEAS: Login to save this article or follow this journal

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

Contents:

Author Info

  • Terrence August

    ()
    (Rady School of Management, University of California, San Diego, La Jolla, California 92093)

  • Tunay I. Tunca

    ()
    (Graduate School of Business, Stanford University, Stanford, California 94305)

Registered author(s):

    Abstract

    In recent years, vendor liability for software security vulnerabilities has been the center of an important debate in the software community and a topic gaining government attention in legislative committees and hearings. The importance of this question surrounding vendor security liability is amplified when one considers the increasing emergence of zero-day attacks where hackers take advantage of vulnerabilities before the software vendor has a chance to release protective patches. In this paper, we compare the effectiveness of three software liability policies: vendor liability for damages, vendor liability for patching costs, and government imposed security standards. We find that vendor liability for losses is not effective in improving social welfare in the short run, while liability for patching costs can be effective if either patching costs are large and the likelihood of a zero-day attack is low, or patching costs are small and zero-day likelihood is high. In the long run, when the vendor can invest in reducing the likelihood of security vulnerabilities, loss liability is still ineffective when the zero-day attack probability is high but can increase both vendor investment in security and social welfare when zero-day attack likelihood is sufficiently low. When the zero-day attack probability is high, patch liability is ineffective if user patching costs are large, but partial patch liability can boost vendor investment and improve welfare when patching costs are small. In contrast, in an environment with low zero-day attack probability, full vendor patch liability can be optimal. Finally, comparing the effectiveness of the three liability policies under study, we find that government imposed standards on software security investment can be preferable to both patching and loss liability on the vendor, if zero-day attack likelihood is sufficiently low. However, if zero-day attacks are a common occurrence and patching costs are not too high, partial patch liability is the most effective policy. This paper was accepted by Sandra Slaughter, information systems.

    Download Info

    If you experience problems downloading a file, check if you have the proper application to view it first. In case of further problems read the IDEAS help page. Note that these files are not on the IDEAS site. Please be patient as the files may be large.
    File URL: http://dx.doi.org/10.1287/mnsc.1100.1304
    Download Restriction: no

    Bibliographic Info

    Article provided by INFORMS in its journal Management Science.

    Volume (Year): 57 (2011)
    Issue (Month): 5 (May)
    Pages: 934-959

    as in new window
    Handle: RePEc:inm:ormnsc:v:57:y:2011:i:5:p:934-959

    Contact details of provider:
    Postal: 7240 Parkway Drive, Suite 300, Hanover, MD 21076 USA
    Phone: +1-443-757-3500
    Fax: 443-757-3515
    Email:
    Web page: http://www.informs.org/
    More information through EDIRC

    Related research

    Keywords: IT policy and management; economics of IS; network economics; enabling technologies; software; liability; zero-day;

    References

    No references listed on IDEAS
    You can help add them by filling out this form.

    Citations

    Lists

    This item is not listed on Wikipedia, on a reading list or among the top items on IDEAS.

    Statistics

    Access and download statistics

    Corrections

    When requesting a correction, please mention this item's handle: RePEc:inm:ormnsc:v:57:y:2011:i:5:p:934-959. See general information about how to correct material in RePEc.

    For technical questions regarding this item, or to correct its authors, title, abstract, bibliographic or download information, contact: (Mirko Janc).

    If you have authored this item and are not yet registered with RePEc, we encourage you to do it here. This allows to link your profile to this item. It also allows you to accept potential citations to this item that we are uncertain about.

    If references are entirely missing, you can add them using this form.

    If the full references list an item that is present in RePEc, but the system did not link to it, you can help with this form.

    If you know of missing items citing this one, you can help us creating those links by adding the relevant references in the same way as above, for each refering item. If you are a registered author of this item, you may also want to check the "citations" tab in your profile, as there may be some citations waiting for confirmation.

    Please note that corrections may take a couple of weeks to filter through the various RePEc services.