Coordinated vulnerability disclosure

Divulgazione coordinata delle vulnerabilità (CVD)

Come segnalare, ricevere e coordinare le vulnerabilità di sicurezza, con esempi di policy.

La divulgazione coordinata delle vulnerabilità (Coordinated vulnerability disclosure, CVD) è un termine della sicurezza informatica. Descrive come le persone possono condividere segnalazioni su problemi di sicurezza. Alcuni esempi sono segnalazioni di bug, rischi di intrusione, avvisi di hacking, fughe di dati, violazioni di siti web, ecc.

Traduzioni: العربية, Български, বাংলা, Čeština, Cymraeg, Dansk, Deutsch, Ελληνικά, English, Español, Eesti, Euskara, فارسی, Suomi, Français, Gaeilge, Gàidhlig, ગુજરાતી, Hausa, עברית, हिन्दी, Hrvatski, Magyar, Bahasa Indonesia, Íslenska, Italiano, 日本語, 한국어, Lietuvių, Latviešu, Nederlands, Polski, Português, Română, Русский, Slovenčina, Slovenščina, Svenska, Kiswahili, ไทย, Türkçe, Українська, اردو, Tiếng Việt, 中文

Indice:

Policy:

Introduzione

Questo documento spiega la divulgazione coordinata delle vulnerabilità in modi che possano aiutare le persone a collaborare.

Obiettivi del documento:

  1. Aiutare le persone che scoprono problemi di sicurezza e vogliono segnalarli.

  2. Aiutare i rappresentanti delle aziende a comprendere le esigenze, gli obiettivi, le pratiche e i casi particolari della divulgazione responsabile.

  3. Includere nella cartella del repository esempi di policy di divulgazione coordinata delle vulnerabilità.

Accogliamo volentieri pull request, issue su GitHub o email a security@joelparkerhenderson.com.

Che cos'è la divulgazione coordinata delle vulnerabilità?

