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

 

Control de Aplicación en entornos ICS/SCADA, Parte II

Hoy vamos a continuar con lo que adelantábamos en la entrada “Control de Aplicación en entornos ICS/SCADA, Parte I” poniendo algunos ejemplos sobre cómo esta funcionalidad en los NGFW puede ayudar a detectar, o prevenir, cierto tipo de actividades.

En ella proponía el siguiente entorno:

En la red 192.168.0.0/24 tendremos un PLC (en este caso un Siemens S7-300 emulado con la aplicación Snap7) con IP 192.168.0.65/24 accesible desde una Workstation, 192.168.0.100/24, destinada a labores propias del entorno. Por otro lado, la red 10.10.10.0/24 donde existe una DMZ, y en ella, un servidor SCADA con IP 10.10.10.101/24. Por último, la Red de Oficinas bajo un direccionamiento 192.168.1.0/24, donde a priori no debiera haber ningún tipo de software de Control.

Como NGFW he empleado un Fortinet FortiWifi 60D, el cual tiene instalada una versión FortiOS 5.4.2. Cabe recordar que en esta versión hay que habilitar las firmas “Industrial” ya que por defecto no vienen activadas.

En “Firewall de Segmentación OT-OT” hemos creado el siguiente perfil “Control de Aplicación” para las comunicaciones entre el servidor SCADA  y la red de Control. Como se puede ver, se bloquearán todas las aplicaciones incluidas dentro de la categoría ”Industrial”. Sin embargo, se hará uso de “Application Overrides” para permitir sólo aquellos protocolos y operaciones propias de nuestras instalaciones. Dicho sea de paso, han tenido que ser identificadas con anterioridad. No obstante, y aunque no es necesario indicarlo explícitamente, se impedirá la parada de PLC, algo reservado sólo a nivel local, no por red.

Fortinet define varios controles sobre el tráfico. Estos son Allow, Monitor, Block y Quarantine. Para conocer las diferencias os dejo el enlace en la página Web del fabricante, pincha aquí.

Ahora bien, en “Firewall  Separación IT-OT”, no habrá excepciones de ningún tipo, absolutamente todo se bloquea. Se entiende que no debe existir ningún software que necesite acceder a la red de control y mucho menos que realice operaciones de lectura o escritura sobre variables, bloques de memoria, funciones, etc.

Respecto a las reglas de Firewall, para este laboratorio he sido bastante “laxo”. Puesto que la intención es destacar el uso de esta funcionalidad, he permitido las comunicaciones entre todas las redes y puertos, siendo el “Control de Aplicación” el único que autoriza o deniega el paso de paquetes. Como todos sabemos, no debiera ser así en un entorno real.

Como hemos dicho anteriormente una de las tareas que no pueden llevarse a cabo desde el servidor es ejecutar la orden de paro de los PLCs. Si lo haríamos, esto sería lo que ocurriría.

Como vemos se genera un log donde se refleja la aplicación identificada y la acción tomada.

Pero siguiendo con el esquema, veremos ahora lo que sucede si alguien desde el entorno de oficinas quisiera obtener alguna información. Los ejemplos siguientes se han hecho con una distribución Kali Linux y aplicaciones Plcscan y script S7-info para Nmap. 

El ambas, el resultado sería el siguiente, siendo el de Plcscan el realizado a las 19:23:34 mientas que Nmap a las 19:25:12 en adelante.

Así pues, el resultado por parte del supuesto atacante quedaría:

Como vemos los escaneos no arrojan ninguna información.  En cambio, si aplicásemos el mismo sensor de “Application Control” para las comunicaciones entre el servidor SCADA y el PLC el resultado sería bien distinto:

Como podemos ver, aquí sí se muestra información ya que las las operaciones que realizan ambas aplicaciones concuerdan con los protocolos y operaciones permitidas, al igual que el servidor SCADA. De esta manera, se podrían extraer datos sobre los equipos para luego seguir con fases más avanzadas o dirigir, somo es lógico, el ataque sobre el fabricante en cuestión.

