Documento

GUA METODOLGICA PARA LA GESTIN CENTRALIZADA DE REGISTRO
DE EVENTOS DE SEGURIDAD EN PYMES
DIANA CAROLINA NIO MEJA

ALEJANDRO SIERRA MUNERA
PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMAS
BOGOTA D.C.,
ENERO 2007
GUA METODOLGICA PARA LA GESTIN CENTRALIZADA DE REGISTRO

DE EVENTOS DE SEGURIDAD EN PYMES
DIANA CAROLINA NIO MEJA

ALEJANDRO SIERRA MUNERA
Trabajo de Grado presentado para optar el ttulo de Ingeniero de Sistemas
Director:
Ingeniero Edgar Enrique Ruiz

BOGOTA D.C.,
ENERO 2007

Rector Magnfico: Padre Gerardo Remolina Vargas S.J.
Decano Acadmico Facultad de Ingeniera: Ingeniero Francisco Javier

Rebolledo Moz
Decano del Medio Universitario Facultad de Ingeniera: Padre Antonio Jos

Sarmiento Nova S.J.
Director Carrera de Ingeniera de Sistemas: Ingeniera Hilda Cristina Chaparro

Lpez
Director Departamento de Ingeniera de Sistemas: Ingeniero Germn Alberto

Chavarro Flrez
Nota de Aceptacin
______________________________________________________
______________________________________________________
______________________________________________________
______________________________________________________
______________________________________________________
______________________________________________________
________________________________________
Director del Proyecto
________________________________________
Jurado
_________________________________
Jurado
Enero 2007
Artculo 23 de la Resolucin No. 1 de Junio de 1946

La Universidad no se hace responsable de los conceptos emitidos por sus
alumnos en sus proyectos de grado. Slo velar porque no se publique nada
contrario al dogma y la moral catlica y porque no contengan ataques o
polmicas puramente personales. Antes bien, que se vean en ellos el anhelo de
buscar la verdad y la Justicia
TABLA DE CONTENIDO
1. INTRODUCCION
10
1.1. DESCRIPCIN EL PROBLEMA

1.2. OBJETIVOS DE LA INVESTIGACIN
1.3. ALCANCE DE LA INVESTIGACIN
10
10
11
2. MARCO TERICO
13
2.1. METODOS DE TRANSPORTE

13
2.1.1. SYSLOG
13
2.1.2. SNMP
18
2.2. CORRELACION DE REGISTROS DE EVENTOS DE SEGURIDAD
21
2.2.1. REQUISITOS PARA LA CORRELACIN
21
2.2.2. EVENTOS, INCIDENTES Y EVENTOS COMPUESTOS
21
2.2.3. TIPOS DE CORRELACIN
23
2.3. COMPUTACIN FORENSE Y EVIDENCIA DIGITAL
25
2.3.1. COMPUTACIN FORENSE
25
2.3.2. EVIDENCIA DIGITAL
25
2.4. PROTECCIN DE INFORMACIN Y HERRAMIENTAS DE SEGURIDAD
29
2.4.1. SEGURIDAD FSICA
29
2.4.2. SEGURIDAD LGICA
30
2.4.3. PROTECCIN
30
2.4.4. INVERSIN
33
2.5. CLASIFICACIN Y TIPOS DE ATAQUES INFORMTICOS
34
2.5.1. VULNERABILIDAD
34
2.5.2. AMENAZAS Y ATAQUES
35
2.6. SINCRONIZACION DE RELOJES DE TIEMPO
37
2.6.1. ARQUITECTURA DEL SISTEMA
38
2.7. SSH
39
2.7.1. ARQUITECTURA DE SSH
39
2.7.2. CARACTERSTICAS DE SSH.
41
2.7.3. USOS COMUNES DE SSH
42
3. DESARROLLO DEL PROYECTO
43
3.1. RED TIPICA DE UNA PYME.

3.1.1. TAMAO DE UNA PYME
3.1.2. CARACTERSTICAS DE UNA RED TPICA DE UNA PYME
3.2. REQUERIMIENTOS PARA LA GESTION CENTRALIZADA DE LOS
REGISTROS DE EVENTOS DE SEGURIDAD
44
44
45
47
3.2.1. REQUERIMIENTOS FUNCIONALES

47
3.2.2. REQUERIMIENTOS NO FUNCIONALES
48
3.2.3. DIAGRAMA DE RED TPICA DE UNA PYME.
48
3.3. DEFINICIN DE INFRAESTRUCTURA
50
3.3.1. DEFINICIN DEL MTODO DE SINCRONIZACIN DE RELOJES DE TIEMPO.
50
3.3.2. DEFINICIN DEL MTODO DE TRANSPORTE
50
3.3.3. DEFINICIN DE HERRAMIENTAS DE USO EN LA GUA METODOLGICA.
52
3.3.4. MODELO DE LA INFRAESTRUCTURA PARA LA CENTRALIZACIN DE REGISTROS
DE EVENTOS DE SEGURIDAD.
53
3.3.5. MTODOS UTILIZADOS PARA LA SATISFACCIN DE LOS REQUERIMIENTOS DE
LA GUA METODOLGICA.
55
3.4. ESTRUCTURA DE LA GUA METODOLGICA
57
3.4.1. DIAGRAMA DE FLUJO DE LA GUA METODOLGICA.
57
3.4.2. ORDEN SECUENCIAL DE PASOS PARA LA CONFIGURACIN DE LA
CENTRALIZACIN.
61
3.4.3. CENTRALIZACIN DE REGISTROS DE EVENTOS DE HERRAMIENTAS UTILIZADAS
EN PYMES.
65
3.4.4. DEPENDENCIA DE LOS SERVICIOS.
66
4. VALIDACIN DE LA GUA METODOLGICA
68
4.1. CARACTERSTICAS DEL CASO DE PRUEBA.

4.1.1. DIAGRAMA DE RED DEL CASO DE PRUEBA
4.2. DEFINICIN DE LOS RESULTADOS ESPERADOS.
4.3. OBSERVACIONES Y RESULTADOS OBTENIDOS.
68
69
69
71
5. CONCLUSIONES
72
6. TRABAJOS FUTUROS
74
7. BIBLIOGRAFIA
75
8. ANEXOS
79
LISTA DE TABLAS
Tabla 1. Facilidades y su cdigo numrico respectivo.......................................14
Tabla 2.Severidades y su cdigo numrico respectivo......................................15
Tabla 3. Caracterstica de los Mtodos de transporte.......................................51
Tabla 4. Equipos de la red del caso de prueba..................................................68
tabla 5. Lista de validacin para la guia metodolgica......................................70
LISTA DE FIGURAS
Figura 1. Estructura de mensajes SNMP...........................................................19
Figura 2. Interrupcin [28]..................................................................................36
Figura 3. Intercepcin [28]..................................................................................36
Figura 4. Modificacin [28].................................................................................36
Figura 5. Fabricacin [28]...................................................................................37
Figura 6. Esquema jerrquico de NTP. [37].......................................................38
Figura 7. Esquema de distribucin de SSH.......................................................40
Figura 8.Red Tpica de una pyme definida por Microsoft. [29]..........................45
Figura 9. Diagrama de una Red tpica de una pyme.........................................49
Figura 10. Esquema de centralizacin de logs..................................................54
Figura 11. Diagrama de flujo de la gua metodolgica.......................................58
Figura 12. Diagrama de Flujo para la configuracin del servidor...................61
Figura 13. Diagrama de Flujo para la configuracin de los clientes UNIX LIKE
............................................................................................................................62
Figura 14. Diagrama de Flujo para la configuracin de los clientes WINDOWS
............................................................................................................................63
Figura 15. Diagrama de Flujo para la configuracin de los clientes
dispositivos de red..............................................................................................64
Figura 16. Diagrama de Flujo para la configuracin de los clientes UNIX LIKE,
receptores de logs de los dispositivos de red....................................................65
Figura 17. Diagrama de Dependencias de los Servicios...................................66
Figura 18. Esquema de Red del caso de prueba..............................................69
1. INTRODUCCION
2. DESCRIPCIN EL PROBLEMA
En la actualidad, las pequeas y medianas empresas (Pymes) cuentan con
herramientas y equipos informticos los cuales, en su mayora, generan
registros de eventos de seguridad. Los logs son un conjunto de eventos que se
almacenan en los dispositivos donde son generados, y contienen informacin
acerca de los sucesos que ocurren en el dispositivo.
Es importante mantener un monitoreo constante de los logs para detectar
eventos anormales en las herramientas o dispositivos de red, y poder actuar
oportunamente frente a cualquier dificultad, evitando as la perdida o
manipulacin no autorizada de informacin.
Sin embargo, no es suficiente analizar la informacin de cada dispositivo por
separado, ya que en algunos casos, puede existir una relacin directa entre
eventos sucedidos en distintos equipos.
La revisin de los logs y anlisis de la informacin contenida en stos se vuelve
una tarea bastante compleja y tediosa cuando se genera un sin lmite de logs
en la compaa diariamente. Una solucin a ste problema es mantener
almacenados los logs en un solo equipo, y desde este hacer la revisin de
todos los logs de la pyme.
Existen algunas herramientas de software que permiten realizar la
centralizacin de los registros de eventos y en algunos casos correlacionarlas,
sin embargo, son herramientas bastante costosas, las cuales no se encuentran
al alcance de una pyme. Se encuentran herramientas de cdigo libre o guas
que permiten realizar el transporte sobre los logs, pero no cumplen con todos
los requerimientos de seguridad necesarios para el transporte de estos.
Por lo anterior, se lleva a cabo este proyecto, con el fin de proponer una gua
metodolgica que permita a las pymes gestionar de manera centralizada los
registros de eventos de seguridad.
3. OBJETIVOS DE LA INVESTIGACIN
El principal objetivo de ste trabajo de investigacin es definir y validar una
gua metodolgica para la gestin centralizada de registros de eventos de
seguridad de red, para que pueda ser utilizada en organizaciones de pequea y
mediana escala. Para cumplir con ste objetivo, se intenta dar respuesta a la
pregunta Cmo centralizar registros de eventos de seguridad en pymes
conservando su carcter de evidencia digital a nivel probatorio y
cumpliendo los requicitos para hacer una futura correlacin?. La solucin
a este interrogante,
actividades:
se busca a travs del seguimiento de las siguientes
Apropiacin del conocimiento asociado a la gestin de seguridad, registros

de eventos y computacin forense.
Anlisis y definicin de requerimientos para la gestin centralizada de
registros eventos de seguridad.
Definicin de la infraestructura de software y hardware para la gestin
centralizada de registros de eventos de seguridad que soporte los
requerimientos definidos anteriormente.
Definicin de una gua metodolgica para la implantacin de la
infraestructura definida.
Validacin de la gua metodolgica mediante la definicin e implementacin
de un caso de prueba que se ajuste a las caractersticas de la red de una
pyme.
4. ALCANCE DE LA INVESTIGACIN
El proyecto de investigacin busca la elaboracin de una gua metodolgica
para la gestin centralizada de registros de eventos de seguridad para
pequeas y medianas empresas, la cual debe ser apoyada en herramientas de
libre distribucin o que se encuentren al alcance de una pyme.
Para la elaboracin de la gua se pretende hacer uso de herramientas ya
existentes, que cumplan con alguno(s) de los requerimientos necesarios para
realizar la centralizacin de logs manteniendo su carcter de evidencia digital.
Con el seguimiento de la gua metodolgica la pyme debe lograr centralizar los
registros de eventos de seguridad que generan las herramientas o dispositivos
que cumplan con los requerimientos especificados en la gua.
No hace parte del trabajo de investigacin llevar a la pyme a realizar una
correlacin de registros de eventos, sin embargo, como continuacin del
proyecto, queda abierta la posibilidad de implementar un sistema de correlacin
de logs centralizados.
Dentro del objetivo del proyecto, no se encuentra comprendido el desarrollo de
software, definicin de estndares, definicin de polticas ni de procedimientos
para la pyme.
Al centralizar los registros de eventos de seguridad, es probable que el trfico

de red aumente, no es parte del objetivo del proyecto estudiar o proveer un
rendimiento de red ptimo.
5. MARCO TERICO
La teora en la cual fue basada este proyecto de investigacin se basa en los
conceptos claves para realizar la centralizacin de logs manteniendo su
carcter de evidencia digital. Esto cubre los temas relacionados con los
mtodos de transporte de logs, correlacin de registros de eventos de
seguridad, protocolo de sincronizacin de relojes de tiempo en una red,
mtodos para asegurar el transporte de logs, computacin forense y evidencia
digital.
Tambin se cubrieron temas relacionados con seguridad informtica como los
tipos de ataques informticos y mtodos de proteccin contra estos, con el fin
de conocer las herramientas que son usadas comnmente para la proteccin y
que generan registros de eventos de seguridad que deben ser tenidos en
cuenta en el momento de la centralizacin.
6. METODOS DE TRANSPORTE
Existen diferentes mtodos que se pueden utilizar a la hora de realizar el
transporte de los logs. A continuacin se describen algunos de estos.
7. Syslog
Syslog es un sistema de logs que se encarga principalmente de la
administracin de logs, los cuales son generados por eventos del sistema, sus
programas o por el Kernel. [1]
El envi de mensajes Syslog fue usado inicialmente en sistemas basados en
UNIX para registrar eventos de aplicaciones, sistema operativo o red.
Es comn ahora encontrar equipos de redes que pueden generar y enviar
mensajes Syslog a equipos configurados con un demonio que los reciba [36],
as como ya existen implementaciones para sistemas Windows.
El termino syslog es a menudo utilizado para describir tanto el protocolo para el
envo de mensajes, como el programa o librera que enva mensajes syslog.
7.1.1.1.
Mensaje Syslog
Un mensaje syslog cuenta con tres campos descritos a continuacin:
PRI: Este campo debe estar compuesto por 3,4 o 5 caracteres y debe estar
rodeado de corchetes angulares.
Comienza con el carcter < seguido de un nmero, el cual precede del
carcter >. El cdigo utilizado en esta parte debe ser un ASCII de 7 bits en
un campo de 8 bits como est descrito en el RFC 2234.
El nmero encerrado por los corchetes es conocido como la Prioridad, la
cual est compuesta por 1,2 o 3 enteros decimales. La Prioridad representa
a la vez la Facilidad y Severidad las cuales se encuentran codificadas
numricamente con valores decimales.
Algunos de los demonios de sistemas operativos y procesos se les han
asignado valores de Facilidad. Si a algn proceso o demonio no se le ha
asignado explcitamente una Facilidad, puede usar cualquiera de las
facilidades de uso local (local use) o usar la Facilidad nivel de usuario
(user level).
Aquellas Facilidades que han sido asignadas son mostradas en la siguiente
tabla, as como sus cdigos numricos:
Cdigo
Numrico
Facilidad
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Mensajes de kernel
Mensajes de nivel de usuario
Sistema de correo
Demonios del sistema
Mensaje de seguridad/autorizacin
Mensaje generado internamente por
syslogd
Subsistema de impresora en lnea
Subsistema de noticias de red
Subsistema UUCP
Demonio de reloj(nota 2)
Mensaje de seguridad/autorizacin(nota
1)
Demonio FTP
Subsistema NTP
Auditoria de eventos (nota 1)
Alerta de eventos (nota 2)
Demonio de reloj (nota 2)
Uso local 0
Uso local 1
Uso local 2
Uso local 3
Uso local 4
Uso local 5
Uso local 6
Uso local 7
Tabla 1. Facilidades y su cdigo numrico respectivo
Nota 1. Se han encontrado algunos sistemas operativos que utilizan las

