LESIS - Laboratory of Engineering Studies in Information Security

Nunca la misma IP dos veces: construyendo cf-proxy con Cloudflare Workers

2026-10-11T09:00:00-03:00

Introducción

Durante un pentest es habitual tener que cambiar la dirección IP momentáneamente por algún motivo. Quizá estés intentando hacer peticiones sucesivas a un endpoint con un rate limit basado en IP, quizá tu IP actual haya sido bloqueada por un firewall a raíz de una prueba anterior (o simplemente porque tu proveedor tiene mala reputación). Sea cual sea el motivo, seguramente alguna vez en la vida tuviste que conectarte a una VPN o a un proxy.

Pero cuando esto ocurre durante una evaluación de seguridad, el problema normalmente no termina ahí. Si te bloquearon una vez, es muy probable que te bloqueen de nuevo pronto y necesites una forma de volver a cambiar la dirección. Con el tiempo esto se vuelve muy molesto, sobre todo si el objetivo está baneando tu IP con demasiada frecuencia y estás haciendo una prueba sensible al tiempo. En esta situación, la mejor opción sería automatizar la rotación de direcciones IP para que dos peticiones consecutivas nunca provengan del mismo origen.

Hay algunos servicios que ofrecen esta funcionalidad, pero encontrar uno bueno es difícil. La mayoría están pensados para crawlers y empresas de data scraping y cobran caro por proporcionar direcciones IP con buena reputación para evitar que el tráfico se marque como automatizado. Los más baratos te dan direcciones de un pool de proveedores de nube (AWS, GCP, Oracle, etc.), que tienen muchas probabilidades de ser detectadas como sospechosas o automatizadas, mientras que los servicios que sí ofrecen proxies residenciales con direcciones de ISPs comunes pueden ser muy turbios (algunos incluso venden servicios ilegales sostenidos por botnets).

En este escenario, una herramienta como cf-proxy puede marcar la diferencia. Para empezar, un plan de Workers es bastante barato (US$ 5,00/mes te dan 10 millones de peticiones) y requiere poca configuración. Solo configuras las opciones de proxy en el cliente que estés usando y cada conexión tendrá una dirección distinta casi siempre, así que no tienes que preocuparte por tener varios proxies para alternar en round-robin. Y en cuanto a reputación, una dirección IP de Cloudflare no está nada mal, ya que suelen ser de confianza e incluso figurar en listas de permitidos. Dicen que 1 de cada 5 sitios de internet usa sus servicios, así que bloquear sus ASN puede ser muy peligroso para algunos proveedores de nube.

Dicho esto, usar un worker como proxy no está exento de limitaciones. La mayor es que Cloudflare no permite conexiones TCP salientes hacia sus propios rangos de IP, así que tendrás problemas para conectarte a sitios que están detrás de su reverse proxy (que son muchos). También se niega a conectar al puerto 25/TCP (normalmente dedicado a SMTP) de cualquier objetivo, pero eso no suele ser un gran inconveniente.

Qué es cf-proxy y cómo funciona

cf-proxy es una utilidad que permite enrutar tu tráfico a través de la red global de servidores de Cloudflare, enmascarando la dirección IP de origen y logrando una rotación automática de IP en el proceso. Como Cloudflare se ha vuelto tan popular y está tan extendida, sus ASN tienden a ser de confianza e incluso a figurar en listas de permitidos en algunos firewalls, sobre todo cuando se usa como reverse proxy para aprovechar su solución de WAF mientras mantiene oculto el servidor de origen de una aplicación web. En estos escenarios, esta utilidad también puede servir para sortear esos filtros de red y hablar directamente con el servidor de origen.

En esencia, cf-proxy no es muy complicado. La arquitectura serverless sobre la que corre hace la mayor parte del trabajo. De hecho, todo el código consta de solo dos archivos, y el código que se despliega en los Cloudflare Workers son apenas 35 líneas de JavaScript:

import { connect } from 'cloudflare:sockets';

export default {
    async fetch(request) {
        const TOKEN = '<YOUR-AUTH-TOKEN>'

        if (request.headers.get('Authorization') !== TOKEN)
            return new Response('Unauthorized', { status: 401 });

        const upgradeHeader = request.headers.get('Upgrade');

        if (!upgradeHeader || upgradeHeader !== 'websocket')
            return new Response('Expected Upgrade: websocket', { status: 426 });

        try {
            const target = connect(request.headers.get('X-Proxy-Target'));
            const writer = target.writable.getWriter();
            const websocket = new WebSocketPair();
            const [client, server] = Object.values(websocket);

            server.accept();
            server.addEventListener('message', e => e.data.arrayBuffer().then( buf => writer.write(buf) ));

            target.readable.pipeTo(new WritableStream({
                write(chunk) {
                    server.send(chunk);
                },
            }));

            return new Response(null, { status: 101, webSocket: client, });
        } catch (e) {
            return new Response(e, { status: 500 });
        }
    }
}

Esto es todo lo que hace falta para reenviar tu tráfico. El worker recibe una petición, la autentica con un token en la cabecera Authorization (al fin y al cabo, no queremos que nadie use nuestros workers para hacer cosas malas, ¿verdad?), comprueba si es una petición válida de upgrade a WebSocket, se conecta al objetivo recibido por la cabecera X-Proxy-Target, hace el upgrade de la conexión al protocolo WebSocket y luego transmite cualquier dato que reciba, transfiriéndolo entre el cliente del proxy y el servidor objetivo. Todo eso de la rotación de IP es solo un efecto secundario de cómo se crean las instancias del worker para atender las peticiones.

Los workers se despliegan por la red global de servidores de Cloudflare y se aprovisionan bajo demanda cuando se invocan. Hay algún algoritmo inteligente de aprovisionamiento¹ para minimizar la latencia y el tiempo de aprovisionamiento, pero como es un proceso muy rápido y la red es simplemente enorme, es muy poco probable que dos invocaciones seguidas se desplieguen en el mismo servidor, por lo que la dirección casi con seguridad será distinta en la siguiente invocación.

Del otro lado de este proceso tenemos el archivo proxy.js, que corre localmente y proporciona el servidor de proxy (HTTP o SOCKS5) que nuestro cliente usará para hablar con internet. Aunque es un poco más grande (unas 230 líneas), es igual de simple que el anterior. La parte más complicada es probablemente la máquina de estados que se usa para proporcionar el servidor SOCKS5. Todo lo que hace este script es interpretar las opciones de línea de comandos (de una forma no muy óptima) para identificar el worker, el token de autenticación y el protocolo de proxy que debe proporcionar, y luego empieza a aceptar conexiones en un puerto TCP. Para cada conexión recibida identifica el objetivo según el protocolo de proxy en uso e inicia la conexión WebSocket con el worker indicado, pasando el token de autenticación y el host objetivo por las cabeceras HTTP, como se mencionó antes. Y si esto funciona, los datos se transfieren entre el cliente y el worker hasta que la conexión se cierra.

El origen

La base de lo que más tarde se convertiría en cf-proxy nació de una necesidad real durante un pentest.

Necesitaba sortear un rate limit basado en IP para una tarea concreta de enumeración. Por lo que pude ver, la aplicación objetivo imponía un límite de 5 req/min con backoff creciente ante reincidencias. Podía esquivarlo cambiando mi dirección IP cada 5 peticiones y reutilizando la misma IP solo después de un minuto. La forma barata de hacerlo era levantar algunas instancias de cómputo en un proveedor de nube con acceso SSH y luego tunelizar mis peticiones por ellas en round-robin, pero eso requeriría 12 instancias solo para hacer 1 petición por segundo. Es factible, pero muy lento para este escenario. Había estimado 100 mil peticiones para agotar el espacio de búsqueda, lo que llevaría más de 24 horas a un ritmo de 1 rps. Estaba claro que necesitaba un enfoque mejor, pero no tenía ganas de comprar un proxy rotativo comercial para eso (por los motivos ya mencionados).

Mientras buscaba alternativas encontré un artículo sobre usar funciones de AWS Lambda como proxies. El problema era que, por la forma en que se aprovisionan los lambdas, la dirección IP no cambiaba durante 5 a 15 minutos y eso no funcionaría para mi caso concreto, pero me dio la idea de usar aplicaciones serverless como proxies. Un compañero de trabajo me había presentado hacía poco los Cloudflare Workers y me parecieron muy interesantes, pero como alguien que no hace desarrollo web aún no les había encontrado un buen uso, así que pareció una buena oportunidad para probar.

Para validar la idea, creé una cuenta gratuita en Cloudflare y desplegué un worker usando el código de ejemplo de la documentación oficial, que consultaba una API remota para devolver la dirección IP del cliente (el propio worker, en este caso); luego probé invocando el worker varias veces y comprobando que la IP era distinta en cada petición. ¡Funcionó como por arte de magia!

Partiendo de este principio, reescribí el worker para que recibiera los parámetros necesarios e hiciera las peticiones a la aplicación objetivo por mí, devolviendo el resultado que obtuviera. Esto resultó ser una solución viable, que me permitió terminar la enumeración mucho más rápido sin que me bloquearan, y el plan gratuito casi cubrió todas las peticiones que necesité. Aunque la funcionalidad central de cf-proxy ya estaba presente en esta versión inicial, era muy limitada y no volví a tocarla durante un buen tiempo.

Durante otra evaluación de seguridad unos días después, había identificado una posible vulnerabilidad de inyección en un objetivo mediante revisión de código, pero cualquier intento de explotarla estaba siendo bloqueado por Cloudflare. Como no lograba crear un payload que sorteara el filtro, tenía que esquivar el WAF de alguna manera.

Revisando varias fuentes, descubrí que el dominio que alojaba la aplicación objetivo solía resolver a una dirección IP concreta hasta cierto momento en el pasado, tras el cual empezó a apuntar a Cloudflare. Como la misma IP parecía haber alojado esa aplicación durante mucho tiempo antes, era razonable suponer que no habían cambiado el host, sino que solo habían puesto el WAF por delante. Pero aunque el host parecía seguir vivo, no aceptaba conexiones en ninguno de los puertos que probé. Mi suposición era que habían puesto una regla de firewall para aceptar tráfico solo del ASN de Cloudflare, de modo que no se pudiera hablar directamente con el servidor web (como yo estaba intentando).

Si tan solo pudiera hacer que mi tráfico pareciera venir de Cloudflare… un momento… ¡puedo hacerlo!

Para comprobar si era así, desplegué un worker que haría peticiones a esa dirección IP en los puertos 80 y 443, lo que confirmó que había algo respondiendo en el puerto 80. Ahora tenía una forma de sortear el WAF usando un worker para hacer las peticiones directamente al servidor de origen en mi nombre, así que solo modifiqué el worker para que recibiera algunos parámetros que definieran cosas como el método de la petición, la ruta, el cuerpo, etc.

Llegado a este punto ya podía continuar con la evaluación, pero me quedó claro que este pequeño truco podía tener aplicaciones reales en muchos otros escenarios, así que decidí convertirlo en una herramienta.

Más tarde mejoré el worker para que se comportara como un proxy de verdad, abriendo conexiones con hosts remotos y reenviando el tráfico. Usar WebSockets fue la elección natural, ya que permiten transmitir datos entre ambos lados de la conexión con más facilidad. La primera versión solo ofrecía un proxy HTTP; unos días después añadí soporte para SOCKS5. Y así fue como surgió cf-proxy.

Conclusión

Rotar la IP durante una evaluación no tiene por qué significar pagar por un proxy residencial turbio ni hacer malabares con una docena de instancias en la nube. cf-proxy convierte los Cloudflare Workers en un proxy rotativo barato que te entrega una dirección nueva y por lo general de confianza en casi cada petición, y el mismo truco que oculta tu origen también puede llevarte más allá de un WAF, directo al servidor que hay detrás. No es una bala de plata, ya que no puedes alcanzar hosts dentro de los propios rangos de Cloudflare y el puerto 25 queda descartado, pero para los casos que cubre es difícil de superar en precio y simplicidad. El código está en GitHub por si quieres probarlo.

Los workers se aprovisionan en ubicaciones físicamente cercanas al origen de la petición para minimizar la latencia, por lo que suelen estar en la misma región global (o al menos en el mismo país) que tu propia IP de origen. ↩

Nuestra primera detección de un grupo malicioso que utiliza inteligencia artificial y que tiene como objetivo a las empresas fintech brasileñas de pequeño y mediano tamaño

2026-06-29T15:00:00-03:00

El trabajo de LESIS nos coloca con frecuencia en diferentes frentes de seguridad ofensiva, respuesta a incidentes e inteligencia de amenazas. En una oportunidad reciente, fuimos convocados para apoyar una investigación que involucraba a una institución financiera brasileña. Nuestro papel inicial era responder una pregunta objetiva: ¿cuál fue el vector de entrada utilizado por el actor malicioso?

Para ello, realizamos un análisis orientado por simulación adversaria. Partimos de la misma premisa operativa del atacante: comprometer una aplicación o recurso adyacente que permitiera, directa o indirectamente, llegar a sistemas con potencial de movimiento financiero. Este enfoque nos permitió reconstruir parte de la cadena de ataque, identificar el vector inicial y, posteriormente, localizar mecanismos de persistencia utilizados por el threat actor.

Durante la investigación, observamos que la persistencia implantada por el grupo se comunicaba con infraestructura externa controlada por los operadores. A partir de ese punto, profundizamos el análisis de la infraestructura de comando y control, con el objetivo de entender si existían elementos adicionales que pudieran contribuir a la respuesta al incidente y a la protección de otros posibles objetivos.

