preparazione

In questa sezione, discuteremo in dettaglio come preparare la tua organizzazione al lancio e alla gestione di un programma di divulgazione delle vulnerabilità efficace, inclusi consigli pratici su come colmare le lacune che hai identificato.

Ricerca di bug

Integrare il tuo programma di sicurezza esistente con ricercatori esterni in materia di sicurezza è un ottimo modo per trovare problemi complessi e oscurare le vulnerabilità. Tuttavia, l'utilizzo di una VDP per trovare problemi di sicurezza di base che potrebbero essere rilevati internamente rappresenta uno spreco di risorse.

Gestione delle attività

Quando si tratta di individuare i bug, l'unico modo per capire da dove iniziare è avere una buona idea delle risorse disponibili. Puoi acquistare un centinaio di strumenti di sicurezza, ma non farà alcuna differenza se i team stanno installando applicazioni, sistemi e servizi ad hoc a tua insaputa, soprattutto se non hai un modo per scoprire ed eseguire valutazioni della sicurezza su questi asset. Verifica con le persone e i team responsabili della creazione di nuove applicazioni, sistemi e servizi per vedere se dispongono di un processo per la creazione e il mantenimento di un inventario di ciò che viene generato e dei relativi proprietari. Se non è disponibile un processo attuale, questa è un'ottima opportunità per collaborare con questi team per crearne uno. Comprendere gli asset della tua organizzazione è il punto di partenza migliore per identificare la tua superficie di attacco. Nell'ambito di questo processo, il team di sicurezza dovrebbe essere coinvolto nello sviluppo di una nuova implementazione dell'infrastruttura per fornire revisioni della sicurezza. È buona norma disporre di un inventario completo di asset e proprietari. Questo tipo di inventario è utile quando si applicano nuove patch che richiedono l'arresto temporaneo di determinati sistemi. Fornisce una roadmap delle persone o dei team che devono essere informati e quali sistemi sono interessati. Una solida procedura di gestione delle risorse garantisce che i proprietari vengano identificati nelle prime fasi del processo, aggiornati regolarmente e che tutti i sistemi dell'organizzazione funzionino come previsto.

Oltre a una gestione proattiva degli asset, valuta quali misure reattive puoi implementare per identificare gli asset che appartengono alla tua organizzazione, ma che sono sfuggiti ai tuoi processi standardizzati di gestione degli asset. Ciò può includere l'utilizzo degli stessi processi di "ricognizione" utilizzati dai ricercatori della sicurezza che partecipano alle VDP e ai programmi di ricompense per la segnalazione di bug. Ad esempio, puoi utilizzare strumenti senza costi e open source che analizzano ed enumerano gli intervalli IP o i domini IP rivolti a internet che potrebbero appartenere alla tua organizzazione. Una ricerca su Google per reconing delle taglie dei bug produrrà una serie di suggerimenti utili per aiutarti a identificare gli asset della tua organizzazione di cui non eri a conoscenza.

Analisi delle vulnerabilità di base

Ora che disponi di solide basi su dove devi individuare i problemi di sicurezza, analizziamo come riuscirci. Esistono vari livelli di profondità a cui puoi accedere a seconda delle risorse della tua organizzazione, ma devi trovare un equilibrio tra le tue iniziative per la sicurezza interna e la community esterna di pirateria informatica attraverso il tuo programma di divulgazione delle vulnerabilità. Questo saldo è diverso per ogni organizzazione, a seconda delle risorse disponibili.

Scegli i tuoi strumenti

Esistono molti strumenti diversi per identificare le vulnerabilità. Alcuni strumenti di analisi delle vulnerabilità sono disponibili senza costi, mentre altri sono a pagamento. Capire quali strumenti scegliere dipende dalle tue esigenze individuali.

• Requisiti della tua organizzazione
• In che misura ogni strumento soddisfa questi requisiti
• Se i vantaggi dello strumento superano i costi (finanziari e di implementazione).

