NIS2, la sicurezza della supply chain: ecco le regole operative di ENISA

Le linee guida tecniche sulla direttiva NIS2 che ENISA ha realizzato in collaborazione con la Commissione europea e i vari Stati membri, nell’ambito del gruppo di cooperazione NIS, forniscono utili regole operative oltre che sulla corretta gestione degli incidenti, anche su tutto ciò che riguarda la sicurezza della catena di approvvigionamento/fornitura, la cd supply chain.

NIS2, linee guida ENISA: la sicurezza della supply chain

Circa la politica di sicurezza della supply chain, l’ENISA nella guida implementativa in parola si richiama all’art. 21, paragrafo 2, lettera d), della direttiva (UE) 2022/2555 NIS2, suggerendo ai soggetti coinvolti/pertinenti di istituire, attuare e applicare una politica di sicurezza della catena di approvvigionamento che disciplini le relazioni con i fornitori diretti e prestatori di servizi al fine di attenuare i rischi individuati per la sicurezza delle reti e dei sistemi informativi.

I principali contenuti, con qualche esempio

Anzitutto, occorre identificare e comunicare il ruolo dei fornitori intesi in senso ampio.

Tra le buone pratiche è bene tener conto del ruolo o meglio tipologia di fornitore, se diretti, ICT, fornitore di software; di hardware, di servizi gestiti (MSP), di servizi di sicurezza gestiti (MSSP) o utente.

Nell’ambito di questa politica occorre poi stabilire i criteri per la selezione e la stipula di contratti con i fornitori/prestatori di servizi. Tali criteri comprendono, leggiamo nella bozza di linee guida (ufficiosamente tradotte):

1. le pratiche di cibersicurezza dei fornitori e dei prestatori di servizi, comprese le loro procedure di sviluppo sicuro;
2. la capacità dei fornitori e dei prestatori di servizi di soddisfare le specifiche di cibersicurezza stabilite dai soggetti pertinenti;
3. la qualità e la resilienza complessive dei prodotti e dei servizi TIC e le misure di gestione dei rischi di cibersicurezza in essi integrate, compresi i rischi e il livello di classificazione dei prodotti e dei servizi TIC;
4. la capacità dei soggetti pertinenti di diversificare le fonti di approvvigionamento e di limitarne la dipendenza.

Poi nell’elaborare tale policy, secondo ENISA i soggetti coinvolti debbono tenere conto dei risultati delle valutazioni coordinate dei rischi per la sicurezza delle catene di fornitura cd critiche effettuate conformemente all’art. 22, par. 1, della NIS2, se del caso, seguendo le attività del Gruppo di Cooperazione per le Reti e i Sistemi Informativi (NIS), sulla catena di approvvigionamento.

Tra gli esempi e le evidenze, l’ENISA richiama anche gli “obiettivi aziendali del soggetto, gli scenari e le raccomandazioni del gruppo di cooperazione NIS” da doversi integrare nella policy in questione.

Non solo, i soggetti coinvolti sono tenuti a provvedere affinché i loro contratti con i fornitori e i prestatori di servizi specifichino, se del caso mediante accordi sul livello dei servizi (cd SLA), quanto segue:

1. i requisiti di cibersicurezza per i fornitori o i prestatori di servizi, compresi i requisiti relativi alla sicurezza nell’acquisto di servizi o prodotti TIC;
2. i requisiti in materia di consapevolezza, competenze e formazione e, se del caso, certificazioni richieste ai dipendenti dei fornitori o dei prestatori di servizi;
3. requisiti relativi alla verifica del background dei dipendenti dei fornitori e dei prestatori di servizi;
4. l’obbligo per i fornitori e i prestatori di servizi di notificare, senza indebito ritardo, ai soggetti interessati gli incidenti che presentano un rischio per la sicurezza della rete e dei sistemi informativi di tali soggetti;
5. il diritto di revisione contabile o il diritto di ricevere relazioni di revisione;
6. l’obbligo per i fornitori e i prestatori di servizi di gestire le vulnerabilità che presentano un rischio per la sicurezza della rete e dei sistemi informativi dei soggetti interessati;
7. i requisiti relativi al subappalto e, qualora i soggetti pertinenti consentano il subappalto, anche quelli in ordine alla cyber security;
8. la risoluzione del contratto, naturalmente.

Per piccole realtà organizzative che hanno evidentemente un potere contrattuale limitato nei rapporti con grandi fornitori e prestatori di servizi è bene ad esempio ricorrere alla contrattazione collettiva o acquisto di prodotti o servizi; ovvero alla rappresentanza da parte di un’associazione di cui si è associati; alla consulenza legale per la revisione e la negoziazione di un contratto circa clausole specifiche sul livello di servizio, assicurandosi che i fornitori di servizi segnalino le vulnerabilità dei loro sistemi o prodotti o servizi che presentano un rischio per la sicurezza della rete e dei sistemi informativi dell’entità.