Facilidades 4, 10, 13 y 14 para seguridad/autorizacin.
Nota 2. Se han encontrado algunos sistemas operativos que utilizan las
Facilidades 9 y 15 para mensajes de reloj
Cada Prioridad de mensaje tiene un indicador de Severidad decimal. Estas

severidades son descritas en la siguiente tabla:
Cdigo
Numrico
0
1
2
3
4
5
6
7
Severidad
Mensajes de kernel
Mensajes de nivel de usuario
Sistema de correo
Demonios del sistema
Mensaje de seguridad/autorizacin
Mensaje generado internamente por
syslogd
Subsistema de impresora en lnea
Subsistema de noticias de red
Tabla 2.Severidades y su cdigo numrico respectivo
El valor de la Prioridad se calcula multiplicando el valor de la Facilidad por 8

y sumndole el valor de la severidad.
HEADER (Cabecera): La cabecera contiene dos campos: TIEMSTAMP y

HOSTNAME.
El TIMESTAMP va inmediatamente despus del ltimo > del PRI. ste
corresponde a la fecha y hora local del dispositivo que transmite. stas se
encuentran en formato Mmm dd hh:mm:ss donde:
o Mmm corresponde a la abreviacin en ingls del nombre del mes.
La primera letra seguida de las otras dos en minscula. Estos
valores pueden ser: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep,
Oct, Nov, Dec.
o dd representa al da del mes. Si el da es menor a 10 se debe
representar como un espacio y el nmero del da. Por ejemplo: el
7 de Agosto se debe representar: Aug 7 con 2 espacios entre la
g y el 7.
o hh:mm:ss esto representa a la hora local. Las horas (hh) estn
representadas en un formato de 24 horas. Los valores permitidos
estn entre 00 y 23, inclusive. Los minutos (mm) y segundos (ss)
estn entre 00 y 59 inclusive.
El HOSTNAME corresponde al nombre del dispositivo, la direccin ipv4 o la
direccin ipv6. El valor recomendado es el nombre del dispositivo, y debe
estar especificado en STD 13 [3]. El nombre no debe contener espacios
internos ni tampoco el nombre del dominio. Si se utiliza la direccin ipv4, se
debe mostrar en la notacin decimal con puntos como se usa en STD 13. Si
se usa la direccin ipv6, se puede usar cualquier representacin vlida
usada en RFC 2373.
MSG. El mensaje o MSG tiene 2 campos. TAG (Etiqueta) y CONTENT. El

primero representa el nombre del programa o proceso que gener el
evento. El TAG no debe exceder a 32 caracteres. El otro campo CONTENT

es libre de utilizacin y contiene lo detalles del mensaje
A raz de que cada proceso, programa, aplicacin y sistema operativo fue
escrito de manera independiente, hay poca uniformidad en el contenido de
los mensajes syslog. El protocolo esta diseado simplemente para
transportar esos mensajes de eventos. En todos los casos, existe un
dispositivo que origina el mensaje. El proceso syslog en la mquina puede
enviar el mensaje syslog a un recolector. Sin embargo, no se hace ningn
reconocimiento del recibo del mensaje. [2]
7.1.1.2.
Caractersticas de syslog
El programa syslog provee una plataforma estandarizada, bajo la cual

programas (tanto sistemas operativos como aplicaciones) pueden publicar
mensajes para que sean tratados por ninguna, cualquiera, o todas las acciones
siguientes, basado en la configuracin de syslog: [4]
Guardar en un archivo (p.e. /var/adm/messages) o dispositivo (p.e.
/dev/console)
Enviar directamente a un usuario o usuarios si han iniciado sesin (p.e. root)
Reenviar a otro equipo (p.e. @loghost)
Configurar un servidor syslog en una red es algo relativamente sencillo, sin
embargo, los principales problemas que tiene syslog son los siguientes:
Syslog utiliza el protocolo UDP, ya que este protocolo es no orientado a
conexin, no se asegura que los mensajes lleguen al destinatario.
Los mensajes no estn cifrados y al viajar por la red como texto plano son
susceptibles a ser vistos por personas no autorizadas, por ejemplo un
sniffer.
Cualquier persona puede dirigir mensajes de una naturaleza maliciosa, sin
ninguna autenticacin de quien es el remitente. Esto puede concluir en
ataques de denegacin de servicio y puede permitir que un atacante
distraiga al administrador con mensajes falsos para no llamar la atencin
con su ataque.
Por este motivo se han desarrollado alternativas basadas en syslog para
aprovechar la funcionalidad que este provee, de una manera mas confale.
7.1.1.3.
Evoluciones de syslog
Syslog Modular.
Syslog modular es una implementacin de syslog que tiene un nuevo modulo
que se encarga de verificar la integridad de los eventos. Los eventos pueden
ser firmados mediante algoritmos como PEO-1 y L-PEO, con los que se pude
verificar si los eventos han sido modificados. [5]
Nsyslog. Nsyslog es una herramienta desarrollada por Darren Reed la cual

afronta el problema de la integridad de la versin original de syslog,
remplazando el uso de paquetes UDP por el uso de paquetes TCP. Con el
protocolo TCP se busca mejorar la confiabilidad de la entrega de los mensajes
ya que este protocolo revisa la llegada de estos mediante el uso de acuses.
Otra ventaja es que sobre TCP se puede implementar SSL (Secure Socket
Layer) que permite cifrar los mensajes lo que provee confidencialidad. [5]
Nsyslog se mantiene compatible con la versin anterior de syslog ya que puede
ser configurado para escuchar por el puerto 514/UDP.
Syslog-NG. sta evolucin de syslog fue desarrollado por Balabit IT y su
objetivo es extender la versin regular de syslog.
Las principales extensiones que ofrece son:
Habilidad de decidir que tan frecuentemente se escriben los datos a disco.
Habilidad de controlar si la transmisin se hace mediante UDP o TCP.
Habilidad de enviar los datos a una base de datos.
Con syslog-ng el formato del archivo de configuracin
[5]
syslog-ng.conf cambia.
Stealthful Loggin. Para un proyecto de Honeypot, es clave recolectar los

