CSIRT: Piano di Incident Response in 12 Step [2026]

Il 16 ottobre 2024 l’Italia ha recepito la direttiva NIS2 con il Decreto Legislativo 138/2024, e da allora migliaia di aziende italiane devono fare i conti con un obbligo che prima riguardava quasi solo banche e infrastrutture critiche: rispondere a un incidente informatico in tempi stretti, con un team dedicato e procedure scritte. Il nome tecnico di quel team è CSIRT, Computer Security Incident Response Team, e nel 2026 non è più un lusso da multinazionale.

Il problema è che costruirne uno sembra un progetto da consulenza a sei cifre. Non lo è per forza. Con gli strumenti open source giusti, un mandato chiaro e qualche giorno di lavoro strutturato, un’azienda di medie dimensioni può avere un CSIRT operativo, testato e allineato ai tempi di notifica del NIS2. Questa guida mostra come farlo in 12 step, con stack tecnologico completo (TheHive, Cortex, MISP), script pronti all’uso e i playbook che servono davvero quando arriva la chiamata alle tre di notte.

Il costo di arrivarci impreparati si misura in cifre concrete. Secondo l’IBM Cost of a Data Breach Report 2026, il tempo medio globale per identificare e contenere una violazione è salito a 247 giorni, e il costo medio di una violazione ha raggiunto 4,99 milioni di dollari. Un CSIRT che funziona non elimina il rischio di essere attaccati, ma taglia drasticamente il tempo tra la scoperta e il contenimento, che è la variabile che pesa di più su quel conto finale.

Cos’è un CSIRT: definizione, ruolo e differenze con CERT e SOC

Un CSIRT è il gruppo di persone, interno, esterno o misto, che riceve la segnalazione di un incidente di sicurezza, la valuta, la contiene e coordina il ritorno alla normalità. Non è un prodotto da comprare. È una funzione organizzativa che si appoggia su strumenti, procedure scritte e un mandato chiaro da parte del vertice aziendale. Il nome compare spesso insieme a un altro termine, “referente CSIRT”, la figura che il NIS2 chiede alle aziende di designare formalmente come punto di contatto verso l’autorità nazionale.

In Italia il riferimento nazionale è CSIRT Italia, operativo sotto l’Agenzia per la Cybersicurezza Nazionale (ACN), l’ente istituito per proteggere gli interessi nazionali nel cyberspazio. CSIRT Italia gestisce un portale di segnalazione degli incidenti, pubblica bollettini periodici come “La Settimana Cibernetica” e distribuisce un feed pubblico di threat intelligence tramite MISP, la piattaforma open source per la condivisione di indicatori di compromissione.

A livello europeo, CSIRT Italia fa parte della EU CSIRTs Network, che riunisce 39 team: i CSIRT designati da ciascuno Stato membro più il CERT-UE, la squadra che protegge le istituzioni dell’Unione. Tre acronimi vengono spesso confusi tra loro, e vale la pena chiarirli prima di partire con la parte pratica.

Il CSIRT risponde agli incidenti quando accadono. Il CERT, Computer Emergency Response Team, è storicamente un concetto simile, usato più spesso da enti governativi o da team che gestiscono anche la divulgazione di vulnerabilità. Il SOC, Security Operations Center, è la funzione che monitora log e alert in modo continuo per individuare un’anomalia prima che diventi un incidente conclamato. In pratica un SOC alimenta il CSIRT: il primo rileva, il secondo interviene. Molte aziende medie uniscono le due funzioni nello stesso team, ma i ruoli restano distinti anche quando le persone coincidono.

La differenza pratica emerge nel momento peggiore possibile, cioè durante un incidente vero. Un SOC che si limita a inoltrare alert senza un CSIRT pronto a riceverli produce solo rumore. Un CSIRT senza un SOC (o senza log da qualche parte) scopre gli incidenti troppo tardi, spesso da un cliente o da un fornitore invece che dai propri strumenti. Le due funzioni vanno progettate insieme fin dal primo giorno, anche quando il team che le esegue è composto dalle stesse tre o quattro persone.

