SIEMENS SCALANCE S615, firewall para protección de célula

La seguridad perimetral es, y seguirá siendo, el primero de los requisitos para proteger los entornos industriales. Si no somos capaces de establecer los límites y saber hasta dónde llegan los entornos IT y OT, poco podremos hacer a favor de su seguridad. Para ello la apuesta es el despliegue de NGFW y ejercer así un control hasta Capa 7 para Separar y Segmentar nuestras redes. Pero si lo que necesitamos, o queremos, es ir un paso más allá y bajar a nivel de célula, también podremos hacerlo empleando modelos más pequeños pero adaptados físicamente a situaciones ambientales más hostiles de temperatura, humedad, polvo o campos electromagnéticos. Tal es el caso de modelos como Fortinet Fortigate Rugged30D, 35D, 60D y 90D; CheckPoint 1200R o Palo Alto 220R

Sin embargo, puede haber escenarios en los que este grado de protección a bajo nivel no pueda o no tenga porqué alcanzarse.

Por un lado, hay que tener en cuenta un que las actualizaciones de las firmas Antivirus, Control de Aplicación, IDS/IPS, Filtrado Web hay que renovarlas asumiendo un coste mayor o menor dependiendo el número de equipos o el período de soporte contratado. Y por otro, que cada organización determinará el grado de riesgo asumible en función de su actividad. Por lo que podrá aceptar que no es aceptable tal inversión, dando por buena una protección hasta Capa 4 implementando en firewalls superiores los citados controles.

No nos podemos olvidar que cada proyecto lleva aparejado un consumo de recursos, tanto de tiempo, personal y dinero. Dicho de otra manera, ¿cuánto tiempo necesito? ¿Cuántos profesionales me hacen falta? Y … ¿Cuánto me va a costar? Y en este sentido, no solamente en el momento del despliegue sino en los años sucesivos.

Cada organización es única, con lo que arquitecturas, sistemas, procesos, riesgos, amenazas, vulnerabilidades entre otros factores deben ser tratados de forma individual.

Por tanto, por muy buenas y que sean las medidas, y las propuestas sean de máximos, puede haber muchos condicionantes que nos hagan reducir nuestras pretensiones y no ir a propuestas de máximos. Por tanto, deberemos buscar una vez más alternativas y aproximaciones distintas.

En este sentido los fabricantes de equipos industriales disponen de productos de networking para una u otra función. Tal es el caso del equipo SIEMENS Scalance S615

Se trata de un Router/Firewall de pequeño tamaño con el que podremos crear hasta un total de 128 reglas de filtrado en Capa 4 y con el que podremos apoyarnos para realizar un filtrado de las comunicaciones. Posee un diseño pequeño, para equipos individuales o un conjunto reducido de ellos, pudiéndose instalar como es lógico, sobre carril DIN para un montaje próximo al equipo final.

Permite ser alimentado por doble fuente de alimentación a 24VDC, mientras que sus 5 puertos RJ45 nos permiten conectar distintos equipos a nivel de célula un rango de operación de -40º a 70º C. La protección ambiental está situada en IP20.

Ya dentro de las funcionalidades de filtrado (de tipo “Stateful Inspection”) si bien no tendría mucho sentido hacerlo, podremos deshabilitar la funcionalidad de cortafuegos.

Luego dentro del mismo menú podremos definir Servicios IP, Protocolos a nivel de capa 3 e incluso establecer el tipo y código permitidos por ICMP.

La definición de servicios lo encontraremos en la pestaña “IP Service”, desde donde luego los encontraremos como veremos en las reglas a configurar.

Las reglas las configuraremos en la pestaña “IP Rules”. En cuanto a las acciones podremos elegir entre Permitir, denegar o denegar sin enviar ninguna notificación al emisor.

Adicionalmente a las IPs origen y destino, podremos definir las interfaces de entrada y salida para luego completarlas con los servicios.

Para cada una de ellas podremos indicar si queremos registrar algún tipo de log y su respectiva categorización en caso de “machee” con alguna de las reglas configuradas. En nosotros estará definir qué es más o menos importante.

Luego en otro de los menús podremos visualizarlos.

