Attacco alla rete elettrica ucraina del 2015: MATRIX alla prova
Dagli standard OT a un incidente reale: MATRIX viene confrontato con NIST, IEC 62443 e NIS2 e applicato retrospettivamente alla catena dell’attacco alla rete elettrica ucraina del 2015.
Nella quinta parte della serie il framework è stato applicato allo scenario delle sottostazioni NovaGrid. Questa sesta parte lo mette alla prova in tre modi.
Prima confronta le sei fasi con NIST SP 800-82r3, ISA/IEC 62443 e articolo 24 del d.lgs. 138/2024. Poi affianca MATRIX ai metodi di Cloud Security Alliance e Software Engineering Institute. Infine rilegge, passaggio per passaggio, l’attacco del 23 dicembre 2015 alle società di distribuzione elettrica ucraine.
MATRIX e standard OT: NIST, IEC 62443 e NIS2
Il primo criterio di adeguatezza di un framework di selezione dei controlli è la sua completezza: le sei fasi devono generare, nel loro insieme, gli artefatti e le attività che gli standard di settore prescrivono, senza lasciare scoperti requisiti essenziali.
La Tabella 3 mappa ciascuna fase di MATRIX sui corrispondenti requisiti della NIST SP 800-82r3,[1] della serie ISA/IEC 62443[2] e dell’articolo 24 del decreto di recepimento della NIS2.[3] La mappatura mostra che le fasi del framework coprono l’intero ciclo prescritto dalle tre fonti, dalla identificazione del contesto e degli asset fino al monitoraggio continuo e alla gestione del rischio residuo.
L’esercizio non rivela lacune di copertura. La specificità di MATRIX rispetto alle tre fonti non risiede dunque nell’aggiunta di requisiti nuovi, ma nel meccanismo, assente negli standard, che vincola la selezione di ciascun controllo all’idoneità tecnica dell’asset e alla criticità di missione, rendendo esplicita la logica di allocazione differenziata.
Tabella 3. Mappatura di copertura delle fasi di MATRIX sui requisiti degli standard di riferimento.
| Fase MATRIX | NIST SP 800-82r3 | ISA/IEC 62443 | Art. 24 D.Lgs. 138/2024 |
| M, contesto di missione e DAAS | Identificazione di sistema e impatto; categorizzazione | Definizione del system under consideration e delle zone | Analisi del rischio orientata all’impatto |
| A, idoneità degli asset | Inventario e caratterizzazione degli asset OT | Assegnazione dei security level target per zona | Gestione e proporzionalità delle misure |
| T, superficie d’attacco | Analisi di minacce e vulnerabilità | Identificazione di threat e conduit esposti | Gestione delle vulnerabilità e della supply chain |
| R, rischio e compromessi | Valutazione e trattamento del rischio | Riconciliazione tra security level target e raggiunto | Selezione di misure adeguate e proporzionate |
| I, matrice di allocazione | Selezione e implementazione delle contromisure | Realizzazione dei requisiti di sicurezza per zona | Controllo accessi, MFA, crittografia, segmentazione |
| X, esecuzione ed evoluzione | Monitoraggio, manutenzione e miglioramento continuo | Gestione del ciclo di vita della sicurezza | Continuità operativa, gestione e notifica incidenti |
MATRIX a confronto con CSA e Software Engineering Institute
La seconda componente confronta MATRIX con i due schemi metodologici a esso più prossimi: il processo in cinque fasi della Cloud Security Alliance per le infrastrutture critiche[4] e l’approccio del Software Engineering Institute alla mappatura dei principi zero trust su ambienti a vincoli stringenti.[5] Il confronto è condotto rispetto a cinque criteri rilevanti per l’adozione in ambito OT, sintetizzati nella Tabella 4.
Il confronto evidenzia che MATRIX eredita dal SEI la centralità dei compromessi e l’idea di profilazione dell’idoneità, ma le traduce in un artefatto operativo, la matrice di allocazione, che né il processo CSA né il lavoro SEI rendono esplicito. Il valore distintivo si concentra quindi nella capacità di produrre, asset per asset e capability per capability, una traccia decisionale comunicabile e verificabile.
Tabella 4. Confronto strutturato tra MATRIX e gli schemi metodologici esistenti.
| Criterio | CSA cinque fasi | SEI principi e tradeoff | MATRIX |
| Orientamento alla missione | Implicito | Parziale | Esplicito, fase M |
| Profilazione dell’idoneità degli asset | Assente | Presente, set di attributi | Presente e integrata nella selezione |
| Analisi esplicita dei compromessi | Limitata | Centrale | Centrale, fase R |
| Allocazione differenziata dei controlli | Assente | Concettuale | Operativa, matrice di allocazione |
| Tracciabilità documentale per la conformità | Bassa | Media | Alta, artefatto matriciale |
Attacco alla rete elettrica ucraina del 2015: la validazione retrospettiva di MATRIX
La componente più stringente applica il framework, a posteriori, a un incidente reale e ampiamente documentato, così da verificare se le sue fasi avrebbero condotto alla selezione di controlli pertinenti rispetto ai vettori effettivamente sfruttati. Il caso scelto è l’attacco del 23 dicembre 2015 alle società di distribuzione elettrica ucraine, che provocò un’interruzione di alimentazione per circa 225.000 utenze e la cui ricostruzione forense è disponibile nella relazione E-ISAC e SANS.[6] La scelta è motivata da due ragioni: l’incidente colpì un ambiente di sottostazioni di distribuzione, omologo allo scenario illustrativo, e la sua catena di attacco è nota nel dettaglio.
È inoltre accertato che l’interruzione non fu causata dal solo malware impiegato, bensì dall’operatività manuale degli attaccanti sui sistemi di controllo, circostanza che rende il caso particolarmente adatto a saggiare un framework incentrato sull’autorizzazione e sulla verifica dell’accesso.
La catena dell’attacco: da BlackEnergy 3 a KillDisk
La Tabella 5 scompone la catena di attacco nei suoi passaggi documentati e associa a ciascuno la fase di MATRIX e la capability che ne avrebbero ridotto la probabilità o l’impatto.
Tabella 5. Applicazione retrospettiva di MATRIX alla catena di attacco del 2015.
| Passo dell’attacco | Fase MATRIX | Capability di contenimento |
| Spear phishing con macro su workstation corporate, impianto di BlackEnergy 3 | T, A | Verifica della postura del dispositivo; segmentazione IT e OT |
| Ricognizione prolungata e raccolta di credenziali, assenza di autenticazione forte | A, I | Identità e autenticazione a più fattori; monitoraggio centralizzato |
| Accesso remoto ai sistemi SCADA tramite credenziali legittime | I | Autorizzazione continua basata su policy; gestione sicura degli accessi remoti di terze parti |
| Apertura manuale degli interruttori da HMI compromesse | M, I | Microsegmentazione tra livelli; verifica dell’identità sui comandi verso il Livello 1 |
| Sovrascrittura del firmware dei convertitori seriale-Ethernet delle sottostazioni | A, R | Controlli compensativi e gestione del rischio residuo sugli asset non aggiornabili |
| Cancellazione delle workstation con KillDisk e perdita di visibilità | X | Monitoraggio e logging centralizzato fuori banda; continuità operativa |
| Disabilitazione dell’alimentazione di soccorso del centro di controllo | M, R | Caratterizzazione dei DAAS critici; prioritizzazione orientata all’impatto |
| Denial of service telefonico verso i call center | T | Mappatura estesa della superficie d’attacco oltre il perimetro tecnico |
Accesso allo SCADA e apertura degli interruttori: i passaggi decisivi
L’analisi mostra che ogni passo della catena trova corrispondenza in almeno una fase del framework e in una capability che ne avrebbe ostacolato la riuscita o ridotto le conseguenze. Sono particolarmente significativi due punti. Primo, i passaggi decisivi dell’attacco, l’accesso remoto con credenziali legittime e l’apertura manuale degli interruttori, ricadono esattamente nello spazio che la fase I presidia con l’autorizzazione continua e la verifica dell’identità sui comandi critici.
Firmware compromesso, asset legacy e rischio residuo
Secondo, il danno più duraturo, la sovrascrittura del firmware dei convertitori, colpì asset non aggiornabili: proprio la categoria per cui MATRIX prescrive controlli compensativi e la contabilizzazione esplicita del rischio residuo, anziché l’illusione di una protezione nativa. La validazione retrospettiva non dimostra che il framework avrebbe impedito l’incidente, affermazione che nessun metodo qualitativo può sostenere, ma conferma che la sua applicazione avrebbe portato all’attenzione, in modo strutturato, i controlli la cui assenza fu determinante.
Cosa dimostra la validazione del framework MATRIX
Nel loro insieme, le tre componenti delineano una validazione onesta nei suoi limiti e robusta nelle parti dimostrabili. La copertura rispetto agli standard e il confronto con gli schemi esistenti collocano il framework nel suo spazio metodologico, mentre la prova retrospettiva su un incidente reale ne saggia la pertinenza operativa contro un avversario documentato. Permangono, dichiaratamente, la natura qualitativa del metodo e l’assenza di una validazione empirica sul campo in impianti in esercizio, che resta la prova ultima e l’obiettivo prioritario degli sviluppi futuri.
PRINCIPIO GUIDA: Dalla compromissione iniziale al sabotaggio: ogni fase dell’attacco evidenzia un controllo che avrebbe potuto ridurne probabilità o impatto.
Dalla validazione ai limiti del framework MATRIX
La validazione ha confini dichiarati: il metodo è qualitativo e manca ancora una prova su impianti in esercizio. Nella settima parte della serie l’autore discute apertamente pregi, limiti e generalizzabilità di MATRIX. Il paper integrale «Zero Trust selettivo negli ambienti OT» è disponibile per il download.
Fonti:
[1] K. Stouffer, M. Pease, C. Tang, T. Zimmerman, V. Pillitteri, S. Lightman, A. Hahn, S. Saravia, A. Sherule e M. Thompson, Guide to Operational Technology (OT) Security, NIST Special Publication 800-82r3. Gaithersburg, MD, USA: National Institute of Standards and Technology, 2023, doi: 10.6028/NIST.SP.800-82r3.
[2] International Electrotechnical Commission, IEC 62443: Security for Industrial Automation and Control Systems (serie). Ginevra, Svizzera: IEC.
[3] Decreto Legislativo 4 settembre 2024, n. 138, recepimento della direttiva (UE) 2022/2555 (NIS2). Gazzetta Ufficiale della Repubblica Italiana, n. 230, 1° ottobre 2024.
[4] Cloud Security Alliance, Zero Trust Guidance for Critical Infrastructure. Seattle, WA, USA: CSA Zero Trust Working Group, ott. 2024.
[5] C. J. Alberts, T. Morrow, R. Brown e C. M. Wallen, Tailoring Security and Zero Trust Principles to Weapon System Environments, Special Report. Pittsburgh, PA, USA: Software Engineering Institute, Carnegie Mellon University, 2025.
[6] R. M. Lee, M. J. Assante e T. Conway, Analysis of the Cyber Attack on the Ukrainian Power Grid. Washington, DC, USA: E-ISAC e SANS Industrial Control Systems, 2016.
https://www.ictsecuritymagazine.com/articoli/attacco-alla-rete-elettrica-ucraina-2015/