A pesar de toda la atención prestada a las amenazas avanzadas y a los ataques impulsados por la IA, muchas infracciones exitosas todavía dependen de técnicas que existen desde hace décadas.
La inyección SQL se ha estudiado y debatido durante más de 20 años; sin embargo, más del 20 % de las organizaciones siguen siendo vulnerables cuando se evalúan por primera vez, y la tecnología sigue representando una parte importante de las vulnerabilidades modernas.
Vicepresidente de Producto en Wallarm.
Los scripts entre sitios (XSS) son otro ejemplo de larga data. Permite a los atacantes inyectar scripts maliciosos en aplicaciones web, lo que permite el robo de datos, el secuestro de sesiones y acciones no autorizadas en nombre de usuarios legítimos.
La técnica ha persistido desde finales de la década de 1990 y continúa apareciendo en aplicaciones modernas, incluidas aquellas creadas en marcos que afirman mitigarla de forma predeterminada.
Si la industria ha pasado tanto tiempo lidiando con ataques de décadas de antigüedad, ¿por qué siguen teniendo éxito? La respuesta tiene menos que ver con la conciencia y más con cómo se crean y mantienen los entornos tecnológicos modernos.
La tecnología no se reemplaza a sí misma
La tecnología no se reemplaza a sí misma en ciclos limpios. Los nuevos sistemas se superponen a los existentes y el código antiguo permanece para respaldar las operaciones comerciales. Con el tiempo, esto crea entornos que son más complejos y difíciles de proteger por completo.
Las organizaciones continúan creando API, adoptando microservicios e integrando herramientas de inteligencia artificial en sus sistemas. Estos cambios respaldan el crecimiento y mejoran el rendimiento, pero también aumentan la exposición.
Cada nueva capa introduce conexiones, dependencias y posibles puntos de falla adicionales. Las vulnerabilidades antiguas rara vez se eliminan en este proceso. Son heredados.
Por eso las estrategias de ataque a largo plazo son efectivas. Los atacantes no necesitan métodos sofisticados, mientras que los métodos simples siguen funcionando.
Las brechas en la propiedad crean riesgos reales
Existe una desconexión entre cómo se perciben las responsabilidades de seguridad y cómo se implementan. Los desarrolladores esperan que los controles de seguridad detecten problemas más adelante. Los equipos de seguridad asumen que ya existen prácticas de codificación segura. Ambas suposiciones crean brechas.
Las API ilustran claramente el problema. Algunos se desarrollan internamente, mientras que otros se ensamblan a partir de terceros. Los equipos de seguridad de aplicaciones se centran en activos desarrollados internamente, mientras que los equipos de gestión de vulnerabilidades suelen considerar que las API están fuera de su alcance.
El resultado es que algunas API nunca se evalúan por completo ni se monitorean de manera consistente, y las clases de vulnerabilidades conocidas permanecen en ellas mucho después de que la industria las considera resueltas.
La superficie de ataque de la IA son en su mayoría problemas antiguos en envases nuevos
Gran parte de la conversación sobre la seguridad de la IA se centra en los riesgos específicos del modelo: inyección rápida, jailbreak, envenenamiento de datos de entrenamiento y robo de modelos. Estos riesgos son reales y vale la pena abordarlos. Éstas son sólo una pequeña parte de la superficie de ataque real que introduce una implementación de IA.
Un sistema de IA de fabricación es una aplicación distribuida.
Incluye API de inferencia que aceptan entradas del usuario y devuelven resultados del modelo, canales de recuperación que extraen de bases de datos vectoriales y almacenes de datos tradicionales, marcos de agentes que llaman a herramientas y servicios externos, capas de identidad y autorización que acceden a capacidades y una cadena de suministro de modelos, bibliotecas y conjuntos de datos disponibles de terceros.
Cada uno de estos componentes se construye a partir de patrones arquitectónicos que son anteriores a la IA generativa en años o décadas.
Esto significa que la superficie de ataque de la IA expone las mismas clases de vulnerabilidades con las que los profesionales siempre han luchado. Los puntos finales de inferencia son API y heredan los mismos problemas de autenticación, autorización, limitación de velocidad y validación de entradas que tiene el resto del ecosistema API.
Bases de datos de consultas de canalización de generación mejorada de recuperación, lo que significa que aún se aplican fallas de inyección SQL y control de acceso. Las herramientas de agentes ejecutan solicitudes contra sistemas internos y externos, lo que reintroduce la falsificación de solicitudes del lado del servidor y la inyección de comandos en nuevos contextos.
El riesgo de la cadena de suministro en los registros de modelos y los paquetes de dependencia refleja el riesgo en cualquier otra cadena de suministro de software.
Los equipos que se centran exclusivamente en amenazas novedosas específicas de la IA dejan vulnerables superficies más grandes y familiares. Si la API de inferencia rompe la autorización a nivel de objeto o una política CORS mal configurada, el atacante no necesita crear una inyección de aviso inteligente. El camino de menor resistencia todavía pasa por los fundamentos.
Aquí también se agrava el problema de la velocidad. Las funciones de IA se entregan en plazos estrictos y la superficie de API se expande más rápido de lo que evalúan los equipos de seguridad. Cada nuevo punto final hereda la postura de seguridad API existente de la organización, incluidas las lagunas que ya existen.
La seguridad es una decisión empresarial.
La priorización de la seguridad requiere traducir las vulnerabilidades técnicas en impacto empresarial. Un hallazgo de inyección SQL se entiende en términos generales como una clase, pero su importancia depende de los datos que expone y de cómo se accede a ellos. Excepto en ese contexto, la prioridad predeterminada es lo que sea ruidoso, que suele ser lo que sea nuevo.
Así es como las organizaciones sobreestiman su protección contra amenazas fundamentales. Tienen herramientas que abordan vulnerabilidades conocidas en el alcance o la revisión del código, pero la cobertura falla en los bordes, especialmente en las API y los componentes de IA que no se asignan claramente a los modelos de seguridad de aplicaciones tradicionales.
Los viejos riesgos no desaparecen
No se necesita ningún nuevo enfoque para solucionar este problema. Las prácticas de seguridad establecidas todavía funcionan. La dificultad es aplicarlas de manera consistente en un entorno que evoluciona y se reconstruye, y garantizar que las antiguas clases de vulnerabilidad no se vean privadas cuando se introducen nuevas tecnologías.
Tres tareas son las más importantes. Defina la propiedad de cada API y componente de IA, interno o de terceros, para que ningún activo quede entre los equipos. Pruebe las implementaciones de IA utilizando los protocolos de seguridad API y de aplicaciones existentes antes de agregar herramientas específicas de IA.
y medir la exposición en función de lo que es alcanzable y explotable, no de si una clase de vulnerabilidad se considera nueva o antigua.
El éxito constante de ataques de décadas de antigüedad no es una falta de conocimiento. Esta es una brecha prioritaria. Los equipos de seguridad que equilibren la atención entre las nuevas amenazas y los fundamentos no abordados reducirán la exposición de manera más efectiva que perseguir cualquier riesgo que actualmente aparece en los titulares.
Hemos presentado el mejor software de seguridad para terminales
Este artículo fue producido en parte Perspectiva profesional de TechRadarNuestro canal para mostrar las mejores y más brillantes mentes de la industria tecnológica actual.
Las opiniones expresadas aquí son las del autor y no necesariamente las de TechRadarPro o Future plc. Si está interesado en contribuir, obtenga más información aquí:
