L’evoluzione dell’intelligenza artificiale sta ridefinendo in modo profondo non solo le capacità di analisi dei dati, ma anche le modalità con cui le informazioni possono essere alterate, simulate o rese indistinguibili dall’autentico. In questo scenario emergono le tecniche anti-forensics assistite dall’AI, che spaziano dal data poisoning alla manipolazione della firma fotografica PRNU, fino ai deepfake e agli evasion attacks, mettendo in crisi la stabilità epistemologica della prova digitale.

Il contributo, che fa parte di una serie dedicata all’impatto dell’intelligenza artificiale sui sistemi probatori e sulle dinamiche del processo penale contemporaneo, analizza le principali categorie di attacchi e manipolazioni, mostrando come l’AI possa essere utilizzata sia per alterare i dati in ingresso ai modelli sia per falsificare log, immagini, contenuti multimediali e output algoritmici. L’obiettivo è evidenziare le implicazioni forensi di queste tecniche e la necessità di approcci probatori fondati su catene di verifica multiple e indipendenti.

Tecniche anti-forensics assistite dall’AI

Data poisoning, PRNU manipulation, deepfake ed evasion attacks: l’arsenale operativo dell’anti-forensics assistita dall’AI.

Data shaping e data poisoning

Il modellamento del dato (data shaping) consiste nell’alterare il dato prima che venga analizzato, senza renderlo necessariamente sospetto all’occhio umano o agli strumenti tradizionali. L’avvelenamento del dataset (data poisoning) colpisce invece i dati di addestramento, aggiornamento o affinamento del modello (fine-tuning), inducendo il sistema ad apprendere correlazioni errate o comportamenti distorti.

Goldblum et al. hanno sistematizzato questa categoria di attacchi in uno studio pubblicato su IEEE Transactions on Pattern Analysis and Machine Intelligence, distinguendo tra avvelenamento della disponibilità, volto a degradare le prestazioni generali, e avvelenamento per inserimento di backdoor, che induce comportamenti malevoli specifici attivabili da un innesco (trigger) predefinito.

Il caso Microsoft Tay (2016), benché non forense in senso stretto, rimane il riferimento emblematico: il chatbot fu ritirato dopo circa sedici ore perché un attacco coordinato sfruttava la sua capacità di apprendimento online per contaminarlo con contenuti offensivi e ideologicamente connotati. Il caso (documentato in un episodio reale) dimostra che un sistema AI può essere compromesso non perché difettoso nella propria architettura, ma perché esposto deliberatamente a un ambiente informativo ostile.

In ambito forense il parallelo è diretto: un modello linguistico impiegato per riassumere, classificare o correlare chat, messaggi di posta elettronica o documenti sequestrati potrebbe incontrare un corpus previamente manipolato con testi orientati, istruzioni ambigue o dati semanticamente falsificati. A ciò si aggiunge il rischio dell’iniezione di prompt indiretta (indirect prompt injection, IPI): un documento apparentemente innocuo, processato da un sistema AI nell’ambito di un’analisi forense, può contenere istruzioni nascoste capaci di alterare le conclusioni del modello senza lasciare tracce evidenti nei log applicativi ordinari. Per questo la letteratura sulla forensic readiness dei sistemi LLM insiste sull’invocation logging: registrazione strutturata dell’inferenza, con timestamp, identificatori di sessione, prompt completo, contesto utilizzato, parametri rilevanti e output generato.

Implicazione forense: ogni dato in ingresso a un sistema AI deve essere conservato nella forma grezza originale, autenticato con firma crittografica, sottoposto a controllo delle versioni e mantenuto separato dal dato trasformato. L’output del sistema AI non è mai valutabile in modo autonomo senza conoscere il dataset di partenza, il prompt esatto, il contesto operativo e l’intera catena delle trasformazioni subite dal dato.

Costruzione artificiosa dei log: fabbricare una realtà tecnicamente plausibile

Il log crafting consiste nella creazione o manipolazione di registrazioni di sistema formalmente coerenti: sintassi corretta, timestamp credibili, sequenze compatibili, messaggi verosimili. Il rischio specifico è che un sistema AI, addestrato al riconoscimento di pattern statistici, accetti come autentica una sequenza artificiale non perché difettoso, ma perché quella sequenza è stata confezionata per soddisfare esattamente i criteri di validità che il sistema impara a riconoscere.

Il caso Stuxnet rimane il riferimento storico più documentato di manipolazione sistematica della percezione dello stato di un sistema. Il malware modificava segretamente il funzionamento dei PLC Siemens S7-315 e S7-417 inviando agli operatori letture false che mostravano condizioni operative normali, mentre i macchinari venivano progressivamente danneggiati. Falliere, Murchu e Chien descrivono la componente rootkit come un replay attack sul canale di comunicazione PLC, rappresentando il primo caso documentato di malware capace di manipolare la percezione dello stato fisico di un impianto industriale. La logica sottostante, mostrare al sistema di monitoraggio una realtà diversa da quella effettiva, è la medesima che governa il log crafting assistito da AI in contesto forense.

In assenza di una fonte sperimentale univoca e stabilizzata, il log crafting assistito da AI deve essere qualificato come rischio metodologico emergente, non come risultato forense già consolidato. La capacità dei modelli linguistici di generare sequenze sintatticamente corrette e temporalmente plausibili impone comunque una cautela processuale precisa: i log sono spesso una fonte primaria in indagini su accessi non autorizzati, frodi informatiche ed esfiltrazione di dati, ma non devono essere valutati isolatamente.

Sul piano operativo, essi devono essere sistematicamente triangolati con fonti indipendenti non controllate dalla stessa parte: sistemi EDR, piattaforme SIEM, log di firewall e proxy, telemetria cloud, Master File Table (MFT), USN Journal ($UsnJrnl), Event Log di Windows, dati di flusso di rete (netflow e netcap), timeline applicative e repliche su sistemi remoti. La single-source evidence, ossia la prova che poggia su una sola fonte, in particolare se filtrata da un sistema AI, è strutturalmente fragile e non può fondare, da sola, una pronuncia di condanna.

PRNU manipulation: alterazione della firma della sorgente fotografica

Fondamenti della tecnica. La Photo Response Non-Uniformity (PRNU) costituisce, allo stato attuale della disciplina forense, il riferimento metodologico più robusto per l’attribuzione di un’immagine digitale a uno specifico dispositivo di acquisizione. Il suo impiego sistematico trova fondamento nel lavoro seminale di Lukáš, Fridrich e Goljan, che dimostrarono come le imperfezioni microscopiche introdotte in fase di fabbricazione del sensore CMOS o CCD generino un pattern di risposta fotoelettrica statisticamente univoco e riproducibile. La firma PRNU è indipendente dai metadati EXIF e non eliminabile attraverso la semplice rimozione degli header del file.

Il fingerprint-copy attack e le sue evoluzioni. L’attacco più documentato è il fingerprint-copy attack: l’avversario, disponendo di un campione di immagini scattate con il dispositivo bersaglio, estrae la stima del PRNU di quel sensore e la sovrappone a immagini provenienti da un dispositivo diverso, inducendo l’algoritmo di identificazione a classificare erroneamente la sorgente.

Li, Luo, Rao e Huang hanno proposto un attacco migliorato che opera con un metodo a blocchi (block-wise), sovrapponendo la firma in maniera dispersa e non uniforme sull’immagine bersaglio. La calibrazione dell’intensità della firma iniettata è vincolata alla qualità oggettiva dell’immagine risultante, riducendo così la componente non-PRNU rilevabile dal triangle test. Gli esperimenti, condotti su 2.900 immagini provenienti da quattro fotocamere distinte, confermano l’efficacia dell’attacco (risultato dimostrato sperimentalmente).

Il triangle test, introdotto da Goljan e Fridrich per contrastare il fingerprint-copy, sfrutta la correlazione anomala tra immagini sottratte e immagini falsificate. Marra et al. hanno dimostrato che anche questo test è attaccabile. Sul versante delle contromisure, Barni, Santoyo García e Tondi hanno proposto una statistica pooled migliorata per rafforzare il triangle test contro l’attacco fingerprint-copy mentre un successivo studio, con compagine d’autore parzialmente diversa, ne ha mostrato il superamento, evidenziando i limiti del test pooled nell’identificazione PRNU. L’approccio Universal Wavelet Relative Distortion (UWRD), documentato da Sameer e Naskar, offre infine un attacco counter-forensic basato su trasformata wavelet che mira a sopprimere l’impronta PRNU senza introdurre artefatti visibili macroscopici.

Deep learning: dualismo offensivo-difensivo. Le medesime architetture di apprendimento profondo che hanno rafforzato la capacità di identificazione della sorgente vengono ora impiegate anche come strumenti di attacco. Sul versante difensivo, reti convoluzionali (CNN), strutture residuali e contrastive learning estraggono l’impronta PRNU con maggiore robustezza rispetto ai metodi statistici tradizionali. Sul versante offensivo, le stesse architetture possono essere addestrate per sopprimere, falsificare o sostituire l’impronta in modo impercettibile: un approccio definibile adversarial fingerprint manipulation, che opera in modo automatizzato, scalabile e adattivo rispetto alle contromisure forensi note. La letteratura più recente conferma che nessun metodo di identificazione, tradizionale o neurale, può essere considerato immune ad attacchi mirati condotti con strumenti di deep learning.

Principio processuale: l’attribuzione di un’immagine a uno specifico dispositivo non può fondarsi esclusivamente su una correlazione PRNU positiva ottenuta mediante algoritmo automatico. Ogni perizia deve soddisfare condizioni concorrenti:

• disponibilità dell’immagine originale con catena di custodia verificabile;
• dataset di riferimento statisticamente significativo;
• verifica di coerenza temporale e integrità crittografica dei metadati;
• esclusione di ricampionamento o ricompressione;
• analisi manuale integrativa da parte di un esperto.

La forza probatoria della PRNU risiede nella convergenza con altri elementi, non nella sua autonomia.

Content-aware fill, inpainting e deepfake: l’evidenza visiva come simulazione persuasiva

Tassonomia delle tecniche di manipolazione sintetica. Il content-aware fill e l’inpainting computazionale rimuovono o sostituiscono porzioni di un’immagine attraverso algoritmi di completamento contestuale basati su GAN o modelli di diffusione, producendo riempimenti visivamente coerenti. Il deepfake video sostituisce o sintetizza il volto di un individuo in sequenze video mediante architetture encoder-decoder. Il voice cloning replica le caratteristiche acustiche della voce (timbro, cadenza, intonazione, pattern prosodici) da campioni audio anche molto brevi, producendo sintesi difficilmente distinguibile dall’originale in condizioni di ascolto non specialistico. Sistemi come VALL-E hanno mostrato la possibilità di generare una voce sintetica a partire da campioni di circa tre secondi.

In contesto forense, il problema non risiede soltanto nella distinzione tra autentico e falsificato, ma nella capacità di provare, con standard processuali, tre elementi distinti: l’origine del file, la sua integrità nel tempo e il contesto della sua produzione e diffusione.

Il caso Arup (Hong Kong, 2024). Nel gennaio 2024 un dipendente della filiale di Hong Kong della società di ingegneria britannica Arup eseguì quindici bonifici bancari per un importo complessivo di circa 200 milioni di dollari di Hong Kong (circa 25,6 milioni di dollari statunitensi), distribuiti su cinque conti correnti, a seguito di una videoconferenza nella quale tutti i partecipanti, ad eccezione della vittima, erano rappresentazioni deepfake di dirigenti reali.

L’accesso iniziale era avvenuto tramite spear-phishing impersonante il CFO; i deepfake erano stati costruiti da materiali video e audio prelevati da conferenze aziendali pubblicamente accessibili. La Hong Kong Police Force ha confermato che nessun soggetto è stato arrestato, i fondi non sono stati recuperati e l’attribuzione dell’attacco rimane aperta (caso reale documentato). L’episodio documenta tre vulnerabilità sistemiche:

• l’assenza di un canale di autenticazione out-of-band per le disposizioni finanziarie;
• l’assenza di protocolli di verifica dell’identità del chiamante nelle videoconferenze;
• la mancanza di formazione specifica del personale sull’identificazione di segnali visivi e vocali di sintesi artificiale.

Il caso Zelensky (Ucraina, marzo 2022). Il 16 marzo 2022 fu diffuso un video deepfake del presidente Zelensky che simulava un appello alla resa. Il professore Hany Farid (UC Berkeley) identificò anomalie nella proporzione testa-corpo, incongruenze nell’accento e artefatti di temporizzazione caratteristici delle architetture di face-swapping. Il video fu smentito e rimosso dalle principali piattaforme. Si tratta di uno dei primi episodi documentati di impiego operativo del deepfake in un contesto bellico attivo con finalità di disinformazione strategica.

Metodologia forense e protocollo di autenticazione. Le metodologie attualmente più consolidate analizzano le inconsistenze spazio-temporali tra fotogrammi consecutivi. Il modello MVFNet estrae congiuntamente feature forensi spaziali e temporali per rilevare inpainting, deepfake, splicing e re-encoding. Metodi basati sulla trasformata di Fourier sull’asse temporale pixel per pixel consentono di individuare periodicità artificiali introdotte dai generatori nella dimensione temporale. Una rassegna sistematica dei metodi forensi per l’identificazione multimodale di deepfake sui social media conferma che l’affidabilità di questi strumenti dipende fortemente dalla qualità del campione e che nessuno di essi è, da solo, conclusivo.

Sul piano della provenienza, il C2PA (Coalition for Content Provenance and Authenticity) ha rilasciato la specifica 2.2 nel 2025. Le Content Credentials costituiscono un meccanismo promettente di provenance tracking, ma non sono una garanzia assoluta: i manifest possono essere rimossi in fase di upload, ricodifica o distribuzione, e l’assenza di credenziali non consente, da sola, alcuna inferenza conclusiva sull’origine artificiale o autentica del contenuto. Per il voice cloning, uno studio del 2025 ha documentato criticità significative dei sistemi di speaker verification e degli strumenti anti-spoofing in condizioni realistiche, tra rumore, compressione e variabilità degli algoritmi di clonazione.

Principio fondamentale: un video convincente non è una prova; è un artefatto digitale che richiede autenticazione indipendente. Il protocollo forense prevede:

• ricostruzione del primo upload verificabile (timestamp, piattaforma, URL, hash);
• analisi della catena di diffusione;
• esame dei metadati embedded e delle codifiche successive;
• confronto con fonti indipendenti coeve;
• valutazione del contesto di pubblicazione.

Come rilevato da Farid, nessuna tecnica di rilevamento può essere trattata come prova autonoma e definitiva in assenza di un contesto probatorio convergente.

Evasion attacks: modifiche minime, effetti massimi

Fondamenti teorici. Gli evasion attacks operano in fase di inferenza: il modello è già addestrato, i parametri sono fissi, e la manipolazione riguarda esclusivamente l’input. Si distinguono dagli attacchi di data poisoning, che agiscono in fase di addestramento, e dagli attacchi di model extraction o membership inference. Il principio fondante fu formalizzato da Szegedy et al.: perturbazioni di ampiezza impercettibile, ottimizzate tramite L-BFGS, sono sufficienti a indurre l’errore di classificazione con confidenza elevata.

Goodfellow, Shlens e Szegedy fornirono la spiegazione meccanicistica attraverso il Fast Gradient Sign Method (FGSM): la linearità delle reti negli spazi ad alta dimensione è la causa strutturale della vulnerabilità. Carlini e Wagner hanno proposto tre metodi di ottimizzazione per le norme L0, L2 e L-infinito, diventati il benchmark di riferimento per la valutazione della robustezza adversarial.

Brown et al. hanno introdotto il concetto di adversarial patch: un pattern visivo stampabile e applicabile fisicamente che produce misclassification indipendentemente da posizione, scala e orientamento. Eykholt et al. hanno dimostrato che sticker applicati a segnali stradali, visivamente percepibili come atti vandalici ordinari, inducevano misclassification nel 100% delle immagini in laboratorio e nell’84,8% dei fotogrammi catturati da un veicolo in movimento per il classificatore bersaglio (risultato dimostrato sperimentalmente). Il principio forense diretto è di rilevanza immediata: la soglia di plausibilità di un attacco adversarial non coincide con quella della percezione umana.

Il caso Tencent Keen Security Lab – Tesla Autopilot, 2019. Il documento tecnico Experimental Security Research of Tesla Autopilot dimostrò sperimentalmente che l’apposizione di tre piccoli sticker sulla carreggiata era sufficiente per indurre il sistema di riconoscimento delle corsie del Tesla Model S a generare un comando di sterzo nella corsia opposta. Il rapporto documentava ulteriori superfici di attacco: attivazione dei tergicristalli tramite adversarial example fisico e controllo dello sterzo mediante gamepad wireless. L’esperimento dimostra che la frontiera dell’attacco include la manipolazione dell’ambiente percepito dal sistema, aprendo scenari di rischio che i modelli tradizionali di threat modeling non contemplano.

Evasion attacks nel dominio malware. Demetrio et al. hanno dimostrato che la modifica funzionalmente neutrale di sezioni inutilizzate dei file Windows PE, con iniezione di contenuto adversarial ottimizzato, può indurre misclassification nel classificatore MalConv. La letteratura successiva ha esteso il problema sia agli attacchi contro classificatori malware sia alla generazione di falsi positivi sistematici, ma i tassi di evasione dipendono fortemente da modello, dataset, vincoli funzionali del file e scenario sperimentale. In un contesto processuale è quindi metodologicamente scorretto trasferire percentuali ottenute in laboratorio direttamente al caso concreto senza validazione specifica.

Implicazione processuale: un classificatore AI che dichiara un file benigno, una conversazione non rilevante o un’immagine autentica deve essere trattato esclusivamente come strumento di triage. La sua pronuncia è condizionata dall’insieme di pattern appresi durante l’addestramento, dalla distribuzione del dataset, dall’assenza di esempi adversarial nel training set e dall’assenza di attacchi attivi al momento dell’inferenza: quattro condizioni non verificabili a posteriori senza documentazione rigorosa della pipeline di sviluppo del modello.

Ulteriori superfici di attacco nella catena della prova

Documenti, comunicazioni e codice malevolo AI-generato spostano il problema sull’attribuzione e sulla catena della prova.

Documenti testuali e comunicazioni

La generazione di documenti testuali è la capacità più consolidata dei sistemi AI attuali. Un LLM di qualità commerciale può generare contratti, email e messaggi di testo con stile linguistico personalizzato (voice cloning testuale); completare documenti lacunosi in modo stilisticamente coerente; tradurre mantenendo artefatti linguistici che simulano autenticità; generare metadati credibili per file Office.

Kirchenbauer et al. hanno proposto tecniche di watermarking per LLM, ma senza marcatori preventivi l’identificazione del testo AI rimane statisticamente fragile. Sadasivan et al. hanno evidenziato un limite strutturale dei sistemi di rilevazione del testo generato da AI: quando chi produce il testo conosce, o può interrogare, il detector utilizzato per valutarlo, può progressivamente modificare l’output fino a renderlo meno riconoscibile come artificiale. Ne deriva che tali strumenti possono avere utilità orientativa o di triage, ma non possono essere impiegati, da soli, come prova dell’origine artificiale di un documento in sede processuale.

Implicazione processuale: un documento presentato come prova non può essere autenticato basandosi esclusivamente sull’analisi del testo; è necessario risalire ai sistemi di origine, verificare i log dei server, analizzare la trasmissione di rete e le copie di backup indipendenti. In mancanza di tali riscontri, la sola analisi stilistica, sia essa compiuta da un esperto umano o da un sistema AI, non può assurgere a prova di autenticità o di falsità nel contesto processuale.

