Continuando con el análisis de los controles del estándar de PCI DSS versión 4.0.1 que son obligatorios a partir del 31 de marzo de 2025 , en esta segunda parte vamos a detallar los controles que dejan de ser buenas prácticas a partir de esa fecha y que van desde el requisito 7 (incluido) hasta el requisito 10 (incluido).

Requisitos que dejan de ser buenas prácticas el 31 de marzo de 2025

Requisito 7.2.4:

Definición:

7.2.4 Todas las cuentas de usuario y los privilegios de acceso relacionados, incluyendo las cuentas de terceros/proveedores, se revisan de la siguiente manera: 

• Al menos una vez cada seis meses. 
• Para asegurarse de que las cuentas de usuario y el acceso sigan siendo apropiados según la función del trabajo. 
• Se aborda cualquier acceso inadecuado. 
• La gerencia reconoce que el acceso sigue siendo apropiado. 

Enfoque para la versión 4.0.1:

La nueva versión del estándar refleja la necesidad de revisar las cuentas de usuarios, así como sus privilegios, detectando usuarios que no son necesarios en el entorno, usuarios que tendrían que haber sido dados de baja o usuarios con privilegios excesivos.

Requisito 7.2.5:

Definición:

7.2.5 Todas las aplicaciones y cuentas del sistema y los privilegios de acceso relacionados se asignan y administran de la siguiente manera: 

• Basado en los privilegios mínimos necesarios para la operatividad del sistema o aplicación.
• El acceso está limitado a los sistemas, aplicaciones o procesos que específicamente requieren su uso. 
  

Enfoque para la versión 4.0.1:

Del mismo modo que con la nueva versión del estándar se tienen que revisar las cuentas de usuario y los privilegios asociados, se debe hacer una revisión de las cuentas de sistema y aplicación, también conocidas como cuentas de servicio, así como de sus privilegios, para confirmar que los privilegios que tienen son los necesarios para la realización de su tarea, y que el acceso está limitado a aquellos sistemas, aplicaciones o procesos que requieren su uso.

Se entiende como cuentas de aplicación, de sistema o de servicio aquellas cuentas que ejecutan procesos o realizan tareas en un sistema informático o aplicación, normalmente con privilegios elevados para poder llevar a cabo las acciones especializadas y que no son utilizadas por individuos.

El estándar señala como buenas prácticas el establecer una base de referencia al configurar este tipo de cuentas, que incluya:

• Asegurarse de que la cuenta no sea miembro de un grupo privilegiado como administradores de dominio, administradores locales o root.
• Restringir en qué computadoras se puede usar la cuenta.
• Restricción de las horas de uso.
• Eliminar cualquier configuración adicional como acceso VPN y acceso remoto.
  
  

Requisito 7.2.5.1:

Definición:

7.2.5.1 Todo el acceso de aplicaciones y cuentas del sistema y los privilegios de acceso relacionados se revisan de la siguiente manera: 

• Periódicamente, (a una frecuencia definida en el análisis de riesgos específico de la entidad, el cual se desarrolla de acuerdo a todos los elementos especificados en el Requisito 12.3.1.).
• El acceso a la aplicación/sistema sigue siendo apropiado para la función que se está realizando.
• Se aborda cualquier acceso inadecuado.
• La gerencia reconoce que el acceso sigue siendo apropiado. 

Enfoque para la versión 4.0.1:

La revisión de los accesos de cuentas de sistema, aplicación o servicio debe realizarse de forma periódica de acuerdo con la frecuencia definida como resultado del TRA de frecuencia ejecutado por la organización. La revisión periódica de los derechos de acceso de estas cuentas favorece la detección de derechos de acceso excesivos. La frecuencia sugerida por el PCI SSC en la guía de TRA, para tomar como referencia, es de 6 meses.

Requisito 8.3.6:

Definición:

8.3.6 Si las contraseñas/frases de paso se utilizan como factores de autenticación para cumplir el requisito 8.3.1, estas deberán cumplir el siguiente nivel mínimo de complejidad: 

• Una longitud mínima de 12 caracteres (o SI el sistema no admite 12 caracteres, una longitud mínima de ocho caracteres).
• Contener tanto caracteres numéricos como alfabéticos. 

