Valutare l'impatto di un attacco ransomware su una PMI: simulazione e piano di risposta

A fine novembre 2025 ho ricevuto una chiamata dal direttore generale di un'azienda del settore manifatturiero con sede nel nord-est, circa 60 dipendenti, un fatturato annuo intorno agli 8 milioni di euro e una produzione che dipendeva in modo critico da quattro sistemi IT: il gestionale ERP che governava ordini, magazzino e fatturazione elettronica, il server di posta con le caselle PEC per la comunicazione con la pubblica amministrazione, un NAS interno con tredici anni di documentazione tecnica e progettuale, e un applicativo web che i clienti del portale B2B usavano per inserire e tracciare gli ordini. La domanda era semplice e allarmante nella sua onestà: "Se domani mattina accendiamo i computer e tutto è cifrato, quanto tempo ci serve per tornare operativi?" Nessuno in azienda aveva mai provato a rispondere a quella domanda con dei numeri. Ho proposto una simulazione di impatto ransomware - non un penetration test, non un vulnerability assessment, ma un esercizio strutturato per misurare quanto l'azienda avrebbe effettivamente resistito a uno scenario di cifratura completa dei sistemi. I risultati, raccolti in cinque giorni di lavoro distribuiti su due settimane, erano peggiori di quanto chiunque si aspettasse: 18 ore per ripristinare i sistemi principali nella migliore delle ipotesi, 40 ore per i secondari, e il backup più recente utilizzabile risaliva a tre settimane prima. Tre settimane di ordini, fatture, email, documenti progettuali che sarebbero andati persi. In un'azienda che fattura 8 milioni l'anno, tre settimane di dati significano circa 460.000 euro di transazioni commerciali potenzialmente irrecuperabili.

Mappare i sistemi critici prima che lo faccia un attaccante

La prima fase della simulazione è quella che chiamo asset criticality mapping: un censimento sistematico di tutti i sistemi IT dell'azienda, classificati per impatto operativo del loro fermo. Non è un inventario hardware - è un'analisi di dipendenza di business. Per ogni sistema mi pongo tre domande: quanto tempo l'azienda può restare operativa senza questo sistema? Quanti dipendenti sono bloccati se questo sistema non funziona? Quale impatto economico diretto produce ogni ora di indisponibilità?

Nel caso dell'azienda manifatturiera, la mappatura ha prodotto quattro livelli di criticità:

• Livello 0 (fermo produzione immediato): ERP gestionale - ordini, magazzino, DDT, fatturazione elettronica. Senza questo sistema i 14 operatori di magazzino non possono evadere ordini, i 6 commerciali non possono emettere offerte, e l'amministrazione non può fatturare. Impatto stimato: 100% della capacità operativa bloccata entro 2 ore dal fermo
• Livello 1 (degrado operativo grave entro 4 ore): server di posta e PEC, applicativo web B2B per i clienti. I clienti non possono inserire ordini, l'azienda non può comunicare con PA e fornitori
• Livello 2 (degrado operativo moderato entro 24 ore): NAS documentale, sistema di stampa etichette, VPN per i commerciali in mobilità
• Livello 3 (impatto differibile): sito web istituzionale, sistema di ticketing interno, software di time tracking

Questa classificazione non è un esercizio accademico - è il documento da cui derivano direttamente le priorità di ripristino in caso di incidente. Senza questa mappa, durante un attacco ransomware reale il team IT (che in una PMI di 60 dipendenti spesso è una sola persona, il "responsabile IT" che gestisce anche le stampanti e i telefoni VoIP) tenterebbe di ripristinare tutto contemporaneamente, non riuscendo a ripristinare nulla in tempi utili. La guida #StopRansomware pubblicata da CISA e dal Joint Ransomware Task Force indica esplicitamente che il primo passo di qualsiasi piano di risposta è identificare e classificare i servizi mission-critical per definire le priorità di recovery. Non è un suggerimento - è il fondamento operativo su cui si costruisce tutto il resto.

