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!

 

CPU Protection, Part II

In addition to my last post where I talked about CPU protection (click here to access), today I will write about how we can detect if protection is enabled on a S7-300. If not, we could connect to the PLC (CPU or communications module), upload the program, and modify it. After this, download it again.

Other actions that could be accomplished are establishing new passwords on FCs, FBs, etc. When a legitimate user would want to access to read or write them, he/she could not do it because would not know the configured password.

S7Scan tool can help us to get this information, CPU Protection. We have to take a look at “Module Protection” section. There, we can see if this is set up. In the figure below, it is not.

Well, what can we do? As I said we could be online and inspect the program, its configuration and upload it.

On the other hand, if “Module Protection” is configured as on the picture below, we will not be able to do it.

A password will be requested in two ways. Firstly, if we want to access to a Block or Function after we are online.

And secondly, if we want to upload the program. See the area where indicates “<introducir contraseña> that means <introduce your password>

This is an example on how these features can help us introducing new controls. Are they all effective as we expect? Well this is another question… During this work I found there is a limitation of eight characters long.

Apart from this, we know that passwords can be cracked by specific software or stored in plain text. Configure a password it is not a silver bullet to protect access. We have to implement other security measures and try to stop an intrusion, deliberate action or similar, before it reaches the objective.

We can not trust the security device by its own features because they could not be as robust as they should be. Industrial components, devices or systems have been designed to be robust, simple, reliable, safe, etc. not secure. Security is relatively new, since attacks have been carried out or vulnerabilities have been discovered and published.

Thanks again, I will see you in the next!

Having said this, I hope you have enjoined this post!

To be continued…

Stay tuned!

CPU Protection, Part I

To alter the normal operation of a system it is necessary to get access. For this reason we have to configure all available features to prevent that unauthorized people or software could carry out any action over them. However, we must not forget that security measures can obstruct the recovery of an equipment if do not define clear processes to get it back if something goes wrong or simply beaks down.

Two years ago, I wrote about some controls over Siemens S7-1200 PLCs. You can access it by clicking here. But today I will talk about other.

One of these features is to configure online control access to PLC CPUs. Not to protect the program and the content stored in it. Why is this important? Because when we connect any device to ethernet networks we are increasing the attack and exposure surface. Accordingly, to that, there are more possibilities to suffer any intentional or unintentional action that could affect to our OT devices.

With this feature we can set up passwords to restrict the access to functions and memory areas. In general, in level 1 hardware configuration can be read and modified by anybody; Level 2, read access do not need any password but if you want to change some parameter you will need to type a password; and finally, Level 3, without a password you cannot modify some several parameters. Obviously in both cases there are conditions and exceptions that you can do. For further information please visit “Virtual Library” and locate the following document named “Security with SIMATIC controllers” in SIEMENS area.

After several years in the Industrial Cybersecurity field, in most cases I have not seen this feature implemented that can be used to hamper unsolicited actions on process controllers. If we do not restrict access to anybody, they could upload the program, modify functions and other parametrizations and download it to the PLC again. After that, who knows what will happen if this occur. Other scenario could be the theft of intellectual property by the third parties that can participate in a project during a commissioning phase.

It does not matter which controller we are using, Siemens, OMRON, B&R, Schneider, or any other. The message is to request, identify or consider if this kind of feature is available and apply it to bring more security, to end devices. Of course, without introducing potential factors that could compromise the normal operation.

We know, there are scenarios where it could be difficult to start up some controls and invest more time to find compensatory measures instead of applying them natively. Obviously, if the device count with it.

In addition to that, keep in mind that a password or any other similar measure, could by cracked, but at least, we have applied one more step to reinforce the Defense in Depth concept that we must implement to protect our industrial environments.

Having said this, I hope you have enjoined this post!

To be continued…

Stay tuned!