En este sentido conviene mencionar la posibilidad de enviarlos a un servidor Syslog para poderlos consolidad junto con los de otros equipos. Esto cobra especial importancia si contamos con un sistema de correlación SIEM con el que podremos detectar anomalías de forma conjunta y contextualizada.

Como podemos apreciar se trata de un cortafuegos con capacidades reducidas, y con limitaciones en comparación productos de fabricantes especializados. No obstante, puede ser un buen recurso como apoyo a otros con las funcionalidades y motores de análisis necesarios para garantizar unos niveles de protección acordes a las amenazas de hoy en día.

Tal es el caso de la protección PLCs, RTU´s como se puede apreciar en la imagen siguiente.

Hasta aquí la presentación de este equipo, que aunque sencillo, puede ayudarnos a mejorar los controles de acceso a equipos finales.

¡Nos vemos en la próxima!

Un saludo.

Reproduciendo PCAPs, TCPreplay

El uso de protocolos de comunicaciones basados en Ethernet en entornos industriales aparte de ser clara, resulta necesaria para la integración de tecnologías y sistemas que ayudan a mejorar procesos. Aunque, también es cierto, que la existencia de buses de campo basados en comunicaciones serie seguirá estando presente hasta que puedan ser reemplazados por aquéllos. Ethernet ofrece una flexibilidad, escalabilidad y capacidades de integración evidentes.

Sin embargo, esas ventajas traen consigo nuevos riesgos. Los componentes, sistemas y equipos comienzan a estar más expuestos y por tanto con un mayor riesgo frente a amenazas de distinta índole.

Desde el punto de vista de la ciberseguridad en muchas ocasiones deberemos de analizar distintos patrones de tráfico con el fin de identificar activos, anomalías o extraer algún tipo de información que resulte de interés. Para ello deberemos recurrir a capturar tráfico de una manera pasiva o, no intrusiva, para no introducir latencias o variaciones de éstas que puedan afectar los procesos. Algo crítico, como ya sabemos.

Los recursos más empleados son los puertos espejo en switches o dispositivos TAP de los que ya hablaba en las siguientes entradas.

Puerto espejo, un aliado a veces olvidado

TAP devices, Siemens TAP 104

Sin embargo, no son los únicos. Cortafuegos también disponen de estas características como podemos observar en los del Fabricante Fortinet como se muestra en la imagen siguiente. Una funcionalidad a tener presente tanto en los encargados de “Separar y Segmentar” o de proteger una celda, célula o un conjunto menor de equipos siguiendo una estrategia de Virtual Patching

Las capturas que realizaremos están muy bien desde el punto de vista de recolección de información para su análisis posterior, tanto de forma manual o por medio de alguna herramienta que nos facilite la tarea.

Ahora bien, puede darse el caso en el que queramos por ejemplo reproducir ese tráfico en un entorno controlado tal y como se ha producido en nuestra red OT. Algo que como es lógico no podremos realizar en el original

Para esos casos podremos emplear herramientas como la que nos atañe en el día de hoy, tcpreplay. Con tcpreplay podremos reproducir las capturas previamente recogidas e inyectarlas de nuevo en la red y así ver efectos, comprobar configuración de cortafuegos, NIDS, entre otras. Para ello he generado el siguiente escenario:

Desde la estación con una distribución “Kali Linux” reproduciremos las capturas previamente recolectadas para poder visualizarlas en un equipo Windows 10 con el analizador Wireshark.

Para el caso más sencillo, deberemos indicar la interfaz por dónde se inyectará el tráfico y la captura en sí. En nuestro caso “eth0” y “omron.pcap” respectivamente.

Como podemos comprobar las direcciones IP de la captura son distintas a configuradas en los equipos ya que pertenecen al entorno original.

No obstante, dispondremos de otras opciones, dependiendo de nuestras necesidades y objetivos. Por ejemplo.

Establecer la frecuencia con la que emitiremos los paquetes, es este caso 1 segundo:

Como podremos comprobar en la columna “Time” vemos la sucesión de tiempos según lo indicado en el paso anterior.

