Captura

Para entrar en contexto, imaginemos la siguiente situación: en un evento público se quiere implementar un sistema de control de acceso para limitar el ingreso de personas que puedan causar disturbios y afectar la seguridad de los asistentes. Para ello, se han definido tres estrategias diferentes:

  1. Emplear una “Lista Negra” (Blacklist), en la cual se tienen los nombres de todos los individuos que previamente han sido reseñados por su mal comportamiento. Esta lista debe estar lo más actualizada posible y está basada en un histórico de acciones, por lo cual se convierte en un control reactivo. La política será Se permitirá el ingreso de todos los asistentes EXCEPTO de los que se encuentren en la lista negra(Accept-all).
    • Ventajas: Si la cantidad de asistentes es muy amplia, el uso de una lista negra optimizará el proceso de ingreso, ya que por lo general son más los asistentes sin reseña que aquellos reseñados.
    • Desventajas: La lista negra debe estar siempre actualizada, ya que de no estarlo se puede permitir el acceso de un asistente no deseado. Así mismo, es recomendable que la lista negra sea actualizada empleando diferentes fuentes, como por ejemplo la policía u otros entes de investigación. Por otro lado, entre más grande y detallada sea la lista negra más complejo será el proceso de identificación y por ende el tiempo de entrada será mayor.
  2. Emplear una “Lista Blanca” (Whitelist),  en la cual se listan los nombres de todas las personas que no han sido reseñadas y que opcionalmente cuentan con una “recomendación” de un tercero de confianza. La política será “Se permitirá ÚNICAMENTE el ingreso de aquellos que se encuentren en la lista blanca y se DENEGARÁ el resto(Deny-all).
    • Ventajas: Si la cantidad de asistentes es limitada, el uso de una lista blanca optimizará el proceso de ingreso. Se denegará a cualquiera que no esté en la lista.
    • Desventajas: La lista debe estar desarrollada de una forma muy completa, ya que si hay un error en algún dato se puede denegar el acceso a un asistente válido (falso positivo). Así mismo, si hay cambios continuos en la lista de asistentes a ser admitidos se pueden presentar errores de acceso, por lo que la lista debe ser actualizada cada vez que haya un cambio.
  3. Permitir el acceso de cualquier persona (sin necesidad de listas) y monitorizar de forma continua su comportamiento durante el evento. Si algún asistente se comporta de forma contraria a las reglas establecidas, se procederá con su retiro del local y el ingreso de su nombre a la “Lista Negra”
    • Ventajas: No hay tiempos de espera en el ingreso, ya que no existe ninguna validación previa.
    • Desventajas: Puede ser bastante molesto para los asistentes que los estén monitorizando de forma continua. Así mismo, pueden existir problemas entre el momento en el que se presenta un incidente y se detecta al sospechoso, con lo cual la organización del evento deberá asumir cualquier daño generado durante este umbral de tiempo. Por otro lado, si la monitorización no es correcta, se podrían sacar del evento a asistentes “inocentes”.

Bajo estas circunstancias, ¿cuál podría ser la mejor alternativa a emplear en este escenario? La respuesta es: depende. En función de las necesidades, disponibilidad de personal, ubicación física, presupuesto, etc. se deberá buscar la alternativa que mejor se adapte al entorno.

Si extrapolamos el ejercicio mental anterior al campo de la seguridad de la información, podemos rápidamente concluir que tanto la “lista negra” (Blacklist) como la “lista blanca” (Whitelist) son ejemplos claros de ACL (Access Control List), que podemos encontrar en múltiples tecnologías y con diferentes nombres:

  • Listas negras: Ampliamente usadas en tecnologías como control de spam, sistemas de detección de intrusos, soluciones de Data Loss Prevention (DLP) y antivirus (comúnmente llamadas “firmas” o “vacunas”)
  • Listas blancas: Empleadas en reglas de firewall, controles de acceso discrecional (DAC), controles de acceso basado en roles (RBAC) y sistemas de autenticación, entre otros.

Así mismo, la tercera alternativa (aquella basada en comportamiento) la podemos encontrar bajo el nombre de “Análisis Heurístico“, presente en sistemas de detección de intrusos y antivirus como herramienta complementaria al uso de listas negras.

