Hablaba en mi entrada “Autenticación y Autorización, conceptos básicos”, conceptos básicos” sobre la necesidad de aplicar controles de acceso en equipos, componentes, sistemas para garantizar que sólo aquél o aquello deba poder acceder o conectarse. Siempre de manera legítima.
Ahora bien, ¿cómo los podemos aplicar en materia de Ciberseguridad Industrial? ¿Sobre qué ámbito, escenario o circunstancia? ¿con el fin de proteger, qué? Veamos algún ejemplo.
Los entornos industriales son muy heterogéneos y muy especializados con lo que se requiere profesionales con conocimiento y experiencia sobre distintos ámbitos. No es lo mismo el que debe programar las trayectorias que debe seguir un robot para realizar un movimiento donde hablaremos de velocidades, precisión de trayectoria, cinemática directa, inversa, posición de reposo, etc. A otro que va a programar un autómata donde hablaremos de contactos normalmente abiertos, normalmente cerrados, marcas, contadores, temporizadores, palabra, doble palabra, etc. O incluso un “logic solver” para controlar las seguridades de una máquina por medio de cortinas, apertura de puertas, sensores de proximidad, pulsadores de emergencia.
Por ello es que el mismo equipo pueda contener distinto tipo de software, del mismo o distintos fabricantes, y que sea utilizado por distintas personas o técnicos que puedan abrir los proyectos por ejemplo de TIA Portal, Sysmac Studio, etc.
Lo que vamos a ver a continuación es la posibilidad de limitar los accesos a estos proyectos para evitar que sean modificados, accidental o intencionadamente y que al ser descargados, por ejemplo, sobre la CPU del un PLC.
Aunque se ejemplarice con el software TIA Portal v16, no pretende ser un manual de éste sino la funcionalidad que debemos buscar en cada fabricante y en los productos de éste, Sea SIEMENS, Phoenix Contact, Beckhoff, Mitsubishi, Snchneider Electric, o cualquier otro.
A continuación, vamos a crear un proyecto para la CPU del PLC de la serie S7-1200 con las características que se indican.
Una vez que hayamos accedido podemos encontrar la opción “Configuración de Seguridad” en donde localizamos la posibilidad de proteger el proyecto. Una vez apliquemos esta opción se nos habilitarán otro conjunto de opciones relacionadas con la seguridad.
Allí deberemos de indicar un usuario. Un usuario que inicialmente tendrá los máximos privilegios, es decir, editar los bloques de programa, crear otros usuarios, etc. Y así poder tener acceso completo al proyecto en sí. En nuestro caso “eng01”.
Cabe mencionar la posibilidad de establecer requisitos mínimos de la contraseña que cada usuario vaya a utilizar y así aportar mayor complejidad o reducir la posibilidad de su obtención. Estaría definiendo la “Autenticación”.
Luego cada usuario se asignará a un grupo, el cual tendrá unos derechos asignados. Es decir en función de en qué grupo incluyamos el usuario, éste podrá hacer tal o cual cosa. En nuestro caso el usuario “eng01” se incluirá en “Engineering Administrator” que como vemos tiene los máximos privilegios, pudiendo editar el programa del PLC, crear más usuarios, cambio de nombre, IPS, etc. Etc. En este caso estaríamos configurando la “Autorización”.
Hay que tener presente que estas opciones no tienen porqué estar presente en todas las versiones tanto de hardware, firmware o software de programación. Si intentamos hacer lo mismo con versión TIA Porta v11 con un hardware similar pero no igual, con diferente versión firmware, no encontraremos esa posibilidad.
Esto nos da una idea de cómo los fabricantes cada vez más están introduciendo distintos tipos de medidas para restringir los accesos, comunicaciones, permisos, etc. Y por tanto la necesidad aplicar medidas en este sentido.
Hasta aquí la entrada de hoy, en la siguiente seguiremos con ello.
Hace unos años saltaba la noticia acerca de la aparición de un nuevo malware para Sistemas de Control Industrial bajo el nombre TRITON, TRISIS o HATMAN. Un malware que a diferencia de otros como Stuxnet, Havex, Blackenergy2, CrashOverride tiene como objetivo sistemas SIS.
Los sistemas SIS (Safety Instrumented Systems) son los encargados de mantener bajo condiciones “seguras” instalaciones, procesos y equipos en caso de producirse alguna anomalía o mal funcionamiento. Así como en inglés podemos diferenciar entre “Security” y “Safety”, en español, empleamos únicamente la palabra “Seguridad” introduciendo cierta confusión. Es por ello es que muchas veces debamos especificar el ámbito al que hacemos referencia. Esto es, “Security”, seguridad de la información y “Safety”, seguridad de personas o instalaciones.
Estos sistemas operan al margen del propio proceso productivo, monitorizándolo y siendo independientes de los equipos que participan en él. No obstante, pueden estar integrados dentro de éstos. Aunque, en general, el equipamiento industrial es robusto y confiable, los SIS lo son aún más incorporando técnicas de corrección de errores, autodiagnóstico, componentes redundantes, aparte de una implementación específica acorde a la instalación o infraestructura de la que van a formar parte. Los requisitos están regulados según el estándar bajo el estándar IEC-61508, habiendo otros como el IEC-61511 que lo complementa en cuanto a uso de los mismos.
Cuando un sistema SIS detecta una condición que supera, o va en contra, de lo programado, actúa llevando el proceso a un estado seguro o deteniendo la actividad. Por ejemplo, son los encargados de parar el brazo de un robot en caso de que la puerta de la jaula donde se ubique, se abra evitando que éste pueda golpear a un técnico o dañar las instalaciones. O bien, parar una cadena de montaje si alguno de los sensores infrarrojos que delimitan su perímetro, detectan la presencia de una persona mientras está en movimiento evitando algún tipo de golpe, lesión o atrapamiento.
Como decía al principio, en esta ocasión, el malware detectado no afecta a sistemas de control tradicionales sino SIS, lo que supone un cambio a lo que podríamos estar acostumbrados y una evolución en los ataques a elementos OT.
TRITON/TRISIS/HATMAN, según sea la fuente en la que nos basemos, permite realizar cambios en los controladores SIS del fabricante Schneider Electric modelo Triconex. Entre sus características destacamos la capacidad para leer programas, lectura y escritura de funciones, consultas del estado del controlador y otras adicionales que pueden ser implementadas por medio de payloads específicos.
Durante el incidente que supuso la posterior investigación y detección de este malware, algunos controladores entraron en un estado de “seguridad” provocado por un supuesto fallo y que automáticamente pararon el proceso.
El malware se compone de dos piezas fundamentales. Por un lado, un componente que reside en un equipo tipo PC que posee el software legítimo para la comunicación de los controladores y por otro, dos binarios que se descargan en el propio controlador para actuar sobre él.
Todo comienza con el compromiso de la estación de trabajo encargada de la comunicación contra estos controladores SIS y que emplea sistema operativo Windows. El malware es nombrado como si fuera la aplicación Triconex Trilog, cuya función es el análisis de logs de las estaciones Triconex y que se encuentra dentro de la suite TriStation. El malware es distribuido dentro de un ejecutable denominado “trilog.exe”. Se trata de un script escrito en Python empleando el compilador “py2exe”, el cual es entregado junto con un fichero “library.zip”. Éste, contiene las librerías necesarias para poder operar así como dos binarios necesarios “inject.bin” (código de función maliciosa) e “imain.bin” (control lógico malicioso) que serán enviadas al controlador para la interacción con él. FireEye lo resume así en la siguiente imagen:
Una vez iniciado “trilog.exe” se crea una instancia que comprueba el estado del controlador mediante al protocolo TriStation empleado por el software legítimo TriStation TS1131 para la configuración de los mismo a través del puerto UDP 1502. Si éste se encuentra operativo, conecta con él y pasa los binarios “inject.bin” e “imain.bin” a las librerías de comunicación para enviarlas y almacenarlas en la memoria del controlador.
Una vez allí, el script realiza comprobaciones periódicas para conocer el estado del controlador. Si éste presenta algún error intenta resetearlo a un estado previo mediante el protocolo TriStation. Si esto fracasa, intenta escribir datos falsos en esa misma memoria para borrar cualquier rastro y obstaculizar cualquier tarea forense para determina la causa que ha provocado el fallo.
Dicho protocolo, que no implementa medidas de autenticación y cifrado aunque pueden configurarse ACLs en los equipos que lo dispongan, no está documentado públicamente,. Por tanto hace entender que el autor debió realizar labores de ingeniería inversa para poder llevar a su implementación. El descubrimiento de controladores SIS puede ser realizado mediante el envío de paquetes broadcast usando UDP 1502.
Es importante señalar que los controladores Triconex disponen de un “switch” físico que permite conmutar entre los distintos estados en los que puede operar el equipo. Las configuraciones y cambios deben realizarse en modo “Program”, posición bajo la que podría actuar TRISIS. Sin embargo, si lo está en modo “Run” o “Remote” las modificaciones no están permitidas, con lo que reduciríamos la probabilidad de que pueda ser comprometido.
Así pues, se presentan, a priori, distintos escenarios con las consecuencias que podrían tener sus efectos. Estos podrían ser:
Parada del proceso. Se provocan distintos cambios no autorizados que hagan que los equipos detengan su funcionamiento en previsión de consecuencias mayores.
Programación errónea de dispositivos SIS. Introducir variables o parámetros que permitiesen la operación de las instalaciones bajo condiciones que entrañen peligro para personas y elementos físicos.
Parada o alteración de planta. Dependiendo del impacto afectar a la actividad de la compañía.
Daños físicos. Sin la capacidad de regularizar o parar la actividad en caso necesario, la maquinaria o sistemas no interrumpirían su funcionamiento y por consiguiente el correspondiente daño.
Al parecer, se tiene constancia de que al menos existe una víctima localizada en la zona de Oriente Medio, no trascendiendo su identidad. Dada la naturaleza, propósito, grado de conocimiento tanto tecnológico como de proceso que se requiere, hace pensar que una nación pudiera estar detrás de la autoría. No se aprecian objetivos ni intereses económicos lo que se podría descartar delincuencia organizada.
Sin bien debemos ser conscientes de este nuevo y preocupante escenario, hemos de contextualizar y valorar todas las pruebas existentes, evitando sensacionalismos y alarmas innecesarias. La Ciberseguridad Industrial es un tema álgido dentro de los profesionales del sector, por lo que debemos analizar las circunstancias, condiciones, requerimientos y tecnologías para que estos ataques tengan efecto. Algunos de ellos podrían ser:
Aplica a equipos concretos de un determinado fabricante, no a todos.
Debe darse la condición de que un conmutador físico debe estar en cierta posición.
Alto conocimiento de esta tecnología.
Conocimiento del proceso que se gestiona para poder actuar de forma dirigida y provocar el mayor daño o impacto posible.
No seguir las principales recomendaciones o estándares en materia de Ciberseguridad Industrial. Dependiendo del tipo de compañía, infraestructura o sector esto pudiera ser más o menos probable. No podemos considerar una empresa del sector petroquímico que una manufacturera del sector automoción.
Por último, mencionar algunas recomendaciones que pueden evitar tanto la infección, como la propagación y posterior ejecución.
Establecer una red físicamente independiente para los sistemas SIS.
Implementar NGFW que filtren el tráfico de gestión hacia ellos.
Aplicar Control de Aplicación, Antivirus e IDS/IPS a nivel de red en NGFW.
Sobre la Workstation para sistemas SIS aplicar soluciones de Control de acceso, usuarios con permisos específicos, integración a posible Directorio Activo; Whitelisting de Aplicación [1],[2]; Control de dispositivos USB [1]
Aplicar controles de acceso físico a dichos sistemas; cabinas, armarios, etc.
Registro de logs o envío de eventos cada vez que se lleve a cabo alguna intervención sobre SIS.
Verificar la posición correcta de conmutadores físicos, en este caso, modo “Run” o “Remote”.
Así pues, por esta y otras, amenazas, vectores de ataque e intereses de distinto tipo, resulta necesario tomar medidas y controles sobre nuestros entornos OT. Obviamente, cada infraestructura, organización o compañía será objeto de unas u otras dependiendo de la importancia estratégica, criticidad o actividad, despertando los intereses de agencias, gobiernos, competencia o delincuencia. No podemos tratar a todos por igual. Hemos de contextualizar y analizar de la manera que merece, con la inteligencia que requiere.
Once we have installed Network agent, we will deploy KICS for Nodes. Before this we must install management plugin on Kaspersky Security Center, which requires a restart after the process is finished. It is recommended to make sure that the plugin has been installed correctly. You can check it by going to Administration server and verify its properties.
The next step will be installing KICS for Nodes software package to control software, virus presence, and many more. Before that, we will import KICS for nodes generic policy and distribute it on target hosts even before KICS for Nodes has been installed. Do not worry, this generic policy excludes any device and whitelist control so the PC will work without any restriction. Later on, we will have to configure it and give specific whitelist and device controls and, of course, other security options such as enabled modules, anti-virus analysis, exclusions, etc.
Keeping in mind that each deployment must be carried out in accordance to engineering and production requirements of automation and industrial systems. So, we will plan and inform each action to take.
As you can see in the picture below, there are two kind of policies. One for Network Agent (KLagent) and other for KICS for Nodes software.
Once it has been imported, we have to activate it. As I said, there is not any direct effect on the target system because KICS for Nodes is not installed yet.
To deploy KICS for Nodes, KSC allows installing software on managed devices groups by setting up a package. First of all, we have to create it by importing a precompiled kics.kud file but you can import a .exe file as well. For more info please visit this link.
In the picture below you can find two files, one imported by an .kud file and the other one with .exe
Once we have created KICS for Nodes packages, we can customize them configuring the components to install before executing the remote installation wizard. During the process we will have to give some additional information such as target hots, admin credentials, among others.
These are the grouped hosts which we are going to install KICS for Nodes. We can select one by one or the folder which includes them all.
Other software is recommended to be installed such as published hotfixes to correct issues, improvements, or bugs.
After this, the next step to follow is to perform an on-demand antivirus scan. Why? Because we must be sure that the host is not infected by any kind of viruses. If this occurs, we could include virus processes in our whitelist and, in consequence, allow its execution. However, we must keep in mind that this analysis can consume CPU, memory and other hardware resources and impact on the host behavior.
Next, we will configure according our needs. KICS for Nodes policy has in the left hand a column named “sections” where you can find the features grouped by functionality. For example, in “Local activity Control” you can configure modules regarding “Application Launch Control”, “Device Control” and “Wi-Fi Control”.
But if you navigate in other section, such as “Real Time computer protection” you can see other features regarding “Real-Time File Protection”, “KSN usage” and “Exploit Prevention”.
And that is all for now. In the next article, we will explore the different options and show how whitelisting technique works to prevent the execution of any non-authorized software.
