Responsible Disclosure: perché è fondamentale in cyber security

Il Responsible Disclosure è un approccio etico alla segnalazione delle vulnerabilità informatiche.

Prevede che chi individua un problema di sicurezza lo comunichi all’organizzazione responsabile in modo riservato e cooperativo, così da permetterle di correggerlo prima che l’informazione diventi pubblica.
In questo modo chi segnala e chi riceve la segnalazione lavorano nella stessa direzione: proteggere i dati e prevenire attacchi.

1. Di che cosa si tratta
2. Storia del Responsible Disclosure
3. Divulgazione coordinata e non coordinata
4. Come effettuare un Responsible Disclosure
5. Perché è fondamentale in cybersecurity

Di che cosa si tratta

Il Responsible Disclosure, o divulgazione coordinata delle vulnerabilità, è la procedura con cui chi individua una falla di sicurezza contatta l’organizzazione che ne è responsabile, dandole modo di correggerla prima che il problema diventi di dominio pubblico.

Riguarda siti web, applicazioni e servizi e si applica tanto ai grandi produttori di software quanto alle aziende che hanno fatto sviluppare un gestionale su misura.

La pratica si è diffusa negli ultimi anni con la crescente rilevanza della sicurezza informatica.
Viene spesso associata agli hacker etici ma è un comportamento che dovrebbe valere per chiunque scopra una vulnerabilità, anche per caso.

Il motivo è pratico prima che etico: la divulgazione coordinata previene conseguenze gravi, dal furto di dati al danneggiamento dei sistemi.
Perché funzioni, però, serve che l’organizzazione contattata risponda e intervenga. E non è affatto scontato.

Storia del Responsible Disclosure

La pratica è emersa nei primi anni Novanta come risposta ai problemi della divulgazione non coordinata, che esponeva gli utenti prima che i produttori avessero la possibilità di correggere.

All’inizio non esisteva alcun consenso su come gestire la questione e il dibattito era acceso.
Da una parte chi sosteneva la pubblicazione immediata per costringere le aziende ad agire, dall’altra chi proponeva un approccio più graduale per non danneggiare gli utenti finali.

Nel tempo si è affermata la seconda posizione, con l’adozione di linee guida e standard da parte di aziende, organizzazioni di sicurezza e governi.
I riferimenti internazionali oggi sono due norme ISO/IEC: la 29147, che disciplina come un’organizzazione riceve e gestisce le segnalazioni, e la 30111, che riguarda il processo interno di analisi e correzione.

Parallelamente numerose aziende tecnologiche hanno istituito programmi di ricompensa che retribuiscono i ricercatori per le segnalazioni, trasformando l’attività in un mercato regolato. Ogni vulnerabilità confermata attraverso questo percorso riceve un identificativo pubblico, il codice CVE, che permette a chiunque di riconoscerla e verificarla.

Divulgazione coordinata e non coordinata

Sono due approcci distinti e conviene chiarire subito che solo il primo rientra nel Responsible Disclosure.

La divulgazione coordinata

È la forma corretta.
Chi ha individuato la vulnerabilità la comunica all’organizzazione, le concede un tempo ragionevole per correggerla e solo dopo la pubblicazione della correzione rende pubblici i dettagli.

I vantaggi sono tre. Permette di segnalare senza esporre nessuno. Consente all’organizzazione di intervenire prima che il problema circoli. Costruisce un rapporto di collaborazione che rende più probabili le segnalazioni future.

La divulgazione non coordinata

È l’approccio opposto e consiste nel pubblicare i dettagli senza concedere all’organizzazione il tempo di correggere.

Viene difesa da chi sostiene che senza pressione pubblica molte aziende rinvierebbero indefinitamente, e l’argomento ha un fondamento.
Ma comporta due conseguenze pesanti. L’organizzazione potrebbe non avere le risorse per correggere in tempi rapidi. E nell’intervallo fra pubblicazione e correzione chiunque può sfruttare la falla, come mostra la rapidità con cui una vulnerabilità pubblicata diventa un exploit funzionante.

C’è poi un caso intermedio, che è quello più diffuso nella pratica professionale.
Il ricercatore concede un termine di novanta giorni e pubblica alla scadenza, indipendentemente dal fatto che la correzione sia arrivata. È un compromesso fra le due posizioni e oggi costituisce lo standard informale del settore.

Come effettuare un Responsible Disclosure

La procedura si articola in cinque passaggi.

Individuare la vulnerabilità e fermarsi lì.
La differenza fra l’aver notato un problema e l’averlo sfruttato è la differenza fra una segnalazione e un accesso non autorizzato. Vale anche quando le intenzioni sono buone.

Valutare l’impatto, cioè capire quali conseguenze può avere e quali sistemi o dati coinvolge.
Serve per descrivere il problema in modo che chi lo riceve ne comprenda la gravità, e il riferimento comune è il Common Vulnerability Scoring System.

Comunicare la scoperta al responsabile, attraverso canali dedicati quando esistono.
I produttori strutturati hanno un indirizzo per le segnalazioni di sicurezza, mentre con le realtà più piccole la strada è il referente tecnico contattato in via riservata. La comunicazione deve contenere prodotto e versione, descrizione riproducibile del comportamento osservato, impatto stimato e la dichiarazione esplicita di non aver condotto alcuna attività oltre all’osservazione.

Concedere il tempo per la correzione, con una scadenza indicata fin dall’inizio.
Novanta giorni è la convenzione più seguita, estendibile quando il problema richiede riprogettazioni e riducibile quando emergono prove di sfruttamento in corso. Quando la segnalazione coinvolge componenti usati da molti prodotti, come accaduto con la libreria XZ Utils, il coordinamento si estende a decine di soggetti.

Pubblicare i dettagli a correzione avvenuta, così che chi utilizza quel prodotto sappia di doversi aggiornare.

Se vi trovate nella posizione di chi ha scoperto un problema e deve decidere cosa farne, abbiamo scritto una guida pratica su cosa fare dopo aver trovato una vulnerabilità.

Perché è fondamentale in cybersecurity

Le ragioni sono quattro e riguardano soggetti diversi.

Sul piano economico, una vulnerabilità non segnalata può essere individuata da qualcun altro con intenzioni diverse.
I danni ricadono su aziende, clienti e in alcuni casi su infrastrutture critiche.

Sul piano della riservatezza, ogni giorno in cui una falla resta aperta è un giorno in cui i dati di chi usa quel sistema sono esposti.
Ed è un’esposizione che non finisce con la pubblicazione della correzione: finisce quando la correzione viene applicata, e quel momento dipende da un processo di patch management che in molte aziende passa in secondo piano.

Per i produttori, la segnalazione è l’unico modo per correggere problemi che i controlli interni non hanno intercettato.
Nessun processo di sviluppo, per quanto rigoroso, li trova tutti. La vicenda di Log4Shell lo ha mostrato su una delle librerie più diffuse al mondo.

E infine c’è il rapporto di fiducia.
Un’organizzazione che risponde in modo appropriato alle segnalazioni riceve le successive. Una che ignora o minaccia chi segnala smette di riceverne, e i problemi che la riguardano circolano comunque. Solo per altre vie.