Lista de verificación PCI DSS de seguridad del lado del cliente

Cómo usar esta lista

Los números de requisito se refieren a PCI DSS v4.0.1. Esta lista es una ayuda de estudio escrita a partir de material público del PCI SSC; no es una evaluación, y qué puntos se aplican a usted depende de cómo acepte pagos y de lo que decidan su adquirente o su evaluador. Lea primero el artículo sobre SAQ A, SAQ A-EP y SAQ D si no está seguro.

1. Alcance: conozca sus páginas de pago

• Haga una lista de cada página y paso de su flujo donde se introducen datos de tarjeta o donde se muestra un formulario de pago incrustado.
• Anote cómo acepta pagos cada página: redirección, iframe o formulario incrustado, o envío directo.
• Anote qué SAQ o tipo de informe espera su adquirente, y el razonamiento.
• Incluya las páginas detrás de un inicio de sesión, los pagos de varios pasos y las variantes que solo ven algunos visitantes (por ejemplo, según el país o el dispositivo).

2. Requisito 6.4.3: gestionar los scripts de la página de pago

• Un inventario de cada script que se ejecuta en cada página de pago, construido a partir de lo que carga el navegador: vea cómo crear un inventario de scripts.
• Una justificación comercial o técnica escrita para cada script.
• Un método para confirmar que cada script está autorizado, con un registro de quién lo aprobó y cuándo.
• Un método para asegurar la integridad de cada script, como Integridad de Subrecursos (SRI), hashes o una Política de Seguridad de Contenido (CSP).
• Una forma de tratar los scripts nuevos o modificados, incluidos los que carga un gestor de etiquetas u otros scripts.

Vea PCI DSS 6.4.3 explicado.

3. Requisito 11.6.1: detectar cambios y manipulación

• Un mecanismo que evalúe las cabeceras HTTP y el contenido de las páginas de pago tal como las recibe el navegador del consumidor.
• Alertas a personal designado ante modificaciones no autorizadas, incluidas adiciones y eliminaciones.
• Una ejecución al menos una vez cada siete días, o con la frecuencia de su análisis de riesgos específico.
• Un proceso para clasificar las alertas, decidir si un cambio estaba autorizado y responder.
• Registros de ejecuciones, alertas y decisiones conservados como evidencia.

Vea PCI DSS 11.6.1 explicado y cómo detectar la manipulación del lado del cliente.

4. Requisito 12.3.1: análisis de riesgos específico

• Si elige para el 11.6.1 una frecuencia distinta de la semanal, un análisis de riesgos específico documentado que la respalde.
• Una revisión de ese análisis al menos una vez cada doce meses.
• La aprobación del análisis por las personas responsables de la decisión.

5. Controles afines que reducen el riesgo

• 6.4.1 y 6.4.2: protección de las aplicaciones web de cara al público. Cuando pasó su fecha de entrada en vigor, el 6.4.2, una solución técnica automatizada que detecta y previene ataques basados en la web, ocupó el lugar del 6.4.1.
• 6.3.2: un inventario del software a medida y personalizado y de los componentes de software de terceros, que ayuda a saber qué ejecuta usted.
• 6.2.4: técnicas para prevenir o mitigar ataques de software comunes en el software a medida y personalizado, relevante para XSS e inyección.
• 6.3.3: instalar a tiempo los parches de seguridad aplicables.
• Un control de acceso sólido para las personas y los sistemas que pueden publicar cambios en las páginas de pago, incluida la autenticación multifactor cuando PCI DSS la exige.
• Cabeceras de seguridad que dificultan el abuso de la página: cabeceras de seguridad HTTP para páginas de pago.

6. Requisito 12.8: proveedores de servicios de terceros

Los proveedores de scripts, de gestores de etiquetas y de pagos son terceros cuyos servicios pueden afectar la seguridad de los datos de tarjetas.

• 12.8.1: una lista de los proveedores de servicios de terceros (TPSP) que usa, con una descripción del servicio que presta cada uno.
• 12.8.2: acuerdos escritos en los que cada TPSP reconoce su responsabilidad por la seguridad de los datos de cuenta que maneja o que podría afectar.
• 12.8.3: diligencia debida antes de contratar a un TPSP.
• 12.8.4: un programa para vigilar el estado de cumplimiento de PCI DSS de cada TPSP al menos una vez cada doce meses.
• 12.8.5: información sobre qué requisitos de PCI DSS gestiona cada TPSP, cuáles son suyos y cuáles se comparten.

7. Preparación ante incidentes y evidencia

• Un plan de respuesta a incidentes que contemple un posible skimmer: quién decide, cómo se elimina el script, cómo se conserva la evidencia y cuándo se informa al adquirente y a las marcas de tarjetas (el requisito 12.10.1 trata del plan).
• Una carpeta o un sistema de evidencia para cada período de evaluación: inventarios, aprobaciones, evidencia del método de integridad, resultados de monitoreo, alertas, análisis de riesgos y registros de proveedores.
• Un responsable designado de los scripts de la página de pago, para que los cambios no queden sin revisar.