SIEM Wazuh en empresas: 259.545 registros analizados en la semana 35

El SIEM Wazuh en empresas permite convertir grandes volúmenes de registros técnicos en información útil para conocer qué está ocurriendo realmente en una infraestructura. Durante la semana 35 de 2026, nuestro SOC de GHM Soluciones Informáticas analizó 259.545 registros procedentes de Microsoft 365, SonicWall, UniFi, Windows y Kaspersky.

El periodo de seguridad analizado comprende del 21 al 28 de agosto de 2026. Durante estos siete días, Microsoft 365 generó 293 eventos relevantes de seguridad, mientras que no se registraron detecciones Windows de alta confianza, eventos críticos de Kaspersky, eventos relevantes de perímetro SonicWall/UniFi ni correlaciones multisource confirmadas.

Además, Wazuh permaneció completamente operativo, con el clúster en estado GREEN, los principales servicios activos, un uso de memoria del 29,8 % y un 16,7 % de disco utilizado.

Sin embargo, el dato más importante no es únicamente el número de registros.

El verdadero valor está en poder responder:

¿Qué ocurrió? ¿Qué necesita revisión? ¿Qué es actividad normal? ¿Qué eventos están relacionados?

Ahí es donde un SIEM Wazuh en empresas, combinado con análisis SOC, aporta contexto.

SIEM Wazuh en empresas: 259.545 registros en siete días

Durante la semana 35, las principales fuentes generaron:

  • Windows: 9.339 registros
  • SonicWall: 127.385 registros
  • UniFi: 33.422 registros
  • Kaspersky: 11.461 registros
  • Microsoft 365: 77.938 registros

En conjunto:

259.545 registros de actividad y seguridad durante una semana.

Esto demuestra uno de los principales retos de la ciberseguridad moderna.

Una empresa puede generar cientos de miles de registros sin sufrir cientos de miles de ataques.

Por eso necesitamos diferenciar entre:

telemetría → evento → alerta → investigación → incidente confirmado

No son conceptos equivalentes.

259.545 registros no significan 259.545 amenazas

Este punto es especialmente importante.

Un firewall genera eventos continuamente.

Microsoft 365 registra accesos, modificaciones, operaciones sobre archivos y cambios administrativos.

Los endpoints generan actividad.

Los antivirus registran funcionamiento, actualizaciones y detecciones.

Las redes generan telemetría.

Por tanto:

más logs no significa automáticamente más riesgo.

El objetivo del SIEM es procesar toda esa información para localizar las señales que merecen realmente atención.

Durante la semana 35, por ejemplo, Microsoft 365 produjo 77.938 eventos únicos, pero el resumen de seguridad destacó 293 eventos relevantes para análisis.

¿Qué ocurrió esta semana en Microsoft 365?

Microsoft 365 concentró la principal actividad relevante de seguridad.

Los eventos destacados estuvieron relacionados con:

  • acceso desde un nuevo dispositivo;
  • modificaciones de usuarios;
  • restablecimiento de contraseña;
  • creación y modificación de políticas de Acceso Condicional;
  • cambios de propietarios y miembros de grupos;
  • modificación de métodos MFA;
  • creación de service principals;
  • actividad elevada sobre SharePoint y OneDrive.

Aquí vuelve a aparecer una diferencia fundamental:

una alerta de seguridad no significa necesariamente que exista una intrusión.

Una modificación de una política de Acceso Condicional puede ser completamente legítima.

Un cambio de contraseña puede haber sido realizado por un administrador.

Un nuevo dispositivo puede corresponder a la renovación de un teléfono.

Una lectura elevada de documentos puede responder a una sincronización o actividad profesional normal.

El trabajo consiste precisamente en comprobar el contexto.

SIEM Wazuh en empresas y 293 eventos relevantes de Microsoft 365

El informe semanal clasificó 293 eventos de Microsoft 365 como relevantes para revisión.

La mayor parte estuvo relacionada con una lectura masiva de archivos en SharePoint / OneDrive, donde se registraron 276 eventos FileAccessed.

Una regla de este tipo resulta útil porque una actividad elevada sobre archivos puede corresponder a diferentes escenarios.

Por ejemplo:

  • sincronización legítima;
  • migración de información;
  • acceso intensivo por trabajo;
  • descarga masiva;
  • actividad automatizada;
  • comportamiento que necesita investigación.

La regla identifica el comportamiento.

