ALIENVAULT

Gestión Unificada de Seguridad

USM (Unified Security Management)

ENERO 2018
Agenda
Dia 1

1. Introducción tecnología USM Alienvault

2. Escenarios de Despliegue e integración con plataformas
3. Manejo de la interfaz web (GUI)
4. Manejo de Assets y Networks
5. Threat Detection (NIDS y HIDS)
1) Introducción tecnología USM
Alienvault
Enfoque AlienVault:
Unified Security Management (USM)
USM Platform
Es una plataforma única que acelera y simplifica la detección
de amenazas, respuesta a incidentes y cumplimiento
normativo para el equipo de TI.

AlienVault Labs Threat Intelligence

Identifica las amenazas más significativas que afectan a su
red con más de 3000 reglas de correlación predefinidas y
directiva de remediación específica del contexto.

Open Threat Exchange (OTX)

El repositorio más grande del mundo de datos de amenazas
provenientes de la multitud, proporciona una visión continua
de las amenazas en tiempo real.
 Plataforma USM

SIEM DESCUBRIMIENTO DE ACTIVOS

• Gestión de logs • Escaneo activo y pasivo de red
• Información de amenazas OTX • Inventario de activos
• Correlación de Eventos de SIEM • Inventario de software basado en host
• Respuesta a Incidentes

EVALUACIÓN DE
MONITOREO DE COMPORTAMIENTO VULNERABILIDADES
• Colección de Logs • Monitoreo continuo de vulnerabilidades
• Análisis del flujo de red (Netflow) • Escaneo activo autenticado/sin
• Monitoreo de la disponibilidad del autenticar
servicio • Verificación de remediación

DETECCIÓN DE INTRUSOS
• IDS de red Capacidades de Seguridad
• IDS de host Esenciales Incorporadas
• Monitoreo de la Integridad de Archivos (FIM)
Descubrimiento de Activos

• Descubrir activos en tu entorno.Por defecto esta activo.

• Detectar cambios de activos en tu entorno.
• Detectar activos rogue en tu red.
• Ejecutar escaneos de activos una sóla vez o programados.
• Ejecutar fingerprinting pasivo del Sistema Operativo.
• Ejecutar descubrimiento pasivo de servicios.

• Tools: p0f,Arpwatch,Nmap & Prads

• En el USM: Ir a
ENVIRONMENT>ASSETS&GROUPS>ASSETS > ADDASSETS >Scan For New Assets
ENVIRONMENT>ASSETS&GROUPS>SCHEDULE SCAN
Evaluación de vulnerabilidades

• Identificar posibles vectores de ataques.

• Comparar aplicaciones instaladas con vulnerabilidades conocidas.
• Revisar cumplimiento.
• Ejecutar escaneos sin y con autenticación.
• Programar escaneos de vulnerabilidades.
• Ejecutar escaneos de vulnerabilidades una vez y programados.
• Usado para reglas de cross correlation
• Tools: OpenVAS

• En el USM Ir a:
ENVIRONMENT>VULNERABILITIES>OVERVIEW
Detección de Intrusos
• Sistema de Detección de Intrusos de Red (NIDS) para interfaces de
sniffing pasivo analiza el payload data y monitorea la actividad
potencialmente malintencionada.
• Sistema de Detección de Intrusos de Host (HIDS) para detectar
problemas en los host, incluída la supervisión de la integridad del
archivo, las comprobaciones de rootkit y las verificaciones del registro.
• Los Sistemas de Detección de Intrusos (IDS) monitorean el tráfico de
la red en busca de comportamiento malicioso, mensajes de registro
del sistema y actividad del usuario.

• Tools: Snort, Suricata , OSSEC

• En el USM ir a:
ENVIRONMENT>DETECTION>AGENTS
Monitoreo del Comportamiento
• Proporciona visibilidad dentro de sus patrones de tráfico
permitiéndole detectar rápidamente niveles anormales de actividad.
• Monitorea la salud del sistema.
• Integra NetFlow de AlienVault USM.
• Integra el monitoreo de la disponibilidad.
• Identifica anomalías desde los subsistemas IDS incluyendo
violaciones de políticas (por ejemplo, tráfico de compartición de
archivos, punto a punto, mensajería instantánea).

• Tools: Netflow , Ntop , Nagios

