Casi come Cellebrite Ufed v. Signal pongono in luce come la cybersecurity sia un fattore essenziale per la corretta riuscita di un’indagine di digital forensics. In particolare, emerge come uno scarso livello di sicurezza del software utilizzato per l’analisi della copia forense rischi in concreto di tradursi in un’indagine fuorviante, dalla quale non potranno che conseguire risultati inattendibili.

È opportuno, tuttavia, osservare come nell’assetto giuridico che disciplina la materia manchi del tutto una normativa tecnica che imponga livelli minimi di sicurezza nelle strumentazioni utilizzate. Sul punto, il rinvio del legislatore alle best practices – tra le quali ve ne sono di specifiche che si occupano di sicurezza – è l’unico appoggio normativo che possa rinvenirsi riguardo al dovere di rispettare criteri minimi di cybersecurity. Però, dal momento che la giurisprudenza ha stabilito come il mancato rispetto delle buone pratiche internazionali non comporti automaticamente l’inutilizzabilità delle evidenze digitali, sorge spontaneo chiedersi se la soluzione adottata sul piano legislativo si possa valutare sufficiente oppure se sia il caso di introdurre accorgimenti giuridici ulteriori.

In realtà, se si prende in considerazione la rapidità con cui evolvono le minacce informatiche e se si considera l’entità del danno che un’indagine potrebbe subire in caso di mancanza d’uso di strumenti sicuri, appare palese come l’attuale impostazione della disciplina contenga un vuoto normativo che, in un contesto di crescente ricorso alle tecniche di digital forensics, corre il rischio di aumentare sempre più la percentuale di errori giudiziari.

La questione assume un tono di maggiore inquietudine se si considera che strumenti con acclarate vulnerabilità, come ad esempio la precedente versione del software Phisycal Anayzer di Cellebrite Ufed, sono stati largamente usati dalle procure e dalle forze dell’ordine del nostro Paese e potenzialmente potrebbero tuttora essere in utilizzo presso i medesimi organi.

Il problema si pone dal momento che, non disponendo la Pubblica Amministrazione di strumenti e software di digital forensics prodotti direttamente dallo Stato, procure e forze dell’ordine per munirsi di simili sistemi sono costrette a rivolgersi ad aziende private, quasi sempre straniere. Tale circostanza, in assenza di una normativa specifica che disponga standard minimi di sicurezza, comporta che l’acquirente – in questo caso, gli organi statali – debbano necessariamente rifarsi ai livelli di sicurezza che propone l’azienda venditrice, la quale agendo secondo logiche privatistiche potrebbe talvolta ritenere non necessario incrementare le difese dei propri sistemi. Si rammenti, a titolo esemplificativo, che il precedente di Phisycal Analyzer veniva ad esistenza proprio a causa del mancato ammodernamento del software, che circolava con un aggiornamento obsoleto poiché non implementato da anni dalla casa produttrice.

Alla luce di quanto esposto, si presenta sempre più necessario il perfezionamento di un intervento normativo diretto a colmare il vuoto legislativo in tema di sicurezza e volto all’eliminazione delle attuali incertezze.

L’intervento, nello specifico, dovrebbe muoversi su due piani distinti ma connessi tra loro. Innanzitutto, andrebbero stabiliti dei livelli minimi di sicurezza che gli applicativi usati per le operazioni di digital forensics dovrebbero rispettare per poter essere adoperati ai fini d’indagine. In secondo luogo, occorrerebbe fare in modo che lo Stato sia messo concretamente nella posizione di valutare attivamente lo standard di sicurezza minima essenziale di tali applicativi.

Per fare ciò, bisognerebbe mettere a punto un sistema di controllo diretto dello Stato sulle aziende fornitrici: ipotesi allo stato attuale molto difficile, sia perché le maggiori aziende tech sono straniere e sia perché le medesime, in ottica di mercato, tendono a proteggere il segreto delle loro invenzioni, anche nei confronti degli Stati a cui offrono il servizio.

Oltre alla possibilità di creare dei software di completa proprietà dello Stato – in linea teorica la scelta migliore, ma in termini pratici di complessa realizzazione nonché estremamente dispendiosa^[1] – un’altra soluzione potrebbe essere incentivare la nascita di un gruppo di aziende conformi a specifici criteri, organizzate in consorzio e sottoposte alla diretta vigilanza dello Stato, che ne costituirebbe il primo fruitore dei servizi^[2]. Una simile soluzione, se opportunamente regolata, permetterebbe allo Stato di imporre a tali aziende il rispetto di livelli di sicurezza minimi per i loro prodotti e la necessità di sottoporsi a controlli specifici che garantirebbero l’efficienza dei servizi e la più completa trasparenza al riguardo. Di ritorno, tali aziende avrebbero la certezza di un cliente sicuro quale la Pubblica Amministrazione.

È chiaro che una soluzione del genere andrebbe disciplinata a regola d’arte al fine di evitare situazioni di abuso e in ogni caso non sarebbe realizzabile nel breve termine.

Non vi è dubbio, tuttavia, che la questione della sicurezza informatica nella digital forensics debba essere quanto prima attenzionata a livello normativo; così da impedire da un lato che sia compromessa la genuinità delle indagini di informatica forense e dall’altro tutelando la posizione processuale dell’indagato.

CONCLUSIONI

La rivoluzione digitale che caratterizza l’attuale fase storica ha notevolmente impattato, tra gli altri, anche i settori del diritto processuale e delle scienze forensi. Qui, le nuove tecnologie stanno trovando larghissimo impiego soprattutto per quanto concerne l’ambito investigativo e il ricorso alle tecniche di digital forensics si rivela, sempre più di frequente, un elemento imprescindibile per gli inquirenti. L’analisi dei dispositivi elettronici rinvenuti sulla scena del crimine o in uso dall’indagato permette infatti di reperire informazioni, trovare indizi, collezionare elementi di prova e raggiungere risultati che le indagini tradizionali, in un mondo sempre più informatizzato, difficilmente riuscirebbero a ottenere.

Per contro, a causa della delicatezza che caratterizza questo tipo di operazioni, le potenzialità investigative della digital forensics si scontrano inevitabilmente con una serie di criticità.

Ove non adeguatamente tenuta in conto durante le fasi di acquisizione, analisi e catena di custodia, la fragilità della digital evidence rischia di compromettere da un lato il buon esito delle indagini e, dall’altro, le garanzie difensive del soggetto indagato, che nella normalità della casistica riveste, durante l’espletamento delle attività forensi, un ruolo meramente passivo.

Inoltre, proprio la natura digitale di questo tipo di indagine non lascia immune la digital forensics dai pericoli che riguardano il settore informatico in generale, imponendo la necessità di adottare opportuni accorgimenti anche per quanto concerne la sicurezza. Come dimostrato dai recenti casi di cronaca, infatti, il concetto di cybersecurity nella digital forensics non può assolutamente essere sottovalutato al fine di garantire la completa attendibilità dell’indagine.

Per quanto riguarda la disciplina normativa si è visto come in Italia, anziché regolare dettagliatamente la materia, sia stata scelta una strategia di rinvio alle c.d. best practices internazionali, inserendo all’interno del codice di procedura penale esclusivamente l’obbligo, nel maneggiare le evidenze digitali, di fare ricorso a tecniche atte a preservare l’integrità e l’immodificabilità dei dati.

Questo atteggiamento legislativo, seppur giustificabile alla luce della continua evoluzione tecnologica, ha lasciato ampio spazio di manovra alla giurisprudenza; la quale, avendo chiarito la non obbligatorietà per gli inquirenti di rispettare le best practices, parrebbe aver addirittura ridimensionato il proposito della legge n. 48/2008.

Il nostro modello giuridico propone, attualmente, un contemperamento tra garanzie del diritto di difesa ed esigenze investigative nettamente sbilanciato in favore di queste ultime, ponendo l’indagato in una posizione oltremodo subalterna e relegandone le tutele costituzionali in secondo piano. Per tutelarne quanto più possibile la posizione processuale potrebbe essere utile, allora, trovare nuove strategie per anticipare il contraddittorio: ad esempio con la possibilità di nominare un consulente per la difesa che intervenga ancor prima della discovery delle prove. Si rammenta in proposito che la giurisprudenza ha ricompreso le operazioni di digital forensics tra gli atti ripetibili, eseguibili pertanto senza la necessità di integrare il contraddittorio con l’indagato: evenienza che tuttavia, unita alla possibilità di discostarsi dalle best practices, rischia di assumere i contorni propri del processo inquisitorio. Secondo l’attuale impostazione, infatti, l’onere probatorio (inquadrabile come probatio diabolica) di indicare come il discostamento dagli standard internazionali abbia compromesso le evidenze digitali ricade in capo all’indagato, anche laddove non abbia potuto partecipare alle operazioni.

La mancata previsione di una disciplina specifica in tema di cybersecurity può, inoltre, riverberarsi negativamente sull’attendibilità delle risultanze che vengano analizzate con strumenti di digital forensics non sostenuti da idonei sistemi di sicurezza. Andrebbero altresì previsti opportuni controlli sulle aziende fornitrici di questi servizi, per poter valutare l’efficienza dei prodotti in uso presso le Pubbliche Amministrazioni.

Alla luce di tali considerazioni appare ormai necessaria la creazione di un assetto normativo più dettagliato, che sappia calibrare correttamente il peso delle criticità che permeano una materia delicata come l’informatica forense per individuare il corretto bilanciamento tra esigenze investigative, cybersecurity e diritto di difesa.

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] Si consideri che il mondo della sicurezza è in continua evoluzione e, in ottica di spese, per lo Stato sviluppare software proprietari significherebbe investire in maniera continuativa somme di denaro molto ingenti obbligandolo ad uno sforzo economico di elevate proporzioni.

^[2] Una soluzione simile è stata proposta anche per quanto riguarda la materia del captatore informatico, strumento che per molti aspetti, se non in maniera addirittura più rilevante, patisce dal punto di vista della cybersecurity delle medesime problematicità a cui soggiacciono gli strumenti informatici per la digital forensics. Si veda sul punto il servizio giornalistico intitolato “Infiltrato speciale”, curato da P. MONDANI nella trasmissione “Report”, puntata del 18/11/2019.

Articolo a cura di Francesco Lazzini

https://www.ictsecuritymagazine.com/articoli/la-necessita-di-software-di-digital-forensics-direttamente-gestiti-e-controllati-dallo-stato/

Dal punto di vista tecnico-operativo, le indagini di digital forensics vengono svolte utilizzando specifici strumenti hardware e software^[1] che, una volta collegati al sistema informatico da acquisire, ne esplorano le aree di memoria e ne producono una copia^[2] – nella quale vengono ricompresi lo spazio non allocato e le parti di file cancellati ma non definitivamente eliminati – che successivamente viene esfiltrata verso un file di backup appositamente creato sul dispositivo hardware usato per l’acquisizione e dove viene, quindi, dislocata la copia forense del sistema sotto indagine. Concluse le operazioni di acquisizione, il clone informatico viene poi analizzato mediante programmi di analisi che permettono di prendere visione del contenuto digitale in esame. In particolare, questi software hanno il compito di scandagliare a fondo tutti i singoli file che sono presenti nella copia forense, visionandone tutte le parti, metadati inclusi, verificando che non vi siano contenuti occultati e nel caso procedendo ad analisi dei medesimi^[3].

È ovvio che più il programma di analisi è moderno e aggiornato più sarà in grado di scovare file nascosti e di conseguenza maggiore sarà la resa in termini di risultato finale.

Qualora, invece, i file siano protetti da password, occorrerà procedere allo sblocco del loro contenuto mediante attacchi brute force volti all’individuazione della chiave che custodisce i dati^[4].

In estrema sintesi e senza tecnicismi, l’attività di individuazione della digital evidence è suddivisibile in due fasi: la prima è quella di acquisizione in copia forense della memoria del dispositivo, mentre la seconda prevede l’analisi della copia estratta, fase nella quale, più precisamente, vengono rintracciate e identificate le evidenze digitali stoccate in memoria che si sospettavano poter essere presenti sul dispositivo al momento del sequestro.

Per entrambe le fasi, in situazioni particolari, possono profilarsi problemi di sicurezza informatica. Durante tali momenti, ad esempio, delle criticità potrebbero insorgere qualora il dispositivo da acquisire e analizzare sia infetto da un virus informatico. Clonando la memoria inevitabilmente verrebbe clonato anche il programma malevolo, che per conseguenza si estenderebbe alla copia forense.

Ora, se l’infezione sul dispositivo originario fosse nota, il problema in realtà non si porrebbe. In tal caso, infatti, l’ostacolo potrebbe essere facilmente aggirato acquisendo più copie del dispositivo e quindi procedendo alla disinfezione del virus da una di esse, per poi confrontarla con le altre per valutare se l’operazione di eliminazione del malware abbia comportato la compromissione di dati oppure abbia mantenuto inalterate le informazioni^[5].

Il problema emerge quando il virus informatico passa inosservato all’occhio dei software adoperati per le operazioni forensi. Si consideri sul punto che, al pari degli altri programmi informatici, anche gli strumenti adoperati per la digital forensics possono avere delle vulnerabilità nella sicurezza, soprattutto quando il sistema non viene regolarmente aggiornato. In linea teorica, pertanto, potrebbe capitare che un malware sfugga al controllo e continui a svolgere indisturbato il compito per il quale è stato progettato.

In particolare, esistono alcuni tipi di malware che una volta sottoposti all’azione dei programmi di analisi sono in grado di corromperne l’algoritmo e alterarne il funzionamento per far commettere al software operazioni per le quali originariamente non era settato o che non era stato autorizzato a svolgere. È superfluo specificare che in simili evenienze l’attendibilità delle risultanze ottenute con l’analisi forense sarebbe del tutto assente.

Ad ogni modo, vulnerabilità di questo tipo non colpirebbero la genuinità del procedimento di formazione della copia forense, ma esclusivamente il successivo passaggio di analisi, compromettendo quindi non l’acquisizione in sé (consistente in una mera copiatura dei byte della memoria originale senza attività di elaborazione) ma solo i sistemi di analisi e in conseguenza l’analisi che ne scaturisce^[6].

Un recente caso di cronaca, andato alla ribalta delle testate giornalistiche che si occupano di cybersicurezza, ha messo in chiaro come quanto appena descritto non sia solo un’ipotesi di scuola, bensì potrebbe realmente accadere, o meglio, sarebbe già accaduto. Il caso riguarda lo scambio di battute avutosi tra fine 2020 e prima metà del 2021 tra la nota app di messaggistica Signal e l’azienda israeliana produttrice di strumenti di informatica forense – tra le più affermate sul mercato – Cellebrite Ufed.

