La gestione dei rischi occupa il centro esatto della disciplina NIS 2, eppure la normativa non impone un metodo unico: un’organizzazione può partire dagli asset, dai processi, dai servizi o dagli scenari di minaccia.
Ogni prospettiva illumina una parte diversa della realtà e ne lascia un’altra in ombra.
La scelta del metodo, dunque, non è una decisione tecnica di secondo piano: determina il modo in cui l’organizzazione comprenderà i propri rischi, selezionerà le misure e dimostrerà la coerenza del proprio sistema.
Il metodo giusto non esiste: c’è quello che l’organizzazione riesce davvero a usare
Non esiste un metodo universalmente corretto per analizzare i rischi. Esiste un metodo coerente con il contesto, capace di produrre risultati ripetibili, che l’organizzazione comprende e riesce a mantenere nel tempo e che collega i rischi alle decisioni.
Chi cerca “il modello migliore” sta ponendo la domanda sbagliata.
La domanda corretta suona diversamente: quale modello consente a questa organizzazione – con la sua storia, le sue persone, le sue informazioni – di rappresentare i propri rischi in modo completo, comprensibile e utilizzabile?
La differenza tra le due domande cambia completamente lo scenario.
Un metodo molto sofisticato fallisce quando pretende informazioni che l’organizzazione non possiede; un modello semplice, invece, funziona quando produce valutazioni coerenti e orienta decisioni concrete.
La qualità dell’analisi non dipende dal numero di colonne della matrice. Dipende dalla qualità del ragionamento che collega attività, eventi, conseguenze e misure e dalla capacità di rendere tale analisi ripetibile, come del resto insegna anche la ISO/IEC 27001.
La gestione dei rischi è un processo, non un documento
L’analisi dei rischi viene talvolta descritta come un documento e la definizione è riduttiva perché il documento è soltanto l’evidenza finale di un processo che:
- parte dalla comprensione del contesto;
- identifica ciò che deve essere protetto;
- individua gli eventi capaci di produrre conseguenze negative;
- valuta impatti e probabilità;
- considera le misure esistenti;
- determina il livello di rischio;
- orienta il trattamento;
- monitora i risultati e aggiorna le valutazioni quando cambiano attività, tecnologie, minacce o dipendenze.
Fermare questo movimento in un file è come fotografare un fiume.
La logica del decreto NIS conferma l’impostazione. L’art. 24 richiede ai soggetti NIS misure tecniche, operative e organizzative adeguate e proporzionate alla gestione dei rischi.
Quindi non parte dal controllo, ma dal rischio che quel controllo deve mitigare. Il principio esclude ogni approccio puramente documentale.
Una misura non è adeguata perché compare in un elenco, ma è adeguata quando affronta un rischio concreto con un’efficacia coerente con il contesto.
Prima del metodo vengono i criteri
Alcune organizzazioni compiono il percorso alla rovescia: scelgono lo strumento prima di avere definito il metodo.
Acquistano una piattaforma, importano una matrice, adottano un modello trovato in rete e poi cercano di adattare la propria realtà alle colonne disponibili.
Il percorso corretto è l’opposto. Prima occorre stabilire:
- cosa verrà analizzato e con quali criteri;
- come verrà valutato l’impatto e stimata la probabilità ed eventualmente, per i modelli più sofisticati, anche il grado di rilevabilità della minaccia;
- come verranno considerate le misure esistenti;
- come verrà calcolato il rischio residuo;
- quali soglie richiederanno un trattamento;
- chi approverà l’accettazione del rischio e quando (con che frequenza) avverrà il riesame.
Soltanto dopo si sceglie lo strumento, che a quel punto è davvero uno strumento e non un metodo travestito.
Qualunque sia la scelta, un metodo solido possiede alcune qualità riconoscibili. In particolare è:
- coerente: valutazioni simili producono risultati confrontabili;
- ripetibile: persone diverse, applicando gli stessi criteri, non ottengono risultati arbitrari;
- comprensibile: il vertice capisce perché un rischio è stato considerato alto;
- documentato: le decisioni restano ricostruibili in quanto motivate;
- aggiornabile: non richiede uno sforzo tale da diventare obsoleto il giorno dopo la sua costruzione;
- dettagliato: ad un livello congruente con le esigenze di documentazione dell’organizzazione;
- utile, che è la qualità riassuntiva di tutte le altre: ogni risultato orienta una decisione.
L’approccio per asset: la profondità e il suo prezzo
Il primo approccio parte da ciò che possiede valore per l’organizzazione: informazioni, hardware, software, infrastrutture, servizi, persone, sedi, competenze, fornitori.
Il percorso tipico:
- identifica l’asset;
- individua le minacce;
- analizza le vulnerabilità;
- valuta le conseguenze e determina il rischio.
Il vantaggio è evidente: la protezione diventa concreta.
L’analisi osserva puntualmente ciò che può essere compromesso, collega un sistema alle sue vulnerabilità specifiche, associa misure tecniche a componenti definite e sostiene con naturalezza attività come la gestione degli aggiornamenti, il controllo degli accessi, la protezione delle configurazioni, la gestione delle vulnerabilità e il monitoraggio.
Il prezzo si paga quando il dettaglio cresce.
Una grande organizzazione possiede migliaia di asset – server, applicazioni, database, apparati, dispositivi, account, componenti cloud, servizi esterni – e l’inventario rischia di assorbire più risorse dell’analisi: ogni modifica richiede un aggiornamento, ogni duplicazione moltiplica le valutazioni.
Il problema più profondo riguarda il significato
Un server non è critico perché esiste ma è critico perché sostiene una funzione e quindi contiene le informazioni che vanno protette.
Senza il collegamento al processo o al servizio, l’analisi diventa tecnicamente dettagliata e organizzativamente muta.
Il vertice – e in generale la maggior parte delle risorse di un’organizzazione – non reagisce alla frase: «L’asset SRV147 presenta un rischio alto». Reagisce, invece, immediatamente a: «Un attacco a questo sistema può bloccare la gestione degli ordini per tre giorni».
La distanza tra queste due frasi è infatti la distanza tra un inventario e un’analisi.
È la stessa differenza tra chiedere «Quale rischio presenta l’asset SRV147?» e chiedere «Che cosa succede se l’asset SRV147 diventa indisponibile, per esempio per un guasto o per mancanza di alimentazione?».
Alla prima domanda può rispondere solo chi conosce nel dettaglio il sistema tecnico. Alla seconda risponde con naturalezza chi ha padronanza dei processi e delle dipendenze operative.
A quel punto, il lavoro consiste nello stimare la probabilità che l’evento si verifichi – considerando le molteplici cause possibili – e nel valutare se un’interruzione di tre giorni sia accettabile per l’organizzazione.
L’approccio per processi: il linguaggio delle conseguenze
L’analisi per processi ribalta la prospettiva perchè non parte dalla tecnologia, ma parte dal modo in cui l’organizzazione opera.
Gestione degli ordini, produzione, risorse umane, acquisti, amministrazione, assistenza ai clienti, erogazione di un servizio eccetera: per ciascun processo vengono individuati attività, responsabili, asset, informazioni, persone, tecnologie, fornitori, dipendenze ed eventi di rischio.
Il vantaggio principale sta nel linguaggio.
Il rischio viene descritto attraverso le conseguenze sul funzionamento dell’organizzazione: non “il database potrebbe diventare indisponibile”, ma “l’organizzazione potrebbe perdere la capacità di gestire gli ordini”.
Questa formulazione avvicina la sicurezza alle decisioni, consente al vertice di comprendere l’effetto, aiuta a stabilire le priorità e favorisce il dialogo con la continuità operativa, la qualità e la gestione dei servizi.
Il limite dipende dalla qualità della mappa.
Se i processi non sono definiti, l’analisi poggia su una rappresentazione fragile; se, invece, la mappa è generica, i rischi diventano astratti e se è troppo dettagliata, riemerge lo stesso problema dell’inventario degli asset, soltanto travestito da organigramma.
C’è un errore da evitare con cura: il processo non sostituisce la tecnologia.
Una valutazione orientata al business deve comunque identificare gli asset dai quali dipende, altrimenti descrive perfettamente le conseguenze senza indicare dove intervenire – una diagnosi senza terapia.
L’approccio per servizi: il dialogo naturale con la categorizzazione
Il terzo approccio parte da ciò che l’organizzazione eroga: la posta elettronica, la piattaforma gestionale, il portale, il servizio di pagamento, il servizio di autenticazione, il servizio sanitario, l’assistenza, il servizio di gestione del personale.
La prospettiva funziona particolarmente bene quando esiste un catalogo dei servizi: ognuno di questi può essere valutato considerando gli utenti, i livelli attesi, la disponibilità, l’integrità, la riservatezza, l’autenticità, le dipendenze e le conseguenze dell’interruzione.
Questo approccio, non a caso, dialoga con naturalezza con la categorizzazione NIS, costruita proprio attorno ad attività e servizi.
Il collegamento può risultare quasi immediato: l’organizzazione individua il servizio interno corrispondente, confronta le valutazioni, ricostruisce i rischi, verifica le misure.
Il limite si annida negli asset condivisi. Un’infrastruttura può sostenere dieci servizi: analizzata separatamente dentro ciascuno, produce duplicazioni; lasciata alla responsabilità di tutti e finisce per non essere analizzata da nessuno.
Le dipendenze trasversali – un sistema di identità, una rete, un’infrastruttura cloud, un fornitore – hanno un effetto sistemico e la loro criticità non impatta su un solo servizio ma dal numero e dalla rilevanza dei servizi che sostengono.
Su questo punto torneremo, perché è qui che i modelli semplici cominciano a scricchiolare.
L’approccio per scenari: la forza del racconto, il rischio della cronaca
Il quarto approccio parte da un evento.
Un attacco ransomware, la compromissione di un account privilegiato, l’indisponibilità del cloud, un errore umano, una perdita di dati, un attacco alla catena di fornitura, un’interruzione della connettività, la compromissione di un sistema industriale.
Per ogni scenario si analizzano cause, asset coinvolti, vulnerabilità, conseguenze, probabilità, misure esistenti e rischio residuo.
Il vantaggio è l’immediatezza.
Lo scenario racconta qualcosa che può accadere: le persone riescono a immaginarlo, il vertice ne comprende le conseguenze, le funzioni tecniche possono discutere i controlli applicati e quelli da applicare.
La valutazione diventa concreta.
Il metodo permette inoltre di analizzare eventi che colpiscono più asset contemporaneamente: un ransomware non compromette un solo server, ma può coinvolgere identità, reti, endpoint, backup, fornitori e comunicazioni e lo scenario consente di osservare l’intera catena.
Il limite riguarda la completezza.
Un elenco troppo ristretto lascia zone d’ombra; uno troppo ampio diventa impossibile da mantenere e c’è un’insidia più sottile: la cronaca orienta l’attenzione verso gli attacchi più visibili e l’organizzazione che si affida solo agli scenari noti rischia di valutare gli eventi di cui parlano i giornali trascurando errori, guasti, dipendenze e vulnerabilità meno spettacolari ma altrettanto capaci di fermarla.
Le prospettive complementari
Attorno ai quattro approcci principali ne orbitano altri, ciascuno con un pregio e una controindicazione.
L’analisi per minacce parte dagli eventi ostili o accidentali e offre una visione immediata, ma può perdere il collegamento con il valore degli elementi colpiti.
Invece l’analisi per sistemi e applicazioni, comune negli ambienti IT e OT, facilita le attività tecniche e rischia di restare distante dagli obiettivi organizzativi.
L’analisi per unità organizzative aiuta ad attribuire responsabilità e produce duplicazioni quando più strutture usano le stesse risorse.
Inoltre, l’analisi per trattamenti di dati personali serve alla protezione dei dati e non può coprire da sola l’intero sistema di sicurezza.
L’analisi per obiettivi, infine, parte da ciò che l’organizzazione vuole conseguire e favorisce l’integrazione con la gestione complessiva dei rischi, ma richiede una maturità organizzativa elevata.
Nessuna di queste prospettive è concorrente delle altre: sono viste complementari sulla stessa realtà.
Che cosa richiede la ISO/IEC 27001
La ISO/IEC 27001, riferimento internazionale per i sistemi di gestione della sicurezza delle informazioni, richiede un processo di gestione dei rischi coerente con le caratteristiche e le necessità dell’organizzazione e non propone un modello unico valido per tutti: la stessa presentazione ufficiale della norma sottolinea la necessità di adattare il processo a dimensioni, obiettivi e struttura.
Questa flessibilità viene talvolta scambiata per libertà assoluta, ma non lo è.
La libertà riguarda la scelta del metodo, non elimina il rigore: l’organizzazione deve dimostrare come identifica i rischi, come li analizza e li valuta, come seleziona le misure, come determina il rischio residuo e come assume le decisioni.
Infine, la qualità si misura sulla tracciabilità, non sulla forma della matrice.
Come scegliere l’approccio
La scelta, alla fine, deve partire dal contesto.
Un’organizzazione con un inventario aggiornato e una forte maturità tecnica può muovere dagli asset; un’altra con processi ben definiti partirà dai processi; un soggetto orientato all’erogazione valorizzerà i servizi; chi vuole coinvolgere il vertice troverà negli scenari il proprio alleato.
Pesano le dimensioni, la complessità, il settore, il modello operativo, la maturità, le competenze, la qualità delle informazioni disponibili, i sistemi di gestione già esistenti, gli obblighi applicabili.
Inoltre, pesa un criterio che le organizzazioni sottovalutano sistematicamente: la capacità di mantenere il modello nel tempo.
Un metodo perfetto ma non aggiornato diventa rapidamente inutile.
Il modello deve crescere con l’organizzazione, non deve paralizzarla.
Gestione dei rischi NIS 2: il metodo non è imposto, ma dalla scelta discende la qualità del sistema
Ogni metodo mostra una parte della realtà.
L’approccio per asset offre profondità tecnica; quello per processi collega il rischio al funzionamento; quello per servizi osserva ciò che viene erogato; quello per scenari rende concreti gli eventi.
Nessuno possiede tutte le risposte e la scelta non deve seguire le mode: deve seguire il contesto.
Il metodo giusto è quello che consente di comprendere i rischi, comunicarli e decidere.
La qualità non dipende dal punto di partenza; dipende dalla capacità di mantenere visibile la catena che lega ciò che l’organizzazione deve proteggere, gli eventi che possono comprometterlo, le conseguenze, le misure e il rischio residuo.
Quando la catena resta visibile, il metodo funziona. Invece, quando si spezza, l’analisi diventa un esercizio.
Resta però una domanda e chi è arrivato fin qui probabilmente se la sta già ponendo: è davvero necessario scegliere una sola prospettiva? Un servizio dipende da processi. Questi ultimi utilizzano informazioni. Esse vivono su asset; gli asset sono esposti a minacce che, a loro volta, sfruttano vulnerabilità.
La realtà non è divisa in modelli.
Nel prossimo capitolo, entreremo nel modello ibrido e vedremo come collegare servizi, processi, informazioni, asset e scenari in un’unica architettura del rischio.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Giuseppe Alverone e Monica Perego
Source link