Codice malevolo AI-generato e attribuzione forense

Sistemi e servizi malevoli pubblicizzati come WormGPT e FraudGPT, richiamati da report di threat intelligence del 2023, sono stati presentati come strumenti per generare campagne di phishing e contenuti offensivi altamente personalizzati.

Per il consulente o perito informatico forense, il codice malevolo generato o assistito da AI introduce una criticità specifica: l’attribuzione dell’autore. Tradizionalmente, alcuni elementi stilistici del codice (denominazione delle variabili, struttura delle funzioni, commenti, scelte algoritmiche e ricorrenze sintattiche) potevano contribuire, insieme ad altri indicatori tecnici, a formulare ipotesi sull’autore o sul gruppo di attori coinvolto. L’intervento dell’AI tende però a uniformare, alterare o mascherare tali impronte individuali; ne consegue che l’attribuzione forense diventa più fragile e non può fondarsi sul solo stile del codice, ma richiede la convergenza di ulteriori elementi: infrastruttura utilizzata, catena di distribuzione, telemetria, log, artefatti di compilazione, contesto operativo e, ove disponibili, tracce relative al servizio AI eventualmente impiegato.

Ciò incide sulla tenuta complessiva della ricostruzione tecnico-probatoria nei procedimenti per cybercrime: per l’accusa, rende più fragile l’attribuzione del codice malevolo a un determinato autore o gruppo di attori; per la difesa, impone la possibilità di contestare in modo tecnicamente fondato inferenze attributive basate su indicatori stilistici non più sufficientemente affidabili. Ne deriva la necessità di rivedere i metodi tradizionali di attribuzione, privilegiando approcci multi-fonte fondati sulla convergenza tra codice, infrastruttura, telemetria, log, artefatti di compilazione e contesto operativo.

Il contributo di Cosimo de Pinto offre una ricognizione delle principali tecniche di anti-forensics assistite dall’AI, evidenziando come data poisoning, manipolazione della firma PRNU, sintesi di contenuti multimediali e attacchi di evasione possano incidere in modo strutturale sulla produzione e sulla valutazione della prova digitale. Ne emerge un quadro in cui non solo i dati e i modelli possono essere alterati, ma anche le tracce stesse dell’attività informatica diventano potenzialmente costruibili, sollevando criticità rilevanti in termini di affidabilità e verificabilità.

Per un approfondimento sistematico di queste dinamiche, si invita alla lettura del paper di Cosimo De Pinto “Quando l’AI mente bene: deepfake, prova digitale e anti-forensics nel processo penale”, che sviluppa in modo organico il rapporto tra intelligenza artificiale, attendibilità della prova e criticità processuali, offrendo un quadro teorico e operativo indispensabile per comprendere l’impatto dell’AI sul diritto probatorio contemporaneo.

https://www.ictsecuritymagazine.com/articoli/tecniche-anti-forensics/

L’adozione di sistemi di intelligenza artificiale generativa sta producendo una trasformazione profonda nel modo in cui il diritto processuale penale interpreta, valuta e utilizza la prova digitale. Ciò che per anni è stato considerato un elemento relativamente stabile e verificabile ovvero il dato digitale come traccia dell’origine di un evento o di un’azione entra oggi in una fase di progressiva instabilità epistemica. La possibilità di generare contenuti artificiali altamente coerenti, completi di metadati plausibili e strutture tecniche formalmente corrette, incrina infatti uno dei presupposti storici della digital forensics: la corrispondenza tra traccia e origine.

Questo articolo si inserisce all’interno della serie di approfondimenti a cura di Cosimo de Pinto dal titolo “Quando l’AI mente bene – Deepfake, prova digitale e anti-forensics nel processo penale”. L’approfondimento analizza la frattura introdotta dall’AI generativa nel paradigma tradizionale della prova informatica, evidenziando come la “plausibilità sintetica” possa sostituirsi alla tracciabilità dell’origine come criterio implicito di affidabilità.

Nel testo si esamina la discontinuità tra anti-forensics classica e nuove tecniche abilitate dall’intelligenza artificiale, mettendo in luce il passaggio da strategie di occultamento o distruzione della prova a sistemi capaci di costruire evidenze artificiali credibili e difficilmente distinguibili da quelle autentiche. L’analisi si concentra inoltre sulle implicazioni processuali di tale evoluzione, con particolare attenzione ai rischi per la valutazione giudiziale della prova digitale e alle possibili ricadute sulla presunzione di innocenza e sulla libertà personale.

La fine dell’innocenza digitale

L’AI generativa incrina il presupposto che la prova digitale rifletta sempre la propria origine.

La digital forensics si è sviluppata, nel corso dei suoi tre decenni di storia disciplinare, attorno a un presupposto implicito: i dati digitali conservano tracce della propria origine, e tali tracce possono essere estratte, interpretate e presentate come prova con ragionevole certezza scientifica. Un file aveva una biografia verificabile: nasceva in un momento preciso, recava l’impronta del software che lo aveva generato, i metadati del sistema operativo, le impronte dell’hardware. Su questo fondamento, ben descritto nella manualistica di riferimento, si è costruita l’intera architettura processuale della prova digitale nei sistemi giuridici occidentali.

Dal paradigma classico alla frattura epistemica

	Computer forensics classica	Scenario AI generativa
Presupposto di base	Le tracce digitali riflettono l’origine del dato	Un contenuto può simulare un’origine credibile
Obiettivo dell’analisi	Ricostruire eventi e attribuire provenienza	Verificare anche la possibilità di un’origine sintetica
Segni di manipolazione	Spesso lasciano anomalie residue	Possono imitare pattern statisticamente plausibili
Ruolo dell’esperto	Interpretare tracce e coerenze tecniche	Corroborare, autenticare e contestualizzare
Rischio giuridico	Errore tecnico circoscritto	Potenziale violazione della libertà personale

L’avvento dei modelli generativi di intelligenza artificiale, in particolare dei Large Language Models (LLM), dei modelli text-to-image, dei sintetizzatori vocali neurali e dei sistemi di video synthesis, ha introdotto nella catena della prova digitale una variabile che i framework forensi tradizionali non erano stati progettati per gestire: la plausibilità sintetica. Un documento, un’immagine, una registrazione audio o video possono oggi essere generati artificialmente in modo da superare non soltanto la percezione umana, ma anche una parte significativa delle analisi strumentali disponibili ai laboratori forensi. Come osservato dalla letteratura tecnica più recente, gli avversari non si limitano più a nascondere le prove: le costruiscono, le avvelenano e orientano l’investigatore verso una narrazione falsa.

Le conseguenze di questa trasformazione non sono confinabili all’ambito tecnico. Nei procedimenti penali, ogni errore nella valutazione di una prova digitale si traduce in una potenziale violazione della libertà personale. Un soggetto innocente può essere condannato sulla base di una conversazione WhatsApp mai avvenuta, di un’immagine fotografica manipolata, di un video che lo mostra in un luogo in cui non si è mai recato, di un log di sistema artatamente costruito per collocarlo in prossimità di un reato. L’AI non mente come un essere umano: produce output statisticamente coerenti, difficili da smascherare con gli strumenti tradizionali, e capaci di ingannare persino analisti esperti.

Ogni errore nella valutazione di una prova digitale si traduce in una potenziale violazione della libertà personale.

Il presente paper analizza le intersezioni tra AI generativa, tecniche di anti-forensics e il concetto giuridico di prova digitale, con attenzione alle implicazioni pratiche per consulenti tecnici, avvocati e magistrati. Vengono esaminate le principali superfici di attacco, le tecniche di evasione forense abilitate dall’AI, i framework di auditabilità esistenti, le lacune normative che rendono urgente un ripensamento del valore probatorio del dato digitale e, soprattutto, i rischi concreti per la libertà delle persone che derivano da un approccio acritico all’impiego dell’AI in sede processuale.

Metodo, contributo e domanda di ricerca

Metodo. Sintesi critica interdisciplinare che incrocia letteratura peer-reviewed, casi documentati, standard normativi e implicazioni processuali della prova digitale nell’era dell’AI generativa.

Contributo. Un quadro di sintesi tra tecnica di attacco, artefatto colpito, contromisure e rischio residuo; ricostruzione del nesso tra auditabilità tecnica e tenuta probatoria; proposta di principi guida per una digital forensics AI-resistant.

Domanda di ricerca. In che modo l’AI generativa trasforma la natura della prova digitale e quali condizioni metodologiche e giuridiche sono necessarie per conservarne l’affidabilità?

Questo paper affronta una delle sfide più critiche e meno sistematizzate dell’attuale panorama della sicurezza informatica applicata al diritto: l’impatto dell’intelligenza artificiale generativa sull’affidabilità delle prove digitali nei procedimenti penali. Non si tratta di uno scenario futuro. Le tecniche qui analizzate (data poisoning, log crafting, PRNU manipulation, deepfake, voice cloning, evasion attacks) sono operative già oggi, e i loro effetti sul sistema giustizia sono documentabili. Il taglio è deliberatamente duplice, tecnico e giuridico, perché duplice è il pubblico cui il problema si rivolge: professionisti della sicurezza, consulenti tecnici d’ufficio e di parte, magistrati e avvocati che si trovano a maneggiare prove digitali la cui affidabilità non può più essere data per scontata.

Sul piano del metodo, il lavoro è una sintesi critica di taglio interdisciplinare. Sul versante tecnico incrocia la letteratura peer-reviewed su anti-forensics e adversarial machine learning con casi documentati di rilevanza processuale o geopolitica; sul versante giuridico procede a un’analisi dottrinale e giurisprudenziale del diritto della prova, ancorata alla normativa italiana ed europea vigente e agli standard tecnici internazionali della famiglia ISO/IEC 27000. Le fonti sono state selezionate privilegiando, ove disponibili, gli atti originali (paper, whitepaper, testi normativi, massime ufficiali) rispetto alle fonti secondarie.

Per onestà epistemica, ogni affermazione tecnica viene qualificata secondo tre gradi di evidenza, esplicitati nel testo: risultato dimostrato sperimentalmente in letteratura; condotta documentata in un caso reale; rischio metodologico emergente, ipotizzato in via teorica ma non ancora consolidato in giudicato.

Il contributo originale è triplice: un quadro di sintesi che mette in relazione ciascuna tecnica di attacco con l’artefatto forense colpito, la contromisura di rilevazione e il rischio residuo (sezione 5); un raffronto comparato tra l’ordinamento italiano e il modello angloamericano (sezione 7); e un framework forense resistente all’AI articolato in cinque principi operativi e quattro proposte normative (sezione 10). La domanda di ricerca che tiene insieme l’intero discorso è la seguente: a quali condizioni una prova digitale generata o mediata da sistemi AI può fondare un giudizio di responsabilità penale senza violare la presunzione di innocenza e il diritto a un equo processo?

Anatomia dell’anti-forensics tradizionale e la discontinuità dell’AI

Dalle tecniche che cancellano le tracce a un’AI che le costruisce: una rottura qualitativa, non solo quantitativa.

L’anti-forensics prima dell’AI

La disciplina dell’anti-forensics, intesa come l’insieme delle tecniche volte a ostacolare, fuorviare o rendere impossibile l’analisi forense di un sistema digitale, è quasi coeva alla nascita della computer forensics stessa. Harris la definisce come qualsiasi tentativo di compromettere la disponibilità o l’utilità delle prove in un processo forense.

Le tecniche classiche si articolano in quattro categorie principali:

• distruzione dei dati (data destruction) tramite sovrascrittura multipla secondo lo standard DoD 5220.22-M, degaussing o distruzione fisica del supporto;
• occultamento dei dati (data hiding) mediante steganografia, cifratura di volumi interi (VeraCrypt, BitLocker) e slack space exploitation;
• trail obfuscation mediante applicazioni portable, timestamp manipulation (Timestomp) e cancellazione selettiva dei log di sistema;
• attacchi alla capacità di analisi attraverso exploit nei tool forensi (FTK, EnCase, Autopsy), file artatamente costruiti (crafted) e tecniche anti-VM e anti-sandbox.

La caratteristica comune di queste tecniche è che esse lasciano tracce della propria applicazione: assenza dove dovrebbe esserci presenza, anomalie statistiche, pattern inusuali. In questa prospettiva, la forensics tradizionale lavora spesso sulla deviazione rispetto all’atteso: l’anti-forensics classica mirava a cancellare, occultare o rendere non interpretabile l’evidenza. Nell’ecosistema AI la logica cambia radicalmente.

La discontinuità dell’AI: quando l’assenza non fa rumore

L’AI generativa introduce una rottura epistemica nel paradigma descritto. Il problema non è produrre contenuti falsi: è produrre contenuti coerenti con le aspettative statistiche di un analista forense. Un LLM avanzato istruito a generare la trascrizione di una conversazione WhatsApp produrrà testo con le peculiarità linguistiche del presunto autore, con riferimenti contestualmente plausibili e struttura temporale coerente; se integrato con un generatore di metadati, produrrà file con timestamp consistenti, encoding corretto, struttura interna del database SQLite di WhatsApp formalmente valida.

La differenza rispetto all’anti-forensics tradizionale è qualitativa, non soltanto quantitativa: non si tratta necessariamente di un’anti-forensics più efficiente, ma di una crisi del concetto stesso di autenticità digitale. Il bersaglio reale diventa ciò che il modello vede: dati, log, metadati, timestamp, immagini, testo, prompt, contesto RAG, workflow, plug-in, API e catena software. L’AI non mente in senso umano; produce un output coerente rispetto all’input e al contesto che riceve. Se input e contesto sono manipolati, la conclusione può essere tecnicamente elegante e probatoriamente falsa.

L’AI non mente in senso umano; produce un output coerente rispetto all’input e al contesto che riceve.

L’approfondimento ha mostrato come l’AI generativa stia alterando in modo strutturale il concetto stesso di prova digitale, spostando l’attenzione dalla tracciabilità dell’origine alla plausibilità sintetica del contenuto. Questo passaggio segna una discontinuità profonda per la digital forensics e apre scenari in cui la distinzione tra dato autentico e dato costruito diventa sempre più complessa da stabilire, con conseguenze dirette sul piano processuale e sulla tutela della libertà personale.

Il prossimo articolo approfondirà le principali tecniche anti-forensics assistite dall’AI insieme alle nuove superfici di attacco lungo la catena della prova digitale, dai documenti alle comunicazioni fino al codice generato automaticamente.

Per un inquadramento più completo e sistematico, è possibile approfondire il paper di Cosimo de Pinto “Quando l’AI mente bene – Deepfake, prova digitale e anti-forensics nel processo penale”: la lettura consente di comprendere in modo organico le dinamiche tra attacco, prova digitale e rischio probatorio, offrendo un riferimento utile sia per l’analisi tecnica sia per l’applicazione nel contesto processuale.

 

https://www.ictsecuritymagazine.com/articoli/prova-digitale/

L’intercettazione nasce come problema di analisi del segnale: individuare una presenza attraverso le sue emissioni. Per lungo tempo ciò ha significato lavorare su radiofrequenze e trasmettitori, in un contesto in cui la minaccia era esterna al dispositivo.

Nel quadro contemporaneo del Metodo SPECTRA questa separazione non esiste più. La sorveglianza può essere interna al sistema operativo, integrata nei flussi di dati e mascherata nel traffico cifrato. Il problema si sposta dal segnale al comportamento del sistema.

Le tecniche TSCM tradizionali restano necessarie sul piano fisico, ma non coprono più l’intero dominio della minaccia. In questo scenario emerge anche il limite degli IOC: ciò che non è catalogato non è visibile. Da qui il passaggio ai pattern, con lo smartphone come nodo centrale.

Nel passaggio conclusivo, il punto critico è chiaro: una bonifica basata solo su indicatori noti è strutturalmente incompleta. Molte minacce moderne restano fuori campo perché non ancora classificate.

L’ultimo approfondimento si colloca in questa transizione: dagli IOC ai pattern, dalla verifica del noto alla lettura di comportamenti e anomalie nel tempo.

Cosa sono gli IOC e il limite delle signature

Nella bonifica logica moderna, soprattutto in ambito smartphone e PC, uno degli errori metodologici più frequenti è affidarsi esclusivamente agli Indicatori di Compromissione (IOC). Gli IOC sono uno strumento fondamentale nell’analisi forense e nella risposta agli incidenti, ma diventano pericolosi quando utilizzati come unico criterio decisionale.

Gli IOC sono elementi osservabili che indicano una possibile compromissione: hash di file malevoli, domini o IP associati a infrastrutture C2, nomi di processi noti, certificati digitali specifici, stringhe di firma binaria, pattern di traffico già classificati. Sono, di fatto, tracce riconosciute di minacce già identificate, e il loro funzionamento si basa su una logica semplice: se compare qualcosa già noto come malevolo, si segnala la compromissione. È il paradigma alla base di antivirus tradizionali, EDR basati su firme, database di spyware noti, blacklist DNS/IP e scanner mobile commerciali.

I sistemi basati su signature funzionano per confronto tra il campione osservato e un database di firme conosciute. Se il campione non è presente nel database, non viene rilevato e tende a essere classificato come pulito. Da qui un limite strutturale: un sistema basato su firme riconosce solo ciò che già conosce. In ambito TSCM logico questo è critico, perché uno spyware custom non sarà presente nei database pubblici, un’operazione mirata può usare infrastrutture dedicate e non tracciate, un captatore istituzionale non compare nelle blacklist commerciali e un malware evoluto può mutare hash a ogni build.

Database incompleti e minacce evolute

I database pubblici contengono indicatori relativi a spyware commerciali diffusi, trojan Android/iOS noti, famiglie malware catalogate e infrastrutture già smantellate, ma presentano limiti evidenti: lag temporale (l’indicatore viene pubblicato solo dopo analisi e disclosure), visibilità parziale (non tutte le operazioni vengono rese pubbliche), bias commerciale (i tool mostrano ciò che possono rilevare, non ciò che esiste) e cecità verso le operazioni mirate (una campagna altamente selettiva può non lasciare tracce pubbliche).

Il problema diventa evidente con minacce zero-day, malware polimorfico, captatori custom, infrastrutture temporanee, C2 su CDN legittime e uso di servizi cloud comuni. In questi casi l’IP può sembrare legittimo, il dominio neutro, il traffico cifrato HTTPS e il processo dotato di un nome innocuo. Dal punto di vista IOC puro non esiste alcun indicatore classificato come malevolo; dal punto di vista comportamentale possono invece emergere persistenza anomala, flussi dati costanti in orari atipici, connessioni ripetitive verso ASN non coerenti con l’uso dell’utente e pattern di esfiltrazione compatibili con sorveglianza remota.

L’illusione del “nessun risultato”

Uno dei rischi operativi maggiori è l’inferenza “non abbiamo trovato IOC, quindi il dispositivo è pulito”. L’affermazione è metodologicamente scorretta: l’assenza di IOC equivale solo a “non sono stati trovati indicatori già noti”, non ad “assenza di compromissione”. In ambito TSCM logico questo errore può portare a falsi negativi critici. Un approccio esclusivamente IOC-based è infatti reattivo, dipendente da intelligence esterna, non autonomo e non investigativo: non analizza il comportamento, non studia i pattern, non costruisce una baseline e non misura le anomalie relative al contesto. Si limita a confrontare.

IOC e minacce moderne: perché l’analisi da sola non è sufficiente

