¿Cómo se diseñaría la seguridad en dispositivos industriales con acceso a Internet / redes que funcionarán durante décadas donde el mal funcionamiento podría costar vidas? [cerrado]

Tu 'primer paso' es en realidad la trampa en la que cayó la industria. Al creer que hay una manera de poner estos sistemas en línea sin una comprensión profunda del dominio de seguridad, y sin proporcionar una manera de actualizar los componentes de seguridad sin comprometer la integridad del resto de los sistemas, se quedaron atrapados en las dependencias de procesos de los antiguos. , protocolos inseguros. Con eso, quiero decir que ofrecieron la promesa de un mantenimiento barato a control remoto, por lo que eliminaron la necesidad de que expertos costosos viajen a sitios remotos. Redujeron la cantidad de personas; Que se dejaron totalmente dependientes de los sistemas de control remoto. No pueden apagarlos ahora incluso ante una emergencia de seguridad cibernética, porque dependen de ese control para que sigan funcionando.

El primer paso es separar los componentes orientados a Internet del resto de los sistemas. Dejar el controlador del sistema en línea y esperar que su página de inicio de sesión integrada a partir de 2003 lo mantenga seguro es un fracaso.

Debido a que las redes SCADA son tan vulnerables, todo el sistema debe tener un cortafuegos de ICN; Incluyendo otros sistemas internos y redes. Mírate a ti mismo como el operador de SCADA y asume que todos los demás miembros de tu organización, incluidos tus administradores de sistemas y administradores de red, están intentando piratear tu red de SCADA, luego defiéndelo.

Puede ser que no tenga una defensa adecuada, o que el riesgo de compromiso sea demasiado grande en términos de seguridad. Un espacio de aire es la última, la mejor defensa; incluso entonces, no es perfecto. Stuxnet fue un ejemplo de un ataque de ICN que saltó el espacio de aire utilizando un exploit de 0 días en una unidad USB.

No incruste la parte del software orientada a Internet en el propio dispositivo. Lo ideal es que el dispositivo solo tenga un software simple (que se ejecute en un microcontrolador) que sea responsable de las funciones básicas del dispositivo (como verificar los bloqueos de seguridad antes activando cosas peligrosas o manejando características que requieren tiempos precisos) y se comunica con el mundo exterior a través de una interfaz simple y estándar como un puerto serie.

Todo lo demás debe manejarse a través de un software desarrollado para un SO de propósito general, para que pueda actualizarse independientemente del proveedor (por extraño que parezca, recomendaría Windows para esto; su compatibilidad con versiones anteriores es bastante buena, todavía puedo ejecutar El software de la era XP está bien en Windows 8.1) en lugar de vincular el software a un sistema operativo completo que no se puede actualizar una vez que el proveedor no proporciona las actualizaciones. Además, el protocolo para hablar con el dispositivo debe publicarse para que un tercero pueda volver a implementar el software original en caso de que ya no pueda ejecutarse en un sistema operativo moderno.

También los costos recurrentes para mantener seguro el dispositivo (incluida la reescritura del software si es necesario) deben tenerse en cuenta en el costo total de propiedad / mantenimiento del dispositivo.

Finalmente, no ponga las cosas en Internet si no lo requieren; es una situación de riesgo frente a un compromiso ya que ningún software es seguro, y en este caso diría que poner el dispositivo en Internet debería ser una solución de último recurso debido al costo de un compromiso (una pérdida de vidas humanas no puede expresarse en $$$), y si se decidió poner el dispositivo en la red, se deben tomar las precauciones adecuadas, como esconderlo detrás de una puerta de enlace VPN y capacita a los usuarios sobre las prácticas de seguridad correctas (he visto muchos dispositivos SCADA con contraseñas predeterminadas, lo que significa que ya no es un problema técnico sino humano)