Datos de entrenamiento y prueba

December 14th, 2009 by Juan Iturbe Araya

Durante la investigación en papers sobre IDS, lo primero que se busca son los datos de entrenamiento y de prueba. Para datos de entrenamientos de un IDS, las opciones más utilizadas en estos trabajos son las siguientes:

  1. KDD’ 99 (link)
  2. DARPA 98 (link)
  3. Datos de redes propias.

Cada uno de los cuales tienen sus pros y contras.

Pros:

KDD’99: utilizados en la mayoría de los paper sobre IDS, con los cuales se prueban y se comparan diferentes técnicas de clasificación (Redes neuronales, logica difusa, arboles de decisión…)

DARPA 98: seis semanas de entrenamiento y dos de testing de lunes a viernes. Gran cantidad de datos e información en bruto de los datos de la red.

Datos de redes propios: datos con etiquetados con ataques actuales.

Contras

KDD’99: las características utilizadas no pueden ser reproducidas en linea (se requeriria una maquina muy poderosa). Pero si se pudiera, los ataques solo se detectarían una vez realizados.

DARPA ‘98: Ataques muy antiguos, por lo que la mayoría de IDS basados en firmas (ej: snort), los detectan.

Datos de redes propias: muy costoso de implementar, dado el etiquetamiento de los ataques que se deben realizar y eliminar datos privados que pueden aparecer en el payload del paquete snifeado.

Conclusión

Creo que los IDS, se deben probar con estos tres conjuntos de datos de pruebas, ya que con los KDD’ 99 se puede probar y comparar la técnica utilizada, con los Darpa’98, si el IDS es basado en anomalías, no interesa que sean antiguos los datos, las anormalías lo son antes y ahora. Con un conjunto de datos reales para evaluar el IDS en escenarios reales.

Curvas ROC Clasificador basado en Población

November 27th, 2009 by ppinacho

El modelo EIA, contempla dos posibles clasificadores:

  • Cambio del tamaño de población.
  • Cambio de la energía promedio de la población.

Aquí se presenta la calibración ROC del primer clasificador, el cual cuenta con los parámetros:

  • Longitud de la Ventana Deslizante.
  • Ancho de Banda.
  • Umbral de Alerta del clasificador.

Curva ROC para parámetro ancho de banda de clasificador

En base a los experimentos realizados,  la curva ROC para el ancho de banda es la siguiente:

anchoBandaROC

Curva Bezier

Al realizar una aproximación en base a una Curva Bezier logramos la siguiente aproximación:

anchoBandaROCBezier

El mejor valor para este parámetro fue 2.

DATOS:

1-Especificidad             Sensibilidad                Ancho de Banda

0.019126276896327      0.507365792759051    16

0.023147141925668      0.366042446941323    32

0.038252553792654      0.656179775280899    8

0.045968267767877      0.637702871410737    6

0.058030862855901      0.578027465667915    7

0.068354705498805      0.587016229712859    5

0.097478808954575      0.749063670411985    2

0.12855900891111        0.672159800249688    4

0.164855466202999      0.653183520599251    3

0.197674418604651      0.686142322097378    -1

0.22136492066942        0.706616729088639    1

0.236905020647685      0.711860174781523    -2

0.391436644207781      0.959051186017478    -4

0.409258856770267      0.83270911360799     -8

0.698109106715931      0.937578027465668    -16

0.939687024559878      0.974282147315855    -32

Curva ROC para parámetro largo de ventana de clasificador

En base a los experimentos realizados,  la curva ROC para la longitud de la ventana deslizante  es la siguiente:

ROC_VentanaPoblacion5

Aumentando la resolucion sobre el eje X para ver en detalle los valores:

ROC_VentanaPoblacion3

Curva Bezier

Al realizar una aproximación en base a una Curva Bezier logramos la siguiente aproximación:

ROC_VentanaPoblacion6

El mejor valor encontrado fue: 900.

DATOS

1-Especificidad          Sensibilidad              Longitud-Ventana

0.006085633557922    0.057428214731586    25

0.044446859378396    0.13832709113608      50

0.046620299934797    0.333333333333333    75

0.061073679634862    0.465168539325843    100

0.092805911758314    0.674157303370786    275

0.092914583786134    0.644194756554307    1000

0.099652249510976    0.609737827715356    225

0.100304281677896    0.472659176029963    150

0.100304281677896    0.502871410736579    125

0.101934362095197    0.592009987515605    250

0.115953053683982    0.528339575530587    375

0.122256031297544    0.573283395755306    175

