LA SECURITY NEI SISTEMI DI MONITORAGGIO E CONTROLLO

Transcript

1 INFRASTRUTTURE CRITICHE STEFANO PANZIERI, socio fondatore AIIC Dip. Informatica e Automazione Università degli Studi Roma Tre ENZO M. TIEGHI, socio AIIC Amministratore Delegato di Vision Automation s.r.l. LA SECURITY NEI SISTEMI DI MONITORAGGIO E CONTROLLO Un mondo diverso È opinione comune che l esperto di security sia una figura con delle caratteristiche e una preparazione tecnica abbastanza omogenee e consolidate. Dopo tutto, si tratta di essere esperti di sistemi anti-intrusione (IDS e IPS), e di conoscere bene cosa vuol dire una policy e come sia possibile implementarla con un router o, meglio ancora, con un firewall. È bene conoscere alcune vulnerabilità del protocollo per reti informatiche più diffuso al mondo, il TCP/IP, ma è meglio sapere anche quali sono le pecche dei sistemi operativi che più diffusamente sono utilizzati. Ebbene, tutte queste cose sono molto importanti, ma non salveranno un impianto da uno stop imprevisto causato, ad esempio, da un worm informatico che si sia annidato nello strato dei sistemi di supervisione e controllo, e nemmeno da un attacco diretto ad una struttura informatica che, sempre per esempio, gestisce la distribuzione di un servizio vitale come può essere un acquedotto. Potrebbero non fermarli, perché c è qualcosa di differente nei sistemi informatici impiegati in un impianto industriale, o di una grande rete di distribuzione, che a volte rendono difficilmente applicabili, per lo meno in maniera diretta, le normali tecniche di protezione di un tradizionale sistema IT. Diciamolo subito, questa differenza è saltata agli occhi solo da qualche anno. Prima degli eventi del 9/11 il mondo dormiva sonni tranquilli, pensando che i sistemi di controllo industriale, più spesso indicati con la sigla SCADA (Supervisory Control and Data Acquisition), fossero esenti da certi mali dei normali sistemi IT. La security, troppo spesso associata solo alla protezione dei dati e da sempre suddivisa in confidenzialità, integrità e di- 12 Safety&Security lug-ago 2007

