NIS2 e ISO 27001: riutilizzare i controlli, esaminare le lacune

Un programma ISO 27001 può offrire una solida struttura operativa per la NIS2: valutazione del rischio, responsabili, controlli, evidenze e miglioramento. Il passo successivo è una valutazione, requisito per requisito, di ciò che quella struttura copre effettivamente.

Per un CTO la domanda utile non è se i framework si sovrappongano. È se un controllo implementato protegga il servizio pertinente, soddisfi l’obbligo applicabile e produca evidenze a supporto di tale conclusione. Riutilizzate l’implementazione quando queste condizioni sono soddisfatte; preservate le differenze giuridiche e operative quando non lo sono.

Capire che cosa stabilisce ciascun framework

La ISO/IEC 27001 specifica i requisiti di un sistema di gestione della sicurezza delle informazioni, o SGSI, con un perimetro definito. I punti da 4 a 10 ne trattano la struttura di gestione, compresi il trattamento del rischio, la valutazione delle prestazioni e il miglioramento. L’Annex A contiene 93 controlli di riferimento suddivisi nelle categorie organizzativi, relativi alle persone, fisici e tecnologici. L’applicabilità dei controlli si basa sul rischio e non impone di implementare ogni controllo in modo identico. La ISO 27002 fornisce linee guida per l’implementazione.

La NIS2 è una direttiva UE attuata tramite la legislazione nazionale. L’applicabilità dipende da settore, dimensioni, servizio e specifiche regole di inclusione. Gli allegati I e II individuano i settori pertinenti, ma il settore da solo non determina se un’organizzazione sia un soggetto essenziale o importante. Alcuni soggetti rientrano nell’ambito di applicazione indipendentemente dalle dimensioni.

Le differenze pratiche sono:

La certificazione è effettuata da organismi di certificazione indipendenti, non dall’ISO. Non stabilisce la conformità alla NIS2, e la NIS2 in generale non richiede la certificazione ISO 27001. L’applicazione della NIS2 può comprendere misure di vigilanza e sanzioni; la certificazione ISO ha una diversa finalità di assurance.

Partire dal confronto dei confini

Confrontate il perimetro certificato del SGSI con le entità giuridiche e i servizi soggetti alla NIS2. Un certificato che copre un team di sviluppo può lasciare fuori dal proprio confine le operations di produzione, un’altra controllata o sedi aggiuntive.

Create un confronto dei perimetri che registri:

• Entità giuridiche, paesi e servizi interessati, con la base dell’inclusione.
• Sistemi, reti, sedi e fornitori di supporto pertinenti.
• Il perimetro del SGSI, il perimetro del certificato e le esclusioni.
• Requisiti nazionali, norme settoriali e autorità competenti applicabili, compresi gli eventuali obblighi di registrazione, le informazioni richieste sul soggetto, i canali di invio e gli obblighi di aggiornamento.
• Chi ha approvato la valutazione di applicabilità e quando deve essere riesaminata.

Distinguete una lacuna di perimetro da una lacuna di controllo. Un ambiente di produzione esterno al SGSI può già disporre di buoni controlli di accesso, ma quei controlli richiedono comunque responsabili, valutazione ed evidenze all’interno del filone di lavoro NIS2.

Verificate la legislazione settoriale prima di duplicare gli obblighi. L’articolo 4 disciplina il rapporto con gli atti giuridici settoriali dell’Unione. Per le entità finanziarie, il rapporto con il DORA richiede un’analisi specifica per ruolo. Per le attività in Germania, consultate le informazioni del BSI sulla NIS2 invece di presumere che gli obblighi KRITIS esistenti e quelli NIS2 siano identici.

Mappare i controlli implementati, non le etichette simili

L’articolo 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate. I suoi dieci ambiti minimi di misure offrono un punto di partenza per la mappatura, ma una formulazione simile è un indizio utile, non una prova di equivalenza.

Usate quanto segue come spunti per la revisione, non come dichiarazioni automatiche di copertura:

La Dichiarazione di applicabilità registra i controlli necessari e la motivazione della loro inclusione o esclusione. Non è intercambiabile con il piano di trattamento del rischio, con le risultanze degli audit interni o con i verbali del riesame della direzione. Usate insieme questi artefatti per spiegare sia la progettazione sia il funzionamento.

Una policy stabilisce le aspettative. Un’esportazione della configurazione può mostrare l’implementazione. Risultati delle revisioni degli accessi, ticket di remediation e registrazioni dei test possono mostrare il funzionamento. Riutilizzate le evidenze solo quando sistema, periodo e obiettivo della valutazione corrispondono.

Evitate percentuali di sovrapposizione fisse. La copertura dipende dall’implementazione e dal perimetro giuridico; un numero universale non può stabilire il livello di preparazione.

Costruire un percorso di notifica degli incidenti che funzioni sotto pressione

Un piano di risposta allineato alla ISO può supportare rilevamento, contenimento, indagine e ripristino senza definire la notifica regolamentare. L’articolo 23 della NIS2 aggiunge obblighi di notifica per gli incidenti significativi.

Le fasi di notifica previste dalla direttiva comprendono generalmente:

• Un preallarme senza indebito ritardo ed entro 24 ore da quando si è venuti a conoscenza dell’incidente significativo.
• Una notifica dell’incidente senza indebito ritardo ed entro 72 ore, che aggiorna il preallarme e fornisce una valutazione iniziale.
• Una relazione finale, di norma entro un mese dalla trasmissione della notifica dell’incidente. In caso di incidente ancora in corso, a quel punto è richiesta una relazione sui progressi, con la relazione finale da presentare entro un mese dalla gestione dell’incidente.

Va inoltre fornita una relazione intermedia se richiesta dal CSIRT o dall’autorità competente.

Verificate le norme nazionali e settoriali applicabili: la direttiva prevede una tempistica di notifica diversa per i prestatori di servizi fiduciari. Non usate una soglia generica di interruzione come sostituto dei criteri di significatività applicabili.

Come raccomandazione pratica di implementazione, create un runbook di notifica che indichi il responsabile della valutazione, il percorso di escalation, la persona autorizzata all’invio, il personale di riserva, il canale verso l’autorità e le informazioni necessarie in ciascuna fase. Registrate in modo distinto le marcature temporali di rilevamento, conoscenza, valutazione della significatività e invio.

Esercitate il processo con informazioni incomplete. Il team deve essere in grado di inviare la prima comunicazione richiesta senza attendere la conclusione di un’indagine forense. Conservate le versioni inviate, le ricevute, i fatti a supporto e le decisioni sul superamento o meno della soglia da parte dell’incidente.

Quando si applica anche un’altra disciplina di notifica, coordinate l’indagine ma valutate separatamente ciascun obbligo di notifica. Un record dell’incidente condiviso non rende identici destinatari, presupposti o scadenze.

Rendere dimostrabili governance e resilienza

L’articolo 20 impone agli organi di gestione di approvare le misure di gestione dei rischi di cybersicurezza e di sovrintenderne l’attuazione. Tratta inoltre la formazione dei membri degli organi di gestione. Un riesame della direzione esistente è un’evidenza utile, ma verificate se registra esplicitamente le approvazioni, la supervisione, le decisioni e le azioni conseguenti pertinenti.

Fornite al management una visione pronta per le decisioni: servizi interessati, rischi rilevanti, opzioni di trattamento, eccezioni aperte e risultati sull’efficacia. Verbali di riunione che si limitano a dire «discusso di sicurezza» forniscono poche evidenze di una supervisione effettiva. Assegnate a ogni azione approvata un responsabile e una data di revisione.

La continuità richiede un trattamento altrettanto concreto. L’articolo 21 comprende backup, disaster recovery e gestione delle crisi; non impone un requisito universale di certificazione ISO 22301. Stabilite il livello di approfondimento necessario in base al servizio, ai rischi e alle regole applicabili.

Testate il ripristino dei dati e del servizio, non solo il completamento dei job di backup. Includete dipendenze come servizi di identità, DNS, supporto dei fornitori, credenziali privilegiate e comunicazioni quando l’ambiente ordinario non è disponibile. Registrate i risultati di ripristino ottenuti e gli ostacoli irrisolti rispetto agli obiettivi concordati.

