En esta sexta entrega de la serie “Análisis de PCI DSS v4.0” se analizarán los requerimientos 10 y 11 del estándar PCI DSS v4.0. Estos requerimientos hacen parte del grupo 5. Regularly Monitor and Test Networks, que continua con el mismo nombre de la versión 3.2.1 del estándar.

El objetivo de estos dos requerimientos es garantizar la trazabilidad en el entorno de cumplimiento con el fin de detectar patrones maliciosos y servir como base en el caso de una investigación forense y validar que los niveles de seguridad del entorno continúan siendo aceptables a lo largo del tiempo.

Requerimiento 10: Log and Monitor All Access to System Components and Cardholder Data

El requerimiento 10 define los controles de seguridad necesarios para registrar las actividades que afectan a los componentes del sistema del entorno y a los datos del titular de tarjeta con el fin de identificar de forma proactiva cualquier evento sospechoso y poder realizar una investigación posterior a la ocurrencia de un incidente. Los elementos críticos que hacen parte de este requerimiento son los registros de eventos/auditoría (o logs) y su sincronización a nivel de tiempo, para garantizar la correcta correlación de actividades de todos los activos involucrados en un evento en particular.

Es importante aclarar que en la versión 4.0 de PCI DSS se excluyen de este requerimiento de forma explícita las actividades realizadas por los titulares de tarjeta (cardholders) y se incluyen las acciones realizadas por empleados, contratistas, consultores, proveedores internos y externos y cualquier otra entidad que tenga acceso o pueda afectar la seguridad del entorno.

En términos generales, este requerimiento no tuvo cambios relevantes más allá de una reorganización de controles y adición de algunas aclaraciones:

Gestión de registros de eventos (logs):

  • Se aclara que los registros de auditoría (logs) deben estar habilitados y activos para todos los componentes del sistema y datos del titular de tarjeta. Igualmente, se hace énfasis en que estos registros solamente deben contener la información requerida para su operación, evitando el almacenamiento de datos sensibles (req. 10.2.1).
  • A partir del 31 de marzo de 2025 la revisión de los registros de eventos (logs) se debe realizar empleando herramientas automatizadas . Este requerimiento responde a la necesidad de minimizar la interacción humana y su consiguiente tasa de error durante el proceso de revisión manual de logs.
  • Los periodos de revisión de los registros de eventos que no deben ser revisados diariamente (req. 10.4.1) se deben ajustar con base en un análisis de riesgos, de acuerdo con el requerimiento 12.3.1.

Todos los demás controles relacionados con logs (tipos de acciones a ser registradas, detalles de cada evento, centralización y protección de logs, tiempos de retención, etc.) no cambian en esta nueva versión.

Sincronización de tiempo:

Todos los controles relacionados con sincronización de tiempo no cambian en esta nueva versión.

Respuesta a fallos en sistemas de seguridad críticos:

  • A diferencia de PCI DSS v3.2.1 en donde se requería que solamente los proveedores de servicio realizaran acciones detectivas y correctivas ante cualquier falla crítica en sistemas de seguridad críticos, en PCI DSS v4.0 este requerimiento ha sido ampliado a todas las entidades afectadas por el cumplimiento de PCI DSS a partir del 31 de marzo de 2025 (req. 10.7.2) . Esto incluye no solamente la identificación y la generación de alertas del control de seguridad crítico afectado sino también la definición de actividades orientadas a la restauración del servicio afectado (req. 10.7.3). Estos controles introducen de forma sutil el concepto de disponibilidad (availability) dentro de los controles de PCI DSS, orientados tradicionalmente a la protección de la confidencialidad (confidentiality) y la integridad (integrity).

Triada de la seguridad de la información (CIA)

Requerimiento 11: Test Security of Systems and Networks Regularly

En términos generales, a lo largo del estándar PCI DSS se enumeran las acciones vinculadas con el ciclo de vida de los controles de seguridad para la protección de datos de tarjetas de pago: categorización de activos, selección e implementación (requerimientos 1, 2, 3, 4, 5, 6, 7, 8 y 9), monitorización (requerimiento 10) y evaluación (requerimiento 11). El objetivo de la fase de evaluación de controles es el de determinar hasta qué punto los controles se aplican correctamente, funcionan según lo previsto y producen el resultado deseado con respecto al cumplimiento de los requisitos del estándar. Todas estas acciones son cubiertas en el requerimiento 11 de PCI DSS.

Como resultado de la evolución en las técnicas de ataque y las vulnerabilidades de software, así como la masificación en el uso de plataformas en la nube (cloud), el requerimiento 11 ha incluido una serie de actualizaciones que permiten optimizar las actividades orientadas hacía la evaluación de los controles de seguridad exigidos por el estándar, entre las cuales se encuentran:

Redes inalámbricas:

  • Los procesos de identificación de redes inalámbricas deben detectar e identificar no solamente los puntos de acceso autorizados sino también los no autorizados (req. 11.2.1). La aplicabilidad de este control es extensiva tanto a organizaciones que permiten el uso de este tipo de tecnología en sus instalaciones como aquellas que lo prohíben por normativa.
  • El control asociado con los procedimientos de respuesta ante la identificación de puntos de acceso inalámbricos no autorizados (11.1.2 en PCI DSS v3.2.1) se movió al requerimiento 12.10.5 en PCI DSS v4.0.

