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 quello ottenibile impiegando il 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 del 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 18, 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 tali servizi delle tipologie sopra elencate (payroll, contabilità, gestione documentale, ecc.) 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. 18 è il nuovo standard per effettuare la reportistica sui controlli nelle aziende di servizi – sostituendo le precedenti SSAE no. 16 e 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 o ad una ISO 27001. Le modifiche apportate dal nuovo standard richiedono alle aziende di prendere maggiore controllo e proprietà dei propri controlli interni, relativamente all’identificazione e alla classificazione del rischio e alla gestione appropriata delle relazioni con i fornitori di terze parti.

Il report SSAE 18 (Statement on Standards for Attestation Engagements no. 18) 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 18 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 18 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 18 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 completamento 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

La normativa IATF 16949 prevede alcuni requisiti che riguardano la sicurezza delle informazioni dell’organizzazione automotive ed infatti le Sanctioned Interpretation riguardano anche la sicurezza delle informazioni gestite. Ricordiamo che una Sanctioned Interpretation modifica l’interpretazione di una regola o di un requisito della IATF 16949 e diventa essa stessa la base di una non conformità.

In particolare, alcune di esse riguardano ai punti seguenti:

6.1.2.3 PIANI DI EMERGENZA

L’organizzazione deve:

a) – b) (…)

c) preparare piani di emergenza per la continuità della fornitura in caso si verifichino: guasti di apparecchiature chiave (vedere anche sezione 8.5.6.1.1), interruzione dei prodotti, processi e servizi di fornitura esterna, disastri naturali, incendi, interruzione di servizi, attacco informatico ai sistemi informativi, mancanza di manodopera o problemi alle infrastrutture.

S.I.: “Le organizzazioni devono affrontare la possibilità di un attacco informatico che potrebbe interrompere le proprie attività produttive e logistiche, inclusi i ransomware. Le organizzazioni devono assicurarsi di essere preparate in caso di attacco informatico.”

7.1.3.1 PIANIFICAZIONE DELLO STABILIMENTO, DEI MEZZI E DELLE APPARECCHIATURE

…l’organizzazione deve… implementare la protezione informatica delle apparecchiature e dei sistemi di supporto della produzione

S.I.: “La sicurezza informatica non si limita alle funzioni di supporto e alle aree degli uffici che utilizzano i computer. Anche la produzione utilizza controlli e attrezzature computerizzati potenzialmente a rischio in caso di attacchi informatici. L’aggiunta di questo requisito guida verso l’implementazione delle protezioni necessarie per garantire il continuo funzionamento e l’ininterrotta produzione, al fine di soddisfare le esigenze dei clienti”

Le suddette prescrizioni restano generiche e non entrano molto nel merito di una disciplina molto articolata e complessa come quella della sicurezza delle informazioni in generale e della sicurezza informatica in particolare.

Per questa ragione è uscito lo standard TISAX® (Trusted Information Security Assessment eXchange), che rappresenta uno schema a fronte del quale le aziende automotive più importanti (OEM, Tier 1) richiedono l’assessment ai loro fornitori in quanto essi trattano informazioni critiche dal punto di vista della Riservatezza, dell’Integrità e della Disponibilità delle stesse.

È facile immaginare che alcune informazioni scambiate nella catena di fornitura automotive, richiedono una certa protezione. Si tratta di: dati di prodotti e di componenti (specifiche tecniche, documenti progettuali e disegni dimensionali, dati di validazione file PPAP/APQP, dati di collaudo e omologazione), dati aziendali fondamentali per il business (schede processi, programmi di produzione, software di produzione e manutenzione, informazioni personali, strategie aziendali, dati di marketing e di vendita), dati collegati ai rapporti tra fornitori e clienti del settore (offerte, contratti, ordini di componenti, fatture, piani di consegne, dati e informazioni su clienti e fornitori), dati su veicoli (anomalie, guasti, richieste di assistenza, …).