Quanto costa realmente un'ora di downtime per una PMI manifatturiera?

Il costo non è mai solo il fatturato perso. È la somma di cinque componenti che la maggior parte dei titolari non contabilizza fino a quando non ci si trova dentro: il mancato fatturato diretto (ordini non evasi, consegne non partite), il costo del personale fermo ma retribuito, le penali contrattuali per ritardi nelle consegne, il danno reputazionale verso i clienti B2B che non possono tracciare i propri ordini, e i costi di ripristino tecnico che includono consulenza d'emergenza, hardware sostitutivo e overtime del personale IT.

Per l'azienda della simulazione, ho calcolato il costo orario del downtime totale partendo dai dati reali di bilancio: fatturato annuo 8 milioni di euro su circa 230 giorni lavorativi equivale a circa 34.800 euro al giorno, ovvero 4.350 euro l'ora di capacità produttiva. A questo ho aggiunto il costo del personale inattivo (60 dipendenti con un costo medio lordo aziendale di 35 euro l'ora producono 2.100 euro l'ora di costo fisso che continua a maturare durante il fermo) e una stima conservativa delle penali contrattuali basata sugli SLA dichiarati ai clienti principali. Il totale: circa 7.200 euro per ogni ora di downtime completo. In 18 ore - il tempo minimo stimato per ripristinare i sistemi di Livello 0 - il danno economico diretto superava i 129.000 euro. In 40 ore, necessarie per un ripristino completo, si arrivava a quasi 290.000 euro, senza contare il costo della consulenza d'emergenza e del ripristino tecnico.

Questi numeri non sono anomali. I dati aggregati del 2025 indicano che il tempo medio di recovery da un attacco ransomware per le PMI è di 24 giorni, con un costo medio di downtime che per le aziende di fascia media supera i 350.000 dollari al giorno. Il dato ancora più preoccupante è che l'87% delle PMI non dispone di un piano di incident response strutturato, il che significa che quei 24 giorni si allungano ulteriormente per assenza di procedure, ruoli definiti e priorità documentate. Nel mio lavoro di consulenza sulla sicurezza infrastrutturale, trovi il dettaglio delle competenze che porto in questi scenari nel mio profilo professionale, e questo tipo di simulazione preventiva è esattamente il genere di intervento che permette di scoprire queste criticità prima che un attaccante le sfrutti.

RTO e RPO: le due metriche che decidono se l'azienda sopravvive

RTO (Recovery Time Objective) è il tempo massimo accettabile per ripristinare un sistema dopo un incidente. RPO (Recovery Point Objective) è la quantità massima di dati che l'azienda può permettersi di perdere, misurata in tempo trascorso dall'ultimo backup utilizzabile. Sono le due metriche fondamentali di qualsiasi piano di disaster recovery, e nel caso dell'azienda manifatturiera erano entrambe fuori controllo.

L'RTO dichiarato informalmente dal responsabile IT era "qualche ora". L'RTO reale, misurato durante la simulazione, era 18 ore per i sistemi di Livello 0. Il divario nasceva da tre fattori che trovo sistematicamente in ogni PMI che non ha mai testato il proprio piano di ripristino: primo, il tempo di identificazione dell'incidente (quanto passa dal momento della cifratura a quando qualcuno se ne accorge e inizia ad agire) era stimato in 2-4 ore, perché nessun sistema di monitoring generava allarmi automatici; secondo, il ripristino del gestionale ERP richiedeva una reinstallazione completa del sistema operativo, del database MySQL e dell'applicativo, perché non esisteva un'immagine disco pronta; terzo, la connessione internet dell'azienda (100 Mbit simmetrici) richiedeva circa 6 ore per scaricare il backup completo del database dal provider cloud dove era conservato.

