Alejandro sierra munera pontificia universidad javeriana facultad de ingenieria



Descargar 296.24 Kb.
Página1/5
Fecha de conversión11.01.2017
Tamaño296.24 Kb.
  1   2   3   4   5
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


2.INTRODUCCION 12

3.DESCRIPCIÓN EL PROBLEMA 12

4.OBJETIVOS DE LA INVESTIGACIÓN 12

5.ALCANCE DE LA INVESTIGACIÓN 13

6.MARCO TEÓRICO 15

7.METODOS DE TRANSPORTE 15

7.1.1.Syslog 15

7.1.2.SNMP 20

8.CORRELACION DE REGISTROS DE EVENTOS DE SEGURIDAD 23

8.1.1.Requisitos para la correlación 23

8.1.2.Eventos, Incidentes y Eventos Compuestos 23

8.1.3.Tipos de Correlación 25



9.COMPUTACIÓN FORENSE Y EVIDENCIA DIGITAL 27

9.1.1.Computación Forense 27

9.1.2.Evidencia digital 27

10.PROTECCIÓN DE INFORMACIÓN Y HERRAMIENTAS DE SEGURIDAD 31

10.1.1.Seguridad física 31

10.1.2.Seguridad lógica 32

10.1.3.Protección 32

10.1.4.Inversión 35

11.CLASIFICACIÓN Y TIPOS DE ATAQUES INFORMÁTICOS 36

11.1.1.Vulnerabilidad 36

11.1.2.Amenazas y ataques 37

12.SINCRONIZACION DE RELOJES DE TIEMPO 39

12.1.1.Arquitectura del sistema 40



13.SSH 41

13.1.1.Arquitectura de SSH 41

13.1.2.Características de SSH. 43

13.1.3.Usos comunes de SSH 44



14.DESARROLLO DEL PROYECTO 45

15.RED TIPICA DE UNA PYME. 46

15.1.1.Tamaño de una Pyme 46

15.1.2.Características de una red típica de una PyME 47

16.REQUERIMIENTOS PARA LA GESTION CENTRALIZADA DE LOS REGISTROS DE EVENTOS DE SEGURIDAD 49

16.1.1.Requerimientos funcionales 49

16.1.2.Requerimientos no funcionales 50

16.1.3.Diagrama de Red típica de una Pyme. 50



17.DEFINICIÓN DE INFRAESTRUCTURA 52

17.1.1.Definición del método de sincronización de relojes de tiempo. 52

17.1.2.Definición del método de transporte 52

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

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

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



18.ESTRUCTURA DE LA GUÍA METODOLÓGICA 59

18.1.1.Diagrama de flujo de la guía metodológica. 59

18.1.2.Orden secuencial de pasos para la configuración de la centralización. 63

18.1.3.Centralización de registros de eventos de herramientas utilizadas en pymes. 67

18.1.4.Dependencia de los servicios. 68

19.VALIDACIÓN DE LA GUÍA METODOLÓGICA 70

20.CARACTERÍSTICAS DEL CASO DE PRUEBA. 70

20.1.1.Diagrama De Red Del Caso De Prueba 71



21.Definición de los resultados esperados. 71

22.observaciones Y RESULTADOS OBTENIDOS. 73

23.CONCLUsIONES 74

24.TRABAJOS FUTUROS 76

25.BIBLIOGRAFIA 77

26.ANEXOS 81



LISTA DE TABLAS


Tabla 1. Facilidades y su código numérico respectivo 16

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

Tabla 3. Característica de los Métodos de transporte 53

Tabla 4. Equipos de la red del caso de prueba 70

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

LISTA DE FIGURAS



Figura 1. Estructura de mensajes SNMP 21

Figura 2. Interrupción [28] 37

Figura 3. Intercepción [28] 38

Figura 4. Modificación [28] 38

Figura 5. Fabricación [28] 39

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

Figura 7. Esquema de distribución de SSH 42

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

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

Figura 10. Esquema de centralización de logs. 56

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

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

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

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

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

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

Figura 17. Diagrama de Dependencias de los Servicios 68

Figura 18. Esquema de Red del caso de prueba 71



  1. INTRODUCCION

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



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


  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.

      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.


        1. Mensaje Syslog

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




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




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




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




    • 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 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]



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




        1. Evoluciones de syslog
  1   2   3   4   5


La base de datos está protegida por derechos de autor ©bazica.org 2016
enviar mensaje

    Página principal