0.132253857856988    0.713607990012484    450

0.133557922190828    0.664669163545568    350

0.137035427081069    0.569538077403246    200

0.13920886763747      0.650686641697878    475

0.14007824386003      0.727340823970037    325

0.141925668332971    0.705118601747815    425

0.157139752227777    0.701373283395755    300

0.161269289284938    0.771785268414482    1200

0.163551401869159    0.738576779026217    750

0.176266029124103    0.674157303370786    825

0.177896109541404    0.619725343320849    400

0.178656813736144    0.719850187265918    1300

0.182351662682026    0.59965034965035      500

0.183981743099326    0.795505617977528    900

0.190719408824169    0.722097378277154    600

0.219408824168659    0.73083645443196      1500

0.240491197565747    0.817228464419476    675

Curva ROC para parámetro umbral de alerta del clasificador

En base a los experimentos realizados,  la curva ROC para el umbral de alerta es la siguiente:

ROC_umbralPoblacion

Curva Bezier

Al realizar una aproximación en base a una Curva Bezier logramos la siguiente aproximación:

ROC_umbralPoblacionBezier

Mejor valor encontrado: 5

DATOS:

1-Especificidad         Sensibilidad                     Umbral de Alerta

0                                 0                                1200

0.013366659421865      0.08689138576779      600

0.053140621603999      0.382022471910112    300

0.072049554444686      0.598501872659176    40

0.075961747446207      0.659675405742821    65

0.078243860030428      0.657178526841448    70

0.079982612475549      0.652434456928839    75

0.096283416648555      0.564794007490637    60

0.098239513149315      0.630961298377029    35

0.106933275374918      0.68414481897628      55

0.114866333405781       0.679151061173533   45

0.118235166268203       0.654431960049937   50

0.144316452945012       0.600749063670412   10

0.155292327754836       0.714856429463171   4

0.159421864811997       0.640699126092385   25

0.163008041730059       0.609488139825218   30

0.169528363399261       0.683645443196005   20

0.19419691371441         0.777777777777778   5

0.196153010215171       0.647440699126092    15

0.199087154966312       0.769288389513109    2

0.252336448598131       0.721847690387016    1

0.263203651380135       0.704119850187266    3

0.27787437513584         0.737328339575531    0

Gran Rollback

November 21st, 2009 by ppinacho

El análisis ROC fue dificultoso e inadecuado debido a que realmente  los parámetros observables de la población: energía promedio y tamaño de población en la relación OR planteada resultan ser clasificadores independientes, por lo cual su análisis debe ser llevado a cabo por separado. Por esta razón, se repetirán de forma independiente de la siguiente forma:

  • Tamaño de población:
    • Longitud de la Ventana Deslizante.
    • Ancho de banda de clasificación.
  • Energía promedio
    • Longitud de la Ventana Deslizante.
    • Ancho de banda  de la energía.

Para la determinación del error el muestreo será unitario (paquete a paquete)  para de esta forma  aumentar la resolución al máximo sobre el error. Por otro lado la posición del umbral será determinado en dos instancias separado por parámetro y luego consolidado. Con esto finalmente se decidirá si se opera con los dos clasificadores en conjunto o se optará por el mejor.

¿mínimos locales en el ROC?

November 3rd, 2009 by ppinacho

Desarrollado pruebas de ROC, en base a una configuración establecida empíricamente de los parámetros, me di cuenta de que la elección de los primeros parámetros a ajsutar  sesgaba bastante el rendimiento por forzar a los otros parámetros a establecer una configuración “adecuada” para mejorar el rendimiento del clasificador. Creo que el problema en mi caso  está en no haber explorado significativamente variaciones de los parámetros para tener una estimación de donde están los optimos valores de estos. No obstante esto, me parece difícil determinar a priori que parámetros son más relevantes para iniciar la calibración, y creo que esto podría llevar a la generación de mínimos locales del error del clasificador. ¿No será mejor en este caso utilizar una metaheurística para determinar los mejores parámetros de la calibración ROC?

Dejo planteado el tema para la reflexión…

Pedro Pinacho D.

Análisis ROC (Datos Para Test)

October 18th, 2009 by ppinacho

Parámetros a Calibrar con ROC

Los parámetros del clasificador considerados son:Ancho de Banda de Energía, Ancho de Banda de Población, Tamaño de Ventana de Energía, Tamaño de Ventana de Población, Umbral. Los cuales son independientes de los parámetros del modelo los cuales fueron elegidos previamente con el objetivo de maximizar la sensibilidad del modelo a cambios.

