GUÍA METODOLÓGICA PARA LA GESTIÓN CENTRALIZADA DE REGISTRO DE EVENTOS DE SEGURIDAD EN PYMES

DIANA CAROLINA NIÑO MEJÍA ALEJANDRO SIERRA MUNERA

PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SISTEMAS BOGOTA D.C., ENERO 2007

GUÍA METODOLÓGICA PARA LA GESTIÓN CENTRALIZADA DE REGISTRO DE EVENTOS DE SEGURIDAD EN PYMES

DIANA CAROLINA NIÑO MEJÍA ALEJANDRO SIERRA MUNERA

Trabajo de Grado presentado para optar el título 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 Magnífico: Padre Gerardo Remolina Vargas S.J.

Decano Académico Facultad de Ingeniería: Ingeniero Francisco Javier Rebolledo Múñoz

Decano del Medio Universitario Facultad de Ingeniería: Padre Antonio José Sarmiento Nova S.J.

Director Carrera de Ingeniería de Sistemas: Ingeniera Hilda Cristina Chaparro

López

Director Departamento de Ingeniería de Sistemas: Ingeniero Germán Alberto Chavarro Flórez

Nota de Aceptación ______________________________________________________

______________________________________________________

______________________________________________________

______________________________________________________

______________________________________________________

______________________________________________________

________________________________________ Director del Proyecto

________________________________________

Jurado

_________________________________

Jurado

Enero 2007

Artículo 23 de la Resolución No. 1 de Junio de 1946 “La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que se vean en ellos el anhelo de buscar la verdad y la Justicia”

TABLA DE CONTENIDO

1. INTRODUCCION 10

1.1. DESCRIPCIÓN EL PROBLEMA 10 1.2. OBJETIVOS DE LA INVESTIGACIÓN 10 1.3. ALCANCE DE LA INVESTIGACIÓN 11

2. MARCO TEÓRICO 13

2.1. METODOS DE TRANSPORTE 13 2.1.1. SYSLOG 13 2.1.2. SNMP 18 2.2. CORRELACION DE REGISTROS DE EVENTOS DE SEGURIDAD 21 2.2.1. REQUISITOS PARA LA CORRELACIÓN 21 2.2.2. EVENTOS, INCIDENTES Y EVENTOS COMPUESTOS 21 2.2.3. TIPOS DE CORRELACIÓN 23 2.3. COMPUTACIÓN FORENSE Y EVIDENCIA DIGITAL 25 2.3.1. COMPUTACIÓN FORENSE 25 2.3.2. EVIDENCIA DIGITAL 25 2.4. PROTECCIÓN DE INFORMACIÓN Y HERRAMIENTAS DE SEGURIDAD 29 2.4.1. SEGURIDAD FÍSICA 29 2.4.2. SEGURIDAD LÓGICA 30 2.4.3. PROTECCIÓN 30 2.4.4. INVERSIÓN 33 2.5. CLASIFICACIÓN Y TIPOS DE ATAQUES INFORMÁTICOS 34 2.5.1. VULNERABILIDAD 34 2.5.2. AMENAZAS Y ATAQUES 35 2.6. SINCRONIZACION DE RELOJES DE TIEMPO 37 2.6.1. ARQUITECTURA DEL SISTEMA 38 2.7. SSH 39 2.7.1. ARQUITECTURA DE SSH 39 2.7.2. CARACTERÍSTICAS DE SSH. 41 2.7.3. USOS COMUNES DE SSH 42

3. DESARROLLO DEL PROYECTO 43

3.1. RED TIPICA DE UNA PYME. 44 3.1.1. TAMAÑO DE UNA PYME 44 3.1.2. CARACTERÍSTICAS DE UNA RED TÍPICA DE UNA PYME 45 3.2. REQUERIMIENTOS PARA LA GESTION CENTRALIZADA DE LOS REGISTROS DE EVENTOS DE SEGURIDAD 47

3.2.1. REQUERIMIENTOS FUNCIONALES 47 3.2.2. REQUERIMIENTOS NO FUNCIONALES 48 3.2.3. DIAGRAMA DE RED TÍPICA DE UNA PYME. 48 3.3. DEFINICIÓN DE INFRAESTRUCTURA 50 3.3.1. DEFINICIÓN DEL MÉTODO DE SINCRONIZACIÓN DE RELOJES DE TIEMPO. 50 3.3.2. DEFINICIÓN DEL MÉTODO DE TRANSPORTE 50 3.3.3. DEFINICIÓN DE HERRAMIENTAS DE USO EN LA GUÍA METODOLÓGICA. 52 3.3.4. MODELO DE LA INFRAESTRUCTURA PARA LA CENTRALIZACIÓN DE REGISTROS DE EVENTOS DE SEGURIDAD. 53 3.3.5. MÉTODOS UTILIZADOS PARA LA SATISFACCIÓN DE LOS REQUERIMIENTOS DE LA GUÍA METODOLÓGICA. 55 3.4. ESTRUCTURA DE LA GUÍA METODOLÓGICA 57 3.4.1. DIAGRAMA DE FLUJO DE LA GUÍA METODOLÓGICA. 57 3.4.2. ORDEN SECUENCIAL DE PASOS PARA LA CONFIGURACIÓN DE LA CENTRALIZACIÓN. 61 3.4.3. CENTRALIZACIÓN DE REGISTROS DE EVENTOS DE HERRAMIENTAS UTILIZADAS EN PYMES. 65 3.4.4. DEPENDENCIA DE LOS SERVICIOS. 66

4. VALIDACIÓN DE LA GUÍA METODOLÓGICA 68

4.1. CARACTERÍSTICAS DEL CASO DE PRUEBA. 68 4.1.1. DIAGRAMA DE RED DEL CASO DE PRUEBA 69 4.2. DEFINICIÓN DE LOS RESULTADOS ESPERADOS. 69 4.3. OBSERVACIONES Y RESULTADOS OBTENIDOS. 71

5. CONCLUSIONES 72

6. TRABAJOS FUTUROS 74

7. BIBLIOGRAFIA 75

8. ANEXOS 79

LISTA DE TABLAS

Tabla 1. Facilidades y su código numérico respectivo ..................................... 14 Tabla 2.Severidades y su código numérico respectivo .................................... 15 Tabla 3. Característica de los Métodos de transporte...................................... 51 Tabla 4. Equipos de la red del caso de prueba ................................................ 68 tabla 5. Lista de validación para la guia metodológica ..................................... 70

LISTA DE FIGURAS

Figura 1. Estructura de mensajes SNMP ......................................................... 19 Figura 2. Interrupción [28] ................................................................................ 36 Figura 3. Intercepción [28]................................................................................ 36 Figura 4. Modificación [28] ............................................................................... 36 Figura 5. Fabricación [28]................................................................................. 37 Figura 6. Esquema jerárquico de NTP. [37] ..................................................... 38 Figura 7. Esquema de distribución de SSH...................................................... 40 Figura 8.Red Típica de una pyme definida por Microsoft. [29] ......................... 45 Figura 9. Diagrama de una Red típica de una pyme........................................ 49 Figura 10. Esquema de centralización de logs................................................. 54 Figura 11. Diagrama de flujo de la guía metodológica. .................................... 58 Figura 12. Diagrama de Flujo para la configuración del servidor .................. 61 Figura 13. Diagrama de Flujo para la configuración de los clientes UNIX LIKE......................................................................................................................... 62 Figura 14. Diagrama de Flujo para la configuración de los clientes WINDOWS......................................................................................................................... 63 Figura 15. Diagrama de Flujo para la configuración de los clientes dispositivos de red. .............................................................................................................. 64 Figura 16. Diagrama de Flujo para la configuración de los clientes UNIX LIKE, receptores de logs de los dispositivos de red................................................... 65 Figura 17. Diagrama de Dependencias de los Servicios.................................. 66 Figura 18. Esquema de Red del caso de prueba ............................................. 69

10

1. INTRODUCCION

1.1. DESCRIPCIÓN EL PROBLEMA

En la actualidad, las pequeñas y medianas empresas (Pymes) cuentan con herramientas y equipos informáticos los cuales, en su mayoría, generan registros de eventos de seguridad. Los logs son un conjunto de eventos que se almacenan en los dispositivos donde son generados, y contienen información 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 manipulación no autorizada de información. Sin embargo, no es suficiente analizar la información de cada dispositivo por separado, ya que en algunos casos, puede existir una relación directa entre eventos sucedidos en distintos equipos. La revisión de los logs y análisis de la información contenida en éstos se vuelve una tarea bastante compleja y tediosa cuando se genera un sin límite de logs en la compañía diariamente. Una solución a éste problema es mantener almacenados los logs en un solo equipo, y desde este hacer la revisión de todos los logs de la pyme. Existen algunas herramientas de software que permiten realizar la centralización 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 código libre o guías 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 guía metodológica que permita a las pymes gestionar de manera centralizada los registros de eventos de seguridad.

1.2. OBJETIVOS DE LA INVESTIGACIÓN

El principal objetivo de éste trabajo de investigación es definir y validar una guía metodológica para la gestión centralizada de registros de eventos de seguridad de red, para que pueda ser utilizada en organizaciones de pequeña y mediana escala. Para cumplir con éste objetivo, se intenta dar respuesta a la pregunta ¿Cómo centralizar registros de eventos de seguridad en pymes conservando su carácter de evidencia digital a nivel probatorio y cumpliendo los requicitos para hacer una futura correlación?. La solución

11

a este interrogante, se busca a través del seguimiento de las siguientes actividades: • Apropiación del conocimiento asociado a la gestión de seguridad, registros

de eventos y computación forense. • Análisis y definición de requerimientos para la gestión centralizada de

registros eventos de seguridad. • Definición de la infraestructura de software y hardware para la gestión

centralizada de registros de eventos de seguridad que soporte los requerimientos definidos anteriormente.

• Definición de una guía metodológica para la implantación de la

infraestructura definida. • Validación de la guía metodológica mediante la definición e implementación

de un caso de prueba que se ajuste a las características de la red de una pyme.

1.3. ALCANCE DE LA INVESTIGACIÓN