Puoi utilizzare questo modello di requisiti (OpenDocument .ods, Microsoft Excel .xlsx) per valutare vari strumenti in base ai tuoi requisiti. Alcuni requisiti di esempio sono inclusi nel modello, ma è consigliabile discuterne con i team IT, di sicurezza e di progettazione per allinearsi alle funzionalità richieste. Prima di lanciare un programma di divulgazione delle vulnerabilità, ti consigliamo di eseguire scansioni delle vulnerabilità per tutti gli asset rivolti all'esterno (come siti web, API e app mobile). In questo modo, potrai trovare e correggere vulnerabilità facilmente rilevabili prima di invitare ricercatori esterni per la sicurezza a eseguire test su questi asset e servizi.

Configurazione della scansione

Le analisi automatiche delle vulnerabilità possono rilevare molti problemi, ma anche generare falsi positivi. Ecco perché è necessario disporre delle risorse per convalidare i risultati prima di condividerli con i team interessati. Dovrai implementare i processi per assicurarti che le analisi vengano eseguite regolarmente e che i risultati di queste analisi vengano effettivamente gestiti. Questo aspetto avrà un aspetto diverso per ogni organizzazione, ma devi determinare almeno quanto segue:

• Frequenza di ricerca
  • Continua
  • Ogni settimana
  • Mensile
• Quali asset vengono analizzati
• Credenziali
  • Scansioni autenticate e non autenticate
  • (suggerimento: se non esegui la scansione con le credenziali, un ricercatore della sicurezza esegue dei test con le credenziali quando avvii la VDP, potrebbe verificarsi un picco di vulnerabilità identificate)
• Ruoli e responsabilità
  • Identifica i membri del team responsabili dell'esecuzione delle scansioni
  • Se necessario, configura una rotazione
• Risultati della scansione
  • Verifica dei risultati dell'analisi
  • Segnalare bug per le vulnerabilità verificate
  • Identificazione dei proprietari per correggere i bug
  • Contattare i proprietari in merito alla correzione

Più avanti nella guida, illustreremo in dettaglio come garantire la risoluzione dei problemi di sicurezza identificati nella sezione Correggere i bug.

Procedura di revisione della sicurezza

Sebbene l'analisi delle vulnerabilità sia un ottimo modo per identificare in modo reattivo i problemi di sicurezza nella tua organizzazione, l'implementazione di processi di analisi della sicurezza può aiutare a prevenire l'introduzione delle vulnerabilità. Nell'ambito di questa guida, il termine controllo della sicurezza si riferisce a qualsiasi situazione che attiva una revisione manuale da parte di un membro del team di sicurezza. In genere, ciò include l'autorità per bloccare una modifica se è considerata troppo rischiosa. Se il tuo team di sicurezza non è in grado di bloccare le modifiche rischiose, ti consigliamo di disporre comunque di processi per documentare il rischio. Questo può aiutare a garantire che chiunque promuova il cambiamento sia a conoscenza del rischio associato e lo accetti in modo proattivo.

Criteri di revisione della sicurezza

Quando devono essere eseguiti i controlli di sicurezza? La creazione di un insieme di criteri che attiva una revisione della sicurezza aiuta ad assicurarsi che tutti siano al passo con i tempi. Di seguito sono riportati alcuni esempi di scenari che potrebbero attivare un controllo della sicurezza.

• Viene proposta una nuova funzionalità relativa ai dati utente sensibili
  • Una nuova funzionalità che consente agli utenti di condividere la propria posizione sulla mappa
  • Richiedere agli utenti informazioni potenzialmente sensibili, come indirizzo di casa, data di nascita o numero di telefono
• Vengono apportati importanti aggiornamenti alle funzionalità esistenti
  • Prendere i dati utente esistenti e usarli in un modo nuovo che gli utenti potrebbero non aspettarsi senza offrire loro l'opportunità di disattivarli
  • Modifiche a qualsiasi funzionalità relativa all'autenticazione, all'autorizzazione e alla gestione delle sessioni
• Modifiche all'ambiente di produzione dell'azienda
  • le modifiche alla configurazione di rete, in particolare le modifiche che potrebbero comportare l'esposizione dei servizi
  • Installazione di un nuovo software che gestisce dati utente sensibili che, se compromessi, potrebbero essere utilizzati indirettamente per accedere a dati utente sensibili
  • Supporto di nuovi sistemi o servizi