• En el USM ir a:
ENVIRONMENT>NETFLOW
ENVIRONMENT>AVAILABILITY
Inteligencia de Seguridad

• Busca patrones con datos colectados usando inteligencia de

Emerging Threats, Open Threat eXchange (OTX), patrones definidos
de actividad e información sobre vulnerabilidades.
• Utiliza casi 3000 reglas o directivas pre-fabricadas en el motor de
correlación.
• Compartir información desde el Open Threat eXchange (OTX).
• La inteligencia de seguridad combina y correlaciona los eventos y
otros datos a buscar patrones maliciosos en el trafico de red y dentro
de la actividad del host.

• En el USM Ir a:
CONFIGURATION>OPEN THREAT INTELLIGENCE
CONFIGURATION>THREAT INTELLIGENCE
ANALYSIS>SECURITY EVENTS (SIEM)
2) Escenarios de despliegue e
integración con plataformas
Arquitectura USM - Componentes

• USM Sensor: Agrega la data de log collection , asset discovery , vulnerability scanning ,
IDS data y netflow data.

• USM Server: Administra las funcionalidades colectando la informacion forwardeada de los

USM Sensors , evalua y correlaciona eventos , risk assessment , genera alarmas y
almacena eventos para assessment y reporting.

• USM Logger: Almacena eventos de seguridad y alarmas como archivos en el sistema

firmados digitalmente.

• Un USM AIO (All in One) Tiene los tres componentes en un mismo sistema.
Opciones de despliegue
On-premise, en cloud, o con un USM All-in-One para colectar,
Proveedor de Servicio Gestionado All-in-One
correlacionar, almacenar y
Appliance
de Seguridad (MSSP). gestionar la información.

USM Server para correlacionar la

Componentes
información y gestionar el despliegue.

separados
Appliance físico o virtual para on- USM Logger para un largo periodo
premise. de almacenamiento.

USM Sensor para colectar la

información de la infraestructura.
Hardware Appliance Virtual Appliance

Puede elegir All-in-One o USM Federation Server para

componentes separados. MSSP
despliegues multi-tenant & MSSPs.
 Arquitectura USM

Los USM sensor están diseñados para enviar sus datos al USM Server. Una vez que el USM Server
ha procesado los datos de los USM Sensors, los datos se almacenan en la USM Logger.
Escenario 01: Un único entorno

AlienVault USM
All-in-One Appliance

Información
de Seguridad

Security Network PCs Servers

Data Sources

Un único entorno
Escenario 02: Entorno distribuido

Logger Sensor Server VPN Sensor

Información
de Seguridad

Security Network PCs Servers

Security Network PCs Servers Data Sources

Data Sources

Local Principal Local Remoto

USM Workflow
USM Workflow
Interacción de puertos entre equipos
Integración con diversas plataformas
3) Manejo de la Interfaz Web
4) Manejo de Assets y Networks
Manejo de Assets y Networks
Resumen
Manejo de Assets y Networks
Definicion de Assets
En USM, un ASSET es un equipo que tiene una
dirección IP única en la red de la compañía.

Un ASSET o ACTIVO generalmente incluyen hardware,

como servidores, servidores de correo, servidores de
archivos, computadoras de escritorio, computadoras
portátiles, impresoras, firewalls, enrutadores, otros
dispositivos de red o dispositivos de seguridad como el
propio USM.

En el USM ir a: ENVIRONMENT>ASSETS&GROUPS
Manejo de Assets y Networks
Definicion de Assets
El USM tiene un sistema de ASSET MANAGEMENT que es
usado por todos los componentes de Alienvault. Estos ASSET
son inicialmente agregados al USM mediante el passive
discovery y active scanning, también se pueden agregar
manualmente.
El sistema de ASSET MANAGEMENT permite una fácil
búsqueda usando diversos filtros para revisar y editar
información de un ASSET.
Este sistema también incluye un inventariado integral al cual
de agrega información detallada del ASSET.

En el USM ir a: ENVIRONMENT>ASSETS&GROUPS
Manejo de Assets y Networks
Asset List View – Search Filter
Manejo de Assets y Networks
Asset List View – Search Filter
Manejo de Assets y Networks
Asset List View - Actions
Manejo de Assets y Networks
Examinando el Asset
Manejo de Assets y Networks
Examinando el Asset
Manejo de Assets y Networks
Valor de un Asset
Cada Asset que es detectado o importado
en el Alienvault tiene un valor de Asset que
va del 0 al 5 , 0 es el valor mas bajo y 5 el
mas alto. Este valor esta incluido en el
calculo del risk assessment realizado por el
USM Server (SIEM).

