Archivo de la categoría: Infraestructura de red

Separación, segmentación, comunicaciones, seguridad perimetral y electrónica de red.

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.

Phoenix Contact Switch confguration

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.

Pasarelas Serie/Ethernet y seguridad asociada

Posted on por
Responder

Son muchos los factores que intervienen en posibilidad de sufrir un incidente de seguridad en un entorno industrial. Las vulnerabilidades no sólo afectan a cuestiones técnicas sino también en cuanto a organización, arquitectura en componentes, políticas, procedimientos, etc.

Uno de los más importantes es el progresivo aumento en el grado de exposición de sistemas y componentes a través de su conexión a redes. Los motivos y propósitos pueden ser muy variados, desde la recogida de datos para mejora de coeficiente OEE, telemetría, diagnosis, soporte remoto, envío de programas y recetas, entre muchos otros.

Sin embargo, muchos de ellos no disponen de conexiones Ethernet tal y como conocemos en redes IT. Las comunicaciones serie RS-485, RS-232 están muy muy extendidas y seguirán estando. La migración a aquéllas supone una inversión de recursos que pueden ir desde el despliegue de nuevo cableado, nuevos módulos de comunicaciones, ajuste de programas en controladores, cambio de hardware, etc. que pueden hacerlo inviable o no ser razón suficiente para ello.

Para su integración se pueden emplear las denominadas pasarelas en los que nos permitirán la integración de una a otra. Es decir, por un lado, tenemos una conexión serie y, en la otra, Ethernet, tal y como e muestra en las imágenes siguientes.

Estos dispositivos a menudo pasar desapercibidos, pero también deben ser foco de atención desde el punto de vista de la Seguridad ya que un simple cambio en la dirección IP, valores en la comunicación serie, borrado de configuración, podría dejar sin comunicación al equipo final.

Por ello aspectos tan básicos como la asignación de una contraseña, cambiar la que viene por defecto, o restringir su acceso mediante los cortafuegos perimetrales son tareas a realizar de manera obligada. También, según modelos, la definición de una ACL, Lista de Control de Acceso en la indiquemos desde qué direcciones IP podremos conectarnos y hacer cambios.

No obstante, estos dispositivos cuentan con alguna otra funcionalidad que también conviene mencionar. Como sabemos resulta necesario ejercer una monitorización de nuestros dispositivos y componentes, y una de las maneras es el envío eventos como puede ser por Syslog o SNMP. A partir de la recepción del log en cuestión podremos habilitar o desencadenar otras acciones o al menos ser consciente de la ocurrencia del hecho.

Así pues, en este caso en concreto la pasarela nos permitirá hacerlo bien por SNMP o envío de correo electrónico, para lo cual deberemos proporcionar los valores oportunos.

Claro está otra de las recomendaciones es emplear estos recursos a través de versiones seguras, es decir, SNMPv3 en lugar de SNMPv1, SNMPv2c, sin embargo, esto no siempre estará disponible. Todo dependerá de lo nuevo o viejo del equipo o versión de firmware si es que a través de una actualización se puede conseguir tales versiones seguras.

Finalmente habrá que definir sobre qué eventos querremos ser informados y sobre qué medio, correo o Trap de SNMP.

Las pasarelas juegan un papel muy importante cara integrar equipos con comunicaciones serie en redes Ethernet. Sin embargo, también debemos de cuidar su acceso ya que de ganarse, bien por una mala configuración, una vulnerabilidad, un permiso excesivo, la falta de asignación de contraseñas, etc. algo o alguien podría efectuar un cambio y dejarnos sin conectividad. Y claro, hecho esto, un posible impacto en las operaciones de aquello que esté detrás, una máquina, un Centro de Transformación, un controlador numérico o cualquier otro componentes o sistema.

Así pues, no las dejemos de lado y dediquémosles la atención que merecen.

Un saludo!

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

Posted on por

El progresivo aumento de buses de campo y protocolos basados en tecnología Ethernet y otros sistemas, hace que nuestros activos tecnológicos estén cada vez más visibles por la red que los une. Sin duda, esto trae consigo múltiples beneficios, pero también riesgos que deberemos mitigar, reducir o transferir hasta un punto en el que sean asumibles por las organizaciones. El riesgo cero no existe y la seguridad al 100% tampoco.

