La definizione di sicurezza informatica e le linee guida per proteggere i dati sensibili

La sicurezza informatica è quella disciplina che si prefigge l’obiettivo di mantenere inalterato il valore degli asset informatici custoditi all’interno di un sistema informatico contro le minacce cibernetiche, soprattutto quando si parla di informazione o dato, sia esso personale che aziendale. In questo articolo vediamo cos’è la sicurezza informatica ed esaminiamo la norma ISO/IEC 27001 che definisce i requisiti per impostare e gestire un Sistema di gestione della Sicurezza delle Informazioni.

articolo a cura di Chiara Ponti e Renato Castroreale

Sicurezza informatica: che cos’è

La sicurezza informatica (in inglese information security) o sicurezza delle informazioni, è l’insieme dei mezzi e delle tecnologie tese alla protezione dei sistemi informatici in termini di disponibilità, confidenzialità (riservatezza) ed integrità. Per sistemi informatici si intendono tutti quei beni, o asset informatici, coinvolti nel trattamento delle informazioni.

La sicurezza informatica si concretizza nel lavoro incessante di sicurezza dell’informazione, perché è il bene digitale più prezioso.
L’informazione, ovvero l’insieme di dati che la compongono, è centrale in un sistema informatico in quanto è motivo della sua esistenza, dalla progettazione allo sviluppo e manutenzione. L’informazione è, per definizione, conoscenza, quindi deve avere un valore per il singolo tanto quanto per diversi individui, siano essi organizzati o meno.

Sicurezza delle informazioni: la norma ISO/IEC 27001

La certificazione ISO/IEC 27001 (Tecnologia delle Informazioni – Tecniche di Sicurezza – Sistemi di Gestione della Sicurezza delle Informazioni – Requisiti) è una Norma Internazionale che definisce i requisiti per impostare e gestire un Sistema di gestione della Sicurezza delle Informazioni (SGSI o ISMS, dall’inglese Information Security Management System); il Sistema include aspetti relativi alla sicurezza logica, fisica ed organizzativa.

Sicurezza informatica: come rispondere ai requisisti della norma ISO/IEC 27001

Per rispondere pienamente ai requisiti della norma ISO/IEC 27001, occorre un approccio completo che includa sia gli aspetti tecnici, ma ancor prima quelli organizzativi.
Chi recepisce quindi la visione limitata, che prevede che per implementare la sicurezza (anche in ambito privacy) occorra pensare solo agli strumenti, sbaglia di grosso.
Non può essere implementato un sistema per la sicurezza delle informazioni, se questi aspetti non sono stati ben considerati. Un sistema di sicurezza basato solo sulla tecnologia, non evolve, non è in grado di attivare il ciclo virtuoso di miglioramento continuo, venendo meno anche l’aspetto fondamentale del fattore umano ed organizzativo.

Lo schema High Level Structure

In tutte le norme ISO, che ormai seguono la struttura unificata HLS o High Level Structure, i primi aspetti che vengono trattati sono quelli di contesto e quelli organizzativi.
Lo schema HLS, rammentiamo, ha introdotto una standardizzazione dei contenuti delle norme ISO, a beneficio della loro comprensione ed integrazione.
Questo schema prevede la suddivisione della norma in dieci punti, che sono:
1)    scopo;
2)    normative di riferimento;
3)    termini e definizioni;
4)    contesto dell’organizzazione;
5)    leadership;
6)    pianificazione;
7)    supporto;
8)    operation;
9)    valutazione delle performance;
10)  Implementazione.

Senza commentare i singoli punti, appare lapalissiano come gli aspetti organizzativi siano, ancor più di quelli tecnici, considerati dalla norma.
Tutto tende a far comprendere come gli aspetti umani, gli aspetti organizzativi, siano elemento fondante per il raggiungimento degli obiettivi posti dall’adozione di un modello di gestione, che nel nostro caso è quello relativo alla sicurezza delle informazioni (anche in ottica di privacy).

Linee Guida per attuare la sicurezza informatica

Definire una linea guida per l’attuazione della Sicurezza Informatica in un semplice articolo è cosa alquanto difficile; cercheremo quindi di trattare brevemente quegli elementi che ne contraddistinguono maggiormente la sua implementazione.
Volendo quindi riassumere i passaggi più importanti della realizzazione di un modello per la Sicurezza delle Informazioni, ci si potrebbe soffermare su:

1. l’Analisi del Contesto;
2. l’Approccio Risk Based;
3. la Valutazione dei Rischi
4. I Controlli
5. il Sistema Documentale;
6. il Miglioramento Continuo

Sicurezza informatica: l’analisi del Contesto

Innanzitutto, l’organizzazione deve implementare alcuni passaggi essenziali di analisi dell’organizzazione e del contesto nel quale essa opera; comprendere le necessità e le aspettative delle parti interessate.
Tale analisi deve considerare tutti i fattori, inclusi ovviamente quelli relativi alle norme vigenti/cogenti.
Tutto questo si rende necessario per fornire il giusto indirizzo al sistema di gestione per la sicurezza delle informazioni e ad eventuali altri schemi integrati.
Come controparte di questa analisi occorre determinare e misurare i fattori di incertezza che possono influire sull’attività dell’organizzazione. Nel farlo ricordiamoci sempre di abbracciare tutto lo spettro di possibili elementi che possono influire in qualsiasi ambito.
Ad esempio, in una situazione di emergenza come la pandemia da covid-19, che ha introdotto moltissime incertezze, occorre senz’altro prendere in considerazione tutti questi aspetti.
Insomma, a seconda del momento storico, la vita dell’organizzazione può essere influenza da molteplici fattori interni ed esterni, che se non sono ben compresi possono rendere inefficace l’obiettivo di Sicurezza delle Informazioni.

L’approccio Risk Based

L’approccio risk based è basato sull’assunzione che il processo di gestione dei rischi e delle opportunità (che descriveremo tra poco) diventi fondamentale per indirizzare le scelte dell’organizzazione.
Quando si parla di gestione del rischio non si può non citare la ISO/IEC 31000 “Gestione del rischio – Principi e linee guida”, che si pone appunto l’obiettivo di fornire indicazioni su come implementarne un modello di gestione.
La norma definisce il rischio come “effetto dell’incertezza sugli obiettivi”, precisando che tale effetto può essere sia positivo (rischio) che negativo (opportunità).
L’approccio risk based è quindi un cambio radicale che impatta su tutta l’organizzazione e stravolge il normale modo di pensare.

I rischi correlati alla sicurezza delle informazioni

Spesso nelle organizzazioni quando ad esempio si deve decidere l’acquisto di uno strumento software (o di qualsiasi altra natura), si effettua una selezione basandosi sulle referenze del fornitore e del prodotto stesso, sul prezzo della soluzione, sulle sue funzioni, ma quasi mai si analizzano i rischi correlati alla sicurezza delle informazioni e/o alla privacy.

Questo modo di pensare, e di conseguenza di agire, porta spesso all’acquisto di soluzioni sicuramente ottime ed economiche, ma che non sono in grado di garantire caratteristiche di sicurezza adeguate o addirittura basilari.
Questo capita perché spesso si sottovaluta la questione e si pensa ad un incidente di sicurezza (o peggio ad un data breach), come ad uno spiacevole inconveniente che viene archiviato nel giro di poche ore. Ma non è così!
Un incidente di sicurezza può mettere l’organizzazione in grado di non poter sostenere il danno subito, l’organizzazione può perdere irrimediabilmente la sua immagine, insomma può essere costretta a chiudere le sue attività.
E tutto questo può capitare semplicemente per non aver correttamente considerato il rischio.

La Gestione dei Rischi e l’approccio Risk Based

La ISO/IEC 31000 identifica diversi momenti nel flusso di Gestione del rischio o Risk Management, ma nella nostra volontà di semplificare i concetti al fine di renderli più comprensibili, ne segnaliamo solamente due:

1. risk assessment (individuazione e valutazione dei rischi);
2. risk treatment (il trattamento dei rischi).

A sua volta il risk assessment e scomponibile in tre differenti fasi:

1. l’identificazione dei rischi – risk identification;
2. l’analisi dei rischi – risk analysis;
3. la valutazione dei rischi – risk evaluation.

La traduzione dei termini inglesi esposti nello schema, lascia spesso adito a diverse interpretazioni, ed in effetti le differenze tra i vari passaggi possono essere assai sottili.

Risk Assessment

