Protección PCs Industriales

En entornos industriales, como es lógico,  también nos encontramos con equipamiento basado en tecnología PC (x86, x64) con una gran cantidad de usos, como controlar una célula de automatización, estación de programación, interactuar con elementos de periferia, visualización de estados de procesos, entre otros muchos.

Sin embargo, las características son muy distintas si las comparamos con sus similares en entornos de oficinas aún cuando estemos hablando funcionalmente del mismo tipo de equipos.

Una de esas diferencias son el superior ciclo de vida lo que nos expone a tratar con equipos con antigüedad elevada pero plenamente funcionales. Sin embargo, hay que decir que presentan algunas limitaciones. Por ejemplo, el sistema operativo, el cual puede estar sin soporte o sin aplicar muchas (sino todas) las actualizaciones que corrijan errores o vulnerabilidades.

Aparte existen otras importantes. En el caso que un integrador haya desarrollado una instalación, maquinaria, DCS, etc. donde exista un equipo de estas características, el contrato de soporte permitirá cualquier intervención únicamente a la empresa desarrolladora, o fabricante. Con ello se busca impedir que ninguna manipulación pueda afectar al normal funcionamiento de componentes, equipamiento o maquinaria e incumplir acuerdos de rendimiento, disponibilidad u operación. Y como no, entre ellas, la aplicación de las actualizaciones de seguridad que tanto se recomiendan.

Eso en materia de sistema operativo, pero si nos referimos a las aplicaciones o software, podremos encontrarnos con escenarios en los no sólo se empleen los del mismo fabricante que sistemas de control, sino también otros empresas y que han sido desarrolladas “a medida” acorde a las necesidades del cliente. A ello hay que sumar que cada parametrización de ese software bien de control, telemetría o visualización será acorde a cada escenario concreto. Esto es, aunque existan dos compañías llevando a cabo la misma actividad, las representaciones, umbrales, alertas, sistemas de seguridad funcional serán distintas.

Por otra parte, el hardware, por su antigüedad, también presenta limitaciones que nos obliga a trabajar con menores recursos hardware, lo cuales deben estar dedicados a las aplicaciones que controlen el proceso o las funcionalidades asignadas. Es decir, no podemos, aún cuando sea posible, implementar software adicional que pueda impactar negativamente en recursos de CPU, memoria o acceso a disco.

Además de lo anterior, tales despliegues, como norma general no se han hecho teniendo en cuenta la ciberseguridad, con lo que es más que habitual que firewalls a nivel de host estén deshabilitados o con un “Permit, Any, Any”; todos los servicios por defecto, habilitados; ausencia de software de seguridad, etc. etc. etc.

Aunque los sistemas de control no estén expuestos directamente en la red, es posible que estos equipos dispongan de dos tarjetas de red. Una “aguas abajo” para comunicar con los elementos de control; y otra “aguas arriba” para ser accesible con otros sistemas de planta, servidores, mantenimiento, etc.

Según todo lo anterior, a la vista está que las circunstancias que rodean a equipos PC o servidores hacen que los riesgos que permitan a algo o alguien, poder llevar a cabo una acción que repercuta en la operación son elevados. Por ello, debemos presentarles especial atención ya que como hemos visto pueden tener la capacidad de interactuar con otros sistemas o tecnología de control y automatización. Obviamente esto no puede afirmarse con rotundidad ya que dada la heterogeneidad puede haber escenarios que no aplique en su totalidad. En cualquier de los casos es necesario desplegar medidas para su protección.

Cuando hablamos de equipos industriales no sólo podremos referenciarnos a HMI (Human Machine Interfaces), servidores SCADA o Estaciones de ingeniería. Podemos encontrarnos como sistemas de visión artificial; DNCs; CNCs; Thin Clients, Visualización, equipos de operador para la visualización de órdenes de fabricación o recetas,

En este sentido la aproximación es distinta a los entornos IT. Aquí, OT, por ser equipos donde los cambios son menos frecuentes; recursos hardware limitados y reservados a aplicaciones concretas; cualquier funcionalidad no puede penalizar funcionalidades, el recurso más frecuente es el Whitelisting.

Esta estrategia se centra en la definición de una “Lista Blanca” donde incluir aquellas aplicaciones que deben ser empleadas para la funcionalidad del equipo. Todo aquello que no esté incluida en ella, no podrá ser ejecutado; sea código, aplicaciones, etc.

Aquí os dejo un enlace donde podéis encontrar más información en un documento elaborado por el ICS-CERT.

Guidelines for Application Whitelisting in Industrial Environments

Conceptualmente hablando, esto mismo puede ser realizado a nivel de red. Esto es, por medio de los firewall de próxima generación con capacidades de realizar DPI (Deep Packet Inspection) y poder permitir o denegar aplicaciones, software o consignas que se envían por protocolos tales como S7, Modbus, Bacnet, Ethernet/IP, IEC 104, entre otros muchos.

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

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

Hace tiempo atrás hablé de la solución de Symantec Critical System Protection, cuyos artículos puede encontrarlos aquí:

Whitelisting en SCI (Parte I)

Whitelisting en SCI (Parte II)

Sin embargo esta ocasión abordaré este aspecto con la solución del fabricante Kaspersky KICS for Nodes ya que, como toda evolución de producto introduce mejoras. Más aún cuando Kaspersky se ha posicionado como líder en el ámbito de la Ciberseguridad Industrial.

Aquí os dejo un video donde se describen algunas funcionalidades, aunque no son las únicas.

Como podemos comprobar esta solución, tanto para equipos clientes como servidores, se basa en distintas capas de protección. Desde el Whitelisting de aplicaciones, control de dispositivos USB, Firewall a nivel de host, antivirus, entre otros.

Desde el punto de gestión, todos los equipos podrán ser gestionados y administrados desde una consola centralizada, como es Kaspersky Security Center, KSC.

Estas y otras funcionalidades son las que iremos descubriendo y ejemplarizando en futuros artículos sobre distintos casos de uso en entornos industriales.

Nos vemos en la siguiente!

 

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.

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.

Viendo los logs:

en total fueron 55 detecciones:

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

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.

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

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

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