Attività di digital forensics e diritto di difesa

Se da un lato la potenzialità investigativa offerta dalle nuove tecniche dell’informatica forense comporta un indiscutibile vantaggio per il lavoro degli inquirenti, dall’altro, se non debitamente perimetrata all’interno di una disciplina ben delineata, rischia inevitabilmente di porre a rischio le garanzie con le quali la Costituzione ha inteso tutelare il diritto di difesa e il giusto processo (artt. 24 e 111 Cost.).

La fragilità che contrassegna la digital evidence, infatti, rende le attività di digital forensics estremamente delicate e una scarsa attenzione normativa (oppure orientamenti giurisprudenziali più attenti alle necessità di repressione dei reati che alle garanzie difensive), potrebbero aggravare non di poco la posizione del soggetto sottoposto alla macchina processuale.

La lacunosità della disciplina codicistica – che, come visto, si limita a richiedere l’adozione di modalità idonee alla salvaguardia del dato – unita alla posizione della giurisprudenza dominante che sembrerebbe abbracciare soluzioni poco inclini a considerare necessaria la partecipazione dell’indagato nel momento acquisitivo, lascia intendere che il tentativo di contemperazione tra esigenze investigative ed esigenze difensive tenda, nel nostro ordinamento, a privilegiare le prime.

È proprio l’insufficienza del contraddittorio che contraddistingue la fase di acquisizione in copia forense, giudicata atto ripetibile e pertanto eseguibile autonomamente dall’autorità procedente in assenza della controparte giudiziale, che però riduce notevolmente il principio di dialettica tra le parti che il nostro modello processuale (prevalentemente accusatorio) ha fatto proprio, con conseguente smussamento dell’“arsenale difensivo” a disposizione dell’indagato. Se si tiene inoltre conto del fatto che un certo grado di disparità sussiste in ogni caso, anche nel corso delle indagini tradizionali, si può cogliere come la sperequazione tra accusa e difesa sia destinata ad aumentare in caso di attività di digital forensics.

Ora, se è vero come sostiene la giurisprudenza che l’estrazione in copia forense costituisce una mera operazione meccanica, è anche vero che la volubilità del dato consente di affermare che si tratti comunque di un tipo di attività altamente aleatoria e che anche il minimo errore potrebbe condurre ad esito fatale per il processo e per l’accusato. Ad esempio, uno scorretto uso delle apparecchiature, una piccola disattenzione o anche fattori ambientali potrebbero comportare alterazioni involontarie come la cancellazione di dati idonei a dimostrare che in un determinato momento l’indagato stava utilizzando il computer e dunque non poteva trovarsi altrove a commettere il reato.

Al contrario, immedesimandosi negli investigatori, talvolta anticipare il contraddittorio alla fase acquisitiva potrebbe significare dover anticipare la discovery del materiale probatorio ad una fase ancora acerba; con conseguente rischio di mettere in allerta un eventuale colpevole che potrebbe così riuscire a correre ai ripari, anche se in realtà tale evenienza non sembra essere sufficiente a giustificare la limitazione del principio costituzionale del diritto alla difesa.

Altra situazione è quella in cui l’eventualità del caso concreto non consente all’autorità procedente di poter dilazionare le operazioni ad altro momento in attesa dell’instaurazione del contraddittorio, poiché la situazione impone di agire con assoluta urgenza.

Una soluzione capace di rappresentare un punto di incontro tra necessità investigative e garanzie difensive potrebbe essere quella – già enucleata da parte della dottrina attiva nel settore delle scienze forensi – di affiancare all’operatore incaricato dall’autorità un esperto, inteso come «consulente tecnico a futura memoria»[1], che avrebbe il ruolo di partecipare alle operazioni di acquisizione o anche solo di supervisionarle ed eventualmente intervenire consigliando le migliori modalità tecniche, così da poter in qualche modo anticipare il contraddittorio tra le parti anche nelle occasioni in cui l’indagato non possa partecipare. Inoltre, una simile figura infonderebbe sicuramente un grado di attendibilità maggiore al materiale informatico estratto. È ovvio, in ogni caso, che questa soluzione dovrebbe essere considerata pur sempre secondaria rispetto alla possibilità di intervento del diretto interessato o di esperti da quest’ultimo nominati.

L’importanza dell’intervento di un esperto nella veste di “consulente tecnico a futura memoria”, che controlli la fase di acquisizione in ottica di tutela preventiva dell’indagato, potrebbe essere avvertita come essenziale se si tiene conto degli arrivi giurisprudenziali per i quali è stato giudicato non obbligatorio, ai fini dell’utilizzabilità del materiale informatico, l’aver seguito i criteri operativi messi a punto dalle best practices.

Proprio la non obbligatorietà del rispetto delle migliori pratiche, intesa come utilizzabilità della digital evidence ottenuta con procedimenti non riconosciuti dagli standard internazionali, si rivela un’altra causa di aggravio nei confronti dell’indagato. Come stabilito dalle già esaminate sentenze pronunciate nel caso Vierika, in base ad un meccanismo di inversione dell’onere probatorio diventa, infatti, compito della difesa trovare elementi capaci di destituire l’attività svolta dagli inquirenti, che nella loro funzione sono liberi di discostarsi dalle regole precostituite dai protocolli comunemente riconosciuti senza inciampare in ipotesi di invalidità. In pratica, l’indagato si ritrova nella situazione di dover dimostrare da un lato l’avvenuta violazione delle best practices e, dall’altro, che tale violazione abbia prodotto un possibile pregiudizio all’integrità del dato digitale raccolto. È superfluo precisare come il riuscire a provare l’inattendibilità del materiale probatorio senza aver avuto la possibilità di partecipare all’acquisizione del medesimo si traduce a tutti gli effetti in un’ipotesi di probatio diabolica.

Sul punto occorre richiamare un moderno orientamento per il quale l’onere probatorio dovrebbe cadere sull’accusa e verrebbe correttamente assolto qualora fossero indicate talune circostanze, ovvero: il soggetto che ha individuato il dato informatico, come il dato si presentava al momento del rinvenimento, modo e tempo di acquisizione del dato e modalità di successiva conservazione[2]. Spetterebbe poi alla difesa, in ottica di ripartizione dell’onere probatorio, riuscire a dimostrare anche sul presupposto di proprie attività investigative la non genuinità del reperto[3].

Si deve osservare, tuttavia, come anche seguendo tale approccio, sebbene più rispettoso delle esigenze difensive, non si riuscirebbe comunque ad attenuare del tutto il carattere diabolico della prova contraria che l’indagato dovrebbe individuare per smantellare la tesi dell’accusa. Le indicazioni che dovrebbero integrare il valore probatorio del dato digitale, infatti, sarebbero in ogni caso faticosamente confutabili da una parte processuale che non ha avuto la possibilità materiale di partecipare alle attività investigative che hanno riguardato quel dato.

In pratica, anche se si volesse appoggiare questo nuovo orientamento, non vi è dubbio che in caso di eventuali incertezze queste graverebbero, inevitabilmente, sulla posizione dell’indagato contro il quale la prova è utilizzata. Situazione che fuoriesce dagli schemi del processo prevalentemente accusatorio del codice del 1988, assumendo un tono squisitamente inquisitorio.

La posizione subalterna dei diritti dell’indagato rispetto all’esigenza investigativa, in ultimo, si riflette anche sul diritto alla riservatezza. Le operazioni di digital forensics, infatti, si manifestano come attività particolarmente invasive dal punto di vista della riservatezza, concretizzandosi in un’intrusione non irrilevante nella sfera privata del soggetto indagato. Questo perché computer, smartphone e simili, oltre a contenere i possibili elementi di prova ricercati, immancabilmente fanno da contenitore ad una grande quantità di informazioni e dati sensibili che nulla hanno a che fare con il presunto delitto. Metaforicamente parlando, nella società odierna tali dispositivi sono a tutti gli effetti equiparabili a delle vere e proprie casseforti digitali di dati personali, che con questo tipo di operazioni vengono inevitabilmente forzate. Partendo da tale presupposto, appare opportuno comprendere fino a che punto gli inquirenti possano spingersi nel trattare reperti informatici.

In sostanza appare opportuno chiedersi se – e come – la portata invasiva delle moderne tecniche dell’informatica forense possa essere limitata in favore al diritto alla privacy dell’indagato. Invero, il legislatore e la giurisprudenza nell’ultimo decennio hanno già avuto modo di confrontarsi con il tema della capacità invasiva delle nuove tecnologie, peraltro in materie che per molti aspetti possono paragonarsi, dal punto di vista privacy, alla digital forensics. Tra queste, prima fra tutte la recente disciplina relativa alle intercettazioni ambientali a mezzo captatore informatico, ossia quel tipo di intercettazioni condotte con l’uso di un «un software (rectius: malware) di tipo trojan che si introduce occultamente nelle “mura protette” di un sistema informatico»[4] e che una volta al suo interno è in grado di monitorarlo e potenzialmente di esfiltrarne, da remoto e di nascosto, il contenuto digitale.

Ebbene, la normativa del captatore – e delle intercettazioni in generale – proprio in considerazione della sua capacità penetrativa nella vita dell’indagato, seppure con qualche incertezza, ha limitato la possibilità del suo utilizzo solo ad alcuni tipi di reato e solo al ricorrere di determinate condizioni[5].

Sul punto è sufficiente osservare che, anche in materia di digital forensics, non vi è motivo di non ritenere che una limitazione alla possibilità di ricorso alle operazioni di acquisizione in copia forense solo per fatti di reato in grado di arrecare un particolare disvalore sociale, potrebbe essere un giusto contemperamento tra necessità investigative e tutela della riservatezza dell’indagato.

Ad ogni modo, seppure un contemperamento tra dovere di repressione dei reati e privacy in tema di digital forensics, nei termini visti, al momento ancora non è stato oggetto di dibattito, occorre prendere nota di una recente pronuncia giurisprudenziale, scaturita da un caso di notevole impatto mediatico, relativo a fatti di finanziamento illecito a partiti politici e traffico di influenze illecite, con la quale la Suprema Corte, tenuta in considerazione l’eventualità che nelle indagini informatiche vengano acquisite informazioni “sensibili” o “supersensibili”, ha evidenziato le modalità operative e i limiti ai quali deve soggiacere il sequestro probatorio di dati informatici e telematici[6].

In particolare, ribadendo il principio del divieto di esecuzione di indagini meramente esplorative, la Cassazione ha precisato che in caso di sequestro attraverso apprensione fisica delle memorie di sistemi elettronici, una volta realizzata una copia integrale del contenuto del sistema (denominata «copia mezzo») questa debba essere analizzata al fine di selezionare i contenuti pertinenti al reato per cui si procede e quindi restituita al legittimo titolare, giacché la medesima, una volta carpiti gli elementi utili alle indagini, non rileva di per sé quale cosa pertinente al reato, trattandosi unicamente di «un insieme di dati indistinti e magmatici». In sintesi, la copia integrale va intesa come un mero strumento dal quale reperire le informazioni pertinenti al reato e in conseguenza di ciò, non sussistendo reali ragioni al trattenimento di qualsiasi altro tipo di dato in essa contenuto, può essere trattenuta esclusivamente per il tempo strettamente necessario all’espletamento delle operazioni di selezione del materiale di interesse investigativo[7].

Questo articolo è stato estratto dal white paper “La Digital forensics nel processo penale” disponibile in maniera libera e gratuita al seguente link: https://www.ictsecuritymagazine.com/pubblicazioni/digital-forensics-nel-processo-penale/

Note

[1] N. FUSARO, “Delitti e condanne… Prova scientifica e ragionevole dubbio”, in Osservatorio del Processo Penale, 2009, pp. 4-5. Lo stesso concetto viene riportato dal medesimo autore anche nell’opera “La sentenza assolutoria della Corte di assise d’appello di Perugia per l’omicidio di Meredith Kercher, tra valutazione della prova scientifica e prevalenza del principio dell’oltre ogni ragionevole dubbio. L’analisi del criminologo”, in “L’assassino di Meredith Kercher”, Aracne, 2012, p. 379, dove si legge «soprattutto nelle prime fasi di indagine, durante il sopralluogo e nel corso degli altri atti irripetibili, quale l’autopsia, appare opportuna, essendo nella quasi totalità dei casi ancora ignoto l’autore del reato, la già richiamata previsione di un consulente difensivo “a futura memoria”, che vesta anche solo e semplicemente le vesti di discussent, garantendo anticipatamente quella dialettica che, pur prevista dal nostro codice di procedura all’art. 358 c.p.p., finisce il più delle volte per essere totalmente disattesa».

[2] R. MURENEC, op. cit., p. 114.

[3] Ibidem.

[4] O. CALAVITA, “L’odissea del trojan horse, Tra potenzialità tecniche e lacune normative”, in Diritto Penale Contemporaneo, fasc. 11/2018, p. 46.

[5] Si consideri che la disciplina vigente in materia di captatore informatico ne legifera l’utilizzo unicamente in materia di intercettazioni ambientali. Attualmente il “trojan di stato” può essere usato esclusivamente per i reati contemplati dall’art. 266 c.p.p. e ne è proibito l’uso all’interno dei luoghi indicati dall’art. 614 c.p., salvo che vi sia fondato motivo di ritenere che ivi si stia svolgendo l’azione criminosa. Limitazione che tuttavia non si applica per i procedimenti di criminalità organizzata di stampo mafioso e terrorismo e, previa indicazione delle ragioni giustificative, anche per i delitti dei pubblici ufficiali o degli incaricati di pubblico servizio contro la pubblica amministrazione con pena della reclusione non inferiore nel massimo a cinque anni.

[6] Cass. Pen., Sez. IV, Sent. n. 34256 del 2020.

[7] Sull’argomento si veda M. Pittiruti, “Dalla Corte di Cassazione un vademecum sulle acquisizioni probatorie informatiche e un monito contro i sequestri digitali omnibus”, in Sistema Penale, consultabile sul sito https://www.sistemapenale.it/it/scheda/cass-sez-vi-sent-22-settembre-2020-dep-2-dicembre-2020-n-34265-pres-di-stefano-rel-silvestri?out=print.

Articolo a cura di Francesco Lazzini

Profilo Autore

Laureato in giurisprudenza con successivo conseguimento dei master in Scienze Forensi (Criminologia-Investigazione-Security-Intelligence) e in Informatica giuridica, nuove tecnologie e diritto dell’informatica. Attività di studio postuniversitario focalizzata in materia di indagini con l’utilizzo del captatore informatico e digital forensics.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/attivita-di-digital-forensics-e-diritto-di-difesa/




Industrial Cybersecurity – Architettura per la sicurezza

Il monitoring prevede l’acquisizione di informazioni dal/nel target system circa il suo stato e il suo funzionamento.

Tali informazioni, in formato grezzo e/o preventivamente elaborato e/o aggregato, vengono rese disponibili all’attività di detection che, in caso di errore, criticità o anomalia, coinvolge l’attività di reaction per l’attuazione delle necessarie contromisure, il tutto sotto la supervisione di personale dedicato.

Figura 9: Architettura concettuale di un CPS sicuro

Si noti che lo schema di Figura 9 si riferisce ad attività che possono essere svolte sia totalmente dentro al sistema in esecuzione, ad esempio quanto legato ad attacchi di tipo DoS (Denial of Service) sia, parzialmente, all’esterno, come la verifica di corretta implementazione di policy di sicurezza quando (un caso tipico sono gli Industrial Control Systems) non siano disponibili meccanismi automatici (enforcement) di applicazione delle policy stesse. In tal caso, a fronte di una descrizione dettagliata del sistema, comprensiva dei meccanismi di sicurezza, fornita possibilmente in modo (semi) automatico dal monitoring, si costruisce un modello del sistema stesso, su cui si verifica, tramite opportune tecniche di analisi, che le policy di sicurezza previste per il sistema siano soddisfatte dalla sua implementazione: ad esempio verificando che chi esercita il ruolo di “operatore” su di una certa macchina non possa modificarne i “parametri di configurazione” e che a farlo possa essere soltanto il “responsabile della produzione”. Per fare ciò, occorre verificare che l’assegnazione delle credenziali agli utenti dei singoli dispositivi e la loro configurazione consenta appunto di garantire tali desiderata.

Nel caso in cui la verifica fallisca, le necessarie correzioni vengono apportate sul modello del sistema e, in caso di successiva verifica positiva, ribaltate sul sistema reale.

Per ciò che concerne le attività di monitoring, detection e reaction effettuate sul sistema reale, sono evidentemente necessari sensori o sonde di acquisizione, risorse di computazione e comunicazione e quanto altro necessario alla riconfigurazione, quindi componenti hardware e software che devono trovarsi distribuiti nel sistema stesso per assolvere alle suddette funzioni.

Questa sovrastruttura per la sicurezza dev’essere progettata indissolubilmente dal sistema nel caso di nuovi CPS, oppure aggiunta in caso di CPS esistenti, privi o non sufficientemente dotati di risorse per la sicurezza.

Figura 10: Analisi di sicurezza

Esempi

Esempi di quanto sopra descritto possono provenire da recenti attività di ricerca nel settore. In particolare,
verranno introdotti:

  • strumenti di analisi che operano su modelli di sistema, costruiti mediante informazioni acquisite dall’attività
    di monitoring sul sistema in esecuzione;
  • strumenti di riconfigurazione automatica dell’infrastruttura di sicurezza a seguito di intervenute situazioni di
    rischio, causate da azioni malevole o semplicemente da impreviste situazioni fisiologiche;
  • analisi delle prestazioni di software e dispositivi per la sicurezza, al fine di garantire che la loro introduzione
    non influisca negativamente sulle prestazioni del sistema.

Analisi

