Penetration test automatizzato: come funziona, limiti e come scegliere

Il NIST definisce il penetration test come «una metodologia di test in cui i valutatori, di norma entro vincoli specifici, tentano di aggirare o superare le funzioni di sicurezza di un sistema». La parola chiave è tentano: una scansione di vulnerabilità che confronta le versioni del software con un catalogo non è un penetration test, per quanto sia automatica. Tra i tre approcci cambia chi decide il tentativo successivo.

• Penetration test manuale. Un tester, o un team, pianifica ed esegue ogni passo. Porta giudizio e creatività ed è l'unica opzione per alcuni bersagli, ma costa, si fa poche settimane l'anno e dipende dalla bravura delle singole persone.
• Penetration test automatizzato. Il software esegue sequenze d'attacco predefinite: individua gli host, associa i servizi a debolezze note, prova exploit e attacchi alle credenziali già noti e segue i percorsi che si aprono. È ripetibile e può girare a calendario, ma resta limitato alle tecniche che i suoi autori hanno codificato.
• Penetration test autonomo (agentico). Agenti AI leggono ciò che trovano, formulano un'ipotesi, scelgono o scrivono l'azione successiva e vanno avanti finché l'ipotesi non è dimostrata o smentita. Sanno gestire situazioni che nessun playbook prevedeva, e proprio per questo il loro comportamento è meno prevedibile. È qui che i controlli di sicurezza descritti più avanti contano di più.

Sul mercato queste etichette si usano con disinvoltura. Guarda il meccanismo: lo strumento segue una sequenza fissa o decide il passo successivo? E tenta davvero lo sfruttamento, o lo deduce?

Quasi tutti gli strumenti, comunque si presentino, seguono lo stesso ciclo:

1. Perimetro e regole d'ingaggio. Intervalli di indirizzi, domini e applicazioni inclusi; cosa è escluso; finestre di test; quali azioni richiedono approvazione; chi può fermare il test.
2. Ricognizione. Host, servizi esposti, versioni del software, applicazioni web, identità e relazioni di fiducia.
3. Analisi. Confronto di ciò che è stato trovato con debolezze note, configurazioni errate e credenziali predefinite o deboli, e scelta di cosa provare per primo.
4. Tentativi di sfruttamento. Provare a usare davvero una debolezza, entro i limiti fissati dall'operatore. È il passo che distingue un penetration test da una scansione.
5. Post-exploitation. Da un punto d'appoggio: escalation dei privilegi, raccolta di credenziali, movimento laterale e la catena che porta ai sistemi che contano.
6. Evidenze e report. Ogni finding con i comandi, le risposte e gli artefatti che lo dimostrano, una severità e le indicazioni per correggerlo.
7. Retest. Dopo la correzione si ripete la stessa prova, per dimostrare che il percorso è chiuso.

Poiché dal passo 2 al 7 lavora il software, il ciclo può ripetersi ogni settimana o dopo ogni modifica rilevante invece che una volta l'anno. È questo il valore principale dell'automazione: frequenza e costanza, non un singolo test migliore.

Le informazioni di partenza decidono quale attaccante rappresenta il test. Un test black box parte solo dal perimetro autorizzato: è il punto di vista di un attaccante esterno. Un test gray box parte da una conoscenza parziale, come le credenziali di un utente standard, la documentazione o il codice sorgente del software in uso: è il punto di vista di un insider, o di un attaccante che ha già rubato un account con il phishing o ha studiato il bersaglio.

I due rispondono a domande diverse. Il black box misura ciò che è esposto; il gray box misura cosa può fare un attaccante informato dietro il login. Molti strumenti offrono anche un avvio in modalità assumed breach, da un host già dentro la rete. Chiedi quali modalità supporta lo strumento e come conserva e usa le credenziali che gli fornisci. Vedi penetration test black box e gray box.

Uno strumento automatizzato agisce su sistemi di produzione, e uno agentico scrive da sé le proprie azioni. La sicurezza non può poggiare su un documento di perimetro: deve imporla il motore. Pretendi almeno:

• Verifica del perimetro a ogni azione. Il bersaglio di ogni chiamata a uno strumento, e ogni indirizzo presente nel codice generato, confrontati con il perimetro autorizzato al momento dell'esecuzione, non solo all'avvio della campagna. L'host dello strumento stesso escluso. Estensione del perimetro agli host scoperti in corsa solo con un consenso esplicito, e registrata.
• Soglie di approvazione. Autonomia graduale, in cui decidi quali classi di azione attendono una persona: sfruttamento, attacchi alle credenziali, tutto ciò che può modificare lo stato di un bersaglio, test di denial of service. L'autonomia completa deve essere una scelta deliberata, non l'impostazione predefinita.
• Un arresto di emergenza. Un solo comando che ferma ogni operazione, sopravvive al riavvio dello strumento e si può revocare solo con una decisione esplicita dell'operatore.
• Limiti di velocità e finestre di test, perché ricognizione e sfruttamento non saturino sistemi fragili né girino fuori dagli orari concordati.
• Isolamento del codice generato. Il codice di exploit gira in un ambiente confinato che non può raggiungere l'infrastruttura di chi esegue il test.
• Un registro a prova di manomissione di ogni azione, degli agenti e degli operatori, per ricostruire cosa è successo se qualcosa si rompe.

