IX Congreso Internacional de Ciberseguridad Industrial. Fortinet & Nozomi Networks.

Los pasados 4 y 5 de octubre se celebró en Madrid el IX Congreso Internacional de Ciberseguridad Industrial organizado por el Centro de Ciberseguridad Industrial. En él, un año más, se dieron cita profesionales, expertos e instituciones con el fin de compartir dos jornadas cargadas de puntos de vista, investigaciones, nuevas líneas de productos, casos de éxito, mesas redondas y momentos para el networking empresarial donde intercambiar y hacer nuevos contactos.

A diferencia de las dos ediciones anteriores, este año acudía no sólo como espectador sino, además, como ponente. Allá por el mes de mayo tuve la oportunidad de participar en “La voz de la Industria”, pero esta vez tocaba hacerlo con proyección internacional.

Dicha ponencia se hizo en conjunto con miembros del equipo de profesionales de  GrupoCMC,  Fortinet y Nozomi Networks siendo cada uno de ellos Jose Luis Laguna, Director Técnico de Fortinet Iberia; Antonio Navarrete, Ingeniero Pre-venta; y Edgar Capdevielle, como CEO de ésta última y un servidor como GrupoCMC.

CCI_01

El tema de nuestra presentación era “Demostración práctica de protección de un escenario de automatización industrial” donde simulamos el funcionamiento de una presa hidroeléctrica empleando para securizarla con equipos específicos como Fortinet Fortigate Rugged 90D y solución SCADAGuardian. Ahora bien, ¿cuál fue nuestro discurso para ver la necesidad de ambos? Comencemos.

Bajo mi punto de vista y basándome en lecciones aprendidas (prácticas, no teóricas) en proyectos planteamos que la actualización de equipamiento porque sea más seguros no es una prioridad. Las empresas no los cambian porque incorporen tal o cual medida de seguridad, lo hacen porque la función que realicen lo requiera. Además, puede no es fácil llevarlas a cabo ya que la implementación de unas u otras tecnologías puede necesitar ventanas de tiempo amplias. Por ejemplo, pensemos una migración de una arquitectura RS-485 a una Ethernet. En otro orden, por muy planificados que estén los trabajos, cualquier intervención no deja de introducir un riesgo que desemboque en un impacto en la actividad siendo éste inasumible.

Es por ello que la Seguridad Perimetral sigue siendo la primera medida. ¿Por qué? Porque permite reducir los riesgos en una primera instancia sin la necesidad de actuar sobre esos equipos finales desactualizados, sin soporte en algunos casos, sin compatibilidad con soluciones de seguridad, con largos ciclos de vida, que por su criticidad sea inviable actuar sobre ellos para aplicar parches, con desarrollo de aplicaciones propias, y un largo etcétera. Además, permite atajar la propagación de amenazas o incidentes a través de filtrado de tráfico junto con funciones avanzadas como Control de Aplicación, Antivirus, Filtrado Web o IDS/IPS. Sí filtrado web. Hay equipos que permiten ciertas funcionalidades a través de servidores web embebidos a los que les pueden afectar las mismas vulnerabilidades con la dificulta que, o no pueden ser corregidas, o supone la actualización completa de firmware o software.

Por supuesto, esto último respaldado con un buen diseño y arquitectura de red ya que de nada nos sirve incorporar un equipo último modelo, si luego tenemos una red plana o enrutada…

Aparte de lo anterior, otra de las necesidades que veíamos era la inclusión de medidas en materia de visualización y monitorización. No me refiero a solucione SCADA, sino a nivel de red. De tráfico.

La Industria 4.0 trae consigo una buena cantidad de beneficios no sólo por los avances tecnológicos como fabricación aditiva, robótica colaborativa, simulación, etc. sino la inclusión de las Tecnologías de Información para mejorar los procesos convirtiendo las fábricas en más productivas, competitivas, eficientes energéticamente, etc. Esto requiere tener una visión de lo que ocurre en nuestras instalaciones, consiguiéndose mediante la recolección de información tanto en tiempo real como en cortos espacios de tiempo y a partir de ahí corregir desviaciones o tomar otro tipo de medidas. Ahora bien, para alcanzar ese propósito los equipos deben de estar interconectados y en el momento que esto se produce, todos comienzan a estar expuestos. Y como bien sabemos, una medida para reducir los riesgos es reducir justamente el grado de exposición.