Es importante tener en cuenta que el uso de estas listas no es excluyente. Al contrario, son controles complementarios. El problema de su implementación conjunta radica muchas veces en la penalización en el desempeño del equipo y en la complejidad de configuración.

Los antivirus y PCI DSS

your-computer-might-be-at-riskLos antivirus tradicionales por lo general hacen uso de listas negras (blacklist) y algoritmos heurísticos para la detección de código malicioso.  Este tipo de tecnología ha sido bastante útil durante los últimos años, sin embargo – y debido al rápido desarrollo, diversificación y distribución de malware actualmente – es necesario contemplar otras estrategias que soporten y complementen dichas soluciones.

Un antivirus, para que pueda ofrecer un nivel de seguridad  óptimo, requiere (entre otros):

  • Actualización constante de las firmas de virus: La organización se vuelve vulnerable en el umbral de tiempo entre que el fabricante libera la actualización y se descarga y despliega en los equipos de la red. Por ello, se requiere definir una estrategia específica para la monitorización, descarga y despliegue de actualizaciones incluyendo el consumo de ancho de banda requerido.
  • Desempeño: Debido a que día tras día las firmas de antivirus son mas grandes y complejas, el uso de recursos por parte de la solución antivirus debe ser planificado con detalle. Este tipo de soluciones mal dimensionadas puede penalizar el desempeño en equipos con pocos recursos de hardware.
  • Plataformas soportadas: Todos los sistemas comúnmente afectados por software malicioso deben tener instalada una solución antivirus. Sin embargo, algunas plataformas antiguas o software sin soporte (pero operativo) muchas veces no son soportados, quedando como “islas” de riesgo en la organización.

El requerimiento 5 de PCI DSS (“Utilice y actualice regularmente el software o los programas antivirus”) define los controles necesarios para la protección contra código malicioso en sistemas comúnmente afectados por este software. Se requiere la instalación de una solución antivirus que sea capaz de detectar, remover y proteger contra todos los tipos conocidos de software malicioso (es decir: basado en firmas), mantener dicha solución en ejecución, actualizada, configurada para ejecutar revisiones periódicas y generando registros de eventos.

Sin embargo, en muchos entornos que procesan, almacenan o transmiten datos de tarjetas de pago se encuentran sistemas con limitaciones en términos de hardware, sistemas operativos no soportados por el fabricante o por la solución antivirus, aplicaciones heredadas y sin soporte, equipos remotos conectados a través de líneas con ancho de banda limitado,  etc. en los cuales es prácticamente imposible desplegar una solución antivirus y – por ende – se incumple con el requerimiento 5. Algunos ejemplos de este tipo de equipos son: cajeros automáticos (ATM), quioscos de autoservicio, estaciones remotas de cobro por líneas telefónicas, terminales de punto de venta (TPV/POS), etc.

Las listas blancas (Whitelist) como alternativa de cumplimiento al requerimiento 5 de PCI DSS

En vista de estas limitaciones, el PCI SSC publico la FAQ 1051 en la cual se aceptan otros controles diferentes a aquellos basados en listas negras (o basados en firmas) para el cumplimiento del requerimiento 5 en forma de controles compensatorios:

Is application whitelisting a suitable compensating control to meet Requirement 5?
The Council is looking for equivalent controls that address malware and all types of threats referenced in Requirement 5, which are often found in traditional anti-virus solutions. If another type of solution (application whitelisting, for example) addresses the identical threats with a different methodology than a signature-based approach, it may still be acceptable to meet the requirement.

