El estándar de seguridad de datos de la industria de tarjetas de pago (PCI DSS) ha sido fundamental para garantizar la protección de los datos en transacciones con tarjetas de pago. Desde su primera publicación en 2004, PCI DSS ha evolucionado para adaptarse a las cambiantes amenazas y tecnologías emergentes. La versión 4.0, publicada en marzo de 2022, introduce cambios significativos destinados a fortalecer la seguridad y ofrecer mayor flexibilidad a las organizaciones.​

Historia y desarrollo de PCI DSS.

PCI DSS surgió como resultado del esfuerzo conjunto de las principales marcas de tarjetas de pago, con el objetivo de unificar los controles de seguridad en un único estándar. La primera versión, lanzada en 2004, estableció los principios básicos de ciberseguridad para la protección de datos de tarjetas. A lo largo de los años, el estándar ha sido revisado y actualizado para incorporar mejoras y aclaraciones basadas en la retroalimentación de la comunidad y la evolución del panorama de amenazas.​

Objetivos principales de PCI DSS 4.0.

La versión 4.0 de PCI DSS se centra en cuatro objetivos clave:​

  1. Satisfacer las necesidades de seguridad en la industria de pagos: Adaptar el estándar a las nuevas amenazas y tecnologías emergentes.​
  2. Promover la seguridad como un proceso continuo: Fomentar la evaluación y mejora constante de las prácticas de seguridad.​
  3. Aumentar la flexibilidad en la implementación de controles de seguridad: Permitir a las organizaciones utilizar diferentes métodos para alcanzar los objetivos de seguridad.​
  4. Reforzar los métodos de validación: Mejorar la transparencia y granularidad en los procesos de evaluación y cumplimiento.​

Cambios significativos en PCI DSS 4.0.

Enfoque personalizado.

Uno de los cambios más notables es la introducción del enfoque personalizado. Mientras que el enfoque tradicional (ahora denominado «enfoque definido») requiere que las organizaciones implementen controles tal como se especifican en el estándar, el enfoque personalizado permite a las entidades seleccionar controles que se adapten mejor a su entorno específico, siempre que se cumplan los objetivos de seguridad establecidos. Esto ofrece mayor flexibilidad y fomenta la innovación en las prácticas de seguridad. ​

Actualizaciones en requisitos de autenticación.

La versión 4.0 introduce mejoras en los requisitos de autenticación para fortalecer la protección de los datos:​

  • Longitud de contraseñas: Se aumenta la longitud mínima de las contraseñas de 7 a 12 caracteres. Si el sistema no admite 12 caracteres, se permite una longitud mínima de 8 caracteres.
  • Autenticación Multifactor (MFA): Se requiere el uso de MFA para todos los accesos al entorno de datos del titular de la tarjeta (CDE), no solo para los administradores.​
  • Intentos de autenticación inválidos: Se incrementa el número de intentos fallidos permitidos antes de bloquear una cuenta, de 6 a 10.

Gestión de riesgos y concienciación en seguridad.

PCI DSS 4.0 enfatiza la importancia de la gestión de riesgos y la concienciación en seguridad:​

  • Análisis de riesgos específicos: Se requiere realizar análisis de riesgos documentados para determinar la frecuencia de ciertas actividades, como escaneos de malware y revisiones de accesos.​
  • Programa de concienciación en seguridad: Debe revisarse y actualizarse al menos una vez cada 12 meses para reflejar las amenazas y vulnerabilidades actuales.

Desarrollo seguro y gestión de vulnerabilidades.

La nueva versión introduce requisitos más estrictos relacionados con el desarrollo seguro y la gestión de vulnerabilidades:​

  • Inventario de software personalizado: Mantener un inventario de software a medida y de los componentes de terceros incorporados.
  • Protección contra Phishing: Implementar procesos y mecanismos automatizados para detectar y proteger al personal contra ataques de phishing.​
  • Revisión automatizada de registros: Utilizar herramientas automatizadas para llevar a cabo revisiones de registros de auditoría, como soluciones SIEM (Security Information and Event Management).