Junto con ello los flujos de tráficos deben ser un reflejo del proceso. Nada que no forme parte de la actividad propia, debe existir. Sólo lo estrictamente necesario.

La contextualización de la información también debe estar presente. Tenemos que tener una visión amplia de lo que sucede. Si hablamos de una fábrica de producción en serie, el fallo en un equipo instalado en una línea a priori no debería afectar a otra. Pero si ese problema no se resuelve dentro de los tiempos máximos podría dejar de suministrar piezas o material a esta última provocando unas consecuencias mayores.

Finalmente, conviene diferenciar entre información e inteligencia sobre amenazas. Debemos pararnos a pensar que no toda la información que obtenemos con esta monitorización puede ser del todo útil. Por ello cara a recolectar datos debemos analizar la calidad de la información; su origen; cantidad; relevancia para la organización, sistemas y entorno; capacidad para recolectar, correlar o analizar; y finalmente, cómo la aplico. Es decir, si no hago nada con ella, ¿para qué conseguirla?

Si sumamos ambos aspectos, por un lado, la seguridad perimetral y por otro la necesidad de monitorización, es que encontramos el beneficio de contar ambos productos destacando entre otros aspectos:

Fortinet Fortigate:

  • Gama productos específicos para entornos industriales.
  • Diseño rugerizado capaz de soportar entornos hostiles con polvo, humedad y temperatura muy superiores a entorno IT tradicional.
  • Electrónica de alto rendimiento.
  • Integración con soluciones de gestión centralizada.
  • Deep Packet Inspection sobre protocolos industriales.
  • Montaje sobre carril DIN y alimentación por fuentes de alimentación externas.

Nozomi SCADAguardian:

  • Solución diseñada para entornos industriales.
  • Identificación de activos y protocolos
  • Detección de anomalías en flujos y tipos de tráficos.
  • Instalación pasiva no introduciendo latencias adicionales.
  • Evaluación de vulnerabilidades a partir de información recolectada.
  • Detección de amenazas, riesgos e incidentes.
  • Variedad de paneles de control y generación de informes para análisis y labores forenses.

Sin embargo, el mayor de los beneficios está por anunciar. Y es que a pesar de los beneficios de ambos por separado, tanto Fortinet  como Nozomi Networks han alcanzado un grado de integración tal que, en caso de SCADAguardian detecte una anomalía a partir del análisis de tráfico, puede interactuar de forma automática con los equipos Fortigate configurando una regla en los firewalls que deniegue el tráfico anómalo identificado.

Esto introduce un grado adicional de protección ya que permite atajar cualquier incidente en el mismo instante que se produce reduciendo así el tiempo transcurrido desde que una amenaza es detectada, interpretada, valorado el alcance, puesta en marcha su mitigación, resolución y extraídas las conclusiones. Sin embargo, esto no es fácil ya que lleva aparejado una importante labor desde el punto de vista que debemos conocer qué activos y protocolos tenemos en nuestra organización para saber cuáles son legítimos o cuales no; definir tendencias y patrones; sopesar de qué forma SCADAguardian va interactuar con los Firewalls, esto es, bloquear IPs, cerrar sesiones, y un largo etcétera.

Como decía anteriormente para demostrar este valor añadido, ideamos una réplica de lo que podría ser una presa hidroeléctrica. En la imagen siguiente se ve el esquema de la simulación en la que aparece un taque donde se acumula el agua. Luego, se abre una electroválvula que, al abrirse, deja pasar el agua haciendo mover una turbina que es la que genera electricidad para  ser almacenada en el tanque inferior. Finalmente, se acciona una bomba que impulsa de nuevo el agua al tanque superior, para volver a repetir el proceso.

Escenario lógico

La lógica está gestionada por un equipo TRIDIUM JACE el cual cuenta con una interfaz web para labores de administración. Tanto la electroválvula como la bomba están conectadas al equipo TRIDIUM SEDONA el cual recibe las órdenes de abrir/cerrar y paro/arranque del JACE por medio del protocolo ModbusTCP.

