Sicurezza delle informazioni: come usare la nuova ISO/IEC 27001:2022

A fine ottobre 2022 è stata pubblicata l’ultima versione dello standard internazionale ISO/IEC 27001 con i requisiti per i sistemi di gestione per la sicurezza delle informazioni. In un articolo precedente sono riportate le novità più significative.

Presentiamo ora alcuni esempi per attuare queste novità.

Monitoraggio degli obiettivi

Il monitoraggio degli obiettivi relativi alla sicurezza delle informazioni è un nuovo punto. Va detto che il monitoraggio era già previsto per i processi e i controlli e, implicitamente, anche per gli obiettivi.

Considerando che gli obiettivi di sicurezza delle informazioni possono essere di più tipologie, ecco come possono essere monitorati:

• gli obiettivi relativi ad azioni e progetti (p.e. “cambiare il sistema di backup” o “attivare un nuovo sito di DR”) possono essere monitorati attraverso le analisi periodiche di avanzamento dei progetti e delle attività;
• gli obiettivi relativi a misurazioni (p.e. “ridurre il numero di incidenti”, “mantenere la disponibilità dei sistemi informatici”) vanno monitorati secondo periodicità proprie di ciascuna misurazione, da stabilire in fase di pianificazione;
• gli obiettivi relativi al completamento delle attività pianificate (p.e. “completare gli audit interni”, “svolgere scansioni delle vulnerabilità su tutti i sistemi”) vanno anch’essi monitorati secondo periodicità proprie di ciascuna misurazione, da stabilire in fase di pianificazione; per esempio, nelle piccole organizzazioni, l’esecuzione degli audit interni può essere analizzata annualmente o semestralmente, mentre nelle grandi mensilmente o trimestralmente.

Pianificazione dei cambiamenti

I cambiamenti al sistema di gestione vanno pianificati a seguito di un’analisi delle non conformità, dei rischi o delle opportunità. Per questo il requisito non è da ritenersi significativamente nuovo.

La pianificazione deve seguire le stesse regole adottate per le correzioni, le azioni correttive, le azioni per affrontare i rischi e le opportunità.

Il metodo più semplice consiste in una tabella con i seguenti campi:

• Data apertura;
• Azione;
• Risorse necessarie;
• Responsabile dell’azione;
• Scadenza;
• Verificata da;
• Verifica dell’efficacia.

Può essere utile aggiungere altri campi: numero dell’azione, origine dell’azione (rischio, opportunità, NC, rapporto di audit interno o esterno, ecc.), note di avanzamento, stato (aperto, chiuso, in attesa di verifica dell’efficacia).

Per i progetti più complessi, la tabella deve far riferimento ai progetti stessi.

Deve essere quindi stabilita una periodicità per riesaminare le azioni pianificate.

Lista dei controlli per il SOA

La ISO/IEC 27001:2022 chiarisce che non è necessario usare, per la dichiarazione di applicabilità, i controlli dell’Annex A (vanno solo specificati quelli esclusi, ma non quelli utilizzati). E’ possibile usare altre liste, ma è evidentemente comodo usare proprio l’Annex A, anche perché basato sull’esaustiva ISO/IEC 27002.

Il nuovo requisito permette però di usare in modo più flessibile il SOA.

In alcuni casi, per facilitare l’analisi delle misure adottate, è possibile suddividere i controlli dell’Annex A in sottocontrolli. Per esempio, il controllo 5.14 sul trasferimento delle informazioni, può essere suddiviso nei controlli 5.14.1 relativo alle regole che deve seguire il personale, 5.14.2 su come le regole di trasferimento delle informazioni con clienti e fornitori debbano essere oggetto di accordi tra le parti, 5.14.3 sulla sicurezza dei trasferimenti elettronici (email, instant messaging, social network), 5.14.4 sulla sicurezza dei trasferimenti fisici, 5.14.5 sulle regole in merito alle conversazioni di persona o al telefono e i messaggi vocali.

Nel caso si usino più riferimenti per i controlli (p.e. i controlli del Cybersecurity framework del NIST, le misure di sicurezza richieste da ACN ai fornitori di servizi cloud, eccetera), è possibile raffinare i controlli dell’Annex A per avere una più precisa relazione tra i controlli del SOA e i diversi riferimenti.

Migrazione dei controlli del 2013 a quelli del 2022