El “Control de Aplicaciones” puede ser de gran utilidad, sino necesario. Obviamente su configuración y parametrización requiere de una labor que puede resultar costosa en tiempo ya que hay que definir claramente el tráfico que atraviesa por nuestra red. No sólo en lo que se refiere a IPs y puertos, sino también a aquellas aplicaciones que generan el tráfico de Operación, Control y Monitorización. No obstante, no debiera ser la única. Para ser más completos, además habría de acompañarlo de otras como IPS y Antivirus, funcionalidades que ya disponemos. Algo que también resultaría interesante según entornos y necesidades es la consolidación de logs en servidores, tanto para su almacenamiento (Syslog Server) como correlación (SIEM).

Ya por último un factor que no podemos olvidar es que todas estas medidas pueden introducir una latencia en las comunicaciones debido a la carga computacional que requiere el análisis en tiempo real. Según fabricantes, dispositivos y modelos puede variar con lo que dependiendo de nuestra arquitectura, comunicaciones (TCP/IP, RT o IRT), sistemas, etc. es algo que debemos tener presente en cualquiera de los casos.

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

Edorta.

Control de Aplicación en entornos ICS/SCADA, Parte I

Hace poco más de dos meses hablaba de la necesidad de utilizar NGFW (Next Generation Firewall) para securizar nuestros entornos industriales. En ese ejemplo empleaba Modbus como protocolo y el uso de la funcionalidad IPS (Intrusion Protection System) para frenar posibles ataques. El artículo lo podéis encontrar a continuación:

¿Por qué es necesario NGFW en entornos ICS/SCADA?

Si bien los fabricantes están incorporando características de seguridad en sus productos, la presencia de equipos que no disponen de ellas es, y seguirá siendo, muy amplia. Esto es debido a que el ciclo de vida de los mismos es mayor si lo comparamos contra entornos IT tradicionales. Esto da pie a que exista equipamiento “antiguo”, totalmente funcional, pero con vulnerabilidades susceptibles de ser explotadas. Esto es comprensible ya que en el momento de su diseño, la seguridad no era una necesidad. Sí, la funcionalidad y robustez, algo que se mantiene en la actualidad. A veces es posible corregirlas mediante actualizaciones, pero no siempre es así ya que el hardware puede ser parcial o totalmente incompatible según el modelo en cuestión. Entonces, bien sea porque no es necesario su reemplazo o técnicamente posible su actualización, la securización pasa por elementos o medidas externas. Y como no, los NGFW son una de ellas.

Otras de las funcionalidades que poseen los NGFW es el denominado “Control de Aplicación”. Esta permite identificar el software que circula por la red, interpretar la información contenida en los paquetes mediante “Deep Packet Inspection” y a partir de aquí, permitir, bloquear, monitorizar o poner en cuarentena el mismo. Esto facilita reconocer herramientas en entornos donde, en principio, no debiera darse esas comunicaciones y por tanto alertarnos de que algo anormal está sucediendo o, aún peor, una actividad hostil.

Si bien resulta necesario frenar cualquier actividad no autorizada o perjudicial para nuestras infraestructuras, mejor aún es poder identificarlas o frenarlas antes de que se produzcan. Situándonos en el papel de un atacante, antes de llevar a cabo cualquier acción han de darse fases como reconocimiento, identificación de equipos, redes, servicios, vulnerabilidades, etc. debiendo emplear herramientas con las que, de forma activa o pasiva, poder obtener dicha información. Por tanto, si somos capaces de detectarlas, no sólo estaremos previniendo una actividad inusual sino además, que algo o alguien pueda estar dando los primeros pasos antes de llevar a cabo una acción mayor. Y como no, si esto se produce, identificar qué es lo que ha fallado o es necesario corregir.

Por poner un ejemplo, propongo el siguiente escenario:

Arquitectura_APP_CONTROL_01

Escribir una leyenda

