¿Cuáles son las principales vulnerabilidades de seguridad en los sistemas SCADA para centros de datos y qué empresas se centran en desarrollar soluciones para estos problemas?

Dos excelentes respuestas aquí de Ron Brash y Jonathan Day. Déjame agregar un poco de color adicional:

Ya en la edad oscura, antes de que tu madre supiera qué era Internet o el correo electrónico, agregar automatización de computadoras para controlar los sistemas fue un movimiento económico brillante. Podría hacer que un programa de computadora abra un interruptor o cierre una válvula, en lugar de enviar a un tipo para que lo haga. Los enormes costos de implementación tuvieron reembolsos por debajo de los 12 meses, sin mencionar una mayor confiabilidad ya que las computadoras no “olvidan”, “simplemente deténgase para tomar una taza de café” o “tienen que ir al baño”.

Sin embargo, todos estos sistemas se desarrollaron de manera monolítica, una computadora para una planta (o un edificio en una planta). Típicamente hechos de minicomputadoras (DEC PDP-8, PDP-11, DataGeneral Nova, etc.) que ejecutan sistemas operativos “en tiempo real”, estos sistemas NO estaban conectados en red. Por lo general, tenían múltiples tarjetas con actuadores analógicos con líneas de par trenzado en cada punto final de control.

La segunda ola de automatización consistió en usar LAN para interconectar sistemas de control, y así “mejorar aún más la eficiencia” y aprovechar el uso de múltiples computadoras más pequeñas versus una computadora más grande, coordinadas a través de una red.

A principios de los años 80, una de mis tarjetas de llamadas era UNIX como SO en tiempo real, combinada con redes / computación distribuida. Recuerdo a un cliente importante que vino a buscar un sistema de control basado en UNIX. Restricciones de tiempo muy estrictas, no tolera en absoluto los retrasos. Recomiendo una arquitectura de red de token ring Proteon mucho más costosa, pero fue descartada por el cliente que seleccionó Ethernet porque “con solo unos pocos sistemas, ¿qué tan probable es una colisión y retransmisión de todos modos?”

Unos meses más tarde, la fábrica argentina de fertilizantes del cliente explotó y se quemó en el suelo debido a tal evento.

Si bien estos eventos son raros en estos días, eso es realmente lo que está en juego con una falla del sistema. Ka-boom. La gente muere. Propiedad destruida.

La tercera ola generalmente fue tratar de eliminar la mayor cantidad posible del componente humano. Tenga en cuenta que “SC” en SCADA significa “Control de supervisión”, es decir, personas que le dicen a la computadora qué decirle a la planta qué hacer. Entonces, razonaron varios visionarios, ¿qué pasaría si pudieras dejar que la computadora lo resuelva todo solo, con algunas reglas programadas?

Y ahí es donde realmente comenzaron los problemas. Las personas responsables no creían que alguna vez debían preocuparse por la seguridad, porque cada implementación estaba desconectada de cualquier cosa y todo lo demás, y había que pasar controles de seguridad físicos para acceder a ella. Nadie pensó en la evolución de las plataformas informáticas ni en la necesidad de portabilidad de la plataforma, porque todos los que vendían plataformas tenían un interés personal en que el cliente NO pudiera moverse, ¡nunca!

Ahora agregue a eso el crecimiento de Internet, las personas que conectan LAN internas a redes SCADA “para que los ingenieros puedan iniciar sesión en los sistemas sin abandonar sus escritorios e ir a la planta”, avancen unos años a BYOD y muy pronto, habrán los chicos se sentaron en Starbucks en un iPad con plantas de energía, sin pensar realmente en la seguridad.

Es un gran problema, es muy costoso solucionarlo.

La mejor solución provisional, en realidad, es obligar a los operadores de sistemas SCADA a desconectar sus redes de control de todo lo demás y aplicar procedimientos de auditoría estrictos para cada una de esas redes. Falla, y la gente es despedida.

Eso al menos nos dará algo de tiempo para descubrir si hay una forma económicamente viable de resolver realmente este problema. Sospecho que involucrará algún tipo de sistema operativo hipervisor seguro en tiempo real, basado en UNIX, que emule las llamadas anteriores del sistema operativo en la medida en que el código existente sea compatible con binarios, eliminando así el mayor obstáculo “no podemos permitirnos este”.

