Atribución y Niveles de Confianza: Framework para Analistas CTI
Framework completo de atribución CTI: niveles de confianza ICD 203, sistema Admiralty/NATO, calidad de evidencias, niveles de atribución (infraestructura a estado), Diamond Model aplicado, errores comunes y buenas prácticas para reportar confianza.
Atribuir un ciberataque sin cuantificar la confianza es irresponsable. Este framework convierte la incertidumbre en un lenguaje compartido entre analistas, directivos y clientes
La atribución es el acto de asignar un ciberataque a un actor específico. Es la conclusión más valiosa y más peligrosa que puede producir un equipo CTI. Valiosa porque permite anticipar, defender y disuadir. Peligrosa porque una atribución incorrecta puede escalar un conflicto, desperdiciar recursos de defensa o destruir la credibilidad del equipo.
La diferencia entre un analista junior y uno senior no es la cantidad de IOCs que procesan. Es cómo comunican lo que no saben. Los niveles de confianza son el mecanismo formal para eso.
Atribución técnica vs. atribución política
Antes de hablar de confianza, hay que distinguir dos tipos de atribución radicalmente diferentes.
Atribución técnica. Conectar un ataque con herramientas, infraestructura y TTPs. "El malware usado es X-Agent, asociado a APT28." Esto es responsabilidad del equipo CTI.
Atribución política. Afirmar que un estado patrocina al grupo. "El gobierno de Rusia ordenó este ataque." Esto es responsabilidad de gobiernos, no de analistas. Requiere SIGINT, HUMINT y contexto geopolítico que un equipo CTI privado normalmente no posee.
Un analista CTI produce atribución técnica. Puede inferir atribución operacional (qué grupo organizó el ataque). Nunca debería hacer atribución política como si fuera un hecho.
Niveles de confianza: ICD 203
El Intelligence Community Directive 203 establece una escala de confianza utilizada por la comunidad de inteligencia de EE.UU. y adoptada de facto por gran parte de la industria CTI.
Escala de probabilidad
| Nivel | Término inglés | Probabilidad | Significado |
|---|---|---|---|
| 6 | Almost certain | 93-100% | Evidencia de alta calidad, múltiples fuentes independientes, sin contradicciones |
| 5 | Probable / Likely | 63-85% | Evidencia sólida pero con gaps; las fuentes son coherentes |
| 4 | Even chance | 40-60% | Evidencia equilibrada; tanto la hipótesis como su contraria son posibles |
| 3 | Unlikely / Improbable | 15-37% | Evidencia débil a favor; la mayoría de indicios apuntan en otra dirección |
| 2 | Very unlikely | 5-15% | Evidencia muy débil; posible pero improbable |
| 1 | Remote | 0-5% | Casi descartable; requeriría evidencia excepcional para ser cierto |
Nivel de confianza (confidence)
Separado de la probabilidad, ICD 203 define el nivel de confianza en el análisis mismo:
| Nivel | Criterio |
|---|---|
| High confidence | Información de alta calidad, múltiples fuentes independientes, analistas experimentados, sin sesgos identificados |
| Moderate confidence | Información razonablemente creíble, algunas fuentes corroboran, gaps identificados pero manejables |
| Low confidence | Información fragmentaria, pocas fuentes, gaps significativos, analistas tienen reservas |
Combinación en un reporte
La forma correcta de expresar una conclusión CTI:
"Con confianza moderada, evaluamos que es probable (63-85%) que el incidente fue conducido por APT28. La confianza es moderada porque: (1) las TTPs son consistentes con el grupo, (2) la infraestructura C2 coincide parcialmente con campañas previas documentadas por Mandiant, pero (3) no se han identificado artefactos exclusivos de APT28 y (4) un grupo criminal podría haber reutilizado herramientas publicadas."
Esta frase comunica tres cosas: qué se cree (APT28), con qué certeza (probable), y por qué no se está más seguro (gaps).
Sistema Admiralty / NATO
El Admiralty Code (también llamado NATO Evaluation System) es más antiguo y más simple que ICD 203. Evalúa dos dimensiones por separado: la fiabilidad de la fuente y la credibilidad de la información.
Fiabilidad de la fuente (A-F)
| Código | Fiabilidad | Descripción |
|---|---|---|
| A | Completamente fiable | Historial de precisión comprobada; sin antecedentes de error |
| B | Normalmente fiable | Historial mayoritariamente preciso; errores menores ocasionales |
| C | Bastante fiable | Historial mixto; información a veces precisa, a veces no |
| D | No habitualmente fiable | Historial pobre; más errores que aciertos |
| E | No fiable | Historial de información incorrecta o deliberadamente engañosa |
| F | No evaluable | Sin historial; fuente nueva o desconocida |
Credibilidad de la información (1-6)
| Código | Credibilidad | Descripción |
|---|---|---|
| 1 | Confirmada | Confirmada por fuentes independientes |
| 2 | Probablemente verdadera | No confirmada, pero coherente con información conocida |
| 3 | Posiblemente verdadera | No confirmada, no contradice información conocida |
| 4 | Dudosamente verdadera | No confirmada, inconsistente con información conocida |
| 5 | Improbable | Contradice información confirmada |
| 6 | No evaluable | Sin base para determinar credibilidad |
Aplicación práctica en CTI
| Fuente | Información | Clasificación |
|---|---|---|
| Mandiant (historial excelente) | "APT28 usa nueva variante de X-Agent" | A2 |
| Investigador independiente (nuevo) | "IP 45.67.89.123 es C2 de APT28" | F3 |
| OTX pulse anónimo | "Hash abc123 es Emotet" | F4 |
| CISA KEV (gobierno EE.UU.) | "CVE-2024-1234 explotada activamente" | A1 |
| Feed de Telegram no verificado | "Lazarus prepara ataque a bancos EU" | D5 |
MISP implementa el Admiralty Code en cada evento y atributo, lo que permite filtrar automáticamente por calidad.
Calidad de evidencia: no todas las evidencias valen lo mismo
Antes de asignar confianza, el analista debe evaluar la calidad de cada pieza de evidencia.
Jerarquía de evidencias en CTI
| Nivel | Tipo de evidencia | Peso | Ejemplo |
|---|---|---|---|
| 1 | Acceso directo al sistema comprometido | Muy alto | Análisis forense del disco, memory dump, logs de red |
| 2 | Análisis técnico de malware | Alto | Reverse engineering del binario, análisis de sandbox |
| 3 | Inteligencia de fuentes técnicas | Alto | DNS pasivo, WHOIS histórico, certificados TLS |
| 4 | Reportes de vendors de seguridad | Medio-Alto | Mandiant, CrowdStrike, Microsoft, Kaspersky |
| 5 | Feeds de IOCs públicos | Medio | MalwareBazaar, ThreatFox, OTX |
| 6 | Fuentes abiertas (OSINT) | Medio-Bajo | Artículos de prensa, blogs, conferencias |
| 7 | Fuentes no verificables | Bajo | Telegram, foros, redes sociales, fuentes anónimas |
Criterios de evaluación
Para cada evidencia, evaluar:
- Procedencia. ¿De dónde viene? ¿Es de primera mano o citada por terceros?
- Corroboración. ¿Está confirmada por fuentes independientes?
- Frescura. ¿Cuándo se obtuvo? La inteligencia técnica caduca rápido.
- Especificidad. ¿Apunta a un actor concreto o es genérica?
- Resistencia a manipulación. ¿Podría haber sido plantada por el adversario?
Framework de atribución: niveles
La atribución no es binaria. Hay niveles, y cada nivel requiere más evidencia que el anterior.
Los 5 niveles de atribución
Nivel 1: Atribución de infraestructura.
Conectar el ataque con servidores, dominios e IPs específicos.
- Evidencia: DNS pasivo, WHOIS, certificados TLS, hosting providers
- Confianza típica: Alta (datos técnicos objetivos)
- Ejemplo: "El C2 está en 185.220.101.34, alojado en BulletProof Hosting en Moldavia"
Nivel 2: Atribución de herramientas (tooling).
Conectar el ataque con malware, exploits o frameworks específicos.
- Evidencia: Análisis de malware, YARA rules, code similarity
- Confianza típica: Moderada-Alta
- Ejemplo: "El binario es una variante de X-Agent con similitud de código del 87% respecto a la muestra analizada por ESET en 2024"
- Caveat: Las herramientas se comparten, se roban y se filtran. Cobalt Strike lo usan cientos de grupos.
Nivel 3: Atribución operacional.
Conectar el ataque con un patrón operativo (modus operandi) de un grupo conocido.
- Evidencia: TTPs (MITRE ATT&CK), cadena de infección, victimología, horarios de actividad, errores de OPSEC
- Confianza típica: Moderada
- Ejemplo: "La cadena de infección (spearphishing → macro → PowerShell → Cobalt Strike → exfiltración DNS) coincide con 4 campañas previas atribuidas a APT28"
- Caveat: Los grupos evolucionan sus TTPs. Las coincidencias pueden ser circunstanciales.
Nivel 4: Atribución organizacional.
Conectar el grupo con una organización específica (unidad militar, agencia de inteligencia, grupo criminal).
- Evidencia: Indictments judiciales, SIGINT, HUMINT, investigaciones periodísticas de largo plazo
- Confianza típica: Baja-Moderada (para equipos CTI privados)
- Ejemplo: "APT28 ha sido asociado al GRU (unidad 26165) por el DOJ de EE.UU. en el indictment de julio 2018"
- Caveat: Esta atribución generalmente la hacen gobiernos, no equipos privados.
Nivel 5: Atribución estatal.
Afirmar que un estado ordenó la operación.
- Evidencia: Inteligencia clasificada, declaraciones gubernamentales, contexto geopolítico
- Confianza típica: Fuera del alcance de equipos CTI privados
- Ejemplo: "El gobierno del Reino Unido declara que el GRU, bajo dirección del gobierno ruso, condujo la operación"
- Caveat: Esto es una declaración política, no un análisis técnico.
Regla práctica
Un equipo CTI privado puede alcanzar con confianza los niveles 1 a 3. El nivel 4 es posible cuando existe investigación pública previa (indictments, reportes de CERTs nacionales). El nivel 5 no es responsabilidad del analista CTI.
Diamond Model aplicado a la atribución
El Diamond Model proporciona la estructura para organizar la atribución.
ADVERSARY
(Nivel 3-4-5)
/\
/ \
/ \
/ \
CAPABILITY ◄/────────\► INFRASTRUCTURE
(Nivel 2) \ / (Nivel 1)
\ /
\ /
\ /
\/
VICTIM
(Contexto)
La atribución empieza por los vértices con mayor certeza (infraestructura, herramientas) y pivota hacia los de menor certeza (adversario).
Flujo de atribución con Diamond Model
- Infraestructura (Nivel 1). Identificar C2, dominios, IPs. Certeza alta.
- Capability (Nivel 2). Analizar malware, exploits. Coincidencias con grupos conocidos.
- Victim (Contexto). ¿La víctima encaja con los intereses de algún grupo?
- Adversary (Nivel 3+). Cruzar los tres vértices para generar hipótesis de atribución.
- ACH. Evaluar las hipótesis con la matriz de Analysis of Competing Hypotheses.
- Confianza. Asignar nivel según ICD 203 o Admiralty Code.
Errores comunes de atribución
Error 1: Atribución por herramientas
"Usa Cobalt Strike, así que es un APT." Cobalt Strike es usado por cientos de grupos, desde APTs hasta criminales y pentesters. Una herramienta no es un actor.
Error 2: Atribución por idioma
"El código tiene strings en mandarín, así que es chino." Los idiomas se plantan deliberadamente. Olympic Destroyer (atribuido a Sandworm/GRU) contenía artefactos que imitaban a Lazarus, incluyendo strings en coreano.
Error 3: Atribución por víctima
"Atacó al sector energético europeo, así que es ruso." Múltiples actores (estatales y criminales) atacan los mismos sectores por motivos diferentes. La victimología es contexto, no prueba.
Error 4: Atribución circular
"Mandiant dice que es APT28. CrowdStrike cita a Mandiant y dice que es Fancy Bear (APT28). Microsoft cita a ambos y dice que es STRONTIUM (APT28)." Son tres fuentes que dicen lo mismo, pero no son tres fuentes independientes. Son una fuente y dos ecos.
Error 5: Omitir hipótesis alternativas
Reportar "el ataque es de APT29" sin mencionar que también podría ser APT28 o un grupo criminal. ICD 203 exige documentar hipótesis alternativas.
Error 6: Confundir confianza con probabilidad
"Atribuimos con alta confianza a APT28" no significa "estamos seguros de que es APT28." Significa "nuestra confianza en nuestro análisis es alta." Si la probabilidad es 65% (probable) con alta confianza, eso dice: "estamos razonablemente seguros de nuestro juicio de que hay un 65% de probabilidad."
Buenas prácticas para reportar confianza
1. Separar observación de inferencia
| Tipo | Ejemplo |
|---|---|
| Observación | "El malware contacta 185.220.101.34 en puerto 443" |
| Inferencia | "Este C2 es consistente con infraestructura de APT28" |
| Conclusión | "Con confianza moderada, evaluamos que el ataque es probable obra de APT28" |
2. Documentar las evidencias que faltan
No solo qué sabes. Qué te falta.
"Nuestra confianza es moderada (no alta) porque:
- No hemos podido analizar el binario completo (solo el loader)
- No tenemos acceso a los logs de red del primer día del incidente
- La infraestructura C2 no aparece en campañas previas documentadas"
3. Usar lenguaje calibrado
| Evitar | Usar |
|---|---|
| "Es APT28" | "Evaluamos que es probable (63-85%) que sea APT28" |
| "Confirmamos" | "Con alta confianza, evaluamos" |
| "No hay duda" | Nunca usar. Siempre hay duda |
| "Podría ser" | Demasiado vago. Cuantificar: "unlikely (15-37%)" |
4. Versionar la atribución
La atribución cambia con nueva evidencia. Un reporte de atribución debe ser un documento vivo.
v1.0 (día 1): "Even chance (40-60%), confianza baja"
v1.1 (día 3): "Probable (63-85%), confianza moderada"
Motivo: nuevos IOCs correlacionan con campaña APT28 Q3 2025
v1.2 (día 14): "Almost certain (93-100%), confianza alta"
Motivo: CERT nacional confirma con SIGINT independiente
5. Incluir indicadores de cambio
Qué nueva evidencia haría que cambies tu conclusión:
- "Si el C2 resulta ser infraestructura compartida en foro criminal, la confianza baja a 'even chance'"
- "Si aparece un segundo incidente con misma cadena de infección en sector defensa OTAN, la confianza sube a 'almost certain'"
Matriz de decisión: qué sistema de confianza usar
| Contexto | Sistema recomendado | Razón |
|---|---|---|
| Reporte para SOC interno | Admiralty Code (A2, B3, etc.) | Rápido, conciso, accionable |
| Reporte para CERT nacional | ICD 203 (probable, confianza moderada) | Estándar de la comunidad de inteligencia |
| Evento MISP compartido | Admiralty Code + taxonomía MISP | Nativo en MISP |
| Briefing ejecutivo para CISO | ICD 203 simplificado | "Probable" y "posible" son intuitivos para no técnicos |
| Publicación en blog CTI | ICD 203 | Estándar de la industria |
| Compartición STIX/TAXII | Campo confidence (0-100) | Cuantitativo, procesable por máquinas |
Recursos
- ICD 203: Analytic Standards (Office of the DNI). El estándar de referencia para niveles de confianza
- Richards J. Heuer, Psychology of Intelligence Analysis (CIA, 1999). Capítulo 12: niveles de confianza
- NATO STANAG 2022: Intelligence Reports. Especificación del Admiralty Code
- Thomas Rid & Ben Buchanan, Attributing Cyber Attacks (Journal of Strategic Studies, 2015). El paper académico de referencia
- MITRE ATT&CK, Groups (https://attack.mitre.org/groups/). Catálogo de actores con TTPs documentadas
- Timo Steffens, Attribution of Advanced Persistent Threats (Springer, 2020). Libro completo sobre el tema
- MISP Project, Taxonomies: Admiralty Scale (https://www.misp-project.org/taxonomies.html). Implementación en MISP
Preguntas frecuentes
Artículos relacionados
Este contenido tiene fines exclusivamente educativos y de investigación en ciberseguridad defensiva. No se proporcionan binarios maliciosos ni payloads ejecutables. El uso indebido de esta información es responsabilidad exclusiva del usuario. Leer disclaimer completo.