Novedades de PCI DSS en la Versión 4.0

El PCI SSC ha venido trabajando desde finales del 2019 en una actualización del estándar PCI DSS que nos trae una serie de actualizaciones y novedades que desde hace algún tiempo han venido pidiendo tanto los QSA como los comercios y proveedores de servicio con el ánimo de hacer más claros algunos requerimientos, generar nuevos lineamientos en temas que eran áreas grises y la actualización o evolución de algunos requisitos mínimos a la realidad actual. Todos estos cambios buscan atender los cambios en la evolución de los riesgos a los que están expuestos los datos de las tarjetas de pago en el mercado actual.

• Marzo 31 de 2022: la nueva versión se publica junto con los documentos de validación. También se publica contenido de apoyo para introducir esta nueva versión 4.0 (Blog y video). A partir de este momento inicia el periodo de transición en el que ambas versiones del estándar conviven.
• Junio 30 de 2022*: se publica la documentación de soporte e inicia la formación de los QSA en esta nueva versión. Todos aquellos QSAs que hayan recibido la formación y pasado el respectivo examen podrá realizar evaluaciones sobre la versión 4.0. En este periodo también está previsto realizar el PCI DSS v4.0 Global Symposium.
• Marzo 31 de 2024*: se retira la versión 3.2.1, es decir, finaliza el periodo de transición y a partir de este momento todas las evaluaciones deberán ser realizadas sobre la versión 4.0.
• Marzo 31 de 2025*: entrarán en vigor todos los nuevos requerimientos marcados para fechas futuras.

*Nota: estas fechas pueden ser cambiadas por el PCI SSC.

Al leer estos hitos aparece una inquietud en referencia a los requisitos nuevos que no tienen fechas futuras definidas para su aplicabilidad, en este caso todos estos requerimientos aplicarán si se lleva la evaluación con la versión 4.0 del estándar. Es decir, estos requerimientos serán efectivos a partir de la primera evaluación que se haga en la organización sobre la nueva versión del estándar. Para los nuevos requisitos con fecha de entrada en vigor en 2025, el PCI SSC recomienda encarecidamente que sean implementados lo antes posible con el objetivo de garantizar el máximo nivel de protección posible sin esperar a la fecha límite de entrada en vigor de su obligatoriedad.

En total, sobre la versión 4.0 de la norma PCI DSS, tenemos 64 nuevos requerimientos donde 51 serán aplicables a partir del 31 de marzo de 2025, es decir hay 13 requerimientos nuevos que serán aplicables en el momento en que se haga una evaluación con esta versión del estándar.

Desde el punto de vista de aplicabilidad de estos 64 nuevos controles, 53 serán aplicables a todas las entidades y tendremos 11 que son exclusivos para los proveedores de servicio. Es decir, los 64 nuevos controles aplicarán a los proveedores de servicio. Claro está que dependiendo del entorno de datos de tarjeta habrá algunos que no apliquen.

Algunas de las novedades más grandes que presenta el estándar son:

• Enfoque al riesgo
• Flexibilidad o facilidad de personalización
• Seguridad
• Autenticación
• Monitoreo
• Alcance
• Desarrollo de aplicaciones

Veamos cómo se encuentran en el nuevo estándar cada una de estas novedades.

Enfoque al riesgo

Muchos de los controles hacen referencia al análisis de riesgo para determinar la mejor vía de implementación de éstos. Algunos ejemplos de los temas que hacen referencia a estos análisis de riesgos dirigidos son:

• las frecuencias del escaneo del antivirus,
• la revisión de los POS/POI,
• la revisión de logs de los componentes no críticos,
• los algoritmos de cifrado,
• los enfoques personalizados,
• los riesgos del ambiente, entre otros.

Sin embargo, el análisis de riesgos (Requisito 12.2 de la versión 3.2.1) para todo el alcance ha sido removido para definir ahora análisis de riesgos dirigidos a temas específicos, esto se ve reflejado en el nuevo requisito 12.3.1 donde menciona que para los requisitos del Enfoque Definido donde se provea la flexibilidad de la frecuencia en que una tarea es ejecutada, se debe tener un análisis de riesgos dirigido al tema o control específico que defina la frecuencia como resultado. El análisis de riesgos debe contener los siguientes elementos:

• estar documentado;
• identificar los activos a ser protegidos;
• identificar las amenazas contra las cuales el requisito está protegiendo;
• identificación de los factores que contribuyen a la probabilidad y/o al impacto de que se materialice una amenaza;
• el análisis resultante debe determinar la justificación de la frecuencia con la que debe ejecutar el requisito para minimizar la probabilidad de que se materialice la amenaza;
• revisión al menos una vez cada 12 meses para determinar si los resultados siguen siendo válidos o si es necesario un análisis de riesgo actualizado;
• realización de análisis de riesgos actualizados cuando sea necesario, según se determine en la revisión anual.

Igualmente, en el nuevo requisito 12.3.2 se pide un análisis de riesgos para cada requisito donde se tome el Enfoque Personalizado, este análisis debe cumplir los siguientes requisitos:

• pruebas documentadas que detallen cada elemento especificado en el Apéndice D: Enfoque personalizado (incluyendo, como mínimo, una matriz de controles y un análisis de riesgos);
• aprobación de las pruebas documentadas por la alta dirección;
• actualización del análisis de riesgos específico al menos una vez cada 12 meses.

Flexibilidad o facilidad de personalización

La estructura de los controles incluye una definición del objetivo de este para lograr un enfoque personalizado logrando algunos objetivos adicionales:

• alargar la vida de los requerimientos frente a cambios del entorno y/o la industria;
• facilitar la implementación de metodologías o técnicas de implementación alternativas que cumplen con el objetivo de seguridad original.

Los nuevos controles ahora tienen los siguientes elementos:

• El Enfoque Definido de Requisitos y Procedimientos de Prueba describe el método tradicional para implementar y validar el cumplimiento del estándar utilizando los Requisitos y Procedimientos de Prueba definidos en la norma.
• El Objetivo del Enfoque Personalizado es la meta o el resultado previsto para el requisito. Debe ser cumplido por las entidades que utilizan un enfoque personalizado. La mayoría de los requisitos del estándar tienen definido este objetivo.
  El Apéndice D del estándar describe las expectativas para las entidades y los asesores (QSA) cuando se utiliza el Enfoque Personalizado.
  Las entidades que siguen el Enfoque Definido pueden referirse al Objetivo del Enfoque Personalizado como orientación, pero el objetivo no sustituye ni reemplaza al Requisito del Enfoque Definido.
  
  Cabe destacar que el enfoque personalizado está pensado para entidades que demuestren un enfoque robusto de gestión de riesgos, incluyendo, aunque sin limitarse a aquellas que tienen departamentos dedicados a la gestión de riesgos o un enfoque de gestión de riesgos en toda la organización.
  

• Las Notas de Aplicabilidad se aplican tanto al Enfoque Definido como al Enfoque Personalizado. Estas notas incluyen información que afecta al modo de interpretar el requisito en el contexto de la entidad o en la determinación del alcance.
  Las notas son parte integral del estándar y deben tenerse plenamente en cuenta durante una evaluación.
  En los controles nuevos que tienen una fecha futura de aplicación se definirá en esta nota la fecha a partir de la cual se deberá tener en cuenta como un requisito mandatorio.
• La Guía proporciona información para entender cómo se debe cumplir un requisito. Las orientaciones no son obligatorias es decir no sustituyen ni amplían ningún requisito del estándar, pero si apoyan en su interpretación.
  La sección de Guía tiene varias subsecciones que no necesariamente estarán presentes para cada requisito:
• El Propósito describe el objetivo, el beneficio o la amenaza que hay que evitar; la razón por la que existe el requisito.
• Una Buena Práctica es un ejemplo de tarea o control que puede ser considerada por la entidad al cumplir un requisito.
• Las Definiciones son los términos que pueden ayudar a entender el requisito en situaciones donde el requisito hace referencia a términos que pueden ser entendidos como genéricos y hace falta claridad sobre los mismos.
• Los Ejemplos describen algunas formas en que se podría cumplir un requisito.
• La Información Adicional incluye referencias a sitios, entidades y/o documentación externa que puede ayudar a complementar le implementación del control. En este punto es importante mencionar que, aunque la versión anterior hacía referencia en algunos casos a este tipo de referencias externas, en esta nueva versión las referencias se han extendido de manera importante y ahora incluye referencias a otras entidades como por ejemplo:
• ANSI (American National Standards Institute)
• CIS    (Center for Internet Security)
• CSA    (Cloud Security Alliance)
• ENISA (European Union Agency for Cybersecurity)
• FIDO Alliance (The FIDO Alliance)
• ISO (International Organization for Standardization)
• NCSC (The UK National Cyber Security Centre)
• NIST (National Institute of Standards and Technology)
• OWASP (Open Web Application Security Project)
• SAFEcode (Software Assurance Forum for Excellence in Code)