Ma il problema peggiore era l'RPO. Il backup del gestionale ERP veniva eseguito ogni notte da un cronjob che scriveva un dump MySQL su un NAS nella stessa rete locale. Il NAS, collegato allo stesso dominio Active Directory dei PC degli utenti, sarebbe stato cifrato insieme a tutto il resto in uno scenario ransomware reale - rendendo il backup locale completamente inutile. L'unico backup offsite era una copia settimanale caricata su un object storage cloud, ma il job di upload si era silenziosamente interrotto tre settimane prima per un errore di autenticazione scaduta. Nessuno se ne era accorto perché nessuno monitorava lo stato dei backup. Il risultato: RPO reale di 21 giorni, contro un RPO dichiarato di "una notte". In termini di business, significava perdere tre settimane di ordini, fatture, movimenti di magazzino e corrispondenza PEC - un danno che avrebbe richiesto settimane di lavoro manuale per ricostruire parzialmente, con la certezza che una parte dei dati sarebbe andata persa per sempre.

Il NIST IR 8374 sulla gestione del rischio ransomware, aggiornato nel 2025 per allinearsi al Cybersecurity Framework 2.0, raccomanda esplicitamente tre azioni fondamentali: sviluppare e testare regolarmente un piano di recovery con ruoli definiti, implementare e verificare una strategia di backup con copie isolate dalla rete di produzione, e mantenere una lista aggiornata di contatti interni ed esterni per la gestione degli incidenti. L'azienda della simulazione non soddisfaceva nessuno di questi tre requisiti. Questo tipo di lacune - monitoring assente, backup non verificati, assenza di alerting sullo stato dei job - è esattamente ciò che copre la checklist di hardening NIS2-ready per applicazioni e infrastruttura PMI che ho descritto in un articolo dedicato, perché il primo livello di resilienza al ransomware non è il software antivirus: è la disciplina operativa quotidiana.

La regola 3-2-1-1-0 e il backup air-gap: ricostruire la resilienza

Dopo la fase di assessment, ho implementato un'architettura di backup che segue la regola 3-2-1-1-0, lo standard de facto raccomandato da Veeam nella propria documentazione tecnica sulla resilienza dei dati e adottato come best practice da CISA e dalla maggior parte dei framework di sicurezza: tre copie dei dati, su due tipi di media diversi, una copia offsite, una copia immutabile o air-gapped, zero errori verificati nei test di ripristino.

In pratica, per l'azienda manifatturiera l'implementazione ha significato una revisione completa dello stack di backup. Il vecchio cronjob che scriveva un dump MySQL sul NAS locale è stato sostituito da uno script che cifra il backup alla sorgente, lo carica su un object storage con retention lock attivo, e verifica l'integrità della copia remota prima di dichiarare il job completato:

#!/bin/bash
# Script di backup notturno ERP - versione post-simulazione
# Esegue dump MySQL, comprime, cifra e carica su storage immutabile

set -euo pipefail

BACKUP_DIR="/var/backups/erp"
DATE=$(date +%Y%m%d_%H%M%S)
DB_NAME="erp_produzione"
GPG_RECIPIENT="[email protected]"
S3_BUCKET="s3://backup-erp-immutable"

# Dump MySQL con lock minimo grazie a --single-transaction (InnoDB)
mysqldump --single-transaction --routines --triggers \
  "${DB_NAME}" | gzip > "${BACKUP_DIR}/${DB_NAME}_${DATE}.sql.gz"

# Cifratura con chiave GPG dedicata al backup
gpg --encrypt --recipient "${GPG_RECIPIENT}" \
  "${BACKUP_DIR}/${DB_NAME}_${DATE}.sql.gz"

# Upload su object storage con retention lock di 30 giorni
# Il bucket ha Object Lock abilitato: nessuno può cancellare o sovrascrivere
aws s3 cp "${BACKUP_DIR}/${DB_NAME}_${DATE}.sql.gz.gpg" \
  "${S3_BUCKET}/${DATE}/" \
  --storage-class STANDARD_IA

# Pulizia locale: mantieni solo gli ultimi 7 giorni
find "${BACKUP_DIR}" -name "*.sql.gz*" -mtime +7 -delete

