La norma ISO 90003 (UNI CEI ISO/IEC/IEEE 90003:2020 – Linee guida per l’applicazione della norma ISO 9001 nel settore del software) è una guida preziosa per le organizzazioni che desiderano applicare la ISO 9001:2015 nel campo dello sviluppo e della gestione del software. Questa norma offre indicazioni chiare per l’acquisizione, la fornitura, lo sviluppo, il funzionamento e la manutenzione del software, senza modificare i requisiti esistenti della ISO 9001:2015. L’applicazione di questa linea guida costituisce un passo importante per garantire la qualità e l’affidabilità dei servizi legati alle applicazioni software di qualsiasi tipo.

Oggi, purtroppo, si denota un forte decadimento della qualità del software sviluppato per le diverse applicazioni (programmi desktop, programmi client-server, applicazioni web, app per dispositivi mobili, ecc.). Il continuo aggiornamento dei software, causato apparentemente per motivi di sicurezza, ovvero per “patchare” le vulnerabilità emerse, in realtà maschera una qualità del software non adeguata al momento del rilascio. La fretta nel rilasciare nuove versioni spesso porta a trascurare test adeguati allo scopo e l’evento che ha messo in crisi a livello mondiali moltissimi sistemi Microsoft lo scorso luglio ne è solo un esempio.

Obiettivi della norma

I principali obiettivi della norma UNI CEI ISO/IEC/IEEE 90003:2020 sono:

1. Guida all’applicazione della ISO 9001:2015: Fornire indicazioni specifiche per le organizzazioni su come applicare i principi e i requisiti della ISO 9001:2015 nel contesto dello sviluppo e della gestione del software.
2. Supporto per l’acquisizione e la fornitura di software: Offrire linee guida per l’acquisizione, la fornitura, lo sviluppo, il funzionamento e la manutenzione del software e dei relativi servizi di supporto.
3. Mantenimento della qualità: Assicurare che le pratiche di gestione del software siano allineate con gli standard di qualità internazionali, contribuendo così a migliorare la qualità e l’affidabilità dei prodotti software.
4. Non modificare i requisiti ISO 9001:2015: La norma non aggiunge né modifica i requisiti della ISO 9001:2015, ma si concentra sull’applicazione di questi requisiti nel settore del software.

I benefici nell’applicazione delle linee guida

I benefici per un’organizzazione nell’applicare le linee guida della norma UNI CEI ISO/IEC/IEEE 90003:2020 alla gestione del software includono:

1. Miglioramento della qualità del software: L’applicazione della norma aiuta a stabilire processi e pratiche che migliorano la qualità del software sviluppato, riducendo difetti e aumentando la soddisfazione del cliente.
2. Allineamento con standard internazionali: Seguendo le linee guida della norma, le organizzazioni possono garantire che i loro processi di gestione del software siano conformi agli standard internazionali, facilitando l’integrazione e la cooperazione con partner e clienti globali.
3. Ottimizzazione dei processi: La norma fornisce indicazioni su come implementare un sistema di gestione della qualità (SGQ) efficace, che può portare a una maggiore efficienza operativa e a una riduzione dei costi attraverso processi più snelli e ben definiti.
4. Flessibilità e adattabilità: La norma è progettata per essere indipendente dalla tecnologia e dai modelli di ciclo di vita, permettendo alle organizzazioni di adattare le linee guida alle loro specifiche esigenze e contesti operativi.
5. Supporto alla gestione del rischio: Implementando un sistema di gestione per la qualità basato su questa norma, le organizzazioni possono identificare e gestire meglio i rischi associati allo sviluppo e alla manutenzione del software, contribuendo a una maggiore stabilità e affidabilità dei prodotti.
6. Soddisfazione del cliente: Un focus sulla qualità e sull’affidabilità del software porta a una maggiore soddisfazione del cliente, poiché i prodotti e i servizi forniti rispondono meglio alle loro esigenze e aspettative.

I requisiti principali della norma

I requisiti principali che caratterizzano la norma UNI CEI ISO/IEC/IEEE 90003:2020, in relazione all’applicazione della ISO 9001:2015 nel contesto del software, includono:

1. Sistema di gestione della qualità (SGQ, QMS nella dizione inglese): Le organizzazioni devono stabilire, implementare, mantenere e migliorare un sistema di gestione della qualità che soddisfi i requisiti della ISO 9001:2015, adattandolo alle specificità del settore software.
2. Focus sul cliente: È fondamentale garantire che i requisiti dei clienti siano compresi e soddisfatti, contribuendo così a migliorare la soddisfazione del cliente stesso.
3. Processo di sviluppo del software: La norma incoraggia l’adozione di processi ben definiti per lo sviluppo, la gestione e la manutenzione del software, che possono includere pratiche di ingegneria del software come quelle descritte in ISO/IEC/IEEE 12207:2017.
4. Documentazione e registrazioni: Le organizzazioni devono mantenere documentazione adeguata e registrazioni (informazioni documentate da conservare secondo la definizione ISO 9001:2015) per dimostrare la conformità ai requisiti del SGQ e per facilitare il monitoraggio e la revisione dei processi.
5. Gestione dei rischi: È richiesto un approccio basato sul rischio per identificare, valutare e gestire i rischi associati ai processi di sviluppo del software, al fine di prevenire effetti negativi sulla qualità.
6. Miglioramento continuo: Le organizzazioni devono impegnarsi in un processo di miglioramento continuo, utilizzando feedback, audit e analisi delle prestazioni per identificare opportunità di miglioramento.
7. Formazione e competenza: È essenziale garantire che il personale coinvolto nei processi di sviluppo del software sia adeguatamente formato e competente, per garantire la qualità del lavoro svolto.

Questi requisiti mirano a garantire che le organizzazioni possano fornire software di alta qualità, soddisfacendo le aspettative dei clienti e conformandosi agli standard internazionali. Purtroppo spesso gli auditor ISO 9001 degli organismi di certificazione non entrano nel dettaglio di questi aspetti secondo quello che è indicato in questa normativa che, seppur linea guida, costituiscxe un valido strumento per comprendere se i requisiti ISO 9001 sono stati declinati correttamente nelle attività legate al settore informatico dello sviluppo software.

I test

Secondo la norma UNI CEI ISO/IEC/IEEE 90003:2020, la gestione del test del software deve seguire alcuni principi e pratiche chiave per garantire la qualità e l’affidabilità del prodotto finale. Ecco come deve essere gestito il test del software:

1. Pianificazione dei test: È fondamentale sviluppare un piano di test che definisca gli obiettivi, le strategie, le risorse necessarie e i criteri di accettazione. Questo piano deve essere allineato con i requisiti del software e le aspettative del cliente.
2. Definizione dei requisiti di test: I requisiti di test devono essere chiaramente definiti e documentati, in modo da garantire che tutti gli aspetti del software siano testati in modo adeguato. Ciò include la definizione di casi di test basati sui requisiti funzionali e non funzionali.
3. Esecuzione dei test: I test devono essere eseguiti in modo sistematico e documentato. È importante registrare i risultati dei test, compresi eventuali difetti riscontrati, per facilitare la tracciabilità e la gestione delle problematiche.
4. Verifica e validazione: I test devono essere utilizzati per verificare che il software soddisfi i requisiti specificati (verifica) e per convalidare che il software soddisfi le esigenze e le aspettative del cliente provandolo nell’ambiente operativo finale (validazione).
5. Gestione dei difetti/anomalie: Deve essere implementato un processo per la gestione dei difetti, anomalie o malfunzionamenti identificati durante i test. Questo include la registrazione, la classificazione, la risoluzione e la verifica delle correzioni apportate.
6. Riesame dei risultati dei test: I risultati dei test devono essere analizzati e riesaminati per identificare aree di miglioramento e per garantire che le problematiche siano state risolte in modo efficace. Questo processo contribuisce al miglioramento continuo del sistema di gestione della qualità.
7. Documentazione dei test: È essenziale mantenere una documentazione dettagliata dei test, compresi i piani di test, i casi di test, i risultati e le azioni correttive intraprese. Questa documentazione serve come riferimento per audit e revisioni future.

Implementando queste pratiche, le organizzazioni possono garantire che il processo di test del software sia efficace e contribuisca a fornire prodotti di alta qualità che soddisfano le aspettative dei clienti. Troppo spesso i test vengono demandati allo sviluppatore stesso senza fornirgli indicazioni precisi di cosa e come deve essere testato l’applicativo. Spesso non vengono redatte delle vere e proprie Specifiche di Test che normalmente possono essere differenti dalle Specifiche dei Requisiti dell’applicativo: come testare un software è cosa diversa da come lo si deve realizzare.

La manutenzione del software

Ma dopo il collaudo di accettazione ed il rilascio come deve essere gestita la manutenzione del software e l’assistenza tecnica ai clienti secondo questa norma?

Secondo la norma UNI CEI ISO/IEC/IEEE 90003:2020, la gestione della manutenzione del software e dell’assistenza tecnica ai clienti deve seguire alcune linee guida fondamentali per garantire la qualità e l’affidabilità del servizio. Ecco come deve essere gestita:

1. Pianificazione della manutenzione: È importante sviluppare un piano di manutenzione che definisca le attività necessarie per mantenere il software in buone condizioni operative. Questo piano dovrebbe includere la gestione delle modifiche, la risoluzione dei problemi e le attività di supporto.
2. Attività di manutenzione: Le attività di manutenzione devono comprendere:
3. Risoluzione dei problemi e supporto tecnico, inclusa l’assistenza help desk.
4. Monitoraggio del sistema per rilevare eventuali guasti o malfunzionamenti.
5. Modifiche all’interfaccia quando si apportano aggiunte o cambiamenti ai componenti hardware controllati dal software.
6. Gestione della configurazione, test e attività di assicurazione della qualità.

3. Documentazione delle attività di manutenzione: È essenziale mantenere registrazioni dettagliate delle attività di manutenzione, comprese le modifiche apportate, i problemi risolti e le interazioni con i clienti. Queste registrazioni possono essere utilizzate per valutare e migliorare il prodotto software e il sistema di gestione della qualità.
4. Assistenza tecnica ai clienti: L’assistenza ai clienti deve essere ben strutturata e deve includere:
5. Un sistema di supporto per rispondere alle richieste e ai problemi dei clienti. Un buon sistema di ticketing costituisce un valido supporto per svolgere l’assistenza tecnica al cliente.
6. Formazione e documentazione per i clienti, per aiutarli a utilizzare il software in modo efficace.
7. Un processo per raccogliere feedback dai clienti, che può essere utilizzato per migliorare il software e i servizi di supporto.

5. Gestione dei rischi: Le organizzazioni devono gestire i rischi associati alla manutenzione del software, inclusi quelli legati alla disponibilità del supporto per i prodotti acquistati e alla continuità del servizio.
6. Miglioramento continuo: Le informazioni raccolte durante le attività di manutenzione e assistenza devono essere utilizzate per identificare opportunità di miglioramento, sia per il software che per i processi di supporto. Questo approccio contribuisce a garantire che il software rimanga rilevante e soddisfi le esigenze dei clienti nel tempo.

Implementando queste pratiche, le organizzazioni possono garantire che la manutenzione del software e l’assistenza tecnica siano gestite in modo efficace, contribuendo così alla soddisfazione del cliente e alla qualità complessiva del prodotto.

Naturalmente non vanno dimenticati i requisiti contrattuali con i clienti. Spesso le attività di manutenzione orinaria sono comprese nel canone di licenza d’uso (o canone di abbonamento per software SaaS). Esse comprendono la risoluzione dei bug o malfunzionamenti software, il supporto operativo nell’utilizzo dell’applicativo (talvolta compreso un “monte ore” di assistenza), interventi eseguiti entro determinati SLA e così via.

Las manutenzione comprende non solo attività correttive, ma anche attività evolutive, ovvero modifiche che migliorano le funzionalità e la sicurezza del software. La loro gestione deve essere mantenuta sotto controllo attraverso procedure di change management che definiscano un ciclo di approvazione delle modifiche comprendente anche la valutazione dei possibili effetti negativi dell’implementazione delle modifiche sulle funzionalità preesistenti, prevedendo appositi test di regressione (regression test).

È opportuno che il fornitore del servizio di assistenza software stabilisca con il cliente una classificazione delle anomalie segnalate per livello di gravità (es. Bloccante, Critica, Secondaria…) e per priorità dell’intervento (es. priorità alta richiede un intervento entro 4 ore, ecc.).

In base ai requisiti contrattuali il fornitore del servizio di assistenza dovrà dimensionare adeguatamente le proprie risorse dedicate.

Documenti e registrazioni

Ma quali sono le principali registrazioni da conservare e documenti da mantenere nel ciclo di progettazione e sviluppo software?

Secondo la norma UNI CEI ISO/IEC/IEEE 90003:2020, è fondamentale mantenere una serie di registrazioni e documenti durante il ciclo di progettazione e sviluppo del software per garantire la qualità e la tracciabilità del processo. Le principali registrazioni e documenti da conservare includono:

1. Piani di progetto: Documenti che definiscono gli obiettivi, le risorse, le tempistiche e le strategie per il progetto di sviluppo software.
2. Requisiti del software: Documentazione che specifica i requisiti funzionali e non funzionali del software, inclusi i criteri di accettazione.
3. Specifiche di progettazione e sviluppo: Documenti che descrivono l’architettura, il design e le specifiche tecniche del software, inclusi diagrammi di flusso e modelli E-R.
4. Casi di test e risultati: Documentazione relativa ai casi di test sviluppati per verificare e validare il software, insieme ai risultati ottenuti durante le attività di test.
5. Documentazione di sviluppo: Include codice sorgente, pseudo codice, modelli di dati e qualsiasi altro output generato durante il processo di sviluppo.
6. Documentazione di supporto: Manuali utente, documentazione operativa, materiale di formazione e documentazione di manutenzione.
7. Registrazioni dei riesami, verifiche e validazioni: Verbali delle riunioni e delle review del progetto, che documentano le decisioni prese e le modifiche apportate durante il ciclo di vita del progetto.
8. Registrazioni delle modifiche: Documentazione delle modifiche apportate al software, inclusi i motivi delle modifiche e l’impatto previsto (processo di change management).
9. Documentazione di gestione della configurazione: Registrazioni relative alla gestione della configurazione del software, che includono lo stato delle versioni, le modifiche e le approvazioni. Il processo di configuration management oggi non può più essere gestito senza tool appositi (es. SVN, GitHub, Microsoft Source Safe, ecc.).
10. Feedback e valutazioni*: Documentazione relativa al feedback ricevuto dagli utenti e alle valutazioni delle prestazioni del software, che possono essere utilizzate per miglioramenti futuri.

Mantenere questi documenti e registrazioni non solo aiuta a garantire la qualità del software, ma fornisce anche una base per audit, revisioni e miglioramento continuo del processo di sviluppo.

Il processo di progettazione e sviluppo software

Vediamo ora una breve sintesi del capitolo più importante di questa norma, ovvero quello dedicato al processo di Progettazione e sviluppo software.

8.3 PROGETTAZIONE E SVILUPPO DI PRODOTTI E SERVIZI

8.3.1 Generalità

• La progettazione e lo sviluppo devono essere disciplinati per prevenire problemi.
• Riduzione della dipendenza dalla verifica e validazione per l’identificazione dei problemi.

8.3.2 Pianificazione della progettazione e dello sviluppo

• La pianificazione deve coprire attività come analisi, progettazione, sviluppo, testing, installazione e supporto.
• Include anche gestione delle risorse, interfacce, analisi dei rischi e altro.

8.3.2.2 Ciclo di vita del software

• L’uso di modelli di ciclo di vita  (es. Waterfall, Agile) appropriati è essenziale.
• Adattamento delle procedure con il progredire del progetto.

8.3.2.3 Riesame, verifica e validazione

• Riesame, verifica e validazione per la progettazione e lo sviluppo del software.
• Operazioni e manutenzione del software trattate negli accordi sul livello di servizio o nelle procedure di manutenzione.

8.3.2.4 Responsabilità e autorità

• Applicabile al software, ma senza una guida specifica per il software.

8.3.2.5 Interfacce

• Definizione chiara delle responsabilità e delle informazioni tra le parti coinvolte nel prodotto software.
• Coinvolgimento degli utenti finali e funzioni operative intermedie nelle interfacce.

8.3.3 Input di progettazione e sviluppo

• Necessità di input chiari e precisi per garantire un progetto e sviluppo efficace.
• Revisione accurata per eliminare ambiguità e assicurare coerenza.

8.3.4 Riesame, verifica e validazione dei risultati

• Attività formali per assicurare che i risultati siano conformi ai requisiti.
• Procedure di gestione delle carenze identificate durante le attività di revisione.

8.3.5 Risultati della progettazione e dello sviluppo

• Definizione e documentazione completa degli output del processo di progettazione e sviluppo.
• Conservazione dei risultati specificati per un periodo coerente con la politica di gestione documenti.

Per la gestione della configurazione viene fatto riferimento alla norma ISO/IEC/IEEE 12207:2017.

Conclusioni

Oggi il software impatta in modo significativo non solo sulle attività produttive, ma anche sulle attività umane ordinarie (rapporti con la P.A. per richiedere informazioni e fornire dichiarazioni e pagamenti, sistemi di pagamento,  sistemi IOT presenti in aziende ed anche in ambienti domestici, app per lo svago e l’intrattenimento,…), pertanto è necessario che chi progetta, sviluppa e manutiene il software applichi regole consolidate per garantire un livello di qualità e sicurezza delle applicazioni adeguato all’utilizzo che ne viene fatto.

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 questo periodo molte organizzazioni, sia pubbliche che private, hanno scoperto – per necessità – il lavoro a distanza, formalmente definito “lavoro flessibile”, telelavoro o smartworking.

Fermo restando che il vero smartworking non consiste
nel farsi mandare un documento a casa via e-mail da un collega (o da sé stesso),
lavorarci su fra le mura domestiche e poi rimandarselo in ufficio, cerchiamo di
capire quali sono le modalità efficaci, efficienti e “sicure” per lavorare con
continuità da casa o comunque da un sito che non è l’ufficio o la sede
aziendale in genere.

In questo periodo molte organizzazioni ed i loro dipendenti,
collaboratori e consulenti stanno sperimentando tecnologie che sono disponibili
già da alcuni anni a basso costo o addirittura gratis, ma che necessitano di acquisire
competenze informatiche di base per poterle utilizzare in modo produttivo.

Partendo dagli strumenti più semplici, i colossi dell’informatica
e del web – come Microsoft e Google, ma anche Apple per i suoi utenti – hanno messo
a disposizione, insieme alle relative suite di produttività (es. Office
365), anche alcuni strumenti per lavorare su documenti condivisi tramite
cloud (ad es. Google Drive, One Drive), per comunicare in modo organizzato
sul medesimo progetto, per organizzare riunioni via web (es. Skype for
Business ora migrato in Teams, Google Meet, Hangout, oppure GoToMeeting, ecc.).
Tali strumenti permettono di lavorare a distanza su documenti informatici, anche
contemporaneamente, di condividere lo schermo e di vedersi in modo estremamente
proficuo, anche per l’ambiente. Infatti, un effetto collaterale benefico di
questa emergenza coronavirus è la riduzione del traffico – e quindi dell’inquinamento
– nelle strade e l’eliminazione della carta, ovvero della stampa di documenti,
quando non necessaria.

Le aziende più strutturate avevano già previsto modalità di “telelavoro”
nelle quali il PC utilizzato dal dipendente fuori sede poteva collegarsi
direttamente ai sistemi informatici aziendali tramite VPN.

Per fare questo passo ulteriore, e collegarsi tramite
internet ai sistemi aziendali, occorrono maggiori competenze del reparto
sistemistico aziendale (troppo spesso ridotto all’osso o demandato all’esterno
a consulenti che magari in questo momento sono molto impegnati) ed altre
tecnologie.

