cyber security

Infrastrutture informatiche critiche: come riconoscerle e garantirne la sicurezza

La robustezza informatica deve essere aumentata in tutte le infrastrutture dell’ecosistema e non solo in quelle che la direttiva NIS classifica come critiche. Vediamo come assicurare l’igiene di ogni parte del sistema e garantire un adeguato livello di sicurezza complessivo, partendo da due eventi diversi ma correlati

Pubblicato il 19 Gen 2021

Fabrizio Baiardi

Professore Ordinario di Informatica, Responsabile gruppo ICT risk assessment and management, Università di Pisa

Emilio Panti

Università di Pisa & Haruspex srl

Riconoscere le infrastrutture critiche a cui applicare le varie normative di riferimento del settore è un compito molto difficoltoso. Per illustrare la complessità del problema che vogliamo discutere, partiamo da due eventi diversi ma tra loro correlati.

Indice degli argomenti

La direttiva NIS

Il primo evento è la direttiva NIS, Network Information Security, emanata nel luglio 2016 dal parlamento Europeo e recepita dall’Italia nel giugno 2018 [1]. Questa direttiva è una normativa che definisce alcune misure legislative per creare un livello comune, quanto più elevato possibile, di sicurezza delle reti e in generale dei sistemi informativi all’interno dell’Unione Europea. Lo scopo principale della direttiva è di migliorare la capacità di ogni singolo Stato membro di gestire la sicurezza delle reti informatiche. I vari stati dovrebbero aumentare, in modo comune e cooperato, i livelli di sicurezza in modo da riconoscere e gestire i rischi, nonché gli errori più gravi nella fornitura dei servizi informatici. Le disposizioni previste dalla Direttiva riguardano gli operatori di servizi essenziali, OSE, in settori che vanno dai trasporti al bancario, al sanitario, alla produzione ed al trasporto dell’energia ed alla distribuzione dell’acqua potabile. Altri operatori di servizi essenziali sono quelli delle infrastrutture ICT e dei mercati finanziari. Infine, la direttiva riguarda anche i fornitori di piattaforme che operano nei settori dei:

motori di ricerca;
servizi di cloud computing;
mercati online.

L’attacco a SolarWinds

Il secondo evento di nostro interesse è il recente attacco a SolarWinds [2, 3]. In base al recente annuncio del Dipartimento Informazioni e Sicurezza, “il sofisticato attacco introduce una backdoor all’interno della piattaforma SolarWinds attraverso un aggiornamento che permette all’hacker, una volta selezionate le vittime di interesse, di eseguire comandi manuali all’interno dei sistemi della vittima. Ponendo quindi le basi anche per il rilascio di ulteriore codice malevolo volto potenzialmente a spiare o a manomettere ulteriormente i sistemi dell’ente attaccato o dei servizi da esso erogati” [4]. Semplificando, si tratta di un attacco alla supply chain, ovvero ad un fornitore di software. Il sito del fornitore, SolarWinds in questo caso, viene attaccato e nel software viene inserita una backdoor. Nello specifico, la backdoor Sunburst è stata inserita in una libreria nella piattaforma Orion. La piattaforma comprende i seguenti strumenti:

Network Performance Manager (NPM)
Netflow Traffic Analyzer (NTA)
Network Configuration Manager (NCM)
Virtualization Manager (VM)
Server and Application Monitor (SAM)
Storage Resource Monitor (SRM).

L’attaccante sfrutta la backdoor quando lo strumento software, o l’aggiornamento di esso, viene installato sul sistema del cliente finale. Dopo un intervallo di tempo variabile da 12 a 14 giorni dall’installazione, la backdoor Sunburst tenta di connettersi ad un dominio di command&control per scaricare una seconda backdoor, Teardrop. Questa seconda backdoor installa il malware Cobalt Strike che permette all’attaccante di rubare informazioni, elevare i propri privilegi e muoversi lateralmente. Recentemente, è emersa anche una seconda versione dell’attacco, che inietta in una libreria della piattaforma un malware, Supernova, in grado di sfruttare una vulnerabilità della piattaforma per installare la backdoor.

