Printer Friendly

Sistema multi-agente deliberativo para la obtencion y analisis de datos en Honeynets.

Deliberative multi-agent system for data collection and analysis in Honeynets

Sistema multi- agente deliberativo para a obtencao e analise de dados em Honeynets.

I. INTRODUCCION

Las plataformas de prevencion de intrusiones basan su funcionamiento en la comparacion del evento registrado contra un sistema de informacion, plataforma o cualquier componente que este conectado a una red de datos, con firmas previamente identificadas; de esta manera pueden llegar a determinar si una accion que se realiza contra un sistema puede categorizarse como un posible evento malicioso. El entorno en el cual se identifican los eventos maliciosos y se generan las firmas correspondientes, es normalmente un ecosistema computacional vulnerable, donde, mediante la utilizacion de una arquitectura de referencia como es el proyecto HoneyNet (2), implementan un tipo especifico de HoneyPot (3), exponiendo, en internet, los entornos vulnerables para identificar los diferentes comportamientos de atacantes, los componentes de software que lanzan, los pasos que ejecutan y como logran acceder o extraer informacion de este sistema. El nucleo de esta propuesta se centra en la implementacion de una HoneyNet basada en agentes inteligentes con capacidad de deliberacion para aproximar la identificacion de nuevos patrones.

El articulo se compone de la definicion del problema, la justificacion del proceso y los requerimientos, la metodologia utilizada para el desarrollo del proyecto y la implementacion del modelo con los resultados obtenidos.

II. ESTADO DE LA CUESTION

En la actualidad las empresas tienen desplegadas sus plataformas en redes publicas, de manera transparente o a traves de capas medias de seguridad. Para que una entidad pueda llegar a identificar de manera eficiente -a traves de un software o plataforma- eventos maliciosos depende en gran medida de que la fuente de conocimiento que lo alimente este actualizada, en la mayoria de los casos, funcionan a partir de firmas que describen e identifican eventos maliciosos. La captura de estas firmas puede llevarse a cabo dentro de una red HoneyNet, un tipo especifico de HoneyPot de alta interaccion, que expone maquinas vulnerables y componentes especificos que permiten la captura y analisis del comportamiento de atacantes. El proyecto HoneyNet define una arquitectura o diseno de referencia para su implementacion, dicha arquitectura inicial se define de la siguiente forma en la figura 1:

[FIGURA 1 OMITIR]

El diseno anterior esta concebido para ser un sistema centralizado con un unico punto de adquisicion de datos, esto significa que:

* El limite en la captura de nuevos patrones estaria en un solo elemento, implicando un porcentaje realmente bajo de captura de ataques conocidos y desconocidos.

* Habria una unica arquitectura implementada y por consiguiente un unico objetivo estructurado.

* Se tendria un unico objetivo dentro de millones de maquinas reales y vulnerables.

* El acceso a los datos recolectados seria limitado.

Debido a lo anterior, el uso de un sistema multi-agente como base fundamental del sistema distribuido permite que estos, a diferencias de arquitecturas distribuidas tradicionales, tengan un comportamiento basado en su entorno, establecidos en una semantica de comunicacion y en sus caracteristicas principales, donde todos trabajan para cumplir un objetivo, en este caso, extraer informacion de diferentes fuentes usando la misma semantica y deliberar sobre los datos obtenidos para la posible identificacion de atacantes.

El boletin de seguridad de Kaspersky 2014" muestra que los ataques tienden a incrementarse. Basandose en la comparacion con el ano previo, algunas estadisticas son:

* 6,167,233,068 ataques fueron detectados y neutralizados.

* 38% de usuarios fueron objetivo de un ataque web al menos 1 vez en el ano.

* 1,910,520 intentos de lanzamiento de aplicaciones maliciosas de bancos en las maquinas de usuarios fueron neutralizados.

* 1,432,660,467 ataques fueron lanzados desde recursos en linea [2].