El proyecto de investigación busca la elaboración de una guía metodológica para la gestión centralizada de registros de eventos de seguridad para pequeñas y medianas empresas, la cual debe ser apoyada en herramientas de libre distribución o que se encuentren al alcance de una pyme. Para la elaboración de la guía se pretende hacer uso de herramientas ya existentes, que cumplan con alguno(s) de los requerimientos necesarios para realizar la centralización de logs manteniendo su carácter de evidencia digital. Con el seguimiento de la guía metodológica 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 guía. No hace parte del trabajo de investigación llevar a la pyme a realizar una correlación de registros de eventos, sin embargo, como continuación del proyecto, queda abierta la posibilidad de implementar un sistema de correlación de logs centralizados. Dentro del objetivo del proyecto, no se encuentra comprendido el desarrollo de software, definición de estándares, definición de políticas ni de procedimientos para la pyme.

12

Al centralizar los registros de eventos de seguridad, es probable que el tráfico de red aumente, no es parte del objetivo del proyecto estudiar o proveer un rendimiento de red óptimo.

13

2. MARCO TEÓRICO

La teoría en la cual fue basada este proyecto de investigación se basa en los conceptos claves para realizar la centralización de logs manteniendo su carácter de evidencia digital. Esto cubre los temas relacionados con los métodos de transporte de logs, correlación de registros de eventos de seguridad, protocolo de sincronización de relojes de tiempo en una red, métodos para asegurar el transporte de logs, computación forense y evidencia digital. También se cubrieron temas relacionados con seguridad informática como los tipos de ataques informáticos y métodos de protección contra estos, con el fin de conocer las herramientas que son usadas comúnmente para la protección y que generan registros de eventos de seguridad que deben ser tenidos en cuenta en el momento de la centralización.

2.1. METODOS DE TRANSPORTE

Existen diferentes métodos que se pueden utilizar a la hora de realizar el transporte de los logs. A continuación se describen algunos de estos.

2.1.1. Syslog

“Syslog es un sistema de logs que se encarga principalmente de la administración 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 común 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 envío de mensajes, como el programa o librería que envía mensajes syslog.

2.1.1.1. Mensaje Syslog

Un mensaje syslog cuenta con tres campos descritos a continuación:

14

• PRI: Este campo debe estar compuesto por 3,4 o 5 caracteres y debe estar rodeado de corchetes angulares.

Comienza con el carácter “<” seguido de un número, el cual precede del carácter “>”. El código 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 número 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 numéricamente con valores decimales. Algunos de los demonios de sistemas operativos y procesos se les han asignado valores de Facilidad. Si a algún proceso o demonio no se le ha asignado explícitamente 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 códigos numéricos:

Código Numérico

Facilidad

0 Mensajes de kernel 1 Mensajes de nivel de usuario 2 Sistema de correo 3 Demonios del sistema 4 Mensaje de seguridad/autorización 5 Mensaje generado internamente por

syslogd 6 Subsistema de impresora en línea 7 Subsistema de noticias de red 8 Subsistema UUCP 9 Demonio de reloj(nota 2)

10 Mensaje de seguridad/autorización(nota 1)

11 Demonio FTP 12 Subsistema NTP 13 Auditoria de eventos (nota 1) 14 Alerta de eventos (nota 2) 15 Demonio de reloj (nota 2) 16 Uso local 0 17 Uso local 1 18 Uso local 2 19 Uso local 3 20 Uso local 4 21 Uso local 5 22 Uso local 6 23 Uso local 7

Tabla 1. Facilidades y su código numérico respectivo Nota 1. Se han encontrado algunos sistemas operativos que utilizan las Facilidades 4, 10, 13 y 14 para seguridad/autorización. Nota 2. Se han encontrado algunos sistemas operativos que utilizan las Facilidades 9 y 15 para mensajes de reloj

15

Cada Prioridad de mensaje tiene un indicador de Severidad decimal. Estas severidades son descritas en la siguiente tabla:

Código Numérico

Severidad

0 Mensajes de kernel 1 Mensajes de nivel de usuario 2 Sistema de correo 3 Demonios del sistema 4 Mensaje de seguridad/autorización 5 Mensaje generado internamente por

syslogd 6 Subsistema de impresora en línea 7 Subsistema de noticias de red

Tabla 2.Severidades y su código numérico respectivo

El valor de la Prioridad se calcula multiplicando el valor de la Facilidad por 8 y sumándole el valor de la severidad.

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

El TIMESTAMP va inmediatamente después 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 abreviación en inglés del nombre del mes. La primera letra seguida de las otras dos en minúscula. Estos valores pueden ser: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec.

o dd representa al día del mes. Si el día es menor a 10 se debe

representar como un espacio y el número del día. 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) están

representadas en un formato de 24 horas. Los valores permitidos están entre 00 y 23, inclusive. Los minutos (mm) y segundos (ss) están entre 00 y 59 inclusive.

El HOSTNAME corresponde al nombre del dispositivo, la dirección ipv4 o la dirección 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 dirección ipv4, se debe mostrar en la notación decimal con puntos como se usa en STD 13. Si se usa la dirección ipv6, se puede usar cualquier representación válida 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

16

evento. El TAG no debe exceder a 32 caracteres. El otro campo CONTENT es libre de utilización y contiene lo detalles del mensaje A raíz de que cada proceso, programa, aplicación y sistema operativo fue escrito de manera independiente, hay poca uniformidad en el contenido de los mensajes syslog. El protocolo esta diseñado simplemente para transportar esos mensajes de eventos. En todos los casos, existe un dispositivo que origina el mensaje. El proceso syslog en la máquina puede enviar el mensaje syslog a un recolector. Sin embargo, no se hace ningún reconocimiento del recibo del mensaje. [2]

2.1.1.2. Características 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 configuración 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 sesión (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

conexión, no se asegura que los mensajes lleguen al destinatario. • Los mensajes no están 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 autenticación de quien es el remitente. Esto puede concluir en ataques de denegación de servicio y puede permitir que un atacante distraiga al administrador con mensajes falsos para no llamar la atención con su ataque.

Por este motivo se han desarrollado alternativas basadas en syslog para aprovechar la funcionalidad que este provee, de una manera mas confíale.

2.1.1.3. Evoluciones de syslog

Syslog Modular. Syslog modular es una implementación 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]

17

Nsyslog. Nsyslog es una herramienta desarrollada por Darren Reed la cual afronta el problema de la integridad de la versión 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 versión anterior de syslog ya que puede ser configurado para escuchar por el puerto 514/UDP. Syslog-NG. Ésta evolución de syslog fue desarrollado por Balabit IT y su objetivo es extender la versión 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 transmisión se hace mediante UDP o TCP. • Habilidad de enviar los datos a una base de datos. Con syslog-ng el formato del archivo de configuración syslog-ng.conf cambia. [5] 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 dirección falsa o a una dirección 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 técnica se le llama Stealthful Loggin. [5] RFC 3195, Reliable delivery for Syslog (Entrega confiable para Syslog). Este RFC describe un método 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 túnel en el que los mensajes de syslog se pueden asegurar mientras son enviados. BEEP también provee autenticación. [5]

18

2.1.1.4. Comparación de evoluciones de syslog

Debido a que syslog es un protocolo que permite el transporte de los logs, podría ser una herramienta viable en la centralización 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 opción 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 conexión, ni tampoco garantiza integridad, autenticidad, ni privacidad. Por las razones anteriores es conveniente, en caso de ser posible, realizar alguna modificación a éste protocolo o implementar alguna metodología que garantice mayor seguridad.

2.1.2. SNMP

SNMP (Simple Network Managment Protocol) es un protocolo de administración de red, el cual gestiona la configuración de dispositivos de red desde una estación de trabajo. Sin embargo, existen algunos dispositivos de red que no fueron creados para ser administrados con SNMP, para lograr la administración de estos existe un agente especial llamado agente Proxy. [7] SNMP v.1 trabaja con el protocolo de transporte no orientado a conexión, UDP. Los agentes SNMP escuchan por el puerto 161.

2.1.2.1. Componentes de SNMP:

SNMP se compone de tres partes [7]:

1. Consola de administración: La consola de administración es un programa que se encuentra en una estación de trabajo. Ésta tiene la función 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 vía SNMP para lograr la administración de la red” [7]. Se encuentra dividida en cuatro áreas:

19

atributos del sistema, atributos privados, atributos experimentales y atributos de directorio.

Para representar la información de una MIB cada objeto debe tener un identificador de objeto único llamado OID, éste es una secuencia de números enteros no negativos que van separados por un punto. Este identificador sale de un árbol estandarizado mundialmente.

2.1.2.2. Operaciones de SNMP:

En este protocolo existen 6 comandos u operaciones básicas: 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 administración. Este evento siempre es reportado sin solicitud.

2.1.2.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: Versión Comunida

d SNMP PDU

Mensaje SNMP Tipo PDU

empresa Dirección agente

Trap genérico

Trap específico

Time-stamp

Campos variables

Trap PDU Figura 1. Estructura de mensajes SNMP

En donde cada uno de los campos se define a continuación: • Versión: en este campo se define la versión de SNMP que se va a utilizar. • Comunidad: se define la relación 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. • Dirección agente: se encuentra la dirección del objeto generador del trap. • Trap genérico: Es el tipo genérico del trap. • Trap específico: Indica el código específico del trap.

20

• Time-stamp: Indica el tiempo que transcurrió entre la ultima vez que se reinició el dispositivo de red y la creación del trap.

2.1.2.4. SNMP v.3

SNMP v.3 se define como la adición de seguridad y administración a SNMP v.2. Esta versión fue diseñada para corregir, mediante el uso de algoritmos de autenticación y de cifrado, algunos problemas de seguridad con los que contaba la versión anterior, los cuales son mencionados a continuación: • Falta de Integridad • Falta de Autorización • Falta de Autenticación • Spoofing Sin embargo, aún no previene ataques como denegación de servicios y sniffer. Esta versión provee un mejor sistema de seguridad, mucho más robusto y confiable. Utiliza cifrado por medio de DES y autenticación con MD5. También 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 versión frente a las versiones anteriores, es que soporta el uso de lenguajes orientados a objetos, como Java o C++, para la construcción de los elementos propios del protocolo. [8] Debido a que el protocolo SNMP presenta una versión mejorada (SNMP v3), en la cual se reflejan adelantos en el tema de seguridad, garantizando así integridad, autorización, autenticación y spoofing; este protocolo se puede ver como una herramienta útil en la administración de logs. SNMP, presenta adicionalmente, otra gran ventaja ya que provee soporte de lenguajes de programación orientados a objetos, lo cual podría facilitar la intervención en la construcción de elementos del protocolo.

