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

Anuncios

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:

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.

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.

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

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.

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.

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?

Anuncios

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.

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.

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:

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

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:Y el Master recogería estos resultados:

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:

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

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

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) :

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:

Generaríamos el siguiente log en el Firewall.

Y también, hacer una lectura:

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.

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

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”.

Y el correspondiente log en el Firewall:

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

Idem con la lectura:

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

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 .

Reduciendo el tiempo de recuperación

Anuncios

Como he comentado en artículos anteriores, el objetivo primero para entornos OT, es garantizar la disponibilidad de las instalaciones, quedando a un segundo y tercer plano la integridad y confidencialidad de la información manejada. Esto no quiere decir que no sea importante, sino que se establecen prioridades.

Lo que se pretende con la securización de las instalaciones, es reducir los riesgos de sufrir un incidente y que se vea afectado el funcionamiento de las Infraestructuras de automatización y Control, ya sean Críticas o Industriales. Sin embargo conviene recordar, que no es menos importante garantizar la seguridad de tipo “Safety”. Me refiero a las funcionalidades de protección a personas, esas que vienen de la mano de accionadores de emergencia, barreras infrarrojas, detectores de presencia, y demás dispositivos que evitan que un técnico de mantenimiento, operario, etc. sufra un accidente que ponga en riesgo su vida o integridad física.

De todos es sabido que las amenazas, vulnerabilidades, riesgos y negligencias están ahí, y que la seguridad al 100% no existe. Lo que hoy puede tener unos niveles aceptables, mañana con la aparición de un nuevo bug, exploit, etc. puede no tenerlo.  Aparte, considerando la idiosincrasia de estos entornos con funcionamientos en muchos casos 24 X 7 X 365, la puesta en marcha de parches, actualizaciones, mejoras y nuevas soluciones, puede retrasarse a períodos de tiempo realmente largos. Eso teniendo en cuenta que puedan ser aplicados sobre las mismas plataformas, ya que no siempre es así.

Por tanto, teniendo en cuenta que a pesar de haber desplegado un plan de seguridad para nuestro entorno OT, ¿es suficiente para garantizar la disponibilidad? ¿qué ocurre durante el este período de tiempo en el que estamos expuestos por no poder aplicar medidas correctoras? ¿qué va a pasar si en ese intervalo sufrimos un incidente?

Pues bien, garantizar la disponibilidad no es sólo poner en marcha aquellas medidas que reduzcan los riesgos, sino que, si sufrimos un incidente, tengamos la capacidad de recuperarnos en el menor tiempo posible. Para alcanzar este propósito es necesario implementar, junto con el resto, un Plan de Contingencia que permita restaurar dispositivos y sistemas a un estado nuevamente operativo.

Por ejemplo, si un HMI queda infectado o por alguna razón su hardware sufre un daño, y esto desemboca en una sustitución del equipo, mientras dure dicha operación nuestra instalación puede quedar fuera de servicio. O bien, un operario realiza un cambio incorrecto en un autómata y debe cargarse el programa a una versión anterior.

Ejemplos se pueden poner muchos, pero lo cierto es que resulta indispensable la inclusión de un proceso de generación de copias de respaldo para cubrir estos supuestos. Cuando hablo de un proceso me refiero a un método. Aquí hay que considerar muchos puntos. Uno de ellos es el tipo de equipo. No es lo mismo un PC, que un servidor SCADA, que un PLC o RTU. Así cómo en los dos primeros podremos instalar un agente que nos haga una copia del sistema operativo, ficheros, aplicaciones, etc. en el segundo y tercero su naturaleza puede que no nos lo permita y debamos elegir otra solución o vía.

Un aspecto clave es establecer la forma en que se hacen de estas copias. Todo cambio debe de estar documentado y programado, salvo que se trate de un incidente obviamente. Por ello debe seguirse una nomenclatura que permita la identificación inequívoca de los ficheros, catalogar si es software, sistema operativo, versiones, fecha en la que se hizo, control de accesos a los mismos por parte de las personas responsables, control de integridad, etc. Además, dependiendo del número dispositivos puede justificarse la instalación de herramientas centralizadas que permitan automatizar este proceso.

La generación de copias lleva aparejado necesariamente un espacio de almacenamiento adicional. Nuevamente dependiendo del número, puede necesitar de una inversión en nuevo hardware o sistemas. Aquí la estrategia marcará la manera de llevarse a cabo. Me refiero a que éstas sean accesibles bien de forma local o por red, esto es, que en caso de recuperación pueda descargarse la copia desde un servidor o desde un disco duro externo conectado via USB.

