A cura di Lorenzo Dina

Nelle piccole e medie realtà produttive italiane — che si tratti di automazione, packaging, food & beverage o metalmeccanica — le priorità sono chiare: sicurezza degli operatori, continuità operativa, e affidabilità dell’impianto.

Un fermo impianto non pianificato, anche di poche ore, può costare decine di migliaia di euro tra scarti, penali e mancata produzione — molto più di qualsiasi investimento preventivo in sicurezza.

Quando si parla di digital forensics, la reazione tipica dell’imprenditore o del responsabile di stabilimento è di distacco: “Roba da grandi aziende”, “Cose da CSI”, o peggio, “Problemi che affronteremo se mai succederà qualcosa”.

Tuttavia, nel contesto attuale in cui il mondo industriale è sempre meno isolato e più connesso all’esterno, questo approccio è rischioso. La forensic readiness non è un’attività investigativa post-incidente, ma uno strumento difensivo e preventivo. È, a tutti gli effetti, una forma di “manutenzione digitale” che permette di:

• Ridurre drasticamente i tempi di fermo impianto in caso di incidente.
• Limitare l’impatto legale e assicurativo.
• Rispondere ai nuovi obblighi di compliance europea.

di seguito una breve analisi di come applicare i concetti di Forensic readiness all’interno di una PMI italiana senza stravolgere l’architettura esistente.

Cos’è la forensic readiness (spiegata facile)

Dimentichiamo per un attimo i termini complessi. Forensic readiness significa semplicemente: essere in grado di raccogliere dati affidabili, integri e completi senza dover improvvisare quando qualcosa va storto.

In un contesto industriale (OT), questo si traduce in quattro capacità operative:

1. Sapere esattamente dove vengono salvati i log dei macchinari e per quanto vengono conservati.
2. Sapere chi sta comunicando con chi all’interno della rete di impianto.
3. Poter ricostruire una timeline degli eventi (chi ha fatto cosa e quando).
4. Farlo senza spegnere l’impianto o interrompere la produzione.

Non si tratta di fare analisi forensi tutti i giorni. Si tratta di progettare e/o gestire l’infrastruttura ICS/OT oggi affinché, domani, la root cause analysis (RCA) sia tecnicamente possibile e accurata. È come installare una scatola nera su un aereo: speri di non doverla mai aprire, ma se serve, deve esserci e deve aver registrato tutto.

Perché sta diventando necessaria: CRA + NIS2

Il panorama normativo sta cambiando rapidamente. Il Cyber Resilience Act (CRA) è un regolamento UE che introduce requisiti di sicurezza stringenti per qualsiasi prodotto con elementi digitali. Questo impatta direttamente su:

• Dispositivi IIoT (Industrial IoT).
• Gateway e router industriali.
• Pannelli operatore (HMI).

La NIS2 è la direttiva (UE) 2022/2555 che introduce obblighi di risk management e incident reporting in tempi brevi per soggetti classificati come “essenziali” e “importanti” in settori definiti.

Per una PMI, il messaggio importante, depurato dal “legalese”, è: se succede un incidente e non si riesce a dimostrare chi ha fatto cosa e quando, si è automaticamente in posizione di svantaggio, anche se non si ha colpa. Diventa quindi (molto) più difficile stare sul mercato senza evidenze tecniche, soprattutto per OEM e integratori; per le PMI utilizzatrici, la pressione arriverà via filiera/assicurazioni/contratti.

Questa incapacità di ricostruzione ha conseguenze immediate su:

• Responsabilità contrattuali: Se un macchinario connesso causa un difetto di produzione, un fermo o un incidente di sicurezza, di chi è la colpa? Del fornitore, dell’integratore o dell’operatore? Senza dati forensi, il contenzioso è assicurato, il risultato incerto.
• Assicurazioni cyber: Le polizze richiedono sempre più spesso evidenze di “due diligence” prima di sottoscrivere la polizza e la verificano dopo in caso di liquidazione di sinistro.
• Audit di filiera: I grandi clienti industriali pretendono standard di sicurezza elevati dai loro fornitori e una gestione del rischio delle terze parti e della catena di fornitura.