En la red 192.168.0.0/24 tendremos un PLC (en este caso un Siemens S7-300 emulado con la aplicación Snap7) con IP 192.168.0.65 el cual es accesible desde una Workstation 192.168.0.100/24 destinada a labores propias del entorno. Por otro lado, tenemos una red 10.10.10.0/24 donde ubicamos una DMZ, y en ella, un servidor SCADA con IP 10.10.10.101/24. Por último, la Red de Oficinas bajo un direccionamiento 192.168.1.0/24, donde a priori no debiera haber ningún tipo de software de Control.

Como NGFWs he empleado un Fortinet FortiWifi 60D, el cual tiene instalada una versión FortiOS 5.4.2. Cabe recordar que en esta versión hay que habilitar las firmas “Industrial” ya que por defecto no vienen activadas.

En la siguiente imagen vemos una captura del Software Step7 de Siemens desde la Workstation que citaba anteriormente.

Step7_01_EDITADA

Para el “Firewall Separación IT-OT” de los entornos de Oficinas y de Control, hemos creado el siguiente perfil de “Application Control”. Aquí bloqueamos todo tipo de aplicaciones, no debe darse ninguna comunicación desde un lado a otro.

APP_CONTROL_IT-OT_001

Sin embargo, ya dentro del entorno OT, en “Firewall Segmentación OT-OT”, sí que permiten las aplicaciones “Industrial” y “Network Services”. Esto es:

APP_CONTROL_OT-OT_001

Si queremos ser más estrictos podríamos bloquear una categoría completa y permitir a su vez que aplicaciones incluidas dentro de ésta, se ejecuten. Esto es, monitorizar la actividad de estos dos últimos y sin embargo denegar una acción concreta. Esto se consigue mediante la opción “Application Overrides”, cuya configuración prevalecerá sobre la definida de un modo más global.  En la imagen siguiente podemos ver que aunque monitoricemos el tráfico, vamos a impedir especificamente la acción de Bloquear la CPU del PLC mediante el protocolo S7 de Siemens.

APP_CONTROL_OT-OT_002

También podríamos hacer lo propio definiendo un filtro, “Filter Overrides”. Por ejemplo todas las comunicaciones “Cliente-Servidor bloquearlas independientemente de qué categoría estén.

APP_CONTROL_OT-OT_003

A partir de aquí será configurar las reglas en el Firewall según sean nuestros direccionamientos, interfaces y servicios de igual manera que lo sería en un Firewall tradicional. Es decir, podemos definir que desde un origen a un destino y bajo un mismo puerto sólo se puedan llevar a cabo tareas específicas de ese protocolo.

Hasta aquí una presentación de los que es y para qué se utiliza el “Control de Aplicaciones” dentro de un NGFW del fabricante Fortinet. En la próxima veremos algunos ejemplos y la funcionalidad de esta característica.

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

Un saludo.

Edorta.

¿Por qué es necesario NGFW en entornos ICS/SCADA?

Como he hablado en otras ocasiones el primer paso para securizar un entorno de control y automatización es separarlo del de IT mediante un dispositivo de seguridad perimetral. Luego, ya dentro del propio entorno OT, es necesario segmentar la misma en áreas más pequeñas con el fin de que si se produce un anomalía o incidente, éste no se propague al resto y ponga en peligro la disponibilidad total, o parcial, de las instalaciones.

separacion_01

El dispositivo estrella para este tipo de tareas es el firewall. Los cortafuegos tradicionales (L2, L3, L4) han quedado ineficaces ante el creciente y diversificado aumento de amenazas, vulnerabilidades y vectores de ataque. Surgen entonces los NGFW (Next Generation Firewall) que además de las características típicas incorporan otras como motores Antivirus, IDS/IPS, Control de Aplicación, Filtrado Web y DPI (Deep Packet Inspection).

A continuación, indico algunos enlaces de artículos relacionados a este respecto.

  1. Defensa en Profundidad, breve repaso.
  2. Defensa en profundidad OT
  3. Separar y Segmentar, primeros pasos para reducir riesgos…
  4. Virtual Patching en funcionamiento (Parte I)
  5. Virtual Patching en funcionamiento (Parte II)
  6. Virtual Patching en funcionamiento (Parte III)

