NIS 2 – Informazioni, sicurezza e fornitori

La normativa NIS2 introduce e sottolinea l’importanza di condividere le informazioni sulle vulnerabilità, con i Paesi membri. Il processo, seppur descritto in modo molto generale, racchiude al suo interno una serie di complessità che meritano una riflessione.

Cosa dice la NIS2

L’articolo 21 della NIS 2 è intitolato “Misure di gestione dei rischi di cibersicurezza”. Al comma 2, punto d) si legge che le misure di sicurezza delle informazioni sono basate su una approccio multirischio e sono mirate a tutelare i sistemi informatici, di rete e il relativo ambiente fisico e comprendono, tra i vari aspetti anche la:

sicurezza della catena di approvvigionamento, compresi aspetti relativi alla sicurezza riguardanti i rapporti tra ciascun soggetto e i suoi diretti fornitori o fornitori di servizi

L’informazione contenuta nell’articolo 21 è importante e si posiziona all’interno di uno scenario più complesso. Per comprendere tale scenario è bene sapere che la ISO 27001:2022, all’interno dell’Annesso A, riporta un controllo di sicurezza (il 5.21) denominato “Managing information security in the information and communication technology (ICT) supply chain” (Gestione della sicurezza delle informazioni nella catena di approvvigionamento delle tecnologie dell’informazione e della comunicazione (TIC)). Vi è quindi una fortissima correlazione tra la NIS2 e la ISO 27001, che non è solo di natura formale ma soprattutto di natura sostanziale.

Un breve accenno alla gestione del rischio

Prima di descrivere il modo in cui un rischio possa riguardare l’organizzazione e i fornitori, è bene dedicare un momento di approfondimento al modello di mitigazione e gestione del rischio basato sullo standard normativo che prevede due fasi essenziali, quali:

RISK MANAGEMENT = RISK ASSESSMENT + RISK TREATMENT

Nella fase di Risk Assessment il rischio deve essere individuato e messo in scala di priorità insieme a tutti gli altri. Nel Risk Management sarà invece necessario scegliere la strategia migliore per mitigare il rischio e lo standard ISO propone quattro possibili approcci:

• Modifica del rischio: questo implica l’adozione di misure che eliminano la minaccia o riducono la probabilità del suo manifestarsi al di sotto di un livello accettabile.
• Mantenimento del rischio: si mantiene il rischio senza alterarlo ma solo dopo una valutazione del rischio. È evidente che lo si ritiene sufficientemente tollerabile.
• Elusione del rischio: si evita, quando possibile, l’attività o la condizione che dà origine al rischio particolare dovrebbe essere evitata.
• Condivisione del rischio: in questo caso, il rischio viene trasferito ad altre entità o terze parti, come attraverso l’acquisto di assicurazioni o la creazione di partenariati.

Sino ad ora è stato descritto quale strategia adottare al fine di mitigare i rischi derivanti da un incidente informatico: bisogna ora cercare di capire la relazione tra rischio e fornitori.

Rischio e fornitori

Nel rapporto con i fornitori bisogna innanzitutto precisare che tale interazione può interessare uno o più soggetti e che quindi la rischiosità deve essere prevista per tutta la filiera e non solo per un singolo soggetto. La circolazione delle informazioni pone, da sempre, un problema di adeguata trasmissione e detenzione dei dati. Immaginando di dover far transitare dati da un server dell’organizzazione, ad un sistema cloud fornito da una società: quali sono i criteri essenziali per garantire che il dato sia protetto? Scriverli in un elenco potrebbe non essere sufficiente, perchè parte di questi criteri è assoggettato al tipo di informazione che deve transitare: spostare un report sui bulloni è un conto, spostare cartelle cliniche è un altro. Cosa dire poi di elementi come “archivi di posta” o “risultanze di vulnerabilità”?

La grande compenetrazione ricercata tra mondo pubblico e mondo privato, richiede una particolare attenzione affinché i dati condivisi siano ben protetti e adeguatamente trasmessi. Nel mondo sanitario, ad esempio, i dati dovrebbero essere detenuti da servizi con particolari infrastrutture, atte a detenere adeguatamente tali informazioni. Alcuni cloud provider hanno deciso di rispettare quanto richiesto dalla normativa HIPAA/HITECH (per approfondimenti consultare questo articolo) ma è necessario specificare che non esiste una certificazione di conformità HIPAA/HITECH.

In tal senso la NIS2 apre uno scenario interessante: l’uso dei sistemi europei di certificazione della cibersicurezza (Articolo 24), in cui si legge:

Al fine di dimostrare il rispetto di determinate prescrizioni di cui all’articolo 21, gli Stati membri possono imporre ai soggetti essenziali e importanti di utilizzare determinati prodotti TIC¹, servizi TIC e processi TIC, sviluppati dal soggetto essenziale o importante o acquistati da terze parti, che siano certificati nell’ambito dei sistemi europei di certificazione della cibersicurezza adottati a norma dell’articolo 49 del regolamento (UE) 2019/881.

La condizione per garantire un corretto rapporto tra fornitori e organizzazioni, sarebbe quindi anche quella di utilizzare prodotti specifici che soddisfino requisiti di sicurezza ben precisi. Ciò riapre il discorso sulla produzione di dispositivi, applicazioni, soluzioni, che potremmo definire made in EU e che, pertanto, rappresentino una garanzia per gli utilizzatori. Il mercato europeo potrebbe trarre solo giovamento da una condizione di questo tipo che porrebbe l’Europa in una condizione di maggior autonomia rispetto ai paesi che oggi rappresentano i principali produttori. Oggi l’Europa può contare su una serie eterogenea di normative che, nell’insieme, riescono a gestire gran parte delle problematiche

