Palo Alto Networks ha presentato Unit 42 Continuous Frontier AI Defense il 22 settembre come servizio annuale per valutare con continuità applicazioni web, API, identità, repository e infrastrutture cloud. La promessa non è soltanto trovare un difetto, ma provare se quel difetto può diventare un percorso d'attacco e portare una correzione prioritaria al team giusto.
Perché è importante
- Palo Alto Networks ha annunciato Unit 42 Continuous Frontier AI Defense, un servizio globale in abbonamento per cercare, validare e aiutare a correggere esposizioni.
- Il servizio usa Claude Mythos 5, GPT-5.6-Cyber e modelli open-weight orchestrati da un harness multi-modello.
- I numeri sulle prestazioni sono dichiarazioni del fornitore: servono prove indipendenti, autorizzazioni e revisione umana prima di applicare patch.
Che cosa offre Unit 42
La differenza rispetto a un audit periodico è il ritmo. Una configurazione cambiata o una nuova release può aprire un'esposizione poche ore dopo il test precedente. Un controllo continuo riduce il tempo di scoperta, ma il risultato dipende dal perimetro autorizzato, dagli accessi e dalla capacità di distinguere un finding confermato da una semplice ipotesi.
L'azienda indica anche suggerimenti a livello di codice e virtual patching. Scoprire e modificare sono però attività diverse: una pipeline sicura crea prima un'evidenza riproducibile, poi propone una modifica reversibile e chiede una decisione esplicita. La verifica va ripetuta su casi reali, con una persona responsabile, una misura osservabile e un risultato reversibile.
Perché il servizio usa più modelli
Unit 42 dichiara di combinare Claude Mythos 5, GPT-5.6-Cyber e modelli open-weight tramite un harness che assegna il compito al modello più adatto. Secondo Palo Alto, nessun singolo modello ha superato il 40% di copertura in ambienti complessi e i risultati dei principali modelli si sovrapponevano per meno del 10%: sono dati del fornitore, non una misura universale.
L'orchestrazione può ridurre i punti ciechi, perché modelli addestrati su dati diversi possono osservare segnali differenti. Aumenta però costi, latenza, versioni da governare e possibilità di ricevere suggerimenti incompatibili. Più modelli non equivalgono automaticamente a una difesa migliore. La verifica va ripetuta su casi reali, con una persona responsabile, una misura osservabile e un risultato reversibile.
Per essere utile, ogni finding deve conservare quale modello lo ha prodotto, quale prova lo sostiene e chi lo ha validato. Senza questa traccia la varietà diventa una lista di risposte difficile da confrontare e da contestare. La verifica va ripetuta su casi reali, con una persona responsabile, una misura osservabile e un risultato reversibile.
Cosa puoi farci concretamente
- Definire perimetro, finestre autorizzate e asset che possono essere testati.
- Misurare vulnerabilità confermate, falsi positivi, problemi mancati e tempo dalla scoperta alla correzione.
- Conservare modello, evidenze, approvazione e rollback per ogni remediation.
Il confine tra scansione e modifica
Un agente che individua una vulnerabilità può anche proporre una patch, ma l'impatto operativo cambia radicalmente. La scansione produce un'ipotesi da verificare; la patch altera un ambiente che può essere in produzione. Un flusso prudente separa i permessi, registra il diff, prova il rollback e richiede test prima di applicare il cambiamento.
Le finestre di test devono essere definite insieme ai responsabili dei sistemi. Non ogni asset può sopportare una simulazione aggressiva, e non ogni suggerimento può essere eseguito senza una persona nominata. Le autorizzazioni devono coprire sia la lettura sia le azioni eventuali. La verifica va ripetuta su casi reali, con una persona responsabile, una misura osservabile e un risultato reversibile.
Anche i dati sono parte della sicurezza. Log, sorgenti, configurazioni e risultati possono contenere segreti o dati personali. Prima del collegamento l'azienda deve sapere dove vengono elaborati, per quanto tempo restano disponibili e come revocare gli accessi. La verifica va ripetuta su casi reali, con una persona responsabile, una misura osservabile e un risultato reversibile.
Il test minimo prima dell'abbonamento
Una PMI può iniziare con una web app non critica, alcune API e un account cloud di prova. Il confronto deve includere scanner tradizionali, revisione umana e servizio multi-modello, usando vulnerabilità già confermate e casi innocui per misurare precisione e falsi positivi. La verifica va ripetuta su casi reali, con una persona responsabile, una misura osservabile e un risultato reversibile.
Le metriche più utili sono problemi confermati, vulnerabilità mancate, tempo di triage, tempo di correzione e costo operativo. Un finding che richiede ore di verifica può annullare il vantaggio della scoperta automatica, mentre una patch applicata senza prove può aumentare il rischio. La verifica va ripetuta su casi reali, con una persona responsabile, una misura osservabile e un risultato reversibile.
Il lancio interpreta una direzione del mercato: gli attaccanti usano AI per aumentare velocità e scala, e i difensori cercano di fare lo stesso. La scelta responsabile non è affidarsi 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.
