Coordinated vulnerability disclosure

Active theme: Light

← Policy

NCSC.nl

1. Introduzione

La società è sempre più digitalizzata. Oggi quasi tutti i processi comportano a un certo punto l'uso di computer, dai telefoni cellulari a software specializzati. Sebbene questa evoluzione crei molte nuove opportunità, le vulnerabilità dei sistemi IT possono avere un forte impatto. Di conseguenza, la conoscenza di queste vulnerabilità dovrebbe essere gestita in modo efficace.

Un certo numero di organizzazioni ha iniziato a pubblicare policy su come segnalare le vulnerabilità all'inizio del 2013. Dopo aver consultato queste parti, il Centro nazionale per la sicurezza informatica (National Cyber Security Centre, NCSC) ha riassunto gli sviluppi sotto forma di "Linee guida per raggiungere una pratica di Responsible Disclosure" ("Leidraad om te komen tot een praktijk van Responsible Disclosure"; le "Linee guida"). Con questa policy le aziende indicano di essere aperte a ricevere segnalazioni esterne di vulnerabilità, descrivono le loro precondizioni e fanno promesse. Questo processo ha creato chiarezza e un ambiente piuttosto sicuro per le parti segnalanti per indagare e segnalare vulnerabilità senza commettere direttamente un reato penale. Alla riunione ad alto livello dell'UE sulla sicurezza informatica nel 2016, 29 organizzazioni hanno ribadito l'importanza di una policy per la gestione delle vulnerabilità firmando il Manifesto sulla divulgazione coordinata delle vulnerabilità (Coordinated Vulnerability Disclosure Manifesto)1 promosso dal CIO Platform Netherlands e da Rabobank in collaborazione con l'NCSC.

La divulgazione coordinata delle vulnerabilità (Coordinated Vulnerability Disclosure, CVD) si è dimostrata di grande importanza per le parti pubbliche e private. Esse dipendono fortemente dal funzionamento indisturbato dei sistemi informativi nella pratica quotidiana. Le segnalazioni di vulnerabilità nei loro sistemi hanno contribuito a migliorare la sicurezza e la continuità dei sistemi negli ultimi anni, da un lato correggendo le vulnerabilità e dall'altro contribuendo alla consapevolezza generale delle aziende olandesi sulla sicurezza IT.

Negli ultimi anni è diventato chiaro che le parti segnalanti sono disposte a operare entro le condizioni della policy CVD stabilita dalle organizzazioni. Le segnalazioni sono fatte direttamente o indirettamente alle organizzazioni dalle parti segnalanti. La pratica di divulgazione responsabile ha dimostrato che le parti segnalanti in buona fede e le organizzazioni vulnerabili sono riuscite a collaborare e quindi a compiere il passo successivo per aumentare la sicurezza delle reti e dei sistemi informativi.

Per questa revisione abbiamo nuovamente parlato con un gruppo ampio e diversificato di parti segnalanti, parti private e pubbliche, nonché con la Procura e la Polizia nazionale. Queste conversazioni hanno confermato la pratica attuale e hanno portato ad aggiunte e miglioramenti. Il nuovo punto di attenzione più importante è la comunicazione tra chi segnala la vulnerabilità e l'organizzazione, nonché con altre parti dopo che una vulnerabilità è stata risolta.

I capitoli seguenti trattano la definizione di CVD, gli elementi costitutivi di una policy CVD e il processo di comunicazione.

Nota a margine: le precedenti Linee guida usavano il termine "responsible disclosure", che era il termine comune per questa pratica all'epoca. Nel frattempo è diventato chiaro che questo termine pone troppa enfasi sulla responsabilità della parte segnalante, mentre il principio di base è che la parte segnalante e l'organizzazione potenzialmente vulnerabile dovrebbero essere partner alla pari nel dialogo. Questo sentimento è meglio espresso dal termine oggi comunemente usato "Coordinated Vulnerability Disclosure" (CVD), che è anche il nome usato negli standard ISO 29147 e 30111 su questo processo.

2. Vulnerabilità coordinata

Negli ultimi 30 anni sono stati usati vari metodi per aumentare la consapevolezza sulle vulnerabilità dei sistemi IT. Alcuni esempi sono:

  • "Full Disclosure", rendere una vulnerabilità completamente pubblica;

  • "Non-disclosure", vendere o usare una vulnerabilità in proprio;

  • "Coordinated Vulnerability Disclosure" (CVD), la divulgazione coordinata di una vulnerabilità.

Quest'ultima pratica è espressamente preferita.

La comunità IT ha mostrato grande disponibilità a condividere conoscenze ed esperienza. Cercare la collaborazione con questa comunità può quindi contribuire a migliorare la sicurezza complessiva dei sistemi.

L'obiettivo della divulgazione coordinata delle vulnerabilità