Nonostante i limiti, gli IOC restano preziosi: utili per identificare minacce note, fondamentali in ambito incident response, indispensabili per la correlazione OSINT e validi come primo filtro rapido. Il problema non è l’uso degli IOC, ma il loro uso esclusivo. In un contesto caratterizzato da spyware custom, captatori evoluti, infrastrutture dinamiche, cifratura end-to-end e servizi cloud legittimi, un’analisi basata solo su IOC è insufficiente. La vera differenza metodologica risiede nella capacità di analizzare ciò che non è ancora classificato, e richiede l’integrazione tra analisi degli indicatori noti e analisi dei pattern comportamentali, oggetto del capitolo seguente.

Approccio ibrido: IOC e analisi pattern-centrica

Nell’analisi del traffico acquisito durante attività di bonifica è frequente osservare dispositivi che mantengono connessioni periodiche verso un numero ristretto di endpoint dominanti. La distinzione tra servizi legittimi e possibili architetture di controllo remoto richiede quindi un’analisi quantitativa dei flussi nel tempo. Questo capitolo rappresenta il cuore metodologico della bonifica logica moderna.

In uno scenario caratterizzato da minacce evolute, infrastrutture distribuite e strumenti di sorveglianza sempre più modulari, nessun singolo approccio analitico è sufficiente. La metodologia efficace si fonda su un modello ibrido che integra analisi basata su IOC (Indicator of Compromise) e analisi pattern-centrica comportamentale. L’integrazione di queste due prospettive consente di ridurre i falsi negativi, aumentare la capacità di individuare minacce non catalogate e mantenere un impianto metodologico tecnicamente difendibile.

Analisi basata su IOC

L’analisi IOC individua indicatori noti, già associati a campagne di sorveglianza o malware documentati: indirizzi IP noti per attività C2, domini associati a infrastrutture di sorveglianza, hash di file malevoli, certificati digitali anomali, pattern di User-Agent riconducibili a tool specifici, processi o servizi riconosciuti come spyware commerciali. I vantaggi sono la rapidità di identificazione delle minacce già catalogate, l’alta affidabilità quando l’indicatore è verificato e la facilità di documentazione tecnica.

I limiti strutturali sono altrettanto netti: funziona solo su minacce note, è inefficace contro infrastrutture custom o dedicate ed è eludibile tramite rotazione IP, domini dinamici, CDN e tunneling. Nel contesto della sorveglianza professionale o statale, l’infrastruttura può essere dedicata, temporanea, non riutilizzata e priva di indicatori pubblici: in tali scenari l’analisi IOC può risultare formalmente corretta ma operativamente cieca.

Analisi basata su pattern

L’approccio pattern-centrico non cerca etichette, ma comportamenti. Non si domanda “questo IP è noto?”, ma “questo comportamento è coerente con un uso legittimo del dispositivo?”. L’osservazione comportamentale studia i flussi in termini di frequenza, durata, periodicità, volume e direzionalità, con l’obiettivo di individuare regolarità anomale: connessioni periodiche a intervalli costanti, trasmissioni notturne ripetitive, sincronizzazioni non giustificate dall’uso dell’utente.

In assenza di Deep Packet Inspection (DPI), l’analisi si basa su conteggi, distribuzioni e correlazioni temporali. Un flusso persistente è una comunicazione che si ripete nel tempo, mantiene endpoint stabili e mostra comportamento strutturato; la persistenza è un parametro chiave nella valutazione di compatibilità con scenari di monitoraggio remoto.

Un nodo dominante è un endpoint che concentra una percentuale significativa dei flussi, mantiene relazioni multiple e mostra comportamento di aggregazione: in un contesto di sorveglianza può rappresentare un server di raccolta, un relay o un punto di orchestrazione, ma la sua identificazione resta strutturale, non attributiva. L’analisi temporale è spesso decisiva: attività in assenza di interazione utente, picchi in orari specifici, variazioni cicliche e incrementi improvvisi di uplink. Nel contesto TSCM logico, l’uplink anomalo persistente è uno degli elementi più significativi, in quanto compatibile con scenari di esfiltrazione.

Integrazione operativa

L’approccio ibrido non è una semplice somma di tecniche, ma una sequenza logica: ricerca IOC per l’esclusione rapida di minacce note; analisi strutturale dei flussi; studio della persistenza; identificazione dei nodi dominanti; valutazione temporale; separazione tra traffico infrastrutturale normale e pattern compatibili con monitoraggio. L’analisi non produce certezze assolute, ma gradi di compatibilità, scenari probabilistici e valutazioni tecnicamente argomentabili.

Esempio illustrativo

Lo scenario seguente ha finalità esclusivamente didattiche. Non descrive un caso reale, ma serve a mostrare l’applicazione della separazione tra dato, analisi e ipotesi.

Si supponga di acquisire passivamente, per un periodo di osservazione di sette giorni, il traffico di rete di uno smartphone presente in un ambiente sensibile.

Il dato è l’insieme degli elementi osservabili e verificabili: lo smartphone stabilisce connessioni verso un medesimo endpoint a intervalli regolari di circa quindici minuti, anche nelle ore notturne e in assenza di interazione utente; il volume in uplink verso tale endpoint è costante e superiore al downlink; il flusso si mantiene su HTTPS e l’endpoint non compare in alcuna blacklist pubblica.

L’analisi interpreta questi elementi in relazione tra loro: la regolarità dell’intervallo è compatibile con un meccanismo di beaconing; la prevalenza dell’uplink in assenza di attività dell’utente è coerente con un trasferimento di dati verso l’esterno; la persistenza notturna esclude una correlazione con l’uso applicativo dichiarato. Il confronto con la baseline degli altri dispositivi dell’ambiente mostra che nessuno presenta un profilo analogo. Allo stesso tempo, l’analisi registra le spiegazioni alternative legittime: notifiche push, sincronizzazione cloud, telemetria di sistema o keep-alive di un’applicazione di messaggistica possono produrre pattern simili.

L’ipotesi, esplicitamente condizionale, è che il comportamento osservato risulti tecnicamente compatibile con uno scenario di esfiltrazione remota persistente, qualora le spiegazioni alternative vengano escluse attraverso la correlazione con il dispositivo e la verifica delle applicazioni installate. L’output corretto non è quindi “il dispositivo è intercettato”, ma una valutazione di compatibilità tecnica, argomentata e subordinata all’esclusione delle ipotesi fisiologiche.

Perché l’approccio combinato è necessario

Un modello solo IOC è insufficiente; un modello solo comportamentale rischia un’eccessiva interpretazione. La robustezza metodologica deriva dal confronto tra dato noto e comportamento osservato e dalla distinzione netta tra dato oggettivo, pattern e ipotesi. La bonifica logica moderna richiede analisi passiva, assenza di attribuzione prematura e separazione tra evidenza tecnica e narrativa.

L’intelligenza artificiale come supporto analitico

Nel contesto della bonifica logica moderna, l’analisi di traffico di rete, log di sistema, metadati di comunicazione e osservazioni provenienti da domini differenti può generare una quantità elevata di dati tecnici eterogenei. In tali scenari, strumenti basati su intelligenza artificiale possono rappresentare un supporto utile all’attività dell’analista, soprattutto nelle fasi di normalizzazione, correlazione e prioritizzazione delle anomalie.

L’intelligenza artificiale non deve tuttavia essere intesa come sostituzione dell’operatore, né come meccanismo decisionale autonomo. Nel metodo SPECTRA, il suo ruolo è quello di intelligenza aumentata: un sistema di supporto capace di assistere l’analista nell’individuazione di pattern ricorrenti, nella comparazione tra eventi tecnici e nell’evidenziazione di comportamenti che meritano approfondimento.

In ambito TSCM logico, l’intelligenza artificiale può essere utile in particolare per aggregare grandi volumi di dati provenienti da PCAP, log di sistema, eventi RF, traffico Wi-Fi, traffico cellulare e metadati di rete; per individuare ricorrenze temporali non immediatamente evidenti all’osservazione manuale; per evidenziare nodi dominanti, flussi persistenti e comunicazioni ripetitive; per correlare eventi appartenenti a domini diversi (ad esempio attività RF, uplink cellulare e traffico dati); per supportare la costruzione di baseline ambientali o dispositive; e per assegnare priorità agli elementi da verificare, riducendo il carico cognitivo dell’analista.

Sul piano delle tecniche, questo supporto si traduce in famiglie di metodi già consolidate nell’analisi del traffico e dei log. Algoritmi di anomaly detection (per esempio Isolation Forest o autoencoder) possono segnalare flussi che si discostano da una baseline appresa, evidenziando uplink anomali o connessioni in fasce orarie atipiche.

Tecniche di clustering non supervisionato (per esempio DBSCAN o k-means su feature di flusso quali frequenza, volume, durata e periodicità) consentono di raggruppare comunicazioni con comportamento simile e di isolare i flussi che non rientrano in alcun raggruppamento atteso. Modelli linguistici di grandi dimensioni (LLM) possono assistere nella normalizzazione e nella correlazione di log eterogenei, nella sintesi di sequenze di eventi e nella generazione di ipotesi da sottoporre a verifica. In tutti i casi si tratta di strumenti di supporto alla lettura del dato, non di moduli decisionali autonomi.

Il valore dell’intelligenza artificiale non risiede quindi nella capacità di decidere se un dispositivo sia compromesso, ma nella capacità di rendere più leggibili strutture complesse di dati. Un sistema di analisi può, ad esempio, segnalare che un determinato endpoint compare con frequenza anomala, che un flusso si ripete in assenza di interazione utente, oppure che un’attività di rete coincide temporalmente con eventi radio osservati nello stesso ambiente. Questi output non costituiscono prove autonome: rappresentano indicatori analitici che devono essere interpretati all’interno del contesto operativo.

Per essere realmente utile, l’intelligenza artificiale deve essere integrata in una metodologia strutturata. Un utilizzo generico, non contestualizzato o basato su prompt isolati rischia di produrre risultati apparentemente convincenti ma metodologicamente deboli. In particolare, nel dominio della bonifica tecnica, l’intelligenza artificiale deve operare su dati normalizzati, criteri espliciti e categorie analitiche coerenti con il modello di riferimento: dato, pattern, ipotesi e valutazione.

Il rischio principale è l’automazione dell’interpretazione. Un’anomalia statistica non equivale a una compromissione; un flusso persistente non equivale automaticamente a un canale di esfiltrazione; un endpoint dominante non è necessariamente un server di comando e controllo. L’intelligenza artificiale può evidenziare correlazioni, ma non può sostituire la valutazione tecnica dell’analista, che deve distinguere tra comportamento fisiologico, anomalia contestuale e scenario compatibile con sorveglianza remota.

Nel metodo SPECTRA l’intelligenza artificiale assume quindi una funzione di supporto su tre livelli. Sul piano descrittivo, organizza i dati osservati, li sintetizza e li rende consultabili in modo più rapido. Sul piano correlativo, evidenzia relazioni temporali o strutturali tra eventi appartenenti a domini differenti. Sul piano prioritario, aiuta l’analista a individuare quali elementi meritano verifica ulteriore. Non assume invece funzione attributiva o conclusiva: non stabilisce l’autore di un’attività, non identifica con certezza una compromissione e non sostituisce la validazione umana.

In questa prospettiva, l’intelligenza artificiale può diventare uno strumento rilevante per la bonifica moderna, ma solo se subordinata a una metodologia rigorosa. Il suo impiego deve rafforzare la separazione tra dato, analisi e ipotesi, non indebolirla. Il processo decisionale resta responsabilità dell’analista umano, che deve valutare gli output alla luce del contesto, delle spiegazioni alternative e dei limiti tecnici dell’osservazione passiva. L’intelligenza artificiale non trasforma la bonifica tecnica in un processo automatico: la rende più scalabile, più ordinata e più efficiente, ma non elimina la necessità di competenza tecnica, interpretazione critica e validazione metodologica.

Bonifica logica nella cybersecurity: limiti degli IOC e importanza dell’approccio combinato

La bonifica logica non può basarsi esclusivamente su liste di indicatori, né su intuizioni comportamentali isolate. Richiede un approccio combinato, strutturato e tecnicamente difendibile. L’analisi IOC individua ciò che è già conosciuto; l’analisi pattern-centrica individua ciò che si comporta in modo anomalo. Solo l’integrazione delle due consente una valutazione coerente nel contesto della sorveglianza contemporanea.

Principi della metodologia di analisi passiva

Questo capitolo definisce l’impianto metodologico alla base dell’analisi tecnica applicata alla bonifica logica dei dispositivi e delle comunicazioni. Non si tratta di una procedura operativa, ma di un modello concettuale strutturato che consente di interpretare correttamente i fenomeni osservabili senza alterare il contesto tecnico analizzato. L’obiettivo non è trovare uno spyware, ma stabilire se il comportamento tecnico di un sistema sia compatibile o incompatibile con scenari di sorveglianza remota.

Analisi passiva del traffico

Il primo principio è la passività assoluta dell’osservazione. L’analisi si fonda sull’acquisizione e l’esame di traffico di rete già generato, metadati di comunicazione, distribuzione protocollare, persistenza dei flussi, frequenza e periodicità delle connessioni. Non viene generato traffico di test, non vengono effettuate interrogazioni forzate, non si inducono risposte dal dispositivo. Questo approccio garantisce integrità forense del contesto, assenza di alterazioni comportamentali e riduzione dei falsi positivi dovuti a stimolazione artificiale. In altre parole, si osserva il sistema mentre si comporta naturalmente.

Nessuna interazione attiva con il dispositivo

L’analisi non prevede installazione di software di scansione invasivi, esecuzione di exploit di verifica, test di penetrazione sul dispositivo oggetto di analisi né interrogazioni dirette verso endpoint sospetti. L’interazione attiva può modificare i log, attivare meccanismi di autodifesa, alterare i pattern di comunicazione e compromettere la validità dell’analisi. Il dispositivo viene trattato come una sorgente di dati, non come un bersaglio da stimolare.

Approccio non attributivo

Un principio fondamentale è la non attribuzione. L’analisi non identifica un autore, non attribuisce responsabilità, non formula accuse e non costruisce narrative investigative. Si limita a rispondere a una domanda tecnica: il comportamento osservato è compatibile con un’architettura di sorveglianza remota? Qualsiasi riferimento a soggetti, organizzazioni o presunti attori rimane fuori dall’ambito metodologico, riducendo bias interpretativi, derive speculative e sovrainterpretazioni.

Priorità ai pattern comportamentali

Il fulcro metodologico è l’analisi dei pattern. Non si parte da un indicatore di compromissione predefinito, ma dall’osservazione di nodi dominanti, flussi persistenti, distribuzione anomala dei protocolli, ricorrenza temporale e volumi incoerenti rispetto all’uso dichiarato. L’analisi è orientata a frequenza, durata, periodicità e topologia delle comunicazioni. Un singolo evento isolato non ha valore diagnostico; un comportamento ripetitivo, strutturato e coerente nel tempo può invece assumere significato tecnico. L’attenzione si concentra sulla coerenza del sistema, non sull’eccezione.

Separazione tra dato, analisi e ipotesi

Il metodo impone una distinzione netta tra tre livelli. Il dato è un elemento osservabile, numerico, verificabile e riproducibile. L’analisi è l’interpretazione tecnica del dato, la correlazione tra più elementi e l’identificazione di pattern. L’ipotesi è un possibile scenario compatibile, sempre condizionale e mai affermato come certezza. Questa separazione evita che l’ipotesi influenzi la lettura del dato, che il sospetto diventi conclusione e che l’interpretazione si trasformi in narrativa. Il dato resta autonomo, l’analisi è dichiarata, l’ipotesi è esplicitamente condizionale.

Coerenza con il paradigma contemporaneo

La sorveglianza moderna non si manifesta necessariamente con segnali evidenti o comportamenti plateali. Può essere silente, intermittente, a basso volume e distribuita su più endpoint. Per questo motivo l’approccio metodologico non è orientato alla firma, ma alla struttura comportamentale del sistema. La domanda centrale non è “c’è uno spyware noto?”, ma “il comportamento complessivo del dispositivo è compatibile con un modello di controllo remoto?”.

Metodologia di analisi passiva: principi fondamentali per la sicurezza informatica moderna

La metodologia di analisi passiva si fonda su cinque principi cardine: osservazione non intrusiva, assenza di stimolazione attiva, neutralità attributiva, centralità dei pattern e separazione rigorosa tra dato e ipotesi. È un modello che privilegia la solidità tecnica rispetto alla spettacolarizzazione del risultato. In un contesto in cui la sorveglianza si è spostata dal perimetro fisico al dispositivo, la qualità dell’analisi dipende dalla disciplina metodologica: non dalla ricerca dell’effetto, ma dalla coerenza del metodo.

Limiti tecnici e ambiguità dell’analisi

Ogni analisi tecnica, sia essa RF, logica o di traffico di rete, opera entro limiti strutturali che devono essere esplicitati con chiarezza. L’obiettivo di una bonifica moderna non è produrre certezze assolute, ma valutare la compatibilità tecnica dei pattern osservati con scenari di sorveglianza.

Traffico cifrato

L’evoluzione delle comunicazioni digitali ha portato a un uso quasi totale della cifratura end-to-end: TLS 1.3, HTTPS obbligatorio, DNS over HTTPS e DNS over TLS, VPN commerciali, protocolli proprietari cifrati. Dal punto di vista forense passivo (PCAP, log di rete, metadata), il contenuto del traffico non è analizzabile, il payload non è interpretabile e l’ispezione profonda (DPI) è spesso inefficace o tecnicamente inappropriata. L’analisi si concentra quindi su pattern di persistenza, frequenza delle connessioni, distribuzione temporale, nodi dominanti e anomalie rispetto alla baseline. Un flusso cifrato verso un endpoint remoto non è di per sé indicativo di attività malevola: è un dato compatibile con molteplici scenari, inclusi quelli pienamente legittimi.

Servizi cloud legittimi

Le infrastrutture cloud moderne (CDN, storage distribuito, push notification, telemetria) rendono complessa l’attribuzione tecnica. Un dispositivo può comunicare costantemente con infrastrutture di aggiornamento sistema, servizi di sincronizzazione, backup automatici, piattaforme di messaggistica e servizi di analytics. Molti captatori informatici, commerciali o statali, utilizzano infrastrutture cloud per mascherare il traffico, ma lo stesso vale per applicazioni legittime. Ne consegue che la presenza di traffico verso IP di grandi provider non è di per sé indicativa, la reputazione dell’IP non è elemento decisivo e l’assenza di blacklist non equivale a innocuità. L’analisi deve quindi basarsi sulla coerenza comportamentale, non sulla mera destinazione.

Falsi positivi

Ogni metodologia orientata ai pattern comporta il rischio di falsi positivi: applicazioni che mantengono socket persistenti per notifiche push, sistemi di backup che generano upload periodici, servizi VoIP con keep-alive frequenti, sincronizzazioni in background dopo inattività. Un pattern di traffico persistente, notturno o ricorrente può essere compatibile sia con un captatore sia con un servizio cloud legittimo. La distinzione richiede correlazione temporale, analisi del contesto operativo, confronto con baseline e validazione su più fonti di dato (rete, sistema, comportamento utente). L’errore metodologico più grave è interpretare un’anomalia come prova.

Impossibilità di certezza assoluta

In ambito tecnico-forense passivo non si dispone sempre del controllo dell’infrastruttura, delle chiavi di cifratura, dell’accesso ai server remoti né dei log lato controparte. L’analisi può quindi stabilire la compatibilità tecnica con uno scenario di sorveglianza, l’incompatibilità tecnica con determinate ipotesi e la probabilità relativa di determinati comportamenti, ma non può, nella maggior parte dei casi, stabilire con certezza assoluta l’identità dell’operatore remoto, la finalità esatta della comunicazione o la presenza di un captatore specifico in assenza di artefatti diretti.

