Protección PCs Industriales

En entornos industriales, como es lógico,  también nos encontramos con equipamiento basado en tecnología PC (x86, x64) con una gran cantidad de usos, como controlar una célula de automatización, estación de programación, interactuar con elementos de periferia, visualización de estados de procesos, entre otros muchos.

Sin embargo, las características son muy distintas si las comparamos con sus similares en entornos de oficinas aún cuando estemos hablando funcionalmente del mismo tipo de equipos.

Una de esas diferencias son el superior ciclo de vida lo que nos expone a tratar con equipos con antigüedad elevada pero plenamente funcionales. Sin embargo, hay que decir que presentan algunas limitaciones. Por ejemplo, el sistema operativo, el cual puede estar sin soporte o sin aplicar muchas (sino todas) las actualizaciones que corrijan errores o vulnerabilidades.

Aparte existen otras importantes. En el caso que un integrador haya desarrollado una instalación, maquinaria, DCS, etc. donde exista un equipo de estas características, el contrato de soporte permitirá cualquier intervención únicamente a la empresa desarrolladora, o fabricante. Con ello se busca impedir que ninguna manipulación pueda afectar al normal funcionamiento de componentes, equipamiento o maquinaria e incumplir acuerdos de rendimiento, disponibilidad u operación. Y como no, entre ellas, la aplicación de las actualizaciones de seguridad que tanto se recomiendan.

Eso en materia de sistema operativo, pero si nos referimos a las aplicaciones o software, podremos encontrarnos con escenarios en los no sólo se empleen los del mismo fabricante que sistemas de control, sino también otros empresas y que han sido desarrolladas “a medida” acorde a las necesidades del cliente. A ello hay que sumar que cada parametrización de ese software bien de control, telemetría o visualización será acorde a cada escenario concreto. Esto es, aunque existan dos compañías llevando a cabo la misma actividad, las representaciones, umbrales, alertas, sistemas de seguridad funcional serán distintas.

Por otra parte, el hardware, por su antigüedad, también presenta limitaciones que nos obliga a trabajar con menores recursos hardware, lo cuales deben estar dedicados a las aplicaciones que controlen el proceso o las funcionalidades asignadas. Es decir, no podemos, aún cuando sea posible, implementar software adicional que pueda impactar negativamente en recursos de CPU, memoria o acceso a disco.

Además de lo anterior, tales despliegues, como norma general no se han hecho teniendo en cuenta la ciberseguridad, con lo que es más que habitual que firewalls a nivel de host estén deshabilitados o con un “Permit, Any, Any”; todos los servicios por defecto, habilitados; ausencia de software de seguridad, etc. etc. etc.

Aunque los sistemas de control no estén expuestos directamente en la red, es posible que estos equipos dispongan de dos tarjetas de red. Una “aguas abajo” para comunicar con los elementos de control; y otra “aguas arriba” para ser accesible con otros sistemas de planta, servidores, mantenimiento, etc.

Según todo lo anterior, a la vista está que las circunstancias que rodean a equipos PC o servidores hacen que los riesgos que permitan a algo o alguien, poder llevar a cabo una acción que repercuta en la operación son elevados. Por ello, debemos presentarles especial atención ya que como hemos visto pueden tener la capacidad de interactuar con otros sistemas o tecnología de control y automatización. Obviamente esto no puede afirmarse con rotundidad ya que dada la heterogeneidad puede haber escenarios que no aplique en su totalidad. En cualquier de los casos es necesario desplegar medidas para su protección.

Cuando hablamos de equipos industriales no sólo podremos referenciarnos a HMI (Human Machine Interfaces), servidores SCADA o Estaciones de ingeniería. Podemos encontrarnos como sistemas de visión artificial; DNCs; CNCs; Thin Clients, Visualización, equipos de operador para la visualización de órdenes de fabricación o recetas,

En este sentido la aproximación es distinta a los entornos IT. Aquí, OT, por ser equipos donde los cambios son menos frecuentes; recursos hardware limitados y reservados a aplicaciones concretas; cualquier funcionalidad no puede penalizar funcionalidades, el recurso más frecuente es el Whitelisting.

Esta estrategia se centra en la definición de una “Lista Blanca” donde incluir aquellas aplicaciones que deben ser empleadas para la funcionalidad del equipo. Todo aquello que no esté incluida en ella, no podrá ser ejecutado; sea código, aplicaciones, etc.

Aquí os dejo un enlace donde podéis encontrar más información en un documento elaborado por el ICS-CERT.

Guidelines for Application Whitelisting in Industrial Environments

Conceptualmente hablando, esto mismo puede ser realizado a nivel de red. Esto es, por medio de los firewall de próxima generación con capacidades de realizar DPI (Deep Packet Inspection) y poder permitir o denegar aplicaciones, software o consignas que se envían por protocolos tales como S7, Modbus, Bacnet, Ethernet/IP, IEC 104, entre otros muchos.

Control de Aplicación en entornos ICS/SCADA, Parte I

Control de Aplicación en entornos ICS/SCADA, Parte II

Hace tiempo atrás hablé de la solución de Symantec Critical System Protection, cuyos artículos puede encontrarlos aquí:

Whitelisting en SCI (Parte I)

Whitelisting en SCI (Parte II)