L'obiettivo della CVD è contribuire alla sicurezza dei sistemi IT condividendo la conoscenza sulle vulnerabilità. Nella CVD la conoscenza viene condivisa con una o più organizzazioni potenzialmente vulnerabili al fine di arrivare a una soluzione comune per la vulnerabilità trovata in collaborazione con la parte segnalante. È importante che le organizzazioni interessate abbiano tempo sufficiente per rimediare a qualsiasi vulnerabilità o proteggere i sistemi al fine di limitare o prevenire perdite o danni il più possibile. La pietra angolare del processo è la divulgazione della conoscenza sulle vulnerabilità dopo la risoluzione.

Nella CVD è essenziale che tutte le parti rispettino gli accordi su come segnalare una vulnerabilità e su come gestirla. È utile se un'organizzazione pubblica in anticipo le precondizioni, ad esempio quali sistemi rientrano nell'ambito e che tipo di ricerca può essere condotta. Un principio importante per queste precondizioni è che l'organizzazione, in linea di principio, non denuncerà la parte segnalante né intraprenderà altre azioni legali se l'indagine e la segnalazione sono condotte entro le condizioni stabilite. Queste Linee guida forniscono alle organizzazioni indicazioni per redigere la propria policy che incarni i principi della CVD.

Come indica il nome, è centrale nella CVD che l'organizzazione e la parte segnalante si coordinino tra loro. A tale riguardo, dovrebbero esserci il minor numero possibile di passaggi intermedi tra la persona che segnala la vulnerabilità e la persona all'interno dell'organizzazione responsabile della risoluzione del problema.

Può essere importante informare più parti contemporaneamente se una vulnerabilità riguarda molti sistemi. In tal caso, l'NCSC o altre parti della comunità della sicurezza possono sostenere il processo CVD con un ruolo di coordinamento.

3. Aree di responsabilità

Lo scopo di perseguire una policy CVD è che le parti segnalanti e l'organizzazione collaborino per ridurre le vulnerabilità nei sistemi IT. L'attuazione di questa policy dovrebbe essere vista come un complemento alle misure esistenti in materia di sicurezza delle informazioni. I vari attori hanno ciascuno il proprio ruolo e le proprie responsabilità. Questi sono spiegati più in dettaglio di seguito.

L'organizzazione che possiede/gestisce un sistema

L'organizzazione che possiede/gestisce o fornisce un sistema è la principale responsabile della sicurezza di tale sistema. In altre parole, l'organizzazione è anche responsabile del seguito da dare a una segnalazione di vulnerabilità.

L'organizzazione può scegliere di redigere la propria policy CVD usando queste Linee guida e di comunicare questa policy alle potenziali parti segnalanti. Pubblicando una policy CVD, le organizzazioni mostrano la loro disponibilità a ricevere informazioni sulle vulnerabilità.

Una parte che stabilisce una policy CVD può impegnarsi al principio di non presentare denuncia alla polizia se le regole che si applicano alla policy vengono rispettate.

Una volta che una parte segnalante ha segnalato una vulnerabilità, la responsabilità spetta all'organizzazione. È importante rendersi conto che la parte segnalante è spesso qualcuno esterno all'organizzazione. Questa parte non ha una visione diretta dei processi interni che possono essere attivati dopo la segnalazione di una vulnerabilità. Di conseguenza, le parti segnalanti apprezzeranno di essere informate sugli sviluppi nella risoluzione della vulnerabilità. Questa comunicazione continua è importante anche per creare le giuste aspettative sul seguito e sulla tempestività della soluzione.

La parte che segnala una vulnerabilità

In un modo o nell'altro, la parte segnalante è stata in grado di identificare una vulnerabilità e vuole contribuire alla sicurezza dei sistemi IT facendo risolvere questa vulnerabilità ed eventualmente rendendola pubblica in una fase successiva. La parte segnalante può aver scoperto qualcosa attraverso l'osservazione passiva o testando attivamente il sistema IT. Naturalmente, questa parte è responsabile delle proprie azioni e del modo in cui ha scoperto la vulnerabilità. È responsabilità della parte segnalante essere a conoscenza delle condizioni stabilite da un'organizzazione nella propria policy CVD. La maggior parte dei governi e delle aziende ha pubblicato le proprie policy CVD sui propri siti web.

Trovare vulnerabilità può tuttavia comportare la violazione della legge. Nel contesto della CVD, l'organizzazione e la parte segnalante possono concordare che non presenteranno denuncia per eventuali atti penalmente rilevanti. A tale riguardo, la policy CVD pubblicata dall'organizzazione è il principio guida. Le parti possono anche concordare che non verrà intrapresa alcuna azione civile.

Se vi è il sospetto che la legge sia stata violata dalla parte segnalante, una policy CVD può innanzitutto contribuire a evitare che il segnalatore venga denunciato alle autorità. Questa procedura dipende interamente dalle precondizioni della policy che un'organizzazione richiede a una parte segnalante di rispettare e dal fatto che tale rispetto sia stato ottenuto, potenzialmente con una corrispondente promessa di non presentare denuncia penale finché la parte opera entro le condizioni della policy. Se viene presentata una denuncia alla polizia, l'esistenza e il rispetto di una policy CVD sono una circostanza rilevante nei Paesi Bassi, di cui il Pubblico Ministero terrà conto nel decidere se avviare un'indagine penale e/o procedere penalmente. In linea di principio, la polizia e la Procura (OM) non avvieranno un'indagine penale se la parte segnalante ha chiaramente rispettato le regole della policy CVD dell'organizzazione in questione. Tuttavia, la Procura e la polizia possono indagare ulteriormente sul caso se vi sono indicazioni che la parte segnalante sia andata consapevolmente o inconsapevolmente troppo oltre nelle proprie azioni e/o non abbia rispettato la policy CVD. Sulla base di questa indagine, la Procura può decidere se procedere penalmente.