Forensic Readiness: perché l’OT non è l’IT (e come gestirlo)

L’errore più grave che è spesso commesso nelle PMI è tentare di applicare le logiche IT (ufficio) all’ambiente OT (fabbrica). Questo è il punto in cui molte iniziative di sicurezza OT falliscono già in fase di progetto.

In un ufficio, se un PC è sospetto, è possibile isolarlo, spegnerlo e farne una acquisizione forense tutto anche in maniera automatica secondo un playbook. In fabbrica:

• Non è possibile spegnere un PLC senza fermare la linea o una sua parte (con costi enormi).
• Non è possibile installare “agent” di sicurezza sulla maggior parte dei dispositivi.
• Non è possibile fare scansioni aggressive della rete, perché si rischierebbe di mandare in crash sistemi deterministici sensibili alla latenza.

La forensic readiness industriale deve essere passiva e non intrusiva. Si basa su tre pilastri fondamentali.

Pilastro 1 – Logging minimo ma utile

Non serve un SIEM (Security Information and Event Management) da multinazionale. Servono pochi log, ma quelli giusti, salvati in maniera persistente e raccolti dai punti nevralgici :

1. Gateway / IPC / Edge Device: Spesso sono basati su Linux, a volte sono obsoleti. Devono tracciare login (riusciti e falliti), riavvii, aggiornamenti firmware e, soprattutto, le connessioni remote (VPN di teleassistenza).
2. HMI (Pannelli Operatore): Molti HMI moderni hanno la funzione Audit Trail che registra chi ha premuto cosa, modifiche ai set-point o ai parametri. Nelle PMI spesso questa funzione è disattivata. Attivare la funzione, ove possibile, fornisce una grande visibilità sulle azioni eseguite prima dell’incidente.
3. PLC: Anche se limitati, registrare i cambi di stato (es. da RUN a STOP), i download di nuovi programmi o gli errori critici è essenziale.

Pilastro 2 – Tracciabilità temporale (il tempo è tutto)

Si immagini un incidente dove un dispositivo ci dice che l’attacco è iniziato alle 10:00, ma il PLC registra il fermo alle 09:50 perché gli orologi non sono allineati. L’indagine si complica ben prima di iniziare, in alcuni casi finisce per impossibilità di conciliare le timeline.

A questo si aggiunge un problema meno evidente ma estremamente rilevante in ambito OT: il cosiddetto Epochalypse, ovvero il rollover del tempo al 19 gennaio 2038.
Molti dispositivi industriali (PLC, RTU, gateway embedded) utilizzano ancora rappresentazioni del tempo basate su time_t a 32 bit. Quando il contatore supererà il limite, l’orologio tornerà indietro al 1901 o a valori incoerenti, generando:

• timestamp errati o negativi nei log,
• eventi apparentemente “nel futuro” o “nel passato”,
• perdita totale dell’affidabilità temporale delle evidenze.

In ottica forense questo significa una cosa molto chiara:

• un sistema non sincronizzato oggi è un problema;
• un sistema non epoch-safe domani è una prova inutilizzabile.

La best practice consiste nell’utilizzare protocolli di sincronizzazione del tempo coerenti con il dominio temporale di riferimento, quali:

• PTP (Precision Time Protocol) per reti industriali ad alta precisione,
• SNTP (Simple Network Time Protocol) per dispositivi embedded,
• NTP (Network Time Protocol) per gateway e sistemi IT/OT di supervisione,
• meccanismi di sincronizzazione integrati nei protocolli industriali (es. PROFINET, EtherCAT, EtherNet/IP).

È fondamentale assicurarsi che gateway, HMI, server SCADA, sistemi di supervisione e telecamere derivino l’orario dalla stessa fonte fidata, tipicamente:

• un server NTP/PTP interno,
• sincronizzato a una sorgente primaria esterna (GNSS, time server certificato),
• con dispositivi verificati rispetto al supporto post-2038.

Senza una sincronizzazione coerente — e senza la consapevolezza dei limiti di capacità tecnica dei dispositivi di gestire il tempo — la correlazione degli eventi diventa impossibile e la validità forense delle evidenze può essere compromessa, anche in assenza di un attacco sofisticato.

Pilastro 3 – Network visibility passiva

Poiché molti dispositivi industriali (PLC vecchi, sensori, attuatori) non producono log utili, la rete diventa l’unica fonte di verità.

Si configura lo switch centrale per “copiare” il traffico che passa verso il PLC o il Gateway e inviarlo a una porta dove è collegata una sonda (o dove potrà collegarsi l’analista forense).

• Vantaggio: È completamente invisibile al processo produttivo. Non rallenta la rete e non tocca i macchinari.
• Cosa cercare: Traffico anomalo tra PLC e HMI, o connessioni verso l’esterno in orari anomali.

I benefici concreti: oltre la burocrazia

Implementare questi pilastri porta vantaggi tangibili, non solo teorici:

• Prima dell’incidente: Acquisire una conoscenza reale dell’impianto. Spesso si scoprono configurazioni “oscure” o fornitori che hanno accessi remoti sempre aperti senza che la proprietà lo sappia.
• Durante l’incidente: Meno panico. Invece di urlare “Spegnete tutto!” (cancellando le prove e danneggiando la produzione), si possono prendere decisioni basate su quanto documentato e noto.
• Dopo l’incidente: Si ottiene una ricostruzione credibile da presentare ad assicurazioni, legali e clienti. I tempi di ripristino si accorciano perché è più facile capire esattamente cosa è stato toccato.

La checklist minimale per la PMI

Per supportare le PMI abbiamo predisposto un punto di partenza rapido per fare una prima valutazione. Se anche solo una di queste risposte è “non lo so”, non è un fallimento: è il punto corretto da cui partire:

• Inventario: Conosco quali dispositivi sono critici per la produzione?
• Log: Traccio e gestisco dove finiscono i log dei gateway e degli HMI? Sono salvati su una memoria non volatile?
• Tempo: I sistemi hanno orari coerenti e sincronizzati?
• Visibilità: Posso osservare il traffico di rete senza staccare cavi?
• Accessi: So esattamente chi può accedere da remoto (teleassistenza) e quando lo fa?

Perché dovreste iniziare oggi

La forensic readiness non è un lusso per pochi. È l’equivalente digitale di avere estintori carichi e uscite di sicurezza libere. Per una PMI manifatturiera italiana significa passare dalla speranza che non accada nulla alla capacità concreta di gestire l’imprevisto senza paralizzare l’impianto.

Investire oggi nella forensic readiness costa una frazione rispetto al costo di un fermo non gestito. Ma soprattutto riduce il tempo necessario per capire cosa è successo, decidere cosa fare e ripartire. In un contesto regolatorio e di filiera sempre più esigente, non poter dimostrare “chi ha fatto cosa e quando” equivale a perdere controllo negoziale.

I controlli critici per la cybersecurity ICS/OT indicati dal SANS Institute sottolineano proprio questo: visibilità, raccolta strutturata dei log e capacità di analisi a posteriori non sono attività opzionali, ma prerequisiti di resilienza operativa. Senza dati affidabili e temporalmente coerenti, la root cause analysis diventa fragile — e con essa ogni decisione tecnica, legale o assicurativa.

In ambito industriale, la sicurezza non è solo prevenzione. È la capacità di ricostruire i fatti, dimostrarli e ripartire rapidamente, anche quando non è immediatamente evidente che si sia trattato di un attacco informatico.

 

[recent_post_slider limit=”5″]