In quest’articolo andremo a commentare le nuove revisioni delle due più importanti norme della famiglia ISO 27k, avvenute nel corso del 2022:

• ISO/IEC 27001:2022 – Information security, cybersecurity and privacy protection — Information security management systems — Requirements
• ISO IEC 27002:2022 Information security, cybersecurity and privacy protection — Information security controls

La seconda è stata anche pubblicata dall’UNI con il prefisso UNI CEI EN alcuni mesi fa, ma di fatto l’Ente di Normazione Italiano si è astenuto dal tradurre le 170 pagine di norma, limitandosi alla traduzione del titolo (“Sicurezza delle informazioni, cybersecurity e protezione della privacy – Controlli di sicurezza delle informazioni”) e poco più, lasciando molti delusi visto che la precedente versione era stata tradotta. Ora ci si aspetta la pubblicazione della UNI CEI EN ISO 27001 con traduzione in italiano che dovrebbe costare pochi sforzi viste le limitate differenze rispetto alla versione precedente e le similitudini con altre norme con struttura HLS. Aspettative che non dovrebbero andare eluse visto che la ISO 27001 è anche una norma certificabile.

Le modifiche alla ISO 27001, oltre al recepimento dei “corriggendum” della precedente versione della norma e l’allineamento alla struttura HLS delle altre norme sui sistemi di gestione, sono veramente minime. I cambiamenti che hanno un impatto sui sistemi di gestione della sicurezza delle informazioni (SGSI) sono sostanzialmente:

• Definire quali requisiti delle parti interessate saranno affrontate nel SGSI (punto 4.2)
• Esplicitazione dei processi necessari al sistema di gestione (punto 4.4)
•  Pianificazione dei cambiamenti – al punto 6.3, completamente nuovo – in piena analogia con le altre norme sui sistemi di gestione
• Al punto 7.4 deve essere stabilito “come si deve comunicare”, ma i sottopunti d) ed e) precedenti eliminati non dicevano cose tanto diverse
• I riferimenti ai controlli di sicurezza al punto 6.1.3 e nell’Annex A.

Proprio quest’ultimo è il cambiamento più significativo della norma in quanto stabilisce che l’elenco dei controlli dell’Annex A (e della ISO 27002) sono solo una possibile lista di controlli di sicurezza sulla quale basare il SGSI e la Dichiarazione di Applicabilità (S.o.A.).

Poiché, salvo alcune realtà particolari, non credo che la gran parte delle organizzazioni si rivolga a framework diversi da quello proposto dalla ISO 27002, direi che è proprio questa norma che apporta modifiche sostanziali al SGSI.

Dunque, i controlli della ISO 27001, che sono diventati 93 (dai 114 precedenti) restano i capisaldi della SoA e per ognuno di essi si dovrà esplicitare le eventuali motivazioni di non applicabilità e le motivazioni di applicabilità (requisiti cogenti, requisiti contrattuali o di business, esigenza derivante dalla valutazione del rischio…).

La ISO 27002, oltre ad essere stata modificata – in parte – nei contenuti dei controlli di sicurezza, è anche stata completamente cambiata nella sua struttura che risulta semplificata.

Ora, infatti, i controlli sono suddivisi in 4 (macro) temi:

• controlli organizzativi (37 controlli);
• controlli sulle persone (8 controlli);
• controlli fisici (14 controlli);
• controlli tecnologici (34 controlli)-

Anche se la maggior parte dei controlli sono classificati come “organizzativi”, fra di essi vi sono molti controlli di forte caratterizzazione tecnologica ed ICT, ad esempio:

• A.5.7    Threat intelligence (Monitoraggio delle minacce)
• A.5.11  Return of assets (Restituzione degli asset)
• A.5.15  Access control (Controllo degli accessi)
• A.5.16  Identity management (Gestione delle identità)
• A.5.17  Authentication information (Informazioni di autenticazione)
• A.5.21  Managing information security in the information and communication technology (ICT) supply-chain (Sicurezza delle informazioni nella filiera di fornitura ICT)
• A.5.23  Information security for use of cloud services (Sicurezza delle informazioni per l’uso dei servizi cloud)
• ….

Appare evidente che non solo alcuni controlli riguardano, nella stragrande maggioranza di casi, “oggetti” ICT (A.5.11: per lo più si restituiscono dispositivi elettronici, A.5.17: stiamo parlando di username e password…), ma alcuni riguardano proprio solamente informazioni in formato digitale (A.5.23). Evidentemente l’Ente normatore (ovvero il Gruppo di lavoro che ha preparato la norma) ha inteso enfatizzare la componente “gestionale” di tali controlli.

Per analogia con le “misure di sicurezza tecniche ed organizzative” richieste dal GDPR si dovrebbe – ad esempio – comprendere il “controllo degli accessi (logici)” fra le misure di sicurezza organizzative e così via.

Al di là della numerosità dei controlli nelle 4 tematiche, è interessante la suddivisione dei controlli tenendo chiaramente separati i controlli relativi alla sicurezza fisica ed ambientale, dai controlli che mettono al centro il fattore umano, dai controlli organizzativi a quelli legati alla sicurezza informatica.

Dal pinto di vista contenutistico i cambiamenti nei controlli possono essere così riassunti

• 11 nuovi controlli
• 35 invariati
• 24 accorpati da controlli esistenti
• 58 aggiornati.

In realtà se andiamo a leggere con attenzione i 93-11= 82 controlli che non sono “nuovi” troviamo molte novità, non solo dovute ad aggiornamenti tecnologici e dello stato dell’arte della cybersecurity e della data protection. Pertanto, in fase di transizione dei SGSI esistenti occorre fare molta attenzione anche ai controlli i cui contenuti non sono apparentemente variati.

Altre novità interessanti della norma riguardano la terminologia e l’introduzione degli attributi.

La norma, infatti, riporta un ampio spettro di termini, definizioni e glossario di abbreviazioni che integrano i contenuti della ISO 27000. Peccato che sia mancata la traduzione nella nostra lingua.

Ma la novità forse più rilevante è stata l’introduzione di una serie di attributi associati ad ogni controllo, una sorta di tag o metadati che caratterizzano i controlli stessi.

Ogni controllo viene caratterizzato, infatti, dai seguenti attributi:

• Tipo di Controllo: Preventivo, di Monitoraggio (detective) o Correttivo
• Proprietà: Riservatezza, Integrità, Disponibilità
• Cybersecurity concepts: Identify, Protect, Detect, Respond, Recover
• Operational capabilities: Governance, Asset management, Information protection, Human resource security, Physical security, System and network security, Application security, Secure configuration, Identity and access management, Threat and vulnerability management,         Continuity, Supplier relationships security, Legal and compliance, Information security event management, Information security assurance
• Security domains: Governance and Ecosystem, Protection, Defense, Resilience.

Quindi, a parte le Proprietà dei Controlli (Confidentiality, Integrity e Availability in inglese) che costituiscono una mezza novità in quanto le stesse proprietà della Sicurezza delle Informazioni sono note da tempo, ma non erano state ufficialmente associate ai controlli, gli altri attributi costituiscono una grossa novità della norma al fine di classificare/categorizzare i controlli.

A fini puramente statistici possiamo notare che i controlli sono classificati in 83 Preventivi, 13 di Monitoraggio (Detective) e 14 Correttivi, da cui appare chiaro che ogni controllo può essere classificato in più di un solo tipo. Emerge anche il fatto che prevale l’ottica di prevenzione degli incidenti e delle violazioni di sicurezza. Ci si aspetterebbe che i controlli preventivi siano focalizzati alla riduzione della probabilità che una minaccia si concretizzi in un rischio di sicurezza delle informazioni, ad esempio attraverso l’eliminazione di vulnerabilità. Per i controlli classificati come Detective (o di monitoraggio) ci si aspetterebbe un indicatore di monitoraggio dell’efficacia delle misure di sicurezza adottate.

Più equilibrio c’è sulle proprietà dei controlli (R I D) dove si hanno 87 controlli che impattano la Riservatezza, 84 l’Integrità, 85 la Disponibilità: dunque sono pochi i controlli che non mirano a tutelare tutte e tre le Proprietà di sicurezza dell’informazione.

Curiosamente l’attributo Physical Security del gruppo di attributi “Operational capabilities” comprende 16 controlli di cui 2 non appartenenti al tema dei “controlli fisici”: “Procedure operative documentate” e “Lavoro da remoto”. Naturalmente ciò si giustifica per il fatto che devono essere presenti procedure documentate sui controlli fisici e che il lavoro da remoto (lavoro agile e/o smartworking) comprende aspetti che riguardano i controlli fisici (dove svolgo il lavoro da remoto? Come proteggo la postazione di lavoro da accessi fisici non autorizzati?).

Lasciando da parte queste statistiche sulla classificazione dei controlli nei vari attributi, la cui importanza ed utilità probabilmente si evidenzierà nelle fasi applicative della norma, veniamo ad esaminare alcuni aspetti pratici.

Cosa deve fare un’organizzazione certificata ISO 27001 per migrare alla nuova versione della norma?

Come anticipato le modifiche alla ISO 27001 sono davvero poco significative e il grosso del lavoro riguarderà i controlli dell’Annex A ovvero della ISO 27002:2022.

Sono reperibili, anche nella norma ISO 27002:2022 stessa, delle tabelle di conversione tra i vecchi controlli (114) ai nuovi controlli (93). Alcuni esperti consigliano di partire da qui per “convertire” la vecchia S.o.A. nella nuova S.o.A., cercando di coprire i nuovi controlli.

Questo approccio è valido nella maggior parte dei casi e ci permette di fare una gap analysis che comunque sarà richiesta anche dagli enti di certificazione nell’eventuale audit di sorveglianza 2024 laddove l’organizzazione non sia già pronta per la migrazione alla nuova norma.

È comunque opportuno valutare se non sia il caso di ristrutturare completamente il sistema di gestione della sicurezza delle informazioni, partendo dalla valutazione dei rischi. Questo requisito, infatti, è stato rielaborato dalla norma ISO 27005:2022 che ora considera due diversi approcci e molti esperti ritengono che modelli di risk assessment diversi da quello proposto dalla linea guida ISO 27005 siano migliori, perché più snelli e più facilmente applicabili nelle nostre imprese.

Dunque, si potrebbe passare dall’approccio classico, basato su asset – minacce – vulnerabilità – probabilità – gravità, ad un approccio basato sugli scenari o solo sulle vulnerabilità, intese come assenza o inefficacia dei controlli. Al proposito si segnala la disponibilità del tool gratuito VERA di Cesare Gallotti per la valutazione dei rischi ISO 27001:2022.

Dopo la valutazione dei rischi occorre riprogettare la S.o.A., evidentemente riconsiderando solamente i documenti che descrivono l’implementazione dei vari controlli di sicurezza.

Se le policy di sicurezza e le istruzioni operative relative ai controlli erano legate alla vecchia nomenclatura dei controlli sarebbe opportuno modificare la struttura del SGSI.

Se esiste un Manuale del Sistema di Gestione (che magari copre anche altre normative, ISO 9001, ISO 14001…)  si potrebbe partire da esso per richiamare i documenti di secondo livello del SGSI, ovvero le policy o le procedure. Esse dovrebbero riportare la descrizione dei processi e delle policy di sicurezza nei vari ambiti (controlli relativi alle persone, controlli di sicurezza fisica, controllo degli accessi logici, protezione dal malware, continuità operativa, gestione relazioni con i fornitori, ecc.), comprendenti le responsabilità ed i principi generali di scurezza delle informazioni.