Con la llegada de Ethernet, la superficie de exposición aumenta, y lo hace para poder ganar acceso y recolectar información de los dispositivos sobre los cuales se basa el tan citado “proceso”. Sin embargo, esto sucede tanto para bueno como para lo malo. Y es que, para ganar flexibilidad, escalabilidad, interoperabilidad y prestaciones, tenemos que pagar un precio.

Adicionalmente, vemos cómo las amenazas y acciones malintencionadas sobre los sistemas de control, y otros coligados a éstos, van en aumento. Y lo hacen, entre otras razones, por el beneficio económico que éstas pueden generar para el que la lleva a cabo. Aparte de la propia idea del sabotaje, por supuesto. Y claro, entre que la seguridad no ha sido un requisito, el continuo reporte de vulnerabilidades, las dificultades por corregirlas, la posibilidad de acceder de forma local o remota por red, y falta de medidas de seguridad hace que se genere una situación de lo más propensa.

Es por ello que sea necesario que, una vez acometidas las acciones necesarias a nivel de red como Separación y Segmentación y Deep Packet Inspection, o a nivel de equipo final en PLCs o equipos basado en arquitectura PC basado en Whitelisting, debamos tener visibilidad de lo que pasa en nuestro entorno de planta. Es decir, monitorizar su comportamiento y por tanto tener un mecanismo de alerta temprana ante anomalías.

Como ya comentamos existen en el mercado distintas soluciones entre ellas Nozomi Guardian. Con su versión 20.0 recién lanzada al mercado y en la que introducen numerosas mejoras respecto a su predecesora, veremos algunos ejemplos sobre su necesidad y ejemplos de utilidad. Para ello se partiremos del siguiente esquema.

En él hay representado un autómata virtualizado SIEMENS S7-300 con IP 10.10.201.102; un equipo portátil con IP 10.10.201.103 y una RTU 10.10.201.102. La sonda estará conectada a un puerto espejo donde se replicará el tráfico de los anteriores. La administración de la sonda Nozomi Guardian se realizará en otra del rango 10.10.101.10/24 donde se ubica el servidor que recolecta información de ambos, RTU y PLC. Sí, lo sé, las redes de administración deberían tener su propio segmento pero esto es un entorno de laboratorio. Como se puede apreciar el rango 10.10.201.0/24 pertenece a la de planta y 10.10.101.0/24 iDMZ.

Conviene recordar que en el momento de su despliegue hemos de establecer un período de aprendizaje en que la herramienta hará un perfilado de sobre los activos y comportamiento. A partir de aquí, empleará esta información para indicar la aparición de un nuevo activo, nodo, protocolo, variable, entre otros. La duración dependerá de varios factores como la ocurrencia de eventos que deban ser recogidos, tamaño de la red, equipos implicados, entorno, etc.

En este sentido para generar las alertas, se ha decidido establecer un período de aprendizaje “Learning” de aproximadamente, más o menos, 5 minutos para luego configurar en modo ”Protecting”.

Así pues, durante ese tiempo el sistema detecta los siguientes equipos:

A lo largo de sucesivas entradas iremos ejemplarizando distintos escenarios de riesgo a través de la herramienta Guardian de Nozomi Networks y de cómo se convierten en una necesidad una vez alcancemos un nivel de madurez mínimo.

Ahora bien, no pensemos que esto funciona solo. Deberemos tener un conocimiento mínimo de nuestra red para poder hacer una correcta gestión de las alertas que se nos generan y apoyarnos en otros como los cortafuegos. En ese sentido, y salvo que estos últimos operen en Capa 2 o tengan la capacidad de filtrar las comunicaciones dentro de la misma subred, no detectarán comunicaciones entre segmentos. Si no sabemos lo que es legítimo difícilmente podremos identificar lo anómalo, y por tanto tomar medidas correctoras para neutralizarlo.

¡Nos vemos en la próxima!

¡Un saludo!