SOC e sistemi ICS: quali componenti del sistema devono essere assolutamente collegati.

Redazione RHC : 6 Gennaio 2022 09:59

Autore: Andrey Proshin, responsabile del sistema di automazione Solar JSOC presso Rostelecom-Solar, Igor Semenchev, analista prevendita di Solar JSOC presso Rostelecom-Solar

Le imprese industriali sono sempre più prese di mira dagli attacchi informatici. Allo stesso tempo, le tecniche e gli strumenti utilizzati dai criminali informatici stanno diventando sempre più sofisticati.

Secondo Rostelecom-Solar, oltre il 90% degli attacchi di hacker altamente professionali sono diretti a strutture CII, tra cui gli attacchi più frequenti sono nel settore energetico, nell’industria, nel complesso militare-industriale e nel settore pubblico.

Una dinamica simile di minacce è stata espressa dai rappresentanti dell’NKTsKI al SOC Forum 2021: le principali industrie colpite da attacchi informatici sono il settore pubblico (21%), il complesso di combustibili ed energia (17%) e l’industria (14%).

Secondo la valutazione Claroty, sono state pubblicate nella prima metà del 2021, 637 vulnerabilità su prodotti hardware, mentre 76 su prodotti software.

Allo stesso tempo, il 61% di tutte le vulnerabilità era associato alle capacità di sfruttamento di codice da remoto e il 65% alla possibilità di una completa perdita di disponibilità (Disponibilità) del sistema.

I dati della BDU FSTEC confermano inoltre che un gran numero di carenze ed errori è legato proprio alla possibilità di operare in rete, il che, insieme alle difficoltà di installazione tempestiva degli aggiornamenti e all’utilizzo di workaround, rende le reti industriali vulnerabili a attacchi da parte di criminali informatici avanzati.

Lo sviluppo attivo del mercato RaaS (ransomware as a service) riguarda anche la sicurezza dei sistemi di controllo di processo. Secondo Rostelecom-Solar, nel 2020 il numero di attacchi ransomware è aumentato del 30% e la tendenza continua ancora oggi.

Quasi ogni settimana ci sono notizie su nuovi incidenti con ransomware sferrati in aziende con ICS.

Ad esempio, nel novembre 2021, ci sono stati attacchi alla società australiana CS Energy e alla Delta-Montrose Electric Association (DMEA). Quest’ultimo, a causa delle azioni degli hacker, ha perso tutti i suoi dati degli ultimi 25 anni.

In questo articolo, parleremo in dettaglio delle funzionalità di rilevamento degli incidenti in un sistema di ICS: di quali fonti di dati ed eventi abbiamo bisogno e quali funzionalità di connessione abbiamo riscontrato.

Descrizione di una tipica architettura ICS (modello Purdue)

Il principio fondamentale di qualsiasi addetto alla sicurezza è che non puoi proteggere ciò che non capisci. Pertanto, prima di introdurre la funzione di rilevamento degli incidenti in un sistema di controllo di processo automatizzato, è necessario analizzare in dettaglio come viene costruito un sistema o un’installazione specifica, da quali componenti è costituito e come funziona il processo tecnologico stesso.

Finora, il modello più rilevante che descrive l’architettura complessiva del sistema di controllo del processo è il modello Purdue:

In questa prospettiva, non si tiene conto dell’inizio dell’uso di ambienti cloud, dei requisiti per la separazione fisica di DCS ed ESD e altri punti, ma è molto adatto al nostro compito.

Il modello Purdue è costituito da diversi strati che rispecchiano la composizione della rete industriale:

• dispositivi fisici (sensori, sensori, attuatori),
• PLC (controllori a logica programmabile) e sistemi SCADA per il controllo di un gran numero di dispositivi fisici;
• Rete DMZ (server storici, controller di dominio, server di accesso remoto, ecc.);
• rete aziendale (sistemi di gestione della produzione, ERP e ogni altra infrastruttura, compreso l’accesso a Internet).

Ciascuno dei livelli ha le proprie caratteristiche, ad esempio, sistemi software e hardware specializzati, protocolli industriali sono spesso proprietari.

E, soprattutto, ci sono due requisiti importanti dal punto di vista del funzionamento di un sistema di controllo di processo automatizzato:

• non invasività, ovvero l’eliminazione dell’influenza degli strumenti di monitoraggio sulle prestazioni e sulla sicurezza funzionale del sistema di controllo di processo;
• mancanza di azioni di controllo, ovvero l’impossibilità di inviare un comando o influenzare software e dispositivi nella rete industriale.

