Inizia in piccolo
Anche se è già stato menzionato, vale la pena rivedere. Potresti avere la tentazione di lanciare il programma "pubblicamente" annunciandolo a tutti e, nel caso di un programma interno, rendere pubblicamente accessibili le norme del programma e il modulo di invio delle segnalazioni. Questo può essere rischioso, in quanto non ti dà la possibilità di iniziare in piccolo per poi fare lo scale up. Qualunque sia la vostra preparazione, ci saranno sempre sorprese quando lancerete una VDP. Potresti ricevere più vulnerabilità del previsto e non riuscire a tenere il passo. Forse metà del team si ammala e non riesce ad aiutare a individuare i bug. Magari hai dimenticato di eseguire scansioni autenticate e, quando un ricercatore lo fa, si verifica un impatto accidentale del sistema nel tuo sistema,creando 100.000 nuovi account. Qualunque possano essere le sorprese, è meglio iniziare in piccolo e gradualmente incrementare il programma nel tempo. Riscontrerai problemi, il che è del tutto normale, ma è meglio avere la larghezza di banda per gestirli uno alla volta.
Se hai deciso di sviluppare il programma internamente, ti consigliamo di fare riferimento alle norme del programma e di segnalare il modulo di invio sul tuo sito web, ma potresti richiedere agli hacker di effettuare l'accesso prima di poterle visualizzare. Se utilizzi una piattaforma di terze parti, queste gestiranno automaticamente l'invito a un piccolo gruppo di ricercatori di sicurezza per te. In entrambi i casi, puoi creare un modello di invito da utilizzare per invitare gli hacker alla tua VDP privata, come segue:
Un saluto da Google, <Nome della tua organizzazione> ti invitiamo a partecipare alla nostra VDP privata. Stiamo iniziando in modalità privata in piccolo, per poter basare i nostri processi VDP per offrire la migliore esperienza possibile ai ricercatori della sicurezza. Consulta le norme del programma per le linee guida e l'ambito dei test. Se avete un feedback per noi nelle prime fasi della nostra VDP, non esitate a comunicarcelo.Dopo che il tuo primo gruppo di ricercatori sarà stato invitato e sarà stato concesso l'accesso al tuo programma, inizierai a ricevere i report. Potresti anche non ricevere alcun report, ma non è un problema. Supponiamo che inviti cinque ricercatori sulla sicurezza. È possibile che due di loro sono troppo impegnati e decidono di non guardare affatto il tuo programma. Un'altra persona potrebbe essere in vacanza e perdere del tutto il tuo messaggio di invito. Il quarto e il quinto hacker potrebbe dare un'occhiata e testarlo per un giorno o due, ma non trovare alcuna vulnerabilità. Potrebbero tornare sul sito alcune settimane dopo e segnalare qualcosa in quel momento, ma può essere ancora scioccante dover svolgere tutte queste operazioni, inviare inviti e non ricevere alcuna segnalazione. Se succede, non preoccuparti. È una cosa del tutto normale: bisogna iniziare con un approccio ridotto e fare lo scale up. Se invii cinque inviti e non registri un volume elevato di report, inviane altri cinque, poi altri cinque, dieci o addirittura venti. Se usi una piattaforma di terze parti, questa è dotata di meccanismi automatici che invitano gli hacker lentamente nel tempo, in base al volume di report desiderato. D'altra parte, se ricevi un numero enorme di report sulle vulnerabilità dopo aver invitato solo cinque ricercatori della sicurezza, potresti evitare di invitarne altri finché il volume dei report non cala.
Classifica e iterazione
Per le prime due settimane dopo il lancio della VDP, potrebbe essere opportuno attivare contemporaneamente due o più persone che ti aiutino a valutare i report sulle vulnerabilità in arrivo, a presentare bug e a comunicare con i ricercatori. In genere, si verifica un picco di segnalazioni numerose al momento del lancio di un programma, per poi stabilizzarsi nel tempo. Quando valuti i report sulle vulnerabilità in arrivo, potresti ricevere feedback dagli hacker e identificare lacune o malintesi nelle norme del programma. Potresti anche rilevare problemi nei processi e negli strumenti. Se inizi con poco e hai molta attenzione ed energia da parte del tuo team in queste prime due settimane, sfrutta questo periodo per iterare e migliorare rapidamente il tuo programma. Dopo un mese o due, le cose si arrescano e l'esecuzione senza intoppi del programma diventerà una cosa naturale.
Fare lo scale up e il lancio pubblico
Man mano che il tuo team si abitua alla gestione del programma, inviterai sempre più hacker a partecipare. Hai ampliato il tuo ambito includendo tutto ciò di cui sai (e persino gli asset di cui forse non avevi immaginato l'esistenza). Alla fine, potresti arrivare a un punto in cui hai invitato un centinaio o addirittura alcune centinaia di hacker, ma il volume delle segnalazioni sembra in calo. Tutti i report inviati sembrano avere una gravità bassa o media. La rotazione del servizio sembra essere piuttosto leggera e il tuo team è esperto nell'assegnazione di priorità ai report sulle vulnerabilità, nell'indirizzarli alla risoluzione e nel comunicare con gli hacker. A questo punto, potresti essere pronto a lanciare pubblicamente il programma. Prima di farlo, ricontatta tutti i tuoi stakeholder per assicurarti che siano a conoscenza del lancio pubblico e che prendano parte al tuo progetto. Come per il lancio privato iniziale, prepara il tuo team a un altro potenziale picco nel volume dei report per il lancio pubblico. Una differenza fondamentale quando viene lanciato pubblicamente è che chiunque può inviarti un report sulla vulnerabilità. Tieni presente che questa operazione può generare molto rumore. Ad esempio, gli utenti confuso su come accedere al proprio account o persino i bot di spam che compilano moduli e inviano automaticamente email potrebbero inviare segnalazioni alla tua VDP. È utile disporre di modelli per chiudere rapidamente i report comuni non relativi alla sicurezza o persino prerilasciarli modificando il modulo in modo da reindirizzare gli utenti alla posizione giusta (ad esempio, il personale di assistenza per cose come le password dimenticate). L'aspetto positivo è che ora potranno farlo rendendo pubblico il tuo programma, grazie ad hacker esperti che prima non avevano modo di contattarti. Questo potrebbe aiutarti a scoprire vulnerabilità di gravità elevata o critica di cui non conoscevi l'esistenza. Inoltre, offre tutti i vantaggi menzionati in precedenza in questa guida, tra cui l'avere un canale standardizzato per consentire alla community globale di pirateria informatica di rivelare direttamente le vulnerabilità, riducendo il rischio di violazioni e PR negative.
Festeggia
Complimenti, hai fatto molta strada e ora hai una VDP pubblica. Non dimenticare di festeggiare con il tuo team e tutti gli stakeholder che ti hanno aiutato. È importante esprimere la tua gratitudine e trovare un modo per festeggiare il tuo successo insieme. Oltre a celebrare il lancio pubblico della tua VDP, non dimenticare di celebrare i traguardi raggiunti lungo il percorso, come l'anniversario del lancio pubblico, o evidenziando bug particolarmente interessanti e critici che sono stati rilevati e risolti tramite la VDP. La raccolta di metriche durante il processo può aiutarti a dimostrare il successo del tuo programma e mettere in evidenza i risultati tuoi e del tuo team.