Enfoque para la versión 4.0.1:

Aunque la versión 3.2.1 ya incluía que las contraseñas o frases de paso tuvieran que contener caracteres alfanuméricos y una longitud mínima, la versión 4.0.1 incluye un aumento en esta longitud, pasando a ser de 12 caracteres, siempre que sea posible esta configuración. En caso de que no sea posible esta configuración, la longitud mínima debe ser de 8 caracteres.

Este requisito no aplica a cuentas de usuario en terminales punto de venta que sólo tienen acceso a un número de tarjeta simultáneamente para procesar una única transacción ni a cuentas de sistemas, aplicaciones o servicios ya que se rigen por los requisitos de la sección 8.6.

Requisito 8.3.10.1:

Definición:

8.3.10.1 Requisito adicional sólo para proveedores de servicios: Si las contraseñas/frases de paso se utilizan como el único factor de autenticación para el acceso del usuario del cliente (es decir, en cualquier implementación de autenticación de factor único), entonces: 

• Las contraseñas/frases de paso se cambian al menos una vez cada 90 días,
  
  O
• La postura de seguridad de las cuentas se analiza dinámicamente y el acceso a los recursos en tiempo real se determina automáticamente de acuerdo a dicha postura. 

Enfoque para la versión 4.0.1:

La versión 3.2.1 ya contemplaba que las contraseñas o frases de paso fueran cambiadas, al menos, una vez cada 90 días. El principal cambio con la versión 4.0.1 radica en su aplicabilidad, ya que solo aplica a cuentas de usuario de cliente que solamente utilizan contraseñas o frases de paso como único factor de autenticación para el acceso.

El otro cambio está en la periodicidad del cambio de estas contraseñas, pudiendo analizar de forma dinámica la postura de seguridad de estas cuentas, así como el acceso a los recursos en tiempo real. Estos análisis pueden incluir la integridad del dispositivo, la ubicación, el número de accesos y los recursos a los que se accede, etc., pudiendo denegar y bloquear el acceso de estas cuentas en tiempo real. 

Este requisito no se aplica a las cuentas de los usuarios consumidores que acceden a la información de sus propias tarjetas de pago.

Requisito 8.4.2:

Definición:

8.4.2 Los MFA se implementan para todos los accesos sin consola al CDE.

Enfoque para la versión 4.0.1:

Los accesos sin consola al CDE requieren de MFA, más allá de los accesos administrativos, como se contemplaba para la versión 3.2.1 y que recoge el requisito 8.4.1.

Requisito 8.5.1:

Definición:

8.5.1 Los sistemas MFA se implementan de la siguiente manera:

• El sistema MFA no es susceptible a ataques de repetición.
• Los sistemas MFA no pueden ser omitidos por ningún usuario, incluyendo los usuarios administrativos, a menos que esté específicamente documentado y autorizado por la administración de manera excepcional durante un período de tiempo limitado.
• Se utilizan al menos dos tipos diferentes de factores de autenticación.
• Se requiere el éxito de todos los factores de autenticación antes de que se otorgue el acceso.

Enfoque para la versión 4.0.1:

La versión 4.0.1 del estándar añade una serie de controles adicionales a tener cuenta enfocados en la protección de los sistemas MFA, incluyendo controles contra ataques de repetición. El estándar señala algunos ejemplos de métodos para ayudar a proteger contra estos ataques:

• Identificadores de sesión y claves de sesión únicos.
• Marcas de tiempo.
• Contraseñas o códigos de un solo uso basados en tiempo.
• Mecanismos anti-repetición que detectan y rechazan intentos de autenticación duplicados.

Requisito 8.6.1:

Definición:

8.6.1 Si las cuentas de sistema o aplicación pueden ser utilizadas para el inicio de sesión interactivo, se gestionan de la siguiente manera: 

• Se impide el uso interactivo a menos que se requiera por una circunstancia excepcional.
• El uso está limitado al tiempo necesario para la circunstancia excepcional.
• La justificación de negocio para su uso está documentada.
• El uso interactivo está explícitamente aprobado por la dirección.
• La identidad del usuario individual se confirma antes de que se conceda el acceso a una cuenta.
• Cada acción realizada es atribuible a un usuario individual 

