El mito de la “seguridad por diseño”

He hablado con líderes de seguridad que creen que sus aplicaciones móviles están protegidas. No se equivocan en lo que han hecho, sino en lo que protegen.

En conversaciones recientes, he escuchado tres defensas seguras:

“Nuestro backend está diseñado correctamente”.

Implementaron la separación de preocupaciones, seguridad de API por capas y autenticación en cada paso. Siguieron el manual.

“Nuestro proveedor se encarga de eso”.

Muchas organizaciones, especialmente bancos pequeños, cooperativas de crédito y actores regionales, dependen de proveedores de aplicaciones de marca blanca. La lógica es la siguiente: este proveedor presta servicios a cientos de instituciones, así que algo debe estar haciendo bien. Y si algo sale mal, el problema es mayor que el nuestro.

“No somos un objetivo”.

Empresas manufactureras, de logística y empresas B2B se ven fuera del radio de acción. El ransomware y el robo de datos están en su punto de mira. ¿Una aplicación móvil convertida en arma? No tanto.

Cada una de estas posturas es razonable. Y todas pasan por alto lo mismo.

El ataque en el que no están pensando

Las prácticas de seguridad por diseño se centran en crear aplicaciones sin vulnerabilidades explotables: sin desbordamientos de búfer, sin credenciales codificadas y con parches CVE oportunos. Esto es un buen trabajo, pero dificulta la tarea del atacante.

Pero se supone que el atacante es outside tratando de conseguir in.

Esto es lo que falta: el ataque de la aplicación modificada.

Tu aplicación se entrega limpia. Supera todos los análisis de seguridad. Está firmada y se distribuye a través de canales oficiales. Luego, un atacante la descarga, le aplica ingeniería inversa y realiza una pequeña modificación, quizás cambiando una sola instrucción de la rama. La reempaquetan y la distribuyen a través de canales no oficiales o engañan a los usuarios para que la instalen directamente.

Ahora tienen un agente de confianza dentro de su perímetro.

Tu backend no puede notar la diferencia. Las llamadas a la API parecen legítimas. La autenticación funciona. Los patrones de tráfico son normales. Porque sigue siendo... tu aplicación—solo que con un pequeño fragmento de malware en el viaje.

Esto no es un ataque teórico. Es un documentado, vector de ataque creciente. Y pasa directamente a través de las defensas que esos líderes de seguridad me describieron.

¿Por qué persiste el punto ciego?

El pensamiento tradicional sobre seguridad crea modelos mentales difíciles de eliminar. Si has dedicado tu carrera a defender perímetros, reforzar servidores y corregir vulnerabilidades, piensas en términos de amenazas externas que intentan vulnerar tus límites.

El ataque de la aplicación modificada no traspasa tus muros. Entra por la puerta principal con tu uniforme.

Las prácticas de codificación segura no lo impiden: el código original fue Seguro. La arquitectura de backend no lo detecta: las solicitudes provienen de lo que parece ser tu aplicación legítima. Y tu proveedor no puede salvarte: está resolviendo el mismo problema que tú, a gran escala, con el mismo punto ciego.

El problema de CYA

Hay otra dinámica en juego. En algunas de mis conversaciones, percibí que los líderes de seguridad habían aceptado cierto tipo de riesgo, siempre y cuando la culpa pudiera recaer en otro.

Si tu proveedor de marca blanca sufre una vulneración de seguridad, es su problema. Eres una víctima, no la causa. Si el vector de ataque era algo contra lo que nadie en tu sector se defendía, no eres negligente, eres normal.

Esto es una preservación racional de la carrera profesional. Pero no es seguridad.

La incómoda verdad es que la frase “nadie más lo está haciendo tampoco” deja de ser una defensa en el momento en que eres tú quien explica la infracción a la junta directiva.

La pregunta que vale la pena hacer

No estoy aquí para decirle a nadie que su programa de seguridad está mal. Defensa en profundidad, codificación segura, fortalecimiento de API: todo esto es real y necesario.

Pero yo preguntaría esto: ¿Cuál es tu plan para el ataque que utiliza tu propia aplicación en tu contra?

Si la respuesta es "lo detectaríamos en el backend", me opondría. Podrías detectar anomalías con el tiempo. Pero para entonces, el daño ya está hecho: credenciales obtenidas, sesiones pirateadas, fraude cometido.

Si la respuesta es "eso no es una amenaza realista para nosotros", me preguntaría qué sustenta esa confianza. Las herramientas de ataque están mercantilizadas. Las técnicas están documentadas. Los objetivos se están expandiendo más allá de los servicios financieros.

Y si la respuesta es “eso es problema de otra persona”, simplemente preguntaría: ¿Lo es?