Construir un stack SOC open source con Wazuh, TheHive, Cortex y MISP: ensamblado vs integrado

Existe un stack SOC libre y de código abierto canónico, y ha sido más o menos los mismos cuatro nombres durante años: Wazuh para detección, TheHive para gestión de casos, Cortex para análisis de observables, MISP para inteligencia de amenazas. Los cuatro son proyectos maduros con años de uso en producción, y en conjunto cubren la mayor parte de lo que vende una suite SOC comercial. El problema está en la palabra conjunto. La integración entre las herramientas es un proyecto que usted construye y luego mantiene.

Esta guía cubre qué hace cada pieza, cuánto cuesta realmente ensamblarlas, cómo cambian los requisitos cuando usted opera la seguridad de más de una organización, y dónde encaja SocTalk, que se ubica encima de este stack y no en su lugar.

El stack SOC FOSS clásico

Wazuh es la capa SIEM/XDR: un agente en cada endpoint, un manager que aplica reglas de detección al flujo de eventos, y un indexador (basado en OpenSearch) que almacena y busca los resultados. Incluye de fábrica monitoreo de integridad de archivos, detección de vulnerabilidades, análisis de logs y un conjunto de reglas por defecto muy amplio. Es donde nacen las alertas.

TheHive es la capa de gestión de casos: una plataforma de respuesta a incidentes de seguridad donde las alertas se convierten en casos, los casos llevan tareas y observables, y los equipos de analistas colaboran con un registro de auditoría. Si Wazuh es donde nacen las alertas, TheHive es donde las investigaciones viven y mueren.

Cortex es el compañero de TheHive para el análisis de observables. Usted le entrega una IP, un hash, un dominio o una URL, y sus plugins analizadores consultan en paralelo servicios de reputación y sandbox, desde VirusTotal y AbuseIPDB hasta Hybrid Analysis y decenas más, y luego devuelven un veredicto. Convierte "aquí hay un hash" en "esto es lo que el mundo sabe sobre este hash".

MISP es la plataforma de inteligencia de amenazas: agrega, correlaciona y comparte indicadores de compromiso entre feeds y comunidades de intercambio. Consultar un observable contra MISP le dice si pertenece a una campaña o actor conocido, un contexto que ninguna de las otras tres herramientas aporta por sí sola.

Son cuatro herramientas que cubren cuatro trabajos distintos, todas open source, y en el papel un SOC completo.

El costo real de integración

Cada una de estas herramientas se instala en una tarde. Ahí terminan los tutoriales de laboratorio casero, y ahí empieza el trabajo real, porque ninguna habla con las otras de fábrica en la forma que un SOC de producción necesita.

El pegamento corre por su cuenta. Las alertas de Wazuh no se convierten en casos de TheHive sin un forwarder que usted escribe o adopta y luego mantiene a través de los cambios de API en ambos lados. Los analizadores de Cortex necesitan claves de API por proveedor, manejo de límites de tasa, y una decisión sobre qué analizador corre para cada tipo de observable. MISP necesita feeds configurados, trabajos de sincronización programados, e indicadores propensos a falsos positivos curados antes de que usted se atreva a automatizar sobre ellos.

Luego viene la superficie operativa: cuatro productos significan cuatro sistemas de autenticación y calendarios de rotación de claves de API, cuatro cadencias de actualización que pueden romper su pegamento en cualquier release, cuatro estrategias de respaldo, y, desde que TheHive pasó a usar Cassandra/Elasticsearch por debajo, una huella de almacenamiento de datos nada trivial solo para la gestión de casos. Sume TLS entre cada par, monitoreo para cada servicio, y la pregunta de a quién se le avisa cuando el forwarder de Wazuh a TheHive deja de reenviar en silencio.

Las herramientas en sí no tienen la culpa; esto es simplemente lo que implica componer proyectos independientes. La capa de integración equivale a un quinto producto, salvo que nadie lo distribuye, lo documenta ni lo actualiza por usted.

Una sola organización vs MSSP: la bifurcación de requisitos

Para una sola organización, el impuesto anterior es pagable. Usted construye el stack una vez, el pegamento sirve a un solo tenant, y un ingeniero capaz puede mantenerlo sano como trabajo de medio tiempo.

Para un MSP o MSSP, los requisitos se bifurcan con fuerza:

• El aislamiento no es negociable. Las alertas, casos e indicadores del cliente A deben ser demostrablemente invisibles para el cliente B, por contrato y a menudo por regulación. Las herramientas single-tenant compartidas convierten eso en un ejercicio de configuración por herramienta, con modos de falla por herramienta.
• Los stacks por cliente multiplican el impuesto. Diez clientes en stacks dedicados significan diez managers e indexadores de Wazuh que desplegar, actualizar y respaldar, más diez copias de su pegamento.
• El onboarding debe ser repetible. El cliente número once debería tomar un comando y no una semana de arqueología en la wiki. Los stacks construidos a mano derivan, y esa deriva tarde o temprano aparece como un incidente.
• Un solo panel. Los analistas que cubren veinte clientes no pueden rotar entre veinte dashboards.

Esta es la brecha entre "el stack SOC FOSS funciona" y "el stack SOC FOSS funciona como negocio".

Dónde encaja SocTalk: un plano de control encima del stack

SocTalk deja las cuatro herramientas en su lugar. Es un plano de control multi-tenant con licencia Apache 2.0 y una capa de triaje con AI construida alrededor de este stack, para MSPs y MSSPs que lo ejecutan en su propio Kubernetes:

• Wazuh es el plano de datos. Cada cliente recibe un manager y un indexador de Wazuh dedicados en un namespace aislado, aprovisionados por el plano de control, o usted trae un Wazuh existente mediante el perfil provided. Los agentes se enrolan por un ingress enrutado por hostname con secretos con alcance de tenant.
• La capa de triaje con AI se ubica entre Wazuh y sus analistas. Un embudo de ingesta determinista deduplica, agrupa y correlaciona alertas antes de que corra cualquier modelo; un loop agéntico de LangGraph investiga lo que sobrevive; las escalaciones siempre pasan por una compuerta de revisión humana. Los detalles están en Cómo funciona.
• TheHive, Cortex y MISP son integraciones, consultadas durante la ejecución: Cortex para reputación de observables, MISP para contexto de inteligencia de amenazas, TheHive como destino de exportación de los casos escalados.
• La maquinaria multi-tenant es el producto: aislamiento por namespace con NetworkPolicy de Cilium, seguridad a nivel de fila de Postgres como respaldo de datos, una máquina de estados del ciclo de vida del tenant, y configuración de LLM por tenant.

Conozca la superficie de integración de V1 antes de planificar en torno a ella:

• La exportación a TheHive es opcional y síncrona: el worker llama a la API de TheHive en el momento del nodo del grafo, creando el caso y los observables. No hay outbox, no hay loop de reintentos, y no hay subchart de TheHive incluido; si TheHive no está accesible, la falla se registra y el caso continúa solo en SocTalk.
• Cortex es exclusivamente gestionado por el cliente en V1. Usted opera Cortex por su cuenta y SocTalk lo llama. No hay subchart incluido; la selección de analizadores usa un mapa fijo en el código, y las llamadas fallidas no son fatales para la ejecución.
• Las consultas a MISP corren en el misp_worker del pipeline contra su instancia de MISP; un subchart de MISP incluido queda diferido a una versión futura.
• El código de notificaciones y aprobación bidireccional por Slack existe en el repositorio pero no está conectado al runtime del chart de V1. La cola de revisión del dashboard es hoy la superficie funcional de human-in-the-loop.

SocTalk empaqueta el plano Wazuh multi-tenant y la capa de triaje, y se conecta a las instancias de TheHive/Cortex/MISP que usted opera. La conveniencia de los subcharts incluidos sigue en la hoja de ruta; esta versión no la incluye.

Cuándo construir el stack usted mismo, y cuándo desplegar SocTalk

Ambos caminos son open source, así que la elección depende de criterios operativos:

Arme el stack de cuatro herramientas por su cuenta cuando usted es una sola organización con tiempo de ingeniería, quiere control máximo sobre cada componente, su volumen de alertas es manejable para su dotación de analistas, y la multi-tenencia es irrelevante. El stack clásico más su propio pegamento es un patrón probado, y usted entenderá cada cable porque lo soldó usted mismo.

Considere SocTalk cuando usted es un MSP/MSSP que necesita stacks de Wazuh por cliente repetibles detrás de un solo plano de control, aislamiento de tenants demostrable, y triaje con AI que comprime el volumen de alertas antes de que los analistas lo vean, y prefiere operar una plataforma gestionada con Helm en lugar de N stacks construidos a mano. Usted sigue operando Kubernetes, y en V1 sigue operando sus propios TheHive, Cortex y MISP si los quiere.

La forma más rápida de evaluar es la VM de demo: una imagen, un asistente en el navegador, unos cinco minutos hasta una instalación multi-tenant en funcionamiento con un tenant de demo incorporado. Desde ahí, Cómo funciona explica el pipeline, y las páginas de TheHive y Cortex documentan exactamente qué hacen y qué no hacen las integraciones de V1, para que pueda planificar el resto de su stack en torno a ellas.