En diciembre de 2015 el ICS-CERT publicaba un documento sobre las 7 estrategias que pueden ser implementadas para contrarrestar las debilidades más comunes en los sistemas de control industrial. El resumen y enlace lo podéis encontrar aquí.
Hoy vamos a hablar sobre la primera de ellas, “Application Whitelisting (AWL), o “Listas Blancas de Aplicaciones”. Veamos de qué se trata.
AWL ofrece un enfoque distinto respecto a la seguridad de un host más allá de un HIDS/HIPS, antivirus u otras tecnologías basadas en “Lista Negras», o “Blacklists”. Una solución este tipo, compara el objeto monitorizado contra una lista de lo que es conocido como “malo”, no permitiéndose ejecutar. Esto presenta dos problemas; uno, que la “Lista Negra” debe ser actualizada periódicamente, lo cual conlleva una labor de administración importante; y la segunda, que no hay forma de detectar ataques “zero-days”. O bien, no estén disponibles aún las actualizaciones de las que sí se conozcan.
Por el contrario una “Lista Blanca” crea una lista de lo que es conocido como “bueno” y le aplica un criterio simple: si no está en la lista, se bloquea.
Las soluciones basadas en “Listas Blancas” emplean esta lógica sobre aplicaciones y ficheros de un equipo tipo PC, Thin Client o cualquier otro dotado con un Sistema Operativo compatible. Por ejemplo, si un malware consigue vencer el perímetro de seguridad, y encontrar la forma de llegar a un equipo éste evitará su ejecución puesto que no se encuentra en su lista blanca. No lo “mata” pero lo “frena”. También puede ser empleado para prevenir la instalación de software autorizado en el sistema.
Los distintos antivirus dependen de continuas actualizaciones de sus firmas. A medida que éstas aumentan, y con toda certeza, la demanda de recursos también. Esto sobre hardware relativamente nuevo puede no llegar a ser un problema pero en entornos industriales donde el ciclo de vida es mucho mayor, puede afectar al rendimiento del equipo. Eso hablando de Sistemas Operativos que aún tienen soporte y del que existan productos comerciales compatibles.
Para el caso de estos Sistemas Operativos “legacy”, AWL es una buena solución ya que al no disponer de parches o actualizaciones, si un malware quisiera aprovechar una de ellas, y al no estar definido en la lista, no podría ejecutarse o realizar cambios en el sistema. Aparte, aunque las hubiera, tampoco sería necesario (aunque si aconsejable), su instalación (previa descarga, testeo y evaluación, claro) ya que sólo sería necesario actualizar las AWL cuando lo hagan las aplicaciones.
A diferencia de los de los antivirus los cuales pueden registrar un aumento en el uso de CPU o memoria en el momento de lleva a cabo el análisis, con AWL puede definirse un comportamiento base después de la instalación puesto que éste se mantiene relativamente estable durante su operación.
AWL se ubica dentro de las estrategias de Hardening de sistemas, como por ejemplo HMI, estaciones de trabajo u otro tipo de equipos involucrados en las áreas de automatización. No obstante, algunos fabricantes de este tipo de soluciones han incorporado más funcionalidades a las propias del control de aplicaciones, como pueden ser el control de dispositivos USB (fuente de infección y propagación), reporting con mayor y menor detalle de eventos en el sistema, creación dinámica de las Listas, Sandboxing, etc.
En el siguiente enlace podréis encontrar un informe sobre algunos aspectos adicionales sobre “Whitelisting” elaborado por el ICS-CERT. Enlace.
La administración puede efectuarse en modo Stand-Alone, esto es actuando sobre el agente o bien de forma centralizada desde un servidor.
Para esta entrada he elegido Symantec Embedded Security: Critical System Protection una solución que va orientada en esta línea.
En mi caso he desplegado el siguiente entorno virtual simulando distintos entornos:
El esquema lo he “decorado” con supuestos equipos conectado, aunque lo relevante aquí son los PC que quedan definidos de la siguiente manera:
Windows 2012 R2: 192.168.10.254/24
Windows XP: 192.168.10.10/24
Windows 7: 192.168.10.20/24
Windows 2000: 192.168.10.30/24
La solución cuenta con 3 componentes principales; el software del servidor de gestión; el cliente pesado (consola), para conectarse al servidor de gestión; y el agente que se instala en los equipos finales. Para el ejemplo he utilizado la versión 6.5.1 para todos los componentes, excepto para el Windows 2000 que ha sido la 5.2.4 por temas de compatibilidad. Además de esto, conviene resaltar algunas consideraciones más:
El servidor para su funcionamiento requiere de una base de datos. Dependiendo del número de equipos podremos que ésta resida en el mismo o en uno dedicado. Para esta ocasión he seleccionado la “Express”, no recomendable para un entorno de producción.
Los puertos empleados, importante si estamos detrás de un Firewall, son:
En lo referente a los agentes comentar el error que surge en sistemas operativos Windows 7 Professional ya que éstos requieren de un controlador firmado. En mi caso he aplicado los parches correspondientes y no ha habido más problemas. Más información aqui.
La instalación de los “Agentes” no es compleja. A lo largo del proceso habrá que definir el tipo de administración; funcionalidad IDS, IPS (o ambas); IP del servidor; certificado para el cifrado de las comunicaciones.
A partir de aquí a través del cliente pesado nos logueamos en el servidor y podremos ver nuestros equipos.
Desde la consola central tendremos varias pestañas, en “Home” localizaremos información básica.
Aquí conviene destacar dos conceptos importantes en “Prevention” y “Detection”. “Prevention” hace referencia a aquello que se permite, o no, esto es aplicaciones (Whitelisting), Usuarios que pueden hacer cambios, Sandboxing, etc. Mientras que “Detection” hace referencia a todo aquello que se registra o notifica, como si un usuario se ha logueado incorrectamente, intento de cambio en un registro, de conexión por red, etc. En cada equipo deberá aplicarse una política de cada. Cada una de ellas se podrá (y deberá) configurar según las características del equipo, con lo que se deberá permitir o no. En el caso de las de “Whitelisting” la herramienta emplea distintas “Sandboxes” predefinidas, aunque podremos crear las nuestras propias.
Por defecto la herramienta viene con un conjunto de políticas hechas, las cuales podremos copiar y ajustar según nuestras necesidades. Para ello se definen tres estrategias “Basic”, “Hardened” y “Protected Whitelisting”.
Con esta entrada de hoy hemos hecho una introducción a un software de Whitelisting para bastionar nuestros sistemas, en concreto bajo sistemas operativos Windows, aunque la compatibilidad del producto se extiende a Linux también.
En entras sucesivas iremos descubriendo más información al respecto.
Nos vemos en la siguiente!!