Lo anterior ha permitido que surjan iniciativas como el proyecto HoneyNet, que ademas de definir los lineamientos para implementar, de la mejor forma una arquitectura para la investigacion de ataques y obtencion de firmas, trata de contribuir en la identificacion de nuevos eventos o elementos maliciosos para que puedan ser prevenidos mediante el uso de Sistema de Deteccion de Intrusiones (IDS). Este tipo de iniciativas, ha planteado soluciones que permiten la captura de eventos dentro de una unica red vulnerable y controlada, ademas, han sido concebidas de manera centralizada, limitando en gran medida la cantidad de eventos capturados, siendo estas de por si, excelentes alternativas.

Debido a que los IDS estan pensados para estar centralizados en una sola estacion, lo cual es una gran limitante de los mismos, se han propuesto soluciones basadas en sistemas distribuidos. Los principales problemas de utilizar arquitecturas tradicionales son [3]:

* La consola central tiende a ser un solo punto de fallo, en tal sentido, la red entera esta sin proteccion si esta falla.

* La escalabilidad es limitada. Procesar toda la informacion en un nodo implica un limite en el tamano de la red que puede monitorizar.

* Se evidencian dificultades en reconfigurar o anadir capacidades y firmas a los IDS.

* El analisis de los datos de la red puede ser defectuoso, debido a su arquitectura centralizada, durante un periodo de fallo, los datos capturados pueden llegar a ser defectuosos o presentar perdida de paquetes.

Asi pues, la propuesta del uso de un sistema multi-agente como base fundamental del sistema distribuido, permite que estos, a diferencias de arquitecturas distribuidas tradicionales, tengan un comportamiento basado en su entorno, establecidos en una semantica de comunicacion y en sus caracteristicas principales, donde, todos trabajan para cumplir un objetivo, en este caso, extraer informacion de diferentes fuentes usando la misma semantica y deliberar sobre los datos obtenidos para la posible identificacion de atacantes.

A continuacion se presentan algunos de los trabajos mas significativos que se han realizado en el desarrollo de sistemas multi-agentes y la seguridad informatica.

Una de las areas en las que se ha venido trabajando es en la visualizacion de la informacion de grandes volumenes de datos de HoneyNets dentro de una red comprometida, la cual es visualizada usualmente por elementos de monitoreo mostrando patrones en el trafico [4]. Tambien se ha trabajo en modelos que permiten dar proyeccion para visualizar los datos de trafico [5]. Estudios en los que se demuestra la importancia de las HoneyNet en la seguridad informatica, una vez analizadas las definiciones mas comunes, la planificacion, implementacion y casos de prueba para la implementacion de una HoneyNet se pueden evidenciar en [6]; al igual, como la recopilacion de datos de estas y la aplicacion de tecnicas de mineria de datos han dado como resultado nuevas reglas asociadas a datos historicos o estructuras especificas a ser utilizadas por IDS o Firewalls [7]. Los lineamientos y guias del proyecto HoneyNet han sido definitivos en la concepcion de una arquitectura centralizada y suficientemente robusta, para realizar la implementacion de HoneyNets, que sea un elemento fundamental dentro del macro de la seguridad informatica [8]. El uso de sistemas multi-agente para la reduccion de falsas alarmas dentro de sistemas de deteccion de intrusos [9] o el aumento de la atencion a atacantes para que accedan a la red HoneyNet [10] son puntos que se han trabajado, sin embargo, tienen focos diferentes en cuanto a que ninguno centra sus esfuerzos en la deteccion de nuevos patrones o extraccion distribuida de datos. Tambien se ha trabajado en el uso de un sistema multi-agente, con la inclusion de un sistema de razonamiento basado en casos asentado en creencias, deseos e intenciones para la deteccion y clasificacion de ataques a partir de la tecnica de deteccion anomala [11] o en la utilizacion de un sistema multi-agente que se encarga de remover procesos maliciosos y archivos ejecutables de servidores, protegiendo la red de posibles ataques 0-day [12].