# Verifica integrità: confronta dimensione locale e remota
REMOTE_SIZE=$(aws s3 ls "${S3_BUCKET}/${DATE}/" | awk '{print $3}')
LOCAL_SIZE=$(stat -c%s "${BACKUP_DIR}/${DB_NAME}_${DATE}.sql.gz.gpg")

if [ "${REMOTE_SIZE}" -ne "${LOCAL_SIZE}" ]; then
  echo "ERRORE: dimensione backup remoto non corrisponde al locale" >&2
  # Invio alert via webhook al canale di monitoring
  curl -s -X POST "https://hooks.monitoring.local/backup-alert" \
    -H "Content-Type: application/json" \
    -d "{\"status\": \"FAILED\", \"db\": \"${DB_NAME}\", \"date\": \"${DATE}\"}"
  exit 1
fi

echo "Backup completato e verificato: ${DB_NAME}_${DATE}"

Il punto critico dell'architettura non è lo script in sé - è la separazione delle credenziali e dell'accesso. L'account che gestisce il bucket di backup immutabile ha credenziali dedicate, conservate in un password manager accessibile solo al responsabile IT e a me come consulente esterno, mai salvate in chiaro sul server di produzione. Il server di produzione usa un ruolo IAM con permessi di sola scrittura (s3:PutObject) e nessun permesso di cancellazione o modifica. Questo significa che anche se un attaccante ottiene accesso root al server, non può cancellare o sovrascrivere i backup esistenti sullo storage cloud - il retention lock a livello di object storage lo impedisce a livello di protocollo, indipendentemente dai permessi dell'utente. I dati del 2025 confermano la criticità di questo approccio: l'89% delle vittime di ransomware ha subìto un tentativo di compromissione dei propri repository di backup, e il 58% delle aziende che hanno pagato il riscatto ha comunque subìto perdita parziale o totale dei dati.

La seconda copia air-gapped è un disco USB esterno cifrato con LUKS che il responsabile IT porta fisicamente fuori sede ogni venerdì. È una soluzione a bassa tecnologia, quasi arcaica, ma è l'unica che garantisce un'immunità totale a qualsiasi attacco software: un disco scollegato dalla rete e chiuso in un cassetto non può essere cifrato da un ransomware. Il costo di due dischi USB da 4 TB ciascuno (uno in sede, uno fuori sede, in rotazione settimanale) è stato di 180 euro. Il costo dell'assenza di questa misura, in caso di attacco reale, sarebbe stato nell'ordine delle centinaia di migliaia di euro.

Il piano di risposta: chi fa cosa nei primi 60 minuti

Un piano di incident response che nessuno conosce e nessuno ha mai praticato è esattamente equivalente a non avere un piano. La parte finale della simulazione è stata la costruzione di un documento operativo di risposta - non un manuale di 80 pagine che nessuno leggerà mai, ma un runbook di due facciate A4 plastificate, appeso fisicamente accanto al quadro elettrico del rack server e salvato in formato PDF sul telefono del direttore generale, del responsabile IT e del mio contatto di emergenza.

Il runbook è organizzato in blocchi temporali:

Primi 15 minuti (contenimento): chi scopre l'anomalia chiama il responsabile IT e il direttore generale. Il responsabile IT isola fisicamente i segmenti di rete coinvolti (stacca i cavi di uplink dagli switch, non spegne i server - i dati in RAM possono essere utili per la forensics). Nessuno tenta di "pulire" o "ripristinare" nulla in questa fase. Viene attivato il canale di comunicazione alternativo (un gruppo Signal pre-configurato, non l'email aziendale che potrebbe essere compromessa).

Dai 15 ai 60 minuti (valutazione e triage): il responsabile IT verifica l'estensione del danno - quali sistemi sono cifrati, quali sono ancora intatti, quali backup sono raggiungibili. Contatta il consulente di sicurezza esterno (nel runbook c'è il mio numero diretto, quello del mio backup e quello di un secondo consulente di fallback). Viene avviata la comunicazione verso il legale aziendale per valutare gli obblighi di notifica: il GDPR impone la comunicazione al Garante Privacy entro 72 ore se c'è stata violazione di dati personali, e la direttiva NIS2 aggiunge obblighi di notifica per le aziende che rientrano nel perimetro dei soggetti essenziali o importanti.

