Breach and Attack Simulation (BAS), pentest automatizzato e AEV: differenze

• Breach and Attack Simulation (BAS) risponde a: se un attaccante usasse questa tecnica, i miei controlli la fermerebbero, e il mio team se ne accorgerebbe? Uno strumento BAS ripete scenari d'attacco presi da una libreria, di solito mappati su MITRE ATT&CK, in modo controllato: file malevoli simulati contro i gateway di posta e web, tecniche eseguite da agenti sugli endpoint, tentativi di esfiltrazione contro i sistemi di data loss prevention. Il risultato è una pagella di ciò che è stato bloccato, rilevato o mancato.
• Il penetration test automatizzato risponde a: partendo da qui, cosa può raggiungere davvero un attaccante? Lo strumento individua gli asset, tenta di sfruttare le debolezze, raccoglie e riusa credenziali, si muove lateralmente e riporta i percorsi che hanno funzionato, con le evidenze. Il risultato è un insieme di percorsi d'attacco dimostrati. Vedi penetration test automatizzato.
• L'Adversarial Exposure Validation (AEV) non è una terza tecnica. È la categoria di mercato con cui Gartner indica le tecnologie che forniscono «evidenze coerenti, continue e automatizzate della fattibilità di un attacco» (traduzione nostra), e Gartner precisa che sostituisce la breach and attack simulation e le tecnologie di penetration test e red teaming automatizzati del suo Hype Cycle for Security Operations 2023. Vedi Adversarial Exposure Validation (AEV).

Ogni voce mette a confronto BAS e pentest automatizzato; l'AEV, come categoria, può comprendere l'uno o l'altro.

• Domanda. BAS: i miei controlli bloccano e rilevano le tecniche note? Pentest automatizzato: quali percorsi d'attacco funzionano in questo ambiente?
• Metodo. BAS: ripete scenari catalogati, costruiti per essere innocui. Pentest automatizzato: tenta lo sfruttamento reale e concatena i risultati. La definizione di AEV di Gartner ammette sia l'esecuzione di scenari d'attacco sia la modellazione o la misura dell'esito.
• Punto di partenza. BAS: agenti su endpoint scelti e traffico simulato attraverso i gateway. Pentest automatizzato: una posizione esterna (black box), un set di credenziali o un host dentro la rete (gray box o assumed breach).
• Cosa si installa. BAS: di solito agenti su un campione di endpoint più una console di gestione. Pentest automatizzato: di solito un nodo d'attacco o un'appliance con visibilità di rete, spesso senza agenti sugli endpoint.
• Risultato. BAS: tassi di prevenzione e rilevamento per tecnica, lacune nei controlli, regole di detection da aggiungere. Pentest automatizzato: percorsi dimostrati, credenziali compromesse, host coinvolti, evidenze per ogni passo e correzione per ogni finding.
• Trova percorsi che nessuno aveva previsto? BAS: no, verifica gli scenari della sua libreria. Pentest automatizzato: sì, entro le sue tecniche e il perimetro; gli strumenti autonomi si adattano anche a ciò che trovano.
• Rischio per la produzione. BAS: basso per costruzione, perché le simulazioni sono pensate per essere innocue. Pentest automatizzato: lo sfruttamento reale comporta un rischio reale, quindi controllo del perimetro, soglie di approvazione e arresto di emergenza sono decisivi.
• Chi lo usa. BAS: detection engineering, SOC e architettura di sicurezza. Pentest automatizzato: gestione delle vulnerabilità, sicurezza offensiva e i team che devono correggere.
• Posto nel CTEM. Entrambi servono la fase di validazione del CTEM: la BAS valida i controlli, il pentest automatizzato valida le esposizioni.

La BAS è lo strumento giusto quando la domanda riguarda le difese più che le debolezze. Mostra, tecnica per tecnica, se l'agente sull'endpoint ha bloccato un comportamento, se il SIEM ha generato un allarme, se il gateway di posta ha fermato un payload. È ripetibile, quindi adatta ai test di regressione dopo una modifica alle regole o l'introduzione di un nuovo prodotto, e poiché i suoi scenari sono innocui per costruzione può girare spesso in produzione.

I limiti discendono dallo stesso progetto. Uno strumento BAS verifica gli scenari della propria libreria, quindi non dice nulla di un percorso d'attacco per cui nessuno ha scritto uno scenario. Una tecnica simulata da un agente installato da te non dimostra che un attaccante potrebbe arrivare a quell'endpoint. E i risultati sono aggiornati quanto la libreria: un buon fornitore aggiorna gli scenari in fretta, ma resta un catalogo.

Il penetration test automatizzato è lo strumento giusto quando la domanda riguarda l'esposizione: un attaccante può arrivare da internet, o da una postazione compromessa con il phishing, fino all'amministratore di dominio, al sistema dei pagamenti, alla rete OT? Trova combinazioni che nessun finding isolato rivela, come un account di servizio debole, una password di amministratore locale riutilizzata e un segmento di rete piatto, e le dimostra con evidenze. Gli strumenti autonomi vanno oltre, ragionando su ciò che trovano invece di seguire una sequenza fissa.