En otros escenarios podrá interesarnos la opción de enviar los paquetes tan rápido como sea posible con el parámetro “-t”. En este caso podremos comparar los resultados con el ejemplo anterior y ver, una duración de 244 segundos frente a 0,012045. Algo que puede ser útil para comprobar comportamientos, respuestas, etc.

Otras opciones que tendremos será la de poder indicar la cantidad de paquetes a enviar. Por ejemplo, 1 paquete por segundo durante un tiempo de 15 segundos.

Mientras que con el siguiente la emisión de 15 paquetes pero sin la limitación de tiempo.

Hasta ahora hemos visto la posibilidad de definir una serie de parámetros y realizar los envíos. Sin embargo, podremos hacerlo de forma controlada interactuando con la herramienta. Esto puede ser interesante en momentos en lo que debamos analizar, por ejemplo, alguna acción y detectar los paquetes a través de los cuales se ha realizado. Por ejemplo, en un entorno de laboratorio si detectamos la parada de un PLC poder ir paquete a paquete hasta detectar el cambio de estado de la CPU del controlador.

Según la imagen siguiente habremos enviado un total de 100 paquetes. Primero habremos mandado 10, luego 20, luego 5, 50, 10, 3, y 1. En paralelo habremos observado el comportamiento en el entorno que hubiéramos deseado.

La tendencia hacia las comunicaciones Ethernet en entornos industriales en detrimento de las serie es clara, aunque éstas seguirán vigentes durante mucho tiempo ya que la migración requiere de recursos humanos, técnicos y económicos importantes. Algo que puede no ser asumible por las organizaciones.

Pero sobre aquellas que así lo sean, buses de campo como supervisión, es probable que tengamos la necesidad de capturar esas comunicaciones y realizar un análisis posterior en un entorno de laboratorio y con otro tipo de herramientas, como puede ser también Grassmarlin. En el caso de tener la necesidad de querer reproducir tales capturas para observar el comportamiento en un medio o entorno similar al original, tcpreplay es una herramienta a tener muy presente. Ahora queda explorar el resto de opciones.

Un saludo, ¡nos vemos en la siguiente!

Publicaciones CERTSI e INCIBE sobre Ciberseguridad Industrial, actualizado 24/01/19.

Tanto INCIBE (Instituto Nacional de Ciberseguridad de España) como CERTSI (CERT de Seguridad e Industria) publican a menudo en sus respectivas Webs noticias, guías y artículos sobre distintas temáticas teniendo como telón de fondo la seguridad. Para esta ocasión he ordenado las referentes a Ciberseguriad Industrial, que recopilan un buen número de investigaciones, incidentes, análisis, e informes, sobre distintas temáticas.  Sin duda constituye un conjunto de referencias para el aprendizaje de todo profesional que esté o quiera desempeñarse en securización de estos entornos. Espero que os guste y sobre todo os resulte útil.

Un saludo!