La divulgazione coordinata delle vulnerabilità descrive tre passi quando qualcuno scopre un problema di sicurezza (come un bug software) e vuole segnalarlo al produttore (come l'azienda che realizza il software).

Passi:

  1. Lo scopritore segnala il problema in privato e in buona fede al produttore.

  2. Il produttore cerca in buona fede di proteggere gli utenti e di risolvere il problema.

  3. Trascorso un determinato periodo di tempo, il problema di sicurezza viene reso pubblico.

Passo 1: segnalare il problema

Il passo 1 spetta allo scopritore: segnalare il problema in privato e in buona fede.

  • Bene: lo scopritore invia al produttore le informazioni pertinenti, ad esempio tramite email all'indirizzo email di sicurezza del produttore (tipicamente "security@example.com") o tramite un modulo su una pagina web del sito del produttore (tipicamente "https://www.example.com/security").

  • Male: pubblicare la segnalazione su un blog pubblico, avvisare i media, minacciare, tentare di vendere il problema di sicurezza agli hacker, ecc.

  • Suggerimento: lo scopritore può scegliere di restare anonimo; anche il produttore può scegliere di restare anonimo.

Se lo desideri, continua a seguire il problema.

  • Bene: aprire canali di comunicazione, fornire informazioni di aggiornamento o monitorare la situazione.

  • Male: dimenticarsi del problema.

  • Suggerimento: lo scopritore può scegliere se aiutare o meno, se restare in comunicazione o meno, e può anche cambiare l'accordo se le circostanze cambiano.

Se lo desideri, divulga il problema ad altri.

  • Bene: attendere il periodo di tempo stabilito e poi rendere pubblico il problema, ad esempio pubblicando le informazioni pertinenti su un sito di notizie sulla sicurezza, contattando ricercatori di sicurezza terzi pertinenti o annunciando il problema su qualsiasi social pubblico, ecc.

  • Male: non divulgare il problema ad altri, a meno che tu ritenga che ciò comporterebbe un rischio superiore a quello comparabile per te o per altri.

  • Suggerimento: se le circostanze cambiano, ad esempio se si scopre un rischio maggiore o uno sfruttamento attivo in the wild, lo scopritore può divulgare il problema ad altri prima.

Passo 2: garantire i contatti

Il passo 2 spetta al produttore: garantire che i contatti siano utilizzabili.

  • Bene: il produttore pubblica un indirizzo email di contatto per la sicurezza (per convenzione "security@example.com") e, idealmente, una chiave di cifratura email sicura.

  • Bene: il produttore pubblica una pagina web di contatto per la sicurezza (per convenzione "https://www.example.com/security") e, idealmente, rende la pagina facile da trovare, ad esempio tramite il footer del sito, la mappa del sito e la ricerca.

  • Male: il produttore non fornisce un indirizzo email né una pagina web, oppure non li rende facili da trovare.

Garantire le capacità del personale.

  • Bene: il produttore forma il personale di supporto su cosa fare se riceve una richiesta di sicurezza, ad esempio come rispondere con le informazioni di contatto o come inoltrare la richiesta al team interno giusto.

  • Bene: il produttore verifica periodicamente che le capacità del personale funzionino.

  • Male: il produttore non forma o non verifica.

Rispondere allo scopritore entro i tempi previsti.

  • Se lo scopritore non specifica una tempistica, usa un giorno lavorativo, perché è lo standard di settore e l'attuale buona pratica del settore.

  • Se lo scopritore pone domande, rispondi. Questo è particolarmente importante se lo scopritore chiede il permesso di effettuare test. Assicurati che tutte le risposte siano chiare e dirette.

Rispondere allo scopritore tramite un contatto di sicurezza autorizzato e/o un processo di sicurezza autorizzato.

  • Bene: una risposta da un indirizzo email specifico per la sicurezza, come "security@example.com".

  • Ad esempio, queste sono cattive pratiche: una risposta da un indirizzo email generico, come "help@example.com", o da chiunque non sia un professionista della sicurezza autorizzato.

Comunicare allo scopritore che il problema è riconosciuto come una segnalazione di sicurezza.

  • Bene: formulazioni specifiche per la sicurezza, come "Il nostro team di sicurezza ha ricevuto la tua segnalazione di divulgazione responsabile", oppure "Il nostro processo di sicurezza prevede questi passi successivi", oppure "Le tue informazioni sono ora nel nostro tracker di sicurezza con numero id XYZ", ecc.

  • Male: formulazioni generiche, come "Apprezziamo la tua attività", oppure "Prendiamo sul serio la sicurezza", formulazioni di scaricabarile come "Abbiamo inoltrato la tua email a un altro reparto", ecc.

Passo 3: agire in buona fede

Il passo 3 spetta allo scopritore e al produttore insieme: agire in buona fede.

Comprendere che la divulgazione coordinata delle vulnerabilità descrive un processo in buona fede.

  • L'obiettivo n. 1 è la buona fede nell'aiutare gli utenti a proteggersi dai rischi di sicurezza.

  • L'obiettivo n. 2 è la buona fede nel risolvere il problema di sicurezza.

  • Lo scopritore e/o il produttore possono scegliere in buona fede di coinvolgere altre persone esperte di sicurezza, ad esempio contattando altri ricercatori di sicurezza pertinenti per aiutare con il problema.

Comprendere che la divulgazione coordinata delle vulnerabilità non crea alcun obbligo.

  • Lo scopritore e/o il produttore possono ritirarsi in qualsiasi momento, per qualsiasi motivo, con o senza preavviso. È cortese tenere tutte le persone interessate informate e aggiornate, ma ciò non è sempre possibile, pratico o desiderabile.

  • La divulgazione coordinata delle vulnerabilità non crea alcun accordo legale. Se lo scopritore e il produttore hanno già un accordo legale, suggeriamo che tutte le persone coinvolte consultino gli avvocati appropriati; non usare questo documento come consulenza legale.

Comprendere che la divulgazione coordinata delle vulnerabilità mira a usare una buona comunicazione e a respingere le minacce.

  • La divulgazione coordinata delle vulnerabilità funziona al meglio quando tutte le persone coinvolte comprendono che l'obiettivo n. 1 è aiutare gli utenti a proteggersi dai rischi di sicurezza e l'obiettivo n. 2 è risolvere il problema di sicurezza.

  • La divulgazione coordinata delle vulnerabilità respinge qualsiasi tipo di minaccia di ritorsione, intimidazione, sospensione, revoca, estorsione, onere di dare seguito o colpevolizzazione della vittima.

Comprendere che la divulgazione coordinata delle vulnerabilità può significare cose diverse per persone diverse.

  • Lo scopritore e il produttore possono avere una comprensione diversa della divulgazione coordinata delle vulnerabilità. Queste comprensioni possono non coincidere. La buona fede include che tutte le persone coinvolte lo comprendano.

  • Alcuni produttori pubblicano policy di divulgazione coordinata delle vulnerabilità. Queste possono essere una guida utile. Se uno scopritore sceglie di usare un tipo diverso di divulgazione coordinata delle vulnerabilità, o ha una diversa comprensione della divulgazione responsabile, va assolutamente bene.

Comprendere che tipicamente lo scopritore sta facendo un favore all'editore.

  • Tipicamente lo scopritore non ha bisogno del permesso di nessuno per pubblicare le vulnerabilità.

  • Tipicamente le informazioni dello scopritore aiutano l'editore.

Verificare il successo

Dopo che il problema è stato risolto, il produttore deve verificare il successo.

  • Tutte le persone e i processi hanno gestito la divulgazione con successo? In caso affermativo, bene. In caso contrario, considera di svolgere ricerche post-intervento, come l'analisi delle cause radice (RCA), report post-mortem, diagrammi di Ishikawa o analisi causale basata sulla teoria dei sistemi (CAST).

  • Eventuali problemi ancora aperti sono stati classificati (triage) e tracciati?

  • Il produttore e lo scopritore comprendono entrambi cosa fare per eventuali passi successivi? Questo è particolarmente importante da fare correttamente nel caso in cui ci siano ulteriori divulgazioni coordinate di vulnerabilità.

Linee guida

Le linee guida per la divulgazione coordinata delle vulnerabilità possono provenire da molti ambiti, come esperti di etica, sostenitori legali, le ragionevoli aspettative del pubblico generale, ecc.

Se cerchi linee guida, potrebbero interessarti questi tre ambiti, tutti descritti di seguito.

  • Buon samaritano

  • Dovere di soccorso

  • Dovere di diligenza

Buon samaritano

Wikipedia: Good Samaritan law

Le leggi del buon samaritano offrono protezione legale alle persone che prestano un'assistenza ragionevole a chi è, o a chi ritengono sia, ferito, malato, in pericolo o altrimenti incapace. La protezione è pensata per ridurre l'esitazione dei presenti ad aiutare, per timore di essere citati in giudizio o perseguiti.

Dovere di soccorso

Wikipedia: Duty to rescue

Un dovere di soccorso è un concetto che descrive una circostanza in cui una parte può essere ritenuta responsabile per non essere venuta in soccorso di un'altra parte in pericolo. Un dovere di soccorso può avere aspetti morali e/o legali.

Dovere di diligenza

Wikipedia: Duty of care

Un dovere di diligenza è l'obbligo di attenersi a uno standard di ragionevole cura nel compiere qualsiasi atto che potrebbe prevedibilmente danneggiare altri. Un dovere di diligenza può avere aspetti morali e/o legali. Alcuni aspetti da considerare sono: la prevedibilità del danno o della lesione, la possibile entità del potenziale danno o lesione, l'importanza o il valore sociale dell'attività svolta dal convenuto, l'utilità della condotta per il convenuto, la fattibilità di una condotta alternativa, i costi e gli oneri associati alla condotta alternativa, l'utilità relativa della condotta alternativa e la sicurezza relativa della condotta alternativa.

Casi particolari

I nostri team di sicurezza hanno visto un'ampia gamma di casi particolari.

Li descriviamo qui per aiutare le persone a capire dove c'è un'ampia gamma di opinioni su ciò che può essere accettabile e ciò che può non esserlo. Raccomandiamo che tutte le persone coinvolte comunichino in buona fede su questi aspetti.

Accesso alle informazioni di altri utenti

Esempio: scopri che un URL contiene il tuo id utente, e rivela un bug, e credi di poter modificare l'URL per cambiare il tuo id utente con un id utente diverso.

  • È accettabile che lo scopritore lo faccia, ad esempio con il solo scopo di scoprire se riguarda anche altri utenti?

  • È più importante capire rapidamente l'ampiezza del rischio per tutti gli utenti, che proteggere un paio di utenti le cui informazioni potrebbero essere già visibili agli hacker?

  • È accettabile che lo scopritore lo faccia con tutti gli utenti che vuoi?

  • È accettabile che lo scopritore provi a contattare gli utenti per far loro sapere che sono interessati? È accettabile offrire suggerimenti per la mitigazione?

Negazione del servizio

Esempio: scopri un bug che sospende accidentalmente il tuo account, ad esempio attivando un blocco della password.

  • Questo è considerato un attacco di negazione del servizio?

Email non richieste

Esempio: provi a segnalare un problema di sicurezza a persone dell'azienda che ritieni pertinenti, e che scopri facendo ricerche su LinkedIn, Facebook, ecc., oppure usando convenzioni di denominazione come "webmaster@example.com" o "security@example.com".

  • È accettabile?

  • Questo è considerato un'email non richiesta?

  • Questo è considerato un'email non autorizzata?

Gruppi esclusi

Esempio: fai parte di un gruppo escluso, ad esempio sei minorenne, oppure sei in una lista di sanzioni, oppure sei in un paese presente in una lista di sanzioni.

  • È accettabile che tu faccia una segnalazione?

  • È accettabile segnalare in forma anonima?

  • È accettabile modificare deliberatamente informazioni potenzialmente identificative, ad esempio per sfuggire al gruppo escluso, e con l'obiettivo di aiutare la divulgazione a raggiungere le persone giuste?

Terze parti

Esempio: scopri che il software di un'azienda ha un bug che coinvolge una terza parte, come un'integrazione con un altro software o un altro sito web.

  • È accettabile che tu segnali tutte le informazioni che trovi a entrambe le parti?

  • È necessario fare due diverse divulgazioni responsabili, ad esempio una segnalazione a un'azienda e una segnalazione diversa all'azienda terza parte, con l'obiettivo di limitare le informazioni inviate a ciascuna azienda?

  • È accettabile che lo scopritore metta in contatto le aziende tra loro?

Software dannoso

Esempio: sei abbastanza esperto da poter scrivere un virus che ritieni possa aiutare gli utenti a proteggersi dal rischio di sicurezza, o a identificare se sono a rischio, o a risolvere il rischio di sicurezza.

  • È accettabile?

  • È accettabile che lo scopritore indirizzi gli utenti a software di questo tipo, e/o a guide o tutorial che descrivono come creare questo tipo di software?

Divulgazione coordinata delle vulnerabilità vs. divulgazione responsabile

La divulgazione coordinata delle vulnerabilità è il termine preferito.

  • L'aspetto più importante è il coordinamento tra scopritore e produttore.

La divulgazione responsabile (responsible disclosure) è un termine deprecato.

  • Le persone hanno opinioni diverse su cosa significhi essere responsabili. Ad esempio, alcune persone sostengono che sia responsabile per lo scopritore avvisare immediatamente il pubblico indipendentemente da qualsiasi interazione con il produttore, e irresponsabile fare divulgazione coordinata delle vulnerabilità perché nasconde informazioni al pubblico.

Tracciamento