Lo schema di Figura 10 illustra il modo di operare delle metodologie di analisi di sicurezza su modelli del sistema, eventualmente acquisiti dal sistema stesso mediante il supporto del monitoring. In sostanza, l’attività di verifica svolta da un tool software determina se il modello del sistema soddisfa i requisiti di sicurezza espressi come policy. Dal risultato ottenuto si possono effettuare, sul modello e/o le policy, le opportune correzioni, da applicare infine sul sistema reale quando i risultati dell’analisi diano esito positivo.

L’esempio specifico descritto qui concerne la verifica di implementazione di policy di access control: da un lato ci sono le policy descritte mediante il formalismo RBAC e, dall’altro, il modello del sistema comprensivo di descrizione della geografia dei luoghi, locali, armadi, quadri elettrici, della configurazione di rete atta a determinare la raggiungibilità di un dispositivo da un altro, la configurazione di ciascun dispositivo con il software installato, gli account e appunto la connettività; infine gli utenti del sistema, quindi tutte le unità di personale, ciascuna con le credenziali assegnate e il ruolo (o i ruoli) di competenza. Le policy di access control di fatto definiscono direttamente chi può fare cosa e dove nel sistema: per ciascun soggetto (chi), quale azione (cosa) e su quale oggetto (dove), senza che debba essere specificato il come. A partire dalla descrizione dettagliata del sistema, si computano le medesime informazioni attraverso il come e si confrontano i due insiemi.

Eventuali discrepanze possono significare che il sistema non implementa correttamente le policy e che, quindi, occorre apportare le necessarie correzioni.

In ciò, l’analisi stessa è di aiuto: in quanto è in grado di fornire, per ogni azione da parte di un soggetto su di un certo oggetto, la sequenza di operazioni necessarie al compimento di quella che determina la discrepanza nel confronto di cui sopra (il come). In altre parole, l’analisi fornisce il controesempio. La computazione di ciò può essere decisamente onerosa, quindi particolare attenzione è stata dedicata alle ottimizzazioni, ottenute mediante la composizione degli automi a stati finiti che descrivono rispettivamente le azioni fisiche (ad es. accesso a un locale o a un cabinet attraverso una porta) e quelle cyber (ad es. accesso a server web, ssh a nodo remoto) da parte di ciascun soggetto.

Figura 11: Verifica di implementazione di policy di access control

La Figura 11 fornisce un esempio specifico, costituito, sul lato sinistro, da una infrastruttura geograficamente dislocata in due siti, dove uno dei due è costituito da più edifici (capannoni) ognuno dei quali contiene più celle di lavoro, ciascuna con le proprie connessioni all’interno e verso l’esterno. I collegamenti di rete tra edifici e verso l’esterno sono protetti da firewall. Per tutti i dispositivi e i locali descritti si conoscono le azioni che è possibile effettuare su ciascuno, nonché le eventuali credenziali necessarie e le configurazioni (server software installati, ad esempio). Non rappresentati in figura ci sono poi i soggetti che popolano la struttura, ad esempio i manutentori, l’ingegnere di produzione, gli operatori di linea ecc., ciascuno con le credenziali che gli sono state fornite.

La parte destra della Figura 11 descrive come vengono elaborate la suddetta descrizione – chiamata Implementation Model – e l’insieme delle policy di access control, chiamato Specification Model: da ciascuno si determinano i due rispettivi set I e S di triple chi agisce dove (soggetto, azione e oggetto) che vengono confrontati. Alla luce del risultato del confronto vengono attuate le eventuali correzioni, modificando opportunamente il modello del sistema o le policy. Si noti che in questo modo di procedere si riconoscono i passi dell’ISM descritti in Figura 8: Identification of Assets in the Broader Sense è il sistema con la sua geografia, geometria e dispositivi che lo occupano e relative interconnessioni, Definition of Security Policies and Threats sono le policy di access control, mentre il Risk Assessment non compare in maniera esplicita ma il suo effetto è la determinazione della configurazione del sistema, anch’essa parte della sua descrizione per ciò che concerne i meccanismi di sicurezza.

La fase di Validation è qui costituita dall’analisi vera e propria.

Riconfigurazione Dinamica

Figura 12: Topologia di riferimento

La ridistribuzione dinamica delle regole di filtraggio, tra firewall che risiedono nella stessa rete, è una soluzione tecnica in grado di far fronte a variazioni temporanee del carico di traffico elaborato dai firewall stessi.

Nelle reti che includono più firewall in cascata, questi possono essere sfruttati per consentire il trasferimento di un insieme di regole da un firewall ai suoi vicini “a valle”, quando i cambiamenti nel profilo del traffico di input lo suggeriscono. Il meccanismo su cui si basa questa tecnica è la riduzione del numero medio di regole controllate per pacchetto, al fine di aumentare la velocità di elaborazione dei pacchetti. Il modello di rete tiene conto sia della topologia del sistema che delle caratteristiche del firewall. Un opportuno algoritmo di trasformazione sposta le regole tra i firewall in cascata, consentendo miglioramenti tangibili delle prestazioni in termini di velocità di elaborazione dei pacchetti per un dato profilo di traffico e garantendo l’integrità di sicurezza della rete. Lo scotto da pagare è un maggior consumo di banda, dato che anche ai pacchetti che verranno scartati è consentito effettuare un percorso più lungo nella rete del sistema. Per questa ragione, tale metodologia è utile durante le fasi di aumento del traffico, ma conviene tornare alla configurazione iniziale nel momento in cui la situazione di sofferenza abbia termine. La Figura 12 illustra parte di quanto descritto: data la topologia della rete, che può essere fisica o virtuale, con i dispositivi di rete fisici o virtualizzati, eventualmente basati su SDN (Software Defined Networks) e NFV (Network Function Virtualization), il flusso del traffico critico, indicato dal verso delle frecce che descrivono i collegamenti di rete, muove dal nodo sorgente, in grigio, verso le destinazioni. Ad esempio, fw1 è il firewall sovraccarico nello schema di sinistra della figura, mentre lo stesso ruolo è recitato da fw2,2 nello schema centrale. Lo schema di destra illustra invece la modularità e la scalabilità dell’approccio: se, per motivi diversi, una parte di rete non può o non deve essere considerata in dettaglio, può venire assimilata ad un singolo nodo a cui vengono associati tutti gli indirizzi della sottorete che rappresenta.

Riferendosi alla Figura 9, la situazione di criticità deve venire identificata dall’attività di detection che attinge dal monitoring, che quindi deve poter acquisire in tempo reale informazioni circa le prestazioni dei singoli firewall: ad esempio dai firewall stessi se possono rendere disponibili informazioni sul loro stato, quali il numero di pacchetti in coda, oppure da misure indirette quali la latenza dei pacchetti, cioè quanto tempo impiegano ad attraversare ciascun firewall. In quest’ultimo caso occorre disporre di un sofisticato sistema di acquisizione e misurazione, basato ad esempio su TAP (Test Access Point). Lo stesso monitoring può essere di aiuto nel determinare la topologia della rete, necessaria all’attività di reaction per il calcolo della nuova configurazione a partire dalla configurazione corrente dei firewall, da iniettare poi nei firewall coinvolti dalla trasformazione.

Tutto ciò per dire che in questo caso, come in moltissimi altri, la gestione efficace – e quindi ampiamente automatizzata – della sicurezza richiede una sovrastruttura non banale, la cui attività non deve inficiare le prestazioni richieste al CPS e che deve a sua volta essere sicura.

Prestazioni

La disponibilità di studi prestazionali e modelli semplici per firewall in grado di gestire protocolli di comunicazione a livello di applicazione industriale, come Modbus/TCP, è cruciale quando l’impatto di questi dispositivi deve essere stimato, anche approssimativamente, prima della loro effettiva messa in funzione nel sistema destinazione. Sfortunatamente, la maggior parte dei produttori non fornisce questo tipo di informazioni per i prodotti disponibili in commercio. Pertanto, una soluzione praticabile è lo sviluppo e la convalida sperimentale di modelli semplici che possono essere utilizzati dai progettisti per prevedere quelle caratteristiche del firewall non esplicitamente correlate alle loro capacità di sicurezza. Ad esempio, la latenza introdotta sull’inoltro dei messaggi è un aspetto di notevole interesse in molti sistemi di controllo industriale, dove ritardi e oscillazioni nei tempi di gestione dei pacchetti possono avere un forte impatto sull’efficacia del controllo e dell’automazione. È pertanto necessario disporre di modelli prestazionali per dispositivi commerciali per la sicurezza nei CPS. In particolare, qui si riporta brevemente l’esperienza che ha portato a caratterizzare un dispositivo commerciale in grado di eseguire filtraggio avanzato a livello di applicazione del traffico Modbus/TCP. Una serie di esperimenti progettati ad hoc, eseguiti per mezzo di un testbed di laboratorio appositamente sviluppato, ha consentito sia lo sviluppo che la validazione del modello, confermando una buona corrispondenza delle prestazioni stimate con il comportamento effettivo del dispositivo.

Figura 13: Sistema di misura di latenza

La Figura 13 illustra lo schema concettuale del sistema di misura: a sinistra senza dispositivo, per la caratterizzazione del sistema stesso, a destra con il dispositivo da caratterizzare. In sostanza, il nodo TG genera e spedisce pacchetti con cadenza costante programmabile e lunghezza costante programmabile, il TAP duplica il messaggio e il ricevitore R riceve le due istanze sulle porte r e s, salvando, per ciascun pacchetto ricevuto su ciascuna porta, il tempo di arrivo. Nel caso dello schema di sinistra i due tempi, che dovrebbero teoricamente coincidere, differiscono di pochi microsecondi per il fatto che vengono gestiti in sequenza dalla routine di interrupt di R, che impiega appunto qualche microsecondo. Questa differenza non inficia le misure effettuate con l’inserimento del dispositivo da caratterizzare, nello schema di destra, perché quest’ultimo introduce una latenza sempre superiore ai 100 microsecondi, rendendo marginale, quindi trascurabile, la latenza introdotta dal sistema di misura: infatti la differenza tra i tempi di arrivo a R delle due istanze di ciascun pacchetto trasmesso da TG è, al netto della marginale latenza del sistema di misura, la latenza che il dispositivo introduce.

Il dispositivo è in grado di filtrare traffico TCP e UDP standard e traffico Modbus/TCP, cioè pacchetti TCP il cui payload è costituito da un pacchetto Modbus. Mentre il traffico “standard” viene filtrato in base al contenuto dell’header del pacchetto, quindi il test rispetto alle regole di filtraggio è veloce, il traffico Modbus/TCP per essere filtrato richiede l’analisi del payload del pacchetto, quindi è certamente più oneroso da un punto di vista computazionale. Ciò comporta un rischio: da un lato si vuole filtrare traffico potenzialmente affetto da vincoli temporali anche stringenti e, dall’altro, questo filtraggio è computazionalmente oneroso, quindi rischia di introdurre latenze incompatibili con gli eventuali vincoli temporali che il controllo impone alla comunicazione.

Questo giustifica un’indagine approfondita per determinare l’esatto comportamento del dispositivo e la latenza introdotta dall’attività di filtraggio. Dai dati forniti dal produttore, non è possibile inferire alcunché circa la struttura funzionale del dispositivo, né il ritardo introdotto dal filtraggio; ma grazie a una serie di campagne di misura, dapprima per il solo traffico “standard” e poi per il traffico Modbus/TCP, è stato possibile determinare lo schema funzionale del firewall con estrema precisione, riuscendo anche a determinare i tempi di attraversamento di ciascun blocco da parte del pacchetto sotto esame, come illustrato in Figura 14.

Figura 14: Schema architetturale del firewall oggetto di indagine

In particolare, è risultato che il dispositivo è di fatto costituito da due firewall in sequenza, Q1 e Q2, dove Q1 è un tradizionale firewall IP mentre il secondo riceve dal primo solo i pacchetti Modbus/TCP, non gestiti da Q1. In base a ciò, risulta che il traffico “standard” ha la priorità sul traffico Modbus/TCP; inoltre il filtraggio dei pacchetti ModbusTCP, accumulati eventualmente nel buffer B2, avviene soltanto quando Q1 è inattivo, riducendo ulteriormente la priorità del filtraggio di tale traffico.

Le misure effettuate con data rate 100 Mb/s hanno consentito di determinare la lunghezza dei due buffer B1 e B2: 256 elementi ciascuno, e sono rispettivamente circa 31.95 , 138.87 e 0.745 microsecondi e rappresentano il tempo medio di attesa del pacchetto prima di essere accodato nel buffer B1, il tempo medio di attesa prima che il pacchetto, estratto da B1, venga valutato rispetto alle regole di Q1 e il tempo medio di valutazione del pacchetto rispetto ad una singola regola: quindi se la regola soddisfatta è in posizione R, il tempo di valutazione è . Circa Q2, invece, è in media 99.27 microsecondi, mentre il tempo di valutazione del pacchetto rispetto alle regole Modbus/TCP è in media 282.75 microsecondi e non dipende dalla posizione della regola soddisfatta.

Tale modello è stato poi validato mediante ulteriori campagne di misura dove, date le caratteristiche del traffico iniettato, la latenza prevista, determinata utilizzando il modello, è risultata coincidente con il valore misurato.

Il risultato, in sintesi, è che il dispositivo ha una latenza compresa tra 100 e 600 microsecondi (a seconda del tipo di pacchetto e della posizione della regola soddisfatta) e che il firewall non è in grado di gestire flussi superiori ai 2000 pacchetti per secondo.

L’importanza di questa esperienza non è tanto nei numeri che sono stati determinati, quanto nel fatto che nessuno di questi è reso noto dal produttore, rendendo di fatto impossibile stabilire a priori se il dispositivo sia idoneo e compatibile con le caratteristiche del traffico e del sistema che dovrebbe impegnarlo. Ciò deve quindi portare a una grande attenzione e prudenza nella scelta di dispositivi di sicurezza per i CPS: senza un’indicazione delle performance, infatti, non è possibile stabilire la compatibilità del dispositivo rispetto alle necessità del traffico da filtrare o da gestire.

Conclusioni

Da una prospettiva storica, i requisiti di sicurezza dei CPS sono stati tradizionalmente specificati da organizzazioni attive in una serie di domini di infrastrutture critiche, tra cui, ad esempio:

  • distribuzione di acqua e gas;
  • trasmissione e distribuzione di energia elettrica;
  • produzione di gas e petrolio;
  • produzione e distribuzione alimentare;
  • sistemi di trasporto.

In tutti questi ambiti, la security è sempre stata tenuta in debita considerazione: quindi si sono inizialmente sviluppate linee guida e raccomandazioni specifiche, oggi certamente obsolete ma comunque importanti nell’evoluzione darwiniana delle linee guida per la security dei CPS.

Nel tempo, infatti, i requisiti comuni sono stati individuati, fusi e amalgamati in diversi documenti da vari organismi di normazione internazionali e nazionali. Oggi l’Information Security Management (ISM) è universalmente considerato come un processo, chiamato anche Information Security Program (ISP) dal NIST, che ha recentemente introdotto un importante aggiornamento alla sua linea guida. Questo documento, nella sua ultima versione, sebbene ancora in forma di draft, è considerato tra i migliori e più completi punti di partenza per approfondire le tematiche della security dei CPS a 360°.

Indipendentemente dalla loro diversa struttura e grado di generalità, tutti i principali sforzi di normazione concordano, in pratica, sullo stesso concetto di base.

Ovvero:

i rischi per la sicurezza devono essere minimizzati mediante opportuni controlli che affrontino le vulnerabilità sfruttabili da possibili minacce, il cui obiettivo è l’abuso e/o il danneggiamento dei beni.

Concetto che, al termine del presente documento, dovrebbe risultare del tutto chiaro e condiviso, alla luce dell’aumentata sensibilità e consapevolezza che si spera siano progressivamente maturate con la lettura del medesimo.

Questo articolo è stato estratto dal white paper “Industrial Cybersecurity” disponibile in maniera gratuita al seguente link: https://www.ictsecuritymagazine.com/pubblicazioni/industrial-cybersecurity/

Articolo a cura di Luca Durante

Profilo Autore

Luca Durante è Primo Ricercatore presso l’Istituto di Elettronica e Ingegneria dell’Informazione e delle Telecomunicazioni del Consiglio Nazionale delle Ricerche (CNR-IEIIT) di Torino.
Nel 1996 ha conseguito il Dottorato di Ricerca in Ingegneria Informatica presso il Politecnico di Torino, è autore di oltre 70 articoli per riviste e conferenze internazionali, ed è stato ed è tuttora Responsabile Scientifico per il CNR in Progetti Europei e in contratti di ricerca con aziende.
È stato inoltre general co-chair, program co-chair e membro del comitato di
programma di conferenze internazionali, associate editor di IEEE Transactions on Industrial Informaatics e revisore per riviste internazionali.
Gli interessi di ricerca vertono principalmente sulle tematiche di sicurezza
informatica, attualmente declinati sulle policy di sicurezza per il controllo di accessi e la sicurezza dei sistemi cyber-fisici.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/industrial-cybersecurity-architettura-per-la-sicurezza/




Industrial Cybersecurity: Gli attacchi più diffusi e le contromisure

Le vulnerabilità non sono isolate ma correlate tra di loro; ed esistono tipiche sequenze del loro sfruttamento per portare a compimento degli attacchi. Certamente avere barriere al confine tra parte IT e parte OT, così come adeguate policy di sicurezza, sono sfide ancora da vincere.

Boundary Protection: il confine tra le reti IT e OT in CPS sta svanendo a causa della maggiore connettività. I confini deboli rappresentano un grande rischio, come si è visto negli incidenti informatici del passato. Stabilire una DMZ che contenga meccanismi di protezione, incluso un firewall, è il primo passo per rafforzare questi confini. Tuttavia, anche la stessa DMZ può essere soggetta ad attacchi e deve essere attentamente progettata e implementata.

