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.

Profilo Autore

Titolare delle licenze EJPT e ECPPT (Professional Penetration Tester) della società eLearnSecurity. Svolge attività di Network Security in particolare Penetration Test & VA – Vulnerability Assessment.
Nel 2019 fonda la società ISK (www.isksecurity.it), partner strategico ed esterno per attività di Security specializzata. Svolge attività di bonifiche ambientali da microspie, attività di Security Assessment e Mobile Security.

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/

Post-incident review è il nome della fase che chiude il ciclo di vita di un incidente, il momento in cui un’organizzazione si ferma a capire cosa è successo davvero, perché, e cosa deve cambiare perché non si ripeta. È presente in ogni framework di riferimento, eppure è la parte che viene saltata, rinviata o ridotta a una formalità più di ogni altra. Una volta ripristinati i sistemi e rientrata l’emergenza, l’attenzione si sposta altrove, la pressione cala e la revisione diventa una riunione che qualcuno verbalizza senza che ne segua nulla.

Il paradosso è che si tratta della fase con il rapporto più alto tra valore e costo. Non richiede tecnologia, non richiede budget, richiede solo tempo e onestà, due risorse che dopo un incidente scarseggiano. Un attacco gestito male e mai analizzato è una spesa pura; lo stesso attacco, analizzato a fondo, diventa l’unico investimento in sicurezza che nasce da dati reali invece che da ipotesi. La differenza tra le due cose non sta negli strumenti, ma nel fatto che la revisione venga presa sul serio come disciplina, e non trattata come l’adempimento che chiude la pratica.

Dalla chiusura dell’incidente all’apprendimento

La revisione post-incidente non è un’invenzione delle aziende più mature, è un requisito codificato. Nella sua versione precedente, la guida del NIST sulla risposta agli incidenti dedicava una fase distinta all’attività successiva all’evento, con due obiettivi: ridurre la probabilità che un incidente simile si ripeta e migliorare le procedure di gestione. La revisione vigente del 2025 scioglie quella fase in un flusso continuo allineato al Cybersecurity Framework 2.0, in cui le lezioni apprese rientrano nella fase di preparazione e alimentano l’intero ciclo. Lo stesso impianto si ritrova nello standard internazionale dedicato alla gestione degli incidenti, la ISO/IEC 27035 nella versione del 2023, che colloca la fase di apprendimento delle lezioni come parte esplicita e non opzionale del processo.

La conseguenza pratica è che la revisione non chiude il ciclo, lo riavvia. Ciò che emerge da un incidente deve tornare indietro e modificare qualcosa di concreto: una regola di rilevamento, una procedura di incident response, un controllo di accesso, un percorso di formazione. Se l’analisi resta confinata in un documento che nessuno riapre, il ciclo è interrotto, e l’organizzazione si limita a collezionare incidenti senza imparare da essi. La misura della qualità di una revisione non è lo spessore del rapporto, ma il numero di cose che cambiano per effetto suo.

Post-incident review senza colpevoli: il principio blameless

C’è una ragione ricorrente per cui la revisione fallisce, ed è umana prima che tecnica: la paura. Se l’analisi di un incidente si trasforma nella ricerca del responsabile, le persone smettono di collaborare. Chi ha commesso un errore lo nasconde, chi ha visto qualcosa tace, e il quadro che emerge è ripulito e inutile. Per questo la sicurezza ha adottato un principio nato nei settori ad alto rischio come l’aviazione e la sanità, dove l’errore può essere fatale: la revisione blameless, senza colpa, codificata dall’ingegneria dell’affidabilità dei sistemi e oggi diffusa anche nella risposta agli incidenti.

Il principio è preciso e spesso frainteso. Blameless non significa assenza di responsabilità o che tutto è permesso, significa partire dal presupposto che ogni persona coinvolta abbia agito con buone intenzioni sulla base delle informazioni che aveva in quel momento. La domanda non è “chi ha sbagliato”, ma “cosa, nel sistema, ha reso possibile quell’errore e come lo rendiamo impossibile la prossima volta”. Lo spostamento è sottile ma decisivo: trasforma l’errore individuale in un difetto di processo, che è l’unico tipo di problema su cui un’organizzazione può davvero intervenire. Quando le persone sanno che parlare di un errore non porterà a una punizione ma a una correzione, l’informazione circola, e la revisione finalmente vede ciò che è accaduto.

Da lezioni ad azioni: l’unico esito che conta

La trappola più comune è confondere la revisione con la stesura di un rapporto. Un documento di analisi ben fatto contiene una sintesi, una cronologia dei fatti, l’individuazione delle cause profonde e una valutazione dell’impatto, ma nessuno di questi elementi cambia qualcosa da solo. L’unico esito che conta è l’elenco delle azioni correttive, e perché sia reale ogni azione deve avere tre attributi: un responsabile con nome e cognome, una scadenza e un criterio per dire che è stata completata. Un’azione senza responsabile non viene fatta, un’azione senza scadenza viene rimandata all’infinito, un’azione senza criterio di chiusura viene dichiarata conclusa senza esserlo.

Qui si gioca la credibilità dell’intero esercizio. La root cause analysis, l’analisi delle cause profonde, deve spingersi oltre la prima spiegazione comoda: non “un dipendente ha cliccato su un link” ma perché quel messaggio è arrivato, perché il filtro non lo ha intercettato, perché quel clic ha avuto le conseguenze che ha avuto. Ogni “perché” risale di un livello verso una causa sistemica, e si ferma quando arriva a qualcosa che l’organizzazione può effettivamente correggere. Le azioni che ne derivano vanno poi tracciate come qualsiasi altra attività, con revisioni periodiche del loro stato, altrimenti l’elenco delle lezioni apprese diventa l’elenco delle lezioni dimenticate.

Perché la revisione viene saltata, e cosa la rende possibile

Le organizzazioni non rinunciano alla revisione per cattiva volontà, ma per una combinazione di fattori prevedibili. Il primo è il tempo: a incidente chiuso, i team tornano sul lavoro arretrato e la riunione di analisi slitta finché i ricordi sbiadiscono. Per questo la prassi consolidata raccomanda di condurla a ridosso della chiusura, finché i fatti sono ancora freschi e i protagonisti disponibili. Il secondo è l’assenza di un metodo: senza un’agenda strutturata, ruoli definiti e un formato ripetibile, persino un solido piano di incident response non basta a impedire che la riunione diventi una conversazione che gira a vuoto. Il terzo, il più insidioso, è la cultura punitiva, che svuota la revisione dall’origine trasformandola in un processo difensivo.

C’è infine un fraintendimento di fondo, quello di riservare la revisione solo agli incidenti gravi. Anche i quasi-incidenti, gli eventi minori contenuti prima di degenerare, contengono informazioni preziose proprio perché mostrano cosa ha funzionato, e analizzarli a freddo costa poco. Un’organizzazione che impara solo dai disastri impara poco e tardi. La post-incident review, in definitiva, è il punto in cui la sicurezza smette di essere una sequenza di reazioni e diventa un sistema che si corregge: non l’ultimo atto burocratico di un incidente, ma il primo atto della difesa contro il prossimo. Le aziende che escono più forti da un attacco non sono quelle che lo hanno gestito meglio, ma quelle che, dopo, hanno avuto il coraggio di guardarlo in faccia e cambiare qualcosa.

https://www.ictsecuritymagazine.com/articoli/post-incident-review-lessons-learned/

Sintesi dell’intervento di Luca Cadonici (Digital Forensics Expert, Cyber Security & Mobile Forensics Lecturer) alla 14ª Cyber Crime Conference, Auditorium della Tecnica, Roma, 7 maggio 2026.

A chiudere i lavori della seconda giornata della 14ª Cyber Crime Conference, Luca Cadonici, co-fondatore di Secure Path LTD, docente di Cyber Security all’Università degli Studi di Perugia e all’European Forensic Institute di Malta, membro ONIF e contributor de L’Europeista, ha proposto una ricostruzione integrale del caso Graphite. Una vicenda che, nelle sue parole, ha tutti i tratti di una spy story: non solo per la sofisticazione tecnica dello spyware impiegato, ma anche per le domande, in larga parte ancora aperte, sul perimetro normativo ed etico entro cui si è mossa l’attività di sorveglianza.

Spyware Graphite, l’innesco mediatico: 31 gennaio 2025

La cronologia del caso si apre nel primo pomeriggio del 31 gennaio 2025, quando alle 14:55 e alle 15:21 Reuters rilancia, citando un funzionario di Meta, che circa 90 utenti WhatsApp in oltre venti Paesi, fra cui giornalisti e membri della società civile, sono stati bersaglio di uno spyware prodotto dalla società israeliana Paragon Solutions, specializzata in software di sorveglianza di tipo governativo. WhatsApp dichiara di aver neutralizzato la campagna e di aver indirizzato i bersagli al Citizen Lab dell’Università di Toronto. Meta non rivela né l’identità dei target né la metodologia che le ha consentito di attribuire l’attacco a Paragon.

Le caratteristiche dell’attacco emergono fin da subito: gli utenti venivano inseriti in chat di gruppo WhatsApp, all’interno delle quali veniva inviato un PDF malevolo capace di innescare un exploit zero-click, ossia senza alcuna interazione della vittima. Alle 17:11 The Guardian conferma che i target sono stati allertati direttamente da Meta. Alle 20:52, Fanpage.it pubblica la notizia che il proprio direttore, Francesco Cancellato, ha ricevuto la notifica di sicurezza.

Le vittime italiane

Nei giorni successivi la lista dei bersagli italiani prende forma. Oltre a Cancellato, vengono indicati pubblicamente Luca Casarini, Giuseppe Caccia e don Mattia Ferrari, tutti riconducibili alla ONG Mediterranea Saving Humans, attiva nel soccorso ai migranti, e David Yambio, rifugiato sud-sudanese in Italia, presidente dell’associazione Refugees in Libya. L’11 febbraio Yambio rende noto di aver ricevuto già il 13 novembre 2024 una notifica analoga da parte di Apple, che lo informava di un “mercenary spyware attack” indirizzato all’iPhone associato al suo Apple ID, “probabilmente per ciò che sei o per ciò che fai”.

La rescissione del contratto

Il 6 febbraio 2025 The Guardian riporta che Paragon ha chiuso il contratto con l’Italia. Il fatto stesso che un contratto esistesse è la prima informazione realmente rilevante: significa che Graphite era in uso a un’autorità italiana. Paragon, infatti, sostiene di vendere soltanto a entità governative (forze dell’ordine, procure, agenzie di intelligence) e di applicare clausole contrattuali che vietano il targeting di giornalisti e attivisti per i diritti umani. La rescissione viene motivata proprio con la violazione di tali clausole.

