Folleto Alienvault-OSSIM

SIATI, S.A. DE C.V. Domicilio Fiscal: R.F.C.: SIA 030407 9T8 Francisco Díaz Covarrubias No. 60, Int. 4 Col. San Rafael, C.P. 06470, México, D.F.

DESCRIPCIÓN GENERAL

DE

Tel.: (55) 5592-1945 y Fax: (55) 5592-5513, www.siati.com.mx


1. Introducción

OSSIM (Open Source Security Information Management System) agrupa más de 15 programas de código abierto proporcionando todos los niveles tecnológicos necesarios para cubrir el ciclo completo de la gestión de seguridad y crear centros remotos de supervisión de seguridad (SOC).

Esta característica lo hace un sistema complejo pero muy potente ya que añade las características de programas de seguridad y monitores de red muy consolidados, tales como Snort, Nessus, Nagios o Ntop.

Conjuntamente estas herramientas hacen posible un estrecho control sobre grandes redes, desplegando sensores de bajo costo y controlando la información desde un punto central. Ya existen extensas redes, con cientos de sensores, desplegadas en organizaciones gubernamentales, financieras o de telecomunicaciones. Abstracción

El propósito de OSSIM no es solo recolectar la información detallada y en profundidad que los IDS o los monitores pasivos pueden ofrecer, sino también implementar un proceso abstracto en el cual millones de eventos con un formato muy técnico y de bajo nivel, se convierten en unas docenas de alarmas de alto nivel mucho más comprensibles.

Una parte principal de la abstracción está sobre todo producida por el Motor de Correlación, que permite al administrador crear Directivas de Correlación o patrones para relacionar diferentes eventos, generando conclusiones de más alto nivel.

Un ejemplo típico de correlación podría ser “Gusano Detectado” después de encontrar un numero anormal de conexiones. También se podrían correlacionar algunas de estas Alarmas de Gusano Detectado para producir un nivel mas alto aún, “Alarma de Plaga”.

También existe una abstracción hecha por las Métricas de Seguridad y los paneles de Riesgos; unos permiten a un administrador crear Métricas específicas (pensando normalmente en el objetivo de cumplir las normas de seguridad) y los otros proporcionan una visualización agregada de la situación de riesgo de cada equipo y red.




Filtrado de Falsos Positivos

Un objetivo importante de correlacionar los eventos de seguridad es luchar contra el enorme volumen de falsos positivos creados por los IDS y por los dispositivos de seguridad en general. Las organizaciones reciben millones de ellos por día, haciendo imposible para un administrador comprobarlos todos.

Las Directivas de Correlación de OSSIM revisan estos eventos buscando evidencias para asegurarse de si son o no ataques reales. Por defecto damos un valor bajo al parámetro “Fiabilidad” de la mayoría de eventos; solamente aumentará si las comprobaciones proporcionadas por el Motor de Correlación resultan positivas.

Como ejemplo, una directiva de correlación comprobará, después de que se haya intentado ejecutar un troyano o exploit, si se produce cualquier respuesta desde el equipo atacado. También comprobará si el canal de comunicación persiste en cuanto a tiempo o datos transmitidos, o incluso si la máquina atacada se comporta de forma anómala durante las siguientes horas. Cada una de las comprobaciones que llegue a ser positiva nos llevará a creer más y más en que se está realizando un ataque real.

Las directivas de correlación son administradas por lo que llamamos el proceso de “Correlación Lógica”, aunque hay otros dos métodos de correlación para eliminar eficazmente los falsos positivos: “Correlación de Inventario” y “Correlación Cruzada”.

La correlación de inventario comprueba si el ataque afecta a un determinado servicio o sistema operativo, así como la versión de los mismos. Se asegura también de si el sistema atacado tiene ese S.O. y servicio activo, desestimando el evento si no es así.

La correlación cruzada (y valga la redundancia) “cruza” información de los IDS’s y los escáneres de vulnerabilidades, priorizando o despriorizando el evento en caso de ser vulnerable o no a ese ataque. Gestión del Riesgo

OSSIM actúa, informa y lanza respuestas utilizando parámetros de riesgo. El riesgo se calcula y almacena para cada uno de los eventos recolectados.

En el Proceso de Gestión de Seguridad se utiliza esta valoración; se desencadenan respuestas automáticas, se generan informes de alarmas y se toman medidas de la situación de riesgo de las redes. La administración, el ajuste y los procedimientos forenses deben ser guiados por estas medidas.