Tali procedure potrebbero poi richiamare delle istruzioni operative di dettaglio che descrivono le modalità operative di attuazione dei controlli, richiamando eventuali documenti di consultazione, database o prospetti consultabili da sistema informatico (applicativi, funzioni del sistema operativo, tabelle Excel o Word, ecc.).

Procedure/policy ed istruzioni operative dovrebbero poi essere richiamate nella Dichiarazione di Applicabilità (SoA) in corrispondenza dei vari controlli.

Non è efficiente predisporre una procedura o una istruzione per ogni controllo della ISO 27002, ma determinate procedure potrebbero comprendere più controlli assimilabili ad una medesima attività.

Chiaramente esisteranno documenti prodotti ed aggiornati periodicamente che dovranno rispondere ad uno o più controlli nella SoA, ad es. il Business Continuity Plan.

Una struttura con dettagli crescenti a partire dal vertice della cosiddetta “Piramide della Documentazione”, nota nei sistemi qualità da alcuni lustri, costituito dal Manuale del Sistema di Gestione, favoriscono anche una classificazione dei documenti del SGSI. Infatti Manuale e Procedure/Policy avranno un livello di astrazione tale da poterli trasmettere anche all’esterno a clienti e partner che lo richiedono, mentre le istruzioni operative ed i documenti ad essa allegati o richiamati – quali ad esempio l’elenco degli asset informatici, la mappa della rete, l’elenco degli utenti con le relative autorizzazioni, le configurazioni ICT, ecc. – dovrebbero essere classificati come documenti riservati, accessibili, anche internamente, ad un numero limitato di persone.

Naturalmente, come avviene per qualunque sistema di gestione ed a maggior ragione per i SGSI, la struttura modulare della documentazione deve essere progettata in modo che le modifiche più frequenti ai documenti riguardino un piccolo insieme di documenti a livello più basso nella Piramide della Documentazione, in quanto si tratta dei documenti di maggior dettaglio.

Per quelle organizzazioni che dispongono anche di una certificazione ISO 27017 e/o ISO 27018 la cattiva notizia è che i controlli di queste normative saranno allineati successivamente alla ISO 27002:2022, dunque, in attesa che ciò avvenga, bisogna cercare di barcamenarsi alla meglio fra nuovi e vecchi controlli e ciò non sarà poco complicato.

Infine, per chi si approccia con questa nuova versione della norma alla progettazione di un nuovo SGSI il consiglio è quello di non farsi condizionare dall’approccio minimalista della documentazione dei sistemi qualità ISO 9001 di questi tempi: nel SGSI ISO 27001 è necessario documentare molto di più, soprattutto gli aspetti di dettaglio; non solo perché sono richiesti dagli Organismi di Certificazione, ma anche perché per una gestione interna efficace ed efficiente solo mantenendo un elevato livello di documentazione delle attività operative – soprattutto quelle in ambito ICT – si riesce a mantenere il controllo delle stesse a fronte di cambiamenti di tecnologie e di persone e a garantire l’accountability del sistema, anche lato privacy (il GDPR docet).

In un precedente articolo abbiamo trattato della valutazione del rischio privacy per adempiere ai requisiti del GDPR (Regolamento UE 2016/679 sulla protezione dei dati personali), ma chi ha o deve implementare un sistema di gestione per la sicurezza delle informazioni come deve considerare la valutazione dei rischi sui trattamenti di dati personali? Tale valutazione è implicita nella valutazione dei rischi sulla sicurezza delle informazioni, ovvero è un “di cui” di essa? Oppure, come sostengono alcuni esperti di privacy, è tutta un’altra cosa e va considerata separatamente? Cerchiamo di chiarire questi aspetti.

Cos’è il rischio per la sicurezza delle informazioni?

Partiamo dalla valutazione del rischio per la sicurezza delle informazioni, ovvero essenzialmente per i sistemi di gestione certificati ISO 27001.

Prima di parlare di valutazione del rischio dovremmo soffermarci sulla terminologia: sicurezza delle informazioni non è “sicurezza informatica” e non è “cybersecurity”. Tralasciamo le discussioni sul termine cybersecurity (in italiano “sicurezza cibernetica”?) che per taluni equivale alla sicurezza informatica, per altri è la protezione delle informazioni digitali da attacchi informatici (non da incidenti naturali!), per altri ancora ha a che fare con la sicurezza degli appartai IT e OT…

La sicurezza informatica è un sottoinsieme della sicurezza delle informazioni? Dunque, la valutazione del rischio ICT è una parte della valutazione del rischio per la sicurezza delle informazioni?

Non è proprio così, ma quasi: la sicurezza informatica riguarda gli apparati ICT che normalmente trattano informazioni digitali. Ora un problema tecnico, dovuto ad un attacco informatico deliberato oppure ad un evento accidentale, comporta anche un rischio per la sicurezza delle informazioni? In teoria non è sempre così perché un attacco informatico ad una infrastruttura critica (ad es. un acquedotto o una rete elettrica) generalmente non comporta conseguenze sulla sicurezza delle informazioni, ovvero sulla sua declinazione in riservatezza, integrità e disponibilità. Perciò non costituisce un rischio per la sicurezza delle informazioni? Ma le apparecchiature informatiche e le infrastrutture ICT cosa trattano? Non trattano byte, ovvero informazioni? Facciamo un esempio su un fatto accaduto di recente: il blocco del traffico aereo alcuni giorni fa negli Stati Uniti è stato provocato da un incidente informatico, pare fosse colpa di un file “corrotto” (ma anche se fosse stato un attacco di hacker Russi, cosa che non ci diranno mai, la sostanza non cambierebbe): ebbene è considerato un incidente sulla sicurezza delle informazioni, ovvero si è concretizzato un rischio sulla sicurezza delle informazioni? Apparentemente no perché le conseguenze sono state il blocco dei voli con disagi per i passeggeri, maggiori costi per Compagnie Aeree e passeggeri e così via. Ma la causa di tutto questo non è stata la mancanza di informazioni (= mancata disponibilità di informazioni) sulla sicurezza dei voli che ha fatto prudentemente mantenere a terra molti aeromobili?

Ovviamente tutto dipende dal contesto in cui si trova l’organizzazione che deve valutare i rischi e qual è il campo di applicazione del sistema di gestione ISO 27001 che, nel caso, ci chiede la valutazione del rischio.

Il viceversa – ovvero che la sicurezza informatica non copra tutta la sicurezza delle informazioni – è dimostrabile in modo più semplice: le informazioni su supporto cartaceo devono essere protette e la loro protezione generalmente non riguarda la sicurezza informatica.

La valutazione del rischio sulla sicurezza delle informazioni

Fatta questa premessa andiamo ad esaminare cosa ci dice la teoria e la letteratura sul risk assessment per l’information security, ovvero per il SGSI ISO 27001.

In principio fu la vecchia versione della ISO 27005 a guidare queste valutazioni del rischio sulla sicurezza delle informazioni. In sintesi, questa norma ci diceva di partire dal censimento degli asset dell’organizzazione, di andare a vedere quali informazioni essi trattano (information asset) e, quindi, fare una valutazione del valore degli asset riguardo alle caratteristiche di sicurezza, ovvero riservatezza, integrità e disponibilità.

Poi occorreva identificare le minacce alla sicurezza delle informazioni (gli attacchi hacker, gli incendi, gli errori di configurazione dei sistemi, ecc.) e le vulnerabilità presenti negli asset (sistemi non aggiornati, assenza di protezione fisica del CED, mancanza di consapevolezza del personale, ecc.).

Una combinazione di questi elementi, ovvero una minaccia che sfrutta una vulnerabilità per far concretizzare un rischio su un determinato asset veniva ponderata in base alla probabilità di accadimento (in realtà viene usato il termine verosimiglianza) x la gravità delle conseguenze/danno potenziale x il valore dell’asset, al fine di ottenere un determinato livello di rischio quali-quantitativo.

Oggi l’ultima versione della medesima norma prende in considerazione due approcci:

• Approccio basato sugli eventi: i rischi possono essere identificati attraverso le considerazioni della Direzione e il contesto dell’organizzazione. Questo permette di concentrare gli sforzi sui rischi più critici, senza disperdersi nella valutazione di numerosi rischi che poi giudicherò minori e non degni di essere considerati con azioni di trattamento.
• Approccio basato sugli asset: i rischi possono essere identificati attraverso l’ispezione di asset, minacce e vulnerabilità. È quello già previsto dalla precedente edizione della ISO 27005.

Altri metodi di valutazione del rischio possono essere utilizzati, classificati in genere in metodi quantitativi (basati su un calcolo più o meno “preciso” del rischio, a fronte di valutazioni della probabilità matematica di accadimento dell’evento negativo e di valutazione quantitativa del danno, ad es. in termini economici) e qualitativi (il valore del rischio: “Alto”, “Medio”, “Basso”, ecc. non è espresso in valori assoluti, ma rappresenta solo un metodo di confronto fra i vari rischi).

In generale questi metodi qualitativi, secondo alcuni esperti, portano sempre ad un calcolo del rischio basato sulla formula:

r(m, a, v) ∝ p(m) ⋅ i(m, a) ⋅ g(v)

dove r rappresenta la funzione “rischio” che dipende da m= minacce, a= asset, v= vulnerabilità in modo proporzionale alla probabilità di accadimento della minaccia, all’I=impatto della minaccia sull’asset e alla g=gravità della vulnerabilità.

Un approccio completamente diverso, proposto da altri esperti, non prende in considerazione le minacce, ma parte dalle vulnerabilità presenti per determinare i rischi concreti che dovranno essere valutati attraverso la classica formula Rischio =Possibilità di accadimento x Gravità del danno o delle conseguenze provocate dal concretizzarsi del rischio.

Le fasi successive del processo di valutazione dei rischi, dopo la loro identificazione, sono sempre le stesse: analisi dei rischi, ponderazione dei rischi, scelta delle opzioni di trattamento, determinazioni dei controlli/contromisure necessari, confronto con i controlli dell’Annex A della ISO 27001 e definizione della Dichiarazione di Applicabilità (S.o.A.).