21

2.2. CORRELACION DE REGISTROS DE EVENTOS DE

SEGURIDAD

La correlación 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 correlación busca asociar los eventos para encontrar información útil. [11]

2.2.1. Requisitos para la correlación

Antes de realizar la correlación es necesario haber cumplido con algunos requisitos: Consolidación, Normalización y Reducción. [10]

• La consolidación de los datos consiste en el transporte de los eventos desde los dispositivos o herramientas de seguridad hasta un punto central. El método de transporte utilizado para la consolidación debe ser orientado a conexión y se debe garantizar la integridad y seguridad de los datos. Es importante proteger los datos durante este transporte, para ello se debe usar algún método de cifrado y autenticación.

• La normalización de los datos consiste en cambiar el formato de los

datos a un solo formato polimórfico. Es primordial para propósitos forenses que durante este proceso no se pierda ni se cambie ningún dato.

• Reducción de los datos. Esto se puede realizar comprimiéndolos,

suprimiendo duplicados o combinando eventos similares en un solo evento.

Teniendo en cuenta que uno de los aspectos más 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 estén sincronizadas. Por esto es importante no perder de vista un aspecto que podría clasificarse dentro de la normalización que propone Caldwell, y valdría la pena distinguirlo de la normalización de la forma de los registros.

2.2.2. Eventos, Incidentes y Eventos Compuestos

Un incidente esta definido como el resultado de la correlación de varios eventos. “la correlación,…, es tomar varios eventos de seguridad aislados y unirlos para crear un único y relevante incidente de seguridad.”[10]. Un evento es la representación de cambios de estado de interés que pueden ocurrir en un sistema. Éstos se clasifican en eventos primitivos y eventos compuestos. Los primeros están predefinidos en un sistema y la detección de

22

estos esta embebida en la implementación 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 especificación de eventos compuestos llamado JESL (Java Event Specification Language) el cual se describe a continuación. JESL El lenguaje JESL esta basado en los conceptos enumerados a continuación:

• 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 más reciente del evento e en un tiempo t.