L’indagine del COPASIR

Il Comitato parlamentare per la sicurezza della Repubblica, presieduto da Lorenzo Guerini, conduce fra il 4 gennaio e il 4 giugno 2025 otto audizioni e dieci sessioni interne, oltre a quattro sopralluoghi presso DIS, AISI, AISE e Procura Generale presso la Corte di Appello di Roma. L’obiettivo è stabilire chi, in Italia, utilizzasse Graphite.

Vengono escluse rapidamente il Dipartimento dell’Amministrazione Penitenziaria, la Procura Nazionale Antimafia e Antiterrorismo, i Carabinieri, la Guardia di Finanza e la Polizia di Stato. Paragon stessa conferma di aver avuto rapporti contrattuali solo con le agenzie di intelligence.

AISE ha firmato il contratto il 13 dicembre 2023 e attivato il sistema il 23 gennaio 2024 sulla piattaforma iOS, e l’8 febbraio 2024 su Android. L’uso dello spyware è stato dichiarato in relazione a contrasto all’immigrazione illegale, fugitive tracking, contrabbando di carburante, controspionaggio, antiterrorismo, criminalità organizzata e sicurezza interna, sempre con autorizzazione del Procuratore Generale presso la Corte di Appello di Roma, su numeri estremamente limitati di utenti.

AISI ha utilizzato Graphite dal 2023, con contratto in scadenza il 7 novembre 2025. Nel suo caso il COPASIR documenta due tipologie di attività: l’intercettazione dinamica di comunicazioni in tempo reale (autorizzata dal Procuratore Generale presso la Corte di Appello di Roma) e l’esfiltrazione di chat già memorizzate sui dispositivi target, condotta ai sensi dell’art. 18, comma 2, della Legge 124/2007, che consente al personale dei Servizi di compiere atti altrimenti costituenti reato previa autorizzazione del Presidente del Consiglio o dell’autorità delegata, tipicamente il Sottosegretario all’intelligence.

La policy del fornitore e i suoi limiti

Paragon Solutions, ha ricordato Cadonici, fornisce i propri servizi solo a entità statali che garantiscano tutela dei diritti umani e libertà civili. Il contratto vieta espressamente il targeting basato su religione, sesso, etnia, orientamento sessuale, e proibisce di colpire giornalisti e attivisti dei diritti umani, esattamente il profilo di alcune delle vittime accertate.

Esiste poi un dettaglio particolarmente significativo: la licence di Graphite esclude da possibili bersagli i numeri telefonici di alcuni Paesi, ma non quelli italiani. In altre parole, Paragon può legittimamente, secondo i propri termini contrattuali, vendere o noleggiare il software ad agenzie di intelligence estere che colpiscano utenze italiane. L’Italia è cliente e, contemporaneamente, possibile bersaglio.

La licenza italiana, secondo quanto verificato dal COPASIR, presenta inoltre alcune restrizioni operative significative: non consente l’attivazione remota di microfono e fotocamera, la sorveglianza ambientale in tempo reale, né l’accesso alla galleria fotografica. Sono invece consentite l’intercettazione di comunicazioni in transito su piattaforme di messaggistica cifrata, ai sensi del D.L. 144/2005, e l’estrazione di chat residenti in memoria, ai sensi dell’art. 18 della L. 124/2007.

Il meccanismo di infezione e la dashboard

Il vettore di infezione è stato identificato come la vulnerabilità CVE-2025-27363, che non risiedeva nei server WhatsApp ma veniva innescata dall’anteprima del PDF malevolo inviato in chat di gruppo. La falla è stata individuata l’11 dicembre 2024 e completamente patchata il 17 dicembre 2024, neutralizzando ogni ulteriore sfruttamento da parte di Paragon o dei suoi clienti.

Graphite opera in background, esfiltra dati verso un server di Command and Control (C2) posizionato presso il cliente, richiede autenticazione dell’operatore per ogni azione e registra ogni operazione su un database (cancellabile dal cliente, contenente i dati esfiltrati) e su un audit log (non cancellabile dal cliente, accessibile a Paragon a fini di accountability).

Curiosa la circostanza, riportata da Cadonici, che il volto stesso della segretissima dashboard di Graphite sia stato svelato per errore: nel febbraio 2026 il General Counsel di Paragon Solutions ha caricato, e poco dopo rimosso, su LinkedIn uno screenshot del pannello di controllo. L’immagine, ha osservato Cadonici, mostra un’interfaccia non dissimile da quella dei comuni software di mobile forensics, con l’identificazione del numero target, un singolo comando Intercept, indicatori di stato in tempo reale e accesso a inventario applicazioni, account e log di messaggistica con conversazioni leggibili.

Le conclusioni del COPASIR e l’indagine delle procure

La relazione del COPASIR, approvata il 4 giugno 2025, accerta che l’uso di Graphite da parte dell’AISI ha riguardato Luca Casarini e Giuseppe Caccia, monitorati dal 2019 in due distinte operazioni, con Graphite impiegato a partire dal settembre 2024 nella seconda operazione, finalizzata, ufficialmente, alla prevenzione di attività di favoreggiamento dell’immigrazione clandestina e non al monitoraggio dell’attivismo per i diritti umani. Per Cancellato, don Ferrari e Yambio, il Comitato non ha rinvenuto alcuna attività intercettiva tramite Graphite da parte dei Servizi italiani. Yambio risulta oggetto di una intercettazione tradizionale (non spyware) su un’utenza intestata a don Ferrari ma da lui effettivamente utilizzata.

Sul caso Cancellato, i parlamentari hanno accesso diretto al database e all’audit log di Paragon presso le agenzie, hanno inserito il numero del giornalista nel sistema e non hanno trovato evidenze di intercettazione, né richieste o decreti di autorizzazione presso DIS o Procura Generale di Roma.

A marzo 2026, una consulenza tecnica disposta dalle procure di Roma e Napoli, coordinate dalla Procura Nazionale Antimafia e Antiterrorismo, e affidata a specialisti della Polizia Postale e a un collegio di docenti universitari, ha rilevato tracce di compromissione compatibili con Graphite nei database WhatsApp dei dispositivi Android di Cancellato, Caccia e Casarini. Tutti e tre gli attacchi sono datati alle prime ore del 14 dicembre 2024, in una sequenza ravvicinata che suggerisce una campagna coordinata. L’ispezione sul server Graphite in uso all’AISI ha confermato le operazioni nei confronti di Caccia e Casarini, ma non ha rilevato tracce riferibili a Cancellato. Allo stato, dunque, l’identità di chi ha attaccato il direttore di Fanpage resta ignota.

Il caso Pellegrino e il cluster Fanpage

Il quadro si complica ulteriormente con il caso di Ciro Pellegrino, giornalista di Fanpage e stretto collaboratore di Cancellato. Il 29 aprile 2025 un gruppo selezionato di utenti iOS ha ricevuto una notifica di Apple relativa a un attacco spyware avanzato. Il Citizen Lab, in un report di giugno 2025, ha confermato con alta confidenza il targeting di Pellegrino e di un secondo giornalista europeo (anonimo) tramite Graphite, sfruttando un exploit zero-click via iMessage corrispondente alla vulnerabilità CVE-2025-43200, poi corretta in iOS 18.3.1.

Entrambi i casi sono stati ricondotti alla medesima infrastruttura operativa e allo stesso account iMessage attaccante, denominato ATTACKER1, oltre che a un fingerprint P1 costituito da un pattern anomalo di certificati TLS self-signed attribuito con alta confidenza a Graphite dal Citizen Lab nelle indagini di marzo 2025. È quindi il secondo giornalista di Fanpage colpito da Graphite: un cluster che, secondo gli elementi emersi, configura una campagna mirata contro la redazione del giornale.

Un caso reale di advanced spyware activity

Cadonici ha quindi presentato un caso reale analizzato dalla sua azienda, Secure Path LTD, tramite la soluzione di rilevazione Smartscan, condotto su un Samsung Galaxy S25 Ultra con Android 16. L’analisi, basata su un PCAP di circa 597 MB e su una finestra sospetta di circa 10 minuti, ha portato a ipotizzare attività di spyware di livello alto.

L’attacco è multicanale e Living off the Land: per il canale di Command and Control sfrutta connessioni verso c.whatsapp.net
sull’indirizzo 157.240.231.61:80
, con metodi HTTP POST /chat
e user-agent WAChat/1.2
, senza SNI, veicolando payload cifrati o offuscati su porta 80, ovvero su un canale normalmente in chiaro. in chiaro che agli occhi di un detection di rete appare come comunicazione legittima verso l’infrastruttura Meta.

L’esfiltrazione, invece, non viene veicolata verso il C2: i dati vengono caricati su servizi Google legittimi (
backup.googleapis.com
per circa 17,5 MB, people-pa.googleapis.com
per circa 786 KB), per essere poi recuperati dall’attaccante via token. Una architettura a due canali (C2 su Meta, esfiltrazione su Google) che ottiene un’evasione molto efficace appoggiandosi a trusted services il cui traffico è, per definizione, indistinguibile dal normale uso del dispositivo.

Mitigazione del rischio

Il mercato mobile è essenzialmente Apple e Android: conoscere le rispettive contromisure è quindi cruciale. Su iOS, il Lockdown Mode (da iOS 16) blocca la maggior parte degli allegati non immagine, disabilita le anteprime dei link e la compilazione JIT del browser, blocca inviti FaceTime da contatti sconosciuti e impedisce l’installazione di profili di configurazione o l’enrollment MDM. Su Android, dalla versione 16, il Google Advanced Protection introduce un toggle di hardening a livello di OS: Chrome in modalità HTTPS-only con disattivazione degli ottimizzatori JavaScript più rischiosi, Messages safeguards contro phishing e scam, Play Protect non disattivabile, blocco del sideload da fonti sconosciute e attivazione della Memory Tagging Extension sui chip compatibili.

Cadonici ha citato tre casi storici neutralizzabili oggi proprio da questi accorgimenti: i watering hole contro iOS del 2019 (campagne Poison Carp e EvilBamboo contro la diaspora tibetana e uigura), bloccati dalla disattivazione del JIT in Lockdown Mode; il FORCEDENTRY di Pegasus del 2021, exploit iMessage zero-click via PDF/JBIG2, neutralizzato dal blocco di allegati non-immagine e anteprime; e la campagna FluBot del 2021 su Android, che oggi sarebbe contenuta dal blocking del sideload da APK non firmate e dai warning sui link sospetti.

Il nodo giuridico: corrispondenza in transito e corrispondenza memorizzata

