{% extends "global/layout.html" %} {% block title %}{{ _('Vulnerability Response Process') }}{% endblock %} {% block lastupdated %}{% trans %}January 2017{% endtrans %}{% endblock %} {% block content_id %}vrp{% endblock %} {% block content %}

{% trans %} This process is subject to change. Please refer to this page for the current VRP. {%- endtrans %}

I. {{ _('Point of Contact for Security Issues') }}

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

II. {{ _('Security Response Team') }}

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

  1. zzz
  2. str4d

III. {{ _('Incident Response') }}

  1. {% trans -%} Researcher submits report via one or both of two methods: {%- endtrans %}
    1. {{ _('Email')}}
    2. HackerOne
  2. {% trans -%} Response Team designates a Response Manager who is in charge of the particular report based on availability and/or knowledge-set. {%- endtrans %}
  3. {% trans limit=3 -%} In no more than {{limit}} working days, Response Team should gratefully respond to researcher using only encrypted methods. {%- endtrans %}
  4. {% trans -%} Response Manager makes inquiries to satisfy any needed information and to confirm if submission is indeed a vulnerability. {%- endtrans %}
    1. {% trans -%} If submission proves to be vulnerable, proceed. {%- endtrans %}
    2. {% trans -%} If not vulnerable: {%- endtrans %}
      1. {% trans -%} Response Manager responds with reasons why submission is not a vulnerability. {%- endtrans %}
      2. {% trans -%} Response Manager moves discussion to a new or existing ticket on public Trac if necessary. {%- endtrans %}
  5. {% trans -%} If over email, Response Manager opens a HackerOne issue for new submission. {%- endtrans %}
  6. {% trans %} Establish severity of vulnerability: {% endtrans %}
    HIGH
    {% trans -%} Effects network as a whole, has potential to break entire network or is on a scale of great catastrophe. {%- endtrans %}
    MEDIUM
    {% trans -%} Effects individual routers, or must be carefully exploited. {%- endtrans %}
    LOW
    {% trans -%} Is not easily exploitable. {%- endtrans %}
  7. {% trans -%} Respond according to the severity of the vulnerability: {%- endtrans %}
    1. {% trans limit=3 -%} HIGH severities must be notified on website and news feed within {{limit}} working days of classification. {%- endtrans %}
      1. {% trans -%} The notification should list appropriate steps for users to take, if any. {%- endtrans %}
      2. {% trans -%} The notification must not include any details that could suggest an exploitation path. {%- endtrans %}
      3. {% trans -%} The latter takes precedence over the former. {%- endtrans %}
    2. {% trans -%} MEDIUM and HIGH severities will require a Point Release. {%- endtrans %}
    3. {% trans -%} LOW severities will be addressed in the next Regular Release. {%- endtrans %}
  8. {% trans -%} Response Team applies appropriate patch(es). {%- endtrans %}
    1. {% trans -%} Response Manager designates a PRIVATE monotone "hotfix branch" to work in. {%- endtrans %}
    2. {% trans -%} Patches are reviewed with the researcher. {%- endtrans %}
    3. {% 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 %}
    4. {% trans -%} Vulnerability announcement is drafted. {%- endtrans %}
      1. {% trans -%} Include severity of vulnerability. {%- endtrans %}
      2. {% trans -%} Include systems/apps effected. {%- endtrans %}
      3. {% trans -%} Include solutions (if any) if patch cannot be applied. {%- endtrans %}
    5. {% trans -%} Release date is discussed. {%- endtrans %}
  9. {% trans -%} At release date, Response Team coordinates with developers to finalize update: {%- endtrans %}
    1. {% trans -%} Response Manager propagates the "hotfix branch" to trunk. {%- endtrans %}
    2. {% trans -%} Response Manager includes vulnerability announcement draft in release notes. {%- endtrans %}
    3. {% trans -%} Proceed with the Point or Regular Release. {%- endtrans %}