Es recomendado que cada Asset en una

organizacion tenga un valor asignado
basado en la importancia del role del Asset
en la organizacion.
Manejo de Assets y Networks
Factores a determinar un valor de Asset
Si el host que genera el evento no esta incluido en el USM
inventory , el sistema intenta obtener el valor del activo del
host.
El sistema verifica si el host pertenece a una de las redes
definidas.
Si el host pertenece a una de las redes y no esta definido el
valor del activo del host , el sistema utilizara el valor del activo
de la red para realizar el calculo del riesgo.
Si el valor del Asset no esta definido explícitamente para una
red , el sistema usara el valor predeterminado de 2 para el
host.
Manejo de Assets y Networks
Descubrimiento de Activos
El descubrimiento de activos inicial es una de las principales
funciones de Alienvault.

Se utiliza para aumentar el conocimiento de los ASSET

existentes al determinar el sistema operativo y los servicios
que tiene en ejecución.
Manejo de Assets y Networks
Descubrimiento de activos
El Descubrimiento de activos se puede programar para
regularmente buscar nuevos host.
Sin embargo un escaneo programado y un escaneo manual
son vistos diferentes por el USM.
El resultado del escaneo programado es agregado
automáticamente a la BD pero el resultado del escaneo
manual tiene que ser agregado manualmente.
Manejo de Assets y Networks
Asset Groups
Los Assets pueden ser asignados a grupos para
gestionarlos fácilmente (por ejemplo DMZ Hosts, HR
servers , network firewalls , Microsoft Server 2008).

Los Asset Groups son integrados dentro del USM

workflow.Ellos pueden ser usados para correr reportes ,
filtrar alarmas/eventos/raw logs , scans , políticas y
directivas para threat intelligence.
Manejo de Assets y Networks
Network y Network Groups
Networks son creados por un CIDR notación para subnets
(por ejemplo 10.1.2.0/24 para una clase C).
Los Assets son parte de una network.Los Assets son
organizados dentro de una network basado en la dirección
IP.
El USM reconoce automáticamente la network por su
notación CIDR. Adicionalmente las networks se pueden
agrupar en grupos de networks para una gestión mas fácil.

ENVIRONMENT > ASSETS & GROUPS > NETWORKS.

Manejo de Assets y Networks
Network y Network Groups
5) Threat Detection (HIDS y NIDS)
Threat Detection
NIDS (Network Intrusion Detection System)
El Sistema de Detección de Intrusiones de Red (NIDS)
monitorea el tráfico en modo promiscuo desde y hacia todos
los dispositivos en busca de tráfico de red sospechoso.

NIDS supervisa una copia del tráfico de red y realiza análisis

en el tráfico al compararlo con una base de datos de ataques
conocidos (base de firmas) o al detectar anomalías en los
patrones de tráfico.

En el USM ir a: CONFIGURATION>COMPONENTS>SENSOR
CONFIGURATION>DETECTION
Threat Detection
NIDS (Network Intrusion Detection System)
NIDS es una muy importante tool dentro del USM y activa:
• Información de ataque detallada de la escucha pasiva
• Deteccion de problemas de seguridad (Trojan horses,
viruses,worms)
• Deteccion de violación de políticas (pornografía,
p2p,mensajeria)
• Deteccion de malas configuraciones.
Es una de las principales fuentes de información para las
directivas de correlacion y cross correlacion.
Threat Detection
HIDS (Host Intrusion Detection System)
Alienvault USM viene con HIDS integrado el cual provee:
• Log Monitoring y Collection
• Rootkit detection
• File integrity cheking
• Windows registry integrity checking
Alienvault HIDS usa la arquitectura server/agent , donde el
Alienvault HIDS agent reside en los servidores que son
monitoreados y el HIDS server reside en el USM Sensor.

En el USM ir a: ENVIRONMENT>DETECTION>HIDS
Threat Detection
HIDS (Host Intrusion Detection System)
Alienvault usa el OSSEC como agente HIDS desplegados en
cliente y se comunica con el USM Sensor vía UDP 1514
Para Windows la configuración esta en C:\Program Files
(x86)\ossec-agent\ossec.conf y log file en C:\Program Files
(x86)\ossec-agent\ossec.log.
Para Linux la configuración esta en /var/ossec/etc/ossec.conf
y log file en /var/ossec/logs/ossec.log

