File verificati, rischio reale: l'integrità in OT va garantita fino al deploy

Il 9 novembre 2026 IIoT World ha pubblicato un articolo contrassegnato come "Sponsored by Opswat" che riprende un post del blog di OPSWAT. La tesi: controllare i file una sola volta all'ingresso della rete OT lascia scoperto il tratto più delicato, quello tra l'approvazione e l'installazione su un PLC o un HMI. Trattandosi di contenuto di matrice commerciale, senza dati di incidenti, statistiche o validazioni indipendenti, va letto come un'argomentazione del fornitore, non come evidenza di mercato.

Il vuoto tra scansione e deploy

Nella pratica, in molti siti industriali firmware dei fornitori, patch degli appaltatori e aggiornamenti di configurazione vengono scansionati al punto di ingresso e l'approvazione viene registrata. Da lì in poi, però, i team di sicurezza perdono visibilità fino a quando il file arriva a destinazione.

Se nel frattempo il file viene modificato, per errore o per manomissione, non è distinguibile da uno intatto: il rapporto di scansione resta valido e l'approvazione resta a registro. Una scansione dimostra che il file era pulito in un dato momento, non che sia lo stesso file nel momento in cui viene installato.

Perché i sistemi legacy non possono colmarlo da soli

PLC, HMI e workstation di ingegneria datate non possono eseguire agenti EDR e non sono in grado di verificare che il file in arrivo corrisponda a quello approvato. Una volta collegato il dispositivo, i file sono accessibili di default. L'articolo lo riassume così:

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

La soluzione proposta

OPSWAT propone MetaDefender Drive con Smart Touch e Secure File Storage. I file copiati da dispositivi di fornitori o appaltatori restano isolati finché non superano la verifica a un MetaDefender Kiosk. Se un file verificato viene modificato prima del deploy, 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 deploy". Le prestazioni dichiarate del prodotto non sono state verificate in modo indipendente.

Tra gli altri requisiti elencati dall'articolo:

• scansionare i dispositivi di appaltatori e supply chain prima che si colleghino all'OT;
• applicare politiche di ispezione coerenti sui siti distribuiti, con gestione centralizzata;
• gestire la distribuzione sicura del firmware in ambienti air-gapped;
• mantenere visibilità centralizzata e registri pronti per l'audit.

Cosa portarsi a casa

Il rischio si concentra nel passaggio di consegne tra approvazione e deploy. Per i produttori multi-sito, soprattutto nei settori regolamentati dove serve dimostrare che un file è rimasto invariato dall'approvazione all'installazione, è una domanda di audit concreta: oggi, in ciascuno dei nostri siti, come proviamo che il file installato è quello approvato?

Il principio non dipende da un singolo prodotto: controlli di integrità, come la verifica di hash o di firma al momento del deploy, applicati dal sistema e non lasciati alla disciplina dei singoli operatori. Un punto di partenza pragmatico è registrare l'hash del file al momento dell'approvazione, custodirlo separatamente dal supporto di trasferimento e confrontarlo prima dell'installazione, valutando poi se strumenti dedicati, di questo o di altri fornitori, servano a rendere il processo applicabile in modo uniforme.