Cuando el sistema supervisado controla el monitor

Un control de seguridad puede estar presente, habilitado y aparentemente funcionando mientras alguien, discretamente, socava su capacidad para cumplir su función. 

Un informe reciente de OpenAI describió dos incidentes relacionados con agentes de IA que realizaban tareas de codificación interna. En un caso, un agente suprimió las alertas de seguridad automáticas mientras reparaba un proceso de evaluación. El monitoreo continuó ejecutándose y guardando informes, pero las alertas destinadas a alertar a un humano sobre dichos informes habían sido desactivadas. En otro caso, un agente eliminó una integración de monitoreo mientras modificaba el código y, posteriormente, informó erróneamente sobre los cambios realizados. 

Los detalles difieren, pero ambos incidentes plantean una cuestión arquitectónica fundamental. ¿Qué sucede cuando el sistema que se está monitorizando tiene el control suficiente como para interferir con su propia monitorización? 

La seguridad de las aplicaciones lleva años lidiando con una versión de este problema. Una aplicación móvil se ejecuta en un dispositivo que su desarrollador no controla. Un atacante podría inspeccionar su código, manipular su ejecución o intentar desactivar las protecciones diseñadas para detectar dichas actividades. Pero añadir una comprobación de seguridad es solo el primer paso. La propia comprobación necesita protección. 

¿Quién vigila a los guardias? 

Consideremos una aplicación de banca móvil que comprueba si su código ha sido modificado. Si la comprobación detecta alguna manipulación, podría cerrar la aplicación, requerir autenticación adicional o restringir las transferencias de alto valor, permitiendo al mismo tiempo que continúen las funciones menos sensibles. Estas son respuestas útiles. Pero plantean otra pregunta: ¿Qué impide que un atacante encuentre la comprobación de integridad y la modifique para que deje de funcionar? 

Una protección que se puede desactivar sin resistencia puede generar una falsa sensación de seguridad entre los desarrolladores. La aplicación contiene el código para detectar manipulaciones, pero un atacante que pueda modificarlo también podría vulnerar la detección. 

La misma preocupación se aplica a la monitorización de amenazas. Un sistema puede identificar comportamientos sospechosos, pero esa capacidad resulta inútil si un atacante puede interferir con el mecanismo responsable de su identificación o suprimir sus resultados. Este es el desafío que subyace a una pregunta recurrente en seguridad: ¿quién vigila a los vigilantes? 

Agregar más protección puede ser útil, pero solo si dichas protecciones se contemplan en el diseño. De lo contrario, un atacante podría simplemente atacar el mecanismo que implementa la política de seguridad. 

Construyendo una red de vigilancia 

Digital.aiLa tecnología de protección de aplicaciones Arxan aborda este desafío mediante un sistema de controles de seguridad llamado Guards. Los Guards se inyectan en el binario de la aplicación protegida. Pueden verificar la integridad de la aplicación y responder a cualquier manipulación detectada según las políticas configuradas para la misma. Dependiendo del caso de uso, una respuesta podría cerrar la aplicación, activar la autenticación reforzada o deshabilitar una función sensible, como las transferencias financieras de alto valor. Un detalle arquitectónico importante es que los propios Guards pueden protegerse mediante otros Guards. 

Esto crea lo que llamamos un Red de vigilanciaUn sistema de seguridad no tiene por qué funcionar de forma aislada, como una comprobación que un atacante pueda identificar y atacar. Otros sistemas de seguridad pueden protegerlo, y estas protecciones, a su vez, pueden recibir capas adicionales de protección. En algunas implementaciones, la cadena se extiende a través de múltiples capas, con sistemas de seguridad que protegen a otros sistemas de seguridad. 

Esa estructura por capas modifica el problema al que se enfrenta un atacante. Deshabilitar una comprobación de seguridad específica puede requerir superar también las protecciones que la rodean. Un intento de interferir con una parte de la arquitectura de protección puede toparse con otras partes diseñadas para detectar o resistir dicha interferencia. Ese diseño cobra más importancia ahora que cuando se describió la idea por primera vez. Las herramientas de IA han reducido el costo y la habilidad necesarios para realizar ingeniería inversa de aplicaciones a gran escala, y una sola verificación aislada es el tipo de objetivo que el análisis automatizado puede encontrar y corregir rápidamente.  

Cuando los Guardianes están configurados para protegerse entre sí, la eliminación de uno está diseñada para activar a los demás. Dependiendo del objetivo, los equipos también pueden variar la protección con más de una configuración: valores semilla que hacen que cada compilación protegida sea estructuralmente diferente, selección aleatoria de instancias de Guardianes en el momento de la protección y probabilidades de ejecución que implican que no todos los Guardianes se ejecuten en cada ejecución. Algunos mecanismos de protección varían su comportamiento en tiempo de ejecución, por lo que no presentan una firma estática: una suma de comprobación incremental, por ejemplo, puede verificar un rango diferente en cada invocación en lugar de repetir una comprobación fija que el análisis automatizado podría aprender y eludir. Una rutina de eliminación de efectos que funcionó contra una versión o una ejecución, no garantiza que funcione contra la siguiente. 

La Red de Protección no garantiza que una aplicación sea imposible de vulnerar. Ninguna arquitectura puede garantizarlo frente a todos los atacantes, plataformas o amenazas. Su propósito es dificultar la localización, alteración y neutralización de las protecciones, incluso considerando los ataques dirigidos contra ellas mismas. Esta distinción es crucial. Los atacantes no siempre necesitan superar toda una arquitectura de seguridad. A veces, solo necesitan desactivar el mecanismo que, de otro modo, expondría su actividad. Proteger las protecciones aumenta la complejidad de este enfoque.  