Orden de Evaluación de los factores:
El orden está determinado por la importancia del factor para la clasificación. Determinado por esto los sucesivos parámetros considerarán el mejor valor  encontrado en el análisis ROC de los parámetros ya evaluados

  • 1º Tamaño de Ventana de Energía
  • 2º Tamaño de Ventana de Población
  • 3º Ancho de Banda de Energía
  • 4º Ancho de Banda de Población
  • 5º Umbral

Valores iniciales:
Se realizó una precalibración de parámetros del clasificador a partír de datos normales de un servidor expuesto a sesiones de conexión SSH, el cual posteriormente es scaneado con nmap. Con esto se determinaron los valores iniciales.

  • Ancho de Banda de Energía: radio 9
  • Ancho de Banda de Población: radio 12
  • Tamaño de Ventana de Energía: 1674 muestras
  • Tamaño de Ventana de Población: 666 muestras
  • Umbral de alerta: 50 Alertas consecutivas

Set de Prueba para Análisis ROC:
En base a las herramientas nmap y Nessus se generaron obtuvieron los siguientes set de datos:

Archivos fuente de datos:

Datos de Ataque:

snort_trafico_Nessus2_Ruka_DoS_proprocesado: 18793 paquetes
snort_trafico_Nessus2_Ruka_fullScan_preprocesado: 85716 paquetes
snort_trafico_nmap_O_sV_ruka2alumnos_preprocesado: 14954 paquetes
snort_trafico_nmap_sS_ruka2alumnos_preprocesado: 2439 paquetes
snort_trafico_nmap_sT_ruka2alumnos_preprocesado: 2073 paquetes

Datos Normales:
snort_trafico_normal_alumnos_proprocesado: 37026 paquetes

Datos para análisis ROC:

Para el  análisis ROC se llevará a cabo la presentación de los datos de ataque y datos normales de forma  intercalada, de la siguientes forma:

  1. Normal
    • Contenido: 10000 paquetes de datos normales (6800 en ventana de entrenamiento)
  2. Ataque DoS
    • Contenido: 1000  paquetes de intento de DoS Miscelaneo.
  3. Normal
    • Contenido: 2000 paquetes  de datos normales.
  4. Scanning Connect (sT)

    • Contenido: 1000 paquetes.
  5. Normal
    • Contenido: 2000 paquetes  de datos normales.
  6. Scanning Syn (sS)
    • Contenido: 1000 paquetes.
  7. Normal
    • Contenido: 2000 paquetes  de datos normales.
  8. Scanning Service & OS Detection (sV)
    • Contenido: 1000 paquetes.

2º Jornada de Charlas de Seguridad Informática

October 7th, 2009 by ppinacho

Luego de la presentación del grupo de Nagios de GITS en talleres y charlas en Expotecnológica 2009. La Escuela de Informática de Santo Tomás continúa con sesiones de charlas técnicas de Seguridad Informática, presentándose las siguientes exposiciones a realizarse en Auditorio de Sede Prat, Santo Tomás el día 23 de Octubre a partir de las 16:30 horas.

PROGRAMACIÓN SEGURA CON ZEND FRAMEWORK

El mea culpa de los desarrolladores y la problemática de la programación ingenua. Zend Framework una herramienta para desarrollos más seguros (16:30 horas)

Expositor: Alejandro Henriquez, Ingeniero Civil Informático de la Universidad de Concepción, Desarrollador de Aplicaciones Web en PHP con Zend Framework, Docente de IP Santo Tomás y AIEP en Concepción, y miembro de GITS.

DETECTANDO INTRUSOS CON INTELIGENCIA ARTIFICIAL

La detección de intrusos en sistemas computacionales es un área desafiante para la Inteligencia Artificial y Minería de Datos. En esta charla se presenta un resumen de las propuestas que GITS tiene sobre esto. (17:30 horas)

Expositor: Pedro Pinacho, Jefe Carreras Informáticas Santo Tomás, Consultor en Seguridad Informática, Investigador Responsable de GITS, Ingeniero Civil Informático, Profesor DIINF-USACH.

LA IMPORTANCIA DE LA SEGURIDAD ELÉCTRICA EN UN DATA CENTER

Mucho se habla de la seguridad de un Data Center basada en los Datos, Administración, Red, entre otros, pero ¿Cuanto nos preocupamos de los sistemas eléctricos que alimentan nuestros equipos?. (19:00 horas)

Expositor: Ingeniero de Ejecución en Computación e Informática. Administrador de Redes y Servidores, Isapre Masvida S.A. (12 años). Docente IP Diego Portales, IP Santo Tomás.


