Diseño e Implementación de un Sistema de Gestión de Eventos e Información de Seguridad (SIEM) con Graylog

Es imprescindible para cualquier organización contar con una estrategia de monitoreo, análisis y prevención de incidentes de seguridad que puedan atentar contra la integridad, confidencialidad y disponibilidad de la información. Un SIEM permite el análisis de seguridad en tiempo real tanto de aplicaciones, dispositivos y redes pero en muchos casos estos sistemas representan elevados costos adicionales a la operación de una compañía pequeña/mediana por lo que, en esta ocacion, implementaremos un laboratorio Open Source como lo es GrayLog.

Es tarea primordial saber lo que está sucediendo en nuestra red. La visibilidad y el análisis son objetivos fundamentales no solo para la seguridad sino también para la disponibilidad y el cumplimiento de todos los servicios de TI.

Image for post
Image for post
Ilustración 1 — Kalpa Kalhara Sampath (2020). Top Free Security Information and Event Management(SIEM) Software’s

¿Que es un SIEM?

Las advertencias de la industria sobre amenazas en materia de seguridad van en aumento y cuanto más sofisticadas, más atraen nuestra atención, pero la base de una estructura de seguridad sólida comienza con algo más simple: los registros o eventos también llamados Logs.

El monitoreo e interpretación de estos logs junto con la mitigación de amenazas de seguridad internas y externas comienzan con un SIEM (por su siglas en inglés Security Information and Event Management / Sistema de Gestión de Eventos e Información de Seguridad).

Gartner utilizó el término “SIEM” en un reporte titulado “Mejore la Seguridad de IT con la Gestión de Vulnerabilidades” del año 2005. El término reúne los conceptos de Gestión de Eventos de Seguridad (SEM — Security Event Management) con el de Gestión de Información de Seguridad (SIM — Security Information Management) para obtener lo mejor de ambos mundos. SEM cubre la monitorización y correlación de eventos en tiempo real mientras que SIM lleva estos datos a un siguiente nivel que incluye el almacenamiento, análisis y generación de reportes/tableros de control.

Un SIEM se nutre de millones de logs diarios producidos por una infraestructura de TI (e IoT en algunos casos). A pesar del volumen de eventos y registros involucrados en una red, no suele ser tan complejo como parece: herramientas y procesos adecuados pueden ayudar a transformar nuestro SIEM en un núcleo procesable de información en tiempo real para la mitigación de ataques y amenazas.

Por qué y para qué implementar un SIEM

La gestión de eventos no solo significa almacenar todo el tráfico de la red en un “conglomerado” de datos. Los eventos/logs de firewalls, servidores, bases de datos, aplicaciones, IDPS (sistemas de detección/prevención de intrusos) y registros de acceso físico, por ejemplo, deben fluir hacia un sistema de registro centralizado para su posterior análisis. Si bien este es un primer paso válido, muchos departamentos dentro de las organizaciones asumen que la generación y envío de dichos registros a un repositorio central es la función principal de un SIEM; error.

El almacenamiento de registros y ejecución de informes no conforma el potencial de un SIEM. Los registros deben analizarse y correlacionarse para identificar eventos/patrones y alarmas para detectar posibles ataques y amenazas. Para gestionar estos millones de registros de forma continua y convertirlos en “inteligencia de seguridad” deberá existir cierto grado de automatización, ya que es prácticamente imposible depender únicamente de los administradores, ingenieros y analistas.

Aquí es donde entra en juego el SIEM como herramienta de correlación para procesar los datos, convertir registros/logs en información y alertar al usuario cuando se detecte cualquier comportamiento inusual.

Ventajas y “desventajas” al utilizar un SIEM

La visión global de la infraestructura desde un SIEM es posible sólo si esos datos están estandarizados para que pueda ejecutar su análisis y correlación de manera efectiva. Esto asume (y obliga) que los eventos provenientes de distintos sistemas y fuentes de datos posean un formato estandarizado.