En la entrada de hoy vamos a ver la necesidad de este tipo de dispositivos NGFW en detrimento de los tradicionales. Para ello me voy a basar en el software utilizado en la entrada “Simulador de protocolo ModBus”, creado el siguiente entorno.

arquitectura

La idea es representar dos supuestos entornos; uno IT (de Oficinas) y uno OT (de automatización). En este último he simulado un equipo cliente ModBus el cual será el “objetivo” de las acciones a realizar. Por otro lado, en parte de IT/OT, situaré el posible “atacante” (Kali Linux) junto con un equipo legítimo (Maestro Modbus). He decidido especificar IT/OT para cubrir dos supuestos. Cuando me refiero a “IT”, represento el concepto de “Separación” y con “OT” el de “Segmentación”. De esta manera cubrimos las posibles acciones llevadas a cabo desde la propia red de Control como desde otra ajena a éstas como puede ser la de “Oficinas” o Internet si consideramos equipos accesibles remotamente. En cualquiera de los casos, ambos están separados por un equipo Fortinet FortiWifi60D con una versión de FortiOS 5.2.8. Habrá que piense que esta versión ya tiene un tiempo y que las hay más nuevas. Tiene razón, pero hay una explicación. Las actualizaciones en equipos industriales, se producen en intervalos de tiempo superiores si lo comparamos contra entornos IT con lo que es muy común encontrarse no con las últimas. Además de esto, no debemos olvidar el uso de equipamiento acorde a la actividad que vamos a realizar. Lo correcto sería emplear, por ejemplo uno de la serie Fortinet Fortigate Rugged.

Así pues, el esclavo queda configurado como sigue:

esclavo_01

Por otro lado, el firewall permite el tráfico según la siguiente regla.

config_forti_01

Como se puede apreciar sólo se deja pasar el protocolo “ModBus” (TCP-502), entre la red 172.30.123.0/24 y el destino “Esclavo_MODBUS” (172.20.123.200). Lo suyo sería dejar pasar sólo aquellos equipos que lo necesiten. Aparte de ser un entorno de laboratorio, en la vida real, es probable que alguien se pueda configurar manualmente la IP de un equipo legítimo, la infección de uno de ellos o las conexiones vengan de redes configuradas con DHCP con lo que se abra a todo su rango. No es descabellado. Lo dicho, cobra especial importancia la correcta configuración de las reglas del firewall.

Según lo anterior el resultado de una conexión legítima al esclavo sería la siguiente:log_forti_01Y el Master recogería estos resultados:

master_01

Considerando las características de ModBus que no posee ninguna medida de seguridad nativa, un atacante podría con alguna herramienta poder leer o escribir datos. Para este caso he utilizado mbtget, la cual podéis encontrar aquí.

Así pues leeremos los siguientes registros:

kali_01O escribir, por ejemplo, “12345” en la primera entrada.

kali_02

Y… oh sorpresa! el usuario legítimo lo vería….

master_02

Con ello vemos que los Firewall tradicionales no son del todo efectivos para este tipo de entornos y protocolos. Vamos a proceder a configurar el “Perfil de Seguridad”, término que emplea Fortinet para definir las características de seguridad adicionales y que son definidos en cada una de las reglas. Estos perfiles pueden ser ajustados según necesidades. En el siguiente ejemplo optamos por activar en “Modo Monitor” de la característica “IPS” con lo que operaría como un IDS (Intrusion Detection System) en lugar de un IPS (Intrusion Prevention System) :

config_forti_02

Aún podríamos llevar a cabo una escritura con el valor “55555” en el esclavo desde el equipo atacante, ya que sólo detectaríamos tal acción:

kali_03

Generaríamos el siguiente log en el Firewall.

kali_07

Y también, hacer una lectura:

kali_04

