Edition 13

Due cose sono vere contemporaneamente, ed è necessario tenerle presenti entrambe. La prima: l'avvertimento è reale e fondato. Gli attacchi basati sull'IA stanno arrivando, colpiranno le infrastrutture critiche, e una risposta coordinata pubblico-privata è genuinamente la risposta giusta. Dopo l'estate che abbiamo vissuto, che un settore che per due anni ha minimizzato il problema lo dica finalmente ad alta voce è un progresso. La seconda: leggete la lista dei firmatari con occhio critico. Le aziende che costruiscono i modelli più capaci sul versante offensivo sono le stesse che vi vendono la difesa, e questa lettera vale anche come annuncio coordinato di lancio per Daybreak, Mythos e Perception.

Raccogliete il segnale, ma tenete il portafoglio chiuso per un momento. L'avvertimento sistemico non vi obbliga ad acquistare la nuova piattaforma di difesa AI di qualcuno, e non sostituisce certamente i fondamentali su cui continuo a insistere. La risposta giusta a "gli attacchi AI stanno arrivando" non è un nuovo prodotto AI luccicante agganciato a fondamenta instabili: è completare il lavoro di base sottostante, lo stesso lavoro che avrebbe fermato la maggior parte degli incidenti dell'estate. Acquistate gli strumenti difensivi se guadagnano il loro posto. Non lasciate che una lettera aperta ben orchestrata faccia quella scelta al posto vostro.

Questo è l'intero argomento sulla sicurezza dell'IA condensato in un progetto del weekend, e vale più della lettera della coalizione di cui sopra. Non perché sia sofisticato, ma perché è banale. Un tizio, leggermente infastidito dal suo monitor, ha puntato un'IA commerciale sul firmware chiuso di gadget ordinari e li ha compromessi tutti. La barriera che un tempo proteggeva l'hardware oscuro, ovvero il fatto che eseguirne il reverse engineering era un lavoro lento, specializzato e costoso, è esattamente la barriera che l'IA ha appena abbattuto. Questa è la vera storia di quest'epoca: non una nuova magia, ma il crollo del costo della competenza.

Per il vostro threat model, due considerazioni. Prima: ogni periferica è un piccolo computer connesso e quasi privo di protezioni, e il vostro inventario degli asset quasi certamente non include la webcam, il monitor o i dispositivi delle sale riunioni che possono essere riprogrammati per persistere al di sotto del sistema operativo. Seconda: è per questo che i prompt di autorizzazione del browser contano. WebUSB, WebHID e WebBluetooth fanno sì che un sito malevolo possa raggiungere quell'hardware se un utente clicca su "consenti". Se i vostri programmi di supply-chain e endpoint si fermano a laptop e server, si fermano troppo presto.

Soffermatevi sull'86%, perché è il numero che dovrebbe riorganizzare le vostre priorità. La maggior parte delle organizzazioni non riesce a vedere cosa i propri dipendenti stiano inviando all'IA, il che significa che la maggior parte delle policy di AI governance sono documenti che descrivono una realtà che nessuno sta effettivamente misurando. Questo è il problema dello shadow AI e dello shady AI di qualche settimana fa, ora supportato da telemetria: vietare gli strumenti non funziona, sposta semplicemente l'utilizzo su account personali dove la visibilità è zero. L'unica cosa che funziona è un percorso autorizzato e monitorato, più comodo da usare di quello non ufficiale.

Non perdete però di vista l'elemento genuinamente nuovo, perché è lì che vivono gli incidenti del prossimo anno. Il centro di gravità si è spostato dai dipendenti che incollano testo in un chatbot agli agenti collegati direttamente ai vostri sistemi tramite MCP, e Netskope sta osservando quel traffico quadruplicare. Si tratta di un rischio diverso: non ciò che un essere umano digita, ma ciò che un agente autonomo è autorizzato a raggiungere. Un aumento di quattro volte nel tessuto connettivo tra i vostri dati e i modelli esterni equivale a un aumento di quattro volte nel raggio d'azione di un'eventuale compromissione. Se la vostra AI governance presuppone ancora che il rischio sia un copia-incolla in ChatGPT, state governando il problema dell'anno scorso.

Ho avuto interlocutori che hanno sollevato questo tema nell'ultima settimana, quindi voglio essere diretto sul perché l'inquadratura consueta sia sbagliata. Il quantum non è correttamente catalogato come problema futuro, e la ragione non è la tempistica dell'hardware, che nessuno riesce a stabilire con precisione. È il paradigma "harvest now, decrypt later". Nel momento in cui i vostri dati cifrati vengono catturati, il conto alla rovescia inizia, e la decifratura avviene semplicemente in un secondo momento. Quindi la domanda onesta non è "quando arriverà il quantum", ma "per quanto tempo i miei dati devono restare segreti, ed è più a lungo di quanto ci vorrà perché qualcuno possa violare la crittografia che li protegge". Per la maggior parte dei dati regolamentati, contratti, cartelle cliniche, segreti commerciali, la risposta è già sì. Il che significa che sono già esposti.

E questo si somma a tutto il resto in questa newsletter. Ogni violazione che ho esaminato in cui "solo dati cifrati" sono stati sottratti rappresenta un deposito nel caveau di qualcuno, in attesa. Una crittografia già debole, TLS mal configurato, dimensioni di chiave obsolete, schemi sviluppati in casa, non ha bisogno di un computer quantistico per essere preoccupante: ne ha bisogno uno ora e un computer quantistico in seguito. La prima mossa non è il panico né una sostituzione totale: è un inventario crittografico. Sapere dove usate la crittografia, quali algoritmi, quali dimensioni di chiave, in quali sistemi, inclusi quelli gestiti dai vostri fornitori. Non si può migrare ciò che non si vede, e l'UE vuole quell'inventario completato entro la fine di quest'anno. Questo è un progetto del 2026 che indossa un costume del 2032.

Questo è l'equilibrio su cui voglio che riflettiate concretamente, perché entrambi gli estremi vengono venduti come best practice e sono entrambi trappole. La frammentazione è reale: cinquanta strumenti disconnessi, cinque dashboard e tre team che lavorano su tre tempistiche diverse è il modo in cui un incidente contenuto diventa una violazione da 276 giorni. Quindi il consolidamento è davvero una buona pratica igienica. Ma spingetelo troppo oltre e arriverete esattamente dove DORA e NIS2 vi dicono di non essere: il rischio di concentrazione, con l'intera postura di sicurezza che poggia su un unico fornitore che diventa così un single point of failure e un bersaglio appetibile. DORA lo nomina esplicitamente: la dipendenza eccessiva da un terzo ICT critico è un rischio che siete tenuti a gestire, non un'efficienza da massimizzare.

Quindi la risposta non è uno slogan: è un giudizio, ed è vostro da difendere. Consolidate per integrazione e visibilità, le cose che la frammentazione distrugge, ma mantenete un'indipendenza deliberata nei punti in cui una brutta giornata di un singolo fornitore vi trascinerebbe giù con lui. Mappate le vostre dipendenze critiche, chiedetevi quali fornitori non potreste davvero permettervi di perdere, e assicuratevi che la risposta non sia «tutti» né «uno solo». Questo è il vero lavoro dietro la strategia dei vendor, ed è esattamente il muscolo che NIS2 e DORA cercano di sviluppare. Né "un'unica gola da stringere" né "best-of-breed per tutto" è una strategia. L'equilibrio lo è.