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

Following Part I and Part II, we will give another example why OT monitoring is necessary to have a look about what is happing in industrial environment. The last one finished if somebody connected their laptop to the network and then to a PLC. Today, we will see what happens if somebody, that is, a third party, contractor, support team, etc. carries out a task that requires that the PLC CPU goes to STOP and the process, as well.

Having said this, imagine a manufacturing plant in operation and during an intervention, an engineer puts online and accidentally sends a STOP command by STEP7 software or something similar that requires it. Obviously other scenario can be a targeted attack on an exposed controller in the network.

If this occurs a message will appear in “Alerts” tab with score of “10” in the risk column. In the picture below we can see the steps since the PC (IP: 10.10.201. 103)  establishes connection with the CPU (IP, 10.10.201.102) by COTP protocol and sends STOP and START requests.

If we open both alerts, we will find more information of the source, its MAC and IP address, port, protocol, direction and so on.

For troubleshooting purposes, we can download a trace of the packets to find more low-level information. After that we are able to open it with a network protocol analyzer.

This example has been done once Guardian is in Protecting mode. Before this, we have to configure the tool in a “Listening” mode to learn about the asset, protocol, communication, behavior, etc. to take a picture of the network and everything it contains.

If this event occurs during this time, the alert can be different. In this case the alert will be scored with 9 and 6 values, respectively. In the first example we have to remember that the device from which we send STOP command, has not been discovered during “Listening” phase so the tool will categorize the action with a higher value.

Until now, we talked about a concise command. But if the CPU is not protected as I wrote in previous posts.

So, we can go one step ahead and think that if we can reach the PLC to STOP and START the CPU we could access and download it’s program. If it can be done, we could modify it and then upload it again to cause error condition, alter variables, configure passwords in order to do not permit legitimate access, and so on. If this occurs, we could identify it as shown in the  following picture.

Today we have analyzed different actions that can be identified by Nozomi Guardian monitoring tool, it can help us to detect actions that could alter normal operations. After this, we could start to investigate how a machine tool, production line or other facility stops without any reason.

However, it is important to remark that before deploying any security monitoring tool, an organization should have carried out other technical actions. One of them is to separate and segregate IT and OT environments. To do so, it is necessary to identify, analyze and decide which traffic must be permitted to pass across our firewalls. Once it has be done, we will have the criteria to say if what is happening is a normal or abnormal behavior. In other words, if we do not identify and understand which workstations  can access  industrial equipment and implement a strict change management process, we will not have the capacity to discover the root cause of the alert. Does somebody act on a PLC? Is it an attack? Has the communication module  failed?

These tools are useful solution if we implement it on stable, well-know and secure OT network.

Thanks for reading the post! See you!!

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

Siguiendo con la Parte I sobre “Visibilidad y detección de anomalías” comenzaremos un conjunto de ejemplos sobre cómo estas herramientas especializadas pueden ayudarnos a detectar ciertas situaciones.

Pongamos el primero. Un equipo ajeno a nuestra organización se conecta a la red de fábrica para llevar cabo una intervención por parte de un tercero. Esto es, un proveedor, una ingeniería. Algo muy habitual, y necesario, dado el grado de especialización que requiere la puesta en marcha o mantenimiento de maquinaria. ¿Y por qué digo necesario? Porque, salvo aspectos previamente acordados, esta tarea es llevada por los fabricantes de esa maquinaria.

Para ello se firman contratos de soporte que garantizan tiempos de respuesta, intervenciones programadas según necesidades, etc.. Y claro está, deberán de utilizar sus propios equipos. Los mismos donde tienen instalado el software y herramientas necesarias para hacer su trabajo y que como sabemos el precio de las licencias no suele ser especialmente económico como para que asuma el coste el propietario cuando él lo que contrata es un servicio.

Por ello, y otras razones es que esta situación es inevitable en muchos entornos y asumir que un equipo del que no sabemos a priori de su estado de protección, uso se le ha dado, a qué redes se ha conectado, software instalado, entre otras; es inevitable.

Dado que este equipo no ha sido registrado en el “período de aprendizaje” una vez conectado a la red y gracias a la replicación de tráfico a través del puerto espejo es que Nozomi Guardian detecta que tanto MAC como IP, genera una alerta categorizada como “10”.

Si accedemos al detalle de este podremos ver de una manera desglosada todas las acciones que ha intentado llevar a cabo.

En la parte inferior, además, vendrá representada de manera gráfica las IPs, protocolos y sentidos contra los que se quiere establecer comunicaciones. Esto aporta un grado de intuitividad y simplicidad importante cara a interpretar la información, lo cual ayuda a la persona encargada de atender las alarmas como la resolución DNS contra los servidores de Google. Adicionalmente a la derecha entontaremos información complementaria como Sistema operativo, tipo de nodo, MAC, IP, entre otras.Ahora bien, hasta aquí no deja de ser un comportamiento al uso, Ahora bien, ¿cómo se vería por ejemplo si quisiera ponerse online con la CPU de un PLC? En este caso he elegido SIEMENS STEP7?