Escaneos de vulnerabilidades internos:

  • Para escaneos de vulnerabilidades internos se aclara que la herramienta empleada debe estar actualizada con la información más reciente de vulnerabilidades (req. 11.3.1).
  • A diferencia de PCI DSS v3.2.1, las vulnerabilidades no categorizadas como críticas o de alto riesgo deben ser gestionadas de acuerdo con un análisis de riesgos y se deben ejecutar re-escaneos en caso de ser necesario (req. 11.3.1.1). Este control es aplicable a partir del 31 de marzo de 2025.
  • Probablemente uno de los cambios más relevantes en PCI DSS es el de la inclusión del concepto de “escaneos autenticados” (authenticated scanning). Este enfoque permite que los escaneos internos vayan más allá de la detección de vulnerabilidades desde el punto de vista de red y evolucione hacia la identificación de vulnerabilidades desde el punto de vista del activo (host), dando mayor visibilidad a los resultados e incorporando no solo las vulnerabilidades de los servicios publicados en redes de datos sino también del software local y su configuración. Para ello, la entidad debe establecer credenciales de autenticación con suficientes privilegios para que puedan ser usadas por la herramienta de escaneos. En el caso que el dispositivo no soporte autenticación, es necesario documentar esta excepción (req. 11.3.1.2). Este control es aplicable a partir del 31 de marzo de 2025.

Diferencias entre el escaneo de vulnerabilidades tradicional y el escaneo autenticado

Escaneos de vulnerabilidades externos:

Todos los controles relacionados con escaneos de vulnerabilidades externos no cambian en esta nueva versión.

Pruebas de penetración internas y externas:

  • Se aclara que:
    • Las pruebas desde el interior de la red (o «pruebas de penetración internas») significan pruebas desde el interior del CDE y hacia el CDE desde redes internas de confianza y no confiables.
    • Las pruebas desde el exterior de la red (o «pruebas de penetración externas») son las que se realizan en el perímetro externo expuesto de las redes de confianza y a los sistemas críticos conectados o accesibles a redes públicas.
    • Los reportes de las pruebas de penetración deben almacenarse al menos durante 12 meses.
  • Las vulnerabilidades explotables identificadas en este ejercicio deben ser corregidas de acuerdo con los niveles de riesgo definidos por la organización (req. 11.4.4).
  • En el caso de proveedores multi-tenant, estos proveedores deberán proveer evidencia a sus clientes de que las pruebas de penetración de su infraestructura han sido ejecutadas satisfactoriamente y facilitar a sus clientes la ejecución de sus propias pruebas (req. 11.4.7). Este control es aplicable a partir del 31 de marzo de 2025.

Sistemas de detección/prevención de intrusiones (IDS/IPS):

  • Para proveedores de servicio, los sistemas de detección o prevención de intrusiones deben ser capaces de detectar, alertar, prevenir y gestionar canales de comunicación encubiertos de malware (req. 11.5.1.1). Este control es aplicable a partir del 31 de marzo de 2025.

Protección contra cambios no autorizados en páginas de pago:

Probablemente uno de los controles más esperados en esta versión de PCI DSS era el control para la protección contra cambios no autorizados en páginas de pago. Con la escalada de ataques contra sitios web de comercio electrónico empleando digital skimmers (código malicioso desarrollado para permanecer oculto mientras captura y exfiltra datos sensibles en sitios web, siendo el equivalente digital a los skimmers físicos instalados en dispositivos POI y cajeros electrónicos), era cuestión de tiempo que el PCI SSC tomara cartas en el asunto, dado que este tipo de ataques no podía ser ni identificado ni gestionado con los controles de la versión 3.2.1 de PCI DSS.

En abril de 2017 el PCI SSC publicó el documento Information Supplement: Best Practices for Securing E-commerce. Este documento en su sección 7.7 “Best Practices for Securing e-Commerce” describía una serie de mejores prácticas entre las cuales se encontraba la revisión regular de cualquier enlace web (tales como URLs, iFrames, APIs, etc.) desde el sitio web del comercio hacia la pasarela de pago para confirmar que estos enlaces no habían sido alterados para redirigir el tráfico hacia ubicaciones no autorizadas. Aún así, estas acciones se quedaban cortas para mitigar los ataques de digital skimmers.

En PCI DSS v4.0 se ha incluido el control 11.6.1, en donde se requiere el despliegue de un control para detectar cambios y manipulaciones no autorizadas en páginas de pago. Estas soluciones deben alertar al personal interno en caso de modificaciones no autorizadas y su ejecución debe ser al menos cada 7 días o con una periodicidad basada en un análisis de riesgos de la entidad.

Este control (11.6.1) complementa el control 6.4.3 de PCI DSS v4.0 en donde se requiere de una verificación de los scripts cargados en los formularios de pago.

Referencias

¡Únete a la conversación! 1 Comentario

  1. hola,

    Para el tema de control (11.6.1) complementa el control 6.4.3, seria suficiente con instalar y usar una herramienta SBOM?

    11.6.1 – Se requiere el despliegue de un control para detectar cambios y manipulaciones no autorizadas en páginas de pago.
    6.4.3 – Se requiere de una verificación de los scripts cargados en los formularios de pago.

    Software Bill of Materials (SBOM) lista los companentes o scripts de la pagina, su version cuando fue modificada ysi tiene vulnerabilidades. con esta herramientas con alertas al SOC, y un procediemiento seria suficiente para cumplir con estos nuevo requerimientos, no?

    Responder

Deja un comentario

Categoría

Análisis de PCI DSS v4.0

Tags

, , , , , , ,