Tra i modelli disponibili per il calcolo del rischio sulla sicurezza delle informazioni secondo la ISO 27001 segnaliamo il tool VERA di Cesare Gallotti (https://www.cesaregallotti.it/Pubblicazioni.html ) che prevede l’identificazione di una serie di Minacce/Rischi per le quali sono attribuiti una probabilità di accadimento ed un impatto fino a costituire il c.d. “rischio puro” o “rischio intrinseco”. Quindi vengono stabilite le vulnerabilità che non sono altro che l’inversamente proporzionale ai controlli, ovvero all’efficacia degli stessi. Combinando il rischio intrinseco con le vulnerabilità/controlli si ottiene il valore del rischio calcolato sulla sicurezza delle informazioni. Tale modello comprende anche una parte legata alla privacy (comunque cogente anche in ambito SGSI) nella quale si valutano i soli rischi (minacce) attinenti alla privacy e le relative conseguenze.

Altri esperti definiscono il “rischio inerente” come il rischio derivante dalla combinazione di probabilità/possibilità di accadimento dell’evento e dalla gravità delle conseguenze. Applicando i controlli di sicurezza, ovvero le contromisure (le misure di sicurezza tecniche ed organizzative in termini privacy) si ottiene il “rischio residuo”, che dovrà poi essere confrontato con i criteri di accettabilità per stabilirne le opzioni di trattamento.

Altri schemi e standard prevedono valutazioni dei rischi sulla sicurezza ICT, che oggi costituisce parte preponderante della sicurezza delle informazioni. Gli approcci possono essere leggermente diversi, ma sostanzialmente non si discostano dalla seguente metodologia-

1. Identifico le minacce che incombono sui sistemi e sui dati (es. virus ransomware o, più in dettaglio le tecniche che rendono possibile un attacco ransomware: phishing, social engineering, attacchi di forza bruta a siti web per la ricerca di credenziali di accesso, ecc.)
2. Identifico gli eventi che, se si concretizza la minaccia, possono costituire un rischio per i miei dati
3. Valuto le misure di mitigazione che sono state implementate per fronteggiare il rischio.
4. Valuto la probabilità di accadimento dell’evento.
5. Valuto l’impatto che comporta tale rischio per i dati e tutto quel che ne consegue.
6. Calcolo il valore del rischio (residuo).
7. Definisco le azioni di trattamento del rischio (accettare il rischio oppure adottare ulteriori misure di prevenzione o protezione per ridurre il rischio o addirittura eliminarlo.

La valutazione del rischio privacy

Quando si valuta il rischio relativo alla privacy, è possibile identificare minacce specifiche per la privacy. Tra di esse vi sono:

• rappresentazione scorretta, se i dati relativi a una persona sono errati, oppure presentati o elaborati in modo non corretto possono provocare danni all’interessato; questa minaccia può anche riguardare i risultati della profilazione di una persona (che, ad esempio, potrebbe essere esclusa da programmi sanitari o economici), eventualmente anche con strumenti basati sull’intelligenza artificiale;
• distorsione, ossia l’interpretazione volutamente o inavvertitamente scorretta dei dati, con potenziali impatti negativi sulla singola persona; questa minaccia è, in pratica, quella del pettegolezzo e della maldicenza, che può portare al biasimo, alla stigmatizzazione, all’isolamento e anche alla perdita di libertà di una persona;
• sorveglianza, attraverso l’uso dei dati, soprattutto in ambito informatico; è necessario riconoscere la differenza tra logging (ossia la raccolta di dati per assicurare la sicurezza delle persone e della proprietà) e la sorveglianza (che porta, anche se non sempre per scelta deliberata, a discriminazione, perdita di fiducia, autonomia o libertà, danni fisici o materiali);
• blocco alla conoscenza dei dati trattati, ossia segretezza in merito al fatto che i dati personali sono trattati e alle modalità con cui lo sono; questo può portare all’uso dei dati personali iniquo e, per le singole persone fisiche, alla mancanza di autodeterminazione, alla perdita di fiducia e a perdite economiche;

In pratica le minacce per la privacy potrebbero essere diverse da quelle per la sicurezza delle informazioni, o meglio alcune (la maggioranza) coincidono, altre sono differenti. Ma se consideriamo che l’informazione è anche un dato personale e che la stessa ISO 27001 comprende un controllo denominato “Privacy e protezione dei dati personali” (controllo A.18.1.4 della versione 2013 della ISO 27001-27002) capiamo bene che – nella valutazione del rischio per la sicurezza delle informazioni – dobbiamo considerare anche gli impatti che una determinata violazione di dati personali può avere sui diritti e le libertà dell’interessato e non solo sul business dell’organizzazione.

Dunque un medesimo evento rischioso, ad esempio un data breach sul portale web dell’azienda oppure un ransomware che non comporta un’esfiltrazione di dati (anche personali), ma “soltanto” un blocco dei sistemi per un paio di giorni, potrebbe portare ad una valutazione e, quindi, ad un indice (livello) di rischio differente semplicemente perché – a parità di probabilità di verificarsi dell’evento – l’impatto sui diritti e le libertà dell’interessato, piuttosto che sul business dell’organizzazione, può essere sensibilmente diverso.

Quindi la valutazione dei rischi potrebbe essere unica a patto di considerare i differenti effetti a fronte del verificarsi di medesimi eventi.

Naturalmente ogni organizzazione avrà i suoi parametri e le sue specificità: dal punto di vista dell’interessato: un conto è un blocco dei sistemi informativi per un paio d giorni di un Ospedale ed un conto è il medesimo blocco per un’azienda manifatturiera dove probabilmente il fatto di non poter accedere ai dati dei dipendenti per un paio di giorni non costituirebbe un gran problema (salvo che non sia il giorno di pagamento degli stipendi…).

Tuttavia, alcuni esperti della materia privacy potrebbero obiettare: ma per il GDPR devo valutare i rischi sui trattamenti di dati personali, quindi considerare i rischi per ogni trattamento! Allora bisognerebbe riprendere il concetto di “Asset” dove i dati personali (dei dipendenti, dei clienti, ecc.) costituiscono un “asset informativo” con un certo valore, dato dalla combinazione delle diverse caratteristiche di sicurezza (Riservatezza, Integrità e Disponibilità).

Spesso, però, si può semplificare considerando il caso peggiore (worst case), ovvero dato un determinato evento rischioso (ad es. un data breach sul portale web) consideriamo lo scenario peggiore per tutti i trattamenti di dati personali. Allora per i trattamenti dei dati personali dei dipendenti avrò un determinato impatto, mentre per i dati personali dei clienti avrò un impatto di tipo e valore diverso: nel nostro caso di esempio per l’Ospedale il rischio maggiore sarebbe sui dati dei pazienti e dei relativi trattamenti (es. prenotazioni, refertazione visite ed esami, ecc.), mentre per l’azienda manifatturiera il rischio più elevato sarà sui trattamenti dei dati dei dipendenti (elaborazione paghe, ecc.).

Evidentemente la valutazione del rischio privacy per ogni singolo trattamento di dati personali che abbiamo inserito nel Registro delle Attività di Trattamento (ai sensi dell’art. 30 del GDPR) potrebbe risultare parecchio oneroso e non giustificato per una medio-piccola organizzazione. È comunque sempre opportuno raggruppare più trattamenti sui quali incombono i medesimi fattori di rischio. Ad esempio in un’organizzazione che gestisce tutti i dati in formato digitale attraverso file di Office conservati in un file Server ed un unico applicativo gestionale è perfettamente inutile replicare le medesime minacce ed eventi di rischio legati all’IT su diversi trattamenti. Eventuali vulnerabilità o misure di sicurezza non completamente efficaci legate al controllo degli accessi degli utenti, agli strumenti anti-malware, ai backup o alla (scarsa) consapevolezza del personale impattano su tutti i trattamenti di dati personali e basterà considerare solo il caso peggiore, ovvero l’impatto di gravità più alta su tutti i trattamenti per “risolvere” il problema della valutazione del rischio privacy. Infatti, ai fini della protezione dei dati personali, il trattamento del rischio che andremo ad attuare sarà finalizzato a prevenire il rischio (abbassare la probabilità che la minaccia si concretizzi) oppure a proteggere il dato dall’evento che non può essere completamente evitato (ridurre la gravità dell’impatto), dunque miglioreremo la protezione dei dati personali su tutti i trattamenti effettuati.

In conclusione il problema non è pensare di coprire anche la valutazione del rischio privacy attraverso una valutazione più ampia sulla sicurezza delle informazioni, ma fare quest’ultima valutazione in modo incompleto, senza considerare nel modo corretto i rischi associati alla protezione dei dati personali.

Come spesso accade, se si fanno le cose per bene si può fare (quasi) tutto.

Come noto il Regolamento UE 679/2016 (GDPR) non prevede più – a differenza del previgente D.Lgs 196/2003 – di attuare delle misure “minime” di sicurezza” a protezione dei dati personali trattati da un’organizzazione (titolare o responsabile del trattamento), bensì misure di sicurezza adeguate, stabilite a fronte di una valutazione dei rischi sui trattamenti.

In particolare, all’Articolo 32 del GDPR: Sicurezza del trattamento (Considerando 83), si riporta quanto segue:

In altri articoli di questo blog abbiamo esaminato varie misure di sicurezza, tecniche ed organizzative, che ogni titolare o responsabile del trattamento dovrebbe adottare e non è l’obiettivo di questo articolo fare un’elencazione delle possibili misure di sicurezza. Si veda al proposito Misure di sicurezza di un’applicazione web per essere conformi al GDPR, Prime esperienze di applicazione del GDPR, Come gestire il Responsabile del trattamento ai sensi del GDPR, Come gestire il Responsabile del trattamento ai sensi del GDPR.

In questo articolo vorrei invece soffermarmi su un aspetto, la valutazione di “adeguatezza” di una misura di sicurezza e la possibilità di un’organizzazione di dimostrare a terzi (soggetti di cui tratta dati personali in qualità di titolare, altri titolari del trattamento per i quali svolge il ruolo di responsabile del trattamento, Garante per la Protezione dei Dati Personali a fronte di eventuali ispezioni) di aver fatto tutto quello che poteva per proteggere i dati personali, ovvero di dimostrare l’accountability.

Molte organizzazioni chiedono ai consulenti privacy ed ai loro DPO (o RPD, Responsabile della Protezione Dati) quali misure di sicurezza minime devono adottare, oppure se le misure adottate sono sufficienti. Ma è difficile rispondere a questa domanda in quanto il panorama delle misure di sicurezza, soprattutto sul fronte ICT, è profondamente mutato dal 2004 quando entrò in vigore il vecchio D. Lgs 196/2003 ed in particolare il suo Allegato B (ora abrogato).

Occorre fare una valutazione dei rischi che incombono sul trattamento, basata sulla valutazione della probabilità e della gravità dell’impatto che determinati eventi negativi, rispettivamente, si verifichino e delle conseguenze che possono portare ai dati personali trattati. Inoltre, nella determinazione delle misure di sicurezza, occorre contestualizzare (l’art. 25 del GDPR cita: «Tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’ambito di applicazione, del contesto e delle finalità del trattamento…») e non tutte le misure di sicurezza sono uguali a sé stesse in tutti i contesti.

Cerchiamo di capire meglio, partendo da una domanda che un auditor o consulente privacy formula normalmente al responsabile di un’organizzazione – di medio-piccole dimensioni – per la quale deve svolgere un assessment sullo stato di adeguatezza rispetto al GDPR.

Auditor: «Quali misure di sicurezza tecnologiche avete adottato per proteggere i dati trattati su supporto e lettronico?»

Responsabile organizzazione: «Abbiamo tutte le misure richieste dalla normativa: antivirus, firewall, backup, password…»

I problemi per il bravo auditor o consulente privacy iniziano a questo punto: bisogna capire quali di queste misure specifiche sono implementate e come, ovvero come sono configurate. Infatti, il GDPR ci chiede di considerare lo stato dell’arte della tecnologia, ma anche delle minacce apportate ai dati personali dai “cattivi”, ovvero gli hacker, il personale infedele, i malintenzionati in genere. Inoltre ci sono da considerare anche i rischi di origine ambientale, quali catastrofi naturali, terremoti, ecc.. Purtroppo, anche in questo ambito lo “stato dell’arte” negli ultimi 10-15 anni ha fatto aumentare la probabilità di eventi quali terremoti ed alluvioni in zone nelle quali non si erano mai verificati eventi gravi (vedi ad es. Emilia – Romagna). Anche la pandemia Coronavirus, sebbene non abbia portato ad aumentare i rischi diretti di perdita di dati o di perdita di riservatezza degli stessi, ha comportato – essenzialmente attraverso il lavoro a distanza – a cambiare il “perimetro” entro il quale i dati vengono trattati, generando nuove vulnerabilità presto sfruttate da malintenzionati che hanno prontamente creato nuove minacce per attaccare i dati delle aziende.

Prendendo spunto da provvedimenti e sanzioni già comminate dal Garante Privacy relativamente alle misure di sicurezza non adeguate, a fronte di una violazione (data breach) verificatasi, vorrei esaminare alcune misure di sicurezza implementate da quasi tutte le organizzazioni.

Premesso che il GDPR ci chiede di scegliere le misure di sicurezze anche in base al costo di attuazione, dunque non può chiedere ad una piccola organizzazione (ad es. uno Studio Professionale o una piccola Società di servizi che tratta anche dati particolari) le stesse misure di sicurezza adottate da un’azienda a livello Enterprise – ad es. sistemi antintrusione molto evoluti, appliance di sicurezza informatica o altri strumenti “top di gamma” – è comunque necessario dimostrare di non aver trascurato il problema, per noncuranza oppure per eccessiva riduzione dei costi.

Partiamo dall’antivirus, ormai meglio denominato anti-malware, il cui obiettivo è prevenire virus informatici, tra cui i tanto temuti ransomware, ma anche syware (programmi spia che raccolgono dati a fini pubblicitari, quando va bene) e simili.

Ci sono antivirus gratuiti (ma attenzione che molti di essi non sono freeware per uso commerciale, per cui si rischia di incorrere in sanzioni per assenza di licenza) che offrono una discreta protezione, ma non certamente ottimale come quella fornita dalle corrispondenti versioni a pagamento. Tra gli anti-malware gratuiti c’è anche Microsoft Defender (o Windows Defender), incluso e preinstallato in Windows 10 che offre anch’esso una discreta protezione, ma non ha performance eccellenti nella protezione dal ransomware e non costituisce una scelta ottimale per chi tratta dati particolarmente critici (ad es. dati sanitari).

La scelta di non adottare una soluzione a pagamento è sostenibile? Se tutto va bene non ci sono problemi, ma se siamo colpiti da un ransomware che ci blocca l’attività e ci costringe a segnalare la violazione dati al Garante Privacy (difficile nascondere la violazione se, come nel caso di una Farmacia lombarda bisogna stare chiusi e mettere un cartello in strada nel quale si informa la gentile clientela che si resta chiusi per problemi informatici…) è difficile sostenere che le nostre misure di sicurezza erano adeguate. Come si giustifica la scelta di non spendere per un antivirus commerciale? A fronte del costo di circa una cinquantina di euro l’anno per la protezione di 3 PC è difficile sostenere la motivazione economica.

Ma acquistare un antivirus professionale non basta, occorre configurarlo correttamente.

Pensate che un software di sicurezza completo di anti-malware, firewall ed altri tool di sicurezza accessori (aggiornamento applicazioni, analisi vulnerabilità, protezione webcam, ecc.) tra i più noti, come Kaspersky Internet Security, presenta oltre una quarantina di parametri da configurare per ottenere un giusto compromesso fra prestazioni del computer e delle applicazioni e livello di protezione, con la necessità di configurare opportunamente alcuni parametri per poter utilizzare determinate applicazioni. Ad esempio, per poter utilizzare una semplice chiavetta per la firma digitale al fine di accedere al portale di accesso del Processo Civile Telematico (necessario per avvocati e CTU come il sottoscritto) occorre disabilitare il controllo delle connessioni crittografate, impostata per default dall’antivirus come attiva. L’utilizzo di applicazioni web – dal semplice home-banking ai siti di e-commerce, ai portali specifici utilizzati da alcune organizzazioni per determinate attività lavorative – richiedono talvolta impostazioni specifiche, anche dipendenti dai browser usati, relativamente ad anti-banner, cookie, navigazione in incognito e così via.

Naturalmente in caso di diversi PC collegati in rete con un server che accede a internet la situazione si complica. In sostanza bisogna saper configurare correttamente i tool di protezione oppure ricorrere ad un consulente informatico esterno.

Per il firewall vale il discorso fatto per l’antivirus, sia per quanto riguarda le soluzioni gratuite, sia per quanto riguarda la corretta configurazione. Come ulteriore complicazione si aggiunge il firewall hardware offerto ormai da quasi tutti i modem/router delle compagnie telefoniche, che deve essere configurato in modo da evitare incompatibilità con il firewall software e la struttura informatica interna. Tra l’altro spesso le incompatibilità riscontrate da utenti non esperti portano ad eliminare alcune misure di sicurezza per evitare problemi. Anche in questo caso spesso è difficile rinunciare ad un tecnico esperto esterno, in particolare per le piccole organizzazioni che non hanno un vero responsabile ICT interno in grado di gestire e risolvere la maggior parte dei problemi.

Se poi l’organizzazione deve accedere ad applicazioni web o ha installate sul proprio server applicazioni gestionali che devono essere fruibili anche esternamente, c’è l’esigenza di esporre servizi ed applicazioni all’esterno per renderle visibili e/o rendere visibili dall’esterno a determinate risorse (PC o server) interne.

In tutti questi casi occorre ancora l’intervento di uno specialista e spesso non basta un intervento “una tantum”. Purtroppo, molte organizzazioni di piccole dimensioni, che magari trattano dati particolari (di cui all’art. 9 del GDPR), scelgono di spendere per servizi professionali esterni solo quando strettamente necessario, mentre spesso ci sarebbe bisogno di una manutenzione costante dei sistemi informatici, almeno dal punto di vista sistemistico. Infatti, col tempo le configurazioni degli strumenti di protezione cambiano, oppure cambiano le modalità di fruizione delle applicazioni e gli strumenti di protezione non vengono riconfigurati di conseguenza.

Qui andiamo ad introdurre l’argomento dell’Amministratore di Sistema, figura tanto discussa a causa del provvedimento del Garante per la Protezione Dati Personali di ormai 10 anni fa (cfr. Misure e accorgimenti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici relativamente alle attribuzioni delle funzioni di amministratore di sistema – 27 novembre 2008; aggiornato in base al provvedimento del 25 giugno 2009).

Da un punto di vista puramente formale è bene precisare che tale Provvedimento NON è stato abrogato, sebbene in talune situazioni può essere derogata la nomina dell’Amministratore di Sistema (AdS) e il GDPR non citi questa figura. Da un punto di vista sostanziale non si può negare che la nomina formale – con compiti e responsabilità precise – dell’AdS costituisca una misura di sicurezza di tipo organizzativo. Al di là di questo il fatto di delegare il controllo dei propri sistemi informatici ad uno o più AdS in modo continuativo garantisce il Titolare (o Responsabile) del trattamento che i sistemi informatici siano ben configurati.

Ricordiamo la definizione di AdS, secondo l’Autorità Garante:

«Con la definizione di “amministratore di sistema” si individuano generalmente, in ambito informatico, figure professionali finalizzate alla gestione e alla manutenzione di un impianto di elaborazione o di sue componenti. Ai fini del presente provvedimento vengono però considerate tali anche altre figure equiparabili dal punto di vista dei rischi relativi alla protezione dei dati, quali gli amministratori di basi di dati, gli amministratori di reti e di apparati di sicurezza e gli amministratori di sistemi software complessi.»

Purtroppo, queste regole sono sovente disattese per due ragioni fondamentali:

1. Molte organizzazioni si rivolgono a consulenti informatici e tecnici sistemisti esterni solo “alla bisogna”, ovvero quando c’è da installare una nuova risorsa hardware o un nuovo software, oppure quando si verifica un problema. Già questo non va proprio bene alla luce dei discorsi fatti sopra: il titolare del trattamento potrebbe non avere sotto controllo le misure di sicurezza implementate “una tantum”.
2. Altre organizzazioni hanno un rapporto continuativo con un soggetto esterno che, di fatto, svolge il ruolo di AdS (spesso nominato Responsabile ICT esterno) in quanto detiene continuativamente le credenziali di system administrator (usiamo il termine inglese per distinguerlo dal termine italiano che rievoca il provvedimento del Garante) e svolge manutenzione periodica sui sistemi informatici dell’organizzazione, ma non è stato formalmente nominato Amministratore di Sistema. Perché? Spesso perché non ha il controllo completo sui sistemi, in quanto altri soggetti possono operare con le credenziali di system admin (talvolta le medesime) sui sistemi dell’organizzazione, perché non tutte le risorse hardware ed i software vengono installati e configurati dal Responsabile ICT esterno, il quale, quindi, non vuole garantire determinate misure di sicurezza perché non è in grado di assicurarlo. Altre volte è la stessa Direzione dell’organizzazione che desidera eludere alcune misure di sicurezza ritenute “adeguate” dall’AdS ed addirittura le c.d. misure minime di sicurezza di cui al Disciplinare tecnico (allegato B) del vecchio Codice Privacy. Altre volte, infine, è solo questione di soldi.

In molte situazioni – che rientrano in ambedue le casistiche sopra citate – come aggravante c’è il problema dei log e della loro conservazione. Infatti, il provvedimento impone che siano conservati i log degli AdS, in formato non modificabile dagli stessi, per almeno sei mesi. Poiché per realizzare ciò normalmente occorre un applicativo a ciò dedicato (oppure occorre sviluppare apposite procedure informatiche), talvolta la Direzione dell’organizzazione non vuole spendere per acquistare tale applicativo e, dunque, il candidato AdS (in questo caso può essere anche interno all’organizzazione, ovvero un dipendente) non accetta la nomina perché non è in grado di adempiere ai propri compiti relativamente alla conservazione dei log.

In entrambe le tipologie di situazioni i Titolari (o Responsabili) del trattamento devono solo pregare di non subire un data breach importante, perché nel caso la sanzione dell’Autorità Garante è assicurata in quanto non si riuscirebbe ad assicurare l’accountability del Titolare (o Responsabile) del trattamento.

Altro caposaldo delle misure di sicurezza è il backup, che – rimanendo strettamente nell’ambito del GDPR, ovvero nel trattamento di dati personali – può avere livelli di importanza molto diversi. Infatti, garantire la disponibilità dei dati ha un impatto differente per un Ospedale oppure per un’azienda manifatturiera.

Anche in questo caso non basta dire avere il backup, ma bisogna porsi altre domande:

• Viene fatto un backup sempre completo? Oppure viene fatto un backup incrementale o differenziale?
• Qual è la frequenza del backup?
• Su quali e quanti supporti viene salvato il backup?
• Dove e come vengono conservati i supporti?
• Il backup è accessibile on-line? È cifrato?
• Qual è la retention dei backup (ovvero fino a quanto tempo nel passato riesco a recuperare i file)?
• Vengono eseguite prove di ripristino (restore) complete o parziali?
• E così via.

Una regola sui backup è quella del “3-2-1”, ovvero mantenere almeno 3 copie dei dati (compreso l’originale), su 2 supporti, almeno 1 in una location remota.

È inutile aggiungere che anche se il backup può essere eseguito automaticamente (salvo poi gestire i supporti off-line e portarli con una certa frequenza in un’ubicazione remota), la configurazione dello stesso deve essere eseguita da personale un minimo esperto; e quindi ci riallacciamo al discorso fatto in precedenza.

L’ultimo elemento della domanda iniziale sulle misure di sicurezza è costituito dalle password, ovvero dalle credenziali di autenticazione, meglio descritte dall’espressione “controllo degli accessi logici” ai sistemi informatici.

Molti ritengono di essere a norma dotandosi di accessi con password di almeno 8 caratteri, da cambiare periodicamente. Sulla variazione periodica della password molti sorvolano, ma se da un lato esistono tesi valide che ritengono che la variazione periodica, soprattutto con frequenza breve (mensile o trimestrale) della password sia non solo inutile, ma anche controproducente, dall’altro molte organizzazioni hanno sposato questa tesi in modo inconsapevole, direi quasi incosciente.

Come al solito bisogna avere una visione completa del problema: si può eliminare il cambiamento della password a condizione di adottare una strategia di sicurezza adeguata come usare password complesse (caratteri alfanumerici, numerici e simboli, ecc.) ed introdurre l’autenticazione a due fattori. Questo è molto più importante se stiamo parlando dell’autenticazione ad un’applicazione web alla cui pagina di login potrebbero facilmente accedere anche soggetti esterni malintenzionati.

C’è poi il principio del minimo privilegio che andrebbe soddisfatto, ovvero ogni utente dovrebbe poter accedere esclusivamente alle risorse di cui ha bisogno per lavorare. Purtroppo, invece, molte piccole organizzazioni concedono a tutti di vedere tutto, basandoci sulla fiducia che tutti i collaboratori si comportino correttamente, anche al fine di evitare problemi di accesso in caso di assenza di personale.

Da un lato questa prassi può essere pericolosa perché, pur credendo alla buona fede di tutti, nel caso in cui un utente clicchi su un allegato malevolo o su una pagina web contenente malware, si rischia di compromettere tutte le risorse del sistema informatico portandosi in casa un ransomware. Analogamente se le credenziali di accesso di un utente venissero compromesse (per attacchi informatici o tramite attività di social engineering) un malintenzionato avrebbe accesso a tutte le risorse dei sistemi.

Dall’altro lato le esigenze della Direzione e/o della proprietà dell’organizzazione possono essere soddisfatte da sistemi informatici adeguatamente configurati, acquisendo gli strumenti giusti, da parte di un tecnico esperto. Dunque, anche in questo caso, spesso è questione di costi.

Da ultimo vorrei brevemente affrontare il problema delle comunicazioni elettroniche, tra cui la mail riveste un ruolo principe.

È facile vedere che molte piccole organizzazioni e singoli professionisti utilizzano indirizzi di posta elettronica gratuiti (le estensioni vanno da @libero.it a @tin.it a @gmail.com e così via). Chiaramente questi servizi di posta sono gratis a discapito della privacy, pertanto sono spesso origine di spam perché i provider rivendono gli indirizzi ed i dati di profilazione a terzi.

Visto il costo di 10-15 euro l’anno di un indirizzo di posta elettronica a pagamento, è difficile giustificare un soggetto che utilizza la posta elettronica anche per trasmettere e ricevere dati particolari (ex dati sensibili). In caso di data breach del gestore (per “libero.it” è già successo) o dell’utente, ad esempio per aver subito l’intercettazione della posta, trasmessa con protocolli non cifrati (ad es. “tin.it” non utilizza i protocolli SSL o TLS), anche in questo caso, non ci sono giustificazioni plausibili.

Altre possibili misure di sicurezza non implementate, quali l’impiego di protocolli di comunicazione obsoleti o deprecati per comunicazioni di dati particolari, l’invio di buste paga o altre informazioni personali che ricadono fra le particolari categorie di dati attraverso e-mail in chiaro (non cifrate) e così via, dovrebbero essere prese in considerazione.

Si ribadisce che occorre comprendere che una determinata misura di sicurezza tecnica non è, di per sé, adeguata o meno in assoluto. A seconda del contesto in cui si opera, della natura dei dati trattati, del costo (nell’ottica che abbiamo esplicitato sopra) e dei vincoli che esistono per svolgere una determinata attività, una certa scelta dell’imprenditore – adeguatamente documentata – può essere ritenuta accettabile in una realtà e reputata inadeguata in un’altra, magari semplicemente perché non si ravvisa una scelta consapevole, supportata da ragionamenti ed evidenze oggettive da parte del titolare (o responsabile) del trattamento.

Il consiglio è, quindi, di farsi documentare dal consulente informatico esterno o amministratore di sistema, in un’apposita relazione sulle misure di sicurezza dei sistemi informatici, tutte le misure di sicurezza effettivamente implementate e di mantenere aggiornato tale documento.

Il campo delle misure di sicurezza tecniche ed organizzative a protezione dei dati personali è molto ampio: esistono le norme ISO 27001 e soprattutto i controlli della ISO 27002 sui sistemi di gestione della sicurezza delle informazioni, integrate dalla ISO 27701 specifica sulla protezione dei dati personali, le Linee Guida ENISA, il Cybersecurity Maturity Model, le Linee Guida NIST, le Misure di Sicurezza AGID (specifiche per la P.A.) e così via. Facendo riferimento a documenti normativi riconosciuti o best practice consolidate si riesce a dimostrare l’adeguatezza delle proprie misure di sicurezza nei confronti di terzi.

Qualcuno obietta sempre: «Ma se gli hacker sono riusciti a violare Enti governativi molto importanti ed aziende molto grandi e strutturate, che volete che possa fare io nella mia piccola organizzazione?». Naturalmente i malintenzionati cercano sempre di “pescare” i pesci più grossi, anche se alle volte vanno “a strascico” per cui anche i più piccoli devono difendersi facendo quello che è nelle loro possibilità.

In conclusione, le piccole organizzazioni devono stare molto attente a non ritenere che la privacy possa essere risolta con qualche adempimento formale e dichiarando di applicare alcune misure di sicurezza minimali per essere conformi; in altre parole con la compilazione/redazione di qualche documento da firmare e tenere nel cassetto, come certe soluzioni “preconfezionate” vorrebbero far credere.

In caso di catastrofi e calamità naturali quali terremoti, alluvioni, inondazioni, incendi, eruzioni vulcaniche, uragani oppure atti terroristici, uno dei danni collaterali dopo la perdita di vite umane e i danni materiali ad edifici ed infrastrutture, occorre considerare il blocco dei sistemi informativi che può rallentare notevolmente la ripresa delle normali attività.

Le metodologie da impiegare per prevenire e mitigar i danni che possono compromettere la ripresa delle attività dopo un evento catastrofico riguardano la tematica della business continuity (continuità operativa).

Nell’intervento presentato lo scorso 17/11 al Convegno EVENTI SISMICI: PREVENZIONE, PROTEZIONE, SICUREZZA, EMERGENZA, le cui slide sonono scaricabili in questa pagina, si sono presentate tutte le attività da porre in essere per controllare tali situazioni indesiderate, in particolare sono stati trattati i seguenti argomenti:

• business continuitymanagement
• normative ISO 22301, ISO 2001/27002 e ISO 27031 per la gestione della business continuity, con particolare riferimento ai sistemi informatici
• gestione dei rischi per la continuità operativa
• disaster recovery
• obiettivi ed indicatori di business continuity
• business continuity plan (piano di continuità operativa).

 

La sicurezza dei dati in caso di terremoto

 

La norma UNI CEI ISO/IEC 27002:2014 “Raccolta di prassi sui controlli per la sicurezza delle informazioni” (che sostituisce la ISO 27002:2005) è stata progettata per essere impiegata nelle organizzazioni che intendono implementare un sistema di gestione della sicurezza delle informazioni ISO 27001 e la prendono come riferimento per la scelta dei controlli di sicurezza da attuare.

Struttura della norma

La norma contiene 14 punti di controllo di sicurezza (erano 11 nella precedente versione della norma) che riuniscono un totale di 35 categorie principali di sicurezza (erano 39 nella versione precedente) e 114 controlli (erano 133 nella versione precedente).

Ogni punto che definisce controlli di sicurezza contiene una o più categorie principali di sicurezza, al cui interno sono raggruppati i controllo relativi. Nella norma viene precisato che l’ordine dei punti è indipendente dalla loro importanza, infatti, a seconda delle circostanze, i controlli di sicurezza appartenenti ad uno o a tutti i punti di controllo potrebbero rivelarsi più o meno importanti ed ogni organizzazione che impiega la norma dovrebbe identificare i controlli applicabili al proprio interno, la loro importanza ed il loro impiego in ogni processo di business.

Ogni categoria principale di controllo di sicurezza contiene:

• L’obiettivo di controllo che dichiara cosa si vuole raggiungere
• I controlli che possono essere applicati per raggiungere l’obiettivo di controllo.

La descrizione dei controlli sono strutturate come segue:

• Controllo: definisce nello specifico il controllo funzionale alla soddisfazione dell’obiettivo di controllo.
• Guida attuativa: fornisce informazioni più dettagliate per supportare l’attuazione del controllo. La guida può risultare completamente attinente o sufficiente a tutte le situazioni oppure potrebbe non soddisfare i requisiti specifici di controllo dell’organizzazione.
• Altre informazioni: fornisce informazioni aggiuntive che potrebbe essere necessario considerare, per esempio considerazioni legali e riferimenti ad altre norme. Nel caso non vi siano informazioni aggiuntive da considerare questa parte non è riportata nel testo.

Elenco dei controlli

I punti di controllo definiti dalla norma sono i seguenti:

5 Politiche per la sicurezza delle informazioni

Al suo interno viene individuata la categoria “Indirizzi della direzione per la sicurezza delle informazioni” (5.1), in cui viene indicata la necessità di stabilire una politica per la sicurezza delle informazioni coerente con gli obiettivi e gli indirizzi dell’organizzazione in merito all’Information Security, anche in funzione del contesto di riferimento (mercato, esigenze dei clienti, leggi e regolamenti applicabili). Tale politica dovrà essere mantenuta aggiornata attraverso riesami periodici.

6 Organizzazione della sicurezza delle informazioni

In questa sezione sono definiti le seguenti categorie principali:

• Organizzazione interna (6.1): è necessario definire tutti i ruoli e le responsabilità per la sicurezza delle informazioni, separazioni dei compiti, modalità di contatto con le autorità e con gruppi specialistici ed infine le modalità di gestione dei progetti con riferimento alla sicurezza delle informazioni.
• Dispositivi portatili e telelavoro (6.2): in questa categoria sono raggruppati due controlli molto importanti che, forse, meriterebbero una trattazione separata, anche se poi i controlli relativi sono descritti in modo dettagliato. I dispositivi portatili da gestire e mantenere sotto controllo sono di diverse tipologie (notebook, tablet, smartphone, …) ed ognuna di essa meriterebbe una trattazione a sé, così come la proprietà del dispositivo (azienda, dipendente o collaboratore, o semplice visitatore) ed il tipo di impiego (esclusivamente aziendale, esclusivamente privato o misto come nel caso del BYOD, Bring Your Own Device). Per quanto riguarda il telelavoro occorre tenere sotto controllo diversi parametri ed aspetti di sicurezza fisica e logica, non trascurando il fatto che ora il telelavoro è inteso in senso più ampio rispetto alla precedente versione della norma.

Quest’area è nel complesso più ridotta rispetto alla sezione 6 della precedente versione della norma che, tra l’altro, riportava la medesima categoria riferita a dispositivi portatili e telelavoro alla sezione 11, quella del controllo accessi. Del resto questa seconda categoria deve essere considerata in senso un po’ più ampio perché la sicurezza dei dispositivi portatili e del telelavoro deve essere valutata insieme alla gestione delle connessioni wi-fi e degli accessi a siti web aziendali e ad eventuali servizi cloud.

Francamente ci si poteva aspettare qualcosa di più in quest’area ove al 6.2 l’evoluzione tecnologica in questi ultimi 9 anni trascorsi dalla precedente versione della ISO 27002 ha fatto passi da gigante moltiplicando anche le possibili vulnerabilità e qualche citazione più specifica del problema del BYOD e dell’autenticazione a due fattori (2FA) sarebbe stata gradita.

7 Sicurezza delle risorse umane

In questa sezione sono descritte le attività da considerare per garantire la sicurezza nella gestione del personale prima, durante ed al termine del rapporto di lavoro:

• Prima dell’impiego (7.1): in due controlli vengono esposte tutte le cautele da intraprendere al momento dell’assunzione di una persona o dell’incarico ad un collaboratore esterno, non solo accordi di riservatezza e clausole contrattuali sul futuro rapporto lavorativo, ma anche – per quanto reso possibile dalla legislazione applicabile – un’accurata indagine conoscitiva sul passato, lavorativo e non, del futuro dipendente/collaboratore.
• Durante l’impiego (7.2): nel corso della normale attività lavorativa viene data enfasi all’applicazione delle procedure stabilite e le responsabilità della Direzione nell’applicazione delle stesse, alla formazione-addestramento e sensibilizzazione del personale ed al ricorso ad eventuali processi disciplinari. Dunque regole da rispettare, ma anche motivazione ed incentivazione del personale, oltre che sanzioni a chi infrange le regole.
• Cessazione e variazione del rapporto di lavoro (7.3): vengono presi in esame tutti gli aspetti e le attività da svolgere quando si chiude un rapporto di lavoro o avviene un’assegnazione ad altro incarico, come ad esempio il prolungamento della validità degli accordi di riservatezza, i passaggi di consegne e la comunicazione all’altro personale interessato della cessazione del rapporto di lavoro.

Qualche perplessità desta la traduzione UNI in quest’area: viene utilizzato il termine “soffiare” in senso di “soffiata”, “spiata”, “delazione”, “informazione anonima su un comportamento non corretto” ed il termine “inazioni” probabilmente intendendo “omissioni” o il contrario di azioni, ovvero il “non agire”.

I contenuti sono analoghi a quelli della precedente versione della norma alla sezione 8, anche se i controlli sono in numero minore.

8 Gestione degli asset

In quest’area viene trattata la gestione degli asset (tradotti come “beni” nella precedente versione della norma ISO 27001) all’interno di tre categorie:

• Responsabilità per gli asset (8.1): tutti gli asset aziendali vanno inventariati, ne deve essere definito un responsabile e le regole per l’utilizzo e la gestione durante tutto il ciclo di vita.
• Classificazione delle informazioni (8.2): le informazioni dovrebbero essere classificate in funzione del livello di riservatezza richiesto e conseguentemente etichettate in funzione della loro classificazione. Le procedure per il trattamento degli asset dovrebbero essere una logica conseguenza della classificazione degli stessi e delle informazioni in essi trattate.
• Trattamento dei supporti (8.3): al fine di garantire riservatezza, integrità e disponibilità delle informazioni contenute nei supporti rimovibili (hard-disk esterni, chiavi USB, DVD, ecc.) occorre prevedere opportune procedure di gestione degli stessi durante tutto il loro ciclo di vita (impiego, dismissione, trasporto, ecc.).

Nella presente sezione – praticamente immutata rispetto alla corrispondente sezione 7 della precedente versione della norma, salvo l’aggiunta di due controlli – viene richiamata la classificazione degli asset finalizzata alla valutazione dei rischi contenuta nella ISO 27005.

9 Controllo degli accessi

Questa sezione tratta l’importante aspetto del controllo degli accessi alle aree dove sono custodite informazioni, in formato digitale o su supporto cartaceo, sia dal punto di vista degli accessi fisici, sia dal punto di vista degli accessi logici ai sistemi informatici. Le categorie prese in esame sono le seguenti:

• Requisiti di business per il controllo degli accessi (9.1): occorre definire una politica di controllo degli accessi basata sull’accesso alle sole informazioni necessarie per svolgere il proprio lavoro (come impone anche la normativa sulla privacy in vigore in Italia) e regolamentare l’accesso alle reti (soprattutto evitare l’uso incontrollato delle reti wi-fi senza autenticazione utente).
• Gestione degli accessi degli utenti (9.2): è necessario regolamentare il processo di registrazione (tramite credenziali di autenticazione univoche) e de-registrazione degli utenti, la fornitura delle credenziali di accesso (provisioning), la gestione degli accessi privilegiati (ad es. quelli in qualità di “amministratore di sistema”, cfr. apposita disposizione del Garante della Privacy), la gestione delle informazioni segrete per l’autenticazione (password, smartcard, ecc.), il riesame periodico dei diritti di accesso, la rimozione degli stessi al termine del rapporto (o la revisione in caso di cambio mansioni).
• Responsabilità dell’utente (9.3): è importante regolamentare ed istruire il personale sull’uso della password.
• Controllo degli accessi ai sistemi e alle applicazioni (9.4): è opportuno limitare l’accesso alle informazioni, predisporre procedure di log-on sicure, procedure di gestione delle password, limitare l’impiego di programmi di utilità privilegiati, limitare gli accessi al codice sorgente dei programmi.

Nei controlli esposti sono illustrati molti principi di sicurezza delle informazioni abbastanza noti ai più, ma spesso non recepiti nelle PMI per scarsa competenza dei responsabili IT (spesso esterni), richieste di gestioni semplificate da parte degli utenti e dei responsabili, mancanza di consapevolezza da parte della Direzione e, soprattutto, la ricerca del minor costo nelle apparecchiature e nella formazione del personale. Per questo motivo molte regole basilari, ad esempio relative ad una corretta gestione della rete wi-fi (creazione di accessi “ospite” per gli esterni, impiego di autenticazioni per singolo utente tramite protocollo Radius o da pannello di controllo del router, segmentazione delle reti in Vlan, …) e delle password (impiego di password complesse e memorizzate in modo sicuro tramite utility apposite, uso non promiscuo delle password, variazione delle password al primo accesso,…) spesso non vengono implementate.

Nel complesso sono presenti molti meno controlli rispetto alla precedente versione della norma alla sezione 11, ma i contenuti, opportunamente aggiornati, sono equivalenti.

10 Crittografia

Questo punto di controllo prevede una sola categoria “Controlli crittografici” (10.1) all’interno della quale sono descritti due controlli inerenti la politica relativa all’impiego dei controlli crittografici e la gestione delle chiavi crittografiche. La trattazione è molto dettagliata e comprende diversi aspetti da non sottovalutare come cosa fare in caso di indisponibilità, temporanea o permanente, delle chiavi crittografiche. In Italia occorre considerare la normativa specifica sulla firma digitale e la gestione dei certificati tramite le certification authority accreditate. Viene richiamata la norma ISO/IEC 11770 per ulteriori informazioni sulle chiavi.

Questa che era prima una categoria (cfr. punto 12.3 della norma ISO 27002:2005) ora è salito a livello di punto di controllo.

11 Sicurezza fisica e ambientale

La sezione comprende due categorie:

• Aree sicure (11.1): devono essere definiti dei perimetri che delimitano aree con diversi livelli di sicurezza, nei quali occorre prevedere adeguate protezioni per prevenire accessi indesiderati e safety (viene citata la normativa antincendio), devono essere attivati sistemi di controllo e registrazione degli accessi alle aree sicure, devono essere implementate particolari misure di sicurezza fisica per proteggere aree chiave e devono essere adottate misure di protezione contro disastri e calamità naturali (incendi, alluvioni, terremoti, ecc.). Inoltre devono essere progettate ed attuate procedure per permettere il lavoro in aree sicure e protette e, infine, devono essere implementati controlli particolari nelle aree di carico/scarico materiali.
• Apparecchiature (11.2): particolari accorgimenti devono essere intrapresi per proteggere le apparecchiature impiegate (per elaborazione o archiviazione di informazioni in genere) rispetto ad accessi non consentiti o minacce di possibili danneggiamenti, anche provenienti dalle infrastrutture di supporto (connettività di rete, energia elettrica, gas, acqua, ecc.) o da carenze di sicurezza dei cablaggi. Inoltre le apparecchiature devono essere sottoposte a regolare manutenzione, dispositivi hardware e software devono essere mantenuti sotto controllo in caso di trasferimenti all’esterno dell’organizzazione, adottando, nel caso particolari misure di sicurezza ed in caso di dismissione di apparecchiature o supporti di memorizzazione le informazioni in essi contenute devono essere cancellate in modo sicuro. Infine è necessario definire istruzioni affinché le apparecchiature non siano lasciate incustodite quando con esse è possibile accedere ad informazioni riservate ed occorre definire politiche di “scrivania pulita” per prevenire la visione di informazioni riservate da parte di personale non autorizzato.

fine I parte ….continua…

La norma ISO 27001 pubblicata nel 2013 è stata tradotta in italiano e convertita in norma UNI nel marzo 2014 come UNI CEI ISO/IEC 27001:2014 – Tecnologie informatiche – Tecniche per la sicurezza – Sistemi di gestione per la sicurezza delle informazioni – Requisiti. Essa specifica i requisiti per stabilire, attuare, mantenere e migliorare in modo continuo un sistema di gestione per la sicurezza delle informazioni nel contesto di un’organizzazione, includendo anche i requisiti per valutare e trattare i rischi relativi alla sicurezza delle informazioni adattati alle necessità dell’organizzazione.

La nuova ISO 27001 non riporta termini e definizioni, ma richiama la ISO 27000.2014 (scaricabile gratuitamente da http://standards.iso.org/ittf/licence.html) per tutti i termini utilizzati nelle norme della serie ISO 27k.

Si segnala che nel capitolo introduttivo della ISO 27001 è scomparso il paragrafo “Approccio per processi”, sebbene venga sottolineata l’importanza che il sistema di gestione per la sicurezza delle informazioni sia parte integrante dei processi e della struttura gestionale complessiva dell’organizzazione.

La norma ISO 27001 riprende la nuova struttura di tutte le norme sui sistemi di gestione e, pertanto, al capitolo 4 tratta il “contesto dell’organizzazione”. In questo capitolo viene esposto che per comprendere l’organizzazione e il suo contesto (4.1) occorre determinare i fattori esterni ed interni pertinenti alle finalità dell’organizzazione stessa e che influenzano la sua capacità di conseguire i risultati previsti per il proprio sistema di gestione per la sicurezza delle informazioni e che per comprendere le necessità e le aspettative delle parti interessate (4.2) occorre individuare le parti interessate al sistema di gestione per la sicurezza delle informazioni ed i requisiti delle stesse attinenti ad esso.

Anche la determinazione del campo di applicazione del Sistema di Gestione per la Sicurezza delle Informazioni (SGSI o ISMS, Information Security Management System) è un’attività inerente la comprensione dell’organizzazione ed il suo contesto. In questo ambito l’organizzazione deve determinare i confini di applicabilità del sistema di gestione per la sicurezza delle informazioni ISO 27001 al fine di stabilirne il campo di applicazione, in modo analogo a quanto avveniva nella versione precedente della norma, considerando anche i fattori esterni ed interni ed i requisiti delle parti interessate esposti ai paragrafi precedenti.

Il capitolo 5 “Leadership” rispecchia anch’esso la nuova struttura delle norme sui sistemi di gestione. In esso, al paragrafo 5.1, viene indicato quali modalità l’alta direzione deve attuare per dimostrare leadership e impegno nei riguardi del sistema di gestione per la sicurezza delle informazioni. In analogia con altri sistemi di gestione, l’alta direzione deve stabilire politica ed obiettivi, mettere a disposizione le risorse necessarie per l’attuazione del SGSI, comunicare l’importanza di un’efficace gestione della sicurezza delle informazioni e dell’essere conforme ai requisiti del SGSI stesso; deve, inoltre, assicurare che il SGSI ISO 27001 consegua i risultati previsti, fornire guida e sostegno al personale per contribuire all’efficacia del sistema di gestione della sicurezza delle informazioni e, naturalmente, deve promuovere il miglioramento continuo.

Il paragrafo 5.2 tratta della politica per la sicurezza delle informazioni per la quale i requisiti sono analoghi a quelli presenti negli altri sistemi di gestione: naturalmente la politica deve essere documentata, comunicata all’interno dell’organizzazione ed essere disponibile a tutte le parti interessate.

Anche il paragrafo 5.3 – che riguarda ruoli, responsabilità e autorità nell’organizzazione – è molto simile a quanto riportato nelle altre norme sui sistemi di gestione; in particolare, il fatto che la l’alta direzione debba assegnare responsabilità e autorità per assicurare che il sistema di gestione per la sicurezza delle informazioni sia conforme ai requisiti della norma e per riferire alla direzione stessa sulle prestazioni del sistema di gestione per la sicurezza delle informazioni, se non definisce la nomina di un responsabile per il sistema di gestione della sicurezza delle informazioni poco ci manca. Pur non essendo richiesto un rappresentante della direzione (non lo era neanche nella versione 2005 ISO e 2006 UNI della norma) viene rafforzato il concetto che è necessario assegnare responsabilità precise, all’interno o all’esterno dell’organizzazione (consulente), per garantire la conformità del SGSI.

Il capitolo 6 “Pianificazione” tratta, nel paragrafo 6.1, quali azioni occorre attuare per affrontare rischi ed opportunità. Infatti sulla base di quanto emerso dall’analisi del contesto dell’organizzazione occorre determinare i rischi e le opportunità che è necessario affrontare per assicurare che il sistema possa conseguire i risultati previsti, possa prevenire, o almeno ridurre, gli effetti indesiderati e realizzare il miglioramento continuo. Le azioni per affrontare rischi ed opportunità devono essere pianificate, così come le modalità per integrare ed attuare le azioni stesse nei processi del proprio sistema di gestione per la sicurezza delle informazioni e per valutare l’efficacia di tali azioni.

La valutazione dei rischi relativi alla sicurezza delle informazioni è trattata al paragrafo 6.1.2, dove sono riportati i requisiti per il processo di valutazione del rischio relativo alla sicurezza delle informazioni. Il processo di valutazione del rischio dovrà comprendere le seguenti attività

• Stabilire e mantenere i criteri di rischio relativo alla sicurezza.
• Assicurare che le ripetute valutazione del rischio producano risultati coerenti, validi e confrontabili tra loro (il metodo usato deve essere ripetibile e riproducibile con risultati coerenti come se fosse un dispositivo di misurazione sotto conferma metrologica).
• Identificare i rischi relativi alla sicurezza.
• Analizzare i rischi individuati, valutando le possibili conseguenze che risulterebbero se tali rischi si concretizzassero e valutando la verosimiglianza realistica di concretizzarsi dei rischi identificati, ovvero la probabilità che essi accadono, e, infine, determinando i livelli di rischio.
• Ponderare i rischi comparando i risultati dell’analisi dei rischi con i criteri stabiliti e definendo le priorità di trattamento dei rischi precedentemente valutati.

Naturalmente la valutazione dei rischi deve essere documentata.

Il trattamento del rischio relativo la sicurezza delle informazioni (6.1.3) deve essere definito ed applicato attraverso un processo del tutto similare a quello stabilito nella versione precedente della norma, anche se esposto in modo differente. Oltre a selezionare l’opzione di trattamento dei rischi consuete occorre determinare i controlli necessari per attuare le opzioni selezionate per il trattamento del rischio, tenendo presente controlli riportati nell’appendice A e meglio dettagliati nella norma ISO 27002 (anch’essa tradotta finalmente in italiano come UNI CEI ISO/IEC 27002:2014 – Tecnologie informatiche – Tecniche per la sicurezza – Raccolta di prassi sui controlli per la sicurezza delle informazioni) al fine di non omettere controlli che potrebbero essere necessari.

Resta la necessità di redigere una Dichiarazione di Applicabilità che riporti:

• i controlli selezionati come necessari (che siano attuati o meno) e la relativa giustificazione per l’inclusione;
• i controlli presenti nell’Appendice A della ISO 27001 stessa eventualmente esclusi con le giustificazioni per la loro esclusione
• i controlli selezionati attualmente applicati.

Quest’ultimo punto costituisce una novità nel testo della norma che chiarisce e sancisce una prassi comunemente adottata dagli Organismi di Certificazione, ovvero quella di accettare una dichiarazione di applicabilità di determinati controlli di sicurezza la cui attuazione è stata pianificata, ma deve ancora venire.

Infine occorre predisporre un piano di trattamento dei rischi relativi alla sicurezza delle informazioni che dovrà essere approvato dalla Direzione, comprendente anche l’accettazione dei rischi residui che si è deciso di non trattare.

Anche questo processo di trattamento del rischio dovrà essere documentato.

Il sistema di gestione per la sicurezza delle informazioni ISO 27001 dovrà porsi degli obiettivi e pianificare le azioni adeguate per conseguirli (paragrafo 6.2). Le caratteristiche degli obiettivi sono le stesse degli altri sistemi di gestione (devono essere coerenti con la politica, misurabili, ecc.).

La pianificazione delle azioni poste in essere per conseguire gli obiettivi per la sicurezza delle informazioni deve comprendere le azioni pianificate, le risorse necessarie, le responsabilità, i tempi di completamento delle azioni, e le modalità di valutazione dei risultati.

Il capitolo 7 “Supporto” non presenta novità significative rispetto all’analogo capitolo delle altre norme relative ad altri sistemi di gestione. Pertanto i paragrafi Risorse (7.1), Competenza (7.2) Consapevolezza (7.3) e Comunicazione (7.4) non presentano sorprese di sorta, ma solo una esplicitazione più chiara rispetto al passato di cosa ci si dovrebbe attendere da un sistema di gestione per la sicurezza delle informazioni.

Il paragrafo 7.5 “Informazioni documentate” con i suoi sotto paragrafi descrive i requisiti relativi a documenti e registrazioni, secondo la dizione delle precedenti norme sui sistemi di gestione. Anche in questo caso i requisiti non presentano novità rispetto al passato, ma solo un diverso ordine di esposizione ed una maggior chiarezza nel descrivere che cosa ci si aspetta da un sistema di gestione documentato.

Non sono richieste procedure particolari, né un manuale del sistema di gestione ISO 27001, ma solo le informazioni documentate indicate nei vari punti della norma.

Il capitolo 8 “Attività operative” dispone requisiti relativi ai punti:

• pianificazione e controlli operativi (8.1);
• valutazione del rischio relativo la sicurezza delle informazioni (8.2);
• trattamento del rischio relativo la sicurezza delle informazioni (8.3).

In questo capitolo non ci sono novità rispetto alla versione precedente della norma, ma solo una riscrittura secondo la nuova struttura delle norme sui sistemi di gestione di quanto era già prescritto in passato. I contenuti, in verità, sono alquanto scarni, infatti viene prescritto di mantenere sotto controllo i processi operativi dell’organizzazione (processo produttivo o erogazione del servizio, approvvigionamenti, commerciale, ecc.) attraverso l’attuazione di tutti i controlli di sicurezza pianificati, monitorando ogni cambiamento e rivalutando periodicamente i rischi secondo le modalità già descritte nei paragrafi deò capitolo 6.

Il capitolo 9 “Valutazione delle prestazioni”, riporta i requisiti per il monitoraggio, la misurazione, l’analisi e la valutazione (9.1) del SGSI, per gli audit interni (9.2) e per il riesame della direzione (9.3). Anche in questo capitolo non sono presenti novità sostanziali rispetto alla precedente versione della norma, ma solo una riscrittura del testo in modo più chiaro. In particolare viene indicata la necessità di monitorare e misurare l’efficacia dell’attuazione dei controlli di sicurezza e tutti i processi che forniscono evidenza del buon funzionamento del SGSI.

Nel capitolo 10 “Miglioramento” sono trattate non conformità, azioni correttive e miglioramento continuo. Anticipando quello che avverrà per la prossima versione della norma ISO 9001:2015, si rileva l’eliminazione delle requisito riguardante le azioni preventive che vanno a confluire insieme a tutte le azioni di miglioramento non legate a non conformità o incidenti sulla sicurezza delle informazioni.

È curioso il fatto che mentre nella versione precedente la norma ISO 27001 non dedicava un paragrafo alle non conformità, che venivano citate nel testo, ma erano citati anche gli incidenti per la sicurezza delle informazioni, questa nuova versione non tratta gli incidenti – se non nei controlli dell’appendice A – e dedica il paragrafo 10.1 alle non conformità ed alle azioni correttive attuate per eliminarle.

Si ricorda che ACCREDIA ha disposto che Tutte le certificazioni emesse sotto accreditamento a fronte della ISO/IEC 27001:2005 dovranno essere ritirate entro il 1° ottobre 2015; oltre tale data potranno sussistere solo certificazioni secondo la nuova ISO 27001:2013. Pertanto restano pochi mesi per convertire i vecchi SGSI alla nuova norma. Probabilmente la stragrande maggioranza delle organizzazioni con SGSI certificato o certificando ISO 27001 dispongono già della certificazione ISO 9001 per la qualità, ma la nuova norma ISO 9001:2015, la cui struttura è allineata alla ISO 27001:2013 deve ancora essere ufficialmente emessa.

Il consiglio per le organizzazioni che si stanno adeguando alla 27001:2013 è quello di strutturare il sistema di gestione integrato secondo il nuovo schema, dunque allineare anche il sistema di gestione per la qualità sulla base delle indicazioni disponibili dalla bozza di ISO 90001:2015. Così facendo si avrà un sistema di gestione integrato ISO 9001-27001 omogeneo e meglio gestibile nell’immediato.

Questo probabilmente comporterà ristrutturare il manuale del sistema di gestione, anche se non esplicitamente richiesto dalla nuova norma, al fine di mantenere una continuità con il passato e garantire il controllo su tutta la documentazione del sistema di gestione.

Le modifiche al SGSI non sono sostanziali e riguardano più che altro i 114 controlli di sicurezza dell’appendice A e della ISO 27002 che naturalmente impattano sul trattamento dei rischi e sulla Dichiarazione di Applicabilità (Statement of Applicability, SoA).

La norma UNI CEI ISO 27001 (Sistemi di gestione della sicurezza delle informazioni – Requisiti), recentemente pubblicata in nuova versione 2013 dall’ISO, richiede una valutazione preliminare dei rischi sulla sicurezza delle informazioni (punto 4.2.1) al fine di implementare un sistema di gestione della sicurezza delle informazioni idoneo a trattare i rischi che l’organizzazione effettivamente corre in merito all’Information Security.

Gli approcci possibili alla valutazione dei rischi possono essere diversi ed i metodi per effettuare il cosiddetto Risk Assessment possono variare di caso in caso, in funzione della dimensione, della complessità e del tipo di organizzazione che si sta esaminando.

La ISO 27005 (Information security risk management) è il principale riferimento per la gestione del rischio in ambito sicurezza delle informazione, ma anche altre norme quali la ISO 31000 (Risk management – Principles and guidelines) – recepita in Italia come UNI ISO 31000 (Gestione del rischio – Principi e linee guida) – e ISO 31010 (Risk management – Risk assessment techniques) possono essere prese a riferimento.

Vediamo un esempio di possibile approccio alla gestione del rischio finalizzato a preparare una valutazione dei rischi sulla sicurezza delle informazioni.

Il processo di gestione dei rischi comprende le seguenti fasi, descritte nel seguito:

1)      Identificazione dei rischi

2)      Analisi e ponderazione dei rischi

3)      Identificazione e valutazione delle opzioni per il trattamento dei rischi

