Blog de Internet Security Auditors: PCI DSS v4.0 – Actualización SAQs

El estándar PCI DSS v3.2.1 ha sido actualizado a la v4.0 el pasado marzo de 2022 por lo que, actualmente, nos encontramos en un periodo de transición entre ambas versiones. Dicho periodo finalizará el 31 de marzo de 2024, momento en el cual la v3.2.1 será retirada y la v4.0 será la única activa.

Dentro de este período de transición, estaba previsto que en el Q1 de 2022 se lanzara oficialmente la v4.0, incluidos sus documentos de validación y, finalmente, en abril 2022 se publicaron dichos documentos. Entre los documentos disponibles en la biblioteca pública del PCI SSC (https://www.pcisecuritystandards.org/document_library/) para ser usados tanto por comercios, proveedores y empresas QSAC, es posible filtrar por aquellos relativos a los cuestionarios de autoevaluación o SAQs, que son los que analizaremos a continuación.

¿Cuáles son las principales diferencias en los SAQs de la v3.2.1 y la v4.0?

Cada SAQ se actualizó para reflejar los cambios en PCI DSS. Esto incluye requisitos actualizados para cada SAQ junto con orientación adicional sobre el uso de “Implementado con remediación” (In Place with Remediation) y “No aplicable”. Por lo tanto, por cada control de los requisitos del estándar, existen las siguientes posibilidades de estados:

• Implementado (In Place)
• Implementado con remediación (In Place with Remediation)
• Implementado con control compensatorio (In Place with CCW)
• No Aplicable (Not Applicable)
• No testado (Not Tested)  Opción solo disponible para SAQ D o RoC.
• No Implementado (Not in Place)

Al alinearse a la v4.0 de PCI DSS, cada SAQ cuenta con una afectación diferente dependiendo de los controles que tengan incluidos. Por ejemplo, para el SAQ A y el SAQ A-EP, un cambio sustancial es el nuevo requisito 6.4.3 sobre la gestión de scripts en los navegadores de los consumidores, ya que este es un nuevo requisito que no estaba reflejado en la v3.2.1 del estándar.

Respecto a los apartados de cada SAQ y AoC de SAQ, los cambios pueden resumirse en:

• El apartado 1 sobre Información de Contacto, ha sido rediseñado pero, fundamentalmente, cuenta con el mismo tipo de información:
  
  

  Apartado 1 de la sección 1 de un SAQ

   
  
• El apartado 2 también ha sido rediseñado, sobre todo el 2a y 2b, para reflejar de una forma más clara la información descrita. En el apartado 2e también se ha rediseñado para aunar todos los estándar del PCI SSC que puedan certificar algún tipo de producto, bien sea software o hardware, y que deben declararse en dicho apartado:
  
  

  Apartado 2a y 2b de la sección 1 de un SAQ

  
  

  Apartado 2e de la sección 1 de un SAQ

  
  
• Añadida la sección 3, en la que se detalla el resultado del atestado y la evaluación, en similitud con la misma sección en el documento del Atestado de Cumplimiento (AoC).

Cada SAQ también explica el enfoque personalizado, junto con el hecho de que este enfoque no se admite en los SAQ. Estos cambios aseguran que los SAQ estén alineados con las respectivas actualizaciones de RoCs y AoCs.

No sorprende que el SAQ D tenga la mayor cantidad de cambios. Tanto el SAQ D para comerciantes como el SAQ D para proveedores de servicios ahora permiten una evaluación parcial mediante el uso del estado "No probado" (Not Tested). Esto se refleja en todo el documento, con la opción de “Parcial” como tipo de evaluación que se agrega a la sección 3.

El SAQ D para proveedores de servicios tiene una sección adicional para detallar el entorno revisado. Esta nueva sección, la 2a, requiere datos que solo antes estaban en un ROC. Significa que los proveedores de servicios deben incluir en esta sección 2a lo siguiente:

• Un diagrama de red de su entorno de datos de tarjeta o CDE.
• Completar una tabla de datos de tarjeta con la siguiente información:
• Almacén de datos (Nombre de la base de datos, nombre del servidor de archivos, etc.).
• Nombre(s) de archivo(s), nombre(s) de tabla(s) y/o nombres del campo.
• Elementos de datos de tarjeta almacenados (por ejemplo, PAN, fecha de caducidad, nombre del titular, etc.).
• Cómo se protegen los datos (por ejemplo, qué tipo de encriptación y fortaleza es implementada, etc.).
• Cómo se registra o traza (logged) el acceso a los almacenes de datos (descripción del mecanismo de log utilizado para registrar el acceso a los datos; por ejemplo, describir la solución de la organización para la administración de registros o SIEM, el registro a nivel de aplicación, el registro del sistema operativo, etc., que este implementado).
• Completar una tabla de almacenamiento de datos sensibles de autenticación o SAD, que identifique todas las bases de datos, tablas y archivos que almacenan datos confidenciales de tarjeta (SAD) y proporcione los siguientes detalles:
• Almacén de datos (Nombre de la base de datos, nombre del servidor de archivos, etc.).
• Nombre(s) de archivo(s), nombre(s) de tabla(s) y/o nombres del campo.
• ¿Se almacena el SAD en la preautorización?
• ¿Se almacena el SAD como parte de las funciones del emisor?
• Cómo se protegen los datos (por ejemplo, qué tipo de encriptación y fortaleza es implementada, etc.).
• Completar una tabla con todos los tipos de componentes del sistema dentro del alcance (los "componentes del sistema" incluyen dispositivos de red, servidores, otros dispositivos informáticos, componentes virtuales, componentes de la nube y software, etc.). Para cada tipo de componente del sistema dentro del alcance, incluso si está incluido dentro de otro componente del sistema, se debe enumerar cada componente con diferentes roles, proveedores o marca/modelo/versión con la siguiente información:
• Tipo de componente del sistema (por ejemplo, aplicación, firewall, servidor, IDS, software antimalware, base de datos, etc.).
• Número total de componentes del sistema (se debe indicar cuántos componentes del sistema de este tipo están en el alcance).
• Fabricante.
• Nombre y versión del producto.
• Rol / Descripción de su función.
• Resultados de escaneos ASV trimestrales realizados en los últimos 12 meses, con la siguiente información:
• Fecha del/los escaneos.
• Nombre del ASV que realizó el escaneo.
• ¿Se encontraron vulnerabilidades que resultaron en un análisis inicial fallido?
• (En caso afirmativo) Para todos los escaneos que resulten en fallidos o “PCI FAIL”, proporcionar la(s) fecha(s) de los nuevos escaneos que muestran que las vulnerabilidades se han corregido.

¿Qué cambios se han incluido con la revisión 1 (r1) de Diciembre 2022?

En la publicación de la documentación liberada en abril 2022, como se ha comentado en el anterior punto, una de las características de los reportes de la v4.0 era la opción de “Implementado con remediación” (In Place with Remediation), la cual significaba que la organización estaba en cumplimiento con el control, si bien se había tenido que remediar durante la auditoría. El objetivo de este nuevo estado era promover la seguridad como un proceso continuo, proporcionado un elemento para identificar aquellos controles que necesitan mejoras año tras año. Sin embargo, tras recibir diversos comentarios de la industria, el PCI SSC ha decidido eliminar esta característica de validación cambiándola por una hoja de trabajo separada para que los auditores documenten la información sobre los controles que necesitan mejoras. Esta nueva hoja de trabajo, junto con alguna orientación adicional, como preguntas frecuentes y otro material de apoyo para ayudar a las organizaciones a comprender y usar dicha hoja de trabajo, estará disponible a principios de 2023.

Otro aspecto añadido ha sido la adición en la sección 3 del estado “Implementado con control compensatorio” (In Place with CCW). En caso de declarar algún control con este estado, se debe cumplimentar el Anexo B del propio SAQ.

Cabe destacar, que esta revisión 1 publicada en diciembre 2022, también incluyen algunas aclaraciones y correcciones de formato.

Referencias

• https://www.pcisecuritystandards.org/document_library
• https://blog.pcisecuritystandards.org/changes-to-pci-dss-v4-0-reporting-in-place-with-remediation
• https://www.pcisecuritystandards.org/faq/articles/Frequently_Asked_Question/How-do-I-contact-the-payment-card-brands/

Autor: Alberto Villar - PCI SSA, PCI QSA, CISSP, CSSLP, ISO 27001 L.A., CSFPC, SFPC
Dpto. de Consultoría