La Procura ha pubblicato una lettera di policy in cui tratta più specificamente gli aspetti importanti per arrivare a una decisione di indagare e/o procedere penalmente. Ad esempio, se le azioni della parte segnalante abbiano servito un importante interesse pubblico, se la parte abbia agito in modo sproporzionato e se la parte avrebbe forse potuto agire in un altro modo, meno drastico. La relativa lettera di policy elabora ulteriormente questi aspetti.2 La giurisprudenza rilevante dal 20133 mostra che questi aspetti sono presi in considerazione anche in tribunale se un'organizzazione non ha una policy CVD.

4. Elementi costitutivi del processo di divulgazione coordinata delle vulnerabilità

Di seguito sono forniti gli elementi costitutivi per dare forma al processo CVD per l'organizzazione, il segnalatore e l'NCSC.

L'organizzazione

Promuovere la CVD inizia con un'organizzazione che possiede sistemi IT o che fornisce un prodotto/sistema IT. Dopotutto, questa organizzazione è la principale responsabile della sicurezza delle informazioni di tali sistemi IT. Per collaborare efficacemente con varie parti per risolvere le vulnerabilità, un'organizzazione può decidere di redigere e pubblicare una policy CVD. Redigere la propria policy CVD consente all'organizzazione di dimostrare come gestisce le segnalazioni di vulnerabilità. In questo modo, un' organizzazione può anche dare forma al modo in cui desidera ricevere le notifiche. Un tale processo può essere organizzato come segue:

  • L'organizzazione stabilisce e pubblica una policy CVD.

  • In questa policy, l'organizzazione fornisce regole chiare per la ricerca che le parti segnalanti possono condurre, ad esempio quali tecniche sono consentite e quali sistemi rientrano o non rientrano nell'ambito.

  • L'organizzazione rende facile per una parte segnalante fare una segnalazione. Un' opzione è l'uso di un metodo di segnalazione standardizzato; ad esempio, uno specifico indirizzo email o un modulo online. Inoltre, l'organizzazione può decidere se accettare segnalazioni anonime.

  • L'organizzazione riserva capacità interna e predispone un processo per rispondere adeguatamente alle segnalazioni. È consigliabile predisporre un processo con cui le eventuali vulnerabilità trovate possano essere adeguatamente risolte. A tale riguardo, l'origine della segnalazione è irrilevante. La vulnerabilità può anche essere stata individuata da un dipendente interno o durante un test, ad esempio.

  • L'esperienza pratica mostra che vi sarà un maggiore interesse a segnalare vulnerabilità all'organizzazione dopo la pubblicazione iniziale di una policy CVD. L'organizzazione dovrebbe tenerne conto nel pianificare la capacità (aggiuntiva).

  • Quando l'organizzazione riceve la segnalazione di vulnerabilità, si assicura che la segnalazione raggiunga il prima possibile il reparto più adatto a valutarla e gestirla.

  • L'organizzazione invia una conferma di ricezione della segnalazione alla parte segnalante, preferibilmente firmata digitalmente per sottolineare la priorità.

  • Successivamente, l'organizzazione si consulterà con la parte segnalante per stabilire il periodo entro il quale avverrà un'eventuale pubblicazione. Questo periodo dipenderà fortemente dalla natura della vulnerabilità e dal tipo di sistema.

  • Come linea guida, per le vulnerabilità del software si usa spesso un periodo di circa 60 giorni. Risolvere le vulnerabilità dell'hardware è più difficile; può essere usata una linea guida di 6 mesi.

  • Può essere opportuno estendere o ridurre questo periodo di comune accordo a seconda di quanti o pochi sistemi IT dipendono dal sistema per cui è stata segnalata la vulnerabilità o se la vulnerabilità è più facile o più difficile da risolvere.

  • Una vulnerabilità può rivelarsi difficile o impossibile da risolvere, oppure possono esserci costi elevati per risolverla. In tali casi, l'organizzazione può concordare di considerare la vulnerabilità un rischio accettato e di non rimediarvi, eventualmente in consultazione con la parte segnalante.

  • L'organizzazione terrà informata la parte segnalante sullo sviluppo del processo.

  • Inoltre, l'organizzazione può offrire che la parte segnalante sia riconosciuta pubblicamente per aver pubblicato la vulnerabilità. È anche possibile optare per una divulgazione congiunta verso l'esterno.

  • È preferibile premiare la parte segnalante per aver segnalato vulnerabilità nei sistemi se la parte ha rispettato le regole della policy CVD. L' importo della ricompensa può dipendere dalla qualità della segnalazione. Premiare la parte segnalante può creare un rapporto migliore tra tale parte e l'organizzazione, oltre ad aumentare la disponibilità delle persone a fare nuove segnalazioni in conformità con la policy CVD.

  • In consultazione con la parte segnalante, l'organizzazione può concordare di informare la più ampia comunità IT sulla vulnerabilità se è plausibile che la vulnerabilità sia presente anche altrove.

  • Nella propria policy CVD, l'organizzazione può impegnarsi al principio di non presentare denuncia alla polizia se la parte segnalante ha rispettato le regole delineate nella policy.