Con esto, se abría la puerta al uso de otras tecnologías como las basadas en listas blancas de aplicaciones (Application Whitelisting) que pueden ser usadas como control compensatorio cuando existe una justificación administrativa o técnica que impida el uso de una solución antivirus o cuando se tienen sistemas operativos no soportados por el fabricante para cumplir con el requerimiento 6.1 (ver FAQ 1130 “Are operating systems that are no longer supported by the vendor non-compliant with the PCI DSS?”).  Este tipo de soluciones tienen las siguientes características:

  • Mantiene un listado de aplicaciones específicas autorizadas que se pueden ejecutar en el equipo. Cualquier otra aplicación (ejecutable o librería) que no pertenezca a este listado será denegada, reforzando el criterio de “deny-all”, los controles de software autorizado descritos en el requerimiento 12.3.7 y las configuraciones de securización (hardening) del requerimiento 2.  Este listado puede estar basado en código firmado, valores de hash, rutas en ubicaciones específicas en el filesystem (paths), asociación de binarios con determinados permisos, etc.
  • Puede permitir la definición de políticas de acceso discrecional en archivos de forma más granular: El mismo concepto de lista blanca se puede implementar en el control de lectura, escritura y ejecución en archivos en el filesystem, protegiendo al sistema más allá de los controles nativos discrecionales provistos por el sistema operativo.
  • Permiten la replicación de políticas desde una imagen (“Gold Image”) a otros equipos similares en la red: Cuando se cuenta con un grupo de equipos con características de software/hardware y funcionalidades similares, se pueden definir políticas de listas blancas en una imagen y replicarlas en dicho grupo de equipos, haciendo más fácil la configuración, inclusive de forma centralizada.
  • No requiere de actualización constante: Debido a que la lista blanca cambia en función de las modificaciones que se hagan a los ejecutables o librerías por necesidades de actualización o funcionamiento, la cantidad de veces que requiere configuración y despliegue es mucho menor a la de una lista negra. De hecho, algunas soluciones de listas blancas de aplicaciones se puede configurar de forma automática cuando se reciben actualizaciones de componentes (conforme con el requerimiento 6.1 de PCI DSS).

Sin embargo, el uso de soluciones de listas blancas tiene ciertas desventajas que deben ser gestionadas de forma metodológica por el administrador para disminuir el riesgo asociado:

  • Complejidad en la definición de políticas de listas blancas: Para que la solución sea efectiva y evitar falsos positivos, se debe realizar un análisis detallado de la funcionalidad esperada del equipo, los ejecutables y librerías relacionados y sus dependencias. Un cambio mal planificado puede afectar de forma colateral un servicio requerido o dar pie a la ejecución de software no autorizado.  Así mismo, la gestión de políticas de listas blancas en un entorno con gran cantidad de equipos y tecnologías puede llegar a ser muy compleja.
  • Gestión de actualizaciones y cambios: Como se comentaba anteriormente, algunas soluciones pueden configurarse de forma dinámica, identificando aquellos componentes que han sido actualizados por una fuente confiable y agregándolos dentro de la lista blanca. Si esta labor se tiene que realizar de forma manual, puede ser un trabajo tedioso para el administrador.
  • Vulnerabilidades en software autorizado: Si un ejecutable o librería se encuentra dentro de la lista blanca y contiene una vulnerabilidad, es posible que debido a los permisos asociados dicha vulnerabilidad se pueda hacer latente.
  • Ejecución de software en memoria dinámica: Cuando un ejecutable o librería es validado contra su imagen en el disco duro, se puede comprobar su validez en una lista blanca. Sin embargo, cuando el mismo binario es ejecutado directamente en memoria, esta validación es imposible, ya que por la propia arquitectura del sistema operativo la imagen en la RAM es modificada, dejando inválidos los conceptos de comparación.
  • Protección de la lista blanca maestra y del módulo de validación: Estos dos componentes son el eje de la solución de listas blancas. Cualquier modificación o des-habilitación de estos elementos puede dejar al sistema sin una protección válida, razón por la cual se deben tomar acciones preventivas para evitar este tipo de incidentes.

Conclusión: El uso de listas blancas (o “Whitelist”) puede ser usado como una alternativa (control compensatorio) al cumplimiento del requerimiento 5 de PCI DSS en caso que se cuente con una justificación administrativa o técnica que impida el despliegue de una solución antivirus. Al igual que cualquier otra solución de seguridad, no es perfecta. Dependiendo del entorno y complejidad del ámbito donde se quiera implementar puede ser una buena alternativa, lo cual debe ser validado previamente entre el administrador y un asesor QSA.