Registro dei rischi e sicurezza informatica, alcuni aggiustamenti per rafforzare il legame

Un componente prezioso della corporate governance è il registro dei rischi. Non obbligatorio ma fortemente raccomandato per fornire / costruire una solida organizzazione per il processo di governance del rischio. Consiste nella raccolta degli scenari di rischio identificati che vengono contabilizzati e incorporati nel profilo di rischio a livello aziendale. È la bussola del piano di risposta al rischio perché rappresenta il riferimento principale per tutte le informazioni relative al rischio, supportando le decisioni relative al rischio e la prioritizzazione delle attività di risposta al rischio.

Secondo quanto definito nel CRISC Review Manual¹ “le organizzazioni mantengono registri dei rischi al fine di consolidare tutte le informazioni sul rischio in un unico archivio centrale”. Ossia “ottenere da un’unica fonte lo stato del processo di gestione dei rischi”.² La forza di queste frasi sta nella parola “unica” che significa globale e centralizzato. Il legame tra gli obiettivi aziendali e l’operatività a loro supporto è reso possibile dalla presenza di un unico collettore per la condivisione di tutte le informazioni di controllo.

Questo archivio centrale è una risorsa di estremo valore ma critica in quanto trasversale a tutti i processi aziendali. Sono consolidate in questo archivio tutte le informazioni utili al processo di valutazione e trattamento del rischio aziendale e conseguentemente la cura prestata alla sua manutenzione deve essere massima. Ad esempio, consideriamo la ciclica esigenza di una puntuale e attenta attribuzione delle responsabilità, alla continua accuratezza negli aggiornamenti del contesto analizzato, all’ottimizzazione degli indicatori di performance, di rischio, di maturità, alla necessaria condivisione dei contenuti per accrescere la sensibilità verso i temi del rischio oppure alla ricerca di semplificazione per una maggior chiarezza nella comunicazione. In altre parole, si cerca sempre di migliorare e quindi di creare del nuovo valore aggiunto.

Una nuova fronte di miglioramento può essere trovata esaminando la completezza delle informazioni incluse nello scenario di rischio. Nel caso degli scenari di rischio per l’IT (ma non solo), deve essere inclusa stabilmente la classificazione del dato in quanto fattore interno di rischio. Non è un’ulteriore dato da gestire ma una precisa serie di obiettivi da rispettare, che necessitano di ricevere una adeguata attenzione organizzativa.

Spesso, la classificazione del dato è esposta a livello di policy ma senza una chiara attribuzione operativa mentre, altre volte, è a livello operativo ma senza un chiaro riferimento agli obiettivi di business. Per fornire evidenza sia dell’allineamento con gli obiettivi che del collegamento con i controlli, la giusta collocazione è nel registro dei rischi. Questa soluzione può essere praticamente implementata senza appesantire lo scenario di rischio, aiutando anche il controllo interno a trovare la giusta soluzione per la classificazione dei dati.

Registro del rischio

Il registro del rischio è assimilabile ad una tabella relazionale fatta da campi chiave e campi attributo. I campi chiave identificano uno scenario di rischio per un asset (dominio di identificazione del rischio), mentre i rimanenti campi sono quelli che lo qualificano (dominio di valutazione del rischio) e ne stabiliscono il trattamento (dominio della risposta al rischio). Ogni singola registrazione è identificata da una chiave univoca (figura 1) definita da tre elementi principali correlati tra loro: l’evento di rischio (ovvero le condizioni del verificarsi della minaccia), la risorsa (ovvero il bene materiale o immateriale, o suo componente, da proteggere dal rischio) e la minaccia (ovvero la causa potenziale del rischio, interno o esterno).