- Ventaja: Un formato y estructura estandarizada reduce la carga de trabajo del equipo y permite tener una vista global de la actividad en una organización.

- Desventaja: Los datos no siempre estarán estandarizados o segregados de manera correcta. Esto implica un mayor consumo de tiempo en su preparación para que puedan ser correctamente interpretados por el SIEM. Los equipos de TI se enfrentan al problema(?) de tener que generar modelos y automatizaciones de estructuración de datos para luego generar la información de manera que se puedan reconocer, segmentar y analizar potenciales incidentes.

Dicho esto, la mayor ventaja de implementar exitosamente un SIEM es que permitirá en un corto plazo ganar tiempo en la deteccion y mitigación de incidentes. Al tener un sistema de alerta temprana y detección adecuada se pueden reducir, de manera considerable, amenazas emergentes y persistentes, así como vulnerabilidades o ataques desde el más simple al más complejo.

Lab SIEM — Intro

Decidí utilizar Graylog como herramienta SIEM el cual permite integrar en su instalación y configuración gran parte de los módulos de su “competencia” (Elasticsearch/MongoDB) pero por sobre todo, el alto volumen de documentación que éste y sus módulos poseen.

Topología de un Lab SIEM

Image for post
Image for post

Sistema seleccionado como actor SIEM:
- Graylog (Linux VM)

Agentes de monitoreo en dispositivos:
- SYSLOG-NG modo Cliente (Linux VM)
- NXLog (MS Windows VM)

Fuente externa para enriquecimiento de datos y geolocalización:
- MaxMind GeoLite2 Database

SYSLOG-NG

SYSLOG-NG es un reemplazo de syslogd para sistemas UNIX. Admite IPv6 y es capaz de enviar logs de manera confiable usando TCP/SSL con la posibilidad de filtrar el contenido de los mensajes usando expresiones regulares (RegEx).

También es posible la reescritura de mensajes y el formateo de mensajes en JSON. Esto hace que syslog-ng sea ideal para el preprocesamiento de eventos y su posterior análisis ya sean scripts propios o sistemas SIEM.

GRAYLOG

Graylog es una herramienta para la gestión de eventos que brinda muchas opciones para analizar logs entrantes de diferentes fuentes.

La forma en que funciona Graylog es bastante similar a ELK (Elasticsearch/Logstash/Kibana). Además del server Graylog (aplicación e interfaz web), también hace uso de MongoDB para el almacenamiento de configuraciones y Elasticsearch-OSS (Open Source Software) para ingestión de los eventos transformándose así en un pack 100% operativo.

NXLog

NXLog es un agente basado en syslog que permite leer registros multilínea (como los Windows Event Logs), reconocer su estructura y así poder reenviarlos a un gestor de eventos.

MaxMind GeoIP Database

GeoIP2 permite identificar la ubicación y otras características de los recursos en línea para una amplia gama de posibles aplicaciones, la geolocalización por sobre todo incluyendo personalización de contenido pero tambien la detección de fraude, orientación de anuncios, análisis de tráfico y compliance entre otras características.

Preparación e instalación del Lab

Como una instalación desde cero escapa al objetivo del articulo y es similar para cualquier otra distribución de Linux, se optó por la utilización de una máquina virtual open source (OVA — Open Virtual Appliance) provisto por el mismo sitio de Graylog: https://packages.graylog2.org/appliances/ova y la aplicación VirtualBox para su posterior carga e inicio. De acuerdo a su documentación, los requerimientos mínimos para el appliance Graylog son 4 GB de RAM y 2 CPU.

Paso 1.
Descargar el archivo graylog-3.3.5–1.ova

Paso 2.
Tras finalizar la importación, para arrancar la VM, pulsar en el botón “Iniciar”.

Tras iniciar la VM, la consola de la misma nos mostrará:

- La dirección IP donde está ejecutándose el la interfaz web de Graylog.
- Usuario:Password de acceso Web.
- usuario:password de acceso a la consola Linux.

Image for post
Image for post