2. Recopilación de herramientas

Herramientas de código abierto Algunos de los productos de código abierto utilizados son:

• Snort: IDS • Nessus: Escáner de vulnerabilidades • Ntop: Monitor de red • Nagios: Monitor de disponibilidad

http://www.snort.org/

http://www.nessus.org/

http://www.ntop.org/

http://www.nagios.org/



• Osiris y Snare: IDS’s de Host • Spade y HW Aberant Behaviour: Detectores de anomalías • Arpwatch, P0f, Pads, y Fprobe: Monitores pasivos • Nmap: Escáner de red • Acid/Base: Analizador Forense • Otros pequeños programas como Oinkmaster, PHPAcl, fw1logcheck, ScanMap3D, etc • OSVDB: Base de datos de vulnerabilidades

Herramientas desarrolladas para OSSIM

La lista de módulos creados por el equipo de OSSIM para conectar los programas anteriores es:

• Sistema Recolector. • Motor de Correlación Lógica, Cruzada y de Inventario. • Gestor de Inventario. • Gestores para modificar prioridades, realizar ajustes, y crear Políticas de Recolección. • Generador de informes de Seguridad. • Gestor de Incidencias y Reacción a ellas. • Cumplimiento de Normas de Seguridad y Paneles de Métricas y medidas de Riesgo.

3. Arquitectura Un despliegue típico de OSSIM consiste en 4 elementos:

1. Sensores 2. Servidor de Control 3. Base de Datos 4. Frontal Web

A veces se utiliza un primer nivel instalando agentes en las máquinas monitorizadas, tal y como podemos ver.

Una característica muy importante es que OSSIM también puede recibir eventos de dispositivos comerciales o aplicaciones personalizadas gracias a una serie de plugins configurables, tanto específicos como genéricos.

También se pueden instalar motores de correlación en todos los Sensores, permitiendo correlación o filtrado a un bajo nivel, así como la implementación de políticas de Consolidación de eventos (para reducir drásticamente el ancho de banda).

http://osiris.shmoo.com/

http://http/www.intersectalliance.com/projects

http://www.bleedingsnort.com/

http://cricket.sourceforge.net/aberrant/rrd_hw.htm

http://www.securityfocus.com/tools/142

http://lcamtuf.coredump.cx/p0f.shtml

http://passive.sourceforge.net/

http://sourceforge.net/projects/fprobe

http://insecure.org/nmap

http://base.secureideas.net/

http://oinkmaster.sourceforge.net/

http://phpacl.sourceforge.net/

http://sourceforge.net/projects/fw1-loggrabber

http://scanmap3d.sourceforge.net/

http://osvdb.org/


Veamos que software se instala generalmente en cada elemento:

Sensor

Los sensores son desplegados en diferentes redes para monitorizar su actividad.

Generalmente los sensores contienen:

• Detectores de bajo nivel y monitores que pasivamente (sin afectar al rendimiento de la red) recolectan datos buscando patrones.

• Escáneres que pueden buscar vulnerabilidades en la red activamente (realizando conexiones).

• También suelen incluir el Agente OSSIM que recibe datos de máquinas de la red, como por ejemplo un router o firewall, y se comunica con su servidor de gestión “padre” para enviarle eventos.

En una configuración típica, un sensor de OSSIM podría realizar las siguientes funciones.

1. IDS (Snort). 2. Escáner de vulnerabilidades (Nessus). 3. Detección de anomalías (Spade, p0f, pads, arpwatch, RRD aberrant behaviour). 4. Análisis y Monitorización de la red (Ntop). 5. Recolección de datos de elementos locales; routers, firewalls, IDS’s, etc. 6. Procesos reactivos, incluso como un Firewall.

Servidor de Gestión

El Servidor de gestión realiza al menos las siguientes funciones: • Una serie de tareas principales tales como son Normalizar, Priorizar, Recolectar, Evaluar

el Riesgo, y ejecutar el Motor de Correlación.

• El mantenimiento y las tareas externas, tales como backups, backups programados, inventario online o lanzamiento de escaneos.

Base de Datos La BBDD almacena eventos e información útil para la gestión del sistema. Es una base de datos SQL.

Frontal El Frontal o Consola es la aplicación de visualización y gestión de los datos, en este caso un frontal web.