Cadonici ha quindi evidenziato quella che il COPASIR stesso definisce una contraddizione dell’attuale quadro normativo italiano. Le intercettazioni preventive condotte dai Servizi per finalità di sicurezza nazionale (D.L. 144/2005, convertito nella L. 155/2005) e quelle giudiziarie nei procedimenti penali (artt. 266-268 c.p.p.) richiedono autorizzazione giudiziaria, rispettivamente del Procuratore Generale presso la Corte di Appello di Roma e del GIP su richiesta del PM, in attuazione dell’art. 15 della Costituzione, che tutela la libertà e la segretezza della corrispondenza.

L’esfiltrazione tramite spyware di dati memorizzati sul dispositivo, invece, ricade oggi sotto l’art. 18, comma 2, della L. 124/2007 e richiede solo l’autorizzazione dell’esecutivo, ovvero del Presidente del Consiglio o dell’autorità delegata, senza alcun controllo giurisdizionale. Una asimmetria non da poco: significa che, a parità di contenuto, due messaggi attraversati dallo stesso interesse investigativo possono ricevere garanzie costituzionali del tutto diverse a seconda del momento in cui vengono acquisiti.

La sentenza n. 170/2023 della Corte costituzionale ha però già chiarito che anche i messaggi memorizzati su dispositivi mobili e di interesse attuale per il titolare costituiscono “corrispondenza”, ricadendo quindi sotto le garanzie dell’art. 15. È su questo terreno, ha sottolineato Cadonici riprendendo il COPASIR, che si misura la necessità di un intervento del legislatore: per evitare che l’esfiltrazione di dati possa avvenire al di fuori dell’ordinario perimetro di garanzia giurisdizionale.

Spyware fra diritto ed etica

In chiusura, Cadonici ha richiamato il piano etico. Graphite, ha ricordato, si è mosso in un contesto formalmente legale: intercettazioni preventive autorizzate, attività intrusive autorizzate. Eppure la stessa operazione può finire per coinvolgere attivisti per i diritti umani, ONG attive nel soccorso in mare o in contesti migratori, giornalisti che indagano sull’operato del Governo. Si pongono allora questioni di proporzionalità, purpose limitation e rischio di function creep: il confine tra sospetto e attivista, tra sicurezza e dissenso, è molto sottile e tende a spostarsi nel tempo.

Cadonici ha citato anche scenari internazionali, come quello dei giornalisti indiani critici dell’esecutivo sorvegliati con software analoghi: anche democrazie consolidate possono trovarsi a fare un uso problematico di questi strumenti. Da qui l’invito a portare la discussione sullo spyware di livello statale al centro del dibattito pubblico, definendone limiti legali più chiari, sottoponendolo a un controllo democratico costante e creando le condizioni perché una misura legalmente autorizzata non diventi, di fatto, eticamente inaccettabile.

Guarda il video completo dell’intervento di Luca Cadonici (Digital Forensics Expert, Cyber Security & Mobile Forensics Lecturer) alla Cyber Crime Conference 2026:

https://www.ictsecuritymagazine.com/articoli/spyware-graphite-spionaggio/

Data Security Posture Management (DSPM) nasce da una domanda che molte organizzazioni scoprono di non saper rispondere con precisione: dove si trovano, in questo momento, i dati sensibili che devono proteggere, chi può accedervi e quanto sono esposti. È una domanda apparentemente banale che diventa insidiosa non appena i dati smettono di vivere in pochi database controllati e si spargono tra cloud diversi, ambienti SaaS, copie di test e set di addestramento per modelli di AI. Il termine è stato introdotto da Gartner nel 2022 e indica una categoria di mercato prima ancora che una tecnologia definita da uno standard: va quindi letto per la funzione che descrive, non come un’etichetta di prodotto.

Il punto di vista è il tratto che distingue questa disciplina dagli strumenti di postura più noti. La sicurezza tradizionale osserva dispositivi, reti e configurazioni, poi prova a dedurre dove sia il rischio per i dati. Un approccio data-first rovescia la sequenza: parte dal dato, ne segue le copie e i movimenti, e solo dopo valuta la superficie che lo espone. Non sostituisce le difese perimetrali, ma colma un angolo cieco che quelle difese, da sole, non illuminano.

Dal perimetro al dato: perché cambia il punto di osservazione

La proliferazione del multicloud ha reso normale ciò che dieci anni fa era un’eccezione: lo stesso dato sensibile replicato in ambienti gestiti da team, policy e provider differenti. Un data lake alimentato per analisi, un bucket creato per un progetto pilota e mai dismesso, un database di collaudo popolato con dati di produzione reali. Ognuna di queste copie è un’esposizione potenziale, e nessuna compare nell’inventario ufficiale se qualcuno non va a cercarla.

Da qui l’idea centrale: non si può proteggere ciò che non si sa di avere. Prima della cifratura, della tokenizzazione o del mascheramento, che agiscono su dati già individuati, serve sapere quali dati esistono, di che natura sono e in quali condizioni si trovano. È lo scarto rispetto ai controlli che presidiano il singolo archivio noto, e la ragione per cui la mappatura viene prima della protezione.

Come funziona il Data Security Posture Management

Il Data Security Posture Management lavora in modo continuo e si articola, secondo le definizioni più diffuse, in quattro momenti concatenati. Il primo è la data discovery: una scansione ricorrente degli ambienti on-premise e cloud per localizzare gli archivi che contengono dati sensibili, compresi quelli non censiti. Il secondo è la classificazione, che ordina i dati per grado di sensibilità, modalità di conservazione, permessi di accesso e vincoli normativi, dal GDPR al PCI DSS fino alle regole di settore.

Segue la valutazione della postura e del rischio, dove emergono le configurazioni errate, i permessi eccessivi, i flussi di dati anomali e le potenziali violazioni di conformità. Non è solo un elenco: la fase include l’assegnazione di una priorità per gravità, che è ciò che distingue un inventario da uno strumento di lavoro. L’ultimo momento è la remediation: la correzione, dove possibile automatizzata, delle esposizioni individuate, insieme al monitoraggio che riporta il ciclo al punto di partenza.

Vale una nota sul come: questi strumenti sono tipicamente agentless, non richiedono cioè di installare software su ogni risorsa monitorata, ed è la ragione per cui promettono di coprire ambienti che nessun inventario manuale riuscirebbe a inseguire. La sequenza conta più delle singole fasi, perché trasforma un controllo occasionale in un presidio ricorrente sulla condizione reale dei dati.

Shadow data, il problema che questa disciplina rende visibile

Il concetto che meglio spiega il valore di questo approccio è quello di shadow data: copie di informazioni finite in archivi non sorvegliati dagli stessi team e dalle stesse policy che proteggono gli originali. Si generano nei modi più ordinari, spesso legittimi. Un flusso DevOps che duplica un ambiente, un progetto di machine learning che estrae un campione per l’addestramento, una migrazione tra cloud che lascia residui. Nessuna di queste operazioni è un attacco, eppure ciascuna può creare un archivio sensibile che nessuno sta guardando.

Gli shadow data sono difficili da governare proprio perché sfuggono all’inventario. Rendere visibile ciò che era invisibile è la funzione più concreta di questi strumenti, e la premessa di qualunque riduzione seria dell’esposizione. Senza quella visibilità, le metriche di rischio raccontano solo la parte di realtà che era già nota.

DSPM, CSPM e CNAPP: livelli complementari, non alternativi

Una fonte frequente di confusione è la sovrapposizione con le sigle vicine. Il CSPM presidia la configurazione dell’infrastruttura cloud nella logica del cloud posture management, il CNAPP consolida in un’unica piattaforma la protezione di infrastruttura e carichi di lavoro, mentre il DSPM opera un livello più in profondità, sul dato in sé. Sono strati diversi della stessa superficie: chi ha già impostato la logica di un CNAPP ottiene visibilità sull’infrastruttura, ma non necessariamente sul contenuto sensibile che quell’infrastruttura ospita. Che si tratti di una categoria di mercato affollata lo dice il censimento dei prodotti che si presentano sotto questa etichetta, oltre cinquanta, dai puri specialisti alle piattaforme di cloud security che vi hanno aggiunto un modulo.

Vale la pena distinguere anche rispetto a controlli spesso citati insieme. La tokenizzazione e il mascheramento proteggono dati già identificati, l’SSPM misura la postura delle applicazioni SaaS: nessuno dei due risponde alla domanda su dove si trovino i dati sensibili e quanto siano esposti. È lì che si colloca il perimetro proprio del Data Security Posture Management, che completa gli altri strumenti invece di rimpiazzarli.

Dal governo della postura al minimo privilegio sul dato

Sapere dove sono i dati serve a poco se non si traduce in decisioni sugli accessi. Uno degli esiti più utili di questi strumenti è la fotografia dei permessi effettivi: quanti account possono leggere un archivio sensibile, con il peso crescente delle identità non umane come service account, chiavi e token, e quanti di quei permessi sono in eccesso rispetto al bisogno reale. È il terreno su cui il governo della postura incontra il principio del minimo privilegio, cardine di ogni modello Zero Trust: ridurre l’overpermissioning sui dati abbassa l’impatto potenziale di una credenziale compromessa.

Su questo confine si colloca anche l’integrazione con altri controlli. L’incrocio con i sistemi di Data Loss Prevention arricchisce l’analisi dei flussi, mentre la convergenza verso approcci di Data Detection and Response punta a colmare la distanza tra la fotografia statica della postura e il rilevamento di ciò che accade ai dati in tempo reale. Sono direzioni di sviluppo del mercato, da osservare con la cautela dovuta a categorie ancora in assestamento, non come funzioni garantite di ogni soluzione.

Cosa aspettarsi, senza illusioni

Adottare un Data Security Posture Management non elimina il lavoro difficile della sicurezza del dato: lo rende affrontabile, perché lo àncora a un inventario reale invece che a un’ipotesi. Il ritorno più tangibile non è un cruscotto in più, ma la capacità di rispondere con dati alla mano a domande che prima ricevevano stime: quali informazioni sensibili sono esposte, dove, e con quale priorità intervenire.

Le indicazioni su diffusione e maturità del mercato restano stime di analisti, da trattare come tali; ciò che è verificabile è il vuoto che questa disciplina copre, cioè la distanza tra i dati che un’organizzazione crede di avere sotto controllo e quelli che ha davvero. Ridurre quella distanza è il primo passo concreto verso una postura del dato difendibile.

https://www.ictsecuritymagazine.com/articoli/data-security-posture-management-dspm/