TISAX è un meccanismo di valutazione e di scambio dei risultati di un assessment fra le organizzazioni della catena di fornitura automotive, nato per iniziativa del VDA tedesco – attualmente responsabile dello schema – e che si sta affermando come una declinazione degli standard di sicurezza delle informazioni (ISO 27001 su tutti, ma anche SPICE ISO 15504 per il software automotive) nel settore automotive.

Il sistema TISAX si basa su:

1. Una registrazione dell’azienda al TISAX®
2. La scelta di un organismo (audit provider) che effettua audit secondo questo schema
3. L’esecuzione dell’assessment da parte dell’organismo indipendente
4. La condivisione dei risultati dell’assessment con i partecipanti al TISAX e l’accesso ai dati degli altri partecipanti.

I partecipanti registrati al TISAX possono anche essere OEM che si ritengono partecipanti “passivi” in quanto non effettuano un assessment, ma invitano i loro fornitori a farlo per poi accedere ai risultati dell’assessment stesso.

L’intero meccanismo è monitorato dall’ENX, associazione no profit che svolge un ruolo simile ad un Ente di Accreditamento.

L’audit o assessment TISAX porta ad ottenere una “Label” mediante un processo che è del tutto simile a quello delle certificazioni dei sistemi di gestione.

L’assessment TISAX ha uno scopo, un ambito di applicazione per il quale viene valutato dall’audit provider (esiste lo scopo di tipo Standard, Narrow ed Extended).  L’ambito di applicazione di una valutazione TISAX, però, non può essere determinato dall’organizzazione, ma deve necessariamente comprendere tutti i processi e le risorse coinvolte nel trattamento di informazioni afferenti all’industria automobilistica.

Dallo scopo derivano gli obiettivi dell’assessment che permettono di ottenere una “Label” di un determinato tipo (Livello di Maturità da 0 = Incomplete a 5 = Optimizing).

La documentazione (tutta in lingiua inglese o tedesca) resa disponibile per questo schema è ampia e comprende un TISAX Handbook dettagliato, un TISAX Simplified Group Assessment e soprattutto una check-list per l’autovalutazione. Tutti i documenti aggiornati sono reperibile al link https://portal.enx.com/en-US/TISAX/downloads/.

Anche l’audit non è di un unico tipo: esiste l’audit di livello 1 (AL 1) che essenzialmente è una autovalutazione dell’organizzazione, quello di livello 2 (AL 2) che consiste in una verifica di quanto indicato dall’azienda nel questionario di valutazione, condotta prevalentemente da remoto, infine l’audit di livello 3 (AL 3) è più completo ed approfondito, dunque più severo per l’organizzazione.

Probabilmente molte organizzazioni a cui è stato richiesto dai loro clienti un assessment TISAX non sanno rispondere alle domande della check-list di autovalutazione, oppure risponderebbero in modo errato senza una consulenza competente in grado di guidarli verso l’audit/assessment TISAX senza rischiare di fare un buco nell’acqua.

La check-list per l’assessment TISAX propone, per ciascun punto di controllo, uno o più obiettivi di controllo ai quali sono associati requisiti obbligatori (must), requisiti auspicabili (should), requisiti aggiuntivi necessari laddove è richiesto un elevato livello di protezione delle informazioni e, tra le altre informazioni, il riferimento al requisito ISO 27001 dell’appendice A (equivalente al controllo ISO 27002) corrispondente.

I controlli sono suddivisi in tre aree: Information security, Prototype protection e Data protection.

I risultati degli obiettivi di controllo sono poi riepilogati nella scheda dei risultati (Result) che produrrà la valutazione complessiva e genererà un grafico Radar complessivo per evidenziare i livelli di maturità per i diversi punti di controllo, oltre a grafici radar per singola area.

Sono infine riportati alcuni esempi, anche di KPI significativi per monitorare l’adeguatezza della gestione della sicurezza delle informazioni in ambito automotive.

La copertura dei controlli ISO 27001 Appendice A – ISO 27002 è solo parziale, ma l’obiettivo è far raggiungere anche ad aziende medio-piccole che operano nel settore automotive un livello di maturità accettabile sulla sicurezza delle informazioni, senza pretendere di ottenere l’ardua ed onerosa certificazione ISO 27001.