Como vemos en los logs del Firewall, en la columna “Action” vemos como figura “detected”. El tráfico se ha detectado pero no se ha cortado.

log_forti_04

Sin embargo, si cambiamos el perfil IPS y esta vez lo reconfiguramos como “Block”

ips_02

config_forti_03

El atacante se encontrará que no podrá llevar a cabo la escritura. Por ejemplo modificando el primer campo con el valor “8888”. Se produce un “timeout”.

kali_05

Y el correspondiente log en el Firewall:

log_forti_05

Aquí ya vemos cómo en la columna “Action” ya consta como “Dropped”.

Idem con la lectura:

kali_06

log_forti_06

Mientras tanto el cliente legítimo sigue funcionando con total normalidad.

master_03

En el día de hoy hemos comprobado la funcionalidad IDS/IPS para este equipo del fabricante Fortinet, sin embargo, no es la única que debemos aplicar. Hay que apoyarse en otras como Antivirus, Control de Aplicación y filtrado Web. Esto debe mantenerse bajo cualquier circunstancia, también cuando estos firewalls se empleen para establecer VPN y acceder a éstos de forma remota.

Adicionalmente, conviene que los logs generados, se consoliden en un servidor para poder ser almacenados y analizados bien para llevar a cabo una monitorización del estado de la seguridad por medio de un SIEM, como para realizar labores de forénsica en caso de ser necesario. Fortinet cuenta con algunos productos específicos como FortiAnalyzer o FortiManager, que aunque sea este último una herramienta de gestión incorpora algunas funcionalidades de gestión de logs. Este tipo de soluciones deben de contemplarse desde el inicio de los proyectos. Hemos de tener una visión más allá del despliegue inicial ya que todo lo que instalemos luego hay que administrarlo por lo que a la hora de elegir tal o cual producto, esto también ha de considerarse.

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

Identificando tráfico en redes ICS, Grassmarlin.

Son muchos los motivos que nos pueden llevar a realizar un análisis de tráfico, desde una auditoría, documentación de tráfico, hasta una labor de troubleshooting, etc. En concreto esto cobra mayor importancia en los entornos industriales con la evolución de los protocolos de comunicaciones hacia estándares Ethernet y TCP/IP permitiendo la integración con otros sistemas y tecnologías dando lugar a la llamada Industria 4.0 e IIoT.

Pero esta integración también tiene sus riesgos, ya que el grado de exposición dentro de la red aumenta con lo que resulta necesario implementar estrategias de seguridad que reduzcan los riesgos de sufrir un incidente.

Dentro de un proceso de securización, en concreto, de un entorno industrial, una de las primeras zonas donde intervenir es a nivel de infraestructura de red. Aquí surgen dos conceptos importantes como son “Separación” y “Segmentación”. Por separación entendemos dividir las redes de entornos IT tradicionales como por ejemplo “Oficinas”; y las redes de automatización OT como pueden ser las de producción en una empresa manufacturera. Entre cada una de ellas es necesario instalar un elemento de seguridad que filtre todas aquellas comunicaciones entre ambos entornos, siendo el más común un NGFW que además de las funciones tradicionales de un cortafuegos añada una capa más de seguridad con motores Antivirus, IDS/IPS, Control de Aplicación, DPI, etc.

Separacion_01

Hecho esto, la siguiente fase es segmentar nuestro entorno OT. Esto es, fraccionar en áreas, zonas, celdas, más pequeñas nuestra red o conjunto de redes, de tal manera que en caso de incidente en una de ellas, éste no se propague al resto y ponga en peligro la totalidad de las instalaciones. Recordemos que la regla número uno es garantizar la “Disponibilidad”. Esto requiere que todo el tráfico de cada una de estas áreas, celdas, etc. pase nuevamente por un dispositivo tipo NGFW y quede condicionado a unas políticas de seguridad preestablecidas.

Escenario_01

Ahora bien, para que todo esto funcione deberemos en primer lugar identificar el tráfico y realizar el análisis del que hablaba al principio.

