Casi d'uso

Dodici scenari. Una sola appliance.

Ogni caso d'uso parte da un problema concreto e lo collega a un flusso di lavoro di Zero Hunt. Tre per pilastro: scenario, problema, soluzione, risultato, tempi. Ognuno ha un link diretto: puoi girare a un collega proprio quello che fa al caso suo.

Pilastro 1 — Pentest generativo

Validazione offensiva continua, con codice di exploit generato dall'AI per ogni target.

Sostituisci il pentest annuale con la validazione continua

⌛ ROI in 30 giorni rispetto al costo annuale del fornitore

Scenario: Paghi €50-150k l'anno a un fornitore di pentest e il report è già superato poche settimane dopo la consegna.
Problema: Il pentest manuale è una fotografia. Quando arriva il PDF, la superficie d'attacco è già cambiata: nuovi IP sul perimetro, nuovi servizi, nuove credenziali. Il prossimo appuntamento con il regolatore è tra sei o dodici mesi, e le evidenze sono già vecchie.
Come lo risolve Zero Hunt: Pianifica campagne continue sull'appliance: quotidiane, settimanali o innescate da un cambiamento (un nuovo IP, un nuovo servizio, una nuova credenziale). Lo sciame di 10 agenti lavora in autonomia e ogni finding è firmato e datato. I pentester senior continuano a guidare le campagne threat-led dalla Red Team Chat interattiva, per le valutazioni in cui l'esperienza umana fa la differenza.
Risultato: Sostituisce l'equivalente di 1-2 FTE di ore di fornitore al mese. Le evidenze sono aggiornate a ogni appuntamento con il regolatore, non solo in fase di audit. Il tempo per validare un nuovo asset scende da "al prossimo incarico" a "entro un'ora".

Per approfondire:Finanza · DORA Art. 25 →Utility · NIS2 →NIS2/DORA e la fine del pentest annuale →

Valuta l'esposizione a un CVE critico in poche ore dall'annuncio

⌛ Ore, non trimestri, per ogni CVE critico

Scenario: Un CVE critico esce alle 22:00 (aggiunta al CISA KEV, advisory del vendor, segnalazione di sfruttamento di massa). Il tuo stack è sulla versione interessata. E adesso?
Problema: La risposta abituale è "aspetta il prossimo pentest in calendario", che può essere a trimestri di distanza. Applicare la patch dice solo che la versione è cambiata, non se quel percorso era davvero sfruttabile nel tuo ambiente. Senza una prova, alla domanda del CdA "siamo vulnerabili?" non sai dare una risposta difendibile.
Come lo risolve Zero Hunt: L'appliance acquisisce di continuo CISA KEV, NVD e advisory dei vendor (21 fonti di intelligence). Quando esce un CVE rilevante, lo sciame di 10 agenti genera un exploit specifico per il tuo ambiente, lo esegue in sandbox contro il tuo inventario e produce un artefatto firmato che prova la sfruttabilità (o la non sfruttabilità). Spesso prima della riunione del mattino.
Risultato: Il tempo tra l'annuncio del CVE e un verdetto difendibile sull'esposizione scende da trimestri a ore. Alla domanda del CdA rispondi sì o no con le evidenze allegate, non con una probabilità.

Per approfondire:Utility · NIS2 →Sanità →Caso CVE-2026-20182 + 31431 →

Esegui campagne TLPT threat-led allineate a TIBER-EU per DORA art. 26

⌛ Ciclo TLPT trimestrale invece del minimo di 3 anni

Scenario: Sei un'entità significativa ai fini di DORA (banca, assicurazione, istituto di pagamento) tenuta a condurre pentest threat-led con metodologia documentata ed evidenze firmate, dall'input di threat intelligence fino alla chiusura.
Problema: Gli incarichi TLPT affidati a fornitori esterni costano €150-400k l'uno, il perimetro si congela al momento dell'acquisto e la tracciabilità metodologica si mette insieme a mano. Una seconda campagna nello stesso anno è rara, anche quando lo scenario di minaccia cambia in modo sostanziale.
Come lo risolve Zero Hunt: L'appliance esegue campagne TLPT compatibili con TIBER-EU, alimentate da 21 feed di threat intelligence in tempo reale. Le fasi della metodologia (fornitura della threat intelligence → test del red team → purple team → chiusura) sono tracciate in modo nativo; ogni artefatto è firmato e concatenato in sequenza, producendo una catena verificabile fino all'input di threat intelligence. Il requisito di evidenza dell'RTS 2025 diventa una query, non un progetto.
Risultato: Evidenze di livello TLPT su richiesta, non una volta ogni 3 anni. Il costo per campagna si riduce al solo tempo di calcolo. Il confronto in audit con EBA e Banca d'Italia passa da "dov'è la documentazione?" a "quale intervallo di tempo?".

