En esta quinta entrega de la serie “Análisis de PCI DSS v4.0” se analizarán los cambios aplicados a los requerimientos 7, 8 y 9 del estándar en su nueva versión (4.0). Estos requerimientos – que hacen parte del grupo 4 “Implement Strong Access Control Measures” – están orientados hacia la implementación y monitorización de controles físicos y lógicos para la identificación, la autenticación, la autorización y la gestión de privilegios en los componentes del sistema que hacen parte del entorno de cumplimiento de PCI DSS para evitar el acceso no autorizado, controlar la confidencialidad, la integridad y la disponibilidad de los activos y permitir la relación entre una entidad (una persona o un sistema informático) con las acciones que esa entidad realiza en el entorno.

Antes de proceder con el análisis de los cambios aplicados a estos requerimientos, es importante recordar las definiciones de algunos términos empleados a lo largo del estándar:

• La identificación es la atribución de una identidad única a una persona o sistema.
• La autenticación es el proceso de verificación de la identidad del usuario/sistema. Al solicitar acceso y presentar una identificación de usuario/sistema único, el usuario/sistema proporciona un conjunto de datos privados a los que sólo él tiene acceso o conocimiento. Para este proceso se emplea la validación de uno o más de los siguientes factores:
  • Algo que se sabe (something you know – SYK), como una contraseña,
  • Algo que se tiene (something you have – SYH), como un token o una tarjeta inteligente (smart card),
  • Algo que se es (something you are -SYA), como un control biométrico.
• La autorización es el proceso de definir los recursos específicos que necesita un usuario/sistema (acceso) y determinar los privilegios sobre dichos recursos. La gestión de la autorización debe estar basada en los siguientes criterios:
  • «Necesidad de saber» (Need-to-know) se refiere a proporcionar acceso sólo a la menor cantidad de datos necesarios para realizar un trabajo.
  • Los «mínimos privilegios» (Least privileges) se refieren a proporcionar sólo el nivel mínimo de privilegios necesarios para realizar un trabajo.
  • La “separación de responsabilidades” (Separation of duties) permiten dividir las funciones de misión crítica entre diferentes individuos y/o funciones, define roles y responsabilidades para cada individuo o rol y garantiza que el personal de seguridad que administra las funciones de control de acceso no administre también las funciones de auditoría para evitar conflictos de interés empleando el control dual y el conocimiento dividido:
    • Control dual (dual control): Un proceso que utiliza dos o más entidades separadas (normalmente personas) que operan de forma concertada para proteger funciones o información sensibles. Ninguna entidad por sí sola puede acceder o utilizar el material.
    • Conocimiento dividido (Split knowledge): Separación de los datos o la información en dos o más partes, cada una de las cuales se mantiene constantemente bajo el control de personas o equipos autorizados por separado, de modo que ninguna persona o equipo conozca la totalidad de los datos.

La relación entre estos tres importantes conceptos es sencilla:

• La identificación proporciona unicidad
• La autenticación proporciona validez
• La autorización proporciona control

Relación entre Autenticación, Autorización e Identificación

La gestión de estos tres conceptos se denomina “Identidad y gestión de acceso” (Identity and Access Management – IAM) y sus reglas de implementación son evaluadas en los controles de estos tres requerimientos de PCI DSS.

Requerimiento 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

El requerimiento 7 define los criterios para la autorización y la gestión de privilegios. Este requerimiento ha sido tradicionalmente el requerimiento con menos controles del estándar PCI DSS y así ha continuado en la versión 4.0 del estándar.

Los cambios implementados en esta versión son mínimos y se encuentran focalizados principalmente en aclaraciones y ampliación de su aplicabilidad.

