ICSSPLOIT, paro de PLCs S7-300 y S7-400

Hola de nuevo. Siguiendo en la línea de herramientas orientadas a redes industriales, hoy le toca turno a ICSSPLOIT.

ICSSPLOIT es un framework dirigido a sistemas y protocolos de control industrial que puede sernos de utilidad en tareas como auditorías y labores de pentesting. Escrito en Python, presenta un aspecto similar al Metasploit, conservando la interfaz y la forma de interacción. Se trata de un software Open Source pudiéndolo descargar desde su sitio en Github. Allí podremos ver el conjunto de scanners, exploits, protocolos y clientes que soporta, y que esperemos vaya creciendo con el tiempo. Veamos un resumen.

Funcionalidades ICSSPLOIT_01

La herramienta viene preparada para Kali Linux incluyendo lo necesario para su funcionamiento. Sin embargo, si algo nos faltase, podríamos mirar su fichero “requirements” y llevar a cabo la instalación de los paquetes mediante:

pip install -r requirements

Así pues qué mejor manera que verla en acción con un ejemplo. En otras entradas he trabajado con simuladores pero en esta ocasión lo haré con un PLC Siemens S7-300 real. Por supuesto, en un entorno de laboratorio. Por si fuera poco, además lo haré en formato vídeo. Una novedad que he querido introducir gracias al creciente número de visitas que ha ido teniendo el blog. Así pues, a continuación, veremos cómo llevar a “STOP” tanto la CPU como el una tarjeta CP del autómata para luego revertir el proceso. Todo de forma remota. Ahí va!

 

Como decía, también es válido para los S7-400. A continuación muestro la captura con Wireshark sobre los paquetes enviados y recibidos. Comentar que el PLC tiene IP 192.168.0.1 y el PC 192.168.0.100 .

PLC A STOP_01

Y su arranque:

PLC A START_01

Hasta aquí la entrada de hoy. Corta, pero que con el vídeo espero haya sido ilustrativa y hayamos descubierto esta nueva herramienta que sin duda va a ser de mucha utilidad para los profesionales de la seguridad. En sucesivas entradas iremos descubriendo nuevas funcionalidad, poco a poco.

¡Un saludo, nos vemos en la siguiente!

Edorta

Puerto espejo, un aliado a veces olvidado.

Como hemos hablado en otras ocasiones, poco a poco se va extendiendo el uso de protocolos industriales basados en tecnología Ethernet en lugar de los tradicionales serie. Esto, si bien permite otra manera de interconexión, también abre nuevas posibilidades en la denominada Industria 4.0. Sin embargo, obliga a tomar cierto tipo de medidas en cuanto a Ciberseguridad se refiere ya que los dispositivos y sistemas que intervienen en los procesos de control y automatización no sólo comienzan a estar más expuestos sino que son susceptibles de sufrir los mismos problemas con ciertos agravantes.

No obstante, aunque se trate de comunicaciones Ethernet, los equipos de networking industrial no sólo conservan funcionalidades tradicionales, sino además otras propias de estos entornos como MRP en contraposición a STP, Spanning Tree Protocol.

Una que puede sernos de mucha utilidad, sin menospreciar a otras tantas, es la de “Port Mirroring” o Puerto Espejo. Esto es, la capacidad de un Switch para poder replicar el tráfico que pasa por dos o más puertos y enviarlo por un tercero. Para entender mejor este concepto haré un repaso sobre cómo funciona un switch. Aunque sea algo bastante obvio para Técnicos de Comunicaciones o Administradores, seguramente no lo sea tanto para otros de Mantenimiento o Ingenieros de Procesos.

Esquema_01

Pongamos un ejemplo con dos equipos llamados “HMI” y “PLC”. Para comunicarse el equipo “HMI” con el “PLC” deberá conocer la IP del de “destino” y, al darse cuenta que está dentro de su misma red, deberá obtener entonces la MAC de éste. Para ello echará mano del protocolo ARP. El protocolo ARP permite conocer la dirección MAC de un equipo a partir de una IP conocida. Por tanto, si “HMI” no la tiene almacenada en su caché ARP  deberá realizar un ARP request. Es decir, preguntará a toda su red sobre cuál es la MAC del equipo con IP XXX.XXX.XXX.XXX. En este caso la dirección MAC de destino será ff:ff:ff:ff:ff:ff, un broadcast de capa 2. Todos los equipos la recibirán y la procesarán pero sólo el que tenga la IP por la cual se pregunta contestará con un ARP Replydiciendo “–La MAC de la IP XXX.XXX.XXX.XXX es XX:XX:XX:XX:XX:XX. Conocida por “HMI” tanto la IP y MAC de “destino”, se producirá la comunicación. Si por el motivo que sea no se conocen algunos de estos campos, la comunicación no se produce.

Así pues, un Switch, a diferencia, de los Hubs introduce un nivel de “inteligencia”. Un switch contiene una tabla, denominada CAM (Content-Addresseable Memory) en la cual se incluyen las direcciones MAC de cada uno de los equipos conectados a los distintos puertos del switch. Para realizar las tareas de conmutación, acudirá a ella para saber por cuál de ellos deberá enviar el tráfico en función de la MAC de destino. Esta asignación de direcciones MAC podrá hacerse de forma dinámica o manual. La forma manual implica que el administrador asigne a cada puerto del switch la MAC del equipo conectado; mientras que la forma dinámica se basa en que por cada trama que ingrese por cada boca del switch, éste mirará la MAC de origen y la incluirá en la CAM. Pasado cierto tiempo, si no se recibe tráfico se borrará dicho registro. Así, a la hora de efectuar la comunicación, los switches se fijarán en la MAC de destino, consultarán dicha tabla para saber por qué puerto deben enviarla y la “despacharán”.

