NIS2: acquisizione, sviluppo e manutenzione dei sistemi informativi e di rete

Con l’avvio della seconda fase della normativa, il Tavolo per l’attuazione della disciplina NIS dell'ACN si è riunito il 10 aprile 2025 per valutare, tra le altre cose, le specifiche fondamentali per l’adempimento degli obblighi previsti dalla nuova normativa NIS. A partire dal 15 aprile, ha comunicato alle aziende il loro eventuale assoggettamento agli obblighi normativi, precisando se rientrano nelle categorie essenziali o importanti. Le imprese, però, non sono rimaste in attesa negli ultimi mesi, ma si sono attivate per soddisfare al meglio i nuovi criteri di Compliance previsti dalle nuove norme in materia di cybersecurity.

In questo, come sappiamo, un apporto fondamentale è stato dato dall’ENISA che ha pubblicato linee guida di approfondimento per ogni misura prevista dalla Direttiva.

Tra queste, merita particolare attenzione la misura all’art. 24, comma 2, lettera e) del decreto legislativo del 4 settembre 2024, n. 138 “Sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete”

Quest’ultima, strategica quanto complessa, si articola in 10 elementi:

• Sicurezza dell'acquisizione di servizi, sistemi o prodotti;

• Ciclo di vita dello sviluppo sicuro;

• Gestione della configurazione;

• Gestione delle modifiche, riparazioni e manutenzione;

• Test di sicurezza;

• Gestione delle patch di sicurezza;

• Sicurezza delle reti;

• Segmentazione della rete;

• Protezione da software malevoli e non autorizzati;

• Gestione e divulgazione delle vulnerabilità.

Sicurezza dell'acquisizione di servizi, sistemi o prodotti

La Direttiva impone un approccio sistematico e sicuro per l'acquisto di servizi e prodotti ICT critici, al fine di garantire la sicurezza delle reti e dei sistemi informatici dell’organizzazione. Ciò si traduce nel fatto che ogni processo legato a tali acquisizioni sia basato su una valutazione preliminare dei rischi, considerando attentamente ogni fase del ciclo di vita dei componenti coinvolti.

La sicurezza informatica deve essere integrata con il processo di acquisto con una documentazione accurata e chiara delle procedure che ne supportano l'implementazione. Questo permette di garantire trasparenza e di avere uno standard aziendale di riferimento per le transazioni di acquisto.

I processi di acquisto diretti o tramite gara devono incorporare requisiti per la sicurezza informatica o documentazioni dettagliate che illustrano i processi basati sugli standard del settore a cui attenersi. L'obiettivo è assicurare che la gestione e l'acquisizione di componenti ICT avvengano in modo responsabile, minimizzando i rischi e mantenendo un alto livello di sicurezza nel lungo periodo.

Nello specifico, un processo di acquisto di servizi, sistemi o prodotti informatici sicuro deve prevedere:

• requisiti di sicurezza da considerare in fase di acquisto;
• requisiti relativi agli aggiornamenti di sicurezza durante l'intero ciclo di vita del componente in acquisto oppure relativi alla sostituzione dopo la fine del periodo di supporto;
• informazioni che descrivono i componenti hardware e software utilizzati;
• informazioni che descrivono le funzioni di cibersicurezza implementate e la configurazione necessaria per il loro funzionamento sicuro;
• la garanzia della conformità ai requisiti di sicurezza identificati in fase di analisi dei rischi;
• metodi per convalidare la conformità ai requisiti di sicurezza dichiarati, nonché la documentazione dei risultati della convalida.

È, inoltre, raccomandato che bandi di gare e contratti di acquisto richiedano ai fornitori:

• soluzioni già testate secondo un framework riconosciuto di sicurezza informatica;
• garanzia di intervento, gratuita e tempestiva, se vengono rilevati problemi di sicurezza durante il periodo di garanzia.