El SOC determina su significado.

Una lectura masiva de SharePoint no significa automáticamente robo de información

Supongamos que una cuenta accede a cientos de documentos en poco tiempo.

Podría ser preocupante.

Sin embargo, también podría estar ocurriendo porque:

  • OneDrive está sincronizando una biblioteca;
  • el usuario acaba de configurar un equipo;
  • se está realizando una migración;
  • una aplicación legítima está indexando contenido.

Por eso no sería correcto afirmar:

“Se detectó una exfiltración de datos.”

sin evidencias adicionales.

La formulación correcta sería:

“Se detectó un patrón de acceso elevado que requiere contextualización.”

Esta diferencia evita alarmas innecesarias y permite centrar el análisis en hechos verificables.

Microsoft 365 generó 77.938 eventos únicos

El volumen de Microsoft 365 aumentó de forma muy significativa esta semana.

El desglose fue:

  • Exchange Online: 6.504
  • SharePoint Online: 37.024
  • OneDrive for Business: 27.999
  • Microsoft Entra ID: 6.368
  • Microsoft Teams: 10
  • Otros servicios: 33

Total:

77.938 eventos únicos de Microsoft 365.

La semana anterior se habían registrado 18.935.

Por tanto, el volumen aumentó considerablemente.

Sin embargo, nuevamente:

más actividad no significa necesariamente mayor nivel de amenaza.

Buena parte del incremento procede de SharePoint y OneDrive.

SIEM Wazuh en empresas y monitorización de SharePoint

SharePoint generó 37.024 registros durante la semana 35.

Este tipo de telemetría puede resultar muy valioso porque SharePoint puede contener:

  • documentación corporativa;
  • proyectos;
  • contratos;
  • información interna;
  • archivos compartidos;
  • datos de clientes.

Monitorizar su actividad permite establecer reglas relacionadas con:

  • accesos;
  • modificaciones;
  • descargas;
  • actividad masiva;
  • acciones administrativas.

No significa que cada acceso deba generar una alarma.

El objetivo es identificar comportamientos fuera de lo esperado.

OneDrive generó 27.999 registros

OneDrive for Business produjo otros 27.999 eventos únicos.

OneDrive es una de las herramientas más utilizadas en Microsoft 365.

Por ello, puede generar una enorme cantidad de actividad legítima.

Por ejemplo:

sincronizar una biblioteca grande

puede producir miles de operaciones.

Sin embargo, disponer de esos registros permite investigar posteriormente.

Si meses después aparece una incidencia, podemos preguntarnos:

¿Qué archivos se consultaron?

¿Cuándo?

¿Desde qué contexto?

¿Coincidió con otros eventos?

Sin telemetría, esas preguntas pueden quedar sin respuesta.

Microsoft Entra ID: 6.368 eventos

Microsoft Entra ID generó 6.368 eventos únicos durante la semana.

La identidad se ha convertido en uno de los principales perímetros de seguridad.

Hoy un usuario puede acceder desde cualquier lugar a:

  • Outlook;
  • Teams;
  • SharePoint;
  • OneDrive;
  • aplicaciones empresariales.

Por eso resulta especialmente importante supervisar:

  • inicios de sesión;
  • cambios de usuarios;
  • grupos;
  • aplicaciones;
  • políticas;
  • MFA;
  • administradores.

Un firewall protege la red.

Pero Microsoft Entra ID protege en gran medida quién puede acceder a los recursos cloud.

SIEM Wazuh en empresas y cambios de Acceso Condicional

Durante la semana aparecieron eventos relacionados con la creación y modificación de políticas de Acceso Condicional.

Este tipo de cambios merece especial atención.

Una política puede determinar:

  • desde qué países se permite acceder;
  • si se exige MFA;
  • si el dispositivo debe cumplir políticas;
  • si se permite un navegador;
  • qué aplicaciones están incluidas.

Por tanto, una modificación puede alterar directamente la postura de seguridad del tenant.

Sin embargo, también puede formar parte de una tarea administrativa perfectamente legítima.

Por eso una regla debería avisar.

Después:

el SOC revisa quién realizó el cambio, cuándo y sobre qué política.

Restablecimientos de contraseña también deben quedar registrados

El informe también detectó una operación de restablecimiento de contraseña clasificada como crítica por las reglas establecidas.

Esto no significa que el restablecimiento fuera malicioso.

Pero sí representa una acción sensible.

