Archivo de la categoría: Automatización

Gestión de redes y Ciberseguridad

Posted on por
Responder

Para que podamos bastionar, configurar, habilitar o deshabilitar servicios, características o funcionalidades de los equipos presentes en los entornos industriales, plantas, talleres, maquinaria, células de automatización, etc. éstos deben de ser capaces de ser administrables. Es decir, poder acceder a ellos bien de forma local o remota, a través de una interfaz gráfica, de texto o cliente software, y así poder llevar a cabo cambios sobre sus prestaciones.

En paralelo, con el creciente aumento de la conectividad los switches juegan un papel fundamental ya que es el primer elemento que permite a los dispositivos a ellos acceder a otros por medio de una red, bien Ethernet o Ethernet Industrial. Sí, una cosa son las comunicaciones en los entornos de oficinas o IT (Ethernet) y otra muy distinta la red de planta, periferia, o buses de campo sobre Ethernet Industrial.

Desafortunadamente, bien por cuestiones económicas o desconocimiento, la existencia de estos equipos no gestionados es muy muy amplia. Así como en entornos IT nadie imagina no poder configurar una VLAN, tener una interfaz de administración, configurar un puerto espejo, etc. en los entornos OT es muy común no disponer de ello.

Esto hace que cualquier equipo va a tener total visibilidad sobre los elementos de su subred por estar en el mismo dominio de Broadcast pudiendo descubrir bien a través de protocolos como LLDP, peticiones ARP, etc. los equipos allí presentes. Si esto lo sumamos a la existencia de redes planas en la que o no hay o todo es la misma VLAN el alcance es mucho mayor.

Menú de configuración switch Phoenix Contact

A esto hay que sumar la posibilidad que terceros, esto son ingenierías o proveedores, puedan conectarse a nuestras redes para llevar a cabo intervenciones programadas o puestas en marcha, lo que sumado a una falta de implementación de controles de acceso podría dar lugar al robo, copia o modificación no autorizada de desarrollos, programaciones, configuraciones o parametrizaciones hechas por cada uno de ellos. Y que dicho sea de paso puedan ser nuestra competencia.

Por ello desde un punto de vista de aplicación de seguridad en redes es vital que debamos desplegar switches que sean gestionables para poder aplicar esos controles y que un switch no gestionable no podrá. Pasamos de comunicar todo con todo, tener plena visibilidad a decir esto sólo debe comunicarse con esto y sólo esto debe verse con aquello.

Esto nos va a permitir aplicar de manera más eficiente estrategias como la microsegmentación o aplicar un control de accesos a más bajo nivel para aquellos escenarios donde tengamos que reducir el nivel de exposición de equipos más críticos. También es cierto que existen cortafuegos que permiten operar en capa 2. Por ejemplo, en modo “Transparent” para productos del fabricante Fortinet, “Virtual Wire” para Palo Alto o SCALANCE de SIEMENS.

En la teoría esto es un gran recurso, pero lamentablemente todo tiene un precio, tanto de adquisición como de mantenimiento. Comprar un NGFW y no renovar las licencias de soporte y actualización, poca protección nos va a ofrecer más allá de la capa 4. Aparte, claro está, que cada uno de ellos va a constituir un único punto de fallo, salvo que los despleguemos en HA (Activo-Pasivo; Activo-Activo) donde su coste será mayor.

Por ello resulta necesario que todo cuanto pueda aplicarse desde la electrónica de red, necesaria para el funcionamiento debe aplicarse. Así podrán llevarse a cabo una reducción del grado de exposición y delimitar los tráficos antes de que otro elemento como puede ser un de ser un cortafuegos, pueda llevar un filtrado sobre los paquetes o tramas.

Interfaz de gestión de Switch SIEMENS XC 208

Pero esto no es lo único que deberemos tener presente. Los equipos gestionables al poseer una interfaz para el acceso, bien gráfica o CLI a la que también debe aplicarse medidas de control, des habilitar funcionalidades no utilizadas, emplear protocolos que ofrezcan medidas para garantizar la confidencialidad por ejemplo de credenciales, etc.

Si un usuario no autorizado ganase acceso podría en un momento dado cambiar parámetros que pudieran generar inestabilidad en las comunicaciones, impedir acceso legítimo, creación de nuevos usuarios, entre otras muchas opciones. Por ejemplo, según la siguiente imagen des habilitar la redundancia para una topología en anillo.

Configuración de topología en anillo en switch SIEMENS XC208

Hasta aquí la entrada de hoy. Nos vemos en las siguiente donde trataremos más aspectos de sobre la protección de redes industriales.

Autenticación y Autorización, protegiendo proyectos. Parte II.

Posted on por
1

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!

Un saludo

Autenticación y Autorización, conceptos básicos

Posted on por
1

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.

¡Nos vemos en la siguiente!