Tuttavia, un’azienda del settore manifatturiero che opera in questo settore spesso non ha risorse IT interne adeguate per gestire un progetto di adeguamento al TISAX e l’infrastruttura tecnologica implementata potrebbe non fornire adeguate garanzie dal punto di vista della sicurezza.

Occorre dunque effettuare una sorta di gap analysis per capire qual è lo stato attuale dell’organizzazione rispetto alla sicurezza delle informazioni, per capire quali azioni occorre mettere in campo per poter raggiungere il livello di maturità richiesto e la conseguente Label TISAX. Credo che alcune organizzazioni, però, si attiveranno subito con l’iscrizione al TISAX per avviare il processo, senza sapere cosa li aspetta.

I costi per l’ottenimento di una determinata Label TISAX variano in funzione del numero dei siti e degli scopi, ma sono comunque ripartiti nei seguenti:

• Costo di registrazione al TISAX (a partire da € 405)
• Costi per l’audit da parte di un Audit Provider (dipendono dal livello di audit e sono ricorrenti per rinnovare la Label ogni 3 anni, ma non sono previsti audit di sorveglianza)
• Costi per l’eventuale consulenza finalizzata al raggiungimento del livello di maturità richiesto
• Costi del personale interno per seguire il progetto (personale IT, qualità, direzione, risorse umane, …)
• Speseper adeguamento di hardware e software
• Costi per eventuale assistenza sistemistica esterna.

Chi è realmente il Responsabile della protezione dei dati (RPD) o Data Protection Officer (DPO), figura prevista dal Regolamento UE 679/2016 (GDPR)?

Forse sarebbe meglio rispondere anche ad altre domande:

• Cosa fa il DPO?
• Quali requisiti deve possedere?
• A chi serve il DPO?

Il Garante italiano per la Protezione dei Dati Personali e le Linee-guida del WP243, sviluppate dall’apposito Gruppo di Lavoro Articolo 29 a livello europeo, ci vengono in aiuto, ma non bastano a disperdere il polverone che si sta facendo da ogni parte attorno a questa figura.

Si legge da varie fonti di “Corsi specialistici per DPO”, “Esami per qualifiche da DPO”, “migliaia di posti di lavoro come DPO” e così via. È tutto al vero?

Vediamo anzitutto quali sono i requisiti di un DPO o RPD che dir si voglia.

Il Responsabile della Protezione dei Dati (RPD o DPO), nominato dal titolare del trattamento o dal responsabile del trattamento, dovrà:

1. Possedere un’adeguata conoscenza della normativa e delle prassi di gestione dei dati personali, anche in termini di misure tecniche e organizzative o di misure atte a garantire la sicurezza dei dati. Non sono richieste attestazioni formali o l’iscrizione ad appositi albi professionali, anche se la partecipazione a master e corsi di studio/professionali può rappresentare un utile strumento per valutare il possesso di un livello adeguato di conoscenze.
2. Adempiere alle sue funzioni in piena indipendenza e in assenza di conflitti di interesse. In linea di principio, ciò significa che il RPD non può essere un soggetto che decide sulle finalità o sugli strumenti del trattamento di dati personali.
3. Operare alle dipendenze del titolare o del responsabile oppure sulla base di un contratto di servizio (RPD/DPO esterno).

Il titolare o il responsabile del trattamento dovranno mettere a disposizione del Responsabile della Protezione dei Dati le risorse umane e finanziarie necessarie all’adempimento dei suoi compiti.

Leggendo queste righe si evince che non possono esistere corsi per DPO che qualifichino per questo ruolo, né elenchi o albi. Ovviamente tutti i “corsi per DPO” possono essere più o meno validi per svolgere questa mansione in futuro, ma non forniscono la “patente” per farlo.

Le competenze del DPO (insieme di livello di istruzione, conoscenze, capacità/abilità ed esperienza…) devono svariare fra competenze legali, informatiche ed organizzativo-gestionali. Naturalmente il RPD deve conoscere bene il Regolamento UE 679/2016, ma anche il D.Lgs 196/2003 che costituisce tuttora la normativa sulla privacy italiana da oltre 13 anni ed i vari provvedimenti del Garante italiano su videosorveglianza, Amministratori di Sistema, ecc..