La minaccia (o un insieme di minacce) è identificata in funzione del bene da proteggere. Più precisamente è una combinazione di fattori di rischio ben noti con la sigla SWOT che sta per forza, debolezza, opportunità e minaccia. Non è necessariamente una causa negativa, potrebbe anche essere un’opportunità da cogliere. L’evento di rischio è in funzione dei fattori di rischio, esterni od interni, che possono verificarsi. E’ qualificato durante le fasi di valutazione, di controllo, di audit o come input del management. La minaccia è contro una risorsa che è sicuramente importante per gli obiettivi aziendali, altrimenti non sarebbe in questo contesto.

Questi elementi sono in sostanza rappresentati da tre liste, i cui membri posso aumentare o diminuire in funzione delle analisi di contesto che vengono periodicamente effettuate. In modo ciclico, combinando un elemento da ciascuna lista, aggiungendo parametri obiettivo, descrizioni, valutazioni di indicatori, si viene a creare un record completo detto “scenario di rischio”. La valorizzazione dello scenario con lo stato corrente e con i controlli per raggiungere lo stato desiderato è il compito del processo di risk management dell’azienda.

L’importanza del processo di gestione del registro del rischio è reso evidente dai passi che compie nel suo ciclo di funzionamento. Parte dagli obiettivi di business, identifica le possibili cause di incertezza, include le misure di risposta, raccoglie l’esito dei controlli e comunica il tutto al top management per le conseguenti decisioni (basate sul rischio). Poi, riparte il ciclo di gestione del rischio con i nuovi indirizzi del top management. Il top management interviene anche a definire la soglia di accettazione del rischio affinché sia in linea con gli obiettivi aziendali.

Il comportamento del processo di gestione del registro del rischio presenta delle analogie con quello della classificazione dei dati. La classificazione dei dati definisce la soglia oltre la quale emergerà un danno inevitabile all’azienda ed inoltre è approvata dal top management. Da questa considerazione risulta intuitivo collocare la classificazione dei dati nel “risk register”, in quanto, la classificazione definisce un obiettivo di protezione con necessità di approvazione del top management, per impegnare le risorse a protezione del bene stesso e con la finalità di ottimizzare il valore del bene per l’azienda. È un parallelismo con alcune situazioni che si riscontrano nel ciclo di gestione del rischio. La classificazione dei dati trova la sua sede naturale in questo registro.

Per quanto importante possa essere, un processo operativo non potrà decidere sull’obiettivo di protezione del dato. Ad esempio, il processo ICT gestisce l’elaborazione e la conservazione dei dati di fatturazione ma non è l’owner del dato. Il processo di contabilità è presumibilmente l’owner del dato ma non decide sulla durata di conservazione, su questo interviene una regolamentazione di legge. In ogni caso, anche ammesso che la contabilità suggerisca l’azione più corretta, sarà comunque chi risponde degli obiettivi aziendali a decidere se approvare o meno su qualsivoglia questione con impatto sugli obiettivi stessi.

Classificazione dei dati

Dopo che il top management ha definito l’obiettivo di protezione di un bene aziendale, sarà compito di un processo operativo agire affinché tale obiettivo sia salvaguardato per tutta la durata della vita del bene stesso. Questa attività di protezione dovrà essere eseguita nel modo più efficace ed efficiente possibile. Da qui la necessità di accedere ad un quadro di riferimento del contesto esaustivo (valore obiettivo), inclusivo anche dei valori di classificazione dei dati, da comparare con la valutazione delle prestazioni raggiunte dal controllo operativo (valore misurato). Il mancato rispetto della classificazione dei dati ha una forte rilevanza sia sulla valutazione d’impatto che sulla probabilità di accadimento dell’evento di rischio.

Non ultimo passo, ma in sequenza temporale seguente all’implementazione dei controlli, il processo di audit deve assicurare che le attività siano in linea con gli obiettivi. Per la valutazione di conformità è fondamentale avere sempre un facile e pieno accesso ai requisiti implementativi, obiettivi inclusi. Il vantaggio di poterli avere tutti in un unico documento, qual è il “risk register”, è duplice. E’ sicuramente agevole perché il documento è redatto secondo regole che impongono la semplicità narrativa per favorire la comunicazione ed inoltre, ciclicamente, è soggetto alla revisione di direzione che garantisce l’allineamento agli obiettivi aziendali.