Escenario lógico_01

Y todo ello en la realidad quedó en….

CCI_03

Así pues, lo que se hizo en vivo y en directo fue llevar a cabo un ataque sobre el TRIDIUM Sedona enviando paquetes específicos ModbusTCP desde un PC que provocada el paro de la bomba o el cierre de la electroválvula. Esto es posible debido a la falta de medidas de seguridad nativas de dicho protocolo.

Más tarde, para ver la efectividad de ambas soluciones trabajando conjuntamente se incorporó el equipo SCADAguardian el cual recibía el tráfico desde un puerto espejo de un FortiSwitch. Luego tras la integración de Fortigate Rugged 90D en aquél, se repitió nuevamente el ataque no teniendo éxito ya que al considerarse que provenía de un equipo no legítimo, SCADAguardian lo consideraba como “malicioso” enviando la orden al Firewall de la generación de una regla que lo cortase. Impedía así que llegase el paquete al TRIDIUM Sedona y por tanto evitando el cierre o paro de los dispositivos.

Obviamente este fue una prueba de concepto, sin embargo en un entorno real esta tarea llevaría más tiempo. Sería necesario dejar aprender durante unos días o semanas el comportamiento de la red para poder establecer qué tráficos son buenos y cuáles no. También la manera en la que queremos que se comporte el Cortafuegos, esto es, cortar sesiones, bloquear IP, etc. etc.

A continuación os dejo un video elaborado por Fortinet donde se explica todo ello. ¡Excelente!

Quedamos muy satisfechos con la exposición ya que aparte de lo original, práctico y puesta en escena todo salió muy bien. No quería pasar por alto agradecer a mis compañeros de GrupoCMC que diseñaron la interfaz gráfica y metieron horas para que todo saliese en esta línea. Sin ellos, su conocimiento, experiencia y sobre todo su actitud; esto no hubiera sido posible. Como no, a Jose Luis, Antonio y Edgar por los esfuerzos, trabajo e iniciativa; a Jose Valiente, Miguel García-Menéndez y Susana Asensio por la organización de este congreso de referencia; y finalmente a los asistentes que esperamos fuese de su agrado esta exposición en la que se invirtió tanto tiempo como ganas de haber proporcionado una forma automática, rápida y eficiente de proteger nuestros entornos de control y automatización industrial sea cual sea su naturaleza o criticidad.

CCI_02

Un abrazo!!

ICSSPLOIT, PROFINET-DCP

No hace mucho hablábamos de ICSSPLOIT como herramienta en labores de auditoría y pentesting en entornos industriales. En concreto, veíamos la posibilidad de parar y arrancar tanto la CPU como un módulo de comunicaciones CP en un autómata SIEMENS S7-300. Ver entrada.

Además del módulo de “exploits” y “creds”, disponemos de un tercero denominado “scanners” cuyo nombre ya delata su objetivo no haciendo falta decir mucho mas sobre él. Hasta la fecha disponemos de un total de 3:

profinet_dcp_scan

s7comm_scan

vxworks_6_scan

Para esta ocasión fijaremos nuestra atención en el primero de ellos. El mismo, emplea el estándar de comunicaciones PROFINET para la recolección de información de  aquellos dispositivos que lo utilicen.

Conviene recordar en lo que respecta a entornos industriales, se marcan 3 tipos de comunicaciones cuyo uso dependerá de las necesidades del entorno y precisión de procesos. Estos son:

  1. Standard TCP/IP, empleado para tareas en las que latencias  de hasta 100 ms pueden ser aceptables como ocurre en entornos IT.
  1. RT (Real Time), son aquellas en las que los tiempos de latencia pueden oscilar hasta 10 ms o son de carácter determinista.
  1. IRT (Isochronous Real Time), comunicaciones en los que los tiempos son inferiores a 1 ms.

Para entender mejor dicho estándar, a continuación citaremos algunos de los aspectos más relevantes del mismo.

Para lograr la identificación de los dispositivos, al estar basado en Ethernet, el direccionamiento viene dado por la dirección MAC, IP y nombre del dispositivo.

También encontraremos varios tipos de protocolos y funciones según sea el uso y contexto. Podremos hablar de:

PROFINET-IO, destinado a comunicaciones entre dispositivos de campo, entradas y salidas.

PROFINETMRP, para su uso en entornos de alta disponibilidad en topologías en anillo. A continuación se muestra una captura de un switch Siemens X208 en el que se reflejan dichos parámetros.

Config HA Switch_01

PROFINET-RT, transferencia de datos en tiempo real.

PROFINET-IRT, transferencia de datos en tiempo real isócrono.

PROFINET-PTCP, sincronización de señales temporales como reloj y tiempo entre dispositivos.

TRama Profinet-PTCP_01

PROFISAFE, aplicación de PROFINET en funcionalidades relativas a la protección de personas bajo el término “Safety”.

Y aqui es donde llegamos al punto que nos interesa para la entrada de hoy…

PROFINET-DCP, esto es PROFINET Discovery and Configuration Protocol o PN-DCP. Se trata de un protocolo basado en la Capa de Enlace, L2, empleado para descubrir dispositivos, identificar información relativa a éstos y configurar parámetros como nombres y direcciones IP.

Dentro de su funcionalidad, ofrece varios servicios y métodos de comunicación según sea la aplicación como “Identify All (multicast service/ Group)”,  “Identify (multicast service)”, “Set (unicast service)”, “Set / Reset to Factory (unicast service)”, “Set / Flash (unicast service)”, “Get (unicast service)” y “Hello (multicast service)”.

¿Ahora bien, cómo encaja ICSSPLOIT en todo esto? Como decía al principio, el framework en cuestión trae consigo una herramienta dentro del módulo “Scanners” que nos permitirá obtener el nombre, valores de direccionamiento IP y modelo del equipo por medio de PROFINET-DCP. Eso sí, dentro de la misma subred. En el vídeo que se muestra a continuación vemos el resultado.

En la captura siguiente se puede apreciar cómo desde una máquina virtual se solicita información de un equipo “Siemens” cuya dirección MAC aparece sombreada.

PROFINET-DCP_03

Una vez procesada, dicha estación PROFINET responde con los valores que aparecen en el video, esto es, dispositivo (S7-300); nombre, (pn-io) y direccionaminto IP (192.168.0.1; 255.255.255.0; 192.168.0.1)

PROFINET-DCP_04

Con la entrada de hoy hemos visto la manera de recolectar información empleando ICSSPLOIT a través de PROFINET-DCP. Otra forma, esta vez, fuera de los protocolos habituales.

Muchas gracias, nos vemos en la próxima.

Un saludo.

Edorta

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

Controlando nuestros Proveedores, Parte II.

Hola de nuevo. Siguiendo con la entrada anterior “Controlando nuestros Proveedores, Parte I” en el día de hoy vamos a ver la manera en cómo trabaja el binomio FortiGate + FortiClient.

Si bien la protección es en tiempo real, al hacer un análisis antivirus vemos la forma en la que detecta malware según la base de firmas del fabricante. Para ver su funcionamiento he dejado en el escritorio un fichero de EICAR.

Escritorio Proveedor_01

No obstante, para que no fuese un típico ejemplo, también tenía una carpeta con el software incluido en el repositorio Pengowin y que desde aquí, dicho sea de paso, recomiendo dicho proyecto.

Aviso de virus_01

Viendo los logs:

Logs de Virus_01

en total fueron 55 detecciones:

Registro de Virus_02

Para terminar la desinfección es posible que se solicite un reinicio del sistema.

Captura_02_Tras Finalizar AV

Como se puede ver, también en el escritorio tenía el simulador del protocolo S7 de SIEMENS, Snap7 del que hablaba en la entrada “Snap7 suite de PLCs y comunicaciones Siemens”. Al ejecutar el cliente para hacer una lectura del supuesto PLC, esto es “clientdemo.exe”, como el protocolo “ICMP” y “S7 Protocol” no están permitidos vemos su bloqueo, al igual que otros relacionados con el sistema operativo.

Aplicaciones Bloqueadas_02

Si actualizásemos el perfil del control de aplicación correspondiente, ya podríamos acceder al mismo, en la IP 192.168.0.1.