Cambios en la nomenclatura de los requisitos.

Los 12 requisitos principales de PCI DSS han sido renombrados para reflejar mejor sus objetivos y adaptarse a las tecnologías actuales. Por ejemplo:​

  • Versión 3.2.1: «Instalar y mantener una configuración de firewall para proteger los datos del titular de la tarjeta.»
  • Versión 4.0: «Instalar y mantener controles de seguridad de la red.»

Periodo de transición y fechas clave.

Para facilitar la transición a la nueva versión, se ha establecido un periodo en el cual ambas versiones, 3.2.1 y 4.0, coexisten:​

  • Marzo 2022 – Marzo 2024: Las organizaciones pueden ser evaluadas bajo cualquiera de las dos versiones.​
  • 31 de marzo de 2024: Retiro oficial de la versión 3.2.1; a partir de esta fecha, solo la versión 4.0 será válida para evaluaciones.​
  • 31 de marzo de 2025: Fecha límite para la implementación de ciertos requisitos nuevos que, hasta entonces, se consideran mejores prácticas.

Cambios en los nombres de los requerimientos 1 y 2 de PCI DSS.

Requerimiento 1: Install and Maintain Network Security Controls.

La evolución de las tecnologías de virtualización y las infraestructuras en la nube ha llevado a una redefinición del primer requerimiento de PCI DSS. En la versión 4.0, el término «firewall», presente desde la primera edición del estándar, ha sido reemplazado por «Network Security Controls» (NSCs), un concepto más amplio que incluye cualquier tecnología de red capaz de gestionar y controlar el tráfico entre distintos segmentos lógicos o físicos mediante reglas predefinidas.

Este cambio no es inesperado, ya que el PCI Security Standards Council (PCI SSC) ya había anticipado estos ajustes en su documento Information Supplement – Cloud Computing Guidelines de 2018. Allí se analizaron los desafíos de seguridad en entornos multiusuario en la nube, tecnologías emergentes como Fog Computing e IoT, y soluciones como SDN, contenedores y Virtual Desktop Infrastructure (VDI). La versión 3.2.1 de PCI DSS no lograba abarcar completamente estos escenarios, lo que llevó a la reformulación del requerimiento.

Entre los principales cambios destacan:

  • La exigencia de estándares de configuración para las reglas de filtrado de los NSCs (1.2.1).
  • La necesidad de que los cambios en conexiones de red y configuraciones sigan el proceso de gestión de cambios (1.2.2).
  • Nuevas prácticas en diagramas de red (1.2.3), como el etiquetado de segmentos y la identificación detallada de controles de seguridad.
  • Mayor especificidad en diagramas de flujo de datos (1.2.4), asegurando la trazabilidad de cada transacción.
  • Restricciones más claras sobre protocolos y puertos, permitiendo solo aquellos con justificación de negocio y aplicando controles adicionales a los inseguros (1.2.5, 1.2.6).
  • La obligación de revisar semestralmente la configuración de los NSCs para garantizar su efectividad (1.2.7).
  • Protección estricta de los archivos de configuración de los NSCs (1.2.8).

Asimismo, la clasificación de redes en confiables y no confiables se ha alineado con las guías del documento Information Supplement – Guidance for PCI DSS Scoping and Network Segmentation. Esto refuerza la necesidad de implementar NSCs en los puntos de segmentación entre redes con distintos niveles de confianza.

Un cambio notable en la versión 4.0 es la eliminación de la obligatoriedad de la Red desmilitarizada (DMZ) para filtrar el tráfico entrante. Aunque sigue siendo una recomendación, ya no es un requisito estricto. Sin embargo, si la DMZ maneja datos de tarjetas, se debe considerar parte del Cardholder Data Environment (CDE).

Requerimiento 2: Apply Secure Configurations to All System Components

Este requerimiento ha sido renombrado para enfatizar que las configuraciones seguras deben aplicarse a todos los componentes del sistema, sin importar si son tradicionales o basados en servicios en la nube.