Iniciativas mas recientes como [13] y [14] evidencian una taxonomia de HoneyNets basada en sistemas de razonamiento adaptativo que permiten clasificar y deliberar sobre algunos casos de redes senuelo. En [15] se presenta un sistema basado en deliberacion usando JColibri, no obstante, sobre una arquitectura de un solo nodo y no como un entorno distribuido que conforme una HoneyNet. En [16] y [17] se proponen clasificaciones de eventos de ataques basados en sensores HoneyNets y en [18] un analisis de redes senuelo basada en tecnicas de reconocimiento de patrones.

En terminos generales los proyectos e investigaciones homogeneos concentran sus esfuerzos en la identificacion de ataques en diferentes momentos, componentes y capas, obteniendo o capturando paquetes a nivel de red para su procesamiento, pero no han buscado nuevos patrones de ataque dentro de los ya existentes, teniendo en cuenta que un evento por si mismo no necesariamente identifica un vector de ataque.

III. MATERIALES Y METODOS

El proceso que se siguio para realizar la implementacion de todo el proyecto se apoyo en tres aristas: en la primera se conceptualizo como el problema, se identifico la solucion y se expresaron un conjunto de requerimientos; la segunda trata de garantizar el correcto modelamiento de los componentes de software y hardware necesarios para obtener un entorno completo y cumplir con la solucion; la tercera surge para garantizar el desarrollo organizado de cada uno de los programas o componentes de software necesarios.

Para alcanzar el modelamiento correcto, se utilizo UPSAM (4) como metodologia de Ingenieria de Software de Agentes, que enmarca el proceso de analisis de sistemas multi-agentes en el paradigma del modelado de agentes y permite alinearlo al proceso de diseno de RUP (5).

Se ha hecho uso de esta metodologia para la realizacion de un analisis y diseno organizado de un sistema orientado a agentes, contextualizandola en el uso de algunos procesos de RUP (Proceso Unificado de Rational), orientados al desarrollo de agentes, dirigido por casos de uso y centralizado en la arquitectura. A continuacion se muestran algunos modelos asociados a UPSAM:

* Modelo de tareas: servicios, tareas, objetivos y funcionalidades asociados a roles. Este modelo normalmente se expresa a traves del uso de casos de uso orientado a agentes.

* Modelo de arquitectura de la organizacion de agentes: descripcion de agrupacion de los agentes y sus relaciones. En este modelo es normal la utilizacion de un diagrama general de actividades acompanado de la especificacion de responsabilidades, propositos, percepciones, tareas y salidas.

* Modelo de agentes: descripcion de agentes a instancias, comportamiento y como realizar el control especificado, en este modelo es comun la utilizacion de diagramas de clases basados en los conceptos claves de los roles asociados a los agentes.

* Modelo de comunicacion de agentes: descripcion de la secuencia de interaccion entre los diferentes tipos o roles, este modelo es normalmente especificado a traves de diagramas de secuencia [19].

Teniendo un modelamiento correcto que apoya directamente el diseno de la plataforma, se adapto PSP60, que permite de manera individual un seguimiento al proceso de desarrollo, determinando entregables basicos, metricas y elementos de seguimiento. Se han explicado las diferentes fases del proceso PSP en su version cero, al igual que los artefactos asociados a cada etapa [20]. Para el desarrollo de este proyecto se opto por la division del proyecto en micro-desarrollos, acorde a lo expuesto para proyectos mas extensos [21].

A. Especificacion de requerimientos El esquema de especificacion, se compone de:

* Rol: define que rol bajo el sistema es el interesado en el cumplimiento o logro de una necesidad especifica.

* Necesidad: la definicion de que se espera lograr con la implementacion de un punto especifico.

* Objetivo: lo que se desea lograr u obtener posterior a la implementacion.

* Criterio de la aceptacion: los elementos que se esperan obtener una vez se realiza la implementacion y que garantizan que se esta logrando el objetivo de la misma.

Algunos ejemplos de como se realizo el plasmado de estos son:
TABLA I
ESPECIFICACION DE REQUERIMIENTOS DEL PROYECTO

Rol        Necesidad                     Objetivo

Usuario    Obtener los posibles          Generar y alimentar
           ataques que se detectan       la base de casos
           en la red

