En marzo de 2.022 salía a la luz la nueva versión del estándar PCI DSS, la versión 4.0 que sustituirá definitivamente a la 3.2.1 el 31 de marzo de 2.024.
La versión 4.0 de PCI DSS mantiene la estructura de los 12 requisitos pero trae consigo numerosos cambios que iremos analizando en este y otros artículos del blog. Las principales novedades (enfoque al riesgo, personalización de los subrequisitos, etc.) fueron analizadas en otro artículo del blog (Novedades de PCI DSS en la Versión 4.0), por lo que en esta serie de 6 artículos nos centraremos en los cambios introducidos por cada uno de los requisitos, haciendo énfasis en los principales cambios de contenido en los subrequisitos y obviando los cambios en la numeración o en la fusión/separación de requisitos.
Requisito 1: Install and Maintain Network Security Controls
El primer cambio dentro del requisito 1 lo tenemos en el nombre del propio requisito, cuyo nombre en la versión 3.2.1 era "Install and maintain a firewall configuration to protect cardholder data". El estándar deja claro que con el cambio de nombre se van a cubrir más sistemas que los firewalls y routers, incluyendo dispositivos virtuales, mecanismos de control de acceso basado en cloud, sistemas de virtualización, etc., que se encargarán de controlar el tráfico en las redes de las organizaciones.
Otro de los cambios es la diferenciación en la nomenclatura de los tipos de red, haciendo referencia a redes no confiables (Internet, conexiones dedicadas como las B2B mediante redes inalámbricas, redes de terceros, etc., redes corporativas fuera del entorno, etc., y redes confiables (redes dentro del scope de PCI DSS).
Los principales cambios en este requisito los mencionamos a continuación:
- 1.1.2. Definición de roles y responsabilidades. Los roles y responsabilidades correspondientes al requisito 1 (gestión de los controles de seguridad de red o NSC, configuración de los NSC, etc.) deberán ser formalmente asignados para garantizar que el personal es consciente de sus responsabilidades del día a día.
- 1.2.5. Todos los servicios, protocolos y puertos permitidos son identificados, aprobados y tienen definida una necesidad de negocio. En la versión 3.2.1 se solicitaba un listado de aquellos servicios, protocolos y puertos considerados inseguros. Con la nueva versión se va más allá, y se incluyen tanto aquellos considerados inseguros (subrequisito 1.2.6) como aquellos que no lo son.
- 1.2.7. Se deben revisar las configuraciones de los NSCs al menos cada 6 meses. Además de revisar cada 6 meses las reglas de todos los NSCs, se deberán revisar las configuraciones para asegurar que solo los servicios, protocolos y puertos son los que se han definido según las justificaciones de negocio documentadas en el requisito 1.2.5.
Otros cambios a tener en cuenta:
- 1.2.2. Los cambios en las conexiones de red y en las configuraciones de NSCs son aprobadas y gestionadas a través del proceso de control de cambios definido en el requisito 6.5.1. La nueva versión del estándar especifica que los cambios en estos sistemas tienen que incluir todo lo especificado en el requisito 6.5.1 (requisito 6.4.5 en la versión 3.2.1) de gestión de cambios, incluyendo:
- Razón y descripción del cambio.
- Documentación del impacto en la seguridad.
- Aprobación del cambio documenta por las partes autorizadas.
- Pruebas que verifiquen que el cambio no impacta de forma negativa en la seguridad.
- Procedimientos para gestionar fallos y volver a un estado seguro (pruebas de marcha atrás).
- 1.2.3. Gestión de los diagramas de red. Se añade un listado de buenas prácticas para la elaboración correcta de los diagramas de red que, aunque era una práctica ya solicitada tanto por los QSAs como por los documentos de evaluación, asegura un nivel de madurez adecuado de estos documentos. Los puntos cubiertos son:
- Establecer todas las localizaciones (data centers, instalaciones corporativas, proveedores cloud, etc.).
- Etiquetado de todos los segmentos de red.
- Inclusión de todos los controles que proveen segmentación incluyendo identificadores únicos (nombre del control, fabricante, modelo, versión) y de todos los componentes de sistema.
- Etiquetado de áreas fuera del scope.
- Un control de cambios (fecha de la última actualización y nombres de las personas que hacen y aprueban la actualización).
- Una leyenda explicativa.
- 1.2.4. Gestión de diagramas de flujo. Del mismo que en el punto anterior, la nueva versión añade un listado de buenas prácticas para el desarrollo eficaz de los diagramas de red teniendo en cuenta:
- Todos los flujos (autorización, establecimiento, etc.).
- Todos los canales de aceptación (card-present, card-not-present, e-commerce).
- Todos los tipos de datos recibidos/transmitidos.
- Los puntos de entrada y salida.
- Los lugares donde los datos de cuenta son transmitidos/procesados/almacenados (incluyendo si se almacenan en periodos de corta o larga duración).
- Fuente que proporciona los datos de cuenta (clientes, terceras partes, etc.) y cualquier entidad con la que se compartan datos de cuenta.
- Control de cambios (fecha de última actualización y nombres de las personas que hacen y aprueban la actualización).
- 1.2.6. Se definen y se implementan funciones de seguridad para todos los servicios, protocolos y puertos que se utilizan y son considerados inseguros, así como la mitigación del riesgo asociado. Se debe añadir al conjunto de funciones adicionales la mitigación de riesgos. Se tiene que comprender y aceptar por parte de la organización el riesgo por el uso de servicios, protocolos y puertos inseguros, justificar su utilización y definir e implementar las medidas adicionales de seguridad para reducir los riesgos introducidos en el entorno.
- 1.2.8. Los ficheros de configuración de los NSCs son protegidos contra accesos no autorizados y se mantienen consistentes con configuraciones de red activas. Además de proteger la consistencia como en la versión anterior, en esta se incluye la protección de los ficheros de configuración ante accesos no autorizados para evitar configuraciones no autorizadas en los ficheros de red almacenados.
Otro de los cambios con el que nos encontramos es la no obligatoriedad de implementar una DMZ (requisito 1.3.1 en la versión 3.2.1), aunque aparece como buena práctica en los requisitos 1.4.1 y 1.4.2 para la gestión de conexiones entre redes no confiables y servicios que la organización necesita tener disponibles al público, no se trata de un control de seguridad obligatorio en la versión 4.0.
Las variaciones de los demás requisitos no son consideradas significativas respecto a la versión anterior del estándar.
Requisito 2: Apply secure configurations to all system components
Del mismo modo que ocurría con el requisito 1, el requisito número 2 de la versión 4.0 cambia también su nombre ("Do not use vendor-supplied defaults for system passwords and other security parameters") ampliando el foco a la seguridad en las configuraciones a nivel general y no sólo a los parámetros por defecto, incluyendo la eliminación de software innecesario y funciones y cuentas innecesarias, y la deshabilitación o eliminación de servicios innecesarios.
Los principales cambios en este requisito los mencionamos a continuación:
- 2.1.2. Definición de roles y responsabilidades. Los roles y responsabilidades correspondientes al requisito 2 (configuración de sistemas, actualización de los estándares de configuración, etc.) deberán ser formalmente asignados para garantizar que el personal es consciente de sus responsabilidades del día a día.
- 2.2.1. Desarrollo, implementación y mantenimiento de estándares de configuración. Ya en la versión 3.2.1 se hacía referencia al desarrollo de guías de configuración para todos los sistemas del entorno. En la nueva versión se añade que sean actualizados los estándares de acuerdo a la identificación de nuevas vulnerabilidades y que se verifique su aplicación en todos los nuevos sistemas antes de su conexión al entorno de producción o inmediatamente después de instalarlo.
- 2.2.2. Gestión de las cuentas por defecto. Se eliminarán o deshabilitarán las cuentas por defecto que no vayan a ser utilizadas, pero podrán mantenerse aquellas que sí se utilicen cambiando la contraseña por defecto por una que cumpla con el requisito 8.3.6 (longitud mínima de 12 caracteres alfanuméricos).
- 2.2.3. Gestión de los niveles de seguridad de las funciones principales de los sistemas. Los sistemas deberán tener solamente una función principal (control existente en la versión 3.2.1), o las funciones principales con distintos niveles de seguridad que existan en un mismo componente serán aisladas de cualquier otro, o las funciones principales con diferentes niveles de seguridad en un mismo sistema serán configuradas de forma segura de acuerdo al nivel requerido por la función de más alto nivel de protección. De esta forma se permite una mayor flexibilidad en la configuración de los sistemas.
- 2.2.5. Gestión de servicios, protocolos o daemons inseguros. Además de incluir el añadir nuevas funciones de seguridad para reducir el riesgo por su utilización como señalaba la versión 3.2.1, la nueva versión del estándar incluye una justificación de negocio documentada para estos, así como la documentación de las nuevas funcionalidades.
- 2.3.2. Gestión de los cambios de las claves de cifrado WIFI. Se deben proteger las claves de cifrado de las comunicaciones inalámbricas cambiándolas cuando alguien con el conocimiento de la clave deje la compañía o su rol, o cuando se sospeche o se sepa que ha sido comprometida.
Otros cambios principales que recoge el requisito 2, pero de distinta índole, son los siguientes:
- Se elimina la validación de que la organización sea un proveedor de hosting compartido. Se incluye el contenido en otros requisitos.
- El inventariado de sistemas pasa al requisito 12 (12.5.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 1 y 2, siendo estos:
- Definición de roles y responsabilidades para ambos requisitos.
- Identificar y aprobar los servicios, protocolos y puertos seguros.
- Revisión de los NSCs de forma semestral.
- Gestión de los estándares de configuración.
- Protección de las cuentas por defecto necesarias.
- Gestión de los niveles de seguridad de las funciones principales de los sistemas.
- Gestión adecuada de servicios, protocolos o daemons inseguros.
- Protección de las claves de cifrado WIFI.
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.
Tal y como se ha mencionado en el artículo, la nueva versión del estándar va más allá y evita ciertas limitaciones de la versión 3.2.1 dentro de los requisitos 1 y 2, como es la inclusión de los NSCs o la mayor aplicabilidad de las configuraciones a todos los sistemas. Con la nueva versión se incluyen una serie de buenas prácticas que facilitan la interpretación de los requisitos y la madurez en los mismos (diagramas de red, diagramas de flujo, cambios en cuentas por defecto, etc.).
En el próximo artículo se analizarán los cambios en los requisitos 3 y 4 del estándar.
- 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: Diego de la Horra - CSFPC, PCIP, ISO 27001 L.A.
Dpto. Consultoría