=i)(e, es t tiempoelen e de reciente mas instancia la i

t tiempoelen ocurrido ha no (e,1) 0),(# te

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

evento e (e,i) i)(e, de attr atributo del valor eliattreAttrValue =),,(

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

relativa de un evento e en un tiempo t )),(#,,(),,,( iteattreAttrValueitattreAttrValuer +=

Donde (#(e,t)+i)>0, y t es el tiempo de referencia. • @ y @r: Un atributo común de todos los eventos es el tiempo de

ocurrencia. Por eso se define la función @ y @ relativo para representar el tiempo de ocurrencia de una determinada instancia del evento e.

),,"",(),(@),"",(),@(

itimeOcurrenceTeAttrValueieiimeOcurrenceTeAttrValueie

rr ==

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

23

),@()1,@(0

ieiei

>+>∀

• @f y @fr: Mediante esta función se puede definir un subconjunto de

instancias de e, en el cual están las instancias de e que cumplen con una expresión booleana f. Este grupo de instancias constituyen el evento ef.

),,@(),,,(@),@(),,(@

iTeiTfeieife

ffr

ff

=

=

2.2.2.1. Especificación 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 CE’s ATTRIBUTES;

2.2.3. Tipos de Correlación

Los dos aspectos más importantes en la correlación de eventos son la velocidad con la cual ocurre la correlación, y la exactitud de los datos devueltos en la correlación. [11] Es importante que el sistema de correlación informe los incidentes tan rápido como sea posible para que el administrador de la red actúe de acuerdo a esto. De igual forma, el sistema de correlación debe reducir el número de falsos positivos y falsos negativos [9]. Luego de haber cumplido con los requisitos para correlacionar se puede proceder a la correlación. Existen diferentes métodos para esto: correlación basada en reglas, correlación estadística y correlación con sistemas de inteligencia artificial

24

2.2.3.1. Correlación basada en reglas

Éste tipo de correlación 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 común. [12] Los motores de correlación basados en reglas aplican los incidentes conocidos en un ataque para seguir detectando exactamente este ataque [12]. En otras palabras, los sistemas de correlación basados en reglas combinan un conjunto de reglas con los eventos que va recibiendo. Basándose en los resultados de cada prueba, y la combinación 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 correlación funcione bien y los resultados sean exactos, es necesario ingresar las reglas correctamente y mantenerlas actualizadas en caso de algún cambio en los datos. [11]

2.2.3.2. Correlación estadística

Esta correlación no emplea ningún conocimiento preexistente de incidentes malévolos, sino que por el contrario confía 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 también comparar a los patrones acumulados de la actividad, para distinguir normal de anormal (sospechoso). La correlación estadística utiliza algoritmos numéricos especiales para calcular los niveles de amenaza incurridos por los eventos relevantes de la seguridad. Tal correlación 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 históricamente, de modo que las desviaciones lleguen a ser evidentes. La detección de incidentes al usar correlación estadística no requiere ningún conocimiento preexistente del incidente a ser detectado. Los métodos estadísticos se pueden, sin embargo, utilizar para detectar incidentes en umbrales predefinidos de la actividad. Tales umbrales se pueden configurar basándose en la experiencia que supervisa el ambiente. [12]

2.2.3.3. Correlación con sistemas de inteligencia Artificial

Este tipo de correlación usa varias formas de inteligencia artificial (AI). Hay muchos tipos diversos de inteligencia artificial, y las técnicas de la correlación de eventos se han propuesto utilizar varias combinaciones de ellas, incluyendo redes neuronales y sistemas expertos. Los sistemas de AI tienen una ventaja

25

en que, si están bien programados, tienen la capacidad de aprender por si solos, ayudando a eliminar la continua necesidad de los expertos [11]. Este tipo de correlación se basa en la forma en que el cerebro humano correlación información. El objetivo de la correlación de logs es lograr detectar ataques o amenazas en un tiempo mínimo, para alcanzar a actuar frente a determinado suceso. Es importante que los logs cumplan con los requisitos de normalización, sincronización de tiempo, transporte y reducción, para lograr una correlación exitosa.

2.3. COMPUTACIÓN FORENSE Y EVIDENCIA DIGITAL

2.3.1. Computación Forense

Según el FBI, la computación forense se define como “la ciencia de adquirir, preservar, obtener y presentar datos que han sido procesados electrónicamente y guardados en un medio computacional” [14]. Esta ciencia también se ocupa de crear y emplear medidas preventivas para eventos ocurridos en sistemas de información y/o en redes locales. La computación forense tiene como fin asistir en la reconstrucción posterior de eventos o ayudar a anticipar acciones no autorizadas [15]. El uso del análisis forense y la evidencia digital ayuda a identificar y procesar gran cantidad de crímenes. Para esto los investigadores usan un gran número de técnicas y herramientas de software que ayudan en el proceso del análisis computacional. En computación forense es importante conocer el tema de la evidencia digital y su manejo.

2.3.2. Evidencia digital

Al iniciar una investigación de computación forense se debe hacer con la recolección de datos o información, la cual está presente en las pruebas o evidencias obtenidas de los sitios donde se ha cometido algún incidente o delito informático. Casey define la evidencia digital como “cualquier dato que puede establecer que un crimen se ha cometido o puede proporcionar una relación entre un crimen y su víctima o un crimen y su autor”. [16]

26

La evidencia digital se puede recolectar y analizar con herramientas y técnicas 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 daño. Sin embargo, este problema es mitigado con algunas características 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 comúnmente para no manejar los originales y evitar el riesgo de dañarlos.

• Actualmente, con las herramientas existentes, es muy fácil comparar la evidencia digital con su original, y determinar si la evidencia digital ha sido alterada.

• La evidencia de Digital es muy difícil de eliminar. Aún 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.

2.3.2.1. Clasificación de la evidencia digital

Cano clasifica la evidencia digital que contiene texto en 3 categorías [18]: Registros generados por computador: Estos registros son aquellos, que como dice su nombre, son generados como efecto de la programación 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 híbridos que incluyen tanto registros generados por computador como almacenados en los mismos: Los registros híbridos son aquellos que combinan afirmaciones humanas y logs. Para que estos registros sirvan como prueba deben cumplir los dos requisitos anteriores.

27

Este artículo se centrara en la evidencia digital de registros generados por computador (logs).

2.3.2.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 manipulación. Por esta razón 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 artículo 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 reputarán auténticos, sin necesidad de presentación personal ni autenticación. Todo ello sin perjuicio de lo dispuesto en relación 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 orígenes son “creíbles y verificables” [19]. Para probar la confiabilidad, se debe contar con una arquitectura de computación 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 computación del sistema logrará tener un funcionamiento correcto siempre que tenga algún mecanismo de sincronización del registro de las acciones de los usurarios del sistema y que a posea con un registro centralizado e íntegro de los mismos registros.

28

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, sincronización y centralización” [19] para lograr tener una vista completa de la situación. Para lograr lo anterior es necesario hacer una verdadera correlación 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 códigos de procedimientos y disposiciones legales del ordenamiento del país. Es decir, debe respetar y cumplir las normas legales vigentes en el sistema jurídico.

2.3.2.3. Manipulación de la Evidencia Digital

Es importante tener presente los siguientes requisitos que se deben cumplir en cuanto a la manipulación de la evidencia digital.

• Hacer uso de medios forenses estériles (para copias de información) • 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 investigación, deben estar disponibles para su revisión.

• Siempre que la evidencia digital este en poder de algún 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 recolección y análisis

de la evidencia digital, serán quienes deben garantizar el cumplimiento de los principios anteriores.

2.3.2.4. centralización de registros de eventos dentro del ciclo de vida de la evidencia digital.

Al analizar el documento de buenas prácticas en la administración de la evidencia digital, de Jeimmy J. Cano [21], se observa que dentro del ciclo de vida para la administración de la evidencia digital, el cual se comprende de 6

29

pasos, hay 2 de ellos que se deben tener en cuenta en el transporte de registro eventos. Los cuales son citados a continuación. Paso 2. Producción de la evidencia. Este paso esta compuesto de los siguientes objetivos:

• “que el sistema o tecnología de información produzca los registros electrónicos

• identificar el autor de los registros electrónicos almacenados • identificar la fecha y hora de creación • verificar que la aplicación está operando correctamente en el momento

de la generación de los registros, bien sea en su creación o modificación.

• Verificar la completitud de los registros generados” Paso 3. Recolección de la evidencia. El paso 3 requiere el cumplimiento de 5 objetivos citados a continuación:

• “Establecer buenas prácticas y estándares para recolección 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

recolección de la evidencia digital • Desarrollar criterios para establecer la relevancia o no de la evidencia

recolectada.”

2.4. PROTECCIÓN DE INFORMACIÓN Y HERRAMIENTAS DE

SEGURIDAD

Es necesario conocer las técnicas existentes para proteger la información y los recursos de una red. Estas técnicas se clasifican en dos tipos: Seguridad Física y Seguridad Lógica.

2.4.1. Seguridad física

La seguridad física es uno de los aspectos más olvidados durante el diseño de un sistema de seguridad informática. Sin embargo, este es un tema de gran importancia y sin él, no tendría sentido la seguridad de la red.

30

La Seguridad Física se refiere a controlar e implementar mecanismos de seguridad dentro y alrededor del centro de cómputo. También 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 también, para el edificio o lugar físico en el que se encuentra la información. Este tipo de seguridad está enfocado a prevenir las amenazas ocasionadas tanto por el hombre como por la naturaleza, al medio físico en que se encuentra ubicado el centro. Las principales amenazas que se prevén en la seguridad física 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 lógica.

2.4.2. Seguridad lógica

En las compañías, lo más importante que se tiene es la información, y por lo tanto deben existir técnicas, que complementen a la seguridad física, que la aseguren, lo cual es brindado por la Seguridad Lógica. La seguridad lógica es de los mecanismos más importantes e influyentes de la seguridad informática. Este tipo de seguridad tiene como función la imposición de barreras y procedimientos que protejan el acceso a los datos y sólo se permita acceder a ellos a los usuarios autorizadas para hacerlo. Los objetivos que plantea la seguridad lógica 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 información transmitida se reciba sólo por el destinatario

al cual ha sido enviada. • Establecer que la información recibida sea la misma que ha sido

transmitida.

2.4.3. Protección

La mayoría 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.

31

A continuación se mencionan algunas herramientas o técnicas de protección de información, sin embargo es importante tener en cuenta que ninguna de las técnicas expuestas a continuación representará el 100% de la seguridad deseada, por tanto, será la suma de algunas de ellas las que convertirán un sistema interconectado en confiable.

2.4.3.1. Criptografía.

Esta técnica de protección es una de las mejores defensas de las comunicaciones. La criptografía es una técnica que permite mantener los datos de un modo privado y protegido, lo cual impide que un intruso logré ver la información real. El tener la información que se envía por la red cifrada, garantiza que no sea la información original, sino que se encuentra codificada y carente de sentido excepto para el receptor, quien cuenta con los medios precisos para decodificarla. La criptografía ayuda a proteger la confidencialidad de la información. Su objetivo principal es dificultar el acceso por parte de un individuo no autorizado, a la información, incluso si posee la información cifrada y conoce el algoritmo criptográfico empleado. Generalmente se requiere tiempo y dinero para lograr interpretar la información cifrada. Algunos de los métodos más usados actualmente para ésta técnica son: criptografía simétrica, criptografía asimétrica y criptografía híbrida (combinación de las dos anteriores). Los métodos anteriores hacen manejo de llaves y funciones matemáticas. • Algoritmos simétricos: éste método utiliza la misma clave para cifrar y

descifrar la información, lo cual lo hace rápido y fácil de implementar tanto en hardware como en software. Los algoritmos simétricos no proporcionan Autenticación. Un ejemplo de éstos algoritmos, es el algoritmo DES.

• Algoritmos asimétricos: estos algoritmos utilizan dos claves diferentes

(pública y privada) relacionadas entre sí, en donde la información cifrada por la primera de ellas solamente puede ser descifrada por su par y viceversa.

Con algoritmos asimétricos se obtiene confidencialidad y autenticación. Un ejemplo de algoritmos simétricos es RSA.

2.4.3.2. Autenticación.

La autenticación se refiere al proceso de verificar la identidad de una persona. Éste proceso se puede llevar a cabo por medio de sistemas biométricos (huella digital, retina, etc) smart cards, firmas digitales, passwords, PKI, etc.

32

2.4.3.3. Firewalls.

Estas herramientas son unas de las más conocidas al momento de establecer seguridad, y deben ser uno de los sistemas a los que más se debe prestar atención. Un firewall es un sistema que ejerce políticas de seguridad establecidas. Este sistema puede ser de software ejecutándose 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 tráfico entre redes y para examinar los paquetes que llegan o salen de la red en la que se encuentran. Si el firewall encuentra algún elemento extraño en el tráfico de la red, restringe el paso. Sin embargo, vale la pena nombrar que el firewall no protege ataques como: virus y bombas lógicas, tunelling, ataques físicos, y todo aquello que circule por la red sin pasar por el firewall.

2.4.3.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. También podrán definirse otras características como limitaciones de anchos de banda y horarios.

2.4.3.5. Sistema de Detección de Intrusos (IDS).

Los IDS son sistemas diseñados para examinar tráfico 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 tráfico de la red buscando posibles ataques. • Controlar los logs de los servidores para descubrir anomalías (tanto de

intrusos como de usuarios autorizados). • Mantener almacenado el estado exacto de cada uno de los archivos del

sistema para detectar la modificación de los mismos. • Controlar el ingreso de cada nuevo archivo al sistema para detectar

caballos de troya o ataques semejantes. • Controlar el núcleo 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 métodos de detección:

33

• Por anomalías: a partir de la caracterización del tráfico y estadísticas del sitio, el IDS busca desviaciones.

• Por firmas: el IDS busca patrones predefinidos dentro del tráfico. 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.

2.4.3.6. Antivirus.

El antivirus es un programa creado para prevenir la penetración de los virus en un equipo, evitando su propagación a los diferentes sistemas. Estas herramientas tienen algunos mecanismos de detección, eliminación y reparación de archivos infectados. Los antivirus se encuentran constantemente monitoreando el sistema.

2.4.3.7. Dispositivos de red.

Estos dispositivos tienen la capacidad de analizar los paquetes y darles la ruta más adecuada dependiendo de su destino. Y aunque no es su función principal, pueden ser configurados para alertar el intento de entrar a redes privadas, así como también tienen la posibilidad de temporizar el login para evitar ataques de fuerza bruta. Los enrutadores pueden también, hacer control del ancho de banda y evitar de éste modo ataques como denegación de servicios Los enrutadores o cualquier dispositivo de red, no debe ser considerado, ni siquiera en ambientes pequeños, como el único elemento de seguridad. De hecho, debe ser usado en primera instancia, para cumplir su función con la que fue diseñado.

2.4.3.8. Sistemas Anti-Sniffers.

Estas herramientas tienen como función 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.

2.4.4. Inversión

Los costos de las diferentes herramientas de protección se están haciendo accesibles, en general, incluso para las organizaciones más pequeñas. Esto hace que la implementación de mecanismos de seguridad se dé prácticamente

34

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 tamaño y potencialidades de la herramienta. También es importante mencionar que actualmente, en Internet, se encuentran gran cantidad de herramientas de libre distribución.

2.5. CLASIFICACIÓN Y TIPOS DE ATAQUES INFORMÁTICOS

2.5.1. Vulnerabilidad

Las vulnerabilidades de seguridad, es la posibilidad de que el sistema u organización 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 crítico en la seguridad informática. Sin embargo, vale la pena mencionar, que la gran mayoría 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.

2.5.1.1. Tipo de vulnerabilidades

A continuación se definirán algunas vulnerabilidades más comunes en los sistemas. Ésta clasificación fue tomada de [25]. Service Deny (DoS): Durante éste ataque, el intruso intenta evitar que un usuario tenga acceso a información 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 programación. 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 víctima de un web Server legítimo a una página dañina que contiene HTML malévolo [27]. Commands Inyection: éste error de sistema permite al atacante introducir código dañino por medio del servicio web a otros sistemas a través del protocolo http o mediante scripts. SQL Injections: Esta vulnerabilidad hace referencia a una técnica de explotar aplicaciones Web que no validan la información suministrada por el cliente,

35

para enviar consultas SQL maliciosas por medio de un campo o parámetro de la aplicación, con el fin de realizar modificaciones sobre la base de datos. Stack Overflow: Esta vulnerabilidad ocurre cuando el tamaño máximo de la pila del sistema es excedido. Heap Overflow: El heap es una región de memoria que es inicializada dinámicamente para un programa. Un heap overflow ocurre cuando el contenido del heap es sobrescrito por código arbitrario. Esto sucede por un error de programación, al no poner límites a algún componente del programa. Integer Overflow: Estos errores suceden debido a la no comprobación y a las malas suposiciones de los programadores en la conversión entre diferentes tipos y operaciones aritméticas. Path Manipulation: Consiste en la manipulación del path de las aplicaciones, lo cual provee ubicaciones distintas y por tanto recursos distintos a los normalmente utilizados.

2.5.2. Amenazas y ataques

Como consecuencia de las vulnerabilidades en los sistemas se crean las amenazas. Una amenaza es una condición del entorno de la información, que se puede presentar en una persona, máquina, suceso o idea, la cual, dada una oportunidad, podría dar lugar a que se produjese una violación de los principios de la seguridad. Cuando dicha violación de seguridad se produce, se habla de un ataque.

2.5.2.1. Clasificación de ataques según el principio violado

Las amenazas o ataques se pueden clasificar de la siguiente manera según su modo de acción: Interrupción: Este tipo de ataque sucede cuando el atacante atenta contra un recurso del sistema dejándolo en un estado no disponible o inoperable, debido a la destrucción del recurso, o de ocasionar el mal funcionamiento del mismo. La interrupción es un ataque contra la disponibilidad. Algunos ejemplos de interrupciones son la destrucción de un recurso de hardware, dañar una línea de comunicación o deshabilitar un servidor de base de datos.

Emisor Recepto

r

36

Figura 2. Interrupción [28] Intercepción: Éste ataque ocurre cuando un intruso consigue acceso no autorizado a un recurso. La intercepción atenta contra la confidencialidad. Debido a que en este ataque no se produce ningún tipo de alteración sobre los recursos, es muy complicado detectarlo. Ejemplos de este ataque son la copia no permitida de información, o la interferencia de una red para observar los datos que viajan por ella.

Figura 3. Intercepción [28]

Modificación: En este ataque, el intruso accede al recurso y lo altera o modifica. Este es un ataque contra la integridad. Es el más peligroso de los ataques, pues puede ocasionar mucho daño. Los ejemplos más comunes de este ataque son: modificación de los datos de un archivo, y alteración de los datos que viajan por la red.

Figura 4. Modificación [28]

Fabricación: Es el ataque en el cual un intruso fabrica información falsa y la inserta en el sistema a atacar. Este es un ataque contra la autenticidad. Ejemplos de este ataque son la inserción de mensajes falsos en una red o añadir registros a un archivo.

Emisor Receptor

Intruso

Emisor Receptor

Intruso

37

Figura 5. Fabricación [28]

2.5.2.2. Clasificación de ataques según su efecto.

Los ataques se pueden así mismo clasificar de forma útil en términos de ataques pasivos y ataques activos. • Ataques pasivos. Estos ataques, el intruso únicamente monitorea o escucha

la información que viaja por la red, no la modifica, ni la altera. Con el fin de interceptar datos y analizar el tráfico que viaja por la red para obtener información.

Como se menciono anteriormente, estos ataques son muy difíciles de detectar, ya que no provocan ninguna modificación de los datos. La forma de evitar estos ataques es usando métodos para cifrar la información. • Ataques activos. Este tipo de ataque, sucede cuando el intruso realiza

alguna modificación de los datos que viajan por la red o cuando se lleva a cabo la creación de un falso flujo de datos.

Estos ataques son los más perjudiciales para el atacado.

2.6. 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 versión 4, el cual ha sido formalizado en el RFC 1305. Existe también una versión 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 correlación confiable, teniendo en cuenta los logs generados por los dispositivos. [38]

Emis Rece

Intrus

38

2.6.1. Arquitectura del sistema

El protocolo NTP fue diseñado 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 precisión y debe contar con el software necesario para manejar NTP. La idea es que este servidor primario transmita la información del tiempo a otros servidores de tiempo (Stratum 2) quienes, a su vez, deben transmitir la información y sincronizar a otros servidores. Todos los participantes de este esquema deben tener el software requerido para la sincronización por NTP. En NTP, existen dos formas de sincronización. 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 numeración de Stratum inmediatamente superior a la de su servidor. En la otra forma, existen dos maquinas que se prestan servicios de sincronización entre sí, es decir, cada máquina se configura para comportarse como cliente o servidor, según el que sea m. En esta configuración los servidores se llaman peers. La siguiente Figura refleja el esquema jerárquico usado por NTP. Ésta jerarquía puede ser usada hasta 16 niveles.

Figura 6. Esquema jerárquico de NTP. [37]

39

NTP provee una precisión de tiempo de uno o dos milisegundos en LANs, y hasta 10 milisegundos en WANs. Este protocolo trabaja enviando mensajes UDP a través del puerto 123

2.7. SSH

SSH (The Secure Shell) es un protocolo que permite transportar datos de manera segura. SSH actúa transmitiendo datos sobre TCP/IP, y utiliza mecanismos fuertes de cifrado y autenticación que garantizan la integridad, confidencialidad y autenticación 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 través de la red, SSH los cifra automáticamente, y al ser recibidos los descifra automáticamente.

2.7.1. Arquitectura de SSH

SSH utiliza una arquitectura cliente/servidor, en la cual una máquina actúa 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 autenticación. Así como, de prestar los servicios propios de SSH. Las máquinas que actúan 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 conexión con el cliente. El servidor puede conectarse con muchos clientes y la comunicación entre cliente/servidor es bidireccional. Tal y como se muestra en la Figura 6.

40

Figura 7. Esquema de distribución de SSH Una vez los clientes se conectan al servidor, el servidor acepta la conexión y responde al cliente enviando su versión de identificación. El cliente recibe la identificación del servidor y envía la suya propia. Esto se realiza con el fin de verificar que la conexión se realizo por el puerto correcto, además de declarar la versión del protocolo usado y del software utilizado de cada uno. Después del intercambio de identificaciones, se pasa a un protocolo binario basado en paquetes, en el cual el servidor envía su llave de host (cada host tiene un llave RSA utilizada para autenticar el host), la llave del servidor, y otra información al cliente. Cuando el cliente la recibe, genera una llave de sesión, la cifra usando ambas llaves de RSA, y envía la llave de sesión cifrada y el tipo de cifrado seleccionado al servidor. El servidor envía un mensaje cifrado de confirmación al cliente. [43] Luego, el cliente se autentica usando alguno de los métodos de autenticación. Si la autenticación es exitosa, el cliente hace peticiones de preparación para la sesión.

41

2.7.2. Características de SSH.

SSH tiene algunas características, descritas a continuación, que proveen un nivel de seguridad alto, y protegen la comunicación entre cliente-servidor.

2.7.2.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 sesión y luego destruidas cuando la sesión 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).

2.7.2.2. Autenticación.

El protocolo SSH contiene dos autenticaciones: el cliente verifica la identificación del servidor SSH y el servidor valida la identidad de los clientes que requieren una conexión. La autenticación 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 autenticación es usualmente realizada con contraseñas, sin embargo éste esquema es una forma débil de autenticación, ya que la contraseña puede ser obtenida por un atacante. Existen otros métodos de autenticación tales como autenticación por rhosts, autenticación por rhosts basado en RSA, y autenticación por RSA. Sin embargo, existen configuraciones en las cuales se agregan otros métodos de autenticación.

2.7.2.3. Autorización.

Los servidores de SSH tiene varios esquemas para la restricción de las acciones de los clientes: acceso a sesiones interactivas, reenvío de puertos (port forwarding), agente de reenvío de llaves, entre otros. Esto se hace con la intención de no dar privilegios iguales a todos los clientes, sino por el contrario, se restringen de acuerdo a sus funciones.

2.7.2.4. Integridad

Para asegurar que los datos que llegan al receptor no fueron alterados y son los mismos que envío 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.

42

2.7.2.5. Túnel (Tunneling)

La creación de un túnel SSH se realiza para encapsular algún servicio basado en TCP (como telnet) en una sesión de SSH. Esto se realiza con el fin de dar la seguridad de SSH a otros protocolos.

2.7.3. Usos comunes de SSH

El protocolo SSH es usado comúnmente 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 administración remota a los servidores de forma segura.

• Transferencia segura de archivos. Esta tecnología 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 información 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 aplicación. Con el uso de línea 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 túnel TCP, y redireccionar los puertos de conexión sobre el canal cifrado en ambas direcciones de la comunicación. Así establecer la comunicación a través del túnel, lo que garantiza integridad, confidencialidad y autenticación en la comunicación, aun sin la necesidad de cambiar la funcionalidad de la aplicación ni la interfaz de usuario. Ésta característica hace que SSH sea una solución genérica para asegurar las conexiones.

3. DESARROLLO DEL PROYECTO

El desarrollo de éste proyecto está orientado a la definición de una guía metodológica para la gestión centralizada de registros de eventos de seguridad de red, para que pueda ser utilizada en organizaciones de pequeña y mediana escala. Para lograr lo anterior, el proyecto fue desarrollado en cinco etapas consecutivas. La etapa inicial busca la apropiación del conocimiento asociado a la gestión de seguridad, registros de eventos y computación forense. Esta etapa se desarrollo por medio de la investigación en fuentes bibliográficas e indagación con personas más cercanas a los conceptos de interés. Ésta etapa se ve reflejada en el capítulo 2 de éste documento. Una vez, obtenido el conocimiento propio del tema a desarrollar, la etapa siguiente es realizar el análisis y definición de requerimientos para la gestión centralizada de registros eventos de seguridad. La definición de los requerimientos se realiza con base en un análisis de las características de una red típica de una pyme. y en los conceptos de correlación y evidencia digital obtenidos en la etapa inicial. Luego de la etapa de levantamiento de requerimientos, se ejecuta la definición de una infraestructura de software y hardware para la gestión centralizada de registros de eventos de seguridad que soporte los requerimientos definidos anteriormente. La definición de dicha infraestructura se realiza por medio del diseño de un sistema de centralización que debe cumplir con los requerimientos definidos, y de la definición de herramientas que soporten dicho diseño. A continuación, se procede a definir una guía metodológica para la implantación de la infraestructura definida. Ésta etapa se desarrolla estructurando el diseño del sistema de centralización que se definió anteriormente. Para esto se definen una serie de actividades y métodos que debe realizar el usuario final con el fin de lograr la centralización de los registros de eventos de seguridad. Finalmente, la etapa a realizar es validar la guía metodológica mediante la definición e implementación de un caso de prueba que se ajuste a las características de la red de una pyme. Esta etapa de validación se realiza mediante el seguimiento paso a paso de la guía metodológica y observando los resultados obtenidos. Este capítulo abarca las etapas 2, 3 y 4 del desarrollo del proyecto. La etapa de validación de la guía metodológica se encuentra comprendido en el capitulo 4 “Validación de la guía Metodológica” de este documento

44

3.1. RED TIPICA DE UNA PYME.

La definición de una red típica de una pyme se planeo realizar por medio del levantamiento de información en entidades públicas 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 tecnológico de la pequeña y mediana empresa, la cual nos pudiera revelar información apropiada para la definición de las características de una pyme. De este modo, se planeo en segunda medida realizar un estudio con una muestra significativa de pequeñas y medianas empresas, para lograr así obtener la información deseada. Al ejecutar esta acción, se encontró que no es sencillo obtener información en cuanto al manejo de la seguridad informática y de la red de pymes donde no se tiene una relación de confianza previa, por lo que el levantamiento de información no tuvo éxito. Finalmente, se decidió buscar la información de las características de una red típica de una pyme por medio del tamaño definido para estas legalmente, obteniendo así un número aproximado de usuarios. Seguidamente, se buscó información en los proveedores de tecnología para pymes, de esta manera se consiguió obtener la información deseada y se pudo realizar un esquema genérico de una red típica de una red.

3.1.1. Tamaño de una Pyme

Según la ley LEY 905 DE 2004 que reforma la LEY 590 DE 2000 se define el tamaño las microempresas, pequeñas empresas y medianas empresas de la siguiente manera: “ARTÍCULO 2o. El artículo 2o de la Ley 590 de 2000 quedará así: Artículo 2o. Definiciones. Para todos los efectos, se entiende por micro incluidas las Famiempresas pequeña y mediana empresa, toda unidad de explotación económica, realizada por persona natural o jurídica, en actividades empresariales, agropecuarias, industriales, comerciales o de servicios rurales o urbanos, que responda a dos (2) de los siguientes parámetros: 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 mínimos mensuales legales vigentes. 2. Pequeña empresa: a) Planta de personal entre once (11) y cincuenta (50) trabaja-dores, o