È, infatti, fondamentale garantire che i contratti di supporto coprano l'intero ciclo di vita dei sistemi, includendo anche la gestione dell'obsolescenza e l'alerting continuo.

Anche in questo caso, i soggetti pertinenti devono riesaminare e, se opportuno, aggiornare i processi a intervalli pianificati e qualora si verifichino incidenti significativi.

I processi e le procedure relativi all'acquisizione sicura di servizi, sistemi o prodotti ICT dovrebbero comunque essere rivisti annualmente, riesaminando quali sono stati casi di difficoltà, le evidenze di malfunzionamenti, le situazioni favorevoli, cosa ha funzionato e cosa non ha funzionato. E, in base a questo, andrebbero aggiornati sia il piano dei rischi sia il processo stesso.

Inoltre, è importante allineare i bandi di gara e i contratti alla policy di sicurezza della supply chain dell’organizzazione.

Ciclo di vita dello sviluppo sicuro

Prima di sviluppare un sistema informativo e di rete, inclusi i software, i soggetti interessati devono stabilire e applicare norme per lo sviluppo sicuro di tali sistemi, sia che lo sviluppo avvenga internamente sia che venga esternalizzato. Queste norme devono coprire tutte le fasi dello sviluppo, comprese le specifiche, la progettazione, l'implementazione e i test.

In tutte le fasi del ciclo di vita del software si raccomanda di utilizzare framework standard e riconosciuti nello stabilire le norme, i processi e le procedure.

Nel definire tali norme, bisogna seguire alcune best practice:

• effettuare un'analisi dei requisiti di sicurezza nelle fasi di specifica e progettazione di qualsiasi sviluppo o progetto di acquisizione intrapreso dalle entità interessate o per conto di tali entità;
• applicare i principi per la progettazione di sistemi sicuri e i principi di codifica sicura a qualsiasi attività di sviluppo di sistemi informativi come la promozione di architetture di sicurezza informatica per progettazione e zero-trust;
• stabilire requisiti di sicurezza per quanto riguarda gli ambienti di sviluppo;
• stabilire e implementare processi di test di sicurezza nel ciclo di vita dello sviluppo;
• selezionare, proteggere e gestire in modo appropriato i dati dei test di sicurezza;
• sanificare e rendere anonimi i dati dei test in base alla valutazione del rischio.

Tutte le organizzazioni, dunque, dovrebbero implementare un processo sicuro per il ciclo di vita dello sviluppo software (SDLC), basati su approcci DEVSECOPS. Tuttavia, per le realtà più piccole, è sufficiente adottare pratiche di progettazione sicura e processi di test di sicurezza meno impegnativi, che garantiscano le misure essenziali, come ad esempio mantenere ambienti separati per lo sviluppo, il testing e la produzione.

In ogni caso, particolare attenzione deve essere posta anche alla fase di post-rilascio con verifiche periodiche per identificare nuove vulnerabilità, non presenti ai tempi della realizzazione del prodotto.

In caso di sviluppo esternalizzato di sistemi informativi e di rete, i soggetti pertinenti oltre ad applicare le politiche e le procedure di sicurezza sopra citate devono tener conto anche delle misure espresse nel requisito che tratta la catena di approvvigionamento.

Gestione della configurazione

Le aziende interessate dalla NIS2 devono adottare misure adeguate a istituire, documentare, implementare e monitorare le configurazioni di sicurezza di hardware, software, servizi e reti.

I processi devono essere documentati in conformità con le best practice e gli standard di sicurezza (ITIL, ISO 20000).

Nelle grandi aziende è consigliabile utilizzare appositi tool che gestiscono in automatico le configurazioni, le verifiche e le correzioni.

La gestione della configurazione prevede due attività principali:

1. definire e garantire la sicurezza nelle configurazioni per hardware, software e servizi e le loro reti;
2. definire e attuare processi e strumenti volti a far rispettare le configurazioni sicure, definite per l'hardware, il software, i servizi e le reti, per i sistemi di nuova installazione e per i sistemi in funzione durante il loro ciclo di vita.

