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.

Lo scorso dicembre – dopo lunghe discussioni – è stata pubblicata la norma UNI 11697:2017 “Attività professionali non regolamentate – Profili professionali relativi al trattamento e alla protezione dei dati personali – Requisiti di conoscenza, abilità e competenza”, inerente la definizione dei requisiti relativi all’attività professionale dei soggetti operanti nell’ambito del trattamento e della protezione dei dati personali (compreso il DPO), da questi esercitata a diversi livelli organizzativi (pubblico o privato).

L’UNI dichiara che “La norma definisce i profili professionali relativi al trattamento e alla protezione dei dati personali coerentemente con le definizioni fornite dall’EQF e utilizzando gli strumenti messi a disposizione dalla UNI 11621-1 Attività professionali non regolamentate – Profili professionali per l’ICT – Parte 1: Metodologia per la costruzione di profili professionali basati sul sistema e-CF“.

La norma, anche dopo la sua uscita, è stata fonte di animate discussioni fra gli esperti del settore e, soprattutto, è stata vivacemente contestata da chi ritiene che non esponga in modo chiaro e preciso i requisiti professionali delle figure in oggetto oppure definisca delle figure professionali favorevoli a certi profili piuttosto che altri.

Le figure professionali delineate dalla norma UNI sono le seguenti:

1. Data Protection Officer (DPO), figura di supporto al titolare o responsabile del trattamento nell’applicazione e per l’osservanza del Regolamento (UE) 2016/679, in conformità all’ art. 37 (Designazione del Responsabile della protezione dei dati), art. 38 (Posizione del Responsabile della protezione dei dati) e art. 39 (Compiti del Responsabile della protezione dei dati).
2. Manager Privacy, figura che assiste il titolare nelle attività di coordinamento di tutti i soggetti che – nell’organizzazione – sono coinvolti nel trattamento di dati personali (responsabili, incaricati, amministratori di sistema, ecc.), garantendo il rispetto delle norme in materia di privacy e il mantenimento di un adeguato livello di protezione dei dati personali.
3. Specialista Privacy, figura di supporto appositamente formato (è richiesta una formazione minima di 24 ore), che collabora con il Manager Privacy e cura la corretta attuazione del trattamento dei dati personali all’interno dell’organizzazione, svolgendo le attività operative che, di volta in volta, si rendono necessarie durante tutto il ciclo di vita di un trattamento di dati personali.
4. Valutatore Privacy, figura dotata di una apposita formazione (minima di 40 ore) che si caratterizza per la sua terzietà sia nei confronti del Manager che dello Specialista Privacy; egli esercita una attività di monitoraggio (audit) andando ad esaminare periodicamente il trattamento dei dati personali e valutando il rispetto delle normative di settore emanate.

Concentriamoci sulla figura del DPO o RPD. La norma definisce una descrizione sintetica del profilo, una missione, dei risultati attesi, dei compiti principali, delle competenze, delle abilità e delle conoscenze.

Per ognuna delle competenze assegnate seguenti è definito un livello di competenza:

• Pianificazione di Prodotto o di Servizio
• Sviluppo della Strategia per la Sicurezza Informatica
• Gestione del Contratto
• Sviluppo del Personale
• Gestione del Rischio
• Gestione delle Relazioni
• Gestione della Sicurezza dell’Informazione
• Governante dei sistemi informativi

Tra le Abilità (Skill) stabilite che deve possedere il DPO si segnalano:

• Contribuire alla strategia per il trattamento e per la protezione dei dati personali
• Capacità di analisi
• Capacità organizzative
• Pianificazione e programmazione
• Saper analizzare gli asset critici dell’azienda ed identificare debolezze e vulnerabilità riguardo ad intrusioni o attacchi
• Saper anticipare i cambiamenti richiesti alla strategia aziendale dell’information security e formulare nuovi piani
• Saper applicare gli standard, le best practice e i requisiti legali più rilevanti all’information security
• Garantire che la proprietà intellettuale (IPR) e le norme della privacy siano rispettate
• egoziare termini e condizioni del contratto
• Preparare i template per pubblicazioni condivise
• Progettare e documentare i processi dell’analisi e della gestione del rischio
• Essere in grado di seguire e controllare l’uso effettivo degli standard documentativi aziendali

Invece tra le Conoscenze (Knowledge) possedute dal DPO vi sono:

• I principi di privacy e protezione dei dati by design e by default I diritti degli interessati previsti da leggi e regolamenti vigenti Le responsabilità connesse al trattamento dei dati personali
• Norme di legge italiane ed europee in materia di trattamento e di protezione dei dati personali
• Norme di legge in materia di trasferimento di dati personali all’estero e circolazione dei dati personali extra UE
• Le metodologie di valutazione d’impatto sulla protezione dei dati e PIA
• Le norme tecniche ISO/IEC per la gestione dei dati personali
• Le tecniche crittografiche
• Le tecniche di anonimizzazione
• Le tecniche di pseudonimizzazione
• Sistemi e tecniche di monitoraggio e “reporting”
• Gli strumenti di controllo della versione per la produzione di documentazione
• I rischi critici per la gestione della sicurezza
• I tipici KPI (key performance indicators)
• Il ritorno dell’investimento comparato all’annullamento del rischio
• la computer forensics (analisi criminologica di sistemi informativi)
• La politica di gestione della sicurezza nelle aziende e delle sue implicazioni con gli impegni verso i clienti, i fornitori e i sub-contraenti
• Le best practice (metodologie) e gli standard nella analisi del rischio
• Le best practice e gli standard nella gestione della sicurezza delle informazioni
• Le norme legali applicabili ai contratti
• Le nuove tecnologie emergenti (per esempio sistemi distribuiti, modelli di virtualizzazione, sistemi di mobilità, data sets)
• Le possibili minacce alla sicurezza
• Le problematiche legate alla dimensione dei data sets (per esempio big data)
• Le problematiche relative ai dati non strutturati (per esempio data analytics)
• Le tecniche di attacco informatico e le contromisure per evitarli

Fra le competenze richieste determinate dalla norma emergono profili afferenti a:

• Consulenti direzione
• Consulenti ed esperti di sistemi di gestione della sicurezza delle informazioni (famiglia delle norme ISO 27000)
• Auditor di sistemi di gestione
• Esperti di Risk Management
• Consulenti/esperti sulle normative attinenti alla privacy ed alla protezione dei dati personali (leggi, normative, disposizioni del Garante, ecc.)

Inoltre sono richieste conoscenze legali sulla contrattualistica, competenze sulla sicurezza informatica (tecniche di attacco, crittografia, ecc.) e sui sistemi informatici e relativi database.

Pur con le dovute precisazioni relative al fatto che il candidato DPO dovrà ricoprire un ruolo le cui caratteristiche dipendono fortemente dall’organizzazione in cui dovrà andare a operare, è evidente che prevalgono le competenze gestionali/manageriali e quelle relative alla sicurezza delle informazioni, piuttosto che quelle legali. Per quanto possa essere contestata, la norma chiaramente individua soggetti più vicini all’ingegnere dell’informazione che all’esperto legale come possibile DPO/RPD. Sicuramente le competenze legali eventualmente mancanti a un profilo molto vicino all’ingegnere dell’informazione sono più facilmente colmabili, anche attraverso consulenze specifiche, rispetto ad altre situazioni in cui il potenziale DPO si trova a dover colmare il gap di competenza relativo ai sistemi di gestione della sicurezza delle informazione, al risk management, alle basi di dati e magari anche alla cybersecurity.

Sicuramenteci sono in giro illustri avvocati esperti di info security e data protection, magari anche consulenti ed auditor ISO 27001, ma tutti coloro che si propongono per il ruolo di DPO con competenze essenzialmente giurisprudenziali saranno adatti a ricoprire il ruolo di DPO?

