Edition 12

Sto sostenendo una versione di questo argomento da mesi, ed è utile sentirlo da qualcuno esterno alla nostra bolla, in un linguaggio semplice, con il grafico allegato. Il punto non è che l'AI inventerà attacchi magici inarrestabili. È l'opposto. L'AI rende gli attacchi ordinari, la password mai ruotata, il sistema non patchato, l'accesso mal configurato, economici, veloci e instancabili, per poi eseguirli su una scala che nessun team umano potrebbe eguagliare. Esponenziale è la parola che dovrebbe tenervi svegli la notte. Una capacità che raddoppia ogni pochi mesi non vi lascia un margine confortevole per organizzarvi.

Prendete quindi i consigli concreti di Thompson, perché coincidono con quelli con cui chiudo metà di queste newsletter: i fondamentali sono l'intero gioco, adesso. Non perché siano affascinanti, ma perché sono esattamente ciò che la curva sta venendo a colpire. I tre elementi qui sotto sono i fondamentali, che mostrano le loro crepe in tempo reale. Sistemate i vostri prima che l'esponenziale lo faccia al posto vostro.

È il concetto "il certificato non è il controllo", raccontato attraverso l'MFA. Ognuna di queste aziende avrebbe potuto dire veridicamente "abbiamo l'autenticazione a più fattori". L'auditor ha spuntato la casella. E gli attaccanti sono entrati attraverso l'unico percorso di accesso non coperto dalla policy MFA, usando password che avrebbero dovuto essere ruotate anni fa. MFA abilitato non significa MFA applicato. Un controllo con una lacuna di copertura non è un controllo: è un buco a forma di controllo.

I compiti a casa sono specifici, non filosofici. Verificate che il vostro accesso condizionale si applichi effettivamente a ogni utente, ogni app e ogni tipo di client, senza eccezioni per protocolli legacy, posizioni attendibili o policy in modalità solo report che avete dimenticato di promuovere. Eliminate definitivamente i grant di autenticazione deprecati come ROPC. E date priorità alla risposta in base alle credenziali effettivamente valide, non in base al tenant maggiormente bersagliato, perché il target più rumoroso di solito non è quello compromesso. Si tratta di un audit di due ore che chiude una porta a cui hanno bussato 81 milioni di volte.

Qui ci sono due cose contemporaneamente, ed entrambe contano. In primo luogo, non lasciate che questo vi scoraggi dall'usare le passkey: rimangono la migliore opzione resistente al phishing disponibile, e questo attacco non rompe la passkey, ma abusa del recupero dell'account per aggiungerne una. Il problema è la registrazione, non la crittografia. In secondo luogo, e più importante, questo rompe un playbook. "Resettare la password e revocare le sessioni" è la memoria muscolare di ogni incident responder, e questo è un esempio concreto di quella memoria muscolare che lascia l'attaccante esattamente dove si trovava.

Aggiornate quindi il playbook adesso, prima di averne bisogno. Quando rispondete a una compromissione di account, il reset delle credenziali non è l'ultimo passaggio: è quello intermedio. Enumerate e rimuovete ogni autenticatore e passkey sull'account, verificate i metodi di recupero e le app connesse, e confermate che nessun dispositivo non riconosciuto sia ancora registrato. Se il vostro runbook di incident response non include attualmente la voce "verifica degli autenticatori registrati", contiene esattamente la lacuna che questo toolkit è stato costruito per sfruttare.

Questo caso mi piace perché abbatte una comoda convinzione che tutti condividono: scaduto significa morto. Non è così. Una data di scadenza non è mai stata un controllo di sicurezza: è una comodità logistica per la riemissione del supporto fisico, e in questo caso l'implementazione di Visa non vincolava nemmeno la data ai dati firmati della carta. Così milioni di persone gettano nel cestino carte "morte" che, per l'attaccante giusto, sono ancora vive.

Tirate il filo e la lezione è la stessa della casella di posta dell'ex dipendente di cui ho scritto tempo fa: la disattivazione non è la revoca. Una cosa è davvero morta solo quando il backend la termina effettivamente, e molto spesso la carta, l'account, il token, l'accesso continuano a funzionare molto dopo che tutti danno per scontato che non esistano più. Per la vostra organizzazione la domanda non riguarda le carte di credito. È: cosa avete "scaduto" che sta ancora silenziosamente accettando connessioni?

Prendete il vocabolario, ignorate il pitch commerciale. Shady AI nomina qualcosa di reale che la maggior parte delle policy AI manca completamente. Tutti sono impegnati a bloccare gli strumenti non autorizzati, la shadow AI, mentre l'assistente approvato acquisisce silenziosamente la capacità di leggere ogni documento, interrogare ogni sistema e agire per conto di qualcuno, e nessuno lo ri-governa quando le sue funzionalità si espandono. Approvare uno strumento una volta non significa approvare tutto ciò che sarà in grado di fare il trimestre successivo.

Questo è il cuore operativo della governance AI, ed è esattamente ciò attorno a cui ruota ISO 42001: non una policy di uso accettabile una tantum, ma una supervisione continua di ciò che la vostra AI può toccare e fare man mano che cambia. L'incidente Meta è la spia: un agente approvato che si comporta in un modo che nessuno aveva previsto, esponendo dati per due ore. Se la vostra governance AI è una policy firmata in un cassetto piuttosto che un controllo attivo sugli accessi ai dati e sui permessi degli agenti, avete shady AI, che la vediate o meno. Dopo tutto quanto sopra, questo è il fondamentale su cui anticipare il problema.