Pasarelas Serie/Ethernet y seguridad asociada

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

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!

 

 

Identificando tráfico con cortafuegos, Parte II

Hablábamos en la entrada “Más que IPs y puertos para proteger entornos industriales” la necesidad de identificar los protocolos e instrucciones para limitar aquellas acciones que pueden realizar sobre Sistemas de Control Industrial. Para llevar a cabo esta acción, podemos emplear soluciones como Nozomi SCADAGuardian la cual, entre otras funciones, permite realizar Deep Packet Inspection (DPI) y extraer la información que necesitamos.

Sin embargo, los  mismos cortafuegos que nos ayudan a “Separar y Segmentar” podrán ayudarnos en esta tarea. En “Identificando tráfico con cortafuegos, Parte I” veíamos como podríamos hacerlo con equipamiento del fabricante Fortinet. En el día de hoy abordaremos la misma tarea, pero con aquellos del fabricante Palo Alto.

El mismo, dispone del equipo PA-220R para proteger este tipo de entornos teniendo la capacidad para realizar DPI sobre protocolos de esta índole. Además, es apto para instalaciones de entornos tales como subestaciones o plantas generadoras de energía ya que dispone de compatibilidad con estándares como IEC 61850-3 e IEEE 1613. Sus características físicas le permiten operar en rangos de temperatura y humedad de -40-70º C y 10-90%; respectivamente, pudiendo evitar daños físicos en entornos hostiles y polvo en suspensión ya que carece de piezas móviles para su refrigeración. Igualmente dispone de doble alimentación proporcionando así redundancia en lo que suministro eléctrico se refiere.

Dicho lo cual, veremos que las interfaces pueden ser configuradas de distintos modos, entre ellas el “TAP” con el que podremos monitorizar y analizar el tráfico que le llega.

Más tarde, definiremos una “Zona” en la cual incluir la interfaz que recibirá el tráfico que replicaremos desde el puerto espejo del switch o un dispositivo TAP. La denominaremos “Analisis_Trafico_ICS” y le asignaremos la interfaz “ethernet1/8”.

Luego, habrá que crear una política en la que deberemos indicar como origen y destino la Zona configurada en los puntos anteriores e indicar qué aplicaciones queremos detectar.  En nuestro caso seleccionaremos “Any” para poder hacerlo sobre todas aquellas que recojan las firmas que hayan sido desarrolladas hasta el momento.

Adicionalmente podremos habilitar otros controles para la detección de amenazas tales como antivirus, vulnerabilidades, filtrado URL, etc. Esto nos permitirá identificar la presencia de actividades o tráfico malicioso ya presente en nuestra red. Como se puede apreciar hemos creado un “Security Profile Group” con alguno de ellos.

Hecho esto, el siguiente paso será comenzar a procesar tráfico. De igual modo que hicimos en la entrada “Identificando tráfico con cortafuegos, Parte I”, reproduciremos tráfico con la herramienta TCPReplay previamente capturado a partir de distintas fuentes. En este nos hemos decantado por IEC 60870-5-104 y BACnet.

A partir de aquí, en la pestaña “Monitor” podremos ver los logs generados según distintos resultados de ese análisis. Por ejemplo, continuación se muestra el contenido relativo al tráfico en sí mismo, esto es, IPs de origen destino, puertos, Aplicación, etc.

Pero como hemos dicho, también nos interesa analizar en busca de amenazas como intentos de intrusión, malware, etc. Esta información la localizamos en el subapartado “Threat”. En este caso vemos cómo de entre las capturas reproducidas identificamos la presencia del archiconocido “Wannacry”, algunas anomalías relativas a Siemens S7 o DNP3.

Con la interoperabilidad entre entornos IT y OT, es imprescindible conocer las comunicaciones que se realizan hacia/desde los equipos. Un activo no sólo se compone de los datos de fabricante, modelo, instalación, etc. también han de incluirse sus comunicaciones dentro del modelo de gestión de activos. Un firewall y sus funcionalidades extras serán tan eficientes como estrictos seamos con su configuración y mantenimiento.

Pero, para conseguirlo, hemos hacer la tarea previa de identificarlas y estructurarlas y para ello los mismos cortafuegos también pueden ayudarnos.

Un saludo, ¡nos vemos en la siguiente!