Disaster recovery e business continuity vengono spesso usati come sinonimi, ma indicano due cose distinte, e confonderle è il primo passo verso un ripristino che non regge alla prova dei fatti. La business continuity è l’obiettivo: tenere operative le funzioni essenziali di un’organizzazione mentre un evento avverso è in corso. Il disaster recovery è uno dei mezzi per raggiungerlo, la parte che riguarda il recupero dei sistemi informativi e dei dati dopo un’interruzione. Il primo è un problema di organizzazione, il secondo un problema di tecnologia, e l’errore ricorrente è trattare il secondo come se esaurisse il primo.

La distanza tra avere un piano e avere un piano che funziona si misura su due numeri: quanto a lungo l’organizzazione può restare ferma e quanto lavoro recente può permettersi di perdere. Sono il Recovery Time Objective e il Recovery Point Objective, RTO e RPO. Quasi tutto il valore di una strategia di continuità si concentra qui, e quasi tutti gli errori nascono dal modo in cui questi due valori vengono fissati: scelti dall’IT per comodità tecnica invece che derivati dall’impatto sul business, scritti su un documento e mai verificati con una prova reale.

Due piani, un solo obiettivo

La gerarchia tra i due concetti non è una sottigliezza terminologica, perché definisce chi decide cosa. La guida del NIST sul contingency planning descrive una suite di piani coordinati: il piano di continuità operativa fa da quadro generale e il disaster recovery è uno dei piani operativi della suite, dedicato al ripristino dei sistemi a supporto delle funzioni critiche. Accanto al disaster recovery convivono altri piani: la gestione della crisi, la comunicazione, la continuità delle operazioni. Vederli come un insieme coordinato, e non come documenti separati che vivono in cassetti diversi, è la differenza tra una risposta governata e una somma di reazioni scollegate.

Questa distinzione ha una conseguenza pratica immediata. Il disaster recovery risponde alla domanda tecnica: come riporto in funzione server, applicazioni e dati. La business continuity risponde a una domanda più ampia, quella che dà forma al piano di continuità operativa: quali processi devono restare in piedi, in quale ordine, con quali risorse alternative anche non informatiche. Un’organizzazione che ha costruito un solido piano di disaster recovery ma non ha definito le priorità di business si ritrova a ripristinare con efficienza sistemi che, in quel momento, non sono i più urgenti da riavere.

Disaster recovery senza metriche è solo una speranza

Il punto in cui i due piani si saldano sono gli obiettivi di ripristino, e qui conta la precisione. Il Recovery Time Objective è il tempo massimo entro cui un processo deve tornare operativo prima che il danno diventi inaccettabile. Il Recovery Point Objective è la quantità massima di dati che si può accettare di perdere, espressa come finestra temporale: un RPO di un’ora significa che, nel caso peggiore, si torna alla situazione di sessanta minuti prima dell’incidente. Sopra entrambi sta il Maximum Tolerable Period of Disruption, il periodo oltre il quale l’interruzione produce conseguenze irreversibili; l’RTO deve restare al di sotto di questa soglia, con un margine di sicurezza.

Questi valori non si inventano e non li sceglie il reparto tecnico in base a ciò che è comodo realizzare. Lo standard internazionale dedicato alla continuità operativa, la norma ISO 22301 nella versione del 2019, li fa discendere dall’analisi di impatto sul business, la business impact analysis, che misura per ciascuna attività il danno prodotto dal tempo di fermo. È da quel danno, non dalla disponibilità di un sito secondario, che derivano l’RTO e l’RPO. Invertire l’ordine, fissare gli obiettivi a partire da ciò che l’infrastruttura già consente, è l’errore che svuota di senso l’intero esercizio: si ottengono numeri raggiungibili ma scollegati da quanto l’organizzazione può davvero tollerare.

L’RPO, in particolare, è un requisito travestito da metrica. Dichiarare un RPO di quindici minuti e affidarsi a un backup notturno è una contraddizione che resta invisibile finché non arriva l’incidente, momento in cui ci si accorge che si sono persi non quindici minuti ma un’intera giornata di lavoro. La frequenza con cui si copiano o si replicano i dati deve discendere dall’RPO, non il contrario.

L’orologio normativo: ripristino e backup non sono più facoltativi

Per anni la continuità operativa è stata trattata come buona pratica, qualcosa che si faceva se restavano tempo e budget. Quella stagione è finita, perché il quadro regolatorio europeo l’ha trasformata in obbligo con requisiti verificabili. La direttiva NIS2, all’articolo 21, include esplicitamente tra le misure minime di gestione del rischio la continuità operativa, citando la gestione del backup, il ripristino in caso di disastro e la gestione delle crisi. Non è più una raccomandazione: è una delle condizioni a cui i soggetti essenziali e importanti devono conformarsi.

Per il settore finanziario il vincolo è ancora più dettagliato. Il regolamento DORA, applicabile dal gennaio 2025, impone all’articolo 11 una politica di continuità operativa ICT con piani di risposta e ripristino da testare almeno una volta l’anno, e all’articolo 12 politiche di backup che specifichino perimetro e frequenza minima in base alla criticità dei dati, con verifiche periodiche delle procedure di ripristino e controlli sull’integrità dei dati recuperati. Il messaggio comune alle due norme è netto: non basta possedere i piani, occorre dimostrarne il funzionamento con prove documentate. La continuità diventa così un processo misurabile, non una dichiarazione di intenti.

Perché i piani falliscono quando servono

I piani di continuità raramente falliscono per assenza. Falliscono perché non sono mai stati messi alla prova nelle condizioni che dovrebbero affrontare. Il caso più frequente è il disallineamento tra obiettivi dichiarati e capacità reali: un RTO di quattro ore che presuppone un failover automatico mai eseguito davvero, o un sito di ripristino che esiste sulla carta ma non è mai stato attivato sotto carico. Un secondo errore è ignorare le dipendenze: si ripristina l’applicazione critica ma non il servizio di autenticazione, la rete o il sistema da cui dipende, e il ripristino si blocca su un anello trascurato della catena.

C’è poi un punto cieco che riguarda proprio i dati. Le strategie di ripristino moderne danno per scontato di poter contare su una copia integra da cui ripartire, ma un ransomware che cifra anche i backup azzera questa premessa, ed è la ragione per cui la difesa del dato si è spostata verso copie immutabili e isolate. Infine, il fattore che pesa più di ogni tecnologia è la prova: un piano testato una volta all’anno in modo realistico, con tempi cronometrati e scenari plausibili, vale più di una documentazione perfetta mai esercitata. È nella prova che si scopre se l’RTO dichiarato è raggiungibile o è solo un numero gradevole su una slide.

Disaster recovery e business continuity, in conclusione, non si giudicano dallo spessore del piano ma dalla fedeltà dei suoi numeri alla realtà dell’organizzazione. Le aziende che si rialzano in fretta da un’interruzione non sono quelle con la documentazione più curata, ma quelle che hanno fissato RTO e RPO a partire dall’impatto sul business, li hanno tradotti in scelte tecniche coerenti e li hanno verificati prima che servissero. La continuità non è ciò che si scrive quando tutto funziona: è ciò che resta in piedi quando smette di funzionare.

https://www.ictsecuritymagazine.com/articoli/disaster-recovery-business-continuity-rto-rpo/

Questo contributo si inserisce in una serie di approfondimenti dedicati al tema della gestione del rischio informatico in ambito sanitario come misura tecnico-organizzativa di conformità normativa. In questo articolo, l’attenzione si concentra sul ruolo della gestione del rischio nella gestione del documento informatico, analizzando come la corretta formazione, gestione e conservazione dei documenti digitali rappresentino un elemento essenziale per garantire sicurezza, conformità normativa e continuità operativa nel settore sanitario. L’approfondimento introduce i principali riferimenti normativi, le logiche della dematerializzazione e i processi di gestione documentale nel contesto della trasformazione digitale.

Gestione del documento informatico: definizione e rilevanza giuridica

Il documento informatico viene definito come “la rappresentazione digitale di atti, fatti o dati aventi rilevanza giuridica^[1]”. In questa prospettiva, il documento può essere inteso come un’entità idonea a rappresentare un fatto dotato di rilevanza giuridica, ovvero come qualsiasi elemento capace di rendere conoscibile un fatto, che è una persona e non un oggetto rappresentativo.

In tale concezione emergono alcuni profili di evidente innovazione rispetto alla nozione tradizionale di documento. In particolare, il documento non si configura più come una realtà materiale, bensì come un’entità immateriale, caratterizzata da una natura informatica. Inoltre, la sua funzione rappresentativa non si limita alla mera attestazione di fatti o atti giuridici, ma si estende alla rappresentazione di dati, assumendo così una portata conoscitiva più ampia e articolata^[2].

Si distingue a questo punto, oltre che dalla semplice nozione di “file”^[3], anche dal documento analogico, inteso, invece, come la raffigurazione non digitale dei medesimi contenuti giuridicamente significativi.

Sulla base delle “Linee Guida^[4] sulla formazione, gestione e conservazione dei documenti informatici”^[5], tutte le pubbliche amministrazioni sono obbligate a adeguare i propri sistemi di gestione documentale e questo comporta un’estensione del concetto tradizionale di documento, che oggi ricomprende anche elementi normalmente non percepiti come tali: ad esempio registrazioni digitali, e-mail non certificate, messaggi di chat e, più in generale, ogni traccia informatica prodotta nel corso delle attività online. Perciò, ‹‹in quella che definiamo “amministrazione pubblica digitale”, accanto ai documenti cartacei trovano posto i documenti informatici, anche sottoscritti con firma digitale, che seguono canali di comunicazione differenti e sono prodotti con strumenti di vario genere^[6]››.

Per affrontare il tema sotto il profilo giuridico, oltre a far riferimento all’articolo 20 del CAD^[7] comma 1 e al d.lgs. 82 del 2005, bisogna menzionare anche il Regolamento (UE) n. 910/2014 (eIDAS^[8]), che rappresenta il quadro normativo europeo in materia di identificazione elettronica e servizi fiduciari digitali. In particolare, l’articolo 46^[9] stabilisce che a un documento elettronico non può essere negata efficacia giuridica né ammissibilità come mezzo di prova in giudizio esclusivamente a causa della sua forma elettronica, sottolineando i profili inerenti alla generazione e alla memorizzazione su supporto digitale di documenti con contenuto testuale, visivo o audiovisivo^[10].

