Riesgo de seguridad y fraude: una amenaza, dos equipos

¿Qué es el riesgo de seguridad y fraude?

El riesgo de seguridad y fraude es la probabilidad de que una debilidad en tu software permita a un atacante cometer fraude contra ti o tus clientes. Une dos campos que suelen trabajar por separado: la seguridad de aplicaciones, que encuentra y corrige fallas de software, y la prevención del fraude, que detecta y detiene el abuso financiero.

La Association of Certified Fraud Examiners (ACFE) explica el fraude con el triángulo del fraude, un modelo del criminólogo Donald Cressey. Tiene tres partes: una "necesidad financiera que no se puede compartir", una "oportunidad percibida" y una "racionalización". Cressey estudió a malversadores, personas que roban el dinero que otros les confían para administrar, así que el triángulo del fraude describe primero el fraude interno.

El fraude externo es el que cometen personas de fuera de la empresa, como clientes, suplantadores o grupos criminales. En el fraude externo contra un negocio digital, el lado de la oportunidad del triángulo del fraude suele ser una falla de software: un restablecimiento de contraseña que no verifica la identidad, una API que devuelve los datos de otro cliente, un formulario de pago que acepta cualquier monto. El equipo de fraude no puede eliminar esa oportunidad. Solo pueden hacerlo quienes escriben el código. Ese es el riesgo de ciberfraude en una frase: el motivo es del atacante, pero la oportunidad es de tu software.

Triángulo del fraude visto desde la aplicación. Elaboración propia.

¿Por qué los programas antifraude dejan fuera a ingeniería?

Las guías sobre fraude que revisamos piden que varios equipos trabajen juntos, pero ninguna nombra al equipo que escribe el código. La Office of the Comptroller of the Currency (OCC) de EE. UU. dice en su Bulletin 2019-37 que "el riesgo de fraude es una forma de riesgo operativo". Espera que los bancos tengan modelos, sistemas de monitoreo o reportes que detecten actividad fraudulenta "en todas las líneas de negocio y funciones".

Las guías de gestión del riesgo de fraude hacen la misma petición. La guía de Stripe sobre gestión del riesgo de fraude pide a las empresas "involucrar a las partes interesadas de distintos departamentos" durante la evaluación del riesgo de fraude, es decir, la revisión de dónde y cómo puede ocurrir el fraude en una organización. La guía nunca menciona a los ingenieros ni a la seguridad de aplicaciones.

Además, los dos equipos hablan idiomas distintos. En un artículo de octubre de 2025, Mastercard escribió que los equipos de ciberseguridad y de fraude usan vocabularios diferentes, lo que dificulta la comunicación. El artículo también cita una encuesta en la que el 60 % de los ejecutivos de fraude y riesgo del mundo dice que se entera de las brechas cibernéticas solo cuando ya empezaron las pérdidas por fraude.

La detección del fraude puede funcionar sin ingeniería. Cerrar la falla por la que pasa el fraude, no: no requiere ingeniería, pero tampoco corrige nada.

¿Qué vulnerabilidades permiten el fraude?

Agrupamos el fraude que nace en una aplicación en cuatro tipos: apropiación de cuentas (account takeover), recolección de datos (data harvesting), fraude en pagos (payment fraud) y cuentas falsas (fake accounts). Cada uno tiene un nombre del lado del equipo de fraude y otro distinto del lado de ingeniería. La tabla usa debilidades de Fluid Attacks Database y casos públicos documentados por reguladores.

El fraude de card testing (prueba de tarjetas) es un ejemplo claro de esta brecha. En el card testing, los atacantes hacen muchos pagos pequeños para saber qué números de tarjetas robadas funcionan. La documentación de Stripe les dice a los comercios que no son desarrolladores, o que usan un plugin o una plataforma, que prevenirlo "suele requerir cambios en el código". Nuestro artículo sobre sistemas de pago seguros cubre otras fallas en los flujos de pago.

Debilidad 417, Account Takeover, en Fluid Attacks Database.

¿Cómo se ve la apropiación de cuentas en nuestra investigación?

Nuestros investigadores de seguridad encuentran caminos de apropiación de cuentas en aplicaciones reales y los publican como advisories. En Bhima 1.27.0 (CVE-2023-0944), una referencia directa insegura a objetos (IDOR), es decir, una falla que permite a un usuario llegar a los datos de otro con solo cambiar un ID, le permitió a un usuario común cambiar las credenciales de otros usuarios, incluidas las del administrador.

En VitalPBX 3.2.3-8 (CVE-2023-0486), una falla de cross-site scripting (XSS) reflejado permitía capturar la cookie de sesión del administrador mediante un enlace malicioso. En CandidATS 3.0.0 (CVE-2022-42750), una falla de XSS almacenado, causada por archivos subidos que la aplicación no validaba bien, permitía a un atacante remoto apropiarse de cuentas de usuarios.