Por razones operativas, no publicaremos IoCs, payloads, direcciones, nombres de archivos, rutas internas ni detalles que puedan comprometer investigaciones. Aun así, los artefactos analizados revelaron un conjunto consistente de comportamientos, herramientas y patrones de operación.

Qué se observó

La infraestructura analizada contenía payloads, artefactos de apoyo a la explotación, logs de solicitudes, scripts de recepción de datos y evidencias de intentos anteriores contra múltiples objetivos. En algunos casos, la misma infraestructura mantenía información relacionada con más de un objetivo u operación, incluyendo intentos fallidos, actividades en curso y datos obtenidos después del compromiso.

El análisis de estos materiales nos llevó a seis conclusiones principales.

Los objetivos observados eran fintechs brasileñas, en especial organizaciones pequeñas y medianas, con menor exposición mediática y menor madurez pública en seguridad en comparación con grandes instituciones financieras.
Las evidencias indican la actuación de un grupo, y no de un operador aislado. Esta evaluación se basa en múltiples señales: diferentes identificadores de acceso, actividad concurrente desde orígenes distintos, patrones operativos incompatibles con una única sesión humana continua y diferencias estilométricas en artefactos de código.
Al menos uno de los operadores parece tener familiaridad con el portugués brasileño. Esta conclusión proviene del uso del idioma en artefactos operativos y comentarios observados durante el análisis.
Identificamos evidencias del uso de LLMs para apoyar la construcción de tooling ofensivo. Los artefactos indican el uso de modelos de lenguaje para ayudar en la creación o adaptación de exploits, web shells, mecanismos de bypass, scripts de exfiltración y componentes auxiliares utilizados durante la operación.
Observamos intentos de eludir guardrails de LLMs mediante contextualización engañosa, especialmente llevando al modelo a operar bajo la premisa de un pentest autorizado. Este patrón es relevante porque muestra que el uso de IA por parte del grupo no se limitó a la productividad: también fue incorporado al proceso de desarrollo ofensivo.
Un punto relevante observado fue la duración de una de las operaciones asociadas a este conjunto de artefactos. En uno de los objetivos, identificamos actividad distribuida a lo largo de aproximadamente tres meses, lo que indica una intención directa y continua contra la organización comprometida. Este comportamiento reduce la hipótesis de un intento oportunista aislado y refuerza la evaluación de que el grupo mantenía interés operativo en el objetivo, adaptando su enfoque a medida que encontraba barreras, nuevas oportunidades de acceso y caminos potenciales para ampliar el impacto.

Cadena de ataque

El vector común observado fue la explotación de vulnerabilidades a nivel de aplicación. El grupo no parecía depender exclusivamente de aplicaciones directamente vinculadas a flujos financieros. Por el contrario: buscaba aplicaciones en la misma infraestructura o en entornos adyacentes que pudieran servir como punto de entrada para movimiento lateral.

Después del acceso inicial, el grupo buscaba credenciales, archivos de configuración, variables de entorno, integraciones internas y recursos de administración que pudieran ampliar el acceso.

En los casos en que el compromiso avanzó, la persistencia fue simple. En los artefactos analizados, no observamos un esfuerzo sofisticado de ocultación. El objetivo parecía ser funcionalidad y velocidad operativa, no sigilo avanzado. Esto no redujo el impacto potencial de la operación: incluso implantes simples pueden ser suficientes cuando se combinan con credenciales válidas, segmentación débil, permisos excesivos y baja visibilidad del tráfico saliente.

En al menos un caso, los controles existentes impidieron la comunicación directa entre el implante y la infraestructura externa. La respuesta del grupo fue adaptar la operación. Observamos intentos de entrega de payloads blind, probing de diferentes puertos y ajustes sucesivos para entender el control aplicado y decidir cómo evadirlo. Este comportamiento indica capacidad operativa y persistencia, aunque el tooling en sí no sea particularmente sofisticado.

También observamos foco en la exfiltración de credenciales. El grupo buscaba acceso a otras aplicaciones y servicios utilizados por colaboradores de la organización comprometida, lo que sugiere interés en escalar el ataque más allá del primer sistema explotado.

Por qué esto importa

Hay tres puntos que hacen que esta campaña sea relevante:

El primero es la elección de los objetivos: las fintechs brasileñas pequeñas y medianas pueden operar activos financieros relevantes, integraciones críticas y flujos transaccionales sensibles, pero no siempre cuentan con la misma capacidad de detección, respuesta y hardening encontrada en grandes instituciones financieras. Esto crea una superficie atractiva para grupos motivados financieramente.
El segundo es el papel de las aplicaciones como punto de entrada: la operación refuerza un patrón recurrente en muchas organizaciones: el camino hacia el impacto financiero no necesariamente comienza en el sistema financiero principal. Puede comenzar en una aplicación legada, un servicio administrativo, una integración poco monitoreada o un componente interno que comparte infraestructura con sistemas más críticos.
El tercero es el uso de IA como acelerador: el uso de LLMs no transforma automáticamente a un operador común en un actor avanzado, pero reduce costos, acelera la iteración y facilita la adaptación de tooling. En la práctica, esto permite que grupos con capacidad intermedia produzcan más variaciones de payloads, prueben hipótesis más rápidamente y superen obstáculos con menor dependencia de conocimiento especializado profundo.

TTPs observadas — MITRE ATT&CK

Descripción comportamental de las TTPs del grupo. No incluye IoCs, como IPs, hashes, nombres de archivos, rutas internas o nombres de víctimas.

Táctica	Técnica (ATT&CK)	Comportamiento observado
Desarrollo de Recursos (TA0042)	Obtain Capabilities: Tool (T1588.002)	Uso de exploits públicos listos junto con scripts propios (asistido por IA / agéntico)
Desarrollo de Recursos (TA0042)	Develop Capabilities (T1587)	Generación de tooling, playbooks e informes asistida por IA / agéntica
Acceso Inicial (TA0001)	Exploit Public-Facing Application (T1190)	Explotación a nivel de aplicación contra servicios expuestos, incluyendo aplicaciones legadas y modernas
Descubrimiento (TA0007)	Network Service Discovery (T1046)	Reconocimiento de la red interna, a partir del acceso obtenido, contra servicios adyacentes
Ejecución / Movimiento Lateral (TA0002 / TA0008)	Server-side abuse → consola de administración (T1190 → T1505.003)	Pivote hacia consola de administración/deploy para implantar código
Persistencia (TA0003)	Web Shell (T1505.003) + Masquerading (T1036)	Web shells disfrazados de endpoints legítimos de la propia aplicación, como health checks
Escalamiento de Privilegios (TA0004)	Escape to Host (T1611)	Acceso de contenedor a host por aislamiento deficiente del contenedor
Acceso a Credenciales (TA0006)	Credentials in Files / Private Keys (T1552.001 / .004)	Recolección de credenciales en archivos de configuración y claves, así como secretos expuestos en artefactos
Acceso a Credenciales (TA0006)	Steal Application Access Token (T1528)	Robo de tokens de acceso para reutilización (replay)
Acceso a Credenciales (TA0006)	Brute Force: Password Cracking (T1110.002)	Cracking offline de hashes exfiltrados con wordlists contextuales
Recolección (TA0009)	Email Collection (T1114)	Descarga masiva de buzones de correo y búsqueda dirigida de credenciales de acceso remoto y de sistemas financieros
Evasión de Defensas (TA0005)	Account Manipulation (T1098)	Alteración del hash de contraseña de un administrador por un valor conocido
Comando y Control (TA0011)	Non-Standard Port / Fallback Channels (T1571 / T1008)	Cuando el tráfico saliente fue bloqueado: payloads blind, escaneo de múltiples puertos y ajuste iterativo del canal
Impacto (TA0040)	Financially motivated targeting (intención)	Foco en datos y credenciales de pagos, crédito y banking

Conclusión

Esta investigación muestra un grupo con motivación financiera, foco sectorial claro y capacidad de adaptar tooling según los controles encontrados en el entorno de la víctima. El uso de IA aparece como un elemento de aceleración operativa, especialmente en la creación y modificación de herramientas ofensivas, pero no sustituye los fundamentos tradicionales de la intrusión: explotación de aplicaciones, recolección de credenciales, movimiento lateral, persistencia y búsqueda de impacto financiero.

No publicaremos IoCs ni detalles técnicos sensibles en este momento. La decisión es intencional: preservar ventaja de inteligencia, proteger a víctimas potenciales y evitar que la infraestructura o los métodos observados sean rápidamente modificados por los operadores.

Si su organización desea acceder al informe técnico detallado, póngase en contacto con nosotros. Estamos siempre disponibles para colaborar con equipos de seguridad, respuesta a incidentes e inteligencia de amenazas.

Dependabot: automatizando la actualización de dependencias en GitHub

2026-06-25T08:00:00-03:00

Mantener las dependencias actualizadas es una de las tareas más descuidadas en el ciclo de vida de un proyecto de software. No por descuido o desconocimiento, sino porque el trabajo cotidiano impone prioridades más visibles: funcionalidades, correcciones de bugs, plazos. Las dependencias desactualizadas rara vez generan síntomas inmediatos. Los problemas que introducen suelen aparecer tarde, y cuando aparecen, el costo es alto.

A partir de este diagnóstico, decidimos configurar Dependabot en nuestros repositorios. Este texto describe qué es la herramienta, cómo funciona, cómo hicimos la configuración y qué aprendimos durante el proceso.

El problema de las dependencias

Todo proyecto de software moderno depende de bibliotecas externas. Estas bibliotecas, a su vez, tienen sus propias dependencias. A medida que pasa el tiempo, se publican nuevas versiones con correcciones de bugs, mejoras de rendimiento y, principalmente, correcciones de vulnerabilidades de seguridad.

Cuando se descubre una vulnerabilidad en una biblioteca ampliamente utilizada, puede recibir un identificador CVE (Common Vulnerabilities and Exposures) y pasar a estar registrada en bases públicas de vulnerabilidades y advisories. A partir de ese momento, la falla deja de ser solo un riesgo teórico: se convierte en información conocida públicamente, incluso por personas con intención maliciosa. Los proyectos que todavía utilizan la versión vulnerable permanecen expuestos hasta que se aplica la actualización.

El problema es que seguir este flujo manualmente, en varios repositorios, con varios lenguajes y gestores de paquetes diferentes, es inviable en la práctica. Sin automatización, este proceso tiende a volverse inconsistente, atrasado o simplemente olvidado.

Qué es Dependabot

Dependabot es una herramienta de GitHub que monitorea las dependencias de los repositorios y abre pull requests automáticamente cuando identifica versiones más recientes o vulnerabilidades conocidas. Opera directamente dentro de la infraestructura de GitHub, sin necesidad de instalar o configurar servidores externos.

La herramienta funciona en dos modos complementarios. El primero es el monitoreo de seguridad. Cuando una vulnerabilidad se registra en GitHub Advisory Database y afecta una dependencia presente en el proyecto, GitHub puede generar una alerta en el repositorio. Cuando los security updates están habilitados, Dependabot puede abrir automáticamente un pull request con la versión corregida o con una actualización que elimine la exposición identificada.

El segundo modo es la actualización de versiones. Independientemente de las vulnerabilidades, Dependabot verifica periódicamente si existen versiones más recientes de las dependencias y propone las actualizaciones de forma automatizada.

En ambos casos, el resultado es un pull request que el equipo puede revisar, probar y aprobar. La decisión final permanece en manos de las personas. Lo que cambia es que el trabajo de monitoreo y preparación de la actualización deja de ser manual.

Cómo configurarlo

La configuración de Dependabot se realiza mediante un archivo llamado dependabot.yml, que debe estar dentro de la carpeta .github del repositorio.

Un ejemplo básico para proyectos que usan npm es:

version: 2

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

Este archivo le indica a Dependabot que verifique, una vez por semana, las dependencias npm declaradas en la raíz del proyecto. A partir de esta configuración, la herramienta empieza a acompañar nuevas versiones disponibles y puede abrir pull requests automáticamente cuando haya actualizaciones.

En repositorios con muchas dependencias, una configuración un poco más controlada puede ser más adecuada:

version: 2

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "09:00"
      timezone: "America/Sao_Paulo"
    open-pull-requests-limit: 5

En este caso, además de definir la frecuencia, también especificamos el día, la hora y la zona horaria de la verificación. El parámetro open-pull-requests-limit ayuda a controlar el volumen de pull requests abiertos al mismo tiempo, evitando que la primera ejecución de la herramienta genere más trabajo del que el equipo puede revisar.

La configuración también acepta variaciones relevantes: es posible ignorar paquetes específicos, definir labels, configurar mensajes de commit, agrupar actualizaciones y declarar múltiples ecosistemas dentro de un mismo repositorio, en caso de que el proyecto utilice lenguajes o gestores de paquetes diferentes en carpetas distintas.

En el caso del blog de LESIS, por ejemplo, la configuración necesitó contemplar más de un ecosistema. Además de las dependencias Ruby gestionadas por Bundler, también configuramos Dependabot para acompañar actualizaciones de los workflows de GitHub Actions:

version: 2