Paso 3. Ingreso a interfaz de Graylog

Para iniciar sesión en la interfaz de Administración de Graylog se debe ingresar desde un navegador soportado (Mozilla, Chrome, Edge, Safari) usando la IP definida.

Image for post
Image for post

Una vez dentro de la interfaz web podemos ver diferentes pestañas las cuales veremos más adelante. Por el momento solo prestar atención al icono de alerta en el margen superior derecho.

Image for post
Image for post

Al pulsarlo, Graylog nos informa que existe un Nodo sin entradas/inputs en ejecución. Esto significa que por el momento no estamos recibiendo ningún evento. Teniendo en cuenta que acabamos de crear una VM y realizar un primer acceso esto era presumible por lo que comenzaremos a instalar y configurar en nuestra segunda VM nuestro cliente SYSLOG de monitoreo y captura de eventos para luego reenviarlos a nuestro Graylog SIEM.

Instalación de syslog-ng en VM Linux cliente

Paso 1.
Actualizar el repositorio de nuestra VM Linux.
ubuntu@SYSLOG:~$ sudo apt-get update

Paso 2.
Descargar la última versión de syslog-ng.
ubuntu@SYSLOG:~$ sudo apt-get install syslog-ng -y

Image for post
Image for post

Paso 3.
Verificar que el servicio de syslog-ng esté activo y ejecutándose.
ubuntu@SYSLOG:~$ sudo service syslog-ng status

Image for post
Image for post

Paso 4.
Una vez verificado que el servicio esté activo procederemos a configurar el reenvío de los datos hacia nuestro SIEM. Para esto utilizaremos el puerto 5140/TCP (Si bien el protocolo UDP cuenta con una velocidad de transmisión superior a TCP, lo hace a costa de una pérdida de precisión en la transmisión de la información y justamente es lo que intentamos prevenir)

Editamos el archivo syslog-ng.conf:
ubuntu@SYSLOG:/$ sudo vi /etc/syslog-ng/syslog-ng.conf

y, bajo el título:

########################
# Destinations
########################

Agregamos lo siguiente:

# GRAYLOG
# Defino el nuevo host destino/puerto
destination d_net {
syslog("192.168.0.18" port(5140));
};

# Indico a syslog-ng que envíe datos desde 's_src' al destino syslog antes definido
log {
source(s_src); # el parámetro s_scr fue definido en la configuración predeterminada de syslog-ng
destination(d_net);
};

Luego, guardamos el archivo.

Paso 4.
Reiniciamos el servicio de syslog-ng:
ubuntu@SYSLOG:/$ sudo service syslog-ng restart

Paso 5.
Configuración de nueva entrada (Input ) en Graylog.

Accedemos nuevamente a la interfaz web de Graylog y pulsamos sobre la pestaña “System” para luego seleccionar la opción “Inputs”

Image for post
Image for post

Se nos presentará una lista desplegable donde poder elegir el tipo de entrada que deseamos configurar

Image for post
Image for post

En nuestro caso seleccionaremos la opción “Syslog TCP” y pulsamos “Launch new input”.

Image for post
Image for post

Completamos el formulario con los datos correspondientes a nuestra VM cliente (cliente syslog-ng).

- Título de la entrada: algo descriptivo
- Dirección de enlace: IP/Host origen (Opcional)
- Puerto: puerto a monitorear

Image for post
Image for post

Ingresados todos los datos, podemos pulsar el botón “Save”

Image for post
Image for post

Paso 6.
De haber realizado todos los pasos anteriores y configuraciones correctamente observaremos que el icono de alerta anterior ha desaparecido y nuestro nuevo Input “SYSLOG-NG” fue creado y está ejecutandose satisfactoriamente.

Image for post
Image for post

Instalación de NXLog en VM Windows cliente

En nuestro caso la VM es un Windows 10 por lo que instalaremos el agente NXLog el cual permite enviar los eventos a nuestro SIEM en formato GELF (Graylog Extended Log Format).