Ahora bien, si por distintas razones necesitásemos conocer el tráfico que pasa en entre “HMI” y “PLC”, no podríamos conseguirlo ya que el switch sólo conmuta el tráfico por los puertos involucrados. Aquí es donde aparece el concepto de “Port Mirroring” o “Puerto Espejo”. Mediante esta funcionalidad lo que conseguimos es que el switch haga una copia de dicho tráfico y lo envíe por un tercer puerto. ¿Con qué finalidad? Por ejemplo, si en este último conectamos un analizador de tráfico, podremos estudiar todo aquello que suceda entre “HMI” y “PLC” y detectar posibles anomalías sin interferir entre el flujo de comunicaciones. Obviamente el switch tiene que tener esta capacidad para hacerlo, sino… no hay nada que hacer.

Si bien las tasas de transferencia en entornos OT son menores que en entornos IT, esto no quita que debamos tener presente algunas consideraciones. Por ejemplo, si las comunicaciones son Full-Duplex (enviar y recibir a la vez) y el enlace es de 100 Mbps, el tráfico que puede llegar a recibir un equipo es de 200 Mbps, 100 Mbps para enviar y otros 100 Mbps para recibir. Si el enlace del puerto espejo es también a 100 Mbps el consumo de ancho de banda entre “HMI” y “PLC” no puede ser superior al 50%, ya que estaríamos superando la capacidad del mismo. O bien, que sea de una velocidad inferior, por ejemplo, a 10 Mbps. En esos casos, el switch descartaría paquetes con lo que el tráfico capturado no se correspondería con la realidad. Aparte, claro está, de la carga computacional que supone para la CPU del propio switch la copia de las tramas. A esto hay que sumar otras limitaciones que cada fabricante pueda considerar en sus productos.

Sin duda es un buen recurso, pero como comento, hay que tener en cuenta algunos aspectos técnicos.

A continuación, pondré ejemplos sobre su implementación en equipos. En la siguiente imagen se muestra una captura de la configuración de un switch Mikrotik RouterBoard 260GS, el cual dispone de 5 puertos RJ-45 10/100/1000 + 1 SFP.

config Mikrotik RouterBoard_01

Según cómo está configurado, estaríamos haciendo una copia del tráfico tanto saliente como entrante del puerto 1 que es dónde en teoría habría conectado un PLC y la enviaríamos por el puerto 2 donde conectaríamos un sniffer que lo recogería para un posterior análisis. Un clásico de este tipo de funciones es el archiconocido Wireshark. También podríamos seleccionar sólo uno de los sentidos, o bien el saliente o entrante según sean nuestras necesidades.

Captura Wireshark_01

Lo cierto es que ese dispositivo resulta de mucha utilidad ya que por su pequeño formato puede ser utilizado en tareas sobre equipos finales como supervisión, diagnóstico, troubleshooting, etc. Aparte, al disponer de un módulo SFP podremos conectarlo a enlaces de fibra o par de cobre.

Ya sobre equipos de red tradicionales, podemos poner un ejemplo con switches Cisco. La funcionalidad la recoge este fabricante como puerto SPAN (Switched Port Analyzer). Aquí las posibilidades, como es lógico, son mayores y pasamos a la interfaz de consola. Podéis encontrar más información en este enlace.

Hasta ahora hemos visto switches “tradicionales”, sin embargo otros específicos de entornos OT también poseen esta funcionalidad como los muestra SIEMENS en este enlace y de donde se extraen las siguientes imágenes.

SIEMENS_Port_Mirroring_01

SIEMENS_Port_Mirroring_02

Sin embargo esto no es exclusivo de equipos de networking. Por ejemplo, el fabricante Fortinet la incluye en sus dispositivos. A continuación se muestran capturas sobre un FortiWifi 60D con versión de FortiOS 5.4.5. Como podemos ver la forma de acceder a ella es a través del apartado de “Interfaces”.

Fortigate SPAN_01

En mi caso “HW_SW_01”, y ya en su configuración veremos el campo correspondiente:

Fortigate SPAN_02

Como vemos el criterio es similar, interfaz a monitorizar y a hacia cuál queremos enviar la copia de los paquetes. Haciendo una prueba, he conectado en el puerto “internal1” un servidor Modbus (10.10.10.100) y desde el puerto “internal2” (10.10.10.200) el cliente desde cual hacer las lecturas. Finalmente, un equipo con Wireshark en el puerto “internal3” donde capturar el tráfico.

Wireshark_Modbus_01

Un caso de uso podría ser en un equipo donde se le aplique una estrategia de “Virtual Patching” y necesitemos saber qué es lo que está sucediendo desde, hacia, él. Hace tiempo escribí a este respecto, os dejo los enlaces:

Hasta aquí la entrada de hoy con la que espero hayáis podido descubrir una nueva funcionalidad de vuestros equipos. Puede que escondida, pero seguro de utilidad en un futuro. Las aplicaciones pueden ser varias, espero poder escribir sobre alguna de ellas. Sólo falta tiempo.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Edorta

