¿Whitelisting en sistemas de control?

Desde que la seguridad empezó a tomarse en serio en los sistemas de control, una de las principales preocupaciones ha sido cómo combatir el malware y la ejecución de exploits en estos entornos.

A nivel de oficina (los entornos TIC clásicos) lo más típicos suele ser mantener el sistema operativo y las aplicaciones parcheadas, disponer de un sistema antivirus actualizado con las últimas firmas, asegurarse de que los usuarios dispongan de los mínimos privilegios necesarios para realizar su trabajo, controlar mediante proxy la navegación web, y en algunos casos, limitar el uso de puertos USB o similares. Aunque la concienciación del personal es clave para lograr un uso responsable y seguro de los equipos finales, no conviene fiarse del eslabón más débil de la cadena.

Como ya hemos contado en alguna ocasión [1], los sistemas de control poseen ciertas características que los hacen diferentes de una red de oficina o servidores: limitación de ancho de banda, memoria y CPU en los equipos de campo; necesidad de garantizar una precisión en los datos del proceso monitorizado, tanto en el tiempo de respuesta como en calidad del valor de lectura de las variables a monitorizar; etc.


A la eterna discusión [2] [3] [4] sobre si los sistemas antivirus (AV) son realmente eficaces, conviene añadir las reservas que estos suscitan entre los responsables de los sistemas de control. Resulta crítico estudiar en detalle las consecuencias de integrar una solución antivirus comercial generalista en estos entornos. Conviene pensar en términos de configuración de: la acción por defecto cuando se detecta un fichero infectado, la cantidad de tiempo de CPU que se asigna al AV, la habilitación (o no) de análisis heurístico, listado de ficheros a excluir en los análisis, mejor momento para ejecutar los análisis o la actualización de firmas, habilitación (o no) del análisis en tiempo real. En el último caso, cuando una aplicación de control accede a datos del histórico, el tráfico generado se traduce en un escaneo intensivo, que consume recursos y reduce sustancialmente el rendimiento del sistema. En la siguiente imagen, extraída de un interesante estudio sobre el uso de AV en sistemas de control [5], podemos ver el impacto en un sistema HMI de una actualización en las definiciones de virus.


http://1.bp.blogspot.com/_QUsiOTimAd...+Control+1.png

Por otro lado, parece que existen indicios suficientes como para pensar que potenciales atacantes se han infiltrado ya en muchas infraestructuras críticas (IC), así lo puso de manifiesto Jason Larson, un investigador del INL, hace poco más de una semana en la conferencia FIRST [6]. Por lo visto, se encuentran actualmente monitorizando y estudiando el proceso que se controla en las IC comprometidas, esperando a la mejor oportunidad para realizar un ataque, ya sea a través de exploits lanzados manualmente o a través de la propagación de malware.

Ante este panorama, parece lógico que deberíamos disponer ya de otros sistemas alternativos a los antivirus. Siempre que estos sistemas se han puesto en entredicho, ha surgido como alternativa eficaz el uso de listas blancas de aplicaciones; eficaz sí, aunque no siempre eficiente. A grandes rasgos, el concepto de listas blancas de aplicaciones hace referencia a la habilidad de garantizar que solo se ejecuten aquellas aplicaciones que sean seguras y hayan sido aprobadas por la autoridad competente dentro de una compañía. Las listas blancas tienen muchas ventajas, y realmente pueden ser muy eficaces a la hora de controlar la propagación de malware y la ejecución de exploits. Así, permiten evitar ataques zero-day, evitan la infección de ejecutables, impiden la ejecución de troyanos, reduce la necesidad de aplicar parches de seguridad, etc. No obstante, pueden llegar a ser un quebradero de cabeza para el administrador de sistemas de la empresa. Las listas blancas de aplicaciones presuponen realizar un inventario exhaustivo de aplicaciones permitidas, muchas veces clasificadas por área o incluso por máquina y/o tipo de usuario que hace uso de la misma. Además, imponen en muchos casos barreras a la productividad y a la libertad de los usuarios, con el consecuente enfado de estos. A quién no le ha tocado bajarse una aplicación freeware para editar rápidamente una imagen para una presentación, o un “recuperador” de contraseñas para acceder a un documento Word protegido por un compañero que ya no está en la empresa. Se trata de aplicaciones que usas una vez, o que quizás no uses nunca. Esto dependerá de los imponderables de tu trabajo diario y de la forma que tengas de enfrentarte a ellos. Un sistema de listas blancas de aplicaciones puede ser eficaz desde el punto de vista de la seguridad, pero perjudicar la eficiencia del usuario final en su trabajo diario.