• Se aclara de forma explícita que este requerimiento aplica a cuentas interactivas (asociadas a un usuario en particular) y acceso de empleados, contratistas, proveedores internos y externos y otros terceros. También se aplican ciertos controles a cuentas de aplicación y del sistema utilizadas por la entidad (también llamadas «cuentas de servicio», empleadas para la conexión entre aplicaciones sin interacción directa con una persona).
• Se aclara que los controles de este requerimiento no aplican a los consumidores (titulares de tarjetas).
• Se requiere de una revisión semestral de todas las cuentas de usuario y de sus privilegios para validar y confirmar que estos elementos continúan siendo apropiados con base en los roles y responsabilidades definidos para identificar variaciones durante los procesos de altas, bajas o cambios durante el ciclo de vida de las cuentas. La Dirección debe reconocer que el acceso es el adecuado (req. 7.2.4) – Este control será válido a partir de marzo 31 de 2025.
• Se amplia la aplicabilidad de este requerimiento para cubrir no solo las cuentas de usuarios interactivos sino también las cuentas de aplicación y de sistema. Para ello:
  • La asignación de privilegios a estas cuentas debe estar basadas en el menor privilegio y su acceso debe estar limitado a los sistemas, aplicaciones o procesos que específicamente requieren de su uso (req. 7.2.5) – Este control será válido a partir de marzo 31 de 2025.
  • Se requiere de una revisión periódica de las cuentas de aplicación y de sistema para remediar cualquier acceso inapropiado. La Dirección debe reconocer que el acceso es el adecuado (req. 7.2.5.1) – Este control será válido a partir de marzo 31 de 2025.
  • Los accesos a repositorios de datos de tarjetas de pago deben estar realizarse a través de aplicaciones o métodos programáticos basados en roles y con base en el menor privilegio, en donde solamente los administradores responsables pueden ejecutar consultas directas a dichos repositorios (req. 7.2.6). Este control remplaza al control 8.7 de PCI DSS v3.2.1, aclarando que el acceso no es solamente a bases de datos sino a cualquier repositorio de datos de tarjetas.

Los controles asociados a la existencia de un sistema de control de acceso para el entorno configurado para “denegar todo” (deny all) por defecto continua sin mayores cambios en esta nueva versión del estándar.

Requerimiento 8: Identify Users and Authenticate Access to System Components

Como complemento a la gestión de los procesos de autorización descritos en el requerimiento 7, el requerimiento 8 establece los criterios para la identificación y la autenticación de usuarios, sistemas y/o aplicaciones.

Dentro de los cambios más relevantes a este requerimiento se encuentran:

• En la versión 4.0 de PCI DSS se permitirá el uso de cuentas grupales, compartidas, genéricas u otras credenciales de autenticación compartidas, siempre y cuando su uso se realice de forma excepcional, justificado, aprobado por la Dirección, se identifique al individuo que usa la cuenta antes de garantizar su acceso y que se pueda relacionar cada actividad con el usuario que la realizó. Este cambio permite gestionar ciertas limitaciones técnicas (como por ejemplo el uso de la cuenta “root” en sistemas operativos Unix), en donde anteriormente era necesario usar un control compensatorio como alternativa de cumplimiento.
• Se realizaron varios cambios a la política de contraseñas:
  • Los intentos de autenticación inválidos se ampliaron de 6 a 10 (req. 8.3.4)
  • La longitud de la contraseña se amplió de 7 a 12 caracteres (o a 8, si el sistema no soporta 10 caracteres) (req. 8.3.6)
  • En el caso de que la contraseña sea usada como único factor de acceso, estas contraseñas deben ser cambiadas cada 90 días o se requiere analizar la postura de seguridad de la cuenta de forma dinámica, determinando el acceso a los recursos de forma automática y en tiempo real (req. 8.3.9). Este requerimiento también es aplicable a las cuentas de los clientes de los proveedores de servicio, a partir de marzo 31, 2025 (req. 8.3.10.1)

Respecto al uso de la autenticación multifactor (MFA), los cambios incluidos en la versión 4.0 son los siguientes:

• Se requiere MFA para todos los accesos que no sean por consola (acceso realizado empleando una interfaz de red en vez de una conexión física directa) al CDE por personal con acceso administrativo (req. 8.4.1)
• Se requiere MFA para todos los accesos al CDE (el acceso al CDE no se puede obtener empleando un único factor de autenticación) (req. 8.4.2) – aplicable a partir de marzo 31, 2025.
• Se requiere MFA para todos los accesos de red remotos originados desde fuera de la red corporativa (incluyendo accesos de usuarios y administradores, así como terceros y proveedores) que puedan acceder o impactar el CDE (req. 8.4.3)
• Se describen las configuraciones técnicas que se deben implementar en MFA, incluyendo controles para evitar ataques de “replay”, uso de al menos dos factores de autenticación diferentes, validación correcta de todos los factores de autenticación antes de conceder acceso al recurso/red y restricciones para “saltar” los controles de MFA si existe autorización de la Dirección, está documentado y se permite solamente en una franja de tiempo limitada (req. 8.5.1) – aplicable a partir de marzo 31, 2025.

