View source for Full disclosure (computer security)

{{short description|Policy in computer security}}

In the field of [[Computer security|computer security]], independent researchers often discover flaws in software that can be abused to cause unintended behaviour; these flaws are called [[Vulnerability (computing)|vulnerabilities]]. The process by which the analysis of these vulnerabilities is shared with third parties is the subject of much debate, and is referred to as the researcher's ''disclosure policy''. '''Full disclosure''' is the practice of publishing analysis of software vulnerabilities as early as possible, making the data accessible to everyone without restriction. The primary purpose of widely disseminating information about vulnerabilities is so that potential victims are as knowledgeable as those who attack them.<ref name=exposing>{{cite web |last=Heiser|first=Jay |title=Exposing Infosecurity Hype |archive-url=https://web.archive.org/web/20060328012516/http://infosecuritymag.techtarget.com/articles/january01/columns_curmudgeons_corner.shtml  |archive-date=28 March 2006|url=http://infosecuritymag.techtarget.com/articles/january01/columns_curmudgeons_corner.shtml |work=Information Security Mag |publisher=TechTarget |date=January 2001 |access-date=29 April 2013 }}</ref>
<!--  Dates seem correct what causes error?? -->

In his 2007 essay on the topic, Bruce Schneier stated "Full disclosure – the practice of making the details of security vulnerabilities public – is a damned good idea. Public scrutiny is the only reliable way to improve security, while secrecy only makes us less secure".<ref name="schneier">{{cite web|url=https://www.schneier.com/essay-146.html|title=Damned Good Idea|last=Schneier|first=Bruce|date=January 2007|publisher=CSO Online|access-date=29 April 2013}}</ref> Leonard Rose, co-creator of an [[Electronic mailing list|electronic mailing list]] that has superseded bugtraq to become the de facto forum for disseminating advisories, explains "We don't believe in security by obscurity, and as far as we know, full disclosure is the only way to ensure that everyone, not just the insiders, have access to the information we need."<ref name=fulldisc>{{cite web |last=Rose |first=Leonard |title=Full-Disclosure |url=https://lists.grok.org.uk/mailman/listinfo/full-disclosure |archive-url=https://wayback.archive-it.org/all/20101223024433/https://lists.grok.org.uk/mailman/listinfo/full-disclosure |url-status=dead |archive-date=23 December 2010 |work=A lightly-moderated mailing list for the discussion of security issues |access-date=29 April 2013 }}</ref>

== The vulnerability disclosure debate ==

The controversy around the public disclosure of sensitive information is not new. The issue of full disclosure was first raised in the context of locksmithing, in a 19th-century controversy regarding whether weaknesses in lock systems should be kept secret in the locksmithing community, or revealed to the public.<ref name=hobbs>{{cite book|last=Hobbs|first=Alfred|title=''Locks and Safes: The Construction of Locks|year=1853|publisher=Virtue & Co.|location=London}}</ref> Today, there are three major disclosure policies under which most others can be categorized:<ref name=sans>{{cite web|last=Shepherd|first=Stephen|title=Vulnerability Disclosure: How do we define Responsible Disclosure?|url=https://www.sans.org/reading_room/whitepapers/threats/define-responsible-disclosure_932|work=SANS GIAC SEC PRACTICAL VER. 1.4B (OPTION 1)|publisher=SANS Institute|access-date=29 April 2013}}</ref> [[Social:Non-disclosure agreement|Non Disclosure]], [[Responsible disclosure|Coordinated Disclosure]], and Full Disclosure.

The major stakeholders in vulnerability research have their disclosure policies shaped by various motivations, it is not uncommon to observe campaigning, marketing or lobbying for their preferred policy to be adopted and chastising those who dissent. Many prominent security researchers favor full disclosure, whereas most vendors prefer coordinated disclosure. Non disclosure is generally favored by commercial exploit vendors and blackhat hackers.<ref name="Moore2005">{{cite book|last=Moore|first=Robert|title=Cybercrime: Investigating High Technology Computer Crime|year=2005|publisher=Matthew Bender & Company|isbn=1-59345-303-5|page=258}}</ref>

=== Coordinated vulnerability disclosure ===

Coordinated vulnerability disclosure is a policy under which researchers agree to report vulnerabilities to a coordinating authority, which then reports it to the vendor, tracks fixes and mitigations, and coordinates the disclosure of information with stakeholders including the public.<ref>{{Cite web|url=https://www.ceps.eu/ceps-publications/software-vulnerability-disclosure-europe-technology-policies-and-legal-challenges/|title=Software Vulnerability Disclosure in Europe|date=2018-06-27|website=CEPS|language=en-US|access-date=2019-10-18}}</ref><ref>{{Cite journal |last1=Weulen Kranenbarg |first1=Marleen |last2=Holt |first2=Thomas J. |last3=van der Ham |first3=Jeroen |date=2018-11-19 |title=Don't shoot the messenger! A criminological and computer science perspective on coordinated vulnerability disclosure |journal=Crime Science |language=en |volume=7 |issue=1 |pages=16 |doi=10.1186/s40163-018-0090-8 |issn=2193-7680|doi-access=free }}</ref> In some cases the coordinating authority is the vendor. The premise of coordinated disclosure is typically that nobody should be informed about a vulnerability until the software vendor says it is time.<ref>{{Cite web|url=https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html|title=Project Zero: Vulnerability Disclosure FAQ|website=Project Zero|access-date=2019-10-18}}</ref><ref name=rfc>{{cite web|last=Christey|first=Steve|title=Responsible Vulnerability Disclosure Process|url=https://tools.ietf.org/html/draft-christey-wysopal-vuln-disclosure-00|publisher=IETF|access-date=29 April 2013|page=3.3.2}}</ref>  While there are often exceptions or variations of this policy, distribution must initially be limited and vendors are given privileged access to nonpublic research.

The original name for this approach was “[[Responsible disclosure|responsible disclosure]]”, based on the essay by Microsoft Security Manager Scott Culp “It's Time to End Information Anarchy”<ref name="culp">{{cite web |last=Culp |first=Scott |title=It's Time to End Information Anarchy |url=http://www.microsoft.com/technet/treeview/default.asp?url=/technet/columns/security/noarch.asp |work=Technet Security |publisher=Microsoft TechNet |access-date=29 April 2013 |url-status=dead |archive-url=https://web.archive.org/web/20011109045330/http://www.microsoft.com/technet/treeview/default.asp?url=%2Ftechnet%2Fcolumns%2Fsecurity%2Fnoarch.asp |archive-date=November 9, 2001 }}</ref> (referring to full disclosure). Microsoft later called for the term to be phased out in favor of “Coordinated Vulnerability Disclosure” (CVD).<ref name="co-ord">{{cite web|last=Goodin|first=Dan|title=Microsoft imposes security disclosure policy on all workers|url=https://www.theregister.co.uk/2011/04/19/microsoft_vulnerability_disclosure_policy/print.html|work=The Register|access-date=29 April 2013}}</ref><ref name="mssec" />

Although the reasoning varies, many practitioners argue that end-users cannot benefit from access to vulnerability information without guidance or patches from the vendor, so the risks of sharing research with malicious actors is too great for too little benefit. As Microsoft explain, "[Coordinated disclosure] serves everyone's best interests by ensuring that customers receive comprehensive, high-quality updates for security vulnerabilities but are not exposed to malicious attacks while the update is being developed."<ref name="mssec">{{cite web|url=https://www.microsoft.com/security/msrc/report/disclosure.aspx|title=Coordinated Vulnerability Disclosure|last=Microsoft Security|website=[[Company:Microsoft|Microsoft]] |url-status=live|archive-url=https://web.archive.org/web/20141216085920/http://download.microsoft.com/download/2/5/5/255EF667-218D-42B1-84B4-1A21F39BA167/CVD.docx|archive-date=2014-12-16|access-date=29 April 2013}}</ref>

To prevent vendors to indefinitely delaying the disclosure, a common practice in the security industry, pioneered by Google,<ref>{{Cite web |title=About Google's App Security - Google |url=https://about.google/intl/ALL_us/appsecurity/ |access-date=2023-05-17 |website=about.google |language=en}}</ref> is to publish all the details of vulnerabilities after a deadline, usually 90 or 120<ref>{{Cite web |title=Policy {{!}} Zero Day Initiative |url=https://zerodayinitiative.com/ |access-date=2023-05-17 |website=zerodayinitiative.com}}</ref> days reduced to 7 days if the vulnerability is [[Exploit (computer security)|under active exploitation]].<ref>{{Cite web |date=2022-08-30 |title=Reviewing 90 Day Responsible Disclosure Policies in 2022 |url=https://www.tenable.com/podcast/reviewing-90-day-responsible-disclosure-policies-in-2022 |access-date=2023-05-17 |website=Tenable® |language=en}}</ref>

=== Full disclosure ===

Full disclosure is the policy of publishing information on vulnerabilities without restriction as early as possible, making the information accessible to the general public without restriction. In general, proponents of full disclosure believe that the benefits of freely available vulnerability research outweigh the risks, whereas opponents prefer to limit the distribution.

The free availability of vulnerability information allows users and administrators to understand and react to vulnerabilities in their systems, and allows customers to pressure vendors to fix vulnerabilities that vendors may otherwise feel no incentive to solve. There are some fundamental problems with coordinated disclosure that full disclosure can resolve.

* If customers do not know about vulnerabilities, they cannot request patches, and vendors experience no economic incentive to correct vulnerabilities.
* Administrators cannot make informed decisions about the risks to their systems, as information on vulnerabilities is restricted.
* Malicious researchers who also know about the flaw have a long period of time to continue exploiting the flaw.

Discovery of a specific flaw or vulnerability is not a mutually exclusive event, multiple researchers with differing motivations can and do discover the same flaws independently.

There is no standard way to make vulnerability information available to the public, researchers often use mailing lists dedicated to the topic, academic papers or industry conferences.

=== Non disclosure ===

Non disclosure is the policy that vulnerability information should not be shared, or should only be shared under non-disclosure agreement (either contractually or informally).

Common proponents of non-disclosure include commercial exploit vendors, researchers who intend to exploit the flaws they find,<ref name=sans /> and proponents of [[Security through obscurity|security through obscurity]].

=== Debate ===
In 2009, Charlie Miller, Dino Dai Zovi and Alexander Sotirov announced at the CanSecWest conference the "No More Free Bugs" campaign, arguing that companies are profiting and taking advantage of security researchers by not paying them for disclosing bugs.<ref>{{Cite web |title=Dailydave: No more free bugs (and WOOT) |url=https://seclists.org/dailydave/2009/q2/17 |access-date=2023-05-17 |website=seclists.org |language=en}}</ref> This announce made it to the news and opened a broader debate about the problem and its associated incentives.<ref>{{Cite web |title="No more free bugs"? There never were any free bugs |url=https://www.zdnet.com/article/no-more-free-bugs-there-never-were-any-free-bugs/ |access-date=2023-05-17 |website=ZDNET |language=en}}</ref><ref>{{Cite web |date=2009-03-23 |title=No more free bugs for software vendors |url=https://threatpost.com/no-more-free-bugs-software-vendors-032309/72484/ |access-date=2023-05-17 |website=threatpost.com |language=en}}</ref>

==== Arguments against coordinated disclosure ====

Researchers in favor of coordinated disclosure believe that users cannot make use of advanced knowledge of vulnerabilities without guidance from the vendor, and that the majority is best served by limiting distribution of vulnerability information. Advocates argue that low-skilled attackers can use this information to perform sophisticated attacks that would otherwise be beyond their ability, and the potential benefit does not outweigh the potential harm caused by malevolent actors. Only when the vendor has prepared guidance that even the most unsophisticated users can digest should the information be made public.

This argument presupposes that vulnerability discovery is a mutually exclusive event, that only one person can discover a vulnerability. There are many examples of vulnerabilities being discovered simultaneously, often being exploited in secrecy before discovery by other researchers.<ref name=ac1d>{{cite web|last=B1tch3z|first=Ac1d|title=Ac1db1tch3z vs x86_64 Linux Kernel|url=http://seclists.org/fulldisclosure/2010/Sep/268|access-date=29 April 2013}}</ref> While there may exist users who cannot benefit from vulnerability information, full disclosure advocates believe this demonstrates a contempt for the intelligence of end users. While it's true that some users cannot benefit from vulnerability information, if they're concerned with the security of their networks they are in a position to hire an expert to assist them as you would hire a mechanic to help with a car.

==== Arguments against non disclosure ====

Non disclosure is typically used when a researcher intends to use knowledge of a vulnerability to attack computer systems operated by their enemies, or to trade knowledge of a vulnerability to a third party for profit, who will typically use it to attack their enemies.

Researchers practicing non disclosure are generally not concerned with improving security or protecting networks. However, some proponents{{who?|date=June 2022}} argue that they simply do not want to assist vendors, and claim no intent to harm others.

While full and coordinated disclosure advocates declare similar goals and motivations, simply disagreeing on how best to achieve them, non disclosure is entirely incompatible.

== References ==
{{Reflist}}

{{DEFAULTSORT:Full disclosure (computer security)}}
[[Category:Computer security procedures]]

{{Sourceattribution|Full disclosure (computer security)}}