NIS2 e sicurezza misurabile: definizione di un incidente “significativo” secondo la misura DE.CM-01

In questo articolo

La nuova direttiva NIS2 e il D.lgs. 138/2024 che la recepisce puntano a una sicurezza basata sulla misurabilità delle prestazioni. La misura DE.CM-01 del Framework Nazionale FNCDP v2.1 introduce un tema che tratta non tanto “l’accorgersi che qualcosa è successo” ma la misurazione di deviazioni rispetto a valori di normalità predefiniti. Prima è necessario stabilire che cosa sia normale per i servizi critici, ovvero i livelli di servizio (SL) attesi, e poi rilevare anomalie significative. Un principio esplicitato nelle linee guida ACN è che per considerare un evento come incidente significativo non è sufficiente un semplice allarme tecnico ma deve emergere la violazione di almeno uno dei criteri oggettivi stabiliti.

In particolare, il criterio IS-3 stabilisce che un incidente è grave quando “si ha evidenza della violazione dei livelli di servizio attesi” definiti in DE.CM-01.

La misura DE.CM-01, collocata nella funzione Detect del FNCDP, indica di fatto il monitoraggio continuo della rete per individuare eventi potenzialmente avversi.

Se in termini operativi, vengono richiesti strumenti di rilevamento (IDS, SIEM, analisi del traffico) e processi dedicati, la vera novità sta nel suo significato a livello organizzativo, dove il DE.CM-01 impone di definire in anticipo cosa osservare e quali deviazioni segnalare.
In altre parole, il “sensore” non è solo una questione tecnica, ma si basa sui parametri di servizio concordati a priori. Per fare un esempio, per un servizio online critico si stabiliscono un obiettivo di disponibilità (ad es. 99,9% uptime) e tempi di risposta massimi. Se il monitoraggio rileva performance al di sotto di questi livelli, scatta l’allarme: l’anomalia viene qualificata come potenzialmente significativa solo perché ha superato le soglie di tolleranza definite.

Le linee guida ACN sottolineano chiaramente quanto non basti il semplice alert ma sia necessario dimostrare di aver previsto in anticipo quale deviazione supera la normalità.

Per tradurre in concreto questo concetto, è fondamentale collegare i livelli di servizio (SL) alle analisi di impatto sul business (BIA) e agli accordi contrattuali (SLA). La Business Impact Analysis individua processi e servizi critici e ne quantifica l’impatto (economico, reputazionale, di continuità) in caso di interruzione.

Dai risultati della BIA si ricavano indicatori chiave: recovery time objective (RTO), recovery point objective (RPO), obiettivi di disponibilità, capacità di throughput, tempi di attesa ammissibili ecc. Gli indicatori si traducono poi in SLA interni ed esterni, che fissano i target operativi da rispettare (ad es. il servizio deve rispondere entro 1 secondo, mantenere il 99,5% di uptime mensile, ecc.). Gli SLA diventano la soglia di riferimento per il monitoraggio DE.CM-01.

Un esempio: se un servizio di e-commerce ha SLA di uptime 99,9% (≈8.8 ore di downtime all’anno), si potrà definire un trigger di incidente se, ad esempio, si accumula più di 1 ora di indisponibilità in un singolo giorno lavorativo. In questo modo l’incidente viene “misurato” sulla base di dati oggettivi e non solo di allarmi IT.

Un approccio di questo genere segna il passaggio da una sicurezza reattiva a una proattiva basata sulle metriche.
Diversi studi hanno già evidenziato i vantaggi di un monitoraggio continuo e predittivo. Gartner prevede che, entro il 2030, le soluzioni di cybersecurity preemptive – in grado di anticipare le minacce con AI/ML – arriveranno a coprire il 50% della spesa IT in sicurezza (oggi sono sotto il 5%).
Analogamente, il Ponemon Institute rileva che le organizzazioni con monitoraggio proattivo riducono il rischio informatico del 60% rispetto a chi adotta strategie reattive. Definire e misurare i propri SL consente di rilevare prima le anomalie, limitando così costi e danni.

E i costi costo del downtime? Una survey ITIC del 2024 mostra che oltre il 90% delle grandi aziende stima un costo medio di oltre 300.000 $ per ogni ora di inattività IT. Anzi, il 40% dichiara perdite oltre 1 milione di dollari all’ora. I dati quindi, confermati da ricerche di settore, sottolineano che investire in misurabilità e in strumenti di monitoraggio (anche se costoso) è ampiamente giustificato dai potenziali risparmi in termini di perdite evitate.