La caratteristica digitale del documento emerge chiaramente dalla disciplina contenuta nel codice dell’amministrazione digitale e, in particolare, dall’art. 40, che, pur rivolgendosi espressamente alle pubbliche amministrazioni, contribuisce a definire in via generale la nozione di documento informatico come atto formato mediante strumenti informatici nel rispetto delle regole tecniche previste dall’art. 71 del CAD^[11]. In questo senso, il documento informatico è tale non solo per il suo contenuto, ma soprattutto per le modalità con cui viene creato sin dall’origine.

Le regole tecniche che disciplinano la formazione del documento informatico sono state adottate, inoltre, con il DPCM 13 novembre 2014, entrato in vigore nel febbraio 2015, e sono rimaste applicabili anche oltre il termine inizialmente previsto per l’adeguamento delle amministrazioni, successivamente sospeso dal legislatore. Tale sospensione, finalizzata all’aggiornamento delle regole tecniche in coerenza con le modifiche introdotte dal d.lgs. 179/2016 e dal regolamento eIDAS, ha tuttavia prodotto un rallentamento nel processo di piena attuazione del principio del digital first^[12], pur senza incidere sulla vigenza delle disposizioni tecniche esistenti.

Dematerializzazione e trasformazione digitale nella PA

La disciplina tecnica si concentra, innanzitutto, sulle modalità di formazione del documento informatico, che può avvenire attraverso la redazione diretta mediante software, l’acquisizione di documenti informatici già esistenti o la trasformazione di documenti analogici in formato digitale, nonché tramite la registrazione automatica di dati derivanti da processi informatici o dall’aggregazione strutturata di informazioni provenienti da banche dati interoperabili. L’analisi complessiva delle norme mostra come il legislatore attribuisca un ruolo centrale al documento nativamente digitale, mentre per i documenti ottenuti mediante acquisizione o aggregazione sia necessario adottare ulteriori misure tecniche e organizzative idonee a garantirne l’integrità e l’immodificabilità.

Le regole tecniche non si limitano, tuttavia, a disciplinare la fase genetica del documento, ma anticipano requisiti minimi funzionali alla sua corretta gestione nel tempo, in vista della conservazione. Emblematica, in tal senso, è la previsione dei metadati obbligatori, intesi come informazioni descrittive essenziali per identificare il documento, collocarlo nel suo contesto e assicurarne la gestione all’interno dei sistemi di conservazione. La centralità dei metadati mette in luce anche rilevanti criticità applicative, in particolare nel processo civile telematico, dove una gestione non sempre accurata di tali informazioni rischia di compromettere la qualità e l’affidabilità del documento informatico.

Il collegamento strutturale tra formazione del documento e conservazione emerge ulteriormente dalle disposizioni che regolano il trasferimento dei documenti nei sistemi di conservazione e la predisposizione del pacchetto di versamento, che rappresenta il primo passaggio del procedimento conservativo. Ciò conferma come la disciplina del documento informatico sia concepita in modo unitario, secondo una logica che integra fin dall’origine le esigenze di autenticità, integrità e durata nel tempo.

In questo quadro, il processo di digitalizzazione della pubblica amministrazione e della giustizia non può non prescindere da una corretta formazione e gestione dei documenti in modalità esclusivamente digitale. La piena valorizzazione delle potenzialità del digitale richiede, infatti, di considerare il documento non soltanto come testo leggibile dall’uomo, ma anche come insieme strutturato di dati, funzionale allo scambio di informazioni, all’interoperabilità dei sistemi e alla cooperazione applicativa.

Alla luce di tali considerazioni, appare auspicabile un’interpretazione dell’art. 40 del CAD^[13] che renda obbligatoria la formazione e l’emanazione di regole tecniche, destinata a determinare l’immediata applicazione dell’obbligo di formazione digitale dei documenti amministrativi.

In tale quadro di progressiva digitalizzazione dei processi amministrativi, il settore sanitario emerge come uno degli ambiti in cui l’evoluzione del documento informatico assume una rilevanza particolarmente significativa. La sanità, infatti, costituisce uno dei campi nei quali la trasformazione digitale ha prodotto gli effetti più incisivi, non soltanto in termini di efficienza organizzativa e continuità dell’azione amministrativa, ma anche con riguardo alla tutela dei diritti fondamentali della persona, primo fra tutti il diritto alla salute^[14].

L’impiego del documento informatico in ambito sanitario si colloca, pertanto, all’interno di un contesto normativo e tecnologico complesso, nel quale le esigenze di dematerializzazione e interoperabilità dei sistemi informativi devono necessariamente bilanciarsi con l’obbligo di assicurare elevati livelli di sicurezza, integrità e riservatezza dei dati personali. In tale prospettiva, assume particolare centralità la nozione di documento informatico sanitario, inteso quale strumento imprescindibile per la corretta gestione, conservazione e circolazione delle informazioni cliniche nel sistema sanitario digitale.

Un passaggio cruciale del processo di digitalizzazione in ambito sanitario è rappresentato dall’adozione, appunto, da parte delle strutture sanitarie, di strumenti informatici avanzati per la gestione delle informazioni cliniche. L’obiettivo principale di tali strumenti è migliorare l’efficacia delle attività di assistenza e di prevenzione^[15]. Tra questi assume un ruolo centrale il Fascicolo Sanitario Elettronico^[16] (FSE), una piattaforma digitale che raccoglie e organizza i dati relativi alla salute del paziente.

Si configura come una risorsa innovativa e strategica per i professionisti del settore medico e ospedaliero. Il suo funzionamento si basa essenzialmente su due fasi: la prima riguarda la raccolta e la conservazione strutturata di un elevato numero di dati e documenti sanitari; la seconda consiste nella possibilità di rendere tali informazioni accessibili e condivisibili tra i diversi soggetti autorizzati, consentendo così un utilizzo coordinato e legittimo dei dati all’interno del sistema sanitario. In particolare, il FSE consente di ricostruire in maniera unitaria il percorso clinico dell’individuo, rendendo accessibili i dati e i documenti prodotti dai soggetti appartenenti al Servizio Sanitario Nazionale, nonché dalle strutture sanitarie private che partecipano all’erogazione delle prestazioni assistenziali.

Il fascicolo, inoltre, viene alimentato da una pluralità di attori del sistema sanitario, tra cui aziende sanitarie locali, strutture ospedaliere, medici di medicina generale, pediatri e altri professionisti sanitari.

All’interno del FSE confluiscono le informazioni relative agli eventi clinici che hanno interessato l’assistito nel corso del tempo, quali referti diagnostici, verbali di accesso al pronto soccorso, lettere di dimissione ospedaliera, prescrizioni farmacologiche e, più in generale, tutta la documentazione idonea a descrivere lo stato di salute e le prestazioni ricevute. A tale patrimonio informativo possono aggiungersi ulteriori documenti caricati direttamente dall’interessato, contribuendo ad arricchire il contenuto.

Dunque, è stato pensato e creato come uno strumento a carattere longitudinale, destinato ad accompagnare l’assistito lungo l’intero arco della sua vita. Persegue, quindi, sotto il profilo funzionale, l’obiettivo di garantire un punto di accesso unico, sicuro e continuo alla storia sanitaria del cittadino, favorendo in tal modo, la disponibilità immediata delle informazioni cliniche, indipendentemente dal luogo in cui esse sono state prodotte, agevolando la continuità delle cure e il coordinamento tra i diversi professionisti coinvolti nell’assistenza.

La condivisione controllata dei dati contribuisce, inoltre, a ridurre la duplicazione di esami diagnostici e di prestazioni sanitarie non necessarie, con evidenti benefici in termini di efficienza del sistema. Dunque, il FSE è destinato ai cittadini maggiorenni iscritti e assistiti dal Sistema Sanitario Regionale e trova la propria disciplina nel D.P.C.M. n. 178 del 2015^[17]. A partire dal 19 maggio 2020, viene alimentato in modo sistematico e tempestivo dai soggetti, pubblici e privati, che prendono in carico l’assistito, mediante l’inserimento dei dati relativi alle prestazioni sanitarie erogate.

Tra i contenuti del fascicolo rientrano, a titolo esemplificativo, le certificazioni vaccinali, i promemoria di prenotazione delle visite, i profili sanitari sintetici, le dichiarazioni di consenso o di diniego alla donazione di organi e tessuti, nonché i piani diagnostico-terapeutici. Il sistema consente altresì all’interessato di integrare il proprio fascicolo attraverso un’apposita sezione denominata “taccuino”^[18], nella quale è possibile inserire documentazione clinica, annotazioni personali e dati relativi al monitoraggio di specifici parametri di salute, quali pressione arteriosa, glicemia e colesterolo.

In tale ambito possono essere caricati anche documenti sanitari riferiti a prestazioni effettuate al di fuori del Servizio Sanitario Nazionale prima del 18 maggio 2020. I dati inseriti possono essere visualizzati in forma aggregata e grafica, esportati e, su scelta dell’utente, resi accessibili al medico curante. L’accesso al Fascicolo è consentito mediante strumenti di identificazione digitale, quali la Tessera Sanitaria, la Carta d’Identità Elettronica (CIE) o il Sistema Pubblico di Identità Digitale (SPID). Attraverso il portale istituzionale di riferimento è possibile consultare il fascicolo ed esprimere i consensi necessari alla sua utilizzazione. In assenza di strumenti di autenticazione già attivi, l’interessato può rivolgersi ai punti territoriali competenti per procedere all’abilitazione e all’attivazione del servizio.

La finalità ultima rimane, comunque, quella di realizzare un punto unico di aggregazione e condivisione delle informazioni sanitarie e sociosanitarie rilevanti, generate dai diversi attori del sistema sanitario. Ciò consente, da un lato, all’assistito di disporre della propria documentazione clinica in formato digitale in modo continuo e ubiquo, favorendo una maggiore consapevolezza e libertà nelle scelte di cura; dall’altro, agevola l’attività dei professionisti sanitari, che possono accedere tempestivamente alle informazioni necessarie per garantire un’assistenza più efficace e appropriata, anche in situazioni di emergenza, agevolando al contempo il rapporto tra medico e paziente.

Gestione documentale e sicurezza delle informazioni

Nel contesto dell’amministrazione digitale, il documento non può più essere considerato un oggetto statico, bensì il risultato di un processo dinamico che richiede una governance^[19]continua e strutturata. La gestione documentale si configura, pertanto, come un insieme coordinato di regole, strumenti e attività finalizzate ad assicurare la corretta produzione, circolazione e conservazione delle informazioni nel tempo.

