Día 1: Charlas sobre seguridad, auditoría y peritaje informático
El día 29/10/2014 se efectuó la primera charla del ciclo de charlas sobre seguridad, auditoría y peritaje informático del DIINF. Entre los objetivos de estas charlas se tienen la difusión sobre temas específicos e interesantes sobre la seguridad, peritaje y auditoria informática, discutir sobre los desafíos que enfrenta Chile en estos aspectos, intercambiar experiencias entre empresa y universidad, conocer a nuevos interesados en nuestros programas de postgrado y educación continua y que ellos aprecien en primera persona cuales son los temas que estos programas abarcan.
Tuvimos la visita de dos expositores del McAfee Labs, División de Intel Security. Fernando Ruiz y Daniela Ramirez, ambos investigadores en el área de Malware Mobile. Daniela, es Ingeniera electrónica de la Universidad Técnica Federico Santa María. Por otro lado Fernando, es Ingeniero civil en informática en la Universidad del Biobio y es certificado en seguridad computacional avanzada de la Universidad de Stanford. Ambos trabajan con investigadores de Estados Unidos, Japón y China buscando, detectando y analizando aplicaciones Android sospechosas y potencialmente maliciosas.
Daniela en su charla titulada "Landscape of Mobile Malware Threats.", hizo una revisión de la evolución del malware mobile desde el 2012 hasta nuestros días. Destaca el aumento del malware en el año 2012, lo cual relaciona a la popularidad alcanzada por los dispositivos smartphones en ese año, se observa también un crecimiento sostenido del mismo en los años 2013 y 2014. Luego mostró varios malware específicos, sus objetivos de ataques y contramedidas. Finalmente se tuvo una entretenida ronda de preguntas, donde hubo bastantes interrogantes. Entre sus respuestas,se dio a conocer que Mcafee labs, división. De Intel security , a través de técnicas de crawling son capaces de obtener y analizar automáticamente alrededor de 30.000 archivos apk diarios. Por otra parte, entre los malware mostrados en la presentación se tienen algunos que incluyen chantajes como por ejemplo: se le indica al usuario que si no deposita cierta cantidad de dinero en una cuenta bancaria determinada, se le enviará un correo a todos los contactos del usuario, indicándoles que se detecto pornografía infantil en su smartphone.
Por su parte, Fernando en su charla titulada "Ransomware: Cripto Extorsión en móviles", dio a conocer una técnica que están utilizando los ciberdelicuentes hoy en día para extorsionar a los usuarios de dispositivos moviles. El ransomware es una aplicación malintencionada que restringe el acceso a determinadas partes o archivos del sistema infectado, y pide un rescate a cambio de quitar esta restricción. El ransomware es una realidad principalmente en países con gran cantidad de usuarios de smartphone, por lo que Chile en estos momentos no estaría en la mira de estos Ciberdelicuentes. Ademas, el desarrollo de un kit malware puede llegar a costar aproximadamente 1 MM USD, por lo que una población como la chilena no seria atractiva. Finalmente se muestran varios ejemplos de aplicaciones malware tipo ransomware y ejemplos de códigos de las mismas y resalta que hasta el momento el malware de este tipo ha utilizado criptografía del tipo simétrica para encriptar los archivos, por lo que es relativamente simple rescatar los mismos. Como predicción (y tal como ya sucedió con los equipos de escritorio con el software Cryptolocker), se espera que en un futuro muy cercano comiencen a aparecer ransomware que utilice criptografía del tipo asimétrica lo cual implicaría mucha mas dificultad y hasta la imposibilidad de recuperar los archivos de un sistema infectado.
Un buen Security Scanner
Pueden revisar un artículo sobre como realizar un buen scanner de seguridad aquí.
Material para sesión 1 GITS
Pidiendo disculpas a los estudiantes por lo tardío de la liberación de este material. Se les hace entrega de dos documentos. Uno que forma parte de un curso de diplomado sobre seguridad y redes dictado por el profesor Pinacho y otro extraído directamente desde la red complementario al primero.
No obstante esto, los tópicos principales para las primeras sesiones son Protocolos de la pila TCP/IP en especial la capa de transporte y de aplicación. Para entender esto existen libros en biblioteca adecuados para complementar sus dudas sobre el material entregado.
Descargar archivo 1 (hosted in rapidshare)
Descargar archivo 2 (hosted in rapidshare)
Atte, DC.
Datos de entrenamiento y prueba
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:
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
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:
Curva Bezier
Al realizar una aproximación en base a una Curva Bezier logramos la siguiente aproximación:
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:
Aumentando la resolucion sobre el eje X para ver en detalle los valores:
Curva Bezier
Al realizar una aproximación en base a una Curva Bezier logramos la siguiente aproximación:
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:
Curva Bezier
Al realizar una aproximación en base a una Curva Bezier logramos la siguiente aproximación:
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
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?
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)
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:
- Normal
- Contenido: 10000 paquetes de datos normales (6800 en ventana de entrenamiento)
- Ataque DoS
- Contenido: 1000 paquetes de intento de DoS Miscelaneo.
- Normal
- Contenido: 2000 paquetes de datos normales.
- Scanning Connect (sT)
- Contenido: 1000 paquetes.
- Normal
- Contenido: 2000 paquetes de datos normales.
- Scanning Syn (sS)
- Contenido: 1000 paquetes.
- Normal
- Contenido: 2000 paquetes de datos normales.
- Scanning Service & OS Detection (sV)
- Contenido: 1000 paquetes.
2º Jornada de Charlas de Seguridad Informática
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.
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.
