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

PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS BOGOTA D.C., ENERO 2007

PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS

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
2.INTRODUCCION.................................................................................................................12 3.DESCRIPCIN EL PROBLEMA.........................................................................................12 4.OBJETIVOS DE LA INVESTIGACIN.............................................................................12 5.ALCANCE DE LA INVESTIGACIN................................................................................13 6.MARCO TERICO..............................................................................................................15 7.METODOS DE TRANSPORTE............................................................................................15 8.SYSLOG........................................................................................................................................15 9.SNMP........................................................................................................................................20 10.CORRELACION DE REGISTROS DE EVENTOS DE SEGURIDAD..........................23 11.REQUISITOS PARA LA CORRELACIN.................................................................................................23 12.EVENTOS, INCIDENTES Y EVENTOS COMPUESTOS..............................................................................23 13.TIPOS DE CORRELACIN................................................................................................................25 14.COMPUTACIN FORENSE Y EVIDENCIA DIGITAL................................................27 15.COMPUTACIN FORENSE...............................................................................................................27 16.EVIDENCIA DIGITAL......................................................................................................................27 17.PROTECCIN DE INFORMACIN Y HERRAMIENTAS DE SEGURIDAD...........31 18.SEGURIDAD FSICA .......................................................................................................................31 19.SEGURIDAD LGICA......................................................................................................................32 20.PROTECCIN................................................................................................................................32 21.INVERSIN .................................................................................................................................35 22.CLASIFICACIN Y TIPOS DE ATAQUES INFORMTICOS....................................36 23.VULNERABILIDAD.........................................................................................................................36 24.AMENAZAS Y ATAQUES.................................................................................................................37 25.SINCRONIZACION DE RELOJES DE TIEMPO ...........................................................39 26.ARQUITECTURA DEL SISTEMA.........................................................................................................40 27.SSH..........................................................................................................................................41 28.ARQUITECTURA DE SSH...............................................................................................................41 29.CARACTERSTICAS DE SSH...........................................................................................................43 30.USOS COMUNES DE SSH...............................................................................................................44 31.DESARROLLO DEL PROYECTO...................................................................................45 32.RED TIPICA DE UNA PYME.............................................................................................46 33.TAMAO DE UNA PYME................................................................................................................46 34.CARACTERSTICAS DE UNA RED TPICA DE UNA PYME.......................................................................47 35.REQUERIMIENTOS PARA LA GESTION CENTRALIZADA DE LOS REGISTROS DE EVENTOS DE SEGURIDAD.............................................................................................49 36.REQUERIMIENTOS FUNCIONALES......................................................................................................49 37.REQUERIMIENTOS NO FUNCIONALES.................................................................................................50 38.DIAGRAMA DE RED TPICA DE UNA PYME........................................................................................50 39.DEFINICIN DE INFRAESTRUCTURA.........................................................................52

40.DEFINICIN DEL MTODO DE SINCRONIZACIN DE RELOJES DE TIEMPO...................................................52 41.DEFINICIN DEL MTODO DE TRANSPORTE........................................................................................52 42.DEFINICIN DE HERRAMIENTAS DE USO EN LA GUA METODOLGICA.....................................................54 43.MODELO DE LA INFRAESTRUCTURA PARA LA CENTRALIZACIN DE REGISTROS DE EVENTOS DE SEGURIDAD...55 44.MTODOS UTILIZADOS PARA LA SATISFACCIN DE LOS REQUERIMIENTOS DE LA GUA METODOLGICA........57 45.ESTRUCTURA DE LA GUA METODOLGICA..........................................................59 46.DIAGRAMA DE FLUJO DE LA GUA METODOLGICA.............................................................................59 47.ORDEN SECUENCIAL DE PASOS PARA LA CONFIGURACIN DE LA CENTRALIZACIN................................63 48.CENTRALIZACIN DE REGISTROS DE EVENTOS DE HERRAMIENTAS UTILIZADAS EN PYMES...........................67 49.DEPENDENCIA DE LOS SERVICIOS.....................................................................................................68 50.VALIDACIN DE LA GUA METODOLGICA..........................................................70 51.CARACTERSTICAS DEL CASO DE PRUEBA.............................................................70 52.DIAGRAMA DE RED DEL CASO DE PRUEBA...................................................................................71 53.DEFINICIN DE LOS RESULTADOS ESPERADOS...................................................................................71 54.OBSERVACIONES Y RESULTADOS OBTENIDOS..................................................................73 55.CONCLUSIONES...............................................................................................................74 56.TRABAJOS FUTUROS......................................................................................................76 57.BIBLIOGRAFIA.................................................................................................................77 58.ANEXOS..............................................................................................................................81