Proveedores Externos, posible punto de entrada… 

Como bien sabemos la seguridad no es algo que se acaba con la implementación de un conjunto de medidas técnicas y la definición de unas políticas que prevengan que algo o alguien cause un daño en nuestra organización. En el caso concreto de los entornos industriales, esto además puede repercutir no sólo en un punto de vista lógico sino además afectar en los elementos físicos de las instalaciones.

A la hora de llevar a cabo un proyecto se ha de realizar un análisis de riesgos que evalúe y cuantifique el nivel en el que una organización está expuesta a sufrir un incidente de seguridad considerando, entre otros, las amenazas, vectores de ataque y vulnerabilidades. Sin embargo, estos aspectos pueden cambiar con el paso del tiempo, en particular las vulnerabilidades ya que, como podemos comprobar, la aparición de nuevas es algo continuo. Por tanto, los niveles que resultan satisfactorios a día de, un año después pueden no serlo, siendo la ciberseguridad  un proceso vivo que debe revisarse y ajustarse.

Una de las circunstancias a las que nos vamos a enfrentar, y que muchas veces nos olvidamos, es la existencia de gran cantidad de proveedores dentro de las organizaciones industriales. Las mismas recurren a productos y servicios especializados de terceros que luego deben ser soportados durante su ciclo de vida y garantizar así un respaldo en caso de incidencias.

Para poder llevar a cabo las respectivas tareas, los técnicos de estos proveedores deberán en algún momento, conectarse a la red de operación. Y esto presenta un problema, ya que:

  1. En muchas ocasiones contarán con un software propietario con licencias asignadas a ese equipo dificultando, o no siendo posible, reasignarlas a otro de la propia organización.
  1. Por supuesto al ser un equipo de un tercero no sabemos el estado de actualización del sistema operativo.
  1. Como no, desconocimiento del uso responsable, o no, que se le ha dado por parte de su propietario o usuario.
  1. Puesto que se tratarán de equipos portátiles para disponer de movilidad para llevarlos a tal o cual cliente, vaya uno a saber a qué otras redes han estado conectados.
  1. Y ya para rematar, como no puede ser de otra manera, usuario con permisos de administración y contraseñas de dominio público para que sea quien sea el que lo utilice, lo pueda hacer con total libertad.

Con todo lo dicho, ¿vamos a dejar conectarse a nuestra red equipos sobre el que no tenemos control o bien desconocemos el estado de actualización, limpieza, software instalado, etc? ¿Cómo encaja esta situación dentro de nuestras políticas? Y por si fuera poco, ¿si encima estos técnicos vienen del extranjero? ¿qué hacemos?

Indudablemente esto es una situación a la que deberemos hacer frente y necesariamente contemplarla dentro de nuestras políticas. Esto es, la gestión de los proveedores.

A este respecto deberemos tener en cuenta dos aspectos. Por un el administrativo y por otro, la solución técnica.

Desde el punto administrativo la organización deberá establecer un proceso donde se regule qué hay que hacer cuando un proveedor deba conectarse a nuestra red OT.

La primera de ellas es realizar un análisis de riesgos de este proveedor con lo que habrá que identificar:

  1. Necesidad justificada de la acción.
  2. Alcance de trabajos.
  3. Activos sobre los cuales se va a actuar.
  4. Información técnica sobre las intervenciones.
  5. Duración estimada.
  6. Recursos empleados.
  7. Manera en la que afecta a la organización.
  8. Análisis del impacto que tiene para la organización en caso de producirse un error y cómo afecta a aspectos tales como financiero, operativo, clientes y trabajadores.
  9. Representación gráfica tanto del riesgo existente como del residual si el primero no puede ser reducido o mitigado.

Otra de la información que tenemos que recoger son las necesidades de comunicación que van a tener. Esto es, direcciones IP, servicios, protocolos, etc. Esto mismo puede ser reflejado en un documento para que los administradores de los firewalls deban configurar los permisos correspondientes. Aquí dependerá de cada cual, pero importante valorar funcionalidades de los mismos en materia de:

  1. Portal Cautivo.
  2. Validación de reglas según validación de usuarios.
  3. Limitación temporal de permisos.
  4. Perfiles de seguridad concretos según labores a realizar.
  5. Otros.

Ya por último es importante considerar los acuerdos de confidencialidad y muy especialmente de responsabilidad. En cada intervención, por mucho que se planifique y se reduzcan las posibilidades de sufrir un incidente, el riesgo está. Por tanto, conviene acordar si fruto de esa intervención se deriva un error que afecte a la actividad de la instalación, y a su vez, un perjuicio económico a la empresa en cuestión.  ¿Quién las asume?

Una de las acciones que también debe  contemplarse, o deben realizarse, es hacer  un escáner de vulnerabilidades para conocer qué o cuáles pueden estar afectando al equipo de nuestro proveedor. Esto nos va a permitir exigir que antes de llevar a cabo cualquier trabajo deba actualizar los equipos o corregir las desviaciones antes de efectuar la conexión a nuestra red.

En el artículo de hoy hemos hecho una aproximación desde el punto de vista de que exista una VLAN dedicada a empresas externas donde toda comunicación contra otra red debe pasar por un Firewall (NGFW, Next Generation Firewall). Sin embargo, puede ocurrir que esta estrategia no sea efectiva dependiendo de la arquitectura y equipos que componen nuestras redes. Puede haber situaciones que sea necesario que los proveedores deban conectarse físicamente a la red control. Veamos la imagen siguiente:

El PLC tiene por un lado una tarjeta de comunicaciones que conecta con la red 192.168.1.0/24, y luego la propia de su CPU con el 192.168.10.0/24. Según el esquema inicial donde nuestro proveedor lo hace desde el entorno de oficinas debiendo pasar por los firewalls  de “Separación” y por el de “Segmentación”, no podría llegar a las interfaces de la red 192.168.10.0/24 ya que el PLC puede no tener la capacidad de llevar cabo el enrutamiento entre ambas. Sí que podríamos llegar a él por la red 192.168.1.0/24 y a través del software de configuración poder ver el resto de interfaces, pero si lo que queremos es llegar directamente a los sensores o actuadores de la periferia 192.168.10.0/24 que controla, por ejemplo por HTTP, S7, ModbusTCP, FTP, o cualquier otro (sea seguro, o no) seguramente no podamos hacerlo por esa falta de capacidad.

Por tanto, he aquí un problema añadido y es que, ¿Dejamos conectar a ese proveedor su PC y que se efectúen las comunicaciones en Capa 2? ¿Cuáles son los riesgos a los que nos enfrentamos si no tenemos ningún cortafuegos que filtre las comunicaciones? ¿Cómo hacemos frente a estas situaciones?

Bueno pues estas y otras cuestiones trataremos de ir resolviéndolas poco a poco en nuevas entradas.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Edorta

Un breve repaso a definiciones de malware

Como hemos dicho en otras entradas, la proliferación de equipamiento industrial en redes basadas en tecnología Ethernet ha ido en aumento al igual que el grado de exposición frente a actividades maliciosas. Tal es el caso del malware algo que, si bien ya estábamos acostumbrados en entornos IT, su presencia en entornos industriales no sólo está haciéndose mayor sino que su desarrollo está siendo dirigido hacia este tipo de dispositivos. Además, cobra especial importancia cuando los equipos con Sistemas Operativos Windows no sólo no están parcheados sino que además no cuentan con herramientas protección. Aquí podemos entrar en un debate donde encontraremos detractores y defensores sobre la seguridad que ofrecen este tipo de productos, los anitvirus. En cualquier caso convendría realizarse algunas preguntas y que para nada son todas las que podrían ser.

  1. ¿Ofrecen los antivirus del mercado firmas para malware dirigido a Sistemas de Control Industrial?

IRONGATE

  1. Considerando el ciclo de vida mayor de los equipos en comparación con entornos IT, ¿Ofrecen soporte a Sistemas Operativos como Windows 2000 y XP presentes aún en entornos OT?
  1. Todo equipo tiene una parte software y otra hardware. Teniendo en cuenta que estos Sistemas Operativos poseen recursos como CPU, memoria, etc. mucho menor de lo actual. ¿qué impacto tiene la carga computacional cuando se lleva a cabo un análisis de equipo?
  1. Según lo anterior, ¿podrían verse afectadas en un momento dado las aplicaciones que interactúan con los equipos de campo y que cuyo funcionamiento debe garantizarse?
  1. A diferencia de entornos de oficinas donde, como norma general, diariamente existe una ventana de tiempo para poder llevar cabo ciertas acciones, ¿qué ocurre en los casos de 24 X 7 X 365?

Crashoverride portada

Cuestiones aparte, lo que si es cierto es que muchas veces los técnicos, ingenieros de procesos o de mantenimiento, que interactúan en última instancia con el equipamiento potencialmente infectable, no sólo no son conscientes de los riesgos sino además de las diferencias que existen entre los tipos demalware. Por tanto, si una entidad emite una información sobre tal o cual campaña o bien se emite un boletín con las características del “bicho” es más que probable que estas personas entiendan poco, o nada, de todo cuanto ahí se documenta. ¿Porqué? Porque hasta ahora no había esa necesidad. Estos profesionales deben de saber de automatismos, sensores, actuadores, relés, motores, neumática, hidráulica, robots, etc. etc. La ciberseguridad no era una prioridad, hasta ahora. Por tanto, al hablar de Troyanos, Rootkits, Gusanos, o cualquier otro, estamos hablando de algo que pueden no saber interpretar, ni en su particularidad ni en su contexto pero que afecta a los equipos que sí son de su responsabilidad.

Así pues, veía necesario hacer un pequeño resumen de los principales tipos para hacernos una idea de una manera sencilla y sin entrar en muchos detalles, de lo que dicha documentación trata de contarnos. Vamos pues.

Droppers

Es software que permite la instalación de malware sobre un objetivo determinado. Esta acción puede hacerse bien en una sola fase, por ejemplo, el malware viene embebido dentro de un fichero; o bien en dos fases. Esto es, el “dropper” descarga una pieza de software desde un servidor y a continuación se produce la infección.

Rootkits

Estas “herramientas” tratarán de encubrir procesos o servicios que están llevando algún tipo de actividad maliciosa, como puede ser permitir acceso remoto a un atacante. Esto se puede conseguir ofreciendo información falsa sobre las tareas que se están ejecutando y pretender hacer ver que todo está correcto cuando en realidad el equipo está comprometido.

Adware y Spyware