Ecco un esempio di estratto testuale

“Appalti che contengono gli elementi di cui al punto 5.1.4 dell’Allegato al Regolamento.

Confronto tra gli appalti selezionati e le relative gare d’appalto al fine di verificare se siano presi in considerazione l’acquisizione sicura di sistemi, prodotti e processi di servizi ICT, e in particolare gli elementi di cui al punto 6.1.2 dell’allegato al regolamento”.

Il richiamo all’analisi dei rischi

L’analisi dei rischi prima di stipulare qualsiasi accordo con fornitori e prestatori di servizi è fondamentale, essendo il risultato delle valutazioni dei fornitori anche di servizi.

I soggetti coinvolti, una volta effettuata tale valutazione, devono comunque riesaminare monitorare, rivalutare tale impianto e, se necessario, agire post modifiche, a intervalli pianificati.

Nel momento in cui si dovessero verificare cambiamenti significativi o incidenti significativi connessi alla fornitura di servizi TIC o impattanti sulla sicurezza dei prodotti TIC da parte dei fornitori e dei prestatori di servizi, ecco che la policy in questione andrebbe rivista.

In ogni caso, una revisione di quest’ultima a prescindere da cambi di scenario sarebbe bene effettuarla almeno una volta all’anno.

Di qui, la necessità di creare e mantenere un processo di monitoraggio dei fornitori e di quelli più specificamente di servizi durante l’intero ciclo di vita.

Piani, programmi di revisione e registri

Ancora, ENISA suggerisce di predisporre e mantenere aggiornato un “elenco degli incidenti di sicurezza correlati o causati dall’interazione con un fornitore o un fornitore di servizi”.

D’altra parte, definire le responsabilità relative alla manutenzione, al funzionamento e alla proprietà dei beni è di primaria importanza, e parimenti assicurarsi che il monitoraggio comprenda la rivalutazione periodica della compliance lo è altrettanto.

Qualche esempio/evidenza come le evidenze/registri “parlanti” sui livelli di servizio costantemente monitorati in conformità con gli accordi sul livello di servizio (SLA) stabiliti; oppure le registrazioni di risposta agli incidenti che confermano se l’entità tenga conto degli incidenti relativi a servizi, sistemi o prodotti TIC da fornitori e prestatori di servizi.

Ma non è tutto. La dimostrazione che i contratti firmati con terzi (ad esempio appaltatori, fornitori) sono in linea con la politica in materia di sicurezza delle reti e dei sistemi informativi è data ad esempio dal controllo delle clausole contrattuali, dai riferimenti ai ruoli e alle responsabilità chiave in materia di sicurezza, nonché dall’obbligo per l’appaltatore di segnalare incidenti, e via a seguire.

Anche la gestione del processo di “dismissione” di alcuni fornitori/prestatori di servizi, con relativa documentazione, non è affatto da trascurare. Anzi, vista anche l’influenza che tale circostanza, pensando ad una eventuale transizione di servizi, dati e diritti di accesso può determinare nel rapporto tra fornitore e prestatore di servizi.

Elenco incidenti di sicurezza correlati o causati da terze parti

Occorre poi considerare i criteri per l’utilizzo della catena di fornitura del software open source (OSS), e in particolare:

1. valutazione del rischio;
2. collaborazione con la comunità OSS, fornendo prove dell’impegno profuso per le revisioni tra pari, rimanendo informati sulle ultime minacce alla sicurezza e migliori pratiche;
3. costanti aggiornamenti, assicurandosi che tutte le librerie open source siano regolarmente aggiornate alle ultime versioni dal fornitore o dal fornitore di servizi;
4. verifica delle licenze, considerando il tipo di licenza (permissiva/BSD, copyleft) e annesse caratteristiche;
5. revisioni del codice, richiedendo al fornitore o al fornitore di servizi di eseguire revisioni regolari del codice e test di sicurezza sulle librerie open source per identificare e risolvere eventuali problemi di sicurezza;
6. “dipendenze” software, richiedendo al fornitore o al fornitore di servizi di fornire informazioni sugli strumenti per gestire le dipendenze (es. Dependabot, Yarn, Gradle, Pip) nonché garantendo che tutte le librerie e le relative dipendenze siano sicure e aggiornate.
7. Zero Trust, verificando e autenticando tutte le richieste di accesso.

I contratti con il fornitore

In relazione al contratto, ENISA richiama all’attenzione che per avere contratti validi e robusti, occorrono contenuti di sostanza raggiungibili grazie a:

1. una descrizione chiara e completa dei prodotti e dei servizi TIC;
2. accurate descrizioni dei livelli di servizio, tempistiche nella risposta ai disservizi ben definite, aggiornamenti precisi quando necessari e opportuni, clausole in materia di protezione dei dati robuste e ben strutturate in termini di compliance, accordi di non divulgazione ovvero obblighi per i fornitori e i prestatori di servizi, precisi obblighi del fornitore o del prestatore di servizi di fornire assistenza all’entità senza costi aggiuntivi o a un costo determinato ex ante, in caso di incidente informatico che presenti un rischio per il prodotto o il servizio TIC oggetto del contratto;
3. il diritto di recesso con relativi congrui periodi (minimi) di preavviso per la risoluzione degli accordi contrattuali;
4. la previsione di audit di seconda, terza parte;
5. da ultimo ma non ultimo disposizioni in materia di proprietà intellettuale.

Per ulteriori dettagli, si rinvia direttamente al documento in parola (punto 5).

L’esperta: sfida critica per la supply chain security

Sui punti appena illustrati, abbiamo chiesto un intervento a Federica Maria Rita Livelli, Business Continuity & Risk Management Consultant, BCI Cyber Resilience Committee Member, CLUSIT Scientific Committee Member, ENIA Comitato Scientifico.

“La direttiva NIS2 introduce, indubbiamente, una sfida critica per la sicurezza della supply chain, poiché la protezione di un’azienda è intrinsecamente legata alla sicurezza dei suoi fornitori e prestatori di servizi. Di fatto, come è ben noto, una catena è forte quanto il suo anello più debole, e una violazione presso un fornitore può mettere a rischio anche tutte le imprese a lui collegate, a livello sia digitale sia fisico.

L’ENISA, con la sua guida per la conformità alla NIS 2, affronta questa problematica, sottolineando come le entità che rientrano nel perimetro della NIS2 debbano sviluppare e applicare una rigorosa politica di sicurezza della supply chain. Questo implica identificare e comunicare il proprio ruolo nella catena e governare le relazioni con fornitori diretti e partner di servizi, in modo da mitigare i rischi per i sistemi di rete e informativi.

Di fatto, la conformità alla direttiva NIS2 richiede alle aziende di coinvolgere i fornitori, incluse le PMI, in un percorso di rafforzamento della sicurezza informatica. Tra i punti deboli più comuni della supply chain figurano accessi non sicuri, malware e attacchi alla logistica, i quali non solo rappresentano rischi di compromissione ma possono anche causare ritardi e tempi di inattività con ricadute operative ed economiche significative.

Sebbene l’adozione delle misure di sicurezza richieste dalla NIS2 possa gravare finanziariamente sui fornitori, soluzioni come le Cyber Trust Labels possono rivelarsi strumenti efficaci per ridurre al minimo i rischi e garantire la conformità ai requisiti legali.

Importante da considerare alcuni fattori che le organizzazioni – soprattutto le PMI – si troveranno ad affrontare nel percorso di compliance alla NIS2 e, precisamente:

1. l’onere finanziario della sicurezza informatica può comportare un aumento dei prezzi o la cancellazione dei fornitori;
2. una sicurezza informatica efficace richiede investimenti in termini di tempo e manodopera, che possono andare a discapito di altre attività aziendali;
3. non tutti i fornitori dispongono delle competenze necessarie, il che può comportare costi aggiuntivi per il reclutamento di personale specializzato;
4. gli aggiornamenti continui dei sistemi e dei processi per soddisfare le scadenze mutevoli rappresentano una sfida costante;
5. i clienti possono introdurre rigidi standard di sicurezza informatica nei contratti, il che può comportare complicazioni legali in caso di violazioni della sicurezza.

Tuttavia, non si tratta necessariamente di un aspetto negativo, dato che le aziende che saranno in grado di soddisfare i requisiti NIS2 possono rafforzare i propri rapporti commerciali e migliorare la propria posizione competitiva innovando e migliorando i processi.

Pertanto, a fronte di quanto sopra, le organizzazioni essenziali e importanti dovranno trovare un equilibrio nell’adozione di strategie che considerino l’impatto dei requisiti di sicurezza sui propri fornitori.

Supporto e flessibilità possono aiutare a superare le sfide e un approccio collaborativo può portare a una maggiore sicurezza e a relazioni commerciali sane. Solo in questo modo riusciremo a superare le sfide della compliance alla NIS2 e contribuire a salvare i nostri ecosistemi “supportando” le imprese che per dimensione e per cultura non hanno ancora intrapreso il cammino della cyber resilience ed evitare di lasciare indietro qualcuno”.

Niente di più vero.