Continuano gli aggiornamenti su Stuxnet che, come dicevo, secondo me rimarrà nella storia del malware come uno di quelli che hanno cambiato la prospettiva sul problema malware. Le considerazioni che vorrei mettere in evidenza sono due. La prima, di cui purtroppo non ricordo la fonte, è che sembra probabile che chi ha scritto Stuxnet e chi lo ha utilizzato (quasi certamente) per attaccare gli impianti di arricchimento iraniani, siano due “gruppi” diversi. La considerazione nasce dalla professionalità con cui è stato realizzato Stuxnet, compresa la presenza di tre 0-day e la difficoltà nello scrivere codice per sistemi SCADA, e dalla “disattenzione” da parte di chi lo ha utilizzato, che invece ha fatto sì che finisse su Internet, portando allo scoperto l’operazione e soprattutto bruciando le 0-day. Per quanto siamo ancora nel campo delle ipotesi, mi sembra un ragionamento credibile. Il corollario, che differisce un po’ dalle mie prime considerazioni, e che riporto perché mi trova d’accordo, è che ci siano organizzazioni che hanno a disposizione un arsenale di competenze, risorse, strumenti e di vulnerabilità 0-day, che usano per attività “coperte”, anche svolte da altre organizzazioni “amiche”: in questo caso di sabotaggio, in altri probabilmente di spionaggio, probabilmente anche industriale a supporto delle proprie aziende. Vorrei sottolineare questo ultimo punto, ovvero lo spionaggio industriale, su cui tornerò dopo. Il secondo riferimento invece l’ho ancora, ed è questo articolo di Symantec, in cui si descrive come Stuxnet sia pensato per attaccare impianti con delle specifiche caratteristiche. Per capire il problema, bisogna entrare nella logica dei sistemi SCADA. La facilità con cui si scrivono worm per i computer general purpose è che più o meno tutti funzionano allo stesso modo, e possiamo dare molte cose per scontate. Ad esempio, se mi connetto alla porta tcp/80 di un server su Internet, quasi certamente ci troverò un server Web, con il quale comunico secondo uno specifico protocollo standard; quando questo mi comunica che supporta una certa versione di php, ho tutta un’altra serie di “cose note” su cui lavorare, e ancora di più se ad esempio dalle pagine che mi restituisce si capisce che c’è, che so, WordPress. I sistemi SCADA non sono così: se è vero che i sistemi di supervisione sono essenzialmente macchine standard, normalmente Windows, e che il protocollo che utilizzano per gestire la componente SCADA sono a loro volta standard (sebbene non IP), la rete SCADA di fatto è composta principalmente da sensori e attuatori (e componenti che hanno lo stesso ruolo di un router/switch). Per farla breve, un sensore manda valori numerici al sistema di supervisione, un attuatore riceve valori numerici dal sistema di supervisione e di conseguenza “fa qualcosa”: aziona un relè o qualcosa del genere. Il punto importante è che i sensori che leggono la temperatura di una stanza, o la percentuale di una sostanza chimica in un camino, o il numero di rotazioni di un motore, si presentano al sistema di controllo allo stesso modo: sensori che mandano numeri. Lo stesso per gli attuatori: indirizzi a cui mandare numeri È solo chi conosce l’impianto che sa che un sensore corrisponde a una temperatura e l’altro alle rotazioni, e quali numeri corrispondano a cosa, e di conseguenza scrive i programmi che, in funzione dei numeri che arrivano da certi sensori, manda altri numeri agli attuatori. Senza sapere esattamente com’è l’impianto, intervenire sulla rete SCADA vuole dire fare cose a caso: si potrebbe avviare e fermare un motore come anche accendere o spegnere una luce. È per questo che si dice che chi ha scritto Stuxnet per attaccare gli impianti iraniani li doveva già conoscere. Naturalmente, attacando le reti SCADA si potrebbe fare anche altro, ad esempio farsi inviare dal sistema di supervisione il programma di gestione dell’impianto, che spesso comprende delle iconcine o delle stringhe molto esplicative, che permetterebbero di conoscere l’impianto e il processo industriale molto nel dettaglio, ma sarebbe spionaggio e non sabotaggio, e non è questo che fa Stuxnet.
Ora, il motivo per cui continuo a insistere su Stuxnet è che ne dobbiamo dedurre che organizzazioni con competenze e risorse stanno già scrivendo codice mirato, comprensivo di 0-day, allo scopo di fare sabotaggio o spionaggio industriale attraverso i sistemi informativi. In questi tempi di crisi, mi aspetto che lo spionaggio industriale, anche supportato dai governi o da organizzazioni “vicine” sia particolarmente di tutti (quelli capaci) contro tutti, salvo forse europei contro europei, e quindi non dobbiamo farci troppe illusioni.
Il punto importante è che ci sono gli 0-day di mezzo. Come ci si protegge? È chiaro che tutta l’importanza che viene data ai bug software, alle patch e a quest’area del pen-testing, per quanto una base necessaria, non è di grande aiuto contro un avversario che dispone di 0-day. In questo caso l’unica possibilità è una robustezza “architetturale”, sia di codice che di sistemi, che è quella che la security ha sempre richiesto e che invece è così poco gradita a chi vorrebbe realizzare sistemi senza questo tipo di vincoli (limitandosi a un po’ di patch management e antivirus dopo). Solo un’architettura robusta può fare sì che un singolo 0-day non permetta di aggirare tutte le protezioni. Su come proteggersi da 4 0-day si può discutere, naturalmente 😉
Se questi non sono discorsi che devono necessariamente interessare la maggior parte delle reti e delle organizzazioni, per le quali portarsi a un livello medio di sicurezza sarebbe già un buon passo, per reti, organizzazioni e impianti più critici il discorso è diverso. E qui si innesta la ricerca che stiamo facendo al Dipartimento di Informatica di Pisa. Si tratta di un’evoluzione di quanto stavamo già studiando da anni in questo campo, anche in ambito SCADA, ovvero come valutare la capacità di sistemi complessi di resistere ad attacchi portati da minacce con diverse capacità in termini di risorse, competenze ecc. Quello che stiamo aggiungendo adesso è una valutazione probabilistica della presenza delle vulnerabilità: non so quale sia la vulnerabilità, ma c’è una certa probabilità che un certo componente del mio sistema sia vulnerabile, o lo diventi entro l’anno. Il problema come sempre non si può affrontare con i tipici strumenti come la Fault Tree Analysis, perché qui abbiamo una componente intelligente che non si muove a caso sul sistema, ma segue una logica di massimo profitto. Quali sono le conseguenze sul mio sistema? È possibile che una minaccia con determinate risorse raggiunga un certo obiettivo, e in quanto tempo? Più o meno di quanto ci metto io ad applicare una patch? E soprattutto, a prescindere dal patch management, dove posso intervenire sul mio sistema per ridurre questi impatti? Cosa succede se aumento la robustezza di questo o quel componente, è un investimento efficace? Tutte domande che saranno sempre più fondamentali e alle quali, anche grazie ad un simulatore su cui stiamo lavorando, contiamo di trovare risposte interessanti 😉