4)      Scelta degli obiettivi di controllo ed i controlli per il trattamento dei rischi

5)      Accettazione dei rischi residui.

Le attività suddette vengono descritte nel Rapporto di valutazione dei rischi (Risk assessment report).

L’identificazione dei rischi che incombono sulla sicurezza delle informazioni avviene attraverso:

a)      L’identificazione degli asset significativi all’interno del SGSI: tale attività avviene come descritto nella procedura Identificazione e valutazione degli asset.

b)      La valorizzazione ai fini del SGSI degli asset rilevati: tale attività avviene come descritto nella procedura Identificazione e valutazione degli asset. La valorizzazione degli asset in termini di riservatezza, integrità e disponibilità avviene per singolo asset oppure per gruppi di asset omogenei ai fini del SGSI; nel seguito in entrambe le situazioni si utilizzerà il termine asset intendendosi anche “raggruppamento di asset”.

c)       Identificazione delle minacce/pericoli che incombono sugli asset: tale attività viene svolta valutando le minacce note della letteratura e quelle ipotetiche specifiche in relazione ai servizi svolti dall’organizzazione. Le minacce vengono associate agli asset (e quindi alle informazioni che essi gestiscono) e vengono valorizzate in una scala da 1 a 3 (Bassa, Media, Alta). La stessa minaccia può assumere un livello di gravità diverso a seconda dell’asset cui si applica..

