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!

 

 

1 comentario en “Visibilidad y detección de anomalías, Parte I

  1. Pingback: Enredando con redes ...Visibilidad y detección de anomalías, Parte IIEnredando con redes …

Los comentarios están cerrados.