Acest proces poate fi modificat. Vă rugăm să consultați această pagină pentru actualul VRP.

This page was last updated April 2023.

Researchers: during your study and network testing, 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 team and community members - Performing any physical or electronic attempts against I2P property and/or data centers

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.

I. Punct de contact pentru probleme de securitate

II. Echipa de răspuns la securitate

Echelon is the trusted security point-of-contact. He forwards emails to team members as appropriate.

III. Răspuns la incident

1. Researcher submits report via: security (at) geti2p.net
2. Echipa de răspuns desemnează un manager de răspuns care este responsabil de raport particular bazat pe disponibilitate și / sau set de cunoștințe.
3. In no more than 3 working days, Response Team should respond to researcher using only encrypted methods.
4. Managerul de răspuns face anchete pentru a satisface orice informație necesară și pentru confirmarea dacă transmiterea este într-adevăr o vulnerabilitate.
   1. Dacă depunerea se dovedește a fi vulnerabilă, continuați.
   2. Dacă nu este vulnerabil:
      1. Managerul de răspuns răspunde cu motivele pentru care transmiterea nu este o vulnerabilitate.
      2. Managerul de răspuns mută discuția la un bilet nou sau existent pe Trac public, dacă este necesar.
5. Stabiliți severitatea vulnerabilității:

   HIGH

   Rețeaua cu efecte în ansamblu, are potențialul de a rupe întreaga rețea sau este la scară de mari catastrofe.

   MEDIUM

   Affects individual routers, or must be carefully exploited.

   LOW

   Nu este ușor de exploatat.

6. Răspundeți în funcție de gravitatea vulnerabilității:
   1. Gravitatea ridicată trebuie notificată pe site-ul web și în fluxul de știri 3 zile lucrătoare de clasificare.
      1. Notificarea trebuie să enumere pașii adecvați pentru utilizatori, dacă este cazul.
      2. Notificarea nu trebuie să includă detalii care ar putea sugera o exploatare cale.
      3. Acesta din urmă are prioritate asupra primului.
   2. Severitatea medie și înaltă va necesita o eliberare de punct.
   3. Gravitatea scăzută va fi abordată în următoarea versiune periodică.
7. Echipa de răspuns aplică patch-uri adecvate.
   1. 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.
   2. Patch-urile sunt revizuite cu cercetătorul.
   3. Orice mesaj asociat cu angajamentele PUBLIC în timpul revizuirii nu trebuie face referire la natura de securitate a sucursalei PRIVATE sau a angajamentelor acesteia.
   4. Anunțul de vulnerabilitate este redactat.
      1. Includeți severitatea vulnerabilității.
      2. Includeți sisteme / aplicații efectuate.
      3. Includeți soluții (dacă există) dacă patch-ul nu poate fi aplicat.
   5. Data de lansare este discutată.
8. La data lansării, echipa de răspuns se coordonează cu dezvoltatorii pentru finalizarea actualizării:
   1. Response Manager propagă „ramura de remediere rapidă” în portbagaj.
   2. Response Manager include proiectul de anunț de vulnerabilitate în notele de lansare.
   3. 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.

IV. Procesul de divulgare post-eliberare