Usuario    Identificar de cada ataque    Generar y alimentar
           la IP origen, la IP           la base de casos
           destino, el evento
           asociado y la ocurrencia

Usuario    Tener una aplicacion          Garantizar de manera
           liviana, desacoplada de       masiva su implementacion
           la arquitectura del SO        para la obtencion de
           que permita a consultar       vectores de ataque
           los ataques y obtener         geograficamente
           los campos especificados      distribuidos

Rol        Criterios de Aceptacion

Usuario    1. Consulta SQL eficiente
           2. SQL preciso al esquema utilizado por SNORT7
           3. SQL que permita realizar la consulta asociada

Usuario    1. Consulta SQL eficiente
           2. SQL preciso al esquema utilizado por SNORT
           3. SQL que permita realizar la consulta asociada

Usuario    1. Aplicacion Java
           2. Ejecucion de la aplicacion con una maquina
           virtual estandar en un sistema operativo Windows
           3. Ejecucion de la aplicacion y visualizar la
           consulta de datos
           4. Ejecucion de la aplicacion y busqueda
           de servicio de construccion de casos


B. Diseno

Las caracteristicas asociadas de autonomia, reactividad, proactividad, movilidad, inteligencia, entre otras, sugieren y sustentan la necesidad de dividir, de manera sistemica, los diferentes actores que interactuan con las diferentes capacidades asociadas a los agentes. Lo anterior soporta la interaccion compleja entre los diferentes agentes para lograr un objetivo comun. El diseno asociado de los agentes que intervienen en la plataforma y sus responsabilidades, se presenta en la Tabla II:
TABLA II

RESPONSABILIDADES DE LOS AGENTES

Agente                      Responsabilidades

Poller      Se encarga de sensar y obtener paquetes capturados
           previamente por el ambiente dentro de la HoneyWall.
            Este agente es clonado y distribuido dentro de las
            diferentes HoneyWalls, registrandose en cada caso
                           en las YellowPages.

Builder       Se encarga de sensar y recibir la informacion
              referente a posibles ataques o comportamientos
             anormales identificados previamente por agentes
             Pollers, ademas, notifica al agente deliberador
               sobre nuevos datos. Este agente es clonado y
               distribuido de manera estrategica de acuerdo
                a la carga y posicion geografica asociada

Maa-UI        Se encarga de sensar y recibir notificaciones
              sobre nuevos ataques procesados por el agente
               Builder. Tambien se encarga de controlar la
              interaccion entre el UI y la logica propia del
               agente, deliberar y persistir nuevos casos.
                El agente encargado de la deliberacion es
                       lanzado desde el UI de este.


La arquitectura general planteada para la implementacion de la plataforma MAS+CBR se definio en 4 niveles, con opcion de escalabilidad horizontal de manera transparente, como se presenta en la Figura 2, el comportamiento de los agentes asociados, se describe como:

* Agente Maa-Ui o Sistema de razonamiento y gestor de conocimiento.

* Interfaz de usuario que permite la gestion y configuracion del CBR.

* Elementos de negocio que garantizan la interaccion hacia los demas componentes.

* Elementos de integracion con otras plataformas y componentes.

* Elementos de persistencia que trabajan hacia la base de datos.

Agente Builder o constructor y procesador de datos.

* Elementos propios de la definicion del agente.

* Elementos de negocio que garantizan la interaccion con otros componentes.

* Elementos y servicios comunes a los agentes.

Agente Poller o extractor de datos.

* Elementos propios de la definicion del agente.

* Elementos de negocio que garantizan la interaccion con otros componentes.

* Elementos y servicios comunes a los agentes.

El comportamiento deliberativo asociado al agente Maa-Ui se diseno basado en un CBR (Case Base Reasoning) asi:

a. RETRIEVE u obtencion, esta fase se encarga de obtener casos previos de la base de conocimiento, acorde a la configuracion base realizada. En este punto la fuente de datos ha sido el esquema propio del IDS, el cual fue consultado por el agente extractor y entregado para su procesamiento a un agente constructor.