1.

LISTA DE TABLAS
TABLA 1. FACILIDADES Y SU CDIGO NUMRICO RESPECTIVO.........................16 TABLA 2.SEVERIDADES Y SU CDIGO NUMRICO RESPECTIVO.........................17 TABLA 3. CARACTERSTICA DE LOS MTODOS DE TRANSPORTE.......................53 TABLA 4. EQUIPOS DE LA RED DEL CASO DE PRUEBA.............................................70 TABLA 5. LISTA DE VALIDACIN PARA LA GUIA METODOLGICA....................72

LISTA DE FIGURAS

FIGURA 1. ESTRUCTURA DE MENSAJES SNMP...........................................................21 FIGURA 2. INTERRUPCIN [28].........................................................................................37 FIGURA 3. INTERCEPCIN [28].........................................................................................38 FIGURA 4. MODIFICACIN [28]........................................................................................38 FIGURA 5. FABRICACIN [28]...........................................................................................39 FIGURA 6. ESQUEMA JERRQUICO DE NTP. [37]........................................................40 FIGURA 7. ESQUEMA DE DISTRIBUCIN DE SSH........................................................42 FIGURA 8.RED TPICA DE UNA PYME DEFINIDA POR MICROSOFT. [29].............47 FIGURA 9. DIAGRAMA DE UNA RED TPICA DE UNA PYME....................................51 FIGURA 10. ESQUEMA DE CENTRALIZACIN DE LOGS...........................................56 FIGURA 11. DIAGRAMA DE FLUJO DE LA GUA METODOLGICA.......................60 FIGURA 12. DIAGRAMA DE FLUJO PARA LA CONFIGURACIN DEL SERVIDOR...............................................................................................................................63 FIGURA 13. DIAGRAMA DE FLUJO PARA LA CONFIGURACIN DE LOS CLIENTES UNIX LIKE..........................................................................................................64 FIGURA 14. DIAGRAMA DE FLUJO PARA LA CONFIGURACIN DE LOS CLIENTES WINDOWS..........................................................................................................65 FIGURA 15. DIAGRAMA DE FLUJO PARA LA CONFIGURACIN DE LOS CLIENTES DISPOSITIVOS DE RED...................................................................................66 FIGURA 16. DIAGRAMA DE FLUJO PARA LA CONFIGURACIN DE LOS CLIENTES UNIX LIKE, RECEPTORES DE LOGS DE LOS DISPOSITIVOS DE RED. ...................................................................................................................................................67 FIGURA 17. DIAGRAMA DE DEPENDENCIAS DE LOS SERVICIOS..........................68

FIGURA 18. ESQUEMA DE RED DEL CASO DE PRUEBA.............................................71

2. INTRODUCCION
3. 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.

4. 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 infraestructura definida. de la

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.

5. 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.

6. 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.

7. 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. 8. 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. 8.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 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Facilidad 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 syslogd Subsistema de impresora en lnea Subsistema de noticias de red

por

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] 8.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. 8.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]

8.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. 9. 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. 9.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. 9.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.

9.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 PDU

Trap Timeespecfico stamp

Campos variables

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. 9.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.

10.

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] 11. 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. 12. 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, " OcurrenceTime" , 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 ) 12.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; 13. 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

13.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] 13.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]

13.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.

14.

COMPUTACIN FORENSE Y EVIDENCIA DIGITAL

15. 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. 16. 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. Clasificacin de la evidencia digital

16.1.1.1.

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). 16.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. 16.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. centralizacin de registros de eventos dentro del ciclo de vida de la evidencia digital.

16.1.1.4.

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: 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.

17.

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. 18. 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. 19. 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.

20. 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. 20.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. 20.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.

20.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. 20.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. 20.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. 20.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. 20.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. 20.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. 21. 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.

22.