Chiedi ai fornitori di mostrarti questi controlli in funzione, non di descriverli. Una prova semplice durante un pilota: avvia una campagna, attiva l'arresto di emergenza, riavvia il servizio e verifica che resti fermo.

L'automazione aumenta frequenza e costanza. Non rende superflui i tester umani, e uno strumento che promette il contrario sta esagerando.

• Difetti di logica applicativa. Abusare di un flusso di approvazione, di una procedura di rimborso o di una regola di prezzo richiede di capire cosa l'applicazione dovrebbe fare. Gli strumenti migliorano, ma la maggior parte di questi difetti la trovano ancora le persone.
• Social engineering e accesso fisico. Phishing, telefonate pretestuose all'help desk ed entrare in un edificio fanno parte delle intrusioni reali e dei test threat-led, e restano fuori da ciò che fa uno strumento di test di rete.
• Decisioni su perimetro e rischio. Quali sistemi si possono testare, quanto rischio per la produzione è accettabile e se un finding conta per il business sono decisioni di persone che ne rispondono.
• Interpretazione. Trasformare i finding in un racconto per il consiglio di amministrazione, un'autorità o un auditor, e decidere cosa correggere prima in base alle priorità del business.
• Assenza di prove. Un'esecuzione automatica senza finding dimostra che le tecniche provate non hanno funzionato. Non dimostra che nient'altro funzionerebbe.

Il modello che funziona è una combinazione: test automatizzati o autonomi in continuo, persone qualificate per i test approfonditi periodici e per ciò che gli strumenti non raggiungono, e i finding dello strumento come input per quelle persone, non come loro sostituto.

Diverse norme fissano requisiti su chi esegue il test, e uno strumento automatizzato da solo non li soddisfa.

• TLPT ai sensi del DORA. Le entità finanziarie individuate dalla propria autorità competente devono svolgere un threat-led penetration test almeno ogni tre anni, su sistemi di produzione che supportano funzioni essenziali o importanti (Regolamento (UE) 2022/2554, art. 26). I tester devono avere la massima idoneità e reputazione; disporre di capacità tecniche e organizzative e di competenze specifiche in threat intelligence, penetration test e red teaming; essere certificati da un organismo di accreditamento di uno Stato membro o aderire a codici di condotta o quadri etici formali; fornire una garanzia indipendente o una relazione di audit sulla gestione dei rischi del test; ed essere coperti da un'assicurazione di responsabilità professionale (art. 27, par. 1). L'uso di tester interni richiede l'approvazione dell'autorità, ogni tre test va incaricato un tester esterno, e gli enti creditizi significativi possono usare solo tester esterni (art. 26, par. 8, e art. 27, par. 2). Vedi TLPT e il playbook sull'ingaggio TLPT DORA.
• NYDFS 23 NYCRR 500.5(a)(1). Penetration test dall'interno e dall'esterno del perimetro dei sistemi informativi, eseguiti «da un soggetto qualificato, interno o esterno, almeno una volta l'anno». Vedi il playbook NYDFS Part 500.
• CMMC Level 3, CA.L3-3.12.1e. Penetration test almeno una volta l'anno o quando si apportano modifiche di sicurezza significative al sistema, «avvalendosi di strumenti di scansione automatici e di test ad hoc condotti da esperti della materia». Il requisito li cita entrambi. Vedi il playbook CMMC Phase 2.

In tutti i casi la lettura è la stessa: l'automazione produce evidenze tra un esercizio obbligatorio e l'altro e aiuta ad arrivarci preparati, mentre l'esercizio obbligatorio resta in mano a persone qualificate.

Usa queste domande in una richiesta d'offerta o in un pilota. Separano strumenti che in una demo sembrano uguali.