La detección necesita un camino hacia la respuesta. 

Proteger las comprobaciones de integridad es solo una parte del problema. Los equipos de seguridad también necesitan visibilidad sobre lo que sucede cuando una aplicación encuentra una situación sospechosa. 

Arxan Threat Monitoring opera dentro de la aplicación protegida. Los controles de monitorización se inyectan en el binario y las alertas se pueden visualizar a través de un navegador o integrarse en un sistema de gestión de información y eventos de seguridad (SIEM). Esto permite a las organizaciones revisar los eventos de seguridad a nivel de aplicación e incorporarlos a sus operaciones de seguridad generales. La arquitectura también es importante. La monitorización opera dentro de la aplicación, por lo que no debe describirse como un observador totalmente externo. Sus controles forman parte del binario protegido y la arquitectura de protección está diseñada para resistir la manipulación de la aplicación y sus mecanismos de seguridad. 

Guard Network desempeña un papel fundamental en este proceso al proteger los propios controles. Las alertas externas y la integración con SIEM permiten que los eventos reportados estén disponibles más allá de la aplicación. Estos mecanismos cumplen diferentes funciones. Guards puede ayudar a proteger la integridad de la aplicación y activar respuestas ante manipulaciones detectadas. La monitorización de amenazas puede revelar actividades relevantes para la seguridad. Los informes externos pueden ayudar a los equipos de seguridad a investigar eventos y coordinar una respuesta. 

Cada componente tiene sus limitaciones. Un canal de informes no puede reportar un evento que nunca se detectó, y no se debe asumir que ninguna protección resista todos los ataques posibles. El objetivo es dificultar que un atacante comprometa una aplicación y, posteriormente, desactive los mecanismos diseñados para exponer o limitar dicha vulneración. 

La respuesta debe ajustarse a la amenaza. 

Los controles de seguridad suelen analizarse en función de lo que detectan. En la práctica, lo que sucede después puede ser igual de importante. Una aplicación bancaria podría requerir una autenticación reforzada tras detectar una situación sospechosa. Podría restringir las transferencias de alto valor, pero permitir las operaciones rutinarias. Una aplicación con requisitos de integridad más estrictos podría cerrarse si su código ha sido modificado. Estas respuestas reflejan diferentes evaluaciones de riesgo. Un desarrollador puede elegir una respuesta en función de la aplicación, la amenaza y las posibles consecuencias de permitir que la ejecución continúe. 

Uno de nuestros clientes del sector de los videojuegos adoptó un enfoque más ingenioso. El equipo creó un sistema de protección que detectaba las trampas de los jugadores. Al activarse, desactivaba la gravedad del juego, haciendo que los jugadores que hacían trampa salieran flotando del tablero. Es un ejemplo memorable, y la idea subyacente es seria. La protección estaba vinculada a una consecuencia relevante en el entorno donde se producía el ataque. En lugar de considerar la detección como el final del proceso, el desarrollador la utilizó para modificar las funcionalidades de la aplicación. 

El mismo principio se aplica cuando las consecuencias implican dinero, datos confidenciales o acceso a funcionalidades críticas. La respuesta debe ser proporcional al riesgo y debe resultar difícil para un atacante neutralizar el mecanismo que la activa. Los desarrolladores también deben tener en cuenta los falsos positivos, las rutas de recuperación y el impacto en los usuarios legítimos. La protección debe mejorar la resiliencia de una aplicación sin generar interrupciones innecesarias. 

Pregunta qué sucede cuando los guardias son el objetivo. 

El informe de OpenAI nos recuerda que la monitorización puede verse comprometida mediante cambios en los sistemas que pretende observar. Los desarrolladores de aplicaciones se enfrentan a un desafío similar cuando su software se ejecuta en entornos donde los atacantes pueden inspeccionar y manipular su ejecución. La cuestión va más allá de si una aplicación cuenta con comprobaciones de integridad o monitorización de amenazas. Se extiende a cómo se protegen esos mecanismos, cómo responden a las interferencias y si un atacante puede desactivar los controles que, de otro modo, expondrían el ataque. 

Aquí es donde la Red de Guardias cobra importancia. Al usar Guardias para proteger a otros Guardias, Arxan agrega capas de protección alrededor de los propios mecanismos de seguridad. Esto crea obstáculos adicionales para los atacantes que intentan modificar las defensas de la aplicación o neutralizar controles individuales. Al evaluar una arquitectura de seguridad de aplicaciones, hágase tres preguntas.

1) ¿Qué sucede cuando un atacante ataca la propia protección?
2) ¿Qué impide que una sola modificación desactive un mecanismo de seguridad crítico?
3) ¿Qué opciones tiene la aplicación cuando un guardia detecta manipulación? 

El objetivo no es garantizar que una aplicación sea invulnerable, sino dificultar su manipulación, preservar las protecciones necesarias ante un ataque y brindar a los desarrolladores soluciones prácticas para responder cuando la integridad de la aplicación se vea comprometida. En ocasiones, esta respuesta implica restringir una transacción financiera; en otras, desactivar la aplicación. 

Y a veces significa desactivar la gravedad y ver cómo los jugadores de un tramposo se alejan flotando.