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!

 

Identificando tráfico con cortafuegos, Parte I

Comentábamos en la entrada “Más que IPs y puertos para proteger entornos industriales” la necesidad de realizar un análisis del tráfico de red para identificar las comunicaciones existentes dentro de nuestro entorno OT. Con los activos y servicios localizados, podremos empezar a configurar las reglas necesarias en nuestros cortafuegos dentro de las acciones de “Separación y Segmentación” necesarias para limitar accesos o propagación de acciones que puedan afectar a la operatividad de nuestras instalaciones.

Sin embrago, debemos ir un paso más allá y conocer aquellos protocolos y comandos que permiten interactuar entre sistemas de control. Sin embargo, uno de los problemas más comunes es el alto grado de desconocimiento ya que, muy a menudo, nos enfrentamos a redes conmutadas o enrutadas donde todo comunica sin filtro alguno.

Esto cobra especial importancia, a nivel de célula de automatización, instalación o conjunto de equipos en planta; base de la actividad de las empresas. Sistemas superiores deben comunicar con controladores y éstos a su vez con elementos de periferia, como sensores, actuadores o cabeceras dentro de arquitecturas de periferia distribuida. Esto da lugar a en muchas ocasiones a que PLCs dispongan de dobles en laces de red. Por ejemplo, un módulo de comunicaciones para su integración “aguas arriba” con la red corporativa y otra “aguas abajo” de la propia CPU para entradas, salidas y módulos de conexión de dentro arquitecturas descentralizadas.

Como bien sabemos las latencias en este tipo de entornos son un aspecto crítico ya que las comunicaciones deben de hacer frente al carácter determinístico de éstas. Por tanto, debamos donde debamos identificar el tráfico no podemos introducir tiempos adicionales que puedan interferir en la operación.

Por tanto, surgen pues dos necesidades, documentar nuestras comunicaciones independientemente del segmento; y el despliegue de nuevos elementos de seguridad perimetral para separar y segmentar nuestras redes IT y OT.

Gracias a las funcionalidades de los productos de algunos fabricantes podremos apoyarnos en alguna de ellas para hacer esto último.

Por ejemplo, el fabricante Fortinet nos permite la configuración de alguna de las interfaces físicas en un modo denominado “One-arm-Sniffer”. Este modo, a diferencia de las habituales para permitir o denegar el flujo de comunicaciones, permitirá analizar mediante los motores IPS y Control de Aplicación el tráfico enviado desde un puerto espejo un dispositivo TAP. En caso de coincidencia con alguna de las firmas, se genera el correspondiente log y registro, descartándose el tráfico recibido.

De esta manera podremos utilizar nuestro equipo Fortinet Fortigate como un IDS o detectar qué tráfico a nivel de capa 7 que como hablamos en la entrada “Más que IPs y Puertos para proteger entornos industriales”. 

En primer lugar, deberemos configurar la interfaz en el modo anteriormente indicado, a partir de lo cual nos aparecerán las distintas opciones como los motores de filtrado contra los cuales queremos analizar el tráfico recibido. Como vemos en la imagen siguiente en nuestro caso hemos elegido la interfaz número 4.

Luego dentro de “Edit Sniffer Profile” podremos configurar cada uno de los motores y por tanto y ajustarlo en función de nuestras necesidades. En nuestro caso, puesto que planteamos el escenario de identificación de las comunicaciones y los protocolos industriales nos centraremos en éstos.

Para la presente entrada he empleado la herramienta TCPreplay para la reproducción de capturas PCAP.

De esta manera, el Firewall nos ha identificado no sólo un buen conjunto de ellos sino además los comandos que a través de ellos se envían. Como podemos ver en la imagen siguiente dentro de Modbus encontramos “Modbus_Function.Reserved.Code” y “Modbus_Read_Coils” entre otras como “S7.Protocol_CPU-Function.Read.SZL” o “DNP3_Response”.

Dependiendo de la arquitectura que tenga en nuestras instalaciones de planta las opciones podrán ser diversas, aparte de dónde radique el interés o necesidad por identificar ese tráfico. Es decir, podremos desplegar su uso a nivel de célula para conocer cómo un HMI, un PLC o periferia intercambian información; o bien, cómo desde servidores SCADA o MES envían o reciben consultas sobre equipos de planta para labores de control de producción, monitorización, telemetría entre otras.

En cualquiera de los casos, la idea es explotar otra funcionalidad de los cortafuegos que vayamos a desplegar y en la que nos podremos apoyar para la identificación de comunicaciones. Quizás no tengamos herramientas como “Nozomi SCADAGuardian” pero alternativas, las tenemos.

No obstante Fortinet no es el único. Próximamente presentaremos una funcionalidad similar, pero de otro fabricante.

¡Un saludo, nos vemos en la próxima!