Pirámide de Automatización Industrial. Rev. 12/05/21

Esta es una actualización de la entrada publicada 06/01/2017 en la que se han incluido contenido adicional.

A menudo veo en distintos artículos y publicaciones sobre Ciberseguridad Industrial cómo securizar entornos de automatización y control, teniendo en cuenta sus particularidades y otros aspectos que los hacen cada vez más complejos e “inteligentes”. Se habla de vulnerabilidades, amenazas, riesgos, separar, segmentar, bastionar, cifrar, definir roles, establecer procedimientos y por si fuera poco, su relación con sistemas IT tradicionales dentro de los que llamamos “Industria 4.0”. Sin embargo, y muy especialmente a aquellos que se incorporan recientemente, conviene recordar, y explicar, cuál es el modelo base sobre el que se encuadran dichas tecnologías y de cómo sistemas y dispositivos interoperan entre sí. Así como en IT existe el modelo teórico de referencia OSI, en entornos OT encontramos la “Pirámide de Automatización”, la cual recoge las tecnologías empleadas en la automatización y gestión de procesos productivos, ordenándolas en 5 niveles distintos. En resumidas cuentas, no podemos llevar a cabo ninguna acción sin antes tener claro la manera en la que éstas y sus componentes se integran, más aún, cuando se aprecia una clara evolución desde sus comienzos hasta nuestros días.

Aunque no quede representado como una pirámide propiamente dicha, el modelo queda como sigue:

Nivel 0

En este nivel encontramos tanto sensores (medición y conteo) como actuadores (Motores, robots, servos, etc.). Comprende también el propio proceso productivo.

Nivel 1

Aquí situamos los conocidos PLCs (Programmable Logic Controller) los cuales ya requieren de una programación específica para poder llevar a cabo las operaciones mediante el procesado de los datos y señales proporcionadas por los elementos de Nivel 0 y emitir a su vez órdenes de salida hacia otros, como pueden ser las consignas en los actuadores. Cuando por volumen, situación geográfica o estratégica, entre otros motivos, se requiere de una arquitectura distribuida, nos referiremos a DCS (Distributed Control System) con distintas CPUs de Control. Las RTU (Remote Terminal Unit) también estarían comprendidas dentro de este nivel.

Nivel 2

Aunque también puede situarse PLCs a un nivel superior de los de Nivel 1, esta capa se refiere principalmente a la supervisión y control del proceso. Esto se consigue por dos vías, por medio de sistemas HMI (Human Machine Interface), los cuales permiten hacer esto último a un nivel local, digamos a “pie de línea”; o cuando lo que se busca es una visión más amplia o centralizada, mediante sistemas SCADA que recogen la información de distintas fuentes y las aglutinan en una o varias interfaces gráficas donde podremos observar el estado de las instalaciones, secuencias de fabricación, anomalías de operación, etc. Los equipos sobre los que sustentan estas aplicaciones están basados en equipos tipo PC o Servidores, por lo que al disponer de una capacidad y flexibilidad mayor que los anteriores. El software empleado podrá tener además otras capacidades tales como almacenamiento de logs, control de accesos, configuración de alertas y alarmas, etc.

Nivel 3

En este nivel encontraremos dos sistemas principales, los Historizadores y Sistemas MES (Manufacturing Execution System). Los Historizadores son los encargados de almacenar la información de proceso o de infraestructuras, según sea el caso. Están basados en motores de Bases de Datos, y aunque se apoyan sobre productos comerciales, están específicamente diseñadas para este propósito, con alguna particularidad distinta al convencional. Por ejemplo, una de las características es la capacidad para gestionar gran cantidad de accesos en tiempo real junto con la inclusión de registros conocidos como VTQ (Value, Timestamp, Quality). Al generarse un mayor número de entradas, también se genera mayor cantidad de información, por lo que tener la propiedad de compresión de ésta resulta necesaria y a su vez un factor diferenciador entre soluciones propietarias. Por otro lado, las soluciones MES son sistemas que permiten gestionar el entorno industrial o manufacturero, dentro del flujo de fabricación de un producto determinado. Entre sus funcionalidades destacan la trazabilidad del producto, análisis de rendimiento, recursos empleados, gestión de calidad y procesos, asignación de ordenes de fabricación, entre otras.

Nivel 4