Least Functionality: la rete industriale eterogenea interconnessa contiene una varietà di potenziali punti di accesso (ad es. porta, protocollo, servizi) e non è necessario mantenerli tutti attivi. La Least Functionality si riferisce al divieto e alla limitazione dell’uso di questi per prevenire potenziali abusi: tenere “aperti” solo i punti di accesso strettamente necessari. Le aziende tendono a sottovalutare o addirittura ignorare la sicurezza perché si concentrano sulla riduzione dei costi, con conseguente presenza di vulnerabilità legate alla mancata implementazione di tale policy, che effettivamente ha un costo: ridurre al minimo necessario le funzionalità di un sistema, spegnendo quelle non necessarie, richiede un’analisi attenta e costante delle sue necessità, funzionalità e prestazioni. Costa meno lasciare i dispositivi configurati così come vengono forniti dal venditore, anziché entrare nel merito dell’uso che se ne farà una volta installati.

Identification & Authentication: l’applicazione di adeguati meccanismi di autenticazione in un ambiente industriale impedisce l’accesso non autorizzato a dispositivi e informazioni. L’autenticazione delle comunicazioni uomo-macchina o macchina-macchina (M2M) richiede l’identificazione preventiva. Alle entità non identificate in tali ambienti dev’essere proibito di agire. Un avversario che riesca a inserirsi in una comunicazione non autenticata può danneggiare il CPS modificando, da un lato, i valori comunicati dai sensori e/o agli attuatori nonché, al contempo, impedire il rilevamento dell’intrusione stessa.

Physical Access Control: l’accesso alle strutture industriali avviene tramite chiavi, schede elettroniche e tecnologie mobili. Mentre le chiavi fisiche sono soggette a furto, le carte elettroniche e le tecnologie mobili non sono inviolabili. Disporre quindi di sistemi di verifica continua degli accessi a tutti i livelli consente di prevenire eventuali abusi.

Audit Review and Analysis: le organizzazioni dovrebbero adottare il sistema ISM (Information Security Management) come meccanismo operativo di monitoraggio e analisi degli eventi in tempo reale, nonché tracciamento e registrazione dei dati di sicurezza per scopi di conformità o di auditing. Naturalmente il sistema ISM stesso dev’essere protetto perché, se manipolato da un attaccante, costui potrebbe renderlo inefficace, e non consentire l’individuazione degli abusi commessi.

Authentication Management: tre principi essenziali che devono essere regolati dai criteri di applicazione della password sono la modifica, la rimozione e la crittografia delle password.

  1. Password Change: i dispositivi COTS (Commercial Off-the-Shelf ) per CPS, come i PLC, vengono forniti con una password predefinita assegnata dal fornitore. Ciò (vedi Stuxnet) rappresenta un grande rischio, pertanto dovrebbe essere impostata una nuova password prima della messa in funzione del dispositivo, cambiandola con frequenza regolare.
  2. Password Removal: questo è, più in generale, il tema delle credenziali che devono essere rimosse dal sistema e rese inattive per tutti quei soggetti che, a vario titolo, non hanno più necessità od obbligo di usarle. Anche questa attività richiede un’attenzione continua al controllo degli accessi. Anche gli eventuali repository di credenziali devono essere protetti.
  3. Password Encryption: è necessario applicare meccanismi di crittografia avanzata per proteggere le password a partire dalla fase di autenticazione. Se la password viene trasmessa o conservata come testo in chiaro, un malintenzionato può accedervi in caso di intrusione.

Least Privilege: il NIST suggerisce di applicare il principio del privilegio minimo come parte della strategia di difesa in profondità per il CPS. In base a tale principio, si fornisce un accesso minimo a un software/utente per attività essenziali e solo quando necessario, mentre il numero di attività viene mantenuto al minimo. Ciò determina sistemi facili da analizzare, con una maggiore sicurezza complessiva. Il privilegio minimo può essere fornito tramite l’applicazione del controllo degli accessi in base al ruolo (RBAC) che assegna ben precisi diritti di accesso a specifici ruoli.

Allocation of Resources: a causa della crescente interconnettività, fornire un ambiente sicuro per i CPS richiede sempre più risorse. Questo problema dev’essere affrontato anche a livello di management, per orientare anche verso la sicurezza gli investimenti da effettuare.

Account Management: gli account aggiuntivi nelle reti dei CPS vengono utilizzati in situazioni eccezionali (ad esempio, prima messa in funzione da parte del venditore/installatore). Questi account temporanei/di emergenza hanno in genere elevati privilegi di accesso Pertanto, devono essere rimossi/disabilitati una volta completato il loro utilizzo. Tale azione dovrebbe essere regolata da una rigorosa politica di controllo degli accessi.

Figura 7: Linee di difesa

Remote Access: la possibilità di accedere remotamente ai CPS ne aumenta indubbiamente la superficie di attacco; anche perché ormai l’accesso remoto non solo è utilizzato in modo passivo per scopi di monitoraggio, ma si vuole che consenta di operare sul sistema e i suoi dispositivi esattamente come se si fosse fisicamente presenti nell’impianto. A fronte di un’indubbia comodità in tal senso, una politica forte di controllo degli accessi a tutti i livelli, compreso quello remoto, è allora necessaria. I principali modelli di controllo degli accessi implementati negli ambienti industriali sono il DAC (Discretionary Access Control), MAC (Mandatory Access Control), RBAC (Role Based Access Control) e ABAC (Attribute Based Access Control). Ulteriori modelli sono stati sviluppati per l’IIoT e il Cloud.

I pilastri della sicurezza

Gli attacchi informatici più sofisticati della storia (ad es. Stuxnet, TRITON) prendono di mira i sistemi di controllo gestiti da CPS. Pertanto, il concetto di difesa in profondità deve essere applicato a tutti gli elementi del CPS. La difesa in profondità può essere fornita stabilendo diversi livelli di difesa in cui ogni livello ha un determinato scopo, mentre l’obiettivo comune è fornire un ambiente sicuro. Questi livelli possono differire per le risorse tecniche (ad es. hardware, software) pur mostrando somiglianze in termini di personale e procedure. Un ambiente industriale sicuro, progettato sulla base di un approccio di difesa in profondità, dovrebbe contenere le tre linee di difesa schematizzate in Figura 7.

In particolare, la prevention si basa su meccanismi capaci di impedire il successo di eventuali attacchi, quindi renderli inoffensivi. D’altro canto non è possibile poter sempre prevenire tutto ciò che è indesiderato, compreso ciò che ancora non si conosce; inoltre, in ambito cyber, la ricerca e lo sviluppo di nuove tecniche di attacco corrono persino più velocemente dell’attività opposta, sul fronte della difesa. Quindi, accanto alla prevention, occorre disporre di sistemi di detection che, utilizzando informazioni fornite dal monitoring, identifichi con la maggiore tempestività possibile i potenziali attacchi.

In che modo? Ad esempio riconoscendo deviazioni rispetto al comportamento atteso o agli standard del sistema. A quale livello? Tutti: dall’analisi del traffico di rete a livello di singolo pacchetto, ad anomalie nel consumo di energia da parte di attuatori in tempo reale, ma anche offline, ad esempio con la verifica di corretta implementazione nel sistema di determinate policy di sicurezza, o con l’analisi di prestazioni dei dispositivi impiegati per la sicurezza per accertare che siano compatibili coi requisiti prestazionali del sistema. La detection dunque prevede di disporre di una sorta di riferimento, che può anche essere un modello, rispetto al quale valutare il comportamento e/o la configurazione effettiva del sistema. In questo tipo di attività, oggi trovano largo impiego tecniche basate sull’intelligenza artificiale. La reaction rappresenta l’applicazione dei correttivi necessari a contrastare e possibilmente inibire quanto di (potenzialmente) malevolo o rischioso è stato individuato dalla detection, parallelamente all’eventuale ripristino delle funzionalità e prestazioni eventualmente già affette dall’attacco stesso. Chiaramente, detection e reaction sono attività che si possono sviluppare su tempi anche lunghi: ad esempio sequenze storiche che vanno molto indietro nel tempo per la detection, mentre la reaction, soprattutto quando non può essere totalmente automatica e richiede quindi un intervento umano, può portare a tempi assai lunghi per il recupero totale delle funzionalità e prestazioni del sistema attaccato, oltre al suo irrobustimento nei confronti delle criticità identificate.

Come appare quindi evidente, la sicurezza dei sistemi in generale è un processo sempre attivo, in continua esecuzione ed evoluzione, che può essere schematizzato come ISM (Information Security Management) in Figura 8, secondo i principali documenti sul tema che adottano modelli concettuali simili basati sui passaggi logici e temporali rappresentati nella parte sinistra della figura. Gli eventi che compaiono nella parte destra dell’immagine, invece, sono i responsabili del (ri)avvio e dell’iterazione del processo ISM fino al raggiungimento di una situazione soddisfacente e confermata dalla fase di validazione. La convalida ha lo scopo di dimostrare che il rischio complessivo è stato abbassato al di sotto di una soglia accettabile e di solito comporta sia attività offline (ovvero nuove sessioni di valutazione del rischio) che run-time (ovvero monitoraggio e misurazioni).

Figura 8: Information Security Management (ISM)

L’intera sequenza di passaggi viene quindi ripetuta ogni volta che:

  1. i risultati verificati in fase di validazione non corrispondono alle aspettative (riduzione del rischio inadeguata);
  2. vengono introdotte modifiche in qualsiasi parte/componente del sistema generale, comprese apparecchiature, policy, livelli di rischio, requisiti aziendali, normativi o legali, minacce o vulnerabilità scoperte di recente e così via;
  3. le attività di monitoring e detection in fase di esecuzione rilevano un incidente di sicurezza con conseguenze superiori alla soglia di gravità accettabile (le conseguenze stimate fanno parte dei risultati prodotti durante la valutazione del rischio).

In sostanza, dunque, l’ISM riguarda l’intera organizzazione di una società, includendo i seguenti elementi:

  • formazione e impegno dei dipendenti e dei dirigenti;
  • rapporti con partner, fornitori e clienti;
  • business continuity;
  • requisiti legali e contrattuali;
  • rispetto delle politiche e degli standard di sicurezza;
  • conformità tecnica;
  • gestione delle risorse;
  • access control;
  • gestione delle comunicazioni e delle operazioni;
  • sicurezza fisica e ambientale.

Si noti che tutti gli aspetti sopra elencati sono strettamente correlati: ad esempio, l’impegno del management garantisce le risorse e gli investimenti necessari (formazione, attrezzature e audit), mentre la formazione dei dipendenti consente la comprensione di meccanismi e tecniche di sicurezza, così come la corretta attuazione delle policy e delle procedure.

Questo articolo è stato estratto dal white paper “Industrial Cybersecurity” disponibile in maniera gratuita al seguente link: https://www.ictsecuritymagazine.com/pubblicazioni/industrial-cybersecurity/

Articolo a cura di Luca Durante

Profilo Autore

Luca Durante è Primo Ricercatore presso l’Istituto di Elettronica e Ingegneria dell’Informazione e delle Telecomunicazioni del Consiglio Nazionale delle Ricerche (CNR-IEIIT) di Torino.
Nel 1996 ha conseguito il Dottorato di Ricerca in Ingegneria Informatica presso il Politecnico di Torino, è autore di oltre 70 articoli per riviste e conferenze internazionali, ed è stato ed è tuttora Responsabile Scientifico per il CNR in Progetti Europei e in contratti di ricerca con aziende.
È stato inoltre general co-chair, program co-chair e membro del comitato di
programma di conferenze internazionali, associate editor di IEEE Transactions on Industrial Informaatics e revisore per riviste internazionali.
Gli interessi di ricerca vertono principalmente sulle tematiche di sicurezza
informatica, attualmente declinati sulle policy di sicurezza per il controllo di accessi e la sicurezza dei sistemi cyber-fisici.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/industrial-cybersecurity-gli-attacchi-piu-diffusi-e-le-contromisure/




La Direttiva NIS2: Il quadro giuridico italiano

Dall’entrata in vigore della Direttiva NIS nel 2016, il contesto delle minacce informatiche ha subito significative trasformazioni, registrando un incremento del numero, dell’entità, della sofisticazione e della frequenza degli incidenti informatici. Sebbene la Direttiva NIS abbia costituito un passo iniziale rilevante, questa evoluzione ha messo in luce l’insufficienza del quadro normativo vigente e le disparità nella sua applicazione tra gli Stati membri dell’Unione Europea, manifestando la necessità di un aggiornamento normativo per rispondere efficacemente ai rischi emergenti e alle sfide del futuro.

In risposta alla crescente esigenza di rafforzare la sicurezza informatica e la resilienza del sistema economico e sociale europeo, il 14 dicembre 2020, la Commissione Europea ha avanzato una proposta di aggiornamento della Direttiva NIS, culminata con l’emanazione della Direttiva (UE) 2022/2555, nota come NIS2, il 27 dicembre 2022 da parte del Parlamento Europeo e del Consiglio. Questa nuova direttiva abroga la precedente, introducendo un rinnovato impegno verso l’uniformità e il potenziamento delle misure di sicurezza informatica per gli operatori essenziali e importanti, con l’obbligatorio recepimento della normativa da parte degli Stati membri entro il 17 ottobre 2024.

La NIS2 si distingue per il suo approccio sistematico e coerente, mirato a colmare le lacune precedentemente identificate e armonizzare le disposizioni relative alla gestione del rischio di cybersicurezza e alla notifica degli incidenti informatici. Essa estende l’ambito di applicazione per includere nuove esigenze di tutela in settori emergenti e nell’economia digitale interconnessa, mirando così a potenziare la resilienza delle infrastrutture critiche e a favorire la cooperazione e lo scambio di informazioni tra gli Stati membri dell’Unione Europea. In tale ottica, la Direttiva stabilisce obblighi più definiti per gli operatori e accresce notevolmente i requisiti per l’implementazione delle best practice di sicurezza informatica. Per assicurare la conformità a tali requisiti ed obblighi, vengono introdotti meccanismi di vigilanza ed esecuzione uniformi ed efficaci, corredati da sanzioni legali più rigide per le violazioni.

Con lo schema di Decreto legislativo, approvato il 10 giugno 2024, si realizza un’importante evoluzione nella legislazione italiana per allinearsi alle disposizioni della Direttiva (UE) 2022/2555. Tale decreto incorpora un insieme di interventi strategici finalizzati a potenziare la resilienza e la sicurezza delle infrastrutture critiche di rete e dei sistemi informativi. In questo contesto normativo, l’Agenzia per la Cybersicurezza Nazionale (ACN) è stata confermata autorità nazionale responsabile per la gestione e il coordinamento delle misure di sicurezza informatica, operando come principale interfaccia per le relazioni con altri Stati membri e con le istituzioni europee.

Il decreto de quo stabilisce criteri precisi per identificare i soggetti tenuti a implementare strategie efficaci di gestione dei rischi cibernetici e a segnalare tempestivamente eventuali incidenti. Tali requisiti si estendono a un ampio spettro di operatori essenziali attivi in settori chiave come energia, trasporti, settore bancario, gestione delle acque potabili e reflue, produzione alimentare, sanità, spazio e infrastrutture digitali, al fine di preservare la sicurezza e il benessere collettivi.

Lo schema di Decreto introduce una novità di rilievo: l’obbligo di iscrizione per i soggetti che rientrano nell’ambito di applicazione della normativa. L’articolo 7, paragrafo 1, prevede che tali soggetti debbano registrarsi, o aggiornare annualmente la propria registrazione, sulla piattaforma digitale resa disponibile dall’Autorità nazionale competente NIS.

L’obbligo di registrazione sarà operativo non appena la piattaforma dell’Autorità sarà accessibile e, successivamente, dovrà essere adempiuto tra il 1° gennaio e il 28 febbraio di ogni anno. Il processo di registrazione richiede la comunicazione di dati accurati e aggiornati, come la ragione sociale, l’indirizzo, i recapiti, la designazione di un punto di contatto e i settori di appartenenza indicati nel suddetto articolo.

La summenzionata procedura è fondamentale per garantire che le organizzazioni siano correttamente classificate come soggetti essenziali o importanti, facilitando una gestione efficace e uniforme delle politiche di sicurezza informatica, come delineato negli articoli 3 e 6 del Decreto. Inoltre, questo adempimento è necessario per consentire all’Agenzia per la Cybersicurezza Nazionale di svolgere le proprie funzioni di supervisione, controllo e gestione della sicurezza informatica, in conformità con quanto stabilito nel Decreto stesso: la registrazione, infatti, fornisce all’ACN le informazioni necessarie per identificare e monitorare tali soggetti, assicurando che rispettino le misure di sicurezza prescritte. Analogamente, l’aggiornamento dei dati consente all’ACN di mantenere un elenco accurato e aggiornato di questi soggetti, garantendo che siano sottoposti ai necessari controlli.

Secondo l’articolo 7, l’Autorità nazionale competente NIS è responsabile della verifica delle informazioni trasmesse dai soggetti registrati, assicurando che rispettino i requisiti normativi per l’inclusione nell’elenco previsto dallo stesso articolo. La mancata o tardiva registrazione rappresenta un’inadempienza agli obblighi normativi e comporta l’applicazione di sanzioni amministrative pecuniarie, che possono essere aumentate fino al triplo, come previsto dall’articolo 38, comma 13, del Decreto.

Tanto premesso, l’accuratezza e la tempestività nella registrazione e nell’aggiornamento delle informazioni sono essenziali per garantire l’integrità e l’efficacia delle misure di sicurezza informatica richieste dal legislatore nazionale, per cui, la loro inosservanza, comporta il rischio di incorrere in ulteriori severe sanzioni.

