Cómo elegir una herramienta para el PCI DSS 6.4.3 y 11.6.1

El 10 de marzo de 2025, el PCI Security Standards Council publicó una guía dedicada a los requisitos 6.4.3 y 11.6.1 del PCI DSS, tres semanas antes de que ambos pasaran a ser obligatorios. Desde entonces, el mercado se llenó de herramientas que prometen resolver los dos requisitos, y quien tiene que elegir una recibe propuestas que no se pueden comparar entre sí: una vigila scripts, otra visita la página desde afuera, otra promete resolverlo todo en la CDN. Esta guía ordena esas opciones y las preguntas que conviene hacer antes de firmar.

Respuesta directa

Elija por la cobertura de los dos requisitos a la vez: inventario y autorización de scripts (6.4.3) y detección de cambios con alerta (11.6.1). Prefiera herramientas que observen sesiones reales de compradores, que cubran todos los medios de pago de su página (tarjeta de crédito, tarjeta de débito, pagos instantáneos, billeteras) y que entreguen un informe listo para el QSA sin obligarle a cambiar de infraestructura.

Por qué existe el requisito

El ataque que motivó ambos requisitos ocurre en el navegador del comprador. Un script entra en la página de pago por un plugin comprometido, un proveedor externo vulnerado o un cambio directo en el servidor. Ese script copia los datos de la tarjeta mientras se escriben y los envía al delincuente. La página sigue funcionando, el pedido se aprueba y nadie se da cuenta durante semanas.

El 6.4.3 ataca la causa: la empresa debe saber qué scripts cargan en la página de pago, quién autorizó cada uno y por qué. El 11.6.1 ataca el efecto: la empresa necesita un mecanismo que detecte cambios no autorizados en el contenido de la página y en los encabezados de seguridad, y que avise cuando ocurran.

Los requisitos hablan de tarjetas, pero la misma técnica cambia un código QR, una referencia de pago o la dirección de una billetera. Una herramienta que solo mira el campo de la tarjeta deja la mitad del checkout sin vigilancia.

Los cuatro enfoques del mercado

1. Agente de scripts en la página

Un pequeño código instalado en la tienda se ejecuta en el navegador de cada comprador, registra qué scripts cargaron y lo reporta a un panel. Es el enfoque más cercano a lo que describe el requisito, porque ve la sesión real, en el dispositivo y la red del propio comprador.

El límite está en lo que el agente verifica. Muchos solo listan scripts y los comparan con la lista aprobada. Si un script autorizado se altera en su origen, o si el cambio ocurre en el contenido y no en un script, hace falta una segunda capa.

2. Monitor externo con visitas simuladas

Un robot del proveedor abre su página de pago a intervalos regulares, registra lo que cargó y lo compara con la visita anterior. No se instala nada en la tienda y la configuración toma minutos.

El punto débil es la muestra. El robot ve lo que el robot ve: una dirección IP conocida, un navegador estándar, una sesión sin carrito ni usuario. Los ataques que solo se activan para compradores de cierta región, en celular, o después de completar la dirección pasan desapercibidos. Y entre una visita y otra, la página queda sin vigilancia.

3. Política CSP desde la CDN o el firewall de aplicaciones

La política de seguridad de contenido (CSP) es un encabezado que le dice al navegador desde qué orígenes puede cargar scripts la página. Algunos proveedores de CDN y de firewall ofrecen generar y vigilar esa política como producto.

Funciona bien para bloquear orígenes desconocidos. No cubre cambios dentro de un script ya permitido, exige que la tienda pase a usar esa CDN o ese firewall, y la política necesita mantenimiento cada vez que se agrega un proveedor al checkout. Para el 6.4.3, la CSP ayuda en la parte de integridad, pero no sustituye el inventario con justificaciones.

4. Verificación del pago en sí

En lugar de preguntar "qué scripts cargaron", este enfoque pregunta "¿lo que ve el comprador es lo que emitió el servidor?". El código QR, la clave del pago instantáneo, la referencia de pago, la dirección de la billetera y el destino del formulario de tarjeta se comparan con lo que la tienda generó. Si hay diferencia, la herramienta bloquea y alerta.

La ventaja es cubrir el resultado del ataque sin importar cómo entró en la página. El límite es que, por sí sola, no cumple el 6.4.3: el inventario y la autorización de scripts tienen que venir junto.

Siete preguntas para hacerle a cualquier proveedor

1. ¿Qué medios de pago cubre? Pida la lista: tarjeta de crédito, tarjeta de débito, pagos instantáneos, billeteras digitales, stablecoins. Una respuesta genérica como "toda la página" suele significar "solo scripts".
2. ¿Observa sesiones reales o simuladas? Las sesiones reales muestran lo que vio cada comprador. Las simuladas muestran lo que vio el robot.
3. ¿Bloquea automáticamente o solo alerta? El 11.6.1 exige alerta. Bloquear es lo que evita la pérdida. Pregunte qué pasa en los minutos entre la alerta y la acción de su equipo.
4. ¿Exige que use la CDN o el firewall del proveedor? Cambiar de infraestructura por un requisito suele costar más que la herramienta.
5. ¿Qué informe entrega para el QSA? Pida un ejemplo real: inventario con responsable y justificación, historial de cambios, alertas emitidas y atendidas.
6. ¿Qué pasa entre una evaluación y la siguiente? El requisito acepta verificación semanal, pero el ataque no espera. Pregunte cuál es el intervalo real de detección.
7. ¿Quién opera la herramienta en el día a día? Cuántas horas al mes dedicará su equipo a aprobar scripts, revisar alertas y mantener listas. Esa cuenta define el costo verdadero.

Errores comunes

• Comprar un inventario y creer que terminó. El 6.4.3 pide inventario; el 11.6.1 pide detección y alerta. Son entregas distintas.
• Tratar el requisito como un asunto solo de tarjetas. El mismo script que copia tarjetas cambia códigos QR. Dejar fuera los pagos instantáneos deja la puerta abierta.
• Planear la revisión semanal y descubrir el ataque al sexto día. El intervalo del análisis de riesgo es el mínimo aceptable, no la meta.
• Confundir antifraude con integridad de la página. El antifraude evalúa si el comprador es legítimo. Los requisitos tratan de si la página es legítima.
• Aceptar capturas de pantalla y hojas de cálculo como evidencia. El QSA quiere historial, con fechas, responsables y justificaciones.
• Elegir por el precio del plan y olvidar el costo de operación. Una herramienta barata que exige un analista dedicado termina saliendo cara.

Dónde encaja Proteside

Proteside entra en la página con una línea de código, sin cambiar de CDN ni de plataforma. En cada sesión real de compra, compara el código QR, la clave del pago instantáneo, la referencia de pago y la dirección de la billetera con lo que emitió el servidor de la tienda, y bloquea el cambio antes de que el comprador pague. Al mismo tiempo, mantiene el inventario de scripts de la página de pago, registra autorizaciones y justificaciones y exporta la evidencia de los requisitos 6.4.3 y 11.6.1 con historial.

Para ver cómo se compara cada enfoque punto por punto, con hechos públicos y fecha de consulta, visite la página de comparativos.