Blog 5 domande critiche su Mythos a cui ogni CISO deve saper rispondere | Insight

Mythos ha portato alla luce migliaia di nuove vulnerabilità critiche. Ecco le cinque domande che ogni CISO riceverà, e come rispondervi.

Se nelle ultime settimane ti sei svegliato alle 3 di notte a fare l'inventario mentale del tuo ambiente (i sistemi legacy, le dipendenze open source che nessuno tocca da anni, il software di terze parti ereditato tramite acquisizioni), non sei solo.

Ogni CISO con cui ho parlato da quando Anthropic ha reso pubblica la sua LLM Mythos sta facendo lo stesso inventario mentale.

Sfruttando Mythos, il Progetto Glasswing ha portato alla luce migliaia di vulnerabilità critiche precedentemente sconosciute in sistemi operativi, browser e livelli infrastrutturali. È questa la notizia che ha fatto i titoli.

La parte più difficile arriva alle 3 di notte. Anche se nel nostro ambiente non è cambiato nulla, il rischio a cui siamo esposti è aumentato in modo esponenziale. Vulnerabilità che prima non potevano essere sfruttate realisticamente possono ora essere concatenate da Mythos per compromettere qualsiasi ambiente in cui riesca a ottenere un primo accesso.

Questo non si risolverà semplicemente limitando l'accesso a Mythos. Ogni modello frontier d'ora in poi avrà queste capacità intrinseche. E ha reso una cosa inequivocabile: l'AI ha creato questa superficie di esposizione, e l'AI dovrà far parte di come la difendiamo.

Ecco quello che ho imparato gestendo le domande da aprile. La versione delle 3 di notte esaurisce il suo corso quando arrivano le patch. La versione diurna è quella che puoi plasmare adesso.

Sapere esattamente cosa ti chiederanno il consiglio di amministrazione, il team legale e i regolatori, e avere una risposta operativa e difendibile già pronta, è ciò che ti permette di guidare questa risposta invece di esserne guidato.

Queste sono le cinque domande che contano di più.

Prima: cosa ha fatto davvero Mythos

Il Progetto Glasswing è stata una coalizione a rilascio controllato. Anthropic ha messo a disposizione il suo modello di AI più avanzato, Mythos, a un gruppo selezionato di fornitori tecnologici per scansionare il proprio codice sorgente alla ricerca di vulnerabilità, prima di qualsiasi divulgazione pubblica.

Il risultato: migliaia di vulnerabilità critiche precedentemente sconosciute individuate nei principali sistemi operativi, browser, dispositivi edge e livelli infrastrutturali. Mythos ha analizzato il codice sorgente direttamente a livello di blueprint, portando alla luce difetti presenti in produzione da anni, alcuni da decenni.

Le patch stanno arrivando. La domanda è se la tua organizzazione sarà pronta a riceverle.

Domanda 1: "Qual è la nostra esposizione, e abbiamo davvero un inventario accurato degli asset?"

Di solito è la prima domanda, ed è spesso la più difficile a cui rispondere onestamente. Mythos ha cambiato il calcolo su quali vulnerabilità contano: può concatenare CVE di livello medio e basso per ottenere lo stesso accesso di un exploit critico, il che significa che il tuo backlog è diventato molto più rilevante.

Se non riesci a rispondere alla domanda sulla tua esposizione, di solito è perché la visibilità continua degli asset non è stata trattata come una capacità mission-critical. Nella maggior parte degli ambienti in cui ho lavorato, una piccola percentuale di vulnerabilità genera la stragrande maggioranza del rischio organizzativo reale. Devi sapere quali stai guardando oggi, non lo scorso trimestre.

E il calcolo si complica ulteriormente quando si considera il volume di patch in arrivo dai tuoi fornitori OEM e infrastrutturali. Ogni sistema operativo, browser e livello di piattaforma si trova di fronte alla stessa pipeline di divulgazione, e questo lavoro supererà i metodi di risk-scoring su cui la maggior parte di noi ha fatto affidamento nell'ultimo decennio.