El “Adware” se trata de software publicitario que genelaralmente se presenta en los navegadores web como añadidos con una funcionalidad concreta siendo muy comunes en aplicaciones gratuitas. En algunas ocasiones pueden contener algún tipo de software tipo “Spyware” con el fin de recolectar cierto tipo de información del usuario o del equipo sobre el cual se instala.

Gusanos

La función principal de los gusanos es la de replicarse a sí mismo y conseguir extenderse. Las dos vías más comunes es hacerlo por la red o bien por otro medio como las memorias USB. Pueden operar de forma independiente, aunque a menudo son usados conjuntamente con algún otro módulo. Por ejemplo, el gusano se propaga y dicho módulo infecta al equipo vulnerable. Un ejemplo lo tenemos con el malware Wannacry que tanto oímos hablar no hace mucho tiempo.

Troyanos

Se trata de malware cuyo principal propósito es dar acceso remoto a un sistema para actuar en él en un momento dado. Aparte de abrir una puerta trasera, podrán  incorporar otras funcionalidades como captura de pulsaciones de teclas para posteriormente enviarlos a un host remoto, o incluso un rootkit para pasar desapercibido.

Ransomware

¿Qué se puede decir de este tipo de malware con todo lo que ha acontecido con “Wannacry”?  En cualquiera de los casos debemos de decir que el objetivo de este tipo de malware es impedir el acceso a ficheros y solicitar un rescate para permitir su acceso de nuevo. La principal vía es el cifrado de los mismos, y posterior aviso de que la operación se ha llevado a cabo. Una vez efectuado el pago, el atacante envía la clave para proceder a su descifrado y así recuperar la información.

wannacry_05-1024x774

Hasta qui he querido dar una definición muy muy breve de los principales tipos de malware y que a menudo podremos encontrar en aquellos informes que puedan aparecer relativos a incidentes en entornos industriales. La entrada de hoy puede parecer muy “light” para aquellos que provengan del mundo IT, pero en este caso ha he pretendido dirigirla a personas relacionadas más con las Tecnologías de Operación que, generalmente, no están relacionadas con este tipo de términos.

Dicho lo cual, hasta aquí la entrada de hoy que, aunque descafeinada para algunos, espero sea el punto de partida para otros, que seguro deberán familiarizarse cada vez más con estos u otros tecnicismos.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Edorta.

 

Evaluando riesgos en entornos industriales.

A menudo oigo en los distintos congresos y personas con las que hablo la manera en la que se abordan las distintas estrategias, aproximaciones y formas con las que securizar instalaciones industriales. Se habla de separar entornos, filtrar tráfico, bastionar, estrategia de Defensa en Profundidad y otros tantos conceptos, pasando por alto el primero de todos ellos. El punto de partida, la base sobre la cual vendrán todas aquellas soluciones técnicas, de infraestructura y operacionales. Esto es: el Análisis de Riesgos o Risk Assesment en la lengua de Shakespeare.

Todos sabemos que la seguridad al 100% no existe y lo que se ha de perseguir es la reducción del riesgo de sufrir un incidente que ponga en peligro la disponibilidad de nuestras instalaciones. Y también, como no, las respectivas consecuencias que puede llegar a tener.

Así pues, podríamos hablar de:

Riesgos inaceptables, aquellos que superan un determinado límite o puedan provocar un efecto significativamente negativo en la empresa.

Riesgos aceptables, son aquellos que pueden ser asumidos o que no requieran de una inversión  de tiempo o medios adicionales para seguir reduciéndolo.

Riesgos latentes, aquellos que no son susceptibles de reducir ya que no existe una forma para alcanzarlo.

Con ellos definidos, podremos plantear alguna de las siguientes estrategias para hacerles frente y avanzar en el desarrollo de la evaluación.

Reconocimiento y aceptación del riesgo, se identifica y se asume el riesgo que por una causa u otra no debamos, o podamos, seguir reduciéndolo.

Reducción de riesgos, se emplean medidas específicas para limitar la probabilidad de que se produzcan incidentes y/o las consecuencias puedan resultar admisibles.

Transferencia del riesgo, el riesgo se “traslada” a otra entidad como puede ser el caso de seguros.

Prevención de riesgos, se trata de mitigar las consecuencias de un suceso antes de que se produzcan tratando de impedir o interrumpir su ejecución. También, por haber encontrado una alternativa.

Evaluación del riesgo v1

Así pues, especialmente en la reducción y mitigación, debemos contar con un conjunto de contramedidas que nos ayuden a materializar todo lo que ahora hemos ido dando forma en el papel. A groso modo, las podemos encuadrar en:

Infraestructura, aquellas en las que se basa especialmente en la arquitectura de red como la separación de los entornos IT y OT y la segmentación de este último.

Técnicas, aquellas abordan el resto de acciones sobre distintos aspectos como pueden ser el Control de Accesos, Antivirus, Cifrado, bastionado, etc.

Operativas, todas las anteriores requieren de personas y métodos de trabajo que  las mantengan y regulen. Resulta necesario establecer Roles y Procesos para asignar responsabilidades y procedimientos sobre los cuales trabajar.

Como norma general los riesgos van cambiando con el paso del tiempo. Lo que hoy presenta unos niveles aceptables, mañana con la aparición de nuevas vulnerabilidades deja de serlo. Por tanto, se requiere que estos procesos deban ser revisados con el fin de actualizarlos y adaptarlos a las nuevas circunstancias.

risk-icon-copy2

