Come valutare una piattaforma di pentest autonomo: piano di pilota e scorecard

La maggior parte delle valutazioni fallisce qui: il pilota parte prima che qualcuno abbia deciso cosa sia un buon risultato.

1. 1Scegli un perimetro rappresentativo. Uno o due segmenti interni con carichi reali, un dominio Active Directory se ne hai uno e una parte del perimetro esterno. Un laboratorio pulito nasconde proprio i problemi per cui compri lo strumento.
2. 2Scrivi le regole d'ingaggio. Host e reti esclusi, finestre di test, azioni mai consentite in produzione, chi può fermare il test e come raggiungerlo.
3. 3Inserisci debolezze note. In un segmento di test prepara alcuni problemi che il tuo team conosce già: una password di amministratore locale riusata, un servizio non aggiornato, una condivisione troppo aperta. Sono la risposta nota con cui misurare cosa sfugge.
4. 4Definisci il successo per iscritto. Per esempio: nessuna azione fuori perimetro, ogni risultato dimostrato, risultati non validi sotto una soglia che scegli tu, quasi tutte le debolezze note trovate, re-test funzionante sui problemi corretti.
5. 5Definisci le condizioni di arresto. Qualsiasi azione fuori perimetro, qualsiasi disservizio non approvato o qualsiasi dato che esce dall'ambiente chiude il pilota.
6. 6Nomina le persone. Un responsabile dalla tua parte, gli approvatori delle azioni soggette ad approvazione e gli analisti che esamineranno i risultati.

Verifica prima la sicurezza: una piattaforma che non si controlla non si può far girare spesso, e la frequenza è il motivo per comprarla.

• Perimetro rigido. Metti un host escluso dentro una rete in perimetro e verifica che l'agente non lo tocchi mai e che l'eventuale tentativo sia registrato. Il perimetro deve essere imposto dalla piattaforma, non lasciato al giudizio del modello.
• Arresto di emergenza. Attivalo a metà di un'esecuzione. Ogni azione in corso deve fermarsi e il registro deve mostrare quando.
• Approvazioni. Chiedi quali azioni partono da sole, quali aspettano una persona e se puoi cambiarlo per ogni campagna. Ogni approvazione deve registrare chi ha approvato cosa e quando. Vedi test di sicurezza AI con human in the loop.
• Limiti di carico e impatto. Controlla come la piattaforma limita carico, blocchi degli account e tecniche invasive su sistemi fragili come OT, stampanti o server legacy.
• Registro completo delle azioni. Devi poter ricostruire ogni comando eseguito dall'agente, su quale host e perché.

Un agente autonomo può descrivere una vulnerabilità che una stringa di versione si limita a suggerire, o credere che un exploit sia riuscito quando non è così. La prova è ciò che separa un risultato da un'ipotesi.

• Per ogni risultato chiedi: la richiesta o la tecnica esatta usata, la risposta del sistema e cosa ha potuto fare l'agente dopo l'accesso, con data e ora.
• Verifica che le evidenze non si possano modificare dopo. Registri firmati e concatenati permettono a un auditor di confermare che il report corrisponde a ciò che è successo.
• Scegli tre risultati e riproducili con il tuo team partendo solo dalle evidenze. Se non ci riesce, le evidenze non bastano né per la correzione né per un auditor.
• Controlla cosa contengono le evidenze. Credenziali catturate e campioni di dati sono sensibili: chiedi dove vengono conservati, chi li vede e come vengono cancellati alla fine.

Conta ciò che i tuoi analisti accettano, non ciò che mostra la dashboard.

• Risultati non validi. Fai segnare a ogni analista ogni risultato come valido, non valido o duplicato. La quota non valida è il costo di verifica che pagherai ogni settimana. Nel confronto ICLR 2026 tra agenti AI e pentester professionisti anche l'agente migliore si è visto scartare circa una segnalazione su cinque: chiedi a ogni fornitore come misura la propria.
• Ciò che sfugge. Confronta i risultati con le debolezze che hai inserito. Uno strumento che segnala molto ma non trova i tuoi problemi noti è rumoroso, non accurato.
• Gravità nel contesto. Verifica che la gravità rifletta cosa può raggiungere un attaccante da quel punto nel tuo ambiente, non solo il punteggio CVSS.
• Duplicati e rumore. Una causa deve essere un risultato con molti host coinvolti, non cinquanta ticket.

• Percorsi di attacco, non elenchi

  Il valore di un red team autonomo è concatenare: una credenziale debole porta a un server, poi a un amministratore di dominio, poi a un sistema critico. Chiedi almeno un percorso mostrato passo per passo.

• Interno ed esterno

  Verificali entrambi, e controlla se l'agente può partire da una posizione di compromissione presunta su una normale postazione.

• Identità

  Gli errori di configurazione di Active Directory e delle identità cloud sono il terreno su cui si muovono gli attacchi reali. Guarda cosa testa l'agente e come lo dimostra.

• Black box e gray box

  Fai un'esecuzione senza credenziali e una con un normale account utente: la differenza mostra quanto l'agente dipende da ciò che gli dai.

• Cosa non testa

  Logica di business delle applicazioni su misura, social engineering e accesso fisico restano di solito alle persone. Un fornitore che promette tutto è un segnale d'allarme.