La autenticación de Agent/Server es realizado vía un pre-shared key

el cual es similar a la siguiente cadena
6687cf219a97c5ccf5b476f1f1283bfe18901c12516b3c124dd0e8ae78a46fd2
Threat Detection
HIDS (Host Intrusion Detection System)
OSSEC Agent
Logcollectord: Read logs
Syscheckd: File integrity checking
Rootcheckd: Malware and
rootkits detection
Agentd: Forwards data to the server

OSSEC Server
Remoted: Receives data from
agents
Analysisd: Processes data
(mainprocess)
Monitord: Monitor agents
Agenda
Dia 2

1. Datasource Plugin y rsyslog

2. Threat Intelligence
3. Mantenimiento de sistema
4. Vistas y Reportes
5. Procesos , archivos y comandos mas usados para soporte de la
plataforma
6) Activando rsyslog y Datasource
Plugin
Data Source Plugin
Data Aggregation
Determina cual data va ser agregada
Es realizado por el USM Sensor
Eventos pueden ser colectados usando múltiples
métodos:
 Configuración de mirror de trafico
 Configuración de datasource cuando
envían eventos al USM Sensor.
 Configuración de USM a pull eventos de
aplicaciones o dispositivos.
Data Source Plugin
Normalization
Es el proceso de trasladar información generado por
diferentes herramientas dentro de un único y
normalizado formato.
Es realizado por el USM Sensor
La información es normalizada usando expresiones
regulares.
La normalización de los datos también permite que
el motor de correlación de USM detecte los patrones
de comportamiento que se producen en los
diferentes tipos de activos supervisados.
Data Source Plugin
Tipos de Plugins
Detector Plugins – Tipo de plugins que recibe y extrae
eventos de archivos de logs. Alienvault provee una serie de
detector plugins para los fabricantes mas conocidos.

Monitor Plugins – Tipo de plugins que colecta información

ejecutando comandos como nmap y tcptrack extrae
información y estatus de los objetivos monitoreados.
Data Source Plugin
Tipos de Detector Plugin
Plugin Source Description Examples
Database Extrae datos de una base de datos externa y los convierte en mcafee-epo
eventos del USM

Log Monitorea un archivo de logs que lo recibe a traves de syslog.Los

plugins extraen eventos de los archivos haciendo match cada
linea en el archivo de logs usando expresiones regulares
Security Device Monitor Cisco devices usa el protocolo SDEE para especificar el cisco-ips
Event Exchange formato de los mensajes usados para comunicar eventos
(SDEE) generados por ciertos dispositivos de seguridad Cisco.

Windows Permite conectar de forma remota a eventos y datos de Windows wmi-

Management sin un agente.Los complementos de WMI recopilan los eventos y application-
Instrumentation datos de Windows de forma remota. logger
(WMI)
Data Source

Cualquier aplicación o ispositivo que genera eventos

de información colectados por el USM

Alienvault puede colectar eventos de cualquier data

source usando un data source plugin.

El plugin instruye como analizar y comprender los

eventos provenientes de un particular data source.

El USM viene con data sources preconfigurados

para los dispositivos y aplicaciones mas
comúnmente implementados.

https://www.alienvault.com/docs/data-sheets/usm-plugins-list.pdf
Data Source Plugin

Un data source plugin es un pedazo de software que permite normalizar y

entender cierto tipo de eventos de un data source.
El plugin consta de dos archivos:
- USM Sensor : .cfg
Localización de los eventos(.log)
Expresiones regulares
Reglas de normalización de los logs

- USM Server : .sql

Describe los eventos normalizados , los cuales van hacer almacenados en
el SIEM database.

Archivos .cfg se encuentran ubicados en USM Sensor /etc/ossim/agent/plugins folder

Archivos .sql se encuentran ubicados en USM Server
/usr/share/doc/ossim-mysql/contrib/plugins folder
Data Source Plugin
Activando un Plugin
Cualquier data source que va ser usado en un despliegue necesita
activarse.Los siguientes plugins están activos globalmente por default:
AlienVault_NIDS, AlienVault_HIDS, prads, pam_unix, ssh, y sudo