Spesso, inoltre ci si concentra solo sulla risk analysis e sulla risk evaluation, trascurando la fase di risk identification. Questo capita perché, il primo punto richiede maggiore sforzo e partecipazione per essere attuato con successo. Nell’identificazione dei rischi è difatti essenziale avere come input il risultato di una analisi dettagliata del contesto nel quale opera l’organizzazione.

La risk identification

La risk identification richiede inoltre che siano coinvolti tutti quei settori dell’organizzazione che per esperienza e capacità possono fornire elementi di rilievo. Ad esempio, tutti i rischi relativi alla sicurezza fisica ed ambientale, possono essere identificati con successo solo da chi quotidianamente ha a che fare con questi fattori, e via discorrendo.

Una volta ottenute tutte le informazioni possibili, occorre ragionare per impostare i dati necessari su un modello di calcolo che ci consenta di avere infine una valutazione, per quanto possibile oggettiva e non soggettiva, che consenta di misurare il rischio (tipicamente un valore numerico in una scala definita).

La prima volta che partecipammo ad un corso ISO/IEC 31000, ci colpì molto l’affermazione che un Risk Assessment doveva dare sempre lo stesso risultato, a prescindere da chi lo effettua.
Francamente ancora oggi abbiamo difficoltà nell’accettare questa affermazione, perché la fase di valutazione dipende da quella di identificazione, che è per sua natura molto soggettiva, e perché la stessa valutazione ha degli elementi di valutazione che richiedono una scelta parte di chi la esegue. Siamo quindi certi che un buon sistema possa dare risultato simili, ma non certo identici.

Per ottenere un valore del rischio occorre un modello che riesca, dati in input tutte le variabili raccolte, ottenere un risultato numerico che rappresento il rischio in una determinata scala (ma di questo parleremo al capitolo seguente).

Le soglie di accettabilità

Quello che occorrerà fare è anche, a seconda del possibile range di rischio derivato dal modello, decidere quelle che si definiscono “soglie di accettabilità”.
Normalmente le soglie sono due, la prima per stabilire quando il rischio richiedere un trattamento e la seconda quando lo stesso presenta un valore inaccettabile. Ad esempio, se la scala di rischio fosse da 1 a 100 si potrebbe dire che un rischio sotto il 30 sia accettabile, da 30 a 60 che il rischio richieda un trattamento per essere ridotto, mentre oltre i 60 si potrebbe affermare che lo stesso non sarebbe assolutamente accettabile.

Nel definire le soglie di accettabilità, ISO/IEC 31000 docet, occorre sempre rapportare il rischio al danno economico per far comprendere più facilmente alla direzione la misura del rischio, ed ottenere la sua attenzione/partecipazione.

Risk Treatment

Una volta che il nostro modello ha terminato un primo ciclo, vedremo sicuramente che qualche rischio necessita di un trattamento, ed occorrerà quindi valutare come procedere.

Le possibili opzioni che possiamo utilizzare, prevedono che il rischio possa essere:

1. eliminato;
2. trasferito;
3. trattato;
4. accettato.

Di seguito analizziamo dunque le varie opzioni.

Eliminazione

L’eliminazione consiste nel non eseguire più quel processo/servizio/trattamento che ha un rischio non accettabile.
Apparentemente questa opzione può sembrare difficile da comprendere, ma in realtà è più semplice di quello che si possa pensare, e supportiamo quindi questa affermazione con un esempio (in ambito privacy, ma lo stesso vale in altri contesti).

Un esempio

Al centralino di una organizzazione, vengono registrati nomi, cognomi e numeri di documenti di identità (carte di identità e/o patenti), su un faldone che nel tempo si va a riempire. Il rischio è quello che qualcuno possa sottrarre il faldone, o comunque accedere anche temporaneamente alle informazioni in esso registrate. Sorge spontanea, dunque, una domanda: a cosa serva questo modo di operare, a cosa serve registrare i numeri dei documenti di identità? Qui prodest? La risposta è semplice, a nulla (come molto sovente accade)! Ed è quindi sufficiente eliminare la registrazione dei documenti, prendendone semplicemente visione sul momento. Ecco come il trattamento dei dati sia stato eliminato (o significativamente modificato), ed il nostro rischio sia sparito con esso.

Trasferimento