El primero de los pasos será capturarlo para posteriormente realizar el análisis para extraer de él la información que necesitemos. Para llevar cabo esta tarea contamos con la aplicación Grassmarlin.

GrassMarlin es una herramienta destinada a entornos industriales y sistemas SCADA con la que podremos llevar a cabo:

  1. Identificación de tráfico
  2. Descubrimiento de dispositivos.
  3. Representación lógica y física.
  4. Gráfico de segmentos o arquitecturas.
  5. Exportar información a formato .CSV.

Todo ello lo realiza de forma pasiva sin interceder en la operativo normal de la operación de los equipos. Para ello permite dos opciones:

  1. Interpretar la información contenida en un fichero PCAP
  2. Captura de tráfico con la propio Grassmarlin.

Para conseguir esta información sin interceder en la operativa, la forma de hacerlo es la configuración de un puerto en modo “port-mirroring” (puerto espejo) de tal manera que recibamos una copia de todo el tráfico hacia/desde otros que sean de nuestro interés. Os dejo dos enlaces ejemplo sobre cómo hacerlo sobre dispositivos de distintos fabricantes.

Siemens

Cisco

Es posible descargarla desde aquí, estando disponible para sistemas operativos Microsoft Windows y Linux. Su última versión es la 3.

Para el presente artículo voy a partir de una captura que importaré a Grassmarlin.

captura_01

En la zona de “Network Tree Map” podremos ver tanto las redes y los nodos existentes; mientras que en la parte derecha la “Logical View” la forma gráfica de la misma con los enlaces entre uno y otro.

Si sobre uno de los nodos hacemos “botón derecho”, “Show all connections” podremos ver todas aquellas relacionadas con éste, junto con un gráfico representativo del tamaño del paquete en función del tiempo.

captura_02

Si sobre uno ellos hacemos nuevamente “botón derecho” podremos ver dicha captura en Wireshark. Esta aplicación se instala por defecto, pero en una versión antigua. Si disponemos una más reciente, podremos configurarlo en “Option – Preferences – Wireshark Executable Path” y abrirlo con ésta. Luego, en la esquina inferior derecha tendremos la opción de exportar el contenido a un fichero con formato CSV y a partir de ahí formatear y explotar la información para uno u otro propósito.

captura_03

La aplicación incluye por defecto algunos identificadores como pueden ser los primeros 24 bits que hacen referencia a los fabricantes en las direcciones MAC. No obstante, si no localizamos alguna podremos dar de alta nuevas en función de nuestras necesidades.

captura_04

Lo mismo ocurre con los protocolos.

captura_05

Allí encontraremos un buen número de ellos, pero si en el caso de que queramos bien editar uno existente o crear el nuestro propio, tendremos la capacidad de hacerlo. Aquí os dejo una muestra de modbus.

captura_06

Finalmente comentar que Grassmarlin dispone de una vista física. Esto es una representación de los equipos. Según he visto en distintas webs, la versión 3 sólo dispone de compatibilidad con dispositivos Cisco. La información que deberemos contener en un fichero de configuración para su importación es el resultado de los siguientes comandos:

  1. “show running-config”
  2. “show ip arp” (OU) “show mac address-table”
  3. “show interfaces”

Como podemos comprobar Grassmarlin puede sernos de mucha utilidad. En el proceso de trasformación de la industria y de la inclusión de políticas de ciberseguridad, identificar el tráfico resulta vital. Es muy común que los responsables o personas involucradas en procesos de fabricación, ingeniería, mantenimiento, etc. no estén familiarizados con todos estos términos y ni conozcan cómo y de qué manera se comunican sus equipos. Como mucho te puedan decir, si tal o cual equipos lo hace con tal o cual servidor o dispositivo, pero hasta ahí. Esta herramienta nos podrá facilitar mucho esta tarea y sobre todo poder comenzar a documentar todo aquello que sea necesario y evitar así esta situación.

Espero que os haya gustado, nos vemos en la siguiente.

Edorta