b. REUSE o reutilizacion, con base a la informacion obtenida se revisa y plantea una propuesta de solucion al problema dado. Dentro de la obtencion de los resultados se realizo una configuracion base de parametros de peso y similitud para su comparacion con la base de conocimiento obtenida del IDS, esto da como resultado un posible escenario que resuelve el problema planteado dentro de la busqueda de nuevos comportamientos o vectores de ataque.

c. REVISE o revision, se realiza una aprobacion del planteamiento de solucion. En este punto los casos obtenidos y acordes al planteamiento de la hipotesis del proyecto, son aprobados de manera automatica, no siendo esto una condicion de fondo, siendo posible crecer en la revision.

d. RETAIN o retencion, se almacenan los casos que se consideran utiles.

[FIGURA 2 OMITIR]

En la fase de Reuse, el agente deliberativo se encarga de clasificar los nuevos escenarios con base en los previamente obtenidos de la base de conocimiento, para lo cual, utiliza el algoritmo KNN:

[FIGURA 3 OMITIR]

Del comportamiento que se presenta en la grafica se pude concluir que la configuracion x definida previamente, se encuentra acorde a la proximidad cerca de los elementos a, b y c, siendo estas, posibles tipificaciones para la misma, sin embargo y debido a la cantidad de elementos cercanos se clasifica como (a). La configuracion que se usa para la propuesta se basa en los siguientes elementos, definidos previamente en el modelo de dominio:

* IP Origen

* Ip Destino

* Alertas

** Identificacion de Alertas

** Ocurrencias

** Fecha

Durante el proceso de ejecucion del algoritmo KNN, las funciones de similitud son criticas en la comparacion, en este caso, se realizo la implementacion de una funcion especifica de comparacion, asi:

Sea A = {Alerta 1, Alerta 2, ..., Alerta n} (1)

Sea B = [Alerta 1,Alerta 2, ... Alertan] (2)

Donde A son las alertas asociadas a patrones de ataques ya identificados y B un nuevo patron configurado:

A [interseccion] B = [Alerta 1, Alerta 3] (3)

La interseccion de los conjuntos define los elementos comunes a ambos, por consiguiente, si n es el total de elementos del conjunto A y m es el total de elementos del conjunto resultante de la interseccion

A [interseccion] B = [Alerta 1, Alerta 3] (3)

Siendo SV el resultado de similitud y realizando una aproximacion sobre el valor del resultado.

C. Implementacion

El desarrollo de la plataforma sesga su operacion en la extraccion de datos de una HoneyNet, esta se encuentra implementada bajo un esquema de virtualizacion basico que involucra los siguientes elementos:

1) Maquina Atacante: esta maquina virtualizada con el unico objetivo de servir como host atacante, desde el cual se realizarian ataques a maquinas vulnerables dentro del laboratorio.

2) HoneyWall: esta maquina fue virtualizada para que actuara como un punto de captura centralizada dentro de la red de posibles ataques, su objetivo es permitir el control de los datos de entrada que pueden indicar un ataque, capturar estos datos, analizarlos y permitir herramientas para analizarlos.

3) Maquina(s) Atacante(s): VM (Virtual Machines) para representar una o varias maquinas vulnerables, desde su sistema operativo hasta las aplicaciones que corren.

Con la implementacion a nivel de hardware virtualizado, se desarrollo el sistema multi-agente, modelado en la figura 4.

[FIGURA 4 OMITIR]

Los eventos relevantes que son identificados y transcritos a representaciones JSON para ser enviados al agente disponible, cuentan con la siguiente estructura:

[ILUSTRACION OMITIR]

El Agente Poller es el encargado de realizar la consulta y el envio de los datos a los agentes builder que se encuentran disponibles:

[FIGURA 5 OMITIR]

[FIGURA 6 OMITIR]

Una vez el agente Builder recibe la informacion, la procesa y almacena en la estructura especifica de la plataforma. Para que el agente deliberativo inicie su proceso, el agente builder le notifica el Mensaje ACL. La interaccion base se puede resumir en la siguiente figura, capturada a traves del agente sniffer dentro framewok JADE:

[FIGURA 7 OMITIR]

* Tanto el agente Builder como el Agente Poller se registran en las paginas amarillas ofreciendo servicios especificos.

* Entre los agentes se inicia una interaccion, donde el agente Poller solicita al agente Builder encontrado el procesamiento de la informacion, una vez acepta, esta es recibida y procesada.

El agente Maa-ui, una vez configurado, esta pendiente de la recepcion de nuevos eventos, para esto, el agente builder una vez procesa un segmente de informacion, realiza la notificacion necesaria.

III. RESULTADOS

Con la ejecucion del SMA (Ver Figura 8), se dio una aproximacion al fortalecimiento de los metodos de extraccion de informacion de diferentes entornos en el marco de la seguridad, basada en redes senuelo, siguiendo los lineamientos del proyecto HoneyNet y el nucleo de eventos fuera la misma, logrando una solucion no intrusiva pero si dependiente. La ejecucion del prototipo, como se puede observar en la Figura 9, presenta una tasa de precision --de deteccion--viable (Ver Tabla III); que puede sesgarse por las funciones de similitud; en este caso las asociadas a los eventos de la la configuracion para detectar nuevos vectores de ataque se basa en el algoritmo KNN y el modelo CBR confiable (Ver tabla IV).

[FIGURA 8 OMITIR]

En la tabla IV se muestra el comportamiento de los patrones detectados.

En la figura 9, se presenta el resultado de deteccion correcta e incorrecta de nuevos casos

[FIGURA 9 OMITIR]

El comportamiento anterior muestra una alta asertividad en las configuraciones de clasificacion, donde los atributos son cadenas de texto fragmentadas; con un comportamiento diferente en el momento que se utiliza la funcion de configuracion asociada al listado de alertas, donde se utilizo la interseccion de los objetos sin especificar el detalle de la comparacion.

IV. CONCLUSIONES

Con la implementacion del sistema multi-agente se lograron identificar diferentes tipos de vectores de ataques e informacion anomala, con una base de conocimiento previamente cargada a partir de eventos de diferentes entornos, con una deliberacion acertada de nuevos patrones de intrusion. El sistema multi-agente deliberativo se baso en la implementacion de un CBR encargado del razonamiento de los agentes, sin embargo, las funciones de comparacion que se desarrollaron han tenido en algunos casos, comportamientos no acertados al momento de realizar la ejecucion del algoritmo de clasificacion, por lo cual, la optimizacion deberia aumentar la capacidad de deliberacion correcta tanto de vectores de ataque como de informacion anomala.

Si bien la implementacion de un algoritmo de aprendizaje supervisado como es CBR con un algoritmo de clasificacion KNN para obtener un resultado de deliberacion sobre informacion recolectada presento un comportamiento aceptable; dependia de una buena base de conocimiento, que para este caso, no estaba afinada en un porcentaje superior al 80% y reduciendo los falsos positivos, generando en algunos casos falsas deliberaciones sobre nuevos vectores de ataque y datos anomalos.

Recibido Noviembre 10 de 2015--Aceptado Mayo 30 de 2016

REFERENCIAS

[1] HoneyNet Project, "Know your enemy: HoneyNets. Honeynet Project" 2006. Disponible en: http://old.honeynet.org/papers/honeynet/

[2] M. Garnaeva, V. Chebyshev, D. Makrushin, R. Unuchek, A. Ivanov, "Kaspersky Security Bulletin 2014. Overall statistics for 2014" Securelist, 8, Dic.2014. Disponible: https://securelist.com/analysis/ kaspersky-security-bulletin/68010/kaspersky-security-bulletin-2014overall-statistics-for-2014/

[3] Isaza, G. Castillo, AG., et al. "Towards Ontology-Based Intelligent Model for Intrusion Detection and Prevention". En: Estados Unidos Journal Of Information Assurance And Security ISSN: 1554-1010 ed: v.5 fasc.2 p.376--383 ,2010

[4] R.A. Becker, S.G. Eick, and A.R. Wilks, "Visualizing Network Data,"IEEE Transaction. Visualization and Computer Graphics, vol. 1, no.1, pp. 16-28, Mar. 1995.