IV. {{ _('Post-release Disclosure Process') }}

  1. {% trans limit=90 -%} Response Team has {{limit}} days to fulfill all points within section III. {%- endtrans %}
  2. {% trans -%} If the Incident Response process in section III is successfully completed: {%- endtrans %}
    1. {% trans -%} Response Manager contacts researcher and asks if researcher wishes for credit. {%- endtrans %}
    2. {% trans -%} Finalize vulnerability announcement draft and include the following: {%- endtrans %}
      1. {% trans -%} Project name and URL. {%- endtrans %}
      2. {% trans -%} Versions known to be affected. {%- endtrans %}
      3. {% 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 %}
      4. {% trans -%} Versions not checked. {%- endtrans %}
      5. {% trans -%} Type of vulnerability and its impact. {%- endtrans %}
      6. {% trans -%} If already obtained or applicable, a CVE-ID. {%- endtrans %}
      7. {% trans -%} The planned, coordinated release date. {%- endtrans %}
      8. {% trans -%} Mitigating factors (for example, the vulnerability is only exposed in uncommon, non-default configurations). {%- endtrans %}
      9. {% trans -%} Workarounds (configuration changes users can make to reduce their exposure to the vulnerability). {%- endtrans %}
      10. {% trans -%} If applicable, credits to the original reporter. {%- endtrans %}
    3. {% trans -%} Release finalized vulnerability announcement on website and in news feed. {%- endtrans %}
    4. {% trans -%} For HIGH severities, release finalized vulnerability announcement on well-known mailing lists: {%- endtrans %}
      1. oss-security@lists.openwall.com
      2. bugtraq@securityfocus.com
    5. {% trans -%} If applicable, developers request a CVE-ID. {%- endtrans %}
      1. {% trans -%} The commit that applied the fix is made reference too in a future commit and includes a CVE-ID. {%- endtrans %}
  3. {% trans -%} If the Incident Response process in section III is *not* successfully completed: {%- endtrans %}
    1. {% 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 %}
    2. {% trans -%} Any developer meetings immediately following the incident should include points made in section V. {%- endtrans %}
    3. {% 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 %}
    4. {% 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 %}

V. {{ _('Incident Analysis') }}

  1. {{ _('Isolate codebase') }}
    1. {% trans -%} Response Team and developers should coordinate to work on the following: {%- endtrans %}
      1. {% trans -%} Problematic implementation of classes/libraries/functions, etc. {%- endtrans %}
      2. {% trans -%} Focus on apps/distro packaging, etc. {%- endtrans %}
      3. {% trans -%} Operator/config error, etc. {%- endtrans %}
  2. {{ _('Auditing') }}
    1. {% trans -%} Response Team and developers should coordinate to work on the following: {%- endtrans %}
      1. {% trans -%} Auditing of problem area(s) as discussed in point 1. {%- endtrans %}
      2. {% trans -%} Generate internal reports and store for future reference. {%- endtrans %}
      3. {% trans -%} If results are not sensitive, share with the public via IRC or public Trac. {%- endtrans %}
  3. {% trans limit=45 -%} Response Team has {{limit}} days following completion of section III to ensure completion of section V. {%- endtrans %}

VI. {{ _('Resolutions') }}

{% 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 %}

  1. Trac
  2. HackerOne
  3. IRC
  4. Email
  5. Twitter

VII. {{ _('Continuous Improvement') }}

  1. {% trans -%} Response Team and developers should hold annual meetings to review the previous year's incidents. {%- endtrans %}
  2. {% trans -%} Response Team or designated person(s) should give a brief presentation, including: {%- endtrans %}
    1. {% trans -%} Areas of I2P affected by the incidents. {%- endtrans %}
    2. {% trans -%} Any network downtime or monetary cost (if any) of the incidents. {%- endtrans %}
    3. {% trans -%} Ways in which the incidents could have been avoided (if any). {%- endtrans %}
    4. {% trans -%} How effective this process was in dealing with the incidents. {%- endtrans %}
  3. {% trans -%} After the presentation, Response Team and developers should discuss: {%- endtrans %}
    1. {% trans -%} Potential changes to development processes to reduce future incidents. {%- endtrans %}
    2. {% trans -%} Potential changes to this process to improve future responses. {%- endtrans %}
{% endblock %}