La disputa aveva origine allorché l’azienda israeliana comunicava pubblicamente di aver trovato il modo per violare le difese dell’applicazione di messaggistica – come noto tra le più sicure e tra le più improntate alla garanzia della privacy degli utenti – affermando di esserne persino riuscita decifrare i contenuti delle chat e i relativi allegati. Successivamente, sebbene l’azienda, sul presupposto delle polemiche che stavano emergendo, avesse tentato di ridimensionare la portata sensazionalistica della comunicazione originale, si scatenava ugualmente la reazione di Signal.

Per tutta risposta infatti quest’ultima, a mezzo di un articolo pubblicato pochi mesi dopo dal proprio amministratore delegato^[7], nello sminuire ulteriormente la notizia dell’hackeraggio^[8] controbatteva insinuando di essere stata a sua volta in grado di individuare alcune vulnerabilità presenti sul software di analisi Physical Analyzer, sviluppato e distribuito sul mercato dalla società israeliana.

In pratica, secondo l’amministratore delegato di Signal, il software della Cellebrite dopo il lancio nel 2012 non sarebbe più stato implementato con i necessari aggiornamenti, sicché avrebbe presentato diverse falle nel proprio sistema di sicurezza. Sfruttando queste mancanze sarebbe stato possibile eseguire sul software dei codici capaci di modificare sia i report di Cellebrite relativi all’attacco sia quelli precedenti e futuri, creati a partire da dispositivi acquisiti in precedenza. Inoltre, sarebbe stato possibile attuare modifiche rilevanti nel contenuto analizzato: inserire o rimuovere parti testuali, messaggi di posta elettronica, immagini, contatti, file e qualunque tipo di dato, il tutto sfuggendo completamente ai controlli dei checksum. Nei casi peggiori, come riporta sempre Signal, un attacco simile avrebbe addirittura potuto causare la fuoriuscita dei dati presenti sul dispositivo analizzato, il tutto con ovvia ripercussione sull’attendibilità dell’analisi stessa^[9].

Il caso appena esaminato rende evidente le maggiori criticità di cybersecurity che possono inficiare la funzionalità degli strumenti per le analisi forensi. Il rischio è che malware capaci di agire nei termini su visti possano presto divenire una realtà largamente diffusa.

Secondo gli esperti, tuttavia, si potrebbe ricorrere ad alcune contromisure. In particolare, per ovviare alle problematiche di file illeciti di questo genere una soluzione potrebbe essere quella di rivolgere lo sguardo agli strumenti di machine learning; ovvero a algoritmi che facendo ricorso a logiche matematiche e di elaborazioni computazionale sono in grado di apprendere informazioni direttamente dai dati che gli vengono sottoposti, senza che abbiano ricevuto in precedenza delle istruzioni specifiche. Una volta “addestrati” questi algoritmi sono in grado di adattarsi a situazioni nuove e potenzialmente, in chiave predittiva, a riconoscere programmi che si comportano in maniera difforme dalla normalità, potendo quindi teoricamente scoprire file malevoli che si camuffano da altri programmi.

L’applicazione delle logiche del machine learning alla digital forensics^[10], in fase di esame della copia forense, potrebbe quindi aiutare il programma di analisi a individuare possibili programmi malevoli e catalogarli come file sospetti.

Su un piano più tecnico gli algoritmi di machine learning, operando una verifica dei metadati dei programmi presenti sulla copia, sarebbero in grado di comprendere se un file possa essere potenzialmente dannoso mediante un confronto con i metadati di programmi già noti al sistema o dal medesimo già considerati sospetti^[11].

Di certo l’applicazione degli algoritmi di machine learning non può costituire l’unica soluzione. Una buona strategia difensiva non può prescindere, ad esempio, dal costante aggiornamento del sistema e dalla applicazione delle altre comuni buone pratiche e accorgimenti che costituiscono i principi fondanti della sicurezza informatica.

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 un approfondimento delle diverse tipologie di software che vengono utilizzati nelle operazioni di informatica forense e sul funzionamento degli stessi si rimanda a M. VITIELLO, “Il laboratorio di informatica forense: i software, gli strumenti hardware, i costi” consultabile sul sito https://www.agendadigitale.eu/documenti/il-laboratorio-di-informatica-forense-i-software-gli-strumenti-hardware-i-costi/#:~:text=Ad%20esempio%20Magnet%20Axiom%20%C3%A8,maggior%20numero%20di%20evidenze%20possibili.

^[2] Si rammenta che per impedire che i dati da acquisire vengano corrotti dallo strumento di acquisizione medesimo è necessario che questo abbia la funzione di blocco di scrittura (write blocking).

^[3] Per recuperare file cancellati oppure danneggiati vengono impiegati appositi strumenti di file recovery che servono proprio a ripristinare contenuti parziali.

^[4] L’attacco di brute force «consiste nel provare tutte le possibili combinazioni di lettere, caratteri speciali e numeri finché non individua la mescolanza giusta. Un’operazione che viene, ovviamente, eseguita da un software. Il tempo di riuscita dell’impresa dipende dalla velocità di calcolo del computer, nonché dalla complessità e la lunghezza della password (quanti e quali caratteri sono stati utilizzati)». La definizione è tratta da R. RIJITANO, “Brute force: cosa sono, come fare e prevenire gli attacchi a forza bruta”, consultabile sul sito https://www.cybersecurity360.it/nuove-minacce/brute-force-cosa-sono-gli-attacchi-a-forza-bruta-come-farli-e-prevenirli/.

^[5] Ovviamente, in ogni caso, in sede processuale bisognerà capire se e in che modo il programma malevolo possa aver corrotto le informazioni sulla copia originale prima che venisse rilevato.

^[6] Quanto finora riferito e la disamina che segue trae le mosse da P. DAL CHECCO, “Signal ha hackerato Cellebrite, svelate vulnerabilità nelle app di hacking telefonico: i risvolti”, in Cybersecurity360 consultabile sul sito https://www.cybersecurity360.it/nuove-minacce/signal-ha-hackerato-cellebrite-svelate-vulnerabilita-nelle-app-di-hacking-telefonico-i-risvolti/.

^[7] L’articolo è consultabile sul sito Signal >> Blog >> Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer from an app’s perspective.

^[8] Secondo quanto sostenuto da Signal, infatti, in realtà Cellebrite sarebbe riuscita semplicemente a capire dove si trovasse la chiave di cifratura con la quale i messaggi venivano localmente cifrati, cioè sul dispositivo analizzato, e non a forzare il meccanismo di cifratura delle chat dell’applicazione.

^[9] Per un maggiore approfondimento si rimanda nuovamente a P. DAL CHECCO, op. cit., in Cybersecurity360.

^[10] Si rimanda a N. BASSETTI, “Machine learning per l’identificazione dei file sospetti: tecniche e sviluppi”, in Cybersecurity360, consultabile sul sito https://www.cybersecurity360.it/soluzioni-aziendali/machine-learning-per-lidentificazione-dei-file-sospetti-tecniche-e-sviluppi/.

^[11] Ibidem.

Articolo a cura di Francesco Lazzini

https://www.ictsecuritymagazine.com/articoli/digital-forensics-e-cyber-security-caso-cellebrite-ufed-vs-signal/

Nell’ambito dell’email security esistono diversi protocolli volti a garantire l’autenticità, l’integrità e la riservatezza delle comunicazioni, tra i più importanti ci sono:

• SMTP (Simple Mail Transfer Protocol): è il protocollo di base utilizzato per inviare e ricevere email, tuttavia, per impostazione predefinita, SMTP non offre meccanismi di autenticazione e sicurezza. Pertanto, molte implementazioni incorporano estensioni relative a STARTTLS per crittografare le comunicazioni tra i server di posta elettronica.
• SSL/TLS (Secure Sockets Layer/Transport Layer Security): sono protocolli crittografici utilizzati per garantire la riservatezza e l’integrità delle comunicazioni tra client e server. In questo caso il protocollo STARTTLS consentirà di avviare una connessione sicura SSL/TLS durante la trasmissione delle email. Si noti che il protocollo SSL è ormai in disuso in quanto poco sicuro; pertanto, come best practice si consiglia il protocollo TLS alla versione 1.2. La versione del TLS 1.3 sarebbe in realtà quella desiderata, tuttavia, non essendo in grado di “comunicare” con le sue versioni precedenti può creare molti problemi di comunicazione con chi non adotta tale protocollo (purtroppo ancora poco diffuso).
• PGP (Pretty Good Privacy) / GPG (GNU Privacy Guard): sono protocolli di crittografia end-to-end utilizzati per cifrare e decifrare i contenuti delle email. Consentono agli utenti di proteggere il contenuto delle loro comunicazioni durante la trasmissione.
• S/MIME (Secure/Multipurpose Internet Mail Extensions): è un protocollo di crittografia che fornisce sicurezza alle email utilizzando certificati digitali che firmano e cifrano i messaggi. È spesso utilizzato per garantire la riservatezza e l’autenticità delle email.
• DNSSEC (Domain Name System Security Extensions): questo protocollo non è specificamente legato alle email tuttavia la sicurezza del DNS è cruciale per i protocolli di SPF, DKIM e DMARC. DNSSEC previene gli attacchi di spoofing e garantisce l’integrità delle informazioni.

Quando viene inviata un’email, il server del destinatario esegue alcuni controlli per verificare se il messaggio risulta legittimo e inviato da un mittente autorizzato. Questi controlli sono possibili attraverso l’implementazione dei protocolli SPF, DKIM e DMARC:

• SPF (Sender Policy Framework): è un protocollo di autenticazione che verifica se un server di posta elettronica è effettivamente autorizzato a inviare messaggi per un determinato dominio. Come si evince dalla figura 5, Il mittente pubblicherà il record SPF nel DNS, specificando quali sono i server autorizzati a inviare email per proprio conto, così, quando un server di posta riceverà un messaggio, potrà verificare l’autenticità del mittente controllandone il record SPF.

Nota. Quando un messaggio viene forwardato l’SPF authentication fallisce.

Questo protocollo risulta particolarmente efficace contro gli attacchi di tipo spoofing e phishing.

• DKIM (Domain-Keys Identified Mail): il protocollo utilizza la firma digitale per verificare l’autenticità dell’email ricevuta e confermare che non sia stata manomessa durante la consegna. Il protocollo prevede che il server SMTP del mittente aggiunga una firma (signature) con chiave privata negli header dei messaggi di posta. Questa firma potrà confermare che l’email è stata realmente inviata dal mittente dichiarato e che il contenuto non è stato manomesso durante la trasmissione. Se il server destinatario prevede la verifica della firma, verrà eseguita un’interrogazione DNS del dominio mittente per ottenere la chiave pubblica, con la quale sarà possibile verificare il messaggio e garantirne così l’integrità e la non compromissione della mail. In figura 6 il funzionamento descritto.

Questo protocollo è particolarmente efficace contro gli attacchi “man in the middle”. SPF e DKIM possono cooperare ma non necessariamente devono essere abbinati.

• DMARC (Domain-based Message Authentication, Reporting, and Conformance): è un protocollo che, utilizzando SPF e DKIM, fornisce indicazioni su come dovranno essere gestite le email non autenticate specificando quale azione si dovrà intraprendere in caso non ci sia una corretta la configurazione:
  • None à nessun’azione, il messaggio verrà analizzato dal server di posta ed eventualmente consegnato.
  • Quarantine à il messaggio sarà classificato come non legittimo e quarantenato. Il messaggio in questo caso è ancora recuperabile per un certo periodo (tendenzialmente non oltre i 30 giorni).
  • Reject à il messaggio sarà respinto e non recuperabile.

In figura 7 si può osservare il funzionamento del DMARC.

Sarà compito del DNS Admin configurare correttamente la politica di “pass” dell’email e quando questa invece non dovrà essere consegnata e perché settando quindi il record con una delle policy sopra descritte (none, quarantine o reject). Il DMARC include, inoltre, anche un meccanismo di reporting contenente informazioni dettagliate sul flusso mail aiutando così gli amministratori a monitorare e migliorare la configurazione della sicurezza dei server di posta.

In sintesi, SPF, DKIM e DMARC lavorano insieme per garantire l’autenticità e l’integrità del messaggio verificando che questi sia inviato effettivamente dal dominio dichiarato e che quindi il mail server sia effettivamente autorizzato. L’implementazione corretta e combinata di tutti i protocolli sin qui descritti contribuisce a rafforzare la sicurezza delle comunicazioni via email, proteggendo gli utenti da minacce come spam, phishing e spoofing.

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

https://www.ictsecuritymagazine.com/articoli/email-security-i-protocolli-di-sicurezza-che-garantiscono-lautenticita-lintegrita-e-la-riservatezza-delle-comunicazioni/

Nel panorama della sicurezza informatica, la minaccia di attacchi fisici tramite dispositivi USB malevoli è una realtà crescente. Tra questi, uno dei più insidiosi è il famigerato USBsamurai. Questo piccolo dispositivo, apparentemente innocuo, rappresenta una vera e propria bomba a orologeria per qualsiasi infrastruttura industriale. Scopriamo insieme di cosa si tratta, come funziona e quali misure adottare per difendersi.

Cos’è USBsamurai?

