◇ OpenCyber Academy
Ingeniería · Capítulo 23 · Español

Capítulo 23 — Seguridad de la IA y del aprendizaje automático: análisis de amenazas y fallos

Aprendizaje gratuito y abierto para quienes desean proteger a las personas y la tecnología. No se necesita una cuenta para estudiar ni consultar las respuestas.

Capítulo 23 — Seguridad de la IA y del aprendizaje automático: análisis de amenazas y fallos

Mapa de la lección

Lección 23 publicada. Mapa, ejemplo, EX067.

flowchart TD
  N0["Resultados de aprendizaje"]
  N1["23.1 Análisis estructurado de amenazas"]
  N2["23.2 Correspondencia con catálogos compartidos"]
  N3["23.3 Combinación con el análisis de fallos"]
  N4["23.4 Jerarquización"]
  N5["23.4b Mantener vivo el análisis"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX067"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje"]
  N1["23.1 Análisis estructurado de amenazas"]
  N2["23.2 Correspondencia con catálogos compartidos"]
  N3["23.3 Combinación con el análisis de fallos"]
  N4["23.4 Jerarquización"]
  N5["23.4b Mantener vivo el análisis"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX067"]
[Resultados de aprendizaje]
    |
    v
[23.1 Análisis estructurado de amenazas]
    |
    v
[23.2 Correspondencia con catálogos compartidos]
    |
    v
[23.3 Combinación con el análisis de fallos]
    |
    v
[23.4 Jerarquización]
    |
    v
[23.4b Mantener vivo el análisis]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX067]

Resultados de aprendizaje

Usted será capaz de (1) realizar un análisis estructurado de amenazas sobre un sistema de IA con preguntas de tipo STRIDE adaptadas a la IA; (2) asignar las amenazas a técnicas de MITRE ATLAS y a entradas de OWASP para LLM; (3) combinar el análisis de amenazas con el de fallos; y (4) jerarquizar las amenazas según su riesgo.

23.1 Análisis estructurado de amenazas

Recorra cada elemento del diagrama de flujo de datos y pregúntese: ¿puede suplantarse (sensor falso, proveedor falso), manipularse (datos envenenados, pesos modificados), repudiarse (acción de un agente imposible de rastrear), divulgarse (inferencia de pertenencia, filtración del prompt), denegarse (agotamiento de recursos) o usarse para elevar privilegios (una inyección de instrucciones que llega a una herramienta)? Añada preguntas propias de la IA: ¿puede el modelo ser evadido, extraído, dotado de una puerta trasera o inducido a fabular de forma convincente? Recorrer elemento por elemento mantiene el análisis completo de un modo que la lluvia de ideas no consigue. Cada pregunta se formula aunque la respuesta parezca obvia, y «no aplicable» se anota con su motivo.

23.2 Correspondencia con catálogos compartidos

MITRE ATLAS organiza el comportamiento de los adversarios contra la IA en tácticas (como reconocimiento, desarrollo de recursos, acceso inicial, acceso al modelo de ML, persistencia, evasión de defensas, descubrimiento, recopilación, preparación del ataque de ML, exfiltración e impacto) y técnicas, con estudios de casos reales. Hacer corresponder sus amenazas con técnicas de ATLAS y entradas de OWASP para LLM ayuda a los revisores a comprobar la cobertura y enlaza con mitigaciones conocidas. La correspondencia es una comprobación cruzada, no un sustituto del análisis. Si una técnica del catálogo no tiene ninguna amenaza equivalente en el modelo, el equipo se pregunta si se pasó por alto o si realmente no aplica. Los estudios de casos son especialmente útiles para convencer a las partes interesadas de que una amenaza es real, ya que describen ataques que ocurrieron de verdad.

23.3 Combinación con el análisis de fallos