Naturalmente queste considerazioni valgono se si pensa di affidare il ruolo di DPO ad un’unica figura, con l’eventuale supporto di un team di esperti nelle varie discipline.

Chiaramente ogni organizzazione o ente pubblico che vorrà selezionare il proprio DPO potrà decidere come meglio crede in base ai compiti e le caratteristiche identificate per il DPO dal Regolamento UE 679/2016, ma la norma UNI 11697, volontaria, dice questo.

Il Regolamento (Ue) 2016/679, noto anche come RGPD (Regolamento Generale sulla Protezione dei Dati) o GDPR (General Data Protection Regulation), troverà piena attuazione esattamente fra un anno da oggi, il 25 maggio 2018, ovvero al termine del periodo di transizione.

A seguito dell’interessante seminario svoltosi venerdì 19 maggio 2017 presso l’Ordine degli Ingegneri di Bologna sulle possibili forme di certificazione in ambito Privacy, è utile fare qualche riflessione sull’attuazione di questa nuova normativa nelle organizzazioni del nostro Paese.

Attualmente esistono alcuni documenti ufficiali che permettono di comprendere meglio come declinare i requisiti del GDPR nella propria organizzazione, tra i quali:

• Linee Guida all’applicazione del RGPD del Garante Privacy italiano
• Linee guida sui responsabili della protezione dei dati (RPD) WP-243 (compreso l’allegato con le FAQ)
• Linee guida per la valutazione di impatto -WP248 .

Al momento, però, le indicazioni fornite non sono in grado di fugare tutti i dubbi sull’applicazione del GDPR, anzi!

Il GDPR dà spazio a integrazioni dei requisiti in esso riportati per regolamentare situazioni specifiche per tipo di dati trattati e particolari legislazioni nazionali, sarà compito del Garante Italiano definire eventuali disposizioni integrative che avranno valore di Legge.

Esaminando i concetti principali del GDPR, quali responsabilizzazione (accountability) del titolare e del responsabile del trattamento, privacy by design, privacy by default, valutazione di impatto, valutazione dei rischi e “misure di sicurezza adeguate”, è facile individuare molti punti di debolezza di numerose organizzazioni italiane che, per mentalità, non sono abituate ad affrontare il problema della protezione dei dati personali con metodo e come una reale priorità. Per molti vertici aziendali la privacy è “solo una scocciatura” e il nuovo Regolamento un “ennesimo obbligo cui toccherà adeguarsi”, ma non tanto prima della scadenza. Come se bastasse fare quattro documenti per risolvere il problema per sempre (o per lo meno fino al prossimo cambiamento normativo)!.

Purtroppo questo “approccio” per essere conformi al GDPR deve cambiare, perché è una norma di stampo anglosassone (tipo “common law”, a dispetto della Brexit) che richiede una forte responsabilizzazione di coloro che ricopriranno il ruolo di titolari (rappresentanti legali per le società) e responsabili del trattamento.

L’affidamento all’esterno di dati personali, anche solo per adempimenti legislativi, come la preparazione delle buste paga demandate allo Studio di Consulenza del Lavoro, devono richiedere un’attenta analisi del contratto con il soggetto esterno e verifica che esso soddisfi tutti i requisiti in termini di misure di sicurezza per la protezione dei dati.

Certamente per le PMI che trattano solo dati personali di dipendenti e collaboratori, oltre a nominativi di referenti di clienti e fornitori, l’adeguamento al GDP non sarà di particolare impatto, ma basta demandare all’esterno ad un servizio via web come la gestione del personale oppure avere un sito internet di e-commerce che raccoglie dati di utenti per rendere la gestione un pochino più complessa.

Viceversa le organizzazioni che trattano dati particolari (i.e. sensibili), soprattutto se poco strutturate e se gestiscono tali dati insieme a fornitori di servizi mediante internet, dovranno cambiare il loro atteggiamento sulla privacy e valutare attentamente i rischi che corrono. Soprattutto non credano che basti far scrivere un DPS o “riesumare” quello precedentemente redatto prima che il Governo lo abolisse: la carta (o i documenti digitali) non bastano, occorre la consapevolezza e la sostanza di applicazione di regole comportamentali, misure di sicurezza fisica e logica (sistemi informatici) ritenute adeguate (da chi?) e instaurare con fornitori e partner rapporti contrattuali che prendano in considerazione anche il trattamento dei dati personali e la loro tutela.

Recenti eventi come i ransomware del tipo Wannacry potrebbero far piangere veramente i titolari di trattamenti di dati sanitari, il cui valore per gli hacker potrebbe essere ben superiore dei 300 dollari in Bitcoin. Il ricatto potrebbe essere non del tipo “se rivuoi i tuoi dati paga”, ma “se non vuoi che divulghi su internet i tuoi dati paga il riscatto”!. Ci sono stati già casi analoghi legati a ricatti a proprietari di diritti di serie TV americane molto più innocui.

Relativamente al ruolo del DPO, l’obbligo di nomina imposto dal Regolamento ricade in modo certo solo su Enti Pubblici, mentre le Organizzazioni che controllano in modo regolare e sistematico dati personali di interessati su larga scala e quelle che trattano dati particolari (traducibili con i dati sensibili del vecchio Codice Privacy, D.Lgs 196/2003) su larga scala o trattano dati relativi a condanne penali e reati non sono facilmente determinabili. Cosa significa “su larga scala”? Le indicazioni fornite hanno permesso di stabilire che un medico di base della Sanità Italiana non tratta dati sanitari su larga scala, ma come considerare strutture superiori come Farmacie, Ambulatori medici Privati, Cliniche Private? Gli Studi Legali devono nominare un DPO?

Sicuramente le competenze del DPO dovrebbero comprendere competenze legali (conoscenza di normative e leggi applicabili alla materia ed ai dati trattati dall’organizzazione titolare del trattamento), competenze informatiche (non necessariamente particolarmente approfondite, per esse può rivolgersi a tecnici specializzati come sistemisti ed esperti di sicurezza informatica) e gestionali-organizzative.

Relativamente alle forme di certificazione sulla privacy che, beninteso, non esimono i titolari ed i responsabili del trattamento da essere passibili delle sanzioni previste dal Regolamento e dal Garante Privacy Italiano in caso di infrazioni, occorre distinguere fra diversi tipi di certificazione:

• Certificazione di prodotto o servizio, accreditata secondo ISO 17065, come ad es. lo schema ISDP 10003:2015 – Criteri e regole di controllo per la Certificazione dei processi per la tutela delle persone fisiche con riguardo al trattamento dei dati personali – Reg. EU 679/2016.
• Certificazione delle figure Professionali della Data Protection (DPO, “Auditor Privacy”, “Privacy Officer” e “Consulente Privacy”).
• Certificazione delle Aziende del Data Protection Management System in conformità al Codice di Condotta DPMS 44001:2016^© ed al Reg. (UE) 679/2016.
• Certificazione del sistema di gestione della sicurezza delle informazioni secondo la ISO 27001:2013.

Premesso che la certificazione accreditata secondo il Regolamento UE 679/2016, così come esposta dall’articolo 43 dello stesso RGPD, trova attualmente riscontri solo in standard e certificazioni afferenti allo schema di accreditamento ISO 17065 (certificazioni di prodotto o servizio), emergono le seguenti considerazioni:

• Non si è ancora affermato un sistema di gestione della privacy riconosciuto che, sulla base della struttura HLS delle norme sui sistemi di gestione (ISO 9001, ISO 27001, ecc.), consenta di gestire la protezione dei dati con un approccio sistemico, basato sui processi e concetti come il risk based thinking e l’attuazione di azioni finalizzate ad affrontare i potenziali rischi sul trattamento di dati personali.
• Il ruolo del Data Processor Officer (DPO o RPD), come è definito dal Regolamento, non corrisponde ad una figura professionale specifica avente determinati requisiti di competenza (istruzione scolastica e post scolastica, conoscenze normative e tecniche, esperienza nell’ambito privacy, partecipazione a corsi di formazione, superamento di esami o abilitazioni). Il DPO è piuttosto “un ruolo” che potrebbe richiedere competenze differenti a seconda della realtà in cui opera e della criticità della protezione dei dati personali nell’organizzazione stessa.
• Tutti gli schemi e gli standard sopra indicati permettono di ridurre il rischio che il titolare del trattamento e gli eventuali responsabili incorrano in infrazioni nel trattamento di dati personali e, quindi, rischino infrazioni anche pesanti e/o gravi danni di immagine.

Per concludere, secondo il risk based thinking, quali rischi corrono le aziende che non sono adeguate al GDPR?

La probabilità di essere sanzionati a seguito di ispezioni del Nucleo Privacy della GdF è estremamente bassa, un po’ più alta per organizzazioni che trattano dati particolarmente critici (la valutazione è fatta in base al numero delle ispezioni avvenute negli ultimi anni).

La probabilità di incorrere in sanzioni o in risarcimento danni a causa di istanze di interessati che si sentono danneggiati nella loro privacy oppure in caso di incidenti di dominio pubblico è un po’ più alta.

L’impatto delle conseguenze nel caso si verifichino suddetti eventi negativi dipende dal tipo di organizzazione e dai dati trattati, può essere significativo o devastante a seconda dei casi.

Leggi anche l’articolo Impatti del Regolamento Privacy sullo sviluppo software.

Il Nuovo Regolamento Europeo sulla Privacy, emanato lo scorso maggio ed in vigore entro fine maggio 2018, pone nuove questioni relativamente all’impiego di programmi software per l’elaborazione di dati personali, in particolare se si tratta anche di dati c.d. “sensibili” secondo la vecchia definizione del D. Lgs 196/2003.

Infatti il nuovo Regolamento Europeo sulla privacy (“Regolamento UE 2016/679 del Parlamento europeo”) impone alle organizzazioni che intendono effettuare trattamenti di dati personali di “progettare” il sistema in modo tale che sia conforme fin da subito (Privacy by design ) alle regole della privacy, spostando la responsabilità del corretto trattamento tramite strumenti informatici idonei sul titolare e sul responsabile del trattamento, quando identificato.

Nella pratica una organizzazione, prima di impiegare un applicativo software per trattare dati personali dovrà verificare che esso sia conforme ai requisiti stabiliti dal regolamento UE 679/2016, ovvero che presenti caratteristiche di sicurezza adeguate per mantenere protetti i dati personali, compresa l’eventuale pseudonomizzazione dei dati personali, quando necessaria, e la cifratura dei dati stessi.

Il Regolamento parla anche di “certificazione” della privacy, che può riferirsi ad un singolo o ad un insieme di trattamenti effettuati da un programma software, oppure da tutti i trattamenti effettuati da una organizzazione. In quest’ultimo caso siamo molto vicini alla certificazione del sistema di gestione ISO 27001. Al proposito è stato approvato da ACCREDIA lo schema proprietario ISDP©10003:2015 (conformità alle norme vigenti EU in tema di trattamenti dei dati personali).

Lo schema di certificazione ISDP 10003:2015 risponde ai requisiti di cui agli art. 42 e 43 del Regolamento 679/2016 ed è applicabile a tutte le tipologie di organizzazioni soggette alle norme vigenti in tema di tutela delle persone fisiche con riguardo al trattamento dei dati personali e la libera circolazione di tali dati. Lo schema di certificazione specifica ai “Titolari” e “Responsabili” del

trattamento, soggetti ai vincoli normativi vigenti nel territorio dell’EU, i requisiti necessari per la corretta valutazione della conformità alle norme stesse.

Ricordiamo anche che all’art 25, coma 2 il Regolamento sancisce che:

Il titolare del trattamento mette in atto misure tecniche e organizzative adeguate per garantire che siano trattati, per impostazione predefinita, solo i dati personali necessari per ogni specifica finalità del trattamento. Tale obbligo vale per la quantità dei dati personali raccolti, la portata del trattamento, il periodo di conservazione e l’accessibilità. In particolare, dette misure garantiscono che, per impostazione predefinita, non siano resi accessibili dati personali a un numero indefinito di persone fisiche senza l’intervento della persona fisica.

Rappresenta la c.d. Privacy by default: devono essere trattati “per default” solo i dati necessari a perseguire le finalità del trattamento posto in essere dal responsabile dello stesso, ovvero non devono essere trattati dati in eccesso senza che una persona fisica autorizzata lo consenta.

La certificazione introdotta all’Art. 42 può servire a dimostrare l’adozione di misure tecniche ed organizzative adeguate.

L’impatto di queste regole sugli applicativi software utilizzati per trattare anche dati personali è notevole: una organizzazione di qualsiasi dimensione che adotta un sistema informatico gestionale che tratta dati personali non in modo conforme al Regolamento UE 679/2016 di fatto rischia di essere sanzionata perché non ha adottato misure di sicurezza adeguate. Le responsabilità ricadono, in questo caso, sul titolare del trattamento e sul responsabile del trattamento, ove presente.

Dunque prima di adottare un nuovo software che gestisce archivi contenenti dati personali (a maggior ragione se vengono gestiti dati sanitari o altri dati c.d. “sensibili”) titolari e responsabili del trattamento devono valutarne la conformità alla normativa sulla privacy e questo può essere al di fuori delle competenze di chi decide l’acquisto di un applicativo software (responsabili EDP, Direttori Generali, ecc.), soprattutto nelle piccole e medie imprese o nelle strutture sanitarie di modeste dimensioni (es. Cliniche ed ambulatori privati).

La casistica di software che ricadono in questa sfera è vastissima, si va dai comuni ERP che trattano anche dati del personale, ai software per la gestione delle paghe, ai programmi per la gestione delle fidelity card, ai software impiegati in strutture sanitarie o quelli utilizzati dagli studi legali.

Oggi molti applicativi, magari obsoleti, non permettono di implementare misure di sicurezza adeguate (password di lunghezza adeguata, password di complessità minima variate periodicamente, password trasmesse via internet con connessioni crittografate, gestione utenti, raccolta di dati minimi indispensabili, gestione dei consensi, procedure di backup, ecc.) e in futuro il loro impiego diverrà non conforme alla normativa sulla privacy, ovvero non saranno più commercializzabili.

Da un lato i progettisti e gli sviluppatori di applicativi software dovranno considerare fra i requisiti di progetto anche quelli relativi alla normativa privacy, dall’altro le organizzazioni che adotteranno applicativi software (o che già li stanno utilizzando) saranno responsabili della loro eventuale non conformità al Regolamento Privacy.

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

 

Lo scorso 4 maggio è stato pubblicato sulla gazzetta ufficiale della Comunità Europea il “Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE (regolamento generale sulla protezione dei dati)” e dopo 20 giorni dalla sua pubblicazione è divenuto legge europea, pertanto a partire dal 25 maggio 2016 decorrono i due anni di transitorio per l’applicazione del nuovo Regolamento.

Nella pagina Documenti di questo sito è possibile scaricare il testo ufficiale (ora anche per gli utenti non registrati).

