PCI DSS 6.4.3 explicado: gestión de los scripts de la página 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, disponible en la biblioteca de documentos del PCI SSC. El requisito 6.4.3 abarca todos los scripts de la página de pago que se cargan y se ejecutan en el navegador del consumidor, y tiene tres partes:

1. Autorización. Existe un método para confirmar que cada script está autorizado, es decir, que alguien con facultad para decidir ha acordado que ese script puede ejecutarse en esa página.
2. Integridad. Existe un método para asegurar la integridad de cada script, es decir, que el script que se ejecuta es el que se aprobó y no ha sido alterado.
3. Inventario y justificación. Se mantiene una lista de todos los scripts, con una razón comercial o técnica escrita de por qué es necesario cada uno.

Está en la parte de PCI DSS sobre el desarrollo y el mantenimiento de sistemas y software seguros, y es el complemento del requisito 11.6.1, que detecta los cambios no autorizados. Para saber por qué existen ambos, vea por qué los creó el PCI SSC.

Qué scripts y qué páginas

El requisito no se limita a los scripts de terceros. Los scripts que usted escribió, las bibliotecas que aloja, los scripts cargados por un gestor de etiquetas y los scripts cargados por otros scripts son todos scripts que se ejecutan en el navegador en la página de pago. PCI DSS v4.0.1 añadió además una nota que indica que el requisito se aplica a los scripts de la página web de un comercio que incluye el formulario de pago incrustado de un proveedor de pagos, por ejemplo en un iframe. Si se aplica a su entorno, y cómo, depende de cómo acepte pagos; vea 6.4.3 y 11.6.1 para SAQ A, SAQ A-EP y SAQ D, y confírmelo con su adquirente o evaluador.

Formas de cumplir cada parte

PCI DSS deja el método a su elección, y un QSA decide si lo que usted hace cumple la intención. Los enfoques de uso común incluyen:

Autorización

• Un flujo de aprobación documentado: quién puede aprobar un script, qué información necesita y cómo se registra y se fecha la decisión.
• Un control técnico que haga cumplir la lista aprobada, por ejemplo una Política de Seguridad de Contenido (CSP) que permita solo orígenes de scripts aprobados.

Integridad

• Integridad de Subrecursos (SRI) para scripts externos estáticos, de modo que el navegador compare el archivo con un hash aprobado.
• Alojar copias aprobadas usted mismo y comparar periódicamente sus hashes con los valores aprobados.
• Hashes o nonces de CSP para scripts en línea.
• Un monitoreo que compare el contenido que recibe el navegador con una línea base aprobada, lo que también respalda el 11.6.1.

Ninguna técnica cubre todos los casos. Un hash sobre un archivo estático no sirve con un script que un proveedor cambia cada semana, y una lista de orígenes permitidos de CSP no dice si el archivo de un host permitido ha sido alterado. Por eso muchas organizaciones combinan métodos.

Inventario y justificación

El inventario debe ser real, es decir, construido a partir de lo que carga el navegador y no de lo que dice el código fuente. Cada entrada necesita una razón que un revisor pueda entender y comprobar. Vea cómo crear un inventario de scripts de la página de pago.

Qué suele querer ver un evaluador

Los evaluadores difieren, así que pregunte al suyo, pero es habitual este tipo de evidencia:

• el inventario actual de cada página de pago, con responsable, finalidad y justificación de cada script;
• registros de quién autorizó cada script y cuándo, y de cómo se aprueba un cambio;
• una descripción del método de integridad y evidencia de que funciona, como hashes, archivos de política y resultados de monitoreo;
• evidencia de que el inventario coincide con lo que realmente cargan las páginas y de que se revisa y se actualiza, no se produce una sola vez;
• cómo se tratan los scripts nuevos o modificados entre revisiones.

Errores comunes

• Un inventario hecho una sola vez a partir del código fuente, sin los scripts que añade un gestor de etiquetas o que cargan otros scripts.
• Justificaciones como «marketing» o «petición del proveedor» que no dicen por qué el script es necesario en una página de pago.
• Contar solo la página principal del pago y olvidar los demás pasos del flujo.
• Tratar el iframe de un proveedor de pagos como si eliminara todas las obligaciones sobre la página que lo rodea.