Contáctenos

La seguridad de la IA no está rota, solo estamos defendiendo lo equivocado

Líderes del pensamiento

La seguridad de la IA no está rota, solo estamos defendiendo lo equivocado

mm

La industria de la ciberseguridad tiene un patrón: cuando surge una nueva tecnología, inmediatamente empezamos a construir barreras a su alrededor. Lo hicimos con la nube, con los contenedores y ahora con la IA, solo que esta vez, las barreras que construimos están en los lugares equivocados.

Si hoy asiste a cualquier revisión de seguridad empresarial, escuchará las mismas prioridades: proteger los modelos de IA, protección de los datos de entrenamiento, validando resultados e implementando copilotos basados ​​en IA. Los proveedores se apresuran a vender herramientas de "seguridad de IA" que se centran exclusivamente en controles a nivel de modelo, como barandillas, defensas de inyección rápida y plataformas de monitorización de modelos.

Pero los atacantes están utilizando sus integraciones de IA como vías de acceso a todo lo demás.

La verdadera superficie de ataque que nadie está mirando

Un patrón que observamos constantemente en entornos empresariales revela una historia preocupante: los equipos de seguridad invierten fuertemente en la seguridad de sus entornos de desarrollo de IA: controles de acceso a modelos, marcos de gobernanza de datos y herramientas de seguridad MLOps. Esto genera una falsa confianza de que su IA está "protegida".

Pero al mapear la superficie de ataque real, se observa que los chatbots de IA suelen tener tokens OAuth para docenas de plataformas SaaS, claves API con permisos excesivos en la nube y relaciones de confianza de identidad que pueden crear rutas directas desde una simple inyección de aviso a la infraestructura de producción. Los modelos en sí mismos pueden ser seguros, pero los ecosistemas en los que se desarrollan suelen estar completamente abiertos, y este no es un caso excepcional.

Las empresas utilizan actualmente un promedio de más de 130 aplicaciones SaaS, con integraciones de IA que abarcan proveedores de identidad, infraestructura en la nube, bases de datos y sistemas críticos para el negocio. Cada integración representa una posible ruta de ataque, y cada conexión API representa un límite de confianza que los atacantes investigan activamente.

El problema no es que nuestras herramientas de seguridad de IA sean defectuosas. Es que estamos protegiendo componentes individuales mientras los atacantes explotan las conexiones entre ellos.

Por qué la seguridad centrada en modelos no es lo importante

El enfoque actual de la seguridad de la IA se basa en una incomprensión fundamental de cómo funcionan los ataques modernos. Tratamos la IA como un activo independiente que necesita protección, de forma similar a cómo protegeríamos una base de datos o una aplicación web. Pero la IA en producción no existe de forma aislada. Es un nodo en un complejo grafo de identidades, permisos, API y flujos de datos.

Considere una implementación típica de IA empresarial. Tiene un agente de IA con acceso a su Google Workspace. Está conectado a Salesforce mediante API. Está integrado con Slack para notificaciones. Extrae datos de buckets de AWS S3. Se autentica mediante Okta o Azure AD. Activa flujos de trabajo en ServiceNow.

La seguridad tradicional de la IA se centra en el modelo en sí: su postura de seguridad, la validación inmediata y la seguridad de los resultados. Pero los atacantes se centran en las integraciones: a qué pueden acceder mediante cuentas de servicio comprometidas, dónde pueden acceder mediante manipulaciones de API y qué límites de confianza pueden traspasar mediante integraciones explotadas.

El ataque no empieza ni termina con el modelo de IA. El modelo es solo el punto de entrada.

Las rutas de ataque no respetan los límites del producto

Aquí es donde la mayoría de las organizaciones se atascan. Han implementado herramientas de seguridad que proporcionan visibilidad en un solo dominio. Una herramienta supervisa los permisos en la nube. Otra rastrea las configuraciones de SaaS. Una tercera gestiona la gobernanza de identidades. Una cuarta se encarga de la gestión de vulnerabilidades.

Cada herramienta te muestra su pieza del rompecabezas. Ninguna te muestra cómo se conectan las piezas.

De acuerdo con GartnerLas organizaciones utilizan actualmente un promedio de más de 45 herramientas de seguridad. Sin embargo, a pesar de esta enorme inversión, los atacantes están encadenando con éxito configuraciones erróneas en estos dominios, ya que ninguna herramienta puede ver la ruta de ataque completa por sí sola.

Un atacante no necesita encontrar una vulnerabilidad crítica en su modelo de IA. Solo necesita encontrar una cadena. Quizás se trate de una función de IAM mal configurada asociada a su servicio de IA, que tiene permisos para un bucket de S3 y que contiene credenciales para una aplicación SaaS con acceso de administrador a su entorno de producción.

