Gestione delle vulnerabilità NIS 2 ai sensi dell'articolo 21(2)(e)
La gestione delle vulnerabilità ha due lati in NIS 2. Come trattate le debolezze nei vostri sistemi. E come trattate le debolezze che le persone vi segnalano. L'articolo 21(2)(e) è dove risiede l'obbligo, il CIR (UE) 2024/2690 §6.10 ne specifica i dettagli e il §30(2)(5) BSIG lo recepisce nel diritto tedesco.
La versione breve
La gestione delle vulnerabilità è il punto (e) dell'elenco dell'articolo 21(2). Il CIR intitola la sezione corrispondente 'Trattamento e divulgazione delle vulnerabilità'. Quel titolo è rivelatore. NIS 2 si occupa di due cose contemporaneamente: le debolezze presenti nei sistemi che gestite e le debolezze che soggetti esterni trovano nei vostri prodotti e vogliono segnalarvi.
Il CIR §6.10 stabilisce cinque azioni. Raccogliere informazioni sulle vulnerabilità da CSIRT, autorità, fornitori e prestatori di servizi. Eseguire scansioni delle vulnerabilità a una cadenza documentata. Porre rimedio senza indugio a quelle critiche. Legare il trattamento delle vulnerabilità ai vostri processi di gestione delle modifiche, delle patch, del rischio e degli incidenti. E predisporre una procedura di divulgazione coordinata delle vulnerabilità (CVD) allineata con la politica nazionale di CVD.
La Germania recepisce la stessa regola nel diritto nazionale tramite il §30(2)(5) BSIG. Il quadro nazionale di CVD passa attraverso il programma di divulgazione coordinata CERT-Bund presso il BSI. NIS 2 stessa istituisce inoltre una banca dati europea delle vulnerabilità ai sensi dell'articolo 12, gestita dall'ENISA, in cui i soggetti possono divulgare su base volontaria.
Articolo 21(2)(e) della direttiva NIS 2 (2022/2555)
Sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informatici e di rete, compresi il trattamento e la divulgazione delle vulnerabilità.
Punto (e) dell'elenco delle dieci misure. Notate l'impostazione: il trattamento e la divulgazione delle vulnerabilità rientrano in un obbligo più ampio attorno ad acquisizione, sviluppo e manutenzione. Il CIR lo suddivide in sezioni separate (§6.9 acquisizione, §6.10 vulnerabilità). La metà relativa alla divulgazione è quella che viene sottovalutata.
CIR (UE) 2024/2690, allegato §6.10
I soggetti interessati ottengono informazioni sulle vulnerabilità tecniche dei loro sistemi informativi e di rete, valutano la propria esposizione a tali vulnerabilità e adottano misure appropriate per gestirle.
Diritto UE direttamente vincolante per i settori indicati nell'allegato del CIR (DNS, TLD, cloud, centri dati, MSP, servizi fiduciari e gli altri). Il §6.10.2 elenca cinque azioni concrete. Il §6.10.3 stabilisce che, quando saltate la mitigazione, ne mettete per iscritto il motivo. Il §6.10.4 stabilisce che riesaminate periodicamente i canali che usate per monitorare le informazioni sulle vulnerabilità.
§30(2)(5) BSIG (Germania)
Misure di sicurezza per l'acquisizione, lo sviluppo e la manutenzione di sistemi, componenti e processi delle tecnologie dell'informazione, compresi la gestione e la divulgazione delle vulnerabilità.
La Germania copia il testo UE. Il quadro nazionale di CVD passa attraverso il programma di divulgazione coordinata CERT-Bund presso il BSI, che è ciò a cui rimanda in Germania l'espressione 'allineata con le politiche nazionali di CVD applicabili' del CIR §6.10.2(e).
Far entrare le informazioni
Seguite le informazioni sulle vulnerabilità da CSIRT, autorità, fornitori e prestatori di servizi. Eseguite scansioni delle vulnerabilità a una cadenza appropriata al vostro ambiente. Gli strumenti di scansione (Tenable, Qualys, Nessus, OpenVAS) sono il lato ingegneristico. I flussi informativi (newsletter CERT-Bund, avvisi dei fornitori, NVD) sono il lato della consapevolezza. Servono entrambi.
Correggere quelle critiche, documentare il resto
Le vulnerabilità critiche vengono corrette senza indugio. Il trattamento delle vulnerabilità deve agganciarsi alla vostra gestione delle modifiche, gestione delle patch, gestione del rischio e gestione degli incidenti. Quando decidete di non mitigare, il §6.10.3 stabilisce che create un piano di mitigazione documentato o mettete per iscritto perché non è necessaria alcuna azione. Nessun arretrato silenzioso.
Attuare un processo di divulgazione coordinata
Istituite una procedura per ricevere segnalazioni di vulnerabilità da soggetti esterni e coordinarne la divulgazione, allineata con la politica nazionale di CVD applicabile. Meccanica minima: un canale di contatto pubblicato (casella security@ o un file security.txt), uno SLA di riscontro, una tempistica di rimedio e una pubblicazione coordinata. Il CERT-Bund farà da intermediario se necessario.
Periodico, non reattivo
Il §6.10.2(b) stabilisce che le scansioni vengono eseguite 'periodicamente, se del caso'. Il §6.10.4 stabilisce che riesaminate periodicamente i canali che usate per monitorare le informazioni sulle vulnerabilità. Entrambe le espressioni significano: cadenza scritta. Documentate ogni quanto eseguite le scansioni, documentate ogni quanto riesaminate l'elenco dei vostri flussi informativi e attenetevi a ciò. Una scansione una volta l'anno perché qualcuno se n'è ricordato non è periodica.
La divulgazione coordinata è un obbligo, non un'opzione
Il §6.10.2(e) stabilisce che la procedura deve esistere. Non 'se ricevete segnalazioni'. La procedura esiste affinché, quando un ricercatore trova davvero qualcosa, abbia un canale e voi abbiate un processo. Minimo praticabile: una casella security@vostrodominio.com che qualcuno legge, una finestra di riscontro (comunemente 7 giorni) e una finestra di divulgazione (comunemente 90 giorni). Documentatela, pubblicatela, fate puntare a essa un file security.txt.
BSI / programma CVD CERT-Bund
Il BSI gestisce CERT-Bund, il CSIRT federale, e attua un programma di divulgazione coordinata delle vulnerabilità. I ricercatori possono segnalare tramite CERT-Bund e il BSI si coordinerà con i fornitori interessati. Il §30(2)(5) BSIG rimanda a questo. Se state impostando un processo di CVD per la prima volta, allineare le vostre tempistiche e i canali di contatto al modello CERT-Bund è l'impostazione predefinita sicura.
Banca dati europea delle vulnerabilità (articolo 12 NIS 2)
L'articolo 12 di NIS 2 istituisce una banca dati europea delle vulnerabilità gestita dall'ENISA. I soggetti possono divulgarvi le vulnerabilità su base volontaria. Non è un canale di segnalazione obbligatorio ai sensi dell'articolo 23. È una risorsa di riferimento valida in tutta l'UE che aggrega informazioni sulle vulnerabilità tra gli Stati membri.
CSIRT nazionali come coordinatori CVD
Ogni Stato membro ha il proprio CSIRT nazionale che funge da coordinatore CVD (NCSC-NL nei Paesi Bassi, CERT.at in Austria, CCB in Belgio). L'obbligo è lo stesso in tutta l'UE. Ciò che differisce: a quale CSIRT vi rivolgete e l'esatta meccanica del loro processo di coordinamento.
Applichiamo le patch al Patch Tuesday, è sufficiente.
Non lo è. Il §6.10.2(c) stabilisce che le vulnerabilità critiche vengono corrette senza indugio. Il Patch Tuesday è una cadenza di rilascio del fornitore. Uno zero-day divulgato di giovedì con sfruttamento attivo non aspetta fino al martedì successivo. Vi serve una cadenza di patch per le correzioni di routine e un processo fuori banda per i problemi critici.
Non abbiamo un processo di CVD perché nessuno ci segnala mai vulnerabilità.
Il §6.10.2(e) non dice 'impostate un processo quando iniziano ad arrivare le segnalazioni'. Dice che la procedura deve esistere. Lo scopo è assicurare che, quando un ricercatore trova davvero qualcosa, abbia un canale chiaro e il vostro team sappia cosa fare. Una casella security@ e una politica di una pagina bastano a soddisfare l'obbligo. Non averla è un rilievo.
La scansione delle vulnerabilità è compito del team di sicurezza.
Lo è, finché non leggete il §6.10.2(d): il trattamento delle vulnerabilità deve essere coerente con la gestione delle modifiche, delle patch, del rischio e degli incidenti. E il §6.10.4: riesaminate i canali a livello organizzativo. Questo rende la gestione delle vulnerabilità un processo trasversale ai team che tocca le operazioni IT, lo sviluppo, il rischio e l'organo di gestione, non un'attività di sicurezza isolata.
Il lato ingegneristico è di solito in condizioni ragionevoli. La maggior parte dei team IT del Mittelstand gestisce già uno scanner (Tenable, Qualys, Nessus, OpenVAS) e ha una qualche cadenza di patch, anche se è solo 'Patch Tuesday per i client, trimestrale per i server'. Gli obblighi del CIR §6.10.2(a)+(b)+(c) riguardano per lo più mettere per iscritto ciò che già accade e stringere la tempistica delle correzioni critiche.
Il lato CVD è la metà poco documentata. Minimo realistico: una casella security@vostrodominio.com instradata a due persone, una politica di divulgazione di una pagina (riscontro entro 7 giorni, divulgazione entro 90 giorni, riconoscimento ai ricercatori che lo desiderano) e un file security.txt in /.well-known/security.txt che punta alla casella. Mezza giornata di lavoro. La parte che gli audit segnalano davvero.
Il modulo PRO acquisisce in un unico posto il vostro inventario delle vulnerabilità, il calendario delle scansioni, i compiti di rimedio e le decisioni di accettazione. Ogni rilevamento di scansione viene indirizzato in un compito con un titolare, una scadenza e un'approvazione. Il 'documentare perché non è necessaria alcuna azione' del §6.10.3 è lo stesso percorso di approvazione: giustificazione scritta, approvatore nominato, pista di controllo. Nessun foglio di calcolo separato.
Forniamo anche un modello di politica di CVD (impostazione della casella security@, contenuto del security.txt, SLA di riscontro e divulgazione allineati con CERT-Bund). Inserite il vostro dominio e i vostri contatti e avete coperto l'obbligo del §6.10.2(e). Le segnalazioni in entrata vengono instradate nello stesso flusso di compiti dei rilevamenti di scansione, così la tempistica di risposta viene tracciata allo stesso modo.
- Direttiva (UE) 2022/2555 (NIS 2), articolo 12 e articolo 21(2)(e) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regolamento di esecuzione (UE) 2024/2690 della Commissione (CIR), allegato §6.10 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Legge BSI (BSIG), §30(2)(5) come modificato dalla legge di attuazione di NIS2 e di rafforzamento della cibersicurezza
- Programma di divulgazione coordinata delle vulnerabilità BSI / CERT-Bund — bsi.bund.de
- Banca dati europea delle vulnerabilità dell'ENISA (articolo 12 NIS 2)