Il Garante per la Protezione dei dati personali ha pubblicato un’apposita guida (http://194.242.234.211/documents/10160/5184810/Guida+al+nuovo+Regolamento+europeo+in+materia+di+protezione+dati ).

Rispetto al precedente articolo pubblicato su questo sito il 27/04/2016, basato sulla traduzione della proposta di Regolamento approvata dal Parlamento Europeo a dicembre 2015, di cui il presente articolo costituisce un aggiornamento, si rilevano alcune differenze nella traduzione del testo originale inglese in lingua italiana, rispetto all’attuale Codice privacy D.Lgs 196/2003:

• Viene mantenuto il “Titolare del trattamento” (Data Controller);
• Viene mantenuto il “Responsabile del Trattamento” (Data processor);
• Viene abolito l’Incaricato del trattamento.

Il nuovo Regolamento introdurrà una legislazione in materia di protezione dati uniforme e valida in tutta Europa, affrontando temi innovativi – come il diritto all’oblio e alla portabilità dei dati – e stabilendo anche criteri che da una parte responsabilizzano maggiormente imprese ed enti rispetto alla protezione dei dati personali e, dall’altra, introducono notevoli semplificazioni e sgravi dagli adempimenti per chi rispetta le regole. Il Regolamento UE 679/2016, però, non sarà l’unica fonte legislativa per regolamentare la protezione dei dati personali, infatti le Autorità dei singoli Stati Membri – e quindi il Garante della Privacy per l’Italia – potranno integrare i contenuti del Regolamento dettagliando meglio alcuni aspetti che al momento appaiono poco chiari, introdurre linee guida generali e di settore, regolamentare aspetti particolari, ecc.

A tal proposito occorre ricordare che, con l’uscita del Regolamento 679 non vengono aboliti i provvedimenti del nostro Garante su Videosorveglianza, Amministratori di Sistema, fidelity card, biometria, tracciamento flussi bancari, ecc. Tali provvedimenti probabilmente verranno modificati e/o integrati dal Garante Privacy per aggiornarli ed eventualmente adeguarli alle prescrizioni del Regolamento Europeo 679.

Il Garante Privacy italiano potrà inoltre integrare il Regolamento UE 679 per disciplinare il trattamento di dati personali effettuato per adempiere obblighi di legge italiana e in particolari ambiti, ad esempio quello dei dati sanitari, oppure per definire in modo più dettagliato gli obblighi per le PMI (ovvero per le organizzazioni che occupano meno di 250 dipendenti, per le quali il regolamento 679 ha stabilito delle semplificazioni).

Ma quali sono le principali novità per le imprese nella gestione della privacy a fronte del Regolamento UE?

L’aspetto più significativo è sicuramente il cambio di approccio rispetto al Codice Privacy attualmente in vigore in Italia, ed in particolare all’Allegato B, ovvero al Disciplinare Tecnico delle Misure Minime di Sicurezza. Il nuovo Regolamento Europeo sulla privacy, infatti, non definisce requisiti specificati in termini precisi, come avviene per l’attuale normativa italiana sulla privacy, ma sposta la responsabilità di definire le misure di sicurezza idonee a garantire la privacy dei dati personali trattati sul titolare o responsabile del trattamento, dopo un’attenta analisi dei rischi.

Dunque non ci sono più misure minime, ma solo misure di sicurezza adeguate, progettate dal titolare o responsabile del trattamento dopo aver effettuato l’analisi dei rischi che incombono sui dati personali che si intende trattare. Sottolineiamo quest’ultimo aspetto: le misure di prevenzione vanno poste in atto prima di iniziare il trattamento.

Poiché a livello nazionale la legislazione italiana ed il Garante per la Protezione dei Dati Personali hanno seguito il percorso europeo, a partire dalla Direttiva Europea 46/95, a livello di principi sulla privacy non ci sono differenze significative tra normativa italiana e Regolamento Europeo. Infatti, alcune regole già imposte dal Codice Privacy e dalle successive disposizioni del Garante restano valide, anche se con contorni un po’ meno definiti da criteri oggettivi. In sostanza:

• Viene regolamentato solo il trattamento di dati personali di persone fisiche (non giuridiche) per scopi diversi dall’uso personale.
• Resta una distinzione fra trattamento di dati personali comuni e trattamento di dati c.d. sensibili, anche se la definizione del D.lgs 196/2003 non viene utilizzata nel Regolamento UE 679, lasciando però la possibilità agli Stati membri di stabilire una disciplina particolare in merito.
• Restano gli obblighi di informare l’interessato sull’uso che verrà fatto dei suoi dati personali.
• Restano gli obblighi di ottenere il consenso per i trattamenti non necessari o per i trattamenti di particolari tipi di dati, ad esempio quelli idonei a rivelare lo stato di salute delle persone, le origini razziali, le idee religiose, ecc.

Tra gli elementi che cambiano vi sono sicuramente:

• La denominazione ed i ruoli degli attori: il titolare del trattamento rimane tale, il responsabile del trattamento è ora responsabile in solido con il titolare per i danni derivanti da un trattamento non corretto, l’incaricato rimane il soggetto che fisicamente tratta i dati, ma tale ruolo non è delegabile, se non attraverso uno specifico accordo contrattuale. Il responsabile può individuare un proprio rappresentante.
• I dati personali trattati devono essere protetti con misure organizzative e tecniche adeguate a garantirne la riservatezza e l’integrità.
• I diritti dell’interessato sono più ampi e maggiormente tutelati.
• Il responsabile del trattamento deve mettere in atto misure tecniche ed organizzative tali da consentirgli di dimostrare che tratta i dati personali in conformità al Regolamento. Tali misure devono seguire lo stato dell’arte e devono derivare dall’analisi dei rischi che incombono sui dati, secondo relativa gravità e probabilità.
• Privacy by default: devono essere trattati “per default” solo i dati necessari a perseguire le finalità del trattamento posto in essere dal responsabile dello stesso, ovvero non devono essere trattati dati in eccesso senza che una persona fisica autorizzata lo consenta.
• Privacy by design: ogni nuovo trattamento di dati personali dovrà essere progettato in modo da garantire la sicurezza richiesta in base ai rischi a cui è sottoposto prima di essere implementato. Anche i sistemi informatici dovranno essere progettati secondo tale principio.
• Possono esserci più responsabili per un medesimo trattamento che risulteranno, pertanto, corresponsabili di eventuali trattamenti non conformi, ma dovranno stabilire congiuntamente le rispettive responsabilità.
• Le imprese con sede al di fuori dell’Unione Europea, che trattano dati personali di interessati residenti nella UE dovranno eleggere una propria organizzazione o entità all’interno della UE che sarà responsabile di tali trattamenti.
• Devono essere mantenuti registri dei trattamenti di dati effettuati con le informazioni pertinenti e le relative responsabilità. Tali registri non sono obbligatori per organizzazioni con meno di 250 dipendenti salvo che non trattino dati sensibili (secondo la definizione del Codice della Privacy attualmente in vigore) o giudiziari. Tale discriminante potrà essere meglio specificata da appositi provvedimenti del nostro Garante.
• Il responsabile del trattamento deve notificare all’autorità competente – e, in casi gravi, anche all’interessato – ogni violazione dei dati (data breach) trattati entro 72 ore dall’evento.
• Quando un trattamento presenta dei rischi elevati per i dati personali degli interessati (i casi specifici dovranno essere esplicitati dall’Autorità Garante), il responsabile del trattamento deve effettuare una valutazione di impatto preventiva, prima di iniziare il trattamento.
• Viene introdotta la certificazione del sistema di gestione della privacy (le cui modalità dovranno essere meglio definite tramite gli Organismi di Accreditamento Europei, ACCREDIA per l’Italia)..
• È richiesta la designazione di un Responsabile della Protezione dei Dati (Data Protection Officer) nelle Aziende Pubbliche e nelle organizzazioni che trattano dati sensibili o giudiziari su larga scala oppure che la tipologia di dati trattati e la loro finalità richieda il controllo degli incaricati al trattamento su larga scala.

 

Proprio quest’ultimo punto, variato rispetto alle precedenti versioni del Regolamento, farà molto discutere, poiché non stabilisce criteri precisi ed oggettivi (cosa significa “su larga scala”?) per l’adozione di tale figura professionale, di competenze adeguate a garantire una corretta applicazione della normativa sulla privacy. Il Responsabile per la Protezione dei Dati dovrà essere correttamente informato dal Responsabile del Trattamento su tutte le attività che riguardano la privacy e dovrà disporre di risorse adeguate per svolgere il proprio compito e mantenere le sue competenze adeguate al ruolo che ricopre. Egli dovrà inoltre essere indipendente dalle altre funzioni dell’organizzazione e riferire solamente all’alta direzione.

La sicurezza dei dati – in termini di riservatezza, integrità e disponibilità – deve essere garantita in funzione del rischio che corrono i dati stessi, dei costi delle misure di sicurezza e dello stato dell’arte della tecnologia. Pertanto le password di almeno 8 caratteri variate almeno trimestralmente, l’antivirus aggiornato, il firewall e l’aggiornamento del sistema operativo potrebbero essere misure adeguate per determinati trattamenti, ma non per altri, oppure in determinate organizzazioni, ma non in altre, in ogni caso lo potrebbero essere oggi, ma non domani quando il progresso tecnologico (anche degli hacker e di coloro che minacciano i nostri dati) potrebbe renderle insufficienti.

Lasciando per il momento stare gli impatti che il nuovo Regolamento UE sulla privacy potrà avere per i colossi del web, quali Facebook, Google, ecc., è opportuno osservare che per le piccole e medie imprese italiane dovrà cambiare l’approccio alla privacy, soprattutto per quelle organizzazioni che trattano dati sensibili o giudiziari. Occorrerà un cambio di mentalità: non serve più un po’ di carte (informative, consensi, lettere di incarico, …) ed alcune misure minime di sicurezza specifiche (password, antivirus,…) per garantire il rispetto della legge. Poiché molti imprenditori vedono la privacy solo come un disturbo da gestire soltanto per non incorrere in sanzioni e, quindi, come una pratica da sbrigare nel modo più indolore possibile, ecco che il passaggio al nuovo Regolamento – che dovrà avvenire nei prossimi due anni – non sarò proprio una passeggiata.

Le responsabilità in capo al responsabile del trattamento (ex titolare del trattamento) sono maggiori e comunque più impegnative da gestire, soprattutto laddove il trattamento di dati venga delegato a fornitori (es. consulenti del lavoro, consulenti fiscali e legali, strutture esterne, ecc.) che dovranno inevitabilmente essere tenuti sotto controllo.

Non è che taluni principi fossero assenti dalla normativa italiana del 2003, ma – complice la crisi e le semplificazioni adottate da precedenti governi, soprattutto l’abolizione del DPS – hanno un po’ sminuito l’importanza della privacy in azienda, anche perché – si sa come siamo fatti noi italiani – senza sanzioni esemplari non ci preoccupiamo di nulla… e sono stati molto rare le sanzioni comminate alle aziende, anche perché i controlli sono stati molto poco frequenti.

Paradossalmente ha spaventato di più la disposizione sui cookie perché la sua mancata applicazione è di fatto pubblica, mentre altre regole di fatto trascurate rimangono tra le muar delle organizzazioni di ogni dimensione.

L’indeterminatezza di alcune regole potrà essere colmata da disposizioni specifiche dei singoli Stati membri e/o da linee guida di settori specifici che potranno agevolare l’interpretazione della legge.

Ora la privacy sarà meno materia per avvocati – se non per la stesura di contratti che regolamentano i rapporti fra clienti e fornitori anche in materia di trattamento dati personali – e più materia per esperti della sicurezza delle informazioni. Infatti l’approccio del nuovo Regolamento Europeo sulla Privacy si avvicina, mutatis mutandis, a quello della norma UNI EN ISO/IEC ISO 27001 e della linea guida UNI EN ISO/IEC 27002.

L’adozione del nuovo Regolamento UE sarà, pertanto, più impegnativa per piccole organizzazioni che trattano molti dati c.d. sensibili o giudiziari, quali organizzazioni private nel campo della sanità (cliniche ed ambulatori privati, farmacie, …), studi di consulenza del lavoro, infortunistiche, studi legali, studi di consulenza fiscale, ecc., piuttosto che per aziende che trattano come unici dati sensibili i dati relativi ai propri dipendenti. Anzi saranno proprio queste ultime che dovranno pretendere da società e studi di consulenza esterna adeguate garanzie per il trattamento dei dati di cui sono responsabili.

 

In questo articolo (cfr. precedente articolo) passiamo ad esaminare la seconda parte della norma La norma UNI CEI ISO/IEC 27002:2014 – Raccolta di prassi sui controlli per la sicurezza delle informazioni (che sostituisce la ISO 27002:2005).

12 Sicurezza delle attività operative

Questa area comprende ben 7 categorie:

• Procedure operative e responsabilità (12.1): devono essere predisposte procedure per documentare lo svolgimento di una serie di attività inerenti la sicurezza, occorre gestire i cambiamenti all’organizzazione e la capacità delle risorse (di storage, di banda, infrastrutturali ed anche umane), infine è necessario mantenere separati gli ambienti di sviluppo da quelli di produzione.
• Protezione dal malware (12.2): un solo controllo in questa categoria (protezione dal malware) che prescrive tutte le misure di sicurezza da attuare contro il malware. Non solo antivirus per prevenire ed eliminare malware, ma anche azioni di prevenzione tecnica e comportamentali (consapevolezza degli utenti).
• Backup (12.3): devono essere documentate ed attuate procedure di backup adeguate a garantire il ripristino dei dati in caso di perdita dell’integrità degli stessi e la continuità operativa (vedasi anche punto 17).
• Raccolta di log e monitoraggio (12.4): devono essere registrati, conservati e protetti i log delle attività degli utenti normali e di quelli privilegiati (si ricorda che per apposita disposizione del Garante Privacy italiano i log degli accessi in qualità di Amministratore di Sistema devono essere mantenuti in modo “indelebile” per almeno 6 mesi), occorre inoltre mantenere sincronizzati gli orologi dei sistemi con una fonte attendibile.
• Controllo del software di produzione (12.5): particolari attenzioni devono essere adottate nell’installazione ed aggiornamento del software di produzione (non solo per organizzazioni del settore ICT, banche o assicurazioni, ma anche per aziende manifatturiere!).
• Gestione delle vulnerabilità tecniche (12.6): viene fornita dalla norma un’ampia guida attuativa sulla gestione delle vulnerabilità tecniche conosciute (occorre mantenere un censimento dell’hardware e del relativo software installato su ogni elaboratore, installare le patch di sicurezza in modo tempestivo, mantenersi aggiornati sulle vulnerabilità di sicurezza conosciute, ecc.), oltre alle indicazioni sulla limitazione nell’installazione dei software (è opportuno, infatti, ridurre al minimo la possibilità per gli utenti di installare applicativi software autonomamente, anche se leciti come le utility gratuite che, a volte, possono essere il veicolo di adware o altre minacce alla sicurezza).
• Considerazioni sull’audit dei sistemi informativi (12.7): gli audit sui sistemi informativi dovrebbero avere un impatto ridotto sulle attività lavorative e le evidenze raccolte dovrebbero essere raccolte senza alterare i dati dei sistemi (accessi in sola lettura) e dovrebbero essere mantenute protette.

Questi elementi nella precedente versione della norma erano in gran parte all’interno della sezione 10 “Communications and Operations Management” (ma la gestione delle vulnerabilità tecniche era, invece, al paragrafo 12.6, per puro caso lo stesso della versione attuale della norma), il quale comprendeva anche i controlli del punto 13 seguente.

13 Sicurezza delle comunicazioni

Questa sezione contiene due sole categorie:

• Gestione della sicurezza della rete (13.1): occorre adottare alcuni accorgimenti per garantire la sicurezza delle reti interne (responsabilità, autenticazioni, ecc.); viene anche citata la ISO/IEC 27033 nelle sue parti da 1 a 5 sulla sicurezza delle reti e delle comunicazioni per ulteriori informazioni. Deve, inoltre, essere gestita la sicurezza dei servizi di rete, compresi i servizi acquistati presso fornitori esterni, e la segregazione delle reti (separazione delle VLan, gestione delle connessioni Wi-Fi, …).
• Trasferimento delle informazioni (13.2): occorre stabilire ed attuare politiche e procedure per il trasferimento delle informazioni con qualsiasi mezzo (posta elettronica, fax, telefono, scaricamento da internet, ecc.), nel trasferimento di informazioni con soggetti esterni occorre stabilire accordi sulle modalità di trasmissione, le informazioni trasmesse tramite messaggistica elettronica dovrebbero essere adeguatamente controllate e protette (non solo e-mail, ma anche sistemi EDI, instant messages, social network, ecc.) e, infine, occorre stabilire e riesaminare periodicamente accordi di riservatezza e di non divulgazione con le parti interessate.

I 7 controlli di quest’area sono sicuramente molto dettagliati e migliorano, oltre ad aggiornare, la precedente versione della norma, includendo controlli (un po’ sparsi nella versione 2005 della ISO 27002) che recepiscono le nuove modalità di comunicazione, tra cui i social network, professionali e non.

14 Acquisizione, sviluppo e manutenzione dei sistemi

Quest’area tratta la sicurezza dei sistemi informativi impiegati per le attività aziendali e comprende tre categorie:

• Requisiti di sicurezza dei sistemi informativi (14.1): la sicurezza dei sistemi informativi- acquistati o sviluppati ad hoc – deve essere stabilita fin dall’analisi dei requisiti, deve essere garantita la sicurezza dei servizi applicativi che viaggiano su reti pubbliche (ad esempio attraverso trasmissioni ed autenticazioni sicure crittografate), infine occorre garantire la sicurezza delle transazioni dei servizi applicativi.
• Sicurezza nei processi di sviluppo e supporto (14.2): devono essere definite ed attuate politiche per lo sviluppo (interno o esterno all’organizzazione) sicuro dei programmi applicativi, devono essere tenuti sotto controllo tutti i cambiamenti ai sistemi (dagli aggiornamenti dei sistemi operativi alle modifiche dei sistemi gestionali), occorre effettuare un riesame tecnico sul funzionamento degli applicativi critici a fronte di cambiamenti delle piattaforme operative (sistemi di produzione, database, ecc.) e si dovrebbero limitare le modifiche (personalizzazioni) ai pacchetti software, cercando comunque di garantirne i futuri aggiornamenti. Inoltre dovrebbero essere stabiliti, documentati ed attuati principi per l’ingegnerizzazione sicura dei sistemi informatici e per l’impiego di ambienti di sviluppo sicuri. Nel caso in cui attività di sviluppo software fossero commissionate all’esterno, dovrebbero essere stabilite misure per il controllo del processo di sviluppo esternalizzato. Infine dovrebbero essere eseguiti test di sicurezza dei sistemi durante lo sviluppo e test di accettazione nell’ambiente operativo di utilizzo, prima di rilasciare il software.
• Dati di test (14.3): i dati utilizzati per il test dovrebbero essere scelti evitando di introdurre dati personali ed adottando adeguate misure di protezione, anche al fine di garantirne la riservatezza.

Nel complesso i 13 controlli di questa sezione sono molto dettagliati e comprendono una serie di misure di sicurezza informatica ormai consolidate che riguardano tutti gli aspetti del ciclo di vita del software impiegato da un’organizzazione per la propria attività. Alcuni principi vanno commisurati ad una attenta valutazione dei rischi, poiché una stessa regola di sicurezza informatica (ad es. l’aggiornamento sistematico e tempestivo del software di base) potrebbe non garantire sempre l’integrità e la disponibilità dei sistemi (ad es. errori o malfunzionamenti introdotti dagli ultimi aggiornamenti di un sistema operativo).

15 Relazioni con i fornitori

Questo punto di controllo tratta tutti gli aspetti di sicurezza delle informazioni che possono legati al comportamento dei fornitori. Sono state individuate due categorie:

• Sicurezza delle informazioni nelle relazioni con i fornitori (15.1): è necessario stabilire una politica ed accordi su tematiche inerenti la sicurezza delle informazioni con i fornitori che accedono agli asset dell’organizzazione; tali accordi devono comprendere requisiti per affrontare i rischi relativi alla sicurezza associati a prodotti e servizi nella filiera di fornitura dell’ICT (cloud computing compreso).
• Gestione dell’erogazione dei servizi dei fornitori (15.2): occorre monitorare – anche attraverso audit se necessario – e riesaminare periodicamente le attività dei fornitori che influenzano la sicurezza delle informazioni, nonché tenere sotto controllo tutti i cambiamenti legati alle forniture di servizi.

16 Gestione degli incidenti relativi alla sicurezza delle informazioni

L’area relativa agli incidenti sulla sicurezza delle informazioni (sezione 13 della precedente versione della norma) comprende una sola categoria (erano 2 nella precedente edizione):

• Gestione degli incidenti relativi alla sicurezza delle informazioni e dei miglioramenti (16.1): devono essere rilevati e gestiti tutti gli incidenti relativi alla sicurezza delle informazioni (viene qui richiamata la ISO/IEC 27035 – Information security incident management), ma anche rilevate ed esaminate tutte le segnalazioni di eventi relativi alla sicurezza che potrebbero indurre a pensare che qualche controllo è risultato inefficace senza provocare un vero e proprio incidente e pure tutte le possibili debolezze dei controlli messi in atto. In ogni caso ogni evento relativo alla sicurezza delle informazioni va attentamente valutato per eventualmente classificarlo come incidente vero e proprio o meno. Occorre poi rispondere ad ogni incidente relativo alla sicurezza delle informazioni in modo adeguato ed apprendere da quanto accaduto per evitare che l’incidente si ripeta. Infine dovrebbero essere stabilite procedure per la raccolta di evidenze relative agli incidenti e la successiva gestione (considerando anche eventuali azioni di analisi forense).

17 Aspetti relativi alla sicurezza delle informazioni nella gestione della continuità operativa

In quest’area (corrispondente al punto 14 sella precedente versione della norma) viene trattata la business continuity in 5 controlli suddivisi in due categorie:

• Continuità della sicurezza delle informazioni (17.1): la continuità operativa per la sicurezza delle informazioni dovrebbe essere pianificata a partire dai requisiti per la business continuity, piani di continuità operativa (business continuity plan) dovrebbero essere attuati, verificati e riesaminati periodicamente.
• Ridondanze (17.2): per garantire la disponibilità (e la continuità operativa) occorre prevedere architetture e infrastrutture con adeguata ridondanza.

Naturalmente sull’argomento esiste la norma specifica UNI EN ISO 22301:2014 – Sicurezza della società – Sistemi di gestione della continuità operativa – Requisiti.

18 Conformità

Questo ultimo punto di controllo (era il punto 15 nella ISO 27002:2005) tratta la gestione della cosiddetta “compliance”, ovvero la conformità a leggi, regolamenti ed accordi contrattuali con i clienti. Sono identificate due categorie:

• Conformità ai requisiti cogenti e contrattuali (18.1): occorre innanzitutto identificare i requisiti cogenti, quindi attuare controlli per evitare di ledere i diritti di proprietà intellettuale, proteggere adeguatamente le registrazioni che permettono di dimostrare la conformità a tutti i requisiti cogenti, in particolare devono essere rispettati leggi e regolamenti sulla privacy (in Italia il D.Lgs 196/2003 in attesa del nuovo Regolamento Europeo, ma nella norma viene citata come riferimento la ISO/IEC 29100:2011 “Information technology – Security techniques — Privacy framework”). Infine occorre considerare eventuali limitazioni all’uso dei controlli crittografici vigenti in alcune nazioni.
• Riesami della sicurezza delle informazioni (18.2): dovrebbe essere svolto periodicamente un riesame indipendente sulla sicurezza delle informazioni dell’organizzazione, i processi di elaborazione delle informazioni e le procedure dovrebbero essere riesaminate periodicamente per valutarne la continua conformità ed adeguatezza alla politica ed alle norme ed infine dovrebbero essere eseguite delle verifiche tecniche della conformità dei sistemi informativi a politiche e standard di sicurezza (ad esempio penetration test e vulnerability assessment). Su quest’ultimo controllo si fa riferimento alla ISO/IEC TR 27008 – Guidelines for auditors on information security management systems controls.

Il BCP (Business Continuity Plan) o Piano di Continuità Operativa è un documento richiesto alle organizzazioni certificate ISO 27001 (Sistema di gestione per la sicurezza delle informazioni – Requisiti) al controllo A.17.1 “Continuità della sicurezza delle informazioni”, ma anche – e soprattutto – dalla norma specifica UNI EN ISO 22301:2014 – Sicurezza della società – Sistemi di gestione della continuità operativa – Requisiti, che abbiamo trattato in un precedente articolo.

Gli eventi delle ultime settimane, ma anche degli ultimi anni, hanno mostrato quanto scarsa sia l’adozione di questo strumento nel nostro Paese. Molti sono, infatti, gli esempi di situazioni critiche – essenzialmente causate da disastri naturali – che non sono state fronteggiate nel modo corretto e che hanno portato a costi sociali elevatissimi che si sono scaricati inevitabilmente sulla collettività:

• Il terremoto dell’Aquila e dell’Emilia;
• Le alluvioni in Liguria ed in Toscana;
• Le interruzioni di energia elettrica protrattesi nel tempo a Cortina qualche Natale fa e, più recentemente, in Emilia dopo una forte nevicata;
• Le forti nevicate verificatesi in Emilia-Romagna nel 2012.

In tutte queste situazioni di emergenza, oltre ai danni materiali ed alle perdite di vite umane, si sono verificate disfunzioni e ritardi nella ripresa dell’operatività ordinaria. Il vantaggio di avere predisposto un buon piano di continuità operativo è proprio questo: ipotizzando una situazione di crisi si cerca di limitare i danni e di tornare all’operatività normale nel più breve tempo possibile.

Tornando ad aspetti più tecnici, mentre la ISO 27001 tratta la continuità operativa in termini di sicurezza delle informazioni, ovvero di garantire il ritorno alla piena disponibilità delle informazioni senza perdite significative delle stesse, la ISO 22301 amplia il raggio di azione del business continuity plan, comprendendo la gestione delle discontinuità di un servizio, non necessariamente legato alla disponibilità di informazioni su supporto cartaceo o elettronico (anche se oggi ben poche attività possono farne a meno). Alcuni esempi possono chiarire meglio il concetto:

• La gestione di un ospedale a fronte di grandi epidemie che riducono anche la disponibilità di risorse umane sufficienti ad affrontare l’emergenza;
• Un servizio di trasporto di persone o beni in caso di calamità naturali;
• Un servizio di pronto intervento di manutenzione in caso di calamità naturali che impediscono al personale di recarsi al lavoro;
• Un servizio di ristorazione collettiva in caso di calamità naturali o epidemie influenzali che impediscono al personale di recarsi al lavoro;
• E così via.

Si ricorda che la continuità operativa è l’insieme di attività volte a minimizzare gli effetti distruttivi, o comunque dannosi, di un evento che ha colpito un’organizzazione o parte di essa, garantendo la continuità delle attività in generale.

La sfera di interesse della continuità operativa va oltre il solo ambito informatico, interessando l’intera funzionalità di un’organizzazione (Azienda, Ente Pubblico, ecc.) ed è, pertanto, assimilabile all’espressione “business continuity”.

La continuità operativa comprende sia gli aspetti strettamente organizzativi, logistici e comunicativi che permettono la prosecuzione delle funzionalità di un’organizzazione, sia la continuità tecnologica, che riguarda l’infrastruttura informatica e telecomunicativa (ICT) ed è nota come “disaster recovery” (DR). Pertanto, le soluzioni per garantire la continuità dei servizi non considerano soltanto le componenti tecnologiche utilizzate, ma anche tutte le altre risorse (personale, impianti, infrastrutture, ecc.).

Le analisi, valutazioni e scelte di trattamento del rischio richieste dalla gestione della continuità operativa sono le seguenti:

• Identificazione dei rischi;
• Analisi e valutazione dei rischi;
• Analisi delle conseguenze di disastri, malfunzionamenti, interruzioni di servizi (Business Impact Analysis);
• Realizzazione di piani (controlli) affinché i processi di business siano riattivati entro il tempo richiesto.

Le analisi valutano per ogni asset (o gruppo di asset) critico il tempo che tale asset può rimanere indisponibile con danno basso o nullo. I piani (Business Continuity Plan) devono essere mantenuti costantemente aggiornati per essere efficaci al momento del bisogno.

Per meglio comprendere la predisposizione di un BCP occorre introdurre alcune definizioni basilari:

• Mission Critical Activity (MCA): attività critica o di supporto al business relativamente ai servizi o prodotti offerti dall’organizzazione (internamente o esternamente), incluse le sue correlazioni con altri processi e single points of failure, che permettono all’organizzazione di raggiungere i suoi obiettivi di business considerando le stagionalità e/o tempi di rilascio critici
• Business Impact Analysis (BIA): analisi gestionale attraverso la quale un’organizzazione valuta quantitativamente (per esempio finanziariamente, Service Level Agreement, SLA) e qualitativamente (per esempio reputazione, leggi, regolamenti) gli impatti e le perdite che possono risultare se l’organizzazione subisce un grave incidente, e il minimo livello di risorse necessarie per il ripristino.
• Maximum Tollerance DownTime (MTDT): massimo intervallo di tempo ammissibile di interruzione del servizio (quante ore posso permettermi di non erogare il servizio ai clienti?).
• Maximum Tollerance Data Loss (MTDL): massima perdita di dati tollerata (quanti dati posso permettermi di perdere?).
• RTO (Recovery Time Objective): periodo di tempo entro il quale devono essere ripristinati un minimo livello di servizio, i sistemi di supporto e le funzionalità principali dopo un’interruzione dei servizi. Normalmente è il lasso di tempo entro il quale cui le MCA devono essere ripristinate.
• RPO (Recovery Point Objective): istante (punto) nel tempo al quale i dati sono coerenti e possono essere ripristinati.
• MBCO (Minimum Business Continuity Objective): livello di servizio minimo accettabile dall’organizzazione per raggiungere i propri obiettivi di business durante una rottura.

Il processo di gestione della continuità operativa deve prendere in esame tutti i processi e le attività aziendali e classificarli in funzione della loro criticità nel modo seguente:

1. Attività critiche per il business (MCA’s);
2. Attività importanti;
3. Attività secondarie.

Per le attività critiche vengono stabiliti degli obiettivi di continuità operativa in termini di MTDT, MTDL, RTO, RPO, MBCO e stabiliti dei piani di continuità operativa, che comprendono le contromisure messe in campo per garantire gli obiettivi.

Per la pianificazione delle attività di continuità operativa è necessario valutare preliminarmente gli impatti degli eventi che possono causare interruzioni dei processi di business, predisponendo una BIA.

A seguito della valutazione dei rischi di interruzione del servizio erogato ai clienti devono essere predisposti, attuati e periodicamente verificati uno o più Piani di Continuità Operativa (Business Continuity Plan) aventi lo scopo di mantenere o ripristinare il funzionamento dei processi critici ed assicurare la disponibilità delle informazioni necessarie a garantire un livello di servizio accettabile, a fronte del verificarsi dei rischi di interruzioni o malfunzionamenti precedentemente identificati e valutati.

Dunque se pensiamo ad un servizio di pubblica utilità (servizi ospedalieri, trasporto pubblico, mense scolastiche, servizi di pulizia e raccolta rifiuti, ecc.) occorre definire due livelli:

• Un primo livello che identifica il ripristino di un servizio minimo dopo l’interruzione;
• Un secondo livello che sancisce la ripresa dell’attività ordinaria.

Per ogni livello devono essere stabiliti i tempi entro i quali vengono raggiunti e che possono costituire SLA contrattuali.

È bene comprendere che i BCP devono prefigurare uno scenario di crisi ben definito, al verificarsi del quale si vuole reagire in modo adeguato. Chiaramente non tutti gli scenari possibili possono essere gestiti nei BCP, ma solo quelli più probabili e di impatto più grave, sulla base della valutazione dei rischi preliminarmente svolta.

I contenuti dei BCP potrebbero essere i seguenti:

1. Scopo e campo di applicazione
2. Obiettivi
3. Requisiti di business continuity (RPO, RTO,…)
4. Identificazione dei processi critici (MCA’s)
5. Business Impact Analysis
6. Piano di Disaster Recovery
7. Piano di Continuità Operativa, contenente:

• Rilevazione dell’incidente (metodi e procedure): dichiarazione del disastro o incidente, valutazione del danno, attivazione del piano):
• Risposta all’incidente (attività, tempi, responsabilità, procedure);
• Ripristino dell’operatività (attività, tempi, responsabilità, procedure di azione e continuità);
• Risorse (personale e competenze, tecnologie, infrastruttura, software, dati, siti alternativi, centri di emergenza o crisi);
• Fornitori (Lista dei fornitori di recovery, dettagli dei contratti, procedure di attivazione);
• Organizzazione e Responsabilità;
• Documentazione;
• Comunicazioni (contatti, soggetti da informare, messaggi);

