Industrial Control Network Cyber Security continuous monitoring

Monitorización continua de seguridad en redes de control
industrial utilizando patrones de comportamiento
Por Enrique Martín Garcia
Schneider Electric – Global Solutions
IT Consulting & Integration Services
C/ Valgrande, 6
28018 Alcobendas
Madrid – Spain
enrique.martingarcia@telvent.com

23 de Enero de 2014
2
Contenidos
Resumen ....................................................................... 2
Introducción.................................................................. 2
Fundamentos de la monitorización............................ 3
Redes IT versus Redes OT............................. 3
Matriz de conexión......................................... 4
Matriz de actividad......................................... 5
Matriz operacional ......................................... 5
Pruebas sobre la tecnología de monitorización ....... 6
Pruebas sobre la matriz de conexión.............. 6
Pruebas sobre la matriz operacional............... 8
IEC 61850 MMS operación anormal..................... 8
IEC 61850 longitud de cabecera anormal.............. 8
Pruebas sobre la matriz de actividad.............. 9
Conclusiones.............................................................. 10
Agradecimientos ........................................................ 10
Referencias ................................................................. 10
Resumen
Debido al gran crecimiento en sistemas de
control industrial basados en soluciones
comerciales (COTS) conectados por TCP/IP
[1], y a las amenazas asociadas a estos, la
monitorización continua del correcto
funcionamiento de las redes Operacionales
(OT) ha llegado a ser crucial para nuestro
bienestar y forma de vida. Las nuevas
tecnologías de monitorización, como la de
utilización de patrones de comportamiento
en redes de control, pueden ayudarnos a
ejecutar eficazmente estas tareas.
Introducción
Cuando hablamos de seguridad en este tipo
de redes industriales, tenemos que
enfocarnos en la disponibilidad y fiabilidad,
ya que los sistemas de control están
diseñados para trabajar 24x7 en tareas de
misión crítica que pueden ir desde el
transporte de la electricidad, gas y petróleo
que necesitamos, hasta el procesamiento del
agua que bebemos.
Todas estas tareas críticas dependen del
correcto comportamiento de los sistemas de
control industrial. Este comportamiento
puede ser interrumpido por cualquier
operación humana anormal no intencionada
o por una acción maliciosa con intenciones
políticas, económicas o terroristas. En
muchos casos, estos tipos de acciones son
realizadas por usuarios de la organización
[2], los cuales tienen los derechos, recursos
y algunas veces intenciones de interrumpir
las operaciones normales.
Para garantizar el correcto funcionamiento
de estos sistemas, se necesita estar alerta de
cualquier problema que pudiéramos
detectar a través de la monitorización
continua [3].
En este documento, proponemos la
monitorización continua mediante la
construcción de patrones de
comportamiento como método para

3
conseguir la mayor disponibilidad y seguridad de
nuestros activos.
Fundamentos de la monitorización
Redes IT versus Redes OT
En cualquier red IP en el mundo de las tecnologías
de la información (IT), hay tal variedad de
actividades con tal número de variantes, que se hace
extremadamente complicado el poder establecer
patrones de funcionamiento normales.
Un ejemplo que mostramos a continuación es el
registro de conexiones TCP abiertas al Puerto 80
(HTTP) que se generan después de navegar
solamente por 10 páginas Web:
Las páginas accedidas tienen las siguientes
categorías:
 Una página Web personal.
 Dos canales nacionales de TV
 Dos Bancos Nacionales
 Dos Tiendas online internacionales
 Dos periódicos
 Una Universidad Americana.
En la siguiente figura, podemos ver las conexiones
establecidas tras acceder solamente a 3 páginas.
En Internet hoy en día este comportamiento
es normal, y es producido debido al
diferente uso de servidores Web de
distribución de contenidos (adds, banners,
etc) y otras tecnologías de marketing que
están fuera de nuestro control
El tráfico IT no es solo HTTP, sino también
DNS, SMTP, POP3, IMAP, FTP y otros
servicios nuevos que pueden cambiar
rápidamente las conexiones de red
necesarias para ejecutar las operaciones.
En este escenario, está claro que no
podemos plantearnos tener un patrón de red
estable para poder el correcto
comportamiento operacional (BluePrint)

