analíticas de terceros / seguimiento de etiquetas javascript y PCI DSS

No hay ningún requisito de PCI específico para tener Javascript de terceros en su sitio o no.

Personalmente, no consideraría que un proveedor de análisis sea un proveedor de servicios PCI bajo PCI DSS.

Sin embargo, existen requisitos para que su sitio web personalizado se desarrolle de forma segura (6.5), y para que se revise mediante evaluaciones de seguridad o se ejecute bajo la protección de un WAF (6.6).

Además, existen requisitos para los análisis de vulnerabilidad (11.2) y las pruebas de penetración externa (11.3.1).

Una biblioteca de terceros que aloje su sitio web debe estar marcada como una vulnerabilidad en uno de estos requisitos. Durante una prueba de seguridad normal, que no es de PCI, generalmente se expresará que hay una biblioteca de terceros presente y este riesgo debe revisarse para garantizar que la biblioteca sea de confianza y que el dominio en el que se aloja también sea de confianza, en caso de que sea así. Un dominio externo. Si el dominio de terceros no es de confianza, o si está comprometido, sería un riesgo para su entorno y para el cumplimiento de su PCI. Es decir, algo alojado en google.com probablemente estaría bien, pero algo alojado en otro lugar puede que no.

Durante una prueba de seguridad, esto suele ser inicialmente clasificado por un pentester como una vulnerabilidad de bajo riesgo. Sin embargo, debe ser revisado por la empresa. Si su empresa acepta este riesgo, simplemente documéntelo como tal. Si considera que es un riesgo que no puede aceptarse, debe documentar los pasos tomados para mitigar dicho riesgo. Por ejemplo, al poner el script de terceros a través de una revisión de código y luego alojar el script localmente en lugar de que se obtenga de un dominio de terceros.

PCI DSS consiste principalmente en documentar cómo ha tratado con el espíritu de cada requisito, en lugar de en una lista blanca o negra de latas y canots. Luego, si lo auditan, puede llevar el QSA a través de su proceso de decisión comercial para demostrar cómo cumple con los requisitos anteriores.

_{Descargo de responsabilidad: no soy un QSA, ni, lo que es más importante, su QSA. Solo su QSA calificado puede evaluar con precisión sus responsabilidades bajo PCI DSS, ya que tendrán un conocimiento completo de su negocio y cómo se relaciona con sus actividades de procesamiento de tarjetas.}

No soy un QSA. Debe consultar a su QSA sobre este asunto.

Estoy totalmente de acuerdo en que la entrega de javascript desde una fuente no segura como parte de las páginas que contienen datos en el alcance para PCI-DSS no debe pasar la prueba con una alerta QSA. Me gustaría ir un paso más allá y decir que otras páginas en la misma sesión no deben contener javascripts no protegidos.

Puede que sea demasiado conservador, pero iría un par de pasos más allá de eso. La inclusión de contenido del servidor o del lado del cliente de cualquier contenido no pasaría a formar parte del asesor. Tenga en cuenta que esta fuente fuera de su control puede cambiar el contenido sin que usted sepa que lo han hecho. ¿Qué mecanismo propone aplicar para probar la seguridad de ese contenido externo? Se me ocurre una amplia y fea gama de posibles ataques. ¿Con qué fiabilidad puede garantizar que sea seguro cada vez que se incluye?

Como alternativa, considere copiar el contenido a su propio servidor, verificando la seguridad y luego sirviéndolo directamente, sin cargarlo dinámicamente desde un tercero. En efecto, esto lo hace parte de su sitio y sujeto a sus procesos de control de cambios.

PCI DSS 3.1 Requisito # 12.8 estados

"¿Se mantienen e implementan políticas y procedimientos para administrar a los proveedores de servicios con los que se comparten los datos del titular de la tarjeta, o que podrían afectar la seguridad de los datos del titular de la tarjeta ..."

Al examinar si los análisis están o no dentro del alcance, tenga en cuenta los siguientes puntos:

• Los proveedores de análisis definitivamente están proporcionando un servicio y, por lo tanto, deben considerarse proveedores de servicios. La Guía de Cumplimiento de PCI refuerza esto , tomando como referencia la definición de Proveedor de Servicios de PCI:

"Entidad comercial que no es una marca de pago, directamente involucrada en el procesamiento, almacenamiento o transmisión de datos del titular de la tarjeta. Esto también incluye a las compañías que brindan servicios que controlan o podrían afectar la seguridad de los datos del titular de la tarjeta . (Fuente: www.pcisecuritystandards.org) "

• El javascript externo definitivamente tiene el potencial de afectar la seguridad de sus datos PCI. (Ver la respuesta de JaimeCastells)

Si se le pide a un QSA que revise el requisito, use su opinión. Si su nivel de PCI no requiere un QSA, debe tomar la decisión basándose en su mejor comprensión después de investigar a fondo la pregunta (y, opcionalmente, contratar a un consultor de QSA).

La principal preocupación es que tiene que confiar en Google o cualquier otro tercero que le ayude a rastrear a los usuarios. Cuando presenta PCI DSS de manera estricta, es responsable de asegurarse de que solo las entidades compatibles con PCI DSS puedan acceder a los datos del titular de la tarjeta o a cualquier información confidencial. Por lo tanto, no se permite cargar un script de un tercero que no cumpla con las normas. El cumplimiento debe ser probado por un AOC.

Sin embargo, lo que puede hacer normalmente es alojar la secuencia de comandos de seguimiento en su servidor. Lo que significa que puede evaluar una vez que el script correspondiente no esté robando datos de la tarjeta. Cuando aloja el script, tiene el control y no necesita tener un AOC. Normalmente, los datos de seguimiento reales se pasan a un tercero mediante una imagen. Por lo tanto, al controlar el script, usted controla qué datos salen de su entorno y, como tal, se conforma.