SCADA es extremadamente inseguro porque es extremadamente difícil tener tiempos altamente deterministas y una fuerte seguridad al mismo tiempo. También está diseñado para ser suspendido con respecto a las redes de área amplia, sin visibilidad alguna. Sin embargo, SCADA en sí rara vez es el problema. Debido a que se ejecuta en entornos de misión crítica, cualquier tiempo de inactividad y cualquier error de software es potencialmente catastrófico. El diseño de software para este tipo de estándar es costoso y lento. (En promedio, está viendo de 1 a 10 líneas de código por día por programador). Es por eso que la mayoría de los sistemas SCADA ejecutan Windows NT, generalmente una versión 3.x. Reescribir el código para Windows Server 2007 costaría demasiado, y las versiones modernas de Windows no están diseñadas con ese tipo de estabilidad en mente. Son muy complejos.

Podrían, por supuesto, cambiarse a Linux. Existen sistemas Linux de nivel de operador, pero eso no es lo suficientemente bueno. Se necesitarían alrededor de un millón de ingenieros de software con una comprensión de los métodos formales de aproximadamente tres años de trabajo continuo para lograr que el kernel, el compilador y la biblioteca C lleguen al punto en que puedan certificarse sin errores y ser lo suficientemente tolerantes a los fallos, y el kernel real- tiempo suficiente para un uso serio de SCADA. Si asume cien mil por codificador, ese es un costo total de cien mil millones. Recuerde que hacer esto con Windows requeriría cien billones, debido a los niveles más altos de complejidad y niveles más bajos de control de calidad. Cien mil millones son factibles solo si los gobiernos de EE. UU. Y la UE pagaron por ese desarrollo, ningún fabricante de SCADA tiene ese tipo de dinero de juego.

Entonces esto lleva al problema número uno. Windows NT tiene un sistema de seguridad decente pero es antiguo. Desde entonces han surgido muchas estrategias de ataque y Microsoft no proporciona actualizaciones. Windows NT tampoco está diseñado para funcionar en computadoras modernas y los fabricantes modernos no proporcionan controladores para él, por lo que los errores de seguridad en el hardware no pueden repararse reemplazando partes. Incluso si pudiera encontrar controladores, ¿quién fabrica tarjetas que usan ranuras ISA en estos días? ¿Aparte de los proveedores de SCADA? (¿Hay ingenieros de software, además de mí, lo suficientemente mayores como para recordar ISA?)

Por lo tanto, los defectos de seguridad en el hardware y el sistema operativo no pueden ser reparados o solucionados por los vendedores o los usuarios, y un sistema operativo de reemplazo de estándar adecuado requeriría dos poderes mundiales importantes para interferir descaradamente con el mercado y escribir uno. E incluso entonces, llevará al menos tres años.

La siguiente debilidad tampoco está en SCADA, per-se. De acuerdo con Slashdot, por razones más allá de cualquier comprensión racional, los usuarios aparentemente están colocando los programas de control reales en Internet, con protocolos no autenticados y no garantizados. ¿Qué podría salir mal?

El protocolo SCADA en sí no está encriptado ni autenticado. Como se mencionó anteriormente, tiene que ser totalmente determinista y nadie pensó que las personas fueran lo suficientemente estúpidas como para ejecutarlo en redes públicas. Es una violación completa de las prácticas básicas de seguridad, una amenaza para los requisitos deterministas y, debido a que la latencia es tan grande, absolutamente irracional en un entorno donde los errores se miden en millas de propiedad destruida.

Los sistemas de control industrial (ICS), como el Control de supervisión y la adquisición de datos (SCADA), abarcan tanto la tecnología de la información (todo lo relacionado con la tecnología informática) como la tecnología operativa (las plataformas utilizadas para ejecutar activos físicos). Así que puedes imaginar todos los datos que los ICS procesan y administran.

