Novedades PCI DSS v4.0

By albert
19 Ene 2023

El 31 de marzo de 2022, el PCI Security Standards Council (PCI SSC), foro mundial de seguridad en los pagos, publicó la versión 4.0 de Payment Card Industry Data Security Standard (de ahora en adelante, PCI DSS). PCI DSS es un estándar mundial que proporciona una línea base de requisitos técnicos y operativos diseñados para proteger los datos del titular de tarjetas.

De esta manera, la versión 4.0 sustituye a la anterior versión 3.2.1, con el objetivo de abordar las nuevas amenazas y tecnologías emergentes. La norma actualizada, así como el documento de resumen de cambios entre versiones se pueden encontrar en la página oficial del Council.

No obstante, y para que las organizaciones tengan tiempo de entender los cambios de esta nueva versión y puedan llevar a cabo las actualizaciones necesarias para adaptarse, la versión actual de PCI DSS 3.2.1 seguirá activa durante dos años hasta su retirada en marzo de 2024. Así, las organizaciones afectadas podrán ser evaluadas con cualquiera de las dos versiones (3.2.1 y 4.0) hasta la fecha de retirada de PCI DSS 3.2.1, marcada para el 31 de marzo de 2024, momento a partir del cual la única versión válida será PCI DSS 4.0.

PCI DSS Transition 4.0

Aspectos más relevantes de la PCI DSS 4.0

Si bien es cierto que la nueva versión 4.0 introduce cambios importantes respecto a la anterior versión, el objetivo de la presente entrada del blog será resumir, en alto nivel, aquellos aspectos más significativos y relevantes entre versiones, con el objetivo de proporcionar una idea al lector sobre lo que supone esta nueva versión. 

Enfoque definido y enfoque personalizado

Anteriormente, las organizaciones debían implementar los controles tal y como aparecían en el estándar siguiendo el enfoque definido. Mediante este enfoque, la organización implementa los controles de seguridad para cumplir los requisitos establecidos y el asesor sigue los procedimientos de prueba definidos para verificar el cumplimiento de los requisitos.

En esta nueva versión, se introduce el concepto de enfoque personalizado, el cual permite que la organización pueda implementar controles para cumplir con el objetivo del enfoque personalizado establecido en el requisito de una manera que no siga estrictamente el requisito definido. Debido a que cada implementación personalizada será diferente, no existen procedimientos de prueba definidos. El asesor QSA deberá verificar que los controles implementados cumplan con el objetivo establecido.

El objetivo del enfoque personalizado es el de apoyar la innovación en las prácticas de seguridad, permitiendo que las organizaciones tengan mayor flexibilidad para mostrar cómo sus controles de seguridad cumplen los objetivos establecidos en PCI DSS.

Cabe destacar que la mayoría de los requisitos PCI DSS pueden cumplirse utilizando el enfoque definido o el personalizado. No obstante, algunos requisitos no disponen de un objetivo del enfoque personalizado establecido, por lo que este enfoque no podrá ser aplicado para estos controles de seguridad.

Las organizaciones podrán utilizar tanto el enfoque definido como el personalizado, por lo que se podría utilizar el enfoque definido para cumplir con algunos requisitos y utilizar el enfoque personalizado para cumplir con otros requisitos.

Autenticación

A medida que siguen apareciendo nuevas amenazas, la gestión de identidades y accesos tiene un papel fundamental en la protección de los datos del titular de tarjeta. En esta nueva versión se han introducido cambios notables referentes al proceso de autenticación e inicio de sesión:

  • Se aumenta el número de intentos de autenticación inválidos antes de bloquear la cuenta, de seis a diez intentos.
  • La longitud de las contraseñas se aumenta de siete (7) a doce (12). Si el sistema no lo permite, longitud mínima de ocho (8) caracteres.
  • La autenticación multifactor o MFA se utilizan para todos los accesos al CDE, no solamente a los administradores. NOTA: no aplica a cuentas de aplicaciones o sistema ni cuentas de usuario en terminales de puntos de venta que tienen acceso a un solo número de tarjeta a la vez.
  • Todas las cuentas de usuario y los privilegios de acceso relacionados, incluyendo las cuentas de terceros, se deben revisar al menos una vez cada seis (6) meses.
  • El acceso de aplicaciones y cuentas del sistema se revisa periódicamente, a una frecuencia definida en el análisis de riesgos específico de la entidad.
  • Se permite el uso de cuentas grupales o genéricas, siempre y cuando se usen de manera excepcional y su uso esté limitado por un tiempo determinado. Además, la identidad del usuario individual debe confirmarse antes de conceder el acceso a la cuenta genérica y cada acción realizada en esa cuenta debe ser atribuible al usuario individual.