• Interazione con un nuovo fornitore o modifica del modo in cui collabori con un fornitore esistente
  • Inserimento di un nuovo fornitore che gestirà i dati utente sensibili
  • Modifiche alla collaborazione con un fornitore esistente che comporta la gestione di dati utente sensibili

Non si tratta di un elenco esaustivo, ma dovrebbe aiutarti a pensare a quali tipi di modifiche dovrebbero richiedere una revisione della sicurezza. Quando definisci i criteri relativi a ciò che richiede o meno un controllo della sicurezza, parlane con le principali parti interessate all'interno dell'organizzazione per assicurarti che:

• Gli stakeholder hanno la possibilità di esaminare i criteri e fornire un feedback
• Gli stakeholder accettano i criteri
• Gli stakeholder accettano di richiedere proattivamente le revisioni della sicurezza

Documenta questi criteri e spiega come richiedere una revisione della sicurezza (ad esempio, segnalando un bug in una coda monitorata dal team addetto alla sicurezza) per semplificare il più possibile l'esecuzione di questo processo per la tua organizzazione.

Risorse per la revisione della sicurezza

A differenza delle analisi automatiche, le revisioni della sicurezza possono richiedere un maggior numero di risorse. Ogni team di sicurezza ha a disposizione molto tempo durante la giornata per svolgere una miriade di attività, quindi dovrai stimare il numero di controlli di sicurezza che potrebbero essere generati in base ai tuoi criteri. Se scopri che il tuo team è sopraffatto e rimane indietro, chi aspetta il lancio delle loro funzionalità si infastidisce del team di sicurezza. Questo può causare un cambiamento culturale nell'organizzazione, che porta il team di sicurezza a essere visto come un blocco invece che come un partner. Se il processo di controllo della sicurezza non è efficiente, molti individui e team cercheranno di ignorarlo completamente. Se le risorse sono limitate, valuta la possibilità di allentare i criteri per richiedere una revisione della sicurezza e accetta un rischio residuo maggiore. Se si verificano incidenti a causa della mancanza di risorse per eseguire i controlli di sicurezza, ciò contribuirà a giustificare la necessità di ulteriori risorse.

Esecuzione di revisioni della sicurezza

Quando devi decidere quali revisioni della sicurezza eseguire e come eseguirle, avrai bisogno di una coda prioritaria da cui eseguire il pull. Crea un modo standardizzato per consentire agli altri membri della tua organizzazione di richiedere una revisione della sicurezza con qualsiasi informazione ti serva per assegnare le priorità in modo appropriato. Ad esempio, puoi compilare un questionario che includa elementi come la natura della modifica, incluso un breve riepilogo della modifica e i tipi di dati utente che potrebbero essere interessati. Puoi classificare automaticamente le potenziali revisioni della sicurezza in modifiche a rischio alto, medio o basso in base alle risposte a queste domande. Se una modifica è ad alto rischio, potresti richiedere una procedura di revisione della sicurezza più approfondita. Se una modifica comporta un rischio inferiore, potresti essere in grado di implementare una procedura di revisione della sicurezza più leggera per ridurre le risorse richieste e accelerare il processo, consentendo di migliorare l'attività. Prendi in considerazione la possibilità di impostare una rotazione all'interno del tuo team per essere responsabile della gestione della coda dei controlli della sicurezza, garantire che i nuovi controlli della sicurezza vengano scelti dai membri del tuo team e continuare a seguire l'avanzamento dei controlli di sicurezza esistenti. Il processo effettivo della valutazione della sicurezza varia a seconda di ciò che viene esaminato. Ad esempio, una nuova funzionalità dell'app per dispositivi mobili potrebbe richiedere la revisione del codice da parte di un tecnico di sicurezza alla ricerca di potenziali vulnerabilità. Potrebbe essere necessario esaminare il nuovo software installato per garantire che il controllo dell'accesso sia configurato correttamente. Lavorare con fornitori esterni può comportare una procedura completamente diversa. Come riferimento, leggi il questionario per la valutazione della sicurezza del fornitore di Google.

