La notifica ricevuta dall’Agencia Española de Protección de Datos (AEPD) su una violazione di dati personali apparentemente eseguita mediante un agente di IA pone una domanda a sicurezza IT, DPO e direzione.
Occorre, infatti, chiedersi se le misure adottate riescono a produrre un effetto prima che l’attacco raggiunga o alteri i dati.
Indice degli argomenti
Data breach ai tempi dell’IA: una riflessione su GDPR e cyber difesa
La nota pubblicata il 14 settembre dall’Autorità Garante spagnola non è una ricostruzione definitiva dell’incidente. Inoltre, una sola notifica non consente di misurare la diffusione degli attacchi condotti mediante agenti di intelligenza artificiale.
Offre però l’occasione di verificare un presupposto spesso implicito nei piani di sicurezza: fra l’accesso a un sistema e l’intervento della difesa c’è abbastanza tempo per accorgersi di ciò che sta accadendo.
L’AEPD riferisce di aver ricevuto la prima notifica in questi termini: una violazione di dati personali che sarebbe stata eseguita mediante un agente di IA basato su un noto modello linguistico.
Secondo quanto comunicato dall’organizzazione colpita, l’agente avrebbe cercato vulnerabilità, effettuato un accesso al sistema, proseguito le verifiche, modificato dati personali e avuto accesso a fatture.
Il condizionale è parte della notizia. Le informazioni contenute nella notifica devono essere verificate.
Non conosciamo le istruzioni ricevute dall’agente, gli strumenti e i permessi di cui disponeva o il grado di intervento umano nelle diverse fasi.
Nessuna esfiltrazione di dati accertata
Non risulta accertata un’esfiltrazione di dati. Non sappiamo neppure quale vulnerabilità, credenziale o configurazione abbia consentito l’accesso: la partecipazione di un agente alla sequenza non identifica, da sola, la causa della violazione.
L’impiego di un modello linguistico, inoltre, non indica che il modello o l’infrastruttura del suo produttore siano stati compromessi.
Il caso merita attenzione senza trasformarlo nella storia di un «hacker artificiale». La questione riguarda il tempo che può separare una mossa dell’attacco dalla successiva.
Quando l’attacco riduce le pause
Un aggressore può chiedere a un chatbot suggerimenti e decidere personalmente che cosa tentare.
Un agente, se configurato con gli strumenti necessari, può invece eseguire un’operazione, osservarne il risultato e adattare il passaggio seguente entro i limiti delle istruzioni ricevute.
È questo il significato tecnico di «autonomia»: una modalità operativa, non un’intenzione della macchina né la scomparsa del ruolo di chi la impiega.
Ricognizione, uso di credenziali, verifica dei privilegi e accesso ai dati sono passaggi conosciuti. La possibilità di concatenarli rapidamente può ridurre il tempo disponibile per rilevare e contenere l’intrusione.
Alcune operazioni potrebbero inoltre richiedere meno competenze a chi tenta l’attacco.
Da qui non segue che chiunque possa compromettere qualunque sistema: contano le vulnerabilità effettivamente presenti, le credenziali utilizzabili, la configurazione dello strumento e le difese incontrate.
La guida iberica
La guida spagnola BP/36 del CCN-CERT nella sezione 3.4 esprime il problema con una formula che vale la pena riportare: «Lo que ya sabíamos hacer, ahora hay que hacerlo a velocidad de máquina» (letteralmente: “Quello che sapevamo già fare, ora dobbiamo farlo alla velocità di una macchina“).
La guida richiama anche la necessità di adattare i processi difensivi al ritmo
dell’automazione offensiva.
È un’analisi dello scenario tecnico, non una misura già accertata della durata dell’incidente notificato all’AEPD.
Un alert può essere corretto e arrivare dopo che i dati sono stati consultati. Una procedura per revocare credenziali può essere completa e richiedere più tempo della sessione sospetta. Un account può essere protetto da autenticazione forte e conservare, una volta compromesso, privilegi eccessivi.
Ogni controllo esiste; la domanda è quando riesce a fermare qualcosa.
La prova per il GDPR
Il GDPR non ha bisogno di una nuova categoria denominata «attacco mediante IA».
Gli articoli 24 e 32 chiedono già al titolare misure tecniche e organizzative adeguate al rischio, tenendo conto, fra l’altro, dello stato dell’arte.
L’articolo 32 riguarda riservatezza, integrità, disponibilità e resilienza dei sistemi, insieme alla verifica regolare dell’efficacia delle misure. Gli articoli 5, paragrafo 2, e 25 completano il quadro della responsabilizzazione e della protezione dei dati fin dalla progettazione e per impostazione predefinita.
Il GDPR non prescrive un prodotto specifico né fissa un numero di minuti valido per tutti entro cui bloccare un’intrusione.
Chiede una valutazione aderente ai trattamenti e ai rischi concreti. Se, per un determinato trattamento, i dati possono essere raggiunti o modificati prima che l’organizzazione riconosca un accesso anomalo, i tempi effettivi della difesa diventano un elemento dell’adeguatezza da verificare.
La valutazione d’impatto sulla protezione dei dati quando necessario
L’articolo 35, paragrafo 11, prevede inoltre il riesame di una valutazione d’impatto sulla protezione dei dati quando necessario, almeno se cambia il rischio rappresentato dalle operazioni di trattamento.
La segnalazione spagnola non obbliga a riaprire indistintamente tutte le DPIA. Offre però una ragione per controllare quelle relative ai trattamenti più esposti: descrivono ancora realisticamente i privilegi disponibili, i percorsi verso i dati e la possibilità di scoprire in tempo un accesso improprio?
La modifica di dati personali indicata nella notifica aggiunge una dimensione precisa.
Non c’è soltanto il rischio che qualcuno legga informazioni riservate: dati alterati potrebbero essere usati in processi successivi prima che l’organizzazione se ne accorga.
Se ciò sia avvenuto nel caso spagnolo, e con quali conseguenze, resta da accertare. È però una domanda che il titolare può già porre nella propria analisi del rischio.
Dall’alert alla decisione sulla violazione
Quando emerge una violazione di dati personali, la risposta tecnica deve consentire al titolare di ricostruire i fatti e decidere se notificare l’autorità e se comunicare l’accaduto agli interessati.
Gli articoli 33 e 34 del GDPR prevedono presupposti distinti. La notifica all’autorità, salvo che sia improbabile un rischio per i diritti e le libertà delle persone fisiche, va effettuata, ove possibile, entro 72 ore da quando il titolare viene a conoscenza della violazione.
La comunicazione agli interessati riguarda i casi di rischio elevato. Le informazioni ancora incomplete possono essere fornite per fasi.
Se la violazione viene rilevata da un responsabile del trattamento, questi deve informare il titolare senza ingiustificato ritardo, ai sensi dell’articolo 33, paragrafo 2.
La rapidità della difesa tecnica serve meno se le informazioni necessarie alla valutazione restano ferme fra fornitore, sicurezza IT e uffici che devono decidere.
Per i soggetti cui si applica la NIS2, recepita in Italia dal decreto legislativo n. 138/2024, lo stesso evento può richiedere anche la valutazione degli obblighi di gestione e notifica degli incidenti di cyber sicurezza.
I presupposti NIS e GDPR non sono coincidenti: occorre una ricostruzione tecnica condivisa da cui trarre, secondo ciascuna disciplina, le decisioni pertinenti.
Che fare e cosa dice l’AEPD: i 4 aspetti della gestione del rischio
Secondo l’Autorità Garante iberica la notifica cambia lo scenario della gestione del rischio sotto quattro aspetti:
- Analisi del rischio: gli attacchi assistiti o eseguiti mediante IA vanno considerati espressamente. Una voce generica come «accesso non autorizzato» può non descriverne adeguatamente probabilità, velocità e portata.
- Tempi di risposta: le procedure pensate per attacchi condotti manualmente possono essere troppo lente quando un agente esplora più risorse, prova diverse vie d’accesso e adatta rapidamente le proprie azioni.
- Credenziali e permessi: un account, una chiave API o un token con privilegi eccessivi possono consentire all’agente di raggiungere più servizi prima che l’anomalia venga rilevata.
- Contenimento: la supervisione umana resta necessaria, ma deve essere affiancata da meccanismi capaci di rilevare e contenere tempestivamente l’attacco.
L’AEPD prosegue invitando titolari, responsabili del trattamento e DPO a rivedere senza indugio i propri modelli di sicurezza e protezione dei dati alla luce dell’uso offensivo degli agenti di IA.
I fondamenti, osserva, restano gli stessi: conoscere i trattamenti, minimizzare i dati, limitare gli accessi, correggere le vulnerabilità, controllare i fornitori ed essere pronti a rispondere agli incidenti.
Dall’avvertimento alla prova concreta
A partire dalle indicazioni dell’AEPD, una verifica utile può essere questa: scegliere un sistema in cui gli operatori consultano e aggiornano i dati dei clienti e simulare l’uso non autorizzato di un account.
Quanto tempo passerebbe prima del primo avviso? Quanto prima che l’accesso sia bloccato? Nell’intervallo, quali dati potrebbero essere letti o modificati? La funzione di sicurezza IT può misurare questi tempi e controllare se l’account abbia più permessi del necessario.
Il DPO può valutare le possibili conseguenze per i clienti e verificare se l’analisi del rischio, o quando necessario la DPIA (Data Protection Impact Assessment), descriva ancora correttamente quella possibilità.
Il titolare deve sapere chi può disporre rapidamente il blocco e quali informazioni gli serviranno per decidere come gestire un’eventuale violazione di dati personali.
La prova dovrebbe lasciare quattro risultati: quando è arrivato il primo avviso, quando l’accesso è stato bloccato, quali dati erano raggiungibili nel frattempo e che cosa ha causato eventuali ritardi.
Su questa base si può correggere una misura o una procedura e ripetere la prova per vedere se la correzione ha funzionato.
La notifica spagnola non permette ancora di stabilire come sia avvenuto l’accesso, quanto abbia fatto autonomamente l’agente o se casi simili diventeranno frequenti.
Nei propri sistemi, invece, ogni organizzazione può già cercare una risposta verificabile alla domanda su cosa potrebbe accadere ai dati nel tempo che passa fra il primo avviso e il blocco dell’accesso.
Partecipa alla community