11

I work on an (intentionally undisclosed) open source project. To the best of my knowledge, we do not have a discoverable policy on reporting security vulnerabilities.

Rails has their own policy requesting that security vulnerabilities are not announced to the public; so does PostgreSQL and Oracle, to pick a couple big names.

While we can certainly come up with our own policy for reporting security vulnerabilities in the project I work on, I would prefer to leverage someone else's work. Is there any kind of open standard that we can follow for our requested procedure to report discovered security vulnerabilities?

Mark Rushakoff
  • 427
  • 3
  • 10

4 Answers4

7

Primarily, three philosophies are followed in the industry regarding security vulnerabilities:

  1. Full Disclosure
  2. No disclosure
  3. Responsible Disclosure

In full disclosure the security researcher who discover vulnerabilities openly announce the details of the vulnerability and in most cases a PoC of the exploit is also provided with the disclosure information. This idea was prevalent in the 90s when security researchers used to announce security vulnerabilities on almost daily basis in Windows, Linux, and other software on websites such as Full Disclosure and Bugtraq mailing list.

The second philosophy is that of no disclosure. For example, in case of patch Tuesday Microsoft releases a lot of fixes for the vulnerabilities you don't know anything about other than a short description. This philosophy is usually followed by private security researchers working in collaboration with the software vendor. It is also followed by the internal security/QA team of the vendor.

The third and most widespread philosophy followed nowadays is the responsible disclosure policy. Here, the security researcher who discover the vulnerability give sufficient time (one month is the bare minimum in most cases) to fix the vulnerability. After that time the security researcher disclose the vulnerability and exploitation details to the public even if the vendor don't patch the security hole. This is called responsible disclosure since the vendor has enough time to provide a patch of the vulnerability and don't expose critical machines to be exploited freely.

You can follow the third option since it is the one followed by most of the security researchers nowadays and provide protection to both the vendor of the software as well as the security researcher and user of the software in ensuring that the vendor will provide a patch for the vulnerability because of the pressure of the impending date of full disclosure.

techraf
  • 9,159
  • 11
  • 45
  • 63
void_in
  • 5,621
  • 1
  • 23
  • 29
  • 4
    Thanks, but that doesn't answer my question. We certainly would prefer that if someone found a vulnerability in our software, that they would responsibly disclose it. I was trying to ask if there was an existing form or template we could use to ask people to follow responsible disclosure. – Mark Rushakoff Apr 26 '13 at 04:14
  • Out of curiosity, what happens when a software vendor follows the third methodology and a vulnerability is discovered that would either require 3.a) a temporary, bad, but vulnerability containment method sufficient patch (i.e. in time, fixes exact vulnerability but might expose another), or 3.b) a proper patch solving a major design flaw, but takes longer than the agreed on time to fix? Which of the two (3.a or 3.b) is preferable then? 3.a solves one vulnerability but leaves you exposed to another (Java comes to mind LOL), and 3.b comes with a threat of being exposed until patch is released. – TildalWave Apr 26 '13 at 04:14
  • @TildalWave what I have seen is that if the security researcher know that the vendor is actually trying to solve the problem, then the date of the disclosure can be extended. The purpose of the impending dislosure is to pressurize the vendor to work on the patch. In case of Oracle, it is a known fact that they used to not provide a patch even for months but now the pressure of a public exploit within hours forced them to provide a patch on priority basis. – void_in Apr 26 '13 at 04:26
  • @MarkRushakoff Accuvant Labs have provided a template for their disclosure policy at http://www.accuvant.com/sites/default/files/Accuvant%20Responsible%20Dislosure%20Policy_230610.pdf. Although that is from a security researcher perspectvie, but is is going to give you at idea about what you can ask from the security researcher once (s)he notifies you about the security vulnerability. – void_in Apr 26 '13 at 04:37
2

There is an Open source Responsible Disclosure Framework that you may use:

This Framework is maintained by Bugcrowd and CipherLaw. It is designed to quickly and smoothly prepare your organization to work with the independent security researcher community while reducing the legal risks to researchers and companies. The policy itself has been written with both simplicity and legal completeness in mind.

  • Setting up a Responsible Disclosure Program - A step by step best practices guide on how to setup your program.
  • Responsible Disclosure Policy - A boilerplate disclosure policy.
morallo
  • 121
  • 3
1

I found that there are two ISO standards in development that are due to be finished by the end of the year that relate to vulnerability handling:

  • ISO 30111 "covers all vulnerability handling processes, whether they are identified internally or are reported by an external source"
  • ISO 29147 "covers vulnerability disclosures from external sources such as end users, security researchers and hackers"

I haven't been able to find any drafts of those standards online, but I'm excited to see them when they are finished.

Mark Rushakoff
  • 427
  • 3
  • 10
1

There's some tips on disclosing security vulnerabilities to open source projects on the Open Source Software Security Wiki hosted by OpenWall, but it's rather bare-bones at the moment, and certainly nothing like a standard template.

You can certainly find plenty of examples of how the vulnerabilities are disclosed to the public, either by the bug finders or the projects, on the associated oss-security mailing list.

alanc
  • 140
  • 4