Visibilidad de la red a través del SIEM

La imagen a continuación muestra un ejemplo de una red sencilla que incluye múltiples endpoints basados en Linux/Windows, un servidor de datos y un sitio web. Cada componente se comunica con los demás o accede a Internet a través de un enrutador.

Cada componente de una red puede generar varias fuentes de registros (logs), que contienen información sobre diferentes eventos, por lo que podemos dividir las fuentes de logs de la red en dos categorías.

1. Fuentes de logs centradas en el host

Estas fuentes capturan eventos que ocurren dentro o están relacionados con un equipo específico. Algunos ejemplos incluyen Windows Event Logs, Sysmon y Osquery.

Algunos eventos que se registran en esta categoría son:

• Acceso a archivos por parte de un usuario

• Intentos de autenticación

• Ejecución de procesos

• Modificación de claves o valores en el registro de Windows

• Ejecución de scripts en PowerShell

2. Fuentes de logs centradas en la red

Estos registros se generan cuando los equipos se comunican entre sí o acceden a internet para visitar sitios web. Protocolos comunes incluyen SSH, VPN, HTTP/HTTPS, FTP, entre otros.

Algunos ejemplos de eventos en esta categoría son:

• Conexiones SSH

• Acceso a archivos mediante FTP

• Tráfico web

• Acceso a recursos de la empresa a través de VPN

• Compartición de archivos en la red

Los dispositivos generan cientos de eventos por segundo, revisar los registros en cada dispositivo de manera individual en caso de incidentes puede ser una tarea muy tediosa. Aquí es donde un SIEM resulta fundamental.

Un SIEM también permite correlacionar eventos, realizar búsquedas, investigar incidentes y responder rápidamente.

Algunas funciones clave que ofrece un SIEM son:

• Ingesta de logs en tiempo real

• Alertas ante actividades anómalas

• Monitoreo y visibilidad 24/7

• Detección temprana para proteger contra las amenazas más recientes

• Análisis de datos y visualización de información

• Capacidad de investigar incidentes pasados

Fuentes de logs e ingestión de logs

1. Endpoints Windows

En sistemas Windows, cada evento que ocurre en el sistema se registra en el visor de eventos, una utilidad que permite visualizar toda la actividad del sistema. Cada tipo de evento recibe un identificador único, lo que facilita la revisión y el seguimiento de los registros.

Todos estos registros, provenientes de los endpoints con Windows, se envían automáticamente a la solución SIEM. Esto permite un monitoreo centralizado, mejor visibilidad y análisis en tiempo real de toda la actividad en la red.

2. Endpoints Linux

Linux recopila y almacena todos los registros relacionados con el sistema, incluyendo eventos, errores, advertencias y más. Estos logs son enviados de manera continua a la plataforma SIEM para su monitoreo constante y análisis en tiempo real.

Las ubicaciones más comunes donde Linux guarda estos registros son:

• /var/log/httpd: Aquí se almacenan los registros de solicitudes y respuestas HTTP, así como los errores relacionados con el servidor web.

• /var/log/cron: En esta carpeta se registran los eventos relacionados con las tareas programadas mediante cron.

• /var/log/auth.log y /var/log/secure: Estos archivos contienen los registros relacionados con la autenticación y accesos del sistema.

• /var/log/kern: En este archivo se guardan los eventos relacionados con el núcleo del sistema (kernel).

A continuación vemos un ejemplo de el log de cron:

May 28 13:04:20 ebr crond[2843]: /usr/sbin/crond 4.4 dillon's cron daemon, started with loglevel notice
May 28 13:04:20 ebr crond[2843]: no timestamp found (user root job sys-hourly)
May 28 13:04:20 ebr crond[2843]: no timestamp found (user root job sys-daily)
May 28 13:04:20 ebr crond[2843]: no timestamp found (user root job sys-weekly)
May 28 13:04:20 ebr crond[2843]: no timestamp found (user root job sys-monthly)
Jun 13 07:46:22 ebr crond[3592]: unable to exec /usr/sbin/sendmail: cron output for user root job sys-daily to /dev/null

3. Servidor Web

En cuanto a los servidores web también es importante vigilar todas las solicitudes y respuestas que entran y salen del servidor web por posibles intentos de ataques.

En Linux, las ubicaciones comunes para guardar todos los registros relacionados con Apache son:

• /var/log/apache

• /var/log/httpd.

A continuación muestro un ejemplo de el log de acceso de apache2.