ENTRADA LIBERADA

Sobre análisis R.O.C.

October 2nd, 2009 by ppinacho

Una de las complicaciones de la realización del análisis R.O.C. bajo la perspectiva del clasificador basado en EIA es que este último no fue ideado para la clasificación del flujo del tráfico de red paquete a paquete como es tradicional para Benchmark como DARPA y derivados. EIA está pensado en evaluar la situación del sistema de forma global, integrando de cierta forma las etapas de clasificación y eliminación de ruido del clasificador, no importando una alta granularidad en el análisis de los paquetes de entrada sino más bien que independiente de que los paquetes de ataque y normalidad vengan mezclados, el sistema tiene dos estados posibles, los cuales son:

  • Situación Normal: Sistema en operación sin ataques presentes.
  • Bajo Ataque (Stress): El sistema se encuentra amenazado por uno o más ataques.

Desde esta perspectiva el análisis ROC del sistema se realizará considerando lo siguiente:

Antes del ataque, es decir cuando la Situación es Normal se considerá todo el tráfico perteneciente a una situación normal, por lo cual  toda alerta será considerada un FP (falso positivo) y todo el tráfico clasificado como normal será considerado VN (verdadero negativo). Por otro  una vez iniciado un ataque, el sistema cambiará a estado de Bajo Ataque, por lo cual independientes de el tráfico el sistema, el clasificador debe durante este lapso indicar la presencia de la amenaza, por lo cual todo el tráfico en este estado que gatille una alerta será marcado como VP (verdadero positivo) y toda ausencia de alerta será notada como FP (falso positivo).

Debido a la necesidad de realizar una discretización temporal determinada por un número por definir de muestreos consecutivos, la regla se extiende de la siguiente forma en esos lapsos de muestreo, los cuales se entenderán como las unidades del análisis ROC clasificables en VP,VN, FP y FN.

  • Durante Situación Normal: la existencia de una alerta  de intrusión en una lapso de muestreo,  marcará tal lapso de muestreo como FP en caso de no existir alertas en tal lapso se marcará  este como VN.
  • Durante la situación de Bajo Ataque: la inexistencia de alertas en el lapso de muestreo deteminará la clasificación de este como FN, en caso de existir alertas se clasificará este período como VP.

Presencia en Expotecnológica 2009

September 21st, 2009 by ppinacho

Alumnos de Santo Tomás  Concepción miembros de GITS tendrán a su responsabilidad el dictar una charla titulada: Control de Disponibilidad con Nagios además de realizar dos talleres técnicos en el evento sobre la instalación adecuada de estas herramientas. Los alumnos pertenecientes a las carreras de Técnico en Sistemas Informáticos y Técnico en Plataformas Informáticas son Francisco Chamorro, Gonzalo Benavente, Giordan Marchant y Mauricio Becerra.

El evento Expotecnológica TIC 2009 se desarrollará desde el 24 al 26 de Septiembre en el Espacio Ferial SurActivo de la ciudad de Concepción.

Reunión Inicial GITS Concepción

August 26th, 2009 by ppinacho

Con una asistencia de 15 estudiantes de Ingeniería Ejecución Informática, Técnico en Plataformas y Técnico en Sistemas se realizó la primera reunión del grupo en Concepción. En esta se estableció la coordinación inicial de horarios y actividades. Estableciéndose los siguiente acuerdos:

  1. Sesiones regulares los días Miercoles a las 15:30 horas (sala 2-2)
  2. Se abordará inicialmente conceptos de algoritmos evolutivos básicos y nociones elementales de sistemas IDS.
  3. Los alumnos se comprometen a estudiar por su parte el principio de selección natural de Darwin, relacionarse con la herramienta NetLogo y buscar información sobre sistemas IDS.

Alumnos Integrantes GITS Presentan en Seminario.

August 25th, 2009 by ppinacho
Afiche de Seminario

Afiche de Seminario

Una  destacada participación tuvieron alumnos de las carreras de Técnico en Sistemas Informáticos (TSI), y Técnico en Plataformas Informáticos (TPI) en el seminario: Plataformas de Servicio & Software Libre organizado por la Escuela de Informática de Santo Tomás sede Concepción. En la oportunidad expusieron los alumnos miembros de GITS Francisco Chamorro y Giordan Marchant sobre Control de Disponibilidad con la plataforma Nagios, exhibiendo las características y bondades de la herramienta, junto con el uso actual en Chile de la misma, la presentación fue acompañada de una demo sobre aspectos relevantes de su funcionamiento.