Il mercato degli applicativi gestionali ha favorito questa
trasformazione attraverso il rilascio di applicativi web che non
necessitano di installazione su server in azienda o comunque che non funzionano
in tecnologia client-server, ma possono essere resi accessibili via web da
qualsiasi parte del mondo, dunque anche da casa propria, anche se si è in
quarantena, ma si gode di ottima salute!

Chiaramente l’utilizzo di tutti questi strumenti “innovativi” non può essere realizzato da un giorno all’altro in modo efficace ed efficiente, occorrerebbe un periodo di formazione del personale e di test. Ma l’emergenza non ci concede questo tempo e – come al solito – siamo costretti ad operare in modalità diverse a fronte di un evento destabilizzante. È giocoforza ricordare che proprio in questi giorni è uscita la versione italiana della norma UNI EN ISO 22301:2019 sui sistemi di gestione della continuità operativa (leggi l’articolo), ovvero sulla business continuity. Ma quante aziende avevano un piano di business continuity che considerasse lo scenario della pandemia o comunque dell’assenza forzata dal lavoro di numerose persone?

Dunque molti sono costretti a improvvisare, ma occorre
pensare anche alla sicurezza delle attività lavorative a distanza, ovvero
occorre ragionare in termini di “security”, mentre alla “safety” delle persone
si pensa cercando di evitare il più possibile i contatti fisici.

Se con lo smartworking preveniamo i l corona-virus,
siamo sicuri di prevenire anche i virus informatici, ovvero il malware che
potrebbe far perdere la necessaria riservatezza, integrità e/o disponibilità ai
nostri dati? Riusciamo a garantire il rispetto della normativa sulla protezione
dei dati (GDPR)?

Ci viene in soccorso la UNI EN ISO 27002 (Linea Guida
sui controlli di sicurezza delle informazioni), al punto 6.2.2 Telelavoro, ma
non solo.  Tale norma ci insegna che:

«Dovrebbero essere attuate una politica e delle misure di
sicurezza a suo supporto (del telelavoro) per proteggere le informazioni
accedute, elaborate o memorizzate presso siti di telelavoro. »

Perciò le organizzazioni che permettono attività di
telelavoro o smartworking – e in questo momento sono moltissime, anche a
fronte della modifica normativa – dovrebbero emettere una policy che definisca
le condizioni e le limitazioni al telelavoro, ovvero stabilire delle regole
generali per gestire lo smartworking in modo sicuro, nelle diverse
situazioni.

Gli aspetti da considerare dovrebbero essere i seguenti:

• Il livello di sicurezza fisica del sito
  di telelavoro (es. l’abitazione del dipendente/collaboratore oppure il luogo
  pubblico dove esso può esercitare l’attività lavorativa), considerando gli
  edifici e l’ambiente circostante. In pratica consideriamo il fatto che se la
  postazione di lavoro non è all’interno della sede aziendale devono essere
  garantiti un accesso controllato in modo continuo delle persone estranee a
  documenti e dispositivi elettronici. L’abitazione ha una porta blindata e/o un
  sistema di allarme? La postazione di lavoro è facilmente accessibile da porte o
  finestre aperte?
• L’ambiente di telelavoro proposto: l’azienda
  può prevedere l’utilizzo di determinati tipi di locali piuttosto che altri (es.
  divieto di lavorare in luoghi pubblici).
• I requisiti per la sicurezza delle
  comunicazioni, tenendo in considerazione la necessità di accesso remoto ai
  sistemi interni dell’organizzazione (ad esempio l’accesso più sicuro è tramite
  VPN crittografata), la criticità delle informazioni che sono accedute e
  trasmesse attraverso il canale di comunicazione (ad es. dati personali
  appartenenti a categorie particolari di dati), nonché la criticità del sistema
  interno. Occorre cambiare il punto di vista: le comunicazioni non avvengono più
  all’interno dell’azienda, ma dall’interno all’esterno e viceversa e necessitano
  di essere protette con comunicazioni crittografate. Anche il semplice invio di
  e-mail dall’ufficio all’abitazione del dipendente dovrebbe comunque garantire
  trasmissioni sicure (es. con crittografia SSL/TLS) su un indirizzo privato
  approvato e l’accesso a siti sFTP dovrebbe essere preferito rispetto ai meno
  sicuri FTP.
• La fornitura di accesso in modalità desktop
  virtuale che prevenga l’elaborazione e la memorizzazione di informazioni su
  dispositivi privati: se il dispositivo usato dal dipendente è il proprio PC
  casalingo – e non un notebook fornito dall’azienda – potrebbe essere opportuno
  non consentire il salvataggio di dati particolarmente riservati in locale, ma
  solo di lavorare in desktop remoto sul PC aziendale.
• Le minacce di accesso non autorizzato alle
  informazioni o alle risorse da parte di altri soggetti che frequentano il
  luogo di lavoro flessibile, per esempio i famigliari e gli amici: evidentemente
  in un contesto privato possono esserci altri soggetti che non sono autorizzati
  ad accedere alle informazioni aziendali che potrebbero accedervi, pertanto
  occorre stabilire regole ferree con i dipendenti (es. divieto di divulgare
  password a conviventi).
• L’uso di reti casalinghe e i requisiti o le
  limitazioni alla configurazione dì servizi wireless di rete: soprattutto se
  il collegamento alla rete aziendale non avviene tramite VPN è importante
  garantire la sicurezza della rete cablata o Wi-Fi dell’abitazione o di altro
  luogo ove si è abilitati a lavorare. Quasi tutti i dispositivi sono in grado di
  valutare se la rete Wi-Fi a cui ci si collega dispone almeno di un livello di
  sicurezza WPA2. In caso negativo occorre configurare adeguatamente il
  router/modem casalingo, se si è in un luogo pubblico meglio astenersi dalla
  connessione. In certi casi è l’azienda stessa a fornire una connessione sicura
  tramite scheda SIM 3G/4G.
• Le politiche e le procedure per prevenire
  discussioni riguardo i diritti per la proprietà intellettuale sviluppatisi
  su dispositivi privati: è opportuno stabilire regole precise per chiarire al
  dipendente che eventuali progetti sviluppati in smartworking casalingo
  rimangono di proprietà dell’azienda.
• L’accesso a dispositivi privati (per verificare
  la sicurezza del sistema o durante un’indagine), che potrebbero essere proibiti
  dalla legge. Se il dipendente usa un proprio dispositivo privato che contiene
  materiale illegale o viene usato per consultare siti illegali potrebbero
  esserci dei problemi.