USBsamurai, è solo uno dei tanti impianti hardware maliziosi che vari ricercatori nel mondo hanno creato negli ultimi anni per testare e migliorare la postura di sicurezza di infrastrutture critiche aziendali ed industriali. Il loro comune denominatore è uno: COTTONMOUTH. Nome in codice di un impianto hardware sviluppato dal NSA e reso noto al pubblico da Edward Snowden nel 2013 (https://upload.wikimedia.org/wikipedia/commons/8/85/NSA_COTTONMOUTH-I.jpg). In sintesi, si trattava di un impianto hardware malevolo controllato da remoto via radio, mascherato da innocuo cavetto USB. Il quale, una volta collegato al computer vittima avrebbe permesso all’agente operativo di compromettere remotamente la macchina e dargli accesso illimitato ad essa e, potenzialmente, alla rete a cui tale PC era collegato.

USBsamurai, Origini e Ispirazione

Proprio come COTTONMOUTH, USBsamurai è un dispositivo di hacking. Tuttavia, a differenza del primo, è relativamente semplice da costruire con componenti COTS (Commercial off-the-shelf) facilemnte reperibili ed a basso costo (i.e. 15 EUR), mascherato da cavetto USB, progettato per eseguire attacchi informatici quando viene collegato a un computer o a un sistema industriale. A prima vista, sembra un comune cavo USB, ma al suo interno nasconde potenti funzionalità che lo rendono un’arma temibile.

Come Funziona USBsamurai?

Una volta collegato ad un computer vittima, USBsamurai può eseguire una serie di operazioni malevole in modo autonomo e quasi impercettibili. Ecco alcune delle sue caratteristiche principali:

• Automazione degli Attacchi: Può essere programmato per eseguire comandi specifici non appena viene collegato, come l’apertura di terminali, l’iniezione di comandi o l’installazione di malware.
• Interfaccia HID (Human Interface Device): Simula l’input di tastiera o mouse, permettendo di eseguire azioni come se fossero fatte dall’utente, bypassando molte delle misure di sicurezza standard.
• Raccolta di Informazioni: Può raccogliere dati sensibili dal sistema target e trasmetterli a un server remoto o salvarli localmente per un successivo recupero.
• Bypass di sistemi Air-Gapped Attraverso il controllo remoto via radio ed un protocollo di comunicazione sicuro basato su cifratura AES a 2.4GHz, USBsamurai è perfetto per essere utilizzato in ambienti “Air-Gapped”, poichè creare un canale di comunicazione alternativo e occulto tra l’attacante ed il sistema vittima. Un Air-Gap fisico implica la separazione fisica tra due sistemi informatici. Ad esempio, un’organizzazione quali una banca, un impianto nucleare, un complesso militare, può mantenere un sistema di rete completamente isolato da Internet o da qualsiasi altro sistema esterno.

Perché è Pericoloso per le Infrastrutture Industriali?

Le infrastrutture industriali sono particolarmente vulnerabili agli attacchi fisici per diverse ragioni:

• Accesso Fisico: In molte realtà industriali, il controllo dell’accesso fisico può non essere rigido come quello dei sistemi informatici, permettendo a un attaccante o un ignara vittima a cui è stato donato un device USB malizioso (i.e. vedasi casi noti di attacchi simili [1] [2] [3] [4] [5]) di collegare dispositivi USB con relativa facilità.
• Sistemi Critici: I sistemi industriali controllano processi critici che, se compromessi, possono causare danni significativi, fermare la produzione o addirittura mettere in pericolo vite umane.
• Obsolescenza Tecnologica: Molti impianti utilizzano hardware e software datati, spesso non più supportati o aggiornati, rendendoli particolarmente suscettibili agli attacchi.

Composto da un cavo USB classico, un ricetrasmettitore proveniente da mouse/tastiera wireless ed un firmware creato ad-hoc e disponibile in opensource su github, USBsamurai, una volta assemblato e programmato, può essere controllato a distanza.

USBsamurai non è solo un cavo, ma può essere facilmente utilizzato come impianto hardware interno per armare altri dispositivi USB, per esempio: un mouse, da poi donare/sostituire alla vittima.

USBsamurai in Azione

Osserva USBsamurai in azione in questi video dimostrativi:

1. Attacco simulato a una centrale nucleare
2. Compromissione di un impianto chimico
3. Presentazione del DEFCON demo labs

Nel seguente video è possibile vedere in azione USBsamurai. Il quale viene utilizzato per condurre un attacco nei confronti di una engineering workstation di un impianto nucleare (simulato) in cui viene inoculato un finto malware ransomware per spiegare anche ai meno esperti del settori di come, in determinati ambienti altamente critici, non ci si possa fidare nemmeno di un cavo USB (all’apparenza innocuo).

In questo video, invece, vengono presentati una serie di attacchi ad una simulazione di un infrastruttura industriale (i.e. impianto chimico) ed in particolare la conduzione del cosidetto air-gap bypass che va a colpire un’infrastruttura totalmente isolata con l’esterno. La quale, una volta compromessa con USBsamurai, ha portato all’esplosione del serbatoio di contenimento delle tossine e quindi allo sversamento delle stesse, senza che l’engineering workstation avvisasse il personale in anticipo dell’imminente incidente.

Infine, per i lettori più curiosi, si consiglia la visione della presentazione fatta a DEFCON demo labs:

Come Proteggersi da USBsamurai

USBsamurai rappresenta una minaccia concreta per qualsiasi infrastruttura industriale. La sua capacità di agire in modo invisibile e autonomo lo rende particolarmente pericoloso. È fondamentale che le aziende adottino misure di sicurezza adeguate per proteggere i loro sistemi da questa tipologia di attacchi, garantendo così la continuità operativa e la sicurezza delle loro operazioni. In un mondo sempre più interconnesso e automatizzato, la consapevolezza e la prevenzione sono le armi migliori contro le minacce emergenti. La difesa contro impianti hardware malevoli come USBsamurai richiede un approccio multilivello:

• Controllo degli Accessi Fisici: Implementare misure rigide per controllare chi può accedere alle aree sensibili e ai sistemi critici.
• Politiche di Sicurezza USB: Limitare l’uso di dispositivi USB non autorizzati (i.e. qualsiasi dispositivo USB e non concentrarsi esclusivamente sulle Flash Drives!) eb utilizzare software che possa rilevare e bloccare dispositivi USB malevoli (i.e. soluzioni DLP – Data Loss Prevention).
• Aggiornamenti e Patch: Assicurarsi che tutti i sistemi siano aggiornati e che siano applicate le patch di sicurezza più recenti.
• Educazione e Consapevolezza: Formare il personale sui rischi associati ai dispositivi USB di qualsiasi natura & forma (i.e. innocui cavetti USB inclusi).

Riferimenti e Note

[1] https://www.isssource.com/ics-alert-usb-malware-attack/

[2] https://www.powermag.com/dhs-usb-drives-spread-malware-in-control-system-environment-at-two-power-plants/

[3] https://unit42.paloaltonetworks.com/unit42-tick-group-weaponized-secure-usb-drives-target-air-gapped-critical-systems/

[4] https://www.darkreading.com/ics-ot-security/to-damage-ot-systems-hackers-tap-usbs-old-bugs-and-malware

[5] https://www.securityweek.com/honeywell-usb-malware-attacks-on-industrial-orgs-becoming-more-sophisticated/

Articolo a cura di Luca Bongiorni

https://www.ictsecuritymagazine.com/articoli/sicurezza-industriale-usbsamurai-la-minaccia-invisibile-per-le-infrastrutture-industriali/

Come per tutti i problemi complessi con cause molteplici, non esiste una soluzione per il ransomware che sia contemporaneamente semplice, efficace ed economica. In generale, possiamo distinguere tra contromisure basate sul ripristino dei dati criptati da una intrusione e quelle che mirano a contenere l’intrusione prima del suo successo completo.

Il backup come contromisura

Le contromisure basate sul ripristino dei dati sono efficaci solo quando l’attaccante non ricorre a double extortion o comunque non minaccia la pubblicazione dei dati esfiltrati. La base di queste contromisure sono le copie di backup dei dati. Ovviamente, tali copie vanno difese impedendo che, come quasi sempre accade, l’attaccante le elimini durante la sua intrusione. Una difesa possibile sono strategie come la 3-2-1, che prevede l’utilizzo di almeno tre copie dei dati memorizzate su due supporti diversi, di cui almeno una non in linea o su un altro sistema; non in linea vuol dire non collegato ad una rete e non semplicemente spento, visto che alcuni ransomware possono forzare il boot di una macchina per criptarne le informazioni.

La strategia 3-2-1 è talmente efficace che la gang Lockbit la usa per proteggere le informazioni sui propri malware: ma è difficile garantire l’aggiornamento istantaneo e continuo delle copie, soprattutto di quella non online. Ergo, tutti i dati non ancora memorizzati sulla copia non online potranno andare persi, aumentando il tempo di ripristino.

Una seconda strategia di difesa prevede l’uso di memorie immutabili. Si tratta di memorie worm, write once read many, in cui ogni operazione può essere scritta ma non aggiornata. In generale, la proprietà worm viene garantita in modo nativo da CD-r o DvD-r, oppure utilizzando degli interruttori o delle chiavi fisiche che impediscono l’aggiornamento del supporto fisico di memoria. Memorie worm, ormai messe comunemente a disposizione dai fornitori di servizi cloud, possono essere usate per memorizzare backup; ma sono anche stati sviluppati file system che utilizzano questi dispositivi e che offrono all’utente una interfaccia completamente standard. Sostanzialmente, ogni scrittura di una pagina fisica del file system provoca non la modifica della stessa ma l’allocazione e la scrittura di una nuova pagina. In questo modo, il dispositivo conserva tutte le pagine già scritte e la copia di backup è prodotta automaticamente, pertanto non può essere cancellata.

La robustezza come contromisura

Una soluzione più generale e proattiva cerca di bloccare l’intrusione prima che abbia successo. Ciò richiede l’adozione di difese standard, cioè non specializzate per il ransomware. Tra queste strategie ricordiamo:

• l’aumento della security awarness degli utenti;
• una politica di patching per le vulnerabilità più critiche;
• la classificazione delle informazioni;
• la minimizzazione dei diritti assegnati ad ogni utente;
• il privilegio minimo;
• la segmentazione delle reti.

In particolare, la segmentazione delle reti e la separazione delle varie sottoreti mediante firewall è una delle contromisure più efficaci per il contenimento della diffusione del malware sia nel caso in cui attaccanti usino una piattaforma di attacco automatizzata, sia in quello di human operated ransomware. Le strategie che le varie gang usano nelle loro intrusioni dimostrano che la segmentazione può determinare un aumento significativo del tempo per la raccolta di informazioni e di quello per criptarle, aumentando così il tempo a disposizione dei difensori. Una forma estrema di segmentazione è l’air gap, cioè l’impossibilità di due reti di interagire come richiesto dalla strategia 3-2-1 discussa in precedenza. Un’altra contromisura efficace − soprattutto nel caso di ransomware che esfiltri le informazioni − è l’egress filtering, cioè il filtraggio delle comunicazioni in uscita per individuare comunicazioni anomale in termini di quantità o di destinatari. Tenendo conto che molte gang hanno sfruttato vulnerabilità in sistemi per VPN, in prospettiva, anche soluzioni zero trust potranno essere adottate per respingere intrusioni che sfruttano credenziali rubate o device infettati al di fuori del perimetro aziendale.

Sostanzialmente, la soluzione più generale per contrastare il ransomware non è diversa da quella per contrastare altre minacce ed è basato su una lista di meccanismi e strategie che gli esperti di sicurezza informatica suggeriscono da tempo ma che le organizzazioni, dalle più piccole alle più grandi, non riescono ad adottare. Questo può in parte essere dovuto ai meccanismi di scelta dei responsabili della sicurezza, che privilegiano persone interne all’organizzazione rispetto a quelle in possesso delle competenze necessarie.

Delegare a ditte esterne l’installazione, gestione e manutenzione di strumenti per la propria sicurezza può migliorare, anche drammaticamente, le competenze a disposizione; ma pone uno dei problemi più critici nella situazione attuale, quello dei supply chain attacks e delle vulnerabilità condivise tra organizzazioni diverse. Ad esempio, Solarwinds, una azienda produtrice di strumenti per la sicurezza informatica, è stata vittima di una intrusione che ha permesso all’attaccante di manipolare il codice dei suo tool, facendo sì che ogni utilizzatore di queste soluzioni diventi una potenziale vittima. Intrusioni simili potrebbero coinvolgere le ditte che offrono servizi di sicurezza. A questo si affianca la carenza di risorse che le organizzazioni riservano per la propria sicurezza.

È singolare come l’alta dirigenza delle organizzazioni, sia pubbliche che private, spinga per l’adozione delle tecnologie emergenti per aumentare la competitività aziendale trascurando come ogni adozione aumenti la digitalizzazione dei processi aziendali ma anche la superficie d’attacco dell’organizzazione e i rischi associati.

In contrapposizione ai ridotti investimenti da parte delle vittime, le gang ransomware investono costantemente una parte dei loro profitti per migliorare la qualità dei loro strumenti software e delle loro infrastrutture di attacco. Ad esempio, un anno fa solo poche varianti erano in grado di criptare informazioni su sistemi operativi diversi da Windows: oggi tutte le varianti possono criptare informazioni su qualsiasi sistema Windows o Linux e su macchine virtuali e sono quindi in grado di attaccare qualsiasi server.

Assicurazioni e contrattacchi

Oltre alle soluzioni più tipicamente informatiche e sistemistiche, altre strategie di mitigazione sono state proposte. Una è quella delle polizze assicurative: una soluzione classica per trasferire il rischio ma, dopo un entusiasmo iniziale, le assicurazioni sono restie a coprire il rischio cyber perché è governato da correlazioni e condivisioni spesso ignote a priori. Non siamo nel mondo felice delle assicurazioni auto, dove il fatto che un automezzo è coinvolto in un incidente non cambia la probabilità che un altro automezzo lo sia. Nell’ecosistema informatico, la scoperta di una vulnerabilità in un sistema operativo può cambiare lo scenario di rischio in un numero elevato di sistemi. Il rischio di un singolo evento catastrofico che coinvolga un numero elevatissimo di sistemi informatici preoccupa molto sia gli assicuratori che i riassicuratori. La diffusione di NotPetya ha concretizzato molte delle caratteristiche di un tale evento e ha provocato un numero elevato di cause legali che, per la prima volta, hanno posto il problema delle intrusioni informatiche come atti di guerra in un periodo di guerra non dichiarata. Inoltre, come certificato in numerose audizioni presso il senato US, le assicurazioni non sono attualmente in grado di adeguare il costo delle loro polizze alla effettiva robustezza della singola infrastruttura perché non sanno misurare tale robustezza. Ciò produce un approccio “one size fits all”, che ovviamente i clienti non amano, ed evidenzia la necessità di test per misurare tale robustezza, così come i crash test misurano quella di un’autovettura.

Un recente esempio di contrattacco è quello FBI contro la gang Hive. A partire dal luglio 2022, gli agenti FBI si sono infiltrati nella infrastruttura d’attacco e nei sistemi della gang rubando chiavi di decrittazione che venivano poi fornite alle vittime della gang.

Complessivamente sono state fornite circa 300 chiavi a vittime che erano sotto attacco mentre gli agenti si muovevano nei sistemi di Hive e circa 1000 alle vittime precedenti.

In generale, la fornitura delle chiavi ha permesso alle vittime di risparmiare più di 130 milioni di dollari. Nel gennaio 2023, un’azione congiunta delle forze di polizia di più paesi ha smantellato l’infrastuttura d’attacco e i sistemi di Hive. Coloro che hanno smantellato la gang prevedono che a breve i membri si riorganizzeranno sotto un altro nome o in altro gruppi. Alcune ore dopo l’operazione del FBI, alcuni siti che pubblicizzavano l’offerta di una taglia per informazioni su Hive sono stati bloccati da un attacco DoS. Secondo molti analisti, il DoS è stato realizzato da agenti che hanno operato per conto del governo russo. Questo può fornire indizi sulla sponsorizzazione delle gang ransomware.

Una diversa versione di contrattacco, citata per completezza, è quella della sicurezza offensiva: cioè la possibilità, non per le forze di polizia ma per una organizzazione che scopra di essere attaccata da una gang, di contrattaccare. In pratica, c’è chi propone una innovazione legale che permetta anche ad una organizzazione privata di contrattaccare per smantellare i sistemi delle gang che la stanno attaccando. Ad esempio, Entrust, una grande società di sicurezza informatica, ha in passato eseguito un attacco DoS per impedire l’accesso al sito web dove la gang Lockbit aveva minacciato di pubblicare dei dati esfiltrati da Entrust. L’innovazione è controversa ed estremamente discutibile, visto che le infrastrutture di attacco sono botnet costruite con risorse che non appartengono sicuramente all’attaccante. La proposta evidenzia come anche nel settore civile si possano presentare situazioni che richiedono l’adozione di piattaforme offensive.

Si pensi ad esempio alle azioni per smantellare le botnet che le gang criminali utilizzano nelle loro intrusioni ransomware, ma non solo. Esperienze passate hanno dimostrato che l’efficacia delle azioni per smantellare una botnet dipende dalla capacità di agire simultaneamente su tutta la botnet stessa. Senza tale simultaneità, la tecnologia P2P che le botnet adottano permette alla parte non smantellata di sopravvivere e di ricreare quella eliminata. Solo l’automazione delle azioni in una singola piattaforma può garantire la simultaneità.

Contrasto al riciclaggio

Il miglioramento della tecnologia per analizzare i flussi di pagamento su strutture dati di tipo blockchain e per deanonimizzare i soggetti coinvolti in questi flussi permette di individuare e punire gli attori coinvolti nel riciclaggio dei riscatti. Sfruttando questa tecnologia, a gennaio 2023 il Department of Justice statunitense ha incriminato e arrestato Anatoly Legkodymov, fondatore e maggiore azionista di Bitzlato, una società per il cambio di valute. L’accusa a Bitzlato è quella di riciclare i riscatti del ransomware del dark market Hydra, smantellato nell’aprile 2022. Questi riscatti comprendono anche quelli generati dal ransomware Conti.

Complessivamente, circa il 2% dei fondi gestiti da Bitzlato proveniva da ransomware mentre gli altri erano sostanzialmente legati al mercato della droga.

Il cambio di prospettiva

Molti ricercatori e analisti evidenziano come il fenomeno del ransomware metta in crisi gli strumenti tradizionali di analisi e gestione del rischio. Infatti, il fenomeno richiede un approccio altamente dinamico in cui lo scenario di rischio può essere completamente rivoluzionato in conseguenza di una nuova strategia di attacco o di una nuova vulnerabilità. Inoltre, anche i sistemi da proteggere si evolvono per nuovi nodi, nuove applicazioni e nuovi utenti. È chiaro che tutte queste caratteristiche generano una situazione che è, ad esempio, molto diversa da quelle che le compagnie di assicurazione affrontano tradizionalmente e che hanno tempi di evoluzione minori per molti ordini di grandezza. Non si tratta solo della scarsità delle informazioni su intrusioni, ricatti e danni subiti per la naturale ritrosia delle vittime a condividere tali informazioni. Purtroppo, molte di queste informazioni diventano obsolete all’apparire, ad esempio, di gang che usano strategie di attacco o diffusione del ransomware diverse. Quindi la scarsità dei dati è un fenomeno strutturale, sistemico dell’ecosistema informatico e non è legato a una carenza momentanea a cui si può rimediare creando agenzie che, come per il traffico aereo, raccolgano e facilitino la condivisione di informazioni su incidenti o malfunzionamenti. Fortunatamente, esistono strumenti formali per rimediare alla mancanza di dati: ad esempio il metodo Monte Carlo, che può essere integrato con la tecnologia del digital twin per condurre esperimenti ripetuti che forniscano i dati di interesse ma sintetici. Questi dati possono permette di reagire in tempi brevi o brevissimi a repentini cambi di scenario sia nei sistemi da proteggere che nelle intrusioni contro di essi.

Possiamo concludere dicendo che la necessità di un approccio dinamico alla valutazione e gestione del rischio generato dal ransomware è corretta ma parziale perché, in realtà, tutti i rischi cyber richiedono un approccio dinamico: solo accettando e gestendo questa dinamicità possiamo disporre di solidi strumenti di analisi in grado di gestire anche il rischio ransomware.

Questo articolo è stato estratto dal white paper “Ransomware – Innovazione e redditività del cyber crime” disponibile in maniera libera e gratuita al seguente link: https://www.ictsecuritymagazine.com/pubblicazioni/ransomware-innovazione-e-redditivita-del-cyber-crime/
La monografia del Prof. Baiardi offre un’approfondita panoramica sul fenomeno, partendo dalla sua storia ed evoluzione per poi concentrarsi sul profilo dei principali attaccanti: non più singoli cybercriminali ma gruppi organizzati (che oggi forniscono anche ai “neofiti” i necessari strumenti offensivi tramite il Ransomware-as-a-service o RaaS) nonché attori statali che, sempre più spesso, impiegano tali attacchi a fini di spionaggio o come armi nella guerra cibernetica con altri Stati.

Articolo a cura di Fabrizio Baiardi

https://www.ictsecuritymagazine.com/articoli/ransomware-le-contromisure/

Spam

Anche note con l’acronimo UCE (Unsolicited Commercial Email), sono messaggi pubblicitari indesiderati inviati tendenzialmente a un elevato numero di utenze. Gli spammer e i cybercriminali con l’invio di mail di spam hanno l’obiettivo di:

• • Raccogliere informazioni dai destinatari;
  • Diffondere codice malevolo;

Può essere considerato come spam anche tutto ciò che proviene da un’utenza sconosciuta con qualsiasi tipo di contenuto indesiderato.

Phishing

Sono mail inviate da fonti apparentemente affidabili e note (come, ad esempio, istituti finanziari o aziende) e inducono l’utente che l’ha ricevuta a compiere delle azioni al fine di ottenere informazioni sensibili come: username, password, dati finanziari e/o indurlo all’esecuzione di malware. I messaggi di phishing spesso contengono link fraudolenti in cui si invitano gli utenti a fornire informazioni confidenziali rispondendo direttamente all’email o cliccando sul link malevolo. Gli attacchi di phishing possono avere una vasta gamma di obiettivi a seconda dell’attaccante, come ad esempio, la generica truffa che mira ad ottenere informazioni bancarie/postali. Il phishing può essere di numerose categorie, tra cui:

• • Spear Phishing: più mirata e specifica, in quanto i cybercriminali si concentrano su un individuo o un’organizzazione specifica. Utilizzano informazioni dettagliate per personalizzare i messaggi rendendo così più probabile che le vittime cadano nella trappola. In alcuni casi le campagne di phishing possono essere mirate alle alte sfere aziendali (CEO, CISO ecc), in questo caso si parla anche di Whale Phishing.
  • Smishing: è un attacco che, per la sua esecuzione, utilizza i messaggi di testo o gli SMS. Una tecnica comune di smishing consiste nell’inviare un SMS contenente un collegamento cliccabile o un numero di telefono da richiamare. Un esempio comune è un SMS che sembra provenire dal proprio istituto bancario. Il contenuto afferma che il conto è stato compromesso e che è necessario agire immediatamente. L’attaccante chiederà di cliccare nel link dell’SMS e di verificare numero di conto corrente bancario, codice fiscale, ecc. Una volta inserite, l’aggressore potrà utilizzarle per acquisire il controllo del conto bancario e realisticamente svuotarlo in breve. In figura 3 due chiari esempi di smishing:

• Vishing: questo attacco viene eseguito tramite una chiamata vocale, da qui la “v” al posto delle lettere “ph” nel nome. Un comune attacco di vishing include una chiamata da qualcuno che afferma di essere un rappresentante di un’azienda o un determinato ente (Microsoft e simili). Questa persona, fingendo di voler aiutare, informa l’utente di aver rilevato, ad esempio, una violazione nella sua macchina o l’individuazione di un malware e chiede quindi al malcapitato di fornire informazioni personali (come possono essere carta di credito o username e password) per poi successivamente indurlo a installare un software malevolo o ad effettuare operazioni in suo favore.

Spoofing

E’ una tecnica che utilizza l’impersonificazione come mezzo per rubare informazioni importanti o accedere a conti bancari. Questa pratica viene usata in vari contesti come:

• • Spoofing dell’indirizzo IP, l’invio di messaggi ad una macchina usando un indirizzo IP mascherato come attendibile.
  • Spoofing di mail, la modifica dell’header from di una mail per farla sembrare proveniente da qualcuno o qualcosa di diverso dalla fonte effettiva.
  • Spoofing del DNS, modifica del server DNS al fine di dirottare un nome di dominio specifico verso un indirizzo IP diverso.

Lo spoofing, quindi, è un tipo di impersonificazione che cerca di ingannare una rete o un essere umano per fargli credere che la fonte di determinate informazioni sia attendibile. Gli attaccanti, ad esempio, utilizzano questa tecnica per inviare mail che appaiono come provenienti da qualcuno di fidato, in modo da spingere l’utenza a fornire dati sensibili. In alternativa, possono provare ad utilizzare lo spoofing dell’IP e del DNS per dirottare l’utenza su siti fraudolenti che tenteranno poi di infettare la macchina destinataria.

Business Email Compromise (BEC)

Gli aggressori compromettono un account aziendale e utilizzano l’accesso per condurre frodi finanziarie e truffe. Possono inviare richieste di trasferimenti di denaro e/o ottenere informazioni aziendali sensibili. Secondo un report dell’FBI, nel 2018 ogni giorno, circa 400 aziende sono state vittime di attacchi tramite BEC e che nella maggior parte dei casi gli obiettivi erano gli addetti dello staff finanziario. È stato stimato inoltre che il totale delle perdite, solo nel periodo tra ottobre 2013 e maggio 2018, salì all’astronomica cifra di 12.536.948.299 USD.

Malware tramite email

I cybercriminali possono distribuire malware inviando email con allegati dannosi. Se l’utente viene indotto ad aprire l’allegato, il malware può infettare il sistema, consentendo agli aggressori di prendere il controllo e/o rubarne i dati. Tra i malware più noti vi è “Emotet” un malware bancario diffuso nel 2014 e ancora tutt’oggi utilizzato. La sua peculiarità di questo malware è quella di favorire la propagazione di altri malware scatenando un’infezione multipla. Tra i malware più diffusi da Emotet ci sono: Trickbot (trojan bancario), Quakbot (trojan) e Ryuk (ransomware). In questa categoria viene inclusa dunque anche una delle minacce più rilevanti degli ultimi decenni, ovvero il Ransomware. Gli utenti, in questo caso, ricevono un’email contenente un link o un allegato dannoso. Se l’utente apre il file o clicca sul link, il ransomware infetterà il sistema cifrandone tutti i file. Successivamente, gli aggressori chiederanno un riscatto per rilasciare la chiave di decriptazione. Secondo l’IBM Security X-Force Threat Intelligence, gli attacchi ransomware hanno rappresentato il 17% di tutti gli attacchi informatici solo nel 2022. Questa tipologia di malware è talmente diffusa che da molti anni ormai si parla anche di “Ransomware-as-a-service (RaaS)” ovvero un modello di business per i criminali informatici in cui viene venduto il codice ransomware ad altri hacker che a loro volta metteranno in atto attacchi ransomware per poi successivamente quindi chiedere un riscatto (tipicamente in bitcoin) per decriptarne i dati dei mal capitati. In quest’ultimo caso è fondamentale avere e programmare dei backup periodici (salvati su sistemi esterni) per evitare di pagare e/o perdere i propri dati.

Man-in-the-Middle (MitM)

In questo tipo di attacco, viene intercettata e/o modificata la comunicazione tra due parti. Gli attacchi MitM possono essere eseguiti anche attraverso email, dove gli aggressori cercano di intercettare e/o manipolare i messaggi in transito. Per questo tipo di minacce è fondamentale:

• • Non usare comunicazioni non cifrate;
  • Utilizzare protocolli sicuri come SSL/TLS e HTTPS;
  • Utilizzare almeno la WPA2 encryption;

Zero-Day

Ovvero vulnerabilità di un software non note, ai suoi sviluppatori o da essi conosciuta ma non gestita, utilizzate per compromettere molteplici sistemi. Gli aggressori possono inviare email con allegati o link che sfruttano queste vulnerabilità prima che vengano corrette. Per fronteggiare queste questo fenomeno molte case produttrici di software utilizzano dei “mercati intermediari” in cui vengono convalidate le vulnerabilità zero-day scoperte e, in base alla loro criticità, pagano coloro che l’hanno segnalata. Tra le realtà più consolidate ci sono:

• zeronomi.com
• zerodium.com
• netragard.com
• zerodaytechnology.com
• zerodayinitiative.com

I siti di questo tipo sono completamente legali, in quanto si limitano a validare e retribuire le vulnerabilità scoperte dai diversi “ethical hacker” e simili. Un altro modo per mitigare e/o individuare queste vulnerabilità, oltre alla condivisione delle informazioni (fondamentale per la cyber defense), è fare un uso di sandbox al fine di individuare prontamente comportamenti “inattesi”.

Per proteggersi dagli attacchi veicolati tramite email, è quindi fondamentale adottare pratiche di sicurezza come:

• L’uso di soluzioni di email security;
• Investire sulla formazione dei dipendenti aumentandone la consapevolezza delle minacce veicolate tramite email;
• L’implementazione di politiche di sicurezza rigorose;

Tra i sistemi di sicurezza necessari al rafforzamento del perimetro difensivo in merito all’email security abbiamo:

• Antivirus e antimalware necessari a rilevare e bloccare malware e/o ransomware presenti negli allegati delle email.
• Firewall perimetrali multilivello per monitorare, filtrare ed eventualmente bloccare attività considerate non legittime. L’uso dei firewall va combinato anche con gli IPS/IDS.
• Filtri antispam per bloccare messaggi indesiderati (spam, phishing ecc.) riducendo così il rischio di cadere in truffe o fornire informazioni sensibili.
• Sistemi di autenticazione e firme digitali per garantire che le email provengano da fonti non malevole e che quindi non siano state compromesse durante il trasferimento. Rigettando quindi ogni mail che non abbia la configurazione attesa.
• Algoritmi di crittografia per proteggere i contenuti delle email durante la trasmissione in modo che solo il destinatario autorizzato possa decifrarli garantendo così l’integrità del messaggio.
• Training per i dipendenti, con apposite “campagne awareness” allo scopo di sensibilizzarli sulle minacce informatiche provenienti dalla posta elettronica. Tra le pratiche su cui si deve lavorare, ad esempio, c’è quella di indurre i dipendenti a porre maggior attenzione alle mail provenienti da utenze sconosciute invitandoli quindi ad evitare di aprire allegati o cliccare su link sospetti.
• Politiche di sicurezza aziendali regolando l’uso delle email definendo procedure di sicurezza che stabiliscano criteri per la gestione delle informazioni sensibili. Ad esempio, come in figura 4, utilizzando appositi tag per classificare le comunicazioni (public, internal, confidential e strictly confidential) tramite email.

• Sistemi di monitoraggio e rilevamento delle minacce per individuare attività sospette e/o tentativi di accesso non autorizzato alle caselle di posta elettronica. Attività che può essere supportata da un team di security operation center (SOC)
• Riduzione della superficie d’attacco, riducendo al minimo tutti i servizi esposti e utilizzando protocolli sicuri per le comunicazioni disabilitando anche tutto ciò che non è necessario.

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

https://www.ictsecuritymagazine.com/articoli/email-security-tipologie-di-attacchi-veicolati-tramite-email-e-pratiche-di-sicurezza/

La gestione del rischio relativo alle terze parti sta diventando un aspetto sempre più importante e delicato per chi si occupa di Cyber Security.

Il motivo è molto semplice: la gestione del rischio sugli asset interni al proprio perimetro seppur molto complessa, anche in realtà molto strutturate e di grandi dimensioni ha raggiunto un approccio consolidato.

Aziende che hanno una solida cultura di Cyber Security sono infatti in grado di portare all’approvazione del Board investimenti, anche molto importanti, per implementare soluzioni di sicurezza che controllino la corretta configurazione degli stack SW e/o soluzioni di logging e monitoring che siano in grado di intercettare la maggior parte degli attacchi in una fase preliminare, limitando impatti più ampi.

Il rischio derivante da “soggetti terzi”, quindi esterni rispetto alla propria azienda, è molto più difficile da inquadrare e gestire.

Fino ad oggi, l’approccio di molte aziende è stato e continua ad essere quello di demandare ad aziende terze l’esecuzione di interi processi aziendali, senza però tenere nel debito conto le ripercussioni che un incidente Cyber o più in generale di un data leak occorso sulla terza parte può avere sul proprio contesto aziendale.

Detta in altri termini, c’è la tentazione di considerare un incidente di una terza parte meno grave di un incidente sulla propria infrastruttura, anche in virtù di clausole contrattuali che trasferiscono la responsabilità sulla protezione dei dati e implementazione di presidi Cyber.

Tuttavia, una terza parte può avere all’interno della propria infrastruttura dati personali/critici di cui l’azienda committente è comunque responsabile, nonché avere interconnessioni con la stessa che portano con sé anche il rischio di una propagazione delle minacce sulle infrastrutture e sui servizi, con un possibile impatto sulla continuità del business aziendale.

Nell’RSA Conference del 2023 [1] è stato condiviso uno studio molto interessante condotto dalla Difesa Statunitense che denota un marcato trend che dal 2008 al 2020 evidenzia una sempre maggiore rilevanza degli incidenti di sicurezza relativi alle terze parti.

A ciò si aggiunge al fatto che il livello di rischio Cyber sta aumentando globalmente ed in particolare nel mondo delle Telco:

• Un report di Zayo illustra una crescita di attacchi DDOS del 200% anno su anno globalmente ma con una crescita degli attacchi del 1175% nell’industry delle Telco tra il Q1 e il Q2 del 2023
• La situazione geopolitica a livello mondiale rende le Telco, in quanto infrastruttura critica del paese, un obiettivo rilevante per attori in grado di utilizzare ingenti risorse in attacchi su larga scala, come la disruption operata verso l’operatore ucraino Kyivstar tristemente conferma
• Un trend di crescita di aziende compromesse nei data leak forum delle varie “ransomware” gang. La fine del secondo quarter del 2023 ha visto circa 1350 organizzazioni vittime di ransomware con un increase di circa il 66% rispetto al primo quarter secondo studi di settore

Ma perché vediamo un trend così netto verso le terze parti negli incidenti relativi alla sicurezza informatica?

In una società sempre più digitalizzata, gli attacchi informatici sono diventati più sofisticati e attraggono molti più attori del passato, anche in virtu’ di una “democratizzazione” dei tool che consentono anche ad attori con poca esperienza di far leva su strumenti o servizi estremamente avanzati, quali ad esempio Ransomware as a Service (RaaS), Phishing as a Service (PhaaS) o DDOS as a Service (DaaS).

Da un lato realtà con una rilevante dimensione, spesso guidate anche da tematiche regolatorie, hanno intrapreso un percorso di incremento della resilienza Cyber sui propri asset primari.

Dall’altro lato, l’ecosistema delle terze parti, spesso fatto da aziende di dimensioni molto più contenute e con una limitata capacità di investimento, hanno faticato a definire piani ugualmente efficaci e si stanno dimostrando come l’anello debole della catena.

Risulta facilmente intuibile come per un attaccante sia meno oneroso e probabilmente altrettanto redditizio compromettere una terza parte per entrare in possesso dei dati delle aziende appaltatrici o da lì, trovare accesso alle loro reti.

Di seguito alcuni spunti di riflessione non esaustivi, che possono aiutare ad avviare un percorso di migliore gestione del rischio:

Valutare l’opportunità di un outsourcing esplicitandone e accettandone il rischio implicito:

Come chiarito sopra, il controllo di una terza parte non può essere mai equivalente al controllo sugli asset presente nell’organizzazione interna ed è necessario prenderne esplicitamente coscienza. Non sempre demandare processi all’esterno è un vantaggio nel momento in cui si prende coscienza dei rischi e delle necessarie azioni da mettere in campo per mitigarli. L’opportunità va esplicitamente valutata in termini di costi/benefici e se l’outsourcing rimane comunque l’opzione migliore, è importante fare una attenta analisi dei dati che si rende necessario esportare verso la terza parte e degli eventuali impatti di business nel caso di interruzione del servizio a causa di incidenti.

Identificare un robusto framework contrattuale:

Avere una resilienza nella Cyber Security ha un costo ed è necessario proteggere gli investimenti internamente alla terza parte rendendoli parte del framework contrattuale, non solo in termini di controlli ma anche di eventuali penali/rescissione del contratto nel caso si verifichino eventi non correttamente gestiti.

Assicurarsi che la terza parte implementi i controlli più rilevanti, entrando nel merito della qualità implementativa:

La maggior parte degli incidenti hanno le stesse cause, ad esempio assenza di MFA, assenza di WAF/IPS, Vulnerability critiche esposte sul perimetro esterno, attacchi di social engineering, assenza di anti-malware/EDR sugli asset, assenza di logging e monitoring. Identificare i controlli prioritari e fare un deep dive della loro implementazione con la terza parte sia in termini di adeguatezza di funzionalità che di copertura degli asset ha un enorme valore in termini di prevenzione rispetto ad un self assessment su un numero ampio a piacere di controlli generici spesso fatto all’unico scopo di rispettare processi di compliance.

Supportare le terze parti con rilevanti feed di Threat Intelligence:

La lotta tra chi difende e chi attacca è per definizione impari. Un attaccante ha mesi/anni per preparare un attacco, mentre chi difende si trova spesso a disperdere energie su più fronti e a dover reagire in tempi molti stretti. In questa situazione, è fondamentale l’apporto della Threat Intelligence, che consente di focalizzare gli sforzi nelle aree più critiche sia in termini di vulnerabilities che di tecniche usate dagli attaccanti per compromettere asset. Difficilmente aziende piccole sono in grado di avere una capability di Threat Intelligence matura, pertanto fornire alle proprie terze parti informazioni rilevanti per aiutarle a direzionare gli sforzi è sicuramente un approccio da valutare.

È chiaro dagli spunti sopra citati che si tratta di una tematica articolata e che non esiste una unica ricetta per far fronte a questa tipologia di rischio la cui gestione ha un costo sia in termini di complessità che di budget.

Per questo motivo, anche in considerazione delle implicazioni di business che ne possono conseguire, il rischio delle terze parti e la sua conseguente gestione è uno dei temi più importanti da riportare quando si parla di rischio Cyber. Renderlo evidente al Board e definire un approccio strutturato sono un ottimo punto di partenza per iniziare ad affrontarlo nel modo più corretto.

Note

[1]: How Top CISOs Are Transforming Third-Party Risk Management (rsaconference.com)

Articolo a cura di Luigi Iaccarino

https://www.ictsecuritymagazine.com/articoli/third-parties-che-ruolo-giocano-nella-sicurezza-aziendale/

Al pari delle altre prove scientifiche, la digital evidence esige di essere trattata con estrema cura e valutata con particolare attenzione. Il fatto che l’elemento probatorio sia il frutto di un procedimento scientifico non significa di per sé che sia sicuramente attendibile; o meglio, sebbene scientificamente attendibile, non dimostra automaticamente che un soggetto abbia realizzato una determinata condotta criminosa. Per fare un esempio, il rinvenimento di una traccia genetica in un luogo non vuol dire conseguenzialmente che il soggetto che l’ha lasciata abbia commesso il delitto ivi consumato. Costui potrebbe essere passato in quel luogo in un momento precedente o successivo, oppure la traccia genetica potrebbe esservi stata trasportata involontariamente da altri soggetti sui quali, per qualsiasi ragione, si era posata. Da questo esempio si comprende agevolmente il fattore da tenere sempre in considerazione quando ci si trova a trattare la prova scientifica, ovvero la contestualizzazione del reperto rinvenuto.

Ne deriva che anche il dato digitale estratto mediante acquisizione in copia forense vada valutato e contestualizzato all’interno dell’intero quadro investigativo, tenendo a mente che da un’errata analisi potrebbe scaturire un’erronea interpretazione del quadro probatorio nel suo complesso e, di conseguenza, un errore giudiziario.

Tra i casi giudiziari più recenti dove una scorretta interpretazione degli esiti delle operazioni di informatica forense ha rischiato di trasformarsi in un clamoroso errore giudiziario vi è il processo celebratosi presso la Corte d’Assise del Tribunale di Palermo nei confronti del cittadino eritreo Behre Medhanie Tasmafarian, noto alla cronaca giudiziaria come caso Mered^[1].

Una serie di errori investigativi avevano convinto le autorità britanniche a ritenere che Behre Medhanie Tasmafarian fosse in realtà il trafficante di migranti Medhanie Yehdego Mered detto “il generale”, ricercato dalle forze dell’ordine di diversi paesi.

Le errate intuizioni portavano nel 2016 all’arresto del cittadino eritreo mentre si trovava in Sudan e successivamente alla sua consegna mediante estradizione in Italia, dove veniva posto sotto custodia cautelare in carcere e quindi processato con l’accusa di tratta di esseri umani.

Le inesattezze investigative originavano dall’interpretazione di alcune frasi pronunciate dal Bhere, mentre comunicava col proprio telefono cellulare, parlando di viaggi migratori. Questa circostanza, unita all’omonimia tra il cittadino eritreo e il generale, induceva le forze britanniche ad inciampare nella convinzione che si trattasse della stessa persona. Seguiva il sequestro del dispositivo e la sua sottoposizione alla procedura di estrazione in copia forense, mediante la quale venivano clonate tutte le chat presenti sul dispositivo – quelle presenti sui social network comprese – tutti i file audio, video, immagine, i dati di navigazione internet e tutta la cronologia delle telefonate effettuate, sia tramite applicazione che sulla linea telefonica tradizionale^[2]. Tuttavia, ancora una volta, i dati estratti venivano fraintesi non facendo altro che avvalorare l’erronea tesi propugnata dall’accusa, in seguito smontata unicamente grazie alla prova genetica e agli esiti della perizia fonica che accertavano come si fosse trattato, in realtà, di soggetti diversi. Seguiva quindi, dopo tre anni di carcerazione preventiva, la sentenza assolutoria con la quale il Tribunale di Palermo stabiliva il non doversi procedere dopo aver accertato l’avvenuto scambio d’identità tra il cittadino eritreo coinvolto nel processo e il trafficante di migranti Medhanie Yehdego Mered.

Un altro caso emblematico, dove la digital forensics ha giocato un ruolo fondamentale, è il celebre “delitto di Garlasco”, relativo al tragico omicidi o di una giovane ragazza nell’omonima località della provincia pavese e dal quale è scaturito uno dei processi mediatici più seguiti dalla cronaca giudiziaria italiana.

Senza entrare nel merito della vicenda processuale, durata ben cinque gradi di giudizio con due pronunce della Suprema Corte e conclusasi con la condanna definitiva del fidanzato della vittima, è di interesse la pronuncia assolutoria di primo grado emessa dal Tribunale di Vigevano^[3], dove sono stati effettuati ampi ragionamenti in merito al valore attribuibile ad una prova informatica colpita da fenomeni contaminativi^[4].

Nel caso di specie, il reperto informatico attenzionato durante le indagini consisteva nel personal computer dell’imputato, utile al fine di stabilire l’attendibilità dell’alibi del medesimo durante la mattina in cui si era svolta l’azione delittuosa. Secondo la ricostruzione dell’imputato, infatti, durante i momenti in cui si consumava l’omicidio egli si sarebbe trovato nella propria abitazione, innanzi al proprio computer, intento a lavorare alla tesi di laurea.

L’analisi del dispositivo, una volta accertato che per motivi tecnici non sarebbe stato possibile un suo utilizzo sulla scena del crimine, si palesava dunque necessaria al fine della ricostruzione della timeline delle attività ivi compiute, al fine di stabilire se il dispositivo fosse stato realmente adoperato in orari compatibili con quelli dell’omicidio.

Si poneva, tuttavia, un problema di non poco conto: durante le prime fasi d’indagine la genuinità delle informazioni memorizzate nel computer era stata pesantemente compromessa. Come riportato in sentenza, «quando il reperto informatico veniva consegnato ai consulenti tecnici del pubblico ministero che procedevano all’effettuazione delle copie forensi dello stesso, i carabinieri accedevano ripetutamente e scorrettamente (senza l’utilizzo, cioè delle necessarie tecniche forensi di indagine) alla quasi totalità del contenuto del computer»^[5]. L’effettuazione di tali accessi, condotti senza il rispetto dei principi basilari dell’informatica forense già noti all’epoca delle indagini^[6], provocava «la sottrazione di contenuto informativo con riferimento al personal computer di Alberto Stasi pari al 73,8% dei files visibili (oltre 56.000) con riscontrati accessi su oltre 39.000 files, interventi di accesso su oltre 1500 files e creazione di oltre 500 files. Insomma interventi che hanno prodotto effetti devastanti in rapporto all’integrità complessiva dei supporti informatici (in questi termini si esprime il collegio peritale)», come si legge in un passaggio successivo «Si deve, dunque, ritenere che questa preliminare e sommaria attività investigativa è stata posta in essere secondo una metodologia sicuramente scorretta, disattendendo i protocolli già invalsi in materia (anche prima dell’entrata in vigore della legge citata) venendo, quindi, a costituire una causa di potenziale alterazione e dispersione del contenuto del documento informatico».

Alla luce dei danni arrecati al contenuto digitale del dispositivo, descritti come «devastanti», il giudice si trovava dunque innanzi alla necessità di comprendere se le informazioni in esso ricavabili potessero essere ugualmente utilizzabili in giudizio – e in caso positivo fino a che punto – oppure se, a prescindere, si fosse dovuta dichiararne l’inutilizzabilità.

Partendo dall’assunto che, nonostante gli accessi incauti dei primi investigatori, i consulenti dell’accusa riuscirono ugualmente a stabilire, con le immancabili incertezze del caso, una timeline delle operazioni del dispositivo^[7], in sentenza non è stata adottata una posizione di assoluto rifiuto nei confronti della prova informatica acquisita con le modalità sopra viste.

Il giudice, nel percorso logico che lo ha condotto alla decisione, ha operato una verifica degli elementi informatici incrociandoli con dati estratti da altri dispositivi elettronici. Sostanzialmente, l’attendibilità delle digital evidence estratte dal computer dell’imputato non è stata cercata unicamente all’interno delle stesse, bensì si è fatto ricorso ad elementi esterni ad esse per valutare se e in che modo tutte le risultanze, ad un esame incrociato, combaciassero tra loro.

In altre parole è stato fornito un giudizio di attendibilità della prova informatica, con conseguente conferma positiva circa la sua utilizzabilità processuale, ricorrendo ad altri elementi che in qualche modo, secondo il giudice, hanno consentito di dare conferma della genuinità delle informazioni estratte dal computer dell’imputato per quanto riguarda la linea temporale delle operazioni svolte.

Benché l’aver giudicato utilizzabile del materiale ottenuto con metodologie di acclarata scorrettezza procedurale desti sicuramente delle perplessità, si deve osservare come in ogni caso la pronuncia abbia il merito di aver chiarito come metodi investigativi non conformi alle logiche scientifiche possano comportare, nelle procedure di digital forensics, danni irreparabili alle evidenze informatiche, le quali, peraltro, necessitano di essere calate all’interno dell’intero quadro dell’indagine e non valutate in autonomia^[8].

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] Corte d’Assise del Tribunale di Palermo, Sent. del 12 luglio 2019.

