En los ambientes de seguridad, cada cierto tiempo, aparecen “nuevas soluciones” que prometen y parecen ser la “bala de plata” para todos los problemas existentes.

Este es el caso de las herramientas de whitelisting o listas blancas que contienen nombres de aplicaciones, archivos o sitios legítimos y “confiables”.

En principio se podría insinuar que si una compañía aplica el filtrado a través de estas listas blancas, sería imposible que una aplicación dañina sea ejecutada en el sistema, ya que la misma no aparecería como válida.

Por ejemplo, Windows XP incorporó su tecnología Software Restriction Policies (SRP) para evitar que los usuarios ejecutaran aplicaciones no autorizadas o dañinas como un malware.

Posteriormente Windows 7 mejoró esta tecnología con la incorporación de AppLocker,  un “control que ayuda a evitar la ejecución de aplicaciones no deseadas y desconocidas en la red de una organización”.

Esta herramienta puede ser utilizada por cualquier usuario o en una red de una organización para filtrar (bloquear o permitir) la ejecución de aplicaciones de tres formas posibles, las cuales también tienen desventajas asociadas:

• Identificar una carpeta o un archivo determinado: esta regla tiene la dificultad que si alguien aloja un archivo dañino en una carpeta definida como “confiable”, se permitiría la ejecución de dicho archivo, sin ninguna otra validación posterior.
• Identificar un archivo a través de su hash: esta regla es prácticamente imposible de aplicar en ambientes dinámicos en donde los archivos y aplicaciones cambian en forma continua o en el caso de parchear una aplicación vulnerable.
• Validar las aplicaciones a través de su firma digital utilizando el certificado generado por  su fabricante. Esta aproximación si bien es la más confiable, tiene dos desventajas conocidas: por un lado, se podría evitar la verificación del certificado a través del uso de un exploit  y, por otro lado, la opción más evidente, es el firmado de aplicaciones dañinas con certificados validos fraudulentos o previamente robados al fabricante, aunque Microsoft advierte de certificados fraudulentos.

De todos modos, las mayores dificultades del whitelisting no se basan en lo expresado anteriormente sino en que, así como es imposible conocer todos los programas dañinos, es imposible generar o tener un listado de las millones de aplicaciones legítimas existentes y las miles que se crean o modifican diariamente, sumado eso a lo difícil de la administración y mantenimiento de la lista.

Por lo expresado, esta aproximación podría ser válida y aconsejable en un escenario estático, acotado, donde la cantidad de aplicaciones sea reducida y no cambie en el tiempo.

Finalmente, ¿cómo hacen las compañías para agregar aplicaciones a una whitelist?

Utilizan muchos software antivirus. Ya que la única forma de saber que un programa es realmente benigno es acceder al código fuente del mismo, observarlo y verificarlo por completo para ver qué es lo que está haciendo realmente, procedimiento que nadie realiza. Es por ello que estas empresas recaen en confiar en la fuente y terminan utilizando software antivirus.

A simple vista, el whitelisting aparece como “la" solución a los problemas de malware o aplicaciones dañinas pero, si se analiza en profundidad, es fácil observar las dificultades inherentes a su diseño, desarrollo y mantenimiento.

Un modelo de protección adecuado debería contemplar la seguridad en profundidad de modo tal que cada control implementado sea utilizado para varios objetivos y, si uno de ellos es sobrepasado, sea otro control el que tome su lugar.

Las whitelisting pueden ser utilizadas pero en conjunto con un firewall de perímetro, un firewall de aplicaciones, un IDS, un antivirus y cualquier otra herramienta cuyo fin sea evitar la ejecución de aplicaciones dañinas. Las balas de plata no existen y por lo tanto, la seguridad no debe basarse en ellas.

Cristian Borghello es consultor externo de seguridad de ZMA