1. Test del BCP (prove, tempi, responsabilità)
2. Manutenzione del BCP

Si precisa che i BCP possono far riferimento ad altri documenti (ad es. Piani di Disaster Recovery), aggiornati autonomamente. In ogni caso deve essere sempre possibile risalire alla configurazione attuale del BCP, ovvero alle revisioni vigenti dei documenti esterni richiamati nel Piano di Continuità Operativa. Tale configurazione e la relativa rintracciabilità dei documenti relativi al BCP deve essere disponibile sia in formato elettronico, sia su supporto cartaceo, con gestione di copie di riserva del BCP disponibili in locali/siti/ubicazioni alternative, al fine di essere sempre disponibili in caso di verificarsi dell’evento che ha generato l’interruzione dei processi critici.

Si rammenta che per la Pubblica Amministrazione la continuità operativa ed i relativi Piani di Business Continuity sono previsti dall’Art. 50 bis del Codice per l’Amministrazione Digitale; essa, pertanto, deve essere gestita dagli responsabili degli Enti Pubblici in modo adeguato, con riferimento agli standard internazionali sulla materia.

[Download non trovato]

Oggi le imprese tendono ad esternalizzare molti processi ed attività secondarie al fine di ottimizzarne i costi e la qualità del servizio risultante che, se svolto da personale specializzato, è spesso superiore a quella ottenibile con personale interno.

