Capítulo 2 — Modelado de amenazas para sistemas LLM
Segunda entrega del recorrido capítulo por capítulo de LLM Primer VII: Seguridad de la IA. El capítulo que toma las cuatro preguntas de Shostack, STRIDE, PASTA y MITRE ATLAS, y las aplica a un sistema cuyo componente más poderoso lee toda entrada como potencialmente instructiva.
Por qué existe este capítulo
El capítulo 1 sostuvo que la seguridad de la IA es estructuralmente diferente. El capítulo 2 le da a esa diferencia forma operativa. Las cuatro preguntas de Adam Shostack — en qué estamos trabajando, qué puede salir mal, qué vamos a hacer al respecto, hicimos un buen trabajo — son las mismas para cualquier sistema, pero los diagramas, los inventarios de activos y los catálogos de adversarios que las responden se ven distintos cuando el sistema en cuestión incluye lógica de construcción de prompts, un pipeline de recuperación, un registro de herramientas y una función probabilística que trata el contenido recuperado en pie de igualdad con las instrucciones del desarrollador. El capítulo recorre los marcos — STRIDE, PASTA, MITRE ATLAS, NIST AI 100-2 — y produce la plantilla de trabajo del modelo de amenazas de un sistema LLM al que los capítulos posteriores siguen remitiéndose.
2.1 Los marcos se adaptan; los diagramas no pueden seguir siendo perezosos
STRIDE — spoofing, tampering, repudio, revelación de información, denegación de servicio y elevación de privilegio — resulta mapear sorprendentemente bien a los sistemas LLM. El spoofing se convierte en ataques de identidad sobre la API o suplantación del usuario. El tampering se convierte en inyección de prompts, envenenamiento de datos de entrenamiento y manipulación del índice de recuperación. El repudio se convierte en las disputas sobre quién envió qué prompt y quién produjo qué salida. La revelación de información se convierte en la extracción de datos de entrenamiento, la filtración del system prompt y la exposición entre inquilinos. La denegación de servicio se convierte en el LLM10 de OWASP, consumo no acotado mediante prompts caros e inundaciones de tokens. La elevación de privilegio se convierte en la frontera de uso de herramientas — un usuario que induce al modelo a llamar a una herramienta privilegiada hereda los privilegios de esa herramienta. PASTA superpone contexto de negocio y simulación de adversarios para equipos que ya hacen trabajo de red team. Ambos marcos asumen un diagrama de flujo de datos que separa los componentes de los que depende la pregunta de vigilancia. En sistemas LLM, el diagrama siempre debería separar la lógica de construcción de prompts, el pipeline de recuperación, el registro de herramientas, la llamada al modelo, la ruta de manejo de salida y la ruta de logging.
2.2 Activos que no aparecen en los inventarios convencionales
Un modelo de amenazas es tan bueno como su inventario de activos. Los sistemas LLM introducen categorías desconocidas para equipos cuyo trabajo previo fue sobre aplicaciones convencionales. El modelo en sí tiene varios subactivos — los pesos (un binario de varios gigabytes que representa una inversión significativa en entrenamiento), el comportamiento documentado (system prompt, políticas de seguridad, entrenamiento de alineamiento) y la reputación (un fallo público daña el producto con independencia de cualquier compromiso técnico). Los datos abarcan datos de entrenamiento, datos de ajuste fino, corpus de recuperación, entradas de usuario y salidas; cada uno tiene sus propios requisitos de confidencialidad, integridad y disponibilidad. El prompt en sí es ahora un activo — la propiedad intelectual de muchos productos vive en un system prompt refinado durante meses, y la lista de OWASP de 2025 llama explícitamente a la filtración del system prompt como LLM07. La infraestructura abarca la pila de inferencia, el almacén vectorial, las interfaces de herramientas y las credenciales que los unen. Los logs son un activo porque son el registro forense, y los activos de segundo orden — reputación del modelo, cumplimiento regulatorio, confianza del cliente — dependen de que los primarios sobrevivan al contacto con el tráfico.
2.3 Los adversarios tienen incentivos específicos
Un modelo de amenazas que protege por igual contra todo no protege contra nada. El inventario de adversarios tiene que ser específico. Los usuarios curiosos sondean el sistema para ver qué hace — usan técnicas que circulan por redes sociales, su volumen es alto, su impacto individual por incidente es bajo, pero su efecto acumulado sobre la seguridad aparente del sistema es significativo. Los usuarios maliciosos pretenden un daño específico — extraer contenido que el sistema debería rechazar, robar datos de otros usuarios o el system prompt, usar el sistema para atacar a terceros mediante phishing redactado o malware generado. Los competidores extraen el modelo (capítulo 8) o el system prompt para reducir su propio coste de desarrollo. Los internos operan desde dentro de la frontera de confianza. Los actores estatales combinan ataques a nivel de modelo con el resto de su oficio, y sus objetivos suelen ser organizaciones antes que el modelo directamente. Los agentes automatizados — a su vez LLMs, a veces guiados por otros adversarios — son la categoría más nueva y la que retoma el capítulo 17. Cada categoría de adversario tiene distintas capacidades, distintos incentivos y distintos perfiles de detección, y las mitigaciones que elevan el coste contra uno pueden no afectar al otro.
Lo que prepara el Capítulo 2
La plantilla desarrollada aquí — descripción del sistema en una página, diagrama de flujo de datos con fronteras de confianza, inventario de activos, catálogo de adversarios, enumeración de amenazas por STRIDE, mapeo de mitigaciones, registro de riesgo residual — es el marco que el resto del libro rellena. El capítulo 3 expande la categoría de activos de datos en su estructura completa — riesgos de datos de entrenamiento, memorización y extracción, manejo de entradas sensibles, cifrado y retención. El capítulo 4 retoma la inyección de prompts, que la categoría de tampering de STRIDE ya ha nombrado como la amenaza dominante contra el componente de construcción de prompts. Los capítulos 5 y 6 desarrollan las mitigaciones para la inyección de prompts en las capas de entrada, salida y RAG. Capítulos posteriores vuelven a la misma plantilla — el capítulo 11 para observabilidad, el capítulo 12 para identidad — pero el inventario de activos y el catálogo de adversarios introducidos aquí son los que esos capítulos extienden.
Próximamente — Capítulo 3: Seguridad de datos y privacidad. Riesgo de los datos de entrenamiento, memorización y extracción, los incidentes de Samsung y del Garante, y la disciplina de cifrado, aislamiento y retención que la seguridad de datos exige en sistemas LLM.