Correggere i bug

Trovare i bug è importante, ma la sicurezza migliora solo una volta risolti. Sapere quali rischi esistono per la tua organizzazione è positivo, ma riuscire a affrontarli in modo efficiente è meglio.

Gestione delle vulnerabilità

Le vulnerabilità derivano da una varietà di risorse, tra cui iniziative interne (ad esempio analisi delle vulnerabilità e revisioni di sicurezza), test e audit di penetrazione di terze parti o anche ricercatori esterni per la sicurezza che inviano notifiche tramite canali di assistenza prima del lancio ufficiale della VDP. La tua organizzazione ha bisogno di un modo per classificare le vulnerabilità nuove ed esistenti per garantire che vengano comunicate agli stakeholder giusti, assegnate correttamente le priorità e risolte in modo tempestivo. Quando avvii la VDP, avrai un nuovo flusso di vulnerabilità che entrano nei processi di gestione delle vulnerabilità. La presenza di solidi processi per la gestione di queste vulnerabilità consente di monitorare i progressi verso la correzione e di rispondere alle richieste di aggiornamenti da parte di ricercatori esterni della sicurezza. Riuscire a dare rapidamente la priorità a una vulnerabilità e comunicare con i partecipanti VDP sulle tempistiche di correzione aumenterà il coinvolgimento con la community di ricercatori sulla sicurezza, oltre a migliorare la reputazione della sicurezza della tua organizzazione. Le seguenti sezioni descrivono i vari aspetti del programma di gestione delle vulnerabilità che conviene adottare prima di lanciare la VDP.

Stabilisci standard di gravità e tempistiche per la correzione

La creazione di un linguaggio comune per la gravità delle vulnerabilità e le tempistiche ideali per la correzione associate a ogni gravità semplifica il definire le aspettative standard per la tua organizzazione. Se ogni vulnerabilità viene trattata come un'emergenza, la tua organizzazione esaurirà le sue risorse e si metterà risentimento nei confronti del team di sicurezza. Se ogni vulnerabilità è considerata a bassa priorità, le vulnerabilità non verranno mai risolte e il rischio di una violazione aumenta. Ogni organizzazione dispone di risorse limitate, quindi è necessario stabilire un ranking relativo alla gravità. Questo ranking fornisce criteri che aiutano la tua organizzazione a capire in quale gravità rientra una vulnerabilità e le tempistiche di correzione previste associate a ogni gravità. Prepara una bozza di linee guida sulla gravità e condividila con i principali stakeholder della tua organizzazione per ricevere feedback. Ad esempio, se l'ingegneria è coinvolta nella creazione degli standard di gravità, è più probabile che acconsentano a questi standard e li aderiscano quando arriva il momento di correggere una vulnerabilità entro un periodo di tempo specificato. Queste linee guida sulla gravità possono variare a seconda dei rischi specifici della tua attività. Ti consigliamo di prendere in considerazione un esercizio di modellazione delle minacce per capire quali sono le minacce più probabili e di impatto per la tua organizzazione e includere esempi di problemi che rientrano in ogni categoria di gravità. Di seguito è riportato un esempio di standard di gravità e tempistiche di correzione per un'organizzazione finanziaria.