Includendo la classificazione del dato nel “risk register” miglioriamo diverse fasi del processo di risk management. Ad esempio, osserviamo che la classificazione del dato è un parametro utilizzato come fattore di rischio interno, contribuisce a migliorare la valutazione di impatto e probabilità, permette di indirizzare il design dei controlli, fornisce un elemento di riferimento per gli audit ed è adoperabile nella revisione di direzione.

Considerata l’utilità, rimane da definire praticamente come gestire la classificazione dei dati nel registro dei rischio aziendale. Per rendere l’informazione facilmente utilizzabile in questo contesto, è necessario gestire solamente pochi elementi di numero ed inoltre per essere efficaci, vanno ricercati in modo da risultare chiaramente comprensibili sia a posizioni manageriali che operative.

Il registro dei rischio aziendale è un documento trasversale all’intera organizzazione. La direzione aziendale inizializza i parametri di allineamento agli obiettivi di business e gli operativi aggiornano conseguentemente i controlli. Pertanto, deve avere una struttura semplice e l’eventuale eccesso di dettaglio deve essere demandato ad un altro documento. Lo strumento idoneo a ricevere il dettaglio, necessario ad una corretta valutazione di impatto e probabilità, nel caso della continuità operativa, è la business impact analisi (BIA).³ Questo documento è una pietra miliare dell’azienda e probabilmente, in molte organizzazioni, non sarà necessario aggiungere altri documenti di dettaglio.

La continuità operativa rappresenta la maggioranza dei record presenti nel registro e il suo documento di riferimento è la BIA. La BIA ha necessità di essere allineata agli obiettivi di business e può realizzare ciò per tramite del legame che si crea per tramite del comune scenario di rischio, condividendo quello già definito nel registro ed evitando così duplicazioni. Anche i record del registro relativi al puro raggiungimento di una performance specifica (es. ambito finanziario) sono indirettamente legati alla continuità operativa. Nell’analisi di impatto della continuità operativa, per completezza, ci saranno da considerare anche le conseguenze imputabili a questi record, evitando a questi un’inutile ricorso a dettagli di carattere operativo.

Lo scenario di rischio è rappresentato da un record descrittivo di un bene o un processo o più probabilmente da una categoria ove tutti gli elementi hanno analoghi requisiti di sicurezza. Nel caso di un bene con una sua specifica necessità di un dettaglio diverso dalla norma, si può generare un nuovo record per duplicazione di una singola istanza.

Ad esempio, la categoria generica “firewall” avrà un suo scenario definito qualitativamente come riferimento standard delle misure di protezione comuni a tutti i firewall, ossia una baseline di sicurezza per tutti gli elementi rappresentati in quella categoria. Se uno di questi è installato in una zona che richiede una misura di protezione non contemplata dalla baseline di sicurezza, allora si crea una nuova istanza per i requisiti aggiuntivi. Se cambia lo scenario di rischio, si duplica il record standard del registro del rischio e sul nuovo record si aggiungono i nuovi requisiti. Se cambia solo l’attività operativa necessaria a soddisfare una valutazione più stringente, si duplica il record corrispondente nella BIA e si modificano i valori di dettaglio specifici per gestire questa eccezione.

Terna di sicurezza informatica (terna CIA)

L’eventuale livello di sicurezza richiesto alle informazioni stabilisce il loro obiettivo di protezione ed è consuetudine ricorrere alla terna identificata dall’acronimo CIA che sta per confidenzialità, integrità e disponibilità.⁴