Los cambios más relevantes incluyen:

  • Se exige el desarrollo de estándares de configuración segura para todos los componentes, incluyendo sistemas en la nube (2.2.1), con referencias a guías de la Cloud Security Alliance (CSA).
  • Se permite el uso de cuentas por defecto de fabricantes siempre que sus contraseñas sean cambiadas (2.2.2). Anteriormente, PCI DSS requería su eliminación total, salvo en casos excepcionales con controles compensatorios.
  • Se clarifica el concepto de «función primaria» en un sistema (2.2.3), permitiendo múltiples funciones con distintos niveles de seguridad, siempre que estén adecuadamente aisladas o aseguradas al nivel más alto de protección requerido.
  • Se refuerzan controles sobre servicios, protocolos y funciones innecesarias, exigiendo su eliminación o desactivación (2.2.4, 2.2.5).
  • Se restringe el acceso administrativo no basado en consola a métodos con criptografía robusta, incluyendo accesos a través de APIs.
  • Se agregan controles específicos para la seguridad en redes inalámbricas (2.3.1), incluyendo el cambio de claves cuando un empleado con acceso a ellas deja la empresa o si hay sospechas de compromiso.
  • El control de inventario de componentes ha sido movido al requerimiento 12, alineándolo con su propósito de gestión organizativa.

Requerimiento 5: Protección de sistemas y redes contra Software malicioso.

Desde su primera versión, el estándar PCI DSS ha incluido controles para la detección, remoción, bloqueo y contención de código malicioso. Sin embargo, hasta la versión 3.2.1, estos controles se referenciaban genéricamente como “software antivirus”, lo cual era inexacto, ya que este tipo de soluciones también protege contra otras formas de malware, como gusanos, troyanos, ransomware, spyware, rootkits, adware y backdoors.

A partir de la versión 4.0 de PCI DSS, se adopta el término «antimalware» para abarcar todas las amenazas de software malicioso, haciendo más precisa la definición del requerimiento.

Diferencias clave entre «antivirus» y «antimalware»

Otros cambios clave en este requerimiento incluyen:

  • Evaluación periódica para determinar qué componentes requieren protección antimalware. Aquellos que no sean susceptibles deben listarse explícitamente (Req. 5.2.3).
  • Actualizaciones automáticas obligatorias para las soluciones antimalware (Req. 5.3.1).
  • Inclusión explícita del término «escaneo en tiempo real» para clarificar que la protección debe ser continua ante eventos como descarga o modificación de archivos (Req. 5.3.2).
  • Incorporación del análisis de comportamiento como un método de detección alternativo a los escaneos tradicionales (Req. 5.3.2).
  • Configuración de escaneos programados basados en análisis de riesgos (Req. 5.3.2.1).
  • Requerimiento de escaneo obligatorio para medios de almacenamiento removibles (Req. 5.3.3).
  • Retención de logs alineada a la política general de gestión de registros: 12 meses de almacenamiento, con acceso inmediato a los últimos 3 meses (Req. 5.3.4).
  • Inclusión de controles específicos para mitigar ataques de phishing, con medidas adicionales en servidores de correo electrónico (Req. 5.4.1).

Requerimiento 6: desarrollo y mantenimiento seguro de sistemas y software.

El requerimiento 6 ha sido ampliado para abarcar no solo las aplicaciones, sino el software en general. Se especifica que sus controles aplican a todos los componentes del sistema, excepto la sección 6.2, que se centra en software desarrollado internamente.

Cambios principales en seguridad de software personalizado.

  • Reorganización de secciones:
    • 6.2: Seguridad en software personalizado.
    • 6.3: Gestión de actualizaciones y vulnerabilidades.
    • 6.4: Protección de aplicaciones web de acceso público.
    • 6.5: Gestión de cambios.
  • Refuerzo de controles de seguridad durante el ciclo de vida del desarrollo.
  • Mayor detalle en la capacitación obligatoria para desarrolladores:
    • Debe realizarse anualmente.
    • Debe cubrir los lenguajes de programación utilizados.
    • Debe incluir formación sobre herramientas de detección de vulnerabilidades (Req. 6.2.2).
  • Revisión de código obligatorio con guías de desarrollo seguro, revisión de vulnerabilidades y aplicación de correcciones antes de la puesta en producción (Req. 6.3.2).
  • Agrupación de vulnerabilidades comunes en una única sección (SQLi, XSS, CSRF, etc.) (Req. 6.2.4).