1. Modello di deployment. È un SaaS, un piano di controllo in cloud con un agente nella tua rete, o tutto on-premise? Può funzionare senza alcuna connessione a internet? Gartner osserva che i prodotti della sua categoria Adversarial Exposure Validation sono in genere erogati come SaaS, con o senza agenti on-premise: non dare per scontato l'on-premise.
2. Dati in uscita. Cosa lascia la tua rete: mappe di rete, finding, credenziali recuperate, screenshot, prompt verso un modello AI? Dove gira il modello AI e chi altro tratta quei dati? Vengono usati per addestrare modelli?
3. Prova di sfruttamento. Lo strumento tenta davvero lo sfruttamento o lo deduce dalle versioni? Cosa contiene l'evidenza di un finding? Come assegna la severità ai finding che non è riuscito a dimostrare?
4. Approvazione umana. Quali azioni attendono una persona a ciascun livello di autonomia? Si può impostare per singola campagna? Ogni approvazione è registrata con nome e ora?
5. Controlli di sicurezza. Perimetro verificato a ogni azione, arresto di emergenza, limiti di velocità, finestre di test e nessun test di denial of service se non lo abiliti tu.
6. Evidenze. Puoi dimostrare che i registri dei test non sono stati alterati? Sono firmati, concatenati e verificabili offline? Si possono esportare per un auditor?
7. Mappatura di compliance. Su quali framework mappa i finding, e come? Uno strumento che dichiara di sostituire un test previsto dalla legge è un campanello d'allarme.
8. Copertura e modalità. Rete interna, Active Directory, applicazioni web, API, cloud, OT; black box e gray box; gestione delle credenziali.
9. Retest. Ogni correzione si può ritestare su richiesta con la stessa prova, ed è compreso nel prezzo?
10. Modello di prezzo. Per asset o indirizzo IP, per test, a consumo (crediti o token), in abbonamento, oppure un'appliance. Calcola quanto costerà testare in continuo, non quanto costa un singolo test: il prezzo a consumo cresce proprio con i test che vorresti fare di più.
11. Un pilota sulla tua rete. Scegli un segmento con debolezze che conosci già e guarda cosa lo strumento trova, cosa dimostra e cosa gli sfugge.

Le sezioni precedenti vogliono essere utili qualunque strumento tu scelga. Questa descrive come risponde alla checklist Zero Hunt, il prodotto dietro questo sito.

• Deployment e dati. Zero Hunt è un'appliance on-premise che esegue un red team AI autonomo per reti e infrastrutture su AI privata: i modelli proprietari ZeroHunt Apex girano sulla GPU dell'appliance, senza servizi AI esterni. Nessun dato del cliente lascia l'appliance. Un'appliance connessa scarica aggiornamenti firmati e threat intelligence pubblica; la modalità air-gapped disattiva l'OSINT pubblico e il download di codice sorgente pubblico.
• Come testa. Un controller coordina dieci agenti specializzati: ricognizione, analisi delle vulnerabilità, sfruttamento, sfruttamento web, credenziali, post-exploitation, pivoting, pianificazione tattica su ATT&CK, analisi del sorgente e reportistica. Le campagne girano in black box per impostazione predefinita, e in gray box tramite test autenticati con credenziali fornite da te o tramite l'analisi del sorgente della versione esatta del software in uso.
• Human in the loop. Cinque livelli di autonomia. Al più basso ogni scansione attiva attende approvazione; al successivo i test di exploit e sulle credenziali; poi i test di exploit e di denial of service; poi solo i test di denial of service; il più alto non ha soglie di approvazione e si sceglie in modo esplicito. La verifica dello sfruttamento è abilitata solo ai due livelli più alti. Sotto, un operatore può eseguire un singolo proof of concept dopo un consenso scritto e nominativo, con il perimetro riverificato in quel momento; il motore propone un verdetto e l'ultima parola spetta all'operatore. Vedi human in the loop.
• Sicurezza. Il perimetro è verificato sulle chiamate agli strumenti e negli script generati, gli indirizzi dell'appliance sono esclusi, l'estensione del perimetro in corsa è su consenso ed è registrata, e l'arresto di emergenza resta attivo anche dopo un riavvio finché un operatore non lo revoca.
• Evidenze e compliance. Ogni tentativo di attacco è un record firmato Ed25519 in una catena di hash SHA-256 per campagna; report e pacchetti esportati sono firmati ECDSA. I finding sono mappati su 34 framework di UE, USA, Regno Unito, Canada, APAC, Medio Oriente, America Latina e Africa.
• Costo. L'appliance ha un costo fisso, senza tariffe a token, qualunque sia il numero di campagne.

Zero Hunt non sostituisce i tester qualificati richiesti da TLPT, NYDFS Part 500 o CMMC Level 3: offre test continui, supportati da evidenze, tra un esercizio e l'altro. Confrontalo con altri strumenti nella pagina delle alternative, leggi del red team AI on-premise o richiedi una demo. Correlati: BAS, pentest automatizzato e AEV e Adversarial Exposure Validation (AEV).

• Penetration testing, definizioni del glossario (NIST CSRC)
• Regolamento (UE) 2022/2554 (DORA), articoli 26 e 27 (EUR-Lex)
• 23 NYCRR Part 500 come modificato dal Second Amendment (NYDFS, PDF)
• 32 CFR Part 170, programma CMMC, inclusa la tabella 1 al §170.14(c)(4) (eCFR)
• Gartner Predicts AI Agents Will Reduce The Time It Takes To Exploit Account Exposures by 50% by 2027 (comunicato Gartner, 18 marzo 2025)
• Adversarial Exposure Validation, definizione del mercato (Gartner Peer Insights)