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.
La diferencia entre el CDE declarado y el CDE real
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.
Verificar no es lo mismo que declarar
La forma de cerrar esta brecha es conceptualmente simple: no preguntar dónde está el dato, sino buscarlo. Verificar técnicamente, sobre los sistemas reales, dónde aparecen patrones que corresponden a números de tarjeta. Esto convierte el inventario de una declaración de buena fe en el resultado de una comprobación.Pero hacerlo bien tiene una exigencia que conviene no subestimar. Un PAN no siempre está donde una búsqueda de texto plano lo encontraría. Puede estar dentro de un documento ofimático comprimido, dentro de un adjunto dentro de un contenedor de correo, dentro de una imagen escaneada que ninguna búsqueda textual va a leer, o en una tabla de una base de datos a la que el inventario nunca llegó. Una verificación que solo mire ficheros de texto en rutas conocidas reproduce la misma ceguera que tenía el inventario declarado, solo que con un disfraz técnico.
Captura 2: Configuración "simple" de CardExpose
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.
El inventario como verificación, no como trámite
Cuando un inventario se construye así, deja de ser el documento que se actualiza una vez al año para pasar la auditoría y se convierte en lo que la norma pretendía que fuera: una imagen fiel de dónde está realmente el dato sensible. La diferencia entre ambas cosas no es burocrática. Es la diferencia entre creer que se controla el scope y controlarlo de verdad.En las auditorías que realizamos, el inventario declarado y el inventario verificado a veces no coinciden completamente. La distancia entre uno y otro es, casi siempre, la medida exacta del riesgo que la organización no sabía que tenía y un importante incumplimiento de PCI DSS.
Contar con un servicio de búsqueda de datos que pueda contar con la herramienta más potente del mercado en la búsqueda de datos en cualquier lugar que pueda imaginarse, es el punto clave.
El Equipo de Internet Security Auditors cuenta con el conocimiento y la herramienta adecuada: CardExpose.
Captura 3: Gestión de hallazgos de CardExpose
