Cómo gestionar el requisito 12.3.1 de PCI DSS v4.0 mediante un FRA - Blog de Internet Security Auditors

Desde la publicación de la v4.0 del estándar PCI DSS, los nuevos requisitos incluidos (y que están detallados en el documento de resumen del cambio de v3.2.1 a v4.0: https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v3-2-1-to-v4-0-Summary-of-Changes-r2.pdf) se han dividido en dos grupos; por un lado aquellos que son obligatorios desde el momento que se alinea el entorno a la v4.0 y, por otro lado, aquellos que son recomendados, mejores prácticas o, como describe el estándar en su versión en español, "prácticas recomendadas" hasta el 31 de marzo de 2025, momento a partir del cual se convertirán en obligatorios. Este sería el caso del requisito 12.3.1 que vamos a analizar y para ello voy a tratar de responder a diversas cuestiones que considero fundamentales para entender el contexto y contenido de este requisito en concreto.

¿En qué consiste el requisito 12.3.1?

Su enunciado en español es el siguiente:

"Cada requisito 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..."

Esto quiere decir que, dentro del conjunto de requisito del estándar, hay un grupo de ellos que deben realizarse con una periodicidad (formaciones, evaluaciones, escaneos, revisiones, etc.) y estos requisitos en la v3.2.1 venían con una periodicidad máxima definida que la organización no podía superar, a menos que aplicara un control compensatorio (con un aporte de justificación técnica o de negocio asociada) al requisito, y ahora con la aplicación del requisito 12.3.1 dicha frecuencia pasará a calcularse en base a un análisis de riesgos específico (o dicho de otra forma, un análisis de riesgos de frecuencia - FRA). Adicionalmente, el requisito 12.3.1 recoge en 6 puntos una serie de características que debe contener como mínima el FRA que se aborde.

¿A que requisitos afecta el control 12.3.1?

Cada requisito que es afectado por el control 12.3.1, viene especificado en el propio estándar que la frecuencia debe definirse en base al FRA definido en el requisito 12.3.1, utilizando la coletilla similar a "…se realiza de acuerdo con todos los elementos especificados en el Requisito 12.3.1". A continuación, expongo la lista de todos los requisitos afectados:

• 5.2.3.1: La frecuencia de las evaluaciones periódicas de los componentes del sistema identificados como no en riesgo de malware.
• 5.3.2.1: Si se realizan escaneos periódicos de malware para cumplir con el requisito 5.3.2, la frecuencia de los escaneos.
• 7.2.5.1: La frecuencia de revisión de todos los accesos de aplicaciones y cuentas del sistema y los privilegios de acceso relacionados.
• 8.6.3: La frecuencia de cambio de las contraseñas/frases de paso para cualquier cuenta de aplicación y de sistema.
• 9.5.1.2.1: La frecuencia de las inspecciones a los dispositivos POI y el tipo de inspección que se realice.
• 10.4.2.1: La frecuencia de las evaluaciones periódicas de los componentes del sistema identificados (No definidos en el Requisito 10.4.1).
• 11.3.1.1: La aplicación (parcheado) de todas las demás vulnerabilidades aplicables (aquellas que no se clasifican como de alto riesgo o críticas (según las clasificaciones de riesgo de vulnerabilidad de la entidad definidas en el Requisito 6.3.1).
• 11.6.1: La frecuencia de aplicación de las funciones del mecanismo de detección de cambios y manipulaciones.
• 12.10.4.1: La frecuencia de la capacitación periódica del personal de respuesta a incidentes.

¿Qué debe incluir un FRA?

Como hemos comentado anteriormente, el requisito especifica 6 puntos obligatorios que debe cubrir el FRA, y que se pueden categorizar de la siguiente forma:

• Características del FRA
  • "Identificación de los activos a proteger": Se deben documentar todos los activos a proteger para incluirlos en el FRA. Debemos tener en cuenta que no son todos los activos del entorno, pues el texto especifica "activos a proteger", por lo que para una aproximación óptima, tomaremos en cuenta los activos del entorno de datos de tarjeta o "CDE" y no todos los activos del alcance o "scope". Para seguir optimizando este proceso, y que el FRA no tenga un tamaño excesivo y complejo de gestionar, bastará con identificar todas las tipologías de activos del CDE, es decir, si tenemos 10 servidores Linux iguales, no hará falta tener 10 activos, sino uno del tipo "servidor Linux".
  • "Identificación de las amenazas contra las que protege el requisito": Se deben identificar y documentar, al menos, las principales amenazas que son mitigadas al implementar el control. Es lógico pensar que, probablemente, diferentes controles protegerán un conjunto diferente de amenazas, por lo que éstas deberán ser identificadas de forma individual por cada requisito.
  • "Identificación de factores que contribuyen a la probabilidad y/o impacto de que se materialice una amenaza": Para cubrir este aspecto, el cual se puede abordar de varias formas, creemos que en una primera aproximación se podría describir con un texto los factores fundamentales que determinan el valor propio de probabilidad y/o impacto.
  • "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": Este punto será el resultado del propio análisis, el cual se habrá calculado un riesgo como producto de la multiplicación de impacto por probabilidad. Con el riesgo resultante se deberá determinar un valor de frecuencia en concreto que se aplicará al requisito analizado.
• Condiciones del FRA
  • "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": Se deberá crear una tarea dentro del calendario de actividades de PCI DSS que sea la revisión del FRA. Dicha tarea deberá tener una frecuencia máxima de 365 días entre intervalos. En cuanto a la revisión, deberá quedar constancia (mediante un control de cambios o histórico de versiones) en el informe del FRA que se ha realizado dicha revisión.
  • "Realización de análisis de riesgos actualizados cuando sea necesario, según lo determinado por la revisión anual":  Muy similar al punto anterior, pero esta vez se deberá realizar el FRA si ha existido algún cambio que provoque la actualización del mismo y sin tener que esperar a la revisión anual. Como el cambio no tiene por qué afectar a la totalidad de los nueve requisitos listados anteriormente, es importante observar las dos posibles situaciones que se pueden dar:
    • Se actualiza únicamente el riesgo del requisito o requisitos afectados por el cambio: En este escenario, se deberá hacer la revisión total del FRA según el calendario de tareas marcado para cubrir la revisión anual.
    • Se actualiza el riesgo del requisito o requisitos afectados y se revisan el resto de los requisitos, por lo que la tarea de revisión anual, se volverá a "poner a 0" o "iniciarse" y se tendrán otros 365 días como máximo hasta su nueva revisión.

Todos estos puntos son obligatorios que estén documentados y abordados como parte de la metodología definida del FRA y su propia ejecución. Dentro de la metodología, se pueden añadir puntos o acciones adicionales a las definidas en el propio requisito 12.3.1 (un ejemplo sería la identificación de las dependencias entre los activos).

¿Cómo implementar un FRA?

Para enfocar la tarea de implementación de un FRA tanto en la definición de su metodología, como en la realización y ejecución del propio FRA, se deberán tener en cuenta diferentes factores propios de la organización, así como su propia metodología y herramientas usadas internamente para desarrollar proyectos, si bien, abordaremos la implementación del FRA de manera que sea válido para el mayor número de organizaciones posibles, basándonos en nuestra experiencia y conocimientos de múltiples organizaciones ya certificadas PCI DSS.

Siempre que se implementa una tarea en un ambiente tecnológico, la recomendación es automatizarla al máximo posible para atacar dos aspectos fundamentales, por un lado, la estandarización de cara a evitar errores recurrentes, y por otro lado la dupla coste-eficiencia, pues los recursos tanto de tiempo como materiales suelen ser bastante limitados. Es por ello que, en este caso, se puede implementar el FRA mediante una hoja de cálculo sencilla, en la que estén claramente identificados los requisitos a los que se puede aplicar el FRA, los activos afectados en cada requisito, así como sus amenazas que provocan los valores de impacto y/o probabilidad según los factores que se describan. Tras implementar el cálculo sencillo mediante la fórmula estándar de riesgo = probabilidad x impacto, obtendremos un valor de riesgo, que nos deberá determinar una frecuencia concreta.

De esta forma, el mantenimiento del FRA a través de la hoja de cálculo, nos permitirá mantener un fácil mantenimiento del mismo, así como tener una trazabilidad del mismo. Hay que recordar, que lo recomendado sería tener un documento adicional en el que se explique la metodología y referencia a la hoja de cálculo que será la que soporte toda la operativa, si bien el formato de esta metodología puede ser variado o incluso incluirse en la propia hoja de cálculo a modo autoexplicativo.

Lo importante que deberá ser revisado para comprobar si se está alineado con el requisito 12.3.1 es que, cada uno de los cuatro puntos de las características del FRA más los dos puntos de las condiciones estén adecuadamente documentados ya que, de lo contrario, podrán provocar dudas a posibles revisores o auditores, así como que el resultado del FRA quede claro y conciso, sabiendo en todo momento que frecuencia aplicar a cada control.

¿Cómo se aplicaba la frecuencia en estos requisitos en la v3.2.1 del estándar?

El conjunto de requisitos anteriormente listado, en la v3.2.1 del estándar ya contaba con una frecuencia claramente definida (diario, semanal, mensual, trimestral, etc.) la cual no podía excederse salvo que se aplicara un control compensatorio.

¿Qué significa que sea “práctica recomendada” hasta el 31 de marzo de 2025?

Significa que su aplicación es opcional hasta el 31 de marzo de 2025, siendo recomendado aplicarlo lo antes posible ya que es una buena práctica de la industria.

Si la frecuencia es recomendada, ¿cada cuanto aplico o realizo lo contenido en el requisito?

Recordemos que la práctica recomendada es la realización del FRA, no la propia ejecución de la tarea que especifica el requisito, por lo que, si bien es opcional definir dicha frecuencia mediante un análisis de riesgos específico, la frecuencia debe existir de alguna forma, pues la tarea del requisito debe ejecutarse con una periodicidad. Es en este caso que lo más habitual o sencillo es que se tome como referencia la frecuencia ya definida en la v3.2.1 del estándar.

Otras partes del estándar a tener en cuenta

Cabe destacar el apartado 7 "Descripción de los Plazos Utilizados en los Requisitos PCI DSS" (página 25 y 28 del estándar en inglés y español respectivamente) del estándar, en el cual se resumen todos los plazos que se definen en los requisitos de PCI DSS, incluido el plazo de "periódicamente" y que afecta directamente al requisito comentado 12.3.1. Lo destacable de este texto es que define con claridad lo que se espera que realice una organización respecto a los plazos definidos, así como explicaciones de situaciones que pueden ocurrir respecto a las tareas y su calendario previsto, como retrasos en su ejecución o incumplimientos de estos y la implicación de incumplimiento del requisito si se ha debido a una mala gestión o falta de seguimiento.

Conclusiones

Este nuevo requisito 12.3.1 que implementa un nuevo concepto de análisis de riesgo específico para determinar la frecuencia o como hemos llamado de forma "acrónima" FRA. En la v3.2.1, todas las frecuencias que definía el estándar estaban claramente fijadas especificando el periodo (o incluso número de días) en el que se debía ejecutar. También contábamos en la v3.2.1 del estándar con el requisito 12.2 sobre el análisis de riesgos del entorno, el cual, tendía a quedarse en un mero formalismo con una practicidad en la organización limitada. Este nuevo enfoque con el FRA en conjunto con el TRA (análisis de riesgos dirigido para organizaciones que utilicen el enfoque personalizado), creo que aportan una mayor utilidad y precisión al uso de un análisis de riesgos en el entorno de datos de tarjeta para evaluarlo y protegerlo más eficientemente.

Por último, cabe señalar la importancia de una buena gestión y organización a la hora de implementar nuevos requisitos, contando con el soporte experto de consultores QSAs que puedan guiar en esta tarea que se suma a muchas otras tareas que se deben tener en cuenta en los entornos críticos involucrados en el tratamiento de los datos de tarjetas.

Biografía