Dalla prima ora in poi (ripristino prioritizzato): il ripristino segue esattamente l'ordine della mappa di criticità costruita nella prima fase della simulazione. Prima il gestionale ERP (Livello 0), poi posta e PEC e applicativo web B2B (Livello 1), infine i sistemi secondari. Ogni ripristino viene verificato con un test funzionale minimo prima di passare al sistema successivo. Ho descritto in dettaglio il framework di incident response allineato a NIS2 nel mio articolo dedicato alla gestione delle prime 72 ore di un incidente di sicurezza su applicazioni Laravel e Symfony, che copre anche gli aspetti di forensics e comunicazione normativa che qui tocco solo in superficie.

Il test più importante della simulazione è stato quello che nessuno voleva fare: il tabletop exercise. Ho riunito il direttore generale, il responsabile IT, il responsabile amministrativo e un commerciale senior in una sala riunioni per due ore. Ho descritto uno scenario - "Sono le 7:45 di lunedì mattina, il primo dipendente che arriva accende il PC e vede un file README_RANSOM.txt sul desktop. I file sono rinominati con estensione .locked. Cosa fate?" - e li ho lasciati reagire. I primi dieci minuti sono stati caotici: nessuno sapeva chi doveva fare cosa, il responsabile IT ha detto "spengo tutto", il direttore generale ha detto "chiamo la polizia postale", il commerciale ha detto "avviso i clienti". Ho fermato l'esercizio e abbiamo ricominciato seguendo il runbook. La seconda iterazione è stata ordinata, sequenziale, efficace. Quella è stata la prova che il piano funzionava - non perché era scritto bene, ma perché era stato praticato almeno una volta dalle persone che avrebbero dovuto eseguirlo sotto pressione.

Tre mesi dopo la simulazione, ho condotto un secondo tabletop exercise senza preavviso. Il tempo di reazione del team è passato da "caos per dieci minuti" a "contenimento iniziato entro tre minuti". Il responsabile IT aveva memorizzato la sequenza di isolamento della rete. Il direttore generale sapeva che la prima chiamata era al consulente di sicurezza, non alla polizia postale. Il commerciale sapeva che la comunicazione ai clienti avveniva solo dopo la valutazione dell'estensione del danno, non prima. Questo è il valore di una simulazione: non il documento che produce, ma il muscolo mentale che allena nelle persone che dovranno agire quando la pressione sarà reale e il tempo misurato in minuti, non in giorni.

L'investimento totale per l'intera operazione - cinque giorni di consulenza per la simulazione e l'assessment, implementazione dell'architettura di backup 3-2-1-1-0, stesura del runbook, due tabletop exercise - è stato nell'ordine di poche migliaia di euro. Il costo di un singolo giorno di downtime reale, come abbiamo calcolato, supera i 50.000 euro. Il rapporto costo-beneficio non è un'opinione - è aritmetica. Se la tua azienda ha un gestionale, un database clienti e una posta elettronica che sono essenziali per le operazioni quotidiane, e non hai mai testato cosa succederebbe se domani mattina tutto fosse cifrato, il momento di farlo è adesso, non dopo l'incidente. Ho costruito un framework completo di disaster recovery per applicazioni PHP e infrastrutture PMI che dettaglia anche gli aspetti di ripristino applicativo e i pattern di automazione che qui ho solo accennato. Se vuoi capire come si applica uno scenario di simulazione alla tua realtà specifica, con numeri reali calcolati sui tuoi sistemi e sul tuo modello di business, contattami per una valutazione: il primo passo è sempre una conversazione di trenta minuti in cui mappiamo insieme i tuoi sistemi critici e le tue dipendenze operative, senza impegno e senza vendita di soluzioni preconfezionate.