Building Your Own CTI Stack: Arquitectura Mínima Viable

Por qué construir tu propio stack CTI

Hay dos caminos para tener capacidad CTI operativa: comprar una plataforma comercial o construir tu propio stack con herramientas open source. La decisión no es trivial y depende de variables concretas.

Comprar tiene sentido cuando tu equipo no tiene experiencia técnica en despliegue de infraestructura, necesitas soporte 24/7 con SLA contractual, o el presupuesto permite licencias de 30.000-80.000 EUR/año (ThreatConnect, Anomali ThreatStream, Recorded Future).

Construir tiene sentido cuando necesitas control total sobre los datos (soberanía, ENS, RGPD), tu presupuesto no cubre licencias enterprise, quieres personalizar workflows específicos para tu sector, o ya tienes analistas con perfil técnico.

La realidad de la mayoría de SOCs medianos en España y Latinoamérica: el presupuesto no da para plataformas comerciales, pero sí hay talento técnico capaz de desplegar y mantener un stack open source. Este artículo es para ese escenario.

Qué resuelve un stack CTI propio

Un stack CTI operativo necesita cubrir cinco funciones:

1. Ingesta: recoger IOCs y reportes de múltiples fuentes.
2. Almacenamiento: persistir datos estructurados y buscables.
3. Enriquecimiento: añadir contexto automático a cada indicador.
4. Análisis: correlacionar, priorizar y producir inteligencia.
5. Acción: enviar detecciones al SIEM, EDR, firewall o equipo de respuesta.

Ninguna herramienta sola cubre las cinco. Por eso hablamos de stack.

---

Arquitectura mínima viable: los componentes

MISP: el corazón del stack

MISP (Malware Information Sharing Platform) es el estándar de facto para compartición de threat intelligence. Pero es mucho más que compartir: es tu base de datos central de IOCs y eventos.

Qué hace bien MISP:

• Ingesta de feeds (OSINT, comerciales, comunidades MISP).
• Taxonomías y galaxias (MITRE ATT&CK, threat actors, malware families).
• Correlación automática entre eventos.
• Exportación en múltiples formatos (STIX, CSV, Suricata, Snort, YARA).
• API REST completa para automatización.

Qué no hace bien:

• Gestión de casos/incidentes (no es un ITSM).
• Enriquecimiento automático de IOCs (necesita Cortex o scripts externos).
• Interfaz moderna (la UI funciona, pero no gana premios de UX).

Requisitos mínimos: 4 vCPU, 8 GB RAM, 100 GB SSD. Ubuntu 22.04 o Debian 12.

TheHive: gestión de casos e incidentes

TheHive complementa a MISP gestionando el flujo de trabajo cuando un IOC se convierte en algo que investigar. Es tu plataforma de case management.

Integración con MISP: TheHive puede importar eventos de MISP como alertas y crear casos a partir de ellos. También puede exportar observables de vuelta a MISP. La comunicación es bidireccional.

Funciones clave:

• Alertas desde MISP, SIEM, email u otras fuentes.
• Creación de casos con tareas asignables.
• Observables (IOCs) asociados a cada caso.
• Dashboards de métricas (casos abiertos, tiempo de resolución).
• API REST para automatización.

Requisitos mínimos: 4 vCPU, 8 GB RAM, 50 GB SSD. Java 11+. Puede compartir servidor con MISP si la carga es moderada.

Cortex: enriquecimiento automatizado

Cortex es el motor de análisis que conecta TheHive (y MISP) con servicios externos de enriquecimiento. Cuando un analista recibe un hash, IP o dominio, Cortex lo pasa por múltiples analizadores en paralelo.

Analizadores disponibles (selección):

• VirusTotal (hash, URL, dominio).
• AbuseIPDB (IP).
• Shodan (IP, dominio).
• MISP Warninglists (listas de exclusión).
• Yara (escaneo de ficheros).
• MaxMind GeoIP.
• PassiveTotal / RiskIQ.
• OTX AlienVault.

Por qué Cortex y no scripts propios: podrías escribir scripts que llamen a las APIs directamente. Cortex estandariza la interfaz, gestiona rate limits, cachea resultados y se integra nativamente con TheHive. Ahorra semanas de desarrollo.

Requisitos mínimos: 2 vCPU, 4 GB RAM. Puede correr en el mismo servidor que TheHive.

n8n: orquestación y automatización

