TL;DR

Si maneja datos de tarjetas de crédito, PCI DSS es obligatorio. Y punto. Abarca cómo proteger los datos de los titulares de tarjetas (CHD) y los datos confidenciales de autenticación (SAD): cifrado, cortafuegos, control de acceso, registro, escaneado, todo.

Si no lo hace, se arriesga a multas, infracciones, demandas y a que los procesadores de pagos le corten el grifo. El cumplimiento no es opcional, es supervivencia.

Resumen del cuadro de mando de PCI DSS:

• Esfuerzo del desarrollador: Moderado a Alto (Requiere codificación segura, configuración segura, manejo cuidadoso de los datos de los titulares de tarjetas, adherencia a los controles de acceso, soporte a escaneos/registros de vulnerabilidades).
• Coste de las herramientas: Moderado a alto (cortafuegos, escáneres de vulnerabilidades (escaneos ASV), supervisión de la integridad de los archivos, registro/SIEM, herramientas de cifrado, potencialmente soluciones de tokenización/P2PE).
• Impacto en el mercado: Crítico (Obligatorio para cualquier entidad que maneje datos de tarjetas de pago; su incumplimiento puede suponer la imposibilidad de procesar pagos con tarjeta).
• Flexibilidad: De baja a moderada (los requisitos básicos son prescriptivos, pero los métodos específicos de aplicación pueden variar; la v4.0 introduce más flexibilidad con el "enfoque personalizado").
• Intensidad de auditoría: Alta (Requiere validación anual mediante Cuestionario de Autoevaluación (SAQ) o Informe de Cumplimiento (ROC) formal por parte de un Evaluador de Seguridad Cualificado (QSA), además de escaneos de vulnerabilidades trimestrales).

¿Qué es PCI DSS?

La Payment Card Industry Data Security Standard (PCI DSS) es una norma mundial de seguridad de la información diseñada para prevenir el fraude con tarjetas de crédito mediante mayores controles en torno al manejo y almacenamiento de datos. Se aplica a cualquier organización, independientemente de su tamaño o ubicación, que acepte, procese, almacene o transmita datos de titulares de tarjetas (CHD) o datos sensibles de autenticación (SAD).

CHD incluye el número de cuenta principal (PAN), el nombre del titular de la tarjeta, la fecha de caducidad y el código de servicio. El DUA incluye los datos de seguimiento completos, los códigos de verificación de la tarjeta (CVV2, CVC2, etc.) y los PIN: el DUA nunca debe almacenarse después de la autorización.

La PCI DSS fue creada por las principales marcas de tarjetas de pago (Visa, Mastercard, American Express, Discover, JCB), que formaron el Consejo de Normas de Seguridad de la PCI (PCI SSC) para gestionar la norma. Las marcas de tarjetas y los bancos adquirentes, y no directamente el PCI SSC, se encargan de velar por su cumplimiento.

La norma se organiza en torno a 6 objetivos que se traducen en 12 requisitos básicos (estos siguen siendo coherentes en su concepto para la más reciente PCI DSS v4.0):

1. Construir y mantener una red y unos sistemas seguros:
   
   • Req 1: Instalar y mantener los controles de seguridad de la red (cortafuegos).
   • Req 2: Aplique configuraciones seguras a todos los componentes del sistema.
2. Proteja los datos de su cuenta:
   
   • Req 3: Proteger los datos almacenados de la cuenta (por ejemplo, encriptar el PAN).
   • Req 4: Proteger los datos de los titulares de tarjetas con criptografía fuerte durante la transmisión a través de redes abiertas y públicas.
3. Mantener un programa de gestión de vulnerabilidades:
   
   • Req 5: Proteger todos los sistemas y redes de software malicioso.
   • Req 6: Desarrollar y mantener sistemas y programas informáticos seguros (aplicación de parches, codificación segura).
4. Aplique medidas estrictas de control de acceso:
   
   • Req 7: Restringir el acceso a los componentes del sistema y a los datos de los titulares de tarjetas en función de la necesidad de conocimiento de la empresa.
   • Req 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema.
   • Req. 9: Restringir el acceso físico a los datos de los titulares de tarjetas.
5. Supervise y pruebe regularmente las redes:
   
   • Req 10: Registrar y controlar todos los accesos a los componentes del sistema y a los datos de los titulares de tarjetas.
   • Req. 11: Compruebe periódicamente la seguridad de los sistemas y redes (análisis de vulnerabilidades, pruebas de penetración).