Un cambio de contraseña realizado por un administrador puede ser:

  • soporte legítimo;
  • alta de usuario;
  • recuperación de acceso;
  • respuesta a una incidencia.

Sin embargo, si una cuenta administrativa comprometida modifica contraseñas, el mismo evento puede resultar extremadamente importante.

Por eso merece quedar registrado y contextualizado.

Monitorización de MFA

Otra actividad detectada estuvo relacionada con la eliminación o modificación de un método de autenticación sin contraseña.

Los métodos MFA forman parte de la protección de identidad.

Por tanto, cualquier alta, baja o modificación puede ser relevante.

Especialmente para:

  • administradores;
  • usuarios con acceso a información sensible;
  • cuentas con privilegios.

Una modificación legítima es habitual.

Una modificación inesperada puede necesitar investigación.

Nuevos dispositivos observados

El correlador de Microsoft 365 también detectó un primer inicio de sesión interactivo desde un nuevo deviceId.

Este tipo de regla personalizada puede ayudar a detectar rápidamente cuando aparece un nuevo dispositivo asociado a una identidad.

Puede corresponder a:

  • renovación del teléfono;
  • nuevo portátil;
  • reinstalación;
  • alta corporativa.

Pero también podría ser:

  • un dispositivo desconocido;
  • un acceso no previsto.

Nuevamente:

la detección abre la investigación, no dicta automáticamente la conclusión.

SIEM Wazuh en empresas y aplicaciones de Microsoft 365

También aparecieron eventos relacionados con la creación de nuevos service principals.

Un service principal representa una identidad utilizada por una aplicación o servicio dentro de Microsoft Entra.

Esto permite que aplicaciones legítimas puedan trabajar con:

  • Microsoft Graph;
  • usuarios;
  • grupos;
  • datos;
  • automatizaciones.

Sin embargo, precisamente porque pueden recibir permisos, resulta recomendable supervisar:

  • nuevas aplicaciones;
  • nuevos consentimientos;
  • cambios de privilegios;
  • modificaciones de service principals.

Así podemos detectar rápidamente cambios que necesiten validación.

127.385 registros de SonicWall

SonicWall fue la fuente individual con mayor volumen de telemetría:

127.385 registros durante la semana.

Pero es fundamental explicar correctamente qué significa.

SonicWall:

detecta, genera y registra eventos.

Posteriormente:

nuestro SOC analiza los logs y su contexto.

Entre los eventos habituales de un firewall pueden existir:

  • conexiones;
  • bloqueos;
  • escaneos;
  • VPN;
  • reglas;
  • servicios;
  • tráfico de red.

Miles de registros de firewall no significan miles de ataques.

SIEM Wazuh en empresas y firewall

Centralizar la telemetría del firewall permite responder preguntas posteriormente.

Por ejemplo:

¿Qué IP intentó conectar?

¿Qué puerto utilizó?

¿Fue permitida o descartada?

¿Habíamos visto anteriormente esa dirección?

¿Coincide con actividad de un servidor?

¿Existe un evento en el endpoint?

Aquí aparece el verdadero valor de relacionar fuentes.

El firewall observa una parte de la historia.

El endpoint observa otra.

Microsoft 365 aporta la identidad.

El SIEM permite intentar unirlas.

33.422 registros de UniFi

La infraestructura UniFi produjo 33.422 registros durante la semana 35.

Además, el indicador semanal de pérdida de paquetes registró 0 eventos.

La telemetría de red puede incluir información procedente de:

  • gateways;
  • switches;
  • puntos de acceso;
  • clientes;
  • eventos operativos.

Esto amplía la visibilidad más allá de los ordenadores.

Una infraestructura empresarial también depende de la red.

Switches y puntos de acceso también generan información útil

Cuando un usuario comunica:

“La red iba mal esta mañana.”

puede haber diferentes causas.

Por ejemplo:

  • endpoint;
  • WiFi;
  • switch;
  • gateway;
  • conexión WAN.

Si disponemos de telemetría histórica resulta más sencillo reconstruir qué estaba ocurriendo.

Por tanto, la monitorización no debe centrarse únicamente en amenazas.

También puede ayudar en disponibilidad y diagnóstico.

11.461 registros de Kaspersky

Kaspersky generó 11.461 registros durante la semana.

El resumen no identificó eventos críticos de Kaspersky durante el periodo analizado.