updates:
  - package-ecosystem: "bundler"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "03:00"
      timezone: "America/Sao_Paulo"
    open-pull-requests-limit: 5
    labels:
      - "dependencies"
      - "ruby"
    commit-message:
      prefix: "chore(deps)"
      prefix-development: "chore(deps-dev)"
      include: "scope"
    groups:
      production:
        dependency-type: "production"
        update-types:
          - "minor"
          - "patch"
      production-major:
        dependency-type: "production"
        update-types:
          - "major"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "04:00"
      timezone: "America/Sao_Paulo"
    open-pull-requests-limit: 5
    labels:
      - "dependencies"
      - "github-actions"
    commit-message:
      prefix: "ci"
      include: "scope"
    groups:
      minor-patch:
        update-types:
          - "minor"
          - "patch"
      major:
        update-types:
          - "major"

En este ejemplo, bundler monitorea las gems del proyecto, mientras que github-actions monitorea las actions utilizadas en los workflows del repositorio. La configuración también define labels específicas para cada ecosistema, prefijos de commit y agrupamientos de actualización.

Los agrupamientos ayudan a organizar el volumen de pull requests. En el caso de las dependencias de producción, por ejemplo, las actualizaciones minor y patch pueden agruparse por separado de las actualizaciones major, que tienden a exigir más atención durante la revisión. El mismo razonamiento se aplicó a las actualizaciones de GitHub Actions.

Cuando se asignó la tarea, el punto de partida fue estudiar la herramienta. Dependabot no era algo familiar hasta entonces, así que antes de cualquier configuración fue necesario entender cómo funcionaba, qué monitoreaba y cuáles eran las opciones disponibles. Ese tiempo de estudio fue necesario y valió la pena: la configuración en sí, después de comprender la herramienta, fue directa. La documentación de GitHub cubre los casos más comunes con claridad, y los primeros pull requests generados automáticamente aparecieron poco después de agregar el archivo.

Limitaciones que encontramos

Un aprendizaje importante del proceso fue que Dependabot no ofrece soporte para todos los gestores de paquetes. En nuestro caso, algunos proyectos utilizan CPAN, el gestor de dependencias de Perl, que no está en la lista de ecosistemas soportados por la herramienta. En esos repositorios, el monitoreo automatizado no es posible con Dependabot, y el seguimiento debe hacerse por otros medios.

Para proyectos Perl, Bunkai, una herramienta de análisis de composición de software desarrollada por LESIS, cubre parte de esa brecha al identificar dependencias desactualizadas y vulnerabilidades conocidas en proyectos que usan CPAN.

Además, vale mencionar que Dependabot no es la única herramienta disponible para este tipo de automatización. Una alternativa libre bastante conocida es Renovate, una herramienta open source para actualización automatizada de dependencias. Al igual que Dependabot, Renovate identifica dependencias desactualizadas y puede abrir pull requests con las actualizaciones necesarias.

Renovate puede ser especialmente interesante para equipos que no utilizan GitHub, ya que fue diseñado para funcionar en diferentes plataformas de hospedaje de código, como GitLab, Bitbucket, Azure DevOps, Forgejo y Gitea. También suele considerarse cuando el proyecto exige mayor flexibilidad de configuración, políticas de actualización más específicas o flujos más personalizados.

En nuestro caso, Dependabot fue una elección natural por estar integrado a GitHub y exigir poca configuración inicial. Aun así, para proyectos fuera del ecosistema de GitHub o con necesidades más complejas de automatización, Renovate es una alternativa que vale la pena evaluar.

Antes de configurar la herramienta, conviene verificar si los gestores de paquetes utilizados en el proyecto están entre los soportados. La lista oficial de ecosistemas compatibles está disponible en la documentación de GitHub y cubre los casos más comunes, como npm, pip, Maven, Gradle, Composer y RubyGems, entre otros, pero no es universal.

Otro punto que merece atención es el volumen inicial de pull requests. En repositorios con muchas dependencias que no fueron actualizadas durante algún tiempo, la primera ejecución de Dependabot puede generar un número expresivo de propuestas al mismo tiempo. Esto puede sobrecargar el flujo de revisión si no hay un límite configurado. El parámetro open-pull-requests-limit, en el archivo de configuración, permite controlar este comportamiento.

Por qué esto importa

La gestión de dependencias no es solo una cuestión de organización interna. Es una cuestión de seguridad con consecuencias externas. Las bibliotecas desactualizadas son un vector de ataque documentado y explotado activamente. La diferencia entre un proyecto vulnerable y un proyecto más seguro, en muchos casos, está en la existencia de un proceso que mantenga las dependencias monitoreadas y actualizadas.

Dependabot no sustituye una postura de seguridad integral, pero resuelve una parte específica del problema de forma confiable y con bajo costo de configuración. Transforma una tarea que tendería a ser olvidada en un proceso continuo, auditable e integrado al flujo normal de trabajo del equipo.

Conclusión

La experiencia de configurar Dependabot en nuestros repositorios fue positiva. El esfuerzo inicial es pequeño, la integración con GitHub es nativa, y el resultado, dependencias monitoreadas de forma continua, justifica con creces el tiempo invertido.

Las limitaciones existen y deben conocerse antes de crear expectativas. No todos los ecosistemas son soportados, y el volumen de pull requests puede exigir ajustes finos en la configuración. Pero, para los repositorios compatibles, la herramienta entrega exactamente lo que promete.

Más que una conveniencia, mantener dependencias actualizadas es una responsabilidad. La automatización no elimina esa responsabilidad; ayuda a garantizar que se cumpla de forma consistente.

Referencias

Elegir el método correcto para compartir identificadores

2026-05-05T08:00:00-03:00

Introducción

Algunos problemas de seguridad aparecen justamente cuando dos empresas legítimas quieren colaborar.

Imagine una institución financiera digital con una base muy grande de clientes y un marketplace preparando una promoción exclusiva para clientes de esa institución. Durante la campaña, el marketplace necesita saber qué personas también son clientes de la institución financiera para aplicar el beneficio correctamente.

El problema parece simple: una empresa tiene la lista de clientes elegibles, la otra tiene su propia base de usuarios, y la promoción debe valer solo para la intersección entre las dos bases.

Pero existe una pregunta importante: ¿cómo permitir esa comparación sin exponer más datos personales de lo necesario?

El Escenario

La necesidad de negocio era directa: una campaña promocional debía ser ofrecida por un socio comercial solo a clientes de la institución financiera.

Como la institución financiera tenía una base de clientes mayor que la base del socio, simplemente enviar todos los CPFs de sus clientes al socio permitiría la comparación, pero expondría a muchas más personas de lo necesario.

La primera propuesta del equipo responsable de la integración era cifrar un archivo que contenía todos los CPFs de los clientes elegibles y transmitirlo por un canal seguro. El socio recibiría el archivo, lo descifraría, lo compararía con su propia base e identificaría qué usuarios eran elegibles.

Desde el punto de vista del transporte, eso parece razonable. El archivo estaría protegido durante el envío. El canal podría estar autenticado. El acceso podría estar restringido.

Pero el problema principal no era solo el transporte. El problema era la minimización.

Al final del proceso, el socio tendría acceso a una lista completa de CPFs de clientes de la institución financiera, incluso personas que tal vez ni siquiera tuvieran cuenta en el marketplace, nunca participaran en la campaña o nunca necesitaran ser conocidas por el socio. La criptografía protegería el archivo en el camino, pero no reduciría el dato revelado al destinatario.

La Criptografía Resuelve Otro Problema

La criptografía es una herramienta de confidencialidad. Protege datos contra quien no debe acceder a ellos durante el almacenamiento o la transmisión. Si un archivo cifrado es interceptado por alguien sin la clave, el contenido permanece protegido.

Pero, en muchos flujos de integración, el destinatario legítimo necesita abrir el archivo. Después de descifrarlo, pasa a ver los valores originales.

En este caso, la criptografía respondía a la pregunta:

¿Cómo enviar la lista de CPFs sin que terceros lean el archivo en el camino?

Pero había una segunda pregunta que todavía debía ser respondida:

¿Cómo permitir que el socio descubra solo qué clientes ya existen en su propia base, sin recibir la lista completa de la institución financiera?

Estas preguntas parecen parecidas, pero son problemas diferentes. La primera trata de confidencialidad en tránsito y seguía siendo necesaria. La segunda trata de minimización de datos y exposición al destinatario. El punto no era reemplazar la criptografía, sino reconocer que debía combinarse con un diseño que revelara menos información.

Dónde Ayudan los Hashes

Un hash criptográfico transforma una entrada en una salida de tamaño fijo. Para la misma entrada, el resultado siempre es el mismo. Para entradas diferentes, se espera que los resultados sean diferentes. Los buenos algoritmos de hash también hacen impracticable recuperar la entrada original a partir de la salida, siempre que la entrada tenga suficiente entropía.

Esta propiedad determinística permite comparación sin transmitir el valor original.

Por ejemplo, en lugar de compartir:

123.456.789-10

una empresa podría compartir:

sha256("12345678910") = 01b6...f3a9

Si el socio normaliza sus propios CPFs de la misma forma y calcula el mismo hash, puede comparar los hashes. Cuando hay igualdad, existe un CPF en común.

La ganancia de privacidad es intuitiva: en lugar de revelar directamente los CPFs, las empresas comparan representaciones derivadas. El socio solo debería poder reconocer los CPFs que ya conoce, porque necesita tener el valor original en su propia base para generar el mismo hash.

Esta idea es útil, pero hay una trampa importante.

CPF Es Enumerable

Los desarrolladores muchas veces aprenden hash en el contexto de contraseñas. En ese contexto, la entrada idealmente es secreta, elegida por el usuario y difícil de adivinar. Aun así, las contraseñas exigen algoritmos específicos como Argon2, bcrypt o scrypt, además de salt, costo computacional y buenas políticas de almacenamiento.

CPF es diferente.

CPF tiene formato conocido, cantidad limitada de combinaciones y dígitos verificadores. Esto significa que un atacante puede generar muchos CPFs candidatos, calcular sus hashes y compararlos con una lista filtrada. Ese es el principio de los ataques de diccionario o rainbow table.

Por eso, el siguiente enfoque es débil:

sha256(cpf_normalizado)

No revela el CPF de forma directa, pero tampoco debe tratarse como anonimización. Para identificadores previsibles, un hash simple suele ser reversible por fuerza bruta o precomputación.

Este punto es esencial: hash no es magia. La seguridad depende tanto del algoritmo como de la naturaleza de la entrada.

La Normalización Importa

Antes de cualquier comparación, ambos lados necesitan llegar exactamente a la misma representación del identificador.

En el caso de CPF, esto normalmente significa eliminar puntuación, validar longitud, preservar ceros a la izquierda y rechazar valores inválidos o malformados. De lo contrario, el mismo CPF puede producir hashes diferentes:

123.456.789-10
12345678910

Estas dos cadenas tienen apariencia equivalente para una persona, pero son entradas diferentes para un algoritmo de hash.

Toda estrategia de comparación necesita documentar la normalización antes de documentar el algoritmo. Sin eso, el proceso produce falsos negativos, inconsistencia operativa y dificultades de auditoría.

Salt No Siempre Resuelve

Una reacción común es agregar salt:

sha256(salt || cpf_normalizado)

En almacenamiento de contraseñas, salt es fundamental porque impide que el mismo valor genere el mismo hash en bases diferentes y dificulta tablas precomputadas genéricas. Pero, en un proceso de comparación entre dos empresas, ambas partes necesitan generar el mismo resultado para el mismo CPF.

Si cada empresa usa un salt diferente, los hashes no coincidirán. Si el salt se comparte entre las empresas, ayuda contra algunas tablas precomputadas externas, pero no impide que una parte con acceso al salt enumere CPFs candidatos y calcule sus hashes.

Salt es útil, pero no resuelve por sí solo el problema de identificadores previsibles en una integración de matching.

HMAC con API como Camino Pragmático

Una alternativa mejor que hash simple es usar HMAC:

hmac_sha256(clave_secreta, cpf_normalizado)

HMAC usa una clave secreta en el cálculo. Sin la clave, un tercero que obtenga la lista de HMACs no consigue calcular fácilmente los valores correspondientes para CPFs candidatos. Esto reduce bastante el riesgo de ataques offline por terceros.

Pero hay una cuestión de diseño. Si la clave se comparte con el socio para que calcule HMACs sobre su propia base, también puede calcular HMACs para CPFs candidatos por cuenta propia. Esto puede ser aceptable en algunos escenarios, siempre que la clave sea específica para la campaña, tenga rotación, alcance limitado y controles de auditoría, pero cambia el modelo de confianza.

Un camino pragmático sería combinar HMAC con una API controlada por la institución financiera. En este diseño, el marketplace prepara su propia base, normaliza los CPFs, calcula los identificadores derivados según la especificación de la campaña y envía un lote a la API. La institución financiera compara esos valores contra una representación equivalente de su propia base y devuelve solo el resultado necesario para la campaña. Ese resultado no necesita ser una nueva lista de CPFs. Puede ser una marca de elegibilidad asociada a los usuarios del propio marketplace.

Un ejemplo simple sería:

Marketplace envía:
user_id=10, hmac_cpf=aaa
user_id=20, hmac_cpf=bbb
user_id=30, hmac_cpf=ccc

Después de la comparación, la API podría responder:

user_id=10, eligible=true
user_id=20, eligible=false
user_id=30, eligible=true

Con esto, el marketplace consigue aplicar la campaña dentro de su propia base, pero no recibe la lista completa de CPFs de la institución financiera. El CPF se usa como clave técnica de comparación, pero el resultado operativo es una marca de elegibilidad.