Guías:

  1. Despliegue de un IDS/IPS y gestión centralizada de alertas.
  2. Protocolos y Seguridad en SCI.
  3. Identificación y reporte de incidentes de seguridad para operadores estratégicos: Guía básica de protección de Infraestructuras Críticas.
  4. El Puesto del Operador: Guía básica de protección de Infraestructuras Críticas.
  5. Guía de Seguridad de Protocolos Industriales – Smart Grid

 Artículos:

  1. Estándar IEC 61850, todos para uno y uno para todos.
  2. Seguridad industrial 2018 en cifras.
  3. Respondiendo a incidentes industriales, SOC OT.
  4. Mejorando la seguridad en IEC 104 con la ayuda del estándar 62351.
  5. TI y TO, ¿ya son amigos?
  6. Control desde dispositivos portables: viejos conocidos, nuevos riesgos.
  7. Estandarización y seguridad en el protocolo OPC UA.
  8. El protocolo serie, entiéndelo y protégelo.
  9. El responsable de la ciberseguridad industrial en la actualidad.
  10. Información privilegiada y ciberespionaje industrial.
  11. Kill Switch en sistemas de automatización y control.
  12. Acceso seguro a SCI: arquitectura de red para accesos externos.
  13. Lista de para actuación frente a ciberincidentes: Gestión y resiliencia.
  14. Las claves de los últimos ataques en sistemas de control industrial.
  15. Registrando eventos en sistemas de control para mejorar la seguridad
  16. Fuzzing y testing en sistemas de control industrial
  17. Defensa Activa e Inteligencia: Threat Intelligence en los entornos industriales
  18. WPA3, la mayor actualización de seguridad en redes Wi-Fi desde hace más de una década
  19. Amenazas emergentes en sistemas de control industrial
  20. Defensa activa e inteligencia: de la teoría a la práctica
  21. Mitigando problemas de disponibilidad en la industria
  22. Tendencias en la industria, mejoras en la ciberseguridad
  23. Auditorías en comunicaciones inalámbricas industriales.
  24. Monitorizando redes y eventos en SCI: más información, más seguridad
  25. Zonas y conductos, protegiendo nuestra red industrial
  26. Honeypot, una herramienta para conocer al enemigo
  27. Entendiendo el tráfico de red industrial, disectores y Lua y Kaitai
  28. Acceso seguro a los SCI: doble factor y accesos externos
  29. Tú reportas, ellos actúan.
  30. Automatización de bajo conste.
  31. El valor de los indicadores de compromiso en la industria.
  32. Gestión de parches en Sistemas de Control.
  33. Introducción a los sistemas embebidos.
  34. Seguridad Industrial 2017 en cifras.
  35. Convergencia TI-TO.
  36. Retos y riesgos de ciberseguridad y privacidad en IoT.
  37. Iniciativas y y mejores prácticas de seguridad en IoT.
  38. 46 métricas para mejorar la ciberresiliencia en un servicio esencial.
  39. Diseño y configuración de IPS, IDS y SIEM en Sistemas de Control Industrial.
  40. Cómo evaluar mi nivel de capacidades en Ciberseguridad según C4V.
  41. Los conocimientos del personal de seguridad industrial.
  42. Ciberseguridad en las comunicaciones inalámbricas en Entornos Industriales
  43. SNMP, ¿es tan simple como el nombre indica?
  44. Cortafuegos transparentes, ladrillos de cristal.
  45. PRP y HSR: Protocolos redundantes.
  46. Robots y drones en la Industria 4.0.
  47. Hardware Hacking en Sistemas de Control Industrial.
  48. CrashOverride: El malware para SCI ataca de nuevo.
  49. Analizando la seguridad sin riesgos: laboratorios de pruebas.
  50. Asegurando la virtualización de tus sistema de control.
  51. Gestión de credenciales en sistemas de control.
  52. Prevención de intrusos y gestión de eventos para sistemas de control.
  53. Insider, las dos caras del empleado.
  54. Amenazas emergentes en entornos industriales.
  55. Honeypots Industriales.
  56. Gestionar el riesgo de los proveedores como propio.
  57. Seguridad en protocolos industriales – Smart Grid
  58. Criptografía para reforzar la ciberseguridad en entornos industriales.
  59. Características y seguridad en PROFINET.
  60. Analizadores de red en Sistemas de Control.
  61. Seguridad Industrial 2016 en cifras.
  62. ¿Nuevo ciberataque a la red eléctrica de Ucrania?
  63. Inventario de activos y gestión de la seguridad SCI.
  64. Líneas de actuación del Esquema Nacional de Seguridad Industrial.
  65. Protocolos Industriales: Herramientas de Seguridad.
  66. ¿Tu empresa es segura? Medir es el primer paso para conseguirlo.
  67. Atrapando sombras en la industria.
  68. Cyber Kill Chain en Sistemas de Control Industrial.
  69. DDOS de actualidad: IoT y los DNS de Dyn.
  70. Seguridad en BlueTooth: Fortalezas y debilidades.
  71. ZigBee en el laboratorio.
  72. Thinking in Big (Data) y la seguridad industrial.
  73. Seguridad desde abajo: dispositivos finales a escena.
  74. Familia de malware en la industria.
  75. Protegiéndose de BlackEnergy: Detectando anomalías.
  76. Seguridad en Comunicaciones ZigBee.
  77. BlackEnergy y los Sistemas Críticos.
  78. Desmontando Modbus.
  79. Safety y security: juntos pero no revueltos.
  80. BMS: Edificios inteligentes, ¿y seguros?
  81. Seguridad industrial 2015 en cifras.
  82. Un SCADA en la ciudad.
  83. Aplicando seguridad en WirelessHart.
  84. Sistemas de control de software libre.
  85. Arquitecturas de seguridad en la nube para la industria.
  86. Las aplicaciones de control se hacen mayores.
  87. Mi SCADA en las nubes.
  88. Evolucionando la comunicación en la industria.
  89. La Ciberseguridad en la Industria 4.0.
  90. Divide y vencerás: Segmentación al rescate.
  91. Monitorización de amenazas en SCADA.
  92. Evolucionando la infraestructura de red en SCI.
  93. Bug Bounties en SCI: Vulnerabilidades en busca y captura.
  94. El consumo eléctrico bajo control.
  95. Buenas prácticas de configuración en la red inteligente.
  96. Disciplina militar en Control Industrial: OPSEC.
  97. Auditorias en sistemas de control.
  98. Amenazas en los Sistemas de Control Industrial.
  99. Certificaciones de seguridad en sistemas de control.
  100. La evolución de los dispositivos en los sistemas de control industrial.
  101. Estándares de ciberseguridad en las redes inteligentes.
  102. BYOD en entornos industriales.
  103. IEC 62443: Evolución de la ISA 99.
  104. La seguridad de los coches inteligentes a examen.
  105. La ciberseguridad en las subestaciones y el estándar IEC 61850.
  106. Herramientas TI que evolucionan para TO.
  107. La evolución del software en los sistemas de control industrial.
  108. Diferencias entre TI y TO.
  109. Normativas de seguridad en sistemas de control.
  110. Identificación de sistemas de control industrial.
  111. Problemática de los antivirus en entornos industriales.
  112. Seguridad en Protocolos de Sistemas de Control Industrial.
  113. Del Air Gap a la Segmentación en ICS.
  114. Guía de seguridad de Sistemas de Control Industrial.
  115. La problemática de la ciberseguridad para los profesionales de los sistemas de control industrial.
  116. Protegiendo Infraestructuras Críticas: no es suficiente con medidas IT.
  117. Hacia una evaluación eficaz de la seguridad en ICS.