• ISO/IEC 27001: lo standard internazionale per la gestione della sicurezza delle informazioni. Molte organizzazioni, comprese quelle europee, cercano la certificazione ISO/IEC 27001 per dimostrare che hanno implementato un sistema di gestione della sicurezza delle informazioni efficace.
• GDPR (General Data Protection Regulation): la conformità al GDPR è fondamentale per qualsiasi software che tratta dati personali di cittadini dell’Unione Europea. Le organizzazioni devono garantire che i loro software rispettino le disposizioni del GDPR per la protezione dei dati personali.
• eIDAS (Electronic Identification, Authentication and Trust Services): per le applicazioni software che forniscono servizi di identificazione e autenticazione elettronica, il rispetto delle norme eIDAS è importante per garantire l’interoperabilità e la fiducia nei servizi digitali transfrontalieri nell’UE.
• Marcature e certificazioni specifiche del settore: alcuni settori specifici dell’industria del software possono richiedere certificazioni o marcature particolari.

Cybersecurity Certification

È importante cominciare con l’affermare che l’ENISA ha messo in campo un sottodominio dedicato alla certificazione per la cybersecurity (https://certification.enisa.europa.eu/); lo scopo è, per l’appunto, quello di creare un mercato di prodotti affidabili (CABs-Conformity Assessment Bodies). Al momento il sistema di certificazione è in fase di creazione e deve superare determinati step.

I documenti più aggiornati sullo schema di certificazione sono reperibili qui. Ma cerchiamo di comprendere meglio il processo che serve a far nascere uno schema di certificazione:

1. La commissione Europea redige la bozza dell’URWP. L’Union Rolling Work Programme pubblicato dalla Commissione Europea il 7 febbraio 2024 definisce il programma di lavoro dell’ENISA per il quadro di certificazione della sicurezza informatica dell’UE. Indica gli argomenti prioritari e prevede richieste di schemi di certificazione candidati su cui l’Agenzia europea per la cibersicurezza sarebbe invitata a lavorare.
2. La bozza è presa in esame dai seguenti gruppi ECCG (European Cybersecurity Certification Group) e SCCG (Stakeholder Cybersecurity Certification Group). Ciò fornisce una visione completa delle note e dei suggerimenti provenienti dall’esterno. Viene quindi realizzata la versione finale e inviata all’ENISA.
3. L’ENISA, sulla base dell’URWP e quindi degli argomenti e delle richieste, effettua una prima bozza dello schema di certificazione. Poiché le tecnologie sono eterogenee e di complessità molto elevata, l’ENISA potrà avvalersi di un supporto specialistico nominato appositamente AHWG (Ad Hoc Working Group). Quando la bozza dello schema di certificazione si ritiene maturo esso diviene il candidate scheme e l’ENISA provvederà a renderlo di pubblica consultazione. Sul candidate scheme si esprimerà anche lo ECCG (European Cybersecurity Certification Group).
4. Se il candidate scheme è solido, viene reinviato alla Commissione Europea che, a questo punto, procede a redigere prima una bozza di “atto d’implementazione” da cui nascerà lo schema di certificazione definitivo.

Sono tre gli schemi di certificazioni sotto sviluppo:

• EUCC (EU Common Criteria): come si legge direttamente dal sito dell’ENISA “la Commissione Europea ha adottato il regolamento attuativo relativo allo schema comunitario di certificazione della cibersicurezza sui Common Criteria (EUCC). Su base volontaria, il nuovo schema EUCC consente ai fornitori ICT che desiderano mostrare una prova di affidabilità di sottoporsi a un processo di valutazione comunemente inteso nell’UE per certificare prodotti ICT come componenti tecnologici (chip, smartcard), hardware e software. Lo schema si basa sul collaudato quadro di valutazione SOG-IS Common Criteria già utilizzato in 17 Stati membri dell’UE. Propone due livelli di garanzia in base al livello di rischio associato all’uso previsto del prodotto, servizio o processo, in termini di probabilità e impatto di un incidente.” Il SOGIS è il Senior Officials Group Information System Security, di cui l’Italia fa parte con l’OCSI (Organismo di Certificazione della Sicurezza Informatica)
• EU5G: dedicato alla certificazione delle tecnologie mobili in 5G.
• EUCS (EU Cloud Services): dedicato ai servizi cloud

L’ENISA ha messo a disposizione anche un breve video esplicativo.

Conclusioni

La certificazione di prodotti “EU made” è importante, sia per ragioni imprenditoriali che di sicurezza. Questo soprattutto in un periodo in cui i data breach sembrano essere legati tanto alle regole, quanto alle tecnologie adottate. Il processo proposto da ENISA risulta vincente per due ottime ragioni: il primo è che si apre ai portatori d’interesse e non solo ai gruppi di lavoro interni, ma questa è una buona prassi già ampiamente diffusa in Europa. Il secondo aspetto, sicuramente più rilevante, è l’istituzione dell’ADHG (Ad Hoc Working Group) che ha lo scopo di essere composto da specialisti dei vari settori, garantendo così un’efficace risultato finale.

Note

1. Si tenga in considerazione che TIC significa (Tecnologie dell’Informazione e della Comunicazione) ↩︎