Gravità	Descrizione	Sequenza temporale della correzione	Esempi
Critico	Problemi che rappresentano una minaccia imminente per i nostri utenti o la nostra azienda.	Proprietario: un proprietario principale per garantire che la vulnerabilità venga corretta deve essere identificato entro 8 ore. Effettua chiamate e consulta le risorse se necessario, anche al di fuori del normale orario di lavoro. Soluzione: il problema stesso deve essere risolto, o quantomeno attenuato il rischio, il prima possibile o al massimo entro tre giorni lavorativi.	Compromesso di un database di produzione che include i registri finanziari di tutti gli utenti. Un malintenzionato che riesce ad accedere ai segreti commerciali, come i nostri algoritmi di investimento proprietari. Un incidente attivo che include un utente malintenzionato che ha accesso alla nostra rete interna o ai sistemi di produzione sensibili.
Alto	Problemi che, se sfruttati, potrebbero causare danni significativi.	Proprietario: il proprietario principale deve essere identificato entro un giorno lavorativo. Soluzione: entro 10 giorni lavorativi (circa 2 settimane).	Vulnerabilità che potrebbero comportare l'accesso a funzionalità o dati utente sensibili (ad esempio la possibilità per un utente di sottrarre fondi da un altro utente).
Medium	Problemi più difficili da sfruttare o che non comportano danni diretti.	Proprietario: il proprietario principale deve essere identificato entro cinque giorni lavorativi. Soluzione: entro 20-40 giorni lavorativi (circa 1-2 mesi).	Problemi verificati identificati da scanner automatici, ad esempio le patch per gli aggiornamenti della sicurezza senza exploit noti. Problemi relativi alla divulgazione di informazioni che potrebbero essere utili per ulteriori attacchi. Problemi relativi alla limitazione di frequenza che potrebbero essere sfruttati (ad es. la possibilità di indovinare in continuazione le password di un utente).
Basso	Problemi con impatto minimo; utilizzato principalmente per registrare problemi noti.	Non sono previsti requisiti per trovare un proprietario o correggere un proprietario entro un determinato periodo di tempo.	Divulgazione di informazioni che non presenta rischi probabili, ma dove le informazioni non devono essere accessibili all'esterno.

Cura dei bug

Non stiamo parlando di taglio di capelli, ma di come assicurarsi che i bug siano formattati correttamente in modo che possano essere facilmente corretti. Utilizzando la tabella precedente come guida, stabilisci le tue definizioni di gravità. Queste definizioni vengono utilizzate per classificare i bug in varie gravità e per comunicarli ai proprietari.

Oltre ad assegnare una gravità a ogni vulnerabilità, dovrai assicurarti che i bug siano in un formato standard che semplifichi l'elaborazione da parte dei team di ricezione. Le vulnerabilità inseriranno i processi di gestione delle vulnerabilità in una varietà di formati (ad esempio risultati di analisi automatizzati o riscritture manuali derivanti dai controlli di sicurezza). Dedicare del tempo alla conversione di ogni vulnerabilità in un formato standard aumenterà le possibilità che il team ricevente sia in grado di comprendere e risolvere rapidamente il problema.

Questo formato o modello può variare a seconda della tua organizzazione e delle informazioni più pertinenti per aiutare i proprietari a correggere i bug loro assegnati, ma ecco un modello di esempio che puoi utilizzare. Potrai riutilizzare questo modello in un secondo momento, quando creerai il modulo di invio per il programma di divulgazione delle vulnerabilità per i ricercatori.

Titolo: <una riga della descrizione del problema, di solito il tipo di vulnerabilità, l'asset, il servizio e così via; facoltativamente, includi la gravità o mappa la gravità a un campo nel tuo tracker dei problemi>Riepilogo: <breve descrizione della vulnerabilità e perché è importante> Passaggi per la riproduzione: <istruzioni dettagliate su come mostrare l'esistenza della vulnerabilità, come può essere risolto il problema o come risolvere il problema

Ecco un esempio di potenziale vulnerabilità ad alta gravità:

Titolo: [HIGH] Non sicuro Direct Object Reference (IDOR) nelle pagine del profilo Riepilogo: nella funzionalità delle pagine profilo della nostra app è stato rilevato un IDOR che consente a qualsiasi utente di ottenere l'accesso non autorizzato per visualizzare e modificare il profilo di un altro utente, inclusi il nome completo, l'indirizzo di casa, il numero di telefono e la data di nascita dell'altro utente. Abbiamo esaminato i log e questo problema non sembra essere ancora stato sfruttato. Questo problema è stato rilevato internamente. Passaggi di riproduzione:

1. Configura un proxy, ad esempio Burp Suite) per intercettare il traffico su un dispositivo mobile su cui è installata l'app.
2. Visita la pagina del tuo profilo e intercetta la richiesta HTTP associata.
3. Modifica profileID=###### in profileID=000000 (si tratta di un utente di prova) e invia insieme la richiesta HTTP.
4. L'app mostrerà il profilo dell'utente 000000 e potrai visualizzare e modificare le sue informazioni.

Scenario / impatto di attacco: qualsiasi utente può utilizzare questa vulnerabilità per visualizzare e modificare il profilo di un altro utente. Nel peggiore dei casi, un utente malintenzionato potrebbe automatizzare il processo di recupero delle informazioni del profilo di ogni utente nell'intero sistema. Sebbene non crediamo che questo problema sia stato ancora sfruttato, è importante considerare questo problema come un problema standard con gravità ALTA. Se osserviamo prove di sfruttamento, ciò potrebbe portare alla gravità CRITICA. Procedura di correzione: implementa i controlli lato server per assicurarti che l'utente che effettua la richiesta possa accedere per visualizzare/modificare il profilo richiesto tramite il valore di profileID. Ad esempio, se Alice ha eseguito l'accesso e ha l'ID profilo 123456, ma risulta che Alice abbia richiesto l'ID profilo 333444, l'utente dovrebbe visualizzare un errore e questo tentativo di accedere al profilo di un altro utente dovrebbe essere registrato. Per ulteriori informazioni su IDOR e su come risolvere il problema, consulta i materiali di OWASP su questo bug.

Puoi risparmiare tempo e attività manuali trovando dei modi per automatizzare la conversione delle vulnerabilità da varie origini nel tuo formato standard. Man mano che crei più vulnerabilità, potresti trovare temi comuni nelle procedure di correzione. Oltre a usare il modello di formato di bug generico, potresti voler creare altri modelli per i tipi di vulnerabilità più comuni.

Trovare proprietari

Forse uno degli aspetti più difficili della gestione delle vulnerabilità è identificare i proprietari che aiutino a correggere i bug, oltre a trovare il loro consenso per dedicare risorse per la correzione puntuale dei bug. Se hai impostato le procedure di gestione delle risorse, il processo sarà un po' più semplice. In caso contrario, questa potrebbe essere una motivazione per farlo. A seconda delle dimensioni della tua organizzazione, trovare un proprietario potrebbe essere abbastanza semplice o incredibilmente complesso. Man mano che la tua organizzazione cresce, cresce anche lo sforzo per determinare chi è responsabile della risoluzione dei problemi di sicurezza appena rilevati. Valuta di implementare una rotazione operativa on-duty. Chiunque sia in servizio ha la responsabilità di esaminare le vulnerabilità non assegnate, rintracciare i proprietari e assegnare le priorità in base alla gravità. Anche se sei in grado di identificare chi è responsabile della correzione di una vulnerabilità e assegnarlo al bug, devi anche convincerlo a dedicare del tempo alla risoluzione effettiva. Questo approccio può variare a seconda del team o dell'individuo e su quali altri elementi stanno lavorando. Se hai raggiunto il consenso dell'organizzazione per gli standard di gravità e le tempistiche per la correzione, puoi farvi riferimento, ma a volte potrebbe essere necessaria un'ulteriore persuasione per chiedere a qualcuno di correggere un bug. Ecco alcuni suggerimenti generali per promuovere la correzione delle vulnerabilità:

• Spiega il motivo: quando a qualcuno viene assegnata una vulnerabilità da correggere, di solito c'è un lavoro imprevisto. Spiega perché è importante risolvere questo problema in modo tempestivo (ad es. lo scenario di impatto / attacco) e assicurati che il proprietario ne abbia compreso.
• Raccogliere contesto: in alcuni casi, solo una persona ha le conoscenze necessarie per correggere un bug e potrebbe avere altre attività su cui sta lavorando. Scopri di più: è possibile che le altre attività siano più importanti della risoluzione di questa vulnerabilità nel breve termine. Dimostrare empatia e flessibilità nelle tempistiche di correzione ti aiuterà a guadagnare buona reputazione e a rafforzare il tuo rapporto con le persone a cui devi risolvere le vulnerabilità. Fai però attenzione a non lasciare un margine eccessivo, altrimenti la tua organizzazione non prenderà sul serio i tempi di correzione.
• Spiega come: anche se nel bug includi consigli per la correzione, il proprietario che ha risolto il problema potrebbe essere confuso o aver bisogno di aiuto per imparare a risolvere il bug. Se hanno bisogno di aiuto per capire come risolvere il problema, dai loro insegnamenti. La semplice distribuzione di bug ai proprietari senza aiutarli danneggerà il rapporto dell'organizzazione con il team di sicurezza. Aiutare il più possibile gli altri consente loro di correggere le vulnerabilità presenti e future, oltre che di insegnare agli altri.
• Adatta la richiesta: vari team e privati potrebbero avere processi esistenti per il modo in cui accettano e danno la priorità alle richieste di lavoro in arrivo. Alcuni team potrebbero volere che tutte le richieste in arrivo passino attraverso i propri manager. Altri preferiscono che le richieste di assistenza vengano inviate in un formato standard. Alcune funzioneranno solo su ciò che è stato predefinito in uno sprint. In ogni caso, dedicare un po' di tempo ad adattare la tua richiesta al formato utilizzato di solito dal team o dal singolo individuo per accettare le richieste di assistenza aumenterà le probabilità che la tua richiesta venga assegnata a una priorità e venga intrapresa un'azione.
• Riassegnare come ultima risorsa: se hai già provato tutte le soluzioni precedenti e la persona o il team responsabile della correzione di una vulnerabilità non impiegherà il tempo per risolvere un problema di sicurezza grave, valuta la possibilità di riassegnare il caso al team dirigenziale, se necessario. Questa dovrebbe essere sempre l'ultima risorsa, in quanto potrebbe danneggiare il tuo rapporto con la persona o il team in questione.

Analisi delle cause principali

Oltre a trovare e correggere le singole vulnerabilità, l'esecuzione dell'analisi delle cause principali (RCA) può aiutarti a identificare e risolvere i problemi di sicurezza sistemici. Tutti hanno risorse limitate, quindi si potrebbe avere la tentazione di saltare questo passaggio. Tuttavia, dedicare tempo all'analisi delle tendenze dei tuoi dati sulle vulnerabilità, nonché a esaminare ulteriormente bug critici e ad alta gravità, può farti risparmiare tempo e ridurre i rischi a lungo termine. Ad esempio, supponiamo che noti che lo stesso tipo di vulnerabilità (ad esempio reindirizzamento di intent) compare più volte in tutta l'app. Decidi di parlare con i team che stanno introducendo questa vulnerabilità nella tua app e ti rendi conto che la maggior parte di loro non capisce che cos'è il reindirizzamento degli intent, perché è importante o come impedirlo. Hai messo insieme un discorso e una guida per educare gli sviluppatori della tua organizzazione su questa vulnerabilità. Questa vulnerabilità probabilmente non scomparirà completamente, ma la frequenza con cui compare probabilmente diminuirà. Quando avvii la VDP, ogni vulnerabilità segnalata da una terza parte è sfuggita ai processi di sicurezza interni esistenti. L'esecuzione di RCA sui bug della tua VDP fornirà ulteriori informazioni su come migliorare sistematicamente il tuo programma di sicurezza.

Rilevamento e risposta

Per rilevamento e risposta si intendono tutti gli strumenti e i processi in atto per rilevare e rispondere a potenziali attacchi contro la tua organizzazione. Queste soluzioni potrebbero venire sotto forma di soluzioni acquistate o sviluppate autonomamente che analizzano i dati per identificare comportamenti sospetti. Ad esempio, nella sezione Grooming bug abbiamo parlato del logging ogni volta che un utente tenta di accedere senza autorizzazione al profilo di un altro utente. Potresti visualizzare un indicatore o un avviso se noti che un utente genera un numero elevato di tentativi di accesso ai profili di altri utenti non riusciti in un breve periodo di tempo. Puoi persino automatizzare il processo di blocco dell'accesso dell'utente ai tuoi servizi per un determinato periodo di tempo o per sempre fino a quando la situazione non può essere esaminata e ripristina manualmente l'accesso. Se non disponi già di meccanismi di rilevamento e risposta, valuta la possibilità di collaborare con un consulente esperto che ti aiuti a creare un programma DFIR di analisi forense e risposta agli incidenti digitali per la tua organizzazione. Se già disponi di meccanismi di rilevamento e risposta, considera le conseguenze di avere cinque, dieci o addirittura cento ricercatori di sicurezza che testano le tue piattaforme di attacco rivolte a Internet. Ciò può avere un grande impatto su qualsiasi sistema IDS/IPS (sistemi di rilevamento e prevenzione delle intrusioni) in atto.