Nuevamente:

11.461 registros ≠ 11.461 amenazas.

Un antivirus genera telemetría relacionada con:

  • funcionamiento;
  • comprobaciones;
  • actualizaciones;
  • eventos del agente;
  • protección.

El SOC necesita localizar dentro de ese volumen las señales que realmente requieren atención.

Windows generó 9.339 registros

Windows aportó 9.339 registros durante la semana 35.

El resumen semanal registró:

0 detecciones Windows de alta confianza.

Sin embargo, los logs Windows siguen siendo una fuente fundamental.

Pueden aportar información sobre:

  • inicios de sesión;
  • procesos;
  • servicios;
  • errores;
  • cambios;
  • actividad administrativa;
  • seguridad.

Además, pueden correlacionarse con información de firewall, antivirus o Microsoft 365.

Correlación Windows / SonicWall: cero coincidencias confirmadas

El correlador Windows / SonicWall estuvo activo y operativo durante el periodo.

Sin embargo, no produjo correlaciones multisource confirmadas durante la semana.

Esto es completamente válido.

Un correlador no debería generar alertas porque sí.

Debe hacerlo cuando se cumplen condiciones específicas.

Por ejemplo:

evento endpoint + conexión firewall + misma IP + misma ventana temporal

Si no existe coincidencia suficiente, no debe inventarse una relación.

Correlación Microsoft 365 / endpoint: cero eventos

Tampoco se confirmaron correlaciones entre Microsoft 365 y las fuentes endpoint durante la semana.

Sin embargo, disponer del correlador activo permite buscar escenarios como:

inicio de sesión anómalo

evento en endpoint

conexión de red

Cuando varias señales coinciden, un comportamiento inicialmente débil puede adquirir mayor relevancia.

SIEM Wazuh en empresas y correlaciones personalizadas

Una de las ventajas de un SIEM es que las reglas pueden adaptarse al entorno.

No todas las empresas tienen:

  • las mismas aplicaciones;
  • los mismos servidores;
  • los mismos riesgos;
  • los mismos usuarios.

Por eso utilizamos correlaciones personalizadas según cada infraestructura.

Por ejemplo:

  • Windows + SonicWall;
  • Microsoft 365 + endpoint;
  • identidad + nuevo dispositivo;
  • firewall + endpoint;
  • antivirus + red;
  • actividad administrativa + usuario.

El objetivo es conseguir alertas que tengan contexto para esa empresa concreta.

Alertas personalizadas de indicadores de compromiso

También podemos generar reglas relacionadas con indicadores de compromiso.

Por ejemplo:

  • IP;
  • dominios;
  • patrones;
  • eventos;
  • comportamientos;
  • secuencias.

Sin embargo, debemos mantener siempre una diferencia:

indicador no significa compromiso confirmado.

Una IP puede aparecer en una lista.

Un dominio puede tener reputación negativa.

Una conexión puede resultar anómala.

Después debemos analizar:

  • origen;
  • destino;
  • contexto;
  • frecuencia;
  • relación con otros sistemas.

SIEM Wazuh en empresas para Windows, macOS y Linux

Wazuh permite recopilar información de diferentes sistemas operativos y fuentes.

Entre ellos:

  • Windows;
  • macOS;
  • Linux.

Además, puede integrarse con otras tecnologías mediante:

  • agentes;
  • syslog;
  • APIs;
  • archivos de logs;
  • integraciones específicas.

Puede consultar las capacidades directamente en la documentación oficial de Wazuh.

Esto permite construir una plataforma común incluso en empresas que utilizan diferentes sistemas operativos.

Servidores: uno de los principales activos a monitorizar

Los servidores suelen concentrar información especialmente importante.

Por ejemplo:

  • aplicaciones;
  • usuarios;
  • archivos;
  • bases de datos;
  • servicios.

Por tanto, disponer de logs permite investigar:

  • accesos;
  • procesos;
  • cambios;
  • errores;
  • autenticaciones;
  • actividad inesperada.

Además, estos eventos pueden relacionarse con el firewall o con otros endpoints.

NAS y almacenamiento

Un NAS también puede convertirse en un activo crítico.

Puede almacenar:

  • documentación;
  • proyectos;
  • copias;
  • archivos compartidos.

En una ingeniería, despacho o estudio de arquitectura puede contener años de trabajo.

Por tanto, cuando el dispositivo permite exportar telemetría útil, conviene integrarlo dentro de la estrategia de monitorización.

