top space  top space  top space  top space  top space       Visualizza il sito in italiano Visualizza il sito in inglese

I cinque miti della sicurezza SCADA


“If they’re so important, why aren’t they built with something to protect them?” – SCADA and me, di Robert M. Lee

 

I sistemi di controllo industriale (“Industrial Control Systems” o “ICS”, comunemente noti anche con la denominazione “SCADA”) sono parte integrante della società moderna. Essi costituiscono un importante strumento di gestione dei processi che regolano il funzionamento delle infrastrutture critiche per la vita quotidiana (energia, trasporti, telecomunicazioni, salute pubblica, etc.). Per questo motivo, gli incidenti riguardanti le piattaforme SCADA possono avere un impatto catastrofico su differenti settori della società, causando perdite economiche significative e mettendo potenzialmente in pericolo anche la vita umana.

 

Nonostante il ruolo fondamentale rivestito dai sistemi di controllo industriale, diversi fattori contribuiscono a renderli particolarmente insicuri ed esposti ad attacchi. Tra di essi, il principale è la mancanza di consapevolezza delle peculiarità degli ICS, purtroppo molto diffusa anche tra gli addetti ai lavori. Rispetto alla loro controparte IT, infatti, i sistemi di controllo industriale presentano:

 

  • Differenti requisiti in termini di performance, affidabilità e longevità
  • Differenti architetture, sistemi operativi e applicazioni
  • Differenti obiettivi di sicurezza e gestione del rischio

 

SCADA 1

I controlli di sicurezza applicati agli ICS devono pertanto essere progettati tenendo conto delle loro specifiche caratteristiche e delle eventuali incompatibilità con i paradigmi comunemente accettati per l’IT. In particolare, l’obiettivo fondamentale della sicurezza IT è la protezione del dato, mentre nel caso degli ICS è la protezione del processo. Ciò si traduce nel passaggio in secondo piano del requisito di riservatezza, sostituito da quelli di disponibilità e integrità, che vengono considerati particolarmente importanti in ambito SCADA.

 

L’attuale condizione di scarsa maturità della sicurezza degli ICS è evidenziata dall’esistenza di luoghi comuni e veri e propri miti, che inevitabilmente si incontrano lavorando in questo settore. Di seguito analizzeremo brevemente i cinque principali miti della sicurezza SCADA.

 

  1. “La nostra rete SCADA è completamente separata da Internet”

 

Il cosiddetto “mito dell’air gap” è un tema ricorrente nei dibattiti sulla sicurezza dei sistemi di controllo industriale. In realtà, le reti a cui sono attestati gli ICS non sono mai del tutto isolate: oltre alle interconnessioni (che spesso comprendono ambienti di sviluppo e collaudo, reti IT anche di terze parti, connessioni wireless di vario tipo, GPS per la sincronizzazione dell’ora, VPN per la gestione remota e modem per la comunicazione con gli apparati di campo), la distribuzione geografica di molte infrastrutture SCADA determina la creazione di punti di accesso non adeguatamente presidiati alla rete di processo (si pensi ad esempio ai contatori elettrici intelligenti esposti a manomissione da parte degli utenti). Inoltre, i famigerati malware Stuxnet e Flame hanno recentemente dimostrato come non esista un vero e proprio perimetro da proteggere e di conseguenza sia possibile infiltrarsi in una rete tramite canali alternativi (es. notebook e altri dispositivi mobili, dischi USB, etc.). Infine, a prescindere dall’efficacia della separazione con le altre reti, la rete di processo è spesso “piatta”: al suo interno convivono diversi sistemi ed ambienti, che pur presentando differenti livelli di criticità non sono adeguatamente segmentati l’uno dall’altro.

 

Per affrontare queste problematiche è necessario effettuare un censimento di tutti i punti di accesso alla rete SCADA e delle relazioni di fiducia in essa presenti, da utilizzare come base per implementare adeguate misure di sicurezza procedurali, tecnologiche e fisiche, sia a livello di perimetro che all’interno della stessa rete di processo (applicando il noto paradigma della “defense in depth”). In particolare dovranno essere garantiti il controllo degli accessi, la tracciabilità delle operazioni ed il monitoraggio delle anomalie.


 

  1. “Utilizziamo protocolli proprietari, perciò siamo al riparo dagli attacchi”

 

