OpenIOC vs STIX 2.1: Evolución de los Estándares CTI

Los estándares CTI permiten que las organizaciones compartan inteligencia de amenazas de forma estructurada, automatizable y sin ambigüedad

Sin un formato común, compartir inteligencia es copiar y pegar texto libre en emails. Con estándares, un indicador detectado en una organización puede alimentar las defensas de miles de organizaciones en minutos. Esta es la historia de cómo pasamos de OpenIOC a STIX 2.1, y por qué importa.

Historia: del texto libre al grafo de conocimiento

Los primeros años (2007-2011)

Antes de los estándares formales, la inteligencia de amenazas se compartía en informes PDF, listas de IPs en archivos de texto plano y correos electrónicos entre analistas. Cada organización tenía su propio formato. La automatización era imposible.

En 2007, MITRE desarrolló MAEC (Malware Attribute Enumeration and Characterization) como primer intento de estructurar atributos de malware. Era un paso importante, pero demasiado complejo para adopción masiva.

OpenIOC (2011-2013)

Mandiant (ahora parte de Google Cloud) creó OpenIOC en 2011 como formato XML para describir indicadores de compromiso. Fue el primer estándar práctico que los equipos de respuesta a incidentes adoptaron ampliamente.

Características de OpenIOC:

• Formato XML con schema definido
• Lógica booleana (AND/OR) para combinar indicadores
• Foco en artefactos forenses: hashes de ficheros, claves de registro, mutex, conexiones de red
• Integración con Redline (herramienta de análisis forense de Mandiant)

Ejemplo simplificado de un IOC en OpenIOC:

<ioc id="example-ioc-001">
  <short_description>Emotet Dropper</short_description>
  <definition>
    <Indicator operator="AND">
      <IndicatorItem>
        <Context document="FileItem" search="FileItem/Md5sum"/>
        <Content type="md5">d41d8cd98f00b204e9800998ecf8427e</Content>
      </IndicatorItem>
      <IndicatorItem>
        <Context document="RegistryItem" search="RegistryItem/Path"/>
        <Content type="string">HKCU\Software\Microsoft\Office\</Content>
      </IndicatorItem>
    </Indicator>
  </definition>
</ioc>

OpenIOC resolvía un problema real, pero tenía limitaciones fundamentales: no modelaba relaciones entre entidades (actores, campañas, TTPs), era XML (verboso y difícil de procesar), y no definía un protocolo de transporte.

CybOX y STIX 1.x (2012-2015)

MITRE desarrolló CybOX (Cyber Observable eXpression) para describir observables cibernéticos y STIX 1.x como contenedor más amplio que incluía actores, campañas, TTPs y cursos de acción. Junto a ellos, TAXII 1.x definía el transporte.

STIX 1.x era XML, extremadamente complejo, y su adopción fue limitada por la dificultad de implementación. Un indicador simple podía requerir cientos de líneas de XML anidado.

STIX 2.0 y 2.1 (2017-2021)

La comunidad aprendió de los errores. OASIS (Organization for the Advancement of Structured Information Standards) tomó el liderazgo y rediseñó STIX desde cero:

• JSON en lugar de XML: más ligero, más fácil de parsear
• Modelo de grafos: objetos conectados por relaciones explícitas
• CybOX absorbido: los observables se integraron directamente en STIX
• Simplificación radical: menos objetos, más claros, mejor documentados
• Versionado de objetos: cada objeto tiene su historial de cambios

STIX 2.1 (publicado en 2021) es la versión actual y el estándar de facto del ecosistema CTI.

Objetos STIX 2.1: los bloques de construcción

STIX 2.1 define tres categorías de objetos.

STIX Domain Objects (SDOs): las entidades del dominio

SDO	Descripción	Equivalente MalwareIntel
attack-pattern	Técnica de ataque (mapea a ATT&CK)	TTP
campaign	Conjunto de actividad maliciosa con objetivo común	Campaign
course-of-action	Contramedida o mitigación	D3FEND Mitigation
identity	Organización, individuo o grupo	(metadata)
indicator	Patrón que detecta actividad maliciosa	IOC con patrón STIX
infrastructure	Recursos usados por el atacante	C2 Infrastructure
intrusion-set	Conjunto de comportamientos atribuidos a un actor	ThreatActor (parcial)
malware	Software malicioso	MalwareFamily
malware-analysis	Resultado de análisis de una muestra	(enrichment data)
note	Comentario o contexto adicional	(metadata)
observed-data	Observable crudo (IP, hash, dominio)	IOC (valor crudo)
opinion	Evaluación subjetiva sobre otro objeto	(confidence score)
report	Colección de inteligencia sobre un tema	(blog/report)
threat-actor	Individuo o grupo con intención maliciosa	ThreatActor
tool	Software legítimo usado con fines maliciosos	(tag en TTP)
vulnerability	Debilidad explotable (CVE)	(KEV/EPSS data)