Quali saranno le competenze prevalenti? Fino a che livello un DPO deve sapere di sicurezza informatica?

Sicuramente sono più importanti competenze di base consolidate a 360° negli ambiti legale, informatico e gestionale, piuttosto che essere esperti di una materia e non conoscere nulla delle altre. Infatti il DPO non dovrà configurare un firewall (attività che potrà delegare a tecnici sistemisti), ma dovrà sapere cos’è e conoscere i suoi principi di funzionamento.

Per capire quali competenze precise dovrà possedere il DPO occorre comprendere che il DPO è un ruolo da ricoprire in una determinata organizzazione, dunque sarà importante che il DPO conosca discretamente i processi gestionali dell’organizzazione in cui dovrà operare ed in funzione del tipo di organizzazione dovrà possedere requisiti minimi differenti. Per esempio il DPO di un Ospedale o di una organizzazione della Sanità Privata non dovrà necessariamente avere le stesse competenze del DPO di un Comune, di un Ufficio Giudiziario o di una Società che sviluppa software per la profilazione di utenti. Quindi ad ognuno il suo DPO.

Infine sottolineiamo il fatto che il DPO deve essere indipendente dalle altre funzioni aziendali e dipendere solo dal titolare del trattamento, dunque in molte organizzazioni difficilmente una figura interna possiede questi requisiti.

 

Quindi, quali sono i compiti del DPO?

Il Responsabile della Protezione dei Dati dovrà, in particolare:

• sorvegliare l’osservanza del Regolamento, valutando i rischi di ogni trattamento alla luce della natura, dell’ambito di applicazione, del contesto e delle finalità;
• collaborare con il titolare/responsabile, laddove necessario, nel condurre una valutazione di impatto sulla protezione dei dati (DPIA);
• informare e sensibilizzare il titolare o il responsabile del trattamento, nonché i dipendenti di questi ultimi, riguardo agli obblighi derivanti dal Regolamento e da altre disposizioni in materia di protezione dei dati;
• cooperare con il Garante e fungere da punto di contatto per il Garante su ogni questione connessa al trattamento;
• supportare il titolare o il responsabile in ogni attività connessa al trattamento di dati personali, anche con riguardo alla tenuta di un registro delle attività di trattamento.

Esaminando i suddetti punti emerge un ruolo un po’ da consulente e un po’ da auditor, ma con contorni non ben definiti. In base al tipo di organizzazione il DPO o RPD che dir si voglia dovrà svolgere compiti più o meno estesi, potrà essere supportato da un team di altre persone, interne o esterne all’organizzazione, che potranno essere specialisti in ambito informatico, legale o altro a seconda del settore di appartenenza. Ad esempio in una organizzazione sanitaria il DPO potrebbe essere supportato da esperti nel settore sanitario, ad esempio medici.

Anche un DPO esterno potrebbe assumere l’incarico avvalendosi di un team di collaboratori, anche per far fronte alle numerose richieste da parte degli interessati che potrebbero porre quesiti sulle modalità di trattamento dei propri dati personali.

Inoltre è da sottolineare il fatto che il DPO deve disporre anche di autonomia e risorse sufficienti a svolgere in modo efficace i compiti cui è chiamato ed è il titolare (o responsabile) del trattamento che ha l’onere di garantire ciò.

In definitiva il perimetro dei compiti del DPO andrebbe definito bene di caso in caso in apposito contratto o delega del titolare.

Si osserva che il GDPR impone al titolare o al responsabile del trattamento di pubblicare i dati di contatto del DPO e di comunicare i dati di contatto del DPO alle pertinenti autorità di controllo; dunque è un incarico ufficiale e pubblico, affinché tutti gli interessati al trattamento di dati personali effettuato dall’organizzazione possano contattare il DPO per richiedere informazioni sul trattamento dei dati che li riguardano.