Sin embargo esta ocasión abordaré este aspecto con la solución del fabricante Kaspersky KICS for Nodes ya que, como toda evolución de producto introduce mejoras. Más aún cuando Kaspersky se ha posicionado como líder en el ámbito de la Ciberseguridad Industrial.

Aquí os dejo un video donde se describen algunas funcionalidades, aunque no son las únicas.

Como podemos comprobar esta solución, tanto para equipos clientes como servidores, se basa en distintas capas de protección. Desde el Whitelisting de aplicaciones, control de dispositivos USB, Firewall a nivel de host, antivirus, entre otros.

Desde el punto de gestión, todos los equipos podrán ser gestionados y administrados desde una consola centralizada, como es Kaspersky Security Center, KSC.

Estas y otras funcionalidades son las que iremos descubriendo y ejemplarizando en futuros artículos sobre distintos casos de uso en entornos industriales.

Nos vemos en la siguiente!

 

Visibilidad y detección de anomalías, Parte III

Following Part I and Part II, we will give another example why OT monitoring is necessary to have a look about what is happing in industrial environment. The last one finished if somebody connected their laptop to the network and then to a PLC. Today, we will see what happens if somebody, that is, a third party, contractor, support team, etc. carries out a task that requires that the PLC CPU goes to STOP and the process, as well.

Having said this, imagine a manufacturing plant in operation and during an intervention, an engineer puts online and accidentally sends a STOP command by STEP7 software or something similar that requires it. Obviously other scenario can be a targeted attack on an exposed controller in the network.

If this occurs a message will appear in “Alerts” tab with score of “10” in the risk column. In the picture below we can see the steps since the PC (IP: 10.10.201. 103)  establishes connection with the CPU (IP, 10.10.201.102) by COTP protocol and sends STOP and START requests.

If we open both alerts, we will find more information of the source, its MAC and IP address, port, protocol, direction and so on.

For troubleshooting purposes, we can download a trace of the packets to find more low-level information. After that we are able to open it with a network protocol analyzer.

This example has been done once Guardian is in Protecting mode. Before this, we have to configure the tool in a “Listening” mode to learn about the asset, protocol, communication, behavior, etc. to take a picture of the network and everything it contains.

If this event occurs during this time, the alert can be different. In this case the alert will be scored with 9 and 6 values, respectively. In the first example we have to remember that the device from which we send STOP command, has not been discovered during “Listening” phase so the tool will categorize the action with a higher value.

Until now, we talked about a concise command. But if the CPU is not protected as I wrote in previous posts.

So, we can go one step ahead and think that if we can reach the PLC to STOP and START the CPU we could access and download it’s program. If it can be done, we could modify it and then upload it again to cause error condition, alter variables, configure passwords in order to do not permit legitimate access, and so on. If this occurs, we could identify it as shown in the  following picture.

Today we have analyzed different actions that can be identified by Nozomi Guardian monitoring tool, it can help us to detect actions that could alter normal operations. After this, we could start to investigate how a machine tool, production line or other facility stops without any reason.

However, it is important to remark that before deploying any security monitoring tool, an organization should have carried out other technical actions. One of them is to separate and segregate IT and OT environments. To do so, it is necessary to identify, analyze and decide which traffic must be permitted to pass across our firewalls. Once it has be done, we will have the criteria to say if what is happening is a normal or abnormal behavior. In other words, if we do not identify and understand which workstations  can access  industrial equipment and implement a strict change management process, we will not have the capacity to discover the root cause of the alert. Does somebody act on a PLC? Is it an attack? Has the communication module  failed?

These tools are useful solution if we implement it on stable, well-know and secure OT network.

Thanks for reading the post! See you!!

Tools: Pss

Continuing with CPU Protection Part I and Part II I will present to you a tool that can help us to obtain the protection level password if it has been configured to control the access to a PLC CPU. In this case, a S7-300 SIEMENS controller.

Its name is PSS and the last version that I have found is 1.83. I have tested it on S7-300 but the author refers to other software over the ones known to be used for the same purpose such as STEP7, MicroWIN, WINCC, LOGO, etc. Please click the “?” symbol on the bottom right corner for more information.

Although some of them can be obsolete, we know that the lifecycle of OT devices and technologies is longer than IT equipment. For this reason, nowadays this tool can be  useful to audit or assess even when the software is very old.

To obtain it, we must select the directory which stores the project with the device that has a password configured.

After this, press right click button and select “Start Scan”.

Few seconds later we will see the password in plain text if it has been detected. In this case “ICS2020”.

Note if you change this password and assign another, apparently, it will still be stored because if you repeat the process you can see the previous ones.

This tool can be useful to recover forgotten passwords, but it can be used if somebody has unauthorized access to the system or media that stores them. It is not enough to establish a backup plan only; it is also necessary to protect the PLC program copies.

It does not make sense make a copy of programs or configuration files if somebody can access them and extract the passwords that restrict the capabilities to read and write on them.

As mentioned, we have to deploy different controls across our facilities, systems, networks, and apply all possible and available features that they bring us the security that we need. Keep always in mind that we can not introduce a higher risk that we are trying to mitigate and passwords can be cracked…

Thanks again for your time, see you in another one!

Stay tuned!