Este enfoque cambia el problema a un modelo de consulta controlada. Si la API permite probar CPFs arbitrarios, incluso con autenticación y HMAC, puede convertirse en un oráculo de elegibilidad. Por eso, este tipo de solución necesita controles adicionales: aceptar solo lotes asociados a la base declarada del socio, limitar reprocesamientos, auditar consultas, imponer ventanas de campaña y definir claramente qué está permitido probar. En otras palabras, HMAC y API pueden formar una solución práctica, pero la garantía pasa a depender de gobernanza y control operativo. Para escenarios que exigen una garantía técnica más fuerte sobre lo que cada parte aprende, existe un enfoque más sofisticado.

Una Alternativa Más Sofisticada: Intersección Privada de Conjuntos

Una alternativa más sofisticada para este tipo de problema se conoce como intersección privada de conjuntos, o Private Set Intersection (PSI).

En términos simples, PSI es una familia de protocolos criptográficos que permite que dos partes comparen conjuntos y descubran una intersección sin compartir los conjuntos en claro. La idea no es “cifrar una lista y entregarla al otro lado”. La idea es ejecutar un proceso en el que cada parte mantiene su conjunto y participa en una comparación protocolizada.

Un ejemplo pequeño ayuda a visualizar el objetivo. Suponga que la institución financiera tiene los CPFs 111, 222, 333 y 444. El socio tiene los CPFs 222, 444 y 555. El resultado necesario para la campaña es saber que 222 y 444 están en los dos conjuntos. El socio no necesita aprender que 111 y 333 existen en la base de la institución financiera. La institución financiera tampoco necesita aprender que 555 existe en la base del socio, a menos que el diseño del protocolo o de la campaña lo exija.

En una comparación común usando archivo, una de las partes recibe una lista y hace la intersección localmente. Eso es simple, pero obliga a esa parte a ver valores que no forman parte del resultado final. En una API de consulta, por otro lado, la institución financiera puede evitar entregar toda su base al marketplace, pero pasa a observar el lote que el marketplace está consultando. Eso puede ser aceptable. Pero, si el requisito también es reducir lo que la institución financiera aprende sobre la base del marketplace, una API centralizada puede no ser suficiente.

Existen diferentes formas de implementar PSI. Algunas usan criptografía de clave pública, otras usan oblivious transfer, circuitos garbled o construcciones basadas en hashing y claves efímeras. El detalle matemático cambia según el protocolo, pero el objetivo de seguridad permanece: permitir matching entre conjuntos sin transformar una integración en compartición amplia de base.

También es importante observar que PSI no define solo “cómo comparar”. Ayuda a definir “quién aprende qué”. En algunos diseños, ambas partes aprenden la intersección. En otros, solo una parte aprende qué usuarios son elegibles. Para el caso de la promoción, este segundo modelo tiene más sentido: el marketplace necesita aplicar el beneficio dentro de su propia base, mientras que la institución financiera no necesariamente necesita aprender qué clientes también están en el marketplace.

Aplicado al caso de la promoción, el resultado deseado tal vez no fuera una nueva lista de CPFs compartida entre empresas. Podría ser solo una forma de que el socio marque, dentro de su propia base, qué usuarios son elegibles. Esta distinción reduce exposición porque mantiene el foco en el resultado operativo de la campaña, no en la circulación de identificadores.

PSI, sin embargo, no elimina todos los riesgos. Si una parte puede elegir libremente el conjunto de entrada, todavía puede intentar probar identificadores que no pertenecen a su base legítima. Por eso, PSI no reemplaza contrato, auditoría, controles de alcance y validación del proceso. Lo que mejora es otro punto: reduce la necesidad de que una parte entregue toda su base en claro, y también puede reducir cuánto observa la otra parte durante la comparación.

En la práctica, PSI es más complejo que una API con HMAC. Exige una biblioteca adecuada, entendimiento del protocolo, cuidado con la normalización, tratamiento de errores, auditoría, pruebas de performance y evaluación de lo que cada parte aprende durante el proceso. No todo caso exige ese nivel de sofisticación. Pero debe considerarse cuando el requisito no es solo evitar que el marketplace reciba toda la base de la institución financiera, sino también reducir cuánto aprende la institución financiera sobre el conjunto del marketplace durante el matching.

Una Jerarquía Práctica de Soluciones

No toda integración necesita el mismo nivel de protección. Una forma pragmática de pensar es organizar las opciones por reducción de exposición.

Un archivo con CPFs cifrado en tránsito protege contra interceptación, pero revela la lista completa al destinatario. Es simple, pero débil en minimización.

Hash simple de los CPFs evita exposición directa casual, pero es vulnerable a enumeración porque CPF es previsible. No debe tratarse como anonimización.

HMAC con clave controlada mejora la protección contra terceros y filtraciones de la lista derivada, pero exige gobernanza fuerte sobre la clave. En lugar de compartir la clave con el socio, una API autenticada usando HMAC puede ser una alternativa práctica cuando el objetivo es responder elegibilidad sin entregar toda la base de la institución financiera, siempre que no permita consultas arbitrarias sin control.

PSI o un protocolo equivalente es una opción más sofisticada cuando también hay interés en reducir lo que la institución financiera aprende sobre el conjunto consultado por el marketplace, además de evitar la entrega de toda la base al socio.

Esta jerarquía ayuda a explicar por qué la respuesta inicial de “vamos a cifrar el archivo” era insuficiente. La pregunta no era solo cómo transportar datos con seguridad. La pregunta era cuánto dato necesitaba revelarse para alcanzar el objetivo.

Conclusión

Una revisión de seguridad para este tipo de compartición debe comenzar por preguntas simples. Antes de elegir algoritmo, es necesario entender cuál es el objetivo exacto de la comparación, quién necesita aprender el resultado y qué formato debe tener ese resultado. ¿El resultado necesita ser una lista de CPFs, una lista de usuarios elegibles, un booleano por usuario o solo una cuenta agregada?

También es necesario evaluar qué datos de personas fuera de la intersección serían expuestos por la solución propuesta. Esta es una pregunta central, porque una solución puede parecer segura por usar criptografía y aun así revelar un conjunto mucho mayor de lo necesario al destinatario legítimo.

Otro punto importante es la naturaleza del identificador usado. Si el identificador es previsible o tiene baja entropía, hash simple no debe tratarse como protección fuerte. La existencia de normalización documentada también debe verificarse, porque pequeñas diferencias de formato pueden romper la comparación o crear excepciones difíciles de auditar.

Por último, la revisión debe cubrir quién controla claves, salts o secretos, si el proceso es auditable y reproducible, y si existe retención limitada de los archivos intermedios y resultados. Estas preguntas evitan que la discusión quede limitada a “¿el archivo está cifrado?”. La seguridad del transporte importa, pero minimización, finalidad, retención y modelo de confianza importan tanto como ella.

Criptografía, hash, HMAC, APIs y PSI son herramientas diferentes para problemas diferentes. La decisión correcta depende menos de la familiaridad con una técnica específica y más de lo que cada parte necesita aprender durante el proceso.

El aprendizaje principal de este caso es que “transmitir con seguridad” no es lo mismo que “revelar el mínimo necesario”. En integraciones entre empresas, especialmente cuando involucran identificadores personales, la arquitectura debe comenzar por la minimización: ¿quién necesita saber qué, por cuánto tiempo y con qué garantía técnica?

A veces, la mejor solución no es cifrar mejor el archivo. Es evitar que el archivo exista de esa forma.

Referencias

Orientaciones para ofuscación y enmascaramiento de PII

2026-05-04T10:00:00-03:00

Introducción

Muchas aplicaciones manejan información personal identificable, conocida por la sigla PII: nombres, direcciones, correos electrónicos, teléfonos, documentos, identificadores de dispositivo y otros datos capaces de identificar a una persona directa o indirectamente.

Cuando esta información aparece en pantallas de aplicación, logs, reportes, herramientas de soporte, notificaciones o entornos no productivos, el sistema debe evitar exponer más de lo que el usuario u operador realmente necesita. Una forma común de reducir esta exposición es enmascarar u ofuscar parte del valor.

Esta práctica es familiar. Un flujo de recuperación de contraseña puede mostrar solo parte de un correo electrónico. Un panel de soporte puede mostrar solo los últimos dígitos de un teléfono. Una interfaz bancaria puede mostrar un identificador fiscal parcialmente oculto. Aun así, los detalles suelen ser inconsistentes. Sistemas distintos eligen caracteres visibles distintos, cantidades distintas y formatos distintos.

Esa inconsistencia importa. Si la misma PII se enmascara de formas diferentes en varias aplicaciones, cada aplicación puede revelar un fragmento diferente. Un atacante capaz de activar u observar esos flujos puede combinar los fragmentos y reconstruir el valor original.

Este artículo propone orientaciones prácticas para enmascarar campos comunes de PII. El objetivo no es definir un estándar legal universal, sino ofrecer una base técnica para personas de ingeniería, seguridad y producto que necesitan un comportamiento consistente al mostrar o procesar datos personales.

Ofuscación, enmascaramiento y anonimización

Los términos suelen usarse como sinónimos, pero no significan lo mismo.

Enmascaramiento es la sustitución de parte de un valor por un marcador fijo, normalmente para ocultar caracteres sensibles mientras se conserva suficiente contexto para reconocimiento. Por ejemplo, user.name@example.com puede convertirse en u*******e@e*****e.com.

Ofuscación es una práctica más amplia de hacer que los datos sean más difíciles de entender o interpretar. El enmascaramiento es un tipo de ofuscación, pero no toda ofuscación es enmascaramiento. La ofuscación también puede incluir tokenización, supresión, truncamiento o transformaciones que preservan formato.

Un ejemplo de ofuscación que no es solo enmascaramiento es sustituir un correo electrónico por un identificador opaco. En lugar de mostrar heitor.gouvea@lesis.lat como h***********a@l***s.lat, el sistema podría mostrar user_8f3a91. En este caso, el valor original no aparece parcialmente. Fue sustituido por un identificador opaco. Esto puede ser tokenización o seudonimización, dependiendo de cómo se mantenga el mapeo con el valor original.

Anonimización significa transformar datos para que una persona ya no pueda ser identificada, directa o indirectamente, usando medios razonablemente disponibles. El enmascaramiento parcial no debe tratarse como anonimización por defecto. Un correo electrónico o teléfono enmascarado todavía puede vincularse a una persona, especialmente cuando se combina con otros datos.

En la práctica, el enmascaramiento es más útil como control de minimización de datos. Reduce la exposición innecesaria. No reemplaza criptografía, control de acceso, registros de auditoría, límites de retención o eliminación segura.

Por qué importa la consistencia

Considere una persona que usa el mismo alias público en varias redes sociales. Un atacante quiere descubrir el correo electrónico asociado con ese alias. No puede ver el correo completo, pero puede activar flujos de recuperación de contraseña en varias plataformas.

Si cada plataforma enmascara el correo de una forma diferente, el atacante puede recibir fragmentos como estos:

Plataforma	Correo enmascarado
Instagram	`h*********a@g*l.com`
Twitter	`*************@gmail.com`
LinkedIn	`*****ouvea@gm******`
Facebook	`hei********@gma*om`
Telegram	`***r.**ea@g***.com`

Figura 1: fragmentos de un mismo correo revelados por diferentes reglas de enmascaramiento pueden combinarse para reconstruir el valor original.

Individualmente, cada fragmento puede parecer inofensivo. Juntos, pueden revelar suficiente estructura para reconstruir la dirección.

El mismo problema puede ocurrir dentro de una organización. Si dos aplicaciones leen la misma base de datos y enmascaran un identificador fiscal de formas diferentes, cada aplicación puede exponer una parte diferente del valor. Con el tiempo, logs, tickets, correos, capturas de pantalla y conversaciones de soporte pueden acumular suficientes fragmentos para debilitar la protección.

Por este motivo, el enmascaramiento debe tratarse como una decisión compartida de política, no como un detalle local de formato de interfaz. El mismo campo debe enmascararse de la misma forma en productos, herramientas internas, APIs y flujos operativos.

Cuándo enmascarar PII

El enmascaramiento de PII es útil siempre que el valor completo no sea necesario para el usuario, operador o acción del sistema que se está ejecutando.

En sistemas de soporte, los agentes suelen necesitar confirmar que están mirando al cliente correcto, pero rara vez necesitan el documento completo, teléfono completo o correo completo. Mostrar un fragmento limitado puede ser suficiente para la verificación mientras se reduce la exposición en la interfaz de soporte.

En pruebas de restauración de backups, los equipos pueden necesitar forma y volumen de datos realistas, pero no deberían necesitar acceso a identificadores reales de clientes. Enmascarar o sustituir PII durante la restauración puede preservar el valor operativo de la prueba sin exponer datos personales innecesariamente en entornos no productivos.

En analytics y entrenamiento de modelos, los datos de producción pueden contener señales que los datos sintéticos no reproducen bien. Aun así, el comportamiento por defecto debe ser eliminar, enmascarar, agregar o tokenizar PII, a menos que el valor completo sea estrictamente necesario y esté legalmente justificado.

En logs y sistemas de observabilidad, el enmascaramiento es especialmente importante porque los logs suelen copiarse, indexarse, retenerse, exportarse y ser accedidos por grupos operativos más amplios. Un campo seguro en una base de datos de producción restringida puede volverse riesgoso cuando se repite en pipelines de logs.

Principios generales de enmascaramiento

Las decisiones de enmascaramiento deben seguir algunas reglas simples.

Revele el mínimo necesario para completar el flujo. Si la persona usuaria solo necesita distinguir entre dos teléfonos, los dos o cuatro últimos dígitos pueden ser suficientes. Si un operador solo necesita saber que un correo fue enviado al dominio esperado, la parte local completa no debe estar visible.