4
Cuando comparamos Redes IT con Redes de
Tecnología de Operaciones (OT), encontramos las
siguientes diferencias:
Redes OT Redes IT
Número de dispositivos IP Baja Alta
Servicios ejecutándose Baja Alta
Protocolos utilizados Baja Alta
Exposición internet Baja Alta
Número de amenazas Media Alta
Prioridad de la disponibilidad Alta Baja
Prioridad de la confidencialidad Baja Alta
Prioridad de la integridad Alta Media
Las redes de control industrial son:
 Menores en número de dispositivos y
servicios.
 No debieran conectarse directamente a
Internet.
 Bien definidas y diseñadas
 Ejecutan operaciones repetitivas.
En estas condiciones es fácil ver que construir un
patrón de comportamiento normal es posible,
permitiendo de esta manera que cualquier evento
fuera de este modelo pueda ser rápidamente
detectado y comunicado.
Para configurar nuestro sistema de monitorización
industrial basado en patrones de comportamiento,
debiéramos pensar en tres principios fundamentales:
 Qué va a donde (Matriz de conexión)
 Quién está haciendo qué (Matriz
operacional)
 A qué hora ocurre (Matriz de actividad)
Si tenemos un claro conocimiento de estos tres
puntos, podremos tener un sistema de
monitorización basado en patrones que pueda evitar
falsos positivos y proporcionar el mejor
rendimiento.
Este patrón de comportamiento va a proteger
nuestra Red industrial de cualquier operación
errónea o intento de interrupción malicioso.
Veamos esto en los siguientes puntos:
Matriz de conexión.
Cuando hablamos de Redes de control
TCP/IP tenemos que tener en cuenta que la
tupla (local ip, local port, remote ip, remote
port) es lo que define cada conexión
TCP/UDP. Cada dirección IP del servidor
normalmente puede utilizar hasta 65.536
puertos.
Dentro de la pila TCP, estos cuatro campos
son utilizados como claves compuestas para
asociar paquetes a conexiones.
Los puertos son números de 16 bits por lo
que el número máximo de conexiones que
cualquier cliente podrá tener a cualquier
puerto host es de 64.000.
Podemos calcular el máximo número de
conexiones externas en una red TCP,
usando la siguiente formula:
(No consideramos conexiones dentro del
mismo servidor).
Estos valores pueden crecer
exponencialmente en función del número de
servidores interconectados y del número de
puertos abiertos por cada servidor).