d)      Identificazione delle vulnerabilità: tale attività viene svolta valutando le vulnerabilità note della letteratura, quelle ufficiali comunicate da fonti autorevoli e quelle ipotetiche specifiche in relazione ai servizi svolti dall’organizzazione. Le vulnerabilità vengono associate agli asset (e quindi alle informazioni che essi gestiscono) e vengono valorizzate in una scala da 1 a 3 (Bassa, Media, Alta). La stessa vulnerabilità può assumere un livello di gravità diverso a seconda dell’asset cui si applica.

e)      Identificazione degli impatti o conseguenze che la perdita dei requisiti di riservatezza, integrità e disponibilità possono avere sugli asset. Le conseguenze del concretizzarsi di una minaccia in grado di sfruttare una vulnerabilità vengono anch’esse valorizzate attraverso la formula seguente:

Impatto = Valore Asset x Gravità Minaccia x Gravità Vulnerabilità.

L’analisi e ponderazione dei rischi per la sicurezza delle informazioni identificati avviene attraverso:

a)      La valutazione della probabilità che si verifichino i singoli rischi identificati nella fase precedente. La probabilità di accadimento di un rischio avviene considerando gli incidenti verificatisi in passato e statistiche eventualmente disponibili. L’assegnazione di una livello di probabilità attraverso una scala qualitativa avviene secondo il seguente schema:

Valore	Descrizione	Esempio
1	Mai verificatosi ma possibile	Non è mai accaduto nella storia dell’organizzazione
2	Raro	Accaduto una volta all’anno
3	Periodico	Accaduto circa 3 volte l’anno
4	Regolare	Accaduto circa una volta al mese
5	Frequente	Si verifica settimanalmente

b)      Determinazione dell’indice di esposizione al rischio moltiplicando la gravità dell’impatto per la probabilità. Il risultato ottenuto sarà un valore da 3 a 81.

c)       Definizione dei criteri di accettazione dei rischi: si stabilisce un livello minimo di tolleranza dei rischi al di sotto del quale i rischi vengono accettati ed al di sopra del quale i rischi devono essere trattati con azioni mirate.

Relativamente alla identificazione e valutazione delle opzioni per il trattamento dei rischi, per i rischi che si è deciso di trattare, in ordine decrescente dal maggiore al minore, vengono scelte delle azioni di mitigazione del rischio, che possono consistere nelle seguenti opzioni:

• Ridurre il rischio attraverso l’applicazione di obiettivi di controllo e controlli preventivi e correttivi, finalizzati alla riduzione degli effetti (impatto) del verificarsi del rischio e/o alla riduzione della probabilità che si verifichi.
• Evitare il rischio attraverso l’applicazione di obiettivi di controllo e controlli finalizzati ad evitare che si concretizzino le situazioni che permettono al rischio di concretizzarsi, ovvero ridurre a zero la probabilità che l’incidente paventato si verifichi.
• Trasferire il rischio attraverso la stipula di polizze assicurative oppure l’esternalizzazione a fornitori di processi ed attività con la relativa presa in carico da parte del fornitore dei relativi rischi.