Mantenga el formato reconocible cuando eso ayude a la usabilidad. Por ejemplo, preservar puntuación en un CPF o teléfono puede ayudar a reconocer el tipo de campo sin exponer el valor completo.

Evite revelar información estructural de alto valor. En algunos identificadores, ciertos dígitos tienen significado. En CPFs brasileños, por ejemplo, los dos últimos dígitos son verificadores y el noveno dígito puede indicar la región de emisión. Una regla de enmascaramiento debe considerar esa semántica en lugar de ocultar caracteres aleatorios.

Use una regla de enmascaramiento por tipo de campo y aplíquela en todos los lugares. Si la política para un correo electrónico es revelar el primer y último carácter de la parte local y de la etiqueta principal del dominio, toda aplicación debe usar la misma regla.

No use enmascaramiento parcial como única protección para almacenamiento sensible. Si el valor original debe conservarse, protéjalo con control de acceso, criptografía cuando sea apropiado, auditoría rigurosa y límites de retención. El enmascaramiento debe controlar principalmente la exposición en la capa de presentación, exportación, logging o datos derivados.

El enmascaramiento debe ocurrir lo más cerca posible de la superficie de exposición: interfaz, logs, exportaciones, mensajes, reportes y entornos derivados. No debe confundirse con transformar el dato original en la base de datos sin una necesidad clara.

Patrones recomendados

Los patrones siguientes ofrecen un punto de partida práctico. Son ejemplos de baseline, no reglas universales. Cada organización debe validar los campos según jurisdicción, amenaza y necesidad operativa, pero el punto central es la consistencia.

Campo	Valor original	Valor enmascarado	Orientación
CPF	`111.222.333-00`	`**.222.33-**`	Oculte los tres primeros dígitos, el noveno dígito y los dos dígitos verificadores. Preserve la puntuación solo para legibilidad.
Correo electrónico	`user.name@example.com.br`	`u*****e@e***e.com.br`	Revele solo el primer y último carácter de la parte local y de la etiqueta principal del dominio. Preserve sufijos públicos, como `.com.br`, cuando sea necesario para reconocimiento.
Teléfono	`(11) 91234-5678`	`(11) 9**-78`	Preserve código de país o área solo cuando sea necesario para enrutamiento o reconocimiento. Revele la menor cantidad posible de dígitos finales exigida por el flujo.
Dirección IPv4	`203.0.113.42`	`203.0.113.***`	Para visualización, oculte el octeto de host. Para analytics, prefiera agregación por subred cuando sea posible.
Dirección IPv6	`2001:db8:abcd:0012:0000:0000:0000:0001`	`2001:db8:abcd:0012:**:::**`	Preserve solo el prefijo de red necesario para uso operativo. Oculte segmentos específicos de interfaz.
Documento	`12.345.678-9`	`*.345.67-*`	Trate documentos nacionales o regionales como identificadores estructurados. Oculte dígitos verificadores y evite exponer todas las posiciones semánticas.
Placa de vehículo	`ABC1D23`	`A*123`	Revele solo el mínimo necesario para reconocimiento por el usuario. Evite exponer suficientes caracteres para identificar unívocamente el vehículo en bases pequeñas.
IMEI	`356938035643809`	`35693803*****09`	Revele solo el TAC o dígitos finales cuando exista necesidad operativa. Evite mostrar el identificador completo del dispositivo en logs o herramientas de soporte.

Estos ejemplos son intencionalmente conservadores. La cantidad exacta de caracteres visibles puede cambiar según el flujo, pero cada sistema debe tomar esa decisión explícitamente.

Orientaciones de implementación

La lógica de enmascaramiento debe vivir en código compartido, no ser reimplementada independientemente en cada pantalla o servicio. Una pequeña biblioteca o servicio compartido reduce inconsistencias y facilita futuros cambios de política.

En organizaciones con múltiples sistemas, la forma más práctica de garantizar consistencia es adoptar una biblioteca estándar de enmascaramiento. En lugar de explicar la política completa a cada equipo y revisar manualmente cada implementación, la empresa puede recomendar una interfaz única para campos como CPF, correo electrónico, teléfono, IP y documentos.

Esto hace que la verificación sea más simple. En lugar de validar si cada proyecto implementó correctamente cada regla, la revisión pasa a verificar si el proyecto está usando la biblioteca aprobada. La política sigue siendo importante, pero su aplicación queda centralizada, comprobable y más fácil de evolucionar.

En algunas empresas, puede tener sentido desarrollar una biblioteca interna para esto, especialmente cuando existen reglas regulatorias, formatos locales, requisitos de auditoría o estándares específicos de producto. Esa biblioteca puede incluir pruebas, documentación, ejemplos de uso y versionado claro para cambios de comportamiento.

Los cambios en reglas de enmascaramiento deben versionarse y comunicarse, porque pueden afectar soporte, auditoría, pruebas e integraciones que dependen del formato mostrado. Si una regla cambia, debe tratarse como un cambio de comportamiento de la biblioteca, no como un detalle interno invisible.

Para empresas que usan LLMs o GenAI en el desarrollo, el mismo principio también se aplica. La recomendación de enmascaramiento puede formar parte de una skill, guideline o paquete de contexto usado por asistentes internos, instruyendo al modelo a usar la biblioteca estándar en lugar de generar nuevas implementaciones de enmascaramiento para cada proyecto.

Cada función de enmascaramiento debe recibir un valor normalizado y devolver una representación enmascarada. Normalización y enmascaramiento son preocupaciones relacionadas, pero separadas. Por ejemplo, un teléfono puede normalizarse internamente al formato E.164, mientras la capa de visualización puede formatearlo según la localidad del usuario antes de aplicar el patrón visible.

Los campos de PII deben enmascararse antes de entrar en pipelines de log, observabilidad o analytics. Después de que el dato sensible fue indexado, replicado y retenido, la corrección se vuelve mucho más difícil.

El tamaño de la entrada importa. Los valores cortos no deben filtrar demasiada información por accidente. Si la parte local de un correo tiene solo dos caracteres, revelar el primer y último carácter revela la parte local completa. En esos casos, enmascare el segmento completo o revele solo un carácter.

La política también debe definir qué ocurre con valores inválidos o inesperados. Una función de enmascaramiento debe fallar de forma cerrada: si no puede interpretar un valor con seguridad, debe devolver una representación totalmente enmascarada o redactada en lugar de la entrada original.

Por último, pruebe el comportamiento de enmascaramiento como lógica relevante para seguridad. Las pruebas unitarias deben cubrir valores normales, valores cortos, valores malformados, formatos internacionalizados, separadores, valores vacíos y valores ya enmascarados. Las pruebas de regresión son útiles porque cambios accidentales en el enmascaramiento pueden aumentar la exposición silenciosamente.

Hashing y criptografía son controles diferentes

Enmascaramiento, hashing y criptografía resuelven problemas diferentes.

La criptografía protege la confidencialidad transformando datos con una clave criptográfica. Si el sistema necesita recuperar el valor original, la criptografía puede ser apropiada para almacenamiento o transmisión, dependiendo del modelo de amenaza y de la gestión de claves.

Hashing transforma datos en un resumen de tamaño fijo. Es útil para verificaciones de integridad y, con algoritmos adecuados de hash de contraseña, para almacenamiento de contraseñas. Hashes simples de PII predecible suelen ser débiles porque muchos identificadores tienen espacios de búsqueda pequeños o enumerables. Si es necesario usar hash de PII para coincidencia o deduplicación, use una construcción con clave u otro diseño adecuado al riesgo.

El enmascaramiento cambia lo que se muestra o exporta. No protege el valor original donde ese valor todavía existe. Un campo enmascarado en una interfaz no significa que la base de datos esté cifrada. Un valor enmascarado en un log no significa que los sistemas anteriores dejaron de procesar la PII original.

Buena ingeniería de privacidad normalmente combina estos controles: minimizar recolección, restringir acceso, enmascarar visualización, cifrar almacenamiento y transporte sensibles, auditar uso y eliminar datos cuando ya no sean necesarios.

Conclusión

El enmascaramiento de PII es un control práctico para reducir exposición innecesaria de datos personales, pero solo funciona bien cuando es intencional y consistente.

El riesgo principal no es solo mostrar demasiados caracteres en un lugar. Es mostrar caracteres diferentes en lugares diferentes, permitiendo que fragmentos sean combinados. Una política compartida de enmascaramiento ayuda a prevenir ese modo de falla y da a los equipos de ingeniería un estándar claro para aplicar en aplicaciones, logs, herramientas de soporte, exportaciones y flujos de datos no productivos.

El enmascaramiento debe tratarse como parte de un programa más amplio de privacidad y seguridad. Apoya la minimización de datos, mejora la privacidad del usuario y reduce la exposición operativa, pero no reemplaza criptografía, control de acceso, revisión legal o buena gobernanza de datos.

Referencias

Primitivas y vulnerabilidades

2026-04-26T16:20:00-03:00

Introducción

La semana pasada probé el uso de LLMs para apoyar el proceso de investigación de vulnerabilidades. Eso me hizo pensar: ¿cómo podemos “enseñar” a un modelo a ayudar realmente a encontrar bugs válidos?

Reflexioné sobre mi propio proceso: cómo analizo código, modelo amenazas y llego al punto en que algo se convierte, de hecho, en una vulnerabilidad.

Entendiendo, o creando, primitivas

En resumen, percibí que intento responder tres preguntas durante los análisis:

¿Qué está intentando hacer este código, feature, componente o endpoint?
¿Qué hace realmente?
¿Qué es posible hacer con eso?

Elijo una primitiva: la menor parte del sistema que ejecuta una acción, como una función, endpoint o componente. Primero intento entender qué debería hacer, usando documentación, nombres y contexto.

Después observo qué hace realmente: ejecuto, pruebo entradas válidas e inválidas, inspecciono logs y comparo con el comportamiento esperado.

Cuando encuentro una discrepancia entre intención y realidad, me pregunto: ¿qué se puede hacer con esto? A partir de ahí mapeo qué podría controlar un actor malicioso, qué acciones conseguiría ejecutar y cuál sería el impacto.

Si esa diferencia permite causar un impacto real, entonces es una vulnerabilidad.

Pequeñas discrepancias aisladas a veces no generan impacto relevante, pero cuando se encadenan casi siempre revelan vectores interesantes. Después de mirar lo micro, es necesario tener un entendimiento de lo macro: cómo todas esas primitivas pueden combinarse.

Ahora estoy usando algunos prompts generados a partir de este entendimiento en el día a día, de manera automatizada e integrada a mi workflow. Me apoyan en un entendimiento más rápido de componentes, sugieren entradas de datos más contextuales, proponen entradas de prueba y traducen discrepancias en posibles escenarios.

Un ejemplo simple

En un análisis pasado, probé una aplicación web e identifiqué una pantalla de login. Hice varias pruebas, incluyendo el uso de un correo válido con contraseñas incorrectas, intentando generar feedbacks diferentes de la aplicación para entender mejor el comportamiento del flujo.

Después de más de cinco intentos de login con la contraseña incorrecta, la aplicación devolvió una advertencia: la cuenta estaba bloqueada porque el límite de intentos había sido excedido.

Con la primera pregunta, la intención parecía clara: ese control existía para prevenir ataques de fuerza bruta.

Con la segunda pregunta, el comportamiento real tenía detalles importantes. El bloqueo no expiraba automáticamente, el usuario no tenía una forma simple de desbloquear su propia cuenta y no se enviaba ninguna notificación por correo avisando sobre el bloqueo. Para recuperar el acceso, era necesario contactar al soporte.

Con la tercera pregunta, el impacto posible quedaba más claro. Un actor malicioso no necesitaba descubrir la contraseña ni acceder a la cuenta. Bastaba con conocer o enumerar correos válidos y realizar intentos de login con contraseñas incorrectas para bloquear cuentas reales. Un control creado para proteger contra fuerza bruta podría ser usado como una primitiva de denegación de servicio contra usuarios legítimos.

Conclusión

Pensar en primitivas ayuda a transformar el análisis en un proceso más explícito. En lugar de mirar el sistema solamente como un conjunto grande y complejo de funcionalidades, paso a observar pequeñas acciones, comparar intención y realidad, y después entender cómo esas diferencias pueden ser usadas.

Este razonamiento es útil para la investigación manual y también para el uso de LLMs. Cuanto mejor puedo describir una primitiva, su intención, su comportamiento real y su posible impacto, mejor puedo usar modelos y automatizaciones como apoyo al proceso de investigación. Al final, encontrar vulnerabilidades sigue dependiendo del juicio técnico, pero estructurar el camino hacia ellas vuelve ese juicio más claro, repetible y fácil de comunicar.

Seguridad digital para niños: preparando a la próxima generación

2026-04-26T15:30:00-03:00

La seguridad de la información necesita llegar antes a las personas. Durante mucho tiempo, este tema fue tratado como algo restringido a profesionales, empresas y equipos técnicos. Pero la realidad cambió: los niños crecen conectados, usan dispositivos desde temprano, conversan en entornos digitales, juegan en línea, consumen contenidos, comparten información y construyen una parte importante de sus relaciones en el ciberespacio.

Este entorno ofrece enormes oportunidades, pero también expone a niños y familias a riesgos que no siempre son fáciles de percibir. Estafas, ingeniería social, robo de cuentas, exposición de datos, desinformación y hábitos inseguros ya forman parte de la vida digital cotidiana. Por eso, preparar a la próxima generación no es solo una decisión educativa. Es una responsabilidad colectiva.