Cada configuración incorrecta individual podría tener una puntuación "media" o "baja" en tus herramientas de seguridad. ¿Pero encadenadas? Eso representa una exposición crítica. Y es completamente invisible si analizas cada dominio de seguridad de forma aislada.

El imperativo de la gestión de la exposición

Es por esto que la conversación debe pasar de la “seguridad de la IA” a la gestión continua de la exposición a amenazas para entornos integrados con IA.

No basta con preguntarse si nuestros modelos de IA son seguros. Los equipos de seguridad necesitan comprender qué puede alcanzar realmente un atacante si compromete una cuenta de servicio de IA. Necesitan visibilidad sobre cómo se pueden encadenar las configuraciones incorrectas en la nube, SaaS y sistemas de identidad. Necesitan saber cómo las integraciones de IA están cambiando su superficie de ataque en tiempo real. Y necesitan priorizar los riesgos basándose en la atacabilidad real, no solo en las puntuaciones de gravedad.

La mayoría de los programas de seguridad todavía priorizan los riesgos de forma aislada, utilizando puntuaciones CVSS y listas de verificación de cumplimiento que ignoran por completo si una vulnerabilidad es realmente explotable en su entorno específico.

Esta brecha es aún más pronunciada en los sistemas de IA, ya que cambian constantemente. Se añaden nuevas integraciones cada semana. Los permisos evolucionan. Las conexiones API cambian. La superficie de ataque del mes pasado no es la misma que la de hoy, pero su evaluación de seguridad probablemente sí lo sea.

Cómo se ve realmente la seguridad consciente de la ruta de ataque

Asegurar la IA en la producción requiere un enfoque fundamentalmente diferente, y se reduce a cuatro cambios clave en el pensamiento.

En primer lugar, necesita una visibilidad unificada en todos los dominios de seguridad. Deje de exigir que cada herramienta de seguridad opere aisladamente. Sus herramientas de seguridad en la nube, gobernanza de identidades, gestión de SaaS y análisis de vulnerabilidades contienen piezas clave del rompecabezas de la ruta de ataque. Necesitan compartir datos en tiempo real para que pueda ver cómo se encadenan las configuraciones incorrectas.

En segundo lugar, adopte la simulación continua de rutas de ataque. No espere a que las pruebas de penetración o los ejercicios de equipo rojo descubran rutas explotables. Pruebe continuamente cómo un atacante podría moverse por su entorno, centrándose en la explotabilidad real en lugar de basarse en puntuaciones de gravedad teóricas.

En tercer lugar, priorice según el contexto. Un bucket de S3 mal configurado no es crítico solo por ser público. Es crítico si es público y contiene credenciales con acceso privilegiado, además de ser accesible desde un recurso expuesto a internet. El contexto importa más que cualquier puntuación individual.

En cuarto lugar, avance hacia la remediación preventiva. Para cuando su equipo del SOC esté investigando una alerta, ya habrá perdido un valioso tiempo de respuesta. La defensa moderna requiere la capacidad de cerrar las rutas explotables antes de que se conviertan en armas, no después de un incidente.

La advertencia que no podemos ignorar

A medida que la IA se integra en todas las capas de la infraestructura empresarial, la superficie de ataque se expande a una velocidad que los equipos de seguridad no pueden calcular manualmente. Estamos añadiendo integraciones de IA a un ritmo diez veces superior al que las protegemos.

Si protege la IA de forma aislada, protegiendo el modelo e ignorando el ecosistema en el que opera, ya está perdiendo terreno. Los atacantes no piensan en herramientas, sino en rutas. No explotan vulnerabilidades individuales. Encadenan configuraciones erróneas en todo el entorno.

Las empresas que lograrán proteger la IA no serán las que cuenten con más herramientas de seguridad. Serán las que comprendan que la seguridad de la IA es inseparable de la gestión de la exposición en toda su superficie de ataque.

La seguridad del modelo es fundamental. Lo importante es comprender el alcance que un atacante puede alcanzar al comprometer una integración de IA. Hasta que los equipos de seguridad puedan responder a esta pregunta de forma continua, en tiempo real y en todo su entorno, no estarán protegiendo la IA. Solo esperan que las barreras que han construido estén en el lugar correcto.

Piyush Sharma, cofundador y director ejecutivo de TuskiraPiyush cuenta con más de dos décadas de experiencia en ciberseguridad, respaldada por una licenciatura en Informática y un MBA. Emprendedor en serie con dos salidas exitosas, ha ocupado importantes puestos de liderazgo empresarial y de producto, incluyendo en Symantec y Tenable. También fue director ejecutivo y cofundador de Accurics, empresa posteriormente adquirida por Tenable Inc. Inventor consumado, Piyush posee una docena de patentes en ciberseguridad, lo que demuestra sus innovadoras contribuciones al campo.