STIX Relationship Objects (SROs)

Los SROs conectan SDOs entre sí, formando el grafo de conocimiento:

{
  "type": "relationship",
  "id": "relationship--a1b2c3d4",
  "relationship_type": "uses",
  "source_ref": "threat-actor--apt28-id",
  "target_ref": "malware--emotet-id",
  "confidence": 85,
  "created": "2026-01-15T10:00:00Z"
}

Tipos de relación habituales:

Relación	De -> A	Significado
uses	threat-actor -> malware	El actor usa este malware
uses	malware -> attack-pattern	El malware implementa esta técnica
indicates	indicator -> malware	Este indicador detecta este malware
attributed-to	intrusion-set -> threat-actor	Se atribuye al actor
targets	campaign -> identity	La campaña ataca a esta organización
mitigates	course-of-action -> attack-pattern	La contramedida mitiga esta técnica
variant-of	malware -> malware	Variante de otra familia

STIX Cyber-observable Objects (SCOs)

Los SCOs representan datos observados directamente en la red o en un endpoint:

• ipv4-addr, ipv6-addr, domain-name, url
• file (con hashes MD5, SHA-1, SHA-256)
• email-addr, email-message
• network-traffic, process, software
• windows-registry-key, user-account

Un indicator SDO referencia SCOs mediante el STIX Pattern Language:

[file:hashes.'SHA-256' = 'a1b2c3d4...'] AND
[network-traffic:dst_ref.type = 'ipv4-addr' AND
 network-traffic:dst_ref.value = '203.0.113.42']

TAXII 2.1: el protocolo de transporte

TAXII (Trusted Automated eXchange of Indicator Information) define cómo los sistemas intercambian objetos STIX a través de HTTP/HTTPS.

Conceptos clave de TAXII 2.1

API Root: punto de entrada al servidor TAXII. Una organización puede tener varios API Roots para diferentes audiencias.

Collections: conjuntos lógicos de objetos STIX. Cada collection tiene un ID único y puede ser de lectura, escritura o ambas.

Channels (nuevo en 2.1): mecanismo publish/subscribe para distribución en tiempo real.

Endpoints TAXII 2.1

GET  /taxii2/                          -> Discovery (API roots disponibles)
GET  /taxii2/{api-root}/               -> Información del API root
GET  /taxii2/{api-root}/collections/   -> Lista de collections
GET  /taxii2/{api-root}/collections/{id}/objects/  -> Objetos STIX
POST /taxii2/{api-root}/collections/{id}/objects/  -> Publicar objetos
GET  /taxii2/{api-root}/collections/{id}/manifest/ -> Metadatos sin contenido

Filtrado y paginación

TAXII 2.1 soporta filtros por:

• added_after: objetos añadidos después de una fecha (para sincronización incremental)
• match[type]: filtrar por tipo de objeto STIX
• match[id]: filtrar por ID específico
• match[version]: versión del objeto

Esto permite a los consumidores obtener solo las actualizaciones desde su última sincronización, reduciendo el ancho de banda.

Comparativa: OpenIOC vs STIX 2.1

Aspecto	OpenIOC	STIX 2.1
Formato	XML	JSON
Mantenimiento	Sin actualizaciones desde 2013	Activo (OASIS TC)
Modelo de datos	Indicadores aislados	Grafo de conocimiento
Entidades	Solo IOCs (artefactos forenses)	18 tipos de objeto (actores, campañas, TTPs, malware...)
Relaciones	No explícitas	Objetos Relationship tipados
Transporte	No definido	TAXII 2.1 (HTTP/HTTPS)
Observables	Artefactos forenses (ficheros, registro)	Cyber-observable Objects (red, endpoint, email)
Lógica de detección	Booleana (AND/OR en XML)	STIX Patterning Language
Atribución	No soportada	threat-actor, intrusion-set, campaign
Mitigaciones	No soportadas	course-of-action
Confianza	No	Campo confidence (0-100)
TLP	No nativo	Marking definitions integradas
Adopción actual	Legacy (Mandiant/FireEye tools)	Universal (MITRE, MISP, OpenCTI, CrowdStrike, Palo Alto)