Cliente SNAP7_01

También disponemos de un “Filtro Web”, funcionalidad que no he utilizado pero también útil si necesitamos tener acceso a una interfaz Web. ¡Ojo! Hablo de equipos locales, no accesos a Internet.

Como decía en el post anterior es compatible con los “Security Profiles” configurables en cada una de las reglas del Firewall, con lo que a nivel de red también podríamos ejercer un control adicional. Configurar los perfiles de qué se puede ejecutar, o no, en un PC puede llegar a ser complejo y laborioso en función de cada proveedor. Con lo que llegado el momento, podríamos llegar a ser más permisivos en este sentido en cuanto a consentir toda la categoría “Industrial” o “Servicios de RED” y denegar “Botnet”, “Game”, “P2P”, etc. y luego apoyarnos en reglas y “Security Profiles” como indicaba en las entradas:

También destacar la visibilidad que podemos tener desde el Fortigate a la hora de monitorizar los FortiClients conectados y de si cumplen, o no, con las políticas establecidas. Para ello deberemos ir a “Monitor – FortiClient Monitor”.

Forticlient Monitor_01

Ya por último comentar que en este caso hemos hecho uso de un Firewall Fortigate para la gestión de los endpoint. Sin embargo, Fortinet dispone de un producto específico para la gestión de este software denominada FortiClientEMS (Enterprise Management Server) con lo que podremos realizar un control centralizado y una gestión más pormenorizada de todos ellos.  Aquí os dejo un video presentación y enlaces con información al respecto.

Integración de Fortigate y FortiClientEMS.

Como hemos visto nuestros proveedores pueden ser no sólo un punto de entrada sino también el origen de un problema mucho mayor. Los habrá que sean estrictos con el uso de sus equipos sin embargo, esto no es razón para pensar que nada malo pueda suceder. Los entornos industriales no son para nada similares a los de Oficina o IT tradicionales. Los ciclos de vida son mayores con lo que la posibilidad de encontrarnos con Sistemas Operativos y Hardware viejo u obsoleto, es bastante común. Con ello, falta de soporte del fabricante y vulnerabilidades incapaces de corregir, y aun existiendo parches, según actividad de la compañía, desarrollos de software propios, o cierre, hacen que muchas veces sea inviable. A esto hay que sumar la existencia de empresas proveedoras de servicios que necesitan conectarse a nuestras instalaciones para llevar a cabo las tareas para las cuales han sido contratadas, y que no hace posible desplegar su software sobre otro equipo de la organización en el que sí tenemos control y conocimiento de su estado.

Con esta entrega hemos visto cómo con los NGFW FortiGate y endpoint FortiClient podemos llevar a cabo un control y permitir qué equipos de terceros puedan conectarse a nuestra red. De esta manera reducimos los riesgos  de que algo, o alguien, pueda comprometer la disponibilidad de nuestras instalaciones. No pretende ser un manual, ni mucho menos, sino una visión sobre de qué manera podemos ejercer dicho control y supervisión.

Obviamente existen en el mercado otros fabricantes, con otras soluciones que de igual manera puedan satisfacer nuestras necesidades, pero resulta interesante ver esta en concreto por su integración junto con el hardware de red. Como hemos visto, desde hace relativamente poco tiempo, los fabricantes de equipos de control y automatización tipo SIEMENS, Phoenix Contact, entre otros, incluyen ya características relacionadas con la Ciberseguridad, cosa con los equipos más antiguos o bien, o no disponen o son débiles. Por tanto, delegar en la electrónica de red y seguridad perimetral aspectos de la seguridad sigue siendo un hecho que durará por mucho tiempo ya que la renovación de PLCs, Robots, o cualquier otro por motivos puramente de seguridad, no es una razón de peso o prioridad.

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

Edorta

 

Controlando nuestros Proveedores, Parte I.