Il trasferimento è invece ad esempio l’accensione di una polizza assicurativa.
Immaginiamo che la nostra ipotetica organizzazione abbia sede alle pendici del Vesuvio (nulla di personale verso i napoletani, che anzi adoriamo, ma non è facile trovare esempi di città costruite sulle pendici di un vulcano). Essa presenterà un rischio molto elevato in merito ai disastri naturali. In questo caso l’unica cosa che può decidere di fare l’organizzazione da questo punto di vista (a parte il trasferirsi in un luogo meno rischioso), è quello di assicurassi contro quel tipo di rischio.
In questo modo, in caso di incidente grave, almeno viene scongiurato il rischio di chiusura dell’organizzazione, che incassato il premio della polizza assicurativa potrà riprendere la sua attività.

Trattamento

Il trattamento consiste invece nell’agire attivando nuovi controlli o migliorando l’applicazione di quelli attuati.
Abbiamo potuto valutare nel corso della lettura dei precedenti capitoli, come l’annex A della ISO/IEC 27001, la ISO/IEC 27002 e la ISO/IEC 27701, offrano molti sputi per interventi mirati in ambito della sicurezza delle informazioni e della privacy.
Se questi controlli non risultassero sufficienti, sarebbe possibile stabilirne di nuovi (come prevede la norma) in autonomia.
Aumentando quindi il loro numero, o il loro effetto positivo, la loro applicazione (ed ovviamente dopo avere fatto eseguire una nuova valutazione con i nuovi parametri al nostro modello matematico per la valutazione) è probabile che il rischio si riduca e scenda sotto la soglia di accettabilità.
Se così non fosse si dovrebbe ripetere l’operazione, investendo in quei controlli che possono avere maggiore effetto sul rischio che si sta considerando, fino a raggiungere una situazione accettabile.
Il trattamento è solitamente la metodologia più utilizzata nella gestione dei rischi, al punto che la stessa ISO/IEC 27001 prevede una specifica reportistica (Risk Treatment Plan).

Accettazione

In ultimo il rischio può essere accettato.
Ma avendo definito una soglia di accettabilità, è alquanto “scomodo” effettuare una accettazione se il rischio è oltre la soglia. Chi ha preso la scomoda decisione potrebbe trovarsi a dare spiegazioni, in merito alle sue decisioni.
Il nostro consiglio è quindi quello di coinvolgere la direzione, e pretendere un accantonamento a bilancio a copertura del rischio che si è evidenziato. In questo modo l’organizzazione è da un lato informata del rischio, la stessa decide scientemente di accettarlo, ma pone inoltre in essere una modalità che consenta di recuperare l’evenienza in cui il rischio manifesti il suo effetto negativo.

Rivalutare i rischi

È bene comunque comprendere che tutto il processo di gestione dei rischi, non ha e non deve avere mai fine.
Le simulazioni di scenari ipotetici, effettuate cautelativamente, possono inoltre prevenire spiacevoli scenari.
Il consiglio è quindi quello di ricorrere spesso a rivalutare i rischi, ad esempio prima di ogni cambiamento significativo (acquisto di prodotti/servizi, attivazione di un nuovo fornitore, cambio di uno strumento gestionale, ecc.).
In questo modo il sistema diventa proattivo e ci aiuta ad indirizzare le nostre scelte, includendo il fattore della sicurezza delle informazioni (come peraltro la norma ci chiede di fare) e quello in ambito privacy.
Certo, si tratta di un profondo cambio di mentalità, molto radicale, ma possiamo assicurare che offre notevoli vantaggi.

Sicurezza informatica: i Controlli (Allegato A)

La norma ISO/IEC 27001 fornisce un allegato, contenente 114 preziosi punti di controllo per l’implementazione della sicurezza. In questo tale norma è veramente molto efficace.
Ancor più, la ISO/IEC 27002 commenta questi punti di controllo, e ne fornisce una linea guida per la sua attuazione.
I 144 controlli sono suddivisi in raggruppamenti ed obiettivi, e la tabella sotto riportata li riporta brevemente.