I limiti: agisce su sistemi reali, quindi servono controlli di sicurezza robusti e un'autorizzazione chiara. Dice meno sulla detection, perché ti mostra cosa ha funzionato ma non se il SOC se n'è accorto, a meno di incrociare la sua cronologia con gli allarmi. E come ogni automazione, un'esecuzione senza finding dimostra solo che le sue tecniche non hanno funzionato.

Gartner definisce l'Adversarial Exposure Validation come l'insieme di tecnologie che «confermano come le tecniche d'attacco potenziali riuscirebbero a sfruttare un'organizzazione e ad aggirare i controlli di prevenzione e rilevamento», «eseguendo scenari d'attacco e modellando o misurando l'esito per dimostrare l'esistenza e la sfruttabilità delle esposizioni» (traduzione nostra). La definizione copre sia la domanda sui controlli a cui risponde la BAS sia quella sull'esposizione a cui risponde il pentest automatizzato: per questo entrambi i tipi di fornitore oggi descrivono i propri prodotti come AEV.

Per chi compra la conseguenza è semplice: il nome della categoria non dice a quale domanda un prodotto risponde meglio. Chiedi da dove viene il prodotto (una libreria di simulazioni o un motore di sfruttamento), se esegue gli attacchi o li modella, e quali vettori di minaccia copre. Tra le funzionalità che Gartner considera obbligatorie per la categoria ci sono la pianificazione automatica, scenari d'attacco forniti dal vendor che richiedono poche o nessuna competenza di hacking, scenari su più vettori di minaccia e risultati empirici che migliorano i dati teorici, come quelli sulle vulnerabilità.

• Vuoi sapere se EDR, SIEM e gateway di posta e web intercettano le tecniche note, e tarare le regole di detection: BAS, o un prodotto AEV nato come BAS.
• Vuoi sapere se un attaccante può raggiungere i sistemi critici, e correggere prima ciò che è dimostrato sfruttabile: penetration test automatizzato o autonomo.
• Hai un programma CTEM e ti servono evidenze continue per la fase di validazione: AEV, che in pratica spesso significa entrambi gli strumenti, uno per i controlli e uno per le esposizioni.
• Un'autorità richiede un test threat-led o annuale da parte di tester qualificati (TLPT DORA, NYDFS 500.5, CMMC Level 3): un ingaggio condotto da persone, con l'automazione nel frattempo per arrivarci preparati. Vedi TLPT.
• L'ambiente è air-gapped, classificato o non può inviare dati a terzi: il modello di deployment decide prima della categoria. Verifica che lo strumento giri interamente on-premise, senza piano di controllo in cloud e senza servizi AI esterni.
• Ti serve solo l'elenco delle patch mancanti: uno scanner di vulnerabilità. Per questo non serve nessuno dei tre, e nessuno dei tre lo sostituisce.

• Una scansione di vulnerabilità non è una validazione. Lo scanner deduce l'esposizione da versioni e firme; BAS e pentest producono evidenze agendo.
• Modellare un percorso d'attacco non è sfruttarlo. Gli strumenti basati su grafi calcolano quali percorsi sembrano praticabili a partire dai dati di configurazione. È utile per le priorità, ma un percorso modellato resta un'ipotesi finché qualcosa non lo esegue.
• Il red teaming è più ampio di qualsiasi strumento. Un esercizio di red team è una campagna condotta da persone verso un obiettivo, che include social engineering e accesso fisico e spesso non viene annunciata ai difensori. Gli strumenti automatici ne coprono una parte.
• «AI red teaming» spesso significa testare modelli AI. Molti risultati di ricerca per questa espressione parlano di attacchi ai modelli linguistici, non alle reti. Per le infrastrutture i termini più chiari sono pentest autonomo o red team AI autonomo per reti e infrastrutture.

Zero Hunt, il prodotto dietro questo sito, sta dalla parte del pentest automatizzato: è un red team AI autonomo per reti e infrastrutture che tenta lo sfruttamento reale e dimostra quali esposizioni sono sfruttabili, con evidenze per ogni finding. Non è uno strumento BAS. Non ripete scenari di consegna via email o di malware contro i tuoi gateway e non nasce per tarare le regole di detection: se la tua domanda principale è quella, un prodotto nato come BAS è la scelta migliore, e i due approcci convivono bene.

Nella sua categoria, a distinguerlo è il modello operativo. Gira on-premise su AI privata, con i propri modelli sull'appliance e nessun dato del cliente in uscita. Testa in modalità black box e gray box. Cinque livelli di autonomia mantengono una persona nel ciclo per le azioni invasive. Ogni tentativo di attacco è registrato in una catena di hash firmata, e i finding sono mappati su 34 framework di compliance in tutto il mondo. Zero Hunt non è citato da Gartner come vendor AEV.

Guarda il confronto nella pagina delle alternative, leggi del red team AI on-premise o richiedi una demo.

• Adversarial Exposure Validation, definizione del mercato e funzionalità obbligatorie (Gartner Peer Insights)
• Market Guide for Adversarial Exposure Validation, 24 marzo 2026, abstract (Gartner)
• Penetration testing, definizioni del glossario (NIST CSRC)
• Regolamento (UE) 2022/2554 (DORA), articoli 26 e 27 (EUR-Lex)