Gestione degli incidenti informatici: quale metodo adottare? Cosa cambia con la NIS2?

Il quadro normativo: NIS2 e D.Lgs. 138/2024

In Italia, il contesto normativo di riferimento è il Decreto Legislativo 4 settembre 2024, n. 138 (in vigore dal 16 ottobre 2024), che recepisce la Direttiva europea NIS2 (Network and Information Security). L’Agenzia per la Cybersicurezza Nazionale (ACN) è diventata il motore attuativo della direttiva e ha pubblicato determinazioni operative per strutturare obblighi, ruoli e scadenze per i soggetti essenziali e importanti (scopri di più nell’articolo dedicato).

La vera prova del nove per qualsiasi organizzazione è la gestione degli incidenti, ecco perché è così importante parlarne e capire come reagire. Secondo la normativa vigente, le tempistiche di notifica sono stringenti: pre-notifica (early warning) entro 24 ore dalla rilevazione e notifica completa entro 72 ore, con follow-up successivo. Questi tempi non lasciano spazio all'improvvisazione. Chi non ha definito in anticipo ruoli chiari, procedure testate e registri aggiornati, troverà quelle 72 ore insufficienti.

A livello europeo, il Regolamento di esecuzione (UE) 2024/2690 ha ulteriormente alzato l'asticella per i servizi "digitali" (tra cui cloud, data center, managed services marketplace…). Anche chi non rientra direttamente in queste categorie subisce l'impatto delle clausole contrattuali lungo tutta la catena del valore.

Il processo per rispondere a un incidente

Un processo di risposta agli incidenti efficace segue fasi precise. Le organizzazioni più mature, ispirate ai framework ITIL (Information Technology Infrastructure Library) e alle pratiche SRE (Site Reliability Engineering), articolano la risposta in sette passaggi:

1. Rilevare l'incidente, idealmente prima che gli utenti se ne accorgano.
2. Configurare e attivare i canali di comunicazione del team (chat, videochiamata ecc.).
3. Valutare l'impatto e assegnare un livello di gravità (SEV1, SEV2, SEV3) *.
4. Comunicare tempestivamente con clienti e stakeholder.
5. Fare escalation ai responder corretti tramite strumenti di allerta.
6. Assegnare e delegare chiaramente i ruoli. Il responsabile degli incidenti ha l’autorità complessiva sull'incidente, il responsabile tecnico guida il team tecnico che risolveil problema, il responsabile delle comunicazioni ha il compito di redigere e inviare le comunicazioni interne ed esterne relative all'incidente. Un dato spesso sottovalutato: l'87% degli stakeholder aziendali richiede aggiornamenti durante un incidente e il 56% è più frustrato dalla mancanza di comunicazione che dall'incidente stesso.
7. Risolvere e documentare l’incidente.

*

Fonte: Collaborative incident management with Jira Service Management – Atlassian.com

Il ruolo del fattore umano nella prevenzione e nella risposta

Le tecnologie di rilevamento sono necessarie ma non sufficienti, il fattore umano rimane centrale. Gartner prevede che la maggioranza dei CISO adotterà entro breve un approccio human-centric security, stimando una riduzione del 30% degli incidenti.

Questo modello si costruisce con alcune leve fondamentali:

• Formazione continua e contestualizzata: simulazioni realistiche, campagne di ethical phishing seguite da sessioni educative, esercitazioni pratiche che allenino i team a reagire correttamente.
• Sistemi intuitivi: progettare procedure e strumenti che minimizzino gli errori. Ad esempio, adottare sistemi SSO (Single Sign-On) per semplificare l'autenticazione sicura.
• Responsabilizzazione collettiva: ogni persona nell'organizzazione è un anello fondamentale della catena della sicurezza, per cui tutti devono essere formati.

Revisione post-incidente: imparare senza cercare colpevoli  

Quando un incidente è risolto, il lavoro non è finito. La revisione post-incidente (PIR - Post-Incident Review) è il momento in cui un'organizzazione trasforma una criticità in un'opportunità di miglioramento.

Una revisione post-incidente efficace ha queste caratteristiche:

• Si svolge entro 24-48 ore dalla risoluzione, per evitare di tralasciare dettagli importanti.
• Adotta una cultura senza colpe (blameless postmortem): l'obiettivo è capire cosa è successo, non punire chi ha sbagliato.
• Applica tecniche come i "Cinque Perché" (Five Whys) per identificare le cause: chiedersi perché è successo e poi interrogarsi sulla risposta. Ripetere questo processo almeno cinque volte per assicurarsi di scoprire e analizzare tutti i fattori più profondi.
• Produce un report strutturato con sequenza temporale, impatto, azioni correttive e owner.

La revisione post-incidente aumenta anche la fiducia: dimostra a clienti, partner e stakeholder un'organizzazione trasparente e pronta a migliorare costantemente.

Atlassian e Jira Service Management: una risposta concreta

Costruire una gestione degli incidenti matura richiede metodo, ma anche gli strumenti adeguati. Jira Service Management di Atlassian è la piattaforma che centralizza alert, notifiche e collaborazione in un unico ambiente, supportando i team IT e DevOps nella gestione degli incidenti.

Concretamente significa poter rispettare le tempistiche stringenti della NIS2: gli alert provenienti da tutti i sistemi di monitoring vengono aggregati automaticamente, i team corretti vengono notificati tramite e-mail, chiamata vocale o push notification e i clienti vengono informati proattivamente delle interruzioni di servizio. Per la fase di revisione post-incidente, la piattaforma genera automaticamente report con causa principale, punti di forza e aree di miglioramento e permette di collegare ogni azione correttiva direttamente all'incidente che l'ha generata.

Se vuoi saperne di più su Atlassian e Jira Service Management per la gestione degli incidenti scarica l'ebook gratuito "Gli incidenti accadono. Ciò che conta è come li gestisci."