^[2] Sulla questione si veda l’inchiesta dalla testata giornalistica online Irpimedia, “Errori giudiziari: come la prova tecnologica manda in carcere un innocente” realizzata ad opera di R. COLUCCINI, consultabile sul sito https://irpimedia.irpi.eu/prova-tecnologica-caso-mered/.

^[3] Tribunale di Vigevano, Sent. del 17 dicembre 2009.

^[4] Sullo stesso argomento si veda anche A. GAMMAROTA con relatore C. MAIOLI, “Informatica forense e processo penale: la prova digitale tra innovazione normativa e incertezze giurisprudenziali” [dissertation thesis], 2016, pp. 120 e ss., consultabile sul sito http://amsdottorato.unibo.it/7723/1/Gammarota_Antonio_tesi.pdf, opera dalla quale si sono prese le mosse per la disamina della questione.

^[5] Nel particolare le operazioni scorrette svolte dai carabinieri che per primi accedevano al dispositivo erano consistite in «sette (e non cinque come riferito) accessi al personal computer di Alberto Stasi; non corretta indicazione dell’avvenuta installazione ed utilizzo di diverse periferiche USB (oltre a quella correttamente indicata); non corretta indicazione dell’avvenuto accesso al disco esterno in uso ad Alberto Stasi; non corretta indicazione di accessi multipli al file della tesi di laurea in vari percorsi di memorizzazione dello stesso: si vedano sul punto i rilievi del collegio peritale tecnico/informatico».

