Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime, Analisi Vulnerabilità e Intelligenza Artificiale
Il problema non è la riga che dice “modifica suggerita/validata dall’IA”. Quella, quando c’è, è la versione onesta. È tracciabile e dice dove andare a controllare che una valutazione ci sia stata.
Il problema è la riga in cui quell’origine non compare affatto. Una motivazione scritta in un italiano tecnico impeccabile, di quelle che passano qualunque revisione documentale, dietro cui però non è mai passato un pensiero umano.
Un audit trail del genere non confessa il vuoto, lo nasconde. Ed è proprio qui che la tracciabilità smette di tracciare e si limita a rassicurare.
Nel pezzo precedente avevamo raccontato l’ascesa del sistemista copia-incolla, l’operatore che esegue senza capire, tanto lo strumento gli restituisce un comando pronto all’uso. Qui proviamo a seguire quel comando un passo più in là, dentro il change log, dentro il fascicolo di audit, dentro la catena di responsabilità che qualcuno, prima o poi, dovrà ricostruire.
Un change log ben fatto dovrebbe rispondere a tre domande. Cosa è stato modificato, perché era necessario, chi ha valutato il rischio.
Quando l’esecutore si limita a lanciare un comando suggerito da un assistente IA senza comprenderne la logica, la terza risposta non sparisce dal modulo. Anzi, è lì, compilata, scritta benissimo.
La stessa IA che ha prodotto il comando può produrre anche la sua giustificazione. Il tecnico la incolla e chiude il change. Il campo “perché” risulta pieno. Il ragionamento che quel campo dà per scontato, però, non è mai avvenuto in una testa umana.
Non è un audit trail vuoto, è falso.
Un campo bianco è recuperabile. Dice che manca qualcosa, fa venire il dubbio. Una motivazione finta ma ben scritta, invece, no. Sembra plausibile, coerente, indistinguibile da una vera per chiunque la legga. E dietro non c’è nessuno capace di sostenerla, se lo si mette alla prova.
Non è un’impressione isolata. La letteratura di governance ha già un nome per il fenomeno, AI evidence gap, il divario tra il sapere che l’IA è stata usata e il riuscire a dimostrare come.
Ne discende uno spostamento di prospettiva, dal system logging, cioè chi ha fatto cosa e quando, al decision logging, ovvero la registrazione della logica che ha portato alla decisione.
Non è materia da convegno per consulenti. I principali framework di riferimento, dal NIST all’AI Act europeo, spingono ormai nella stessa direzione, e trattano la tracciabilità del ragionamento come una cosa dovuta, non come un extra.
Un’organizzazione può quindi conservare in modo impeccabile il comando eseguito, e anche una motivazione scritta a regola d’arte, e aver perso lo stesso l’unica cosa che a un revisore interessa davvero, ovvero che dietro quelle parole ci sia stata una valutazione reale del rischio.
La stessa ISO 27001, in materia di change management, non chiede soltanto di registrare i cambiamenti. Chiede che vengano valutati e autorizzati da chi ne comprende l’impatto.
Un modulo compilato non equivale a una valutazione. È la prova che qualcosa è stato scritto, non che qualcosa è stato capito.
Qui comincia la parte scomoda. Il CISO è il garante della governance. Deve poter dimostrare a un revisore, a un cliente o a un’autorità che ogni modifica critica è passata sotto gli occhi di qualcuno con la competenza per valutarla.
Se quella valutazione non è mai avvenuta, e al suo posto c’è un’esecuzione fiduciosa ben documentata, il CISO finisce per firmare una tracciabilità che non tracciava niente.
Il punto non è che qualcuno abbia mentito. Il processo ha semplicemente smesso di produrre la sostanza che il modulo di change management presuppone, e ha continuato a produrne la forma.
La forma regge fino al giorno in cui qualcuno la interroga sul contenuto.
Notte, ticket ad alta priorità, un servizio esposto non risponde.
Il tecnico di turno descrive il sintomo all’assistente AI, riceve un comando che allarga una regola del firewall, lo applica e il servizio torna su. Il change è chiuso.
Nel campo motivazione compare “regola aggiornata per ripristinare la raggiungibilità del servizio”. Ha funzionato, il sintomo è sparito. La motivazione, per come è scritta, passerebbe qualunque revisione. Nessuno però, quella notte, ha saputo rispondere alla domanda che contava. Quella regola, oltre a risolvere il downtime, cosa lascia esposto?
Il comando serviva a far tornare verde il monitor, non a tenere in sicurezza il perimetro. E nessuno, quella notte, era nella posizione di accorgersi della differenza. Tre settimane dopo, quella regola allargata è la porta d’ingresso di un incidente. E il fascicolo di change, tecnicamente, è in ordine.
È qui che il tema smette di essere una questione di igiene procedurale e diventa un problema di conformità con conseguenze personali.
Con la NIS2, recepita in Italia dal decreto NIS (D.Lgs. 138/2024), la cybersicurezza esce dal perimetro del solo reparto tecnico. Il decreto stabilisce che siano gli organi di amministrazione e direttivi ad approvare le misure di gestione del rischio, a sovrintenderne l’attuazione e a risponderne in prima persona. Non si scarica né sul reparto IT né sul fornitore, tanto meno sull’assistente conversazionale.
Il compito si delega, a un tecnico, a un fornitore, a uno strumento. Il dover rispondere no, quello resta ancorato dov’era, e nessun framework aveva previsto che potesse sparire lungo la catena senza che nessuno se ne accorgesse.
E le misure che il decreto pretende ruotano attorno a un principio semplice. L’analisi del rischio viene prima dell’azione, non dopo.
Prima bastava avere un log delle modifiche. Adesso bisogna dimostrare che il rischio è stato valutato prima di agire. In caso di incidente, un auditor esterno che chiede perché una certa modifica è stata approvata e si sente rispondere, “l’ha suggerito l’IA”, mette la governance in una posizione indifendibile. Non a causa della modifica, ma per il vuoto a monte, là dove sarebbe dovuto esistere un ragionamento umano verificabile.
E il calendario non gioca a favore di chi rimanda. Mancano due mesi al 31 ottobre 2026, il termine entro cui i soggetti NIS devono aver implementato le misure di sicurezza di base. Da quella data l’ACN esce dalla fase di accompagnamento ed entra in quella di verifica e ispezione. Il periodo in cui “abbiamo il log” bastava come risposta sta per terminare.
Vietare l’IA nell’operatività sarebbe una battaglia persa, e probabilmente sbagliata. Il punto non è mai stato il comando, ma la prova che dietro ci sia stata una comprensione.
La reazione istintiva è aggiungere un campo obbligatorio in cui l’esecutore scrive il “perché” con parole sue. È la prima cosa che cade, perché quel campo lo riempie l’IA in tre secondi. Basta chiederle anche la giustificazione e incollarla. Casella spuntata, comprensione zero. Se la prova è un testo, e il testo si può generare, quella prova non prova più niente.
Nessun campo del change log può garantire che dietro esista una comprensione umana. La prova va messa dove l’IA non arriva, in una persona a cui fare due domande prima che la modifica venga applicata. Cosa lascia esposto questa modifica, e cosa succede se è sbagliata. Chi ha capito risponde, chi ha incollato si ferma. Non è un adempimento in più, è l’unico controllo che regge, perché un testo si falsifica mentre una persona si interroga.
Il resto viene di conseguenza. L’output dell’IA torna a essere un input e non un’autorità. “Suggerito dall’assistente” è un punto di partenza, non un timbro. La validazione resta l’atto umano che segue, registrato con un nome accanto. E se l’esecutore non regge le domande, non è colpa sua né dell’IA. Significa che una modifica sta per entrare in produzione senza che nessuno l’abbia capita, ed è lì che deve fermarsi, finché fermarla costa ancora poco.
L’audit invisibile non è quello che manca. È quello che c’è, sembra in ordine, e non regge la prima domanda seria. Spostare la prova sulla persona è l’unico modo per renderlo di nuovo visibile.
Betti RHC, la prima graphic novel al mondo dedicata alla cybersecurity awareness, ha finalmente il suo sito ufficiale. Uno spazio tutto suo dove scoprire il progetto, sfogliare le copertine degli episodi e immergersi nel mondo di Betti: la giovane laureanda in informatica che, dopo la morte misteriosa del padre, si trasforma nell'hacker più potente del mondo. Una storia avvincente che, episodio dopo episodio, affronta una minaccia digitale diversa — dal phishing al ransomware, fino al cyberbullismo — e insegna a riconoscerla e a difendersi, senza che sembri mai una lezione.
Sul sito trovate tutto ciò che rende Betti un progetto diverso dal solito: la sua filosofia, le anteprime delle tavole e il racconto di come nasce ogni volume. Perché dietro Betti RHC c'è solo lavoro umano: ogni tavola è disegnata interamente a mano dagli artisti del Gruppo Arte di Red Hot Cyber, senza alcun uso di intelligenza artificiale. E a garantire che ogni storia sia realistica e tecnicamente corretta c'è la supervisione degli hacker etici del gruppo HackerHood, che mantengono il racconto fedele al mondo reale della sicurezza informatica.
C'è spazio anche per le aziende, che possono usare Betti come strumento di awareness diverso dai soliti corsi: acquistare i volumi, personalizzarli con il proprio brand o sponsorizzare nuovi episodi. E come primo regalo, l'episodio "Byte the Silence", dedicato al cyberbullismo, è scaricabile gratuitamente per uso personale.
Perché la miglior difesa, in fondo, è una bella storia. 👉 Scopri tutto su https://betti.redhotcyber.com/