La parte segnalante

La parte segnalante è la chiave per un processo CVD di successo. In un modo o nell'altro, questa parte è stata in grado di identificare una vulnerabilità e vuole contribuire alla sicurezza dei sistemi IT facendo risolvere questa vulnerabilità da un'organizzazione e rendendola pubblica. In tal modo, le parti segnalanti riconoscono di poter dare un importante contributo alla società rivelando le vulnerabilità in modo coordinato. Per ottenere un processo CVD di successo, i seguenti elementi costitutivi sono importanti per la parte segnalante:

  • La parte segnalante è responsabile delle proprie azioni e deve osservare i principi di proporzionalità e sussidiarietà quando indaga e segnala vulnerabilità. In altre parole, la parte segnalante non dovrebbe fare più di quanto necessario per dimostrare la vulnerabilità e dovrebbe sempre segnalare prima la vulnerabilità al proprietario del sistema/delle informazioni.

  • La parte segnalante deve segnalare il problema il prima possibile per evitare che parti malintenzionate scoprano la vulnerabilità e ne approfittino.

  • La parte segnalante deve fare la segnalazione all'organizzazione in modo riservato per impedire ad altri di accedere a queste informazioni.

  • La parte segnalante non può far dipendere la presentazione di una segnalazione o l'ulteriore fornitura di informazioni dalla ricompensa. L'iniziativa di concedere una ricompensa in caso di segnalazione spetta all'organizzazione ricevente, che può delineare precondizioni nella propria policy pubblicata.

  • La parte segnalante e l'organizzazione stipulano accordi chiari sulla divulgazione della vulnerabilità. Se è coinvolta più di un'organizzazione, il principio di base è che le vulnerabilità possono essere pubblicate solo se tutte le organizzazioni vi acconsentono. È consigliabile stipulare questi accordi in una fase iniziale.

  • La parte segnalante e l'organizzazione coinvolta possono stipulare accordi per informare la più ampia comunità IT. Ad esempio, questa situazione può applicarsi a una vulnerabilità (già nota o meno) che si sa essere presente in più di una località. Il Centro nazionale per la sicurezza informatica (NCSC) può essere coinvolto in questo processo per supportare i gruppi target del governo centrale e delle infrastrutture critiche o per informare più parti in caso di una vulnerabilità che riguarda molti sistemi.

L'NCSC

Il processo CVD è principalmente una questione per le organizzazioni e le parti segnalanti. Ciononostante, l'NCSC incoraggerà l'uso di un processo CVD. In consultazione con la parte segnalante e l'organizzazione, l'NCSC può anche essere coinvolto nella condivisione di informazioni sulla vulnerabilità con la propria utenza al fine di limitare ulteriori rischi di sicurezza derivanti dalla vulnerabilità.

Se la segnalazione della vulnerabilità non procede come la parte segnalante si aspetta, o se preferisce non segnalare la vulnerabilità direttamente all'organizzazione, può contattare l'NCSC.4 In questo caso, l'NCSC può agire da intermediario ove necessario.

Il proprietario del sistema IT è in ogni momento responsabile della sicurezza del sistema. L'NCSC non può costringere il proprietario del sistema a rimediare a una vulnerabilità, né può garantire che il proprietario non intraprenderà azioni legali contro la parte segnalante. Di conseguenza, la parte segnalante deve tenere conto degli elementi costitutivi sopra citati per le organizzazioni e le parti segnalanti quando cerca e segnala una vulnerabilità. Una parte segnalante può aspettarsi che l'NCSC faccia il possibile per far risolvere la vulnerabilità e tratti la segnalazione in modo riservato. L'NCSC non condivide alcun dato personale a meno che non sia legalmente obbligato a farlo.

Se possibile, l'NCSC userà le informazioni ottenute sulle vulnerabilità in consultazione con le organizzazioni e le parti segnalanti per condividere ulteriormente la conoscenza con la comunità IT. Ad esempio, può farlo pubblicando parte delle informazioni, scrivendo o aggiornando una scheda informativa (fact sheet) o un white paper, oppure informando organizzazioni specifiche.

  • A seconda dell'organizzazione interessata e della natura della vulnerabilità accertata, l'NCSC si adopererà per portare la vulnerabilità all' attenzione dell'organizzazione interessata. Tuttavia, il proprietario del sistema IT in questione rimane responsabile del sistema.

  • Ove possibile e necessario, l'NCSC fornirà all'organizzazione interessata consigli su come rimediare alla vulnerabilità.

  • L'NCSC tratterà le segnalazioni in modo riservato e non condividerà i dati personali delle parti segnalanti o dell'organizzazione ricevente senza consenso, a meno che ciò non derivi da un obbligo di legge.

  • Ove possibile, l'NCSC terrà informata la parte segnalante sugli sviluppi nei contatti con l'organizzazione e nella risoluzione della vulnerabilità.

  • Nei casi in cui una segnalazione venga fatta all'NCSC, l'NCSC cercherà di mettere in contatto la parte segnalante o potenziale parte segnalante e l'organizzazione.