Otras Guías de interés:

  1. Guía de Pentest: Recolección de información (Information Gathering).
  2. Guía sobre análisis de tráfico con Wireshark.
  3. Guia de Seguridad en servicios DNS
  4. Ciber-Resiliencia: Aproximación a un marco de medición.
  5. Detección de APTs.

Sumando fuerzas, Switching y Firewalling para proteger maquinaria e instalaciones industriales

Dentro de cualquier estrategia de protección de entornos industriales no podemos pasar por alto la heterogeneidad de éstos. No podemos considerar de igual manera una actividad dedicada a la fabricación de vehículos, farmacéutica, alimentación o componentes electrónicos. Los tiempos de respuesta, los máximos asumibles de parada, estrategia de producción, pueden no ser para nada similares. Por tanto, la manera en la que debemos priorizar y desplegar las medidas que prevengan incidentes, debe ser distinta.

Pero independientemente del sector, los propietarios de los activos (esto es, las propias empresas) incorporan tecnología distinta de fabricantes, ingenierías, integradores o cualquier otra tercera parte debido al alto grado de especialización aparte de la complejidad o necesidades concretas de estos entornos. Claro está, que en muchos casos sea más operativo, económico o práctico externalizar estas tareas en lugar de desarrollar la solución y el conocimiento con medios internos.

Puesto que forman parte del proceso, se ha de acordar contratos de mantenimiento con el fin de garantizar un recurso en caso de ser necesario y recibir soporte a lo largo del ciclo de vida del producto, que como sabemos, dentro del mundo es OT es mayor que el tradicional IT. Esto es, respuesta ante una incidencia, actualizaciones, modificaciones o cualquier otra razón, de tal manera que el propietario de ese activo no pueda ver afectada su actividad por no saber resolver, atender o actuar sobre él.

