Durante la semana 37 de 2026, nuestra plataforma de SIEM Wazuh en empresas procesó y centralizó 280.265 registros de seguridad y actividad procedentes de diferentes capas de las infraestructuras que monitorizamos.
El periodo analizado comprende desde el 4 de septiembre a las 16:00 hasta el 11 de septiembre de 2026 a las 16:00.
La información procede de fuentes como:
- Windows;
- Microsoft 365;
- Microsoft Entra ID;
- SonicWall;
- UniFi;
- Kaspersky;
- infraestructura de red;
- sistemas y servidores integrados.
Sin embargo, una cifra como 280.265 registros no significa que se hayan producido 280.265 amenazas.
Ese es precisamente uno de los puntos más importantes de un SIEM:
recoger miles de eventos, relacionarlos, aplicar reglas y reducir todo ese volumen hasta encontrar aquello que realmente merece atención.
Durante esta semana se identificaron eventos administrativos relevantes en Microsoft 365 y una incidencia de protección de endpoint que fue recuperada automáticamente.
La plataforma permaneció operativa y en estado GREEN, mientras nuestro SOC mantuvo la supervisión y revisión contextual de las señales relevantes.
¿Qué analizamos con SIEM Wazuh en empresas?
Un SIEM no debería limitarse a recibir los logs de un único servidor.
Nuestro objetivo es obtener visibilidad sobre diferentes capas de la infraestructura.
Dependiendo del entorno del cliente podemos integrar información procedente de:
Windows
macOS
Linux
servidores
NAS
firewall
switches
puntos de acceso WiFi
antivirus y Endpoint
Microsoft 365
Microsoft Entra ID
De esta forma, un evento aislado puede relacionarse con lo que está ocurriendo en otros sistemas.
Eso permite pasar de:
“ha ocurrido este evento”
a:
“¿qué estaba ocurriendo alrededor de ese evento?”
Ahí aparece una de las principales ventajas del SIEM Wazuh en empresas.
280.265 registros centralizados durante la semana 37
La telemetría de la semana quedó distribuida de la siguiente forma:
| Fuente | Registros |
|---|---|
| Windows | 47.553 |
| SonicWall | 128.572 |
| UniFi | 71.250 |
| Kaspersky | 11.393 |
| Microsoft 365 | 21.497 |
| Total | 280.265 |
Más de 280.000 eventos que, sin centralización, permanecerían repartidos entre consolas, archivos y plataformas independientes.
Y este es un problema habitual en muchas empresas.
Tienen:
- firewall;
- antivirus;
- Microsoft 365;
- switches;
- servidores.
Pero cada solución trabaja por separado.
Tener logs no significa estar monitorizado
Un firewall puede registrar miles de conexiones.
Un antivirus puede generar eventos.
Microsoft 365 puede registrar accesos y cambios.
Windows puede almacenar actividad del sistema.
Pero si nadie relaciona esa información, podemos tener muchos datos y muy poca visibilidad.
Nuestro enfoque es:
fuentes de seguridad
↓
SIEM Wazuh
↓
reglas y correlaciones
↓
detecciones relevantes
↓
análisis SOC
La tecnología permite procesar el volumen.
El análisis aporta contexto.
Microsoft 365: 21.497 registros en siete días
Microsoft 365 generó 21.497 eventos únicos durante el periodo analizado.
La distribución fue:
- Exchange Online: 8.810
- Microsoft Entra ID: 6.749
- SharePoint Online: 5.412
- OneDrive for Business: 486
- Microsoft Teams: 9
- otros servicios: 31
Estos registros representan actividad normal y administrativa del entorno cloud.
No deben interpretarse automáticamente como amenazas.
La cuestión importante es identificar dentro de esa actividad los eventos que requieren revisión.
SIEM Wazuh en empresas y Microsoft 365
Microsoft 365 se ha convertido en una de las fuentes de información más importantes para la seguridad empresarial.
Dentro del ecosistema podemos encontrar eventos relacionados con:
- autenticaciones;
- cambios de contraseña;
- MFA;
- usuarios;
- grupos;
- SharePoint;
- OneDrive;
- Exchange;
- aplicaciones;
- service principals;
- políticas de Acceso Condicional.
Una parte de esta actividad es completamente normal.
Por ejemplo:
un administrador modifica una política.
Eso puede ser una operación legítima.
Pero también puede ser relevante desde el punto de vista de seguridad.
Por eso necesitamos responder:
¿quién realizó el cambio?
¿cuándo?
¿era una acción prevista?
¿qué ocurrió después?
Tres eventos relevantes de Microsoft 365 durante la semana
Durante la semana 37 se identificaron tres eventos de Microsoft 365 que merecieron contextualización.
Estaban relacionados con:
- incorporación o modificación de un service principal;
- modificación de una política de Acceso Condicional;
- cambio de una contraseña de usuario.
Es muy importante entender qué significa esto.
Tres eventos relevantes no significan tres ataques.
Son operaciones administrativas que, por su potencial impacto sobre la seguridad, conviene supervisar.
¿Por qué monitorizar los cambios de Acceso Condicional?
Las políticas de Acceso Condicional pueden decidir:
- quién puede acceder;
- desde qué dispositivo;
- desde qué ubicación;
- si se requiere MFA;
- si el dispositivo debe ser compatible.
Por tanto, modificar una de estas políticas puede cambiar directamente el nivel de protección de Microsoft 365.
Un administrador puede realizar el cambio de forma totalmente legítima.
Sin embargo, también es exactamente el tipo de modificación que queremos poder identificar.
Por ejemplo:
política modificada
↓
SIEM registra el evento
↓
SOC revisa el contexto
↓
se confirma si corresponde a una actuación autorizada
Ese es el valor de monitorizar actividad administrativa.
¿Por qué vigilar los service principals?
Un service principal representa una identidad utilizada por una aplicación o servicio dentro de Microsoft Entra ID.
Puede disponer de permisos para acceder a recursos.
Por eso la creación o modificación de uno merece visibilidad.
No significa automáticamente:
“aplicación maliciosa”.
Puede tratarse simplemente de un servicio legítimo incorporado por el administrador.
Pero conviene conocer:
- cuándo se crea;
- qué permisos obtiene;
- qué aplicación representa;
- quién autorizó la operación.
Las identidades de aplicaciones también forman parte de la superficie de seguridad de Microsoft 365.
Cambios de contraseña: normales, pero auditables
Cambiar una contraseña es una operación habitual.
Pero también puede aparecer durante:
- recuperación de cuentas;
- respuesta a incidentes;
- modificaciones administrativas.
Por tanto, registrar y conservar esta actividad ayuda a mantener trazabilidad.
La pregunta no debe ser:
“¿cambiar una contraseña es sospechoso?”
La pregunta correcta es:
“¿podemos saber cuándo ocurrió y relacionarlo con el resto de la actividad?”
Kaspersky: una parada de protección recuperada
Durante la semana también se registró una parada de protección de Kaspersky posteriormente recuperada automáticamente.
Este tipo de evento es útil porque demuestra otra función del SIEM:
supervisar que las propias herramientas de seguridad continúan funcionando.
No basta con instalar un antivirus.
También hay que saber si:
- está operativo;
- su protección se detiene;
- el servicio se recupera;
- aparece una incidencia repetitiva.
En este caso, la protección se recuperó.
Aun así, el evento queda registrado para mantener trazabilidad.
Monitorizar las herramientas que monitorizan
Existe un principio importante:
una herramienta de seguridad que deja de funcionar puede convertirse en un punto ciego.
Por eso conviene vigilar también:
- antivirus;
- agentes;
- firewall;
- servicios SIEM;
- colectores;
- procesos.
Si un sistema deja de enviar información:
eso también es información.
SonicWall: 128.572 registros durante la semana 37
SonicWall aportó 128.572 registros durante el periodo.
Es la fuente con mayor volumen de telemetría esta semana.
El firewall puede registrar información relacionada con:
- conexiones;
- tráfico;
- reglas;
- accesos;
- VPN;
- detecciones;
- actividad de red.
Sin embargo, debemos mantener la diferencia entre:
evento generado por el firewall
y:
amenaza confirmada.
SonicWall registra actividad.
Nuestro SOC analiza los logs y su contexto.
¿Por qué enviar los logs del firewall a Wazuh?
Porque el firewall ve una parte de la historia.
Imagine:
SonicWall detecta una conexión externa.
Por sí sola podría no tener relevancia.
Pero podemos encontrar simultáneamente:
Windows → actividad anómala
Endpoint → alerta
Microsoft 365 → autenticación inesperada
Firewall → conexión exterior
Cada señal aporta contexto.
La correlación puede transformar varios eventos aparentemente independientes en una investigación prioritaria.
UniFi: 71.250 eventos de red
La infraestructura UniFi generó 71.250 registros durante la semana.
Dependiendo de la instalación, UniFi puede proporcionar información de:
- switches;
- puntos de acceso;
- gateway;
- conectividad;
- estado de red;
- tráfico.
La red también forma parte de la ciberseguridad.
No únicamente porque transporte los datos.
También porque puede ayudarnos a entender:
desde dónde se comunica un dispositivo y hacia dónde.
Monitorización de switches y puntos de acceso
En muchas empresas se supervisan los servidores pero se olvida la electrónica de red.
Sin embargo:
switches
y:
puntos de acceso WiFi
son parte esencial de la infraestructura.
Una caída, error o comportamiento anómalo puede afectar a:
- conectividad;
- usuarios;
- cámaras;
- NAS;
- servidores;
- dispositivos IoT.
Por eso la monitorización no debería terminar en el PC.
Windows generó 47.553 eventos durante la semana
Windows aportó 47.553 registros al sistema durante el periodo analizado.
Estos registros pueden incluir diferentes tipos de actividad del sistema operativo.
Por ejemplo:
- servicios;
- autenticación;
- procesos;
- eventos del sistema;
- seguridad;
- aplicaciones.
El objetivo no consiste en mostrar todos los eventos a un administrador.
Sería prácticamente imposible utilizarlos de esa manera.
El objetivo es:
filtrar + correlacionar + priorizar.
47.553 eventos Windows no significan 47.553 alertas
Este punto es fundamental.
Un equipo Windows puede generar continuamente logs.
La mayor parte corresponden a operaciones normales.
Por eso no tiene sentido enviar una notificación por cada evento.
Un buen sistema de monitorización debe reducir ruido.
Por ejemplo:
evento aislado normal → registrar
secuencia relevante → analizar
Así evitamos uno de los problemas más habituales en seguridad:
la fatiga de alertas.
11.393 eventos de Kaspersky
La telemetría de Kaspersky alcanzó 11.393 registros.
El antivirus aporta otra perspectiva sobre el endpoint.
Puede registrar información relacionada con:
- protección;
- análisis;
- amenazas;
- servicios;
- funcionamiento del agente.
Al integrarlo con otras fuentes conseguimos algo especialmente útil:
no depender únicamente de la consola del antivirus.
SIEM Wazuh en empresas: correlaciones personalizadas
Una de las partes más importantes de nuestro servicio no es únicamente desplegar Wazuh.
Es adaptar las correlaciones a la infraestructura.
Cada empresa es diferente.
Una asesoría puede utilizar:
- Microsoft 365;
- VPN;
- servidor;
- NAS.
Una ingeniería puede tener:
- estaciones de trabajo;
- NAS;
- firewall;
- VPN;
- aplicaciones técnicas.
Una administración de fincas puede depender principalmente de:
- Microsoft 365;
- programa de gestión;
- banca;
- acceso remoto.
Por eso las mismas reglas no siempre tienen el mismo valor.
¿Qué es una correlación?
Imagine tres eventos:
1. Firewall: conexión desde una dirección externa.
2. Windows: autenticación.
3. Endpoint: proceso sospechoso.
Cada uno por separado podría tener una prioridad determinada.
Pero si ocurren:
sobre el mismo sistema
y:
dentro del mismo intervalo temporal
la relevancia puede aumentar considerablemente.
Eso es correlación.
Correlación no significa generar más alertas
El objetivo debería ser justamente el contrario:
generar mejores alertas.
No necesitamos:
10.000 avisos.
Necesitamos identificar:
qué 5 requieren atención.
Esta es una de las razones por las que un SIEM necesita configuración y mantenimiento.
Indicadores de compromiso personalizados
También podemos incorporar indicadores de compromiso adaptados a cada entorno.
Por ejemplo:
- direcciones IP;
- dominios;
- patrones;
- comportamientos;
- eventos concretos.
Cuando aparece un indicador nuevo podemos comprobar:
¿ha aparecido en nuestra infraestructura?
Y si conservamos histórico:
¿apareció anteriormente?
Hasta 400 días de almacenamiento de logs
Nuestro servicio de SIEM Wazuh en empresas puede mantener hasta 400 días de histórico de logs de las fuentes integradas.
Esto proporciona una ventaja especialmente importante:
poder mirar hacia atrás.
Imagine que hoy conocemos una nueva vulnerabilidad.
La corregimos.
Perfecto.
Pero aparece otra pregunta:
¿alguien intentó explotarla hace tres meses?
Sin histórico:
puede ser imposible comprobarlo.
Los logs funcionan como memoria de seguridad
Una infraestructura sin histórico únicamente puede responder:
“¿qué está pasando ahora?”
Una infraestructura con retención puede intentar responder también:
“¿qué pasó anteriormente?”
Esto puede resultar útil para:
- incidentes;
- auditorías;
- investigaciones;
- indicadores de compromiso;
- cambios administrativos;
- cumplimiento.
Por eso la conservación de logs tiene valor más allá de la detección inmediata.
Auditorías y trazabilidad
Otro uso importante del SIEM es la trazabilidad.
Por ejemplo:
¿cuándo se modificó una política?
¿cuándo cambió una contraseña?
¿qué usuario realizó una operación?
¿qué actividad existía alrededor del incidente?
No siempre buscamos demostrar que existió un ataque.
A veces necesitamos reconstruir:
qué ocurrió.
Estado de la plataforma: GREEN
Durante la semana 37, el clúster Wazuh permaneció en estado:
GREEN
con 510 shards.
El servidor registraba:
- 42 % de uso de memoria
- 16,7 % de utilización de disco
Además, los principales servicios permanecían activos:
- wazuh-manager;
- wazuh-indexer;
- wazuh-dashboard;
- filebeat;
- postfix.
La monitorización también debe incluir:
la propia plataforma de monitorización.
¿Por qué vigilar Wazuh?
Porque un SIEM caído genera un problema evidente:
dejamos de recibir visibilidad.
Por eso controlamos el estado de:
- manager;
- indexer;
- dashboard;
- colectores;
- almacenamiento;
- copias.
La monitorización debe ser recursiva:
también hay que supervisar al sistema que supervisa.
Copias de seguridad del propio SIEM
Durante la generación del informe, las copias de los logs de Wazuh se encontraban en estado:
OK
tanto en el servidor como en NAS.
Además, el sistema mantenía snapshots del Indexer en:
servidor
y:
NAS
con la retención prevista operativa.
Esto tiene un objetivo:
proteger también la información utilizada durante las investigaciones.
¿Por qué realizar snapshots del Indexer?
El Indexer almacena una parte fundamental de la información utilizada por Wazuh.
Los snapshots permiten disponer de puntos de recuperación.
La estrategia no debería ser:
“tenemos SIEM, por tanto nunca fallará”.
La estrategia correcta es:
“si ocurre un problema, ¿cómo recuperamos la plataforma y sus datos?”
Monitorización de Microsoft 365 más allá del correo
Muchas empresas identifican Microsoft 365 únicamente con:
Outlook + Word + Excel.
Desde seguridad, Microsoft 365 es mucho más.
Tenemos:
Entra ID
para identidad.
Exchange Online
para correo.
SharePoint
para información compartida.
OneDrive
para almacenamiento.
Teams
para colaboración.
Un incidente en cualquiera de ellos puede proporcionar información relevante.
Entra ID: 6.749 eventos
Microsoft Entra ID generó 6.749 eventos únicos durante la semana.
La identidad se ha convertido en uno de los principales perímetros de seguridad.
Un atacante ya no necesita necesariamente entrar físicamente en nuestra oficina.
Puede intentar:
robar una cuenta Microsoft 365.
Por eso monitorizar:
- autenticaciones;
- cambios;
- privilegios;
- aplicaciones;
- Acceso Condicional;
es cada vez más importante.
Exchange Online: 8.810 eventos
Exchange fue la fuente Microsoft 365 con mayor volumen esta semana:
8.810 registros.
El correo sigue siendo uno de los principales canales de entrada utilizados en ataques.
Phishing, BEC y robo de credenciales continúan siendo amenazas habituales.
No todos los eventos de Exchange son de seguridad.
Pero disponer del histórico puede aportar contexto cuando necesitamos investigar una cuenta.
SharePoint y OneDrive
Durante la semana se procesaron:
5.412 eventos de SharePoint
y:
486 de OneDrive.
Las empresas almacenan cada vez más información en Microsoft 365.
Por tanto, ante una cuenta comprometida no queremos revisar únicamente:
quién inició sesión.
También puede interesarnos:
qué actividad realizó después.
El SIEM no sustituye las protecciones nativas de Microsoft 365
Wazuh no sustituye:
- MFA;
- Acceso Condicional;
- permisos;
- protección de identidad.
Añade otra capacidad:
centralización y análisis.
La estrategia adecuada es por capas.
Por ejemplo:
MFA reduce el riesgo
Acceso Condicional controla
Microsoft registra
Wazuh centraliza
SOC analiza
Monitorización de servidores, NAS y sistemas críticos
En muchas pymes el activo más importante no es el ordenador del usuario.
Puede ser:
servidor
NAS
Microsoft 365
firewall
Por eso priorizamos la monitorización de aquellos activos donde una incidencia podría tener mayor impacto.
El SIEM permite adaptar la supervisión a cada infraestructura.
SIEM Wazuh para servidores
Un servidor puede contener:
- aplicaciones;
- documentos;
- bases de datos;
- servicios;
- credenciales.
Por eso los eventos procedentes del servidor suelen tener especial interés.
Podemos monitorizar, dependiendo de la plataforma:
- Windows Server;
- Linux;
- servicios;
- autenticaciones;
- cambios;
- disponibilidad.
NAS: almacenamiento que también necesita seguridad
Un NAS puede almacenar:
- documentación;
- proyectos;
- copias;
- información administrativa.
En muchos ataques de ransomware, los recursos compartidos también se convierten en objetivo.
Por eso deben tratarse como activos críticos.
No como:
“el disco de red que está en el armario”.
macOS y Linux también forman parte del SIEM
Wazuh permite trabajar con sistemas diferentes.
Por eso podemos integrar:
Windows
macOS
Linux
dentro de una misma estrategia de monitorización.
Esto resulta especialmente útil en empresas con entornos heterogéneos.
No necesitamos crear un sistema de seguridad completamente separado para cada sistema operativo.
El SIEM aporta visibilidad; el SOC aporta análisis
Esta diferencia es fundamental.
Un SIEM puede:
- recopilar;
- indexar;
- aplicar reglas;
- correlacionar.
Pero una alerta puede necesitar contexto.
Por ejemplo:
política de Acceso Condicional modificada.
¿Es un ataque?
No necesariamente.
Quizá el administrador estaba realizando un cambio previsto.
Nuestro SOC revisa ese contexto.
Automatización + supervisión humana
La automatización es imprescindible cuando manejamos:
280.265 registros en una semana.
Ninguna persona debería leer manualmente uno por uno.
Pero tampoco es recomendable pensar que:
“la herramienta ya lo decide todo”.
El modelo que aplicamos combina:
automatización
para reducir volumen
con:
análisis humano
cuando existe una detección relevante.
¿Qué significa una semana con pocas alertas?
Puede parecer contradictorio:
280.265 registros
pero:
pocos eventos destacados.
Eso puede ser completamente normal.
El objetivo de un SIEM no es fabricar incidentes.
Es identificar los eventos relevantes dentro de una enorme cantidad de actividad legítima.
Una semana con pocos incidentes:
no significa que Wazuh no haya trabajado.
Significa que el sistema ha procesado la telemetría y no ha convertido indiscriminadamente cada registro en una alarma.
Más alertas no significa mejor seguridad
Dos SOC pueden revisar la misma infraestructura.
Uno genera:
5.000 alertas.
Otro genera:
20 eventos contextualizados.
No podemos determinar cuál es mejor únicamente por la cantidad.
La pregunta debería ser:
¿cuántas señales relevantes somos capaces de detectar sin ahogar al equipo en ruido?
SIEM Wazuh en empresas y fatiga de alertas
La fatiga de alertas aparece cuando existen tantos avisos que dejan de resultar útiles.
El analista puede terminar viendo:
alerta
alerta
alerta
hasta que una verdaderamente importante pasa desapercibida.
Por eso las reglas personalizadas son fundamentales.
Queremos reducir:
ruido
y aumentar:
contexto.
Cada cliente necesita correlaciones diferentes
No tiene los mismos riesgos:
una asesoría laboral
que:
una ingeniería
o:
un despacho de abogados.
Por eso adaptamos la monitorización a la infraestructura real.
Podemos priorizar:
- Microsoft 365;
- servidores;
- firewall;
- VPN;
- NAS;
- Endpoint.
La monitorización debe responder al negocio.
SIEM Wazuh en empresas para administraciones de fincas
Una administración de fincas puede depender de:
- programa de gestión;
- documentos;
- banca;
- correo;
- Microsoft 365.
Un compromiso de identidad puede tener un impacto importante.
La centralización de eventos permite disponer de mayor trazabilidad.
SIEM para asesorías
Una asesoría contable o laboral trabaja con información especialmente sensible.
Puede utilizar:
- certificados;
- nóminas;
- Seguridad Social;
- bancos;
- correo.
La monitorización puede ayudar a investigar accesos o actividad anómala.
SIEM para despachos de abogados
En un despacho jurídico, la confidencialidad de:
- expedientes;
- comunicaciones;
- documentación;
es especialmente importante.
Disponer de histórico también puede facilitar investigaciones si aparece un incidente meses después.
SIEM para arquitectura, construcción e ingeniería
Estos entornos pueden manejar:
- proyectos;
- planos;
- documentación;
- NAS;
- estaciones de trabajo potentes;
- acceso remoto.
Aquí, servidores y almacenamiento suelen ser activos prioritarios.
Una infraestructura supervisada no es una infraestructura invulnerable
Conviene dejarlo claro.
Un SIEM no garantiza:
“nunca habrá un incidente”.
Su objetivo es mejorar:
- visibilidad;
- detección;
- investigación;
- trazabilidad.
La ciberseguridad funciona mediante varias capas.
SIEM Wazuh dentro de una estrategia de ciberseguridad
Una arquitectura puede combinar:
MFA
Endpoint / EDR
firewall administrado
segmentación
copias
SIEM Wazuh
SOC
Cada capa responde a una necesidad diferente.
Puede conocer nuestras soluciones de ciberseguridad para empresas.
Endpoint y firewall también generan información
Las soluciones de Endpoint y firewall no deberían trabajar completamente aisladas.
Sus eventos pueden integrarse para aportar contexto.
Puede consultar nuestra solución de Endpoint y firewall para empresas.
La correlación es especialmente interesante cuando una misma actividad aparece en distintas fuentes.
¿Qué diferencia existe entre SIEM y SOC?
Es una pregunta habitual.
SIEM
Es la plataforma tecnológica que:
- centraliza;
- almacena;
- busca;
- correlaciona.
SOC
Es la función de seguridad que:
- analiza;
- investiga;
- contextualiza;
- comunica;
- interviene cuando corresponde.
Por tanto:
Wazuh es la plataforma.
El SOC realiza el análisis.
¿Una pyme necesita un SIEM?
No todas las empresas necesitan exactamente la misma arquitectura.
Pero puede ser especialmente útil cuando existen:
- varios sistemas;
- Microsoft 365;
- firewall;
- servidores;
- NAS;
- acceso remoto;
- requisitos de auditoría.
La pregunta no es únicamente:
“¿somos lo suficientemente grandes?”
También:
“¿qué impacto tendría no poder investigar un incidente?”
Histórico para revisar incidentes meses después
Imagine que en marzo descubrimos:
una cuenta comprometida.
Queremos saber:
¿qué ocurrió en enero?
Si los logs ya se han eliminado:
la investigación puede quedar incompleta.
Con una retención de hasta 400 días, disponemos de una ventana considerable para búsquedas retrospectivas.
Auditoría: demostrar con registros, no con memoria
Después de un incidente puede ser necesario responder:
“¿cuándo ocurrió?”
Decir:
“creemos que fue el martes”
no es lo mismo que poder consultar:
fecha + hora + evento + origen.
Los logs aportan evidencia técnica.
Semana 37: plataforma operativa y copias correctas
El informe semanal también verifica la salud del propio sistema.
Durante la generación del informe:
🟢 Cluster Wazuh: GREEN
📊 510 shards
🧠 Memoria del servidor: 42 %
💾 Disco utilizado: 16,7 %
Además:
✅ wazuh-manager activo
✅ wazuh-indexer activo
✅ wazuh-dashboard activo
✅ filebeat activo
✅ postfix activo
✅ copia de logs en servidor correcta
✅ copia de logs en NAS correcta
✅ snapshots del Indexer correctos
✅ política de retención de snapshots correcta
Esto completa otra parte de nuestro enfoque:
monitorizar la seguridad y también la infraestructura que proporciona esa monitorización.
¿Qué nos deja la semana 37?
El principal valor del informe no está únicamente en una cifra.
Sin embargo, la cifra ayuda a visualizar la magnitud:
280.265 registros analizados en siete días.
Dentro de ellos encontramos:
- actividad Windows;
- firewall;
- red;
- Endpoint;
- Microsoft 365.
Y después:
reglas + correlación + análisis SOC.
Ese es el proceso que permite convertir logs en información útil.
Conclusión: SIEM Wazuh en empresas significa poder ver, relacionar e investigar
Durante la semana 37 de 2026, nuestro entorno de SIEM Wazuh en empresas procesó:
280.265 registros
procedentes de:
- Windows: 47.553
- SonicWall: 128.572
- UniFi: 71.250
- Kaspersky: 11.393
- Microsoft 365: 21.497
Dentro de Microsoft 365 se revisaron eventos procedentes de Exchange, SharePoint, OneDrive, Teams y Microsoft Entra ID.
Además, durante la semana se identificaron tres eventos administrativos relevantes en Microsoft 365 para su contextualización y una parada de protección de Endpoint que fue recuperada automáticamente.
Mientras tanto, la plataforma permaneció:
operativa
con el clúster:
GREEN
y sus principales servicios, copias y snapshots en funcionamiento.
Pero el verdadero valor no está en poder decir:
“recibimos 280.265 logs”.
Está en poder responder:
“¿qué ocurrió, dónde ocurrió, qué relación tenía con otros sistemas y necesitamos actuar?”
En GHM Soluciones Informáticas integramos monitorización de:
Microsoft 365 + Windows + macOS + Linux + servidores + NAS + firewall + switches + puntos de acceso + antivirus
mediante SIEM Wazuh, correlaciones adaptadas a cada infraestructura y análisis de nuestro SOC.
Además, podemos mantener hasta 400 días de histórico de logs para investigaciones, auditorías y búsquedas retrospectivas.
Puede conocer nuestro servicio de SIEM Wazuh para empresas.
Porque cuando ocurre un incidente, una de las peores respuestas posibles es:
“no sabemos qué pasó porque ya no tenemos los registros”.
📩 Contactar con GHM Soluciones Informáticas
Preguntas frecuentes sobre SIEM Wazuh en empresas
¿Cuántos registros se analizaron durante la semana 37 de 2026?
Se centralizaron 280.265 registros procedentes de Windows, SonicWall, UniFi, Kaspersky y Microsoft 365.
¿280.265 registros significan 280.265 amenazas?
No. La mayoría de los logs corresponden a actividad legítima. El objetivo del SIEM es identificar dentro de ese volumen los eventos realmente relevantes.
¿Cuántos eventos generó Microsoft 365?
Durante el periodo se procesaron 21.497 eventos únicos de Microsoft 365.
¿Qué servicios de Microsoft 365 se monitorizan?
Entre otros, Microsoft Entra ID, Exchange Online, SharePoint Online, OneDrive for Business y Microsoft Teams.
¿Hubo eventos relevantes de Microsoft 365?
Sí. Se contextualizaron tres operaciones administrativas relacionadas con un service principal, una política de Acceso Condicional y un cambio de contraseña.
¿Esos tres eventos fueron ataques?
No. Un evento relevante requiere revisión, pero no implica automáticamente un incidente de seguridad.
¿Qué ocurrió con Kaspersky?
Se registró una parada de protección que posteriormente fue recuperada automáticamente. El evento permanece registrado para mantener trazabilidad.
¿Cuántos registros generó SonicWall?
128.572 registros durante el periodo analizado.
¿SonicWall analiza los logs?
SonicWall registra los eventos del firewall. Los logs se centralizan en Wazuh y nuestro SOC analiza su contexto y las posibles correlaciones.
¿Cuántos eventos aportó UniFi?
La infraestructura UniFi generó 71.250 registros durante la semana.
¿Qué puede monitorizarse con UniFi?
Dependiendo de la infraestructura, switches, puntos de acceso, gateways, conectividad y otros eventos de red.
¿Qué sistemas operativos pueden integrarse con Wazuh?
Entre otros, Windows, Linux y macOS.
¿Se pueden monitorizar servidores?
Sí. De hecho, los servidores suelen ser uno de los activos prioritarios dentro de una estrategia SIEM empresarial.
¿Se pueden monitorizar NAS?
Dependiendo del fabricante y de las fuentes de logs disponibles, pueden integrarse eventos del NAS y otros sistemas de almacenamiento.
¿Qué es una correlación de eventos?
Es relacionar varios eventos procedentes de una o varias fuentes para obtener un contexto que no estaría disponible observándolos de forma aislada.
¿Las correlaciones son iguales para todas las empresas?
No. Podemos adaptar reglas y correlaciones a las características de cada infraestructura.
¿Qué son los indicadores de compromiso?
Son datos o patrones que pueden estar relacionados con actividad maliciosa, como determinados dominios, direcciones IP o comportamientos. Un indicador por sí solo no confirma una intrusión.
¿Cuánto tiempo pueden almacenarse los logs?
En nuestro servicio podemos mantener hasta 400 días de histórico de las fuentes integradas.
¿Para qué sirve conservar 400 días?
Para investigaciones retrospectivas, análisis de incidentes, búsqueda de indicadores y auditorías.
¿Cuál fue el estado de Wazuh durante la semana 37?
El clúster se encontraba en estado GREEN y los principales servicios estaban operativos.
¿Se realizan copias del propio SIEM?
Sí. El informe confirma copias de logs y snapshots del Indexer tanto en servidor como en NAS.
¿Qué diferencia existe entre Wazuh y un SOC?
Wazuh es la plataforma tecnológica que recoge, almacena y correlaciona. El SOC analiza los eventos, su contexto y determina si requieren actuación.
¿Un SIEM sustituye al antivirus?
No. Antivirus o Endpoint / EDR, firewall, MFA, SIEM y SOC cumplen funciones diferentes y se complementan.
¿Un SIEM impide todos los ciberataques?
No. Su función principal es mejorar la visibilidad, detección, correlación, investigación y trazabilidad.
¿Por qué es útil para una pyme?
Porque permite centralizar información que normalmente estaría repartida entre Microsoft 365, firewall, servidores, Endpoint y red.
¿Cuál es el principal valor del SIEM Wazuh en empresas?
Poder transformar miles de registros independientes en información útil para responder:
qué ocurrió, cuándo, dónde, qué otros sistemas estuvieron relacionados y si es necesario actuar.