Tali azioni vengono documentate nel Piano di trattamento dei rischi. Esso deve definire le singole azioni da intraprendere, i tempi e le relative responsabilità e risorse per gestire i singoli rischi. L’efficacia delle azioni pianificate porterà ad un ricalcolo della valutazione dei rischi, ottenendo nuovi indici.

La scelta degli obiettivi di controllo e dei controlli per il trattamento dei rischi da attuare avviene in base dall’elenco dei controlli applicabili definito a partire dai controlli identificati a livello normativo (norme della famiglia ISO 27000) a cui si possono aggiungere altri controlli ritenuti utili.

I controlli vengono ritenuti applicabili o non applicabili, se applicabili possono essere attuati in modo completo o parziale. L’applicazione dei controlli può infatti essere ritenuta conveniente solo su alcuni processi/attività, in funzione della diversa esposizione al rischio che possiedono le varie attività svolte dall’organizzazione.

L’attuazione del piano di trattamento dei rischi porta all’accettazione dei rischi residui, ovvero ad evidenziare i rischi residui ritenuti accettabili, dato dall’insieme dei rischi valutati accettabili in sede di prima valutazione dei rischi ed i rischi residui trattati dalle azioni contenute nel piano di trattamento dei rischi.

Il piano di trattamento dei rischi riporta le seguenti informazioni:

1)      Elenco dei rischi da trattare;

2)      Descrizione delle relazioni fra il rischio e l’azione di trattamento del rischio prescelta;

3)      Descrizione delle relazioni fra il rischio e gli obiettivi di controllo ed i controlli selezionati per gestire il rischio.

Lo scopo della procedura Identificazione e valutazione degli asset (predisposta con riferimento alla ISO 27005 – Information technology — Security techniques — Information security risk management – Annex B – Identification and valuation of assets and impact assessment) dovrebbe essere quello di definire le modalità operative e le responsabilità per l’effettuazione e l’aggiornamento del censimento dei beni (asset) aziendali e la relativa valutazione, in termini di riservatezza, integrità e disponibilità delle stesse. In essa vengono stabiliti:

• la classificazione degli asset;
• l’identificazione di ogni asset che ha impatto sulla sicurezza delle informazioni;
• la valutazione quantitativa di ogni asset in relazione alla sua importanza per la sicurezza delle informazioni.

La classificazione degli asset potrebbe distinguere due categorie principali di asset:

1. Asset primari: processi/attività ed informazioni;
2. Asset di supporto: hardware, software, reti, personale, sito, struttura organizzativa.

Gli asset possono essere delle seguenti tipologie:

1. Information asset: dati digitali e non digitali, sistemi operativi, software applicativo, beni intangibili (conoscenza, marchi, brevetti, …).
2. Asset fisici: infrastruttura IT, Hardware, Sistemi di controllo, Servizi IT.
3. Risorse Umane: dipendenti, collaboratori esterni e consulenti.

L’identificazione e ed il censimento degli asset aziendali (asset inventory) ha lo scopo di identificare i requisiti di sicurezza (riservatezza, integrità e disponibilità) degli stessi e valutarne possibili vulnerabilità.

Ad ogni information asset deve essere associato un valore in termini di Riservatezza, Integrità e Disponibilità; tale valore viene espresso in termini qualitativi attraverso l’attribuzione di un  livello di importanza (Basso, Medio, Alto) a cui è associato un valore numerico crescente (1,2,3).

Ad ogni asset di supporto o asset non informativo (risorse fisiche e risorse umane) viene associato un valore in termini di criticità dell’asset, dato dalla somma dei valori di importanza dei requisiti dell’asset in termini di Riservatezza, Integrità, Disponibilità in funzione delle informazioni che esso gestisce. Dunque l’importanza di una risorsa per la sicurezza dipende dai requisiti di Riservatezza, Integrità e Disponibilità, espressi in livelli (Basso/Medio/Alto) a cui corrisponde il valore 1/2/3.

Di conseguenza il valore associato all’asset potrà variare da un minimo di 3 (Riservatezza=Basso + Integrità=Basso + Disponibilità=Basso) ad un massimo di 9 (Riservatezza=Alto + Integrità=Alto + Disponibilità=Alto).

Poiché gli asset possono essere di diversi tipi (risorse fisiche e risorse umane), la metodologia di valutazione dei requisiti di sicurezza delle informazioni è differente per ogni tipo di asset.

Il Valore dell’Asset in termini di sicurezza delle informazioni viene utilizzato nel Risk Assessment in combinazione con:

• le minacce che incombono sugli asset che possono sfruttare le vulnerabilità rilevate degli asset stessi;
• la probabilità che la minaccia si concretizzi in un incidente di sicurezza (delle informazioni);
• la gravità dell’impatto associato all’incidente.