Penetration test black box e white box: quale scegliere

In un penetration test black box il tester parte senza informazioni, come un attaccante esterno. In un white box riceve i dettagli completi di reti e applicazioni, per il software anche il codice. Il grey box sta in mezzo, con credenziali o schemi parziali. Si sceglie in base al rischio da misurare: l'estraneo su internet, l'utente con un accesso, il difetto nel codice.

La scelta non è una questione di gusti né di prezzo soltanto: cambia quali vulnerabilità il test può trovare e quali resteranno fuori dal report. Qui vediamo cosa misura ciascuna modalità secondo le fonti che i tester usano davvero (le linee guida NIST SP 800-115, la guida al penetration testing del PCI Security Standards Council e la OWASP Web Security Testing Guide), un errore di lettura frequente e i criteri per decidere. Se ti serve prima il quadro generale, parti dalla guida su cos'è un penetration test.

Le tre modalità in breve

La classificazione più chiara è quella della Penetration Testing Guidance del PCI Security Standards Council (Information Supplement, settembre 2017, sezioni 1.3 e 2), che distingue tre tipi di penetration test in base a quanto il committente rivela prima che il test cominci:

• Black box: il committente non fornisce alcuna informazione prima dell'inizio. Il tester deve scoprire da solo cosa esiste e cosa è esposto.
• White box: il committente può fornire dettagli pieni e completi sulla rete e sulle applicazioni.
• Grey box: il committente fornisce dettagli parziali sui sistemi bersaglio. Nella pratica sono di solito account di test, l'elenco degli indirizzi o la documentazione delle API.

Nelle applicazioni la distinzione si fa più concreta. NIST SP 800-115, nell'appendice C, chiama white box le tecniche che analizzano direttamente il codice sorgente, black box quelle che lavorano sull'eseguibile dell'applicazione senza conoscerne il sorgente, e grey box la combinazione delle due.

Black box: cosa misura e cosa lascia fuori

Il black box risponde a una domanda precisa: cosa vede e cosa riesce a fare chi arriva da internet senza sapere niente di te? È il test che più somiglia al primo contatto di un attaccante opportunista, e per questo dà una misura realistica della superficie esposta: servizi dimenticati, sottodomini, pannelli di amministrazione raggiungibili, informazioni che trapelano da fonti pubbliche.

Il limite sta nel tempo. Un attaccante vero ha settimane o mesi, un test ha un numero definito di giornate, e in black box una parte di quelle giornate se ne va a ricostruire informazioni che il committente conosce già. La guida PCI lo dice in chiaro: un test black box può richiedere più tempo, denaro e risorse per arrivare a un risultato che soddisfi i requisiti del PCI DSS, e i penetration test per il PCI DSS si svolgono di norma in white box o grey box, perché danno risultati più accurati e una verifica più completa.

C'è poi un limite di profondità. La OWASP Web Security Testing Guide, nell'introduzione, indica la revisione del codice come lo strumento per trovare difetti sottili, come errori di logica applicativa, debolezze crittografiche e race condition, che dall'esterno, in prospettiva black box, sono difficili da rilevare. Un black box pulito quindi non dice che quei difetti non ci sono: dice che non si vedevano da fuori, in quel tempo.

White box: la copertura più ampia

In white box il tester lavora con la mappa in mano: architettura, configurazioni, inventario degli asset, per le applicazioni anche il sorgente. Il tempo che il black box spende a scoprire va invece in analisi, e la copertura cresce.

NIST SP 800-115 (appendice C) aggiunge due osservazioni utili per chi sviluppa software in casa. La prima: per le applicazioni custom le tecniche white box tendono a essere più efficienti e convenienti delle black box nel trovare difetti di sicurezza. La seconda è il rovescio: l'analisi del codice da sola non rileva i difetti nelle interfacce fra componenti né i problemi introdotti in compilazione, nel linking o nella configurazione al momento dell'installazione. NIST indica le tecniche black box soprattutto per i componenti compilati ad alto rischio, per le interazioni fra componenti e con utenti, altri sistemi e ambiente esterno, e per capire come l'applicazione regge alle minacce.

Il white box quindi non è il black box con più informazioni: è un'altra domanda. Il black box chiede cosa ottiene un estraneo, il white box chiede dove sono i difetti, anche quelli che oggi nessuno ha ancora raggiunto.

Grey box: chi ha già un piede dentro

Il grey box riproduce uno scenario molto concreto: qualcuno che ha già un accesso. Un utente con credenziali valide, un fornitore con un accesso limitato, un attaccante che ha rubato la password di un dipendente. Il tester riceve quello che quel profilo avrebbe, e da lì prova a spingersi oltre.

Per le applicazioni web è spesso l'unica scelta sensata. Senza account di test la parte autenticata resta fuori, e lì stanno di solito i controlli di autorizzazione: un utente che legge i dati di un altro, un ruolo base che arriva a funzioni da amministratore. Ne parliamo nel dettaglio nell'articolo sul web application penetration test, dove la raccomandazione è dare credenziali per ciascun ruolo.

Conoscenza e segretezza sono due assi diversi