^[6] Sul punto si deve tenere presente che, sebbene la sentenza risalga alla fine del 2009, le attività di indagine sul dispositivo si sono svolte in un periodo di poco successivo alla commissione del delitto, risalente all’estate del 2007, momento in cui la legge n. 48 del 2008 ancora non era entrata a far parte del nostro ordinamento. Tuttavia, la pronunci mette in chiaro come, nonostante la legge sia entrata in vigore in un momento successivo alle indagini, le metodologie tecniche proprie della digital forensics erano già invalse nella prassi delle attività investigative aventi ad oggetto reperti informatici.

^[7] Più precisamente in sentenza si legge: «Il complesso di queste alterazioni veniva rilevato anche dai consulenti tecnici del pubblico ministero (i Ris di Parma) nella loro successiva analisi. Pur tenendo conto di quanto sopra, i Ris, nella loro relazione tecnica e successive integrazioni e chiarimenti, concludevano sostanzialmente nel senso che il giorno 13 agosto 2007 il computer portatile di Alberto Stasi veniva acceso alle ore 9.36; quindi venivano aperte delle fotografie digitali fino alle ore 9.57 e dopo le ore 10.17 non sarebbero presenti tracce informatiche che comportino la presenza attiva di un utente che interagisce con il PC», tuttavia, il collegio peritale, sempre come indicato in sentenza, riusciva in ogni caso mediante l’estrazione dei metadati esterni al sistema operativo a stabilire «con certezza (e questo è un’evidenza probatoria non contestata dalle parti) l’interazione diretta e sostanzialmente continuativa dell’utente con il computer dalle ore 10.17 fino alle ore 12.20 del giorno 13 agosto».