L’analisi tecnica moderna non produce verità assolute, ma valutazioni strutturate, classificazione dei pattern, analisi di coerenza e scenari compatibili. L’output corretto non è “il dispositivo è intercettato”, ma “i pattern osservati risultano tecnicamente compatibili con uno scenario di esfiltrazione remota persistente, in assenza di spiegazioni alternative coerenti”. Questa distinzione non è debolezza metodologica: è rigore scientifico.

La bonifica logica e l’analisi di traffico devono essere presentate per ciò che sono: strumenti probabilistici ad alta competenza tecnica, non strumenti di certezza assoluta. La credibilità di un’analisi non deriva dall’enfasi conclusiva, ma dalla chiarezza con cui vengono dichiarati i suoi limiti. L’analisi individua compatibilità tecniche, non prove definitive.

Implicazioni per la bonifica moderna

Il percorso tecnico sviluppato nei capitoli precedenti conduce a una conclusione chiara: la bonifica moderna non può più essere intesa come una semplice attività di scansione radio o ispezione manuale, ma come un processo analitico integrato, multidimensionale e continuativo. Le tecniche di rilevazione radio rimangono fondamentali, così come l’ispezione manuale dell’ambiente e la verifica fisica delle infrastrutture; tuttavia, l’evoluzione delle tecnologie di sorveglianza ha progressivamente ampliato il dominio della minaccia, che oggi può manifestarsi anche a livello software, di rete o di comportamento dei dispositivi. La bonifica tecnica moderna richiede quindi un approccio metodologico capace di integrare analisi provenienti da domini differenti: spettro radio, infrastrutture di rete e sistemi digitali.

Integrazione tra analisi RF e analisi logica

La bonifica RF tradizionale rimane uno strumento fondamentale. L’analisi dello spettro consente di individuare trasmettitori attivi in ambiente, rilevare segnali anomali per potenza, persistenza o modulazione, identificare uplink sospetti su bande note e analizzare comportamenti radio incompatibili con la semplice ricezione passiva. Accanto all’analisi RF deve essere sempre affiancata l’ispezione manuale dell’ambiente: la verifica fisica degli spazi, degli oggetti e delle infrastrutture rimane una componente essenziale delle attività TSCM, consentendo di individuare dispositivi elettronici occultati anche in assenza di emissioni radio attive.

L’evoluzione delle minacce ha però spostato una parte significativa del rischio dal dominio ambientale al dominio digitale. Oggi la sorveglianza può manifestarsi attraverso dispositivi mobili compromessi, software di controllo remoto, configurazioni improprie di rete, flussi dati anomali ma apparentemente legittimi e pattern di comunicazione compatibili con esfiltrazione silente. Di conseguenza, la bonifica moderna deve integrare analisi RF ambientale, analisi di rete locale, analisi logica dei dispositivi e correlazione tra livelli fisico e digitale. La separazione netta tra bonifica ambientale e bonifica informatica non è più coerente con lo scenario operativo attuale.

Evoluzione delle minacce: dall’emissione alla mimetizzazione

Le microspie analogiche classiche erano relativamente semplici da individuare: trasmissione continua, modulazione riconoscibile, comportamento stabile. Le minacce moderne si caratterizzano invece per trasmissioni intermittenti, uso di infrastrutture esistenti (rete cellulare, Wi-Fi), cifratura dei contenuti, attivazione condizionata (trigger remoto) e integrazione in dispositivi apparentemente legittimi. Il paradigma non è più semplicemente cercare una frequenza, ma interpretare un comportamento.

Un segnale su una banda nota non è automaticamente innocuo, così come un flusso dati cifrato non è automaticamente malevolo. La distinzione avviene attraverso l’analisi del contesto: potenza rispetto all’ambiente, persistenza nel tempo, coerenza con l’uso dichiarato dello spazio, correlazione con eventi o presenze, distribuzione temporale delle attività. La minaccia moderna tende alla mimetizzazione, e la bonifica deve quindi evolversi verso l’interpretazione dei comportamenti tecnici.

Il ruolo dell’analisi comportamentale

Il passaggio concettuale più rilevante riguarda l’introduzione dell’analisi comportamentale. Non si tratta di attribuire intenzioni, ma di osservare pattern oggettivi: flussi dati ricorrenti in determinate fasce orarie, attivazioni RF non coerenti con l’uso dell’ambiente, uplink persistenti senza traffico visibile, dispositivi che mantengono comunicazioni costanti anche in stato di apparente inattività. L’analisi comportamentale non sostituisce la tecnica, ma la completa, e richiede raccolta strutturata dei dati, comparazione temporale, definizione di baseline ambientali e capacità di distinguere traffico infrastrutturale da trasmissione locale. In questo modello la bonifica diventa un processo ciclico: acquisizione, classificazione, correlazione, interpretazione, validazione. Il risultato non è un semplice “assenza di segnali”, ma una valutazione tecnica argomentata del rischio.

Il metodo SPECTRA: formalizzazione della metodologia multidominio

Posizionamento rispetto allo stato dell’arte

Le attività di Technical Surveillance Countermeasures (TSCM) sono da tempo descritte in letteratura tecnica e in ambito istituzionale attraverso linee guida operative consolidate. Documenti riconducibili a contesti governativi, come quelli sviluppati in ambito National Security Agency e Dipartimento della Difesa statunitense, definiscono in modo strutturato le procedure di bonifica ambientale, con particolare enfasi sull’analisi radioelettrica, sull’ispezione fisica e sulla rilevazione di dispositivi elettronici.

Parallelamente, negli ultimi anni si sono sviluppate metodologie tecniche avanzate orientate all’analisi dei dispositivi e dei captatori informatici: in questo ambito, i lavori di Amnesty International Security Lab e Citizen Lab hanno introdotto approcci forensi e di network analysis basati su indicatori tecnici, analisi dei log e correlazione delle infrastrutture di comunicazione, contribuendo in modo significativo alla comprensione delle moderne tecnologie di sorveglianza software.

Nonostante l’elevato livello tecnico, questi approcci risultano generalmente strutturati per dominio: le metodologie TSCM tradizionali operano prevalentemente sul piano fisico e radio, mentre le metodologie forensi moderne si concentrano sul dispositivo e sul traffico di rete. Il metodo SPECTRA si inserisce in questo contesto come formalizzazione di un approccio integrato.

Non introduce nuove tecniche di rilevazione, ma organizza in modo esplicito un modello analitico multidominio in cui analisi ambientale e radioelettrica, ispezione fisica, analisi dei dispositivi e osservazione del traffico di rete vengono trattate come componenti interdipendenti di un unico processo. L’elemento distintivo del metodo non è quindi lo strumento utilizzato, ma la logica di integrazione: il valore analitico non è attribuito alla singola evidenza, ma alla correlazione tra evidenze eterogenee osservate nel tempo.

La differenza metodologica è netta. Nei framework tradizionali il dato viene analizzato principalmente all’interno del proprio dominio di origine; nel metodo SPECTRA il dato assume significato solo attraverso la relazione con altri domini e la sua evoluzione temporale. Questo comporta due elementi metodologici espliciti: il pattern multidominio come unità minima di analisi e la correlazione temporale come criterio interpretativo. In questo senso, SPECTRA non rappresenta un rebranding di pratiche esistenti, ma la formalizzazione di un modello analitico che integra in modo strutturato domini tecnici tradizionalmente trattati separatamente.

Il confronto sintetico con i principali riferimenti dello stato dell’arte chiarisce il contributo specifico del metodo.

Va inoltre osservato che la stessa metodologia forense di Amnesty riconosce esplicitamente un principio coerente con l’impianto di questo lavoro: la mancata corrispondenza con indicatori pubblici noti non conferma l’assenza di compromissione, ma indica soltanto che non sono stati trovati riscontri con indicatori già catalogati. È la stessa logica che, al capitolo 7, motiva il superamento di un approccio basato esclusivamente su IOC.

Definizione estesa

SPECTRA (Security Pattern Environment Correlation Technical Reconnaissance & Analysis) è una metodologia multidominio per attività di Technical Surveillance Countermeasures (TSCM) basata sull’integrazione coordinata di tecniche eterogenee e sulla correlazione di pattern tecnici nel tempo. Il metodo non introduce una singola tecnica, ma formalizza un sistema integrato di analisi in cui ogni componente contribuisce alla riduzione del rischio di sorveglianza tecnica.

Principio cardine

Nessuna tecnica, isolatamente, è sufficiente a garantire una bonifica efficace. La sicurezza deriva esclusivamente da integrazione, correlazione e continuità temporale. La mancanza di uno di questi elementi introduce inevitabilmente zone cieche analitiche.

Architettura del metodo

SPECTRA è composto da sei componenti operative, da applicare congiuntamente.

1. Analisi ambientale fisica: ispezione strutturale, verifica di accessi e punti sensibili, individuazione di modifiche o anomalie.
2. Analisi spettro RF: scansione wideband e mirata, identificazione di segnali persistenti e burst, valutazione della potenza rispetto al contesto.
3. Rilevazione elettronica (giunzioni non lineari): individuazione di circuiti attivi/passivi, rilevamento di dispositivi spenti o non trasmittenti, attività conforme alle tecniche TSCM tradizionali.
4. Analisi dispositivi autorizzati: smartphone, PC, IoT; verifica logica e comportamentale; analisi del traffico dati e delle attività anomale; individuazione di compatibilità con captatori informatici.
5. Gestione dispositivi non bonificabili: dispositivi esterni (ospiti, fornitori, terzi) per i quali è impossibile una verifica tecnica diretta; misure di isolamento controllato, esclusione dall’ambiente sensibile e messa in sicurezza attiva (per esempio saturazione acustica dei microfoni).
6. Monitoraggio temporale: osservazione a breve, medio e lungo termine; correlazione degli eventi nel tempo; identificazione di pattern ricorrenti.

Figura 1. Schema concettuale del metodo SPECTRA. Il metodo integra domini tecnici differenti (ambiente fisico, spettro RF, rilevazione elettronica, dispositivi, gestione del rischio residuo e osservazione temporale) all’interno di un processo di correlazione multidominio e analisi pattern-centrica finalizzato alla valutazione tecnica del rischio di sorveglianza.

Logica unificante

Il metodo si basa su un principio operativo preciso: il valore analitico non è nella singola rilevazione, ma nella correlazione tra domini e nel tempo. Per esempio: RF più traffico dati indica una possibile attività di esfiltrazione; dispositivo più comportamento anomalo indica una possibile compromissione; segnale più persistenza indica una possibile sorgente locale.

Approccio pattern-centrico

SPECTRA introduce un cambio di paradigma. Non si cerca il singolo dispositivo, la singola frequenza o l’indicatore statico, ma si analizzano pattern tecnici, coerenza con il contesto e anomalie multidominio. Il pattern rappresenta l’unità minima di significato analitico nel metodo.

Dimensione temporale

Il metodo opera su tre scale: breve termine (rilevazioni immediate), medio termine (comportamento nel tempo) e lungo termine (persistenza e ricorrenza).

Gestione del rischio residuo

Elemento fondamentale del metodo: ciò che non è verificabile deve essere controllato. Questo riguarda in particolare i dispositivi non autorizzati, i dispositivi non analizzabili e gli ambienti non completamente isolabili. La soluzione è il contenimento del rischio, la riduzione della capacità di acquisizione (audio/dati) e il controllo delle condizioni operative. L’assenza di rilevazioni non equivale all’assenza di capacità di acquisizione.

Distinzione metodologica rispetto alla TSCM tradizionale

SPECTRA non sostituisce la TSCM: la include, la estende e la integra. Supera il limite di una visione orientata solo all’RF, solo al piano fisico o solo al dispositivo, introducendo correlazione strutturata, analisi comportamentale e integrazione multidominio.

Limite delle tecniche isolate

Il metodo formalizza un punto chiave: la bonifica RF da sola è insufficiente, così come lo sono l’analisi dei dispositivi da sola, l’isolamento dei dispositivi da solo e il monitoraggio RF continuativo da solo. La sicurezza emerge solo dalla combinazione delle tecniche. La sicurezza non è funzione della tecnica utilizzata, ma del grado di integrazione tra tecniche.

Output del metodo

SPECTRA non produce certezza assoluta, ma una valutazione tecnica strutturata basata su anomalie rilevate, pattern identificati e coerenza con il contesto. Il risultato è sempre espresso in termini probabilistici e contestuali, non deterministici.

Formalizzazione dell’acronimo

• S, Security: finalità di protezione dalla sorveglianza tecnica.
• P, Pattern: analisi basata su pattern tecnici, non su eventi isolati.
• E, Environment: ambiente fisico come dominio operativo.
• C, Correlation: correlazione multidominio e temporale.
• T, Technical: approccio tecnico, non teorico.
• R, Reconnaissance: ricognizione sistematica dell’ambiente.
• A, Analysis: analisi strutturata dei dati raccolti.

Definizione conclusiva

SPECTRA è una metodologia multidominio che integra tecniche di analisi ambientale, RF, elettronica, dispositiva e comportamentale, basata sulla correlazione di pattern nel tempo, finalizzata all’identificazione di anomalie tecniche compatibili con attività di sorveglianza o acquisizione non autorizzata di informazioni.

Contesto operativo e livelli di minaccia

Le attività di sorveglianza tecnica possono manifestarsi su livelli profondamente differenti in termini di capacità, risorse e obiettivi. In via generale è possibile distinguere lo spionaggio statale (elevata capacità tecnica, accesso a risorse avanzate come exploit zero-day e infrastrutture dedicate), lo spionaggio privato professionale (investigatori, aziende, competitor), lo spionaggio mirato a basso/medio livello (strumenti commerciali avanzati), lo spionaggio amatoriale/opportunistico (dispositivi a basso costo, software facilmente accessibile) e la sorveglianza in ambito personale (partner, familiari, soggetti interni). Il fattore discriminante tra questi scenari è rappresentato principalmente da budget operativo, livello tecnico dell’attore e obiettivi della sorveglianza.

Nel contesto operativo TSCM/SPECTRA, tali differenze non modificano il principio metodologico fondamentale. L’analisi del contesto orienta la valutazione del rischio, ma non riduce il perimetro della bonifica.

Durante la fase preliminare vengono raccolte informazioni sul contesto, stimato lo scenario di minaccia e definito il livello di rischio; in fase operativa, però, la bonifica deve comunque essere completa e multidominio. Una microspia da 50 euro e un sistema avanzato condividono lo stesso spazio operativo, un captatore software e un trasmettitore RF possono coesistere, e una minaccia apparentemente semplice può produrre effetti critici. Di conseguenza, il metodo SPECTRA prescinde dal livello dell’attaccante nella fase di verifica tecnica: il contesto serve a interpretare i risultati, a pesare le anomalie e a formulare ipotesi, ma non giustifica mai una riduzione dell’analisi.

Conclusioni

L’evoluzione della sorveglianza tecnica ha determinato uno spostamento strutturale del punto di acquisizione delle informazioni: dall’ambiente fisico al dispositivo personale, e dall’hardware dedicato al software residente. Questo cambiamento non è esclusivamente tecnologico, ma profondamente metodologico. Le tecniche di bonifica tradizionali, basate su analisi radioelettrica, ispezione fisica e rilevazione elettronica, rimangono strumenti fondamentali, ma non sono più sufficienti a descrivere l’intero dominio della minaccia.

Nel contesto contemporaneo la sorveglianza può manifestarsi attraverso dispositivi legittimi compromessi, traffico di rete cifrato, pattern comportamentali distribuiti nel tempo e infrastrutture apparentemente indistinguibili da quelle ordinarie. Di conseguenza, la bonifica tecnica non può più essere intesa come una singola attività, ma come un processo analitico multidominio. Il metodo SPECTRA si inserisce in questo contesto come formalizzazione di tale approccio, integrando analisi ambientale, analisi RF, rilevazione elettronica, analisi dei dispositivi, osservazione del traffico e correlazione comportamentale all’interno di un unico modello metodologico coerente.

Il contributo principale del metodo non consiste nell’introduzione di nuove tecnologie, ma nella definizione di un principio operativo chiaro: la sicurezza non è il risultato di una tecnica, ma dell’integrazione strutturata di più domini analitici. In questo paradigma il dato isolato perde significato, il pattern diventa unità analitica, il tempo diventa variabile critica e la certezza lascia spazio alla valutazione probabilistica. La bonifica tecnica moderna non consiste quindi nel trovare una microspia, ma nel determinare se un sistema tecnico, nel suo complesso, presenti comportamenti compatibili con scenari di sorveglianza. Questo passaggio rappresenta il vero punto di discontinuità rispetto ai modelli tradizionali e definisce il perimetro operativo della contro-sorveglianza tecnica contemporanea.

Il presente lavoro si basa principalmente su esperienza tecnica operativa e sull’analisi di casi documentati nella letteratura tecnica e giornalistica internazionale relativi all’utilizzo di captatori informatici e spyware commerciali.

Il lavoro mette in luce un cambiamento strutturale: la sorveglianza non è più un elemento esterno, riconoscibile tramite segnali dedicati, ma una funzione integrata nei sistemi digitali. Oggi il software può operare direttamente all’interno del sistema operativo dello smartphone, acquisendo dati alla sorgente e rendendo spesso invisibile il tradizionale punto di intercettazione.

Di conseguenza, anche la contro-sorveglianza deve adattare il proprio paradigma: le tecniche classiche restano fondamentali, ma non sono più sufficienti a descrivere un contesto in cui traffico cifrato e processi interni si sovrappongono al comportamento ordinario del dispositivo.

Il Metodo SPECTRA nasce in questo scenario, proponendo un approccio che non si basa solo su segnali e indicatori noti, ma sulla lettura dei pattern e delle dinamiche comportamentali nel tempo.

https://www.ictsecuritymagazine.com/articoli/ioc-bonifica-logica/

Il Cryptographic Bill of Materials (CBOM) risponde a una domanda che quasi ogni organizzazione, di fronte alla migrazione post-quantum, scopre di non saper trasformare in un elenco: dove, e con quali algoritmi, chiavi e certificati, l’azienda usa la crittografia. Sembra una domanda banale, e invece è insidiosa, perché la crittografia non vive in un posto solo. È incorporata nelle applicazioni, nelle librerie di terze parti, nei protocolli negoziati a runtime, nei certificati che scadono in silenzio, nell’hardware. Nessuno l’ha mai censita davvero, perché finora non è servito. Ora serve, e serve in fretta.

La ragione è la transizione verso una crittografia resistente ai computer quantistici, spinta da scadenze ormai fissate e dalla minaccia del “raccogli ora, decifra dopo”, che rende urgente proteggere già oggi i segreti destinati a durare a lungo. Ma prima di sostituire un algoritmo bisogna sapere di averlo. Il CBOM è lo strumento standardizzato che trasforma questa consapevolezza da esercizio manuale a inventario ripetibile, ed è la prima mossa concreta di una migrazione che, senza di esso, procederebbe alla cieca.

Che cos’è un Cryptographic Bill of Materials

Un Cryptographic Bill of Materials è l’inventario strutturato e leggibile dalle macchine degli asset crittografici di un sistema: gli algoritmi, le chiavi, i certificati e i protocolli, insieme alle relazioni che li legano ai componenti software che li usano. È l’estensione, al mondo della crittografia, di un’idea già familiare: quella del Software Bill of Materials. Come l’SBOM elenca le componenti di cui un software è fatto, il CBOM elenca la crittografia che quel software impiega, e dove la impiega. La differenza è che qui le dipendenze non sono librerie ma primitive crittografiche, ed è proprio la loro invisibilità a rendere l’inventario necessario.