OpenIOC: valor residual

Aunque STIX 2.1 domina el ecosistema, OpenIOC conserva valor en contextos específicos:

1. Respuesta a incidentes forense: OpenIOC sigue integrado en herramientas como Redline y YARA (vía conversión). Para un analista forense que busca artefactos en disco, la lógica booleana de OpenIOC es directa y eficaz.

2. Simplicidad: para compartir un conjunto pequeño de hashes y claves de registro dentro de un equipo, un fichero OpenIOC es más rápido de crear que un bundle STIX completo.

3. Compatibilidad legacy: organizaciones con herramientas Mandiant/FireEye desplegadas pueden seguir consumiendo OpenIOC sin migrar toda la infraestructura.

La recomendación es clara: para cualquier proyecto nuevo, usar STIX 2.1. Para conversión de IOCs legacy, herramientas como stix-shifter o openioc-to-stix automatizan la migración.

STIX 2.1 en la práctica

MISP (Malware Information Sharing Platform)

MISP usa su propio formato interno (eventos, atributos, galaxies), pero soporta importación y exportación STIX 2.1 nativa. Los feeds MISP pueden servirse como collections TAXII 2.1.

Flujo típico:

Analista crea evento MISP
  -> Añade atributos (IOCs) y tags (ATT&CK)
  -> MISP genera bundle STIX 2.1 automáticamente
  -> Otros MISP o plataformas CTI consumen via TAXII

OpenCTI

OpenCTI está construido nativamente sobre STIX 2.1. Su modelo interno es el grafo STIX: cada entidad, relación y observable sigue la especificación. Los conectores de OpenCTI importan datos de fuentes externas y los normalizan a STIX antes de almacenarlos.

MITRE ATT&CK

ATT&CK distribuye su base de conocimiento completa en formato STIX 2.1 a través de un servidor TAXII público:

Server:     cti-taxii.mitre.org
API Root:   /stix/taxii2/
Collections:
  - Enterprise ATT&CK
  - Mobile ATT&CK
  - ICS ATT&CK

Esto permite a cualquier plataforma sincronizar automáticamente las técnicas, grupos y software de ATT&CK.

MalwareIntel

MalwareIntel consume feeds STIX 2.1 (MITRE ATT&CK via TAXII) y normaliza los datos a su modelo interno. El endpoint GET /api/v1/export/stix genera bundles STIX 2.1 para interoperabilidad con otras plataformas.

Ejemplo completo: un IOC en STIX 2.1

Un indicador que detecta actividad de Emotet, con su contexto completo:

{
  "type": "bundle",
  "id": "bundle--example-001",
  "objects": [
    {
      "type": "indicator",
      "id": "indicator--a1b2c3d4",
      "name": "Emotet C2 IP",
      "pattern": "[network-traffic:dst_ref.value = '203.0.113.42']",
      "pattern_type": "stix",
      "valid_from": "2026-01-01T00:00:00Z",
      "confidence": 90,
      "labels": ["malicious-activity"]
    },
    {
      "type": "malware",
      "id": "malware--emotet-001",
      "name": "Emotet",
      "malware_types": ["loader", "banking-trojan"],
      "is_family": true
    },
    {
      "type": "relationship",
      "id": "relationship--rel-001",
      "relationship_type": "indicates",
      "source_ref": "indicator--a1b2c3d4",
      "target_ref": "malware--emotet-001"
    }
  ]
}

Este bundle contiene el indicador, la familia de malware asociada y la relación entre ambos. Cualquier plataforma compatible con STIX 2.1 puede importarlo directamente.

Hacia el futuro: STIX 2.1 y más allá

El comité técnico de OASIS trabaja en extensiones para cubrir nuevos dominios:

• STIX Extensions: objetos custom para dominios específicos (financiero, salud, infraestructura crítica)
• STIX Confidence Framework: estandarización del campo confidence con escalas compatibles entre organizaciones
• Integración con CACAO: playbooks de respuesta automatizada que referencian objetos STIX

La tendencia es clara: STIX 2.1 se consolida como el lenguaje universal de la inteligencia de amenazas, y TAXII 2.1 como su protocolo de distribución.

Recursos

• Especificación STIX 2.1 (OASIS)
• Especificación TAXII 2.1 (OASIS)
• MITRE ATT&CK STIX Data
• OpenIOC Schema (Mandiant)
• cti-python-stix2 (librería Python)
• stix-shifter (conversión entre formatos)
• OpenCTI Documentation
• MISP STIX Support