registros de eventos. En el proyecto Honeynet ( http://www.honeynet.org) buscan
proteger la confidencialidad del servidor de logs y los datos que en este
residen. Para proteger a este equipo se configura el dispositivo que genera los
mensajes syslog para enviarlos a una direccin falsa o a una direccin de
broadcast. Luego se configura un equipo objetivo (honeypot) con Snort. La
interfaz de red del servidor de logs no se configura como promiscua en ese
segmento de red. Un filtro de Snort se crea para escuchar todos los mensajes
broadcast de syslog en esta interfaz de red inactiva, y enviar estos mensajes a
un archivo de log. A esta tcnica se le llama Stealthful Loggin. [5]
RFC 3195, Reliable delivery for Syslog (Entrega confiable para Syslog).
Este RFC describe un mtodo para la entrega confiable de los mensajes
syslog. Uno de los objetivos es mantener compatibilidad con el RFC 3164.
Para la confiabilidad se usa el protocolo BEEP descrito en el RFC 3080 [6],
creando un tnel en el que los mensajes de syslog se pueden asegurar
mientras son enviados.
BEEP tambin provee autenticacin. [5]
7.1.1.4.
Comparacin de evoluciones de syslog
Debido a que syslog es un protocolo que permite el transporte de los logs,

podra ser una herramienta viable en la centralizacin de los registros de
eventos de seguridad. Este protocolo no genera costos adicionales, lo cual es
un punto a su favor en el momento de decidir la mejor opcin al momento de
centralizar.
Sin embargo ste protocolo presenta desventajas en cuanto al manejo de
seguridad ya que no garantiza la llegada del mensaje al utilizar un protocolo no
orientado a conexin, ni tampoco garantiza integridad, autenticidad, ni
privacidad.
Por las razones anteriores es conveniente, en caso de ser posible, realizar
alguna modificacin a ste protocolo o implementar alguna metodologa que
garantice mayor seguridad.
8. SNMP
SNMP (Simple Network Managment Protocol) es un protocolo de
administracin de red, el cual gestiona la configuracin de dispositivos de red
desde una estacin de trabajo. Sin embargo, existen algunos dispositivos de
red que no fueron creados para ser administrados con SNMP, para lograr la
administracin de estos existe un agente especial llamado agente Proxy. [7]
SNMP v.1 trabaja con el protocolo de transporte no orientado a conexin, UDP.
Los agentes SNMP escuchan por el puerto 161.
8.1.1.1.
Componentes de SNMP:
SNMP se compone de tres partes [7]:

1. Consola de administracin: La consola de administracin es un
programa que se encuentra en una estacin de trabajo. sta tiene la
funcin de indagar los agentes por medio de SNMP. Su responsabilidad
principal es ejecutar aplicaciones para analizar el funcionamiento de la
red.
2. Agente: Un agente es un programa que se encuentra en un dispositivo
de red, el cual es administrable por SNMP. La responsabilidad principal
del agente es consultar o modificar las variables de la MIB.
3. MIB: Una MIB es una base de datos virtual de objetos administrados
que son accesibles por el agente y manipulados va SNMP para lograr la
administracin de la red [7]. Se encuentra dividida en cuatro reas:
atributos del sistema, atributos privados, atributos experimentales y

atributos de directorio.
Para representar la informacin de una MIB cada objeto debe tener un
identificador de objeto nico llamado OID, ste es una secuencia de
nmeros enteros no negativos que van separados por un punto. Este
identificador sale de un rbol estandarizado mundialmente.
8.1.1.2.
Operaciones de SNMP:
En este protocolo existen 6 comandos u operaciones bsicas: GetRequest,

GetNext, GetResponse, SetRequest, Trap, GetBulkRequest.
El comando trap, es utilizado cuando ocurre un evento inusual. En este caso,
los agentes utilizan este comando para enviar datos a la consola de
administracin. Este evento siempre es reportado sin solicitud.
8.1.1.3.
Estructura de la PDU
La estructura del mensaje SNMP cuando se utiliza un comando trap se define

como se ve en la Figura siguiente:
Versin Comunida
d
SNMP PDU
Mensaje SNMP
Tipo
PDU
empresa
Direccin Trap
agente
genrico
Trap
Timeespecfico stamp
Campos
variables
Trap PDU
Figura 1. Estructura de mensajes SNMP

En donde cada uno de los campos se define a continuacin:
Versin: en este campo se define la versin de SNMP que se va a utilizar.
Comunidad: se define la relacin que existe entre un agente y un grupo de
aplicaciones SNMP.
Tipo de PDU: Indica el tipo de la PDU que va en el mensaje (GetRequest,
GetNextRequest, SetRequest, GetResponse, trap).
Empresa: indica el tipo de objeto que genera un trap.
Direccin agente: se encuentra la direccin del objeto generador del trap.
Trap genrico: Es el tipo genrico del trap.
Trap especfico: Indica el cdigo especfico del trap.
Time-stamp: Indica el tiempo que transcurri entre la ultima vez que se

reinici el dispositivo de red y la creacin del trap.
8.1.1.4.
SNMP v.3
SNMP v.3 se define como la adicin de seguridad y administracin a SNMP v.2.

Esta versin fue diseada para corregir, mediante el uso de algoritmos de
autenticacin y de cifrado, algunos problemas de seguridad con los que
contaba la versin anterior, los cuales son mencionados a continuacin:
Falta de Integridad
Falta de Autorizacin
Falta de Autenticacin
Spoofing
Sin embargo, an no previene ataques como denegacin de servicios y sniffer.

Esta versin provee un mejor sistema de seguridad, mucho ms robusto y
confiable. Utiliza cifrado por medio de DES y autenticacin con MD5. Tambin
utiliza un modelo de usuarios y de control de acceso basado en vistas sobre la
MIB actual. Esto permite que se pueda restringir el acceso a ciertas partes de
la MIB.
Otra mejora de esta versin frente a las versiones anteriores, es que soporta el
uso de lenguajes orientados a objetos, como Java o C++, para la construccin
de los elementos propios del protocolo. [8]
Debido a que el protocolo SNMP presenta una versin mejorada (SNMP v3), en
la cual se reflejan adelantos en el tema de seguridad, garantizando as
integridad, autorizacin, autenticacin y spoofing; este protocolo se puede ver
como una herramienta til en la administracin de logs.
SNMP, presenta adicionalmente, otra gran ventaja ya que provee soporte de
lenguajes de programacin orientados a objetos, lo cual podra facilitar la
intervencin en la construccin de elementos del protocolo.
9. CORRELACION DE REGISTROS DE EVENTOS DE

SEGURIDAD
La correlacin tiene como objetivo encontrar incidentes los cuales son una
serie de eventos que ocurren en distintos puntos de la red [10]. En otras
palabras, la correlacin busca asociar los eventos para encontrar informacin
til. [11]
10. Requisitos para la correlacin
Antes de realizar la correlacin es necesario haber cumplido con algunos
requisitos: Consolidacin, Normalizacin y Reduccin. [10]
La consolidacin de los datos consiste en el transporte de los eventos

desde los dispositivos o herramientas de seguridad hasta un punto
central. El mtodo de transporte utilizado para la consolidacin debe ser
orientado a conexin y se debe garantizar la integridad y seguridad de
los datos. Es importante proteger los datos durante este transporte, para
ello se debe usar algn mtodo de cifrado y autenticacin.
La normalizacin de los datos consiste en cambiar el formato de los

datos a un solo formato polimrfico. Es primordial para propsitos
forenses que durante este proceso no se pierda ni se cambie ningn
dato.
Reduccin de los datos. Esto se puede realizar comprimindolos,

suprimiendo duplicados o combinando eventos similares en un solo
evento.
Teniendo en cuenta que uno de los aspectos ms importantes de un registro de

eventos es el hecho de guardar la estampilla de tiempo exacta del momento en
que se produjo el log, es muy importante, a la hora de correlacionar varios
eventos en diferentes dispositivos, que esas estampillas de tiempo estn
sincronizadas. Por esto es importante no perder de vista un aspecto que podra
clasificarse dentro de la normalizacin que propone Caldwell, y valdra la pena
distinguirlo de la normalizacin de la forma de los registros.
11. Eventos, Incidentes y Eventos Compuestos
Un incidente esta definido como el resultado de la correlacin de varios
eventos.
la correlacin,, es tomar varios eventos de seguridad aislados y unirlos para
crear un nico y relevante incidente de seguridad.[10].
Un evento es la representacin de cambios de estado de inters que pueden
ocurrir en un sistema. stos se clasifican en eventos primitivos y eventos
compuestos. Los primeros estn predefinidos en un sistema y la deteccin de
estos esta embebida en la implementacin del mismo. Los eventos compuestos

surgen de componer varios eventos primitivos y compuestos, cada uno de
estos llamado evento componente.
Adicionalmente un evento puede ser recurrente, es decir un evento puede
ocurrir varias veces en un intervalo de tiempo. Cada ocurrencia de un evento
se define como instancia de evento.
Se ha definido un lenguaje para la especificacin de eventos compuestos
llamado JESL (Java Event Specification Language) el cual se describe a
continuacin.
JESL
El lenguaje JESL esta basado en los conceptos enumerados a continuacin:
Evento
Evento Primitivo
Evento Compuesto
Instancia de Evento
Para denotar una instancia de un evento se define (e,i) como la i-esima
instancia del evento e. [13]
Funciones
#: Define el ndice de la instancia ms reciente del evento e en un
tiempo t.
0 (e,1) no ha ocurrido en el tiempo t

# (e, t)
i la instancia mas reciente de e en el tiempo t es (e, i)
AttrVale: Permite acceder al valor del atributo attr de la instancia del

evento e (e,i)
AttrValue (e, attr , i ) el valor del atributo attr de (e,i)
AttrValuer : Permite acceder al valor del atributo attr de la instancia

relativa de un evento e en un tiempo t
AttrValue r (e, attr , t , i ) AttrValue (e, attr , # (e, t ) i )
Donde (#(e,t)+i)>0, y t es el tiempo de referencia.
@ y @r: Un atributo comn de todos los eventos es el tiempo de

ocurrencia. Por eso se define la funcin @ y @ relativo para representar
el tiempo de ocurrencia de una determinada instancia del evento e.
@(e, i ) AttrValue (e, " OcurrenceT ime" , i )
@ r (e, i ) AttrValue r (e, " OcurrenceTime" , t , i )
Si se considera el tiempo t dentro de valores no negativos.

i 0
@(e, i 1) @(e, i )
@f y @fr: Mediante esta funcin se puede definir un subconjunto de

instancias de e, en el cual estn las instancias de e que cumplen con
una expresin booleana f. Este grupo de instancias constituyen el evento
ef .
@ f (e, f , i ) @(e f , i )
@ fr (e, f , T , i ) @(e f , T , i )
11.1.1.1.
Especificacin de Eventos Primitivos y Compuestos
Eventos Primitivos:
define primitive event PE with
attributes ([NAME, TYPE], ..., [NAME, TYPE])
Eventos Compuestos:
define composite event CE with
attributes ([NAME, TYPE], ..., [NAME, TYPE])
which occurs
whenever timing condition
TC is [satisfied violated]
if condition
C is true
then
ASSIGN VALUES TO CEs ATTRIBUTES;
12. Tipos de Correlacin
Los dos aspectos ms importantes en la correlacin de eventos son la
velocidad con la cual ocurre la correlacin, y la exactitud de los datos devueltos
en la correlacin. [11] Es importante que el sistema de correlacin informe los
incidentes tan rpido como sea posible para que el administrador de la red
acte de acuerdo a esto. De igual forma, el sistema de correlacin debe reducir
el nmero de falsos positivos y falsos negativos [9].
Luego de haber cumplido con los requisitos para correlacionar se puede
proceder a la correlacin. Existen diferentes mtodos para esto: correlacin
basada en reglas, correlacin estadstica y correlacin con sistemas de
inteligencia artificial
12.1.1.1.
Correlacin basada en reglas
ste tipo de correlacin consiste en identificar ciertos incidentes y su

secuencia, es decir cada uno de los eventos que se dieron para llegar al
incidente. Este conocimiento del ataque se utiliza para relacionar eventos y
para analizarlos juntos en un contexto comn. [12]
Los motores de correlacin basados en reglas aplican los incidentes conocidos
en un ataque para seguir detectando exactamente este ataque [12]. En otras
palabras, los sistemas de correlacin basados en reglas combinan un conjunto
de reglas con los eventos que va recibiendo. Basndose en los resultados de
cada prueba, y la combinacin de eventos en el sistema, el motor de
procesamiento de reglas analiza datos hasta que llega a un estado final. Luego,
reporta un diagnostico o no reporta nada, dependiendo de la profundidad y de
la capacidad del conjunto de reglas. [11]
Para que este tipo de correlacin funcione bien y los resultados sean exactos,
es necesario ingresar las reglas correctamente y mantenerlas actualizadas en
caso de algn cambio en los datos. [11]
12.1.1.2.
Correlacin estadstica
Esta correlacin no emplea ningn conocimiento preexistente de incidentes

malvolos, sino que por el contrario confa en el conocimiento (y el
reconocimiento) de actividades normales, que se han acumulado en un cierto
plazo. Luego, los eventos en curso son clasificados por un algoritmo
incorporado y se pueden tambin comparar a los patrones acumulados de la
actividad, para distinguir normal de anormal (sospechoso).
La correlacin estadstica utiliza algoritmos numricos especiales para calcular
los niveles de amenaza incurridos por los eventos relevantes de la seguridad.
Tal correlacin busca desviaciones de niveles normales de eventos y otras
actividades rutinarias. Los niveles del riesgo se pueden computar de los
eventos entrantes y seguir posteriormente en tiempo real o histricamente, de
modo que las desviaciones lleguen a ser evidentes.
La deteccin de incidentes al usar correlacin estadstica no requiere ningn
conocimiento preexistente del incidente a ser detectado. Los mtodos
estadsticos se pueden, sin embargo, utilizar para detectar incidentes en
umbrales predefinidos de la actividad. Tales umbrales se pueden configurar
basndose en la experiencia que supervisa el ambiente. [12]
12.1.1.3.
Correlacin con sistemas de inteligencia Artificial
Este tipo de correlacin usa varias formas de inteligencia artificial (AI). Hay
muchos tipos diversos de inteligencia artificial, y las tcnicas de la correlacin
de eventos se han propuesto utilizar varias combinaciones de ellas, incluyendo
redes neuronales y sistemas expertos. Los sistemas de AI tienen una ventaja
en que, si estn bien programados, tienen la capacidad de aprender por si

solos, ayudando a eliminar la continua necesidad de los expertos [11]. Este
tipo de correlacin se basa en la forma en que el cerebro humano correlacin
informacin.
El objetivo de la correlacin de logs es lograr detectar ataques o amenazas en
un tiempo mnimo, para alcanzar a actuar frente a determinado suceso.
Es importante que los logs cumplan con los requisitos de normalizacin,
sincronizacin de tiempo, transporte y reduccin, para lograr una correlacin
exitosa.
13.
COMPUTACIN FORENSE Y EVIDENCIA DIGITAL
14. Computacin Forense

Segn el FBI, la computacin forense se define como la ciencia de adquirir,
preservar, obtener y presentar datos que han sido procesados
electrnicamente y guardados en un medio computacional [14]. Esta ciencia
tambin se ocupa de crear y emplear medidas preventivas para eventos
ocurridos en sistemas de informacin y/o en redes locales.
La computacin forense tiene como fin asistir en la reconstruccin posterior de
eventos o ayudar a anticipar acciones no autorizadas [15].
El uso del anlisis forense y la evidencia digital ayuda a identificar y procesar
gran cantidad de crmenes. Para esto los investigadores usan un gran nmero
de tcnicas y herramientas de software que ayudan en el proceso del anlisis
computacional.
En computacin forense es importante conocer el tema de la evidencia digital y
su manejo.
15. Evidencia digital
Al iniciar una investigacin de computacin forense se debe hacer con la
recoleccin de datos o informacin, la cual est presente en las pruebas o
evidencias obtenidas de los sitios donde se ha cometido algn incidente o
delito informtico.
Casey define la evidencia digital como cualquier dato que puede establecer
que un crimen se ha cometido o puede proporcionar una relacin entre un
crimen y su vctima o un crimen y su autor. [16]
La evidencia digital se puede recolectar y analizar con herramientas y tcnicas

especiales.
Cuando ha sucedido un incidente, generalmente, las personas involucradas en
el crimen intentan manipular y alterar la evidencia digital, tratando de borrar
cualquier rastro que pueda dar muestras del dao. Sin embargo, este problema
es mitigado con algunas caractersticas que posee la evidencia digital. [16]
La evidencia de Digital puede ser duplicada de forma exacta y se puede

sacar una copia para ser examinada como si fuera la original. Esto se
hace comnmente para no manejar los originales y evitar el riesgo de
daarlos.
Actualmente, con las herramientas existentes, es muy fcil comparar la
evidencia digital con su original, y determinar si la evidencia digital ha
sido alterada.
La evidencia de Digital es muy difcil de eliminar. An cuando un registro
es borrado del disco duro del computador, y ste ha sido formateado, es
posible recuperarlo.
Cuando los individuos involucrados en un crimen tratan de destruir la
evidencia, existen copias que permanecen en otros sitios.
15.1.1.1.
Clasificacin de la evidencia digital
Cano clasifica la evidencia digital que contiene texto en 3 categoras [18]:

Registros generados por computador: Estos registros son aquellos, que
como dice su nombre, son generados como efecto de la programacin de un
computador. Los registros generados por computador son inalterables por una
persona. Estos registros son llamados registros de eventos de seguridad (logs)
y sirven como prueba tras demostrar el correcto y adecuado funcionamiento del
sistema o computador que gener el registro.
Registros no generados sino simplemente almacenados por o en
computadores: Estos registros son aquellos generados por una persona, y
que son almacenados en el computador, por ejemplo, un documento realizado
con un procesador de palabras. En estos registros es importante lograr
demostrar la identidad del generador, y probar hechos o afirmaciones
contenidas en la evidencia misma. Para lo anterior se debe demostrar sucesos
que muestren que las afirmaciones humanas contenidas en la evidencia son
reales.
Registros hbridos que incluyen tanto registros generados por
computador como almacenados en los mismos: Los registros hbridos son
aquellos que combinan afirmaciones humanas y logs. Para que estos registros
sirvan como prueba deben cumplir los dos requisitos anteriores.
Este artculo se centrara en la evidencia digital de registros generados por

computador (logs).
15.1.1.2.
Criterios de admisibilidad
En legislaciones modernas existen cuatro criterios que se deben analizar al

momento de decidir sobre la admisibilidad de la evidencia: la autenticidad, la
confiabilidad, la completitud o suficiencia, y el apego y respeto por las leyes y
reglas del poder judicial [19].
Autenticidad: Una evidencia digital ser autentica siempre y cuando se
cumplan dos elementos:
El primero, demostrar que dicha evidencia ha sido generada y registrada
en el lugar de los hechos
La segunda, la evidencia digital debe mostrar que los medios originales
no han sido modificados, es decir, que la los registros corresponden
efectivamente a la realidad y que son un fiel reflejo de la misma.
A diferencia de los medios no digitales, en los digitales se presenta gran
volatilidad y alta capacidad de manipulacin. Por esta razn es importante
aclarar que es indispensable verificar la autenticidad de las pruebas
presentadas en medios digitales contrario a los no digitales, en las que aplica
que la autenticidad de las pruebas aportadas no ser refutada, de acuerdo por
lo dispuesto por el artculo 11 de la ley 446 de 1998: Autenticidad de
documentos. En todos los procesos, los documentos privados presentados por
las partes para ser incorporados a un expediente judicial con fines probatorios,
se reputarn autnticos, sin necesidad de presentacin personal ni
autenticacin. Todo ello sin perjuicio de lo dispuesto en relacin con los
documentos emanados de terceros [20].
Para asegurar el cumplimiento de la autenticidad se requiere que una
arquitectura exhiba mecanismos que certifiquen la integridad de los archivos y
el control de cambios de los mismos.
Confiabilidad: Se dice que los registros de eventos de seguridad son
confiables si sus orgenes son crebles y verificables [19]. Para probar la
confiabilidad, se debe contar con una arquitectura de computacin en correcto
funcionamiento, la cual demuestre que los logs que genera tiene una forma
confiable de ser identificados, recolectados, almacenados y verificados.
Una prueba digital es confiable si el sistema que lo produjo no ha sido violado
y estaba en correcto funcionamiento al momento de recibir, almacenar o
generar la prueba [18]. La arquitectura de computacin del sistema lograr
tener un funcionamiento correcto siempre que tenga algn mecanismo de
sincronizacin del registro de las acciones de los usurarios del sistema y que a
posea con un registro centralizado e ntegro de los mismos registros.
Suficiencia o completitud de las pruebas: Para que una prueba est

considerada dentro del criterio de la suficiencia debe estar completa. Para
asegurar esto es necesario contar con mecanismos que proporcionen
integridad, sincronizacin y centralizacin [19] para lograr tener una vista
completa de la situacin. Para lograr lo anterior es necesario hacer una
verdadera correlacin de eventos, la cual puede ser manual o sistematizada.
Apogeo y respeto por las leyes y reglas del poder judicial: Este criterio se
refiere a que la evidencia digital debe cumplir con los cdigos de
procedimientos y disposiciones legales del ordenamiento del pas. Es decir,
debe respetar y cumplir las normas legales vigentes en el sistema jurdico.
15.1.1.3.
Manipulacin de la Evidencia Digital
Es importante tener presente los siguientes requisitos que se deben cumplir en

cuanto a la manipulacin de la evidencia digital.
Hacer uso de medios forenses estriles (para copias de informacin)
Mantener y controlar la integridad del medio original. Esto significa, que

a la hora de recolectar la evidencia digital, las acciones realizadas no
deben cambiar nunca esta evidencia.
Cuando sea necesario que una persona tenga acceso a evidencia digital
forense, esa persona debe ser un profesional forense.
Las copias de los datos obtenidas, deben estar correctamente

marcadas, controladas y preservadas. Y al igual que los resultados de la
investigacin, deben estar disponibles para su revisin.
Siempre que la evidencia digital este en poder de algn individuo, ste

ser responsable de todas la acciones tomadas con respecto a ella,
mientras est en su poder.
Las agencias responsables de llevar el proceso de recoleccin y anlisis

de la evidencia digital, sern quienes deben garantizar el cumplimiento
de los principios anteriores.
15.1.1.4.
centralizacin de registros de eventos dentro del ciclo

de vida de la evidencia digital.
Al analizar el documento de buenas prcticas en la administracin de la

evidencia digital, de Jeimmy J. Cano [21], se observa que dentro del ciclo de
vida para la administracin de la evidencia digital, el cual se comprende de 6
pasos, hay 2 de ellos que se deben tener en cuenta en el transporte de registro

eventos. Los cuales son citados a continuacin.
Paso 2. Produccin de la evidencia.
Este paso esta compuesto de los siguientes objetivos:
que el sistema o tecnologa de informacin produzca los registros

electrnicos
identificar el autor de los registros electrnicos almacenados
identificar la fecha y hora de creacin
verificar que la aplicacin est operando correctamente en el momento
de la generacin de los registros, bien sea en su creacin o
modificacin.
Verificar la completitud de los registros generados
Paso 3. Recoleccin de la evidencia.

El paso 3 requiere el cumplimiento de 5 objetivos citados a continuacin:
16.
Establecer buenas prcticas y estndares para recoleccin de evidencia

digital
Preparar las evidencias para ser utilizadas en la actualidad y en tiempo
futuro
Mantener y verificar la cadena de custodia
Respetar y validar las regulaciones y normativas alrededor de la
recoleccin de la evidencia digital
Desarrollar criterios para establecer la relevancia o no de la evidencia
recolectada.
PROTECCIN DE INFORMACIN Y HERRAMIENTAS DE
SEGURIDAD
Es necesario conocer las tcnicas existentes para proteger la informacin y los
recursos de una red. Estas tcnicas se clasifican en dos tipos: Seguridad Fsica
y Seguridad Lgica.
17. Seguridad fsica
La seguridad fsica es uno de los aspectos ms olvidados durante el diseo de
un sistema de seguridad informtica. Sin embargo, este es un tema de gran
importancia y sin l, no tendra sentido la seguridad de la red.
La Seguridad Fsica se refiere a controlar e implementar mecanismos de

seguridad dentro y alrededor del centro de cmputo. Tambin provee
mecanismos de seguridad en los medios de acceso remoto al centro. Estos
mecanismos son implementados para proteger el hardware y medios de
almacenamiento de datos. Este concepto se ajusta tambin, para el edificio o
lugar fsico en el que se encuentra la informacin.
Este tipo de seguridad est enfocado a prevenir las amenazas ocasionadas
tanto por el hombre como por la naturaleza, al medio fsico en que se
encuentra ubicado el centro.
Las principales amenazas que se prevn en la seguridad fsica son:
Desastres naturales, incendios accidentales, tormentas e inundaciones.

Amenazas ocasionadas por el hombre.
Disturbios, sabotajes internos y externos voluntarios.
Como se mencion anteriormente, sta seguridad es de alta importancia y

debe siempre ir de la mano con la seguridad lgica.
18. Seguridad lgica
En las compaas, lo ms importante que se tiene es la informacin, y por lo
tanto deben existir tcnicas, que complementen a la seguridad fsica, que la
aseguren, lo cual es brindado por la Seguridad Lgica.
La seguridad lgica es de los mecanismos ms importantes e influyentes de la
seguridad informtica. Este tipo de seguridad tiene como funcin la imposicin
de barreras y procedimientos que protejan el acceso a los datos y slo se
permita acceder a ellos a los usuarios autorizadas para hacerlo.
Los objetivos que plantea la seguridad lgica son:
Restringir el acceso a los programas y archivos.
Asegurar que no cualquier persona pueda modificar los programas ni los
archivos sin ser autorizada.
Verificar que la informacin transmitida se reciba slo por el destinatario
al cual ha sido enviada.
Establecer que la informacin recibida sea la misma que ha sido
transmitida.
19. Proteccin
La mayora de los problemas de seguridad son ocasionados por los usuarios
de los sistemas y es responsabilidad del administrador detectarlos y encontrar
la mejor manera de terminar con ellos.
A continuacin se mencionan algunas herramientas o tcnicas de proteccin de
informacin, sin embargo es importante tener en cuenta que ninguna de las
tcnicas expuestas a continuacin representar el 100% de la seguridad

deseada, por tanto, ser la suma de algunas de ellas las que convertirn un
sistema interconectado en confiable.
19.1.1.1.
Criptografa.
Esta tcnica de proteccin es una de las mejores defensas de las

comunicaciones. La criptografa es una tcnica que permite mantener los datos
de un modo privado y protegido, lo cual impide que un intruso logr ver la
informacin real.
El tener la informacin que se enva por la red cifrada, garantiza que no sea la
informacin original, sino que se encuentra codificada y carente de sentido
excepto para el receptor, quien cuenta con los medios precisos para
decodificarla.
La criptografa ayuda a proteger la confidencialidad de la informacin. Su
objetivo principal es dificultar el acceso por parte de un individuo no autorizado,
a la informacin, incluso si posee la informacin cifrada y conoce el algoritmo
criptogrfico empleado. Generalmente se requiere tiempo y dinero para lograr
interpretar la informacin cifrada.
Algunos de los mtodos ms usados actualmente para sta tcnica son:
criptografa simtrica, criptografa asimtrica y criptografa hbrida (combinacin
de las dos anteriores). Los mtodos anteriores hacen manejo de llaves y
funciones matemticas.
Algoritmos simtricos: ste mtodo utiliza la misma clave para cifrar y
descifrar la informacin, lo cual lo hace rpido y fcil de implementar tanto en
hardware como en software. Los algoritmos simtricos no proporcionan
Autenticacin. Un ejemplo de stos algoritmos, es el algoritmo DES.
Algoritmos asimtricos: estos algoritmos utilizan dos claves diferentes
(pblica y privada) relacionadas entre s, en donde la informacin cifrada por
la primera de ellas solamente puede ser descifrada por su par y viceversa.
Con algoritmos asimtricos se obtiene confidencialidad y autenticacin. Un
ejemplo de algoritmos simtricos es RSA.
19.1.1.2.
Autenticacin.
La autenticacin se refiere al proceso de verificar la identidad de una persona.

ste proceso se puede llevar a cabo por medio de sistemas biomtricos (huella
digital, retina, etc) smart cards, firmas digitales, passwords, PKI, etc.
19.1.1.3.
Firewalls.
Estas herramientas son unas de las ms conocidas al momento de establecer

seguridad, y deben ser uno de los sistemas a los que ms se debe prestar
atencin.
Un firewall es un sistema que ejerce polticas de seguridad establecidas. Este
sistema puede ser de software ejecutndose en un sistema operativo o en un
enrutador, o puede ser hardware. El firewall puede proteger una red confiable
de una que no lo es (por ejemplo Internet). Esta herramienta es utilizada para
controlar el trfico entre redes y para examinar los paquetes que llegan o salen
de la red en la que se encuentran. Si el firewall encuentra algn elemento
extrao en el trfico de la red, restringe el paso.
Sin embargo, vale la pena nombrar que el firewall no protege ataques como:
virus y bombas lgicas, tunelling, ataques fsicos, y todo aquello que circule por
la red sin pasar por el firewall.
19.1.1.4.
Listas de control de acceso (ACL).
Las ACL, son listas que permiten definir permisos a usuarios y grupos
concretos. Por ejemplo, puede definirse sobre un Proxy una lista de todos los
usuarios (o grupos de ellos) a quien se le permite el acceso a Internet, FTP, o
cualquier otro servicio. Tambin podrn definirse otras caractersticas como
limitaciones de anchos de banda y horarios.
19.1.1.5.
Sistema de Deteccin de Intrusos (IDS).
Los IDS son sistemas diseados para examinar trfico que viaja por la red con
el fin de identificar amenazas y detectar escaneos, pruebas y ataques.
Los objetivos de los detectores de intrusos son:
Monitorear el trfico de la red buscando posibles ataques.

Controlar los logs de los servidores para descubrir anomalas (tanto de
intrusos como de usuarios autorizados).
Mantener almacenado el estado exacto de cada uno de los archivos del
sistema para detectar la modificacin de los mismos.
Controlar el ingreso de cada nuevo archivo al sistema para detectar
caballos de troya o ataques semejantes.
Controlar el ncleo del Sistema Operativo para detectar posibles
infiltraciones en l, con el fin de controlar los recursos y acciones del
mismo.
Alarmar al administrador de cualquiera de las acciones mencionadas.
Los IDS utilizan dos mtodos de deteccin:

Por anomalas: a partir de la caracterizacin del trfico y estadsticas del
sitio, el IDS busca desviaciones.
Por firmas: el IDS busca patrones predefinidos dentro del trfico.

Aunque los IDS son muy importantes dentro del esquema de seguridad de un
sistema, tiene algunos defectos como el hecho de arrojar resultados falsos
positivos o falsos negativos.
19.1.1.6.
Antivirus.
El antivirus es un programa creado para prevenir la penetracin de los virus en

un equipo, evitando su propagacin a los diferentes sistemas.
Estas
herramientas tienen algunos mecanismos de deteccin, eliminacin y
reparacin de archivos infectados. Los antivirus se encuentran constantemente
monitoreando el sistema.
19.1.1.7.
Dispositivos de red.
Estos dispositivos tienen la capacidad de analizar los paquetes y darles la ruta

ms adecuada dependiendo de su destino. Y aunque no es su funcin
principal, pueden ser configurados para alertar el intento de entrar a redes
privadas, as como tambin tienen la posibilidad de temporizar el login para
evitar ataques de fuerza bruta.
Los enrutadores pueden tambin, hacer control del ancho de banda y evitar de
ste modo ataques como denegacin de servicios
Los enrutadores o cualquier dispositivo de red, no debe ser considerado, ni
siquiera en ambientes pequeos, como el nico elemento de seguridad. De
hecho, debe ser usado en primera instancia, para cumplir su funcin con la que
fue diseado.
19.1.1.8.
Sistemas Anti-Sniffers.
Estas herramientas tienen como funcin detectar Sniffers en el sistema. Por lo

general los anti-sniffers se basan en verificar el estado de la tarjeta de red, para
detectar si est en modo promiscuo.
20. Inversin
Los costos de las diferentes herramientas de proteccin se estn haciendo
accesibles, en general, incluso para las organizaciones ms pequeas. Esto
hace que la implementacin de mecanismos de seguridad se d prcticamente
en todos los niveles: empresas grandes, medianas, chicas y usuarios finales.
Todos pueden acceder a las herramientas que necesitan y los costos van de
acuerdo con el tamao y potencialidades de la herramienta.
Tambin es importante mencionar que actualmente, en Internet, se encuentran
gran cantidad de herramientas de libre distribucin.
21.
CLASIFICACIN Y TIPOS DE ATAQUES INFORMTICOS
22. Vulnerabilidad
Las vulnerabilidades de seguridad, es la posibilidad de que el sistema u
organizacin est expuesto a una amenaza. Las vulnerabilidades pueden ser
aprovechadas por un atacante para acceder a un sistema o una red.
En la actualidad las vulnerabilidades son un punto crtico en la seguridad
informtica. Sin embargo, vale la pena mencionar, que la gran mayora de las
vulnerabilidades se deben malas configuraciones de las aplicaciones, sistemas
operativos y equipos de trabajo, as como a los descuidos de los oficiales de
seguridad.
22.1.1.1.
Tipo de vulnerabilidades
A continuacin se definirn algunas vulnerabilidades ms comunes en los

sistemas. sta clasificacin fue tomada de [25].
Service Deny (DoS): Durante ste ataque, el intruso intenta evitar que un
usuario tenga acceso a informacin o recursos [26]. Sucede cuando el atacante
hace uso excesivo del recurso a atacar, evitando de este modo, que el usuario
real pueda acceder a este recurso, perjudicando el funcionamiento del sistema.
Buffer Overflow: Este tipo de vulnerabilidad, es causado por un error de
programacin. Sucede cuando se escribe una cantidad de datos mayor sobre
el buffer de la que ste puede almacenar.
Cross-site scripting: sta vulnerabilidad consiste en que un intruso redirige a
la vctima de un web Server legtimo a una pgina daina que contiene HTML
malvolo [27].
Commands Inyection: ste error de sistema permite al atacante introducir
cdigo daino por medio del servicio web a otros sistemas a travs del
protocolo http o mediante scripts.
SQL Injections: Esta vulnerabilidad hace referencia a una tcnica de explotar
aplicaciones Web que no validan la informacin suministrada por el cliente,
para enviar consultas SQL maliciosas por medio de un campo o parmetro de

la aplicacin, con el fin de realizar modificaciones sobre la base de datos.
Stack Overflow: Esta vulnerabilidad ocurre cuando el tamao mximo de la
pila del sistema es excedido.
Heap Overflow: El heap es una regin de memoria que es inicializada
dinmicamente para un programa. Un heap overflow ocurre cuando el
contenido del heap es sobrescrito por cdigo arbitrario. Esto sucede por un
error de programacin, al no poner lmites a algn componente del programa.
Integer Overflow: Estos errores suceden debido a la no comprobacin y a las
malas suposiciones de los programadores en la conversin entre diferentes
tipos y operaciones aritmticas.
Path Manipulation: Consiste en la manipulacin del path de las aplicaciones,
lo cual provee ubicaciones distintas y por tanto recursos distintos a los
normalmente utilizados.
23. Amenazas y ataques

Como consecuencia de las vulnerabilidades en los sistemas se crean las
amenazas. Una amenaza es una condicin del entorno de la informacin, que
se puede presentar en una persona, mquina, suceso o idea, la cual, dada una
oportunidad, podra dar lugar a que se produjese una violacin de los principios
de la seguridad. Cuando dicha violacin de seguridad se produce, se habla de
un ataque.
23.1.1.1.
Clasificacin de ataques segn el principio violado
Las amenazas o ataques se pueden clasificar de la siguiente manera segn su

modo de accin:
Interrupcin: Este tipo de ataque sucede cuando el atacante atenta contra un
recurso del sistema dejndolo en un estado no disponible o inoperable, debido
a la destruccin del recurso, o de ocasionar el mal funcionamiento del mismo.
La interrupcin es un ataque contra la disponibilidad. Algunos ejemplos de
interrupciones son la destruccin de un recurso de hardware, daar una lnea
de comunicacin o deshabilitar un servidor de base de datos.
Emisor
Recepto
r
Figura 2. Interrupcin [28]
Intercepcin: ste ataque ocurre cuando un intruso consigue acceso no

autorizado a un recurso. La intercepcin atenta contra la confidencialidad.
Debido a que en este ataque no se produce ningn tipo de alteracin sobre los
recursos, es muy complicado detectarlo. Ejemplos de este ataque son la copia
no permitida de informacin, o la interferencia de una red para observar los
datos que viajan por ella.
Emisor
Recepto
r
Intruso
Figura 3. Intercepcin [28]

Modificacin: En este ataque, el intruso accede al recurso y lo altera o
modifica. Este es un ataque contra la integridad. Es el ms peligroso de los
ataques, pues puede ocasionar mucho dao. Los ejemplos ms comunes de
este ataque son: modificacin de los datos de un archivo, y alteracin de los
datos que viajan por la red.
Emisor
Recepto
r
Intruso
Figura 4. Modificacin [28]

Fabricacin: Es el ataque en el cual un intruso fabrica informacin falsa y la
inserta en el sistema a atacar. Este es un ataque contra la autenticidad.
Ejemplos de este ataque son la insercin de mensajes falsos en una red o
aadir registros a un archivo.
Emis
or
Rece
ptor
Intrus
o Fabricacin [28]
Figura 5.
23.1.1.2.
Clasificacin de ataques segn su efecto.
Los ataques se pueden as mismo clasificar de forma til en trminos de

ataques pasivos y ataques activos.
Ataques pasivos. Estos ataques, el intruso nicamente monitorea o escucha
la informacin que viaja por la red, no la modifica, ni la altera. Con el fin de
interceptar datos y analizar el trfico que viaja por la red para obtener
informacin.
Como se menciono anteriormente, estos ataques son muy difciles de detectar,
ya que no provocan ninguna modificacin de los datos. La forma de evitar estos
ataques es usando mtodos para cifrar la informacin.
Ataques activos. Este tipo de ataque, sucede cuando el intruso realiza
alguna modificacin de los datos que viajan por la red o cuando se lleva a
cabo la creacin de un falso flujo de datos.
Estos ataques son los ms perjudiciales para el atacado.
24.
SINCRONIZACION DE RELOJES DE TIEMPO
NTP (Netowork Time Protocol) es un protocolo de red que provee mecanismos

para sincronizar el tiempo en los dispositivos presentes en una red. Este
protocolo se ha desarrollado hasta la versin 4, el cual ha sido formalizado en
el RFC 1305. Existe tambin una versin simple del protocolo (SNTP) la cual
se encuentra descrita en el RFC 2030. [37]
El tiempo es extremadamente importante en los dispositivos de red. ste es el
nico marco de referencia que hay entre ellos. Por este motivo es importante
mantener sincronizado el tiempo de la red y poder de as realizar una
correlacin confiable, teniendo en cuenta los logs generados por los
dispositivos. [38]
25. Arquitectura del sistema

El protocolo NTP fue diseado para ser usado por un conjunto de clientes y
servidores de tiempo. En ste existe un servidor primario (Stratum 1), el cual
debe estar conectado a un reloj de referencia de gran precisin y debe contar
con el software necesario para manejar NTP. La idea es que este servidor
primario transmita la informacin del tiempo a otros servidores de tiempo
(Stratum 2) quienes, a su vez, deben transmitir la informacin y sincronizar a
otros servidores. Todos los participantes de este esquema deben tener el
software requerido para la sincronizacin por NTP.
En NTP, existen dos formas de sincronizacin. La mencionada anteriormente,
en la cual existe un cliente que se sincroniza con un servidor. Este cliente se
comporta a su vez como un servidor de otro cliente, y tendr una numeracin
de Stratum inmediatamente superior a la de su servidor. En la otra forma,
existen dos maquinas que se prestan servicios de sincronizacin entre s, es
decir, cada mquina se configura para comportarse como cliente o servidor,
segn el que sea m. En esta configuracin los servidores se llaman peers.
La siguiente Figura refleja el esquema jerrquico usado por NTP. sta jerarqua
puede ser usada hasta 16 niveles.
Figura 6. Esquema jerrquico de NTP. [37]
NTP provee una precisin de tiempo de uno o dos milisegundos en LANs, y

hasta 10 milisegundos en WANs.
Este protocolo trabaja enviando mensajes UDP a travs del puerto 123
26.
SSH
SSH (The Secure Shell) es un protocolo que permite transportar datos de

manera segura. SSH acta transmitiendo datos sobre TCP/IP, y utiliza
mecanismos fuertes de cifrado y autenticacin que garantizan la integridad,
confidencialidad y autenticacin durante la transferencia de los datos. [41]
El cifrado de los datos se realiza de una manera transparente para los
usuarios. Cuando los datos van a ser enviados a travs de la red, SSH los cifra
automticamente, y al ser recibidos los descifra automticamente.
27. Arquitectura de SSH
SSH utiliza una arquitectura cliente/servidor, en la cual una mquina acta
como servidor SSH, el cual debe tener un programa servidor corriendo, y es el
encargado de aceptar o denegar conexiones con los diferentes clientes,
dependiendo del xito de la autenticacin. As como, de prestar los servicios
propios de SSH.
Las mquinas que actan como clientes, deben tener configurado e instalado
un programa cliente SSH, por el cual se realizan las peticiones al servidor.
El servidor escucha por el puerto 22 esperando para establecer la conexin con
el cliente. El servidor puede conectarse con muchos clientes y la comunicacin
entre cliente/servidor es bidireccional. Tal y como se muestra en la Figura 6.
Figura 7. Esquema de distribucin de SSH

Una vez los clientes se conectan al servidor, el servidor acepta la conexin y
responde al cliente enviando su versin de identificacin. El cliente recibe la
identificacin del servidor y enva la suya propia. Esto se realiza con el fin de
verificar que la conexin se realizo por el puerto correcto, adems de declarar
la versin del protocolo usado y del software utilizado de cada uno.
Despus del intercambio de identificaciones, se pasa a un protocolo binario
basado en paquetes, en el cual el servidor enva su llave de host (cada host
tiene un llave RSA utilizada para autenticar el host), la llave del servidor, y otra
informacin al cliente. Cuando el cliente la recibe, genera una llave de sesin,
la cifra usando ambas llaves de RSA, y enva la llave de sesin cifrada y el tipo
de cifrado seleccionado al servidor. El servidor enva un mensaje cifrado de
confirmacin al cliente. [43]
Luego, el cliente se autentica usando alguno de los mtodos de autenticacin.
Si la autenticacin es exitosa, el cliente hace peticiones de preparacin para la
sesin.
28. Caractersticas de SSH.

SSH tiene algunas caractersticas, descritas a continuacin, que proveen un
nivel de seguridad alto, y protegen la comunicacin entre cliente-servidor.
28.1.1.1.
Privacidad.
SSH suministra privacidad de los datos que viajan por la red por medio del
cifrado. ste cifrado se basa en llaves aleatorias que son negociadas
seguramente para la sesin y luego destruidas cuando la sesin es finalizada.
El protocolo Secure Shell soporta una variedad de algoritmos de cifrado para
los datos, incluyendo los siguientes: TSS, RC4, IDEA, DES, y triple-DES
(3DES).
28.1.1.2.
Autenticacin.
El protocolo SSH contiene dos autenticaciones: el cliente verifica la

identificacin del servidor SSH y el servidor valida la identidad de los clientes
que requieren una conexin.
La autenticacin del servidor se realiza para que el cliente est seguro de que
el servidor no es un atacante que quiera realizar acciones no autorizadas.
La autenticacin es usualmente realizada con contraseas, sin embargo ste
esquema es una forma dbil de autenticacin, ya que la contrasea puede ser
obtenida por un atacante. Existen otros mtodos de autenticacin tales como
autenticacin por rhosts, autenticacin por rhosts basado en RSA, y
autenticacin por RSA. Sin embargo, existen configuraciones en las cuales se
agregan otros mtodos de autenticacin.
28.1.1.3.
Autorizacin.
Los servidores de SSH tiene varios esquemas para la restriccin de las

acciones de los clientes: acceso a sesiones interactivas, reenvo de puertos
(port forwarding), agente de reenvo de llaves, entre otros. Esto se hace con la
intencin de no dar privilegios iguales a todos los clientes, sino por el contrario,
se restringen de acuerdo a sus funciones.
28.1.1.4.
Integridad
Para asegurar que los datos que llegan al receptor no fueron alterados y son
los mismos que envo el emisor, el transporte con SSH revisa la integridad de
los datos, por medio del uso de algoritmos hash basados en MD5 y SHA-1.
28.1.1.5.
Tnel (Tunneling)
La creacin de un tnel SSH se realiza para encapsular algn servicio basado

en TCP (como telnet) en una sesin de SSH. Esto se realiza con el fin de dar la
seguridad de SSH a otros protocolos.
29. Usos comunes de SSH
El protocolo SSH es usado comnmente para las siguientes actividades:
Administrar sistemas de forma segura. SSH fue creado inicialmente para

proveer acceso seguro a terminales de servidores Unix sobre redes
TCP/IP. Se usa para remplazar las conexiones basadas en telnet y
lograr la administracin remota a los servidores de forma segura .
Transferencia segura de archivos. Esta tecnologa se utiliza para

remplazar la funcionalidad de FTP y es usada para la transferencia de
archivos de forma segura, sobre todo cuando los datos transmitidos
contienen informacin confidencial.
Conexiones seguras en aplicaciones. SSH ofrece dos diversos medios

de asegurar conexiones de aplicaciones entre los equipos de los
usuarios finales y los servidores de la aplicacin. Con el uso de lnea de
comandos, puede ser usado como terminal seguro para remplazar el
acceso basado en Telnet de los hosts. Otro medio es usar SSH para
hacer un tnel TCP, y redireccionar los puertos de conexin sobre el
canal cifrado en ambas direcciones de la comunicacin. As establecer
la comunicacin a travs del tnel, lo que garantiza integridad,
confidencialidad y autenticacin en la comunicacin, aun sin la
necesidad de cambiar la funcionalidad de la aplicacin ni la interfaz de
usuario. sta caracterstica hace que SSH sea una solucin genrica
para asegurar las conexiones.
30. DESARROLLO DEL PROYECTO

El desarrollo de ste proyecto est orientado a la definicin de una gua
metodolgica para la gestin centralizada de registros de eventos de seguridad
de red, para que pueda ser utilizada en organizaciones de pequea y mediana
escala. Para lograr lo anterior, el proyecto fue desarrollado en cinco etapas
consecutivas.
La etapa inicial busca la apropiacin del conocimiento asociado a la gestin de
seguridad, registros de eventos y computacin forense. Esta etapa se
desarrollo por medio de la investigacin en fuentes bibliogrficas e indagacin
con personas ms cercanas a los conceptos de inters. sta etapa se ve
reflejada en el captulo 2 de ste documento.
Una vez, obtenido el conocimiento propio del tema a desarrollar, la etapa
siguiente es realizar el anlisis y definicin de requerimientos para la gestin
centralizada de registros eventos de seguridad. La definicin de los
requerimientos se realiza con base en un anlisis de las caractersticas de una
red tpica de una pyme. y en los conceptos de correlacin y evidencia digital
obtenidos en la etapa inicial.
Luego de la etapa de levantamiento de requerimientos, se ejecuta la definicin
de una infraestructura de software y hardware para la gestin centralizada de
registros de eventos de seguridad que soporte los requerimientos definidos
anteriormente. La definicin de dicha infraestructura se realiza por medio del
diseo de un sistema de centralizacin que debe cumplir con los
requerimientos definidos, y de la definicin de herramientas que soporten dicho
diseo.
A continuacin, se procede a definir una gua metodolgica para la
implantacin de la infraestructura definida. sta etapa se desarrolla
estructurando el diseo del sistema de centralizacin que se defini
anteriormente. Para esto se definen una serie de actividades y mtodos que
debe realizar el usuario final con el fin de lograr la centralizacin de los
registros de eventos de seguridad.
Finalmente, la etapa a realizar es validar la gua metodolgica mediante la
definicin e implementacin de un caso de prueba que se ajuste a las
caractersticas de la red de una pyme. Esta etapa de validacin se realiza
mediante el seguimiento paso a paso de la gua metodolgica y observando los
resultados obtenidos.
Este captulo abarca las etapas 2, 3 y 4 del desarrollo del proyecto. La etapa de
validacin de la gua metodolgica se encuentra comprendido en el capitulo 4
Validacin de la gua Metodolgica de este documento
31.
RED TIPICA DE UNA PYME.
La definicin de una red tpica de una pyme se planeo realizar por medio del
levantamiento de informacin en entidades pblicas o privadas, cuyo objetivo
fuese el estudio y apoyo a las pymes. Sin embargo, al realizar esta actividad,
se encontr que no existen grandes estudios a nivel tecnolgico de la pequea
y mediana empresa, la cual nos pudiera revelar informacin apropiada para la
definicin de las caractersticas de una pyme.
De este modo, se planeo en segunda medida realizar un estudio con una
muestra significativa de pequeas y medianas empresas, para lograr as
obtener la informacin deseada. Al ejecutar esta accin, se encontr que no es
sencillo obtener informacin en cuanto al manejo de la seguridad informtica y
de la red de pymes donde no se tiene una relacin de confianza previa, por lo
que el levantamiento de informacin no tuvo xito.
Finalmente, se decidi buscar la informacin de las caractersticas de una red
tpica de una pyme por medio del tamao definido para estas legalmente,
obteniendo as un nmero aproximado de usuarios. Seguidamente, se busc
informacin en los proveedores de tecnologa para pymes, de esta manera se
consigui obtener la informacin deseada y se pudo realizar un esquema
genrico de una red tpica de una red.
32. Tamao de una Pyme
Segn la ley LEY 905 DE 2004 que reforma la LEY 590 DE 2000 se define el
tamao las microempresas, pequeas empresas y medianas empresas de la
siguiente manera:
ARTCULO 2o. El artculo 2o de la Ley 590 de 2000 quedar as:
Artculo 2o. Definiciones. Para todos los efectos, se entiende por micro
incluidas las Famiempresas pequea y mediana empresa, toda unidad de
explotacin econmica, realizada por persona natural o jurdica, en actividades
empresariales, agropecuarias, industriales, comerciales o de servicios rurales o
urbanos, que responda a dos (2) de los siguientes parmetros:
1. Mediana empresa:
a) Planta de personal entre cincuenta y uno (51) y doscientos (200)
trabajadores, o
b) Activos totales por valor entre cinco mil uno (5.001) a treinta mil (30.000)
salarios mnimos mensuales legales vigentes.
2. Pequea empresa:
a) Planta de personal entre once (11) y cincuenta (50) trabaja-dores, o
b) Activos totales por valor entre quinientos uno (501) y menos de cinco mil
(5.000) salarios mnimos mensuales legales vigentes o,
3. Microempresa:
a) Planta de personal no superior a los diez (10) trabajadores o,
b) Activos totales excluida la vivienda por valor inferior a quinientos (500)
salarios mnimos mensuales legales vigentes o,
Para efectos de la definicin del tamao de una red el factor que interesa es el
nmero de trabajadores, por lo cual se puede deducir que siendo una Pyme
una empresa pequea o mediana, el nmero de trabajadores podra oscilar
entre 11 y 200 trabajadores.
33. Caractersticas de una red tpica de una PyME
33.1.1.1.
Red tpica SMB Microsoft
En [29] definen una red tpica SMB con productos Microsoft de la siguiente
manera.
Figura 8.Red Tpica de una pyme definida por Microsoft. [29]

