El PCI SSC publica el documento «Targeted Risk Analysis (TRA) Guidance» para PCI DSS v4.x
En noviembre de 2023 el PCI SSC publicó una nueva guía para soportar las actividades requeridas en PCI DSS v4.x. En esta ocasión, se trata del documento PCI DSS v4.x Targeted Risk Analysis Guidance (Análisis de Riesgo Dirigido, de acuerdo con la traducción oficial del estándar), que brinda las pautas necesarias para la definición de los periodos de ejecución de controles con frecuencia flexible o la identificación de riesgos cuando se usa el enfoque personalizado (Customized Approach).
Cambios en el enfoque del análisis de riesgos en PCI DSS v4.x
Uno de los cambios más relevantes introducidos en PCI DSS v4.0 – y probablemente uno de los más criticados – fue el de la aplicabilidad y el alcance de los análisis de riesgos. De acuerdo con el glosario del PCI SSC, un análisis de riesgos es un proceso que identifica los recursos críticos del sistema y sus amenazas, cuantifica la exposición a pérdidas basándose en las frecuencias y costes estimados de ocurrencia y (opcionalmente) recomienda cómo asignar recursos a las contramedidas para minimizar la exposición total.
En PCI DSS v3.2.1, se requería la realización de un análisis de riesgos anual o en cambios significativos, que empleara una metodología formal para la identificación de activos críticos, amenazas y vulnerabilidades. Este análisis debía cubrir toda la organización (enterprise-wide), por lo que en su alcance podrían estar activos fuera de PCI DSS, no relevantes desde el punto de vista de protección de datos de tarjetas de pago.
Debido a ello, en PCI DSS v4.0 el enfoque de este análisis de riesgos fue cambiado para focalizarse exclusivamente en el entorno PCI DSS y permitir cierta flexibilidad a la entidad para definir la periodicidad en la ejecución de determinados controles con base en el perfil de riesgo de su entorno. Este nuevo enfoque se denomina Targeted Risk Analysis (TRA), cuyo objetivo es:
- Determinar la justificación y la frecuencia con la que debe realizarse un control para minimizar la probabilidad de que se materialicen las amenazas identificadas sobre los activos de su alcance. Como mínimo, este análisis de riesgos debe revisarse cada 12 meses (12.3.1).
- Revisar y documentar la evidencia requerida cuando se usa el enfoque personalizado (Customized Approach) para cumplir con un control en particular. En este caso, se requiere de la aprobación documentada por parte de la Dirección y su ejecución debe ser cada 12 meses (12.3.2).
Análisis de riesgos en PCI DSS v3.2.1 y 4.0
PCI DSS v4.x y Targeted Risk Analysis (TRA)
Para aclarar las posibles dudas que pudieran surgir durante la implementación del TRA, el PCI SSC publicó en noviembre de 2023 el documento Information Supplement -Targeted Risk Analysis Guidance y una serie de plantillas para soportar el desarrollo de esta actividad:
| Tipo de Targeted Risk Analysis (TRA) | Descripción | Formularios asociados |
|---|---|---|
| Definición de periodicidad de ejecución de controles |
En este TRA, la entidad debe:
|
PCI DSS v4.x Sample Template: TRA for Activity Frequency |
| Uso del Enfoque Personalizado (Customized Approach) – Req. 12.3.2 |
En este TRA la entidad debe:
|
PCI DSS v4.x Sample Templates to Support Customized Approach |
Una vez establecidos los periodos de ejecución y los riesgos en el uso del enfoque personalizado, los formularios asociados serán revisados por el asesor QSA durante el proceso de evaluación de cumplimiento para comprobar que esta actividad se ha desarrollado conforme con el perfil de riesgo de la entidad.
Requerimientos afectados por Targeted Risk Analysis (TRA)
Adicionalmente, en el Information Supplement – Targeted Risk Analysis Guidance se incluye una lista de los controles de PCI DSS v4.0 afectados por TRA y sus respectivos periodos de ejecución con base en las recomendaciones del PCI SSC (solamente para referencia para la toma de decisiones):
| Requerimiento de PCI DSS v4.0 | Frecuencia sugerida |
|---|---|
| 5.2.3.1 The frequency for periodic evaluations for system components identified as not at risk for malware is defined in the entity’s targeted risk analysis. | Al menos una vez cada seis (6) meses |
| 5.3.2.1 If periodic malware scans are performed to meet Requirement 5.3.2, the frequency of scans is defined in the entity’s targeted risk analysis. | Al menos una (1) vez al día |
| 7.2.5.1 All access by application & system accounts and related access privileges are reviewed periodically (at the frequency defined in the entity’s targeted risk analysis). | Al menos una vez cada seis (6) meses |
| 8.6.3 Passwords/passphrases for application and system accounts are changed periodically (at the frequency defined in the entity’s targeted risk analysis). | Al menos una vez cada tres (3) meses |
| 9.5.1.2.1 The frequency of periodic POI device inspections and the type of inspections performed is defined in the entity’s targeted risk analysis. | Al menos una (1) vez cada mes |
| 10.4.2.1 The frequency of periodic log reviews for all other system components (not defined in Requirement 10.4.1) is defined in the entity’s targeted risk analysis. | Al menos una (1) vez cada semana |
| 11.3.1.1 All other applicable vulnerabilities (those not ranked as high-risk or critical per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are addressed based on the risk defined in the entity’s targeted risk analysis. | Media: Dentro de los primeros tres (3) meses
Baja: Dentro de los primeros seis (6) meses Informativa: Monitorizar regularmente |
| 11.6.1 A change- and tamper-detection mechanism is deployed to detect unauthorized modifications to HTTP headers and contents of payment pages, with the mechanism functions performed at least once every seven days OR periodically at the frequency defined in the entity’s targeted risk analysis. | Al menos una (1) vez cada semana |
| 12.10.4.1 The frequency of periodic training for incident response personnel is defined in the entity’s targeted risk analysis. | Al menos una (1) vez al año y al inicio del trabajo. |
Es importante aclarar que el TRA solamente puede ser usado en los controles de PCI DSS explícitamente identificados como tal. Si una entidad quiere ejecutar cualquier otro control con una periodicidad diferente a la establecida, aplican las siguientes restricciones:
- Si se quiere ejecutar un control con una periodicidad MAYOR a la establecida por el estándar (por ejemplo, ejecutar un control de forma mensual en vez de trimestral), esto se puede hacer sin problema, sin que sea necesario el uso de un TRA.
- Si se quiere ejecutar un control con una periodicidad MENOR a al establecida por el estándar (por ejemplo, ejecutar un control de forma trimestral en vez de mensual), se estaría incurriendo en un incumplimiento del control.
¿Tienes dudas adicionales respecto a la implementación del TRA? Déjanos tus preguntas en los comentarios.
Excelente, gran material