Gestión de vulnerabilidades y actualizaciones.

  • Instalación obligatoria de parches críticos y de alto riesgo dentro del primer mes de su publicación (Req. 6.3.3).
  • Identificación de vulnerabilidades en software base y componentes como librerías, compiladores y frameworks.
  • Inclusión del concepto de «bug bounty» como estrategia para reportar vulnerabilidades (Req. 6.3.1).
  • Creación de un inventario de software desarrollado internamente, incluyendo librerías y frameworks (Req. 6.3.2, obligatorio desde el 31 de marzo de 2025).

Protección de aplicaciones web.

  • Desde el 31 de marzo de 2025, será obligatorio el uso de herramientas automatizadas para la protección en tiempo real de aplicaciones web (p. ej., Web Application Firewall – WAF). Los escaneos periódicos dejarán de ser suficientes.
  • Se menciona Runtime Application Self-Protection (RASP) como complemento del WAF (Req. 6.4.1).
  • Implementación de controles técnicos para proteger scripts en páginas de pago:
    • Validación de autorización de cada script.
    • Verificación de integridad de cada script.
    • Inventario detallado de scripts usados y su propósito.
    • Obligatorio desde el 31 de marzo de 2025.

Requerimiento 7: Restricción de acceso a componentes del sistema y datos de titulares de tarjeta.

El requerimiento 7 define los criterios para la autorización y la gestión de privilegios. Tradicionalmente, ha sido el requerimiento con menos controles dentro del estándar PCI DSS, y esta tendencia continúa en la versión 4.0 con cambios mínimos enfocados en aclaraciones y ampliación de su aplicabilidad.

Cambios clave en la Versión 4.0:

  • Aplicabilidad explícita a cuentas interactivas y acceso de empleados, contratistas, proveedores internos y externos, además de terceros.
  • Inclusión de ciertos controles para cuentas de aplicación y de sistema utilizadas por la entidad (cuentas de servicio).
  • Exclusión de la aplicabilidad de estos controles a los consumidores (titulares de tarjetas).
  • Revisión semestral de cuentas de usuario y privilegios (Req. 7.2.4), con validación de la Dirección. Aplicable desde el 31 de marzo de 2025.
  • Aplicación del principio de mínimo privilegio a cuentas de aplicación y de sistema, con acceso limitado solo a sistemas o procesos específicos (Req. 7.2.5).
  • Revisión periódica de cuentas de aplicación y de sistema para corregir accesos inapropiados, con reconocimiento de la Dirección (Req. 7.2.5.1). Aplicable desde el 31 de marzo de 2025.
  • Acceso a repositorios de datos de tarjetas solo mediante aplicaciones o métodos programáticos basados en roles, con acceso directo restringido a administradores responsables (Req. 7.2.6).
  • Mantenimiento del sistema de control de acceso con configuración «denegar todo» por defecto.

Requerimiento 8: Identificación y autenticación de usuarios.

Complementando la gestión de autorizaciones del requerimiento 7, el requerimiento 8 establece los criterios para la identificación y autenticación de usuarios, sistemas y aplicaciones.