Aspetto	CSIRT	CERT	SOC
Funzione principale	Risponde e coordina gli incidenti confermati	Ruolo storicamente simile, spesso in ambito governativo o divulgazione vulnerabilità	Monitora log e alert in modo continuo
Quando interviene	Dopo la conferma di un incidente	Dopo la conferma di un incidente o una falla critica	Prima che l’incidente sia confermato
Riferimento in Italia	CSIRT Italia, sotto ACN	Il nome è usato meno spesso dopo la nascita di ACN	SOC interni o esternalizzati (MSSP)
Orizzonte temporale	Ore o giorni, per singolo incidente	Ore o giorni	Continuo, 24 ore su 24
Output principale	Contenimento, notifica NIS2, rapporto finale	Advisory e bollettini di sicurezza	Alert, ticket, escalation verso il CSIRT

Prerequisiti: cosa serve prima di iniziare

Prima di aprire un terminale servono tre cose che nessun tool risolve da solo: uno sponsor esecutivo che firmi il mandato, un elenco anche approssimativo dei sistemi critici da proteggere, e un budget minimo per l’infrastruttura tecnica. Sul fronte tecnico, questa guida usa uno stack open source che gira su una singola macchina virtuale per un ambiente di test, e su un piccolo cluster per la produzione.

Strumento	Versione consigliata	Uso nel progetto
Docker Engine	24 o successiva, con Compose V2	Esegue l’intero stack in container
Node.js	20 LTS o 22 LTS	Webhook di ingestion e script di automazione
TheHive	Ultima versione stabile	Gestione dei casi (case management)
Cortex	Ultima versione stabile	Analisi automatica degli indicatori
MISP	Ultima versione stabile	Condivisione di threat intelligence
RAM disponibile	Minimo 8 GB per un ambiente di test	Elasticsearch e Cassandra sono le voci più pesanti
Slack o Microsoft Teams	Permessi admin per creare un webhook in ingresso	Notifiche automatiche del CSIRT

Per seguire tutti gli step senza intoppi conviene anche avere un account email dedicato al CSIRT, separato dalla casella del singolo dipendente. Altrimenti un incidente rischia di restare bloccato nella casella di posta di qualcuno in ferie, ed è uno degli errori più banali e più comuni che vedremo più avanti.

Sul budget, la voce più grande di solito non è il software, che in questa guida è gratuito, ma l’infrastruttura che lo ospita e il tempo delle persone coinvolte. Per un ambiente di produzione modesto, un piccolo cluster su un provider cloud europeo o su server on-premise già esistenti copre le esigenze descritte qui senza bisogno di investimenti straordinari. La spesa cresce con la disponibilità richiesta: un CSIRT che deve rispondere H24 costa più di uno che opera in orario lavorativo con reperibilità telefonica.

Step 1: Definire mandato, perimetro e sponsorship esecutiva

Il primo documento da scrivere non è tecnico. È il mandato: un testo breve, firmato da un dirigente con potere decisionale, che stabilisce cosa il CSIRT può fare durante un incidente. Isolare un server, sospendere un account, bloccare il traffico verso un dominio: senza questa autorità scritta, ogni decisione durante una crisi diventa una discussione, e in un incidente le discussioni costano tempo che spesso non c’è.

Il perimetro va definito con la stessa cura. Quali sistemi copre il CSIRT? Solo l’infrastruttura IT centrale, o anche gli ambienti cloud, i fornitori critici, le filiali estere? Un perimetro vago genera zone grigie proprio nei momenti in cui serve chiarezza assoluta.

Un modo concreto per evitare ambiguità è scrivere, accanto al mandato, un elenco delle azioni che il CSIRT può eseguire senza chiedere permesso, e uno separato delle azioni che richiedono comunque il via libera di un dirigente, per esempio spegnere un sistema di produzione che genera fatturato. Questa distinzione, discussa e approvata prima di un incidente, evita che l’Incident Commander debba negoziare la propria autorità proprio mentre l’orologio delle scadenze NIS2 sta già scorrendo.

Step 2: Costruire il team e assegnare i ruoli

Un CSIRT funzionante non richiede un esercito. Richiede ruoli chiari, anche se le stesse persone ne coprono più di uno nelle aziende piccole. La tabella seguente riassume la struttura minima che regge un incidente reale senza andare in affanno.