5
Cuando estudiamos el número de puertos abiertos
en una red de control industrial bien configurada,
encontramos los siguientes valores:
Nodo de la red de
control industrial
Puertos
abiertos
Suma de
los otros
Puertos
Conexiones
de red
potenciales
Vijeo Citect Scada
Server 16 101 1616
Vijeo Citect Client 10 107 1070
Network Switch 6 111 666
Unity Pro
Workstation 2 115 230
Radius & Syslog
server 16 101 1616
Historian Server 16 101 1616
Historian Client 9 108 972
WSUS, NTP &
SNMP Server 16 101 1616
Firewall 6 111 666
PLC Modicom
M340 8 109 872
PLC Modicom
Quantum 12 105 1260
Total 12200
Este valor perfectamente acotado en el número de
conexiones de red hace posible pensar en la
generación de un patrón de comportamiento bien
definido y manejable.
Este es otro principio básico de administración de
sistemas y seguridad: Cada sistema de control
industrial o desplegado en un entorno crítico tiene
que estar bastionado al máximo para reducir la
cantidad de recursos necesarios en su gestión y
minimizar los riesgos de intrusiones remotas
Por otro lado, la existencia de tablas de conexiones
correctamente documentadas, facilita el
mantenimiento de la red y mejora la resistencia de
la red en caso de problemas al ser más fácil la
detección de cualquier error en la configuración o
despliegue.
Matriz de actividad
Muchos sistemas de monitorización confían solo en
las operaciones que son permitidas en la red pero no
tienen en cuenta cuando se ejecutan. Este hecho es
importante si usuarios internos ejecutan operaciones
no apropiadas (De manera intencionada o
no intencionada)
Cada Red de control debería tener
procedimientos operacionales aprobados
que los usuarios deberían seguir cuando
realizan un acceso para ejecutar cualquier
operación, y estos procedimientos tendrían
que definir los horarios de cada posible
operación en la red.
Con esta información, deberíamos poder
definir una tabla que reflejase la relación
entre usuarios, procedimientos, acciones y
horarios.
Cualquier actividad fuera de esta tabla
debiera ser detectada, registrada y escalada
como un evento anormal.
Está claro que algunas operaciones como
reconfiguración del PLC o RTU,
actualización de la base de datos del
SCADA o cambios de estados en ejecución
de elementos de campo, tienen que ser bien
conocidas y ejecutarse una ventana de
operaciones definida por el administrador.
Más adelante mostraremos como la
utilización de calendarios facilita el poder
identificar operaciones inusuales o poco
normales en la red de producción y ser
escaladas apropiadamente.
Matriz operacional
Aunque muchos fabricantes de sistemas de
control soportan la existencia de diferentes
roles para el entorno operacional, es un
hecho que los grupos de trabajo muchas
veces usan el mismo usuario y clave para
ejecutar su trabajo, no utilizando algunas
veces estos roles de forma adecuada debido
a la facilidad o al temor de no ser capaces
de entrar en el sistema en situaciones
críticas.
El uso anónimo de los roles operaciones es
difícil de detectar y por tanto y podría hacer

6
imposible detectar un fallo humano o una
intervención maliciosa.
Más tarde mostraremos como la tecnología de
monitorización basada en patrones de
comportamiento puede utilizarse para detectar
comandos no permitidos ejecutados por usuarios
legítimos.
Pruebas sobre la tecnología de
monitorización
Una vez establecidos los principios y metodología
de monitorización de nuestra red de control, vamos
a presentar nuestras solución y como se comporta
en cada uno de estos aspectos.
La solución utilizada en el Área de Cyber Seguridad
está basada en una tecnología muy disruptiva que
construye el patrón de comportamiento de la red de
manera automática y desatendida.
El patrón de comportamiento construido por la
solución, define los modelos de conexión,
protocolos, tipos de mensaje, campos de mensaje y
valores de los campos que son permitidos en
nuestra red (Lista Blanca). De manera que cuando
una comunicación difiere del patrón, el sistema de
sensores lo reporta indicando la fuente exacta del
problema.
Esta tecnología es conocida como inspección
profunda del comportamiento de los paquetes
(DPBI)
Toda esta tecnología se implanta en un sensor
controlado desde un centro de gestión instalado
como un servidor físico o virtual llamado
SCAB. (Security Control Awareness Box)
Vamos a ver como los principales principios
de monitorización de redes industriales
funcionan en dispositivos de prueba en
nuestro CyberLab.
Pruebas sobre la matriz de conexión
Después de conectar los sensores del SCAB
a la red, podemos empezar la fase de
aprendizaje.
En esta fase, SCAB construye de manera
autónoma nuestro patrón de
comportamiento de red.

7
El flujo que sigue es mostrado a continuación:
Podemos personalizar el patrón de comportamiento
si es necesario con solo añadir, modificar o borrar
conexiones utilizando un editor de textos.
El sensor es capaz de reconocer e inspeccionar
distintos protocolos:
 OPC-DA
 MMS
 Modbus/TCP
 IEC 101/104
 ICCP
 IEC 61850
 RPC/DCOM,
 SMB/CIFS
 DNP3
 HTTP
 VNC
 RDP
Después de la finalización de la fase de aprendizaje,
tenemos el perfil de la comunicación local de la red
de control.
En este momento SCAB, conoce cada tupla
permitido en la red de control.
Src IP,Src Port -> Dest. IP,Dest Port
Esto es algo difícil de conseguir en una Red
Local multipropósito sin tener varios
cambios (Alertas) por hora.
Desde este instante, podemos ser alertados
por:
 Nuevos dispositivos en la red
 Dispositivos intentando conectarse a
nuestro modelo
 Dispositivos recibiendo información
de fuera de nuestro modelo.
Para conseguir estas alertas, tenemos que
cambiar los sensores del estado de
aprendizaje al estado de detección.
Hicimos un test muy sencillo después de
construir el modelo de red intentando
conectarnos desde 10.1.1.243 al puerto 502
en 10.1.31.10.
Como hay una clara violación del modelo,
obtenemos lo siguiente:
Descendiendo en el árbol de alerta,
podemos ver con mayor detalle la
descripción del perfil de violación de la
comunicación:

8
Pruebas sobre la matriz operacional
A pesar de que detectar conexiones no permitidas
en una red de control bien definida no parece muy
impresionante, es imprescindible hacerlo de manera
continua.
Esta funcionalidad es bien conocida pero no muy
útil cuando intentamos detectar operaciones
ejecutadas desde dispositivos válidos por usuarios
legítimos. Para la detección de estas acciones,
necesitamos utilizar la tecnología de inspección
profunda de comportamiento de paquetes (DPBI).
Una vez el patrón de red es creado, hay una
colección de conexiones (IP, puertos, destino IP,
puerto destino) protocolos y comandos permitidos.
Pero usando la tecnología DPBI, hay también
valores válidos o rangos de valores permitidos para
cada mensaje del protocolo en el modelo de Red
que SCAB ya ha creado.
Vamos a ver dos casos en un sistema crítico de
control de protocolos de red: IEC 61850 MMS.
IEC 61850 MMS operación anormal.
En este caso, hemos activado el sensor IEC 61850
DPBI en modo de aprendizaje en nuestro SCAB y
hemos ejecutado comandos usuales que no
incluyeron ninguna instrucción de “Borrar Fichero”.
Esto significa, que nuestra matriz operacional no
contiene este comando en el patrón de
comportamiento de la red.
Después de activar el modo de detección, y ejecutar
dichos comandos en la red, las alertas salen y la
acción es almacenada con la tiempo exacto de
ejecución , la IP y la información que podemos ver
en la siguiente figura
recorriendo los mensajes de violación
dentro del árbol, podemos ver el nombre del
fichero que ha sido borrado.
(IED_CONF.dat):
IEC 61850 longitud de cabecera anormal
Utilizando el mismo entorno de prueba
(MMS activado en el motor DPBI), hemos
enviado un mensaje desde la IP 10.1.1.243
con una cabecera de 1026 bytes a nuestro
puerto de simulación RTU en la IP
10.1.31.10.
El efecto de realizar esta acción, hizo que
los dispositivos de campo conectados a la
RTU no tuvieran respuesta (Negación de
servicio)
Una vez ejecutado este comando, el SCAB
detecta la fuente de la operación y la
dirección IP de destino.