Il primo passo è decidere dove inserire la triade CIA nel registro. Il record dello scenario di rischio è generalmente letto da sinistra a destra, la triade di sicurezza può essere posta prima dei campi di impatto e probabilità usati per l’analisi del rischio (figura 2). Questa posizione serve ad assicurare la conoscenza dei vincoli di sicurezza stabiliti, prima di procedere con la stima dell’impatto e della probabilità. È evidente che questa informazione aggiuntiva riesce a migliorare la percezione delle conseguenza nel caso di un mancato raggiungimento dell’obiettivo di protezione.

Al fine di una gestione efficace della terna CIA è importante definire come trattare i suoi tre parametri e quali livelli usare. Per un uso agevole, sia per definire l’obiettivo sia per comprenderlo, dobbiamo operare con un basso numero di livelli per ogni parametro, selezionando solo quelli con la migliore capacità di sintetizzare con chiarezza i concetti. Questo è il lavoro esposto dei prossimi paragrafi. Anche se probabilmente non sarà possibile trovare un stesso insieme che sia idoneo per tutte le organizzazioni, sarà però possibile usarlo come base di partenza per tutte quelle che devono affrontare situazioni particolari non contemplate qui.

Confidenzialità
Il primo parametro è la confidenzialità. Esprime l’insieme dei soggetti autorizzati ad accedere all’informazione e le modalità permesse alla sua circolazione. La metrica scelta per l’obiettivo di confidenzialità deve saper fornire un valore di riservatezza del dato e contemporaneamente definire il limite imposto alla sua comunicazione ad altri soggetti. Si può sintetizzare con quattro livelli qualitativ (figura 3).

Pubblico è un dato senza barriere e senza possibilità di nuocere all’organizzazione. Tipicamente è il dato che troviamo sui siti Internet senza necessità alcuna di accesso con autenticazione. È pertanto sbagliato applicare regole su questa categoria perché è stato posto fuori dal controllo dell’organizzazione. Quindi, la diffusione di queste informazioni non deve richiedere alcuna autorizzazione e non può implicare alcuna conseguenza.

Interno è un dato a libera circolazione ma solo entro i confini aziendali o altri soggetti formalmente autorizzati. Tipicamente è il dato che troviamo sulle bacheche aziendali. È quella tipologia di dato che chiunque in azienda può consultare liberamente ma ne viene vietata la comunicazione all’esterno del perimetro aziendale, se non diversamente autorizzati. Nel caso si verifichi un’esposizione esterna non autorizzata, l’impatto sugli obiettivi di business è ragionevolmente limitato.

Confidenziale è un dato che richiede un sistema di identificazione e filtraggio dei soggetti che accedono all’informazione. Tipicamente è il dato che troviamo nei meeting ristretti ad un ben preciso elenco di invitati. È necessario essere dotati di credenziali autorizzate dall’owner del dato per avere accesso. Se fosse esposto esternamente all’insieme dei soggetti autorizzati potrebbe causare effetti negativi agli obiettivi o all’immagine aziendale.

Riservato è un dato per una ristretta cerchia di soggetti e la circolazione tra essi è tracciata. Tipicamente è l’informazione che troviamo nell’ambito della ricerca e sviluppo, quello che rappresenta il vantaggio competitivo tecnologico. I requisiti non sono solo autenticazione forte per l’accesso ma anche necessità di un canale di comunicazione sicuro. Se fosse esposto esternamente all’insieme dei soggetti autorizzati potrebbe compromettere il raggiungimento degli obiettivi o addirittura provocare seri problemi legali.

Solo nel caso si rendesse realmente necessario, si può aggiungere un livello opzionale estremo per descrivere la situazione di un’informazione priva di circolazione, tranne il trattamento effettuato dal suo legittimo proprietario. È il caso di una richiesta di conservazione sicura senza alcun trattamento fatto da persone. Ad esempio, le credenziali di autenticazione, una nuova formula chimica non brevettata oppure le chiavi crittografiche usate nei sistemi di comunicazione. Se l’informazione fosse impropriamente esposta creerebbe una pericolosa breccia nel sistema di sicurezza fino alla compromissione del business.

