Un penetration test cerca di verificare se debolezze tecniche possano essere sfruttate nel perimetro autorizzato e con quali conseguenze. Per commissionarlo bene occorre definire obiettivi, sistemi, limiti, dati utilizzabili e risultati attesi. Il rapporto finale deve aiutare a correggere e verificare le vulnerabilità, non soltanto produrre un elenco di segnalazioni.
Il NIST SP 800-115 offre un riferimento metodologico per pianificazione e valutazione tecnica. La OWASP Web Security Testing Guide approfondisce il contesto delle applicazioni web. Questi documenti aiutano a impostare l’incarico, senza sostituire la valutazione del sistema concreto o introdurre un obbligo generalizzato di usare un unico metodo.
Definire la domanda dell’incarico
Precisate quale rischio volete esaminare: accesso non autorizzato a dati, separazione fra clienti, privilegi eccessivi, esposizione di un servizio o possibilità di compromettere un percorso critico. Un obiettivo espresso soltanto come «testare la sicurezza» lascia troppa libertà di interpretazione e rende difficile valutare la completezza del lavoro.
Distinguete penetration test, scansione automatica e audit di sicurezza. La scansione può individuare segnali o configurazioni note; il penetration test approfondisce possibilità di sfruttamento nel contesto concordato; l’audit può includere processi e controlli che non si esauriscono nelle prove di attacco. Le attività possono essere complementari.
Il committente deve conoscere il servizio e poter autorizzare il perimetro. La presenza di un dominio dell’organizzazione non implica che ogni infrastruttura sottostante sia liberamente sottoponibile a prove. Chiarite coinvolgimento dei fornitori e condizioni dei servizi esterni prima dell’avvio.
Delimitare sistemi, account e ambienti
Allegate elenco di domini, indirizzi, applicazioni, API e ambienti inclusi. Indicate esclusioni e dipendenze. La mappatura dei sistemi e dei flussi permette di identificare componenti critiche e collegamenti che potrebbero essere toccati indirettamente.
Stabilite livello di conoscenza fornito al valutatore e credenziali di prova disponibili. Per un’applicazione con più ruoli, un solo account può non consentire di esaminare adeguatamente le separazioni. Preparate identità di esercitazione con privilegi differenti, evitando l’uso di account personali ordinari quando non necessario.
Scegliete ambiente di prova o produzione sulla base degli obiettivi e delle differenze reali. Un ambiente di laboratorio può ridurre alcuni rischi, ma potrebbe non rappresentare configurazione, dati e integrazioni effettive. Registrate le differenze e i limiti delle conclusioni che ne derivano.
Scrivere regole di ingaggio comprensibili
L’autorizzazione deve indicare chi esegue le attività, finestra temporale, tecniche ammesse e condizioni di interruzione. Chiarite eventuali esclusioni relative a indisponibilità, ingegneria sociale, accesso fisico o modifica dei dati. L’assenza di un divieto esplicito non dovrebbe essere interpretata come autorizzazione illimitata.
Definite contatti operativi e sostituti, canale di emergenza e modo di riconoscere l’attività autorizzata. Se viene individuata una criticità grave, il valutatore deve sapere come segnalarla senza attendere il rapporto finale. Stabilite anche chi può chiedere una sospensione e come viene documentata.
| Elemento | Decisione da formalizzare |
|---|---|
| Perimetro | Sistemi, account e funzionalità inclusi |
| Finestra | Periodo e limiti orari pertinenti |
| Tecniche | Attività ammesse ed esclusioni |
| Dati | Materiale utilizzabile e modalità di protezione |
| Arresto | Condizioni e contatto per interrompere |
| Segnalazioni | Percorso per criticità urgenti |
| Consegna | Rapporto, evidenze e riesame delle correzioni |
Proteggere dati ed evidenze durante il lavoro
Preferite dati sintetici quando consentono di verificare il controllo. Se l’attività incontra dati reali, limitate raccolta e copia a quanto necessario per dimostrare il problema. Un’esfiltrazione estesa può aumentare il danno senza aggiungere valore alla prova, quando un campione minimo documenta già la possibilità di accesso.
Definite custodia delle evidenze, canali di consegna, persone autorizzate e cancellazione al termine. Il rapporto può contenere dettagli che facilitano un attacco e deve essere trattato come informazione riservata. Evitate distribuzioni ampie o allegati inviati a caselle condivise prive di controllo.
Valutate i ruoli privacy del fornitore in relazione alle operazioni effettive e, quando pertinente, il contratto dell’articolo 28. Non presumete una qualificazione soltanto dal nome del servizio. Chiarite inoltre dove lavorano i valutatori e quali strumenti o subfornitori possono ricevere dati.
Concordare il contenuto del rapporto
Ogni rilievo dovrebbe descrivere sistema coinvolto, condizione osservata, impatto, evidenza minima e proposta di correzione. La gravità deve essere collegata al contesto: una debolezza che consente accesso fra clienti può avere conseguenze diverse da un errore su una funzione pubblica priva di dati personali.
Chiedete una distinzione fra vulnerabilità confermate, ipotesi da approfondire e limitazioni del test. La riproducibilità deve essere sufficiente per chi corregge, senza diffondere istruzioni o segreti oltre il gruppo autorizzato. La direzione può ricevere una sintesi separata che espliciti rischio e priorità.
Conservate versione e periodo della prova. Un risultato riguarda una configurazione in un momento determinato; non costituisce una garanzia permanente di assenza di vulnerabilità. Le esclusioni devono comparire anche nella sintesi, affinché chi legge soltanto il documento breve non attribuisca al test una copertura maggiore di quella reale.
Trasformare i rilievi in correzioni
Assegnate ogni rilievo a un proprietario e definite la priorità in base a esposizione, conseguenze e possibilità di abuso. Distinguete mitigazione immediata e correzione strutturale. Una restrizione temporanea può ridurre il rischio mentre viene sviluppata una modifica, ma deve avere un riesame e non scomparire dalla visibilità del progetto.
Il rafforzamento di Windows e Linux può affrontare debolezze di configurazione; problemi applicativi richiedono invece interventi sul processo di autorizzazione, validazione o gestione delle sessioni. Non chiudete un rilievo con una misura che non incide sul percorso dimostrato.
Valutate se la stessa causa sia presente in altri sistemi o funzioni. Una vulnerabilità in una pagina può derivare da un componente condiviso. La correzione dovrebbe affrontare la causa nel perimetro pertinente, senza presumere che la modifica dell’unico esempio segnalato elimini tutte le manifestazioni del problema.
Verificare il risultato e gli effetti collaterali
Concordate una nuova verifica delle correzioni, con criteri di accettazione. Il valutatore deve poter confermare che il percorso precedente non sia più possibile e che la misura non sia soltanto cosmetica. Documentate versione corretta, esito e eventuali limitazioni della prova successiva.
Verificate anche il funzionamento del servizio. Una correzione che blocca utenti legittimi o elimina dati necessari può introdurre un altro problema. Il referente applicativo deve confermare i casi d’uso essenziali, mentre il controllo di sicurezza esamina l’efficacia della protezione.
I log di sicurezza possono aiutare a verificare se gli eventi del test siano stati rilevati e presi in carico. Tenete distinta la valutazione delle difese di rilevazione dal successo della correzione tecnica: sono risultati diversi e possono richiedere azioni separate.
Integrare il lavoro nella gestione del rischio
Collegate esiti e azioni al dossier di approvazione della sicurezza. Se rimangono vulnerabilità, la decisione sull’uso del servizio deve considerarne conseguenze e condizioni. Un’accettazione interna del rischio non elimina obblighi applicabili né sostituisce una correzione necessaria.
L’articolo 32 GDPR comprende la verifica e valutazione dell’efficacia delle misure. Il penetration test può contribuire a tale lavoro quando pertinente, insieme ad altri controlli. Il fascicolo finale dovrebbe permettere di seguire ogni rilievo dalla prova iniziale alla decisione e alla verifica della correzione, mantenendo chiari perimetro, limiti e responsabilità.
Alla fine dell’incarico, revocate gli account creati per le prove e verificate la rimozione di file, agenti o configurazioni temporanee concordate. Chiedete conferma della gestione delle evidenze e conservate la documentazione necessaria al riesame. Un test può lasciare accessi utili al valutatore ma non più necessari al servizio; la chiusura operativa deve quindi essere parte della consegna, con un referente che ne confermi l’esecuzione.