9
Buscando la alerta en la figura, podemos ver el
valor exacto transmitido en la cabecera (1026) que
puede causar un problema potencialmente muy
serio.
En ambos casos los comandos fueron ejecutados
desde direcciones IP legítimas por usuarios
legítimos, y únicamente utilizando esta tecnología
pudieron ser detectados, registrados y comunicados.
Pruebas sobre la matriz de actividad
Las violaciones de los modelos de redes son
siempre detectadas y comunicadas, pero cuando
estas operaciones han sido ejecutadas fuera de los
tiempos de operación normales, tenemos que
tratarlas con mayor importancia.
El escenario más común es detectar las anomalías
en las horas no laborables (Vacaciones)
Como el periodo vacacional puede variar según el
país o la región, las fechas concretas pueden ser
configuradas utilizando las funcionalidades de
“Vacaciones” de manera que fechas independientes
o múltiples pueden ser añadidas a la lista de
vacaciones.
Utilizando los días de vacaciones, se pueden añadir
filtros de alerta y se puede mostrar las alertas
durante los días no laborables para tratarlos
de una manera prioritaria.
Hemos activado esta funcionalidad en esta
prueba definiendo el día de hoy como
festivo, de manera que las alertas fueran
filtradas y mostradas directamente.
Al producir distintas violaciones del modelo
de comportamiento de red, obtenemos el
siguiente resultado:
Todas las alarmas fueron detectadas y
comunicadas utilizando los filtros dado que
ocurrieron en un día no laborable.

10
Conclusiones
Parece claro que Organizaciones críticas han
entendido la necesidad de monitorizar de manera
continua su red operacional para poder detectar
cualquier anomalía que puede comprometer la
producción y los objetivos de negocio.
Aparte de desplegar los procedimientos apropiados
de seguridad en nuestra organización, nuestra
metodología establece tres fuentes de información
para conseguir la deseada seguridad operacional y
niveles de disponibilidad:
 Matriz de conexión
 Matriz operacional
 Matriz de actividad
Debiera haber una cuarta matriz describiendo el
intercambio de información de los dispositivos de
nuestra red industrial: La Matriz volumétrica.
Cuando se transmiten nuevos ficheros de
configuración, modificamos la base de datos de un
SCADA o modificamos ficheros de configuración
de los dispositivos de campo, utilizamos un rango
de valores bien definidos.
Es posible establecer el máximo y el mínimo de
estos valores en el tamaño de la información que
nuestra red de control está intercambiando entre los
diferentes dispositivos a través de las soluciones
basadas en flujos y en servidor.
Para mantener y gestionar toda esta información,
proponemos la solución SCAB, como una
herramienta útil en las redes SCADA para construir
un patrón comportamiento y detectar cualquier
problema causado por errores humanos o por
intentos malintencionados que puede comprometer
a nuestras redes.
La metodología y solución de sensores continúa
propuesta, permite examinar la configuración actual
de nuestra red y de sus comunicaciones
(dispositivos, aplicaciones, protocolos, tipos/valores
de mensajes), analizar la operatividad de la red,
detectar comunicaciones o cambios en la
configuración inesperados y despliegue de nuevos
dispositivos de campo, haciendo más fácil
mejorar la resiliencia de nuestra red de
control.
Agradecimientos
Me gustaría dar las gracias a DelI España e
Intel España por el soporte proporcionado a
los servidores de nuestro CyberLab.
Referencias
[1] S.M. Bellovin. “Security Problems
in the TCP/IP Protocol Suite”. Computer
Communication Review, Vol. 19, No. 2, pp.
32-48, April 1989.
[2] Suzanne Dawson, Heather Davis,
Richard Lynch and Others. “2013 State of
Cybercrime Survey”. The Software
Engineering Institute CERT Program at
Carnegie Mellon University. pp. 9-12, Jun
2013
[3] Dr. Sandro Etalle, Dr. Cliford
Gregory, Dr. Damiano Bolzoni, Dr.
Emmanuele Zambon, Dr. Daniel
Trivellato,“Monitoring Industrial Control
Systems to improve operations and
security”, Dic 2013.

Industrial Control Network Cyber Security continuous monitoring

Más contenido relacionado

Destacado (20)

Similar a Industrial Control Network Cyber Security continuous monitoring (20)

Más de Itconic (20)

Último (20)

Industrial Control Network Cyber Security continuous monitoring