Per approfondire:Finanza · DORA Art. 26 →vs Pentera (TLPT) →Approfondimento DORA + NIS2 →

Pilastro 2 — AI Traffic Analysis

Rilevamento alla velocità di linea di ciò che gli strumenti endpoint non vedono.

Intercetta il ransomware durante la cifratura, non dopo

⌛ Rilevamento in secondi, non in ore o giorni

Scenario: Gestisci un ospedale, un'azienda manifatturiera o qualsiasi ambiente attivo 24 ore su 24, dove nel primo trimestre 2026 il tempo mediano all'impatto è sotto le 48 ore e la fase di cifratura, una volta avviata, si esaurisce in 90 minuti.
Problema: I segnali endpoint si accendono durante la cifratura, ma ormai è tardi: i file sono bloccati, i backup corrono contro la nota di riscatto e le 6 ore successive se ne vanno in comunicazioni di crisi. La cadenza a lotti del SIEM (finestre di 15 minuti su query di 24 ore) si perde del tutto l'ondata.
Come lo risolve Zero Hunt: Il Pilastro 2 è un modello di deep learning a 4 head che gira sulla GPU dell'appliance, con un throughput di base di 2.7+ Gbit/s. Riconosce la firma comportamentale di una cifratura in corso — scritture SMB/NFS rapide e a ventaglio, schemi laterali prevedibili, il traffico di privilege escalation che la precede — mentre l'attività è in atto. L'esito arriva al tuo SOAR in pochi secondi; la connessione alla condivisione di file può essere interrotta prima che la cifratura si completi.
Risultato: Il tempo mediano di rilevamento della fase di cifratura scende da ore o giorni a secondi o minuti. La finestra per il recupero si apre prima che la cifratura si completi.

Per approfondire:Sanità · bersaglio n. 1 del ransomware →vs Cymulate (simulazione e rilevamento) →Ransomware senza cifratura 2026 →

Rileva l'esfiltrazione massiva di dati mentre è in corso

⌛ Rilevamento durante l'ondata, non il mattino dopo

Scenario: Affronti la tendenza del 2026: gli affiliati ransomware saltano del tutto la cifratura e vanno dritti all'esfiltrazione massiva e silenziosa dei dati, poi estorcono minacciando di pubblicarli. L'endpoint vede letture legittime. Il SOC non vede nulla.
Problema: Il DLP basato sui volumi non vede l'esfiltrazione preparata a tappe (l'attaccante accumula i dati dentro il perimetro, poi li porta fuori diluendoli su più ore attraverso intervalli CDN legittimi). L'ispezione TLS è ormai in ritirata sotto HSTS preload, ESNI e QUIC. L'unico segnale affidabile è il traffico in uscita dalla rete, ed è proprio lì che i difensori sono più deboli.
Come lo risolve Zero Hunt: Il modello di machine learning sui pacchetti classifica i metadati dei flussi (tempistiche, ventaglio in ingresso e in uscita, distribuzione dei byte, ASN di destinazione, hash JA3/JA4) mentre i pacchetti transitano. Un host che da importatore netto di dati diventa esportatore netto, un flusso in uscita prolungato verso un ASN mai visto, un tunnel SD-WAN che trasporta 10 volte il volume abituale: tutti si accendono durante l'ondata, in tempo per interrompere il collegamento.
Risultato: La scoperta avviene durante la finestra dell'esfiltrazione, non il mattino dopo, quando i dati sono già fuori. I conti alla rovescia verso il regolatore (GDPR art. 33, art. 23 NIS2) partono da quando ne vieni a conoscenza, e una conoscenza che arriva durante l'esfiltrazione, non dopo, è una data che puoi difendere.

Per approfondire:Sanità · art. 33 GDPR →Finanza · DORA artt. 17-22 →Approfondimento sul ransomware di sola esfiltrazione →

Smaschera i C2 occulti su TLS, tunnel DNS e domain fronting

⌛ Rilevamento in minuti sui protocolli C2 nuovi

Scenario: Il tuo EDR lavora per firme. Il tuo NDR lavora per regole. Entrambi si perdono il traffico di comando e controllo che imita il comportamento legittimo — beacon HTTPS, tunnel DNS-over-HTTPS, traffico fatto passare attraverso il tuo stesso provider CDN.
Problema: Gli affiliati potenziati dall'AI riscrivono i protocolli C2 a ogni campagna. Le firme statiche scadono al primo contatto. Il rilevamento a regole richiede uno schema già noto. Il segnale reale — la periodicità dei beacon, il jitter, il ventaglio delle connessioni, le anomalie nel fingerprint del certificato — sfugge a entrambi i livelli.
Come lo risolve Zero Hunt: Uno dei 4 head di inferenza è dedicato all'identificazione del tipo d'attacco, addestrato su miliardi di sequenze PCAP etichettate, compresi gli schemi di traffico C2 occulto. Il modello classifica basandosi solo sui metadati dei flussi: funziona bene anche sui payload cifrati, senza bisogno di ispezione TLS. Il punteggio JA3/JA4 intercetta i casi "sembra legittimo, ma non lo è".
Risultato: I canali C2 emergono entro pochi minuti dall'attivazione, qualunque sia la famiglia di protocollo o la strategia di fronting. Il team di threat hunting riceve una rosa ristretta ad alta affidabilità invece di un milione di alert.