Ruolo	Responsabilità principale	Impegno tipico
Incident Commander	Decide, coordina, comunica con il vertice aziendale	Un referente più un vice
Analista di sicurezza	Analizza log, indicatori e malware	Da due a quattro persone a rotazione
Referente legale e privacy	Valuta gli obblighi di notifica (NIS2, GDPR)	Coinvolto su richiesta
Referente comunicazione	Gestisce la comunicazione interna ed esterna	Coinvolto sugli incidenti gravi
Referente IT e infrastruttura	Esegue isolamento, patching, ripristino	Almeno due persone con accesso privilegiato
Referente CSIRT (NIS2)	Punto di contatto ufficiale verso ACN	Un nominativo formalmente designato

L’ultima riga merita attenzione. Il referente CSIRT è la persona che il NIS2 vuole vedere nominata per iscritto, quella che riceve le comunicazioni ufficiali da ACN e che firma le notifiche di incidente. Designarne uno solo, senza sostituto, è uno degli errori più frequenti tra le PMI italiane che stanno adeguandosi in questi mesi.

Per le aziende troppo piccole per avere quattro o cinque persone dedicate, una rotazione settimanale di reperibilità tra due o tre membri del team copre la maggior parte dei casi. L’importante è che la lista di reperibilità sia scritta da qualche parte di facilmente accessibile, e non solo nella testa di chi l’ha organizzata.

Step 3: Classificare gli incidenti per severità e impatto

Senza una scala di severità condivisa, ogni analista decide da solo cosa è urgente, e il risultato è che tutto diventa urgente o niente lo è. Serve uno schema semplice, con tempi di risposta associati a ogni livello, salvato in un formato che sia leggibile sia da una persona sia da uno script di automazione.

{
  "severity_levels": [
    { "code": "P1", "name": "Critico", "example": "Ransomware attivo, esfiltrazione dati in corso", "response_time_minutes": 30 },
    { "code": "P2", "name": "Alto", "example": "Accesso non autorizzato confermato, sistema isolato", "response_time_minutes": 120 },
    { "code": "P3", "name": "Medio", "example": "Malware rilevato e contenuto, nessuna diffusione", "response_time_minutes": 480 },
    { "code": "P4", "name": "Basso", "example": "Tentativo di phishing bloccato, nessun impatto", "response_time_minutes": 1440 }
  ]
}

Questo file diventa la base su cui il webhook di ingestion, costruito nello step 7, decide a chi mandare la notifica e con quale urgenza. Un P1 sveglia l’Incident Commander alle tre di notte. Un P4 finisce in un riepilogo settimanale.

Step 4: Scegliere lo stack tecnologico open source

Per questa guida usiamo tre progetti open source che insieme coprono l’intero ciclo di vita di un incidente. TheHive gestisce i casi: apertura, assegnazione, timeline, chiusura. Cortex esegue analisi automatiche sugli indicatori, per esempio interrogando servizi esterni su un hash di file o un indirizzo IP sospetto. MISP raccoglie e condivide indicatori di compromissione, compreso il feed pubblico distribuito da CSIRT Italia.

Nessuno dei tre richiede licenze a pagamento nella sua versione community. Il costo reale è nel tempo di configurazione e nella macchina che li ospita, non nel software.

CSIRT interno o esternalizzato: cosa conviene davvero

Prima di installare qualunque cosa, vale la pena rispondere a una domanda che questa guida presuppone già decisa: costruire il CSIRT internamente o affidarlo a un fornitore esterno? Non è una scelta binaria. Molte aziende italiane, soprattutto tra le PMI toccate per la prima volta dal NIS2, adottano un modello ibrido: un piccolo nucleo interno che conosce i sistemi aziendali, appoggiato a un provider di sicurezza gestita per la copertura notturna e nei weekend.

Il CSIRT interamente interno, come quello descritto in questa guida, ha senso quando l’azienda ha già competenze di sicurezza in casa e sistemi abbastanza particolari da rendere difficile spiegarli da zero a un fornitore esterno ogni volta che succede qualcosa. Il vantaggio è il controllo diretto e la conoscenza pregressa dell’ambiente. Lo svantaggio è dover garantire copertura, formazione continua e aggiornamento degli strumenti con le proprie risorse.

Esternalizzare a un provider di incident response gestita ha senso quando il team interno è piccolo o inesistente e serve una copertura H24 immediata. Lo svantaggio tipico è il tempo che il fornitore impiega a familiarizzare con l’ambiente specifico durante il primo vero incidente, un costo che si riduce firmando accordi di onboarding preventivo invece di aspettare la crisi per far conoscere al fornitore la propria infrastruttura. In entrambi i casi, il referente CSIRT verso ACN, descritto nello step 2, resta comunque una responsabilità che l’azienda non può scaricare del tutto su un terzo.