Paso 1.
Primeramente en la interfaz de Graylog crearemos una nueva entrada siguiendo los pasos anteriormente descriptos pero en este caso seleccionando la opción “GELF UDP” de la lista desplegable. (GELF, Graylog Extended Log Format)

Image for post
Image for post

Luego pulsaremos “Launch new Input” y completamos el formulario con los datos correspondientes a nuestra VM cliente

- Título de la entrada: algo descriptivo
- Dirección de enlace: IP/Host origen (Opcional)
- Puerto: puerto a monitorear

A modo de ejemplo, para este caso añadiremos solo Título y Puerto a monitorear:

Image for post
Image for post

Observaremos a continuación que nuestro Input fue creado y está ejecutandose satisfactoriamente

Image for post
Image for post

Instalación y Configuración de NXLog en VM Windows cliente

La instalación del agente NXLog es prácticamente sencilla por lo que no lo cubriremos en esta instancia. Solo debemos descargar la versión Community Edition y seguir los pasos del asistente de instalación.

Paso 1.
Para configurar el agente ingresamos el path de instalación de NXLog C:\Program Files (x86)\nxlog\conf y procederemos a editar el archivo nxlog.conf

Al final del contenido del archivo insertamos lo siguiente:

# Extension a utilizar. Los tipos de módulo disponibles se encuentran en C:\Program Files (x86)\nxlog\modules\extension
<Extension _gelf>
Module xm_gelf
</Extension>

# Nombre Input deseado ‘winevt’ y módulo a utilizar ‘im_msvistalog’. Los tipos de input disponibles se encuentran en C:\Program Files (x86)\nxlog\modules\input
<Input winevt>
Module im_msvistalog
</Input>

# Nombre Output deseado. Módulo a utilizar ‘om_udp’, Host destino, Puerto y Formato. Los tipos de output disponibles se encuentran en C:\Program Files (x86)\nxlog\modules\output
<Output graylog>
Module om_udp
Host 192.168.0.18
Port 5142
OutputType GELF
</Output>

# Asignar un nombre y ruta a seguir nombre_input => nombre_output (respetar los espacios entre =>)
<Route graylog_route>
Path winevt => graylog
</Route>

Al finalizar, guardamos los cambios en el archivo.

Paso 2.
Ingresar a los servicios de windows (services.msc) en la VM cliente, buscar el servicio nxlog e iniciarlo.

Image for post
Image for post

Ejecutando búsquedas en Graylog.

A partir de este momento si pulsamos en el icono de graylog en el margen superior izquierdo nos llevará nuevamente al Home de nuestro SIEM. Aquí pulsaremos la pestaña “Search” para realizar búsquedas y analizar los datos obtenidos.

Image for post
Image for post

Podremos observar eventos provenientes de nuestras VMs almacenandose en Graylog y generando su histograma de mensajes

Image for post
Image for post

En este histograma también podremos elegir cómo visualizar los gráficos, por días, semanas, horas, etc.

Las búsquedas se hacen con una sintaxis particular pero con una curva de aprendizaje relativamente baja, por lo que podemos hacer búsquedas de eventos que tengan un campo con un valor concreto, mensajes que incluya alguno o todos los términos de una lista, que cumpla con una expresión regular, etc.

También podremos elegir el intervalo de tiempo para realizar búsquedas, que puede ser “relativo” (ej. los últimos 30 minutos) o absoluto, en el que elegiremos la fecha/hora de inicio y final del intervalo.

Image for post
Image for post

Para facilitar el no tener que realizar constantemente las mismas búsquedas podemos guardar una búsqueda, de esta forma se guardarán tanto los términos de la búsqueda como el intervalo de tiempo seleccionado bajo un nombre descriptivo. Así, podremos repetir la misma con tan solo seleccionarla de una lista, sin necesidad de volver a configurarla.

Image for post
Image for post

La documentación completa sobre el lenguaje de búsqueda utilizado por Graylog podrá encontrarla en el siguiente link: https://docs.graylog.org/en/3.3/pages/searching/query_language.html