En este contexto conocimos O Cibernauta, un proyecto que utiliza la literatura infantil para acercar a niños, padres y educadores a temas esenciales de seguridad digital y ciudadanía en línea. Su primer libro, O Cibernauta em A Super Senha Secreta, publicado por Editora Brasport, transforma un tema técnico - la creación y el cuidado de contraseñas - en una aventura accesible, lúdica y útil para distintas edades.

La propuesta es simple y poderosa: enseñar temprano, de forma ligera y práctica, para que la seguridad digital forme parte de la educación de los niños antes de que aparezcan los problemas. Cuando un niño entiende por qué importa una contraseña, por qué no debe compartir cierta información o por qué debe desconfiar de pedidos extraños, no aprende solamente una regla. Empieza a desarrollar criterio para navegar en un mundo cada vez más complejo.

El proyecto fue creado por Daniel Meirelles y Eduardo Argollo, quienes identificaron dentro de sus propias familias la dificultad de conversar sobre seguridad de la información de manera clara y práctica. A partir de esa preocupación, construyeron una iniciativa que conecta tecnología, educación y cuidado, mostrando que niños y adultos pueden aprender juntos sobre protección digital.

LESIS decidió apoyar este movimiento de forma concreta. Compramos 30 ejemplares del libro y los estamos donando a personas e instituciones que pueden multiplicar este conocimiento. También seguimos apoyando a los autores con conexiones para eventos, conversaciones y posibles alianzas que ayuden al proyecto a llegar más lejos.

Esta acción es pequeña si se compara con el tamaño del desafío. Aun así, representa una convicción importante: la seguridad de la información no se fortalece únicamente con investigación, herramientas, auditorías o respuesta a incidentes. También se fortalece cuando ayudamos a un niño a entender mejor el entorno digital en el que ya vive.

Al apoyar O Cibernauta, apoyamos una visión de futuro en la que la cultura de seguridad comienza antes de la vida profesional, antes de la primera cuenta bancaria, antes del primer incidente. Comienza en la formación de hábitos, en el diálogo dentro de casa, en la escuela y en los espacios donde los niños pueden aprender con curiosidad, imaginación y cuidado.

Queremos contribuir a un ecosistema de seguridad más maduro, accesible y humano. Esto incluye apoyar a profesionales, comunidades técnicas, iniciativas educativas y también proyectos que miran a quienes todavía están empezando su relación con la tecnología.

Seguiremos buscando formas de apoyar iniciativas que utilizan la educación como herramienta de transformación. Porque proteger el futuro también significa preparar mejor a las personas que van a construirlo.

Conoce más sobre el proyecto en Instagram de O Cibernauta y en Editora Brasport.

Máquina de estados para la gestión de vulnerabilidades

2026-04-09T00:00:00-03:00

En muchas organizaciones, el proceso de gestión de vulnerabilidades sufre un problema recurrente — pero frecuentemente ignorado: la inconsistencia en la definición y el uso de los estados. Es común ver los mismos estados siendo utilizados con significados diferentes por equipos distintos, o encontrar estados redundantes, mal definidos o innecesarios, que generan más confusión que claridad. Esto compromete la trazabilidad, dificulta la comunicación entre áreas, imposibilita métricas confiables y debilita la capacidad de la organización para responder a riesgos reales.

Para hacer frente a este escenario, adoptar una máquina de estados formalizada es una estrategia eficaz. De forma clara y objetiva, representa el ciclo de vida de una vulnerabilidad: cada transición tiene un significado preciso, y todos los equipos comparten el mismo entendimiento sobre lo que representa cada estado.

El flujo comienza con Draft, que indica un borrador en construcción por parte del analista o pentester. La vulnerabilidad aún está siendo documentada y no ha sido sometida a triaje — puede faltar contexto, evidencias o detalles técnicos. Tras esta etapa, pasa a Identified, donde se evalúan el impacto y la prioridad. Si se deriva para corrección, asume el estado Fixing, reflejando el trabajo activo de mitigación. Durante el proceso, puede identificarse que se trata de una repetición de un caso anterior, pasando entonces a Duplicated. Si el análisis muestra que no existe riesgo real — por ejemplo, debido a una condición de explotación inviable — el estado pasa a False Positive. En ciertos casos, la organización opta por aceptar el riesgo, ya sea por limitaciones técnicas, costo de corrección o impacto considerado bajo; en esos casos, el estado es Accepted Risk. Tras la corrección, el hallazgo entra en Retest para ser reevaluado. Si se valida, el proceso concluye con el estado Fixed.

La definición rigurosa de esta máquina de estados no es burocracia: es una base necesaria. Al eliminar ambigüedades y redundancias, mejora la colaboración entre áreas, reduce el retrabajo y permite decisiones mejor fundamentadas. También posibilita generar métricas consistentes, útiles para identificar cuellos de botella, medir la eficiencia y respaldar auditorías.

Esta propuesta de máquina de estados es, al mismo tiempo, compacta y completa. Es el modelo más eficaz que he encontrado en la práctica: lo suficientemente simple para una adopción rápida y lo suficientemente abarcador para cubrir los principales escenarios. Se ha mostrado como un excelente punto de partida para estandarizar procesos, fortalecer la gobernanza y facilitar la integración entre seguridad, producto e ingeniería.

A continuación, el diagrama que representa este flujo:

Taxonomía económica de las vulnerabilidades

2026-02-08T13:52:02-03:00

En ciberseguridad, una de las preguntas más relevantes y, al mismo tiempo, más difíciles de responder con precisión es: ¿cuál es el costo financiero de una vulnerabilidad? Aunque existen diversos programas y prácticas orientados a la gestión de vulnerabilidades, el desafío de asignar un valor monetario a cada falla, especialmente cuando aún no ha sido explotada, sigue poco abordado desde una perspectiva objetiva y cuantitativa.

A medida que los ataques se vuelven más sofisticados, aumentan las exigencias regulatorias y crece la complejidad de los ecosistemas digitales contemporáneos, comprender el costo real de una vulnerabilidad se vuelve esencial. Esta comprensión permite fundamentar decisiones estratégicas de seguridad de la información no solo en percepciones de riesgo, sino también en análisis económicos tangibles.

Contexto y datos analíticos

Históricamente, las decisiones relacionadas con la priorización y la inversión en seguridad se han basado en evaluaciones cualitativas y modelos de riesgo construidos a partir de escenarios hipotéticos. Aunque útiles, estos enfoques no siempre aportan argumentos sólidos para justificar la asignación de recursos frente a áreas como finanzas, producto o dirección ejecutiva.

En este contexto, existe la necesidad de un análisis centrado en la medición económica de vulnerabilidades, basado en datos reales. A partir de un nuevo análisis de datos, este estudio busca responder con mayor precisión la siguiente pregunta:

¿Cuál es el costo de una vulnerabilidad, considerando distintos niveles y categorías de severidad?

Responder esta pregunta aporta un soporte importante para estrategias de priorización, definición presupuestaria y toma de decisiones en seguridad de la información.

Premisas

Para conducir el análisis de forma objetiva, clara y relevante para la toma de decisiones, se establecieron las siguientes premisas. Estas delimitan el alcance del estudio y sustentan el enfoque metodológico adoptado.

1. Las vulnerabilidades tienen valor económico medible: cada vulnerabilidad puede asociarse con un valor monetario que refleja el esfuerzo requerido para su descubrimiento y reporte, así como los riesgos que representa. Los programas de bug bounty se toman como referencia de mercado para esta medición.

2. El valor de la vulnerabilidad aumenta con la severidad: se asume que la severidad de la vulnerabilidad, determinada por impacto y probabilidad de explotación, está directamente relacionada con su costo. Las vulnerabilidades críticas tienden a implicar riesgos mayores y, por tanto, costos superiores.

3. Las recompensas de bug bounty son proxies válidos para estimar payouts organizacionales: los montos pagados en programas de bug bounty se utilizan como estimaciones conservadoras del payout organizacional asociado al descubrimiento y reporte de vulnerabilidades. Para mayor rigor, siempre se utiliza el valor mínimo dentro de cada rango publicado de recompensas.

4. El foco está exclusivamente en la fase de descubrimiento: el análisis no contempla etapas posteriores del ciclo de vida de la vulnerabilidad (como remediación, revalidación, divulgación o impacto de explotación). Se concentra únicamente en la estimación del payout asociado a la identificación.

5. Los recursos de seguridad son limitados y requieren asignación estratégica: dado que los presupuestos de seguridad son finitos, comprender el costo por vulnerabilidad respalda decisiones más efectivas sobre asignación de esfuerzo e inversión.

Fuera de alcance

Aunque relevantes, los siguientes temas quedan fuera del alcance de este estudio:

1. Diseño de una estrategia completa de gestión de vulnerabilidades: este documento no propone un framework integral de gestión de vulnerabilidades; se limita al análisis del payout asociado al descubrimiento. No se abordan temas como priorización de correcciones, políticas de remediación, procesos de respuesta o integración con sistemas de gestión de riesgos.

2. Evaluación o comparación de proveedores, herramientas o métodos específicos: el objetivo no es comparar soluciones ni recomendar plataformas. Los datos de bug bounty se usan exclusivamente como insumo empírico para estimación de payouts, sin juicios de valor sobre efectividad o eficiencia frente a otros enfoques.

3. Estimación del impacto financiero de incidentes reales: el estudio no modela consecuencias financieras de explotaciones exitosas, como fuga de datos, interrupción operativa, sanciones regulatorias o pérdida reputacional. El foco es la medición del payout asociado al descubrimiento, no el impacto final de vulnerabilidades explotadas.

4. Propuestas presupuestarias o recomendaciones directas de asignación de recursos: aunque los resultados pueden apoyar decisiones de inversión en seguridad, este trabajo no ofrece recomendaciones prescriptivas de asignación presupuestaria. La aplicación práctica depende del contexto y de las prioridades de cada organización.

5. Análisis de vulnerabilidades desconocidas o zero-days: el análisis se restringe a vulnerabilidades conocidas y catalogadas. Cuestiones relacionadas con fallas aún no descubiertas, incluidas aquellas explotadas por actores maliciosos antes de su divulgación pública (zero-days), están fuera de alcance.

Enfoque

Inspirado en la teoría de la asimetría de información presentada en The Market for Lemons: Quality Uncertainty and the Market Mechanism [1], este estudio parte de la premisa de que los mercados pueden revelar precios incluso bajo incertidumbre sobre la calidad del bien transado, siempre que existan mecanismos de señalización mínimamente estables.

En seguridad de la información, los programas de bug bounty funcionan como esos mecanismos al asignar valores monetarios diferenciados a las vulnerabilidades según su severidad percibida. Por lo tanto, se asume que las recompensas reflejan, de forma conservadora, un valor de mercado asociado al descubrimiento y reporte de vulnerabilidades, mitigando parcialmente la asimetría entre quienes identifican vulnerabilidades y quienes soportan su riesgo. Con base en esta premisa, la metodología adopta un enfoque cuantitativo y comparativo, utilizando datos reales de programas de bug bounty para estimar niveles típicos de payout organizacional entre categorías de severidad.

Aunque las recompensas no representan el costo total derivado de la existencia o explotación de una vulnerabilidad, aportan un proxy estandarizado y empíricamente observable para la medición económica. Desde la perspectiva de la asimetría de información, los programas de bug bounty operan como mercados de incentivos en los que el precio señala no solo el valor percibido de la vulnerabilidad, sino también el esfuerzo esperado para su descubrimiento. En este esquema, los investigadores independientes tienden a invertir racionalmente solo cuando el payout neto esperado supera los costos marginales de descubrimiento, validación y reporte, condición necesaria para la rentabilidad y la continuidad operativa.

Cuando los montos ofrecidos se perciben como insuficientes frente a la complejidad de la superficie de ataque o los requisitos de validación, el compromiso y el volumen de reportes tienden a caer. De forma simétrica, las organizaciones ajustan dinámicamente las recompensas como mecanismos de atracción o desincentivo, aumentándolas cuando escasean reportes calificados o reduciéndolas cuando el volumen de vulnerabilidades reportadas excede la capacidad de clasificación y remediación.

Este ciclo de entrada, salida y migración entre programas actúa como un mecanismo autocorrectivo. En consecuencia, aunque la asimetría de información no desaparece por completo, tiende a mantenerse residual y operacionalmente aceptable, ya que desajustes persistentes entre esfuerzo requerido y pago ofrecido son detectados rápidamente por los investigadores y repercutidos en la dinámica de precios del mercado.

Alcance del análisis

El análisis se restringe a la etapa de descubrimiento de vulnerabilidades, es decir, al esfuerzo necesario para identificar y reportar una vulnerabilidad con evidencia técnica. Las fases de remediación, revalidación y divulgación quedan fuera de alcance. Los datos se obtienen exclusivamente de fuentes públicas, priorizando:

Plataformas de bug bounty con información abierta;
Recompensas categorizadas por severidad;
Múltiples geografías, para mayor representatividad.

Justificación del enfoque

Al utilizar datos de mercado (recompensas efectivamente pagadas), este enfoque evita la subjetividad típica de las estimaciones de impacto y adopta un criterio reconocido en distintos sectores como referencia práctica de valor. Este método también permite comparaciones futuras con otros modelos de inversión en seguridad, como pruebas de penetración (pentests) o herramientas automatizadas, proporcionando una base concreta para evaluar retorno sobre la inversión (ROI) y orientar la asignación de recursos.