• Gli accordi di licenza del software tali
  per cui le organizzazioni potrebbero diventare responsabili per le licenze di
  software sulle workstation private di proprietà del personale o di utenti di
  terze parti. Chiaramente se il dipendente utilizza il proprio PC occorre che le
  licenze software siano conformi alla legge applicabile. Anche un Office con
  licenza Student o Privata non potrebbe essere usato per scopi aziendali o
  professionali. Eventuali indagini dell’Autorità potrebbero creare problemi al
  dipendente ed all’azienda.
• Le protezioni dal malware e i requisiti per
  l’uso di firewall in caso di utilizzo di PC privati devono essere comunque
  garantiti. Sarebbe bene richiedere la presenza di un anti-malware ed un
  firewall di livello equivalente a quello aziendale (le licenze free degli
  antivirus sono da evitare).

In generale dovrebbero essere stabilite regole fra azienda e
dipendente che definiscano quali dispositivi utilizzare, come utilizzarli, dove
poter lavorare, quali misure di sicurezza occorre mantenere sempre, come
gestire i backup delle informazioni e le stampe, quali informazioni si possono
elaborare, se ci sono particolari restrizioni per il trattamento di dati
personali appartenenti a categorie particolari di dati (art. 9 del GDPR), la
gestione delle procedure di autenticazione e la gestione delle password, le
attività non consentite dai dispositivi utilizzati anche per lavoro e così via.

Anche per attività che richiedono software particolari e
costosi (es. editing grafico e progettazione CAD) i produttori di software
stanno venendo incontro agli utenti con licenze non legate ad un particolare
dispositivo fisico, ma utilizzabili, con il supporto del cloud, su dispositivi
differenti, anche se non contemporaneamente.

Purtroppo sono tutti elementi che non si possono
improvvisare da un giorno all’altro, ma che sarebbe opportuno considerare e
gestire anche nell’emergenza.

Infine occorre considerare un problema di capacità:
se un’azienda normalmente è strutturata per uno smartworking
contemporaneo del 20% dei dipendenti (ad esempio una giornata lavorativa a
settimana) e in questa situazione di emergenza il lavoro a distanza sale al 90%,
probabilmente le reti e le VPN dovranno essere ridimensionati per supportare
tutto il traffico, nella consapevolezza che le connessioni di rete delle
abitazioni dei dipendenti potrebbero non garantire prestazioni sufficienti e
questo problema potrebbe essere difficile da ovviare anche con connessioni
tramite chiavette con SIM 4G se l’abitazione del dipendente si trova in una zona
mal servita dai provider internet.

In questo articolo parleremo ancora di business continuity, ovvero di business continuity plan ed in particolare della progettazione delle procedure di disaster recovery.

Molte organizzazioni che non predispongono un vero e proprio piano di continuità operativa (o business continuity plan, BCP), comunque hanno una procedura di disaster recovery, più o meno evoluta. Purtroppo, però, questa attività viene delegata quasi interamente ai responsabili ICT senza coinvolgere il management, i responsabili dei processi primari di business ed in particolare di quelli più critici.

Non che i responsabili ICT non siano in grado di progettare una procedura di disaster recovery adeguata, ma spesso sono loro stessi che stabiliscono i requisiti di base del disaster recovery, ovvero implicitamente definiscono gli obiettivi RTO e RPO che dovrebbero essere alla base della procedura.

Riprendiamo le definizioni di questi indici, già esposte in precedenti articoli, per capire meglio di cosa si tratta.

• Recovery Point Objective (RPO) ovvero il punto (l’istante nel tempo) al quale le informazioni sono coerenti e possono essere ripristinate per consentire la ripresa delle attività (denominato anche Maximum Data Loss).
• Recovery Time Objective (RTO): periodo di tempo entro il quale i servizi erogati, la produzione, i servizi di supporto e le funzionalità operative devono essere ripristinati dopo l’incidente che ha generato la discontinuità.

 

Facciamo un esempio per comprendere meglio il significato degli indici sopra esposti.

Supponiamo che una piccola organizzazione che opera nel settore dei servizi, denominata ALFA srl, decida di effettuare un backup incrementale dei propri dati con frequenza giornaliera su un NAS interno, mantenendo le ultime 7 versioni dei dati e che poi, per cautelarsi a fronte di eventuali catastrofi naturali che potrebbero rendere inutilizzabile il sistema informatico aziendale e tutti i backup salvati su NAS, effettui anche un backup completo su nastri DAT con cadenza settimanale. I nastri magnetici dell’ultimo backup settimanale sono conservati a casa del titolare, a 20 km di distanza dalla sede dell’azienda, il quale quando si porta via il backup restituisce quello della settimana precedente.

Qual è il valore di RPO e RTO per questa azienda?

Occorre distinguere fra diversi tipi di problemi (disastro):

1. Si tratta di un crash del sistema che ha comportato la perdita dei soli dati (eventualmente anche dei supporti di memorizzazione) oppure
2. Si tratta di un evento catastrofico che ha reso inutilizzabile l’intero server e l’infrastruttura informatica della sede di ALFA?

Evidentemente nel primo caso potrebbero essere sufficienti i backup su supporto NAS da ripristinare su un nuovo hard disk, reperibile in tempi brevi. Dunque il RTO potrebbe essere pari anche ad una sola giornata, dipende dal tempo che si impiega a ripristinare il sistema (tempi di acquisto dei nuovi supporti di memorizzazione, tempi di eventuale reinstallazione del sistema operativo del server e degli applicativi, ecc.). Il RPO invece è pari ad una giornata di lavoro o meno, a seconda dal tempo trascorso dall’ultimo backup giornaliero eseguito. In questo caso per valutare correttamente il RTO occorre capire quanto tempo si impiegherebbe a reinstallare il sistema, partendo dai supporti originali oppure da un’immagine del sistema creata attraverso l’impiego di macchine virtuali. Questa seconda soluzione, certamente più costosa della prima, potrebbe abbassare drasticamente il RPO.

Nel secondo caso il ripristino dell’operatività dipende anche dai danni generati alla sede dell’organizzazione: che si sia verificato un terremoto che ha reso inagibili i locali oppure un’alluvione i cui danni possano essere riparati entro qualche giorno o settimane la situazione può essere sensibilmente differente e il RTO, anche in questo caso può essere di alcuni giorni o settimane, indipendentemente dalla strategia di backup implementata. Il backup settimanale su nastro, conservato in un luogo sicuro (da valutare se la distanza dalla sede è sufficiente per garantire un’alta probabilità di evitare danni), garantirebbe un RPO di al massimo una settimana di dati persi.

Bisogna capire se questi valori, di RPO e RTO, sono accettabili per l’organizzazione oppure le perdite, in termini di dati e di discontinuità operativa, mettono a repentaglio la sopravvivenza dell’azienda.

