Para finalizar el análisis de los controles del estándar de PCI DSS versión 4.0.1 que son obligatorios a partir del 31 de marzo de 2025 , en esta tercera y última parte vamos a detallar los controles que dejan de ser buenas prácticas a partir de esa fecha y que van desde el requisito 11 (incluido) hasta el requisito 12 (incluido).
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:
Definición:
11.3.1.1 Todas las demás vulnerabilidades aplicables (aquellas que no se clasifican como vulnerabilidades de alto riesgo o vulnerabilidades críticas según las clasificaciones de riesgo de vulnerabilidad de la entidad definidas en el Requisito 6.3.1) se gestionan de la siguiente manera:
▶️ Abordado en función del riesgo definido en el análisis de riesgo 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:
La frecuencia con la que se remedian las vulnerabilidades, catalogadas como no críticas ni altas en los escaneos internos de vulnerabilidades, viene determinada por el resultado de la ejecución de un TRA de frecuencia por parte de la organización. El resultado del TRA de frecuencia debe definir la periodicidad con la que se deben resolver las distintas vulnerabilidades encontradas. La frecuencia sugerida por el PCI SSC en la guía de TRA, para tomar como referencia, es de 3 meses para las medias, 6 meses para las bajas y monitorización regular para las informacionales.
Adicionalmente, deben realizarse re-escaneos según sea necesario para verificar que las distintas vulnerabilidades encontradas en los escaneos internos se resuelven de forma adecuada.
Definición:
11.3.1.2 Los escaneos de vulnerabilidades internas se realizan mediante escaneos autenticados como sigue:
Enfoque para la versión 4.0.1:
Adicionalmente a cómo se venía abordando en versiones anteriores del estándar el requisito relativo a escaneos internos de vulnerabilidades, la nueva versión del estándar requiere que estos sean autenticados o con credenciales.
Para ello, el usuario autorizado que va a ejecutar el escaneo requiere privilegios elevados de acceso para la ejecución correcta del propio escaneo. De este modo, se detectará información adicional a la que se venía identificando con los escaneos no autenticados. Las credenciales deben protegerse y controlarse de acuerdo a los requisitos 7 y 8.
Se consideran privilegios suficientes aquellos para ingresar a los recursos del sistema, permitiendo la ejecución de un análisis exhaustivo de vulnerabilidades.
Definición:
11.4.7 Requisito adicional sólo para los proveedores de servicios multiusuario: Los proveedores de servicios multiusuario apoyan a sus clientes para las pruebas de penetración externas según los Requisitos 11.4.3 y 11.4.4.
Enfoque para la versión 4.0.1:
Los proveedores de servicio multi-tenant deben ayudar a sus clientes a realizar las pruebas de penetración externas. Para ello, el proveedor de servicio puede:
▶️ Proporcionar evidencia para demostrar que se han realizado pruebas de penetración de acuerdo con los requisitos 11.4.3 y 11.4.4.Definición:
11.5.1.1 Requisito adicional sólo para proveedores de servicios: Las técnicas de detección y/o prevención de intrusión detectan, alertan/impiden y abordan los canales de comunicación de malware encubierto.
Enfoque para la versión 4.0.1:
Adicionalmente a lo que requería la versión 3.2.1 relativo a la instalación de dispositivos IDS/IPS, la versión actual del estándar añade que los controles de prevención y/o detección de intrusión protejan a los entornos contra los canales de comunicación de malware encubierto, como sería la tunelización de DNS, tunelización a través de ICMP o canales en redes P2P.
El estándar proponer como buenas prácticas el escaneo de puntos finales en tiempo real, el filtrado del tráfico de salida, una lista de “permitidos”, herramientas de prevención de pérdida de datos (DLP) y herramientas de supervisión de la seguridad de la red (IDS/IPS).
Definición:
11.6.1 El mecanismo de detección de cambios y manipulaciones se despliega de la siguiente manera:
▶️ Para enviar alertas al personal sobre modificaciones no autorizadas (incluyendo indicadores de compromiso, cambios, adiciones y borrado) en los encabezados HTTP que afectan la seguridad y en el contenido de script de las páginas de pago tal y como las recibe el navegador del consumidor.
▶️ El mecanismo está configurado para evaluar el encabezado HTTP y las páginas de pago recibidas por el navegador del consumidor.
Las funciones del mecanismo se realizan de la siguiente manera:
- Al menos semanalmente
O
- Periódicamente, (a una frecuencia definida en el análisis de riesgos específico de la entidad, el cual se desarrolla de acuerdo a todos los elementos especificados en el Requisito 12.3.1.).
Enfoque para la versión 4.0.1:
El objetivo del requisito es el detectar cambios no autorizados en las páginas o formularios de pago, detectando y respondiendo de forma adecuada ante ellos mediante alertas al personal. El mecanismo debe hacer comprobaciones en los encabezados HTTP y en las páginas de pago recibidas por el navegador del consumidor. Algunas de las formas mencionadas por el estándar son las siguientes:
▶️ Las Infracciones de la Política de Seguridad de Contenido (CSP) se pueden reportar a la entidad mediante las directivas CSP report-to o report-uri.
▶️ Los cambios en el CSP en sí pueden indicar una manipulación.
▶️ El monitoreo externo por parte de los sistemas que solicitan y analizan las páginas web recibidas (también conocido como monitoreo sintético de usuarios) puede detectar cambios en JavaScript en las páginas de pago y alertar al personal.
▶️ La incrustación de un script de detección de alteraciones a prueba de manipulaciones en la página de pago puede alertar y bloquear cuando se detecta un comportamiento de script malicioso.
▶️ Los proxies inversos y las Redes de Entrega de Contenido o CDN pueden detectar cambios en los scripts y alertar al personal.
El requisito también aplica para páginas webs que contienen una página o formulario de pago incrustado de un TPSP o procesador de pagos (iframes).
La frecuencia con la que el mecanismo hace las comprobaciones para detectar cambios no autorizados debe ser semanal o basarse en el resultado de un TRA de frecuencia ejecutado por parte de la organización. La frecuencia sugerida por el PCI SSC en la guía de TRA, para tomar como referencia, es de 7 días.
Definición:
12.3.1 Para cada requisito de PCI DSS que especifique completar un análisis de riesgo específico, el análisis se documenta e incluye:
▶️ Identificación de los activos a proteger.
Enfoque para la versión 4.0.1:
Tal y como se ha analizado en otros artículos publicados en el 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), el enfoque que da la nueva versión del estándar cambia por completo la visión sobre las evaluaciones de riesgos. El objetivo de este requisito queda cubierto en los artículos mencionados.
Definición:
12.3.3 Los protocolos criptográficos y suites de cifrado en uso se documentan y revisan, al menos, una vez cada 12 meses, incluyendo al menos lo siguiente:
▶️ Un inventario actualizado de todos los protocolos criptográficos y suites de cifrado en uso, incluyendo su propósito y dónde se utilizan.
Enfoque para la versión 4.0.1:
Este nuevo control enfatiza la importancia de la protección de protocolos y suites de cifrado utilizadas en los procesos de almacenamiento y transmisión de PANs, protección de contraseñas y aquellos procesos que forman parte de la autenticación del acceso. El objetivo del control es identificar los protocolos criptográficos y las suites de cifrado utilizadas dentro del entorno, facilitando la monitorización de las tendencias en la industria. De este modo, se puede responder de forma ágil ante vulnerabilidades encontradas en ellos.
Definición:
12.3.4 Las tecnologías de hardware y software en uso se revisan al menos una vez cada 12 meses, incluyendo al menos lo siguiente:
▶️ Análisis de que las tecnologías continúan recibiendo correcciones de seguridad por parte de los proveedores con prontitud.
Enfoque para la versión 4.0.1:
Este nuevo requisito tiene como objetivo el asegurarse de que las versiones de las tecnologías desplegadas en el entorno de PCI DSS se encuentran actualizadas y respaldadas por los fabricantes, evitando que pueda haber sistemas fuera de soporte en el alcance. Esta revisión anual favorece que los controles protegidos por estas tecnologías continúan siendo efectivos.
Definición:
12.5.2.1 Requisito adicional solo para proveedores de servicios: El alcance PCI DSS es documentado y confirmado por la entidad al menos una vez cada seis meses y ante cambios significativos en el entorno dentro del alcance. Como mínimo, la validación del alcance incluye todos los elementos especificados en el Requisito 12.5.2.
Enfoque para la versión 4.0.1:
El requisito presenta una evolución del requisito 12.5.2, incluido en la versión 4.0 sobre confirmación y documentación del alcance PCI DSS, para que los proveedores de servicio ejecuten este control cada 6 meses o después de cambios significativos, incluyendo todos los elementos especificados dentro del requisito 12.5.2.
Definición:
12.5.3 Requisito adicional solo para proveedores de servicios: Los cambios significativos en la estructura organizativa dan como resultado una revisión documentada (interna) del impacto en el alcance PCI DSS y la aplicabilidad de los controles; los resultados se comunican a la dirección ejecutiva.
Enfoque para la versión 4.0.1:
Se debe realizar una revisión documentada sobre el impacto que tiene en el alcance de PCI DSS un cambio en la estructura organizativa de una empresa, como serían fusiones o adquisiciones de empresas, o cambios significativos o reasignaciones de personal responsable de los controles de seguridad. De esta forma se garantiza que los controles de seguridad se encuentran debidamente implementados y activos, teniendo definido un responsable para cada uno de esos controles.
Definición:
12.6.2 El programa de concienciación sobre seguridad es:
▶️ Revisado al menos una vez cada 12 meses, y
Enfoque para la versión 4.0.1:
El programa de formación y concienciación debe revisarse de forma anual, y actualizarse para incluir nuevas amenazas y vulnerabilidades que afecten al entorno PCI DSS de una organización.
Definición:
12.6.3.1 El training de concienciación de seguridad incluye la concienciación ante amenazas y vulnerabilidades que podrían impactar la seguridad los datos de titular de tarjeta o datos sensibles de autenticación, incluyendo, pero no limitado a:
▶️ Phishing y ataques relacionados.
Enfoque para la versión 4.0.1:
El requisito 12.6.3.1 se presenta como una evolución del requisito incluido en la versión 3.2.1, obligando a las organizaciones a incluir concienciación relativa a phishing y ataques relacionados, e ingeniería social. Como buenas prácticas se señala el incluir ejemplos de correos electrónicos de phishing y pruebas periódicas para determinar la prevalencia del personal para informar sobre dichos ataques. Este material puede incluir:
▶️ Cómo identificar el phishing y otros ataques de ingeniería social.Definición:
12.6.3.2 La capacitación en concienciación sobre seguridad incluye la concienciación sobre el uso aceptable de las tecnologías de usuario final de acuerdo con el requisito 12.2.1.
Enfoque para la versión 4.0.1:
Del mismo modo que el requisito anterior, este control supone una evolución en cuanto a los procesos de capacitación dentro de las organizaciones, teniendo en cuenta el uso adecuado de las tecnologías de usuario final (tecnologías inalámbricas y de acceso remoto, portátiles, tablets, etc.) de acuerdo con el requisito 12.2.1. El objetivo es reducir los riesgos al utilizar este tipo de dispositivos dentro del alcance de PCI DSS.
Definición:
12.10.4.1 La frecuencia de la capacitación periódica del personal de respuesta a incidentes es definida según 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:
La frecuencia con la que se realizan las formaciones periódicas del personal de respuesta ante incidentes viene dada por el resultado de la ejecución de un TRA de frecuencia por parte de la organización. El resultado del TRA de frecuencia debe definir la periodicidad con la que se debe realizar esta formación. La frecuencia sugerida por el PCI SSC en la guía de TRA, para tomar como referencia, es de 1 año o cuando nuevo personal es incorporado a la organización.
Definición:
12.10.5 El plan de respuesta a incidentes de seguridad incluye el monitoreo y la respuesta a las alertas de los sistemas de monitoreo de seguridad, incluyendo, pero no limitado a:
▶️ Sistemas de detección y prevención de intrusiones.
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, que incluye como parte del plan de respuesta ante incidentes la respuesta ante alertas generadas por los mecanismos de detección de cambios y manipulaciones en las páginas o formularios de pago.
Definición:
12.10.7 Existen procedimientos de respuesta a incidentes que se iniciarán cuando se detecten PANs almacenados en un lugar inesperado, e incluyen:
▶️ Determinar qué hacer si se descubren PANs fuera del CDE, incluyendo su recuperación, eliminación segura y/o migración al CDE actualmente definido, según corresponda.
Enfoque para la versión 4.0.1:
El objetivo del control es evolucionar el plan de respuesta ante incidentes definido, incluyendo procesos de respuesta ante la identificación de PANs almacenados en lugares inesperados. Como buena práctica, si se encuentran PANs fuera del CDE se debe analizar para:
▶️ Determinar si se guardaron independientemente de otros datos o con SAD.La fecha del 31 de marzo de 2025 marca un hito crucial en el cumplimiento de PCI DSS. A partir de esa fecha, varios controles, que hasta ahora solo eran considerados buenas prácticas o recomendaciones, se convertirán en requisitos obligatorios. Este cambio representa un desafío importante para las organizaciones, que deberán adaptarse a estas nuevas exigencias para garantizar la seguridad de los datos de tarjetas de pago y cumplir con el estándar.
En esta serie de artículos hemos analizado a fondo estos controles, proporcionando una explicación detallada de cada uno de ellos y el enfoque que aporta la versión 4.0.1 del estándar. Esta nueva versión no solo establece requisitos más estrictos, sino que también fomenta un enfoque más flexible y basado en el riesgo, permitiendo a las organizaciones adaptar sus controles a sus necesidades y características particulares, siempre que puedan justificar la efectividad de las soluciones adoptadas.
La implementación de estos nuevos controles no es solo una respuesta a las vulnerabilidades identificadas, sino también a amenazas cada vez más sofisticadas y complejas. Estos controles refuerzan la seguridad de los entornos PCI DSS y garantizan que las organizaciones estén mejor preparadas para enfrentar los retos de seguridad en un panorama de amenazas en constante evolución.
Desde la introducción de la versión 4.0, las organizaciones han tenido un tiempo progresivo para adaptarse a estos controles. Sin embargo, el 31 de marzo de 2025 representa la fecha límite para su implementación total y correcta, lo que subraya la importancia de planificar y ejecutar los cambios necesarios para cumplir con los requisitos del estándar.
A medida que nos acercamos a esta fecha crítica, es esencial que las organizaciones realicen una evaluación exhaustiva de sus sistemas y procesos actuales. Con una adecuada planificación y preparación, las organizaciones estarán en una posición más fuerte para afrontar estos desafíos y seguir cumpliendo con las mejores prácticas de seguridad en el futuro.
Referencias
Estándar PCI DSS v4.0.1:
https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf
Guía TRA PCI DSS v4.x:
https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Supporting%20Document/PCI_DSS_V4.x_TRA_Guidance.pdf
PCI DSS v4.0: Análisis de Riesgos Específico de Frecuencia
https://blog.isecauditors.com/pci-dss-v40-analisis-de-riesgos-especifico
Cómo gestionar el requisito 12.3.1 de PCI DSS v4.0 mediante FRA
https://blog.isecauditors.com/2023/10/como-gestionar-el-requisito-12-3-1-de-pci-dss-mediante-fra.html