Un equivoco frequente è pensare che black box significhi anche test segreto. Non è così. NIST SP 800-115, al paragrafo 2.4.2, tratta un asse separato: il test palese (overt), svolto con la conoscenza e il consenso dello staff IT, e il test occulto (covert), svolto senza che lo staff IT lo sappia ma con il permesso pieno della direzione.

Le due scelte si combinano. Un test può essere black box e palese (il tester non sa niente, ma il team IT è avvisato) oppure grey box e occulto. Secondo NIST il test occulto serve a misurare il danno che un avversario può causare e la reazione del personale, non a identificare tutte le vulnerabilità; è spesso lungo e costoso perché il tester deve rallentare per non farsi notare, mentre il test palese costa meno, comporta meno rischi ed è il più usato. In cambio, l'occulto dà un'indicazione più fedele della sicurezza di tutti i giorni, perché gli amministratori non sono in allerta. Quando l'obiettivo diventa mettere alla prova anche chi rileva e risponde, si entra nel campo descritto nell'articolo su red team, blue team e purple team.

Come scegliere: quattro situazioni tipiche

Vuoi sapere cosa è esposto su internet

Un black box sul perimetro esterno è la risposta diretta. Se poi prevedi anche un test interno con lo stesso team, NIST SP 800-115 (paragrafo 2.4.1) suggerisce di fare prima quello esterno, così i tester non acquisiscono conoscenze sull'architettura che un avversario non avrebbe e che renderebbero il risultato meno attendibile.

Hai un'applicazione sviluppata in casa

Qui il white box rende di più, perché l'accesso al codice e alla documentazione porta il test sui difetti di logica che da fuori non si vedono. Conviene affiancarlo a prove black box sulle interazioni fra componenti e con l'esterno, che l'analisi del codice non vede: la combinazione delle due è quella che NIST chiama grey box.

Ti preoccupano utenti, fornitori e credenziali rubate

Il grey box con credenziali per ogni ruolo è lo scenario che risponde meglio: misura cosa succede quando l'attaccante supera il login, che è il punto in cui molte violazioni cominciano.

Il test serve per la conformità

Per le carte di pagamento, la guida del PCI SSC osserva che i test per il PCI DSS si fanno di norma in white o grey box. Nel finanziario, DORA all'articolo 26 prevede per le entità identificate dalle autorità un test di penetrazione guidato dalla minaccia (TLPT) almeno ogni tre anni, sui sistemi attivi di produzione che supportano le funzioni essenziali o importanti: è un esercizio diverso dal penetration test ordinario, che trattiamo nell'articolo su test di resilienza DORA e TLPT.

Le fasi non cambiano, cambia il punto di partenza

Qualunque modalità tu scelga, il test segue le stesse quattro fasi descritte da NIST SP 800-115 al paragrafo 5.2.1:

1. Pianificazione: si fissano regole d'ingaggio, approvazioni della direzione e obiettivi. È qui che si decide black, grey o white box.
2. Scoperta: raccolta di informazioni, identificazione di servizi e analisi delle vulnerabilità.
3. Attacco: si verifica se le vulnerabilità potenziali sono sfruttabili; ogni accesso ottenuto può riportare alla scoperta di nuovi sistemi.
4. Reporting: corre in parallelo alle altre fasi e si chiude con il rapporto finale.

La modalità sposta il peso fra le fasi. In black box la scoperta occupa una quota ampia delle giornate; in white box gran parte di quella fase è già coperta dalla documentazione ricevuta e il tempo va all'attacco e all'analisi. Per questo il livello di conoscenza è uno dei fattori che pesano sul costo di un penetration test.

Cosa preparare prima del test

• In ogni caso: autorizzazione scritta, perimetro, finestre temporali, contatti per le emergenze e criteri di stop.
• In grey box: account di test per ciascun ruolo, l'elenco degli indirizzi e dei domini in perimetro, la documentazione delle API.
• In white box: schemi di rete, configurazioni dei sistemi rilevanti, accesso al repository del codice e una persona del team di sviluppo disponibile per le domande.
• In un test occulto: una persona della direzione che sa del test e può confermarlo, così un allarme del team di sicurezza non diventa un incidente vero.

Tre errori da evitare

• Scegliere il black box perché sembra più realistico. È realistico per un attaccante esterno senza informazioni. Se il rischio che ti preoccupa è un account compromesso, il test più realistico è un grey box.
• Leggere un black box senza risultati come un via libera. Dice cosa non si è visto da fuori in un tempo limitato, non che i sistemi sono privi di difetti.
• Non scrivere la modalità nel report. Chi legge il risultato tra un anno, magari un auditor, deve sapere con quali informazioni partiva il tester per interpretarlo. È uno dei punti da controllare in un buon report di penetration test.

Da dove partire

La domanda giusta non è quale modalità sia migliore, ma quale rischio vuoi misurare: l'estraneo che arriva da internet, l'utente che supera il login o il difetto nascosto nel codice. Spesso la risposta è una combinazione, per esempio un black box sul perimetro e un grey box sulle applicazioni critiche. Se vuoi ragionare su perimetro e modalità per la tua azienda, trovi come lavoriamo nei nostri servizi di cybersecurity.