45

b) Activos totales por valor entre quinientos uno (501) y menos de cinco mil (5.000) salarios mínimos 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 mínimos mensuales legales vigentes o, …” Para efectos de la definición del tamaño de una red el factor que interesa es el número de trabajadores, por lo cual se puede deducir que siendo una Pyme una empresa pequeña o mediana, el número de trabajadores podría oscilar entre 11 y 200 trabajadores.

3.1.2. Características de una red típica de una PyME

3.1.2.1. Red típica SMB Microsoft®

En [29] definen una red típica SMB con productos Microsoft® de la siguiente manera.

Figura 8.Red Típica de una pyme definida por Microsoft. [29]

En esta red se identifican los servidores típicos así como los equipos típicos tanto de usuarios como de red y seguridad que se enuncian a continuación: DC. Domain Controller Un DC es responsable de controlar y mantener las actividades del dominio. Más específicamente responde a solicitudes de autenticación, y de chequeo de permisos.

46

En un DC están [30]:

• Una copia física 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 Impresión. Exchange: Servidor de correo electrónico 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 Inalámbrico

3.1.2.2. Servicios de la red típica de una PyME y sus principales implementaciones

Con base en los componentes definidos en [29], una red típica de una PyME tendría los siguientes servicios:

• Servidor de Autenticación • DNS • DHCP • Servidor de Archivos • Servidor de Impresión • Servidor de correo electrónico Según estadísticas de [33] los 3 servidores de correo más usados son:

o Microsoft ESMTP MAIL Service o Sendmail o Imail

• Servidor o manejador de bases de datos • Servidor Web

47

De acuerdo con [31] los tres servidores Web más 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 Según [32] la industria de los Firewalls con VPN integrados ha crecido notablemente; “es el tercer segmento más grande dentro del software de seguridad”. También aseguran que según un estudio de Infonetics Research, Cisco System es la empresa líder en este mercado seguida por Check Point Software Technologies. Sumando entre ambas un 59,2% del mercado. • Access Point inalámbrico • Enrutador hacia Internet

3.2. REQUERIMIENTOS PARA LA GESTION CENTRALIZADA

DE LOS REGISTROS DE EVENTOS DE SEGURIDAD

De acuerdo con los requisitos definidos anteriormente (sección 2.2) para realizar el proceso de correlación, y para mantener el carácter de evidencia digital de los registros de eventos, se definen los requerimientos propios para la gestión centralizada de éstos. Estos requerimientos se clasifican en requerimientos funcionales y requerimientos no funcionales. Los funcionales son aquellos que se definen la interacción entre el sistema y sus usuarios u otros sistemas, independiente a su implementación. 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]

3.2.1. 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 polimórfico para su correlación. El formato por lo menos debe tener

o Identificación del sistema que generó el evento o Estampilla de tiempo o Detalle del evento

• Debe existir un proceso de reducción de datos para el proceso de correlación. Con esto se busca la eficiencia en la correlación y se puede hacer mediante:

o Compresión de datos

48

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 algún mecanismo de identificación del sistema o tecnología de información que los generó para efectos de su utilización como evidencia digital.

3.2.2. Requerimientos no funcionales

• Se debe utilizar un método de transporte confiable. o El método de trasporte debe ser orientado a conexión o Debe garantizar la integridad de los datos. o Debe mantener algún mecanismo de autenticación o Los datos deben estar cifrados durante el transporte.

• Se debe utilizar algún mecanismo de autenticación con respecto al sistema que los generó.

• Se debe asegurar que no se perdió, ni cambó ningún 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.

3.2.3. Diagrama de Red típica de una Pyme.

De acuerdo al análisis realizado de la red de una pyme, se determina que el esquema de red que define apropiadamente la red típica de una pyme es como se muestra en la figura 8.

49

Figura 9. Diagrama de una Red típica de una pyme

3.2.3.1. Logs de Seguridad en una Pyme

De acuerdo con la clasificación de NIST [34] podríamos encontrar los siguientes logs de seguridad en una Pyme: Logs de Aplicaciones de Seguridad

• Logs de Servidor de Autenticación • 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)

50

3.3. DEFINICIÓN DE INFRAESTRUCTURA

Tras haber definido los requerimientos que debe satisfacer la guía metodológica, se procede a realizar la definición de los procedimientos que deben estar comprendidos en la guía metodológica, para la satisfacción de la totalidad de los requerimientos.

3.3.1. Definición del método de sincronización 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 sincronización de tiempo más 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 instalación y configuración de NTP es necesario determinar un servidor de NTP, el cual debe ser un equipo con sistema operativo UNIX Like1, 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 configuración . 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 sincronización de relojes, la cual se describe en la guía metodológica. [ANEXO 1]. Los dispositivos de red (routers, access point, etc), deben también ser sincronizados. Estos tienen soporte desde la fábrica, para correr el protocolo NTP, o SNTP.

3.3.2. Definición del método de transporte

Para cubrir el requerimiento que hace referencia a tener todos los registros de eventos en un punto central de la red, se consideran los protocolos que pueden proveer transporte de logs (SNMP, Syslog y sus versiones mejoradas).

1 Entiéndase como Unix Like todo sistema operativo que se comporte de manera similar a un sistema UNIX, como Linux.

51

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 autenticación, integridad, y confidencialidad. Adicionalmente, este transporte debe ser orientado a conexión. Para establecer el método más apropiado para realizar el transporte, se busca el método que cumpla con la mayor cantidad de requerimientos posibles. Para esto, se realiza una comparación entre los métodos contemplados teniendo en cuenta los requerimientos con los que cumplen. Método de transporte Integridad Autenticación Confidencialidad Orientado a

conexión Syslog-ng P RFC 3195 /Secure Syslog

P P P P

Nsyslog P P P Modular Syslog(msyslog) P Stealthful Logging SNMP Traps v1. SNMP Traps v3. P P P

Tabla 3. Característica de los Métodos de transporte Como se observa en la Tabla 3 ninguno de los métodos contemplados cumple con todos los requisitos necesarios para realizar el transporte. Por lo que se contempla la idea de establecer un túnel SSH, por medio del cual se encapsule algún servicio basado en TCP en una sesión de SSH. Esto garantiza satisfacer los requerimientos de proveer autenticación, integridad, confidencialidad y transporte orientado a conexión. Para la elección 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 podría ser utilizado. Sin embargo, se encuentra que secure syslog (rfc 3195) no tiene implementación para sistemas operativos Windows, lo cual restringe su uso en la guía metodológica, considerando que este sistema operativo es usualmente utilizado en pequeñas y medianas empresas. Finalmente, se decide el uso de syslog-ng, ya que además 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 gestión centralizada de los logs, y hace más sencilla su correlación. Con la implementación de syslog-ng, se garantiza también el cumplimiento del requerimiento que exige que los registros de eventos queden todos en un solo formato polimórfico para su correlación, ya que el formato utilizado es el propio de syslog.

52

3.3.3. Definición de herramientas de uso en la guía metodológica.

Una vez definido el método 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 actúa bajo una arquitectura cliente servidor, se considera necesaria la determinación 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 típica de una pyme. Es importante aclarar que todas las herramientas utilizadas para la centralización de registros de eventos son de libre distribución lo que permite a todas las pymes seguir la guía metodológica sin limitaciones económicas de software. Con este documento se adjuntan versiones adquiridas durante el segundo semestre de 2006 de todas las herramientas utilizadas.

3.3.3.1. Herramientas para el servidor.

Para la creación del túnel SSH, se debe buscar una herramienta que permita establecer el túnel en una máquina con sistema operativo UNIX LIKE y actúe 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 túnel, 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 página 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 guía metodológica. [ANEXO 1]

3.3.3.2. Herramientas para clientes con sistema operativo UNIX LIKE.

En los clientes con sistema operativo UNIX LIKE, para establecer el túnel SSH, se sugiere el uso de la herramienta SSH client [44]. Aunque cualquier otra que permita establecer un túnel SSH con el servidor podría ser útil. En cuanto a syslog-ng, se utiliza la misma herramienta nombrada para el servidor, y su configuración es tal como se muestra en la guía metodológica. [ANEXO 1]

53

3.3.3.3. Herramientas para clientes con sistema operativo WINDOWS.

En los equipos con sistema operativo Windows, para establecer el túnel se debe usar una herramienta que permita su creación, la cual debe permitir su administración por medio de línea de comandos, así como su ejecución de fondo (en background), de éste modo el proceso de establecer el túnel 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 conexión por medio de línea de comandos. Existe una herramienta llamada LASSO [47], la cual es un software de código abierto, diseñado para recoger registros de eventos en Windows, pasarlos a formato syslog y transportarlos vía TCP a cualquier receptor de logs compatible con syslog-ng.

3.3.3.4. Herramientas para otros clientes.

Los dispositivos de red presentes en la red de la pyme, como requerimiento de la guía 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 envíen 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 demás dispositivos de red, es posible realizar la centralización por medio de syslog con UDP sin embargo no se cumpliría en su totalidad con los requerimientos de la guía. Por no proveer integridad, confidenciabilidad, ni autenticación. Actualmente, no se tiene implementado syslog seguro en los dispositivos de red, sin embargo, probablemente en un futuro los dispositivos lo tengan integrado.

3.3.4. Modelo de la infraestructura para la centralización de registros de eventos de seguridad.

Con base en las definiciones de los métodos para satisfacer los requerimientos que debe satisfacer la guía y de las herramientas tecnológicas que ayudan a cumplir con los métodos definidos, se modela la infraestructura de la guía metodológica de acuerdo al esquema de centralización mostrado en la figura 9.

54

