En un artículo anterior planteamos por qué el inventario de datos de tarjeta que casi toda organización presenta en su auditoría rara vez coincide con lo que de verdad hay en sus sistemas, y por qué construirlo "preguntando" es la causa raíz de esa brecha. Partiendo de esta premisa exploraremos como realizar un proceso de descubrimiento de datos que: permita controlar el inventario de la organización, sea sostenible en el tiempo y en el camino intentaremos responder: ¿por qué esa brecha es tanto un problema de seguridad como de cumplimiento?, ¿y cómo se ejecuta en la práctica un proceso de descubrimiento que ayude a identificar y mantener de forma sostenida en el tiempo?
Un atacante que ha comprometido un sistema busca el camino de menor resistencia hacia el dato de valor, ese camino rara vez pasa por el CDE (Cardholder Data Environment – Entorno de datos de tarjetahabiente) bien defendido. Pasa por las copias olvidadas de ese mismo dato que viven fuera de él: sin cifrar, sin segmentar, sin nadie revisando los logs de acceso. Ejemplos de escenarios mal protegidos se encuentran lastimosamente todos los días: un volcado de staging en un servidor sin bastionado, un log legible por cualquier proceso del host, un contenedor de correo con años de adjuntos, una captura de pantalla subida como evidencia a un ticket de soporte.
Ninguno de estos puntos está cubierto por la prevención de fuga de datos perimetral, una herramienta DLP (Data Loss Prevention – Prevención de pérdida de datos) no puede frenar la salida de un dato que no sabe que está ahí. La monitorización no salta sobre un fichero que nadie marcó como sensible. No se puede proteger lo que no se ha descubierto, ni monitorizar una vía de exfiltración que no se sabe que existe.
Hacerlo bien implica identificar todos los flujos donde transita, procesa o almacenan datos de tarjetahabiente (CHD - Cardholder Data) o datos sensibles de autenticación (SAD- Sensitive Authentication Data), no solo los obvios. Es fácil identificar el sistema de pagos principal; lo que realmente aporta valor es encontrar los flujos secundarios: la integración con el ERP, el módulo de reembolsos, la gestión de PQR, por poner algunos ejemplos.
El error metodológico más común es abordar esto preguntando al área de TI “¿qué sistemas almacenan tarjetas?”. Esa pregunta siempre da una respuesta incompleta, porque TI conoce su inventario, no necesariamente el negocio. La recomendación es hacer estas entrevistas estructuradas por proceso, no por sistema. Para cada canal o proceso se documenta quién captura el dato, por dónde viaja, dónde se detiene (aunque sea temporalmente) y quién más lo puede ver. Preguntas simples destapan flujos ocultos:
▪️“¿Alguna vez han tenido que resolver un problema de un pago exportando datos a Excel?”
▪️“¿Qué hace el equipo cuando un cliente reclama un cargo, o pide el número de tarjeta por correo o chat?”
El escaneo técnico dirigido complementa esas entrevistas usando patrones de PAN (Primary account number – número primario de cuenta), expresiones regulares por marca, validadas con el algoritmo de Luhn como segundo filtro, cualquier número de 16 dígitos que empiece por 4 hace “match” con Visa, aunque sea un número de factura interno, así que la expresión regular sola no basta.
La Etapa 1 se cierra normalmente con:
▪️Inventario de repositorios, cada uno marcado como “confirmado” o “descartado”.
▪️Diagrama de flujo de datos.
▪️Lista de sistemas conectados, justificada.
▪️Definición preliminar del CDE, lista para pasar a validación.
Esta etapa invierte la carga de la prueba, todo lo NO confirmado se asume en alcance, hasta que se demuestre lo contrario. Esto tiene una consecuencia práctica importante, sobre los repositorios en alcance dudoso, la búsqueda ya no es un muestreo, es cobertura total, el estándar es revisar todo, no se hace sobre una muestra estadística.
Con ese estándar de cobertura total, y con la profundidad técnica que exige buscar donde el PAN realmente puede haber acabado, la validación se ejecuta en tres frentes simultáneos:
▪️Componentes de sistema: lo ya inventariado, pero validado técnicamente con esa misma profundidad,
no solo confirmado por documentación.
▪️Red corporativa: segmentos fuera del CDE con conectividad no controlada hacia él, verificados con pruebas
de segmentación reales, no solo revisión de reglas de firewall en papel.
▪️Terceros y proveedores: validados contractual y técnicamente. No basta con la cláusula del contrato; hay que
confirmarlo con evidencia, logs de transferencia, especificación de los payloads compartidos. No es raro encontrar
un proveedor que recibe “solo métricas” pero cuyo payload completo incluye el PAN sin que nadie lo evidenciara.
Operativizar este proceso exige definir cuatro elementos, idealmente en un proceso formal:
▪️Cadencia por criticidad:
▫️Alta criticidad (bases de datos del CDE, integraciones activas) en ciclo trimestral o mensual
▫️Criticidad media (file shares, soporte) en semestral
▫️Baja probabilidad, pero no descartable (entornos de desarrollo, backups históricos) en anual.
▪️Disparadores fuera de calendario: cambios de infraestructura, nuevas integraciones o incidentes de seguridad deben activar una revisión inmediata, sin esperar la fecha programada.
▪️Responsables: quién ejecuta, quién revisa los hallazgos, quién aprueba el cierre.
1. Dictado en una grabación: Los call center capturan datos de tarjeta por voz constantemente, y muchas de esas llamadas se graban por motivos de calidad o cumplimiento y se acumulan durante años. Un número dictado al agente, o introducido mediante el teclado del teléfono durante un IVR, queda registrado como audio o como tonos DTMF. Ninguna búsqueda de ficheros lo detecta, identificarlo exige analizar el contenido del audio, o aplicar enmascaramiento de DTMF en el momento de la captura, antes de que el tono quede traducido a texto en un log.
2. Anidado en capas: Un adjunto dentro de un correo, dentro de un contenedor de buzón, dentro de una copia de seguridad. Un fichero de texto dentro de un ZIP, dentro de un documento ofimático que a su vez es un contenedor comprimido, dentro de otro archivo. Cada capa de envoltura es una barrera más para una búsqueda superficial. La herramienta que solo mira el primer nivel ve un fichero comprimido y pasa de largo. El PAN está tres capas más adentro, esperando.
3. Dentro de una imagen: Un PDF escaneado de un formulario de pago, una captura de pantalla del terminal de punto de venta, una fotografía de una tarjeta que un cliente envió "para confirmar el pago", para cualquier búsqueda de texto, estos ficheros son opacos, no contienen caracteres, contienen píxeles. El número de tarjeta está perfectamente legible para un ojo humano y completamente invisible para herramientas de sistema como grep en Linux o Unix, solo una herramienta que aplique reconocimiento óptico de caracteres (OCR) sobre el contenido visual encuentra lo que hay.
4. Datos que se creían borrados: Un fichero con números de tarjeta “borrado” hace meses puede seguir íntegro en el espacio no asignado del disco. Para las herramientas que solo ven el sistema de ficheros vivo, ese dato no existe. Para un análisis del espacio libre, está perfectamente recuperable, y eso significa que también lo está para quien tenga acceso al disco.
El grep no ve dentro de una imagen ni escucha un audio, el DLP no inspecciona el espacio libre, el script casero no entra recursivamente en contenedores anidados. Cada punto ciego es, en el fondo, una capacidad que falta y la pregunta para cualquier organización que maneja datos de tarjeta no es si tiene PANs fuera de control, casi con certeza los tiene. La pregunta es si dispone de la capacidad de encontrarlos antes de que lo haga una auditoría, o alguien con malas intenciones.
Por qué esto no es solo cumplimiento, es defensa
Hemos hablado de la búsqueda de datos como un problema de inventario, pero conviene indicar que el costo de tener datos huérfanos no es solamente de cumplimiento, el costo real es de exposición, y para entender por qué, hay que mirar el problema desde el otro lado: el del atacante.Un atacante que ha comprometido un sistema busca el camino de menor resistencia hacia el dato de valor, ese camino rara vez pasa por el CDE (Cardholder Data Environment – Entorno de datos de tarjetahabiente) bien defendido. Pasa por las copias olvidadas de ese mismo dato que viven fuera de él: sin cifrar, sin segmentar, sin nadie revisando los logs de acceso. Ejemplos de escenarios mal protegidos se encuentran lastimosamente todos los días: un volcado de staging en un servidor sin bastionado, un log legible por cualquier proceso del host, un contenedor de correo con años de adjuntos, una captura de pantalla subida como evidencia a un ticket de soporte.
Ninguno de estos puntos está cubierto por la prevención de fuga de datos perimetral, una herramienta DLP (Data Loss Prevention – Prevención de pérdida de datos) no puede frenar la salida de un dato que no sabe que está ahí. La monitorización no salta sobre un fichero que nadie marcó como sensible. No se puede proteger lo que no se ha descubierto, ni monitorizar una vía de exfiltración que no se sabe que existe.
La metodología: cómo hacer un buen descubrimiento
El proceso de descubrimiento no es una tarea puntual, es un ciclo continuo con tres momentos que se apoyan uno en el otro. El primero fundamenta el terreno, el segundo lo valida sin concesiones, y el tercero sostiene esa higiene en el tiempo, porque el entorno cambia constantemente.Etapa 1: Fundamentar el descubrimiento en el análisis de brechas
Esta es la foto inicial que define todo lo que viene después. Si sale mal, todo el proceso posterior hereda ese error; de hecho, la mayoría de las brechas de cumplimiento nacen exactamente aquí, en una definición de alcance incompleta.Hacerlo bien implica identificar todos los flujos donde transita, procesa o almacenan datos de tarjetahabiente (CHD - Cardholder Data) o datos sensibles de autenticación (SAD- Sensitive Authentication Data), no solo los obvios. Es fácil identificar el sistema de pagos principal; lo que realmente aporta valor es encontrar los flujos secundarios: la integración con el ERP, el módulo de reembolsos, la gestión de PQR, por poner algunos ejemplos.
El error metodológico más común es abordar esto preguntando al área de TI “¿qué sistemas almacenan tarjetas?”. Esa pregunta siempre da una respuesta incompleta, porque TI conoce su inventario, no necesariamente el negocio. La recomendación es hacer estas entrevistas estructuradas por proceso, no por sistema. Para cada canal o proceso se documenta quién captura el dato, por dónde viaja, dónde se detiene (aunque sea temporalmente) y quién más lo puede ver. Preguntas simples destapan flujos ocultos:
▪️“¿Alguna vez han tenido que resolver un problema de un pago exportando datos a Excel?”
▪️“¿Qué hace el equipo cuando un cliente reclama un cargo, o pide el número de tarjeta por correo o chat?”
El escaneo técnico dirigido complementa esas entrevistas usando patrones de PAN (Primary account number – número primario de cuenta), expresiones regulares por marca, validadas con el algoritmo de Luhn como segundo filtro, cualquier número de 16 dígitos que empiece por 4 hace “match” con Visa, aunque sea un número de factura interno, así que la expresión regular sola no basta.
La Etapa 1 se cierra normalmente con:
▪️Inventario de repositorios, cada uno marcado como “confirmado” o “descartado”.
▪️Diagrama de flujo de datos.
▪️Lista de sistemas conectados, justificada.
▪️Definición preliminar del CDE, lista para pasar a validación.
Etapa 2: Validar el alcance e invertir la carga de la prueba
En esta fase cambia el principio rector, la etapa 1 es descubrimiento dirigido por hipótesis de negocio: entrevistamos, mapeamos, construimos una teoría de dónde están los datos. La etapa 2 es verificación exhaustiva e independiente de esa teoría, incluyendo lo que el negocio no mencionó, no conoce o recuerda.Esta etapa invierte la carga de la prueba, todo lo NO confirmado se asume en alcance, hasta que se demuestre lo contrario. Esto tiene una consecuencia práctica importante, sobre los repositorios en alcance dudoso, la búsqueda ya no es un muestreo, es cobertura total, el estándar es revisar todo, no se hace sobre una muestra estadística.
Con ese estándar de cobertura total, y con la profundidad técnica que exige buscar donde el PAN realmente puede haber acabado, la validación se ejecuta en tres frentes simultáneos:
▪️Componentes de sistema: lo ya inventariado, pero validado técnicamente con esa misma profundidad,
no solo confirmado por documentación.
▪️Red corporativa: segmentos fuera del CDE con conectividad no controlada hacia él, verificados con pruebas
de segmentación reales, no solo revisión de reglas de firewall en papel.
▪️Terceros y proveedores: validados contractual y técnicamente. No basta con la cláusula del contrato; hay que
confirmarlo con evidencia, logs de transferencia, especificación de los payloads compartidos. No es raro encontrar
un proveedor que recibe “solo métricas” pero cuyo payload completo incluye el PAN sin que nadie lo evidenciara.
Etapa 3: Operativizar las validaciones periódicas (BAU)
La certificación no es la meta, es el punto de partida de la vigilancia continua. Una vez certificados, el riesgo no desaparece cambia de naturaleza. Aparecen nuevos flujos de negocio, configuraciones que “revierten” con el tiempo (logs que vuelven a capturar el payload completo tras una actualización), personal nuevo que reintroduce prácticas riesgosas sin conocer el historial de hallazgos. Sin un proceso activo después de la certificación, en doce meses se puede acabar exactamente en el mismo punto de partida.Operativizar este proceso exige definir cuatro elementos, idealmente en un proceso formal:
▪️Cadencia por criticidad:
▫️Alta criticidad (bases de datos del CDE, integraciones activas) en ciclo trimestral o mensual
▫️Criticidad media (file shares, soporte) en semestral
▫️Baja probabilidad, pero no descartable (entornos de desarrollo, backups históricos) en anual.
▪️Disparadores fuera de calendario: cambios de infraestructura, nuevas integraciones o incidentes de seguridad deben activar una revisión inmediata, sin esperar la fecha programada.
▪️Responsables: quién ejecuta, quién revisa los hallazgos, quién aprueba el cierre.
Los puntos ciegos donde el PAN sobrevive invisible
El número de tarjeta en muchas ocasiones “se esconde” por la complejidad acumulada de los sistemas reales, y casi siempre en formatos que las búsquedas convencionales no saben leer. Ya hemos hablado del por qué (cumplimiento y defensa) y del cómo se organiza el proceso (las tres etapas). Queda la parte más concreta, los sitios exactos donde el PAN sigue ahí, invisible para las herramientas que la mayoría de las organizaciones emplean para buscarlo.1. Dictado en una grabación: Los call center capturan datos de tarjeta por voz constantemente, y muchas de esas llamadas se graban por motivos de calidad o cumplimiento y se acumulan durante años. Un número dictado al agente, o introducido mediante el teclado del teléfono durante un IVR, queda registrado como audio o como tonos DTMF. Ninguna búsqueda de ficheros lo detecta, identificarlo exige analizar el contenido del audio, o aplicar enmascaramiento de DTMF en el momento de la captura, antes de que el tono quede traducido a texto en un log.
2. Anidado en capas: Un adjunto dentro de un correo, dentro de un contenedor de buzón, dentro de una copia de seguridad. Un fichero de texto dentro de un ZIP, dentro de un documento ofimático que a su vez es un contenedor comprimido, dentro de otro archivo. Cada capa de envoltura es una barrera más para una búsqueda superficial. La herramienta que solo mira el primer nivel ve un fichero comprimido y pasa de largo. El PAN está tres capas más adentro, esperando.
3. Dentro de una imagen: Un PDF escaneado de un formulario de pago, una captura de pantalla del terminal de punto de venta, una fotografía de una tarjeta que un cliente envió "para confirmar el pago", para cualquier búsqueda de texto, estos ficheros son opacos, no contienen caracteres, contienen píxeles. El número de tarjeta está perfectamente legible para un ojo humano y completamente invisible para herramientas de sistema como grep en Linux o Unix, solo una herramienta que aplique reconocimiento óptico de caracteres (OCR) sobre el contenido visual encuentra lo que hay.
4. Datos que se creían borrados: Un fichero con números de tarjeta “borrado” hace meses puede seguir íntegro en el espacio no asignado del disco. Para las herramientas que solo ven el sistema de ficheros vivo, ese dato no existe. Para un análisis del espacio libre, está perfectamente recuperable, y eso significa que también lo está para quien tenga acceso al disco.
El grep no ve dentro de una imagen ni escucha un audio, el DLP no inspecciona el espacio libre, el script casero no entra recursivamente en contenedores anidados. Cada punto ciego es, en el fondo, una capacidad que falta y la pregunta para cualquier organización que maneja datos de tarjeta no es si tiene PANs fuera de control, casi con certeza los tiene. La pregunta es si dispone de la capacidad de encontrarlos antes de que lo haga una auditoría, o alguien con malas intenciones.
Cómo se ve esto en la práctica
La Etapa 3 la vigilancia periódica, no la foto única es la parte que más organizaciones se saltan, porque no deja un entregable único que enseñar en la auditoría. En Internet Security Auditors usamos y proponemos CardExpose Scanner para alcanzar este objetivo: cada ciclo de escaneo cierra con un resumen ejecutivo que cuantifica los hallazgos, los ficheros analizados, la severidad y la distribución por marca y tipo de archivo, y que además separa las tarjetas de prueba conocidas de la exposición real, para no hacer perder tiempo al equipo investigando falsos positivos ya conocidos.
CardExpose Scanner es parte de la Suite que incluye una Consola que permite orquestar los escaneos gestionados a través de Agentes desplegados en la infraestructura de la empresa en los sistemas soportados que incluyen Windows Desktop, Linux y MacOS en equipos de escritorio y Windows Server, Linux Server, Solaris Intel/SPARC, AIX, IBM iSeries (AS/400) y Linux s390x para IBM Z en servidores, midframe y mainframe con todas las capacidades disponibles en todas las plataformas soportadas.
Resumen ejecutivo de un ciclo de escaneo en CardExpose
Ese resumen es, en la práctica, el artefacto que convierte la Etapa 3 en un proceso real y no en una intención, proporciona al rol responsable dentro de la organización algo concreto que revisar en cada ciclo, y permite comparar de un ciclo a otro si la superficie de exposición real está creciendo o encogiendo que es al final, la única métrica que importa una vez que el inventario ya se verificó una primera vez.