1. Echipa de răspuns are 90 zile pentru îndeplinirea tuturor punctelor din secțiunea III.
2. Dacă procesul de răspuns la incident în secțiunea III este finalizat cu succes:
   1. Managerul de răspuns contactează cercetătorul și îl întreabă dacă cercetătorul dorește credit.
   2. Finalizați proiectul de anunț pentru vulnerabilitate și includeți următoarele:
      1. Numele proiectului și adresa URL.
      2. Versiuni despre care se știe că sunt afectate.
      3. Versiunile despre care se știe că nu sunt afectate (de exemplu, codul vulnerabil a fost introdus într-o versiune recentă, iar versiunile mai vechi nu sunt afectate).
      4. Versiunile nu sunt verificate.
      5. Tipul de vulnerabilitate și impactul acesteia.
      6. Dacă este deja obținut sau aplicabil, un CVE-ID.
      7. Data de lansare planificată și coordonată.
      8. Factorii de atenuare (de exemplu, vulnerabilitatea este expusă numai în configurații neobișnuite, care nu sunt implicite).
      9. Rezolvări (modificările de configurare pe care le pot face utilizatorii pentru a reduce expunerea la vulnerabilitate).
      10. Dacă este cazul, credite către reporterul inițial.
   3. Eliberați anunțul de vulnerabilitate finalizat pe site-ul web și în fluxul de știri.
   4. 1. If the vulnerability may be exploited while the network is being upgraded, delay the announcement until the vulnerable routers are upgraded.
      2. After the update is successful, write the announcement for the news feed, send it for translation, and release it.
      3. When translations come in, news operators should pull in the translations and update their feeds.
   5. Pentru severități înalte, eliberați anunțul de vulnerabilitate finalizat pe listele de corespondențe cunoscute:
      1. oss-security@lists.openwall.com
      2. bugtraq@securityfocus.com
   6. Dacă este cazul, dezvoltatorii solicită un ID CVE.
      1. Angajamentul care a aplicat remedierea se face referire și la un angajament viitor și include un CVE-ID.
3. Dacă procesul de răspuns la incident în secțiunea III nu este * finalizat cu succes:
   1. Echipa de răspuns și dezvoltatorii organizează o întâlnire IRC pentru a discuta de ce / ce puncte în secțiunea III nu au fost soluționate și modul în care echipa le poate rezolva în cadrul viitor.
   2. Orice reuniuni de dezvoltatori imediat după incident ar trebui să includă puncte realizat în secțiunea V.
   3. În cazul în care apar dispute cu privire la dacă sau când trebuie dezvăluite informații despre o vulnerabilitate, echipa de răspuns va discuta în mod public problema prin IRC și încearca de a ajunge la consens.
   4. Dacă nu este îndeplinit consensul privind divulgarea la timp (nu mai târziu de 90 zile), cercetătorul (după 90 zile) are tot dreptul să expună vulnerabilitate pentru public.

V. Analiza incidentelor

1. Izolați baza de coduri
   1. Echipa de răspuns și dezvoltatorii ar trebui să se coordoneze pentru a lucra la următoarele:
      1. Implementarea problematică a claselor / bibliotecilor / funcțiilor etc.
      2. Concentrați-vă pe aplicații / ambalaje distro etc.
      3. Eroare operator / configurare etc.
2. Audit
   1. Echipa de răspuns și dezvoltatorii ar trebui să se coordoneze pentru a lucra la următoarele:
      1. Auditarea zonei (zonelor) problemelor descrise la punctul 1.
      2. Generați rapoarte interne și stocați pentru referințe viitoare.
      3. Dacă rezultatele nu sunt sensibile, împărtășiți-le publicului prin IRC sau Trac public.
3. Echipa de răspuns are 45 zile după finalizarea secțiunii III pentru a se asigura completarea secțiunii V.

VI. rezoluţiile

Orice întrebări sau rezoluții suplimentare privind incidentul (incidentele) dintre cercetător și echipă de răspuns + dezvoltare după divulgarea publică poate fi adresate prin următoarele:

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

VII. Imbunatatire continua

1. Echipa de răspuns și dezvoltatorii ar trebui să organizeze întâlniri anuale pentru a revizui cele anterioare incidente de anul.
2. Echipa de răspuns sau persoana (persoanele) desemnate (e) ar trebui să prezinte o prezentare succintă, inclusiv:
   1. Zonele I2P afectate de incidente.
   2. Orice întrerupere a rețelei sau costuri monetare (dacă există) ale incidentelor.
   3. Modalități în care incidentele ar fi putut fi evitate (dacă există).
   4. Cât de eficient a fost acest proces în tratarea incidentelor.
3. După prezentare, echipa de răspuns și dezvoltatorii ar trebui să discute:
   1. Modificări potențiale ale proceselor de dezvoltare pentru a reduce incidentele viitoare.
   2. Modificări potențiale ale acestui proces pentru a îmbunătăți răspunsurile viitoare.