Ricordiamo che per alcune attività critiche il verificarsi di eventi disastrosi con RTO di settimane e di RPO di una settimana potrebbero portare a danni economici ingenti, non coperti da polizze assicurative (ritardi nella consegna di commesse con addebito di penali da parte del committente, perdita di commesse importanti, ecc.).

In questa seconda situazione occorrerebbe certamente un sito di disaster recovery, ovvero un sito alternativo, geograficamente distante dalla sede principale dell’azienda, in grado di consentire la ripresa dell’attività in pochissimo tempo (ore, al massimo una giornata lavorativa) e la perdita dei dati di al massimo una giornata, dunque ottenendo un RTO = 1 giorno e RPO = 1 giorno. Ciò potrebbe essere ottenuto senza investimenti consistenti in una struttura gemella, ma dotandosi di una infrastruttura tecnologica in cloud.

In conclusione la procedura di disaster recovery dovrebbe essere progettata da personale competente (responsabile IT, consulenti esterni, …) basandosi su precisi input da parte della Direzione aziendale, derivanti da obiettivi di RPO e RTO ritenuti adeguati per l’organizzazione. La procedura di disaster recovery progettata avrà dei costi (che possono variare in base alle soluzioni scelte) che la Direzione dovrà mettere a budget per garantirsi gli obiettivi desiderati. Viceversa bisognerà migrare verso obiettivi meno ambiziosi di RPO e RTO, ma la Direzione deve essere consapevole di ciò. In caso di disastri, infatti, nessuno potrà accusare altri di non aver pensato alle giuste contromisure ed ognuno si assumerà le responsabilità che gli spettano.

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.

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

Struttura della norma

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

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

Ogni categoria principale di controllo di sicurezza contiene:

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

La descrizione dei controlli sono strutturate come segue:

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

Elenco dei controlli

I punti di controllo definiti dalla norma sono i seguenti:

5 Politiche per la sicurezza delle informazioni

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

6 Organizzazione della sicurezza delle informazioni

In questa sezione sono definiti le seguenti categorie principali:

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

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

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

7 Sicurezza delle risorse umane

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

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

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

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

8 Gestione degli asset

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

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

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

9 Controllo degli accessi

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

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

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

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

10 Crittografia

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

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

11 Sicurezza fisica e ambientale

La sezione comprende due categorie:

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

fine I parte ….continua…

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

