candado

El estándar PCI DSS define una serie de controles físicos, lógicos y administrativos para la protección de los datos de tarjetas de pago que son transmitidos, procesados y/o almacenados.  La mayoría de veces estos controles se pueden implementar sin mayores traumatismos dentro de la organización, pero otras veces (ya sea por limitantes técnicas o administrativas) es muy difícil proceder con el despliegue de un control de acuerdo con las indicaciones del estándar. Por ejemplo:

  • Una organización tiene dentro de su infraestructura de comunicaciones una gran cantidad de equipos activos de red con un firmware que no permite cifrar la transferencia de datos de autenticación administrativos y por ello se sigue empleando un protocolo inseguro (telnet), incumpliendo los requerimientos 1.1.5, 2.2.2, 2.3 y 8.4. Sin embargo, el solo hecho de realizar un cambio de todo este parque de equipos implica una inversión económica bastante elevada que se sale del presupuesto técnico asignado.
  • Una empresa tiene una aplicación crítica para su negocio que únicamente se puede ejecutar en una plataforma operativa que ya no es soportada, incumpliendo con el requerimiento 6.1.  Esta aplicación no puede ser migrada en el corto plazo ya que el fabricante tiene previsto el proceso de portabilidad a una nueva plataforma el siguiente año.
  • Una empresa cuenta con una arquitectura centralizada cliente/servidor en la cual se tiene un servidor mainframe que desempeña tareas para diferentes áreas y procesa y almacena información con diferentes niveles de confidencialidad, con lo cual “aislar” este entorno no es viable en el mediano plazo, incumpliendo con los requerimientos 1.3.7 y 2.2.1.
  • El software proporcionado por un fabricante en particular no cumple con los controles de gestión de contraseñas de PCI DSS (incumpliendo el requerimiento 2.2 y 8.5) y las únicas alternativas disponibles no soportan el sistema operativo donde ese software está instalado.
  • Un sistema operativo presente en la red no permite renombrar ni deshabilitar la cuenta de administrador, incumpliendo con los requerimientos 2.1, 8.1 y 8.5.8

Frente a esto, ¿cómo proceder en estos casos?

A pesar que existe un incumplimiento de uno o varios requerimientos, es posible cumplir con el estándar si se cuenta con un argumento justificado y documentado que describa la limitante técnica o administrativa (a ser validado por un QSA) haciendo uso de “controles compensatorios” (o “controles de compensación” como se traduce en el estándar PCI DSS en español). Un “control compensatorio” es un control que a pesar que no está descrito explícitamente en el estándar permite proporcionar un nivel de seguridad similar (o superior) al del control original y debe ser empleado bajo circunstancias excepcionales. Está descrito en el Anexo B y cuenta con una hoja de trabajo de reporte (Anexo C) en el documento del estándar.

Anexo B de PCI DSS: Hoja de trabajo de controles de compensación

Los controles compensatorios – para poder ser aceptados como tal – deben cumplir con los siguientes criterios:

  1. Cumplir con el propósito y el rigor del requisito original de PCI DSS.
  2. Proporcionar un nivel similar de defensa, tal como el requisito original de PCI DSS, de manera que el control compensatorio compense el riesgo para el cual se diseñó el requisito original de PCI DSS.
  3. Ir más allá (“above and beyond”) del simple cumplimiento del requisito (El simple cumplimiento con otros requisitos de PCI DSS no constituye un control de compensación).

Para poder utilizar un control compensatorio es importante tener presente tres elementos claves:

  1. Un control de PCI DSS no puede ser considerado un control compensatorio si ya fue requisito para el elemento en revisión.
  2. Un control de PCI DSS se puede considerar control compensatorio si se requiere para otro requerimiento pero no es requisito para el elemento en revisión.
  3. Los controles existentes de PCI DSS se pueden combinar con nuevos controles para convertirse en un control compensatorio.

A continuación se describen una serie de controles que pueden ser empleados como controles compensatorios por una empresa (ya sea solos o combinados entre sí o con otros controles del estándar), en función de sus necesidades y posterior a un análisis coste/beneficio. Se hace hincapié en la necesidad de soportar estas decisiones en el criterio de un QSA y se presentan solamente a manera de ejemplo.

  • Uso de herramientas de DLP (Data Loss Prevention)
  • Uso de autenticación de dos factores dentro  del CDE (Cardholder Data Environment): Solamente es requerido para accesos remotos (Req. 8.3)
  • Uso de Firewall Personal en equipos dentro del CDE: Solamente es requerido para equipos móviles con conectividad directa a Internet y que acceden al CDE remotamente (Req. 1.4)
  • Uso de controles de  acceso a la red (Network Access Control, NAC)
  • Uso de controles de ejecución de programas basados en listas blancas (Whitelist)
  • Uso de control de acceso y filtrado a nivel de dirección MAC (Media Access Control)
  • Uso de controles de filtrado de URL
  • Uso de grabación de sesiones de usuario (pantalla) con tecnologías como Screen Session Recording or User Activity Monitoring
  • Uso de herramientas que permitan la elevación de privilegios generando registros de eventos de la sesión (como “SU” y “SUDO” en Unix)
  • Uso de túneles VPN IPSEC/SSL dentro del CDE: Solamente es requerido cuando existe transmisión de datos de tarjetas en redes públicas abiertas (Req. 41)

Entre otros.

¿Conoce de más controles compensatorios que se puedan aplicar? Los comentarios (como siempre) son bienvenidos.