5	Politiche per la sicurezza delle informazioni
5.1	Indirizzi della direzione per la sicurezza delle informazioni
6	Organizzazione della sicurezza delle informazioni
6.1	Organizzazione interna
6.2	Dispositivi portatili e telelavoro
7	sicurezza delle Risorse Umane
7.1	Prima dell’impiego
7.2	Durante l’impiego
7.3	Cessazione e variazione del rapporto di lavoro
8	Asset management
8.1	Responsabilità per gli asset
8.2	Classificazione delle informazioni
8.3	Trattamento dei supporti
9	Controllo accessi
9.1	Requisiti di business per il controllo degli accessi
9.2	Gestione degli accessi degli utenti
9.3	Responsabilità dell’utente
9.4	Controllo degli accessi ai sistemi e alle applicazioni
10	Crittografia
10.1	Controlli crittografici
11	Sicurezza fisica e ambientale
11.1	Aree sicure
11.2	Apparecchiature
12	Sicurezza delle attività operative
12.1	Procedure operative e responsabilità
12.2	Protezione dal malware
12.3	Backup
12.4	Raccolta di log e monitoraggio
12.5	Controllo del software di produzione
12.6	Gestione delle vulnerabilità tecniche
12.7	Considerazioni sull’audit dei sistemi informativi
13	Sicurezza delle comunicazioni
13.1	Gestione della sicurezza della rete
13.2	Trasferimento delle informazioni
14	Acquisizione, sviluppo e manutenzione dei sistemi
14.1	Requisiti di sicurezza dei sistemi informativi
14.2	Sicurezza nei processi di sviluppo e supporto
14.3	Dati di test
15	Relazioni con i fornitori
15.1	Sicurezza delle informazioni nelle relazioni con i fornitori
15.2	Gestione dell’erogazione dei servizi dei fornitori
16	Gestione degli incidenti relativi alla sicurezza delle informazioni
16.1	Gestione degli incidenti relativi alla sicurezza delle informazioni e dei miglioramenti
17	Aspetti relativi alla sicurezza delle informazioni nella gestione della continuità operativa
17.1	Continuità della sicurezza delle informazioni
17.2	Ridondanze
18	Conformità
18.1	Conformità ai requisiti cogenti e contrattuali
18.2	Riesami della sicurezza delle informazioni

Come si può vedere dalla tabella la trattazione offerta da questo controlli è veramente “a tutto tondo” ed offre la possibilità di creare un Sistema per la Sicurezza delle Informazioni veramente efficace.
Dovendo quindi fornire una breve guida all’implementazione di un Sistema per la Sicurezza delle Informazioni, non si può non considerare questo importantissimo elemento.

I Controlli forniscono:

1. Un elemento concreto per l’attuazione della sicurezza;
2. Un elemento di verifica nella Gestione del Rischio (i controlli e la loro attuazione sono gli elementi che posso abbattere il rischio).

Il Sistema Documentale

Un sistema per la sicurezza delle informazioni deve essere supportato da un buon sistema documentale. La norma ne richiede l’implementazione a sostegno del sistema stesso, ed esso ne diventa la spina dorsale giacché ne governa tutte le attività.
Per una migliore comprensione abbiamo suddiviso il sistema documentale in varie sezioni, a seconda del tipo di documento, anche se in questo senso non ci sono delle regole auree, ma questa suddivisione è dettata dalla buona pratica, ed aiuta i fruitori del sistema documentale ad orientarsi meglio.

Quattro raggruppamenti

Nell’esporre i vari documenti useremo quindi questi raggruppamenti:

1)  manuale e politiche
2)  gestione del rischio
3)  procedure
4)  registrazioni

A questi quattro raggruppamenti ne consigliamo l’aggiunta di un quinto, che conterrà l’elenco degli “strumenti utili”. Pur non essendo questi ultimi realmente parte del sistema documentale, ne diventano parte integrante nella misura in cui ne estendono le capacità, ne sostengono la gestione, e ne semplificano la tenuta.

Il numero e la scelta dei documenti ancora una volta nascono dalle esigenze del sistema e dalla buona pratica, con un occhio attento alla semplificazione ed alla integrazione (come sempre).

Tabella di riepilogo