Da ultimo, ma non di minore importanza: i DPO non rispondono personalmente in caso di inosservanza del GDPR, ma tale responsabilità ricade sempre e solo sul titolare o sul responsabile del trattamento.

 

 

Vediamo, infine, in quali casi è previsto il DPO, ovvero quando una organizzazione è obbligata a nominare un DPO.

Dovranno designare obbligatoriamente un RPD:

1. amministrazioni ed enti pubblici, fatta eccezione per le autorità giudiziarie;
2. tutti i soggetti la cui attività principale consiste in trattamenti che, per la loro natura, il loro oggetto o le loro finalità, richiedono il monitoraggio regolare e sistematico degli interessati su larga scala;
3. tutti i soggetti la cui attività principale consiste nel trattamento, su larga scala, di dati sensibili, relativi alla salute o alla vita sessuale, genetici, giudiziari e biometrici.

Anche per i casi in cui il regolamento non impone in modo specifico la designazione di un RPD, è comunque possibile una nomina su base volontaria. Ma questa frase non farà effetto su quelle Società che pensano di nominare un DPO solo se strettamente obbligatorio per legge.

Si precisa che un gruppo di imprese o soggetti pubblici possono nominare un unico RPD.

Dunque un consulente esterno qualificato potrebbe assumere il ruolo di DPO, per così dire, in outsourcing, per diverse organizzazioni.

Gli esempi forniti nella Linea-guida del GdL Articolo 29 su chi effettivamente dovrà nominare un DPO in ambito privato forniscono qualche indicazione, ma non dirimono tutti i dubbi. Soprattutto il concetto di “larga scala” è molto dibattuto: preso atto che un medico di famiglia non tratta dati particolari (sanitari in questo caso) su larga scala, salendo sul gradino superiore di questa scala virtuale, quale soggetto, avente comunque un organico ridotto, tratta dati particolari su larga scala: un poliambulatorio privato, una clinica/ospedale privati, un Amministratore di Condominio, un fornitore di servizi di ristorazione collettiva?

Speriamo che non siano le sentenze a definire meglio la normativa che, qui come in altre parti, lascia ampio spazio all’interpretazione.

Da quanto esposto emerge una similitudine fra la figura del DPO – che deve proteggere i dati personali dell’individuo – e l’RSPP (Responsabile del Servizio Prevenzione e Protezione per la Sicurezza e Salute del Lavoro, secondo il D.Lgs 81/2009 e s.m.i.) – che deve garantire la sicurezza nei luoghi di lavoro -, con un distinguo, però: l’RSPP è responsabile anche legalmente in caso di incidente, mentre il DPO non è responsabile in caso di violazione dei dati personali.

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).

Le nuove regole sulla firma digitale sono entrate in vigore questa settimana. Le novità di legge obbligheranno gli utenti ad aggiornare il software del proprio sistema di firma per garantire un più elevato grado di affidabilità e sicurezza. La deliberazione n.45/2009 del CNIPA e le successive modifiche della determinazione commissariale n.69/2010 hanno infatti definito i nuovi standards tecnici di sicurezza per la firma digitale.Nella maggior parte dei casi, l’aggiornamento software si traduce semplicemente in una operazione eseguibile direttamente online, che consentirà di adeguare la propria smart card alle nuove funzioni di sicurezza definite nelle regole tecniche. In altri casi, ovvero per tutte quelle smart card il cui numero di serie inizia con la sequenza 1202, sarà invece necessario procedere ad una vera e propria sostituzione fisica della scheda. Purtroppo, tali schede non sono in grado di accogliere i formati e gli algoritmi previsti per le nuove specifiche di sicurezza e pertanto devono essere sostituite. In realtà, queste smart card sono quelle di prima emissione, che avrebbero raggiunto presto il limite di validità della carta. In virtù delle scadenze definite dalla normativa i certificatori accreditati dovranno rendere disponibili gli aggiornamenti dei dispositivi entro prossimo 31 dicembre 2010, mentre gli utenti avranno modo di adeguare la propria firma entro il 30 giugno 2011. (Fonte CertineWs)

viaFirma digitale: finalmente al via una nuova e più sicura versione | Information Security.