Step 5: Installare TheHive e Cortex con Docker Compose

Il modo più rapido per avere un ambiente di test funzionante è un unico file Docker Compose che avvia Cassandra, Elasticsearch, Cortex e TheHive in sequenza corretta.

version: "3.8"
services:
  cassandra:
    image: cassandra:4
    environment:
      - MAX_HEAP_SIZE=2G
      - HEAP_NEWSIZE=400M
    volumes:
      - cassandra_data:/var/lib/cassandra
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8
    environment:
      - discovery.type=single-node
      - xpack.security.enabled=false
    volumes:
      - es_data:/usr/share/elasticsearch/data
  cortex:
    image: thehiveproject/cortex:latest
    depends_on:
      - elasticsearch
    ports:
      - "9001:9001"
  thehive:
    image: strangebee/thehive:latest
    depends_on:
      - cassandra
      - elasticsearch
      - cortex
    ports:
      - "9000:9000"
    command: >
      --cql-hostnames cassandra
      --index-backend elasticsearch
      --es-hostnames elasticsearch
volumes:
  cassandra_data:
  es_data:

Avvia lo stack e verifica che TheHive risponda sulla porta 9000.

$ docker compose up -d
[+] Running 5/5
 ✔ Network csirt_default            Created
 ✔ Container csirt-cassandra-1      Started
 ✔ Container csirt-elasticsearch-1  Started
 ✔ Container csirt-cortex-1         Started
 ✔ Container csirt-thehive-1        Started

$ curl -s -o /dev/null -w "%{http_code}" http://localhost:9000
200

Se il primo avvio restituisce un errore di connessione da parte di TheHive, non allarmarti. È il problema più comune di questo step, ed è trattato per esteso nella sezione dedicata alla risoluzione dei problemi.

Step 6: Collegare MISP e il feed pubblico di CSIRT Italia

Con MISP installato, il passo successivo è aggiungere il feed pubblico che CSIRT Italia mette a disposizione per la condivisione di indicatori di compromissione. La configurazione avviene dalla sezione “Feeds” dell’interfaccia MISP, oppure via API con un payload come questo.

{
  "Feed": {
    "name": "CSIRT Italia - Feed pubblico",
    "provider": "ACN - CSIRT Italia",
    "url": "URL-DEL-FEED-MISP-INDICATO-DA-ACN",
    "source_format": "misp",
    "input_source": "network",
    "enabled": true,
    "caching_enabled": true
  }
}

Sostituisci il campo url con l’indirizzo pubblicato nella pagina ufficiale di CSIRT Italia, dove ACN mantiene aggiornate anche le istruzioni di accesso. Una volta importato, il feed alimenta automaticamente Cortex, che potrà confrontare ogni nuovo indicatore ricevuto dal webhook con quelli già noti.

Il valore di questo collegamento cresce nel tempo. Il primo giorno il feed è quasi vuoto di corrispondenze utili per la tua azienda specifica, ma ogni ransomware, ogni campagna di phishing e ogni vulnerabilità sfruttata attivamente che CSIRT Italia osserva a livello nazionale arricchisce la base di indicatori che Cortex confronta automaticamente. Dopo qualche mese di raccolta, un nuovo alert dal tuo SIEM può risultare già noto e già classificato, invece di richiedere un’analisi da zero.

Step 7: Costruire un webhook di ingestion in Node.js

La maggior parte degli incidenti non arriva bussando alla porta di TheHive. Arriva da un SIEM, da un antivirus, da un modulo di contatto sul sito. Serve un punto di ingresso unico che normalizzi tutto in un formato coerente prima di creare un caso.

import express from "express";
import crypto from "node:crypto";

const app = express();
app.use(express.json());

const WEBHOOK_SECRET = process.env.CSIRT_WEBHOOK_SECRET;

function verifySignature(req) {
  const signature = req.get("X-Signature") || "";
  const expected = crypto
    .createHmac("sha256", WEBHOOK_SECRET)
    .update(JSON.stringify(req.body))
    .digest("hex");
  return crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected));
}