Enfoque para la versión 4.0.1:

Debe protegerse el acceso interactivo de las cuentas de sistema, aplicación o servicio, limitando su utilización para acciones excepcionales y garantizando la trazabilidad de las acciones llevadas a cabo por estas cuentas, pudiendo identificar a los usuarios individuales que las utilizan. 

Requisito 8.6.2:

Definición:

8.6.2 Las contraseñas/frases de paso para cualquier cuenta de aplicación y de sistema que puedan ser utilizadas para el inicio de sesión interactivo no están codificadas en scripts, archivos de configuración/propiedades, o código fuente a la medida y personalizado.

Enfoque para la versión 4.0.1:

Las contraseñas o frases de paso utilizadas por cuentas de aplicación o sistema, también conocidas como cuentas de servicio, que puedan utilizarse para logins interactivos, no pueden estar hardcodeadas en scripts, ficheros de configuración o de propiedades, o en código fuente hecho a medida y personalizado. El almacenamiento de estas contraseñas o frases de paso tiene que protegerse de acuerdo a lo especificado en el requisito 8.3.2, es decir, a través de criptografía robusta para mantener esta información ilegible. Para ello, pueden utilizarse vaults o bóvedas de contraseñas u otros controles gestionados por el sistema.

Requisito 8.6.3:

Definición:

8.6.3 Las contraseñas/frases de paso para cualquier cuenta de aplicación y de sistema están protegidas contra el uso indebido de la siguiente manera:

• Las cuentas de sistema y de aplicación se cambian periódicamente, (a una frecuencia definida en el análisis de riesgos específico de la entidad, el cual se desarrolla de acuerdo a todos los elementos especificados en el Requisito 12.3.1.) y ante la sospecha o la confirmación de que estén comprometidas.
• Las contraseñas/frases de paso se construyen con la complejidad necesaria y apropiada para la frecuencia con la que la entidad cambia las contraseñas/frases de paso.

Enfoque para la versión 4.0.1:

La versión 4.0.1 añade un nuevo control para las cuentas de sistema, aplicación o servicio, enfocado en la protección de las contraseñas o frases de paso que tienen estas cuentas, las cuales deben tener una complejidad apropiada para la frecuencia con la que son cambiadas. Esta periodicidad de cambio de contraseñas para estas cuentas viene basada en la ejecución de un TRA de frecuencia. El resultado de la ejecución debe determinar la frecuencia con la que son cambiadas estas contraseñas o frases de paso. La frecuencia sugerida por el PCI SSC en la guía de TRA, para tomar como referencia, es de 3 meses.

Algunos de los factores a tener en cuenta señalados por el propio estándar son los siguientes:

• ¿Qué tan seguro es el almacenamiento de las contraseñas/frases de acceso? (por ejemplo, si se almacenan en una bóveda de contraseñas).
• Rotación del personal.
• El número de personas con acceso al factor de autenticación.
• Si la cuenta puede utilizarse para inicio de sesiones interactivas.
• Si la postura de seguridad de las cuentas es analizada dinámicamente, y el acceso en tiempo real a los recursos se determina automática y consecuentemente (ver el Requisito 8.3.9).

Otras pautas señaladas por el estándar como buenas prácticas son las siguientes:

• Considerar un tiempo de vida de la contraseña de 1 año.
• Longitud de 15 caracteres alfanuméricos con mayúsculas y minúsculas, además de caracteres especiales.

Requisito 9.5.1.2.1:

Definición:

9.5.1.2.1 La frecuencia de las inspecciones a los dispositivos POI y el tipo de inspección que se realice se define en el análisis de riesgos específico de la entidad, que se realiza de acuerdo con todos los elementos especificados en el Requisito 12.3.1.

Enfoque para la versión 4.0.1:

La frecuencia con la que se inspeccionan los dispositivos POI (Point of Interaction) por parte de las organizaciones tiene que venir definida de acuerdo con el del TRA de frecuencia ejecutado por la organización. Esta revisión periódica reduce el riesgo de alteración o sustitución de dispositivos POI en el entorno. La frecuencia sugerida por el PCI SSC en la guía de TRA, para tomar como referencia, es de 1 mes.