Alcune di queste attività – ad esempio la gestione delle paghe e del personale, l’acquisizione di documenti e dati in formato digitale e la relativa archiviazione sostitutiva, la gestione contabile e fiscale, i servizi informatici, ecc. – prevedono la gestione di informazioni critiche dal punto di vista della riservatezza e degli aspetti legali e di compliance ad essi correlati.

Per questo motivo alcune aziende internazionali – multinazionali o grandi gruppi con sedi all’estero, in particolare negli Stati Uniti – richiedono, alle loro filiali o consociate italiane, evidenza della buona gestione dei servizi affidati in outsourcing.

Per le aziende soggette a tale standard la Sezione 404 del Sarbanes-Oxley Act (SOX) richiede che i fornitori di servizi in outsourcing siano provvisti di una particolare certificazione, il Report SSAE 16, per garantire che controlli e processi interni siano appropriati alla gestione delle informazioni dei propri clienti.

La crescente richiesta di servizi in outsourcing pone, quindi, l’esigenza da parte delle organizzazioni che forniscono servizi in outsourcing delle tipologie sopra elencate (payroll, contabilità, gestione documentale, …) di fornire ai propri clienti e ad altri soggetti un rapporto di revisione completo sui sistemi di controllo e sui processi, al fine di assicurare che i servizi erogati alla clientela siano sicuri e conformi a uno standard riconosciuto.