Aplicaciones en el mercado hay varias. En mi ejemplo utilizaré una del fabricante Acronis en concreto del producto Backup Advanced 11.7. Con él podremos realizar imágenes de disco de nuestros equipos y, como comentaba,  para recuperarlos en caso de fallo, rotura de hardware, o cualquier otra incidencia que afecte a su funcionamiento.

Esta solución consiste en un servidor central de administración y un agente software que se debe instalar en los equipos sobre los que se quiere hacer los backups. Para administrarlo, necesitamos de un software cliente (consola) con el que conectaremos al servidor y desde ahí llevar a cabo todas las operaciones necesarias como pueden ser:

  1. Dar de alta equipos.
  2. Organizar lugares de almacenamientos de las copias (Bóvedas).
  3. Control de acceso y permisos de usuarios.
  4. Programación de copias.
  5. Definición de nodos de almacenamiento.

En lo referente al servidor de gestión, a la hora de instalar nos preguntará sobre cómo va a utilizarse el equipo para a partir de ello instalar más o menos componentes.

En el Escritorio del servidor se habrá generado un acceso directo del software con el que nos conectaremos (consola) , en este caso a nosotros mismos contra la IP 127.0.0.1.

Por la parte del cliente, ha de instalarse dos tipos de software. Uno denominado “AcronisAgentCore” y “AcronisAgentWindows”. La instalación es sencilla, un ejecutable más.

Luego, desde el servidor, deberemos dar de alta los equipos para poder dar las órdenes de la generación de las copias. Lo haremos proporcionando el nombre o IP además de las credenciales definidas en el proceso de instalación.

En el apartado “Equipos con agentes – Todos los equipos con agentes” veremos el equipo ya registrado, para este ejemplo, el “HMI-EST-01”.

Allí encontraremos varios parámetros de configuración. Dadas las características de los entornos industriales me centraré en concreto en dos de ellas. La primera es la compresión. La imagen guardada podrá ser comprimida para ahorrar espacio, sin embargo esto podrá afectar no sólo en la generación de la copia sino también la recuperación de la imagen. Esto habrá de tenerse en cuenta ya que aumentará el tiempo en el que el equipo podrá estar disponible de nuevo.

La segunda corresponde la prioridad que tendrá el agente de Acronis con respecto al resto de procesos que corran sobre el equipo final. La generación de la copia consume una serie de recursos, los cuales no podrán afectar al resto aplicaciones control que corre en ese mismo instante. Las copias deberemos programarlas, de ser posible, para su ejecución fuera del horario de funcionamiento pero en el supuesto de que no sea así deberemos dar prioridad al resto en lugar a la de Acronis.

Finalmente, lanzaremos la tarea teniendo una duración variable en función de todos los parámetros configurados y el rendimiento de nuestra red.

Si bien los valores pueden variar bastante, para hacernos idea, una máquina virtual de 60,5 GB de disco duro se quedó en 44 GB y tuvo una duración del entorno a media hora.

Para poder recuperar un equipo, deberemos crear un dispositivo de arranque, esto es un Live CD o USB. Para ello tendremos que instalar la aplicación “Acronis Media Builder” y definir alguno de ellos.

Con anterioridad deberemos tener cambiados los parámetros en la BIOS del sistema para arrancar desde la unidad de CD o medios extraíbles. A partir de aquí el asistente de Acronis nos guiará durante el proceso, teniendo que asignar una IP e indicar el lugar donde se almacena la copia que queremos recuperar.

El mensaje de hoy no es tanto ver la manera de “protegerse” sino de “recuperarse”. O dicho de otra manera no tanto a la seguridad sino  minimizar el tiempo de recuperación en el caso de que tengamos una brecha. Las estadísticas dicen que las vulnerabilidades descubiertas van en aumento y que los ataques cada vez son más diversificados. Que exista un parche, no quiere decir que se pueda implementar nada más publicarse y por tanto, mientras esta situación se mantenga, los equipos son vulnerables. He puesto el ejemplo de un HMI ya que están a la cabeza de ser el objetivo estrella, para desde ahí llevar a cabo distintas acciones sobre la red de control. Estos HMI están basados principalmente sobre sistemas operativos Microsoft Windows, de ahí que en este caso haya puesto como ejemplo una solución como la de Acronis Backup Advanced, y aplicación sobre equipos con esas características.

Espero que haya sido interesante, lo dicho “garantizar la disponibilidad no es sólo poner en marcha aquellas medidas que reduzcan los riesgos, sino que, si sufrimos un incidente, tengamos la capacidad de recuperarnos en el menor tiempo posible”. 

Saludos!