I soggetti pertinenti devono riesaminare e, se opportuno, aggiornare le configurazioni a intervalli pianificati o in caso di cambiamenti significativi.

In generale, è consigliabile una revisione mensile delle configurazioni, per garantire che le patch siano state applicate, i sistemi eseguano le versioni più recenti del software, i backup siano eseguiti secondo il piano e non vi siano errori gravi su server, dispositivi o dischi.

Gestione delle modifiche, riparazioni e manutenzione

Le procedure di gestione delle modifiche servono a controllare i cambiamenti ai sistemi informativi e di rete, in linea con le politiche generali di gestione delle modifiche.

Gli organi preposti, all’interno delle imprese, dovrebbero valutare standard riconosciuti per lo sviluppo delle procedure di gestione delle modifiche, tenendo in considerazione elementi come: richieste di modifica, valutazione dei rischi, requisiti per test e approvazioni, procedure per il ripristino e documentazione delle modifiche e delle relative approvazioni, ruoli e responsabilità, strumenti software. In tale contesto, può essere di particolare aiuto la pratica di change enablement dell’ITIL.

Bisogna garantire che le modifiche siano documentate, testate e valutate per il potenziale impatto, basandosi sulla valutazione dei rischi dell’azienda, prima di essere attuate.

Nel caso in cui un’emergenza impedisca di seguire le normali procedure, i soggetti pertinenti devono documentare il risultato della modifica e spiegare perché le procedure non sono state seguite.

Un processo di emergenza dovrebbe includere:

• descrizione della modifica;
• motivazione dell'emergenza;
• approvazione;
• ragioni del ritardo;
• azioni di follow-up;
• modalità di ritorno a uno stato precedente del sistema in caso di fallimento della modifica.

È opportuno identificare casi in cui potrebbe ricorrere una modifica di emergenza al fine di mitigarli e ridurne la probabilità. Inoltre, bisognerebbe garantire che le procedure regolari di controllo delle modifiche, non applicabili in situazioni di emergenza, vengano applicate immediatamente dopo l'intervento di emergenza.

Infine, le procedure di gestione delle modifiche devono essere revisionate almeno una volta all'anno o in caso di cambiamenti significativi.

Test di sicurezza

Il tema della sicurezza è al centro della Direttiva NIS2. La misura all’art. 24, comma 2, lettera e) del decreto legislativo del 4 settembre 2024, n. 138 “Sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete” prevede precise politiche e procedure connesse proprio ai testi di sicurezza.

Per sviluppare una politica di testing efficace, è fondamentale considerare gli standard riconosciuti e stabilire un programma di testing che sia proporzionato alla dimensione, complessità e maturità dell’organizzazione.

In questo contesto, i soggetti interessati devono:

• determinare, in base alla valutazione dei rischi, la necessità, l'ambito, la frequenza e il tipo di test di sicurezza;
• eseguire i test di sicurezza, seguendo una metodologia documentata;
• documentare il tipo, l'ambito, la tempistica e i risultati dei test, inclusa la valutazione della criticità e le azioni di mitigazione per ogni risultato;
• applicare azioni di mitigazione per i risultati critici.

Per garantire la sicurezza e l'affidabilità dei sistemi, è cruciale eseguire test su reti e sistemi informativi in momenti chiave, come l'installazione iniziale, gli aggiornamenti infrastrutturali o applicativi significativi, o dopo interventi di manutenzione. È opportuno adottare una varietà di test di sicurezza, che possono includere valutazioni di vulnerabilità, penetration testing, revisione del codice, simulazioni di attacchi informatici o esercitazioni di risposta a cyberattacchi.

Questi test dovrebbero essere effettuati su base regolare in tutta l’azienda, specialmente in caso di cambiamenti rilevanti o incidenti significativi. È consigliabile realizzare audit interni ed esterni in modo sporadico e conservare prove dettagliate dei test svolti, in una forma comprensibile per un esperto terzo.

