El periodo analizado comprende del 14 al 21 de agosto de 2026. Durante estos siete días, Microsoft 365 generó 14 eventos relevantes de seguridad, mientras que no se registraron detecciones Windows de alta confianza, eventos críticos de Kaspersky, eventos relevantes en el perímetro SonicWall/UniFi ni correlaciones multisource confirmadas.
Además, la plataforma permaneció OPERATIVA, con el clúster Wazuh en estado GREEN y todos los servicios principales activos.
Sin embargo, el objetivo de un SIEM no es simplemente almacenar grandes cantidades de información.
El verdadero valor consiste en centralizar, correlacionar, contextualizar y revisar los eventos para detectar aquello que realmente necesita atención.
SIEM Wazuh en empresas: 184.832 registros en una semana
Durante la semana 34, el volumen de telemetría analizado fue:
- Windows: 5.005 registros
- SonicWall: 138.458 registros
- UniFi: 11.328 registros
- Kaspersky: 11.106 registros
- Microsoft 365: 18.935 registros
En total:
184.832 registros de seguridad y actividad analizados durante siete días.
Cada una de estas fuentes aporta una perspectiva diferente.
Windows muestra actividad de los endpoints.
SonicWall proporciona visibilidad sobre el perímetro.
UniFi aporta información de red.
Kaspersky registra eventos relacionados con protección endpoint.
Microsoft 365 permite analizar actividad de identidad, correo, colaboración y acceso cloud.
Por tanto, el SIEM Wazuh en empresas permite reunir esas fuentes para disponer de una visión mucho más completa.
¿Qué aporta un SIEM Wazuh en empresas?
Una infraestructura empresarial moderna genera miles de registros cada día.
Un firewall produce eventos.
Windows genera registros.
Microsoft 365 registra inicios de sesión, cambios y acciones administrativas.
El antivirus genera sus propias detecciones.
Además, switches, puntos de acceso, servidores, NAS y otros sistemas pueden aportar información adicional.
Sin una plataforma centralizada, cada fuente permanece aislada.
En cambio, Wazuh permite recopilar, analizar y almacenar logs de endpoints, aplicaciones y dispositivos de red. Su documentación oficial explica que el análisis de logs puede utilizarse para detección de amenazas, monitorización, resolución de incidencias y auditoría. Documentación oficial de análisis de logs de Wazuh.
Microsoft 365 generó 18.935 registros durante la semana
Microsoft 365 representó una parte importante de la actividad analizada durante la semana 34.
El desglose fue:
- Exchange Online: 5.451
- SharePoint Online: 3.334
- OneDrive for Business: 330
- Microsoft Entra ID: 9.813
- Microsoft Teams: 5
- Otros servicios: 2
En total:
18.935 eventos únicos de Microsoft 365.
Además, el volumen fue significativamente superior al de la semana anterior, cuando se registraron 9.806 eventos.
Sin embargo, un aumento de registros no implica necesariamente un aumento equivalente del riesgo.
Puede deberse a más actividad, cambios administrativos, procesos internos o variaciones en las fuentes de auditoría.
Por eso el contexto es imprescindible.
SIEM Wazuh en empresas y 14 eventos relevantes de Microsoft 365
De los miles de registros generados por Microsoft 365, 14 eventos fueron clasificados como relevantes para revisión de seguridad.
Entre ellos aparecieron actividades relacionadas con:
- cambios de políticas de Acceso Condicional;
- modificaciones de service principals;
- actividad administrativa de Exchange;
- primer inicio de sesión interactivo observado desde un nuevo dispositivo.
El hecho de que un evento aparezca marcado como relevante o crítico no significa automáticamente que exista una intrusión.
Una modificación administrativa legítima puede activar exactamente la misma regla que un cambio realizado por un atacante.
Por ello, nuestro SOC revisa:
- quién realizó la acción;
- qué recurso fue modificado;
- cuándo ocurrió;
- desde dónde;
- qué otros eventos coinciden;
- si la modificación estaba prevista.
Las alertas necesitan contexto
Una alerta puede decir:
“Política de Acceso Condicional modificada.”
Eso es información importante.
Sin embargo, todavía falta responder:
¿Quién realizó el cambio?
¿Era un administrador autorizado?
¿Formaba parte de una tarea planificada?
¿Existieron otros eventos relacionados?
Por eso un SIEM no debería convertirse simplemente en una máquina que genera alertas.
Debe ayudar a construir contexto.
SIEM Wazuh en empresas y Acceso Condicional
Durante la semana aparecieron eventos relacionados con modificaciones de políticas de Acceso Condicional.
Este tipo de cambios merece supervisión porque las políticas pueden controlar:
- desde qué países se accede;
- qué dispositivos están permitidos;
- si se exige MFA;
- si el dispositivo debe estar administrado;
- qué aplicaciones pueden utilizarse.
Por tanto, una modificación no autorizada podría reducir la seguridad de una organización.
Sin embargo, una modificación realizada por un administrador durante una tarea de mantenimiento es completamente diferente.
La alerta identifica el cambio.
El análisis determina su significado.
Modificaciones de service principals
También se registraron eventos relacionados con modificaciones de service principals en Microsoft Entra ID.
Los service principals representan identidades utilizadas por aplicaciones y servicios.
Por ello, las modificaciones sobre estos objetos pueden resultar relevantes para la seguridad.
Sin embargo, también pueden formar parte de procesos perfectamente legítimos.
Por ejemplo:
- Intune;
- aplicaciones empresariales;
- integraciones;
- automatizaciones;
- servicios de Microsoft.
Por tanto, el contexto vuelve a ser fundamental.
Primer inicio de sesión desde un nuevo dispositivo
Otra de las reglas personalizadas detectó el primer inicio de sesión interactivo observado desde un nuevo deviceId.
Este tipo de alerta puede resultar útil porque permite detectar rápidamente cuando una identidad aparece asociada a un dispositivo que no había sido observado previamente.
Sin embargo, nuevamente:
nuevo dispositivo no significa dispositivo malicioso.
Puede tratarse de:
- renovación de equipo;
- nuevo portátil;
- reinstalación;
- dispositivo corporativo recién incorporado;
- cambio legítimo de hardware.
Por eso el SOC analiza el conjunto antes de decidir si existe riesgo.
Microsoft 365 necesita monitorización
Muchas empresas siguen considerando Microsoft 365 únicamente como:
correo + Word + Excel + Teams.
Sin embargo, desde el punto de vista de seguridad también contiene información relacionada con:
- identidades;
- autenticación;
- accesos;
- cambios administrativos;
- aplicaciones;
- SharePoint;
- OneDrive;
- Exchange;
- Teams.
Microsoft explica que los logs de auditoría son importantes para mantener, investigar y proteger los entornos Microsoft 365. Microsoft Learn: Microsoft 365 audit log collection.
Por tanto, centralizar esta información mejora considerablemente la capacidad de análisis.
SIEM Wazuh en empresas y Microsoft Entra ID
Microsoft Entra ID es una de las fuentes más importantes para detectar actividad relacionada con identidad.
Durante la semana 34 aportó 9.813 eventos únicos.
Estos registros pueden ayudar a analizar:
- inicios de sesión;
- cambios administrativos;
- aplicaciones;
- identidades;
- modificaciones de directorio;
- políticas.
Además, Microsoft explica que los logs de auditoría de Entra permiten revisar actividades relacionadas con recursos de directorio y diferentes servicios de Microsoft 365. Microsoft Learn: logs de auditoría de Microsoft Entra ID.
138.458 registros de SonicWall
SonicWall fue nuevamente la fuente con mayor volumen de telemetría durante la semana:
138.458 registros.
Aquí es importante diferenciar funciones.
SonicWall genera y registra los eventos.
Nuestro SOC de GHM Soluciones Informáticas analiza posteriormente esos logs y su contexto.
El firewall puede registrar información relacionada con:
- conexiones;
- bloqueos;
- accesos;
- amenazas;
- escaneos;
- servicios;
- tráfico.
Sin embargo, miles de eventos no significan miles de ataques.
Buena parte forma parte de la actividad habitual de cualquier conexión empresarial a Internet.
SIEM Wazuh en empresas y firewall
Integrar el firewall dentro del SIEM Wazuh en empresas permite conservar y consultar su actividad junto con otras fuentes.
Esto permite responder preguntas como:
- ¿qué IP intentó conectar?
- ¿qué puerto utilizó?
- ¿la conexión fue permitida o descartada?
- ¿apareció la misma IP anteriormente?
- ¿existe actividad relacionada en Windows?
- ¿hubo un inicio de sesión coincidente?
- ¿el antivirus generó alguna alerta?
Cada log aislado cuenta una pequeña parte.
La correlación puede mostrar una historia completa.
11.328 registros de UniFi
La infraestructura UniFi aportó 11.328 registros durante la semana 34.
Además, el informe no registró eventos semanales de pérdida de paquetes dentro del indicador de salud de red.
La monitorización de red puede incluir:
- switches;
- puntos de acceso;
- gateways;
- conexiones;
- cambios;
- eventos operativos.
De este modo, el SIEM puede incorporar también información sobre el estado de la infraestructura de comunicaciones.
SIEM Wazuh en empresas y redes
La seguridad no empieza y termina en el ordenador.
También depende de la red.
Por ejemplo:
Un endpoint puede mostrar actividad anómala.
Sin embargo, el firewall puede aportar información sobre su conexión exterior.
A continuación, el switch puede indicar desde qué segmento se produjo.
Finalmente, Microsoft 365 puede mostrar actividad relacionada con la misma identidad.
Por tanto, combinar fuentes aumenta considerablemente el contexto disponible.
11.106 registros de Kaspersky
Kaspersky generó 11.106 registros durante la semana.
Además, no se registraron eventos críticos dentro del resumen semanal.
Este punto vuelve a demostrar que el volumen de logs y el volumen de incidentes son conceptos diferentes.
Miles de registros pueden formar parte de:
- funcionamiento del agente;
- actualizaciones;
- actividad del endpoint;
- eventos informativos;
- controles de seguridad.
Nuestro SOC analiza las señales relevantes cuando aparecen.
SIEM Wazuh en empresas y Endpoint / EDR
La protección endpoint permite observar lo que ocurre dentro de los equipos.
Mientras el firewall observa comunicaciones de red, el endpoint puede aportar información sobre:
- procesos;
- archivos;
- aplicaciones;
- detecciones;
- comportamiento.
Combinar ambos puntos de vista mejora el análisis.
Por ejemplo:
Firewall: conexión hacia una IP sospechosa.
Endpoint: proceso que generó la conexión.
Microsoft 365: identidad relacionada.
SIEM: correlación entre las fuentes.
Esta es una de las principales ventajas de centralizar la telemetría.
Windows generó 5.005 registros
Windows aportó 5.005 registros durante la semana 34.
El resumen semanal no identificó detecciones Windows de alta confianza.
Sin embargo, esto no significa que Windows no genere información útil.
Los registros del sistema operativo pueden aportar contexto sobre:
- inicios de sesión;
- servicios;
- procesos;
- cambios;
- errores;
- eventos de seguridad;
- actividad administrativa.
Además, las reglas personalizadas pueden utilizar esta información para buscar patrones específicos de cada infraestructura.
Cero correlaciones Windows / SonicWall
Durante la semana 34 no se detectaron correlaciones multisource confirmadas entre Windows y SonicWall.
Esto es igualmente importante.
Un sistema de correlación no tiene como objetivo generar alertas constantemente.
Debe avisar cuando se cumplen condiciones concretas.
Por ejemplo:
evento Windows + conexión firewall + mismo origen/destino + ventana temporal determinada
Si las condiciones no coinciden, no debería forzarse una alerta.
Por tanto, cero correlaciones también es un resultado válido.
Cero correlaciones Microsoft 365 / endpoint
El correlador entre Microsoft 365 y endpoint tampoco produjo correlaciones confirmadas durante la semana.
Sin embargo, mantener esta capacidad activa permite detectar escenarios más complejos.
Por ejemplo:
- inicio de sesión anómalo;
- actividad en endpoint;
- conexión de red;
- detección antivirus.
Por separado pueden ser señales débiles.
Juntas pueden convertirse en una incidencia relevante.
SIEM Wazuh en empresas y correlaciones personalizadas
Cada empresa tiene una infraestructura diferente.
Una asesoría no utiliza exactamente las mismas aplicaciones que una ingeniería.
Un despacho de abogados tiene necesidades distintas de una constructora.
Por tanto, las reglas de monitorización también pueden adaptarse.
En nuestros servicios utilizamos correlaciones personalizadas según la infraestructura para buscar relaciones entre eventos que sean relevantes para cada entorno.
Por ejemplo:
- Microsoft 365 + endpoint;
- Windows + firewall;
- identidad + dispositivo;
- antivirus + red;
- cambios administrativos + usuario.
Esto permite reducir ruido y mejorar el contexto.
Alertas personalizadas de indicadores de compromiso
El SIEM Wazuh en empresas también puede utilizar reglas personalizadas para detectar indicadores de compromiso.
Por ejemplo:
- direcciones IP;
- dominios;
- comportamientos;
- eventos;
- secuencias;
- patrones de conexión.
Sin embargo, detectar un indicador tampoco demuestra automáticamente un compromiso.
Puede ser necesario comprobar:
- origen;
- destino;
- contexto;
- reputación;
- frecuencia;
- equipo implicado.
De nuevo, la tecnología genera información.
El SOC la interpreta.
El SOC analiza los logs
Esta diferencia es fundamental en nuestro servicio.
Un firewall genera registros.
Microsoft 365 genera auditoría.
Windows genera eventos.
Kaspersky genera detecciones.
UniFi genera telemetría.
Wazuh centraliza y procesa esa información.
Después, nuestro SOC de GHM Soluciones Informáticas analiza los logs, revisa el contexto y determina qué situaciones requieren atención o investigación.
Por tanto, no se trata simplemente de instalar un programa.
Se trata de convertir datos técnicos en información útil.
¿Por qué almacenar 400 días de logs?
Una incidencia no siempre se descubre el mismo día en que comienza.
Imaginemos que hoy detectamos un comportamiento sospechoso.
La pregunta inmediatamente puede ser:
¿Cuándo apareció por primera vez?
Después:
¿Qué ocurrió antes?
¿Se conectó a otros equipos?
¿Hubo accesos similares meses atrás?
Si los registros antiguos ya no existen, responder será mucho más difícil.
Por eso en nuestros servicios mantenemos hasta 400 días de histórico de logs.
SIEM Wazuh en empresas y 400 días de histórico
Mantener 400 días de logs permite realizar investigaciones retrospectivas.
Por ejemplo, podemos revisar:
- conexiones anteriores;
- cambios administrativos;
- accesos;
- eventos de endpoints;
- actividad de Microsoft 365;
- alertas de firewall.
Además, el histórico puede resultar especialmente útil para:
- incidentes;
- auditorías;
- cumplimiento;
- análisis forense;
- revisión de tendencias.
Wazuh permite recopilar y almacenar registros procedentes de endpoints, aplicaciones y dispositivos de red. Documentación oficial de Wazuh sobre recopilación y análisis de logs.
Un SIEM no sirve únicamente cuando existe un ataque
Existe la idea de que un SIEM solamente resulta útil durante un ciberataque.
Sin embargo, también puede ayudar a investigar:
- fallos;
- cambios;
- accesos;
- comportamiento;
- problemas operativos;
- auditorías.
Por ejemplo, si un administrador realiza una modificación legítima de Acceso Condicional, el evento puede quedar registrado.
Meses después, ese histórico puede ayudar a explicar cuándo se produjo el cambio.
Estado de Wazuh durante la semana 34
La plataforma permaneció OPERATIVA durante el periodo analizado.
El estado al cierre del informe fue:
- Clúster: GREEN
- Shards: 461
- Memoria del servidor: 23,8 %
- Disco utilizado: 15,8 %
- UniFi Packet Loss: 0 eventos semanales
Además, permanecían activos:
- wazuh-manager;
- wazuh-indexer;
- wazuh-dashboard;
- filebeat;
- postfix.
Por tanto, la infraestructura SIEM se encontraba operativa y con recursos disponibles.
¿Por qué monitorizar el propio SIEM?
Porque la herramienta de monitorización también necesita ser monitorizada.
No serviría de mucho tener miles de dispositivos enviando información si:
- el almacenamiento estuviera lleno;
- el indexador hubiera fallado;
- Filebeat estuviera detenido;
- el dashboard no respondiera.
Por eso también controlamos el estado de los propios componentes de Wazuh.
SIEM Wazuh en empresas para Windows, macOS y Linux
Wazuh puede recopilar información de diferentes sistemas operativos.
Entre ellos:
- Windows;
- macOS;
- Linux.
Esto facilita utilizar una misma plataforma en empresas que mantienen entornos heterogéneos.
La documentación oficial de Wazuh describe la recopilación de logs desde estos sistemas mediante agentes y otros métodos. Wazuh: recopilación de logs.
Por tanto, una empresa no necesita limitar la monitorización a un único fabricante o sistema operativo.
Servidores también necesitan monitorización
Los servidores suelen concentrar algunos de los activos más importantes.
Por ejemplo:
- archivos;
- aplicaciones;
- bases de datos;
- usuarios;
- servicios.
Por ello, analizar su actividad puede ayudar a detectar:
- accesos;
- errores;
- cambios;
- comportamientos inesperados;
- problemas de servicio.
Además, un evento de servidor puede correlacionarse con una conexión del firewall o con actividad en otro endpoint.
NAS y almacenamiento empresarial
Los sistemas NAS también pueden contener información crítica.
Por ejemplo:
- copias;
- documentación;
- proyectos;
- archivos compartidos.
En algunos entornos funcionan prácticamente como servidores.
Por ello, conviene incluir su actividad dentro de la estrategia de seguridad siempre que la plataforma y el dispositivo permitan obtener la telemetría necesaria.
Switches y puntos de acceso
La red también genera información importante.
Un switch puede indicar eventos de conectividad.
Un punto de acceso puede aportar información sobre dispositivos inalámbricos.
Un firewall controla el perímetro.
Cada componente ofrece una visión distinta.
Por tanto, cuanto mayor sea la integración, mayor será el contexto disponible durante una investigación.
SIEM Wazuh en empresas y auditorías
Los logs también tienen valor fuera de un incidente.
Durante una auditoría puede ser necesario demostrar:
- existencia de registros;
- actividad administrativa;
- cambios;
- eventos;
- controles;
- trazabilidad.
Mantener histórico facilita enormemente esta tarea.
Además, permite revisar periodos anteriores sin depender de que el evento continúe disponible en la plataforma original.
¿Qué ocurre si solo guardamos logs durante 30 días?
Imaginemos que una incidencia se descubre 90 días después.
Si solo conservamos 30 días, gran parte de la evidencia ya habrá desaparecido.
En cambio, con un histórico más amplio podemos retroceder.
Por eso mantener hasta 400 días de logs ofrece una ventaja importante para investigaciones que no comienzan inmediatamente.
El volumen no determina el nivel de riesgo
Esta semana se analizaron 184.832 registros.
Sin embargo, solo Microsoft 365 produjo 14 eventos destacados dentro del resumen de seguridad.
Además, no hubo detecciones Windows de alta confianza, eventos críticos de Kaspersky ni eventos relevantes de perímetro.
Esto demuestra una idea fundamental:
184.832 registros no significan 184.832 amenazas.
El SIEM procesa grandes cantidades de actividad para ayudar a localizar las pocas señales que merecen atención.
SIEM Wazuh en empresas y reducción del ruido
Uno de los problemas de la seguridad moderna es el exceso de información.
Si una persona recibe miles de alertas cada día, terminará ignorándolas.
Por ello, una estrategia correcta debe:
- clasificar;
- filtrar;
- correlacionar;
- contextualizar;
- priorizar.
El objetivo es que el equipo de seguridad pueda concentrarse en aquello que realmente importa.
¿Qué aporta nuestro SOC?
La tecnología automatiza una parte muy importante del proceso.
Sin embargo, todavía existen preguntas que necesitan contexto.
Por ejemplo:
¿Ese cambio estaba previsto?
¿Ese inicio de sesión pertenece al usuario?
¿Ese nuevo dispositivo es corporativo?
¿Esa IP forma parte de un proveedor legítimo?
¿Existe actividad relacionada?
Nuestro SOC revisa estas situaciones y las contrasta con el contexto disponible.
SIEM Wazuh en empresas para Microsoft 365
Microsoft 365 puede generar miles de eventos semanales.
En esta semana fueron 18.935.
Sin una estrategia de monitorización, muchos cambios pueden permanecer únicamente dentro de los propios portales.
Centralizarlos facilita:
- búsquedas;
- correlaciones;
- reglas personalizadas;
- histórico;
- análisis.
Además, las alertas pueden adaptarse a los riesgos concretos de la organización.
Ejemplo: cambio de Acceso Condicional
Imaginemos que alguien modifica una política que restringe los accesos desde determinados países.
El cambio puede ser legítimo.
Sin embargo, también podría formar parte de un intento de reducir la seguridad después de comprometer una cuenta administrativa.
La alerta por sí sola no responde.
Por eso necesitamos analizar:
actor + momento + política + actividad anterior + actividad posterior
Este es el tipo de contexto que un SIEM puede ayudar a reconstruir.
Ejemplo: nuevo dispositivo
Un usuario inicia sesión desde un dispositivo no observado previamente.
Puede ser un nuevo portátil.
Pero también puede tratarse de un acceso que merece revisión.
Por eso una regla personalizada puede avisar en el primer caso observado.
Después, el SOC comprueba el contexto antes de clasificarlo.
SIEM Wazuh en empresas para despachos profesionales
Administraciones de fincas, asesorías contables, asesorías laborales, despachos de abogados y otros profesionales manejan información especialmente sensible.
Por ejemplo:
- DNI;
- nóminas;
- información fiscal;
- cuentas bancarias;
- documentos;
- certificados;
- correo.
En estos entornos, tener únicamente antivirus ya no proporciona toda la visibilidad necesaria.
También conviene saber qué está ocurriendo en:
- Microsoft 365;
- firewall;
- endpoints;
- servidores;
- red.
Arquitectura, construcción e ingeniería
Las empresas de arquitectura, interiorismo, construcción e ingeniería pueden manejar grandes cantidades de documentación y proyectos.
Además, suelen utilizar:
- servidores;
- NAS;
- VPN;
- Microsoft 365;
- software especializado;
- almacenamiento cloud.
Por tanto, una incidencia puede afectar tanto a la seguridad como a la continuidad de los proyectos.
La monitorización ayuda a disponer de mayor contexto cuando aparece una anomalía.
SIEM Wazuh en empresas y respuesta a incidentes
Cuando se produce un incidente, una de las primeras necesidades es reconstruir qué ocurrió.
Por ejemplo:
¿Cuál fue el primer evento?
¿Qué usuario participó?
¿Qué equipo estaba implicado?
¿Qué conexiones se produjeron?
¿Hubo cambios administrativos?
¿Qué ocurrió posteriormente?
Los logs proporcionan las piezas necesarias para intentar responder.
Por eso almacenarlos y correlacionarlos tiene un valor especialmente importante durante una investigación.
Un firewall no sustituye al endpoint
El firewall puede controlar el tráfico.
Sin embargo, no conoce todo lo que ocurre dentro del equipo.
El endpoint sí puede aportar esa perspectiva.
Del mismo modo, el endpoint no dispone de toda la información de Microsoft 365.
Por eso una estrategia de seguridad por capas resulta mucho más completa.
Endpoint, firewall, Microsoft 365 y SIEM
Cada tecnología tiene una función.
Firewall: controla y registra comunicaciones.
Endpoint / EDR: protege y supervisa dispositivos.
Microsoft 365: genera información sobre identidad y actividad cloud.
SIEM Wazuh: centraliza y correlaciona.
SOC: analiza y contextualiza.
Por tanto, no existe una única solución que sustituya al resto.
La seguridad necesita visibilidad
No podemos investigar aquello que no registramos.
Por eso la visibilidad es uno de los fundamentos de la seguridad.
Cuantas más fuentes relevantes tengamos correctamente integradas, más posibilidades existen de entender una incidencia.
Sin embargo, tampoco se trata de recopilar datos indiscriminadamente.
Las fuentes deben aportar valor y mantenerse correctamente configuradas.
Semana 34: principales conclusiones
Durante la semana 34 de 2026:
- se analizaron 184.832 registros;
- Microsoft 365 generó 18.935 eventos;
- aparecieron 14 eventos relevantes de seguridad en Microsoft 365;
- Windows no produjo detecciones de alta confianza;
- Kaspersky no registró eventos críticos;
- no hubo eventos relevantes de perímetro SonicWall/UniFi;
- no se confirmaron correlaciones multisource;
- la plataforma Wazuh permaneció operativa y en estado GREEN.
Por tanto, la semana estuvo marcada principalmente por la revisión de actividad y cambios en Microsoft 365.
Conclusión: SIEM Wazuh en empresas convierte registros en contexto
El SIEM Wazuh en empresas nos permitió analizar 184.832 registros durante la semana 34 de 2026 procedentes de Windows, SonicWall, UniFi, Kaspersky y Microsoft 365.
Sin embargo, el dato importante no es únicamente el volumen.
Lo verdaderamente útil es poder localizar dentro de esos miles de eventos:
- cambios relevantes;
- nuevos dispositivos;
- modificaciones administrativas;
- posibles indicadores;
- relaciones entre distintas fuentes.
Además, mantener hasta 400 días de histórico permite revisar incidentes meses después y disponer de evidencia para auditorías e investigaciones.
En GHM Soluciones Informáticas combinamos SIEM Wazuh, SOC, Endpoint / EDR, firewall administrado y monitorización de Microsoft 365 para mejorar la visibilidad sobre la infraestructura empresarial.
Puedes conocer más sobre nuestro servicio de SIEM Wazuh para empresas y nuestras soluciones de ciberseguridad empresarial.
¿Tu empresa podría saber hoy qué ocurrió en Microsoft 365, su firewall o sus servidores hace seis meses?
Solicitar una revisión de ciberseguridad
Preguntas frecuentes sobre SIEM Wazuh en empresas
¿Qué es un SIEM Wazuh en empresas?
Un SIEM Wazuh en empresas permite recopilar, procesar y centralizar información de seguridad procedente de diferentes sistemas para mejorar la monitorización, búsqueda y análisis de eventos.
¿Cuántos registros se analizaron durante la semana 34?
Nuestro SOC analizó 184.832 registros correspondientes al periodo del 14 al 21 de agosto de 2026.
¿Qué fuentes se monitorizaron?
El informe incluye telemetría procedente de Windows, Microsoft 365, SonicWall, UniFi y Kaspersky.
Además, Wazuh puede integrarse con otras fuentes como macOS, Linux, servidores, NAS y dispositivos de red compatibles.
¿Qué ocurrió en Microsoft 365?
Durante la semana se analizaron 18.935 registros de Microsoft 365, de los cuales 14 fueron destacados como eventos relevantes de seguridad dentro del informe.
¿Los 14 eventos relevantes significan que Microsoft 365 fue comprometido?
No. Una alerta relevante indica que una actividad merece análisis, pero no demuestra por sí sola que exista un compromiso.
¿Qué tipo de eventos aparecieron?
Se observaron, entre otros, cambios de políticas de Acceso Condicional, modificaciones de service principals y un primer inicio de sesión desde un nuevo dispositivo.
¿Hubo detecciones Windows de alta confianza?
No. El resumen semanal registró cero detecciones Windows de alta confianza.
¿Hubo eventos críticos de Kaspersky?
No. El informe semanal registró cero eventos críticos.
¿Hubo incidentes relevantes en SonicWall o UniFi?
El resumen semanal registró cero eventos relevantes de perímetro SonicWall/UniFi.
¿Hubo correlaciones confirmadas entre fuentes?
No. El informe registró cero correlaciones Windows/SonicWall y cero correlaciones Microsoft 365/endpoint durante este periodo.
¿Por qué se conservan 400 días de logs?
Porque algunos incidentes se descubren semanas o meses después. Mantener histórico permite revisar actividad anterior, buscar relaciones y facilitar auditorías e investigaciones.
¿Puede Wazuh monitorizar Windows, macOS y Linux?
Sí. Wazuh admite recopilación de logs desde diferentes sistemas operativos y otras fuentes mediante agentes, syslog y APIs, dependiendo de la integración. Documentación oficial de Wazuh.
¿Puede monitorizar Microsoft 365?
Sí, mediante las integraciones y fuentes de auditoría configuradas se puede incorporar actividad de Microsoft 365 al análisis y correlación.
¿Quién analiza los registros?
Las diferentes tecnologías generan eventos y logs. Nuestro SOC de GHM Soluciones Informáticas analiza esos registros, revisa su contexto y determina qué actividad requiere investigación o actuación.
¿Un SIEM sustituye al antivirus o al firewall?
No. Son tecnologías complementarias. El firewall protege y controla comunicaciones, Endpoint / EDR protege los dispositivos y el SIEM centraliza y correlaciona información para mejorar la visibilidad.
¿Cuál fue el estado de la plataforma esta semana?
La plataforma permaneció operativa, con clúster GREEN, 23,8 % de memoria utilizada, 15,8 % de disco y los principales servicios Wazuh activos.
