Módulo 8: PCI DSS v4.0.1 — 51 cambios

Para ver la definición formal consulta PCI DSS 4.0.1. Este módulo es la versión práctica.

PCI DSS v4.0.1 es la versión actual del estándar de seguridad de tarjetas de pago, y reemplaza a la v3.2.1 como la única versión que los evaluadores tienen permitido usar. Si todavía corres controles diseñados para el estándar anterior, tu próxima evaluación va a fallar. Esta guía recorre lo que cambió entre PCI DSS v3.2.1 y v4.0.1, y qué significan esos cambios en la práctica.

PCI DSS v4.0.1 es la versión actual del Payment Card Industry Data Security Standard, publicada en junio de 2024 como una revisión menor de la v4.0 (marzo de 2022). Reemplaza a la v3.2.1, que se retiró el 31 de marzo de 2024 — toda evaluación posterior a esa fecha debe usar la línea v4. Los doce requisitos centrales se mantienen iguales en número, pero su contenido se amplió, y un conjunto de requisitos con fecha futura pasó a ser obligatorio el 31 de marzo de 2025. Un nuevo "enfoque personalizado" permite a las organizaciones cumplir el objetivo de seguridad de un requisito usando controles técnicos alternos en vez de los prescritos.

PCI DSS v4.0.1 no es un estándar nuevo — es una actualización de erratas y aclaraciones a PCI DSS v4.0, que fue la primera reescritura mayor desde 2018. Los cambios principales son el nuevo enfoque personalizado, los requisitos ampliados de autenticación y scripting, y las reglas más estrictas en torno a las responsabilidades de los proveedores de servicio. La transición de v3.2.1 a v4 se cerró el 31 de marzo de 2024, y los requisitos con fecha futura — aquellos que el PCI SSC marcó como necesitados de tiempo extra de implementación — pasaron a ser obligatorios el 31 de marzo de 2025. El resto de esta guía desglosa esos cambios requisito por requisito y señala los que más probablemente afecten a los centros de contacto y operadores de pago telefónico.

Una nueva era para la seguridad en pagos

PCI DSS no se queda quieto. El estándar pasó por varias revisiones mayores desde su creación en 2004, y la actualización más significativa de su historia llegó con la versión 4.0, publicada en marzo de 2022. Una revisión menor, v4.0.1, siguió en junio de 2024 para atender erratas y aportar aclaraciones. Juntas representan un cambio fundamental en cómo el PCI Security Standards Council espera que los negocios aborden la seguridad en pagos.

Si venías cumpliendo con PCI DSS v3.2.1 — la versión anterior — necesitas entender qué cambió. La fecha límite de transición desde la v3.2.1 fue el 31 de marzo de 2024, lo cual significa que toda evaluación posterior a esa fecha debe usar el estándar v4. Además, algunos requisitos nuevos de la v4 tenían una fecha límite extendida de implementación al 31 de marzo de 2025, tras la cual pasaron a ser obligatorios para todas las organizaciones. Esta guía cubre los cambios clave y qué significan para tu negocio.

Como vimos en el Módulo 1, PCI DSS aplica a toda organización que almacene, procese o transmita datos del titular de tarjeta. La actualización a v4 no cambia quién debe cumplir — cambia cómo se cumple y sube la vara de lo que significa "bien hecho".

El enfoque personalizado: flexibilidad con rigor

Quizá el cambio más comentado de PCI DSS v4 es la introducción del "enfoque personalizado". En versiones anteriores, había en esencia una sola forma de cumplir cada requisito: seguir el control prescrito al pie de la letra. La v4 ahora ofrece dos caminos.

El enfoque definido es al que estás acostumbrado — controles específicos y prescriptivos que te dicen exactamente qué implementar. Instala un cortafuegos. Usa contraseñas de 12 caracteres. Cifra datos con un estándar específico. Si sigues el control definido, cumples el requisito.

El enfoque personalizado permite a las organizaciones cumplir el objetivo de un requisito usando controles alternativos de su propio diseño. En vez de preguntar "¿implementaste este control específico?", el evaluador pregunta "¿tu control alternativo cumple el objetivo de seguridad con la misma efectividad?". Este enfoque se valida con una matriz detallada de controles personalizados y con pruebas independientes.

El enfoque personalizado no es un atajo — en muchos sentidos es más exigente porque tienes que probar que tu alternativa es igual de efectiva. Está diseñado para organizaciones maduras con programas de seguridad sofisticados que ya pueden tener controles que no coinciden con la redacción prescriptiva pero logran el mismo resultado. Para la mayoría de negocios pequeños y medianos, el enfoque definido seguirá siendo la opción práctica.

Requisitos de autenticación reforzados

PCI DSS v4 apretó bastante los requisitos en torno a la autenticación — cómo las personas prueban que son quienes dicen ser al acceder a los sistemas.