Per approfondire:Supply chain della difesa →vs Cymulate →

Pilastro 3 — Compliance automatica

Evidenze continue, firmate e pronte per il regolatore, per costruzione.

Produci le evidenze dell'art. 23 NIS2 come sottoprodotto dell'attività quotidiana

⌛ Da giorni per incidente a una sola query

Scenario: Sei un'entità essenziale o importante ai sensi della NIS2 (in Italia, decreto legislativo 138/2024). Ogni incidente significativo fa scattare un preallarme entro 24 ore, una notifica entro 72 ore e una relazione finale entro un mese, a partire da quando ne vieni a conoscenza.
Problema: Mettere insieme a mano le evidenze dell'art. 23 richiede giorni per ogni incidente: ricostruzione della cronologia, mappatura dei controlli, esportazione firmata, conversione nel formato richiesto dal regolatore. L'autorità competente — in Italia l'ACN — si aspetta evidenze continue di misure efficaci, non fotografie annuali.
Come lo risolve Zero Hunt: Ogni azione — scansione, finding, evento di traffico, remediation — è firmata nel momento in cui è registrata e mappata in automatico sui controlli degli artt. 21 e 23 NIS2. Il Trust Center esporta con un clic un pacchetto pronto per il regolatore. La timeline 24h / 72h / 1 mese diventa una query su record firmati, non una corsa contro il tempo.
Risultato: La conformità alle scadenze di notifica diventa un flusso interrogabile. Il confronto con l'auditor passa da "mostrami la documentazione" a "seleziona un intervallo di date". Gli organi di gestione, responsabili in prima persona ai sensi dell'art. 20 NIS2, dispongono di un registro firmato di cosa si sapeva, cosa è stato fatto e quando.

Per approfondire:Utility · NIS2 essenziali →PA italiana · decreto 138 →Approfondimento NIS2 + DORA →

Mappa i finding su 34 framework in un solo passaggio

⌛ Circa il 70% di lavoro duplicato in meno tra i framework

Scenario: Affronti più regimi di audit in parallelo — NIS2, DORA, GDPR, ISO 27001, PCI DSS, SOC 2 — che condividono i controlli di fondo ma richiedono ciascuno il proprio formato di evidenza.
Problema: I team GRC tengono catene di evidenze parallele, una per framework. Lo stesso finding viene rimappato a mano 3-6 volte. La deduplica tra framework resta teorica; in pratica il lavoro si moltiplica per il numero di regimi da coprire.
Come lo risolve Zero Hunt: Il motore di compliance mappa in automatico ogni finding sui 34 framework, con la deduplica dei controlli tra framework già integrata. Un punteggio pesato per gravità riflette il modello di rilevanza di ciascun regolatore. I report sono generati per singolo framework a partire dallo stesso archivio firmato.
Risultato: Il lavoro di audit ridondante cala fino al 70%. Un solo finding soddisfa più framework senza rimappature manuali. Le entità con più regimi passano da "costruisci le evidenze per ogni audit" a "pubblica una porzione dell'archivio per ogni audit".

Per approfondire:Finanza · più normative →PA italiana · NIS2 + AgID →

Esporta il pacchetto per l'auditor: firmato, verificabile, ripetibile

⌛ Esportazione con un clic invece di giorni di lavoro manuale

Scenario: Inizia il ciclo di audit. L'auditor chiede "tutte le evidenze relative al controllo X.Y.Z per il primo trimestre". Hai 5 giorni per metterle insieme a partire dai log di SIEM, SOAR, EDR, GRC e sistema di ticketing.
Problema: Mettere insieme le evidenze a mano è la singola attività che porta via più tempo nel GRC. L'autenticità viene messa in dubbio (lo screenshot è stato manomesso?). La catena di custodia è un racconto, non una prova. La riconciliazione tra strumenti diversi introduce errori su cui poi l'auditor scava.
Come lo risolve Zero Hunt: Il Trust Center esporta un pacchetto autonomo, firmato con ECDSA, circoscritto a controlli, periodo e framework. Contiene finding, file di evidenza, eventi di traffico e log di remediation: ogni artefatto porta la firma originale del momento in cui è stato registrato. L'auditor la verifica crittograficamente, senza dover riporre fiducia nella nostra infrastruttura.
Risultato: La preparazione dell'audit si riduce da giorni a una sola operazione di esportazione. Le domande dell'auditor su autenticità e catena di custodia trovano risposta in una verifica crittografica, non in un racconto.