I rischi potenziali includono:

• Sovraccarico di avvisi: un flusso di avvisi o segnali che sembrano attacchi dannosi, ma in realtà sono test normali e approvati da parte dei ricercatori di sicurezza che partecipano alla tua VDP. È possibile generare così tanto rumore che diventa difficile distinguere gli attacchi reali dai test di sicurezza legittimi.
• Falsi allarmi relativi alla risposta agli incidenti: se hai dei processi in atto per le persone della pagina alle 02:00 di sabato, queste persone non saranno contente di svegliarsi e indagare su una potenziale violazione che in realtà riguardava solo un ricercatore della sicurezza che esegue dei test legittimi.
• Blocco dei ricercatori nella sicurezza: se disponi di sistemi IPS (sistemi di prevenzione delle intrusioni) aggressivi, potresti finire per bloccare l'indirizzo IP di un ricercatore che sta tentando di eseguire scansioni, test manuali e così via per identificare le vulnerabilità e segnalartele. Soprattutto nel caso di una VDP, se un ricercatore sulla sicurezza viene bloccato dopo cinque minuti di test, potrebbe perdere interesse e concentrarsi sul programma di un'altra organizzazione. Ciò può comportare una generale mancanza di coinvolgimento nel tuo programma da parte di ricercatori della sicurezza, il che aumenta il rischio che le vulnerabilità rimangano non scoperte (e quindi sconosciute alla tua organizzazione). È possibile che tu non voglia attenuare i tuoi IPS, ma ci sono altre misure che puoi adottare per mitigare il rischio di perdere il coinvolgimento dei ricercatori.

La modalità di risoluzione di questi rischi dipende in gran parte dall'approccio che vuoi adottare per collaborare con ricercatori esterni sulla sicurezza. Se vuoi uno stile di test più black box che muova attacchi reali, non puoi fare nulla. In questo caso, il traffico del ricercatore genererà avvisi e il tuo team potrebbe intraprendere azioni per esaminare il problema e rispondere di conseguenza. Ciò aiuterà il tuo team a esercitarsi a rispondere ad attacchi che sembrano veri, ma potrebbe diminuire il coinvolgimento dei ricercatori sulla sicurezza, soprattutto se sono stati bloccati per non poter eseguire test. Potrebbe anche comportare la perdita di un vero attacco mentre si dedica tempo a indagare su test legittimi. Se preferisci adottare un approccio grey, puoi considerare la possibilità di collaborare con i ricercatori sulla sicurezza per identificare in qualche modo autonomamente il traffico di test. In questo modo, potrai autorizzare o escludere in altro modo il traffico dai test e dagli avvisi conseguenti. Il tuo team sarà in grado di distinguere meglio gli attacchi reali dai test approvati e i ricercatori saranno in grado di individuare e segnalare le vulnerabilità senza essere ostacolato dai sistemi di prevenzione delle intrusioni. Alcune organizzazioni chiedono ai ricercatori della sicurezza di inviare un modulo per richiedere un identificatore univoco che possa essere associato alle intestazioni nelle richieste generate dal ricercatore. Ciò consente all'organizzazione di autorizzare il traffico per il ricercatore, nonché la possibilità di identificare se il ricercatore inizia ad andare oltre l'ambito concordato dei test. In tal caso, puoi contattare il ricercatore e chiedergli di attendere fino a quando non troverete insieme un piano di test.