En esta red se identifican los servidores tpicos as como los equipos tpicos
tanto de usuarios como de red y seguridad que se enuncian a continuacin:
DC. Domain Controller
Un DC es responsable de controlar y mantener las actividades del dominio.
Ms especficamente responde a solicitudes de autenticacin, y de chequeo de
permisos.
En un DC estn [30]:
Una copia fsica de la base de datos Active Directoty
Un Active Directory esta compuesto por
o LDAP
o X.500
o DNS
o Kerberos
Servicios de Registros
o Kerberos
o LAN Manager Authentication
Adicionalmente sirve como servidor DHCP.
Servidor de Archivos
Servidor de Impresin.
Exchange:
Servidor de correo electrnico basado en PC.
SQL Server
Servidor de base de datos basado en PC
IIS
Servidor Web basado en PC
Servidor de Seguridad/VPN (ISA Server)
Punto de Acceso Inalmbrico
33.1.1.2.
Servicios de la red tpica de una PyME y sus

principales implementaciones
Con base en los componentes definidos en [29], una red tpica de una PyME
tendra los siguientes servicios:
Servidor de Autenticacin
DNS
DHCP
Servidor de Archivos
Servidor de Impresin
Servidor de correo electrnico
Segn estadsticas de [33] los 3 servidores de correo ms usados son:
o Microsoft ESMTP MAIL Service
o Sendmail
o Imail
Servidor o manejador de bases de datos
Servidor Web
De acuerdo con [31] los tres servidores Web ms usados en Agosto de
2006 son:
o Apache.
o Microsoft IIS.
o Zeus Web Server.
Cubriendo entre los 3 un 93,21% de los encuestados.
Servidor VPN + Firewall
Segn [32] la industria de los Firewalls con VPN integrados ha crecido
notablemente; es el tercer segmento ms grande dentro del software de
seguridad. Tambin aseguran que segn un estudio de Infonetics
Research, Cisco System es la empresa lder en este mercado seguida
por
Check Point Software Technologies. Sumando entre ambas un
59,2% del
mercado.
Access Point inalmbrico
Enrutador hacia Internet
34.
REQUERIMIENTOS PARA LA GESTION CENTRALIZADA
DE LOS REGISTROS DE EVENTOS DE SEGURIDAD