4. Reportes OSSIM incluye una gran cantidad de reportes de seguridad para el análisis tanto en tiempo real como forense:

• Métricas a Medida. • Métricas de Riesgo. • Consola Forense. • Reportes de Seguridad. • Reportes de Anomalías. • Reportes de Disponibilidad. • Reportes de Uso y Perfiles de Red.

Que pueden ser mostradas de muchas formas como se ve en los ejemplos: :

5. Funcionalidad El camino que recorren los paquetes consta de varias fases, pudiendo tener cada una de ellas diferentes sub-fases:

5.1.‐ Detectores 5.1.1.‐Detectores por Patrones Llamamos Detector a cualquier programa que escuche en la red, un socket o un fichero de log buscando patrones y produciendo eventos de seguridad cuando coincidan con dichos patrones.

La funcionalidad de los detectores tradicionales está basada en patrones, y el mejor ejemplo es un IDS (Intrusion Detection System), que será capaz de detectar patrones definidos utilizando firmas o reglas.



Prácticamente cualquier elemento en la red, como por ejemplo un router, una máquina de usuario o un firewall, tiene alguna capacidad para detectar patrones de seguridad. Estos elementos generan logs con los eventos producidos (patrones coincidentes), y esa información se recolecta para los motores de correlación.

Detectores por Patrones incluidos en OSSIM

OSSIM incluye algunos detectores por patrones de código abierto que se instalan en los Sensores. El detector básico por patrones incluido dentro de OSSIM es el NIDS (Network Intrusion Detection System) Snort. El propio Snort incluye varios preprocesadores para la detección de ataques. Otros detectores incluidos son Snare y el HIDS (Host Intrusion Detection System) Osiris

Detectores externos

OSSIM también incluye un Sistema Recolector que permite la obtención de datos de otros muchos dispositivos externos.

Este Sistema Recolector es alimentado por plugins que hacen posible que se reciban datos de elementos externos, como puedan ser sistemas operativos Windows, Linux y otros UNIX, firewalls como Checkpoint, o dispositivos de red como Cisco.

Se incluye una arquitectura de plugins personalizables que hace muy fácil la creación de un plugin específico para cualquier aplicación o dispositivo.

5.1.2.-Detectores por Anomalías

La habilidad para detectar anomalías es mas reciente que las coincidencias por patrones. En este caso no tenemos que decir al sistema de detección lo que es bueno y lo que es malo; puede aprender por si mismo y alertarnos cuando estadísticamente el comportamiento se desvíe lo suficiente de lo que ha aprendido como normal.

La Detección por Anomalías proporciona un punto de vista que es a la vez diferente y complementario a la Detección por Patrones. Esta técnica ofrece una solución para el control de acceso de usuarios privilegiados, como por ejemplo en los ataques internos realizados por empleados desleales, donde no




se viola ninguna política de seguridad y no se ejecuta ningún exploit. En cambio sí que representan una anomalía en el uso y la forma de usar un servicio.

Veamos algunos ejemplos donde los detectores de anomalías pueden ser útiles:

• Un nuevo ataque para el cual todavía no existen firmas podría producir una anomalía obvia aunque sorteasen los sistemas de detección por patrones

• Un gusano que se haya introducido en la organización, malware, un ataque de spam o incluso el uso de programas P2P generarán un número de conexiones anómalas que serán fáciles de detectar

• Podemos asimismo detectar: o Uso de servicios poco habituales en los orígenes o destinos de las

conexiones o Utilización de los recursos a horas extrañas o Exceso de tráfico o de número de conexiones o Cambios en el sistema operativo de una máquina, en la IP, la dirección

MAC, o los servicios activos.

Detectores por Anomalías incluidos en OSSIM

OSSIM es diferente de la mayoría de los productos SIM en el amplio uso que hace de la detección por anomalías. Los siguientes productos de código abierto están compilados en OSSIM y son utilizados para la detección por anomalías:

• Spade detecta conexiones inusuales en los puertos y direccionamientos utilizados

• Plugin Aberrant behaviour (comportamiento aberrante) de Ntop aprende los parámetros de uso normales y alerta cuando no se comportan en la manera predicha.

• Arpwatch se utiliza para detectar cambios de MAC.

• P0f se usa para detectar cambios en el S.O.

• Pads y Nmap detectan nuevos servicios de red que puedan aparecer o cambiar.

5.2. – Monitores

