PCI DSS se actualiza a la versión 4.0.1

El 31 de marzo 2022 se publicó una de las actualizaciones más esperadas del estándar Payment Card Industry Data Security Standard (PCI DSS), la versión 4.0 que nos trajo muchas novedades y actualizaciones para alinearse con nuevas tecnologías, su aplicación empezó a ser obligatoria (al menos algunos requisitos) a partir del 31 de marzo de 2024.  El 11 de junio del 2024 se ha publicado una nueva versión, la 4.0.1, esta nueva versión es una actualización menor que tiene algunos cambios que nacen de la retroalimentación de la industria y tiene los siguientes cambios:

• Se busca corregir algunos errores tipográficos, de formato y falta de encabezados.
• Se actualizan y aclaran algunas orientaciones, incluidos los cambios para alinearlas con publicaciones posteriores.
• Se eliminan las definiciones de las orientaciones para aquellas que ya están en el glosario.
• Se añaden nuevos términos en el glosario y se hacen referencias estas.
• Se cambia la frase «afecte a la seguridad del CDE» por «afecte a la seguridad de los datos del titular de la tarjeta y/o los datos sensibles de autenticación».
• Se actualizan los procedimientos de prueba para alinearlos con la redacción actualizada de los requisitos.
• Se eliminaron las referencias a la fecha 31 de marzo de 2024.

Dado que no hay cambios en los controles ni en el alcance de estos, el periodo de transición es bastante corto, quedando vigentes las dos versiones del estándar hasta el 31 de diciembre de 2024, fecha a partir de la cual todas las evaluaciones deberán ser hechas contra la versión 4.0.1. En todo caso queda pendiente por parte del PCI SSC publicar las nuevas versiones de las plantillas para los reportes de cumplimiento u los formularios de autoevaluación que está programada para el tercer trimestre del año.

Veamos un poco más de detalle de algunos cambios relevantes:

• En la sección 4 de alcance, se agregó una subsección para cuando los datos del titular de la tarjeta y/o los datos confidenciales de autenticación se reciben accidentalmente a través de un canal no previsto y nos da dos alternativas:
  • Incluir el canal en el ámbito de su CDE y aplicar los correspondientes controles.
  • Eliminar los datos de forma segura y aplicar medidas para impedir que el canal se utilice en el futuro para enviar dichos datos.
• En la sección 7 se clarifica que para las evaluaciones recurrentes donde aplica un nuevo requerimiento que tiene una frecuencia definida sólo se evaluará la ejecución más reciente. Ejemplo: si un proveedor de servicio viene certificando un entorno que no tiene segmentación y en la nueva evaluación se decide separar alguna parte de la red, esta nueva evaluación incorporará el requerimiento 11.4.5 y se pedirá el último reporte de la prueba de segmentación (no dos como aplicaría por ser proveedor de servicio).
• Requisito 3: Se han aclarado las notas de aplicabilidad para emisores y empresas que prestan servicios de emisión.
• Se ha añadido un Objetivo de Enfoque Personalizado y se ha aclarado la aplicabilidad para las organizaciones que utilizan hashes criptográficos con clave para hacer ilegibles los Números de Cuenta Principales (Primary Account Numbers, PAN).
• Requisito 6: Se ha vuelto a la redacción de la norma PCI DSS v3.2.1 según la cual la instalación de parches/actualizaciones en un plazo de 30 días sólo se aplica a las «vulnerabilidades críticas».
• Se han añadido Notas de Aplicabilidad para aclarar cómo se aplica el requisito de gestión de scripts de páginas de pago.
• Requisito 8: Se agregó una Nota de Aplicabilidad que indica que la autenticación multifactor para todos los accesos (no administrativos) al CDE no se aplica a las cuentas de usuario que sólo se autentican con factores de autenticación resistentes al phishing.
• Los sistemas que dependen únicamente de factores basados en el conocimiento o limitados en el tiempo, como contraseñas o contraseñas de un solo uso (One Time Password, OTP), no se consideran resistentes al phishing, como tampoco lo son los SMS o los enlaces mágicos. Un ejemplo de autenticación resistente al phishing es FIDO2.
• Requisito 12: Se han actualizado las Notas de Aplicabilidad para aclarar varios puntos sobre las relaciones entre clientes y proveedores de servicios externos (Third-Party Service Provider, TPSP).
• Apéndices: Se han eliminado las plantillas de muestra de Enfoque Personalizado del Apéndice E y se ha hecho referencia a las plantillas de muestra que están disponibles en el sitio web del PCI SSC.
• Se añadieron las definiciones de «Excepción legal», «Autenticación resistente al phishing» y «Visitante» al Apéndice G.

Como vemos los cambios no han sido significativos y podemos empezar a usar este nuevo documento para facilitar la lectura e interpretación del estándar.

Marzo 31 de 2024: se retiró la versión 3.2.1, es decir, finalizó el periodo de transición contra esta versión y a partir de este momento todas las evaluaciones deberán ser realizadas sobre la versión 4.0. Junio 11 de 2024: se publica la versión 4.0.1 e inicia el periodo de transición entre las versiones 4.0 y la 4.0.1. Diciembre 31 de 2024*: finaliza el periodo de transición y a partir de este momento todas las evaluaciones deberán ser realizadas contra la versión 4.0.1. Marzo 31 de 2025*: entrarán en vigor todos los nuevos requerimientos marcados para fechas futuras. *Nota: estas fechas pueden ser cambiadas por el PCI SSC.