policies/secpolicy.html

   1 <!DOCTYPE html>
   2 <html lang="en">
   3 <!--#include virtual="/inc/head.inc" -->
   4
   5 <body>
   6 <!--#include virtual="/inc/banner.inc" -->
   7
   8   <div id="main">
   9     <div id="content">
  10       <div class="blog-index">
  11         <article>
  12           <header>
  13             <h2>Security Policy</h2>
  14             <h5>
  15               Last modified 28th September 2015
  16             </h5>
  17         </header>
  18           <div class="entry-content">
  19
  20             <h2>Introduction</h2>
  21
  22             <p>Recent flaws have captured the attention of the media
  23             and highlighted how much of the internet infrastructure is
  24             based on OpenSSL.  We've never published our policy on how
  25             we internally handle security issues; that process being
  26             based on experience and has evolved over the years.</p>
  27
  28             <h2>Reporting security issues</h2>
  29
  30             <p>
  31             We have an email address which can be used to notify
  32             us of possible security vulnerabilities.  A subset of
  33             OpenSSL team members receive this mail, and messages
  34             can be sent using PGP encryption.  Full details are at <a
  35             href="/news/vulnerabilities.html">https://www.openssl.org/news/vulnerabilities.html</a>
  36             </p>
  37
  38             <p>
  39             When we are notified about an issue we engage resources
  40             within the OpenSSL team to investigate and prioritise it.
  41             We may also utilise resources from the employers of our team
  42             members, as well as others we have worked with before.
  43             </p>
  44
  45             <h2>Background</h2>
  46
  47             <p>
  48             Everyone would like to get advance notice of security issues
  49             in OpenSSL.  This is a complex topic and we need to set out
  50             some background with our findings:
  51             </p>
  52             <ul>
  53               <li>The more people you tell in advance the higher the
  54               likelihood that a leak will occur.  We have seen this
  55               happen before, both with OpenSSL and other projects.</li>
  56
  57               <li>A huge number of products from an equally large number of
  58               organisations use OpenSSL. It's not just secure websites, you're
  59               just as likely to find OpenSSL inside your smart TV, car, or
  60               fridge.</li>
  61
  62               <li>We strongly believe that the right to advance patches/info
  63               should not be based in any way on paid membership to some forum.
  64               You can not pay us to get security patches in advance.</li>
  65
  66               <li>We can benefit from peer review of the patches and advisory.
  67               Keeping security issues private means they can't get the level
  68               of testing or scrutiny that they otherwise would.</li>
  69
  70               <li>It is not acceptable for organisations to use advance notice
  71               in marketing as a competitive advantage.  For example "if you
  72               had bought our product/used our service you would have been
  73               protected a week ago".</li>
  74
  75               <li>There are actually not a large number of serious
  76               vulnerabilities in OpenSSL which make it worth spending
  77               significant time keeping our own list of vendors we trust, or
  78               signing framework agreements, or dealing with changes, and
  79               policing the policy.  This is a significant amount of effort per
  80               issue that is better spent on other things.</li>
  81
  82               <li>We have previously used third parties to handle notification
  83               for us including CPNI, oCERT, or CERT/CC, but none were
  84               suitable.</li>
  85
  86               <li>It's in the best interests of the Internet as a whole to get
  87               fixes for OpenSSL security issues out quickly. OpenSSL embargoes
  88               should be measured in days and weeks, not months or years.</li>
  89
  90               <li>Many sites affected by OpenSSL issues will be running a
  91               version of OpenSSL they got from some vendor (and likely bundled
  92               with an operating system).  The most effective way for these
  93               sites to get protected is to get an updated version from that
  94               vendor.  Sites who use their own OpenSSL compilations should be
  95               able to handle a quick patch and recompile once the issue is
  96               public.</li>
  97             </ul>
  98
  99             <h2>Internal handling of security issues</h2>
 100
 101             <p>This leads us to our policy for security issues notified
 102             to us or found by our team which are not yet public.</p>
 103
 104             <p>"private" means kept within the OpenSSL development
 105             team.</p>
 106
 107             <p>We will determine the risk of each issue being addressed.
 108             We will take into account our experience dealing with past
 109             issues, versions affected, common defaults, and use cases.
 110             We divide the issues into the following categories:</p>
 111
 112             <ul>
 113               <li><em>CRITICAL Severity.</em>
 114               This affects common configurations and which are also likely to
 115               be exploitable. Examples include significant disclosure of the
 116               contents of server memory (potentially revealing user details),
 117               vulnerabilities which can be easily exploited remotely to
 118               compromise server private keys (excluding local, theoretical or
 119               difficult to exploit side channel attacks) or where remote code
 120               execution is considered likely in common situations.  These
 121               issues will be kept private and will trigger a new release of
 122               all supported versions.  We will attempt to address these as
 123               soon as possible.</li>
 124
 125               <li>
 126               <em>HIGH Severity.</em>
 127               This includes issues that are of a lower risk than critical,
 128               perhaps due to affecting less common configurations, or which
 129               are less likely to be exploitable.  These issues will be kept
 130               private and will trigger a new release of all supported
 131               versions.  We will attempt to keep the time these issues are
 132               private to a minimum; our aim would be no longer than a month
 133               where this is something under our control</li>
 134
 135               <li>
 136               <em>MODERATE Severity.</em>
 137               This includes issues like crashes in client applications,
 138               flaws in protocols that are less commonly used (such as DTLS),
 139               and local flaws.  These will in general be kept private until
 140               the next release, and that release will be scheduled so that it
 141               can roll up several such flaws at one time.</li>
 142
 143               <li>
 144               <em>LOW Severity.</em>
 145               This includes issues such as those that only affect the
 146               openssl command line utility, unlikely configurations, or hard
 147               to exploit timing (side channel) attacks.  These will in general
 148               be fixed immediately in latest development versions, and may be
 149               backported to older versions that are still getting updates.  We
 150               will update the vulnerabilities page and note the issue CVE in
 151               the changelog and commit message, but they may not trigger new
 152               releases.</li>
 153             </ul>
 154
 155             <p>During the investigation of issues we may work with individuals
 156             and organisations who are not on the development team.  We do this
 157             because past experience has shown that they can add value to our
 158             understanding of the issue and the ability to test patches.  In
 159             cases where protocols are affected this is the best way to
 160             mitigate the risk that a poorly reviewed update causes signficiant
 161             breakage, or to detect if issues are being exploited in the wild.
 162             We have a strict policy on what these organisations and
 163             individuals can do with the information and will review the need
 164             on a case by case basis.</p>
 165
 166             <h2>Prenotification policy</h2>
 167
 168             <p>Where we are planning an update that fixes security issues
 169             we will notify the openssl-announce list and update the home
 170             page to give our scheduled update release date and time and
 171             the severity of issues being fixed by the update.  No futher
 172             information about the issues will be given.  This is to aid
 173             organisations that need to ensure they have staff available
 174             to handle triaging our announcement and what it means to
 175             their organisation.</p>
 176
 177             <p>For updates that include critical or high severity issues we will
 178             also prenotify with more details and patches.  Our policy
 179             is to let the organisations that have a general purpose OS
 180             that uses OpenSSL have a few days notice in order to prepare
 181             packages for their users and feedback test results.</p>
 182
 183             <p>We use the mailing list described at <a
 184             href="http://oss-security.openwall.org/wiki/mailing-lists/distros">http://oss-security.openwall.org/wiki/mailing-lists/distros</a>
 185             for this.  We may also include other organisations that
 186             would otherwise qualify for list membership.  We may
 187             withdraw notifying individual organisations from future
 188             prenotifications if they leak issues before they are public
 189             or over time do not add value (value can be added by providing
 190             feedback, corrections, test results, etc.)</p>
 191
 192             <p>Finally, note that not all security issues are notified to
 193             us directly; some come from third parties such as companies
 194             that pay for vulnerabilities, some come from country CERTs.
 195             These intermediaries, or the researchers themselves, may
 196             follow a different style of notification. This is within their
 197             rights and outside of the control of the OpenSSL team.</p>
 198
 199           </div>
 200           <footer>
 201             You are here: <a href="/">Home</a>
 202             : <a href=".">Policies</a>
 203             : <a href="">Security Policy</a>
 204             <br/><a href="/sitemap.txt">Sitemap</a>
 205           </footer>
 206         </article>
 207       </div>
 208       <!--#include virtual="sidebar.inc" -->
 209     </div>
 210   </div>
 211   <!--#include virtual="/inc/footer.inc" -->
 212   </body>
 213   </html>
 214