6. Mantener una política de seguridad de la información:
   
   • Req 12: Apoyar la seguridad de la información con las políticas y programas de la organización.

La validación del cumplimiento varía en función del volumen de transacciones procesadas anualmente (niveles 1-4 para comerciantes, niveles 1-2 para proveedores de servicios), desde cuestionarios anuales de autoevaluación (SAQ) hasta auditorías formales in situ realizadas por un evaluador de seguridad cualificado (QSA) que dan lugar a un informe de cumplimiento (ROC). Normalmente se requieren escaneos trimestrales externos de vulnerabilidades por parte de un Proveedor de Escaneado Aprobado (ASV). PCI DSS v4.0 es la versión actual, cuyos requisitos serán obligatorios a partir del 31 de marzo de 2025.

¿Por qué es importante?

Para cualquier empresa que toque datos de tarjetas de pago, el cumplimiento de la norma PCI DSS es absolutamente esencial:

• Obligatorio para la aceptación de tarjetas: Lo exigen las principales marcas de tarjetas a través de contratos con los bancos adquirentes. Su incumplimiento puede impedir la aceptación de pagos con tarjeta.
• Evita las filtraciones de datos: La implantación de controles PCI DSS reduce significativamente el riesgo de costosas filtraciones de datos de titulares de tarjetas.
• Evita sanciones graves: El incumplimiento puede dar lugar a multas mensuales sustanciales por parte de los bancos adquirentes/marcas de tarjetas (que van de 5.000 a más de 100.000 dólares al mes), incluso si no se produce ninguna infracción.
• Reduce el impacto de las infracciones: Si se produce una infracción, el cumplimiento de la norma PCI DSS demuestra la diligencia debida y puede reducir potencialmente las multas, la responsabilidad legal y los costes de indemnización (como las tasas de reemisión de tarjetas).
• Fomenta la confianza de los clientes: La conformidad demuestra a los clientes que usted se toma en serio la seguridad de sus datos de pago, lo que fomenta la confianza y la fidelidad.
• Protege la reputación de la marca: Una violación de datos de tarjetas daña gravemente la reputación de una empresa. PCI DSS ayuda a evitarlo.
• Proporciona una base de seguridad: Ofrece un sólido marco de seguridad de referencia que beneficia a la postura de seguridad general de la organización, no solo para los datos de pago.

Ignorar la norma PCI DSS simplemente no es una opción para las empresas que desean aceptar tarjetas de pago.

Qué y cómo aplicar (técnica y política)

La implantación de PCI DSS implica abordar los 12 requisitos básicos mediante controles técnicos y políticas/procedimientos documentados. Las áreas clave que afectan al desarrollo y las operaciones incluyen:

1. Red segura (Req 1 y 2):
   
   • Implantar y mantener cortafuegos para segmentar el Entorno de Datos de Titulares de Tarjeta (CDE) de otras redes.
   • Utiliza configuraciones seguras: cambia los valores predeterminados del proveedor, desactiva servicios/puertos innecesarios, endurece los sistemas. Pruebas: Reglas de cortafuegos, normas de configuración, diagramas de red.
2. Proteger los datos de los titulares de tarjetas (Req 3 y 4):
   
   • Minimice el almacenamiento: No almacene datos de titulares de tarjetas a menos que sea absolutamente necesario. No almacene nunca el DUA después de la autorización.
   • Enmascarar PAN: Enmascara el número de cuenta principal (PAN) cuando se muestra (sólo son visibles los primeros 6/últimos 4 dígitos).
   • Encriptar PAN: hacer ilegible el PAN almacenado utilizando criptografía fuerte (por ejemplo, AES-256) y una sólida gestión de claves.
   • Cifre la transmisión: Cifrar CHD durante la transmisión a través de redes abiertas/públicas (utilizar versiones TLS fuertes, protocolos seguros). Pruebas: Política de conservación de datos, diagramas de flujo de datos, configuración del cifrado, procedimientos de gestión de claves.
3. Gestión de vulnerabilidades (Req 5 y 6):
   
   • Antimalware: Implante y actualice periódicamente soluciones antimalware en los sistemas afectados habitualmente por programas maliciosos.
   • Parcheado: Implantar un proceso para identificar y aplicar parches de seguridad con prontitud (dentro de los plazos definidos para los parches críticos).
   • Codificación segura: Desarrollar aplicaciones de software (internas o a medida) basadas en directrices de codificación segura (por ejemplo, OWASP), formar a los desarrolladores, abordar las vulnerabilidades de codificación comunes (inyección, XSS, etc.). Pruebas: Registros de gestión de parches, política de codificación segura, registros de formación de desarrolladores, resultados de SAST/DAST.