Una de las principales dificultades a las que nos encontraremos será cuantificar un riesgo, tanto a nivel individual sino también encuadrado dentro de la actividad de la empresa. Debemos hablar desde un punto de vistico holístico de la seguridad y no como algo de activos concretos o aislados. Esto incluye también a un concepto de seguridad que muchas veces pasa por alto. Hasta ahora nos referimos a seguridad de la información, esto es “Security”. Sin embargo, existe otro clave como es el de la seguridad de personas, esto es, “Safety. Este último también debe ser tenido en cuenta aún más si cabe que el primero.

Este enfoque nos proporcionará no sólo una visión más completa sino dimensionar otro de los conceptos clave, la “probabilidad”. La probabilidad de sufrir en mayor o menor medida un incidente y por tanto dirigir, priorizar y ajustar nuestros recursos con el fin de establecer no sólo el orden sobre el cual actuar sino dónde invertir más dinero.

Teniendo en cuenta toda la información a recolectar y analizar, la evaluación de riesgos puede convertirse en una tarea abrumadora ya que son muchos los factores y variables que pueden participar. A esto hay que sumar las diferencias propias de los dos entornos IT y OT, que de un tiempo a esta parte vienen conviviendo más estrechamente. Para ello es necesario “tratar” de hablar el mismo idioma, cosa que resulta complicado ya que los campos de actuación son muy distintos y las disciplinas, aún más. Por ello vamos a resumir los más relevantes:

Amenazas.

Es el elemento que inicia el evento en cuestión el cual puede producir un daño material o inmaterial sobre los componentes de un sistema o conjunto de ellos. Podemos catalogarlas como Intencionadas o no intencionadas según sea el caso. Os dejo dos enlaces donde hace tiempo hablaba de ello:

Objetivo.

Es el elemento que sobre el que recae la amenaza. Erróneamente podemos pensar en activos o componentes electrónicos, nada más lejos de la realidad. Los administradores, ingenieros de proceso también lo son ya que cuentan con una información privilegiada de la organización, de sus procesos, de su actividad, de todo lo que ello conlleva y que mediante Ingeniería Social pueden revelar mucho conocimiento que de otra manera sería más difícil alcanzar.

Vulnerabilidad. 

Es la debilidad que permite a una amenaza alcanzar al objetivo. Aquí os dejo otro enlace de otro post:

Vulnerabilidades en Sistemas de Control Industrial.

Vector de ataque 

Es el medio a través del cual se lleva a acción. Puede ser de los más variado dependiendo de qué lo origine. Nuevamente me remito a uno de mis artículos.

Vectores de ataque sobre Sistemas de Control Industrial.

Incidente

El evento en sí mismo, la consecución de todos los objetivos anteriores. Dependiendo de los elaborado y estudiado que sea, la capacidad de éxito será mayor.

Probabilidad.

Qué tanto por cien de posibilidades hay de que un ataque consiga su propósito. Cuanto más reduzcamos el riesgo, menor será.

Aquí conviene hacer una diferencia entre dos conceptos que a menudo pueden resultar con fusos como son “Consecuencia” e “Impacto”.

Consecuencia.

Es el resultado directo del ataque.

Impacto.

Es el grado en el que el ataque afecta a la actividad de la empresa, tanto en daños humanos, materiales, económicos o incluso ecológicos. A partir de ahí, la recuperación será más o menos compleja según sea éste mayor o menor.

Así pues y poniendo todo en su conjunto podríamos resumir que:

La probabilidad de que una amenaza pueda llevar a cabo un ataque mediante un vector  determinado debido a una potencial vulnerabilidad sobre un activo, tendrá una consecuencia con un impacto sobre la organización. En resumen, cuanto mejor será nuestra evaluación y medición de los riesgos; más eficiente y mejor dimensionadas serán las estrategias para mitigarlos.

Así pues, podríamos resumir dicho proceso en la siguiente imagen:

Proceso de evaluación de riesgos v2

Si bien los pasos indicados se dividen en otras subtareas, es a grandes rasgos,  estos son los aspcetos clave que nos podemos encontrar antes de poner en marcha cualquier proyecto para securizar nuestras instalaciones e infraestructuras. Como hemos dicho, no es un proceso fácil, y bastante tedioso la verdad, pero totalmente necesario no sólo para buscar las medidas más efectivas, sino también dimensionar la inversión económica tanto inicial como de mantenimiento. Todo tiene un costo, al inicio con el despliegue como en manutención en los años venideros.

Hasta aquí la entrada de hoy, menos técnica pero no por ello menos relevante.

Un saludo.

Edorta

MRP, Media Redundancy Protocol

Como avanzaba en la entrada “Redundancia en entornos ICS/SCADA” hoy comenzaremos a hablar de aquellos mecanismos que dotan a nuestras redes industriales de una resiliencia mayor. La tendencia de los protocolos empleados en este tipo de entornos es evolucionar hacia tecnología Ethernet en lugar de la tradicional serie. Sin embargo, su propia naturaleza, no permite la creación de bucles en la red ya que el tráfico “Broadcast” podría no sólo ralentizar las comunicaciones, sino bloquearlas. Ante la necesidad de entornos que requieren alta disponibilidad, hemos configurar protocolos que “rompan” esos bucles dejando un solo camino posible para la comunicación entre equipos. En caso de producirse un fallo, dicho protocolo será capaz de detectarlo y desencadenar las medidas necesarias para que todo el tráfico comience a ir por una vía alternativa. En entornos IT, el más conocido es Spanning Tree Protocol (STP) así como sus respectivas versiones RSTP, MSTP o PVSTP. Sin embargo, los tiempos que maneja para poder restaurar las comunicaciones son muy altos para los requerimientos de los sistemas de control y automatización, siendo necesario emplear otros que iremos viendo en esta y entradas sucesivas.

