Después de 1 mes y medio alejado de las redes por vacaciones, trabajo y demás, volvemos con un artículo que a más de uno le pueda servir de ayuda sobre todo en la parte de BlueTeam e Integración. Vamos a ver como realizar la integración de Sophos Central con un SIEM, en este caso el SIEM que voy a utilizar y el cual tengo montado para uso personal es SPLUNK.

Descripción

En este artículo, veremos como se integra a través de un script que podemos descargar desde Github. Como alguno sabrá, también es posible integrar Sophos Central en Splunk a través de un TA, el problema que tenemos a la hora de hacerlo de esta manera es que solo permite 1 API por TA y si tenemos varios clientes, no nos sirve ya que son varias API para un único TA.

He de comentar que en principio no importa que tipo de SIEM estemos utilizando, siempre y cuando este pueda recoger inputs locales o recibirlos a través de SYSLOG. Para este caso se va a realizar recogiendo un archivo local y añadiéndolo al SIEM para su monitorización.

Requisitos

Para la integración de Sophos Central con nuestra solución SIEM, necesitaremos descargar desde Github el script que nos permite realizar la llamada a la “API + Headers”, para así extraer las alertas y eventos que se produzcan en la consola de Sophos Central.

• Descarga del Script: https://github.com/sophos/Sophos-Central-SIEM-Integration

Descargamos el script, en mi caso lo he ubicado dentro del directorio «etc» en el directorio home de Splunk: /opt/splunk/etc/Sophos-Central-SIEM/

Output de help del binario «siem.py» :

El archivo que tendremos que modificar para añadir la API es «config.ini«, lo veremos en pasos siguientes.

Generación de API en Sophos Central

Pasamos a Sophos Central para generar la API. Os dejo las imágenes para que sea más visual:

Nos dirigimos a «Configuración global» > «Administración de token de API»:

Presionamos en la esquina superior derecha en «Añadir Token«, establecemos un nombre para nuestra API Token y guardamos:

Nos apareceran directamente las API’s generadas, para este caso nos interesa «URL acceso API + Encabezados«, la copiamos directamente del botón en el lateral de esta:

Modificación de Script y añadir API

Una vez generada y copiada la API que necesitaremos, tendremos que dirigirnos al directorio que hemos descargado desde Github y editar el archivo de configuración «config.ini«, pegaremos la API en la 4ª línea que comienza con «token_info«:

Podemos elegir el formato de salida que tendrán los eventos generados (json, cef o keyvalue), el nombre del archivo output txt que los contendrá, nos permite elegir si queremos eventos, alertas o todo (event, alert o all) y por último nos permite configurar las propiedades para un reenvío a través de Syslog, el cual no utilizaremos en este caso.

Una vez añadida la API, procedemos a ejecutar el archivo «siem.py» y obtendremos el archivo con el nombre indicado anteriormente en la ubicación «./log/ARCHIVO.txt«

Podemos visualizar el archivo output generado:

He de comentar que cuando ejecutamos «siem.py«, extraerá únicamente los eventos/alertas nuevos que no han sido generados anteriormente como máximo en 24 horas, en su ejecución inicial únicamente recupera las últimas 12 horas ya que no tenemos generado el archivo de estado. A través de los comandos en la ejecución del binario, podemos indicarle que en su ejecución inicial, recoja las últimas 24 horas (-s SINCE o –since=SINCE). 

En la carpeta «state«, se almacena el estado en el cual quedó en la última ejecución para que así no se duplique la extracción de eventos/alertas en el archivo output.

Bien, ya tenemos el archivo de configuración «config.ini» con la API añadida y se ha realizado la primera ejecución de «siem.py», solo nos faltaría automatizar el proceso para ejecutar el binario «siem.py» cada X tiempo para que las alertas y eventos se vayan agregando automáticamente al archivo de salida txt.

Tengo que comentar que tuve problemas a la hora de automatizar la ejecución del binario, si lo añadía directamente con «crontab -e«, no se ejecutaba correctamente. Al final decidí crear un script en bash (por llamarlo de alguna forma) que contuviese el cambio de directorio a la ubicación del binario y la ejecución y en el archivo crontab alojado en /etc añadir el comando para que se ejecute cada X tiempo.

Existe la posibilidad de realizar la automatización desde el propio Splunk añadiendo Scripts y tiempo de ejecución, pero creo que es mejor que estos procesos se lleven a cabo fuera de la solución Siem, ya que le estaríamos añadiendo un consumo extra. 

De todas formas si alguien conoce otra alternativa para realizar este proceso, que lo deje en los comentarios y estaré agradecido de poder leerlo y añadirlo a la lista =P

Vamos al lío, creamos el script en bash:

Le asignamos permisos de ejecución y nos dirijimos a /etc para editar el archivo crontab directamente con el editor, añadimos la última línea que nos permitirá automatizar el proceso de ejecución.

Como se puede ver en la imagen, está puesto para que se ejecute cada 1 min ya que estuve realizando comprobaciones por el tema del script y demás, pero podéis indicarle el tiempo que consideréis necesario:

Una vez modificado y los cambios guardados en el archivo crontab, comprobamos en «/var/log/syslog» que se está ejecutando correctamente:

Como podemos ver en la imagen anterior, el proceso se ejecuta cada minuto, bien hemos terminado la primera parte, pasemos a la segunda parte que tiene que ver con Splunk y como añadir Inputs Locales.

Agregando Local Input en Splunk

Nos dirigimos a Splunk y hacemos clic en «Settings» > «Data Inputs»:

Tenemos que añadir un nuevo Local Input de tipo Files & Directories. Hacemos clic en «+ Add new»:

Nos abrirá la ventana para configurar y seleccionar el archivo local.

Seleccionamos Continuously Monitor para que constantemente esté comprobando el contenido del archivo e indexarlo, hacemos clic en Browse y seleccionamos el archivo que vamos a monitorizar, en este caso el archivo output txt que genera el binario siem.py.

Una vez realizado, continuamos pulsando en Next en la parte superior.

Como vemos, se muestran los eventos/alertas generados en formato JSON. Podemos elegir un «Source Type» para identificar estos eventos según origen:

Configuramos el Source Type para identificar al cliente y pulsamos nuevamente en Next:

Ahora toca el turno de seleccionar el tipo de App Context – Search & Reporting (Search)  y  crear el Index (Índice) para agrupar todos los eventos, esto nos permitirá tener en un mismo saco todos los eventos y alertas de Sophos, hacemos clic en Create a new index y lo creamos.

Cuando se nos abra la ventana para crear el Index, únicamente introducimos un nombre para este, el resto se deja por defecto. Pulsamos en Next:

En la siguiente ventana, nos mostrará un pequeño resúmen del Local Input a crear:

Para finalizar pulsamos en Submit y en la siguiente ventana presionamos en Start Searching para empezar a realizar búsquedas en Splunk:

Recordemos que el tipo de lenguaje que utiliza Splunk para la búsqueda y creación de queries, se denomina SPL (Search Processing Language), para todos aquellos que no lo sepan, es un tipo de lenguaje que combina las mejores capacidades de SQL con la sintaxis de tuberías de Unix.

Resultado de búsqueda y tabla

Para comprobar que el archivo monitorizado está siendo indexado correctamente, podemos realizar una consulta simple utilizando el nombre del Index que hemos definido y podremos comprobar como se nos muestran correctamente los eventos:

Ya para terminar, si nos queremos cercioar que efectivamente se está realizando la llamada a la API y recogiendo los eventos/alertas correctamente y de esta forma Splunk los va indexando, podemos generar una alerta en un Endpoint para que se genere una alerta en Sophos Central.

Yo he generado un par de alertas y he sacado una tabla para que se muestre de una forma más visual:

Resumen de campos JSON

• customer_id: Identificador único del cliente.
• datastream: Tipo log (alerta o evento).
• dhost: Nombre de la estación 
• endpoint_id: Identificador único del endpoint de la estación de trabajo.
• endpoint_type: Tipo de estación Endpoint.
• group: Tipo de política en Sophos Central.
• id: Identificador del evento/alerta generado.
• name: Pequeño resumen de evento/alerta.
• rt: Fecha/Hora de cuando se ha generado el evento/alerta.
• severity: Nivel de criticidad/severidad.
• source_info: Si hacemos clic en el desplegable, nos mostrará la dirección IP de la estación de trabajo donde está instalado el Endpoint de Sophos.
• suser: Nombre de usuario que ha generado el evento/alerta.

Documentación sobre Event Types Sophos API

https://community.sophos.com/kb/en-us/132727

Finalizando

Es posible que os estéis preguntando…¿Y como se añaden más clientes? Bueno, para añadir más clientes lo único que hay que realizar es copiar el directorio del script y duplicarlo, acordándose de añadir la API correspondiente en el archivo de configuración, añadirlo a crontab y al script creado en bash, a parte de añadir el Local Input en Splunk con un nuevo Source Type para identificar a este cliente. El Index puede ser el mismo para todos y así tenerlos todos los clientes indexados en uno.

También cabe la posibilidad de con un mismo Script, manejar diferentes API’s, pero sinceramente no lo he probado, si alguno quiere dejarme en los comentarios una forma alternativa con la que se pueda realizar, estaré encantado de leerte y aprender =D

Nos vemos en el próximo artículo.

Saludos!