Hace unos días hablaba acerca de la necesidad de gestionar los proveedores externos e incluirlos en nuestras políticas de seguridad, claro está, orientadas a su actividad. Muy particularmente en grandes corporaciones, éstas se ven obligadas adquirir a terceros equipos, productos y servicios especializados para la actividad de la misma. Luego, cara a garantizar una respuesta o asesoramiento, firman contratos de soporte con el fin de obtener ayuda en caso de ser necesario. Como veíamos en la entrada “Proveedores Externos, posible punto de entrada…” ha de establecerse un procedimiento tanto administrativo como técnico que regule cómo han de conectarse y qué requisitos deben reunir sus equipos antes, durante y después de conectarse a nuestra red de control.

A diferencia del post que citaba anteriormente, hoy hablaré sobre cómo podemos controlar técnicamente dichos equipos. Es un ejemplo, obviamente no dará respuesta a todas las necesidades ni a todas las casuísticas que sin duda serán muy particulares dependiendo de tecnologías, industrias, equipos, actividad, o cualquier otro factor.

El objetivo será llevar a cabo un control sobre el PC de un proveedor que necesariamente ha de conectarse, sí o sí, a nuestra red OT para llevar a cabo tareas de soporte o mantenimiento. Estos PC contendrán el software necesario sin embargo, no tendremos ni su control, ni conocimiento alguno del estado de actualización de sistema operativo, aplicaciones; firmas antivirus (si las hubiera); vulnerabilidades; etc. etc. Habrá quien piense que una alternativa pueda ser instalar las herramientas en PCs de la propia organización sobre los que sí tendríamos aquello que ahora nos falta. No le quito razón, sin embargo, la realidad nos muestra una serie de inconvenientes:

  1. Coste de licenciamiento de Software. ¿Nueva instalación, nueva licencia? ¿reasignación de licencias?
  2. Necesidad de probar aplicaciones en PCs de la organización para garantizar pleno funcionamiento.
  3. Dada el ciclo de vida mayor, probabilidad de uso en Sistemas Operativos con distintas versiones.
  4. Desarrollo de herramientas a medida y bajo condiciones concretas, diferentes a los empleados en la organización.

Por tanto, con todo en contra, lo que sí podríamos hacer es obligar a nuestros proveedores a cumplir nuestras normativas y marcarles las vías de cómo hacerlo. De hecho, es algo que las políticas de seguridad deben contemplar. Me refiero a que una vez implementadas todas las herramientas y medidas, todo nueva sistema, instalación o equipo debe cumplir con aquello especificado para el nuevo “ciberseguro” escenario. Para algo lo hemos hecho, ¿no?

Para ello emplearemos la aplicación endpoint FortiClient de Fortinet con el que podremos identificar y remediar equipos vulnerables, o comprometidos, reduciendo así la superficie de ataque. Luego podremos integrarlo en otras soluciones del mismo fabricante, aspecto que no abordaremos en este post.

Para la Prueba de Concepto he creado el siguiente ejemplo:

Como vemos en la figura, un proveedor ha de conectarse a la red Control para llevar a cabo determinadas tareas. Tiene dedicada una VLAN con un direccionamiento 192.168.254.0/24 a la que deberán conectarse todos los equipos de proveedores. Así pues, todas las comunicaciones deberán pasar por el Firewall (NGFW) que bien podría ser el de Separación o de Segmentación dependiendo de cómo tenga definida la arquitectura la organización. Luego, en función de cómo configuremos el mismo, dejaremos pasar el tráfico necesario hacia la red 192.168.0.0/24, esto es, la de Control.

Para ello emplearé la versión 5.4.4 de FortiClient y un equipo FortiGate 61E con FortiOS 5.4.5.

Lo primero que deberemos hacer será definir una subred, VLAN para nuestros proveedores y que el Gateway, por ejemplo, sea el Fortigate.

En ella deberemos habilitar por un lado la detección de Dispositivos y el control de acceso basado en Forticlient. Ni qué decir que desde la red de proveedores no puede existir la posibilidad de acceso a los Firewalls….

El siguiente paso será definir qué Aplicaciones vamos a dejar permitir ejecutar a los proveedores en sus equipos. Para ello deberemos ir a “Security Profiles – Application Control” y definir uno con los parámetros que creamos convenientes. Os dejo dos entradas que os pueden orientar en las que hablaba de esto mismo:

Con ello listo, iremos a “Security Profiles – FortiClient Profiles” y crearemos el que a posteriori será el que se aplicará sobre los endpoints.

Allí deberemos especificar algunos parámetros como: la red sobre la que se aplicará, en nuestro caso la 192.168.254.0/24, “LAB_RED PROVEEDORES”; acción en caso de no cumplimiento, “Block – Warning – Auto-update”; el tipo de dispositivo, “ALL”; Versión mínima del software FortiClient, “5.4.1”; comportamiento del motor Antivirus, “Realtime Protection, Up-to-date signatures”; y por último el perfil de Firewall de Aplicación, el que hemos definido anteriormente, “LAB_APP-CONTROL_S7”.

Aquí quizás puede llevarnos a confusión el concepto de Control de Aplicación, pero que en este caso se aplica de dos maneras distintas. Una cosa es el Control de Aplicación que se  ejecuta sobre las aplicaciones del PC y que lo regula en el endpoint FortiClient; y otro distinto el que podemos aplicar sobre el tráfico de red en cada una de las reglas configuradas y definidas dentro de la columna “Security Profiles”.

Si en estos instantes alguien quisiera acceder a algún recursos de la red no podría ya que no cumple con los requisitos. Si por ejemplo abriésemos un navegador y pretenderíamos navegar aparecería el siguiente mensaje:

La instalación del endpoint es sencilla. Lo único que tendremos que tener en cuenta es realizar una instalación completa, en lugar de sólo la funcionalidad de VPN. Una vez finalizada se comenzará a descargar los distintos componentes.

Si abrimos el cliente veremos una pantalla con los distintos apartados del endpoint.  Si nos fijamos a “Firewall de Aplicación” veremos los “Overrides” autorizados relacionados con el protocolo S7.

Hasta aquí hemos visto la manera en la que configuramos, de forma resumida, todo lo necesario para comenzar a ejercer el control del que hablábamos. Con todo listo, será en la próxima entrada, cuando comprobemos los resultados y por tanto su eficiencia.

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

Edorta

 

Snap7, suite para de PLCs y comunicaciones Siemens.

En lo que a comunicaciones se refiere, si en algo se caracterizan los Sistemas de Control Industrial es por la gran cantidad de protocolos existentes.  Según sean las operaciones a llevar a cabo estos pueden dividirse, principalmente, en dos grades grupos: “Fieldbus” y “Backend”. Dentro de “FieldBus” encontramos aquellos relacionados con tareas vinculadas a operaciones de proceso y control; mientras que en “Backend” los vinculados a funciones de supervisión, como lo son servidores y sistemas SCADA. Algunos ejemplos son:

Fieldbus:

  • Profibus
  • Devicenet
  • Canbus
  • Profinet
  • Ethernet/IP
  • CC-Link
  • SERCOS

Backend:

  • OPC
  • DNP3

En cualquiera de los casos el abanico existente es muy amplio y por si fuera poco a éstos hay que sumar los que cada fabricante desarrolla para sus propios productos. Tal es el caso de S7 de SIEMENS, objeto en día de hoy, aunque como podéis imaginar, no el único.

Fabricante Protocolo
OMRON FINS
HITACHI HI-Protocol
ROCKWELL RS-Logix
SCHNEIDER Unitelway
HONEYWELL UDC

Dicho lo cual, aunque tengamos que hacer una referencia al protocolo en sí, nos vamos a centrar en una suite llamada Snap7 con la que podremos imitar ciertas comunicaciones y comportamientos de igual modo que lo hicimos con Modbus en la entrada “Simulador de Protocolo MODBUS”.

Snap7 es un software multi plataforma para comunicarse de igual manera que lo harían de forma nativa PLCs del fabricante SIEMENS empleando tecnología Ethernet y protocolo S7.

Entre sus características principales destacan:

  • Arquitectura diseñada para 32 y 64 bits.
  • Software Open Source.
  • Soporte para varios sistemas operativos, Windows, Linux, MacOSX, etc.
  • Soporte para varios tipos de CPU.
  • No son necesarios librerías de terceros.
  • No es necesaria su instalación.
  • Modelos de transmisión de información síncrona como asíncrona.
  • Se incluyen algunas demos para su uso directo.