4. Control de acceso (Req 7, 8, 9):
   
   • Mínimo privilegio/Necesidad de saber: Restrinja el acceso al CHD y a los componentes del sistema en función de la función y los permisos mínimos necesarios.
   • Identificaciones únicas y autenticación: Asigne identificadores únicos para el acceso; aplique una autenticación sólida (contraseñas/frases de contraseña complejas, MFA, especialmente para el acceso al CDE).
   • Seguridad física: Acceso físico seguro a los sistemas que almacenan/procesan CHD. Pruebas: Políticas de control de acceso, configuración RBAC, configuración MFA, política de contraseñas, registros de acceso físico.
5. Supervisión y pruebas (Req 10 y 11):
   
   • Registro: Implemente un registro de auditoría detallado para todos los componentes del sistema; rastree el acceso a los recursos de red y CHD. Proteja los registros de manipulaciones. Utilice la sincronización horaria (NTP).
   • Revisión de registros: Revise regularmente los registros en busca de actividades sospechosas.
   • Exploración de vulnerabilidades: Realice exploraciones ASV externas trimestrales y exploraciones de vulnerabilidades internas. Hacer frente a las vulnerabilidades.
   • Pruebas de penetración: Realice pruebas de penetración internas/externas anuales (y después de cambios significativos).
   • Detección y prevención de intrusiones: Implantar IDS/IPS.
   • Detección de cambios: Utilice la supervisión de la integridad de los archivos (FIM) para los archivos críticos. Pruebas: Procedimientos de revisión de registros, configuración SIEM, informes de escaneo ASV, informes pentest, registros FIM.
6. Política de seguridad de la información (Req 12):
   
   • Mantener una política global de seguridad de la información, revisarla anualmente y distribuirla al personal pertinente.
   • Definir las responsabilidades en materia de seguridad, impartir formación de sensibilización.
   • Implantar un plan de respuesta a incidentes y ponerlo a prueba. Pruebas: Documento de política de seguridad de la información, registros de formación, plan de respuesta a incidentes y resultados de las pruebas.

PCI DSS v4.0 introduce actualizaciones como requisitos más estrictos en materia de contraseñas/MFA, mayor aplicabilidad de los controles, nuevos requisitos para la prevención del phishing y la seguridad de los scripts en las páginas de pago, y permite un "enfoque personalizado" para cumplir los requisitos en condiciones específicas, junto con el tradicional "enfoque definido".

Errores comunes que hay que evitar

Conseguir y mantener el cumplimiento de la norma PCI DSS suele ser todo un reto. Evite estos errores comunes:

1. Alcance incorrecto: No identificar con precisión todos los sistemas, redes y aplicaciones que almacenan, procesan o transmiten CHD, o que podrían afectar a la seguridad del CDE. Este es el error más crítico.
2. Almacenamiento de datos sensibles de autenticación (DAS): Almacenamiento ilegal de CVV2, datos de pista completa o datos PIN después de la autorización.
3. Protección de datos inadecuada: Almacenamiento de PAN sin cifrar, uso de un cifrado/gestión de claves deficiente o transmisión de CHD a través de canales inseguros.
4. Control de acceso débil: Uso de credenciales compartidas/por defecto, carencia de MFA para el acceso a CDE, no aplicación del mínimo privilegio, no revocación del acceso con prontitud.
5. Registro y supervisión insuficientes: No registrar eventos relevantes, no revisar los registros regularmente o no proteger los registros de manipulaciones.
6. Ignorar la gestión de vulnerabilidades: Saltarse los escaneos ASV trimestrales, fallar en los escaneos internos, no parchear vulnerabilidades críticas con prontitud.
7. Malas prácticas de codificación segura: Desarrollo de aplicaciones con vulnerabilidades comunes (SQLi, XSS) que exponen CHD.
8. Descuido de políticas y procedimientos: Carecer de políticas, procedimientos o un plan de respuesta a incidentes documentados, o no formar a los empleados.
9. Cumplimiento de los proveedores: Asumir que los proveedores de servicios de terceros cumplen las normas sin verificar o tener acuerdos contractuales adecuados.
10. Tratar el cumplimiento como algo anual: Considerar la norma PCI DSS como una mera auditoría/SAQ anual en lugar de un proceso de seguridad continuo.

