I rischi nascosti legati alla distribuzione dei file negli ambienti OT

Nella maggior parte degli ambienti OT, l’inserimento di un file in un sistema critico segue una sequenza specifica di passaggi. Il processo ha inizio con l’arrivo di un fornitore con il firmware, di un appaltatore che porta una patch o di un team di manutenzione che esegue aggiornamenti di configurazione. I file vengono analizzati, approvati e consegnati. Tuttavia, in qualche fase tra queste procedure e il momento in cui il file raggiunge il PLC (controllore logico programmabile) o l’HMI (interfaccia uomo-macchina), i team di sicurezza ne perdono completamente traccia.

Per affrontare questa sfida vengono utilizzati diversi approcci. Le soluzioni basate sulla rete gestiscono il trasferimento dei file tra i sistemi IT e OT, mentre i flussi di lavoro basati su chioschi controllano i supporti rimovibili al punto di ingresso. Tuttavia, una parte del problema rimane costantemente irrisolta: si tratta di ciò che accade a un file dopo che è stato verificato, mentre è in transito verso il sistema critico.

La maggior parte degli operatori OT dispone di solidi flussi di lavoro di ispezione integrati. Di norma, i supporti rimovibili e i dispositivi temporanei vengono sottoposti a scansione prima di entrare nell’ambiente OT isolato e le approvazioni vengono registrate. Questi controlli sono necessari, ma presentano un limite comune: creano un unico momento di fiducia.

I sistemi OT legacy non sono stati progettati per verificare la provenienza dei dati che ricevono. I PLC, le interfacce HMI e le workstation di progettazione legacy in genere non sono in grado di eseguire agenti EDR (Endpoint Detection and Response) né di verificare che i file in entrata corrispondano alle approvazioni originali. Quando un dispositivo viene collegato, i file diventano accessibili per impostazione predefinita.

Queste limitazioni fanno sì che la sicurezza di ogni distribuzione di file in un sistema critico dipenda dal fatto che ogni operatore segua o meno le procedure di verifica manuale. Affidarsi al fatto che ogni operatore segua ogni fase in ogni sede è un presupposto procedurale, non un controllo di sicurezza.

La domanda dovrebbe ora passare da “questo file era integro al momento della scansione?” a “possiamo confermare che si tratti ancora dello stesso file nel momento in cui viene implementato nel sistema critico?”.

Nei settori soggetti a regolamentazione è fondamentale verificare che un file non abbia subito modifiche dal momento dell'approvazione fino alla distribuzione. Una volta che un file ha superato il controllo, deve esistere un meccanismo che consenta di verificare se abbia subito modifiche.

Negli ambienti OT, il problema rimane irrisolto, poiché la maggior parte dei flussi di lavoro attuali non dispone di un meccanismo per rilevare le modifiche successive alla verifica. Se un file viene modificato dopo la verifica a causa di un errore o di una manomissione deliberata, il sistema OT di destinazione non è in grado di rilevarlo. Il record di scansione rimane valido e l’approvazione viene comunque registrata. Un file che è stato verificato come sicuro tre giorni fa e che da allora è stato alterato appare identico a un file che è stato considerato sicuro tre giorni fa e che non è stato modificato. L’operatore che lo distribuisce non ha alcun modo affidabile per distinguere i due casi.

La verifica non si esaurisce con l'MetaDefender Kiosk . Se un file verificato viene modificato dopo la scansione e prima della distribuzione, viene automaticamente bloccato e nascosto. In tal caso, il file deve superare nuovamente la verifica prima di poter essere reso accessibile.

Questo meccanismo garantisce l'integrità dei file, evitando così all'operatore di doverla verificare manualmente. Ciò fa passare il modello di sicurezza da "scansione una tantum e distribuzione" a "verifica continua fino alla distribuzione".