La risposta che regge di fronte al consiglio è un numero di esposizione aggiornato con una data, un responsabile nominato per ciò che è ancora nel gap, e un approccio di scoring costruito per le vulnerabilità concatenate.

Domanda 2: "Siamo in grado di applicare le patch abbastanza velocemente, su larga scala, senza rompere la produzione?"

La risposta ideale è sì… ma forse non con i processi attuali. La maggior parte delle organizzazioni opera su cicli di patch mensili o trimestrali, una cadenza costruita per un'era in cui le minacce si muovevano lentamente. Quando una patch viene rilasciata, il conto alla rovescia inizia per tutti, compresi i threat actor che la fanno ingegneria inversa per trovare la vulnerabilità sottostante.

La velocità da sola rompe le cose. Nelle organizzazioni in cui una sola persona gestisce IT, sicurezza e molte altre funzioni, un deployment fallito nel momento sbagliato significa giorni di downtime. Ciò che funziona è costruire una capacità di risposta alle patch con prioritizzazione della criticità degli asset, change management coordinato e percorsi di escalation. È un nuovo modello operativo, costruito per la cadenza che la minaccia ora richiede.

Quello che riporti alla leadership è esattamente questo: un SLA di patch definito per i tuoi asset più critici, una prioritizzazione documentata per il resto, e un protocollo di change management che regge a un deployment reale.

Domanda 3: "Cosa si nasconde nel nostro software open source e di terze parti?"

Ogni CISO esperto conosce la risposta onesta: no, e dobbiamo prestare attenzione a questo. Pensa a Log4j. I malintenzionati avevano introdotto vulnerabilità in quella libreria anni prima che qualcuno se ne accorgesse; era utilizzata in migliaia di organizzazioni, molte delle quali l'avevano integrata in software consegnato ai clienti. L'esposizione non è stata scoperta. Era già ovunque.

Il Progetto Glasswing ha portato alla luce la stessa realtà su scala più ampia. Le vulnerabilità vivono nelle librerie open source che i tuoi sviluppatori hanno importato anni fa, nelle integrazioni di terze parti ereditate tramite acquisizioni e nei pacchetti che alimentano la tua infrastruttura web.

Se non hai un software bill of materials per il tuo ambiente, non sai cosa stai gestendo. Quello che riporti in quella stanza è un SBOM in corso, un elenco prioritizzato delle tue dipendenze ad alto rischio, e un albero di contatti con i fornitori pronto prima che arrivi la prossima divulgazione.

Domanda 4: "Abbiamo la capacità ingegneristica per rimediare il nostro backlog?"

È la domanda che nessuno vuole dire ad alta voce alla propria leadership, ma a cui tutti stanno pensando. La remediation richiede persone qualificate, e la carenza di talenti nella sicurezza non si è fermata per Glasswing. Per la maggior parte delle organizzazioni, le persone che farebbero il lavoro di remediation sono già completamente impegnate.

Se c'è un gap nella tua capacità ingegneristica, riconoscerlo chiaramente è la cosa più responsabile che puoi fare. Integra con risorse esterne, fai un triage rigoroso per concentrare i team interni sugli elementi ad alto rischio, e incorpora pratiche secure-by-default nello sviluppo futuro. Le organizzazioni che usciranno meglio da questa situazione saranno quelle che stanno prendendo decisioni realistiche sulla capacità adesso.

Ciò che funziona di fronte alla leadership è una matematica onesta: le ore necessarie, il gap tra queste e la capacità del tuo team, e il piano specifico che stai seguendo per colmarlo.

Domanda 5: "Se una patch è in ritardo, siamo in grado di rilevare e contenere l'exploit?"

Ecco la realtà onesta: non tutte le patch arriveranno in tempo. Il consiglio lo sa. Il team legale lo sa. La domanda che stanno davvero ponendo è: qual è il backstop?