app.post("/webhook/incident", (req, res) => {
  if (!verifySignature(req)) {
    return res.status(401).json({ error: "firma non valida" });
  }

  const { source, severity, description, indicators } = req.body;

  const incident = {
    id: crypto.randomUUID(),
    source,
    severity: severity || "P4",
    description,
    indicators: indicators || [],
    receivedAt: new Date().toISOString(),
    status: "nuovo"
  };

  console.log(`[CSIRT] Nuovo incidente ${incident.id} - severita ${incident.severity}`);
  res.status(202).json({ id: incident.id, status: incident.status });
});

app.listen(3000, () => console.log("Webhook CSIRT in ascolto sulla porta 3000"));

Un test rapido con curl conferma che il flusso funziona prima di collegarlo a un sistema reale.

$ curl -X POST http://localhost:3000/webhook/incident \
  -H "Content-Type: application/json" \
  -H "X-Signature: 6a1b3f9c..." \
  -d '{"source":"SIEM","severity":"P2","description":"Login anomalo da IP esterno","indicators":["203.0.113.55"]}'

{"id":"6f1a2e3d-8b2c-4a11-9c3e-2d1f0a9b7c44","status":"nuovo"}

Da qui, il passo successivo naturale è inoltrare l’oggetto incident a TheHive tramite la sua API REST per creare il caso vero e proprio, e passare l’array indicators a Cortex per l’analisi automatica.

Step 8: Automatizzare le notifiche su Slack e Teams

Un caso aperto in TheHive che nessuno controlla per ore non serve a niente. Il webhook creato allo step precedente può richiamare direttamente una funzione di notifica, colorata in base alla severità, così chi riceve il messaggio capisce in un secondo se deve fermare quello che sta facendo.

async function notifySlack(incident) {
  const webhookUrl = process.env.SLACK_CSIRT_WEBHOOK;

  const color = { P1: "#d32f2f", P2: "#f57c00", P3: "#fbc02d", P4: "#388e3c" }[incident.severity] || "#607d8b";

  const payload = {
    attachments: [
      {
        color,
        title: `Nuovo incidente ${incident.severity} - ${incident.id}`,
        text: incident.description,
        fields: [
          { title: "Origine", value: incident.source, short: true },
          { title: "Ricevuto alle", value: incident.receivedAt, short: true }
        ]
      }
    ]
  };

  const response = await fetch(webhookUrl, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(payload)
  });

  if (!response.ok) {
    throw new Error(`Notifica Slack fallita: ${response.status}`);
  }
}

Per Microsoft Teams la logica è identica: cambia solo il formato del payload, che segue lo schema delle Adaptive Card invece degli attachment in stile Slack.

Step 9: Scrivere i playbook di contenimento, eradicazione e ripristino

Un playbook non è un manuale teorico. È una checklist che qualcuno stressato alle due di notte può seguire riga per riga senza dover inventare nulla. Conviene scriverli come file di testo strutturato, versionati in git insieme al resto del progetto, così ogni modifica lascia traccia.

playbook: ransomware
trigger: "rilevata cifratura anomala di massa su file server"
fasi:
  identificazione:
    - isolare gli host coinvolti dalla rete, senza spegnerli
    - preservare la memoria RAM se possibile, prima di qualsiasi intervento
    - raccogliere hash dei file cifrati e della nota di riscatto
  contenimento:
    - disabilitare gli account compromessi
    - bloccare gli indicatori noti su firewall ed EDR
    - isolare i backup non ancora colpiti
  eradicazione:
    - rimuovere il malware confermato sugli host isolati
    - reimpostare le credenziali coinvolte
  ripristino:
    - ripristinare da backup verificati e non collegati alla rete compromessa
    - monitorare per 14 giorni eventuali segnali di reinfezione
  post_incidente:
    - preparare il rapporto per la notifica NIS2 entro un mese
    - aggiornare il playbook con le lezioni apprese

Scrivi almeno tre playbook per partire: ransomware, accesso non autorizzato e fuga di dati. Coprono la maggioranza degli scenari che un CSIRT italiano incontra davvero. Tieni ogni playbook breve, idealmente leggibile in meno di due minuti, perché durante un incidente reale nessuno ha il tempo o la lucidità di scorrere dieci pagine per trovare il passaggio giusto.

Step 10: Allineare i tempi alle scadenze del NIS2

L’articolo 23 della direttiva NIS2 fissa tre scadenze precise per i soggetti che rientrano nel suo perimetro. Il Decreto Legislativo 138/2024 le recepisce in Italia, con CSIRT Italia come punto di ricezione delle notifiche.

