November 2, 2026
STIX y TAXII: Convertir los datos de amenazas en inteligencia
Un analista de seguridad ve un dominio extraño en una alerta a las 7:42 de la mañana de un martes. ¿Es malicioso? ¿Está vinculado a un…

By Maram Raboudi
9 min read
Un analista de seguridad ve un dominio extraño en una alerta a las 7:42 de la mañana de un martes. ¿Es malicioso? ¿Está vinculado a un incidente que otra empresa tuvo la semana pasada? ¿Debería bloquearse, o es un servicio en la nube compartido por miles de organizaciones que dejaría sin funcionar la nómina?
Una hoja de cálculo de indicadores no puede responder esas preguntas. Necesitas saber de dónde vino la afirmación, qué tan seguro estaba el autor, a qué campaña pertenece y si sigue siendo cierta hoy. Dos estándares abiertos fueron creados para transportar exactamente ese contexto: STIX y TAXII.
La respuesta corta: STIX (Structured Threat Information Expression) es un formato JSON estándar para describir inteligencia de amenazas cibernéticas. TAXII (Trusted Automated Exchange of Intelligence Information) es un protocolo HTTPS para compartir esa inteligencia entre sistemas. STIX es el lenguaje; TAXII es la ruta de entrega.
Es importante señalar que STIX y TAXII se centran en estructurar e intercambiar inteligencia de amenazas; el descubrimiento y la identificación iniciales de las amenazas son procesos separados que tienen lugar antes de esta etapa.
¿Qué es STIX?
Es un estándar abierto, mantenido por OASIS, que describe la información de amenazas cibernéticas como JSON. En lugar de pasar valores desconectados de un lado a otro, un equipo describe objetos y las relaciones entre ellos: un indicador, una campaña de phishing, una familia de malware, un comportamiento de ataque o un avistamiento en su propio entorno.
Imagina que una empresa ficticia recibe un informe sobre una campaña de phishing dirigida a su industria. El informe menciona un dominio sospechoso, un archivo adjunto malicioso y un comportamiento observado después de abrir el adjunto. Una lista plana captura el dominio y el hash del archivo. Una representación en STIX conserva el resto del panorama:
Qué se observó: el dominio o el archivo, como un objeto Indicator o Observed Data.
Con qué puede estar asociado: un objeto Campaign, Intrusion Set o Malware.
Qué comportamiento se reportó: un Attack Pattern, que a menudo apunta a una técnica de MITRE ATT&CK.
De dónde vino la afirmación: una Identity (la fuente) y referencias externas al informe original.
Qué tan seguros están los analistas: un valor de confianza de 0 a 100.
Cómo se relacionan los objetos: objetos Relationship, como "este indicador indica esa campaña".
-> Así encajan estas piezas: Un objeto Identity dice quién escribió el informe. Un Indicator contiene el dominio sospechoso. Una Campaign llamada "Payroll Lure" le da una etiqueta a la actividad, y un Attack Pattern apunta a la técnica T1566.001 de MITRE ATT&CK, spearphishing attachment. Dos objetos Relationship los unen: el indicador "indicates" la campaña, y la campaña "uses" la técnica. Más tarde, un Sighting registra que tu propio equipo vio el dominio una vez.
Esa estructura importa cuando llega información nueva. Si otro equipo reporta el mismo dominio en un contexto diferente, los analistas pueden comparar los dos registros lado a lado sin asumir que prueban el mismo actor o la misma campaña.
Un ejemplo de STIX 2.1
El contenido STIX es JSON. A continuación se muestra el informe ficticio de phishing de la sección anterior, escrito como un bundle STIX 2.1: una fuente, un indicador, una campaña, un patrón de ataque, dos relaciones y un avistamiento local. El dominio, las fechas y los IDs son inventados, y el dominio está bajo example.com para que nadie lo confunda con un indicador real.
{
"type": "bundle",
"id": "bundle--b92f4d1a-6c37-4e85-9a0d-7f1e5c3b8a24",
"objects": [
{
"type": "identity",
"spec_version": "2.1",
"id": "identity--8f2b8c1e-6a3d-4c58-9d7e-2b1f4a6c9e10",
"created": "2026-10-14T08:00:00.000Z",
"modified": "2026-10-14T08:00:00.000Z",
"name": "Example Threat Intel Team",
"identity_class": "organization"
},
{
"type": "indicator",
"spec_version": "2.1",
"id": "indicator--7d3e9a51-0c28-4b6f-9e14-a5c8f2b60d37",
"created_by_ref": "identity--8f2b8c1e-6a3d-4c58-9d7e-2b1f4a6c9e10",
"created": "2026-10-14T08:30:00.000Z",
"modified": "2026-10-14T08:30:00.000Z",
"name": "Payroll lure domain",
"description": "Domain used in phishing emails that imitate an HR payroll update.",
"indicator_types": ["malicious-activity"],
"pattern": "[domain-name:value = 'payroll-update-portal.example.com']",
"pattern_type": "stix",
"valid_from": "2026-10-12T00:00:00.000Z",
"valid_until": "2027-01-12T00:00:00.000Z",
"confidence": 70,
"external_references": [
{
"source_name": "Example Industry Advisory 2026-041",
"url": "https://example.com/advisories/2026-041"
}
],
"object_marking_refs": [
"marking-definition--34098fce-860f-48ae-8e50-ebd3cc5e41da"
]
},
{
"type": "campaign",
"spec_version": "2.1",
"id": "campaign--c4a1d7e2-5b39-4e8f-a6d0-3f7b92e1c845",
"created_by_ref": "identity--8f2b8c1e-6a3d-4c58-9d7e-2b1f4a6c9e10",
"created": "2026-10-14T08:30:00.000Z",
"modified": "2026-10-14T08:30:00.000Z",
"name": "Payroll Lure",
"first_seen": "2026-10-12T00:00:00.000Z",
"confidence": 50
},
{
"type": "attack-pattern",
"spec_version": "2.1",
"id": "attack-pattern--2b9e6f4a-1d73-4c0b-8e5a-6a7d3c9f1b22",
"created_by_ref": "identity--8f2b8c1e-6a3d-4c58-9d7e-2b1f4a6c9e10",
"created": "2026-10-14T08:30:00.000Z",
"modified": "2026-10-14T08:30:00.000Z",
"name": "Spearphishing Attachment",
"external_references": [
{
"source_name": "mitre-attack",
"external_id": "T1566.001",
"url": "https://attack.mitre.org/techniques/T1566/001/"
}
]
},
{
"type": "relationship",
"spec_version": "2.1",
"id": "relationship--e1a4c8b7-3f52-4d19-b6a8-0c9d7e2f5a41",
"created_by_ref": "identity--8f2b8c1e-6a3d-4c58-9d7e-2b1f4a6c9e10",
"created": "2026-10-14T08:30:00.000Z",
"modified": "2026-10-14T08:30:00.000Z",
"relationship_type": "indicates",
"source_ref": "indicator--7d3e9a51-0c28-4b6f-9e14-a5c8f2b60d37",
"target_ref": "campaign--c4a1d7e2-5b39-4e8f-a6d0-3f7b92e1c845"
},
{
"type": "relationship",
"spec_version": "2.1",
"id": "relationship--5c7f2a96-8b14-4e03-a9d5-1b6e3f8c0d72",
"created_by_ref": "identity--8f2b8c1e-6a3d-4c58-9d7e-2b1f4a6c9e10",
"created": "2026-10-14T08:30:00.000Z",
"modified": "2026-10-14T08:30:00.000Z",
"relationship_type": "uses",
"source_ref": "campaign--c4a1d7e2-5b39-4e8f-a6d0-3f7b92e1c845",
"target_ref": "attack-pattern--2b9e6f4a-1d73-4c0b-8e5a-6a7d3c9f1b22"
},
{
"type": "sighting",
"spec_version": "2.1",
"id": "sighting--a3d6e91c-7f08-4b25-8c4e-9e0b1a5d2f63",
"created_by_ref": "identity--8f2b8c1e-6a3d-4c58-9d7e-2b1f4a6c9e10",
"created": "2026-10-15T09:10:00.000Z",
"modified": "2026-10-15T09:10:00.000Z",
"sighting_of_ref": "indicator--7d3e9a51-0c28-4b6f-9e14-a5c8f2b60d37",
"where_sighted_refs": ["identity--8f2b8c1e-6a3d-4c58-9d7e-2b1f4a6c9e10"],
"first_seen": "2026-10-15T07:42:00.000Z",
"last_seen": "2026-10-15T07:42:00.000Z",
"count": 1
}
]
}{
"type": "bundle",
"id": "bundle--b92f4d1a-6c37-4e85-9a0d-7f1e5c3b8a24",
"objects": [
{
"type": "identity",
"spec_version": "2.1",
"id": "identity--8f2b8c1e-6a3d-4c58-9d7e-2b1f4a6c9e10",
"created": "2026-10-14T08:00:00.000Z",
"modified": "2026-10-14T08:00:00.000Z",
"name": "Example Threat Intel Team",
"identity_class": "organization"
},
{
"type": "indicator",
"spec_version": "2.1",
"id": "indicator--7d3e9a51-0c28-4b6f-9e14-a5c8f2b60d37",
"created_by_ref": "identity--8f2b8c1e-6a3d-4c58-9d7e-2b1f4a6c9e10",
"created": "2026-10-14T08:30:00.000Z",
"modified": "2026-10-14T08:30:00.000Z",
"name": "Payroll lure domain",
"description": "Domain used in phishing emails that imitate an HR payroll update.",
"indicator_types": ["malicious-activity"],
"pattern": "[domain-name:value = 'payroll-update-portal.example.com']",
"pattern_type": "stix",
"valid_from": "2026-10-12T00:00:00.000Z",
"valid_until": "2027-01-12T00:00:00.000Z",
"confidence": 70,
"external_references": [
{
"source_name": "Example Industry Advisory 2026-041",
"url": "https://example.com/advisories/2026-041"
}
],
"object_marking_refs": [
"marking-definition--34098fce-860f-48ae-8e50-ebd3cc5e41da"
]
},
{
"type": "campaign",
"spec_version": "2.1",
"id": "campaign--c4a1d7e2-5b39-4e8f-a6d0-3f7b92e1c845",
"created_by_ref": "identity--8f2b8c1e-6a3d-4c58-9d7e-2b1f4a6c9e10",
"created": "2026-10-14T08:30:00.000Z",
"modified": "2026-10-14T08:30:00.000Z",
"name": "Payroll Lure",
"first_seen": "2026-10-12T00:00:00.000Z",
"confidence": 50
},
{
"type": "attack-pattern",
"spec_version": "2.1",
"id": "attack-pattern--2b9e6f4a-1d73-4c0b-8e5a-6a7d3c9f1b22",
"created_by_ref": "identity--8f2b8c1e-6a3d-4c58-9d7e-2b1f4a6c9e10",
"created": "2026-10-14T08:30:00.000Z",
"modified": "2026-10-14T08:30:00.000Z",
"name": "Spearphishing Attachment",
"external_references": [
{
"source_name": "mitre-attack",
"external_id": "T1566.001",
"url": "https://attack.mitre.org/techniques/T1566/001/"
}
]
},
{
"type": "relationship",
"spec_version": "2.1",
"id": "relationship--e1a4c8b7-3f52-4d19-b6a8-0c9d7e2f5a41",
"created_by_ref": "identity--8f2b8c1e-6a3d-4c58-9d7e-2b1f4a6c9e10",
"created": "2026-10-14T08:30:00.000Z",
"modified": "2026-10-14T08:30:00.000Z",
"relationship_type": "indicates",
"source_ref": "indicator--7d3e9a51-0c28-4b6f-9e14-a5c8f2b60d37",
"target_ref": "campaign--c4a1d7e2-5b39-4e8f-a6d0-3f7b92e1c845"
},
{
"type": "relationship",
"spec_version": "2.1",
"id": "relationship--5c7f2a96-8b14-4e03-a9d5-1b6e3f8c0d72",
"created_by_ref": "identity--8f2b8c1e-6a3d-4c58-9d7e-2b1f4a6c9e10",
"created": "2026-10-14T08:30:00.000Z",
"modified": "2026-10-14T08:30:00.000Z",
"relationship_type": "uses",
"source_ref": "campaign--c4a1d7e2-5b39-4e8f-a6d0-3f7b92e1c845",
"target_ref": "attack-pattern--2b9e6f4a-1d73-4c0b-8e5a-6a7d3c9f1b22"
},
{
"type": "sighting",
"spec_version": "2.1",
"id": "sighting--a3d6e91c-7f08-4b25-8c4e-9e0b1a5d2f63",
"created_by_ref": "identity--8f2b8c1e-6a3d-4c58-9d7e-2b1f4a6c9e10",
"created": "2026-10-15T09:10:00.000Z",
"modified": "2026-10-15T09:10:00.000Z",
"sighting_of_ref": "indicator--7d3e9a51-0c28-4b6f-9e14-a5c8f2b60d37",
"where_sighted_refs": ["identity--8f2b8c1e-6a3d-4c58-9d7e-2b1f4a6c9e10"],
"first_seen": "2026-10-15T07:42:00.000Z",
"last_seen": "2026-10-15T07:42:00.000Z",
"count": 1
}
]
}Cómo leer este bundle STIX
Cada campo de ese bundle responde a una pregunta que un analista se hace antes de actuar. Esto es lo que hace cada uno.
El campo patternes la lógica de detección, escrita en el lenguaje de patrones de STIX. Aquí dice: coincide con cualquier nombre de dominio igual al dominio del señuelo de nómina. Las pasarelas de correo, los proxies y los SIEM pueden traducir ese patrón a sus propias consultas.
valid_from yvalid_until le dan al indicador una vida útil. Este está pensado para ser de confianza desde el 12 de octubre de 2026 hasta el 12 de enero de 2027, porque los dominios se reasignan y un indicador sin fecha de fin se convierte en una fábrica de falsos positivos.
confidencees un número de 0 a 100 establecido por el autor. El indicador tiene 70 y la campaña 50, lo que indica que el equipo confía más en el dominio que en la historia más grande que lo rodea.
created_by_refvincula cada objeto con la Identity que lo escribió, así que siempre sabes quién está haciendo la afirmación. external_references apunta al aviso original y, en el attack pattern, a la página de ATT&CK de la técnica, para que puedas verificar la fuente tú mismo en lugar de creerle a cualquiera.
object_marking_refsadjunta una etiqueta de manejo, aquí TLP:GREEN, que responde a la pregunta de con quién puedes compartirlo. Volvemos a esto más adelante.
relationship_type es el verbo que conecta dos objetos, como "indicates" o "uses". Sin él tienes un montón de hechos; con él tienes una historia.
Finalmente, sighting_of_refvincula una observación local con el indicador con el que coincidió. Fíjate en lo que una lista plana habría perdido: la campaña, la técnica, la fuente, qué tan seguros estaban y cuánto tiempo es válida la afirmación. Fíjate también en que el Sighting es un objeto separado, escrito por el equipo que lo vio. La evidencia local se sitúa junto al reporte externo en lugar de sobrescribirlo.
Si quieres probarlo, guarda el bundle como bundle.jsony analízalo con la biblioteca de Python stix2de OASIS. Rechaza los objetos mal formados, lo que la convierte en una verificación rápida de cualquier cosa que generes o recibas.
# pip install stix2
import stix2
with open("bundle.json") as f:
bundle = stix2.parse(f.read())
for obj in bundle.objects:
print(obj.type, obj.id)# pip install stix2
import stix2
with open("bundle.json") as f:
bundle = stix2.parse(f.read())
for obj in bundle.objects:
print(obj.type, obj.id)¿Qué es TAXII?
TAXII significa Trusted Automated Exchange of Intelligence Information. Es un protocolo para intercambiar información de amenazas cibernéticas, normalmente contenido STIX, entre sistemas. Piensa en STIX como un paquete cuidadosamente etiquetado y en TAXII como la ruta de entrega. TAXII puede automatizar el intercambio, pero no puede arreglar la información de mala calidad que hay dentro del paquete.
TAXII 2.x es una API REST simple sobre HTTPS. Un servidor publica collections de objetos STIX, agrupadas bajo uno o más API roots. Un cliente descubre lo que está disponible, elige una colección que tiene permitido leer y solicita objetos, normalmente filtrados por tipo o por fecha.
La conversación tiene cuatro pasos. Primero viene el descubrimiento: una petición GET a /taxii2/ devuelve el título del servidor y su lista de API roots. Segundo, el cliente le pide a un API root, por ejemplo /api1/, su título, las versiones de TAXII que soporta y el tamaño máximo de petición. Tercero, GET /api1/collections/ lista las colecciones, cada una con un ID, un título y si puedes leerla, escribir en ella, o ambas. Cuarto, GET /api1/collections/{id}/objects/ devuelve un envelope que contiene los propios objetos STIX.
Aquí está el paso 4 con curl. El encabezado Accept nombra la versión de TAXII, match[type] filtra por tipo de objeto STIX, y added_after devuelve solo lo que es nuevo desde tu última consulta. La opción -g evita que curl trate los corchetes como un rango.
curl -g -s \
-H "Accept: application/taxii+json;version=2.1" \
-u "analyst:$TAXII_PASSWORD" \
"https://taxii.example.com/api1/collections/91a7b528-80eb-42ed-a74d-c6fbd5a26116/objects/?match[type]=indicator&added_after=2026-10-01T00:00:00Z&limit=100"curl -g -s \
-H "Accept: application/taxii+json;version=2.1" \
-u "analyst:$TAXII_PASSWORD" \
"https://taxii.example.com/api1/collections/91a7b528-80eb-42ed-a74d-c6fbd5a26116/objects/?match[type]=indicator&added_after=2026-10-01T00:00:00Z&limit=100"La respuesta es un envelope. Cuando more es true, el valor next se incluye en la siguiente petición para obtener la página siguiente.
{
"more": false,
"objects": [
{
"type": "indicator",
"spec_version": "2.1",
"id": "indicator--7d3e9a51-0c28-4b6f-9e14-a5c8f2b60d37",
"pattern": "[domain-name:value = 'payroll-update-portal.example.com']",
"confidence": 70
}
]
}{
"more": false,
"objects": [
{
"type": "indicator",
"spec_version": "2.1",
"id": "indicator--7d3e9a51-0c28-4b6f-9e14-a5c8f2b60d37",
"pattern": "[domain-name:value = 'payroll-update-portal.example.com']",
"confidence": 70
}
]
}La mayoría de los equipos no escriben estas peticiones a mano. La biblioteca taxii2-client envuelve las mismas llamadas:
# pip install taxii2-client stix2
from taxii2client.v21 import Server, Collection
server = Server("https://taxii.example.com/taxii2/",
user="analyst", password="...")
for api_root in server.api_roots:
for c in api_root.collections:
print(c.id, c.title, "read:", c.can_read, "write:", c.can_write)
collection = Collection(
"https://taxii.example.com/api1/collections/91a7b528-80eb-42ed-a74d-c6fbd5a26116/",
user="analyst", password="...")
envelope = collection.get_objects(**{
"match[type]": "indicator",
"added_after": "2026-10-01T00:00:00Z",
})
for obj in envelope.get("objects", []):
print(obj["id"], obj.get("confidence"), obj["pattern"])# pip install taxii2-client stix2
from taxii2client.v21 import Server, Collection
server = Server("https://taxii.example.com/taxii2/",
user="analyst", password="...")
for api_root in server.api_roots:
for c in api_root.collections:
print(c.id, c.title, "read:", c.can_read, "write:", c.can_write)
collection = Collection(
"https://taxii.example.com/api1/collections/91a7b528-80eb-42ed-a74d-c6fbd5a26116/",
user="analyst", password="...")
envelope = collection.get_objects(**{
"match[type]": "indicator",
"added_after": "2026-10-01T00:00:00Z",
})
for obj in envelope.get("objects", []):
print(obj["id"], obj.get("confidence"), obj["pattern"])Publicar funciona en sentido contrario: un cliente con acceso de escritura envía un POST de un envelope a la misma ruta /objects/ y recibe un status resource que puede consultar para ver si cada objeto fue aceptado.
Una coincidencia es una pista, no un veredicto
Supón que un endpoint se conecta a un dominio incluido en una colección de inteligencia compartida. La coincidencia merece ser investigada, pero no significa automáticamente que el endpoint esté comprometido. El dominio puede haber cambiado de manos, haber sido clasificado erróneamente o estar alojado en infraestructura compartida con servicios legítimos.
Un buen flujo de trabajo mantiene el juicio junto con la evidencia. Cada paso a continuación corresponde a un campo que viste en el bundle de ejemplo:
- Revisa las fechas. ¿Cuándo fue creado el indicador, y está dentro de su ventana valid_from y valid_until? Un dominio señalado hace ocho meses puede haber sido revendido desde entonces.
- Rastréalo hasta su fuente original. Sigue created_by_ref y external_references. Varios informes pueden repetir una sola afirmación original, lo cual parece corroboración pero no lo es.
- Compáralo con la evidencia local. ¿Qué proceso hizo la conexión? ¿Qué pasó antes y después? Un Sighting que registres es la mitad local de la historia.
- Considera explicaciones benignas y el costo de bloquear. Sopesa el valor de confidence frente a lo que un bloqueo rompería, como un proveedor de alojamiento compartido o un proveedor de nómina.
- Elige una acción proporcionada: investigar, monitorear, bloquear o dejar el indicador de lado.
Para el indicador de ejemplo, un acierto en un registro de la pasarela de correo es una pista sólida. Se convierte en un hallazgo cuando el usuario hizo clic, el proxy muestra una descarga y el endpoint muestra un proceso de Office lanzando un script. Se convierte en un falso positivo cuando resulta ser la propia prueba de concientización de seguridad del equipo de RR. HH. La misma coincidencia lleva a acciones diferentes dependiendo de lo que diga la evidencia que la rodea.
Por eso la procedencia, las marcas de tiempo, la confianza y el contexto no son decoración opcional. Ayudan a los analistas a decidir cuánto vale hoy una pieza de inteligencia.
Compartir también necesita límites
Un intercambio útil respeta las restricciones de manejo y la privacidad. El Traffic Light Protocol (TLP) les dice a los destinatarios hasta dónde puede viajar una pieza de información. Es una convención de manejo, no cifrado ni un sistema de control de acceso. Los equipos aún necesitan verificar quién puede recibir la información y aplicar las políticas de su organización.
En STIX, una etiqueta TLP es un objeto al que apuntan otros objetos. El indicador de ejemplo lleva object_marking_refs que apunta a esta definición:
{
"type": "marking-definition",
"spec_version": "2.1",
"id": "marking-definition--34098fce-860f-48ae-8e50-ebd3cc5e41da",
"created": "2017-01-20T00:00:00.000Z",
"definition_type": "tlp",
"name": "TLP:GREEN",
"definition": { "tlp": "green" }
}{
"type": "marking-definition",
"spec_version": "2.1",
"id": "marking-definition--34098fce-860f-48ae-8e50-ebd3cc5e41da",
"created": "2017-01-20T00:00:00.000Z",
"definition_type": "tlp",
"name": "TLP:GREEN",
"definition": { "tlp": "green" }
}La etiqueta viaja con los datos, así que una herramienta posterior puede leerla y, si está construida para ello, filtrar o advertir. TLP 2.0 tiene cinco niveles. TLP:CLEAR significa que no hay restricción de divulgación. TLP:GREEN permite compartir dentro de la comunidad del destinatario pero no por canales públicos. TLP:AMBER limita el intercambio a la organización del destinatario y a los clientes que necesitan la información para actuar, y TLP:AMBER+STRICT lo reduce solo a la organización del destinatario. TLP:RED es solo para destinatarios nombrados, sin reenvío posterior.
Verifica qué versión de TLP implementa tu plataforma, porque las herramientas más antiguas todavía usan etiquetas de TLP 1.0 como TLP:WHITE.
Herramientas que usan STIX y TAXII: ATT&CK, MISP y OpenCTI
Rara vez usarás estos estándares por sí solos. Son el formato y el transporte comunes que conectan otras herramientas y comunidades.
MITRE ATT&CK es la base de conocimiento pública de tácticas y técnicas de los atacantes, y es de donde provienen los IDs de técnica como T1566.001. Los objetos Attack Pattern de STIX hacen referencia a esos IDs, como en nuestro ejemplo. MISP y OpenCTI son plataformas de código abierto para gestionar y compartir inteligencia de amenazas. MISP importa y exporta STIX y puede servir datos a clientes TAXII, mientras que OpenCTI está construido en torno al modelo de datos STIX 2 y tiene conectores para fuentes TAXII.
Las comunidades sectoriales también importan. Los ISAC e ISAO, los grupos de intercambio de industrias como la financiera o la de salud, a menudo operan servidores TAXII o publican feeds STIX para sus miembros, y muchos CERT gubernamentales publican avisos con acceso STIX o TAXII junto al informe legible por humanos.
Un patrón común los une: un feed TAXII entrega bundles STIX a una plataforma como MISP u OpenCTI, los analistas los enriquecen y revisan allí, y los indicadores aprobados se envían al SIEM o al EDR como detecciones.