Complessivamente, l’attacco è particolarmente critico perché i clienti utilizzano la piattaforma SolarWinds per il monitoraggio e la gestione delle loro infrastrutture. Inoltre, tra i clienti di SolarWinds sono presenti anche compagnie di telecomunicazione, le quali, essendo fornitrici di servizi essenziali, sono soggette alla normativa NIS. Ovviamente questi fornitori sono stati informati dell’attacco anche se SolarWinds, non essendo una società europea, non è in alcun modo soggetta alla normativa NIS. L’informazione sull’attacco e l’immediata applicazione delle varie patch non elimina il fatto che le infrastrutture critiche di questi OSE possano essere state attaccate in un periodo che va da giugno a dicembre 2020, con perdita di informazioni e potenziale installazione di malware che potrebbe essere ancora attivo nonostante le contromisure adottate. Il fatto che la password che proteggeva il sito SolarWinds fosse Solarwinds123 [5], se non di per sé già risolutivo, poiché gli attaccanti potevano utilizzare altre vie o altri strumenti, è comunque indicativo di una scarsa attenzione ai problemi di cybersecurity da parte di SolarWinds.

Supply chain ed ecosistema informatico

Gli attacchi alla supply chain sono noti da tempo. Ad esempio, negli stessi giorni in cui si scopriva l’attacco a SolarWinds, veniva segnalato un altro attacco alla supply chain in cui il gruppo Lazarus inseriva del malware nei browser degli utenti che visitavano siti di homebanking o del governo sudcoreano [6]. A conferma della lunga storia degli attacchi alla supply chain, vi è il fatto che di essi si occupano anche i Common Criteria, uno standard internazionale, ISO/IEC 15408, per la valutazione e la certificazione del livello di sicurezza offerto da moduli e sistemi informatici [7]. I Security Assurance Requirements dei Common Criteria definiscono i requisiti da soddisfare durante lo sviluppo e il trasporto del componente che si sta valutando per garantire i livelli di sicurezza adeguati. Considerazioni simili erano anche presenti nei cosiddetti Rainbow Books pubblicati negli anni ‘80 e ‘90 del secolo scorso [8].

Come garantire l’igiene informatica di tutto l’ecosistema

Gli attacchi alla supply chain evidenziano come la sicurezza delle infrastrutture critiche non possa essere garantita trascurando quella dei fornitori o degli strumenti utilizzati per il monitoraggio e la gestione delle stesse. In altri termini, le infrastrutture critiche sono organismi immersi in un ecosistema che comprende anche le infrastrutture informatiche dei loro fornitori e dei loro utilizzatori e che spazia tra paesi e continenti diversi. Gli organismi di questo ecosistema interagiscono, producono, condividono e si scambiano moduli software fondamentali per il loro funzionamento. Queste interazioni dimostrano che il problema della sicurezza non può essere affrontato in modo separato nelle diverse infrastrutture dell’ecosistema. Solo garantendo l’igiene informatica di tutto l’ecosistema possiamo sperare di difendere nel modo migliore quei particolari organismi che sono le infrastrutture critiche. L’igiene informatica può essere ottenuta garantendo un livello di sicurezza minimo in fase di progetto.

Questa garanzia, la security by design, si può ottenere individuando e rimediando alle vulnerabilità prima che esse vengano sfruttate da un attaccante, come avviene quando si applica la cybersecurity predittiva. Per poter intervenire e fermare l’attaccante è necessario analizzare in modo proattivo ogni infrastruttura per capire come essa potrebbe essere attaccata e per individuare tutti i possibili percorsi di attacco. La scoperta di soli alcuni, pochi, percorsi di attacco mediante sporadici penetration test non può garantire il miglioramento della robustezza del sistema che viene valutato [9].

La “offensive security” non risolve tutto

