La sicurezza informatica non si ferma ai confini dell’organizzazione

Un incidente che coinvolge un fornitore di servizi informatici, un gestore cloud, un manutentore o un subfornitore può compromettere la continuità operativa dell’intera organizzazione. Per questo motivo, nel quadro NIS2, la sicurezza della catena di approvvigionamento non può essere trattata come un semplice allegato contrattuale o come un’attività da svolgere una sola volta. I chiarimenti pubblicati dall’Agenzia per la Cybersicurezza Nazionale, richiamati nel documento delineano un processo strutturato per valutare e governare i rischi connessi alle forniture. L’indicazione centrale è chiara: il soggetto NIS deve adottare un approccio basato sul rischio, applicando requisiti proporzionati alla rilevanza della singola fornitura. Non è quindi sufficiente inserire le stesse clausole di cybersecurity in tutti i contratti. Occorre comprendere quali fornitori possano incidere sulla sicurezza dei sistemi informativi e di rete, quali rischi introducano e quali controlli siano realmente necessari.

Le quattro fasi della gestione del rischio di fornitura

Viene descritta la gestione della sicurezza della supply chain come un processo articolato in quattro fasi:

1. valutazione del rischio associato alla fornitura;
2. identificazione dei requisiti di sicurezza;
3. applicazione effettiva dei requisiti;
4. verifica nel tempo.

Queste fasi non costituiscono attività isolate. Formano un ciclo che deve essere documentato, aggiornato e integrato nella gestione complessiva della sicurezza dell’organizzazione. 

1. Valutare il rischio della singola fornitura

Il primo passaggio consiste nel comprendere il rischio introdotto da ciascuna fornitura. Non tutti i fornitori presentano la stessa esposizione: un fornitore che accede ai sistemi aziendali o tratta dati critici richiede una valutazione diversa rispetto a chi presta un servizio privo di impatto informatico. Anche la profondità dell’analisi deve essere proporzionata al rischio. Le forniture potenzialmente più rilevanti richiederanno verifiche maggiormente approfondite, mentre per quelle a impatto limitato potrà essere sufficiente una valutazione più semplice, purché motivata e documentata.

2. Individuare i requisiti di sicurezza pertinenti

Una volta valutato il rischio, il soggetto NIS deve identificare quali requisiti richiedere al fornitore. La sequenza è importante: i requisiti non dovrebbero essere scelti in astratto, ma devono discendere dai rischi concretamente associati alla prestazione. Il documento evidenzia infatti che definire prescrizioni senza una preventiva mappatura del rischio può produrre requisiti arbitrari oppure sproporzionati rispetto all’impatto effettivo della fornitura. In funzione del rischio, i requisiti possono riguardare, per esempio:

• protezione degli accessi ai sistemi;
• gestione delle vulnerabilità;
• continuità operativa e ripristino;
• segregazione e protezione dei dati;
• gestione degli incidenti;
• impiego di subfornitori;
• restituzione o cancellazione dei dati al termine del rapporto;
• disponibilità di informazioni ed evidenze utili alle verifiche.

Il contenuto effettivo deve essere calibrato sulla specifica fornitura, evitando sia l’assenza di controlli sia l’applicazione automatica di obblighi non pertinenti.

3. Rendere i requisiti vincolanti

I requisiti identificati devono essere concretamente applicati. Nella maggior parte dei casi, ciò avviene attraverso il contratto, gli accordi sul livello di servizio e gli allegati tecnici o di sicurezza. Tra gli strumenti indicati nel documento rientrano le clausole di sicurezza, gli SLA, gli obblighi di notifica degli incidenti e i diritti di audit. In questa fase, il controllo definito durante la valutazione del rischio diventa un impegno verificabile del fornitore. È opportuno che le clausole chiariscano almeno:

• che cosa deve fare il fornitore;
• entro quali termini;
• quali incidenti o anomalie deve comunicare;
• quali evidenze deve rendere disponibili;
• a quali subfornitori si estendono gli obblighi;
• come vengono gestite le non conformità;
• quali sono le conseguenze in caso di mancato rispetto degli impegni.

Non basta, tuttavia, inserire una clausola generica che obblighi il fornitore a “rispettare la NIS2”. Gli impegni dovrebbero essere specifici, comprensibili, coerenti con il rischio e concretamente controllabili.

4. Verificare l’effettivo rispetto dei requisiti

La conclusione del contratto non chiude il processo ma si richiede una fase di verifica, perché un requisito non controllato rischia di rimanere solo formale. Il soggetto NIS deve quindi prevedere un monitoraggio nel tempo, con modalità proporzionate alla criticità della fornitura. La verifica può comprendere:

• questionari periodici;
• acquisizione di certificazioni o attestazioni;
• esame di report di audit;
• verifiche documentali;
• monitoraggio degli SLA;
• incontri periodici con i fornitori più critici;
• audit diretti, ove giustificati;
• rivalutazioni a seguito di incidenti o modifiche rilevanti.

La sola presenza di una certificazione non dovrebbe essere considerata automaticamente sufficiente. Può rappresentare un’evidenza importante, ma deve essere valutata rispetto all’oggetto, al perimetro e al rischio della specifica fornitura.

I cinque criteri minimi da considerare

Vengono individuati cinque elementi minimi per valutare il rischio della fornitura:

1. Accesso ai sistemi e alle reti: occorre considerare se il fornitore può accedere ai sistemi informativi e di rete del soggetto NIS e con quali privilegi.
2. Accesso a dati e proprietà intellettuale: la valutazione deve tenere conto anche della criticità delle informazioni accessibili.
3. Impatto di una grave interruzione: va stimato che cosa accadrebbe se il servizio non fosse più disponibile.
4. Tempi e costi di ripristino: bisogna valutare quanto sarebbe complesso e costoso ripristinare il servizio o sostituire il fornitore.
5. Ruoli e responsabilità: occorre comprendere quale ruolo svolga il fornitore nel governo o nella gestione dei sistemi informativi e di rete.

Si tratta di un contenuto minimo, non di un elenco esaustivo. Il soggetto NIS può quindi aggiungere altri fattori, come la dipendenza da un unico fornitore, la sostituibilità del servizio, la localizzazione dei dati, l’impiego di subfornitori e la storia degli incidenti.  Questi criteri possono essere tradotti in una matrice di valutazione, attribuendo a ciascun fornitore un livello di rischio. La classificazione dovrebbe poi determinare quali controlli applicare, con quale frequenza verificarli e chi sia responsabile del monitoraggio.

Non tutti i fornitori devono ricevere gli stessi requisiti

Uno dei chiarimenti più rilevanti riguarda il principio di proporzionalità. Secondo quanto riportato nel documento, non è necessario definire requisiti di sicurezza per tutte le forniture e non è richiesto trasferire automaticamente a ogni fornitore tutte le misure applicabili al soggetto NIS. L’approccio corretto consiste nell’applicare:

• i requisiti pertinenti;
• alla fornitura pertinente;
• con un livello di intensità coerente con il rischio.

Questo principio deve essere gestito con attenzione. La proporzionalità non significa libertà di omettere controlli senza motivazione. Se un requisito non viene applicato perché non pertinente, è opportuno conservare la valutazione che ha portato a tale decisione. La tracciabilità consente di dimostrare che l’esclusione deriva da un’analisi ragionata e non da una semplice dimenticanza. 

Contratti misti e raggruppamenti temporanei di imprese

Vengono poi affrontate le forniture che comprendono prestazioni differenti, alcune rilevanti per la sicurezza informatica e altre prive di un impatto significativo. Nei contratti misti, i requisiti devono essere modulati secondo proporzionalità, pertinenza e adeguatezza rispetto alle specifiche prestazioni affidate. Non è quindi necessario applicare indistintamente lo stesso livello di controllo a tutte le componenti del contratto. Lo stesso criterio si applica ai raggruppamenti temporanei di imprese. Le misure devono riguardare i componenti che eseguono, anche solo in parte, prestazioni con impatto sulla sicurezza informatica, tenendo conto dei ruoli e della ripartizione delle attività all’interno del raggruppamento.  In questi casi è particolarmente importante che il contratto identifichi con precisione:

• quale impresa svolge ciascuna attività;
• chi accede ai sistemi o ai dati;
• chi gestisce gli incidenti;
• chi coordina le comunicazioni;
• quali obblighi si applicano ai singoli componenti;
• quale soggetto mette a disposizione le evidenze necessarie alle verifiche.

Anche la subfornitura deve essere conosciuta

La valutazione della supply chain non dovrebbe limitarsi al contraente diretto. Il documento ricorda che, ai fini dell’individuazione dei fornitori rilevanti, può essere necessario considerare anche il soggetto che eroga concretamente il servizio lungo la catena di subfornitura. Per questo motivo, il soggetto NIS dovrebbe conoscere almeno i subfornitori che partecipano alle componenti critiche del servizio. Le clausole contrattuali possono prevedere:

• l’obbligo di comunicare i subfornitori rilevanti;
• la preventiva informazione in caso di sostituzione;
• l’estensione degli obblighi di sicurezza ai subfornitori;
• la responsabilità del fornitore principale per le attività affidate a terzi;
• la collaborazione lungo la catena in caso di incidente.

Che cosa dovrebbero fare ora le organizzazioni

Per tradurre le FAQ in un processo operativo, è consigliabile adottare un piano articolato nei seguenti passaggi:

1. Censire le forniture, identificando servizi, referenti, contratti, sistemi interessati, dati trattati e subfornitori conosciuti.
2. Classificare i fornitori, utilizzando almeno i cinque criteri della FAQ MSB.14.
3. Individuare le forniture rilevanti, comprese quelle non strettamente ICT che possono comunque incidere su sistemi, reti o continuità operativa.
4. Definire requisiti differenziati, associando i controlli al livello di rischio.
5. Verificare i contratti esistenti, individuando clausole mancanti, troppo generiche o non verificabili.
6. Integrare i requisiti nei nuovi acquisti, coinvolgendo sicurezza, IT, acquisti, legale, privacy e responsabili del servizio.
7. Programmare le verifiche, stabilendo modalità, responsabilità e periodicità.
8. Gestire incidenti e cambiamenti, rivalutando il rischio quando cambia il servizio, il subfornitore o l’architettura tecnica.
9. Documentare le decisioni, comprese le ragioni per cui determinati requisiti non vengono applicati.
10. Riferire agli organi responsabili, integrando il rischio fornitori nella governance complessiva della cybersecurity.

Il documento sottolinea inoltre che la gestione della supply chain non dovrebbe rimanere separata dalla gestione degli incidenti e dalle altre misure di sicurezza. Deve inserirsi nei medesimi processi di governance, con ruoli e responsabilità chiaramente definiti.