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

<p>{% trans %}This page was last updated in June 2020.{%- endtrans %}</p>

<p>{% trans %}Researchers: while you research/hack, we ask that you refrain from the following: - Performing active exploits or Denial of Service attacks on the
i2p network - Performing social engineering on i2p development team members - Performing any physical or electronic attempts against i2p property and/or data
centers{%- endtrans %}</p>
<p>{% trans %}As i2p is an open-source community, many volunteers and development team members run their own I2P Sites as well as public (“non-private internet”) domains. These
sites/servers are NOT in the scope of the vulnerability assessment / response process, only the underlying code of i2p is.{%- endtrans %}</p>

<h2 id="i.-point-of-contact-for-security-issues">I. {{ _('Point of Contact for Security Issues') }}</h2>

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

<h2 id="ii.-security-response-team">II. {{ _('Security Response Team') }}</h2>

<p>{% trans -%}
Echelon is the trusted security point-of-contact. He forwards e-mails to team members as appropriate.
{%- endtrans %}</p>

<h2 id="iii.-incident-response">III. {{ _('Incident Response') }}</h2>

<ol>
  <li>{% trans -%}
Researcher submits report via:
  {%- endtrans %}
      security (at) geti2p.net
  </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
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 %}
Establish severity of vulnerability:
  {% endtrans %}
    <dl>
      <dt>HIGH</dt>
      <dd>{% trans -%}
Affects 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 -%}
Affects 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 works on a patch LOCALLY, patches are shared by the response team via PGP-encrypted e-mail until such a time as it is safe to expose to the public.
      {%- 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. At this time, it is not possible to release an in-network update for only one operating system or
		architecture. In order that all affected products can be released as quickly as possible, the person responsible
		for that software should be able to perform necessary release processes in a timely manner. Importantly this should include
		consideration for package maintainers in Debian, Ubuntu and F-Droid.
      {%- endtrans %}</li>
    </ol>
  </li>
</ol>

<h2 id="iv.-post-release-disclosure-process">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><ol>
        <li>If the vulnerability may be exploited while the network is being upgraded, delay the announcement until the vulnerable routers are upgraded.</li>
		<li>After the update is successful, write the announcement for the news feed, send it for translation, and release it.</li>
		<li>When translations come in, news operators should pull in the translations and update their feeds.</li>
      </ol></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 id="v.-incident-analysis">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 id="vi.-resolutions">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>IRC</li>
  <li>Email</li>
  <li>Twitter</li>
</ol>

<h2 id="vii.-continuous-improvement">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 %}