La rivoluzione di prospettiva è sostenuta anche dalle normative. Il decreto Legislativo 138/2024 ha recepito la direttiva NIS2, innalzando gli standard di sicurezza. In Italia i soggetti “essenziali” e “importanti” (soggetti NIS) devono conformarsi alle misure del FNCDP 2.1. Le Linee Guida ACN (specifiche di base) dettagliano le misure obbligatorie e i tipi di incidenti significativi da segnalare. Il nuovo criterio oggettivo IS-3 collega esplicitamente gli incidenti ai livelli di servizio violati ed evidenzia che senza SL definiti e monitorati non è possibile riconoscere un incidente significativo, rendendo la normativa stessa non rispettata.

Dal 2026 scatteranno scadenze e obblighi stringenti: come previsto dall’ACN, entro 24 ore dalla scoperta di un incidente significativo il soggetto NIS deve inviare una pre-notifica al CSIRT Italia, e completare la notifica formale entro 72 ore (solo 24 ore per alcune entità specifiche).

In queste comunicazioni si descrive la natura dell’evento, la valutazione iniziale di gravità e l’eventuale impatto transfrontaliero, utilizzando anche i dati quantitativi raccolti (es. deviazioni di SL). A regime, ogni evento va analizzato partendo proprio dai dati di servizio: ad esempio, una anomalia di rete che causa il superamento del downtime concordato in SLA deve essere identificata come incidente significativo (criterio IS-3), altrimenti non si verificherebbe l’obbligo di notifica.

Per tradurre quanto esposto sopra in un percorso strutturato, ecco una possibile checklist di interventi pratici:

• Identificare i servizi e processi critici. Partire dalla Business Impact Analysis: mappare le attività con maggior impatto (e.g. sistemi produttivi, piattaforme di transazione, servizi sanitari digitali).
• Definire i livelli di servizio attesi (SL). Tradurre i risultati della BIA in indicatori concreti (uptime, RTO, tempi di risposta, performance). Se necessario, negoziare SLA contrattuali interni o con clienti/fornitori che riflettano questi obiettivi di servizio.
• Stabilire soglie di tolleranza. Per ciascun SL fissare i valori limite ammissibili (es. massimo downtime ammesso settimanale, latenza massima, soglie di errore). Documentare chiaramente quando una variazione diventa degrado di servizio.
• Implementare sistemi di monitoraggio e allerta. Configurare tool di rete, SIEM, log management e dashboard 24/7 per raccogliere i dati di performance. Gli indicatori definiti vanno tracciati automaticamente, con notifiche in real-time in caso di superamento delle soglie.
• Formalizzare procedure e ruoli. Aggiornare il piano di gestione incidenti definendo cosa fare quando un SLA è violato: chi riceve l’allarme, come analizzarlo, come avvisare il Referente CSIRT. Addestrare il team IT sulla nuova “cultura della tolleranza”: dovranno capire che una deviazione da SL equivale a pre-allarme.
• Verificare e adattare. Eseguire simulazioni (ad es. disaster recovery test) per verificare che le misure di monitoraggio siano efficaci e che il personale risponda correttamente. Rivedere periodicamente SL e soglie in base a nuove esigenze o modifiche di processo.

Esempio pratico: un fornitore di servizi cloud potrebbe stabilire che il suo servizio di database ha SLA di 99,9% di uptime mensile (≃43 minuti di downtime). Si decide che un’interruzione superiore a 30 minuti in una settimana farà scattare un’indagine interna. Quindi si configura il SIEM per monitorare metriche di disponibilità e, se il downtime cumulato oltrepassa 30 minuti, un alert segnala “l’anomalia di servizio”. Il team valuta subito se quel guasto è un incidente significativo (es. causa interruzione clienti) e attiva le notifiche secondo procedura.

L’adozione di questo approccio porta gli amministratori di sicurezza a misurare attivamente la propria resilienza. In linea con le aspettative di NIS2, i processi aziendali vengono così modellati intorno ai rischi reali e alle priorità di business. Le aziende conformi saranno quindi quelle che possono dimostrare dati concreti: report di monitoraggio, registri di allerta, documentazione SLA/SLA, piani di risposta. Grazie ai riferimenti del FNCDP 2.1 e delle linee guida ACN, ogni decisione (dalle risorse allocate alle scelte tecniche) sarà oggettivamente verificabile e coerente con l’obiettivo di rendere il sistema sicuro “misurabile” e non solo “adempito”.

BeeCyber offre servizi di cyber security completi e personalizzati per proteggere le aziende da minacce informatiche. BeeCyber fornisce una valutazione approfondita dei rischi, gestione delle identità, sistemi di protezione dei dati, monitoraggio continuo delle minacce e risposte rapide agli incident.
I servizi includono penetration test, vulnerability assessment e consulenza strategica per garantire conformità alle normative come NIS2, GDPR, ISO 27001 e altri requisiti specifici del settore.
Le soluzioni su misura di BeeCyber, insieme alla formazione del personale, aiutano a mantenere i sistemi aziendali sicuri e operativi.

Una mail al mese sui temi più caldi della cybersecurity. Iscriviti ora!
Compila il form per iscriverti alle nostre Cybernews