5.2.1.- Monitores de red Creemos que la monitorización es esencial para un sistema de seguridad, y en su ausencia los administradores de seguridad pueden estar ciegos ante eventos pasados ya que podrían no distinguir entre actividad normal y anormal siendo incapaces de ver el comportamiento de la red en su totalidad.

OSSIM es diferente de la mayoría de los SIM’s porque es capaz de correlacionar la información de cualquiera de los detectores o monitores, permitiéndonos crear Directivas de Correlación muy completas y útiles.


Perfiles de uso y Monitorización de Sesiones Los monitores de OSSIM crean un Perfil de uso para cada máquina en la red con la siguiente información:

• Información de uso de red de la máquina, tal como el número de bytes transmitidos a lo largo del tiempo.

• Información de actividad de los servicios, como por ejemplo el uso de mail o http

• La monitorización en tiempo real de las sesiones proporciona una instantánea de la situación de las sesiones en las que ha participado cada máquina

OSSIM proporciona estas tres capacidades de monitorización utilizando el monitor pasivo de Ntop, que puede actuar como un sniffer y ver la situación de la red con el grado más alto de detalle.

Flows (flujos).

Los flujos proporcionan información de tráfico estadística tales como orígenes, destinos, puertos, tráfico y duración de las sesiones.

Muchos dispositivos de red, como los routers Cisco, tienen agentes de flujo incluidos en sus sistemas operativos. Esto hace fácil el realizar un análisis de la red extenso y rápido. Los flujos dan una información menos detallada que los sniffers, pero permiten la monitorización distribuida sin tener que desplegar sensores en cada dominio de la red.

OSSIM tiene un plugin que permite implementar flujos con fprobe en sus Sensores, siendo la información visualizada dentro de Ntop.

5.2.2.-Monitores de Disponibilidad La disponibilidad de la información es importante para detectar ataques de Denegación de Servicio.

OSSIM incluye el monitor de disponibilidad Nagios, capaz de comprobar, mostrar e información de máquinas y redes que no estén disponibles.



Incluye también un plugin capaz de recolectar e incluir estos eventos en la correlación, los informes y los procesos de toma de decisiones.

5.2.3.-Monitores personalizados

Existe un plugin que hace posible el crear un Monitor Personalizado para extraer cada parámetro que queramos reunir, filtrar o consolidar, y enviar esta información al Servidor para que sea analizada por procesos de mas alto nivel.

Esto podría ser útil para lanzar un escaneo de Nmap después de una posible intrusión en una máquina o para comprobar el estado de un SAI después de un apagón.

5.3.‐ Escáneres de Vulnerabilidades

Los escáneres de vulnerabilidades permiten auditar la red desde el punto de vista específico en el que están localizados.

Buscan debilidades en los dispositivos de las redes analizadas, lanzando tests o simulaciones de ataques para comprobar si los niveles de red, servicio o aplicación son vulnerables desde esos puntos.

OSSIM incluye el escáner de seguridad Nessus 2.X, el mas completo y ampliamente distribuido.

Éste escáner puede ser instalado en cada uno de los sensores desplegados o en un servidor central, dependiendo de las necesidades de la auditoría. Los escaneos pueden ser lanzados automáticamente mediante un programador de tareas.

Los informes individuales con recogidos desde el servidor central, manteniendo así OSSIM una lista de vulnerabilidades para cada máquina de manera que la Correlación Cruzada pueda ser llevada a cabo por el Motor de Correlación. La información histórica de cada vulnerabilidad para cada máquina o red escaneada también se almacena.



5.4.‐ Inventariado Automático

El inventariado automático se realiza a nivel de los sensores con los detectores pasivos que pueden ver todo el tráfico. Este mecanismo de inventariado está también implementado en el servidor gracias a los escáneres de red que pueden encontrar máquinas y servicios activamente desde un punto central. Ambos métodos alimentan automáticamente la base de datos de inventario con la siguiente información:

• Tipo de S.O. y Versión. • Tipo de Servicio y Versión. • Direcciones MAC e IP.

OSSIM implementa inventariado automático usando los siguientes programas de código abierto:

• Nmap como un escáner de red (sin necesidad de instalar Agente). • P0f como un detector de S.O. pasivo (sin necesidad de instalar Agente). • Pads como un detector pasivo de servicios (sin necesidad de instalar Agente). • Arpwatch como un detector pasivo de cambios ARP (sin necesidad de instalar

Agente). • OCS como un Agente.