Firewall, switches y AP forman parte de la seguridad

La infraestructura de comunicaciones también debe supervisarse.

Un firewall controla el perímetro.

Un switch conecta los dispositivos.

Un punto de acceso proporciona conectividad inalámbrica.

Cada componente genera información diferente.

Por eso el SIEM Wazuh en empresas puede aportar más valor cuanto mejor seleccionemos las fuentes relevantes.

Microsoft 365 ya es un activo crítico para muchas empresas

Para muchas organizaciones, Microsoft 365 contiene:

  • correo;
  • documentación;
  • conversaciones;
  • identidades;
  • archivos;
  • calendarios.

Por tanto, proteger únicamente los servidores locales ya no es suficiente.

Hay que supervisar también el cloud.

Durante esta semana, Microsoft 365 produjo 77.938 eventos únicos, muy por encima de otras semanas recientes.

Precisamente por ese volumen, disponer de reglas que prioricen actividad sensible resulta fundamental.

El volumen de Microsoft 365 demuestra por qué necesitamos automatización

Revisar manualmente 77.938 registros sería poco práctico.

Por eso una plataforma SIEM ayuda a:

  • procesar;
  • clasificar;
  • filtrar;
  • correlacionar;
  • priorizar.

Después, el analista puede centrarse en los eventos de mayor interés.

Automatización y análisis humano cumplen funciones diferentes.

La automatización reduce volumen.

El SOC aporta contexto.

El SOC no es simplemente una bandeja de alertas

Un SOC debe responder preguntas.

Por ejemplo:

¿Este evento es legítimo?

¿Se esperaba este cambio?

¿Existe una segunda señal?

¿Debemos contactar con el cliente?

¿Hay que actuar?

Eso es muy diferente de recibir automáticamente cientos de correos.

Una alerta que nadie revisa aporta poco valor.

SIEM Wazuh en empresas y retención de 400 días

En nuestros servicios conservamos hasta 400 días de histórico de logs.

¿Por qué?

Porque un incidente no siempre se descubre inmediatamente.

Imaginemos que hoy encontramos una cuenta comprometida.

Entonces queremos saber:

¿Cuándo apareció por primera vez la actividad?

¿Qué ocurrió hace tres meses?

¿Ya vimos esa IP?

¿Qué archivos se consultaron?

¿Hubo accesos anteriores?

Sin histórico, las respuestas pueden haber desaparecido.

400 días ayudan en investigaciones y auditorías

Un histórico amplio puede resultar útil para:

  • incidentes;
  • investigaciones;
  • auditorías;
  • análisis forense;
  • revisión de tendencias;
  • comprobaciones posteriores.

Los eventos antiguos no tienen únicamente valor operativo.

También pueden convertirse en evidencia.

Por eso la retención debe definirse antes de necesitarla.

SIEM Wazuh en empresas y respuesta a incidentes

Cuando aparece una incidencia, uno de los primeros objetivos es reconstruir la línea temporal.

Por ejemplo:

09:10 → inicio de sesión

09:15 → acceso a archivos

09:22 → conexión exterior

09:25 → evento endpoint

Si disponemos de todas las fuentes, podemos intentar reconstruir esa secuencia.

Sin ellas, cada pieza queda aislada.

Una empresa necesita saber qué está ocurriendo también cuando todo parece funcionar

La monitorización no debería activarse únicamente después de sufrir un ataque.

Precisamente su valor está en funcionar antes.

Durante la semana 35:

  • no hubo detecciones Windows de alta confianza;
  • no hubo eventos críticos Kaspersky;
  • no hubo eventos relevantes de perímetro;
  • no hubo correlaciones multisource confirmadas.

Eso también es información.

Significa que los controles continuaron funcionando y que no se detectaron determinadas condiciones de riesgo definidas.

SIEM Wazuh en empresas y estado de la plataforma

El propio sistema de monitorización también necesita supervisión.

Al cierre del informe semanal:

  • clúster: GREEN
  • shards: 479
  • memoria utilizada: 29,8 %
  • disco utilizado: 16,7 %
  • pérdida de paquetes UniFi: 0 eventos semanales

Además, permanecían activos:

  • wazuh-manager;
  • wazuh-indexer;
  • wazuh-dashboard;
  • filebeat;
  • postfix.

Por tanto, la plataforma disponía de capacidad y sus principales servicios continuaban funcionando.

