Homelab SOC #17 - Construyendo el Dashboard Operacional del SOC
Por Wuilmer Bolívar · IT Operations Specialist
Hasta este momento de la serie, nos hemos centrado en la Fase 1 y 2: preparar la infraestructura, desplegar Wazuh, integrar agentes (Windows y Linux), configurar OPNsense y añadir Suricata como IDS.
Ahora que nuestra red está segmentada y generando eventos de seguridad, nos enfrentamos a un nuevo problema: el ruido. Tener miles de logs en bruto no equivale a tener seguridad. Un Centro de Operaciones de Seguridad (SOC) requiere visibilidad clara e inmediata.
Con este capítulo inauguramos oficialmente la Fase 3: Operación del SOC. Nuestro primer paso será construir la piedra angular de la observabilidad del analista: el Dashboard Operacional.
Utilizaremos OpenSearch Dashboards (integrado en Wazuh v4.14.6) para transformar datos crudos en inteligencia accionable.
Objetivo de este capítulo
La pregunta que responderemos será:
¿Cómo transformar los miles de eventos sin procesar de Wazuh en un panel visual, interactivo y estructurado jerárquicamente para la operación diaria?
Al finalizar este capítulo tendremos:
- Comprendida la escala de severidad de alertas (0-16) de Wazuh.
- KPIs dinámicos configurados por niveles de riesgo.
- Gráficos de tendencias temporales y distribución de agentes.
- Visualizaciones tácticas basadas en MITRE ATT&CK.
- Una tabla de alertas consolidada limpia y directa.
- Nuestro primer Dashboard Operacional completamente ensamblado.
Arquitectura visual del Dashboard
Para que un dashboard sea verdaderamente “operacional” y no solo un adorno, la clave es estructurar la información de manera jerárquica. La vista del analista debe ir de lo general a lo particular.
El diseño que implementaremos seguirá este flujo:
+---------------------------------------------------------------------------------------+
| [ Total Alertas ] [ Críticas ] [ Altas ] [ Medias ] [ Bajas / Informativas ] |
+---------------------------------------------------------------------------------------+
| [ Tendencia de Alertas (Línea de tiempo) ] | [ Top 10 Agentes Afectados (Barras) ] |
+---------------------------------------------------------------------------------------+
| [ Matriz / Top Tácticas MITRE (Donut) ] | [ Top Reglas Frecuentes (Tabla) ] |
+---------------------------------------------------------------------------------------+
| [ Tabla Consolidada de Alertas Recientes con Detalles Filtrados (Saved Search) ] |
+---------------------------------------------------------------------------------------+
- Nivel 1 (Arriba): KPIs inmediatos. ¿Cuántas alertas críticas tengo ahora mismo?
- Nivel 2 (Medio): Contexto temporal y espacial. ¿Cuándo ocurrieron los picos y qué máquinas están fallando?
- Nivel 3 (Medio-Bajo): Inteligencia táctica. ¿Qué técnicas (MITRE) están usando y qué reglas saltan más?
- Nivel 4 (Abajo): Los logs, filtrados y listos para investigar.
Entendiendo los niveles de severidad en Wazuh
Antes de crear nuestras métricas, debemos entender cómo clasifica Wazuh sus eventos. El sistema maneja una escala del 0 al 15 (llegando al 16 para reglas personalizadas muy específicas).
Para nuestro SOC, mapearemos los rangos (rule.level) de la siguiente manera usando el operador is between en OpenSearch:
| Categoría SOC | Rango Wazuh | Descripción Operativa |
|---|---|---|
| Informativas / Bajas | 0 - 7 | Eventos de rutina, telemetría o advertencias menores de bajo impacto. |
| Medias | 8 - 11 | Errores de configuración, intentos fallidos (fuerza bruta bloqueada). |
| Altas | 12 - 14 | Ataques detectados, evasión de defensas o anomalías críticas. |
| Críticas | 15 - 16 | Compromiso confirmado, malware activo o comportamiento de ransomware. |
Paso 1: Creando los KPIs (Visualización de Métricas)
Vamos a crear las tarjetas superiores. Nos dirigimos a Menu (☰) > Visualize > Create visualization y seleccionamos Metric.
Asegurándonos de usar el index pattern wazuh-alerts-*, configuramos lo siguiente para la tarjeta de alertas críticas:
- En el panel derecho (Metrics), dejamos la agregación por defecto en
Count. - En la barra superior, hacemos clic en + Add filter.
- Seleccionamos el campo
rule.level, operadoris between, con valores de 15 a 16. - Guardamos como
SOC - KPI - Critical Alerts.
Repetimos este proceso para el resto de niveles, ajustando únicamente los rangos numéricos del filtro.
Paso 2: Tendencias y Distribución
Para entender el comportamiento de la red, necesitamos contexto visual.
Tendencia de Alertas en el Tiempo
Esta gráfica nos mostrará picos anómalos.
- Tipo: Area Chart (o Line Chart).
- Y-Axis: Aggregation
Count. - X-Axis: Aggregation
Date Histogram, Fieldtimestamp, IntervalAuto. - Split series: Sub-aggregation
Terms, Fieldrule.level, Size10.
Top 10 Agentes
- Tipo: Horizontal Bar.
- Y-Axis: Aggregation
Terms, Fieldagent.name, Order byCount Descending.
Paso 3: Análisis Táctico y el error común del “Split Table”
Aquí construiremos las visualizaciones de inteligencia: el Top de Tácticas MITRE (con un Donut Chart agrupando por rule.mitre.tactic) y una tabla con las reglas más disparadas.
Al intentar construir la tabla (Data Table) agrupando por rule.id y rule.description, es muy común cometer un error que fragmenta la vista.
La forma correcta es:
- Bucket > Split rows >
Terms>rule.id - Añadir otro sub-bucket > Split rows >
Terms>rule.description.
Esto unifica todo en una sola tabla limpia.
Paso 4: La Tabla Consolidada (Discover)
El último componente de nuestro dashboard no se crea en la sección Visualize, sino en Discover. No queremos que los analistas vean todo el JSON (_source) por defecto, ya que es ilegible a primera vista.
Desde Discover, seleccionamos únicamente los Selected Fields que aportan valor inmediato:
@timestampagent.namerule.levelrule.descriptiondata.src_ipdata.dest_ip
Una vez configuradas las columnas, hacemos clic en Save (arriba a la derecha) y lo guardamos como SOC - Saved Search - Tabla de Alertas.
Ensamblando el Dashboard
Con todas las piezas construidas, nos vamos al apartado de Dashboards, creamos uno nuevo, y comenzamos a añadir (Add) nuestras visualizaciones guardadas.
La maquetación es puro arrastrar y soltar. Ajustamos los KPIs en una sola fila superior delgada, damos gran anchura a la gráfica de tiempo y colocamos las tablas en la zona inferior.
Estado actual del laboratorio
Con esta implementación hemos logrado:
- ✓ Comprender la integración de OpenSearch Dashboards.
- ✓ Mapear correctamente la severidad de Wazuh a métricas operativas.
- ✓ Crear 9 visualizaciones clave (Métricas, Gráficos y Tablas).
- ✓ Solucionar problemas de maquetación en agrupaciones de datos.
- ✓ Disponer de un Dashboard Operacional de SOC funcional y jerarquizado.
Tener visibilidad centralizada cambia por completo la experiencia de administrar la red. Ya no somos ciegos ante el tráfico que pasa por OPNsense o los eventos de nuestros servidores.
¿Qué sigue?
Con la observabilidad base ya establecida y nuestro Dashboard brillando en el monitor, es hora de poner a prueba el entorno.
En los próximos capítulos de esta Fase 3, nos enfocaremos en mejorar las capacidades de detección. Empezaremos a crear reglas personalizadas, casos de uso específicos y, muy pronto, lanzaremos simulaciones de ataques (como fuerza bruta o escaneos) para ver cómo nuestro nuevo panel reacciona en tiempo real.
Lo aprendido
En este capítulo dimos el salto fundamental de la infraestructura pura a la operación, aprendimos que los datos de seguridad sin procesamiento visual carecen de utilidad táctica.
Comprendimos el manejo de los Buckets y Aggregations en OpenSearch (una habilidad transferible a Elasticsearch y Kibana), asimilamos la estructura de severidad de Wazuh, y descubrimos cómo la maquetación estratégica de la información puede reducir drásticamente el tiempo que un analista tarda en identificar un incidente en medio del ruido constante de la red.