Es de resaltar que usando estas técnicas, sin instalar ningún Agente, el tipo de S.O. y la información de la versión detectada es únicamente aproximada debido a los métodos de suposición utilizados. Es en el lado del servidor donde la información puede ser insertada o cambiada manualmente.

5.5.‐ Sistema de Colección.

El proceso de recolección unifica los eventos de seguridad de todos los sistemas críticos de la organización en un único formato en una sola consola.

Con esos eventos unificados seremos capaces de observar todo lo relacionado con el estado de la seguridad en un momento particular del tiempo – vengan de donde vengan; un router un firewall, un IDS o un servidor UNIX- en la misma pantalla y con el mismo formato.

La recolección de datos puede hacerse de dos formas en la parte del sensor:

• Enviando los datos desde la máquina a ser analizada, usando un protocolo nativo, al Sensor más cercano que actuará como concentrador.

• Instalando agentes en la máquina a ser analizada, los cuales enviarán información al sensor.

Escoger un método u otro dependerá normalmente de la capacidad de las máquinas de enviar datos hacia el exterior y de lo que se quiera analizar.



5.5.1.-Agentes y Plugins de OSSIM

OSSIM tiene un proceso llamado “agente” instalado en todos sus sensores.

El agente tiene una serie de plugins que permiten analizar sintácticamente todos los eventos específicos para un sistema. Un ejemplo de plugins típicos podrían ser los usados para Windows, Checkpoint o Cisco. La lista actual de plugins se puede consultar en www.ossim.net.

Hay un plugin personalizable que hace más sencilla la recolección de información desde cualquier aplicación o dispositivo.

5.5.2.-Recolección, Normalización y Política de Priorización

Los plugins analizarán sintácticamente los logs y el agente los enviará por la red hacia el servidor.

Cuando los eventos llegan al servidor, ocurre una normalización de los valores de prioridad. Esta normalización es necesaria ya que cada detector categoriza las prioridades o amenazas de una forma diferente. Por ejemplo, la máxima prioridad de Snort es 3, mientras que UNIX tiene 8 niveles. En OSSIM todos los eventos son normalizados utilizando valores de prioridad entre 0 y 5.

Las tablas de normalización tienen una serie de valores por defecto que los administradores pueden cambiar individualmente para cada evento.

Existe también un Panel de Política donde la prioridad o la amenaza puede ser contextualizada en la topología de red, asignando por ejemplo valores mas altos a los ataques externos que a los internos, y rebajando la prioridad de los falsos positivos detectados.

5.5.3.-Recolección, Normalización y Política de Priorización.

Es posible instalar una política de priorización y directivas de correlación en cada sensor para filtrar y controlar la cantidad y tipo de eventos que serán recogidos.

Podemos por ejemplo consolidar un gran número de eventos similares y enviar únicamente uno.

Podemos evaluar asimismo el riesgo instantáneo en el nivel del sensor y recoger solo los eventos más importantes.

La política de priorización puede descargarse de un servidor padre, de forma que el sensor no necesita acceso directo a una base de datos, y se puede usar una política de priorización global en un servidor central para todos los sensores.


http://www.ossim.net/


6. Correlación

La correlación se realiza de 3 formas diferentes: • Correlación de diferentes eventos (Correlación

Lógica). • Correlación de eventos y vulnerabilidades

(Correlación Cruzada). • Correlación de eventos y sistemas operativos –

servicios (Correlación de Inventario).

La correlación puede reducir el número de eventos de un día de millones a menos de una docena, comprobando cada uno de ellos antes de alertar acerca suyo. Esto da información a la Consola con la que puede generar alarmas e informar de ellas en un formato abstracto mucho más comprensible y fácil de leer.

La aproximación del motor de correlación lógica es comprobar todos los eventos. Ya que podemos tener millones de alertas en un día no podemos confiar en ellas a menos que las comprobemos antes. El motor de correlación buscará evidencias o síntomas para analizar si el ataque es real o es un falso positivo.

6.1.‐Correlación Lógica

El principal propósito de la correlación lógica es buscar evidencias para comprobar si un evento de seguridad (o un conjunto de ellos) es verdad o es un falso positivo. Este es un tema importante en los sistemas de seguridad actuales. Podemos tener millones de eventos por día, pero la mayoría de ellos serán falsos positivos. Es necesario tener procesos automáticos para comprobar si un ataque se está llevando a cabo en realidad.