test@test:/var/log/apache2$ ls
access.log  error.log  other_vhosts_access.log

test@test:/var/log/apache2$ cat access.log
192.168.2.185 - - [15/Jul/2025:11:02:39 +0000] "GET / HTTP/1.1" 200 3460 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36"

192.168.2.185 - - [15/Jul/2025:11:02:39 +0000] "GET /favicon.ico HTTP/1.1" 404 490 "http://192.168.2.31/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36"

4. Ingestión de Logs

Todos estos registros contienen información valiosa que puede ayudar a detectar posibles problemas de seguridad. Cada solución SIEM tiene su propia forma de recolectar estos logs.

A continuación, se describen algunos métodos comunes que utilizan:

• Agente o Agente de Reenvío: Muchas soluciones SIEM utilizan un pequeño programa llamado agente, que se instala en los endpoints. Este agente se configura para recopilar los registros importantes y enviarlos automáticamente al servidor SIEM.

• Syslog: Es un protocolo muy utilizado para recopilar datos de diferentes sistemas, como servidores web o bases de datos. Los datos se envían en tiempo real a un destino centralizado para su análisis.

• Subida Manual: Algunas plataformas SIEM, como Splunk o ELK, permiten importar datos offline para su revisión rápida. Una vez cargados, los datos se normalizan y quedan disponibles para su análisis.

• Reenvío de Puertos: También es posible configurar el SIEM para que escuche en un puerto específico, y los endpoints envíen la información a ese puerto para su procesamiento.

En el caso de la solución SIEM Splunk, nos ofrece diferentes métodos para la recolección/subida de logs.

¿Porque utilizar SIEM?

El SIEM se utiliza para correlacionar la información recopilada y detectar posibles amenazas.

Cuando se identifica una amenaza o se supera cierto umbral, se genera una alerta. Esta alerta permite a los analistas tomar acciones apropiadas según la investigación. El SIEM es fundamental en el ámbito de la ciberseguridad, ya que ayuda a detectar y protegerse contra las amenazas más recientes de forma rápida.

El SIEM es uno de los componentes principales de un Centro de Operaciones de Seguridad (SOC). Su función comienza con la recopilación de logs y la evaluación para determinar si algún evento o flujo coincide con las condiciones definidas en las reglas o si supera ciertos límites.

Capacidades del SIEM

Algunas capacidades clave del SIEM son:

• Detectar correlaciones entre eventos provenientes de diferentes fuentes de logs.

• Brindar visibilidad tanto de actividades en los hosts como en la red.

• Facilitar a los analistas investigar las amenazas más recientes y responder de manera oportuna.

• Realizar búsquedas avanzadas para detectar amenazas que no hayan sido identificadas por las reglas existentes.

Responsabilidades como Analista SOC

El analista de SOC emplea soluciones SIEM para obtener una visión más clara de las actividades en la red.

Algunas de sus tareas principales son:

• Supervisar e investigar eventos de seguridad.

• Detectar y gestionar falsos positivos.

• Ajustar las reglas para reducir el ruido y evitar alertas incorrectas.

• Elaborar informes y asegurar el cumplimiento de normativas.

• Detectar áreas de la red que no están siendo monitoreadas y ampliar la cobertura para mejorar la visibilidad.

Analizando Logs y Alertas

La herramienta SIEM recibe todos los logs relacionados con la seguridad mediante agentes, reenvío de puertos, etc. Una vez que los logs son ingeridos, el SIEM busca comportamientos no deseados o patrones sospechosos dentro de los registros, utilizando las condiciones establecidas en las reglas por los analistas. Si se cumple alguna condición, se activa una regla y se investiga el incidente.

Dashboard / Panel de Control

Los paneles de control (dashboards) son los componentes más importantes de cualquier SIEM. El SIEM presenta los datos para su análisis después de ser normalizados y procesados. El resumen de estos análisis se muestra en forma de información accionable mediante múltiples paneles. Cada solución SIEM incluye algunos paneles predeterminados y ofrece la opción de crear paneles personalizados.

Algunas de la información que se puede encontrar en un panel son:

• Resumen de Alertas

• Notificaciones del Sistema

• Alertas de Estado

• Lista de Intentos de Inicio de Sesión Fallidos

• Cantidad de Eventos Ingeridos

• Reglas Activadas

• Principales Dominios Visitados

A continuación, ejemplo de como se ve un dashboard en la solución SIEM Qradar.

Reglas de Correlación