Último nivel de todos. Aquí ubicamos las sistemas ERP (Enterprise Resource Planning) o BI (Business Intelligence). Éstos gestionan de forma global la producción dentro de una empresa, además de otros aspectos como la distribución, logística, inventario, facturación, RR.HH. etc. Son sistemas modulares y especializados en función de la tarea a realizar, permitiendo la resolución de problemas vinculados a la fabricación y departamentos afines. Constituye un apoyo a la toma de decisiones para la actividad ya que aglutina muchas y distintas fuentes de información sirviendo de apoyo para la toma de decisiones que permitan mantener y mejorar la unidad de negocio. Partiendo de esta idea surge el concepto de Business Intelligence Industrial. En este caso los orígenes de la información son sistemas tipo SCADA, HMI, Historian, DCS, permitiendo además una integración con los sistemas ERP o BI. Una vez que la información es recogida, contextualizada y almacenada, es analizada a partir de su representación mediante informes o cuadros de mando, de una forma intuitiva y casi siempre gráfica.

La comunicación entre los componentes podrá ser de carácter Vertical u Horizontal. En el caso de las Verticales, el sentido podrá ser ascendente o descendente y llevada a cabo mediante protocolos concretos según sea el nivel y cometido en cuestión. Si bien la comunicación puede ser directa, no es de extrañar el uso de convertidores y pasarelas de medios y protocolos. Las Horizontales, son aquellas que se dan dentro del mismo nivel entre equipos de igual naturaleza, tanto por funcionalidad o necesidad, como puede ser redundancia para entornos en Alta Disponibilidad.

En cuanto a la conexión entre niveles y sistemas, podrá realizarse mediante una variedad de tipos de medios físicos, buses y protocolos según sea el caso, aunque dependiendo el entorno y capacidades, es más predominante el uso de unos u otros. Por ejemplo en cuanto a medios físicos se refiere tendremos RS-485, Ethernet, Fibra Óptica y más recientemente Wi-Fi. En cuanto a buses de campo según sea el medio podrán ser unos u otros. En el caso de RS-485 podremos encontrar, Profibus, Canbus, Modbus, etc. y en Ethernet, Profinet, Ehernet/IP, Ethercat, etc.

Como decía, para el caso en que debamos conectar unos con otros existen los conocidos “Gateway o pasarelas” que permiten pasar de un medio a otro, por ejemplo Ethernet/RS-485; Fibra óptica/Ethernet; Gateway para transformación de protocolos; etc.

Hablando en concreto de protocolos de supervisión nos referiremos a DNP3, OPC o Modbus/TCP, con algunas versiones que ya incluyen medidas de seguridad.

Por supuesto existen otros más, especialmente los desarrollados por los fabricantes y que son de carácter propietario, como S7-Messaging (SIEMENS), Unitelway (Schneider), FINS (OMRON), etc.

En resumen, las comunicaciones dependiendo del propósito podrán ser:

Automatización:

Comunicación entre CPUs de controladores como RTUs, PLCs y periferia distribuida.

Visualización y Control:

Monitorización y Supervisión de procesos, notificación de anomalías y envío de órdenes (consignas).

Programación:

Envío de programas desde el equipo de programación (Por ejemplo, FIELPG de SIEMENS) y dispositivos de Control como PLCs.

Comunicación con sistemas superiores como Historizadores, ERP, BI, etc.

¿Y por qué todo esto? Porque a partir de aquí es donde se debe construir un proyecto para proteger nuestro entorno industrial. Si no entendemos esto, no podremos comprender el grado en que afectan unas u otras vulnerabilidades; las consecuencias de las debilidades en protocolos sin medidas de seguridad nativas; de porqué debamos basar la protección a nivel de infraestructura en lugar de desplegar herramientas software; del impacto que puede tener una brecha en unos u otros sistemas; de la capacidad y límite de desplegar nuevas medidas; por dónde empezar a realizar el análisis de riesgos; de qué personas puede tener responsabilidad sobre uno u otro equipo; dónde instalar un NGFW; y así hasta un buen número de otras casuísticas.

Debemos ser conscientes cómo y con quién operan los dispositivos. Hecho esto, podremos implementar las soluciones y minimizar los riesgos de sufrir un incidente que ponga en peligro la disponibilidad de nuestras instalaciones, y en el caso de Infraestructuras Críticas, evitar un mal mayor como daños ecológicos, pérdida de vidas humanas, falta de suministro de servicios esenciales, y un largo etcétera. No se trata de llegar a saber cómo se programa un PLC, pero sí saber que ese PLC se comunica con una periferia mediante protocolos vulnerables; que se interactúa con él desde una estación con un sistema operativo sin parchear desde vaya uno a saber cuándo; que se puede conectar un USB infectado o ejecutar una aplicación desde la cual realizar un escaneo de la red o llevar a cabo un infección accidental o dirigida; que pueda interceptarse el tráfico de supervisión; realizarse una denegación de servicio contra las Bases de Datos que almacenan información relativa al proceso, y así hasta que uno se aburra.

En fin, antes de ponernos manos a la obra toca familiarizarnos con este modelo, que seguro nos ayudará a tomar las mejores decisiones.

A continuación os dejo un video donde podréis complementar todo lo anterior.

Un saludo, nos vemos en la próxima.

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!