Lo standard di riferimento è nato in ambito aperto. Il formato CBOM è stato introdotto in CycloneDX, il progetto di OWASP per le distinte dei materiali, con la versione 1.6 dell’aprile 2024, su un contributo iniziale di IBM Research, ed è stato poi standardizzato come ECMA-424. Non si è fermato lì: la versione 1.7, rilasciata nell’ottobre 2025 e ratificata come ECMA-424 di seconda edizione a dicembre 2025, ne ha ampliato le capacità, aggiungendo un elenco standardizzato delle famiglie di algoritmi e una lista completa delle curve ellittiche, utili anche fuori da CycloneDX per le verifiche di conformità e di prontezza al post-quantum. Non è quindi un formato proprietario legato a un fornitore, ma una grammatica comune con cui descrivere la postura crittografica di un’organizzazione, generarla con strumenti di scoperta automatica e scambiarla come si scambia già un SBOM.

Perché l’inventario viene prima della migrazione

Gli standard post-quantum, almeno i principali, ci sono: nell’agosto 2024 il NIST ha finalizzato i primi tre algoritmi resistenti al calcolo quantistico (FIPS 203, 204 e 205). E “primi” è la parola esatta, perché il quadro non è ancora completo: un ulteriore algoritmo, HQC, è stato selezionato nel marzo 2025, e la firma FN-DSA (FIPS 206) è tuttora in lavorazione. Le agenzie, intanto, hanno iniziato a fissare le date entro cui abbandonare gli algoritmi vulnerabili. Il problema, insomma, non è più quale crittografia adottare, ma dove va applicata, ed è qui che casca l’asino: la maggior parte delle organizzazioni non possiede una mappa di dove e come usa la crittografia. È un sapere sparso tra team diversi, sepolto in codice scritto anni prima, delegato a componenti che nessuno controlla riga per riga.

Non a caso le stesse autorità mettono l’inventario al primo posto. Il documento congiunto di CISA, NSA e NIST, dell’agosto 2023, indica come passo iniziale proprio la costruzione di un inventario crittografico: sapere quali algoritmi sono in uso, in quali sistemi, a protezione di quali dati. È l’applicazione di un principio tanto semplice quanto trascurato, cioè che non si può migrare ciò che non si vede. Senza quella mappa, ogni piano di transizione resta una stima, e ogni scadenza un salto nel buio.

Da allora le autorità hanno alzato la posta, e il CBOM è passato dalle raccomandazioni a un atto di governo. Con l’ordine esecutivo di giugno 2026 sulla sicurezza crittografica (Executive Order 14412), la Casa Bianca ha incaricato il Dipartimento della Sicurezza interna, tramite la CISA e in coordinamento con il NIST, di pubblicare entro 270 giorni, quindi verso il 19 marzo 2027, una guida sugli elementi minimi di un cryptographic bill of materials capace di abilitare la valutazione automatizzata degli asset crittografici di un componente hardware o software. È la prima volta che una direttiva federale nomina il CBOM come artefatto definito: il segnale che l’inventario non è più una buona pratica suggerita, ma la base su cui si costruirà la conformità.

Non solo Stati Uniti: la spinta arriva anche dall’Europa

Il baricentro del dibattito è statunitense, ma la stessa direzione si legge in Europa, ed è la parte che riguarda più da vicino chi lavora in Italia. La Coordinated Implementation Roadmap del Gruppo di Cooperazione NIS, del giugno 2025, chiede agli Stati membri di avviare la transizione entro la fine del 2026, di completare la migrazione delle infrastrutture critiche non oltre il 2030 e di estenderla ai sistemi restanti, per quanto praticabile, entro il 2035. La spinta potrebbe poi irrigidirsi in obbligo: la proposta COM(2026) 13, presentata dalla Commissione nel gennaio 2026 nell’ambito di un pacchetto di semplificazione della direttiva NIS2 e di allineamento al Cybersecurity Act, se approvata da Parlamento e Consiglio scriverebbe la crittografia post-quantum direttamente nel testo della direttiva, trasformando la pianificazione da interpretazione della clausola sullo “stato dell’arte” a requisito esplicito.

Per l’Italia la scadenza di fine 2026 è vicina, e il segnale nazionale è già arrivato: l’11 giugno 2026 l’Agenzia per la Cybersicurezza Nazionale ha pubblicato due nuovi documenti sulle funzioni crittografiche, dedicati ai cifrari a flusso e alle firme digitali, e ha aggiornato alla versione 2.0 la guida sul TLS, integrandovi le soluzioni post-quantum. Il messaggio, su entrambe le sponde dell’Atlantico, converge: la migrazione ha una data, e una data trasforma l’inventario da progetto rimandabile a compito immediato.

Dal CBOM alla crypto-agility

L’inventario, di per sé, non protegge nulla: è il presupposto di ciò che viene dopo. Con una fotografia accurata della crittografia in uso, un’organizzazione può fare ciò che senza quella mappa resta un’ipotesi. Può individuare gli algoritmi vulnerabili al quantum e distinguerli da quelli ancora solidi; può stabilire una priorità, mettendo in cima ciò che protegge segreti destinati a durare anni; può scovare la crittografia debole o scaduta che si annida ovunque, non solo quella da rimpiazzare in vista del post-quantum.

È qui che il CBOM incontra la crypto-agility, cioè la capacità di cambiare algoritmo senza riscrivere l’applicazione da capo. Se la crypto-agility è l’obiettivo, il CBOM è la mappa che lo rende raggiungibile: non si può sostituire in modo ordinato ciò di cui si ignora la collocazione. Un inventario tenuto aggiornato trasforma una migrazione monolitica e rischiosa in una serie di interventi mirati e verificabili, e permette di dimostrare a un revisore, dati alla mano, a che punto sia la transizione. La stessa logica vale per la migrazione post-quantum nel suo complesso, che diventa gestibile solo quando poggia su un inventario reale anziché su una supposizione.

I limiti: un inventario non è una migrazione

Sarebbe però un errore trattare il CBOM come una soluzione anziché come un punto di partenza. La scoperta della crittografia è tecnicamente difficile: gli algoritmi si nascondono nei binari, nell’hardware, nelle componenti di terze parti e nei protocolli decisi solo al momento della connessione, e nessuno strumento li individua tutti con certezza. Un CBOM, inoltre, è una fotografia, e come ogni fotografia invecchia: senza un processo che lo mantenga aggiornato si trasforma in fretta nel ritratto di un sistema che non esiste più. Gli strumenti di generazione stanno maturando, ma non sono ancora chiavi in mano, e la parte più insidiosa resta la crittografia che non lascia tracce facili da leggere.

Proprio per questo l’inventario non va inteso come una precondizione da esaurire prima di muoversi. Commentando l’ordine esecutivo, Cloudflare ha messo in guardia dal trasformare il CBOM esaustivo in un prerequisito paralizzante: catalogare ogni algoritmo in ogni libreria richiede molto tempo, e il rischio è che l’inventario risulti già superato nel momento in cui viene completato. La lezione è pratica: conviene procedere in parallelo, cominciando a migrare i sistemi più esposti mentre l’inventario si affina, invece di attendere una mappa perfetta che forse non arriverà mai.

Va poi ricordato che l’inventario, da solo, non corregge nulla. Elencare gli algoritmi deboli non li sostituisce, e produrre un CBOM solo per spuntare una casella di conformità, senza usarlo per pianificare e verificare, è un costo senza ritorno. La via realistica è duplice: automatizzare la scoperta il più possibile e integrarla nei processi, così che l’inventario si aggiorni da sé, e trattare il CBOM come uno strumento di lavoro continuo, non come un allegato prodotto una volta e poi dimenticato.

Cosa aspettarsi, senza illusioni

La migrazione post-quantum sarà la più grande transizione crittografica degli ultimi decenni, e il Cryptographic Bill of Materials ne è la parte meno vistosa e più decisiva, quella da cui dipende tutto il resto. Il ritorno concreto non è un documento in più, ma la capacità di rispondere con i dati a domande che oggi ricevono solo stime: quali sistemi usano crittografia vulnerabile, dove, e con quale priorità intervenire. L’orologio del “raccogli ora, decifra dopo” ha già iniziato a scorrere per i dati che devono restare riservati a lungo, e partire dall’inventario è il primo passo verso una postura crittografica difendibile. Chi tratta il CBOM come un adempimento otterrà un file inutile; chi lo tratta come la mappa su cui costruire la propria crypto-agility otterrà il controllo di una transizione che, altrimenti, subirà alla scadenza.

https://www.ictsecuritymagazine.com/articoli/cryptographic-bill-of-materials-cbom/

Il quishing, cioè il phishing veicolato da un QR code, ha smesso di essere una curiosità e nel 2026 è diventato, nella telemetria di Microsoft, il vettore email in più rapida crescita. Non è un dettaglio di forma, un phishing con un’immagine al posto di un link: è un attacco costruito apposta per aggirare i controlli che difendono la posta aziendale e per portare la vittima là dove quei controlli non arrivano. I numeri lo confermano. Il rapporto Microsoft sulle minacce email del primo trimestre 2026 registra un balzo del phishing via QR da 7,6 a 18,7 milioni di attacchi tra gennaio e marzo, più 146%, il volume mensile più alto da almeno un anno, su circa 8,3 miliardi di minacce di phishing via email rilevate nel trimestre. ESET, nel suo Threat Report del primo semestre 2026 (dicembre 2025-maggio 2026), rileva che ormai l’11% delle email di phishing contiene un QR code, con una media di centomila rilevamenti al mese: è un livello record, sia pure su una serie storica breve, dato che ESET lo traccia come categoria distinta solo da settembre 2025. Per il lettore italiano conta la geografia dei bersagli: in testa Stati Uniti (19%) e Spagna (17%), seguiti da Messico (6%) e Regno Unito (5%), con l’Italia al 3% insieme a Cechia, Canada e Polonia; il fenomeno non risparmia il nostro Paese.

La ragione di questa crescita non è la novità della tecnica, che esiste da anni, ma la sua efficacia contro le difese attuali. Il QR sposta l’attacco in un punto cieco, e lo fa sfruttando due debolezze insieme: una tecnica, nei gateway di posta, e una umana, nella fiducia quasi automatica che le persone ripongono in un quadratino da inquadrare. Una precisazione di perimetro, prima di procedere: qui si parla del quishing via email, ma lo stesso inganno vive anche nel mondo fisico, con QR fraudolenti su parcometri, bike sharing e finti avvisi di multa o di pedaggio. A Pesaro, nel maggio 2026, la società dei parcheggi controllata dal Comune ha denunciato la comparsa di QR fraudolenti su alcuni parcometri cittadini, che rimandavano a pagine non autorizzate dove veniva chiesto l’inserimento dei dati della carta: cambia il canale, non il meccanismo. Capire perché funziona è la premessa per difendersi in modo diverso dal solito richiamo a “non fidarsi delle email”.

Perché il quishing, o QR code phishing, scavalca i controlli dell’email

I filtri di sicurezza della posta sono costruiti per analizzare testo e link: seguono gli URL, ne valutano la reputazione, riscrivono i collegamenti, confrontano il contenuto con schemi noti di truffa. Un QR code, per quei filtri, è un’immagine, e l’indirizzo che nasconde non è leggibile come testo. Il collegamento malevolo viaggia dentro un disegno che il gateway, se non è attrezzato a decodificarlo, non ispeziona. È lo scarto che rende il quishing efficace: non c’è un link da bloccare, c’è una figura che supera i controlli perché quei controlli guardano altrove.

Gli attaccanti hanno affinato anche la consegna. Il canale dominante resta l’allegato PDF, che anzi cresce dal 65% delle campagne QR di gennaio al 70% di marzo, mentre i documenti Office scendono dal 31% al 24%. Accanto a questo, nel marzo 2026 Microsoft ha osservato un aumento del 336% dei QR piazzati direttamente nel corpo dell’email: un volume ancora minoritario, il 5% del totale, ma un segnale di sperimentazione. È la conferma che la tecnica non solo cresce, ma cerca di continuo la superficie che i sistemi testuali non sanno leggere.

Il salto sul telefono, fuori dal perimetro

C’è un secondo motivo, più insidioso del primo, ed è dove finisce la vittima. Un QR non si clicca dalla postazione di lavoro, si inquadra con il telefono. Nel momento in cui il dipendente prende lo smartphone per scansionare il codice, esce dall’ambiente protetto del computer aziendale ed entra su un dispositivo che le difese dell’organizzazione, di norma, non presidiano. Se poi il telefono è personale, come accade nella maggior parte dei casi, l’attacco si completa interamente fuori dal perimetro gestito, lontano dall’endpoint detection e dai proxy che filtrano il traffico dei portatili.

È un trasferimento di terreno prima ancora che di vittima: l’attacco parte in un canale sorvegliato, la posta, e si conclude in uno che quasi nessuno sorveglia, il browser di un telefono privato. A questo si aggiunge la fiducia implicita nel formato. Un URL sospetto mette in guardia, un QR no, perché è illeggibile all’occhio umano e associato a usi quotidiani e legittimi, dal menu del ristorante al pagamento. La vittima non vede l’indirizzo verso cui sta andando finché non ci è già arrivata, spesso su uno schermo piccolo dove i segnali d’allarme di un sito falso sono più difficili da cogliere.

Dove porta davvero: non un’immagine, una catena

Sarebbe un errore fermarsi al QR come se fosse l’attacco. Il codice è solo la consegna; la pagina di destinazione è quasi sempre una trappola per le credenziali, e nelle campagne più evolute non un semplice sito clone ma una pagina adversary-in-the-middle che si frappone tra la vittima e il servizio reale. Una pagina di questo tipo non ruba solo la password, ma intercetta anche il codice del secondo fattore e il token di sessione, così l’attaccante entra come se avesse superato l’autenticazione forte. È la ragione per cui il quishing non va derubricato a truffa da utente distratto: è l’anello iniziale di una catena che può arrivare a un account takeover completo. Che non sia roba da dilettanti lo conferma chi lo usa: a gennaio 2026 l’FBI ha diffuso un’allerta sui QR malevoli impiegati nello spearphishing del gruppo nordcoreano Kimsuky contro obiettivi statunitensi, descrivendo attacchi che si chiudono con il furto e il riuso del token di sessione, così da scavalcare l’MFA senza generare un allarme di “autenticazione fallita”. E le pagine AiTM a valle non sono artigianali, ma servite da kit di phishing-as-a-service: un ecosistema in continuo rimescolamento: Tycoon 2FA è stato smantellato a inizio marzo 2026, ma un kit rivale come Starkiller era già documentato due settimane prima del takedown.

Letto così, il vettore QR e il furto di sessione non sono due problemi distinti, ma lo stesso attacco visto da due estremi. Il QR serve a far attraversare indenne la posta e a spostare la vittima su un dispositivo scoperto; la pagina AiTM, all’altro capo, monetizza quel varco rubando l’accesso. Difendere solo un estremo lascia l’altro aperto.

Come difendersi: l’awareness non basta, serve struttura

La prima reazione, formare le persone a diffidare dei QR, è utile ma insufficiente, e per un motivo strutturale: il QR è nato per essere inquadrato senza pensarci, e un livello di sospetto abbastanza alto da bloccarlo bloccherebbe anche gli usi legittimi. La security awareness resta un tassello, ma va affiancata a controlli che non dipendono dall’attenzione del singolo. Sul piano della posta significa dotare i gateway della capacità di decodificare i QR nelle immagini e di analizzare la destinazione prima della consegna, invece di trattarli come figure innocue. Sul piano del dispositivo significa estendere la protezione ai telefoni che accedono alle risorse aziendali, perché è lì che l’attacco si consuma.

Ma la difesa che chiude davvero la catena agisce all’ultimo anello, l’autenticazione. Se l’accesso è protetto solo da fattori resistenti al phishing, come le passkey basate su FIDO2, senza fallback su OTP o SMS, la pagina AiTM a cui il QR conduce non ha nulla da rubare: non esiste un codice da intercettare né un token riutilizzabile, perché la credenziale è legata al dominio legittimo e non funziona altrove. È lo spostamento decisivo, dal cercare di impedire alla vittima di arrivare sulla pagina falsa al rendere inutile il fatto che ci arrivi. Le altre misure riducono la probabilità dell’attacco; questa ne annulla il guadagno.

Cosa aspettarsi, senza illusioni

Il quishing non è una moda passeggera ma un vettore destinato a restare, perché sfrutta un divario reale e duraturo: quello tra la posta aziendale, sorvegliata, e il telefono personale, che non lo è. Finché l’attacco potrà partire in un canale controllato e concludersi in uno scoperto, il QR resterà uno strumento comodo per gli aggressori, e i numeri del 2026 lo dicono già con chiarezza. La risposta efficace non è un cartello che invita a non inquadrare i codici, ma una difesa a strati che unisce l’ispezione dei QR nella posta, la protezione dei dispositivi mobili e, soprattutto, un’autenticazione che regge anche quando la vittima finisce sulla pagina sbagliata. Trattare il quishing come una questione di distrazione individuale è il modo più sicuro per continuare a subirlo; trattarlo come ciò che è, un bypass architetturale, è il primo passo per neutralizzarlo.

https://www.ictsecuritymagazine.com/articoli/quishing-qr-code-phishing/

La memory safety è uno dei problemi di sicurezza più antichi del software, e nel 2026 è tornata in cima all’agenda con la spinta delle agenzie governative. Si tratta dell’assenza di una intera famiglia di difetti, quelli che nascono quando un programma gestisce a mano la memoria e sbaglia: un buffer overflow che scrive oltre i confini di un’area, un use-after-free che accede a memoria già liberata, una lettura fuori dai limiti. Non sono bug esotici, sono i mattoni con cui si costruiscono da decenni gli exploit più gravi, e continuano a esserlo. Secondo la guida di CISA e agenzie alleate del dicembre 2023, due terzi delle vulnerabilità segnalate nei linguaggi non memory-safe restano legate proprio alla gestione della memoria.

Il punto di svolta non è tecnico ma di prospettiva. Per anni questi difetti sono stati trattati come errori da correggere uno per uno; oggi l’idea che si sta affermando è che siano una classe da eliminare alla radice, scegliendo strumenti che non li rendano possibili. È lo spostamento dal “programmare con più attenzione” al “programmare in un linguaggio che non lascia commettere quell’errore”, e ha smesso di essere una preferenza accademica per diventare una richiesta esplicita di chi regola il mercato.

Che cos’è la memory safety, e perché C e C++ non ce l’hanno

Un linguaggio è memory-safe quando impedisce, per costruzione, gli accessi scorretti alla memoria: non si può leggere oltre la fine di un array, usare un puntatore a memoria già liberata o dimenticare di controllare un limite, perché il linguaggio non lo consente o lo verifica al posto dello sviluppatore. Rientrano in questa categoria linguaggi molto diversi tra loro, da Java e C# a Go, Swift, Python e Rust, che ci arrivano per strade differenti: alcuni con un garbage collector che gestisce la memoria automaticamente, Rust con un sistema di proprietà verificato dal compilatore che ottiene lo stesso risultato senza rinunciare al controllo di basso livello.

C e C++, i linguaggi su cui poggia gran parte del software di sistema, non offrono questa garanzia: lasciano allo sviluppatore la gestione manuale della memoria, e con essa la possibilità di sbagliare. La conseguenza è quantificata da chi ha più codice al mondo. Microsoft ha stimato nel 2019 che circa il 70% delle proprie vulnerabilità con CVE derivasse ogni anno da problemi di memory safety, e in Chrome, su un’analisi di 912 bug di gravità alta o critica segnalati dal 2015 in poi, Google ne ha ricondotto alla stessa classe circa il 70%. Non è una questione di programmatori distratti: è che una classe di errori, su basi di codice enormi, si ripresenta comunque, a prescindere dalla bravura di chi scrive.