Integrità
Il secondo parametro è l’integrità. Esprime il livello di protezione dell’informazione rispetto alla modifica non autorizzata. La metrica scelta deve saper fornire una valutazione delle possibilità di alterazione del dato. Si può sintetizzare con tre livelli qualitativi (figura 4) associati alle diverse tipologie di controllo delle modifiche.

Il primo livello è la garanzia del riconoscimento dell’identità dell’autore prima della modifica. È richiesto un meccanismo di controllo accessi al dato che si attua verificando le credenziali di autenticazione del soggetto che sta accedendo. Solo alle utenze autorizzate viene consentita la modifica. Il meccanismo prescelto per l’identificazione dell’identità è descritto nelle linee guida della sicurezza informatica. Da un punto di vista organizzativo, sono attese almeno due regole. Le autorizzazioni di accesso agli utenti sono soggette a revisione periodica e viene erogata l’opportuna formazione per responsabilizzare gli utenti sull’uso e conservazione delle credenziali di autenticazione.

Il secondo livello è la garanzia della capacità di riconoscimento di alterazioni non autorizzate del dato. È richiesto, nell’operazione di modifica, la registrazione automatica di informazioni aggiuntive per poter identificare in seguito eventuali cambiamenti illegali del dato originale (quello autorizzato), ad esempio mediante un hash o un checksum. In alternativa, garantire la ridondanza registrando una copia in un ambiente non violabile da soggetti indesiderati. La scelta del meccanismo di protezione sarà definita nell’ambito della BIA per assicurare una soluzione che massimizzi il valore rispetto agli obiettivi.

Il terzo livello è la garanzia che l’autore del dato non possa negare la paternità e la validità della modifica effettuata. È richiesto un processo che garantisca entrambi gli aspetti, ossia che solo i soggetti autorizzati e ben identificati possano accedere in modifica e che non ci sia la possibilità di alterare il dato senza lasciare traccia di ciò. La scelta della soluzione non è facile. È sicuramente onerosa perché per la tematica della terza parte di fiducia (TTP) digitale non è stata ancora individuata una soluzione di riferimento che sia semplice, economica e realisticamente affidabile. Se richiesto, bisognerà affidarsi a meccanismi di autenticazione forte e sistemi di crittografia a chiave pubblica o l’uso delle blockchain.

Esiste, come opzione, un livello estremo. Il dato, dopo essere stato generato, non potrà più subire alcuna modifica. È richiesta la garanzia assoluta che il valore originale non potrà essere cambiato dopo la sua generazione. Ad esempio, è il caso di una memoria ROM o di un supporto ottico non riscrivibile.

Disponibilità
Il terzo parametro della CIA è la disponibilità. Garantisce l’accessibilità all’informazione da parte dei legittimi utilizzatori nel momento in cui lo richiedono. La metrica scelta deve saper fornire un valore di disponibilità della risorsa, nel rispetto di tempi predefiniti od eventuali perdite ammissibili dei dati. Si può sintetizzare con tre livelli qualitativi (figura 5) legati alla capacità di reazione ed alla tollerabilità della perdita.

Questo è un parametro fortemente legato alla continuità operativa e può gestire anche risorse di tipo servizio oppure sistemi e non solo. Rispetto agli altri parametri di classificazione dei dati precedentemente visti, la definizione dell’obiettivo di disponibilità fatta in modo generico, è più complicata perché spesso richiede dei dati puntuali e le dichiarazioni qualitative non sono sempre sufficientemente esaustive. Inoltre, nel “risk register” è sempre preferibile, per quando possibile, utilizzare categorie di asset anziché asset puntuali, questo perché aumenta la leggibilità da parte del top management.