Il pilota dura qualche settimana; lo strumento lavora per anni. Valuta il lavoro intorno.

• Re-test. Correggi due risultati e chiedi alla piattaforma di ritestarli. Deve ripetere il percorso originale e mostrare che non funziona più.
• Passaggio ai ticket. Controlla l'esportazione verso il tuo sistema di ticket e le indicazioni di correzione: sono abbastanza precise per il team che gestisce il sistema?
• Report. Guarda separatamente il riepilogo per la direzione e il report tecnico, e la mappatura sui framework per cui rendiconti, come NIS2, DORA, PCI DSS o ISO 27001.
• Tempo degli analisti. Misura quanto dura la verifica di ogni risultato. Quel numero, moltiplicato per la frequenza delle esecuzioni, è il vero costo in personale.
• Deployment e dati. Dove girano i modelli, cosa esce dalla rete e se funziona air-gapped è trattato nella checklist in 15 domande per l'acquisto on-premise.

• Nessun pilota sulla tua rete,

  solo demo nel laboratorio del fornitore o su sfide pubbliche.

• Punteggi di benchmark senza metodo

  Un punteggio su sfide che il fornitore poteva studiare in anticipo non è alla cieca. Chiedi chi ha fatto la misura e su cosa.

• Risultati senza prova,

  o prove limitate a screenshot e output di scanner.

• Perimetro affidato al modello,

  che deve seguire istruzioni, invece di un limite imposto dalla piattaforma.

• Nessun arresto di emergenza attivabile da te,

  o uno che impiega minuti ad agire.

• I tuoi dati escono dalla rete

  per inferenza o analisi senza una risposta chiara e contrattuale su dove finiscono.

• «Sostituisce del tutto i tuoi pentester»

  I test guidati dai regolatori, come il TLPT di DORA, richiedono ancora team umani.

1. 1Settimana 0: preparazione. Concorda perimetro, regole d'ingaggio, criteri di successo e di arresto; inserisci le debolezze note; installa la piattaforma e collega gli approvatori.
2. 2Settimana 1: test di sicurezza e prima esecuzione. Verifica di proposito il rispetto del perimetro e l'arresto di emergenza, poi esegui una campagna black box sul perimetro esterno e su un segmento interno al livello di autonomia più prudente.
3. 3Settimana 2: profondità. Esegui una campagna gray box da compromissione presunta con un normale account utente. Esamina i percorsi di attacco e fai classificare agli analisti ogni risultato.
4. 4Settimana 3: correzione e re-test. Correggi alcuni risultati e le debolezze note, poi ritesta. Riproduci tre risultati partendo solo dalle evidenze.
5. 5Settimana 4: voto e decisione. Compila la scorecard, misura il tempo di analisi per risultato e confronta con i criteri scritti nella settimana 0.

Per vedere come funziona il pentest autonomo dall'inizio alla fine prima del pilota, parti dalla guida. Per confrontare prima le piattaforme sulla carta, usa il confronto tra strumenti di pentest automatizzato e l'OWASP Autonomous Penetration Testing Standard come linguaggio comune per i requisiti.

Quanto deve durare un pilota di pentest autonomo? Di solito bastano due-quattro settimane: una per i test di sicurezza e una prima esecuzione, una per un'esecuzione gray box più profonda, una per correggere e ritestare, e il tempo per dare il voto. I piloti più brevi raramente includono un re-test, ed è lì che molti strumenti cedono.

È sicuro fare un pilota in produzione? Solo con un perimetro imposto dalla piattaforma, un arresto di emergenza che controlli tu e l'approvazione umana per le azioni invasive. Parti dal livello di autonomia più prudente e da segmenti dove un disservizio sarebbe tollerabile.

Come misuro i falsi positivi? Fai segnare agli analisti ogni risultato come valido, non valido o duplicato, e inserisci debolezze note per misurare ciò che sfugge. Contano entrambi i numeri: pochi falsi positivi con molte mancanze non è un buon risultato.

Posso fidarmi dei punteggi di benchmark dei fornitori? Solo se la misura era alla cieca e fatta da qualcuno diverso dal fornitore. I risultati su sfide pubbliche che il fornitore poteva studiare non sono alla cieca. Un pilota sulla tua rete è una guida migliore.

Cosa deve dire il contratto dopo il pilota? Perimetro e regole d'ingaggio, chi approva le azioni soggette ad approvazione, dove stanno dati e modelli, come vengono conservate e cancellate le evidenze e come funziona il re-test. La checklist per l'acquisto on-premise citata sopra elenca le domande su dati e deployment.

Dove si colloca Zero Hunt? Zero Hunt è un red team AI autonomo su un'appliance on-premise con modelli propri, quindi i dati dei test restano nella tua rete. Limiti di perimetro e arresto di emergenza sono imposti dalla piattaforma, gli operatori scelgono uno di cinque livelli di autonomia che decidono quali azioni aspettano un'approvazione, e ogni risultato è supportato da evidenze firmate Ed25519 e concatenate con hash. Non pubblica ancora numeri di benchmark; la metodologia di valutazione è in preparazione, e si può valutare con il pilota descritto qui.