10.- OSSIM Un poco de teoría.
10º artículo de la serie OSSIM. Parte 1, 2, 3, 4, 5, 6, 7 , 8. 9
Este artículo quizás podría ser el número uno. En este capítulo voy a hablar de la gestión de riesgos con OSSIM, que realmente es el propósito de esta suite.
También voy a intentar explicar el funcionamiento interno del sistema de eventos, alarmas, correlación.
OSSIM no es un gestor de log centralizado, como pueda ser cualquier servicio RSYSLOG. OSSIM es mucho más. Con OSSIM identificamos nuestros activos, establecemos prioridades en los eventos, creamos reglas que nos permiten gestionar el comportamiento de nuestros eventos, correlaciona eventos para detectar alertas,etc.
Empezamos el recorrido por nuestro sistema a monitorizar, las fuentes de logs. Podemos usar un servidor Windows o Linux instalando el agente OSSEC. Con este agente recopilamos información mediante los logs del sistema. OSSEC no es OSSIM. OSSEC es un HIDS (Host Intrusion Detection System) o mejor dicho LIDS ( Logs Intrusion Detection System). En comparación con un IDS de red como Snort, OSSEC no va a monitorizar los eventos de red para detectar un ataque, sino que "depende" de logs de Apache, Mod_security, firewall de Windows o cualquier aplicación que añadamos a la configuración de OSSEC para monitorizar.
Como hemos mencionado, podemos configurar cualquier LOG en OSSEC para ser monitorizado y enviado a OSSIM. Si tenemos un sistema Snort instalado previamente, podemos monitorizar sus ficheros de logs mediante el agente. Si por cualquier motivo no podemos instalar el agente OSSEC en el servidor/sistema Snort, podemos configurar Snort para que envíe log al servidor rsyslog de OSSIM.
Esto no es exclusivo para Snort, sino para CUALQUIER LOG.
Una de las herramientas que incorpora el propio OSSIM es SNORT. Esto quiere decir que podemos usar un Snort propio bajo un sensor, y que internamente envie información a OSSIM. Depende de tu infraestructura y necesidades el usar un Snort externo o usar el implementado con OSSIM.
He comentado arriba que podemos configurar OSSEC para que lea cualquier fichero de logs de nuestras aplicaciones pero... OSSIM en concreto lis plugins del sensor deben conocer la configuración de ese fichero. Cuando habilitamos plugins en el sensor debemos elegir los sistemas que vamos a parsear. Por ejemplo. Imagina que tienes un firewall Cisco, Fortigate o cualquiera de los populares. Si "conectamos" esa fuente de logs a nuestro sistema OSSIM, este entenderá perfectamente el formato del log.
Por supuesto que podemos crear nuestros plugins personalizados para nuestros sistemas.
Ya hemos obtenido logs y los hemos "parseado" con los plugins del sensor.
Este sensor es un componente de OSSIM. Podemos tener tantos sensores como nos apetezca. Al igual que hacemos con una instalación distribuida de Snort en la que tenemos un servidor central y varios sensores.
La instalación del sensor OSSIM ( no confundir con OSSEC) debe realizarse con el fichero ISO proporcionado por AlienVault, por lo que no se puede instalar en un servidor Linux en ejecución. Quizás tu si puedas, pero he repasado la documentación y foros y al parecer es mucho más que complejo.
Si tenemos un VPS externo a la organización, si tenemos una DMZ fuertemente protegida, o simplemente por cuestiones de rendimiento queremos usar otro sensor OSSIM, la opción más elegante es instalarlo como una VM dentro del segmento de red que queramos.
Cuando el plugin OSSIM parsea el log, identifica unos campos básicos y los normaliza en su base de datos. Uno de los campos principales es el identificador de seguridad o SID. Esto qué significa?. Imaginamos que tenemos un servidor Windows con un agente OSSEC instalado. Configuramos que se reenvíen todos los logs del sistema ( visor de eventos) al sistema OSSIM. OSSIM normaliza la información pero no va a mostrar un evento por cada registro. Como decía al principio, OSSIM es una consola para administrar eventos de seguridad. El plugin OSSEC dentro de OSSIM conoce los identificadores de eventos de Windows, y en ese proceso de normalización, asignará un SID concreto para ese evento. Mediante las políticas decidimos qué eventos queremos que se nos muestren.
Los campos "Destino" o que OSSIM normalizará son estos:
Una vez normalizado el log se convierte en un evento en OSSIM ( o quizás por nuestra configuración, desechamos ese evento. Como hicimos en la práctica de políticas personalizadas).
A este evento le asignamos unos valores para conseguir mediante la métrica de OSSIM un valor definido como RIESGO.
Por cada SID de nuestro plugin podemos atribuir un valor para estos dos conceptos:
Priority: Prioridad. La urgencia para investigar el evento.
Reliability: "Confiabilidad". La probabilidad de que el evento sea un falso positivo.
Por defecto os muestro algunos valores para el plugin OSSEC con sistemas Windows.
Ahora tenemos un evento normalizado y valorado según estos dos criterios.
Ahora nos referimos al artículo de personalización de activos, en donde veíamos como a cada activo o Asset se le asignaba un valor entre 0 y 5 según la importancia de este activo.
Con estos 3 parámetros se define el Riesgo como:
(ASSET VALUE * PRIORITY * RELIABILITY) / 25 = RISK OF THE EVENT
Por cada fabricante, metodología o normativa existe una formula para calcular el riesgo.
Por ejemplo aquí teneís dos formulas. 1 y 2.
Si quieres leer un poco más sobre este asunto, te recomiendo MAGERIT ( Metodología y gestión de riesgos de los sistemas de información.
Tenemos que tener en cuenta que por eventos que produzcan un Riesgo mayor a 1 se creará una alarma en OSSIM.
Una vez asignado el riesgo, OSSIM lo agrupa por una Taxonomia que nos será útil a la hora de filtrar la información en nuestros cuadros de mando e informes.
Si realizaste la inscripción en el servicio OTX como vimos anteriormente, ahora es el turno de comparar la ip de origen del evento con la base de datos pública de OTX para identificar ese equipo. Si el equipo es externo (IP publica) se enviará esa información al servicio OTX dado su carácter colaborativo o comunitario como quieras llamarlo.
El evento sigue de viaje !!! empezó siendo un log en un fichero, y ahora se ha hecho mayor !!! Es el turno para el motor de correlación, la verdadera punta de flecha de OSSIM. Cuando hablamos de correlación hablamos de identificar patrones de comportamiento entre elementos, que puedan ser de distinta fuente. Por ejemplo, un brute force sobre un servidor o servicio es fácil de detectar, pero imaginar un escenario distinto en el que un atacante tiene un usuario y clave SSH y lo que está haciendo es probar contra TODOS los equipos que corren un servidor SSH. No vamos a tener X intentos de conexión a un servidor, sino a varios servidores.
Podemos crear nuestras propias correlaciones con nuestras "paranoyas" de seguridad más complicadas. Una de las que he leído y por supuesto nunca he implementado es una correlación de autenticación wifi y lectores de presencia: Si tenemos un sistema de control de presencia para empleados, el típico lector de tarjetas, conectado a nuestro servidor OSSIM sabemos que usuarios están dentro del edificio. Si tenemos un sistema de Wi-fi autenticado conectado a OSSIM sabemos cuando un usuario se conecta: La magia se produce en forma de alerta o evento de seguridad a investigar cuando un empleado que NO ha pasado por el detector de tarjeta está conectado al sistema Wi-fi... La imaginación y las regular expressión al poder!!! :-)
Para ver algunos ejemplos que out-of-box de OSSIM:
Creo que no se me ha pasado ningún paso en el proceso de "gestión" de logs de OSSIM.
Espero que os haya servido de ayuda para comprender un poco más el mundo SIEM, y como OSSIM gestiona la entrada de información y como la procesa.
En siguiente capítulos seguiremos trabajando más en detalle con esta suite de herramientas.
Gracias por leerme !!!!
Este artículo quizás podría ser el número uno. En este capítulo voy a hablar de la gestión de riesgos con OSSIM, que realmente es el propósito de esta suite.
También voy a intentar explicar el funcionamiento interno del sistema de eventos, alarmas, correlación.
OSSIM no es un gestor de log centralizado, como pueda ser cualquier servicio RSYSLOG. OSSIM es mucho más. Con OSSIM identificamos nuestros activos, establecemos prioridades en los eventos, creamos reglas que nos permiten gestionar el comportamiento de nuestros eventos, correlaciona eventos para detectar alertas,etc.
Empezamos el recorrido por nuestro sistema a monitorizar, las fuentes de logs. Podemos usar un servidor Windows o Linux instalando el agente OSSEC. Con este agente recopilamos información mediante los logs del sistema. OSSEC no es OSSIM. OSSEC es un HIDS (Host Intrusion Detection System) o mejor dicho LIDS ( Logs Intrusion Detection System). En comparación con un IDS de red como Snort, OSSEC no va a monitorizar los eventos de red para detectar un ataque, sino que "depende" de logs de Apache, Mod_security, firewall de Windows o cualquier aplicación que añadamos a la configuración de OSSEC para monitorizar.
Como hemos mencionado, podemos configurar cualquier LOG en OSSEC para ser monitorizado y enviado a OSSIM. Si tenemos un sistema Snort instalado previamente, podemos monitorizar sus ficheros de logs mediante el agente. Si por cualquier motivo no podemos instalar el agente OSSEC en el servidor/sistema Snort, podemos configurar Snort para que envíe log al servidor rsyslog de OSSIM.
Esto no es exclusivo para Snort, sino para CUALQUIER LOG.
Una de las herramientas que incorpora el propio OSSIM es SNORT. Esto quiere decir que podemos usar un Snort propio bajo un sensor, y que internamente envie información a OSSIM. Depende de tu infraestructura y necesidades el usar un Snort externo o usar el implementado con OSSIM.
He comentado arriba que podemos configurar OSSEC para que lea cualquier fichero de logs de nuestras aplicaciones pero... OSSIM en concreto lis plugins del sensor deben conocer la configuración de ese fichero. Cuando habilitamos plugins en el sensor debemos elegir los sistemas que vamos a parsear. Por ejemplo. Imagina que tienes un firewall Cisco, Fortigate o cualquiera de los populares. Si "conectamos" esa fuente de logs a nuestro sistema OSSIM, este entenderá perfectamente el formato del log.
Por supuesto que podemos crear nuestros plugins personalizados para nuestros sistemas.
Ya hemos obtenido logs y los hemos "parseado" con los plugins del sensor.
Este sensor es un componente de OSSIM. Podemos tener tantos sensores como nos apetezca. Al igual que hacemos con una instalación distribuida de Snort en la que tenemos un servidor central y varios sensores.
La instalación del sensor OSSIM ( no confundir con OSSEC) debe realizarse con el fichero ISO proporcionado por AlienVault, por lo que no se puede instalar en un servidor Linux en ejecución. Quizás tu si puedas, pero he repasado la documentación y foros y al parecer es mucho más que complejo.
Si tenemos un VPS externo a la organización, si tenemos una DMZ fuertemente protegida, o simplemente por cuestiones de rendimiento queremos usar otro sensor OSSIM, la opción más elegante es instalarlo como una VM dentro del segmento de red que queramos.
Cuando el plugin OSSIM parsea el log, identifica unos campos básicos y los normaliza en su base de datos. Uno de los campos principales es el identificador de seguridad o SID. Esto qué significa?. Imaginamos que tenemos un servidor Windows con un agente OSSEC instalado. Configuramos que se reenvíen todos los logs del sistema ( visor de eventos) al sistema OSSIM. OSSIM normaliza la información pero no va a mostrar un evento por cada registro. Como decía al principio, OSSIM es una consola para administrar eventos de seguridad. El plugin OSSEC dentro de OSSIM conoce los identificadores de eventos de Windows, y en ese proceso de normalización, asignará un SID concreto para ese evento. Mediante las políticas decidimos qué eventos queremos que se nos muestren.
Los campos "Destino" o que OSSIM normalizará son estos:
Una vez normalizado el log se convierte en un evento en OSSIM ( o quizás por nuestra configuración, desechamos ese evento. Como hicimos en la práctica de políticas personalizadas).
A este evento le asignamos unos valores para conseguir mediante la métrica de OSSIM un valor definido como RIESGO.
Por cada SID de nuestro plugin podemos atribuir un valor para estos dos conceptos:
Priority: Prioridad. La urgencia para investigar el evento.
Reliability: "Confiabilidad". La probabilidad de que el evento sea un falso positivo.
Por defecto os muestro algunos valores para el plugin OSSEC con sistemas Windows.
Ahora tenemos un evento normalizado y valorado según estos dos criterios.
Ahora nos referimos al artículo de personalización de activos, en donde veíamos como a cada activo o Asset se le asignaba un valor entre 0 y 5 según la importancia de este activo.
Con estos 3 parámetros se define el Riesgo como:
(ASSET VALUE * PRIORITY * RELIABILITY) / 25 = RISK OF THE EVENT
Por cada fabricante, metodología o normativa existe una formula para calcular el riesgo.
Por ejemplo aquí teneís dos formulas. 1 y 2.
Si quieres leer un poco más sobre este asunto, te recomiendo MAGERIT ( Metodología y gestión de riesgos de los sistemas de información.
Tenemos que tener en cuenta que por eventos que produzcan un Riesgo mayor a 1 se creará una alarma en OSSIM.
Una vez asignado el riesgo, OSSIM lo agrupa por una Taxonomia que nos será útil a la hora de filtrar la información en nuestros cuadros de mando e informes.
Si realizaste la inscripción en el servicio OTX como vimos anteriormente, ahora es el turno de comparar la ip de origen del evento con la base de datos pública de OTX para identificar ese equipo. Si el equipo es externo (IP publica) se enviará esa información al servicio OTX dado su carácter colaborativo o comunitario como quieras llamarlo.
El evento sigue de viaje !!! empezó siendo un log en un fichero, y ahora se ha hecho mayor !!! Es el turno para el motor de correlación, la verdadera punta de flecha de OSSIM. Cuando hablamos de correlación hablamos de identificar patrones de comportamiento entre elementos, que puedan ser de distinta fuente. Por ejemplo, un brute force sobre un servidor o servicio es fácil de detectar, pero imaginar un escenario distinto en el que un atacante tiene un usuario y clave SSH y lo que está haciendo es probar contra TODOS los equipos que corren un servidor SSH. No vamos a tener X intentos de conexión a un servidor, sino a varios servidores.
Podemos crear nuestras propias correlaciones con nuestras "paranoyas" de seguridad más complicadas. Una de las que he leído y por supuesto nunca he implementado es una correlación de autenticación wifi y lectores de presencia: Si tenemos un sistema de control de presencia para empleados, el típico lector de tarjetas, conectado a nuestro servidor OSSIM sabemos que usuarios están dentro del edificio. Si tenemos un sistema de Wi-fi autenticado conectado a OSSIM sabemos cuando un usuario se conecta: La magia se produce en forma de alerta o evento de seguridad a investigar cuando un empleado que NO ha pasado por el detector de tarjeta está conectado al sistema Wi-fi... La imaginación y las regular expressión al poder!!! :-)
Para ver algunos ejemplos que out-of-box de OSSIM:
Creo que no se me ha pasado ningún paso en el proceso de "gestión" de logs de OSSIM.
Espero que os haya servido de ayuda para comprender un poco más el mundo SIEM, y como OSSIM gestiona la entrada de información y como la procesa.
En siguiente capítulos seguiremos trabajando más en detalle con esta suite de herramientas.
Gracias por leerme !!!!