De acuerdo con los requisitos definidos anteriormente (seccin 2.2) para
realizar el proceso de correlacin, y para mantener el carcter de evidencia
digital de los registros de eventos, se definen los requerimientos propios para la
gestin centralizada de stos.
Estos requerimientos se clasifican en requerimientos funcionales y
requerimientos no funcionales. Los funcionales son aquellos que se definen la
interaccin entre el sistema y sus usuarios u otros sistemas, independiente a su
implementacin. Mientras que los no funcionales, son aquellos que describen
aspectos del sistema visibles por el usuario pero que no se relacionan en forma
directa al comportamiento funcional del sistema. [35]
35. Requerimientos funcionales
Los registros de eventos deben quedar en un punto central.

Es necesario garantizar que los registros de eventos queden todos en un
solo formato polimrfico para su correlacin.
El formato por lo menos debe tener
o Identificacin del sistema que gener el evento
o Estampilla de tiempo
o Detalle del evento
Debe existir un proceso de reduccin de datos para el proceso de
correlacin.
Con esto se busca la eficiencia en la correlacin y se puede hacer

mediante:
o Compresin de datos
o Borrado de duplicados
o Filtrar datos combinando varios eventos relacionados en uno solo.
Las estampillas de tiempo de los registros de eventos deben estar
sincronizadas y deben incluir por lo menos la fecha y hora en la que se
gener.
Los registros de eventos deben tener algn mecanismo de identificacin
del sistema o tecnologa de informacin que los gener para efectos de
su utilizacin como evidencia digital.
36. Requerimientos no funcionales
Se debe utilizar un mtodo de transporte confiable.

o El mtodo de trasporte debe ser orientado a conexin
o Debe garantizar la integridad de los datos.
o Debe mantener algn mecanismo de autenticacin
o Los datos deben estar cifrados durante el transporte.
Se debe utilizar algn mecanismo de autenticacin con respecto al
sistema que los gener.
Se debe asegurar que no se perdi, ni camb ningn dato en los
registros de eventos para su uso como evidencia digital.
Se debe verificar que el sistema est en correcto funcionamiento en el
momento en que se generan o modifican los registros.
Los registros de eventos de seguridad, debe poder ser utilizados en
tiempo presente y futuro.
o Esto se refiere a que la forma de almacenamiento debe poder ser
consultada en el futuro y en el presente.
37. Diagrama de Red tpica de una Pyme.