Esto supone un problema para los citados integradores ya que una vez sus sistemas o maquinaria están en las instalaciones de sus clientes, dejan de tener, a priori, un control sobre el mismo. No tienen la garantía de que alguien pueda, en un momento dado, “conectarse” y llevar a cabo una acción que derive en un mal funcionamiento y generar un incidente con mayor o menor impacto. Por tanto, resulta necesario controlar los puntos de conexión a ese equipamiento en particular al de red como switches que permitan la comunicación entre equipos y componentes. Particularmente si hay consecuencias económicas…

En este sentido la conjunción de Switches y Firewalls del fabricante Fortinet pueden ayudarnos ya que dichos cortafuegos poseen la capacidad de controlar algunas funciones de los switches mediante un controlador embebido.

En este caso disponemos de un Fortigate Rugged 90D y un FortiSwitch Rugged 112D-PoE.

El Firewall será el que nos una a la red del cliente y evitará que un activo de la red de éste llegue a los componentes de la instalación o maquinaria en cuestión. La configuración podrá ser variada según la topología, esto es, que opere a nivel de capa 2 o 3. Será pues nuestra seguridad perimetral. El modo de acceso lo podemos establecer a través de un túnel VPN a partir de las opciones que nos permite el equipo. Obviamente, habilitaremos los distintos perfiles de seguridad como Antivirus, IDS/IPS, Control de Aplicación, etc.

Ya aguas abajo del Cortafuegos, el Switch permitirá la comunicación entre los equipos finales. Cómo configuremos ambos equipos dependerá del tipo de instalación, arquitectura, tipo de tráfico, conexionado, entre otras variables.

Para poder llevar a cabo esta administración, deberemos configurar una de las interfaces del Fortigate para la comunicación con el FortiSwitch empleando el protocolo FortiLink. En nuestro caso serán enlaces por medio de dos SFP de fibra en ambos extremos. Podréis encontrar más información en estos dos enlaces, enlace 1 y enlace 2.

Por defecto el switch operará en modo “Local Management”.

Si decidimos gestionarlo desde el Firewall deberemos tener presente que la se borrará cualquier configuración existente.

Hecho esto, se nos generarán dos interfaces, dependiendo de las características habilitadas.

Para poder agregar el switch deberemos ir al apartado “WIFI & Switch Controller” y comprobar que el switch se ha detectado y autorizarlo. Una vez hecho el mismo se reiniciará. Según el modelo del switch, por defecto se definirán algunas interfaces de “Auto-discovery”. Podréis encontrar más información aquí.

En el siguiente apartado podremos crear las interfaces de cada una de las VLAN que necesitemos. En mi caso he creado la VLAN100.

A continuación, podremos asignar a cada puerto la correspondiente VLAN y configurar algunos otros parámetros adicionales relativos a PoE, STP, Status, etc.

El último apartado será lo relacionado a las Políticas de Seguridad, algo que nos es objeto por ahora, todo se andará.

Cabe mencionar que aunque veamos que las características de parametrización son menores podremos abrir un CLI desde el apartado “Managed FortiSwitch”.

No obstante, si lo deseásemos también podríamos acceder a la interfaz web. Para ello deberemos de configurar una ruta estática que apunte a la interfaz creada para el enlace Fortilink.

A partir de ahí, podremos acceder a él, no sin antes ser avisados de que este equipo está siendo gestionado por un Fortigate.

Así pues, lo que he querido mostrar hoy es la posibilidad de administrar desde un Firewall algunos parámetros de un switch y con ello ejercer un control sobre los puertos de éste desde éste sin tener la necesidad de acceder a él. Por ejemplo, ante una tarea de mantenimiento, por defecto, dejaremos deshabilitados los puertos que no se utilicen y habilitar uno en caso de ser necesario. Pero si en contreto se trata de una tarea ejercida por un personal externo a la organización como puede ser la ingeniería que construyó la citada maquinaria podríamos, crear una VLAN concreta, asignarla aun puerto del switch y que todo el tráfico pase por el firewall hacia los equipos autorizados, teniendo registro y control de lo que se realice. Aparte, someterlo a filtrado de capa 7, generando los logs pertinentes y registrando evidencias de lo que suceda.

Además, hemos de recordar que los equipos FortiGate también disponen de un controlador Wi-Fi con lo que de forma análoga podremos administrar puntos de acceso tal y como se muestra en la imagen siguiente.

