NIS2 Articolo 21(2)(e): sviluppo sicuro e gestione delle vulnerabilità per gli MSP
Una libreria di logging che il vostro cliente non ha mai scelto consapevolmente, mai installato di proposito e non saprebbe nominare a memoria pubblica una CVE critica un venerdì pomeriggio. Si annida tre livelli sotto un agente di monitoraggio che avete distribuito per lui diciotto mesi fa. L'orologio che conta non è quello dell'advisory del fornitore: è quello che un auditor fa partire quando chiede quanto in fretta l'avete saputo, quanto in fretta avete agito e dove sta la prova.
È esattamente questo scenario che l'Articolo 21(2)(e) di NIS2 vuole prevenire. È la misura che la maggior parte dei consulenti salta perché suona come un problema da sviluppatori. Non lo è. È un problema di catena di fornitura e manutenzione, e per gli MSP una delle misure più difficili da documentare.
L'Articolo 21(2)(e) copre tutto ciò che costruite, acquistate e mantenete
Le dieci misure di gestione del rischio dell'Articolo 21(2) sono la spina dorsale della conformità NIS2. L'attenzione maggiore va a quelle visibili: MFA, backup, notifica degli incidenti. La misura (e) è più silenziosa e più ampia: «la sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informatici e di rete, compresi la gestione e la divulgazione delle vulnerabilità».
Leggetela con calma. Tre verbi — acquisizione, sviluppo, manutenzione — più un obbligo permanente di gestire e divulgare le vulnerabilità. Si applica sia che scriviate codice, sia che rivendiate una piattaforma o teniate semplicemente aggiornato il software di qualcun altro. Nessuna esenzione per «noi non sviluppiamo nulla». Se mantenete i sistemi di un cliente, la metà manutenzione di questa misura è vostra.
Articolo 21 — 10 Misure di Cybersicurezza NIS2
Articolo 21
10 Misure di Cybersicurezza
Governance & Strategia
1Analisi dei rischi & politiche di sicurezza delle informazioni6Valutazione dell'efficacia delle misure di sicurezzaIncidenti & Continuità
2Gestione degli incidenti & notifica3Continuità operativa & ripristino di emergenzaCatena di Fornitura & Sistemi
4Sicurezza della catena di fornitura5Sicurezza nello sviluppo di sistemi di rete e informativiControlli Tecnici
8Crittografia & cifratura10Autenticazione a più fattori & comunicazioni sicurePersone & Risorse
7Igiene informatica & formazione9Sicurezza HR & controllo degli accessi
Per la mappa completa di come (e) si collega alle altre nove misure, vedete la nostra panoramica di tutte e dieci le misure dell'Articolo 21.
Cosa significa in pratica «acquisizione, sviluppo e manutenzione sicuri»
Scomponete la misura nelle tre cose che chiede davvero.
Acquisizione significa scegliere software e fornitori con la sicurezza come criterio di selezione, non come ripensamento. Ciò comporta una valutazione documentata del fornitore: segue pratiche di sviluppo sicuro, pubblica advisory, si impegna a divulgare le vulnerabilità del suo prodotto? Un «usiamo fornitori affidabili» di una riga non sopravvive a un audit.
Sviluppo significa che tutto ciò che costruite — un portale clienti, uno script di automazione, un'integrazione su misura — attraversa un ciclo di vita sicuro. Standard di codifica sicura, revisione del codice, test di sicurezza prima del rilascio e un processo per le vulnerabilità trovate dopo il go-live. Non vi serve un documento SDLC di 40 pagine. Vi serve un processo ripetibile che potete mostrare.
La manutenzione è dove vive la maggior parte degli MSP. Significa applicare le patch, gestire i cambiamenti e tenere un inventario accurato di cosa è distribuito e dove. Non potete applicare patch a ciò che non vedete, e non potete provare di averlo fatto senza registrazioni.
Costruite, o solo mantenete? I controlli cambiano
La misura si applica a tutti nel perimetro, ma il peso si sposta a seconda di cosa fate. Usate la logica decisionale qui sotto per capire quali controlli comportano il maggior rischio di audit per la vostra operatività.
La NIS2 si Applica alla Tua Organizzazione?
1La tua organizzazione opera in un settore essenziale o importante (energia, trasporti, salute, infrastrutture digitali, ecc.)?
Sì▼No▼2La tua organizzazione ha 50 o più dipendenti oppure un fatturato annuo superiore a 10 milioni di euro?
✗La NIS2 non si applica direttamente alla tua organizzazione.
Sì▼No▼✓La NIS2 si applica alla tua organizzazione come entità essenziale o importante.
3La tua organizzazione è un fornitore di infrastrutture critiche o un prestatore di servizi fiduciari qualificati?
Sì▼!La NIS2 potrebbe applicarsi alla tua organizzazione — consulta un esperto legale per confermare il tuo status.
1La tua organizzazione opera in un settore essenziale o importante (energia, trasporti, salute, infrastrutture digitali, ecc.)?
Sì ↓No →2La tua organizzazione ha 50 o più dipendenti oppure un fatturato annuo superiore a 10 milioni di euro?
Sì ↓No →3La tua organizzazione è un fornitore di infrastrutture critiche o un prestatore di servizi fiduciari qualificati?
Sì ↓No →✗La NIS2 non si applica direttamente alla tua organizzazione.
✓La NIS2 si applica alla tua organizzazione come entità essenziale o importante.
!La NIS2 potrebbe applicarsi alla tua organizzazione — consulta un esperto legale per confermare il tuo status.
Si applicaPossibile applicazioneNon si applica
Se mantenete solo software di terzi, la vostra esposizione sta nell'accuratezza dell'inventario, negli SLA delle patch e nelle registrazioni delle modifiche. Se sviluppate qualcosa rivolto al cliente, aggiungete alla lista codifica sicura, revisione del codice e test pre-rilascio. Se rivendete o combinate piattaforme di altri fornitori, i vostri controlli di acquisizione — verifica dei fornitori e clausole di divulgazione — diventano la prima cosa che un auditor sonda. Mappate i vostri servizi con onestà prima di costruire l'insieme dei controlli.
Gestione delle vulnerabilità: ricezione, triage e SLA delle patch
La gestione delle vulnerabilità è un ciclo, non un progetto. Ha tre parti in movimento.
La ricezione è come le vulnerabilità vi arrivano: advisory dei fornitori, la vostra scansione, penetration test di terzi e un canale con cui esterni possano segnalare una falla in qualcosa che gestite. Se manca quest'ultima casella, vi manca un controllo che la direttiva nomina esplicitamente.
Il triage è come ordinate ciò che arriva. Gravità più esposizione più sfruttabilità, valutate ogni volta allo stesso modo così che due tecnici arrivino alla stessa risposta.
La rimediazione è la patch, legata a un orologio di livello di servizio. NIS2 non prescrive tempistiche di patching, quindi il mercato ha adottato uno standard di fatto che gli acquirenti ora inseriscono nei contratti: critico entro 24–48 ore, alto entro 7 giorni, medio entro 30 giorni, basso entro 90 — con un processo di eccezione documentato per i casi in cui davvero non potete applicare la patch in tempo. Quel processo di eccezione conta quanto lo SLA. Un auditor non cerca un registro perfetto. Ne cerca uno difendibile.
L'insidia per gli MSP: dovete poter produrre queste registrazioni per cliente, al momento dell'audit, su richiesta. Una scansione che vive solo in una dashboard non è una prova. Una traccia datata ed esportabile sì.
Divulgazione coordinata delle vulnerabilità e la EUVD
Gestire le proprie vulnerabilità è metà della misura. L'altra metà è la divulgazione, e NIS2 ha costruito un canale formale per essa.
Ai sensi dell'Articolo 12, ogni Stato membro designa un CSIRT come coordinatore di un programma nazionale di divulgazione coordinata delle vulnerabilità (CVD). Quel CSIRT agisce da intermediario fidato tra chi segnala una falla e il fornitore il cui prodotto la contiene. Contatta le parti coinvolte, sostiene il segnalante e negozia le tempistiche di divulgazione, inclusi i casi spinosi in cui una vulnerabilità colpisce prodotti in più Paesi contemporaneamente.
Ad alimentare tutto questo c'è la European Vulnerability Database (EUVD), gestita dall'ENISA, che opera un registro delle vulnerabilità come autorità di numerazione CVE (CNA) ufficiale da gennaio 2024. Per un MSP la EUVD è una seconda fonte di verità accanto agli advisory dei fornitori, e saperci lavorare fa ormai parte del mestiere. Trattiamo il lato pratico nella nostra guida alla EUVD per gli MSP.
La lezione pratica: vi serve un modo pubblicato con cui qualcuno possa segnalare una vulnerabilità in un prodotto o servizio che gestite, e una decisione su come partecipate al processo CVD nazionale. Entrambi sono auditabili. Nessuno dei due è opzionale se siete nel perimetro.
Quando la falla di un fornitore diventa la responsabilità del vostro cliente
Qui la misura (e) smette di essere astratta. Una vulnerabilità nel prodotto di un fornitore non resta contenuta. Si propaga a cascata — dal fornitore a voi, al vostro cliente, ai clienti di quest'ultimo — e gli obblighi di catena di fornitura di NIS2 (misura (d)) fanno sì che la responsabilità viaggi con essa.
Escalation delle sanzioni NIS2 — Oltre la multa
!Evento scatenante
Non conformità rilevata o incidente verificatosi
Un'autorità di vigilanza identifica una lacuna di conformità o un'organizzazione non soddisfa i requisiti NIS2
Le autorità possono imporre▼Sanzioni non finanziarie1Ordini di conformità con scadenze vincolanti
2Audit di sicurezza obbligatori a vostre spese
3Divulgazione pubblica delle violazioni
4Istruzioni vincolanti su misure di sicurezza specifiche
Scala verso▼Conseguenze operative e personali1Sospensione di certificazioni o licenze operative
2Divieto temporaneo di funzioni dirigenziali per individui
3Denominazione pubblica delle persone fisiche responsabili
Evento scatenanteNon finanziarioOperativo / personale
Se un componente che avete distribuito porta una falla critica senza patch e un cliente viene compromesso attraverso di essa, «il fornitore avrebbe dovuto avvisarci» non è una difesa. La direttiva si aspetta che abbiate valutato quel fornitore, contrattualizzato la divulgazione e disposto di un processo per agire non appena arrivato l'advisory. Per questo acquisizione e gestione delle vulnerabilità sono un'unica misura e non due: la debolezza entra da ciò che avete acquistato e si gestisce con ciò che fate dopo. La nostra panoramica sulla sicurezza della catena di fornitura percorre il lato contrattuale.
La prova che un auditor chiederà davvero
La misura (e) si giudica sulle tracce documentali, non sulle intenzioni. Tenete pronte queste, per cliente ove pertinente:
Un inventario di software e fornitori aggiornato, non un foglio di calcolo dell'anno scorso. Valutazioni dei fornitori che mostrino che la sicurezza è stata un criterio di selezione. Una policy di patching con SLA basati sulla gravità, più i log che provano di averli rispettati — e le registrazioni delle eccezioni dove non è avvenuto. Una gestione dei cambiamenti che leghi ogni modifica a un'approvazione. Un canale di ricezione e divulgazione delle vulnerabilità che esista e sia monitorato. E, se sviluppate qualcosa, note di SDLC sicuro: standard di codifica, evidenze di revisione, risultati dei test pre-rilascio.
Niente di tutto ciò è esotico. Tutto ciò è la differenza tra superare un audit e spiegare, dopo un incidente, perché le registrazioni non esistono. La misura (f) — valutare se i vostri controlli funzionano davvero — poggia direttamente su questa; vedete la nostra guida al ciclo di audit per come le due si collegano.
Cominciate da ciò che potete vedere
La maggior parte degli MSP fa già il 60% di questa misura: applicano patch, tracciano i cambiamenti, scelgono fornitori decenti. Il divario sta quasi sempre nella prova e nel canale di divulgazione, non nel lavoro sottostante. Il modo più rapido per trovare i vostri divari specifici è guardare i vostri controlli di manutenzione e acquisizione attraverso la lente dell'Articolo 21(2)(e) e segnare cosa potreste consegnare a un auditor oggi rispetto a cosa dovreste raccogliere all'ultimo.
Se volete che quel divario venga mappato per voi, eseguite un NIS2 quick scan gratuito: indica, per misura, esattamente dove si colloca la vostra postura di sviluppo sicuro e gestione delle vulnerabilità rispetto alla direttiva.
La misura (e) non è la parte più appariscente di NIS2. È quella che più probabilmente risulta sottile quando un auditor tira il filo, proprio perché sembra il lavoro di qualcun altro. Per un MSP, è il vostro.