De acuerdo al anlisis realizado de la red de una pyme, se determina que el
esquema de red que define apropiadamente la red tpica de una pyme es como
se muestra en la figura 8.
Figura 9. Diagrama de una Red tpica de una pyme

37.1.1.1.
Logs de Seguridad en una Pyme
De acuerdo con la clasificacin de NIST [34] podramos encontrar los

siguientes logs de seguridad en una Pyme:
Logs de Aplicaciones de Seguridad
Logs de Servidor de Autenticacin
Logs de VPN+Firewall
Logs de Antivirus/Antimalware
Logs de Sistemas Operativos (estaciones de trabajo, servidores y equipos
de red)
Logs de Sistema
Logs de Auditabilidad
Logs de Aplicaciones
Logs del servidor de correo
Logs del servidor Web
Logs del servidor de archivos
Logs del servidor de DBMS(base de datos)
38.
DEFINICIN DE INFRAESTRUCTURA
Tras haber definido los requerimientos que debe satisfacer la gua

metodolgica, se procede a realizar la definicin de los procedimientos que
deben estar comprendidos en la gua metodolgica, para la satisfaccin de la
totalidad de los requerimientos.
39. Definicin del mtodo de sincronizacin de relojes de tiempo.
Al detectar la necesidad de que todos los relojes de tiempo de los dispositivos
presentes en la red se encuentren sincronizados, para que a su vez, las
estampillas de tiempo de los logs generados por estos dispositivos se
encuentren sincronizadas, se establece el uso del protocolo de tiempo de red
(NTP).
Aunque se tiene conocimiento de otro protocolo de sincronizacin de tiempo
ms simple (SNTP), se determina el uso de NTP debido a que un servidor NTP
puede prestar servicios a un cliente SNTP, lo cual provee mayor cobertura.
Para la instalacin y configuracin de NTP es necesario determinar un servidor
de NTP, el cual debe ser un equipo con sistema operativo UNIX Like 1, y debe
contar con el software NTPd [48].
De igual forma, los clientes con sistema operativo UNIX LIKE, deben contar con
el mismo software del servidor para su configuracin .
En cuanto a los clientes con sistema operativo Windows 2000, este sistema
operativo tiene incorporado el protocolo SNTP v2.
Los sistemas operativos Windows XP, tienen incluido su propio cliente de NTP
para la sincronizacin de relojes, la cual se describe en la gua metodolgica.
[ANEXO 1].
Los dispositivos de red (routers, access point, etc), deben tambin ser
sincronizados. Estos tienen soporte desde la fbrica, para correr el protocolo
NTP, o SNTP.
40. Definicin del mtodo de transporte
Para cubrir el requerimiento que hace referencia a tener todos los registros de
eventos en un punto central de la red, se consideran los protocolos que pueden
proveer transporte de logs (SNMP, Syslog y sus versiones mejoradas).
1
Entindase como Unix Like todo sistema operativo que se comporte de manera similar a un
sistema UNIX, como Linux.
Sin embargo, hay que tener en cuenta que no basta con transportar los
registros de eventos a un punto central. Este transporte debe realizarse
cumpliendo con los requerimientos que obligan a tener un mecanismo que
garantice autenticacin, integridad, y confidencialidad. Adicionalmente, este
transporte debe ser orientado a conexin.
Para establecer el mtodo ms apropiado para realizar el transporte, se busca
el mtodo que cumpla con la mayor cantidad de requerimientos posibles. Para
esto, se realiza una comparacin entre los mtodos contemplados teniendo en
cuenta los requerimientos con los que cumplen.
Mtodo de transporte
Syslog-ng
RFC 3195
/Secure Syslog
Nsyslog
Modular Syslog(msyslog)
Stealthful Logging
SNMP Traps v1.
SNMP Traps v3.
Integridad
Autenticacin
Confidencialidad
Orientado
conexin
Tabla 3. Caracterstica de los Mtodos de transporte
Como se observa en la Tabla 3 ninguno de los mtodos contemplados cumple

con todos los requisitos necesarios para realizar el transporte. Por lo que se
contempla la idea de establecer un tnel SSH, por medio del cual se encapsule
algn servicio basado en TCP en una sesin de SSH. Esto garantiza satisfacer
los requerimientos de proveer autenticacin, integridad, confidencialidad y
transporte orientado a conexin.
Para la eleccin del servicio utilizado para ser encapsulado en SSH, se observa
en la tabla 3 que syslog-ng, secure syslog (rfc 3195) y Nsyslog y SNMP v.3 son
basados en TCP, por lo que cualquiera de stos podra ser utilizado.
Sin embargo, se encuentra que secure syslog (rfc 3195) no tiene
implementacin para sistemas operativos Windows, lo cual restringe su uso en
la gua metodolgica, considerando que este sistema operativo es usualmente
utilizado en pequeas y medianas empresas.
Finalmente, se decide el uso de syslog-ng, ya que adems de soportar los
requerimientos necesarios, provee el beneficio de almacenar los registros de
eventos en una base de datos, lo cual, aunque no es requerido, facilita la
gestin centralizada de los logs, y hace ms sencilla su correlacin.
Con la implementacin de syslog-ng, se garantiza tambin el cumplimiento del
requerimiento que exige que los registros de eventos queden todos en un solo
formato polimrfico para su correlacin, ya que el formato utilizado es el propio
de syslog.
41. Definicin de herramientas de uso en la gua metodolgica.

Una vez definido el mtodo de transporte para los registros de eventos de
seguridad, se determinan las herramientas que ayuden a realizar el transporte
con base en los protocolos ya establecidos.
Al considerar que el protocolo SSH acta bajo una arquitectura cliente servidor,
se considera necesaria la determinacin de las herramientas para el servidor,
as como para cada uno de los clientes a utilizar, teniendo en cuenta los
dispositivos utilizados en una red tpica de una pyme.
Es importante aclarar que todas las herramientas utilizadas para la
centralizacin de registros de eventos son de libre distribucin lo que permite a
todas las pymes seguir la gua metodolgica sin limitaciones econmicas de
software.
Con este documento se adjuntan versiones adquiridas durante el segundo
semestre de 2006 de todas las herramientas utilizadas.
41.1.1.1.
Herramientas para el servidor.
Para la creacin del tnel SSH, se debe buscar una herramienta que permita
establecer el tnel en una mquina con sistema operativo UNIX LIKE y acte
como servidor de SSH. Se recomienda el uso de la herramienta Open SSH
[44], ya que sta es una herramienta libre que permite establecer el tnel, y
soporta todas las versiones del protocolo SSH. sta herramienta es
desarrollada por the OpenBSD Project.
Luego, se debe obtener la herramienta syslog-ng, la cual se encuentra
disponible en la pgina principal de syslog-ng [45]. Esta herramienta se debe
configurar para responder a los servicios solicitados por los clientes, de
acuerdo como se muestra en la gua metodolgica. [ANEXO 1]
41.1.1.2.
Herramientas para clientes con sistema operativo UNIX

LIKE.
En los clientes con sistema operativo UNIX LIKE, para establecer el tnel SSH,
se sugiere el uso de la herramienta SSH client [44]. Aunque cualquier otra que
permita establecer un tnel SSH con el servidor podra ser til.
En cuanto a syslog-ng, se utiliza la misma herramienta nombrada para el
servidor, y su configuracin es tal como se muestra en la gua metodolgica.
[ANEXO 1]
41.1.1.3.
Herramientas para clientes con sistema operativo

WINDOWS.
En los equipos con sistema operativo Windows, para establecer el tnel se

debe usar una herramienta que permita su creacin, la cual debe permitir su
administracin por medio de lnea de comandos, as como su ejecucin de
fondo (en background), de ste modo el proceso de establecer el tnel ser
transparente para el usuario final. Para este proceso se recomienda el uso de
la herramienta PLINK [46], la cual hace parte del paquete PUTTY y permite la
conexin por medio de lnea de comandos.
Existe una herramienta llamada LASSO [47], la cual es un software de cdigo
abierto, diseado para recoger registros de eventos en Windows, pasarlos a
formato syslog y transportarlos va TCP a cualquier receptor de logs compatible
con syslog-ng.
41.1.1.4.
Herramientas para otros clientes.
Los dispositivos de red presentes en la red de la pyme, como requerimiento de

la gua deben soportar syslog. De ste modo, ser posible realizar el transporte
de los logs. Sin embargo, como syslog no provee mecanismos de seguridad, es
necesario establecer una red alterna entre el dispositivo y un equipo con
sistema operativo UNIX Like, al cual se enven los logs. Y este deber estar
configurado como cliente, para enviar sus logs y los del dispositivo al servidor.
En el caso de los access point, y en caso de no tener un computador disponible
para la red alterna de los dems dispositivos de red, es posible realizar la
centralizacin por medio de syslog con UDP sin embargo no se cumplira en su
totalidad con los requerimientos de la gua. Por no proveer integridad,
confidenciabilidad, ni autenticacin.
Actualmente, no se tiene implementado syslog seguro en los dispositivos de
red, sin embargo, probablemente en un futuro los dispositivos lo tengan
integrado.
42. Modelo de la infraestructura para la centralizacin de registros de
eventos de seguridad.
Con base en las definiciones de los mtodos para satisfacer los requerimientos
que debe satisfacer la gua y de las herramientas tecnolgicas que ayudan a
cumplir con los mtodos definidos, se modela la infraestructura de la gua
metodolgica de acuerdo al esquema de centralizacin mostrado en la figura 9.
Figura 10. Esquema de centralizacin de logs.

Como se observa en el esquema, el modelo se encuentra compuesto de un
nico servidor de logs, y una cantidad de clientes. La comunicacin entre los
clientes y el servidor es orientada a conexin y basada en el protocolo TCP.
Esta comunicacin tiene la caracterstica de garantizar la integridad de los
datos, confidencialidad y autenticacin. Estos principios de seguridad son
garantizados por medio del tnel SSH.
En cuanto a la instauracin del tnel SSH, en el servidor de logs se tiene un
servidor de SSH (sshd), este se obtiene con la herramienta Open SSH. El
servido de SSH se encarga de aceptar o denegar las conexiones con los
clientes, dependiendo de la satisfaccin o falla del proceso de autenticacin.
El servidor SSH (sshd) se comunica por TCP con la herramienta syslog-ng,
quien se encarga se recibir los registros de eventos transportados por el tnel y
enviarlos para su almacenamiento a una base de datos (mysql) y/o a archivos
planos.
Para el envo de los registros de eventos de los clientes con sistema operativo
UNIX LIKE, se tiene la herramienta syslog-ng. Syslog-ng se comunica va TCP
con un cliente SSH (ssh) de la herramienta Open SSH, y ste cliente SSH se
encarga de establecer el tnel con el servidor. De ste modo se realiza el
transporte de los registros de eventos desde el cliente hasta el servidor.
De forma similar, se realiza el transporte de los registros de eventos de los
clientes con sistema operativo Windows, en donde la herramienta LASSO
acta recogiendo los logs. sta herramienta se comunica va TCP con el cliente
SSH (plink) para Windows y transporta los registros de eventos por medio del
tnel SSH hasta el servidor.
Los clientes con sistema operativo diferente a Windows o UNIX LIKE, como los
dispositivos de red, envan sus registros de eventos por medio de syslog, a un
cliente UNIX LIKE. Este transporte se realiza va UDP y sin ningn mecanismo
de integridad, confidencialidad, ni autenticacin, por lo cual se debe tener una
red alterna, que se utilice nicamente para este transporte y debe ser
fsicamente altamente protegida.
43. Mtodos utilizados para la satisfaccin de los requerimientos de la
gua metodolgica.
A continuacin se muestra la manera en que se abarca cada uno de los
requerimientos definidos para la gua metodolgica, con la infraestructura
definida.
43.1.1.1.
Requerimientos funcionales
Los registros de eventos deben quedar en un punto central.

Como se observa en la estructura de la metodologa, el elemento principal de la
gua metodolgica es el transporte de los registros de eventos desde su lugar
de origen hasta un repositorio central ubicado en el servidor de logs. De ste
modo todo los registros de eventos quedan ubicados en un punto central.
Es necesario garantizar que los registros de eventos queden todos en un
solo formato polimrfico para su correlacin. Este formato debe contener
Identificacin del sistema que gener el evento, Estampilla de tiempo y
Detalle del evento.
Por medio del uso del protocolo syslog en la estructura de la gua
metodolgica, se garantiza que todos los registros de eventos enviados al
servidor de logs tengan un nico formato, el cual est compuesto de tres
campos: PRI (prioridad del evento), HEADER (en donde se encuentra la
estampilla de tiempo y el identificador del origen del evento) y MSG (contiene el
nombre de programa o proceso que genero el evento y el detalle del evento).
Las estampillas de tiempo de los registros de eventos deben estar

sincronizadas y deben incluir por lo menos la fecha y hora en la que se
gener.
Al sincronizar todos los relojes de tiempo de los dispositivos presentes en la red
se garantiza que las estampillas de tiempos de los registros de eventos se
encuentren sincronizados. Adicionalmente, con el protocolo syslog, se
garantiza que las estampillas de tiempo se encuentren en formato Mmm dd
hh:mm:ss, incluyendo as la fecha y hora del evento.
Los registros de eventos deben tener algn mecanismo de identificacin
del sistema o tecnologa de informacin que los gener para efectos de
su utilizacin como evidencia digital.
A travs del protocolo syslog se garantiza que todos los registros de eventos
enviados al servidor de logs tengan la informacin del sistema o tecnologa que
los gener. Esta informacin se encuentra contenida en el campo MSG
(contiene el nombre de programa o proceso que genero el evento y el detalle
del evento) de los mensajes de syslog.
43.1.1.2.
Requerimientos no funcionales
Se debe utilizar un mtodo de transporte confiable: el mtodo de

trasporte debe ser orientado a conexin, debe garantizar la integridad de
los datos, debe mantener algn mecanismo de autenticacin y los datos
deben estar cifrados durante el transporte.
Este requerimiento es satisfecho por medio de la creacin del tnel SSH, a
travs del cual, viajan los registros de eventos. El protocolo SSH es orientado a
conexin. Suministra la privacidad de los datos utilizando algoritmos de cifrado
para los datos. Utiliza mtodos de autenticacin, en ste caso el proceso de
autenticacin se realizar por medio de llaves pblicas y privadas. Y garantiza
que los datos que llegan al servidor de logs son los mismos que salieron del
origen, por medio de la utilizacin de algoritmos Hash para la integridad de los
datos.
Se debe utilizar algn mecanismo de autenticacin con respecto al
sistema que los gener.
El protocolo SSH permite la autenticacin del cliente con el servidor. El mtodo
definido para realizar la autenticacin es por medio de llaves pblicas y
privadas.
Se debe asegurar que no se perdi, ni camb ningn dato en los registros
de eventos para su uso como evidencia digital.
El protocolo SSH garantiza la integridad de los datos por medio del uso de
algoritmos HASH garantizando as la integridad de los datos.
Se debe verificar que el sistema est en correcto funcionamiento en el
momento en que se generan o modifican los registros.
Para asegurar que el sistema est en correcto funcionamiento en el momento