Da problema tecnico a richiesta delle autorità

La novità è che la memory safety è entrata nei documenti delle autorità. La stessa guida di CISA, NSA, FBI e delle agenzie di Australia, Canada, Regno Unito e Nuova Zelanda chiede ai produttori di software di pubblicare una roadmap memory-safe, cioè un piano concreto per ridurre nel tempo la dipendenza dai linguaggi non sicuri. Con il documento Product Security Bad Practices, arrivato alla versione 2.0 nel gennaio 2025, il tono si è fatto più netto: sviluppare nuove linee di prodotto in linguaggi non memory-safe, per il software che sostiene funzioni critiche, viene indicato come una cattiva pratica, e ai produttori si chiede di pubblicare la propria roadmap entro la fine del 2025, scadenza ormai alle spalle, con l’eccezione dei prodotti la cui fine del supporto è prevista prima del 2030. Lo stesso documento precisa di non imporre alcun obbligo: non è una legge, ma una guida; sposta però le attese, e con esse la responsabilità di chi continua a ignorare il problema.

L’orientamento è confermato e dettagliato dal documento congiunto NSA e CISA sui linguaggi memory-safe del giugno 2025. In Europa la spinta è meno esplicita ma va nella stessa direzione, per la via del security by design: il Cyber Resilience Act, i cui requisiti essenziali di cybersicurezza si applicheranno dall’11 dicembre 2027, imporrà sicurezza fin dalla progettazione e gestione delle vulnerabilità per i prodotti con elementi digitali, mentre l’obbligo di segnalare le vulnerabilità attivamente sfruttate scatta già dall’11 settembre 2026. Il regolamento non nomina i linguaggi memory-safe, e il collegamento resta quindi inferenziale, ma un difetto di memoria evitabile alla radice è proprio il tipo di rischio che quell’obbligo mira a comprimere. La memory safety, insomma, sta migrando dal terreno delle buone pratiche a quello delle aspettative di mercato e, in prospettiva, degli obblighi.

La lezione di Android: non riscrivere tutto, cambiare il nuovo codice

La domanda ovvia è come si applichi tutto questo a basi di codice che contano decine di milioni di righe in C e C++. La risposta più convincente arriva da Google, che sul codice di Android ha ottenuto un risultato netto senza una riscrittura di massa. La serie storica è eloquente: la quota di vulnerabilità dovute a problemi di memoria è passata dal 76% del 2019 al 24% del 2024, e nel 2025, secondo la rilevazione di novembre, è scesa sotto il 20% per la prima volta. Google non ha riscritto il vecchio codice, ha spostato sui linguaggi memory-safe il codice nuovo, e la differenza si legge nella densità dei difetti: una stima prudente colloca il codice Rust di Android intorno a 0,2 vulnerabilità di memoria per milione di righe, contro le circa mille del C e del C++, oltre mille volte in meno.

Funziona perché le vulnerabilità non si distribuiscono in modo uniforme nel tempo: il codice appena scritto ne contiene molte di più di quello che è invecchiato ed è stato ripulito a forza di correzioni. Concentrare i linguaggi sicuri dove nasce il rischio, cioè nelle nuove funzionalità, fa crollare la quota complessiva senza il costo proibitivo di rifare ciò che già funziona. E smonta anche l’idea che la sicurezza costi in produttività: sempre su Android, sulle modifiche medie e grandi il tasso di rollback delle modifiche in Rust è circa quattro volte più basso che in C++, e le modifiche in Rust passano in generale circa il 25% di tempo in meno in revisione. Non bisogna migrare tutto, insomma: bisogna smettere di aggiungere il problema.

Rust non risolve tutto: i limiti e la strada realistica

Sarebbe però un errore trasformare la memory safety in un tifo per un linguaggio. Anche il codice memory-safe ha i suoi confini: Rust prevede blocchi unsafe per le operazioni di basso livello e per il dialogo con il codice C, che riaprono in parte i rischi che il linguaggio altrove elimina. Il peso di questi blocchi, però, va misurato e non esagerato: nel codice Rust circa il 4% sta dentro blocchi unsafe, e unsafe non disattiva la maggior parte dei controlli del linguaggio. E soprattutto la sicurezza della memoria non elimina le altre categorie di bug, dalla logica errata alle vulnerabilità di iniezione: un programma memory-safe può essere insicuro in mille altri modi. Ciò che si guadagna è la scomparsa della classe più numerosa e più sfruttata, non la sicurezza assoluta.

Resta poi l’enorme patrimonio di software che non si può realisticamente riscrivere, dai kernel al mondo embedded e industriale, dove C e C++ domineranno ancora a lungo. Per quel codice la risposta non è il linguaggio ma l’irrobustimento a più livelli: mitigazioni del compilatore, analisi statica lungo la pipeline di DevSecOps con strumenti come i SAST, fuzzing sistematico e architetture che confinano i danni. Che le difese a più livelli funzionino lo mostra un caso reale, arrivato peraltro dal versante opposto: una vulnerabilità del 2025 in un decoder Rust di Android (CVE-2025-48530), annidata in un blocco unsafe, non è mai arrivata in un rilascio pubblico, e il codice CVE le è stato assegnato solo per tracciarne la correzione con la giusta priorità. Il postmortem ha stabilito che l’allocatore hardened Scudo la rendeva comunque deterministicamente non sfruttabile grazie alle sue guard pages, che anzi hanno contribuito a scoprirla trasformando un overflow silenzioso in un crash rumoroso. Scudo è l’allocatore predefinito di Android, benché Google stia ancora lavorando con i partner per renderlo obbligatorio ovunque. È la difesa in profondità che fa il suo lavoro, e la conferma che la strada realistica è duplice: linguaggi memory-safe per il nuovo, difese a più livelli per il vecchio.

La pressione, del resto, si sente anche fuori da Android. Il mondo C++ ha reagito ai richiami delle agenzie scegliendo la via dei Profiles, un insieme di regole di sicurezza opzionali, dopo aver di fatto accantonato la proposta più radicale di un borrow checker in stile Rust, una scelta che diversi critici giudicano insufficiente a garantire una sicurezza stretta. Dentro Microsoft, un distinguished engineer ha reso pubblico a fine 2025 il proprio obiettivo, eliminare C e C++ dal codice dell’azienda entro il 2030, usando AI e algoritmi per tradurre i codebase più grandi, come da strategia del gruppo di ricerca di cui fa parte. L’autore ha poi precisato che si tratta di un progetto di ricerca e non di una strategia aziendale, ma la sola circolazione dell’idea dice quanto si sia spostato il baricentro del dibattito. E un argomento nuovo rende tutto più urgente: quando la generazione di codice assistita dall’AI produce software più in fretta di quanto gli umani riescano a rivederlo, conviene che quel codice nasca in un linguaggio che certi errori non li permette nemmeno.

Cosa aspettarsi, senza illusioni

La memory safety non è una bacchetta magica e non renderà sicuro il software di colpo, ma è probabilmente l’intervento con il miglior rapporto tra costo e beneficio disponibile oggi: rimuove alla radice la classe di vulnerabilità più numerosa e più sfruttata, e lo fa nel punto più economico, cioè prima che il difetto esista. Per chi sviluppa significa adottare una disciplina di secure coding che parte dalla scelta del linguaggio per il codice nuovo; per chi compra software significa iniziare a chiedere ai fornitori la loro roadmap memory-safe, esattamente come oggi si chiede un SBOM. Il messaggio che arriva dalle agenzie è che continuare a produrre nuovi difetti di memoria, avendo gli strumenti per non farlo, non sarà più considerato normale. La memory safety, da nicchia per specialisti, è diventata il modo più concreto per ridurre la superficie d’attacco alla fonte.

https://www.ictsecuritymagazine.com/articoli/memory-safety-linguaggi-sicuri/

Il security data lake è la risposta a un problema che i responsabili della sicurezza conoscono bene ma di cui si parla poco: raccogliere e conservare i dati necessari a rilevare un attacco è diventato così costoso da spingere molte organizzazioni a rinunciarvi, cioè a scartare log che sarebbero serviti proprio nel momento peggiore. Il SIEM, il sistema che da vent’anni sta al centro del centro operativo di sicurezza, è nato in un’epoca di volumi di dati incomparabilmente più piccoli, e il suo modello economico, che fa pagare in proporzione a quanto si immette, mal si adatta a un mondo in cui i log crescono più in fretta dei budget. Da qui una trasformazione silenziosa ma profonda: la piattaforma non scompare, ma si scompone.

L’idea di fondo è separare due cose che il SIEM teneva insieme: la conservazione dei dati e la loro analisi. Da un lato uno strato di raccolta capace di trattenere tutto a costi bassi; dall’altro uno strato analitico che interroga quei dati quando servono. È la stessa logica che ha ridisegnato l’analisi dei dati aziendali dieci anni fa, arrivata ora, con ritardo, alla sicurezza. E non è una moda da fornitori: è la conseguenza aritmetica di un costo per gigabyte che, moltiplicato per i volumi odierni, non regge più.

Perché il SIEM tradizionale non regge più i volumi

Il nodo è il modello di prezzo. La maggior parte dei SIEM fattura in base al volume immesso, così ogni fonte aggiunta, ogni picco di traffico, ogni nuovo sistema da monitorare fa salire il conto. La reazione prevedibile dei team, sotto pressione di budget, è filtrare all’origine: non inviare al SIEM i log ritenuti meno critici, campionarli, o conservarli per pochi giorni. Ogni scelta di questo tipo è un risparmio immediato e un punto cieco differito, perché la fonte scartata è spesso quella che, a incidente avvenuto, avrebbe raccontato come l’attaccante è entrato e cosa ha toccato.

È il motivo per cui il problema economico è, in realtà, un problema di sicurezza. Quando l’analista deve scegliere quali dati permettersi invece di quali dati servono, la copertura di rilevamento smette di essere una decisione tecnica e diventa una voce di spesa. La crescita dei volumi, alimentata da cloud, identità, endpoint e ambienti ibridi, ha reso questa tensione insostenibile, e ha spinto il mercato a cercare un’architettura che disaccoppi il costo della conservazione da quello dell’analisi.

Che cos’è un security data lake

Un security data lake è un archivio centralizzato che raccoglie i dati di sicurezza, strutturati e non, su storage a oggetti a basso costo, tenendoli disponibili per l’interrogazione senza il sovrapprezzo di un’indicizzazione permanente. La differenza rispetto al SIEM classico è che conservare non implica più pagare per analizzare in continuazione: i dati restano lì, economici, e la potenza di calcolo viene applicata quando serve, sui dati che servono. Questo permette di trattenere anni di storico, invece di giorni, e di condurre indagini retrospettive che con la ritenzione ridotta imposta dai costi sarebbero impossibili.

La contropartita è il tiering, cioè la distinzione tra dati “caldi”, subito interrogabili per il rilevamento in tempo reale, e dati “freddi”, conservati a lungo e richiamabili con qualche attesa in più per le indagini e la conformità. Formati aperti e storage di proprietà dell’organizzazione riducono inoltre il rischio di lock-in, il vincolo che a lungo ha reso difficile lasciare un fornitore di SIEM una volta che ci si erano riversati dentro tutti i log. È un cambio di rapporti di forza: i dati tornano a essere dell’azienda, e la piattaforma di analisi diventa sostituibile.

La security data pipeline: filtrare prima di pagare

Tra le fonti e lo strato di analisi si è inserito un terzo componente, la security data pipeline, che raccoglie i dati, li normalizza, li arricchisce e decide dove instradarli. La sua funzione economica è semplice e potente: ridurre ciò che arriva al SIEM costoso, mandando il resto al data lake a basso costo, senza perdere nulla. È la promessa che ha reso questo strato l’oggetto delle acquisizioni che hanno riscritto il mercato tra il 2025 e il 2026: CrowdStrike ha rilevato Onum per 290 milioni di dollari, SentinelOne ha rilevato Observo AI per 225, e soprattutto Palo Alto Networks si è presa Chronosphere, una piattaforma di observability che porta con sé anche capacità di telemetry pipeline: l’operazione, annunciata a novembre 2025 per 3,35 miliardi e perfezionata il 29 gennaio 2026, vale oltre sei volte le due precedenti messe insieme, il segno che rendere sostenibile l’ingestion su larga scala è ormai un asset strategico.

Federated search: cercare dove i dati già sono

La federated search è la capacità di interrogare dati che risiedono in posti diversi, un SIEM, un bucket su cloud, una piattaforma di analytics, senza doverli prima centralizzare. Serve a superare il presupposto storico che per correlare i dati bisognasse ammassarli tutti nello stesso posto, presupposto che è anche la radice del costo. Se si può cercare dove i dati già sono, la centralizzazione totale smette di essere obbligatoria, e con essa cade una parte consistente della spesa.

Il mercato si consolida e si biforca

Questa transizione avviene mentre il mercato dei SIEM attraversa il suo più grande riassetto. Nel marzo 2024 Cisco ha chiuso l’acquisizione di Splunk per circa 28 miliardi di dollari; a maggio Palo Alto Networks ha annunciato l’acquisto delle attività SaaS del QRadar di IBM, perfezionato ad agosto per 1,1 miliardi comprensivi della componente variabile, di cui 500 milioni in contanti, migrando i clienti verso la propria piattaforma Cortex XSIAM; a luglio Exabeam e LogRhythm hanno completato la fusione. E il consolidamento non è solo cronaca finanziaria: il QRadar SaaS acquisito da IBM è già stato messo in fine vita, con la prima ondata di dismissioni (QRadar on Cloud, SOAR, Log Insights) scaduta il 14 aprile 2026 e la seconda (EDR, XDR, X-Force Threat Intelligence) fissata al 31 agosto 2026, un prodotto storico uscito dal mercato in meno di due anni dall’acquisizione, mentre le versioni on premise restano fuori dal perimetro dell’annuncio.

Sotto il consolidamento si intravede una distinzione più utile per chi deve scegliere, e più sottile della vulgata “aperto contro integrato”. Anche gli ecosistemi tutto-in-uno hanno ormai assorbito il data lake e la federated search, cioè proprio le tecnologie che sembravano la loro alternativa. Microsoft Sentinel, per esempio, ha reso generalmente disponibile un data lake nativo con storage a livelli e fino a dodici anni di dati interrogabili, e dall’aprile 2026 può federare dati da Fabric, ADLS e Azure Databricks; la sua piattaforma unisce già SIEM, XDR, SOAR e gestione dell’esposizione. E non è un caso isolato: anche Splunk, ormai in Cisco, ha annunciato un proprio Machine Data Lake dentro il Cisco Data Fabric presentato a settembre 2025, con una federazione che raggiunge Amazon S3, Iceberg, Delta Lake, Snowflake e Azure, e disponibilità annunciata nel corso del 2026. Lo ha ammesso senza giri di parole Kamal Hathi, a capo di Splunk in Cisco: ingerire tutti i dati dentro Splunk non è un’idea praticabile, la strada è portare l’analisi dove i dati vivono, non costruire un unico grande lago. Il Machine Data Lake non contraddice la frase, la completa: è il livello economico che sta sotto le piattaforme di analisi, da cui i dati vengono promossi solo quando servono. È esattamente la tesi da cui siamo partiti, pronunciata dal fornitore che proprio sul lago unico ha fondato vent’anni di fatturato.

La domanda vera, allora, non è “aperto o integrato”, ma due altre: chi possiede lo storage in cui vivono i dati, e quanto è portabile il formato in cui sono scritti. Da lì dipende se domani si potrà cambiare piattaforma di analisi senza rifare tutto, ed è la decisione che ogni SOC si troverà a prendere.

Il movimento, poi, non è più solo interno alla sicurezza. Il 24 marzo 2026 Databricks, uno dei nomi del lakehouse per l’analisi dei dati, ha presentato Lakewatch, un SIEM agentico e aperto oggi in private preview, annunciando insieme le acquisizioni di Antimatter e SiftD.ai, quest’ultima fondata dal creatore del Search Processing Language di Splunk e dagli architetti del suo stack di ricerca. È la conferma letterale del punto di partenza: la logica che ha ridisegnato l’analisi dei dati aziendali non solo è arrivata alla sicurezza, ma ora sono i fornitori del dato, e persino i creatori del linguaggio del vecchio SIEM, a entrare nel SOC.

Il rischio: un lago senza rilevamento è una palude

C’è un modo di sbagliare questa transizione, ed è trattare lo storage economico come un fine invece che come un mezzo. Poter conservare tutto tenta a fare esattamente questo, cioè accumulare dati con l’idea vaga di analizzarli “poi”, e il risultato è un archivio enorme e inerte, sul quale nessuno costruisce rilevamento. Un data lake senza detection non è una strategia, è una palude: costa meno di un SIEM mal dimensionato, ma non protegge di più. Il dato diventa sicurezza solo quando qualcuno scrive le regole di correlazione, definisce cosa cercare e mantiene viva la disciplina del rilevamento, esattamente come nell’evoluzione del SOC verso una difesa che misura la propria efficacia.

Va aggiunta la spinta della conformità, che in Europa rema nella stessa direzione. NIS2 e DORA non fissano una durata minima di conservazione dei log, ma impongono di definirla, documentarla e giustificarla in base al rischio, oltre a garantire l’integrità e la reperibilità delle evidenze, come ricorda la mappa degli adempimenti NIS2: in pratica, la ritenzione lunga smette di essere una scelta discrezionale e diventa una posizione da difendere davanti a un auditor. Su questo un security data lake è la risposta economicamente sostenibile, perché consente di trattenere anni di dati senza pagarli come se fossero tutti caldi. Per una volta la conformità coincide con la buona pratica di sicurezza, perché lo storico che serve al revisore è lo stesso che serve all’analista per ricostruire un attacco lento.

Cosa aspettarsi, senza illusioni

Il SIEM non sta morendo, si sta scomponendo, e il security data lake è la parte di questa scomposizione che ridà alle organizzazioni una leva che avevano perso: decidere cosa conservare in base a ciò che serve alla difesa, non a ciò che il modello di prezzo consente. Il ritorno concreto non è solo il risparmio, ma la fine del compromesso quotidiano tra copertura e budget, e la possibilità di guardare indietro di anni quando un’indagine lo richiede. Resta però la parte difficile, che nessuna architettura regala: il rilevamento, la correlazione e le persone che li governano. Chi tratta il security data lake come una scorciatoia per spendere meno otterrà un magazzino di dati; chi lo tratta come la fondazione su cui costruire un rilevamento finalmente non più razionato otterrà una difesa migliore. La differenza, come sempre, non è nello strumento ma in cosa ci si fa.

https://www.ictsecuritymagazine.com/articoli/security-data-lake-siem/

Il codice generato dall’AI ha smesso di essere una curiosità da laboratorio ed è entrato nel flusso di lavoro quotidiano di gran parte degli sviluppatori, spesso senza che l’organizzazione se ne sia accorta davvero. La promessa è evidente e reale: scrivere più in fretta, delegare le parti ripetitive, abbassare la barriera d’ingresso a chi programma poco. Il problema è che la sicurezza non è migliorata alla stessa velocità della produttività, e i numeri cominciano a dirlo con precisione. Il Veracode GenAI Code Security Report, nella sua prima edizione del luglio 2025, ha messo alla prova oltre cento modelli su ottanta compiti in cui esisteva sia una via sicura sia una insicura, e ha misurato una cosa precisa: nel 45% dei casi il modello sceglie la via insicura.

