i2p.www/i2p2www/pages/site/research/vrp.html

{% extends "global/layout.html" %}
{% block title %}{{ _('Vulnerability Response Process') }}{% endblock %}
{% block lastupdated %}{% trans %}January 2017{% endtrans %}{% endblock %}
{% block content %}
<p>{% trans %}
This process is subject to change. Please refer to this page for the current VRP.
{%- endtrans %}</p>

<h2>I. {{ _('Point of Contact for Security Issues') }}</h2>

	security@geti2p.net - GPG Key fingerprint = EA27 06D6 14F5 28DB 764B F47E CFCD C461 75E6 694A

<h2>II. {{ _('Security Response Team') }}</h2>

<p>{% trans -%}
Only the following members have access to the security point of contact:
{%- endtrans %}</p>

<ol>
  <li>zzz</li>
  <li>str4d</li>
</ol>

<h2>III. {{ _('Incident Response') }}</h2>

<ol>
  <li>{% trans -%}
Researcher submits report via one or both of two methods:
  {%- endtrans %}
    <ol>
      <li>{{ _('Email')}}</li>
      <li><a href="https://hackerone.com/i2p">HackerOne</a></li>
    </ol>
  </li>

  <li>{% trans -%}
Response Team designates a Response Manager who is in charge of the particular
report based on availability and/or knowledge-set.
  {%- endtrans %}</li>

  <li>{% trans limit=3 -%}
In no more than {{limit}} working days, Response Team should gratefully
respond to researcher using only encrypted methods.
  {%- endtrans %}</li>

  <li>{% trans -%}
Response Manager makes inquiries to satisfy any needed information and to
confirm if submission is indeed a vulnerability.
  {%- endtrans %}
    <ol>
      <li>{% trans -%}
If submission proves to be vulnerable, proceed.
      {%- endtrans %}</li>
      <li>{% trans -%}
If not vulnerable:
      {%- endtrans %}
        <ol>
          <li>{% trans -%}
Response Manager responds with reasons why submission is not a vulnerability.
          {%- endtrans %}</li>
          <li>{% trans -%}
Response Manager moves discussion to a new or existing ticket on public Trac if necessary.
          {%- endtrans %}</li>
        </ol>
      </li>
    </ol>
  </li>

  <li>{% trans -%}
If over email, Response Manager opens a HackerOne issue for new submission.
  {%- endtrans %}</li>

  <li>{% trans %}
Establish severity of vulnerability:
  {% endtrans %}
    <dl>
      <dt>HIGH</dt>
      <dd>{% trans -%}
Effects network as a whole, has potential to break entire network or is on a scale of great catastrophe.
      {%- endtrans %}</dd>
      <dt>MEDIUM</dt>
      <dd>{% trans -%}
Effects individual routers, or must be carefully exploited.
      {%- endtrans %}</dd>
      <dt>LOW</dt>
      <dd>{% trans -%}
Is not easily exploitable.
      {%- endtrans %}</dd>
    </dl>
  </li>

  <li>{% trans -%}
Respond according to the severity of the vulnerability:
  {%- endtrans %}
    <ol>
      <li>{% trans limit=3 -%}
HIGH severities must be notified on website and news feed within {{limit}}
working days of classification.
      {%- endtrans %}
        <ol>
          <li>{% trans -%}
The notification should list appropriate steps for users to take, if any.
          {%- endtrans %}</li>
          <li>{% trans -%}
The notification must not include any details that could suggest an exploitation
path.
          {%- endtrans %}</li>
          <li>{% trans -%}
The latter takes precedence over the former.
          {%- endtrans %}</li>
        </ol>
      <li>{% trans -%}
MEDIUM and HIGH severities will require a Point Release.
      {%- endtrans %}</li>
      <li>{% trans -%}
LOW severities will be addressed in the next Regular Release.
      {%- endtrans %}</li>
    </ol>
  </li>

  <li>{% trans -%}
Response Team applies appropriate patch(es).
  {%- endtrans %}
    <ol>
      <li>{% trans -%}