L’efficacia di tale sistema dipende in larga misura dalla capacità di presidiare l’intero ciclo di vita del documento^[20], che prende avvio con la sua creazione^[21], prosegue con le fasi di utilizzo e organizzazione (gestione) e si conclude con la conservazione, temporanea o permanente^[22]. In ciascuna di queste fasi emergono esigenze differenti – operative e giuridiche – che impongono l’adozione di soluzioni metodologiche e tecnologiche specifiche. In particolare, l’introduzione di sistemi informatici di gestione documentale richiede l’implementazione di procedure formalizzate e controlli costanti, indipendentemente dal fatto che tali sistemi siano gestiti internamente o affidati a soggetti esterni.

Tali sistemi devono essere in grado di garantire sicurezza, affidabilità e tracciabilità delle operazioni, nel rispetto dei principi in materia di trattamento dei dati personali e sulla base di un’attenta analisi dei rischi connessi all’utilizzo delle tecnologie digitali.

La formazione del documento informatico costituisce la fase iniziale del suo ciclo di vita ed è determinante ai fini del riconoscimento del valore giuridico e probatorio del documento stesso. In questa fase devono essere assicurati, sin dall’origine, criteri di razionalità organizzativa, qualità formale, accessibilità e coerenza con le regole tecniche vigenti. In questa prospettiva, la gestione documentale non può prescindere dall’adozione di strumenti di pianificazione e controllo, quali il manuale di gestione documentale, i sistemi di workflow[23] e le piattaforme di Document & Content Management^[24], capaci di operare in ambienti interoperabili e ad elevato grado di automazione.

Il documento informatico, in questo contesto, può essere formato attraverso diverse modalità, tra cui la creazione mediante strumenti software o servizi cloud qualificati, l’acquisizione per via telematica o su supporto informatico, la produzione di copie informatiche di documenti analogici, nonché la generazione automatica di dati derivanti da processi informatici o da sistemi informativi interoperanti. Indipendentemente dalla modalità adottata, il documento deve essere identificato in modo univoco e persistente, così da consentirne la tracciabilità lungo l’intero ciclo di vita.

Elemento essenziale della fase di formazione è il conseguimento delle caratteristiche di immodificabilità e integrità del documento informatico. Tali caratteristiche possono essere garantite mediante l’apposizione di una firma elettronica (avanzata, qualificata o digitale) o di un sigillo elettronico avanzato o qualificato[25], attraverso la memorizzazione in sistemi di gestione documentale dotati di adeguate misure di sicurezza, mediante l’invio tramite servizi di recapito certificato, ovvero mediante il versamento in un sistema di conservazione. In tal modo, il documento viene sottratto a modifiche non autorizzate e ne viene assicurata la stabilità nel tempo.

Contestualmente alla formazione del documento informatico, devono essere generati e associati in modo permanente i metadati^[26], ossia le informazioni strutturate che descrivono il documento, ne contestualizzano la produzione e ne consentono l’identificazione, la gestione e la conservazione. L’insieme minimo dei metadati è definito dalle Linee Guida AgID e deve essere integrato, ove necessario, da ulteriori elementi informativi specificati nel manuale di gestione documentale dell’ente.

Fondamentale in questa fase, inoltre, è la questione sulla selezione del formato del documento, che inevitabilmente incide direttamente sulla resilienza del documento rispetto a incidenti tecnici, sulla possibilità di migrazione futura e sulla facilità di gestione dei file. L’adozione di formati non idonei o deprecati può comportare impatti significativi sull’organizzazione, rendendo necessarie complesse attività di conversione e aumentando il rischio di perdita di informazioni^[27].

In questo contesto si inserisce anche il concetto di dematerializzazione^[28], che rappresenta il processo attraverso il quale documenti originariamente formati su supporto analogico vengono trasformati in documenti informatici, idonei a sostituire gli originali cartacei ai fini giuridici, amministrativi e archivistici^[29]. Tale processo non si esaurisce in una mera attività di scansione, ma si configura come un’operazione complessa, disciplinata da precise regole tecniche e normative, finalizzate a garantire la conformità, l’affidabilità e la qualità del documento risultante.

Secondo le Linee Guida AgID, la copia per immagine su supporto informatico di un documento analogico deve essere prodotta mediante processi e strumenti idonei ad assicurare la perfetta corrispondenza di forma e contenuto tra il documento originale e quello digitalizzato. Tale corrispondenza deve essere verificata attraverso un raffronto diretto tra i documenti, cioè nei casi di dematerializzazione massiva, mediante l’adozione di una certificazione di processo, che attesti la correttezza e l’affidabilità dell’intero flusso di digitalizzazione.

Proseguendo, invece, con la seconda fase, cioè quella di gestione documentale si nota come quest’ultima comprenda l’insieme delle attività finalizzate all’organizzazione, al trattamento e all’utilizzo dei documenti informatici nel corso della loro vita. Essa assicura il corretto svolgimento dei procedimenti amministrativi, la trasparenza dell’azione amministrativa e la possibilità di reperire tempestivamente le informazioni.

Un momento centrale della gestione è rappresentato dalla registrazione informatica dei documenti, che consente l’identificazione certa e inequivocabile di ciascun documento prodotto o ricevuto. Per le pubbliche amministrazioni, la registrazione di protocollo assume un ruolo fondamentale, in quanto garantisce la tracciabilità del documento, l’immodificabilità dei dati essenziali e la storicizzazione delle operazioni effettuate. La registrazione si accompagna alla segnatura di protocollo, che associa stabilmente al documento un insieme di informazioni identificative.

Ulteriore attività imprescindibile della gestione documentale è la classificazione, finalizzata all’organizzazione logica dei documenti in relazione alle funzioni e alle competenze dell’ente. La classificazione, effettuata sulla base di un piano di classificazione preventivamente definito, costituisce parte integrante dei metadati del documento e guida la formazione dell’archivio e delle aggregazioni documentali. Nel sistema di gestione informatica dei documenti, i documenti vengono organizzati in aggregazioni documentali informatiche, quali fascicoli, serie documentarie e serie di fascicoli.

In particolare, il fascicolo informatico rappresenta lo strumento attraverso cui vengono gestiti i flussi documentali relativi a procedimenti amministrativi o ad affari omogenei, assicurando la coerenza, la completezza e la ricostruibilità dell’attività amministrativa. La gestione documentale è presidiata da specifiche figure organizzative, tra cui il responsabile della gestione documentale, ed è regolata da strumenti fondamentali quali il Manuale di gestione documentale^[30], che descrive ruoli, procedure, sistemi e metadati adottati dall’ente.

Dopodiché, c’è la conservazione del documento informatico^[31], che rappresenta la fase conclusiva del ciclo di vita documentale ed è finalizzata a garantire, nel lungo periodo, le caratteristiche di autenticità, integrità, affidabilità, leggibilità e reperibilità dei documenti. Essa risponde non solo a esigenze giuridiche e amministrative, ma anche a finalità archivistiche e storiche. La conservazione è svolta all’interno di un sistema di conservazione appositamente dedicato, distinto dai sistemi di gestione corrente, al quale i documenti vengono trasferiti mediante appositi processi di versamento.

All’interno del sistema di conservazione, i documenti sono organizzati in pacchetti informativi e sottoposti a controlli che ne garantiscono la permanenza e la validità nel tempo^[32]. Il processo di conservazione è regolato da procedure formalizzate e da misure di sicurezza fisica e logica, volte a prevenire rischi di perdita, alterazione o accesso non autorizzato. Esso può comprendere, ove necessario, operazioni di riversamento o migrazione dei documenti verso nuovi formati, al fine di contrastare l’invecchiamento tecnologico e mantenere la leggibilità nel tempo. Figura centrale della fase di conservazione è il responsabile della conservazione, cui compete la definizione delle politiche conservative e la supervisione dell’intero processo, sulla base di quanto descritto nel manuale di conservazione^[33].

Quest’ultima fase costituisce una fase autonoma e altamente specializzata, affidata a sistemi dedicati progettati per assicurare la leggibilità, l’integrità e l’autenticità dei documenti nel lungo periodo. Tuttavia, le esigenze conservative devono essere considerate fin dall’origine, poiché scelte inadeguate nella fase di formazione possono compromettere la validità giuridica e la durata nel tempo dei documenti stessi.

Dall’analisi emerge, dunque, come la gestione documentale, in via generale, costituisca uno dei principali presìdi della sicurezza informativa. La corretta formazione, gestione e conservazione dei documenti informatici deve contribuire, come già detto, a garantire la riservatezza, l’integrità e la disponibilità delle informazioni, riducendo il rischio di accessi non autorizzati, alterazioni o perdita dei dati.

L’articolo ha evidenziato come la gestione del documento informatico costituisca un presidio fondamentale per la sicurezza delle informazioni, approfondendo il ciclo di vita documentale, i requisiti di integrità e autenticità, nonché il ruolo della dematerializzazione e dei sistemi di conservazione digitale, con particolare riferimento al contesto sanitario. Nel prossimo approfondimento verrà analizzato il caso ASL 1 Abruzzo, con focus su l’incidente e il contesto organizzativo e sulle criticità emerse e misure correttive.

Per approfondire ulteriormente questi temi, è possibile scaricare il white paper gratuito “La gestione del rischio informatico in ambito sanitario come misura tecnico-organizzativa di conformità normativa”, a cura di Piergiorgio Verrecchia.

Note

[1] Si veda il Codice dell’Amministrazione Digitale (CAD), introdotto con il decreto legislativo 7 marzo 2005, n. 82 (d.lgs. 82/2005), che ha l’obiettivo di promuovere lo sviluppo dell’innovazione digitale all’interno della pubblica amministrazione, favorendo un miglioramento in termini di efficienza, trasparenza e accessibilità dei servizi erogati. Per un approfondimento: www.letrattitve.it.

[2] F. CARNELUTTI, Documento – Teoria moderna, in Nov. Digesto Italiano, VI, Torino, 1957, pag. 85.

[3] Il file rappresenta un’unità digitale destinata alla conservazione di dati, all’interno della quale possono essere archiviati contenuti di natura diversa. Esso può assumere la forma di un testo, di un’immagine, di un contenuto audiovisivo, di un brano sonoro o di un’applicazione informatica. Ogni file è identificato da una denominazione specifica e da un’estensione, elementi che consentono di riconoscerne la tipologia e la funzione. I file possono essere strutturati secondo differenti formati, ciascuno dei quali è sviluppato per rispondere a finalità precise, quali la redazione di documenti testuali, la gestione di immagini o la riproduzione di contenuti audio. Si veda www.anap.it.

