Sentinel Chicken Networks
This policy serves as a guideline for how affiliates of Sentinel Chicken Networks may disclose vulnerabilities,
and to instruct MAINTAINERS on what may be expected when an ORIGINATOR discovers an ISSUE. This document is in no way
legally binding to any parties. Once again, it is merely a guideline.
Full Disclosure Policy
This policy is a modified version of a policy originally edited by rain forest puppy
which is available at http://www.wiretrip.net/rfp/policy.html.
Policy modified: July 28, 2003
Policy modified: May 23, 2002
Policy modified: Feb 9, 2002
Executive overview for vendors and software maintainers
This policy states the 'guidelines' that an individual intends to follow. You basically have 5 days (read below for the
definitions and semantics of what is considered a 'day') to return contact to the individual, and must keep in contact
with them at least every 5 days. Failure to do so will discourage them from working with you and encourage them to
publicly disclose the security problem.
This policy is not set in stone--in fact, it is encouraged that all parties regularly communicate with each during the
process, adjusting as situations arise.
Table of contents
Purpose of this policy
Detailed/commented explanation of policy
SCN Disclosure Policy FAQ
Using this policy
Purpose of this policy
This policy exists to establish a guideline for interaction between a researcher and software maintainer. It serves to
quash assumptions and clearly define intentions, so that both parties may immediately and effectively gauge the problem,
produce a solution, and disclose the vulnerability.
First and foremost, a wake-up call to the software maintainer: the researcher has chosen to NOT immediately disclose the
problem, but rather make an effort to work with you. This is a choice they did not have to make, and a choice that
hopefully you will respect and accept accordingly.
The goal of following this policy, above all else, is education:
Education of the vendor to the problem (ISSUE, as defined below).
Education of the researcher on how the vendor intends to fix the problem, and what
caveats might cause a solution to be delayed.
Education of the community of the problem, and hopefully a resolution.
With education, through continued communication between the researcher and software maintainer, it allows both parties to
see where the other one is coming from. Coupled with compensation*, the experience is then beneficial to the researcher,
vendor, and community.
(*Compensation is meant to include credit for discovery of the ISSUE, and perhaps in some cases, encouragement from the
vendor to continue research, which might include product updates, premier technical subscriptions, etc. Monetary
compensation, or any situation that could be misconstrued as extortion, is highly discouraged.)
The ISSUE is the vulnerability, problem, or otherwise reason for contact and communication.
The ORIGINATOR is the individual or group submitting the ISSUE.
The MAINTAINER is the individual, group, or vendor that maintains the
software, hardware, or resources that are related to the ISSUE.
The DATE OF CONTACT is the point in time when the ORIGINATOR contacts
All dates, times, and time zones are relative to the ORIGINATOR.
A work day is generally defined in respect to the ORIGINATOR.
A. The ORIGINATOR will send email regarding the ISSUE to the MAINTAINER; the point in time when email is sent from the
ORIGINATOR is considered the DATE OF CONTACT.
It is important that the ORIGINATOR review any documentation included with the object of the ISSUE for indication of a
proper method of contact. That failing, the ORIGINATOR should check the web site of the MAINTAINER for methods of contact.
Should the ORIGINATOR not be able to locate a suitable email address for the MAINTAINER, the ORIGINATOR should address the
regardless of their existence. Anyone who could be deemed as a 'MAINTAINER' is encouraged to populate at least some of
the above email addresses. Email auto-responses should NOT be considered as a message from the MAINTAINER.
Note: addressing the ISSUE to InterNIC handles may cause the email to be misdirected (for example, to a virtual hosting
company who happens to host the MAINTAINER's web site). Addressing the ISSUE to the above listed email addresses may
cause the email to be received by non-authoritative persons (for example, to an online service provider who happens to
have an user named 'security-alert').
B. The MAINTAINER is to be given 5 working days (in respects to the ORIGINATOR) from the DATE OF CONTACT; should no
contact occur by the end of 5 working days, the ORIGINATOR should disclose the ISSUE. Should the MAINTAINER contact the
ORIGINATOR within the 5 working days, it is at the discretion of the ORIGINATOR to delay disclosure past 5 working days.
The decision to delay should be passed upon active communication between
the ORIGINATOR and MAINTAINER.
C. Requests from the MAINTAINER for help in reproducing problems or for additional information should be honored by the
ORIGINATOR. The ORIGINATOR is encouraged to delay disclosure of the ISSUE if the MAINTAINER provides feasible reasons for
D. If the MAINTAINER goes beyond 5 working days without any communication to the ORIGINATOR, the ORIGINATOR may choose to
disclose the ISSUE. The MAINTAINER is responsible for providing regular status updates (regarding the resolution of the
ISSUE) at least once every 5 working days.
E. In respect for the ORIGINATOR following this policy, the MAINTAINER is encouraged to provide proper credit to the
ORIGINATOR for doing so. Failure to document credit to the ORIGINATOR may leave the ORIGINATOR unwilling to follow this
policy with the same MAINTAINER on future issues, at the ORIGINATOR's discretion.
Suggested (minimal) credit would be:
"Credit to [ORIGINATOR] for disclosing the problem to [MAINTAINER]."
F. The MAINTAINER is encouraged to coordinate a joint public release/disclosure with the ORIGINATOR, so that advisories of
problem and resolution can be made available together.
G. If the ISSUE is publicly disclosed, by a third-party, the ORIGINATOR is encouraged to discuss the current status of the
ISSUE with the MAINTAINER; based on that discussion, the ORIGINATOR may choose to disclose the ISSUE. The MAINTAINER is
encouraged to credit the ORIGINATOR for discovering the ISSUE. Should the MAINTAINER disclose the ISSUE, or items
supporting/relating to the ISSUE (patches, fixes, etc), the ORIGINATOR may
choose to disclose the ISSUE.
Detailed/commented explanation of policy
This section serves to elaborate on the items in the policy, for better
A. Pretty self explanatory--the ORIGINATOR is to email the MAINTAINER about the problem. The ORIGINATOR should do their
homework and try to find the correct address to email (by checking the MAINTAINER's web site, by looking in documentation
distributed with the software/product, etc). Emailing InterNIC handles or addresses such as 'postmaster' or 'webmaster'
is not good, since they are most likely IT support staff and not the proper representatives to handle such a situation.
B. The MAINTAINER has 5 work days respond. Note that all times of work days are relative to the ORIGINATOR, not the
MAINTAINER. Suggestion to the MAINTAINER: sooner is better than later--just because you have 5 days does not mean you
need to take them all. The ORIGINATOR is technically free to do whatever they want to do after 5 work days--however, they
should be fair and wait if the MAINTAINER shows adequate initiative to fix the ISSUE.
C. Just as the MAINTAINER shouldn't ignore the ORIGINATOR, neither should the ORIGINATOR ignore the MAINTAINER. The
ORIGINATOR should help the MAINTAINER recreate the problem, if necessary. It's probably in the best interest of the
ORIGINATOR to help the MAINTAINER confirm the problem--otherwise, the ORIGINATOR stands to disclose a potentially false
D. The MAINTAINER has to actively give status reports. Note that it's the MAINTAINER's responsibility to do so, and not
the ORIGINATOR's responsibility to request them.
E. If the ORIGINATOR does indeed take the time to follow this policy, they should be acknowledged not only for doing so,
but in general, acknowledged for finding the problem. There are proper ways to cite references, credit sources, and
otherwise respect the origination of information--I suggest vendors do the same. If you can not respect the ORIGINATOR
enough for taking the time to notify you of the ISSUE, the ORIGINATOR (and possibly others) may feel reluctant to follow
this policy with the same MAINTAINER in the future.
F. Making the problem and solution advisories available together allows the community to have immediate access to both the
problem description and the appropriate fix.
G. If the MAINTAINER feels it's appropriate to alert the public of the issue, then there's no reason why the ORIGINATOR
should not. Traditionally, alerting the community of a problem (but not providing full exploit details) has proven to be
futile; other researchers are then just as likely to discover the problem as well--and they may not bide by the guidelines
set by this policy. Therefore, if the issue is to be disclosed, all aspects of it should be disclosed. If a third-party
discovers and publishes the vulnerability, the MAINTAINER and ORIGINATOR should evaluate the status of a fix, and act
accordingly. No matter what, the MAINTAINER should always credit the ORIGINATOR.
SCN Disclosure Policy FAQ
Q. This policy uses dates and times for gauging responses. How do time zones/holidays/weekends/cultural differences factor
A. First off, as noted above, all dates and times are relative to the ORIGINATOR. Now, it is quite possible that a
difference in date/time perspective occurs, due to: the ORIGINATOR being on a different continent than the MAINTAINER, the
MAINTAINER having a different work week than the ORIGINATOR, the MAINTAINER being sick, the MAINTAINER taking an extended
weekend, the MAINTAINER having a holiday, etc. Therefore the initial contact period was extended to 5 days--we feel that
5 days should be adequate to surmount any date/time differences.
Q. I'm a software maintainer, and I can't possibly fix the problem in 5
A. You don't have to. If you (re)read the above, you have 5 days to establish communication. Provided you cooperate with
the researcher and keep them 'in the loop', they should provide you with whatever time necessary to resolve the ISSUE
(within fair reason).
Q. You mention compensation--do ORIGINATORs expect to be paid?
A. NO! (Well, they shouldn't...I can't definitely predict the expectations of people) Compensation, as mentioned in this
policy, is meant first-and-foremost to be PROPER CREDIT. Academia has historically and religiously provided credit when
referencing all types of works and research; the ISSUE provided by the ORIGINATOR should also be thought of as research,
and the ORIGINATOR should be credited accordingly. Now, beyond that, it may be in the vendor's best interest to promote
good relations with the researcher, and one suggested way is to provide updates and product licenses. A lot of research
is done on evaluation and trial versions of software--providing a single, full license/copy should produce little impact
on the vendor, but greatly help the researcher. Another suggestion is to allow access to support sites/technical content,
such as TechNet (if you happen to be Microsoft :)
Using this policy
This policy is free for anyone to modify, republish, sell, or otherwise use. The goal is to establish communication and
interaction amongst the security community (users, researchers, and vendors)--not hamper it with copyrights and
People are encouraged to use this policy or derivatives. You can make use this policy by supplying the URL (found at the
top of this document) in the initial vendor contact email, and giving indication that you intend to following the
If you intend to be an ORIGINATOR, we suggest you prefix your advisory
sent to the MAINTAINER with something similar to:
"This advisory is being provided to you under the policy
documented at http://www.sentinelchicken.com/disclosure_policy/.
You are encouraged to read this policy; however, in the interim,
you have approximately 5 days to respond to this initial
email. This policy encourages open communication, and I look
forward to working with you on resolving the problem detailed
In addition, should the ORIGINATOR and MAINTAINER arrive at a unified resolution and disclosure, it may be of interest to
contact the CVE officials (http://cve.mitre.org) to assign a CVE identifier to the vulnerability. Doing so allows the
vulnerability to be referenced and cataloged, facilitating it's acceptance and use into the community.
rain forest puppy [rfp-at-wiretrip.net] and all those who helped construct
the original Full Disclosure Policy v2.0