El 31 de marzo de 2025 es una fecha crucial para numerosas organizaciones en el ámbito de PCI DSS. La introducción de la versión 4.0 del estándar PCI DSS en 2022, seguida de la versión más actual publicada por el PCI SSC, 4.0.1, ha marcado esta fecha como un hito fundamental para la implementación y el mantenimiento de los nuevos controles que se han introducido en estas versiones del estándar.

Como se detalla en la serie de artículos publicados en el blog (https://blog.isecauditors.com/2023/10/version-4-de-pci-dss-analizando-requisitos-1-y-2.html-0), en los cuales se abordan los cambios introducidos en cada uno de los requisitos de la versión 4.0 de PCI DSS, se establece que existen ciertos requisitos, o partes de los mismos, que se consideran buenas prácticas hasta el 31 de marzo de 2025. A partir de esa fecha, dichos requisitos pasarán a ser de cumplimiento obligatorio y tendrán que ser evaluados durante la auditoría correspondiente, eliminando la validez de la FAQ 1564 publicada por el PCI SSC en marzo de 2023 que permitía establecer como no aplicables los nuevos requisitos considerados buenas prácticas. En consecuencia, se presentan las siguientes situaciones en los entornos actuales:

• La necesidad de implementar nuevos controles.
• La implementación de componentes de controles ya existentes. Se conserva parte del control original, añadiendo nuevos apartados para incrementar la seguridad.
• La introducción de nuevos controles, basados en controles existentes, que sustituirán a los anteriores.

A continuación, detallaremos cada uno de estos controles según aparecen en el estándar hasta el requisito 6 (incluido).

Requisitos que dejan de ser buenas prácticas el 31 de marzo de 2025

El listado de requisitos, ordenados según su aparición en la versión 4.0.1 del estándar de PCI DSS, que incluyen buenas prácticas hasta el 31 de marzo de 2025 son los siguientes:

Requisito 3.2.1:

Definición:

3.2.1 El almacenamiento de datos del titular de la tarjeta se mantiene al mínimo mediante la implementación de políticas y procedimientos de retención y eliminación de datos que incluyan al menos lo siguiente: 

• Cubren todas las ubicaciones donde hay datos del titular de la tarjeta almacenados. 
• Cubren todos los datos sensibles de autenticación (SAD) almacenados antes de completar la autorización. Este punto es una de las mejores prácticas hasta su fecha de vigencia; refiérase a las Notas de Aplicabilidad que aparecen a continuación para obtener más detalles. 
• Limitar la cantidad de datos almacenados y su tiempo de retención a lo requerido por los requisitos legales o reglamentarios y/o de negocios. 
• Requisitos de retención específicos para los datos del titular de la tarjeta almacenados que definen la duración del período de retención e incluyen una justificación de negocio documentada. 
• Procesos para el borrado seguro o para hacer que los datos del titular de la tarjeta sean irrecuperables cuando ya no se necesitan según la política de retención. 
• Un proceso para verificar, al menos una vez cada tres meses, que los datos del titular de la tarjeta almacenados que excedan el período de retención definido se han eliminado de forma segura o se han vuelto irrecuperables.

Enfoque para la versión 4.0.1:

Casi la totalidad del requisito era obligatorio de cumplir dentro de la versión 3.2.1 del estándar, salvo la parte subrayada, con la que se extienden las políticas de retención y eliminación de datos hasta los datos sensibles de autenticación o SAD que son almacenados antes de completar la autorización. El objetivo es limitar el almacenamiento de SAD dentro del entorno a lo estrictamente necesario por negocio, garantizando el borrado seguro de los mismos una vez se haya realizado la autorización de la transacción.

Requisito 3.3.2:

Definición:

3.3.2 Los SAD que se almacenan electrónicamente antes de completar la autorización se cifran mediante criptografía sólida.

Enfoque para la versión 4.0.1:

Todos los SAD que son almacenados previo a la autorización deben ser cifrados utilizando criptografía robusta. Se entiende por criptografía robusta aquella que se basa en algoritmos probados y aceptados por la industria que disponen de longitudes de clave que proporcionan un mínimo de 112 bits de robustez de clave efectiva. Algunos de los algoritmos permitidos son AES 128, AES 192 o AES 256. Se recomienda que todas las implementaciones nuevas utilicen un mínimo de 128 bits de robustez de clave efectiva.

Cualquier organización emisora, o aquellas que soportan los servicios de emisión, no estarían obligados a cumplir con este requisito siempre que exista una necesidad de negocio documentada.

Requisito 3.3.3:

Definición:

3.3.3 Requisito adicional para emisores y empresas que soportan servicios de emisión y que almacenan datos sensibles de autenticación: Cualquier almacenamiento de datos sensibles de autenticación está: 

• Limitado a lo que se necesita para una necesidad legítima de negocio de emisión y está asegurado. 
• Cifrado utilizando criptografía robusta. Este punto es una de las mejores prácticas hasta su fecha de vigencia; refiérase a las Notas de Aplicabilidad que aparecen a continuación para obtener más detalles.

Enfoque para la versión 4.0.1:

Como en el caso del requisito 3.2.1, el requisito ya era obligatorio de cumplir dentro de la versión 3.2.1 del estándar para emisores y empresas que soportan servicios de emisión y que almacenan datos sensibles de autenticación o SAD, salvo la parte subrayada, con la que se pretende aportar un grado mayor de seguridad, protegiendo los SAD utilizando criptografía robusta.

Requisito 3.4.2:

Definición:

3.4.2 Cuando se utilicen tecnologías de acceso remoto, los controles técnicos impiden la copia y/o la reubicación de PANs para todo el personal, excepto para aquellos con autorización explícita y documentada y una necesidad legítima de negocio y definida.

Enfoque para la versión 4.0.1:

El uso de tecnologías de acceso remoto como son los escritorios virtuales introduce una serie de riesgos que pretenden reducirse a través de este nuevo control, limitando la posibilidad de copiar/mover PANs a dispositivos de almacenamiento (discos duros locales, unidades virtuales, medios electrónicos extraíbles, unidades de red, nube) no autorizados.

Requisito 3.5.1.1:

Definición:

3.5.1.1 Los hashes utilizados para hacer ilegibles los PANs (según el primer punto del requisito 3.5.1) son hashes criptográficos con clave para el PAN completo, con procesos y procedimientos de gestión de claves asociados de acuerdo con los Requisitos 3.6 y 3.7.

Enfoque para la versión 4.0.1:

Este requisito presenta una ligera evolución con respecto a la versión 3.2.1 del estándar, indicando que, en caso de proteger los PANs a través de hashes con el fin de hacerlos ilegibles al almacenarlos, estos deben ser hashes criptográficos con clave robusta. Es decir, que pueden utilizarse algoritmos como HMAC, CMAC y GMAC siempre y cuando vayan con claves con una robustez criptográfica efectiva de, al menos, 128 bits. Algún ejemplo es HMAC_SHA216 o CMAC_SHA512.

Requisito 3.5.1.2:

Definición: 

3.5.1.2 Si se utiliza un cifrado a nivel de disco o de partición (en lugar de un cifrado de base de datos a nivel de archivo, columna o campo) para hacer que los PANs sea ilegibles, sólo se implementará de la siguiente manera: 

• En medios electrónicos extraíbles,
  
  O 
• Si se utiliza para medios electrónicos no extraíbles, los PANs también se hacen ilegibles mediante otro mecanismo que cumpla con el Requisito 3.5.1. 

Enfoque para la versión 4.0.1:

El cifrado a nivel de disco, o a nivel de partición, normalmente cifra con una misma clave el disco/partición y los datos almacenados, por lo que al descifrar el disco/partición también los datos almacenados se descifran. Por tanto, se considera una solución válida su implementación en medios electrónicos extraíbles (CD-ROM, DVD-ROM, memorias USB y discos duros extraíbles) y en medios no extraíbles añadiendo otro mecanismo adicional, como los descritos en el requisito 3.5.1 (hashes criptográficos unidireccionales basados en criptografía sólida para el PAN completo, truncamiento con las limitaciones expuestas por el estándar, índice de tokens y criptografía robusta con procesos y procedimientos de gestión de claves asociados).

Para organizaciones emisoras o que soportan los procesos de estas, este requisito no aplica a los PANs que se acceden para el procesamiento de transacciones en tiempo real. Sin embargo, sí se aplica a los PAN almacenados para otros fines.

Requisito 3.6.1.1:

Definición: 

3.6.1.1 Requisito adicional sólo para proveedores de servicios: Se mantiene una descripción documentada de la arquitectura criptográfica que incluye:

• Detalles de todos los algoritmos, protocolos y claves utilizados para la protección de los datos del titular de la tarjeta almacenados, incluyendo la fuerza de la clave y la fecha de caducidad.
• Evitar el uso de las mismas claves criptográficas en entornos de producción y de prueba. Este punto es una de las mejores prácticas hasta su fecha de vigencia; consulte las Notas de Aplicabilidad que aparecen a continuación para obtener más detalles.
• Descripción del uso de claves para cada clave.
• Inventario de los módulos de seguridad de hardware (HSM), sistemas de gestión de claves (KMS) y otros dispositivos criptográficos seguros (SCD) utilizados para la gestión de claves, incluido el tipo y la ubicación de los dispositivos para apoyar el cumplimiento del Requisito 12.3.4.

Enfoque para la versión 4.0.1:

Casi la totalidad del requisito era obligatorio de cumplir dentro de la versión 3.2.1 del estándar para las empresas que actúan como proveedores de servicio, salvo la parte subrayada, que añade un nivel más de seguridad al establecer nuevos controles documentados para evitar el uso de las mismas claves de cifrado en los entornos de producción como en los de prueba. De este modo el compromiso de una clave de cifrado en un entorno no productivo (entorno de desarrollo, de preproducción, etc.) no afectaría a la seguridad de los datos de cuenta en el entorno productivo.

Requisito 4.2.1:

Definición:

4.2.1 Se implementan fuertes protocolos de seguridad y criptografía de la siguiente manera para proteger los PANs durante la transmisión a través de redes públicas abiertas: 

• Solo se aceptan claves y certificados confiables. 
• Los certificados utilizados para proteger los PANs durante la transmisión a través de redes públicas abiertas se confirman como válidos y no están vencidos ni revocados. Este punto es una de las mejores prácticas hasta su fecha de vigencia; consulte las notas de aplicabilidad a continuación para obtener más detalles. 
• El protocolo en uso sólo admite versiones o configuraciones seguras y no admite el apoyo ni el uso de versiones, algoritmos, tamaños de clave o implementaciones inseguras. 
• La robustez del cifrado es apropiada para la metodología de cifrado en uso. 

Enfoque para la versión 4.0.1:

De nuevo para este requisito, la casi la totalidad del requisito era obligatorio de cumplir dentro de la versión 3.2.1 del estándar, salvo la parte subrayada, incluyendo, como una parte importante de la protección de las comunicaciones en redes abiertas y públicas, los certificados utilizados, los cuales deben mantenerse vigentes y no encontrase ni vencidos ni revocados. Para ello se pueden utilizar Certificate Revocation Lists (CRL) actualizadas u Online Certificate Status Protocols (OCSP) para validar que los certificados no han sido revocados y continúan siendo válidos. Adicionalmente, se debe comprobar que las fechas de validez de los certificados es correcta, evitando el uso de certificados caducados.

Requisito 4.2.1.1:

Definición:

4.2.1.1 Se mantiene un inventario de las claves y certificados confiables de la entidad utilizados para proteger los PANs durante la transmisión.

Enfoque para la versión 4.0.1:

El objetivo del requisito es identificar todos los algoritmos, protocolos, claves, certificados, etc., utilizados para la protección de las comunicaciones de PANs en redes abiertas y públicas. El inventariado permite identificar custodios de claves, fechas de caducidad, etc, permitiendo que la organización responda de forma efectiva y rápida a vulnerabilidades encontradas en los protocolos, algoritmos, certificados, etc., utilizados. Para los certificados, es recomendable incluir las CAs (Autoridades de Certificación) emisoras y las fechas de caducidad.

Requisito 5.2.3.1:

Definición:

5.2.3.1 La frecuencia de las evaluaciones periódicas de los componentes del sistema identificados como no en riesgo de malware se define en el análisis de riesgo específico de la entidad, el cual se realiza de acuerdo con todos los elementos especificados en el Requisito 12.3.1.

Enfoque para la versión 4.0.1:

La inclusión de los Análisis de Riesgos Específicos (TRA) basados en frecuencia suponen un gran cambio en la versión 4.0 y 4.0.1, como se analizó en otros artículos del blog (https://blog.isecauditors.com/pci-dss-v40-analisis-de-riesgos-especifico o https://blog.isecauditors.com/2023/10/como-gestionar-el-requisito-12-3-1-de-pci-dss-mediante-fra.html). Para este requisito, el objetivo es el de definir la periodicidad con la se ejecuta el control a través del TRA de frecuencia. La frecuencia sugerida por el PCI SSC en la guía de TRA, para tomar como referencia, es de 6 meses.

Requisito 5.3.2.1:

Definición:

5.3.2.1 Si se realizan escaneos periódicos de malware para cumplir con el requisito 5.3.2, la frecuencia de los escaneos se define en el análisis de riesgos específico de la entidad, que se realiza de acuerdo con todos los elementos especificados en el Requisito 12.3.1.

Enfoque para la versión 4.0.1:

Tal y como se ha señalado para el requisito anterior, la ejecución de los escaneos periódicos de malware tiene que basarse en el resultado de un TRA de frecuencia. La frecuencia sugerida por el PCI SSC en la guía de TRA, para tomar como referencia, es de 24 horas.

Requisito 5.3.3:

Definición:

5.3.3 Para los medios electrónicos extraíbles, la solución antimalware:

• Realiza escaneos automáticos cuando el medio es insertado, conectado o montado lógicamente,
  
  O
• Realiza un análisis continuo del comportamiento de los sistemas o procesos cuando el medio está insertado, conectado o montado lógicamente.

Enfoque para la versión 4.0.1:

La solución antimalware desplegada en una organización debe proteger al entorno de PCI DSS cuando los medios electrónicos extraíbles (CD-ROM, DVD-ROM, memorias USB y discos duros extraíbles) son insertados, conectados o montados lógicamente mediante escaneos automáticos o a través de análisis continuo de comportamiento.

Requisito 5.4.1:

Definición:

5.4.1 Existen procesos y mecanismos automatizados para detectar y proteger al personal contra ataques de phishing.

Enfoque para la versión 4.0.1:

El PCI SSC ha considerado que el incremento de ataques de ingeniería social, especialmente de phishing, en los últimos años supone un aumento en el riesgo de los entornos en los que se trabaja con datos de cuenta, ya sea para obtener los propios datos de cuenta o las credenciales de acceso al entorno. Para ello, la versión 4.0.1 del estándar de PCI DSS establece la necesidad de implementar controles para la protección contra estos tipos de ataque. Algunos de los mecanismos propuestos en el estándar son:

• Autenticación de mensajes basada en dominio, informes y conformidad (DMARC - Domain-based Message Authentication, Reporting & Conformance).
• Marco de Políticas del Remitente (SPF - Sender Policy Framework).
• Correo Identificado con Claves de Dominio (DKIM - Domain Keys Identified Mail).

Los mecanismos para bloquear correos electrónicos de phishing y malware, como depuradores de enlaces y antimalware del lado del servidor, puede reducir los incidentes de seguridad en entornos PCI DSS, así como disminuir el tiempo de respuesta ante estos ataques.

Requisito 6.3.2:

Definición:

6.3.2 A fin de facilitar la gestión de vulnerabilidades y parches se mantiene un inventario del software a medida y personalizado, y de los componentes del software de terceros incorporados en el software a medida y personalizado.

Enfoque para la versión 4.0.1:

El objetivo del requisito es limitar la exposición a vulnerabilidades de software hecho a medida y personalizado, identificando todos los componentes de terceros incluidos en el entorno, tanto el propio software como componentes del software de terceros incorporados en ese software a medida y personalizado, como serían librerías, APIs, etc. De este modo el proceso de gestión de vulnerabilidades incluye estos componentes, facilitando la identificación de vulnerabilidades y su remediación. 

Se recomienda incluir en el inventario todos los componentes y dependencias del software de pago, incluidas las plataformas o entornos de ejecución compatibles, bibliotecas de terceros, servicios y otras funcionalidades requeridas.

Requisito 6.4.2:

Definición:

6.4.2 Para aplicaciones web de cara al público se implementa una solución técnica automatizada que detecta e impide continuamente ataques basados en la web, con al menos lo siguiente:

• Se instala frente a aplicaciones web de cara al público y está configurado para detectar e impedir ataques basados en la web.
• Funcionando activamente y actualizándose según corresponda.
• Generando registros de auditoría.
• Configurados ya sea para bloquear los ataques basados en la web o para generar una alerta que se investigue inmediatamente.

Enfoque para la versión 4.0.1:

El requisito 6.4.2 reemplazará al requisito 6.4.1, por el cual será necesario implementar una solución técnica automatizada en tiempo real, como los WAFs (Firewalls de Aplicaciones Web), para proteger las aplicaciones web con interfaces públicas, eliminando la posibilidad de hacer revisiones manuales o automatizadas cada 12 meses. De este modo, se asegura una monitorización activa de las interfaces públicas protegiendo al entorno de ataques basados en la web. 

Otro de los puntos clave que cambia con respecto a versiones anteriores del estándar, es la necesidad de que la solución debe actualizarse para asegurar la protección de las aplicaciones web. 

Requisito 6.4.3:

Definición:

6.4.3 Todos los scripts de las páginas de pago que se cargan y ejecutan en el navegador del consumidor se gestionan de la siguiente manera: 

• Se implementa un método para confirmar que cada script está autorizado. 
• Se implementa un método para asegurar la integridad de cada script. 
• Se mantiene un inventario de todos los scripts con una justificación empresarial o técnica por escrito que explique su necesidad. 

Enfoque para la versión 4.0.1:

Este nuevo requisito tiene como objetivo principal el controlar los scripts que se incluyen en las páginas o formularios de pago, identificando cada uno de ellos en un inventario que incluya su justificación de negocio. De esta forma se permite validar que todos los scripts son los autorizados por la organización para su carga y ejecución en el navegador del consumidor. Adicionalmente, se debe asegurar la integridad de cada uno de los scripts, a través de una monitorización y evitando que pueda haber scripts fraudulentos con la finalidad de robar los datos de cuenta de los consumidores.

Este requisito se aplica a todos los scripts cargados desde el entorno de la entidad y a los scripts cargados desde terceras y cuartas partes, así como a los scripts que se encuentran en las páginas web de la organización que incluyen una página o formulario de pago incrustado de un TPSP o procesador de pagos (por ejemplo, uno o más marcos en línea o iframes).

Cuando la página de pago se cargue en un iframe, el uso de la Política de Seguridad de Contenido (CSP - Content Security Policy) de la página principal puede ayudar a evitar la sustitución de la página de pago por contenido no autorizado.

Algunos ejemplos de mecanismos mencionados por el estándar son:

• Integridad de sub-recursos (SRI - Sub-resource integrity), lo que permite al navegador del consumidor validar que un script no ha sido manipulado.
• Un CSP, que limita las ubicaciones desde las cuales el navegador del consumidor puede cargar un script y transmitirle datos del titular de la tarjeta.
• Sistemas propios de gestión de scripts o etiquetas, que pueden impedir la ejecución de scripts maliciosos.