La certificazione SSAE no. 16 è il nuovo standard per effettuare la reportistica sui controlli nelle aziende di servizi – sostituendo la precedente SAS no. 70 – e risponde alla domanda crescente di disporre di regole conformi a standard internazionali riconosciuti in tutto il mondo, migliorativi rispetto ad una semplice certificazione ISO 9001.

Il report SSAE 16 (Statement on Standards for Attestation Engagements no. 16) viene rilasciato da auditor indipendenti qualificati dall’AICPA (dall’American Institute of Certified Public Accountants) dopo un articolato processo di analisi dei processi interni, confronto degli stessi con un’apposita matrice di controlli che produrrà una gap analysis la quale costituirà il punto di partenza per portare, attraverso l’introduzione di idonei controlli ed apposita documentazione procedurale, alle verifiche di efficacia dei controlli implementati atti  a garantire l’adeguatezza degli stessi e delle informazioni processate.

Il report SSAE 16 costituisce un’esaustiva fotografia del funzionamento dell’organizzazione di servizi e dei controlli implementati per garantire non solo la conformità del servizio, ma anche la sicurezza nella gestione dei dati elaborati.

Il processo che porta alla certificazione SSAE 16 comprende una dettagliata mappatura dei processi organizzativi e dei flussi informativi che permette di effettuare la mappatura degli obiettivi di controllo, delle criticità e dei rischi, finalizzata alla valutazione dei rischi (risk assessment), imprescindibile punto di partenza per qualsiasi sistema di controllo interno.

Sebbene questo schema SSAE 16 ricalchi per alcuni elementi la certificazione ISO 9001 e la certificazione ISO 27001, esso presenta una valenza particolare in determinati settori e costituisce il logico completamente in un percorso di miglioramento e di qualificazione dell’organizzazione di servizi nei confronti del cliente.

Tale certificazione, si ribadisce, è rivolta in particolare alle seguenti organizzazioni di servizi:

• Servizi di gestione paghe del personale
• Acquisizione dati e documenti in formato digitale
• Conservazione sostitutiva
• Servizi contabili e fiscali
• Servizi di assistenza e sviluppo software.