Infine, è fondamentale valutare e correggere i risultati emersi, in particolare quelli con impatto critico medio-alto su confidenzialità, integrità, autenticità o disponibilità dei servizi. Tutti i risultati e le azioni correttive devono essere adeguatamente documentati.

I piani di test andrebbero rivisti almeno una volta l’anno e in caso di cambiamenti significativi.

Gestione delle patch di sicurezza

È fondamentale che le imprese interessate dalla Direttiva NIS2 definiscano e applichino procedure coerenti con quelle di gestione delle modifiche, gestione delle vulnerabilità, gestione dei rischi, ecc., per garantire che:

1. le patch di sicurezza siano applicate entro un termine ragionevole dalla loro disponibilità;
2. le patch di sicurezza siano testate prima di essere applicate nei sistemi di produzione;
3. le patch di sicurezza provengano da fonti affidabili e siano verificate per l'integrità;
4. siano adottate misure supplementari e accettati rischi residui quando una patch non è disponibile o non può essere applicata come si vedrà più avanti.

Quando si sviluppano procedure per la gestione delle patch di sicurezza, è fondamentale seguire standard riconosciuti. Le azioni da intraprendere possono variare a seconda del tipo di sistema: ad esempio, è essenziale applicare patch obbligatorie per i sistemi esposti (come dispositivi connessi a Internet, firewall e router), mentre per sistemi isolati o legacy si può optare per una gestione più limitata.

È importante istituire un processo che, insieme all'inventario degli asset, consenta di essere tempestivamente informati sulle nuove patch di sicurezza disponibili, pianificandone l'implementazione in modo adeguato. L'attività di patching dovrebbe essere integrata nella normale manutenzione e nella programmazione delle interruzioni dei servizi. Tuttavia, alcune vulnerabilità critiche potrebbero richiedere interventi immediati.

Inoltre, è essenziale verificare la provenienza delle patch, ad esempio attraverso certificati digitali, firme digitali, registri delle modifiche forniti dal produttore e feedback dalla comunità sulla loro affidabilità. Le patch dovrebbero essere applicate solo dopo essere state approvate o testate in un ambiente isolato, seguendo le procedure di gestione dei cambiamenti.

Quando si implementano patch di sicurezza, è essenziale adottare misure proporzionate alle dimensioni e all'importanza dell'entità, assicurandosi che le patch non introducano ulteriori vulnerabilità o instabilità. Nel caso in cui applicare le patch non sia fattibile, si possono considerare misure compensative come il rafforzamento della sicurezza (hardening), l'uso di sistemi di rilevamento delle intrusioni, la segmentazione della rete, il controllo degli accessi e un monitoraggio costante. È anche previsto che una patch possa non essere applicata se gli svantaggi superano i benefici in termini di cibersicurezza. Le ragioni di tale decisione devono essere debitamente documentate e motivate.

Sicurezza delle reti

Con la NIS2, la protezione della rete assume un ruolo fondamentale che deve essere attuata attraverso una serie di azioni:

• documentare l'architettura della rete in modo chiaro e aggiornato;
• stabilire e applicare controlli per proteggere i domini di rete interni da accessi non autorizzati;
• configurare controlli per prevenire accessi e comunicazioni di rete non necessari;
• stabilire e applicare controlli per l'accesso remoto ai sistemi informativi e di rete, inclusi quelli dei fornitori di servizi;
• non utilizzare i sistemi utilizzati per l'amministrazione e l'implementazione delle policy di sicurezza per altri scopi;
• vietare o disattivare esplicitamente connessioni e servizi non necessari;
• consentire l'accesso ai sistemi informativi e di rete solo tramite dispositivi autorizzati;
• consentire connessioni dei fornitori di servizi solo previa autorizzazione e per un periodo limitato, come durante la manutenzione;
• stabilire comunicazioni tra sistemi distinti solo attraverso canali affidabili, isolati logicamente, crittograficamente o fisicamente, garantendo l'identificazione dei punti finali e la protezione dei dati;
• adottare un piano per la transizione sicura e graduale verso protocolli di comunicazione di ultima generazione, accelerando tale transizione;
• istituire un piano per l'adozione di standard moderni di comunicazione via email, internazionalmente concordati e interoperabili;
• applicare le migliori pratiche per la sicurezza del DNS e l'igiene dell'instradamento del traffico internet.