El motor de correlación lógica de OSSIM tiene como características:

• Origen híbrido, aceptando información de entrada tanto de los patrones de los detectores como de los indicadores de los monitores.

• Arquitectura recursiva ya que la salida serán eventos que pueden ser correlacionados de nuevo por otras directivas de correlación.

• Arquitectura jerárquica distribuida, ya que podemos definir n niveles de correlación en una topología distribuida.

• Definiciones flexibles orientadas a objetos y a rangos de tiempo para el escenario de cada directiva.

La correlación lógica se realiza mediante directivas de correlación que están implementadas como un árbol de nodos de condiciones lógicas. Este tipo de estructura es también conocido como árbol AND/OR, utilizado generalmente en sistemas de inteligencia artificial y del que OSSIM utiliza un tipo específico.




Cuando la condición de un nodo es satisfecha, el motor de correlación saltará al primer nodo hijo. Si no, saltará al siguiente hermano (nodo a la derecha al mismo nivel con el mismo padre). Esto implementa la operación “AND” en el eje Y y la operación “OR” en el eje X.

La variable de fiabilidad crece según el motor de correlación avanza a través de los nodos comprobando las coincidencias de las condiciones: cuantas mas coincidencias en los nodos tengamos (evidencias), mas posibilidades habrá de que el ataque sea cierto.

Cada directiva define un nuevo tipo de evento (heredando su nombre del de la directiva) y tiene una prioridad específica, ya que la mayor parte de las veces indica patrones más amplios que los eventos que lo han generado.

Este nuevo evento se tratará como uno mas de los que analiza OSSIM (probablemente con una alta fiabilidad) y será reinsertado en la cola de ejecución tal y como si procediese de un agente externo. Creamos así un camino recursivo donde se pueden implementar diferentes niveles de correlación.

6.2.‐Correlación Cruzada

La correlación cruzada permite priorizar o despriorizar eventos para los que sabemos que un activo determinado es (o no) vulnerable, cruzando la información de los detectores y los escáneres de vulnerabilidades.

La correlación cruzada de OSSIM depende de bases de datos de vulnerabilidades y de tablas de correlación cruzada para cada detector. OSSIM utiliza la base de datos de vulnerabilidades de OSVDB y actualmente incluye tablas de correlación cruzada para el IDS Snort y para Nessus.

6.3.‐Correlación de Inventario.

Los ataques que se lanzan son siempre contra objetivos con un S.O. y/o servicio específico.

La correlación de inventario comprueba si la máquina atacada utiliza ese S.O. y/o servicio específico para el cual se está lanzando el ataque. Si lo utiliza estaremos seguros de que existe un riesgo, pero si no, podemos confirmar que el evento de ataque es un falso positivo.

Este tipo de correlación depende de la precisión del inventario. OSSIM tiene capacidades de realizar inventarios manuales y automáticos para ajustar estos detalles.

7. Gestión del Riesgo

Tal y como se ha explicado en la introducción, la arquitectura de OSSIM ha sido diseñada para la gestión del riesgo y la toma de decisiones.

Esto significa que todas las decisiones son tomadas teniendo en cuenta la gestión del riesgo, con lo que es necesario comprender el proceso de cálculo del valor del Riesgo y lo que significa cada uno de los parámetros.



Solo a través de este conocimiento podrá un administrador conocer como aproximarse al proceso de ajuste y gestión de todo el sistema de seguridad.

La importancia en términos de seguridad de un evento depende de los 3 factores siguientes:

1. El valor del activo que sea el destino del ataque, o cuanto dinero cuesta. 2. La amenaza representada por cada evento, o cuanto puede dañar nuestro activo. 3. La probabilidad de que el evento ocurra

7.1.- Visión tradicional: Riesgo Intrínseco.

Estos tres factores mencionados son los bloques que construyen la definición tradicional de Riesgo:

“Una medida del Impacto potencial de una Amenaza en determinados Activos, teniendo en cuenta la probabilidad de que ocurra realmente”.

A la gestión del riesgo tradicional le afectan los riesgos intrínsecos, o riesgos latentes. En otras palabras, los riesgos que una organización asume tanto por los activos que necesita para su propósito de desarrollo de negocio, como por las amenazas circunstanciales para esos activos.

7.2.- Riesgo en Tiempo Real.