Se pueden activar los plugins necesarios para su entorno , este es realizado

a través del menú Assets & Groups.Se pueden agregar por assets , asset
groups o networks.

Tambien se puede activar un plugin de forma global por CONFIGURATION >

DEPLOYMENT > ALIENVAULT CENTER >System Detail > Sensor
Configuration > COLLECTION
Syslog

Syslog es un protocolo que permite enviar logs a archivos o servidores

remotos y es soportado por muchos sistemas operativos y dispositivos de red.

USM appliance utiliza rsyslog como el sistema por defecto para implementar
syslog , los archivos de configuración de los dispositivos reside en
/etc/rsyslog.d
Data Source Plugin
Data Source Plugin
7) Manejo de Politicas,Directivas ,
eventos y alarmas (Threat Intelligence)
Eventos

Un evento es cualquier entrada de log generada por cualquier

data source y normalizada por el USM Sensor.
Para un evento es importante saber:
Cuando fue le evento generado?
Cual sistema o usuarios están relacionados al evento?
Cual data source genero el evento?
Cual es el tipo de evento?
Cual es el riesgo del evento?
Por defecto el USM realiza un risk assessment para todos los eventos
que luego se correlacionan y almacenan en el SIEM database.
Data Source Plugin ID

El data source plugin ID es un único numero usado por el USM para identificar
cada data source
Este numero es usado para identificar un evento, en reglas de correlacion y
cuando defines reglas de políticas.
El rango reservado para que los usuarios puedan crear nuevos data source
plugins es de 9000 - 10000

En el USM ir a :Configuration > Threat Intelligence > Data Source

Event Type ID

Event Type ID o plugin SID es un único numero (dentro de cada data

source) que identifica diferentes eventos que un data source es permitido
generar.
Event Type ID siempre es asociado a un plugin ID ya que multiples data
source pueden compartir event types comunes.
Por ejemplo Por ejemplo HTTP 404:Not Found event type en Apache y IIS

En el USM ir a :Configuration > Threat Intelligence > Data Source

Event Priority

Muestra la importancia del evento mismo.

Determina el impacto que podría tener en la red y la urgencia para que sea
investigado
La prioridad es un valor entre 0 y 5

• 0 — No importance
• 1 — Very Low
• 2 — Low
• 3 — Average
• 4 — Important
• 5 — Very Important
Event Reliability

Reliability determina la probabilidad que el evento sea preciso

Reliability va entre 0 y 10

0 Falso positivo
1 10% posibilidad de ser un ataque
2 20% posibilidad de ser un ataque
…
10 Ataque Real

Por ejemplo si tienes un ataque sobre IIS y el target es un servidor Linux , el

reliability debería ser 0.Sin embargo si tienes un ataque DoS sobre Apache y el
target es un servidor Linux el cual tiene una vulnerabilidad conocida sobre la versión
de Apache entonces el reliability se incrementa considerablemente.
Risk Calculation

El USM Server calcula el riesgo por cada evento procesado

El riesgo es un valor entre 0 (low risk) a 10 (very high risk)
De acuerdo al calculo del riesgo del evento se categoriza si este evento generara
una alarma.

Por ejemplo si seun incrementa

login administrativo
el valor del
es detectado
server a 5 ,elelrisk
cualcalculation
tiene una
prioridad
debería ser:
de 2 y una confiabilidad de 3 , y el valor de el asset origen es 2 (PC)
y el valor de el asset destino es 4 (servidor) el risk calculation deberia ser:

Event risk ≈ (5 * 2 * 3)/25 = 1.2

El calculo del riesgo seria = 1 el cual lanzaria una alarma.

Event risk ≈ (4 * 2 * 3)/25 = 0.96 El calculo del riesgo seria = 0
Alarmas

Una Alarma es un especial tipo de evento el cual se genera cuando el riesgo del
evento es 1 o mayor.
Si el motor de correlacion detecta un nuevo evento a atraves de una directiva de
correlacion(tal evento se llama directive event) y la correlacion tiene un alto
reliability (el cual resulte un alto riesgo del evento) el evento correlacionado se
convierte en una alarma.

Las alarmas son el punto de partida para que los analistas comiencen
investigaciones y análisis. Estos pueden generarse:
- Con reglas de correlación (de directivas de correlación).
- Eventos individuales de controles de seguridad
- Eventos de registro particulares que son suficientemente significativos para
justificar investigación
Alarmas
Correlacion