Per non perdere questi benefici, è sufficiente ricorrere ad un altro documento per i dettagli, ad esempio la BIA. La BIA nasce come documento di approfondimento per l’analisi degli impatti agli obiettivi di business e conserva tutti i valori caratteristici di ogni asset rilevante. È importante però assicurare sempre il collegamento tra il record di dettaglio dell’impatto della BIA ed il suo riferimento nel risk register per garantire la coerenza ed evitare inutili ridondanze di informazioni.

Livello baseline
Corrisponde alle misure normalmente assicurate quando i vincoli di continuità ed i livelli di rischio operativo sono ritenuti accettabili. Fa riferimento alle misure di protezione generali descritte nelle policy di sicurezza ed integrate con procedure per le misure operative. La baseline rappresenta l’insieme delle normali misure messe in atto per assicurare i livelli minimi di continuità, attesi in condizioni prive di ripercussioni particolarmente gravi, nel caso si verifichino incidenti.

Livello significativo
Corrisponde ad ulteriori misure applicate rispetto a quelle definite nella baseline, quando i vincoli di continuità ed il rischio operativo sono significativi si richiede una attenzione superiore alle misure convenzionali. In questa situazione, verosimilmente, si stabiliscono degli indicatori di continuità⁵ nella BIA quali, ad esempio, il Maximum Tolerable Downtime (MTD) ed il Recovery Point Objective (RPO). Questi valori dovrebbero richiedere delle azioni aggiuntive rispetto alla norma ma comunque non particolarmente impegnative od onerose da attuarsi e le conseguenze di eventuali mancanze potrebbero essere gravi ma non critiche.

Livello impegnativo
Corrisponde alle misure più gravose da applicare quando i vincoli di continuità sono vitali e le condizioni di rischio per assicurare l’operatività sono fortemente avverse. L’alta criticità nel rispettare gli elevati parametri di disponibilità per la continuità operativa richiede un notevole sforzo ed, in caso negativo, ci saranno conseguenze estremamente severe. Questa è una situazione dove un mancato controllo od una errata valutazione di un KPI nei processi critici, devono essere classificati come incidenti e non come una banale diminuzione di performance.

Livello ininterrotto
Ci potrebbe essere l’esigenza di inserire un ulteriore opzione, come limite superiore, nel caso di un sistema con un vincolo di continuità senza possibilità alcuna di interruzione o perdita di dati e, nel caso si verifichi, comporterà il fallimento dell’intera organizzazione. Ad esempio, un sistema di navigazione aerea, un sistema di allarme di fuga radioattiva ma anche il sensore temperatura del forno cucinando una torta. Questa situazione richiederà un’attenta analisi di rischio e tra le conseguenti contromisure ci sarà un ridondanza sui componenti critici per permettere la continuità in situazioni avverse ed assicurare l’assenza di perdite di dato. L’attesa è anche di dover affrontare costi significativi ma giustificati dall’analisi rischio che fornisce gli elementi per decidere tra l’ammissibilità del rischio oppure la mitigazione del rischio.

Protezione del dato personale

La terna CIA può sembrare sufficiente a stabilire la corretta classificazione del dato ma la rilevanza assunta negli ultimi anni dalla protezione del dato personale richiede un’attenta riflessione. Va rimarcato che, nei Paesi ove è in vigore la protezione del dato personale, questo è un requisito obbligatorio di legge e non certo solamente un requisito derivato da una policy interna. Questo fa capire che non può essere oggetto di giudizio da parte dell’organizzazione, le regole generali le impone la legge. Essendo la protezione del dato personale un fattore di rischio esterno, è d’obbligo gestirlo nel registro dei rischi aziendali. Inoltre, poiché è obbligatorio trattarlo, la sola risposta possibile a questo rischio è mitigare il rischio.

