3.-OSSIM. Políticas y acciones personalizadas. ¿Qué hago como mis logs?
Tercer artículo de la serie sobre OSSIM nuestro framework para realizar nuestras tareas SIEM.
Parte 1, 2, 3, 4, 5, 6, 7 , 8. 9 10
Cuando hablamos de la gestión de la información nos referimos no solo a la detección y almacenamiento, sino a todas las posibles acciones que debemos llevar a cabo ante esas situaciones.
Vivimos en un mundo conectado a la red las 24 horas del día, y la pregunta no es ¿Tendré algún incidente de seguridad? sino ¿Cuando tendré algún incidente de seguridad?. Podríamos debatir largo y tendido sobre este concepto, sobre todo con directores financieros pero asumimos que estamos en esa corriente, en la de ser todo lo proactivos que podamos.
Vamos a poner un ejemplo sencillo. Has seguido la serie de artículos uno y dos, has montado tu sistema y recibes al día 1200 logs, o 12000. Aún no has conectado tus sistemas de producción, salvo el ejemplo que hicimos de instalar OSSEC en un servidor Windows. Solo con los propios logs de OSSIM del demonio ssh ya tenemos entretenimiento para rato. Podemos desactivar la monitorización del demonio ssh o podemos desactivar toda la monitorización del demonio en ese servidor, salgo los intentos de login con una clave incorrecta. Viendo el proceso descubriréis lo fácil e intuitivo que es.
Podemos movernos por las distintas opciones pinchando en los bloques de color o en los menús laterales.
Configuramos las opciones relativas al origen, destino, puertos.
Ahora configuramos los eventos. Podemos seleccionar eventos por su taxonomía, por la categorización que tienen, o bien por fuentes de datos o DS (data sources). Vamos a crearnos una fuente de datos específica para el componente SSHD.
Podríamos configurar de golpe todos los eventos generados por el sensor SSHD y creando una segunda política para incluir solo el evento de SSH password failure como notificación. Usamos la ordenación de políticas, como hacemos con los firewalls, para procesar primero la regla de "aceptar", en nuestro caso, la segunda regla.
O podemos hacerlo al revés. Seleccionando evento por evento dentro del sensor SSHD y dejando sin marcar el que queremos que SI notifique.
Dentro de las opciones relativas a las consecuencias nos vamos a centrar en la parte de SIEM. Solo queremos limpiar eventos innecesarios pero que pueden aportar valor.
En el próximo artículo haremos varias pruebas de acciones. La parte de Logger y fordwarding no está operativa en la versión OSSIM que estamos usando ( Alienvault=pago). Logger básicamente lo que hace es guardar los logs que recibimos de nuestras fuentes en formato RAW. OSSIM almacena las alertas generadas durante el tiempo que indiquemos, pero no conserva el log completo. Si hay campos que no se parsean por OSSIM se pierden. Por supuesto al alcanzar el ciclo de retención también se pierden. Podría ser necesario almacenar el log en raw para temas forenses, judiciales, etc. Fordwarding básicamente hace lo mismo con las alertas hacia otro servidor syslog.
Por defecto se retienen los eventos durante 5 días. Podemos configurarlo..
Para este ejemplo de "limpiar" los eventos SSH del propio servidor salvo las contraseñas incorrectas simplemente activaremos NO en Sql Storage. .
Set Event Priority:
Risk Assessment.
Logical Correlation.
Cross Correlation.
Sql Storage.
**Introducción.En próximos capítulos ampliaremos estos conceptos**
Risk Assessment. Establece niveles de alerta para eventos.
Cross Correlation. Referencias que se hacen entre eventos que contienen una ip de destino común. Por ejemplo, podríamos no almacenar un evento de fallo de inicio de sesión pero usar Cross Correlation. Varios intentos de inicio de sesión nos proporcionarían una correlación que llamamos "ataque de fuerza bruta" igual que las alertas de Snort y similares. Por supuesto podemos crear nuestras propias correlaciones...
Logical Correlation: Referencias entre eventos que no tienen por qué tener como denominador común la ip de destino. Pongamos un ejemplo, tenemos una regla que no alerta de los login correctos en un ssh. Tenemos una regla para los ataques de fuerza bruta, con 3 intentos en n tiempo. Imaginar que un atacante intenta una password, no la encuentra, intenta otra password y acierta. No tendríamos ningún evento de la intrusión. Podríamos haber creado esa referencia o directiva.
***
Ya tenemos configurada la gestión de los eventos del demonio ssh para que no nos inunde de información, pero conseguimos toda la potencia que nos ofrece un sistema de correlación de logs como OSSIM.
Espero que os haya gustado el artículo. En próximos capítulos ampliaremos mas información.
Gracias por leerme.
Parte 1, 2, 3, 4, 5, 6, 7 , 8. 9 10
Cuando hablamos de la gestión de la información nos referimos no solo a la detección y almacenamiento, sino a todas las posibles acciones que debemos llevar a cabo ante esas situaciones.
Vivimos en un mundo conectado a la red las 24 horas del día, y la pregunta no es ¿Tendré algún incidente de seguridad? sino ¿Cuando tendré algún incidente de seguridad?. Podríamos debatir largo y tendido sobre este concepto, sobre todo con directores financieros pero asumimos que estamos en esa corriente, en la de ser todo lo proactivos que podamos.
Vamos a poner un ejemplo sencillo. Has seguido la serie de artículos uno y dos, has montado tu sistema y recibes al día 1200 logs, o 12000. Aún no has conectado tus sistemas de producción, salvo el ejemplo que hicimos de instalar OSSEC en un servidor Windows. Solo con los propios logs de OSSIM del demonio ssh ya tenemos entretenimiento para rato. Podemos desactivar la monitorización del demonio ssh o podemos desactivar toda la monitorización del demonio en ese servidor, salgo los intentos de login con una clave incorrecta. Viendo el proceso descubriréis lo fácil e intuitivo que es.
Podemos trabajar con una política por defecto para todo el sistema, o para un política concreta para un servidor. En esta prueba realizaremos la política por defecto.
Podemos movernos por las distintas opciones pinchando en los bloques de color o en los menús laterales.
Configuramos las opciones relativas al origen, destino, puertos.
Ahora configuramos los eventos. Podemos seleccionar eventos por su taxonomía, por la categorización que tienen, o bien por fuentes de datos o DS (data sources). Vamos a crearnos una fuente de datos específica para el componente SSHD.
O podemos hacerlo al revés. Seleccionando evento por evento dentro del sensor SSHD y dejando sin marcar el que queremos que SI notifique.
Dentro de las opciones relativas a las consecuencias nos vamos a centrar en la parte de SIEM. Solo queremos limpiar eventos innecesarios pero que pueden aportar valor.
En el próximo artículo haremos varias pruebas de acciones. La parte de Logger y fordwarding no está operativa en la versión OSSIM que estamos usando ( Alienvault=pago). Logger básicamente lo que hace es guardar los logs que recibimos de nuestras fuentes en formato RAW. OSSIM almacena las alertas generadas durante el tiempo que indiquemos, pero no conserva el log completo. Si hay campos que no se parsean por OSSIM se pierden. Por supuesto al alcanzar el ciclo de retención también se pierden. Podría ser necesario almacenar el log en raw para temas forenses, judiciales, etc. Fordwarding básicamente hace lo mismo con las alertas hacia otro servidor syslog.
Por defecto se retienen los eventos durante 5 días. Podemos configurarlo..
Para este ejemplo de "limpiar" los eventos SSH del propio servidor salvo las contraseñas incorrectas simplemente activaremos NO en Sql Storage. .
Risk Assessment.
Logical Correlation.
Cross Correlation.
Sql Storage.
**Introducción.En próximos capítulos ampliaremos estos conceptos**
Risk Assessment. Establece niveles de alerta para eventos.
Cross Correlation. Referencias que se hacen entre eventos que contienen una ip de destino común. Por ejemplo, podríamos no almacenar un evento de fallo de inicio de sesión pero usar Cross Correlation. Varios intentos de inicio de sesión nos proporcionarían una correlación que llamamos "ataque de fuerza bruta" igual que las alertas de Snort y similares. Por supuesto podemos crear nuestras propias correlaciones...
Logical Correlation: Referencias entre eventos que no tienen por qué tener como denominador común la ip de destino. Pongamos un ejemplo, tenemos una regla que no alerta de los login correctos en un ssh. Tenemos una regla para los ataques de fuerza bruta, con 3 intentos en n tiempo. Imaginar que un atacante intenta una password, no la encuentra, intenta otra password y acierta. No tendríamos ningún evento de la intrusión. Podríamos haber creado esa referencia o directiva.
***
Ya tenemos configurada la gestión de los eventos del demonio ssh para que no nos inunde de información, pero conseguimos toda la potencia que nos ofrece un sistema de correlación de logs como OSSIM.
Espero que os haya gustado el artículo. En próximos capítulos ampliaremos mas información.
Gracias por leerme.