^[8] Si veda A. GAMMAROTA, op. cit., pp. 136-138 dove, nonostante la sentenza sia ormai risalente nel tempo, si ritiene che «il percorso logico-argomentativo della sentenza appena ripercorsa si pone come moderno paradigma per la corretta valutazione dell’attendibilità dei dati, nonché della corretta interrelazione delle informazioni derivanti dai dispositivi digitali».

Articolo a cura di Francesco Lazzini

https://www.ictsecuritymagazine.com/articoli/precedenti-emblematici-il-caso-mered-e-la-sentenza-di-primo-grado-sul-caso-di-garlasco/

“La sicurezza è un processo, non un prodotto. I prodotti offrono una certa protezione, ma l’unico modo per fare business in modo efficace in un mondo insicuro è mettere in atto processi che riconoscano l’insicurezza intrinseca nei prodotti.”

Questa citazione, tratta dal saggio di Bruce Schneier intitolato “Il Processo della Sicurezza” scritto nel 2000, riassume perfettamente gli obbiettivi e la missione della Sicurezza del Prodotto:

• I prodotti non possono essere considerati sicuri al 100% per definizione.
• Non possiamo affidarci ciecamente a loro senza una corretta analisi del rischio. Ecco perché la loro maturità di sicurezza intrinseca deve essere costantemente verificata e corretta per minimizzare i rischi di minacce.
• Per minimizzare tali rischi di minacce/vulnerabilità, è cruciale implementare la sicurezza in ogni fase del Ciclo di Vita del prodotto.

Nei paragrafi seguenti indagheremo più in dettaglio diversi aspetti della Sicurezza del Prodotto (i.e. ProdSec).

Partendo dalle definizioni formali di: Minaccia, Rischio & Vulnerabilità, approfondiremo le definizioni di SDLC Sicuro (Secure Software Development Life Cycle), SecDevOps, Threat Modeling e come adottarli e implementarli per migliorare i processi di R&S di un’azienda e la relativa postura di sicurezza. Infine, analizzeremo un case-study dal punto di vista di un fornitore di telecomunicazioni, e un case-study relativo a un tool di sicurezza (i.e. Zsniffer) sviluppato in-house per sopperire alle lacune delle controparti commerciali esistenti.

Stato dell’Arte della Sicurezza del Prodotto

Stiamo entrando in una nuova era in cui realtà e mondo digitale coesistono fianco a fianco, alimentati da progressi tecnologici come ICT, 5G, AI, Cloud, Machine Learning, etc. In questa rivoluzione digitale, la cybersecurity emerge come un attore altrettanto importante.

Dall’ultimo rapporto del World Economic Forum [1] emerge come la superficie di minaccia (i.e. Threat Surface) stia aumentando a livello globale. Tale analisi, illustra l’espansione del panorama della cybersecurity in tutte le sue sfaccettature e individua l’infrastruttura delle telecomunicazioni come fondamenta del mondo digitale, enfatizzando il suo ruolo critico nel garantire una postura corretta di sicurezza.

Lo stato dell’arte nella sicurezza del prodotto all’interno dell’industria delle telecomunicazioni è caratterizzato da un panorama in rapida evoluzione dove la sicurezza sta diventando una parte integrante del ciclo di vita del prodotto, guidata dalla crescente complessità delle minacce e dai rigorosi requisiti normativi (i.e. 5G Toolbox, PSNC, NIS2, etc.).

Le aziende di telecomunicazioni stanno integrando misure di sicurezza avanzate come la crittografia end-to-end, audit di sicurezza regolari e threat intelligence in tempo reale nei loro prodotti e infrastrutture.

L’adozione di pratiche di SDLC Sicuro, il dispiegamento di strumenti di sicurezza automatizzati nelle pipeline CI/CD e l’implementazione di strategie robuste di risposta agli incidenti stanno diventando uno standard.

Con l’ascesa della tecnologia 5G e dei dispositivi IoT, c’è un significativo focus sul potenziamento della sicurezza delle reti e dei dispositivi contro minacce informatiche sofisticate, garantendo l’integrità e la disponibilità dei servizi di comunicazione.

Vulnerabilità vs Minaccia vs Rischio

Nel campo della cybersecurity, è fondamentale distinguere tra rischio, vulnerabilità e minaccia, ognuno dei quali rappresenta un elemento critico nel panorama della sicurezza e della gestione del rischio.

L’immagine sopra è utile per comprendere al meglio questi tre concetti:

• La porta aperta simboleggia una Vulnerabilità: una debolezza o una lacuna (ad esempio, un punto di ingresso non sicuro nel sistema) che potrebbe essere sfruttata da un attore malevolo (i.e. Threat Actor).
• L’orso all’esterno rappresenta una Minaccia: un attore esterno che può sfruttare tale vulnerabilità, con il potenziale per causare danni o interruzioni di servizio.
• Il Rischio è la probabilità e l’impatto potenziale che l’orso (Minaccia) effettivamente passi attraverso la porta aperta (Vulnerabilità) e causi il caos. Esso considera la probabilità che la minaccia sfrutti quella determinata vulnerabilità e i danni conseguenti che potrebbero derivarne.

I professionisti della cybersecurity, quali CISO, Security Manager e team di Sicurezza dei Prodotti, lavorano diligentemente per identificare e chiudere le “porte aperte”, valutare la capacità e l’intento di potenziali “orsi” e implementare misure per ridurre il rischio complessivo a un livello accettabile, garantendo che venga rispettato il paradigma CIA (Confidentiality, Integrity & Availability), pilastro portante della sicurezza.

Zero-Day Vs n-Day e Patching Management

Dopo aver chiarito cosa si intende per vulnerabilità, approfondiamo ora le due tipologie in cui queste si suddividono e la differenza tra di loro:

– Vulnerabilità 0-day (Zero-Day): questo termine si riferisce a una falla di sicurezza che è sconosciuta sia ai produttori di software sia agli utenti. Dal momento che il produttore ha avuto “zero giorni” per affrontare la vulnerabilità, essa può essere sfruttata dagli aggressori prima che il produttore ne sia a conoscenza e possa correggerla. Gli aggressori sfruttano tipicamente le 0-day sviluppando o acquistando un malware creato per colpire la vulnerabilità specifica, il che spesso porta ad attacchi avanzati e mirati. Questa tipologia di vulnerabilità è molto preziosa per i threat actor in quanto non esiste una difesa nota contro di esse nel momento in cui vengono sfruttate. Al contempo però cercare di usare questa tipologia risulta sicuramente più dispendioso.

– Vulnerabilità n-Day: rappresentano vulnerabilità che al contrario sono già state divulgate pubblicamente e possono essere note sia al produttore che al pubblico, ma che per vari motivi non sono state ancora corrette dagli utenti. La “n” indica il numero di giorni da quando la vulnerabilità è stata resa pubblica. Le vulnerabilità n-day vengono comunemente sfruttate utilizzando metodi e strumenti noti disponibili nella comunità hacker, poiché i dettagli di queste vulnerabilità sono di solito di pubblico dominio.

Risulta dunque, evidente che una gestione adeguata delle Patch di sicurezza (i.e. Vulnerability Patch Management) è essenziale per le aziende al fine di mitigare i rischi associati alle vulnerabilità.

Implementando tempestivamente le patch, le aziende possono eliminare la finestra di opportunità che permette agli aggressori di sfruttare queste vulnerabilità.

Il dispiegamento tempestivo delle patch è dunque cruciale per proteggersi da violazioni di dati, attacchi ransomware e altri incidenti di sicurezza che possono derivare da vulnerabilità non mitigate. Una loro gestione efficace non solo protegge le reti aziendali, ma preserva anche la fiducia dei clienti e rispetta i requisiti normativi riguardanti la cybersecurity.

In sostanza, comprendere la differenza tra vulnerabilità 0-day e n-day è fondamentale non solo per i professionisti della cybersecurity, ma per tutti i soggetti coinvolti nello sviluppo dei prodotti, in quanto permette alle organizzazioni di modellare le strategie difensive da adottare per salvaguardare i loro asset digitali.

CISO (Assets Security) Vs CPSO (Products Security)

