Palo Alto Networks ha annunciato Unit 42 Continuous Frontier AI Defense, un servizio pensato per valutare in modo continuo applicazioni web, API e infrastruttura cloud. L'azienda lo propone come abbonamento annuale e permette di scegliere il mix di modelli AI usati per cercare vulnerabilità, collegare segnali e suggerire una correzione.
Perché è importante
- Palo Alto Networks ha annunciato Unit 42 Continuous Frontier AI Defense, un servizio globale in abbonamento per cercare vulnerabilità e possibili percorsi d'attacco.
- Il servizio combina Claude Mythos 5, GPT-5.6-Cyber e modelli open-weight, con scelta del mix in base alle esigenze del cliente.
- I test continui possono ridurre il tempo tra una modifica e la scoperta di un rischio, ma non sostituiscono autorizzazioni, revisione umana, log e gestione delle patch.
Che cosa offre Unit 42
La differenza rispetto a un audit occasionale è il ritmo. Ogni modifica a un'applicazione o a una configurazione cloud può aprire un percorso inatteso; un controllo continuo prova a intercettarlo prima che diventi un incidente. Il valore dipende però dalla qualità degli accessi e dalla capacità di distinguere un finding reale da un'ipotesi.
Palo Alto dichiara che il servizio può fornire fix a livello di codice e opzioni di virtual patching. La proposta è interessante, ma l'azione automatica deve restare separata dalla scoperta: prima si conferma il problema, poi si valuta una modifica reversibile. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare.
Perché usare più modelli
Il servizio usa Claude Mythos 5, GPT-5.6-Cyber e modelli open-weight. Palo Alto sostiene che nessun singolo modello abbia trovato più del 40% delle vulnerabilità in un ambiente complesso e che i risultati dei due modelli principali si sovrapponessero meno del 10%. Sono dati dichiarati dall'azienda e vanno verificati su ambienti indipendenti prima di trasformarli in una promessa generale.
L'idea del modello multiplo ha una logica: sistemi addestrati su dati diversi possono vedere segnali diversi. Più modelli non significano però automaticamente più sicurezza. Aumentano costi, tempi, gestione delle versioni e possibilità di ricevere suggerimenti incompatibili tra loro. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare.
La pipeline deve quindi conservare quale modello ha generato ogni finding, quali prove lo sostengono e chi ha deciso la priorità. Senza questa traccia, la varietà diventa soltanto una lista di risposte difficili da confrontare. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare.
Cosa puoi farci concretamente
- Definire quali applicazioni, API, repository e asset cloud possono essere testati e con quali finestre autorizzate.
- Misurare vulnerabilità confermate, falsi positivi, percorsi non trovati e tempo dalla scoperta alla correzione.
- Conservare evidenze, prompt, modello usato e approvazione della remediation prima di applicare una modifica automatica.
Il confine tra scansione e modifica
Un sistema che trova una vulnerabilità può anche proporre una patch. Le due attività hanno profili diversi: la prima produce un'ipotesi verificabile, la seconda cambia un ambiente che può essere in produzione. Un flusso sicuro crea prima un caso di prova, registra il diff e verifica rollback, test e dipendenze.
Le organizzazioni devono definire finestre e limiti. Non ogni asset può essere sottoposto a test aggressivi in qualunque momento; non ogni suggerimento può essere applicato senza un responsabile. Le autorizzazioni devono coprire sia la lettura sia le azioni eventuali. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare.
Anche la gestione dei dati conta. Log, sorgenti, configurazioni e risultati possono contenere informazioni sensibili. Prima di collegare il servizio, il cliente deve sapere dove vengono elaborati i dati, per quanto tempo restano disponibili e come revocare gli accessi. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare.
Il test minimo prima dell'abbonamento
Una PMI può valutare una difesa AI continua con un perimetro ridotto: una web app non critica, alcune API e un ambiente cloud di prova. Il confronto deve includere scanner tradizionali, revisione umana e il servizio multi-modello, usando vulnerabilità già confermate e casi innocui. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare.
Le metriche più utili sono precisione, falsi positivi, vulnerabilità mancate, tempo di triage e tempo di correzione. Va misurato anche il costo operativo: un finding che richiede ore di verifica può annullare il vantaggio della scoperta automatica. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare.
Unit 42 interpreta una direzione del mercato: gli attaccanti usano AI per aumentare velocità e scala, mentre i difensori cercano di fare lo stesso. La soluzione non è affidare la sicurezza a un modello, ma creare un ciclo governato in cui più modelli propongono, le persone verificano e ogni cambiamento resta reversibile.
Fonti
Documenti, comunicati e pubblicazioni consultati per ricostruire dati e contesto.