El motor de correlacion genera nuevos eventos que son

reinyectados al USM server y procesados como si estuvieran
llegando del USM Sensor.

El motor de correlacion utiliza multiples eventos para generar

nuevos eventos con alto reliability

El USM usa dos tipos de correlacion: Logical Correlation y

CrossCorrelation
Correlation
Logical Correlation
Nuevos eventos son generados usando la información que proveen
los detectors y monitors
Logical Correlation es configurado usando directivas de correlación
Nuevos eventos van a tener nueva prioridad y confiabilidad
Las directivas están definidas a través de arboles lógicos , en cual
eje horizontal define una operación OR entre eventos individuales
y el vertical define una operacion AND
Cada directiva tiene un nombre , también tiene un ID , todo evento
correlacionado tiene como plugin ID 1505

En el USM ir a: CONFIGURATION > THREAT INTELLIGENCE > DIRECTIVES.

Correlation
Logical Correlation

Basado en el numero de ocurrencias de eventos individuales, el motor de correlación

puede decir que el evento podría ser:

- El resultado de un error de tipeo por parte del administrador (un intento de login fallido
seguido por un successful login)

- Successfull brute force attack con bajo reliability (10 intentos de logins fallidos
seguido por uno exitoso)

- Successfull brute force attack con alto reliability (100,000 intentos de logins fallidos
seguido por uno exitoso)
Correlation
Logical Correlation
Correlation
Cross Correlation
Correlaciona dos tipos diferentes de eventos detectados por
dos diferentes data sources.
La mayoría de cross correlation esta relacionada a eventos de
IDS con vulnerabilidades
El IDS detecta un ataque a un asset con una vulnerabilidad
especifica , el reliability del evento va cambiar a 10
USM es pre configurado con una serie de reglas de
Cross correlation.
Correlation
Cross Correlation
Correlaciona dos tipos diferentes de eventos detectados por
dos diferentes data sources.
La mayoría de cross correlation esta relacionada a eventos de
IDS con vulnerabilidades
El IDS detecta un ataque a un asset con una vulnerabilidad
especifica , el reliability del evento va cambiar a 10

En el USM ir a: CONFIGURATION > THREAT INTELLIGENCE >

CROSS CORRELATION
 USM Policy

Politicas son configuraciones de objetos en el USM que permiten

decir como el sistema va procesar los eventos una ves que estos
arriben al USM Server
A continuación se menciona algunos ejemplos de uso de políticas:
- Realice el risk assesstment y la correlación sin almacenar
eventos en el servidor base de datos
- Almacenar eventos en el USM Logger y no correlacionar eventos
Esto normalmente se hace si los eventos en cuestión no tienen
directivas o reglas de cross correlation para procesarlas.
- Correlacionar eventos y forwardear estos a otro USM Server sin
almacenarlos.En implementaciones distribuidas mas grandes los
componentes del USM se pueden escalonar para permitir escalamiento
adicional.
USM Policy

El filtrado eficiente elimina el procesamiento de eventos innecesarios y

mejora la rendimiento del sistema

Las políticas son también usadas para:

 Reducir los falsos positivos
 Enviar un mail de notificación
 Oculte temporalmente las verdaderas alarmas positivas hasta
que se lleve a cabo una acción correctiva o preventiva
 Incrementar la importancia de un evento especifico

En el USM ir a: CONFIGURATION > THREAT INTELLIGENCE >

POLICY.
USM Policy

Reglas de políticas son aplicados en orden descendiente

Las políticas deben ser ordenados del mas especifico ,por asset, puerto especifico
etc al mas general
Se deben de ordenar cuidadosamente cuando un evento hace match con una
política el sistema va detener el procesamiento de este evento.
USM Policy

Una política tienes dos componentes: condiciones y consecuencias(Acciones).

Conectados juntos con una relación de causa-efecto (if <condiciones> then
<acciones>)

Condiciones determina que eventos van hacer procesados por la política

Consecuencias define que va suceder cuando los eventos hagan match con las
condiciones.
USM Policy
Actions
Actions son una consecuencias para un USM Policy.Cuando un evento hace match
con una política una acción es ejecutada

Estas son las 3 acciones que se pueden realizar:

Enviar un correo mail
Ejecutar un comando para invocar un script en Alienvault USM
Apertura un ticket en el sistema de ticket interno de Alienvault USM