La autenticación multifactor (MFA) se amplió. Bajo la v3.2.1, la MFA era obligatoria para acceso remoto al entorno de datos del titular de tarjeta. Bajo la v4, la MFA es obligatoria para todo acceso al CDE, sea remoto o local. Es un cambio importante para organizaciones donde el personal antes usaba autenticación de un solo factor (solo contraseña) para acceder a sistemas de pago desde dentro de la oficina.

Los requisitos de contraseña se reforzaron. La longitud mínima de contraseña pasó de 7 a 12 caracteres (o de 8 caracteres si tu sistema no soporta 12). Las contraseñas deben incluir caracteres numéricos y alfabéticos. Estos requisitos aplican a todas las cuentas con acceso al entorno de datos del titular de tarjeta, incluidas las cuentas de servicio y las cuentas de aplicación.

El bloqueo por autenticación fallida sigue en 10 intentos, pero los requisitos en torno a la gestión de cuentas se apretaron. Las cuentas inactivas deben eliminarse o deshabilitarse dentro de 90 días, y hay nuevos controles para cuentas compartidas y de servicio.

Para los negocios que ya adoptaron prácticas modernas de autenticación — gestores de contraseñas, MFA por todos lados, políticas de contraseñas fuertes — estos cambios pueden no requerir mucho trabajo. Pero para las organizaciones que todavía usan contraseñas simples o que no tienen MFA en sistemas internos, este es un esfuerzo de cumplimiento importante.

Cifrado y protección de datos ampliados

Los requisitos de protección de datos bajo la v4 se ampliaron y aclararon. Algunos cambios vale la pena destacarlos:

El cifrado a nivel de disco ya no se acepta como único método para proteger datos del titular de tarjeta almacenados en la mayoría de sistemas. Bajo la v3.2.1, el cifrado de disco completo (como BitLocker) podía satisfacer el Requisito 3 en algunos entornos. La v4 aclara que el cifrado de disco solo satisface el requisito en medios removibles. Para otro almacenamiento, necesitas cifrado a nivel de archivo, columna o campo — o mejor aún, no almacenes los datos.

Los requisitos de gestión de claves de cifrado se reforzaron, con guía más específica sobre rotación de claves, almacenamiento de claves y separación de funciones entre custodios de claves.

Los requisitos de hashing se apretaron. Si usas hashing para volver ilegibles los PAN, el hash debe llevar clave (usando HMAC o un mecanismo similar). Los hashes simples sin clave ya no se consideran adecuados porque pueden revertirse con ataques de tablas arcoíris.

El mensaje es claro: el consejo quiere ver protección de datos más fuerte y deliberada. La mejor estrategia sigue siendo la que venimos defendiendo en toda esta serie — reduce la cantidad de datos del titular de tarjeta en tu entorno para que haya menos que proteger. El enmascaramiento DTMF para pagos telefónicos y las páginas de pago alojadas para transacciones en línea logran esto al enrutar los datos de tarjeta directo al procesador.

Análisis de riesgo dirigido

PCI DSS v4 introduce el concepto de "análisis de riesgo dirigido" para varios requisitos. Bajo la v3.2.1, muchos controles de seguridad tenían frecuencias fijas — escanear trimestralmente, revisar anualmente, rotar contraseñas cada 90 días. La v4 permite a las organizaciones determinar sus propias frecuencias para ciertos controles, siempre que hagan un análisis de riesgo formal que justifique el calendario elegido.

Por ejemplo, en vez de exigir que todas las relaciones con proveedores de servicio se revisen a intervalos fijos, la v4 permite determinar la frecuencia de revisión adecuada con base en un análisis de riesgo que considere la naturaleza del servicio, los datos involucrados y el perfil de riesgo. Esto aplica a áreas como:

• Frecuencia de revisión de registros — cada cuánto revisas los registros en busca de eventos de seguridad
• Frecuencia de cambio de contraseñas — cada cuánto deben cambiarse las contraseñas (si eliges rotación por tiempo en vez de cambios por evento)
• Frecuencias de escaneo de vulnerabilidades para escaneos internos más allá de los trimestrales requeridos por ASV
• Ciclos de revisión para políticas de seguridad, reglas de cortafuegos y accesos de usuario

Es una flexibilidad de doble filo. Defines frecuencias que tienen sentido para tu negocio, pero debes documentar el análisis de riesgo y estar listo para defender tus decisiones ante un evaluador. "Solo revisamos los registros una vez al mes porque estamos ocupados" no va a pasar. "Revisamos los registros una vez al mes porque nuestro análisis de riesgo dirigido identificó volumen bajo de transacciones, controles detectivos compensatorios y alertas automatizadas que reducen el riesgo a un nivel aceptable" sí podría.

Seguridad continua y el fin del cumplimiento puntual