Las amenazas y los fallos suelen compartir efectos: un defecto no detectado puede deberse a un deslumbramiento (fallo) o a una marca (ataque). Analícelos juntos, de modo que controles como la monitorización estratificada y la alternativa manual cubran ambos. El análisis conjunto también evita el trabajo duplicado y los controles contradictorios. Una alternativa manual diseñada para el deslumbramiento puede activarla un atacante que quiera ralentizar las inspecciones, de modo que la propia alternativa necesita un límite de frecuencia o una alerta. Las tablas de peligros y de amenazas de Sam comparten identificadores para los efectos, de modo que un revisor puede ver todas las causas, accidentales o deliberadas, que conducen a un defecto no detectado y comprobar que algún control cubre cada una de ellas.

23.4 Jerarquización

Estime la probabilidad (capacidad y motivación del atacante, exposición) y el impacto (seguridad funcional, económico, legal, reputacional). Use una escala ordinal sencilla y documente el razonamiento. Vuelva a jerarquizar cuando cambien el sistema o el panorama de amenazas. Las escalas ordinales como baja, media y alta son honestas en cuanto a la precisión: las estimaciones de probabilidad de los ataques son juicios, no mediciones. Escribir el razonamiento junto a cada valoración, por ejemplo «media: los boletines de proveedores son públicos y los puede editar cualquier empleado del proveedor», permite a los revisores cuestionar el juicio en lugar del número. La nueva jerarquización la desencadenan los acontecimientos, como una herramienta nueva o un ataque publicado, no solo el calendario.

23.4b Mantener vivo el análisis

Los modelos de amenazas envejecen. Las herramientas nuevas, las fuentes de datos, las versiones de modelos y los ataques publicados cambian el panorama. Guarde el análisis junto a la arquitectura, asígnele una versión y programe su revisión en cada cambio significativo y, como mínimo, una vez al año. Registre qué amenazas se aceptaron y quién lo hizo, para que los riesgos aceptados no caigan en el olvido. En el caso de Wrench, el desencadenante es concreto: cuando Bulletin Gate entró en servicio, hubo que volver a puntuar la amenaza 1 de Sam, la inyección mediante boletines de proveedores, porque ahora los boletines llegan a Wrench solo como registros estructurados. La probabilidad bajó, pero en su lugar apareció una amenaza nueva: una actualización envenenada del modelo de extracción, que el ensayo del capítulo 47 puso a prueba más adelante.

23.5 Ejemplo resuelto (caso sintético de NRS)

Las cinco amenazas principales de Sam para Wrench: (1) inyección indirecta mediante boletín de proveedor → herramienta de órdenes de trabajo (probabilidad media, impacto alto); (2) inyección en las notas de los contratistas (media/alto); (3) divulgación de información sensible procedente de documentos de RR. HH. en la recuperación (media/medio, mitigada en el capítulo 13); (4) extracción del prompt del sistema que revela los nombres de las herramientas (alta/bajo); (5) agotamiento de recursos mediante documentos muy largos (media/medio). Cada una se hizo corresponder con OWASP (LLM01, LLM01, LLM02, LLM07, LLM10) y con técnicas de ATLAS de inyección de instrucciones y de denegación del servicio de ML.

Las dos amenazas de inyección comparten entrada en cada catálogo, pero siguen separadas en la lista porque sus fuentes, y por tanto sus controles, difieren.

23.6 Errores y límites

Una lista de amenazas sin modelo del sistema es genérica y pasa por alto las vías propias del diseño. Ignorar los fallos que tienen el mismo efecto que los ataques lleva a controles duplicados o a lagunas. Las jerarquías congeladas en la fase de diseño quedan desfasadas a medida que cambian las herramientas y las fuentes de datos. Sam vincula la lista de amenazas a la versión del diagrama, de modo que cualquier cambio en el diagrama marca el análisis para su revisión.

Ejercicios — capítulo 23

Síntesis del capítulo

El análisis de amenazas convierte el modelo del sistema en una lista jerarquizada de lo que podría salir mal, en correspondencia con catálogos compartidos y combinada con el análisis de fallos para que los controles cubran ambos.

Siga estudiando — capítulo 23 de 50

← Capítulo 22 (borrador) · Índice de capítulos del curso · Capítulo 24 (borrador) →