Metodología

La metodología adoptada en este estudio fue diseñada para garantizar transparencia, reproducibilidad y consistencia en el análisis de datos extraídos de plataformas públicas de bug bounty. A continuación se detallan las principales etapas del proceso:

La recolección de datos se realiza mediante scrapers propios desarrollados para extraer información de programas activos que:

Divulgan valores financieros asignados a vulnerabilidades;
Clasifican claramente las fallas por severidad.
Se incluyen programas de empresas de distintos tamaños y sectores, con cobertura nacional e internacional, para capturar una visión representativa del mercado.

Después de la recolección, los datos se filtran con los siguientes criterios de exclusión:

Iniciativas VDP (Vulnerability Disclosure Program) que no ofrecen recompensas financieras;
Programas con datos inconsistentes o incompletos de severidad o recompensas;
Recompensas genéricas sin vínculo con severidad.

Las recompensas se clasifican en las siguientes categorías, con base en las descripciones proporcionadas por los programas o, cuando no están disponibles, en criterios compatibles con el estándar CVSS:

Informativa
Baja
Media
Alta
Crítica

Normalización de valores, para evitar distorsiones en los resultados:

Para rangos de valores (por ejemplo, $1,000 a $5,000), se utiliza el valor mínimo del rango, adoptando un enfoque conservador;
Todos los valores se convierten a dólares estadounidenses (USD), con base en una tasa de cambio de referencia.

Análisis

Se analizaron 808 programas de bug bounty, distribuidos entre HackerOne, Bugcrowd, YesWeHack, Intigriti, BugHunt y Bugpay. La muestra incluye programas activos de organizaciones con diferentes tamaños, sectores y ubicaciones geográficas, lo que proporciona una visión amplia y representativa del mercado de recompensas por vulnerabilidades.

Figura 1: distribución de programas de bug bounty por plataforma.

Los datos utilizados en este análisis están disponibles para reproducción y verificación en el repositorio: https://huggingface.co/datasets/lesis-lat/bug-bounty-programs-rewards/viewer/default/train

Figura 2: distribución de programas de bug bounty por tipo de visibilidad (público vs privado).

La tabla siguiente presenta los valores mínimos y máximos de recompensa observados en cada categoría de severidad, destacando la amplia variación existente entre programas y plataformas. En particular, mientras que vulnerabilidades de baja severidad pueden tener recompensas mínimas simbólicas, los rangos superiores, especialmente para severidades alta y crítica, alcanzan valores significativamente elevados, reflejando diferentes estrategias de incentivo y percepción de riesgo.

	Baja	Media	Alta	Crítica
Mínimo	$1.00	$3.00	$5.00	$50.00
Máximo	$2,000.00	$47,175.93	$58,969.91	$100,000.00

Tabla 1: valores mínimo y máximo de recompensas de bug bounty por severidad (USD).

Estos valores delimitan todo el rango de variación de los datos observados y sirven de base para análisis estadísticos más robustos.

Adicionalmente, el análisis de tendencia central revela patrones más estables de precios por severidad. La tabla siguiente presenta valores de media, mediana y moda, indicando que, pese a la presencia de outliers relevantes, la concentración de recompensas ocurre en niveles bien definidos para cada categoría.

Severidad	Media	Mediana	Moda
Baja	$154.75	$100.00	$100.00
Media	$563.93	$350.00	$500.00
Alta	$1,825.83	$1,000.00	$1,000.00
Crítica	$4,601.35	$3,000.00	$3,000.00

Tabla 2: media, mediana y moda de recompensas por severidad (USD).

Figura 3: comparación de la mediana de recompensas por plataforma y severidad.

Comparar media y mediana a la luz de los coeficientes de skewness indica que la media aritmética no representa adecuadamente el comportamiento típico de las recompensas por vulnerabilidad. Todas las categorías de severidad presentan alta asimetría positiva (skewness variando aproximadamente entre 6.49 y 21.72), evidenciando distribuciones fuertemente concentradas en valores bajos, con pocos pagos excepcionalmente altos. Aunque la intensidad del skewness varía entre severidades, especialmente en vulnerabilidades de severidad media, este patrón explica la divergencia sistemática entre media y mediana y confirma la sensibilidad de la media a valores extremos, haciendo más apropiadas las métricas robustas para la interpretación de datos.

Figura 4: precios típicos de vulnerabilidades por severidad entre plataformas.

La variabilidad de los valores de recompensa se evaluó mediante el rango intercuartílico (IQR), que captura la dispersión del núcleo central de la distribución. Se observa un aumento consistente de la variabilidad típica a medida que crece la severidad de la vulnerabilidad. Para vulnerabilidades de baja severidad, el IQR es aproximadamente USD 141.03, indicando mayor concentración de valores practicados. Este intervalo se amplía a USD 300.00 para severidad media, USD 1,410.30 para severidad alta y USD 3,500.00 para vulnerabilidades críticas, mostrando una expansión progresiva del rango en el que se concentran las recompensas más frecuentes. Este comportamiento indica que vulnerabilidades más severas se asocian no solo con valores más altos, sino también con mayor incertidumbre económica de precios.

Figura 5: medianas de recompensas por severidad en programas públicos vs privados.

En conjunto, los resultados muestran que, aunque existen patrones consistentes de precios por severidad, el mercado de bug bounty presenta alta heterogeneidad y presencia recurrente de valores extremos. Aun así, las estadísticas de tendencia central y dispersión sustentan la conclusión de que el descubrimiento de vulnerabilidades tiene un valor económico observable y diferenciado por nivel de severidad.

Por lo tanto, es metodológicamente adecuado establecer rangos típicos de payout por severidad, siempre que esos rangos se definan mediante medidas robustas como mediana e IQR y no se interpreten como límites determinísticos. Con base en los datos analizados, el descubrimiento de vulnerabilidades de baja severidad presenta un payout típico concentrado entre aproximadamente USD 59 y USD 200, con mediana de USD 100. Para severidad media, el rango típico se ubica entre USD 200 y USD 500, con mediana en torno a USD 350. Las vulnerabilidades de alta severidad muestran mayor dispersión, con valores concentrados entre USD 590 y USD 2,000 y mediana de USD 1,000, mientras que las vulnerabilidades críticas exhiben los rangos de payout más altos, aproximadamente entre USD 1,500 y USD 5,000, con mediana de USD 3,000. Estos rangos reflejan el comportamiento típico del mercado y destacan el aumento progresivo de la incertidumbre económica a medida que aumenta la severidad.

Conclusión

Este estudio investigó la economía de los pagos de recompensa (payouts) por vulnerabilidad mediante un enfoque cuantitativo basado en datos reales de programas de bug bounty. En este contexto, “costo” se refiere al valor pagado por las organizaciones por reportes de vulnerabilidad aceptados, y no al costo interno de esfuerzo incurrido por los investigadores para descubrir y reportar vulnerabilidades. Partiendo de la premisa de que estos programas operan como mecanismos de mercado bajo asimetría de información, el análisis buscó estimar objetivamente cómo varían los valores de payout según la severidad.

Los resultados muestran que el descubrimiento de vulnerabilidades tiene un valor económico observable y sistemáticamente diferenciado por severidad. Los análisis estadísticos evidenciaron distribuciones fuertemente asimétricas en todas las categorías, con valores extremos recurrentes, lo que vuelve a la media aritmética inadecuada como métrica representativa aislada. En contraste, medidas robustas como mediana e IQR resultaron más apropiadas para capturar el comportamiento típico del mercado.

Con base en estos indicadores, fue posible estimar rangos típicos de payout asociados al descubrimiento de vulnerabilidades. Las vulnerabilidades de baja severidad presentan valores concentrados entre aproximadamente USD 59 y USD 200, con mediana de USD 100. Para severidad media, el rango típico se ubica entre USD 200 y USD 500, con mediana en torno a USD 350. Las vulnerabilidades de alta severidad se concentran entre USD 590 y USD 2,000, con mediana de USD 1,000, mientras que las vulnerabilidades críticas presentan los rangos de payout más altos, aproximadamente entre USD 1,500 y USD 5,000, con mediana de USD 3,000. Estos rangos reflejan el comportamiento típico del mercado y destacan el aumento progresivo de la variabilidad económica conforme aumenta la severidad.

Desde una perspectiva económica, estos hallazgos refuerzan la interpretación de los programas de bug bounty como mercados de incentivos en los que las recompensas funcionan como señales que equilibran la oferta de esfuerzo especializado de investigadores y la demanda organizacional de descubrimiento de fallas. En este entorno, los investigadores tienden a asignar esfuerzo solo cuando el retorno esperado excede el costo marginal, sosteniendo la rentabilidad y la continuidad operativa. La asimetría de información, aunque persiste, es disciplinada por la dinámica de migración entre programas y tiende a mantenerse en niveles bajos y aceptables. Aunque estas recompensas no representan el costo total asociado a la existencia o explotación de una vulnerabilidad, sí proporcionan un proxy empírico estandarizado del payout organizacional asociado a su identificación y reporte.

Desde una perspectiva práctica, estimar el Expected Vulnerability Discovery Cost (EVDC) por severidad aporta soporte objetivo para decisiones de priorización, planificación presupuestaria y evaluación de inversiones en seguridad. Al traducir vulnerabilidades en rangos económicos medibles, el estudio ayuda a reducir la dependencia exclusiva de evaluaciones cualitativas y acerca la gestión de vulnerabilidades a una lógica económica comparable con otras inversiones en tecnología y riesgo.

Finalmente, aunque limitado al alcance del descubrimiento y a programas de bug bounty, este trabajo establece una base empírica para investigaciones futuras que exploren la relación entre costo de descubrimiento, costo de remediación e impacto de explotación, así como comparaciones con otros modelos de inversión en seguridad. En este sentido, el análisis no busca ofrecer valores determinísticos, sino referencias económicas robustas para comprender y discutir los costos de vulnerabilidades en entornos digitales contemporáneos.

Referencias

Consideraciones para la elaboración de informes de seguridad

2026-01-15T15:15:10-03:00

Después de días o semanas de trabajo, identificaste fallas relevantes, comprendiste la superficie de ataque del entorno evaluado y reuniste evidencia suficiente para demostrar riesgos reales para el negocio. Desde el punto de vista técnico, la evaluación terminó. Lo que aún falta es transformar ese conocimiento en un informe claro, accionable y comprensible.

En cualquier actividad de seguridad de la información — pruebas técnicas, auditorías, evaluaciones de madurez o análisis de riesgo — el informe es el principal artefacto entregado al cliente. Es el medio por el cual los hallazgos técnicos se convierten en decisiones estratégicas. Sin un buen informe, incluso el mejor trabajo técnico pierde impacto.

Los informes de seguridad documentan objetivos, contexto, alcance, metodología, hallazgos, riesgos y recomendaciones. La cantidad de información involucrada es grande, y por eso la forma en que se organiza y presenta es tan importante como el contenido en sí. Este texto no propone un modelo fijo, sino orientaciones prácticas para mejorar la calidad de la comunicación escrita en seguridad de la información.

Ten claridad sobre el objetivo

Todo informe de seguridad debe partir de una pregunta simple: ¿cuál era el objetivo de la evaluación? Sin esa respuesta bien definida, el documento tiende a convertirse en una colección de hallazgos desconectados. Es común enfocarse en exceso en detalles técnicos. Aunque forman parte del trabajo, el objetivo de una evaluación de seguridad no es demostrar conocimiento, sino reducir riesgo. El informe debe reflejar esa intención.

Mantener el objetivo en mente durante la redacción ayuda a definir qué incluir, el nivel de detalle adecuado y el tono del texto. Crear un borrador antes de escribir suele facilitar este proceso, reduciendo repeticiones, evitando vacíos y haciendo la escritura más fluida.

Comprende quién va a leer

Los informes de seguridad rara vez tienen un único lector. Ejecutivos, gestores y equipos técnicos suelen consumir el mismo documento con expectativas diferentes. Por eso, el texto debe ser comprensible incluso para quien no domina los detalles técnicos. Esto no significa simplificar en exceso, sino explicar conceptos e impactos de forma clara y contextualizada.

Incluir un resumen ejecutivo es una práctica consolidada. Presenta una visión de alto nivel de los principales riesgos y de la postura general de seguridad, y suele ser la única parte leída por quienes toman decisiones. El resto del informe puede ser más técnico, siempre que aporte contexto suficiente y no asuma conocimiento previo.

Sé criterioso con el contenido

Un informe de seguridad no necesita ser extenso para ser completo. Necesita ser relevante. Todo lo que se incluya debe contribuir a la comprensión del riesgo o a la toma de decisiones. Salidas crudas de herramientas, capturas de pantalla repetitivas o información redundante tienden a dificultar la lectura y diluir el mensaje principal.

El foco debe estar en evidencias que sostengan conclusiones claras. Evaluar continuamente cómo cada información se conecta con el objetivo de la evaluación ayuda a mantener el texto cohesionado y bien direccionado.

Busca referencias y estándares

Escribir buenos informes es una habilidad que se desarrolla con práctica y observación. Analizar informes bien estructurados ayuda a identificar estándares de mercado, estilos de redacción eficaces y buenas prácticas de comunicación.

Informes públicos, programas de bug bounty y repositorios con ejemplos reales son fuentes valiosas de referencia. Buscar inspiración no significa copiar modelos, sino comprender cómo otros profesionales comunican riesgos de forma clara y objetiva.

Cuida la presentación