¿Por qué monitorizamos también Wazuh?

Porque un SIEM que deja de recibir eventos puede producir una falsa sensación de seguridad.

Imaginemos:

el dashboard funciona

pero

Filebeat dejó de enviar registros hace tres días.

Podríamos pensar que no existen alertas cuando realmente hemos perdido visibilidad.

Por eso resulta importante controlar:

  • última telemetría;
  • servicios;
  • almacenamiento;
  • memoria;
  • correladores;
  • fuentes.

Semana 35: Microsoft 365 fue la principal fuente de actividad relevante

El elemento más destacable de esta semana fue Microsoft 365.

No porque se haya confirmado un compromiso.

Sino porque se produjo un importante volumen de actividad, especialmente en:

  • SharePoint;
  • OneDrive;
  • Entra ID.

Además, las reglas detectaron cambios administrativos y operaciones sensibles que necesitaban contexto.

Esto demuestra por qué Microsoft 365 también debería formar parte de la estrategia de monitorización empresarial.

SIEM Wazuh en empresas para administraciones de fincas

Una administración de fincas puede gestionar:

  • información de propietarios;
  • cuentas bancarias;
  • proveedores;
  • documentación;
  • Microsoft 365;
  • certificados.

Por tanto, un incidente puede involucrar diferentes sistemas.

Disponer de logs centralizados ayuda a conocer qué ocurrió en:

usuario + equipo + Microsoft 365 + firewall

y no únicamente en una aplicación.

Asesorías laborales y contables

Las asesorías manejan:

  • nóminas;
  • DNI;
  • contratos;
  • cuentas bancarias;
  • información fiscal.

Además, dependen intensamente de:

  • correo;
  • Microsoft 365;
  • aplicaciones profesionales;
  • servidores.

Por tanto, la visibilidad sobre identidad, dispositivos y red resulta especialmente importante.

Despachos de abogados

Los despachos jurídicos necesitan proteger la confidencialidad de:

  • expedientes;
  • comunicaciones;
  • documentos;
  • clientes.

Un SIEM puede contribuir a centralizar señales procedentes de diferentes capas.

Sin embargo, siempre debe combinarse con otras medidas.

Por ejemplo:

  • MFA;
  • Endpoint / EDR;
  • firewall;
  • copias;
  • actualizaciones.

Arquitectura, interiorismo, construcción e ingeniería

Estos sectores pueden depender de:

  • NAS;
  • servidores;
  • VPN;
  • Microsoft 365;
  • grandes repositorios de archivos.

Además, un problema no tiene por qué ser únicamente un ataque.

Puede ser:

  • caída;
  • error;
  • pérdida de conectividad;
  • saturación;
  • acceso inesperado.

La monitorización ayuda también a disponer de información técnica para investigar estos escenarios.

Un despacho profesional en una vivienda también necesita visibilidad

Una pequeña empresa puede pensar que un SIEM solo tiene sentido para grandes organizaciones.

Sin embargo, un despacho profesional puede utilizar:

  • Microsoft 365;
  • VPN;
  • NAS;
  • firewall;
  • varios ordenadores.

Y gestionar información sensible de numerosos clientes.

El tamaño de la oficina no determina por sí solo el riesgo.

Lo importante es:

qué información maneja y de qué sistemas depende.

SIEM Wazuh en empresas no sustituye al firewall

Cada tecnología tiene una función diferente.

Firewall

controla comunicaciones.

Endpoint / EDR

protege y supervisa dispositivos.

Microsoft 365

proporciona servicios cloud y genera telemetría.

SIEM Wazuh

centraliza y correlaciona.

SOC

analiza y contextualiza.

Por tanto, no deberían plantearse como soluciones rivales.

Se complementan.

Tampoco sustituye las copias de seguridad

Un SIEM puede indicar qué ocurrió.

Una copia permite recuperar información.

Por tanto:

logs ≠ backup

Los dos son importantes.

Si un servidor queda cifrado:

la copia puede ayudar a recuperarlo.

Pero los logs pueden ayudar a entender:

  • cómo entró el atacante;
  • cuándo;
  • qué cuenta utilizó;
  • qué hizo antes.

La ciberseguridad necesita prevención y visibilidad

Podemos resumir la estrategia en dos grandes áreas.

Prevención

  • MFA
  • firewall
  • Endpoint / EDR
  • actualizaciones
  • segmentación
  • copias

