Date: Fri, 29 Mar 2024 01:49:30 -0400 (EDT)
Message-ID: <1429552969.541.1711691370901@windcrest.sei.cmu.edu>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_540_1571155553.1711691370899"
------=_Part_540_1571155553.1711691370899
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
5.2 Disclosure Choices
5.2 Disclosure Choices
As we have mentioned previously, participants in Coordinated Vul=
nerability Disclosure iterate over the following questions:
- What actions should I take in response to this knowledge?
- Who else should I tell about it?
- What should I tell them?
Let's take a=
moment to explore questions 2 and 2a in a few scenarios. Each of these dis=
closure options have advantages and disadvantages. In this section, we adap=
t and expand some terminology from Shepherd [1]:
- No Disclosure =E2=80=93 All information about the vuln=
erability is kept private. Sometimes this is enforced by non-disclosure agr=
eements (NDAs). Vendors sometimes prefer this scenario to protect trade sec=
rets or to lessen the impact of perceived negative press. Some finders pref=
er not to disclose vulnerabilities to anyone, in the hope that malicious ac=
tors will not find out about the vulnerability if it is not disclosed. Data=
on the outcomes of a non-disclosure policy are difficult to come by, as th=
ese vulnerabilities are by definition hidden from public view.
- Private Disclosure =E2=80=93 When a product's vendor i=
s aware of a vulnerability, the vendor may take action to address it but wi=
ll only notify its own customer base of the vulnerability and its mitigatio=
n privately. Many of the same motives as the No Disclosure policy are also =
in play here; the hope is that malicious actors are much less likely to fin=
d out about and exploit a vulnerability if very few people are made aware o=
f the issue. Avoiding negative press is also cited as a reason for this app=
roach. Some vulnerability finders are satisfied by this method if all known=
customers can be reached, so that everyone using the software may be prote=
cted. However, this approach is often not practical for widely deployed or =
open source software.
- Limited (Partial) Disclosure =E2=80=93 When a vulnerab=
ility is found, only some information about the vulnerability is disclosed =
to the public. The goal is typically to slow down reverse engineering and e=
xploit development long enough for a fix to be developed and deployed. This=
is done by withholding proof of concept code or other technical details of=
the vulnerability while still providing enough information that users of t=
he product may take action to mitigate the issue.
- Full Disclosure =E2=80=93 When a vulnerability is foun=
d, all information about the vulnerability is disclosed to the public. Typi=
cally, this scenario results in the release of proof of concept exploit cod=
e along with a report describing the vulnerability. In some cases, finders =
following a full disclosure approach may not attempt to notify the vendor a=
t all in advance of the public release of the vulnerability report. In othe=
r cases, they may contact the vendor simultaneously or shortly before issui=
ng a public report. The belief is that this approach serves the greater goo=
d by allowing consumers to be aware of the full impact of issues in their p=
roducts and demand action from vendors, as well as have information availab=
le to take appropriate defensive action and make more informed purchasing d=
ecisions. Another perceived benefit is that a full disclosure allows other =
researchers and organizations to reproduce and confirm the vulnerability, w=
hereas a more limited disclosure may not provide enough information to do s=
o. Alternately, this type of disclosure may also be performed by the vendor=
s themselves: many open source projects, for example, handle security issue=
s in the open in order to maximize review of the vulnerability and testing =
of the proposed solution.
References
- S. Shepherd=
, "Vulnerability Disclosure: How Do We Define Responsible Disclosure?" SANS=
GIAC SEC Practical Repository, 2003.
------=_Part_540_1571155553.1711691370899--