Nell’immagine sopra si può osservare il confronto tra i ruoli del Chief Information Security Officer (CISO) e del Chief Product Security Officer (CPSO), ognuno con responsabilità distinte. Il CISO è tipicamente quel dirigente responsabile per la strategia di sicurezza complessiva di un’organizzazione. Questo ruolo comprende la protezione sia degli asset fisici che digitali, inclusa l’integrità dei dati aziendali e dell’infrastruttura di rete. Esso è incaricato della gestione del rischio, dell’implementazione di politiche e procedure di sicurezza e della conformità agli standard e alle normative del settore.

Al contrario, il ruolo del CPSO, spesso presente nelle aziende degli Stati Uniti, è focalizzato sulla sicurezza dei prodotti. Esso assicura che gli aspetti di sicurezza dei prodotti rispettino standard e requisiti rigorosi.

Con l’evolversi del panorama della cybersecurity, l’aumento della connettività e della complessità dei prodotti, il ruolo del CPSO dovrebbe assumere sempre più importanza all’interno delle aziende produttrici. Questo perché la sicurezza del prodotto non riguarda solo la salvaguardia degli asset informativi, ma anche l’assicurazione dell’integrità dei prodotti stessi.

Rendendo il CPSO una posizione standard all’interno del consiglio di amministrazione dell’azienda, i produttori possono meglio garantire che i loro prodotti siano progettati e costruiti avendo la sicurezza come elemento fondamentale e non come un optional o requisito postumo.

A mio avviso, questo cambiamento è vitale per mantenere la fiducia dei clienti e soddisfare le esigenze di un’industria (tra le altre, le Infrastrutture Nazionali Critiche, come quella delle Telecomunicazioni) dove la sicurezza è una componente intrinseca dell’affidabilità del prodotto.

SDLC Vs Secure SDLC

Il classico SDLC (Software Development Life Cycle) è un framework che definisce il processo per creare software tradizionalmente focalizzato sulle fasi di raccolta dei requisiti, progettazione, sviluppo, test e dispiegamento. Ogni fase segue l’altra in una sequenza lineare o iterativa, dove l’obiettivo principale è la creazione di un software funzionale entro i vincoli di tempo e budget dettati dal mercato.

Il Secure SDLC è un approccio sistematico per sviluppare un software sicuro che integri la sicurezza in ogni fase del processo di sviluppo. Come illustrato nell’immagine qui sopra, esso inizia con la valutazione del rischio (Risk Assessment), la modellazione delle minacce (i.e. Threat Modeling) e la revisione della progettazione sicura (i.e. Security Architecture Review) per anticipare e mitigare potenziali problemi di sicurezza durante la fase di progettazione, l’analisi statica (SAST) durante lo sviluppo per individuare precocemente le vulnerabilità, i test di sicurezza e la revisione del codice per verificare le misure di sicurezza, e la valutazione della sicurezza e la configurazione sicura durante il dispiegamento per garantire la resilienza del software contro gli attacchi.

I benefici nell’addottare il Secure SDLC sono molteplici:

• Riduzione delle Vulnerabilità: affrontando la sicurezza dalle fasi iniziali, i produttori possono ridurre significativamente il numero e la gravità delle vulnerabilità nei loro prodotti consegnati ai clienti B2B e/o eventualmente agli utenti finali.
• Efficienza dei Costi: È risaputo che è più economico affrontare i problemi di sicurezza durante il processo di sviluppo piuttosto che dopo la messa-in-campo, poichè richiederebbe sforzi maggiori, più complessi e costosi. Per non parlare dei danni eventuali legati alle violazioni dei dati dei clienti e alla reputazione dell’immagine.
• Conformità e Fiducia: I prodotti sicuri sono più propensi a rispettare gli standard normativi, il che è essenziale per mantenere la fiducia dei consumatori e proteggere la reputazione del marchio aziendale.
• Vantaggio Competitivo: I prodotti sicuri offrono un vantaggio competitivo, poiché i clienti B2B, come i fornitori di servizi Internet (ISP) e gli operatori di rete mobile (MNO), preferiscono i fornitori che offrono prodotti con robuste caratteristiche di sicurezza.
• Protezione dell’Utente Finale: In ultima analisi, le misure di sicurezza radicate nei prodotti contribuiscono alla protezione dei dati sensibili degli utenti finali, riducendo la probabilità di violazioni dei dati e migliorando la sicurezza informatica complessiva.

Per un’azienda produttrice di telecomunicazioni, implementare il Secure SDLC significa che i suoi prodotti sono progettati co il rischio di potenziali minacce, le quali, se considerate e mitigate in tempo, portano a reti di comunicazione più sicure e affidabili, che è un pilastro fondamentale nella società digitalmente connessa di oggi.

DevOps Vs SecDevOps

In generale, implementare un processo di DevSecOps non è banale. All’interno del mondo delle telecomunicazioni non è affatto più semplice. Il passaggio da DevOps a DevSecOps è impegnativo e richiede cambiamenti e adattamenti.

La chiave sta nel personalizzare le pipeline per facilitare l’automazione. Inoltre, gli strumenti di scansione commerciali, a volte, sono troppo generici per la varietà di protocolli specifici del settore delle telecomunicazioni.

Questo è il motivo per cui si verifica spesso un’ampia personalizzazione e lo sviluppo di strumenti interni.

Principali differenze tra DevOps e SecDevOps

Con DevOps si intende l’insieme di pratiche che combina lo sviluppo software (Dev) e le operazioni IT (Ops) mirando a ridurre il ciclo di vita dello sviluppo.

DevOps enfatizza la collaborazione, l’automazione e l’integrazione tra sviluppatori e personale IT per migliorare la velocità e la qualità della consegna del software.

SecDevOps integra pratiche di sicurezza all’interno del processo DevOps. La principale differenza che si riscontra tra i due è il focus esplicito sulla sicurezza. Mentre DevOps potrebbe incorporare misure di sicurezza, SecDevOps garantisce che la sicurezza sia una priorità in ogni fase del processo di sviluppo e messa-in-campo. Esso comporta l’aggiunta di controlli di sicurezza nella pianificazione, codifica, pre-dispiegamento e anche dopo il dispiegamento, rendendo la sicurezza una responsabilità condivisa dei team di sviluppo, di operazioni e di sicurezza.

Questo approccio mira a individuare e affrontare le vulnerabilità in modo più proattivo, piuttosto che trattare la sicurezza come un passaggio finale o un processo separato che avviene dopo che sviluppo e operazioni hanno fatto la loro parte.

Implementazione di SecDevOps per lo Sviluppo del Prodotto

Implementare correttamente SecDevOps in un’azienda che crea prodotti richiede un cambiamento culturale per cui la sicurezza viene integrata nel modo di pensare e nelle responsabilità di ogni membro del team coinvolto nel ciclo di vita dello sviluppo del prodotto.

Ecco una breve panoramica su come un’azienda può implementare SecDevOps:

• Security-As-Code: La sicurezza dovrebbe essere integrata nel codice sorgente fin dall’inizio. Ciò implica l’utilizzo di strumenti di test di sicurezza delle applicazioni statiche (SAST) e dinamiche (DAST), all’interno della CD/CI pipeline, per scansionare automaticamente le vulnerabilità nel codice e negli ambienti di runtime.
• Test Precoce e Continuo: I test di sicurezza dovrebbero avvenire fin dalla fase iniziale e ripetuti periodicamente. I test automatizzati dovrebbero far parte del normale processo di build e dispiegamento per garantire un feedback immediato su nuovi problemi di sicurezza.
• Educazione e Formazione: Sviluppatori, personale delle operazioni e team di sicurezza dovrebbero ricevere una formazione regolare sulle migliori pratiche di sicurezza attualmente presenti ed essere incoraggiati a mantenere una mentalità orientata alla sicurezza. Un modo per farlo potrebbe essere quello di adottare la cosiddetta “Rete di Security Champions”, che verrà spiegata in dettaglio in seguito.
• Collaborazione e Comunicazione: andrebbe incoraggiata la comunicazione aperta tra sviluppatori, operazioni e team di sicurezza per promuovere un ambiente collaborativo in cui la sicurezza diventa un obiettivo condiviso.
• Incident Response Planning: Bisognerebbe dotarsi di un piano di risposta agli incidenti ben definito che coinvolga tutti gli stakeholder e venga regolarmente testato e aggiornato.
• Monitoraggio e Aggiustamento: l’azienda dovrebbe monitorare continuamente il prodotto e il processo SecDevOps per nuove minacce e inefficienze, adeguando strategie e strumenti di conseguenza.

In conclusione di questa breve panoramica, dovrebbe essere chiaro al lettore che implementare SecDevOps significa considerare la sicurezza non come un ostacolo ma bensì come un facilitatore.

Incorporando la sicurezza nella cultura DevOps, le aziende assicurano che i loro prodotti siano sicuri sin dalle prime fasi di progettazione, proteggendo così gli interessi dei loro clienti.

Case Study: Il Processo HPPD (High Performance Product Development)

Per fornire un esempio pratico al lettore, possiamo guardare all’approccio di ZTE al Secure SDLC (Secure Software Development Lifecycle). Per maggiori informazioni si rimanda il lettore al nuovo ZTE Cybersecurity White Paper rilasciato a dicembre 2023.

Un processo di R&S (Ricerca & Sviluppo) integrato con la sicurezza è essenziale per fornire prodotti di alta qualità e sicuri. Nel 2001, il Security Development Lifecycle (SDL) creato da Microsoft ridusse il numero di vulnerabilità insito nei suoi software di oltre il 50%, migliorando notevolmente la sicurezza e l’efficienza e diventando il modello per lo sviluppo del software di molte aziende in tutto il mondo.

In ZTE, lo High Performance Product Development (HPPD) è un processo comunemente adottato nel campo della R&S. Dopo anni di sviluppo, l’azienda ha integrato le migliori best-practises di Application Security e incorporato misure di controllo della sicurezza in varie fasi all’interno dell’HPPD e ha formulato il suo standard tecnico per applicare il concetto di progettazione sicura, aumentandone notevolmente l’efficienza.

Il Cybersecurity Act dell’UE del 2019 afferma che la sicurezza dovrebbe essere garantita per tutta la durata dei prodotti e servizi ICT per progettazione e processi di sviluppo che evolvono costantemente. Il GSMA NESAS (Network Equipment Security Assurance Scheme) stabilisce requisiti di sicurezza per lo sviluppo del prodotto e l’intero ciclo di vita, rendendolo una best practice per integrare la sicurezza nei processi di sviluppo e nel ciclo di vita delle apparecchiature di comunicazione.

Per questo motivo, il processo HPPD-2017 ha superato l’audit GSMA NESAS e lo Schema di Certificazione di Cybersecurity BSI NESAS – Implementazione Tedesca (NESAS CCS-GI).

Strumenti Sviluppati Internamente orientati al Testing di TelcoSec: ZSniffer

In merito a quanto affermato nei paragrafi precedenti riguardo l’importanza di avere strumenti automatizzati a supporto del Secure SDLC e del processo SecDevOps, possiamo brevemente menzionare un esempio pratico: lo Zsniffer. Una piattaforma di fuzzing sviluppata internamente dai laboratori ZTE, utilizzata per testare la sicurezza e la robustezza dei sistemi software, con un focus particolare sui protocolli di rete “esotici” quali 5GNR, BLE, WIFI, NFC, etc. che lo rendono particolarmente efficiente nel rilevare vulnerabilità relative al mondo delle telecomunicazioni.

Zsniffer ha svolto un ruolo importante nel colmare le lacune dei prodotti commerciali e nel fornire risorse innovative per i test di sicurezza, in particolare dando supporto per alcuni argomenti specifici: fuzzing di Web API, protocolli wireless & wired, business logic, 5G NR e NFC.

Tips & Tricks per le PMI Italiane

Arrivati a questo punto dell’articolo, dovrebbe essere chiaro al lettore che garantire la sicurezza dei prodotti richiede sforzi erculei ed esperienza pregressa. In breve, risorse.

Queste risorse non possono essere le stesse tra diversi attori, specialmente provenienti da diverse realtà industriali. Una domanda legittima sarebbe: “Come può una Piccola-Media Impresa Italiana far fronte a tale richiesta di risorse? Quali opzioni ha per migliorare?”

La risposta non è univoca, tuttavia proviamo ad approssimare alcuni punti che potrebbero fungere da innesco. Qui di seguito vengono forniti una serie di suggerimenti fattibili, scalabili e convenienti dal punto di vista del budget che potrebbero aiutare le PMI nella loro missione.

Rete di Security Champions

Una strategia consigliata, che ho personalmente implementato per anni mentre ricoprivo il ruolo di Responsabile della Sicurezza dei Prodotti per diverse aziende, è quella di implementare un concetto creato negli USA e promosso “dalle Grandi Aziende” del settore IT (come Microsoft): il cosiddetto “Security Champion”.

Chi è? E cosa fa?

Il Security Champion è la figura, all’interno di un team di sviluppo, che ha acquisito le necessarie competenze tecniche di sicurezza ed è in grado di agire come:

• Braccio destro e Punto di Contatto del Team di Sicurezza.
• Portavoce interno per le problematiche di sicurezza che il dev team potrebbe riscontrare, in grado di aiutare i diversi membri del team a migliorare la loro postura di sicurezza e quindi creare prodotti intrinsecamente piu affidabili.

A questo punto, una domanda legittima che il lettore potrebbe porsi è: “Come implementare tale idea, mantenendo i costi contenuti?”

• Ecco un esempio pratico: Si seleziona un membro di ogni singolo team di sviluppo
• Questo viene trasferito per due/quattro settimane presso il Team di Sicurezza, CyberLab, SOC, etc. (i.e. un gruppo composto da esperti di sicurezza).
• In questo contesto, all’individuo vengono forniti una serie di corsi di base relativi alla sicurezza delle applicazioni e, possibilmente, seguiti da esercizi pratici.
• Una volta completata la fase di formazione (i.e. in cui all’individuo viene insegnato che la sicurezza deve essere applicata in ogni fase del Ciclo di Vita di un prodotto), esso viene ricollocato nel team di appartenza.
• L’individuo riprende quindi le sue attività abituali, ma con una consapevolezza e conoscenza migliore delle possibili minacce che possono influenzare il codice del prodotto stesso e con una cultura più orientata alla sicurezza rispetto alla situazione iniziale.

Per concludere, il concetto di Security Champion può migliorare significativamente la postura di sicurezza dei prodotti delle PMI integrando direttamente competenze di sicurezza all’interno dei team di sviluppo.

Questo approccio garantisce una continua attenzione alla sicurezza durante il processo di sviluppo, portando all’identificazione e mitigazione precoce delle potenziali vulnerabilità. Inoltre, i Security Champions facilitano una comunicazione efficace tra sviluppatori e il team di sicurezza, promuovendo una cultura di sicurezza proattiva che si allinea strettamente con gli obiettivi e le pratiche di sicurezza dell’azienda.

