Non conta soltanto se i singoli controlli sono soddisfatti, ma se le competenze rilevanti per un esercizio sicuro funzionano in condizioni realistiche.
La resilienza informatica si realizza quando i controlli, le responsabilità e i processi operativi sono coordinati tra loro. Per questo motivo vale la pena guardare oltre le singole misure e considerare l’intera catena di sicurezza. Chi individua l’anello più debole e lo rafforza in modo mirato ottiene risultati migliori con le proprie risorse.
Disclaimer
PerspectivE è una piattaforma all’interno del sito web AES sulla quale l’associazione offre a settore, scienza, politica ed economia la possibilità gratuita di pubblicare articoli specialistici e analisi rilevanti per il settore. Autrici e autori esterni esprimono in questi articoli la loro opinione personale, che non corrisponde necessariamente ai punti di vista e alle posizioni dell’AES.
Chi attua lo standard minimo ICT assegna requisiti, implementa misure e nomina responsabili. A ogni misura completata, però, si pone un’ulteriore domanda: l’esercizio è diventato davvero più sicuro e più robusto?
Un requisito soddisfatto è un progresso importante. Se ne derivi una resilienza informatica affidabile, tuttavia, si vede solo nell’interazione con altri controlli, con le persone responsabili e con i processi operativi. Questa interazione deve funzionare anche sotto pressione temporale, in caso di assenze del personale o quando si verificano più disturbi contemporaneamente.
La visione dei singoli controlli va quindi completata con quella delle competenze operative: individuare e trattare le vulnerabilità, gestire gli incidenti di sicurezza e ripristinare i servizi critici. Una simile competenza comprende l’intera sequenza, dal fattore scatenante al risultato perseguito, incluse le persone, i sistemi e i partner esterni coinvolti.
Rafforzare l’intera catena, non solo singoli anelli
La sicurezza può essere intesa come una catena. Singoli anelli possono essere tecnicamente eccellenti. Se altrove mancano regole chiare, passaggi di consegne affidabili o responsabilità univoche, la catena resta comunque vulnerabile. La sua solidità si decide sull’anello più debole.
In pratica ciò significa che perfezionare ulteriormente un controllo già solido non è sempre il passo successivo più efficace. La leva maggiore si trova spesso in una debolezza poco appariscente del processo. Un monitoraggio tecnicamente avanzato, per esempio, serve a poco se gli allarmi non vengono valutati per tempo o se l’escalation non porta da nessuna parte.
Invece di limitarsi a evadere la prossima misura singola, conviene quindi osservare regolarmente la competenza nel suo insieme: che cosa funziona in modo affidabile? Dove si inceppa il processo? Dove si impiegano già più risorse di quanto sia ragionevole rispetto al rischio? I tre esempi seguenti mostrano come da questa prospettiva possano emergere priorità diverse.
Figura 1: La resilienza nasce dall’interazione dei controlli, non da singoli anelli perfetti.
Gestione delle vulnerabilità: dalla rilevazione al trattamento efficace
Un aggiornamento installato è una misura. La competenza di gestire le vulnerabilità, tuttavia, inizia prima: i componenti critici e le loro dipendenze devono essere noti. Gli avvisi dei produttori, i risultati delle scansioni di vulnerabilità e le modifiche rilevanti ai sistemi devono raggiungere le persone responsabili. Solo allora si può valutare quali sistemi sono interessati, quali conseguenze sono da temere e quale trattamento è sensato, tenendo conto dell’esercizio, delle finestre di manutenzione e dei requisiti OT.
Un inventario degli asset affidabile ne costituisce la base. Collega i sistemi alla loro criticità, ai responsabili e alle dipendenze operative. Ciò consente per esempio di valutare se una vulnerabilità potrebbe compromettere l’esercizio della rete. Su questa base, IT, OT e partner di servizio esterni devono concordare un trattamento coordinato.
Ne fa parte anche la gestione delle eccezioni: che cosa succede se non è disponibile alcuna patch o se non può essere installata a breve termine? Chi decide sulle misure compensative? Chi accetta un rischio residuo per un periodo limitato, e quando verrà rivalutato? Il lavoro non finisce con il ticket chiuso. Deve essere tracciabile se la vulnerabilità è stata eliminata, se il suo impatto è stato limitato o se il rischio residuo è stato accettato in modo motivato.
Incidenti di sicurezza: dall’allarme alla reazione coordinata
Anche nella gestione degli incidenti di sicurezza il rilevamento tecnico è solo una parte della competenza. Ulteriori fonti di dati e allarmi servono a poco se il processo tra rilevamento, decisione e reazione non funziona.
Uno scenario concreto rende visibili questi passaggi: una configurazione critica viene modificata in modo inatteso. Quale segnale avvia il trattamento? Chi lo valuta, e entro quale termine? Chi può decidere, insieme all’esercizio, su isolamento, spegnimento o prosecuzione dell’esercizio? Supplenza ed escalation funzionano anche al di fuori dell’orario d’ufficio, nella misura in cui l’esercizio lo richiede?
Se la debolezza risiede in questi passaggi, un servizio di picchetto chiarito, una competenza decisionale univoca o un percorso di escalation testato possono ottenere più di un’ulteriore fonte di log. Budget e attenzione dovrebbero essere impiegati dove migliorano effettivamente la capacità di reazione.
Ripristino: dal backup al servizio operativo
Un backup riuscito da solo non ripristina l’esercizio. Ciò che conta è se un servizio necessario torna disponibile entro il tempo richiesto dall’esercizio. A tal fine persone, documentazione, canali di comunicazione, presupposti tecnici e partner esterni devono collaborare.
I piani di ripristino andrebbero quindi testati rispetto a obiettivi di ripristino concreti. Chi avvia e approva il ripristino? Quali sistemi e servizi hanno la priorità? Quali dipendenze determinano la sequenza? Quali procedure sostitutive si applicano se i mezzi di comunicazione centrali vengono a mancare? Se il test rivela una lacuna, servono una persona responsabile, un termine per eliminarla e un nuovo test. Solo così la constatazione rafforza la competenza.
Conclusione: tenere d’occhio l’intera catena di sicurezza
I tre esempi mostrano che lo standard minimo ICT, con il suo quadro e i suoi controlli, resta una base importante. La visione delle competenze trasversali non lo sostituisce. Collega i singoli controlli al risultato operativo che devono rendere possibile insieme.
Per non rimanere bloccati nella routine delle singole misure, occorre prendere regolarmente le distanze dai dettagli. Quale competenza è decisiva per un esercizio sicuro? Dove si trova il suo anello più debole? Non conta solo il livello di maturità più basso, ma quale debolezza potrebbe avere l’impatto maggiore nell’esercizio concreto.
I livelli di maturità dello standard minimo ICT costituiscono la base per valutare i singoli controlli. Si raccomanda inoltre di definire per ogni livello criteri verificabili per l’integrazione nella competenza complessiva: le responsabilità e i passaggi necessari sono coordinati? Vengono praticati in modo affidabile nella quotidianità? L’interazione viene verificata e migliorata? Criteri di questo tipo rendono più concreta la valutazione operativa, senza sostituire le definizioni di livello esistenti.
Un livello di maturità elevato non dovrebbe quindi essere giustificato soltanto dalla qualità di uno strumento, di un documento o di una singola fase di lavoro. Prima della valutazione occorre verificare se anche le interfacce essenziali per il controllo sono state effettivamente implementate. Le lacune residue nell’interazione devono restare visibili, anche se singoli controlli sono già ben sviluppati.
Da questo quadro d’insieme si possono ricavare le priorità: quale miglioramento rafforza nel modo più efficace la competenza in questione? Così le limitate risorse umane e finanziarie possono essere impiegate dove apportano un contributo operativo tracciabile. L’attuazione resta concreta, con responsabili, scadenze e una verifica che la misura elimini effettivamente la debolezza individuata.
Il metro di misura non è quindi l’elenco più lungo possibile di misure completate. Ciò che conta è che il prossimo miglioramento rafforzi l’anello più debole e renda l’intera competenza più affidabile nell’esercizio.
fortControl: sviluppare la sicurezza in modo equilibrato
fortControl è una piattaforma svizzera per la gestione della sicurezza delle informazioni e dei rischi. Riunisce requisiti, rischi e misure e facilita lo sviluppo equilibrato delle competenze di sicurezza: affrontare le debolezze in modo mirato, fissare priorità e tenere d’occhio l’interazione.
