Il manuale del difensore per la scoperta delle vulnerabilità potenziata da LLM

Poiché gli aggressori utilizzano modelli di linguaggio di grandi dimensioni per trovare ed esplorare le CVE più rapidamente, i fornitori devono passare dal trovare più bug a correggere, distribuire e implementare le patch più velocemente.

Conclusioni

• La velocità di risoluzione è ora il fattore di rischio principale. Gli aggressori possono individuare le vulnerabilità più rapidamente con i modelli di linguaggio di grandi dimensioni (LLM), ma la vera esposizione deriva dalla lenta distribuzione delle patch e dai ritardi nelle correzioni.
• Profili di fornitori diversi richiedono strategie difensive diverse. L'attrattiva del prodotto e l'adozione dell'IA influenzano il comportamento degli attaccanti, il che significa che non esiste un manuale di sicurezza valido per tutti.
• Tattiche non ortodosse possono ridurre il vantaggio dell'attaccante, ma comportano costi reali. Tecniche come l'offuscamento delle patch, le modifiche ai tempi di divulgazione o gli sforzi di depistaggio possono introdurre rischi legali, operativi e di fiducia.

Il mio ultimo articolo su come si comporteranno gli attaccanti ha mostrato cosa faranno una volta che i LLM inonderanno il sistema con nuove Vulnerabilità ed Esposizioni Comuni (CVE). Questo saggio esamina cosa potrebbero fare i difensori in risposta. Alcune mosse sono ovvie. Altre infrangono le norme e comportano rischi. Raggruppiamo secondo i quattro tipi di fornitori di quell'articolo, quindi elenchiamo ogni mossa con i suoi compromessi.

I quattro segmenti di fornitori, riassunti

L'articolo precedente classificava i fornitori lungo due assi: la velocità con cui stanno adottando l'IA e quanto il loro prodotto sia attraente per gli attaccanti. Ciascuno dei quattro gruppi di fornitori affronta un diverso manuale d'attacco, quindi ciascuno necessita di una difesa diversa.

Raccomandazioni per segmento

