In tanti si domandano se esiste un chiaro ritorno di investimento nella cyber security: molti affermano di sì, perché in caso di attacco informatico c’è perdita di immagine e perché i danni per ogni dato rubato possono essere anche di milioni di euro, ma la verità è no per tre motivi:
- Internet è stata creata per condividere informazioni, per accelerare le transazioni, per connettere, ma non è stata pensata per essere sicura. Ricordo che inizialmente, quando abbiamo cominciato a usare internet, accedere ad un computer da un’altra parte del mondo era considerato un successo, oggi le chiamiamo botnet. Oggi parliamo di security by design, ma ricordo architetture create per facilitare la connessione e la condivisione e la sicurezza non era sicuramente al centro.
- Chi attacca fa questo mestiere, chi riceve l’attacco normalmente fa un altro mestiere. Un po’ come Leonida con gli Ateniesi, quando domanda loro quale fosse il loro mestiere: “Voi siete avvocati, medici, vasai, invece dall’altra parte ci sono quelli specializzati, il cui mestiere è quello di affrontarvi”. Già questo potrebbe bastare, ma non è l’unico problema.
- Ne abbiamo un altro, di problema, ancor più grande: l’impossibilità di conoscere quando si viene attaccati. Saremo attaccati. Chi attacca, infatti, decide quando attaccare; chi si difende non sa quando verrà attaccato.
È una triste consapevolezza ma si tratta di una guerra impari. L’investimento è essenziale ma la quantità dello stesso non è proporzionale al risultato. Pertanto, non esiste un chiaro ritorno di investimento ma l’essenziale è lavorare per ridurre il rischio e le conseguenze.
Da dove partire per priorità?
- La IT è nata per ottimizzare e nell’ottimizzazione il ritorno di investimento è fondamentale. Non è facile chiedere a coloro i quali sono abituati a fare investimenti in funzione di ROI di farli per «prevenire» senza una certezza di un possibile danno e senza un chiaro ritorno. Prendiamo ad esempio un ospedale. Nel contesto ospedaliero sarebbe meglio investire in un defibrillatore che salva la vita oggi o è meglio investire in micro-segmentazione che presumibilmente salverà una vita domani? È una domanda complessa, ma dalla risposta semplice: si investe solo in presenza di un incidente.
- Assumendo che si decida di investire in sicurezza, quanto si deve investire? Non essendoci un ritorno di investimento che ci aiuti a quantificare, non è possibile deciderne il quantum. Spesso, pertanto, più che per proteggersi dai criminali, si investe per evitare di violare direttive e regolamentazioni.
Ricordiamo che la “cyber security è l’arte di decider dove spendere un centesimo minimizzando la possibilità di essere vittima di un incidente conseguente ad un attacco informatico”.
Cyber security: le migliori quattro tecnologie che funzionano contro il cyber crime
Indice degli argomenti
Un battito d’ali in Brasile può provocare un tornado in Texas
Volgendo lo sguardo al mondo e al rapporto che questo ha con la cyber security, ci piace citare una nota frase: un battito d’ali in Brasile può provocare un tornado in Texas?. Edward Lorenz, nel 1963, lo ha anche dimostrato aggiungendo “La teoria del caos”.
Ora, però, ragioniamoci. Affinché questo accada devono verificarsi molte condizioni, altrimenti il Texas sarebbe devastato continuamente dai tornado a prescindere dal cambiamento climatico. Cosa c’entra questo con la definizione di cyber security? Proviamo a cambiare un attimo questa affermazione: una telecamera di videosorveglianza compromessa in Brasile, può provocare un disastro in Texas?.
Cosa impariamo dal caso Mirai
Immaginiamo di avere un malware che consiste in una botnet e che, installato sulle telecamere di videosorveglianza, venga utilizzato per sferrare attacchi di tipo DDoS (Distributed Denial of Service): significa che l’attaccante potrebbe utilizzare queste telecamere come sorgenti di transazioni indirizzate contemporaneamente verso un DNS rendendolo inutilizzabile. E, se non funziona il DNS, una parte di internet non funziona più, perlomeno la internet che noi conosciamo.
Ovviamente questo è un fatto accaduto: il malware si chiama Mirai, le telecamere non erano in Brasile ma in Canada e il DNS serviva un’importante applicazione comunemente usata per mandare messaggi.
Perché gli attaccanti hanno scelto le telecamere? Semplice, ci sono tante telecamere tutte uguali distribuite sul territorio e spesso installate senza protocollo di autenticazione o talvolta lasciate con la password predefinita dell’installatore.
Internet non è fatto per essere un luogo sicuro. Molti fanno riferimento a Mirai per dimostrare che l’IoT non è sicuro. Ma questo lo sappiamo già. La novità è un’altra.
La cyber security è un bene dal valore intrinseco
La novità è che dopo Mirai abbiamo compreso che non possiamo più fare investimenti sulla cyber security in funzione del valore dell’asset o valore del servizio. Che valore ha la telecamera di videosorveglianza? Che valore ha il servizio che una telecamera offre? Ma se non si protegge una telecamera, un DNS in Texas può essere compromesso. Questo vuol dire “bene dal valore intrinseco” e ha un impatto non solo economico, ma giuridico ed etico.
Ad esempio, per il trattato di Ginevra un esercito non può fare azioni militari contro un civile, ma se a casa mia una telecamera di videosorveglianza viene compromessa cosa succede se da questa telecamera si attacca un altro Stato?
Estremizzando, potremmo pensare che se qualcuno dovesse impossessarsi della telecamera di casa correremmo il rischio di essere considerati non più civili ma militari impegnati nei combattimenti con tutte le conseguenze del caso.
Ecco perché i governi si preoccupano sempre di più che aziende e istituzioni implementino controlli di sicurezza a prescindere dal valore dell’asset e del servizio.
Bisogna preoccuparsi anche di direttive e regolamentazioni
I responsabili della sicurezza devono preoccuparsi non solo di non soccombere agli attaccanti, ma anche di rispettare le leggi. Come principio tutto sommato sarebbe anche ragionevole. Il problema è che la tecnologia corre più velocemente di quanto i legislatori e le istituzioni facciano direttive e regolamentazioni.
Ad esempio, il GDPR è stato pensato nel 2016 per regolare i temi della privacy ma è entrato in vigore nel 2018. In questo lungo arco temporale i contesti sono cambiati e le problematiche aumentano.
L’IoT è solo materia di governance?
La gestione dei dispostivi IoT introduce problemi di governance, ma anche di segmentazione e di gestione degli eventi con le tecnologie esistenti.
Infatti, costringe chi considerava l’IT come una “comodity” a preoccuparsi di gestire, con le stesse pratiche di sicurezza che sono presenti all’interno di Data Center, numerosi dispositivi connessi che forniscono servizi essenziali e che possono essere attaccati come si può attaccare un Data Center.
Senza dimenticare che la stragrande maggioranza dei dispositivi IoT si trova nelle mani dei cittadini comuni (come Smart TV o stampanti). Insomma, per questi ultimi non si può parlare di governance, si deve parlare di certificazione dei dispositivi.
Non è pensabile che si dia a una persona comune uno strumento che poi, se collegato alla insicura internet, possa compromettere la sicurezza di uno stato; ne è pensabile che una persona comune conosca pratiche avanzate di sicurezza.
Va bene la consapevolezza, ma non si può pretendere che tutti sappiano di micro-segmentazione esattamente come si può pretendere che chiunque sappia cosa fare quando ci si taglia con un ferro arrugginito (questo è consapevolezza), ma non si può pretendere che chiunque sappia operare a cuore aperto (questa è competenza).
Se la cyber security è pertanto un bene dal valore intrinseco, dobbiamo salvaguardare l’ecosistema introducendo certificazioni per i dispositivi IoT. Non è possibile inquinare il mare, l’aria, ma neanche l’ecosistema digitale con oggetti intelligenti che vengono buttati su internet.
Esiste la cyber security per tutte le industrie?
Abbandoniamo solo per un attimo la questione dei dispositivi IoT – ma solo per un attimo, vedrete che ci torneremo in quanto l’IoT è la cybersecurity del presente e non del futuro – e poniamoci un problema. Il problema è che spesso consideriamo la cybersecurity come una scienza trasversale a tutte le industrie.
Anzi, a seguito della digitalizzazione dei processi industriali tendiamo a trasferire in ambienti industriali processi tipici dell’IT con un sillogismo del tipo “se in un Data Center abbiamo dei processi per gestire una serie di server interconnessi, gli stessi processi possono essere usati dovunque ci siano intelligenze collegate, che sia uno smart building o un impianto industriale”.
Spesso questa translazione funziona, ma non nella cyber security. Chiaro che qualcosa può essere traslata, ma solo qualcosa. Il motivo è che in cybersecurity non esiste un ROI definito (torniamo sempre qui), non è possibile dire “fai questo e stai tranquillo”. Dobbiamo lavorare sulla riduzione del rischio.
Nascosto dietro questa considerazione c’è un piccolo tranello, una piccola tentazione. La tentazione è di fare qualcosa di inutile in quanto nella eventualità che succeda qualcosa c’è una validissima giustificazione: “non si poteva prevedere”.
Dobbiamo focalizzarci su azioni concrete, che portano sicuramente benefici. Poi si può andare oltre, ma si deve partire da cose concrete. E quali sono le cose concrete?
Abbiamo già parlato della competenza e determinazione degli attaccanti, ma gli attaccanti spesso sono pigri. Perché creare attacchi nuovi e sofisticati, quando si può avere successo nell’attacco utilizzando vulnerabilità o metodologie di attacco conosciute?
Ne consegue la necessità di avere Threat Intelligence specifica per l’industria. Se bisogna decidere come ridurre il rischio e quanto spendere, la prima cosa che dobbiamo chiederci è “quali sono gli attacchi ed incidenti conosciuti in quest’area geografica?”, “quali in quest’area geografica ed in questa industria?”.
Analizziamo un caso specifico: la sanità.
Il fenomeno del cyber crime in sanità pesa nella prima parte dell’anno tra il 10% ed il 5% del fenomeno complessivo. Non trascurabile, ma si parlerebbe di cybercrime anche se la sanità fosse immune al problema. Senza essere distruttivi, a guardare le statistiche, se un direttore sanitario deve decidere se investire in un defibrillatore per salvare una vita o avere un firewall di ultima generazione, immagino che decida di spendere il suo budget in defibrillatori.
L’industria che maggiormente è influenzata dal fenomeno è quella del mercato finanziario, da sempre il target preferito dei criminali. Se nella IT, infatti, dalla macchina di Turing in poi, molte delle innovazioni sono state introdotte nella industria militare, nel mondo del cybercrime e cybersecurity le più grandi innovazioni provengono dal mondo finanziario. Si pensi ad esempio a Zeus, il malware il cui codice sorgente è stato reso pubblico cambiando sensibilmente l’approccio da parte di chi doveva identificare i malware.
Concludiamo con le tecniche di attacco. Se scompare la sanità, il cyber crime continua ad esserci ma, se scompare il phishing, probabilmente sarebbe difficile parlare di cyber crime nella sanità, e non solo.
Se eliminiamo dalla sanità attacchi che hanno successo grazie al phishing e che sfruttano vulnerabilità conosciute, resta poco. Per cui, è vero che dobbiamo preoccuparci di proteggere i dati delle cartelle cliniche, che negli ospedali spesso manca il CISO, ma se a ottobre del 2022 bisogna decidere dove spendere un centesimo all’interno di un ospedale, lo spenderei su un corso di consapevolezza e a seguire su strumenti che verificano le vulnerabilità dei sistemi, incluso i dispositivi IoT.
Il tema caldo delle certificazioni per i dispositivi IoT
Torniamo a trattare il tema della certificazione dei dispositivi che potrebbe ridurre sensibilmente anche i problemi in sanità lasciando al direttore sanitario la necessità di investire solo in consapevolezza.
D’altra parte, se si decide di fare una passeggiata a Londra, per evitare di finire in ospedale per un incidente vale la pena di studiare le regole basiche della circolazione (si circola a sinistra) oppure è meglio indossare un elmetto militare perché è possibile che cada una anguria in testa.
Certo, tutto è possibile, ma cosa è probabile?
Se invece si decide di fare la passeggiata su un territorio di guerra, la scelta cambia. La decisione di cosa fare per mitigare il rischio è funzione della conoscenza del territorio.
Ovviamente non si tratta solo di conoscere l’industria per comprendere da cosa doversi proteggere. È necessario conoscere l’industria anche in termini di processi ed architetture.
Se in ferrovia esiste un dogma che suggerisce di fermare il treno se qualcosa va male, chiaro che non si può utilizzare lo stesso dogma anche sugli aerei.
Se una catena di montaggio è governata tramite un protocollo estremamente delicato, non è possibile suggerire attività di VAPT (Vulnerabiity Assessment e Penetration Test) così come lo si farebbe in un Data Center dove è possibile fare le attività in ambienti di test.
Sanità italiana sotto attacco cyber: ecco come reagire all’emergenza
Chi sono i ragazzi cattivi
Finora ho parlato di attaccanti, spesso si usa il termine hacker e l’hacker viene identificato come una persona cattiva, spesso un ladro.
Però attenzione, la questione è molto più complessa. Faccio un esempio.
Stuxnet è un attacco che si dice sia stato progettato da alcuni Stati per compromettere il programma nucleare di un altro Stato. Chi è il cattivo? In genere, siamo portati a considerare “cattivi” quelli che sono a noi più lontani, a prescindere dal fatto che uno sia il vero «hacker» e l’altro la vittima.
Un altro esempio. Tutti sappiamo quanto i droni possano essere utili, per portare medicine, per fare sopraluoghi in posti pericolosi. Un «hacker» cattivo potrebbe danneggiare il servizio.
Ma cosa succederebbe se il drone entrasse in un aeroporto per lanciare delle bombe? In questo caso voglio pensare che qualcuno sia in grado di attaccare il drone per evitare che il drone entri nel perimetro di un aeroporto.
Anche il termine «malware» fa pensare a una cosa brutta, una specie di malattia. Non sarete sorpresi di apprendere che il malware non è illegale di per sé in nessun paese al mondo. Sarebbe curioso infatti scoprire che diventa illegale programmare. Possiamo rendere illegali sequenze di «if then else»?
Concludo che non solo gli strumenti e i ruoli utilizzati negli attacchi di per sé non sono né buoni o cattivi ma dipendono da chi e come vengono usati, ma scopriamo che spesso sono gli stessi.
Anzi, è importantissimo conoscerli. Infatti, nella logica di assenza di ROI verificata e verificabile, la tentazione di investire o proporre qualcosa di inutile è sempre dietro l’angolo.
Senza nulla togliere all’innovazione, quanto proposto e innovativo non può prescindere dalla conoscenza di cosa esiste già, usato in difesa, ma soprattutto usato efficacemente in attacco.
Ovviamente la conoscenza di controlli, processi e organizzazioni di sicurezza richiede grandissima preparazione ed ha un costo, ma non si può prescindere da questa conoscenza se si vuole usare al meglio quel famoso centesimo di investimento.
Stuxnet: un attacco interno o esterno?
Abbiamo appena parlato di Stuxnet. È passato alla storia per aver dimostrato che un ambiente, malgrado chiuso e non collegato con l’esterno come quello di una centrale nucleare, può essere attaccato.
Da quel momento sono finiti sotto accusa i sistemi SCADA (“Supervisory Control And Data Acquisition”), sistemi dove unità di controllo collegate a sensori e attuatori sono utilizzati per le operazioni industriali (catene di montaggio, turbine di raffreddamento delle centrali nucleari).
In passato i sistemi SCADA utilizzavano sistemi operativi proprietari per HMI (Human Management Interface) e protocolli proprietari per la connessione. In realtà, gli attaccanti in Stuxnet hanno sfruttato quattro vulnerabilità su un sistema di comune utilizzo. Bisognerebbe dunque chiedersi cosa ci facesse un sistema di comune utilizzo all’interno di un sistema SCADA.
Con il passare degli anni competenze e tecnologie per sistemi proprietari si sono ridotte a favore di una maggiore consumabilità di tali sistemi.
Per cui gli HMI sono stati installati su sistemi operativi di comune utilizzo mentre i protocolli di comunicazione tra PLC (“programmable logic controller”) e sensori e attuatori sono finiti su reti IP, quindi internet.
Pertanto, a finire sotto accusa sono i sistemi SCADA tradizionali, ma in realtà l’attacco ha potuto avere successo grazie a vulnerabilità su sistemi operativi comuni.
Altra questione è relativa a come un ambiente chiuso sia stato compromesso. In questo caso sembra che la distanza tra un ambiente chiuso e un ambiente aperto fosse una chiavetta USB lasciata nel parcheggio o in un bar vicino alla centrale. Da quel momento oltre che i sistemi SCADA sono finiti sotto accusa anche le chiavette USB e il dipendente che ha portato la chiavetta all’interno, definito infedele o incapace a seconda dei casi.
In verità, Stuxnet dovrebbe passare alla storia anche per un’altra ragione. Seppure molti hanno criminalizzato il dipendente coinvolto, la verità è che ad oggi non è possibile classificare l’incidente come interno o esterno. Se infatti nella centrale esistevano delle policies di sicurezza che proibivano di introdurre la chiavetta all’interno della centrale, allora il dipendente in maniera consapevole o inconsapevole ha fatto qualcosa che non doveva essere fatto e quindi l’attacco può essere classificato come interno. C’è stato un dipendente che ha veicolato l’attacco.
Se invece questa policy non c’era, l’attaccante ha sfruttato una vulnerabilità di processo oltre alle quattro di software. Parliamo del 2009/2010: quante società avevano policies di sicurezza in materia a quel tempo?
Ne consegue quindi che su Stuxnet, di cui si pensa di sapere tutto, si scopre di sapere ancora poco. Passato alla storia per dimostrare che i sistemi SCADA possono essere attaccati, si scopre che ad essere sfruttate sono vulnerabilità su sistemi di comune utilizzo.
Gli attaccanti e gli attaccati non hanno mai dichiarato di aver ricevuto o fatto l’attacco e adesso scopriamo di non sapere neanche se fu un attacco esterno o interno.
La minaccia delle vulnerabilità zero-day
In Stuxnet furono sfruttate quattro vulnerabilità su sistemi di comune utilizzo non conosciute. Se una vulnerabilità non è conosciuta viene chiamata zero-day. In cyber security spesso si parla di zero-day ma la verità è che gli attacchi hanno successo spesso per vulnerabilità conosciute. Infatti, se una vulnerabilità non è conosciuta, allora a meno che l’attaccante non abbia deciso di comprometterci in qualche modo (Advanced Persistent Threat – ATP) e investire tempo e denaro per scoprirla, allora sarà difficile che altri la scoprano.
Ma se invece la vulnerabilità è conosciuta e pubblicata su CVE (Common Vulnerabilities and Exposure) allora tutti sanno che chi è affetto da questa vulnerabilità, si possono trovare strumenti che sfruttano questa vulnerabilità o addirittura con un processo di reverse engineering si potrebbe individuare come sfruttare la vulnerabilità a partire dalla patch che la risolve (quando esiste).
Attenzione, però: non sempre a fronte di una vulnerabilità esiste una patch e non sempre è possibile installare la patch (si pensi ai sistemi industriali ad esempio). In genere, infatti, le pratiche di service management suggeriscono di provare una patch in ambiente di test e poi pianificare un cambio o una nuova release in produzione. Ovviamente queste attività richiedono tempo e durante questo periodo si resta esposti all’attaccante.
Condividere o meno vulnerabilità è sempre una questione su cui si discute e ha vantaggi e svantaggi più o meno come la decisione di richiedere un brevetto per una invenzione o mantenere il segreto industriale. In ogni caso i responsabili della sicurezza devono prevedere la possibilità di sopravvivere con vulnerabilità che sono conosciute.
L’importanza dei controlli di sicurezza
Le metodologie di attacco vanno conosciute tutte prima di suggerire una cura e questo non è facile in un ecosistema in cui gli attaccanti sono persone estremamente preparate e costringono chi si difende ad esserlo altrettanto.
Questa conoscenza richiede un enorme sforzo e continuo aggiornamento ma è necessario focalizzarsi su pratiche consolidate per evitare di cadere nella tentazione di essere troppo innovativo e produrre attività e servizi non realmente funzionali o proporre solo quello che si conosce.
Esistono diversi framework che descrivono best practice (pratiche provate che funzionano) e che dividono le attività in cinque macro aree: identify, protect, detect, respond and restore.
Cos’è una kill chain
Se un processo di sicurezza è l’insieme di controlli di sicurezza che orchestrati tra di loro producono un risultato consistente, la kill chain è l’insieme di attività che sono necessarie affinché un attacco abbia successo.
Si va dalla pianificazione di un attacco, identificazione della vittima, sviluppo degli strumenti, distribuzione del malware (quando coinvolto), gestione tramite botnet utilizzate per Command & Control fino alla valorizzazione dell’attacco.
Parliamo di organizzazioni estremamente sofisticate che non sono stigmatizzabili semplicemente con la iconografia di un ragazzo con il cappuccio. Parliamo di organizzazioni che si accordano sull’utilizzo delle botnet, che si scambiano i tool di exploit (ad esempio il tool di exploit di WannaCry, Eternal blue, è stato utilizzato anche da altri malware) e che sono in grado di gestire transazioni finanziarie estremamente complesse con le criptovalute.
