1 / 22

Security Market: Incentives for Disclosure of Vulnerabilities

Security Market: Incentives for Disclosure of Vulnerabilities. Peter P. Swire Ohio State University Houston/Sante Fe Conference June 4, 2005. Overview. The prior paper: when it is efficient to disclose security information

robin-sweet
Download Presentation

Security Market: Incentives for Disclosure of Vulnerabilities

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security Market: Incentives for Disclosure of Vulnerabilities Peter P. Swire Ohio State University Houston/Sante Fe Conference June 4, 2005

  2. Overview • The prior paper: when it is efficient to disclose security information • This paper: what are the incentives actors face on whether to disclose? • Security notification statutes • Open Source software • Proprietary software • Government

  3. First Paper: Effects of Disclosure Help Defenders Low High

  4. Low Help Attackers High Open Source Information Sharing Public Domain Military/ Intelligence Effects of Disclosure -- II Help Defenders Low High

  5. Why Computer & Network Attacks More Often Benefit From Disclosure • Hiddenness & the first-time attack • N = number of attacks • L = learning from attacks • C = communicate with other attackers • Hiddenness helps for pit or for mine field • Hiddenness works much less well for • Mass-market software • Firewalls • Encryption algorithms

  6. What Is Different for Cyber Attacks? • Many attacks • Each attack is low cost • Attackers learn from previous attacks • This trick got me root access • Attackers communicate about vulnerabilities • Because of attackers’ knowledge, disclosure often helps defenders more than attackers for cyber attacks

  7. II. Security Notification • California statute, S.B. 1386 • If SSN, bank account breached, then notify • This year, ChoicePoint, B of A, etc. • Likely federal legislation

  8. Security Notification: Externality • 1st party: system owner • 2d parties: • Attackers – steal identities or know exploit • Defenders – Open Source coders, may help • 3rd parties: • Data of 3rd parties held • Externality: secrecy harms third parties but often helps 1st party, so under-disclosure

  9. Security Notification: Legal Rule • I believe the externality is significant • Issues for possible discussion • What is the trigger for notification, to avoid over- and under-notification? • What sort of guidance, advisory opinions, common law, or other mechanisms can clarify over time when to notify?

  10. Incentives to Disclose • California law concerns disclosure of 3rd party data held by 1st party • Next, disclosure by 1st party of data that may help security of 1st and 3rd parties • Security motive – when disclosure will help 1st party’s security goals • Competition motive – when disclosure will help 1st party’s competitive goals

  11. Case 1: Open Source/Security • By ideology, by definition, & under licenses, open source code is viewable by all • Based on interviews, secrecy still used: • For passwords and keys • “Stealth firewalls” and other hidden features that are not observable from the outside • “Secret sauce” such as unusual settings and configurations, to defeat script kiddies • In short, rational secrecy is used to foil first-time and unsophisticated attacks

  12. Case 2: Open Source/Competition • Interviews with O.S. devotees, they smile and admit that they don’t publish their best stuff – what’s going on? • Services dominate products in Open Source business models • GPL 2.0 applies to any work “distributed or published”, but not to services provided by one company • Conclusion: trade secrets used in services have become a key competitive tool • Consistent with IBM and other major players’ services activities

  13. Case 2: Open Source/Competition • Emerging debate on GPL 3.0 • Possible Stallman proposal to require publishing of code used internally • If so, then a likely fracture in the Open Source community, with services companies (i.e., large commercial players) sticking with GPL 2.0 to protect their trade secrets and business models

  14. Case 3: Proprietary/Security • Initially, the owner of closed-source software is in a monopoly position about flaws in the software it wrote • An externality similar to database leaks, because 1st party loses reputation and risks liability with disclosure but harm on the 3rd party user • This description was likely more true several years ago, before computer security was so important • Size of externality depends on the degree to which the seller’s reputation suffers due to security flaws • Over time, outside programmers gain expertise, the 1st party loses its monopoly position in knowledge about vulnerabilities, & reputation effect is greater

  15. Case 3: Proprietary/Security • What pressures force disclosure of vulnerabilities? • Buyers with monopsony power, who have a taste to know the code in their system • Especially governments, who can (and do) require disclosure of vulnerabilities (Air Force) • To the extent there is competition based on software security, then disclosure may be profit-maximizing • Over time, have seen substantially greater openness about vulnerabilities in proprietary software

  16. Case 4: Proprietary/Competitive • Hidden source code as a trade secret and possible competitive edge • Countervailing incentive to have at least partly “open standards” in order to get broad adoption, network effects, & first-mover advantage • At least share with developers & joint ventures • Complex game theory on when to be open

  17. Open Source & Proprietary • Greater secrecy in Open Source than usually recognized • Secret sauce for security • Trade secrets in services • Greater openness in proprietary than usually recognized • Monopsony power, governments, reputation • Financial gains from at least partly open standards • Convergence of the two approaches when it comes to disclosure?

  18. Case 5: Government/Security • The information sharing dilemma • Disclosure helps both attackers & defenders • 1st party wants to share only with trusted third parties • Other 3rd parties may want/need information to protect their own systems/jurisdictions • Examples such as terrorist watch lists, terrorist modes of attack, alerts based on intelligence

  19. Case 5: Government/Security • What mechanisms for disclosure similar to the monopsonist or reputation effects? • Perhaps public choice demand for data sharing • Seems unlikely to be effective in forcing data from law enforcement or intelligence agencies • Thus a rationale for legal rules • FOIA to create transparency, including risks to communities • Executive Orders & congressional mandates to encourage information sharing

  20. Case 6: Government/Competitive • Widespread view that law enforcement & intelligence agencies hoard data • Most famously, the FBI has not shared with locals • Hoarding can protect turf – others can’t use it against the 1st party (the agency) • Hoarding can garner credit with stakeholders – the arrest, the correct intelligence analysis • Again, FOIA and Information Sharing mandates can seek to counter-act excessive secrecy

  21. Conclusions • Identify 1st, 2d, 3rd parties and possible externalities • Highlight overlapping dynamics of disclosure, both for security and competitive goals • Recognize situations where the amount of disclosure is most likely to vary from the optimal, and suggest legal & policy responses

More Related