Siguiendo con la entrada “Autenticación y Autorización, protegiendo proyectos. Parte I” Vamos crear un usuario en nuestro proyecto creado en TIA Portal V16. En este caso será el “eng02” que, a diferencia de “eng01” que tenía los máximos permisos, vamos a incluirlo en el grupo “NET Diagnose”.
Como podemos comprobar los permisos son muy distintos con respecto a “Engineering Administrator”, es decir, reducidos.
Tras guardarlo procederemos de nuevo a abrirlo, y dado que ya lo tenemos protegido veremos que se nos requiere un usuario y una contraseña. Esto es, deberemos introducir las credenciales de “eng01” o “eng02” según sea el caso.
Si introducimos las credenciales de “eng02” veremos que la cosa cambia. Aquí, los menús estará sombreados por los limites que tiene nuestro usuario.
Una de las opciones podría ser la creación de un usuario con máximos privilegios para luego cerrar el proyecto y volverlo a abrir con las credenciales que hemos creado y así saltarnos la protección. En este caso, no podemos apareciendo la siguiente ventana.
Si por ejemplo quisiéramos modificar un Bloque de Programa, ocurriría lo mismo. Podríamos verlo pero no incluir instrucciones, bloques, funciones o cualquier otra modificación como cambiar nombres a variables etc.
Este ejemplo demuestra los dos extremos, hacer todo como administrador o sólo visualizar el contenido de un programa y otras funciones del PLC mediante el control de acceso a los proyectos que contiene toda esta información. No sólo de un PLC sino de un HMI asociado, u otro elemento que incluyamos.
Esto es especialmente importante para aquellos escenarios en los que una ingeniería lleva a cabo un desarrollo y debe facilitar una copia de respaldo su cliente pero quiere permitir ver el contenido pero no facilitar su edición y así evitar modificaciones accidentales.
Otro caso podríamos tenerlo si se nos compromete el servidor de ficheros donde almacenamos las copias de respaldo o se pierde un dispositivo USB con el hacemos una copia y nos lo llevamos a una Workstation y alguien podría abrirlo y ver el contenido.
También no debemos olvidarnos de que en todo ello en un desarrollo, puesta en marcha o mantenimiento de una instalación compuesta por múltiples sistemas o componentes puede haber distintas empresas, integradores o ingenierías. Éstos puedan trabajar en la misma maquinaria, célula, estación o instalación y que se puede dar la situación que sean competencia entre sí, y no sería complejo hacer una copia del contenido de las carpetas donde se almacenan los proyectos, robarlos ya hacernos con la propiedad intelectual de la empresa contraria.
Hasta aquí la entrada de hoy, nos vemos en la siguiente!
Como hemos hablado en muchas ocasiones no existe una medida con la que podamos garantizar la seguridad de nuestras instalaciones máquinas o plantas. Sino que será la puesta en marcha de un conjunto de ellas que, de forma coordinada, establecerán distintas líneas de defensa.
La estrategia de Defensa en Profundidad establece diferentes niveles tanto a nivel organizativo como técnico, siendo uno de ellos el control de accesos. Estos pueden llevarse bien tanto a nivel de red a través de una Separación y Segmentación mediante el filtrado de direcciones IPs y puertos, o llevando a cabo DPI (Deep Packet Inspection) sobre protocolos industriales tanto propietarios (S7, FINS, etc.) como estándares (OPC UA, Ethernet/IP, IEC-104, etc.).
No obstante, a nivel de dispositivo, o sistema, también deben llevarse a cabo controles de acceso para restringir qué o quién puede conectarse a ello y hacer tal o cual cosa. Más aún cuando los equipos ya presentan, y cada vez haya más interfaces y protocolos, para poder conectase a servicios o funcionalidades. Esto es, servicio web (HTTP; HTTPS), consola (Telnet, SSH), envío de copia de respaldo y programas por FTP, protocolos como OPC UA, etc.
Desde el punto de vista de la seguridad restringir, controlar, impedir o limitar que éstos se reduzcan a los mínimos imprescindibles, es básico. Con ello podremos reducir las posibilidades de que algo o alguien puedan hacer cambios tanto de manera intencionada como no intencionada que puedan alterar la normal operación o realizar cambios con unas u otras consecuencias. También recolectar información sobre los dispositivos finales bloqueando los comandos correspondientes.
A diferencia de los entornos IT, el uso de control de acceso físico está, y estará muy extendido. Esto es el uso de llaves o mecanismos que requieran cambiar de un modo a otro que permitan la realización de cambios de forma remota o también local. Esto es algo que podemos encontrar en CPUs de PLCs de Schneider Electric, Siemens o Allen Bradley. Sin embargo, no son los únicos, controladores de robots también pueden tenerlo como es el caso de los ABB con los selectores de Automático, Manual o Manual 100%.
Saliendo de los controladores, también los HMIs, PCs industriales con uno u otro uso, pueden incorporarlo. Como puede ser el caso de llaves que tras introducirlas en un lector permiten la realización de tareas en función del perfil en ellas incluidas. Ejemplo de ello puede ser Euschner o Pilz entre otros.
Pero también, y como ya estamos acostumbrados, podemos realizarlos de manera lógica. Esto es, introduciendo un usuario/contraseña, PIN, etc. Sin embargo esto no es suficiente, ya que debe determinarse que puede hacerse sobre el equipo. Es decir que una vez validado, que las capacidades no sean ilimitadas.
Por tanto, aquí entran en juego dos conceptos, aunque obvios para Tecnologías de Información, no lo es tanto cuando los aplicamos a las de Operación. Estos son, Autenticación y Autorización.
Entendemos por “Autenticación” el proceso por el que se comprueba una identidad a través de alguna credencial como puede ser una contraseña; un usuario y contraseña; un código numérico; certificado digital; etc.
Mientras que “Autorización” hacemos referencia a los permisos o privilegios que dispondrá una persona, software, o activo en general una vez que el proceso de autenticación se ha realizado con éxito. Estos niveles deben estar relacionados y en consonancia con el rol que tenga una persona dentro de la organización para determinar lo que puede o no hacer. Por ejemplo, no es lo mismo las capacidades que pueda tener un Jefe de un equipo de Mantenimiento a un técnico especialista que se debe circunscribir a los equipos que son de su ámbito.
Esto extrapolado a la Ciberseguridad Industrial podrían ejemplarizarse, en el caso de la “Autenticación” en quién o qué puede conectarse a un equipo; quién puede tener acceso a un proyecto de un PLC; quién puede iniciar sesión en una Workstation; etc. Y en el caso de la “Autorización” si se puede escribir una variable o simplemente leerla; si puede visualizarse el estructura del programa de un PLC y no modificarse; o si desde un HMI puede resetearse una alarma y re armar la estación tras un fallo.
En las siguientes imágenes podemos ver el acceso. a la interfaz web de un PLC SIEMENS S7-1200 donde en el primero de los casos nos validamos correctamente, es decir nos autenticamos. En ella además podemos ver cómo incluso podríamos llevar a cabo una parada de la CPU, arranque o encender los leds.
Mientras que si definimos un usuario con menos privilegios podríamos no permitir la parada de la CPU, el arranque o encender los leds. Las posibles opciones quedan determinados en las opciones de la derecha.
Esta comprobación de una identidad puede hacerse bien de forma local o remota. Es decir, si las credenciales son comprobadas en el mismo equipo, aplicación, sistema o componente o si por el contrario se acude a un sistema externo como un servidor como Active Directory, LDAP, RADIUS o una solución comercial de un fabricante.
Por mi experiencia y, como norma general, estas comprobaciones en entornos industriales se realizan de manera local siendo las menos de manera centralizada, dependiendo de qué estemos hablando. Si es un PC de operador o de visualización que posee un sistema operativo de propósito general; si hablamos de un mini PC que administra una estación; un PLC; un HMI; etc. Etc.
Aunque hablemos de sistemas operativos de propósito general como Microsoft Windows o GNU/Linux hemos de tener en cuenta uno de los aspectos diferenciadores y es su ciclo de vida, mayor que los y entornos IT. Esto puede condicionar la forma en la que las nuevas funcionalidades o mejoras que presenten los mecanismos de Autenticación y Autorización dentro de las diferentes versiones de sistemas operativos o firmware. Por ejemplo, si tenemos un puesto de operador con Windows 7 y lo queremos integrar en un dominio con un controlador Windows Server 2019; o bien disponemos de un equipo con una versión GNU/Linux Debian y empleemos SAMBA.
Como vemos resulta necesario establecer los Controles de Acceso necesario, no sólo a nivel de red sino sobre los equipos finales a través de alguna de sus funcionalidades. Adicionalmente no vale sólo con establecer el control sino determinar qué cosas pueden realizarse. De nada no sirve establecer un usuario y contraseña si luego ese usuario tiene permisos administrativos cuando no debería tenerlos.
En próximas entradas pondremos algunos ejemplos sobre cómo podemos poner en práctica estas cuestiones sobre distintos ámbitos en tecnología OT.
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.