Esto lo podríamos acompañar como puede ser el software FortiClient tal y como lo hablaba tiempo atrás en la entrada “Controlando a nuestros Proveedores, Parte I” y “Controlando a nuestros Proveedores, Parte II”.

Desde luego este es el aspecto más básico ya que podremos explotar algunas funcionalidades más que por ahora no hemos contemplado.

Un saludo, hasta la próxima!

¡Seguimos subiendo, a por 2019!

Una vez más estamos de celebración ya que otro año más hemos superado el número de visitas con respecto al anterior. Si bien el 2017 había finalizado superando la barrera de las 50.000, este 2018 lo ha hecho con 57.077.

Sin duda alguna es un motivo de satisfacción personal el que cada año esta cifra se vea aumentada ya que, de alguna manera, pone de manifiesto el interés o al menos la curiosidad tanto por la temática como por el contenido de cada una de las entradas.

He de confesar que me hubiera gustado publicar más, pero entre la vida profesional, compromisos familiares, personales y que los días sólo tienen 24 horas, hacen que sea complicado. A ver si este año conseguimos aumentar la frecuencia, 😉

Pero como todo, esas 57.077 visitas no hubieran sido posibles sin que muchos de vosotros hayáis dedicado una porción de vuestro tiempo a entrar en este sitio y leer algunos, varios o muchos de los que ya hay. A todos vosotros muchas gracias y espero que este 2019 siga en la misma línea y podamos superar la barrera de los 60.000. ¡Ojalá!

¡Mil y una gracias!

También como no, gracias a los colaboradores fabricantes y distribuidores que tanto en el desarrollo de los proyectos como a nivel individual, han ayudado con la cesión de productos a conocer tecnologías y poder dar ejemplos de cómo llevar a cabo tareas en el despliegue o administración de algunos de sus equipamientos. A ellos muchas gracias también.

Nos quedan 365 días por delante. 365 días en los que aparecerán nuevas vulnerabilidades, nuevas tendencias, nuevos incidentes, nuevas amenazas. Sin duda habrá mucho de qué hablar y sobre todo habrá mucho qué hacer para que organizaciones y empresas sepan sacar el máximo provecho a los avances tecnológicos y  mejorar así sus procesos y actividades. Eso sí, tomando las medidas necesarias que minimicen los riesgos que ésta trae consigo.

Un saludo a todos, Feliz año nuevo, nos seguimos “viendo” por aquí.

¡Salud!

Firewalls en Capa 2 en entornos OT

En muchas ocasiones se habla que la primera medida técnica a implementar en lo que a seguridad en entornos industriales se refiere es definir los perímetros entre los entornos IT y OT. Para ello empleamos NGFW capaces no sólo de filtrar tanto por IPs y servicios sino realizar DPI (Deep Packet Inspection) a nivel de capa 7 además de otras funcionalidades como Antivirus, IDS/IPS, Anti DoS. Ya dentro del entorno OT, la recomendación es definir áreas, o zonas, más pequeñas y filtrar el tráfico entre ellas por medio de un segundo Firewall. El de “Segmentación”.

Físico o virtual, en el supuesto de que un error humano o acción malintencionada se produjese en alguna de ellas, evitaríamos la propagación al resto provocando un daño mayor. Además, si el daño es menor, el tiempo que necesitaremos para recuperar el conjunto de equipos afectado será menor, como menor será su número.

En la siguiente imagen podemos ver una configuración en la dicha separación la hacemos por medio de la definición de Firewalls Lógicos dentro de uno físico del fabricante Fortinet.

El tamaño de estas áreas, zonas o celdas según sea la literatura de referencia, podrá albergar un número mayor o menor de equipos. Una de las opciones es definir una VLAN para cada una de ellas con un único dominio de broadcast y direccionamiento. Esto cubriría aspectos como protocolos industriales que operen en Capa 2 o tráfico multicast como LLDP. De esta manera podremos filtrar cualquier comunicación entre subredes, otras áreas, servidores en IDMZ (Industrial DMZ), estaciones de ingeniería, etc. Todo este tráfico pasaría por el Firewall de “Segmentación”.