[5] A. Alonso, S. Porras, E. Ezpeleta, E. Vergara, I. Arenaza, R.

Uribeetxeberria, and E. Corchado, "Understanding Honeypot Data by an Unsupervised Neural Visualization,"Springer Berlin Heidelberg. Computational Intelligence in Security for Information System 2010, vol. 85, pp. 151-160,2010.

[6] C. Doring, "Improving network security with Honeypots, Honeypots Project'Tesis de Maestria dirigida por Dr. Heinz-Erich Erbs,Universidad Wisconsin- Platteville. Darmstadt. 2005.

[7] J. Yin, G. Zhang, andY-Q. Chen, "Intrusion discovery with data mining on Honeynet", 2003 International Conference Machine Learning and Cybernetics", pp.41-45,2-5 Nov. 2003.

[8] G. Rammidi, (2010). "Survey on Current Honeynet research". Disponible: http://honeynetproject.ca/files/survey.pdf

[9] B. Khosravifar, M. Gomrokchi, and J. Bentahar, "A Multi-AgentBased Approach to Improve Intrusion Detection Systems False Alarm Ratio by Using Honeypot," International Conference on Advanced Information Networking and Application, pp.97-102, 2009.

[10] H. Wang, H andQ. Chen, Q, "Design of Cooperative Deployment in Distributed Honeynet System,"14th International Conference on Computer Supported Cooperative Word in Design (CSCWD), pp.711716,2010.

[11] A. Herrero and E. Corchado, "Multiagent System for Network Intrusion Detection," Computational Intelligence in Security for Information System, pp.143-154, 2009. Springer Berlin Heidelberg.

[12] I.S. Kim andM.H. Kim, "Agent-Bases Honeynet Framework for Protecting Server in Campus Networks,"Information Security, IET, vol. 6, no. 3, pp-202-211, 2012.

[13] Fan, W., Du, Zhihui, Fernandez, D. Taxonomy of Honeynet Solutions. Conference: SAI Intelligent Systems Conference (IntelliSys), At London, United Kingdom. 2015

[14] Pauna, A.,Patriciu, V. CASSHH--Case Adaptive SSH Honeypot. Recent Trends in Computer Networks and Distributed Systems Security Volume 420 of the series Communications in Computer and Information Science pp 322-333. 2014

[15] Zakaria, WZ, Kiah, LM. Implementing a CBR Recommender for Honeypot Configuration using jCOLIBRI. Conference Paper. Conference: 3rd International Conference on Computer Science and Computational Mathematics (ICCSCM 2014). 2014

[16] Kacha, P: IDEA: Classification of security events, their participants anddetection probes, in WSEAS TRANSACTIONS on COMPUTERS, pp. 213-223, 2015.

[17] Modern Honey Network, 2015: http://threatstream.github.io/mhn/

[18] Biswas, J.: Analysis of Client Honeypots, in International Journal of Computer Science & Information Technologies, 5(4), 2014.

[19] A. G. Castillo, "Modelos y Plataformas de Agentes Software Moviles e Inteligentes para Gestion del Conocimiento en el Contexto de las Tecnologias de la Informacion", Tesis Doctoral dirigida por Luis Joyanes Aguilar, Facultad de Informatica. Universidad Pontificia de Salamanca. Madrid, 2004.

[20] W. S. Humphrey, "The Personal Software ProcessSM (PSPSM)", Software Engineering Intitute, CMU/SEI-2000-TR-022, ESCTR-2000-022, 2000

[21] Carneige Mellon University,"Personal Software Process for Engineers, Using PSP0", 2006. Disponible: http://www.sei.cmu.edu.

(1) Producto derivado del proyecto de investigacion "Sistema multiagente deliberativo para la obtencion y analisis de datos en Honeynets". Presentado por estudiante de Maestria en Gestion y Desarrollo de Proyectos de Software de la Universidad Autonoma de Manizales.

E. M. Giraldo, estudiante, de la Universidad Autonoma de Manizales, Manizales (Colombia); email: erikumanizales@gmail.com.

