La sicurezza dell'AI basata sull'oscurità è morta, e i difensori affrontano il problema più difficile
La sicurezza dell'AI basata sull'oscurità è crollata nel 2026, quando gli agenti hanno individuato falle trascurate, accelerato lo sviluppo di exploit e raggiunto sistemi protetti principalmente dalla loro complessità specialistica.
Le prove immediate riguardano componenti Windows dimenticati, librerie open source ampiamente esaminate e controller industriali che gestiscono servizi essenziali. Questi sistemi differiscono sul piano tecnico, ma condividevano una difesa silenziosa. Gli attaccanti necessitavano di competenze rare, notevole pazienza o incentivi economici sufficienti per studiarli.
La scoperta di vulnerabilità tramite AI cambia questo calcolo. I modelli possono interpretare codice sconosciuto, spiegare protocolli proprietari, generare harness di test e automatizzare la ricognizione ripetitiva. Il risultato non è un nuovo principio di sicurezza. È l'eliminazione dell'attrito che permetteva alle organizzazioni di rimandare l'applicazione di quelli esistenti.
Questo crea una difficile inversione per i difensori. Individuare le debolezze sta diventando più economico e rapido, mentre validare le patch, coordinare le divulgazioni, testare i sistemi operativi e modificare pratiche di sviluppo difettose restano processi ostinatamente umani.
La questione non è più se le debolezze nascoste emergeranno. È se i difensori riusciranno a correggere le condizioni che le producono prima che la scoperta automatizzata trasformi ogni sistema trascurato in un bersaglio economicamente conveniente.
La sicurezza dell'AI basata sull'oscurità ha perso il suo fossato economico
L'AI non ha confutato la sicurezza basata sull'oscurità. Ha eliminato la carenza di manodopera che consentiva alle organizzazioni di fingere che l'oscurità funzionasse.
La sicurezza basata sull'oscurità descrive un presupposto progettuale o operativo che dipende dal fatto che architettura, interfacce o debolezze restino difficili da scoprire. Non è mai stata considerata un controllo primario valido. Eppure, l'oscurità offriva comunque una protezione pratica quando l'indagine su un sistema sconosciuto richiedeva specialisti rari e settimane di lavoro concentrato.
Quella protezione funzionava come un fossato economico. Un componente vulnerabile poteva rimanere intatto perché gli attaccanti potevano guadagnare di più prendendo di mira software familiari. Un protocollo proprietario poteva scoraggiare gli esterni perché la documentazione era limitata. Un vecchio sottosistema poteva sottrarsi all'esame perché pochi ricercatori ricordavano persino che esistesse.
L'analisi di sicurezza originale pubblicata il 13 settembre mostra come sia cambiato questo equilibrio. Fornitori e ricercatori indipendenti ora usano agenti AI per esaminare software oscuri, datati e sottoposti a intense revisioni. Gli attaccanti utilizzano capacità correlate per analizzare le correzioni e sviluppare exploit.
Brett Leatherman, vicedirettore della Cyber Division dell'FBI, ha descritto modelli che individuano vulnerabilità significative in componenti open source esaminati dalle comunità per un decennio. Secondo quanto riferito, alcune di queste librerie sono utilizzate in una quota sostanziale dell'infrastruttura web.
Ciò non significa che l'AI comprenda autonomamente ogni sistema o produca in modo affidabile un exploit funzionante. Significa che gli investigatori possono entrare in territori sconosciuti senza partire da zero. Un modello può riassumere il codice, tradurre la documentazione, identificare probabili confini di fiducia e generare script per verificare ipotesi.
I sistemi di AI agentica estendono questa assistenza lungo una sequenza di attività. Un agente può ispezionare file, eseguire strumenti, rivedere i risultati, correggere il proprio approccio e proseguire fino a raggiungere un obiettivo definito. Gli operatori umani continuano a stabilire gli obiettivi e fornire l'infrastruttura, ma la macchina assorbe gran parte del lavoro ripetitivo.
Ecco perché la scoperta di vulnerabilità tramite AI mette sotto pressione tanto il software chiuso quanto quello aperto. Il codice pubblico rende più semplice l'analisi diretta, ma il software chiuso espone comunque binari, firmware, comportamento di rete, documentazione, patch e artefatti di configurazione. I modelli possono correlare questi frammenti a una velocità che cambia l'economia del reverse engineering.
Dustin Childs, che guida la Zero Day Initiative di Trend Micro, ha indicato tecnologie dimenticate affrontate durante la record release di patch Microsoft di settembre. I componenti interessati includevano un client Telnet, Windows RNDIS, NFS Portmapper e Link Layer Topology Discovery.
La loro età è rilevante perché illustra il vecchio compromesso. I componenti legacy potevano sopravvivere senza un'attenzione costante da parte di esperti quando poche persone avevano l'interesse o il background per esaminarli. L'AI offre a ricercatori curiosi e attaccanti una guida economica proprio verso queste aree trascurate.
L'oscurità aggiunge ancora qualche ostacolo. Un protocollo non documentato può rallentare un agente, e un dispositivo proprietario può limitare le evidenze disponibili. Tuttavia, un ostacolo non equivale ad autorizzazione, isolamento, autenticazione o sicurezza della memoria. Non gli si può affidare il compito di fermare un'indagine automatizzata persistente.
Il fossato si è quindi spostato dalla conoscenza nascosta a controlli verificabili. I sistemi necessitano di solidi confini d'identità, esposizione minima, impostazioni predefinite sicure, segmentazione testata e progetti che rimangano sicuri quando il loro funzionamento diventa noto.
Questo è il consolidato principio di sicurezza noto come principio di Kerckhoffs, applicato oltre la crittografia. Un sistema dovrebbe rimanere sicuro anche quando un avversario ne comprende il funzionamento, fatta eccezione per segreti gestiti correttamente, come le chiavi crittografiche.
L'AI rende il principio urgente sul piano operativo. La documentazione non deve più essere pubblicata ordinatamente perché il comportamento di un sistema diventi comprensibile. Una quantità sufficiente di prove frammentarie può ora fornire a un agente una mappa utilizzabile.
Il primo punto di pressione è il software dimenticato
I sistemi sottoposti alla maggiore pressione non sono sempre i più nuovi o preziosi. Sono quelli la cui sicurezza dipendeva dal fatto che nessuno li osservasse da vicino.
La ricerca tradizionale sulle vulnerabilità comprende fasi costose. I ricercatori devono apprendere una base di codice, riprodurne l'ambiente operativo, comprenderne le ipotesi e separare le debolezze significative dalle anomalie innocue. Questi passaggi richiedono spesso più tempo dell'individuazione del codice sospetto stesso.
L'AI può comprimerne diversi. Può scrivere harness, tracciare flussi di dati, confrontare implementazioni correlate e spiegare schemi di programmazione sconosciuti. Può inoltre continuare la scansione quando l'attività diventa ripetitiva, aspetto importante perché l'attenzione umana è limitata.
Questo non garantisce risultati utili. I modelli producono falsi positivi, fraintendono il contesto e talvolta inventano spiegazioni tecniche. Tuttavia, l'assistenza a basso costo consente agli operatori di testare più bersagli e abbandonare percorsi improduttivi senza consumare la stessa quantità di tempo specialistico.
Questa ricerca più ampia cambia quale software diventa attraente. I manutentori di vecchie librerie, prodotti enterprise di nicchia, firmware dei dispositivi e servizi interni poco documentati non possono più presumere che gli attaccanti si concentreranno altrove. Lo sconto garantito dalla loro oscurità si sta riducendo.
La stessa pressione si applica alle vulnerabilità note in attesa di distribuzione. Una volta che un fornitore pubblica una correzione, gli attaccanti possono confrontare le versioni corrette e non corrette. Questo processo, chiamato patch diffing, rivela quale codice è cambiato e aiuta gli investigatori a ricostruire la debolezza sottostante.
L'AI rende il patch diffing più rapido interpretando la modifica, proponendo input di attivazione e generando codice di test. La ricerca di Anthropic sullo sviluppo rapido di exploit ha esaminato come i modelli potessero analizzare vulnerabilità divulgate di recente e supportarne lo sfruttamento prima che ogni organizzazione avesse installato la correzione.
Questo comprime il patch gap, ossia l'intervallo tra la disponibilità di una correzione e la sua effettiva ricezione da parte degli utenti. Il divario è sempre stato pericoloso. L'analisi automatizzata rende ogni ora al suo interno più preziosa per gli attaccanti.
Una recente campagna che coinvolgeva un exploit kit basato su Chromium ha dimostrato il rischio operativo. Secondo quanto riferito, gruppi di spionaggio hanno sfruttato vulnerabilità dopo che un progetto upstream aveva rilasciato una patch, ma prima che le release stabili downstream raggiungessero tutti gli utenti. L'AI non era necessariamente responsabile di ogni parte di quella campagna, ma rafforza il metodo che rende efficace questa tempistica.
L'open source non è destinato in modo unico al fallimento secondo questo modello. La revisione pubblica offre ai difensori accesso allo stesso codice e consente un'ampia collaborazione. Il problema più profondo è l'esecuzione asimmetrica. Gli attaccanti possono testare molte possibilità, mentre i manutentori devono validare le segnalazioni, evitare regressioni, coordinare i rilasci e supportare gli utenti.
Il software chiuso affronta un problema correlato con minore visibilità pubblica. Un ricercatore assistito dall'AI può comunque esaminare binari, interfacce, comportamento degli errori, pacchetti di aggiornamento, applicazioni mobili e firmware dei dispositivi. I fornitori non possono presumere che trattenere il codice sorgente preservi un durevole mistero tecnico.
Questo lascia ai manutentori un problema crescente di gestione degli arrivi. Un maggior numero di segnalazioni generate dall'AI non significa automaticamente più vulnerabilità confermate. Alcune segnalazioni saranno duplicati, affermazioni incomplete o errori dall'aspetto plausibile generati senza test adeguati.
Il flusso può assorbire gli stessi esperti necessari per correggere debolezze autentiche. I piccoli progetti open source sono particolarmente esposti perché un componente ampiamente distribuito potrebbe avere solo pochi manutentori. La scoperta automatizzata può crescere indipendentemente dalla loro capacità di revisione.
Le organizzazioni devono quindi misurare più del numero di segnalazioni. Indicatori utili includono il tempo per riprodurre il problema, il tempo per determinarne la gravità, la quota di risultati duplicati, il tempo di validazione delle patch e la ricorrenza per classe di vulnerabilità.
Queste misure distinguono il miglioramento della sicurezza dalla semplice attività. Un team che chiude centinaia di segnalazioni a basso rischio mentre una falla di injection ricorrente permane nel suo processo di sviluppo corre più velocemente senza ridurre l'esposizione futura.
I sistemi industriali perdono la loro barriera specialistica
La tecnologia operativa mostra perché il crollo dell'oscurità comporta conseguenze che vanno oltre la normale manutenzione del software.
La tecnologia operativa, o OT, controlla processi fisici come il trattamento delle acque, le linee di produzione, la distribuzione di carburante e le apparecchiature elettriche. I sistemi di controllo industriale combinano spesso hardware di lunga durata, protocolli proprietari, software ingegneristico specializzato e rigorosi requisiti di disponibilità.
Questo ambiente ha storicamente scoraggiato molti attaccanti. Comprendere un controllore logico programmabile, o PLC, richiedeva conoscenze dei processi industriali e delle comunicazioni specifiche dei dispositivi. Verificare una teoria poteva anche rischiare di interrompere operazioni fisiche.
John Hultquist, chief analyst del Google Threat Intelligence Group, ha sostenuto che la conoscenza specialistica avesse fornito gran parte della protezione pratica attorno ai sistemi industriali. L'AI rende più facile ottenere, organizzare e applicare tale conoscenza.
Il rischio è diventato concreto ad agosto, quando cinque agenzie degli Stati Uniti hanno avvertito di attaccanti che utilizzavano script assistiti dall'AI contro PLC Siemens S7 Series esposti a Internet. Gli ambienti interessati comprendevano impianti idrici, manifattura, energia, chimica, agricoltura e strutture commerciali.
Secondo l'allerta federale sulle minacce, gli operatori combinavano librerie pubbliche per l'automazione industriale con assistenti di coding AI. I loro strumenti imitavano software di monitoraggio legittimi e interagivano con la memoria dei PLC, i dati di configurazione e la logica ladder.
La logica ladder è un linguaggio di programmazione grafico utilizzato per definire il comportamento dei controlli industriali. Modifiche non autorizzate possono influire su apparecchiature reali, anziché limitarsi ad alterare informazioni su uno schermo.
L'attività segnalata ha ridotto le competenze necessarie per operare con il protocollo S7comm utilizzato da questi controller. L'AI potrebbe aiutare gli operatori a generare o modificare script usando informazioni pubbliche. Non ha reso raggiungibile un controller isolato, né ha aggirato ogni controllo di sicurezza correttamente configurato.
L'esposizione è rimasta la condizione abilitante. Secondo quanto riportato, gli attaccanti hanno cercato PLC connessi a internet, con software obsoleto o protetti da credenziali predefinite. Una segmentazione debole ha poi fornito agli script generati un percorso verso funzioni critiche.
Questa distinzione è importante. Definire gli incidenti “attacchi AI” può distogliere le organizzazioni dai controlli che sanno già come implementare. Eliminare l'accesso diretto a internet, modificare le credenziali predefinite, applicare patch ai dispositivi supportati e separare le reti di engineering restano misure essenziali.
La sicurezza dell'AI basata sull'oscurità fallisce più visibilmente quando le organizzazioni confondono la non familiarità con l'isolamento. Un protocollo raro non impedisce l'accesso. Un'interfaccia di engineering proprietaria non autentica il suo utente. Un comando non documentato non ferma un modello addestrato a confrontare esempi e testare risposte.
Allo stesso tempo, i difensori non possono applicare patch agli ambienti industriali come farebbero con laptop consumer. Gli impianti possono programmare la manutenzione con mesi di anticipo. I fornitori potrebbero dover certificare le modifiche. I controller più vecchi possono funzionare per decenni e sostituirli può richiedere un notevole lavoro fisico.
La disponibilità crea anche un dilemma nei test. Un'azione difensiva difettosa può interrompere la produzione o danneggiare le apparecchiature. Gli attaccanti hanno meno ragioni per evitare interruzioni, mentre gli operatori devono convalidare ogni modifica rispetto ai vincoli di sicurezza e operativi.
Questa asimmetria spiega perché una migliore rilevazione da sola non è sufficiente. I proprietari hanno bisogno di inventari accurati delle risorse, accesso remoto controllato, monitoraggio della rete e percorsi di comunicazione applicati. Dovrebbero identificare qualsiasi traffico verso un PLC proveniente da una workstation non destinata all'engineering e indagare sulle scritture al di fuori delle finestre di modifica approvate.
Un data diode, che permette alle informazioni di viaggiare in una sola direzione, può proteggere gli ambienti in cui la telemetria deve uscire ma i comandi non devono mai tornare. Una segmentazione efficace può limitare l'effetto di una workstation compromessa o di uno script generato.
Si tratta di controlli architetturali, non di tentativi di nascondere il sistema. Presuppongono che gli attaccanti comprendano le apparecchiature e negano comunque loro un percorso utilizzabile.
La lezione si estende al software aziendale. Un sistema non dovrebbe restare sicuro solo perché la sua API interna non è documentata o il suo pannello amministrativo usa un indirizzo imprevedibile. L'AI sta trasformando costantemente questi ostacoli in brevi attività di ricerca.
La scoperta delle vulnerabilità tramite AI supera la capacità di riparazione
Il compromesso centrale della sicurezza non è più tra scoperta e ignoranza. È tra scoperta alla velocità delle macchine e correzione limitata dai vincoli umani.
Katie Moussouris, fondatrice e CEO di Luta Security, ha identificato triage, prioritizzazione e riparazione come i veri colli di bottiglia. Trovare ulteriori debolezze ha un valore limitato se le organizzazioni non riescono a stabilire quali contano o a eliminarne le cause.
È qui che le letture ottimistiche della scoperta di vulnerabilità tramite AI diventano incomplete. Un modello che produce dieci volte più risultati plausibili può peggiorare la sicurezza quando la coda di revisione non dispone di prove affidabili, test riproducibili e responsabilità chiare.
I difensori devono rispondere a diverse domande per ogni segnalazione. Il comportamento è reale? Un attaccante può raggiungerlo? Quali privilegi sono richiesti? Lo sfruttamento attraversa un importante confine di fiducia? La correzione proposta comprometterà il comportamento previsto?
Le patch generate dall'AI sembrano offrire un'accelerazione corrispondente. Un modello può ispezionare il codice vulnerabile, suggerire una modifica e generare test. Tuttavia, le prove attuali mostrano che la creazione di patch rimane molto meno affidabile dell'individuazione di comportamenti sospetti.
Un team di ricerca di 1Password ha valutato 6.080 patch generate per sei vulnerabilità divulgate di recente usando due modelli di frontiera. Solo il 26,0 percento ha risolto completamente la vulnerabilità senza modificare materialmente il comportamento dell'applicazione.
Un ulteriore 20,1 percento ha corretto la vulnerabilità, ma ha alterato il funzionamento dell'applicazione. Più seriamente, il 53,9 percento non ha risolto la debolezza, ha introdotto un'altra vulnerabilità o ha fatto entrambe le cose, secondo lo studio sulla convalida delle patch.
Questi risultati non stabiliscono un tasso di fallimento universale per ogni modello, linguaggio o vulnerabilità. I ricercatori hanno deliberatamente selezionato difetti recenti e complessi che richiedevano riparazioni sostanziali. Difetti più semplici e suite di test più robuste possono produrre risultati diversi.
Lo studio espone comunque lo squilibrio centrale. Generare una modifica al codice convincente è più facile che dimostrare che preservi ogni importante proprietà di sicurezza e funzionale.
Alcune riparazioni proposte hanno bloccato in modo ristretto l'input noto della proof-of-concept senza affrontarne la causa sottostante. Questo schema può produrre una patch che supera un test di base pur restando vulnerabile a input alternativi.
Le patch generate dall'AI ereditano anche debolezze dagli ambienti che le valutano. Una suite di test incompleta non può confermare comportamenti che non verifica mai. Un modello può ottimizzare il superamento dei test visibili, anche quando questi rappresentano solo una frazione del contratto di sicurezza.
Una ricerca separata su oltre 100 modelli e 80 attività di programmazione ha rilevato un tasso medio di codice sicuro del 56 percento. Il risultato ha esaminato codice generato anziché la correzione delle vulnerabilità, ma rafforza la necessità di una convalida indipendente.
Le organizzazioni dovrebbero evitare di leggere questi dati come prova che l'AI non possa assistere il lavoro difensivo. I modelli possono predisporre modifiche, generare test di regressione, spiegare funzioni poco familiari e confrontare correzioni alternative. Questi usi possono ridurre lo sforzo di engineering quando gli esperti mantengono l'autorità finale.
Il pericolo inizia quando la velocità diventa la principale metrica di successo. Una patch distribuita rapidamente ma senza una convalida adeguata può mantenere il difetto originale, crearne uno nuovo o modificare silenziosamente le regole di accesso.
L'automazione difensiva deve quindi basarsi sull'esecuzione. Ciò significa compilare ed eseguire le modifiche proposte, testare le proprietà di sicurezza, confrontare i comportamenti e rifiutare le patch che violano invarianti definiti. Un invariante è una condizione che deve rimanere vera in ogni implementazione accettabile.
La revisione umana rimane necessaria per i sistemi ad alto impatto perché i test non catturano mai l'intero contesto operativo. Gli ingegneri devono comprendere perché la debolezza esisteva, quali assunzioni sono fallite e se il codice correlato contiene lo stesso schema.
Questo è più lento che generare una patch. È anche il lavoro che trasforma una segnalazione di vulnerabilità in una riduzione duratura del rischio.
Più segnalazioni non risolveranno processi di sicurezza difettosi
Le organizzazioni che rispondono all'AI con una coda di patch più grande resteranno intrappolate, perché il volume non corregge il processo che ha prodotto i difetti.
Un programma di gestione delle vulnerabilità può sembrare produttivo mentre il rischio continua a crescere. I team contano le segnalazioni critiche, i tempi di chiusura e il totale delle patch perché questi numeri sono facili da raccogliere. Rivelano attività, ma non sempre indicano se il software sta diventando più sicuro.
Moussouris ha avvertito che le organizzazioni non possono vincere aggiungendo all'infinito risorse alla scoperta e alla riparazione individuali. La risposta sostenibile consiste nell'identificare schemi e modificare i sistemi che creano classi ricorrenti di vulnerabilità.
Supponiamo che una revisione assistita dall'AI trovi decine di difetti di injection. Correggere ogni istanza è importante, ma l'opportunità maggiore si trova più a monte nello sviluppo. I team possono introdurre template più sicuri, gestione centralizzata degli input, protezioni del framework e test che impediscano il ritorno dello stesso difetto.
Questa è la differenza tra trattare le segnalazioni e migliorare un controllo di sicurezza. Il primo approccio riduce l'esposizione immediata. Il secondo modifica la velocità futura con cui l'esposizione si manifesta.
Le organizzazioni dovrebbero collegare i dati sulle vulnerabilità alla proprietà del codice, alle decisioni architetturali e agli standard di sviluppo. Se un servizio produce ripetutamente errori di autorizzazione, la leadership deve esaminare il suo modello di accesso anziché celebrare una chiusura più rapida dei ticket.
Lo stesso ragionamento vale per l'infrastruttura. Segnalazioni ricorrenti riguardanti interfacce amministrative esposte suggeriscono un fallimento nella gestione delle risorse o nella governance di rete. Correggere un server senza modificare lo schema di distribuzione lascia intatto il meccanismo sottostante.
Una risposta matura alla sicurezza dell'AI basata sull'oscurità inizia con un inventario onesto. I team devono sapere quali componenti sono distribuiti, chi li mantiene, quali interfacce sono raggiungibili e cosa accade quando il supporto termina.
Le distinte dei materiali software possono aiutare a identificare le dipendenze, ma un inventario deve andare oltre i nomi dei pacchetti. Le organizzazioni necessitano inoltre di versioni del firmware, modelli dei dispositivi, servizi cloud, API interne, autorizzazioni ereditate e risorse di tecnologia operativa.
I sistemi di conoscenza creano un'altra forma di rischio da oscurità. Gli assistenti AI possono far emergere documenti, messaggi, trascrizioni e note a cui i dipendenti erano tecnicamente autorizzati ad accedere, ma che raramente avrebbero scoperto manualmente.
Non si tratta necessariamente di un aggiramento dell'autorizzazione da parte dell'AI. Può essere l'esposizione di autorizzazioni che erano da sempre troppo ampie. L'AI riduce lo sforzo necessario per trovare materiale sensibile all'interno di tali autorizzazioni.
I team che adottano sistemi di ricerca aziendale o retrieval dovrebbero esaminare proprietà dei contenuti, conservazione, ereditarietà degli accessi e confini di indicizzazione prima di una distribuzione estesa. Una base di conoscenza AI ben progettata dovrebbe preservare le autorizzazioni della fonte invece di trattare tutte le informazioni indicizzate come ugualmente disponibili.
Ciò richiede anche un logging accurato. I team di sicurezza necessitano di registri che mostrino a cosa ha avuto accesso un agente, quali strumenti ha invocato, quali modifiche ha proposto e chi ha approvato le azioni consequenziali. Senza queste evidenze, i flussi di lavoro automatizzati diventano più difficili da investigare rispetto ai sistemi legacy che sostituiscono.
La riforma dei processi dovrebbe includere requisiti rigorosi di acquisizione per le segnalazioni di vulnerabilità generate dall'AI. Le segnalazioni dovrebbero identificare le versioni interessate, descrivere il confine di fiducia, fornire passaggi di riproduzione e separare il comportamento osservato dalla speculazione generata dal modello.
I manutentori possono quindi usare l'automazione per raggruppare i duplicati, verificare i dettagli ambientali e dare priorità alle segnalazioni con impatto dimostrato. L'obiettivo non è respingere la ricerca assistita dall'AI. È richiedere prove proporzionate al volume delle affermazioni.
Anche i team di procurement hanno un ruolo. Gli acquirenti dovrebbero chiedere ai fornitori come testano le patch generate dagli agenti, gestiscono i componenti legacy, affrontano la divulgazione coordinata e misurano le classi ricorrenti di vulnerabilità. Una promessa di “usare l'AI per la sicurezza” offre poche garanzie senza questi dettagli.
La visione scettica resta importante. I modelli attuali sono incoerenti e le dimostrazioni impressionanti usano spesso ambienti curati. Alcune segnalazioni dell'AI richiedono ampie correzioni umane, mentre lo sfruttamento completamente autonomo resta meno comune dello scripting assistito e della ricognizione.
Tuttavia, l'incoerenza non ripristina il vecchio fossato. Un attaccante non ha bisogno che ogni tentativo funzioni. Prove parallele a basso costo possono rendere operativamente prezzo un basso tasso di successo, soprattutto contro molti bersagli simili.
I difensori devono pianificare tenendo conto di questa economia. Dovrebbero presumere che codice, binari, configurazioni e patch accessibili riceveranno un esame automatizzato. Il loro vantaggio deve derivare da una progettazione più sicura e da una risposta verificata più rapida, non dalla speranza che l'esame fallisca.
Tre segnali mostreranno se i difensori riusciranno a recuperare terreno
La prossima fase sarà decisa dalla verifica delle patch, dall'esposizione delle infrastrutture critiche e dalla capacità delle organizzazioni di prevenire difetti ricorrenti invece di limitarvisi a contarli.
Il primo segnale è l’affidabilità misurata delle patch generate dall’AI. Le valutazioni future dovrebbero testare vulnerabilità divulgate di recente, preservare il comportamento realistico delle applicazioni e pubblicare metodi riproducibili. Un tasso crescente di correzioni complete ridurrebbe l’attuale divario tra individuazione e rimedio.
Il risultato importante non è che una patch venga compilata. I ricercatori devono verificare che elimini la causa principale, eviti nuove debolezze e preservi il comportamento previsto. Miglioramenti che resistono a valutazioni indipendenti rafforzerebbero l’argomento a favore di un’automazione difensiva supervisionata.
Tassi di fallimento vicini ai livelli attuali sosterrebbero una conclusione più prudente. L’AI continuerebbe ad aumentare i volumi delle individuazioni, mentre la validazione da parte di esperti rimarrebbe la risorsa limitante.
Il secondo segnale è l’esposizione dei controllori industriali e di altri sistemi legacy. Agenzie e operatori dovrebbero monitorare se i PLC accessibili da Internet diminuiscono, se le credenziali predefinite scompaiono e se le organizzazioni rilevano traffico non autorizzato dei protocolli industriali.
Un’altra ondata di attacchi assistiti dall’AI contro controllori esposti rafforzerebbe la valutazione centrale. Dimostrerebbe che gli attaccanti stanno ripetutamente trasformando conoscenze pubbliche in strumenti funzionanti contro sistemi ancora protetti da un’architettura debole.
Una riduzione duratura dell’esposizione indebolirebbe la previsione più allarmante. Non ripristinerebbe l’oscurità, ma dimostrerebbe che l’isolamento di base e la gestione degli asset possono negare agli agenti una via d’attacco pratica.
Il terzo segnale riguarda il modo in cui le organizzazioni di sicurezza misurano i progressi. Un team concentrato solo sul numero di rilevamenti e sul tempo mediano di chiusura avrà difficoltà man mano che le segnalazioni automatizzate si moltiplicano. Un team che monitora classi di difetti ricorrenti, asset esposti, cause principali e rimedi convalidati può ridurre la domanda futura.
Osservate se fornitori e grandi progetti software pubblicheranno queste misure più approfondite. Prove che i difetti di injection, autorizzazione, sicurezza della memoria o configurazione stanno diminuendo suggerirebbero che i cambiamenti di processo stanno funzionando.
Se i totali delle divulgazioni continueranno a stabilire record mentre le stesse classi di difetti ricompariranno, i difensori resteranno su quello che Moussouris ha descritto come un tapis roulant. Un’individuazione più rapida rivelerà più rischi senza modificare il meccanismo che li produce.
La risposta pratica inizia ora. Inventariate i sistemi dimenticati, eliminate l’esposizione non necessaria, testate i confini delle autorizzazioni e richiedete prove per ogni affermazione di sicurezza automatizzata. Usate gli agenti per assistere ricercatori e ingegneri, ma mantenete le riparazioni con conseguenze rilevanti dietro test riproducibili e una revisione responsabile.
La sicurezza dell’AI basata sull’oscurità è già una posizione perdente, perché la vecchia difesa dipendeva da curiosità scarsa e lavoro specialistico. Entrambi stanno diventando disponibili come servizi software.
Il compito più difficile è costruire sistemi che restino sicuri dopo che i loro dettagli diventano comprensibili. Quale dipendenza nascosta, autorizzazione ereditata o controllore esposto la vostra organizzazione vorrebbe meno che un agente AI esaminasse oggi?