Las empresas optan por sistemas SCADA para estar en entornos de centros de datos empresariales, ya que esto podría ser más eficiente para fines de gestión y monitoreo. Sin embargo, también podría tener riesgos. Por un lado, los atacantes tienen la intención de violar e interrumpir las operaciones, dada la motivación correcta y un entorno vulnerable, y atacar con éxito los sistemas de control en el centro de datos podría derribar el centro de datos durante un tiempo considerable.

Los problemas de seguridad en los sistemas SCADA pueden variar desde la política y el procedimiento de la compañía hasta las vulnerabilidades de la plataforma y la red:

· Vulnerabilidades de configuración de la plataforma: datos desprotegidos en dispositivos vulnerables

· Vulnerabilidades de configuración de red: controles de flujo de datos no utilizados, por ejemplo, listas de control de acceso (ACL)

· Vulnerabilidades de comunicación: autenticación de usuarios, datos o dispositivos deficiente o inexistente

· Vulnerabilidades de conexión inalámbrica: protección de datos inadecuada entre clientes y puntos de acceso

Por supuesto, abordar estas vulnerabilidades y otras amenazas son la experiencia de las empresas de seguridad. Elija el que priorice la detección de tráfico malicioso, incluidas las comunicaciones de comando y control (C&C), el monitoreo y el registro de actividades, y las soluciones de parches virtuales. Sin embargo, en la forma más básica de seguridad, los departamentos de TI deberían poder establecer estándares e implementar estrategias sobre autenticación de usuarios y protocolos de seguridad fortalecidos.

Trabajo como ingeniero SCADA para una empresa de generación de electricidad (mi trabajo diario).

SCADA Security está a la vanguardia de mi trabajo, tanto que he pasado todo el año desplegando nuevos servidores para mejorar nuestra seguridad. Tenemos alrededor de 40 sitios repartidos en dos países.

A continuación hay una respuesta que alude a los sistemas SCADA que se ejecutan en plataformas NT: eso es absolutamente incorrecto. Nuestras plataformas son Windows Server 64 bit parcheadas y actualizadas regularmente. Cualquier sistema que se ejecute con tecnología antigua presenta riesgos en tantos niveles que es irresponsable hacerlo. No hay un solo producto en el mercado hoy en día, con una participación significativa en el mercado y una base de clientes que “requiera” una plataforma desactualizada.

Otro Quoran mencionó que el parche de Microsoft el martes puede ser un problema con la necesidad de reiniciar la maquinaria operativa; esto es cierto, programamos nuestros reinicios cuidadosamente y trabajamos en un proceso de parche que nos vea implementando parches de 2 a 3 semanas detrás de nuestra red corporativa. En el caso de que un parche cause caos, deberíamos recogerlo antes de que llegue a nuestra LAN SCADA.

Nuestra red SCADA está separada de nuestra LAN corporativa; sin embargo, por razones de seguridad no puedo entrar en detalles. Tenemos varias capas de dispositivos de seguridad en la LAN, en casi todos los niveles operativos.

En cuanto a las compañías que se especializan en este tipo de protección de infraestructura, los fabricantes de equipos están liderando en mi opinión, Schneider Electric, Rockwell Automation y Moxa, por nombrar algunos.

Sé de varias universidades en la industria, que trabajan en roles similares a los míos, y que aún se niegan a reconocer que la seguridad forma parte de nuestro rol. La actitud es que si el sistema está vacío, no hay riesgo, esto está mal, a la Stuxnet.

Si un ingeniero diseña un sistema que tiene intrínsecamente agujeros de seguridad, se expone a acciones legales si el sistema se ve comprometido alguna vez. Muchos de estos tipos están dispuestos a correr ese riesgo, no estoy de acuerdo: como ingeniero, es mi responsabilidad implementar sistemas que tengan el perfil de riesgo más bajo que pueda desarrollar.

También experimento, de manera regular, ingenieros de TI que creen que los sistemas SCADA no son diferentes de las PC de escritorio que ejecutan MS Word o Exchange: esta es una actitud que trabajo duro para superar. El ingeniero informático promedio no tiene idea de cómo funcionan nuestros sistemas, o de lo que está en riesgo cuando una máquina deja de funcionar repentinamente o muere. Hay una gran diferencia entre la PC que controla el colapso de una planta de generación y la pérdida de su correo electrónico de “Daniel de Cuentas”.