La versión 4.0 del estándar PCI DSS ha introducido una serie de cambios respecto a la versión 3.2.1, los cuales ya han sido analizados en otros artículos del blog a nivel general (https://blog.isecauditors.com/2022/03/novedades-de-pci-dss-en-la-version-4.html) o a nivel de requisito en las series de artículos publicadas dentro del blog (https://blog.isecauditors.com/2023/09/version-4-de-pci-dss-analizando-requisitos-1-y-2.html).
En este artículo nos centraremos en uno de los aspectos clave como es la periodicidad de ejecución de ciertos requisitos de acuerdo a un Análisis de Riesgos Específico o TRA por sus siglas en inglés (Targeted Risk Assessment), obviando su utilización para el cumplimiento de los objetivos de los enfoques personalizados de los requisitos. Estos cambios han sido considerados como una evolución de los requisitos por parte del PCI SSC. En la versión 3.2.1, estos requisitos quedaban marcados por una periodicidad definida dentro del propio estándar.
Identificación de requisitos afectados
Los requisitos en los que el estándar no define una frecuencia mínima de cumplimiento son identificados dentro del estándar con un objetivo de cumplimiento periódico, a definir por la organización a través de un Análisis de Riesgos Específico que tiene que ser ejecutado por la entidad. Estos requisitos periódicos son los siguientes:
- 5.2.3.1. La frecuencia para la evaluación periódica de malware en sistemas que no son susceptibles de sufrirlo tiene que ser definida a través de un Análisis de Riesgos Específicos.
- 5.3.2.1. Si los escaneos periódicos de malware son realizados para cumplir con el requisito 5.3.2 (mantener una solución antimalware que esté activo y realice escaneos periódicos, o que haga escaneos en tiempo real; o bien que realice análisis de comportamiento de forma continua de los sistemas o procesos) tienen que tener una frecuencia de escaneo definida por el Análisis de Riesgos Específico.
- 7.2.5.1. Todos los accesos de cuentas de aplicación y sistema y sus privilegios de acceso tienen que ser revisados de forma periódica de acuerdo al Análisis de Riesgos Específico.
- 8.6.3. Las contraseñas o frases de paso (passphrases) para cuentas de aplicación y sistema son cambiadas de forma periódica según el Análisis de Riesgos Específico.
- 9.5.1.2.1. La frecuencia para la inspección periódica de dispositivos POI y el tipo de inspección realizada se define por un Análisis de Riesgos Específico.
- 10.4.2.1. La frecuencia de revisión de logs menos prioritarios (logs no incluidos dentro del requisito 10.4.1) tiene que realizarse en base a un Análisis de Riesgos Específico.
- 11.3.1.1. Las vulnerabilidades encontradas en los escaneos internos de vulnerabilidades con menos prioridad (aquellas no definidas como críticas o de riesgo alto según el requisito 6.3.1) tienen que ser gestionadas en base al riesgo definido en el Análisis de Riesgos Específico.
- 11.6.1. Los mecanismos de detección de cambios o tampering para detectar modificaciones no autorizadas en las cabeceras HTTP y en el contenido de las páginas de pago tienen que realizarse de forma semanal o de forma periódica de acuerdo con un Análisis de Riesgos Específico.
- 12.10.4.1. La frecuencia de la periodicidad en formaciones para el personal de respuesta ante incidentes es definida por un Análisis de Riesgos Específico.
Análisis de Riesgos Específicos de Frecuencia
Todos los requisitos señalados anteriormente hacen referencia al requisito 12.3.1 sobre la realización de los propios Análisis de Riesgos Específicos. La información que proporciona este requisito dentro del estándar es la siguiente:
Cada requisito de PCI DSS que proporciona flexibilidad sobre la frecuencia con la que se realizan (por ejemplo, los requisitos que deben realizarse periódicamente) está respaldado por un análisis de riesgo específico que está documentado e incluye:
- Identificación de los activos a proteger.
- Identificación de las amenazas contra las que protege el requisito.
- Identificación de factores que contribuyen a la probabilidad y/o impacto de que se materialice una amenaza.
- Análisis resultante que determine e incluya la justificación de la frecuencia con la que se debe realizar el requisito para minimizar la probabilidad de que se materialice la amenaza.
- Revisión de cada análisis de riesgo específico al menos una vez cada 12 meses para determinar si los resultados siguen siendo válidos o si se necesita un análisis de riesgo actualizado.
- Realización de análisis de riesgos actualizados cuando sea necesario, según lo determinado por la revisión anual.
La frecuencia de realización de estas tareas será documentada y quedará respaldada por la política de seguridad de la organización y el análisis de riesgos de la entidad, asegurando la validez y la consistencia con las políticas y procedimientos de seguridad. Esta frecuencia debe ser adecuada para que el requisito cumpla con su objetivo de manera efectiva.
El estándar señala la necesidad de que la organización tenga procesos documentados e implementados garantizando la ejecución de las actividades en un periodo razonable, incluyendo:
- La entidad recibe notificaciones de inmediato siempre que una de las actividades no haya podido llevarse a cabo según la planificación.
- La organización determina los eventos que han provocado el incumplimiento de una actividad programada.
- La entidad realiza la actividad tan pronto como sea posible reprogramando un nuevo calendario para su ejecución.
- La organización genera documentación que demuestre que ocurrieron los elementos anteriores.
Para cubrir con todos estos requisitos, este pasado mes de noviembre, el PCI SSC publicaba una guía para la realización de los Análisis de Riesgos Específicos, válidos tanto para definir la frecuencia de ejecución de los requisitos periódicos como para cubrir con los enfoques personalizados de los requisitos. Esta guía, junto con la plantilla publicada por el Council facilita la labor a las organizaciones para cumplir con los objetivos de los requisitos periódicos y poder definir de forma adecuada la frecuencia de ejecución a través de un Análisis de Riesgos.
La plantilla publicada puede ser utilizada por cualquier entidad para realizar sus propios Análisis de Riesgos Específicos o servir como base para la realización de unos documentos de acuerdo a su propia metodología. La plantilla publicada de ejemplo establece unos campos mínimos para cubrir con el objetivo de estos requisitos periódicos:
- Número del requisito afectado.
- Fecha del TRA inicial.
- Fecha de la revisión más reciente del TRA para confirmar que los resultados continúan siendo válidos.
- Identificación de los activos que son protegidos por este requisito. Ejemplos: Ficheros de logs, credenciales de acceso, activos susceptibles de sufrir malware, dispositivos POI, etc.
- Identificación de las amenazas por las que se ha definido dicho control. Ejemplos: Proteger ante accesos no autorizados, proteger ante malware, proteger ante el uso indebido de credenciales de acceso, proteger ante sustitución o tampering de dispositivos POI, etc.
- Identificación de los factores que contribuyen a aumentar la probabilidad y/o impacto de que la amenaza se materialice. Ejemplos: Exposición ante redes no confiables, complejidad de un entorno, rotación alta de personal, criticidad de los componentes del sistema, volumen y/o sensibilidad de los datos que van a ser protegidos, etc.
- Descripción del análisis y la justificación de la frecuencia de ejecución del requisito para minimizar la probabilidad de que se cumpla la amenaza.
- Si ha sido necesaria una actualización del análisis, indicar si se ha basado en una actualización anual.
- Indicar si existen políticas y procedimientos de seguridad definidos y documentados para la realización de los TRA de forma consistente.
El desempeño de un TRA que incorpora todos estos factores asegura la realización de una evaluación de riesgos robusta, comprensiva y consistente para cada uno de los activos a los que aplica.
Los Análisis de Riesgos Específicos no pueden ser utilizados para disminuir la frecuencia en la ejecución de requisitos marcados con una periodicidad fija dentro del estándar.
Recomendaciones de implantación
La guía publicada por el PCI SSC establece unos periodos recomendables para establecer las frecuencias relativas a cada uno estos controles. La lista de requisitos y la frecuencia asociada la podemos ver a continuación:
| Requisito PCI DSS | Frecuencia sugerida |
| 5.2.3.1 Revisión de malware en componentes que no son susceptibles de sufrir malware. | Al menos una vez cada 6 meses. |
| 5.3.2.1 Revisión de malware en componentes que son susceptibles de sufrir malware. | Al menos una vez al día. |
| 7.2.5.1 Revisión de privilegios de cuentas de aplicación y sistema. | Al menos una vez cada 6 meses. |
| 8.6.3 Cambio de contraseñas/passphrases en cuentas de aplicación y sistema. | Al menos una vez cada 3 meses. |
| 9.5.1.2.1 Inspección de dispositivos POI. | Al menos una vez cada mes. |
| 10.4.2.1 Revisión de logs no prioritarios. | Al menos una vez cada 7 días. |
| 11.3.1.1 Remediación de vulnerabilidades no prioritarias identificadas en los escaneos internos de vulnerabilidades. |
Medias: En 3 meses. Bajas: En 6 meses. Informacional: Monitorización regular. |
| 11.6.1 Revisión de la detección ante cambios y manipulaciones no autorizadas. | Al menos una vez cada 7 días. |
| 12.10.4.1 Entrenamiento del personal que responde ante incidentes. | Al menos una vez al año y después de contratación. |
Conclusiones
La flexibilización adoptada por la nueva versión del estándar con la definición de requisitos que tienen que ser ejecutados con una frecuencia periódica no definida aporta más versatilidad a la hora de cumplir con PCI DSS, pero también añade una serie de nuevas tareas a realizar para obtener la certificación de cumplimiento como es la realización de los TRA o Análisis de Riesgos Específicos para cada uno de estos requisitos.
A diferencia de la versión 3.2.1 del estándar, la cual se centra en la realización de un Análisis de Riesgo de forma general (incluso hay organizaciones que lo han realizado a nivel de organización y no específico para el entorno de PCI DSS), la versión 4.0 otorga una mayor importancia a la gestión y análisis de los riesgos, incorporando los Análisis de Riesgos como parte fundamental en la validación de la seguridad de un entorno al garantizar que las organizaciones realizan una valoración específica del riesgo en distintas áreas fundamentales cubiertas por el estándar (protección antimalware, cuentas de aplicación o sistema o dispositivos POI), cuyo resultado es utilizado dentro del marco de PCI DSS para establecer las frecuencias oportunas en cada uno de estos requisitos periódicos. Las organizaciones tendrán que presentar un TRA documentado por cada requisito aplicable que no tenga una frecuencia definida, siendo estos resultados documentados las evidencias a revisar por el respectivo QSA dentro de la certificación PCI DSS.
Aunque se trata de requisitos que son buenas prácticas hasta el día 31 de marzo de 2025, el PCI SSC ha querido proporcionar las herramientas necesarias a las organizaciones para ir incorporando los Análisis de Riesgos Específicos a la dinámica habitual de las organizaciones, publicando la guía y la plantilla sobre TRA, proporcionando una serie de ejemplos y frecuencias sugeridas que pueden servir de base a las entidades para la realización correcta de los distintos TRA.
Referencias
Estándar PCI DSS v4.0:
https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0.pdf
Resumen de cambios en la versión 4.0 respecto a la 3.2.1:
https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v3-2-1-to-v4-0-Summary-of-Changes-r2.pdf
Guía de Análisis de Riesgos Específico (TRA):
https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Supporting%20Document/PCI_DSS_V4.x_TRA_Guidance.pdf
Plantilla de Análisis de Riesgos Específico (TRA):
https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Reporting%20Template%20or%20Form/PCI-DSS-v4.x-Sample%20Template%20-TRA%20-Activity-Freq.pdf
Cómo gestionar el requisito 12.3.1 de PCI DSS mediante FRA:
https://blog.isecauditors.com/2023/10/como-gestionar-el-requisito-12-3-1-de-pci-dss-mediante-fra.html
Autor: Diego de la Horra - PCIP, ISO 27001 L.A.
Dpto. Consultoría
