Nos encontramos en el post número 3 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 5 y 6.
Dando una visión general, los requisitos 5 y 6 pertenecen al conjunto "Mantain a Vulnerability Management Program" y se centran en elaborar y mantener un sistema de protección ante posibles vulnerabilidades y malware. Más concretamente, en proteger todos los sistemas, redes y softwares y mantenerlos libres de cualquier amenaza de forma proactiva.
En la versión 4.0 de PCI DSS, adquieren los siguientes nombres:
- Requirement 5: Protect All Systems and Networks from Malicious Software
- Requirement 6: Develop and Maintain Secure Systems and Software
A continuación, nos centramos en profundidad en cada uno de los requisitos.
Requisito 5: Protect All Systems and Networks from Malicious Software
El primer cambio significativo que encontramos en este requisito es el propio nombre del requisito. En la versión 3.2.1 de PCI DSS este requisito tenía el siguiente nombre: "Protect all systems against malware and regularly update anti-virus software or programs". Se puede apreciar que ya no solo se centra en los sistemas, sino que también incluye redes que puedan ser vulnerables a malware.
Otra diferencia importante en cuanto a terminología es la utilización de anti-malware en vez de anti-virus. Esto es debido a que, realmente, un virus solo es un tipo de malware que podría afectar a los sistemas y redes. En la siguiente imagen se puede observar diversos tipos de malware.
Entorno a los escaneos periódicos de malware, se añade el término "escaneo en tiempo real", el cual hace referencia a una exploración continua y constante. Es decir, cada vez que se realiza una acción sobre un fichero como podría ser, abrir el fichero, copiar un fichero o descargarlo, se escanea el archivo en busca de cualquier tipo de riesgo o amenaza.
Una vez comentadas las grandes novedades a nivel general del requisito, pasamos a los principales cambios internos producidos dentro del propio requisito:
- 5.1.2. Definición de roles y responsabilidades. Los roles y responsabilidades correspondientes al requisito 5 (configuración de soluciones anti-malware, realización de escaneos, procesos anti-phishing, etc.) deberán ser formalmente asignados para garantizar que el personal es consciente de sus responsabilidades del día a día.
- 5.2.3.1. Frecuencia de evaluaciones para componentes no afectados por malware. Este nuevo requisito pretende establecer la frecuencia para realizar las evaluaciones periódicas de todos los componentes del entorno que no sean susceptibles de sufrir cualquier tipo de malware. Esta frecuencia se establece de acuerdo con el requisito 12.3.1. (Buena práctica hasta el 31 de marzo de 2025).
- 5.3.2.1. Frecuencia de escaneos de malware. De igual forma que el requisito 5.2.3.1, este requisito busca establecer una frecuencia para los escaneos periódicos de malware. La frecuencia se establece de acuerdo con el requisito 12.3.1. (Buena práctica hasta el 31 de marzo de 2025).
- 5.3.3. Solución anti-malware para medios extraíbles. Este nuevo requisito ha surgido para proteger una vía de entrada de malware no contemplada en la versión anterior, los medios extraíbles. Se requiere realizar escaneos automáticos, o bien, análisis de comportamiento cuando un medio es insertado, conectado o montado lógicamente. (Buena práctica hasta el 31 de marzo de 2025).
- 5.4.1. Mecanismos anti-phishing. Este nuevo control, nos obliga a implementar mecanismos automatizados, incluso en componentes fuera del alcance PCI DSS (como un servidor de correo), que permitan a una organización detectar, proteger y mitigar los ataques de phishing. (Buena práctica hasta el 31 de marzo de 2025).
Otros cambios a tener en cuenta:
- 5.2.3. Componentes comúnmente no afectados por malware. El requisito ya se encontraba presente en la versión 3.2.1. En la nueva versión 4.0, se modifica el requisito para hacer referencia a componentes que no necesitan soluciones anti-malware en vez de anti-virus. También, en la nueva versión, añade la necesidad de hacer una evaluación para detectar los componentes que no son susceptibles de malware y crear una lista con todos ellos.
- 5.3.1. Actualización de la solución anti-malware. Este requisito surge de un requisito ya presente en la versión 3.2.1. En este nuevo requisito originado, especifica que las actualizaciones de las soluciones anti-malware deben ser automáticas.
- 5.3.2. Solución anti-malware. Además del nuevo término explicado anteriormente "escaneo en tiempo real", se añade la posibilidad de substituir los escaneos tradicionales por análisis continuos de comportamiento de los sistemas o procesos.
- 5.3.4. Logs provenientes de la solución anti-malware. De igual forma que en la versión 3.2.1 se pedía que la solución anti-virus generase logs de auditoría, se ha originado este requisito el cual nos pide que la solución anti-malware genere dichos logs conforme el requisito 10.5.1.
Requisito 6: Develop and Maintain Secure Systems and Software
De igual forma que el resto de los requisitos hasta el momento, el requisito 6 también ha sufrido una pequeña modificación del nombre en esta nueva versión 4.0. En la versión 3.2.1, aparecía este control con el siguiente nombre "Develop and maintain secure systems and applications". Se aprecia que ya no se centra únicamente en aplicaciones, sino que amplia más el alcance y va dirigido a todo el software en general. El propio council nos indica que este requisito aplica a todos los componentes excepto el requisito 6.2, que aplica a software personalizado o hecho a medida.
A continuación, se recogen los cambios más significativos:
- 6.1.2. Definición de roles y responsabilidades. Los roles y responsabilidades correspondientes al requisito 6 (desarrollo de software seguro, gestión de vulnerabilidades, control de cambios, etc.) deberán ser formalmente asignados para garantizar que el personal es consciente de sus responsabilidades del día a día.
- 6.3.2. Inventario de software. En la versión 4.0 se ha generado este nuevo control el cual nos exige tener y mantener actualizado un listado con todo el software a medida y personalizado, incluyendo componentes de terceros que se encuentren dentro del software. (Buena práctica hasta el 31 de marzo de 2025).
- 6.4.2. Automatización de amenazas en aplicaciones web públicas. Anteriormente, se daba la opción de efectuar evaluaciones ante vulnerabilidades y amenazas de forma manual o automática, o bien, instalar justo delante de una aplicación web una solución automática que detecte y prevenga ataques web, y así controlar el tráfico. Este nuevo requisito sustituirá todo esto y obligará a desplegar una solución técnica automatizada para aplicaciones web públicas que detecte y prevenga continuamente los ataques basados en la web. Por tanto, desparecerá la opción de realizar evaluaciones manuales o automáticas sobre la aplicación. (Buena práctica hasta el 31 de marzo de 2025).
- 6.4.3. Gestión de scripts de pago. En esta nueva versión de PCI DSS 4.0, se contempla la gestión y protección de los scripts utilizados en páginas de pago que se ejecutan en el navegador del consumidor. Se debe asegurar la integridad de los scripts, confirmar que son autorizados y mantener un inventario con los scripts utilizados y su justificación para el uso. (Buena práctica hasta el 31 de marzo de 2025).
- 6.5. Gestión de cambios. En referencia al control de cambios, se han agrupado todos los requisitos que tienen relevancia en el 6.5 (6.5.1 – 6.5.6). De igual forma, se observan diferencias respecto la versión anterior. Primeramente, ya no hacemos referencia a entornos de desarrollo/test, si no que se utiliza el término "preproducción", también se sustituye el término separación de funciones entre entornos por separación de roles y funciones para asegurar que solo se desplieguen los cambios aprobados. En el conjunto de los requisitos 6.5, se incluyen los cambios realizados a software hecho a medida o personalizado. Por último, se permite el uso de PANs reales (live PANs) en entornos de preproducción siempre que el entorno se incluya en el CDE y se proteja de acuerdo con PCI DSS.
Otros cambios a tener en cuenta:
- 6.2.1. El software a medida y personalizado se desarrolla de forma segura. Este requisito estaba presente en la versión anterior. En esta nueva versión se ha modificado el enunciado de software externo e interno por, a medida y personalizado. De esta forma se deja claro que no aplica a software de terceros, únicamente software desarrollado para o por la entidad para su propio uso (aplicable a todo el requisito 6.2).
- 6.2.2. Formación sobre desarrollo seguro. Para la formación, se ha clarificado de forma más precisa el contenido. Sigue siendo obligatorio realizarse anualmente, debe cubrir todos los lenguajes de programación utilizados y se debe añadir las herramientas a utilizar para la detección de vulnerabilidades.
- Revisión de código. En esta nueva versión 4.0 se ha separado el requisito de revisión de código en dos diferentes. En la versión 3.2.1, el requisito 6.3.2 ha sido separado en los requisitos 6.2.3 y 6.2.3.1 de la versión 4.0. Se ha decidido dividir el requisito para dar énfasis en caso de que se necesite una revisión general (6.2.3), o una revisión manual (6.2.3.1).
- 6.2.4. Vulnerabilidades comunes en programación. En la versión anterior teníamos un requisito por cada vulnerabilidad conocida. En esta nueva versión 4.0, se han reagrupado todas ellas en un único requisito más generalizado.
- 6.3.1. Identificación y gestión de vulnerabilidades. Se añade un punto a este requisito para dejar claro que se incluye las vulnerabilidades que afecten a código a medida, personalizado o de terceros.
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 5 y 6, siendo estos:
- Definición de roles y responsabilidades para ambos requisitos.
- Definición de la frecuencia de evaluaciones para componentes no susceptibles de malware.
- Definición de la frecuencia para escaneos de malware.
- Implantación de solución anti-malware para medios extraíbles.
- Despliegue de mecanismos anti-phishing.
- Necesidad de un inventario de software.
- Despliegue de una solución técnica automatizada para aplicaciones web públicas.
- Gestión de scripts de pago.
- Cambios en la gestión de cambios.
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 5 y 6 de la nueva versión del estándar PCI DSS, podemos comprobar que se han hecho mejoras a nivel de seguridad, como sería el cambio de un anti-virus por un anti-malware, que cubre más ampliamente todo el rango de amenazas que pueden aparecer actualmente, o la contemplación del phishing y mecanismos para proteger al personal ante ataques de este tipo. También, podemos observar que la nueva versión del estándar ha modificado terminologías o requisitos que podrían llegar a confusiones, como la separación clara de roles y funciones entre entornos de preproducción y producción, o la utilización de los términos de software a medida o personalizado.
En el siguiente artículo se analizarán los cambios en los requisitos 7 y 8 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