Zero Trust ha sempre incluso un principio di "assume breach", e la maggior parte delle organizzazioni ha adottato altre sue componenti anni fa. Questo è il momento in cui assume breach smette di essere un concetto di pianificazione e diventa una postura operativa. Monitoraggio continuo, threat hunting proattivo e contenimento misurato in minuti, non in ore.

Se il tuo loop da rilevamento a isolamento si misura in ore, i threat actor si stanno già muovendo più velocemente di te. La risposta difendibile è il tuo mean-time-to-contain attuale, l'obiettivo verso cui lo stai portando, e un programma di threat hunting calibrato sulle superfici di esposizione di Mythos.

Le domande si moltiplicano. Come anche le risposte.

Nessuna di queste cinque domande vive in isolamento. Un gap nella visibilità degli asset alimenta il problema delle patch. Un ritardo nelle patch crea una finestra di rilevamento. Una supply chain non scansionata significa che potresti portare un'esposizione di cui non hai ancora chiesto conto. Questo effetto composto è il motivo per cui affrontare l'esposizione su questa scala richiede visibilità continua, patching coordinato, scansione della supply chain, capacità ingegneristica e rilevamento che operano in parallelo.

Questo significa operare alla velocità dell'AI. Mythos ha dimostrato cosa può fare l'AI sul lato offensivo. Il lato difensivo deve essere all'altezza, con tooling AI e automazione integrati in ogni fase dei nostri sforzi di remediation. È l'unico modo per restare avanti rispetto agli avversari invece di rincorrerli perennemente.

La finestra è reale, ed è limitata. Le domande stanno già arrivando. Assicurati di essere pronto con qualcosa di più di una semplice risposta.

Come abbiamo mappato queste domande internamente

Se ti stai chiedendo come operativizzare queste risposte, ecco come l'abbiamo fatto. Le cinque domande sopra corrispondono direttamente a cinque capacità funzionali, quelle che abbiamo implementato per noi stessi per primi, poi confezionato per i clienti sotto il nome Insight Managed Exposure Defense. Se stai valutando la tua postura o costruendo un caso internamente, ecco come si collegano:

"Qual è la nostra esposizione, e abbiamo un inventario accurato degli asset?"

• Continuous Threat Exposure Management: visibilità degli asset in tempo reale, prioritizzazione delle vulnerabilità basata sul rischio e scansione giornaliera, così lavori sempre da un quadro aggiornato del tuo ambiente.

"Siamo in grado di applicare le patch abbastanza velocemente, su larga scala, senza rompere la produzione?"

• Managed Patch: remediation guidata da SLO con scoring della criticità degli asset, change management coordinato e percorsi di escalation per i finding critici, senza che il tuo team debba scegliere tra velocità e stabilità.

"Cosa si nasconde nel nostro software open source e di terze parti?"

• Software Supply Chain & OSS Risk: scansione continua delle librerie open source, sviluppo del software bill of materials e monitoraggio del rischio delle dipendenze, così puoi rispondere alla domanda sulla supply chain con dati concreti.

"Abbiamo la capacità ingegneristica per rimediare il nostro backlog?"

• Software Developer Outsourcing: risorse ingegneristiche security-native che integrano la capacità del tuo team interno senza aggiungere personale, progettate appositamente per il tipo di backlog che Glasswing sta creando.

"Se una patch è in ritardo, siamo in grado di rilevare e contenere l'exploit?"

• Managed XDR: monitoraggio SOC 24/7, threat hunting proattivo e capacità di contenimento misurata in minuti, così la copertura di rilevamento colma il gap mentre la remediation recupera.

Il motivo per cui questi cinque servizi funzionano come offerta integrata, e il motivo per cui li stiamo eseguendo tutti noi stessi in questo momento, è che le domande si moltiplicano, e lo stesso vale per il rischio di affrontarle in modo frammentato.

Che tu costruisca queste capacità internamente, le acquisti, o ricorra a partner per colmare i gap, l'obiettivo è lo stesso: una risposta coerente su tutti e cinque i fronti. Il momento per costruirla è adesso.