Per approfondire:Difesa · CMMC/TRANSEC →PA italiana · AgID/ACN →

Pilastro 4 — AI Remediation Advisor

Dal finding dimostrato alla correzione verificata, in ordine di rischio reale.

Correggi prima ciò che è stato dimostrato sfruttabile

⌛ Un piano ordinato appena finisce la campagna

Scenario: L'ultimo assessment ha prodotto centinaia di finding e questo mese il tuo team ne può chiudere qualche decina.
Problema: Un elenco ordinato per CVSS mette i critici teorici sopra la falla che un attaccante ha davvero usato, e i possibili falsi positivi consumano le stesse ore di quelli reali. Tre host con la stessa libreria obsoleta diventano tre ticket, e nessuno sa dire quali correzioni riducono di più il rischio.
Come lo risolve Zero Hunt: L'AI Remediation Advisor lavora solo sui finding che la campagna ha dimostrato: verificati o sfruttati. Li ordina per sfruttabilità reale — prima il catalogo CISA KEV, poi ciò che è stato sfruttato in questa campagna, poi CVSS, EPSS e severità — li unisce per CVE in azioni di remediation e distribuisce le azioni in ondate P1–P4, con le correzioni più rapide e di maggior impatto per prime.
Risultato: La prima ondata chiude i percorsi che un attaccante potrebbe usare oggi, non quelli che hanno solo un punteggio alto. Nessuno sforzo va ai finding non confermati, e ogni azione copre tutti gli host coinvolti.

Per approfondire:Playbook: patch d’emergenza KEV →Enterprise · team di sicurezza snelli →

Verifica ogni correzione con la stessa prova che ha trovato la falla

⌛ Correzione verificata il giorno del rilascio

Scenario: Un finding critico è stato corretto, e l'auditor — o il CdA — chiede come fai a sapere che la falla è chiusa.
Problema: Gli advisory generici dicono «aggiorna», non quale endpoint, parametro o payload la correzione deve bloccare. Il nuovo test aspetta il prossimo engagement, così «risolto» resta uno stato del ticket invece di un fatto dimostrato.
Come lo risolve Zero Hunt: Quando l'Exploit Forge ha prodotto un proof of concept per l'host, l'advisor lo legge prima di proporre la correzione, così la correzione colpisce il percorso reale: l'endpoint, il parametro, il payload — e file e riga quando gli agenti avevano accesso al sorgente (gray box). Ogni correzione termina con un passo di verifica; rieseguire la stessa prova, o la campagna su quell'host, mostra se l'exploit funziona ancora.
Risultato: La chiusura è dimostrata il giorno in cui la correzione va in produzione invece che al prossimo test annuale, e la campagna rieseguita ne lascia evidenza firmata per il fascicolo di audit.

Per approfondire:Black box e gray box →Finanza · evidenze di remediation DORA →

Dai a un team snello il piano di correzione di un ingegnere senior

⌛ Dal finding a uno script da rivedere, in una conversazione

Scenario: Gestisci la sicurezza con due o tre persone su Linux, Windows, container e un livello web, con finestre di manutenzione che non controlli.
Problema: «Aggiorna alla versione X» non dice come distribuirla in sicurezza, cosa fare fino alla finestra di manutenzione o come tornare indietro se il servizio si rompe. Scrivere quel piano per ogni finding è lavoro da senior, e il team non ne ha il tempo.
Come lo risolve Zero Hunt: Per ogni voce l'advisor indica la causa radice, la correzione esatta, i comandi pronti da copiare per la tua piattaforma, una nota di rilascio sicuro con il passo di rollback e un controllo compensativo da applicare subito se la correzione vera deve aspettare. Su richiesta scrive uno script di correzione idempotente — bash, PowerShell, Ansible, Dockerfile o configurazione del web server — che salva una copia di ogni file che modifica e termina con un controllo PASS/FAIL. I tuoi tecnici lo rivedono e lo eseguono: l'advisor ha solo strumenti in lettura e non esegue mai nulla.
Risultato: Ogni cambiamento arriva con un percorso di rollback, e ogni correzione è mappata sul controllo che soddisfa — ISO 27001 Allegato A, NIS2, DORA, art. 32 GDPR, PCI DSS, CIS — per il fascicolo di audit.

Per approfondire:Enterprise · team di sicurezza da 1-2 FTE →Utility · finestre di manutenzione →

Vedilo all'opera nel tuo ambiente

Scegli il caso più vicino al problema che hai oggi: prepariamo una demo tecnica di 30 minuti su una porzione registrata del tuo stack.

Richiedi una demo Esplora i settori

Non sei pronto per una demo?