Figura 10. Esquema de centralización 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 comunicación entre los clientes y el servidor es orientada a conexión y basada en el protocolo TCP. Esta comunicación tiene la característica de garantizar la integridad de los datos, confidencialidad y autenticación. Estos principios de seguridad son garantizados por medio del túnel SSH. En cuanto a la instauración del túnel 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 satisfacción o falla del proceso de autenticación. 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 túnel y enviarlos para su almacenamiento a una base de datos (mysql) y/o a archivos planos.

55

Para el envío de los registros de eventos de los clientes con sistema operativo UNIX LIKE, se tiene la herramienta syslog-ng. Syslog-ng se comunica vía TCP con un cliente SSH (ssh) de la herramienta Open SSH, y éste cliente SSH se encarga de establecer el túnel 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 actúa recogiendo los logs. Ésta herramienta se comunica vía TCP con el cliente SSH (plink) para Windows y transporta los registros de eventos por medio del túnel SSH hasta el servidor. Los clientes con sistema operativo diferente a Windows o UNIX LIKE, como los dispositivos de red, envían sus registros de eventos por medio de syslog, a un cliente UNIX LIKE. Este transporte se realiza vía UDP y sin ningún mecanismo de integridad, confidencialidad, ni autenticación, por lo cual se debe tener una red alterna, que se utilice únicamente para este transporte y debe ser físicamente altamente protegida.

3.3.5. Métodos utilizados para la satisfacción de los requerimientos de la guía metodológica.

A continuación se muestra la manera en que se abarca cada uno de los requerimientos definidos para la guía metodológica, con la infraestructura definida.

3.3.5.1. Requerimientos funcionales

Los registros de eventos deben quedar en un punto central. Como se observa en la estructura de la metodología, el elemento principal de la guía metodológica 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 polimórfico para su correlación. Este formato debe contener Identificación 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 guía metodológica, 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).

56

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 algún mecanismo de identificación del sistema o tecnología de información que los generó para efectos de su utilización como evidencia digital. A través del protocolo syslog se garantiza que todos los registros de eventos enviados al servidor de logs tengan la información del sistema o tecnología que los generó. Esta información 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.

3.3.5.2. Requerimientos no funcionales

Se debe utilizar un método de transporte confiable: el método de trasporte debe ser orientado a conexión, debe garantizar la integridad de los datos, debe mantener algún mecanismo de autenticación y los datos deben estar cifrados durante el transporte. Este requerimiento es satisfecho por medio de la creación del túnel SSH, a través del cual, viajan los registros de eventos. El protocolo SSH es orientado a conexión. Suministra la privacidad de los datos utilizando algoritmos de cifrado para los datos. Utiliza métodos de autenticación, en éste caso el proceso de autenticación se realizará por medio de llaves públicas y privadas. Y garantiza que los datos que llegan al servidor de logs son los mismos que salieron del origen, por medio de la utilización de algoritmos Hash para la integridad de los datos. Se debe utilizar algún mecanismo de autenticación con respecto al sistema que los generó. El protocolo SSH permite la autenticación del cliente con el servidor. El método definido para realizar la autenticación es por medio de llaves públicas y privadas. Se debe asegurar que no se perdió, ni cambó ningún 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.

57

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 evalúen 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 políticas de procedimientos documentados en los cuales se describa el proceso de elaboración de copias de respaldo. Debe existir un proceso de reducción de datos para el proceso de correlación, mediante compresión 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ó ningún dato en los registros de eventos para su uso como evidencia digital”. Por tal motivo este requerimiento no será tenido en cuenta.

3.4. ESTRUCTURA DE LA GUÍA METODOLÓGICA

La guía metodológica para la gestión centralizada de registros de eventos de seguridad definida pretende llevar al administrador de la red de una pyme a una manera más sencilla y más ágil de analizar y monitorear los registros de eventos generados en la red. La guía procura cumplir con los requerimientos necesarios para realizar una futura correlación de registros de eventos, así como mantener el carácter de evidencia digital de los logs.

3.4.1. Diagrama de flujo de la guía metodológica.

La estructura de la guía metodológica 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 guía metodológica.

58

Figura 11. Diagrama de flujo de la guía metodológica.

3.4.1.1. Sincronización de los relojes de tiempo.

El paso inicial para lograr la centralización de registros de eventos de seguridad, es realizar la sincronización 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 continuación, se realiza la instalación y configuración 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.

59

3.4.1.2. Creación del Túnel SSH.

Tras asegurar que todos los dispositivos de la red tienen sus relojes de tiempo sincronizados, se procede a realizar la creación del túnel 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 túnel desde los clientes. El proceso de creación del túnel depende del tipo de cliente que se vaya a configurar (LINUX, WINDOWS). Para la creación del túnel SSH se debe tener algún mecanismo de autenticación, el mecanismo recomendado por la guía metodológica es por medio de llaves públicas y privadas. Esto con el fin de que el establecimiento del túnel pueda hacerse como un servicio del sistema operativo, y adicionalmente para que la creación del túnel y su proceso de autenticación sea transparente para los usuarios finales. En los sistemas Operativos Windows, para establecer el túnel como un servicio del sistema, es necesaria la creación de una cuenta de usuario en el sistema operativo. Esta cuenta requiere contar con privilegios administrativos. El objetivo de la creación de la cuenta, es poder establecer el servicio en Windows, ya que los servicios deben quedar ligados a una cuenta de usuario.

3.4.1.3. Instalación y creación 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. También existe la posibilidad de almacenarlos de forma duplicada en Bases de datos y archivos planos. Por lo anterior, este paso de la guía metodológica, 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 instalación de MySQL en el servidor de logs. Luego, se debe realizar la creación de la base de Datos de logs y finalmente se debe configurar el pipe, el cual se encargará de realizar la comunicación entre syslog-ng y mysql.

3.4.1.4. Instalación y Configuración de herramientas de envío de eventos.

En el servidor, para la recepción de los registros de eventos de seguridad, antes de la instalación de syslog-ng, es necesario realizar la instalación de la librería Eventlog. Después de esta instalación se procede a instalar y configurar

60

la herramienta syslog-ng, de acuerdo como se muestra en la guía metodológica. [ANEXO 1] A continuación, se debe establecer syslog-ng como un servicio en el servidor, con el fin de que al iniciar el sistema operativo, inicie también el servicio de syslog-ng, sin necesidad de intervención humana. Adicionalmente, en el servidor se debe crear el archivo de configuración 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 configuración se especifica en el ANEXO 1. En Los clientes se debe configurar la herramienta de envío 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.

3.4.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 revisión de los procedimientos de elaboración de copias de respaldo en la pyme. Para esto, se debe evaluar si se tiene un procedimiento que permita periódicamente 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 creación o modificación de una política 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 mínimo la fecha a la que pertenecen, y un identificador.

3.4.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 guía metodológica sugiere realizar auditorias periódicas, en las cuales se evalúe el funcionamiento del sistema.

61

3.4.2. Orden secuencial de pasos para la configuración de la centralización.

La configuración de cada equipo para la centralización de registros de eventos debe cumplir con una secuencia de pasos, los cuales deben ser seguidos estrictamente en el orden descrito a continuación para cada equipo.

3.4.2.1. Secuencia de pasos en la configuración del servidor de logs.

La Figura 11 muestra el diagrama de flujo que describe la secuencia de pasos a seguir para la configuración del servidor.

Figura 12. Diagrama de Flujo para la configuración del servidor

62

3.4.2.2. Secuencia de pasos en la configuración de los clientes UNIX LIKE

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

Figura 13. Diagrama de Flujo para la configuración de los clientes UNIX LIKE

63

3.4.2.3. Secuencia de pasos en la configuración de los clientes WINDOWS

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

Figura 14. Diagrama de Flujo para la configuración de los clientes WINDOWS

64

3.4.2.4. Secuencia de pasos en la configuración de clientes dispositivos de red.

Las Figuras 14 y 15 muestran los diagramas de flujo que describen la secuencia de pasos a seguir para la configuración de los clientes dispositivos de red, así como del cliente UNIX LIKE que recibe sus registros de eventos y los envía al servidor de logs.

Figura 15. Diagrama de Flujo para la configuración de los clientes dispositivos

de red.

65

Figura 16. Diagrama de Flujo para la configuración de los clientes UNIX LIKE, receptores de logs de los dispositivos de red.

La configuración 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 configuración de un cliente UNIX LIKE. Sin embrago en la configuración se Syslog-ng existe una variación, la cual puede ser detallada en la guía metodológica. [ANEXO 1]

3.4.3. Centralización de registros de eventos de herramientas utilizadas en pymes.

Los registros de eventos de las herramientas de seguridad utilizadas en la pyme para la protección informática, tales como Antivirus, AntiSpyware, Firewalls, etc. Deben ser tenidos en cuenta dentro del esquema de centralización.

66

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 algún 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 centralización.

3.4.4. Dependencia de los servicios.

Como se ha mencionado anteriormente, una de las características de la centralización de registros de eventos propuesta por la guía metodológica, es precisamente la transparencia del proceso para el usuario final. Para ello, cada actividad que se realice en el proceso de la centralización 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

67

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 configuración de los servicios y las dependencias en cada sistema operativo, se detalla en la guía metodológica. [ANEXO 1].

68

4. VALIDACIÓN DE LA GUÍA METODOLÓGICA

En el presente capítulo se describe el caso de prueba sobre el cual se realizo la validación de la guía metodológica definida como resultado del trabajo realizado.

4.1. CARACTERÍSTICAS DEL CASO DE PRUEBA.

Para la validación de la guía metodológica se implementa una red que cumpla con las características de una red típica de una pyme en un ambiente controlado. Para este procedimiento se contó con un conjunto de equipos del laboratorio de redes del departamento de Ingeniería de Sistemas de la Pontifica Universidad Javeriana. Los equipos que se disponen para la elaboración 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 características técnicas de los equipos y su función en la red y en el modelo de centralización.

Características técnicas

Sistema Operativo

Función en la red

Elemento del modelo de

centralización Compaq EVO Red Hat Linux Servidor de

logs Servidor de logs

Dell Optiplex Gx 260

Windows XP Host Cliente Windows

Compaq Deskpro

Red Hat Linux Equipo de gestión de logs

Receptor de logs de dispositivo de red.

Dell Optiplex Gx 270

Windows XP Host Cliente Windows

Dell Optiplex Gx 270

Red Hat Linux Host Cliente UNIX Like

Dell Optiplex Gx 270

Red Hat Linux Firewall Cliente UNIX Like

Router Cisco 1800

Cisco IOS Software 1841 v.12,4