El primero de ellos es MRP (Media Redundancy Protocol). Este protocolo está descrito en el estándar IEC 62439-2, el cual es ampliamente utilizado en redes industriales para entornos de alta disponibilidad. MRP opera en Capa 2 y es específico para redes en anillo con hasta 50 equipos, garantizando un comportamiento determinístico en caso necesidad de cambio de un estado a otro. Para ello, define una serie de tiempos máximos para recuperar las comunicaciones según sea la configuración elegida. Éstos pueden ser 500 ms, 200 ms, 30 ms y 10 ms. Como hemos dicho estos son valores máximos, por lo que los tiempos reales oscilan entre la mitad y un cuarto de los mismos. Esto es, si configuramos nuestros equipos con un valor de 200 ms, el tiempo aproximado del cambio entre una ruta a otra de los paquetes podrá rondar entre 50 y 60 ms, aproximadamente.

Como vemos en la imagen anterior, MRP necesita que cada nodo disponga de dos enlaces en el anillo. Dentro de la topología, uno de ellos será elegido MRM (Media Redundancy Manager), el cual   monitoriza y controla,  reaccionando en caso de fallo. Esto lo consigue enviando tramas de control desde cada uno de los puertos, recibiéndolas en el otro extremo.  A pesar de que uno de ellos permanezca “Bloqueado”.

El resto de elementos del anillo reciben el nombre de MRC (Media Redundancy Client). Cada MRC retransmite las tramas de control enviadas por el MRM de un puerto a otro de tal manera que éste pueda detectar el fallo y activar el puerto en “Bloqueado”.

MRP define 3 tipos de tramas de control:

  1. Para monitorizar el estado de anillo. MRM envía regularmente tramas de prueba en ambos puertos que le conectan al anillo.
  2. Cuando el MRM detecta un fallo o recuperación de los enlaces, envía tramas de cambio de topología (“TopoChange”) en ambos puertos de lanillo.
  3. Cuando un MRC detecta un fallo o recuperación en un puerto, local envía tramas de cambio de enlace (“LinkChange”) al MRM. Éstas se consideran como un subtipo de otras denominadas “Linkdown y “Linkup”.

En un funcionamiento normal, “Anillo Cerrado”, el MRM bloqueará todo el tráfico a excepción de estas tramas, por lo que a efectos prácticos el anillo se comporta como si fuera un único enlace. Esto es, no existe ningún bucle.

Anillo Cerrado MRP

                        Anillo Cerrado MRP

Cuando el MRM deja de recibir dichas tramas en el otro extremo, interpreta que el enlace se ha roto en algún punto,  “Anillo Abierto”, por lo que ese puerto que estaba en “Bloqueado”, ahora comienza a enviar tramas de forma normal.

Topología en anillo abierto MRP

                      Anillo Abierto MRP

A esto hay que sumar que los MRC son capaces de informar de cambios de estado en alguno de los enlaces. Si esto se produjese, el MRC envía una trama de control al MRM informando de ello. Si éste la recibe antes de detectar que se ha producido un cambio en el anillo, toma la información contenida en ella para activar el enlace “Bloqueado” y así recuperar la conectividad en el menor tiempo posible. De ahí que, aunque se fijen tiempos máximos, siempre cabe la posibilidad de que el anillo pueda seguir enviando tráfico por debajo de estos umbrales.

Tanto el MRM como el MRC definen una serie de “estados” para sus puertos dentro de la topología.

  1. Disabled, los puertos descartan todas las tramas recibidas.
  1. Blocked, los puertos descartan todas las tramas excepto las tramas de control MRP y algunas otras de protocolos como LLDP.
  1. Forwarding, los puertos reenvían todas las tramas recibidas.
  1. Not Connected, el enlace está físicamente caído o desconectado.

En otro orden, en el caso concreto de PROFINET, MRP puede ser implementado sobre los dispositivos finales sin necesidad de equipos adicionales gracias a la definición de una aplicación concreta como es PROFINET/MRP.

Por último conviene citar las funcionalidades que cada fabricante otorga a sus productos dependiendo de modelos y licenciamiento. Algunos de ellos pueden ser; posibilidad de integración con software de gestión como Siemens Total Integrated Automation (TIA); definición de varios anillos MRP por una misma VLAN; interperabilidad con Spanning Tree Protocol; etc.

No debemos olvidar tampoco de las limitaciones y recomendaciones que cada uno hace a la hora de configurar los equipos. Por ejemplo, Cisco nos habla de que los puertos MRP no pueden ser configurados como puertos SPAN, Private VLAN o Tunnel y, si además la implementación es sobre Profinet, como Trunk; ser configurado en puertos Etherchannel; etc.