Geolocalización mediante fuente externa

Paso 1.
Descargar la base de datos de información de geolocalización. Utilizaremos la base de datos MaxMind GeoLite2.

Paso 2.
El siguiente paso es almacenar la base de datos de geolocalización en el servidor SIEM y asegurarse de que los permisos de archivo estén configurados para permitir que Graylog pueda leer el archivo. En este ejemplo, guardaremos el archivo GeoLite2-City.mmdb en el path /etc/graylog/server

Paso 3.
Ahora necesitamos configurar la tabla de búsqueda (lookup table) para leer la base de datos cuando se le ingresa un input. Primero crearemos un “Data Adapter” desde la pestaña “System” > “Lookup Tables”.

Image for post
Image for post

y pulsar el botón “Create data adapter”

Image for post
Image for post

De la lista desplegable “Data Adapter Type” seleccionaremos “Geo IP — MaxMind™ Databases”

Image for post
Image for post

y completamos el formulario con los datos que correspondan. Al finalizar, pulsamos “Create Adapter”

Image for post
Image for post

Paso 4.
Necesitaremos crear un entrada Cache para la persistencia de los datos y agilizar la conversión.

De la lista desplegable “Cache Type” seleccionar Node-local, in-memory cache, luego completar el formulario con los datos que correspondan. Al finalizar pulsamos “Create Cache”

Image for post
Image for post

Paso 5.
En este último paso crearemos el Lookup Table en si, utilizando el Data Adapter y la Caché generados previamente.

Image for post
Image for post

Pulsamos el botón “Create lookup table” y completamos el formulario con los datos correspondientes a las configuraciones previas. Por último pulsamos “Create Lookup Table” para guardar los cambios.

Image for post
Image for post

Terminados estos ajustes tendremos configurado y operativo nuestro Lab SIEM en donde centralizar el análisis de logs al ser posible recibir eventos de múltiples sistemas. Además, no sólo recibiremos los eventos que ocurran en dichos sistemas y dispositivos, si no que también podremos formatearlos, gestionar cómo almacenarlos, realizar búsquedas, realizar un parseo de eventos para obtener la información que necesitemos y crear Tableros de control/Dashboards donde visualizar la información de manera gráfica, generar alertas y acciones tanto defensivas como ofensivas.

Image for post
Image for post

Conclusiones Finales

Con el armado de este Lab, solo hemos raspado la superficie del potencial de un SIEM sin embargo espero que sirva de base para iniciarse y comprender tanto su funcionamiento como sus posibles aplicaciones.

Si alguien me preguntara sobre cual SIEM utilizar, no soy de la idea de que uno sea mejor o peor que otro (incluso en materia de costos). En definitiva, si ha sido parte de una violación/filtracion de datos, y eventualmente lo será… el verdadero “costo” final sería el mismo.

La afirmación: “Se necesitan 20 años para construir una reputación y cinco minutos para arruinarla” sería válida para la mayoria de las organizaciones.
Entonces, ¿por qué limitarnos a utilizar solo un SIEM? ¿Por qué no aprovechar el potencial de diferentes herramientas para un objetivo común?. “Lo perfecto es enemigo de lo bueno”, Voltaire argumentaba que es preferible hacer una cosa con una calidad buena en un tiempo razonable, que algo excelente o perfecto dedicando a la tarea un tiempo excesivo. En la mayoría de áreas y proyectos exitosos pero especialmente en el mundo de la Seguridad Informática, se trata de ser lo más asertivo posible: buscando entender las necesidades y cubrirlas, sin malgastar tiempo y esfuerzo en aspectos innecesarios.

Creo firmemente que la mejor manera de evitar posibles violaciones y ataques en materia de seguridad es la capacitación constante de todos los recursos humanos que pertenezcan a una organización (internos y externos) así como la pasión de cada uno de nosotros, con el deseo de formar parte de algo especial y el trabajo en equipo.

Saludos!

Written by

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store