MITRE ATLAS

Definición

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) es una base de conocimiento pública de tácticas, técnicas y casos de estudio de adversarios observados contra sistemas con IA, estructurada siguiendo a MITRE ATT&CK para que los ataques específicos de IA se puedan describir en los mismos términos que el resto de la inteligencia de amenazas de una organización.

Alcance

Cualquier organización que construya, despliegue o defienda sistemas con IA, y cualquier equipo de seguridad que ya hable ATT&CK. Es una base de conocimiento, no una norma: nada certifica contra ella y no prescribe controles; describe lo que hacen los adversarios para que quien defiende decida qué detectar y qué prevenir.

Requisitos clave

• Estructurada en tácticas (el objetivo del adversario) y técnicas (cómo se logra), reflejando deliberadamente a MITRE ATT&CK para que los ataques de IA encajen en los modelos de amenaza existentes en lugar de vivir al lado.
• Cubre todo el arco de la intrusión —reconocimiento, acceso al modelo, ejecución, persistencia, evasión de defensas, descubrimiento, recolección, exfiltración, impacto— con etapas específicas de IA como la preparación de un ataque contra un modelo.
• Está guiada por evidencia: las entradas se apoyan en incidentes documentados y ejercicios de red team, que es lo que la separa de una lista de cosas que teóricamente podrían salir mal.
• Complementa a OWASP en lugar de competir con ella. OWASP clasifica debilidades de tu diseño; ATLAS describe el comportamiento adversario que las explota.
• Su valor práctico está en la detección y el red team: una técnica es algo que puedes intentar contra tu propio sistema y algo que puedes buscar en tus logs.
• La matriz se mantiene y amplía conforme se documentan ataques nuevos, así que es una referencia viva y no una lista de comprobación fija.

Controles

Mapea tu pila agéntica sobre la matriz

Recorre las tácticas frente a tu arquitectura y marca qué técnicas son alcanzables. Lo que hace que merezca la pena defender una técnica es su alcanzabilidad, no su plausibilidad.

Convierte las técnicas alcanzables en detecciones

Para cada una, nombra la señal que la mostraría en tu telemetría. Una técnica sin señal correspondiente es una que has decidido no ver.

Úsala como backlog del red team

Las técnicas son comprobables por construcción. Ejecútalas contra tu propio sistema y trata «no pudimos reproducirlo» como un resultado que merece registrarse, no como ausencia de trabajo.

Habla ATT&CK donde la organización ya lo habla

Reporta hallazgos de IA en términos de ATLAS para que entren en los mismos procesos de inteligencia, triaje y respuesta que todo lo demás. El vocabulario nuevo es la vía por la que el riesgo de IA acaba sin dueño.

Lee los casos de estudio, no solo la matriz

Los casos llevan el detalle operativo —cómo se obtuvo el acceso, qué hizo el adversario después—, que es la parte que se traslada a tu propio entorno.

Devuélvela al modelo de amenazas

ATLAS es la entrada externa a un modelo de amenazas agéntico; el modelo es donde sus técnicas se convierten en superficies tuyas, con controles y responsables asociados.

Lista de verificación

• 01Identifica qué tácticas de ATLAS son siquiera alcanzables en tu arquitectura.
• 02Para cada técnica alcanzable, registra el control que la acota y la señal que la detecta.
• 03Donde no haya detección, dilo explícitamente en lugar de dejar la fila en blanco.
• 04Programa ejercicios de red team sacados de la matriz y ve fallar o triunfar cada intento antes de afirmar cobertura.
• 05Reporta los hallazgos con identificadores de ATLAS para que entren en el flujo de inteligencia existente de la organización.
• 06Revisa la matriz periódicamente, porque se documentan técnicas nuevas conforme se observan.
• 07Cruza con el OWASP LLM Top 10 para que debilidades y comportamiento adversario queden mapeados entre sí y no en registros separados.

Errores comunes

• Tratarla como lista de cumplimiento. Nada certifica contra ATLAS, y «revisamos la matriz» no es un control.
• Mapear todas las técnicas sin importar su alcanzabilidad, lo que produce un documento grande y ninguna prioridad.
• Mantener la inteligencia de amenazas de IA en un proceso aparte del que ya tiene la organización: justo el resultado que la alineación con ATT&CK existe para evitar.
• Leer la matriz y saltarse los casos de estudio, que es donde vive el detalle operativo trasladable.
• Suponer cobertura sin probar. Una técnica que nunca has intentado contra tu propio sistema es una técnica sobre la que tienes una opinión.

Ejemplos

• Un equipo mapea su agente de recuperación sobre ATLAS y descubre que el acceso al modelo es trivial (el endpoint es público), la preparación es barata (cualquier editor de la wiki puede plantar contenido) y la exfiltración no tiene control (la salida no está restringida). Tres técnicas, y solo una les preocupaba ya.
• Una organización de seguridad que ya hace ingeniería de detección basada en ATT&CK añade técnicas de ATLAS al mismo backlog, de modo que las detecciones específicas de IA las construye, revisa y guardia el equipo que hace ese trabajo.
• Un red team usa la matriz como lista de objetivos para evaluar un agente y reporta con identificadores de ATLAS, lo que permite triar el hallazgo a gente que nunca ha trabajado con agentes.

FAQs

¿ATLAS sustituye a ATT&CK?

No, es su compañera. ATT&CK cubre el comportamiento adversario convencional; ATLAS cubre las etapas específicas de IA, estructuradas igual a propósito para que un ataque que empieza con un correo de phishing y termina en un modelo se pueda describir de punta a punta.

¿Necesito ATLAS si ya sigo el OWASP LLM Top 10?

Sirven a propósitos distintos y la combinación es justo el punto. OWASP te dice qué clase de debilidad tienes; ATLAS te dice qué hace un adversario con ella, que es lo que de verdad necesitan la detección y el red team.

¿Por dónde encaja para un equipo pequeño?

Primero como backlog de red team. Incluso sin un programa de detección, la matriz da una lista priorizada de ataques que intentar contra tu propio sistema, e intentarlos es la forma más barata de descubrir cuáles de tus controles solo existen sobre el papel.

Referencias

• MITRE ATLAS — Adversarial Threat Landscape for AI Systems
• OWASP — Top 10 for LLM Applications
• NIST — AI Risk Management Framework (AI RMF 1.0)

Gobernanza relacionada