En este sentido, es muy importante resaltar el concepto de “MFA chains” o múltiples autenticaciones empleando MFA dependiendo de dónde inicia y dónde finaliza la conexión. Pueden presentarse casos en los cuales un administrador se conecte desde fuera de la red corporativa a una red que pueda impactar al CDE (primer uso de MFA) y, una vez allí, requiera una conexión por red al CDE (segundo uso de MFA). En estos casos, se requiere el uso de MFA dos veces.

Uso de MFA en PCI DSS v4.0

Finalmente, se describen los controles que se deben aplicar a cualquier cuenta de sistema o de aplicación:

• Cuando se usan estas cuentas como una cuenta interactiva (empleada por un individuo), se debe gestionar como una excepción, debe ser usada en un límite de tiempo definido, debe estar aprobado por la Dirección y se debe confirmar la identidad del usuario, así como realizar seguimiento de las acciones de dicho usuario (req. 8.6.1)– aplicable a partir de marzo 31, 2025.
• Por otro lado, se extienden los controles para evitar que las contraseñas usadas por estas cuentas sean integradas de forma insegura en scripts, ficheros de configuración o en código fuente de aplicaciones (req. 8.6.2).
• Las contraseñas usadas por estas cuentas deben ser cambiadas periódicamente y tener una complejidad apropiada con base en los periodos definidos para su cambio.

Requerimiento 9: Restrict Physical Access to Cardholder Data

A diferencia del resto de requerimientos del estándar PCI DSS v4.0, este es el único requerimiento cuyo nombre no sufrió cambios desde la versión 3.2.1.  Sin embargo, se agregaron múltiples aclaraciones para facilitar la implementación de los controles, incluyendo:

• Definición de tres áreas físicas en donde los controles de PCI DSS son aplicables:
  • Áreas sensibles (sensitive areas)
  • CDE (cardholder data environment)
  • Instalaciones (facilities)

Conceptos de áreas físicas usados en PCI DSS

• Se diferencian los procedimientos a ser aplicados al ciclo de vida de la gestión del acceso físico al CDE por parte de empleados (req. 9.3.1) y visitantes (req. 9.3.2).
• El registro de visitas debe incluir no solamente el nombre del visitante y de su empresa y el nombre de la persona que autoriza su acceso físico, sino también la fecha y hora de la visita (req. 9.3.4).

En cuanto a la seguridad de los puntos de interacción (POI), se añadieron las siguientes aclaraciones:

• Los controles relacionados con la seguridad física del POI no son aplicables a dispositivos COTS (commercial off-the-shelf) – ya que son dispositivos propiedad del comercio y diseñados para distribución en mercados masivos – ni a componentes que permiten el ingreso manual de los datos del PAN, como un teclado de ordenador.
• La frecuencia de las inspecciones físicas realizadas a los POI debe ser definida por la organización con base en un análisis de riesgos (req. 9.5.1.2.1) – aplicable a partir de marzo 31, 2025.

Referencias

• Payment Data Security Essential: Secure Remote Access https://docs-prv.pcisecuritystandards.org/Guidance%20Document/Infographic/Payment-Data-Security-Essential-Secure-Remote-Access.pdf
• Payment Data Security Essential: Strong Passwords https://docs-prv.pcisecuritystandards.org/Guidance%20Document/Infographic/Payment-Data-Security-Essential-Strong-Passwords.pdf
• Multi-Factor Authentication Guidance https://docs-prv.pcisecuritystandards.org/Guidance%20Document/Authentication/Multi-Factor-Authentication-Guidance-v1.pdf
• Skimming Prevention: Best Practices for Merchants https://docs-prv.pcisecuritystandards.org/Guidance%20Document/Skimming%20Prevention/Skimming_Prevention_BP_for_Merchants_Sept2014.pdf
• Skimming Prevention: Overview of Best Practices for Merchants https://docs-prv.pcisecuritystandards.org/Guidance%20Document/Skimming%20Prevention/Skimming_Prevention_At-a-Glance_Sept2014.pdf
• Skimming Resource Guide https://docs-prv.pcisecuritystandards.org/Guidance%20Document/Skimming%20Prevention/PCI_SSC_Skimming_Resource_Guide_v05.pdf