Se una parte segnalante ha trovato una vulnerabilità in un prodotto software o una vulnerabilità che riguarda molti sistemi diversi, ad esempio, la parte segnalante può chiedere all'NCSC di coordinare la risoluzione e la divulgazione della vulnerabilità.

Insieme alla parte segnalante, ai partner, agli sviluppatori e/o agli sviluppatori di software e ad altri team di sicurezza, l'NCSC aiuterà ad analizzare, risolvere o far risolvere, coordinare e divulgare la vulnerabilità in modo controllato. Tutto questo processo si svolge in stretta consultazione con la parte segnalante che ha trovato la vulnerabilità.

Una policy CVD cerca di trovare un equilibrio tra l'importanza di divulgare le vulnerabilità il più rapidamente possibile, in modo da poter adottare misure, e l'importanza che sia gli sviluppatori sia i fornitori abbiano tempo sufficiente per rimediare alla vulnerabilità. Per questo processo, l'NCSC usa un termine standard di 60 giorni tra la segnalazione e la divulgazione pubblica. Tuttavia, possono esserci circostanze in cui si può decidere di estendere o ridurre questo periodo.

L'NCSC condividerà informazioni sulla vulnerabilità con terze parti solo dopo essersi consultato con la parte segnalante. È essenziale in questo contesto che l'NCSC collabori e quindi condivida informazioni sulla vulnerabilità con le parti interessate così da divulgare una vulnerabilità in modo coordinato. In tal modo l'NCSC garantirà che le parti giuste possano lavorare per rimediare alla vulnerabilità, contribuirà a limitare eventuali perdite o danni e contribuirà ad attirare l'attenzione sulla vulnerabilità trovata.

5. Comunicazione e processo di divulgazione

Cinque anni di pratica hanno dimostrato che una comunicazione chiara è la pietra angolare di un processo CVD di successo. Ci sono punti di attenzione prima, durante e dopo il processo CVD.

Comunicazione sul processo di divulgazione

Pubblicare una policy CVD è un primo passo nella comunicazione sul processo. Pubblicando una policy pubblicamente, le parti segnalanti sono invitate a notificare all'organizzazione eventuali vulnerabilità trovate.

Da un lato, l'organizzazione può stabilire condizioni per la ricerca svolta per scoprire vulnerabilità e per il modo in cui viene cercato il contatto. Dall' altro lato, l'organizzazione può impegnarsi al principio di non presentare denuncia alla polizia se le regole della policy vengono rispettate. Questo approccio protegge la posizione della parte segnalante.

Una policy CVD può essere modificata o aggiornata in un secondo momento. È importante essere chiari sulle modifiche a tale riguardo. Le parti segnalanti hanno interesse a sapere cosa è stato modificato e quando. Ad esempio, le modifiche possono essere chiarite includendo una data di pubblicazione all'inizio della policy CVD, descrivendo un riepilogo delle modifiche sotto la policy CVD o mantenendo un archivio con le vecchie versioni della policy CVD.

La policy CVD può fornire linee guida su come comunicare durante il processo, ad esempio indicando aggiornamenti regolari via email o tramite un portale web. Inoltre, la policy CVD può descrivere come un segnalatore può essere riconosciuto menzionandolo in occasione di un aggiornamento, con l'ammissione a una hall of fame o con qualsiasi altra forma di ricompensa.

Comunicazione durante il processo di divulgazione

Una parte segnalante avvia un processo CVD inviando un messaggio all' organizzazione. In questo messaggio, la parte segnalante fornisce una descrizione chiara della vulnerabilità scoperta. Elementi importanti sono l'indirizzo IP o l'URL del sistema interessato e i passaggi necessari per riprodurre la vulnerabilità.

È importante che l'organizzazione comunichi chiaramente con la parte segnalante in modo che le aspettative sul processo siano chiare.

Può già farlo inviando una conferma di ricezione (automatica o altrimenti) che contenga un'indicazione del termine entro il quale verrà inviata una prima o successiva risposta di merito.

È anche possibile lasciare aperto questo periodo e dare un'indicazione iniziale del termine dopo aver valutato il contenuto della segnalazione. È consigliabile essere chiari il prima possibile sul periodo entro il quale è possibile raggiungere una soluzione. In questo modo il segnalatore sa quando può aspettarsi un esito.

In alcuni casi può essere che una data di pubblicazione sia già chiara alla parte segnalante; ad esempio, a causa di una presentazione a una conferenza o perché la parte segnalante ha fissato un proprio termine. In questo caso, è comunque importante che la parte segnalante comunichi chiaramente questa tempistica, la indichi il prima possibile e sia chiara sulla possibilità/impossibilità di rinviare questa data.