In base alla struttura dell’ICS, gli attacchi a questo segmento (esiste persino una matrice MITRE separata) consistono in diverse fasi, che includono: penetrazione iniziale, escalation dei privilegi, distribuzione orizzontale, ricerca, preparazione di malware e danno.

Inoltre, anche criminali informatici con un livello medio di abilità possono compiere azioni di successo, come è stato dimostrato più di una volta al cyber-training del National Cyber-Polygon Russo.

Pertanto, prima in tutta la fase di sviluppo di un attacco, se il SOC è in grado di rilevarlo, maggiore è la possibilità di prevenire conseguenze fatali.

Quale apparecchiatura dovrebbe essere collegata al SOC e perché

Più sistemi colleghiamo al monitoraggio centralizzato, più facile sarà per gli analisti SOC rilevare un attacco e segnalarlo tempestivamente alla divisione aziendale competente (solitamente i dipartimenti di sicurezza delle informazioni e ICS).

Il monitoraggio completo richiede eventi di sicurezza delle informazioni dall’host e una copia del traffico.

Gli eventi IB dall’host sono necessari, poiché non tutte le azioni killchain possono essere rilevate nel traffico di rete: in primo luogo, a volte è crittografato; in secondo luogo, azioni come l’escalation dei privilegi, il dump dell’account, le modifiche alla configurazione del dispositivo possono essere definite solo a livello di nodo.

Ma allo stesso tempo, sfruttare le vulnerabilità della rete, inviare comandi illegittimi, ecc. può essere determinato solo con una copia del traffico.

Ciò significa che per prima cosa è necessario implementare un sistema di monitoraggio del traffico con supporto per i protocolli industriali.

Le difficoltà di attuazione possono sorgere in due fasi:

• Scelta dell’architettura di raccolta delle copie del traffico (SPAN). Come garantire le prestazioni richieste, come consegnare una copia del traffico all’IDS, come evitare la perdita di pacchetti e come calcolare correttamente il carico sull’IDS: questi problemi dovranno essere risolti;
• integrazione di IDS con il SOC stesso. Qui possono sorgere domande sul fatto che debba essere un sistema di monitoraggio separato, come integrarlo con un SIEM, come garantire “nessuna azione di controllo” sull’APCS.

La raccolta di eventi di sicurezza delle informazioni è potenzialmente interessante dai seguenti dispositivi e componenti ICS:

• PLC;
• controllori PAZ;
• hardware di rete;
• AWP e server a livello di sistema operativo;
• strumenti per la sicurezza delle informazioni (software antivirus, firewall, sistemi di controllo per utenti privilegiati, ecc.);
• software applicato (sistemi SCADA);

Parliamo in dettaglio di ciascuno dei componenti.

PLC ( controllori logici programmabili)

Insieme al software applicativo, questa è la parte più difficile, poiché ci sono molti produttori e versioni di firmware nelle reti tecnologiche.

Anche da un produttore, la funzionalità del PLC in termini di registrazione degli eventi di sicurezza delle informazioni dipende fortemente dal modello e dal firmware a disposizione.

I seguenti eventi tipici possono essere ricevuti dal PLC:

• errori di autenticazione;
• abilitare/disabilitare i servizi (HTTP/FTP, ecc.);
• il fatto di caricare una nuova configurazione o progetto;
• modifica dello stato del PLC (run/stop);
• collegamento di nuovi dispositivi.

Rostelecom-Solar ha effettuato dei test su apparecchiature Schneider Electric, collegando i PLC di Siemens a produttori russi (ad es. Entels).

L’esperienza ha dimostrato che eventi interessanti dal punto di vista IS possono essere consegnati e normalizzati in SIEM e sulla base di essi possono essere create regole di correlazione.

AWP e server

In genere, i sistemi operativi sulle postazioni di lavoro di operatori e ingegneri, nonché sui server, sono sistemi operativi basati su Windows, che non richiedono l’installazione di componenti software aggiuntivi per raccogliere gli eventi.

Sono sufficienti i log standard di Windows e, in alcuni casi, il monitoraggio avanzato con Sysmon.

Viene raccomandato inoltre di configurare ulteriormente la raccolta di eventi sui comandi eseguiti, la raccolta di eventi sull’avvio di Script-Block e Module Logging in Powershell, l’accesso ai file, la modifica dei rami del registro.