L’Autorità NIS è abilitata a imporre, nei confronti delle persone fisiche responsabili di un’entità, o che agiscono come suoi rappresentanti legali, nonché di coloro che esercitano funzioni dirigenziali in qualità di amministratore delegato o rappresentante legale di un’entità rilevante o significativa, la sanzione amministrativa accessoria dell’incapacità a ricoprire incarichi dirigenziali presso la stessa entità. La disposizione in commento, avente un forte effetto deterrente, colpisce personalmente i dirigenti aziendali e costituisce una modifica sostanziale rispetto alla Direttiva, che prevede tale sanzione accessoria solo per le entità essenziali.

Nell’ambito delle disposizioni contenute nel decreto, l’art. 27 assume un’importanza significativa, in quanto stabilisce una connessione diretta tra la conformità alle norme di sicurezza e l’uso di tecnologie certificate. In questo contesto, l’Autorità nazionale competente NIS può imporre ai soggetti essenziali e importanti di utilizzare categorie di prodotti TIC, servizi TIC e processi TIC, sviluppati dal soggetto essenziale o importante o acquistati da terze parti, che siano certificati nell’ambito dei sistemi europei di certificazione della cybersicurezza. In attesa che tali sistemi europei di certificazione siano definitivamente adottati, l’Autorità nazionale competente NIS può altresì imporre l’adozione di prodotti, servizi e processi TIC che siano certificati secondo schemi nazionali o europei già riconosciuti.

Dall’analisi dell’articolo 27 e delle misure di sicurezza specificate nel decreto si evidenzia un’attenzione particolare alla protezione delle informazioni, in termini di confidenzialità, disponibilità e resilienza dei sistemi informativi, nonché all’importanza della continuità operativa. In questo contesto, il comma 2 del suddetto articolo si presume faccia riferimento a standard internazionali riconosciuti, come la ISO/IEC 27001 e la ISO 22301.

Lo standard internazionale ISO/IEC 27001 fornisce requisiti per la gestione della sicurezza delle informazioni, enfatizzando la confidenzialità, l’integrità e la disponibilità delle informazioni. Questo standard aiuta le organizzazioni a mitigare i rischi informatici e proteggere i dati sensibili attraverso un sistema di gestione continuativo e strutturato. Parallelamente, lo standard ISO 22301 stabilisce criteri per la gestione della continuità operativa, coprendo la pianificazione, l’attuazione, il monitoraggio e la revisione di un sistema di gestione per affrontare e mitigare incidenti destabilizzanti. Essenziale per la resilienza dei sistemi informativi, questo standard assicura la continuità delle operazioni durante disastri o gravi interruzioni.

Stante ciò, gli standard ISO/IEC 27001 e ISO 22301 forniscono un quadro solido per raggiungere e dimostrare l’elevato livello di sicurezza delle informazioni e di continuità operativa richiesto dal Decreto. Pertanto, l’implementazione combinata dei due standard attraverso un sistema di gestione integrato contribuisce alla conformità con lo schema di Decreto.

Ne consegue che l’approccio proattivo e le sanzioni rigorose in caso di non conformità riflettono la necessità di elevare gli standard di sicurezza informatica.

In conclusione, la strategia delineata non solo consente di proteggere le infrastrutture critiche nazionali ed europee, ma tutela anche la società nel suo insieme, enfatizzando la necessità di sistemi informativi sicuri e resilienti in un ambiente sempre più digitalizzato.

Articolo a cura di Lara Maugeri e Antonietta Riccardi

Profilo Autore

Cyber Security Specialist – ICT Cyber Consulting

Laurea Magistrale in Scienze Filosofiche all’Università di Catania. Certificazioni CISCO: IT Support, Cyber Security & Networking. Auditor ISO/IEC 27001:2022.

Profilo Autore

Cyber Security Specialist – ICT Cyber Consulting

Avvocato. Master in Cybersecurity Governance & Auditing. Auditor ISO/IEC 27001:2022.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/la-direttiva-nis2-il-quadro-giuridico-italiano/




Privacy e metadati di posta elettronica dei dipendenti – Le principali novità

Sono stati finalmente chiariti dal Garante per la protezione dei dati personali molti dei dubbi interpretativi sulla conservazione dei metadati relativi alle comunicazioni di posta elettronica dei dipendenti. In proposito, sia permesso rimandare all’articolo di commento alla precedente versione del provvedimento: “Metadati delle email dei dipendenti: il punto sul provvedimento del Garante sottoposto a consultazione pubblica”.

Il nuovo testo del documento, ampiamente aggiornato a seguito appunto di consultazione pubblica e datato 6 giugno 2024 [10026277] (ma reso disponibile a partire dal 17 giugno), era particolarmente atteso da aziende e consulenti, considerate le difficoltà inizialmente emerse, prime fra tutte la prescrizione di un tempo brevissimo di conservazione dei metadati (7 giorni) e un raggio applicativo incerto. In merito a entrambe le criticità, il provvedimento recente offre indicazioni nettamente migliorative.

Esaminiamone dunque i principali passaggi di rilievo, raggruppandoli in quattro sezioni.

Tempo di conservazione esteso a 21 giorni

L’elemento più lampante del nuovo testo è certamente rappresentato dall’estensione del termine (massimo) di conservazione dei metadati da 7 a 21 giorni. Il nuovo termine, se concede maggiore respiro ai titolari del trattamento, continua tuttavia a non soddisfare le esigenze di motivazione dei provvedimenti dell’Authority.

In effetti, non viene offerta alcuna spiegazione per una determinazione numerica tanto esatta. Ciò, a parere di chi scrive, determina due ordini di difficoltà. La prima è che in tal modo il Garante si sostituisce al titolare del trattamento nella determinazione dei tempi di conservazione, occupando una competenza e un onere che sono del secondo, ai sensi dell’art. 5 GDPR, cosiddetto principio di accountability del titolare.

L’altra è che i titolari del trattamento vengono in tal modo disincentivati a farsi carico della concreta attuazione di tale principio, non disponendo neppure di un percorso motivazionale che permetta loro un’applicazione ragionata e un adattamento in base al contesto.

Vero che l’Autorità smussa alquanto la formulazione categorica, parlando di un termine “a titolo orientativo”, è tuttavia chiaro, dalla complessiva esposizione, che chi vorrà avventurarsi oltre tale termine dovrà vincere una notevole presunzione contraria istituzionale.

In definitiva, 21 giorni sono un periodo secco, che pone una regola e ammette difficili eccezioni.

Effettivo campo di applicazione del provvedimento

I metadati esaminati dal documento di indirizzo sono solo quelli che “corrispondono tecnicamente alle informazioni registrate nei log generati dai sistemi server di gestione e smistamento della posta elettronica (MTA = Mail Transport Agent) e dalle postazioni nell’interazione che avviene tra i diversi server interagenti e, se del caso, tra questi e i client”.

Dunque, diversamente dalla prima stesura, quella aggiornata, che esplode alcune indicazioni già contenute nell’atto di avvio della consultazione pubblica, circoscrive notevolmente il campo applicativo. L’Authority anzi chiarisce, a scanso di equivoci, che il termine di conservazione di 21 giorni non si applica alle comunicazioni di posta elettronica presenti nella casella dei dipendenti. Sono cioè escluse dall’area applicativa “le informazioni contenute nei messaggi di posta elettronica nella loro “body-part” (corpo del messaggio) o anche in essi integrate – ancorché talvolta non immediatamente visibili agli utenti dei software “client” di posta elettronica (i cosiddetti MUA – Mail User Agent) – a formare il cosiddetto envelope, ovvero l’insieme delle intestazioni tecniche strutturate che documentano l’instradamento del messaggio, la sua provenienza e altri parametri tecnici”.

È appena il caso di notare che nel provvedimento iniziale si parlava proprio invece di applicabilità ai “metadati relativi all’utilizzo degli account di posta elettronica in uso ai dipendenti”, dicitura ambigua che peraltro permane tuttora, ma nel solo apparato delle premesse. Questo spostamento del fuoco dai metadati di utilizzo degli account a quelli tecnici generati nelle operazioni di smistamento tra server e server e tra server e client è certamente un bene, perché evita situazioni insostenibili per le aziende.

Giova tuttavia avvertire che, al netto della prescrizione del termine massimo di conservazione di 21 giorni per i soli metadati generati dai sistemi di smistamento e gestione della posta elettronica, non bisogna cadere nell’equivoco di considerare anche il resto del documento come limitato nello scopo.

In verità, il provvedimento del Garante ha vocazione generale, poiché chiarisce la posizione dell’Autorità rispetto a qualsivoglia strumento lavorativo, pur lecito, da cui possa derivare indirettamente controllo a distanza dei dipendenti attraverso un trattamento di dati personali. Le implicazioni sono cioè molto più ampie di quanto una lettura affrettata potrebbe portare a credere.

C’è in particolare un passaggio che vale la pena mettere in evidenza: la costruzione, da parte dell’Autorità, di una presunzione di controllo indiretto del dipendente al decorrere di una certa durata di conservazione delle informazioni di log (e applicabile, giuridicamente, a qualsiasi log). Tale assunto costituisce un punto fermo nella posizione del Garante, ma non altrettanto fermo in caso di evoluzione in contenzioso giudiziale. Insomma, si può contestare. L’opinabilità risiede, a parere di chi scrive, nella natura assiomatica della formulazione, priva di apparati esplicativi convincenti.

Vero che l’esaurirsi della finalità di trattamento, nella specie la finalità di corretto funzionamento dei sistemi di smistamento della posta elettronica, fa venire meno un presupposto di liceità del trattamento, tuttavia è controvertibile che ciò solo trasformi ipso facto il trattamento in una forma di controllo indiretto del lavoratore. Detto altrimenti: la posizione dell’Authority è certamente rispettabile ed è un bene che sia espressa con molta chiarezza, tuttavia si presta, soprattutto per l’asciuttezza con cui è formulata, a essere contrastata con successo.

Sempre in tema di vocazione generale del provvedimento, va apprezzata la tessitura dei rapporti giuridici, in esso ben sviluppata, che esistono tra l’articolo 4 dello Statuto dei lavoratori (legge 300/70), il Codice privacy (d.lgs. 196/03) e, a monte, il GDPR (reg. UE 2016/679), anche in termini di sanzioni applicabili e di responsabilità. Il Garante dunque fornisce utili strumenti concettuali, preziosi per le valutazioni del titolare del trattamento in una serie di contesti diversi, anche per esempio in materia di videosorveglianza dei lavoratori, non solo quindi di metadati della posta elettronica.

Valore giuridico dei documenti di indirizzo

Nel provvedimento del 6 giugno 2024, qui esaminato, sono numerosi i passaggi nei quali è ribadita la natura di mera interpretazione di tale tipologia di provvedimento. È importante perché la prima versione del dicembre 2023 recava, almeno nella percezione dello scrivente, ampia ambiguità, tendendo verso un “provvedimento generale”, nello spirito cioè di quelli che in epoca pre-GDPR il Garante emanava, ossia uno strumento contenente elementi di normazione secondaria.

Insomma, il punto è: con il provvedimento d’indirizzo il Garante scrive nuove regole o si limita a chiarire e sistematizzare quelle già esistenti? Ecco, il tema ha interesse più ampio rispetto al caso che ci occupa, perché l’Authority realizza documenti di indirizzo in svariate materie.

Vale la natura di mero chiarimento e sistematizzazione, come si è detto: il valore meramente interpretativo del testo si trova opportunamente ribadito in più punti della versione aggiornata. Resta tuttavia l’oggettiva considerazione che la determinazione di un termine di conservazione di 21 giorni, sia pure “a titolo orientativo” si palesa a tutti gli effetti come l’introduzione di una regola generale nuova e non come l’interpretazione di una disciplina esistente. Un termine così netto, pur con la “sfocatura” introdotta, tende a stridere con affermazioni, contenute nel documento d’indirizzo, secondo le quali esso “non reca prescrizioni né introduce nuovi adempimenti a carico dei titolari del trattamento”, e che, “stante la natura orientativa del documento di indirizzo, dallo stesso non discendono nuovi adempimenti o responsabilità”.

Proprio l’osservazione tuttavia che la “soglia 21” è indicata in un contesto che non permette l’introduzione di nuove regole può, allo stesso tempo, supportare adeguate linee di difesa per il titolare del trattamento che tale soglia non abbia inteso in termini precettivi.

Il capitolo fornitori

Da ultimo, vale la pena notare che i fornitori dei sistemi di gestione della posta elettronica continuano a essere i grandi assenti dal raggio applicativo del provvedimento. Certo, rispetto alla versione iniziale, il nuovo documento d’indirizzo dedica maggiore spazio agli obblighi di costoro, ma senza porli mai veramente al centro dell’attenzione istituzionale. La sensazione è quella che si resti al livello di quello che gli anglosassoni chiamano “lip service”. Eppure, sono proprio i grandi fornitori parte essenziale del problema e di conseguenza parte essenziale della soluzione. La moltitudine frammentata dei titolari del trattamento che fruisce dei loro servizi spesso può davvero poco, come peraltro emerge tra le righe nello stesso provvedimento del Garante.

In definitiva, chi mette in circolazione sistemi che hanno rilevanza in materia di trattamento dei dati personali, si pensi ai grandi sistemi in cloud, ha il dovere di assicurarne la conformità al GDPR, tuttavia questo passaggio trova collocazione periferica nel documento d’indirizzo.

Conclusioni

L’apertura di una consultazione pubblica e le sostanziali modifiche al documento originario appaiono assai apprezzabili, perché rivelano il profilo di un’Autorità capace di tornare sui propri passi e di migliorare sensibilmente, attraverso un approccio condiviso, il contenuto dei provvedimenti. Il documento d’indirizzo, che sia oppure no condivisibile in toto, presenta certamente passaggi di notevole interesse giuridico, che vanno oltre il campo applicativo immediato. Quest’ultimo inoltre risulta chiarito finalmente con precisione, il che permetterà, prevedibilmente, una riduzione di adempimenti per i titolari del trattamento e altresì del contenzioso. Unica sbavatura, ad avviso di chi scrive, resta la tendenza a prevedere d’ufficio termini di conservazione dei dati personali che spettano unicamente al titolare del trattamento (ciò segna una tendenza sistematica sulla quale è auspicabile una rimeditazione) e la riluttanza a rivolgere primaria attenzione ai grandi fornitori. Soprattutto quest’ultimo aspetto non lascia prevedere il raggiungimento di una soluzione reale in tempi brevi, perché le leve negoziali dei titolari per imporre modifiche di progettazione dei software sono qui debolissime. Resta anche la generale sensazione, nel mercato quanto negli interpreti, che il provvedimento riveli un’eccessiva concentrazione su un argomento interessante ma marginale, che rischia di distrarre energie da tematiche ben più gravi e pressanti.

Articolo a cura di Enrico Pelino

Profilo Autore

Enrico Pelino è avvocato del foro di Bologna, DPO e co-fondatore dello studio legale Grieco Pelino Avvocati. Da sempre cultore dell’intersezione tra diritto e tecnologia, ha conseguito un dottorato di ricerca in diritto dell’informatica presso l’Università di Bologna, e quindi collaborato con associazioni del settore. Attualmente è fellow dell’Istituto Italiano per la Privacy e la valorizzazione dei dati (IIP) e componente del comitato tecnico-scientifico di Anorc Professioni. È altresì nella lista degli Esperti costituenti il “Support Pool” dell’EDPB (European Data Protection Board). Autore di numerosi articoli in riviste specializzate in materia di diritto digitale, invited speaker in primarie conferenze, ha svolto docenze in master per università ed enti di alta formazione. Per l’editore Giuffrè ha curato e scritto, assieme a colleghi di primo livello nazionale, volumi monografici e commentari in materia di protezione dei dati personali e disciplina della società dell’informazione: Il Regolamento Privacy Europeo (2016), Codice della Disciplina Privacy (2019); Privacy e libero mercato digitale (co-autore, 2021); Digital Services Act e Digital Markets Act (2023); Codice commentato della privacy (2024).

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/privacy-e-metadati-di-posta-elettronica-dei-dipendenti-le-principali-novita/




Email Security: Social Engineering e Threat Intelligence

Introduzione

L’email security è un’area della cyber security che coinvolge un insieme di metodologie, procedure e tecnologie il cui scopo è quello di proteggere le comunicazioni che avvengono tramite email prevenendo l’esecuzione di potenziali malware, URL malevoli ed esfiltrazione di informazioni sensibili. Ogni minaccia e rischio per la sicurezza che viene veicolato tramite la posta elettronica verso uno o più utenti deve quindi essere prontamente analizzato ed eventualmente. Il rischio di subire un attacco ransomware e/o malware tramite email è molto elevato basti pensare che, stando alla “The Definitive Email Cybersecurity Strategy Guide” di Proofpoint, oltre il 90% delle minacce per le aziende vengono veicolate o iniziano tramite email. Inoltre, osservando la top ten dei più diffusi Cyber Attacks nel 2023:

  1. Malware
  2. Phishing
  3. Denial-of-Service (DoS) Attacks
  4. Code Injection Attacks
  5. IoT-Based Attacks
  6. Identity-Based Attacks
  7. Supply Chain Attacks
  8. Spoofing
  9. Insider Threats
  10. DNS Tunneling

si può notare che la posta elettronica è uno dei principali vettori di attacco utilizzato dai cyber criminali. Nell’ultimo rapporto del Clusit 2024 si conferma tale tendenza in merito anche alla “severity” degli attacchi informatici, infatti, si afferma che “rimane costante la gravità degli attacchi che fanno uso di Phishing / Social Engineering” e che gli attacchi basati su “phishing e social engineering” in Italia riguardano ormai l’87% in valore assoluto.

Tabella 1. Distribuzione della Severity per tecniche di attacco nel 2022 – Clusit 2024

Social engineering e threat intelligence

Tra le principali metodologie per la costruzione di mail malevole verso specifici target ci sono dunque:

  • La Social engineering
  • L’OSINT (Open-source intelligence)