n8n es el pegamento que conecta todo lo que no se conecta nativamente. Workflows visuales que reemplazan cron jobs y scripts sueltos.

Casos de uso en el stack CTI:

• Ingesta programada de feeds que MISP no soporta nativamente.
• Notificaciones a Slack/Telegram cuando llega un IOC crítico.
• Enriquecimiento adicional fuera de Cortex.
• Generación de reportes diarios/semanales.
• Integración con SIEM/EDR vía API.
• Deduplicación y normalización de datos entre fuentes.

Alternativas: Apache Airflow (más potente, más complejo), Shuffle SOAR (especializado en seguridad, menos maduro).

Requisitos mínimos: 2 vCPU, 2 GB RAM. Docker.

---

Diagrama de arquitectura

┌──────────────────────────────────────────────────────────┐
│                    CAPA DE INGESTA                        │
│  Feeds OSINT ─┐                                          │
│  MISP Communities ─┤                                     │
│  Feeds comerciales ─┤──► MISP ◄──► n8n (feeds custom)   │
│  Email/manual ─┘                                         │
└───────────────────────────┬──────────────────────────────┘
                            │ Eventos + IOCs
                            ▼
┌──────────────────────────────────────────────────────────┐
│                   CAPA DE ANÁLISIS                        │
│                                                           │
│  MISP (correlación) ──► TheHive (casos) ──► Cortex       │
│       │                      │              (enrichment)  │
│       │                      │                  │         │
│       ▼                      ▼                  ▼         │
│  Taxonomías              Tareas            VirusTotal     │
│  Galaxias ATT&CK         Asignación       AbuseIPDB      │
│  Warninglists            Métricas          Shodan         │
└───────────────────────────┬──────────────────────────────┘
                            │ Reglas + IOCs validados
                            ▼
┌──────────────────────────────────────────────────────────┐
│                    CAPA DE ACCIÓN                          │
│                                                           │
│  n8n ──► SIEM (Wazuh/Elastic)                            │
│      ──► EDR (actualización de blocklists)                │
│      ──► Firewall (IP blocklists)                        │
│      ──► Slack/Telegram (alertas)                        │
│      ──► Reportes (PDF/email)                            │
└──────────────────────────────────────────────────────────┘
                            │
                            ▼
┌──────────────────────────────────────────────────────────┐
│                  ALMACENAMIENTO                           │
│                                                           │
│  PostgreSQL (MISP + TheHive)                             │
│  Elasticsearch (opcional, búsqueda full-text)            │
│  Filesystem (muestras, reportes, exports)                │
└──────────────────────────────────────────────────────────┘

---

Capa de ingesta: feeds y fuentes

La ingesta es el primer cuello de botella. Sin datos de calidad, el stack más sofisticado produce basura.

Feeds OSINT recomendados para empezar

Feed	Tipo	Frecuencia	Formato
Abuse.ch (URLhaus, MalwareBazaar, ThreatFox)	IOCs	Cada hora	CSV, API
AlienVault OTX	IOCs + reportes	Continuo	STIX, API
CIRCL MISP feeds	Eventos MISP	Diario	MISP JSON
CISA KEV	Vulnerabilidades explotadas	Semanal	JSON
Botvrij.eu	IOCs europeos	Diario	MISP
Phishtank	URLs phishing	Cada hora	CSV
Feodo Tracker	C2 botnets	Cada 5 min	CSV
MalwareIntel	IOCs + contexto	Continuo	API, STIX

Estrategia de ingesta

No actives 30 feeds el primer día. Empieza con 5-8 feeds de alta calidad y añade progresivamente. Cada feed nuevo requiere:

1. Evaluar la calidad: tasa de falsos positivos, frescura, cobertura.
2. Configurar la ingesta: frecuencia, formato, filtros.
3. Asignar confianza: MISP permite asignar un nivel de confianza por fuente.
4. Monitorizar: ¿cuántos IOCs nuevos aporta? ¿Cuántos ya los tenías?

Un error común: activar todos los feeds disponibles y tener millones de IOCs sin capacidad de procesarlos. Más datos sin análisis es solo ruido.

---

Capa de análisis: de datos a inteligencia

Correlación en MISP

MISP correlaciona automáticamente atributos entre eventos. Si un IP aparece en un evento de phishing y en otro de distribución de malware, MISP lo marca. Esto es correlación pasiva.