Sysmon consente di configurare la registrazione aggiuntiva di eventi come la creazione di uno nuovo o la conclusione di un processo, la creazione di un nuovo file su una workstation, la creazione e l’eliminazione di un oggetto di registro.

Tutto ciò aiuta a identificare un attacco mirato all’infrastruttura e ad ancorarvi l’attaccante.

Non dovresti aver paura di abilitare la registrazione a livello di sistema operativo, ma, ovviamente, prima di configurare la soluzione, dovrebbe essere testata per ogni singola installazione. Nell’esperienza svolta, il carico della CPU per il processo Sysmon è inferiore all’1% anche nel caso di emulazione di un attacco, ovvero nel momento in cui vengono generati più log.

Strumenti per la sicurezza delle informazioni

Sfortunatamente, finora non tutte le aziende hanno raggiunto l’implementazione di un progetto per proteggere un sistema di controllo automatizzato dei processi, quindi l’infrastruttura di solito contiene un set minimo di strumenti di sicurezza delle informazioni imposti. Si tratta, di norma, di un firewall sul perimetro della rete industriale e di agenti antivirus sugli host chiave dell’infrastruttura.

In genere, questi ISS supportano la registrazione completa degli eventi di sicurezza delle informazioni: invio di messaggi su malware rilevato, scadenza delle licenze, arresto dell’agent, connessioni di rete bloccate, ecc. tramite il protocollo syslog.

Queste informazioni sono utili per rilevare malware, rilevare comunicazioni segrete o canali di controllo. Ma evidentemente non è sufficiente, quindi, in fase di attuazione del progetto a tutela dell’OCII/SPCII, nuovi mezzi di protezione possono essere collegati a un sistema di monitoraggio comune.

hardware di rete

La maggior parte delle apparecchiature di rete (switch, router) dispone già di ampie capacità per la registrazione degli eventi. Siamo principalmente interessati ad attacchi L2 (ARP poisoning, spoofing, ecc.), attivazione di nuove porte di rete e modifiche alla configurazione.

Ciò è dovuto al fatto che le reti industriali sono generalmente piuttosto statiche e qualsiasi modifica può segnalare un incidente.

Inoltre, questo metodo può essere utilizzato per identificare connessioni illegali alla rete di router, modem, laptop e altri dispositivi che rappresentano una minaccia per il sistema di controllo del processo.

Software applicativo

Probabilmente, la raccolta di informazioni dal software applicativo è la più difficile da implementare. Anche le capacità di registrazione nei sistemi SCADA variano notevolmente a seconda del produttore e della versione del software, poiché non c’è uno standard comune.

Alcuni sistemi hanno un registro locale accessibile solo tramite sistemi con un’interfaccia GUI, altri hanno la capacità di inviare dati tramite syslog e altri ancora hanno un file locale e di difficile lettura.

Eventi interessanti su cui iniziare a connettere il software applicativo, ovviamente, saranno eventi di autenticazione, creazione o modifica dei diritti utente (soprattutto amministratori), modifica della configurazione del sistema, arresto delle funzioni di registrazione e arresto del processo SCADA stesso.

Come proteggere un ICS

In connessione con le crescenti tensioni geopolitiche, la diffusione di ransomware e la presenza di un gran numero di vulnerabilità nelle reti ICS esistenti, ha portato le organizzazioni ad ampliare il monitoraggio e la risposta agli incidenti informatici.

Sfortunatamente, per gli ICS è impossibile utilizzare gli stessi approcci delle reti aziendali. Nel settore industriale è necessario tenere conto delle specificità della connessione e dei principi generali di non invasività e di mancanza di possibilità di azioni di controllo.

Pertanto, raccomandiamo, come minimo, di creare gruppi di lavoro congiunti tra i dipartimenti del sistema di controllo dei processi automatizzati e della sicurezza delle informazioni. Puoi anche assumere una terza parte (fornitore di servizi) per eseguire le seguenti attività:

• condurre un audit;
• analisi delle possibilità di raccolta di eventi di sicurezza informatica e implementazione della funzione di monitoraggio nell’APCS;
• testare soluzioni progettuali;
• predisposizione di una soluzione per il collegamento di sorgenti di eventi al sistema di monitoraggio;
• utilizzo temporaneo o permanente del SOC del fornitore per svolgere il compito di identificare gli incidenti nel sistema di controllo del processo;
• formazione e tirocini per il personale dei servizi di risposta agli incidenti;
• condurre esercitazioni informatiche periodiche.