Y sin embargo, después de esta reflexión, pueden ser una buena solución para los sistemas de control y ahora os diré por qué.

Existen algunas ventajas evidentes para los sistemas de control en el uso de whitelisting de aplicaciones respecto a la instalación de sistemas AV. Básicamente son dos. Primero, se evitan los problemas de limitación en los recursos hardware de los servidores/remotas. Ya no es necesario analizar cada aplicación que se ejecuta en tiempo real en busca de firmas o patrones de software malicioso y se reduce por tanto el riesgo de que las aplicaciones de control no puedan funcionar correctamente. Segundo, se evitan el complicado y tedioso proceso de integración del AV con el sistema de control [5]: análisis del rendimiento base del sistema, valoración del impacto, y parametrización/adaptación del mismo.

Aparte de las ventajas anteriores existen otras que también merece la pena comentar. El whitelisting de aplicaciones permite reducir el número de parches necesarios, lo cual se traduce en un menor número de interrupciones del servicio, básico en estos sistemas que priman la disponibilidad. Conviene no olvidar que la instalación de cualquier parche en un sistema de control ha de ser programada y supervisada, lo cual supone un esfuerzo y una movilización de recursos, que en algunos casos puede ser importante. Una segunda derivada de la reducción en el número de parches a instalar, es que se puede extender la vida útil de las aplicaciones y sistemas operativos para los que el fabricante deja de ofrecer soporte. Esto resulta especialmente interesante en el caso de muchas instalaciones de control actuales, que utilizan sistemas operativos obsoletos (por ejemplo Windows 95), y versiones de aplicaciones SCADA antiguas. En muchos casos el whitelisting de aplicaciones cubre también archivos de configuración u otros archivos no necesariamente ejecutables. Así, es posible controlar que los programas de control y supervisión de las remotas o del propio SCADA no sufran modificaciones en su código, garantizándose así la integridad y autenticidad de los mismos.

Quizás, la principal razón por la que las listas blancas de aplicaciones sí que pueden llegar a triunfar en los sistemas de control, es que estos sistemas son realmente estáticos, al contrario de lo que ocurre con los equipos de usuarios en cualquier oficina. Las aplicaciones que van a utilizarse en la instalación son claras y fijas, sujetas a mínimas variaciones (alguna actualización de vez en cuando). Siempre tendremos un sistema SCADA, software HMI, un entorno fijo para el desarrollo de aplicaciones de control en las estaciones de ingeniería, drivers de comunicaciones específicos para nuestra instalación, un motor de base de datos concreto para el servidor histórico, etc.

Finalmente, y antes de terminar voy a realizar un breve resumen de las principales características y funcionalidades deseables en un sistema de listas blancas de aplicaciones:

• Identificación de binarios: nombre, ruta, hash (SHA-1), tamaño, …
• Servicio de kernel que realiza comprobaciones antes de la carga en memoria del ejecutable.
• Interceptación de carga de dlls asociadas con el ejecutable.
• Creación automática de la lista blanca inicial: escaneo de unidades en busca de ejecutables.
• Diferenciación entre misma aplicación en distintas máquinas: hashes diferentes para notepad.exe en dos PCs distintos.
• Gestión centralizada de listas: creación y modificación de las listas desde una estación central.
• Administración de listas para grupos de equipos según área o propósito: lista blanca de aplicaciones para las estaciones de ingeniería.
• Listas blancas de proveedores de software para aplicaciones firmadas digitalmente por éstos: no bloqueo de la instalación de un nuevo motor de base de datos, cuyos instaladores están firmados digitalmente por un proveedor de confianza.

A día de hoy existen ya varias soluciones de listas blancas para sistemas de control. Para quienes hayáis tenido la oportunidad de evaluarlas, ¿qué pensáis? ¿Creéis que están suficientemente maduras?

Elyoenai Egozcue,
S21sec labs


Bibliografía:

[1] http://blog.s21sec.com/2008/08/particularidades-de-los-entornos-scada.html
[2] http://techbuddha.wordpress.com/2006/12/01/anti-virus-is-dead/
[3] http://news.cnet.com/8301-10784_3-9712875-7.html
[4] http://www.networkworld.com/news/2007/040507-desktop-antivirus-dead.html
[5] Guidance and Performance Impact Testing to Support the use of Antivirus Software on SCADA and Industrial Control Systems. ISA EXPO 2005, Chicago, IL, October 25-27, 2005
[6] http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1515123,00.html?track=sy160

Fuente: http://blog.s21sec.com/2010/06/whitelisting-en-sistemas-de-control.html