Visibilidad

  • logs
  • SIEM
  • correlaciones
  • SOC
  • histórico

Una reduce las probabilidades.

La otra ayuda a detectar y comprender.

¿Qué información debería monitorizar una empresa?

Depende de su infraestructura.

Sin embargo, puede resultar interesante revisar:

  • Microsoft 365;
  • Windows;
  • macOS;
  • Linux;
  • servidores;
  • NAS;
  • firewall;
  • switches;
  • puntos de acceso;
  • antivirus.

No es necesario recopilar cada log posible.

Hay que seleccionar aquello que tenga valor operativo y de seguridad.

Las reglas deben adaptarse a cada infraestructura

Una empresa con Microsoft 365 necesita unas reglas.

Otra con servidores Linux necesitará además otras.

Una empresa con VPN puede necesitar revisar:

  • conexiones;
  • países;
  • usuarios;
  • intentos.

Una organización con SharePoint puede querer detectar:

  • accesos masivos;
  • cambios;
  • actividad administrativa.

Por eso las reglas genéricas son solamente el principio.

SIEM Wazuh en empresas y reducción de falsos positivos

Cuantas más alertas generamos, mayor puede ser el ruido.

Por eso una buena regla necesita contexto.

Por ejemplo:

300 archivos accedidos

puede parecer mucho.

Pero si corresponde a OneDrive sincronizando una biblioteca, quizá sea completamente normal.

En cambio:

300 archivos + nuevo dispositivo + acceso inusual + evento endpoint

puede necesitar una revisión diferente.

Ahí es donde las correlaciones pueden aportar mayor valor.

Los eventos de seguridad necesitan una línea base

Para detectar lo raro necesitamos conocer lo normal.

Por ejemplo:

Un usuario suele acceder a 20 documentos diarios.

De repente accede a 2.000.

Eso puede resultar interesante.

Pero otra persona trabaja diariamente con miles de documentos.

Por tanto, las reglas deben ajustarse al contexto.

Con el tiempo, la monitorización permite conocer mejor los patrones habituales de cada entorno.

Semana 35: principales conclusiones

Durante la semana 35 de 2026, nuestro SOC analizó 259.545 registros procedentes de las principales fuentes integradas.

Microsoft 365 generó 77.938 eventos únicos y concentró los 293 eventos relevantes de seguridad del resumen semanal.

La actividad destacada estuvo relacionada principalmente con:

  • operaciones sobre SharePoint y OneDrive;
  • cambios de usuarios y grupos;
  • modificaciones de Acceso Condicional;
  • credenciales y MFA;
  • service principals;
  • nuevos dispositivos.

Al mismo tiempo:

  • Windows registró 0 detecciones de alta confianza;
  • Kaspersky registró 0 eventos críticos;
  • SonicWall/UniFi registraron 0 eventos relevantes en el resumen;
  • no hubo correlaciones multisource confirmadas;
  • la plataforma Wazuh permaneció operativa y en estado GREEN.

Conclusión: SIEM Wazuh en empresas convierte 259.545 registros en información útil

El SIEM Wazuh en empresas permitió centralizar durante la semana 35 de 2026 259.545 registros procedentes de Windows, SonicWall, UniFi, Kaspersky y Microsoft 365.

Pero el dato realmente importante fue poder reducir ese volumen hasta localizar 293 eventos relevantes de Microsoft 365 que requerían contexto.

Entre ellos aparecieron:

  • actividad elevada en SharePoint y OneDrive;
  • cambios en Acceso Condicional;
  • modificaciones de usuarios y grupos;
  • cambios de autenticación;
  • nuevos dispositivos;
  • aplicaciones y service principals.

Ninguna de estas señales debe convertirse automáticamente en un “ataque”.

La tecnología detecta el comportamiento.

Nuestro SOC analiza los logs, revisa el contexto y determina qué actividad necesita investigación o actuación.

Además, conservar hasta 400 días de histórico nos permite volver atrás cuando una incidencia no se descubre inmediatamente y facilita investigaciones, auditorías y análisis posteriores.

En GHM Soluciones Informáticas combinamos SIEM Wazuh para empresas, ciberseguridad empresarial, Endpoint / EDR, firewalls administrados, Microsoft 365 y monitorización SOC.

Porque una empresa no necesita únicamente generar logs.

Necesita poder responder:

¿qué ocurrió, cuándo ocurrió y qué debemos hacer ahora?

Contactar con GHM Soluciones Informáticas

Preguntas frecuentes sobre SIEM Wazuh en empresas

¿Qué es un SIEM Wazuh en empresas?

Un SIEM Wazuh en empresas permite centralizar y procesar registros procedentes de diferentes sistemas para mejorar la detección, investigación, correlación y trazabilidad de eventos.

¿Cuántos registros se analizaron durante la semana 35?

Las fuentes incluidas en el informe generaron 259.545 registros durante el periodo comprendido entre el 21 y el 28 de agosto de 2026.

¿Qué fuentes se monitorizaron?

El resumen incluye telemetría de Windows, SonicWall, UniFi, Kaspersky y Microsoft 365.

Además, Wazuh puede incorporar otras fuentes como macOS, Linux, servidores, NAS, firewalls, switches y puntos de acceso según las capacidades de cada sistema.

¿Cuántos registros produjo Microsoft 365?

Microsoft 365 generó 77.938 eventos únicos durante la semana.

¿Cuántos eventos relevantes de seguridad hubo?

El resumen semanal registró 293 eventos relevantes de Microsoft 365.

¿Los 293 eventos significan que hubo 293 ataques?

No. Un evento relevante es una actividad que una regla ha identificado para revisión. Puede corresponder a una acción administrativa o a comportamiento legítimo que necesita contexto.

¿Qué generó la mayor parte de esos eventos?

Una regla relacionada con lectura elevada de SharePoint/OneDrive produjo 276 eventos FileAccessed dentro del resumen.

¿Una lectura masiva de SharePoint significa robo de datos?

No necesariamente. Puede deberse a sincronización, trabajo legítimo, migraciones u otros procesos. El contexto es necesario antes de clasificarla como incidente.

¿Se detectaron cambios en Acceso Condicional?

Sí. Las reglas registraron creación y modificación de políticas de Acceso Condicional durante la semana.

¿Hubo cambios de contraseña y MFA?

Sí. Se registraron operaciones relacionadas con restablecimiento de contraseña y modificación de métodos de autenticación. Esto no implica que fueran maliciosas, pero son acciones sensibles que conviene supervisar.

¿Hubo detecciones Windows de alta confianza?

No. El informe semanal registró 0 detecciones de alta confianza.

¿Hubo eventos críticos de Kaspersky?

No. El resumen registró 0 eventos críticos de Kaspersky.

¿Hubo eventos relevantes de perímetro?

El resumen semanal registró 0 eventos relevantes de perímetro SonicWall/UniFi.

¿Hubo correlaciones confirmadas entre distintas fuentes?

No. Tanto el correlador Windows/SonicWall como el correlador Microsoft 365/endpoint registraron cero correlaciones confirmadas durante el periodo.

¿Por qué conservar 400 días de logs?

Porque algunos incidentes se descubren semanas o meses después. Mantener un histórico amplio permite buscar actividad anterior, reconstruir líneas temporales y conservar evidencia para auditorías e investigaciones.

¿Puede Wazuh monitorizar servidores?

Sí. Dependiendo del sistema y de la integración disponible puede recopilar registros de servidores Windows, Linux y otras plataformas.

¿Puede monitorizar macOS?

Sí. Wazuh dispone de agente y capacidades de recopilación para macOS.

¿Puede integrar firewalls, switches o puntos de acceso?

Sí, cuando los dispositivos permiten exportar logs mediante mecanismos compatibles como syslog, APIs u otras integraciones.

¿Puede monitorizar Microsoft 365?

Sí. Es posible integrar diferentes fuentes de auditoría de Microsoft 365 y Entra ID para disponer de registros sobre identidad, correo, SharePoint, OneDrive y otros servicios.

¿Qué diferencia existe entre SIEM y SOC?

El SIEM recopila, procesa y correlaciona información.

El SOC analiza esa información y su contexto para determinar qué actividad necesita investigación o actuación.

¿Cuál fue el estado de Wazuh durante esta semana?

La plataforma permaneció operativa con clúster GREEN, 29,8 % de memoria utilizada, 16,7 % de disco y los principales servicios activos.

¿Un SIEM sustituye al antivirus o firewall?

No.

SIEM, firewall, Endpoint / EDR, MFA, copias y monitorización realizan funciones diferentes y deben combinarse dentro de una estrategia de seguridad por capas.