Sviluppo e acquisizione sicuri NIS 2 ai sensi dell'articolo 21(2)(e)
NIS 2 stabilisce che devi mettere in sicurezza i sistemi lungo approvvigionamento, sviluppo e manutenzione. L'articolo 21(2)(e) è l'ombrello. Il §6 del CIR (UE) 2024/2690 lo suddivide in dieci sottosezioni. La Germania lo inserisce nel diritto nazionale attraverso il §30(2)(5) BSIG.
La versione breve
L'articolo 21(2)(e) è l'obbligo ombrello per la sicurezza lungo l'intero ciclo di vita IT. Non solo il codice. Non solo le patch. L'intero percorso: acquistare un sistema, costruirlo, configurarlo, modificarlo, testarlo, applicare le patch, gestirlo, dismetterlo. La stessa regola si applica in tutta l'UE.
Il CIR (UE) 2024/2690 riempie il dettaglio. Il §6 dell'allegato ha dieci sottosezioni (§6.1 - §6.10) che rendono operativo l'obbligo. Questa pagina copre il lato sviluppo e modifiche: approvvigionamento (§6.1), il ciclo di vita di sviluppo sicuro (§6.2), gestione della configurazione (§6.3), gestione delle modifiche (§6.4), test di sicurezza (§6.5) e gestione delle patch (§6.6). Sicurezza di rete, segmentazione, anti-malware e gestione delle vulnerabilità (§6.7 - §6.10) hanno pagine proprie.
La Germania inserisce la stessa regola nel diritto nazionale attraverso il §30(2)(5) BSIG. La formulazione è quasi parola per parola il testo UE. Questa pagina percorre la direttiva, il regolamento UE di attuazione e il recepimento tedesco in quest'ordine.
Articolo 21(2)(e) direttiva NIS 2 (2022/2555)
Sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informatici e di rete, compresa la gestione e la divulgazione delle vulnerabilità.
Questo è il punto (e) nell'elenco delle dieci misure di cibersicurezza che ogni soggetto essenziale e importante deve attuare. È l'unico punto dell'elenco che si estende esplicitamente dall'ordine di acquisto alla fine vita.
CIR (UE) 2024/2690, allegato §6
Misure di sicurezza nell'acquisizione, nello sviluppo e nella manutenzione dei sistemi informatici e di rete (articolo 21(2)(e) della direttiva (UE) 2022/2555).
Poiché si tratta di un regolamento (non di una direttiva), è diritto UE direttamente vincolante. Nessun recepimento nazionale necessario. Si applica ai fornitori DNS, ai registri TLD, ai fornitori cloud, ai data center, ai fornitori di servizi gestiti e agli altri settori elencati nel suo allegato. Il §6 ha dieci sottosezioni numerate che nominano ciascuna un obbligo specifico.
§30(2)(5) BSIG (Germania)
Sicurezza nell'acquisizione, nello sviluppo e nella manutenzione dei sistemi di tecnologia dell'informazione, compresa la gestione e la divulgazione delle vulnerabilità.
La Germania copia il testo UE quasi parola per parola. 'Sistemi di tecnologia dell'informazione' invece di 'sistemi informatici e di rete' è formulazione, non significato. Il BSI indica i moduli IT-Grundschutz CON.8 (sviluppo software) e OPS.1.1.3 (gestione delle patch e delle modifiche) come via pratica.
Inserisci requisiti di sicurezza in ogni acquisto
Prima di acquistare un prodotto o servizio IT, scrivi cosa deve fare in materia di sicurezza. Autenticazione, registrazione dei log, supporto agli aggiornamenti, divulgazione delle vulnerabilità, regione di hosting, dove risiedono i dati. Poi convalidi che il fornitore soddisfi effettivamente i requisiti. Questo spetta al soggetto acquirente, non al fornitore. 'Usiamo SaaS' non trasferisce l'obbligo.
Esegui un ciclo di vita di sviluppo sicuro
I requisiti di sicurezza vengono analizzati durante la specifica e la progettazione. Si applicano i principi di codifica sicura, compresi security by design e architetture zero-trust. Gli ambienti di sviluppo stessi sono messi in sicurezza. I test di sicurezza avvengono prima del rilascio. I dati di test sono trattati con cura, non copiati dalla produzione. L'intero ciclo di vita è documentato, non solo una o due pratiche.
Applica le patch entro un termine appropriato, testa prima
Le patch di sicurezza vengono applicate entro un termine appropriato (il testo del CIR), legato alla gravità della vulnerabilità. Le patch sono testate prima della produzione. Le patch di emergenza sono documentate. 'Quando il team ha tempo' non è un termine. Scegli una cadenza, mettila per iscritto, dimostra di rispettarla.
Sicurezza dall'approvvigionamento alla dismissione
Il §6 non riguarda lo sviluppo in senso stretto. Copre l'intero ciclo di vita: come scegli cosa acquistare, come costruisci, come configuri, come testi, come applichi le patch, come modifichi, come dismetti. Un Mittelstand che acquista il 95 per cento del suo software possiede comunque il §6.1 (requisiti di approvvigionamento) e il §6.6 (gestione delle patch). Non puoi rinunciare al ciclo di vita solo perché non scrivi codice.
Disciplina delle modifiche: nessuna modifica di produzione non tracciata
Il §6.4 è netto: le modifiche alla produzione sono gestite, documentate e riesaminate. Anche le modifiche di emergenza vengono documentate, semplicemente a posteriori invece che prima. Una modifica senza ticket, senza approvatore e senza piano di rollback non soddisfa il requisito, anche se funziona. Gli auditor confrontano il registro delle modifiche con il sistema di ticket. Se non riescono a ricostruire chi ha modificato cosa e quando, il controllo non è in atto.
BSI / IT-Grundschutz CON.8 + OPS.1.1.3
Il BSI mappa il §30(2)(5) BSIG su due moduli Grundschutz. CON.8 'Software-Entwicklung' copre il lato SDLC: requisiti, codifica sicura, test, rilascio. OPS.1.1.3 'Patch- und Änderungsmanagement' copre il lato modifiche e patch. Se segui CON.8 e OPS.1.1.3, sei dentro ciò che chiede il §30 BSIG.
Orientamenti tecnici di attuazione dell'ENISA
L'ENISA, l'agenzia dell'UE per la cibersicurezza, pubblica un orientamento tecnico di attuazione (TIG) che prende il testo astratto del §6 del CIR e ti mostra cosa fare in pratica. Mappa ogni sottosezione sui controlli ISO/IEC 27001:2022 (A.8.25 - A.8.32 sullo sviluppo sicuro, A.5.20 - A.5.23 sulle relazioni con i fornitori), così le certificazioni esistenti ti danno un vantaggio iniziale.
Leggi di recepimento nazionali
Ogni Stato membro ha la propria legge di recepimento (Paesi Bassi: Cyberbeveiligingswet, Austria: NISG, Belgio: NIS2-Wet). Gli obblighi ai sensi dell'articolo 21(2)(e) sono gli stessi perché la direttiva stabilisce un unico standard a livello UE. Ciò che differisce: quale quadro nazionale il regolatore indica come via pratica.
Usiamo SaaS, quindi lo sviluppo sicuro è compito del fornitore.
Vero a metà. Il fornitore possiede il codice. Tu possiedi comunque il §6.1: requisiti di sicurezza documentati per ogni prodotto o servizio IT che acquisti, più la convalida che il fornitore li soddisfi. Autenticazione, registrazione dei log, supporto agli aggiornamenti, ubicazione dei dati, notifica delle violazioni. Se il tuo fascicolo di approvvigionamento è vuoto, l'obbligo non è soddisfatto, anche se il fornitore è eccellente.
Facciamo revisioni del codice, quindi la parte SDLC è coperta.
La revisione del codice è una pratica. Il §6.2 vuole l'intero ciclo di vita documentato: requisiti di sicurezza durante la specifica, principi di codifica sicura (compresi security by design e zero-trust), ambienti di sviluppo messi in sicurezza, procedure di test di sicurezza prima del rilascio, trattamento attento dei dati di test. Una singola pratica sopra un processo non documentato non soddisfa la sezione.
Applichiamo le patch quando il team ha tempo.
Il §6.6 richiede un termine appropriato legato alla gravità, più test prima della produzione e documentazione per le patch di emergenza. 'Quando c'è tempo' non è un termine. Scegli una cadenza (ad es. critiche entro 72 ore, alte entro 14 giorni), mettila per iscritto, dimostra di rispettarla nel registro delle modifiche. Un auditor ricostruirà la tua cronologia delle patch dal sistema di ticket.
La maggior parte dell'IT del Mittelstand tedesco si presenta così: 90 per cento software di fornitori (ERP, paghe, posta, condivisione file, CRM), un po' di codice di integrazione, occasionali script interni. Il grande impegno §6 per quel profilo non è l'SDLC. È il §6.1 approvvigionamento e il §6.6 gestione delle patch.
Scrivi il modello di requisiti di sicurezza una volta. Autenticazione, registrazione dei log, divulgazione delle vulnerabilità, supporto agli aggiornamenti, regione di hosting, esportazione dei dati, notifica delle violazioni. Applicalo a ogni nuovo approvvigionamento e a ogni rinnovo. Abbinalo a una cadenza di patch scritta (critiche / alte / medie con un termine ciascuna) e a un registro delle modifiche che tutti usano. Questo copre il grosso del §6 per un tipico Mittelstand senza assumere uno specialista di sicurezza del software.
Abbiamo integrato i requisiti di approvvigionamento §6.1, la documentazione SDLC §6.2, il registro delle modifiche §6.4 e la cadenza di patch §6.6 nel modulo PRO della piattaforma. Compili il modello di approvvigionamento una volta e lo riutilizzi. Ogni nuovo prodotto o servizio IT passa attraverso la stessa checklist di sicurezza con un'approvazione.
Il registro delle modifiche e la cadenza di patch funzionano sulla stessa traccia di audit del resto della piattaforma: ticket, approvatore, piano di rollback, file di prova. Le modifiche di emergenza ottengono il modulo a posteriori. Non mantieni un registro di conformità separato. Quando un auditor chiede come hai applicato la patch a una CVE, la risposta è una query, non tre fogli di calcolo.
- Direttiva (UE) 2022/2555 (NIS 2), Articolo 21(2)(e) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regolamento di esecuzione (UE) 2024/2690 della Commissione (CIR), allegato §6 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Legge sul BSI (BSIG), §30(2)(5) come modificato dalla legge di attuazione di NIS2 e di rafforzamento della cibersicurezza
- Moduli IT-Grundschutz del BSI CON.8 'Software-Entwicklung' e OPS.1.1.3 'Patch- und Änderungsmanagement'
- Orientamenti tecnici di attuazione dell'ENISA per il CIR (UE) 2024/2690 (al maggio 2026)