Politică de divulgare a vulnerabilităților într-o firmă mică

Cineva găsește pe site-ul tău o pagină care îi arată factura altui client dacă schimbă un număr din adresă. Nu e infractor și nu e client. Vrea să îți spună, iar singura adresă pe care o găsește este căsuța generală a firmei. Trimite un email atent, primește un răspuns automat și nu mai aude nimic trei săptămâni. Omul care are o descoperire reală și niciun canal fie renunță, fie o publică. O politică de divulgare a vulnerabilităților oprește această secvență și, pentru o firmă de zece oameni, înseamnă o pagină și un fișier mic.

O politică de divulgare nu este un bug bounty

Un bug bounty este un program de plăți. Are nevoie de cineva care să trieze rapid, de o verificare juridică a termenilor, de o modalitate de a plăti oameni din alte țări și de un scope public care rămâne corect pe măsură ce site-ul se schimbă. O politică de divulgare promite un canal și un răspuns, nu bani. Diferența contează pentru că multe firme mici citesc despre bounty-uri, trag concluzia că tot subiectul e prea mare pentru ele și nu publică nimic.

Kitul de divulgare a vulnerabilităților al NCSC este scris exact pentru situația asta: organizații care nu au niciun proces. Numește trei componente, un canal de contact, o politică și un fișier security.txt, și trimite la ISO/IEC 29147:2018 ca standard din spate. Toate trei încap într-o după-amiază.

Riscul pe care îl acoperi nu este raportul în sine, ci tăcerea de după el. Un cercetător care nu găsește un canal are două opțiuni care te costă mai mult decât o reparație: publică sau vinde.

Publică fișierul și pagina

Două lucruri pentru două categorii de cititori. Fișierul este citit de unelte și de cercetătorii care îl verifică primul. Pagina este citită de omul care decide dacă are încredere să îți dea o descoperire.

security.txt stă la /.well-known/security.txt, în rădăcina domeniului, servit ca text/plain cu UTF-8. RFC 9116 cere două câmpuri, Contact și Expires, și definește Policy, Preferred-Languages, Canonical și Encryption ca opționale. Recomandă o dată de expirare la mai puțin de un an. Un fișier minimal arată așa:

Contact: mailto:security@firmata.ro

Expires: 2027-06-01T00:00:00.000Z

Policy: https://firmata.ro/ro/security

Preferred-Languages: ro, en

Trei observații practice. Adresa trebuie să fie una pe care o citește un om, nu o căsuță comună pe care nu o supraveghează nimeni; un raport care ajunge la office@ și așteaptă acolo este exact eșecul despre care e articolul. Data de expirare e partea pe care o uită toată lumea, așa că pune un memento în calendar lângă ea. Și dacă site-ul redirecționează orice cale către un prefix de limbă, verifică cu curl că fișierul din rădăcină răspunde, pentru că o redirecționare către un 404 e mai rea decât lipsa fișierului.

Pagina este politica în propoziții: ce vrei, ce promiți, ce este în afara scopului. Leagă-o din subsolul site-ului, nu doar din fișier. Majoritatea cercetătorilor nu vor căuta security.txt; vor căuta un link de securitate lângă pagina de contact.

Ce promiți și ce lași afară

O promisiune pe care o poți ține valorează mai mult decât una completă. Patru propoziții acoperă partea utilă.

• O confirmare de primire. Dă un termen: în trei zile lucrătoare, de exemplu. Politica-exemplu a NCSC folosește cinci zile lucrătoare pentru răspuns și zece pentru triaj, cu rugămintea de a nu insista mai des de o dată la paisprezece zile. Alege numere pe care le poți respecta și într-o săptămână proastă.
• O decizie. Spune că îi vei comunica dacă o consideri vulnerabilitate, chiar și când răspunsul este nu.
• Noutăți cât timp e deschis. O linie la fiecare schimbare de stare este suficientă.
• Credit, dacă îl vrea. Întreabă înainte să publici un nume.