Esto supone asumir que una acción malintencionada en la misma subred podría tener éxito ya que el control se efectúa cuando llega, al menos, en Capa 3. No en Capa 2. Pero, ¿qué ocurre si por alguna razón tenemos que llevar a cabo un filtrado a nivel de Capa 2 a un nivel más bajo y un número de equipos más reducido? Quizás una de las respuestas sea el cambio, o rediseño, del plan de direccionamiento de la/las área/s OT en cuestión y así escalar hasta el siguiente nivel. Sin embargo, esto no puede ser viable.

Mejor pongamos un ejemplo gráfico:

Como podemos observar en esta celda disponemos de un convertidor de fibra a cobre hacia un switch (Switch 1) donde se localizan un HMI y del que cuelga otro (Switch 2) al que se encuentran conectados otros controladores, componentes “Safety”, control de movimiento, etc. Si por alguna razón dicho HMI sufriera alguna infección o se quisiera llevar acabo alguna acción malintencionada, podría alcanzar el resto de equipamiento conectado. Vemos que todo se ubica en un mismo dominio de broadcast y con direccionamiento bajo 192.168.0.0/24.

El problema que se plantea es que el HMI sea un equipo con un sistema operativo sin actualizaciones o fuera de soporte. Bien porque la actualización de éstos pueda ser difícil, aunque no imposible, y por otro lado dado, el ciclo de vida elevado, genera más probabilidad de falta de actualizaciones, nuevos desarrollos, pero siguiendo 100% funcionales. Esto puede suponer un riesgo importante a los equipos ubicados en el otro switch de donde cuelgan autómatas, controladores y otros sistemas.

Sin embargo, no podemos olvidar que las intervenciones en entornos OT no sólo deben ser lo menos intrusivas posible sino, que no alteren la operación normal de las instalaciones. El despliegue de soluciones debe ser transparente y con un nivel de riesgo lo más cercano a cero. Como ya sabemos el riesgo igual a cero, no existe.

Cada cambio introduce un riesgo. Por mucho que lo preparemos, planifiquemos, involucremos a todas las personas que puedan responder ante alguna acción no prevista, siempre puede suceder algo que no esté contemplado. La falta de respuesta en tiempo y forma puede desembocar en la pérdida de disponibilidad. Por ello, cuanto menor sea la cantidad de acciones a realizar mejor. Hemos de guardar un equilibrio entre simplicidad y eficiencia.

Es por todo lo anterior que hemos de considerar el uso y funcionalidades a nivel de capa 2 que ofrecen los cortafuegos. Esto es, filtrar el tráfico entre dispositivos que se encuentren en la misma red y tratar de proteger de forma individualizada todos los elementos desplegados en ella sin requerir cambios adicionales. Esto nos permitirá mantener el direccionamiento intacto siendo la única pérdida de servicio, a priori, los segundos que empleemos en conectar el equipo en nuestra red. Obviamente esto introducirá un punto más de fallo, algo que deberemos asumir si lo que queremos es que otro elemento nos proporcione la seguridad que pretendemos.

Por tanto, cuanto más reduzcamos el riesgo sin intervenir en los equipos finales, indudablemente mejor. Claro está esto también dependerá de la criticidad del equipo, su funcionalidad, ciclo de vida, soporte, entre otros factores. Sin embargo, esto no debe ser algo que deba ser así siempre. Para alcanzar unos niveles lo más completos e integrales posibles hemos de aplicar aquellas que estén disponibles en PLCs, switches industriales, entre otros. Aquí os dejo aquellas que podremos encontrar en autómatas modelo S7-1200 del fabricante Siemens.

En el día de hoy he querido destacar la necesidad de uso de modos y funcionalidades a nivel de capa 2 para proteger los entornos industriales, evitando así cambios o interfiriendo en la operativa aunque esto sea tan sencillo como cambiar una dirección IP.

En sucesivas entradas abordaremos este tema y la manera de cubrir estas necesidades. Esto es uso de firewalls a nivel de capa 2, en lugar de 3, como es a lo que estamos más acostumbrados.

¡Nos vemos en la siguiente!