En el USM ir a: CONFIGURATION > THREAT INTELLIGENCE >ACTIONS.

8) Mantenimiento de sistema
Mantenimiento de sistema

Espacio en disco en Alienvault USM es consumido por eventos , alarmas y logs ,

basado en los componentes activos.
ALARMAS y EVENTOS son almacenados en el SIEM database
Por defecto 40,000,000 de eventos son almacenados por 90 días
Alarmas son almacenados hasta que se eliminen de la consola de alarmas del
SIEM
Las alarmas usualmente se eliminan después de la investigación y remediación ,
especialmente si se trato de un falso positivo
Los RAW LOGS son almacenados en el file system hasta que sean eliminados del
sistema, estos consumen excesivo espacio en disco por lo cual es recomendado
exportarlo aun sistema de storage offline y después eliminarlo del USM.
Los LOG FILES creados por el rsyslog y usados por los datasource plugins para
leer los mensajes que llegan.
 Mantenimiento de sistema

Espacio en disco puede ser monitoreado usando la GUI. Navegando a

CONFIGURATION >
DEPLOYMENT > COMPONENTS > ALIENVAULT CENTER
Mantenimiento de sistema
Mantenimiento de sistema
Raw Logs
Una mejor alternativa a activar la expiración de logs es periódicamente mover
los RAW LOGS de el sistema a un sistema de storage.

Mediante SFTP o SCP conectar al USM y copiar los archivos a un sistema de

storage, una ves copiados ya se podrían eliminar del USM.

Los RAW LOGS son almacenados en el file system en la ruta :

/var/ossim/logs/<year>/<month>/<day>/hour/<ip_address>

Los .log.gz son los archivos de logs y los .log.sig archivos que incluyen la firma
digital
Mantenimiento de sistema
Backup de Eventos
Eventos en el USM son automáticamente backed up y pueden ser restaurados

Los eventos son backed up todos los días y se almacenan en el sistema por 30
días.

Restaurar los archivos de backups de eventos es una tarea común cuando los
eventos ya fueron eliminados y se requiere realizar una investigación.
Mantenimiento de sistema
Restaurar Eventos

Se puede eliminar todos los eventos del SIEM database dando en CLEAR
SIEM DATABASE.Seleccionando un archivo de backup se puede eliminarlo
Mantenimiento de sistema
Backup de configuracion
Ir a CONFIGURATION > ADMINISTRATION > BACKUPS >
CONFIGURATION va mostrar todos los backups por cada dispositivo
Alienvault
Mantenimiento de sistema
Restore de configuracion
Ir a CONFIGURATION > ADMINISTRATION > BACKUPS >
CONFIGURATION va mostrar todos los backups por cada dispositivo
Alienvault
9) Vistas y Reportes
Reportes

Reportes permiten la creación de reportes de cumplimiento ,vulnerabilidades,

alarmas , assets y eventos

Reportes pueden ejecutarse inmediatamente o programarse

Reportes pueden ser personalizados

Reportes pueden ser vistos en HTML y descargados o enviados en PDF por correo

Alienvault Threat Intelligence Updates constantemente provee actualizaciones para

el modulo de reportes donde provee nuevas vistas o datos
Reportes
Actions
150 reportes están disponibles por defecto en Reports > All
Reports. Las siguientes acciones puede ser realizadas:
Reportes
Modules y Layouts
Combinacion de modulos y layouts es usado a producir un
reporte
Los modulos definen los queries que se corren sobre el
SIEM database o Logger y extrae los eventos para generar
los graficos y tablas.
Los layouts definen los header ,footer, color scheme e iconos
de reportes
Por default al menos 3000 módulos son disponibles
Reportes
Custom Run
Se puede ejecutar un Custom Run de un USM report para
seleccionar lo siguiente:
Time range a seleccionar los datos
Especificar assets para este reporte
Layout para generar el reporte

A ejecutar un Custom Run,seleccionar un reporte de la lista y