La siguiente imagen muestra un ejemplo de un control con los diferentes componentes que se acaban de mencionar:

Seguridad

Algunos controles se han vuelto más “duros” o “astringentes” con el propósito de subir los niveles de seguridad. A continuación, menciono algunos ejemplos, sin embargo, este endurecimiento se ve a través de todo el estándar.

En desarrollo de aplicaciones se incluyen nuevos controles para proteger los sitios web haciendo referencia a temas específicos como los IFRAME y los SCRIPTS que se manejan dentro de la página de pagos.

En referencia a las suites criptográficas y protocolos de cifrado se pide ahora que se mantenga un inventario de donde se usan y una revisión anual para determinar la viabilidad de seguir usando o no algunos de estos protocolos o suites de cifrado. Igualmente se pide tener una estrategia documentada de cómo se responderá de manera anticipada a cambios en las vulnerabilidades de la criptografía usada.

Las tecnologías usadas también deben ser revisadas cada 12 meses para asegurar que reciben parches y actualizaciones de seguridad por parte del fabricante y que le permiten a la organización mantener el cumplimiento del estándar. Igualmente se deben tener monitoreadas las fechas de fin de vida de las tecnologías junto con los planes de migración a tecnologías soportadas.

Autenticación

Se incluyen varios cambios y novedades:

• se pide acceso de autenticación multi-factor para todas las personas con acceso al CDE y no solamente a los administradores;
• la frecuencia de cambio de contraseñas para las cuentas de aplicación o servicio se define ahora por el análisis de riesgos;
• se adoptan las posturas de seguridad de las cuentas para poder hacer un balance entre longitud de contraseña contra la vida misma de ésta;
• se suben la longitud de las contraseñas mínimas.

Monitoreo

Se incluyen nuevos requerimientos para realizar de manera automatizada los procesos de detección de eventos de seguridad y fallas en los sistemas críticos mediante el análisis de los logs de auditoría.

Alcance

Se incluyen clarificaciones y ejemplos de la definición del alcance de los requisitos PCI DSS, incluyendo detalles como redes inalámbricas y proveedores de servicio entre otros.
Adicionalmente, se incluyen controles para la documentación de la definición del alcance que deberá ser revisada y actualizada al menos una vez al año o con cualquier cambio significativo, en el caso de los proveedores de servicio será cada seis meses o cuando ocurra un cambio significativo.

Desarrollo de aplicaciones

Es importante resaltar que además de hacer un refresco y endurecimiento sobre los controles (Requisitos 6.2 a 6.5) en el Apéndice F se hace referencia al apalancamiento que se debería tener en el nuevo estándar SSLC, esto significa que las aplicaciones deben ser desarrolladas de acuerdo con el requisito o apoyarse en proveedores certificados en el estándar SSLC.

Ya se tocó brevemente el tema de los SCRIPTS y los IFRAME, sin embargo, es importante mencionar en este apartado algunos detalles adicionales como son: se debe tener un inventario y control estricto sobre los SCRIPTS que se ejecutan en la aplicación de pago los cuales deben estar protegidos mediante mecanismos que prevengan la ejecución de scripts no autorizados y que no formen parte del proceso de pago. Igualmente, se debe controlar la fuente desde donde se cargan los IFRAME.

Se elimina la dependencia del TOP 10 de OWASP de hace muchos años con la que se construyó la norma originalmente y que existía en los requisitos 6.5.1 al 6.5.10, para incluir un requisito (6.2.4) que hace referencia a 5 grandes grupos de vulnerabilidades y deja un sexto grupo que hace referencia a los ataques a través de cualquier vulnerabilidad de “alto riesgo” identificados en el proceso de identificación de vulnerabilidades del requisito 6.3.1.

Otro cambio que llega es la formación que se le imparte a los desarrolladores de aplicaciones anualmente, la cual ahora deberá estar orientada o tener módulos relacionados con el lenguaje específico en el que trabaja el desarrollador.

Bibliografía

• Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, Versión 3.2.1, mayo 2018.
• Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, Versión 4.0, marzo 2022.
• Payment Card Industry (PCI) Software Security Framework, Secure Software Lifecycle Requirements and Assessment Procedures, Versión 1.1, febrero 2021.