I soggetti interessati devono riesaminare e aggiornare tali misure a intervalli pianificati e in caso di incidenti significativi o cambiamenti operativi o di rischio.

Sebbene la frequenza della revisione delle misure di sicurezza della rete dipenda dalla valutazione del rischio dell'entità come regola generale, l'entità potrebbe anche:

• monitorare costantemente le reti per individuare minacce in tempo reale;
• eseguire scansioni settimanali per identificare nuove vulnerabilità;
• aggiornare le regole del firewall e altri strumenti su base mensile;
• valutare attentamente lo stato di sicurezza dell'intera rete ogni anno.

Segmentazione della rete

I sistemi devono, poi, essere segmentati in reti o zone, in base ai risultati della valutazione dei rischi. Le imprese devono, inoltre, separare i propri sistemi e reti da quelli appartenenti a terzi. A tale fine i soggetti interessati devono:

• considerare il rapporto funzionale, logico e fisico, inclusa l'ubicazione, tra sistemi e servizi affidabili;
• concedere l'accesso a una rete o zona in base alla valutazione dei requisiti di sicurezza;
• conservare in zone sicure i sistemi critici per il funzionamento o la sicurezza;
• creare una zona smilitarizzata nelle reti di comunicazione, per garantire la sicurezza delle comunicazioni in entrata e in uscita;
• limitare l'accesso e le comunicazioni tra le zone e al loro interno al minimo necessario per il funzionamento o la sicurezza;
• separare la rete di amministrazione dei sistemi informativi e di rete dalla rete operativa;
• separare i canali di amministrazione della rete dal resto del traffico di rete;
• separare i sistemi di produzione dai sistemi utilizzati per sviluppo e test, inclusi i backup.

Conviene, inoltre, limitare il traffico dati tra i vari segmenti di rete al minimo necessario per le operazioni, utilizzando strumenti di controllo del flusso, come i firewall. Le connessioni con reti esterne o sistemi informativi devono avvenire esclusivamente tramite interfacce gestite, composte da dispositivi di protezione perimetrale, configurati secondo l'architettura di sicurezza dell'organizzazione. Questi dispositivi possono includere gateway, router, firewall, sistemi di analisi del codice malevolo a livello di rete, sistemi di virtualizzazione e tunnel crittografati.

I soggetti interessati devono riesaminare e aggiornare la segmentazione della rete a intervalli pianificati, indicativamente ogni due anni, e in caso di incidenti significativi o cambiamenti operativi o di rischio.

Protezione da software malevoli e non autorizzati

Le reti e i sistemi informativi delle organizzazioni devono essere costantemente protetti da software malevoli e non autorizzati. A tal fine, le imprese devono implementare misure per rilevare o prevenire l'uso di tali software e garantire, se opportuno, che i propri sistemi informativi e di rete siano dotati di software di rilevamento e risposta, aggiornati periodicamente in base alla valutazione dei rischi e agli accordi contrattuali con i fornitori.

Per essere compliant, dunque, è necessario utilizzare meccanismi di rilevazione e protezione contro software dannosi e non autorizzati su segmenti di rete, così come su workstation, server e dispositivi mobili collegati alla rete. Questi meccanismi servono a rilevare ed eliminare codice dannoso proveniente da email, allegati, accessi web, supporti rimovibili o sfruttamento di vulnerabilità di sistema. Devono, inoltre, essere configurati per scansioni periodiche regolari e scansioni in tempo reale dei file esterni quando vengono scaricati, aperti o eseguiti.