Las reglas de correlación desempeñan un papel importante en la detección oportuna de amenazas, permitiendo a los analistas actuar a tiempo. Las reglas de correlación son básicamente expresiones lógicas configuradas para activarse.

Algunos ejemplos de reglas de correlación son:

• Si un usuario realiza 5 intentos fallidos de inicio de sesión en 10 segundos, generar una alerta por Multiple Failed Login Attempts.

• Si un inicio de sesión es exitoso después de múltiples intentos fallidos, generar una alerta por Successful Login After multiple Login Attempts.

• Se configura una regla para alertar cada vez que un usuario conecta un USB (útil si el uso de USB está restringido según la política de la empresa).

• Si el tráfico saliente es mayor a 25 MB, generar una alerta por posible intento de exfiltración de datos (generalmente, esto depende de la política de la empresa).

Cómo se crean las Reglas de Correlación

Para explicar cómo funciona la regla, considere los siguientes casos de uso en Eventlog:

Caso de Uso 1

Los adversarios suelen eliminar los registros durante la fase de post-explotación para borrar sus rastros. Cada vez que un usuario intenta eliminar o limpiar los registros de eventos, se registra un "Event ID" único, por ejemplo, el ID 104. Para crear una regla basada en esta actividad, podemos establecer la siguiente condición:

Regla: Si la fuente del registro es WinEventLog y el EventID es 104, activar una alerta de Registro de eventos limpiado / Event Log Cleared.

Caso de Uso 2

Los adversarios utilizan comandos como whoami después de la fase de explotación o escalada de privilegios.

Los siguientes campos serán útiles para incluir en la regla:

• Fuente del registro (Log source): Identificar la fuente que captura los registros de eventos.

• ID de evento (Event ID): ¿Qué ID de evento está asociado con la actividad de ejecución de procesos? En este caso, el ID 4688 será útil.

• NewProcessName: ¿Qué nombre de proceso será útil incluir en la regla?

Regla: Si la fuente del registro es WinEventLog, el código de evento (EventCode) es 4688, y el campo NewProcessName contiene "whoami", entonces activar una ALERTA: Ejecución del comando WHOAMI detectada / WHOAMI command Execution DETECTED.

Investigación de Alertas

Cuando se monitorea un SIEM, la mayor parte del tiempo se dedica a los paneles de control o dashboards, ya que en ellos se muestra de forma resumida los detalles clave de la red.

Cuando se activa una alerta, se examinan los eventos asociados y se verifica qué condiciones de la regla se cumplen. En base a la investigación el analista determinará si la alerta es Verdadero/Falso positivo.

Algunas de las acciones que se realizan tras el análisis son las siguientes:

• La alerta es un Falso Positivo: puede ser necesario ajustar la regla para evitar que se generen falsos positivos similares en el futuro.

• La alerta es un Verdadero Positivo: se realiza una investigación más profunda.

• Contactar al propietario del activo para consultar sobre la actividad detectada.

• Si se confirma actividad sospechosa: aislar el host infectado.

• Bloquear la IP sospechosa.

Parte práctica - Laboratorio

En el laboratorio estático adjunto, se muestran un ejemplo de panel y eventos. Cuando se detecta actividad sospechosa, se activa una alerta, lo que significa que algunos eventos cumplen con la condición de alguna regla ya configurada.

Hacemos click en Start Suspicious Activity y nos saltará una alerta.

En este caso aparece un proceso llamado cudominer.exe, para más información clickamos sobre el mismo.

Debemos identificar el evento que generó la alerta, en este caso identificamos que el usuario responsable de la ejecución del proceso fue Chris.fort.

Además podemos identificar que el hostname que corresponde al equipo de este usuario es HR_02.

Si continuamos investigando descubriremos la regla pre-configurada que hizo saltar la alerta al detectar este proceso.

Esta regla genera una alerta llamada "Potential CryptoMiner Activity" (Actividad potencial de minería de criptomonedas).

Se activa cuando se cumple la siguiente condición:

• EventID = 4688: Indica que se trata de un evento de creación de un nuevo proceso en Windows.

• Log_Source = WindowsEventLogs: El origen del evento es el registro de eventos de Windows.

• ProcessName = (miner OR crypt): El nombre del proceso contiene las palabras "miner" o "crypt".

Por lo tanto podemos verificar que se trata de un Verdadero Positivo, y debemos tomar medidas al respecto, como aislar el endpoint y tomar las medidas necesarias.