Indipendentemente da quali saranno in effetti i contenuti dei Vostri documenti vi consigliano di mettere sempre dei riferimenti puntuali con la norma. Questo può essere agilmente realizzato con una tabella di riepilogo in testa o in fondo al documento, e con cenni puntuali capitolo per capitolo.
Non abbiate quindi il timore di essere poco “eleganti” nell’inserire questi collegamenti, ed anzi usateli a piene mani. È infatti difficile ricordare a memoria le norme e riuscire a collegare rapidamente gli argomenti (magari questo verrà con il tempo), e comunque pensate sempre che chi legge i vostri documenti potrebbe invece avere assoluta necessità di questo piccolo aiuto.
Precisiamo infine che le ultime versioni della norma hanno introdotto il termine “informazioni documentate”, intendendo tutti i tipi di documenti che compongono il sistema di gestione. Noi abbiamo scelto una nomenclatura più classica, con il solo intento di aiutare il lettore nel comprendere la natura dei documenti stessi, riferendoci al termine “registrazioni”.

Il Miglioramento Continuo

William Edwards Deming (nato a Sioux City il 14 ottobre 1900 e morto a Washinton DC il 21 dicembre 1993) è stato un personaggio poliedrico (ingegnere, docente, saggista, consulente di gestione dell’organizzazione, manager, ecc.). Esso ha avuto ed ha ancora oggi una grossa rilevanza sui sistemi di gestione, ed ovviamente anche per quello della sicurezza delle informazioni, grazie alla sua teoria relativa al ciclo di miglioramento continuo (il famoso Ciclo di Deming).

La storia di Deming

La storia di Deming si compie sia nel suo paese natale durante la Seconda guerra mondiale (in particolare per gli studi sul miglioramento della produzione, legati all’economia di guerra) ma anche e soprattutto nel Giappone post-bellico. È difatti in Giappone, che dal 1947 in poi insegnò ai vertici dell’organizzazione delle grandi aziende giapponesi, tecniche per migliorare la progettazione e la qualità dei prodotti. Il suo insegnamento verteva su metodi statistici come l’analisi della varianza (ANOVA) e test di ipotesi.
Questa sua importante attività fornì un contributo essenziale al rilancio dell’economia giapponese e per porre le basi del Giappone moderno, attraverso una produzione di prodotti innovativi e di altissima qualità.

A-conto-B

Negli anni Settanta, la filosofia di Deming è stata riassunta da alcuni dei suoi fautori giapponesi, con il seguente paragone “A-conto-B”:
A – Quando le persone e le organizzazioni si concentrano principalmente sulla qualità, definita dal rapporto Qualità = Risultati degli sforzi di lavoro/Costi totali, tende ad aumentare la qualità e la caduta dei costi nel corso del tempo.
B – Quando le persone e le organizzazioni si concentrano principalmente sui costi (spesso fattore dominante e tipico comportamento umano), i costi tendono ad aumentare e la qualità diminuisce con il tempo.

Plan, Do, Check, Act: il ciclo di Deming

Il ciclo di Deming (PDCA, Plan-Do-Check-Act, Pianificare-Fare-Verificare-Agire) è un metodo di gestione utilizzato per il controllo e il miglioramento continuo dei processi e dei prodotti.
La tecnica si articola in quattro fasi:

P – Plan (Pianificazione)

È la fase in cui vengono stabiliti gli obiettivi e i processi necessari per raggiungere i risultati attesi. Nei sistemi di gestione sono le fasi iniziali di definizione delle politiche, di “strategia”, e la messa a punto delle linee guida per tutte le attività inclusa la definizione di procedure e linee guida.

D – Do (Esecuzione)

In questa fase si mette in atto quanto pianificato al punto precedente:
– si seguono i processi, le procedure e le linee guida impostate, sempre pensando alla politiche definite per il raggiungimento degli obiettivi;
– si raccolgono anche le evidenze, gli indicatori dei processi, che serviranno all’attuazione della fase successiva.

C – Check (Verifica)

È la fase che analizzando quanto raccolto al punto precedente, li confronta con i risultati attesi definiti nella fase di Plan, per valutarne eventuali deviazioni.
Il risultato di questa fase di controllo genera l’output per il punto seguente.

A – Act (Azione)

È la fase di aggiornamento, correzione, miglioramento dei processi. In questa fase vengono indirizzate le analisi delle cause che hanno portato a deviazioni rispetto al risultato atteso; vengono messe in atto tutte le azioni correttive ottenendo il miglioramento del processo/prodotto/servizio.
Il ciclo si ripete all’infinito, portando appunto un miglioramento continuo ai sistemi gestiti con questa metodologia.