File in ambito OT: scansionare una volta sola all'ingresso non basta

Il 9 novembre 2026 IIoT World ha pubblicato un contributo contrassegnato come "Sponsored by Opswat", che riassume un articolo del blog di OPSWAT. La tesi: nei siti OT la scansione di un file al punto di ingresso non è sufficiente, perché l'integrità deve essere garantita fino al momento in cui il file raggiunge un PLC o un HMI. Va letto come contenuto di parte, ma solleva un punto concreto per chi lavora in automazione.

Il vuoto tra approvazione e distribuzione

Secondo l'articolo, i siti OT di solito scansionano e approvano i file all'ingresso: firmware dei fornitori, patch dei contractor, aggiornamenti di configurazione. Dopo l'approvazione, però, i team di sicurezza perdono visibilità fino all'arrivo del file sul dispositivo di destinazione.

Il problema è aggravato dai dispositivi datati. PLC, HMI e workstation di ingegneria legacy non possono eseguire agenti EDR e non sono in grado di verificare che il file ricevuto corrisponda a quello approvato. Una volta collegato il dispositivo, i file sono accessibili per impostazione predefinita.

Che cosa dimostra davvero una scansione

Un file modificato dopo la verifica, per errore o intenzionalmente, appare identico a uno non modificato: il record della scansione resta valido e l'approvazione resta registrata. Nelle parole di OPSWAT, la scansione dimostra che il file era pulito in un dato momento, non che sia ancora lo stesso file al momento del deployment. Confermare che il file non sia cambiato dall'approvazione al deployment viene definito essenziale nei settori regolamentati.

Affidarsi al fatto che ogni operatore segua ogni passaggio in ogni sito è un'ipotesi di processo, non un controllo di sicurezza.

La soluzione proposta e i requisiti elencati

OPSWAT propone MetaDefender Drive con Smart Touch, basato su Secure File Storage. I file copiati da dispositivi di fornitori o contractor restano isolati finché non superano la verifica in un MetaDefender Kiosk. Se un file verificato viene modificato prima del deployment, viene bloccato e nascosto automaticamente fino a una nuova verifica. Il modello passa così da "scansiona una volta e distribuisci" a "verifica in modo continuo fino al deployment".

Tra gli altri requisiti indicati:

• verificare i dispositivi di contractor e supply chain prima che si colleghino;
• applicare politiche di ispezione coerenti tra i siti, con gestione centralizzata;
• gestire la distribuzione del firmware in ambienti air-gapped;
• mantenere registrazioni pronte per gli audit.

Limiti da tenere presenti

Prima di trarre conclusioni conviene considerare alcuni caveat:

• l'articolo non fornisce dati di incidenti né numeri;
• non menziona hash, firme digitali o blockchain;
• le affermazioni sul prodotto sono del fornitore e non sono verificate in modo indipendente;
• è un pezzo di sicurezza più che di automazione, e il legame con l'integrità dei dati è solo parziale.

Indicazione pratica

Il principio è valido indipendentemente dal prodotto. Chi distribuisce programmi PLC, progetti HMI o firmware può chiudere il vuoto con un controllo di hash o di firma nel momento del deployment, confrontando il file con quello approvato. Questo non richiede per forza una piattaforma commerciale e produce anche una traccia di audit utile nei siti regolamentati.

In sintesi: registrare l'impronta del file all'approvazione, verificarla subito prima del caricamento e conservare l'esito. Così il controllo non dipende dalla disciplina del singolo operatore, ma diventa parte del processo.