Ninguna de estas fallas parece fraude en el reporte de un escáner. Cada una parece fraude el día en que un atacante la usa.

¿Cómo cambia el riesgo de fraude cuando un negocio crece?

El riesgo de fraude crece más rápido que el negocio, porque cada nueva funcionalidad abre un camino que los atacantes pueden probar. Cuando un negocio crece, suma aplicaciones, API, métodos de pago y aliados. Cada versión nueva cambia un código que el equipo de fraude nunca ve.

Los atacantes también automatizan. El Open Worldwide Application Security Project (OWASP) lista 21 amenazas automatizadas, como el relleno de credenciales (OAT-008), que define como "intentos masivos de inicio de sesión para verificar la validez de pares robados de usuario y contraseña". Gartner predice que para 2027 los agentes de IA reducirán en un 50 % el tiempo necesario para explotar cuentas expuestas.

Las pérdidas se pueden medir. El Internet Crime Complaint Center (IC3) del FBI registra, en su 2025 IC3 Annual Report, unas 4.700 denuncias por apropiación de cuentas, con pérdidas de 359,7 millones de dólares. En América Latina y el Caribe, el resumen ejecutivo del DBIR 2026 ubica la explotación de vulnerabilidades en el 44 % de las brechas y el abuso de credenciales en el 5 %. El riesgo de ciberfraude, entonces, no es fijo. Cambia con cada versión, a medida que el negocio crece.

Relleno de credenciales (OAT-008). Fuente: OWASP, CC BY-SA 4.0

Vulnerabilidades que cuentan como riesgo de fraude

No toda vulnerabilidad es riesgo de fraude, y un equipo de fraude no necesita todo tu backlog. Para evaluar el riesgo de fraude a partir de las vulnerabilidades de seguridad, usamos estas condiciones en nuestro Fraud risk center. Una vulnerabilidad cuenta solo cuando cumple las cinco condiciones:

1. Corresponde al menos a un tipo de fraude: apropiación de cuentas, recolección de datos, fraude en pagos o cuentas falsas.

2. Está abierta y no está marcada como de riesgo cero.

3. Es alcanzable desde internet.

4. Afecta la confidencialidad o la integridad.

5. Muestra evidencia de explotación en el mundo real: su explotación se ha observado, no solo se ha demostrado posible.

El resultado es una lista corta de lo que un atacante podría usar para cometer fraude. Luego, cada categoría de fraude toma el nivel de exposición de su vulnerabilidad abierta más grave, en una escala de Critical, High, Medium, Low y None. La categoría más expuesta aparece primero.

El filtro cambia lo que lee el equipo de fraude, no lo que corrige ingeniería. Convierte el riesgo de seguridad y fraude en una lista que ambos equipos pueden leer. Las vulnerabilidades que no cumplen las cinco condiciones siguen reportadas y gestionadas en la plataforma como siempre. Las cuatro categorías aparecen siempre, incluso sin exposición, porque para un director de seguridad de la información (CISO) que reporta a la junta directiva, "sin exposición" también es una respuesta. Así es como las organizaciones pueden evaluar el riesgo de fraude con datos de seguridad y reforzar sus defensas donde la exposición es mayor.

Categorías de fraude ordenadas por exposición en el Fraud risk center.

¿Cómo debe un equipo de fraude pasarle un riesgo a ingeniería?

Un buen traspaso le da a ingeniería suficiente contexto para actuar sin necesidad de una reunión. Un analista de fraude que ve una exposición High en apropiación de cuentas necesita una sola acción: pedirles a los responsables del sistema afectado que lo corrijan primero.

En el Fraud risk center, esa acción se llama Escalate. El analista puede escalar un sistema o todos los sistemas afectados de una categoría, y agregar hasta 1.000 caracteres de contexto. Los contactos responsables del sistema reciben un correo con el nivel de exposición, el número de vulnerabilidades, hasta 10 ubicaciones vulnerables y un enlace a las vulnerabilidades en la plataforma. Después, el sistema muestra la etiqueta Requested, para que otros analistas sepan que la solicitud ya está en curso.

El escalamiento no cambia la vulnerabilidad, y el analista de fraude no ve el código. Cada equipo conserva su propio trabajo. El equipo de fraude decide qué es urgente desde el punto de vista del fraude; ingeniería recibe la evidencia para corregirlo. Los detalles están en la documentación del Fraud risk center.

Escalamiento de una categoría de fraude a los responsables de los sistemas. Elaboración propia.

Estrategias de prevención del fraude que necesitan a ingeniería

Las estrategias de prevención del fraude basadas en la detección se apoyan en puntajes, reglas y análisis de comportamiento. Estos pasos suman el lado de ingeniería, y un equipo puede empezar cada uno este trimestre.

1. Acuerden un solo vocabulario