Cambios relevantes en la versión 4.0:

  • Permiso para cuentas compartidas o genéricas en casos excepcionales, con autorización de la Dirección y trazabilidad del usuario que la utiliza.
  • Modificaciones en la política de contraseñas:
    • Intentos fallidos de autenticación aumentan de 6 a 10 (Req. 8.3.4).
    • Longitud mínima de contraseñas pasa de 7 a 12 caracteres (o a 8, si el sistema no soporta 12) (Req. 8.3.6).
    • Contraseñas como único factor de acceso deben cambiarse cada 90 días o contar con análisis dinámico de seguridad para acceso en tiempo real (Req. 8.3.9).
  • Cambios en la Autenticación Multifactor (MFA):
    • MFA obligatorio para accesos administrativos al CDE que no sean por consola (Req. 8.4.1).
    • MFA obligatorio para todos los accesos al CDE, aplicable desde el 31 de marzo de 2025 (Req. 8.4.2).
    • MFA requerido para accesos remotos desde fuera de la red corporativa con impacto en el CDE (Req. 8.4.3).
    • Restricciones para evitar omisión de MFA sin aprobación documentada y en un periodo de tiempo limitado (Req. 8.5.1).
    • Implementación de múltiples autenticaciones en entornos con distintos niveles de acceso al CDE («MFA Chains»).
  • Requisitos para cuentas de sistema o de aplicación:
    • Uso interactivo solo en casos excepcionales, con aprobación de la Dirección y seguimiento de actividades (Req. 8.6.1).
    • Prohibición de almacenamiento inseguro de contraseñas en scripts o archivos de configuración (Req. 8.6.2).
    • Requisito de cambios periódicos y complejidad de contraseñas para estas cuentas.

Requerimiento 9: restricción de acceso físico a datos de titulares de tarjeta.

Este requerimiento mantiene su nombre desde la versión 3.2.1 y se enfoca en clarificar controles para su implementación efectiva.

Cambios y clarificaciones en la Versión 4.0:

  • Definición de tres áreas físicas aplicables:
    • Áreas sensibles (Sensitive Areas).
    • Entorno de Datos de Tarjeta (CDE).
    • Instalaciones (Facilities).
  • Diferenciación en la gestión del acceso físico entre empleados (Req. 9.3.1) y visitantes (Req. 9.3.2).
  • Registro de visitas con inclusión de fecha y hora, además del nombre del visitante, empresa y persona que autoriza (Req. 9.3.4).
  • Seguridad en Puntos de Interacción (POI):
    • Exclusión de controles para dispositivos comerciales de mercado masivo (COTS) y teclados de ingreso manual de PAN.
    • Definición de la frecuencia de inspecciones físicas a POI basada en análisis de riesgos (Req. 9.5.1.2.1). Aplicable desde el 31 de marzo de 2025.

Requerimiento 10: Log and Monitor All access to system components and cardholder data.

El requerimiento 10 establece los controles necesarios para registrar las actividades que afectan a los componentes del sistema y a los datos del titular de tarjeta, con el fin de identificar eventos sospechosos de manera proactiva y facilitar investigaciones posteriores a incidentes. Los elementos clave de este requerimiento incluyen los registros de eventos (logs) y su sincronización temporal, garantizando una correcta correlación de actividades entre los activos involucrados en un evento.

En esta versión del estándar, se excluyen explícitamente las actividades realizadas por los titulares de tarjetas (cardholders), pero se incluyen las acciones realizadas por empleados, contratistas, proveedores y otras entidades que tengan acceso o puedan afectar la seguridad del entorno.

Cambios y aclaraciones importantes:

  1. Gestión de registros de eventos (Logs):
    • Los registros deben estar habilitados y activos para todos los componentes del sistema y los datos del titular de tarjeta.
    • Estos registros deben contener solo la información necesaria para la operación, evitando el almacenamiento de datos sensibles (req. 10.2.1).
  2. Revisión de registros:
    • A partir del 31 de marzo de 2025, la revisión de los registros de eventos debe realizarse con herramientas automatizadas, para reducir la intervención humana y la tasa de error (req. 10.4.1).
  3. Sincronización de tiempo:
    • Los controles de sincronización de tiempo se mantienen sin cambios. La correcta sincronización es esencial para correlacionar eventos de manera efectiva.
  4. Respuesta a fallos en sistemas de seguridad críticos:
    • A partir del 31 de marzo de 2025, todas las entidades afectadas por PCI DSS deberán realizar acciones detectivas y correctivas ante fallos en sistemas de seguridad críticos. Esto incluye no solo la identificación de fallos, sino también actividades orientadas a la restauración del servicio afectado (req. 10.7.2, req. 10.7.3).

