La mayoría de las organizaciones cumplen el inventario de datos de tarjeta exigido por PCI DSS sobre el papel o en su confianza de que así es. El problema empieza cuando alguien comprueba si ese papel se corresponde con la realidad.
Hay un requisito de PCI DSS v4.0 que genera menos debate del que debería: el 12.5.2, que obliga a mantener un inventario actualizado de todas las ubicaciones donde residen datos de titulares de tarjeta. Sobre el papel es sencillo. En la práctica, es donde se concentra una de las brechas más comunes que encontramos al auditar.
El motivo es casi siempre el mismo. El inventario se construye preguntando. Se reúne a los responsables de cada sistema y se les pregunta dónde guardan datos de tarjeta. Cada uno responde con lo que sabe, se consolida en un documento, y ese documento se presenta como el inventario de scope. El problema es que la pregunta «¿dónde guardan datos de tarjeta?» solo captura los lugares donde alguien decidió conscientemente guardar datos de tarjeta. Y esos no son, por desgracia, todos los lugares donde el dato acaba.
El entorno de datos de titulares que una organización declara es el que ha diseñado: la base de datos de transacciones, el sistema de pago, los componentes que tocan el PAN por diseño. El CDE real incluye todo eso más una larga lista de lugares donde el dato llegó sin que figurara en ningún diagrama de arquitectura.
Algunos de los más habituales:
▪️Logs de aplicación que registran peticiones completas, incluido el cuerpo de la transacción
con el PAN en claro, porque alguien activó el nivel de log de depuración y nunca lo desactivó.
▪️Bases de datos de staging o preproducción con copias de tablas de producción, sin
enmascarar, creadas para un proyecto puntual y olvidadas después.
▪️Adjuntos de correo: una hoja de cálculo con números de tarjeta que un departamento envió a
otro, ahora residente en varios buzones y en sus copias de seguridad.
▪️Todo tipo de ficheros actuales, pero también olvidados en espacios de disco, servidores de
ficheros, almacenamientos compartidos en la nube.
▪️Archivos comprimidos por usuarios y/o aplicaciones, con formatos de compresión poco
usados, incluso sólo usados por esas aplicaciones.
▪️Ficheros temporales, exportaciones manuales, volcados de incidencias generados durante una
resolución de problemas y nunca eliminados.
Ninguno de estos lugares aparece cuando se pregunta. No porque nadie quiera ocultarlos, sino porque nadie los recuerda — o nunca supo que existían. El log de depuración lo activó un desarrollador hace dos años. La copia de staging la creó un equipo que ya no está. El adjunto lo envió alguien que consideró que era lo más práctico en ese momento.
Captura 1: Configuración de búsquedas avanzadas de CardExpose
Un inventario construido preguntando solo recoge lo que la organización recuerda. El dato de tarjeta no reside donde se recuerda — reside donde acaba.
La capacidad que realmente cierra la brecha es la que mira donde el dato puede haber acabado, no donde se supone que debería estar: que entra recursivamente en archivos comprimidos y contenedores anidados, que aplica reconocimiento óptico sobre imágenes, que se conecta a los motores de base de datos, que recorre los contenedores de correo. Y que valida cada hallazgo con rigor —algoritmo de Luhn, contraste con rangos de emisor, análisis de contexto y cualificación de criticidad de hallazgos para la facilitar la identificación de falsos positivos— para que el resultado sea accionable y no una avalancha de falsos positivos que el equipo acabe ignorando.
Captura 3: Gestión de hallazgos de CardExpose