Pues bien podríamos ver algo así:

Como podemos ver en este caso ya vemos protocolos COTP y S7 aparte de otras alertas como “NEW-FUNC-CODE” propias de esta conexión.

A partir de aquí ya habrá que determinar la acción a tomar como puede ser si se trata de un falto positivo, intervención sin notificación previa a responsables, registro, tratamiento, etc. Tan importante es detectar las anomalías como saber qué hacemos con ellas, por lo que deberá existir un procedimiento de actuación y escalado para determinar qué hacer.

Hasta aquí ejemplo de qué es lo que veríamos en caso de que un nuevo nodo aparezca en nuestra red.

¡Nos vemos en la próxima!

¡Un saludo!

 

Recolectando tráfico con Nozomi Guardian

Aunque en entornos industriales hay, y seguirá, habiendo por mucho tiempo comunicaciones basadas en protocolos serie, existe una clara tendencia hacia el uso de aquéllos basados en Ethernet. Este hecho que, aunque no resulta fácil por el impacto y consumos de recursos de tiempo, dinero y humanos aporta, entre otras, una escalabilidad e interoperabilidad mucho mayor.

Sin embargo, esto tiene su parte negativa ya que la superficie de exposición aumenta exponencialmente. Es por ello que resulta necesario implementar medidas capaces de reducir los riesgos de sufrir un incidente y por ende alterar el normal funcionamiento de la instalación.

Al igual que sucede en las redes de datos tradicionales, también en este tipo de entornos es necesario llevar a cabo una captura de tráfico para realizar un análisis a bajo nivel. Para conseguirlo recurrir a un puerto espejo alguno de los switches o un dispositivo TAP tal y como hablábamos en las dos siguientes entradas.

Puerto espejo, un aliado a veces olvidado

TAP Devices, SIEMENS TAP 104

Luego le llegará la hora de la parte software. Si bien la herramienta estrella es Wireshark la cual cuenta con la capacidad de analizar el contenido de protocolos industriales, también podremos recurrir a otras como Grassmarlin ya en su última versión 3.2.

Sin embargo, existen otras soluciones propietarias que también tiene la capacidad de recolección y análisis. Hace unos meses hablaba en concreto de la del fabricante Nozomi y su producto Guardian.

Monitorización redes industriales, SCADAGuardian

Este producto gracias al desarrollo de nuevas capacidades, mejoras, acuerdos con compañías líderes del sector ha hecho que tenga una gran presencia en el mercado situándose como la de referencia en el mercado.

Una vez desplegada la sonda en el segmento en cuestión, ésta comenzará a analizar y procesar el tráfico recibido para luego opcionalmente recolectarlo para una descarga estudio posterior. Para ello deberemos aplicar un filtro concreto, como puede ser una dirección de origen, destino, protocolo, puerto o cualquier otro paraámetro que pueda ser proporcionado o soportado.

Dicho lo cual, para hacerlo, dentro del menú principal, deberemos de acudir al menú “admin – Other actions”.

Allí deberemos de seleccionar “Continous trace” y acceder al menú correspondiente.

El siguiente punto, tal y como indicábamos anteriormente, habrá  indicar el filtro que queremos aplicar. En nuestro caso será lo relativo con la dirección 192.168.1.XX. Tras seleccionar “Start” comenzará la captura y que veremos en la parte inferior en la imagen siguiente.

A medida que se vaya cumpliendo la condición especificada, Nozomi Guardian irá almacenando el tráfico que más tarde podremos descargar. Para ello deberemos seleccionar el cuarto de los iconos de la parte inferior. Allí aparecerán todos los ficheros generados hasta ese entonces. A partir de aquí,  como decíamos, bien con Wiresahrk o cualquier otra herramienta podremos analizarlo con detalle.

No obstante, también podremos hacerlo son la misma herramienta. Para ello deberemos ir a “Administration – System – Upload PCAPs” tal y como viene indicado en la imagen siguiente:

Allí bastaría con subir la captura y reproducirla presionando en el icono que se indica.

Como podemos comprobar este tipo de herramientas además de informarnos de los activos, comunicaciones, integración con SIEM, informarnos de anomalías, potenciales vulnerabilidades, entre otras muchas más opciones, también nos permite recolectar el tráfico que pueda capturar. Esto resulta de gran importancia y vitalidad ya nos permitirá analizar a bajo nivel los flujos de comunicaciones y detectar anomalías de distinta índole.

 

Un saludo, nos vemos en la siguiente!