La nuova ISO 27001 non riporta termini e definizioni, ma richiama la ISO 27000.2014 (scaricabile gratuitamente da http://www.iso27001security.com/html/27000.html e curiosamente venduta dall’UNI a € 138 ) per tutti i termini utilizzati nelle norme della serie ISO 27k.

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

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

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

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

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

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

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

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

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

Naturalmente la valutazione dei rischi deve essere documentata.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La privacy dei privati cittadini utenti delle farmacie e dei piccoli ambulatori privati spesso è messa a repentaglio da una gestione non accurata delle regole stabilite dalla normativa al riguardo (D.Lgs 196/2003 – “Codice per la protezione dei dati personali”) e da tutte le buone pratiche di gestione della sicurezza delle informazioni.

I titolari di farmacie ed ambulatori medici polifunzionali sono di fatto legali rappresentanti di imprese che, seppur di piccole dimensioni, raccolgono e gestiscono dati personali sensibili (in particolare dati sanitari relativi alla salute delle persone) di una grande moltitudine di persone fisiche e, come tali, sono tenuti a rispondere di fronte alla legge di tali gestioni.

In questi ultimi anni si è passati da una gestione prevalentemente cartacea dei dati personali sensibili raccolti da queste organizzazioni, ad una gestione elettronica di molte informazioni che riguardano la sfera privata delle persone, ovvero i dati sanitari.

Se pensiamo ad una farmacia moderna possiamo trovare molti trattamenti di dati in formato digitale che solo pochi anni fa non erano presenti: si passa dal ben noto scontrino fiscale parlante (sul quale ha molto disquisito il Garante della Privacy), generato e poi gestito da un sistema informatico, alla ricetta elettronica di recente introduzione, passando per una serie di servizi che le farmacie hanno introdotto da pochi anni: intolleranze alimentari, analisi della pelle, gestione referti esami diagnostici, preparazione di diete, fidelity card, e-commerce, ecc.. Ma anche servizi meno recenti come le prenotazioni di esami tramite CUP ASL o la Dispensazione per Conto vengono gestiti dalle farmacie, attraverso appositi portali dedicati, per conto dei clienti.

Ognuno di questi trattamenti di dati presenta vulnerabilità intrinseche per la sicurezza delle informazioni trasmesse: credenziali di accesso non sufficientemente difficili da individuare, scarsa protezione dei PC e dei Server da attacchi esterni, inadeguata protezione dei medesimi elaboratori in caso di furto e via dicendo.

Come le piccole organizzazioni di altri settori industriali o dei servizi, anche le farmacie non sono dotate di personale esperto nella gestione della sicurezza dei sistemi informatici e spesso il coinvolgimento dei fornitori esterni specializzati non è così sistemato (soprattutto per motivi di costo) da poter garantire una protezione adeguata.

D’altro canto dai computer delle farmacie transitano quantità di dati sensibili di gran linga superiori a quelle di altre piccole organizzazioni e costituiscono il canale di consultazione di archivi di prenotazione di esami diagnostici di un elevatissimo numero di pazienti. Da qui la necessità di proteggere i sistemi informatici delle farmacie, sia da un punto di vista logico, sia fisico, in modo molto più attento rispetto ad un normale PC aziendale.

Anche i piccoli ambulatori privati, che ospitano medici che eseguono visite specialistiche ed esami diagnostici, ultimamente hanno trovato grande beneficio dall’utilizzo delle nuove tecnologie, nonostante la ritrosia all’utilizzo del computer da parte di numerosi medici. Tutto ciò, però, comporta la necessità di proteggere adeguatamente i dati sensibili dei pazienti che transitano in formato digitale in reti locali poco protette. In tali organizzazioni spesso non è nemmeno chiaro chi è il titolare del trattamento dati – il medico che visita il paziente o il centro medico – ed a chi vengono eventualmente delegate le responsabilità per i trattamenti delegati ad altri.

In generale, nelle farmacie e nei piccoli centri medici, tutta la “parte informatica” è delegata a fornitori specializzati che talvolta non conoscono in modo preciso la normativa sulla privacy e sono negligenti nel sottoscrivere le proprie assunzioni di responsabilità a fronte delle attività eseguite; conseguentemente tutte le responsabilità ricadono sul titolare del trattamento, persona fisica o giuridica avente comunque un legale rappresentante, generalmente poco avvezzo a questioni informatiche.

Dal punto di vista normativo, poi, il passaggio da una normativa italiana – molto completa e severa per taluni aspetti, ma ormai obsoleta per quanto riguarda il disciplinare tecnico delle misure minime di sicurezza – ad un nuovo Regolamento Europeo in fase di approvazione, non fa che complicare le cose per le piccole organizzazioni che finora hanno avuto regole precise (password di almeno 8 caratteri variate ogni 3 mesi se si trattano dati sensibili, backup almeno ogni 7 giorni, aggiornamenti semestrali dei programmi software, assenza di idonee dichiarazioni di conformità dei fornitori, ecc.) con le quali confrontarsi. Il nuovo Regolamento, infatti, introdurrà la necessità di valutare i rischi che si corrono dal punto di vista della sicurezza dei dati personali e, conseguentemente, progettare il sistema di gestione della privacy in funzione delle reali esigenze di riservatezza, adottando misure di sicurezza adeguate (non solo “minime”).

Inoltre l’attuale versione del Regolamento Europeo sulla Privacy in approvazione contiene l’obbligo per i titolari di dati personali di dotarsi – entro determinate condizioni – di un “Privacy Officer”, ovvero di una persona, dotata di adeguate competenze in materia di privacy e sicurezza dei dati, responsabile per la gestione della privacy all’interno dell’organizzazione. Ma il limite attualmente stabilito per l’obbligo di nominare un Privacy Officer è legato al numero di dati personali gestiti (più di 5000 in un anno) che viene facilmente superato da una farmacia di medio volume di affari, ma non da numerose imprese industriali con oltre 50 dipendenti.

La ratio del nuovo Regolamento UE è evidentemente quella di garantire migliore protezione dove esistono maggiori rischi, sia per il numero di dati personali trattati, sia per la vulnerabilità dei sistemi.

Il cambio di mentalità di chi gestisce piccole organizzazioni nel settore sanitario non sarà facile, anche perché non ci saranno più regole precise da seguire per stare tranquilli, ma, oserei dire giustamente, il Regolamento Europeo ribalterà la responsabilità di progettare un sistema di gestione della privacy adeguato sulle spalle degli imprenditori. Molti di questi ultimi non saranno in grado di valutare in modo competente ed oggettivo quali misure adottare e dovranno fare attenzione a non credere alle “ricette preconfezionate” a basso costo che hanno già rovinato l’approccio alla privacy negli anni del ben noto DPS (Documento Programmatico sulla Sicurezza).

Già oggi il rischio di molte piccole organizzazioni del settore sanitario è quello di non essere conformi alla legislazione attuale sotto diversi aspetti (mancate nomine degli incaricati, mancanza di credenziali di autenticazione ai sistemi informatici adeguate e variate periodicamente, utilizzo troppo invasivo della videosorveglianza, archiviazione di dati privi di protezione, ecc.), figuriamoci domani se saranno i titolari del trattamento (ovvero i legali rappresentanti o direttori delle organizzazioni) a dover decidere quali misure di sicurezza sono adeguate! Il rischio concreto è quello di sottovalutare il problema privacy, come del resto è avvenuto dopo l’abolizione del DPS che non ha abolito tutti gli altri adempimenti!

Dimenticarsi di proteggere adeguatamente i dati personali dei propri clienti può comportare non solo sanzioni civili (e in alcuni casi anche reati penali) in caso di ispezione da parte del nucleo Privacy della Guardia di Finanza (oggi peraltro molto rare), ma anche, in caso di richiesta di risarcimento danni da parte dell’interessato i cui dati sensibili sono stati violati, ingenti perdite economiche. Talvolta, poi, la mancata diligenza del titolare del trattamento potrebbe portare anche al divieto di intraprendere relazioni commerciali con la Pubblica Amministrazione, riducendo o annullando di fatto la possibilità di operare.

Infine, oltre agli aspetti legati al rispetto della normativa cogente, esistono altri pericoli a cui è sottoposta una organizzazioni che gestisce in modo inconsapevole la sicurezza dei dati, ad esempio la perdita di dati e l’indisponibilità di risorse per garantire la continuità del servizio al cliente e, quindi, perdite economiche più o meno rilevanti in funzione della gravità dell’evento.

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.

In precedenti articoli (Il cloud computing e la PMI, i sistemi di gestione della sicurezza delle informazioni, ISO 22301 e la business continuity, le novità sulla privacy) abbiamo affrontato tutti questi argomenti che, indubbiamente, hanno un unico filo conduttore.

Oggi molte aziende, fra cui anche numerose PMI, hanno dati “nel cloud”, ovvero memorizzati in risorse fisiche non collocate all’interno dell’azienda, bensì su internet, magari senza rendersene conto. Infatti, oltre a veri e propri servizi cloud erogati da fornitori specializzati, molte PMI utilizzano servizi di archiviazione gratuiti quali SkyDrive, Dropbox o Google Drive in maniera non strutturata, in quanto sono propri reparti o uffici o addirittura singoli collaboratori che, per praticità, hanno pensato di sfruttare suddetti tool di archiviazione remota.

In altri casi alcune organizzazioni utilizzano software via web che memorizzano i dati su server remoti, magari presso il fornitore del software (spesso si tratta di Saas, Software as a Service).

Tra i principali aspetti negativi che hanno generato diffidenza sull’archiviazione nel cloud c’è sicuramente la sicurezza dei dati, declinata in termini di riservatezza. Molti imprenditori, infatti, hanno la sensazione che alcuni dati riservati (informazioni commerciali, proprietà intellettuale relativa a progetti, ecc.) debbano rimanere in azienda per paura che qualcuno li possa consultare.

Normalmente una PMI, specialmente una piccola impresa, non effettua un’adeguata valutazione dei rischi che corre e, pertanto, valuta questo argomento a sensazione, piuttosto che con fatti concreti. Quali sono infatti i rischi reali?

In una logica di Risk Assessment, naturalmente, ogni impresa fa storia a se; bisogna conoscere quali dati vorrebbe mettere sul cloud, qual è il livello di riservatezza che tali dati devono avere, se si tratta di dati sensibili, quali procedure di backup sono implementate, di che tipo di connessione internet si dispone e così via.

In linea generale parlare di dati poco sicuri nel cloud perché si teme che qualcuno possa “guardarci dentro” non ha molto senso: a parte che bisognerebbe valutare quale livello di sicurezza ci si aspetta per ogni tipo di dato (si veda il precedente articolo sulla valutazione dei rischi per la sicurezza delle informazioni), oggi molti repository di dati nel cloud forniscono ampie garanzie di sicurezza, soprattutto se sono gestiti da importanti player del settore, quali Microsoft, Google, Amazon, ecc.

Se, come al solito, decliniamo il termine Sicurezza in Riservatezza, Integrità e Disponibilità (ISO 27000 docet) e valutiamo nel complesso il livello di rischio che incombe sui dati nel cloud, vediamo che, a fronte di un livello di riservatezza più che adeguato (i dati di una PMI nel cloud normalmente sono sufficientemente protetti da sguardi indiscreti, grazie alle misure di sicurezza informatica che i fornitori più seri offrono ormai per default), certamente superiore a quello che si può ottenere all’interno dell’azienda stessa (dove potrebbero esserci soggetti interessati a curiosare dove non dovrebbero) la garanzia di integrità dei dati è più che buona, ma sulla disponibilità degli stessi occorre fare qualche riflessione.

Su quest’ultimo aspetto incide non solo l’affidabilità del fornitore di servizi cloud e dell’infrastruttura di cui dispone, ma anche la connessione internet che, ancora ogg,i non è sicuramente adeguata in molte imprese italiane, sia per velocità, sia per continuità del servizio. È proprio questo l’anello di congiunzione con la continuità operativa, più elegantemente detta business continuity.

Infine la privacy, ovvero la protezione dei dati personali con la relativa legge italiana (D.Lgs 196/2003) ed il nuovo Regolamento Europeo che sarà emanato probabilmente il prossimo anno. In questo ambito un Parere della Commissione Europea del 2012 ha per il momento fugato molti dubbi sulle garanzie legali che un’impresa dovrebbe richiedere al proprio fornitore di servizi cloud per essere tranquilla di non incorrere in pesanti problemi legali.

Probabilmente molti contratti che regolamentano la fornitura di servizi cloud (spesso mascherati sotto la fornitura di software as a service) non cautelano adeguatamente l’organizzazione che, non dimentichiamolo, è titolare del trattamento dei dati memorizzati in un server chissà dove. È prassi consolidata, infatti, di numerosi fornitori di SaaS di spostare i database dei propri clienti nello spazio web più conveniente per rapporto qualità/prezzo, non importa se in Canada o in Australia In tali situazioni le aziende non dovrebbero dimenticare che come titolari del trattamento sono i responsabili di fronte alla legge su eventuali inosservanze del Codice della Privacy e che “esportare” i dati personali fuori dalla Comunità Europea non è sempre possibile, come minimo occorre richiedere il consenso dell’interessato.

Dunque quali interrogativi deve porsi un’azienda coscienziosa prima di affidare i propri dati al cloud?

Vediamo i principali, fermo restando che solo dopo una precisa valutazione dei rischi si può determinare quali aspetti sono più critici in ogni singola realtà.

1. Il contratto con il fornitore mi garantisce adeguatamente rispetto alla normativa sulla privacy?
2. Il livello di riservatezza necessario sui dati è adeguatamente garantito da misure di sicurezza dichiarate contrattualmente dal fornitore?
3. La disponibilità dei dati garantita contrattualmente (SLA) è adeguata alle mie esigenze?
4. Posso rientrare in possesso dei miei dati quando voglio e senza costi eccessivi?
5. Il fornitore è sufficientemente affidabile? Si serve di subfornitori egualmente affidabili e resi noti contrattualmente?
6. In caso di perdita dei dati quali sistemi di disaster recovery mi garantiscono di rientrare operativo nel più breve tempo possibile? Tale tempo è coerente con le mie esigenze operative?
7. So esattamente in quale stato o area geografica sono memorizzati i miei dati?
8. Ho considerato tutti i possibili fattori di rischio che possono incombere sulla mia continuità operativa?
9. Ho definito gli obiettivi di disponibilità del servizio e di business continuity in caso di situazione di crisi?
10. Sono in grado di monitorare il comportamento del fornitore ed eventualmente sottoporlo ad audit sul rispetto dei vincoli contrattuali?

Oggi esistono molti sistemi per garantirsi un futuro tranquillo con i dati nel cloud, ad esempio seguendo i principi ed i metodi indicati dalle norme della famiglia ISO 27000 (ISO 27001 che riporta i requisiti di un sistema di gestione della sicurezza delle informazioni certificabile, ISO 27002 che riporta le best practices, ovvero i controlli che possono essere messi in atto, ISO 27005 che è la linea guida per il risk assessment, …) includendovi i requisiti cogenti per la privacy in vigore in Italia ed in Europa. Se il problema di mantenere una certa continuità operativa costituisce un fattore critico si può adottare la metodologia esposta nella ISO 22301 ed in altri standard e linee guida sull’argomento.

Mediante gli stessi sistemi ci si può garantire in modo adeguato nei confronti del fornitore, ad esempio esaminando il contratto con un supporto legale competente, verificare se il fornitore dispone di certificazioni ISO 9001, ISO 27001, ISO 22301 oppure dispone di un Report SSAE 16 (“Statement on Standards for Attestation Engagements” n. 16 , standard AICPA per il reporting sui controlli alle organizzazioni che forniscono servizi in outsourcing, richiesto dalle aziende soggette al Sarbanes-Oxley Act o SOX,  Sezione 404).

Se ascoltiamo quello che ci raccontano gli esperti di sicurezza informatica che relazionano nei frequenti seminari o convegni sull’argomento non c’è certo da stare tranquilli nemmeno all’interno della propria azienda (tra ransomware e data leakage ogni tanto nascono minacce sempre più terrificanti per il futuro delle nostre imprese, senza dimenticare il comportamento dei collaboratori disonesti) e, quindi, un cloud consapevole può veramente essere una buona cosa.

Dall’altra parte la software house che fornisce applicazioni web-based con l’opzione di memorizzare i dati, anziché su un server interno all’azienda, su un server remoto (ovvero nel cloud) dovrebbe prendere in considerazione tutti gli aspetti sopra esposti, sia al fine di fornire un servizio pienamente conforme alle normative applicabili e di piena soddisfazione di tutte le esigenze del cliente, sia al fine di non incorrere in problemi legali nel caso in cui qualcosa andasse storto, anche solo a causa del proprio fornitore di servizi cloud. Dunque valutare quali tipi di dati verranno archiviati nel cloud dai propri clienti e quali garanzie forniscono i fornitori di spazio di archiviazione a cui ci si rivolge (le caratteristiche di un data center sicuro sono state esposte in un articolo apparso lo scorso anno sulla rivista INARCOS).

In conclusione, come per qualsiasi decisone o progetto strategico, le aziende (clienti e fornitori) dovrebbero valutare con adeguate competenze la situazione nel suo complesso ed i rischi che si potrebbe correre. Purtroppo tali competenze, informatiche, legali e gestionali spesso non sono presenti in piccole realtà poco strutturate che, quindi, rischiano di incorrere in problemi significativi e se poi trattano dati sensibili, in particolare dati sanitari, potrebbero veramente incorrere in perdite economiche e di immagine molto importanti.