A quanto pare, il mito della “security through obscurity” resiste ancora nel terzo millennio. Purtroppo, però, i protocolli di comunicazione oscuri e le interfacce proprietarie offrono ben poco in termini di sicurezza reale: nella maggior parte dei casi tali protocolli sono intrinsecamente insicuri e non sono in grado di garantire gli standard di protezione richiesti, in particolare in termini di integrità ed autenticità dei dati trasmessi. Di conseguenza, i sistemi di controllo industriale risultano particolarmente fragili e vulnerabili agli attacchi informatici. Inoltre, al fine di contenere i costi, i produttori di software e apparati SCADA stanno gradualmente migrando le proprie piattaforme verso tecnologie comuni e sistemi operativi “general purpose” come Windows e Linux. Questa tendenza fa sì che i moderni ICS siano affetti dalle medesime vulnerabilità delle loro controparti IT, oltre che da quelle specifiche degli ambienti SCADA.

 

La soluzione di queste problematiche non è immediata, poiché richiede il coinvolgimento dei produttori delle piattaforme SCADA. Tali piattaforme sono spesso basate su architetture applicative obsolete e risultano vulnerabili ad attacchi noti, quali buffer overflow, command injection, directory traversal, etc. In alcuni casi, sono state addirittura scoperte delle backdoor all’interno del codice, presumibilmente inserite dagli stessi sviluppatori. La storia si ripete e la sicurezza SCADA è oggi al livello della sicurezza IT degli anni ‘90. Tuttavia, negli ultimi anni si sta assistendo ad un considerevole aumento di attenzione verso gli ICS da parte di ricercatori, produttori e legislatori, che ha portato allo sviluppo di strumenti di sicurezza, conformità e condivisione delle informazioni sempre più efficaci (NIST Cybersecurity Framework, RIPE Framework, ICS-CERT, SCADASEC, etc.), grazie ai quali possiamo sperare di non ripetere gli errori commessi in passato.

 

  1. “Dobbiamo garantire un accesso rapido in caso di emergenza, quindi non possiamo usare autenticazione forte”

 

Poiché gli ICS devono essere raggiungibili tempestivamente in caso di emergenza, di norma i meccanismi di controllo degli accessi adottati per la loro protezione sono carenti: le credenziali amministrative non nominali, condivise, di default o altrimenti prevedibili, riutilizzate su differenti sistemi e memorizzate in modo insicuro sono ampiamente diffuse. Inoltre, è spesso possibile aggirare i meccanismi di autorizzazione (ad esempio al fine di accedere a funzionalità bloccate sulle interfacce HMI) e interagire con gli apparati di campo (PLC, RTU, etc.) senza autenticarsi. Queste carenze determinano l’esposizione dei sistemi di controllo industriale ad accessi non autorizzati, impedendo di fatto il tracciamento delle operazioni eseguite dagli utenti locali e soprattutto remoti.

 

In realtà, oltre a garantire una protezione superiore, molte soluzioni di strong authentication (quali ad esempio i meccanismi di autenticazione basati su token o i sistemi di identificazione biometrica, entrambi integrabili con i sistemi di controllo degli accessi fisici) consentono un accesso rapido. A fianco di tali soluzioni è inoltre opportuno introdurre controlli addizionali sugli accessi remoti, specialmente se effettuati da terze parti (es. limitazioni di orario, approvazione degli accessi delegata ad un presidio locale, monitoraggio, etc.), oltre a sistemi di rilevamento delle intrusioni (IDS) dedicati collegati con un Security Operations Center (SOC) operativo 24/7.

 

  1. “Non abbiamo bisogno di cifratura, perché i dati degli ICS non sono riservati”

 

Come abbiamo già spiegato, negli ambienti SCADA il requisito di riservatezza è tipicamente considerato come secondario. Tuttavia, la protezione di alcune informazioni confidenziali, quali ad esempio le credenziali di accesso, rimane comunque critica ai fini della sicurezza. Una vulnerabilità che consente ad un agente di minaccia di ottenere un accesso amministrativo non autorizzato ad un ICS, infatti, determina anche la compromissione dell’integrità e della disponibilità del sistema stesso e, potenzialmente, di tutta l’infrastruttura SCADA di cui esso fa parte. E’ inoltre opportuno ricordare che i meccanismi di cifratura consentono di garantire l’integrità e l’autenticità dei dati su cui si fondano i processi di business e l’incolumità dei cittadini.

 