Una parte segnalante è spesso qualcuno esterno all'organizzazione, che non ha alcuna visione dei processi interni che possono essere attivati da una segnalazione. Le organizzazioni possono tenere informata la parte segnalante sugli sviluppi del processo tramite aggiornamenti regolari. Questo approccio chiarisce a una parte segnalante che si sta lavorando a una soluzione. Ove necessario, un'organizzazione può richiedere chiarimenti o testare una soluzione durante il processo.

Se un'organizzazione non è in grado di rispettare la scadenza iniziale di risoluzione, se ne può discutere con il segnalatore per rinviarla. Una comunicazione regolare può rendere chiara questa situazione a un segnalatore in una fase più precoce.

L'intenzione principale della CVD è mitigare la vulnerabilità, ma la "full disclosure" della vulnerabilità è sempre un'opzione per una parte segnalante se ritiene che il processo richiederà troppo tempo. Questa misura è il proverbiale "big stick" (bastone grosso) a disposizione della parte segnalante. Naturalmente, questa situazione deve essere evitata il più possibile.

Comunicazione dopo il processo di divulgazione

Esistono molte possibili ragioni per cui una parte segnalante potrebbe cercare vulnerabilità e poi segnalarle alle organizzazioni tramite il processo CVD. Per un gran numero di parti segnalanti, un incentivo importante è il riconoscimento (pubblico).

Le parti segnalanti ricevono riconoscimento pubblico tramite un ringraziamento in un aggiornamento o l'inserimento in una hall of fame. Tuttavia, la necessità di riconoscimento pubblico non vale per tutte le parti segnalanti; alcune in effetti non vogliono essere note al pubblico. In caso di comunicazione da parte dell'organizzazione, è quindi consigliabile ottenere il consenso della parte segnalante per nominarla.

Inoltre, le parti segnalanti possono anche decidere di comunicare su una segnalazione dopo il completamento del processo CVD. Ad esempio, la parte segnalante può descrivere il processo di scoperta o avvertire altri della vulnerabilità. Un segnalatore può decidere di sottoporre la pubblicazione a un'organizzazione a scopo informativo. Poiché il processo CVD è in linea di principio concluso dopo la rimozione della vulnerabilità, la parte segnalante è successivamente libera di comunicarne, a meno che non vengano presi accordi aggiuntivi nella policy o durante il processo.

Elenco

Comunicazione sul processo di divulgazione

  • Pubblicazione della policy CVD sul sito web

  • Essere chiari sulle restrizioni (vedi il capitolo 6 per i diversi approcci)

  • Restrizioni sui metodi di indagine

  • Linee guida sulla comunicazione

  • Linee guida sulle possibili ricompense: hall of fame, ricompensa finanziaria, t-shirt, ecc.

  • Essere chiari su eventuali aggiornamenti della policy CVD, compresa la data delle modifiche

Comunicazione durante il processo di divulgazione

  • Il segnalatore contatta l'organizzazione riguardo a una vulnerabilità scoperta.

  • L'organizzazione gestisce le aspettative, come il tempo di risposta per una prima risposta tecnica

  • L'organizzazione e il segnalatore si danno reciprocamente chiarezza sul periodo di risoluzione previsto

  • L'organizzazione fornisce frequentemente un aggiornamento (di processo)

  • Ove necessario, il segnalatore e l'organizzazione discutono di contattare altre organizzazioni pertinenti

Comunicazione dopo il processo di divulgazione

  • Discutere il riconoscimento (pubblico) e la ricompensa del segnalatore

  • Concordare come verranno pubblicate le informazioni sulla vulnerabilità, ad esempio la fase di ricerca o l'informazione di altre organizzazioni

6. Esempi di policy di divulgazione coordinata delle vulnerabilità

Esistono molte diverse forme di testi di policy sulla divulgazione coordinata delle vulnerabilità. Poiché la policy CVD pubblicata funge da segnaletica per le potenziali parti segnalanti, assicurati che la forma di questa policy sia in linea con la policy e la strategia dell'organizzazione.

I seguenti elementi sono importanti in una policy CVD:

  • metodo di contatto per una comunicazione sicura;

  • precondizioni per le parti segnalanti;

  • aspettative chiare sulla gestione di una segnalazione;

  • metodo per premiare una segnalazione;

  • numero di versione e data dell'ultima revisione.

Di seguito sono riportati tre esempi: molte organizzazioni nei Paesi Bassi hanno attinto all'esempio di base di ResponsibleDisclosure.nl. Altre organizzazioni includono precondizioni aggiuntive, vedi la policy di Fox IT. Altre ancora applicano un formato più libero per allinearsi al proprio pubblico di destinazione, vedi la policy di Bits of Freedom.

Esempio: ResponsibleDisclosure.nl

Questo testo è scritto da Floor Terra ed è pubblicato con licenza Creative Commons Attribution 3.0 Unported.