La possibilità di raffinare i controlli della ISO/IEC 27001:2022 permette anche di mettere in relazione i nuovi controlli del 2022 con quelli del 2013 e poter così, per la transizione, migrare facilmente.

L’appendice della ISO/IEC 27002:2022 mette in relazione i vecchi e i nuovi controlli, ma alcuni sono in relazione uno a molti. Per facilitare il lavoro di migrazione si potrebbe cercare di identificare, per ogni controllo della ISO/IEC 27001:2013, un unico controllo (o sottocontrollo) della ISO/IEC 27001:2022. Un esempio è quello riportato sul VERA 7.2, disponibile in italiano e in inglese.

Un esempio è il seguente, dove il controllo 5.1 della ISO/IEC 27001:2022 è stato suddiviso in due sottocontrolli per poterli mettere in relazione con i controlli 5.1.1 e 5.1.2 della ISO/IEC 27001:2023

I nuovi controlli

I nuovi controlli sono 11 e sono analizzati nel seguito.

5.7 Threat intelligence

Il controllo richiede un’analisi delle minacce che possono colpire l’organizzazione.

Negli anni passati, per esempio, sono aumentati molto le frodi amministrative: un malintenzionato riusciva a convincere l’amministrazione di un’organizzazione di essere un fornitore e di farsi bonificare dei soldi. Le organizzazioni a conoscenza dell’emergere di questa minaccia hanno avvertito il personale dell’amministrazione e hanno aumentato i controlli quando un fornitore segnala cambiamenti al conto corrente.

Strumenti che permettono di venire a conoscenza di queste minacce sono attualmente pochi e si possono citare: il rapporto annuale del Clusit, i rapporti semestrali dell’NCSC (Svizzera), i provvedimenti del Garante per la protezione dei dati personali e delle altre autorità.

I rapporti del CSIRT Italia, al momento, si limitano a segnalare vulnerabilità dei sistemi. Questo però non è uno strumento di threat intelligence, ma di vulnerability warning. Sono molti gli strumenti di questo tipo, anche automatizzati. Essi sono sicuramente utili e da considerare, ma a rigore non sono strumenti di threat intelligence.

Per tutti i canali di comunicazione va deciso chi ha la responsabilità di monitorarli e a chi deve segnalare le informazioni significative in modo che vengano avviate le opportune azioni.

5.23 Information security for use of cloud services

Vanno riesaminati i contratti con i fornitori di servizi cloud per identificarne le eventuali carenze. È vero che i contratti (o i Terms and conditions) proposti dai grandi fornitori non possono essere modificati, però è necessario che l’organizzazione abbia una copia delle condizioni d’uso (spesso difficili da trovare, anche quando sono sul sito web del fornitore) e sia consapevole di eventuali carenze.

Alcuni aspetti da verificare sono: chi svolge i backup, se è attivato un sito di DR, in quali data center si trovano i sistemi primari, quelli di DR e quelli di backup, i massimi tempi di indisponibilità del servizio, l’adeguatezza della DPA (la “nomina a responsabile del trattamento dei dati personali”), se è possibile cambiare fornitore per lo stesso servizio.

5.30 ICT readiness for business continuity

Questo controllo, peraltro già implicitamente incluso nella precedente versione della norma, richiede che venga pianificata la continuità operativa per i sistemi informatici. Va quindi elaborata una BIA (business impact analysis) e un piano di continuità con riportati i parametri di RTO e RPO della soluzione adottata.

7.4 Physical security monitoring

Questo controllo, peraltro già implicitamente incluso nella precedente versione della norma, riguarda gli strumenti attivi di controllo della sicurezza fisica, ossia telecamere e allarmi.

È anche opportuno verificare chi ha accesso alle telecamere, chi può attivare e disattivare gli allarmi, chi riceve i segnali di allarme e come è previsto che agisca in caso di allarme.

Si dà ovviamente per scontato, tra professionisti, che non sono usati allarmi sonori, visto che non hanno alcuna utilità pratica, tranne disturbare i vicini.

8.9 Configuration management

Questo controllo, colpevolmente assente dalla precedente versione della norma, può essere affrontato documentando le regole di configurazione sicura (ossia di hardening) di server, dispositivi e applicazioni.