click en el icono CUSTOM RUN
Reportes
Visualizando y descargando
El sistema puede tardar un tiempo en generar el informe,
según el tipo de informe, el rango de fechas y la cantidad de
activos.
Después de que el sistema genera el informe, se muestra en
la interfaz de usuario web como un documento HTML. Puede
descargar el informe como un documento PDF o enviarlo a
una dirección de correo electrónico definida.
Para permitir enviar reportes a través de correo se tiene que
tener correctamente configurado el Alienvault USM con un
servidor mail relay
Reportes
Programar un reporte
El sistema también soporta la programación de reportes , esto
permite generar reportes consolidados durante horarios de
baja carga , cuando el sistema es menos utilizado
Considerar usar reporte programado para generar reportes de
cumplimiento. Por ejemplo si se requiere siempre un reporte
mensual de cumplimiento PCI se puede programar para que
este llegue al buzón de correo del auditor
Navegar a Reports > All Reports > Scheduler para
programar un reporte
Reportes
Programar un reporte
Despues que se ejecuta el reporte programado envía el
informe al correo definifo y lo guarda en el repositorio de
informes.
El repositorio guarda todos los informes programados siempre
que este marcado con la opción SAVE IN REPOSITORY
Reportes
Reporte personalizado
Se puede crear un nuevo reporte o personalizar alguno
existente
Se puede personalizar únicamente copias de lor reportes
existentes
Reportes
Personalizar Layout
Si necesita personalizar el Layout se puede crear uno en
Reports > All Reports > Layouts
Reportes
Personalizar Modulo para eventos
Se puede crear reportes personalizados usando:
Buscando eventos guardados en el SIEM
Buscando logs guardados en Raw Logs
Se puede guardar el resultado de la búsqueda como un
custom report module
Se puede usar estos custom report module cuando se
requiera crear un reporte personalizado
Para crear un custom module para eventos ir a
Analysis>Security Events(SIEM)
Reportes
Personalizar Modulo para eventos
Despues de que USM genere un informe , puede verificar que
vea la misma información sobre los eventos como en la vista
de Security Events (SIEM)
Se puede exportar el reporte en PDF y examinar sobre el PDF
Reportes
Personalizar Modulo para Logs
Para crear un custom module logs ir Analysis > Raw Logs,
especificar un filtro de búsqueda en SEARCH y click RAW
QUERY, después que el filtro recopilo información click en
PREDEFINED SEARCHES dar un nombre y grabar
Reportes
Personalizar Modulo para Logs
Buscar en custom module en el área de RAW LOGS , custom
list subarea en Reports > All Reports > Modules
Puedes usar este modulo cuando personalices un informe o
cuando generes datos personalizados usando el wizard como
se muestra en el ejemplo
En el primer paso del wizard se selecciona RAW LOGS –
Custom List modulo , click NEXT a seleccionar los assets
sobre los cuales se realizaran reportes o hacer click en PASO
3 para ir al ultimo paso del asistente
Reportes
Personalizar Modulo para Logs
En el ultimo paso del Wizard tu tienes que seleccionar el log
search grabado previamente
Seleccionar el log search (en el ejemplo CUSTOM LOGS) del
menú de filtro.Click en SAVE o en SAVE y RUN
Reportes
Personalizar Modulo para Logs
Despues de generar el reporte tu puedes verificar que se vea
la información de los logs en Raw Logs view
Estos se puede exportar como PDF para examinar los logs
con el mismo PDF
10) Procesos , archivos y comandos
mas usados para soporte de la
plataforma
Open Source Tool List
Archivos y procesos
Archivos de Logs importantes
Procesos Alienvault
 Debugging conexión datasource

Si el dispositivo de origen esta generando nuevos logs y aun

no aparecen en la GUI SIEM de Alienvault (por ejemplo el
dispositivo no figura como un datasource disponible) los
siguientes pasos ayudaran a aislar en que etapa del
procesamiento de logs esta la falla
 Debugging conexión datasource

Los logs deberían de empezar aparecer en le GUI Analysis >

Security Events (SIEM)
Si no es así , primero validar que tu estas recibiendo paquetes
syslog del dispositivo origen con el comando:
tcpdump -i eth0 -v -w /dev/null ‘src <IP datasource> and port
514’
Otra opcion es:
tcpdump –i any host <IP datasource> and port 514
La cantidad de paquetes capturados deberían indicar los logs
que fueron enviados.
 Debugging conexión datasource

Reiniciar el rsyslog collector y el agente sensor

/etc/init.d/rsyslog restart
/etc/init.d/ossim-agent restart

Buscar algún error relacionado al plugin en el agent logs

cat /var/log/ossim/agent* | grep plugin_id=”1636”
Reinicio de servicios del server