Threat Modeling

Un’altro processo, fortemente raccomandato alle PMI, è il Threat Modeling. Esso può essere facilmente avviato con risorse limitate ed è scalabile.

Di cosa si tratta e quali benefici apporterebbe?

Il Threat Modeling è un approccio strutturato utilizzato nella sicurezza delle applicazioni per identificare, valutare e affrontare potenziali minacce alla sicurezza di un’applicazione software. Comprende l’analisi sistematica del design e dell’ambiente operativo di un’applicazione per anticipare e dare priorità a potenziali vulnerabilità o vettori di attacco.

La modellazione delle minacce, come la conosciamo ora, si è evoluta nel tempo come parte delle pratiche di gestione del rischio nella sicurezza delle informazioni e delle applicazioni. La sua formalizzazione specifica per la sicurezza del software ha iniziato a guadagnare rilevanza a cavallo tra fine anni 90 e primi del 2000. Uno dei primi framework fu STRIDE, sviluppato da due ignegneri della Microsoft: Loren Kohnfelder e Praerit Garg. Esso è presto diventato fondamentale per comprendere e categorizzare le minacce alla sicurezza nelle applicazioni software. A riguardo, si consiglia di consultare le seguenti risorse [2] [3]

I benefici del Threat Modeling sono molteplici: in generale, permette alle organizzazioni di identificare e dare priorità sistematicamente alle potenziali minacce relative ai loro prodotti. Questo approccio proattivo aiuta a comprendere la superficie di attacco, i profili dei potenziali aggressorie le aree più critiche ove effettuare maggiori controlli di sicurezza.

La sua implementazione da parte delle PMI dovrebbe iniziare fin dalla fase iniziale di progettazione del prodotto. Queste possono utilizzare approcci strutturati come STRIDE o PASTA per identificare le minacce. Sessioni regolari che coinvolgono team interfunzionali aiutano a garantire che, man mano che il prodotto si evolve, il Threat Model sia aggiornato per riflettere nuove funzionalità e potenziali vulnerabilità. Per una comprensione più approfondita delle sigle menzionate, si consiglia al lettore di consultare la seguente risorsa [4].

Scansione Automatizzata di Sicurezza all’interno della CD/CI Pipeline

Come menzionato nei paragrafi precedenti, includere la Sicurezza nei processi DevOps è un fattore chiave. In pratica, ciò può essere tradotto (tra gli altri modi) nell’implementazione di strumenti di scansione di sicurezza automatizzati all’interno delle CD/CI pipelines delle PMI che consentano il rilevamento precoce delle vulnerabilità. In questo modo la sicurezza non è una fase separata o finale, ma viene integrata in tutto il ciclo di vita dello sviluppo del software.

Nello specifico, le aziende dovrebbero integrare strumenti come il testing di sicurezza delle applicazioni statiche (SAST), il testing di sicurezza delle applicazioni dinamiche (DAST) e gli strumenti di scansione del Software-Bill-Of-Material (SBOM),attivando così scansioni automatizzate in punti chiave del ciclo di sviluppo.

Questo approccio proattivo riduce il potenziale per interruzioni significative e compromissioni che possono verificarsi quando le vulnerabilità vengono sfruttate. Inoltre, l’automazione porta coerenza e ripetibilità al processo di sicurezza, riducendo il potenziale di errore umano e aumentando l’efficienza complessiva.

Per un’azienda che sviluppa prodotti, specialmente in settori dove la sicurezza è fondamentale come i servizi finanziari, la sanità o le telecomunicazioni, la scansione di sicurezza automatizzata può salvaguardare non solo i dati e la proprietà intellettuale dell’azienda, ma anche quelli dei loro clienti.

Vulnerability Patch Management

Come già menzionato descrivendo le differenze tra gli exploit 0-day e n-day, un robusto processo di Vulnerability Patch Management è cruciale per mantenere l’integrità e la sicurezza dei prodotti software. Esso, riduce la finestra di esposizione agli attacchi assicurando l’applicazione tempestiva delle patch di sicurezza, proteggendo così contro le vulnerabilità note.

Nello specifico, le PMI dovrebbero implementare una strategia di gestione delle patch che includa una routine di monitoraggio delle nuove patch rilasciate dai vari vendors, un approccio di valutazione basato sul rischio per dare priorità alle attività di patching ed un sistema di distribuzione automatizzato per distribuire e applicare le patch. Inoltre, mantenere un inventario di tutti gli asset e dei loro attuali livelli di patch è fondamentale per una gestione efficace.

Coordinated Vulnerability Disclosure

Infine, una volta adottati i vari spunti elencati nei paragrafi precedenti e confermato che la postura di sicurezza sia capace di sostenere i ritmi dello sviluppo dell’azienda, si raccomanda l’implementazione di un processo di CVD (Coordinated Vulnerability Disclosure) al fine di ricevere, catalogare ed integrare tempestivamente eventuali vulnerabilità scoperte da clienti e/o ricercatori di sicurezza.

I benefici dell’implementazione del processo di CVD sono comprovati. Esso fornisce un percorso chiaro su come segnalare potenziali vulnerabilità, migliorando non solo la sicurezza dei prodotti, ma anche la fiducia dei clienti e della comunità di ricercatori e bug-hunters.

Le PMI dovrebbero creare e pubblicare linee guida di divulgazione delle vulnerabilità (CVD Rules & Scope), impostare un sistema di segnalazione sicuro (i.e. PGP) e stabilire un team di risposta (i.e. PSIRT – Product Security Incident Response Team). Nel mentre, al lorointerno, le aziende dovrebbero fornire linee guida su come vengono gestite le vulnerabilità segnalate, chi è responsabile per ogni parte del processo e comunicare le aspettative riguardo le tempistiche e la divulgazione alla parte che segnala (i.e. ricercatore o bug-hunter).

Conclusioni

Garantire la sicurezza dei prodotti non è banale e comporta molteplici sfide. Come menzionato da Bruce Schneier nel suo articolo, la chiave di volta è minimizzare i rischi e assicurarsi che la sicurezza sia considerata in ogni fase del ciclo di vita del prodotto.

I suggerimenti forniti in questo articolo potrebbero essere considerati onerosi, ma se approcciati nel modo giusto e con la mentalità divide-et-impera adeguata, risultano fattibili in una prospettiva a medio/lungo termine.

Ad esempio, già implementando la “Rete di Security Champions” e il processo “Threat Modeling” si potrrebbero evitare molti problemi postumi.

Certo è che tutti gli spunti visti risultano difficilmente implementabili in mancanza di personale di cybersecurity adeguatamente formato. Uno studio condotto da Cybersecurity Ventures ha evidenziato che entro il 2025 ci saranno 3.500.000 posti di lavoro vacanti nel campo della cybersecurity [5].

Affrontare questa problematica risulta quindi imprescindibile, in quanto il divario e la carenza di competenze nel settore rappresentano un ostacolo per lo sviluppo economico e per la sicurezza nazionale.

Negli ultimi anni dei passi avanti in questa direzione sono stati fatti: al fine di fornire alcuni spunti su come identificare, trattenere e formare il personale di cybersecurity, l’ENISA ha creato due opuscoli molto interessanti: l’European Cybersecurity Skills Framework (ECSF) [6], pubblicato nel settembre 2022, e l’European Cybersecurity Skills Framework Role Profiles’s User Manual [7].

L’ECSF è il risultato dello sforzo congiunto dell’ENISA e di un gruppo di lavoro ad hoc, formato da 17 esperti provenienti da 14 stati membri ed è importante nella costruzione di competenze specifiche per la cybersecurity. L’obiettivo del framework è quello di creare una cultura specifica sull’argomento e gettare le basi per la formazione e il riconoscimento di 12 diverse professioni nel campo della cybersecurity, di cui specifica gli obiettivi, i compiti, le competenze e le certificazioniI ruoli identificati sono: Chief Information Security Officer (CISO), Cyber Incident Responder. Cyber Legal, Policy and Compliance Officer, Cyber Threat Intelligence Specialist, Cybersecurity Architect, Cybersecurity Auditor, Cybersecurity Educator, Cybersecurity Implementer, Cybersecurity Researcher, Cybersecurity Risk Manager, Digital Forensics Investigator e Penetration Tester.

Il Manuale Utente dell’ECSF, fornisce orientamenti ed esempi pratici su come sfruttare il Framework e trarne vantaggio per reclutare persone nel campo della cybersecurity o per formare personale o individui interessati a lavorare nel settore. Questo manuale utente include 7 casi d’uso: 3 delle principali associazioni che forniscono certificazioni in cybersecurity ((ISC)², ISACA, SANS), uno dell’Istituto Nazionale di Cybersecurity Spagnolo (INCIBE), uno dell’Organizzazione Europea di Cybersecurity (ECSO) e 2 progetti di ricerca europei (Concordia e Sparta).

Note

[1] https://intelligence.weforum.org/topics/a1Gb00000015LbsEAE

[2] https://owasp.org/www-community/Threat_Modeling

[3] Threat Modeling: Designing for Security, Adam Shostack, Wiley, 2014

[4] https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html

[5] https://cybersecurityventures.com/jobs/

[6] https://www.enisa.europa.eu/publications/european-cybersecurity-skills-framework-ecsf

[7] https://www.enisa.europa.eu/publications/european-cybersecurity-skills-framework-role-profiles

Scarica la versione completa del White Paper ZTE Cybersecurity.

Articolo a cura di Luca Bongiorni

https://www.ictsecuritymagazine.com/articoli/no-secure-sdlc-no-party-perche-e-fondamentale-implementare-la-sicurezza-in-ogni-fase-del-ciclo-di-vita-del-prodotto/

Per comprendere come difendersi da potenziali attacchi malevoli è necessario studiare come questi avvengano. Per fare ciò, esistono diversi modelli, tra questi uno dei più noti ed utilizzati è quello della “Cyber Kill Chain” ideato da Lockheed Martin nel 2011.

Questo modello descrive in sette fasi, si veda la figura 2, come un attaccante può compromettere un determinato target e di contro anche come identificare e prevenire potenziali attività malevole:

1. Reconnaissance: consiste nella raccolta di informazioni tramite tecniche di social engineering e/o OSINT per identificare e selezionare l’obiettivo. Questa fase può avvenire in due modalità:

• • Passiva: analisi e raccolta di informazioni tramite l’uso di siti web, annunci, Google, Shodan e simili.
  • Attiva: tramite l’uso di tool per effettuare scansioni dirette sul target (verifica delle porte aperte con i relativi servizi esposti e molto altro). Tra i tool più noti va sicuramente citato Nmap.

L’obiettivo di questa fase è trovare delle vulnerabilità che, potenzialmente, consentiranno agli attaccanti di entrare nella rete. Di contro la cyber defense dovrà occuparsi di mitigare e ridurre la superficie d’attacco utilizzabile dagli attaccanti.

2. Weaponization: trovata una vulnerabilità, gli attaccanti creano o cercano un exploit che consenta di sfruttarla. In questa fase vengono anche individuati possibili malware a supporto dell’attacco. Spesso per guadagnare l’accesso ad un sistema, vengono sfruttati anche gli zero day o vulnerabilità note ma non ancora “patchate” dagli amministratori del sistema.
3. Delivery: consiste nella trasmissione dell’exploit individuato all’obiettivo, di seguito alcuni esempi di come potrà essere consegnato:

• • Compromissione di un servizio esposto;
  • Invio di una mail malevola all’indirizzo della vittima;
  • Campagne di Social Engineering;
  • Chiavetta USB lasciata nei pressi dell’azienda, ad esempio nel parcheggio;
  • Compromissione di siti web terzi, abitualmente visitati dai dipendenti dell’azienda target (tramite l’uso, ad esempio, di attacchi di cross-site scripting (XSS)).

In questa fase, nella cyber defense, è fondamentale adottare un sistema di monitoraggio che consenta di individuare potenziali attività malevole e quindi strutturare un perimetro difensivo che comprenda almeno: firewall perimetrali, IDS/IPS, secure mail gateway, SIEM e un security operation center (SOC) per la gestione dei molteplici alert che verranno generati.

4. Exploitation: consiste nello sfruttamento di una o più vulnerabilità da parte dei malware introdotti nel sistema sotto attacco. Tendenzialmente si fa uso anche di tecniche di obfuscation per rendere queste azioni totalmente invisibili ai sistemi difensivi precedentemente elencati.
5. Installation: ottenuto l’accesso al sistema gli attaccanti cercheranno di mantenerlo tentando di installare ulteriori malware e backdoors che gli consentiranno successivamente di propagarsi nella rete e di accedere, tramite movimenti laterali, ad utenze con maggior privilegio.
6. Command and Control (C2 o C&C): in questa fase si tenta di stabilire una comunicazione stabile e duratura con l’obiettivo di utilizzare la macchina infetta. In questa fase un APT consentirà ad esempio di:
   • Esfiltrare informazioni sensibili;
   • Infettare altre macchine;
   • Effettuare “privilege escalation” su macchine amministrative;

In queste ultime due fasi, il monitoraggio delle attività sospette lato cyber defense è fondamentale. È molto importante in questo caso, ad esempio, avere sistemi come UEBA (User and entity behavior analytics) e regole di GPO (Group Policy Objects) che consentano di individuare comportamenti anomali e accessi non autorizzati.

7. Actions on objectives: in quest’ultima fase avverrà il vero e proprio attacco al sistema; Questo varierà in base al tipo di attaccante e alle sue motivazioni, ad esempio:
   • Finanziarie;
   • Politiche;
   • Militari;

L’attaccante avrà accesso a informazioni confidenziali e potrà interrompere servizi e/o avere capacità di bloccare l’ordinaria operatività.

In ogni fase del modello, come visto, è possibile individuare delle azioni per mitigare e quindi interrompere la catena d’attacco. Esistono diverse varianti al modello illustrato ma il cui obiettivo è sempre lo stesso; ovvero comprendere il modus operandi dell’attaccante allo scopo di moderare i rischi e quindi “rompere la catena” al fine di interrompere e/o mitigare la minaccia. Questo modello, infine, è anche utilizzato per comprendere al meglio le TTPs (Tecniche, tattiche e procedure) di un determinato “Threat actors” e/o “Malware”. Come visto, la consegna di un malware può avvenire tramite un’email malevola durante la fase di delivery.

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

https://www.ictsecuritymagazine.com/articoli/email-security-cyber-kill-chain-come-modello-di-difesa/