Le più note regole di configurazione sicura sono i CIS benchmarks (https://www.cisecurity.org/cis-benchmarks). Sono molto articolati e pertanto un’organizzazione può adottarne una loro sintesi.

Oggi vanno anche considerate le regole di configurazione sicura dei servizi cloud.

Molti soddisfano questo controllo configurando i sistemi con immagini pre-impostate. Vanno però specificati principi seguiti per la loro realizzazione.

8.10 Information deletion

Questo controllo riguarda la cancellazione delle singole informazioni al termine dei tempi di conservazione.

Questo tema è notoriamente di difficile realizzazione perché, in molti sistemi, è difficile:

• identificare le informazioni che sono state memorizzate da un certo tempo;
• cancellare le singole informazioni a causa dei meccanismi di integrità dei database.

Queste difficoltà sono note da moltissimi anni, ma i prodotti non sono ancora, tranne qualche rara eccezione, sviluppati tenendole in conto.

Alcune attività che possono essere approntate sono:

• riorganizzare gli archivi fisici e digitali in modo da poter identificare le informazioni da cancellare;
• sviluppare i software perché mettano a disposizione report con indicato da quanto tempo le informazioni sono trattate (p.e. da quanto tempo un cliente non è più attivo);
• selezionare i software seguendo il criterio sopra enunciato.

È necessario ribadire che non si tratta di una questione di semplice soluzione.

8.11 Data masking

Controllo relativo all’anonimizzazione e alla pseudonimizzazione dei dati.

Vanno identificati i report e i trattamenti di dati personali che potrebbero invece fare uso di dati anonimi e, quindi, identificare la soluzione di anonimizzazione (o pseudonimizzazione) più adeguata. Si tratta di un’analisi da fare caso per caso, solitamente a livello applicativo.

8.12 Data leakage prevention

Questo controllo riguarda l’uso di strumenti con funzionalità di DLP, ossia strumenti che identificano dati critici e lanciano allarmi o bloccano trasferimenti sospetti.

Oggi molti fornitori di firewall, EDR e altri strumenti di sicurezza mettono a disposizione moduli DLP che cercano di

• identificare automaticamente i dati critici, anche con algoritmi di intelligenza artificiale;
• bloccare alcune azioni sui dati critici.

Questi moduli si limitano ad alcune operazioni di base.

Altri strumenti, invece, richiedono una classificazione manuale di ciascun dato per poter identificare e bloccare le azioni ritenute potenzialmente pericolose. Questi strumenti non sono molto efficaci, ma sono molto costosi. Questo ne limita l’utilizzo ad alcune grandi organizzazioni.

È comunque possibile adottare alcune tecniche di DLP, tra cui:

• bloccare la copia di alcuni file o da alcuni servizi (in particolare di file sharing);
• bloccare l’uso di chiavi USB o altri dispositivi;
• bloccare l’uso di alcuni servizi di messaggistica e di social network;
• bloccare l’uso dell’email su client (anche se questo aggiunge molte inefficienze in alcuni processi).

8.16 Monitoring activities

Anche questo controllo era colpevolmente assente dalla precedente edizione della norma (dove era presente un controllo di raccolta dei log, ma non di monitoraggio della sicurezza).

Le attività sui sistemi informatici e sulla rete vanno monitorate e per questo è necessario usare strumenti come SIEM e IDS. Ne esistono versioni di base, solitamente integrate con i firewall o gli EDR, o soluzioni più avanzate (incluse quelle che tracciano, dopo averla identificata con algoritmi di intelligenza artificiale, una baseline e lanciano allarmi in caso di scostamenti), fino a quelle gestite da fornitori specializzati.

Ulteriori monitoraggi da considerare sono quelli non strettamente di sicurezza, ossia quelli relativi all’uso delle risorse e alla loro disponibilità, con relativi allarmi in caso di saturazione o guasto.

Inutile pensare di attivare una procedura di riesame manuale dei log. Questo era pensabile negli anni Ottanta o Novanta con alcuni specifici sistemi. Oggi i log sono talmente numerosi che è necessario usare sistemi automatizzati.

Questo controllo può essere difficile da attuare con i servizi cloud. Per i servizi IaaS e PaaS sono spesso disponibili soluzioni per l’ambiente cloud utilizzato, anche come componente opzionale (e a pagamento) messa a disposizione dal cloud service provider. Per il modello SaaS, la disponibilità della soluzione dipende dal fornitore.

8.23 Web filtering

Controllo in precedenza incluso tra i controlli di rete, ora è stato meglio evidenziato. Si applica con i firewall (o con le loro evoluzioni) e richiede di limitare l’accesso degli utenti ai servizi web. Oggi, solitamente, i firewall permettono l’attivazione di filtri basati sulla classificazione dei siti elaborata dal produttore del firewall stesso e che permettono il blocco di siti pornografici, di gaming, che trattano di armi, gestiti da terroristi, di hacking, noti per diffondere malware, eccetera.

Oggi alcune organizzazioni non distinguono più tra rete interna ed esterna, facendo in modo che il personale acceda solo a Internet, senza controllo, e da lì ai servizi informatici dell’organizzazione, spesso disponibili via web come servizi cloud. In questo caso, è opportuno attivare sui client soluzioni EDR che filtrino i siti web più pericolosi.

8.28 Secure coding

Controllo in precedenza incluso nel controllo relativo alla politica di sviluppo sicuro (oggi più chiaramente denominato “Ciclo di vita dello sviluppo sicuro”).

Esso è applicabile solo agli sviluppatori di software e richiede che vengano stabilite linee guida per la codifica sicura. Le linee guida più note, da recepire, sono quelle OWASP per le applicazioni web. Bisogna però dire che l’ambito è limitato, appunto, solo alle applicazioni web. D’altra parte è altresì vero che le altre applicazioni sono raramente oggetto di attacco, anche perché disponibili a un limitato numero di persone. Ciò non ostante, è sempre opportuno specificare alcune regole di codifica, sia di qualità sia di sicurezza (dichiarare e limitare sempre le variabili, mantenere i metodi privati, eccetera). Per questo vanno ricercate quelle specifiche per i linguaggi usati (OWASP ne mette a disposizione di generiche e non più aggiornate; molti produttori di strumenti di sviluppo, come Microsoft e Oracle, ne mettono a disposizione per i loro ambienti come .Net e Java).

Alcuni usano strumenti di controllo automatico della qualità e sicurezza del codice (strumenti SAST o DAST) e il loro utilizzo è consigliato. Va però detto che questo non sostituisce linee guida che dovrebbero essere note a tutti gli sviluppatori.

Accanto ai documenti si raccomandano attività di formazione in materia.

Bisogna dire che per certi linguaggi e ambienti è difficile trovare materiale o formatori preparati. Le scelte vanno fatte considerando anche i rischi a cui è sottoposta l’organizzazione.

I controlli cambiati significativamente

Si segnalano nel seguito alcuni controlli cambiati significativamente dalla precedente versione.

8.1.1 Endpoint degli utenti

Questo controllo corrisponde al A.6.2.1 “Politica per i dispositivi portatili” della precedente edizione della norma.

Quanto fatto per i dispositivi portatili, giustamente, deve essere esteso anche a quelli fissi e agli altri dispositivi degli utenti: smartphone, tablet, eccetera.

Il metodo maggiormente raccomandato è quello di collegare tutti i dispositivi usati per accedere ai dati dell’organizzazione a un MDM, che ne controlli l’aggiornamento, l’attivazione delle misure di sicurezza (incluso il controllo degli accessi) e le applicazioni installate. Questo strumento ha i suoi pregi, ma anche i suoi limiti, soprattutto se consideriamo che spesso i dati sono accessibili anche da strumenti personali.

6.7 Lavoro a distanza

Il controllo precedente (A.6.2.2 “Telelavoro”) in Italia poteva far intendere che fosse applicabile solo al telelavoro, inteso come quello regolamentato dall’Accordo interconfederale per il recepimento dell’accordo-quadro europeo sul telelavoro concluso il 16 luglio 2002 e pubblicato il 9 giugno 2004.

Questo controllo richiede di fornire regole e strumenti adeguati a tutti quelli che lavorano a distanza e non solo ai telelavoratori.

Per questo vanno fornite regole precise.

Alcuni vorrebbero strumenti per verificarne l’applicazione, ma sappiamo bene che spesso non è possibile, anche perché gli strumenti usati sono spesso quelli personali e perché molte regole (p.e. “non far usare il proprio dispositivo ad altri”) non possono essere tecnicamente monitorate. E’ comunque necessario che siano fornite le regole.