Lo que podrían preguntar los auditores/QSA (Enfoque en el desarrollador)

Un evaluador de seguridad cualificado (QSA) que realice una auditoría para PCI DSS comprobará las prácticas de desarrollo relacionadas con el requisito 6 (sistemas y software seguros):

• (Req 6.2) "Describa sus procesos de ciclo de vida de desarrollo de software seguro (SSDLC)".
• (Req 6.2.1) "¿Cómo se desarrolla el software personalizado y a medida basándose en las normas del sector y/o PCI DSS (por ejemplo, directrices de codificación segura como OWASP)?"
• (Req 6.2.2) "¿Cómo se forma a los desarrolladores en técnicas de codificación segura?" (Mostrar registros de formación)
• (Req 6.2.3) "¿Cómo se revisan los cambios de código para detectar vulnerabilidades de seguridad antes de su publicación?" (Describa el proceso de revisión del código)
• (Req 6.2.4) "¿Cómo se garantiza la separación de funciones entre los entornos de desarrollo/prueba y producción?"
• (Req 6.3) "¿Cómo identifican e inventariar el software a medida y personalizado?"
• (Req 6.4 - v4.0) "¿Cómo se gestionan los scripts de las páginas de pago para garantizar la integridad y autorizar los scripts?" (Relevante para desarrolladores web)
• (Req 6.5 - v3.2.1 / varios en v4.0) "¿Cómo se protege contra las vulnerabilidades comunes de codificación como fallos de inyección, desbordamientos de búfer, almacenamiento criptográfico inseguro, XSS, etc.?" (Requiere mostrar ejemplos de código, uso de herramientas - SAST/DAST)
• (Req 3) "Mostrar cómo se protegen los datos sensibles (PAN) en el almacenamiento (cifrado, hashing, truncamiento) dentro de la aplicación."
• (Req 4) "Demostrar cómo se encriptan los datos sensibles durante la transmisión".
• (Req 8) "¿Cómo aplica la aplicación los requisitos de complejidad de contraseñas y MFA?"

Las QSA necesitan pruebas de los procesos documentados, la formación de los desarrolladores, el cumplimiento de las normas de codificación segura, las revisiones del código, los resultados de las pruebas de seguridad (SAST/DAST) y la configuración segura de la aplicación.

Ganancias rápidas para los equipos de desarrollo

Los desarrolladores pueden contribuir significativamente al cumplimiento de la norma PCI DSS:

1. NUNCA almacene DUA: Asegúrese de que el código nunca registra, almacena o retiene CVV2, datos de seguimiento o PIN después de la autorización.
2. Minimice la manipulación de CHD: Si es posible, utilice procesadores/pasarelas de pago de terceros que mantengan los CHD totalmente fuera de sus sistemas (reduciendo el alcance). Si tiene que manipularlo, minimice el lugar por donde fluye y se almacena.
3. Conceptos básicos de codificación segura: Se centra en la prevención de las 10 principales vulnerabilidades OWASP, especialmente la inyección (SQLi, inyección de comandos) y Cross-Site Scripting (XSS), a través de la validación de entrada y la codificación de salida.
4. Parametrice las consultas a la base de datos: Utilice siempre sentencias preparadas o consultas parametrizadas para evitar la inyección de SQL.
5. Cifrar/Hash/Tokenizar PAN: Si almacena PAN, utilice un cifrado fuerte y estándar (AES-256) con una gestión de claves adecuada, o considere soluciones de tokenización. No desarrolle su propia criptografía.
6. Utilice TLS seguro: Asegúrese de que todas las transmisiones de CHD utilicen versiones TLS actuales y seguras y suites de cifrado seguras.
7. Aplicar la validación de entradas: Valide rigurosamente todas las entradas procedentes de usuarios o sistemas externos.
8. Aplique cabeceras de seguridad: Utilice cabeceras de seguridad HTTP (como Content-Security-Policy) para mitigar XSS y otros ataques del lado del cliente, especialmente importante para Req 6.4 en v4.0.

Ignore esto y... (Consecuencias del incumplimiento)

Ignorar la norma PCI DSS puede ser perjudicial desde el punto de vista financiero y devastador para la reputación:

• Multas mensuales: Los bancos adquirentes imponen fuertes multas por incumplimiento, que suelen oscilar entre 5.000 y más de 100.000 dólares al mes, y que aumentan en función del nivel de cumplimiento y de la duración del incumplimiento.
• Aumento de las comisiones por transacción: Los bancos pueden aumentar las comisiones por transacción a los comerciantes que incumplan la normativa.
• Penalizaciones de las marcas de tarjetas: Las marcas de tarjetas pueden imponer directamente sanciones adicionales.
• Cancelación del procesamiento de tarjetas: Los bancos pueden revocar por completo la capacidad de aceptar tarjetas de pago, cerrando de hecho los flujos de ingresos por pago con tarjeta.
• Costes de la violación de datos: Si el incumplimiento conduce a una violación, los costes se disparan. Esto incluye investigaciones forenses, costes de sustitución de tarjetas (más de 3-5 dólares por tarjeta), supervisión del crédito de las víctimas, honorarios de abogados, multas reglamentarias (por ejemplo, GDPR si procede) y posibles demandas judiciales.
• Daños a la reputación: La divulgación pública de un incumplimiento o de una filtración de datos de tarjetas daña gravemente la confianza de los clientes y la imagen de marca.
• Mayor escrutinio: Tras un incumplimiento o una infracción, las organizaciones se enfrentan a un escrutinio más intenso por parte de los bancos y las marcas de tarjetas.

PREGUNTAS FRECUENTES

¿Quién debe cumplir la norma PCI DSS?

Cualquier organización que acepte, procese, almacene o transmita datos de titulares de tarjetas de las principales marcas de tarjetas (Visa, Mastercard, American Express, Discover, JCB). Esto incluye a comerciantes, proveedores de servicios (como procesadores de pagos, proveedores de alojamiento) e instituciones financieras.

¿Cuál es la diferencia entre PCI DSS v3.2.1 y v4.0?

PCI DSS v4.0 es la última versión, que sustituye a la v3.2.1 (que se retira el 31 de marzo de 2024, aunque los nuevos requisitos de la v4.0 son mejores prácticas hasta el 31 de marzo de 2025). Entre los principales cambios de la versión 4.0 figuran la actualización de los requisitos sobre contraseñas y AMF, la ampliación de la aplicabilidad de los controles de seguridad, la introducción de nuevos requisitos contra la suplantación de identidad (phishing) y los ataques al comercio electrónico, una orientación más clara y la introducción de un "enfoque personalizado" como forma alternativa de cumplir los objetivos de los requisitos, junto con el tradicional "enfoque definido".

¿Qué son los niveles de vendedor y de proveedor de servicios?

Clasifican a las organizaciones en función del volumen anual de transacciones con tarjeta que procesan. El nivel 1 (mayor volumen) tiene los requisitos de validación más estrictos (ROC anual por QSA, escaneos ASV trimestrales). Los niveles 2, 3 y 4 tienen volúmenes progresivamente menores y suelen validarse mediante SAQ anuales y escaneos ASV trimestrales.

¿Qué es un QSA y un ASV?

Un QSA (Qualified Security Assessor) es una persona certificada por el PCI SSC para realizar evaluaciones PCI DSS in situ y elaborar Informes de Cumplimiento (ROC) para comerciantes/proveedores de servicios de Nivel 1. Un ASV (Approved Scanning Vendor) es una organización certificada por el PCI SSC para realizar las exploraciones trimestrales de vulnerabilidad de la red externa requeridas.

¿Qué es el Entorno de Datos de Titulares de Tarjeta (CDE)?

El CDE comprende las personas, los procesos y la tecnología que almacenan, procesan o transmiten datos de titulares de tarjetas o datos confidenciales de autenticación. Definir con precisión el alcance del CDE es el primer paso crítico en el cumplimiento de PCI DSS, ya que los requisitos se aplican principalmente dentro de este entorno. La segmentación de la red puede utilizarse para reducir el alcance del CDE.

¿Se puede almacenar el código CVV2?

No. Los Datos Sensibles de Autenticación (DAS), que incluyen el código de verificación de 3 ó 4 dígitos de la tarjeta (CVV2, CVC2, CID, CAV2), los datos completos de la banda magnética y los PIN, no deben almacenarse nunca una vez completada la autorización de la transacción. Almacenar DUA es una infracción grave de la normativa.

¿Es obligatorio por ley cumplir la normativa PCI DSS?

Aunque PCI DSS es una norma del sector creada por las marcas de tarjetas, su cumplimiento suele exigirse contractualmente mediante acuerdos entre los comerciantes, los bancos adquirentes y las marcas de tarjetas. El incumplimiento de estos contratos da lugar a sanciones impuestas por los bancos o las marcas. También puede coincidir con requisitos legales como el GDPR si se trata de datos personales.