Gruppo Fornitori 1 — Prime morbide (prodotto attraente, lenta adozione dell'IA)

• Profilo di attacco: Il più attaccato dei quattro gruppi; i prodotti sono preziosi da compromettere.
• Vincolo chiave: Più lento ad accelerare, a causa di pipeline di sviluppo obsolete e regole di approvvigionamento.
• Perché questo è il playbook: Non possono superare gli attaccanti nei prossimi anni. "Adotta semplicemente la scansione assistita da LLM più velocemente" non colmerà il divario da solo.

Mosse ortodosse:

• Esegui una rapida revisione interna assistita da LLM dei percorsi di codice maggiormente colpiti dagli attaccanti: autenticazione, deserializzazione, server-side request forgery (SSRF).
• Punta a raggiungere il Gruppo Fornitori 2 entro 18 mesi.
• Impegnarsi pubblicamente in una tempistica per il rilascio delle patch in modo che i clienti possano pianificare di conseguenza.
• Investi nell'automazione delle soluzioni prima di automatizzare la scoperta.

Opzioni non ortodosse:

• Rilasciare patch false insieme a quelle reali.
• Nascondi cosa cambia effettivamente ogni patch.
• Variare i tempi di emissione delle CVE.
• Coordinare le comunicazioni con le flotte dei clienti.

Consulta il catalogo qui sotto per sapere come funziona ciascuno, i suoi rischi e quando utilizzarlo.

Gruppo fornitori 2 — Treadmillers (prodotto attraente, rapida adozione dell'IA)

• Profilo di attacco: Vive con il tapis roulant delle differenze di patch. Gli aggressori eseguono il reverse engineering di ogni patch non appena viene distribuita.
• Vincolo chiave: Ogni CVE che pubblicano viene fornito con una patch, e ogni patch è un esempio di addestramento etichettato consegnato agli aggressori.
• Perché questo è il playbook: La finestra di vulnerabilità dalla pubblicazione allo sfruttamento si è già ridotta (quota di sfruttamento delle Vulnerabilità Note Sfruttate (KEV) a 30 giorni: 8% nel 2021 al 65% entro il 2023). Il Gruppo Venditori 2 si trova all'avanguardia di questa curva.

Mosse ortodosse:

• Pagamenti per bug bounty abbastanza alti da superare il mercato grigio, in modo che i ricercatori vengano da te invece di vendere al di fuori.
• Meccanismi di distribuzione delle patch che mascherano quale/i file sono cambiati: solo pacchetti patch crittografati e diff binari firmati, nessun diff di sorgente non elaborato.
• Strumenti di aggiornamento automatico che distribuiscono patch in poche ore, non giorni.

Opzioni non ortodosse:

• Rivendica il merito per ogni CVE, che l'abbia trovato il tuo team o meno.
• Attribuire eccessivo merito agli LLM come scopritori quando si segnalano i CVE.
• Preferisci correzioni silenziose: distribuisci la correzione senza pubblicare un CVE.
• Rilascia CVE esca come honeypot per gli aggressori.

Consulta il catalogo qui sotto per sapere come funziona ciascuno, i suoi rischi e quando utilizzarlo.

Gruppo Fornitori 3 — Rumore di fondo (prodotto a bassa attrattiva, lenta adozione dell'IA)

• Profilo di attacco: Non attivamente preso di mira da attaccanti esperti, ma coinvolto da scansioni automatizzate e campagne di ransomware di massa.
• Vincolo chiave: I budget di sicurezza più piccoli, spesso nelle categorie di prodotto con i margini più bassi.
• Perché questo è il manuale operativo: Le tattiche economiche vincono qui. Il manuale operativo standard consiste principalmente nel sottrarre e semplificare.

Mosse ortodosse:

• Sottoscrivi i servizi gestiti del pipeline di sviluppo invece di creare il tuo.
• Spedisci avvisi minimi — “esiste una vulnerabilità, aggiorna alla versione X.Y.Z” senza descrizione CVE, senza dettagli su quale funzione è interessata, senza proof-of-concept — che costringono gli aggressori a fare il proprio lavoro di scoperta.
• Disciplina di fine vita: ritirare i prodotti secondo un programma annunciato pubblicamente e non permettere che un prodotto diventi una fonte permanente di CVE non corretti per gli aggressori.

Opzioni non ortodosse:

• Ignora silenziosamente i rapporti di ricercatori esterni.
• Riscrivere la politica di divulgazione delle vulnerabilità per accettare meno tipi di segnalazioni.
• Strategia del prodotto sacrificabile: lasciare che un prodotto attraente assorba l'attenzione dell'attaccante affinché il resto della gamma rimanga più tranquillo.

Consulta il catalogo qui sotto per sapere come funziona ciascuno, i suoi rischi e quando utilizzarlo.

Gruppo Fornitori 4 — Silenzioso ed efficiente (bassa attrattiva, rapida adozione dell'IA)

• Profilo di attacco: Priorità più bassa per le campagne di attacco attive; gli aggressori prestano meno attenzione.
• Vincolo chiave: L'investimento in AI ripaga proprio perché nessuno sta guardando.
• Perché questo è il playbook: Il vero rischio è salire per sbaglio la scala dell'attrattiva — un'acquisizione può trasformare un fornitore di nicchia nel Gruppo di Fornitori 1 da un giorno all'altro, e un'infrastruttura di sicurezza più leggera viene brutalmente esposta durante la transizione.

Mosse ortodosse:

• Continua a fare ciò che funziona.
• Non divulgare il tuo investimento in IA.
• Metti in atto l'infrastruttura di rimedio e una pipeline di patch matura prima che tu ne abbia bisogno. Preparati ai livelli del Gruppo Fornitori 1, anche se la minaccia attuale non lo giustifica.

Opzioni non ortodosse:

• Rimani strategicamente in silenzio riguardo alla tua pipeline di sviluppo assistita da LLM.
• Lanciare prodotti attraenti esca per distogliere l'attenzione degli aggressori.

Consulta il catalogo qui sotto per sapere come funziona ciascuno, i suoi rischi e quando utilizzarlo.

Il catalogo non convenzionale

Queste non sono approvazioni. Sono mosse che il modello attaccante-risposta dell'articolo precedente dice siano available, ciascuna con i propri compromessi. La tabella sottostante elenca tutte le tredici: come funziona ognuna, l'effetto che ha sull'attaccante e il rischio principale che comporta.

L'imperativo di rimedio

Nessuna delle tattiche sopra menzionate sostituisce la chiusura del gap di rimedio. La conclusione dell'articolo precedente che la rimedio è il vincolo vincolante deve venire prima; ogni altra mossa su questa pagina si basa su di essa: se i clienti rimangono vulnerabili per 252 giorni dopo che una patch è stata rilasciata, le tattiche degli aggressori si adattano a quella finestra, non importa quanto sia ingegnoso il vostro lavoro di scoperta. Mosse concrete con la leva massima tra i gruppi:

1.      Ripristino automatico quando viene distribuita una patch. Il vero motivo per cui i clienti ritardano l'applicazione delle patch di sicurezza non è l'ignoranza, ma la paura di compromettere il sistema in produzione. Una patch che blocca un sistema attivo può causare danni tanto quanto l'attacco che previene, quindi i team testano per settimane mentre il rischio rimane aperto. Il ripristino automatico elimina quella paura: ogni aggiornamento viene distribuito con un modo sicuro e immediato per annullarlo e tornare allo stato funzionante precedente, senza perdita di dati. Quando una patch può essere invertita in pochi secondi, i clienti smettono di esitare e la applicano immediatamente. La difficoltà è che alcune modifiche — come le migrazioni di database — sono difficili da annullare, quindi i fornitori devono progettare per la reversibilità fin dall'inizio.

2.      Distribuzione migliore delle patch — piccoli aggiornamenti firmati. Il modo in cui una patch raggiunge i clienti è importante quanto la velocità con cui viene scritta. Molti fornitori continuano a distribuire patch come grandi installer o modifiche di sorgente grezze — lente da implementare e facili da studiare o manomettere per un attaccante. La soluzione è fornire piccoli aggiornamenti firmati che contengono solo ciò che è cambiato, attraverso i gestori di pacchetti che i clienti già utilizzano. La firma prova che la patch proviene effettivamente dal fornitore e non è stata alterata lungo il percorso; la dimensione ridotta significa che si installa in pochi secondi, quindi più clienti applicano le patch prima. Un beneficio collaterale: distribuire un aggiornamento binario anziché il codice sorgente leggibile offre agli attaccanti meno materiale da analizzare tramite reverse-engineering.

3.      Canali beta per clienti per patch di sicurezza. I fornitori possono scoprire se una patch di sicurezza causa problemi prima che raggiunga tutti. Un canale beta consente a un piccolo gruppo di clienti volontari di eseguire gli aggiornamenti per primi, in ambienti reali, in modo che i problemi emergano nel giro di poche ore anziché dopo un rilascio aziendale completo. Quel segnale precoce indica al fornitore se distribuire ampiamente ora o attendere e correggere. Dà anche agli altri clienti la fiducia di applicare la patch rapidamente, perché l'aggiornamento è già stato provato su sistemi simili ai loro. Il compromesso: i clienti beta si assumono un po' più di rischio per l'accesso anticipato, quindi il programma necessita di un chiaro consenso e di un buon monitoraggio.

4.      “Patch Tuesday è morto” — patching continuo. Il "Patch Tuesday" mensile è stato creato per mantenere prevedibile l'IT aziendale. Ma la prevedibilità ora aiuta gli aggressori: conoscono il programma e una correzione pronta in anticipo può rimanere non rilasciata per settimane mentre viene divulgata o riscoperta. Un modello di patch continuo spedisce ogni correzione di sicurezza non appena viene testata — entro un termine fermo come 48 ore — attraverso un canale solo di sicurezza, separato dagli aggiornamenti delle funzionalità. Questo elimina l'unico ritardo completamente sotto il controllo del fornitore: il divario tra "correzione pronta" e "correzione spedita". Funziona meglio insieme al rollback (#1) e ai canali beta (#3), e richiede ai clienti di accettare frequenti piccoli aggiornamenti invece di un grande lotto mensile.

5.      Pubblicare una cronologia di distribuzione delle patch per coorte di clienti. Questo può sembrare controintuitivo — perché annunciare il proprio programma agli attaccanti? Ma gli attaccanti già stimano quanto velocemente i clienti applicano le patch, e cronometrano i loro attacchi per la parte lenta di quella curva. La raccomandazione trasforma quel ritardo nascosto in una scadenza pubblica e impegnata per ciascun tipo di cliente (ad esempio, infrastrutture critiche 72 ore, standard 7 giorni, lungo termine 30 giorni). Rendere pubblico l'impegno mette pressione sulle squadre interne del fornitore affinché lo rispettino davvero, aiuta i clienti a pianificare e riduce la finestra su cui gli attaccanti fanno affidamento. Il punto non è la segretezza — è responsabilità. Rispettare una scadenza pubblicata è ciò che rimuove il vantaggio di tempo degli attaccanti.

Questi cinque sono la base conservativa; il catalogo scomodo sopra è lo strato speculativo aggiunto.

Chiusura

La corsa LLM a due lati cambia la domanda principale per ogni fornitore. Non è più solo "come troviamo più bug più velocemente?" È "ora che gli attaccanti hanno gli stessi strumenti, come cambiamo ciò che possono vedere, apprendere e costruire?" Il manuale ortodosso — scansione più veloce, audit più ampi, un pipeline interno più pesante — è necessario ma non sufficiente da solo, perché accelera entrambe le parti in modo uguale. Il catalogo scomodo sopra è un tentativo di rompere quel pareggio. La maggior parte delle sue mosse comporta costi che i fornitori mainstream non accetteranno oggi, e alcune stanno già avvenendo silenziosamente, in luoghi che non lo ammetteranno.

Quella parola "oggi" conta. Secondo le norme attuali, ogni tattica nel catalogo va dal sgradevole all'indifendibile, e nulla di ciò è un avallo. Ma le norme seguono le condizioni. Se la tendenza descritta nell'analisi attacker-side continua — gli attaccanti trovano la maggior parte dei CVE, un arretrato di patch che non si riduce mai, e regole di divulgazione che sempre più favoriscono l'offesa — è giusto chiedersi se alcune di queste mosse passino dall'impensabile al dibattito riluttante. Le norme di divulgazione che sembrano permanenti oggi furono esse stesse una reazione a un'era di minacce precedente, e possono cambiare di nuovo. La vera domanda non è se i regolatori e i fornitori dovrebbero optare per queste opzioni. È se ci stiamo silenziosamente avviando verso un futuro abbastanza brutto da metterle sul tavolo — e se è meglio valutare i compromessi ora, con calma, piuttosto che improvvisarli più tardi sotto pressione.

Nei post successivi approfondiremo le singole tattiche: quanto rapidamente aumentano i costi del patch-diffing, cosa consente la legge in ciascun paese e come i quattro gruppi di fornitori si stabiliscono in una strategia stabile.

Punti chiave

• Risolvere conta più che trovare. Il tempo medio per risolvere è di 252 giorni e in aumento; ogni raccomandazione in questo saggio assume che come vincolo vincolante.
• Gruppi di fornitori diversi hanno bisogno di manuali diversi. I soft prime (Gruppo 1) hanno bisogno prima di tutto dell'automazione dal lato della correzione; i Treadmiller (Gruppo 2) necessitano di offuscamento delle patch e aggiornamenti automatici più rapidi; i gruppi di minore attrattiva hanno bisogno di sottrazione economica.
• Le mosse ortodosse sono necessarie ma potrebbero non essere sufficienti. Una scoperta più rapida, un audit più ampio e pipeline interne più pesanti accelerano entrambe le parti simmetricamente.
• Il catalogo non ortodosso rompe la simmetria, con costi. La maggior parte delle voci scambia esposizione legale o danni all'ecosistema per attrito degli attaccanti. Alcuni stanno già accadendo silenziosamente.
• Cinque mosse concrete forniscono leva. Rollback automatico, distribuzione delle patch firmate, canali beta per i clienti, rilasci continui di patch e tempistiche pubblicate per il deployment delle patch.

Analisi CVE giornaliera · Dati: National Vulnerability Database (NVD), Exploit Prediction Scoring System (EPSS), Cybersecurity and Infrastructure Security Agency (CISA) KEV, MITRE ATLAS, OWASP LLM Top 10 per LLM