Questa diversa rilevanza rispetto ad un obiettivo interno si traduce in una particolare necessità di enfasi su questa tematica. Possiamo gestirla con un parametro aggiuntivo alla terna CIA e dedicarlo in via esclusiva alla privacy stessa (figura 6). L’obiettivo di protezione del dato di tipo personale viene stabilito scegliendo tra due possibili valori legati ai differenti trattamenti di legge richiesti (figura 7).

Informazioni di identificazione personale
Informazioni di identificazione personale (PII)⁶ o combinazione di esse, che consente l’identificazione della persona ma, se non associata ad ulteriori informazioni, non permette di conoscere altre caratteristiche personali. Ad esempio, queste includono, particolarità fisiche, stile di vita, preferenze, convinzioni ma anche geolocalizzazione nel tempo o attività in rete oppure profilazione o stato di salute. Si intende la sola identificazione della persona, in uno specifico contesto, senza riuscire ad aggiungere ulteriore conoscenza sulle caratteristiche della persona. La classificazione a livello di confidenzialità è interna o riservata.

Informazioni personali sensibili
Informazioni personali sensibili (SPI)⁷ consiste nell’identificazione della persona ed in attributi aggiuntivi che in un qualche modo possono avere un impatto significativo per l’interessato. Questi dati particolari, che caratterizzano la persona, sono oggetto di maggior tutela da parte della legge perché potenzialmente possono arrecare un danno all’interessato in funzione del contesto nel quale sono esposti. Particolare attenzione va posta quando dati diversi, singolarmente privi di un valore apparente, vengono combinati tra loro per comporre una nuova informazione con interesse di carattere personale, ad esempio, come risposta ad una interrogazione. La correlazione temporanea di dati anonimi può creare un’informazione sensibile ed il relativo processo deve essere classificato. La classificazione di confidenzialità è pari a limitata.

Trattamento di legge obbligatorio
I dati personali possono anche essere protetti dalla legge. Consideriamo, ad esempio, una richiesta di legge per un trattamento specifico a seguito di una violazione, come nel caso di un data breach. Come conseguenza potremmo subire il sequestro di un sistema oppure dover conservare una copia forense o altro con vincoli che impattano anche sui dati personali inclusi. E’ probabilmente uno stato temporaneo ma deve essere gestito con regole diverse da quelle attese per gli stati PII o SPI e quindi potrebbe richiedere una diversa classificazione.

La determinazione dell’esatta classificazione sarà identificata a seguito della valutazione d’impatto sulla protezione dei dati personali (DPIA),⁸ fortemente consigliata anche quando non risulta obbligo di legge (previsto in caso di rischio elevato). Operativamente, la DPIA potrebbe essere ricavata con facilità come sottoinsieme della BIA.⁹ Rispetto ad un dato non personale, in questa analisi si deve considerare anche l’impatto per i propri sistemi informativi in conseguenza all’esercizio dei diritti di legge del soggetto interessato. E.g. diritto alla rettifica o alla cancellazione, diritto all’accesso, diritto alla portabilità e così via che ovviamente comportano azioni specifiche e oneri aggiuntivi da includere nell’analisi di rischio.

Conclusioni

Ritenere la classificazione dei dati un mero passaggio obbligatorio per compilare delle tabelle è una prospettiva che difficilmente farà cogliere l’utilità e necessità di questo processo. Per un organizzazione, la classificazione dei dati, è la bussola che orienta correttamente il proprio sistema di sicurezza delle informazioni. È un processo che deve essere costruito sotto la direzione del top management (garanzia di allineamento agli obiettivi di business) e quindi, le componenti di questo processo devono essere maneggevoli ed intuibili. Il miglior strumento è il registro dei rischi aziendali che già esiste ed utilizza le stesse interconnessioni richieste dalla classificazione dati.