Il dato più scomodo non è la percentuale in sé, ma la sua ostinazione. L’aggiornamento di primavera 2026 del report, esteso a oltre 150 modelli tra cui i più recenti (GPT-5.1 e 5.2, Gemini 3, Claude 4.5 e 4.6), fotografa la stessa situazione di due anni prima: solo il 55% del codice generato è sicuro, mentre la correttezza sintattica ha ormai superato il 95%. I modelli hanno imparato benissimo a produrre codice che funziona e compila, e questo genera fiducia; la stessa fiducia non è però giustificata sul piano della sicurezza, dove i progressi sono stati minimi. Va detta un’eccezione, per onestà: la famiglia GPT-5 con reasoning esteso ha toccato, nella rilevazione dell’ottobre 2025, il tasso più alto mai registrato, tra il 70 e il 72%, ma le release successive non hanno consolidato il vantaggio, restando nel margine d’errore dei modelli precedenti. E anche quel picco lascia vulnerabile quasi un frammento di codice su tre, lontano da un livello accettabile in produzione. Chi accetta un suggerimento perché “gira” sta valutando la funzionalità, non la resistenza a un attacco, e il modello ha ottimizzato esattamente per la prima cosa.

Perché il codice generato dall’AI è insicuro per default

La radice del problema è nel modo in cui questi modelli imparano. Un large language model è addestrato su enormi quantità di codice pubblico, che include tanto le buone pratiche quanto gli esempi vulnerabili, i tutorial semplificati e le scorciatoie insicure che popolano forum e repository. Il modello non distingue il codice sicuro da quello pericoloso: riproduce ciò che è statisticamente plausibile nel contesto, e il pattern insicuro spesso è più frequente di quello corretto. Manca inoltre la cosa che un buon sviluppatore porta con sé, cioè il contesto di minaccia: chi userà questa funzione, con quali input ostili, in quale posizione della superficie d’attacco.

Il dato di addestramento, però, spiega solo una parte, e i numeri dell’aggiornamento 2026 mostrano dove il problema si concentra davvero. I modelli non sbagliano ovunque: sulla SQL injection il codice sicuro sale all’82% e sugli algoritmi crittografici deboli all’86%, perché sono vulnerabilità riconoscibili come pattern locali, viste e riviste etichettate come insicure. Crollano invece dove serve seguire un input non fidato attraverso più funzioni, trasformazioni e file fino al punto in cui viene usato: sul cross-site scripting solo il 15% del codice supera i controlli, sulla log injection appena il 13%, e su queste categorie Veracode segnala che la tendenza sta perfino peggiorando. È la differenza tra riconoscere una forma e ricostruire un contesto, cioè l’analisi di dataflow interprocedurale, difficile da fare in modo consistente perfino per una persona esperta. Non a caso il linguaggio peggiore è Java, fermo al 29% di codice sicuro contro il 62% di Python, e non a caso i modelli con reasoning recuperano qualcosa, perché i passaggi di ragionamento funzionano come una revisione interna del codice. Non è dunque un limite che la prossima generazione di modelli risolverà da sé: è strutturale, legato al tipo di analisi che manca, non alla potenza di calcolo.

Non è (solo) un problema di bug: il debito di sicurezza su scala

La differenza rispetto al passato non è la singola vulnerabilità, che c’è sempre stata, ma la scala e la velocità con cui si moltiplica. Lo ha misurato in produzione Apiiro, su decine di migliaia di repository di aziende Fortune 50 tra dicembre 2024 e giugno 2025: gli sviluppatori assistiti dall’AI committano da tre a quattro volte più spesso e generano circa dieci volte più problemi di sicurezza, con gli errori di sintassi in calo del 76% ma i difetti architetturali in aumento del 153%. È, in numeri di produzione, esattamente la tesi di partenza: codice più corretto in superficie e più fragile nella struttura. Lo stesso pattern insicuro, generato una volta, viene poi replicato in decine di punti prima che qualcuno lo riveda, e si aggiungono modalità di errore nuove: segreti e chiavi lasciati in chiaro nel codice suggerito, e soprattutto le dipendenze inventate di sana pianta dal modello, un vettore di supply chain a sé, lo slopsquatting. Uno studio di USENIX Security 2025 (Spracklen et al., We Have a Package for You!, University of Texas at San Antonio), su 576.000 campioni e sedici modelli, ha trovato che circa un campione di codice su cinque, in Python e JavaScript, referenzia pacchetti inesistenti, e che il 43% di quei nomi allucinati si ripresenta identico su prompt simili: è la riproducibilità, non l’allucinazione in sé, a rendere possibile l’attacco, perché consente all’aggressore di registrare in anticipo il pacchetto che il modello inventerà.

C’è poi la dimensione umana, che amplifica tutto il resto ed è la parte del problema più facile da sottovalutare. Un sondaggio Snyk del 2023 su oltre 500 professionisti rilevava che oltre il 75% riteneva il codice generato dall’AI più sicuro di quello scritto dall’uomo. È una percezione autodichiarata, non una misurazione, e uno studio controllato di Stanford presentato ad ACM CCS nel 2023 ha mostrato l’opposto: chi lavorava con un assistente ha consegnato codice significativamente meno sicuro, ed era al tempo stesso più convinto di averlo scritto sicuro. Nello stesso esperimento, chi si fidava meno dell’assistente e rilavorava i prompt produceva codice con meno vulnerabilità. È il cortocircuito che allenta la revisione critica proprio dove servirebbe di più. Quando poi l’adozione avviene fuori da ogni processo (sviluppatori che incollano codice da assistenti personali senza che l’azienda lo sappia), si entra nel territorio della shadow AI, dove il debito non è nemmeno misurabile perché nessuno sa dove e quanto se ne stia accumulando.

Il tracciamento indipendente conferma che il problema è già reale e non teorico. Il cruscotto del Vibe Security Radar, progetto avviato nel maggio 2025 dal Systems Software & Security Lab del Georgia Tech, al 24 marzo 2026 riporta 78 vulnerabilità pubbliche riconducibili all’AI, 43 delle quali classificate come critiche o gravi, su 46.831 advisory analizzati. Ma il segnale vero è l’accelerazione: dalle 6 nuove CVE di gennaio 2026 alle 15 di febbraio alle oltre 35 del solo marzo, un mese in cui i casi hanno superato quelli di tutto il 2025. E il ricercatore che guida il progetto stima il sommerso da cinque a dieci volte più grande, perché molti commit assistiti dall’AI non lasciano tracce nei metadati.

Dalla generazione alla verifica: dove mettere i controlli

La risposta non è vietare gli assistenti, che porterebbe solo più shadow AI, ma trattare il loro output per quello che è: codice non fidato per default, da sottoporre alla stessa verifica che si applicherebbe al contributo di uno sviluppatore junior molto veloce e molto sicuro di sé. La disciplina, in fondo, esiste già ed è quella del secure coding: analisi statica e dinamica nella pipeline, scansione dei segreti prima del commit, verifica delle dipendenze contro l’esistenza reale e la reputazione del pacchetto, revisione umana obbligatoria sui punti critici. Ciò che cambia è che questi controlli non possono più essere occasionali, perché il volume da controllare è esploso.

Il punto operativo è quindi spostare i controlli dove reggono la scala, cioè automatizzarli e inserirli nel flusso, secondo la logica del DevSecOps: far fallire la build quando la vulnerabilità supera una soglia, non affidarsi alla buona volontà di chi rivede a valle. Vale la pena distinguere due livelli. Il primo è tecnico e riguarda i gate automatici nella pipeline; il secondo è di governo e riguarda le regole d’uso, cioè quali strumenti sono ammessi, su quali basi di codice, con quale tracciabilità di ciò che è stato generato. Senza il secondo livello, il primo copre solo il codice che passa dai canali ufficiali, e lascia scoperto proprio quello più rischioso.

L’obbligo non cambia se a scrivere è una macchina

C’è una ragione normativa, oltre che tecnica, per non trattare l’AI come una scusante. Gli obblighi di sicurezza del prodotto non guardano a chi ha scritto materialmente il codice. Il Cyber Resilience Act impone sicurezza by design, gestione delle vulnerabilità e trasparenza sulle componenti per i prodotti con elementi digitali, a prescindere dal fatto che una parte del codice sia stata generata da un modello. La piena applicazione è fissata all’11 dicembre 2027, ma il primo obbligo che tocca direttamente i fabbricanti scatta prima: dall’11 settembre 2026 dovranno segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi, con allarme rapido entro 24 ore e notifica completa entro 72. Un difetto introdotto da un assistente resta, sul piano della responsabilità, un difetto del produttore: l’automazione della scrittura non trasferisce l’automazione della responsabilità.

Cosa aspettarsi, senza illusioni

Il codice generato dall’AI non è un rischio da rimuovere ma una realtà da governare: è già nel processo di sviluppo, produce valore, e continuerà a diffondersi. Trattarlo come infallibile perché appare competente è però l’errore che i dati smentiscono con più nettezza, dal 45% di scelte insicure misurato nel benchmark, un dato fermo da due anni, alle vulnerabilità già ricondotte a questi strumenti nel mondo reale. Il vero pericolo non è il singolo suggerimento sbagliato, ma la velocità che supera la verifica: quando si genera più in fretta di quanto si riesca a controllare, il debito di sicurezza si accumula dove nessuno lo sta guardando. La via d’uscita non è rallentare né vietare, ma portare la verifica alla stessa scala della generazione, con controlli automatici e regole d’uso chiare. In quell’equilibrio, tra velocità dell’AI e rigore della verifica, si decide se il codice generato dall’AI sarà un moltiplicatore di produttività o un moltiplicatore di esposizione.

https://www.ictsecuritymagazine.com/articoli/codice-generato-dall-ai-sicurezza/

Negli ultimi anni il panorama della sorveglianza tecnica è cambiato profondamente. L’evoluzione dei dispositivi digitali, la diffusione delle comunicazioni cifrate e la presenza costante di smartphone e sistemi connessi hanno progressivamente modificato il modo in cui devono essere interpretati i concetti di intercettazione, bonifica e sicurezza ambientale.

In questo contesto, alcune delle metodologie che per decenni hanno rappresentato il riferimento nelle attività TSCM continuano a mantenere un ruolo fondamentale, ma si confrontano con minacce che non sempre si manifestano attraverso dispositivi dedicati o trasmissioni radio facilmente identificabili. Sempre più spesso il vettore di raccolta informativa coincide con dispositivi legittimamente presenti nell’ambiente e utilizzati quotidianamente dagli stessi utenti.

Questo approfondimento analizza tale evoluzione partendo dal ruolo dello smartphone come moderno vettore di sorveglianza, per poi esaminare i limiti operativi della bonifica ambientale tradizionale e il crescente ruolo della bonifica logica dei dispositivi. L’obiettivo non è sostituire i principi della TSCM classica, ma contestualizzarli all’interno di uno scenario tecnologico in cui la distinzione tra dispositivo di lavoro, strumento di comunicazione e potenziale piattaforma di intercettazione è diventata sempre più sottile.

Architettura sensoriale dello smartphone

Il dispositivo mobile moderno non è semplicemente uno strumento di comunicazione. È un nodo sensoriale permanente, costantemente connesso, dotato di capacità di acquisizione, elaborazione e trasmissione dati superiori a quelle di molti sistemi di sorveglianza dedicati di dieci anni fa. Nel contesto della sicurezza e delle attività di bonifica tecnica, lo smartphone rappresenta oggi uno dei principali vettori di sorveglianza potenziale.

Uno smartphone contemporaneo integra una molteplicità di sensori progettati per migliorare l’esperienza utente ma che, in presenza di compromissione logica, possono essere riconfigurati come strumenti di raccolta informativa.

Il microfono è un sensore MEMS (Micro-Electro-Mechanical System) ad alta sensibilità, progettato per comunicazioni vocali, comandi vocali, assistenti digitali e registrazioni ambientali. In caso di compromissione del sistema operativo o tramite malware con privilegi adeguati può attivarsi in background, registrare audio ambientale, trasmettere flussi audio in tempo reale o salvare registrazioni per esfiltrazione differita. Dal punto di vista TSCM, ciò implica che un dispositivo apparentemente inattivo possa funzionare come microspia ambientale software.

Le fotocamere (anteriore e posteriore) integrano sensori CMOS ad alta risoluzione e possono essere sfruttate per acquisizione immagini, cattura video ambientale, scansione documenti e riconoscimento facciale. In contesto di sorveglianza, un attore ostile può attivare la fotocamera in background, scattare immagini periodiche, registrare video o acquisire documentazione cartacea presente nell’ambiente. L’assenza di indicatori hardware dedicati (LED fisicamente collegati al sensore) rende la rilevazione non banale in caso di compromissione avanzata.

Il sistema GNSS (GPS, Galileo, GLONASS, BeiDou) consente geolocalizzazione precisa, tracciamento storico degli spostamenti e correlazione spazio-temporale degli eventi. In aggiunta al GPS, lo smartphone utilizza triangolazione celle LTE/5G, Wi-Fi positioning e Bluetooth beaconing, permettendo una profilazione estremamente accurata dei movimenti anche in ambienti indoor. Dal punto di vista investigativo, la cronologia posizione è uno dei dataset più sensibili in assoluto. Questa caratteristica apre anche alla possibilità di forme di osservazione opportunistica basate sull’analisi passiva dei segnali emessi dai dispositivi, che possono consentire la correlazione della presenza o degli spostamenti di determinati terminali anche senza una loro compromissione diretta.

Il dispositivo mobile è infine costantemente connesso tramite rete cellulare (2G-5G), Wi-Fi, Bluetooth e NFC. La presenza di una connessione dati attiva consente controllo remoto, aggiornamenti silenti, comando e controllo (C2) ed esfiltrazione immediata dei dati raccolti. A differenza di una microspia RF tradizionale, lo smartphone utilizza infrastrutture legittime di rete, rendendo la rilevazione radio molto più complessa.

Presenza costante del dispositivo

Lo smartphone è sempre acceso, sempre con l’utente, raramente spento e spesso presente in riunioni riservate. Questa caratteristica lo rende un vettore ideale di sorveglianza opportunistica: non è necessario installare un dispositivo esterno, perché il sensore è già nella stanza. Dal punto di vista della sicurezza fisica, il paradigma si è invertito: non si introduce più la microspia nell’ambiente, si sfrutta il dispositivo già ammesso volontariamente.

Accesso remoto ai dati

Uno smartphone moderno contiene messaggi, email, documenti, fotografie, credenziali salvate, cronologia di navigazione, token di autenticazione e dati biometrici. In caso di compromissione logica (malware, exploit zero-click, trojan commerciali) è possibile accedere ai file system, intercettare comunicazioni cifrate prima della cifratura, estrarre database applicativi, acquisire backup locali e attivare sensori on-demand. L’accesso remoto può avvenire tramite server C2 esterni, relay cloud o infrastrutture CDN legittime, rendendo la detection puramente basata su IOC spesso insufficiente.

Perché lo smartphone è oggi il vettore principale

Rispetto a una microspia RF tradizionale, uno smartphone compromesso presenta caratteristiche strutturalmente più favorevoli alla sorveglianza: non richiede installazione fisica, perché è già presente nell’ambiente; utilizza reti legittime invece di una banda dedicata facilmente identificabile; dispone di alimentazione e ricarica costante; integra in un solo dispositivo funzioni audio, video, localizzazione e accesso ai dati; richiede un’analisi logica e comportamentale, non soltanto radioelettrica.

Implicazioni per la metodologia TSCM moderna

L’analisi tecnica non può più limitarsi alla ricerca di trasmissioni RF anomale, dispositivi nascosti e segnali burst in banda non autorizzata. È necessario integrare analisi logica del dispositivo, analisi del traffico di rete, analisi dei pattern comportamentali, correlazione temporale tra uplink e dati, verifica della persistenza e individuazione di consumi energetici anomali. Il paradigma di bonifica deve quindi diventare ibrido: RF, logico, comportamentale e infrastrutturale.

Gestione dei dispositivi non verificabili

In contesti operativi può verificarsi la presenza di dispositivi mobili introdotti da soggetti esterni all’organizzazione, come ospiti, consulenti o partner commerciali. Tali dispositivi non possono essere sottoposti a verifica tecnica preventiva e introducono quindi un potenziale vettore di captazione ambientale, dal momento che gli smartphone moderni dispongono di microfoni ad alta sensibilità, capacità di registrazione locale e connettività permanente.

In queste condizioni, la sicurezza dell’ambiente non può essere garantita esclusivamente tramite attività di bonifica tecnica, ma richiede anche misure di mitigazione del rischio associate alla presenza di dispositivi non verificabili. Tra le pratiche operative adottate in contesti sensibili rientrano tecniche di neutralizzazione acustica dei terminali mobili, basate sulla saturazione dei sensori audio mediante emissioni sonore controllate. Tali approcci non eliminano la presenza fisica del dispositivo, ma riducono la possibilità di acquisizione di audio utile durante attività sensibili.

Smartphone e sicurezza: perché sono un rischio nelle attività TSCM

Lo smartphone non è semplicemente un potenziale bersaglio. È un sistema sensoriale avanzato, costantemente connesso, già accettato all’interno degli ambienti sensibili. Per questo motivo rappresenta oggi uno dei principali vettori di sorveglianza nel panorama contemporaneo: non per natura intrinsecamente ostile, ma per concentrazione funzionale di sensori, connettività e dati.

Limiti della bonifica ambientale tradizionale

Nella pratica operativa delle bonifiche tecniche non è raro riscontrare ambienti radio privi di anomalie significative, nei quali successive verifiche sui dispositivi presenti evidenziano invece comportamenti di rete incompatibili con un uso fisiologico. La bonifica ambientale tradizionale rimane uno strumento fondamentale nel contrasto alle microspie e ai dispositivi di intercettazione ambientale, ma l’integrazione tra comunicazioni radio, reti IP e dispositivi mobili impone una revisione critica del suo perimetro operativo. Non si mette in discussione l’efficacia della bonifica classica: se ne analizzano i limiti strutturali in uno scenario tecnologico ibrido.

Componenti e capacità della bonifica tradizionale

Una bonifica TSCM tradizionale si articola in tre attività complementari. La prima è l’analisi radioelettrica, che comprende l’analisi dello spettro radio (tipicamente da 9 kHz a 6/8 GHz, estendibile oltre), la ricerca di trasmissioni attive (analogiche, digitali, burst, FHSS) e la verifica di segnali persistenti o anomali rispetto alla baseline ambientale, con strumentazione tipica come spectrum analyzer, antenne direzionali e omnidirezionali, near-field probe e tecniche di sweep dinamico. Il principio operativo è semplice: se un dispositivo trasmette in radiofrequenza, la sua emissione può essere rilevata e analizzata.

La seconda è l’ispezione fisica tecnica dell’ambiente: verifica di arredi, oggetti e infrastrutture, controllo di cablaggi e alimentazioni, identificazione di elementi non coerenti con l’ambiente, eventualmente supportata da endoscopi, telecamere termiche e altre tecnologie di imaging. Questa attività rimane uno dei pilastri della bonifica TSCM, poiché molti dispositivi di intercettazione sono progettati per mimetizzarsi in oggetti di uso comune. La terza è la rilevazione di elettronica nascosta tramite strumenti come il rilevatore di giunzioni non lineari (NLJD, Non Linear Junction Detector), che individua dispositivi elettronici occultati grazie alle giunzioni semiconduttive tipiche dei circuiti integrati, anche in assenza di trasmissioni radio attive.