G. A. Isaza, Profesor Asociado Grupo GITIR--Ci2Dt2 Facultad de Ingenieria de la Universidad de Caldas, Manizales (Colombia); email: gustavo.isaza@ucaldas.edu.co.

(2) Es una arquitectura cuyo objetivo es plantear los componentes necesarios para exponer de manera consciente a atacantes, sistemas, aplicaciones y servicios reales, el acceso ilicito a estos, para la captura de comportamientos y formas de ataque.

(3) Componente de software, cuyo objetivo es atraer atacantes, mediante la simulacion de elementos vulnerables, lo anterior tiene como propositos la recoleccion de informacion e investigacion.

(4) Lenguaje y Metodologia de Modelamiento UML, focalizado a agentes inteligentes, Castillo A.G et al 2004. Agentes para la Gestion de Conocimiento.

(5) Proceso de desarrollo de software que proporciona un conjunto de pasos y metodologias aplicables/ adaptables a las necesidades de cada organizacion y/o proyecto.

(6) Proceso para la construccion de software, formado por metodos, formularios y scripts que le presentan a los desarrolladores como planear, medir y gestionar su trabajo.

(7) Sistema de deteccion de intrusiones.

Erik Michel Giraldo Giraldo nacio en Manizales, Caldas, Colombia, el 4 de Noviembre de 1988. Ingeniero de Sistemas y Telecomunicaciones de la Universidad de Manizales. Candidato a Magister en Gestion y Desarrollo de Proyectos de Software de la Universidad Autonoma de Manizales.

Ha ejercido profesionalmente como Desarrollador Senior, Lider de Desarrollo de Software, Arquitecto de Soluciones, Coordinador de Desarrollo y Consultor de empresas de Telecomunicaciones como Claro Colombia, Tigo Colombia, Telintel.

Entre sus campos de interes se encuentra el Desarrollo de Software, Arquitectura de Software, Marcos de Referencias como ITIL, Cobit, PMBook, Metodologias Agiles de Desarrollo Saas, Paas.

Gustavo Isaza Echeverri Ph.D de la Universidad Pontificia de Salamanca (Espana) 2010, recibio su DEA/M.Sc en el 2008 en Ingenieria de Software, se graduo de Ingenieria de Sistemas y Computacion en el ano 1997 de la Universidad Autonoma de Manizales (Colombia), obtuvo su posgrado en desarrollo de software para redes en 1998 de la Universidad de los Andes (Colombia). Es Profesor Asociado e Investigador Asociado de la Universidad de Caldas, miembro del grupo de investigacion GITIR, ha publicado mas de 30 articulos y participado en conferencias relacionadas con inteligencia artificial aplicada a la Ciberseguridad, Bioinformatica, AI en Video juegos, Computacion distribuida y Paralela.
TABLA III
DETECCION CORRECTA VS DETECCION FALLIDA

                       Config 1   Config 2   Config 3   Config 4

Vectores Acertados       90%        20%        90%        30%

Vectores Incorrectos     10%        80%        10%        70%

TABLA IV
CONFIGURACION BASE CBR

Configuracion      ip_src   dst_ip   Alerts    Funcion

Configuracion 1      1        1        1      Cadena|Set
Configuracion 2      1        1       0,5     Cadena|Set
Configuracion 3      0        1        1      Cadena|Set
Configuracion 4      1        0       0,5     Cadena|Set
COPYRIGHT 2016 Universidad Catolica de Pereira
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2016 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Giraldo, E.M.; Isaza, G.A.
Publication:Entre Ciencia e Ingenieria
Date:Dec 1, 2016
Words:5036
Previous Article:Creacion de una arquitectura utilizando Lenguaje de Modelado Unificado (UML) en la implementacion de un Lenguaje Especifico de Dominio Interno...
Next Article:Vitamina C y color superficial en tomate y pimenton verde: efecto de los tratamientos termicos.
Topics:

Terms of use | Privacy policy | Copyright © 2018 Farlex, Inc. | Feedback | For webmasters