Lo dicho, hablar de resiliencia no es sólo hablar de la securización, es tener además la capacidad de recuperarse del elemento que provoca una determinada perturbación. Hoy en día con la cantidad de amenazas que acechan a los Sistemas de Control  Industrial resulta necesario no sólo desplegar medidas técnicas sino además definir arquitecturas que hagan frente a cambios o anomalías inesperadas. Los accidentes ocurren, una fibra óptica rota; un SFP, defectuoso; una configuración accidental de un puerto, o cualquier otra razón,  bien puede desencadenar una alteración en las comunicaciones y por tanto un impacto en el proceso. Esto no quita que debamos hablar de otros riesgos como el “Sabotaje”, “Inyección de tráfico”, “Intrusión”, y que obligen implementar otras medidas como el “Hardening de Sistemas”, “Monitorización”, “Control de Accesos”, entre otras paliando así estas amenazas.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Hasta pronto!

Redundancia en entornos ICS/SCADA

Como hemos hablado en anteriores ocasiones, y no nos cansaremos de repetirlo, la prioridad número uno en entornos industriales es garantizar la disponibilidad. Luego vendrá la integridad y la confidencialidad, pero lo primero es la disponibilidad. Para alcanzarlo, se ha de aplicar una estrategia de Defensa en Profundidad para reducir los riesgos de sufrir un incidente de seguridad y prevenir que algo, o alguien, atente total o parcialmente contra nuestras instalaciones. Dada la limitación y naturaleza de los equipos, así como las debilidades que ofrecen en lo que a materia de seguridad se refiere, muchos de ellos deben delegar en la infraestructura de red la seguridad que por sí mismos no pueden ofrecer. Para ello, ha de comenzarse por la separación de los entornos IT y OT; y más tarde en la segmentación de este último definiendo zonas más pequeñas con el fin de que si una se ve afectada, la amenaza no se propage al resto.

Sin embargo, esto no es lo único que debemos considerar. Si queremos que nuestra red sea resiliente, no sólo debe evitar,  y ser capaz,  de mitigar un ataque sino que debe ser tolerante a fallos, ya sean éstos intencionados o no.

Los enlaces redundantes suponen una medida para evitar puntos únicos de fallo que puedan dejar fuera de servicio toda una instalación. Duplicando las vías de comunicación conseguimos que, en caso de producirse uno, los sistemas comunicarán por caminos alternativos. Así podemos establecer dos posibles propósitos:

  1. Tolerancia a fallos

Aumento de las vías de comunicación que permitan reconducir el tráfico por alguna de las restantes.

  1. Balanceo de carga

Disponiendo de dos o más enlaces entre equipos podemos no sólo lograr el punto anterior sino también un envío alternativo de paquetes por canales distintos de tal manera que consigamos descongestionarlos en caso de saturación de alguno de ellos.

Aunque el punto uno en realidad también está incluido dentro del segundo, el uso de enlaces redundantes en entornos industriales esta usualmente dirigido a éste ya que es más importante garantizar la disponibilidad que el rendimiento. Esto último además se refuerza con que las necesidades de anchos de banda en entornos OT son más pequeñas que en IT.

La tendencia de las comunicaciones industriales es que se basen en tecnologías Ethernet y servicios TCP/IP dejando atrás, o reduciendo el uso,  protocolos basados en buses tipo RS-485 o serie. Sin embargo, el tráfico broadcast propio de la tecnología Ethernet no permite el uso de enlaces redundantes por lo que hemos de implementar protocolos que resuelvan este problema. El más extendido es Spanning Tree Protocol o algunas de sus versiones como RSTP, MSTP o PVSTP, el cual permite disponer de varias rutas físicas, pero bloqueando los puertos de los elementos de la red de tal manera que sólo exista una activa. El resto, permanece en “Standby” hasta que, como digo,  se produzca una caída de alguno de los enlaces que permanecen activos obligando a recalcular una segunda ruta que reestablezca las comunicaciones,  activando alguno de esos enlaces que permanecían en “Standby”. Hasta que esto ocurre transcurre un tiempo que puede ir de uno a varias decenas de segundos según sea el protocolo elegido.

Topología en anillo_01

Esto en entornos IT puede no suponer un problema, donde el retraso en décimas de segundo puede pasar inadvertido mientras se manda un correo o se accede a un fichero en una unidad de red. Aparte, claro está, que existan tecnologías más modernas que permitan la supresión de bucles en Capa 2 y por ende, estos protocolos. Pero insisto, aunque estén implementados, los tiempos pueden ser más amplios, algo que resulta inaceptable para entornos OT. Para hacernos una idea, en comunicaciones tipo RT (Real Time) o IRT (Isochronous Real Time) hablamos de latencias por debajo de 10 ms y 1 ms, respectivamente. Es por ello que las medidas de entornos IT no son aplicables, una vez más, a entornos de automatización, por lo que se han de aplicar otras. En resumen, el método para conmutar de un enlace a otro debe ser predecible para determinar el límite tolerable de latencia, y por tanto, conocer de antemano cómo puede afectar a las comunicaciones según sea su naturaleza. El objetivo debe ser que la convergencia sea tan rápida que resulte transparente para las aplicaciones en uso sin sobrepasar los límites tolerables.

Es por esto que en entornos OT no hablamos de Spanning Tree, ni como decía, ninguna de sus variantes. No tienen cabida. Han de emplearse otros. En las próximas entradas veremos estos protocolos y cómo, una vez más, disponer de una arquitectura de red nos proporcionará,  junto con las medidas de seguridad paralelas,  una resiliencia mayor para hacer frente al creciente número de amenazas y riesgos a los que se enfrentan nuestras infraestructuras.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Un saludo!