Relacionen cada tipo de fraude con las debilidades que lo permiten, como en la tabla anterior. Escriban el mapa y compártanlo con ambos equipos. Cuando el equipo de fraude dice "apropiación de cuentas", ingeniería debe saber que eso significa fallas en la autenticación, las sesiones y el restablecimiento de contraseñas. Cuando ingeniería dice "fuga de información de negocio", el equipo de fraude debe saber que eso puede significar recolección de datos.

Mantengan el mapa corto: cuatro tipos de fraude y las diez u once debilidades que más importan en sus aplicaciones. Un glosario largo que nadie lee no cierra la brecha de vocabulario.

2. Incluyan a ingeniería en la evaluación del riesgo de fraude

Sumen a un ingeniero de seguridad de aplicaciones y a un tech lead a la próxima evaluación del riesgo de fraude. Pregúntenles qué sistemas manejan inicios de sesión, pagos, registros y datos de clientes, y cuáles de ellos son alcanzables desde internet. Esa lista es el punto donde se cruzan el fraude y las vulnerabilidades de seguridad. Luego, pregúntenle al equipo de fraude cuáles de esos sistemas ya muestran señales de abuso, como ráfagas de card testing o cuentas nuevas que nunca hacen transacciones. Un sistema que aparece en ambas listas va primero en el plan de remediación.

3. Midan la exposición, no los conteos

Un conteo de 35 vulnerabilidades altas abiertas le dice poco a un equipo de fraude. La severidad abierta más alta de cada categoría de fraude dice más, porque una falla crítica en un flujo de pago importa más que diez fallas bajas en otra parte. Reporten la exposición por categoría y revísenla después de cada versión. Para la dirección, la misma vista responde una pregunta simple: ¿a qué tipo de fraude está más expuesto hoy nuestro software? Así el riesgo de seguridad y fraude se convierte en una línea del reporte a la junta, en lugar de dos reportes separados.

4. Conviertan el escalamiento en una rutina

Acuerden quién recibe un escalamiento de fraude, qué contexto lleva y qué tan rápido responde ingeniería. Midan cuánto tiempo siguen abiertas las vulnerabilidades escaladas y compárenlo con el de otras vulnerabilidades de la misma severidad. Si las escaladas no se cierran más rápido, la rutina no está funcionando. Revisen las cifras con ambos equipos una vez al mes, en la misma reunión. Luego, vuelvan a probar cada corrección: un reataque confirma que la oportunidad se cerró, no solo que se cerró un ticket.

Un riesgo, una conversación

Los equipos de fraude saben a dónde va el dinero. Ingeniería sabe dónde falla el código. Ningún silo ve la falla que conecta a los dos. El riesgo de seguridad y fraude baja cuando ambos equipos miran la misma lista corta y actúan sobre ella en la misma semana. Creamos el Fraud risk center para esa conversación: muestra a los equipos de fraude qué fallas permiten el fraude y le envía a ingeniería la evidencia para corregirlas.

Preguntas frecuentes

¿Cuál es la diferencia entre el relleno de credenciales y la apropiación de cuentas?

El relleno de credenciales es una de las formas de apropiarse de cuentas. Los atacantes prueban a gran escala pares robados de usuario y contraseña en una página de inicio de sesión, y OWASP lo lista como la amenaza automatizada OAT-008. La apropiación de cuentas es el resultado: el atacante controla la cuenta de un cliente real. Hay otros caminos que llevan al mismo resultado, como el robo de sesiones o un restablecimiento de contraseña débil. Nuestra guía sobre el relleno de credenciales explica el ataque en detalle.

¿Las herramientas de detección de fraude encuentran vulnerabilidades en las aplicaciones?

No. Las herramientas de detección de fraude analizan transacciones, dispositivos y comportamiento para detener el abuso mientras ocurre. No leen código fuente ni prueban si una aplicación tiene fallas. Las pruebas de seguridad, como el análisis estático, el análisis dinámico y las pruebas de penetración, encuentran las vulnerabilidades. Los dos tipos de herramientas responden preguntas distintas, y por eso los equipos que las usan necesitan una vista compartida.

¿PCI DSS exige controles sobre los scripts de las páginas de pago?

Sí. El PCI Security Standards Council explica que los requisitos 6.4.3 y 11.6.1 del Payment Card Industry Data Security Standard (PCI DSS) v4.x buscan que los scripts de las páginas de pago estén "debidamente autorizados, verificados en su integridad y monitoreados frente a manipulaciones". El consejo también advierte que los scripts que se ejecutan en los navegadores de los consumidores "son hoy un objetivo importante para los atacantes que buscan robar datos de tarjetas de pago".

¿Todo el fraude digital se debe a vulnerabilidades de software?

No. Gran parte del fraude que la gente denuncia empieza con ingeniería social, como llamadas falsas, phishing y estafas de inversión, sin ninguna falla de software de por medio. En el 2025 IC3 Annual Report, el fraude de inversión causó las mayores pérdidas reportadas. El riesgo de seguridad y fraude cubre la parte del fraude que depende de una debilidad en tus aplicaciones. Esa es la parte que ingeniería puede eliminar.