La social engineering è una tecnica di manipolazione che fa leva sulle caratteristiche umane per ottenere informazioni private, credenziali di accesso o dati di interesse. Nell’ambito del cybercrimine, queste tecniche sono anche note come “human hacking” e hanno come obiettivo quello di adescare gli ignari utenti inducendoli a esporre dati riservati, a diffondere malware o a concedere l’accesso a sistemi riservati. Questi attacchi possono avvenire online, di persona o attraverso altre interazioni. Tra le caratteristiche di un attacco di social engineering ci sono:

  • Le emozioni come la paura, la curiosità, la rabbia, la tristezza ecc.
  • L’Urgenza della richiesta.
  • L’indurre sicurezza e fiducia nell’interlocutore per fargli compiere azioni a suo svantaggio.

L’Open-Source Intelligence (OSINT) invece fa riferimento a tutte quelle informazioni e risorse disponibili in rete come, media (giornali, radio, televisioni ecc), pubblicazioni accademiche, conferenze e dati pubblici (report governativi e simili) che sono a disposizione di tutti e che quindi potrebbero rappresentare un rischio per la sicurezza. In base al tipo di informazione si parla di:

  • GEOINT, Geospatial Intelligence.
  • SIGINT, Signals Intelligence.
  • HUMINT, Human intelligence (collezione di informazioni relative a una persona e/o un gruppo, tendenzialmente di potenziali criminali).

La threat intelligence si occupa quindi di collezionare i dati “non strutturati” raccolti dalla rete o altre fonti per poi, a seguito di apposite analisi, renderli “strutturati” e utilizzabili per comprendere eventuali possibili attacchi e definire potenziali “threat actors”. Ovviamente, lato attaccante, la threat intelligence può invece essere utilizzata per effettuare azioni malevoli ad aziende e/o piattaforme aiutandoli a definire il “profilo” del target che si intende colpire. In figura 1 si può osservare il processo sin qui descritto.

Figura 1. Cyber Threat Intelligence

Tra le principali fonti OSINT ci sono i social network (Facebook, Instagram, Tik Tok e simili), i motori di ricerca (Google, DuckDuckGo, Bing ecc) e le piattaforme come Shodan, che consentono di ricercare e individuare server o altri sistemi, come webcam ecc, esposti in rete.

“Only The Paranoid Survive”
[Andy Grove]

Esistono inoltre fonti OSINT più strutturare che consentono alla cyber defense di reagire prontamente alle nuove minacce, tra cui:

  • CVSS (Common Vulnerability Scoring System (CVSS)) utilizzato per misurare qualitativamente la “severity” (low, medium, high, critical) di una minaccia. Consente alle organizzazioni di valutare le caratteristiche di una vulnerabilità e la sua gravità mediante un punteggio numerico utilizzando tre componenti:
    • Base: rappresenta le caratteristiche intrinseche della vulnerabilità e che non variano nel tempo. Considera l’impatto della vulnerabilità in caso questa venga sfruttata.
    • Temporale, tiene conto di come la vulnerabilità possa variare nel tempo valutando anche le possibili mitigazioni.
    • Ambientale, dipendente dal sistema in cui si andrà ad operare, si valutano i vari asset di interesse e se ne calcoleranno i danni e i potenziali effetti collaterali.

Di seguito la tabella con i relativi score con le due ultime versioni a confronto:

Tabella 2. CVSS score range

Le vulnerabilità vengono collezionate dal NIST e pubblicate nell’NVD “national vulnerability database” a disposizione di chiunque ne abbia bisogno.

Mitre Att&ck framework: è una knowledge-base che consente di usufruire della “conoscenza” acquisita dalla security community in termini di tattiche, tecniche e procedure (TTPs) utilizzate dagli attaccanti, documentandone il “comportamento” (adversary behaviors) e le modalità d’interazione con gli elementi del sistema target. Questo tipo di minacce sono anche note come APT (Advanced persistence threat) e consentono di stabilire una presenza illecita e duratura all’interno di una rete aziendale. I target tipici di questi attacchi sono gli enti governativi e/o aziende per le quali le conseguenze dell’intrusione vanno dal furto di brevetti industriali, alla compromissione di informazioni personali di impiegati o pazienti, fino ad arrivare al sabotaggio di intere infrastrutture critiche e siti produttivi (si veda ad esempio Stuxnet).

Questo articolo è stato estratto dal white paper “Email Security: Intelligenza Artificiale, Protocolli e Best Practice Contro gli Attacchi Informatici” disponibile in maniera libera e gratuita al seguente link: https://www.ictsecuritymagazine.com/pubblicazioni/email-security-intelligenza-artificiale-protocolli-e-best-practice-contro-gli-attacchi-informatici/

Articolo a cura di Fabrizio Giorgione

Profilo Autore