Para correlación activa, configura:

• Warninglists: excluyen IPs/dominios legítimos (CDNs, Google, Microsoft) que generan falsos positivos.
• Taxonomías: etiquetado estandarizado (TLP, tipo de amenaza, sector afectado).
• Galaxias: mapeo a MITRE ATT&CK, threat actors, malware families.

Triage en TheHive

Cuando MISP genera una alerta, TheHive la recibe y el analista decide:

• Ignorar: falso positivo o irrelevante para el contexto.
• Crear caso: requiere investigación.
• Escalar: requiere respuesta inmediata.

El triage efectivo necesita contexto. Cortex aporta ese contexto automáticamente: un hash desconocido en VirusTotal tiene implicaciones diferentes a uno con 40 detecciones.

Enriquecimiento con Cortex

Configura Cortex para ejecutar analizadores automáticamente cuando TheHive recibe un observable nuevo. Prioriza:

1. Reputación: VirusTotal, AbuseIPDB (rápidos, alto valor).
2. Geolocalización: MaxMind (contexto geográfico del atacante).
3. Infraestructura: Shodan (puertos abiertos, servicios expuestos).
4. Histórico: PassiveTotal (resoluciones DNS pasadas).

No actives todos los analizadores para todos los tipos de observable. Un hash MD5 no necesita Shodan. Un dominio no necesita YARA.

---

Capa de acción: integración con el stack de seguridad

La inteligencia sin acción es un documento que nadie lee. La capa de acción conecta tu stack CTI con las herramientas que realmente bloquean amenazas.

Integración con SIEM (Wazuh / Elastic Security)

Wazuh acepta feeds de IOCs vía CDB lists. n8n puede exportar IOCs validados de MISP en formato CDB y actualizar Wazuh cada hora. Las reglas de Wazuh generan alertas cuando detectan coincidencias.

Elastic Security acepta threat intelligence vía Filebeat (módulo threatintel) o directamente desde MISP usando la integración nativa. Los IOCs alimentan indicator match rules que correlacionan contra logs en tiempo real.

Integración con EDR

La mayoría de EDRs (CrowdStrike, SentinelOne, Defender for Endpoint) aceptan custom IOCs vía API. n8n puede:

• Exportar hashes de MISP con confianza alta.
• Enviarlos al EDR como blocklist o watchlist.
• Recibir detecciones del EDR y crear alertas en TheHive.

Integración con firewalls

IPs maliciosas validadas pueden alimentar blocklists en firewalls (pfSense, FortiGate, Palo Alto). Automatiza con n8n: extrae IPs de MISP con confianza >= 70%, formatea según el firewall destino, actualiza vía API.

Precaución: nunca envíes IOCs sin validar directamente a blocklists de producción. Un falso positivo en el firewall bloquea tráfico legítimo.

---

Almacenamiento: PostgreSQL vs Elasticsearch

PostgreSQL: el mínimo necesario

MISP y TheHive usan PostgreSQL (o MySQL/MariaDB para MISP). Una sola instancia PostgreSQL puede servir a ambos.

Sizing inicial:

• Hasta 100K eventos MISP: 50 GB disco, configuración default.
• Hasta 500K eventos: 100 GB disco, ajustar shared_buffers y work_mem.
• Más de 500K: considerar Elasticsearch para búsquedas.

Backup obligatorio: pg_dump diario. Retención 30 días local + copia cifrada externa. Sin backup, un fallo de disco destruye meses de inteligencia acumulada.

Elasticsearch: cuándo añadirlo

Elasticsearch entra cuando:

• Las búsquedas full-text en MISP se vuelven lentas (>5 segundos).
• Necesitas dashboards analíticos complejos (Kibana).
• Integras con Elastic Security como SIEM.
• Superas el millón de atributos en MISP.

Requisitos: mínimo 8 GB RAM dedicados, 200 GB SSD. Es el componente más hambriento de recursos del stack.

---

Estimación de costes

Self-hosted (VPS o servidor dedicado)

Componente	Recurso	Coste mensual
Servidor principal (MISP + TheHive + Cortex)	8 vCPU, 16 GB RAM, 200 GB SSD	40-80 EUR
Servidor n8n	2 vCPU, 4 GB RAM, 50 GB SSD	10-20 EUR
Elasticsearch (opcional)	4 vCPU, 16 GB RAM, 500 GB SSD	40-60 EUR
APIs de enriquecimiento	VirusTotal Premium, Shodan	0-100 EUR
Total sin Elasticsearch		50-100 EUR/mes
Total con Elasticsearch		90-260 EUR/mes

