Uno sconosciuto ha segnalato una vulnerabilità: un piano di risposta

Il messaggio di solito arriva all’indirizzo sbagliato: l’assistenza, l’ufficio commerciale, la casella personale del fondatore. Dice che il mittente ha trovato una vulnerabilità nel tuo prodotto. A volte contiene dettagli, a volte chiede se hai un programma di bug bounty, a volte parla di soldi già nella prima riga.

Ciò che fai dopo decide due cose: se questa vulnerabilità verrà corretta senza clamore, e se il prossimo ricercatore scriverà a te o di te.

Chi scrive messaggi del genere

• Ricercatori in buona fede. Hanno trovato qualcosa, spesso per caso o mentre testavano un’intera categoria di prodotti, e vogliono che venga corretto. Molti sperano in una ricompensa o in un riconoscimento; pochi insistono.
• Chi segnala rilievi di strumenti automatici. Uno scanner ha trovato un header mancante o una libreria obsoleta, e la segnalazione è stata inviata a centinaia di aziende. Il rilievo può essere reale e di solito è di poco conto.
• Estorsori. Il messaggio contiene una minaccia: paga, o i dati vengono pubblicati. È un reato e va gestito come un incidente, non come una segnalazione.

Dal primo messaggio spesso non puoi capire con chi hai a che fare. Il piano qui sotto vale per tutti e tre i casi, finché non lo capisci.

La prima ora

1. Non rispondere con rabbia e non minacciare. Una minaccia di azioni legali trasforma una segnalazione privata in una vicenda pubblica.
2. Non pagare e non promettere pagamenti. Non sai ancora per che cosa pagheresti.
3. Non cliccare i link e non aprire gli allegati del messaggio su un computer di lavoro. Passalo a chi si occupa della sicurezza.
4. Avvisa il responsabile della sicurezza. Se non c’è nessuno, questo è il primo rilievo.

Il primo giorno

Conferma la ricezione. Bastano due frasi: la segnalazione è stata ricevuta, è in esame, e questa è la persona con cui parlare. È il silenzio che spinge i ricercatori a rendere pubblico ciò che hanno trovato.

Chiedi i dettagli attraverso un canale che controlli tu. Una casella dedicata, meglio se con una chiave di cifratura. Chiedi l’indirizzo interessato, i passaggi per la riproduzione e a che cosa l’autore della segnalazione è riuscito ad accedere.

Verifica dalla tua parte. Riproduci il problema da te, se possibile in un ambiente di test. Guarda i log del periodo indicato dall’autore: a che cosa si è acceduto, da dove, con quale frequenza. I log ti dicono se l’autore si è fermato alla prova.

La prima settimana

Valuta la gravità. Che cosa può farci un attaccante, e quanto è difficile? Un punteggio CVSS offre un linguaggio comune per la risposta.

Decidi se si tratta di un incidente. Se la vulnerabilità dava accesso a dati personali e non puoi escludere che sia stata sfruttata, possono applicarsi gli obblighi di notifica previsti dalla normativa sulla protezione dei dati, con scadenze brevi. È una domanda per i tuoi legali il primo giorno, non l’ultimo.

Correggi, poi informa l’autore. Di’ che cosa è stato corretto e quando. Se non sei d’accordo con la segnalazione, dillo e spiega perché.

Ringrazia. Un riconoscimento pubblico, con il consenso dell’autore, non costa nulla. La ricompensa è una tua decisione; se la paghi, pagala per il rilievo e non sotto pressione, e di’ che è volontaria.

Quando si parla subito di soldi

Un ricercatore che chiede se hai un programma di bug bounty fa una domanda normale. La risposta può essere «no, ma siamo grati per la segnalazione».

Un mittente che si rifiuta di fornire qualsiasi dettaglio prima del pagamento, fissa una scadenza o minaccia di pubblicare dati non sta segnalando una vulnerabilità. Conserva i messaggi, non gestire la trattativa senza aiuto, coinvolgi i tuoi legali e valuta di rivolgerti alle forze dell’ordine.

Perché la prossima segnalazione arrivi nel posto giusto

La segnalazione è finita nella casella sbagliata perché non ce n’era una giusta. Tre cose risolvono il problema:

• Una politica di divulgazione sul tuo sito: che cosa si può testare, come segnalare, che cosa può aspettarsi chi segnala, e il tuo impegno a non perseguire chi rispetta le regole.
• Un file security.txt in /.well-known/security.txt, il primo posto in cui guardano i ricercatori. L’RFC 9116 richiede due campi, Contact ed Expires; dopo la data indicata in Expires il file è considerato scaduto.
• Un processo dietro la casella: chi la legge, chi verifica, chi decide, entro quanto tempo.

È di questo che si compone un programma di divulgazione delle vulnerabilità. Se in questo momento una segnalazione aspetta una risposta, inviaci una richiesta e indicalo: a queste richieste rispondiamo per prime.