Termine	Scadenza	Cosa comunicare	Destinatario
Preallarme (early warning)	Entro 24 ore dalla scoperta	Sospetto di incidente significativo, eventuale origine	CSIRT Italia / ACN
Notifica dell’incidente	Entro 72 ore dalla scoperta	Valutazione iniziale, gravità, indicatori di compromissione	CSIRT Italia / ACN
Rapporto intermedio	Su richiesta di ACN	Aggiornamento sullo stato della gestione	CSIRT Italia / ACN
Rapporto finale	Entro un mese dalla notifica	Analisi dettagliata, causa, misure di mitigazione	CSIRT Italia / ACN
Comunicazione pubblica	Caso per caso, su indicazione di ACN	Informazioni per il pubblico se l’impatto è diffuso	ACN / CSIRT Italia

Ricordarsi manualmente di questi termini durante un incidente è la ricetta perfetta per mancarli. Meglio calcolarli automaticamente nel momento stesso in cui il caso viene aperto.

function calcolaScadenzeNIS2(incidentDiscoveredAt) {
  const discovered = new Date(incidentDiscoveredAt);

  const preallarme = new Date(discovered.getTime() + 24 * 60 * 60 * 1000);
  const notifica = new Date(discovered.getTime() + 72 * 60 * 60 * 1000);
  const rapportoFinale = new Date(discovered);
  rapportoFinale.setMonth(rapportoFinale.getMonth() + 1);

  return {
    preallarme: preallarme.toISOString(),
    notifica: notifica.toISOString(),
    rapportoFinale: rapportoFinale.toISOString()
  };
}

console.log(calcolaScadenzeNIS2("2026-06-14T09:00:00Z"));

{
  preallarme: '2026-06-15T09:00:00.000Z',
  notifica: '2026-06-17T09:00:00.000Z',
  rapportoFinale: '2026-07-14T09:00:00.000Z'
}

Collega questa funzione al webhook dello step 7 e ogni nuovo incidente porterà già con sé le tre date critiche, pronte per essere mostrate nella card di Slack o nel caso TheHive.

Step 11: Validare il CSIRT con un’esercitazione tabletop

Un piano mai testato è solo una teoria. L’esercitazione tabletop è il modo più economico per scoprire le falle prima che lo faccia un attaccante vero: si riunisce il team, si presenta uno scenario realistico (per esempio un ransomware scoperto un venerdì sera) e si segue il playbook passo per passo, a voce, senza toccare sistemi reali.

Durante l’esercitazione, cronometra ogni fase. Se il team impiega quattro ore per decidere chi ha l’autorità di isolare un server, il problema non è tecnico: è nel mandato scritto allo step 1, che va rivisto.

Invita al tabletop anche persone che normalmente non partecipano alla gestione tecnica: il legale, un responsabile di produzione, qualcuno della comunicazione. Un incidente vero coinvolge quasi sempre più reparti di quanti il team tecnico si aspetti, e la prima volta che il referente legale sente parlare delle scadenze NIS2 non dovrebbe essere durante l’incidente stesso. Ripeti l’esercitazione almeno una volta l’anno, e ogni volta che cambia in modo sostanziale l’infrastruttura coperta dal CSIRT.

Step 12: Misurare la maturità con il modello SIM3

SIM3, Security Incident Management Maturity Model, è un framework usato per valutare quanto un CSIRT sia realmente pronto, non solo sulla carta. Divide la valutazione in quattro domini: organizzazione, risorse umane, strumenti e processi. Per ciascun parametro assegna un livello di maturità, da zero (non definito) a quattro (ottimizzato e riesaminato regolarmente).

Non serve una certificazione formale per trarne beneficio. Anche un’autovalutazione interna, fatta onestamente una volta l’anno confrontando i quattro domini del modello SIM3, mostra con chiarezza dove il CSIRT è solido e dove sta ancora bluffando. Diversi CSIRT nazionali europei usano proprio SIM3 come riferimento comune quando devono confrontare la propria maturità con quella di altri team della rete.

A questo punto i quattro pezzi di codice costruiti negli step precedenti, il webhook di ingestion, lo script di notifica, il calcolo delle scadenze NIS2 e il docker-compose dello stack TheHive/Cortex, formano insieme un piccolo progetto funzionante: un CSIRT starter kit che riceve un segnale, lo classifica, apre un caso, avvisa le persone giuste e tiene traccia delle scadenze legali, tutto senza intervento manuale nei primi minuti più critici.

