PCI DSS para comercios: qué necesitas si aceptas tarjetas
PCI DSS es el estándar de seguridad de la industria de medios de pago. No es una ley, es una obligación contractual: te la imponen las marcas de tarjeta a través de tu banco adquirente, y su incumplimiento puede acarrear multas o la pérdida de la capacidad de cobrar.
Tu nivel depende del volumen
Los niveles van del 1 (más de 6 millones de transacciones anuales, con auditoría por un QSA) al 4 (menos de 20.000 transacciones ecommerce, con autoevaluación). La mayoría de pymes están en niveles 3 y 4 y cumplen mediante un cuestionario SAQ.
Reducir el alcance es la mejor estrategia
Cuantos menos sistemas toquen datos de tarjeta, menos te exige el estándar. Externalizar el pago a una pasarela con redirección o iframe (SAQ A) reduce drásticamente los requisitos frente a procesar los datos en tu propio servidor (SAQ D).
Qué pruebas técnicas exige
- › Escaneos trimestrales de vulnerabilidades externas por un ASV aprobado.
- › Escaneos internos trimestrales y tras cambios significativos.
- › Pruebas de penetración anuales, internas y externas (requisito 11.4).
- › Pruebas de segmentación si usas segmentación para reducir el alcance.
Ojo con la confusión más común: un escaneo automático ASV no sustituye al pentesting. Son requisitos distintos y el estándar los exige por separado.
Los cuatro niveles de comerciante
PCI DSS no exige lo mismo a todos. El nivel depende del volumen anual de transacciones con tarjeta y determina si basta un cuestionario de autoevaluación o hace falta una auditoría presencial por un evaluador certificado.
| Nivel | Volumen anual aproximado | Qué se exige |
|---|---|---|
| 1 | Más de 6 millones de transacciones | Auditoría anual por evaluador certificado (QSA) |
| 2 | De 1 a 6 millones | Cuestionario de autoevaluación y escaneos trimestrales |
| 3 | De 20.000 a 1 millón en comercio electrónico | Cuestionario de autoevaluación y escaneos trimestrales |
| 4 | Menos de 20.000 en comercio electrónico | Cuestionario de autoevaluación, según lo que pida el adquirente |
Qué cambió con la versión 4.0
La versión 4.0 sustituyó a la 3.2.1 y trajo dos cambios que se notan. El primero es el enfoque personalizado: se permite cumplir un objetivo con un control distinto al prescrito, siempre que se documente y se valide. El segundo es que endureció la protección del comercio electrónico frente a la manipulación de scripts en la página de pago, que es por donde entran los ataques de robo de tarjeta más habituales.
El error que dispara el coste
Definir mal el alcance. Todo sistema que almacena, procesa o transmite datos de tarjeta entra, y también todo el que esté conectado a esos sin segmentación efectiva. Una red plana convierte la empresa entera en entorno de datos de tarjeta, y la diferencia de coste entre auditar doce servidores y auditar cuatrocientos no necesita explicación.
El comercio electrónico añade un frente propio. Desde la versión 4.0 hay que inventariar y vigilar los scripts que se cargan en la página de pago, porque basta con que uno de un tercero se altere para que las tarjetas se copien antes de llegar a la pasarela. Es un ataque que no toca tus servidores y que responde igualmente tu comercio. Por eso la segmentación se prueba, no se declara. Si dices que el entorno de pago está aislado, el evaluador va a pedir la evidencia de que ese aislamiento resiste.
Qué aportamos
La prueba de intrusión anual que exige el estándar, y la que toca después de cada cambio significativo. Auditamos la aplicación de pago, la red donde vive y la segmentación que la separa del resto, además de las API por las que circula la transacción. Cada hallazgo va con evidencia y con los pasos para reproducirlo, y el retest a los seis meses cierra el ciclo que el evaluador quiere ver documentado.
Cómo lo abordamos
Los servicios con los que resolvemos lo que cuenta este artículo:
- ›Pentesting de aplicaciones web · Pentesting manual de tu aplicación web contra OWASP WSTG: la lógica de negocio rota y los accesos que no deberían existir.
- ›Pentesting de APIs · Pentesting de tus APIs REST y GraphQL con el OWASP API Top 10, empezando por la autorización a nivel de objeto.
- ›Auditoría de superficie externa · Auditoría de todo lo que expones a Internet: subdominios que nadie recuerda, servicios abiertos y credenciales filtradas en brechas ajenas.