Gestión de riesgos y concienciación

Se introducen nuevos requisitos y modificaciones asociadas a la gestión de riesgos y concienciación en materia de seguridad. Algunos de estos cambios son.

  • Cada requisito PCI DSS que proporciona flexibilidad sobre la frecuencia con la que se realizan está respaldado por un análisis de riesgo específico y documentado. Dicho análisis de riesgo específico se debe revisar una vez cada 12 meses. Algunos ejemplos referenciados a este tipo de análisis de riesgos son: escaneos periódicos de malware, revisión de los accesos de aplicaciones y cuentas de sistema, periodicidad de las contraseñas de cuentas de sistema y aplicación, corrección de vulnerabilidades medias y bajas, etc.
  • Para aquellas entidades que utilizan un enfoque personalizado, se debe realizar un análisis de riesgos específico para cada requisito PCI DSS del enfoque personalizado.
  • El alcance PCI DSS es documentado y confirmado por la entidad al menos una vez cada 12 meses y ante cambios significativos en el entorno dentro del alcance
  • El programa de concienciación sobre seguridad es revisado al menos una vez cada 12 meses y se actualiza según sea necesario.

Desarrollo seguro, monitorización y gestión de vulnerabilidades

La nueva versión 4.0 introduce y endurece los requisitos asociados al desarrollo seguro, gestión de vulnerabilidades y a la monitorización de los activos. Entre estos requisitos, se destaca:

  • Para aplicaciones web públicas se debe implementar una solución técnica automatizada que detecta e impide continuamente ataques basados en la web (Web Application Firewall, WAF).
  • Se mantiene un inventario del software a medida y personalizado, así como de los componentes del software de terceros incorporados en el software a medida y personalizado.
  • Todos los scripts de las páginas de pago que se cargan y ejecutan en el navegador, además de estar inventariados de manera justificada, deben implementar un método para confirmar que cada script está autorizado y debe asegurar su integridad. 
  • Se deben implementar procesos y mecanismos automatizados para detectar y proteger al personal contra ataques de phishing.
  • Se deben utilizar mecanismos y herramientas automatizadas para llevar a cabo las revisiones de los registros de auditoría o logs, por ejemplo, mediante el uso de herramientas SIEM (Security Information and Event Management).
  • Los escaneos de vulnerabilidades internas se llevan a cabo mediante escaneos autenticados.
  • Las credenciales deberán protegerse y controlarse según lo establecido en los requisitos 7 y 8 de PCI DSS.

Encriptación

Referente a la transmisión, visualización y almacenamiento de los datos de tarjeta, esta nueva versión introduce algunos cambios importantes asociados:

  • Debido a la entrada en vigencia del BIN de ocho dígitos, PCI DSS aclara que el PAN debe estar enmascarado, pudiendo mostrar solamente el BIN y los últimos cuatro dígitos. Solamente el personal autorizado podrá ver más que el BIN y los últimos cuatro dígitos del PAN.
  • Los hashes utilizados para hacer ilegible el PAN deberán ser hashes criptográficos con clave (ejemplo de algoritmos: HMAC, CMAC y GMAC), con procesos y procedimientos de gestión de claves asociados según los requerimientos 3.6 y 3.7 de PCI DSS.
  • Si se utiliza un cifrado a nivel de disco o de partición en lugar de un cifrado de base de datos, para hacer que el PAN sea ilegible se implementará en medios electrónicos extraíbles. En caso de que se utilice en medios electrónicos no extraíbles, el PAN se hace ilegible mediante otro mecanismo que cumpla con el requisito 3.5.1 (hash, cifrado, truncamiento o tokenización).
  • Se debe mantener un inventario de las claves y certificados confiables de la entidad utilizados para proteger los datos PAN durante la transmisión. Dicho inventario deberá incluir la CA emisora y la fecha de caducidad del certificado.

¿Qué debo hacer para adaptarme a PCI DSS v4.0?

A2SECURE como empresa certificada QSA PCI Security Standards Council (PCI SSC) con más de 7 años de experiencia en PCI DSS te ayudamos a cumplir con el nuevo estándar PCI DSS v4.0, realizamos el diagnóstico e identificamos los GAPs y los nuevos requerimientos que te aplican y te ayudamos a implementar los nuevos requerimientos de manera ágil y eficiente, independientemente del sector en el que te encuentres.

Los comentarios están cerrados.