CLASIFICACIN Y TIPOS DE ATAQUES INFORMTICOS

23. 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. 23.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.

24. 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. 24.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

Receptor

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

Receptor

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 Figura 5. Fabricacin [28] 24.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.

25.

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]

26. 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

27.

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. 28. 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.

29. Caractersticas de SSH. SSH tiene algunas caractersticas, descritas a continuacin, que proveen un nivel de seguridad alto, y protegen la comunicacin entre cliente-servidor. 29.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). 29.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. 29.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.

29.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.

29.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. 30. 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.

31. 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

32.

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. 33. 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. 34. Caractersticas de una red tpica de una PyME 34.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 34.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

35.

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] 36. 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.

37. 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.

38. 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 38.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)

39.

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. 40. 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. 41. 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).

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 a

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.

42. 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. 42.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] 42.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]

42.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. 42.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. 43. 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. 44. 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. 44.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. 44.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.

45.

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. 46. 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. 46.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.

46.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. 46.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. 46.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. 46.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. 46.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.

47. Orden secuencial de pasos para la configuracin centralizacin.

de la

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. 47.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

47.1.1.2.

Secuencia de pasos en la configuracin clientes UNIX LIKE

de los

La Figura 12 muestra el diagrama de flujo que describe la secuencia de pasos a seguir para la configuracin de los clientes con sistema operativo UNIX LIKE.

Figura 13. Diagrama de Flujo para la configuracin

de los clientes UNIX LIKE

47.1.1.3.

Secuencia de pasos en la configuracin clientes WINDOWS

de los

La Figura 13 muestra el diagrama de flujo que describe la secuencia de pasos a seguir para la configuracin de los clientes WINDOWS.

Figura 14. Diagrama de Flujo para la configuracin

de los clientes WINDOWS

47.1.1.4.

Secuencia de pasos en la configuracin 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.

Figura 15. Diagrama de Flujo para la configuracin 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] 48. 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. 49. 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].

50. 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.

51.

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 Funcin en la red Servidor logs Host Elemento del modelo de centralizacin de Servidor de logs Cliente Windows

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 Windows XP Red Hat Linux Red Hat Linux Cisco Software v.12,4

Equipo de Receptor de logs gestin de logs de dispositivo de red. Host Cliente Windows Host Firewall Cliente UNIX Like Cliente UNIX Like Cliente dispositivo de red

IOS Enrutador 1841

Tabla 4. Equipos de la red del caso de prueba

52. 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

53.

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

si

no

N/A

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

54.

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.

55. 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.

56. 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.

57. BIBLIOGRAFIA
[1] TORRES, Juan Carlos. RONDN, Richard Garca. Administracin E Integridad Logs. http://www.criptored.upm.es/guiateoria/gt_m248h.htm Control, De

[2] LONVICK, C., The BSD Syslog Protocol, RFC 3164, August 2001. http://www.ietf.org/rfc/rfc3164.txt [3] MOCKAPETRIS, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987 [4] PITT DONALD,Log Consolidation with syslog. December 23, 2000
http://www.giac.org/practical/gsec/Donald_Pitts_GSEC.pdf

[5] NAWYN, Kenneth E. A Security Analysis of System Event Logging with Syslog. SANS Institute 2003. www.sans.org/rr/whitepapers/logging/1101.php [6] IETF RFC 3080, http://www.ietf.org/rfc/rfc3080.txt.

[7] BOTERO, Nicols. Modelo de Gestin de Seguridad con Soportes a SNMP. Pontificia Universidad Javeriana, Junio de 2005. [8] FLOREZ, Diego Andrs Londoo, Leonardo Eduardo. Monitoreo y Control de Componentes de Red, Sobre Protocolo SNMP. Pontificia Universidad Javeriana, Octubre de 2005. [9] CRESPO, Joaquin, Correlacin de eventos de seguridad, 2004.
www.germinus.com/sala_prensa/articulos/Correlacion%20Eventos%20Seguridad.pdf

[10] CALDWELL, Matthew. The Importance of Event Correlation for Effective Security Management, ISACA, 2002. http://www.isaca.org/ [11] TIFFANY, Michael A Survey of Event Correlation Techniques, 2002. http://www.tiffman.com/netman/netman.pdf [12] CHUVAKYN, Anton Event Correlation http://www.securitydocs.com/library/2270 in Security, 2004.