Fabrizio Giorgione è nato a Napoli (NA) nel 1992. Si è laureato in ingegneria informatica presso l’università degli studi del Sannio il 17 dicembre del 2018 con una tesi dal titolo: “Analisi della superficie di un sistema SCADA”. Ha sviluppato, presso il laboratorio ISWATlab, un’applicazione Android denominata “Privacy Guard” la quale valuta il rischio di privacy leakage, ovvero il furto di informazioni, sugli smartphone (http://www.iswatlab.eu/?page_id=499). Ha effettuato il tirocinio presso lo “ZLab” di “Cse Cyber Sec” nell’ambito “SOC”, “Forensic” e “Malware Analysis”. Attualmente lavora presso la società di “NTT DATA” come “Cyber security Analyst” nel SOC di Napoli. Il suo compito è quello di effettuare analisi di log, di malware e di prevenire minacce interne ed esterne alla sua azienda e ai clienti della società. Si è occupato, inoltre, del montaggio e della gestione di sonde IDS/IPS presso Telecom Italia nella sede di Roma (RM).

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/email-security-social-engineering-e-threat-intelligence/




Ruolo del gestore del sistema telematico nelle attività di digital forensics

Non di rado gli inquirenti, quando risulta necessario ricorrere alla digital forensics, si trovano a fronteggiare una serie di problematiche relative all’accesso al sistema informatico da analizzare. Oltre alle tecniche di anti forensics volte all’alterazione dei dati o semplicemente funzionali al rallentamento dell’attività investigativa, è frequente, infatti, che l’autorità procedente si trovi a dover operare su supporti e sistemi protetti da password o su informazioni oscurate mediante l’utilizzo di metodi crittografici[1] (c.d. data hiding).

Il problema che si pone per gli investigatori sta nel fatto che talvolta i sistemi di crittografia o di protezione potrebbero risultare particolarmente ostici da superare se non addirittura dannosi per l’indagine, come ad esempio può accadere nel caso in cui la crittografia includa sistemi di sicurezza informatica programmati alla cancellazione dei dati protetti o al blocco definitivo del dispositivo per il caso di tentativi di violazione, così implicando un elevato rischio di perdita del possibile elemento di prova.

Appare evidente come in dette situazioni il ricorso all’ausilio di privati esperti del settore o, ancora meglio, dello stesso gestore del sistema telematico attenzionato, possa apportare un contributo non indifferente per la buona riuscita dell’indagine. Il gestore, infatti, potrebbe essere a conoscenza delle debolezze del sistema e delle falle nella sicurezza, potendo talora, almeno in linea teorica, consegnare nelle mani dell’autorità procedente la chiave per l’accesso al dispositivo o comunque facilitare di molto le operazioni per “bucarne” le difese.

In ragione di ciò occorre capire se i privati, tra i quali il gestore del sistema telematico, abbiano un dovere a collaborare alle indagini, oppure se possano rifiutarsi di prestare la loro cooperazione. In altri termini, bisogna comprendere se l’autorità procedente possa pretendere tale assistenza – obbligo che è stato definito da taluno «servitù di giustizia»[2] – oppure se il privato possa muovere opposizione a simile pretesa.

Partendo dal presupposto che è pacifico, nel nostro ordinamento, che tale pretesa non possa essere avanzata nei confronti dell’indagato e dell’imputato, stante il principio del nemo tenetur se detegere (inteso come il diritto a non dover compiere comportamenti autoincriminanti) ed è altrettanto pacifico che tale richiesta possa, invece, essere rivolta ai consulenti tecnici e privati obbligati a prestare la loro opera in base alle norme codicistiche[3], bisogna capire se tale obbligo sussista anche in capo al gestore del sistema telematico, il quale potrebbe trovarsi nella scomoda situazione di dover mettere a nudo le vulnerabilità del proprio sistema o peggio, a dover creare delle vulnerabilità ad hoc o rivelare stratagemmi capaci di eludere la propria sicurezza a soggetti che, sebbene membri delle forze dell’ordine o da questi delegati, sono comunque esterni all’azienda. Sotto altri punti di vista potrebbero profilarsi, poi, anche problemi collegati al diritto alla riservatezza, poiché fornire la chiave di crittografia di un sistema telematico, in linea teorica potrebbe rendere accessibile non solo il contenuto crittografato del dispositivo sotto indagine ma anche quello degli altri utenti che condividono la stessa struttura di crittografia.

In buona sostanza, giuridicamente parlando, si tratta quindi di stabilire fino a che punto l’esigenza di ordine pubblico possa spingersi nella compressione di diritti individuali a garanzia della sicurezza sociale, in tema di indagini informatiche[4].

Volgendo lo sguardo fuori dal nostro sistema giuridico, si deve rilevare come l’ipotesi per la quale l’esigenza investigativa possa scavalcare le ragioni del gestore informatico è stata presa in considerazione anche presso altri paesi. Già da tempo, infatti, in diversi ordinamenti si è discusso sull’opportunità di imporre alle compagnie informatiche di progettare apposite backdoors ad uso investigativo, con ciò intese delle «intenzionali vulnerabilità che l’autore del sistema dovrebbe introdurre nel proprio protocollo di crittografia, fornendone poi la chiave alla forza pubblica così da consentire di accedere, legalmente, ai dati cifrati a fine d’indagine e prevenzione di crimini particolarmente gravi»[5].

In particolare è interessante osservare come la questione si sia posta in termini pressoché identici nell’ordinamento statunitense, dove sul punto si è sviluppato un nutrito dibattito andato alla ribalta con il caso giurisprudenziale che ha visto contrapposti il Federal Bureau of Investigation (F.B.I.) da una parte e il gigante informatico Apple Inc. dall’altra.

Il caso prendeva le mosse dall’indagine condotta dall’F.B.I. a seguito dell’attentato terroristico di matrice jihadista islamica passato alla cronaca come “la strage di San Bernardino”, portato a segno nell’omonima località della California meridionale nell’autunno del 2015.

Stando all’accadimento dei fatti, durante l’attività investigativa gli inquirenti erano riusciti a rinvenire lo smartphone di uno degli attentatori e a porlo sotto sequestro per l’espletazione delle analisi di informatica forense. Tuttavia, il dispositivo risultava protetto da un complesso sistema crittografico volto alla difesa da accessi indebiti, che in caso di troppi errori nel tentativo di decifrazione avrebbe automaticamente (e definitivamente) cancellato le informazioni delle quali era posto a protezione[6].

Vista la delicatezza della situazione, al fine di salvaguardare il contenuto digitale del dispositivo che avrebbe apportato un rilevante impulso per le indagini, i detectives dell’F.B.I. si appellavano direttamente alla multinazionale di tecnologia Apple Inc., in qualità di produttrice del modello di smartphone sequestrato e di responsabile del relativo sistema telematico, chiedendo a quest’ultima di prestare la propria collaborazione per lo sblocco del telefono.

Nello specifico veniva formulata richiesta nei confronti della società di creare e mettere nelle mani degli inquirenti un software apposito funzionale all’inibizione del sistema di distruzione dei dati, così da consentire alla pubblica autorità di poter eseguire in totale sicurezza tutti i tentativi che si sarebbero resi necessari per bypassare le difese del dispositivo.

La richiesta di cooperazione, tuttavia, veniva disattesa dalla società. Per il gigante informatico, infatti, la creazione di un programma finalizzato allo scopo voluto dagli investigatori, oltre a manifestarsi in palese contrasto con le politiche di riservatezza perseguite dalla società, se per qualsiasi motivo fosse finito nelle mani sbagliate avrebbe potuto mettere a rischio la privacy di tutti gli utenti in possesso del medesimo sistema.

Questo netto rifiuto finiva per costituire il presupposto per l’attivazione della disputa giudiziaria instaurata dall’F.B.I., rappresentata dal Dipartimento di Giustizia degli Stati Uniti, nei confronti della Apple Inc. Giudizio conclusosi con la dichiarazione di rinuncia alla prosecuzione dell’azione da parte del dipartimento della polizia federale, poiché nel frattempo, nonostante la mancata collaborazione, gli investigatori del Federal Bureau of Investigation erano ugualmente riusciti a superare le difese dello smartphone[7]. Ad ogni modo, pronunce più recenti vertenti su questioni analoghe hanno visto disattese le richieste della pubblica autorità in favore delle ragioni opposte dai responsabili dei sistemi informatici[8].

Per quanto concerne il nostro ordinamento si deve precisare che precedenti plateali come quello appena analizzato, per il momento, non si sono ancora verificati; ciononostante la questione giuridica si propone ugualmente di attualità.

A differenza dell’esperienza statunitense, però, parrebbe che per il nostro assetto normativo l’interesse alla sicurezza collettiva debba essere considerato preponderante rispetto ai diritti dei singoli, fatta eccezione per una serie di situazioni giuridiche, tassative, che fanno da limite all’espansione del diritto alla sicurezza della collettività con conseguente riverbero in tema di repressione del crimine e quindi con effetti limitativi alla funzione investigativa: si pensi ad esempio alla centralità del diritto di difesa che impone il divieto di intercettare le conversazioni tra imputato e difensore, al diritto di non incriminarsi, alla tutela apprestata dalla legge al segreto professionale o, ancora, alle garanzie costituzionali relative alla dignità della persona[9].

Pertanto, al di fuori delle limitazioni espressamente previste dalla legge, è ben possibile che il gestore di un sistema telematico sia chiamato a prestare obbligatoriamente la propria assistenza alle forze dell’ordine anche nell’evenienza di indagini di digital forensics.

Questo articolo è stato estratto dal white paper “La Digital forensics nel processo penale” disponibile in maniera libera e gratuita al seguente link: https://www.ictsecuritymagazine.com/pubblicazioni/digital-forensics-nel-processo-penale/

Note

[1] Per crittografia s’intende quella «tecnica di rappresentazione di un messaggio in una forma tale che l’informazione in esso contenuta possa essere recepita solo dal destinatario; ciò si può ottenere con due diversi metodi: celando l’esistenza stessa del messaggio o sottoponendo il testo del messaggio a trasformazioni che lo rendano incomprensibile», https://www.treccani.it/enciclopedia/crittografia/#:~:text=crittografia%20Tecnica%20di%20rappresentazione%20di,a%20trasformazioni%20che%20lo%20rendano.

[2] Tale locuzione è utilizzata in M. TORRE, op. cit., p. 1675 e pp. 1684 – 1685.

[3] Si veda ad esempio l’art. 359 c.p.p. in tema di accertamenti tecnici dove si precisa che i consulenti «non possono rifiutare la loro opera».

[4] La questione è posta in termini simili anche in M. TORRE, op. cit., pp. 1675 e ss.

[5] R. DE VITA e L. LAUDISA, “Vita digitale a rischio: i captatori informatici tra pericoli per i diritti umani e riduzionismo giuridico”, in Osservatorio CyberSecurity Eurispes, p. 3, articolo del 18 novembre 2019, consultabile sul sito https://www.devita.law/wp-content/uploads/2019/11/Vita-digitale-a-rischio.pdf.

[6] Nel particolare tecnico, il dispositivo recuperato dalla polizia «risultava bloccato da un codice di blocco a 4 cifre e impostato per il wiping dei dati dopo 10 tentativi falliti nell’inserimento del codice di blocco, opzione presente nei dispositivi iPhone», così F. MASSA, “Il caso San Bernardino: APPLE vs FBI” in sicurezzaegiustizia.com, consultabile sul sito https://www.sicurezzaegiustizia.com/il-caso-san-bernardino-apple-vs-fbi/. Quindi, il sistema di blocco consisteva in una strategia di sicurezza messa direttamente a disposizione dalla casa produttrice del congegno e non una struttura difensiva messa a punto dall’attentatore. È intuibile comprendere, dunque, come il gestore del sistema telematico avrebbe potuto aggirare le difese del dispositivo con relativa semplicità, o comunque apportare un contributo non indifferente al lavoro delle forze di polizia.

[7] Per una ricostruzione dettagliata della vicenda processuale in questione si rimanda a M. TORRE, op. cit., pp. 1678 e ss., qui preme osservare come un prima pronuncia sulla questione accoglieva le pretese del Dipartimento di Giustizia. Altri casi analoghi, invece, anche successivi alla vicenda riportata, hanno visto le richieste della forza pubblica disattese in favore delle ragioni dei gestori di sistemi telematici.

[8] Ibidem.

[9] Cfr. M. TORRE, op. cit., p. 1685.

Articolo a cura di Francesco Lazzini

Profilo Autore

Laureato in giurisprudenza con successivo conseguimento dei master in Scienze Forensi (Criminologia-Investigazione-Security-Intelligence) e in Informatica giuridica, nuove tecnologie e diritto dell’informatica. Attività di studio postuniversitario focalizzata in materia di indagini con l’utilizzo del captatore informatico e digital forensics.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/ruolo-del-gestore-del-sistema-telematico-nelle-attivita-di-digital-forensics/




Esempi di attacchi cyber e guasti accidentali a CPS

Di seguito si descrivono brevemente alcuni tra i più famosi attacchi contro CPS, divenuti noti ai mezzi di informazione.

Si sottolinea che, in generale, i soggetti attaccati preferiscono tacere su quanto subito, salvo che sia impossibile tacere, proprio per evitare di ammettere la propria vulnerabilità e, di conseguenza, perdere la fiducia di clienti e investitori.

1. Maroochy Shire Sewage Spill. Nel 2000 un ex dipendente di Maroochy Water Services ha violato 142 stazioni di pompaggio delle acque reflue e ha causato la fuoriuscita di circa un milione di litri di acque reflue nei sistemi idrici locali. L’attacco è stato effettuato solo con un laptop, un PC compatto e un trasmettitore radio. L’ex dipendente vendicativo ha avuto accesso al sistema con le proprie credenziali, colpevolmente non disabilitate dall’azienda dopo il suo allontanamento, e ha agito come un insider, e, muovendosi tra le stazioni di pompaggio dell’infrastruttura ha manipolato le configurazioni di sistema. Questo incidente è un buon esempio per mostrare come l’utilizzo delle credenziali conosciute dagli ex dipendenti possa causare incidenti. Occorre una gestione efficace e puntuale del controllo degli accessi da parte delle organizzazioni, revocando tempestivamente le credenziali a chi smetta di averne necessità o diritto.

2. Stuxnet. Nel 2009 l’impianto nucleare dell’Iran è stato preso di mira dall’attacco più complesso conosciuto fino ad oggi. Stuxnet ha infettato più di 100.000 host in 25 Paesi, con il 60% degli host infettati in Iran. Ha preso di mira in modo specifico vulnerabilità esistenti nei sistemi operativi Microsoft e nei PLC Siemens, pur rimanendo nascosto, riuscendo a deteriorare le centrifughe per l’arricchimento dell’uranio, senza che ai sistemi di monitoraggio arrivassero indicazioni di problemi in corso. Si sostiene che Stuxnet sia stato sviluppato dagli Stati Uniti e da Israele per sabotare il programma iraniano di arricchimento dell’uranio. Tuttavia, non ci sono state conferme ufficiali in tal senso. In particolare, è stato sfruttato il fatto che ai PLC Siemens non fosse stata cambiata la password di default.

3. Saudi Aramco Attack. Nel 2012 il produttore di petrolio e gas Saudi Aramco è stato preso di mira da un malware successivamente denominato Shamoon. Gli aggressori hanno avuto accesso alla rete aziendale e hanno distribuito il malware, che ha eliminato i dati relativi alla produzione. Poiché la distribuzione di quel tipo di malware richiede l’accesso fisico ai computer interni, si ritiene che gli aggressori abbiano avuto anche l’aiuto di un insider. L’attacco, che non è riuscito ad accedere alla componente OT, è stato rivendicato dal gruppo “The Cutting Sword of Justice” per motivi politici.

4. Fukushima Daiichi Nuclear Disaster. Nel 2011 un terremoto ha interrotto l’operatività della centrale nucleare di Fukushima Daiichi danneggiando i sistemi di alimentazione che raffreddano i reattori, provocando contaminazione radioattiva e rendendo necessaria l’evacuazione di circa 100.000 residenti. I disastri naturali sono prevedibili solo in una certa misura; di solito, i rischi che possono verificarsi a causa di questi eventi vengono ignorati durante la progettazione del CPS. L’incidente all’impianto nucleare di Fukushima Daiichi ha portato al riesame delle infrastrutture strutture simili, per verificare quanto siano sicure contro i disastri naturali e i conseguenti guasti provocati da questi ultimi.

5. Tridium Niagara Framework Attack. Nel 2012 gli aggressori si sono infiltrati nel sistema HVAC (Heating, Ventilation and Air Conditioning) di un’azienda con sede negli Stati Uniti. L’azienda utilizzava una versione non aggiornata di Tridium Niagara (software per il monitoraggio e l’individuazione di anomalie), contenente diverse vulnerabilità che consentono l’accesso backdoor. Queste vulnerabilità erano all’epoca già state rese note e e descritte da diverse organizzazioni di sicurezza informatica. Tuttavia, la società vittima non era a conoscenza del problema, né aveva aggiornato i propri sitemi. Il CPS era connesso a Internet con protezione basata su password. Gli aggressori, che hanno ottenuto privilegi di amministrazione senza conoscere la password, sfruttando la vulnerabilità già nota, non hanno comunque avuto accesso ad alcun documento
significativo e la motivazione dietro l’attacco è rimasta sconosciuta.

6. Target Attack. Nel 2013 le anomalie nel sistema informatico di Target sono state scoperte da un team esterno all’organizzazione, specializzato in analisi per la sicurezza informatica. Gli aggressori avevano avuto accesso alle informazioni personali di oltre 1.000.000 di clienti. L’elenco dei fornitori di terze parti era accessibile nel portale di Target, e gli aggressori hanno scelto Fazio Mechanical (produttore HVAC) e inviato un’e-mail di phishing a uno dei dipendenti, che ha consentito l’installazione del malware e rubato le credenziali di accesso di Fazio Mechanical. Hanno così avuto accesso alla rete aziendale e rubato informazioni personali con la motivazione del guadagno finanziario. Questo incidente è unico per il modo in cui gli aggressori hanno avuto accesso alla rete IT, ovvero compromettendo prima la rete OT.

7. Godzilla Attack! Turn Back!. Nel 2013 i segnali stradali elettronici a San Francisco, (Stati Uniti) sono stati violati e, invece di messaggi su viabilità e traffico, mostravano “Godzilla Attack” e “Turn Back!” I segnali erano controllati da una società esterna che utilizzava ancora le credenziali predefinite per accedere alla rete. L’incidente non ha causato problemi significativi. La società responsabile dei segnali ha affermato che l’attacco è stato compiuto da qualcuno che già conosceva le credenziali. Si ritiene che la motivazione dietro l’attacco fosse meramente ludica.

8. Brute Force Attacks on Internet-Facing Control Systems. Nel 2013 il proprietario di una stazione di pompaggio del gas negli Stati Uniti ha allertato ICS-CERT in merito a un aumento del numero di tentativi di attacco basati su forza bruta ai propri sistemi, eseguiti da 49 diversi indirizzi IP. Gli attori della minaccia e la motivazione dietro gli attacchi, nessuno dei quali ha avuto successo, sono ancora sconosciuti. Questo caso è un buon esempio per dimostrare come il rilevamento tempestivo dei tentativi di intrusione prevenga ulteriori danni ai sistemi industriali, aumentando la possibilità di una risposta efficace.

9. German Steel Mill Cyberattack. Nel 2014 è stato attaccato l’altoforno di un’acciaieria tedesca. Non essendo stato possibile spegnere la fornace, l’attacco ha provocato ingenti danni fisici. Gli aggressori hanno avuto accesso alla rete aziendale tramite un’e-mail di phishing, quindi si sono trasferiti sulla rete industriale e hanno eseguito il codice dannoso per riprogrammare diversi PLC e compromettere le funzioni della fornace. Hanno sfruttato le vulnerabilità risultanti dalla debole protezione dei confini tra le reti a causa della mancanza di zone demilitarizzate (DMZ) che espongono la rete locale alla rete esterna. L’attacco è stato definito APT (Advanced Persistent Threat) e si ritiene sia stato eseguito da un gruppo con l’obiettivo del furto della proprietà intellettuale.

10. Kemuri Water Company Attack. Nel 2016 Verizon ha pubblicato un rapporto su un attacco a una società di trattamento delle acque. L’azienda aveva memorizzato le credenziali di accesso al sistema OT sul server Web front-end. Gli aggressori, che hanno avuto accesso a tali credenziali tramite SQL injection e phishing, hanno riprogrammato gli attuatori di controllo ma non sono riusciti a causare alcun danno a causa della mancanza di esperienza sui sistemi SCADA. Tuttavia, si ritiene siano state rubate le informazioni personali di circa 2.500.000 utenti.

11. Ukrainian Power Grid Attack. Nel 2015 la società di distribuzione elettrica ucraina Kyivoblenergo è stata oggetto di un attacco che ha provocato un’interruzione di corrente che ha interessato 225.000 utenti. Gli aggressori hanno avuto accesso alla rete IT tramite e-mail di phishing, quindi hanno acquisito le credenziali per infiltrarsi nella rete OT, ove eseguire il malware, denominato BlackEnergy 3; hanno poi continuato ad attaccare il sistema a intervalli di 30 minuti, per impedire l’attivazione di tecniche di mitigazione.

12. TRITON. Nel 2017 il Safety Instrumented System (SIS) di una società di servizi petroliferi e gas del Medio Oriente è stato spento a causa dell’esecuzione riuscita di un malware denominato TRITON. Un controller SIS, realizzato da Schneider Electric e connesso a un PC Windows, è stato disattivato lasciando l’intera utility vulnerabile agli incidenti OT. Gli aggressori si sono prima infiltrati nella rete IT, quindi sono passati all’OT sfruttando la debole protezione del confine tra queste reti.

13. Cryptocurrency Malware Attack on SCADA. Nel 2018 è stato scoperto un malware sul sistema OT di un’azienda europea di servizi idrici. Il malware, progettato per estrarre la criptovaluta Monero utilizzando i server HMI e SCADA della vittima, era in grado di funzionare in modalità invisibile, ma l’IDS ha rilevato un aumento dell’utilizzo della CPU e della larghezza di banda. L’aggiornamento dei sistemi OT richiede pianificazioni a lungo termine e quindi la maggior parte dei sistemi non può ricevere tempestivamente gli aggiornamenti più recenti. In questo caso, le applicazioni HMI non aggiornate, collegate a Internet per consentire la gestione remota, sono state violate dagli aggressori per accedere al sistema.

14. Norsk Hydro Ransomware Attack. Nel 2019 la società produttrice di alluminio Norsk Hydro ha subito un attacco ransomware successivamente denominato LockerGoga. Gli aggressori hanno effettuato l’accesso e crittografato i dati critici, provocando l’arresto della rete aziendale e l’interruzione di molte operazioni, inclusa l’elaborazione degli ordini. Poiché gli avversari, dopo aver ottenuto l’accesso al sistema, hanno scelto di eseguire un ransomware precedentemente noto, si stima che l’attacco mirasse a interrompere la produzione per colpire la reputazione dell’azienda piuttosto che a un guadagno finanziario.

15. Riviera Beach Ransomware Attack. Nel 2019, i servizi idrici di Riviera Beach (una piccola città situata in Florida, USA) sono stati oggetto di un attacco ransomware. Gli aggressori hanno inviato un’e-mail di phishing e il destinatario ha consentito all’attacco di raggiungere tutte le reti cittadine, compresi i sistemi di utenza idrica, a causa dell’interconnessione alla rete informatica senza alcun meccanismo di protezione specifico. Il consiglio comunale ha accettato di pagare il riscatto di 65 Bitcoin (circa $ 600.000 entro quella data); tuttavia, gli aggressori non hanno inviato la chiave di decrittazione. Quindi il consiglio comunale ha deciso di rinnovare i sistemi oggetto dell’attacco.

16. Florida Water Treatment Poisoning Attack. L’8 febbraio 2021 un attaccante ha tentato di avvelenare Oldsmar, una città della Florida negli Stati Uniti. L’attaccante ha avuto accesso al computer che ospita il software di controllo del trattamento dell’acqua tramite un programma di accesso remoto (TeamViewer), quindi ha aumentato la quantità di idrossido di sodio al di sopra del livello normale. Il cambiamento di concentrazione dell’acqua è stato rilevato da un operatore e immediatamente annullato e l’accesso remoto è stato disabilitato. L’avversario non ha infatti falsificato le letture del sensore per ingannare l’operatore, contrariamente a quanto avvenuto per Stuxnet, quindi il cambiamento inaspettato è stato rilevato tempestivamente. Il modo in cui sono state acquisite le credenziali del computer è ancora sconosciuto. In questo incidente, avere personale IT operativo 24 ore su 24, 7 giorni su 7 (che non è il caso della maggior parte dei sistemi industriali) per supervisionare il sistema ha impedito che si verificasse un disastro dalle gravi conseguenze.

17. Colonial Pipeline Ransomware Attack. Il 7 maggio 2021 Colonial Pipeline, una compagnia con sede a Houston (Texas) che trasporta benzina e carburante per aerei mediante un sistema di oleodotti, principalmente negli Stati Uniti sudorientali, ha subito un attacco informatico ransomware che ha avuto un impatto sulle apparecchiature computerizzate che gestiscono l’oleodotto. La Colonial Pipeline Company ha interrotto tutte le attività dell’oleodotto per contenere l’attacco. Sotto la supervisione dell’FBI, la società ha pagato l’importo richiesto dal gruppo DarkSide (75 bitcoin o $ 4,4 milioni di dollari.) Al ricevimento del riscatto gli attaccanti hanno fornito alla compagnia uno strumento informatico per ripristinare il sistema, che tuttavia ha richiesto un tempo di esecuzione assai lungo per giungere al completo ripristino. La Federal Motor Carrier Safety Administration ha emesso una dichiarazione di emergenza regionale per 17 Stati e Washington DC per mantenere aperte le linee di rifornimento di carburante nei giorni successivi all’attacco. È stato il più grande attacco informatico su un obiettivo di infrastrutture petrolifere nella storia degli Stati Uniti. L’FBI e varie fonti dei media hanno identificato il gruppo criminale DarkSide come parte responsabile, ritenendo che lo stesso gruppo avesse rubato 100 gigabyte di dati dai server aziendali nei giorni precedenti. Il 7 giugno, il Dipartimento di Giustizia ha annunciato di aver recuperato 63,7 bitcoin (circa 2,3 milioni di dollari) del pagamento del riscatto. Questo è stato uno dei primi attacchi informatici aziendali di alto profilo che ha avuto inizio da una password personale di un dipendente violata, e probabilmente trovata nel dark web, piuttosto che da un attacco diretto ai sistemi dell’azienda.

Gli attacchi contro i CPS si articolano generalmente in più fasi, e quelli avanzati possono eseguire l’intera Cyber Kill Chain (CKC). L’integrazione di reti IT e OT senza che ci sia una protezione dei confini solida e sicura è l’elemento che si riscontra sia usato più frequentemente negli attacchi.

Le 10 vulnerabilità più sfruttate nei CPS

Gli aggressori prendono di mira principalmente le aziende prive di personale di sicurezza con esperienza nella sicurezza industriale tramite e-mail di phishing; altre (con) cause negli esempi analizzati sono sempre legate al fattore umano, ad esempio il mancato aggiornamento di sistemi e applicativi software o una gestione carente delle credenziali, dal non modificare le password di fabbrica dei dispositivi a non disabilitare tempestivamente le credenziali di chi non ne abbia più diritto o necessità. Anche carenze progettuali e/o implementative, talvolta volute per comodità di accesso remoto semplificato, che rendono debole o inesistente la separazione tra le parti IT e OT di un sistema – eventualmente in concomitanza con le “disattenzioni” di cui sopra – possono consentire a un attaccante di accedere facilmente alla parte OT, ove poter causare ingenti danni.

Quando gli effetti degli attacchi si manifestano a livello OT, a causa degli eventuali danni inferti a cose e/o persone, per l’azienda vittima può essere più difficile occultare l’evento. D’altro canto, la maggior parte delle aziende soggette a violazione dei dati rifiuta di pubblicare un rapporto pubblico sugli incidenti per non intaccare la propria reputazione. Le informazioni sugli incidenti sono per lo più disponibili tramite agenzie di stampa o blogger di sicurezza informatica che affermano di ottenere informazioni tramite informatori (ad esempio, ex o attuali dipendenti sotto pseudonimo), rendendo più difficili ulteriori esami.

Questo articolo è stato estratto dal white paper “Industrial Cybersecurity” disponibile in maniera gratuita al seguente link: https://www.ictsecuritymagazine.com/pubblicazioni/industrial-cybersecurity/

Articolo a cura di Luca Durante

Profilo Autore

Luca Durante è Primo Ricercatore presso l’Istituto di Elettronica e Ingegneria dell’Informazione e delle Telecomunicazioni del Consiglio Nazionale delle Ricerche (CNR-IEIIT) di Torino.
Nel 1996 ha conseguito il Dottorato di Ricerca in Ingegneria Informatica presso il Politecnico di Torino, è autore di oltre 70 articoli per riviste e conferenze internazionali, ed è stato ed è tuttora Responsabile Scientifico per il CNR in Progetti Europei e in contratti di ricerca con aziende.
È stato inoltre general co-chair, program co-chair e membro del comitato di
programma di conferenze internazionali, associate editor di IEEE Transactions on Industrial Informaatics e revisore per riviste internazionali.
Gli interessi di ricerca vertono principalmente sulle tematiche di sicurezza
informatica, attualmente declinati sulle policy di sicurezza per il controllo di accessi e la sicurezza dei sistemi cyber-fisici.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/esempi-di-attacchi-cyber-e-guasti-accidentali-a-cps/




La catena di custodia della digital evidence

In linea generale, una volta raccolto il reperto dalla scena del crimine sorge l’esigenza di conservarne l’originale autenticità in tutti i passaggi successivi – anche mediante documentazione dei singoli spostamenti e indicando chi vi entra in contatto – affinché possa giungere inalterato sino al dibattimento e affinché, in tale sede, possa esserne opportunamente verificata l’attendibilità, valutando la corretta applicazione dei principi cardine della c.d. catena di custodia, espressione con cui «vengono indicati l’insieme di passaggi, formalizzati con un sistema di tracciamento (manuale o elettronico), attraverso i quali il reperto, o meglio i plichi ed i confezionamenti in cui è conservato, transita dalla scena del crimine alla fase del giudizio»[1].

In altre parole, la catena di custodia è la «documentazione cronologica che mostra la conservazione dei reperti dal momento della raccolta a quello della produzione in giudizio»[2] e che permette in sede giudiziale di poter valutare l’attendibilità del reperto sotto i profili della sua integrità e genuinità, o meglio di verificare che durante tutti i passaggi che hanno coinvolto il reperto sia stato salvaguardato l’insieme di informazioni che intrinsecamente possiede[3].

Alla necessità di rispettare i principi della catena di custodia, basilari per la buona riuscita dell’indagine, non fa eccezione nemmeno la prova informatica; caratterizzata, inoltre, da una fragilità che impone un’attenzione ancora maggiore onde impedirne modificazioni involontarie.

Esaurita, dunque, la fase di acquisizione dei dati dal supporto oggetto d’investigazione, le digital evidence ottenute devono essere salvaguardate per garantire il loro ingresso all’interno del processo nello stesso stato nel quale sono state rinvenute. A tal fine occorrerà conservare adeguatamente sia la copia forense che tutte le altre copie che potranno essere estratte a partire da quest’ultima.

Allo stesso modo, al fine di assicurare l’integrità dell’intero quadro probatorio, occorre che anche rispetto al supporto originale siano dettagliatamente documentati gli spostamenti e le fasi operative o conservative che lo interessano, dal suo rinvenimento fino al giudizio.

Nonostante la centralità di questa fase, esattamente come avviene per l’acquisizione, non è però rinvenibile una normativa atta a disciplinarne con chiarezza i passaggi.

La sola disposizione cui è possibile fare riferimento, infatti, è contenuta nel comma 2 dell’art. 260 c.p.p., rubricato “apposizione dei sigilli alle cose sequestrate. Cose deperibili. Distruzione di cose sequestrate”[4], dove non viene indicata una procedura precisa ma è unicamente previsto che “quando si tratta di dati, di informazioni o di programmi informatici, la copia deve essere realizzata su adeguati supporti, mediante procedura che assicuri la conformità della copia all’originale e la sua immodificabilità…”.

Anche in questo caso la strategia del legislatore, stando alla terminologia adoperata, è lasciare la possibilità di fare ricorso alle best practices indicate dalle linee guida internazionali, senza imporre modalità attuative già predeterminate agli operatori.

Anche in questo caso però il ricorso alle migliori pratiche, stante l’omissione dell’indicazione di precise conseguenze in caso di violazione, non sembrerebbe comportare conseguenze sul piano della validità del reperto informatico.

Per la giurisprudenza, in particolare, la disposizione non imporrebbe modalità di custodia obbligatorie, contenendo direttive puramente indicative e di conseguenza derogabili sia per ragioni di assoluta impossibilità che di opportunità. Pertanto, scelte operative inidonee potrebbero avere effetto solo sotto il profilo della valutazione della prova ex art. 192 c.p.p., senza alcuna ripercussione nell’ottica della nullità o inutilizzabilità processuale del reperto digitale[5].

In buona sostanza, la giurisprudenza, ha riadattato le medesime conclusioni alle quali era già pervenuta in tema di acquisizione di digital evidence, sdoganando – anche nella fase della catena di custodia – il principio in base al quale il mancato rispetto di buone pratiche non costituisce automaticamente motivo di invalidità della prova informatica, potendo semmai costituire uno strumento per calibrare il peso giudiziario dell’elemento probatorio. È chiaro che in ogni caso, al fine di non incappare in un vizio motivazionale, il giudice in sentenza resta vincolato al dovere di evidenziare le motivazioni che lo hanno addotto a prendere in considerazione elementi di prova provenienti da processi investigativi derogatori dei principi della catena di custodia.

Non vi è dubbio, comunque, che il rispetto delle indicazioni elaborate dagli standard internazionali fornisca un alto grado di attendibilità al reperto informatico, essendo pertanto detti principi, seppur non cogenti, diffusi nelle prassi operative. Ciò perché seguire tali principi per la custodia dei dati rende di fatto possibile, anche in momenti successivi, verificare l’autenticità del materiale informatico raccolto che potrà essere direttamente visionato, nonché pienamente conosciuto, sia dalle parti sia dal giudice stesso[6].

Dal punto di vista tecnico, nella digital forensics, la catena di custodia si concretizza consiste in un documento all’interno del quale viene riportata, oltre alla descrizione del reperto digitale, ciascuna operazione svolta in relazione al medesimo con l’indicazione del momento di svolgimento (data e ora) e del soggetto materialmente intervenuto. Altre informazioni possono riguardare gli spostamenti, il luogo di custodia e le modalità con la quale questa viene attuata[7].

In termini pratici, all’interno di tale documento viene descritto l’intero arco di vita della digital evidence nel contesto investigativo, dal momento della sua raccolta alla presentazione innanzi all’autorità giudiziaria[8].

Per garantire il corretto funzionamento del meccanismo di conservazione è altresì necessario provvedere all’apposizione dei sigilli sia sul dispositivo originale, sia sui supporti contenenti le copie forensi[9].

Un’eventuale compromissione del sigillo potrà infatti rivelare una possibile manomissione dell’evidenza elettronica, con conseguente inattendibilità del materiale probatorio sul piano processuale.

La peculiarità della digital forensics, inoltre, impone di ragionare sul concetto di protezione dell’evidenza digitale da fattori esterni, con ciò intesi fenomeni provenienti da fonti estranee all’evidenza digitale e al supporto che la ospita ma capaci di influenzarne irrimediabilmente l’integrità e capaci di alterazioni da remoto, bypassando il sistema di sigilli fisico (pertanto molto complessi da individuare).

La questione della protezione della digital evidence dal pericolo di aggressioni ha ricevuto l’attenzione dei più importanti standard internazionali, tra i quali risalta l’ISO/IEC 27037:2012.

In particolare, le linee guida offerte da quest’ultimo si focalizzano sulla necessità di tutelare il dato informatico da fenomeni di perdita (loss), manomissioni (tampering) e distruzioni (spoliation) di informazioni, durante la fase di raccolta, trasporto e stoccaggio nel luogo finale di conservazione.

Infatti – prelevata la possibile prova dalla scena del crimine – occorre fare in modo che questa, una volta confezionata, giunga nel sito di deposito senza subire contaminazioni. È proprio un opportuno confezionamento o impacchettamento del materiale probatorio rinvenuto che scongiura quanto più possibile il prodursi di fenomeni deteriorativi, che possono provenire sia da condizioni naturali che da attività dolose o colpose (come ad esempio errori involontari degli operatori).

Le cause di deterioramento naturale che possono colpire il dato digitale possono riguardare fenomeni ambientali (ad esempio l’umidità, che come risaputo danneggia i sistemi elettronici, fonti di calore oppure, qualora il reperto si trovi all’aperto, pioggia e condizioni atmosferiche in generale: dalla grandine che potrebbe colpire la componente hardware, ai fulmini che potrebbero mandare in tilt il sistema).

I fenomeni volontari, invece, possono consistere sia in danneggiamenti fisici prodotti direttamente sul supporto informatico sia in attacchi da remoto mediante accesso abusivo al sistema. Si pensi a dispositivi accesi con sistema bluetooth attivato, collegati ad altri dispositivi o direttamente connessi alla rete, dove qualsiasi utente in linea può rappresentare un rischio concreto di alterazione. Infine, occorre tenere presente l’alta sensibilità degli apparecchi elettronici nei confronti di campi elettromagnetici, onde radio e in generale frequenze generate da altri sistemi elettronici che potrebbero interferire irreversibilmente sull’integrità del dato, se non addirittura rendere inservibile il supporto dove è registrato.

Durante la fase di trasporto dell’evidenza digitale, pertanto, è necessario adottare strategie protettive utilizzando strumenti capaci di isolare il dispositivo prelevato dal mondo esterno, sia fisico che digitale.

Per i motivi sopra visti, infatti, non è sufficiente riporre l’elemento di prova informatico all’interno di comuni confezioni, come buste di carta o contenitori di plastica, utilizzati ad esempio per l’impacchettamento dei reperti biologici, ma sono necessarie tutele specifiche con l’ausilio di strumenti adeguati.

Tra le diverse soluzioni vi è l’inserimento del supporto prelevato all’interno di una gabbia di Faraday, ovvero un particolare contenitore composto da materiale elettricamente conduttore in grado di schermare le onde elettromagnetiche e le frequenze radio esterne, così rendendo impossibile l’interazione tra il dispositivo elettronico in esso contenuto e apparecchi o campi elettrostatici esterni[10].

Un altro strumento – per ovvi motivi di difficile impiego nella pratica – è il c.d. jammer, capace di inibire temporaneamente la funzione di emissione e ricezione delle onde radio degli apparecchi elettronici che si trovano all’interno del suo raggio d’azione, rendendo in questo modo impossibile comunicazioni tra questi e il supporto prelevato[11].

Simili strategie, chiaramente, devono essere adottate anche successivamente alla fase di trasporto e più propriamente all’interno del luogo di stoccaggio, dove oltre all’emarginazione del dispositivo dall’esterno potrebbero essere adoperati sistemi di videosorveglianza e sistemi altri accorgimenti per rendere inaccessibile a soggetti non autorizzati l’ingresso ai locali di custodia.

Nonostante tutti gli accorgimenti adottabili sul piano della sicurezza, preme sottolineare come il rischio di alterazione non sia mai completamente eliminabile[12]; talvolta, quindi, potrebbe rendersi necessario analizzare direttamente il supporto repertato per verificare che non vi siano state manomissioni o accessi da persone non autorizzate durante le fasi di raccolta, trasporto e conservazione.

In tali evenienze, procedere con dei controlli mirati si rivelerebbe quindi un utile strumento di garanzia ai fini dell’attendibilità del reperto, che – seppure trattato con la massima precauzione,– soggiace sempre, anche se in percentuali bassissime, al rischio di subire violazioni.

In particolare, a talune condizioni, con l’ausilio di appositi software è possibile ricostruire la timeline del dispositivo[13], per verificare che essa coincida con la sequenza cronologica di utilizzo come descritta nel documento della catena di custodia.

In estrema sintesi, nella digital forensics la catena di custodia costituisce un sistema procedurale che, seppure non obbligatorio sul piano giuridico, si rivela essenziale per il corretto esito delle indagini.

Il rispetto dei relativi principi e il corretto uso della strumentazione atta alla protezione del dato informatico, infatti, garantiscono la possibilità di condurre verifiche ex post sulla vita investigativa del reperto digitale.

Tutto ciò, nell’ottica del giusto processo, consente di consegnare nelle mani dei soggetti coinvolti nella dinamica giudiziale la possibilità di verificare in totale trasparenza l’integrità e l’autenticità del materiale probatorio.

Questo articolo è stato estratto dal white paper “La Digital forensics nel processo penale” disponibile in maniera libera e gratuita al seguente link: https://www.ictsecuritymagazine.com/pubblicazioni/digital-forensics-nel-processo-penale/

Note

[1] R. GENNARI e L. SARAVO, “Tecnica, tecnologia e scienza sulle tracce del reato – Le tracce”, in Manuale delle investigazioni sulla scena del crimine, cit., p. 496, dove gli autori specificano che la catena di custodia è meglio nota con il nome inglese “chain of custody”. Effettivamente, preme sottolineare come tale fase dell’investigazione forense sia propria degli sviluppi avutisi in tale settore nella prassi dei paesi anglosassoni e in particolare in quella dell’ordinamento nordamericano. Su quest’ultimo aspetto si veda R. MURENEC, op. cit., p. 128, nota (269).

[2] F. COLAIUDA, “La qualità dell’investigazione sulla scena del crimine – il metodo di lavoro basato sui protocolli operativi e sulle check lists”, p. 1, consultabile sul sito http://www.associazionelaic.it/wp-content/uploads/2018/07/Colaiuda-3.pdf.

[3] R. GENNARI e L. SARAVO, op. cit., p. 497, dove dopo aver individuato quale obiettivo della catena di custodia la salvaguardia delle informazioni contenute dal reperto si precisa che la protezione afferisce a tre aspetti: quello «Scientifico dovuto alla necessità di preservare le tracce da fenomeni degenerativi e degradativi, nonché da possibili contaminazioni» (si aggiunge che in ottica di digital forensics potrebbe tradursi come la necessità di evitare alterazioni del dato digitale); quello «Formale» per il quale «tutte le fasi di custodia, dal repertamento alle analisi di laboratorio, devono essere opportunamente documentate [… al fine di] garantire che non vi sia pericolo di scambio e che per l’oggetto e le informazioni in esso contenute non vi possano essere altre provenienze al di fuori di quella documentata»; quello «Processuale [che] scaturisce dalla necessità di garantire in qualsiasi fase dell’accertamento, a partire quindi dall’ambito nel quale ha origine il reperto, l’acquisizione e la perfetta gestione della fonte di prova scevra da qualsiasi pericolo di manipolazione o ipotesi di manipolazione che ne potrebbe diminuire il valore probatorio».

[4] Si veda sul punto anche R. MURENEC, op. cit., pp. 128 e 129, dove viene fatto apposito rimando a quanto previsto da detta disposizione ai fini di garanzia dell’attendibilità e inalterabilità della prova informatica.

[5] D. CURTOTTI, “Il sequestro”, in “Cyber forensics e indagini digitali Manuale tecnico-giuridico e casi pratici”, cit., p. 475, dove si legge: «Si dica subito che le modalità di custodia delle cose sequestrate indicate dall’art. 260 costituiscono, per la giurisprudenza, prescrizioni meramente indicative che, da un lato, sono derogabili per ragioni di assoluta impossibilità o di opportunità, e, dall’altro lato, non sono astrattamente contestabili, tranne che nel caso in cui dalla loro mancata applicazione vogliano dedursi inconvenienti sostanziali attinenti a concrete ipotesi di alterazione, modificazione o sostituzione dei reperti. Ne consegue che l’inosservanza delle norme non è sanzionata da alcuna ipotesi di nullità ma può incidere unicamente sul diverso profilo della valutazione della genuinità della prova, secondo le regole generali dettate dall’art. 192 c.p.p.».

[6] Si veda L. BARTOLI e C. MAIOLI, “La catena di custodia del dato digitale: tra anelli solidi e anelli mancanti”, in Informatica e diritto, XLI annata, Vol. XXIV, 2015, n. 1-2, p. 141, dove trattando dell’importanza della trasparenza nella digital forensics e nella catena di custodia si precisa che «Un’avvertenza preliminare sembra però opportuna: né le migliori tecniche né le più inespugnabili costruzioni normative possono eliminare in radice il pericolo di errori, perdite o incertezze. Alle norme spetterà il compito di salvaguardare, allora, non tanto la certezza dell’autenticità, quanto la trasparenza del percorso, l’occasione di conoscerne i passaggi. Per il giudice e le parti sarà così possibile smascherare i più malsicuri, considerarne il margine di rischio o ripercorrerli – a volte persino replicarli – così da corroborare o smentire la tenuta metodologica delle procedure adoperate». In proposito di tale affermazione, a loro volta gli autori operano un richiamo a E. CASEY, “Digital Evidence and Computer Crime”, III ed.,Waltham,Academic Press, 2011, p. 68 e ss.; ID., “Error, Uncerainty and Loss in Digital Evidence”, in International Journal of Digital Evidence, Vol. 1, 2002, p. 3, www.utica.edu.

[7] Per un esempio grafico di documento di catena di custodia si veda R. MURENEC, op. cit., p. 129.

[8] Ibidem, dove in nota (269), facendo riferimento al modello di chain of custody dell’esperienza nordamericana, viene precisato che «questo documento [la catena di custodia] deve sempre accompagnare, quasi fosse una “carta d’identità”, gli elementi di prova, descrivendone in maniera precisa la res acquisita e indicando inequivocabilmente il nominativo degli individui che con essa entrano in contatto ed il momento e il luogo in cui ciò avviene».

[9] Si veda D. CURTOTTI, ultima opera citata, p. 476, dove viene riportato un orientamento giurisprudenziale minoritario per il quale, usando le parole dell’autrice, «risultano inutilizzabili le indagini condotte su un computer regolarmente sequestrato ma custodito in uno scatolone aperto, privo dell’apposizione di sigilli contrariamente a quanto dispone l’art. 260 c.p.p.», la pronuncia n questione è Cass. Pen., Sez. III del 19 gennaio 2010.

[10] Per un approfondimento sulla gabbia di Faraday e il suo impiego nell’informatica forense si veda il sito https://www.bit4law.com/blog/informatica-forense-incident-response/gabbia-di-faraday-informatica-forense/. Per esempi relativi a dispositivi utilizzabili per l’isolamento dei supporti informatici si veda https://www.dmi.unict.it/~battiato/CF1213/Lezione02%20-%20ISO%20e%20misurazione%20alterazioni.pdf dove vengono riportare in immagine alcune delle soluzioni adottabili.

[11] Occorre precisare che l’uso di strumenti come il jammer, proprio poiché volti ad azioni di disturbo delle frequenze radio e quindi ad impedire comunicazioni, è sottoposto a stringenti vincoli legislativi, si veda in proposito il dettato dell’art. 617 bis c.p. rubricato «Installazione di apparecchiature atte ad intercettare od impedire comunicazioni o conversazioni telegrafiche o telefoniche».

[12] Come è risaputo nel campo della sicurezza informatica non esiste il c.d. “rischio 0”, sussistendo sempre, nonostante le migliori cautele, una percentuale per quanto bassa di rischio.

[13] Per un approfondimento in tale senso si veda P. DAL CHECCO, “Hacking-Boat 2019 – Digital Forensics”, consultabile sul sito https://hackinboat.it/wp-content/uploads/2019/05/HackInBoat-Digital-Forensics-Paolo-Dal-Checco.pdf.

Articolo a cura di Francesco Lazzini

Profilo Autore

Laureato in giurisprudenza con successivo conseguimento dei master in Scienze Forensi (Criminologia-Investigazione-Security-Intelligence) e in Informatica giuridica, nuove tecnologie e diritto dell’informatica. Attività di studio postuniversitario focalizzata in materia di indagini con l’utilizzo del captatore informatico e digital forensics.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/la-catena-di-custodia-della-digital-evidence/




La sicurezza end-to-end nelle reti 5G

I progressi tecnologici nella connettività creano ampie opportunità per la digitalizzazione di tutti i settori dell’economia, dell’industria, delle istituzioni governative, dei servizi pubblici e della vita quotidiana. Le infrastrutture e i servizi di comunicazione, come il 5G, promuovono una società sempre più interconnessa in cui i dati, le informazioni e i servizi migliorano notevolmente le nostre vite, risultando sempre più pervasivi e, come tali, acquisendo rilevanza e valore, dovendo essere disponibili con livelli di servizio, sicurezza e disponibilità adeguati.

L’avanzamento tecnologico ha trasformato radicalmente la nostra vita quotidiana, influenzando settori come il commercio, le transazioni finanziarie e, come evidenziato dal COVID-19, la gestione delle emergenze sanitarie.

Nel contesto della pandemia, la tecnologia ha svolto un ruolo cruciale nel limitare la diffusione del virus e mitigare l’impatto sulle nostre vite. L’utilizzo di strumenti tecnologici per il tracciamento dei contatti, la comunicazione online, il lavoro a distanza e la fornitura di servizi digitali hanno contribuito a mantenere un certo grado di normalità e connettività sociale durante i periodi di lockdown.

Tuttavia, è importante riconoscere che, nonostante i numerosi vantaggi, la dipendenza eccessiva dalla tecnologia può anche presentare sfide, come problemi di sicurezza informatica, privacy e la creazione di divari digitali tra coloro che hanno accesso alle risorse tecnologiche e coloro che non ne hanno. Pertanto, è cruciale bilanciare l’adozione della tecnologia con una riflessione critica sui suoi impatti sociali e individuali. Riusciamo inoltre ad immaginare quale può essere l’imminente futuro per le nostre abitudini, il sistema di pagamenti, le fabbriche, il gaming, la salute e l’industria, l’impatto sull’ambiente, i trasporti, la cultura e la riduzione del digital divide?

Il mondo si dirige verso una connettività senza limiti che ridefinisce il business e promuove un futuro sostenibile. Ma occorre garantire sicurezza e privacy.

Anche se gli standard 5G, come il 3GPP, definiscono caratteristiche di sicurezza maggiori rispetto alle generazioni precedenti, bisogna considerare che il contesto delle standardizzazioni è confinato a specifiche architetturali e di progettazione; fondamentali e determinanti, ma relativo a contesti non reali di produzione ed esercizio. Invece l’installazione e l’operatività dei sistemi avviene in un contesto live, complesso, con minacce in rapida evoluzione e soggetti malevoli sempre più motivati, attrezzati dal punto di vista tecnologico, spesso organizzati in team, globali o locali, con approcci eterogenei. Di conseguenza risulta fondamentale garantire una connettività end-to-end sicura e che tuteli la privacy per gli utenti finali attraverso un approccio sicuro by-design, rendendo la connettività e i servii fruibili all’utente finale, assicurando i livelli di integrità, confidenzialità e disponibilità richiesti e necessari.

Per garantire queste condizioni, è necessario che tutti gli attori della filiera mettano in atto pratiche di gestione dei rischi di sicurezza come parte integrante

  • della ricerca e l’innovazione delle tecnologie e dei prodotti;
  • della cultura del personale e delle organizzazioni;
  • degli standard e le linee guida internazionali;
  • del ciclo di vita dello sviluppo dei prodotti, inclusa la sicurezza della supply-chain;
  • dell’installazione e gestione di tutti i prodotti delle reti mobili che forniscono il servizio end-to-end, ovvero dalla rete di accesso (RAN), al trasporto, alla CORE fino ai sistemi BSS e OSS delle corrette configurazioni dei sistemi;
  • dell’esercizio dei sistemi;
  • degli aggiornamenti necessari e tempestivi del software;
  • dell’aggiornamento delle competenze degli addetti ai lavori.

L’obiettivo deve essere, per tutte le entità e organizzazioni coinvolte, quello di proteggere le reti di comunicazione e le risorse di rete salvaguardando il servizio per gli utenti finali a partire dai servizi e passando dai sistemi gestionali di rete OSS/BSS a quelli di CORE, da quelli di trasporto e di accesso, fino ad arrivare al terminale d’uso usato dall’utente.

Come sta evolvendo il settore delle telecomunicazioni: le istituzioni

Un approccio olistico e strategico è la prerogativa necessaria per definire un sistema regolatorio e un insieme di politiche, oltre che un requisito fondamentale per mitigare i rischi. Il 5G, e successivamente il 6G, abiliteranno connettività illimitata attraverso tecnologie avanzate su una piattaforma innovativa che necessiterà di adeguati livelli di security e privacy, il tutto per svariati casi d’uso.

Tuttavia, le reti aumenteranno progressivamente ma in maniera decisa la loro complessità: l’insieme degli elementi di una rete, dai dispositivi di accesso alla RAN, alla Core, al Cloud, all’Edge al OSS/BSS costituiranno un ecosistema complesso ed eterogeneo composto di molteplici elementi, di notevole valore e criticità, negli asset, nei contenuti e nei servizi. Per queste ragioni le istituzioni e i policy maker hanno mostrato da tempo una maggiore consapevolezza dei rischi annessi in relazione a:

  • la sovranità degli Stati, intesa come effettiva e concreta autonomia da parte degli stessi su un numero anche ampio di competenze e funzioni. Questa prerogativa deriva dal fatto che reti e servizi di telecomunicazioni sono utilizzate e condivise, con adeguati controlli di sicurezza, sia per ambiti civili che mission and business critical, rappresentando di fatto dorsali strategiche;
  • la governance dei principi etici e legali. Ogni nuovo scenario tecnologico introduce nuovi rischi, i quali richiedono una gestione specifica, senza la quale la tecnologia può rappresentare un veicolo di potenziali minacce;
  • gli impatti politici e sociali, come avvenuto per controversie di voto, per proteste o movimenti sulle piattaforme di social networking.

Dal 2019 è risultata determinante la direzione guida, l’approccio strutturato, coordinato e comprensivo dell’Unione Europea attraverso misure tecniche e strategiche indirizzate attraverso il framework dell’EU 5G Toolbox [1] e il lavoro in itinere di ENISA. Coerentemente, l’Italia ha recepito le indicazioni dell’Unione Europea attraverso un quadro normativo che ha portato alla creazione dell’Agenzia per la Cybersecurity Nazionale (ACN) e, come conseguenza pratica, ad una forte collaborazione tra tutti gli attori (l’Operatore, il Vendor, numerosi gruppi di lavoro presso enti di standardizzazione e/o di diretta pertinenza, system integrator, associazioni di settore, le stesse agenzie di sicurezza) finalizzata a ridurre l’impatto sui rischi per i sistemi e i servizi di comunicazione.

L’esperienza dell’utente finale nelle reti 5G è definita dalla postura di sicurezza e privacy, dalle performance e dalla qualità della copertura del segnale delle reti in esercizio, non solamente quelle, statiche se vogliamo, definite in fase di standard, progettazione e rilascio. Come descritto in [2] dall’OCSE, per gestire la crescente complessità delle reti è necessario adottare un approccio olistico e strategico che accresca la sicurezza digitale delle infrastrutture di comunicazione, considerando l’intero esercizio del ciclo di vita delle stesse, dallo sviluppo degli standard all’installazione e operatività degli apparati di comunicazione nelle reti dell’operatore. Questo approccio dovrebbe:

  1. considerare l’intero ciclo di vita di tutti i prodotti e servizi su cui gli Operatori fanno affidamento per erogare servizi di connettività;
  2. raccogliere il contributo e interesse di tutti gli attori coinvolti nell’end-to-end;
  3. essere coordinato a livello nazionale e internazionale.

Il fine è di implementare una visione comprensiva e olistica che traguardi la sicurezza delle reti, la contestualizzazione di servizi di connettività, tutti alla base del corretto funzionamento del Sistema Paese. E’ necessario prendere in considerazione la robustezza della sicurezza delle reti installate e le mitigazioni dei rischi per tutte le fasi del ciclo di vita, o layers: gli standard, i prodotti e i relativi processi di sviluppo, il deployment delle reti e il loro esercizio. Complessivamente, sono questi layers a definire nel loro insieme lo stato delle reti e quindi l’esperienza finale dell’utente.

Un esempio pratico è quello delle vulnerabilità del software, alle quali si è soliti pensare come a un concetto legato temporalmente alle fasi di sviluppo.

Tuttavia, è noto che le vulnerabilità possono manifestarsi e rilevarsi in ogni fase del ciclo di vita del software, incluso la fase di esercizio e produzione del software, quando lo stesso, rilasciato dal Vendor, è integrato nel contesto Operatore, in una rete distribuita ed eterogenea, per sua natura complessa, ed è parte dell’erogazione di un servizio che deve assicurare determinati livelli di continuità, sicurezza e privacy, integrità e robustezza. In questa specifica fase, ovvero in una rete che sta erogando un servizio, l’impatto di una vulnerabilità critica può essere rilevante poichè devono essere presi in considerazione, per la sua risoluzione o contenimento, numerosi riverberi legati a interdipendenze e vincoli di altri sistemi interconnessi, sia operativi che tecnici e progettuali, ma soprattutto processi e soggetti che possono condizionare il corretto funzionamento complessivo del servizio.

Appare anche evidente come, dal punto di vista operativo e di esercizio, sia opportuno considerare l’intero perimetro dei prodotti e dei servizi, ovvero la RAN, il trasporto, la Core e le reti di interconnessione, i sistemi OSS e BSS, i nodi di positioning etc e non solamente una parte delle reti, anche se ritenuta più critica delle altre. Una vulnerabilità, o una debolezza in un processo, all’interno dell’ecosistema di esercizio di un Operatore rappresenta comunque una opportunità per soggetti malevoli, nonostante la criticità dell’asset di riferimento possa, correttamente, imporre dei criteri di prioritizzazione per la sua risoluzione.

Per le motivazioni esposte pertanto, la complessità effettiva e l’accountability di una rete che eroghi servizi di comunicazione 5G non possono essere appannaggio di un unico soggetto, sia esso l’Operatore o il Vendor di prodotto. Ciascuno per le proprie competenze e responsabilità deve concorrere e collaborare al raggiungimento e mantenimento dell’obiettivo fondamentale, quello della sicurezza e privacy della rete.

Come sta evolvendo il settore delle telecomunicazioni: Vendor e Operatori

Il 5G viene considerato uno standard di comunicazione mobile più sicuro delle generazioni precedenti poiché implementa non solo tutte le funzionalità già incluse nella 4G ma, ad esempio, impiega protocolli di sicurezza aggiornati, permette il network slicing come forma flessibile di network segregation, ovvero specifiche caratteristiche di privacy e security. I Vendor devono garantire l’implementazione degli standard attraverso processi e framework consolidati di sicurezza e soddisfare le aspettative dell’Operatore per quanto riguarda la gestione delle attività di Operation per la sicurezza, adottare programmi di gestione delle vulnerabilità robusti e fornire la giusta visibilità dei prodotti quando inseriti in un contesto di rete. E’ sicuramente fondamentale integrare la sicurezza e privacy all’interno dei prodotti e delle soluzioni sin dalla fase di progettazione per essere in grado di cogliere le opportunità di anticipare il più possibile le eventuali problematiche progettuali e ridurre significativamente i rischi di mancata o errata realizzazione. Il mercato ha recepito queste indicazioni ed è ormai una abitudine riferirsi a Data Protection and Security by design come il modello per lo sviluppo sicuro che affronta le tematiche di sicurezza e privacy in tutte le fasi rilevanti della catena del valore.

Questo approccio aiuta a soddisfare le aspettative degli stakeholder e a far fronte alla rapida evoluzione della tecnologia e ai continui cambiamenti nella legislazione a livello globale e locale, fino al livello di singola opportunità.

Per contro, gli standard e i framework di sviluppo, da soli, seppur implementati alla lettera non bastano ad assicurare reti sicure in esercizio: le fasi di progettazione di una soluzione, di integrazione in rete, di deployment e di operations definiscono un nuovo perimetro e contesto di sicurezza per i prodotti.

E’ quindi necessario per l’Operatore, con il supporto del Vendor, riconsiderare il mutato scenario di deployment e analizzare le minacce e il threat modeling del nuovo contesto.

Da questo punto di vista, è importante osservare come vendor come Ericsson stiano operando nel sostenere il paradigma Zero Trust, ovvero, in estrema sintesi, nessun asset ha un diritto implicito di accesso alle risorse ed è necessario andare oltre le difese perimetrali ordinarie. In particolare negli Stati Uniti dove, sotto la spinta anche degli Enti governativi, si sta assistendo alla definizione di programmi di attuazione per l’implementazione di architetture Zero Trust [ 3 ] in numerose entità, pubbliche e private. L’obiettivo traguarda, anche in questo caso, il servizio end-to-end risultante, quello fornito dall’Operatore, e mira a definire e attuare delle misure che riducano il rischio di esposizione; da notare come comunque non sia possibile sostituire la componente di Security Operations, intesa come monitoraggio, supervisione e verifica delle reti, che continua a costituire un ruolo fondamentale per assicurare il mantenimento delle corrette configurazioni e attese funzionalità.

Anzi, questa componente di servizio va decisamente, anche per le reti 5G, verso modelli di maturità che prevedono l’automazione, così come avvenuto anni fa nel contesto dell’IT, dove le soluzioni di security automation hanno rappresentato l’evoluzione delle piattaforme e processi SIEM e SOC.

Dal punto di vista operativo, emerge quanto mai la necessità per il Vendor e l’Operatore di collaborare attivamente per la messa a punto di processi efficaci per la gestione degli incidenti di sicurezza; appare inoltre rilevante la capacità di condividere e analizzare le indicazioni di Threat Intelligence specifici per le reti Telco, molto spesso globali ma con possibile effetto locale. Inoltre, la gestione delle vulnerabilità deve essere una gestione World class e rivelarsi efficace, di alto livello, trasparente e adeguata ai contesti. Concretamente, processi e soluzioni per la Security Automation e Threat Intelligence devono integrarsi e cooperare con i Security Incident Response Team, ovvero i CSIRT degli Operatori o delle Autorità o i PSIRT (Product Security Incident Response Team) del Vendor.

Dal punto di vista organizzativo, è possibile osservare come le grandi aziende, come Ericsson, abbiano da tempo dato esecuzione a programmi di awareness e skill improvement per il proprio personale, specificatamente per security e privacy, oltre che a programmi formativi per il personale IT all’educazione informatica, si vedano le diverse iniziative e soluzioni per mitigare il rischio di fenomeni di phishing.

Considerazioni finali

L’approccio basato sulle più attuali pratiche di sicurezza deve sicuramente includere il rispetto del security-by-design, meccanismi di automatizzazione che riguardino lo Zero Trust, gli investimenti nello sviluppo delle competenze, la collaborazione attiva e la condivisione delle informazioni tra Operatori, Vendor e Autorità deputate ma anche l’uso strategico dell’automazione a supporto delle attività di Operations. Non ultimo, diventa fondamentale il percorso di cooperazione tra le Agenzie di Sicurezza nazionali, nel condividere un comune standard di riferimento e nel definire condizioni di mutuo riconoscimento operativo, al fine di avviare approcci frammentati in cui possano insinuarsi vulnerabilità di sistema.

Riferimenti

[1] Eu 5G Toolbox – Cybersecurity of 5G networks – EU Toolbox of risk mitigating measures | Shaping Europe’s digital future (europa.eu)

[2] OECD (2023), “Enhancing the security of communication infrastructure”;, OECD Digital Economy Papers, No. 358, OECD Publishing, Paris, https://doi.org/10.1787/bb608fe5-en.

[3] NIST SPECIAL PUBLICATION 1800-35A Implementing a Zero Trust Architecture, Volume A: Executive Summary (nist.gov)

Articolo a cura di Luciano Cioccolanti e Antonio Sfameli

Profilo Autore

Customer Security Director Ericsson South Europe Mediterranean and Eurasia

Laurea in Ingegneria Informatica conseguita a Roma nel 1996, ha maturato una esperienza professionale in contesti tecnologici, culturali e di business eterogenei in campo italiano ed internazionale, avendo avuto l’opportunità di lavorare per Clienti come le Telco italiane ed estere, Commissione Europea di Lussemburgo e primarie società di consulenza. La formazione accademica si è arricchita sui domini Telco, IT, Lawful Interception, Data Protection, Banking e Financial Services, attraverso la partecipazione a eventi di settore e conseguimento di certificazioni professionali (PMP, CISSP, CRISC, CISM, CISA, LA27001, ITIL e CCSK). In Ericsson da Novembre 2021, ricopre il ruolo di Customer Security Director per l’area South East Mediterranean & Eurasia.

Profilo Autore

Government and Policy Advocacy Ericsson South Europe Mediterranean and Eurasia.

Nell’organizzazione corporate EMEA Government and Policy Advocacy è responsabile delle Relazioni Istituzionali di Ericsson.
E’ direttore dei Rapporti Associativi. E’ Componente del Comitato per l’attrazione degli investimenti esteri di Confindustria (ABIE). E’ Vicepresidente della Sezione Comunicazioni in Unindustria. E’ Componente del Gruppo Istituzionale e Comunicazione di Assotelecomunicazioni-Asstel. E’ Componente del Gruppo Istituzionale in ASSONIME.
Collabora con diverse Università e Centri di Competenza Nazionale.
E’ direttore degli Affari Regolatori di Ericsson e dei rapporti con le Autorità di regolazione di settore.
E’ Componente del Country Management Team di Ericsson.
E’ Segretario Generale della Fondazione Lars Magnus Ericsson.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/la-sicurezza-end-to-end-nelle-reti-5g/