Nos encontramos en post número 5 de una serie en la que estamos analizando más en profundidad cada uno de los cambios producidos en los requisitos de la versión 4.0 del estándar PCI DSS. En este post, nos centraremos en analizar los requisitos 10 y 11.
Para introducir los dos requisitos que se hablaran en este post, vamos a comentarlos brevemente.
Estos dos requisitos forman el conjunto llamado “Regularly Monitor and Test Networks”, el cual tiene como objetivo la monitorización del entorno PCI, además de probar el entorno para controlar el nivel de seguridad y posibles fallas por donde podría ser vulnerable nuestro entorno PCI. Así mismo, ayudan a que en caso de que se genere una amenaza se pueda detectar, generar un rastro y se pueda identificar adecuadamente.
En la versión 4.0 de PCI DSS, adquieren los siguientes nombres:
- Requirement 10: Log and Monitor All Access to System Components and Cardholder Data
- Requirement 11: Test Security of Systems and Networks Regularly
A continuación, nos centramos en profundidad en cada uno de los requisitos.
Requisito 10: Log and Monitor All Access to System Components and Cardholder Data
Igual que muchos otros requisitos, se ha modificado el título. En la versión 3.2.1 el requisito era llamado “Track and monitor all access to network resources and cardholder data”. Este cambio se ha realizado para dar más énfasis a los logs de auditoría, a los componentes y a los datos de titulares de tarjetas. Se cambia el término “Audit trails” por “Audit logs”.
Una vez comentadas las novedades generales del requisito, pasamos a los principales cambios internos producidos dentro del propio requisito:
- 10.1.2. Definición de roles y responsabilidades. Los roles y responsabilidades correspondientes al requisito 10 (implementar, revisar y proteger los logs de auditoría, configurar la sincronización de tiempo, etc.) deberán ser formalmente asignados para garantizar que el personal es consciente de sus responsabilidades del día a día.
- 10.4.1.1. Revisiones automatizadas de los registros de auditoría. Se genera este nuevo subrequisito dentro del 10.4. Este requisito consiste en la utilización de mecanismos automatizados para realizar la revisión de las pistas de auditoría. (Buena práctica hasta el 31 de marzo de 2025).
- 10.4.2.1. Frecuencia de revisión de pistas de auditoría para otros componentes. Para todos los componentes que no se encuentren definidos en el requisito 10.4.1 de la versión 4.0, el requisito 10.4.2 nos indica que se deben realizar revisiones periódicas de los registros de auditoría. Este nuevo requisito, nos dice que la frecuencia de las revisiones se debe definir en el análisis de riesgo especifico de la entidad y siguiendo los elementos indicados en el requisito 12.3.1.
- 10.7.2. – 10.7.3. Respuesta a fallas de seguridad en componentes críticos. Estos requisitos ya se encuentran presentes en la versión 3.2.1. En esta nueva versión 4.0, se modifican los requisitos para que aplique no únicamente a proveedores de servicio, sino que también, a cualquier entidad a la que le aplique el requisito. (Buena práctica hasta el 31 de marzo de 2025).
- 10.3.3. Backup de pistas de auditoría. Se combinan los requisitos 10.5.3 y 10.5.4 de la versión 3.2.1 en este requisito para agrupar en un solo requisito todas las tecnologías, incluidas las externas.
Requisito 11: Test Security of Systems and Networks Regularly
En este caso, el requisito también ha sufrido una pequeña modificación en el título. En la versión 3.2.1, podíamos ver el requisito bajo el título “Regularly test security systems and processes”, dejando claro que no solo se incluye sistemas y procesos, sino que también, las redes del entorno.
A continuación, vamos a repasar los cambios más significativos:
- 11.1.2. Definición de roles y responsabilidades. Los roles y responsabilidades correspondientes al requisito 11 (escaneos wifis, escaneos de vulnerabilidades, pentests, etc.) deberán ser formalmente asignados para garantizar que el personal es consciente de sus responsabilidades del día a día.
- 11.3.1.1. Vulnerabilidades no críticas o de bajo riesgo. Este requisito es una evolución de la versión anterior 3.2.1, para tratar todas aquellas vulnerabilidades que aun sin ser críticas o de alto riesgo (según la clasificación del requisito 6.3.1) suponen una amenaza a la entidad. El plazo para abordar estas vulnerabilidades se debe definir en el análisis de riesgo especifico acorde con el requisito 12.3.1. (Buena práctica hasta el 31 de marzo de 2025).
- 11.3.1.2. Escaneos de vulnerabilidades internas autenticados. Probablemente uno de los cambios más significativos con relación a los escaneos. Este requisito aplica únicamente a los componentes que puedan aceptar credenciales para realizar los escaneos, para aquellos que no acepten credenciales, deben estar definidos y documentados. Estos escaneos pueden estar basados en red o en host y para dichos accesos con credenciales, se debe tener el privilegio suficiente para realizar un análisis exhaustivo. (Buena práctica hasta el 31 de marzo de 2025).
- 11.4.1. Pruebas de penetración. Este requisito varía ligeramente respecto a la versión 3.2.1, pero las variaciones que encontramos las hemos consideradas importantes. En esta nueva versión, se añade un período de retención de 12 meses para los resultados de las pruebas de penetración. En las notas de aplicabilidad del requisito, encontramos las definiciones para las pruebas externas e internas:
- Realizar pruebas desde el interior de la red (o "pruebas de penetración interna") significa realizar pruebas tanto desde el interior del CDE como hacia el CDE proviniendo de redes internas confiables y no confiables.
- Pruebas desde fuera de la red (o pruebas de penetración "externas") significa probar el perímetro externo expuesto de redes confiables y sistemas críticos conectado o accesible a infraestructuras de redes públicas.
- 11.4.7. Pruebas externas Multi-tenant service providers. Este requisito ha surgido en la nueva versión 4.0 para que los proveedores de servicio multi-tenant den soporte a sus clientes para realizar las pruebas de penetración externas. Estos proveedores pueden cumplir el requisito de dos posibles formas, la primera realizando ellos mismos las pruebas acordes con los requisitos 11.4.3 y 11.4.4, y demostrando este cumplimiento a sus clientes, o bien, facilitando el acceso rápido para que los clientes puedan realizar sus propias pruebas externas. (Buena práctica hasta el 31 de marzo de 2025).
- 11.5.1.1. Malware encubierto. Este requisito aplica exclusivamente a los proveedores de servicio. Su finalidad recae en que los IDS/IPS implementados sean capaces de detectar, alertar/impedir y abordar todos los posibles canales de comunicación de malware encubierto. (Buena práctica hasta el 31 de marzo de 2025).
- 11.6.1. Cambios no autorizados en páginas de pago. Este requisito se origina debido a la necesidad de proteger las páginas de pago, que no estaba contemplado en la versión anterior 3.2.1. La finalidad del requisito es que a través de un mecanismo se puedan hacer evaluaciones y detectar cambios en las cabeceras HTTP y en el contenido en si de la página que recibe el consumidor. Estas evaluaciones se deben realizar cada siete días, o bien, de forma periódica según se defina en el análisis de riesgos acorde con el requisito 12.3.1. (Buena práctica hasta el 31 de marzo de 2025).
Otros cambios a tener en cuenta:
- 11.2.1. Escaneos Wifis. En este requisito ya presente en la versión 3.2.1, se le ha dado más énfasis para dejar claro que se trata de gestionar los puntos de acceso autorizados y no autorizados, así mismo, también aplica el requisito aun cuando las políticas de la entidad prohíban el uso de este tipo de redes.
- Escaneos frente a cambios significativos. En la versión 3.2.1 teníamos un único requisito que aplicaba tanto para escaneos externos como internos. En esta nueva versión 4.0 se ha dividido en dos requisitos, 11.3.1.3 para escaneos internos y 11.3.2.1 para los externos. Ambos requisitos mantienen la misma dinámica que en la versión 3.2.1. Un detalle a comentar es que, para los escaneos externos realizados tras un cambio significativo no se requiere el uso de un ASV (Approved Scanning Vendor) y tampoco eliminan la necesidad de realizar un escaneo cada 3 meses, es decir, si realizamos un escaneo producido por un cambio significativo, no será válido realizar otro después de 3 meses de realizar dicho escaneo si no que se tiene que seguir la periodicidad de los escaneos realizados por un ASV.
- 11.4.4 Corrección de amenazas encontradas. Este requisito lo podemos encontrar en la versión 3.2.1. En esta nueva versión 4.0, aclara que las vulnerabilidades explotables y debilidades de seguridad se deben corregir de acuerdo a lo definido en el requisito 6.3.1.
Conclusiones
La nueva versión del estándar ha introducido distintos cambios en todos los requisitos del estándar, algunos de mayor calado que otros. Se han analizado aquellos más importantes dentro de los requisitos 10 y 11, siendo estos:
- Definición de roles y responsabilidades para ambos requisitos.
- Automatización de las revisiones a los registros de auditoría.
- Frecuencia de revisión de registros para los componentes no definidos en el 10.4.1.
- Respuesta a fallas de seguridad.
- Vulnerabilidades no críticas o no consideradas de alto riesgo.
- Escaneos de vulnerabilidades autenticados.
- Retención de resultados en las pruebas de penetración.
- Proveedores de servicio Multi-tenant y pruebas de penetración externas.
- IDS/IPS con capacidad para detectar, alertar y mitigar malware encubierto.
- Integridad en las páginas de pago.
La aplicabilidad de estos cambios dependerá en gran medida del tipo de organización que vaya a ser evaluada, así como el impacto que pueda suponer la actualización del estándar, por lo que es recomendable ponerse en contacto con empresas especializadas para una implantación correcta de la nueva norma.
Tras analizar los requisitos 10 y 11, vemos de nuevo como en los demás requisitos que, el estándar ha generado mejoras y ha cubierto puntos no contemplados en la versión 3.2.1. La nueva versión 4.0 cubre posibles amenazas como sería la integridad de las páginas de pago, canales de comunicación para el malware encubierto y se centra en todas las vulnerabilidades halladas en los distintos escaneos y pruebas de penetración, y no solo las críticas y de alto riesgo. También, notamos mejoras a nivel de monitorización como podría ser la respuesta a fallas de seguridad tanto para proveedores de servicio como para las entidades que no lo son.
En el siguiente artículo se analizará los cambios en el requisito 12 del estándar.
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) Data Security Standard, Summary of Changes from PCI DSS Version 3.2.1 to 4.0, diciembre 2022.
Autor: David Sánchez
Dpto. de Consultoría