Enrutador Cliente dispositivo de red

Tabla 4. Equipos de la red del caso de prueba

69

4.1.1. Diagrama De Red Del Caso De Prueba

El diagrama de red de la figura 18, describe el montaje de red realizado para la ejecución de la validación.

Figura 18. Esquema de Red del caso de prueba

4.2. DEFINICIÓN DE LOS RESULTADOS ESPERADOS.

Tras realizar el seguimiento de la guía metodológica se espera obtener los registros de eventos de los equipos presentes en la red, en un punto central. Para lograr llegar a la centralización deseada se espera que la lista de validación 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 validación del proceso de MySQL en caso, en que no se requiera el almacenamiento en Base de Datos sino en archivos secuenciales.

70

Punto para verificar

Equipo Prueba si no N/A

Clientes Windows XP Rectifique que la hora mostrada a la derecha de la barra de herramientas corresponda con la hora que muestra el servidor de NTP

Clientes Unix Like Rectifique que la hora mostrada en a la derecha de la barra de herramientas corresponda con la hora que muestra el servidor de NTP

Sincronización de los relojes de tiempo.

Clientes Dispositivo de red

Verifique que la hora configurada en el sistema corresponda con la hora mostrada por el servidor de NTP

Establecimiento del túnel SSH

Servidor de logs Ejecute el netstat siguiente comando: –na | grep tcp De esta manera verifique cuantas conexiones hacía el puerto 22 existen. El número existente debe ser igual a la cantidad de clientes que se encuentren en funcionamiento en el momento.

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.

Syslog-ng

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.

Servidor de logs Rectifique que al apagar y volver a iniciar la máquina los servicios de NTP, SSH, Mysql y de syslog-ng se inicien automáticamente

Cliente Windows XP Rectifique que al apagar y volver a iniciar la máquina los servicios de LASSO y PLink se inicien automáticamente

Servicios y dependencias

Cliente Unix Like Rectifique que al apagar y volver a iniciar la máquina los servicios de NTP, SSH, y de syslog-ng se inicien automáticamente

Centralización de registros de eventos

Todos los equipos de la red

Rectifique que en el repositorio de registros de eventos haya logs de todos los clientes.

tabla 5. Lista de validación para la guia metodológica

71

4.3. OBSERVACIONES Y RESULTADOS OBTENIDOS.

Una vez concluido el seguimiento de cada paso de la guía metodológica aplicándolo a la red que simula una red típica de una pyme, se encontraron los siguientes resultados.

• Toda la lista de validación se encontraba con la casilla “si” seleccionada para todos los puntos a verificar. Lo que indica que la guía se siguió correctamente, logrando los resultados esperados.

• La guía metodológica se logró seguir paso a paso de manera secuencial sin tener que retroceder a pasos anteriores, lo que da a entender, que la guía se encuentra correctamente estructurada y entendible.

• Se encontró que la instalación del software requerido para los sistemas UNIX Like se encuentra ligada en lo máximo posible al proceso de instalación estándar del software libre.

• Mediante una captura en un analizador de tráfico, 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 guía metodológica permite centralizar los registros de eventos en una organización de forma transparente para los usuarios finales, pues los servicios inician automáticamente una vez inicie el sistema operativo.

• Se observa, que después de seguir la guía metodológica, se logra centralizar los registros de eventos de seguridad de los dispositivos presentes en la red. Siendo la guía metodológica útil para el proceso de gestión de registros de eventos.

5. CONCLUSIONES

Durante el tiempo de desarrollo del trabajo se logró definir y validar una guía metodológica para la gestión centralizada de registros de eventos de seguridad de red, la cual puede ser utilizada en organizaciones de pequeña y mediana escala. La definición de la guía metodológica se consiguió por medio de la apropiación de la teoría asociada a la gestión y centralización de eventos de seguridad, de donde se obtuvieron los requerimientos que debía satisfacer la guía. Con base a estos requerimientos, se definió la infraestructura para la gestión centralizada que los satisficiera. Finalmente, se llegó a la implantación de la infraestructura, definiendo así la guía metodológica, la cual fue validada en un ambiente de pruebas. Durante el desarrollo del trabajo, se obtuvieron las conclusiones y resultados que se describen a continuación: • La centralización de registros de eventos de seguridad es un tema

actualmente muy inquietante en el ámbito de la seguridad informática y de la auditoria, pues facilita la gestión de los registros de eventos de seguridad en las compañías, ahorrando costos de tiempo y esfuerzo de los administradores de la red.

• Aunque se tiene conocimiento de guías o procedimientos para la centralización de registros de eventos, no se conoce ninguna que cumpla con las características de seguridad requeridas para conservar el carácter de evidencia digital de los registros de eventos de seguridad y que contemple al tiempo sistemas operativos diferentes.

• Existen herramientas tecnológicas que permiten la centralización de registros de eventos de seguridad, sin embargo son de precios demasiado elevados, y generalmente no se encuentran al alcance de una compañía de pequeña o mediana escala, por lo que la guía metodológica desarrollada es de un aporte altamente valioso para las pymes.

• El conocimiento en cuanto a la tecnología obtenida en las pymes y al nivel de seguridad informática que se tiene en las compañías de escala pequeña y mediana en Colombia, es demasiado limitado. Las entidades que tienen como objetivo estudiar y apoyar a las pymes, no tienen estudios públicos en el tema.

• En la definición de los requerimientos que debería satisfacer la guía metodológica, se encuentra que dos de ellos se contradicen entre sí. Al tratar de reducir los registros de eventos por medio de la compresión, borrado o filtrado no se estaría cumpliendo con el principio de suficiencia o completitud de los datos para la evidencia digital.

• Durante la etapa de estructuración de la guía metodológica, se encontró la dificultad recolectar los registros de eventos generados por herramientas

diseñadas en Windows, ya que no se rigen ningún estándar tal como lo hacen las herramientas para UNIX con syslog.

• Al realizar el análisis de la información de la seguridad informática en las pequeñas y mediana empresas, se encontró que es un tipo de información muy resguardado lo cual es considerado correcto, pues de esta manera se evitan ataques de ingeniería social

• Con el proceso de validación de la guía se encontró que la guía metodológica es una herramienta que lleva al administrador de la red a realizar de forma segura la centralización de los registros de eventos de seguridad, cumpliendo con los requerimientos definidos.

6. TRABAJOS FUTUROS

A partir del trabajo realizado se deduce que estándares como syslog necesitan ser actualizados agregándoles aspectos de seguridad directamente en el estandar. Asi como definir estándares en necesario que los dispositivos y las herramientas incluyan en su diseño la implementación de estos estándares, para su integración en infraestructuras como esta. Un trabajo futuro propuesto es el desarrollo de una guía que implemente también con herramientas de software libre como OSSIM el proceso de analisis y correlación de los eventos centralizados. También se sugiere la implementación de la guía 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.

7. BIBLIOGRAFIA

[1] TORRES, Juan Carlos. RONDÓN, Richard García. “Control, Administración E Integridad De Logs”. http://www.criptored.upm.es/guiateoria/gt_m248h.htm [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, Nicolás. “Modelo de Gestión de Seguridad con Soportes a SNMP”. Pontificia Universidad Javeriana, Junio de 2005. [8] FLOREZ, Diego Andrés – Londoño, Leonardo Eduardo. “Monitoreo y Control de Componentes de Red, Sobre Protocolo SNMP”. Pontificia Universidad Javeriana, Octubre de 2005. [9] CRESPO, Joaquin, “Correlación 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 in Security”, 2004. http://www.securitydocs.com/library/2270 [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 González José Alejandro, Certain Jaramillo Andrés Felipe. Evidencia Digital: contexto, situación e implicaciones nacionales. Abril de 2005. http://derecho.uniandes.edu.co/derecho1/export/derecho/descargas/texto/NasTecnologias6.pdf [19] Cano Martines Jeimy José. Admisibilidad de la Evidencia Digital: Algunos Elementos de Revisión y Análisis. Agosto de 2003. http://www.alfa-redi.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 Prácticas en la Administración de la evidencia digital”. 2006 [22] SERRANO G, Maria Isabel. “Fundamentos de Criptografía”. http://ainsuca.javeriana.edu.co/seginfor/. Consultado Abril de 2006. [23] GÓMEZ, Nelson. “Soluciones de seguridad”. http://ainsuca.javeriana.edu.co/seginfor/. Septiembre de 2005. Consultado Abril de 2006. [24] Noel, “Clasificación y tipos de ataques contra sistemas de información”, http://ww.delitosinformaticos.com [25] GARZÓN, Daniel. RATKOVICH, Juan Carlos. VERGARA, Alejandro. “Metodología de análisis y vulnerabilidades para empresas de media y pequeña escala en la ciudad de Bogotá”. Febrero de 2005. [26] McDowell, Mindi. “Understanding Denial-of-Service Attacks”. http://www.us-cert.gov/cas/tips/ST04-015.html [27] RAFAIL, Jason. “Cross-Site Scripting Vulnerabilities”. http://www.cert.org/archive/pdf/cross_site_scripting.pdf [28] SERRANO, Maria Isabel. “Seguridad en redes y Técnicas Hacking”. 2005.

[29] “Seguridad en la red: identificación de perímetros de red SMB”, Centro de Información 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”. Presentación 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 solución a muchos problemas”. iWorld – IDG España. 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. “Ingeniería 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. “Instalación y configuración de NTP”. http://www.arcert.gov.ar. Agosto de 2006 [38] AKIN Thomas. “Hardening Cisco Routers”. Febrero de 2002. http://www.oreilly.com/catalog/hardcisco/chapter/ch10.html [39] IETF RFC 1305, http://www.ietf.org/rfc/rfc1305.txt. [40] IETF RFC 2030, http://www.ietf.org/rfc/rfc2030.txt. [41] SSH Communications Security. http://www.ssh.com/ [42] BARRELT, Daniel J. SILVERMAN, Richard. BYRNES, Robret G. “SSH. The Secure Shell – The Definitive Guide”. O’Reily. 2005. [43] IETF RFC 739, http://www.free.lp.se/fish/rfc.txt [44] Open SSH. Noviembre de 2006. http://www.openssh.com/

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

8. ANEXOS

ANEXO 1: Remítase al documento “Guía Metodológica para la Gestión Centralizada de registros de eventos de seguridad en Pymes”