Presso Acme Corporation consideriamo la sicurezza dei nostri sistemi una priorità assoluta. Ma per quanto impegno dedichiamo alla sicurezza dei sistemi, possono comunque esserci vulnerabilità.

Se scopri una vulnerabilità, vorremmo saperlo per poter adottare misure per risolverla il più rapidamente possibile.

Vorremmo chiederti di aiutarci a proteggere meglio i nostri clienti e i nostri sistemi.

Ti chiediamo di fare quanto segue:

  • Invia le tue scoperte via email a cert@example.com. Cifra le tue scoperte usando la nostra chiave PGP per evitare che queste informazioni critiche finiscano nelle mani sbagliate,

  • Non approfittare della vulnerabilità o del problema che hai scoperto, ad esempio scaricando più dati del necessario per dimostrare la vulnerabilità o eliminando o modificando i dati di altre persone,

  • Non rivelare il problema ad altri finché non sarà stato risolto,

  • Non usare attacchi alla sicurezza fisica, ingegneria sociale, denial of service distribuito, spam o applicazioni di terze parti, e

  • Fornisci informazioni sufficienti per riprodurre il problema, così potremo risolverlo il più rapidamente possibile. Di solito l'indirizzo IP o l'URL del sistema interessato e una descrizione della vulnerabilità saranno sufficienti, ma vulnerabilità complesse possono richiedere ulteriori spiegazioni.

Cosa promettiamo:

  • Risponderemo alla tua segnalazione entro 3 giorni lavorativi con la nostra valutazione della segnalazione e una data prevista di risoluzione,

  • Se hai seguito le istruzioni di cui sopra, non intraprenderemo alcuna azione legale nei tuoi confronti in relazione alla segnalazione,

  • Tratteremo la tua segnalazione con la massima riservatezza e non trasmetteremo i tuoi dati personali a terzi senza il tuo permesso,

  • Ti terremo informato sui progressi verso la risoluzione del problema,

  • Nelle informazioni pubbliche relative al problema segnalato, indicheremo il tuo nome come scopritore del problema (a meno che tu non desideri diversamente), e

  • Come segno di gratitudine per il tuo aiuto, offriamo una ricompensa per ogni segnalazione di un problema di sicurezza che non ci era ancora noto. L'importo della ricompensa sarà determinato in base alla gravità della falla e alla qualità della segnalazione. La ricompensa minima sarà un buono regalo da 50 €.

Ci impegniamo a risolvere tutti i problemi il più rapidamente possibile e vorremmo svolgere un ruolo attivo nella pubblicazione finale sul problema dopo che sarà stato risolto.

Esempio: Fox-IT

In Fox-IT consideriamo la sicurezza dei nostri sistemi, della nostra rete e dei nostri prodotti della massima importanza. Nonostante la grande attenzione che dedichiamo alla sicurezza, possono comunque rimanere dei punti deboli. Se hai trovato una debolezza di questo tipo, vorremmo saperlo il prima possibile in modo da poter adottare le misure appropriate il più rapidamente possibile.

I punti deboli possono essere scoperti in due modi: puoi imbatterti per caso in qualcosa durante il normale utilizzo di un ambiente digitale, oppure puoi fare esplicitamente del tuo meglio per trovarli.

La nostra policy di divulgazione responsabile non è un invito a scansionare attivamente la nostra rete aziendale per scoprire punti deboli. Monitoriamo noi stessi la nostra rete aziendale. Ciò significa che c'è un'alta probabilità che una scansione venga rilevata, e che il nostro Security Operation Center (SOC) svolga un'indagine, con possibili costi inutili. Sei tuttavia invitato a cercare attivamente vulnerabilità nei nostri prodotti in un ambiente offline non di produzione e a segnalarci le tue scoperte. La nostra responsabilità verso i clienti significa che la nostra intenzione non è incoraggiare tentativi di hacking sulla loro infrastruttura; tuttavia, vorremmo avere tue notizie il prima possibile se vengono trovate vulnerabilità, in modo da poterle risolvere adeguatamente.

Vorremmo collaborare con te per essere in grado di proteggere meglio i nostri clienti e i nostri sistemi.

Ti chiediamo di:

  • Inviare le tue scoperte via email il prima possibile a security-alert@fox-it.com.

  • Non abusare della vulnerabilità; ad esempio, scaricando, modificando o eliminando dati. Prenderemo sempre sul serio la tua segnalazione e indagheremo su qualsiasi sospetto di vulnerabilità, anche senza prove.

  • Non condividere il problema con altri finché non sarà stato risolto.

  • Non ricorrere ad attacchi alla sicurezza fisica, all'ingegneria sociale o a strumenti di hacking, come gli scanner di vulnerabilità.

  • Fornire informazioni adeguate affinché il problema possa essere riprodotto, così da poterlo risolvere il più rapidamente possibile. Di solito l'indirizzo IP o l'URL del sistema interessato e una descrizione della vulnerabilità sono sufficienti, anche se per vulnerabilità più complesse potrebbero essere necessarie ulteriori informazioni.