Mantenere un registro delle differenze visibile

Per ogni requisito registrate fonte e versione, controlli mappati, perimetro, riferimenti alle evidenze, revisore e motivazione del riutilizzo. Distinguete tra copertura supportata, copertura parziale, implementazione mancante, evidenza mancante e una decisione motivata di non applicabilità. L’assenza di un documento non significa sempre assenza di un controllo, ma richiede comunque un’indagine.

Ogni lacuna richiede un responsabile, la modifica necessaria, le evidenze attese, una scadenza e un revisore per la chiusura. Date priorità alle carenze che minacciano i servizi o impediscono notifiche urgenti, invece di trattare ogni attività documentale come ugualmente urgente.

Errori comuni sono mappare solo l’Annex A trascurando i requisiti di governance, accettare il certificato di un fornitore senza verificarne il perimetro, trattare le evidenze dell’anno precedente come attuali e chiudere un’attività quando una policy è pubblicata ma il processo non è ancora stato testato. Registrazione o certificazione non devono mai essere considerate prova dell’attuazione operativa.

Esempio pratico: estendere un SGSI esistente

Ipotesi illustrative: un fornitore di servizi gestiti dispone di un SGSI certificato ISO 27001 che copre il suo team operativo principale. La valutazione di applicabilità conclude che un servizio erogato tramite un’ulteriore entità giuridica è soggetto alla NIS2. Tale entità utilizza la stessa piattaforma di identità e lo stesso team di gestione degli incidenti, ma modalità di ripristino separate.

Il team confronta innanzitutto i confini dei servizi. Le configurazioni di autenticazione esistenti possono supportare entrambi i perimetri, ma il revisore verifica se sono inclusi gli amministratori, gli account di emergenza e gli account di servizio dell’entità aggiuntiva. Un’esportazione della revisione degli accessi che copre solo il team originario non può dimostrare una copertura completa.

Successivamente, il responsabile della gestione degli incidenti mantiene la procedura di risposta consolidata e aggiunge una valutazione degli incidenti significativi e un percorso di notifica all’autorità. Un’esercitazione tabletop simula un’interruzione di un fornitore con impatto incerto sui clienti. I partecipanti registrano quando sono venuti a conoscenza dei fatti rilevanti, chi ha deciso sulla significatività e come verrebbe inviato un preallarme.

Infine, il responsabile dell’infrastruttura conduce un’esercitazione di ripristino per il servizio dell’entità aggiuntiva. Il test rivela che le credenziali di ripristino dipendono dalla piattaforma di identità non disponibile. Il registro delle lacune assegna un’azione correttiva e richiede un nuovo test superato prima della chiusura.

I deliverable risultanti sono un confronto dei perimetri, mappature revisionate, evidenze estese della revisione degli accessi, registrazioni delle esercitazioni di notifica, risultati del ripristino e l’approvazione da parte del management delle azioni di trattamento in sospeso. I controlli condivisi restano condivisi; le evidenze e le decisioni specifiche dell’entità restano visibili.

Trasformare la valutazione in lavoro mantenuto nel tempo

Il modello di Secani, che collega requisiti ed evidenze, offre ai team una struttura per preservare il lavoro condiviso e le decisioni specifiche di ciascun framework. Modellate i servizi e le dipendenze, collegate le evidenze esistenti ai controlli pertinenti e trasformate le coperture mancanti in attività con un responsabile. Mantenete esplicita l’approvazione umana per mappature e conclusioni sulle evidenze, compresi i suggerimenti supportati dall’IA. La nostra guida alla mappatura tracciabile tra framework spiega come conservare la motivazione alla base del riutilizzo.

Iniziate da un servizio regolamentato. Portate il suo perimetro, il trattamento del rischio, la Dichiarazione di applicabilità, il runbook per gli incidenti e le evidenze dei test recenti in una revisione congiunta tra tecnica e compliance. Producete un registro delle differenze revisionato, poi usate i normali cicli di riesame del SGSI per mantenerlo aggiornato al cambiare di servizi, fornitori e requisiti.