en que se crean o modifican los datos, se sugiere realizar auditorias, que
evalen el comportamiento de los sistemas.
Los registros de eventos de seguridad, deben poder ser utilizados en
tiempo presente y futuro.
Para permitir que los registros de eventos de seguridad se encuentren
disponibles en tiempo presente y futuro se recomienda que la pyme tenga
polticas de procedimientos documentados en los cuales se describa el proceso
de elaboracin de copias de respaldo.
Debe existir un proceso de reduccin de datos para el proceso de
correlacin, mediante compresin de datos, borrado de duplicados o
filtrado de datos combinando varios eventos relacionados en uno solo.
Al analizar ste requerimiento se observa que se contradice con el
requerimiento que sugiere asegurar que no se perdi, ni camb ningn dato en
los registros de eventos para su uso como evidencia digital. Por tal motivo este
requerimiento no ser tenido en cuenta.
44.
ESTRUCTURA DE LA GUA METODOLGICA
La gua metodolgica para la gestin centralizada de registros de eventos de

seguridad definida pretende llevar al administrador de la red de una pyme a
una manera ms sencilla y ms gil de analizar y monitorear los registros de
eventos generados en la red.
La gua procura cumplir con los requerimientos necesarios para realizar una
futura correlacin de registros de eventos, as como mantener el carcter de
evidencia digital de los logs.
45. Diagrama de flujo de la gua metodolgica.
La estructura de la gua metodolgica se basa en el siguiente diagrama de flujo
de datos, en el cual se exponen cada uno de los pasos que hacen parte de la
gua metodolgica.
Figura 11. Diagrama de flujo de la gua metodolgica.

45.1.1.1.
Sincronizacin de los relojes de tiempo.
El paso inicial para lograr la centralizacin de registros de eventos de

seguridad, es realizar la sincronizacin de los relojes de tiempo de todos los
dispositivos presentes en la red de la pyme. Para esto, se debe seleccionar un
servidor de NTP con sistema operativo UNIX LIKE. Este servidor puede ser el
mismo servidor de logs, aunque no es requerido.
A continuacin, se realiza la instalacin y configuracin de NTPd en el servidor
y se configuran los clientes de acuerdo a su tipo (UNIX LIKE, Windows o
dispositivo de red), con el fin de que todos los equipos de la red hagan uso del
protocolo NTP.
45.1.1.2.
Creacin del Tnel SSH.
Tras asegurar que todos los dispositivos de la red tienen sus relojes de tiempo
sincronizados, se procede a realizar la creacin del tnel SSH.
Para ello es necesario elegir el equipo con sistema operativo RED HAT LINUX,
el cual actuar como servidor de SSH. ste ser el mismo equipo que prestar
el servicio de recibir los logs enviados por todos los clientes y de almacenarlos.
Una vez configurado el servidor de SSH, como se muestra en el ANEXO 1, se
crea el tnel desde los clientes. El proceso de creacin del tnel depende del
tipo de cliente que se vaya a configurar (LINUX, WINDOWS).
Para la creacin del tnel SSH se debe tener algn mecanismo de
autenticacin, el mecanismo recomendado por la gua metodolgica es por
medio de llaves pblicas y privadas. Esto con el fin de que el establecimiento
del tnel pueda hacerse como un servicio del sistema operativo, y
adicionalmente para que la creacin del tnel y su proceso de autenticacin
sea transparente para los usuarios finales.
En los sistemas Operativos Windows, para establecer el tnel como un servicio
del sistema, es necesaria la creacin de una cuenta de usuario en el sistema
operativo. Esta cuenta requiere contar con privilegios administrativos. El
objetivo de la creacin de la cuenta, es poder establecer el servicio en
Windows, ya que los servicios deben quedar ligados a una cuenta de usuario.
45.1.1.3.
Instalacin y creacin del repositorio de datos.
Para el almacenamiento de los logs en el servidor de logs, se tienen dos

opciones: almacenamiento en bases de datos o almacenamiento de logs en
archivos. Tambin existe la posibilidad de almacenarlos de forma duplicada en
Bases de datos y archivos planos.
Por lo anterior, este paso de la gua metodolgica, es opcional, y depende de lo
que se requiera en cuanto al almacenamiento.
Inicialmente, para el almacenamiento en Base de Datos, se debe realizar la
instalacin de MySQL en el servidor de logs. Luego, se debe realizar la
creacin de la base de Datos de logs y finalmente se debe configurar el pipe, el
cual se encargar de realizar la comunicacin entre syslog-ng y mysql.
45.1.1.4.
Instalacin y Configuracin
de eventos.
de herramientas de envo
En el servidor, para la recepcin de los registros de eventos de seguridad,

antes de la instalacin de syslog-ng, es necesario realizar la instalacin de la
librera Eventlog. Despus de esta instalacin se procede a instalar y configurar
la herramienta syslog-ng, de acuerdo como se muestra en la gua

metodolgica. [ANEXO 1]
A continuacin, se debe establecer syslog-ng como un servicio en el servidor,
con el fin de que al iniciar el sistema operativo, inicie tambin el servicio de
syslog-ng, sin necesidad de intervencin humana.
Adicionalmente, en el servidor se debe crear el archivo de configuracin de
syslog-ng. En l se especifica la forma de almacenamiento de los registros de
eventos en el servidor que se requiera. Es decir, si se decide que el
almacenamiento debe ser en Bases de datos, se debe especificar en este
archivo, de igual forma, si se decide en archivos, o en forma duplicada. Esta
configuracin se especifica en el ANEXO 1.
En Los clientes se debe configurar la herramienta de envo de acuerdo con su
sistema operativo. De igual manera, para todos los clientes, se debe establecer
el transporte de los registros de eventos como un servicio.
45.1.1.5.
Procedimiento de copias de respaldo.
Una vez configurado y probado el transporte y almacenamiento centralizado de

los registros de eventos de seguridad, es necesario realizar una revisin de los
procedimientos de elaboracin de copias de respaldo en la pyme.
Para esto, se debe evaluar si se tiene un procedimiento que permita
peridicamente almacenar una copia de los registros de eventos centralizados,
sea en la base de datos o en archivos planos. Adicionalmente, se debe revisar
que estas copias de respaldo puedan ser consultadas en tiempo presente y en
tiempo futuro.
En caso, en que no se tenga dicho procedimiento o no cumpla con las
especificaciones anteriores, se hace necesario la creacin o modificacin de
una poltica documentada que describa el procedimiento, y se aplique a la
pyme.
Esto se realiza con el fin de que los registros de eventos de seguridad, se
encuentren disponibles y se puedan consultar en tiempo presente y futuro. Por
tal motivo, vale la pena recalcar que las copias de seguridad deben ir
perfectamente rotuladas, indicando como mnimo la fecha a la que pertenecen,
y un identificador.
45.1.1.6.
Establecer Auditoria.
Para garantizar que los registros de eventos fueron generados o modificados

por un sistema que se encontraba en correcto funcionamiento la gua
metodolgica sugiere realizar auditorias peridicas, en las cuales se evale el
funcionamiento del sistema.
46. Orden secuencial de pasos para la configuracin
de la
centralizacin.
La configuracin de cada equipo para la centralizacin de registros de eventos
debe cumplir con una secuencia de pasos, los cuales deben ser seguidos
estrictamente en el orden descrito a continuacin para cada equipo.
46.1.1.1.
Secuencia de pasos en la configuracin

de logs.
del servidor
La Figura 11 muestra el diagrama de flujo que describe la secuencia de pasos

a seguir para la configuracin del servidor.
Figura 12. Diagrama de Flujo para la configuracin
del servidor
46.1.1.2.

clientes UNIX LIKE
de los

a seguir para la configuracin de los clientes con sistema operativo UNIX LIKE.
de los clientes UNIX LIKE
46.1.1.3.

clientes WINDOWS
de los

a seguir para la configuracin de los clientes WINDOWS.
de los clientes WINDOWS
46.1.1.4.

dispositivos de red.
de clientes
Las Figuras 14 y 15 muestran los diagramas de flujo que describen la

secuencia de pasos a seguir para la configuracin de los clientes dispositivos
de red, as como del cliente UNIX LIKE que recibe sus registros de eventos y
los enva al servidor de logs.

dispositivos de red.
de los clientes
Figura 16. Diagrama de Flujo para la configuracin de los clientes UNIX LIKE,
receptores de logs de los dispositivos de red.
La configuracin del equipo encargado de recibir los registros de eventos
enviados por los dispositivos de red, por medio de syslog y de enviarlos al
servidor de logs, se realiza de manera similar a la configuracin de un cliente
UNIX LIKE. Sin embrago en la configuracin se Syslog-ng existe una variacin,
la cual puede ser detallada en la gua metodolgica. [ANEXO 1]
47. Centralizacin de registros de eventos de herramientas utilizadas en
pymes.
Los registros de eventos de las herramientas de seguridad utilizadas en la
pyme para la proteccin informtica, tales como Antivirus, AntiSpyware,
Firewalls, etc. Deben ser tenidos en cuenta dentro del esquema de
centralizacin.
Se sugiere al administrador, elegir herramientas de seguridad que permitan

reportar sus logs por medio del protocolo syslog. Tambien existe la posibilidad,
si la herramienta es software, de utilizar algn mecanismo que permita reportar
los registros de eventos al sistema operativo, ya sea Windows o Unix Like. De
esta manera, la herramienta utilizada en el sistema operativo para capturar los
registros de eventos y transportarlos a un receptor syslog-ng, ser quien se
encargue de su centralizacin.
48. Dependencia de los servicios.
Como se ha mencionado anteriormente, una de las caractersticas de la
centralizacin de registros de eventos propuesta por la gua metodolgica, es
precisamente la transparencia del proceso para el usuario final.
Para ello, cada actividad que se realice en el proceso de la centralizacin debe
ser instaurada como un servicio en el sistema se presenta. Es importante, tener
presente que estos servicios tienen una dependencia que se debe respetar
para el correcto funcionamiento del sistema.
Figura 17. Diagrama de Dependencias de los Servicios
En los clientes con sistema operativo Windows tanto LASSO como PLINK,
deben configurarse como un servicio del sistema operativo. En este caso el
servicio LASSO depende del servicio tunelssh.
En los cliente UNIX/UNIX, es importante tener en cuenta que se debe
configurar como servicios syslog-ng, ntpd y ssh. En donde syslog-ng depende
de ntpd y de ssh.
De forma similar sucede en el servidor de logs, en donde los servicios a
configurar son syslog-ng, mysql, sshd y ntpd. En este caso, syslog-ng depende
de los otros servicios.
La configuracin
de los servicios y las dependencias en cada sistema
operativo, se detalla en la gua metodolgica. [ANEXO 1].
49. VALIDACIN DE LA GUA METODOLGICA

En el presente captulo se describe el caso de prueba sobre el cual se realizo la
validacin de la gua metodolgica definida como resultado del trabajo
realizado.
50.
CARACTERSTICAS DEL CASO DE PRUEBA.
Para la validacin de la gua metodolgica se implementa una red que cumpla

con las caractersticas de una red tpica de una pyme en un ambiente
controlado.
Para este procedimiento se cont con un conjunto de equipos del laboratorio de
redes del departamento de Ingeniera de Sistemas de la Pontifica Universidad
Javeriana. Los equipos que se disponen para la elaboracin de la red son: 4
equipos con sistema operativo RED HAT LINUX, 2 equipos con sistema
operativo Windows XP y un router Cisco 1800.
La tabla 4 describe las caractersticas tcnicas de los equipos y su funcin en
la red y en el modelo de centralizacin.
Caractersticas
tcnicas
Compaq EVO
Sistema
Operativo
Red Hat Linux
Dell Optiplex Gx Windows XP

260
Compaq
Red Hat Linux
Deskpro
Dell Optiplex Gx
270
Dell Optiplex Gx
270
Dell Optiplex Gx
270
Router
Cisco
1800
Funcin en la
red
Servidor
logs
Host
Elemento del
modelo de
centralizacin
de Servidor de logs
Cliente Windows
Windows XP
Equipo
de Receptor de logs
gestin de logs de dispositivo de
red.
Host
Cliente Windows
Red Hat Linux
Host
Cliente UNIX Like
Red Hat Linux
Firewall
Cliente UNIX Like
Cisco
Software
v.12,4
IOS Enrutador
1841
Cliente dispositivo
de red
Tabla 4. Equipos de la red del caso de prueba
51. Diagrama De Red Del Caso De Prueba

El diagrama de red de la figura 18, describe el montaje de red realizado para la
ejecucin de la validacin.
Figura 18. Esquema de Red del caso de prueba
52.
DEFINICIN DE LOS RESULTADOS ESPERADOS.
Tras realizar el seguimiento de la gua metodolgica se espera obtener los

registros de eventos de los equipos presentes en la red, en un punto central.
Para lograr llegar a la centralizacin deseada se espera que la lista de
validacin mostrada en la tabla 5 se encuentre con todos los puntos
seleccionando la casilla si o N/A.
La casilla N/A se debe llenar nicamente para la validacin del proceso de
MySQL en caso, en que no se requiera el almacenamiento en Base de Datos
sino en archivos secuenciales.
Punto para
Equipo
verificar
Sincronizacin Clientes Windows XP
de los relojes
de tiempo.
Clientes Unix Like
Prueba
Rectifique que la hora mostrada a la derecha de la barra de herramientas

corresponda con la hora que muestra el servidor de NTP
Rectifique que la hora mostrada en a la derecha de la barra de
herramientas corresponda con la hora que muestra el servidor de NTP
Clientes Dispositivo de Verifique que la hora configurada en el sistema corresponda con la hora
red
mostrada por el servidor de NTP
Establecimiento Servidor de logs
Ejecute el netstat siguiente comando:
del tnel SSH
na | grep tcp
De esta manera verifique cuantas conexiones haca el puerto 22 existen. El
nmero existente debe ser igual a la cantidad de clientes que se
encuentren en funcionamiento en el momento.
Syslog-ng
Servidor de logs
Verifique que el proceso de syslog-ng se encuentra corriendo en el sistema.
Cliente Windows XP
Verifique que el proceso de LASSO se encuentra corriendo en el sistema.
Cliente Unix Like
Verifique que el proceso de syslog-ng se encuentra corriendo en el sistema.
Base de datos
Servidor de logs
Valide que el proceso de Mysql se encuentre corriendo en el servidor.
Servicios
y Servidor de logs
dependencias
Cliente Windows XP
Rectifique que al apagar y volver a iniciar la mquina los servicios de NTP,

SSH, Mysql y de syslog-ng se inicien automticamente
Rectifique que al apagar y volver a iniciar la mquina los servicios de
LASSO y PLink se inicien automticamente
Cliente Unix Like
Rectifique que al apagar y volver a iniciar la mquina los servicios de NTP,
SSH, y de syslog-ng se inicien automticamente
Centralizacin
Todos los equipos de Rectifique que en el repositorio de registros de eventos haya logs de todos
de registros de la red
los clientes.
eventos
tabla 5. Lista de validacin para la guia metodolgica
si
no
N/A
53.
OBSERVACIONES Y RESULTADOS OBTENIDOS.
Una vez concluido el seguimiento de cada paso de la gua metodolgica

aplicndolo a la red que simula una red tpica de una pyme, se encontraron los
siguientes resultados.
Toda la lista de validacin se encontraba con la casilla si seleccionada