Cosa promettiamo:

  • Risponderemo alla tua segnalazione entro tre giorni lavorativi, con la nostra valutazione della segnalazione e una data prevista di risoluzione.

  • Tratteremo la tua segnalazione in modo riservato e non condivideremo le tue informazioni personali con terze parti senza il tuo permesso. Un'eccezione a ciò sono la polizia e la magistratura in caso di azione penale o se le informazioni vengono richieste.

  • Ti terremo informato sui progressi della soluzione del problema.

  • Nella comunicazione sul problema segnalato, indicheremo il tuo nome come parte che ha scoperto il problema, se lo desideri.

  • Purtroppo non è possibile garantire in anticipo che non verrà intrapresa alcuna azione legale nei tuoi confronti. Speriamo di poter considerare ogni situazione individualmente. Ci riteniamo moralmente obbligati a denunciarti se sospettiamo che la debolezza o i dati vengano utilizzati in modo abusivo, o che tu abbia condiviso la conoscenza della debolezza con altri. Puoi stare tranquillo che una scoperta accidentale nel nostro ambiente online non porterà a un'azione penale.

  • Come ringraziamento per il tuo aiuto, offriamo una ricompensa per ogni segnalazione di un problema di sicurezza a noi sconosciuto. Determiniamo il valore della ricompensa sulla base della gravità della violazione e della qualità della segnalazione.

Ci impegniamo a risolvere tutti i problemi il più rapidamente possibile, a tenere informate tutte le parti coinvolte e vorremmo essere coinvolti in qualsiasi pubblicazione sul problema una volta risolto.

Esempio: Bits of Freedom

La nostra dipendenza dall'infrastruttura digitale è in continuo aumento. Questo vale per la società nel suo complesso, ma anche per noi stessi. È quindi nostra opinione che i governi e le organizzazioni (inclusa la nostra) debbano impegnarsi con decisione per mettere in sicurezza la nostra infrastruttura digitale. Siamo consapevoli che, nonostante le nostre migliori intenzioni e la massima cura, possono esistere vulnerabilità nei nostri sistemi. Se ti capita di trovare una di queste debolezze, ci farebbe piacere sentirti, così da poter risolvere il problema.

Cosa ci aspettiamo da te

  • Quando indaghi su uno dei nostri sistemi, tieni presente la proporzionalità dell'attacco. Non c'è bisogno di dimostrare che se sottoponi il nostro sito web al più grande attacco DDoS della storia di internet, il sito può diventare irraggiungibile. Lo sappiamo. Capiamo anche che se guidi un bulldozer nel nostro ufficio, probabilmente riuscirai ad afferrare uno dei nostri laptop.

  • Questo principio di proporzionalità è rilevante anche quando si dimostra la vulnerabilità stessa. Non dovresti ispezionare o modificare più dati di quanto strettamente necessario per confermare la validità della tua scoperta. Ad esempio, se riesci a modificare la nostra homepage, aggiungi semplicemente una singola parola non controversa invece di impossessarti dell'intera pagina. Se riesci a ottenere accesso a un database, è sufficiente mostrarci un elenco delle tabelle presenti, o magari il primo record di una di queste tabelle.

  • Una vulnerabilità in uno dei nostri sistemi dovrebbe essere segnalata il prima possibile inviando un'email a security@bof.nl. Preferibilmente cifreresti il tuo messaggio usando OpenPGP. Fornisci informazioni sufficienti affinché possiamo riprodurre e indagare il problema.

  • La chiave pubblica OpenPGP per security@bof.nl

  • Non condividerai la tua conoscenza della vulnerabilità con altre parti finché non avremo affrontato il problema e saremo ancora entro un periodo di tempo ragionevole da quando hai segnalato il problema.

  • Eliminerai tutte le informazioni riservate che hai ottenuto durante le tue indagini non appena avremo risolto la vulnerabilità.

Cosa puoi aspettarti da noi

  • Risponderemo alla tua segnalazione entro tre giorni in modo dettagliato. Includeremo una stima del tempo di cui avremo bisogno per affrontare il problema. Naturalmente, ti terremo regolarmente aggiornato sui nostri progressi.

  • Risolveremo la vulnerabilità il prima possibile. Anche qui la proporzionalità è importante: il tempo necessario per correggere una vulnerabilità dipende da diversi fattori, tra cui la gravità e la complessità del problema in questione.

  • Se segui le linee guida qui esposte, non intraprenderemo azioni legali nei tuoi confronti in relazione alla tua segnalazione.

  • Per noi è importante riconoscerti il merito di ciò che hai fatto - se lo desideri. Menzioneremo il tuo nome in una pubblicazione sulla vulnerabilità solo se sei d'accordo.

  • Come ringraziamento per averci aiutato a proteggere meglio i nostri sistemi, vorremmo premiare ogni segnalazione di una vulnerabilità che ci era sconosciuta in quel momento. La ricompensa dipenderà dalla gravità della vulnerabilità e dalla qualità della segnalazione.

  • Se dovessi trovare una vulnerabilità in un software di terze parti che utilizziamo e tale vulnerabilità è coperta da un programma di bug bounty, non cercheremo di rivendicare questa ricompensa; dovresti farlo tu.