Requisito 10.4.1.1:

Definición:

10.4.1.1 Se utilizan mecanismos automatizados para realizar revisiones de los registros de auditoría.

Enfoque para la versión 4.0.1:

La gestión de registros de auditoría toma un nuevo enfoque en las nuevas versiones del estándar. Este enfoque se apoya en lo señalado por el requisito 10.4.1.1, que tiene como principal objetivo el facilitar la revisión de estos registros mediante la configuración de herramientas SIEM que permiten la automatización de las revisiones a través de baselines que incluyen parámetros normales de actividad, pudiendo identificar eventos revisables por parte del personal. El análisis de la actividad con respecto a las baselines puede mejorar la identificación de actividades sospechosas o anómalas, reduciendo la carga de las personas encargadas de la revisión de los registros de auditoría.

La configuración de las herramientas y la actualización de baselines tiene que realizarse de forma periódica para reflejar cualquier cambio en los eventos a revisar, parámetros normales de actividad, etc., asegurando que se hace una gestión adecuada y efectiva de los registros de auditoría.

Requisito 10.4.2.1:

Definición:

10.4.2.1 La frecuencia de las evaluaciones periódicas de los componentes del sistema identificados (No definidos en el Requisito 10.4.1) se define en el análisis de riesgo específico de la entidad, el cual se realiza de acuerdo con todos los elementos especificados en el Requisito 12.3.1.

Enfoque para la versión 4.0.1:

La frecuencia con la que se revisan los registros de auditoría no contemplados en el requisito 10.4.1 debe basarse en el resultado obtenido de la ejecución de un TRA de frecuencia por parte de la organización. La frecuencia sugerida por el PCI SSC en la guía de TRA, para tomar como referencia, es de 7 días.

Requisito 10.7.2:

Definición:

10.7.2 Las fallas de los sistemas de control de seguridad críticos se detectan, alertan y abordan con prontitud, incluidas, entre otras, las fallas de los siguientes sistemas de control de seguridad críticos:

• Controles de seguridad de la red
• IDS/IPS
• Cambiar los mecanismos de detección
• Soluciones antimalware
• Controles de acceso físico
• Controles de Ingreso lógico
• Mecanismos de registro de auditoría
• Controles de segmentación (si se utilizan)
• Mecanismos de revisión del registro de auditoría.
• Herramientas de prueba de seguridad automatizadas (si se utilizan).

Enfoque para la versión 4.0.1:

Este requisito está basado en el requerimiento 10.7.1, al que reemplazará, y que era una continuación del que aparecía en la versión 3.2.1. Este requisito incluye una serie de fallas en los sistemas de control de seguridad críticos que deben ser monitorizadas y a las que hay que responder de forma rápida y eficiente. A estas fallas se incluyen otras nuevas como:

• Cambiar los mecanismos de detección.
• Mecanismos de revisión del registro de auditoría.
• Herramientas de prueba de seguridad automatizadas (si se utilizan).

Requisito 10.7.3:

Definición:

10.7.3 Las fallas de cualquier sistema de control de seguridad crítico se responden con prontitud, incluidas, entre otras, las siguientes:

• Restaurando las funciones de seguridad.
• Identificando y documentando la duración (fecha y hora de principio a fin) de la falla de seguridad.
• Identificando y documentando las causas de las fallas y documentando el remedio requerido.
• Identificando y abordando cualquier problema de seguridad que surgió durante la falla.
• Determinar si se requieren más acciones como resultado de la falla de seguridad.
• Implementar controles para evitar que se repita la causa de la falla.
• Reanudación del monitoreo de los controles de seguridad.

Enfoque para la versión 4.0.1:

La aplicabilidad de este requisito en la versión 3.2.1 era solamente para proveedores de servicio. La versión 4.0.1 obliga a que todas las organizaciones, independientemente del tipo de entidad que sean, cumplan con este requisito. 

Adicionalmente, se elimina la necesidad de realizar una evaluación de riesgos para determinar si se requieren más acciones como resultado de la falla de seguridad.