En nuestro caso, debido a las capacidades de tiempo real de OSSIM podemos medir el riesgo asociado con la situación actual en términos inmediatos.

En este caso las medidas del riesgo son incrementadas dependiendo del daño que podrían producir y la probabilidad de que la amenaza esté realmente teniendo lugar en el presente.

Esa probabilidad, que es una derivación de los falsos positivos producidos por nuestros detectores, se convierte en el grado de fiabilidad del evento. En otras palabras, una forma de medir cuán a menudo este evento es un falso positivo.

Por riesgo inmediato queremos decir el estado del riesgo producido cuando se recibe un evento y es valorado instantáneamente como una medida del daño que el ataque podría producir, aumentado por la fiabilidad del evento que creó el informe.

Una de las principales razones por las que los sistemas SIM se necesitan es para luchar contra los falsos positivos ya que una organización puede recibir millones en un día.

El sistema OSSIM está completamente diseñado para manejar estos tres parámetros:

• Activos. • Amenazas (que llamamos prioridades). • Fiabilidad.

Gracias a ello se producen parámetros de riesgo en tiempo real para cada evento.


8.‐ Respuestas automáticas

Una vez que recibimos una alarma de un ataque que está teniendo lugar, podemos desencadenar respuestas automáticas para llevar a cabo acciones relacionadas con este ataque. Este tipo de acciones, a través de las respuestas en tiempo real, permite a los administradores ahorrar tiempo.

Las respuestas crean acciones predefinidas tales como enviar un email, bloquear la conexión a nivel del firewall, o desactivar el puerto de un switch. Estas acciones utilizan una serie de variables como SRC_IP, DATE, etc.., que son sustituidas en tiempo real cuando alguna respuesta utiliza dicha acción.

Después de definir un set de acciones genéricas estableceremos una política para dispararlas, muy similar a la política de priorización.

9.‐ Gestión de Incidentes

OSSIM incluye un Gestor de Incidencias que controla la asignación de tareas que se tienen que realizar debido a las acciones resultantes de los eventos de seguridad.

El Gestor de Incidencias permite crear tickets de la mayor parte de las herramientas de informes de OSSIM, tales como el panel de alarmas, la consola forense, las métricas de riesgo, o las puntuaciones de los paneles informativos.

Cada uno de los tickets generados se almacena en la BBDD y una herramienta de búsqueda los filtra. Procesando estos datos, se imprime un Informe de Explotación de forma automática y periódica.

Es posible también mostrar las tendencias e implementar métricas para medir la situación en el momento actual, siguiendo la evolución a través del tiempo.

10.‐ Informes de Seguridad y Análisis Forense

Como parte de los Procedimientos de Gestión de Seguridad los administradores deben revisar periódicamente los Informes de Seguridad y efectuar un Análisis Forense.

10.1.- Informes de Seguridad

Los informes de seguridad se generan automáticamente usando información de diferentes bases de datos. Estos informes dan una visión general del estado de la seguridad, agregando datos desde diferentes puntos de vista:

• Eventos estadísticos de seguridad por origen, destino y tipo.

• Anomalías. • Informes de IDS de host. • Informes de Vulnerabilidades.




10.2.- Análisis Forense

La herramienta de análisis forense es un frontal que gestiona la base de datos de eventos almacenados con una gran cantidad de vistas, permitiendo filtrarlos utilizando cualquiera de los campos de dichos eventos.

11.‐ Métricas y medidas

Hay dos paneles de métricas implementados en OSSIM.

11.1.- Panel de medidas de Cumplimiento de las Normas

OSSIM permite medir, mostrar tendencias evolutivas y crear umbrales para los parámetros de seguridad creando paneles específicos para las normativas existentes.

Estas métricas de objetos se muestran normalmente como gráficos que realizan un seguimiento a los parámetros monitorizados, permitiendo compararlos con periodos de tiempo anterior, ofreciendo una rápida visualización abstracta y medible de la situación de seguridad.



11.2.- Métricas de Riesgo Acumulado

El panel de puntuación de métricas de riesgo consolida el parámetro de riesgo para cada objeto, produciendo una visualización agregada de la situación de riesgo para cada máquina y red.

Se definen umbrales para disparar alarmas en caso de que las métricas crezcan por encima de valores que no se consideren “normales”.

http://www.ossim.net/screenshots/metrics.png

Documents

Folleto Alienvault-OSSIM