Requerimiento 11: Test security of systems and networks regularly.

El requerimiento 11 cubre las acciones vinculadas al ciclo de vida de los controles de seguridad para la protección de datos de tarjetas de pago: categorización de activos, selección, implementación, monitorización y evaluación de controles. El objetivo de este requerimiento es determinar si los controles de seguridad se aplican correctamente y producen los resultados deseados con respecto al cumplimiento de los requisitos del estándar.

Cambios y actualizaciones clave:

  1. Redes inalámbricas:
    • Los procesos de identificación de redes inalámbricas deben detectar tanto los puntos de acceso autorizados como los no autorizados (req. 11.2.1). Este control aplica tanto a organizaciones que permiten redes inalámbricas como a las que las prohíben por normativa.
  2. Escaneos de vulnerabilidades internos:
    • Se requiere que las herramientas de escaneo de vulnerabilidades estén actualizadas con la información más reciente sobre vulnerabilidades (req. 11.3.1).
    • Las vulnerabilidades no categorizadas como críticas o de alto riesgo deben ser gestionadas según un análisis de riesgos y se deben realizar re-escaneos si es necesario (req. 11.3.1.1). Este control será aplicable a partir del 31 de marzo de 2025.
  3. Escaneos autenticados:
    • Se introduce el concepto de “escaneos autenticados”, que permite que los escaneos internos vayan más allá de la detección de vulnerabilidades desde la red, abordando también la configuración del software y los activos locales. Para ello, se deben establecer credenciales de autenticación adecuadas (req. 11.3.1.2).
  4. Escaneos de vulnerabilidades externos:
    • Los controles asociados a escaneos de vulnerabilidades externos no sufren cambios en esta versión.
  5. Pruebas de penetración internas y externas:
    • Se aclara la distinción entre las pruebas de penetración internas (desde dentro del CDE) y externas (desde redes externas o públicas hacia el CDE).
    • Los reportes de las pruebas de penetración deben ser almacenados por al menos 12 meses.
    • Las vulnerabilidades explotables detectadas deben ser corregidas según los niveles de riesgo definidos por la organización (req. 11.4.4).
  6. Sistemas de detección/prevención de intrusiones (IDS/IPS):
    • Los proveedores de servicios deben asegurarse de que sus sistemas de detección y prevención de intrusiones sean capaces de detectar y gestionar canales de comunicación encubiertos utilizados por malware (req. 11.5.1.1), a partir del 31 de marzo de 2025.
  7. Protección contra cambios no autorizados en páginas de pago:
    • Un nuevo control (11.6.1) exige la implementación de mecanismos para detectar cambios no autorizados en páginas de pago, especialmente contra ataques de “digital skimming”. Estos controles deben ejecutarse al menos cada 7 días o con una frecuencia basada en un análisis de riesgos, complementando el control 6.4.3 de PCI DSS v4.0.

Requerimiento 12: Apoyo a la seguridad de la información con políticas y programas organizacionales.

En la versión 4.0 del estándar PCI DSS resalta la importancia de tener políticas, programas y controles organizacionales bien definidos y actualizados para proteger los datos de tarjetas de pago a lo largo del ciclo de vida de los controles físicos y lógicos. A continuación, se detalla la información clave y los cambios relevantes en esta versión:

1. Política de seguridad de la información.

En PCI DSS v4.0, el nombre del requerimiento se modificó para enfatizar que se debe tener un enfoque más robusto que no solo se limite a mantener una política de seguridad de la información, sino también contar con programas y políticas que apoyen la seguridad de la información a nivel organizacional. Los cambios clave incluyen:

  • Roles y responsabilidades claras: La política de seguridad debe especificar claramente los roles y responsabilidades de seguridad de la información (12.3.1), con la aceptación de estos roles por parte del personal correspondiente.
  • CISO o Directores responsables: Es necesario que un miembro de la alta dirección, como el CISO o un miembro de la junta con conocimientos relevantes, asuma la responsabilidad de la seguridad de la información (12.1.4).

