Edition 09

Rileggete il verdetto, perché è il punto centrale: le vulnerabilità erano banali. Gestione non sicura dei dataset, metadati esposti, accessi eccessivamente ampi, credenziali longeve. Nemmeno uno zero-day esotico nei fondamentali, solo i risultati che compaiono nell'ultimo report del vostro pentest e che il vostro piano di risk treatment ha probabilmente rimandato. L'AI non aveva bisogno di essere brillante. Aveva bisogno che voi aveste lasciato il refrigeratore socchiuso; dopodiché ha controllato ogni chiusura 17.600 volte senza annoiarsi, stancarsi o tirarsi indietro.

È questa la discontinuità che dovrebbe cambiare il vostro approccio ai test. Il vostro pentest annuale simula un essere umano: qualche giorno, una persona che dorme, uno scope che finisce. Questo simula qualcosa che non si ferma mai, non dimentica il proprio obiettivo e si ricostruisce ogni volta che lo abbattete. Se il vostro threat model presuppone un attaccante con la pazienza umana e gli orari d'ufficio, state testando un mondo che non esiste più.

La conclusione pratica ricade sempre nello stesso posto, solo più forte: nell'era dell'AI, l'igiene di base è fondamentale. Ruotate le credenziali. Eliminate i token longevi. Applicate il least privilege per davvero, non solo sulla carta. E se conducete offensive testing, iniziate a chiedervi come appare un agentic red-teaming contro il vostro ambiente, perché la controparte lo sta già eseguendo. È la conversazione di governance che ISO 42001 continua a indicare, e questo incidente l'ha appena resa concreta.

Questa è la notizia più vicina alla mia scrivania, quindi sarò diretto su cosa cambia. Se avete un dataset che avete trattato come anonimo perché avete rimosso i nomi o sottoposto gli identificatori ad hashing, l'EDPB, seguendo la Corte, vi ha appena comunicato che questa non è una proprietà del dato, bensì un giudizio contestuale. Anonimo nelle vostre mani può essere dato personale in quelle di qualcun altro. Questo ridefinisce ogni argomento del tipo «è anonimizzato, il GDPR non si applica» in una pipeline di addestramento AI o in una condivisione di dati di ricerca.

Ho scritto uno studio completo sulla definizione di dato personale attraverso i casi Breyer e SRB, che è l'origine di questo approccio relativo; verrà pubblicato su Cyberacademy questa settimana, quindi restate connessi. Se gestite dati che avete etichettato come anonimi, leggetelo prima della vostra prossima decisione di data sharing. La versione breve: l'etichetta non è la protezione. Lo è la valutazione documentata del rischio di re-identificazione che la sorregge.

Lo dico in ogni corso che tengo, e ora lo standard lo dice in undici pagine: l'Annex A non è un catalogo da cui fare shopping. Si parte dai propri rischi, si decidono i controlli che quei rischi richiedono e solo allora si consulta l'Annex A per assicurarsi di non aver dimenticato nulla. Le organizzazioni che sbagliano 27001 lo fanno al contrario: aprono prima l'Annex A e lo trattano come una lista della spesa, finendo con una pila di controlli che non rispondono ad alcun rischio reale. La versione più snella di 27000 esiste in parte per eliminare questa abitudine.

Nota operativa: se i vostri materiali di formazione, i template o il wiki interno citano definizioni di ISO 27000, puntano ora a un'edizione ritirata, e il vocabolario risiede sulla piattaforma online di ISO. E se gestite qualcosa nel cloud, 27017 è finalmente allineata ai controlli del 2022, quindi sia la vostra mappatura dei controlli cloud sia il prossimo cloud audit necessitano della nuova versione.

Notate lo schema comune con i due elementi precedenti. L'EDPB dice che un'etichetta di anonimato non è una protezione. ISO dice che una spunta sull'Annex A non è un controllo. Ora CISA dice che un SBOM generato non è sicurezza della supply chain. Stessa lezione, tre regolatori, una settimana: l'artefatto non è l'outcome. Un SBOM prodotto una volta e archiviato non prova nulla il giorno in cui un nuovo CVE viene segnalato contro un componente sepolto al suo interno.

Anche se siete fuori dallo scope statunitense, questa è la direzione, e NIS2, DORA e il Cyber Resilience Act si basano esattamente su questo tipo di trasparenza della supply chain. Trattate l'SBOM come un inventario vivo da confrontare con i feed di vulnerabilità, non come un PDF per il raccoglitore dell'audit.

Ed ecco la parte su cui anticiparsi: l'SBOM è solo il primo inventario. L'AI Bill of Materials sta arrivando, la stessa rendicontazione applicata a modelli, dataset, pesi e provenienza dell'addestramento, e CISA ha già pubblicato un set complementare di AI minimum elements. È più complesso, perché un modello o un dataset possono cambiare senza che venga mai eseguita una build, quindi uno snapshot annuale è inutile. Guardate l'inizio di questa edizione: un componente AI non censito, sfruttato su scala, è esattamente il rischio che un AI-BoM esiste per rendere visibile. Iniziate a chiederlo ai vostri vendor prima che lo faccia il vostro regolatore.

L'ho costruita perché gli strumenti che continuavo a raccomandare erano o pesanti, o costosi, o trattavano il GRC come un esercizio di compilazione di moduli, che è l'opposto di tutto ciò che insegno in questa newsletter. Esiste un piano gratuito per iniziare. E se volete testarlo seriamente, rispondete a questa email e vi darò un anno completo del piano premium, gratuito, per metterlo alla prova. Se non fa per voi, nessuna pressione: la newsletter rimane esattamente com'è.