Un attacco informatico può paralizzare la tua azienda in pochi minuti. Senza un piano, sei già in ritardo. Noi di Meteora Web lo vediamo ogni giorno nelle PMI italiane: server crittografati, dati rubati, fatturato azzerato. La differenza tra chi si riprende in ore e chi chiude i battenti? Un framework di Incident Response solido, testato, e gestito come un progetto di bilancio: con metriche, priorità e conti alla mano.
In questa guida avanzata entriamo nelle prime tre fasi del ciclo di vita dell'incident response: Preparation, Detection e Containment. Il resto (Eradication, Recovery, Lessons Learned) lo tratteremo in un prossimo approfondimento. Qui vogliamo che tu esca con strumenti operativi per costruire o rafforzare la tua capacità di risposta immediata.
Perché un framework formale? Perché il caos costa più dell'attacco
L'istinto di fronte a un incidente è correre a spegnere tutto. Ma quella reazione distrugge prove, allunga i tempi di ripristino e fa perdere soldi. Noi lo abbiamo visto su un cliente: un ransomware ha colpito il magazzino. Il titolare ha staccato la spina del server. Risultato: backup non recuperabili, giornate di fermo, e una perizia forense che ha dovuto ricostruire tutto da log incompleti. Un framework — come il NIST SP 800-61 o il SANS PICERL — ti dà una sequenza logica, step affidabili, e una lingua comune tra tecnici, management e assicurazione.
Fase 1: Preparation — il 70% del successo si decide prima dell'attacco
La preparazione è tutto ciò che fai prima che scatti l'allarme. Noi la chiamiamo 'contabilità preventiva': come un bilancio di previsione, stabilisci risorse, responsabilità e processi. Senza, ogni altra fase è un tiro al buio.
1.1 Costruisci un team di risposta (CSIRT) con ruoli chiari
Non serve una struttura militare, ma serve che ognuno sappia cosa fare. Per una PMI, il team minimo può essere di 3 persone: un coordinatore (prende decisioni, parla con la direzione), un tecnico sistemista/security (analisi e contenimento) e un referente legale/assicurativo. Documenta i ruoli in una runbook che aggiorni ogni trimestre.
1.2 Strumenti essenziali da avere pronti
- Endpoint Detection and Response (EDR) su tutti i server e workstation critiche.
- SIEM (anche gratuito come Wazuh) per centralizzare log e creare alert.
- Backup offline e immutabili testati almeno ogni 30 giorni.
- VPN e accesso remoto sicuro per il team di risposta.
- Playbook di risposta per scenari comuni: ransomware, phishing, furto di credenziali.
Cosa fare adesso: scarica il template gratuito di playbook da SANS e personalizza uno scenario ransomware per la tua azienda entro 7 giorni.
1.3 Test periodici: il drill che non fallisci mai
Tutti i framework dicono 'tabletop exercise' o 'simulazione'. Noi lo traduciamo in pratica: ogni trimestre, blocca la mattinata, chiama il team, e simula un incidente. Usa una checklist. Misura i tempi di rilevamento e contenimento. Un cliente che seguiamo ha scoperto così che il backup era incompleto su un server critico. Lo ha risolto prima del vero attacco.
Fase 2: Detection — individualo prima che la tua casella di posta esploda
La detection non è solo 'allarme che scatta'. È la capacità di distinguere un falso positivo da una minaccia reale, e di farlo in fretta. Noi, di Meteora Web, vediamo spesso aziende che ignorano alert perché 'troppi falsi allarmi'. Il problema non è l'alert, ma la soglia e il contesto.
2.1 Imposta alert basati su comportamento, non solo su firme
Un antivirus con firme è inutile contro attacchi zero-day. Usa regole di comportamento: 'un utente che accede a 500 file in 30 secondi' è più indicativo di 'nome file ransomware.exe'. In un SIEM come Wazuh, puoi creare regole personalizzate.
Esempio di regola Wazuh per rilevare accesso massivo a file (Linux):
<group name="file_access,attack">
<rule id="100100" level="12">
<if_sid>550</if_sid>
<field name="audit.data.path">^/data/</field>
<field name="audit.data.count" type="pcre2">\d{3,}</field>
<description>Accesso anomalo a più di 100 file in /data</description>
<options>no_full_log</options>
</rule>
</group>
Cosa fare adesso: abilita l'audit dei file system critici (su Linux: auditd, su Windows: SACL) e configura il tuo SIEM per generare alert quando un utente tocca più di 100 file in 5 minuti.
2.2 La catena di custodia dei log: non cancellare nulla
In fase di detection, ogni log è una prova. Configura la retention minima di 6 mesi (meglio 12) per log di autenticazione, accesso a dati sensibili, firewall, DNS. Se il SIEM è su cloud, assicurati che il vendor fornisca un export forense in formato standard (JSON, CSV). Noi abbiamo visto casi in cui un log cancellato ha impedito di risalire al vettore di attacco.
Fase 3: Containment — fermare l'incendio senza allagare la casa
Quando l'incidente è confermato, la priorità è limitare il danno. Il contenimento può essere temporaneo (isolare host) o permanente (ricostruire da backup). L'errore più comune? Staccare tutto e perdere la visibilità sull'attaccante.
3.1 Isolamento chirurgico: blocca la comunicazione, non il server
Se possibile, usa regole firewall o iptables per bloccare il traffico verso l'esterno mantenendo l'host accessibile per la forensics. Esempio su Linux:
# Blocca tutto il traffico in uscita dall'interfaccia eth0 verso internet
# (lascia la rete locale per la forensics)
/sbin/iptables -A OUTPUT -o eth0 -d 0.0.0.0/0 -j DROP
# Blocca solo la porta di comando & control (es. 8443 TCP)
/sbin/iptables -A OUTPUT -o eth0 -p tcp --dport 8443 -j DROP
Su Windows, usa netsh advfirewall per aggiungere una regola di blocco. Dopo il contenimento, genera un dump della memoria (con FTK Imager o Winpmem) prima di spegnere la macchina.
3.2 Contenimento a livello di rete: segmentazione immediata
Se l'attacco si propaga, isola il segmento di rete compromesso tramite VLAN o ACL dello switch. Documenta ogni azione con timestamp e operatore. Questo non è solo buona pratica: in caso di contenzioso assicurativo, la traccia è la tua difesa.
Cosa fare adesso: prepara un documento di 'runbook di contenimento' con comandi pronti per i tuoi ambienti (Linux e Windows). Testalo in un ambiente di lab entro 15 giorni.
Dove vanno a finire i soldi? Il costo della mancanza di preparazione
Noi ragioniamo in numeri. Un'azienda senza IR framework impiega in media 10 giorni per contenere un ransomware (dati IBM 2025). Con un team preparato, scende a 2 giorni. Il costo medio di un'ora di downtime per una PMI italiana è stimato tra 500 e 5.000 euro a seconda del settore. Preparare un piano costa qualche migliaio di euro e qualche ora di formazione. Non prepararlo costa ordini di grandezza superiori.
Lo abbiamo visto con un nostro cliente: dopo un attacco di social engineering (proprio come quelli descritti nel nostro articolo Sulle tecniche di social engineering), hanno attivato il playbook preparato in 4 ore invece di 4 giorni. Il containment è stato rapido, nessun dato crittografato. Il costo? Solo le ore di consulenza.
In sintesi — cosa fare adesso
- Identifica il team CSIRT minimo e scrivi una runbook per uno scenario ransomware entro 7 giorni.
- Configura un SIEM con regole di rilevamento comportamentale (almeno per file system e autenticazione).
- Testa un drill di detection e containment in un ambiente di staging entro 30 giorni.
- Automatizza il blocco di rete con uno script pronto da eseguire via SSH o PowerShell.
- Documenta ogni azione — in un incidente, la traccia vale più di un backup.
Se hai dubbi sul tuo attuale livello di preparazione, possiamo fare un audit gratuito di 30 minuti. Noi di Meteora Web lavoriamo con aziende del Sud Italia e non solo, portando strumenti di serie A in contesti che spesso pensano di non poterseli permettere. Invece non possono permettersi di non averli.
Sponsored Protocol