In alternativa, creare un processo nuovo ha poco senso perché non segue la direzione del miglioramento per semplificazione dei processi interni. Secondo la metodologia Agile la strada da intraprendere è di iniziare con quanto abbiamo e poi perfezionare ciclicamente nel tempo. Meglio quindi riutilizzare ciò che già abbiamo ma accrescendone il valore con la giusta attenzione per non eccedere nella complessità. Quello che nel registro dei rischi non può essere stabilito a livello aggregato o per categoria, può essere spostato in un diverso documento di maggior dettaglio, e.g. la BIA.

Nei parametri di classificazione dei dati rientrerà anche la privacy per migliorare la qualità dello scenario complessivo del rischio aziendale, utile ad una più corretta valutazione di impatto e probabilità. Ulteriormente, utilizzando il registro dei rischi abbiamo l’evidenza del coinvolgimento del top management nel definire i criteri guida per la pianificazione della continuità del business. Questo semplifica l’attività di auditing dell’assegnazione delle responsabilità durante la valutazione del riesame di direzione. Inoltre, l’avere più tipologie di informazioni interconnesse tra loro in uno stesso documento consente un più agile (e puntuale) aggiornamento.

Endnotes

¹ ISACA^®, CRISC^® Review Manual 6^th Edition, USA, 2015, https://www.isaca.org/resources
² Ibid.
³ International Organization for Standardization (ISO), Technical Specification (TS) ISO/TS 22317:2015 Societal security—Business continuity management systems—Guidelines for business impact analysis (BIA), Switzerland, 2015, https://www.iso.org/standard/50054.html
⁴ International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 27000:2018 Information technology—Security techniques—Information security management systems—Overview and vocabulary, Switzerland, 2018, https://www.iso.org/standard/73906.html
⁵ Swanson, M.; P. Bowen; A. W. Phillips; D. Gallup; D. Lynes; Contingency Planning Guide for Federal Information Systems, Special Publication (SP) 800-34 Rev.1, National Institute of Standards and Technology (NIST), USA, May 2010, https://csrc.nist.gov/publications/detail/sp/800-34/rev-1/final
⁶ McCallister, E.; T. Grance; K. Scarfone; Guide to Protecting the Confidentiality of Personally Identifiable Information (PII), Special Publication (SP) 800-122, National Institute of Standards and Technology (NIST), USA, April 2010, https://csrc.nist.gov/publications/detail/sp/800-122/final
⁷ Northeastern University Office of Information Security, Boston, Massachusetts, USA, “What Is Sensitive Personal Identifying Information (PII)?” SecureNU
⁸ European Commission Article 29 Working Party, “Guidelines on Data Protection Impact Assessment (DPIA) (wp248rev.01),” Belgium, 2017, http://ec.europa.eu/newsroom/document.cfm?doc_id=44137
⁹ Sbriz, L.; “Enterprise Risk Monitoring Methodology, Part 1,” ISACA^® Journal, vol. 2, 2019, https://www.isaca.org/archives

Luigi Sbriz, CISM, CRISC, CDPSE, CSF NIST Specialist, ISO/IEC 27001:2013 LA, ITIL v4, UNI 11697:2017 DPO

È il responsabile del monitoraggio dei rischi presso un’azienda multinazionale del settore automotive da oltre cinque anni. In precedenza, è stato responsabile della gestione dei servizi e delle risorse ICT nell’area Asia-Pacific (Cina, Giappone e Malesia) e, prima ancora, è stato responsabile della sicurezza delle informazioni a livello mondo per più di sette anni. Per quanto attiene al monitoraggio interno del rischio, ha sviluppato una metodologia originale unendo un’analisi del rischio operativo con una conseguente valutazione del rischio guidata dal livello di maturità dei processi. Inoltre, ha progettato uno strumento di cyber monitoring e un sistema integrato per monitoraggio del rischio, modello di maturità e audit interno. Sbriz è stato anche consulente per sistemi di business intelligence per parecchi anni. Può essere contattato su LinkedIn (https://it.linkedin.com/in/luigisbriz) oppure su http://sbriz.tel