Errori comuni da evitare

Chi costruisce il primo CSIRT aziendale tende a ripetere lo stesso piccolo insieme di errori, indipendentemente dal settore o dalle dimensioni dell’azienda. Conoscerli in anticipo costa molto meno che scoprirli durante un incidente reale.

Trattare il piano come un documento da archiviare. Un piano scritto e mai provato si scopre inadeguato proprio durante il primo incidente vero, quando è troppo tardi per correggerlo con calma.
Nessuno sponsor esecutivo dietro al team. Senza un mandato firmato dal vertice, ogni decisione urgente diventa una discussione con il legale o con l’IT, e il tempo perso si misura in ore.
Un solo referente CSIRT, senza sostituto. Quando quella persona è in ferie o irraggiungibile, la notifica delle 24 ore rischia di saltare per un motivo puramente organizzativo.
Playbook scritti in astratto, mai testati su uno scenario concreto. Un playbook che nessuno ha mai seguito ad alta voce contiene quasi sempre un passaggio ambiguo che emerge solo sotto pressione.
Strumenti scollegati tra loro. Un SIEM che genera alert e nessuno legge in tempo utile equivale a non avere il SIEM.
Sottovalutare la scadenza delle 24 ore del NIS2. Molte aziende si accorgono del termine solo a incidente già in corso, quando ormai mancano poche ore.

Risoluzione dei problemi più comuni

Questi sono i problemi che emergono più spesso nelle prime settimane dopo aver seguito gli step precedenti, in ordine più o meno di frequenza. Se qualcosa non torna durante l’installazione o l’uso quotidiano dello stack, è probabile che la causa sia già in questa lista.

TheHive non si avvia dopo docker compose up. Cassandra ed Elasticsearch impiegano fino a un minuto per diventare pronti, e TheHive tenta la connessione troppo presto. Aggiungi un healthcheck con condition: service_healthy, oppure riavvia solo il servizio thehive dopo trenta secondi.
Cortex resta “unreachable” da TheHive. Quasi sempre è un problema di rete Docker: l’URL configurato punta a localhost invece che al nome del servizio. Usa il nome del container, cortex, come host.
Il webhook Node.js risponde 401 a ogni richiesta. La variabile CSIRT_WEBHOOK_SECRET non è impostata nell’ambiente, quindi la firma calcolata non corrisponde mai. Verifica il valore prima di avviare il servizio.
Le notifiche su Slack smettono di arrivare senza errori visibili. Il webhook URL è stato rigenerato dopo una modifica ai permessi dell’app Slack. Rigeneralo e aggiorna la variabile d’ambiente.
La coda degli incidenti si riempie di falsi positivi. Serve tuning delle regole del SIEM o del connettore a monte, non un intervento sul CSIRT. Imposta una soglia minima di confidenza prima di generare un caso.
Il team scopre la scadenza delle 72 ore quando è già passata. Manca un promemoria automatico. Collega lo script delle scadenze a un job pianificato che avvisa a metà intervallo, non solo alla scadenza.
Log di fonti diverse arrivano in formati incompatibili nello stesso caso. Normalizza in ingresso, per esempio convertendo tutto in un formato comune come ECS, prima di creare l’osservabile in TheHive.
Elasticsearch va in errore di memoria sulla VM di test. Riduci MAX_HEAP_SIZE a un valore compatibile con la RAM disponibile, indicativamente non oltre la metà della RAM totale della macchina.
Due fonti diverse aprono due casi per lo stesso incidente. Aggiungi una deduplica basata su un hash degli indicatori chiave, come IP, hash del file o dominio, prima di creare un nuovo caso.

Consigli avanzati per CSIRT già operativi

Una volta superata la fase di avvio, alcuni accorgimenti fanno la differenza tra un CSIRT che sopravvive e uno che migliora ogni trimestre. Nessuno di questi richiede di ripartire da zero: si innestano sullo stack già installato negli step precedenti.