2. Uso de tecnologías y análisis de riesgos.

  • Política de uso aceptable: PCI DSS v4.0 ha unificado los controles relacionados con el uso de tecnologías críticas, exigiendo políticas claras sobre el uso aceptable de tecnologías por parte de los usuarios finales y asegurando que las tecnologías sean aprobadas explícitamente por la empresa (12.2.1).
  • Análisis de riesgos (Targeted Risk Analysis): Se introduce el concepto de análisis de riesgos enfocado en los controles específicos de PCI DSS que pueden ser ejecutados de forma personalizada. Este análisis debe justificarse y revisarse al menos cada 12 meses (12.3.1), aplicable a partir de marzo de 2025.

3. Criptografía y tecnologías obsoletas.

  • Revisión de Algoritmos Criptográficos: Se requiere que la organización tenga un inventario actualizado de los algoritmos criptográficos utilizados, incluyendo su justificación y el monitoreo de su viabilidad. También debe haber una estrategia documentada para responder a vulnerabilidades criptográficas (12.3.3).
  • Gestión de Tecnologías Obsoletas: Se debe realizar una revisión de las tecnologías de hardware y software que no serán soportadas por los fabricantes (EOL), con un plan aprobado por la dirección para remediar estas tecnologías (12.3.4).

4. Formación y gestión de proveedores de servicios.

  • Formación en Seguridad: La formación en seguridad debe estar alineada con los roles de cada persona en la protección de los datos de tarjetas y debe actualizarse al menos cada 12 meses (12.6.1 y 12.6.2). Se incorpora la necesidad de que la formación cubra amenazas como phishing, ingeniería social, y el uso de tecnologías de usuario final (12.6.3.1 y 12.6.3.2).
  • Proveedores de Servicios: Se aclara que el cumplimiento de un proveedor de servicios con PCI DSS no implica automáticamente que el cliente cumpla con el estándar. Los proveedores deben proporcionar información sobre su cumplimiento (12.9.2).

5. Gestión de Incidentes.

Los procedimientos de respuesta a incidentes deben estar preparados no solo para incidentes confirmados, sino también para eventos sospechosos (12.10.1). Además, deben incluir mecanismos de detección de manipulación de páginas de pago y gestionar eventos en los que se detecten datos de PAN en ubicaciones no autorizadas (12.10.5).

6. Revisión del alcance del cumplimiento.

Para garantizar que el cumplimiento con PCI DSS sea adecuado, la entidad debe revisar el alcance de PCI DSS periódicamente. Esto incluye flujos de datos, diagramas, componentes del sistema y conexiones con terceros (12.5.1 y 12.5.2), y esta revisión debe hacerse al menos cada 12 meses para comercios y cada 6 meses para proveedores de servicios.

Resumen de cambios importantes en PCI DSS v4.0:

  1. Políticas organizacionales más robustas: Roles claros y responsabilidades aceptadas por el personal.
  2. Enfoque específico en el análisis de riesgos: Introducción del Targeted Risk Analysis y revisión cada 12 meses.
  3. Revisión de criptografía y tecnologías obsoletas: Con un enfoque en asegurar que no se sigan utilizando algoritmos vulnerables y tecnologías EOL.
  4. Formación periódica y alineada a los roles: Actualización continua del material y de las amenazas relevantes.
  5. Gestión de proveedores de servicios y cumplimiento: Clarificación de la responsabilidad de los proveedores y la necesidad de que brinden información sobre su cumplimiento.

La versión 4.0 de PCI DSS refuerza la necesidad de una gestión organizacional sólida de la seguridad de la información, centrando esfuerzos en políticas claras, análisis de riesgos dirigidos, y la correcta formación del personal. Con un enfoque más integrador y específico, PCI DSS v4.0 se adapta a las amenazas actuales y asegura un enfoque más proactivo en la gestión de la seguridad en las organizaciones.

Fuentes: https://www.pcisecuritystandards.org/document_library