Le norme del programma sono essenziali per qualsiasi VDP e devono essere elaborate con attenzione. Le norme del programma sono la prima cosa che i ricercatori nel campo della sicurezza vedono quando partecipano a una VDP. Definisce il tono del programma, definisce le aspettative e definisce il tuo impegno nei confronti dei ricercatori che scelgono di partecipare.
Come creare e ospitare le norme del programma
Segui le linee guida riportate di seguito per redigere la bozza delle norme del programma per la tua VDP. Le norme del programma hanno in genere solo 1-3 pagine e in genere includono i seguenti argomenti:
- Una promessa dei ricercatori
- Linee guida per l'esecuzione dei test
- L'ambito del programma
Le norme del programma devono essere disponibili per tutti i potenziali ricercatori. Se prevedi di lanciare privatamente la VDP solo per pochi ricercatori invitati, le norme del programma richiedono un tipo di controllo dell'accesso per renderlo disponibile ai ricercatori che hai invitato, ma limitato a tutti gli altri. I ricercatori devono anche inviare le segnalazioni, ad esempio un modulo web o un alias email collegato a un sistema di gestione delle richieste di assistenza per monitorare le segnalazioni. Tienilo presente durante la configurazione delle risorse online della VDP.
Le piattaforme di divulgazione di vulnerabilità di terze parti e bounty dei bug in genere offrono funzionalità quali:
- Un modo per creare, modificare e pubblicare una norma
- Controlli di accesso per creare un programma privato
- Invita automaticamente gli hacker a un ritmo confortevole
- Funzionalità della posta in arrivo per facilitare l'elaborazione dei report in arrivo
Le piattaforme di terze parti offrono anche una varietà di servizi di consulenza per semplificare il processo di creazione e lancio di una VDP. In genere le piattaforme e i servizi di consulenza di terze parti hanno un costo. Considera i costi e i vantaggi di utilizzare una terza parte rispetto alla creazione e alla gestione del programma internamente per determinare il percorso migliore per la tua organizzazione.
Per ulteriori fonti di ispirazione su cosa includere nelle norme del programma, leggi il documento "A Framework for a Vulnerability Disclosure Program for Online Systems" del Dipartimento di Giustizia degli Stati Uniti.
Stakeholder delle norme del programma
In sede di bozza delle norme del programma, pensa a come collaborare con i tuoi stakeholder. Vari team possono fornire input su considerazioni da integrare nei criteri.
| Stakeholder | considerazioni |
|---|---|
| Ambito legale |
|
| IT |
|
| Ingegneria |
|
| PR |
|
| Sicurezza |
|
Promessa dei ricercatori
La promessa del ricercatore spiega gli impegni dell'organizzazione nei confronti dei ricercatori partecipanti che agiscono in buona fede seguendo le linee guida per i test descritte nelle norme. Ad esempio, l'impegno a rispondere a tutti i report sulla sicurezza in arrivo entro un periodo di tempo specifico, oltre a comunicare le decisioni in merito a quali report di vulnerabilità vengono accettati e corretti.
Esempio:
<Name of your Organization> si impegna a collaborare con i ricercatori nella sicurezza per identificare e correggere le vulnerabilità nei nostri sistemi e servizi. A condizione che tu agisca in buona fede e rispetti le linee guida riportate nelle presenti norme, faremo del nostro meglio per rispettare quanto segue:- Fornisci una risposta iniziale al tuo report sulla vulnerabilità entro tre giorni lavorativi
- Stabilisci se accettiamo (intendiamo risolvere il problema) o rifiutiamo (identificando la tua segnalazione come falso positivo o rischio accettabile) la tua segnalazione sulla vulnerabilità entro dieci giorni lavorativi.
- Tieniti al corrente sui progressi verso la correzione dei report che accettiamo da te
L'adozione di un linguaggio safe Harbor nelle norme del programma aiuta ad assicurare ai ricercatori che non verranno intraprese azioni legali nei loro confronti per test effettuati con i tuoi sistemi, a condizione che i ricercatori agiscano in buona fede e rispettino tutte le linee guida spiegate nelle norme.
Linee guida per l'esecuzione dei test
Le linee guida per i test descrivono i test di sicurezza che rientrano nell'ambito della VDP, nonché i test che non rientrano nell'ambito e che dovrebbero essere evitati dai ricercatori. Se ci sono tipi specifici di vulnerabilità su cui vorresti che i ricercatori si concentrino, questa sezione è ideale per evidenziarli.
Esempio:
Quando esegui i test di sicurezza, rispetta le seguenti
linee guida:
- Esegui il test solo rispetto ai tuoi account e ai tuoi dati (ad es. crea account di prova). Se individui una vulnerabilità che potrebbe comportare l'accesso ai dati di altri utenti, contattaci prima di continuare.
- Se accedi inavvertitamente ai dati di altri utenti durante i tuoi test, ti invitiamo a comunicarcelo e a non archiviare tali dati.
- Non eseguire test che comportino condizioni di denial of service o peggioramento dei nostri servizi di produzione.
- L'ingegneria sociale non rientra nell'ambito di questo programma; non tentare di progettare socialmente la nostra organizzazione o i nostri utenti.
Siamo particolarmente interessati ai seguenti tipi di vulnerabilità e impatti:
- Esecuzione di codice da remoto
- XSS che comporta l'accesso a dati sensibili (ad es. informazioni sulla sessione)
- Iniezione SQL che dà accesso a funzionalità o dati sensibili
- Difetti della logica di business che comportano l'accesso a funzionalità o dati sensibili
Ci interessano di meno i seguenti tipi di vulnerabilità, che
hanno maggiori probabilità di
essere rifiutati come falsi positivi o rischi accettati:
- Mancanza dell'intestazione X-Frame-Options nelle pagine senza funzionalità di modifica dello stato
- Risultati dell'analisi automatica non verificati
- Problemi che è improbabile che siano sfruttabili e/o che non hanno un impatto realistico sulla sicurezza
Ambito
L'ambito definisce gli asset su cui i ricercatori possono eseguire test, nonché quelli che non sono considerati parte della VDP. L'ambito deve essere attentamente esaminato ed essere il più ampio possibile senza sovraccaricare il tuo team. Più hai intenzione di inserire nell'ambito, maggiori sono le probabilità di ottenere coinvolgimento da parte dei ricercatori della sicurezza. Tuttavia, non rendere l'ambito così esteso da impedire al team di tenere il passo con i report in arrivo. Inizia con alcuni asset nell'ambito. Espandi l'ambito man mano che ti fai un'idea del volume di report che riceverai. Prima di aprire la VDP al pubblico nel corso del tempo, cerca di fare in modo che tutto sia nell'ambito.
Per quanto riguarda la definizione dell'ambito di applicazione delle norme del programma, l'aggiunta di dettagli su ogni asset o area aiuterà i ricercatori della sicurezza a capire cosa è importante per te e dove concentrare i loro sforzi. Puoi anche includere suggerimenti su come eseguire i test in modo sicuro con i tuoi asset. Esempio:
| Asset | mail.example.com |
|---|---|
| Descrizione | Dominio principale che consente agli utenti di accedere alla propria email. |
| Vulnerabilità e effetti interessanti |
|
| Problemi che potrebbero essere rifiutati |
|
| Linee guida per l'esecuzione dei test | Effettua il test solo con gli account di tua proprietà o per i quali hai il consenso esplicito. Quando crei account di prova, includi "vdptest" in qualche punto del nome utente. Puoi creare account di prova all'indirizzo mail.example.com/new. |
Questa è un'analisi abbastanza dettagliata. In alternativa, puoi includere un semplice elenco di asset nell'ambito e fuori ambito:
Ambito
- mail.example.com
- example.com
Fuori ambito
- blog.example.com
Affidare la VDP
Prima di avviare una VDP, devi disporre di alcune risorse. Avrai bisogno di risorse per:
- Esame dei report sulle vulnerabilità in arrivo
- Comunicare con gli hacker
- Trovare i proprietari delle risorse e segnalare i bug
- Correggere i bug
- Gestione delle vulnerabilità / follow-up di correzione
Rivedi i principali stakeholder
Se non lo hai già fatto, rivedi le conversazioni con i principali stakeholder con cui hai discusso della tua VDP in precedenza per assicurarti che siano allineati alla tempistica del lancio della VDP, oltre a mettere in coda tutte le risorse necessarie per il lancio. Ad esempio, potresti voler collaborare con la leadership tecnica per assicurarti che i loro team siano pronti per un potenziale afflusso di bug di sicurezza su cui lavorare nelle prime settimane dopo il lancio. All'interno del tuo team di sicurezza, assicurati che coloro che classificano gli avvisi nei sistemi di rilevamento e risposta siano a conoscenza della data di lancio della VDP e valuta la possibilità di assegnare più tempo e risorse per l'inizio dei test. Dovrai anche creare un team per supportare le operazioni quotidiane della VDP.
Crea il tuo team
L'esecuzione di una VDP richiede una discreta quantità di lavoro operativo basato su interruzioni. Se provi a esaminare, convalidare tecnicamente e rispondere a ogni segnalazione di vulnerabilità ricevuta, oltre a segnalare ogni bug, tenere traccia degli stati e comunicare gli aggiornamenti ai ricercatori in autonomia, potresti burnout. Anche se non hai un grande team per la sicurezza, puoi trovare volontari con un'attenzione particolare alla sicurezza che ti aiutino a creare un team che ti aiuti a rendere operativa ed efficiente la tua VDP. Dovrai comunque avere un "proprietario" o un "leader" definito della VDP che sia responsabile ultimamente del successo della tua VDP, ma avrai anche bisogno di un team che lo supporti.
Crea un programma di servizio
Una volta che disponi delle risorse e sei disponibile ad aiutarti con la VDP, sviluppa una strategia per impostare una pianificazione di servizio. Puoi crearlo come preferisci, ma una rotazione settimanale è una pratica abbastanza comune. Quando sei in servizio per la settimana, è tua responsabilità:
- Triage: esamina i report sulle vulnerabilità in arrivo
- Convalidare tecnicamente la segnalazione e prendere una decisione di accettazione o rifiuto
- Comunica la tua decisione all'hacker che ha segnalato il problema
- Se necessario, chiedi maggiori informazioni all'hacker se non riesci a riprodurre il problema
- Se la vulnerabilità è valida, segnala un bug corretto al proprietario corretto
- Gestione delle vulnerabilità: fai avanti le vulnerabilità esistenti
- Esamina i bug segnalati nelle ultime settimane di servizio per assicurarti che la correzione stia procedendo in base ai tuoi standard di gravità e alle tempistiche di risoluzione.
- Utilizza i suggerimenti di ricerca dei proprietari per persuadere i proprietari a lavorare a questi bug
- Comunica: fornisci aggiornamenti ai ricercatori sulla sicurezza sui report esistenti
- I ricercatori possono chiedere proattivamente aggiornamenti sui report esistenti; controllali e rispondi
- Se una vulnerabilità viene risolta, comunicalo al ricercatore in modo che sappia che il suo duro lavoro ha portato a un cambiamento positivo nella tua organizzazione. Puoi persino includere un linguaggio del modello che chieda al ricercatore di farti sapere se ti è sfuggito qualcosa nella correzione o se la tua correzione potrebbe essere aggirata in qualche modo.
A seconda del numero di segnalazioni che ricevi, della complessità di tali rapporti, delle competenze e delle conoscenze del singolo in servizio, il tuo dovere può richiedere da alcune ore all'intera settimana. Ecco alcuni suggerimenti per una corretta rotazione in servizio:
- Assicurati che il tuo team sia pronto ad intervenire e a fornire assistenza durante le settimane particolarmente impegnative.
- Predisponi una buona procedura di trasferimento; se ci sono problemi che potrebbero richiedere l'attenzione immediata del prossimo incaricato, scrivi alcuni appunti di consegna o avvia una conversazione dal vivo alla fine della settimana.
- Crea una programmazione automatizzata per assicurarti che tutti sappiano quando sono in servizio. Può essere semplice, ad esempio creare voci di calendario ricorrenti per ogni persona.
- In particolare all'inizio della VDP, verifica con la persona in servizio che si ricordi che è la sua settimana e se ha bisogno di aiuto. Se disponi di risorse più giovani sulla rotazione, chiedi a loro di collaborare con più risorse senior per assicurarti che si sentano a proprio agio e possano porre domande man mano che diventano disponibili.
- Prepara una procedura flessibile per cambiare le settimane. Inevitabilmente qualcuno avrà un'emergenza e dovrà prendersi delle ferie durante la settimana oppure qualcuno si va in vacanza e così via. In questo caso, incoraggia il team a passare le settimane secondo necessità per rispettare gli impegni di tutti.
- Crea una "scheda di riferimento" di servizio che delinei i compiti da coprire, inclusa la documentazione su come farlo.
Decidi le differenze tra in-house e di terze parti
Finora la maggior parte delle indicazioni si è basata sulla creazione e sull'esecuzione della VDP internamente. Sono disponibili vari servizi e piattaforme di consulenza che possono assisterti nella creazione e nell'esecuzione di una VDP. Queste terze parti in genere hanno un costo, ma possono essere utili per indicarti come creare, avviare ed eseguire la VDP. Alcuni offrono anche servizi di classificazione per aiutarti a esaminare i report sulle vulnerabilità in arrivo per te, contribuendo a gestire la comunicazione con gli hacker e a riassegnare solo le segnalazioni valide al tuo team. La decisione di creare questo processo internamente o di utilizzare una piattaforma di terze parti dipenderà dai requisiti e dalle risorse disponibili. Se disponi di un budget elevato, ma non di un numero elevato di dipendenti, puoi fare affidamento su una terza parte per la gestione del programma. Se è il contrario, potrebbe valere la pena investire tempo a creare il tuo programma autonomamente.
Ricezione di rapporti
Se decidi di usare una piattaforma di terze parti, questa dovrebbe avere un modo per consentire agli hacker di inviarti segnalazioni direttamente. Se crei il programma internamente, dovrai farlo autonomamente. Potrebbe trattarsi di un indirizzo email che crea automaticamente un ticket o di un bug nel tuo Issue Tracker (ad es. security@example.com) oppure un modulo web con campi obbligatori a cui rimanda un link o la stessa pagina delle norme del programma. Qualunque sia la forma prescelta, questa è la migliore occasione per comunicare agli hacker qual è il formato con cui vorresti ricevere le segnalazioni. Ricordate che chiedere agli hacker di inviare segnalazioni in un determinato formato non è sempre garantito che lo facciano, ma chiedere agli hacker non è male. Ecco un esempio di cosa potresti chiedere in un modulo per l'invio di una segnalazione:
Titolo: [Aggiungi una descrizione di una riga del problema, ad esempio "XSS in
mail.example.com
si traduce in un furto di sessioni"]
1.
2.
3.
Scenario e impatto dell'attacco: [come potrebbe essere sfruttato tutto questo? Quale impatto sulla sicurezza ha questo
problema?]
Consiglio di correzione: [facoltativo, se hai qualche consiglio su come risolvere o risolvere questo problema, aggiungilo qui.]