Il penetration test è terminato, il report è arrivato. Per chi dirige un’azienda, quel documento dovrebbe aiutare a decidere dove intervenire e quali rischi affrontare. Prima di archiviarlo, vale la pena chiedersi: abbiamo verificato anche i percorsi che potrebbe utilizzare un attaccante? Il caso Wind Tre offre un motivo concreto per porre questa domanda.
I test c’erano. La copertura era adeguata?
Il provvedimento del Garante riguarda due episodi avvenuti presso distinti punti vendita. Attraverso telefonate di ingegneria sociale, gli attaccanti avevano ottenuto accesso remoto ai dispositivi e acquisito fattori di autenticazione.
Nel secondo episodio, le interrogazioni dell’applicazione hanno raggiunto i dati di 365.048 clienti. Gli identificativi venivano incrementati progressivamente per richiamare altri record. Per 41.359 persone erano coinvolte anche informazioni sul metodo di pagamento, con il numero della carta parzialmente oscurato.
Wind Tre dichiarava misure di protezione e verifiche periodiche. Il Garante ha rilevato una copertura inadeguata delle API, le interfacce con cui le componenti software si scambiano richieste e dati. L’Autorità parla di «non corretta definizione del perimetro di analisi» e/o «insufficiente profondità delle verifiche condotte». La sanzione riguarda un insieme di carenze tecnico-organizzative, incluse quelle nella gestione di certificati e credenziali.
Il perimetro deve seguire i flussi reali
Un’applicazione comprende la pagina visibile all’utente e le funzioni che lavorano dietro di essa. Se una ricerca richiama API secondarie, quelle interfacce fanno parte del percorso da valutare. Anche le operazioni disponibili dopo l’accesso meritano attenzione: una credenziale compromessa può diventare il punto di partenza di un abuso.
La guida NIST SP 800-115 dedica la pianificazione alla scelta di obiettivi, sistemi, tecniche e regole della verifica. Per la direzione, questo significa concordare quali processi aziendali debbano essere messi alla prova e rendere esplicite le esclusioni.
La profondità si vede negli scenari
Un sistema può riconoscere l’utente e consentirgli comunque operazioni eccessive. OWASP indica tra i rischi delle API i controlli insufficienti sull’accesso ai singoli oggetti: modificare un identificativo non dovrebbe permettere di consultare informazioni altrui.
Scenari come questi richiedono di esplorare ruoli, richieste e sequenze applicative. Nel caso Wind Tre, il Garante ritiene che verifiche mirate sulle API avrebbero potuto individuare ragionevolmente le carenze poi sfruttate.
È una valutazione su quel caso. Nessun penetration test può promettere di anticipare ogni attacco; può però documentare con chiarezza quali percorsi siano stati esplorati, come e con quali risultati.
Tre domande prima del prossimo incarico
Per valutare il lavoro, chiediamo quali flussi e interfacce siano inclusi; quali scenari possano partire da un accesso già ottenuto; quali evidenze e limiti accompagneranno le conclusioni. Un vulnerability assessment aiuta a individuare e classificare le debolezze; un penetration test ne verifica la sfruttabilità nel perimetro concordato.
Correzioni, nuove verifiche e aggiornamento del perimetro devono seguire i cambiamenti dei sistemi. Il valore del report sta nella possibilità di trasformare ciò che è stato osservato in decisioni, mantenendo visibile ciò che resta da verificare.