Response Manager designates a PRIVATE monotone "hotfix branch" to work in.
      {%- endtrans %}</li>
      <li>{% trans -%}
Patches are reviewed with the researcher.
      {%- endtrans %}</li>
      <li>{% trans -%}
Any messages associated with PUBLIC commits during the time of review should not
make reference to the security nature of the PRIVATE branch or its commits.
      {%- endtrans %}</li>
      <li>{% trans -%}
Vulnerability announcement is drafted.
      {%- endtrans %}
        <ol>
          <li>{% trans -%}
Include severity of vulnerability.
          {%- endtrans %}</li>
          <li>{% trans -%}
Include systems/apps effected.
          {%- endtrans %}</li>
          <li>{% trans -%}
Include solutions (if any) if patch cannot be applied.
          {%- endtrans %}</li>
        </ol>
      <li>{% trans -%}
Release date is discussed.
      {%- endtrans %}</li>
    </ol>
  </li>

  <li>{% trans -%}
At release date, Response Team coordinates with developers to finalize update:
  {%- endtrans %}
    <ol>
      <li>{% trans -%}
Response Manager propagates the "hotfix branch" to trunk.
      {%- endtrans %}</li>
      <li>{% trans -%}
Response Manager includes vulnerability announcement draft in release notes.
      {%- endtrans %}</li>
      <li>{% trans -%}
Proceed with the Point or Regular Release. 
      {%- endtrans %}</li>
    </ol>
  </li>

<h2>IV. {{ _('Post-release Disclosure Process') }}</h2>

<ol>
  <li>{% trans limit=90 -%}
Response Team has {{limit}} days to fulfill all points within section III.
  {%- endtrans %}</li>

  <li>{% trans -%}
If the Incident Response process in section III is successfully completed:
  {%- endtrans %}
    <ol>
      <li>{% trans -%}
Response Manager contacts researcher and asks if researcher wishes for credit.
      {%- endtrans %}</li>
      <li>{% trans -%}
Finalize vulnerability announcement draft and include the following:
      {%- endtrans %}
        <ol>
          <li>{% trans -%}
Project name and URL.
          {%- endtrans %}</li>
          <li>{% trans -%}
Versions known to be affected.
          {%- endtrans %}</li>
          <li>{% trans -%}
Versions known to be not affected (for example, the vulnerable code was introduced in a recent version, and older versions are therefore unaffected).
          {%- endtrans %}</li>
          <li>{% trans -%}
Versions not checked.
          {%- endtrans %}</li>
          <li>{% trans -%}
Type of vulnerability and its impact.
          {%- endtrans %}</li>
          <li>{% trans -%}
If already obtained or applicable, a CVE-ID.
          {%- endtrans %}</li>
          <li>{% trans -%}
The planned, coordinated release date.
          {%- endtrans %}</li>
          <li>{% trans -%}
Mitigating factors (for example, the vulnerability is only exposed in uncommon, non-default configurations).
          {%- endtrans %}</li>
          <li>{% trans -%}
Workarounds (configuration changes users can make to reduce their exposure to the vulnerability).
          {%- endtrans %}</li>
          <li>{% trans -%}
If applicable, credits to the original reporter.
          {%- endtrans %}</li>
        </ol>
      </li>
      <li>{% trans -%}
Release finalized vulnerability announcement on website and in news feed.
      {%- endtrans %}</li>
      <li>{% trans -%}
For HIGH severities, release finalized vulnerability announcement on well-known mailing lists:
      {%- endtrans %}
        <ol>
          <li>oss-security@lists.openwall.com</li>
          <li>bugtraq@securityfocus.com</li>
        </ol>
      </li>
      <li>{% trans -%}
If applicable, developers request a CVE-ID.
      {%- endtrans %}
        <ol>
          <li>{% trans -%}
The commit that applied the fix is made reference too in a future commit and includes a CVE-ID.
          {%- endtrans %}</li>
        </ol>
      </li>
    </ol>
  </li>

  <li>{% trans -%}