Apoi propoziția de protecție, cea mai importantă de pe pagină: dacă raportezi cu bună-credință și rămâi în limitele scopului de mai jos, nu vom lua nicio măsură legală împotriva ta și nu te vom reclama autorităților pentru testele pe care le descrii. Formuleaz-o ca promisiune despre comportamentul tău, nu ca afirmație despre lege.

Nu promite un termen de reparare pe care nu îl controlezi sau confidențialitate pe care nu o poți garanta și nu oferi recompensă dacă nu ai de gând să o plătești. Politica-exemplu a NCSC spune direct că nu oferă recompense bănești. Un cercetător care așteaptă bani și primește un email de mulțumire devine un cercetător care publică.

Scopul este ce dă permisiunii o margine

Autorizarea este la fel de largă precum propoziția care o acordă, iar tot ce rămâne în afara ei este acces neautorizat. Un scop care spune „site-ul nostru” și atât nu este un scop. Îl lasă pe cercetător să ghicească, iar ghicitul este felul în care cineva ajunge să testeze procesatorul tău de plăți.

Un scop care funcționează pentru o firmă mică:

• Site-ul public și API-ul lui, pe producție, doar citire.
• Fără modificarea datelor, fără ștergeri, fără încărcări, cu excepția unui fișier de test inofensiv dacă permiți așa ceva.
• Fără denial of service și fără scanare automată de volum mare.
• Fără conturi care nu sunt ale cercetătorului și fără încercări de a ajunge la datele altor clienți dincolo de a demonstra că sunt accesibile.
• Fără inginerie socială, fără phishing pe angajați, fără acces fizic.
• Fără serviciile terțe pe care le folosești, cum ar fi procesatorul de plăți sau panoul de hosting; acelea se raportează furnizorului.
• Orice nu este listat este în afara scopului.

Politica-exemplu din kit are o listă mai lungă de interdicții; ia forma de acolo și taie ce nu ți se aplică. Dacă ai o copie de test, spune-o și spune dacă e în scop: un cercetător care poate strica o copie fără să atingă clienții va alege varianta aceea. Dacă nu ai, ține producția în scop, dar îngust și doar citire.

Pentru un test anume, de exemplu o verificare programată făcută de o persoană cunoscută, trimite o autorizare scrisă cu gazdele, perioada și numele persoanei. Nu lărgi pagina publică pentru un singur cercetător, pentru că următorul va citi aceeași pagină și va presupune aceeași libertate.

Adaugă o regulă despre date. Cere raportorului să șteargă în siguranță tot ce a obținut în timpul testării imediat ce nu mai are nevoie, și în cel mult o lună de la reparare. Aceasta este formularea pe care o folosește NCSC. Nu pune un acord de confidențialitate ca condiție pentru a citi raportul; kitul recomandă împotriva asta, pentru că omul vrea să se repare un bug, nu să devină furnizor.

Cum triezi un raport când nimeni din echipă nu se ocupă de securitate

Raportul vine ca un email de la un necunoscut, posibil cu linkuri și fișiere atașate. Tratează-l ca pe ceva nesigur. Nu deschide linkurile într-o sesiune în care ești autentificat ca administrator și deschide atașamentele pe un calculator pe care nu te-ar deranja să îl reinstalezi. Un raport de securitate este un pretext bun pentru phishing.

Apoi lucrează în ordinea asta.

• Confirmă în aceeași zi. Un paragraf: am primit, ne uităm până joi, acesta este numărul de referință.
• Scrie-l într-un singur tabel. Data, activul, raportorul, reclamația, starea, responsabilul, următoarea acțiune. Folosește stările din kit: nou, triat, reparat, duplicat, informativ, în afara scopului.
• Reprodu-l pe o copie, sau cu un cont creat special. Dacă nu reușești să îl reproduci, cere cererea exactă, nu mai mult acces.
• Judecă după activ, nu după scor. Întreabă ce ar putea face un vizitator anonim, la datele cui ajunge și cât ar costa repararea. Un script injectat în panoul de administrare și același script într-o arhivă de blog sunt probleme diferite cu același nume.
• Spune când. „Săptămâna asta” sau „la următoarea fereastră de mentenanță” este o decizie pe care raportorul se poate organiza. Lipsa unui răspuns nu este.