Se correttamente eseguite e integrate, queste tecniche possono individuare microspie RF analogiche, trasmettitori digitali UHF/VHF, dispositivi GSM/UMTS/LTE attivi, microspie Wi-Fi o Bluetooth in fase di trasmissione, beacon RF persistenti, dispositivi elettronici occultati e circuiti elettronici nascosti anche in assenza di emissioni RF. In sintesi, il modello TSCM tradizionale è progettato per individuare dispositivi hardware dedicati all’intercettazione, collocati fisicamente nell’ambiente.

Il limite strutturale del modello tradizionale

Il limite emerge quando la minaccia non consiste in un dispositivo esterno, ma in una compromissione dei dispositivi legittimi presenti nell’ambiente. In questi scenari le tecniche classiche possono risultare inefficaci, perché non esiste alcun nuovo hardware da individuare. In particolare, esse non possono individuare:

1. software di intercettazione installato su dispositivi mobili, come spyware o captatori informatici presenti su smartphone o tablet;
2. compromissioni di sistemi informatici, come PC, workstation o server aziendali accessibili da remoto;
3. esfiltrazione di dati attraverso traffico di rete cifrato apparentemente legittimo (HTTPS, VPN o altri canali normalmente utilizzati dalle applicazioni);
4. l’utilizzo dei microfoni o dei sensori già presenti nei dispositivi dell’ambiente (smartphone, smart TV, assistenti vocali o altri dispositivi con capacità di acquisizione audio);
5. compromissioni software di dispositivi di rete, come router, access point o altri apparati utilizzabili come punto di accesso o di raccolta dati.

La criticità non riguarda una singola tecnica di rilevazione, ma il paradigma stesso della bonifica tradizionale, concepito per individuare dispositivi hardware dedicati.

Il cambio di paradigma: la minaccia nel dispositivo

Nel contesto tecnologico attuale, la minaccia può non essere esterna all’ambiente, ma interna ai dispositivi legittimi: smartphone compromesso tramite spyware, PC con Remote Access Trojan, tablet con applicazioni di monitoraggio occulto, dispositivi IoT compromessi, smart TV con accesso remoto, router con firmware alterato. In questi scenari non esiste un nuovo dispositivo da cercare, l’hardware è legittimo, la trasmissione avviene su canali perfettamente normali (HTTPS, VPN, DNS, QUIC), il traffico è cifrato e l’emissione RF non è distinguibile da quella ordinaria. Dal punto di vista TSCM tradizionale, l’ambiente può risultare formalmente pulito; dal punto di vista della sicurezza reale, può essere completamente compromesso.

Lo scenario tipico è quello di un ufficio dirigenziale sottoposto a bonifica tecnica completa (RF, ispezione fisica, NLJD) senza alcuna anomalia rilevata, nel quale emerge successivamente uno smartphone con spyware commerciale che esfiltra dati tramite traffico HTTPS e attiva da remoto il microfono.

Per la bonifica ambientale tradizionale non risultano né trasmettitori occulti né dispositivi elettronici nascosti; per la sicurezza reale, l’intercettazione è completa e realizzata tramite un dispositivo legittimo. Il punto è metodologico, non strumentale: la bonifica classica controlla lo spettro radio, verifica la presenza di elettronica nascosta e ispeziona fisicamente l’ambiente, ma non analizza il comportamento logico dei dispositivi digitali, e quindi non può eseguire analisi forense dei terminali, individuare malware o spyware, rilevare pattern di esfiltrazione né identificare compromissioni software. Da qui un rischio operativo significativo: la certificazione di un ambiente pulito basata esclusivamente sull’assenza di dispositivi di intercettazione hardware.

Bonifica ambientale e nuove minacce: perché il TSCM tradizionale non basta più contro dispositivi compromessi e spyware

La bonifica ambientale tradizionale resta necessaria, fondamentale e imprescindibile, ma non è più sufficiente da sola. L’evoluzione delle minacce ha spostato il baricentro dai trasmettitori hardware dedicati ai dispositivi legittimi compromessi, e dai segnali evidenti al traffico cifrato indistinguibile. Una bonifica tradizionale può dichiarare con elevata affidabilità l’assenza di dispositivi di intercettazione hardware attivi o occultati, ma non può escludere la presenza di intercettazioni realizzate tramite dispositivi legittimi compromessi. La differenza tra queste due affermazioni rappresenta il vero punto di rottura concettuale, e richiede un approccio integrato che affianchi alle tecniche TSCM tradizionali l’analisi dei dispositivi digitali, la verifica logica dei terminali e lo studio dei pattern di comunicazione, oggetto del capitolo seguente.

La bonifica logica dei dispositivi

La bonifica logica rappresenta l’estensione naturale della bonifica ambientale nel dominio digitale. Se la TSCM tradizionale si occupa di intercettazioni radio e microspie fisiche, la bonifica logica si concentra su dispositivi informatici e mobili che possono fungere da vettori di raccolta e trasmissione occulta di informazioni. Smartphone e computer non sono solo strumenti di comunicazione, ma veri e propri nodi sensoriali permanenti: microfono, fotocamera, GPS, accelerometri e connettività multi-radio (Wi-Fi, Bluetooth, LTE/5G) li rendono potenziali piattaforme di intercettazione sofisticata. Smartphone apparentemente inattivi possono mantenere comunicazioni periodiche verso endpoint remoti, difficilmente distinguibili dal traffico applicativo ordinario senza un’analisi strutturata dei pattern di rete.

La bonifica logica non coincide con la digital forensics né con il penetration testing offensivo. È un’attività difensiva, osservativa e metodologica, orientata alla rilevazione di anomalie compatibili con scenari di sorveglianza remota, e può essere interpretata come un processo strutturato che prevede acquisizione dei dati tecnici, analisi dei pattern di comunicazione e correlazione tra domini tecnologici diversi.

Analisi di smartphone e PC

L’analisi logica di un dispositivo si fonda su un principio essenziale: osservare senza alterare. L’obiettivo non è forzare il sistema o installare strumenti invasivi, ma analizzare configurazioni di sistema, profili di gestione, servizi attivi, processi in esecuzione, connessioni di rete e pattern temporali di attività.

Nei dispositivi mobili (Android e iOS) si osservano in particolare configurazioni MDM o profili enterprise, permessi anomali concessi ad applicazioni, persistenza di servizi in background e attivazioni radio non coerenti con l’uso dichiarato. Nei sistemi desktop (Windows, macOS) si osservano servizi persistenti, attività pianificate, connessioni outbound ripetitive e nodi di comunicazione dominanti. L’analisi è pattern-centrica: non si fonda esclusivamente su IOC (Indicator of Compromise), ma sulla ricerca di comportamenti ricorrenti, dominanti o incompatibili con l’uso fisiologico del dispositivo.

Acquisizione e osservazione del traffico

La bonifica logica si fonda su una verità tecnica: un dispositivo compromesso deve comunicare. L’acquisizione dei dati di rete, quando consentita dal contesto operativo, avviene in modalità passiva, privilegiando catture di traffico (PCAP/PCAPNG), log di sistema, log radio (Wi-Fi e cellulare) e metadati di connessione. L’attenzione non è rivolta al contenuto delle comunicazioni, ma alla struttura del traffico: frequenza delle connessioni, persistenza temporale, distribuzione IP sorgente/destinazione e concentrazione verso specifici nodi. L’analisi quantitativa (conteggi, flussi, ricorrenze) consente di individuare flussi dominanti, comunicazioni periodiche, nodi di aggregazione e pattern di beaconing. Senza effettuare ispezione profonda del payload è quindi possibile individuare anomalie statistiche compatibili con attività di esfiltrazione o controllo remoto.

L’osservazione del traffico non è un’attività di intercettazione, ma di analisi comportamentale. Si valutano variazioni improvvise del volume dati, attività in orari non coerenti con l’utilizzo, traffico in assenza di interazione utente e correlazioni tra eventi radio e attività di rete. Un principio chiave è la distinzione tra traffico infrastrutturale fisiologico, traffico applicativo legittimo e traffico anomalo per persistenza, frequenza o direzionalità. La bonifica logica non attribuisce automaticamente natura malevola a un flusso sconosciuto: produce invece una classificazione (compatibile con uso normale, da approfondire, incompatibile con scenario fisiologico).

Approccio non invasivo e differenza rispetto ad altre discipline

Elemento distintivo della bonifica logica è l’approccio passivo, non distruttivo e non alterante. Non si effettuano rooting o jailbreak, installazioni di agenti permanenti né modifiche strutturali al sistema. Questo garantisce l’integrità del dispositivo, la preservazione di eventuale valore probatorio e la neutralità metodologica. La disciplina si colloca così in una zona intermedia tra audit tecnico, analisi di sicurezza e osservazione comportamentale.

La bonifica logica non cerca necessariamente malware noto: cerca incoerenze strutturali.

Bonifica logica e TSCM moderno: perché il dispositivo personale è il primo punto di compromissione

In un contesto TSCM moderno la bonifica logica diventa imprescindibile, perché la microspia può essere software, l’esfiltrazione può avvenire su banda legittima e il vettore può essere il dispositivo stesso della vittima. La chiave non è lo strumento, ma la metodologia: separazione tra dato e interpretazione, analisi quantitativa prima di quella qualitativa, esclusione delle spiegazioni fisiologiche prima di formulare ipotesi. La bonifica tecnica moderna non consiste esclusivamente nella ricerca di dispositivi di intercettazione, ma nell’analisi strutturata dell’ecosistema tecnologico presente nell’ambiente osservato. In questo ecosistema, il dispositivo personale è il primo punto di osservazione e, potenzialmente, il primo punto di compromissione.

L’evoluzione della sorveglianza tecnica ha progressivamente spostato l’attenzione dai dispositivi di intercettazione dedicati ai dispositivi digitali legittimamente presenti negli ambienti. In questo approfondimento abbiamo analizzato il ruolo dello smartphone come moderno vettore di sorveglianza, i limiti della bonifica ambientale tradizionale e la necessità di integrare metodologie di bonifica logica per affrontare minacce che operano attraverso software, traffico cifrato e infrastrutture di rete legittime.

Nel prossimo approfondimento esamineremo uno degli aspetti più critici della bonifica logica moderna: i limiti degli approcci basati esclusivamente sugli Indicatori di Compromissione (IOC), il valore di una metodologia pattern-centrica e le inevitabili ambiguità che caratterizzano ogni attività di analisi tecnica. Comprendere cosa può e cosa non può dimostrare un’analisi è infatti un elemento essenziale per evitare false certezze e interpretare correttamente i risultati ottenuti.

Per chi desidera approfondire il tema in modo organico e metodologico, questi argomenti sono sviluppati nel white paper completo “Contromisure tecniche alla sorveglianza nell’era digitale: il Metodo SPECTRA” di Stefano Cangiano. Il documento propone un modello integrato che unisce TSCM tradizionale, analisi logica e osservazione comportamentale dei dispositivi, offrendo una visione strutturata delle moderne attività di bonifica tecnica e delle sfide poste dall’attuale ecosistema digitale.

https://www.ictsecuritymagazine.com/articoli/tscm/

CTEM, acronimo di continuous threat exposure management, nasce da una constatazione scomoda per chi difende le organizzazioni: si applicano patch sempre più in fretta, si automatizzano controlli, si chiudono falle a ritmo crescente, eppure l’esposizione reale al rischio non diminuisce in proporzione. La ragione è che la sicurezza viene ancora gestita come una sequenza di episodi, una vulnerabilità dopo l’altra, anziché come una condizione continua da misurare e ridurre. È esattamente lo spostamento di prospettiva che Gartner ha riassunto nella formula “gestire le minacce, non gli episodi”, e attorno al quale ha costruito un processo a cinque fasi pensato per portare ordine in un’attività che troppo spesso resta reattiva.

Il punto non è tecnologico ma metodologico. Gli strumenti per scoprire vulnerabilità esistono da vent’anni e funzionano. Quello che manca, nella maggior parte dei programmi di sicurezza, è un criterio stabile per decidere cosa conta davvero, in quale ordine intervenire e come verificare che l’intervento abbia ridotto il rischio anziché solo accorciato una lista. Il CTEM prova a colmare proprio questo vuoto.

Perché la gestione delle vulnerabilità non riduce l’esposizione

La gestione delle vulnerabilità tradizionale produce volume: scansioni periodiche, migliaia di CVE ordinati per punteggio CVSS, ticket che si accumulano più velocemente di quanto i team riescano a chiuderli. Il problema è che il numero di falle individuate non dice nulla sul rischio effettivo. Una vulnerabilità con punteggio alto su un sistema isolato e privo di dati critici può attendere; una falla apparentemente minore su un asset esposto e collegato a informazioni sensibili può essere la porta d’ingresso di un attacco.

Ridurre l’esposizione richiede un cambio di unità di misura: non quante vulnerabilità sono state corrette, ma quanto è diminuita la probabilità concreta che un attaccante raggiunga ciò che ha valore per l’azienda. Qui la differenza con la semplice riduzione della superficie d’attacco è sottile ma sostanziale: ridurre la superficie è un obiettivo, mentre il CTEM è il processo che decide quale porzione di quella superficie vada affrontata per prima, con quali risorse e con quale prova di efficacia.

Le cinque fasi del CTEM

Gartner articola il CTEM in un ciclo di cinque fasi, da percorrere in modo iterativo e non una sola volta. La forza del modello sta proprio nella ripetizione: ogni giro affina le priorità alla luce di come sono cambiati l’infrastruttura, le minacce e i controlli.

Scoping

La prima fase definisce il perimetro: quali asset, sistemi e superfici meritano attenzione continua. Gartner invita a guardare oltre i confini tipici della gestione delle vulnerabilità, includendo elementi meno tangibili come gli account social aziendali, i repository di codice online e i sistemi integrati con la catena di fornitura. Due aree fanno da terreno ideale per un primo pilota: la superficie d’attacco esterna, dal perimetro relativamente delimitato, e la postura di sicurezza delle applicazioni SaaS, diventata critica man mano che il lavoro distribuito ha spostato i dati aziendali fuori dal data center.

Discovery

La seconda fase scopre asset, vulnerabilità, configurazioni errate e altri rischi all’interno del perimetro definito. Qui si annida il primo errore ricorrente, secondo Gartner: confondere lo scoping con la discovery. Il volume di asset e falle individuati non è un successo in sé. Trovare di più non serve se non si è prima scelto bene cosa cercare in base al rischio di business e all’impatto potenziale.

Prioritizzazione

L’obiettivo della terza fase non è correggere ogni singolo problema, traguardo irraggiungibile e per giunta inutile. La prioritizzazione pesa urgenza, presenza di controlli compensativi, tolleranza per la superficie d’attacco residua e livello di rischio per l’organizzazione. Si tratta di identificare gli asset ad alto valore e concentrare il trattamento su quelli, accettando in modo consapevole che una parte del rischio resti aperta.

Validazione

La quarta fase è quella che distingue il CTEM da un esercizio teorico: verificare sul campo che le ipotesi reggano. Significa confermare che un attaccante possa davvero sfruttare una vulnerabilità, mappare i percorsi d’attacco che conducono all’asset critico e accertare che il piano di risposta sia abbastanza rapido e robusto da proteggere il business. È il terreno delle tecnologie di validazione, dalla breach and attack simulation al red teaming, spesso ancorate a una tassonomia condivisa delle tecniche avversarie come la matrice MITRE ATT&CK. La validazione trasforma una lista di rischi presunti in una mappa di rischi dimostrati.

Mobilitazione

L’ultima fase riguarda persone e processi, non strumenti. Gartner avverte che non ci si può affidare interamente alla promessa della remediation automatica: per la maggior parte delle situazioni serve che i team facciano proprie le conclusioni del programma e le traducano in azione. L’obiettivo della mobilitazione è ridurre gli attriti nelle approvazioni e nei processi di mitigazione, documentando i flussi di approvazione tra i diversi team. È la fase dove molti programmi si arenano, perché tocca le abitudini organizzative più della tecnologia.

Un programma, non un prodotto

La diffusione del CTEM ha generato un equivoco prevedibile: presentarlo come una categoria di prodotto da acquistare. Sul mercato si moltiplicano piattaforme che si autodefiniscono soluzioni CTEM, ma il CTEM non è un software. È un processo che orchestra strumenti diversi, dalla scoperta della superficie d’attacco esterna alla postura SaaS, dalla prioritizzazione basata sul rischio fino alla breach and attack simulation. Chiamare CTEM un singolo prodotto significa svuotarlo del suo contenuto, che è proprio la capacità di tenere insieme tecnologie e team attorno a un criterio unico di priorità.

La distinzione ha conseguenze pratiche. Un’organizzazione può dotarsi degli strumenti più avanzati e restare priva di un programma CTEM, se manca la fase di prioritizzazione condivisa e la mobilitazione che traduce le evidenze in interventi. Vale anche il contrario: si può avviare un CTEM credibile su un perimetro ristretto con strumenti già in casa, purché il ciclo delle cinque fasi venga percorso davvero e non solo nominato.

Cosa cambia per chi governa il rischio

Quando Gartner ha formulato il modello, ha accompagnato il CTEM con una previsione netta: entro il 2026 le organizzazioni che orientano gli investimenti di sicurezza su un programma di gestione continua dell’esposizione avrebbero avuto una probabilità tre volte minore di subire una violazione. Vale la pena leggerla per ciò che è, una proiezione e non una misura: oggi che il 2026 è arrivato, non esiste uno studio indipendente che certifichi quel rapporto specifico tra adottanti e non adottanti, e la stima va trattata come indicazione di tendenza. La logica operativa, però, resta solida: concentrare le risorse su ciò che è davvero esposto e sfruttabile riduce il rischio in modo più efficace che inseguire ogni falla.

Per chi governa la sicurezza in Italia e in Europa, il modello intercetta una pressione normativa concreta. La logica di NIS2 e di DORA, con il loro impianto di gestione del rischio continua e proporzionata, chiede esattamente ciò che il CTEM prova a sistematizzare: non un adempimento una tantum, ma un processo ricorrente di identificazione, prioritizzazione e verifica. Il legame con DORA è particolarmente stretto sulla fase di validazione: il threat-led penetration testing richiesto agli operatori finanziari mappa quasi uno a uno sulla logica di verifica avversaria del ciclo. Il CTEM non è una risposta di conformità, e non va presentato come tale, ma offre un’ossatura operativa coerente con quella direzione regolatoria.

È la stessa tensione che Jeremy D’Hoinne, VP Analyst di Gartner, pone al centro del modello. Il CTEM, osserva, è un approccio sistemico pragmatico ed efficace per raffinare di continuo le priorità e camminare sul filo tra due realtà inconciliabili della sicurezza moderna: un’organizzazione non può correggere tutto, né può essere certa di quali interventi di remediation possa rinviare senza correre un rischio. È in questa frase che il CTEM rivela la propria natura, non un metodo per eliminare il rischio ma per amministrarlo con cognizione.

Il vero ostacolo, alla fine, non è la disponibilità degli strumenti né la comprensione del metodo. È la mobilitazione, cioè la capacità di un’organizzazione di trasformare evidenze tecniche in decisioni condivise e interventi tempestivi. Per questo il CTEM va letto meno come una tecnologia e più come una disciplina di governo del rischio: sposta la domanda da quante vulnerabilità abbiamo chiuso a quanto siamo davvero meno esposti rispetto al giro precedente. È un cambio di paradigma che premia chi smette di rincorrere gli episodi e inizia a governare l’esposizione come una condizione permanente.

https://www.ictsecuritymagazine.com/articoli/ctem-continuous-threat-exposure-management/