[4] Le Linee Guida racchiudo le regole sugli ambiti materiali regolati dalle seguenti disposizioni del CAD: ‹‹Art. 20, Validità ed efficacia probatoria dei documenti informatici, fatte salve le norme in materia di generazione, apposizione e verifica di qualsiasi tipo di firma elettronica; Art. 21, Ulteriori disposizioni relative ai documenti informatici, sottoscritti con firma elettronica avanzata, qualificata o digitale; Art. 22, commi 2 e 3, Copie informatiche di documenti analogici; Art. 23, Copie analogiche di documenti informatici; Art. 23-bis, Duplicati e copie informatiche di documenti informatici; Art. 23-ter, Documenti amministrativi informatici; Art. 23-quater, Riproduzioni informatiche; Art. 34, Norme particolari per le Pubbliche Amministrazioni; Art. 40, Formazione di documenti informatici; Art. 40-bis, Protocollo informatico; Art. 41, Procedimento e fascicolo informatico; Art. 42, Dematerializzazione dei documenti delle Pubbliche Amministrazioni; Art. 43, Riproduzione e conservazione dei documenti; Art. 44, Requisiti per la conservazione dei documenti informatici; Art. 45, Valore giuridico della trasmissione; Art. 46, Dati particolari contenuti nei documenti trasmessi; Art. 47, Trasmissione dei documenti tra le Pubbliche Amministrazioni; Art. 49, Segretezza della corrispondenza trasmessa per via telematica; Art. 50, Disponibilità dei dati delle Pubbliche Amministrazioni; Art. 51, Sicurezza e disponibilità dei dati, dei sistemi e delle infrastrutture delle Pubbliche Amministrazioni; Art. 64-bis, Accesso telematico ai servizi della Pubblica Amministrazione; Art. 65, Istanze e dichiarazioni presentate alle Pubbliche Amministrazioni per via telematica››. Si veda www.docs.italia.it.

[5] L’Agenzia per l’Italia Digitale (AgID) ha il compito di favorire lo sviluppo dell’innovazione digitale a livello nazionale, incentivando l’adozione delle tecnologie informatiche all’interno della pubblica amministrazione e migliorando l’interazione tra amministrazioni, cittadini e imprese, come previsto dall’art. 14-bis, comma 1. L’Agenzia esercita numerose funzioni: definisce linee guida per l’attuazione del Codice dell’amministrazione digitale (art. 71), pianifica e coordina l’impiego delle tecnologie dell’informazione e della comunicazione da parte delle amministrazioni pubbliche, verifica lo stato di avanzamento delle attività e cura la realizzazione di progetti innovativi, promuovendo al contempo la diffusione della cultura digitale. AgID fornisce inoltre supporto tecnico attraverso pareri sulle procedure di acquisizione di sistemi informativi automatizzati e svolge attività di vigilanza nei confronti dei prestatori di servizi fiduciari, dei gestori di posta elettronica certificata e dei soggetti aderenti al sistema SPID. A tali compiti si aggiungono ulteriori funzioni attribuite dalla normativa vigente e dallo Statuto, come stabilito dall’art. 14-bis, comma 2.

[6] In questi termini S. PIGLIAPOCO, Il fascicolo elettronico, Atti del Convegno del 9 luglio 2010 Roma, Accademia dei Lincei, p. 33.

[7] Art. 20 comma 1 CAD: “Il documento informatico da chiunque formato, la su supporto informatico e la trasmissione con strumenti telematici conformi alle regole di registrazione tecniche di cui all’ articolo 71 sono validi e rilevanti agli effetti di legge, ai sensi delle disposizioni del presente codice”.

[8] electronic IDentification Authentication and Signature.

[9] eIDAS art. 46 – Effetti giuridici dei documenti elettronici – Regolamento (UE) n. 910/2014: “A un documento elettronico non sono negati gli effetti giuridici e l’ammissibilità come prova in procedimenti giudiziali per il solo motivo della sua forma elettronica”.

[10] R. BORRUSO, S. RUSSO, C. TIBERI, L’informatica per il giurista. Dal bit a Internet, 2009, p. 29.

[11] Art. 71 CAD, comma 1: “Le regole tecniche previste nel presente codice sono dettate, con decreti del Presidente del Consiglio dei Ministri o del Ministro delegato per l’innovazione e le tecnologie, di concerto con il Ministro per la funzione pubblica e con le amministrazioni di volta in volta indicate nel presente codice, sentita la Conferenza unificata di cui all’articolo 8 del decreto legislativo 28 agosto 1997, n. 281, ed il Garante per la protezione dei dati personali nelle materie di competenza, in modo da garantire la coerenza tecnica con le regole tecniche sul sistema pubblico di connettività di cui all’articolo 16 del decreto legislativo 28 febbraio 2005, n. 42, e con le regole di cui al disciplinare pubblicato in allegato B al decreto legislativo 30 giugno 2003, n. 196”; art 71, comma 2: “Le regole tecniche vigenti nelle materie del presente codice restano in vigore fino all’adozione delle regole tecniche adottate ai sensi del presente articolo”.

[12] Il processo di digitalizzazione della Pubblica Amministrazione si sviluppa da tempo secondo il principio del Digital First, con la finalità di modernizzare l’azione amministrativa e di semplificare l’interazione tra apparato pubblico, cittadini e imprese. L’adozione sistematica delle tecnologie digitali costituisce lo strumento attraverso cui si intende migliorare l’efficienza dei servizi e ridurre le distanze tra istituzioni e utenti. Il quadro giuridico di riferimento è rappresentato dal Codice dell’Amministrazione Digitale, introdotto con il decreto legislativo 7 marzo 2005, n. 82, che ha dato organicità alle disposizioni in materia di informatizzazione dell’attività amministrativa. Nel corso degli anni, tale corpus normativo è stato più volte aggiornato per adeguarlo all’evoluzione tecnologica; tra gli interventi più rilevanti si segnala il decreto legislativo 13 dicembre 2017, n. 217, volto a rafforzare l’effettività dei diritti legati alla cittadinanza digitale.

A questo impianto si sono aggiunte ulteriori misure di sostegno e promozione della trasformazione digitale, previste dalla legge di bilancio 2020 e dal decreto-legge n. 162 del 2019, che hanno introdotto strumenti diretti a favorire l’innovazione all’interno delle amministrazioni pubbliche. Un’accelerazione significativa è intervenuta con il decreto-legge n. 18 del 2020 (Cura Italia), convertito dalla legge n. 27 del 2020, che ha infatti previsto specifiche disposizioni finalizzate al potenziamento dei processi di digitalizzazione.

Il percorso di rinnovamento è stato ulteriormente consolidato attraverso il decreto-legge n. 76 del 2020, dedicato alla semplificazione amministrativa e all’innovazione digitale, nonché tramite il decreto-legge n. 34 del 2020 (decreto Rilancio), adottato per sostenere la ripresa economica e rafforzare il ruolo delle tecnologie digitali nel settore pubblico. Infine, il decreto-legge 1° marzo 2021, n. 22 ha ridefinito l’organizzazione delle competenze in materia di innovazione tecnologica e transizione digitale, con particolare attenzione alla digitalizzazione della pubblica amministrazione e delle imprese e allo sviluppo delle infrastrutture digitali. Per un approfondimento sul tema: www.altalex.it.

[13] Art. 40 CAD: “Le pubbliche amministrazioni formano gli originali dei propri documenti, inclusi quelli inerenti ad albi, elenchi e pubblici registri, con mezzi informatici secondo le disposizioni di cui al presente codice e le regole tecniche di cui all’articolo 71”.

[14] Art. 32 Cost.: “La Repubblica tutela la salute come fondamentale diritto dell’individuo e interesse della collettività, e garantisce cure gratuite agli indigenti. Nessuno può essere obbligato a un determinato trattamento sanitario se non per disposizione di legge. La legge non può in nessun caso violare i limiti imposti dal rispetto della persona umana”.

[15] Nel piano triennale, con riferimento all’ecosistema sanità, vengono individuati tre progetti rappresentativi a titolo esemplificativo e cioè: il Fascicolo Sanitario Elettronico (FSE), il quale è indicato come esempio di infrastruttura abilitante; il Centro Unico di Prenotazione (CUP), che rappresenta un modello di semplificazione dei rapporti tra la pubblica amministrazione e il cittadino; la telemedicina, infine, richiamata come esempio di integrazione e relazione con il territorio. Si veda per un approfondimento: www.agid.gov.it.

[16] Bisogna fare prima un appunto sul fascicolo elettronico (in termini generali): “Il fascicolo informatico, come definito dall’allegato delle Linee guida, è un’aggregazione documentale informatica strutturata e univocamente identificata contenente atti, documenti o dati informatici prodotti e funzionali all’esercizio di una attività o allo svolgimento di uno specifico procedimento”. Si veda www.agid.gov.it.

[17] L’istituzione del Fascicolo Sanitario Elettronico trova il suo fondamento normativo nell’art. 12 del d.l. n. 179/2012, mentre la disciplina attuativa è stata definita dapprima dal D.P.C.M. n. 178/2015 e, più di recente, dal decreto del 7 settembre 2023, recante l’aggiornamento del sistema nella versione FSE 2.0.

[18] “Il Taccuino è uno spazio interattivo digitale dedicato all’utente dov’è possibile caricare documenti e referti utili alla storia clinica personale. È utile per mettere digitalmente a disposizione documenti che non sono presenti sul FSE perché, ad esempio, prodotti in altre regioni o fuori dal Sistema Sanitario Nazionale.

È inoltre possibile registrare parametri importanti per la valutazione e monitoraggio della nostra salute, come peso, pressione, frequenza cardiaca, etc. Oltre all’utente principale, può visualizzare quanto contenuto sul Taccuino anche un suo delegato (in base all’ambito di operatività della delega stessa). Il delegato può anche caricare documenti e registrare rilevazioni dei parametri in sostituzione dell’utente principale. Al momento, né il MMG/PLS né altri professionisti della salute possono accedere ai contenuti”. Si veda www.aussl2.veneto.it.

[19] Da Garzanti Linguistica: “l’insieme delle procedure e dei principi che consentono la gestione…”

[20] Le Linee guida AgID sulla formazione, gestione e conservazione del documento informatico delineano un modello sistemico di gestione documentale, fondato su principi di qualità, sicurezza, interoperabilità e tracciabilità. In tale prospettiva, la gestione documentale non si esaurisce in una mera attività di archiviazione, ma costituisce un processo continuo che incide direttamente sulla validità giuridica del documento e sulla tutela delle informazioni in esso contenute.

[21] La fase di formazione del documento prevede: valutazione; monitoraggio; ri-progettazione e reingegnerizzazione.