para todos los puntos a verificar. Lo que indica que la gua se sigui
correctamente, logrando los resultados esperados.
La gua metodolgica se logr seguir paso a paso de manera secuencial
sin tener que retroceder a pasos anteriores, lo que da a entender, que la
gua se encuentra correctamente estructurada y entendible.
Se encontr que la instalacin del software requerido para los sistemas
UNIX Like se encuentra ligada en lo mximo posible al proceso de
instalacin estndar del software libre.
Mediante una captura en un analizador de trfico, se logr observar que
los mensajes que viajan por la red se encuentran cifrados, lo que
permite garantizar un nivel de seguridad considerable en el transporte de
los registros de eventos.
La gua metodolgica permite centralizar los registros de eventos en una
organizacin de forma transparente para los usuarios finales, pues los
servicios inician automticamente una vez inicie el sistema operativo.
Se observa, que despus de seguir la gua metodolgica, se logra
centralizar los registros de eventos de seguridad de los dispositivos
presentes en la red. Siendo la gua metodolgica til para el proceso de
gestin de registros de eventos.
54. CONCLUSIONES
Durante el tiempo de desarrollo del trabajo se logr definir y validar una gua
metodolgica para la gestin centralizada de registros de eventos de seguridad
de red, la cual puede ser utilizada en organizaciones de pequea y mediana
escala.
La definicin de la gua metodolgica se consigui por medio de la apropiacin
de la teora asociada a la gestin y centralizacin de eventos de seguridad, de
donde se obtuvieron los requerimientos que deba satisfacer la gua. Con base
a estos requerimientos, se defini la infraestructura para la gestin centralizada
que los satisficiera. Finalmente, se lleg a la implantacin de la infraestructura,
definiendo as la gua metodolgica, la cual fue validada en un ambiente de
pruebas.
Durante el desarrollo del trabajo, se obtuvieron las conclusiones y resultados
que se describen a continuacin:
La centralizacin de registros de eventos de seguridad es un tema

actualmente muy inquietante en el mbito de la seguridad informtica y de
la auditoria, pues facilita la gestin de los registros de eventos de seguridad
en las compaas, ahorrando costos de tiempo y esfuerzo de los
administradores de la red.
Aunque se tiene conocimiento de guas o procedimientos para la
centralizacin de registros de eventos, no se conoce ninguna que cumpla
con las caractersticas de seguridad requeridas para conservar el carcter
de evidencia digital de los registros de eventos de seguridad y que
contemple al tiempo sistemas operativos diferentes.
Existen herramientas tecnolgicas que permiten la centralizacin de
registros de eventos de seguridad, sin embargo son de precios demasiado
elevados, y generalmente no se encuentran al alcance de una compaa de
pequea o mediana escala, por lo que la gua metodolgica desarrollada es
de un aporte altamente valioso para las pymes.
El conocimiento en cuanto a la tecnologa obtenida en las pymes y al nivel
de seguridad informtica que se tiene en las compaas de escala pequea
y mediana en Colombia, es demasiado limitado. Las entidades que tienen
como objetivo estudiar y apoyar a las pymes, no tienen estudios pblicos en
el tema.
En la definicin de los requerimientos que debera satisfacer la gua
metodolgica, se encuentra que dos de ellos se contradicen entre s. Al
tratar de reducir los registros de eventos por medio de la compresin,
borrado o filtrado no se estara cumpliendo con el principio de suficiencia o
completitud de los datos para la evidencia digital.
Durante la etapa de estructuracin de la gua metodolgica, se encontr la
dificultad recolectar los registros de eventos generados por herramientas
diseadas en Windows, ya que no se rigen ningn estndar tal como lo

hacen las herramientas para UNIX con syslog.
Al realizar el anlisis de la informacin de la seguridad informtica en las
pequeas y mediana empresas, se encontr que es un tipo de informacin
muy resguardado lo cual es considerado correcto, pues de esta manera se
evitan ataques de ingeniera social
Con el proceso de validacin de la gua se encontr que la gua
metodolgica es una herramienta que lleva al administrador de la red a
realizar de forma segura la centralizacin de los registros de eventos de
seguridad, cumpliendo con los requerimientos definidos.
55. TRABAJOS FUTUROS

A partir del trabajo realizado se deduce que estndares como syslog necesitan
ser actualizados agregndoles aspectos de seguridad directamente en el
estandar. Asi como definir estndares en necesario que los dispositivos y las
herramientas incluyan en su diseo la implementacin de estos estndares,
para su integracin en infraestructuras como esta.
Un trabajo futuro propuesto es el desarrollo de una gua que implemente
tambin con herramientas de software libre como OSSIM el proceso de analisis
y correlacin de los eventos centralizados.
Tambin se sugiere la implementacin de la gua en un ambiente real y asi
concretar las utilidades de la misma.
Para complementar el software utilizado en este trabajo, se pueden desarrollar
agentes que permitan reportar los eventos de herramientas que por defecto no
soportan el envio de mensajes, para que se integren a la infraestructura.
56. BIBLIOGRAFIA
TORRES, Juan Carlos. RONDN, Richard Garca.
Administracin
E
Integridad
Logs. http://www.criptored.upm.es/guiateoria/gt_m248h.htm
[1]
Control,
De
LONVICK, C., The BSD Syslog Protocol, RFC 3164, August 2001.
http://www.ietf.org/rfc/rfc3164.txt
[2]
MOCKAPETRIS, P., "Domain Names - Concepts and Facilities", STD 13,

RFC 1034, November 1987
[3]
[4]
PITT DONALD,Log Consolidation with
http://www.giac.org/practical/gsec/Donald_Pitts_GSEC.pdf
syslog. December 23, 2000
NAWYN, Kenneth E. A Security Analysis of System Event Logging with

Syslog. SANS Institute 2003. www.sans.org/rr/whitepapers/logging/1101.php
[5]
[6]
IETF RFC 3080, http://www.ietf.org/rfc/rfc3080.txt.
BOTERO, Nicols. Modelo de Gestin de Seguridad con Soportes a

SNMP. Pontificia Universidad Javeriana, Junio de 2005.
[7]
FLOREZ, Diego Andrs Londoo, Leonardo Eduardo. Monitoreo y

Control de Componentes de Red, Sobre Protocolo SNMP. Pontificia
Universidad Javeriana, Octubre de 2005.
[8]
[9]
CRESPO, Joaquin, Correlacin de eventos de seguridad,
www.germinus.com/sala_prensa/articulos/Correlacion%20Eventos%20Seguridad.pdf
2004.
CALDWELL, Matthew. The Importance of Event Correlation for Effective

Security Management, ISACA, 2002. http://www.isaca.org/
[10]
TIFFANY, Michael A Survey of Event Correlation Techniques, 2002.

http://www.tiffman.com/netman/netman.pdf
[11]
CHUVAKYN, Anton Event Correlation

http://www.securitydocs.com/library/2270
[12]
in
Security,
2004.
LIU, G - Mok,A.K.- Yang, E.J. Composite Events for Network Event

Correlation, The University of Texas at Austin, 1999.
[13]
NOBLETT, Michael G. POLLITT, Mark M. PRESLEY, Lawrence A.

Recovering and Examining Computer Forensic Evidence. OCTOBER 2000.
http://www.fbi.gov/hq/lab/fsc/backissu/oct2000/computer.htm
[14]
CARRIER, Brian. Defining Digital Forensic Examination and analysis

Tools.
Agosto
7
de
2002.
http://www.dfrws.org/2002/papers/Papers/Brian_carrier.p
[15]
CASEY, Eoghan. Digital Evidence and Computer Crime: Forensic

Science, Computers, and the Internet. 2004
[16]
[17]
FARNER, Dan. Forensic Discovery. 2006.
Cano Jeimy, Mosquera Gonzlez Jos Alejandro, Certain Jaramillo

Andrs Felipe.
Evidencia Digital: contexto, situacin e implicaciones
nacionales.
Abril
de
2005.
http://derecho.uniandes.edu.co/derecho1/export/derecho/descargas/texto/NasT
ecnologias6.pdf
[18]
Cano Martines Jeimy Jos. Admisibilidad de la Evidencia Digital: Algunos

Elementos de Revisin y Anlisis. Agosto de 2003. http://www.alfa-redi.org/rdiarticulo.shtml?x=1304
[19]
Ley 446 de Julio de 1998, http://www.sic.gov.co/Normatividad/Leyes/Ley

%20446-98.php
[20]
CANO, Jeimmy J. Buenas Prcticas en la Administracin de la

evidencia digital. 2006
[21]
SERRANO G, Maria Isabel. Fundamentos de Criptografa.

http://ainsuca.javeriana.edu.co/seginfor/. Consultado Abril de 2006.
[22]
GMEZ,
Nelson.
Soluciones
de
seguridad.
http://ainsuca.javeriana.edu.co/seginfor/. Septiembre de 2005. Consultado Abril
de 2006.
[23]
Noel, Clasificacin y tipos de ataques contra sistemas de informacin,

http://ww.delitosinformaticos.com
[24]
GARZN, Daniel. RATKOVICH, Juan Carlos. VERGARA, Alejandro.

Metodologa de anlisis y vulnerabilidades para empresas de media y pequea
escala en la ciudad de Bogot. Febrero de 2005.
[25]
McDowell,
Mindi.
Understanding
http://www.us-cert.gov/cas/tips/ST04-015.html
[26]
Denial-of-Service
RAFAIL,
Jason.
Cross-Site
Scripting
http://www.cert.org/archive/pdf/cross_site_scripting.pdf
Attacks .
[27]
Vulnerabilities.
[28]
SERRANO, Maria Isabel. Seguridad en redes y Tcnicas Hacking.
2005.
Seguridad en la red: identificacin de permetros de red SMB, Centro

de Informacin y Recursos para PyMEs, Microsoft Colombia.
http://www.microsoft.com/colombia/pymes/issues/sgc/articles/sec_net_smb_per
_dev.mspx. Consultado: julio 27 de 2006.
[29]
Microsoft Active Directory, An Overview. Presentacin en Power Point.

Windows Experts. www.windows-expert.net . Consultado Julio 31 de 2006
[30]
Netcarft.
Web
Server
Survey
Archives.
Netcraft.
http://news.netcraft.com/archives/web_server_survey.html. Consultado Agosto
8 de 2006
[31]
Firewall/VPN, una solucin a muchos problemas. iWorld IDG Espaa.

http://www.idg.es/iworld/articulo.asp?id=145203. Enero 1 de 2003. Consultado:
Agosto 9 de 2006
[32]
Mail
Server
Survey
April
2004.
FalkoTimme.com.
http://www.falkotimme.com/projects/survey_smtp.php?id=170 .
Consultado
Agosto 14 de 2006.
[33]
Guide to Computer Security Log Management (Borrador). NIST

(Nacional Institute of Standards and Technology). Abril de 2006.
[34]
Bruegge, Bernd. Dutoit, Alen H. Ingeniera de Software orientado a

Objetos. 2002. Pirson Education.
[35]
BABBIN, Jacob. Security Log Management. Identifying Pattenrs In The

Chaos. Syngress Publishing, Inc. 2006
[36]
ArCert. Instalacin y configuracin

Agosto de 2006
[37]
de NTP. http://www.arcert.gov.ar.
AKIN Thomas. Hardening Cisco Routers. Febrero

http://www.oreilly.com/catalog/hardcisco/chapter/ch10.html
[38]
[39]
[40]
[41]
SSH Communications Security. http://www.ssh.com/
de
2002.
BARRELT, Daniel J. SILVERMAN, Richard. BYRNES, Robret G. SSH.

The Secure Shell The Definitive Guide. OReily. 2005.
[42]
[43]
IETF RFC 739, http://www.free.lp.se/fish/rfc.txt
[44]
Open SSH. Noviembre de 2006. http://www.openssh.com/
[45]
Balabit IT Security. 2006. http://www.balabit.com/products/syslog_ng/
[46]
http://www.chiark.greenend.org.uk/~sgtatham/putty
[47]
Source Fore .net. 2007. http://sourceforge.net/projects/lassolog
[48]
The Network Time Protocol project. http://www.ntp.org/
57. ANEXOS
ANEXO 1: Remtase al documento Gua Metodolgica para la Gestin
Centralizada de registros de eventos de seguridad en Pymes

Documento

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Documento

Cargado por

Copyright:

Formatos disponibles

GUA METODOLGICA PARA LA GESTIN CENTRALIZADA DE REGISTRO

DE EVENTOS DE SEGURIDAD EN PYMES

DIANA CAROLINA NIO MEJA

PONTIFICIA UNIVERSIDAD JAVERIANA

GUA METODOLGICA PARA LA GESTIN CENTRALIZADA DE REGISTRO

DIANA CAROLINA NIO MEJA

Trabajo de Grado presentado para optar el ttulo de Ingeniero de Sistemas

PONTIFICIA UNIVERSIDAD JAVERIANA

PONTIFICIA UNIVERSIDAD JAVERIANA

Rector Magnfico: Padre Gerardo Remolina Vargas S.J.

Decano Acadmico Facultad de Ingeniera: Ingeniero Francisco Javier

Decano del Medio Universitario Facultad de Ingeniera: Padre Antonio Jos

Director Carrera de Ingeniera de Sistemas: Ingeniera Hilda Cristina Chaparro

Director Departamento de Ingeniera de Sistemas: Ingeniero Germn Alberto

Director del Proyecto

Artculo 23 de la Resolucin No. 1 de Junio de 1946

1.1. DESCRIPCIN EL PROBLEMA

2.1. METODOS DE TRANSPORTE

3.1. RED TIPICA DE UNA PYME.

3.2.1. REQUERIMIENTOS FUNCIONALES

4.1. CARACTERSTICAS DEL CASO DE PRUEBA.

se busca a travs del seguimiento de las siguientes

Apropiacin del conocimiento asociado a la gestin de seguridad, registros

Al centralizar los registros de eventos de seguridad, es probable que el trfico

Un mensaje syslog cuenta con tres campos descritos a continuacin:

Tabla 1. Facilidades y su cdigo numrico respectivo

Nota 1. Se han encontrado algunos sistemas operativos que utilizan las

Cada Prioridad de mensaje tiene un indicador de Severidad decimal. Estas

Tabla 2.Severidades y su cdigo numrico respectivo

El valor de la Prioridad se calcula multiplicando el valor de la Facilidad por 8

HEADER (Cabecera): La cabecera contiene dos campos: TIEMSTAMP y

MSG. El mensaje o MSG tiene 2 campos. TAG (Etiqueta) y CONTENT. El

evento. El TAG no debe exceder a 32 caracteres. El otro campo CONTENT

El programa syslog provee una plataforma estandarizada, bajo la cual

Nsyslog. Nsyslog es una herramienta desarrollada por Darren Reed la cual

Stealthful Loggin. Para un proyecto de Honeypot, es clave recolectar los

Comparacin de evoluciones de syslog

Debido a que syslog es un protocolo que permite el transporte de los logs,

SNMP se compone de tres partes [7]:

atributos del sistema, atributos privados, atributos experimentales y

En este protocolo existen 6 comandos u operaciones bsicas: GetRequest,

La estructura del mensaje SNMP cuando se utiliza un comando trap se define

Figura 1. Estructura de mensajes SNMP

Time-stamp: Indica el tiempo que transcurri entre la ultima vez que se

SNMP v.3 se define como la adicin de seguridad y administracin a SNMP v.2.

Sin embargo, an no previene ataques como denegacin de servicios y sniffer.

9. CORRELACION DE REGISTROS DE EVENTOS DE

La consolidacin de los datos consiste en el transporte de los eventos

La normalizacin de los datos consiste en cambiar el formato de los

Reduccin de los datos. Esto se puede realizar comprimindolos,

Teniendo en cuenta que uno de los aspectos ms importantes de un registro de

estos esta embebida en la implementacin del mismo. Los eventos compuestos

0 (e,1) no ha ocurrido en el tiempo t

AttrVale: Permite acceder al valor del atributo attr de la instancia del

AttrValuer : Permite acceder al valor del atributo attr de la instancia

@ y @r: Un atributo comn de todos los eventos es el tiempo de

Si se considera el tiempo t dentro de valores no negativos.

@f y @fr: Mediante esta funcin se puede definir un subconjunto de

Especificacin de Eventos Primitivos y Compuestos

Correlacin basada en reglas

ste tipo de correlacin consiste en identificar ciertos incidentes y su

Esta correlacin no emplea ningn conocimiento preexistente de incidentes

Correlacin con sistemas de inteligencia Artificial