In che modo si progetterebbe la sicurezza in dispositivi industriali con connessione in rete e in esecuzione per decenni in cui il malfunzionamento potrebbe costare la vita? [chiuso]

Il tuo "primo passo" è in realtà la trappola in cui è caduto l'industria. Credendo che ci sia un modo per mettere online questi sistemi senza una conoscenza approfondita del dominio di sicurezza, e senza fornire un modo per aggiornare i componenti di sicurezza senza compromettere l'integrità del resto dei sistemi, si sono intrappolati con dipendenze di processi su antiche , protocolli insicuri. Con ciò intendo che offrivano la promessa di una manutenzione a basso costo controllata a distanza, eliminando così la necessità che costosi esperti si recassero in siti remoti. Ridussero il numero di teste; che si sono lasciati completamente dipendenti dai sistemi di controllo remoto. Non possono chiuderli ora anche di fronte a un'emergenza di sicurezza informatica, perché dipendono da quel controllo per tenerli in esecuzione.

Il primo passo è quello di separare i componenti di Internet dal resto dei sistemi. Lasciare il controller di sistema online e sperare che la sua pagina di accesso integrata dal 2003 lo tenga al sicuro è un fallimento.

Poiché le reti SCADA sono così vulnerabili, l'intero ICN deve essere protetto da firewall da ogni altro sistema; compresi altri sistemi e reti interni. Vedi te stesso come l'operatore SCADA e presumi che tutti gli altri membri della tua organizzazione, inclusi amministratori di sistema e amministratori di rete, stiano tentando di hackerare la tua rete SCADA, quindi difenderlo.

Può darsi che tu non abbia una difesa adeguata, o che il rischio di compromessi sia troppo grande in termini di sicurezza. Un traferro è l'ultima, la migliore difesa; anche allora, non è perfetto. Stuxnet è stato un esempio di un attacco ICN che ha saltato il traferro usando un exploit di 0 giorni su un'unità USB.

Non incorporare la parte Internet del software nel dispositivo stesso. Idealmente il dispositivo dovrebbe avere solo un software semplice (in esecuzione su un microcontrollore) responsabile delle funzioni di base del dispositivo (come prima di controllare gli interblocchi di sicurezza prima attivare le cose pericolose o gestire le funzionalità che richiedono tempi precisi) e comunicare con il mondo esterno tramite un'interfaccia semplice e standard come una porta seriale.

Tutto il resto dovrebbe essere gestito tramite software sviluppato per un sistema operativo generico, in modo che possa essere aggiornato indipendentemente dal fornitore (stranamente, in realtà consiglierei Windows per questo - la sua retrocompatibilità è piuttosto buona, posso ancora funzionare Il software XP-era su Windows 8.1) piuttosto che legare il software a un intero sistema operativo che non può essere aggiornato una volta che il fornitore non fornisce aggiornamenti. Anche il protocollo per comunicare con il dispositivo deve essere pubblicato in modo che una terza parte possa reimplementare il software originale qualora non fosse più possibile eseguire su un sistema operativo moderno.

Anche i costi ricorrenti per mantenere il dispositivo sicuro (inclusa la riscrittura del software se necessario) devono essere considerati nel costo totale di proprietà / manutenzione del dispositivo.

Infine, non mettere le cose su Internet se non lo richiedono - è un rischio contro una situazione di compromesso in quanto nessun software è sicuro, e in questo caso direi che mettere il dispositivo su Internet dovrebbe essere una soluzione di ultima istanza a causa del costo di un compromesso (una perdita di vita umana non può essere espressa in $$$), e se si è deciso di mettere il dispositivo in rete occorre adottare le dovute precauzioni, come nasconderlo dietro un gateway VPN e formazione degli utenti sulle pratiche di sicurezza corrette (ho visto molti dispositivi SCADA con password predefinite, il che significa che non è più un problema tecnico ma umano)