Comparativa con soluciones comerciales

Solución	Coste anual	Incluye
Stack open source (self-hosted)	600-3.120 EUR	Todo configurable
ThreatConnect (starter)	~30.000 EUR	Plataforma + feeds básicos
Anomali ThreatStream	~50.000 EUR	Plataforma + feeds premium
Recorded Future	~80.000+ EUR	Plataforma + inteligencia premium

El ahorro es un orden de magnitud. El coste oculto es el tiempo de tu equipo para mantenerlo.

---

Roadmap de implementación: 4 semanas

Semana 1: MISP

• Día 1-2: Despliegue de MISP (Docker o instalación nativa).
• Día 3: Configuración de organización, usuarios y roles.
• Día 4: Activar 5 feeds OSINT iniciales (Abuse.ch, OTX, CIRCL, CISA KEV, Botvrij).
• Día 5: Configurar taxonomías (TLP, tipo de amenaza) y galaxias (ATT&CK).

Entregable: MISP recibiendo IOCs de 5 fuentes, con correlación automática activa.

Semana 2: TheHive + Cortex

• Día 1-2: Despliegue de TheHive y Cortex.
• Día 3: Integración MISP-TheHive (alertas automáticas).
• Día 4: Configurar 5 analizadores de Cortex (VirusTotal, AbuseIPDB, MaxMind, Shodan, MISP Warninglists).
• Día 5: Crear templates de caso (phishing, malware, C2).

Entregable: Pipeline MISP -> TheHive -> Cortex funcionando. Alertas generando casos con enriquecimiento automático.

Semana 3: Automatización con n8n

• Día 1-2: Despliegue de n8n. Workflows de ingesta para feeds que MISP no soporta.
• Día 3: Workflow de notificaciones (Slack/Telegram para IOCs críticos).
• Día 4: Workflow de exportación a SIEM/EDR.
• Día 5: Workflow de reporte diario automático.

Entregable: Automatización operativa. Notificaciones funcionando. Exportación a herramientas de detección activa.

Semana 4: Tuning y documentación

• Día 1-2: Ajustar warninglists (reducir falsos positivos).
• Día 3: Ajustar niveles de confianza por fuente.
• Día 4: Documentar procedimientos operativos (runbooks).
• Día 5: Prueba de carga y ajuste de rendimiento.

Entregable: Stack estable, documentado y en producción.

---

Consideraciones de escalado

Cuándo escalar

• Más de 1M IOCs: separar Elasticsearch en su propio servidor.
• Más de 5 analistas concurrentes: separar TheHive en servidor dedicado.
• Más de 50 feeds: considerar un servidor dedicado solo para ingesta.
• Requisitos de HA: replicación PostgreSQL + balanceo de carga.

Cuándo reconsiderar el approach

Si llegas al punto donde necesitas 3+ servidores dedicados, múltiples analistas a tiempo completo y soporte 24/7, el coste total (infra + personal) puede acercarse al de una solución comercial. En ese punto, reevalúa.

La ventaja del stack propio no desaparece con la escala (control, soberanía, personalización siguen), pero la ventaja de coste se reduce.

---

Errores comunes

1. Activar todos los feeds el primer día: resultado, millones de IOCs sin capacidad de procesarlos. Empieza con 5.
2. No configurar warninglists: resultado, alertas por tráfico a Google, Microsoft, Cloudflare. Ruido insoportable.
3. No asignar confianza por fuente: resultado, todos los IOCs tienen el mismo peso. Un hash de VirusTotal con 0 detecciones pesa igual que uno con 50.
4. Ignorar los backups: resultado, pierdes meses de inteligencia acumulada por un fallo de disco.
5. No documentar: resultado, solo una persona sabe cómo funciona. Si se va, el stack muere.

---

Recursos

• MISP Project (documentación oficial).
• TheHive Project (guías de instalación y uso).
• Cortex Analyzers (lista completa de analizadores).
• n8n (plataforma de automatización).
• MISP Training Materials (materiales de formación oficiales).
• MalwareIntel (feed CTI con contexto en español).
• Wazuh (SIEM open source compatible con el stack).