La presentación influye directamente en la credibilidad del informe. Un contenido técnicamente sólido, pero mal redactado o visualmente inconsistente, transmite descuido. La estandarización de títulos, un espaciado adecuado y un lenguaje claro hacen una diferencia real.

Errores gramaticales y frases ambiguas comprometen la percepción profesional del documento. Independientemente del idioma, una revisión cuidadosa es esencial. Al final, el informe representa tanto los hallazgos como a quien lo produjo.

Documenta desde el inicio

Un buen informe empieza durante la evaluación, no después de que termina. Las anotaciones realizadas desde el inicio ahorran tiempo, evitan retrabajo y facilitan revisiones futuras. Registrar comandos, resultados, evidencias y observaciones permite reconstruir el razonamiento detrás de cada hallazgo. Con el tiempo, es natural desarrollar modelos propios de documentación ajustados al flujo de trabajo de cada profesional. La calidad del informe final depende directamente de la calidad de esa información.

Organización, herramientas y seguridad de la información

Más importante que la herramienta utilizada es el proceso adoptado. La información debe estar organizada, accesible y protegida, especialmente porque las evaluaciones de seguridad suelen involucrar datos sensibles. Automatizar la captura de salidas, complementarla con observaciones personales y usar capturas de pantalla con criterio ayuda a no perder información relevante. El objetivo final es que los datos sean claros, confiables y fáciles de consultar.

La importancia de los respaldos

Los respaldos rara vez reciben atención hasta que se vuelven necesarios. La documentación perdida representa tiempo desperdiciado y, en algunos casos, impacto directo en la entrega. Mantener copias seguras de la documentación, archivos relevantes y snapshots de entornos debe formar parte de la rutina. En seguridad de la información, prevenir casi siempre cuesta menos que corregir.

La importancia de la revisión por pares y de miradas externas

Ningún informe debería considerarse final sin revisión. La revisión por pares mejora la calidad técnica, ayuda a identificar inconsistencias y fortalece la narrativa de los hallazgos. Del mismo modo, la lectura por alguien fuera del contexto de la evaluación es fundamental para validar claridad y comprensión. Si ese lector no entiende el riesgo o el razonamiento presentado, es probable que el cliente tampoco lo entienda.

Cuando la revisión humana no es posible, los modelos de lenguaje pueden utilizarse como apoyo para identificar errores gramaticales, problemas de cohesión y oportunidades de mejora. No reemplazan a revisores humanos, pero pueden funcionar como un segundo par de ojos cuando se usan con criterio.

Herramientas conceptuales

Las herramientas conceptuales ayudan a organizar el pensamiento antes y durante la escritura. Modelos como 5W y 5W2H obligan a reflexionar sobre propósito, contexto, alcance y método, evitando informes sin dirección clara.

Estructuras como Problema, Causa, Impacto y Recomendación ayudan a conectar hallazgos técnicos con riesgos reales y acciones prácticas. Los enfoques basados en escenarios de amenaza facilitan la comunicación de consecuencias, especialmente para públicos no técnicos.

Conceptos como la pirámide invertida y la separación entre hecho, evidencia e interpretación mejoran la claridad y la credibilidad del texto. Preguntarse continuamente qué necesita entender o decidir el lector después de cada sección ayuda a mantener el informe objetivo y enfocado.

Conclusión

Los informes de seguridad son instrumentos de comunicación. Conectan análisis técnicos con decisiones que afectan personas, procesos y negocios. Producir buenos informes exige claridad de propósito, comprensión del público, organización de la información y cuidado en la forma. Revisiones, buenas prácticas de documentación y herramientas conceptuales no son burocracia, sino mecanismos de calidad.

Un informe bien escrito no es solo un registro de lo encontrado. Es el puente entre descubrimiento y acción. Invertir tiempo en esta etapa es una de las formas más eficaces de generar impacto real en seguridad de la información.

Referencias

Fortaleciendo la comunidad de ciberseguridad en Brasil a través de la educación

2026-01-14T19:13:00-03:00

En 2026, LESIS dará un paso más concreto en su compromiso con el desarrollo sostenible del ecosistema de tecnología y seguridad de la información en Brasil. Realizaremos una donación financiera a la ONG Mente Binária, una organización que actúa directamente en la formación de nuevos profesionales para el área de la ciberseguridad.

Creemos que la seguridad de la información no se construye únicamente con tecnología, sino con personas capacitadas, acceso al conocimiento y oportunidades reales de desarrollo profesional. En este punto, el trabajo de Mente Binária resulta fundamental: al invertir en educación técnica accesible y de calidad, la organización ayuda a transformar trayectorias individuales, impactando a familias, comunidades y, en última instancia, al país.

La formación de nuevos profesionales en seguridad fortalece toda la cadena del sector: reduce la escasez de talento en el mercado, eleva el nivel técnico de la industria y contribuye a un entorno digital más seguro, resiliente y preparado para los desafíos actuales y futuros. Cada persona formada representa no solo una nueva carrera, sino un avance colectivo para la industria de la seguridad de la información en su conjunto.

Nuestra contribución financiera es, por sí sola, una acción puntual. Sin embargo, refleja una convicción más amplia: cuando los recursos adecuados llegan a las personas adecuadas, el impacto se multiplica. Las pequeñas acciones, cuando se realizan de manera constante y alineadas con un propósito claro, generan cambios duraderos.

Como institución, LESIS entiende que su papel va más allá de la actividad comercial. Tenemos la responsabilidad de contribuir positivamente al ecosistema en el que operamos, apoyando iniciativas que generen valor social, técnico y humano.

Seguiremos buscando formas de apoyar proyectos que creen en la educación como motor de transformación. Porque, aunque cada acción individual parezca pequeña, es así — paso a paso — como se construye un gran impacto.

Por qué patrocinamos eventos de Seguridad de la Información

2025-11-30T09:33:00-03:00

El año 2025 ha sido marcante para LESIS. Entre proyectos, investigaciones y el crecimiento de nuestra actuación en el mercado, también asumimos un compromiso que consideramos fundamental: contribuir directa y activamente a la comunidad de Seguridad de la Información. Creemos que la innovación nace del encuentro entre personas, del intercambio constante de conocimiento y de la construcción colectiva de soluciones que hacen el mundo digital más seguro. Por eso, apoyar eventos en todo el país se ha convertido en una prioridad y en una forma concreta de impulsar el desarrollo del sector.

A lo largo de este año, patrocinamos financieramente y participamos en iniciativas como Hacking na Web Day RJ, en Río de Janeiro; XibéSec, en Belém; RioCyberSec, también en Río; FortalSec, en Fortaleza; y Hack in Cariri, en Juazeiro do Norte. Cada uno de estos eventos tiene su propia identidad y público: algunos con un fuerte vínculo académico, otros más orientados a la industria, algunos más grandes y consolidados, y otros aún en expansión. Para nosotros, esta pluralidad es precisamente lo que hace tan rica a la comunidad — y apoyar diferentes perfiles es una manera de garantizar que el conocimiento llegue cada vez más lejos. Además de los patrocinios, también nos aseguramos de estar presentes como participantes en eventos destacados, como SBSEG, Web Summit y BSides RJ.

Son espacios donde las discusiones más actuales de la ciberseguridad cobran fuerza, surgen nuevas conexiones y se desarrollan alianzas estratégicas. Estar cerca de estas conversaciones es fundamental tanto para el crecimiento de LESIS como para nuestra capacidad de contribuir efectivamente a los avances del área.

Naturalmente, como empresa, parte de esta inversión retorna en forma de posicionamiento de marca, networking y oportunidades de negocios. Sin embargo, no es eso lo que nos mueve. Nuestra principal motivación es retribuir a la comunidad todo lo que representa para nosotros: conocimiento compartido, inspiración constante y la formación de profesionales que construyen un futuro más seguro para todos. Queremos participar de la base que sostiene este ecosistema, incentivando el surgimiento de nuevos talentos y fortaleciendo iniciativas que generan impacto tanto para quienes están comenzando como para quienes ya tienen una larga trayectoria.

También nos preocupamos por distribuir nuestro apoyo entre diferentes regiones de Brasil. Mientras que algunos polos, como São Paulo, ya cuentan con mayor volumen de inversiones y eventos, otras localidades todavía enfrentan escasez de iniciativas y oportunidades. Apoyar encuentros en el Norte y en el Nordeste, por ejemplo, es una forma de contribuir a un escenario más equilibrado, donde el talento no esté limitado por la geografía.

Este movimiento apenas comienza. Seguimos abiertos a colaborar con quienes comparten esta visión: una comunidad fuerte, diversa, accesible y en constante evolución.

Si organizas un evento y crees en el impacto de la educación, del intercambio y del desarrollo de la seguridad de la información, queremos construir este camino contigo.

Saldo fantasma, rebajas eternas: la trampa de los gift cards

2025-10-04T13:29:00-03:00

Con cierta frecuencia surge la oportunidad de realizar investigaciones de vulnerabilidades en comercios electrónicos. Aunque el contexto sea el mismo, cada una de esas oportunidades es única, ya que siempre existen particularidades en cada aplicación. En esta publicación busco mostrar un caso relacionado con gift cards que considero interesante.

Los sitios que comercializan cualquier tipo de producto presentan una enorme complejidad en la implementación de sus lógicas, y esa complejidad suele dificultar la garantía de que todos los flujos contengan las medidas de seguridad adecuadas. En esta publicación abordaremos específicamente dos elementos frecuentemente presentes en los e-commerces: gift cards y cupones de descuento, en un estudio de caso donde se localizaron primitivas que permitieron la explotación de una vulnerabilidad.

Gift cards: virtuales o físicos, son una especie de tarjeta prepaga que los clientes pueden adquirir para sí mismos o para regalar a otras personas. Poseen un valor monetario asociado que puede utilizarse para compras en el sitio, permitiendo al destinatario elegir los productos o servicios que desee hasta que el saldo del gift card sea completamente utilizado.

Cupón de descuento: se trata de un código, generalmente alfanumérico, entregado a los clientes para reducir el valor de compra de productos o servicios. Al aplicar el cupón durante el proceso de pago, el cliente recibe un descuento o beneficio específico, como un porcentaje de rebaja o envío gratuito, haciendo la compra más ventajosa.

Rocking the gift card loop

Figura 1: Listado de un Gift Card para la venta

Durante un ciclo de actividades de prueba, identifiqué el siguiente escenario: un sitio ofrece la opción de compra de gift cards y, simultáneamente, permite el uso de cupones de descuento en esa misma compra. Por ejemplo, al adquirir un gift card con valor de R$150,00, se permite aplicar un cupón de descuento llamado “15OFF”, que otorga un descuento de R$15. De esta manera, el monto a pagar es de solo R$135,00 por un gift card que todavía conserva la capacidad de compra de R$150,00.

Figura 2: Comprando un Gift Card con cupón de descuento en un e-commerce

El problema en este escenario es que ese gift card puede ser utilizado para la compra de otro gift card, con la posibilidad de aplicar nuevamente el cupón de descuento. Así, en la siguiente transacción es posible adquirir un gift card de R$150,00 utilizando un gift card que costó apenas R$135,00, aplicando otra vez el cupón de descuento de R$15,00.

Surge entonces un patrón: en cada utilización de este flujo ocurre la generación indebida de R$15,00 en saldo adicional. En términos prácticos, en cada transacción el usuario incrementa el valor de crédito disponible sin realizar un nuevo desembolso financiero. Para ilustrar, si el proceso se repite en 10 ciclos consecutivos, el crédito inicial de R$150,00 evoluciona hasta R$300,00, representando un aumento del 100% en el saldo sin ninguna contrapartida financiera. Esta situación caracteriza un escenario de fraude sistémico, ya que permite la creación de saldo ficticio dentro de la plataforma.

Adicionalmente, es importante considerar que cada transacción realizada está sujeta al cobro de tasas operativas por parte de los intermediarios de pago. Así, además del perjuicio derivado de la generación indebida de saldo, el procesamiento recurrente de transacciones incrementa los costos de la operación, ampliando el impacto financiero negativo para la plataforma.

Conclusión

La vulnerabilidad identificada tiene su origen en fallas de lógica de negocio, y su mitigación requiere ajustes estructurales en el flujo de compra. La primera y más directa medida consiste en restringir el uso de gift cards como forma de pago para la adquisición de nuevos gift cards. Esta regla simple elimina la posibilidad de encadenar transacciones que resulten en la generación artificial de saldo. De manera complementaria, se recomienda establecer políticas específicas para los cupones de descuento, impidiendo que se apliquen en operaciones de compra de gift cards. Esta práctica es común en el mercado y busca preservar la integridad financiera del sistema, ya que los gift cards funcionan, en la práctica, como instrumentos de valor almacenado y no deberían ser objeto de promociones que reduzcan su costo de adquisición.

Asimismo, es altamente recomendable implementar mecanismos de prevención y detección de fraudes. El uso de un motor antifraude, integrado al proceso de checkout, permite identificar patrones sospechosos, como múltiples transacciones de aparente bajo riesgo que en la práctica revelan intentos de explotación sistémica. Este tipo de control, asociado al monitoreo continuo y a políticas de limitación de uso (por ejemplo: valor máximo de gift cards adquiridos por cliente en un período determinado), fortalece la resiliencia de la plataforma frente a abusos similares.

En conjunto, estas medidas representan un enfoque de mitigación en múltiples capas, reduciendo la exposición de la empresa al riesgo de fraude financiero y garantizando una mayor confiabilidad.