Separar y Segmentar, primeros pasos para reducir riesgos…

Hace unos meses hablaba del concepto de Defensa en Profundidad en entornos industriales y de las medidas que ello conlleva para reducir el riesgo de sufrir algún incidente de seguridad. Como podemos comprobar no se trata de tomar una única medida, sino que es la suma de un conjunto de ellas aplicadas en distintas capas.

Una que resulta fundamental y deberemos implementar en primera instancia, es Separar y Segmentar nuestras redes. Veremos de qué se trata.

Cuando hablamos de separar nuestras redes, hablamos de establecer una frontera entre la red “Común” donde ubicamos las redes IT tradicionales como un entorno de “Oficinas”; y nuestra de red de automatización o control, llamémosle de “Producción”. La forma cómo lo hacemos es, introduciendo un elemento de seguridad perimetral como un Cortafuegos que permita sólo aquellas comunicaciones que sean estrictamente necesarias. Sin embargo deberemos tener presente aspectos clave en estos tipos de equipos, como que sean Cortafuegos de Próxima generación (NGFW, Next Generation Firewall) con funcionalidades IPS/IDS, Antivirus y Control de Aplicaciones; y que soporten protocolos de ámbito industrial tales como Profinet, Modbus-TCP, OPC, DNP3, ICCP, etc. Es decir no nos vale que sólo hagan DPI (Deep Packet Inspection) sobre FTP, DNS, HTTP, (que también son necesarios) si lo que nos interesa es detectar las amenazas propias de sistemas de control, carentes algunos de ellos de medidas de seguridad inherentes. Ahora bien, no nos podemos olvidad que estos dispositivos introducen latencias y por tanto, dependiendo del ámbito de automatización, estaremos introduciendo retardos, que pueden ser inasumibles.

Dicho lo cual, y por representarlo de forma simple y gráfica, nos quedaría de la siguiente manera:

Separacion_01

Como podemos comprobar estamos hablando de una separación física de ambos entornos. Cada una pose uno o varios enlaces a través del dispositivo de Seguridad Perimetral, y cuyo tráfico será sometido a las reglas que configuremos en él. Obviamente estos equipos, dependiendo de fabricante y modelo, podrán tener unas u otras capacidades.

Al mismo tiempo lo idóneo es que la red de control posea todos los recursos necesarios (servidores de almacenamiento, DNS, NTP, etc.) para poder operar de forma totalmente independiente de la red de “Oficinas” pero lamentablemente esto no siempre es así.

Las redes físicas completamente separadas constituyen la mejor de las opciones, ya que pueden utilizarse para conseguir una separación lógica y física total. Ambos entornos se basan en su propia topología y al no tener componentes de red compartidos tales como switches o routers, todas las comunicaciones de entrada y salida entre la red “Común”, y las redes de “Automatización”, se controlan mediante un punto de seguridad como el NGFW definido anteriormente.

A nivel de infraestructura esta solución también aporta la ventaja que cada cual puede desarrollar su actividad de manera diferente. Por tanto, ante cualquier cambio o migración en los entornos, sólo es necesario modificar el elemento de acoplamiento al Firewall para seguir garantizando la comunicación. Esto es especialmente importante considerando los ciclos de vida del equipamiento en entornos OT, mucho mayor en comparación con los de IT.

No nos debemos olvidar que la premisa de los entornos industriales y las Infraestructuras Críticas es garantizar la disponibilidad de las instalaciones, por tanto en caso de producirse algún fallo en la red “IT”, éste no afectará al entorno “OT”.

Separados ambos entornos, el siguiente paso será aplicar el concepto de Segmentación. La  Segmentación consiste en subdividir la red, o redes, del entorno de automatización en lo que denominamos “Zonas de Seguridad”, y la aplicación de un “Punto de aplicación de seguridad”.