Integra, oltre al feed di CSIRT Italia, fonti settoriali come un ISAC se il tuo settore ne ha uno attivo.
Automatizza le azioni di contenimento più ripetitive, come il blocco di un IP o la disabilitazione di un account, con piccoli “responder” che Cortex può richiamare: il tempo dell’analista va speso sulle decisioni, non sull’esecuzione manuale.
Affianca al tabletop annuale un esercizio più tecnico, tipo purple team, dove un piccolo gruppo simula davvero un attacco mentre il resto del CSIRT risponde.
Misura MTTD e MTTR interni ogni trimestre. L’IBM Cost of a Data Breach Report 2026, pubblicato il 29 luglio 2026, riporta un tempo medio globale di 247 giorni per identificare e contenere una violazione: se il tuo dato è molto sopra quella soglia, il problema di solito è nel rilevamento, non nella risposta.
Ripeti l’autovalutazione SIM3 una volta l’anno per capire quale dei quattro domini è rimasto indietro rispetto agli altri.

Il costo di una violazione resta un buon promemoria del perché vale la pena investire tempo in tutto questo. Secondo lo stesso report IBM, il costo medio globale di una violazione nel 2026 è di 4,99 milioni di dollari, e sale a circa 6 milioni quando l’attacco coinvolge componenti basate su intelligenza artificiale, una categoria che secondo IBM ha riguardato una violazione dolosa su quattro nell’ultimo anno.

Rileggendo i 12 step nel loro insieme, il filo conduttore è sempre lo stesso: un CSIRT non si misura dal numero di strumenti installati, ma da quanto rapidamente e con quanta chiarezza le persone giuste prendono le decisioni giuste. Lo stack tecnico costruito in questa guida, TheHive per i casi, Cortex per l’analisi, MISP per la threat intelligence, un webhook Node.js per l’ingestion e gli script per le notifiche e le scadenze, esiste per togliere attrito da quel processo decisionale, non per sostituirlo. Il mandato, i ruoli e i playbook scritti nei primi step contano quanto il codice, se non di più.

Domande frequenti

Cos’è esattamente un CSIRT?

È il team che riceve, valuta e gestisce gli incidenti di sicurezza informatica di un’organizzazione, dal primo allarme fino al rapporto finale.

Il NIS2 obbliga la mia azienda ad avere un CSIRT interno?

Il NIS2, recepito in Italia con il Decreto Legislativo 138/2024, impone obblighi di notifica e di gestione del rischio ai soggetti che rientrano nel suo perimetro. Non impone sempre un CSIRT interno dedicato: molte aziende si appoggiano a un provider esterno o a un servizio gestito, ma devono comunque avere una funzione capace di rispettare i tempi di notifica.

Quanto costa costruire un CSIRT con gli strumenti di questa guida?

Lo stack descritto, TheHive, Cortex e MISP, è gratuito nella componente software. Il costo reale è nel tempo delle persone e nell’infrastruttura che lo ospita, che per un ambiente di produzione modesto parte da poche centinaia di euro al mese di hosting.

Quali sono i tempi di notifica del NIS2?

In sintesi: preallarme entro 24 ore dalla scoperta, notifica dell’incidente entro 72 ore, rapporto finale entro un mese, tutti indirizzati a CSIRT Italia tramite ACN.

TheHive e Cortex sono davvero gratuiti?

Le versioni community sono open source. StrangeBee, l’azienda dietro TheHive, offre anche piani commerciali con supporto e funzionalità aggiuntive, ma lo stack di base usato in questa guida si appoggia solo su componenti gratuiti.

Come mi collego al feed MISP di CSIRT Italia?

Le istruzioni aggiornate e l’indirizzo del feed sono pubblicati sulla pagina ufficiale di CSIRT Italia sul portale ACN. Una volta ottenuto l’indirizzo, la configurazione lato MISP è quella mostrata nello step 6 di questa guida.

Quanto tempo serve per avere un CSIRT operativo da zero?

Con un mandato già approvato, un team di due o tre persone può avere lo stack tecnico installato e i primi playbook scritti in una o due settimane di lavoro concentrato. La parte più lenta di solito è ottenere lo sponsor esecutivo, non la tecnologia.

Cosa succede se non rispetto le scadenze di notifica NIS2?

Il Decreto Legislativo 138/2024 prevede sanzioni per i soggetti che non rispettano gli obblighi di notifica e gestione del rischio. L’entità esatta dipende dalla categoria del soggetto e dalla gravità della violazione, quindi conviene verificare il testo del decreto insieme al proprio referente legale.

Per una panoramica più ampia sui temi di sicurezza trattati su Shattered, consulta anche la sezione Sicurezza online.