Două categorii acoperă majoritatea a ce primești. NCSC spune că scriptingul cross-site și preluarea unui subdomeniu sunt cele mai frecvente trimiteri către serviciul său de raportare. A doua este adesea o reparație de cinci minute: o înregistrare CNAME veche care arată încă spre un serviciu anulat, pe care oricine îl poate revendica.

Închide discuția cu raportorul

Spune-i când e reparat și invită-l să retesteze. Dacă cere să publice, conveniți o dată în loc să refuzi: politica-exemplu din kit primește cererile de divulgare și cere coordonarea publicării, ca utilizatorii să audă o singură versiune. Dacă raportul este real, dar decizi să nu îl repari, spune asta și spune de ce. Un raport închis cu un motiv termină firul; tăcerea îl reia în public.

Creditul nu costă nimic. Întreabă dacă vrea numele, un pseudonim sau nimic și pune-l pe o listă scurtă de mulțumiri pe pagina de politică, dacă este de acord. Kitul sugerează exact asta și este singura recompensă pe care o vor primi majoritatea celor care găsesc bug-uri mici la tine. Este și motivul pentru care vor raporta următorul tot ție, nu unei liste de discuții.

Partea românească

Dreptul penal român tratează accesul neautorizat la un sistem informatic ca infracțiune. Codul penal, Legea 286/2009, are un capitol separat despre infracțiunile contra siguranței și integrității sistemelor și datelor informatice, alături de capitolele despre frauda informatică și despre instrumentele de plată. Pentru o politică de divulgare contează ideea pe care este construită infracțiunea: accesul fără drept, nu accesul cu intenții rele. Un cercetător atent care rămâne într-un sistem în care nu avea voie să intre este în aceeași situație juridică precum unul neglijent.

Citește de două ori, pentru că schimbă scopul politicii. Nu este un scut. Nu poate obliga un procuror, iar publicarea ei nu transformă o faptă prevăzută de lege într-una permisă. Ce face este să documenteze dinainte și în scris ce gazde ai autorizat și pentru ce. Dacă un raport ajunge vreodată într-o dispută, pagina aceea datată este cea mai clară dovadă a locului unde a început și s-a terminat consimțământul tău. Îi mai face și decizia ușoară cercetătorului cinstit: poate arăta spre o pagină în loc să ghicească.

Din același paragraf decurg două detalii locale. Un raport poate conține date personale, deci regula de ștergere este regula de protecție a datelor pe care ai aplica-o oricărui alt fișier primit necerut. Și publică pagina în română, nu doar în engleză, cu ro primul în Preferred-Languages. Cel care găsește bug-ul pe un site românesc este adesea student sau developer junior și va citi versiunea românească mai atent.

Ce publici săptămâna asta

• Un /.well-known/security.txt cu o adresă supravegheată și o dată de expirare reală.
• O pagină de securitate în ambele limbi: ce vrei, patru promisiuni, lista de scop, propoziția de protecție.
• O căsuță sau un formular care ajunge la o persoană anume, cu număr de referință în primul răspuns.
• Un tabel pentru rapoarte, cu cele șase stări, ținut unde îl vede echipa.
• O copie de test sau un scop de producție doar-citire care spune asta.
• Un memento anual pentru verificarea paginii și a datei de expirare.

Nimic din toate acestea nu este un program de securitate. Este diferența dintre un cercetător care îți spune de un bug și unul care îi spune internetului. Pentru o firmă mică, diferența aceea este cea mai mare parte din risc. Dacă vrei și obiceiurile mai largi din jurul ei, ghidul nostru de securitate cibernetică pentru firme mici acoperă cele zece care contează, iar când vrem să vedem cum formulează alte programe aceleași promisiuni ne uităm la indexul de cercetare pe care îl ținem la Bounty Atlas. Dacă preferi ca cineva să citească proiectul de politică înainte să îl publici, programează un apel introductiv gratuit.