Uno de los temas más fuertes a lo largo de PCI DSS v4 es el énfasis en la seguridad continua. El consejo viene diciendo desde hace años que el cumplimiento debe ser un estado continuo, no un evento anual. La v4 le pone dientes a ese mensaje.

Varios requisitos ahora dicen explícitamente que los controles deben estar implementados y operando de forma efectiva "en todo momento" o "durante todo el año", no solo en el punto de evaluación. Los nuevos requisitos incluyen:

• Requisito 12.3.2: Debe realizarse un análisis de riesgo dirigido para cada requisito de PCI DSS donde la entidad use el enfoque personalizado, y este análisis debe actualizarse cuando las condiciones cambien
• Requisito 5.3.2.1: Si se usan escaneos de malware periódicos (en vez de escaneo en tiempo real), la frecuencia debe definirse por un análisis de riesgo dirigido
• Requisito 10.4.1.1: Deben usarse mecanismos automatizados para realizar revisiones de registros de auditoría

La implicación práctica es que no puedes dejar caer tus controles de seguridad entre evaluaciones y luego correr a ponerlos en orden cuando llega el auditor. La v4 espera que puedas demostrar que tus controles funcionaron durante todo el período de evaluación. Como veremos en el Módulo 9, tratar el cumplimiento como una casilla anual es uno de los errores más comunes — y ahora más riesgosos — que cometen los negocios.

Integridad de scripts y seguridad de páginas de pago

PCI DSS v4 introdujo requisitos totalmente nuevos en torno a la seguridad de las páginas de pago que no existían en la v3.2.1. Estos afectan principalmente a negocios de comercio electrónico, pero conviene entenderlos.

El Requisito 6.4.3 exige que todos los scripts de páginas de pago (JavaScript, por ejemplo) que se cargan y ejecutan en el navegador del consumidor estén gestionados. Necesitas mantener un inventario de todos los scripts, asegurar que cada uno tiene una razón de negocio justificada e implementar un método para confirmar la integridad de los scripts. Esto atiende la amenaza creciente de los ataques de web skimming (a veces llamados ataques Magecart), donde los atacantes inyectan JavaScript malicioso en las páginas de pago para robar datos de tarjeta mientras los clientes los escriben.

El Requisito 11.6.1 exige un mecanismo de detección de cambios y manipulación para las páginas de pago. Si alguien modifica los encabezados HTTP o el contenido de tu página de pago, debes recibir una alerta.

Estos requisitos reflejan el panorama de amenazas que evoluciona. Como la seguridad de pagos en línea mejoró en algunas áreas, los atacantes se cambiaron a ataques del lado del cliente que son más difíciles de detectar con herramientas tradicionales del lado del servidor. Para los negocios que usan páginas de pago alojadas o iframes, el impacto es menor porque la página de pago no se sirve desde tu dominio — otro beneficio de reducir el alcance, como vimos en el Módulo 5.

Calendario y transición

Entender el calendario de transición es importante para planificar:

• Marzo de 2022: Publicación de PCI DSS v4.0
• Junio de 2024: Publicación de PCI DSS v4.0.1 (correcciones menores y aclaraciones)
• 31 de marzo de 2024: La v3.2.1 se retira oficialmente — toda evaluación debe usar la v4
• 31 de marzo de 2025: Fecha límite extendida para los requisitos "con fecha futura" — se identificaron en el estándar como buenas prácticas hasta esa fecha, tras la cual pasaron a ser obligatorios

Si todavía no llevaste tu programa de cumplimiento a la v4, hazlo ya. Tu próxima entrega de SAQ o evaluación QSA debe usar los formularios y criterios v4.0.1. Trabaja con tu banco adquirente o QSA para entender exactamente cuáles requisitos nuevos afectan tu entorno.

Puntos clave

• PCI DSS v4.0.1 es el estándar actual — todas las evaluaciones deben hacerse contra la v4, y la fecha límite final de transición pasó el 31 de marzo de 2025
• El enfoque personalizado ofrece flexibilidad para cumplir objetivos de seguridad con controles alternativos, aunque exige una validación más rigurosa que el enfoque definido
• La MFA ahora es obligatoria para todo acceso al entorno de datos del titular de tarjeta, no solo para acceso remoto — un cambio importante para muchas organizaciones
• Las contraseñas deben tener al menos 12 caracteres con caracteres numéricos y alfabéticos
• El análisis de riesgo dirigido permite a los negocios fijar sus propias frecuencias para ciertos controles, siempre que documenten la justificación
• La seguridad continua ahora es un requisito, no solo una recomendación — los controles deben operar de forma efectiva todo el año, no solo al momento de la evaluación
• Los nuevos requisitos de seguridad de páginas de pago atienden amenazas de web skimming — otra razón para usar páginas de pago alojadas que mantengan los datos de tarjeta fuera de tu dominio