Definiremos como “Zona de Seguridad” al conjunto de dispositivos, aplicaciones, servicios y otros activos agrupados según su ubicación, funcionalidad o condición, tanto desde un punto de vista físico como lógico. Un “Punto de aplicación de seguridad” es un elemento o dispositivo, normalmente un Firewall, cuya  misión es la de filtrar todas las comunicaciones hacia, desde o entre, las distintas “Zonas de Seguridad”. La idea es sencilla, agrupar y aislar  un conjunto de activos y controlar todos los flujos de comunicaciones entre ellos. Al hacerlo conseguiremos por un lado, reducir el grado de exposición que tendrá una “Zona de Seguridad”, y por otro, en caso de producirse un evento de seguridad (ataque, escaneo, propagación de malware, etc.) quede confinado a su “Zona”. Esto no sólo reforzará nuestra seguridad sino que además aumentará nuestro grado de resiliencia frente a cualquier fallo producido por algún tipo de actividad hostil, ya que, aunque una “Zona” haya quedado aislada o sus comunicaciones bloqueadas, el resto de “Zonas” podrán seguir estando operativas. No estarán al 100% pero al menos podrán seguir funcionando a un rendimiento menor durante equis tiempo.

Escenario_01

Una de las preguntas claves es, qué tamaño debe tener una “Zona de Seguridad” y qué dispositivos hay que incluir en cada una de ellas. Cada arquitectura es única,  no sólo por el tipo de equipamiento en sí, a veces común pero distinto según fabricante, modelo y prestaciones, sino cómo cada sistema está desplegado dentro de su propio entorno y cómo se comunica con otros para formar una única, completa e integrada red de control industrial. No existe una respuesta única de cómo se debe diseñar una arquitectura concreta ya que son muchos son los factores a tener en cuenta propios de cada instalación. Algunos de ellos, que no los únicos, son; tamaño de la empresa, sector, actividad, criticidad de los elementos, capacidad de la electrónica de red, antigüedad de los equipos, vulnerabilidades, perfil de usuarios que acceden a ellos, etc.

Nuevamente,  un aspecto clave  son los tiempos. No nos podemos olvidar que en los entornos industriales ha de garantizarse, en primer lugar la disponibilidad de las instalaciones. Por ello en la decisión qué y cuántos componentes se pueden combinar dentro de un área de seguridad deberemos estudiar cuánta cantidad de tiempo es asumible y cuánta no, en el supuesto que algún suceso deje inoperativos, total o parcialmente, nuestros equipos.

Otro de los elementos que deberemos contemplar es la creación de una DMZ. Sí, aquí, en los entornos industriales también debe haberlas. El concepto de esta DMZ es muy similar al que se ha hecho en los entornos IT tradicionales. En esta Zona ubicaremos aquellos recursos compartidos que pudiera haber entre ambas zonas como servidores Antivirus; gestor de parches; otros específicos de la red de automatización como Bases de Datos, ficheros, NTP, DNS, pasarelas VPN, Escritorio Remoto, etc.

Escenario_02

Como vemos poco a poco a medida que nos adentramos van apareciendo más componentes y más aspectos a tener en cuenta. Esto es sólo la “punta del Iceberg”. Seguramente muchos de los que lean el presente verán que faltan muchas cosas, ¡VAYA QUE SI FALTAN! Esto es sólo un esquema genérico, luego hay que profundizar sobre cada uno de los aspectos. Por ejemplo, deberíamos hablar de las ACLs que nos servirán de apoyo para discriminar cierto tipo de tráfico a nivel de la electrónica de red; cómo configurar los equipos en Alta Disponibilidad; ¿enrutamiento estático o dinámico?; diseño de VLANs; cifrado de comunicaciones; y un largo etcétera.

Resumiendo, mucho se podría hablar y escribir sobre cómo diseñar, o ajustar, la arquitectura de red. Podremos establecer parámetros, líneas de trabajo o estrategias genéricas, pero luego cada proyecto es totalmente distinto.

Con esto damos por concluida la entrada de hoy que al igual que las anteriores espero sea de vuestro agrado. Os invito a que dejéis vuestros comentarios.

Un saludo, nos vemos en la próxima.