[23] Con il termine workflow si fa riferimento a un sistema di organizzazione digitale delle attività operative, finalizzato alla razionalizzazione dei processi e al miglioramento dell’efficienza complessiva. Tale modello consente di strutturare e coordinare le singole fasi di lavoro attraverso procedure automatizzate, ottimizzando l’impiego delle risorse disponibili. Attraverso l’automazione dei compiti interni, il workflow permette di ridurre interventi manuali e tempi di inattività, assicurando la continuità del processo. Il completamento di una fase operativa determina, infatti, l’attivazione automatica della fase successiva, garantendo uno svolgimento fluido e ininterrotto delle attività. Si veda per un approfondimento www.chcbs.ch.it.

[24] Document Management System (DMS) costituiscono oggi un elemento chiave nei percorsi di trasformazione digitale delle organizzazioni. Essi non si limitano alla mera conservazione dei documenti, ma offrono funzionalità avanzate per l’organizzazione, il reperimento e la valorizzazione delle informazioni, incidendo in modo significativo sull’ottimizzazione dei processi interni. Attraverso l’automazione dei flussi operativi e l’integrazione con altri ambienti applicativi, i DMS contribuiscono a migliorare la produttività e a rafforzare il coordinamento tra le diverse funzioni aziendali.

In questo contesto si colloca TopMedia SIX, una soluzione basata su un’architettura modulare e flessibile, concepita per supportare in maniera evoluta la gestione documentale, il controllo dei workflow e la collaborazione tra gli utenti, rispondendo alle esigenze di efficienza e governance informativa delle imprese. Per un approfondimento www.agendadigitale.eu.it.

[25] In base al Regolamento eIDAS, il Sigillo Elettronico Avanzato (AdESeal) deve soddisfare 4 requisiti: è strettamente associato al suo creatore; è in grado di identificarlo in maniera inequivocabile; deve essere generato usando dati che il creatore può controllare con un elevato standard di sicurezza; deve essere intrinsecamente legato ai dati cui si riferisce in modo da consentire la rilevazione di ogni loro successiva modifica. Il Sigillo Elettronico Avanzato è idoneo a produrre effetti giuridici e può essere ammesso come prova nei procedimenti giudiziari. Il Sigillo Elettronico Qualificato è l’unica tipologia di sigillo venduta da Namirial e ha le stesse caratteristiche del Sigillo Elettronico Avanzato, ma presenta un ulteriore elemento distintivo.

Questo tipo di sigillo è creato tramite un dispositivo dotato di un certificato qualificato rilasciato da un fornitore di servizi di fiducia qualificato (QTSP) come Namirial. Un Sigillo Elettronico Qualificato svolge tre funzioni: individua il soggetto che ha generato il sigillo, prova la provenienza del file digitale su cui è apposto, fa assumere alla persona giuridica che lo appone la paternità del documento. Si veda www.namirial.it.

[26] I metadati: “Identificativo univoco e persistente associato in modo univoco e permanente al documento informatico in modo da consentirne l’identificazione”. Visionare allegato 5 al documento “Linee Guida sulla formazione, gestione e conservazione dei documenti informatici”.

[27] Per non incorrere in errori o scelte sbagliate, è opportuno orientarsi verso formati di file che garantiscano il massimo livello di interoperabilità e che siano fondati su standard aperti e riconosciuti a livello normativo. Parallelamente, risulta consigliabile adottare una struttura documentale essenziale e lineare, in modo da ridurre al minimo le criticità che possono emergere nelle fasi di conversione tra formati differenti. A tal fine, è preferibile impiegare tipografie di uso comune, evitando soluzioni grafiche particolari che potrebbero non essere correttamente interpretate da tutti i sistemi. Allo stesso modo, l’utilizzo di macro, campi personalizzati o funzionalità avanzate dovrebbe essere contenuto, poiché tali elementi possono compromettere la corretta trasformazione del documento. Per quanto riguarda gli elementi grafici, è consigliabile ancorare le immagini al testo piuttosto che inserirle in cornici o strutture complesse, così da preservarne il posizionamento anche in caso di migrazione del formato. Infine, è buona prassi verificare preventivamente i processi di conversione, attraverso test mirati, al fine di individuare le principali difficoltà operative e definire in anticipo le modalità più adeguate ad affrontarle.

[28] Le attività di dematerializzazione sono orientate alla trasposizione di documenti originariamente prodotti su supporto cartaceo in documenti in formato digitale – o, secondo la più recente terminologia europea, in documenti elettronici ai sensi del Regolamento (UE) n. 910/2014 (eIDAS) – assicurando la permanenza della loro efficacia giuridica e del relativo valore probatorio.

Tale risultato è conseguito attraverso l’adozione di formati documentali adeguati, l’impiego di strumenti di sottoscrizione elettronica e di validazione temporale, nonché mediante l’inserimento del documento all’interno di sistemi di gestione documentale caratterizzati da elevati livelli di sicurezza, fino al successivo versamento nei sistemi di conservazione a norma. Parallelamente, i processi di dematerializzazione devono garantire il mantenimento delle informazioni contestuali e delle relazioni archivistiche che inquadrano il documento nel proprio ambito amministrativo e funzionale, preservandone così non solo il contenuto informativo, ma anche il significato documentale complessivo.

[29] Soffermandoci su tale concetto da un punto di vista sanitario, si parla molto di dematerializzazione dei referti medici e delle cartelle cliniche, che rappresenta un percorso finalizzato alla realizzazione di un sistema documentale interamente digitale, in cui i documenti informatici siano dotati di piena validità giuridica e destinati a sostituire progressivamente quelli cartacei, con l’obiettivo di migliorare la qualità e l’efficienza dei servizi offerti ai cittadini. Si veda la circolare AgID n. 1/2018 del 24 gennaio 2018 “Linee guida per la dematerializzazione del consenso informato in diagnostica per immagini” e www.agid.gov.it.

[30] Si veda “Linee Guida sulla formazione, gestione e conservazione dei documenti informatici” in cui viene descritto il manuale di gestione documentale come strumento attraverso il quale l’amministrazione definisce in modo organico il funzionamento del proprio sistema di gestione dei documenti informatici. Esso stabilisce regole operative, ruoli e responsabilità necessari a garantire un governo corretto ed efficace del protocollo informatico, dei flussi documentali e dell’assetto archivistico. Il manuale disciplina l’utilizzo degli strumenti informatici per la creazione, la trasmissione e la circolazione dei documenti, individuando le competenze delle unità organizzative coinvolte, le modalità di assegnazione e instradamento degli atti e i criteri di autorizzazione all’accesso al sistema documentale.

Particolare rilievo è attribuito alla scelta dei formati documentali e alle procedure volte a garantire interoperabilità, leggibilità e conservazione nel tempo, anche attraverso operazioni di conversione e riversamento. Un ulteriore ambito regolato riguarda le attività di protocollazione e registrazione, incluse le modalità di gestione delle eccezioni, dei registri di emergenza e delle registrazioni particolari, nonché la definizione dei metadati necessari a garantire identificazione, tracciabilità e corretto trattamento dei documenti. Il manuale fornisce inoltre indicazioni sull’organizzazione dell’archivio digitale, sul sistema di classificazione e sulla formazione dei fascicoli e delle aggregazioni documentali, assicurando continuità gestionale, certezza giuridica e trasparenza amministrativa. In tale contesto, assume rilievo anche la formalizzazione dei flussi di lavoro documentali, finalizzata a chiarire i passaggi operativi e le interazioni tra le strutture dell’amministrazione.

Rilevante è infine la funzione del manuale in materia di sicurezza delle informazioni, poiché esso individua le misure tecniche e organizzative adottate per proteggere i documenti e i dati personali da rischi di accesso non autorizzato, perdita o alterazione. Il manuale disciplina altresì le modalità di conservazione dei documenti informatici, definendo tempi, criteri e procedure di trasferimento o scarto. Per un’ulteriore analisi sul tema: www.agid.gov.it.

[31] Le Linee Guida AgID adottano una visione sistemica e integrata della gestione documentale, evidenziando come la qualità della conservazione dipenda in larga misura dalle scelte effettuate nelle fasi di formazione e gestione. Ne consegue che l’attenzione agli aspetti conservativi deve essere posta sin dal momento della creazione del documento, affinché l’intero ciclo di vita sia governato in modo coerente, efficiente e conforme alla normativa vigente.

[32] La dimensione archivistica assume rilievo lungo tutto il processo documentale e non soltanto nella fase finale di conservazione. Tradizionalmente, i documenti vengono organizzati in relazione alla loro funzione e al loro grado di utilizzo, distinguendo tra documentazione attiva, documentazione non più corrente ma ancora rilevante sotto il profilo amministrativo o giuridico, e documentazione destinata alla conservazione permanente. Tale articolazione risponde all’esigenza di garantire un uso efficiente delle informazioni e una corretta selezione dei documenti nel tempo.

[33] Il manuale di conservazione costituisce un documento informatico di carattere fondamentale, volto a descrivere in maniera analitica l’assetto organizzativo del sistema di conservazione, i soggetti che vi operano e le rispettive responsabilità, nonché il modello operativo adottato. Esso deve inoltre fornire una rappresentazione puntuale delle fasi del processo di conservazione, delle soluzioni architetturali e delle infrastrutture tecnologiche impiegate, unitamente alle misure di sicurezza implementate e a ogni ulteriore elemento informativo necessario a garantire il corretto governo, il controllo e la verificabilità, nel tempo, del sistema stesso. Il contenuto minimo del manuale è definito dalle “Linee Guida sulla formazione, gestione e conservazione dei documenti informatici”, che ne disciplinano la struttura al paragrafo 4.6. In tale quadro, le pubbliche amministrazioni sono obbligate a predisporre il manuale di conservazione, a adottarlo mediante un formale atto amministrativo e a renderlo pubblicamente accessibile attraverso il proprio sito istituzionale. L’obbligo di redazione del manuale si estende altresì ai soggetti privati in tutti i casi in cui l’ordinamento preveda specifici doveri di conservazione dei documenti.

Profilo Autore

Praticante avvocato con una formazione avanzata all’intersezione tra diritto e innovazione tecnologica. Laureato in Giurisprudenza presso l’Università degli Studi del Molise, ha successivamente conseguito un Master di II livello in Informatica Giuridica, Nuove Tecnologie e Diritto dell’Informatica presso l’Università La Sapienza di Roma, con una ricerca focalizzata sulla gestione del rischio informatico in ambito sanitario come misura tecnico-organizzativa di conformità normativa.
Il suo ambito di interesse e approfondimento comprende la cybersecurity compliance, la protezione dei dati personali, la responsabilità giuridica legata all’uso delle tecnologie digitali e le implicazioni normative dei sistemi informatici in settori ad alta criticità.

https://www.ictsecuritymagazine.com/articoli/documento-informatico/