Modelado de amenazas para sistemas de IA
Qué activos nuevos aparecen en un sistema de IA, cómo se rompe su cadena de suministro de datos, dónde se queda corto STRIDE y cómo combinar STRIDE, MITRE ATLAS y OWASP LLM Top 10 como tres capas de un mismo análisis.
Modelar una aplicación clásica es inventariar lo que vale (base de datos, código, configuración, claves, credenciales), dónde vive y cómo se protege. Con IA ese inventario se alarga, el sistema se comporta de otra manera y el marco habitual, STRIDE, deja huecos. La nota recorre esas cuatro diferencias y termina uniendo tres marcos en un solo flujo de trabajo. El ejemplo sigue siendo Citas y su asistente (el mapa de componentes está en la nota de anatomía).
Activos nuevos#
Además de lo de siempre, un sistema de IA tiene cosas que robar o corromper que no existen en una app convencional:
| Activo | Qué es | Por qué importa |
|---|---|---|
| Datos de entrenamiento | Los ejemplos con los que el modelo aprendió a comportarse. | Envenenarlos corrompe el modelo en origen. A diferencia de una base de datos comprometida, el daño queda dentro del modelo. |
| Pesos del modelo | Los números que codifican lo aprendido. Son el modelo. | Robarlos entrega una copia funcional de meses de cómputo y, a veces, de millones de inversión. |
| Embeddings | Representaciones numéricas de texto o datos, usadas en RAG, recomendación o detección de fraude. | Manipularlos cambia qué información “ve” el modelo en el momento de la consulta. |
| System prompt | Instrucciones que fijan comportamiento, límites y personalidad. | Filtrarlo enseña tus controles y tu lógica de negocio: es el mapa para esquivarlos. |
| Feature store | Repositorio de datos ya procesados que alimenta al modelo en tiempo real. | Alterar las características cambia lo que el modelo percibe sin tocar el modelo. |
| Registro de modelos | Versiones entrenadas listas para desplegar. | Si cae, alguien puede cambiar un modelo legítimo por uno con puerta trasera y nadie lo nota. |
Dos propiedades del comportamiento, además, condicionan cómo analizas todo lo demás:
- No determinismo. El mismo prompt puede dar respuestas distintas. Probar, auditar y reproducir un incidente cuesta mucho más que con código determinista.
- Caja negra. No puedes seguir el razonamiento de una red neuronal como sigues una ruta de código. Razonas sobre entradas, salidas y modos de fallo, no sobre líneas.
En conjunto: un sistema de IA no es “una app normal con un modelo pegado”. Tiene otros activos, otro comportamiento y otras formas de fallar, y el modelo de amenazas debe recogerlas.
La cadena de suministro de datos#
Una app clásica tiene su cadena de suministro de software: dependencias, librerías, imágenes de contenedor (nota). Un sistema de IA hereda todo eso y suma una segunda cadena, la de los datos, con cinco eslabones:
| Etapa | Qué ocurre | Cómo se ataca |
|---|---|---|
| 1. Recolección | Se reúnen datos de scraping, datasets comprados, bases internas, contenido de usuarios y terceros. | Quien pueda contribuir o influir en una fuente tiene un punto de apoyo. |
| 2. Limpieza y etiquetado | Se filtra y se etiqueta, a veces con equipos externos o herramientas automáticas. En fraude, las etiquetas salen implícitas de los resultados (contracargos, investigaciones). | Etiquetas manipuladas enseñan asociaciones erróneas. Un dataset mal etiquetado no parece corrupto: solo toma malas decisiones. |
| 3. Entrenamiento | El modelo aprende patrones durante días o semanas. | Cualquier veneno que sobreviviera queda en los pesos. No se parchea como una librería: puede exigir reentrenar desde cero. |
| 4. Validación y empaquetado | Se evalúa, se versiona y se guarda en el registro. | Con acceso al registro se sustituye el modelo por uno con puerta trasera. Supera la validación porque los disparadores no están en el conjunto de prueba. |
| 5. Inferencia | El modelo sirve predicciones. En un LLM suele añadirse recuperación de contexto desde bases vectoriales o documentos. | La recuperación es otro punto de inyección que no existe en software tradicional. |
Paso 1 de 6Recolección
Los datos llegan de muchas fuentes: scraping, datasets comprados, bases internas, contenido de usuarios. Cada fuente que alguien más pueda influir es una puerta.
La diferencia de fondo con una dependencia comprometida es el tiempo. Un paquete malicioso se detecta y se revierte en horas. Un dataset envenenado puede no mostrar efectos hasta semanas o meses después, cuando ya se reentrenó, validó y desplegó.
Dónde STRIDE se queda corto#
STRIDE sigue siendo un buen punto de partida, pero aplicado sin adaptar tiene huecos documentados:
- La integridad del entrenamiento no es de primera clase. Tampering cubre datos en tránsito o en reposo. Manipular el conjunto de entrenamiento es distinto: el efecto es difuso, diferido y casi invisible.
- La manipulación adversaria del comportamiento cruza categorías. Crear entradas que hagan fallar a un modelo, alucinar o saltarse las salvaguardas es en parte Tampering, en parte Spoofing y en parte Elevation of Privilege según el contexto.
- El alcance del “privilegio” se ha ampliado. Si el modelo navega, ejecuta código, envía correos o consulta bases de datos, un jailbreak con herramientas no es una escalada clásica: todos los permisos de las herramientas pasan a ser capacidades del atacante (agencia excesivaAgencia excesivaRiesgo de dar a un agente LLM más capacidad, permisos o autonomía de la que necesita, de modo que un fallo o un abuso causa daño real.).
- Robar un modelo no es robar una base de datos. Extraer los pesos a base de consultas a la API es técnicamente Information Disclosure, pero lo que se pierde es la capacidad de IA entera de la organización (extracción de modelo).
Y hay amenazas que no encajan en ninguna letra:
- Ejemplos adversarios: entradas diseñadas para provocar una clasificación errónea.
- Sesgo y equidad: tienen implicaciones regulatorias, pero un modelo sesgado no está siendo “atacado”; falla de una forma que STRIDE no describe.
- Comportamientos emergentes: capacidades que nadie entrenó ni anticipó. No se puede modelar lo que nadie predijo que existiría.
STRIDE adaptado a IA#
La tabla recoge cómo se manifiesta cada categoría, con ejemplos sobre el asistente de Citas:
| STRIDE | Manifestación principal en IA | Otras amenazas de IA | Ejemplo en Citas |
|---|---|---|---|
| Spoofing | Suplantar una fuente de datos (inyección en RAG). | Suplantar el modelo, ataques sobre identidad. | Documentos de “política” falsos en la base de conocimiento del asistente. |
| Tampering | Envenenamiento de datos. | Manipular el modelo, inyección de prompt, alterar características. | Reservas fabricadas que desplazan la frontera de decisión del modelo antifraude. |
| Repudiation | Falta de rastro de las decisiones del modelo. | Contexto volátil, ambigüedad sobre la versión del modelo. | Nadie puede explicar por qué se aprobó una reserva sospechosa. |
| Information disclosure | Extracción o robo del modelo. | Extracción de datos de entrenamiento, fuga del prompt, inversión de embeddings. | Un competidor reconstruye el motor de recomendación a base de consultas. |
| Denial of service | Abuso de coste de inferencia (denial of wallet). | Agotar GPU, sponge examples, interrumpir el pipeline. | Inundan la API con prompts caros y la factura se multiplica. |
| Elevation of privilege | Jailbreak o salto de guardrails. | Agencia excesiva, abuso de herramientas, escalada entre plugins. | Un asistente liberado se usa para consultar datos personales vía sus herramientas. |
MITRE ATLAS: el “cómo” de cada amenaza#
Los huecos de STRIDE se cubren con un catálogo específico de IA. La nota de agentes y MCP presenta ATLASMITRE ATLASBase de conocimiento estilo ATT&CK de tácticas y técnicas de adversarios contra sistemas de IA/ML, mantenida por MITRE. y sus tácticas propias; aquí interesa cómo encaja en el análisis. Reutiliza la jerarquía de ATT&CK:
| Nivel | Responde a | Ejemplo |
|---|---|---|
| Táctica | Por qué: el objetivo del adversario | Preparación del ataque (AI Attack Staging) |
| Técnica | Cómo: el método | Envenenar datos de entrenamiento (AML.T0020) |
| Sub-técnica | Una variante concreta del método | Inyección de prompt directa (AML.T0051.000) o indirecta (AML.T0051.001) |
| Mitigación | Qué lo frena | Validación de entradas, trazabilidad de procedencia |
Cinco técnicas que conviene reconocer a primera vista, cada una ligada a una de las adaptaciones de STRIDE:
| Técnica | ID | Qué es | STRIDE |
|---|---|---|---|
| Poison Training Data | AML.T0020 |
Inyectar datos maliciosos en el pipeline de entrenamiento. Efecto diferido, persiste hasta reentrenar con datos limpios. | Tampering |
| Exfiltration via ML Inference API (sub-técnica Extract ML Model) | AML.T0024 |
Consultar sistemáticamente la API para reconstruir una copia funcional. No exige acceso interno, solo el endpoint público. | Information disclosure |
| Evade ML Model | AML.T0015 |
Crear datos adversarios para que el modelo no identifique bien la entrada: evadir un detector de malware, un filtro de contenido, etc. | Tampering, Spoofing y Elevation of privilege |
| LLM Prompt Injection | AML.T0051 |
Manipular al LLM con instrucciones en la entrada del usuario (directa) o en contenido que procesa (indirecta, p. ej. documentos del RAG). | Tampering |
| Backdoor ML Model | AML.T0018 |
Incrustar un disparador oculto durante el entrenamiento. Con entradas normales se comporta bien; con el patrón, actúa de forma maliciosa. Una bomba lógica dentro de una red neuronal. | Tampering |
OWASP LLM Top 10: dónde vive cada riesgo#
La lista OWASP ya se ha explicado categoría por categoría. Su segundo uso es cruzarla con tu arquitectura, en las dos direcciones:
- Riesgo → componente: “¿dónde vive la inyección de prompt?” En el endpoint de inferencia y en el RAG; ahí van la validación de entradas y la separación de instrucciones y datos.
- Componente → riesgo: “vamos a desplegar una base vectorial, ¿qué hereda?” Aparece en LLM01 (inyección indirecta), LLM08 (debilidades de embeddings) y LLM09 (desinformación por fuentes obsoletas). Ese es el alcance de su evaluación.
La segunda dirección es la útil en el día a día: cada vez que se añade un componente, sabes qué riesgos entran con él.
| Componente | Riesgos que concentra |
|---|---|
| Endpoint de inferencia | LLM01, LLM02, LLM05, LLM06, LLM07, LLM09, LLM10 (siete de diez) |
| Base vectorial / pipeline RAG | LLM01, LLM08, LLM09 |
| Pipeline de entrenamiento | LLM02, LLM03, LLM04, y LLM10 si le inyectan datos basura |
| Registro de modelos | LLM03 (modelos de repositorios externos), LLM04 (sustitución) |
| Feature store | LLM04 |
| Integraciones de herramientas y plugins | LLM03 (dependencias), LLM06 (permisos y autonomía) |
| API gateway | LLM05, LLM06, LLM10 (límites de tasa insuficientes) |
| Frontend web | LLM05 (salida sin sanear → XSS) |
| Configuración del system prompt | LLM02, LLM07 (secretos en el prompt en vez de en un gestor) |
Para qué endurecer en cada uno de los tres grandes:
- Endpoint de inferencia: es el que más pide. Validación de entrada y salida, límites de consumo, herramientas acotadas y ningún secreto en el prompt.
- RAG: validar lo que se indexa, controlar el acceso al almacén vectorial y vigilar la frescura de las fuentes.
- Pipeline de entrenamiento: es por donde entran modelos y datasets de terceros, así que ahí pesa la procedencia y la verificación de integridad.
Las tres capas juntas#
STRIDE, ATLAS y OWASP no compiten: son niveles de zoom del mismo análisis.
| Capa | Qué aporta | Cuándo la usas |
|---|---|---|
| STRIDE-AI | Clasifica la amenaza por tipo | Identificación inicial: ¿qué puede salir mal? |
| MITRE ATLAS | Documenta la técnica concreta | Enriquecimiento: ¿cómo lo haría un atacante? |
| OWASP LLM Top 10 | Sitúa el riesgo en un componente y lo prioriza | Alcance y evaluación: ¿dónde vive y cuánto pesa? |
El flujo, en orden:
- STRIDE: recorre cada componente del sistema con las seis categorías y anota qué puede salir mal.
- ATLAS: para cada amenaza, busca la técnica correspondiente. Obtienes métodos de ataque documentados y casos reales.
- OWASP: ubica cada riesgo en el componente que lo aloja y prioriza por concentración. El endpoint y el pipeline de entrenamiento suelen salir arriba.
- Mitigaciones: toma las de ATLAS y OWASP como punto de partida y asígnalas a cada componente.
Tu turno
Tres capas sobre tu propio sistema
Con un sistema de IA que conozcas (aunque sea un RAG de laboratorio), haz una tabla con una fila por componente:
| Componente | Amenaza STRIDE | Técnica ATLAS | Riesgo OWASP | Mitigación |
|---|---|---|---|---|
| … | … | … | … | … |
Después responde: ¿qué eslabón de tu cadena de datos (recolección, etiquetado, entrenamiento, registro) controlas tú y cuál viene de un tercero?
Reto
Un modelo pasa todas las pruebas de validación y, aun así, se comporta mal con cierta entrada en producción. ¿Qué técnica sospechas y por qué no la vio la validación?
▸Mostrar solución
Una puerta trasera (Backdoor ML Model, AML.T0018), ya sea sembrada en el entrenamiento o
introducida cambiando el modelo en el registro. La validación mide comportamiento sobre un
conjunto de prueba, y ese conjunto no contiene el disparador: con entradas normales el modelo
es correcto. La defensa pasa por procedencia y firma de los modelos, controles de acceso al
registro y pruebas adversarias que busquen disparadores, no solo precisión media.
Reto
¿Por qué un paquete npm comprometido y un dataset envenenado no se gestionan igual?
▸Mostrar solución
Por el tiempo y la reversibilidad. El paquete se identifica, se retira y se parchea en horas. El veneno del dataset no da errores, tarda semanas en notarse y, una vez entrenado, está en los pesos: arreglarlo significa localizar el dato, limpiar el conjunto y reentrenar y revalidar, con el coste en cómputo que eso implica.
En resumen#
- Un sistema de IA añade activos propios: datos de entrenamiento, pesos, embeddings, system prompt, feature store y registro de modelos.
- Su comportamiento es no determinista y de caja negra: analizas entradas, salidas y modos de fallo, no código.
- Además de la cadena de software existe una cadena de datos de cinco eslabones; sus fallos son silenciosos y tardan en aflorar.
- STRIDE sigue sirviendo pero no cubre bien integridad del entrenamiento, manipulación adversaria, privilegio de herramientas y robo de modelos; ni sesgo, ni comportamientos emergentes.
- ATLAS aporta el “cómo” (tácticas, técnicas, sub-técnicas, mitigaciones y casos reales); OWASP aporta el “dónde” y la prioridad.
- Flujo: STRIDE para identificar, ATLAS para enriquecer, OWASP para ubicar y priorizar.