Altro vincolo da soddisfare per garantire l’igiene è l’applicazione periodica di patch e contromisure per mantenere adeguati livelli di robustezza. L’igiene informatica parte quindi dalla necessità di poter difendere le infrastrutture ICT, aumentandone la robustezza. Ciò evidenzia come sia illusoria la proposta di difendere le infrastrutture utilizzando unicamente tecniche di “offensive security” contro il sistema dell’attaccante, ovvero attaccando il sistema dell’attaccante. L’offensive security può essere applicata solo dopo aver rilevato un attacco. Rilevazione che risulta ovviamente estremamente complessa quando gli strumenti utilizzati dall’attaccante sono gli stessi che dovrebbero difendere il sistema. Il problema è noto da tempo se la Repubblica di Platone e quindi le Satire di Giovenale indicavano che «sarebbe certo ridicolo che il custode avesse bisogno d’un custode». Per coloro che preferiscono contrattaccare invece che aumentare la robustezza del proprio sistema, sorge un altro problema perché è spesso semplice per chi è attaccato riutilizzare gli strumenti ed il malware usati contro di lui in attacchi contro terzi o anche contro chi lo sta attaccando. L’ultimo esempio ci è dato ancora dall’attacco a SolarWinds. Usando la versione maliziosa della piattaforma SolarWinds Orion, è stato rubato uno strumento di attacco di FireEye che, sfruttando vulnerabilità, permette di attaccare più di 7 milioni di moduli in più di 5 milioni di sistemi. FireEye utilizzava questo strumento unicamente per valutare la robustezza dei sistemi dei propri clienti mentre non è chiaro come lo utilizzerà chi lo ha rubato. Ovviamente le patch per le vulnerabilità che lo strumento di FireEye sfrutta sono già disponibili da tempo, ma non sappiamo quanti dei potenziali bersagli le abbiano già applicate.

Ecosistema e assessment continuo

Gli attacchi alla supply chain non sono gli unici eventi che suggeriscono che la robustezza informatica deve essere aumentata in tutte le infrastrutture dell’ecosistema e non solo in quelle che la direttiva NIS classifica come critiche. Un ulteriore esempio viene fornito dalle recenti elezioni americane. Prima delle elezioni, Microsoft ha segnalato attacchi alla infrastruttura informatica di una società che operava come advisor di Joe Biden. Gli attacchi sono stati attribuiti a gruppi sponsorizzati dalla Russia [10]. Ovviamente anche l’infrastruttura degli advisor di Joe Biden non era considerata come critica e, altrettanto ovviamente, il successo dell’attacco poteva pesantemente influenzare l’esito delle elezioni. Di nuovo, abbiamo un ecosistema dove le varie infrastrutture interagiscono frequentemente e in cui focalizzarsi solo su alcune di esse può essere illusorio e quindi estremamente pericoloso.

Citiamo infine le infrastrutture informatiche delle aziende e dei laboratori farmaceutici: la drammatica pandemia che stiamo vivendo le ha rese bersaglio di numerosi attacchi, sia da parte della criminalità organizzata che di altri Stati. Intervenire solo ora per metterle in sicurezza è un problema non risolubile e che le lascia esposte ai vari attacchi. Ad esempio, anche adottando strumenti e soluzioni in grado di minimizzare il numero di contromisure da applicare [11], è sperimentalmente verificato che se viene interrotto il patching per un anno di un’infrastruttura, anche piccola, quando il patching riprende occorre applicare circa un centinaio di patch per garantire nuovamente un livello minimo di sicurezza. Nel tempo non banale necessario per applicare queste patch possono essere scoperte altre vulnerabilità da rimediare, aumentando ulteriormente la finestra di vulnerabilità dell’infrastruttura.

Solo un’analisi e una gestione del rischio continuo per tutte le infrastrutture dell’ecosistema informatico può limitare il numero di interventi sulla singola infrastruttura, diluendoli nel tempo, e garantire così un adeguato livello di sicurezza dell’ecosistema complessivo.

Riferimenti