2 sponibilità, veniva affrontata mettendo all ultimo posto il concetto legato alla fornitura del servizio. La confidenzialità (stretta parente della privacy e quindi normata in tutto il mondo) veniva vista come un punto da difendere di primaria importanza. Con i lavori del comitato ISA SP99 ( si è intanto rimessa a posto questa scala di valori, e la disponibilità è diventata prioritaria nella difesa dei sistemi informatici industriali. Passo importante, perché cambia l atteggiamento degli esperti di security dalla base: il funzionamento dell impianto, la cui safety è strettamente collegata alla buona salute dei sistemi di controllo, è al primo posto e pazienza se qualche dato viene perso o sottratto. Non dimentichiamo, infatti, che la Functional Safety (IEC 61508) si poggia sul concetto di SIS (Safety Integrity System) che è un apparato di controllo, sempre più spesso un architettura informatica, attraverso il quale il rischio viene riportato sotto la soglia di accettabilità. Ma le differenze tra un sistema IT e un sistema SCADA non si fermano certo qui. Oltre ai rischi, che come abbiamo visto sono decisamente differenti, e alla alta disponibilità che necessariamente caratterizza i sistemi SCADA, dobbiamo tener presente che la stessa architettura di rete, e i protocolli che troviamo su di essa, sono estremamente differenti. È normale, infatti, che un sistema di supervisione utilizzi dei bus per dialogare con la periferia dell impianto che rispondono a delle esigenze di impiantistica e di controllo particolari. Citiamo solo alcuni dei fattori che rendono un bus di campo (fieldbus) diverso: il determinismo, ovvero la certezza che i dati critici possano raggiungere il sistema di supervisione con un tempo di latenza massimo noto a priori, e il rapporto di payload, che definisce la percentuale di dato utile di una trama rispetto alla dimensione di tutto il pacchetto. Vediamo subito che Ethernet e il protocollo TCP/IP mal si adattano a queste esigenze, che sono quelle di trasferire con un tempo di ciclo inferiore ai È opinione comune che l'esperto di security sia una figura con delle caratteristiche e una preparazione tecnica abbastanza omogenee e consolidate. Dopo tutto, si tratta di essere esperti di sistemi anti-intrusione (IDS e IPS), e di conoscere bene cosa vuol dire una policy e come sia possibile implementarla con un router o, meglio ancora, con un firewall. 10 ms una serie di pacchetti, composti spesso da pochi byte, e prodotti da un elevato numero di sensori e attuatori. A causa di questa stringente necessità di temporizzazione, i bus di campo, che troviamo ai livelli 0, 1 e 2 dell architettura ISA 95, sono semplificati (con molti livelli della pila ISO/OSI svuotati), ben arbitrati, e rafforzati nella loro affidabilità. Solo per citare i più diffusi potremmo elencare Profibus, Modbus, Device- Net, Foundation Filedbus e CAN, sconosciuti ai più ma molto noti agli addetti al settore. Su questi bus si affacciano sistemi di controllo dedicati. Parliamo di PLC, DCS, HMI, CNC, DNC, che sono le sigle che maggiormente rappresentano il mondo dell automazione e del controllo di processo. Questi apparati hanno sistemi operativi propri, spesso poco noti, e architetture che premiano l efficienza e l affidabilità rispetto alla semplicità d uso. E nel 99% dei casi non contemplano l impiego di trasmissioni criptate o l autenticazione dei client. D altro canto, in una rete di campo, non è sempre chiaro quale apparato sia il client e quale il server, potendosi questi due ruoli invertire o mescolare di volta in volta. Una cosa è certa: le risorse sono sempre limitate, e calcolate per espletare al minimo il compito previsto. Non solo, aggiornare uno di questi sistemi può essere complesso quando si tratta di un sistema critico, operativo 365 giorni all anno, 24 ore su 24. Alcuni dei problemi registrati in passato sono collegabili ad aggiornamenti (patch) andati non proprio a buon fine, con effetti secondari scarsamente prevedibili. Quest ultimo fattore, poi, è uno dei più importanti: non è possibile prevedere con esattezza l esito di una modifica così come l esito di un malfunzionamento. La salute e l integrità delle persone, il rischio ambientale e i danni sull asset, devono essere, in quest ordine, elementi primari di valutazione prima di qualsiasi intervento. Ricapitolando, ai livelli più bassi abbiamo a che fare con architetture proprietarie o standard industriali che erano, fino a qualche anno fa, architetture sconosciute, note solo ai tecnici del fornitore e, soprattutto, fuori del mirino dei cracker. Se però andiamo a vedere le statistiche del BCIT (British Columbia Institute of Technology [BCIT]), il quale mantiene un database (Industrial Security Incident Database, ISID [SYMANTEC]) con gli attacchi informatici noti verso installazioni industriali, ci accorgiamo che questo non è più vero e anzi, con una inversione di tendenza, dal 2002 gli impianti di questo tipo raccolgono diversi attacchi. La differenza, che era un punto di forza e che ha fatto vivere tranquilli gli stakeholder per anni senza costringerli a installare particolari contromisure (spesso assenti tuttora!), oggi diventa una vulnerabilità: architetture e protocolli vengono studiati e i cracker possono avere gioco facile. Che questo aspetto abbia una rilevanza notevole è dimostrato anche dal fatto che sin dal 1997 sia stato preso nella necessaria considerazione da una Commissione statunitense [PCCPI] che propose una com- lug-ago 2007 Safety&Security 13

3 plessa strategia mirata a proteggere l integrità delle infrastrutture critiche da attacchi fisici e provenienti dal cyberspace, nonché ad assicurare la continuità dei servizi erogati. Altri documenti, poi, sia statunitensi [NIPP], sia della recente EU [COM576], hanno puntualizzato questo pericolo e portato alla ribalta il problema, legandolo anche alla questione più ampia della protezione delle infrastrutture critiche. Soprattutto però, come si diceva all inizio, i fatti del 9/11 hanno fatto scoprire agli hacker di tutto il mondo, l esistenza di questi sistemi. Ai livelli superiori L architettura non è ancora completa. Se facciamo riferimento alla struttura definita dallo standard ISA S95, ci accorgiamo che esistono anche un livello 3 e un livello 4, i quali contemplano altri sistemi collegati tra di loro da altre reti. In particolare, il livello 3 è quello dei sistemi di supervisione e coordinamento della produzione o anche, se pensiamo a un sistema geograficamente distribuito, il livello al quale avviene la gestione unificata dei vari sottosistemi di controllo (ad esempio delle RTU, Remote Terminal Unit, che controllano localmente la rete di distribuzione dell acqua di una città). A questo livello si collocano apparati informatici basati su sistemi operativi piuttosto standard, semplicemente riconvertiti al controllo di processo tramite un hardening purtroppo spesso fatto in maniera non adeguata. Ricordiamo che OPC (OLE for Process Control) è uno standard per le comunicazioni client-server tra apparati di una rete di processo, basato sul meccanismo OLE e DCOM (appunto) della Microsoft. Al livello 3, sopra ai sistemi SCADA, i software più diffusi sono i MES (Manufacturing Execution Sistem) dotati di varie HMI (Human Machine Interface), a volte collegati anche ai LIMS (Laboratory Information Management System). Il livello 4 non è da meno. Qui troviamo i software di ERP (Enterprise Resource Planning) dedicati alla gestione globale dell azienda dal finanziario alla logistica, non di rado in grado di abbracciare anche il livello 3 quando si presentano in forme particolarmente integrate. E chiaro, insomma, che i dati dell impianto devono essere messi a disposizione anche dei livelli più alti, non fosse altro per consentire ai responsabili di disporre in ogni momento dei dati sulla produzione, o per permettere ai gestori di sapere quante scorte sono in magazzino o quali prodotti saranno ultimati nel mese successivo. Tutti questi sistemi, specie quelli dei livelli più alti, si possono considerare dei gestionali ma, al contrario di quelli che più tipicamente sono presenti nelle imprese di servizi, banche, assicurazioni o nella pubblica amministrazione, devono lavorare con dati di impianto e produzione, e sono responsabili della movimentazione di beni materiali e delle loro lavorazioni. Il problema che si evidenzia, in questo caso, è quello della necessaria intercomunicazione tra la rete per il controllo di processo (Process Control Network) e la rete aziendale (Enterprise Network). Il rischio principale, in una situazione del genere, è che, se un computer della EN viene compromesso, si mette a repentaglio anche la PCN. Le soluzioni di segregazione e segmentazione sino a questo momento adottate, mutuate dall IT tradizionale, prevedono l uso di Router e Firewall in grado di separare logicamente le due reti: a oggi non ci sono molti metodi di protezione di cui sia stata provata l efficacia sul campo da parte di gestori o sviluppatori di sistemi di controllo. La presenza di applicativi particolari in grado di memorizzare dati di impianto condivisi da tutti i livelli (Database ed Historian), e la necessità di utilizzare WLAN basate sui protocolli wireless , comporta la costituzione di zone demilitarizzate (DMZ), tramite uno o più firewall, la cui configurazione, come evidenziato da numerosi studi (vedi ad es. quello del BCIT ), deve tener presente le peculiarità dei protocolli coinvolti, spesso non tutti basati su IP. Non solo, una configurazione con diverse VLAN può prevenire la propagazione del traffico indesiderato su tutta la rete e anche accessi non controllati dall interno e da remoto [NISCC]. Ripetiamo, spesso i protocolli utilizzati a livello industriale hanno caratteristiche e necessità differenti dai normali protocolli di rete e le configurazioni di default dei vari apparati possono non essere efficaci, tanto meno quando sussistono anche necessità di traffic shaping, ovvero, la necessità di creare bande riservate 14 Safety&Security lug-ago 2007

4 per le applicazioni critiche, come ad esempio, quelle che coinvolgono le comunicazioni tra i PLC e i sistemi SCADA e DCS. Cosa non fare Abbiamo compreso, quindi, che le differenze tra la security dei sistemi IT e quella dei sistemi di supervisione e controllo sono molte, troppe, per essere trattate con le metodologie standard. Di conseguenza, gli errori che si commettono nell implementazione di una policy di sicurezza sono molteplici: vediamone almeno alcuni, quelli che portano alle vulnerabilità più comuni. Policy di sicurezza assenti. In qualche caso non esistono delle politiche di sicurezza chiare o, alle volte, pur esistendo, non sono seguite. Ricordiamo che la security è comunque un ciclo che comprende la valutazione del rischio, la progettazione e l implementazione di nuove contromisure in termini di policy e strumenti HW e SW, la loro convalida e, quindi, un nuova valutazione del rischio. Questo ciclo deve essere sempre attivo, pena la perdita di efficacia delle contromisure Poca consapevolezza sui problemi dell impianto. La cui prima ricaduta consiste nell utilizzo di contromisure standard quando ne servirebbero di più appropriate. Documentazione della rete non sempre disponibile e aggiornata. Naturalmente una documentazione accurata e una politica di gestione della configurazione sono di fondamentale importanza, insieme a dei piani di Business Continuity (possibilmente testati) e una politica chiara per la gestione della contingenza e delle ripartenze (Disaster Recovery). A tal proposito, vale l esperienza americana maturata durante gli uragani del 2005 (Katrina e le sue sorelle), durante la quale si sono posti molti problemi per far ripartire correttamente i sistemi di controllo dei vari impianti danneggiati. Un documento del Control Systems Security Center (CSSC, spiega molto bene come le configurazioni vadano annotate e controllate accuratamente, e come l HW e SW utilizzato debba essere validato sia dal punto di vista del firmware, sia da quello delle policy di sicurezza prima di essere installato. Scarsa separazione tra la rete di controllo e quella aziendale. Come detto in precedenza, questo è un errore che può portare facilmente alla compromissione e all esposizione degli apparati di controllo. Una segmentazione e segregazione non accurata è ancora uno degli errori più comuni. Tra l altro, il monitoraggio delle reti, cablate o wireless, dovrebbe essere un normale modo di procedere che, unito alla presenza di antimalaware e di sistemi anti intrusione che verifichino gli accessi remoti, porterebbe un enorme vantaggio in termini di security globale. Controllo degli accessi non sempre praticati. Questa è un altra vulnerabilità a cui facilmente ci si espone, spesso a causa di sistemi operativi datati o comunque mal configurati. Tra l altro, non essendo semplice mantenere aggiornate le Access Control List che indicano quali utenti/processi possono accedere a determinate risorse, spesso queste non vengono utilizzate correttamente. Si tratta, in generale, di problemi legati alla scarsa manutenzione dei sistemi. Mancata registrazione di eventuali incidenti. Questo è un errore molto comune, e lo si commette quando si pensa di utilizzare un IDS in maniera non supervisionata, cioè senza la presenza costante di un operatore. Quest ultimo, aiutandosi con una console opportuna, dovrebbe tener traccia di tutte le anomalie, registrarle e analizzarle, per poter prevenire future intrusioni aggiornando opportunamente l IDS. Utilizzo di sistemi consumer come componenti di rete. In realtà di dispositivi specificatamente progettati per l ambiente industriale non ce ne sono moltissimi, specie quando di parla di sicurezza. Certo è che quelli consumer, come detto anche in precedenza, hanno caratteristiche non sempre soddisfacenti. Non solo, un HW troppo noto a livello mondiale espone a minacce derivanti dalla buona conoscenza delle sue vulnerabilità. E cosa fare Oggi cosa fare è più semplice a dirsi di qualche anno fa. Fortunatamente sono disponibili una serie di documenti, alcuni diventati standard internazionali, che ci possono aiutare a implementare delle policy di sicurezza adatte ai sistemi di controllo industriale [CLUSIT]. Il primo documento che ha tentato di affrontare il problema è, forse, quello pubblicato nel 2001 [STEPS] dal DoE statunitense per la commissione presidenziale sulle infrastrutture critiche. Venivano proposti 21 semplici passi per migliorare la cyber-sicurezza dei sistemi SCADA. Le [GAMP4], nate in ambito farmaceutico, possiedono un appendice (Guide for Automated System Security) dove vengono descritte le misure da implementate per assicurarsi che sia i dati, sia il sistema automatizzato, siano adeguatamente protetti da incidenti dolosi o accidentali. In realtà, se ragioniamo ai livelli più elevati dello schema ISA S95, abbiamo delle norme come la ISO/IEC 17799:2005, ora inglobata nella ISO27000, standard internazionale di riferimento per certificare sistemi di sicurezza delle informazioni. Si tratta, di una norma ampia, da applicare in via volontaria, interpretando i requisiti e identificando contromisure in base ai rischi rilevati. Molto più adatta si presenta lo standard ISA s99: Manufacturing and Control System Security [ISA SP99], preceduto da due importanti technical report. Il primo [TR ] fornisce una valutazione delle tecnologie correnti di sicurezza elettronica e dei vari tool per l ambiente dei sistemi di controllo, includendo in questi lo sviluppo, l implementazione, l operatività e la manutenzione. In altre parole, il TR identifica e valuta le tecnologie correnti e come possono essere usate nei Sistemi di Controllo. Il secondo [TR ] riguarda l analisi di 16 Safety&Security lug-ago 2007

5 un framework per lo sviluppo di un programma di sicurezza elettronica e raccomanda una particolare organizzazione e struttura del piano di sicurezza. Il documento indica dettagliatamente quali elementi minimi includere e in che modo. Gli altri capitoli dello standard (ISA-s99) in corso di pubblicazione e affrontano argomenti come: Models, Definitions, and Terminology (s99.001) Establishing a Manufacturing and Control System Security Program (s99.002) Operating a Manufacturing and Control Systems Security Program (s99.003) Specific Security Requirements for Manufacturing and Control Systems (s99.004) Naturalmente gli standard possono aiutare la protezione dei sistemi SCADA in molti modi: contribuendo a stabilire una base concettuale comune tra tutti gli stakeholders (operatori, vendors, certificatori, autorità, etc.) e supportando i processi ingegneristici: dalla specifica all acquisto, dall operatività alla manutenzione. Si incoraggia, così, lo sviluppo di un mercato di prodotti e servizi per la sicurezza con livelli di affidabilità verificabili. Gli standard odierni, in effetti, raccolgono le best practice, i tool e i metodi già sperimentati con successo dalla comunità della security mondiale. Le metodologie e le tecnologie contenute in questi documenti sono già disponibili e applicabili, e i lavori dei vari comitati internazionali è volto principalmente al loro miglioramento e alla loro più ampia diffusione. Dopo averne tanto discusso negli ultimi anni è giunto il momento di passare ai fatti per aumentare veramente la resilienza degli impianti industriali. Oggi abbiamo buoni metodi e sistemi per identificare le anomalie e sono stati sviluppati ottimi piani per la gestione delle emergenze. Questi, insieme alla creazione di una figura di operatore che dovrà essere opportunamente addestrato affinché li faccia propri, contribuiranno a elevare il margine di sicurezza dando continuità al servizio e al business. Bibliografia [BCIT] E.J. Byres, and J. Lowe; The Myths and Facts behind Cyber Security Risks for Industrial Control Systems, VDE Congress, VDE Association For Electrical, Electronic & Information Technologies, Berlin, October, 2004 [PCCPI] Critical Foundation: Protecting America s Infrastructures. The President s Commission on Critical Infrastructure Protection (adesso NIAC National Infrastructure Protection Board, U.S. DHS), Washington, D.C., [COM576] Green Paper on a European Programme for Critical Infrastructure Protection, COM(2005) 576, Commissione Europea. [NIPP] National Infrastructure Protection Plan. U.S. Departemet of Homeland Security, [CLUSIT] Quaderno Clusit Introduzione alla protezione di reti e sistemi di controllo e automazione (DCS, SCADA, PLC, ecc.) di Enzo M. Tieghi Clusit, 2007 [STEPS] 21 Steps to Improve Cyber Security of SCADA Network. The President s Critical Infrastructure Protection Board & U.S. Department of Energy, [GAMP4] Good Automated Manufacturing Practice 4, ISPE - International Society for Pharmaceutical Engineering, [ISA SP99] Manufacturing and Control System Security committee. Instrument Society of America ( [TR ] Security Technologies for Manufacturing and Control Systems, ISA, [TR ] Integrating Electronic Security into the Manufacturing and Control Systems Environment, ISA, [NISCC] Good Practice Guide on Firewall Deployment for SCADA and Process Control Networks. Prepared for: National Infrastructure Security Co-ordination Centre (NISCC) By the: British Columbia Institute of Technology (BCIT), [SYMANTEC] Security Incidents and Trends in the SCADA and Process Industries (A statistical review of the Industrial Security Incident Database ISID), Symantec White Paper, Eric Byres, David Leversage, Nate Kube, lug-ago 2007 Safety&Security 17