Qualora venissero rilevati dei file infetti, questi devono essere “disinfettati” e messi in quarantena, e monitorando attività non autorizzate e comportamenti anomali del sistema. Tutti i meccanismi devono essere gestiti centralmente e dotati di protezioni che impediscano agli utenti di aggirarne le funzionalità, e devono integrare sistemi antispam nei principali punti di accesso alla rete.

Le protezioni devono essere aggiornate regolarmente, seguendo le procedure aziendali di gestione delle configurazioni e delle patch, per garantire la copertura delle minacce più recenti.

Gestione e divulgazione delle vulnerabilità

Infine, la misura prevede che le aziende interessate dalla direttiva si adoperino per ottenere informazioni sulle vulnerabilità tecniche nei propri sistemi informativi e di rete, valutare la propria esposizione a tali vulnerabilità e adottare misure adeguate a gestirle. Nello specifico, i soggetti interessati devono:

• monitorare le informazioni sulle vulnerabilità attraverso canali adeguati, come bollettini CSIRT, autorità competenti o informazioni fornite da fornitori di servizi;
• effettuare scansioni delle vulnerabilità, se opportuno, e registrare i risultati a intervalli pianificati;
• affrontare senza indebito ritardo le vulnerabilità critiche per le loro operazioni;
• garantire che la gestione delle vulnerabilità sia compatibile con le procedure di gestione delle modifiche, delle patch di sicurezza, dei rischi e degli incidenti;
• stabilire una procedura per la divulgazione delle vulnerabilità in conformità con la politica nazionale di divulgazione coordinata delle vulnerabilità.

È importante stabilire i ruoli e le responsabilità associati alla gestione della vulnerabilità e identificare un unico punto di contatto per la gestione delle vulnerabilità e stabilire canali di comunicazione dedicati per le questioni legate alla sicurezza delle reti e delle informazioni, includendo fornitori e prestatori di servizi.

Per gestire efficacemente le vulnerabilità di sicurezza, è necessario:

• adottare un framework per valutarne la gravità, come il CVSS (Common Vulnerability Scoring System), l'EPSS (Exploit Prediction Scoring System) o il SANS Vulnerability Assessment Framework;
• affrontare con tempestività le vulnerabilità classificate al livello più alto di rischio, ad esempio quelle definite "critiche" dal CVSS o equivalenti, secondo i criteri stabiliti dal CSIRT nazionale.
• segnalare le vulnerabilità ancora sconosciute al CSIRT designato, seguendo le politiche nazionali di Coordinated Vulnerability Disclosure (CVD), ove applicabili.

Se giustificato dall'impatto potenziale della vulnerabilità, i soggetti interessati devono creare e attuare un piano per mitigarla. In altri casi, devono documentare e motivare perché la vulnerabilità non richiede alcun rimedio.

I soggetti interessati devono, infine, riesaminare e aggiornare, se necessario, i canali utilizzati per monitorare le informazioni sulle vulnerabilità a intervalli pianificati e rivedere le informazioni sui canali di monitoraggio delle vulnerabilità tecniche almeno ogni due anni.

La misura riguardante la “Sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete” evidenzia le raccomandazioni fondamentali per garantire un ciclo di vita dell’impianto informatico dell’azienda in linea con le best practice di cybersecurity e in conformità con la normativa NIS2. I benefici, oltre la conformità normativa, derivanti da queste raccomandazioni sono significativi: maggiore resilienza contro le minacce informatiche, riduzione dei rischi operativi, gestione controllata del cambiamento che insieme alle atre misure della normativa rendono le nostre aziende sempre più “sicure”. L’adozione di queste misure consente alle aziende di operare in un ambiente digitale più robusto e stabile, proteggendo dati e infrastrutture critiche dalle innumerevoli minacce informatiche che quotidianamente assediano i nostri impianti.