Occorre pertanto mettere in campo adeguati strumenti di protezione dei dati memorizzati sui sistemi o in transito sulla rete (es. TLS/SSL, PKI), che siano in grado di prevenire gli attacchi Man In The Middle (MITM) ed il furto di informazioni critiche ai fini della sicurezza dell’infrastruttura SCADA, garantendo il rispetto dei requisiti di riservatezza ed integrità.

 

  1. “Non applichiamo patch e non facciamo Penetration Test perché potrebbero impattare sulla disponibilità degli ICS”

 

Nuove vulnerabilità applicabili alle piattaforme SCADA vengono scoperte (e risolte) quasi ogni giorno. Ciò nonostante, le patch di sicurezza vengono raramente applicate in modo tempestivo o non vengono applicate affatto. Una volta installati, spesso gli ICS non sono sottoposti ad hardening e non vengono aggiornati. Le motivazioni sono molteplici: i loro requisiti in termini di affidabilità, longevità, disponibilità e isolamento non sono compatibili con aggiornamenti continui; alcuni apparati di campo non sono immediatamente aggiornabili da chi li gestisce; in alcuni casi, infine, gli stessi produttori di piattaforme SCADA non ne garantiscono il funzionamento in caso di modifiche apportate al sistema operativo o al software applicativo a supporto. Per motivi analoghi, si preferisce non condurre attività di verifica di tipo Vulnerability Assessment e Penetration Test, considerate potenzialmente pericolose per la disponibilità dei sistemi di controllo industriale.

 

SCADA 2

Pur basandosi su osservazioni valide, queste problematiche sono spesso risolvibili. Esse possono essere affrontate predisponendo un ambiente di collaudo il più possibile allineato a quello di produzione (requisito peraltro fondamentale per l’instaurazione di un processo di change management efficace), sul quale sia possibile effettuare agevolmente operazioni delicate come il test delle patch e le verifiche di sicurezza. A tale scopo, potrebbe essere utilizzato anche l’ambiente di Disaster Recovery, spesso presente all’interno di infrastrutture critiche. Vista l’attuale inadeguatezza degli strumenti di scansione automatica, è inoltre altamente consigliabile avvalersi di personale specializzato in grado di condurre analisi di sicurezza approfondite sin dalla fase di progettazione, replicando in modo controllato le eventuali vulnerabilità architetturali, procedurali, progettuali o implementative rilevate in ambiente di collaudo anche su quello di produzione, senza comprometterne l’operatività.

 

Dalla nostra analisi emerge un fatto importante: come nel caso dell’IT, la sicurezza SCADA è in primis una questione culturale. Molto deve essere fatto per cambiare la cultura dell’intera industria, promuovendo in particolare la consapevolezza, la comunicazione e la coordinazione, al fine di integrare la sicurezza nei processi di business e tutelare al meglio la vita degli esseri umani. Le regole fondamentali per innalzare il livello di sicurezza non cambiano, ma come avviene per ogni ambiente complesso è necessario come primo passo comprenderne a fondo il funzionamento e le specificità, per poi ragionare ed agire di conseguenza.

 

 

GLOSSARIO

 

Apparati di campo: dispositivi che fungono da interfaccia tra le piattaforme SCADA e il mondo fisico. Le tipologie più comuni di apparati di campo sono PLC (Programmable Logic Controller) e RTU (Remote Terminal Unit).

Hardening: processo tramite il quale si intende mettere in sicurezza un sistema, riducendone la superficie attaccabile.

HMI (Human Machine Interface): interfaccia di monitoraggio e controllo utilizzata dagli operatori SCADA.

ICS (Industrial Control Systems): sistemi di controllo utilizzati nel settore industriale e nelle infrastrutture critiche (cfr. SCADA).

MITM (Man In The Middle): attacco informatico volto ad intercettare una comunicazione di rete.

PKI (Public Key Infrastructure): infrastruttura IT per la gestione di certificati digitali.

SCADA (Supervisory Control And Data Acquisition): un tipo particolare di ICS dedicato al monitoraggio ed al controllo dei processi industriali su larga scala.

SOC (Security Operations Center): unità di controllo centralizzata per la gestione della sicurezza.

Rete di processo: rete dedicata al controllo dei processi industriali, alla quale sono attestati tutte le componenti di un’infrastruttura SCADA (HMI, apparati di campo, etc.).

TLS/SSL (Transport Layer Security / Secure Socket Layer): protocolli crittografici progettati per realizzare comunicazioni sicure attraverso reti insicure (es. Internet).

 

 

Le immagini sono tratte dal libro “SCADA and me” di Robert M. Lee, edito da IT Harvest Press.

 

21/10/2013 - Marco Ivaldi, Security Advisory Team @ Mediaservice.net