If the Incident Response process in section III is *not* successfully completed:
  {%- endtrans %}
    <ol>
      <li>{% trans -%}
Response Team and developers organize an IRC meeting to discuss why/what points
in section III were not resolved and how the team can resolve them in the
future.
      {%- endtrans %}</li>
      <li>{% trans -%}
Any developer meetings immediately following the incident should include points
made in section V.
      {%- endtrans %}</li>
      <li>{% trans -%}
If disputes arise about whether or when to disclose information about a
vulnerability, the Response Team will publicly discuss the issue via IRC and
attempt to reach consensus.
      {%- endtrans %}</li>
      <li>{% trans limit=90 -%}
If consensus on a timely disclosure is not met (no later than {{limit}} days),
the researcher (after {{limit}} days) has every right to expose the
vulnerability to the public.
      {%- endtrans %}</li>
    </ol>
  </li>
</ol>

<h2>V. {{ _('Incident Analysis') }}</h2>

<ol>
  <li>{{ _('Isolate codebase') }}
    <ol>
      <li>{% trans -%}
Response Team and developers should coordinate to work on the following:
      {%- endtrans %}
        <ol>
          <li>{% trans -%}
Problematic implementation of classes/libraries/functions, etc. 
          {%- endtrans %}</li>
          <li>{% trans -%}
Focus on apps/distro packaging, etc.
          {%- endtrans %}</li>
          <li>{% trans -%}
Operator/config error, etc.
          {%- endtrans %}</li>
        </ol>
      </li>
    </ol>
  </li>

  <li>{{ _('Auditing') }}
    <ol>
      <li>{% trans -%}
Response Team and developers should coordinate to work on the following:
      {%- endtrans %}
        <ol>
          <li>{% trans -%}
Auditing of problem area(s) as discussed in point 1.
          {%- endtrans %}</li>
          <li>{% trans -%}
Generate internal reports and store for future reference.
          {%- endtrans %}</li>
          <li>{% trans -%}
If results are not sensitive, share with the public via IRC or public Trac.
          {%- endtrans %}</li>
        </ol>
      </li>
    </ol>
  </li>

  <li>{% trans limit=45 -%}
Response Team has {{limit}} days following completion of section III to ensure
completion of section V.
  {%- endtrans %}</li>
</ol>

<h2>VI. {{ _('Resolutions') }}</h2>

<p>{% trans -%}
Any further questions or resolutions regarding the incident(s) between the
researcher and response + development team after public disclosure can be
addressed via the following:
{%- endtrans %}</p>

<ol>
  <li>Trac</li>
  <li>HackerOne</li>
  <li>IRC</li>
  <li>Email</li>
  <li>Twitter</li>
</ol>

<h2>VII. {{ _('Continuous Improvement') }}</h2>

<ol>
  <li>{% trans -%}
Response Team and developers should hold annual meetings to review the previous
year's incidents.
  {%- endtrans %}</li>

  <li>{% trans -%}
Response Team or designated person(s) should give a brief presentation, including:
  {%- endtrans %}
    <ol>
      <li>{% trans -%}
Areas of I2P affected by the incidents.
      {%- endtrans %}</li>
      <li>{% trans -%}
Any network downtime or monetary cost (if any) of the incidents.
      {%- endtrans %}</li>
      <li>{% trans -%}
Ways in which the incidents could have been avoided (if any).
      {%- endtrans %}</li>
      <li>{% trans -%}
How effective this process was in dealing with the incidents.
      {%- endtrans %}</li>
    </ol>
  </li>

  <li>{% trans -%}
After the presentation, Response Team and developers should discuss:
  {%- endtrans %}
    <ol>
      <li>{% trans -%}
Potential changes to development processes to reduce future incidents.
      {%- endtrans %}</li>
      <li>{% trans -%}
Potential changes to this process to improve future responses.
      {%- endtrans %}</li>
    </ol>
  </li>
</ol>
{% endblock %}