A día de hoy da soporte parcial a CPUs más nuevas como 1200 y 1500 y más antiguas como 200. Dentro de su estructura se definen 3 componentes principales los cuales son “Client”, “Server” y “Partner”.

Como digo, la aplicación está orientada para ser utilizada en comunicaciones Ethernet y  S7, no siendo necesario ningún adaptador especial.

La implementación del protocolo S7, base de las comunicaciones entre dispositivos SIEMENS, se soporta sobre una ampliación del protocolo TCP recogida en la RFC 1006 y titulada como “ISO Transport Service on top of TCP”. Esto es necesario ya que TCP esta orientado al envío de datos  no transmitiendo información sobre la longitud de la información contenida o sobre cuándo empiezan o terminan. Sin embargo, en aplicaciones de automatización, es indispensable operar orientado a mensajes. Esto es, enviar bloques de datos en los que el receptor sea capaz de reconocer, ahora sí, dónde terminan y finalizan cada uno de ellos. Con RFC 1006, se logra esto último ya que se incluye una cabecera que lo define, y por tanto, garantiza el proceso. Resumiendo, RFC 1006 es una aplicación dirigida a mensajes pero basada en TCP que está basado en datos.

Una vez descargada la aplicación, conviene leer el Manual de Referencia para conocer las capacidades, características, usos y otras cuestiones técnicas.

En mi caso voy a utilizar las “Demos” para Sistemas Operativos Windows los cuales encontraremos junto con el resto de versiones en:

snap7-full-1.4.2\rich-demos

snap7-full-1.4.2\rich-demos\x86_64-win64\bin

Allí encontramos tres aplicaciones:

  • clientdemo
  • serverdemo
  • PartnerDemo

Como se puede entender, hacen referencia a los dispositivos “Cliente” (Workstation, HMI o FieldPG), “Servidor” (PLC) y “Partner” (Comunicaciones entre PLCs); donde, los clientes sólo preguntan, los servidores sólo responden y los partner que pueden hablar de forma bidireccional bajo su propia iniciativa. En cualquiera de los casos, desde el punto de vista hardware, no importa cómo se lleven a cabo estas comunicaciones. Es indiferente de si se trata de un puerto de comunicaciones en la propia CPU 3XX-PN o CPU4XX-PN o un módulo tipo CP343 o CP443.

Para este ejemplo iniciaremos el serverdemo y tras configurar la IP (0.0.0.0 si lo corremos en la propia máquina) pincharemos en “Start”. En la parte inferior se puede ver un espacio donde se registran los eventos que a su vez pueden ser habilitados en la la parte superior.

ServerDemo_01

Por otra parte arrancaremos el software cliente, donde deberemos especificar la IP del serverdemo. Puesto que ambas están en el mismo equipo la IP será la de loopback, 127.0.0.1.

ClientDemo_01

Y pinchando en “Connect”…. Voila! Estamos conectados, en teoría, a un PLC de la serie 300.

ClientDemo_02

Luego exploraremos el contenido de las pestañas, como por ejemplo “Security”.

ClientDemo_03

Para comprobar la manera en la que podremos interactuar debemos irnos a la pestaña “Control”. Como podemos ver, actualmente el PLC están “RUN”, pero si presionamos en “Stop” podríamos pararlo.

ClientDemo_04

En el lado del serverdemo:

ServerDemo_03

Y en el clientdemo:

ClientDemo_05

La herramienta contiene otras muchas funcionalidades que viene reflejadas en el Manual de Referencia que podéis encontrar en el mismo paquete, aparte de distintas casuísticas y topologías. Sin duda Snap7 es un excelente recurso con el que aprender el funcionamiento no sólo de los PLCs del fabricante SIEMENS sino la manera en la que se comunican y explorar técnicamente todo lo que nos ofrecen. Muchas veces nos ceñimos a la parte teórica, buscamos información en uno y otro sitio, pero tener la posibilidad de montarnos nuestro propio laboratorio y simular un escenario por muy simple que sea nos permitirá aplicar todo lo leído y ayudarnos a entender mejor los Sistemas de Control. Así pues ahora toca ponerse manos a la obra.

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

Edorta.