[13] LIU, G - Mok,A.K.- Yang, E.J. Composite Events for Network Event Correlation, The University of Texas at Austin, 1999. [14] 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

[15] CARRIER, Brian. Defining Digital Forensic Examination and analysis Tools. Agosto 7 de 2002. http://www.dfrws.org/2002/papers/Papers/Brian_carrier.p [16] CASEY, Eoghan. Digital Evidence and Computer Crime: Forensic Science, Computers, and the Internet. 2004 [17] FARNER, Dan. Forensic Discovery. 2006.

[18] 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 [19] Cano Martines Jeimy Jos. Admisibilidad de la Evidencia Digital: Algunos Elementos de Revisin y Anlisis. Agosto de 2003. http://www.alfaredi.org/rdi-articulo.shtml?x=1304 [20] Ley 446 de Julio de 1998, http://www.sic.gov.co/Normatividad/Leyes/Ley %20446-98.php [21] CANO, Jeimmy J. Buenas Prcticas en la Administracin de la evidencia digital. 2006 [22] SERRANO G, Maria Isabel. Fundamentos de Criptografa. http://ainsuca.javeriana.edu.co/seginfor/. Consultado Abril de 2006. [23] GMEZ, Nelson. Soluciones de seguridad. http://ainsuca.javeriana.edu.co/seginfor/. Septiembre de 2005. Consultado Abril de 2006. [24] Noel, Clasificacin y tipos de ataques contra sistemas de informacin, http://ww.delitosinformaticos.com [25] 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. [26] McDowell, Mindi. Understanding http://www.us-cert.gov/cas/tips/ST04-015.html Denial-of-Service Attacks.

[27] RAFAIL, Jason. Cross-Site Scripting http://www.cert.org/archive/pdf/cross_site_scripting.pdf

Vulnerabilities.

[28] SERRANO, Maria Isabel. Seguridad en redes y Tcnicas Hacking. 2005.

[29] 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. [30] Microsoft Active Directory, An Overview. Presentacin en Power Point. Windows Experts. www.windows-expert.net . Consultado Julio 31 de 2006 [31] Netcarft. Web Server Survey Archives. Netcraft. http://news.netcraft.com/archives/web_server_survey.html. Consultado Agosto 8 de 2006 [32] 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 [33] Mail Server Survey April 2004. FalkoTimme.com. http://www.falkotimme.com/projects/survey_smtp.php?id=170 . Consultado Agosto 14 de 2006. [34] Guide to Computer Security Log Management (Borrador). NIST (Nacional Institute of Standards and Technology). Abril de 2006. [35] Bruegge, Bernd. Dutoit, Alen H. Ingeniera de Software orientado a Objetos. 2002. Pirson Education. [36] BABBIN, Jacob. Security Log Management. Identifying Pattenrs In The Chaos. Syngress Publishing, Inc. 2006 [37] ArCert. Instalacin y configuracin Agosto de 2006 de NTP. http://www.arcert.gov.ar. de 2002.

[38] AKIN Thomas. Hardening Cisco Routers. Febrero http://www.oreilly.com/catalog/hardcisco/chapter/ch10.html [39] [40] [41] IETF RFC 1305, http://www.ietf.org/rfc/rfc1305.txt. IETF RFC 2030, http://www.ietf.org/rfc/rfc2030.txt. SSH Communications Security. http://www.ssh.com/

[42] BARRELT, Daniel J. SILVERMAN, Richard. BYRNES, Robret G. SSH. The Secure Shell The Definitive Guide. OReily. 2005. [43] [44] IETF RFC 739, http://www.free.lp.se/fish/rfc.txt Open SSH. Noviembre de 2006. http://www.openssh.com/

[45] [46] [47] [48]

Balabit IT Security. 2006. http://www.balabit.com/products/syslog_ng/ http://www.chiark.greenend.org.uk/~sgtatham/putty Source Fore .net. 2007. http://sourceforge.net/projects/lassolog The Network Time Protocol project. http://www.ntp.org/

58. ANEXOS
ANEXO 1: Remtase al documento Gua Metodolgica para la Gestin Centralizada de registros de eventos de seguridad en Pymes