PCI DSS 11.6.1 explicado: detección de cambios y manipulación en las páginas de pago

Qué dice el requisito, en palabras sencillas

Esto es una paráfrasis; la redacción exacta está en PCI DSS v4.0.1, en la biblioteca de documentos del PCI SSC. El requisito 11.6.1 pide un mecanismo que haga tres cosas:

1. Avisar al personal de toda modificación no autorizada de las cabeceras HTTP y del contenido de las páginas de pago. Esto incluye indicadores de compromiso, cambios, adiciones y eliminaciones.
2. Evaluar lo que recibe el navegador del consumidor. Las cabeceras y las páginas de pago se evalúan tal como las recibe el navegador del consumidor, no como existen en su repositorio de código o en el servidor.
3. Ejecutarse con una periodicidad: al menos una vez cada siete días, o periódicamente con la frecuencia definida en el análisis de riesgos específico de la entidad, realizado conforme al requisito 12.3.1.

Mientras el requisito 6.4.3 define qué se permite en la página, el 11.6.1 advierte cuando la página deja de coincidir. Para el contexto, vea por qué el PCI SSC creó estos requisitos.

Por qué importa «tal como lo recibe el navegador del consumidor»

Una página puede cambiar entre su servidor y el cliente: una red de distribución de contenido (CDN), un gestor de etiquetas, un script de terceros o un complemento comprometido pueden añadir o alterar código por el camino o en tiempo de ejecución. Una revisión del repositorio o del servidor de origen pasaría por alto todo eso. Evaluar lo que recibe el navegador es la única vista que incluye todo lo que ejecutará el navegador del cliente. La misma lógica se aplica a las cabeceras HTTP como la Política de Seguridad de Contenido, que un cambio en un proxy, en una CDN o en la configuración del servidor puede eliminar o debilitar. Vea cabeceras de seguridad HTTP para páginas de pago.

Cumplir el requisito en la práctica

Enfoques para el mecanismo

El estándar no prescribe una herramienta. Los enfoques que se comentan en la orientación del sector incluyen:

• Monitoreo sintético externo: un navegador real visita las páginas de pago desde fuera de su red y registra los scripts, el contenido y las cabeceras que recibe.
• Un script incrustado en la página que informa de lo que se ejecuta en los navegadores de los visitantes reales.
• Una función de proxy inverso o de CDN que vigila el contenido que pasa por ella.

Cada uno tiene puntos fuertes y límites. Un script incrustado se ejecuta en el mismo lugar que el de un atacante; el monitoreo externo ve lo que ve su propio navegador y puede no reproducir un script dirigido solo a ciertos visitantes; un proxy ve el tráfico que pasa por él, pero no lo que hacen otros scripts dentro del navegador. Esté preparado para explicar a su evaluador cómo su enfoque, o su combinación de enfoques, cumple la intención.

Frecuencia y análisis de riesgos específico

Lo semanal es la referencia mínima. Si elige otra frecuencia, el requisito 12.3.1 espera un análisis de riesgos específico documentado que la respalde, y una revisión de ese análisis al menos cada doce meses. Muchas organizaciones simplemente comprueban con más frecuencia que cada semana, porque un skimmer que funciona durante una semana puede costar mucho.

Qué ocurre después de una alerta

El requisito trata de avisar al personal, así que alguien debe estar designado, ser notificado y estar listo para actuar. Decida de antemano cómo se clasifica una alerta (¿estaba autorizado el cambio?), quién investiga, de cuánto tiempo dispone y cómo se registra. Vea cómo detectar la manipulación del lado del cliente para un proceso neutral respecto de los proveedores.

Evidencia que conservar

• una descripción del mecanismo y de lo que evalúa (cabeceras y contenido de las páginas de pago);
• el calendario, o el análisis de riesgos que justifica otra frecuencia;
• un historial de ejecuciones, resultados y alertas;
• la investigación y la decisión registradas para cada cambio.