· resumen ante la creciente magnitud del problema del aseguramiento de la seguridad de la...

Mendizale

15 de noviembre de 2006

Resumen

Ante la creciente magnitud del problema del aseguramiento de la Seguridad de la Información

en sistemas y redes de comunicaciones de todo tipo, los tradicionales mecanismos pasivos de

aislamiento y control de acceso se muestran insu�cientes para contener el extraordinariamente

ascendente número de ataques e intentos de int

rusión, bien indiscriminados, bien selectivos, que se producen en la actualidad.

De este modo, en dichas circunstancias, el área de conocimiento de la Detección de Intrusio-

nes, caracterizada fundamentalmente por su comportamiento activo y por el uso de técnicas de

Inteligencia Arti�cial más o menos ambiciosas y so�sticadas, se muestra como una de las tec-

nologías de seguridad más prometedoras, a medio plazo. Así, es posible encontrar actualmente

soluciones comerciales de detección sólidas y de reconocido prestigio, las cuales, bien orientadas

a la monitorización de equipamientos especí�cos, bien orientadas a la supervisión de redes de

comunicación completas, abogan por la utilización de modelos de representación de conocimiento

e inferencia basados en el concepto de Sistema Experto, de encadenamiento de reglas.

De esta manera, por lo general, el conocimiento disponible en relación con ataques docu-

mentados contra dichos equipamientos o redes de comunicación, queda representado en forma

de reglas de producción, confeccionadas por el administrador humano. Dichos Sistemas de De-

tección de Usos Indebidos, se caracterizan por ser muy precisos en sus decisiones, amén de por

un habitual alto nivel de e�ciencia. Sin embargo, presentan una importante limitación: no son

capaces de responder ante lo que no conocen. O lo que es lo mismo, ante la posibilidad de que

un hipotético atacante pueda disponer del conocimiento del sistema de detección (cuestión real-

mente factible en la mayoría de casos), para a partir de él introducir ligeras modi�caciones en

sus procedimientos de ataque que camu�en sus acciones, o bien ante ataques completamente

novedosos, simplemente no hay respuesta.

Por ello, la comunidad cientí�ca estudia actualmente posibles soluciones a este inconveniente,

apareciendo el concepto de Detección de Anomalías como un elemento de análisis indispensable

a medio plazo, bien en forma de complemento al tradicional enfoque de detección de usos in-

debidos, patrones o �rmas, o bien como superconjunto semántico de éste. Para ello, en general,

dicho enfoque de Detección de Anomalías, persigue el objetivo de ser capaz de proporcionar una

respuesta incluso ante situaciones de riesgo no conocidas de antemano, en base a la elaboración

del per�l de comportamiento del sistema a monitorizar, y al cálculo de desviaciones de la activi-

dad cotidiana con respecto a dicho per�l. Así, toda desviación su�cientemente signi�cativa será

considerada como una anomalía del sistema, y susceptible por tanto de ser noti�cada al opera-

dor humano en forma de señal de alarma, de manera que sea posible un análisis pormenorizado

de las causas de dicha alarma, o de procesarse automáticamente, en la línea del paradigma de

Prevención de Intrusiones.

De esta forma, con el objetivo de proporcionar una respuesta completa por parte del sis-

tema de detección, tanto ante ataques conocidos como ante ataques no conocidos, la presente

tesis doctoral explora el camino de la uni�cación de los dos grandes paradigmas de Detección de

Intrusiones, mediante la utilización de modelos de representación de conocimiento e inferencia

de conclusiones basados en el concepto de Red Bayesiana, el cual contempla de manera intrín-

seca toda la potencia de representatividad de los tradicionales Sistemas Expertos basados en

reglas, amén de un amplio conjunto de poderosas capacidades adicionales, como son: inferen-

cia explicativa de conclusiones, encadenamiento omnidireccional de relaciones de causalidad y/o

correlación, representación intrínseca de la magnitud temporal, aprendizaje estructural (o Data

Mining Bayesiano) a partir de los datos, aprendizaje paramétrico completo o secuencial a partir

de dichos datos, capacidad de adaptación del modelo de conocimiento a variaciones del sistema

observado, o posibilidad de obtención, mediante análisis de sensibilidades, de un esquema cuali-

tativo y cuantitativo de la representatividad y grado de interdependencia de los parámetros que

componen el ámbito del problema. De este modo, a partir de los estudios y experimentaciones

llevadas a cabo en la presente tesis doctoral, se consigue un potente modelo de representación

de conocimiento a partir del cual se desarrolla un motor de razonamiento adaptativo capaz de

inferir conclusiones que contemplan, de un modo uni�cado y homogéneo en el tratamiento de los

diversos tipos de parámetros de detección, tanto conocimiento propio del paradigma de Detección

de Usos Indebidos, por un lado, como conocimiento característico del paradigma de Detección

de Anomalías, por otro.

Estos paradigmas se aplican en este proyecto al mundo de la tecnología móvil que se va a ir

introduciendo poco a poco a lo largo de esta memoria.

2

Índice general

1. Introducción 17

1.1. El papel de la detección de Intrusiones en la Sociedad de la Información . . . . . 2

1.2. El papel innovador de la Detección de Intrusiones para dispositivos móviles . . . 12

1.3. Conceptos Fundamentales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.3.1. Conceptos Fundamentales de la Seguridad de la Información . . . . . . . . 15

1.3.2. Conceptos de Detección de Intrusiones . . . . . . . . . . . . . . . . . . . . 18

1.3.3. Modelo general de funcionamiento . . . . . . . . . . . . . . . . . . . . . . 20

1.3.4. Características de los diferentes enfoques . . . . . . . . . . . . . . . . . . 26

1.4. Retos por alcanzar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

1.4.1. Respuesta ante ataques no conocidos (Zero-Day Attacks) contra teléfonos

móviles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

1.4.2. Aprendizaje Bayesiano no supervisado de per�les de usuario . . . . . . . 45

1.4.3. Uni�cación de modelos de detección de intrusiones . . . . . . . . . . . . . 46

1.4.4. Respuesta preventiva mediante intercepción de llamadas al sistema . . . . 47

1.4.5. Optimización de tasas de falsos positivos y falsos negativos . . . . . . . . 47

1.4.6. Superación de limitaciones arquitectónicas . . . . . . . . . . . . . . . . . . 47

1.4.7. Base de conocimiento estándar . . . . . . . . . . . . . . . . . . . . . . . . 48

1.4.8. Análisis de trá�co de redes inalámbricas . . . . . . . . . . . . . . . . . . . 48

1.4.9. Reducción de requerimientos administrativos . . . . . . . . . . . . . . . . 48

1.4.10. Adaptación al comportamiento del sistema . . . . . . . . . . . . . . . . . . 49

1.4.11. Fortalecimiento del sistema de detección . . . . . . . . . . . . . . . . . . . 49

1.4.12. Reducción del consumo de recursos computacionales . . . . . . . . . . . . 50

1.5. Hipótesis fundamentales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

1.6. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

1.7. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

2. Entorno De Trabajo 57

2.1. Detección de Intrusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

2.1.1. Perspectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3

2.1.2. Modelo conceptual de Lundin . . . . . . . . . . . . . . . . . . . . . . . . . 59

2.1.3. Taxonomía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

2.2. Técnicas de análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

2.2.1. Detección de Usos Indebidos . . . . . . . . . . . . . . . . . . . . . . . . . . 76

2.2.2. Detección de Anomalías . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

2.2.3. Modelo General de Denning . . . . . . . . . . . . . . . . . . . . . . . . . . 106

2.3. Implicaciones Arquitectónicas en el Análisis . . . . . . . . . . . . . . . . . . . . . 108

2.3.1. Detección basada en Agentes de Software . . . . . . . . . . . . . . . . . . 108

2.3.2. Detección basada en Grafos . . . . . . . . . . . . . . . . . . . . . . . . . . 110

2.3.3. Sistema Inmunológico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

2.4. Técnicas de Análisis especí�cas para Host Intrusion Detection Systems (HIDS) . 111

2.4.1. Preámbulo: Ataques Mimicry en Sistemas de Detección de Intrusiones . . 112

2.4.2. Detección mediante Análisis Forense . . . . . . . . . . . . . . . . . . . . . 114

2.4.3. Detección basada en análisis estático o instrumentación binaria del sistema 116

2.4.4. Detección basada en �rmas . . . . . . . . . . . . . . . . . . . . . . . . . . 119

2.4.5. Detección de ataques contra la lógica de las aplicaciones . . . . . . . . . . 121

2.4.6. Detección basada en Secuencias de Syscalls . . . . . . . . . . . . . . . . . 123

2.4.7. Detección basada en grafo . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

2.4.8. Visualización e identi�cación del contexto de las intrusiones desde las trazas

de llamadas al sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

2.4.9. Modelación de llamadas al sistema mediante ventana deslizante . . . . . . 136

2.4.10. Modelado de trayectorias de syscalls mediante en análisis del código fuente 145

2.4.11. Solución de instrumentación mediante criptografía . . . . . . . . . . . . . 150

2.4.12. Solución mediante virtualización para terminales móviles . . . . . . . . . . 151

2.5. Modelos de redes probabilísticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

2.5.1. Modelos de Redes Probabilísticas . . . . . . . . . . . . . . . . . . . . . . . 154

2.5.2. Aprendizaje Estructural . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

2.5.3. Modelado de la información de estado [137] . . . . . . . . . . . . . . . . . 182

3. ESIDE-Mendizale Un Framework Bayesiano de detección de intrusiones 213

3.1. Análisis de riesgos y formalización . . . . . . . . . . . . . . . . . . . . . . . . . . 213

3.1.1. Posibles parámetros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

3.1.2. Selección realizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

3.1.3. Futuros parámetros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

3.2. Recogida de información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

3.2.1. Recogida de información en sistemas GNU/Linux . . . . . . . . . . . . . . 230

3.2.2. Recogida de información en sistemas Windows Mobile. . . . . . . . . . . . 252

3.2.3. Recogida de información en sistemas Windows. . . . . . . . . . . . . . . . 258

3.2.4. Recogida de información en sistemas Symbian OS. . . . . . . . . . . . . . 270

4

3.3. Cuestiones arquitectónicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

3.3.1. Riesgo tecnológico, un problema en alza. . . . . . . . . . . . . . . . . . . 280

3.3.2. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

3.3.3. Detección de intrusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

3.3.4. Introducción a DFSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

3.3.5. Estructura básica de DFSU . . . . . . . . . . . . . . . . . . . . . . . . . . 303

3.3.6. DFSU un programa polifacético . . . . . . . . . . . . . . . . . . . . . . . . 312

3.3.7. Componentes de DFSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

3.3.8. DFSU primeros pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

3.3.9. DFSU con�guración y puesta en marcha de una instancia . . . . . . . . . 334

3.3.10. DFSU descripción de las interfaces . . . . . . . . . . . . . . . . . . . . . . 350

3.4. Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

3.4.1. Modelo General Operativo . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

3.4.2. Obtención de la Muestra Evidencial. . . . . . . . . . . . . . . . . . . . . . 357

3.4.3. Aprendizaje e Inferencia de Expertos Mendizale . . . . . . . . . . . . . . . 360

3.4.4. Proceso de Razonamiento en la Red Naive de Uni�cación de Conclusiones 367

3.5. Respuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

3.5.1. Tipos de respuestas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

3.5.2. Respuesta implementada en ESIDE-Mendizale. . . . . . . . . . . . . . . . 373

3.6. Fortaleza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

3.7. Cuestiones Operacionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

3.8. Aspectos sociales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

4. Conclusiones y líneas de investigación futuras 379

4.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379

4.2. Líneas de investigación futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

5

Índice de �guras

1.1. Ratio de plataformas PC compatible infectadas en el mundo . . . . . . . . . . . . 2

1.2. Utilización de Internet por parte de empresas y organizaciones con sede en la UE 5

1.3. Utilización de Internet por parte de individuos particulares residentes en la UE . 5

1.4. Crecimiento del número de usuarios en el territorio español, en miles de usuarios 6

1.5. Evolución del comercio electrónico durante los últimos años (en Euros) . . . . . . 7

1.6. Evolución del comercio electrónico durante los últimos años (en número de transac-

ciones) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.7. Evolución del número de incidentes de seguridad reportados anualmente por CER-

T/CC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.8. Evolución del número de incidentes de seguridad reportados anualmente por FBI

y CSI en su Computer Crime and Security Survey . . . . . . . . . . . . . . . . . 10

1.9. Relación entre el nivel de preparación del hacker y el grado de so�sticación de sus

ataques, según estudios realizados por CERT/CC . . . . . . . . . . . . . . . . . . 11

1.10. Modelo General de Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.11. Taxonomía general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.1. Modelo conceptual de Lundin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

2.2. Taxonomía de Alessandri et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

2.3. Modelo general de Alessandri et al. . . . . . . . . . . . . . . . . . . . . . . . . . . 66

2.4. Taxonomía de Allen et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

2.5. Taxonomía de Bace y Mell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

2.6. Taxonomía de Axelsson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

2.7. Taxonomía de Debar, Dacier y Wespi . . . . . . . . . . . . . . . . . . . . . . . . . 69

2.8. Taxonomía revisada de Debar, Dacier y Wespi. . . . . . . . . . . . . . . . . . . . 70

2.9. Taxonomía de Lazarevic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

2.10. Taxonomía de Krügel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

2.11. Taxonomía de Indican CERT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

2.12. Arquitectura CIDF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

2.13. Taxonomía ESIDE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

2.14. Ubicación de hipótesis fundamentales . . . . . . . . . . . . . . . . . . . . . . . . . 75

7

2.15. Modelo general de Detección de Usos Indebidos. . . . . . . . . . . . . . . . . . . . 77

2.16. Batería de reglas de Snort para detección de Shellcodes . . . . . . . . . . . . . . . 78

2.17. Firma de Snort para detección de ataques contra Apache . . . . . . . . . . . . . . 78

2.18. Firma de Bro para detección de ataques contra Apache . . . . . . . . . . . . . . . 78

2.19. Batería de reglas de Dragon para detección de Shellcodes . . . . . . . . . . . . . . 79

2.20. Firma de NFR para detección del histórico ataque Land Attack . . . . . . . . . . 79

2.21. Regla de MIDAS para monitorización de cuentas de usuario privilegiadas . . . . . 81

2.22. Regla de MIDAs para análisis de horario inusual en el acceso a cuentas de usuario 81

2.23. Base de hechos de P-BEST/EMERALD para detección del histórico ataque TCP

SYN Flood. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

2.24. Batería de reglas de P-BEST/EMERALD para detección del histórico ataque TCP

SYN Flood . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

2.25. Escenario de STAT para detección de ataques contra servidores IMAP . . . . . . 84

2.26. Especi�cación en lenguaje STATL de escenario de STAT para detección de ataque

contra servidores IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

2.27. Reglas de Snort para detección de ataques contra servidores IMAP . . . . . . . . 85

2.28. Red de Petri de IDIOT para validación del proceso de login . . . . . . . . . . . . 85

2.29. Modelo general de Detección de Anomalías . . . . . . . . . . . . . . . . . . . . . 88

2.30. Batería de reglas de TIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

2.31. Árbol de reglas de Wisdom and Sense . . . . . . . . . . . . . . . . . . . . . . . . 95

2.32. Aplicación de redes neuronales a Detección de Intrusiones . . . . . . . . . . . . . 96

2.33. Firma ISL de NFR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

2.34. Batería de reglas ISL de P-BEST/EMERALD . . . . . . . . . . . . . . . . . . . . 98

2.35. Firma ISL del MIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

2.36. Red Bayesiana trivial de modelado de actividad intrusiva . . . . . . . . . . . . . . 99

2.37. Algoritmo Genético general, en pseudocódigo . . . . . . . . . . . . . . . . . . . . 100

2.38. Clasi�caciones convencional y difusa de un parámetro de detección . . . . . . . . 101

2.39. Clasi�cación de eventos basada en máquina de vector soporte . . . . . . . . . . . 102

2.40. Modelo General de Detección de Intrusiones de Denning . . . . . . . . . . . . . . 107

2.41. Modelo General de Detección de Intrusiones de Denning . . . . . . . . . . . . . . 109

2.42. Representación conceptual de GrIDS de una epidemia vírica . . . . . . . . . . . . 110

2.43. Grafo de dependencia que puede seguirse realizando operaciones de BackTracking 116

2.44. Ciclo de vida de una vulnerabilidad en software . . . . . . . . . . . . . . . . . . . 120

2.45. Grafo de llamadas que se producen desde código fuente. . . . . . . . . . . . . . . 124

2.46. Grafo de llamadas entre librerías . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

2.47. Arquitectura bayesiana del sistema de detección de anomalías para host propuesto

en [95] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

2.48. Código fuente y grafo de ejecución presentado en el paper [141] . . . . . . . . . . 130

8

2.49. Arquitectura de un sistema de detección de intrusiones sin (izq) y con (dch) un

módulo de identi�cación del contexto de intrusiones (ICI) . . . . . . . . . . . . . 131

2.50. Set de datos utilizados para el FSG . . . . . . . . . . . . . . . . . . . . . . . . . . 133

2.51. Ejemplo de FSG para diferentes procesos . . . . . . . . . . . . . . . . . . . . . . . 133

2.52. Número de Secuencias Anómalas Mínimas (MFS) no duplicadas en todos los set

de datos intrusivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

2.53. Secuencias Anómalas Mínimas (MFS) compartidas por la misma intrusión en el

mismo proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

2.54. Entropía condicional del modelo de ventana deslizante . . . . . . . . . . . . . . . 137

2.55. Entropía condicional para una ventana de tamaño �n� . . . . . . . . . . . . . . . 137

2.56. Ejemplo de grafo de llamadas al sistema . . . . . . . . . . . . . . . . . . . . . . . 139

2.57. Un árbol de su�jos para el ejemplo de la cadena A B C C A B B C C A A B C . 141

2.58. Árbol de su�jos con punteros de su�jos incluidos . . . . . . . . . . . . . . . . . . 141

2.59. Árbol �nal resultante de la compresión de la �gura anterior . . . . . . . . . . . . 142

2.60. Ejemplo de código y representación de representación NFA . . . . . . . . . . . . . 143

2.61. Ejemplos de implementación de IAM . . . . . . . . . . . . . . . . . . . . . . . . . 143

2.62. Ejemplo de recursividad y autómata generado. . . . . . . . . . . . . . . . . . . . 144

2.63. Ejemplo de recursividad indirecta y autómata generado. . . . . . . . . . . . . . . 144

2.64. Ejemplo de código y modelo HPDA . . . . . . . . . . . . . . . . . . . . . . . . . . 145

2.65. Ejemplo de un programa en C asociado a un modelo de grafo de llamadas (NFA)

y un modelo NDPDA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

2.66. Proceso de llamada a getuid utilizando el modelo VSL. . . . . . . . . . . . . . . . 148

2.67. Proceso de llamada getuid utilizando el modelo VPStatic. . . . . . . . . . . . . . 149

2.68. Instalación del programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

2.69. Comprobación de las syscalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

2.70. Imagen de la arquitectura de los nuevos procesadores para terminales de tercera

generación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

2.71. Comunicación VMM asimétricos . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

2.72. Comunicación dinámica inter-dominio . . . . . . . . . . . . . . . . . . . . . . . . 154

2.73. ID de los registros del procesador lógico virtual . . . . . . . . . . . . . . . . . . . 154

2.74. Esquema de la propagación en poliárboles . . . . . . . . . . . . . . . . . . . . . . 159

2.75. Ejemplo de red naive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

2.76. Ejemplo de sustración de nodos en red Naive . . . . . . . . . . . . . . . . . . . . 162

2.77. Ejemplo de adición de un nodo a una red Naive . . . . . . . . . . . . . . . . . . . 163

2.78. Red bayesiana de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

2.79. Trayectoria Del Algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

2.80. Cadena de Markov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

2.81. Cadena de Markov representada como red bayesiana . . . . . . . . . . . . . . . . 185

9

2.82. Tablas de probabilidad condicionada . . . . . . . . . . . . . . . . . . . . . . . . . 186

2.83. Cadena de Markov y la evolución de sus estados. . . . . . . . . . . . . . . . . . . 190

2.84. Ejemplo de PHMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

2.85. Ejemplo de IDHMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

2.86. Ejemplo de HHMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

2.87. Ejemplo de integración de cadenas interrelacionadas . . . . . . . . . . . . . . . . 192

2.88. Otra aproximación para la integración de cadenas interracionadas . . . . . . . . . 192

2.89. Complejidad del algoritmo Fordward . . . . . . . . . . . . . . . . . . . . . . . . . 195

2.90. Complejidad del algoritmo de Backward . . . . . . . . . . . . . . . . . . . . . . . 196

2.91. Cálculo del algoritmo de Viterbi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

3.1. Imagen del monitor de anomalías desarrollado por Teresa F.Lunt y R. Jagannathan.214

3.2. Arquitectura interna de los sistemas operativos . . . . . . . . . . . . . . . . . . . 218

3.3. Abstracción a dos niveles en sistemas Linux . . . . . . . . . . . . . . . . . . . . . 219

3.4. Formato IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

3.5. Formato TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

3.6. Formato UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

3.7. Formato ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

3.8. Esquema de la estructura del kernel . . . . . . . . . . . . . . . . . . . . . . . . . 231

3.9. Proceso de llamada a una syscall . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

3.10. Ejemplo utilización del comando strace . . . . . . . . . . . . . . . . . . . . . . . . 234

3.11. Esquema de llamada a una interrupción mediante interrupción . . . . . . . . . . 240

3.12. Logo de SuSE, distribución alemana, respaldada por la empresa Novell . . . . . . 241

3.13. Logo del agente de snare para sistemas GNU/Linux . . . . . . . . . . . . . . . . . 242

3.14. Esquema del formato Portable Ejecutable . . . . . . . . . . . . . . . . . . . . . . 254

3.15. Esquema de llamadas para ejecutar una operación a nivel de kernel. . . . . . . . 255

3.16. Esquema de la información contenida en la estructura KDataStruct . . . . . . . . 256

3.17. Detalle de interfaz de usuario del agente. . . . . . . . . . . . . . . . . . . . . . . . 257

3.18. Esquema de memoria de NT, y posible puntos de recolección de datos. . . . . . . 261

3.19. Ejemplo de modi�cación de memoria en el punto de inicio . . . . . . . . . . . . . 264

3.20. Esquema de funcionamiento de la librería strace . . . . . . . . . . . . . . . . . . . 266

3.21. Monitorización de syscalls de un proceso infectado con el virus Satir.994 utilizando

strace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

3.22. Interfaz de usuario del agente, menús generales. . . . . . . . . . . . . . . . . . . . 269

3.23. Menú de selección de syscalls hookeadas . . . . . . . . . . . . . . . . . . . . . . . 269

3.24. Simpli�cación de la arquitectura de Symbian OS . . . . . . . . . . . . . . . . . . 270

3.25. Formato interno de los �cheros ejecutables y librerías para Symbian OS . . . . . 272

3.26. Modelo simpli�cado de la arquitectura de procesadores de un terminal Symbian OS272

3.27. Capas del núcleo de Symbian OS . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

10

3.28. Llamada ejecutiva al kernel de Symbian OS . . . . . . . . . . . . . . . . . . . . . 274

3.29. Código fuente en el que se realiza la llamada para reservar una porción de memoria275

3.30. Arquitectura de los drivers de dispositivo simpli�cada . . . . . . . . . . . . . . . 277

3.31. Selección de hilos en ejecución a interceptar . . . . . . . . . . . . . . . . . . . . . 278

3.32. Volcado de la memoria y de las peticiones que se realizan a la librería . . . . . . . 279

3.33. Detalles de un hilo en ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

3.34. Run-Mode Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

3.35. Ecuación del riesgo tecnológico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

3.36. Seguridad Perimetral (Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

3.37. Etapas en el proceso de detección . . . . . . . . . . . . . . . . . . . . . . . . . . 284

3.38. Logotipo de Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

3.39. Cabecera IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

3.40. De�nición de patrones de uso indebido . . . . . . . . . . . . . . . . . . . . . . . . 290

3.41. Esquema de funcionamiento; Modelo de usos indebidos . . . . . . . . . . . . . . . 291

3.42. Ataque según la �losofía de detección de anomalías . . . . . . . . . . . . . . . . . 292

3.43. Esquema de funcionamiento de un modelo de detección de anomalías . . . . . . . 294

3.44. IPS integrado en una red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

3.45. Taxonomía de los sistemas de detección de intrusiones . . . . . . . . . . . . . . . 301

3.46. Arquitectura de tres capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

3.47. Correlacionando HIDS y NIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

3.48. Estructura de dos capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

3.49. Estructura de tres capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

3.50. Estructura con plugins distribuidos . . . . . . . . . . . . . . . . . . . . . . . . . . 310

3.51. Estructura de Heads jerárquicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

3.52. Estructura de herencia de los plugins . . . . . . . . . . . . . . . . . . . . . . . . . 317

3.53. Clase PlugSkel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

3.54. Clase ExpertSkel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

3.55. Del�n opciones de con�guración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

3.56. Del�n cambiando el modo de funcionamiento . . . . . . . . . . . . . . . . . . . . 322

3.57. Del�n mostrando el modo de funcionamiento actual . . . . . . . . . . . . . . . . . 323

3.58. Listado de modos de funcionamiento de Del�n . . . . . . . . . . . . . . . . . . . . 323

3.59. Del�n ejemplo de una alerta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

3.60. eForwarder opciones de con�guración . . . . . . . . . . . . . . . . . . . . . . . . . 325

3.61. eForwarder listado de modos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

3.62. eForwarer mostrando el modo de funcionamiento actual . . . . . . . . . . . . . . 326

3.63. eForwarder cambiando el modo de funcionamiento . . . . . . . . . . . . . . . . . 326

3.64. Stats, ejemplo de estadisticas de sistema. . . . . . . . . . . . . . . . . . . . . . . . 327

3.65. Head con un tail y dos masters conectados . . . . . . . . . . . . . . . . . . . . . . 347

11

3.66. Plugins cargados en el Head . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

3.67. Plugins cargados en el Tail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

3.68. Visualización de las alertas en el Head . . . . . . . . . . . . . . . . . . . . . . . . 349

3.69. Pantalla principal servidor WebOs . . . . . . . . . . . . . . . . . . . . . . . . . . 350

3.70. Gra�co del sysload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352

3.71. Pantalla de información grá�ca sobre el Tail . . . . . . . . . . . . . . . . . . . . . 352

3.72. Pantalla de inicio de la consola . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

3.73. Comandos de consola para webOs . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

3.74. Pantalla de ayuda de la consola . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

3.75. Comandos de consola ls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

3.76. Aprendizaje de Parámetros de las llamadas al Sistema . . . . . . . . . . . . . . . 364



3.79. Ejemplo de envío de alerta de ataque al telefono móvil (Respuesta pasiva). . . . . 370

3.80. Problemática de la respuesta activa en sistemas NIDS . . . . . . . . . . . . . . . 372

3.81. Ejemplo de arquitectura del sistema, que asegura la fortaleza del sistema mediante

VPN�s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

12

Índice de cuadros

1.1. Utilización de Internet en las diferentes regiones del globo . . . . . . . . . . . . . 3

1.2. Utilización de Internet en las diferentes regiones del globo . . . . . . . . . . . . . 4

1.3. Previsiones de crecimiento del Comercio Electrónico, según Forrester, IDC y eMar-

keter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4. Previsiones de crecimiento del Comercio Electrónico, según Forrester, IDC y eMar-

keter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.5. Áreas de investigación sobre Detección de Intrusiones con mayor actividad . . . . 35

2.1. Líneas de Investigación sobre Detección de Intrusiones . . . . . . . . . . . . . . . 64

2.2. Relación entre retos de la Detección de Intrusiones y líneas de investigación . . . 65

2.3. Métricas utilizadas en el sistema IDES de Detección de Intrusiones basada en per�les 92

2.4. Tabla de probabilidades de la �gura . . . . . . . . . . . . . . . . . . . . . . . . . 185

2.5. Implementación del algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

3.1. Tipo y valores posibles de cada parámetro . . . . . . . . . . . . . . . . . . . . . . 224

3.2. Tipos y posibles parámetros del protocolo TCP . . . . . . . . . . . . . . . . . . . 225

3.3. Tipos y posibles parámetros de UDP . . . . . . . . . . . . . . . . . . . . . . . . . 226

3.4. Tipos y posibles parámetros ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . 227

3.5. Tipo y parámetros de bajo nivel de Snort . . . . . . . . . . . . . . . . . . . . . . 227

3.6. Tipo y parámetros de alto nivel de Snort . . . . . . . . . . . . . . . . . . . . . . . 228

3.7. Parámetros que proponen Mahoney y Chan[364]. . . . . . . . . . . . . . . . . . . 228

3.9. Parámetros de alto nivel de Marina Bykova . . . . . . . . . . . . . . . . . . . . . 229

3.8. Parámetros y tipos de Marina Bykova . . . . . . . . . . . . . . . . . . . . . . . . 229

3.10. Fichero de compilación compileAll.sh . . . . . . . . . . . . . . . . . . . . . . . . . 334

3.11. Fichero slaveconf.xml del Head y del Tail . . . . . . . . . . . . . . . . . . . . . . 335

3.12. Fichero oaconf.xml del head y del tail . . . . . . . . . . . . . . . . . . . . . . . . 337

3.13. Fichero webos.xml del Head y del Tail . . . . . . . . . . . . . . . . . . . . . . . . 338

3.14. Fichero reload.sh del Syshooker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

3.15. Fichero mastercon�g.xml del Syshooker . . . . . . . . . . . . . . . . . . . . . . . 340

3.16. Fichero dfsumcon�.cfg del Snort Modi�cado . . . . . . . . . . . . . . . . . . . . . 341

3.17. Fichero run.sh del Snort Modi�cado . . . . . . . . . . . . . . . . . . . . . . . . . 341

13

3.18. Ejemplo de con�guración del �chero dfsumcon�g.cfg del Snort Modi�cado . . . . 344

3.19. Ejemplo de con�guración del �chero run.sh en el Snort Modi�cado . . . . . . . . 344

3.20. Ejemplo de con�guración del �chero mastercon�g.xml en el Syshooker . . . . . . 344

3.21. Ejemplo de con�guración del archivo slaveconf.xml en el Head . . . . . . . . . . . 345

3.22. Ejemplo de con�guración del �chero slaveconf.xml en el Tail . . . . . . . . . . . . 346

3.23. Listado de llamadas al sistema por el PID 2d82b0aa . . . . . . . . . . . . . . . . 362

3.24. Listado de parámetros para realizar una llamada write en GNU/Linux . . . . . . 363

3.25. Listado de llamadas al sistema por el PID 2d82b0aa (recordatorio) . . . . . . . . 365

14

Listings

2.1. Ejemplo de un ataque Mimicry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

2.2. Hola esto es una prueba aquí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

3.1. Prototipo de función VirtualAlloc de la API Win32. . . . . . . . . . . . . . . . . 220

3.2. Prototipo de la función malloc para sistemas linux provista por el API de glibc. . 220

3.3. Prototipo de syscalls write (código 4) y kill (código 37) de sistemas GNU/linux . 221

3.4. Prototipo de la función NTCreateFile del kernel de Windows . . . . . . . . . . . 221

3.5. Ejemplo de programa en ensamblador . . . . . . . . . . . . . . . . . . . . . . . . 232

3.6. Ejemplo de la mejora con lenguaje C . . . . . . . . . . . . . . . . . . . . . . . . . 233

3.7. Macro para llamar a syscall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

3.8. Contenido de unistd.h los números de las syscalls . . . . . . . . . . . . . . . . . . 235

3.9. De�nición de la IDT en linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

3.10. Inicialización de la IDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

3.11. Gestión de la interrupción 80 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

3.12. Gestión de la llamada sysenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

3.13. Prototipo de la función ptrace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

3.14. Ejemplo de un módulo básico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

3.15. Función que obtiene la base del vector de syscalls . . . . . . . . . . . . . . . . . . 245

3.16. Ejemplo de la intercepción de la syscall Kill . . . . . . . . . . . . . . . . . . . . . 246

3.17. Líneas que son sobreescritas con un salto a la función. . . . . . . . . . . . . . . . 248

3.18. Shellcode a la que saltamos cuando se llama a la función. . . . . . . . . . . . . . 249

3.19. Ejemplo de la creación y destrucción de un dispositovo /proc. . . . . . . . . . . . 250

3.20. Código que permite saber el ejecutable padre del que proviene el proceso. . . . . 252

3.21. Utilizanción de int2Eh en Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 259

3.22. Utilizanción de int2Eh en Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 259

3.23. De�nición de la clase hEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

3.24. Ejemplo para obtener el Identi�cativo de la CPU en ensamblador sobre sistemas

GNU/Linux en nomenclatura AT&T . . . . . . . . . . . . . . . . . . . . . . . . . 362

15

Capítulo 1

Introducción

17

Resumen

Internet se ha convertido en los últimos tiempos en un hábitat peligroso. Cada día que pasa

se desarrollan nuevas y cada vez más potentes herramientas destinadas a atacar sistemas de

información y redes de comunicación de todo tipo, y miles de ordenadores en todos los puntos

del planeta son asaltados diariamente. Desgraciadamente, aún no se ha encontrado una solución

al problema si bien, dentro del área de conocimiento de la Detección de Intrusiones, el campo

de la Detección de Anomalías se per�la como un �rme candidato, con grandes posibilidades de

erigirse en la tecnología de seguridad de la información por excelencia, a medio plazo.

Esta situación se acerca cada día más al usuario, conforme se avanza en la tecnología, el ser

humano tiene a su disposición cada vez más elementos susceptibles de ser atacados. Actualmente

ya se desarrollan sistemas de protección para dispositivos móviles por parte de grandes compañías,

pero el problema del mundo de Internet tradicional se encuentra desplazado encima de un nuevo

mercado: la portabilidad y el multiemplazamiento de los nuevos dispositivos.

1.1. El papel de la detección de Intrusiones en la Sociedad de la

Información

Hasta el momento, las investigaciones llevadas a cabo en el campo de la seguridad de la

información respecto de la cuestión del asalto subversivo e ilegítimo a sistemas informáticos, no

han aportado más que soluciones muy parciales al problema. En el momento de escribir estas

líneas, la magnitud de esta cuestión es tal que prestigiosos observatorios y centros de respuesta

temprana ante incidentes de seguridad, como pueden ser el Computer Emergency Response Team

Coordination Center1CERT[60], el Equipo de Seguridad para la Coordinación de Emergencias en

Redes Telemáticas2 ESCERT [123], su homólogo IrisCERT [98], o el servicio Alerta-Antivirus 3

[23], se ven colapsados con cientos de miles de casos de intrusiones al año. De hecho, se ha llegado

a un punto en el que los datos estadísticos que ofrecen periódicamente dejan de ser realmente

signi�cativos.

Figura 1.1: Ratio de plataformas PC compatible infectadas en el mundo

Asimismo, otros grandes referentes como pueden ser las reconocidas listas de distribución

1Puesto en marcha en 1.988 por iniciativa del Departamento de Defensa [109] estadounidense, a través dela Defense Advanced Research Project Agency [94], y en colaboración con la Carnegie Mellon University [70].Su constitución, el día 17 de Noviembre de 1.988, fue llevada a cabo con carácter de urgencia a raíz del ataqueinformático perpetrado dos semanas antes por Robert Tappan Morris. Se estima que el mítico Gusano de Morrisllegó a infectar alrededor del 10% de los servidores que en aquel momento estaban conectados a Internet en elmundo [118]. El oscuro horizonte que se abría en un sector tan crítico como el informático hizo que el todopoderosoDepartamento de Defensa decidiera acometer esta iniciativa para tratar de minimizar los efectos de crisis similaresen el futuro.

2Tanto esCERT como IrisCERT son dependientes de CERT/CC y tienen un ámbito de actuación circunscritoal territorio español. Actualmente, esCERT se encuentra ubicado en la Universidad Politécnica de Cataluña,mientras que IrisCERT está soportado por la iniciativa RedIris [178].

3Servicio provisto por la entidad pública empresarial Red.es [295], adscrita al Ministerio de Industria, Turismoy Comercio, a través de la Secretaría de Estado para las Telecomunicaciones y para la Sociedad de la Información.

2

Cuadro 1.1: Utilización de Internet en las diferentes regiones del globo

sobre cuestiones de seguridad SecurityFocus BugTraq [132] o Full Disclosure [108], o los obser-

vatorios privados pertenecientes a los grandes fabricantes mundiales de soluciones de seguridad,

como pueden ser Panda Software [324], Kaspersky [222] o Symantec [74], apuntan en la misma

dirección. A modo de ejemplo, sirva la �gura 1.1 para ilustrar la problemática de la seguridad

en el mundo, según el Global Virus Observatory de Panda Software.

De esta forma, la conclusión es clara: En una sociedad de la información cuya realidad depende

cada vez más de la tecnología, como puede deducirse de las cifras de crecimiento del número de

usuarios conectados a Internet [181, 103, 333, 359, 99], o de los diferentes estudios realizados

al respecto por las grandes consultoras como Forrester [172] o Gartner [173], la seguridad de

la información es un campo de las Ciencias de la Computación que aún presenta importantes

de�ciencias. De�ciencias que, además, inciden de forma extraordinariamente negativa en el �uido

desarrollo de actividades cruciales para una evolución tecnológica plena como son el movimiento

de capitales en general y el comercio electrónico en particular. De estar resuelta la cuestión

de la con�abilidad en el uso de las tecnologías de la información y las comunicaciones, dichas

actividades podrían llegar a altísimas cotas de progreso; tal y como se indica en la línea prioritaria

de investigación Towards a Global Dependability and Security Framework del VI Programa

Marco Europeo [72, 296], dentro del Espacio Europeo de Investigación.

A este respecto, las tablas 1.1 y 1.2 ilustran de forma signi�cativa el crecimiento del número

de usuarios a nivel mundial, según cifras de Internet World Stats [180, 179].

En la misma línea, las �guras 1.2 y 1.3 ilustran el grado de utilización de Internet en la Unión

Europea por parte de empresas y organizaciones, y usuarios particulares, respectivamente, según

cifras de la European Statistical Data Support [333]. Existen ciertos países para los que no hay

datos disponibles, y que lógicamente no aparecen en dichas �guras.

De forma análoga, pero ya en el ámbito nacional, la �gura 1.4 ilustra el crecimiento del número

de usuarios y los porcentajes de penetración de Internet en el territorio español, durante los cinco

últimos años, según cifras de la consultora Tatum [99]. Por otro lado, en lo relativo a la creciente

relevancia que está adquiriendo el comercio electrónico a nivel mundial, la tabla 1.3 representa las

3

Cuadro 1.2: Utilización de Internet en las diferentes regiones del globo

Cuadro 1.3: Previsiones de crecimiento del Comercio Electrónico, según Forrester, IDC y eMar-keter

4

Figura 1.2: Utilización de Internet por parte de empresas y organizaciones con sede en la UE

Figura 1.3: Utilización de Internet por parte de individuos particulares residentes en la UE

5

Figura 1.4: Crecimiento del número de usuarios en el territorio español, en miles de usuarios

previsiones realizadas por tres de las mayores �rmas multinacionales de consultoría tecnológica,

como son Forrester, IDC y eMarketer. Dichas previsiones están recogidas en el E-Commerce and

Development Report que Naciones Unidas publica anualmente [268, 267].

De la misma forma, en la tabla 1.4 puede observarse la tendencia de crecimiento prevista para

la Unión Europea, entre otras regiones del planeta, como son Latinoamérica, África, regiones

en vías de desarrollo de Asia y Región del Pací�co y otras regiones en vías de desarrollo, y

Norteamérica y otras regiones desarrolladas de Asia y Región del Pací�co [267].

Por último, en las �guras 1.5 y 1.6 pueden observarse las últimas cifras publicadas por la

Comisión del Mercado de las Telecomunicaciones [103], relativas a la situación del comercio

electrónico en el territorio nacional.

Por otro lado, en lo relativo a la problemática de la seguridad propiamente dicha, son espe-

cialmente signi�cativas las tendencias observadas por CERT/CC [59], así como por el Federal

Bureau of Investigation [128] en colaboración con el Computer Security Institute [79] [129], y que

están representadas en las �guras 1.7 y 1.8. Dichos datos deben servir como botón de muestra

del problema de la seguridad en los Estados Unidos de Norteamérica, si bien la situación en el

resto del orbe es análoga, como se desprende de los estudios realizados por los miembros del

prestigioso Honeynet Project [283]. Dicho proyecto tiene como objetivos la detección y análisis

de comportamientos no documentados, y por lo tanto de alto riesgo, en la actividad subversiva de

Internet, mediante el despliegue de una vasta red (Honeynet) de servidores señuelo o Honeypots4.

De esta forma, han llegado a observarse, por ejemplo, redes domésticas atacadas diariamente en

más de treinta ocasiones, o casos de intrusión en dichos servidores señuelo a los quince minutos

4Honeypot o Tarro de miel: Recurso informático cuyo valor reside en ser atacado, comprometido y analizado,con el objeto de descubrir nuevas formas de ataques informáticos; según la de�nición de su autor, Lance Spitzner[221]. Por su parte, el concepto Honeynet hace referencia, como es lógico, a una red de Honeypots.

6

Cuadro 1.4: Previsiones de crecimiento del Comercio Electrónico, según Forrester, IDC y eMar-keter

Figura 1.5: Evolución del comercio electrónico durante los últimos años (en Euros)

7

Figura 1.6: Evolución del comercio electrónico durante los últimos años (en número de transac-ciones)

de su conexión a Internet [282, 202].

Como puede observarse en la �gura 1.7, el crecimiento del número de incidentes de seguridad

observados por CERT/CC desde su puesta en marcha, presentó hasta el año 2.003 un crecimien-

to exponencial, que ha terminado haciendo que los responsables máximos decidieran eliminar

dicho parámetro de sus estudios anuales, para pasar a proporcionar conclusiones abstractas de

mayor utilidad. De nada sirve conocer el número de víctimas; lo verdaderamente importante es

concienciarse del problema de la seguridad y averiguar cómo evitar convertirse en una de ellas.

De esta forma, a partir de 2.004, CERT/CC publica, en colaboración con el United States

Secret Service [363] y la prestigiosa revista CSO Magazine [80], su E- Crime Watch Survey [265],

del cual ya ha visto la luz su primera edición. En él pueden observarse datos alarmantes, como

por ejemplo el 70% de organizaciones estadounidenses encuestadas que registraron al menos un

caso de intrusión en el último año, o los más de seiscientos sesenta millones de dólares de pérdidas

económicas derivadas de actividad cracker5 que se estiman durante el mismo periodo de tiempo.

En la misma línea, tal y como puede observarse en la �gura 1.8, el informe que anualmente

5Cracker: �Someone who tries to break the security of, and gain access to, someone else's system withoutbeing invited to do so�. De�nición del RFC 2828 [288] del Internet Engineering Task Force [169]. Es un términoconfundido habitualmente con el de Hacker: �Someone with a strong interest in computers, who enjoys learningabout them and experimenting with them�. En cualquier caso, las connotaciones delictivas que se han arrogado aeste término están tan extendidas, que se admite en general su uso.

8

Figura 1.7: Evolución del número de incidentes de seguridad reportados anualmente por CER-T/CC

presentan FBI y CSI12 también revela datos escalofriantes sobre la cantidad de ataques infor-

máticos que concluyen con éxito, si bien en este caso la tendencia que se advierte permite cierto

margen para el optimismo, al menos a medio plazo. No obstante, a pesar de ello, la situación

dista aún mucho de ser halagüeña, ya que más de la mitad (70% en el año 2.000) de los or-

ganismos y grandes corporaciones estadounidenses encuestadas sufren anualmente al menos un

caso de intrusión. AdemÃ½s, existe un importante número de ellas (alrededor del 10%) que ni

siquiera es capaz de determinar con precisión si sus recursos computacionales y de comunicación

son accedidos subversivamente o no.

Asimismo, de los resultados obtenidos por el anteriormente mencionado Honeynet Project

pueden obtenerse conclusiones similares: La seguridad informática se mantiene en niveles de alto

riesgo y la actividad hacker crece desmesuradamente día a día, llegando a observarse crecimientos

del número de ataques en torno al 890% anual. Sin embargo, también se observa cierta mejora en

las cifras de incidentes registrados, debido fundamentalmente a una creciente concienciación por

parte de usuarios, administradores de sistemas y desarrolladores de aplicaciones del problema de

la seguridad, así como a una mayor utilización de las tecnologías de seguridad disponibles. De

esta forma, ha podido observarse un importante progreso, por ejemplo, en la esperanza de vida

media de un servidor GNU/Linux conectado a Internet, que ha pasado de tan sólo 72 horas en

el año 2.000, a tres meses en la actualidad [282]. Por otro lado, existe un importante factor a

9

Figura 1.8: Evolución del número de incidentes de seguridad reportados anualmente por FBI yCSI en su Computer Crime and Security Survey

tener en cuenta a la hora de analizar estos datos de crecimiento de la actividad subversiva en

la red, que es el nivel de preparación técnica que necesita el potencial intruso para atacar un

determinado sistema informático; factor que in�uye directamente en el orden de magnitud de la

amenaza.

Así pues, a medida que la so�sticación, la potencia y la facilidad de uso de las herramientas

de hacking crece, mayor es la población potencial de individuos susceptibles de convertirse en

agentes propagadores de todo tipo de epidemias informáticas. En los orígenes del delito infor-

mático era habitual observar cómo los responsables de los incidentes de seguridad seguían un

per�l común en el que el elemento fundamental era su alto grado de preparación técnica y sus

vastos conocimientos sobre el funcionamiento a bajo nivel de sistemas, redes y arquitecturas6. Sin

embargo, hoy día la situación ha cambiado y, si bien los desarrolladores últimos de herramien-

tas, utilidades y técnicas de hacking siguen correspondiendo a ese per�l de antaño, los usuarios

habituales de las mismas se encuentran a gran distancia de aquéllos7. De esta forma, la amenaza

6Tradicionalmente se ha utilizado el término �Blackhat Hacker� para hacer referencia a este tipo de atacantede elite.

7En la �gura 1.9 se ilustra esta conclusión. Como puede observarse, cada vez es necesario un menor conocimientotécnico para orquestar un ataque mucho más potente y efectivo. De hecho, esta situación ha dado origen a unanueva especie de pirata informático: El �Script Kiddie�, caracterizado fundamentalmente por su baja preparacióntécnica y su carencia de objetivos concretos; características que lo hacen especialmente peligroso, dada la granfacilidad de uso de las nuevas herramientas de hacking y lo indiscriminado de sus acciones.

10

Figura 1.9: Relación entre el nivel de preparación del hacker y el grado de so�sticación de susataques, según estudios realizados por CERT/CC

general crece aceleradamente en nuestros días, y sólo es posible contener el número de incidentes

de seguridad mediante la concienciación e interiorización del problema por parte de los usuarios,

y mediante la utilización de las contramedidas adecuadas, en un proceso continuo de vigilancia

tecnológica [58].

Además, no sólo es relevante la amenaza que constituye esa amplísima población de usuarios

malintencionados, sino que también es necesario prestar especial atención a la ingente colección

de malware8 en forma de virus9, gusanos10, caballos de Troya11 y demás, que prolifera por

doquier. Las diferentes variantes de estos tipos de códigos malignos son capaces de lanzar los

anteriormente mencionados ataques de forma automática, infectando y extendiendo el ataque a

otros sistemas a gran velocidad12, lo que incrementa en varios órdenes de magnitud su impacto

8Malware: Malicious software o código maligno [220].9Virus: �Hidden, self-replicating section of computer software, usually malicious logic, that propagates by

infecting (i.e., inserting a copy of itself into and becoming part of) another program. A virus cannot run by itself;it requires that its host program be run to make the virus active�. De�nición del �SANS glossary of terms used insecurity and intrusion detection� [177].

1018 Gusano o Worm: �Computer program that can run independently, can propagate a complete workingversion of itself onto other hosts on a network, and may consume computer resources destructively.� [177]

1119 Caballo de Troya (Troyano) o Trojan horse: �Computer program that appears to have a useful function, butalso has a hidden and potentially malicious function that evades security mechanisms, sometimes by exploitinglegitimate authorizations of a system entity that invokes the program.� [177]

12Staniford-Chen, Moore, Paxson y Weaver [332] calculan que un gusano de alta velocidad (Flash Worm) podríainfectar el 95% de una población de un millón de ordenadores vulnerables en 510 milisegundos, mediante trá�co

11

potencial [332]. Un ejemplo interesante de este extremo puede ser el del lamentablemente popular

gusano Slammer21, considerado el caso de malware autopropagable más rápido de la historia.

Según los estudios realizados por David Moore, Vern Paxson et al. [253], dicho gusano llegaba

a duplicar la población de ordenadores infectados cada ocho segundos y medio. Qué decir de lo

absurdo de intentar enfrentarse manualmente a amenazas como el mencionado Slammer u otros

históricos como el Witty [88], el Code Red [254], o el Nimda [53], por ejemplo.

En la misma línea, las interesantes cifras publicadas por CERT/CC para el año 2.002, en el

cual se registraron un total de 5.500 vulnerabilidades13 en software de todo tipo, se hacían eco

de esta cuestión y revelaban, además, lo inabordable del problema no ya de la respuesta ante

este tipo de ataques, sino incluso simplemente de una cuestión tan trivial como la administración

de las actualizaciones de seguridad del software por el operador humano. De hecho, se estimaba

en 298 días de trabajo al año el esfuerzo que necesitaría un e�ciente administrador de sistemas

solamente para leer las descripciones de dichas vulnerabilidades y descargar y aplicar los parches

o hot�xes correspondientes [58].

De esta forma, a raíz de esta problemática situación, surge inmediatamente y de forma natural

una conclusión lógica: Es necesario responder ante estos avasalladores ataques con mecanismos

tan automatizados o más que los del atacante, ya sea éste un intruso real o virtual, para poder

contrarrestar e�cazmente su abrumador poder ofensivo; necesidad esta que se ha visto parcial-

mente satisfecha en los últimos tiempos gracias a la aparición y al continuo desarrollo del área de

conocimiento conocida como Detección de Intrusiones. Dicha área de conocimiento se ve mate-

rializada actualmente en los denominados Sistemas de Detección y Prevención de Intrusiones, y

cuenta ya con investigaciones sólidas y de reputada solvencia que incluso han evolucionado hacia

productos comerciales ampliamente extendidos. Sin embargo, los modelos de funcionamiento que

se han venido explorando con mayor intensidad parecen haber tocado techo, y se hace necesa-

rio prestar una mayor atención a otras líneas de investigación, como puede ser la Detección de

Anomalías. De esta forma, será posible tratar ciertas cuestiones que hasta ahora han pasado de-

sapercibidas y que pueden resolver las de�ciencias que tradicionalmente han venido presentando

dichos modelos [340, 297, 28, 15, 84]. Así, con el objetivo de cubrir esta necesidad y dar un paso

más allá en el Área de la Detección de Intrusiones se ha planteado y llevado a cabo el presente

desarrollo.

1.2. El papel innovador de la Detección de Intrusiones para dis-

positivos móviles

Expertos en seguridad de todo el mundo alertan sobre el crecimiento extraordinario de virus,

gusanos y troyanos que han encontrado en los terminales de telefonía móvil un nuevo objetivo

UDP. En el caso de utilizar trá�co TCP serían necesarios 1,3 segundos.13Vulnerabilidad o Vulnerability: �A �aw or weakness in a system's design, implementation, or operation and

management that could be exploited to violate the system's security policy.� [288]

12

a atacar, y sólo es cuestión de tiempo que alcancen las cifras de pérdidas económicas de sus

homólogos cableados, según a�rman especialistas como Aaron Davidson, Chief Executive O�-

cer de SimWorks International, uno de los grandes fabricantes mundiales de servicios móviles,

Bruce Hughes, investigador de la compañía TruSecure, o Norman Bennett, Gerente General de

Symantec Corporation; dos de los grandes fabricantes de soluciones de seguridad.

Así pues, son muchos los fraudes que puede perpetrar esta nueva generación de ataques

informáticos, y contra los que actualmente no existen soluciones de seguridad, con la honrosa

excepción de dos embrionarias herramientas antivirus como son F-Secure Mobile y Kaspersky, que

aún tienen un marcado carácter experimental. De esta forma, un hacker puede infectar el móvil de

un usuario mediante un código malicioso (malware) que realice arbitrariamente establecimientos

de llamadas (con las consiguientes pérdidas económicas), envíos masivos de SMS, MMS, etc. (el

denominado robo de servicio), o incluso espionaje de la información sensible (datos privados,

información bancaria, claves de acceso, etc.) almacenada en la memoria de dicho terminal.

Asimismo, es posible la automatización de estos ataques, lo que ha dado origen a una nueva

generación de gusanos auto-propagables, que pueden reenviarse, por ejemplo, a la lista de con-

tactos; aunque, a través de protocolos wireless como Bluetooth u 802.11a/b/g [Wi-Fi], ni siquiera

es necesario este pequeño conocimiento previo de las víctimas (Overview de vulnerabilidades de

Securityfocus).

Por otro lado, y entrando en un área tecnológica también en creciente expansión, cada vez

son más los dispositivos y soluciones domóticas y de inteligencia ambiental (Ambiental Intelli-

gence, AmI) que abogan por la utilización de tecnologías y protocolos móviles para resolver sus

requisitos de interoperabilidad y conectividad, por lo que, en caso de intrusión, no sólo quedaría

en compromiso el teléfono del usuario, sino toda su red doméstica.

Por último, también son posibles ataques de denegación de servicio [DoS] que inutilicen un

teléfono o dispositivo, o que saturen hasta la inoperancia el ancho de banda de la red telefóni-

ca. En este ámbito, existe un terminal especialmente amenazado: El teléfono con soporte lógico

de aplicaciones basado en Sistema Operativo, como Windows Mobile, o Symbian. Estos móvi-

les tienen conectividad total con Internet, funcionan como mini-ordenadores, y pueden alojar

programas (que perfectamente pueden ser subversivos) como cualquier PC; de forma que here-

dan automáticamente las problemáticas de seguridad que tradicionalmente han venido sufriendo

éstos.

Además, según varias consultoras tecnológicas como Gartner, Nielsen-NetRatings o IDC, el

crecimiento en el número de ventas de estos dispositivos que se espera es extraordinario. Por

ejemplo, según la �rma IDC, el número de estos aparatos vendidos en 2008 puede superar los

130 millones de unidades, un 15% del parque mundial. Según ARC Group, en 2004 se vendieron

27 millones de unidades, casi el 5% del total de móviles vendidos en todo el mundo. Las cifras

de la �rma británica Canalys, que tratan los dos grandes tipos de terminales: los de voz (móviles

sincronizables con PC y Smartphones con posibilidad de cargar aplicaciones) y los de datos

13

(Handhelds o PDAs, con o sin conexión inalámbrica a redes); muestran crecimientos de hasta

un 101% en el caso de los teléfonos móviles y de un 5% en el caso de los PDA. Asimismo, el

fabricante PalmOne (líder del mercado) obtuvo unas ventas de 1.503.590 equipos en el último

cuarto de 2004, un 8% más que en 2003, e incrementó un 154% las ventas de sus conocidos

terminales Treo.

Por otro lado, según cifras de IDC, cada semana se venden en todo el mundo alrededor

de tres millones de dispositivos con tecnología inalámbrica Bluetooth (especialmente sensible a

manipulaciones subversivas), incluyendo no sólo teléfonos móviles, sino también componentes de

automoción, dispositivos domóticos, accesorios informáticos, etcétera, etcétera, y se preveía para

2008 un parque de unos 922 millones de unidades en todo el mundo. También es importante,

ya en un ámbito más local, el crecimiento de líneas UMTS que se espera en el estado: Según el

consejero delegado de Telefónica Móviles, Javier Aguilera, "Esperamos que en 2005 haya más de

un millón de líneas". A lo que hay que añadir, además del crecimiento del mercado mundial, los

más de 300 millones de Euros que preveía invertir Amena, y los 1700 de Telefónica Movistar.

Por otro lado, según consultoras como Tatum o Nielsen-NetRatings, u organizaciones como

la International Telecommunication Union (ITU), el previsible aumento de transacciones eco-

nómicas realizadas a través de móviles es susceptible de convertirse en el principal motor del

malware móvil, al igual que ocurrió con el auge del e-business en el mundo. Los distintos tipos

de gusanos, virus y demás, permitirán el acceso a contraseñas, información bancaria o datos cor-

porativos de millones de clientes que comienzan realmente a usar el móvil para realizar compras

y operaciones �nancieras, sobre todo en Europa y Japón. Se estima que en 2004 más de cuatro

millones de personas usaron el teléfono móvil en el estado para pagar sus compras, según cifras

de la Comisión del Mercado de las Telecomunicaciones.

Por último, también es importante prestar atención al impacto que ESIDE-Mendizale puede

producir en el tejido empresarial vasco, siendo dos las incidencias positivas se detectan a priori:

Por un lado, este proyecto y los estudios sobre los que se basa pueden servir como base para

el desarrollo de un producto de calidad de protección de terminales móviles, precisamente en

un momento en el que la coyuntura mundial y local es muy favorable. Qué decir tiene que un

fabricante de soluciones de seguridad como Panda Software (recientemente galardonada con el

premio "Con mucho gusto" del Departamento de Industria, Comercio y Turismo del Gobierno

Vasco), una las grandes empresas fabricantes de soluciones de seguridad informática a nivel

mundial, y con la que la Facultad de Ingeniería - ESIDE mantiene unas estrechas relaciones,

adquiriría una considerable ventaja competitiva a raíz de este estudio, adelantándose a aquellos

competidores que aún no han contemplado la cuestión móvil entre sus prioridades.

Por otro lado, la cuestión de la seguridad es un problema cada vez más acuciante para orga-

nizaciones y empresas que cada vez más hacen uso de soluciones de movilidad para proporcionar

mayor �exibilidad a sus procesos de negocio, y aunque existen herramientas que aportan cierta

seguridad, se está aún muy lejos de una solución de�nitiva.

14

Este proyecto puede sentar las bases para el desarrollo de una arquitectura de seguridad ro-

busta, �exible y económica, que reduzca las pérdidas por hacking móvil a su mínima expresión.

Además, este proyecto está orientado a servir como solución a un problema ampliamente exten-

dido en empresas, organizaciones y usuarios particulares con todo tipo de per�les, por lo que su

área potencial de implantación es muy amplia.

Así pues, ante un considerable volumen de actividad, es posible plantear una línea de servicio

en un operador de telefonía como puede ser Euskaltel (con quien la Facultad de Ingeniería -

ESIDE mantiene unas estrechas relaciones), que se vería en situación de poder ofrecer un servicio

de seguridad diferenciador y de valor añadido a sus clientes.

Realmente los bene�cios que se conseguirían gracias a la reducción drástica de las pérdidas

económicas debidas al acceso ilegítimo de intrusos a los recursos móviles de empresas y particu-

lares, podrían llegar a ser muy importantes a medio plazo.

Para �nalizar, también es interesante tener en cuenta los bene�cios que podría reportar

ESIDE-Mendizale a aquellas empresas que emplean a los alumnos del Máster en Seguridad de la

Información que se desarrolla en la Facultad de Ingeniería - ESIDE. Dicho Máster en Seguridad de

la Información acoge todos los años a un buen número de alumnos, que posteriormente incorporan

los conocimientos adquiridos a su trabajo cotidiano en empresas como Panda Software, Euskaltel,

IT-Deusto, Vodafone o Telefónica Movistar.

A este respecto, tal y como se ha hecho con los resultados del proyecto ESIDE-Depian (sub-

vencionado por Diputación Foral de Bizkaia a través de del programa Bizkaitek 2004) se pretende

incluir en el módulo relativo a técnicas IDS/IPS un epígrafe con resultados y conclusiones obte-

nidas en el proyecto, lo que redundará aún más en la difusión de los mismos.

1.3. Conceptos Fundamentales

Es importante presentar algunos conceptos básicos, sobre los cuales está basada la presente

memoria de proyecto. En primer lugar se de�nen algunos conceptos fundamentales de Seguri-

dad de la Información, y a continuación se pasa a de�nir conceptos básicos de Detección de

Intrusiones.

1.3.1. Conceptos Fundamentales de la Seguridad de la Información

A pesar de que en el Área de la Seguridad de la Información no existe un acuerdo universal

sobre el propio concepto de Seguridad, una de�nición plausible puede ser la que proporciona el

RFC2828 [288]:

De�nición 1.1, Seguridad: �(1) Measures taken to protect a system. (2) The condition of a

system that results from the establishment and maintenance of measures to protect the system.

(3) The condition of system resources being free from unauthorized access and from

15

unauthorized or accidental change, destruction, or loss.14�

La cual da paso de forma natural al siguiente concepto:

De�nición 1.2, Seguridad de la Información: �The protection of data from disclosure,

alteration, destruction, or loss that either is accidental or is intentional but unauthorized.� 15�

No obstante, es posible obtener una de�nición más representativa del concepto a partir de

la evolución que ha sufrido el mismo hasta nuestros días. En un primer momento el área de

conocimiento de la Seguridad de la Información tenía como objetivo fundamental la protección

de dicha información contra accesos no autorizados; es decir, ser garante de la con�dencialidad

de la misma. Sin embargo, con la proliferación de redes de comunicación como Internet, y el

alto grado de conectividad que proporcionan, además, apareció la necesidad de proteger esa

misma información contra modi�caciones o alteraciones no autorizadas. Surgió de esa forma un

segundo objetivo: Era necesario garantizar también la integridad de la información. Además,

dichas redes de comunicación también propiciaban cierto tipo de agresiones, conocidas como

ataques de denegación de servicio16, que imposibilitaban el legítimo acceso a la información,

simplemente saturando el sistema informático hasta la inoperancia; de forma que fue necesario

incorporar a la de�nición de Seguridad de la Información el concepto de disponibilidad para

incluir esta cuestión. Finalmente, con el extraordinario desarrollo que han venido presentando

las transacciones económicas electrónicas, han aparecido dos nuevas problemáticas. Por un lado,

es necesario prestar especial atención a la cuestión de la autenticación de las partes implicadas

en dichas transacciones. Además, también es perentorio garantizar la responsabilidad de las

acciones tomadas por dichas partes. No puede darse la posibilidad de que los hechos de una de

las entidades implicadas en una transacción, sean repudiados por dicha entidad.

De esta forma, podemos encontrar una excelente de�nición de Seguridad de la Información

en la conferencia que pronunció Danniel G. Wolf [139], Information Assurance Director de la

National Security Agency [262], en el Federal Information Security Reform Act 2.002, la cual se

incluye a continuación, adaptada por cuestión de espacio17:

De�nición 1.3, Seguridad de la Información: �The condition of a system that results from

the establishment and maintenance of measures that assure information con�dentiality and

14Como puede observarse, el RFC2828 proporciona tres de�niciones, cada una de las cuales adquiere un mayornivel de concreción respecto a las precedentes: (1) Conjunto de medidas utilizadas para proteger un sistema. (2)Estado de un sistema que resulta del establecimiento y mantenimiento de medidas de protección para dicho siste-ma. (3) Estado en el que los recursos de un sistema se encuentran libres del peligro de ser accedidos, modi�cados,destruidos o dañados sin autorización.

15Protección de los datos contra la divulgación, alteración, destrucción o menoscabo, ya sean éstas accidentales,o intencionadas pero no autorizadas.

16Denegación de servicio o Denial of Service: �The prevention of authorized access to a system resource or thedelaying of system operations and functions.� [288]

17Lindqvist introduce idénticas re�exiones en la de�nición de Seguridad de la Información que propone en sutesis doctoral [358].

16

integrity, availability, authenticity and non-repudiation in computer and communication

systems.18�

De hecho, Wolf va más allá del concepto tradicional e incluye las cuestiones de la detección

de intrusiones y la respuesta automática ante ellas como parte fundamental de la protección de

la información; tal es la importancia que está alcanzando este campo en el área de la Seguridad

de la Información:

De�nición de Wolf, Seguridad de la Información: �In an age of constant probes and

attacks of on-line networks, however, an increasingly important element of protection deals with

operational responsiveness in terms of detecting and reacting to these time-sensitive events. 19�

Una vez desarrollado el concepto fundamental, existe toda una colección de términos a su

alrededor, los cuales pueden consultarse en la abundante bibliografía al respecto [127, 177, 151,

352, 288][OSSTMM03]. A continuación, se incluyen los más importantes y sobre los que está

basada la anterior de�nición de Seguridad de la Información [288]:

De�nición 1.4, Con�dencialidad: �The property that information is not made available or

disclosed to unauthorized individuals, entities, or processes; i.e., to any unauthorized system

entity.20�

De�nición 1.5, Integridad: �The property that data has not been changed, destroyed, or lost

in an unauthorized or accidental manner.21�

De�nición 1.6, Disponibilidad: �The property of a system or a system resource being

accessible and usable upon demand by an authorized system entity, according to performance

speci�cations for the system; i.e., a system is available if it provides services according to the

system design whenever users request them.22�

De�nición 1.7, Autenticidad: �The property of being genuine and able to be veri�ed and be

trusted.23�18Estado de un sistema que resulta del establecimiento y mantenimiento de medidas de seguridad que aseguran

la con�dencialidad e integridad de la información, así como disponibilidad, autenticidad y no repudio en sistemasde computación y de comunicaciones.

19En una época de constantes rastreos y ataques contra redes de comunicación, un aspecto de seguridad cadavez más importante es el de presentar una respuesta operativa, en términos de detectar y reaccionar ante esoseventos que se producen en tiempo real.

20Propiedad por la cual la información no se hace disponible ni se divulga a individuos, entidades o procesosno autorizados; esto es, a cualquier entidad del sistema.

21Propiedad por la cual los datos no se modi�can, destruyen o dañan, de forma no autorizada o accidental.22Propiedad de un sistema o de un recurso de sistema de ser utilizable ante la demanda de una entidad de

sistema autorizada, de acuerdo con las especi�caciones de rendimiento de dicho sistema; esto es, un sistema esdisponible si proporciona sus servicios de acuerdo a su diseño en cualquier momento en el que los usuarios losoliciten.

23Propiedad de ser genuino y hábil para ser veri�cado y recibir con�anza.

17

De�nición 1.8, Repudio: �Denial by a system entity that was involved in an association

(especially an association that transfers information) of having participated in the

relationship.24�

1.3.2. Conceptos de Detección de Intrusiones

A continuación se describen los términos fundamentales de Detección de Intrusiones sobre

los cuales está basado el presente trabajo de investigación, y que se utilizarán frecuentemente a

lo largo de esta memoria [288]:

De�nición 1.9, Ataque: �An assault on system security that derives from an intelligent

threat, i.e., an intelligent act that is a deliberate attempt (especially in the sense of a method

or technique) to evade security services and violate the security policy of a system.25�

De�nición 1.10, Intruso: �An entity that gains or attempts to gain access to a system or

system resource without having authorization to do so.26�

De�nición 1.11, Intrusión: �A security event, or a combination of multiple security events,

that constitutes a security incident in which an intruder gains, or attempts to gain, access to a

system (or system resource) without having authorization to do so.27�

Respecto a la de�nición de Intrusión, también es interesante prestar atención a la propuesta

por Zamboni [92], en la cual se relaciona explícitamente la intencionalidad de la de�nición de

Shirey con los conceptos de Seguridad de la Información descritos anteriormente:

De�nición 1.12, Intrusión: �Any set of actions that attempt to compromise the integrity,

con�dentiality, or availability of a computer resource.28

29�

24Negativa de una entidad de sistema de haber estado involucrada en una asociación (especialmente en unaasociación que implique transferencia de información) o de haber participado en dicha relación.

25Asalto a la seguridad de un sistema que tiene su origen en una amenaza inteligente; esto es, un acto intelectualque debe considerarse como un deliberado intento (especialmente en la medida en que se utiliza un método o unatécnica) de evadir los servicios de seguridad y violar la política de seguridad de dicho sistema.

26Entidad que consigue o intenta conseguir acceso a un sistema o recurso de sistema sin tener autorización parahacerlo.

27Evento de seguridad, o combinación de múltiples eventos de seguridad, que constituye un incidente de segu-ridad en el cual un intruso consigue, o intenta conseguir, acceso a un sistema (o recurso de sistema) sin tenerautorización para hacerlo.

28Cualquier conjunto de acciones que intente poner en compromiso la integridad, con�dencialidad o disponibi-lidad de un recurso computacional.

29Como puede observarse, la de�nición de Zamboni no incluye los conceptos de Wolf de autenticidad y norepudio. A pesar de que esa primera de�nición es menos exhaustiva, es la que aparece de forma generalizada enla bibliografía.

18

De�nición 1.13, Detección de Intrusiones: �A security service that monitors and analyzes

system events for the purpose of �nding, and providing real-time or near real-time warning of,

attempts to access system resources in an unauthorized manner.30�

A pesar de que la de�nición de Detección de Intrusiones proporcionada por el RFC2828 es

completa y perfectamente contrastada, existen algunas cuestiones que no se abordan completa-

mente. Por ello, es interesante prestar atención a otras alternativas, entre las cuales se encuentra

la excelente de�nición de Rebecca Bace [28], que se incluye a continuación:

De�nición 1.14, Detección de Intrusiones: �Intrusion detection is the process of

monitoring the events occurring in a computer system or network and analyzing them for signs

of intrusions, de�ned as attempts to compromise the con�dentiality, integrity, availability, or to

bypass the security mechanisms of a computer or network. Intrusions are caused by attackers

accessing the systems from the Internet, authorized users of the systems who attempt to gain

additional privileges for which they are not authorized, and authorized users who misuse the

privileges given them. Intrusion Detection Systems (IDSs) are software or hardware products

that automate this monitoring and analysis process. 31�

Por otro lado, también es interesante observar la de�nición que proporciona el Instituto

SANS [177], ya que introduce una primera clasi�cación de Sistemas de Detección de Intrusiones,

en función del origen de los ataques a detectar:

De�nición 1.15, Detección de Intrusiones: �Security management system for computers

and networks. An Intrusion Detection System gathers and analyzes information from various

areas within a computer or a network to identify possible security breaches, which include both

intrusions (attacks from outside the organization) and misuse (attacks from within the

organization). 32�

De forma natural, esta de�nición de la expresión Detección de Intrusiones, como término

genérico que da nombre a un área de conocimiento, introduce el concepto Sistema de Detección

30Servicio de seguridad que monitoriza y analiza los eventos del sistema con el propósito de encontrar intentosde acceso a recursos de sistema de forma no autorizada, y proporcionar aviso en tiempo real (o cerca del tiemporeal) sobre ellos.

31Detección de Intrusiones es el proceso de monitorizar los eventos que se dan en un sistema de computacióno en una red de comunicaciones, y analizarlos en busca de signos de intrusión; de�nidos éstos como intentos deponer en compromiso la con�dencialidad, integridad o disponibilidad, o de evadir los mecanismos de seguridadde dicho sistema o red. Dichas intrusiones son causadas por atacantes que consiguen acceder a sistemas desdeInternet, por usuarios autorizados de dichos sistemas que intentan obtener privilegios adicionales para los cualesno están autorizados, o por usuarios autorizados que hacen un mal uso de los privilegios que se les han otorgado.Por otro lado, los Sistemas de Detección de Intrusiones (IDS) son productos software o hardware que automatizaneste proceso de monitorización y análisis.

32Sistema de gestión de la seguridad para computadores y redes. Un Sistema de Detección de Intrusionesrecoge y analiza información de diferentes áreas dentro de dicho computador o red, con el objetivo de identi�carposibles brechas de seguridad, entre las cuales se incluyen tanto intrusiones (ataques provenientes del exterior dela organización) como usos indebidos (ataques provenientes del interior de dicha organización).

19

de Intrusiones, como realización instrumental del mismo. Bace ya daba paso a esta cuestión en

la de�nición anterior, si bien existen otras que tratan especí�camente dicho concepto, como por

ejemplo la que da Zamboni en su tesis doctoral:

De�nición 1.16, Sistema de Detección de Intrusiones: �A computer system (possibly a

combination of software and hardware) that attempts to perform intrusion detection.33�

Por último, existe un concepto que adquiere especial relevancia en el presente trabajo de

investigación, ya que es la piedra angular sobre la cual se ha desarrollado el mismo, y que

se denomina Detección de Anomalías. El exhaustivo documento recopilatorio de Julia Allen

[15] recoge una excelente de�nición, si bien es un concepto que se desarrollará en profundidad

posteriormente:

De�nición 1.17, Sistema de Detección de Anomalías: �Analysis method that identi�es

any unacceptable deviation from expected behavior. Expected behavior is de�ned, in advance,

by a manually developed pro�leor by an automatically developed pro�le. An automatically

developed pro�le is created by software that collects and processes characteristics of system

behavior over time and forms a statistically valid sample of such behavior. Note that

unexpected behavior is not necessarily an attack; it may represent new, legitimate behavior

that needs to be added to the category of expected behavior. 34�

1.3.3. Modelo general de funcionamiento

Desde la aparición de la Detección de Intrusiones a principios de la década de los ochenta

[20] y hasta nuestros días, los diferentes enfoques propuestos han venido manteniendo, a pesar de

sus lógicas particularidades, un esquema de funcionamiento común. Por lo general, las respon-

sabilidades de todo Sistema de Detección de Intrusiones son la captura de datos del sistema de

información, el análisis de dichos datos en el intento de detectar algún tipo de actividad subver-

siva a partir de ellos, y el proporcionar una respuesta ante aquellas situaciones susceptibles de

comprometer la seguridad del sistema. De esta forma, un primer modelo general de funcionamien-

to quedará compuesto por estos tres pilares fundamentales: Recogida de información, Análisis y

Respuesta [116, 351, 17, 28, 334, 26, 100, 204, 84, 216, 154]. La �gura 1.10 describe dicho modelo

general.

33Sistema de computación (posiblemente combinación de software y hardware) que intenta llevar a cabo la tareade detectar intrusiones.

34Método de análisis que identi�ca cualquier desviación inaceptable respecto del comportamiento esperado.Dicho comportamiento se de�ne, a priori, mediante un per�l que puede construirse manual o automáticamente.Un per�l construido automáticamente se realiza mediante un software que recoge y procesa características delcomportamiento del sistema a lo largo del tiempo, y que produce un modelo estadístico de dicho comportamiento.Es interesante observar que un comportamiento no esperado no es necesariamente un ataque; simplemente puederepresentar nuevo y legítimo comportamiento que necesitará ser incorporado a la categoría de comportamientoesperado.

20

Figura 1.10: Modelo General de Funcionamiento

Como puede observarse, las tres fases de este modelo se llevan a cabo de forma secuencial

y por lo general ininterrumpida, ya que la mayoría de Sistemas de Detección de Intrusiones se

plantean el objetivo de responder ante los diferentes eventos del sistema en tiempo real [255].

Por otro lado, esta división en fases del modelo general, introduce una categorización de los

diferentes tipos de Sistemas de Detección de Intrusiones, en función de la �losofía de diseño que

se sigue en cada una de ellas. De esta manera, existen diferentes tipos de Sistemas de Detección

de Intrusiones dependiendo de la fuente de información utilizada durante el proceso de recogida

de información, dependiendo de la �losofía de análisis que se sigue a la hora de determinar si un

determinado comportamiento es legítimo o subversivo, y en función también del tipo de respuesta

que se proporciona.

Así pues, existen dos fuentes de información fundamentales, que introducen una primera ca-

tegorización. El objetivo fundamental de la fase de recogida de información es obtener y registrar

todo aquel dato que sea susceptible de haber tenido cualquier tipo de relación con las acciones de

los usuarios del sistema. A continuación, a partir de esos datos, la fase de análisis deberá decidir

qué comportamientos están justi�cados y cuáles no, y por último la fase de respuesta actuará

en consecuencia. Para ello, en todo sistema informático, existen dos lugares fundamentales de

los cuales es posible extraer este tipo de información [116, 205, 340, 336, 240, 26, 100, 204]. Por

un lado, las acciones de todo usuario quedan registradas por el servicio de auditoría del Sistema

Operativo o por los registros históricos de los servicios de aplicación que corren en una deter-

minada máquina35, de forma que ésta se convierte precisamente en el primer punto natural del

cual obtener información para el proceso de análisis. Esta ubicación da origen a los denominados

Sistemas de Detección de Intrusiones orientados a la Máquina, e introduce la siguiente de�nición

[177]:

De�nición 1.18, Sistema de Detección de Intrusiones orientado a la Máquina (Host

Intrusion Detection System): �Intrusion detection systems that use information from the

35Algunas fuentes [351, 92, 28, 15, 84, 50] consideran que esta forma de recogida de información constituye porsí misma una tercera categoría de Sistema de Detección de Intrusiones.

21

operating system audit records to watch all operations occurring on the host that the intrusion

detection software has been installed upon.36 [...]�

Por otro lado, dado el extraordinario grado de conectividad que presentan hoy en día los

sistemas de información [58], es difícil que se dé el caso de un intruso que acceda físicamente a

su víctima, y sin embargo es mucho más probable que su asalto se realice a través de algún tipo

de red de comunicación. De esta forma, el trá�co de red se convierte en el medio de transporte

habitual de las órdenes que dicho intruso envía hacia el sistema atacado, y por lo tanto en el

segundo punto lógico de captura de información. Análogamente al caso anterior, esta ubicación

da origen a los denominados Sistemas de Detección de Intrusiones orientados a la Red, e introduce

su correspondiente de�nición [177]:

De�nición 1.19, Sistema de Detección de Intrusiones orientado a la Red (Network

Intrusion Detection System): �Intrusion Detection System that monitors the tra�c on its

network segment as a data source.37 [...]�

Cada uno de estos enfoques presenta sus particularidades, sus ventajas, sus capacidades, sus

inconvenientes y sus limitaciones; aspectos todos ellos que serán tratados en profundidad más

adelante. En general, los sistemas orientados a la máquina consiguen una mayor precisión en

la decisión de análisis, a costa de circunscribir su ámbito de actuación al sistema que protegen

[336, 240]. Asimismo, dependen enormemente de la plataforma software sobre la cual operan.

Por su parte, los sistemas orientados a la red son capaces de salvaguardar por sí mismos redes

enteras de ordenadores, si bien no tienen la precisión de los anteriores y no resuelven por lo

general ciertos problemas, como el análisis de trá�co de red cifrado [17, 28, 15, 26].

Por otro lado, la fase de análisis también presenta una clara dicotomía38, en función del

método de análisis que se emplea [116, 351, 17, 28, 388, 100, 204, 84, 216]. Por un lado, es ha-

bitual utilizar técnicas de Inteligencia Arti�cial basadas en reconocimiento de patrones39, para

representar todo el conocimiento de que se dispone sobre la actividad subversiva que se pretende

detectar. Así, es posible construir una lista negra40 que incluye todos los comportamientos mali-

ciosos conocidos hasta el momento, para a continuación pasar a contrastar la actividad cotidiana

de los usuarios del sistema con dicha lista.

Esta �losofía de detección se denomina Detección de Usos Indebidos o Detección basada en

Conocimiento41, y se caracteriza por su elevada precisión a la hora de decidir la legitimidad36Sistema de Detección de Intrusiones que usa información del registro de auditoría del sistema operativo para

observar todas las operaciones que tienen lugar en la máquina en la que está instalado el software de detecciónde intrusiones.

37Sistema de Detección de Intrusiones que monitoriza el trá�co de su segmento de red como fuente de datos.38Algunas fuentes establecen una tercera categoría, denominada Detección de Anomalías de Protocolo [Go-

lomb03, Das01, Axelsson00].39Reconocimiento de patrones o pattern matching. En el área de la Detección de Intrusiones también se utiliza

habitualmente el concepto de �rma o signature.40Lista negra o blacklist.41Detección basada en Conocimiento o Knowledge-based Detection.

22

de una determinada acción. Sin embargo, adolece de ciertos problemas, entre los cuales el más

relevante es su absoluta falta de respuesta ante ataques aún no documentados. Un intruso puede

construir una ligera variante de un ataque clásico, o por supuesto un ataque completamente

nuevo, y evadir así la vigilancia del Sistema de Detección de Intrusiones. Rebecca Bace y Peter

Mell proponen una buena de�nición [28]:

De�nición 1.20, Detección de Usos Indebidos (Misuse Detection): �Detection method

that analyzes system activity, looking for events or sets of events that match a prede�ned

pattern of events that describe a known attack.42 [...]�

Otro método de detección, que precisamente trata de ir más allá de las limitaciones inherentes

a los métodos de Detección de Usos Indebidos, y conseguir que los Sistemas de Detección de

Intrusiones puedan responder ante ataques novedosos43, no documentados, es la Detección de

Anomalías o Detección basada en Comportamiento44. Esta �losofía de detección también está

basada en técnicas de Inteligencia Arti�cial, pero plantea una forma de análisis complementaria a

la anterior. En lugar de utilizar el conocimiento subversivo conocido para llevar a cabo el proceso

de decisión, utiliza el conocimiento legítimo45. De esta forma, a partir de las acciones habituales

de los usuarios, se construye un per�l de comportamiento que posteriormente es contrastado con

la actividad cotidiana que se registra durante la explotación normal del sistema.

Así, es posible detectar acciones que se salen de la forma de proceder habitual de dichos

usuarios; acciones entre las cuales se encuentran los novedosos modos de ataque mencionados

anteriormente. A este respecto, es importante destacar el hecho de que con este modo de operación

se consigue que el proceso de detección sea completo [100]; característica de la que adolecen los

sistemas de Detección de Usos Indebidos. Además de la de�nición enunciada por Julia Allen e

incluida en el apartado anterior, existe otra precisa alternativa, propuesta también por Bace y

Mell [28]:

De�nición 1.21, Detección de Anomalías (Anomaly Detection): �Detection method

that identi�es abnormal unusual behavior (anomalies) on a host or network.46 [...]�

Este enfoque proporciona capacidad de respuesta ante los peligrosos Zero-Day Attacks y

llega más allá de las habilidades propias de los Sistemas de Detección de Usos Indebidos. No

obstante, también presenta un importante inconveniente: Un nuevo elemento o componente en

el sistema introduce de forma natural nueva actividad, la cual no deja de ser legítima y, sin

42Método de detección que analiza la actividad del sistema, en busca de eventos o conjuntos de eventos queconcuerden con un patrón de eventos prede�nido que describe un ataque conocido.

43Conocidos como zero-day attacks, en contraposición con los anteriormente mencionados ataques conocidos owell-known attacks.

44Detección basada en Comportamiento o Behaviour-based Detection.45En este caso se está usando política de lista blanca o whitelist.46Método de detección que identi�ca comportamiento inusual o anormal (anómalo) en una máquina o en una

red.

23

embargo, es cali�cada por el sistema de detección como subversiva [15, 26]. Esta cuestión obliga

a una actualización continua del per�l de comportamiento, y hace que el sistema presente una

indeseada característica conocida como falso positivo47 48 49. Una buena de�nición es la que

proponen Ptacek y Newsham [385]:

De�nición 1.22, Falso Positivo (False Positive): �An event, incorrectly identi�ed by the

Intrusion Detection System as being an intrusion when none has occurred.50�

Asimismo, Ptacek y Newsham también proponen la correspondiente de�nición del concepto

complementario: el falso negativo.

De�nición 1.23, Falso Negativo (False Negative): �An event that the Intrusion Detection

System fails to identify as an intrusion when one has in fact occurred.51�

Existe una gran colección de estudios realizados en el área de la Detección de Anomalías

[116, 227, 26, 50], si bien aún no se ha conseguido un modelo que consiga integrar todos los

bene�cios que teóricamente caracterizan a este tipo de enfoques [165]. La práctica totalidad de

productos comerciales aún no se ha decido por ella, y se siguen utilizando modelos basados en

Detección de Usos Indebidos [116, 351, 205, 78, 28, 204, 49], debido fundamentalmente a que su

e�cacia aún es discutida y al mencionado problema de los falsos positivos [116, 28].

Por último, la fase de respuesta, que tradicionalmente ha mantenido una única �losofía de

funcionamiento, también ha visto aparecer en los últimos tiempos un nuevo enfoque. De esta

forma, al clásico método de respuesta pasivo consistente en la simple noti�cación de eventos de

alarma al administrador, se suma la posibilidad de llevar a cabo una reacción activa, como puede

ser la recon�guración del entorno de la víctima para aislarla del agresor. Asimismo, también es

posible activar la recogida detallada de información, de cara a la toma de las pertinentes acciones

legales, o pasar directamente al contraataque [28].

Además, actualmente, la tendencia consiste en hacer que esta reacción suponga el �ltrado de

las acciones del usuario, para lo cual el Sistema de Detección de Intrusiones debe ubicarse en un

punto del sistema en el que sea posible interceptar las órdenes de dicho usuario. De este modo,

es posible analizar dichas órdenes antes de ser enviadas �nalmente al sistema para su ejecución.

47Falso positivo o falsa alarma. Un Sistema de Detección de Intrusiones basado en Detección de Anomalías conuna con�guración de�ciente puede saturar de falsos positivos al administrador de dicho sistema, incapacitándoleincluso para responder ante los verdaderos ataques [Newman+02].

48Se estima que es bastante común obtener ratios de alrededor de diez falsos positivos por cada alarma real[78].

49En contraposición con el fenómeno del falso positivo, se encuentra el denominado falso negativo. Esta cuestiónes incluso más preocupante que la anterior, ya que es fruto de la falta de reacción del sistema de detección anteun cierto ataque. Sin embargo, dado el enorme riesgo que supone, es habitual optar por soluciones de compromisoque eliminen la posibilidad de su aparición, por lo general a costa de perjudicar la tasa de falsos positivos.

50Evento incorrectamente identi�cado como intrusión por el Sistema de Detección de Intrusiones, cuando porel contrario no ha ocurrido tal intrusión.

51Evento no identi�cado como intrusión por el Sistema de Detección de Intrusiones, cuando por el contrario síes merecedor de dicha identi�cación.

24

Figura 1.11: Taxonomía general

Este método de respuesta recibe la denominación de Prevención de Intrusiones y pretende dar

un paso más allá en la evolución.

De hecho, algunos autores consideran que dicha tecnología deberá constituir a medio plazo el

método de respuesta por defecto de todo Sistema de Detección de Intrusiones [337, 341], aunque

aún existen poderosas argumentaciones en contra [133]. Timothy Wickham propone una precisa

de�nición de Sistema de Prevención de Intrusiones en su polémico artículo Intrusion Detection

is Dead. Long Live Intrusion Prevention! :

De�nición 1.24, Sistema de Prevención de Intrusiones (Intrusion Prevention

System): �System that actively monitor a network or host for attacks and block those attacks

from occurring.52�

De esta forma, a partir de las tres categorizaciones descritas es posible plantear una prime-

ra taxonomía general, que ilustra de forma conveniente una primera aproximación al área de

conocimiento de la Detección de Intrusiones. La �gura 1.11 ilustra dicha taxonomía

52Sistema que monitoriza activamente una red o una máquina en busca de ataques, y que evita que dichosataques ocurran.

25

1.3.4. Características de los diferentes enfoques

En la actualidad aún no se ha desarrollado un modelo conceptual de Sistema de Detección de

Intrusiones de amplio espectro que minimice los inconvenientes que parecen estar inherentemente

asociados a sus diversas alternativas. Cada uno de los enfoques de diseño existentes proporciona

soluciones a determinadas cuestiones, pero adolece invariablemente de ciertos problemas, por lo

que se hace necesario contemplar la vía de la integración de múltiples métodos de análisis como

el camino a seguir [65, 116, 165, 398, 15, 105]. A continuación se incluye una relación de las

ventajas e inconvenientes que presentan cada una de las ramas de la taxonomía del apartado

anterior.

0.3.4.1 Recogida de información

Respecto a la cuestión de la recogida de información, o lo que es lo mismo, al objetivo es-

tratégico de un Sistema de Detección de Intrusiones que de�ne su ámbito de aplicación, las

dos �losofías de funcionamiento que se han introducido anteriormente (Detección orientada a

la Máquina y Detección orientada a la Red) presentan poderosas capacidades, que convierten a

ambas en extraordinarias herramientas de seguridad en prácticamente todo tipo de sistemas. Sin

embargo, ambos métodos muestran importantes debilidades, que hacen necesario un profundo

esfuerzo de re�exión, de cara a la consecución de un modelo híbrido que maximice las capacida-

des reduciendo los inconvenientes [116, 164, 240, 92, 15, 204]. A continuación se relacionan las

cualidades y defectos de ambas.

0.3.4.1.1 Detección de Intrusiones orientada a la Máquina

La Detección de Intrusiones orientada a la Máquina fue el primer enfoque de diseño sobre

el que se empezó a trabajar en los orígenes de la Detección de Intrusiones [20], y constituye

probablemente la rama sobre la que tradicionalmente se ha desarrollado un mayor número de

investigaciones. En general, este tipo de detección está considerado como el potencialmente más

exacto en la toma de decisiones, debido simplemente a su ubicación dentro del propio sistema que

se pretende proteger. Este emplazamiento permite que el Sistema de Detección pueda determinar

con precisión los usuarios y procesos que están involucrados en un determinado ataque. Además,

desde esta localización, es capaz de analizar el impacto en el sistema de cualquier acción, ya que

tiene a su disposición toda la potencia del Sistema Operativo, y puede analizar detalladamente

sistemas de �cheros, interfaces de red, etcétera, de forma ágil [116, 78, 28, 240, 92].

Sin embargo, en redes corporativas de medio o gran tamaño, el alto coste administrativo

que suponen los procesos de instalación, con�guración y mantenimiento de todo un parque de

Sistemas de Detección de Intrusiones orientados a la Máquina, hace que esta solución sea inviable

en la mayoría de los casos. Por lo general su utilización queda circunscrita a sistemas servidores

[351, 28]. Éstas son las principales características de este tipo de sistemas, aunque es importante

26

prestar atención al conjunto de sus particularidades. A continuación se relacionan las ventajas e

inconvenientes que supone la utilización de esta clase de métodos.

0.3.4.1.1.1 Ventajas

Posibilidad de determinar el éxito o fracaso de un ataque

Habitualmente, los Sistemas de Detección de Intrusiones orientados a la máquina basan sus

decisiones de análisis en los registros históricos de eventos del sistema o de servicios de aplicación,

por lo que pueden obtener una medida precisa del grado de éxito o fracaso de un ataque. Los

sistemas orientados a la red, por el contrario, solamente pueden detectar intentos de intrusión,

pero no son capaces de determinar si dichos intentos han fructi�cado o no. De esta forma, en

general, los sistemas orientados a la máquina presentan una tasa de falsos positivos muy reducida,

lo que hace que sean un buen complemento de los sistemas de red: Éstos detectan los primeros

indicios de actividad sospechosa que aparecen en la red y sus homólogos orientados a la máquina

comprueban si esa actividad ha tenido impacto en el sistema o no. [351, 336, 28, 164, 240]

Monitorización de actividades especí�cas

Este tipo de sistemas de detección puede monitorizar la utilización que los usuarios de un sistema

hacen de sus recursos, pudiendo centrar su atención en cuestiones particulares como el acceso

o modi�cación de archivos, utilización de credenciales y privilegios, manipulación de software,

ejecución y manipulación de procesos, etcétera. Además, su especial ubicación hace posible que

cualquier actividad sospechosa de poner en compromiso la seguridad del sistema pueda ser no

sólo detectada, sino incluso interceptada, mediante una simple redirección de los servicios del

Sistema Operativo en el que se encuentran instalados. [351, 78, 336, 28, 164, 240, 92, 100]

Detección de ataques físicos

Evidentemente, un sistema de detección orientado a la máquina puede revelar cualquier actividad

subversiva que se lleve a cabo mediante la presencia física del intruso ante la víctima. En aquellos

casos en los que el atacante ha alcanzado tan importante nivel de acceso, un sistema orientado

a la red es incapaz de responder, ya que es posible que el intruso no necesite utilizar los recursos

de comunicaciones de dicho sistema, o que incluso sea consciente de que no debe hacerlo para

pasar desapercibido. Por el contrario, un sistema de detección orientado a la máquina no tiene

ninguna di�cultad para detectar dicha intrusión y noti�carla convenientemente. [164, 92, 204]

Detección de ataques a través de medios de comunicación cifrados

Dado que este tipo de sistemas se instala directamente en la máquina a proteger, es posible dar

respuesta a un problema que tradicionalmente se ha caracterizado por la ceguera absoluta que

produce en los sistemas de detección orientados a la red, como es la cuestión del trá�co de red

27

cifrado. Para poder analizar correctamente cualquier tipo de información, un sistema de detección

orientado a la red debe ser capaz de comprender su estructura, lo cual puede convertirse en una

tarea imposible de realizar en la práctica en el caso de que el atacante decida aplicar métodos de

cifrado sobre dicha información. De esta forma, un intruso puede apoyarse en dichos algoritmos

para conseguir eludir la vigilancia del sistema de detección. Sin embargo, dado que la información

que llega al sistema atacado (conteniendo órdenes, archivos o herramientas) debe ser descifrada

antes de ser interpretada por el Sistema Operativo, un sistema de detección orientado a la

máquina no tiene di�cultad alguna para realizar su cometido. [116, 336, 28, 164, 92, 100, 204, 50]

Detección de ataques en redes de comunicación conmutadas

Una de las soluciones que tradicionalmente han abordado el problema de las escuchas ilegítimas

en redes de comunicación, como es el diseño de redes conmutadas, hace que los sistemas de

detección orientados a la red convencionales no puedan acceder a la información que necesitan

para llevar a cabo su actividad de análisis, ya que dichos entornos impiden que esa información

llegue a ellos. Sin embargo, en el caso de los sistemas orientados a la máquina, esa cuestión no

representa un problema, ya que pueden disponer de forma natural de toda la información dirigida

hacia el sistema que protegen. [340, 28, 100, 204, 50]

Reducido tiempo de respuesta

Dado que este tipo de sistemas sólo es responsable de analizar la actividad que se da en el sistema

al cual dedican su vigilancia, el volumen de información que deben analizar es relativamente

pequeño. Por ello, es posible proporcionar una respuesta en condiciones de tiempo real, o muy

cerca de ellas. De esta forma, en la mayoría de los casos, la actividad del intruso puede ser

detenida antes de que pueda producir cualquier daño en el sistema. [240, 92]

0.3.4.1.1.2 Inconvenientes

Elevado coste administrativo y económico

En el caso de utilizar Sistemas de Detección orientados a la Máquina en una red corporativa

con múltiples sistemas conectados, es necesario instalar, con�gurar, administrar y mantener un

sistema de detección en cada uno de dichos sistemas. Evidentemente, esta consideración implica

un extraordinario coste de administración, que a menudo hace que este tipo de soluciones sea

descartado. Por el contrario, un único sistema orientado a la red es capaz, por sí solo o en pequeñas

colectividades de agentes, de llevar a cabo la vigilancia de toda una red corporativa. Por ello,

los costes económicos derivados tanto de los mencionados esfuerzos administrativos, como de la

inversión económica propiamente dicha, son por lo general muy altos, en comparación con los

sistemas orientados a la red. [116, 351, 78, 28, 240, 92, 204]

Vulnerabilidad de emplazamiento

28

Dado que este tipo de sistemas de detección se ubica en el propio sistema a proteger como si

fuera un aplicativo convencional, en aquellos casos en los que el intruso consigue alcanzar cierto

nivel de operatividad en dicho sistema, aparece el riesgo potencial de que el sistema de detección

pueda ser desactivado o subvertido por dicho atacante. Por el contrario, un sistema de detección

orientado a la red es susceptible con�gurarse de forma que su presencia sea no sólo inexpugnable

sino incluso inadvertida para cualquier usuario. [351, 336, 28, 240, 92, 100, 50]

Limitada área de in�uencia

La propia idiosincrasia de estos sistemas hace que su ámbito de protección se vea limitado a un

único sistema, debido a que solamente son capaces de detectar actividad subversiva a partir de

los registros de solicitudes de servicio que los aplicativos hacen al Sistema Operativo de dicho

sistema (ya sea en el nivel de aplicación o en el nivel de servicio), o a partir del trá�co de red

exclusivamente dirigido hacia el mismo. Además, esta forma de actuación hace que el sistema de

detección sea dependiente de la plataforma software (fundamentalmente del Sistema Operativo),

lo que introduce una compleja componente de heterogeneidad en sistemas de información en los

que conviven múltiples tipos de plataformas. Un sistema de detección orientado a la red, por el

contrario, es capaz de detectar comportamientos ilegítimos dirigidos contra redes enteras, ya que

la información que maneja �uye por el medio de comunicación y está rigurosamente estandarizada

en forma de protocolos de comunicación. [351, 340, 78, 336, 28, 240, 204]

Sensibilidad del propio sistema de detección

Un intruso potencial puede orquestar un ataque de denegación de servicio dirigido hacia el propio

sistema de detección, con el objetivo de deshabilitarlo. De esta forma, una vez conseguida la des-

activación de dicho sistema, las acciones de dicho intruso pueden realizarse con total impunidad

e incluso sin dejar rastro. Ésta es una característica especialmente indeseada, tanto en este tipo

de sistemas como en sistemas de detección orientados a la red, y que debe minimizarse haciendo

especial énfasis en el desarrollo e�ciente y optimizado de toda la arquitectura interna del sistema

de detección. [336, 28, 240, 100, 204]

Alto consumo de recursos

Dado que este tipo de sistemas de detección debe ubicarse en el propio sistema a proteger,

necesita hacer uso de sus recursos para su ejecución. Por un lado, el consumo de recursos de

almacenamiento suele verse incrementado notablemente, debido al volumen que habitualmente

presentan los registros históricos de los sistemas operativos, así como al tamaño de los registros

generados por el propio sistema de detección. Por otro, también es importante el consumo de

capacidad de procesamiento que se requiere, ya que es necesario analizar cada una de las peticio-

nes de servicio que los usuarios del sistema o sus aplicativos solicitan al Sistema Operativo local.

Además, es necesario observar que, tal y como se ha explicado anteriormente, cada máquina de

29

la red corporativa debe tener instalado su propio sistema de detección, por lo que esos grandes

consumos se extienden a todo el parque informático de la organización. [116, 336, 28, 100, 204, 50]

0.3.4.1.2 Detección de Intrusiones orientada a la Red

La Detección de Intrusiones orientada a la Red constituyó una importante evolución, introdu-

cida por L. Todd Heberlein [161], del concepto de Detección de Intrusiones original. Hasta aquel

momento la protección de sistemas informáticos se había realizado desde las propias infraestruc-

turas hardware y software que se deseaban salvaguardar, y esta nueva �losofía originó un gran

interés académico, y numerosas investigaciones cientí�cas e inversiones comerciales. En general,

este tipo de detección está considerado como el más poderoso y el que mejores prestaciones ofrece

en grandes infraestructuras informáticas [240]. Su ubicación, anexa al sistema de explotación de

la organización, a través de la captura continua del �ujo de información transmitido a través

de las redes corporativas, consigue que la interferencia o sobrecarga introducidas en el sistema

sean nulas y que las decisiones generadas por el sistema de detección tengan carácter global

[50]; todo ello sin los costosos requerimientos de administración de los sistemas orientados a la

máquina. No obstante, estos sistemas también presentan algunas limitaciones, como por ejemplo

su incapacidad para detectar ataques locales o para determinar el impacto de los ataques que

detectan [28, 92]. Por otro lado, el reducido impacto económico que tiene en los presupuestos de

infraestructura de la organización, hace que la Detección de Intrusiones orientada a la Red sea

una opción muy utilizada, y que alcanza en la actualidad altas cotas de cuota de mercado [351].

En rasgos generales, éstas son las principales propiedades de este tipo de soluciones, aunque es

importante observar sus características en conjunto. A continuación se relacionan las ventajas e

inconvenientes que supone la utilización de esta clase de métodos.


Extensa área de in�uencia

Un único Sistema de Detección de Intrusiones orientado a la Red es capaz de detectar por sí mismo

cualquier tipo de actividad subversiva o anómala que utilice la infraestructura de comunicaciones

de una organización como medio de transporte, incluso en redes con alto número de sistemas

conectados. Además, en casos en los que el volumen de información que �uye a través del sistema

de información supera la capacidad de respuesta del sistema de detección, su arquitectura general

permite que el escalado de dicho sistema sea realmente sencillo y natural [92]. De esta manera,

en el caso de grandes redes corporativas, la vigilancia de los recursos computacionales del sistema

queda en manos no ya de un único sistema de detección, sino en una pequeña colectividad de

procesos agente que colaboran en las tareas de recogida de información, análisis y respuesta.

[351, 78, 336, 28, 240, 92, 204]

Nulas interferencia y sobrecarga en el sistema objetivo

30

El despliegue de este tipo de sistemas de detección tiene un impacto nulo sobre la infraestruc-

tura computacional y de comunicaciones subyacente, ya que por lo general se destina para ello

una máquina adicional dedicada en exclusiva. Así, habitualmente, un sistema orientado a la red

captura de forma pasiva el trá�co de dicha red, sin intervenir activamente en ningún momento.

Simplemente escucha, decide e informa si lo considera necesario. Por ello, esta solución es amplia-

mente adoptada por empresas y organizaciones de todo tipo [351]; en perjuicio de los sistemas

orientados a la máquina, que sí necesitan una importante cantidad de recursos provenientes del

sistema a proteger, como pueden ser memoria principal, capacidad de almacenamiento, capacidad

de procesamiento, etcétera. [116, 336, 28, 100, 204, 50]

Fortaleza de emplazamiento

Un sistema de Detección de Intrusiones orientado a la Red puede con�gurarse de manera que

sea virtualmente invisible para cualquier usuario de la organización, incluyendo por supuesto a

cualquier potencial intruso que tenga como objetivo a dicha organización. Su carácter pasivo

propicia esta característica e incluso es posible utilizar dispositivos hardware o componentes

software que garantizan dicha propiedad [83]. Existen ciertas soluciones de detección orientada a

la red que abogan por un comportamiento reactivo ante las amenazas, pero mantienen igualmente

esta propiedad de su inexpugnabilidad. Por el contrario, un sistema orientado a la máquina es

fácilmente detectable por un intruso, quien puede intentar ponerlo en compromiso para conseguir

sus �nes. Además, esta invisibilidad evita cualquier posibilidad de alteración o corrupción de los

recursos del sistema de detección mismo, de forma que los habituales métodos de eliminación de

evidencias son inviables de antemano; a pesar de que existan ciertas técnicas [385] dirigidas a

evadir la vigilancia de dicho sistema de detección. [351, 336, 28, 240, 92, 100, 50]

Detección de ataques orientados a la red

Dado que este tipo de sistemas de detección analizan todos y cada uno de los paquetes de

información que circulan por la red de comunicaciones, pueden detectar ataques que se realizan

por debajo de los niveles de aplicación o de servicio a los que habitualmente acceden los usuarios

de una máquina. Por lo general, un sistema orientado a la máquina no analiza todos los diferentes

aspectos del trá�co de red, por lo que es incapaz de detectar numerosos tipos de ataque, como

pueden ser los de denegación de servicio o los de fragmentación [385]. Por el contrario, un sistema

orientado a la red sí observa cada uno de los diferentes parámetros que componen dichos paquetes,

y puede responder de forma e�ciente ante un mayor número de amenazas. [116, 336, 240, 100, 50]

Bajo coste administrativo y económico

Debido a la notable amplitud del ámbito de in�uencia que por lo general poseen los sistemas

orientados a la red, unas mínimas tareas administrativas y de supervisión y mantenimiento son

en general su�cientes para una explotación adecuada de dicho sistema de detección. Asimismo, la

31

inversión económica necesaria se mantiene contenida en la mayoría de los casos, y es susceptible

de incrementarse progresivamente a lo largo del tiempo en aquellas situaciones cuya evolución

va requiriendo mayores prestaciones. [116, 78, 28, 240, 92, 204]

Reducido tiempo de respuesta

Al igual que los sistemas orientados a la máquina, los sistemas orientados a la red proporcionan

por lo general excelentes tiempos de respuesta, lo que permite detectar un ataque mientras se está

llevando a cabo. Esta capacidad de respuesta posibilita que el administrador reciba la noti�cación

de dicho ataque a tiempo para responder convenientemente. Además, en el caso de que el sistema

de detección incorpore capacidades de reacción, la respuesta puede en muchos casos llegar incluso

a detener el ataque en cuestión. [28, 164]

Independencia de la plataforma

Como se ha explicado anteriormente, este tipo de sistemas de detección utiliza los paquetes de

información que se transmiten por la red para tomar sus decisiones; paquetes que se caracterizan

por estar conformados en virtud de estándares que regulan sus diferentes características. Dado

que dichos estándares tienen como objetivo la de�nición formal de protocolos de comunicación

entre plataformas habitualmente heterogéneas, la información de la que se nutren los sistemas

de detección orientados a la red es compatible e interpretable por un amplio número de plata-

formas hardware y software. Esto hace que un mismo sistema de detección sea capaz de advertir

comportamientos subversivos en redes que interconectan sistemas de computación heterogéneos,

lo que lo convierte en una herramienta de seguridad excepcional. Por el contrario, los sistemas

orientados a la máquina son especí�cos de la plataforma, por lo que ante la necesidad de vigi-

lancia de sistemas de información heterogéneos son necesarias diferentes soluciones de detección;

con los costes administrativos y económicos que ello conlleva. [116, 78, 336, 240, 100, 50]


Rendimiento en redes de alta velocidad

Ante el problema de la detección de intrusiones en redes de alta velocidad, los sistemas de

detección orientados a la red adolecen por lo general de di�cultades en el correcto procesamiento

de todos los paquetes de información que �uyen por dichas redes, en situaciones de alta ocupación.

Habitualmente, dichos sistemas integran en su arquitectura interna mecanismos de control de

congestión para tratar de paliar este problema, pero, como es lógico, dichos mecanismos tienen

capacidades �nitas. Por ello, es posible la pérdida de paquetes de red que el sistema no ha sido

capaz de capturar temporalmente para su análisis. Esta característica constituye una importante

fuente de inspiración para todo tipo de intrusos, que intentan saturar el sistema de detección,

incapacitándole para responder correctamente. Actualmente, la tendencia consiste en migrar

32

el software de detección a dispositivos hardware que incrementen el rendimiento, así como la

especialización de los tipos de ataque a detectar, y la optimización de los recursos computacionales

necesarios para proporcionar una respuesta en unos márgenes de tiempo aceptables. A este

respecto, está comúnmente aceptada la consideración de estos sistemas de detección orientados

a la red como sistemas de tiempo real acríticos. [116, 336, 28, 164, 240, 92, 100, 204, 50]

Problemas de detección de ataques en redes de comunicación conmutadas

Las redes de comunicación conmutadas se utilizan actualmente de forma habitual en redes corpo-

rativas de tamaño medio y grande, y están basadas en la separación lógica de distintos segmentos

de red, lo que permite alcanzar mayores rendimientos de transferencia de información que en los

anteriores medios compartidos. Sin embargo, esta deseable característica evita el libre acceso al

trá�co de red, lo cual es una cualidad imprescindible para el funcionamiento de todo sistema de

detección orientado a la red. Para poder analizar el trá�co de información, el sistema detector

tiene que poder acceder a él. En cualquier caso, esta problemática tiene una repercusión relativa,

ya que la mayoría de dispositivos de conmutación incorpora puertos especiales53 que permiten

acceder al �ujo completo de información. Basta con conectar el sistema de detección a uno de

esos puertos para garantizar su correcto funcionamiento. [340, 28, 100, 204, 50]

Problemas de detección de ataques a través de medios de comunicación cifrados

Dado que los Sistemas de Detección de Intrusiones orientados a la Red necesitan acceder libre-

mente a la información que circula por dicha red, cualquier obstáculo a ese acceso, ya sea físico

como en el caso anterior, o lógico como en el caso en el que las comunicaciones estén sujetas a es-

quemas de cifrado de la información, incapacita a dichos sistemas para cumplir con su cometido.

Un sistema de detección que no es capaz de interpretar la información contenida en un paquete

de red, no puede realizar ningún análisis respecto de dicho paquete, ni tomar decisión alguna.

Éste es uno de los grandes handicaps que tradicionalmente ha venido sufriendo la Detección de

Intrusiones orientada a la Red, si bien existe una evolución de estos sistemas por la cual es posible

solventar este problema, y que se conoce como Detección de Intrusiones orientada al Nodo de

Red54 [84, 78, 241]. Este enfoque consiste en convertir un sistema orientado a la red en un sistema

orientado a la máquina, que analice el trá�co proveniente del subsistema de comunicaciones de

dicha máquina, después de haber sido descifrado por la capa criptográ�ca de la pila de protocolos

de red. Por supuesto, este avance implica un retroceso en la tradicional capacidad de los sistemas

orientados a la red de detectar intrusiones en grandes redes. [116, 336, 50, 28, 164, 92, 100, 204]

Imposibilidad de determinar el éxito o fracaso de un ataque

53Conocidos como tap ports o mirroring ports.54Este enfoque da lugar a los conocidos Sistemas de Detección de Intrusiones de Nodo de Red o Network Node

Intrusion Detection Systems.

33

Por lo general, los sistemas de detección orientados a la red no son capaces de determinar si un

ataque detectado por ellos ha sido exitoso para el atacante o no. Sólo pueden precisar que en un

momento dado se produjo dicho ataque. Esta particularidad obliga a que, después de detectado

un determinado ataque, el administrador del sistema deba investigar manualmente el impacto

que ha podido tener dicho ataque en su organización. [351, 336, 28, 164, 240]

0.3.4.2 Análisis

La fase de análisis constituye el núcleo central del modelo general de funcionamiento de

todo sistema de detección, ya que es en él donde deben tomarse las decisiones importantes

que afectan a la seguridad del sistema de información que se pretende proteger. La anterior

fase de recogida de información, así como la siguiente, de respuesta, están caracterizadas por

realizarse de forma prácticamente automática, mecánica. Por el contrario, en esta fase de análisis

es necesario disponer de un modelo de representación de conocimiento y de un mecanismo de

inferencia de conclusiones que sean capaces de procesar las complejas relaciones que existen

entre los múltiples parámetros que es necesario estudiar. Por supuesto, es en esta fase de análisis

donde se encuentra concentrado el mayor interés estratégico de todo el área de conocimiento

de la Detección de Intrusiones, y es en ella también donde se registra una mayor actividad

investigadora, ya que aún no se ha conseguido un modelo general que consiga superar los retos

existentes. A este respecto, es interesante observar las conclusiones que se desprenden del estudio

realizado por Emilie Lundin y Erland Jonsson sobre la actividad investigadora en el área de

la Detección de Intrusiones [379] en los últimos años55. La tabla 1.5 es ruto de dicho estudio,

y muestra claramente como la fase de Análisis es el área que oncentra un mayor interés en la

comunidad académica.

A continuación se describen las principales características de las dos grandes �losofías de

funcionamiento sobre las cuales está construida la mayoría de los componentes de análisis de

los actuales Sistemas de Detección de Intrusiones: Detección de Usos Indebidos y Detección de

Anomalías. Como se comprobará, ambos métodos proporcionan importantes bene�cios, pero no

consiguen evitar ciertas debilidades. Esta situación obliga a seguir investigando en búsqueda de

un modelo que sea capaz de aunar las ventajas de ambos métodos, minimizando en la medida

de lo posible los inconvenientes [65, 116, 351, 147, 165, 336, 28, 164, 92, 15, 26, 339].

0.3.4.2.1 Detección de Usos Indebidos

Actualmente, la Detección de Usos Indebidos es el enfoque más extendido y el que ha fructi�-

cado con mayor �rmeza en el mercado [351, 50, 28]; éxito que ha venido producido fundamental-

mente por su e�ciencia y sencillez de administración. Su principio de funcionamiento es simple:

55Para el desarrollo de este estudio se han tomado en consideración las conferencias de mayor prestigio ycontabilizado el número de publicaciones en cada una de las diferentes áreas. En la tabla 1.5 se han seleccionadosolamente las áreas descritas en el modelo general, si bien existen otras líneas de investigación laterales másespecí�cas, que escapan a los objetivos de esta introducción.

34

Cuadro 1.5: Áreas de investigación sobre Detección de Intrusiones con mayor actividad

35

A partir del conocimiento de los diferentes tipos de ataques utilizados por la comunidad hacker,

basta con recoger los eventos que se produzcan en un determinado sistema y contrastarlos contra

dicho conocimiento, para poder detectar intentos de subversión en el sistema.

Por lo general, este conocimiento se estructura en forma patrones que describen las peculia-

ridades de cada ataque. De esta forma, una base de conocimiento puede estar compuesta por

varios miles de patrones o �rmas [29, 18], cada uno de los cuales debe ser comparado con los

sucesos que van teniendo lugar en la explotación cotidiana del sistema de producción. Este modo

de operación hace que el sistema sea realmente sólido y que detecte con precisión toda actividad

maliciosa que tenga registrada en su base de �rmas. Sin embargo, es precisamente este mismo

modo de operación la causa de su más importante limitación: No es posible detectar nada que

no esté previamente documentado.

De esta manera, un intruso (que puede estar al corriente de la con�guración de las bases de

conocimiento que se estén utilizando) puede realizar una ligera modi�cación de un ataque y pasar

desapercibido para el sistema de detección. Es más, cada día aparecen ataques completamente

nuevos, que por supuesto pasan inadvertidos a los detectores, a menos que se incluyan las nuevas

�rmas. Como es obvio, esta cuestión obliga a realizar un continuo y costoso proceso de manteni-

miento, que queda en manos del operador humano, y que hace que el sistema de detección vaya

perdiendo progresivamente su e�ciencia. Ante continuas actualizaciones de la base de �rmas,

llega un momento en el que el volumen de patrones a contrastar consume más tiempo del que

tardan en producirse los eventos del sistema. El detector se satura y se empiezan a ignorar dichos

eventos. Por todo ello, si se desea conseguir una auténtica protección ante ataques novedosos,

es necesario explorar otras vías de investigación que complementen a los sistemas basados en

�rmas. [116, 147, 84, 165, 28, 26, 100, 204]

A continuación se relacionan las ventajas e inconvenientes fundamentales que presenta este

tipo de sistemas de detección:


Precisión en la detección

Los Sistemas de Detección de Usos Indebidos son muy efectivos en la detección de los ataques

que tienen documentados. Esto es debido a que su principio de funcionamiento se reduce a la

comparación de la actividad cotidiana del sistema que se pretende proteger, con una base de

�rmas de ataques que se construye a partir de vasto conocimiento experto sobre métodos de

intrusión y procedimientos para explotar vulnerabilidades conocidas. De esta forma, cualquier

actividad subversiva que se encuentre tipi�cada en dicha base de conocimiento es advertida

rápidamente. [116, 147, 165, 28, 26, 100]

Ausencia de falsos positivos

36

Dada la simplicidad del método de detección, no es habitual que se produzca el fenómeno del falso

positivo, siempre y cuando la base de conocimiento se encuentre convenientemente con�gurada.

Ésta es precisamente la mayor ventaja que presenta este tipo de sistemas de detección con

respecto a otros, como puede ser la Detección de Anomalías, que ha sufrido tradicionalmente

este problema. [116, 84, 28, 15, 100, 358]

Estabilidad del conocimiento

Una característica negativa que presentan algunos Sistemas de Detección de Intrusiones más

ambiciosos que los basados en la Detección de Usos Indebidos, es la posibilidad de que los modelos

de representación de conocimiento adaptativos que utilizan puedan ser dirigidos progresiva e

intencionadamente56 para que, llegado el momento, dejen pasar desapercibidos ciertos eventos que

el potencial intruso no desea que sean detectados. Si el sistema de detección es capaz de adaptarse

a los cambios de comportamiento de los usuarios, es posible que alguno de esos usuarios utilice esa

indeseable característica con �nes maliciosos. Sin embargo, en el caso de la detección de �rmas,

la sencilla estructura de su motor de decisión elimina este problema. [116, 84, 17, 28, 100, 204]

Bajo coste administrativo

Un Sistema de Detección de Usos Indebidos puede proporcionar de forma rápida y �able un

diagnóstico exacto sobre la situación de un sistema de información, sin necesidad de laboriosos

procedimientos administrativos y sin necesidad de disponer de personal de seguridad excepcio-

nalmente experimentado. [116, 147, 28, 15, 100, 358]


Incapacidad de detección de ataques no documentados

La limitación por excelencia de todo sistema de detección de usos indebidos, dada la naturaleza

del propio principio de funcionamiento, consiste en la incapacidad absoluta de este tipo de sis-

temas de advertir cualquier comportamiento subversivo que no se encuentre documentado en su

base de conocimiento. Dado el extraordinario número de vulnerabilidades que se encuentran dia-

riamente, así como de procedimientos de ataque que las explotan [59], esta cuestión adquiere de

forma natural carácter de urgencia. Actualmente, las soluciones al problema pasan por la actua-

lización automática periódica de las bases de �rmas, si bien este método termina por reducir la

e�ciencia del sistema de detección a medio y largo plazo. [116, 84, 205, 17, 28, 15, 26, 100, 204, 358]

Rendimiento decreciente

56Dicha técnica es conocida habitualmente como session creeping.

37

El crecimiento que se produce en las bases de conocimiento a medida que se detectan, analizan y

documentan nuevos tipos de ataques, hace que dichas bases sean complejas de mantener, y que

el rendimiento del sistema termine por degradarse. En esta situación, el sistema de detección

puede llegar incluso a saturarse, y a tomar la decisión de ignorar aquellos eventos que están

saturando sus mecanismos de control de la congestión. Por supuesto, si el sistema se ve obligado

a dejar de analizar eventos, su e�cacia pasa a verse en un serio compromiso. De hecho, existen

técnicas de evasión de Sistemas de Detección de Intrusiones [385] que se basan en esta indeseada

característica. [116, 147, 100, 204]

0.3.4.2.2 Detección de Anomalías

Con el objetivo de aportar una solución al principal problema de los Sistemas de Detección

de Usos Indebidos, y proporcionar un método capaz de detectar ataques desconocidos hasta

el momento, surge la Detección de Anomalías [105], si bien hasta la fecha existen pocos casos

de éxito de dicha tecnología, debido fundamentalmente a la complejidad de administración que

la ha venido caracterizando. Tal y como se describe en la de�nición 1.1.17, su principio de

funcionamiento consiste en primer lugar en elaborar un per�l del comportamiento habitual de

los usuarios. A continuación, la actividad cotidiana de los mismos es comparada con dicho per�l, y

en el caso de que se observe alguna desviación signi�cativa, dicha actividad será clasi�cada como

anómala. Por último, se generará la pertinente respuesta, que en función de la con�guración del

sistema podrá quedar reducida a una noti�cación de alarma al administrador, o por el contrario

llegar a provocar un efecto reactivo sobre el sistema.

Por lo general, este modelo de funcionamiento está basado en las propiedades estadísticas de

los diferentes eventos que se producen en el sistema. De esta forma, es posible que el sistema

de detección aprenda la naturaleza del comportamiento de los usuarios del sistema, e in�era

sus conclusiones, por lo general construidas en base al concepto de probabilidad. Este modo de

operación hace que el sistema pueda prescindir de todo conocimiento apriorístico, y que pueda

detectar ataques para los cuales no existe un modelo previamente documentado. Sin embargo,

su naturaleza probabilística y la necesidad del sistema de detección de permanecer en un estado

de adaptación continua a las variaciones del comportamiento de los usuarios, hace a dichos

sistemas susceptibles de generar falsos positivos. Esta característica no es preocupante siempre

que se mantenga dentro de unos límites de excepcionalidad, pero puede convertirse en un serio

problema si se da con mayor frecuencia. De hecho, la minimización de los falsos positivos es uno

de los mayores retos que actualmente presenta esta tecnología. [116, 84, 28, 15, 26, 100, 204, 358]

A continuación se relacionan las principales ventajas e inconvenientes que presenta la Detección

de Anomalías:


Detección de ataques desconocidos

38

La mayor capacidad de este tipo de Sistemas de Detección de Intrusiones es precisamente la

de poder responder ante lo desconocido. Dado que su �losofía de funcionamiento está basada

en el aprendizaje que el propio sistema de detección hace sobre la realidad de la infraestructura

hardware y software que pretende proteger, es este conocimiento aprendido el elemento que marca

la diferencia entre lo legítimo y lo subversivo. De esta forma, no es necesario documentar todos y

cada uno de los tipos de ataque que aparecen diariamente, sino que basta con realizar un ejercicio

de introspección que determine cómo se comporta habitualmente un sistema de información, y

cómo no. [116, 147, 84, 28, 15, 26, 100, 204, 358]

Documentación de ataques desconocidos

Dada la poderosa propiedad anterior, un sistema de detección basado en anomalías puede generar

automáticamente información descriptiva sobre los nuevos ataques que detecta. De esta forma, es

posible construir, en base a dicha información, nuevas �rmas de ataques que pueden ser utilizadas

por los sistemas de detección de usos indebidos, de cara a la utilización conjunta de ambos. [28]

Rendimiento constante

El modelo de representación de conocimiento de este tipo de sistemas no necesita incrementar

su volumen de conocimiento, sino simplemente adaptarlo a ajustarlo a la realidad de la infraes-

tructura subyacente. Esta propiedad hace que estos sistemas tengan un prometedor futuro, ya

que no adolecen del problema de la pérdida de e�ciencia que sufren los modelos de detección de

usos indebidos. [116, 147]


Inestabilidad del conocimiento

Dada la necesidad de este tipo de sistemas de detección de adaptación continua a la siempre cam-

biante realidad del sistema a proteger, el conocimiento adquirido por los Sistemas de Detección

de Anomalías presenta cierta propensión a la inestabilidad. El comportamiento del sistema cam-

bia, y ese cambio puede in�uir para que lo que en un momento dado ha podido ser considerado

como legítimo, ahora pase a ser subversivo, y viceversa: que lo que en el pasado era considerado

anómalo, pase a convertirse en habitual. Por supuesto, esta cuestión se da cerca de los umbrales

de detección, y no signi�ca que el sistema sufra de indeterminismo. [116, 28, 26, 100, 204, 358]

Posibilidad de subversión del conocimiento

Debido a la misma necesidad de adaptación del apartado anterior, aparece una remota, aunque

posible, probabilidad de que el inherente proceso de aprendizaje de este tipo de sistemas sea uti-

lizado subversivamente, con el objetivo de que en un momento del futuro el sistema de detección

deje de percibir como anómalos ciertos eventos maliciosos. Para ello, un intruso puede provocar a

39

lo largo de un cierto periodo de tiempo ciertos sucesos normales (legítimos), pero cuyos atributos

cada vez se van acercando progresivamente al terreno de lo anómalo. De esta forma, teóricamen-

te, llegaría un momento en el futuro en el que el sistema, que se habría adaptado a esos cambios,

consideraría un evento antes subversivo como perfectamente legítimo. [116, 84, 17, 28, 100, 204]

Alto coste administrativo

En la actualidad, el proceso de aprendizaje que caracteriza a los sistemas de detección de anoma-

lías aún no ha conseguido liberarse de una relativamente costosa tarea de con�guración y ad-

ministración. Asimismo, y dada la naturaleza cambiante de dichos sistemas, el mantenimiento

de los mismos también contribuye de forma notable a incrementar los esfuerzos que una organi-

zación necesita soportar para que su sistema de detección pueda ser explotado con las mayores

garantías. Además, dicho proceso de aprendizaje no sólo precisa de esas importantes tareas de

con�guración y administración, sino que, además, los modelos computacionales que se utilizan

(como pueden ser las redes neuronales o los algoritmos genéticos) requieren muy frecuentemente

la supervisión del mismo por parte del operador humano. [116, 28, 15, 204]

Presencia de falsos positivos

Debido fundamentalmente a la naturaleza probabilística de los modelos de Detección de Anoma-

lías, es frecuente la necesidad de tomar un compromiso sobre la magnitud del volumen de respues-

tas que se consideran convenientes para su correcto procesamiento posterior. Dicho compromiso

se establece habitualmente en base a valores umbral que separan lo que se considera normal (y

por lo tanto, legítimo) de lo que se considera anómalo (y por lo tanto, ilegítimo). Un umbral

muy restrictivo hace que cualquier desviación, por leve que sea, sea considerada merecedora del

lanzamiento de una alarma u otra acción de respuesta. En principio, la seguridad del sistema es

muy alta, y se responde ante cualquier evento sospechoso. Sin embargo, el volumen de respuestas

es enorme, y en el caso habitual de utilizarse la simple respuesta pasiva mediante noti�caciones

de alarma, el administrador queda automáticamente saturado de ingentes cantidades de mensa-

jes que no puede procesar y que por lo general sólo implican acciones legítimas pero ligeramente

desviadas del per�l de comportamiento. O lo que es lo mismo: falsos positivos. Además, y lo que

es aún peor, entre esos grandes volúmenes de mensajes suelen pasar desapercibidos auténticos

peligros, los cuales no pueden ser físicamente diferenciados de los anteriores. Por el contrario, un

umbral muy permisivo genera un número razonable de respuestas, pero posibilita la no detección

de ataques cercanos a dicho umbral, dando origen a los aún más peligrosos falsos negativos.

Por todo ello, parece evidente la necesidad de buscar un equilibrio entre los dos extremos, que

permita minimizar ambos efectos indeseados, si bien su eliminación completa es improbable.

[116, 147, 84, 28, 15, 26, 100, 204, 358]

40

0.3.4.3 Respuesta

Una vez que el sistema de detección ha recogido un determinado evento y tomado la decisión

que considera más apropiada sobre él, es necesario dar una respuesta oportuna al mismo. En la

mayoría de los casos, dicha respuesta implica el lanzamiento de un mensaje de alarma hacia una

consola de gestión a cargo del administrador de dicho sistema. Este modo de actuación es lo que

se conoce como Respuesta Pasiva, y se realiza habitualmente de forma remota, bien mediante un

protocolo de noti�cación propio del sistema de detección, bien mediante algún esquema estándar

de gestión de sistemas como puede ser por ejemplo SNMP57 [351, 147], o bien mediante los

servicios de noti�cación de eventos que proveen los sistemas operativos. Por el contrario, existen

otras soluciones que apuestan por el uso de técnicas más activas, y que intentan mitigar de

forma automática los efectos de los potenciales ataques. Por lo general, una vez detectado un

ataque, este tipo de aproximaciones intentan recabar toda la información posible sobre el origen

de dicho ataque, tanto para poder así orquestar una respuesta más precisa, como para poder

tomar las acciones legales correspondientes con mayor conocimiento de causa. Además, también

es habitual llevar a cabo acciones correctoras del entorno atacado, abortando las conexiones del

intruso con la víctima, bloqueando el acceso de dicho intruso, protegiendo el acceso a servicios

del sistema agredido, etcétera. Asimismo, existen sistemas de detección que presentan un mayor

nivel de agresividad, y optan directamente por contraatacar contra el origen de la amenaza. Por

último, como se ha explicado en apartados anteriores, es importante prestar atención a un nuevo

enfoque que está surgiendo al respecto, y que coloca al sistema de detección dentro del �ujo

de información, de forma que le es posible no ya sólo detectar un cierto ataque, sino incluso

interceptarlo. Este enfoque se denomina Prevención de Intrusiones, y pretende proporcionar un

mayor nivel de seguridad, �ltrando de forma selectiva aquellos eventos dirigidos al sistema que

se pretende proteger. [116, 351, 84, 165, 340, 336, 50, 17, 28, 15, 26, 100, 204] A continuación

se describen las dos principales �losofías de respuesta que presentan los actuales sistemas de

detección: La respuesta pasiva y la respuesta activa.

0.3.4.3.1 Respuesta pasiva

Como se ha descrito anteriormente, la respuesta pasiva constituye la forma de respuesta

más simple y a su vez más extendida, fundamentalmente debido a dos razones: Por un lado,

es habitual que los administradores de sistemas de detección de intrusiones pre�eran mantener

un control estricto sobre las acciones que se llevan a cabo en el sistema de información que

tienen a su cargo, de forma que cualquier hipotética decisión que pudiera tomar dicho sistema

de detección representa un riesgo de inestabilidad en el sistema que en la mayoría de los casos no

es aconsejable tomar automáticamente, sin un cierto proceso de re�exión. Por otro lado, parece

lógico que la responsabilidad de llevar a cabo acciones críticas para el sistema, como suelen ser

las relativas a modi�caciones en la política de seguridad (como es lo habitual), recaigan en un

57SNMP o Simple Network Management Protocol: Protocolo de gestión de red, basado en UDP [288].

41

operador humano, y no en un sistema que se encuentra en continuo peligro de ser subvertido.

[116, 28] A continuación se relacionan las ventajas e inconvenientes más importantes de este

método de respuesta:


Rapidez de respuesta

La principal característica positiva de este método de respuesta es su sencillez y rapidez. Es

posible lanzar una noti�cación de alarma a la consola de gestión del administrador o incluso

a su teléfono móvil en el mismo instante que se detecta un ataque. Una correcta con�guración

del sistema de detección, que mantenga la tasa de falsos positivos en unos límites razonables,

en combinación con este tipo de respuesta, puede ser perfectamente válido en la mayoría de los

casos. [15, 204]

Imposibilidad de subversión

Al contrario que en otros tipo de sistemas más ambiciosos y agresivos, con este tipo de respuesta

no es posible que un potencial intruso llegue a utilizar subversivamente las peligrosas capacidades

de actuación sobre el entorno de dichos sistemas. Deberá ser el operador humano quien decida

si es necesario activar el registro de datos sobre el intruso, bloquear su acceso al sistema, o

contraatacarle. Es un método simple, pero no adolece de los delicados efectos laterales de otros

esquemas más so�sticados. [351, 84, 340, 50, 28, 15, 26, 204]


Incapacidad de reacción

Debido a la propia naturaleza de este método de respuesta, no es posible realizar ningún tipo de

operación ante una determinada evidencia de agresión. En algunos casos, existen ciertas acciones

operativas que pueden tomarse sin riesgo de ser utilizadas en bene�cio del atacante, como por

ejemplo el �ltrado de paquetes de red mal formados, y que este método no puede realizar por

defecto. [340, 28, 204]

Posibilidad de saturación del operador humano

En el caso de disponer de un sistema de detección con respuesta pasiva que sufra del proble-

ma de los falsos positivos, el método por defecto consistente en el envío de noti�caciones de

alarma al administrador puede llegar a saturarle por completo. De hecho, puede llevarle hasta

la más absoluta inoperancia. Además, en muchos casos un determinado evento malicioso es el

desencadenante de otros muchos, de forma que un único ataque se traduce en una avalancha de

noti�caciones. [116, 340, 204]

42

0.3.4.3.2 Respuesta activa

Como se ha explicado anteriormente, existen tres niveles de agresividad en las respuestas de

tipo activo: Recogida adicional de información, recon�guración del entorno lógico de la víctima, y

contraataque [116, 351, 84, 340, 17, 28, 15, 26, 100, 204]. Además, existe un aspecto adicional, en

función de la ubicación del sistema de detección, que permite no ya sólo detectar un determinado

ataque, sino además prevenir al sistema contra él [337, 116, 165, 341, 17, 358]. En el primer caso,

el principio de funcionamiento consiste en, dado que habitualmente el registro de información

que realiza el sistema de detección es muy limitado por cuestiones de espacio, incrementar la

granularidad de la información que se recaba, una vez que se tiene constancia de estar sufriendo

un ataque. De esta forma, es posible registrar las direcciones origen del ataque, los identi�cativos

de usuario responsables del mismo, los recursos que están siendo utilizados, etcétera, etcétera, de

cara a una posterior depuración de responsabilidades. En segundo lugar, se plantea la cuestión

de intentar detener un ataque, una vez detectado, o al menos, evitar ataques posteriores. Para

ello, la solución habitual pasa por la terminación abrupta de las conexiones de red que el intruso

ha activado hacia la víctima. Es posible que el mal ya esté hecho, pero así se intenta al menos

detener cualquier actividad del agresor lo antes posible. Además, también es habitual intentar

evitar cualquier intento futuro de acceso por parte de dicho intruso, mediante la recon�guración

de los dispositivos de enrutado y de �ltrado de paquetes. Asimismo, una solución de agresividad

máxima consiste en atacar mediante patrones de ataque prede�nidos aquellas direcciones desde

las cuales se lanzó el mencionado ataque. Por supuesto, este último extremo no es recomendable

en la práctica, dadas las ambigüedades legales existentes. Por último, en los casos en que el

sistema de detección se encuentre ubicado dentro del �ujo de información por el que deben

circular las órdenes de los usuarios hacia el sistema, es posible realizar �ltrado de alta precisión,

exclusivamente de aquellos eventos que se identi�can como potencialmente peligrosos.


Reacción automática

En este tipo de sistemas es posible con�gurar un cierto grado de respuesta automática, de forma

que es posible graduar su intensidad, en función del grado de certidumbre de que se disponga.

Por ejemplo, aquellos eventos de naturaleza evidentemente maliciosa pueden ser �ltrados direc-

tamente por el sistema de detección, mientras que otras cuestiones en las que exista una mayor

ambigüedad pueden seguir dejándose en manos del administrador. Por su parte, otros eventos

de riesgo medio pueden activar un mecanismo de registro detallado. [116, 84, 340, 28, 15, 204]

Reducción del volumen de noti�caciones de alarma

A pesar de que esta cuestión depende en gran medida de la naturaleza de la fase de análisis,

una respuesta activa con�gurada convenientemente, de forma gradual, puede contribuir a reducir

notablemente la carga de trabajo del operador del sistema de detección. [84, 340]

43

Posibilidad de intercepción del ataque

En el caso de que el sistema de detección se encuentre ubicado en forma de sistema de prevención

de intrusiones, esto es, dentro del �ujo de información y con capacidad de intercepción de cada uno

de los eventos que componen dicho �ujo, a las capacidades anteriores es posible añadir esta última.

Con ella, el objetivo tradicional de detección de la intrusión se extiende extraordinariamente, y

hace posible que cualquier evento clasi�cado como malicioso sea eliminado del sistema que se

está protegiendo. [28, 15, 204]


Potencial exceso de responsabilidad

Un importante inconveniente de los métodos de respuesta activa es precisamente una de sus ca-

pacidades. Así como la absoluta carencia de responsabilidad del sistema de detección perjudica

el rendimiento de dicho sistema, un alto grado de responsabilidad supone un riesgo de ines-

tabilidad difícilmente aceptable por cualquier administrador experimentado. De esta forma, la

solución lógica pasa por encontrar un equilibrio entre ambos extremos, de manera que el sistema

pueda hacerse cargo de cuestiones menores y de repercusión controlada, mientras que el operador

humano toma la responsabilidad de las cuestiones de mayor impacto. [351, 84, 340, 28, 15, 26, 204]

Posibilidad de subversión

Esta característica se encuentra muy relacionada con la anterior, ya que en aquellos casos en

los que el sistema de detección asume un gran nivel de responsabilidad, es posible que esa

capacidad de actuación sea utilizada subversivamente por el intruso. Por ejemplo, es habitual

la recon�guración de dispositivos de red para que realicen el bloqueo de aquellas direcciones

de red desde las cuales se ha detectado un determinado ataque. De esta forma, un agresor que

falsi�ca dichas direcciones en los paquetes de información que intercambia con su víctima puede

conseguir que el propio sistema de detección se encargue de denegar un determinado servicio

a todas las máquinas de la red que está protegiendo, con lo que habrá conseguido servirse a

su antojo de la herramienta que supuestamente debía velar por la seguridad del sistema de

información. [351, 84, 340, 50, 28, 15, 26, 204]

44

1.4. Retos por alcanzar

La novedad más importante de ESIDE-Mendizale radica en el hecho de que hasta el mo-

mento no hay ningún producto inteligente de seguridad en terminales móviles. Las tareas que

actualmente se están llevando a cabo (F-Secure Mobile, Kaspersky) son simplemente antivirales,

por reconocimiento de �rmas de malware conocido, y no permiten responder ante situaciones de

riesgo para la que no existe un modelo claramente de�nido y documentado. Sin embargo, son

muchas las novedades que aporta este proyecto y que lo hacen realmente interesante, tanto desde

el punto de vista cientí�co, como desde el tecnológico, como desde el puramente mercantil. A

continuación se relacionan las más importantes:

1.4.1. Respuesta ante ataques no conocidos (Zero-Day Attacks) contra telé-

fonos móviles

El sistema generará automáticamente y en tiempo real un modelo de comportamiento habi-

tual del usuario que accede normalmente al teléfono móvil, en concreto a través de las interac-

ciones internas que tienen los procesos y aplicaciones de dicho usuario con el Sistema Operativo

del terminal. De esta forma, mediante auditoría continua de dispositivos, llamadas al sistema,

hilos de ejecución, memoria consumida, servicios del API del Sistema Operativo, etcétera, será

perfectamente posible detectar desviaciones respecto del per�l habitual que puedan derivar en

situaciones de peligro para el sistema.

Además, esta técnica permite eliminar los costosos requerimientos de actualización que pre-

sentan los IDSs basados en reglas. A partir de las capacidades y limitaciones descritas en los

apartados anteriores, se pueden observar ciertas cuestiones generales del área de conocimiento

de la Detección de Intrusiones que después de veinte años de investigación permanecen sin una

solución e�caz, y que actualmente constituyen los grandes retos pendientes de esta disciplina

[65, 116, 351, 147, 165, 340, 78, 336, 28, 164, 15, 26, 100, 204, 358, 77, 84].

1.4.2. Aprendizaje Bayesiano no supervisado de per�les de usuario

El principal reto que actualmente presenta la Detección de Intrusiones consiste en dotar a

los módulos de análisis de los sistemas de detección de la capacidad de detectar ataques no

conocidos, en base al comportamiento habitual de los sistemas de información y de sus usuarios.

Las cifras de vulnerabilidades que aparecen periódicamente son extraordinarias [59] y, aunque

las habituales actualizaciones automáticas de las bases de conocimiento contribuyen de forma

notable a mitigar su impacto, la solución pasa por encontrar nuevos diseños que se enfrenten

directamente al problema.

Gracias a la capacidad de aprendizaje probabilístico (aprendizaje de correlaciones entre varia-

bles, e incluso aprendizaje de la estructura de las relaciones entre ellas) e inferencia que propor-

cionan las Redes Bayesianas y las Cadenas de Markov, se puede eliminar la costosa componente

45

de con�guración y mantenimiento que presentan la mayoría de los actuales IDSs.

De esta manera, tanto la generación de los antes mencionados per�les de comportamiento,

como el análisis propiamente dicho, se realizarán de forma transparente para el usuario �nal.

Como se ha mencionado en apartados anteriores, se pretende usar el entorno OpenPNL de

Intel Corporation, en concreto en todo lo relativo a inferencia y aprendizaje automáticos. (Está

previsto que Intel desarrolle una serie de tarjetas aceleradoras especí�cas para toma de decisiones

mediante OpenPNL: hecho que puede aportar unos rendimientos extraordinarios -probablemente

cambiará el orden de magnitud- en cualquier solución software desarrollada sobre dicho entorno.)

Para ello, la Detección de Anomalías se convierte en la opción más interesante, y que presenta

a priori mayores posibilidades. De hecho, es precisamente es en esta área en el que se concentra

actualmente el mayor número de investigaciones. Sin embargo, tal y como se ha explicado en el

apartado anterior, dicha �losofía de análisis presenta importantes inconvenientes, como pueden

ser el exceso de falsos positivos o la propensión a la inestabilidad de sus modelos de representación

de conocimiento. Por ello, es necesario desarrollar nuevos métodos de análisis que integren de

forma homogénea las capacidades de los métodos de Detección de Anomalías y de los de Detección

de Usos Indebidos, potenciando de forma sinérgica las ventajas de ambos, y minimizando sus

desventajas. De esta forma, será posible responder adecuadamente ante ataques bien conocidos,

a la vez que ante ataques de nuevo diseño. [65, 116, 340, 78, 28, 92, 15, 83].

Además, en ESIDE-Mendizale se pretende resolver una problemática tradicional que han

venido sufriendo las Cadenas de Markov, en cuanto a sus requisitos de parametrización estática.

En el presente proyecto se aborda dicha cuestión de forma dinámica, mediante la novedosa técnica

de Bayesian Merging desarrollada por Stolcke y Omohundro, en combinación con los algoritmos

Forward, Viterbi y Baum-Welch.

1.4.3. Uni�cación de modelos de detección de intrusiones

Otro objetivo fundamental que se plantea dentro de la Detección de Intrusiones es el de la

uni�cación de las múltiples soluciones de análisis que existen actualmente, fundamentalmente

mediante la homogeneización de los diferentes modelos de representación de conocimiento exis-

tentes, tanto de detección basada en �rmas como de detección basada en anomalías. Para ello,

el factor principal que debe tenerse en consideración es la taxonomía de los parámetros de aná-

lisis, ya que a partir de ellos y de su morfología deben construirse posteriormente los motores de

análisis responsables de la toma de decisiones. De esta forma, en caso de conseguirse un modelo

de�nitivo de representación que acredite potencia descriptiva y �exibilidad, sería posible avanzar

tanto en el mencionado objetivo de uni�cación, como en el anterior de detección de ataques

desconocidos en base a la integración de modelos de análisis. Asimismo, y dada la naturaleza

evolutiva y siempre cambiante de las tecnologías subyacentes, un paradigma de esas característi-

cas contribuiría a proporcionar grandes posibilidades de extensibilidad al sistema; cualidad ésta

que habitualmente marca la diferencia entre un Sistema de Detección de Intrusiones correcto y

46

uno excelente. [65, 116, 165, 205, 336, 164, 92, 15, 84].

1.4.4. Respuesta preventiva mediante intercepción de llamadas al sistema

Se pretende diseñar el IDS/IPS de manera que sea capaz de interactuar con el núcleo del

Sistema Operativo, de forma que sea posible interceptar comandos y solicitudes de servicio po-

tencialmente peligrosas. Según los grandes gurús de la detección de intrusiones, esta �losofía debe

marcar el futuro inmediato de los IDSs.

Conseguir que según se ejecuta un determinado código se bloquee llegando a un estado

anómalo en particular es como decir que se puede hacer frente a las amenazas e incluso solucionar

el problema que presentan de raíz, dado que después de la intercepción hay formas en las que

se puede devolver a un sistema al estado correcto de funcionamiento inmediatamente anterior.

Esta casuística será cubierta en profundidad en apartados posteriores.

1.4.5. Optimización de tasas de falsos positivos y falsos negativos

Como se ha explicado anteriormente, existen numerosos enfoques de Detección de Intrusiones

que aún adolecen del problema de los falsos positivos, sobre todo en el caso de aquéllos que se

enmarcan dentro del área de la Detección de Anomalías. La cuestión de la existencia de falsos

negativos también representa un problema, sobre todo en el caso de los sistemas de Detección de

Usos Indebidos, pero a menudo se solventa mediante el compromiso de realizar una con�guración

del sistema que proporcione una mayor seguridad, a costa de un mayor coste administrativo. Por

otro lado, dicho efecto también suele mitigarse mediante una actualización frecuente de las bases

de conocimiento. De esta forma, el principal asunto que queda por resolver es la reducción del

volumen de falsos positivos, que en sí mismos pueden constituir una vulnerabilidad susceptible

de ser explotada por un ataque de denegación de servicio, no contra el sistema de detección, sino

contra el operador humano responsable de su administración. [116, 147, 165, 78, 336, 28, 92, 26,

204, 358, 77, 84].

1.4.6. Superación de limitaciones arquitectónicas

En apartados anteriores se han descrito ciertas limitaciones inherentes a los actuales Sistemas

de Detección de Intrusiones orientados a la Red y al Host, como son su incapacidad para recoger

(y por lo tanto analizar) convenientemente información en grandes bloques. Otra cuestión ar-

quitectónica que frecuentemente introduce problemas de e�cacia en dichos sistemas de detección

es el crecimiento que habitualmente experimentan las infraestructuras hardware y software de

las organizaciones. Este crecimiento puede llegar a impedir que el detector de intrusiones pueda

realizar su labor convenientemente, con lo que toda la seguridad que debería aportar desaparece.

Por ello, es necesario que el diseño estructural de cada una de las tres fases que componen el mo-

delo general de todo sistema de detección contemple la cuestión de la escalabilidad con especial

47

atención. [116, 351, 78, 28, 15, 26, 100, 204, 84]

Todas éstas son cuestiones en efecto problemáticas, pero no suponen propiamente un reto,

ya que ya existen soluciones cuando menos parciales que las solventan. Es perfectamente posible

distribuir los procesos de recogida de información, análisis y respuesta en redes con alta carga o

que escalan de tamaño frecuentemente. Sin embargo, en la mayoría de los casos, dichos inconve-

nientes repercuten negativamente en la penetración de las tecnologías de Detección de Intrusiones

en empresas y organizaciones, que no desean realizar inversiones, esfuerzos administrativos, ni

reestructuraciones de infraestructura extraordinarias producto de la incorporación de dichas tec-

nologías. En las actuales condiciones, el retorno de la inversión no está claro, y el verdadero reto

consiste en desarrollar nuevos modelos que justi�quen sin lugar a dudas la implantación de la

Detección de Intrusiones con todas sus consecuencias. Cuanto menos claro estaba hasta la fecha

el llevar el mundo de la Seguridad de la Información a los terminales móviles, pero como se ha

expuesto es de primera necesidad en los tiempos que corren.

1.4.7. Base de conocimiento estándar

Se pretende diseñar la base de conocimiento que da soporte al algoritmo de análisis en formato

XML, para que pueda ser portada a otros sistemas de análisis o incluso a diferentes plataformas

de computación, dado el objetivo generalista del presente desarrollo en cuanto a su ámbito de

aplicación.

No en vano se plantea su integración con los grandes sistemas operativos que copan actual-

mente el mercado de terminales de telefonía móvil avanzados, como son GNU/Linux, Windows

CE/Mobile, Symbian OS, Palm-OS.

1.4.8. Análisis de trá�co de redes inalámbricas

Dado que la utilización de redes y protocolos de comunicación inalámbricos (GSM, GPRS,

EDGE, UMTS, 802.11b/g -WiFi-, Bluetooth, etc.) es una realidad cada vez mayor, este proyecto

contempla el desarrollo de una batería de reglas especí�cas para el análisis del comportamiento

de los usuarios que se conectan a los sistemas informáticos a través de estos medios, lo cual

redunda de forma natural en el carácter global de esta solución de seguridad.

1.4.9. Reducción de requerimientos administrativos

Actualmente, la incorporación exitosa de un Sistema de Detección de Intrusiones a la in-

fraestructura computacional y de comunicaciones de una organización requiere un considerable

esfuerzo de tiempo de administración. De hecho, por lo general, el coste principal no es el relativo

a la inversión en las licencias de uso de los productos (frente al cual incluso es posible optar por

48

soluciones de detección de libre distribución58 sólidas y de reputada solvencia59), sino el derivado

del tiempo que es necesario invertir para conseguir una con�guración adecuada, así como para

llevar a cabo un mantenimiento que asegure la e�cacia del sistema de detección a lo largo del

tiempo.

Asimismo, también es determinante el hecho de que el proceso de detección pueda realizarse

de forma uni�cada sobre arquitecturas hardware y software heterogéneas, como corresponde a

la realidad de cualquier organización moderna, considerando múltiples plataformas, sistemas

operativos, servicios de aplicación, etcétera. Por todo ello, cualquier modelo de funcionamiento

que se plantee debe ser especialmente cuidadoso en mantener unos requisitos administrativos y

de supervisión mínimos, que permitan una adopción natural del mismo por parte de empresas y

organizaciones. [116, 351, 28, 164, 92, 358, 77, 84]

1.4.10. Adaptación al comportamiento del sistema

A pesar de que la fructífera línea de la Detección de Usos Indebidos cuenta con casos de éxito

sobresalientes, enormemente extendidos, y que se caracterizan por su relativa sencillez adminis-

trativa, cada vez es más necesario que los Sistemas de Detección de Intrusiones se adapten por

sí mismos a la siempre cambiante realidad de las infraestructuras informáticas que deben salva-

guardar. Esta cuestión, que en el caso anterior de los sistemas basados en �rmas es importante,

en el caso de los sistemas basados en anomalías es trascendental.

Como se ha explicado en apartados anteriores, la Detección de Anomalías está llamada a

ser la solución al problema de los ataques desconocidos, ya que es capaz a priori de ir más allá

que sus homólogos basados en patrones. No obstante, aunque este extraordinario objetivo se vea

satisfecho, sus habituales y costosos requisitos administrativos deberán desaparecer, o al menos

igualar a los de dichos homólogos, ya que ningún modelo de detección tendrá una verdadera

expansión si no minimiza sus costes de implantación y mantenimiento. [116, 351, 165, 336, 28,

164, 240, 92, 204, 358, 77]

1.4.11. Fortalecimiento del sistema de detección

Actualmente, es frecuente observar cómo el propio Sistema de Detección de Intrusiones se

ha convertido en uno de los primeros elementos del sistema en recibir ataques de todo tipo.

De hecho, en la mente del agresor, esta realidad es fruto de un razonamiento absolutamente

lógico. Para él, no es posible materializar sus subversivas intenciones de forma inadvertida bajo

la estrecha vigilancia del sistema de detección. O lo que es más, en aquellos casos en los que el

sistema esté con�gurado para prevenir ese tipo de comportamientos, dicho atacante ni siquiera

58El concepto de software de libre distribución o software libre fue acuñado por Richard Stallman en 1.984.Dicho concepto hace referencia a una forma de entender la informática que aboga por �la libertad de los usuariospara ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software� [329].

59Actualmente, el Sistema de Detección/Prevención de Intrusiones orientado a la Red de libre distribución porantonomasia es Snort [242, 323].

49

tendrá la posibilidad de ejecutar acción alguna. De esta forma, el sistema de detección pasa a

ser una cotizada presa, que por lo general merece especial atención por parte del intruso.

Por ello, es imprescindible que el diseño e implementación de dicho sistema de detección

contemplen la resistencia a la subversión del mismo como un aspecto fundamental. De nada

sirve un so�sticado módulo de análisis basado en complejas técnicas matemáticas, si el sistema

puede caer fácilmente ante un ataque de denegación de servicio, por ejemplo. Así pues, tiene que

ser extremadamente difícil para un intruso potencial conseguir desactivar o manipular cualquier

componente de dicho sistema de detección, así como lograr que sus acciones pasen inadvertidas

ante él. De hecho, es altamente recomendable considerar la posibilidad de que el propio sistema

sea capaz de automonitorizarse, en busca de ataques que hayan podido realizarse contra su

integridad; solución que ya se aplica, por ejemplo, dentro de algunos sistemas operativos, para

garantizar la consistencia de sus componentes internos. Además, es deseable que dicho sistema

de detección sea tolerante a fallos, en la medida en que debe ser capaz de recuperar su estado

ante fallos generales del sistema, ya sean éstos accidentales o intencionados. [116, 351, 165, 78,

28, 164, 92, 15, 26, 358, 77, 84].

1.4.12. Reducción del consumo de recursos computacionales

Hoy en día, la puesta en explotación de un Sistema de Detección de Intrusiones aún lleva

implícito un alto consumo de los recursos computacionales de la infraestructura que se pretende

proteger; especialmente en el caso de aquéllos sistemas que están orientados a la máquina. Por

ello, a pesar de sus grandes virtudes, la difusión de esta tecnología encuentra actualmente grandes

obstáculos a su incorporación como medida de seguridad en la infraestructura computacional y

de comunicaciones de numerosas organizaciones.

De esta forma, el diseño de los nuevos sistemas de detección debe asegurar la mínima sobre-

carga posible de los mismos sobre los recursos del sistema de información objetivo del análisis, así

como la absoluta garantía de una nula interferencia en su actividad cotidiana. A este respecto,

a pesar de presentar algunas limitaciones intrínsecas (tal y como se ha explicado en apartados

anteriores), la tecnología de Detección de Intrusiones orientada a la Red se revela como el más

�rme candidato al éxito, ya que el aprovechamiento que consigue de los recursos disponibles es

máximo. [116, 351, 78, 164, 92, 100, 77, 84]

1.5. Hipótesis fundamentales

A partir de los retos planteados en el apartado anterior, los cuales señalan la dirección en la

que debe orientarse toda investigación cientí�ca que se desarrolle en estos momentos en el área

de la Detección de Intrusiones, se establecen las siguientes hipótesis fundamentales,de ámbito

de aplicación, de unicidad y homogeneidad, sobre las cuales se sustentan los objetivos generales,

especí�cos y operacionales, así como el desarrollo mismo del presente trabajo:

50

Hipótesis fundamental 1: Ámbito de aplicación. �Se puede aplicar cualquier tipo de

técnica de Detección de Intrusiones (HIDS/HIPS) para sistemas cableados tradicionales en

terminales móviles.�

Esta primera hipótesis se formula con el objetivo de explicar claramente que se ha llegado a

un punto tecnológico tan desarrollado, que es comparable un terminal móvil a un computador

cableado de hace años. Las técnicas de detección de intrusiones que se han estudiado engloban

mayoritariamente técnicas para sistemas cableados de análisis de funcionamiento del Software

Interno. Estás técnicas se van a poder aplicar en mayor o menor medida a los nuevos terminales

móviles, debido a que actualmente tienen la misma potencia que hace unos años el resto de

sistemas informáticos.

Hipótesis fundamental 2: Unicidad. �Es posible combinar en un único modelo de análisis

las principales ventajas de los métodos de Detección de Usos Indebidos y de Detección de

Anomalías orientados a la Host, e incluso alimentar el motor de Detección de Usos Indebidos

con los veredictos del motor de Detección de Anomalías�

Esta segunda premisa se enuncia indicando que dado que los motores de Detección de Usos

Indebidos son más rápidos, una vez se obtenga un resultado por parte del Motor de Anomalías,

se puede incorporar a la batería de reglas del sistema. De esta forma de forma única se dispone

de un sistema que aglutina el conocimiento de ambos mundos de detección que tradicionalmente

han sido separados.

Hipótesis fundamental 2: Homogeneidad. �Es factible analizar de forma homogénea los

diferentes parámetros heterogéneos propios de los Métodos de Detección de Usos Indebidos y

de Detección de Anomalías orientados al Host. E incluso yendo un paso más adelante, se

pueden homogeneizar los veredictos entre Sistemas de Detección basados en Host (HIDS) con

los veredictos de los Sistemas de Detección basados en Red (NIDS).�

Como puede observarse estas hipótesis pretenden aglutinar el resultado �nal de el presente

proyecto: un sistema homogéneo entre diferentes fuentes:

Terminales Móviles (Symbian OS, Windows Mobile, Linux Mobile...)

Terminales Cableados

Redes y gestión de las mismas

Para lo que se ha creado una infraestructura que permita aglutinar de forma homogénea los cono-

cimientos de los Sistemas Probabilísticos Expertos que se han desarrollado para cada submundo.

Aquí se abre una vía por la que una organización puede tener a buen recaudo el completo de

sus sistemas informatizados. Poco a poco se irá exponiendo la forma en la que se ha desarrollado

cada parte y el modo en que se va integrando en el sistema infraestructural completo.

51

1.6. Objetivos

Por todo lo anterior, el objetivo fundamental de ESIDE-Mendizale es desarrollar un Sistema

de Detección y Prevención de Intrusiones en Terminales Móviles, que detecte ataques conocidos

y no conocidos (Zero-Day Attacks), mediante Detección de Anomalías en las llamadas al Siste-

ma Operativo; cumpliendo de esta forma con los objetivos del VI Programa Marco, dentro del

Espacio Europeo de Investigación, en concreto en todo lo relativo a la línea "Towards a Global

Dependability and Security Framework", que establece el objetivo prioritario de investigación

en medidas de seguridad orientadas al fortalecimiento de sistemas informáticos, para asegurar la

con�abilidad en el uso de las TICs; así como con los objetivos del Plan de Ciencia y Tecnolo-

gía del País Vasco, en el área prioritaria �Entorno Seguro de Transacciones y Pago en Negocio

Electrónicoâ�, del Programa Empresa Digital.

Asimismo, según las impresiones recogidas en la �11th International Conference on Concu-

rrent Enterprising� (recientemente celebrada en Munich y bajo la cual se organiza el Proyecto

MOSAIC, �nanciado por dicho VI Programa Marco), la Seguridad en Movilidad es uno de los

pilares fundamentales para el pleno desarrollo de las TICs en �Mobile Collaborative Working

Environments�, una de las futuras líneas prioritarias del VII FP. Así pues, para ello, se creará

en tiempo real, mediante una herramienta matemática denominada Red Bayesiana (denominada

así en honor al creador de su principio básico de funcionamiento, Thomas Bayes, y desarrollada

como mecanismo computacional e�ciente de análisis multivariable por Judea Pearl, investigador

de la Universidad de Cambridge), un modelo del comportamiento normal del terminal móvil,

para posteriormente analizar la actividad cotidiana del mismo y detectar desviaciones que pue-

dan comprometer su seguridad. En concreto, se pretende utilizar una tecnología recientemente

desarrollada y publicada por Intel Corporation, y conocida bajo el nombre de OpenPNL (Open

Probabilistic Network Library), para la programación de sus nuevos prototipos de chips de apoyo

inteligente a la toma de decisiones.

El objetivo fundamental que se pretende conseguir en el presente proyecto es el desarrollo de

una herramienta software que detecte ataques conocidos y desconocidos (aún no documentados)

contra terminales móviles, mediante el análisis de anomalías en las llamadas al Sistema Operativo.

Con esta información se pretende crear un modelo del comportamiento normal del trabajo

del dispositivo, para posteriormente comparar la adecuación de un determinado rastro o traza

de actividad (constituida mediante múltiples parámetros recogidos del sistema en tiempo real) al

modelo; permitiendo detectar desviaciones potencialmente peligrosas respecto al mismo. Estas

desviaciones son indicativas de un comportamiento anormal del sistema y denotan la necesidad

de noti�car en forma de alarma dicho comportamiento, o de actuar de forma reactiva, impidiendo

que cualquier software malicioso pueda comprometer la seguridad del terminal.

Dada la actual situación de crecimiento del sector de las comunicaciones móviles, y las escasas

medidas de seguridad implementadas hoy por hoy en los terminales, es realmente factible el

desarrollar un producto comercial a partir del prototipo que se desarrolle en ESIDE-Mendizale.

52

Para ello, el objetivo especí�co más importante que se pretende alcanzar, si bien no el único, es el

de desarrollar un nuevo método de Detección de Anomalías que resuelva las problemáticas de las

que aún adolecen los IDSs actuales y que, además, compatibilice dicho análisis con las habituales

restricciones computacionales y de almacenamiento que suelen presentar los terminales móviles.

Como ha podido observarse en el estudio del estado del arte llevado a cabo de cara a la

presentación, cada uno de los actuales enfoques de diseño de IDSs proporciona soluciones a

determinados problemas, pero deja sin tratamiento otras cuestiones; por lo que una labor im-

portante que tendrá que afrontar el equipo investigador será la de desarrollar una solución que

sea capaz de modelizar de forma homogénea las dos grandes �losofías de detección (Patrones de

Comportamiento Indebido y Anomalías), combinando las capacidades de ambas y eliminando sus

respectivos inconvenientes. De esta forma, podrá darse cumplimiento al objetivo de responder

ante situaciones de riesgo conocidas (mediante el conocimiento propio de la Detección de Patro-

nes), y también ante situaciones anómalas (mediante el conocimiento propio de la Detección de

Anomalías), que podrían comprometer la seguridad del terminal.

Por otro lado, la capacidad preventiva de los actuales IDSs está muy limitada, y no es su-

�cientemente efectiva en muchos casos. El IDS observa el comando, la llamada al sistema o el

paquete de red enviado por el atacante, pero no está en disposición de detener ese ataque. Como

mucho puede intentar abortar la conexión de red, o bloquear el �rewall, cuando se trata de IDSs

de red, o denegar el acceso a algunos recursos cuando se trata de IDSs de host, pero por lo general

dichas respuestas suelen llegar tarde. Por lo tanto, su objetivo principal se reduce habitualmente

a la mera noti�cación del peligro, en la con�anza de que el usuario o el administrador tomen las

contramedidas necesarias lo antes posible.

Así pues, el segundo objetivo especí�co que se persigue en ESIDE-Mendizale consiste en

lograr no sólo la detección, sino también la intercepción de las solicitudes de actuación de los

usuarios del terminal móvil, para poder realizar el pertinente Análisis de Anomalías antes de que

dicha acción llegue realmente al Sistema Operativo, y sea por lo tanto ejecutada. De esta forma,

será perfectamente posible evitar ataques evidentes, con patrones conocidos y �rmas de ataque

perfectamente reconocibles, y a la vez y de forma homogénea detectar ataques para los que no

existe un modelo previo pero que pueden resultar en algún tipo de perjuicio para el sistema.

Por último, una problemática adicional que suelen presentar los IDSs/IPSs, independiente-

mente de su �losofía de detección, es su alto grado de dependencia respecto del operador humano.

Por un lado, las baterías de reglas de los IDSs basados en reconocimiento de patrones deben ser

continuamente actualizadas con las �rmas de los nuevos ataques se van documentando día a día,

para que el sistema pueda seguir manteniéndose efectivo. Por otro lado, los IDSs basados en

análisis de anomalías necesitan un profundo proceso de con�guración personalizada y puesta a

punto, antes de ser lanzados a explotación y durante el funcionamiento cotidiano de la plataforma

en la que están instalados. Por supuesto, a este respecto, es muy conveniente mantener la �losofía

de continua actualización ante el enemigo, pero también es muy deseable poder disponer de un

53

mayor nivel de automatización de los diferentes procesos del IDS/IPS; nivel de automatización

que puede conseguirse mediante técnicas de Inteligencia Arti�cial como es el caso del Aprendizaje

Bayesiano No Supervisado que se plantea para este proyecto.

Siguiendo la línea anterior, el último objetivo especí�co que se plantea en la presente propuesta

consiste en alcanzar un alto nivel de autosu�ciencia del IDS/IPS; objetivo que redunda de forma

natural en su �exibilidad y adaptación a diferentes entornos y plataformas móviles. De esta

forma, estos objetivos persiguen el desarrollo de un IDS/IPS de Host Móvil, que sea capaz de

proteger de forma robusta toda la lógica implementada en los modernos terminales de telefonía

móvil, que se anticipe de forma e�ciente a situaciones de peligro conocidas o no, y que requiera

de una mínima interacción del operador humano; siendo su meta natural el posterior desarrollo

de un producto software estable y de calidad.

1.7. Estructura de la memoria

La organización de los capítulos de esta memoria es la siguiente:

Capítulo primero: Introducción. En este capítulo se presenta el área de la Detección de

Intrusiones desde un punto de vista global, y se mani�esta su relevancia como elemento de

seguridad en la actual Sociedad de la Información. Asimismo, se introducen los conceptos

fundamentales de Seguridad de la Información y Detección de Intrusiones, incluyendo el

modelo general de funcionamiento y las características más importantes que presentan

actualmente los Sistemas de Detección de Intrusiones. A continuación, a partir de dichas

características se enumeran los grandes retos que presenta la tecnología y se establecen las

hipótesis fundamentales sobre las cuales se basa la presente memoria. Por último, en base a

dichas hipótesis, se de�nen los objetivos generales, especí�cos y operacionales que deberán

alcanzarse para la correcta validación de las anteriores hipótesis.

Capítulo segundo: Entorno de trabajo. En este capítulo se describen las dos disci-

plinas que con�uyen en el presente estudio, como son la Detección de Intrusiones, por un

lado, y los Modelos de Redes Probabilísticas, por otro. Así, en primer lugar, en relación con

la primera de dichas disciplinas, se presenta la perspectiva histórica de los Sistemas de De-

tección de Intrusiones, desde su aparición en la década de los ochenta, hasta nuestros días.

Seguidamente, se continúa describiendo las diferentes áreas de conocimiento que componen

dicha disciplina, según el modelo conceptual propuesto por Emilie Lundin, y se analizan

las diferentes taxonomías de sistemas de detección propuestas por diversos autores, con el

objetivo de ubicar conceptualmente las hipótesis fundamentales y los objetivos enuncia-

dos. A continuación, se concluye con la descripción de las diferentes técnicas de análisis,

categorizadas según los dos grandes enfoques de diseño: Detección de Usos Indebidos y De-

tección de Anomalías. También se incluye un breve epígrafe en el que se describen algunas

implicaciones arquitectónicas. Por otro lado, en lo relativo a la segunda de las disciplinas

54

propuestas, se introducen los conceptos de Modelo de Red Probabilística y de Red Baye-

siana, y se describen sus diferentes potencialidades, como son inferencia de conclusiones,

mediante diversos métodos de propagación exacta de evidencia, aprendizaje automático

estructural y paramétrico, y representación intrínseca de la magnitud temporal, mediante

el concepto de Red Bayesiana Dinámica.

Capítulo tercero: ESIDE-Mendizale. Un framework bayesiano de Detección de Intru-

siones para Sistemas Móviles. En este capítulo se describe la solución propuesta, una vez

explorado el área de conocimiento de la Detección de Intrusiones, así como los diferentes

fundamentos probabilísticos. Dicha solución se ha dado en denominar ESIDE- Mendizale,

en correspondencia con el acrónimo de �Mobile Environment for Discovery of Zero-Day

Attacks through Bayesian Learning�. Por otro lado, para su descripción, se utiliza el modelo

conceptual propuesto por Emilie Lundin, cuya exhaustiva formulación sirve en esta ocasión

como inmejorable hilo conductor de la exposición. Así, a pesar de que las hipótesis funda-

mentales del presente estudio se ubican principalmente en la fase de Análisis, se describen

las cuestiones de Análisis de Riesgos y Formalización, Recogida de Información, Análisis,

Respuesta, Cuestiones Arquitectónicas, Fortaleza, Cuestiones Operacionales, Evaluación y

Aspectos Sociales.

Capítulo cuarto: Experimentación y Análisis de Resultados. En este capítulo, una

vez de�nida la solución propuesta, se describe el proceso de experimentación realizado con el

objetivo de contrastar la validez de las hipótesis fundamentales de la presente memoria. Por

supuesto, a pesar de que son numerosas las implicaciones que presenta ESIDE-Mendizale

desde los diferentes puntos de vista, dichas hipótesis fundamentales se centran en la fase de

Análisis, por lo que la presente experimentación se orienta igualmente hacia esta cuestión.

Se incluyen secuencialmente los análisis de los resultados obtenidos a partir de los diferentes

experimentos.

Capítulo quinto: Conclusiones y Líneas de Investigación Futuras. En este capítulo

se recogen las diferentes conclusiones obtenidas durante el desarrollo de las investigaciones

que han conducido a la consecución de los objetivos marcados en la presente tesis docto-

ral. Asimismo, también se incluye una relación de futuras líneas de investigación que son

susceptibles de abordarse a corto y medio plazo, y en base a las cuales es posible buscar

solución a ciertas cuestiones que aún permanecen por resolver, y a los nuevos retos que se

plantean a raíz de las conclusiones obtenidas.

Se concluye con un apartado dedicado a la bibliografía, con todas las referencias mencionadas

en esta memoria.

55

Capítulo 2

Entorno De Trabajo

2.1. Detección de Intrusiones

Durante la década de los ochenta y hasta la actualidad, el crecimiento exponencial de la

actividad subversiva contra sistemas de información de todo tipo [59] ha suscitado un desarrollo

igualmente acelerado en la investigación que se ha venido desarrollando en el área de la Detección

de Intrusiones.

Esta evolución está caracterizada por avances importantes que se han producido en momentos

puntuales, y ha venido modelando un panorama general complejo y en el que entran en juego

múltiples aspectos propios de los distintos enfoques de detección que se han desarrollado y sobre

los que se sigue investigando. Por ello, y dado que los objetivos marcados en el presente trabajo de

investigación se circunscriben a determinadas parcelas especí�cas de dicho panorama general, se

hace necesaria una acotación del ámbito del problema que se plantea. Con este �n, en la presente

sección se procede a introducir las características generales del actual horizonte investigador, en

concreto a lo largo de los siguientes apartados, así como las características propias de aquellos

campos de la Detección de Intrusiones íntimamente ligados a los objetivos de la presente memoria,

en concreto a través del apartado de �Técnicas de Análisis�.

2.1.1. Perspectiva

Tradicionalmente, las tareas de auditoría de los eventos de seguridad que se producían en

un determinado sistema de información eran llevadas a cabo de forma manual. Las máquinas en

explotación existentes en los diferentes tejidos de la sociedad no eran numerosas, las cifras de

usuarios y aplicaciones se mantenían en niveles bajos, y era no era descabellado el hecho de que

dichas tareas se realizaran de esa manera. Sin embargo, a medida que el número de máquinas,

usuarios, servicios de aplicación, capacidades de conectividad, etcétera, crecía, la magnitud del

número de eventos de seguridad adquiría progresivamente una mayor dimensión que hacía invia-

bles los tradicionales procedimientos de auditoría. Era necesario abordar la búsqueda de nuevos

57

métodos de trabajo automatizados [84, 78, 28, 271, 15] .

De esta forma, en el año 1.980, James P. Anderson desarrolló un estudio, a petición de las

Fuerzas Aéreas de Estados Unidos [362], en el que propuso un sistema de clasi�cación automático

que utilizaba los eventos registrados por el subsistema de auditoría del Sistema Operativo para

detectar actividades subversivas a partir del comportamiento habitual de los usuarios de un

determinado sistema. Este trabajo supuso el comienzo de la Detección de Intrusiones en general,

así como de la Detección orientada a la Máquina y la Detección de Anomalías, en particular.

Muchas de las investigaciones que se han desarrollado desde entonces utilizan este concepto [20],

incluido el presente trabajo de investigación.

Posteriormente, a mediados de los ochenta, SRI International [327] comenzó un intenso es-

fuerzo investigador, por iniciativa del gobierno de los Estados Unidos, con el objetivo de analizar

los registros de auditoría de los grandes sistemas informáticos gubernamentales y crear per�les de

comportamiento de los usuarios de dichos sistemas. En las primeras fases de esta investigación,

la Doctora Dorothy Denning diseñó un primer modelo general de Sistema de Detección de Intru-

siones, a partir del cual se desarrolló posteriormente el denominado proyecto IDES1 [237, 396].

Las conclusiones obtenidas a partir de la realización de dicho proyecto están recogidas en su his-

tórico artículo An Intrusion Detection Model [105], y aún hoy siguen constituyendo un referente

fundamental para todo trabajo de investigación que se desarrolle sobre el tema, sobre todo en el

campo de la Detección de Anomalías.

Por otro lado, mientras SRI International llevaba a cabo dicho proyecto IDES, el Laborato-

rio Lawrence Livermore [263] de la Universidad de California Davis [264] abordó el desarrollo

del proyecto Haystack2, cuyo objetivo era la construcción de una nueva versión de Sistema de

Detección de Intrusiones para las Fuerzas Aéreas que proponía el análisis de los registros de audi-

toría mediante la comparación de los mismos con una batería de patrones de ataque prede�nidos

[Smaha88]. Dicho proyecto dio origen a lo que hoy se conoce como Detección de Usos Indebi-

dos, y su evolución natural, denominada DIDS3 [322], constituyó asimismo la primera solución

distribuida de Detección de Intrusiones.

Posteriormente, al inicio de la década de los noventa, Todd Heberlein, investigador de la

Universidad de California Davis, presentó la idea de la Detección de Intrusiones orientada a la

Red. Hasta entonces, los estudios realizados por Anderson, Denning y el Laboratorio Lawrence

Livermore se habían centrado únicamente en la Detección orientada a la Máquina, de forma

que el desarrollo del denominado proyecto NSM4 supuso una revolución conceptual en el área

[161]. Además, las aportaciones de Heberlein fueron recogidas por el equipo de investigación

1IDES: Intrusion Detection Expert System.2En una entrevista telefónica con Crosby Marks, uno de los desarrolladores del proyecto, éste confesó que:

"Searching through this large amount of data for one speci�c misuse was equivalent to looking for a needle in ahaystack." Este sentimiento del equipo investigador ante la magnitud del problema con el que se enfrentaban lesllevó a decidir dejar simbólica constancia del mismo en el propio nombre del proyecto [271].

3DIDS: Distributed Intrusion Detection System.4NSM: Network Security Monitor.

58

del proyecto Haystack, quien extendió el proyecto DIDS con las nuevas ideas, proponiendo por

primera vez el concepto de Sistema de Detección de Intrusiones Híbrido.

En este ámbito, durante los últimos diez años, las diferentes investigaciones cientí�cas han

ido estabilizándose (como pueden ser los proyectos NIDES5 [19], EMERALD6 [384] o la familia

STAT7 [367, 170]), de forma que, desde �nales de los años noventa y hasta la actualidad, han

aparecido múltiples productos comerciales y de libre distribución sólidos y de contrastada solven-

cia (como pueden ser ISS RealSecure [335] o Snort [323]), por lo general basados en Detección

de Usos Indebidos, que proporcionan soluciones e�cientes a muchas de las problemáticas que

presenta el área de la Detección de Intrusiones.

Sin embargo, tal y como se explica en el apartado 1.3, la tecnología de la Detección de Intru-

siones aún presenta grandes retos por superar, y aunque existen pruebas de concepto ambiciosas

y que prometen grandes resultados, dichas aproximaciones se basan por lo general en la integra-

ción de soluciones parciales, y no en el desarrollo de un modelo de representación e inferencia

intrínsecamente completo [116]. Por ello, todavía es necesario seguir trabajando en el diseño de

nuevos modelos que aborden los problemas de una forma uni�cada y homogénea, tal y como se

enuncia en las hipótesis fundamentales del apartado 1.4.

2.1.2. Modelo conceptual de Lundin

El desarrollo de un Sistema de Detección de Intrusiones no se limita a la obtención de un

mecanismo hardware o software que realice las tres operaciones fundamentales de recogida de

información, análisis y respuesta, constituyentes del modelo general de funcionamiento descrito

en el apartados anteriores.

Por el contrario, dichas componentes se encuentran ubicadas dentro de un contexto más

amplio y en el que existen ciertas cuestiones adicionales que es necesario tener en especial con-

sideración a la hora de abordar el diseño de todo sistema de detección. Estas cuestiones son, en

concreto, la adaptación de dicho sistema al sistema de información que se desea proteger, el im-

pacto administrativo y económico inherente a su despliegue, y el mantenimiento de la seguridad

ante ataques dirigidos hacia él [204, 154]. Asimismo, también es necesario prestar atención a otros

aspectos fundamentales como puede ser la de�nición de la taxonomía de ataques que se pretende

detectar, o la metodología de evaluación de dicho sistema de detección [17, 26, 100]. Por último,

existen ciertas consideraciones éticas y legales sobre las que igualmente es necesario realizar una

profunda re�exión [116, 154]. Emilie Lundin describe este contexto, en su tesis doctoral, de una

forma excepcionalmente precisa. La �gura 2.1 está extraída de dicho estudio y pretende ilustrar

las distintas áreas de conocimiento.

5NIDES: Next Generation Intrusion Detection Expert System.6EMERALD: Event Monitoring Enabling Responses to Anomalous Live Disturbances.7STAT: State Transition Analysis Tool for Intrusion Detection.

59

Figura 2.1: Modelo conceptual de Lundin

Áreas de conocimiento

A continuación se describen las nueve áreas de conocimiento propuestas por Emilie Lundin,

las cuales sirven, además de para de�nir el exhaustivo modelo conceptual descrito en el apartado

anterior, para categorizar la actividad investigadora que se realiza actualmente en el campo de

la Detección de Intrusiones:

Análisis de Riesgos y Formalización

Ésta es el área de conocimiento en el que se establecen los fundamentos básicos de todo el proceso

de Detección de Intrusiones subsiguiente. En ella se de�ne el ámbito del problema de la detección

y se formaliza la taxonomía de intrusiones y de parámetros de detección que se pretende utilizar

como objetivo [116, 17, 26, 358, 304] . El Sistema de Detección de Intrusiones solamente será

capaz de detectar aquellos ataques que puedan especi�carse en base a dicha taxonomía. De esta

forma, en este apartado, se estudian por tanto los diferentes tipos de vulnerabilidades, intrusiones

e intrusos, que se constituyen en elementos de riesgo para las plataformas tecnológicas que se

pretende proteger. Como es lógico, sin una su�ciente atención a esta cuestión en la fase de análisis,

sería extraordinariamente difícil desarrollar un modelo de Sistema de Detección de Intrusiones

que fuera realmente e�caz ante cualquier tipo de ataque. Además, sin unos objetivos claros y bien

de�nidos también se hace especialmente ardua la tarea de evaluación de la e�cacia y e�ciencia

de cualquier tipo de sistema de detección [93].

Recogida de Información

60

En esta área se de�nen la taxonomía y el formato de los datos que se deben registrar para

desarrollar convenientemente las tareas de análisis. Además, otras cuestiones fundamentales que

se plantean en este punto son cómo debe realizarse la tarea de recogida de información, qué

mecanismos de recogida son los más adecuados para ser utilizados, dónde se va a realizar el

almacenamiento de dicha información, y en qué puntos del sistema es más conveniente realizar

dicha recogida. El posterior análisis y por lo tanto el resultado último de la detección, serán tan

e�caces como lo sea el presente proceso de recogida de información [116, 92, 204, 277, 134, 255].

Una mala calidad de los datos recogidos se traduce habitualmente en una menor cobertura ante

los ataques, una mayor tasa de falsos positivos, y en una reducción de la e�ciencia.

Análisis

La tarea de análisis es el corazón de la Detección de Intrusiones, su núcleo, ya que de ella

dependen las decisiones últimas que deben tomarse en el sistema de detección. En esta área

recae, por lo tanto, la responsabilidad de determinar con precisión y e�ciencia la línea que separa

el comportamiento legítimo de los usuarios de la infraestructura tecnológica de una determinada

organización, del comportamiento subversivo contra dicha infraestructura. De esta forma, el reto

que supone afrontar dicha responsabilidad hace que sea precisamente este componente de análisis

el que constituya el área de conocimiento sobre la cual se viene realizando en los últimos años el

mayor número de investigaciones y publicaciones cientí�cas [65, 116, 84, 340, 78, 28, 92, 15, 26,

367, 100].

Respuesta

Una vez que el componente de análisis ha tomado una decisión, es responsabilidad del componente

de respuesta llevar a cabo las acciones pertinentes. En el caso de haberse detectado un intento de

intrusión, o bien una intrusión efectiva, es necesario poner en marcha los mecanismos de alerta

pasiva o activa de que se disponga. Es perentorio noti�car dicha intrusión al administrador del

sistema, y mitigar en la medida de lo posible el impacto potencial de dicha intrusión sobre la

infraestructura tecnológica. Las investigaciones en esta área apuntan hacia el desarrollo de nuevos

modelos de representación grá�ca de intrusiones, mecanismos de respuesta automática e�caces y

seguros, y elaboración de de�niciones formales de las limitaciones a las que deben estar sujetos

dichos mecanismos de respuesta activa [116, 27, 28].

Cuestiones Arquitectónicas

La realidad tecnológica de la mayoría de las actuales corporaciones y organizaciones está carac-

terizada por el alto nivel de conectividad de sus sistemas de computación. La presencia de redes

de comunicación de diferentes tipos es condición sine qua non y la distribución de los compo-

nentes de los modelos de negocio propiciada por dicha conectividad es una práctica ampliamente

extendida.

61

De esta forma, no es descabellado pensar, asimismo, en la distribución de las distintas etapas

del proceso de Detección de Intrusiones [89, 116, 49, 92, 384, 330, 322], con el objetivo de

alcanzar mayores cotas de e�ciencia, tolerancia a fallos y escalabilidad. Sin embargo, la habitual

heterogeneidad de los sistemas de computación, así como de las redes de comunicación, introduce

una importante componente de complejidad en el sistema de detección, a la hora de recoger

información proveniente de diferentes sistemas operativos, diferentes protocolos de comunicación,

diferentes servicios de aplicación, etcétera.

Por otro lado, existen ciertas particularidades técnicas propias de los diferentes tipos de

arquitecturas que pueden llegar a suponer un obstáculo en la labor de dicho sistema de detección,

como pueden ser las anteriormente descritas cuestiones de las redes conmutadas o del cifrado de

las comunicaciones. Los costes de administración pueden elevarse considerablemente, en función

de la �exibilidad que permita el sistema de detección en el momento de su despliegue. [351, 84,

78, 28, 15, 26, 100, 204]

Fortaleza

Como se ha explicado en apartados anteriores, el propio Sistema de Detección de Intrusiones

se convierte desde el momento de su implantación en uno de los objetivos fundamentales de

cualquier intruso. Para él, es necesario pasar lo más desapercibido posible, y la labor del sistema

de detección es precisamente la contraria. Esta es la razón por la que los sistemas de detección

suelen ser objeto de múltiples atentados contra su propia integridad y disponibilidad[116, 385].

En concreto, es muy importante proteger la etapa de recogida de información, tanto durante el

desarrollo de la misma, como posteriormente, en el momento del almacenamiento de la informa-

ción que debe surtir al proceso de análisis [191]. De otra forma, la información de partida puede

ser objeto de subversión y el sistema de detección estaría proporcionando una falsa sensación de

seguridad. [116, 351, 84, 165, 78, 28, 164, 92, 15, 26, 358, 77]

Cuestiones Operacionales

Existe una amplia colección de cuestiones relativas a la utilización de los Sistemas de Detección

de Intrusiones por parte de los usuarios, entre las que se encuentran la cuestión del mante-

nimiento, la escalabilidad, la portabilidad o la extensibilidad. Además, existen otros aspectos

importantes como pueden ser la interoperabilidad entre los distintos componentes o incluso en-

tre distintos sistemas de detección, o la supervisión administrativa necesaria para la correcta

parametrización de dichos sistemas. Por ello, es necesario prestar especial atención a esta cues-

tión de la operatividad, ya que puede marcar en muchos casos la diferencia entre una solución

e�ciente y que ofrece resultados de con�anza, y un software sin utilidad real para el usuario

[116, 351, 84, 340, 28, 164, 92, 15, 358, 77].

Evaluación

62

Esta área de conocimiento debe enfrentarse a una cuestión sobre la que aún hay mucho trabajo

por desarrollar, como es la veri�cación de los resultados, tanto de análisis como de rendimien-

to, ofrecidos por los Sistemas de Detección de Intrusiones. Dicha cuestión de la evaluación ha

demostrado empíricamente ser un problema de difícil solución, ya que no es fácil encontrar una

taxonomía precisa de las propiedades de detección que deben medirse. Es necesario de�nir las

propiedades que caracterizan de la forma más adecuada múltiples tipos de sistemas de cómputo

y diferentes tipos de redes de comunicación, y además es necesario de�nir el conjunto de proce-

dimientos de evaluación que deban aplicarse sobre dichas propiedades. De lo contrario, ante la

ausencia de una referencia sólida en la cuestión de la evaluación, ni los fabricantes de solución de

detección podrán comprobar la efectividad de sus productos, ni los investigadores podrán estar

seguros de la solidez de los modelos de detección sobre los que investigan [116, 249, 93, 232, 184].

Aspectos Sociales

La última cuestión componente del modelo conceptual hace referencia al nivel de responsabilidad

social que puede recaer sobre las decisiones tomadas por el Sistema de Detección de Intrusiones, y

que pueden afectar a terceras partes. Los problemas básicos que pueden observarse a este respecto

hacen referencia, por un lado, al nivel de agresividad que puede con�gurarse en la respuesta del

sistema de detección (máxime teniendo en consideración cuestiones como la potencialidad de

falsi�cación de la identidad del atacante), así como las cuestiones de privacidad derivadas de

la recogida de información necesaria para el proceso de detección. Asimismo, existe una última

consideración consistente en la potencial adaptación de los modelos de respuesta con el objetivo

de que sean capaces de proporcionar información pericial de carácter forense[116, 28, 154, 358] .

Actuales Líneas de Investigación

Cada una de las áreas de conocimiento descritas anteriormente presenta en mayor o menor

medida ciertas cuestiones aún no resueltas y sobre las cuales la comunidad cientí�ca plantea sus

líneas de investigación, con mayor o menor intensidad.

Con el objeto de construir una imagen de conjunto de los estudios más importantes que se

están llevando a cabo en la actualidad en el área de la Detección de Intrusiones, Emilie Lundin

y Erland Jonsson han realizado una recopilación de los artículos publicados en las conferencias

más representativas del sector durante los últimos años [116].

En la siguiente tabla, se incluye la versión completa que aparece en el estudio original, y en

la que se hace referencia al número de investigaciones realizadas en los últimos años en las nueve

áreas de conocimiento que componen el modelo conceptual.

63

Cuadro 2.1: Líneas de Investigación sobre Detección de Intrusiones

Relación entre retos y líneas de investigación

Cada una de las líneas de investigación descritas anteriormente y cuyo volumen de publica-

ciones se recoge en el apartado anterior, está íntimamente relacionada con los retos tecnológicos

descritos en el Capítulo 1. La tabla puesta a continuación describe de forma grá�ca dichas re-

laciones. Como puede observarse, la línea de investigación de análisis (la cual presenta, con una

gran diferencia con respecto al resto de líneas, el mayor número de publicaciones, según la tabla

anterior) aborda por sí misma la mayoría de los retos fundamentales descritos en el capítulo

primero, por lo que la selección de la misma como elemento fundamental del presente trabajo de

investigación puede cali�carse como una opción más que razonable.

2.1.3. Taxonomía

De entre los diferentes elementos componentes del modelo conceptual de Lundin, aquéllos

que tradicionalmente se han utilizado para categorizar las distintas tipologías de Sistemas de De-

tección de Intrusiones han sido los que corresponden al conjunto de consideraciones funcionales

básicas. De esta forma, la recogida de información, el análisis y la respuesta son los tres pila-

res fundamentales que se consideran habitualmente, si bien en algunas ocasiones otras cuestiones

adicionales (arquitectónicas u operacionales, por lo general) son utilizadas también como criterios

de categorización. A este respecto, autores de reconocido prestigio internacional como pueden ser

Alessandri, Allen, Axelsson, Bace, Debar, Kahn, Krügel o Lazarevic, expresan diferentes sensi-

bilidades respecto a la cuestión de la categorización, por lo que no existe una taxonomía general

64

Cuadro 2.2: Relación entre retos de la Detección de Intrusiones y líneas de investigación

única que pueda utilizarse como referente universal. Por ello, y con el objetivo de establecer una

clasi�cación general sobre la cual de�nir el ámbito y la ubicación conceptual del presente traba-

jo de investigación, se incluye a continuación un breve estudio sobre las diferentes alternativas

existentes.

Taxonomía de Alessandri et al.

A pesar de que el objetivo principal del trabajo de Alessandri et al. [17] consiste en clasi�car,

fundamentalmente a nivel operacional y no tanto a nivel conceptual, tanto los distintos tipos de

sistemas de detección, como los distintos tipos de actividad subversiva, incluye una interesante

taxonomía general de Sistemas de Detección de Intrusiones. La �gura siguiente ilustra dicha

taxonomía:

Dicha taxonomía está construida a partir de un modelo general de funcionamiento simple, en

el cual solamente se consideran los componentes de recogida de información y análisis. Dicho mo-

delo general es compatible con los esfuerzos que desarrolla el Intrusion Detection Working Group

(IDWG) del IETF con el objetivo de estandarizar los �ujos de información entre componentes

[102].

Taxonomía de Allen et al.

Julia Allen se aproxima considerablemente al modelo general propuesto por Alessandri [15].

En este caso, la descripción funcional de un Sistema de Detección de Intrusiones se divide en

tres elementos componentes: Sensor, analizador e interfaz de usuario. Alessandri consideraba

65

Figura 2.2: Taxonomía de Alessandri et al.

Figura 2.3: Modelo general de Alessandri et al.

66

Figura 2.4: Taxonomía de Allen et al.

que la cuestión del interfaz podía generalizarse fuera del sistema de detección, por lo que sólo

contemplaba las dos primeras cuestiones. Por otro lado, a partir de dicho modelo, se describen

independientemente las cuestiones de la recogida de información y del análisis. De esta forma,

en cuanto a la cuestión de la recogida de información, Allen establece cuatro tipos de fuentes de

información desde las cuales puede realizarse el proceso de detección: Aplicación, máquina, red o

infraestructura multi-red. Además, en concreto, en la recogida de información basada en máquina,

se diferencia el nivel lógico desde el que se recoge la información para la fase de análisis: A nivel

de servicio de aplicación de auditoría, y a nivel de servicio de llamadas al sistema. Por último,

en cuanto a la cuestión del método de análisis, se describen las dos grandes �losofías: Detección

de usos indebidos, �rmas, o patrones, y detección de anomalías. La taxonomía representada en

la �gura 2.4 es un compendio de todas estas consideraciones:

Taxonomía de Bace y Mell

Rebecca Bace y Peter Mell siguen un modelo de taxonomía similar al propuesto por Allen

et al., si bien en este caso se presta una mayor atención al componente de respuesta, en el cual

se pasa de dar por supuesta la pasividad del mecanismo de respuesta (como es característico de

los casos anteriores), a considerar el hecho de que dicho mecanismo pueda responder de forma

activa [28]. La �gura 2.5 ilustra esta taxonomía.

Taxonomía de Axelsson

A pesar de que Stefan Axelsson centra su estudio general sobre Detección de Intrusiones en

los principios fundamentales del componente de análisis (el cual lógicamente presenta un mayor

interés cientí�co), también incluye una detallada categorización sobre el resto de característi-

cas propias de todo sistema de detección [26]. La �gura a continuación ilustra la taxonomía

presentada por dicho autor:

67

Figura 2.5: Taxonomía de Bace y Mell.

Figura 2.6: Taxonomía de Axelsson

68

Figura 2.7: Taxonomía de Debar, Dacier y Wespi

Taxonomía de Debar, Dacier y Wespi

Una taxonomía muy utilizada como referencia en la bibliografía [297] es la desarrollada por

Debar, Dacier y Wespi en 1.999 [100]. En ella, además de los tres grandes elementos de cate-

gorización que aparecen en la taxonomía de Bace, se introduce la componente de la frecuencia

de análisis del sistema de detección. Este aspecto ha sido especialmente relevante durante las

primeras etapas de la evolución de la Detección de Intrusiones, ya que marcaba la diferencia

entre aquellos sistemas que eran capaces de detectar casos de intrusión en el mismo instante en

que ésta se estaba produciendo, y aquéllos que no. Sin embargo, en la actualidad, la práctica to-

talidad de Sistemas de Detección de Intrusiones operan en tiempo real, por lo que dicha tipología

de clasi�cación ha perdido cierta importancia.

Esta clasi�cación fue revisada por Stefan Axelsson [26] y el propio Debar apenas un año

después [101]. En dicha revisión, se introdujo el concepto de paradigma de detección como nuevo

criterio principal de clasi�cación; paradigma que hace referencia al tipo de análisis que se realiza

y que presenta dos alternativas posibles: Detección orientada al análisis de los estados por los

que pasa el sistema, y detección orientada al análisis de las transiciones entre dichos estados.

Asimismo, dichas alternativas presentan a su vez dos enfoques distintos en lo referente a la

evaluación que llevan a cabo sobre el sistema: Evaluación proactiva y evaluación pasiva o no

intrusiva.

Por último, en cuanto al tipo de fuente de información, se introducen dos nuevas alterna-

tivas: Registro de auditoría de aplicación, por un lado8, y registro de alertas provenientes de

otros sistemas de detección9, conectados secuencialmente, por otro. La �gura 2.8 ilustra estos

8Concepto que hace que la taxonomía en cuestión se mantenga en perfecta consonancia con las alternativaspropuestas por Allen [15] y Bace [28].

9Concepto que contempla la posibilidad de que un determinado Sistema de Detección de Intrusiones utilicela información proveniente de otros sistemas de detección conectados, de esta forma, de manera secuencial. Estaorganización cooperativa de múltiples sistemas de detección permite abordar la problemática de la Reducción deAuditoría [322] de una forma potencialmente más e�ciente.

69

Figura 2.8: Taxonomía revisada de Debar, Dacier y Wespi.

re�namientos realizados sobre la taxonomía original.

Taxonomía de Lazarevic, Kumar y Srivastava

El modelo taxonómico más reciente es fruto de los estudios realizados por Aleksandar Lazare-

vic, Vipin Kumar y Jaideep Srivastava [227], y está basado fundamentalmente en las taxonomías

propuestas anteriormente por Stefan Axelsson [26] y Hervé Debar et al.[100]. En particular, a

los tres pilares fundamentales de recogida de información, análisis y respuesta, se propone la

agregación de la cuestión arquitectónica, así como de la cuestión de la tipología de restricciones

temporales a las que el sistema de detección debe estar sujeto.

Taxonomía de Krügel

Christopher Krügel utiliza en su tesis doctoral[50] una taxonomía similar a la propuesta por

Rebecca Bace y Peter Mell [28], a la cual añade el criterio fundamental del almacenamiento

de datos de auditoría. A continuación se describe, mediante la siguiente �gura, la taxonomía

resultante.

Taxonomía de Indian CERT

El Indian Computer Emergency Response Team propone una clasi�cación de Sistemas de

Detección de Intrusiones dividida en dos grandes grupos de características: Componentes funda-

mentales y cuestiones adicionales [CERT/IN03].

70

Figura 2.9: Taxonomía de Lazarevic

Figura 2.10: Taxonomía de Krügel

71

Figura 2.11: Taxonomía de Indican CERT.

Como puede observarse, las cuestiones fundamentales son idénticas a las recogidas por Bace

y Mell en su propuesta de taxonomía. Por otro lado, las mencionadas cuestiones adicionales

toman en consideración las diferentes tipologías que pueden plantearse en cuanto a arquitecturas,

estrategias de control y temporización.

En concreto, en primer lugar, se hace referencia a la cuestión de la ubicación del sistema de

detección, que puede realizarse bien sobre el propio sistema objetivo a proteger, o bien mediante

una máquina especí�ca dedicada a tal efecto. En segundo lugar, se hace referencia al hecho

de que el control del sistema de detección puede llevarse a cabo desde diferentes niveles de

descentralización, de forma que puede optarse bien por una estrategia centralizada, bien por una

solución completamente distribuida, o bien por un esquema intermedio.

Por último, la periodicidad operativa del sistema de detección puede categorizarse en dos

grandes grupos: por un lado, sistemas orientados a determinar la ocurrencia o no de intrusiones

en el sistema con �nes puramente forenses, y por otro, sistemas orientados a detectar inmediata-

mente cualquier intento de intrusión, con el objetivo de poder plantear una respuesta mientras

dicha intrusión aún está teniendo lugar.

Common Intrusion Detection Framework

Con el objetivo de proporcionar un marco de trabajo estándar, que permitiera tanto a fa-

bricantes como a investigadores eliminar las di�cultades de integración y comunicación que pre-

sentaban los distintos elementos de las múltiples arquitecturas de detección existentes, Kahn,

72

Figura 2.12: Arquitectura CIDF.

Porras, Staniford-Chen y Tung propusieron en 1.998 una arquitectura genérica, dividida en tres

grandes pilares fundamentales [208] que se describen a continuación:

Arquitectura de detección CIDF10, construida a partir de componentes genéricos, denomi-

nados Boxes, y que son responsables de las tareas de recogida de información, almacena-

miento, análisis y respuesta.

Lenguaje de comunicación entre componentes CISL11, que permite un intercambio de in-

formación semántica estándar y bien de�nida.

Especi�cación de directorio, a partir de la cual los diferentes componentes pueden locali-

zarse y autenti�carse entre ellos.

Contribución de Kim y Spa�ord

Dentro del área de conocimiento de la Detección de Intrusiones orientada a la Máquina, Gene

Kim y Eugene Spa�ord introdujeron en 1.994, en su artículo The Design and Implementation

of Tripwire: A File System Integrity Checker, el concepto de Veri�cación de Integridad, también

conocido como Detección de Intrusiones orientada a Objetivos12. En dicho artículo, los autores

proponían un Sistema de Detección de Intrusiones que aplicaba técnicas criptográ�cas de cifrado

irreversible para garantizar la integridad de aquellos recursos críticos del sistema a proteger.

De esta forma, aparecía una nueva tipología de sistema de detección que, si bien mantenía

claramente su orientación a la máquina, dejaba de utilizar información proveniente de los registros

de auditoría de sistemas operativos y servicios de aplicación, y pasaba a utilizar sus propios

registros [389].

10CIDF: Common Intrusion Detection Framework.11CISL: Common Intrusion Speci�cation Languaje.12Detección de Intrusiones orientada a Objetivos o Target-based Intrusion Detection.

73

Figura 2.13: Taxonomía ESIDE.

Contribución de Ko, Ruschitzka y Levitt

Dentro del área de conocimiento de la Detección de Anomalías, Calvin Ko, Manfred Ruschitz-

ka y Karl Levitt introdujeron en su artículo Execution monitoring of security-critical programs

in distributed systems: A speci�cation-based approach, el concepto de Detección de Anomalías

basada en Especi�cación. Dicho concepto supone una importante innovación con respecto a la

�losofía tradicional de detección de anomalías, que abogaba por la creación de per�les (por lo

general estadísticos) de comportamiento para su posterior contraste con la actividad cotidiana

de los usuarios del sistema [213]. En el caso de la presente propuesta, dichos per�les no se cons-

truyen dinámicamente, sino que se especi�can a partir de conocimiento experto que se formaliza

en forma de reglas. De esta forma, todo comportamiento que se desvíe signi�cativamente del

conjunto de reglas preestablecidas será susceptible de ser catalogado como subversivo, y recibirá

consecuentemente una respuesta en esta línea.

Taxonomía ESIDE-Mendizale

A partir de las múltiples consideraciones descritas en los apartados anteriores, se propone

un modelo de taxonomía general que pretende sintetizar los diferentes puntos de vista, desde

una perspectiva conceptual. Dicha taxonomía presenta tres pilares fundamentales: recogida de

información, análisis y respuesta [351, 28, 15] , tal y como se ilustra en la �gura. Además, como

puede observarse en dicha �gura, cada uno de esos tres pilares fundamentales presenta una

categorización propia, construida a partir de las diferentes re�exiones aportadas por los autores

anteriores. En primer lugar, se clasi�can los Sistemas de Detección de Intrusiones en base al tipo

de recogida de información que implementan, que puede estar orientada a la máquina, o a la red

[100].

74

Figura 2.14: Ubicación de hipótesis fundamentales

De esta forma, dentro de las soluciones orientadas a la máquina, en primer lugar, pueden

observarse sistemas de detección basados en información del Sistema Operativo, de los servicios

de aplicación, o de sus propios registros de auditoría (característica particular de los sistemas

de veri�cación de integridad) [389]. Además, la recogida basada en el sistema Operativo puede

realizarse, asimismo, a nivel de servicio o a nivel de kernel o núcleo [15].

Por otro lado, en segundo lugar, la recogida de información orientada a la red presenta,

además de los mecanismos propios de dicha categoría, un tipo especial de sistema de detección

que se caracteriza por su orientación al nodo de red [84, 78, 241].

Asimismo, en lo relativo al método de análisis, la taxonomía propuesta contempla las dos gran-

des �losofías de Detección de Intrusiones: Detección de Usos Indebidos y Detección de Anomalías

[351, 50, 28, 15, 101, 100, 208]. Además, dentro de la Detección de Anomalías, se presta especial

atención a la cuestión de la presencia o no de conocimiento experto, ya que el presente trabajo

de investigación considera especialmente la clara diferenciación que existe entre ambos métodos

[213].

Por último, la fase de respuesta presenta dos categorías de sistemas de detección: Por un lado,

la tradicional respuesta pasiva, consistente en noti�caciones de alarma al operador humano, y

por otro, la respuesta activa contra agresiones detectadas contra el sistema que se pretende

proteger [351, 49, 28, 101, 100, 208]. Además, en lo relativo a la respuesta activa, se diferencia

entre aquellos sistemas que responden a la agresión y aquéllos diseñados para impedir que dicha

agresión consiga impactar en dicho sistema (concepto comúnmente identi�cado con el término

Prevención de Intrusiones) [337, 341].

75

2.2. Técnicas de análisis

Como se ha expuesto anteriormente, en los apartados anteriores, el componente de Análisis

constituye la línea de investigación en la que existe actualmente un mayor interés y sobre la cual

se está llevando a cabo la mayor actividad investigadora, tanto dentro del mundo académico

como dentro de la industria de la Seguridad de la Información.

Dicho componente acapara en estos momentos el mayor número de publicaciones de las

más prestigiosas conferencias internacionales, y centra sobre sí mismo las mayores inquietudes

innovadoras del área de conocimiento de la Detección de Intrusiones.

Además, tal y como se ha explicado, dicho elemento mantiene una íntima relación con los

retos tecnológicos que aún esperan ser resueltos, por lo que se revela claramente como el camino

por el que debe desarrollarse toda investigación relevante. Por todo ello, tanto las hipótesis fun-

damentales, como los objetivos generales, especí�cos y operacionales, se centran precisamente en

el mencionado módulo de análisis, y están basados esencialmente en los principios fundamentales

de éste.

De esta manera, con el objetivo de situar la actividad investigadora realizada en el presente

estudio en el vasto horizonte de cuestiones propias del área de la Detección de Intrusiones, se

describen a continuación las principales �losofías de análisis existentes en la actualidad, esto es:

Detección de Usos Indebidos y Detección de Anomalías.

2.2.1. Detección de Usos Indebidos

Tal y como se explica en la de�nición 1.20, la Detección de Usos Indebidos hace referencia

al método de Detección de Intrusiones que aboga por utilizar la de�nición previa de dichas

intrusiones para su posterior contraste con la actividad cotidiana del sistema que se desea proteger

[28]. De esta manera, la operatoria del sistema de detección está basada por completo en la vasta

recopilación de conocimiento experto proveniente del operador humano, y que incluye una ingente

cantidad de de�niciones de ataques conocidos, así como de vulnerabilidades conocidas. Así pues,

una vez recogido dicho conocimiento experto, la detección de cualquier rastro de una actividad

que previamente haya sido catalogada como maliciosa (y que utilice por lo tanto alguno de

los ataques documentados, o intente explotar alguna de las vulnerabilidades conocidas) puede

llevarse a cabo de forma e�ciente y, sobre todo, muy precisa.

No obstante, es precisamente el motivo de su efectividad la razón de que este tipo de Sistemas

de Detección de Intrusiones se encuentre enormemente limitado para responder ante situaciones

de riesgo para las que no existe un modelo previamente documentado. Por lo general, ante una

ligera variación de uno de los ataques documentados, el sistema de detección no localiza en

su base de conocimiento la �rma o patrón representativo de dicho ataque y es por lo tanto

incapaz de responder. Esta cuestión obliga al administrador humano a una minuciosa (y por lo

tanto, costosa) elaboración de las �rmas de ataque, con el doble objetivo de que sean lo más

76

Figura 2.15: Modelo general de Detección de Usos Indebidos.

genéricas posible y de que no generen falsos positivos. Por otro lado, la respuesta ante un Zero-

Day Attack es igualmente fallida, lo que obliga (al igual que en el caso anterior) a una periódica

actualización de dicha base de conocimiento. En general, estas características propias de los

sistemas de detección basados en Detección de Usos Indebidos hacen que dichos sistemas sean

cali�cados habitualmente como precisos pero incompletos [100].

Así pues, con el objetivo de proporcionar una visión general sobre el funcionamiento interno de

este tipo de sistemas de detección, que permita extraer las conclusiones necesarias para identi�car

las problemáticas existentes y enunciar los grandes retos que aún presenta esta tecnología, se

describen a continuación los principios básicos de funcionamiento sobre los cuales está construida

la inmensa mayoría de ellos.

Reconocimiento estático de Patrones.

Está técnica es la forma de Detección de Usos Indebidos más simple que existe, así como la

más extendida, y está basada en la búsqueda de patrones o �rmas básicas13 dentro del �ujo de

eventos proporcionado por el mecanismo de recogida de información [297, 317]. Dichos patrones

están constituidos por lo general por un conjunto de atributos discretos que tiene el objetivo de

formalizar el conocimiento experto que se deberá utilizar durante el proceso de detección. Por

otro lado, a pesar de las limitaciones semánticas que presenta este método, su sencillez permite

conseguir una gran e�ciencia a la hora de tomar decisiones, por lo que su utilización es en

muchos casos más que su�ciente. Algunos de los actuales Sistemas de Detección de Intrusiones

que utilizan, entre otras, esta técnica son Snort, Bro96[277], NFR97 [260, 294], RealSecure,

CISCO Secure IDS [69], o Dragon [171].

13Es muy habitual la de�nición de patrones mediante la especi�cación de cadenas de símbolos que se correspon-den con diferentes métodos de ataque. Si se localiza una cadena o subcadena concreta dentro de un determinadoevento, se habrá detectado el correspondiente ataque.

77

Figura 2.16: Batería de reglas de Snort para detección de Shellcodes

Figura 2.17: Firma de Snort para detección de ataques contra Apache

Figura 2.18: Firma de Bro para detección de ataques contra Apache

78

Figura 2.19: Batería de reglas de Dragon para detección de Shellcodes

Figura 2.20: Firma de NFR para detección del histórico ataque Land Attack

79

Probabilidad Condicional

El método anterior presenta un comportamiento su�ciente en muchos casos, pero adolece de

una importante carencia de capacidad representativa [297]. En concreto, es habitual el hecho

de que un determinado patrón identi�que la existencia de su ataque correspondiente no de

forma categórica, sino con una cierta probabilidad [304]. De esta manera, es posible la aparición

de situaciones en las que la detección del patrón no implique absolutamente el hecho de que

el sistema esté siendo atacado. Por ello, un motor de análisis semánticamente completo debe

contemplar el concepto de probabilidad condicional [155]:

(2 : 1) P (Intrusion/Patron)14

A continuación, mediante la aplicación del Teorema de Bayes [360] a la expresión anterior,

es posible obtener:

(2 : 2) P (Intrusion/Patron) = P (Patron/Intrusion)P (Intrusion)P (Patron)

De esta forma, a partir de la expresión 2.2, un administrador humano es capaz de cuanti-

�car dicha probabilidad condicional, simplemente mediante el cálculo de los tres términos que

componen dicha expresión. Para ello, es necesario disponer de un registro histórico que recoja la

experiencia del sistema, y a través del cual sea posible cuanti�car la probabilidad a priori15 [155]

de la ocurrencia de una intrusión, o P (Intrusion).Asimismo, gracias a dicho histórico también es posible determinar, para cada uno de los patro-

nes de ataque, tanto la probabilidad a priori de dicho patrón, o P (Patron), como la probabilidad

condicional P (Patron/Intrusion).Por otro lado, este modo de calcular la probabilidad condicional puede no ya utilizarse ante

eventos individuales, sino extenderse incluso a secuencias de eventos, con lo que se consigue una

mayor capacidad representativa del estado del sistema que se pretende proteger. Para ello, sería

necesario calcular, de una forma similar, la probabilidad P (Intrusion/Secuencia De Eventos[304].

Sistemas Expertos

Otra �losofía de análisis, extremadamente potente, que se ha aplicado en algunas ocasiones a

la Detección de Intrusiones basada en Detección de Usos Indebidos es la utilización los denomi-

nados Sistemas de Producción o Sistemas Expertos[387]. Dichos sistemas persiguen el objetivo

fundamental de independizar la lógica de decisión del conocimiento necesario para formalizar la

solución a los problemas a los que se aplican. De esta forma, un sistema experto está compuesto

14La expresión 2.1 indica la probabilidad condicional de que se haya producido una intrusión, ante la evidenciade haberse detectado un determinado patrón de ataque.

15102

80

Figura 2.21: Regla de MIDAS para monitorización de cuentas de usuario privilegiadas

Figura 2.22: Regla de MIDAs para análisis de horario inusual en el acceso a cuentas de usuario

por lo general de un motor de análisis o inferencia, responsable de la toma de decisiones, y de

una base de conocimiento basada en la especi�cación de baterías de reglas, cuya elaboración es

responsabilidad del experto humano.

En general, las reglas en las que estos sistemas codi�can el conocimiento experto responden

al modelo if-then, de forma que habitualmente están compuestas por dos elementos: un conjunto

de condiciones o hechos, y un conjunto de acciones a llevar a cabo en caso de que se cumplan las

condiciones correspondientes. De esta forma, cuando el motor de inferencia detecta que un deter-

minado evento satisface el conjunto de condiciones de una regla, simplemente dispara el conjunto

de acciones asociado a dicha regla, pudiendo con�rmar de esta forma nuevos hechos (satisfacer

nuevas condiciones) que permiten a su vez disparar nuevas reglas, de forma encadenada, hasta

que es explotado todo el conocimiento disponible.

A pesar de que esta �losofía de detección resulta muy precisa, por lo general, el gran volumen

de datos de auditoría que habitualmente es necesario procesar a través del motor de inferencia

puede llegar a introducir serios problemas de rendimiento durante su explotación. El proyecto

Haystack [306] fue, en 1.988, el primer caso de sistema experto aplicado a la Detección de Intru-

siones, si bien han aparecido desde entonces (sobre todo en los primeros años de la evolución)

otras muchas soluciones que aplican conceptos similares, como pueden ser MIDAS16 17 [317],

IDES, NIDES, EMERALD, DIDS o CMDS18 [272].

También los más recientes y anteriormente mencionados Snort, Bro, NFR, RealSecure, CIS-

CO Secure IDS, o Dragon usan esta técnica, en mayor o menor medida. Sin embargo, por lo

general, el conocimiento experto utilizado en estos sistemas no contempla la posibilidad de que

determinados patrones o �rmas habiliten el disparo encadenado de nuevas reglas, lo que repre-

senta la pérdida de uno de los pilares fundamentales de los sistemas expertos. De esta forma,

16MIDAS: Multics Intrusion Detection and Alerting System.17MIDAS utiliza el denominado Production-Based Expert System Toolset (P-BEST), desarrollado inicialmente

por Alan Whitehurst y evolucionado posteriormente en los desarrollos de IDES, NIDES y EMERALD [231].18CMDS: Computer Misuse Detection System.

81

Figura 2.23: Base de hechos de P-BEST/EMERALD para detección del histórico ataque TCPSYN Flood.

la verdadera esencia de este enfoque queda muy frecuentemente sin explotar y restringida a ta-

reas secundarias de registro de información forense, debido a la complejidad administrativa que

introduce su utilización plena19.

Por otro lado, este tipo de sistemas presentan por lo general una importante limitación, rela-

cionada con su incapacidad para representar la dimensión temporal, la cual es utilizada frecuen-

temente para resolver la ordenación cronológica de los eventos a medida que se van produciendo

en el sistema. El conjunto de todos los hechos demostrables de la base de conocimiento no lleva

asociada de forma implícita ningún tipo de información temporal, por lo que dichos sistemas

son simplemente incapaces de determinar el orden en que se han ido con�rmando los diferentes

hechos, y por lo tanto de tomar consideración cronológica alguna durante el proceso de decisión.

Existen algunas soluciones que tratan de solventar esta cuestión mediante la especi�cación

explícita de la información temporal, si bien se reducen en la mayoría de los casos a propuestas

experimentales [304]. En general, aquellas problemáticas de seguridad que requieren necesaria-

mente dichas consideraciones temporales, como pueden ser el escaneo de puertos20 o la denegación

de servicio, son resueltas mediante métodos especí�cos, añadidos como módulos del sistema de

detección [323].

Asimismo, otro inconveniente característico de estos sistemas consiste en que las decisiones

del motor de inferencia están limitadas cualitativamente a la calidad del conocimiento experto de

los responsables de seguridad encargados de la especi�cación de la base de conocimiento. Además,

el modo en que dichos responsables especi�can el mencionado conocimiento experto puede llegar

a hacer que la base de conocimiento sea en muchos casos completamente ininteligible, debido al

altísimo nivel de detalle que puede alcanzarse en la elaboración de las baterías de reglas, sobre

todo en entornos en los que es necesaria una alta optimización de dichas baterías.

Por último, es interesante prestar atención al hecho de que los sistemas expertos son sus-

ceptibles de ser utilizados con el objetivo de combinar múltiples parámetros de Detección de

Intrusiones, de forma que es posible construir un modelo homogéneo que, además, introduce en

el análisis el concepto de certidumbre. En cualquier caso, la representación de la certidumbre

en dichos sistemas de producción presenta grandes limitaciones, tal y como se desprende de los

19De hecho, en las últimas versiones de Snort se apunta la posibilidad de eliminar la capacidad de encadena-miento de reglas, en bene�cio de una solución de registro de información forense administrativamente más sencilla,denominada Tagging [323].

20Escaneo de Puertos o Port Scanning [138]: �An attack that sends client requests to a range of server port ad-dresses on a host, with the goal of �nding an active port and exploiting a known vulnerability of that service.�[288]

82

Figura 2.24: Batería de reglas de P-BEST/EMERALD para detección del histórico ataque TCPSYN Flood

estudios realizados por Judea Pearl [187].

Diagramas de Transición de Estados

Esta propuesta pretende optimizar el volumen del �ujo de alarmas que son transmitidas hacia

el operador humano. En concreto, su objetivo fundamental consiste en identi�car, representar y

analizar las diferentes fases por las que suelen pasar, en general, los distintos tipos de agresiones

contra sistemas de información. De esta forma, en lugar de utilizar un único patrón para repre-

sentar un determinado ataque, este tipo de sistemas utiliza diagramas de transición de estados,

o autómatas �nitos21[373], que representan los distintos estados que debe alcanzar un intruso

potencial para llevar a cabo con éxito dicho ataque. Asimismo, las transiciones entre estados se

caracterizan mediante condiciones, o asertos, que deben ser satisfechas para que se materialicen

dichas transiciones. Cada una de estas transiciones equivale a una regla de los anteriores sistemas

expertos. Por otro lado, el estado inicial de cada uno de los diagramas representa el estado del

sistema antes de ser agredido, mientras que el último de los estados se caracteriza por represen-

tar el éxito del ataque. Lógicamente, el sistema a proteger no debería llegar a ninguno de los

múltiples estados �nales bajo ningún concepto.

De este modo, mediante el seguimiento del estado de avance en el que se encuentra un

determinado atacante, es posible liberar al administrador humano de una gran cantidad de

noti�caciones de alarma. Solamente se le informa de aquellos eventos que pueden llevar al sistema

21Denominados escenarios.

83

Figura 2.25: Escenario de STAT para detección de ataques contra servidores IMAP

Figura 2.26: Especi�cación en lenguaje STATL de escenario de STAT para detección de ataquecontra servidores IMAP

a un estado inseguro. La primera aproximación de Sistema de Detección de Intrusiones basado

en diagramas de transición de estados fue STAT[367, 170, 381] , que posteriormente fue portado

a sistemas Unix bajo el nombre de USTAT[203]. Las �guras siguientes, extraídas de los estudios

de Steve Eckmann, describen de forma grá�ca un escenario de ataque contra servidores IMAP22,

escrito en lenguaje STATL[120].

Sin embargo, a pesar de lo aparentemente innovador de esta propuesta, la aportación concep-

tual que provee con respecto a los anteriores sistemas de detección basados en sistemas expertos

no es muy grande. Ambos modelos son semánticamente equivalentes [119], por lo que cualquier

diagrama de transición de estados puede representarse mediante un conjunto de reglas de pro-

ducción, y viceversa. Eckmann incluso propone la traducción automática23 de baterías de reglas

de Snort24 [242] en escenarios de STAT [381]. Además, se da la circunstancia de que, en muchos

casos, los requisitos de rendimiento obligan a utilizar reglas muy ligeras y con pocas relaciones

entre ellas, por lo que dichos modelos son muy poco utilizados en la práctica.

22IMAP: Internet Message Access Protocol. [288]23Para lo cual, el propio Eckmann ha desarrollado la herramienta Snort2Statl.24A pesar de que en la mayoría de los casos solamente se utiliza la capacidad de Snort de identi�car patrones

estáticos, es posible utilizar toda la potencia conceptual de los sistemas de producción, a través de dos parámetrosespeciales, denominados activates y dynamic [323].

84

Figura 2.27: Reglas de Snort para detección de ataques contra servidores IMAP

Figura 2.28: Red de Petri de IDIOT para validación del proceso de login

Redes de Petri

Una variante interesante de los sistemas de detección basados en diagramas de transición de

estados, es la propuesta en 1.994 por Sandeep Kumar y Eugene Spa�ord, en su sistema IDIOT25

[391], el cual hace uso de las denominadas Redes de Petri [56] para representar escenarios de

intrusión. Dichas Redes de Petri se caracterizan por poseer una capacidad semántica superior a

los tradicionales autómatas �nitos [238], y su uso está muy extendido, sobre todo, en sistemas

de producción automática. En concreto, una de las características más potentes que presentan

es su capacidad de representar procesos o tareas concurrentes, de forma que un determinado

sistema puede encontrarse en un momento dado, no en un único estado de ejecución, sino en

varios. Para ello, una Red de Petri está compuesta, no sólo por un conjunto de estados y un

conjunto de transiciones entre dichos estados (como era el caso de los diagramas de transición de

estados, referenciados anteriormente), sino además por un conjunto de tokens, marcas o testigos,

que habilitan el disparo de dicho conjunto de transiciones. De esta forma, una determinada

transición no se materializará realmente, incluso aunque se con�rme su condición asociada, a

menos que exista un número adecuado de tokens en los estados origen de dicha transición (que

pueden ser varios, al contrario que en el caso anterior) que la habiliten. Por otro lado, una

vez habilitada y disparada dicha transición, se consumen los tokens ya utilizados en los estados

origen, y se crean nuevos tokens en los estados destino de la misma. La �gura 2.31, extraída

de los estudios originales de Kumar y Spa�ord [390], describe de forma grá�ca un escenario de

validación de intentos de acceso a un sistema Unix.

Sin embargo, a pesar de la mayor potencia de representatividad de las Redes de Petri, la

solución propuesta en el proyecto IDIOT, dada la complejidad administrativa que requiere la

elaboración de redes que aprovechen todo el potencial del modelo general, no hace uso de toda

la capacidad semántica que tiene a su disposición (sobre todo en lo relativo a la mencionada

especi�cación de concurrencia) [391], por lo que es posible construir un modelo equivalente ba-

25IDIOT: Intrusión Detection In Our Time. Los autores deseaban hacer referencia explícita, no exenta de ciertaironía, al habitual desfase de tiempo que existe desde que se construye el prototipo experimental hasta que selanza el desarrollo del sistema de producción.

85

sado en sistemas expertos. Además, al igual que en los casos anteriores, la calidad de la base

de conocimiento sigue dependiendo de la calidad del conocimiento experto del administrador

humano responsable de la con�guración del sistema de detección.

Detección basada en Modelos

Esta técnica fue propuesta por Garvey y Lunt en 1991[383] e introduce el concepto de modelo

de ataque, en combinación con un mecanismo de razonamiento basado en evidencias que tiene

como objetivo la inferencia de conclusiones. Mantiene ciertas similitudes con los métodos basados

en diagramas de transición de estados, los cuales son en este caso denominados modelos, así como

con los métodos basados en probabilidad condicional. De esta forma, la omnipresente base de

conocimiento está compuesta en esta ocasión por un conjunto de modelos, cada uno de los

cuales representa una secuencia de comportamientos constitutivos de un determinado ataque.

Posteriormente, durante la explotación del sistema, a partir de las acciones de cada uno de los

usuarios del mismo, el motor de inferencia va descartando probabilísticamente ciertos modelos, de

forma que el conjunto de los ataques posibles que pueden corresponderse con la situación actual

de dicho sistema se va reduciendo progresivamente. De esta manera, si se da el caso de que

dicho conjunto de modelos potenciales queda vacío, se puede concluir que el comportamiento del

usuario en cuestión es legítimo. Además, este método va más allá del mero análisis estadístico

ya que anticipa, antes de llevar a cabo cada una de las comprobaciones, una selección de los

parámetros de comportamiento a veri�car, en base al conjunto de modelos que en un momento

dado aún tiene posibilidades. De esta forma, no sólo se lleva a cabo el análisis pertinente, sino

que se busca continuamente cómo realizar dicho análisis de la forma más e�ciente posible.

En general, el proceso completo de análisis queda reducido de este modo a dos etapas: Una

primera etapa en la cual se establece un conjunto de hipótesis de comportamiento, y una segunda

en la cual se contrastan dichas hipótesis con la actividad registrada en el histórico de auditoría.

En términos probabilísticos, si se desea obtener una veri�cación precisa y e�ciente, la relación

entre las hipótesis de comportamiento y la actividad que realmente se lleva a cabo en el sistema

debe constituir el valor más alto posible [304].

(2 : 3)P (Actividad/Comportamiento)

P (Actividad/Cualquier otro comportamiento)

Al igual que el caso de los Sistemas de Detección de Intrusiones basados en probabilidad

condicional, el registro histórico de las evidencias que se producen en el sistema permite obtener

un cálculo adaptativo de la probabilidad de los diferentes modelos. A medida que el sistema

evoluciona, algunos de esos modelos ganan peso especí�co (se hacen más probables, dados ciertos

comportamientos), mientras que otros pierden relevancia.

De esta forma, es posible obtener una adecuada representación del concepto de certidumbre,

al igual que en el caso de los sistemas basados en probabilidades condicionales, de forma que se

pueden superar ciertas limitaciones inherentes a los sistemas expertos, como pueden ser la pro-

86

pagación de la certidumbre o la aparición de hechos contradictorios. Además, dada su capacidad

para anticipar los parámetros de detección a analizar, si se con�guran los distintos modelos de

forma que utilicen progresivamente parámetros cada vez más detallados y complejos, es posi-

ble obtener unos requisitos computacionales muy bajos. Así pues, en primer lugar, cuando aún

se tiene un gran conjunto de modelos a veri�car, se analizarían parámetros de grano grueso, y

posteriormente, cuando el número de modelos se va haciendo cada vez menor, se irían analizan-

do parámetros con un mayor nivel de detalle. Por supuesto, todas estas consideraciones hacen

que la Detección de Intrusiones basada en Modelos presente unos requisitos de administración

extraordinarios, de forma que en la práctica su utilización es muy escasa.

Por último, es importante prestar especial atención al hecho de que este tipo de sistemas

de detección no sustituyen a los Sistemas de Detección de Intrusiones basados en Detección de

Anomalías, dada la especi�cación manual de las diferentes relaciones entre los múltiples paráme-

tros que constituyen las colecciones de modelos. Esta técnica debe considerarse solamente como

un complemento a dichos sistemas, como se explica en la obra de Pearl [187].

2.2.2. Detección de Anomalías

La Detección de Anomalías hace referencia al método de Detección de Intrusiones que aboga

por comparar el conocimiento relativo al comportamiento habitual del sistema que se desea

proteger con la actividad cotidiana del mismo. De esta forma, la operatoria del sistema de

detección se basa en la elaboración y mantenimiento de un per�l de actividad normal, compuesto

por un conjunto de parámetros o métricas de detección, y en el posterior contraste de dicho

per�l con las acciones que se estén llevando a cabo en un momento dado. Toda acción que se

desvíe signi�cativamente del per�l habitual será inmediatamente catalogada como subversiva y

provocará las acciones de respuesta correspondientes.

De esta manera, dado que la principal fuente de conocimiento del sistema de detección es

la realidad cotidiana del sistema a proteger, y no el conocimiento experto proveniente del ad-

ministrador humano, es posible responder ante situaciones para las cuales no existe un modelo

de ataque conocido y documentado dentro de la base de conocimiento, con lo que se consigue

superar ampliamente las limitaciones características de los sistemas de detección basados en De-

tección de Usos Indebidos. No se utiliza la política de lista negra inherente a estos sistemas, sino

que se opta por una política de lista blanca construida a partir de la observación minuciosa del

sistema objetivo; de forma que es posible responder ante los Zero-Day Attacks mencionados en

apartados anteriores, no en base a lo que se conoce como malicioso, sino a partir de lo que se sabe

que es legítimo, o normal26. En general, estas características propias de los sistemas de detec-

ción basados en Detección de Anomalías hacen que dichos sistemas sean cali�cados de completos

[100], si bien adolecen de cierta falta de precisión que da origen habitualmente a mayores tasas

26Este modo de operación corresponde al modelo general de funcionamiento, si bien existen algunas propuestasque abogan por la utilización de conocimiento experto positivo para especi�car cómo debe ser el comportamientodel sistema [213].

87

Figura 2.29: Modelo general de Detección de Anomalías

de falsos positivos.

De esta forma, con el objetivo de proporcionar una visión general sobre el funcionamiento

interno de este tipo de sistemas de detección, que permita extraer las conclusiones necesarias

para identi�car las problemáticas existentes y enunciar los grandes retos que aún presenta esta

tecnología, se describen a continuación los principios básicos de funcionamiento sobre los cuales

está construida la inmensa mayoría de ellos.

Modelos estadísticos

Dorothy Denning describió en su histórico artículo An Intrusion Detection Model[105] cinco

modelos estadísticos en base a los cuales es posible categorizar los diferentes parámetros o métri-

cas de detección que alimentan actualmente a la práctica totalidad de Sistemas de Detección de

Intrusiones basados en Detección de Anomalías. En concreto, el objetivo fundamental del estudio

desarrollado por Denning consistía en, dado un parámetro x y una secuencia de n observaciones

x1, ..., xn, determinar si una nueva observación xn+1es normal respecto del conjunto de obser-

vaciones previas o si, por el contrario, se desvía de forma signi�cativa de las mismas. Para ello,

Denning propone los modelos estadísticos que se describen a continuación, algunos de los cuales

fueron posteriormente incorporados dentro del proyecto IDES [237, 396].

Modelo Operacional

88

Este modelo está basado en la hipótesis de que la normalidad de los parámetros que componen

un determinado evento puede decidirse mediante la comparación de los mismos con un conjunto

de valores límite que se establecen manualmente en base al histórico de evidencias. De esta forma,

aunque las observaciones anteriores no se usan directamente en la decisión, sirven para establecer

esos límites particulares de las diferentes métricas de detección. A este respecto, el ejemplo de

modelo operacional por antonomasia es el de un contador de intentos de login por unidad de

tiempo, a partir del cual una observación por encima del límite habitual sugiere la existencia de

un intento intrusión.

Modelo basado en media y desviación típica

Este modelo pretende generalizar el modelo operacional, aportando una mayor capacidad re-

presentativa que se consigue a partir de los conceptos estadísticos clásicos de media, varianza y

desviación típica [155]. Para ello, el presente modelo se basa en la hipótesis de que los valores

más representativos del conjunto de las n observaciones pasadas son precisamente la media y la

desviación típica, las cuales se calculan mediante las expresiones siguientes:

(2 : 4) Sumatorio = x1 + ...+ xn

(2 : 5) Sumatorio de cuadrados = x21 + ...+ x2

n

(2 : 6) Media =Sumatorio

n

(2 : 7) V arianza =Sumatorio de cuadrados

(n− 1)−Media2

(2 : 8) Desviacion tipica =√V arianza

De esta forma, una nueva observación es catalogada como anómala si cae fuera de un intervalo

de con�anza centrado en el valor de la media y con un margen de�nido por el administrador

como una fracción k de la desviación típica. La expresión de�ne formalmente los límites de dicho

intervalo:

(2 : 9) Media± k∆Desviacion tipica

Este modelo puede utilizarse sobre distintos tipos de parámetros, como pueden ser contadores

de eventos, temporizadores, y demás métricas acumulables. Además, presenta dos grandes ven-

tajas con respecto al modelo anterior, ya que, por un lado, no necesita conocimiento acumulado

sobre la actividad del sistema para de�nir los diferentes límites. Por el contrario, el propio modelo

es capaz de aprender por sí mismo qué valores constituyen la actividad normal del sistema, y

89

en qué intervalos de con�anza debe ubicarse el comportamiento de los usuarios. Además, por

otro lado, como los intervalos de con�anza pueden construirse de forma especí�ca para cada uno

de los usuarios, el modelo soporta aquellas circunstancias en las que lo que es normal para un

determinado usuario sea anómalo para otro. Por último, con el objetivo de minimizar las posibi-

lidades de sufrir Session Creeping, es posible plantear una variante de este modelo que penalice

progresivamente las observaciones más antiguas, en bene�cio de las más recientes.

Modelo Multivariable

Este modelo pretende generalizar el modelo basado en media y desviación típica, analizando las

potenciales correlaciones existentes entre dos o más métricas. Esta �losofía está basada en la

hipótesis de que es posible obtener una mayor capacidad de discriminación a partir de combi-

naciones de múltiples parámetros de detección, que a partir de métricas individuales. De esta

forma, por ejemplo, la decisión de clasi�car el comportamiento de un determinado usuario, se

realizaría en base al análisis conjunto de una colección de métricas como pueden ser tiempo de

procesador consumido, número de procesos en ejecución, número de operaciones de entrada-salida

solicitadas, frecuencia de acceso al sistema, duración de la sesión de usuario, etcétera, etcétera.

A este respecto, es interesante señalar el hecho de que uno de los mecanismos matemáticos de

análisis multivariable más poderosos son precisamente las Redes Bayesianas [187], mencionadas

anteriormente, y en base a las cuales se ha desarrollado el presente trabajo de investigación.

Modelo basado en Cadenas de Markov

Este modelo pretende complementar a los modelos anteriores, introduciendo el concepto de estado

en el proceso de análisis. Los distintos tipos de análisis descritos hasta el momento toman sus

decisiones sin tener en consideración las múltiples circunstancias por las que ha podido pasar el

sistema que se pretende proteger, por lo que su capacidad de representación se encuentra limitada.

Por el contrario, en este caso, se propone la utilización de un mecanismo matemático orientado

precisamente a resolver este problema de falta de memoria, y que es conocido habitualmente

como Cadena de Markov.

Para ello, este modelo considera no sólo el evento que acaba de producirse en este instante en

el sistema, sino también el que se produjo en el instante anterior. De esta forma, internamente,

se construye una matriz de estado que caracteriza las frecuencias de transición entre los múlti-

ples estados por los que puede pasar el sistema a lo largo de su ciclo de vida (en lugar de las

frecuencias individuales de cada estado, como es característico de los casos anteriores). Así pues,

una determinada observación es categorizada como anómala si su probabilidad de ocurrencia,

dado el estado anterior, es demasiado baja.

Por otro lado, es interesante señalar la posibilidad de que este tipo de análisis puede gene-

ralizarse aún más, con el objetivo de tomar en consideración no ya el estado inmediatamente

anterior, sino un conjunto de n estados anteriores, mediante la utilización de Cadenas de Markov

Generalizadas [90].

90

Por último, es importante prestar especial atención al hecho de que este tipo de análisis,

que constituye un subconjunto semántico de las anteriormente mencionadas Redes Bayesianas

[73, 206, 57, 115, 63, 291], también se incorpora, de forma implícita, a la solución propuesta en

el presente estudio.

Modelo Temporal

Este último modelo pretende complementar las propuestas anteriores, analizando, además del

orden en que se producen los eventos en el sistema (tal y como es característico del caso anterior),

la longitud de los intervalos de tiempo existentes entre dichos eventos. Básicamente, se reduce

a la aplicación del modelo basado en media y desviación típica a una métrica especial que no

es más que el intervalo de tiempo transcurrido entre un determinado evento y el anterior. De

esta manera, una determinada observación será clasi�cada como anómala si su probabilidad de

ocurrir en ese preciso instante es demasiado baja. Este tipo de análisis presenta la ventaja de ser

capaz de estimar tendencias de comportamiento a lo largo del tiempo, lo que le permite detectar

cambios graduales en dicho comportamiento y adaptarse a la nueva realidad del sistema que se

pretende proteger. También esta cuestión es tomada en consideración en el presente trabajo de

investigación, con lo que el exhaustivo modelo estadístico de Denning es abordado en toda su

extensión.

Detección de Umbral

La detección de umbral constituye la forma más simple de Detección de Anomalías. Por

lo general, el principio básico de funcionamiento consiste en analizar, dentro de un intervalo

de tiempo, una determinada métrica de detección, como puede ser, por ejemplo, el número de

intentos de conexión fallidos por unidad de tiempo. Si una vez realizada la observación, dicha

métrica excede un determinado umbral, establecido previamente, se considera dicha observación

como anómala y se dispara la acción de respuesta correspondiente [297]. Un Sistema de Detección

de Intrusiones que goza de gran popularidad y que utiliza esta técnica es Tripwire [174, 357, 389].

Este tipo de detección se corresponde fundamentalmente con el modelo operacional propuesto

por Denning.

Detección basada en Per�les

La detección basada en per�les pretende generalizar el método anterior de detección de um-

bral, de forma que en lugar de considerarse una única métrica de detección, son analizados per�les

compuestos por múltiples parámetros que sirven para obtener una representación más precisa de

la actividad que se lleva a cabo en el sistema. La siguiente tabla incluye algunas de las métricas

utilizadas por el sistema IDES [396, 237].

91

Cuadro 2.3: Métricas utilizadas en el sistema IDES de Detección de Intrusiones basada en per�les

De esta forma, la combinación de este conjunto de métricas para un determinado usuario,

constituye en cada momento un per�l actual de comportamiento, que es comparado periódica-

mente con un per�l almacenado que contiene los múltiples valores umbrales de dicho conjunto

de métricas. Si se produce una situación en la que el per�l actual se desvía signi�cativamente del

almacenado, se considera dicho per�l actual como anómalo y se genera la respuesta pertinente

[297]. En algunos sistemas de detección, además, el mencionado per�l almacenado se actualiza

regularmente con los datos contenidos en el per�l actual, con lo que se consigue la adaptación

automática a potenciales cambios en el comportamiento de los usuarios [304]. Esta modalidad de

detección se corresponde fundamentalmente con el modelo operacional propuesto por Denning, si

bien, en función del tipo de comparación que se implemente internamente, puede presentar ade-

más ciertas peculiaridades propias del modelo basado en media y desviación típica, del modelo

multivariable, y del modelo temporal.

Métricas Estadísticas

En la línea del modelo operacional, del modelo basado en media y desviación típica, del

modelo multivariable y del modelo temporal propuestos por Denning, la detección basada en

métricas estadísticas aboga por el análisis conjunto de los distintos parámetros de detección en

base a una expresión heurística compuesta que combine las distintas componentes de anomalía

posibles. Sobre este principio básico de funcionamiento está basado, por ejemplo, el sistema de

detección NIDES [19], en el cual se utilizan además los conceptos anteriormente mencionados de

per�l actual y per�l almacenado. En concreto, el per�l almacenado que se utiliza está compuesto,

en general, por un conjunto de i métricas s1...si , mientras que el per�l actual está compuesto

por i observaciones c1...ci. Por otro lado, los valores de anormalidad o anomalía ai se obtienen

como la diferencia en valor absoluto entre ambos per�les, de forma que se obtiene un conjunto

de valores a1...ai, para los que ai=|si - ci|. Además, no es habitual que todas las métricas tengan

la misma relevancia, de forma que es necesario añadir un peso especí�co wi a cada métrica. Por

92

último, tampoco es habitual que todos los valores de anomalía tengan la misma repercusión en la

decisión �nal. Las anomalías importantes deben tener una mayor relevancia que otras anomalías

menores, por lo que es necesario considerar dichos valores al cuadrado, por lo menos [297, 304].

Todas estas consideraciones sirven para construir la expresión 2.10, la cual constituye el núcleo

fundamental del mencionado proyecto NIDES.

(2 : 10) Anomalia = w1a21 + w2a

22 + ...+ wia

2i ,∀i > 0

De esta forma, cualquier evento que produzca un valor de anomalía por encima de un determi-

nado umbral, establecido de antemano, será considerado como anómalo y suscitará la respuesta

correspondiente por parte del sistema de detección. En general, este tipo de sistemas de detec-

ción (al igual que el caso anterior, de detección basada en per�les) permite advertir utilizaciones

anómalas de los recursos computacionales del sistema que se desea proteger de forma e�caz, si

bien presenta ciertos inconvenientes de importancia, como pueden ser su incapacidad para repre-

sentar información temporal (al igual que el caso de la Detección de Usos Indebidos basada en

sistemas expertos), la posibilidad de sufrir ataques de Session Creeping, y su falta de precisión

en entornos en los que el comportamiento de los usuarios es ligeramente errático o voluble[93].

Sistemas basados en Reglas

La Detección de Anomalías basada en sistemas de reglas pretende aportar una mayor capaci-

dad semántica a los modelos anteriores. Mientras los sistemas de detección basados en métricas

estadísticas resuelven el problema de la comparación de per�les mediante formulación mate-

mática, sus homólogos basados en sistemas de reglas proponen, como se describe en apartados

anteriores, la utilización de un motor de inferencia responsable de interpretar baterías de reglas

que formalizan conocimiento experto. De esta forma, dado que los mencionados sistemas basados

en reglas presentan un mayor poder expresivo [297], se pretende mediante su utilización la reso-

lución de algunos de los problemas inherentes a dichos modelos anteriores, como son el modelado

explícito de información temporal, y la adaptación del sistema de detección al comportamiento

anárquico de algunas tipologías de usuarios.

Un sistema de Detección de Anomalías basado en sistemas de reglas es ADS27 [380]. Dicho

sistema de detección está orientado a la máquina y es capaz de analizar información del Sistema

Operativo proveniente de los niveles de servicio, o de llamada al sistema, y de interpretación de

comandos. Para ello, es necesario especi�car conjuntos de reglas que representan el comporta-

miento de cada uno de los usuarios del sistema, incluyendo métricas como el tipo de llamadas al

sistema permitidas, número de solicitudes de servicio realizadas, etcétera, etcétera. Una vez ela-

borado ese per�l de comportamiento, durante la explotación del sistema de detección, cualquier

actividad que sobrepase los límites establecidos en el mismo será considerada como anómala por

el motor de inferencia, y se ejecutarán las acciones de respuesta correspondientes.27ADS: Anomaly Detection System.

93

Figura 2.30: Batería de reglas de TIM

En general, esta técnica está basada en la hipótesis de que las secuencias de eventos no se

producen aleatoriamente, sino que por el contrario siguen patrones regulares e identi�cables28.

Por ello, un objetivo fundamental que se aborda es el del análisis de anomalías en la ordenación de

eventos, lo que hace que la Detección de Intrusiones adquiera una mayor calidad. Otros ejemplos

de sistemas de detección que utilizan esta técnica son Wisdom and Sense29 [395] y TIM30 [353].

La �gura superior ilustra de forma conceptual el funcionamiento de una batería de reglas de

TIM, inferida a partir de la observación de una secuencia de eventos registrada en el sistema

a proteger. A pesar de lo particular de su enfoque, su mecanismo de inferencia es muy similar

a las anteriormente mencionadas Cadenas de Markov, por lo se ajusta extraordinariamente al

modelo de detección basado en Cadenas de Markov propuesto por Denning. Por su parte, la

�gura siguiente ilustra un caso de ejemplo de estructura de reglas de decisión de Wisdom and

Sense, de similar capacidad representativa.

Redes Neuronales

Dado que el objetivo fundamental de todo Sistema de Detección de Intrusiones basado en

Detección de Anomalías consiste en deducir, a partir de un conjunto de x1...xnobservaciones,

el grado de normalidad del evento xn + 1[105], la aplicación del mecanismo matemático de

aprendizaje e inferencia conocido como Red Neuronal [MacKay02] se revela como una opción

natural, con prometedoras posibilidades [386, 275]. En concreto, el objetivo fundamental que

se persigue con este enfoque es el de representar todo el conocimiento relativo a los per�les de

comportamiento de los usuarios de una forma implícita al mecanismo de inferencia, y no mediante

los habituales esquemas explícitos inherentes a las aproximaciones basadas en per�les, métricas

estadísticas o sistemas expertos. De esta forma, se enriquece, potencialmente, el conocimiento

28Esta técnica también es conocida habitualmente como Generación de patrones predictivos o Predictive PatternGeneration [304].

29Wisdom and Sense: Sabiduría y Sensibilidad.30TIM: Time-based Inductive Machine.

94

Figura 2.31: Árbol de reglas de Wisdom and Sense

relativo a las múltiples relaciones existentes entre los diferentes parámetros de detección, con lo

que la calidad de las decisiones inferidas es teóricamente superior [297, 304].

Para ello, se organiza un esquema de funcionamiento compuesto por dos fases: aprendizaje,

o entrenamiento, y explotación. De esta manera, en primer lugar se entrena la red neuronal

con un histórico de la actividad de que se ha registrado en el pasado, el cual, además de las

métricas propias del per�l de comportamiento, debe incluir un parámetro de detección adicional

que representa la clasi�cación de dicha actividad. Dicho parámetro de clasi�cación representa

el hecho de si la actividad analizada ha supuesto un ataque (y en caso a�rmativo, el tipo de

ataque) o no contra la seguridad del sistema, de forma que su �nalidad última no es otra que la

de etiquetar el conocimiento disponible para así proporcionar a la posterior fase de explotación

conciencia sobre el hecho clasi�catorio.

Posteriormente, una vez que la red neuronal ha sido entrenada convenientemente, tanto el

conjunto de los múltiples per�les de comportamiento, como sus métricas componentes, quedan

representados implícitamente y de forma uni�cada en las múltiples conexiones neuronales que

componen la citada red. De esta manera, la red en cuestión puede ser �nalmente utilizada para

obtener conclusiones acerca del tipo de categorización que debe aplicarse a las nuevas observacio-

nes que se registren en el sistema. Si los parámetros de detección que componen un determinado

evento mantienen cierta similitud con los recogidos por la red neuronal, dicho evento será con-

siderado anómalo y el sistema de detección responderá en consecuencia. De esta forma, estos

sistemas de detección presentan poderosas posibilidades: son capaces de adaptarse por sí mismos

95

Figura 2.32: Aplicación de redes neuronales a Detección de Intrusiones

a sistemas computacionales cuya realidad evoluciona a lo largo del tiempo, mantienen una alta

estabilidad del conocimiento asimilado (incluso en situaciones sujetas a la in�uencia de compo-

nentes de ruido), son capaces de inferir conclusiones de alto nivel de abstracción, sin necesidad

de hipótesis estadísticas previas, y además son muy e�cientes, una vez puestos en explotación.

Sin embargo, la utilización de redes neuronales introduce un serio inconveniente en lo re-

lativo a la inferencia de relaciones de tipo causa-efecto, ya que dentro de su naturaleza existe

una absoluta incapacidad de explicación de las conclusiones que ofrecen. La suma de sus múl-

tiples conexiones, una vez entrenadas adecuadamente, proporciona unos resultados precisos y

de con�anza, pero es imposible determinar cuáles son las causas exactas que producen dichos

resultados[57]. Por otro lado, la mencionada fase de aprendizaje requiere por lo general unos

costosos esfuerzos administrativos de supervisión, que hacen que, por lo general, este tipo de

sistemas de detección vea reducida su aplicación a condiciones de laboratorio. Algunos casos de

Sistemas de Detección de Intrusiones desarrollados en base a redes neuronales son los prototipos

correspondientes a los estudios realizados por Ángel Grediaga31 et al. [149], Anup Gosh32 et al.

[148], James Cannady y Jim Maha�ey [54], David Endler , y Jake Ryan y Meng-Jang Lin [382].

A pesar de tratarse de un enfoque especialmente particular, puede clasi�carse de una forma in-

tuitiva dentro del modelo multivariable de Denning. La �gura anterior ilustra un caso de red

neuronal utilizada para predicción de comandos en sistemas Unix [Fox+90].

31En las investigaciones realizadas por Grediaga et al. y Cannady y Maha�ey se utiliza un tipo especial de redneuronal denominado Mapa Auto-Organizativo [338], que presenta la característica de que su fase de entrenamientopuede realizarse de forma no supervisada. Ésta es una propiedad fundamental para conseguir unos requisitosadministrativos mínimos, que permitan una adopción natural del Sistema de Detección de Intrusiones resultantepor parte de empresas y organizaciones.

32En las investigaciones realizadas por Gosh et al. se utiliza un tipo especial de red neuronal denominadoRed de Elman [122], que presenta la característica de que ser capaz de representar implícitamente la magnitudtemporal. Ésta es una propiedad fundamental para poder construir un modelo de representación y unos motoresde aprendizaje e inferencia que tomen en consideración de forma intrínseca el hecho cronológico.

96

Figura 2.33: Firma ISL de NFR

Lenguajes de Especi�cicación de Intenciones

Un método que aboga por la especi�cación apriorística del comportamiento de los usuarios

del sistema, es la utilización de lenguajes interpretados a través de los cuales especi�car dicho

comportamiento33. De esta forma, es posible la veri�cación en tiempo real del grado de desvia-

ción que está sufriendo el comportamiento actual de un determinado usuario, con respecto a su

comportamiento ideal, especi�cado mediante uno de dichos lenguajes. Éste es un método que,

además de permitir la especi�cación de comportamiento legítimo, también puede utilizarse para

representar conocimiento experto sobre comportamientos maliciosos de los que el administrador

humano tenga constancia, debido al alto grado de capacidad expresiva que presenta.

Algunos casos de éxito de Sistemas de Detección de Intrusiones que utilizan esta técnica son

IDML34 [230], NFR o Stalker[307]. En todos ellos, se utilizan lenguajes de especi�cación expresa-

mente desarrollados para cada caso, si bien también existen soluciones de detección que utilizan

lenguajes de propósito general de construcción de sistemas expertos, aplicados a la especi�cación

de escenarios de Detección de Intrusiones, como pueden ser P-BEST35 o CLIPS36[299]. Las �gu-

ras siguientes ilustran dos casos de representación de conocimiento de Detección de Intrusiones

propios de NFR y P-BEST/EMERALD, respectivamente.

Por último, también es interesante prestar atención, respecto a la utilización de lenguajes de

especi�cación de intenciones, a los ambiciosos estudios realizados por Jon Doyle et al.[112] en el

Instituto Tecnológico de Massachusetts [251]. La �gura 2.38 muestra un ejemplo de especi�ca-

ción de escenario de intrusión en un servidor de transferencia de �cheros escrito en el lenguaje

propuesto en dicho trabajo de investigación.

Clasi�cación Bayesiana

Los métodos de clasi�cación Bayesiana [187] están basados en los conceptos clásicos de Teoría

de la Probabilidad de probabilidad conjunta [155] y probabilidad condicional, y se caracterizan

fundamentalmente por conseguir la clasi�cación no supervisada de objetos. Esta propiedad de

la no supervisión permite que estos métodos de análisis presenten unos requisitos administrati-

vos mínimos y que los hacen especialmente atractivos, ya que elimina la necesidad de que sus

33Conocidos como lenguajes de especi�cación de intenciones o Intent Speci�cation Languajes o ISL [297].34IDML: Intrusion Detection Markup Languaje.35Utilizado dentro del proyecto EMERALD, entre otros.36Utilizado dentro de los proyectos CLIPSNIDS y DIDS, entre otros.

97

Figura 2.34: Batería de reglas ISL de P-BEST/EMERALD

Figura 2.35: Firma ISL del MIT

98

inherentes procesos de aprendizaje deban ser administrados por el operador humano, como es

menester, por ejemplo, en los casos de los métodos de detección de umbral, o en los basados en

per�les, en métricas estadísticas, en sistemas de reglas, o en redes neuronales [304].

Figura 2.36: Red Bayesiana trivial de modelado de actividad intrusiva

De este modo se consigue una adaptación natural e instantánea a la evolución a lo largo del

tiempo de los sistemas que se pretende proteger, ya que es posible mantener, en paralelo con

los procesos de inferencia y decisión, perennes procesos de aprendizaje automático. Además, un

sistema de clasi�cación Bayesiano permite la identi�cación automática del número de categorías

de clasi�cación, dado el conjunto de datos a clasi�car126, permite operar en base a datos incom-

pletos, permite el análisis uni�cado de parámetros, sin los habituales criterios y restricciones de

excepción presentes en la mayoría de sistemas de detección, e incluso soporta el análisis homogé-

neo de parámetros discretos y continuos; parámetros que, además, pueden ser tanto cuantitativos

como temporales [376].

Sin embargo, a pesar de sus enormes posibilidades, también presenta ligeros inconvenientes.

Por un lado, estos métodos aún presentan cierta di�cultad para de�nir los umbrales de detección

más adecuados; tarea que sigue siendo responsabilidad del administrador de seguridad. Por otro

lado, como es característico de cualquier sistema de adaptación automática al sistema objetivo,

presentan la teórica posibilidad de sufrir ataques de Session Creeping [57]. Algunas propuestas

de Sistemas de Detección de Intrusiones que utilizan métodos de clasi�cación Bayesianos son

los proyectos SPAMBayes [399], ADAM37 [32] y eBayes38 [Valdés+01], así como los estudios

realizados por Steven Scott [305] , Nasser Abouzakhar et al. [13], Christopher Krügel et al. [215],

Burroughs et al. [47], y Nong Ye y Mingming Xu [244]. La �gura anterior ilustra un sistema de

clasi�cación bayesiano utilizado para Detección de Intrusiones orientada a la máquina [304].

Algoritmos Genéticos

Los denominados Algoritmos Genéticos [82] constituyen una técnica de búsqueda y optimi-

zación, perteneciente al área de conocimiento de los denominados Algoritmos Evolutivos [121],

37ADAM: Audit Data Analysis and Mining.38Proyecto desarrollado por SRI International, como elemento componente del proyecto EMERALD.

99

Figura 2.37: Algoritmo Genético general, en pseudocódigo

que también ha sido propuesta dentro del área de conocimiento de la Detección de Anomalías,

en concreto como componente fundamental del motor de análisis del proyecto GASSATA39 [219],

desarrollado por Ludovic Mé. En general, este tipo de métodos están basados en la mecánica

de la Genética y de la Selección Natural [303]. De esta forma, el proceso de búsqueda u optimi-

zación se organiza en base a los principios genéticos clásicos de herencia, mutación, selección y

recombinación, para a partir de cromosomas, formados por vectores de parámetros de detección,

dar origen a un conjunto de generaciones sucesivas cuyos últimos miembros se ajusten perfecta-

mente al problema propuesto. Al �nalizar dicho proceso evolutivo, sólo habrán sobrevivido los

más fuertes.

De este modo, los resultados obtenidos por Mé fueron realmente prometedores, presentando

una tasa de acierto del 0,996 y una tasa de falsos positivos del 0,0044. Además, el tiempo necesario

para obtener dicha solución fue mínimo, por lo que la sobrecarga introducida en el sistema se

mantuvo en unos niveles realmente bajos. Otros estudios interesantes desarrollados en esta línea

pueden ser los llevados a cabo por Dong Kim et al. [211], por Wei Li[368], por el grupo de

investigación de Jan Elo� [280], por Susan Bridges y Rayford Vaughn [40], por Sinclair et al.

[320], y por Mark Crosbie y Gene Spa�ord [76].

Lógica Difusa

La denominada Lógica Difusa40[75] es una extensión de la Lógica de Boole [361] que se

caracteriza por ser capaz de representar el concepto de certidumbre, o grado de veracidad, apro-

ximándose de esa forma al concepto idóneo de Probabilidad [57, 115]. De este modo, mientras

la lógica clásica utiliza únicamente los conceptos absolutos de verdadero o falso, la lógica di-

fusa utiliza múltiples niveles o grados de veracidad, proporcionando de esa manera una mayor

aproximación al razonamiento humano. Por ejemplo, un Sistema de Detección de Intrusiones

basado en lógica difusa puede representar el concepto muy peligroso. Por ello, es posible que un

determinado evento sea clasi�cado como perteneciente (con diferentes grados de pertenencia) a

más de una clase simultáneamente. La �gura siguiente ilustra de forma conceptual la diferencia

entre ambos enfoques utilizando para ello una única métrica de detección como es el número de

puertos TCP-IP accedidos por unidad de tiempo [41].

39GASSATA: A Genetic Algorithm as an Alternative Tool for Security Audit Trails Analysis.40Lógica Difusa o Fuzzy Logic.

100

Figura 2.38: Clasi�caciones convencional y difusa de un parámetro de detección

Por otro lado, es interesante tomar el consideración el hecho de que esta tecnología es suscep-

tible de ser utilizada por sí sola, como elemento fundamental del proceso de Análisis, o bien de

usarse como complemento a otras técnicas de detección, como es el caso del proyecto IIDS41, desa-

rrollado en la Universidad de Mississippi por [41, 40]. Otras Susan Bridges y Rayford Vaughn42

investigaciones desarrolladas al respecto son las llevadas a cabo por John Dickerson et al. en

el proyecto FIRE43[106, 107], así como los estudios realizados por Chavan et al. [64], Jonatan

Gómez y Dipankar Dasgupta[377], y Jianxiong Luo [183].

Máquinas de Vector Soporte

Las denominadas Máquinas de Vector Soporte44 [365] constituyen un método no lineal basado

en optimización cuadrática [150, 394] de aprendizaje supervisado dirigido a la resolución de

problemas de clasi�cación y regresión. Por lo tanto, el objetivo principal de dichos métodos ante

el problema de la Detección de Intrusiones se reduce a clasi�car la actividad de los usuarios, en

principio en las dos grandes categorías canónicas: Maldad y Bondad. Este modo de operación

es similar a los que caracterizan a otros enfoques, como pueden ser las redes neuronales o los

clasi�cadores bayesianos, de forma que su aportación conceptual es limitada. Por otro lado, la

propia de�nición del término incluye una premisa, como es el hecho del aprendizaje supervisado,

que en general supone un importante obstáculo para la e�ciente utilización de un hipotético

Sistema de Detección de Intrusiones que resultara de la aplicación de las referidas máquinas de

vector soporte.

Otros métodos, como pueden ser las Redes Bayesianas, permiten operar de forma e�caz

sin dicha supervisión del entrenamiento [57, 115], de forma que los costes de administración

correspondientes se mantengan dentro de unos límites de adecuada e�ciencia económica. Algunas

41IIDS: Intelligent Intrusion Detection System.42En el desarrollo de este proyecto, Bridges y Vaughn utilizaron Lógica Difusa combinada con Algoritmos

Genéticos.43FIRE: Fuzzy Intrusion Recognition Engine.44Máquinas de Vector Soporte o Support Vector Machines [SVM].

101

Figura 2.39: Clasi�cación de eventos basada en máquina de vector soporte

investigaciones en las que se han aplicado los principios fundamentales de dichas máquinas de

vector soporte son las llevadas a cabo por Crina Groçan et al. [150], por Srinivas Mukkamala y

Andrew Sung [394, 256], por Zonghua Zhang y Hong Shen [156], por Heller et al. [162], y por Hu

et al. [167]. La �gura ilustra de forma conceptual el mecanismo de clasi�cación característico de

las máquinas de vector soporte [167].

Data Mining

El denominado Data Mining45 [349, 158], también conocido como Knowledge Discovery in

Databases46, es una técnica de búsqueda automática de patrones o pautas regulares de conoci-

miento en ingentes volúmenes de información, para la cual se utilizan fundamentalmente técnicas

estadísticas y de reconocimiento de patrones. De este modo, la esencia última de dicha aproxi-

mación no di�ere sustancialmente de otras alternativas propuestas anteriormente, salvo por su

orientación no supervisada y por los grandes requerimientos de e�ciencia que presenta. De esta

forma, se pretende dar un paso adelante en la tecnología estadística clásica mediante la automa-

tización del proceso de extracción de conocimiento.

Por otro lado, aunque los problemas especí�cos a los que puede enfrentarse el Data Mining

son múltiples, son tres los que predominan habitualmente, ya que proporcionan un conocimiento

de mayor calidad: Clasi�cación, Análisis Multivariable de Relaciones y Análisis de Secuencia

[229]. A continuación se describen someramente las mencionadas problemáticas:

Clasi�cación

El objetivo fundamental del problema de clasi�cación consiste en asignar una categoría a cada

uno de los hechos de la base de datos. Por otro lado, puede darse la circunstancia de que el

conjunto de categorías esté de�nido de antemano, o que deba ser inferido a partir de los datos.

45Data Mining o Minería de Datos.46Knowledge Discovery in Databases (KDD) o Descubrimiento de Conocimiento en Bases de Datos.

102

A este respecto, las Redes Bayesianas en general, y las Redes Bayesianas de tipo Naïve en

particular, constituyen el paradigma por excelencia de clasi�cación automática a partir de los

datos [57, 115].

Análisis Multivariable de Relaciones

En este caso el problema consiste en identi�car las relaciones de correlación y causalidad exis-

tentes entre las múltiples variables que componen cada uno de los hechos de la base de datos,

mediante la aplicación de tests estadísticos de independencia e independencia condicional. Al

igual que en el caso anterior, las Redes Bayesianas suponen un método excepcional para la reso-

lución de dicho problema [57, 115]. Por otro lado, es interesante prestar atención a la absoluta

correspondencia existente entre este aspecto del Data Mining y el modelo multivariable propuesto

por Denning.

Análisis de Secuencia

En esta ocasión el problema consiste en identi�car las relaciones de correlación y causalidad exis-

tentes entre los múltiples estados por los que pueden pasar las secuencias de eventos que tienen

origen en un determinado sistema de información. En este caso, los denominados Modelos de

Markov constituyen una excelente aproximación, si bien están superados por las anteriormente

mencionadas Redes Bayesianas, las cuales, aunque presentan unos mayores requisitos compu-

tacionales, proporcionan una mayor capacidad de representación [57, 115], imprescindible para

la resolución de problemas complejos. Al igual que el caso anterior, es interesante prestar aten-

ción a la absoluta correspondencia existente entre esta cuestión y el modelo basado en Cadenas

de Markov propuesto por Denning.

Son abundantes las investigaciones realizadas en el campo de la Detección de Intrusiones que

aplican técnicas de Data Mining. Algunas de las más representativas son las llevadas a cabo

por Guy Helmer et al. [163], por el equipo de investigación de la Universidad de Minnesota

[227, 110], por Wenke Lee y Salvatore Stolfo47 [228, 229, 393], de la Universidad de Columbia, y

por Christina Warrender et al. [374].

Selección de parámetros de detección

Al vasto abanico de posibilidades de análisis descrito en los apartados anteriores es necesario

añadir la cuestión fundamental de la formalización de la información que entra a dicho proceso

de análisis, en la línea del modelo conceptual propuesto por Emilie Lundin [116]. De esta forma,

una cuestión tan importante como la selección del modelo de análisis es la selección de aquellas

métricas o parámetros de detección a partir de los cuales debe desarrollarse éste, de modo que

la diferenciación entre la actividad anómala y la actividad legítima que se registre en el sistema

47Lee y Stolfo utilizan un enfoque de inducción de reglas a partir de los datos muy similar al utilizado en elproyecto TIM.

103

a proteger pueda llevarse a cabo de manera e�ciente. Para ello, es necesario seleccionar, de entre

la amplia colección de métricas que pueden estar a disposición del sistema de detección (en las

múltiples y variadas circunstancias propias de cada tipo de sistema), aquel subconjunto de ellas

que resuelva de forma precisa y e�ciente el problema.

Esta cuestión se denomina habitualmente Selección de parámetros de detección, y adquiere

una complejidad adicional debido a que, por lo general, distintos tipos de ataque requieren

la utilización de distintos tipos de métrica. Por ello, un determinado subconjunto limitado de

parámetros no suele ser adecuado para representar cualquier tipo de ataque, y además, por otro

lado, un conjunto excesivamente elevado de parámetros no consigue, en general, buenos niveles

de rendimiento. De esta forma, la solución pasa por alcanzar el equilibrio entre una adecuada

capacidad representativa y una e�ciencia satisfactoria, mediante la selección dinámica de dichos

parámetros de detección [304].

A este respecto, Heady et al. [160] proponen en su trabajo de investigación una aproximación

de Sistema de Detección de Intrusiones basada en Algoritmos Genéticos que permite explorar

todo el espacio de métricas posibles, con el objetivo de seleccionar un subconjunto ideal. En ella

se busca, a partir de un conjunto inicial de parámetros de detección y mediante las operaciones

genéticas anteriormente mencionadas de herencia, selección, recombinación y mutación, un pro-

ceso de selección natural que obtenga subconjuntos de métricas más fuertes, a partir del grado de

acierto de las predicciones de intrusión que se consiguen en cada una de las generaciones. Aquellas

generaciones que representan mejor el conjunto de ataques de entrenamiento son potenciadas y

resultan seleccionadas a la hora de llevar a cabo nuevas generaciones, en detrimento de aquellas

otras que se encuentran más alejadas del modelo ideal.

Dentro del área de conocimiento de los propuestos Modelos de Redes Probabilísticas, en

general, y en el caso del presente trabajo de investigación, en particular, esta selección se realiza

de forma natural mediante un procedimiento estadístico especialmente interesante, dada su gran

riqueza semántica, denominado Análisis de sensibilidades [57].

Combinación de múltiples métricas

Una vez determinado el conjunto de métricas que mejor es capaz de determinar la presencia

o no de actividad intrusiva en el sistema, es necesario un último esfuerzo de combinación de

todos esos parámetros de detección en una única medida que proporcione unidad al análisis.

Sólo de esta manera es posible obtener una magnitud que represente de forma global y uni�cada

la verdadera dimensión del riesgo que supone cada uno de los eventos que se analizan en el

sistema de detección. Para ello, dos enfoques de combinación muy extendidos son la utilización de

propiedades estadísticas Bayesianas, bien a partir de la aplicación sus principios fundamentales

o bien mediante el uso de los Modelos de Redes Probabilísticas, y la utilización de Matrices

de Covarianzas [304]. Por otro lado, además de la obtención de magnitudes de uni�cación de

métricas, estos principios combinatorios pueden generalizarse de forma que sus bene�cios sean

104

aplicables no ya a múltiples parámetros de detección, sino incluso a múltiples veredictos que

puedan ser generados por diferentes Sistemas de Detección de Intrusiones que cooperen en las

tareas de decisión. En concreto, en el presente trabajo de investigación también se plantea esta

cuestión, la cual se aborda mediante el uso de Redes Bayesianas de tipo Naïve, las cuales están

especí�camente orientadas a la resolución de problemas de clasi�cación [57].

Estadística Bayesiana

Dado un conjunto de métricas A1, A2, ..., Anutilizadas para determinar la legitimidad de la ac-

tividad que se registra en el sistema que se pretende proteger, es posible obtener conclusiones

globales acerca de la realidad de dicho conjunto de métricas, mediante la aplicación de los prin-

cipios probabilísticos clásicos establecidos alrededor del Teorema de Bayes. Para ello, en primer

lugar, es habitual realizar un proceso de discretización de dichos parámetros de detección, que

por lo general implica la existencia de al menos dos estados48: Maldad (o anormalidad) y Bondad.

Por otro lado, también es habitual el planteamiento de la hipótesis de que el sistema objetivo

es susceptible de sufrir intentos de intrusión, los cuales podrán, posteriormente, resultar exito-

sos o no. Dicha hipótesis de intrusión se representa como I y está sujeta a una distribución

de probabilidad P (I). A continuación, a partir de estas consideraciones, es posible calcular la

con�abilidad y la sensibilidad de cada una de las métricas de detección Aimediante las expre-

siones P (Ai = 1/I) y P (Ai = 1/ ∼ I). De esta forma, la probabilidad condicional de I, dado el

conjunto de parámetros Ai, mediante el citado Teorema de Bayes, puede representarse mediante

la expresión:

(2 : 11) P (I/A1, A2, ..., An) = P (A1, A2, ..., An/I)∆P (I)

P (A1, A2, ..., An)

Como puede observarse, es necesario calcular la distribución de probabilidad conjunta del

conjunto de métricas, dada la variable I. Para ello, es necesario tener en especial consideración el

hecho de que el número de probabilidades requerido para representar dicha distribución de pro-

babilidad es exponencial en el número de parámetros [57, 304], lo que puede hacer que el análisis

sea computacionalmente intratable. Por ello, para conseguir que el problema sea abordable en

términos de e�ciencia, es habitual tomar ciertas hipótesis de independencia condicional, que se

traducen en un exponencialmente menor número de probabilidades necesario. En concreto, por

lo general, se considera que cada uno de los parámetros de detección es independiente de los

demás, condicionalmente dada I. Dichas hipótesis se resumen en las siguientes expresiones, las

cuales resultan en la expresión �nal:

(2 : 12) P (A1, A2, ..., An/I) =π∏

i=1

P (Ai/I)

48Por supuesto, en este punto, no es imprescindible que dicha discretización sea binaria, sino que es posibleplantear cualquier tipo de categorización, tanto de los parámetros de detección de entrada, como de los parámetrosde salida obtenidos a partir de éstos.

105

(2 : 13) P (A1, A2, ..., An/ ∼ I) =π∏

i=1

P (Ai/ ∼ I)

(2 : 14)P (I/A1, A2, ..., An)P (∼ I/A1, A2, ..., An)

=P (I)P (∼ I)

∏ni=1 P (Ai/I)∏n

i=1 P (Ai/ ∼ I)

Así pues, de esta forma, es posible calcular la probabilidad de ocurrencia de una intrusión,

dada una observación o evidencia del conjunto de métricas. Por supuesto, las hipótesis de in-

dependencia condicional tomadas pueden no ajustarse completamente a la realidad, por lo que

siempre es necesario contemplar la posibilidad de existencia de relaciones entre los parámetros

de detección, a costa de unos menores rendimientos computacionales.

Matrices de Covarianzas

El proyecto NIDES utiliza un modelo de representación de relaciones estadísticas entre variables

basado en el concepto de Matriz de Covarianza [155]. De esta forma, el conjunto de métricas

A1, A2, ..., Anse representa como un vector A que permite el cálculo de una medida de anomalía

compuesta, en base a la expresión que se indica a continuación, en la que C es la matriz de

covarianzas que representa la dependencia estadística existente entre cada par de variables de

entrada.

(2 : 15) ATC−1A

Dicho modelo de representación es realmente e�ciente, pero adolece de una importante ca-

rencia de capacidad semántica, ya que solamente es capaz de representar relaciones entre parejas

de variables [304]. En ningún caso pueden plantearse conclusiones basadas en múltiples pará-

metros de detección, por lo que la calidad expresiva de este método se encuentra muy limitada,

máxime teniendo en consideración el hecho de que otros enfoques, entre los cuales se encuentran

las anteriormente mencionadas Redes Bayesianas, soportan perfectamente cualquier requisito de

análisis multivariable [57, 115, 187].

2.2.3. Modelo General de Denning

Además de la propuesta de modelo estadístico de Detección de Anomalías, Dorothy Den-

ning [105] también propuso un Modelo General de Detección de Intrusiones, el cual perseguía

el objetivo de integrar los bene�cios y potencialidades de los métodos de Detección de Usos

Indebidos y de Detección de Anomalías. Dicho objetivo abstracto de integración evitaba tomar

en consideración cualquier aspecto de bajo nivel, como pudieran ser el tipo de sistema objetivo,

la formalización de datos de entrada, etcétera, lo que ha contribuido notablemente a que los

principios establecidos en dicho modelo general sigan siendo vigentes en los actuales Sistemas de

Detección de Intrusiones. La �gura siguiente ilustra el mencionado modelo [304].

106

Figura 2.40: Modelo General de Detección de Intrusiones de Denning

Como puede observarse, los distintos eventos concretos se trasforman en una primera fase en

eventos abstractos, independientes de cuestiones como tipo de plataforma, Sistema Operativo,

protocolo de red, etcétera. Posteriormente, estos eventos son utilizados para alimentar tanto a

un primer motor de análisis basado en per�les de comportamiento, denominado Activity Pro�le,

como a un segundo motor de análisis basado en reconocimiento de patrones, denominado Rule

Set. De esta forma, dicho Activity Pro�le, por un lado, utiliza el modelo estadístico de Denning

descrito anteriormente para detectar desviaciones signi�cativas de los per�les de comportamiento,

a la vez que es capaz de construir nuevos per�les ante la aparición de nuevos usuarios o recursos

en el sistema a proteger. Por su parte, el Rule Set se apoya sobre un sistema basado en reglas,

para detectar comportamientos subversivos conocidos. Además, el Activity Pro�le es capaz de

formular en forma de reglas del Rule Set toda aquella actividad que identi�ca como anómala, de

forma que a partir de ese momento, será éste último el encargado de detectar nuevas apariciones

de dicha actividad, con el incremento de e�ciencia que ello conlleva. Por supuesto, ésta es la

propiedad más poderosa del modelo propuesto por Denning, y sobre la cual descansan todos los

esfuerzos de integración de las dos grandes �losofías de detección llevados a cabo en sus trabajos

de investigación.

Por otro lado, aunque el presente estudio, desarrollado en el ámbito del proyecto IDES de SRI

International, revela la importancia de la integración de los dos grandes enfoques de Detección

de Intrusiones y constituye aún actualmente un referente de enorme importancia, alcanza dicha

integración mediante la utilización de una única colección de parámetros de detección que es

compartida por los dos motores de análisis. Los datos son la esencia de la integración, pero

la inferencia que se realiza sobre dichos datos es heterogénea y, por lo tanto, sujeta a grandes

limitaciones de expresividad que restringen la calidad de las conclusiones que se obtienen.

No obstante, a este respecto, es posible encontrar modelos de representación, como las Redes

Bayesianas, que aúnan completamente los principios de funcionamiento de dichos grandes enfo-

ques, consiguiendo un modelo de representación uni�cado y homogéneo por un lado, y un método

107

de obtención de conclusiones que permite tanto el análisis y la toma de decisiones, como el apren-

dizaje de comportamiento, de una forma también uni�cada y homogénea, por otro [57, 115, 187].

Respecto a esta cuestión, es interesante observar la completa adecuación de dichas caracterís-

ticas a la declaración de objetivos general, especí�cos y operacionales del presente trabajo de

investigación.

2.3. Implicaciones Arquitectónicas en el Análisis

Además de las técnicas de análisis expuestas anteriormente, existe una serie de propuestas

relativas al modelo arquitectónico en base al cual se construye un determinado Sistema de Detec-

ción de Intrusiones que introducen ciertas consideraciones importantes en el proceso de análisis.

A continuación se describen las más representativas.

2.3.1. Detección basada en Agentes de Software

Los conceptos de Agente Software, Agente Autónomo y Agente Colaborativo [386], consti-

tuyen un enfoque de diseño que persigue dotar de sensibilidad y autosu�ciencia a los procesos

que implementan la lógica de negocio de cualquier servicio de aplicación tradicional. Además,

también tratan de conseguir el objetivo de la colaboración mediante la distribución lógica de

las cargas de trabajo. De esta forma, un agente software se desarrolla por lo general como un

proceso independiente del sistema, que será gestionado únicamente por el Sistema Operativo, y

que formará parte de una plataforma general dentro de la cual cumple una determinada labor,

monitorizando aquellos eventos que sean de su responsabilidad, analizándolos y actuando en

consecuencia.

El paradigma de sistema de agentes autónomos aplicado al campo de la Detección de Intru-

siones es el proyecto AAFID49 [30], desarrollado por el equipo de investigación de Gene Spa�ord

en la Universidad de Purdue. La �gura anterior ilustra un caso de ejemplo de arquitectura AA-

FID, en la que, como puede observarse, se plantea un estructura jerárquica en base a tres tipos

de componentes fundamentales implementados en forma de agentes autónomos. De esta forma,

cada uno de los agentes AAFID puede ser bien un Agente de campo, bien un Transceptor, o bien

un Monitor.

Por supuesto, cada una de estas categorías tiene asignada una misión concreta. En primer

lugar, los agentes de campo recopilan toda la información proveniente de la máquina que se desea

proteger, en el modo en que se especi�ca en el apartado de formalización. Posteriormente, toda

esa información es enviada al transceptor asignado a cada uno de los agentes, de forma que pueda

encargarse de la coordinación de las operaciones de dichos agentes, así como de la importante

tarea de la Reducción de auditoría, la cual redunda de forma notable en la e�ciencia del motor

de análisis. A continuación, los resultados de este procesamiento son enviados al monitor corres-

49AAFID: Autonomous Agents For Intrusion Detection.

108

Figura 2.41: Modelo General de Detección de Intrusiones de Denning

pondiente, quien tiene la responsabilidad de realizar el análisis propiamente dicho. Por último,

existe una capa de interfaz de usuario que puede aplicarse a cualquiera de los monitores, a través

de los cuales es posible realizar las labores de administración tanto del propio monitor, como de

los transceptores u otros monitores asignados a dicho monitor, como de los agentes de campo

asignados a dichos transceptores.

De esta forma, se consigue un Sistema de Detección de Intrusiones modular, robusto, esca-

lable y extensible. El desarrollo de cada uno de los agentes es más sencillo y, por lo tanto, más

seguro. Por otro lado, el sistema en su conjunto no está sujeto a un único punto de fallo, como es

habitual en sistemas con una orientación más centralizada. Por último, también es posible incor-

porar nuevos agentes ante el crecimiento del sistema que se pretende proteger, así como añadir

fácilmente nuevas funcionalidades. Todas estas ventajas no pueden pasar desapercibidas, dada la

acelerada evolución a la que están sujetos los actuales sistemas de computación y comunicaciones,

por lo que son tomadas en especial consideración en el presente trabajo de investigación. Otros

estudios realizados en la misma línea más recientemente son los llevados a cabo en la Universidad

de Iowa por Guy Helmer et al. [Helmer+03], en el Instituto Nacional de Estándares [260] por

Wayne Jansen et al. [196], y en la Universidad de Monterrey por Joseph Barrus [33].

109

Figura 2.42: Representación conceptual de GrIDS de una epidemia vírica

2.3.2. Detección basada en Grafos

La enorme capacidad infecciosa de algunas de las actuales amenazas que se ciernen sobre

sistemas de información de todo tipo[332], en combinación con ciertas peculiaridades intrínse-

cas propias de cada una de ellas, han dado origen a una propuesta de Sistema de Detección

de Intrusiones que propone la identi�cación de dichas amenazas en función precisamente de ca-

racterísticas exclusivas de su modo de propagación. Dicha propuesta, denominada GrIDS50, ha

sido desarrollada por el equipo investigador de Stuart Staniford-Chen [330], de la Universidad

de California Davis, y aborda el problema de la Detección de Intrusiones de esa manera.

En concreto, el sistema GrIDS monitoriza la actividad existente entre las distintas máquinas

conectadas a la red de comunicación del sistema de información que se pretende proteger, y

obtiene patrones de actividad, en forma de grafo, que posteriormente son comparados con los

patrones de propagación de epidemias conocidas que ya se encuentran documentadas. De esta

forma, el objetivo fundamental consiste en detectar estos ataques a gran escala en las primeras

fases de su desarrollo. La �gura ilustra de forma conceptual un caso de epidemia vírica repre-

sentada por GrIDS en forma de grafo. Por un lado, se muestra un primer grafo que representa

la propagación de una amenaza en sus primeros estadios de evolución, y por otro, se muestra un

segundo grafo en el que la citada epidemia ha alcanzado un estado completamente avanzado.

2.3.3. Sistema Inmunológico

Existe una línea conceptual dentro del área de conocimiento de la Detección de Intrusiones

que aboga por aprovechar las similitudes existentes entre un Sistema de Detección de Intrusiones

y el sistema inmunológico de los seres vivos [325]. Para ello, el objetivo fundamental de dicha

línea conceptual no consiste sino en diferenciar con precisión qué elementos de los presentes en

la realidad del sistema a proteger son propios de dicho sistema y cuáles no. A este respecto,

es interesante observar el alto grado de correspondencia de dicho objetivo fundamental con los50GrIDS: Graph-based Intrusion Detection System.

110

principios básicos de la Detección de Anomalías. De esta manera, al igual que un organismo

vivo es capaz de reconocer comportamientos extraños propios de antígenos, un sistema de de-

tección inmunológico es capaz de detectar comportamientos anómalos de los usuarios, así como

comportamientos clasi�cados de antemano como subversivos.

Además, este tipo de sistemas persiguen otra serie de cuestiones que en el caso de los orga-

nismos vivos se dan con naturalidad, como pueden ser la orientación completamente distribuida,

la diversidad, la adaptabilidad, la autonomía, la cobertura dinámica, la detección de anomalías,

la identi�cación de comportamiento, la no existencia de componentes de con�anza, o la detec-

ción subóptima o imperfecta. Como puede deducirse de manera natural, estas características se

adecuan extraordinariamente al conjunto de retos por alcanzar planteados. No obstante, a pesar

de lo ambicioso de los objetivos planteados y del horizonte de posibilidades que se abre de forma

apriorística ante este enfoque de detección, las investigaciones realizadas hasta el momento no

han conseguido eludir una costosa etapa inicial de aprendizaje supervisado, en la misma línea

que otros enfoques anteriormente descritos.

Por otro lado, a pesar de la supuesta novedad de la estrategia arquitectónica que se plantea, los

métodos de análisis que se utilizan dentro de cada uno de los elementos componentes del sistema

inmune también se corresponden con dichas aproximaciones anteriores, por lo que el nivel de

innovación aportado en lo puramente analítico es limitado. Algunas investigaciones interesantes

sobre el tema son las desarrolladas por Haiyu Hou y Gerry Dozier [378], por Dipankar Dasgupta

y Fabio González [96], y por el equipo de investigación de Steven Hofmeyr .

2.4. Técnicas de Análisis especí�cas para Host Intrusion Detec-

tion Systems (HIDS)

Los Sistemas de Detección de Intrusiones para Sistemas Operativos, o Host, como se vienen

denominando tradicionalmente requieren de datos para poder realizar su labor. Ha pasado

bastante tiempo desde que se empezó a tener ideas sobre cómo facilitar la auditoría de sistemas

en orden de garantizar la seguridad de los mismos. Existen incluso documentos, de hace bastante

tiempo, que a�rman que sin la capacidad de generar y almacenar información de auditoría, no

se puede considerar un sistema como seguro [279]

La auditoría permite dos puntos de acción fundamentales: el primero y más importante

es que si ha acaecido una violación de la seguridad del sistema, los sucesos que se han ido

produciendo son repetibles; así mismo, como segundo punto se tiene el que se va a poder predecir

el comportamiento de los usuarios y actuar en consideración si se estima un posible ataque en

base al conocimiento anterior.

Los Sistemas de Auditoría tienen que ser capaces de:

Aceptar datos de los procesos que puedan registrar sus propios datos de auditoría.

111

Recoger la su�ciente información como para deducir lo que está pasando en el sistema.

Recolectar datos en la totalidad del sistema a todos los efectos.

Hacer acopio de sucesos relativos a la seguridad en otras partes interesantes, aun sin ser

dependientes del host.

Otro de los problemas habituales en este tipo de sistemas es el hecho de que los eventos, evidencias

o muestras se producen muy rápido. Usualmente se afronta esta tesitura en genérico como en

la plataforma de [279], CMW51, Recolección Selectiva y Reducción Selectiva. La Reducción

Selectiva se basa en recoger su�cientes datos para cumplir los requisitos de identi�cación de

usuarios, objetos accedidos, nivel de seguridad, etcétera. La Recolección Selectiva es idéntica al

caso anterior pero recogiendo selectivamente cualquiera de las partes anteriores acorde al patrón

que se esté buscando. Así mismo, los datos deberán ser almacenados bien localmente o bien

externamente en centros de recopilación de información. El hecho de almacenar la información

localmente sucinta un riesgo de poder ser alterado indebidamente. La recogida de datos que

plantearon en su momento abordaba 3 niveles importantes de modo que la captura fuera global:

intercepción de llamadas de sistema (syscall) en kernel, en la interfaz que se le proporciona por

el sistema operativo al usuario y a captura de interacción entre sistema operativo y aplicación.

El problema asociado es el volumen de datos generados, dado que son muchos los recursos a

monitorizar: sistema, aplicaciones, usuarios, etc.

2.4.1. Preámbulo: Ataques Mimicry en Sistemas de Detección de Intrusiones

Se hace un estudio [372] sobre diferentes tipos de sistemas de detección basados en host

(HIDS) para ver la seguridad que presentan contra diferentes ataques evasivos. Los ataques

denominados Mimicry permiten a un atacante realizar el ataque sin ser detectado por ninguno de

los sistemas existentes. Para poder demostrar este tipo de ataques se desarrolla una aplicación

marco que permitiera efectuarlos, demostrando que era viable realizarlos contra la seguridad

existente en una implementación concreta de HIDS.

Los autores argumentan que para detección de anomalías, casi todos las llamadas al sistemas

se pueden traducir en operaciones de no-operación (no-op), de forma que puedan desorientar

al sistema de detección realizando �nalmente la tarea que se desea. Hay mucha literatura que

explica diferentes mecanismos de detección que son susceptibles a engaños mediante este tipo de

técnica:

Sistemas basados en el análisis de llamadas al sistema [134, 310, 14, 309]

Minería de datos [369, 229]

Redes Neuronales [14]

51 Compartmented Mode Workstation

112

Autómatas Finitos [52]

Modelos de Markov Ocultos [374]

Reconocimiento de patrones en secuencias de comportamiento [343, 344]

Una de los puntos de partida de este tipo de técnica es el hecho que no todo código malicioso

tiene la necesidad de llamar a una llamada al sistema. Como segunda arma los atacantes suelen

tener de su mano la paciencia, esperar hasta que la secuencia sea aceptada por el sistema de

detección como comportamiento normal para lanzar el ataque, incluso conduciendo el aprendizaje

del sistema en uno u otro sentido. El atacante contra sistemas basados en detección de llamadas

de sistema, puede introducir un troyano que se encargue de modi�car las librerías a las que se

ha llamado para realizar una determinada tarea.

Una parte importante que se debe tener en consideración cuando se realizan este tipo de

ataques es el hecho de que generalmente, después de haber realizado el ataque el sistema entra en

una serie de trazas de syscalls a las que le ha llevado el código atacante, que generalmente no están

contempladas por los sistemas de detección indicando esta anomalía debidamente (detección a

posteriori al ataque producido). Para poder solucionar este tipo de situaciones se debe llegar a

realizar un cierre de aplicación anticipado pero existente en el sistema de detección, haciendo

pasar el ataque como un fallo de programación en vez de como una violación en la seguridad.

Otra aproximación bastante acertada es realizar un ataque mediante las cadenas de syscalls

más comunes dentro de la aplicación objetivo. Es decir, crear de las diferentes trazas que se

puedan tener, aquella que sea más común para que la desviación �nal sea lo menor posible.

Siguiendo esta línea incluso se pueden realizar ataques o troyanos que emulen a la aplicación

objetivo después de haber realizado el ataque para que el sistema parezca que se encuentra en

un estado correcto.

Un fallo o carencia habitual en los sistemas de detección es la ausencia en el estudio de los

parámetros, haciendo que haya situaciones en las que varias llamadas sean la misma, queriendo

realizar cosas muy diferentes:

Listing 2.1: Ejemplo de un ataque Mimicry

1 //LLAMADA AL SISTEMA INOFENSIVA

open ( " / l i b / l i b c . s o " , O_RDONLY) ;

//LLAMADA AL SISTEMA DE POSIBLE ATAQUE

6

open ( " / e t c / shadow " , O_RDWR) ;

Otro defecto observado es que si no hay forma de insertar el código atacante dentro del

modelo de la aplicación que mantiene el IDS, hay una forma de variar la secuencia del ataque

113

mediante la inserción de operaciones que no hagan nada. Estas operaciones conocidas como, �sin

operación (nop)�, sirven para que la traza se mantenga acorde a lo que ha aprendido el sistema

de detección, pero realmente el objetivo �nal es conseguir poner en marcha la vulnerabilidad de

la seguridad deseada.

Continuando con lo expuesto en el párrafo anterior, siempre es posible generar las variaciones

en el ataque que permitan llegar a la situación en la que el detector no va a ser capaz de indicar

la anomalía. Un ejemplo puede ser tan simple como que una llamada read() de un �chero en

memoria, puede ser equiparada en código a una mmap() seguida de un acceso a memoria. Por

la misma regla, hay secuencias que pueden ser desordenadas desde el ataque original al necesario

para evadir el sistema HIDS. De la misma forma unas pocas llamadas al sistema le dotan al

atacante de un poder especial, como por ejemplo la fork(). Esta última llamada es tratada

por los sistemas HIDS desdoblando el sistema para seguir al proceso padre y al proceso hijo, lo

que permite al atacante realizar el ataque en dos pasos diferentes dentro de distintos procesos.

Además si se consigue un acceso a la llamada execve() se le ofrece al ataque la posibilidad de

ejecutar cualquier cosa que desee en el sistema.

2.4.2. Detección mediante Análisis Forense

Es posible mejorar el conocimiento de lo sucedido en un sistema informático mediante el uso

de técnicas forenses [198] que no requieren de predecir la naturaleza del ataque, el conocimiento

del atacante o de los detalles de los recursos del sistema y objetos afectados. Los principios

incluyen la grabación de datos sobre el sistema operativo en su totalidad, particularmente los

eventos y entornos en espacio de usuario, así como interpretando los eventos en capas de diferente

abstracción según el contexto donde han sucedido. Los autores además, proponen la creación de

una máquina de estados �nita sobre la que los resultados puedan ser establecidos preferiblemente

a ser inferidos.

El análisis forense es el proceso de comprensión, recreación y análisis de los eventos que han

sucedido previamente. El logeo es la grabación de datos que puedan ser útiles en el futuro para la

comprensión de eventos pasados. El proceso de auditoría de sistemas se compone de la recogida,

examen y análisis los datos guardados.

El hecho de trabajar temporalmente después de haber sucedido la vulnerabilidad, les permite

a los expertos conocer la forma en la que ha sido cometida. Para poder realizar este tipo de

análisis hay que hacer uso de una serie de puntos clave:

El sistema al completo debe ser considerado.

Los efectos de una acción pueden ser diferentes de los que se espera que sean.

Los datos en ejecución son el único registro de qué pasó exactamente. Mientras que los

escaneos de vulnerabilidades anteriores y posteriores a la intrusión pueden ayudar ampli-

114

amente, un conjunto de datos en tiempo real es la única fuente autorizada de la que se

puede sacar información completamente �able.

En este tipo de metodologías se tienen en cuenta una serie de premisas de partida:

Principio 1: Tener en cuenta el sistema completamente. Esto incluye tanto el espacio de

usuario, como el espacio de núcleo del Sistema Operativo, sistemas de �cheros, pila de

protocolos de red y subsistemas asociados.

Principio 2 : No siempre esta logeado lo que se presupone sobre fallos esperados, ataques

y atacantes. No creer en ningún usuario y no con�ar en ninguna política, dado que no se

sabe de antemano lo que se encontrará.

Principio 3 : Tener en consideración los efectos de los eventos, no solo por ser debidos a

una serie de acciones, si no por cómo esos efectos pueden alterar el contexto del entorno.

Principio 4 : El contexto ayuda en la interpretación y compresión del signi�cado de un

determinado evento.

Principio 5 : Cada acción y cada resultado debe ser procesado y presentado de forma que

pueda ser analizado y comprendido en un análisis forense.

En el artículo se expone que una de las mayores faltas en esta técnica es la inexistencia de un

análisis automatizado para poder realizar todas las comprobaciones. El resumen de realizar una

solución genérica pasa por recoger no solo los eventos del kernel, si no también información so-

bre los tiempos, tamaños y localizaciones de alojamientos de información en memoria, lecturas y

escrituras. Las herramientas deberán conseguir eventos de información acerca de enlaces abstrac-

tos, sobre todo de aquellos que vayan a la red o que sobrepasen el sistema de �cheros local. Se

deben recoger datos de programas, funciones y nombres de variables. Mediante una correlación

apropiada de esos nombres, eventos de memoria, contexto del sistema, entorno del programa,

herramientas que cubran los principios anteriores, si es presentada de forma humanamente legible

se podrá tener una herramienta adecuada para estas problemáticas.

El análisis de intrusiones a día de hoy, suele ser un trabajo difícil que se realiza generalmente a

mano, debido a que los administradores carecen de información y herramientas para comprender

fácilmente la secuencia de los pasos que ocurren en un ataque. Los creadores de la aplicación

BackTracker [212], después de producirse la intrusión, han dispuesto de una serie de medidas

para poder relacionar las evidencias entre sí. Hay una serie de factores que pueden indicar una

dependencia entre eventos:

Dependencias entre procesos. Esto se produce cuando un proceso afecta directamente en

la ejecución de otro proceso. Las causas pueden ser: creación, compartición de memoria,

envío de mensajes o señales...

115

Dependencias proceso a �chero. Conseguir datos interesantes de �cheros del sistema medi-

ante un proceso. También se puede cargar el �chero completamente en memoria y leer/e-

scribir directamente ahí antes de guardarlo.

Dependencias entre proceso y nombre de �chero. Un ejemplo de esto puede ser cuando

una aplicación carga un �chero con su con�guración, si este contiene datos incorrectos se

pueden producir situaciones peligrosas.

Para realizar el trazado inverso de aplicaciones se logean los objetos y los eventos con las de-

pendencias en tiempo de ejecución. De esta forma se puede construir un grafo que indique las

relaciones entre todos los objetos que se han ido viendo en ejecución. Un ejemplo de un grafo

orientado a los eventos que se van realizando, partiendo de la información de que se ha producido

un ataque:

Figure 2.43: Grafo de dependencia que puede seguirse realizando operaciones de BackTracking

2.4.3. Detección basada en análisis estático o instrumentación binaria del

sistema

En el documento [198] los autores explican la creación de una herramienta, DOME, que

realiza un análisis estático para identi�car las localizaciones (espacio virtual de direcciones) de las

llamadas al sistema que realizan los programas ejecutables. Después de obtener esas direcciones

se monitorizan los programas en tiempo de ejecución y se veri�ca que la posición de memoria

utilizada por el ejecutable es la que corresponde con el estudio del sistema anterior. Esta técnica

es simple, práctica y aplicable al mundo real, pero si bien el equipo de investigación S3lab de la

Universidad de Deusto debe indicar que es posible infectar el código de las llamadas a sistema,

manteniendo intacta la posición del mapeo de memoria virtual.

Los autores sostienen que mediante el sistema DOME realizado obtienen una potente técnica

para proteger el software contra código malicioso, bien código inyectado dentro de los procesos

(bu�er over�ows...), bien código generado automáticamente (virus polimór�cos, troyanos que

116

guardan sus datos cifrados, descifrando su código fuente y ejecutándose en el momento de ar-

rancar...), o bien código malicioso ofuscado (virus, troyanos, gusanos... que ocultan su código de

forma que sean difíciles de detectar).

Mediante esta técnica es posible entrar al tan ansiado campo para los administradores de

detección de ataques nóveles, Zero-day attacks. Este proyecto ha centrado su estudio en windows

2000, con lo que el formato de estudio consecuentemente se ha �jado en formato de �chero

portable ejecutable (formato PE).

Los desarrolladores indican que para la detección del código inyectado, problemática indicada

previamente por el equipo de investigación S3lab, no es posible realizar esta técnica, dado que

lo que se cambia no es la dirección o la llamada a una u otra función, si no el propio código que

se va a ejecutar en el momento de su carga.

Otro tema que plantean en el documento, es la posible sobrecarga del sistema al realizar

la captura de eventos producidos, se indica que producen una sobrecarga al sistema de un 5%

al realizar las funciones de comparación para cada llamada a la API. Así mismo el sistema

desarrollado esta limitado a las llamadas a funciones de Win32, dejando las llamadas más internas

al sistema sin capturar.

Los autores plantean una serie de premisas:

Cualquier código inyectado, generado dinámicamente u ofuscado se asume como malicioso.

El código maligno interactúa con el sistema operativo.

En la interacción con el sistema operativo, el código malicioso, usa las llamadas exportadas

por Win32 (en el sistema operativo en estudio de los autores).

Cuando un código malicioso se esconde de la detección y análisis mediante el uso de gen-

eración de código dinámico y ofuscación, se esconde a su vez el uso de las llamadas a

Win32.

Los ejecutables software que deben ser protegidos pueden ser desensamblados y se puede

obtener la información sobre las API's usadas. Por lo tanto son monitorizables.

Se suele hacer uso de Detours [140]como herramienta de análisis para facilitarse el acceso al sis-

tema operativo en cuestión, herramienta que se introducirá y comentará en el siguiente capítulo.

La investigación últimamente esta decantándose en lo que se denomina instrumentación bi-

naria dinámica, utilizada comúnmente en los estudios para realizar Análisis Forenses [366]. El

malware52 actual es susceptible de tener métodos para modi�car el código de programa que usan.

Los compiladores en tiempo real (JIT) a pesar de dar un soporte transparente, no son capaces de

seguir sistemas o aplicaciones multihilo, programas automodi�cables o código que se autotestea

en modo de núcleo. Para poder resolver este problema los autores han creado una herramienta

52 Término genérico que hace referencia a virus, troyanos, software espía (spyware)

117

que analiza la granularidad sobre el proceso, la red, teclas usadas, �cheros, registro de sistema

y un largo etcétera. Mediante esta herramienta después de detectar un comportamiento anó-

malo se puede analizar a través de debuggers las diferentes formas de un virus polimór�co, su

cifrado-descifrado de datos, el contenido de memoria que ha usado.

Las técnicas de instrumentación binaria representan a la habilidad de controlar las construc-

ciones pertenecientes a cualquier código y es empleada tanto en técnicas de análisis grueso como

granular. El control se re�ere a generar la construcción del ejecutable para observar una posible

alteración semántica. La instrumentación binaria se clasi�ca en dos categorías:

Basadas en pruebas: Dtrace [55], Dyninst [45], Detours [140]. Realizan su función modi�-

cando el programa objetivo para ser ejecutado de una forma determinada cuando se llama

al programa original.

JIT: Pin [234], DynamoRIO [44], Valgrind [257]. Estos métodos se basan en la instru-

mentación mediante empleo de máquinas virtuales (VM).

Los métodos basados en pruebas no son transparentes debido a que las instrucciones originales

se sobreescriben en memoria por medio de lo que se denominan trampolines53.

El sistema que denominan SPiKE ofrece una API sobre la que integrar las funciones para

los analizadores que se quieran. Introduce en la memoria virtual una serie de elementos lógicos

que se activan cuando se produce una lectura, escritura o ejecución. El producto se basa en

otro entorno denominado VAMPiRE [366] para poder insertar esos códigos lógicos en la posición

adecuada de memoria. La técnica de activación de eventos que usan, denominada por ellos Drift

Invisible lo que hace es insertar código en unas determinadas posiciones correspondientes a la

construcción del código del que se desea realizar la instrumentación. Un BreakPoint en código

permite detener la ejecución de código arbitrario durante el tiempo de ejecución. Para evitar

que se detecte este tipo de ganchos se usan páginas de memoria que contienen la información

referente a ellas mismas como �no presente� y se basan en el sistema de Detección de Excepciones

de Paginado en Memoria (PFE).

Los errores más comunes de programación de aplicaciones con los que se suele ganar el control

de un sistema o de una aplicación residen en la manipulación de corrupciones en memoria de

los procesos. Los ataques más comunes actualmente son debidos a �bu�er over�ow� o a �format

string�. Se considera importante identi�car automáticamente cuándo se han producido estos

errores. El punto que presentan los autores de este texto [201] en el que se puede detectar el

error producido es el momento del cierre inesperado y de forma incorrecta de la ampliación.

Una vez conocidos los valores de datos y direcciones que se han embebido en el ataque se puede

bloquear este tipo de ejecuciones. En el documento [201] se presenta y desarrolla un sistema

descentralizado y auto protegido para los ordenadores cableados en red. Se pueden encontrar

53 Un trampolín es una secuencia de código que se puede atravesar entrando en múltiples partes de la mismadado que no realiza operaciones que varíen el contexto del procesador.

118

numerosos intentos para la detección de �rmas de ataque de este tipo, como pueden ser los

siguientes:

Honeycomb [214]

Autograph [210]

Early Bird [312]

Poligraph [193]

Pero este tipo de métodos suelen de una limitación, que generalmente se hace uso de un análisis

sintáctico sobre los ataques, olvidando la semántica en la que se han producido los mismos.

Muchas otras aproximaciones que se están desarrollando se basan más en la instrumentación del

código binario e incluso pueden recuperarse de los ataques una vez producidos:

TaintCheck [259], realiza un análisis dinámico mediante una emulación binaria del pro-

grama para atrapar la propagación del binario por la red. A su vez también se realizan

�rmas de ataques basadas en semántica.

DIRA [321], hace una instrumentación del código para mantener un log de actualización de

la memoria mientras el programa está en ejecución, realizando incluso una vuelta a atrás

para volver a una zona segura cuando se ha producido el ataque.

STEM [311] realiza una aproximación reactiva. Después de detectar un ataque, se reem-

plaza la vulnerabilidad del programa con una versión parcheada.

Las herramientas anteriores aun siendo un paso importante introducen debido a la instru-

mentación de código una sobrecarga importante en la ejecución de un determinado proceso.

El análisis del �ujo de la información dinámica (DIFA) [248] es muy útil para la detección de

intrusiones a nivel de aplicación. Uno de los efectos más habituales de los ataques so�sticados es

el hecho de poder introducir información insegura dentro de partes importantes de la aplicación,

esta modi�cación es un hecho contrastable del suceso de este tipo de ataques. Muchos de estos

patrones de comportamiento, una vez detectados se pueden introducir en un sistema de detección

de intrusiones basado en �rmas.

2.4.4. Detección basada en �rmas

Arbaugh en el año 2001 [43] indica que en el mundo de la seguridad informática de los

sistemas de alta disponibilidad, los administradores se encuentran en la tesitura de mantener

sistemas a sabiendas con vulnerabilidades. Esta situación se produce debido a que se descubren

fallos de seguridad continuamente, pero pasa un tiempo hasta que se tiene la solución de los

119

Figure 2.44: Ciclo de vida de una vulnerabilidad en software

mismos, conllevando que estos administradores se encuentren indefensos durante periodos de

tiempo dado que una baja en el servicio conlleva pérdidas difícilmente cuanti�cables.

Para ello Arbaugh diseñó, implementó y evaluó un sistema que soporte la construcción y eje-

cución de predicados que representen una determinada vulnerabilidad. El sistema que presentan,

Intro-Virt, se vale de técnicas basadas en introspección de máquinas virtuales para monitorizar

la ejecución de la parte software, aplicaciones y sistema operativo.

El proceso por el que una aplicación determinada o sistema operativo se mantiene vulnerable

es el siguiente:

Como se puede ver en la imagen anterior, el hecho de que una vulnerabilidad sea observada,

no implica que inmediatamente se corrija, aquí entran en juego diferentes motivaciones de los

administradores, desarrolladores y directivos [157, 24, 43, 35].

La idea sobre la que se basan los autores es comprobar mediante una serie de predicados si se

dan las propiedades para una u otra vulnerabilidad. Así mismo, combinando los predicados con

los resúmenes de las máquinas virtuales creadas, el usuario podrá conocer si ha sucedido alguna

anomalía de este tipo en el pasado. Los autores dejan claro que descubrir vulnerabilidades

acaecidas, no es prevenir de una posible intrusión, pero sí es un punto de partida para conocer

hasta qué punto el sistema ha sido comprometido.

Otro de los pilares fundamentales que tienen en mente los autores es que mediante la combi-

nación de predicados de vulnerabilidad especí�cos, junto con una respuesta estratégica se puede

alertar al usuario e incluso prevenir sobre los ataques que están sucediendo en el sistema.

Los predicados que buscan los autores son fáciles de escribir una vez que es conocida la

vulnerabilidad e incluso podrían ser transcritos por la entidad que se encargue de escribir el

parche. Un predicado correcto no puede tener ni falsos positivos ni falsos negativos, pero en

contraposición con los detectores de �exploits� especí�cos se lograría captura las variantes del

código malicioso, cualidad que no es soportada por estas últimas herramientas.

Los predicados con las de�niciones de vulnerabilidades deberán ser ejecutados fuera del en-

torno del sistema, es decir, que no es apropiado mantener la revisión de los mismos ni en zona

de usuario, ni en zona de kernel. La solución pasa por tener hardware dedicado a este tipo de

tesituras.

Una de las primeras pruebas que realizan es ejecutar el software objetivo en una máquina

virtual, de esta forma se obtiene acceso total al sistema en estudio, esta técnica se denomina:

introspección de máquinas virtuales [142]. Para poder demostrar estas ideas los autores se basan

120

en VMM (Virtual Machine Monitor), que en plataformas de virtualización como Xen [276], es la

parte encargada de gestionar los recursos utilizados. Así mismo si el atacante consigue poner en

el peligro el propio núcleo del sistema de virtualización, debido a una fuga de la caja estanca en

la que se estaba trabajando, se tendrán problemas complejos de detectar y solventar.

2.4.5. Detección de ataques contra la lógica de las aplicaciones

Como ya hemos visto en secciones anteriores, la detección de anomalías basadas en el análisis

de trazas de llamadas al sistema de los diferentes programas para obtener un modelo de su com-

portamiento y posteriormente analizar sus llamadas en busca de anomalías, puede dar resultados

óptimos en la detección de ataques. No obstante, este tipo de detección no es apropiada cuando

lo que se ataca en la lógica de las aplicaciones. En estos casos se hace insu�ciente en análisis de

�ujo de llamadas al sistema, pues estos ataques en contadas ocasiones modi�can la trayectoria

de ejecución de los procesos (con lo que la traza de llamadas al sistema invocada por éstos se

mantiene intacta). Por tanto, las aproximaciones basadas en el análisis de secuencias de llamadas

al sistema no detectarían estos ataques [134, 371].

Otro problema es que la información que se necesita para detectar ataques a nivel de lógica

de aplicación puede no estar o ser muy difícil de extraer de las llamadas al sistema invocadas por

el proceso.

Para detectar ataques de éste tipo, es recomendable realizar una auditoría selectiva en ciertos

puntos del �ujo de control de la aplicación. El problema es que pocas aplicaciones proveen de un

hook54, e incluso cuando éstos están disponibles no suelen estar colocados en el lugar correcto.

Además, la técnica de instrumentación suele ser especí�ca para cada aplicación y difícil de portar

a otros programas.

Auditando los datos

Auditar es el mecanismo de recogida de datos respecto a la actividad de los usuarios y las

aplicaciones. Ya que el sistema operativo es considerado como una entidad con�able debido a

que se encarga de los accesos a los recursos (como memoria y �cheros), la mayoría de los sistemas

de auditoría están implementados dentro de él. Estos sistemas de auditoría no están diseñados

especí�camente para la detección de intrusiones y por lo tanto, en muchas ocasiones los datos

producidos por los sistemas de auditoría del sistema operativo contienen información irrelevante

y escasez de datos útiles. Debido a este hecho, usualmente los sistemas de detección de intrusiones

desarrollan herramientas propias para acceder directamente al sistema operativo en busca de la

información realmente relevante.

Lunt [235] sostiene que es necesario disponer de aplicaciones auditoras que provean de la

información puramente necesaria para la detección de intrusiones.

54Sistema de recolección de datos a bajo nivel, como por ejemplo las llamadas al sistema invocadas y losargumentos de éstas.

121

Reescritura binaria dinámica

Esta técnica es independiente de plataforma y soporta la recogida de información en cual-

quier lugar dentro del �ujo de control de la aplicación [401] y es utilizada en conjunto con �rmas

especí�cas de aplicación para detectar ataques que explotan los errores de la lógica de la aplica-

ción. Esta aproximación ha sido validada a través de muchos estudios de casos de ataques contra

aplicaciones reales como por ejemplo Apache y OpenSSH [401].

La reescritura binaria dinámica es una técnica de post-compilación que cambia directamente

el código de los ejecutables. Al contrario que la librería de interposición dinámica, la reescritura

binaria dinámica funciona con programas vinculados estática y dinámicamente. Además provee

de un mayor acceso a la parte interna de la aplicación ya que además de las librerías de funcio-

nes, pueden ser utilizadas funciones estáticas de la aplicación. Existen dos tipos de técnica de

reescritura binaria:

1. Estática: Modi�ca la imagen residente en disco del binario55 de los programas.

2. Dinámica: Cambia la imagen de memoria de un proceso.

ATOM [328], EEL [225], Purify [159], y Etch [345] son ejemplos de herramientas basadas en

técnicas de reescritura estática. Dyninst [45] y Detours [140] son ejemplos de herramientas de

reescritura dinámica.

Comparando ambos métodos, la escritura dinámica tiene la ventaja de que mantiene intactos

los ejecutables de las aplicaciones. Además, utilizando la escritura dinámica es posible modi�car

los binarios de la aplicación de varias maneras, dependiendo del contexto de invocación de la

aplicación y permite mantener el código tras una llamada fork()56, por lo que el proceso hijo

también será instrumentalizado.

En términos generales, la reescritura binaria dinámica es una aproximación de interposición.

La técnica de interposición a las llamadas al sistema ha sido utilizada para desarrollar per�les

de usuario y depuración de sistemas software, además de ser muy utilizada con propósitos de

seguridad:

1. Curry, usa interposición dinámica de librerías para pro�ling57 y traceo de llamadas a las

librerías [81].

2. Deteurs, una herramienta de depuración y pro�ling que utiliza reescritura binaria dinámica

para interceptar funciones Win32 [140].

55Los �cheros binarios son archivos electrónicos que han sido guardados utilizando el código básico de lascomputadoras u ordenadores: código binario, una sucesión de ceros y unos. [1]

56Se trata de una llamada al sistema operativo para que duplique el proceso que ha llamado, creando por tantoun proceso hijo que será una copia de él mismo.

57Técnica de creación de per�les de usuario, aplicaciones, ...

122

3. ByPass, extiende la funcionalidad del software de sistemas existente para computación

distribuida utilizando técnicas de interposición en librerías compartidas [354].

4. Interposition Agents, es un RootKit58 para interponerse entre el código de usuario y el

núcleo del sistema operativo [200].

Por lo tanto ésta aproximación separa las rutinas de auditoría de la aplicación original. De esta

manera puede ser añadido un nuevo módulo de auditoría sin que se requiera la recompilación

de la aplicación. La selección del módulo de auditoría es pospuesta hasta el momento en el

que la aplicación es invocada, permitiendo una selección de con�guración de auditoría �exible.

Además, las rutinas de auditoría y la aplicación corren bajo el mismo espacio de direcciones con

rendimiento comparable al acercamiento de modi�cación del código.

2.4.6. Detección basada en Secuencias de Syscalls

Estudio de secuencias de llamadas al sistema para clasi�car las intrusiones [37] y los fallos

inducidos en procesos privilegiados de UNIX. La clasi�cación es una capacidad esencial para

responder a una anomalía, dado que permite asociar respuestas apropiadas para responder a

cada anomalía. Los autores [199] a�rman que la creación de un Diccionario de Anomalías es

imprescindible en este tipo de sistemas. Este tipo de diccionarios se encargan de contener la

información sobre las secuencias anómalas para cada tipo de anomalía. A su vez, en paralelo

con este tipo de diccionarios se pueden crear los denominados Diccionarios Normales, para poder

realizar la clasi�cación debidamente.

Los esfuerzos durante más de 20 años se han centrado en la generación de Sistemas de Seguri-

dad de la Información aplicando técnicas de Minería de Datos, Aprendizaje de Máquinas, Re-

conocimiento de Patrones e Inteligencia Arti�cial [192, 370, 289, 258]. La metodología planteada

en [199], denominada �stide� (sequence time-delay embedding) se puede resumir de la siguiente

forma:

1. Modelado: Se caracteriza el fenómeno en estudio por medio de una secuencia de variables

o símbolos dentro un alfabeto largo pero �nito. Estas secuencias se obtienen manteniendo

el programa en estudio ejecutándose desde el arranque hasta el cierre.

2. Recolección de Datos Normales: Recogida de grandes volúmenes de datos correspondi-

entes a la operación normal del programa, almacenando los símbolos generados. Ene este

apartado se realiza el estudio numerosas ocasiones, produciendo numerosos procesos, hi-

los... tratando de explorar la operación normal de funcionamiento de todas las formas

posibles.

58Es una herramienta que se ejecuta a nivel del sistema operativo capaz de interceptar llamadas al sistema yafectar a los procesos que se están ejecutando, con diversos propósitos.

123

3. Extracción de características: Se selecciona un tamaño de cadena (k), y se construye un

diccionario de secuencias cortas sobre los datos del Diccionario Normal. Esto se realiza

mediante una ventana deslizante del tamaño k a través de la muestra, saltando sólo un

único símbolo cada momento.

4. Detección: Dado una muestra de entrada del sistema en estudio, se realiza la detección

de anomalías mediante comparación de secuencias contra el �chero salvado de normalidad

anterior. Si las secuencias no son encontradas se denominarán �secuencias anómalas� y se

almacenarán en el Diccionario de Anomalías.

2.4.7. Detección basada en grafo

Detección basada en grafo de llamadas al sistema

Los autores establecen que si bien el kernel de linux dota al usuario de una serie de funciones

interesantes de modularidad y �exibilidad, en sistemas embebidos se puede lograr un mejor

rendimiento, para ello se valen de lo que han denominado como �grafo de llamadas al sistema�

basado en la ingeniería inversa de este tipo de sistemas. Mediante una representación en forma

de grafo se puede representar el comportamiento del sistema objetivo mejorando o haciendo

hincapié en optimizar determinadas funciones.

En la forma en la que trabajan los autores, se consigue representar y abstraer el fun-

cionamiento interno del kernel, así como de las aplicaciones que hacen uso del mismo. Una

representación del funcionamiento de llamadas entre funciones de código puede ser el siguiente:

Figure 2.45: Grafo de llamadas que se producen desde código fuente.

Un grafo de llamadas es un grafo dirigido que representa la estructura estática del programa.

Al igual que el grafo anterior se ha realizado para un programa, se puede realizar un grafo

semejante para las llamadas desde el código fuente de las librerías. Es el mismo concepto que en

el caso anterior pero carece de raíz. Esto queda expresado en la �gura siguiente:

124

Figure 2.46: Grafo de llamadas entre librerías

Teniendo el grafo adecuado para cada máquina, dependiendo de las aplicaciones que se tengan

instaladas, se puede diferenciar un comportamiento normal del mismo o sucesos anormales. En

la misma línea, dado que los sistemas de detección de intrusiones se usan para detectar los rastros

de actividades maliciosas sobre redes y sistemas, en el documento de Mutz de 2006, [95] se indica

una forma para detectar una secuencia de llamadas al sistema anómalas.

Los sistemas de detección de intrusiones se clasi�can, como ya se ha comentado en puntos

anteriores, de dos formas: basados en malos usos o basados en anomalías. En los primeros

sistemas (misuse-based) [277, 231] se tiene un número de descripciones de ataque, o �rmas, que

se tratan de localizar sobre �ujos de datos de auditoría de sistemas. Estos sistemas generalmente

son e�cientes y tienen una baja tasa de detecciones erróneas que se denomina �falsos positivos�.

Si bien, la gran pega de este tipo de sistemas es el hecho de que no detectan ataques que no

haya sucedido alguna vez y de los que se tenga conocimiento. Un buen ejemplo para una tarea

concreta puede ser el caso de detección de condiciones de carrera, en el que se ha desarrollado un

lenguaje de auditoría de trazas BSM, denominado BSML [281]. En este documento se explica

un lenguaje para determinar cuando se dan estas situaciones y actuar en consecuencia por si se

esta produciendo un ataque.

Dentro de los diferentes tipos de sistemas de detección de intrusiones, los que se basan en

anomalías [105, 146] construyen modelos del comportamiento que se espera de las aplicaciones.

Para generar estos modelos se revisa la operación normal de las mismas, guardándolo como punto

de referencia. Los modelos que se consiguen se denominan �per�les�.

De la forma anterior comparando los modelos de comportamiento de cada aplicación con

el comportamiento actual se pueden obtener las desviaciones que hayan surgido. Una de las

premisas de esta forma de actuación es el hecho de que una desviación sobre el comportamiento

aprendido, conlleva ser víctima de un ataque. En el documento de Denning [105] se trata de

125

realizar una aproximación basándose en per�les de usuario, pero este tipo de técnicas no pueden

ajustarse a los cambios de repentinos de los usuarios en su comportamiento.

Se han desarrollado diferentes sistemas de anomalías con diferentes técnicas de detección.

Ejemplos de ello pueden ser desde la detección y de datos sobre el trá�co de red [229] o análisis

estadísticos de registros de auditoría [396]. La secuencia de llamadas al sistema producida por

las aplicaciones ha sido objeto de análisis de detección de anomalías. Las técnicas que se han

ido proponiendo son aproximaciones de dos tipos: basadas en especi�caciones y basadas en

aprendizaje.

La aproximación mediante especi�caciones confía en unos modelos especí�cos para cada apli-

cación que han sido realizados manualmente [36, 62, 213], bien con conocimiento experto, bien

derivadas a través del uso de algún programa con alguna técnica de análisis [371]. Los per�les

generados de esta forma son introducidos como entrada de un sistema de detección de intrusiones

en tiempo real, así cuando se produzca una secuencia de llamadas no conformes con el modelo

se levantará la correspondiente alerta. La mayor pega de este tipo de sistemas de detección es el

hecho de que tienen una limitada capacidad para generar las especi�caciones, tarea normalmente

bastante ardua para ser realizada a mano. Otro problema de este tipo de HIDS es la necesidad

de interacción del usuario durante la fase de entrenamiento, si bien es posible utilizar modelos

prede�nidos para cada aplicación, no son aplicables para todos los usuarios, sobretodo al emplear

diferentes con�guraciones. Así mismo, para este tipo de aproximación se requiere el acceso al

código fuente.

Si ahora se analiza la técnica de aprendizaje se debe señalar que no es necesario asumir nada

de antemano, si no que los per�les se construyen en base al análisis de las llamadas al sistema

durante la ejecución normal. Esta primera aproximación vino de la mano de Forrest [134]. La

clave de este método es el hecho de que un programa que tiene que interaccionar con el sistema

operativo en el que esta siendo ejecutado requiere hacer uso de las llamadas al sistema para

poder causar un daño permanente en el sistema. Cuando una secuencia de llamadas al sistema

se desvía del comportamiento esperado, se asume que se está produciendo un ataque.

La idea era recabar durante la fase de aprendizaje todas las posibles secuencias de llamadas al

sistema de una determinada longitud. Durante la fase de detección, se comparaban las cadenas

de secuencias recogidas con las legítimas aprendidas en la primera fase, teniendo la posibilidad

frente a desviaciones de indicar la anomalía. El problema de esta técnica es que sólo hace uso de

la secuencia que siguen estas llamadas, dejando a un lado los argumentos y los valores devueltos

al retornar de las mismas. Además en la metodología de la autora sólo se examina un proceso

en concreto.

Siguiendo ésta línea de trabajo, otros autores han continuado el trabajo precursor del análisis

de secuencias de syscalls [371, 374, 131], y por norma general es la opción más utilizada para

análisis del comportamiento de los programas.

Las técnicas basadas en detección de anomalías conlleva un riesgo inherente de detectar como

126

anomalía comportamiento de secuencias que son legítimas en el funcionamiento de una determi-

nada aplicación, así como realizar código malintencionado que siga las secuencias de llamadas

correctas. Además generalmente las técnicas que se aplican no hacen uso de los argumentos que

llevan asociados las llamadas al sistema.

Se proponen dos posibles mejoras a los sistemas de detección de anomalías basados en host:

1. Aplicar sistemas de detección que incorporen los argumentos que llevan las llamadas al

sistema.

2. Descubrir una forma de cuanti�car la puntuación de anomalía de cada modelo en una

medida global. Este resultado determinará si un evento es parte o no de un ataque.

En concreto para resolver este problema los autores proponen una técnica que hace uso de las

Redes Bayesianas para realizar la clasi�cación de las llamadas al sistema. Los autores demuestran

que el análisis de los argumentos y el uso de clasi�cadores Bayesianos mejoran la precisión contra

los intentos de evasión. La salida de cada uno de los motores de detección individuales se combina

con una Clasi�cación Bayesiana, mejorando a los clasi�cadores basados en umbrales naive que

se usan para combinar las salidas de los modelos.

El sistema propuesto al estar basado en análisis de llamadas al sistema individuales, es más

resistente contra los ataques que tratan de asemejarse a la forma normal de comportamiento de

una aplicación: ataques �mimicry attacks� [348, 346, 372]. La de�nición formal de este tipo de

ataques es aquel que mediante código inyectado ataca a la seguridad de un sistema emulando la

secuencia de llamadas al sistema de las aplicaciones legítimas.

El modelo que presentan los autores [95], consiste en un �ujo ordenado de llamadas al sistema

almacenadas dentro del sistema operativo S = {s1, s2, ...}. Cada llamada al sistema s ∈ S tiene

un valor de retorno rs y una lista de argumentos < as1, ..., a

sn >. Se debe indicar que los autores

no están teniendo en cuenta las relaciones entre las llamadas al sistema. Para cada llamada al

sistema creada por una aplicación se crea un per�l, comparando después del aprendizaje cada

llamada de esa aplicación a las syscalls del sistema si concuerdan con el per�l aprendido en la

primera fase.

En el modo de detección, la función de cada modelo es devolver la probabilidad de que

ocurra un determinado argumento basándose en el modelo aprendido previamente. Un valor de

baja semejanza (�likelihood�) de que una determinada característica es observable en un per�l

establecido indica la posible anomalía que se esta produciendo.

Para los autores del documento [95] sólo se considera ataque aquello que se salga de lo común

dentro de los posibles parámetros que se puedan tener en un argumento de llamada al sistema.

Si un ataque se realiza sin invocar a las llamadas del sistema con unos argumentos dentro de los

del modelo, no será reconocido. Para poder caracterizar las llamadas al sistema se aplican una

serie de modelos que ayudan a la identi�cación de anomalías:

127

1. Longitud de la cadena de texto. Generalmente los parámetros que se introducen en las

llamadas a las API's o al sistema ejecutivo tienen una longitud máxima de unos cientos de

caracteres y generalmente son legibles directamente por el ser humano. Si se introduce un

ataque dentro de este tipo de parámetros se acaban insertando caracteres no reconocidos

que aumentan los tamaños normales que se tenían dentro de cada parámetro.

2. Distribución de Caracteres. La forma en la que se distribuyen los caracteres dentro de las

cadenas de texto de los argumentos suele ser regular, aparte de ser generalmente carac-

teres legibles. Por normal la mayor parte de los caracteres se encuentran en un pequeño

conjunto de 256 caracteres: letras, números y unos poquitos caracteres especiales. Dentro

de los lenguajes naturales escritos, por ejemplo castellano o ingles, los caracteres tienen

una distribución de frecuencias de aparición uniforme. Es cierto que no se puede comparar

un lenguaje natural con el empleado por un sistema computerizado, pero tienen ciertas

semejanzas en la distribución de caracteres que bien pueden ser tenidas en cuenta.

3. Inferencia estructural. Es posible que el atacante haya conseguido mantener la acción

dentro de unos parámetros normales para la distribución de caracteres, y/o en una longitud

adecuada a la �normalidad� de las longitudes de cadenas de texto. Para poder capturar

adecuadamente este tipo de ataques se realiza el análisis de la estructura de argumentos,

que no es más que la gramática de expresiones regulares que puede emplear ese argumento

en concreto. La inferencia estructural es el proceso por el cual se obtiene esta gramática.

4. Buscador de Tokens. El objetivo del localizador de tokens es determinar si los valores de

determinados argumentos de llamadas al sistema se pueden resumir en un conjunto de

alternativas posibles reducido. Esto se debe a que generalmente una aplicación pasa a

menudo valores idénticos, como �ags y handlers, en los argumentos de las syscalls. Cuando

un ataque cambia el �ujo normal de ejecución y consigue saltar al código malicioso propi-

amente dicho, estas restricciones son violadas.

Finalmente para homogeneización de los resultados de los diferentes motores se emplea una

clasi�cación basada en redes bayesianas que tiene la siguiente estructura:

128

Figure 2.47: Arquitectura bayesiana del sistema de detección de anomalías para host propuestoen [95]

Siguiendo la línea de investigación abierta para superación de los sistemas de detección más

utilizados basados en detección de desviaciones, hay autores que clasi�can estos sistemas como

�caja blanca�, �caja negra� o �caja gris� [141]. Para discernir los sistemas y poder clasi�car-

los se valen de la información que usan para construir el modelo mediante el que realizan la

comparación:

Los detectores de caja negra emplean únicamente el número de la llamada al sistema

utilizada. Potencialmente estos detectores pueden hacer uso de los argumentos en esas

llamadas.

Los detectores de caja gris extraen además información en tiempo de ejecución a medida

que las llamadas al sistema se van produciendo.

Los detectores de caja blanca extraen el modelo directamente desde el código fuente o del

binario.

Los detectores de caja negra y caja gris ya han sido comentados en el documento. Los detectores

de caja blanca se basan en el concepto de falsos positivos cero, dado que siempre indican una

posible intrusión. Si bien estos detectores no son siempre apropiados, en principio debido a que

el código fuente no es siempre accesible, además que el hecho de realizar un análisis estático es

129

complejo por causas externas: ofuscación, sistemas de protección digital, packers59... Otro incon-

veniente de las cajas blancas son los programas que se cambian a sí mismos, muy comúnmente

usados en técnicas víricas.

En el paper [141] exponen una nueva técnica que denominan grafo de ejecución, que es técnica

pionera juntando las tres cajas. Se trata de construir un modelo que acepte las mismas secuencias

de llamadas al sistema pero con las bases de partida de las cajas blancas. Los autores denominan

a la secuencia de observaciones como �ejecución�, basándose en llamadas a API's intermedias o

a syscalls directamente de sistemas UNIX, en los que se va apilando/rellenando los parámetros

en la pila para hacer la llamada o en los registros para solicitar la interrupción directamente.

Así mismo en la misma traza de ejecución se anexan los valores de retorno y las direcciones de

retorno que se requieran. Finalmente el concepto de grafo de ejecución, que se construyen en base

a las observaciones de ejecución explicadas con anterioridad, consta de pares de identi�cación

de llamadas al sistema consecutivas y las direcciones de retorno de la pila cuando se realiza la

llamada en sí misma. Dado que cada una de las direcciones devueltas revela información sobre

la estructura de llamadas del sistema, se puede considerar una aproximación a la terminología

de caja blanca.

Figure 2.48: Código fuente y grafo de ejecución presentado en el paper [141]

2.4.8. Visualización e identi�cación del contexto de las intrusiones desde las

trazas de llamadas al sistema

Los sistemas de detección basados en anomalías son muy útiles pues son capaces de detectar

técnicas de intrusiones nuevas que no han sido analizadas y que no tienen �rmas conocidas.

Sin embargo esta capacidad conlleva el problema de la posibilidad de generar falsos positivos.

Esto es debido a que el análisis de la normalidad se lleva a cabo mediante el análisis del funcio-

namiento del programa y comportamientos normales pueden quedar fuera de éste análisis. La

mayoría de las técnicas tratan de generalizar el comportamiento normal para modelar mejor este

59 Un packer es un programa, generalmente comercial que se encarga de impedir que se pueda realizar ingenieríainversa en los programas binarios que se distribuyen.

130

tipo de conducta. Aun así este hecho implica que se contemplará mayor parte de una posible

pauta intrusiva. La identi�cación del contexto de la intrusión60 puede ayudar signi�cativamente

a aumentar la tasa de detecciones y a reducir los falsos positivos generados [402].

Flujo de trabajo del Identi�cador del contexto de intrusiones (ICI)

La adeshión de un módulo de identi�cación del contexto de intrusiones consiste en colaborar

con el motor de análisis de anomalías, realizando un aprendizaje o�-line, (es probable que al

módulo ICI le lleve un tiempo considerable determinar los contextos de intrusiones), en el cual

cada vez que salte una alarma el módulo ICI analizará el contexto y determinará si ésta era

un falso positivo o no. En caso de serlo la secuencia que ha hecho saltar la alarma debería

ser añadida al sistema inteligente de detección de intrusiones como parte del comportamiento

normal, evitando de esta manera futuros falsos positivos por el mismo motivo.

Ésta imagen detalla el el proceso en el que estaría involucrado el módulo ICI [402]:

Figura 2.49: Arquitectura de un sistema de detección de intrusiones sin (izq) y con (dch) unmódulo de identi�cación del contexto de intrusiones (ICI)

1. Todos los eventos procesados por el motor de análisis son copiados al móludo ICI para que

los guarde en un bu�er de tamaño prede�nido.

2. Toda alarma generada por el motor de análisis también es enviada al módulo ICI.

3. El módulo ICI extrae el contexto de la intrusión de la alarma, y más adelante lo procesará,

visualizará y/o lo agrupará.

4. El módulo ICI busca contextos de intrusión ya identi�cados similares.

5. Un experto en seguridad analiza el contexto de la intrusión y decide si la alarma ha sido

un falso positivo o no y el nivel de con�anza teniendo en cuenta los contextos existentes.

6. El vector ICI (alarma,decisión,con�anza) de la alarma es enviado al motor de análisis y/o

a los sistemas de respuesta.60En la detección de intrusiones basada en anomalías, el contexto de la intrusión que corresponde a una alarma,

son las huellas auditadas que se encuentran fuera del modelo normal del comportamiento las que hacen saltar laalarma

131

7. El motor de análisis a�na el modelo de comportamiento normal utilizando el vector obtenido

del ICI para evitar volver a dar el mismo falso positivo.

8. Los sistemas de respuesta activan diferentes estrategias en base al vector ICI.

Otras utilidades para el ICI

Además de la capacidad para reducir los falsos positivos, el módulo ICI puede ser utilizado

como una herramienta para analizar tareas como las que se enumeran a continuación:

1. Para fortalecer la correlación de alertas con las técnicas de detección de anomalías ya que

una alerta no puede determinar consistentemente una intrusión y el contexto de la intrusión

es capaz de mostrar las razones exactas.

2. Para estudiar las características de las intrusiones y mejorar después en base a la informa-

ción obtenida la e�ciencia del experto y proponer nuevas técnicas de análisis.

3. Para aplicarlo en otros campos de la intrusión como el estudio forense.

Visualizando y analizando el contexto

Sabemos que las anomalías en una secuencia de llamadas intrusivas estarán indicadas por un

set de secuencias extranjeras. Por tanto sería de gran ayuda visualizar dicha secuencia no propia

del programa en el esquema del ICI. El tamaño de la ventana aplicado para dicha aplicación

también será crítico ya que en el caso de que la secuencia extraña sea mayor que el tamaño de

la ventana, ésta no será totalmente detectada. En los grá�cos producidos para la visualización

del contexto de la intrusión la longitud de todas las secuencias intrusivas deben ser mostradas

de modo que se conozca si existe la posibilidad de detectarlas completamente o no en base al

tamaño de la ventana. Este tipo de grafo llamado Grá�co de secuencias extranjeras o anómalas

[402] (FSG Foreing secuence graph).

Finalmente se deberían tratar de identi�car secuencias anómalas mínimas (MFS) y los eventos

con los que están asociadas para que sean identi�cados como parte del contexto. Para lograrlo,

los datos pueden ser analizados mediante dos métodos:

1. Separando los datos en bloques más pequeños y evaluando cada bloque.

2. Evaluando todo evento que se encuentre en los datos.

El primer método puede llegar a romper las secuencias anómalas, por lo que la utilización del

segundo método es más acertada.

La siguientes imágenes muestran un ejemplo [402] de visualización de un FSG. Los datos

provienen de la Universidad de Nuevo México y también han sido utilizados en [347, 374]

132

Figura 2.50: Set de datos utilizados para el FSG

Para analizar las características de cada intrusión, su set de datos, incluso siendo en el mismo

proceso es tratado como set de datos individual puesto que cada intrusión genera sus propias

características de contexto en los rastros revisados.

Figura 2.51: Ejemplo de FSG para diferentes procesos

133

Para éste grá�co FSG, el número de secuencias anómalas en cada set de datos es representativo

y la mayoría de las intrusiones pueden ser detectadas aplicando un tamaño de ventana adecuado.

Otro fenómeno signi�cativo es que las intrusiones no generan secuencias anómalas en la primera

fase (excepto en la sub�gura b ). Por ejemplo en la imagen (a), tras 600 llamadas al sistema se

han generado secuencias de llamadas anómalas y esto de alguna forma es indicador de que existe

un periodo de �calentamiento� para las intrusiones, al menos para aquellas que son detectadas

mediante sistemas basados en anomalías.

Además en las tres instancias de �sunsendmail� en la sub�gura (g) se genera el mismo grá�co

FSG. Esto quiere decir que tienen las mismas características de intrusión. Al mismo tiempo, para

las diferentes instancias de la misma intrusión en las sub�guras (a),(c),(f) o (i) sus grá�cos FSG

también son similares. Este fenómeno puede bene�ciar investigaciones en las técnicas de detec-

ción de anomalías puesto que no es necesario crear técnicas especí�cas para detectar diferentes

ejecuciones de una misma intrusión.

Para diferentes intrusiones en un proceso, los grá�cos FSG son diferentes; para el proceso

�sendmail� desde CERT, el grá�co FSG de la intrusión en la sub�gura (c) es diferente del grá�co

FSG para la intrusión sm565a o sm5x en la sub�gura (d); el grá�co FSG de las intrusiones en el

mismo proceso �sendmail� (e), (f) y �sunsendmailcp� en la sub�gura (g) también son diferentes

entre si. Este hecho prueba que no existen estrategias generales para detectar todas las intrusiones

en un proceso, y que las estrategias de técnicas especí�cas de detección son necesarias para

detectarlas.

Identi�cando el contexto de las intrusiones: MFSs

Las secuencias anómalas mínimas en los rastros auditados son una de las características

producidas por una intrusión, lo cual es utilizado por detectores de anomalías para detectar la

intrusión. Como se ha mencionado antes, los MFS son el contexto de las alarmas. Basado en

la identi�cación del contexto de la intrusión en los set de datos, sus estadísticas numéricas son

resumidas en las siguientes tablas:

134

Figura 2.52: Número de Secuencias Anómalas Mínimas (MFS) no duplicadas en todos los set dedatos intrusivos

Figura 2.53: Secuencias Anómalas Mínimas (MFS) compartidas por la misma intrusión en elmismo proceso

Del número total de secuencias anómalas mínimas en cada set de datos intrusivo, se puede

inferir que:

1. Que con un tamaño de ventana igual a 2, es su�ciente para detectar la mayoría de las

intrusiones a excepción de la instancia �decode-280�.

2. Que del grá�co �Ejemplo de FSG para diferentes procesos� mostrado anteriormente y de

las estadísticas de la estancia de la intrusión �decode-280�, se observa que la longitud

mínima de la MFS es 6. Desde su índice posicional, se puede fácilmente encontrar que

135

éste corresponde a la secuencia �2-95-6-6-95-5�. El siguiente listado muestra todas las MFS

acaecidas en las dos instancias decodi�cadas y las correspondientes llamadas al sistema:

decode-280 / proceso 283: 2-95-6-6-95-5 ; decode-314 / proceso 317: 112-6, 6-19, 2-95-1,

2-95-6-6-95-5.

3. Que las diferentes ejecuciones de una intrusión comparte la mayoría de las secuencias

anómalas mínimas (tabla inferior). Especialmente, las diferentes ejecuciones de �sunsend-

mailcp� tienen el mismo set de secuencias anómalas mínimas. Esto es útil para las inves-

tigaciones en técnicas de detección de anomalías puesto que la diversidad en diferentes

ejecuciones de la misma intrusión, es limitada por lo que no es necesario desarrollar un

diseño especí�co para cada una de ellas. Al mismo tiempo, fortalece la a�rmación de que

los grá�cos FSG son especí�cos para cada intrusión y que las diferentes ejecuciones deben

tener las mismas características (contexto de intrusión).

Por último la información de las tablas debería disuadir posibles ataques del tipo mimicry [372] y

del paradigma de ocultamiento de información [348], visto el gran número de secuencias anómalas

mínimas reportadas, en especial, para la intrusión de �bu�er over�ow�.

2.4.9. Modelación de llamadas al sistema mediante ventana deslizante

Este método extiende las primeras investigaciones [126] en la detección de anomalías en

llamadas al sistema para la detección de intrusiones, incorporando tamaños de ventana dinámicos.

El tamaño de la ventana es la longitud de la subsecuencia de una traza de llamadas al sistema

las cuales son utilizadas como la unidad básica para el modelado del comportamiento de una

aplicación o de un proceso. Se presentan dos métodos para la estimación óptima del tamaño

de la ventana basados ambos, en la disposición de datos para el entrenamiento [124]. El primer

método es un modelado de la entropía el cual, determina el tamaño óptimo de la ventana para

los datos. El segundo método es una función modeladora de probabilidad que tiene en cuenta el

contexto para establecer el tamaño de ventana. Un tamaño de ventana dependiente del contexto

está motivado por el hecho de que las llamadas al sistema son generadas por los procesos.

Modelo de entropía

Se puede utilizar un marco teórico de información para escoger el tamaño de ventana óptimo

para las llamadas al sistema. En este marco, se estima cual de los diferentes tamaños de ventana

realizará mejor la ordenación de los datos mediante computación. Una descripción detallada

sobre la aplicación teórica de información a la detección de anomalías es presentada en [10].

La premisa básica para la detección de intrusiones es esa ordenación intrínseca en los da-

tos auditados que es consistente con el comportamiento normal, y distinto del comportamiento

anómalo. Se mostrará empíricamente que cuantos más datos ordenados existen mejor es el ren-

dimiento del modelo de detección de anomalías. El proceso de construcción de un modelo de

136

detección de anomalías debería por tanto involucrar una primera medida de orden de los datos

bajo los diferentes modelos. En este caso, se está interesado en medir la ordenación bajo diferentes

tamaños de ventana. Esta ordenación puede ayudar a elegir el mejor tamaño de ventana.

Para modelar las llamadas al sistema, se usa un modelo predictivo a través del cual la proba-

bilidad the �n� llamadas al sistema es estimada por las �n-1� llamadas previas. La forma en que

la predicción del modelo es entrenada, es que por cada �n-1� secuencia de llamadas al sistema

presentes en la traza61, se mantienen contadores de las siguientes llamadas. La predicción para

una determinada llamada al sistema dada una secuencia de �n-1� llamadas previas es, el número

de esa llamada dividido por el número total62 de llamadas. En este punto la longitud �n� es el

tamaño de la ventana del algoritmo que modela. Se medirá la ordenación de los datos para la

predicción del modelo bajo diferentes valores de �n�.

Se propone utilizar una medida teórica de los datos para medir la ordenación de los datos,

entropía condicional, para ayudarnos a elegir el valor de �n�. Cuantos más datos normalizados,

menor entropía.

La de�nición de la entropía condicional es:

Figura 2.54: Entropía condicional del modelo de ventana deslizante

donde P(x,y) es la probabilidad conjunta de �x� e �y�, y P(x|y) es la probabilidad condicional

de �x� dado �y�. En el contexto de la llamadas al sistema se deja que sea el set de llamadas

al sistema e sea el set de secuencias de llamadas al sistema de longitud �n-1�. �D�

será la notación para el total de secuencias en la traza, |(x,y) será el número de veces que se

origina la secuencia en �D�, y |D| será el total de números de secuencias en la traza. Se puede

de�nir entonces la probabilidad conjunta como . La probabilidad condicionada

de P(x|y) es la predicción de éste modelo. Desde que P(x|y) = 0 para una secuencia (x,y) que no

ocurre en la traza y la entropía condicional es aditiva, se puede representar la entropía condicional

para una ventana de tamaño �n� como63:

Figura 2.55: Entropía condicional para una ventana de tamaño �n�

61Una traza de llamadas al sistema es una secuencia de todas las llamadas al sistema que un proceso de unaaplicación dada realiza durante su tiempo de vida (ejecución).

62Para evitar probabilidades 0, al contador de cada tipo de llamada al sistema se le añade un pequeño valor.63La segunda ecuación puede ser computada de forma e�ciente

137

Grafo de llamadas de una aplicación

La motivación para una dependencia del contexto del tamaño de la ventana proviene del me-

canismo subyacente de cómo un proceso se ejecuta. Las llamadas al sistema en la traza dependen

de la trayectoria en la ejecución del proceso. Asimismo, la trayectoria de un proceso depende de

muchos factores como entradas recibidas o el estado del sistema donde se está ejecutando. Estos

factores determinan que trayectoria de ejecución seguirá el proceso en cada desviación posible.

Se podrían modelar todos los set de las posibles trayectorias de la aplicación utilizando �grafos

de llamadas64�. Los grafos de llamadas modelan la estructura de la aplicación y de�ne las posibles

trayectorias de la ejecución. Cada nodo representa una posible bifurcación del programa, y las

aristas están etiquetados con las llamadas al sistema que se dan entre los nodos. Existe un nodo

de comienzo de�nido para el grafo y al menos un nodo �nal. Es posible observar la trayectoria

de ejecución de un proceso a través de el grafo de llamadas del sistema asociado a éste y por lo

tanto una traza de llamadas al sistema sería simplemente las llamadas al sistema a lo largo de

la trayectoria de ejecución del proceso.

Se debe tener en cuenta que a pesar de que estos grafos existan para todos los programas,

obtenerlos es muy costoso debido a que variarán por el código fuente, por el compilador y por

el sistema operativo empleados. Debido a ésto, es prácticamente inviable asumir que se pueden

recrear los grafos a partir de las llamadas al sistema observadas. Aún no pudiendo determinar

el grafo especí�co de llamadas, se puede asumir que éste existe y utilizar ésto para motivar un

tamaño de ventana dependiente del contexto.

En la aplicación del grafo de llamadas al sistema a la detección de intrusiones, existe un set

de trayectorias de ejecución que corresponden a exploits65. El objetivo del método de modelado

de llamadas al sistema es el ser capaz de determinar si una secuencia de llamadas al sistema

corresponden a una trayectoria de ejecución normal, o si bien pertenece a la trayectoria de

ejecución de un exploit. Hay que tener en cuenta la longitud de la secuencia ha sido ajustada en el

contexto del grafo de llamadas y que con mayor probabilidad una secuencia larga puede identi�car

unívocamente una sección del grafo. Sin embargo, es usualmente demasiado larga para ajustarse

a una sola arista por lo que debe abarcar más ramas. Para que estas secuencias sean observadas

varias veces, los estados de los diferentes procesos donde tienen lugar las secuencias más largas

deberán forzar la trayectoria de ejecución para que coincida con estas ramas. Desgraciadamente

ésto puede generar ruido en el modelo.

Por otro lado, las secuencias más cortas abarcan menos ramas, sin embargo, pueden tener

lugar en múltiples puntos del grafo de llamadas resultando complicado determinar unívocamente

dónde surge la secuencia y, por tanto, si ésta pertenece a un trazado normal o a el trazado de

un exploit.

Idealmente, para una secuencia dada se pre�ere escoger aquella que sea la más corta y que

64Es un grá�co en el cual cada ruta de�ne una posible trayectoria de ejecución para un proceso o una aplicación.65Es el nombre con el que se identi�ca un programa informático malicioso, o parte del programa, que trata de

forzar alguna de�ciencia o vulnerabilidad de otro programa.[2]

138

identi�que unívocamente la rama del grafo donde se genere. Debido a que los nodos de las ramas

ocurren en lugares diferentes, la longitud óptima de una secuencia depende especí�camente de

las llamadas al sistema que ésta contiene. Por lo tanto, la longitud óptima depende del contexto.

La siguiente �gura muestra un ejemplo de grafo de llamadas al sistema:

Figura 2.56: Ejemplo de grafo de llamadas al sistema

Sparse Markov Transducers (SMT)

Los SMT[125] son utilizados para modelar trazas de llamadas al sistema estimando una

probabilidad �predictiva� dependiente del contexto motivada por el marco del grafo de llamadas.

Esta es la probabilidad de predecir la siguiente secuencia de llamadas al sistema dada la secuencia

previa. Una vez que se ha entrenado al modelo desde datos basados en la normalidad de un

proceso, se dispone de una distribución de probabilidad predictiva sobre dicho proceso. En la

fase de evaluación de secuencias de llamadas al sistema para determinar si entran dentro del

rango de la normalidad o si bien pertenecen a una traza generada por la ejecución de un exploit,

se computa cada la probabilidad predictiva para cada secuencia. Si la probabilidad obtenida

está por debajo del umbral establecido entonces la probabilidad de que la secuencia haya sido

originada por el proceso en funcionamiento normal es muy baja y la traza será evaluada como

exploit (anómala). El establecimiento del umbral de�ne la diferencia entre falsos positivos y el

ratio de detección del sistema

139

Detección basada en grafos N-gramas de llamadas al Sistema

Este tipo de sistemas basados en cadenas de Markov con N-gramas[246], se engloban en el

área denominada como computación inmunológica. para ello basándose en el documento de

Forrest [134] han introducido la idea de los n-gramas para caracterizar el modelo. Para poder

establecer el valor de la N se deben basar los cálculos en la granularidad de las llamadas al kernel,

que puede variar de un sistema operativo a otros.

La caracterización del comportamiento de un programa al igual de lo propuesto por Forrest

se basa en la recogida de segmentos deslizantes de longitud N. Los autores indican que un valor

de N grande implica un coste computacional alto y así mismo, un valor bajo será inválido para

la caracterización del sistema.

Otra de las partes importantes del estudio es la determinación del momento en el que se

puede dar el aprendizaje por �nalizado, dado que un aprendizaje incompleto puede llevar a

estimar una tasa de falsos positivos altos. Para poder estimar de forma correcta, durante el

principio del aprendizaje la base de datos crece rápidamente, sin embargo cuando la tasa de

incremento desciende y se hace muy pequeña, se puede decir que la base de datos ha convergido.

En este momento se podrá concluir con que la base de datos es completa y se puede dar por

�nalizado el aprendizaje.

Para poder construir la base de datos con cadenas de texto de múltiples longitudes se puede

tener en cuenta las siguientes consideraciones:

1. Se construye el árbol de su�jos para los N-gramas de los datos de aprendizaje para algún

valor que sea su�cientemente grande de N. N será el límite superior en la longitud de

cadenas multilongitudinales. Una máquina de estados �nita (FSM) mediante el algoritmo

�two-�nger� se puede construir de forma inmediata a partir de ese su�jo.

2. Se puede compactar el árbol de su�jos en un grafo dirigido acíclico mediante la fusión de

subárboles equivalentes.

3. Incluso se pueden llegar a anexar dos subárboles si son muy parecidos introduciendo una

pequeña variación en la forma de compactar.

En general un árbol de su�jos para una determinada cadena de caracteres contiene todos los

posibles su�jos de la misma, por lo que un árbol de su�jos de longitud m tiene m su�jos diferentes.

El árbol de su�jos para un conjunto de cadenas contiene cada su�jo de cada una de ellas. Así

mismo el árbol de su�jos para un conjunto de N-gramas puede construirse realizando primero el

árbol de las cadenas de entrenamiento y después entroncando cada rama con la profundidad N

deseada.

140

Figure 2.57: Un árbol de su�jos para el ejemplo de la cadena A B C C A B B C C A A B C

Cada nodo en profundidad k < N se denomina k-grama, los nodos hijos de profundidad N se

llaman N-gramas y el nodo raíz se rellena con una cadena vacía. Cada enlace se etiqueta con un

símbolo. Estos enlaces de su�jos conectan cada nodo a su su�jo apropiado más largo. Los su�jos

más largos proporcionan una forma de ir de un N-grama (un nodo hijo) al siguiente N-grama:

Figure 2.58: Árbol de su�jos con punteros de su�jos incluidos

A veces puede ser necesario incluso incluir un nodo denominado �Unknown_symbol� (nodo

141

desconocido) para poder contemplar los sucesos que se salgan fuera de lo normal en el modelo

representado por el árbol.

El algoritmo de�nido como detección de �two-�nger� es como leer la cadena �ABCCABBC-

CABABC� con dos dedos de la mano, dejas el dedo de la izquierda �jo al principio de la cadena

mientras desplazas el derecho. El desplazar un caracter el dedo derecho es como descender un

nivel en el árbol. Como se requiere que los dedos estén separados como mucho por N letras,

cuando se alcanza este momento se desplaza una posición el dedo de la izquierda, luego si en

la cadena para una longitud de 4 el máximo era ABCC, ahora se tendrá BCC para contin-

uar y posteriormente BCCA. Una anomalía en la cadena de llamadas al sistema requiere un

desplazamiento del dedo izquierdo.

Con esta representación del modelo de cadenas de llamadas al sistema se puede realizar el

mismo desarrollo efectuado por Forrest [134]para el análisis de las trazas del sistema y detección

de anomalías sobre las mismas.

Figure 2.59: Árbol �nal resultante de la compresión de la �gura anterior

Detección mediante el uso de Autómatas en Línea

Una nueva forma de abstracción en el comportamiento de un programa es la denominada

�Inlined Automaton Model (IAM)�[293]. Una vez se de�ne el modelo de comportamiento de

un determinado programa (accediendo al código fuente) se obtiene un grafo como el siguiente

ejemplo:

142

Figure 2.60: Ejemplo de código y representación de representación NFA

Si en base a lo anterior se materializa la forma en la que se ejecuta, como es el caso que se

esta planteando:

Figure 2.61: Ejemplos de implementación de IAM

La monitorización de los programas se basa en las llamadas a las librerías de funciones, con

lo que se tienen que desarrollar un sistema de interposición que se encargue de comparar las

llamadas con el modelo que se tiene. Los mayores problemas que se pueden plantear en este

tipo de situaciones son derivados de la recursividad. El hecho de que el código fuente de un

programa para diferentes casuísticas vuelva sobre sí mismo, deja un campo abierto para que se

tomen por buenas numerosos cambios en el mismo que darían un resultado de comportamiento

normal, teniendo un ataque en ejecución.

143

Figure 2.62: Ejemplo de recursividad y autómata generado.

Figure 2.63: Ejemplo de recursividad indirecta y autómata generado.

La granularidad es importante y un problema a considerar en este tipo de sistemas de de-

tección. Idealmente un IDS debería monitorizar todas y cada una de las sentencias ejecutadas

por el programa en estudio y de esa forma, validar cada instrucción de la máquina. Esto por lo

general no es posible, lo que lleva a afrontar el problema desde diferentes puntos de granularidad:

cuanto más gruesa la aproximación más sencillo será generar un ataque mimicry. Por ejemplo,

restringir exclusivamente los eventos observables a llamadas al sistema, signi�ca que las llamadas

a las librerías no son incluidas en el modelo. Numerosos ataques de �bu�er over�ow� y �format

string� han acaecido contra las propias librerías instaladas en el sistema operativo.

Detección mediante el uso de Autómatas en llamadas a la pila

Hay otro trabajo[233], que se basa a su vez en autómatas, que incluye en los mismos la

información de la pilla de llamadas. Este modelo se publicita como más potente sobre los que se

basan exclusivamente en secuencias de syscalls, detectando ataques adicionales que los anteriores

no detectan. Este método se basa en el descrito por Feng et al. [131], pero realizando su función

de forma más general. Aun basándose en autómatas de apilamiento de llamadas (HPDA), en vez

de hacer uso de una pila extra como en el modelo de PDA de Wagner and Dean [371], este motor

de análisis se basa exclusivamente en la pila del sistema operativo correspondiente. Cuando se

144

invoca a una syscall, el sistema de detección de intrusiones se activa y comprueba si se puede

pasar del estado en que se encuentra al siguiente. El modelo HPDA, parecido al PDA es una

5-tupla: (S,Σ, T, s, A) donde S es un conjunto �nito de estados y Sigma es un conjunto �nito

de símbolos de�nido como Σ = (Y xAddr) ∪ εsiendo Y = {Entry,Exit, Syscall}y Addr es el

conjunto de posibles direcciones de�nidas por el programa ejecutable. Las entradas de este tipo

de modelos son de los siguientes tipos:

Entrada. Es un punto de entrada para las llamadas del sistema. La dirección asociada es

la dirección de retorno de esta función.

Salida. Es un punto de salida de una función de llamada del sistema. La dirección asociada

es también la dirección de retorno de esta función.

�Syscall� es la invocación de una llamada al sistema, donde la dirección asociada es la

dirección de retorno de esta llamada.

ε es el string vacío.

T es el conjunto de funciones de transición (SxΣ → S)

s es el estado inicial (s ∈ S)

A es el conjunto de estados aceptados (A ⊆ S)

Figure 2.64: Ejemplo de código y modelo HPDA

2.4.10. Modelado de trayectorias de syscalls mediante en análisis del código

fuente

Uno de los inconvenientes a la hora de trabajar con sistemas de detección basados en anoma-

lías del comportamiento �normal� de las aplicaciones, es que no se dispone de todas las muestras

145

posibles. Ésto tiene como consecuencia que un número, (normalmente muy bajo si el entrena-

miento ha sido adecuado), de trayectorias de ejecución no es representado en el modelo creado

y por lo tanto, la posibilidad de generación de falsos positivos66 existe desde un principio. La

razón por la que un entrenamiento puede no se correcto, radica en la di�cultad técnica de obtener

todas las trayectorias posibles de una aplicación ya que su comportamiento se captura duran-

te su ejecución. Además en los sistemas basados en anomalías se �jan umbrales de normalidad

debido a que pueden existir comportamientos normales que pueden ser tan inusuales como un

comportamiento intrusivo. Mediante esta medida se evita pasar comportamientos intrusivos por

alto, pero en cambio se desligitimiza por segunda vez funcionamientos poco probables aunque

correctos de la aplicación.

Wargner y Dean [371] introdujeron por primera vez la idea de extraer del código fuente de

las aplicaciones un modelo de las trayectorias de ejecución. En ejecución cualquier llamada al

sistema que se desvía del modelo determinado estáticamente es considerada como una intrusión

y por lo tanto debe ser prohibida. Un grá�co de llamadas derivado de un grá�co de control de

�ujo (CFG) es un autómata �nito no determinístico (NFA) debido como construye el control en

forma de if − then− else67 y funciones call/return68. El grado de indeterminismo en un CFG

determina el número de trayectorias imposibles [371] y de esta manera latitud disponible para

los ataques de tipo mimicry [372], los cuales son capaces de evadir los sistemas que inspeccionan

patrones de llamadas al sistema generando los patrones de llamadas que la aplicación secuestrada

debería generar hasta que localizan el tipo de llamada al sistema que necesitan. Wagner [371]

y Gi�n [194] trataron de utilizar un modelo autómata de apilación inversa (PDA push-down

automaton) para tratar de mitigar el problema de trayectorias imposibles. Aunque el modelo de

PDA es más preciso que el de NFA, incurre en una costosa comprobación en tiempo de ejecución

[371, 194]. Sin embargo el desafío en la prevención de intrusiones basada en llamadas al sistema

es reducir la vulnerabilidad a ataques mimicry al tiempo que se minimiza la sobrecarga en tiempo

de ejecución.

Construcción del modelo de llamadas al sistema

Recientes sistemas de detección[371, 131, 319, 194, 374, 223, 309] de�nen modelos de compor-

tamientos normal utilizando la actividad realizada en tiempo de ejecución. Los primeros trabajos

como [319, 309] utilizan per�les para construir modelos de comportamiento normal. Sin embar-

go, generar los per�les requiere tiempo y puede producir modelos incompletos. La manera más

idónea de construir el modelo es aplicar un análisis estático para extraer patrones de llamadas

66Un falso positivo se da en el momento que el sistema de detección de anomalías detecta una trayectoria deejecución, (traza de llamadas al sistema), y genera una alerta siendo dicha trayectoria no intrusiva, (se encuentradentro del comportamiento normal de la aplicación).

67Sentencias condicionales que en base al resultado de la evaluación de una condición booleana (positivo onegativo) ejecutan unas acciones u otras.

68Instrucciones de llamada y retorno a una función. En el retorno se da el control a la siguiente instruccióndesde donde fue hecha la llamada.

146

al sistema de la aplicación.

Figura 2.65: Ejemplo de un programa en C asociado a un modelo de grafo de llamadas (NFA) yun modelo NDPDA.

La manera más sencilla de extraer un modelo de llamadas es partiendo del grafo de llamadas

propuesto por Wagner y Dean [371], quienes directamente deducen el grafo de llamadas del grafo

de control de �ujo (CFG) abstrayendo todo a excepción de las funciones y los nodos de llamadas

al sistema como se muestra en la sub�gura (B). El CFG resultante es un autómata de estados

no determinista de NFA debido a que las construcciones tales como if − then− else, los bucles

y las funciones son llamadas desde múltiples sitios.

Una limitación en el modelo de grafo de llamadas es el problema de rutas imposibles como es

indicado por la linea intermitente en la sub�gura (B), la cual surge porque la función f es llamada

desde dos lugares, V y W . El grafo permite una trayectoria imposible {v− > Entrada(f)− >

Salida(f)− > W ′}, lo cual no es posible. La consideración de este tipo de rutas como posi-

bles tiene como consecuencia que exista una posibilidad para un ataque de tipo mimicry [372].

Por ejemplo, si asumimos que ocurre un ataque por desbordamiento del bu�er en la función f

en la �gura (A), cuando f retorne la ejecución sería transferida al código intrusivo inyectado

mediante el desbordamiento. Al tomar el control, el código intrusivo generaría la secuencia de

llamadas {close(), exec(”/bin/sh”)}, logrando llevar a cabo el ataque pues la secuencia generadase corresponde con una de las posibles en el grafo (B). Esta limitación de los modelos de grafos

de llamadas es debido al hecho que sólo veri�ca el orden entre llamadas al sistema de�nidas como

la aplicación, pero no su emplazamiento.

Para eliminar las trayectorias imposibles, Wagner simula las operaciones de pila utilizando un

autómata no determinista de apilación inversa (NDPDA) [371] como se representa en la sub�gura

(C). La idea clave del modelo NDPDA reside en que cuando se encuentra una llamada desde

V , el estado de retorno correspondiente V ′ es introducido en una pila simulada antes de que el

147

control sea transferido, y es retirado cuando la llamada devuelve el control. Este funcionamiento

asegura que la función siempre retornará al lugar donde ha sido llamada sin importar los lugares

desde donde ha sido llamada. Sin embargo, para cada llamada al sistema entrante, el modelo

NDPDA debe calcular un set de posibles con�guraciones de la pila, basándose en las llamadas al

sistema previas. Este set de con�guraciones puede crecer inde�nidamente, especialmente en las

llamadas recursivas. A pesar de un complicado algoritmo para reducir la complejidad del modelo

NDPDA, el peor de los casos en tiempo de ejecución sigue siendo cúbico en la longitud de las

llamadas al sistema. Esto conlleva una alta e inaceptable sobrecarga en tiempo de ejecución para

aquellas aplicaciones que son de tamaño grande.

Los modelos PAID [223] y Dyck [195], utilizan inserciones de llamadas al sistema nulas para

transformar aplicaciones y eliminar el indeterminismo. Sin embargo el modelo Dyck puede produ-

cir sobrecargas impredecibles debido a una inserción desmesurada de llamadas al sistema nulas.

Más aun, el modelo Dyck es indeterminista debido a que no inserta llamadas al sistema nulas

en funciones recursivas. El modelo PAID[224], utiliza grafos inline para eliminar el problema de

trayectorias imposibles. Aunque PAID es un modelo determinista el modelo que genera es dos o

tres veces mayor y requiere extensas modi�caciones:

Figura 2.66: Proceso de llamada a getuid utilizando el modelo VSL.

Cuando getuid es llamado, el VSL previo es {r1, r2, r3}, el VSL actual es {r1, r2, r4}, y el

pre�jo de ambos VSL es {r1, r2}. Por tanto, tras consumir r3, el algoritmo pasa el estado actual

de S_setuid a C3′, y después a C4 tras consumir r4. Finalmente, introduce r4 en la pila y mueve

el estado actual a Entry(f4) [224].Feng propuso un modelo estático (VPS) [2], el cual explota el estado de la pila de usua-

rios para identi�car cada lugar de llamada al sistema. Para cada llamada al sistema entrante

extrae todas las direcciones que se encuentren actualmente en la pila para formar una lista

de pila virtual (VSL) y alimentar con ella a un autómata determinista de apilación inversa

o DPDA como se muestra en la �gura anterior. Los símbolos de r1 a r4 en el DPDA repre-

sentan la dirección de la llamada. Asumiendo que el VSL para una llamada al sistema pre-

148

via Sp es {a1, a2, ..., a1, b1, b2, ..., bm}, y el VSL para las llamadas al sistema actuales Sc es

{a1, a2, ..., a1, c1, c2, ..., cn}. La secuencia {a1, a2, ..., a1}es un pre�jo común para los dos VSL.

Sus algoritmos transversales utilizan {bm, bm−1, ..., b1} para generar los símbolos de entrada quesimulan operaciones de retorno de funciones, y {c1, c2, ..., cn} para generar los símbolos de entra-da que simulan operaciones de llamada a funciones. Tras la llamada a getuid en la �gura superior

el VSL para getuid es {r1, r2}. Asumiendo que el estado actual es S_setuid, el algoritmo utiliza

{r3} y {r4} para generar las siguientes operaciones transversales:

1. No consumir nada y mover al siguiente estado Exit(f3).

2. Sacar un elemento de la pila. Si el elemento en la parte alta de la pila es r3, mover el estado

a C3′.

3. Consumir r4 y mover el estado a C4.

4. Empujar r4 en la pila y mover hasta el estado Entry(f4).

5. Mover hasta el estado getuid cuyo contador coincide el contador de programa de la llamada

actual getuid.

Si todas estas operaciones son aceptadas por el modelo DPDA entonces la llamada al sistema

getuid actual es legítima.

Figura 2.67: Proceso de llamada getuid utilizando el modelo VPStatic.

Si getuid no es llamada, el modelo VPStatic no puede aceptar la llamada al sistema setuid

debiado a que el modelo no puede alcanzar el estado S−setuid desde el estado Entry(main). Lafunción f1en la sub�gura de la derecha (B) es llamada dentro de un bucle. El algoritmo VPStatic

actual no puede aceptar la secuencia de llamadas {setuid, getuid, setuid} desde que el algoritmo

sólo retorna al pre�jo del actual VSL previo.

El modelo VPStatic no puede manejar el indeterminismo debido a las sentencias if − then−else. Por ejemplo en la sub�gura superior (A), la llamada al sistema getuid en f2 no es siempre

149

ejecutada debido a que se realiza dentro de una sentencia if − then− else. Si getuid no es eje-

cutado, el modelo VPStatic genera un falso positivo cuando setuid es ejecutado. En el momento

que setuid es llamado el VSL previo es {} y el VSL actual es {r1}. Según el algoritmo, las únicas

operaciones que pueden generar para atravesar el autómata son:

1. Consumir r1, mover al estado C1

2. Introducir r1en la pila, mover hasta el estado Entry(f1).

3. Mover hasta el estado setuid cuyo contador coincide el contador de programa de la llamada

actual setuid.

Obviamente, tras la segunda operación, la tercera no puede ser aceptada por el autómata desde

que C2 es el único estado que se puede alcanzar desde el estado Entry(f1).VPStatic también falla al manejar el indeterminismo cuando se efectúan llamadas a funciones

desde bucles, como se muestra en la sub�gura (B) superior. Además aunque utiliza el estado de

la pila del usuario, no puede prevenir todos los ataques mimicry [224]. Por ejemplo un ataque de

mimicry podría llenar la pila de tal manera que llegaría a engañarle demandando una llamada al

sistema mediante una instrucción trampa, y recuperando el control y repitiendo el mismo proceso.

Esto es debido a que el modelo no tiene en cuenta la dirección de retorno de la instrucción trampa

y el atacante puede obtener el control tras la llamada a la instrucción trampa.

El modelo PAID utiliza una combinación de todas las direcciones de retorno en la pila del

usuario y la dirección de retorno de la llamada trampa que se encuentra en la pila del núcleo como

coordenada unívoca para cada instancia de llamada al sistema en la aplicación. Además utiliza un

algoritmo nuevo de grafo transversal que soporta backtracking69 para tratar con indeterminismos

creados por sentencias condicionales del tipo if− then−else y es tan e�ciente como el algoritmo

transversal DFA [224]. Finalmente para reducir más aún la vulnerabilidad debido al tamaño

de ventana por parte de ataque mimicry, PAID realiza un extenso y restringido análisis de los

argumentos de las llamadas al sistema, el cual, puede crear restricciones totales o parciales en los

argumentos de llamadas al sistema basado en �cheros de con�guración. Ésta habilidad, estrecha

los posibles valores de los argumentos en muchas de las llamadas al sistema susceptibles de ser

atacadas, tales como la open().

2.4.11. Solución de instrumentación mediante criptografía

El avance de las llamadas al sistema autenticadas [252] se basa en el hecho de introducir

dentro de misma una serie de parámetros extra: argumentos para control de políticas, argumentos

criptográ�cos que garanticen la integridad de la política y de los argumentos. Para poder realizar

este tipo de funciones y proteger los sistemas:

69Es un método de resolución automática de problemas mediante una búsqueda sistemática de posibles solu-ciones. Las soluciones no válidas se eliminan y no se vuelven a comprobar.

150

1. Transformar los programas para cambiar las llamadas al sistema con llamadas al sistema

autenti�cadas.

2. Revisión en tiempo real por parte del kernel para asegurar que cada llamada al sistema

esta dentro de la política que le corresponde.

Para empezar, instalación en el sistema, se analiza el binario de un programa por un instalador de

con�anza, quien primero generará la política que comprenda el comportamiento de cada llamada

al sistema usando un análisis estático y reescribe el binario de forma que cada syscall contenga

tanto la política como la validación criptográ�ca que necesite.

Figure 2.68: Instalación del programa

El segundo paso, comprobación de la syscall en tiempo real, se realiza por medio de una

intercepción en el kernel, que veri�ca el contenido criptográ�co utilizado, con lo que si todo es

correcto se permite la ejecución de la llamada y si no se obliga al cierre del programa solicitante.

Figure 2.69: Comprobación de las syscalls

2.4.12. Solución mediante virtualización para terminales móviles

En las especi�caciones de seguridad [11] [12] se explican los retos tecnológicos en esta ma-

teria para la siguiente generación de dispositivos móviles: medición de la integridad, control

criptográ�co de acceso para los procesos, autenti�cación de usuarios, etc. El objetivo es con-

seguir aumentar la seguridad existente en los dispositivos móviles. El documento [175] se centra

151

en la creación de instancias de sistemas operativos, donde los usuarios son capaces de ejecutar

aplicaciones nativas descargadas de redes libres.

Un dominio (una instancia de Sistema Operativo) es de�nido como un entorno de ejecución

aislado preparado para un grupo de aplicaciones. Esta separación entre dominios hace posible

la prevención de accesos ilegales al espacio de direcciones de otros dominios y limita la máxima

cantidad de recursos que pueden usar las aplicaciones de un dominio en concreto. Estos dominios

incluso pueden funcionar con diferentes sistemas operativos para terminales móviles: Symbian-

OS, µ− ITRON , Linux, etc.

La propuesta no se centra en el uso intensivo de recursos hardware como es el caso de los

dominios basados en hardware. La idea es la creación de dominios software, para el que un

software (VMM, Virtual Machine Monitor) se encarga de gestionar los diferentes SO, así como

de compaginar el uso de recursos hardware. Si no que como ni la solución pura de virtualización

por software, ni la solución de implementar todo en hardware son del todo favorables se propone

una mezcla entre ambas aproximaciones. VIRTUS es una nueva propuesta de arquitectura de

un nuevo procesador con arquitectura de virtualización, creando un dominio hardware para

aplicaciones preinstaladas en un procesador y dominios software para aplicaciones descargadas

en otros procesadores para poder satisfacer los siguientes objetivos de diseño:

Seguridad más fuerte. Las aplicaciones preinstaladas en la siguiente generación de termi-

nales móviles deben ser protegidas de las aplicaciones descargadas.

Virtualización �exible del procesador. La siguiente generación de terminales móviles re-

querirá un número alto de dominios para instalar las aplicaciones descargadas. Se requiere

proporcionar en este tipo de sistemas, como en VIRTUS [175], un número ilimitado de

dominios software para los procesadores virtualizados.

Baja degradación en la funcionalidad. Es un requisito que el hecho de tener múltiples

dominios no degrade la funcionalidad del sistema en el trato con diferentes aplicaciones.

Poca interferencia en la funcionalidad. No debe existir interferencia entre las aplicaciones

preinstaladas y las aplicaciones descargadas. Una separación de aislamiento en los proce-

sadores virtuales soluciona el problema, dado que el dominio de aplicaciones preinstaladas

se ejecuta en un procesador diferente que el que se usa para las descargadas, impidiendo la

infección del software original.

Tamaño de código pequeño. Este requerimiento es intrínseco a la capacidad de proce-

samiento que se puede tener en este tipo de terminales móviles.

152

Figure 2.70: Imagen de la arquitectura de los nuevos procesadores para terminales de tercerageneración

Para poder lograr estos objetivos:

1. una solución puede ser tener máquinas virtuales (VMM) asimétricas a través de las cuales

se pueda integrar el dominio hardware con los dominios software.

Figure 2.71: Comunicación VMM asimétricos

2. Se requiere una comunicación entre dominios que permita que una aplicación corriendo en

un determinado dominio pueda comunicarse de forma criptográ�camente segura con otra

aplicación de otro dominio.

153

Figure 2.72: Comunicación dinámica inter-dominio

3. Así mismo debe resultar sencillo el trabajar con la virtualización para realizar desarrollos

efectivos en cuanto a esta tecnología.

Figure 2.73: ID de los registros del procesador lógico virtual

Listing 2.2: Hola esto es una prueba aquí

int main ( int argc , char ∗∗ argv ) {return 0 ;

3 }

2.5. Modelos de redes probabilísticas

2.5.1. Modelos de Redes Probabilísticas

Antes de comenzar a ver la de�nicion intuitiva de este concepto es aconsejable leer el ANEXO

RRBB.1 - Introducción de conceptos.

154

Redes Bayesianas

De�nición intuitiva Una red bayesiana, red de creencia o red de causalidad es una repre-

sentacion gra�ca de las relaciones causa-efecto dentro del dominio de un determinado problema.

Una descripcion mas formal se puede encontrar en [187].

De�ni�cion forma

Partiendo de un conjunto �nito de nodos X . Cada uno de ellos representa una variable, que

puede ser discreta o continua, aunque solo se van a manejar variables discretas por ser mas

sencillas. Esta relacion biunivoca entre nodos y variables nos premite emplear indistintamente

ambos terminos. Como se ha visto anteriormente los valores de una variable deben constituir un

conjunto exclusivo y exhaustiva.

Las redes bayesianas no necesitan suponer que los diagnosticos son exclusivos y exhaustivos, y

por tanto no es necesario tener una variable D que represente todos los posibles diagnosticos;

por ejemplo, en vez de una variable llamada D=Enfermedad, cuyos valores representasen los po-

sibles diagnosticos correspondientes a la �ebre: neumonia, amigdalitis, paludismo, etc., en la red

bayesiana tendriamos una variable Neumonia que puede tomar dos valores (neumonia-presente y

neumonia-ausente) o mas de dos valores (neumonia-ausente, neumonia-leve, neumonia-moderada

y neumonia-severa), dependiendo del grado de precision que necesitemos en el diagnostico , otra

variable Amigdalitis, Paludismo, etc. De este modo, la red bayesiana puede ofrecer dos o mas

diagnosticos a la vez (por ejemplo, amigdalitis-severa y neumonia-leve), lo cual era imposible con

el metodo probabilista clasico.

En el Anexo RRBB.2 - De�nciones previas a las redes bayesianas se introducen ahora algunas

de�niciones basicas sobre grafos necesarias para entender la de�nicion de red bayesiana.

De�nicion de red bayesiana

La propiedad fundamental de la red bayesiana es la separacion direccional de�nida en [186, 187]

como:

Separacion direccional. Dado un grafo dirigido aciclico conexo y una distribucion de prpobabili-

dad sobre sus variables, se dice que, hay separacion direccional si, dado un nodo X, el conjunto

de padres pa(X), separa condicionalmente este nodo de otro nodo subconjunto Y en que no hay

descendientes de X. Es decir:

P (x|pa(x), y) = P (x|pa(x))

155

Es habitual de�nir las redes bayesianas a partir de grafos dirigidos aciclicos (en ingles DAG,

de Directed Acyclic Graph). Es importante incluir la especi�cacion conexo por tres razones.

La primera, porque muchos de los algoritmos y propiedades de las redes bayesianas solo son

correctos para grafos conexos, por lo que es mejor incluir esta caracteristica en la de�nicion que

tener que añadirla como nota a pie de pagina en casos particulares. La segunda razon es que,

aun en el caso de tener un modelo con dos partes inconexas, podriamos tratarlo como dos redes

bayesianas independientes. Y la tercera, porque los modelos del mundo real con que se suele

trabajar son siempre conexos; si hubiera dos partes inconexas no se tendria uno sino dos modelos

independientes. En base a todo lo anterior se pueden caraterizar las redes bayesianas, así:

Red bayesiana. Grafo aciclico dirigido conexo mas una distribucion de probabilidad sobre

sus variables.

El término direccional hace referencia a la asimetria de dicha propiedad, que se mani�esta

en las siguientes propiedades de las redes bayesianas:

Si A no tiene padres entoces P (x|pa(x)) = P (x|∅) = P (x) y la ecuacion {b.i.1.b.1} se

traduce en P (e|a) = P (e) para cada nodo E que no sea uno de los descendientes de A; en

otras palabras, E es a priori independiente de A. En consecuencia, dos nodos cualesquiera

D y E que no tengan antepasado comun son independientes a priori.

Si D es descendiente de A y antepasado de H, y existe ningun otro camino desde A hasta

H, entonces estos dos nodos se dice que quedan condicionalmente separados por D:

P (h|d, a) = P (h|d)

Si tanto G como H son hijos de D y no tienen ningun otro antepasado comun este ultimo

separa G y H, haciendo que sean condicionalmente independientes:

P (g|d, h) = P (g|d)

En general, la independencia a priori o condicional de dos nodos se pierde al conocer cualquiera

de sus descendientes comunes, ya que en este caso la propiedad de separacion direccional ya no

es aplicable.

Semántica de las redes bayesianas Se han de�nido hasta el momento las redes bayesianas

desde un punto de vista matematico formal. La cuestión que se plantea ahora es su semantica, es

decir, ¾que interpretacion se le puede dar a una red bayesiana? ¾Como se corresponde un modelo

con el mundo real? ¾Por que se puede hablar de causas y efectos en una red bayesiana?

Esta cuestion esta ya parcialmente respondida en la presentacion intuitiva, que fue introducida

antes de la de�nicion formal de red bayesiana precisamente para mostrar que los conceptos

y axiomas introducidos no pareciesen arbitrarios, sino que responden a las propiedades de la

156

causalidad, segun nuestra concepcion intuitiva del mundo real. Es importante señalar que la

estructura de la red, por si misma, aporta gran cantidad de informacion cualitativa. En efecto,

un arco XY indica, ya antes de conocer el valor concreto de la probabilidad condicional, que

hay una correlacion entre ambas variables: el valor que toma X in�uye sobre la probabilidad

de Y , y viceversa. Es lo que se ha dado en llamar in�uencia causal directa. Tal es la relacion

que existe, por ejemplo, entre el pais de origen y el paludismo, o entre el paludismo y la �ebre.

Profundizando un poco mas, se oserva que la existencia de un camino entre dos variables X e Y

, con variables intermedias Z, indica que hay una in�uencia causal indirecta entre ambas.

Tal como se ha discutido en la presentacion intuitiva de las redes bayesianas, cuando el sentido

comun, basado en la experiencia, dice que la in�uencia de una variable X sobre uno de sus efectos

Y1 (por ejemplo, del paludismo sobre la prueba de la gota gruesa) no depende de cuales han sido

las causas o mecanismos que han producido X, ni depende tampoco de si X a dado lugar a otros

efectos, entonces la red contendra un arco desde X hasta Y1 , y no habra ningun arco que conecte

Y1 con las demas variables. Por tanto, la ausencia de arcos es tambien una forma de expresar

informacion. El hecho de que Y1 depende solamente de su causa, X, se traduce matematicamente

diciendo que, conocido el valor de X, la probabilidad de Y1 es independiente de los valores que

toman esas otras variables, o dicho de otro modo, X separa Y1 de dichas variables. Se empieza a

ver aqui la relacion entre el concepto de padre y el de causa, entre el de hijo y el de efecto, entre

el de arco y el de in�uencia causal directa, entre el de independencia en los mecanismos causales

y el de independencia probabilista.

En este punto es donde se mani�esta la importancia del sentido de los arcos y su relacion con

la idea de causalidad. Volviendo al ejemplo del paludismo, el hecho de que las variables Pais-de-

origen y Tipo-sanguineo no tengan ningun padre comun signi�ca que son a priori independientes,

es decir, que el pais no in�uye en el tipo sanguineo y viceversa, de modo que, si no hay mas

evidencia, no se puedeobtener ninguna informacion sobre el pais de origen a partir del tipo

sanguineo, ni viceversa. Sin embargo, el hecho de que ambas variables tengan un hijo comun

signi�ca que, una vez conocido el valor de ese nodo, surgen correlaciones entre los padres70. Se

puede decir, usando la terminología de [186], que el camino entre U1 y U2permanece bloqueado

hasta que sea activado por la llegada de informacion sobre X o sobre alguno de sus descendientes.

Para el caso de los efectos de una variable ocurre precisamente lo contrario: todo medico

sabe que hay correlacion entre la �ebre y el test de la gota gruesa. Sin embargo, tal como se

discute en la De�ncion Intuitiva, la correlacion desaparece cuando se averigua si el paciente tiene

o no tiene paludismo. Es decir, el camino entre Y1 y Y2 está activado en principio, y se bloquea

solo al conocer el valor de X. De esta asimetria entre padres e hijos, re�ejo de la asimetría que

existe en el mundo real entre causas y efectos, procede el nombre de separacion direccional. Por

tanto, hay dos formas de justi�car los enlaces que se introducen u omiten al construir una red.

La primera es de naturaleza teorica: se forma un modelo causal a partir de la experiencia de un

70La correlación que aparece entre las causas se aprecia más claramente en el caso de una puerta OR

157

especialista y se trazan los arcos correspondientes al modelo; la relacion que se ha discutido entre

los mecanismos causales y las propiedades matematicas de independencia permite fundamentar

el modelo. El otro camino para justi�car la red consiste en realizar una comprobacion empirica

a partir de un conjunto su�cientemente amplio de casos, utilizando las herramientas estadisticas

que se emplean habitualmente para detectar correlaciones.

Hay otro punto relativo a la semantica de las redes bayesianas, que se va a mencionar solo

brevemente, pues aun esta muy discutido. Es el que se re�ere al debate entre los que de�enden que

las redes probabilistas pueden expresar causalidad y los que sostienen que estas solo expresan

correlaciones entre variables. En realidad, no se trata de un debate limitado al campo de las

redes bayesianas, sino que la existencia de la causalidad es una cuestion que se han planteado

matematicos y �losofos por lo menos desde el siglo XVII, a partir de las teor1as de Hume.

Para no entrar en esta cuestion se citaran solamente tres trabajos, los de [188] y [397] y el de

[113], que muestran como recientemente han surgido argumentos matematicos para defender la

interpretacion causal frente a la meramente correlacional.

En resumen, lo que se ha intentado mostrar en esta seccion es que la informacion cualita-

tiva que expresa la estructura de una red bayesiana es mas importante aun que la informacion

cuantitativa, como lo demuestra el hecho de que se han construido redes cualitativas [273, 274],

capaces de razonar a partir de las propiedades de independencia de las redes bayesianas, inclu-

so en ausencia de valores numericos. Por este motivo, [3] ha sugerido en nombre de redes de

independencia (independence networks) como el mas adecuado para las redes bayesianas.

Propagacion en poliárboles El algoritmo para poliárboles que se presenta en esta sección,

basado en el paso de mensajes π yλ fue desarrollado por [153] a partir del que Pearl había

propuesto para árboles en [185]. Sin embargo, la principal limitación del algoritmo de Kim y

Pearl es que no permite tratar los bucles que aparecen inevitablemente al desarrollar modelos

del mundo real, por lo que en sí mismo resulta de muy poca utilidad y los constructores de

redes bayesianas. Recurren a otros que, aun perdiendo las ventajas de éste, son aplicables a

todo tipo de redes bayesianas. Sin embargo, aquí se va a estudiar con detalle por dos razones.

Primera, por su sencillez y elegancia, que permitirá comprender mejor las propiedades de las redes

bayesianas. Y segunda, porque el algoritmo de condicionamiento local [114], aplicable también

a redes múltiplemente conexas, es una extensión de éste, que se basa en los mismos conceptos y

de�niciones. Para comprender mejor el desarrollo matemático que se va a realizar, puede ser útil

al lector repasar la de�ncion intuitiva, en que aparecen sencillos ejemplos numéricos que explican

por qué se introducen las de�niciones de π y λ cómo se propaga la evidencia.

Una de las propiedades fundamentales de un poliarbol es que hay un unico camino entre cada

par de nodos. En consecuencia, la in�uencia de cada hallazgo se propaga hasta un nodo X bien

a traves de los padres o a traves de los hijos de éste, por lo que para cada nodo X se pude hacer

una particion de la evidencia (o conjunto de hallazgos) en dos subconjuntos tales que:

158

e = e+X ∪ e-X

e+X ∩ e-X = ∅

Donde e+X representa la evidencia �por encima de X� y e-X la evidencia �por debajo de X�

en el sentido antes mencionado. De forma similar, la eliminacion de un enlace XY divide la red

�y por lo tanto tambien la evidencia- en dos partes, una que se queda �por encima� del enlace

y otra que queda �por debajo�. Se llamaran e+XY y e-XY respectivamente. Al igual que en el caso

anterior se cumple que:

e = e+XY ∪ e-XY

e+XY ∩ e-XY = ∅

En base a la particion de evidencia podemos establecer las siguientes de�nciones:

π(x) ≡ P (x, e+X)

λ(x) ≡ P (e-X |x)

πX(ui) ≡ P (Ui, e+UiX

)

λYi(x) ≡ P (e-XY j|x)

Figura 2.74: Esquema de la propagación en poliárboles

El sentido de estas de�nciones es el siguiente:

1. π(x) indica qué valor de X es mas probable según la evidencia relacionada con las causas

de X, es decir, segun la evidencia �por encima� de X.

2. λ(x) Indica que valor de X explica mejor los hallazgos correspondientes a los efectos de X,

es decir, la evidencia por debajo de X.

159

3. πX(u) Indica qué valor de U es mas probable según la evidencia �por encima� del enlace

UX.

4. λYi(x) Indica qué valor X explica mejor la evidencia �por debajo� del enlace XY.

Antes de concluir esta seccion es conveniente señalar que las de�nciones anteriores, aunque

tomadas del libro de Pearl [187] se han modi�cado de acuerdo con la propuesta de [278].

Un caso particular: Redes tipo Naive

Introducción

Los modelos bayesianos Naive (red naive a partir de ahora) se denominan naive (ingenuo) por

la hipótesis de la que parten. Son utilizadas extensamente en la clasi�cación de muestras de

todo tipo [22, 284, 245], llegando incluso a plantearse estructuras jerárquicas en su interior:

Augmented Naïve Bayes [61]. Hay numerosos estudios actuales para la aplicación y solución de

problemas más complejos mediante creación de Redes en Árbol Aumentadas (TAN), Multiredes

autónomas en las ramas, redes selectivas y variantes parecidas [135, 145, 67].

Una de las aplicaciones más usadas es la gestión de Spam en correos electrónicos mediante una

clasi�cación de textos, tras una temporada de aprendizaje se observan unos resultados

perfectamente válidos con una baja tasa de error71.

Se pueden encontrar aproximaciones que indagan en la aplicación de esta algorítmica en aras

de la Seguridad en base a Anomalías [318]. Las redes activas72 pueden proporcionar una solución

real a la problemática de seguridad haciendo un uso cooperativo de los recursos para análisis por

medio de diferentes técnicas. En este caso se trataría de clasi�car como normal o como anómalo

los sucesos que se ocasionan en tiempo real dentro de una red corporativa.

Siguiendo en la línea de seguridad hay otros trabajos que siguen en la línea de clasi�cación,

pero esta vez en base a determinados parámetros de los paquetes (datagramas / segmentos) o

incluso del contenido de los mismos (ejecutables, imágenes . . . ). Un ejemplo se puede ver en la

referencia [176].

Otras aproximaciones que hacen uso de este tipo de redes pueden ser aquellas en las que se

trata de clasi�car un tipo de comportamiento en base a eventos. Estas aproximaciones tienen en

cuenta una serie de parámetros, y en base al valor que tomen los mismos, pueden decidir si el

comportamiento es anómalo o dentro del margen normal [217].

71SpamBayes, proyecto localizado en la sede web: . Solución para el reconocimiento de spam en correo electrónicoiniciada por Paul Graham.

72Redes caracterizadas por poder dirigir el �ujo de información a través de diverso hardware programable porsus usuarios o terceras partes.

160

Explicación en detalle

Las redes Naïve Bayes parten de la hipótesis de que cada variable Xi es condicionalmente

independiente del resto dado un cluster de varibles con el mismo padre C. Mediante esta

hipótesis la distribucion de probabilidad se puede representar e�cientemente como el producto

de varias distribuciones más simples:

P (X1,X2,..., Xn, C) = Pn

(c)i=1P (xi|C)

Una red naive es un caso especial de red bayesiana sobre las variables X1,..., Xn y C, en la

que el padre de cada variable Xi es C y C no tiene padres. El aumento e�ciencia viene por el

uso de esta estructura restringida.

Para el uso más común, la clasi�cacion, se tiene que C representa la clase que se debe predecir

y Xi representan los atributos observables. Por ejemplo, en un �ltro naive anti-spam, la C puede

represntar la clase �spam� y �no-spam� y Xi puede representar si la i-esima palabra está presente

en el mail tratado. Las distribuciones componentes se pueden aprender a partir de datos de

entrenamiento simplemente mediante el conteo de las ocurrencias de una palabra en las etiquetas

�spam� y �no-spam�. En este ejemplo, así como en muchas aplicaciones de las redes naive la

hipotesis �ingenua� es claramente falsa: las palabras presentes en un email depende de otras

tanto en spam como en email legitimos. Sin embargo, estos modelos tienden a realizarse bien en

la práctica y el análisis teórico ha demstrado que es óptimo [111].

Naive Bayes tambien se utiliza en el clustering, donde el objetivo es aprender la estructura

subyacente de los datos. Al contrario que en la tarea de clasi�cacion, C representa una variable

cluster que nunca se observa directamente. En muchos casos el numero de clusters presentes es

desconocido y se debe inferir [66].

Los modelos de clustering normalmente se aprenden mediante el algoritmo EM en un proceso

iterativo que consta de dos pasos como explica [104] y más adelante en esta memoria.

La estimacion Naive Bayes es la aplicación de los modelos naive Bayes a los problemas

generales de aprendizaje e inferencia, el caso de la inferencia se explica más adelante.

Hasta aquí se ha realizado una presentacion de lo que son las redes bayesianas como con-

cepto, a partir de este punto se procede a describir las potentes funcionalidades de este arti�cio

matematico.

Adicción y eliminación de nodos en caliente.

Con la ayuda de un experto en la materia, J.M. Gutierrez se plantea la siguiente evolución de

una red naive. Si se tiene de partida una red como la siguiente:

161

Figura 2.75: Ejemplo de red naive

La probabilidad para la clasi�cación en función de los dos nodos que aparecen en la �gura es

la que sigue:

P(Padre) = P(Padre_a_priori) · P(Hijo1 / Padre) · P(Hijo2 / Padre)

Caso de que se quiera quitar un nodo dejando la red Naive con sólo un hijo, para calcular el

estado del padre en todo momento se tendría en cuenta únicamente la parte de la red de la que

se disponen datos:

Figura 2.76: Ejemplo de sustración de nodos en red Naive

P(Padre) = P(Padre_a_priori)· P(Hijo1 / Padre)

Igualmente, caso de que se quiera añadir un hijo más para el cómputo correspondiente del

estado del padre:

162

Figura 2.77: Ejemplo de adición de un nodo a una red Naive

P(Padre)=P(Padre_a_priori)·P(Hijo1/Padre)·P(Hijo2/Padre)·P(Hijo3/Padre)

Aprendizaje

Introducción al aprendizaje en redes bayesianas

Existen dos tipos de aprendizaje:

Estructural, que se re�ere al aprendizaje de la estructura (dependencia) grá�ca del grafo,

es decir, determinar las aristas a incluir en el grafo.

Paramétrico, que se re�ere al aprendizaje de la estructura parametrica, es decir, probabili-

dades. En el leguaje de los estadisticos, el aprendizaje parametrico se denomina estimaca-

cion.

En este punto se van a explicar en detalle ambos tipos de aprendizaje asi como los algoritmos

usados en ESIDE-Depian para implementarlos.

Por otro lado, según [57] todo método de aprendizaje consta de 2 elementos:

Una medida de calidad, que se utiliza para decidir cual es mejor de un conjunto de redes

bayesianas candidatas. Esto es una media global de la calidad, ya que mide la calidad de

la red bayesiana en su totalidad, es decur ambas, la calidad de la estructura gra�ca y la

calidad de los parametros estimados.

163

Un algoritmo de busqueda, que se usa para seleccionar un pequeño subconjunto de redes

bayesianas de alta calidad, del que se selecciona el mejor. Hay que darse cuenta que de

todas las posibles redes, incluso para un pequeño numero de variables , es extremadamente

grande y es virtualmente imposible determinar la calidad de todas las redes posibles.

Tambien en [57] se establecen las siguientes etapas para el aprendizaje estructural y

paramétrico:

Elegir la medida de calidad y el algorimo de busqueda.

Utilizar un algoritmo de busqueda para seleccionar un subconjunto de redes bayesianas

con calidades altas. Esto requiere estimar los parametros de las redes seleccionadas usando

metodos de estimacion y evaluando las calidades de todas las redes bayesianas en el conjunto

elegido.

Por ultimo, seleccionar la estructura de la red con mayor calidad del conjunto anterior.

2.5.2. Aprendizaje Estructural

El consiste en la obtencion de la estructura de la red bayesiana, es decir, los nodos y los enlaces

entre los nodos o de una forma más formal, consiste en obtener las relaciones de dependencia e

independencia de las variables involucradas [130].

Existen dos aproximaciones basicas al aprendizaje estructural:

Test de indepencia

Puntuación y procedimientos de búsqueda.

Existen multitud de algoritmos para este tipo de aprendizaje de los cuales se han utilizado los

siguientes:

Algoritmo PC

Este es un algoritmo basado en test de independencia desarrollado por [326] y que pertenece a

la clase de algoritmos basados en restricciones. La idea basica del algoritmo es desarrollar una

serie de declaraciones condicionales de dependencia e independencia mediante tests estadisticos.

El algoritmo realiza los siguientes pasos:

En primer lugar realiza una serie de test de independecia para todos los para de variables,

expecto para las que se haya de�nido algun tipo de restriccion estructural.

164

Posteriormente añade un enlace entre cada par de variables para las que no encuentra in-

dependecia condicional. El grafo resultante constituye el esqueleto de la estrucutura apren-

dida.

Seguidamente identi�ca los colideres, asegurandose que no se dan ciclos dirigidos. (un

collider es un par de enlaces dirigidos tal que se encuentran en el mismo nodo).

Despues se hacen cumplir las direcciones para aquellos enlaces cuya dirección se puede

derivar de la independencia condicional encontrada y los colliders identi�cados.

Finalmente, los enlaces no dirigidos restantes se dirigen de forma aleatoria, aseguranado

que no se producen ciclos.

Hay que darse cuenta de una cosa muy importnte; y es que, en general, este algoritmo no es

capaz de derivar la direccion de todos los enlaces a partir de los datos y por lo tanto algunos

enlaces los dirige de forma aleatoria.

Mejora del Algoritmo PC, el algritmo NPC

NPC signi�ca condicion de ruta necesaria y es un criterio desarrollado por investigadore s

de Siemens en Munich para resolver algunos problemas de los algoritmos basados en restriccio-

nes como el algoritmo PC. Basicamente PC y NPC son iguales en su funcionamiento (ambos

construyen el esqueleto de la red en bases a test de independencia).

NPC trata de reparar las de�ciencias del algoritmo PC y que ocurren espcialmente cuando

se usan conjuntos de datos incompletos. La solucion propuesta por el algorimo NPC se bsa en

la inclusion de un criterio conocido como condicion de ruta necesaria73. Este criterio es la base

para introducir la nocion de regiones ambiguas74 que proporcionan un lenguaje para la seleccion

entre conjuntos de enlaces interdependientes e inciertos.

En los algoritmos basados en restricciones, el esquleto del gráfo se construye mediante la no

inclusion de un enlace en la gráfo siempre que los nodos correspondientes sean condicionalmente

independientes. Puede, sin embargo, haber incosistencias entre el conjunto de independicia con-

diconal y las condiciones de dependencia originadas por el uso de un conjunto de datos limitado.

Es decir no todas las condiciones se pueden representar a la vez.

El número de inconsistencias en el conjunto de condiciones re�ejan el gradod e incertidumbre

del modelo estructural. Por lo que, el numero de incertezas es un medida su�ciente como para

saber si el aprendizaje se realizo consu�encientes datos o no. Las condiciones incosnsitentes

producen multples soluciones a la hora de inducir un grafo aciclico dirigido.73Informalmente, esta condicion dice que el orden de dos variables X e Y debe ser condicionamente independiente

de un conjunto S; es decir, debe existir una ruta entre X y cada Z perteneciente a S (que no atraviese Y) y entrecada Y y cada Z de S (que no atraviese X). Si no, la inclusion de Z en S es inexplicable. Por lo que, para que ladeclaracion de independencia sea valida, se requiere un numero de enlaces en el grafo.

74Cuando la ausencia de un enlace, a, depende de la presencia de otro enlace, b, y viceversa, se de�ene a y bpara ser interdependientes. Tanto a como b constituyen lo que se llama enlaces inciertos. Una region ambigua es elmaximo conjunto de enlaces interdependientes. Es decir, una region ambigua es un conjunto de enlaces inceirtos.El objetivo principal es obtener tan pocas y tan pequeñas regiones ambiguas como se pueda.

165

Algoritmo Hill-Climbing

Una descripción intuitiva de Hill-Climbing se puede encontrar en probablemente sea el

algoritmo de busqueda local mas conocido. La idea que subyace en este algoritmo es la

siguiente: empezando en un estado generado aleatoriamente; moverse al estado vecino con

mejor valor; reiniciandose, a otro estado aleatorio, cada vez que se alcanza el mimino local. Este

proceso se repite hasta que se encuentra la solucion. Hill-Climbing, por lo general, mantiene un

parametro llamado �Max-Flips� que se usa para limitar el numero de movimientos entre

cada reinicio, lo que ayuda a dejar minimos locales no estrictos. El hecho de que tenga que

explorar todos los vecinos del estado actual antes de realizar el siguiente movimiento, se debe

tener en cuenta, puesto que lleva cierto tiempo [5, 314].

El algoritmo Hill-Climbing es un algoritmo de descenso, de sencilla implementación y gran

robustez, que dada la repetitividad de su método de búsqueda permite contrastar resultados. La

dirección de búsqueda se hace de forma exhaustiva calculando todas las posibles direcciones, y

eligiendo aquella que consigue un mayor descenso. Para n variables z = (z0,z1,...,zn−1) se ensayan2n formas [71]:

z1 = (z0 + s, z1,...,zn−1), z2 = (z0 − s, z1,...,zn−1), ..., z2n−1 = (z0,z1,...,zn−1 + s), z2n =(z0,z1,...,zn−1 − s)

donde s toma valores arbitrarios. Tipicamente, se realizan varios escalones , asignando a s

valores decrecientes en los sucesivos escalones. Una vez alcanzada una situacion de equilibrio para

un determinado escalon (cuando ninguna direccion de busqueda proporciona una solucion que

mejore a la actual, cuando la mejora es menor que un cierto valor minimo, o cuando se alcanza

un maximo de busquedas), el proceso se repite para el siguiente escalon k+1 en el que se aplica

un salto s menor.

La tendencia a obtener minimos locales es el principal problema de este algoritmo, que se

debe al caracter descendiente del coste de�nido por los criterios de aceptacion del algoritmo, y

que depende en gran medida de la solucion de partida.

La descripción en forma de algoritmo se puede encontrar en [WIKIPEDI05].

Algoritmo Bayesian Information Criterion (BIC)

BIC se ha convertido en un criterio para la seleccion de modelos popular en los ultimos años.

BIC trata de proporcionar una medida del peso o el factor bayesiano de una evidencia que

favorece a un modelo sobre otro. Tiene, sin embargo, algunas desventajas importantes que

normalmente no son reconocidas [91].

Primero, los factores de Bayes dependen de la creencia previa sobre los valores esperados de

los parametros de la distribucion y no existen garantias de que el factor de Bayes, implicado

por BIC, vaya a hacer que este proximo a uno de los calculados previamente.

166

Segundo, para obtener los factores de Bayes que siguen desde BIC, los investigadores deben

variar la ditribucion previa dependiendo de la distribucion marginal de las variables y de

la naturaleza de las hipotesis. Dichas variaciones parecen injusti�cables, en prinicipio, y

tienden a hacer que BIC se incline a modelos excesivamente simples en la práctica.

Un modelo de mezcla �nita se caracteriza por tener un numero de componentes K y un vector

de parametros θ = (p1,...,pK , λ1,...,λK) . Una forma clasica de elegir un modelo es seleccionar

aquel que maximice la probabilidad integrada [4]:

(m, K) = arg(maxm,K

f(x|m,K))

donde la probabilidad integrada es:

f(x|m,K) =∫Θm,K

f(x|m,K, θ)π(θ|m,K)dθ

con la probabilidad:

f(x|m,K, θ) =∏n

i=1 f(xi|m,K, θ)

y siendo Θm,K el parametro que representa el espacio del modelo m con K componentes y

π(θ|m,K) una distribucion debil o con poca informacion en θ para este modelo. Swarz propuso

una aproximacion asintotica de la probabilidad integrada, valida en condiciones normales:

log f(x|m,K) ≈ log f(x|m,K, θ)− vm,K

2 log(n)

donde θ es la estimacion ML (Maximum-Likelihood) de θ

θ = argmaxθf(x|m,K, θ)

y vm,K es el numero de parametros libres en el modelo m con K componentes. Esto lleva a

minimizar el supuesto criterio BIC:

BICm,K = −2Lm,K + vm,K lnn

donde Lm,K = log f(x|m,K, θ) es la maxima log-likelihood para m y K.

Aprendizaje Paramétrico

El aprendizaje paramétrico consiste en encontrar los parámetros asociados a una estructra dada

de una red bayesiana. Dichos parámetros consisten en las probabilidades a priori de los nodos

raíz y las probabilidades condicionales de las demás variables, dados sus padres. Si se conocen

todas las variables, es fácil obtener las probabilidades requeridas. Las probabilidades previas

corresponden a las marginales de los nodos raíz, y las condicionales se obtienen de las conjuntas

de cada nodo con su(s) padre(s). Para que se actualizen las probabilidades con cada caso

observado, éstas se pueden representar como razones enteras, y actualizarse con cada

observación.

167

Aprendizaje Paramétrico en modelos discretos

La explicacion de este tipo de aprendizaje se realizara con un ejemplo. Supongase que se

compra una bolsa de caramelos de limon y de cerazas de un nuevo fabricante y de los que se

desconoce tolmente las proporciones de cada uno de ellos. En este caso se tiene una serie de

hipotesis continuas. El parametro en este caso, llamado θ , es la proporcion de caramelos de

cereza, y las la hipotesis es hθ . (La propocion de caramelos de limon es (1− θ) ). Si se asume

que todas las proporciones iguales a priori, entonces la aprocimacion Maximum-likelhood es

razonable. Si se modela esta situacion mediante una red bayesiana, se necisita una variable

alatoria, Flavor (que representa el sabor de un caramelo extraido aleatoriamente de la bolsa).

Esta variable tiene los valores cereza y limon, donde la probabilidad de cereza es θ . Ahora se

supone que se tiene N caramelos sin envoltorio, de los cuales c son de cereza y |l = N − c| sonde limon. De esta forma la funcion de probabilidad es:

P (d|hθ) =NΠ

j=1P (dj |hθ) = θc(1− θ)l

La hipotesis de maximum-likelihood viene dada por el valor de θ que maximiza esta expresion.

El mismo valor se obtiene maximizando el log-likelihood,

L(d|hθ) = logP (d|hθ) =N∑

j=1logP (dj |hθ) = c log θ + l log(1− θ)

Mediante algoritmos se reduce los productos a sumas de los datos , que normalmente es mas

facil de maximizar. Para encontrar el valor maximum-likelihood de θ , se diferencia L con

respecto θ e igualando la expresion resultante a 0, de la siguiente forma:

dL(d|hθ)dθ = c

θ −l

1−θ = 0 → θ = cc+l = c

N

Hasta aqui se ha reproducido el metodo de maximum-likelihood para el aprendizaje

parametrico, que en resumen consiste:

Escribir un expresion de probabilidad para los datos en funcion de los parametros.

Calcular la derivada del log-lokelihood para cada parametros

Encontrar el parametro cuya derivada es 0.

El ejemplo mostrado hasta aqui ilustra un problema importante del aprendizaje

maximum-likelihood en general: cuando el conjunto de datos es tan pequeño que algunos

eventos no se han sido observados -por ejemplo, que no hay caramelos de cereza- este

metodo asigna probabilidad 0 a estos eventos. Para evitar esto, se utilizan algun truco

como incializar el conteo de los eventos a 1 en vez de a 0.

168

Los resultados que proporciona este metodo son buenos y es facil comprobar que se puede

extender a cualquier tipo de red bayesiana cuyas probabilidades condicionales se representen

como tablas.

El punto mas imporante es que con datos completos, el problema del aprendizaje parame-

trico con maximum-likelihood en una red bayesiana se descompone en problemas separados,

uno para cada parametro. Otro punto importante es que los valores del parametro para

una variable, dados sus padres, son simplemente las frecuencias observadas de los valores

de las variables para cada con�guracion de los valores de los padres. Como antes, se debe

tener cuidado con los cero cuando los conjuntos de datos son pequeños.

Existe aprendizaje parametrico para modelos continuos, pero como en el presente

proyecto no se hace uso de este tipo de modelos no se van a comentar; tan solo se

comenta que sique los mismos principios que el aprendizaje en modelos discretos.

Aprendizaje Paramétrico bayesiano

El aprendizaje maximum-likelihood da lugar a procedimientos de aprendizaje muy simples,

pero tiene serias de�ciencias en el tratamiento de conjuntos de datos pequeños. Por ejemplo,

siguiendo con el ejemplo de los caramelos, la hipotesis maximum-likelihood es que la bolsa tenga

el 100% de caramelos de cereza ( θ = 1,0 ). A menos que la hipotesis previa sea que la bolsa

debe contener tanto todos los caramelos de limon o todos de cerezas, esta no es una conclusion

razonable. La aproximacion bayesiana para el aprendizaje de parametros establece una hipotesis

previa sobre los posibles valores de los parametros y actualiza la distribucion segun llegan los

datos.

El ejemplo de los caramelos tiene un parametros θ : la probabilidad de que un caramelo

cogido al azar sea de cereza. Desde el punto de vista bayesiano, θ es el valor (desconocido) de la

variable Θ ; la hipotesis previa es simplemente la distribucion previa P (Θ) . Por lo que P (Θ = θ)es la probabilidad previa de que la bolsa tenga θ caramelos de cereza.

Si el parametro θ puede tener cualquier valor entre 0 y 1, entonces P (Θ) debe ser una

distribucion continua distinta de 0 solo entre 0 y 1 y que integra a 1. La densidad uniforme

P (θ) = U [0, 1](θ) es un candidato. Resulta que la densidad uniforme es un miembro de la familia

de la distribuciones beta. Cada distribucion beta se de�ne por dos hiperparametros a y b tales

que:

beta[a, b](θ) = αθa−1(1− θ)b−1

La constante de normalizacion depende de a y b. El valor medio de la distribucion es , por lo

que valores mas grandes sugieren la creencia de que esta mas cercano a 1 que a 0. Valore mayores

de a +b hace la distribucion mas escarpada, sugiriendo una gran certeza sobre el valor de . Por lo

que, la familia beta proporciona un intervalo util de posibilidades para las hipotesis previa.]para

169

θ en el intevalo [0,1]. La constante de normalizacion α depende de a y b. El valor medio de la

distribucion es a/(a+ b) , por lo que valores mas grandes sugieren la creencia de que Θ esta mas

cercano a 1 que a 0. Valore mayores de a +b hace la distribucion mas escarpada, sugiriendo una

gran certeza sobre el valor de Θ . Por lo que, la familia beta proporciona un intervalo util de

posibilidades para las hipotesis previa.

Anterior, entonces, despues de observar un punto de referencia la distribucion posterior de

tambien es una distribucion beta. A la familia beta tambien se la llama conjugada previa para la

familia de distribuciones de variables booleanas. A continuacion se ve como trabaja, mediante el

ejemplo de los caramelos:]Ademas de su felxibilidad la familia beta tiene otras propiedades intere-

santes: si Θ tiene una beta[a, b] anterior, entonces, despues de observar un punto de referencia

la distribucion posterior de Θ tambien es una distribucion beta. A la familia beta tambien se la

llama conjugada previa para la familia de distribuciones de variables booleanas. A continuacion

se ve como trabaja, mediante el ejemplo de los caramelos:P (θ|D1 = cereza) = αP (D1 = cereza|θ)P (θ)

=α'θ·beta[a, b](θ) = α'θ·θa−1(1− θ)b−1

=α'θa(1− θ)b−1 = beta[a+ 1, b](θ)Previa se comporta exactamente como si se hubiera iniciado todo el proceso con una beta[1,1]

previa uniforme habiendo visto a-1 caramlelos de cereza actuales y b-1 caramelos de limon actua-

les. Así, despues de ver un caramelo de cereza, tan solo se incrementa el parametro a para obtener

la probabilidad anterior; de forma similar despues de ver un caramelo de limon, se incrementa

el paraemtro b. Asi, se puede ver que los hiperparametros a y b como contadores virtuales, en

el sentido de que la beta[a, b] previa se comporta exactamente como si se hubiera iniciado todo

el proceso con una beta[1,1] previa uniforme habiendo visto a-1 caramlelos de cereza actuales y

b-1 caramelos de limon actuales.

Mediante el examen de la secuencia de distribuciones beta para el incremento de los valores a

y b, manteniendo las proporciones �jas, se puede ver directamente como la distribucion posterior

sobre el parametro Θ cambia segun llegan los datos. Por ejemplo, si se supone que en la bolsa

actual hay un 75% de caramelos de cereza. La distribucion converge, claramente, a un pico al

rededor del valor de verdad de Θ . Para conjuntos de datos grandes el aprendizaje bayesiano

converge para dar los mismos resultados que el aprendizaje maximum-likelihood.

Si se utilizan tres parametros θ, θ1,θ2 donde θ se ha visto anteriormente lo que es, θ! es la

probabilidad de que los caramelos de cereza tengane envoltorio rojo y θ2 la probabilidad de que

los caramelos de limon tengan envoltorio rojo. La hipotesis bayesiana previa debe cubrir los tres

parametros completamente -es decir, necesitamos especifocar P (Θ,Θ1,Θ2) . Normalemente se

asume independencia de parametros:

P (Θ,Θ1,Θ2) = P (Θ)P (Θ1)P (Θ2)

Con esta asunción, cada parametro puede tener su propia distribucion beta que se actualiza

separadamente segun

170

llegan los datos.

Una vez que se tiene la idea de que los parametros desconocidos se pueden representar va-

riables aleatorias como Θ , es natural incorporarlas a la red bayesiana. Para hacer esto, tambien

se deben hacer copias de las variables que describen cada caso. Por ejemplo, si se observan 3

caramelos entonces se necesita Sabor1, Sabor2, Sabor3 y Envoltorio1, Envoltorio2, Envoltorio3.

El parametro variable Θ determina la probabilidad de cada varibale Sabori :

P (sabor i = cereza|Θ = θ) = θ

De forma similar la probabilidades de envoltorio dependen de Θ1 y Θ2 . Por ejemplo:

P (Envoltorioi = rojo|Sabor i = cereza,Θ1,θ1) = θ1

Ahora el proceso de aprendizaje bayesiano se puede formular como un problema de inferencia

en una reb bayesiana contruida convenientemente. La prediccion para una nueva instancia se

realiza median la incorporacion nuevas variables de la instancia a la red, algunas de las cuales son

encoladas. Esta formulacion del aprendizaje y la prediccion meustra claramente que el aprendizaje

bayesiano no requiere de ningun �principio de aprendizaje� extra.

Aprendizaje paramétrico secuencial

Este tipo de aprendizaje es interesante, sobre todo, en situaciones en las que el proceso de

aprendizaje no puede almacenar todas las observaciones pasadas en la memoria principal [136].

El aprendizaje/adaptación secuencial se puede de�nir como la capacidad crucial de un sistema

para corregir los errores del modelo inicial y poder adaptarse a los cambios en la distribucion

subyacente [34]. Este tipo de aprendizaje es interesante, sobre todo, en situaciones en las que el

proceso de aprendizaje no puede almacenar todas las observaciones pasadas en la memoria

principal [136].

Distingue esto del entramiento y pre�re llamarlo adaptación. En este punto es interesante hacer

una distrincion entre la generacion del modelo inicial y la revision de los parametros que ya

existen en el modelo. Existen dominios donde hay su�cientes datos disponibles para aprender

los parametros de la red a patir de una base de datos. Se puede defnir esta actividad como

entrenamiento. Sin embargo, el caso más normal es tener que usar una combinacion de

conocimiento experto y datos estadisticos para obtener los parametros requeridos. En este

punto alguien puede querer usar los datos recibidos para revisar los parametros de la red; los

parametros inicialmente se pueden precisar de forma imprecisa o, incluso, de forma incorrecta.

[266] distingue esto del entramiento y pre�re llamarlo adaptacion.

Cuando la muestra de entrenamiento aumenta y se requiere una actualizacion rapida e

incremental de la red bayesiana, se puede hacer una alteracion de parametros simple sin que

171

afecte a la estructura de los padres. Esto quiere decir, que para cada varible x ∈ X y para cada

conjunto de padres razonable Πx ∈ Px se debe incrementar el correspondiente valor de celdas y

actuzalar las posteriores. Normalmente este proceso debe afectar a los nodos vivos en el

entramado de padres. Por ejemplo, si se tiene una muestra z y se extiende a z' con el nuevo

ejemplo teniendo x=i y Πc = j, se debe incrementar nx=i|j y

Pr(ΠX |z', ς, E) = Pr(ΠX |z, ς, E) (nx=i|j+αx)(nx=.|j−1+mxαx)

(nx=.|j+mxαx)(nx=i|j−1+αx)

Todo esto se deriva de las propiedades recursivas de la funcion Gamma. El proceso de actua-

lizacion completo realizara, por tanto, O(P) operaciones. Se puede mejorar este proceso actua-

lizando inicialmente, solo, los nodos hoja en los enntramados del padre porque el cambio en el

conteo del ejemplo se puede �ltrar hacia arriba sin referencia a los ejemplos.

Aprendizaje con datos incompletos

Una distinción importante sobre los datos incompletos (missing data) es si la ausencia de estos

datos es depediente del estado real de las variables. Por ejemplo, un dato perdido en un estudio

sobre dogadiccion puede indicar que el paciente lo hizo demasiado enfermo como para continuar

en el estudio. Por otro lado, si la variable es oculta (por ejemplo, nunca se ha observado el

caso) entonces la ausencia del dato es independiente del estado de la variable.

Aunque los metodos bayesianos y los modelos grá�cos estan preparados para el análisis de

ambas situaciones; los metodos necesarios para cuando la ausencia es independiente del estado son

más simples que que aquellos en los que la ausencia es dependiente. En este punto se van a tratar

algunos de ello para ver muchos mas se pueden utilizar las siguientes referencias [301, 190, 189].

Aprendizaje paramétrico con datos incompletos Se van a discutir ahora los métodos para el

aprendizaje paramétrico cuando se usa una muestra de datos incompleta (por ejemplo, cuando

no se han obserado algunas variables de algunos casos). La presentacion formal del problema es

la siguiente:

Suponiendo que se observa un unico caso incompleto. Sea Y ⊂ X y Z ⊂ X que son las

variables observada y no observadas respectivamente. Asumiendo la independencia de parametros

se puede calcular la distribucion posterior de θij para una estructura de red S, como sigue:

p(θij |y, Sh) =∑

x

p(z|y, Sh)p(θij |y, z, Sh)

= (1− p(paji |y, S

h)){p(θij |Sh)} +ri∑

k=1

p(xki , pa

ji |y, S

h){p(θij |xki , pa

ji , S

h)}

Cada término dentro de las llaves en esta ecuacion es una distribucion de Dirichlet. Por lo

que, a menos que Xi y todas las variables en Pai se observen en el caso y, la distribucion posterior

de θij sera una combinacion lineal de distribuciones de Dirichlet.

172

Cuando se observa un segundo caso incompleto, alguna o todos los componentes de Dirichlet

de la ecuacion anterior se dividirán en �mezclas de Dirichlet�. Lo que sigini�ca, que la distribucion

posterior para θij se transformara en una mezcla de mezclas de Dirichlet. A medida que se

siguen observando datos incompletos, cada valor perdido para Z, la distribucion posterior de θijcontendra unnumero de componentes que es exponencial al numero de casos. En general, para

cualquier conjunto interesante de probabilidades y prioridades, el calculo exacto de la distribucion

posterior de θij es intratable. Por lo que se requiere una aproximacion para datos incompletos.

Se procede a continuación a explicar los metodos mas comúnmente utilizados.

Metodos de Monte-Carlo

Una clase de aproximaciones esta basada en los muestreos de Monte-Carlo. Estas

aproximaciones pueden ser extremadamente exactas, siempre que se este dispuesto a esperar

bastante tiempo hasta que se produzca la convergencia.

Se va a presetantar el metodo de Monte-Carlo conocido com Gibbs sampling (que aunque se

ha explicado anteriormente, aquí tiene otra aplicacion).

Dadas las variables X = {X1, ..., Xn} con alguna distribución conjunta p(x) se puede utilizar

el sampler de Gibbs para aproximar la expectativa para la función f(x) con respecto de p(x) de

la siguiente forma. Primero, se elige (de alguna manera, por ejemplo, aleatoriamente) un estado

inicial para cada una de las variables en X. A continuación se elige una variable culaquiera Xi

se desasigna su estado actual, y se calcula su distribucion de probabilidad dados los estados

de resto de n-1 variables. Entonces se muestrea un estado para Xi basado en su distribucion

de probabilidad y se calcula f(x). Finalmente se repiten los dos primeros pasos, manteniendo un

registro del valor medio de f(x). En el límite, como el número de casos se aproxima a in�nito, esta

media es igual a Ep(x)(f(x)) con tal de que se cumplan dos condiciones. Primero, el sampler de

Gibbs debe ser irreducible, es decir, la distribución de probabilidad p(x) debe ser tal que se pueda

muestrear eventualmente cualquier posible con�guracion de X dada cualquier con�guración incial

de X. Segundo, cada Xi se debe elegir amenudo.

Para ilustar el funcionamiento de Gibbs Sampling, se aproximará la densidad p(θs|D,Sh)para cualquier con�guracion de θs dado un conjunto de datos incompletos D = {yi, ..., yn}y una

red bayesiana de variables discretas con prioridades de Dirichlet independientes. Para aproximar

p(θs|D,Sh). Primero se incializa, de alguna forma, los estados de las variables no observadas en

cada caso. Como resultado, se obtiene una muestra completa y aleatoria Dc. Segundo, se elige

alguna variable Xil (variable Xien el caso l) que no se ha observado en la muestra original D

elegida al azar, y se reasigna su estado de acuerdo con la distribucion de probabilidad:

p(x'il |Dc \ xil , Sh) = p(x'il ,Dc\xil |Sh)P

x�il

p(x�il ,Dc\xil |Sh)

173

donde Dc \ xil indica el conjunto de datos Dc con la observacion Xil borrada. Tercero, se

puede repetir esta reasignacion para todas las variables no observadas en D, produciendo una

muestra completa aleatoria nueva D'

c . Cuarto, se calcula la probabilidad posterior p(θs|D,Sh) .Y �nalmente, se repiten los tres primeros pasos y se usa la media de p(θs|D,Sh).

Aproximación Gaussiana

Los metodos de Monte-Carlo proporcionan resultado exacto, pero normalmente son intratables,

por ejemplo, cuando se tiene una muestra de datos demasiado grande. Otra aproximación que

ofrece resultados practicamente igual de exactatos para muestras relativamente grandes es, esta

aproximacion gaussiana [209] y [12] que se comenta en este punto.

La idea que hay detras de esta aproximacion es que, para una cantidad de datos gran-

de, p(θs|D,Sh) ∝ p(D|θs, Sh)p(θs|Sh) se puede aproximar, frecuentemente, a una distribucion

Gaussiana multivarible.

Concretamente, sea:

g(θs) ≡ log(p(D|θs, Sh)p(θs|Sh))

También, se de�ne θs como la con�guracion de θs. Esta con�guracion tambien maximiza

p(θs|D,Sh) y se conoce como la con�guracion MAP de θs.

Para calcular esta aproximacion gaussiana, se debe calcular θs, asi como, el Hessian75 negativo

de g(θs) evaluado en θs.

Aproximación MAP, ML y algoritmo EM

Como aumente el tamaño de la muestra, el pico gaussiano es más agudo tendiendo a la función

delta de la con�guración MAP θs. En este punto no es necesario calcular medias o expectativas.

En su lugar, simplemente se realizan predicciones basadas en la con�guración MAP.

Una aproximación más profunda se basa en la observación de que, como el tamaño de la

muestra aumenta, el efecto de la anterior p(θs|Sh)disminuye. Por lo que, se puede aproximar

θspor medio de la con�guracion de Maximum Likekihood del θs:

θ = argmaxθa

{p(D|θs, Sh)}

Existe un tipo de tecnicas de optimizacion basada en gradiente para para encontrar ML o

MAP. Por ejemplo, se puede usar un gradiente ascendente, donde se siguien las derivadas de

g(θs) o la probabilidad p(D|θs, Sh) hasta el maximo local. [302] y [355] muestran como calcular

las derivadas de la probabilidad de una red bayesiana con distribuiciones multinomiales no res-

tringidas. [46] discute el caso más general donde la funcion de probabilidad viene de una familia

exponencial. Por supuesto estos metodos basados en gradiente encuentran sólo el maximo local.75http://rkb.home.cern.ch/rkb/AN16pp/node118.html

174

Otra tecnica para encontrar un ML o MAP local es el algoritmo EM descrito por [104]. Para

buscar el maximo local MAP o ML, se comienza por asignar, de alguna forma (por ejemplo,

aleatoria) un con�guracion a θs. Seguidamente, se calcula la estadistica su�ciente esperada para

un conjunto de datos completo, donde la expectacion se toma con respecto a la distribucion

conjunta para X condicionada por la con�guracion asignada a θsy los datos conocidos D. En el

ejemplo que se viene mostrando, se puede calcular:

Ep(x|D,θs,Sh)(Nijk ) =N∑

l=1

p(xki , pa

ji |yl, θs, S

h)

donde yl es el l-esimo caso incompleto de D. Cuando Xi y todas las variables en pai se

observan en el caso xlel término para este caso requiere una computación trivial: es cero o uno.

Si no, se puede usar cualquier algoritmo de inferencia bayesiano para evaluar el término. Este

cálculo es el paso de expectacion del algoritmo EM.

Seguidamente, se usan las estadisticas-su�cientes esperadas como si fuesen la actuales estadisiticas-

su�cientes de la muestra completa (aleatoria) D. Si se hace el calculo ML, se determina la con�-

guracion de θs que maximiza p(Dc|θs, Sh). Siguiendo el ejemplo, se tiene que:

θijk =E

p(x|D,θs,Sh)(Nijk )Pri

k=1 Ep(x|D,θs,Sh)

(Nijk )

Si se hace el calculo MAP, entonces se establece la con�guracion de θsque maximiza p(Dc|θs, Sh).

Siguiendo el ejemplo, se tiene que:

θijk =αijk+E

p(x|D,θs,Sh)(Nijk )Pri

k=1(αijk+Ep(x|D,θs,Sh)

(Nijk ))

Esta asignacion, realmente, es el paso de maximizacion del algoritmo EM. Este algorimo

se usa normalmente cuando cuando existen su�cientes estadisiticas (por ejemplo, cuando una

funcion de distribucion local está en una familia exponencial), aunque generalizaciones de EM

permiten que se use en distribuciones locales mas complicadas.

Una vez que se ha construido la red bayesiana ( a partir de concimiento, previo, datos o una

combinacion de ambos) normalmente, surge la necesidad de determinar algunas probabilidades

de interes a partir del modelo. Por ejemplo, en un problema sobre deteccion de fraude, se puede

pretender obtener la probabiliadad de un fraude dadas una serie de observaciones de otras varia-

bles. Esta probabilidad no se almacena directamente en el modelo y por tanto se debe calcular.

En general, el calculo de la probabilidad dado un modelo se conoce como inferencia. En este

punto se va a describir la inferencia en redes bayesiana [86].

Como una red bayesiana, para una variable X, determina la distribucion probabilidad con-

junta de esa variable, se puede (en principio), usar la red baysiana para calcular cualquier pro-

babilidad que resulte de interes. Por ejemplo, para la siguiente red:

175

Figura 2.78: Red bayesiana de ejemplo

La probabilidad se puede calcular:

p(f |a, s, g, j) = p(f,a,s,g,j)p(a,s,g,j) = p(f,a,s,g,j)P

f 'p(f ',a,s,g,j)

Para problemas con muchas más variables, sin embargo, esta aproximacion tan directa no es

posible. Afortunadamente, cuando todas las variables son discretas, se puede aprovechar la inde-

pendencia condicional codi�cada en las redes bayesianas para hacer estos calculos más e�cientes.

Dada la ecuacion de independecia condicional p(j|f, a, s, g) = p(j|f, a, s) la ecuacion anterior

se transforma en:

p(f |a, s, g, j) = p(f)p(a)p(s)p(g|f)p(j|f,a,s)Pf '

p(f ')p(a)p(s)(g|f ')p(j|f ',a,s)= p(f)p(g|f)p(j|f,a,s)P

f 'p(f ')(g|f ')p(j|f ',a,s)

Muchos investigadores han desarrollado algoritmos de inferencia para redes bayesianas con

variables discretas que aprovechan la independencia condicional como se ha descrito arriba. Por

ejemplo en [166], [239] y [287] desarrollan algoritmos que invierten arcos o enlaces en la estructura

de la red hasta que la pregunta probabilista realizada se puede leer directamente del grafo. En

estos algoritmos cada enlace invertido se corresponde con una aplicacion del teorema de Bayes.

[186] desarrolla un esquema de paso de mensajes que actualiza las distribuciones de probabilidad

de cada nodo de una red bayesianas en respuesta a observaciones de una o más variables. [392],

[197] y [97] crearon un algoritmo que primero transforma la red bayesiana en un arbol donde cada

nodo en el arbol se correponde con un subconjunto de variables en X. El algoritmo se aprovecha,

entonces, de algunas propiedades matematicas de los arboles para realizar la inferencia. Este

algoritmo es el que más se utiliza con variables discretas.

Aunque se utiliza la independencia condicional para simpli�car la inferencia probabilistica,

la inferencia exacta en redes bayesianas arbitrarias con nodos discretos es un problema NP-

hard76. Incluso la inferencia aproximada mediante, por ejemplo, el metodo de Monte-Carlo es un

problema NP-hard. El origen de esta di�cultad subyace en lo ciclos no dirigidos de la estructura

de la red bayesiana -ciclos en la estructura donde no se hace caso a la direccionalidad de los

enlaces. Cuando una red bayesiana contiene muchos ciclos la inferencia es intratable. Para muchas

aplicaciones la estructura es su�cientemente simple (o se puede simpli�car sin perder demasiada

exactitud) por lo que la inferencia es e�ciente.

76http://es.wikipedia.org/wiki/NP-hard

176

Algoritmo Gibbs Sampling [51]

Este algoritmo es uno de los más simples dentro de los algoritmos de Monte-Carlo. Lo intro-

dujo [144] en el contexto del procesamiento de imagenes y posteriormente lo discutio [350] en el

contexto de problemas de perdida de datos. El documento [143] ayuda a demostrar el valor del

algoritmo de Gibbs para un amplio abanico de problemas de analisis bayesiano.

Para de�nir este algoritmo, se establece la distribucion condicional total como:

{π(ψ1|ψ2, ..., ψp); π(ψ2|ψ1, ψ3, ..., ψp); π(ψp|ψ1, ..., ψd−1)}

Ahora un ciclo del algoritmo se completa mediante la simulacion de {ψk}pk=1 para esas distri-

buciones, actualizando de forma recursiva las variables condicionantes. Cuando d=2 se obtienen

los dos bloques del sampler de Gibbs que aparecen en [350]. En este sampler cada bloque se

revisa en un orden �jado, de la siguiente manera [39]:

Se especi�ca un valor inicial ψ(0) = (ψ(0)1 , ..., ψ

(0)p )

Repetir para j = 1, 2, ...,M

• Generar ψ(j+1)1 desde π(ψ1|ψ(j)

2 , ψ(j)3 , ..., ψ

(j)p )

• Generar ψ(j+1)2 desde π(ψ2|ψ(j+1)

1 , ψ(j)3 , ..., ψ

(j)p )

• ...

• Generar ψ(j+1)p desde π(ψp|ψ(j+1)

1 , ..., ψ(j+1)p−1 )

Devolver los valores {ψ(1), ψ(2), ..., ψ(M)}

La densidad de la transicion de ψ(j)k hasta ψ(j+1)

k viene dado por

p(ψk|ψ(j+1)1 , ..., ψ

(j+1)k−1 , ψ

(j)k+a, ..., ψ

(j)p ) hasta que el bloque k-esimo se alcanza, el anterior (k-1) se

actualiza. Por lo tanto, la densidad de la transicion de la cadena, bajo el supuesto de que π es

absolutamente continua, viene dada por el producto de las transiciones de los nucleos de cada

bloque:

K(ψ,ψ') =p∏

k=1

π(ψk|ψ(j+1)1 , ..., ψj+1

k−1, ψjk+1, ..., ψ

jp)

Para ilustrar la manera en que los bloques se revisan, se considera el caso de dos bloques,

cada uno con un único componente y esquematizado en la siguiente �gura una posible trayectoria

del algoritmo.

177

Figura 2.79: Trayectoria Del Algoritmo

Los contornos en la �gura representan la distribucion conjunta de ψ y las etiquetas �(0)�,

�(1)�, etc denotan los valores simulados.

Hay que darse cuenta que en cada iteracion del algoritmo se completa despues de que ambos

componentes han sido revisados. Tambien hay que darse cuenta de que cada componente se revisa

a lo largo de la los ejes de coordenas. Esta caracteristica puede ser una fuente de problemas

si dos componentes estan ampliamente correlacionados porque entonces los contornos tienen

compresiones y movimimientos a lo largo del eje de coordenadas que dan lugar a pequeños

movimientos.

Este algoritmo es aplicable cuando la distribucion conjunta no se conce explicitamente, pero

la distribucion condicional de cada variable si es conocida. En resumen, lo que hace este algoritmo

es generar una instancia de la distribucion de cada variable de forma condicional a los valores

actuales de las otras variables [WIKIPEDI05]. Este algoritmo es facil de implementar y garantiza

convergencia hacia la distribucion correcta, sin embargo puede requirir un numero excesivo de

iteraciones antes de que converja [87].

Algoritmo Naive

El metodo de inferencia que se prensenta en este punto se puede aplicar a cualquier modelo

naive.

En [87] describen el algoritmo de la siguiente forma: para preguntas marginales, sea X el

conjunto de variables de consulta, sea C la variable componente de k estados y Z el conjunto

de la demas variables ocultas. (Se asume que la variable componente nunca forma parte de la

consulta, esto es, nunca se observa en los datos de entrenamiento). Permitase que X se re�era a

los estados �jos de las variables de pregunta. Ahora se puede calcular la probabilidad marginal

directamente mediante la suma de todos los posibles estados de C y Z:

P (X = x) =k∑

c=1

∑zP (X = x,Z = z, C = c)

178

Por la hipoteisis de naive Bayes, cada una de las otras variables son indepndientes dada C.

Usando esto, se puede expresar la probabilidad en terminos de las distribuciones aprendidas P(C)

y P (Xi|C) :

P (X = x) =k∑

c=1

∑k

P (c)|Z|∏i=1P (zi|c)

|X|∏j=1

P (xi|c)

Como∑

z P (zi|c) siempre es 1, las variables en Z no afectan al calculo de la probabilidad y

se pueden ignorar con total seguridad:

P (X = x) =k∑

c=1P (c)

|X|∏j=1

P (xj |c)

Como esta expresion es el producto de k sumas, cada suma conteniendo |X|+1 terminos,

el tiempo total requerido para calcaular P(X = x) es O(|X|k). El tiemp de inferencia de naive

Bayes es constante al numero de variables ocultas mientras la inferencia exacta bayesiana es

exponencial al numero de varibles ocultas.

Las probabilidades condicionales se pueden calcular e�cientemente como ratios de las pro-

babilidades marginales. Permitase a Y referirse a un conjunto de variables condionantes en la

consulta condicional y permitase a y referirse a un estado �jo de Y.

P (X = x|Y = y) = P (X=x,Y =y)P (Y =y)

Las probabilidades marginales en numerador y denominador se pueden calcular en tiempo

O(k(|X|+|Y |)) y O(k|Y |) respectivamente. Por otro lado, la probabilidad condicional P(X =x |

Y = y) se pude calcular en tiempo O(k(|X|+|Y |)) . Hay que �jarse en que este tiempo permanace

independiente del numero de variables ocultas.

Puesto que la distribucion de probabilidad completa, sobre multiples variables, especi�ca un

probabilidad para cada uno de un numero exponencial de estados, almacenar estas probabilia-

dades puede requerir un tiempo y espacio tambien exponencial. Se puede, sin embargo, generar

de forma e�ciente un modelo reducido de naive Bayes que incorpore toda la evidencia. En este

modelo reducido se borran todas las variables de Y y las evidencias en Y se han incorporado

mediante el ajuste del peso de los componentes, P(C).

Inferencia con datos incompletos

Las inferencias sobre las magnitudes desconocidas �parámetros, datos no observados, variables

latentes, etc� se obtienen calculando la distribución condicionada de éstas por las magnitudes

conocidas, como son: el modelo estadístico, los datos observados, las variables explicativas, el

método de muestreo y cualquier otra información auxiliar, como pueda ser el redondeo de los

datos, la censura o truncado de estos, etc [182].

179

Puesto que no se han encontrado que metodos o algoritmos emplea la libreria PNL para

realizar esta labor; se pasa a describir algunos de los metodos mas importantes que se han

encontrado.

Metodos de imputacion multiple

La imputacion múltimple (MI) es la practica de �rellenar� los datos perdidos con valores

plausibles. Aparentemnente resuelve que existan missing-data al comienzo del analisis de los

datos. Sin embargo, una metodo de imputacion ingenuo puede crear mas problemas de los que

resuleve, distorsionando las estimaciones, produciendo errores de todo tipo como indica [300].

El procedimiento de MI proporciona tres metodos para la imputacion la imputacion de los va-

lores perdidos y el metodos elegido depende del patron que sigan los missing-data. Para patrones

monotonos son apropoiados tanto el metodo de regresion parametrica, que asume normalidad

multivariable como un metodo no parametrico que usa un metodo de puntuacion de la pro-

pension. Para patrones arbitrarios se puede usar el metodo MCMC77 que asume normalidad

multivariable. A continuacion se describen estos tres metodos comentados.

1. Metodo de regresion paramétrica

De forma intuitiva, este metodo ajusta un modelo de regresion para cada variable con valores

perdidos, con las variables previas como covarianzas. En base al resultado del modelo simula un

nuevo modelo de regresión y lo usa para imputar los missing-data a cada variable [9]. Puesto

que el conjunto de datos tiene un patron de perdida de datos monotono, el proceso se repite

secuencialmente para variables con missing-data.

De un modo mas formal, para una variable Yj con valores perdidos, se ajusta con observaciones

no perdidas de un modelo

Yj = β0 + β1Y1 + β2Y2 + ...+ β(j−1)Y(j−1)

El modelo ajustado tiene estimaciones del parametro de regresion (β0,β1,..., β(j−1), ) y la cova-rianza asociada σ2

jVj donde Vj es la matrix X'X de la interseccion y las variables Y1,Y2,..., Y(j−1).

Para cada imputacion, aparecen nuevos parametros (β*0, β*1, ..., β*(j−1), ) y σ2*j de la distri-

bucion predictiva de los missing-data. Es decir, se simulan de (β0,β1,..., β(j−1), ) , σ2j y Vj .

Los valores perdidos se reemplazan, entonces, por

β*0 + β*1y1+ β*2y2

+ ...+ β*(j−1)y(j−1)+ ziσ*j

donde y1,y2,..., y(j−1) son los valores de la covarianza de las primeras (j-1) variables y z es

una desviacion normal simulada.77Markov Chain Monte Carlo

180

1. Metodo de puntuación de la propensión

La puntuación de la propensión es la probabilidad condicional de la asignacion a un tratamiento

particular dado un vector de covarianzas observadas [301]. En este metodo se genera una pun-

tuacion de la propension para cada variable con valores perdidos para indicar la probabilidad de

la observacion que falta . Las observaciones se agrupan entonces basandose en esa puntuacion y

se aplica a cada grupo una imputación bayesiana aproximada [226].

Con un patron de perdida de datos monótono, los pasos a seguir para imputar valores a cada

variable Yj con datos perdidos son los siguientes:

Crear una variable indicador Rj con el valor 0 para las boservaciones con Yj perdido y el

valor 1 en caso contrario.

Ajustar el modelo logico de la regresion de logit(pj) = β0 + β1Y1 + β2Y2 + ...+ β(j−1)Y(j−1)

donde pj = p(Rj = 0|Y1,Y2,..., Y(j−1)) y logit(p) = log(p/(1− p))

Crear la puntuacion de la propension para cada una de las observaciones para indicar la

probabilidad de los datos perdidos.

Dividir las observaciones entre un �jado de grupos basando es las puntuaciones.

Aplicar un arranque de imputacion bayeisano aproximado para cada grupo. En el grupo

k , denote Yobs la n1 obserbacion sin perdida de datos de los valores de Yj y denote Ymis

la observacion n0 con perdida de datos de Yj . El arraque aproximado de la imputacion

bayesiana primero muestra n1 observaciones aleatorias con remplazamiento de Yobs para

crear un nuevo conjunto de datos Y *obs . Este es una analogia no-parametrica de los para-

metros mostrados para la distribucion predictiva posterior de los datos perdidos. Entonces

muestra los n0 valores de Ymis reemplazandolos aleatoriamente con los valores de Y *obs .

Este proceso se repite secuencialmente para cada variable con valores perdidos.

Este metodo utiliza sólo la informacion de covarianza con la que esta relacionada si los

valores imputados de la varible estan perdidos. No usa correlaciones entre variables. Es efectivo

para inferencias sobre las distribuciones de variables imputadas individualmente, pero no es

apropiado para el analisis de las relaciones entre variables [400].

1. Metodo MCMC

En este metodo se construye una cadena de Markov su�cientemente larga como para que la

distribucion de elementos se estabilice en una distribucion comun y estacionaria. Mediante

simulaciones repetidas se obtiene una distribucion de interes.

En inferencia bayesiana, la informacion sobre los parametros desconocidos se expresa en

forma de distribucion posteriror. MCMC se ha aplicado como un metodo de exploracion de

181

distribuciones posteriores en inferencia bayesiana. Es decir, mediante MCMC , se puede simular

la distribucion conjunta entera de las cantidades desconocidas y para obtener una estimacion

simulada de los parametros posterirores de interes.

Asumiendo que los datos son de una distribucion normal miltivariante, el aumento de da-

tos se aplica a la inferencia bayesiana con missing-data mediante la repeticion de una serie de

imputaciones y pasos posteriores. Los pasos son los siguientes [400]:

Paso de imputacion I-step.

Con el vector de medias estimadas y la matriz de covarianza, este paso simula los valores

perdidos para cada una de las observaciones de forma independiente. Esto es, si se denota

las variables con valores perdidos de la observacion i como Yi(mis) y las variables con

valores observados como como Yi(obs) entonces el paso I-step muestra valores para Yi(mis)

de una distribucion condicional dado Yi(obs) .

Paso posterior p-step

Este paso simula el vector de poblacion media posterior y la matriz de covarianza para

estimaciones de muestras completas.. Estas nuevas estimaciones se usan en el pasos

I-step. Sin informacion previa sobre esos parametros, se usan piroridadas no informativas.

Se puede usar otras prioridades informativas.

Estos dos pasos se repiten lo su�ciente como para que sean con�ables para un conjunto

multiple de datos imputados [316].

La meta es tener la convergencia iterada a su distribucion estacionaria y entonces simular

una muestra independiente de valores perdidos. Es decir, con el parametro actualmente estimado

θ(t) en la t-esima iteracion el paso I-step muestra Y (t+1)miss de p(Ymis |Yobs , θ(t)) y el paso p-step

muestra θ(t+1) de p(θ|Yobs , Y(t+1)mis ) . Esto crea la cadena de Markov (Y (1)

mis , θ(1)), (Y (2)

mis , θ(2)), ...,

que converge en una distribucion para p(Ymis , θ|Yobs).

2.5.3. Modelado de la información de estado [137]

Sea X una variable aleatoria que puede tomar L posibles valores de un conjunto Σ. Sin pérdidade generalidad, sea Σ={1, ..., L} . Proporcionando un conjunto de entrenamiento D que contiene

los resultados de N variables independientes x1,..., xN de X de una distribucion multinomial

desconocida P*. Se puede indicar por Ni el número de ocurrencias del símbolo i en los datos

de entrenamiento. El problema de estimación multinomial es encontrar una aproximación buena

para P* (que tambien es una distribucion multinomial).

Este problema consiste en predecir el resultado de xN+1 dado x1,..., xN . Dada una distribu-

cion anterior sobre las posibles distribuciones multinomiales la estimacion Bayesiana es:

182

P (xN+1|x1,..., xN , ξ) =∫P (xN+1|θ, ξ)P (θ|x1,..., XN , ξ)dθ

donde θ = (θ1, ..., θL) es un vector que describe los posibles valores de las probabilidades

desconocidas P *(1), ..., P *(L) , y ξ es la variable contexto que indica todas las posibles hipotesissobre el dominio.

La probabilidad posterior de θ se puede reescribir usando la ley de Bayes como:

P (θ|x1,..., xN ) ∝ P (x1,..., xN |θ, ξ)P (θ|ξ) = P (θ|ξ)∑iθNii

La distribucion de Dirichlet es una familia parametrica que son las conjugaciones de la dis-

tribucion multinomial. Esto es, si la distribucion previa es de esta familia, entoces esta en la

posterior. Un �Dirichelet prior� para X se especi�ca mediante los hiperparametros α1, ..., αL y

tienen la forma:

P (θ|ξ) = Γ(P

i αi)Qi Γ(αi)

∏iθαi-1i (

∑iθi = 1andθi > 0∀i)

donde Γ(x) =∫∞0 tx-1e-tdt es la funcion gamma. Dado un Dirichlet prior, la prediccion incial

para cada valor de X es:

P (X1 = i|ξ) =∫θiP (θ|ξ)dθ = αiP

j αj

Con todo esto es facil ver que, si el previo es un Dirichelet prior con hiperparametros α1, ..., αL

eentondes el posterior es un Dirichelet con hipermarametros α1 + N1, ..., αL + NL . Por lo la

prediccion para XN+1 es:

P (xN+1 = i|x1,..., xN , ξ) = αi+NiPj(αj+Nj)

Se puede pensar en los hiperparametros αi como un numero de ejemplos �imaginarios� en

los que se ha visto el resultado i. Así, el ratio entre los hiperparametros corresponde a la valo-

racion inicial de la probabilidad relativa de los resultados correspondientes. El peso total de los

hiperparametros representa la con�anza en el conocimiento previo. Como se puede ver, si este

peso es grande, la estimacion de los parametros tiende a ir mas allá de las frecuencias observadas

empiricamente de los datos.

Cadenas de Markov

En este apartado se van a describir las cadenas de Markov, los modelos de Markov Ocultos y

diversas aproximaciones a su implementación. Además se dará una visión de las problemáticas

y algorítmicas empleadas. [290, 228]

183

Cadenas de Markov

Una cadena de Markov representa un automáta con estados �nitos de la siguiente forma:

Figura 2.80: Cadena de Markov

Se de�ne como λ =� N, {π1}, {aij} �

N, representa el número de estados que tiene la cadena.

π representa la probabilidad inicial o a priori de cada uno de los estados.

{aij}, representa la matriz de distribución de probabilidad para transiciones entre estados

de la cadena.

La premisa fundamental que se realiza en todo tratamiento y trabajo relacionado con modelos

de Markov es la hipótesis de independencia de todas las muestras anteriores con la actual salvo

para con la anteior. Esto explicado de forma matemática queda de la siguiente forma:

P (qt = j|qt−1 = i|qt−2 = k, ...) = P (qt = j|qt−1 = i)

La interpretación es que la probabilidad de estar en el estado j en el instante actual sólo

viene condicionada al estado en el que se encontraba el sistema en el instante t-1. El resto de

las muestras que se han producido en el modelo se descartan, si bien hay trabajos relacionados

para ampliación del número de etapas anteriores a tener en consideración: bigramas, trigramas,

. . . n-gramas.

Las cadenas de Markov además tienen la propiedad de ser estacionarias, es decir, que en cada

momento se cumple el principio de Markov, esto es:

P (qt = j|qt−1 = i) = P (qt+1 = j|qt+1−1 = i)

A este tipo de cadenas de Markov también se le suele denominar cadenas de primer orden.

A su vez denotar que los estados en estas cadenas son observables, es decir, se puede saber su

valor en todo momento.

La parte observable de este modelo es la propia secuencia de estados y a su vez se puede

calcular la probabilidad de que se de una observación en concreto para un determinado modelo:

184

P (X|M) = πX1 · αX1X2 . . . αXn−1Xn

La fórmula anterior indica que para calcular la probabilidad de que una cadena de Markov

genere una determinada observación, se calcula de forma tan sencilla como la arriba indicada:

probabilidad de inicio por el primer estado de la observación, por la probabilidad de transición

entre el primer estado observado y el segundo, etc.

Representacion de cadenas de markov como RRBB

Las cadenas de Markov son un subconjunto de las propias Redes Bayesianas. Es decir, que se

puede representar lo mismo de ambas formas. Para el caso de una cadena de Markov simple

como la que sigue:

Figura 2.81: Cadena de Markov representada como red bayesiana

En esta red de ejemplo las probabilidades son las siguientes:

Cuadro 2.4: Tabla de probabilidades de la �gura

Con una determinada distribución inicial π, que indica la probabilidad a priori de que se esté

en un estado o en otro.

Una red bayesiana que represente lo mismo, partiendo del principio de que sólo se mantiene

el conocimiento del estado anterior, queda tan simple como esta:

185

Figura 2.82: Tablas de probabilidad condicionada

Las tablas de probabilidades condicionadas para el nodo de la RRBB que se ha denominado

SFinal, van a indicar la probabilidad de que se de un determinado estado de la variable en

función del estado que haya ocurrido con anterioridad. Como se puede aprenciar en la �gura,

además de tener las tablas de probabilidad condicionada en el segundo nodo, se tiene la tabla de

probabilidad a priori del primero, que coincidirá con la distribución π, de una cadena de markov

simple.

Denotar además, que solo hacen falta dos variables para computar todo, introduciendo evi-

dencias parciales y manteniendo el productorio. Para el primer caso de las cadenas de Markov el

procedimiento para calcular la ruta S1, S2, S3, S5, S4, S1:

P (S1, S2, S3, S5, S4, S1) = P (S1) · P (S2|S1) · P (S3|S2) · P (S5|S3) · P (S4|S5) · P (S1|S4)

Realizando la misma operación, de la RRBB sólo nos va a interesar el CPD78 del segundo

nodo, para poder realizar el cálculo pertinente. Todas las probabilidades condicionadas se van

a poder obtener de la susodicha tabla. Además las probabilidades iniciales, para una cadena de

markov en la que no se tiene de�nido ni estado de principio ni de �nal, quedan representadas en

la tabla o CPD del nodo denominado Sinicial.

En la forma anterior como se puede apreciar, resulta bastante sencilla la modelización de una

cadena de Markov y además se obtienen una serie de ventajas algoritmicas y computacionales

dadas por las redes bayesianas en sí mismas79.

Hidden Markov Model

Los Modelos Ocultos de Markov son autómatas de estados �nitos estocásticos con

observaciones continuas o discretas. Estas observaciones o salidas se conocen como símbolos y

en cada momento del tiempo sólo se extrae uno en concreto.

78CPD, tabla de probabilidades del nodo en cuestión.79Inferencia, aprendizaje, correlación, independencia, representación del conocimiento . . .

186

Básicamente es el mismo concepto que las cadenas de Markov anteriores, con la salvedad de

que los estados no son visibles, si no que de ellos sólo se conoce la salida que emiten.

Se han utilizado extensamente en el reconocimiento del habla, en los que se llega incluso

a una jerarquía de modelos que van desde la detección de subpalabras (fonemas, semisílabas,

sílabas) hasta la detección de palabras y textos completos. Otros usos comunes son el modelado

de secuencias genéticas de ADN, el modelado de textos o la extracción de información de los

mismos [Rabiner93]. Aplicaciones en las que se utilizan pueden ser: robótica, reconocimiento de

voz, genoma humano, economía, �nanzas, marketing y un largo etcétera.

Se pueden considerar como una máquina abstracta con k estados ocultos que emiten símbolos

observables de un alfabeto Σ. Cada estado tiene su propia distribución de probabilidad con lo

que la máquina varía entre los estados de acuerdo a esta distribución. Se tienen que tomar para

realizar un cambio de estado dos decisiones: ¾a qué estado se tiene que pasar?, y ¾qué símbolo

del alfabeto Σ es el que se tiene que emitir?

Los observadores pueden ver los símbolos que han sido o se están emitiendo, pero desconocen

el estado oculto en el que se encuentra el modelo HMM en cada momento. La idea subyacente

es conseguir identi�car la secuencia de estados ocultos por la que se ha ido para la obtención de

una determinada serie de símbolos.

Los parámetros de un Modelo Oculto de Markov son los siguientes:

Alfabeto Σ de símbolos que pueden ser emitidos.

Conjunto S de estados ocultos que pueden emitir símbolos del alfabeto anterior.

Matriz de transiciones T. Indicando la probabilidad de pasar de un estado s a otro estado

s.

Matriz de emisiones A para cada estado. Indica la probabilidad de emitir un determinado

símbolo del alfabeto estando en un determinado estado.

Se puede de�nir otra variable acorde a la ruta seguida a través de los estados ocultos en el

interior del modelo que se denomina habitualmente �path o hidden path�.

Se asume que en total hay N estados Sn posibles para el modelo. Además, se añade un estado

S0 en el que siempre se va a comenzar por conveniencia en la implementación. También se añade

un estado SN como el estado �nal del modelo, dado que llegado a ese punto, el modelo parará.

Se tiene a su vez un conjunto P como posibles salidas del modelo que cumplen el alfabeto Σ= {a1, a2, . . . , aP}. Si además se añade un símbolo a 0 que reprensenta la salida nula se concede

al modelo que pueda haber momentos en los que no exista ninguna salida.

Cada estado Sj tiene una distribución de probabilidad de emisión de símbolos de�nida por el

vector Aj tal que la probablidad de emisón de a cuando se esté en el estado Sj sea de�nida por

Aj (a). Se cumple que:

187

∑α∈A

A(α) = 1 ∀Sj ∈ S

Para la matriz de transiciones T, de�na de forma que Tjk es la probabilidad de moverse desde

el estado Sj al estado Sk. Denotar que las �las de la matriz generada de esta forma deben sumar

1, si bien las columnas no tienen porqué. También se tiene que resaltar que los elementos de la

diagonal de esta matriz deberán ser diferentes de cero para poder permitir transiciones de un

estado a sí mismo.

Para poder eliminar la necesidad de almacenar la distribución inicial de partida de los estados

se tiene a usar el estado comentado anteriormente S0, estado en el que el modelo siempre empieza

y no vuelve nunca a él. Esto indica que la primera columna de la matriz T esté rellena de ceros

y que la primera �la es sólo la distribución de probabilidad de comienzo de los estados.

En general por compendio se va a utilizar a partir de ahora la nomenclatura de [Rabiner93]

en la que una cadena de Markov queda completamente de�nida de la siguiente forma:

N estados ocultos.

M posibles observaciones.

Las distribuciones iniciales de los estados {π1, π2, . . . , πN}

Los estados se etiquetan como S1, S2,. . . , SN.

El número de observaciones se �ja en T y éste será a su vez el número de estados ocultos

a través de los que se ha pasado.

La secuencia de observaciones: O = O1, O2,. . . , OT .

La notación que se emplea para una determinada ruta de estados ocultos es: Q = q1, q2,

. . . , qT.

La matriz de transición entre estados ocultos se denota A y sus coe�cientes serán aij.

La matriz de emisión de símbolos por estado se denota B y es única para cada estado

oculto, por lo que sus coe�cientes en función del estado son: bi(j).

De esta forma la nomenclatura completa para una cadena de Markov viene determinada por:

λ =� N,M, {π1}, {aij}, {bi(j)} �

Los cálculos más comunes que se suelen emplear son:

Probabilidad de que una determinada secuencia siga un determinado camino en el interior

del modelo.

Probablidad de emitir una determinada serie de símbolos alcanzando el estado

188

Probabilidad de estar en un determinado estado símbolos.

Los problemas más comunes para los que se trata de buscar una solución mediante aplicación de

estos modelos [290]:

Calcular la probabilidad con la que un determinado modelo puede producir una secuencia

de observaciones.

Encontrar el camino óptimo dentro de los estados ocultos que más probablemente haya

podido generar una determinada secuencia.

Aprender un HMM que satisfaga lo mejor posible las secuencias observadas.

Para el primero de los problemas planteados, la solución pasa por calcular la probabilidad con la

que la secuencia observada se ajusta al modelo: P(O / λ). Esta útilidad permite seleccionar de

una serie de modelos, cúal es con mayor probabilidad el que la ha generado y por tanto permite

hacer una clasi�cación de la muestra adecuada.

El segundo problema implica que se tenga una observación y se quiera determinar cúal ha sido

el camino seguido en los estados ocultos. Mediante esta resolución se consigue descubrir y arrojar

luz a un comportamiento no observado directamente. Se puede a su vez dar una explicación a los

datos obtenidos al poder comprobar los estados ocultos que han sido los encargados de llegar a

ese resultado. Una de las partes más importantes que se deben de tener en cuenta en este punto

es el criterio de optimización a elegir para realizar la maximización de probabilidad, uno de los

más usados es el criterio de la semejanza, �likelihood80�.

El tercer problema que se plantea es tratar de tener un modelo completamente ajustado a

los datos de muestras observadas. Sería partir de un histórico de observaciones y a partir de ellas

tratar de inferir los parámetros pertinentes del modelo HMM. Esto se consigue mediante entre-

namiento del modelo, realizando un ajuste topológico del mismo y reestimando los parámetros

hasta que el ajuste a las muestras de partida es el mejor posible.

Sobre toda la problemática que se trata de resolver mediante modelos HMM se volverá

más extensamente y en detalle en la parte de algorítmica. Si bien es interesante mostrar la

representación de un HMM de ejemplo y la expansión posible en lo que se denomina �Trellis�:

80Likelihood, valor de semejanza, generalmente usado en logaritmos. Este concepto se ampliará en seccionesposteriores.

189

Figura 2.83: Cadena de Markov y la evolución de sus estados.

En la �gura anterior, a la izquierda se observa un HMM de ejemplo, y a la derecha se

puede observar un despliegue de hacia donde puede evolucionar cada estado en cada momento

dependiendo de la conexión que tenga con el resto. El modelo en Trellis será usado más adelante

para explicación de algoritmos.

Tipos de HMM

1. Pro�le Hidden Markov Models. PHMM

Un modelo oculto de Markov basado en per�les es una representación de un alineamiento

múltiple. Este alimenamiento múltiple es indicado para encontrar una determinada secuencia.

Generalmente se usa en biotecnología o genética. El usar este tipo de modelos se justi�ca

debido a la facilidad con la que puede cuanti�car coincidencias potenciales de nuevas secuencias

proteicas.

Figura 2.84: Ejemplo de PHMM

1. Input Driven Hidden Markov Models, IDHMM

Son modelos de Markov Ocultos que además de quedar de�nida por:

λ =� N,M, {π1}, {aij}, {bi(j)} � tienen en consideración entradas externas en cada estado

oculto en cuestión. Queda de la siguiente forma:

190

Figura 2.85: Ejemplo de IDHMM

El modelo queda de�nido por una sextuplaλ =� S,N,M, {π1}, {aij}, {bi(j)} �, donde S

son los valores �nitos de símbolos de entrada al mismo.

1. Hierarchilcal Hidden Markov Models, HHMM

Esta implementación de modelos de Markov oculto se basa en el establecimiento de una

determinada jerarquía en su interior. La parte superior de la misma por ejemplo podrían ser

estados que emitan frases, justo por debajo estarían otros modelos que representasen palabras,

silabas, cadenas cortas, etcétera. La idea es conseguir desarrollar una estructura lo

su�cienmente amplia y genérica para dar cabida a la resolución de problemas con

características determinadas. Un ejemplo aplicado a biotecnología [Skounakis+03]:

Figura 2.86: Ejemplo de HHMM

1. Coupled Hidden Markov Models, CHMM [Zhong+01]

191

Figura 2.87: Ejemplo de integración de cadenas interrelacionadas

Los ejemplos de la �gura superior indican la forma en la que se pueden integrar dos cadenas

correlacionadas/acopladas mediante una sucesión estructurada de estados ocultos. Los Modelos

de Markov Acoplados vienen dados por una necesidad de incremento de funcionalidad en los

Modelos de Markov simples. Otra aproximación para establecimiento de correlación entre estados

ocultos que se vean altamente relacionados (se incluyen en este punto los HMM Factoriales

izquierda y los HMM de Entrada-Salida):

Figura 2.88: Otra aproximación para la integración de cadenas interracionadas

Algorítmica

En la sección anterior se han descrito una serie de problemáticas a las que se puede dar

solución mediante los Modelos Markovianos. Las soluciones pasan por ajustarse a determinados

algoritmos para la realización de los cálculos pertinentes. A continuación se detalla el

funcionamiento de los algoritmos que se utilizarán:

1. Evaluación en HMM

Dada una secuencia de observaciones y, la probabilidad P(y) se calcula de las siguientes formas:

Calcular la probabilidad del camino seguido por los estados.

Calcular la probabilidad condicionada de cada símbolo emitido al estado en que se encuen-

tra dado el camino anterior.

192

Suma del producto para el camino de la probabilidad del estado por la probabilidad con-

dicionada de emitir esa observación.

P (y) =∑

x P (x, y) =∑

x P (x)P (y/x)

Esta ecuación se simpli�ca aplicando el concepto de Markov y asunciones de independencia

condicional. La probabilidad P(x) para el camino x es igual a la probabilidad inicia del estado

x0, por la probabilidad de realizar una transición del estado x0al estado x1, por la probabilidad

de pasar de x1 a x2 y así sucesivamente.

P (x) = π(x0)τ∏

t=1a(xt−1, xt)

La probabilidad P(y/x) de observar una secuencia y dado un camino x se calcula multipli-

cando la probabilidad de observar y1 después de transicionar de x0 a x1 por la probabilidad de

observar y2 despues de pasar de x1 a x2, etcétera.

P (y|x) =τ∏

t=1b(xt−1, xt, yt)

Y �nalmente si se sustituye adecuadamente en la ecuación inicial por las dos anteriores se llega

a la conclusión:

P (y) =∑

x π(xo)τ∏

t=1a(xt−1, xt)b(xt−1, xt, yt)

La evaluación directa de la ecuación anterior implica O(T NT) multiplicaciones, donde N es el

número de estados en el HMM, y donde hay NT caminos a través de la red �trellis� en que cada

uno de ellos requiere T multiplicaciones.

1. Algoritmo Fordward

Este algoritmo es una altenativa e�ciente para cuanti�car la probabilidad P(y) basado en una

programación dinámica. Este algoritmo calcula las probabilidades de secuencias de

observaciones parciales mediante el uso de probabilidades de observaciones más cortas y sus

posibles estados intermedios. Se denomina algoritmo forward debido a que funciona desde el

comienzo de una secuencia de observaciones hasta el �nal.

Si se denomina αt(j) como la probabilidad conjunta en el instante t del estado xj para la

secuencia de observación parcial y1, . . . , yt:

αt(j) = P (y1, ..., yt, Xt = xj)

193

La probabilidad P(y1, . . . , yt) puede ser calculada marginalizando Xt , esto es, sumar las

probabilidades conjuntas de observar esta secuencia y visitar el estado x en el instante t, para

todo j:

P (y1, ..., yt) =∑jP (y1, ..., yt, Xt = xj) =

∑jαt(j)

Siguiendo el razonamiento anterior se puede concluir que:

P (y) =∑jαT (j)

En base a la demostración anterior, el algoritmo forward trata de calcular los coe�cientes α

inductivamente en la forma que sigue:

α0(j) = π(xj)

αt+1(j) =∑αt(i)aijbij(yt+1), para 0 ≤ t ≤ T − 1

En particular, α0(j) se de�ne como la probabilidad inicial (a priori) del estado x , y αt+1(j) se

calcula de la forma siguiente:

Tomar el valor αt(i) para el estado arbitrario xi.

Buscar la probabilidad de transición aij para pasar del estado x al estado x.

Encontrar la probabilidad de observar yt+1 después de transicionar del estado xi al estado

xj.

Y �nalmente sumar el producto αt(i)·aij·bij·(yt+1) para todo i.

La complejidad del algoritmo forward es O(T·N2).

194

Figura 2.89: Complejidad del algoritmo Fordward

1. Algoritmo Backward

El algoritmo Backward es otro algoritmo para calcular la probabilidad P(y). Como en el

algoritmo anterior, es un algoritmo para programación dinámica. La diferencia con el anterior

radica en que trabaja desde el �nal de la observación al principio de la misma, calculando las

probabilidades de las secuencias de observación parciales, en terminos de probabilidad de

observación de secuencias más cortas, dados los estados intermedios.

Como en el anterior la probabilidad P(yt+1,. . . ,yT) puede ser calculado mediante una

marginalización de Xt: suma las probabilidades conjuntas de observar esta secuencia y visitar el

estado x en el tiempo t, para todo i:

Donde βT(i) denota la probabilidad de observación de la secuencia yt+1, . . . , yT, cuando el

estado xi se visita en el instante t: βT(i)=P(yt+1,. . . ,yT / Xt = x). Teniendo en cuenta que

P(X0 x) = ) se concluye que:

195

Los valores de β se pueden calcular de la forma siguiente:

Particularmente, βT(i) se inicializa a 1 y βt(i) se procesa así:

mirar la probabilidad de transición para pasar del estado x al estado x

observar la probabilidad de que se de una muestra y en la transición de x a x.

Buscar el valor βt(j) para el estado x, que será la probabilidad de observar la secuencia

(y,. . . ,y) dado x en el instante t.

Sumar el producto a b (y) β(i) para todo i.

La complejidad del algoritmo backward es de O(T N2).

Figura 2.90: Complejidad del algoritmo de Backward

196

1. Algoritmo Fordward-Backward

El objetivo del algoritmo Forward-Backward es aglutinar de alguna forma los valores α del

algoritmo forward y los valores β del algoritmo backward. Esto es:

Luego, mediante la marginalización de Xt, se consigue:

1. Filtrado y suavizado de las probabilidades. Filtering and Smoothing algorithms

Las probabilidades se pueden �ltrar de forma sencilla mediante el uso de los valores [F103?]

para las muestras entre los instantes: 0 ≤ t ≤ T.

Las probabilidades suavizadas son calculadas mediante el uso de los valores [F103?] y β para

las muestras entre los intantes: 0 ≤ t ≤ T.

197

1. Decoding Algorithm (Vitervi)

El problema de la decodi�cación consiste en encontrar una ruta que maximice la probabilidad

de pasar por esos estados dada una secuencia de observaciones. Como la secuencia de

observaciones es dada, P(y) es constante con lo que:

Cualquier camino de estados ocultos que pertenezca a la maximización arriba indicada es una

solución válida para el problema de la decodi�cación.

El algoritmo de Vitervi resuelve el problema de la decodi�cación encontrando subrutas

(x0, ..., xt) tales que ∈ arg max{x0, ..., xt}P (x0, ..., xt, y1, ..., yt).

Si se de�ne:

El algoritmo de Vitervi se calcula inductivamente como sigue:

Simultáneamente, el algoritmo almacena los estados que comprenden el camino más probable:

Para calcular el camino más probable, se va hacia atrás en la traza en la forma que se detalla a

continuación:

198

Donde ahora se puede realizar:

Y en particular:

Figura 2.91: Cálculo del algoritmo de Viterbi

El problema del aprendizaje en HMM

Si se consiguieran pares de valores de estados y observaciones en la forma {(x1,y1),. . . ,(xn,yn)}

sería una cuestión muy sencilla la estimación de los parámetros de una cadena de markov

oculta, HMM λ = (π,A,B)Para maximizar la semejanza81 de los datos al modelo se usarían

81Semejanza o Likelihood. Valor, logaritmico generalmente, que indica la probabilidad de que una muestra seajuste a un determinado modelo de Markov Oculto: P(Muestra/Modelo).

199

contadores frecuenciales relativos para estimar las probabilidades iniciales, de transición y de

emisión:

Donde #Z indica el número total de ocurrencias de un determinado evento Z.

En general, sin embargo, los datos de esta forma no están disponibles. Como su propio nombre

indica, la información de los estados está oculta en un HMM.

1. Algoritmo Baum-Welch

El algoritmo Baum-Welch, es un algoritmo destinado al aprendizaje de parámetros de un HMM

dada una secuencia de observaciones.

Si se denota:

Se puede derivar en base a los algoritmos anteriores:

200

La metodología a seguir para calcular el algoritmo Baum-Welch es la siguiente:

Inicializar λ = (π,A,B)

Iterar hasta conseguir que [λ = (π,A,B)] = [λ′ = (π′, A′, B)]

• Maximización

◦ Ejecutar algoritmo forward para calcular:

◦ Ejecutar algoritmo backward para computar:

◦ Para 1 ≤ t ≤ T, calcular:

• Expectación:

◦ Estimar las probabilidades iniciales:

201

◦ Estimar las probabilidades de transición de i a j :

◦ Estimar la probabilidad de transición de i a j y emitir el símbolo k :

◦ Modelo:

1. Algoritmo Bayesian Merging

Introducción

Este algoritmo propuesto en el año 1994 con referencia [308], ha sido la base para el

aprendizaje automatizado en las partes que conllevan cadenas de Markov.

En el esquema general se pueden encontrar tres tipos de gramáticas probabilísticas:

n-gramas

Modelos de Markov Ocultos (HMM)

Gramáticas estocásticas de Contexto-Libre. (SCFG, Stocastic Context-Free Grammars)

En todas las anteriores sería aplicable este algoritmo en particular.

Problemas a solventar

202

La problemática se �ja en encontrar o aprender modelos aplicables a un conjunto de muestras

determinado.

Los modelos probabilísticos más comunes se pueden caracterizar por dos partes:

una estructura discreta (la topología de un HMM, el backbone de contexto libre en un

SCFG)

y una serie de parámetros discretos/contínuos que determinan las probabilidades de las

observaciones que integren el modelo.

El problema radica en la determinación de la estructura. Se ha visto en el apaartado anterior

que el algoritmo baum-welch de partida necesita un modelo base. El hecho de requerir un

modelo de partida obliga a determinar de antemano el número de estados que va a disponer el

modelo en cuestión. Una vez �jada la estructura, los parámetros pueden ser ajustados usando

los métodos estandar, como la maximización de similitud82 (ML).

En los modelos de variables/estados ocultos (HMM, SCFG) la estimación típicamente involucra

EM (Expectation Maximization, ej. Baum-Welch), acertado para estructuras pre�jadas, dado

que puede aprender cualquiera de los comoponentes de un modelo de markov oculto:

λ = (π,A,B):

Explicación funcional

El método denominado Bayesian Merging se puede usar tanto en HMM como en SCFG. Se

trata de realizar diferentes operaciones de unión de subestructuras de un modelo base tratando

de maximizar la probabilidad posterior bayesiana del mismo en base a los datos dados.

Este método se ha propuesto como una alternativa e�ciente, robusta, y cognitivamente plau-

sible para la construccion de modelos probabilisticos en una amplia variedad de dominios.

Este método se ha propuesto como una alternativa e�ciente, robusta, y cognitivamente plau-

sible para la construccion de modelos probabilisticos en una amplia variedad de dominios.

Este algoritmo se puede caracterizar de la siguiente forma:

Incorporacion de datos: Dado un cuerpo de datos X construir un modelo inicial M mediante

la acomodación explícita de cada punto individualmente, tal que, Maximice la probabilidad

P(X|M)83. El tamaño del modelo inicial crecerá con la cantidad de datos y no exhibirá

normalmente una generalización signi�cativa.

82Maximización de similitud o semejanza o likelihood. Explicada anteriormente en la parte algorítmica.83Donde X será la secuencia de observaciones y M será el modelo HMM en este caso.

203

Mezcla de estructura: Consiste en la construcción de una secuencia de nuevos modelos ob-

teniendo M a partir de M mediante la aplicacion de una generalizacion o merging (operador

m) que se une a la subestructura en M.

En resumen, consiste en construir un modelo base de partida introduciendo explícitamente

cada punto de datos individualmente, de modo que el modelo M0 maximize la similitud

P(x/M). Esto quiere decir que para cada muestra se tenga la probabilidad más elevada posible

de producirla con el modelo M planteado.

Después de este paso se construye una secuencia de nuevos modelos a los que se le aplica un

operador o función de mergingM i+1 = m(Mi). Las operaciones que realiza �m()� son dependien-

tes del tipo de modelo, pero en general todo modelo se puede explicar por unas subestructuras

separadas.

Para comprobar la bondad de ajuste de un modelo i+1 con respecto al anterior se utiliza la

fórmula de Bayes (probabilidad posterior):

Esta fórmula como se puede apreciar es proporcional a la probabilidad apriori P(M) y a la

similitud P(x/M). El denominador a la hora de realizar la maximización no necesita ser tomado

en consideración, no depende de M, con lo que puede ser ignorado.

Por último, se necesita encontrar una estrategia para encontrar modelos con la más alta

probabilidad posterior posible. La que se usa en este caso es la denominada BEST-FIRST.

Empezando con el modelo inicial (maximiza la similitud, pero tiene generalmente una baja

probabilidad apriori) se exploran todos los posibles pasos de mezcla (merging). Sucesivamente se

va escogiendo uno (greedy search, búsqueda ávida) o unos (beam search, búsqueda de haz) que

den el mejor incremento inmediato en la probabilidad posterior.

En la práctica, para mantener funcionando correctamente a los modelos en un tamaño mane-

jable, se puede usar una versión "on-line" para el algoritmo de mezcla, en el cual la incorporación

y los estados de mezcla/búsqueda estén intercalados.

Aplicación del modelo de mezcla en las gramáticas probabilísticas.

204

El caso que se esta estudiando se centra en los modelos de Markov Ocultos, HMM. La

aplicación del modelo de mezcla en estos modelos se realiza acorde a lo explicado en los

siguientes párrafos:

1. Para cada muestra observada se crea una única ruta (path) entre el estado inicial y el

�nal asignando un nuevo estado para símbolo token en la misma. Es decir, si se dan los

datos ab, abab el modelo inicial es el siguiente:

2. En el proceso de mezcla, dos estados antiguos del HMM son reemplazados con un único

nuevo estado. Éste estado hereda la unión de las transiciones y emisiones de los estados

anteriores. Una muestra para el ejemplo anterior:

205

3. El punto crucial es que cada uno de estos modelos puede ser encontrado maximizando la

probabilidad posterior del HMM. El punto de parada es cuando se consigue un modelo

que produce un salto muy elevado en el término de similitud, decrementando

considerablemente la probabilidad aposteriori del modelo.

Distribuciones previas.

La aproximación se elige de forma "desinformada apriori", esto amplía la probabilidad apriori a

lo largo de todos los posibles HMM�s sin dar preferencia explícita a topologías particulares. Un

modelo M es de�nido por su estructura M y sus parámetros continuos θ. De esta forma se

puede descomponer la probabilidad del modelo apriori en lo siguiente:

206

Además hay que tener en cuenta que las estructuras de los modelos reciben la probabilidad

apriori de acuerdo a su longitud de descripción:

l(M) es el número de bits necesarios para codi�car M, por ejemplo: número de bits necesarios

para codi�car todas las transmisiones y emisiones.

Las probabilidades apriori para θ , son asignadas en base a la distribución de Dirichlet para

cada parámetro multinomial de transición y emisión, parecido a un arbol de decisión Bayesiana

[Buntine92]. Por conveniencia del modelado se asume que los parámetros asociados a cada estado

son apriori independientes.

Hay tres formas intuitivas de conocer el por qué las simples prioridades como las planteadas

en este apartado pueden conducir a probabilidades posteriores mayores para los modelos HMM.

Estas aproximaciones se demuestran debido a:

Las topologías pequeñas tienen una longitud de descripción menor, y por ello una probabi-

lidad apriori mayor. Esto se corresponde con la intuición de que una estructura más grande

necesita ser seleccionada de un mayor rango de posibles alternativas equiprobables, por lo

que cada elección individual es menos probable en forma a priori.

Los modelos más grandes tienen más parámetros, por ello se hace que cada parámetro en

particular sea menos relevante. Se conoce también como factor de Occam [Gull98].

Después de que dos estados hayan sido unidos, la cantidad de datos efectiva para cada

parámetro se aumenta (la evidencia para las subestructuras mezcladas se junta). Esto

cambia y encumbra las distribuciones posteriores para esos parámetros más cercanos a las

con�guraciones de máxima similitud.

1. Cómputo Posterior

El objetivo del procedimiento de inferencia es la estructura del modelo, luego como se ha dicho,

el objetivo es maximizar la probabilidad posterior del modelo:

207

El motivo matemático para maximizar la parte estructural en vez de simplemente P(M/x),

es que con �nes inferenciales un modelo con una estructura posterior elevada representa mejor

la aproximación del procedimiento óptimo de Bayes para promediar todos los posibles modelos

M. Esta a�rmación anterior se puede calcular de la siguiente forma:

Si bien, puede ser aproximada usando la suposición común de Vitervi sobre las probabilidades

en los HMM�s.

208

Cuadro 2.5: Implementación del algoritmo

209

Otras cuestiones de implementación relacionadas

• Incorporacion e�ciente de muestras:

En el caso más simple este paso crea un estado dedicado para cada instancia de símbolo en

cada una de las muestras X. Estos estados son enlazados con transiciones de probabilidad a 1,

de tal modo que una muestra (x...x) es generado por una secuencia de estados (q...q). q puede

ser alcanzado desde q a través de una trasición de probabilidad 1/X, donde X es el número

total de muestras. Todos los estados emiten su correspondiente símbolo de salida xi con una

probabilidad de uno.

De esta forma, muestras repetidas llevan a multiples caminos a lo largo del modelo, todos

ellos generando el mismo string de entrada. La probabilidad total de un string x de acuerdo al

modelo inicial es entonces c(x)/X (la frecuencia relativa del string x). Como se ha introducido

anteriormente de esta forma se constituye el modelo de maxima similitud con los datos de X.

Denotar que los estados correspondientes en caminos equivalentes podrían ser mezclados sin

tener por ello una perdida en la similitud del modelo. Esto es básicamente lo que va haciendo el

algoritmo en las fases iniciales.

Una optimización en este estado es evitar la multitud de rutas y comprobar para cada nueva

muestra si ya esta introducida en una ruta existente. Caso de que sea de esta forma sólo habra que

actualizar la probabilidad de transmision inicial. Usando una extension del algoritmo de Viterbi,

la nueva muestra puede ser alineada con los estados existentes en el modelo, reclutando nuevos

estados sólo cuando y donde sea necesario. Este alineamiento no tiene efecto en las posibles

mezclas, no va a generar ciclos, pero si que puede reducir el número inicial de estados en el

modelo.

Cálculo de los candidatos a mezclarse

El caso general es examinar todos los posibles pares de estados en el modelo actual:

Como se puede apreciar, lo mejor es mantener el modelo con pocos estados, para evitar unos

costes elevados de cómputo. El coste de una mezcla está generalmente dominado por el coste de

mezclar las distribuciones de salida de los estados involucrados. Debido a lo anterior, conviene

en este caso indexar los estados de acuerdo a sus características de emisión y considerar solo

pares de estados que tengan similares entradas. Esta restricción se podría eliminar más adelante

después de que se hayan agotado todas las posibilidades de mezclas. El bene�cio es claro, dotar

210

al algoritmo de rapidez, y en casos de uso incremental previene de mezclas prematuras que a la

luz de nuevos datos deberían mantenerse separadas.

Evaluación del modelo usando rutas de Vitervi

Para encontrar la probabilidad posterior de un modelo potencial, necesitamos evaluar la

estructura inicial P(M).

El objetivo de la maximización puede ser MAP (Maximun Posterior Probability), cuyos

parámetros pueden calcularse a través del algoritmo Baum-Welch, teniendo en cuenta la condición

de inicio de Dirichlet tomada.

Por otro lado otro objetivo puede ser la evaluación de P(x/M s), cuya solución no tiene una

solución obvia. Para solventar esta situación y la anterior se puede hacer uso de la aproximación

de Vitervi.

Computación de similitud

La probabilidad exacta de la similitud de un modelo con referencia a un cojunto de datos X, es

dada por el producto de cada una de las probabilidades de la muestra con la siguiente ecuacion:

Esto se puede leer como el productorio de la probabilidad de todas las muestras posibles que

haya. Y la probabilidad de las muestras se puede obtener calculando sucesivamente la proba-

bilidad de pasar del estado Inicial al estado 1 por la probabilidad de que el estado 1 emita el

símbolo x1 de la muestra... y as sucesivamente hasta llegar al �nal del "string" /Muestra/Cadena

en cuestión.

La aproximación de Viterbi implica el reemplazo de los sumatorios de todas las muestras por

los terminos con la contribucion mas elevada:

Los términos en esta expresión pueden ser agrupados por estados, llegando a la forma:

211

En esta ecuación anterior los componentes c(q→q�) y C(c→σ) son los contadores totales de

transiciones y emisiones que ocurran a lo largo de las rutas Viterbi asociadas a las muestras de

X. Si se usa la notación de c(q) para la colección de contadores de Vitervi asociados con el estado

q, la fórmula anterior quedará:

MAP parameter estimation.

Para estimar aproximadamente el parametro MAP basado en contadores de ruta Viterbi se han

de modi�car los parametros para incluir las condiciones de Dirichlet.

Para implementar esta evaluacion hace falta aproximar la siguiente integral:

Aplicando una serie de aproximaciones basadas en las rutas óptimas de Vitervi y aplicación

de las prioridades de Dirichlet se puede llegar a obtener una formula más simple.

Actualizacion de ruta usando Viterbi de manera optimista.

Consiste basicamente en creer que los estados mezclados preservan las rutas de maxima

representacin de Vitervi. Para ello se requiere que los contadores intermedios de Vitervi se

mantengan durante la fase de mezcla.

212

Capítulo 3

ESIDE-Mendizale Un Framework

Bayesiano de detección de intrusiones

En este capítulo se explica el modelo conceptual de la solución dividiendo éste en nueve pun-

tos, según el modelo conceptual propuesto por Emilie Lundin. Dichos puntos son: Formalización,

Captura de información, Análisis, Respuesta, Fortaleza, Cuestiones operacionales, Evaluación

y Aspectos sociales. De esta forma se obtiene una visión global del Modelo Conceptual de la

solución propuesta.

3.1. Análisis de riesgos y formalización

Este aspecto es fundamental a la hora de la implementación del modelo puesto que estos

parámetros constituyen las variables que tendra éste. Para dilucidar cuáles serian los parámetros

sensibles de mostrar una actividad anómala de los procesos, se ha realizado un estudio, primero

del estado del arte en cuestiones de sistemas de monitorización de actividad de sistemas, que

puede verse en puntos anteriores. Así como un estudio de cuáles pueden ser los valores susceptibles

de ser monitorizados para detectar dicha actividad anormal.

3.1.1. Posibles parámetros

En este punto se hace un repaso de todos parámetros manejados durante el desarrollo del

proyecto. Estos parámetros son medidas que se toman en los sistemas monitorizados, que per-

miten dilucidar si el equipo se encuentra comprometido o no. Para obtener dichos parámetros,

se han seguido las variables que un estudio previo de las soluciones ya realizadas en éste ámbito

utilizaban para sus desarrollos.

Estos parámetros se pueden dividir en dos grandes grupos muy diferenciados, por una

parte, las medidas que se pueden utilizar para realizar un pro�ling de usuario [236], que

sirven para dilucidar si lo que el sistema está realizando es lo que el sistema suele realizar

213

Figura 3.1: Imagen del monitor de anomalías desarrollado por Teresa F.Lunt y R. Jagannathan.

para un usuario concreto, y por otra parte los parámetros que persiguen dilucidar si un

proceso realiza las acciones que suele realizar.

Estas dos aproximaciones permiten detectar las intrusiones a dos niveles completamente diferen-

tes: por una parte, la detección de intrusiones basada en pro�ling de usuario, permitiría detectar

intrusiones a nivel de usuario, es decir, podría resolver que el usuario actual, no es1 el usuario

que conocía. El otro método, permite controlar la utilización anómala de los recursos para cada

proceso. Es decir, permite realizar un pro�ling de procesos.

Cada una de las técnicas conllevan un tipo de detección diferente y unos resultados diferentes

que se comentarán en los siguientes apartados.

Parámetros de pro�ling de usuario

Estudios anteriores[236], demuestran que un pro�ling de usuario, permite grandes tasas de

acierto sobre la variación de comportamientos de usuario, observando cierto numero de paráme-

tros que permiten discernir un usuario sobre otro. Por lo tanto este método, aprendiendo el per�l

de un usuario, se puede llegar a detectar una utilización anómala, tal y como habían anticipado

mucho tiempo antes[21].

Este sistema de pro�ling de usuario para detección ha sido implementado por varios [236, 21,

117] sistemas, los cuales se enumerarán los parámetros que han manejado para dichos trabajo.

Teresa F. Lunt and R. Jagannathan, Experto de detección de intrusiones

El documento [236], expone la creación del experto de detección de intrusiones basado en

un experto que generaba per�les de los usuarios. En dicho trabajo, utilizaban los siguientes

parámetros, divididos en dos grandes grupos, variables discretas y continuas:

1O al menos se comporta de una manera totalmente diferente.

214

Variables discretas: Este tipo de variables tienen un rango de valores �nito, se trata de un

conjunto de valores que se utilizan para caracterizar aspectos del usuario. Cada per�l de

usuario está compuesto en parte por un conjunto de variables discretas y la probabilidad

de que el usuario cumpla dicho valor.

1. �Time of login�: Se trata del número de sesiones que un usuario inicia en un periodo de

veinticuatro horas. Asimismo, cada periodo de veinticuatro horas se encuentra dividido en

tres categorías diferentes: el periodo de día, periodo de tarde y periodo de cementerio2, el

cuál no debería haber nadie. Cada login es caracterizado en alguno de estos tres periodos.

2. �Location of login�: Localización del login, es el número de sesiones que un determinado

usuario ha iniciado en un determinado lugar. La estación desde la que se conecta el usua-

rio, puede bien estar directamente conectada con el servidor, bien puede estar conectado

mediante un multiplexor, o estar conectado remotamente. Cada localización diferente sería

un valor discreto dentro de la localización del login.

Variables continuas: Este tipo de variables tienen un rango de valores in�nito, es decir, que

pueden tomar cualquier valor, dado que son variables que van aumentando (los valores se

van acumulando), conforme la sesión va avanzando. Cada per�l de usuario, maneja una

probabilidad condicionada de que se den los valores acumulados medios de las sesiones

anteriores. Asumiendo distribuciones normales a este tipo de variables se puede conseguir

el porcentaje de ajuste del valor actual con la normalidad3. Para realizar el estudio normal,

se utilizaron los valores de los último 50 días para poder permitir un grado de cambio

gradual a los usuarios. Las variables estudiadas fueron las siguientes:

1. �Connect time�: Tiempo de conexión, que es la duración de una sesión en un sistema. Como

un sólo usuario puede iniciar varias sesiones en un mismo sistema4, se identi�ca cada una

de las sesiones con un identi�cativo de trabajo, y cuando se acaba la sesión, se cierra cada

uno de los trabajos creados.

2. �CPU Time�: Tiempo de CPU, es la suma del tiempo de procesamiento utilizado en una

sesión.

3. �IO Activity�: Actividad de entrada y salida, la suma de las actividades de entrada / salida

realizadas en una sesión.

4. �Protection Violations�: Violación de protecciones, es el número de violaciones de acceso

de los permisos acumulados en la sesión.

2Traducción literal de �Graveyard period�, supuestamente en este periodo de tiempo no debería haber ningúntipo de actividad en el sistema auditado. Considerando el inglés estadounidense también puede ser una variaciónde Graveyard shift, que signi�ca turno de noche.

3Asumiendo que las interacciones anteriores eran interacciones normales.4Como es usual en sistemas Unix-Like.

215

Este sistema desarrollado, permitía detectar el 95% de los ataques �masquerade�5, en tiempo real,

mostrando una interfaz que permitía al administrador de sistemas de conocer y tomar contra los

eventos anómalos detectados con el conjunto de parámetros anteriores.

Dorothy Denning

Dorothy Denning en su documento[105] establece un modelo en el que de�ne los siguientes

parámetros, todos ellos discretos para determinar si un sistema estaba siendo comprometido.

1. Frecuencia de login: Se trata de un parámetro discreto que re�eja las veces que un usuario

se conecta a un servidor. También puede interpretarse como un parámetro para IDS de red

si se considera contra un servidor.

2. Frecuencia de localización: Parámetro discreto a nivel de host que re�eja, como su nombre

indica las veces que se conecta un usuario desde un determinado lugar. También se puede

interpretar como parámetro a nivel de red si la validacion se hace contra un servidor.

3. Ultimo login: Parámetro discreto a nivel de host re�eja como su nombre indica cuando se

produjo el último login del usuario. También se puede interpretar como parámetro a nivel

de red si la validación se hace contra un servidor.

4. Tiempo entre sesiones: Parámetro discreto a nivel de host que re�eja, como su nombre

indica, el tiempo entre dos sesiones. También se puede interpretar como parámetro a nivel

de red si la validación se hace contra un servidor.

5. Output de la sesión: Este parámetro indica la cantidad de trá�co generada durante una

sesión.

6. Carga de CPU, IO,... etc de la sesión: Se trata de un parámetro discretizado, que marca la

carga de entrada/salida y CPU que genera una sesión. Este parámetro puede considerarse

continuo, y suponer que sigue una ley normal para poder obtener una salida que marcase

la normalidad del mismo. D. Denning, ha discretizado este dato, en vez de utilizar leyes

normales para tratar estos parámetros.

7. Numero fallos en contraseña: Parámetro discreto a nivel de host re�eja, como su nombre

indica, el intentos de validación fallidos. También se puede interpretar como parámetro a

nivel de red si la validación se hace contra un servidor.

8. Frecuencia de ejecución: Parámetro discreto a nivel de host re�eja, como su nombre indica,

la frecuencia con que se ejecuta un determinado programa.

9. Numero de ejecuciones denegadas: Parámetro discreto a nivel de host que indica el número

de ejecuciones denegadas de un determinado programa.5Ataque de suplantación de usuario.

216

10. Carga de CPU, IO,... etc del programa: Parámetro discreto a nivel de host re�eja, como

su nombre indica, el throughput de un determinado programa.

11. Numero de veces que un programa se queda sin recursos: Parámetro discreto a nivel de host

que indica el número de veces que un determinado programa se queda sin recursos.

12. Frecuencia de lectura, escritura, creado y borrado de un �chero: Parámetro discreto a ni-

vel de host que re�eja, como su nombre indica, la frecuencia de operaciones IO de un

determinado programa sobre los �cheros.

13. Registros leídos/escritos: Parámetro discreto a nivel de host que re�eja, como su nombre

indica, la frecuencia de operaciones IO de un determinado programa sobre los �cheros.

14. Fallos de lectura, escritura, creado y borrado de un �chero: Parámetro discreto a nivel de

host que re�eja, como su nombre indica, los fallos de operaciones IO de un determinado

programa sobre los �cheros.

15. Fallos por excesivo uso de recursos por parte de un �chero: Parámetro discreto a nivel de

host que indica el número de veces que un determinado �chero se queda sin recursos.

Una idea que se puede extraer de este documento es la organización del modelo en una serie de

planos o esferas conceptuales que represente diversos aspectos tales como tiempo, lugar por poner

algunos ejemplos sencillos. De esta forma se tiene un plano temporal, un plano de ubicación. Así

se podría conseguir analizar datos heterogéneos de forma homogénea muy fácilmente.

Además también se pueden ver dos aspectos importantes de los planos en los que se está

dando la auditoría en el sistema, tanto a nivel de proceso, como a nivel de usuario, para poder

monitorizar a nivel de usuario, o de proceso.

Parámetros de pro�ling de proceso

Como se ha explicado anteriormente existen multitud de parámetros para modelizar el com-

portamiento de un usuario para con el equipo, pero muchos ataques no se producen por suplan-

tación de usuario, sino que se dan al hacer que un proceso presente un comportamiento diferente

al que debería llegar. Por lo tanto, para llegar a detectar ataques que no son de suplantación de

usuario, habría que llegar a un nivel mas bajo: al pro�ling de proceso[285].

Primeramente, hay que hacer una diferenciación entre el código fuente y los procesos. Los

procesos, son código fuente en proceso de ejecución, es decir el código fuente6 solo es el guión de

lo que se ejecuta, luego lo que se ejecuta es el código fuente cargado en memoria, con sus valores

su puntero de ejecución y su pila de valores, es decir, un proceso.

Cuando los procesos se están ejecutando, no interactúan directamente sobre el hardware del

sistema, sino que utiliza la abstracción que el sistema operativo provee a los programas para con

6También conocido como código muerto.

217

los componentes. Si este sistema no funcionase de esta manera, el software sería especi�co de

una máquina concreta, dejando de funcionar cuando el software se ejecute sobre un hardware

diferente.

Para que este echo ocurra7, el sistema operativo provee de un conjunto de rutinas

que abstraen a al software de los entresijos del funcionamiento del hardware, y permiten

ejecutar códigos fuente entre diferentes máquinas con diferente HW8. Los mismos formatos eje-

cutable (Tanto PE para sistemas Windows como los COFF para formatos Unix), funcionan de

esta manera, reservando espacio para las llamadas a el núcleo que realiza el acceso al Hardware.

Figura 3.2: Arquitectura interna de los sistemas operativos

De la misma manera la arquitectura de los procesadores actuales, implementan en Hardware

todas estas capacidades de los sistemas operativos. Existen varios niveles de privilegio (también

conocidos como Rings), los cuales implementan a nivel hardware el funcionamiento interno del

sistema operativo descrito anteriormente.

Por lo tanto, para realizar un pro�ling de proceso, hay que monitorizar la actividad del

proceso, esta actividad puede abordarse mediante dos perspectivas diferentes, monitorizando la

interacción de los procesos con el kernel, o observando externamente al proceso.

Parámetros de monitorización externa de procesos.

Los parámetros de monitorización externa de procesos, realizan un per�l del aspecto externo

del proceso, es decir, sin analizar ningún tipo de llamada al sistema.

Estas variables son varias de las que explica D. Denning[105] en el artículo de monitorización

de usuarios. Estos parámetros son:

Consumo de memoria de un proceso.

E/S de un proceso.

7Que exista la posibilidad de ejecutar software sobre plataformas Hardware diferentes.8Pos supuesto, nos referimos a HW similar, pero distinto, por ejemplo la utilización de un procesador AMD

o intel ó una tarjeta ATI, o una tarjeta Nvidia; en ningún caso cambios de HW tan grande que afecten a losprogramas de zona de usuario como puede ser la utilización de una arquitectura de 64 y 32 bits.

218

Figura 3.3: Abstracción a dos niveles en sistemas Linux

Consumo CPU de un proceso.

Frecuencia de ejecución.

Fallos de escritura / lectura.

Fallos en los permisos.

Hay que resaltar que el método de monitorización externa de procesos, presenta un alto índice

de fallos, dado que los parámetros considerados, son susceptibles a grandes cambios por la carga

del sistema, y no sólo a la acción de ataques y /o intrusiones tanto externas como internas.

Parámetros de monitorización interna de procesos.

Los procesos, en los sistemas operativos modernos necesitan acceder a servicios provistos por

el sistema operativo para realizar acciones para con su entorno. Esta abstracción, permite que

un mismo código pueda ejecutarse en diferentes sistemas.

Pero esta abstracción no es la única que existe, dado que la cantidad de hardware disponible,

y lo diferentes que son entre sí, hacen que una API de kernel permanente y estándar sea algo

excesivamente rígido, por lo que también se da una abstracción a nivel de usuario, mediante

librerías, que son las que realizan las llamadas a las funciones del Kernel. En los sistemas Win-

dows, la API al nivel de aplicación (en ring3), es conocida como la API Win32, que se encuentra

implementada en diversas DLL del sistema. En los sistemas Linux, esta API, es conocida como

la glibc, aunque también existen otras librerías menos importantes que también llaman al kernel,

como pueden ser la X11 o la librería de sincronización pthread, las cuales están recogidas en el

estándar POSIX.

Por lo tanto, en todos los sistemas operativos modernos, existen dos tipos de posibilidades

para realizar una monitorización interna de procesos, una de ellas, monitorizando las llamadas

219

a la librerías que implementas las API a nivel de usuario, es decir, monitorizar las llamadas a

las librerías Win32, glibc... o bien realizar una monitorización a nivel de llamadas desde dichas

librerías al kernel.

Las llamadas a las librerías de zona de usuario que abstraen las llamadas al kernel, y la

intercepción de este tipo de llamadas producirían una salida de más alto nivel, que permitiría

generar un pro�ling a mayor nivel, pero como contrapartida, se genera gran cantidad de informa-

ción que puede considerarse como ruido. Este inconveniente puede enmascarar las evidencias que

muestran un ataque. En éste ámbito existen varios sistemas[140]9, que implementan la captura

de datos a este nivel.

Tal y como se comenta en estudios anteriores[247], la monitorización de todas las llamadas

de este tipo causa una gran sobrecarga sobre el sistema dado que los programas actualmente

hacen un uso exhaustivo de las rutinas en este tipo de librerías. Pero lo que también se re�eja en

el estudio es que resultaría altamente interesante monitorizar algunas de las llamadas a librerías

externas como pueden ser por ejemplo el API de Winsock10 en sistemas Windows.

El prototipo de estas funciones es en C, y exportan servicios a los programas para que éstos

los consuman.

Listing 3.1: Prototipo de función VirtualAlloc de la API Win32.

LPVOID Vi r tua lA l l o c ( LPVOID lpAddress ,

2 SIZE_T dwSize ,

DWORD f lAl locat ionType ,

DWORD f lP r o t e c ) ;

Listing 3.2: Prototipo de la función malloc para sistemas linux provista por el API de glibc.

void ∗malloc ( s i ze_t s i z e ) ;

La otra opción de monitorización interna de procesos son las syscalls o llamadas al sistema

que generan los programas, éstas bien pueden estar generadas por las librerías o directamente por

los programas que llaman a la función sysenter o bien la interrupción 2e en sistemas Windows o

a la interrupción 80 en sistemas GNU/linux.

Este tipo de parámetros han sido utilizados en estudios anteriores [279, 374, 37, 199, 126,

375, 194], estando demostrado[134] que una alteración del comportamiento o de la naturaleza de

los procesos provoca un cambio de las syscalls que se ejecutan en el nivel privilegiado del sistema

operativo.

Estas llamadas, están formados por un código de función11, y por un número variable de

9También existe para los sistemas GNU/Linux, las librerías ltrace, que permiten una auditoría de los programasa este nivel de abstracción.

10Especi�cación de la API de comunicación mediante red en sistemas Windows, actualmente se encuentra enla versión número dos. Mas información en http://www.sockets.com/.

11Que se almacena en el registro eax del procesador cuando se realiza la llamada a la interrupción.

220

argumentos que se almacenan también en los registros. Por lo tanto cada llamada al sistema

posee un prototipo, identi�cado por un número de llamada.

Listing 3.3: Prototipo de syscalls write (código 4) y kill (código 37) de sistemas GNU/linux

long k i l l_saved ( pid_t , int ) ;

long write_saved ( int , const char ∗ , s i z e_t ) ;

Listing 3.4: Prototipo de la función NTCreateFile del kernel de Windows

NTSTATUS NtCreateFi le ( PHANDLE FileHandle ,

ACCESS_MASK DesiredAccess ,

POBJECT_ATTRIBUTES ObjectAttr ibutes ,

4 PIO_STATUS_BLOCK IoStatusBlock ,

PLARGE_INTEGER Al l o ca t i onS i z e ,

ULONG Fi l eAt t r i bu t e s ,

ULONG ShareAccess ,

ULONG CreateDi spos i t i on ,

9 ULONG CreateOptions ,

PVOID EaBuffer ,

ULONG EaLength ) ;

3.1.2. Selección realizada

Finalmente los parámetros utilizados para el proyecto han sido las syscalls o llamadas al

sistema, los argumentos a favor de esta decisión se encuentra detallada a continuación:

Realiza un modelado del comportamiento de cada proceso: Es decir, no solamente genera

per�les de los usuarios[236], sino que se realiza un pro�ling de proceso, el primer enfoque

es particularmente preciso a la hora de reconocer ataques de suplantación pero hoy en día

uno de los mayores problemas con los que se encuentra la seguridad hoy en día son los

conocidos como bu�er over�ows12[269], que modi�can el comportamiento de cada proceso

para poder realizar acciones arbitrarias sobre el sistema a nivel de proceso. Con el pro�ling

de usuario, los ataques realizados mediante bu�er over�ows puede ser detectado, pero será

inherentemente mas lento e inexacto que un pro�ling de proceso en el cuál se mantiene

un modelo de proceso y no de usuario; detectando inmediatamente si un proceso está

realizando acciones arbitrarias que no debería ejecutar dicho proceso con respecto a la

normalidad.12También conocidos como desbordamiento de bu�er, se trata de realizar sobre los programas acciones que per-

mitan ejecutar código arbitrario. Usualmente se utiliza la técnica de sobreescribir mediante copias no controladasel valor de retorno almacenado en la pila del proceso.

221

Se trata de un mecanismo similar en todos los sistemas operativos modernos: La mayoría

de lo sistemas operativos modernos implementan un mecanismo de comunicación entre los

procesos en zona de usuario y el kernel en ring 0, con privilegios para ejecutar cualquier

acceso al hardware, y es similar en todos los sistemas estudiados, lo que reduce los problemas

de integración entre los datos de diferentes plataformas.

En casi todos los sistemas operativos se encontraban ya implementados[375, 38] sistemas

de recogida de datos parecidos al que habíamos de implementar. Esto presenta la ventaja

de que se sabe de antemano que la auditoría de dichos parámetros es posible.

Permite la correlación de syscalls entre diferentes sistemas, es decir, se puede realizar un

estudio de las syscalls que genera un proceso apache (por poner un ejemplo) en un sistema

GNU/Linux y en un sistema Windows.

Genera una menor cantidad de información, el sistema implementado necesita la mayor

brevedad posible para poder tomar acciones con la mayor brevedad posible, y un volumen de

datos mayor[247] aumenta el tiempo necesario para aprender tanto la normalidad como para

aprender la estructura de los datos aprendidos. Aunque, conceptualmente puede percibirse

que parte de la información vital para la detección de anomalías se haya perdido, en realidad

dichas anomalías se encuentran también[134] en las syscalls de más bajo nivel. De esta

manea al reducir la cantidad de datos, se elimina una gran cantidad de ruido13.

A menor nivel que la mayoría de infecciones de malware, la mayoría[315, 247] de las infec-

ciones de malware utilizan la técnica de interceptar las llamadas a nivel de API del sistema,

por lo que si el sistema de recolección se encuentra en el mismo nivel, puede que el malware

haga que el sistema de recogida de datos no capte las acciones realizadas por el sistema, al

interceptar las llamadas a las API del sistema a un nivel más alto del que lo hace el sistema

de recolección de datos.

Proporciona datos que permiten detectar comportamientos anómalos, que ya ha sido de-

mostrado por estudios anteriores[134], y que han sido la base de multitud de estudios

relacionados con la seguridad anteriormente[199, 126, 131, 375, 194, 309].

Las razones anteriores, han echo que la elección de parámetros para el sistema haya sido utili-

zar las llamadas al sistema para utilizarlas como parámetro en el sistema implementado en el

proyecto.

En el sistema se han utilizado las partes que integran una llamada al sistema:

Función llamada: Habitualmente ha sido el parámetro utilizado, para detectar desviaciones

en el comportamiento de los procesos, normalmente no se utiliza el nombre de la función

sino que se utiliza el número que idéntica unívocamente cada syscall.13Como ruido, se considera los datos que no tienen una representatividad y difuminan la importancia de los

que sí que la tienen.

222

Parámetros de la función: Los parámetros han sido siempre ignorados, hasta que un estudio[372]

demostró que conociendo el sistema que iba a auditar el proceso, era posible engañar al

sistema, emulando la cadena de syscalls que sería lícita en el sistema mediante llama-

das a función que realmente no hacían nada. Este tipo de ataques denominados mimicry,

hicieron necesaria la inclusión de los argumentos como parámetro a incluir en estudios

posteriores[68].

Valor de retorno de la función: El parámetro del valor de retorno[95, 233] , ha sido incluido

en varios estudios actuales de modelización de secuencias de llamadas al sistema.

Como puede apreciarse, cada llamada genera tres parámetros de entrada al sistema, que permiten

realizar una modelización a bajo nivel, para poder realizar una modelización de comportamiento

de procesos, y no de usuarios.

3.1.3. Futuros parámetros

Como futuros parámetros se establece la línea de investigación que se abre para correlacionar

los parámetros de un entorno de red con los parámetros que se contemplan del entorno de host.

Estos parámetros permitirían establecer una serie de esferas /planos de análisis, de forma, que

se integren en el análisis homogéneo parámetros heterogéneos.

Por lo tanto, un análisis de datos heterogéneos, puede dar relaciones entre los dos mundos

ampliamente separados desde sus inicios, como pueden ser los HIDS, y los NIDS.

A continuación se describen los posibles parámetros relacionados con el mundo de la red que

pudieran ser utilizados conjuntamente con los parámetros que ya han sido expuestos anterior-

mente.

Para obtener estos parámetros se tuvieron en cuenta fuentes como los protocolos IP, TCP,

UDP e ICMP, el sistema de detección de intrusos Snort y el proyecto Lerad [364] por citar

algunos. De forma general para todas las tablas, aquellos parámetros en los que el tipo se indica

�Binario / Discreto� es porque se pueden implementar de las dos formas; por ejemplo, para

el parámetro Ipopts de Snort este se puede implementar de forma discreta con una variable

que contenga nueve estados o bien, de forma binaria mediante nueve variables (una para cada

estado) que contenga tan solo dos estados. Y también que en aquellos sitios donde aparece �No

cuanti�cable� es que el parámetro tiene naturaleza discreta pero los valores que pueden contener

son aleatorios.

Formato de las tramas

En este punto se explica el formato de las tramas IP, TCP, UDP, ICMP y se comentan los

posibles valores que pueden tomar y con qué tipo de variables se pueden representar. Se han

elegido estos protocolos puesto que son fundamentales en las redes Ethernet actuales.

223

Formato trama IP

�El protocolo IP (Internet Protocol, IP) es un protocolo no orientado a conexión usado tanto

por el origen como por el destino para la comunicación de datos a través de una red de paquetes

conmutados.�[8]

El formato de su datagrama es el siguiente, según [RFC791]:

Figura 3.4: Formato IP

El tipo y los posibles valores cada parámetro de este datagrama se detallan en la siguiente

tabla.

Parámetro Tipo Valores posibles

Versión Discreto 4 ó 6Internet Header Lenght Discreto 24

Tipo de servicio Discreto 24

Longitud Total Discreto 216

Identi�cador Discreto No cuanti�cableDont Fragment (DF) Binario 0-1More Fragment (MF) Binario 0-1

Desplazamiento del fragmento Discreto 213

Tiempo de vida Discreto 26

Protocolo Discreto 26

Suma de comprobación Discreto 216

Dirección Origen Discreto 232

Dirección Destino Discreto 232

Cuadro 3.1: Tipo y valores posibles de cada parámetro

224

Formato de TCP

�El protocolo de control de transmisión ('Transmission Control Protocol', TCP) está pensado

para ser utilizado como un protocolo 'host' a 'host' muy �able entre miembros de redes de comu-

nicación de computadoras por intercambio de paquetes y en un sistema interconectado de tales

redes.�[10]

Su formato según [10] es el siguiente:

Figura 3.5: Formato TCP

El tipo y los posibles valores cada parámetro de este protocolo se detallan en la siguiente

tabla.


Puerto origen Discreto 216

Puerto destino Discreto 216

Número de secuencia Discreto 212

Número de con�rmación (ACK) Discreto 212

Desplazamiento Discreto 24

URG Binario 0-1ACK Binario 0-1PSH Binario 0-1RST Binario 0-1SYN Binario 0-1FIN Binario 0-1

Ventana Discreto 216

Checksum Discreto 216

Puntero Urgente Discreto 216

Opciones + Relleno Discreto No cuanti�cableDatos Discreto No cuanti�cable

Cuadro 3.2: Tipos y posibles parámetros del protocolo TCP

225

Formato UDP

�Este Protocolo de Datagramas de Usuario (User Datagram Protocol, UDP) asume que el

protocolo IP se utiliza como protocolo subyacente. Este protocolo aporta un procedimiento para

que los programas de aplicación puedan enviar mensajes a otros programas con un mínimo de

mecanismo de protocolo. El protocolo se orienta a transacciones, y a la entrega como la protección

ante duplicados no se garantizan. Las aplicaciones que requieran de una entrega �able y ordenada

de secuencias de datos deberían utilizar el protocolo TCP.�[11]

Su formato según [11] es el siguiente:

Figura 3.6: Formato UDP

El tipo y los valores de cada parámetro de este protocolo se detallan en la siguiente tabla.


Puerto Origen Discreto 216

Puerto Destino Discreto 216

Longitud Discreto 216

Checksum Discreto 216

Cuadro 3.3: Tipos y posibles parámetros de UDP

Formato ICMP

�El protocolo IP se utiliza para el servicio de datagramas de "host" a "host" en un sistema de

redes interconectadas denominado Catenet. Los dispositivos de conexión de redes se denominan

Pasarelas (Gateways). Estas pasarelas se comunican entre ellas con propósito de control median-

te el Protocolo Pasarela a Pasarela (Gateway to Gateway Protocol (GGP)). Ocasionalmente,

una pasarela o un "host" de destino se comunicará con un "host" de origen para, por ejemplo,

informar de un error en el procesamiento de datagramas. El Protocolo de Mensajes de Control

Internet (ICMP) se usa para este propósito. ICMP utiliza el soporte básico de IP como si se

tratara de un protocolo de nivel superior. Sin embargo, ICMP es realmente una parte integrante

de IP, y debe ser implementado por todo módulo IP.�[7]

Su formato según [7] es

226

Figura 3.7: Formato ICMP

El tipo y los valores de cada parámetro de este protocolo se detallan en la siguiente tabla.


Tipo Discreto 28

Código Discreto 28

Checksum Discreto No cuanti�cableContenido Discreto 216

Cuadro 3.4: Tipos y posibles parámetros ICMP

Snort

Mediante un exhaustivo proceso de revisión de las reglas que incluye este sistema se consiguió

extraer un conjunto de métricas que fueron separadas en dos categorías: Bajo Nivel y Alto Nivel

respectivamente. Las de bajo nivel se corresponden con la mayoría de los parámetros de las

tramas de los protocolos explicados anteriormente y las de alto nivel representan conceptos más

complejos que los propios parámetros. Los parámetros de bajo nivel son los siguientes:


Flags (Syn, Ack, Rst, etc) Discreto/Binario 0-1Fragbits (MF,DF) Binario 0-1

TTL Discreto 26

ID Discreto No cuanti�cableIpopts Discreto/binario rr, eol, nop, ts, sec, lsrr, ssrr, satid, anyDsize Discreto No cuanti�cableFlow Discreto/Binario to_client, to_server, from_client, from_server, established,...

Window Discreto No cuanti�cable

Cuadro 3.5: Tipo y parámetros de bajo nivel de Snort

Algunas de los parámetros de alto nivel son los siguientes:

227


Not-suspicious Binario 0-1Attempted-recon Binario 0-1Shellcode-detect Binario 0-1Suspicious-login Binario 0-1System-call-detect Binario 0-1Unsuccessful-user Binario 0-1Unsuccessful-admin Binario 0-1

Icmp-event Binario 0-1

Cuadro 3.6: Tipo y parámetros de alto nivel de Snort

Como se puede observar muchos de los parámetros de los obtenidos de las tramas se corres-

ponde con los parámetros de bajo nivel de Snort, a continuación se muestra una tabla donde se

observa la correspondencia entre los parámetros obtenidos de las las tramas y los obtenidos de

Snort.

Todos los parámetros extraídos de Snort están recogidos en los parámetros de las tramas,

menos �Flow� que se puede implementar de una manera alternativa. Queda claro, de esta forma,

que implementar los parámetros de las tramas combinados con los de Snort permite extender y

mejorar el modelo que incorpora Snort.

Lerad

En el documento [364] Mahoney y Chan proponen un algoritmo para la detección de intru-

siones que utiliza los siguientes parámetros.


Puerto Origen Discreto 216

Puerto Destino Discreto 216

Longitud de la conexión Discreto No cuanti�cableDuración de la conexión Discreto No cuanti�cable

Flags de los dos primeros paquetes Binario/Discreto 0-1Flags de los dos últimos paquetes Binario/Discreto 0-1

Ocho primeros octetos del campo datos Discreto No cuanti�cableNumero de conexiones a un puerto de una ip concreta Discreto No cuanti�cable

Cuadro 3.7: Parámetros que proponen Mahoney y Chan[364].

Marina Bykova

Marina Bikova y otro en su documento [48] analiza los siguientes parámetros para detectar

comportamientos anómalos en la red.

228

Parámetro Tipo

Numero de direcciones IP fuera de rango DiscretoNumero de otras violaciones en la dirección Discreto

Opciones IP no adecuadas DiscretoNumero de paquetes demasiado pequeños (IP/TCP) Discreto

Veces que aparece puerto cero DiscretoChecksum invalido Discreto

Cuadro 3.9: Parámetros de alto nivel de Marina Bykova


Tamaño paquete (IP/TCP) Discreto Tantos como paquetesChecksum (IP/TCP) Discreto Tantos como paquetes

Dirección IP Discreto 212

Opciones IP Discreto No cuanti�cablePuertos TCP Discreto 216

Flags TCP Binarios 0-1Bits reservados TCP Binarios 0-1

Cuadro 3.8: Parámetros y tipos de Marina Bykova

Como puede comprobarse estos parámetros son los mismos que se obtienen del análisis de

las cabeceras de las tramas. Con estos parámetros, Bykova, establece los siguientes parámetros

de mayor de nivel de abstracción.

Christopher Kruegel

De la mano de dos autores altamente reconocidos, como son Christopher Krügel y Giovan-

ni Vigna, en el documento [217] se comentan una serie de métricas factibles de ser aplicadas,

ampliadas y generalizadas. La idea de la que parten es la aplicación de conocimiento experto

para el análisis de solicitudes web. Di�eren las peticiones en una serie de partes de�nidas por el

estándar del protocolo HTTP [6]. El objetivo general de la práctica que realizan es contrastar

el trá�co que se genera en un determinado momento con el trá�co aprendido como válido y sin

ataques en una fase de aprendizaje. Se compone por lo tanto de dos fases diferenciadas y claves,

el aprendizaje y la detección. Durante la primera se tratará de establecer el valor de la métrica

que corresponda en la forma más precisa posible y durante la segunda se comparará, como si de

una medida patrón se tratase, para validar una posible ocurrencia en dos categorías: normal o

anomalía.

Para realizar esta clasi�cación se basan en una serie de métricas susceptibles de ser añadidas

al sistema en futuras ampliaciones como parámetros.

229

3.2. Recogida de información

La recogida de la información permite alimentar el sistema con los datos de los terminales

móviles, (en este caso las syscalls con sus argumentos), estos terminales pueden ser heterogéneos,

es decir, se han desarrollados sistemas de captura de datos para diferentes plataformas: GNU/-

Linux, Windows, Windows Poquet PC y Symbian. Aunque el sistema esta diseñado para ser un

analizador de anomalías en terminales móviles, la solución implementada permite analizar dife-

rentes plataformas, no solamente en terminales móviles, sino en sistemas operativos de propósito

general , ampliando el estudio realizado.

A continuación se detallan los sistemas de recogida de información llevada a cabo en los

sistemas mencionados.

3.2.1. Recogida de información en sistemas GNU/Linux

Los sistemas GNU/Linux se caracterizan por encontrarse en multitud de dispositivos y arqui-

tecturas diferentes, desde dispositivos embebidos14, hasta soluciones móviles, PDA�s... por lo que

un aspecto interesante del proyecto pasaba por realizar un sistema de recogida de información

en sistemas GNU/Linux por la amplitud del arquitecturas y sistemas en los que se encuentran.

Particularmente la opción elegida pasaba por implementar un sistema de recolección de in-

formación para PDA�s de Nokia N770 que utilizan una distribución propia llamada maemo15.

Al �nal de este apartado se especi�carán los detalles de implantación en la Plataforma.

En los sistemas Unix-like16, la arquitectura del sistema se divide en dos partes muy diferen-

ciadas: el modo real y la zona de usuario, siendo las syscalls el lenguaje por el cual hablan las

dos partes. Dichas syscalls17, son el mecanismo que permite conectar las dos zonas divididas por

el sistema operativo, el modo real, en el que se encuentra el kernel, y la zona de usuario, donde

se encuentran los programas de usuario.

Las diferencias entre estas dos zonas son muy signi�cativas, en el modo real, se realizan las

funciones primordiales de los sistemas operativos18, como pueden ser la gestión de memoria,

la gestión de procesos... por lo tanto su tratamiento es eminentemente diferente a la zona de

usuario, en la que se disponen de los servicios provistos por el kernel (gestión de memoria virtual19, gestión de sistemas de �cheros...); y para pedir dichos recursos al sistema operativo, ha que

14también conocidos como dispositivos empotrados.15Mas información sobre esta distribución en www.maemo.org.16Se trata de un sistema de funcionamiento parecido al de un sistema Unix tradicional, pero que no se encuentra

bajo una especi�cación UNIX convencional, tradicionalmente este término ha estado ligado al software libre y asistemas abiertos como GNU/Linux.

17También conocidas como �llamadas al sistema�.18Cabe destacar, la excepción de los sistemas microkernel, en el que las funciones del sistema operativo aparecen

en zona de usuario.19Los sistemas operativos emulan las direcciones de memoria utilizadas por los programas de usuario, haciéndoles

creer que disponen de un rango de direcciones mayor del que existe físicamente en la memoria física de la máquina.De esta manera el sistema operativo puede almacenar temporalmente en zonas del disco duro (minimizando lautilización de un recurso tan valioso como es la memoria) bloques de memoria virtual poco utilizados.

230

Figura 3.8: Esquema de la estructura del kernel

Figura 3.9: Proceso de llamada a una syscall

utilizar el mecanismo de las syscalls.

Los sistemas GNU/Linux, siguen el estándar POSIX 20, que de�nen un conjunto de syscalls,

de esta manera se parte de un conjunto de llamadas al sistema susceptibles de ser recogidas

como parte de la información utilizada posteriormente para el aprendizaje e inferencia de la

herramienta, dado que ya ha sido demostrado en estudios anteriores[375] que los ataques generan

una variación detectable en las syscalls generadas por los procesos.

Sistema de syscalls en sistemas GNU/Linux

Antes de proceder a la intercepción de las llamadas a las syscalls, fue necesario realizar un

completo estudio de la arquitectura que posee el kernel de GNU/Linux para el tratamiento de

las syscalls.

La parte de la gestión de estas syscalls, se pueden dividir en dos partes muy diferenciadas:

La llamada desde la zona de usuario y la recepción por parte de el kernel.

20Portable Operating System Interface, siendo la X referencia a los sistemas Unix. Se trata de un conjunto deestándares que de�ne las syscalls que ha de implementar un sistema Unix. Se encuentra de�nida en los estándaresIEEE1003. Cabe destacar, que este estándar no solamente de�ne las syscalls, sino que también especi�ca programasa nivel de usuario (sed, awk...) linea de comandos y otros tantos aspectos de los sistemas Unix-Like.

231

Llamada a syscalls desde la zona de usuario

La llamada a las funciones del sistema en los sistemas GNU, se implementan mediante in-

terrupciones21 generadas por instrucciones en ensamblador o mediante las puertas de llamada

lcall7/lcall2722, por lo tanto, cuando alguno de los dos mecanismos ocurre, el procesador, cuan-

do un proceso de zona de usuario requiere un recurso, interrumpe lo que estaba haciendo y da

servicio a la petición recibida.

Esta llamada puede realizarse desde los programas directamente en código ensamblador,

llamando a las interrupciones int0x80, para ello se cargan en los registros EAX el código de la

instrucción (en el ejemplo se trata del código de la instrucción write , con el número de syscall

4, seguido de la syscall 1, la exit).

Listing 3.5: Ejemplo de programa en ensamblador

.data # Zona de datos

3 msg : . s t r i n g " He l l o , wor ld ! \ n" # de f i n i c i o n cadena

l en = . − msg # long i tud

. t e x t

8 . g l o b a l main # decimos e l " e n t r y p o i n t "

main :

movl $len , %edx # long i tud de l a cadena

movl $msg , %ecx # puntero a l a cadena

13 movl $1 , %ebx # handler (1 = STDOUT)

movl $4 , %eax # (4 = wr i t e )

int $0x80 # llamada al ke rne l

movl $0 , %ebx #codigo de s a l i d a

18 movl $1 , %eax #(1 = ex i t )

int $0x80 # llamada al ke rne l

Como se puede observar, el código para llamar a una syscall concreta, depende de la syscall

que sea llamada, esto, hace que tenga muchas variaciones, y que el código ensamblador sea

muy difícil de escribir. Por dicha razón, hoy en día la mayoría de las llamadas a las syscalls, se

21Señal que indica al procesador que debe interrumpir el curso de ejecución actual, y proceder a ejecutar eltratamiento especi�co para la interrupción que acaba de ejecutarse.

22Puertas de llamada utilizadas en sistemas Solarix, Unixware, que también son soportados por el kernel deLinux.

232

encuentran englobadas en una librería (conocida como la glibc23), que provee de una API a alto

nivel para las llamadas a las syscalls, lo que permite abstraernos de las llamadas a bajo nivel y

de los registros en los que tenemos que almacenar los argumentos.

Para comparar los dos sistemas, lo que antes se hacia en varias lineas crípticas de ensamblador,

se realiza en una sola línea en lenguaje C.

Listing 3.6: Ejemplo de la mejora con lenguaje C

1 int main ( ) { p r i n t f ( " Hola Mundo" ) ; }

También existe otro tipo de macros que permiten las llamadas a las syscalls abstrayéndonos

en cierto modo de los registros del sistema, estos son:

Listing 3.7: Macro para llamar a syscall

s y s c a l l 2 ( long , runqueue , unsigned long ∗ , dst , long , l en ) ;

Los programas, al seguir su curso generan un numero determinado de syscalls que pueden

ser logeadas, mediante el comando strace24 (para ver las llamadas al sistema así como sus argu-

mentos). Mediante esta útil herramienta se pueden depurar programas comúnmente utilizados,

viendo si existe algún tipo de comportamiento extraño en la secuencia o el tipo de llamadas a

las syscalls del sistema.

Esta herramienta fue un punto de partida sobre el que se planteó comenzar a trabajar, pero

se vieron varios y numerosos inconvenientes:

Se trata de un sistema que trabaja a petición, es decir, hay que decir explícitamente que

el programa se ejecute bajo la supervisión de strace.

Genera una salida en texto que habría que parsear, siendo este un arduo trabajo.

Los programas ejecutados bajo strace, se ejecutan más lentamente que los ejecutados nor-

malmente.

Vistos estos inconvenientes se optó por otro tipo de sistema para capturar las llamadas al

sistema, ya que strace no ofrecía las funcionalidades necesarias, tratándose más de un medio de

depuración de los programas, más que un sistema de monitorización integral.

Recepción de syscalls en zona de kernel

Para poder interceptar las llamadas, se procedió a un estudio exhaustivo de cómo se realiza

la recepción y tratamiento de las llamadas al kernel en los sistemas GNU/Linux.

23GNU C library, es una parte esencial de los sistemas GNU/Linux .24Strace es un comando de la linea de comandos de Linux (comúnmente conocida como bash), que permite

logear las llamadas al sistema que se efectúan por parte de un programa.

233

Figura 3.10: Ejemplo utilización del comando strace

234

La comunicación se realiza mediante syscalls, siendo éstas llamadas a la interrupción 0x80,

estas llamadas, se traducen, en la llamada a la rutina situada en la entrada 0x80 de la tabla

de manejo de interrupciones. Por lo tanto, por ejemplo si se produce una interrupción 0x13, se

sumaría 13 a la dirección base del vector tabla de interrupciones, obteniendo de esa manera la

dirección de la función que ha de gestionar dicha interrupción25.

Este proceso completo se puede encontrar en varios archivos del kernel, en el archivo /us-

r/src/linux/include/asm/unistd.h, podemos encontrar un conjunto completo de las syscalls que

el kernel esta preparado para recibir, en cada versión del kernel existe un número diferente de

syscalls, siendo siempre mayor que el anterior, dado que una vez que se ha insertado una nuevas

syscall, hay que mantenerla en el kernel por razones de compatibilidad, cuando una syscall ha

dejado de ser implementada, se le asigna una nueva syscall: sys_ni_syscall, que devuelve el valor

-ENOSYS, que indica que dicha syscall ya no está implementada.

Listing 3.8: Contenido de unistd.h los números de las syscalls

#ifndef _ASM_I386_UNISTD_H_

#define _ASM_I386_UNISTD_H_

/∗ ∗ This f i l e con ta ins the system c a l l numbers . ∗/4 #define __NR_restart_syscall 0

#define __NR_exit 1

#define __NR_fork 2

#define __NR_read 3

#define __NR_write 4

9 #define __NR_open 5

#define __NR_close 6

Estas llamadas son recibidas a nivel de kernel por código especí�co para cada tipo de proce-

sador, que extrae el valor del registro eax, en el que almacena el numero de la syscall que va a

ejecutarse. Este numero (multiplicado por el tamaño de las direcciones de memoria) se suma a

la dirección base de la idt26, obteniéndose el handler de la interrupción que va a ejecutarse.

Listing 3.9: De�nición de la IDT en linux

struct desc_struct idt_tab le [ 2 5 6 ] __attribute__ ( (__section__( " . da ta .

i d t " ) ) ) = { {0 , 0} , } ;

Como se puede ver en la inicialización, existen varias interrupciones aparte de la 80, de�nida

por la macro SYSCALL_VECTOR, como pueden ser división por 0, page fault...

25El vector de interrupciones es conocido como la zona de memoria en la que se encuentran los punteros a lasfunciones que tratan cada una de las interrupciones. Por lo tanto para desplazarnos por las entradas del vector,sumamos a la dirección base del vector el número de interrupción que queremos tratar.

26Interrupción Description Table: Vector en el que se almacenan

235

Listing 3.10: Inicialización de la IDT

set_trap_gate (0 ,& d iv ide_er ro r ) ;

set_intr_gate (1 ,&debug ) ;

set_intr_gate (2 ,&nmi ) ;

4 set_system_intr_gate (3 , &in t3 ) ; /∗ int3−5 can be c a l l e d from a l l ∗/set_system_gate (4 ,& over f l ow ) ;

set_system_gate (5 ,&bounds ) ;

set_trap_gate (6 ,& inval id_op ) ;

set_trap_gate (7 ,& device_not_avai lab le ) ;

9 set_task_gate (8 ,GDT_ENTRY_DOUBLEFAULT_TSS) ;

set_trap_gate (9 ,& coprocessor_segment_overrun ) ;

set_trap_gate (10 ,& invalid_TSS ) ;

set_trap_gate (11 ,& segment_not_present ) ;

set_trap_gate (12 ,& stack_segment ) ;

14 set_trap_gate (13 ,& genera l_protec t i on ) ;

set_intr_gate (14 ,& page_fault ) ;

set_trap_gate (15 ,& spurious_interrupt_bug ) ;

set_trap_gate (16 ,& coproce s so r_er ro r ) ;

set_trap_gate (17 ,& alignment_check ) ;

19 #ifde f CONFIG_X86_MCE

set_trap_gate (18 ,&machine_check ) ;

#endif

set_trap_gate (19 ,& simd_coprocessor_error ) ;

set_system_gate (SYSCALL_VECTOR,& system_cal l ) ;

Otra función importante que existen en el kernel, se trata de la función request_irq, que

permite habilitar una interrupción, siendo argumentos de la misma, el handler27, y el número

de la interrupción que deseamos mapear. Esta función se encuentra rede�nida para varias de las

arquitecturas, siendo el handler generalizado el que se puede encontrar en /usr/src/linux/kerne-

l/irq/manage.c28.

Una vez que se ha recibido la IRQ, (la interrupción que ha enviado la zona de usuario), se

realiza la gestión de la misma, como se puede ver en la<inicialización de las interrupciones, se

27La función que maneja una interrupción.28Se pueden encontrar otras implementaciones de este código para otras arquitecturas:

arm: arch/arm/kernel/irq.c

arm26: arch/arm26/kernel/irq.c

sparc: arch/sparc/kernel/irq.c

sparc64: arch/sparc64/kernel/irq.c

Estos son los �cheros donde podemos encontrar la implementación de la función que recoge las interrupciones.

236

asigna una función a cada interrupción que será llamada cuando se de dicha interrupción.

Nueva gestión de llamadas al Kernel: Sysenter29.

La gestión de interrupciones, aún a pesar de estar lo más optimizada posible, siguen siendo

una tarea ardua y dura, dado que el kernel tiene que gestionar las puertas de llamada, y todo

el sistema de runlevels. Para mitigar esta de�ciencia, ha surgido una nueva manera de llamar

al Kernel, que se trata de sysenter, que mejora el rendimiento en las llamadas al kernel. Este

sistema es totalmente compatible con el anteriormente explicado, las interrupciones se pueden

llamar tanto por Systenter como por int80. Pero la instrucción systenter está más optimizada.

En los sistemas GNU/Linux, las llamadas a las syscalls se realizan desde la glibc, y en los

últimos tiempos se está llevando a cabo una transición desde las llamadas a las syscalls mediante

la interrupción 80, a la llamada más rápida Sysenter.

Por supuesto esta nueva gestión de llamadas se realiza únicamente en sistemas i386, siendo

especi�co de ésta arquitectura.

Gestión de las syscalls en zona de Kernel

Cuando llega una interrupción 80, el sistema de gestión de interrupciones explicado anterior-

mente delega la gestión a el handler de las syscalls, o en su defecto, se realiza una llamada a la

función sysenter, llamando al handler de las interrupciones.

Este handler es diferente para sysenter y para la interrupción int80, pero esencialmente rea-

lizan la mismo: Inspeccionan si la syscall que se quiere llamar está implementada (el número de

syscall es menor o igual que el número mayor de syscalls), si se produce esta situación se devuelve

un error. En caso contrario, se calcula la dirección donde se encuentra almacenado el handler30

que ha de tratar dichas syscall y se llama a dicha función devolviendo a zona de usuario lo que

el handler devuelva.

Listing 3.11: Gestión de la interrupción 80

#System c a l l handler stub

2 ENTRY( system_cal l )

pushl %eax # save orig_eax

SAVE_ALL

GET_THREAD_INFO(%ebp )

# system c a l l t r a c i ng in

opera t i on / emulat ion

7 /∗ Note , _TIF_SECCOMP i s b i t number 8 , and so i t needs t e s tw

and not t e s t b ∗/29Para mayor información: http://www.codeguru.com/cpp/w-p/system/devicedriverdevelopment/article.php/c8223/#more,

articulo sobre la optimización realizada por la instrucción sysenter[152].30La función que se va a encargar de tratar dicha syscall

237

testw $ (_TIF_SYSCALL_EMU|_TIF_SYSCALL_TRACE|_TIF_SECCOMP|

_TIF_SYSCALL_AUDIT) , TI_flags(%ebp )

jnz sysca l l_trace_entry

cmpl $ ( n r_sy s ca l l s ) , %eax

j a e sysca l l_badsys

12 s y s c a l l_ c a l l :

c a l l ∗ sys_ca l l_tab le (,%eax , 4 )

movl %eax ,EAX(%esp ) # s t o r e the return value

s y s c a l l_ ex i t :

c l i # make sure we don ' t m i s s an

i n t e r r u p t

17 # s e t t i n g ne ed_re s ched o r

s i g p e n d i n g

# between s amp l i n g and th e

i r e t

movl T I_ f l a g s(%ebp ) , %ecx

t e s tw $_TIF_ALLWORK_MASK, %cx # cu r r e n t −>work

j n e s y s c a l l_ e x i t_wo r k

Listing 3.12: Gestión de la llamada sysenter

#Sysenter c a l l handler stub

2 ENTRY( sysenter_entry )

movl TSS_sysenter_esp0(%esp ),%esp

sysenter_past_esp :

s t i

pushl $ (__USER_DS)

7 pushl %ebp

push f l

pushl $ (__USER_CS)

pushl $SYSENTER_RETURN

12 /∗∗ Load the p o t e n t i a l s i x t h argument from user s t a c k .

∗ Care fu l about s e c u r i t y .

∗/cmpl $__PAGE_OFFSET−3,%ebp

17 j a e s y s c a l l_ f a u l t

1 : movl (%ebp ),%ebp

238

. s e c t i o n __ex_table , " a "

. a l i g n 4

. long 1b , s y s c a l l_ f a u l t

22 . p r ev ious

pushl %eax

SAVE_ALL

GET_THREAD_INFO(%ebp )

27

/∗ Note , _TIF_SECCOMP i s b i t number 8 , and so i t needs t e s tw

and not t e s t b ∗/testw $ (_TIF_SYSCALL_EMU|_TIF_SYSCALL_TRACE|_TIF_SECCOMP|

_TIF_SYSCALL_AUDIT) , TI_flags(%ebp )


cmpl $ ( n r_sy s ca l l s ) , %eax

32 j a e sysca l l_badsys


movl %eax ,EAX(%esp )

c l i

movl TI_flags(%ebp ) , %ecx

37 testw $_TIF_ALLWORK_MASK, %cx

jne sysca l l_exit_work

/∗ i f something mod i f i e s r e g i s t e r s i t must a l s o d i s a b l e s y s e x i t ∗/movl EIP(%esp ) , %edx

movl OLDESP(%esp ) , %ecx

42 xo r l %ebp,%ebp

s t i

s y s e x i t

Como se puede ver en los ejemplos mostrados, la llamada call, que se realiza en ambos códigos

(call *sys_call_table(,%eax,4)), es la parte en la que se llama a la función que se encarga de

manejar cada syscall.

Estos punteros a funciones se almacenan en un vector llamado sys_call_table, y como cada

dirección de memoria en i386 son 4 bytes, multiplicando por cuatro el valor de eax31, se obtiene

el o�set32 necesario para calcular la dirección en la que se almacena el puntero a función que se

va a llamar.

El objeto sys_call_table, es de especial importancia, en versiones anteriores del kernel (de

31En eax en ese momento se almacena el número de syscall que se está llamando.32desplazamiento

239

Figura 3.11: Esquema de llamada a una interrupción mediante interrupción

la rama 2.4 y anteriores) dicho objeto se encontraba disponible por parte de cualquiera de los

módulos que se cargasen en el sistema, y con realizar extern void* sys_call_table[]; se tenía acceso

a uno de los puntos mas importantes del sistema operativo. Este aspecto ha sido ampliamente

explotado por rootkits33, lo que llevó a Linus Torvalds34, a decidir eliminar esta exportación

haciendo algo más difícil algo que anteriormente era trivial. Esta ocultación no ha permitido

eliminar todos los sistemas de troyanización del kernel, dado que la dirección de la sys_call_table,

se puede seguir accediendo desde otros caminos que se explicarán posteriormente.

Como se puede ver también en ambos ejemplos el manejo del retorno de la función llamada

es también igual en ambos casos, ya que las funciones llamadas mediante call, devuelven el valor

de retorno en almacenado en la pila, por lo tanto lo que se realiza es almacenar el contenido de

la cima de la pila, que es el resultado de la syscall (todas las syscalls por convención devuelven

un long).

De�nición del sistema de recogida de datos en sistemas GNU/Linux

Para llegar a la sección de plantear las posibles opciones de acceder a las llamadas al sistema

que se dan en un momento en el sistema se realizó un estudio de las técnicas utilizadas para

auditar las aplicaciones en sistemas GNU/Linux.

De un comienzo aparecieron varias opciones:

Realizar un sistema vírico que intercepte las llamadas a las syscalls.

Utilizar un sistema de logeo de syscalls convencional, como pueden ser strace y ptrace.33Sistemas de troyanización del kernel de linux.34Creador del Kernel de Linux, y actualmente mantiene una parte del desarrollo del mismo.

240

Figura 3.12: Logo de SuSE, distribución alemana, respaldada por la empresa Novell

Utilizar un sistema ya realizado por Novell : LAuS[261]35.

Utilizar el sistema de auditoría snare[16].

Adaptar un sistema BSM[270] de auditoría en sistemas Solaris

Los requisitos planeados eran los siguientes:

Funcionamiento en todo tipo de plataformas / arquitecturas.

Funcionamiento en tiempo real y transparente para el usuario.

No haya necesidad de interacción con el usuario.

Dados los requisitos, se fueron analizando las diferentes opciones. El sistema LAuS, era un sis-

tema desarrollado por Novell para la distribución SuSE en forma de parche del kernel de linux,

que permitía auditar las syscalls. Este sistema existe para que los sistemas SuSE obtuvieran el

certi�cado de seguridad informática CC EAL436, esta solución aunque buena para los sistemas

que empleen SuSE, no es �exible para los requisitos marcados por el sistema a emplear, y no se

ha probado en sistemas embebidos ni sistemas móviles. Además para funcionar necesita que el

kernel sea recompilado y es un proceso que para nada es transparente para el usuario.

El sistema LAuS, permite en ordenadores convencionales auditar a procesos, pero no ofrece

la �exibilidad necesaria para realizar un proyecto con él, por lo que la opción de SuSE y Novell

quedó desechada por dichas razones.

Los sistemas de strace y ptrace37, permiten seguir a un proceso el curso de la ejecución de

otro en forma de syscalls, reciben las acciones del otro proceso, este sistema implementable en35Se trata de un sistema de auditoría realizado por Novell para SuSE36Estándar de seguridad informática Common Criteria Assurance Level 4 : Methodically Designed, Tested

and Reviewed. Analysis is supported by the low-level design of the modules of the TOE, and a subset ofthe implementation. Testing is supported by an independent search for obvious vulnerabilities. Developmentcontrols are supported by a life-cycle model, identi�cation of tools, and automated con�guration manage-ment.[URL]http://www.cesg.gov.uk/site/iacs/index.cfm?menuSelected=1&displayPage=13

37La función ptrace, permite, al igual que el comando strace, seguir el funcionamiento de otro proceso.http://linuxgazette.net/issue81/sandeep.html

241

Figura 3.13: Logo del agente de snare para sistemas GNU/Linux

zona de usuario puede parecer en principio una buena opción, pero entraña un gran peligro, que

es fácilmente superable por el malware existente actualmente.

Listing 3.13: Prototipo de la función ptrace

#include <sys / ptrace . h>

long int ptrace (enum __ptrace_request request , pid_t pid , void ∗ addr

, void ∗ data )

El sistema de funcionamiento del sistema ptrace, solamente permite que un proceso siga la

ejecución de un proceso dado, es decir, un solo proceso puede seguir el funcionamiento de otro.

Algunos de los sistemas antimalware para sistemas GNU/Linux hacían uso de la función ptrace,

y la manera que desarrollaron los hackers, fue crear dos procesos en el malware, y se suscribían

mutuamente excluyendo la posibilidad de que cualquier otro proceso se suscribiese a su propia

ejecución, con esta �maniobra de evasión� el sistema de auditoría de syscalls mediante la función

ptrace y el comando strace se ve inutilizado.

Otro aspecto dentro de el sistema de strace/ptrace es que el sistema deja de ser trasparente

para el usuario si se ejecutan bajo el comando strace, ya que los programas han de ser ejecutados

mediante línea de comandos lo que deja al sistema sin posibilidad de ser independiente del usuario

del sistema operativo auditado.

Los sistemas BSM proporcionan un sistema de auditoría y de alertas para el seguimiento de los

usuarios. Se trata de un sistema que no solamente realiza un histórico de las syscall generadas por

el sistema, sino que se encuentra abierto a muchos tipos de eventos, como puede ser que se abra

una conexión ftp... Por lo tanto se trata de un sistema que genera un grupo heterogéneo de datos

de entrada38, en los que pueden aparecen relaciones de dependencia entre los datos de entrada por

el nivel de abstracción de los mismos. Además existen varios tipos de datos (sobre todo syscalls

a bajo nivel), que han sido rechazados para el sistema, dado que generan muchas entradas y que

�genera datos sin sentido� 39, esta supresión de datos, para un sistema de experimentación como

puede ser Mendizale, dichos datos, pueden dar un per�l mucho más exacto de los procesos que

están siendo inspeccionados. Por otra parte los sistemas BSM, permiten auditar usuarios, pero

no procesos en particular, lo que ha ocasionado que auditar procesos mediante un sistema de

auditoría de usuarios, no dé la solución más óptima.38Es decir, podemos encontrar, por una parte datos de muy alto nivel como puede ser la apertura de una

conexión ftp, y con datos de muy bajo nivel, como por ejemplo una syscall.39En concreto: �Several audit classes were excluded because they did not generate meaningful information (or

generated too much data). �

242

El sistema Snare[16], realizado por la empresa intersec alliance, es un sistema global de

detección de intrusiones el cuál dispone de un sistema de logeo de syscalls, que permite generar

reglas estáticas al administrador que genera alarmas cuando dicho evento se da en el sistema.

Este agente utiliza un sistema de auditoría, y por el momento únicamente funciona en Redhat

Enterprise Linux 4.0 U3, y ha sido testado en Fedora Core, en sistemas como Ubuntu Linux de

Canonical, no es funcional todavía, esta situación ha propiciado que este sistema que es funcional

haya sido rechazado en detrimento de la realización de un sistema de recogida de datos propio.

Por lo tanto las líneas que se han seguido han sido utilizar técnicas víricas que permitan

auditar el kernel de linux a bajo nivel. Este proceso se puede llevar a cabo de varias maneras,

pero siempre insertando código a nivel de kernel en forma de LKM40.

Desarrollo del sistema de recogida de datos en sistemas GNU/Linux

Una vez de�nida cuál va a ser la �losofía del sistema, se investigó cuáles eran las opciones

posibles:

Desarrollar un parche del kernel, conceptualmente puede que sea una buena solución dado

que modi�car código que no está en ejecución puede ser mas seguro41, que otras opciones,

pero no era una opción válida, dado que la transparencia con el usuario queda sustancial-

mente reducida con un proceso como recompilar el kernel.

Desarrollar un módulo del kernel de linux que secuestre las funciones del vector sys_call_table,

la cual era la opción más válida para el proyecto, y la que se ha desarrollado.

Por lo tanto, el sistema elegido ha fue un módulo del kernel que realice la recogida de datos, pero

existen también varias opciones en cuanto al acceso a las funciones llamadas a bajo nivel, por

lo tanto uno de los mayores problemas a la hora de desarrollar el sistema de recogida, ha sido

seleccionar qué método se utiliza a la hora de secuestrar las llamadas.

Para seleccionar el método necesario se ha tenido en cuenta la interoperabilidad entre dife-

rentes plataformas o arquitecturas42, y el impacto sobre el sistema operativo43.

Los métodos implementados y estudiados para la elección del método de�nitivo, fueron dos:

Modi�car las entradas de la sys_call_table para que en vez de que se llamen las funciones

que se han de encargar de las syscalls, se llame a funciones nuestras. Este sistema tiene la

complejidad añadida de que desde el kernel 2.5 el símbolo sys_call_table, no se encuentra

exportado en el kernel.40Loadable Kernel Module: Se trata de una sección de código que una vez compilada se la permite ser descargada

y carga en el kernel de linux.41Existen menos posibilidades de que se de un Kernel Panic modi�cando código fuente, que redireccionando

direcciones de memoria en tiempo de ejecución dado que puede tener consecuencias imprevisibles.42Alguno de los métodos utiliza código nativo a la hora de realizar la intercepción de las llamadas, y uno de los

requisitos de este sistema de recogida de datos era la interoperabilidad entre diferentes arquitecturas.43El tiempo de retraso que se puede dar por un proceso como el de la auditoría de syscalls.

243

Modi�car en tiempo de ejecución el código de manipulación de las syscalls del kernel para

que en vez de realizar las funciones originales se llame a un método de�nido por nosotros.

Las dos opciones comentadas fueron han sido realizadas y probadas, para decidir cuál de las dos

era la mejor opción.

Desarrollo de sistema de recogida de datos basado en intercepción de sys_call_table

Esta opción, lo que realiza es la suplantación de las direcciones de memoria almacenadas

en la variable sys_call_table, haciendo que cuando se ejecute una llamada a una syscall (tanto

mediante la interrupción 80, como la llamada sysenter), se llame a una función propia.

El mecanismo de funcionamiento es muy simple, se realiza un módulo del kernel, que cuando

se cargue modi�que las entradas necesarias en el vector de direcciones, y que cuando se descargue

las deje como las encontró. El mecanismo de funcionamiento de los módulos del kernel permi-

ten realizar esta tarea sin problemas, dado que la estructura básica de un módulo del kernel,

únicamente dispone de dos funciones, una que se la llama al cargar44, y otra que se llama al

descargarse45.

Listing 3.14: Ejemplo de un módulo básico

#include <l inux /module . h>

#include <l inux / ke rne l . h>

3 #include <l inux / timex . h>

stat ic int __init f en t_ in i t (void ) {

pr in tk (KERN_INFO " Hola soy un LKM en modo r e a l O_o"

! ! ! \ n" ) ;

r e t u r n 0 ;

}

8

s t a t i c v o i d __exit f e n t_ e x i t ( v o i d ) {

p r i n t k (KERN_INFO "Se descarga e l LKM. . . \ n" ) ;

}

13 modu l e_ in i t ( f e n t _ i n i t ) ;

modu l e_ex i t ( f e n t_ e x i t ) ;

MODULE_LICENSE( "GPL" ) ;

44Existen dos maneras de cargar módulos en el kernel, una mediante el comando insmod (que no carga losmódulos dependientes necesarios, y que carga el módulo desde cualquier localización), y el comando modprobe,que realiza la carga tanto del módulo como de los módulos dependientes necesarios (los módulos han de estarlocalizados en un sitio concreto de la jerarquía de �cheros).

45Mediante el comando rmmod.

244

El problema surge cuando deseamos buscar la dirección de memoria de la variable sys_call_table,

como ya hemos comentado anteriormente, a partir del kernel 2.5 no está disponible en el kernel

directamente. Las opciones para realizar el calculo de esta dirección son varias, este valor, se

encuentra almacenado en el �chero System.map, resultante de compilar el kernel, en este �chero

se encuentran las direcciones46 en las que se almacenarán las variables del kernel, y en este �chero

sí que aparece la variable que nos interesa: sys_call_table.

Por lo tanto podemos copiar esta dirección, y embeberla en el código fuente para disponer

de una referencia a la dirección de memoria en la que se encuentra el vector de direcciones. Otra

opción sería también pasar la dirección mediante un parámetro del LKM, y en el script para

introducir, realizar una manipulación de System.map para que encuentre la dirección adecuada.

Esta solución es viable siempre y cuando se disponga del System.map del kernel que que-

remos auditar, no hace falta recompilar el kernel, sino que el System.map sea el original de la

compilación.

Si el �chero System.map, no estuviese disponible o si la versión del mismo no fuese la original

existe otro método para localizar la dirección de la misma, se trata de buscar en el código que se

está ejecutando la dirección. El método[313] es bastante lógico, existe una función que permite

conocer la dirección base de la tabla IDT47, por que entrando a la entrada 80, tenemos el handler

de la interrupción 80 que es la que se encarga de tratar las syscalls.

En este momento disponemos de el puntero a la función que se encarga de tratar las int80,

y mediante un memcpy48, lo que hacemos es copiar el código de la función que se encarga de

tratar las syscalls (aparece anteriormente la sección de código que se encarga de ello).

Por lo tanto, para encontrar la dirección tenemos que buscar la llamada call que se realiza

desde el código fuente por lo que buscamos los códigos de operación 0x� 0x14 0x85 49, que se

corresponden a la llamada call, y posteriormente encontramos la dirección de la sys_call_table,

este método permite localizar la syscall table, pero tiene varios problemas que se detallarán a

continuación.

Listing 3.15: Función que obtiene la base del vector de syscalls

stat ic void get_sys_cal l_table (void ) {

int i ;

unsigned int sy s_ca l l_o f f ;

char sc_asm [ SIZE ] ;

5

asm( " s i d t %0" : "=m" ( i d t r ) ) ;

p r in tk ( " [+ ] i d t r ba s e a t 0x %08x\n" , i d t r . base ) ;

46Direcciones físicas en las que se van a almacenar47La tabla IDT es el vector de interrupciones.48función de C, que se encarga de copiar una zona de memoria a otra.49Se trata código ensamblador, que se ocupa de hacer una call.

245

memcpy(&idt , ( void ∗) ( i d t r . base+8∗0x80 ) , s izeof ( i d t ) ) ;

10 sy s_ca l l_o f f = ( i d t . o f f 2 << 16) | i d t . o f f 1 ;

p r in tk ( " [+ ] i d t [ 8 0 h ] d e s c r i p t o r p o i n t s t o 0x %08x\n" ,

s y s_ca l l_o f f ) ;

memcpy( sc_asm , (void ∗) sy s_ca l l_o f f , SIZE) ;

for ( i =0; i<SIZE ; i++)

15 i f ( ( sc_asm [ i ] == ' \ x f f ' ) &&

( sc_asm [ i +1] == ' \ x14 ' ) &&

( sc_asm [ i +2] == ' \ x85 ' ) ) {

pr in tk ( " [+ ] s y s_ c a l l _ t a b l e c a l l f ound ! ( a t

by t e %d from 0x %08x a d d r e s s ) \n" , i ,

s y s_ca l l_o f f ) ;

break ; ;

20 }

i f ( i<SIZE) {

sys_ca l l_tab le = (void ∗) ∗ ( ( int ∗) &sc_asm [ i +3]) ;

p r in tk ( " [+ ] s y s_ c a l l _ t a b l e a t 0x %p\n" , sys_ca l l_tab le

) ;

} else {

25 pr in tk ( " [ − ] s y s_ c a l l _ t a b l e not found ! " ) ;

}

}

El código que hemos mostrado tiene el problema de que es muy dependiente de la arquitectura

en la que esté implementado el sistema, por lo que topa con el requisito marcado de independencia

de la arquitectura, dado que el código no sólo se quiere utilizar para arquitecturas i386, sino

también para arquitecturas ARM..., esta opción aunque atractiva, fue desechada.

Por lo tanto el sistema para encontrar la dirección mediante la búsqueda de la dirección de

la base del vector de syscalls, fue desechado en favor del método del System.map, siendo este un

sistema más �exible para la utilización en diferentes arquitecturas.

Listing 3.16: Ejemplo de la intercepción de la syscall Kill

#include <l inux / ke rne l . h>

#include <l inux /module . h>

3 #include <l inux / i n i t . h>

#include <l inux / types . h>

/∗∗Direcc ion de memoria sacado direc tamente de system .map , l a entrada

246

es : s y s_ca l l_ tab l e

∗ ∗/8 #define SYSCALLDIR 0xc03337e0

MODULE_LICENSE( "GPLv2 o r l a t e r " ) ;

stat ic int (∗ k i l l_saved ) ( pid_t , int ) ; //Puntero a func ion para

almacenar e l v a l o r i n i c i a l

/∗∗Direcc ion de memoria sacado direc tamente de system .map , l a entrada

es : s y s_ca l l_ tab l e

13 ∗ ∗/long ∗ sys_ca l l_tab le = ( long ∗ ) SYSCALLDIR;

stat ic int mi_ki l l ( pid_t pid , int s i g )

{

struct task_struct ∗ptr = cur rent ; // Pi l lamos l a i n s t an c i a

d e l pcb

18 pr in tk ( " KÂ ½ l l s i g n a l : %d u s u a r i o %d p id : %d \n" , s i g , ptr−>uid , ptr−>pid ) ;

return ( (∗ k i l l_saved ) ( pid , s i g ) ) ;

}

int __init i n i t_ i n t e r c ep t (void )

{

23 pr in tk ( " Mend i z a l e module l o a d e d \n" ) ;

gett imeofday_saved = ( int (∗ ) ( struct t imeva l ∗ , struct

t imezone ∗) ) ( sys_ca l l_tab le [ __NR_gettimeofday ] ) ;

k i l l_saved = ( int (∗ ) ( pid_t , int ) ) ( sys_ca l l_tab le [ __NR_kill ] )

;

sys_ca l l_tab le [ __NR_kill ] = (unsigned long ) mi_ki l l ;

sy s_ca l l_tab le [ __NR_gettimeofday ] = (unsigned long )

mi_gettimeofday ;

28 return 0 ;

}

void __exit ex i t_ in t e r c ep t (void )

{

/∗ Lo dejamos todo como es taba ∗/33 sys_ca l l_tab le [ __NR_kill ] = (unsigned long ) k i l l_saved ;

sys_ca l l_tab le [ __NR_gettimeofday ] = (unsigned long )

gett imeofday_saved ;

}

247

module_init ( i n i t_ i n t e r c ep t ) ;

module_exit ( ex i t_ in t e r c ep t ) ;

Por lo tanto, este método realiza una suplantación de las direcciones del vector de syscalls

original, esto supone que cuando una función kill es llamada, la función kill original, no es llamada,

sino que se llama realmente a la función suplantada por nosotros. Para no levantar sospechas ni

modi�car el funcionamiento de las syscalls originales, después de realizar lo que queremos (en

el caso del ejemplo un simple printk), llamamos a la función kill original, devolviendo lo que la

función original ha devuelto. De este modo se consigue un logeo transparente al usuario.

Desarrollo de un sistema de recogida de datos basado en la modi�cación en tiempo

de ejecución de la rutina de tratamiento de las syscalls.

Este sistema de tratamiento ha sido desarrollado por parte de un hacker[292], para un rootkit

a nivel de kernel para kernels de la rama 2.6. Este sistema, utiliza una manera diferente para

interceptar todas las llamadas, en lugar de suplantar las direcciones a las que llama la rutina de

tratamiento de las syscalls, modi�ca la rutina de tratamiento con técnicas víricas para ejecutar

su propia función cada vez que llega una syscall.

Este método, tiene la ventaja de que modi�cando en un solo punto50 el código fuente, ya

hookea todas las syscalls, su funcionamiento es eminentemente vírico. Su funcionamiento es

parecido al de un virus, modi�ca el código que se va a ejecutar.

Listing 3.17: Líneas que son sobreescritas con un salto a la función.

arch / i386 / ke rne l / entry . S −−−−2

# system c a l l handler stub

ENTRY( system_cal l )

pushl %eax # save orig_eax

SAVE_ALL

7 GET_THREAD_INFO(%ebp )

cmpl $ ( n r_sy s ca l l s ) , %eax//−−−> Estas i n s t r u c c i on e s seran l a s

que

j a e sysca l l_badsys //−−−> sob r e e s c r i b i r emos con nues tro

s a l t o .

12 # system c a l l t r a c i ng in opera t i on

t e s tb $_TIF_SYSCALL_TRACE,TI_FLAGS(%ebp )


50En el desarrollo anterior, hay que sustituir tantas direcciones a función como syscalls queremos hookear.

248

s y s c a l l_ c a l l :


17 movl %eax ,EAX(%esp ) # s t o r e the return value

. . . .

−−−− eo f −−−−

Exactamente el sistema inserta un salto en la comprobación de si el número de syscall es

mayor al permitido (cmpl $(nr_syscalls),%eax ), y el salto condicional a sys_badsys si el número

de syscall no es el permitido. Estas acciones debemos realizarlas nosotros mismos dentro de la

rutina a la que lleva el salto. Estas dos operaciones ocupan en total 11bytes51, lo más sencillo

será cambiar por un pushl y un ret52, los cuales ocupan 6 bytes.

Este método ha de llevarse a cabo tanto en el handler de sysenter como en el de la interrupción

80, modi�cando en ambos los bytes concretos (en los dos sitios se realiza la misma comprobación).

Por lo tanto mediante este sistema podríamos tener un sistema que logease las interrupciones

o llamadas a la función sysenter sin tocar las direcciones de la sys_call_table.

El problema que plantea este método es la poca portabilidad que ofrece, dado que el código

que sobreescribe es altamente dependiente de la arquitectura sobre la que se ejecuta el sistema,

y además la dirección a la que salta es una shellcode53, que por supuesto, es dependiente de

la arquitectura sobre la que se ejecute el sistema. Por lo tanto, este método, aunque limpio

y efectivo, se trata de un método ampliamente dependiente de la arquitectura en la que esté

implementado.

Listing 3.18: Shellcode a la que saltamos cuando se llama a la función.

char idt_handler [ ]= // ( e l sysenter_hand ler es i d en t i c o )

" \ x90 \ x90 \ x90 \ x90 \ x90 \ x90 \ x90 \ x90 \ x90 \ x3d \ x12 \ x01 \ x00 \ x00 \ x73 \ x02

"

" \ xeb \ x06 \ x68 \ x90 \ x90 \ x90 \ x90 \ xc3 \ x83 \ x f 8 \ x25 \ x74 \ x06 \ x68 \ x90 \ x90

"

" \ x90 \ x90 \ xc3 \ x f f \ x15 \ x90 \ x90 \ x90 \ x90 \ x68 \ x90 \ x90 \ x90 \ x90 \ xc3 " ;

Mecanismo elegido, y detalles de implementación del mismo

Tras las dos aproximaciones que se desarrollaron, se decidió generar un sistema de recogida

de datos mediante la sobreescritura de la sys_call_table, dado que se trata del método arqui-

tectónicamente más neutro y más transparente para el usuario. Por lo tanto el sistema que se

ha implementado necesita el archivo System.map original para funcionar. Esto implica que o

516 bytes el salto condicional y 5 la comparación.52Inserta un valor en la pila del sistema y salta a él mediante el ret.53código ensamblador embebido en el código fuente del LKM.

249

bien se ha compilado el kernel, o bien junto con el mismo se incluyen los archivos System.map

originales54.

La naturaleza desestructurada del Kernel de linux, ha puesto alguna traba al desarrollo del

proyecto, como las cabeceras de las funciones que han de reemplazar a las originales han de ser

exactamente iguales, se hacía necesario buscar las declaraciones de las funciones por todo el árbol

de directorios del Kernel. Para automatizar todo este sistema, se desarrolló un script en Shell

script, que generaba las funciones necesarias para hookear todas las syscalls del kernel de linux.

Otro de los escollos a superar ha sido la comunicación kernel / userland que había que realizar,

dado que la intercepción se realiza a nivel de Kernel, y el análisis del mismo se realiza en otra

máquina. Este sistema implica que hay que realizar una comunicación kernel-userland, existiendo

las siguientes alternativas para que esta comunicación exista:

Netlink sockets Kernel-Userland.

Dispositivos de caracteres.

Dispositivos /proc.

Finalmente la comunicación se estableció mediante dispositivos /proc, generando un dispositivo55

mediante el cual se puede controlar el agente, ver estadísticas y para recibir las syscalls logeadas.

Listing 3.19: Ejemplo de la creación y destrucción de un dispositovo /proc.

1 stat ic int __init proc_in i t (void ) {

i f ( ( p r o cF i l e = create_proc_entry ( " e j emp l o " , 0644 , NULL) )==

NULL)

{

remove_proc_entry ( " e j emp l o " , &proc_root ) ;

6 pr in tk (KERN_ALERT " E r r o r : Could not c r e a t e p r o c

e n t r y \n" ) ;

return −ENOMEM;

}

procF i l e−>owner = THIS_MODULE;

procF i l e−>proc_iops = &InodeAllowedOps ;

11 procF i l e−>proc_fops = &FileAllowedOps ;

procF i l e−>mode = S_IFREG | S_IRUGO | S_IWUSR;

procF i l e−>uid = 0 ;

procF i l e−>gid = 0 ;

procF i l e−>s i z e = 1000 ;

54Echo que se da en la gran mayoría de las distribuciones de linux actuales.55Concretamente /proc/sysmonitor.

250

16 return 0 ;

}

stat ic void __exit proc_exit (void ) {

remove_proc_entry ( " t e t a " , &proc_root ) ;

}

La ventaja de utilizar este tipo de dispositivos radica en que su creación es automática, al

contrario de los dispositivos de caracteres, para los que hay que ejecutar el comando mknod,

además permiten la ejecución de comandos como cat, tail..., de esta manera la utilización del

sistema es mucho más sencilla y simple para el usuario, que utilizando mecanismos netlink, en los

cuales hay que recompilar el kernel y manejar complejas APIs para realizar dicha comunicación.

Otro de los grandes escollos que planteó la implementación del sistema de recolección, fue la

sincronización en el kernel y evitar que ocurran condiciones de carrera56, para lo que se utilizaron

sistemas de sincronización a nivel de kernel, esto se da por la naturaleza multiproceso de los

sistemas GNU/Linux y que hacen que un proceso pueda pararse en cualquier momento para

que su ejecución sea relevada por otro, este proceso plantea el problema de como que algunos

procesos pueden escribir en zonas que otro proceso este leyendo.

Los sistemas utilizados han sido los siguientes:

spin_locks: Cerrojos, que los procesos abren y / o cierran mediante operaciones atómicas57,

y que permiten hacer exclusiva la utilización de un recurso por parte de un proceso.

Semáforos a nivel de kernel, con un funcionamiento similar a los semáforos a nivel de

usuario.

Colas de espera.

Mediante estos métodos se ha realizado un sistema de recepción de datos que ante pruebas de

stress no pierde datos ni entra en condiciones de carrera. Esta parte es importante dado que un

fallo, o un interbloqueo a nivel de kernel, puede ser especialmente dañino, dado que hay grandes

posibilidades de que el sistema sufra un kernel panic58.

Existe una sola situación en la que se desechan datos de syscalls, que es cuando el bu�er en el

que se almacenan los datos se llenan (es decir, no se ha leído lo su�ciente), para evitar un bu�er

over�ow.

Otra situación que ha habido que solventar es la identi�cación del proceso, dado que cuando

estamos recibiendo la syscalls de un proceso, podemos saber el identi�cativo del proceso que

recibe dichas peticiones, pero no sabemos el nombre del ejecutable, para ello se utiliza un método

56También conocidas como race conditions, se producen cuando dos o más procesos se quedan interbloqueadosa la espera de un recurso que nunca se va a liberar.

57El proceso no se puede quedar a mitad de ejecución de dicha operación.58Nombre con el que se conoce a los fallos de Kernel.

251

que permite identi�car el ejecutable del que proviene dicho proceso, de esta manera se puede

identi�car no solamente el nombre del proceso59, sino el ejecutable responsable de dicho proceso.

Listing 3.20: Código que permite saber el ejecutable padre del que proviene el proceso.

int char ∗GetEXE(void ){

i f ( current−>mm) {

struct vm_area_struct ∗vma = current−>mm−>mmap;5 while (vma) {

i f ( (vma−>vm_flags & VM_EXECUTABLE) && vma−>vm_file ) {

char ∗buf = kmalloc (PAGE_SIZE, GFP_KERNEL) ;

char ∗p ;i f ( buf == NULL) return NULL;

10 memset ( buf , 0 , PAGE_SIZE) ;

p = d_path (vma−>vm_file−>f_dentry , vma−>vm_file−>f_vfsmnt ,

buf , PAGE_SIZE) ;

i f ( ! IS_ERR(p) ) {

memmove( buf , p , s t r l e n (p) + 1) ;

return ( const char ∗) buf ;

15 }

k f r e e ( buf ) ; return NULL;

}

vma = vma−>vm_next ;

}

20 }

return NULL;

}

El texto se envía en formato texto plano a la zona de usuario, debiendo el agente de zona de

usuario �parsear �60 cada cadena de texto para conseguir toda la información.

Este agente de zona de usuario, conecta el sistema de recolección de datos con la infraestruc-

tura del sistema de análisis de Mendizale, enviando por red la información recogida por el agente

en el kernel de linux.

3.2.2. Recogida de información en sistemas Windows Mobile.

Windows Mobile es un sistema operativo compacto basado en el API Win32 de Microsoft, que

combinado con una serie de aplicaciones especí�camente diseñadas para este tipo de sistemas,

59Que se puede obtener del valor comm del task_struct que apunta current.60Extraer las diferentes partes de información de una unidad. En este caso concreto de una línea de texto.

252

da soporte a muchos de los dispositivos móviles que se encuentran hoy en el mercado61.

Los sistemas Windows Mobile, en la totalidad de sus versiones Windows CE 3.X, 4.X y 5.X

presenta unas características especiales en el manejo de memoria62, comunicación entre procesos...

que hacen imposible reutilizar herramientas desarrolladas para la auditoría de syscalls en sistemas

Windows convencionales en este tipo de sistema operativo.

Cuestiones de Desarrollo.

Los sistemas Windows CE, carecen por completo de sistemas de debuggeo o de programación

a bajo nivel, por lo que el desarrollo de cualquier tipo de aplicación o de agente de recolección de

información, suponía un gran esfuerzo por parte del equipo de investigación. Afortunadamente,

en la última versión del sistema de desarrollo Microsoft Visual Studio 2005, conscientes de la

situación que existía, Microsoft ha incorporado funcionalidades de depuración en tiempo real y

remotos de aplicaciones para Windows CE.

En concreto, la última versión de �Windows Device Emulator�, soporta la emulación real

de aplicaciones para Windows CE en todas sus versiones, lo que permite que una aplicación

pueda ser probada y desarrollada en un dispositivo63 que tenga las mismas características y

funcionalidades que el dispositivo �nal en el que se va a ejecutar la aplicación �nal. Este echo ha

facilitado la investigación dado que se ha podido emular y desarrollar el agente en un ambiente

idéntico al de un dispositivo físico real.

De esta manera en este momento es posible debugear directamente sobre el dispositivo físico

o sobre el emulador, pudiendo incluso �atachearse�64 a procesos activos bien en la máquina real,

o en el emulador.

Sistema de llamadas al Kernel de Windows CE

El sistema de llamadas al kernel de Windows CE, es similar al de sus hermanos mayores,

los ejecutables tienen un formato PE65, por lo que las llamadas al kernel de NT, no se realizan

directamente desde los programas sino que se realizan desde diferentes DLL que realizan dichos

accesos en lugar del el proceso directamente.

61A �nales del 2004 ya se hizo líder de ventas de software para este tipo de dispositivos por delante de PalmOS.http://www.canalpda.com/displayarticle180.html

62Los sistemas Windows Mobile, poseen un mecanismo propio de protección de memoria, que establece una capade abstracción entre la memoria virtual ofrecida por el procesador y la memoria que utilizan los procesadores. Estemecanismo permite controlar los accesos de lectura / escritura a zonas de memoria que no hayan sido reservadasanteriormente en la capa de abstracción[298].

63Se trata de un dispositivo virtual, pero de las mismas características que un sistema Windows CE normal.64Se trata de una técnica de depuración que permite parar procesos en ejecución y ver lo que están ejecutando

en cada momento.65Portable Ejecutable, formato de archivo ejecutable introducido en la versión 3.1 del kernel de NT. Inspirado

en el formato COFF de sistemas Unix-like, mantiene la compatibilidad con todas las versiones de Windows. Deahí el nombre de Portable.

253

Figura 3.14: Esquema del formato Portable Ejecutable

Este proceso es similar al que realiza la glibc, en sistemas GNU/Linux, pero en este sistema,

las llamadas las realizan diferentes DLLs en vez de una sola librería como la glibc.

Dada que la ubicación de las DLL dentro del sistema del usuario puede variar de una instala-

ción a otra, el PE ha de especi�car en la cabecera las DLL que va a necesitar, para que el loader

resuelva en dinámicamente las dependencias y si es necesario cargue las DLL que no estuvieran

cargadas en ese momento. De la misma manera, el formato PE, de�ne en la IAT66, las funciones

que necesita de las DLL.

Desarrollo del sistema de recogida de datos para Windows Mobile

Para realizar la recogida de datos necesaria para el proyecto hace falta interceptar en algún

punto la llamada en cualquiera de sus fases desde la IAT, hasta el dispacher del kernel de Windows

CE.

Para realizar dicha aproximación varias opciones fueron barajadas[247], la primera de ellas

consistía en la modi�cación en la memoria permanente de las DLL involucradas en las llamadas

al Kernel de Windows CE. De esta manera sería posible inyectar código en cada DLL, o realizar

un wrapper67 sobre la misma. Sin embargo este proceso llevaría consigo la necesidad de modi�car

la memoria ROM de todos los dispositivos en los que se quiere instalar el agente.

Soluciones heredadas de sistemas Windows, como la de modi�car la IAT de todos los procesos

del sistema, o inyección de código en las entradas de las funciones exportadas por las DLL fueron

desechadas por el coste computacional que necesitaban y la limitada potencia de cálculo de los

sistemas ARM en los que se ejecuta Windows CE.

66La IAT es el lugar donde el cargador escribe las direcciones de las funciones exportadas de alguna DLL.67Nombre técnico para un envoltorio software de ciertas funciones o DLLs.

254

Figura 3.15: Esquema de llamadas para ejecutar una operación a nivel de kernel.

La única solución una vez desechada las ideas anteriores, fue la de realizar una recogida de

datos a nivel de kernel, modi�cándolo en tiempo real, para que el usuario �nal no tenga que

realizar pesadas instalaciones ni ralentice el sistema.

Para implementar una solución de este tipo, se necesita un gran conocimiento de cómo se

enumeran internamente las funciones, y de cómo se trata Windows CE las llamadas a las funciones

de su kernel. Pero, afortunadamente Microsoft liberó parte de las especi�caciones internas de

su sistema operativo para sistemas móviles en el cuál se podían ver la distribución de ciertas

estructuras del kernel de linux, y de ciertas llamadas no documentadas del API de Windows CE,

en concreto la llamada PerfomCallBack4, ha sido de especial interés para el estudio que ha sido

llevado a cabo.

Entre los datos que se encontraron en dichas especi�caciones, se encuentran varias estructuras

de gran importancia como puede ser la KDataStruct, que incluye información interna sobre

todo el sistema, y se encuentra siempre en la misma dirección de la memoria68. Dentro de esta

estructura podemos encontrar:

SYSHANDLE_OFFSET: que da acceso al proceso actual.

KINFO_OFFSET: que da acceso a un array de estructuras UserKInfo, que poseen infor-

maciones tan importantes como la lista de módulos, el heap del kernel, y la importantísima

tabla de punteros a las API, SystenAPISets.

En Windows CE existen dos tipos de API, las implícitas y las basadas en �handles�. Las

primeras son accesibles de forma global mediante el uso de la tabla de punteros a las API, encon-68En concreto se encuentra en las direcciones 0xFFFFC800 para el procesador ARM y 0x00005800 para el resto

de CPU soportadas por el sistema.

255

Figura 3.16: Esquema de la información contenida en la estructura KDataStruct

trándose indexadas por su el identi�cativo de su categoría (SH_WIN32, SH_GDI, SH_WMGR,

etc.) y su número de API. Este tipo de interfaces, se encuentran contenidas en objetos de kernel

como mutex o eventos y son referenciadas mediante su número de API y el puntero (handle)

al objeto que las contiene. Este tipo de APIs no son actualmente monitorizadas por el agente

desarrollado.

En los sistemas Windows CE, las llamadas a las funciones del kernel, se realizan mediante la

llamada a unas direcciones de memoria especiales llamadas �traps�, que generan una excepción

que son gestionadas por el dispacher del kernel de Windows CE.

La manera más limpia y rápida de realizar una auditoría de las syscalls que ocurren en un

sistema Windows CE, es modi�car los punteros de las funciones que realizan la gestión de las

excepciones generadas por los traps, para registrar los datos que nos son relevante para luego

devolver el control a la función original suplantada por nuestro agente.

Como algunas funciones del Kernel de Windows CE, realizan una comprobación de que el

propietario del thread en ejecución lo que hace que el agente deba de residir dentro del propio

thread.

Además como ya se ha comentado con anterioridad, las llamadas a las funciones del kernel de

Windows CE, se abstraen dentro de llamadas a DLLs, en este caso, existe una DLL, coredll.dll,

que mantiene una caché con las direcciones de las funciones que tratan las llamadas, por lo

tanto mediante este sistema que hemos explicado, ocurre el problema de que las funciones que

son llamadas desde coredll.dll, no serían redireccionadas debido a la caché que mantiene en su

interior.

Para ello, si queremos también capturar las llamadas de la librería core.dll, habremos de

modi�car las la cache de la librería para todos los procesos.

Al igual que en los procesos en Windows NT/2000, la inyección de una DLL, pasa por

funciones no documentadas, en este caso PerfomCallBack4, que provoca la creación de un thread

256

Figura 3.17: Detalle de interfaz de usuario del agente.

remotamente en el proceso que se desee. La inyección previa de un código binario que efectúe la

llamada a loadlibrary, hace el resto.

Existe también la necesidad de monitorizar también las llamadas de los nuevos procesos que

se creen y no solamente de los que ya existan el sistema en el momento de la carga, por lo que

también es necesario monitorizar la llamada CreateProcess de la API del kernel, para realizar el

mismo proceso con los nuevos procesos.

Por lo tanto una vez de�nida la metodología a seguir, se dividió el desarrollo en dos partes

separadas:

El apartado de modi�cación de la caché de coredll.dll, de la inyección de una dll en to-

dos los procesos que llamen a las funciones nuestras, y la monitorización de la función

CreateProcess, para realizar lo mismo con los procesos nuevos.

El apartado de comunicación con la infraestructura de Mendizale y de interfaz de usuario.

La comunicación entre ambos componentes se realiza mediante la librería HTRACE[356], que

permite la comunicación entre las dos partes del sistema mediante memoria compartida imple-

mentado como un bu�er circular.

El apartado de comunicación con la infraestructura de Mendizale, lo que realiza es leer las

llamadas al Kernel de Windows CE del bu�er circular, y enviarla mediante una conexión TCP

a la infraestructura.

La gestión de la con�guración y de la interfaz de usuario sigue dos caminos separados, por

una parte la con�guración de las llamadas que son capturadas y las que no, cuestión que sea

realiza mediante un �chero XML, en el que se especi�ca qué llamadas son capturadas y cuáles

no.

Por otra parte se puede con�gurar el puerto y dirección ip a la que se puede enviar el resultado

de la captura de las llamadas mediante la interfaz grá�ca, que es minimalista pero muy potente.

El sistema inserta un icono en el systray de Windows Mobile, estando en todo momento visible

y mostrando menús de con�guración con el botón derecho del ratón.

Este sistema de interfaz grá�ca también permite parar y arrancar el sistema de logeo de las

llamadas, lo que permite al usuario del sistema �nal controlar solamente los aspectos necesarios

para él.

257

3.2.3. Recogida de información en sistemas Windows.

Tradicionalmente Microsoft no ha caracterizado por permitir al usuario �nal acceder a bajo

nivel a su plataforma Windows. Sin embargo la gran cantidad de usuarios que utilizan esta

plataforma siempre ofrece gran cantidad de información a los investigadores de los sistemas

operativos.

Desde que Desde que Windows 95 viera la luz en Agosto de 1995, se han publicado muchos

estudios y ensayos, sobre su funcionamiento interno y programación a bajo nivel. Gran parte de

estas investigaciones han sido llevadas a cabo por la comunidad de programadores de virus[315]

, que vieron en esta plataforma un entorno ideal al que migrar sus creaciones.

Actualmente, existen 3 grandes ramas en el mundo Windows. Por una parte tenemos la

conocida rama 9x, surgida del nacimiento de Windows 95, y dirigida al mercado doméstico.

Dada su orientación, la rama 9x carece de mecanismos de seguridad avanzados y permite una

gran �exibilidad y compatibilidad con aplicaciones heredadas de MSDOS y Windows 3.x. La

rama 9x comprende también los sistemas operativos Windows 98 (1998) y Windows Millenium,

además de las diferentes revisiones de los mismos, Windows 95 OSR2, Windows 98 SE, etc.

Por otra parte encontramos la rama NT (New Tecnology), que surgió en la década de los

noventa con una clara vocación profesional, esta familia de sistemas operativos (Windows NT

3.X, Windows NT 3.5.X, Windows NT 4.X y Windows 2000), ofrecían una robustez y �abilidad

ampliamente superior a los sistemas Windows 9X, que tenían un marcado carácter doméstico.

El comienzo de milenio, trajo consigo la eliminación por parte de Microsoft de la rama

Windows 9X, para ofrecer dos versiones de su sistema Windows XP, la versión Home Edition,

y la versión Professional, que ha disfrutado de una amplia difusión y fama en los sistemas

profesionales y privados, que puede considerarse como parte de la familia NT, ya que se trata de

una evolución de los sistemas NT.

De las misma manera los sistemas Windows 2003 (en todas sus versiones), también con un

marcado carácter profesional, se consideran dentro de los sistemas NT.

Otra de las ramas de los sistemas Windows, se trata de su versión para dispositivos móviles

con recursos limitados, como pueden ser PDAs o Tablet PC, Windows CE, tanto en sus versiones

CE4.1 (Windows Mobile 2003SE), ó CE 5.0 (Windows Mobile 2005).

Para �nalizar, y con la inminente comercialización de los sistemas Windows Vista, surge

la última versión de Windows para PC con grandes cambios muy novedosos sobre las ramas

anteriores.

Actualmente el mercado doméstico de Microsoft esta copado con Microsoft Windows XP. El

mercado profesional utiliza también Windows XP (Professional) para escritorio, y Windows 2000

y 2003 para servidores.

El agente de recogida de información desarrollado está destinado a su uso en sistemas opera-

tivos de la rama NT, a partir de Windows 2000, cubriendo de esta manera la casi totalidad del

mercado actual.

258

Métodos de recogida de datos en sistemas Windows

Los sistemas de Microsoft Windows, funcionan a en dos niveles ofrecidos por la arquitectura

i386, los niveles 0, y 3 respectivamente. El kernel se ejecuta en nivel 0 (ring 0), y las aplicaciones

y procesos del sistema lo hacen a nivel 3 (ring 3).

Microsoft siempre ha tenido gran cuidado con mimar la compatibilidad entre sus plataformas

mediante la plataforma Win32, es decir, que una aplicación desarrollada en un sistema Windows

de la rama 9x, funciona igualmente en otro sistema de la rama NT.

Dado que en ambas ramas, el kernel es totalmente diferente en las dos ramas de Windows,

también lo son los procedimientos de llamada y de retorno de datos a la zona de usuario. Con

el �n de salvar esta problemática en compatibilidad, los procesos de zona de usuario, nunca

llamarán directamente al kernel de Windows, sino que lo harán mediante la capa Win32, la cuál,

se encargará de la comunicación con el Kernel.

La capa win32 esta compuesta por una serie de DLLs del sistema que exportan un conjunto

de funciones similares, tanto en 9x como en NT, a los programas de usuario. A este conjunto de

funciones exportadas se le denomina la API win32.

A pesar de que la API ofrecida por la capa Win32, sea similar en todos los sistemas Windows,

la implementación interna de dicha capa, y de la comunicación con el kernel de Windows es

completamente diferente entre los diferentes sistemas. Por lo tanto la capa Win32, ofrece un

nivel de abstracción clave para el mantenimiento de la compatibilidad entre diferentes sistemas

Windows.

En el caso de la rama NT, la comunicación kernel - zona de usuario se realiza mediante dos

mecanismos diferenciados :

Mediante la interrupción 2E que al igual que la interrupción 80 en sistemas GNU/linux es

gestionada en zona Kernel, las DLL que forman la estructura de Win32, suelen terminar

su ejecución mediante la llamada a la interrupción int2Eh.

Listing 3.21: Utilizanción de int2Eh en Windows

MOV EAX, SyscallNumber ; r e que s t ed s y s c a l l number

2 LEA EDX, [ESP+4] ; EDX = params . . .

INT 2Eh ; throw the execu t i on to the

KM hand ler

RET 4∗NUMBER_OF_PARAMS ; r e turn

Mediante la utilización de la instrucción optimizada sysenter[152] que realiza una ejecución

más rápida[31] que los sistemas tradicionales.

Listing 3.22: Utilizanción de int2Eh en Windows

push fn ; push s y s c a l l number

259

pop eax ; EAX = s y s c a l l number

push eax ; t h i s one makes no d i f f

ca l l b ; put c a l l e r address on

s t a c k

5 b : add [ esp ] , ( of fset r − of fset b) ; normal i ze s t a c k

mov edx , esp ; EDX = s tack

db 0 fh , 34h ; SYSENTER in s t r u c t i o n

r : add esp , ( param∗4) ; normal i ze s t a c k

De forma general, el sistema Win32, sigue utilizando la interrupción 2E, en lugar de la optimizada

sysenter, por lo que un debugger an nivel de usuario podría recoger la información de las llamadas

a las DLL, hasta que éstas efectúen la llamada al kernel de NT mediante dicha interrupción. Por

ejemplo, una llamada a la función ExitProcess de Kernel32.dll, prepara los argumentos para la

llamada ZwTerminateProcess en NTdll.dll, la cuál genera llamando a KiFastSystemCall, una

interrupción 2e.

De todo este funcionamiento se puede deducir, que existen dos maneras de monitorizar las

llamadas a el Kernel de Windows, una a nivel de zona de usuario, recibiendo las llamadas a las

DLL que conforman la capa Win32, y otra a nivel de Kernel, recibiendo las llamadas que realizan

dichas DLL al kernel de NT.

260

Figura 3.18: Esquema de memoria de NT, y posible puntos de recolección de datos.

Monitorización de llamadas a la API Win32

Por lo tanto el método a alto nivel, o a nivel de zona de usuario sería interceptar las llama-

das a la API de Win32 que estandariza las llamadas al kernel de Windows. Para realizar esta

acción, existen diversos métodos, que permiten recoger información de este tipo de llamadas,

interponiendo el agente encargado de la recolección de datos entre el llamador y el llamado en

la función.

A continuación se enumeran las opciones posibles que se han contemplado para la implemen-

tación del agente a este nivel de el sistema operativo Windows.

Monitorización de la tabla de informaciones

Cuando un proceso hace uso de una llamada a una función implementada en una DLL, los

procesos no se limitan a saltar a la dirección de la función exportada. De echo aunque la dirección

de la función exportada se mapea en el propio espacio de direcciones de el proceso, no se garantiza

que las direcciones sean las mismas para todos los procesos, ni de que los desplazamientos para

la función exportada se mantenga entre diferentes sistemas operativos.

261

Este echo, puede ser fácilmente observado comparando con un debugger que las direcciones

de las funciones exportadas por el sistema para una misma función en los sistemas operativos

Windows 2000 y Windows NT, son diferentes.

Si diseñamos en ensamblador un programa que efectúe una llamada a ExitProcess asumiendo

como �ja su ubicación en memoria para Windows XP, veremos como la ejecución de dicho

programa en un Windows 2000, u otro sistema operativo Microsoft, resulta en una excepción.

Los primeros ataques informáticos en forma de virus y shellcodes (ataques de inyección de

código), tomaban como �jas las direcciones de memoria de las API que requerían, de tal manera

que eran especí�cos para una versión de Windows, fallando su aplicación genérica al resto de

versiones. En ocasiones, esta especi�cidad es tan grande que su aplicación para la misma versión

del sistema operativo, pero en distintos idiomas, no es viable.

Los primeros ataques informáticos en forma de virus y shellcodes (ataques de inyección de

código), tomaban como �jas las direcciones de memoria de las API que requerían, de tal manera

que eran especí�cos para una versión de Windows, fallando su aplicación genérica al resto de

versiones. En ocasiones, esta especi�cidad es tan grande que su aplicación para la misma versión

del sistema operativo, pero en distintos idiomas, no es viable. Parece claro entonces que el proceso

no puede asumir una posición �ja para las funciones exportadas por las DLL. Lo que ocurre en

realidad es que el proceso de usuario realiza una llamada a la API, de una forma indirecta a

través de la tabla de importaciones (IAT)69.

Todos los programas win32 poseen formato PE (Portable Ejecutable), donde el .EXE se

encuentra dividido en un serie de cabeceras y secciones. Una parte de la cabecera PE esta

formada por la tabla de importaciones IAT, donde el programa expresa al cargador de Windows,

la lista de dependencias con funciones de DLLs.

El cargador del sistema operativo, realizará en el momento de la ejecución de dicho programa,

un mapeo de las DLLs necesarias donde del espacio de direcciones del proceso, y una resolución

dinámica de las funciones requeridas en la IAT. Se puede pensar en la IAT, como un largo

conjunto de buzones, donde en cada uno existe una etiqueta que indica el nombre de la función y

la DLL que la contiene. El cargador de Windows, se encargará en tiempo de carga, de introducir

un papel en cada buzón indicando la dirección de memoria absoluta de dicha función.

Posteriormente el proceso de usuario, cuando efectúa una llamada a una API como Exit-

Process, tan solo realiza un salto indirecto sobre la IAT. De esta forma se garantiza una total

compatibilidad entre diferentes versiones de Windows.

La técnica de interposición basada en la modi�cación de la IAT, consiste en la modi�cación

de la tabla de importaciones de todos los procesos existentes, y de los nuevos generados. Esto se

puede hacer mediante el uso de ciertas APIs de Windows que permiten la escritura en la memoria

de otros procesos. El único problema es que la función trampolín a la que se redireccionará cada

API interpuesta, ha de residir en el espacio de direcciones de memoria del proceso remoto. La

69Inport Address Table.

262

forma más sencilla de implementar esto es introduciendo todo el sistema de monitorización en

una DLL, y mapeando posteriormente dicha DLL en el espacio de direcciones de memoria del

proceso remoto al cual se pretende monitorizar. Esto se consigue mediante la introducción y

ejecución de un pequeño trozo de código ejecutable en el proceso remoto, que se encargue de

realizar una llamada a la API (LoadLibrary) que realice la carga de la DLL[218].

Existe un pequeño problema con la implementación de esta técnica de interposición. En

ocasiones, el proceso tan solo llama a un pequeño conjunto de funciones de DLL, presentes en

su IAT, y son estas DLLs las que internamente efectúan las llamadas a las DLLs del sistema.

Para evitar que estas llamadas pasaran desapercibidas (ya que no usan la IAT del proceso,

sino la IAT de la propia DLL que las contiene), hay que realizar recursivamente el proceso de

modi�cación de la IAT para todas las DLL utilizadas por el proceso.

Además, en ocasiones los procesos utilizan la carga y resolución dinámica de funciones de

DLLs, utilizando para ello las API LoadLibrary() y GetProcAddress. Con el �n de detectar esto

último para realizar la modi�cación de la IAT de las nuevas API, es necesario interponer sendas

API LoadLibrary y GetProcAddress, para llamar en su ejecución al proceso de modi�cación de

IAT, antes de retornar el control al proceso que realizó la llamada.

Existen numerosas herramientas que implementan esta técnica, y todos ellos adolecen un

grave problema que sugiere la utilización de otro tipo de técnica para implementación de nuestro

agente.

Además, esta técnica para la interposición tan solo es efectiva cuando el proceso utiliza

método estándar para la resolución de la API. En efecto todos los procesos tienen la garantía de

utilizar este tipo de métodos, pero bajo los efectos de un ataque la situación cambia.

En los ataques de inyección de código, como por ejemplo los bu�er overfLow, un pequeño

trozo de código, llamado shellcode, es insertado y ejecutado dentro del proceso remoto atacado.

Esta shellcode efectúa una serie de acciones sobre el sistema que resultarán en una vulneración de

la seguridad del mismo. La shellcode requiere de la llamada a APIs y por tanto ha de resolverlas

dinámicamente.

Si bien es cierto que la shellcode podría utilizar la IAT para la resolución de la dirección de

las APIs, buscando en memoria el inicio de la tabla, existen otros métodos mucho más efectivos

para realizar dicha resolución que no toman la IAT como referencia[250].

Uno de ellos, por ejemplo, es la utilización del PEB (Program Execution Block) del proceso

para obtener la base de la dirección en memoria de kernel32.dll a �n de localizar su tabla de

exportaciones para resolver todos sus métodos.

Al no utilizar la shellcode la IAT en su proceso de resolución, no se vería afectada por el

�engaño� de la modi�cación de la IAT, y sus llamadas pasarían totalmente desapercibidas a

ojos del agente HIDS. El HIDS sería en este contexto totalmente incapaz de detectar ninguna

modi�cación entre las APIs llamadas por un proceso sano y uno que se encontrara bajo ataque.

En resumen, la interposición por modi�cación de IAT se muestra muy efectiva para el mode-

263

Figura 3.19: Ejemplo de modi�cación de memoria en el punto de inicio

lado de procesos en situaciones normales, pero gravemente incapaz de modelar todos los compor-

tamientos de ataque. Por ello se ha descartado este método para la implementación de nuestro

agente.

Envolviendo DLLs

Otra técnica de interposición posible, consiste en la modi�cación en disco de todas las DLLs

del sistema (capa win32) a �n de modi�car el inicio de todas sus funciones para incluir el código

necesario para monitorizar su uso por parte del agente.

Un forma sencilla de implementar esta técnica, es la creación de DLLs envoltorio con las

mismas funciones exportadas que las originales. Cada función exportada sería simplemente una

función trampolín hacia la función original de la DLL real.

Esta técnica no resulta viable para su aplicación en nuestro HIDS ya que implicaría la modi-

�cación permanente en disco de importantes archivos de sistema, complicando de esta forma la

distribución e instalación del agente en sistemas en producción.

Modi�cando en memoria el punto de inicio de las API Win32

Otra aproximación posible es la modi�cación en memoria, en tiempo real, del inicio de todas

las funciones relevantes exportadas por las DLLs de sistema, para incluir una llamada a una

rutina del agente que realice la monitorización de la misma antes de devolver el control a la API

original.

Para simpli�car el proceso, los bytes sobrescritos por el CALL introducido habrán de ser

restituidos (ejecutables) antes de que el control sea retornado. De esta manera el sistema, queda

igual una vez que se ha dejado de monitorizar las llamadas al API.

264

Este método es mas directo que la modi�cación de la IAT y no requiere ser realizado recur-

sivamente por cada DLL, o la monitorización del uso de GetProcAddress. En efecto, al realizar

la interposición en el inicio de la cada función exportada, ésta es aplicable a todas las otras DLL

del proceso así como al proceso en si mismo.

Dado que cada DLL es mapeada de forma independiente en el espacio de direcciones de

memoria de cada proceso de usuario del sistema, la modi�cación de una de ellas no implica el

cambio de la misma en el resto de los procesos (no se encuentra en memoria compartida).

Por lo tanto el proceso de interposición habrá de realizarse para todos los procesos del sistema,

existiendo la necesidad de monitorizar la ejecución de nuevos procesos (mediante la interposición

de la API CreateProcess), a �n de realizar el mismo proceso con ellos.

Finalmente, las funciones �trampolín� que se interponen a la llamada a las API originales, han

de residir en el mismo espacio de direcciones de memoria del proceso que efectúa la llamada. Para

que esto se cumpla, dichas funciones han de ser introducidas en la memoria del propio proceso.

Existe una librería, llamada Detours [168], provista por Microsoft Research que implementa

este método de interposición.

Detours automatiza el proceso de modi�cación del inicio de las APIs requeridas y la gestión

de la inyección remota de la DLL. Las funciones trampolín residen por tanto en una DLL que es

insertada en el proceso a monitorizar (o en todos si se desean monitorizar todos), para comunicar

mediante un PIPE, toda la monitorización realizada.

Interposición de llamadas al sistema en modo kernel

Al contrario que el resto de los métodos de monitorización que eran implementados a nivel

de usuario (ring-3), se presenta también la posibilidad de implementar la interposición a nivel de

kernel.

Como ya se ha comentado, las DLL del sistema terminan efectuando llamadas al kernel me-

diante la interrupción 2e, o la instrucción sysenter. El kernel posee un dispatcher que redirecciona

la ejecución a la función correspondiente indicada en los registros del procesador. Para ello el

dispatcher, utiliza la tabla de punteros a servicios (system service table) que contiene la ubicación

en memoria de las distintas funciones de kernel.

Modi�cando dicha tabla de punteros a servicio, es posible redireccionar la llamada a las

mismas a nuestras funciones trampolín, que tras registrar su ejecución, redireccionarán el control

a las originales.

Las funciones trampolín habrán por tanto de residir a nivel de kernel ring-0, y el efecto de la

interposición será global a todos los procesos.

Existe una librería provista por la empresa BlindView, recientemente adquirida por Symantec,

que implementa esta técnica para la monitorización genérica de llamadas al sistema. Su nombre

es strace[38].

Strace esta compuesto por un driver (.SYS) que corre a nivel de kernel, conteniendo las fun-

265

Figura 3.20: Esquema de funcionamiento de la librería strace

266

ciones trampolín y realizando la modi�cación de la tabla de punteros a servicios, y un programa

de usuario que se comunica con el driver de kernel mediante una tubería (named pipe).

Efectividad de los diferentes métodos de interposición, para el modelado de procesos

en el HIDS.

Al igual que en el caso de GNU/Linux, la efectividad de un HIDS por modelado de syscalls en

la plataforma Windows, depende de la capacidad del agente para monitorizar todas las syscalls

generadas, incluso aquellas realizadas a bajo nivel por los ataques y el malware, y de la hipótesis

que un ataque es una desviación visible de las secuencias normales de llamadas la sistema del

proceso.

Este último punto ya ha sido demostrado en otros estudios[375] para otras plataformas UNIX

(Solaris) y también ha sido demostrado para GNU/Linux en apartados anteriores. En este apar-

tado nos centraremos en su demostración práctica para la Windows 2000/XP.

También estudiaremos la capacidad del agente desarrollado, explicado en detalle en el apar-

tado anterior, para la detección de las syscalls generadas por los procesos y el malware.

En el apartado de GNU/Linux nos centramos en el estudio de las llamadas al sistema pa-

ra ataques de inyección de código. En Windows hemos reproducido los mismos experimentos,

utilizando sencillos programas vulnerables que escuchan puertos de red, y creando exploits en

Python que los atacan.

Los resultados se muestran similares a los obtenidos con GNU/Linux, pero con algunas ma-

tizaciones importantes que pasaremos a relatar. Para la monitorización de los exploits hemos

utilizado la librería strace y también Detours, con el �n de determinar la diferencia entre las

mismas, y seleccionar la más adecuada para su implementación en el agente.

En términos generales Detours se muestra mas precisa a la hora de trazar el comportamiento

del proceso bajo ataque, ya que strace se muestra incapaz de re�ejar ciertas acciones como la

escritura de datos en un socket.

Strace por otro lado, se muestra mucho más e�caz para la detección de llamadas al sistema

efectuadas a bajo nivel por parte de ciertas shellcodes, para las cuales Detours no detecta nada. A

pesar de que los procesos de usuario siempre utilizan la API de Windows para efectuar llamadas

al sistema, las shellcodes por el contrario suelen muchas veces realizar las llamadas a bajo nivel

ejecutando directamente la int2e o el procedimiento syscall.

Detours además presenta gravísimos problemas de rendimiento al intentar monitorizar un

gran conjunto de syscalls (1400 en nuestras pruebas) dejando el sistema prácticamente inutiliza-

ble.

Además de demostrar su viabilidad para la detección de ataques de inyección de código, hemos

querido determinar su capacidad para la detección de malware para lo cual se ha monitorizado

la acción de un virus informático del tipo win32.

Para las pruebas hemos monitorizado las llamadas al sistema generadas por un proceso note-

267

Figura 3.21: Monitorización de syscalls de un proceso infectado con el virus Satir.994 utilizandostrace

pad sin infectar, y las hemos comparado con el mismo proceso una vez infectado.

Observamos que en la diferencia encontramos las acciones del virus, muchas de las cuales son

traducidas en llamadas al sistema, que nuestro agente es capaz de monitorizar. Esta observación

abre la puerta a la utilización de modelos para detección mediante patrones o anomalías.

Diseño e implementación del agente

El agente desarrollado para Windows 2000/XP implementa la técnica de interposición de

llamadas al sistema mediante la modi�cación de la tabla de punteros a servicios (system service

table), a nivel de kernel (ring-0).

El agente esta compuesto por 2 componentes principales, uno que corre a nivel de kernel

(ring-0) y otro a nivel de proceso de usuario (ring-3).

El componente de kernel hace uso del driver provisto por la librería strace[38] de BlindView

c©. Dicho driver permite la interposición de syscalls en sus diversas categorías, posibilitando la

selección de las mismas en base a �ltros.

La comunicación con el componente de nivel de usuario se realiza mediante una tubería,

desde la cual el proceso de usuario recibe la información que procesará y enviará por socket al

Head DFSU.

El componente de nivel de usuario ofrece también una rica interfaz grá�ca al usuario donde

éste podrá especi�car el alcance de la monitorización del agente.

La interfaz se divide en distintos tabulados donde podemos especi�car el conjunto de procesos

a los que aplicar la monitorización y el destino de la misma, �chero o DFSU remoto.

Por otra parte también es posible seleccionar la extensión de la monitorización, especi�cando

por categorías las llamadas al sistema que serán monitorizadas.

Las diferentes pruebas sobre los sistemas Windows 2000 y Windows XP sp2 arrojan resultados

positivos, mostrando muy poca sobrecarga en el sistema. Sin embargo aún existe algún problema

de compatibilidad no resuelto.

En Windows XP con service pack 2 instalado, es necesario desactivar en registro la protección

268

Figura 3.22: Interfaz de usuario del agente, menús generales.

Figura 3.23: Menú de selección de syscalls hookeadas

269

Figura 3.24: Simpli�cación de la arquitectura de Symbian OS

de memoria con el �n de que el agente pueda modi�car la tabla de llamadas a servicios a nivel

de kernel.

3.2.4. Recogida de información en sistemas Symbian OS.

Para comenzar a explicar las diferentes formas en las que se puede capturar la interacción del

usuario con las aplicaciones y de éstas con el sistema operativo conviene introducir los mecanismos

internos y la arquitectura de funcionamiento de este tipo de terminales móviles. Centrando un

poco más el tema, en la siguiente �gura se hace un resumen de lo que sería la plataforma diseñada

por los desarrolladores de este sistema operativo:

Symbian OS es una arquitectura que toma las bondades de los sistemas monolínitico y los

basados en microkernels, es decir, que integra funcionalidades de ambos. Se dispone de un hilo

en ejecución con la prioridad más alta para todo el sistema que se denomina nanokernel. Éste

hilo supervisor se encarga de tareas como la sincronización y la organización temporal entre los

diferentes procesos que se tienen en ejecución, así mismo desempeña funciones de mantenimiento

y acceso a bajo nivel, proporcionando una interacción que cumpla con los exigentes requisitos de

las pilas de comunicación GSM/GPRS/UMTS, dado que es objetivo fundamental el cumplir los

tiempos y latencias para poder funcionar correctamente con este tipo de redes.

Por otra parte, por encima del nanokernel se tiene la parte denominada núcleo (kernel)

270

propiamente, que se ocupa de tareas más complejas: acceso a objetos más complejos (hilos de

modo usuario, procesos, manipuladores de objetos del sistema, librerías cargadas dinámicamente,

comunicación entre procesos, etc.). A su vez proporciona una sincronización para objetos más

compleja que el nanokernel, si bien a diferencia del anterior, esta parte no puede alojar memoria

dinámicamente. Dado que no ha sido diseñado el kernel para manipulación de memoria del

terminal, esta parte se ha dejado por completo a cargo del modelo de memoria, implementado

como servicio del kernel en vez de estar embebido dentro del código del mismo.

Los semáforos, mutex, y elementos de sincronización que son proporcionados por el nanoker-

nel, son utilizados por el kernel para poder crear hilos de ejecución de procesos sincronizados,

para conseguir comunicar entre sí diferentes procesos y para manipular los diferentes arrays de

manipuladores que integran este sistema operativo.

El modelo de memoria extraído del núcleo en sí mismo, denominado ASIC, se encarga y

encapsula de manipular si una cache (entendida como porción de memoria) va a estar alojada

en espacio virtual o en espacio físico. Proporcionando una serie de accesos diferentes para la

aplicación que lo requiera:

Acceso directo (sin hacer uso de la MMU)

Movimiento entre partes (parecido a como se realizaba en versiones anteriores EKA170)

Acceso múltiple.

Acceso realizado para el emulador de Symbian OS71.

El modelo de memoria proporciona servicios de manipulación de memoria a bajo nivel, como por

ejemplo el mapeo por proceso de su espacio de direcciones, se encarga cuando se le pide del cambio

de contexto adecuado en la sincronización y es parte fundamental para lograr la comunicación

entre procesos del terminal. Así mismo es importante su función a la hora de creación de procesos

haciendo uso del servidor de �cheros del sistema72

70Actualmente se habla mayoritariamente de EKA2, que es la arquitectura de diseño y desarrollo que se estallevando a cabo por los desarrolladores de Symbian OS

71Como se verá más adelante, la arquitectura ha sido desarrollada para dos soportes hardware diferentes. Laprimera es para los propios terminales móviles y la segunda es para facilitiar el desarrollo con pcs ordinarios, deforma que es posible trabajar con este sistema operativo de forma emulada en un ordenador convencional basadoen IA-32 y sistema operativo Windows, GNU/Linux o MacOS.

72Symbian OS confía en la de�nición de servicio para la implementación del kernel. De esta forma ha desarrolladoservidores especializados, como en este caso el servidor de �cheros, de forma que si hay que tocar algo de lamemoria física de archivos, de donde habrá que copiar el código fuente de la aplicación para ponerla en ejecución(los �cheros ejecutables tienen una forma de estructuración parecida al formato PE de Windows, se denominanE32, disponible en http://newlc.com/El-formato-de-los-�cheros.html), se encargue de forma única este servidor.

271

Figura 3.25: Formato interno de los �cheros ejecutables y librerías para Symbian OS

Como se ha indicado anteriormente, este tipo de terminales requieren de funcionalidades

especí�cas para poder trabajar con la red de GSM/GPRS/UMTS, por lo que disponen de dos

procesadores arquitecturalmente hablando. Uno se hace cargo de mantener operativo el sistema

operativo funcionando, mientras que el otro se encarga de realizar las operaciones que se requieran

para las transaciones dentro de la red de comunicaciones correspondientes.

Figura 3.26: Modelo simpli�cado de la arquitectura de procesadores de un terminal Symbian OS

Ya entrando a nivel de software desarrollable se encuentran los drivers de dispositivo, su

función es la de controlar los diferentes periféricos de los que dispone el sistema. Estos �drivers�

proporcionan la interfaz requerida entre esos periféricos y el resto del sistema Symbian OS. Más

adelante se volverá sobre este tema, con los drivers LDD y PDD. Así mismo más adelante se

explicara junto con los drivers un subconjunto de los mismos, denominado Extensiones, que son

aquellos drivers que se cargan nada más arrancar el mismo (bootstrap process). Estós últimos se

emplean generalmente para inicializar los dispositivos pero han sido usados para otras funciones

272

menos agraciadas73

Otra pieza clave es la librería que hace de nexo entre el ejecutivo (núcleo o kernel) y los

procesos o aplicaciones de zona de usuario. Esta librería se denomina EUSER.DLL y proporciona

los siguientes servicios:

Ejecución de métodos que enteramente se quedan en la zona de usuario. Como pueden ser

la manipulacion de cadenas de texto74.

Acceso a las funciones del kernel que sean requeridas por un proceso. Estas operaciones

son privilegiadas, es decir, que un proceso o aplicación no puede hacer uso de las mismas

directamente.

Acceso a funciones que le indiquen al kernel que debe modi�car su propia memoria, como

pueden ser las de manipulación de hilos, creación de procesos o carga de una librería.

Para dar por concluida esta primera fase de aproximación al conocimiento de este sistema opera-

tivo se presenta a continuación una imagen indicativa de las diferentes capas que tiene el kernel:

Figura 3.27: Capas del núcleo de Symbian OS

Otra parte importante son las librerías cargadas dinámicamente (DLL), el núcleo crea un

objeto de librería para cada DLL que se cargue explícitamente en un proceso de usuario, esto

implica que los estos objetos son especí�cos y pertenecen exclusivamente al proceso para el que

73El virus Cabir, o Caribe, y sus diferentes versiones, si bien no llegan a infectar el terminal propiamente.No llegan a cambiar el código fuente o el de ejecución de las aplicaciones. Se valen de este tipo de drivers paralanzar un proceso o aplicación durante el arranque del terminal. Este proceso es quien se encarga de escanear porBluetooth (una tecnología de comunicación inalámbrica) y enviar una copia del propio virus. Ha sido la voz dealarma para las entidades y organizaciones antivirales de la necesidad de introducir productos para los terminalesmóviles Symbian OS.

74En Symbian OS las cadenas de texto o strings de otros lenguajes se de�nen como Descriptores y se disponede una serie de Macros que implementa la librería EUSER.DLL para trabajar con ellos convenientemente.

273

fueron creados hasta el punto de que si dos procesos comparten la misma librería, el núcleo realiza

dos objetos para representarla diferentes.

Llamadas al sistema en Symbian OS

En Symbian las llamadas al sistema se denominan Executive Call75 y son el mecanismo pro-

porcionado por el núcleo al código de zona de usuario para dar acceso al mismo a sus servicios.

Estas llamadas ejecutivas empiezan como una función en zona de usuario y después se sirven de

una excepción76 como puerta de enlace para permitirles solicitar código de modo kernel. En la

implementación hardware de los terminales móviles con Symbian OS, generalmente una interrup-

ción se activa mediante una instrucción SWI y esta en la arquitectura ARM solo se dispone de

una para pasar a modo privilegiado. Por este motivo se usa un repartidor en el nanokernel para

decodi�car un parámetro pasado desde zona de usuario (opcode) en la instrucción SWI y con él

poder determinar la función a la que tiene que llamar el repartidor (dispatcher). Este mecanismo

de llamadas da como resultado un bajo acoplamiento entre el kernel y los procesos de usuario,

con lo que se pueden realizar cambios en la implementación o en el diseño de ambas partes sin

afectar al resto del sistema operativo de forma sencilla.

El �ujo de ejecución de una executive call esta re�ejado en la �gura:

Figura 3.28: Llamada ejecutiva al kernel de Symbian OS

Si se asume que se ha producido una llamada desde un hilo en ejecución en espacio de usuario

75Llamada ejecutiva o llamada al ejecutivo, conocido también como el núcleo o el kernel.76En otros sistemas operativos esto se conoce como la interrupción de solicitud. En el kernel de Linux se hace uso

de la interrupción int80h y en MS-Dos/Windows de la int20h. El tratamiento de excepciones y de interrupcionesfunciona de maneja semejante en las arquitecturas ARM, PPC o IA-32/64.

274

como la siguiente, en la que se pide una porción de memoria compartida:

Figura 3.29: Código fuente en el que se realiza la llamada para reservar una porción de memoria

El fragmento de código anterior solicita la creación de una porción de memoria y almacena el

manipulador que se le devuelve para poder referenciar a este espacio. Lo siguiente es encontrar

la dirección base del espacio que se consigue mediante el método �RChunk::Base()�, un método

que se encuentra de�nido dentro de la librería de usuario EUSER.DLL. El paso 2 se realiza

dentro de la propia librería aparte de realizar una serie de funciones para realizar la función

solicitada acaba con una interrupción: SWI EExecChunkBase, donde EExecChunkBase es el

opcode necesario para el kernel. En el paso 3 ya interviene el dispatcher del nanokernel y dado

que esto es una llamada rápida (más adelante se volverá sobre este tipo de llamadas) se busca

en una tabla de parejas de entradas de 32 bits que referencian a la llamada que se ha de realizar.

Finalmente tras procesar el paso 3 dentro del nanokernel se requiere hacer uso de otra parte del

núcleo al margen del propio dispatcher quien se encargará de realizara las operaciones necesarias

para la solicitud del proceso en zona de usuario (pasos 4 y 5).

Denotar que las llamadas ejecutivas se realizan en el espacio y contexto del hilo que las

solicita, lo que implica que no se ha salido del espacio de memoria del proceso en cuestión, con lo

que no es posible machacar zonas de memoria de otros procesos haciendo uso de este mecanismo.

Si bien es posible que una vez llegado a código de kernel privilegiado poder solicitar el acceso

a memoria del sistema en general, aunque para ello se requiere realizar una modi�cación de la

información contenida en ROM del terminal móvil, solución bastante compleja para realizar una

infección vírica.

Ahora se va a comentar las diferencias y la forma de funcionamiento de las llamadas ejecutivas

rápidas y las lentas:

Slow executive calls

Estas llamadas se ejecutan con las interrupciones habilitadas y con el kernel desbloqueado, lo

que implica que pueden ser interrumpidas y cambiadas de orden en la ejecución por motivos

de sincronización o solicitudes más urgentes (preemptive system calls). Estas llamadas solicitan

un bloqueo del sistema rápido antes de llamar al manipulador que requieran para realizar sus

operaciones y posteriormente lo liberan para pasar a llamar al manipulador obtenido, después de

esto solicitan al manipulador que haga la tarea que se requiere, pero entran dentro de la tónica

del sistema apropiativo y sincronizable por lo que pueden pasar a segundo plano y tener que

cambiar de contexto de mientras otra solicitud más importante es atendida.

275

Fast executive calls

Las llamadas ejecutivas rápidas al contrario que las anteriores se ejecutan con las interrupciones

deshabilitadas, por lo que deben de ser muy cortas y requerir muy poco tiempo en ejecutarse. Así

mismo no hay muchas de este tipo de llamadas y suelen ser usadas para cosas muy puntuales que

se realicen de forma rápida y efectiva. Las llamadas ejecutivas lentas pueden contener hasta 11

parámetros asociados, en cambio estas llamadas rápidas solo pueden tener asociado un parámetro

de 32bits y sólo devuelven otro valor de 32bits.

Seguridad de instrumentación binaria en Symbian OS

La seguridad dentro del sistema corre a cargo dentro de lo que se denomina una �Capability�,

que no es más que una autorización que indica si el dueño ha con�ado para poder acceder a los

recursos protegidos por la cadena de texto asociada. Este token de autorización puede dar acceso

a API's internas muy sensibles como a los drivers de dispositivos o a datos como la con�guración

del terminal.Los diseñadores han creado una serie de reglas entre lo que se permite hacer y lo

que no dentro del sistema operativo:

Cada proceso tiene un conjunto de tokens, �capabilities�, y éstas no cambian durante toda

su vida

Cuando se desarrolla un programa ejecutable, se tiene que crear un �chero con extensión .MMP

que es el denominado �chero de proyecto. Adicionalmente se requiere actualmente de una línea

extra que de�na las capacidades que se le deberán otorgar a un determinado ejecutable. Tanto

los ejecutables .EXE, como las librerías .DLL tienen sus características de�nidas de esa forma.

Estas capacidades son leídas y escritas en disco durante el proceso de instalación y permanecerán

inalterables desde ese momento, incluso durante la carga se almacenan en memoria en sitios

diferentes y no accesibles desde el programa en ejecución. Se pueden consultar, pero no modi�car.

Un proceso no puede cargar una librería DLL que tenga un conjunto menor de capacidades

que él mismo

Una librería DLL no puede linkarse estáticamente con otra DLL que tenga un conjunto

menor de capacidades de�nido.

Otra parte interesante en el orden de la seguridad interna del sistema operativo es el tratamiento

de la parte de Servidores/Clientes. Como se ha comentado, Symbian incorpora un particionado

especializado de funciones y funcionalidades para tener un bajo acoplamiento dentro del código.

Un servidor, por ejemplo de �cheros o de sockets o de telefonía, siempre comprueba y pregunta a

sus posibles clientes a ver si tienen las capacidades adecuadas para poder solicitarle la realización

de una determinada tarea.

276

Drivers de dispositivo y Extensiones

El papel de los drivers de dispositivo es dotar al código de zona usuario acceso a los recursos

periféricos del hardware sin exponer la operación de acceso al mismo al código de usuario y

volver al dispositivo inestable. Generalmente en todo sistema operativo restringe al modo de

supervisión el acceso a los recursos hardware, con lo que el acceso desde el código usuario a un

driver plantea la misma barrera que entre código de núcleo privilegiado y código en ejecución de

las aplicaciones de usuario. Los drivers son cargados dinámicamente por el kernel y se alojan en

el proceso del kernel después del arranque del sistema.

La arquitectura de drivers en Symbian OS se distribuye en dos capas: lógica y física, como

se indica en la �gura:

Figura 3.30: Arquitectura de los drivers de dispositivo simpli�cada

Los drivers de dispositivo lógicos, LDD, contienen la funcionalidad de una serie de dispositivos

y son los que se comunican con el código de usuario mediante una interfaz simple que de�ne una

API concreta. Este tipo de drivers de�nen una serie de funcionalidades genéricas y se valen de

los drivers físicos, PDD para realizar el acceso al hardware en la manera apropiada. Los PDD

controlan por lo general un dispositivo periférico en particular y por norma sólo se comunican

directamente con otro driver LDD o con una extensión.

Las Extensiones del kernel, no dejan de ser drivers también, con la salvedad de que son car-

gados en el sistema en el momento del arranque del mismo y usualmente son muy especializados

para poder inicializar los diferentes recursos convenientemente.

277

Debug en zona de núcleo (Kernel)

La arquitectura de los terminales móviles actuales basados en Symbian (Symbian S60 3a

generación), basada en EKA2 ha sido diseñada para admitir debugger remotos a nivel de kernel.

Estos debuggeos del núcleo se pueden producir de las siguientes formas:

Debuggers para Emulador. Solución aceptada e implementada en el presente proyecto para

acceder a las trazas del sistema.

La solución empleada para poder acceder a las trazas del sistema ha sido esta debido a la

simplicidad de trabajar con emuladores y al hecho de poder tener acceso físico a los mismos,

pudiendo modi�carlos y adaptarlos convenientemente para la integración de los mismos en la

infraestructura. La operación realizada se basa en cambiar la librería EUSER.DLL, a la que todas

las aplicaciones hacen referencia en su funcionamiento para poder solicitar tareas avanzadas,

por otra librería modi�cada que permitiera realizar la captura y envío de los datos necesarios.

La práctica que se ha llevado a cabo se puede aplicar en los móviles comerciales mediante la

actualización del software y modi�cación de este fragmento de código que reside en la ROM77

del dispositivo.

Para el desarrollo de la intercepción de llamadas al sistema se ha hecho uso del proyecto

HookLogger78, que modi�cado ha dado pie a poder observar la forma de trabajo existente en la

presente memoria.

Figura 3.31: Selección de hilos en ejecución a interceptar

77ROM, Read Only Memory. Memoria que contiene el kernel, los drivers y las librerías del sistema operativo,que no permite ser escrita o modi�cada salvo con el hardware apropiado.

78Disponible en la dirección o�cial http://developer.symbian.com/main/tools/devtools/code/index.jsp, secciónde herramientas de desarrolladores de SymbianOS

278

Figura 3.32: Volcado de la memoria y de las peticiones que se realizan a la librería

Figura 3.33: Detalles de un hilo en ejecución

Debuggers de aplicaciones en tiempo real. Ideal para el desarrollo e implantación de apli-

caciones.

Los debuggers en tiempo real permiten que una aplicación que se encuentre en ejecución en un

terminal móvil Symbian OS pueda ser monitorizada y controlada en base a excepciones (para

poder introducir los breakpoints o puntos de ruptura) desde un PC remoto. La arquitectura de

este tipo de sistemas es la que sigue:

279

Figura 3.34: Run-Mode Debugger

Debuggers con opción de parada y congelación del sistema operativo. Se usan para el

desarrollo de Drivers de Dispositivo o otro software relacionado con el desarrollo del núcleo

3.3. Cuestiones arquitectónicas

Antes de entrar de pleno con DFSU es necesario que todos hablemos o al menos entendamos

el mismo lenguaje, para ello comenzaremos con un repaso al estado del arte en los sistemas de

detección de intrusiones. Tras la lectura de este capítulo el lector deberá comprender qué es un

sistema de detección de intrusiones, cuales son sus principales variantes así como cuáles son las

principales ventajas y desventajas de cada uno.

3.3.1. Riesgo tecnológico, un problema en alza.

Irónicamente, al tiempo que las nuevas tecnologías se vuelven más complejas, al tiempo que

se vuelven más rápidas, más accesibles, se vuelven también más vulnerables. Esta a�rmación a

priori contradictoria cobra sentido al desglosar los factores que componen el Riesgo tecnológico

(RT):

RT = NA∗IE∗CAST

Figura 3.35: Ecuación del riesgo tecnológico

RT

La variable RT (Riesgo Tecnológico) pretende dar un aproximación cuantitativa de la amenaza

a la que se enfrentan nuestros sistemas informáticos.

NA

280

La variable NA (Número de Ataques) representa el número de ataques que sufren nuestros

sistemas, independientemente de si estos tienen éxito o no.

IE

Por supuesto la variable NA no tendría ningún fundamento sin IE (Indice de Éxito) de estos

ataques.

CA

La variable CA (Consecuencias del Ataque) representa cuales son los daños (en términos

económicos) del éxito de un hipotético ataque.

ST

La variable ST (Seguridad Teórica) representa cual es el grado de seguridad de nuestros

sistemas, ¾actualizamos nuestro software? ¾usamos cifrado? ¾claves de seguras? etc...

Si bien es cierto que nuestras medidas de seguridad teórica han mejorado notablemente,

gracias sobre todo a la expansión de las técnicas criptográ�cas y a la seguridad perimetral, la

delegación progresiva de responsabilidades hacia los sistemas informáticos hace que el papel de

estos sea cada día más importante, aumentando inevitablemente las repercusiones de un posible

ataque.

Si el Riesgo Tecnológico dependiese exclusivamente de estos dos factores (CA y ST), es posible

que hubiera podido controlarse gracias a las mejoras en Seguridad Teórica, lamentablemente la

balanza ha sido brutalmente descompensada por una explosión sin precedentes en el número de

ataques79

En todo sistema incipiente sea este: Social, Cultural, Económico o ½como no! Informático,

se produce una evolución a través del uso. Al igual que los caminos de la España del siglo XV

estaban infestados de rateros peligrosos, las autopistas de la información del siglo XXI están

plagadas de malhechores no menos desdeñables. Los técnicos y legisladores del siglo XXI deben

desarrollar técnicas capaces de limpiar Internet de la lacra que nos asola, sin embargo deben

hacerlo empleando juego limpio, es decir mejorando la seguridad teórica y no restringiendo sus

fantásticas capacidades y virtudes.

79Una de las razones del aumento en el número de ataques está en los virus informáticos. Los worms de hoyincorporan rutinas no sólo para replicarse y propagarse sino también para explotar vulnerabilidades conocidas,de este modo muchos de los sistemas que antes pasaban desapercibidos por no ser de especial interés para unatacante humano son ahora los más afectados .

281

3.3.2. Introducción

En la tarde del Miércoles 2 de noviembre de 1988 ordenadores de puntos vitales de los

Estados Unidos, como la NASA, el Pentágono, el Instituto Tecnológico de Massachusetts, las

Universidades de Berkeley, Stanford, Princeton, etcétera, de una costa a otra, de ARPANET a

MILNET, fueron cayendo uno tras otro, víctimas del �gusano� de Robert Morris.

Se habló entonces de millones de dólares en pérdidas y de un diez por ciento de Internet

colapsado. Tal fue la repercusión de ese primer gran ataque que tan solo una semana después,

con el gusano en cuestión aún en plena actividad, la Agencia de Proyectos de Investigación

Avanzada del Departamento de Defensa [DARPA] de los EEUU decidió fundar, en colaboración

con la Universidad Carnegie Mellon, el que sería el primer Centro de Respuesta ante Emergencias

Informáticas [CERT]; centro que posteriormente iría extendiéndose a un gran número de países,

entre ellos España [esCERT e IrisCERT].

Desde entonces hasta hoy los sistemas de seguridad informática han evolucionado enorme-

mente y en muchas direcciones. Sin embargo, el hecho de que no exista una solución uni�cada,

que contemple el problema de forma global, es un síntoma de que dicho problema dista aún de

resolverse. Sin ir mas lejos, estos días Internet sigue convulsa tras ataques como el del gusano

Blaster y sus sucesivas variantes, con unas pérdidas económicas aún por cuanti�car.

Tradicionalmente, la seguridad informática se ha fundamentado en los denominados meca-

nismos de control de acceso, de forma que el objetivo que se ha perseguido siempre ha sido el de

poder identi�car a los usuarios que acceden al sistema, para así poder concederle o restringirle

el acceso a determinados recursos.

Si suponemos que nuestro sistema es una �nca, este control de acceso podría realizarse po-

niendo unos buenos barrotes en las ventanas, reforzando las cerraduras y teniendo un exquisito

cuidado con quien recibe una copia de la llave para entrar. Además, sería una buena idea colocar

en el perímetro de la �nca una verja electri�cada, para de este modo extender el área de segu-

ridad más allá incluso de la puerta de entrada. Lejos de ser una simple metáfora, está es una

práctica que se sigue en el mundo de la informática casi al pie de la letra, esta es la idea con la

que se diseñaron los �rewall o cortafuegos.

Sin embargo, no sólo evolucionan los mecanismos de defensa, también lo hacen las técnicas

de ataque y lo hacen hasta tal punto, que hoy en día los mecanismos de seguridad perimetral

(�rewalls) son una medida necesaria pero claramente insu�ciente. Resumiendo: Una muralla cada

vez más gruesa siempre ha recibido el saludo de un cañón cada vez más potente.

Existe además una creencia generalizada (probablemente por llevar este tipo de paralelismos

con la vida real demasiado lejos) de que los ataques deben llegar siempre desde el exterior, nada

más lejos, gran parte de los ataques a lo que se enfrenta una red provienen precisamente desde su

interior. Empleados descontentos u ordenadores portátiles infectados, suelen ser las principales

fuentes. Salta a la vista que necesitamos un mecanismo automatizado para poder detectar a los

intrusos que ya han conseguido vulnerar el perímetro de seguridad. Aquí es donde entran las

282

técnicas de detección de intrusiones.

Figura 3.36: Seguridad Perimetral (Firewall)

3.3.3. Detección de intrusiones

Un Sistema de Detección de Intrusos (IDS80) trata de detectar (y prevenir81) toda aquella

actividad subversiva que se desarrolla en el perímetro de nuestro sistema o que ya está dentro de

nuestra red. Una de las primeras referencias que podemos encontrar en el campo de la detección

de intrusos es el, ya un clásico, artículo de Dorothy E. Denning �An Intrusion Detection Model�,

de 1987 [EDENNING01]. Este artículo recoge desde un punto de vista conceptual gran parte de

las estrategias de detección más utilizadas en el momento. En él se establece por primera vez una

clasi�cación de los IDS que llega hasta nuestros días, por un lado el Reconocimiento de patrones

de uso indebido y por otro la Detección de anomalías.

A pesar del peso histórico de escte artículo, utilizaremos otra clasi�cación más acorde con

los tiempos extraída de la obra �Sistemas de Detección de Intrusiones� por Diego González

[DGONZALEZ01]. Este autor establece tres fases generales de funcionamiento para cualquier

IDS, y los clasi�ca según las técnicas empleadas en cada una de estas fases.

Como puede verse en la �gura 3.37, la actividad del IDS se divide en 3 pasos:

1. Recogida de información: Capturar la información que posteriormente analizaremos.

2. Análisis: Dónde procesamos esta información.

3. Respuesta: Una vez el sistema he determinado si la información recogida compone una

amenaza o no deberemos tomar las medidas oportunas.

80IDS, acrónimo de Intrusion Detection System81Últimamente los IDSs están evolucionando hacia los IPS (Intrusion Prevention System) donde se trata de

detectar la intrusión antes de que se produzca algún ataque.

283

Figura 3.37: Etapas en el proceso de detección

Taxonomía en base al método de recogida de información

Atendiendo a la fuente de la que los IDS's extraen la información, podemos establecer dos

categorías. Por un lado los IDS's basados es host (HIDS82) y por otro los IDS's basados en red

(NIDS83).

IDS's Basados en Máquina (HIDS) Su funcionamiento en similar al de un antivirus en

el sentido en que el IDS se ejecuta como proceso local a la máquina que se desea vigilar. Este

proceso permanece habitualmente en estado dormido y en base a una serie de condiciones de

activación despierta para chequear si el estado del sistema es seguro o no. Determinar el estado

del sistema no es tarea fácil y su análisis debe afrontarse como si de una gran ecuación se tratara.

Esta ecuación debe tratarse con el mayor de los cuidados pues el más ligero cambio en cualquiera

de las variables puede signi�car que el sistema a pasado de un estado seguro a uno inseguro o

viceversa.

82HIDS, acrónimo de Host based Intrusion Detection System83NIDS, acrónimo de Network based Intrusion Detection System

284

A pesar de que todos los HIDS se ejecutan en la máquina a proteger, no todos ellos extraen

sus variables de los mismos puntos. A continuación se describen vagamente los enfoques más

comunes:

Llamadas al Sistema: Los sistemas operativos ofrecen un conjunto de interrupciones que

pueden ser llamadas por las aplicaciones de usuario para invocar un servicio proporcionado

por éste. Cada uno de estos servicios se llama syscall o llamada al sistema, un ejemplo de

syscall sería abrir un �chero. Dependiendo de la complejidad del programa de usuario el

número de syscalls puede variar entre unas pocas en programas muy sencillos hasta miles o

decenas de miles en programas complejos. Al conjunto de syscalls que ejecuta un programa

se le llama traza y nos da una idea bastante precisa de su comportamiento.

Registros de Auditoría: El Sistema Operativo, así como muchas de las aplicaciones de

usuario en ejecución sobre la máquina, mantienen una estricta contabilidad de todo lo que

está sucediendo84. Esta información tradicionalmente se exporta en el caso del sistema

operativo a través de los dispositivos ubicados en /proc/85 y en el caso de los programas de

usuario a través de �cheros de log. Por su sencillez y facilidad de acceso no es de extrañar

que esta fuese una de las fuentes de información más empleadas en los primeros IDS.

Veri�caciones de integridad: Dentro del área de conocimiento de la Detección de In-

trusiones orientada a la Máquina, Gene Kim y Eugene Spa�ord introdujeron, (1994), en

su artículo The Design and Implementation of Tripwire: A File System Integrity Checker

[TRIPWIRE01], el concepto de Veri�cación de Integridad, también conocido como Detecci

ón de Intrusiones orientada a Objetivos86. En dicho artículo, los autores proponían un Sis-

tema de Detección de Intrusiones que aplicaba técnicas criptográ�cas de cifrado irreversible

empleando para ello funciones resumen, con unas propiedades muy características:

• La entrada del �chero debe poder se de tamaño indeterminado.

• El resultado resumen debe ser de tamaño �jo, como es lógico varios órdenes de mag-

nitud más pequeño que la entrada.

• Dado x, calcular H(x) es en términos computacionales barato.

• H(x) es de un solo sentido, es decir no tiene función inversa.

• H(x) no debe presentar colisiones.

El objetivo perseguido por esta técnica es garantizar la integridad de aquellos recursos

críticos del sistema a proteger. De esta forma, aparecía una nueva tipología de sistema de

84Esta información se suele emplear para generar per�les de rendimiento o para análisis forense en caso de queel sistema haya sido comprometido.

85El empleo de dispositivos /proc es común en los sistemas Unix like, otros sistemas como por ejemplo Windowsutilizan otros métodos.

86Detección de Intrusiones orientada a Objetivos o Target-based Intrusion Detection.

285

detección que, si bien mantenía claramente su orientación a la máquina, dejaba de utilizar

información proveniente de los registros de auditoría de sistemas operativos y servicios de

aplicación, y pasaba a utilizar sus propios registros.

/newpage

Conclusiones HIDS A continuación se detallan las principales ventajas e inconvenientes de

los HIDS:Puesto que se ejecutan en la máquina a proteger tienen acceso a un abanico de

variables mucho más rico que el trá�co de red (syscalls, auditoría de �cheros etc...)

Tienen además acceso al contenido de las conexiones cifradas por estar en uno de los

extremos del trá�co.

Por otro lado, las labores de administración son mucho más costosas ya que deberá

con�gurarse cada ordenador a proteger.

Por muy bien que esté programado el HIDS, los fallos de seguridad existen, de

manera que irónicamente el mecanismo de protección pudiera convertirse en la puerta

de acceso para posibles ataques.

Toda la carga del proceso de detección se lleva a cabo en la propia máquina por lo

que el HIDS degrada el rendimiento de la máquina donde se instala.

IDS's Basados en Red (NIDS) Este es el enfoque utilizado por la mayor parte de los IDS's

modernos que emplean la información capturada a través de sni�ers87 en diferentes segmentos de

la red del sistema para detectar posibles ataques. De este modo, un solo NIDS puede monitorizar

el trá�co de toda una subred, protegiendo así varias máquinas simultáneamente.

A menudo una implementación real de un NIDS corporativo se compone no de uno, sino de

varios NIDS distribuidos en las distintas subredes, cada uno de ellos funcionado por separado en

su segmento de red. Así es precisamente como funciona Snort88.

Figura 3.38: Logotipo de Snort

87Un packet sni�er es un programa de captura de las tramas de red .Generalmente se usa para gestionar la redcon una �nalidad docente, aunque también puede ser utilizado con �nes maliciosos [WIKI03]

88Snort es el estándar de facto de los NIDS. Snort (http://www.snort.org) está disponible bajo licencia GPL,gratuito y funciona bajo plataformas Windows y Unix like.

286

Es habitual que los NIDS sean máquinas dedicadas exclusivamente a la detección de intrusio-

nes, lo que por regla general los hace menos vulnerables89, además no es extraño llegar al extremo

de no asignar IP al interfaz dedicado a la captura de paquetes, de este modo se evita que alguien

pueda direccionar ataques contra él e incluso utilizar cables de solo recepción o network taps,

evitando así que el equipo NIDS pueda ser visto por un hipotético atacante.

89Esta a�rmación a priori un tanto categórica se fundamenta en que en los sistemas muy especí�cos el númerode servicios suele ser muy reducido, un número de servicios reducido reduce a su vez las posibles puertas de accesoa ese sistema. Esto lo hace más seguro.

287

A cada uno de los elementos de información que un IDS puede emplear para discernir si el

trá�co que está analizando es o no un ataque se le llama métrica. Podemos clasi�car las métricas

de red en dos subtipos [BYKOVA01]:

Información de cabecera: El trá�co de red va encapsulado dentro de las cabeceras

del protocolo que se esté utilizando. Como puede verse en la Figura 5: Cabecera IP esta

información se caracteriza por ser discreta90 y fácilmente extraíble ya que cada campo tiene

una longitud �ja91 y está siempre en el mismo sitio. Los siguientes son ejemplos de métricas

extraídas de las cabeceras del protocolo:

• Direcciones IP origen y destino: Las direcciones de la máquina origen y de la

máquina destino son datos interesantes, tanto porque pueden ser empleados defensi-

vamente en las medidas de control de acceso, como porque pueden llegar ser utilizadas

ofensivamente en denegaciones de servicio rudimentarias contra nuestro sistema. Su-

pongamos por ejemplo que uno de nuestros servidores recibe un mensaje ICMP de

ping92. Así pues, si el mensaje ha sido manipulado de forma que su dirección de origen

ha sido sustituida por la de destino, cuando nuestro servidor reciba dicho mensaje, en

lugar de responder al verdadero remitente se responderá a sí mismo inde�nidamente93.

• Puertos origen y destino: Los puertos de origen y destino, son un excelente indi-

cativo de actividades sospechosas, tanto para detectar barridos de puertos, como para

descubrir la presencia de servidores no autorizados en nuestra red (troyanos94).

• Flags TCP: Uno de los campos de la cabecera TCP, el de �ags, contiene una se-

rie de bits (URG, ACK, RST, SYN y FIN), por supuesto necesarios para el buen

funcionamiento del protocolo, pero que tradicionalmente se han modi�cado con otras

intenciones. Por ejemplo, para solicitar la conexión a un servidor, se activa el bit SYN,

mientras que el bit FIN hace justo lo contrario. Por sí solos no son especialmente sig-

ni�cativos, pero ¾no sería sospechoso que un mensaje llevase ambos bits activados?

Tampoco hay que olvidar que uno de los mayores problemas conocidos sobre plata-

formas Windows se fundamentaba en el manejo de paquetes OOB (Out of Band),

tramas con el bit URG activado [OOBATTACK01].

Carga útil:95 La información de cabecera es un añadido que los protocolos de comunica-

ciones deben agregar a sus transmisiones para que estas lleguen a su destino, sin embargo90Hay un número �nito de posibles valores91Tal vez sería más apropiado explicar que la longitud del campo no siempre tiene por que se �ja (casi siempre

lo es) sino que puede precalcularse cuanto va a ocupar. Esto sucede con el campo opciones de la cabecera IP.92Un ping es un mensaje con el que el emisor trata de averiguar si el receptor está activo, de forma que si es

así, éste devuelve un mensaje de echo.93Estos son los llamados ataques chargen94Programa malicioso capaz de alojarse en computadoras y permitir el acceso a usuarios externos, a través de

una red local o de Internet, con el �n de recabar información y/o controlar remotamente la máquina �huésped�.95También llamada payload.

288

lo que realmente le interesa al otro extremo es el contenido de la transmisión, la carga útil.

El problema del payload es que es generado en la capa de aplicación y cada aplicación tiene

su propio formato a la hora de organizar los datos del envío. Esto unido a que no existe un

modo �able96 de determinar a que aplicación de usuario pertenece un determinado paquete,

hacen que la extracción de información del payload sea muy costosa.

Figura 3.39: Cabecera IP

96Los puertos origen y destino podrían emplearse para identi�car protocolos de aplicación conocidos. El pro-blema es que no es un dato �able ya que estos puertos pueden cambiar según las con�guraciones.

289

Conclusiones NIDS Al igual que los HIDS, losNIDs también tienen sus ventajas e inconve-

nientes:Un solo NIDS bien situado puede cubrir las necesidades de un gran número de

ordenadores

El NIDS es transparente para los usuarios �nales y siendo su administración

centralizada, los esfuerzos de los administradores de red son mínimos.

Pueden llegar a perder paquetes si el volumen de trá�co en la red es muy elevado.

Los NIDS en principio no tienen acceso al payload de las conexiones cifradas

Un NIDS sabe si que ha tenido lugar un ataque, pero no sabe si ese ataque ha tenido

éxito o no, ni tampoco cual ha sido su impacto.

Taxonomía en base al método de análisis empleado

Atendiendo a que técnicas emplea el IDS para determinar, si las variables de control recogidas

representan o no un ataque, podemos distinguir principalmente dos corrientes. Por una lado los

sistemas de detección de usos indebidos y por otro los sistemas de detección de anomalías.

Reconocimiento de patrones de uso indebido Este método trata de modelar todo el

conocimiento que los expertos de seguridad han adquirido a lo largo del tiempo, para de este

modo construir una lista negra de todas las actividades que pueden constituir un ataque. Su

utilidad es inmediata ya que el IDS sólo tiene que comparar el estado actual del sistema con

todos y cada uno de los estados recogidos dentro de la lista negra, si coincide con alguno de ellos

entonces es que se ha producido un ataque, de lo contrario el sistema está seguro.

Una de�nición sin duda más elegante es la propuesta por Rebecca Bace y Peter Mell:

Detection method that analyzes system activity, looking for events or sets of events that match aprede�ned pattern of events that describe a known attack.

Figura 3.40: De�nición de patrones de uso indebido

Salta a la vista que este sistema tiene un fallo de base y es que aunque seamos capaces de

modelar todos y cada uno de los ataques existentes, algo por otra parte extraordinariamente

difícil, a medida que el tiempo vaya pasando surgirán nuevos ataques y poco a poco la lista irá

quedándose obsoleta.

/newpage

A pesar de sus claras limitaciones este sistema es muy popular, sobre todo por que cumple

perfectamente con su misión y por ser muy sencillo de comprender. A día de hoy este es el método

más empleado por los IDS modernos. A continuación se detallan sus variantes más conocidas:

Reconocimiento estático de patrones: Esta técnica representa la forma más simple

de detectar malos usos. Normalmente se basa en sistemas que buscan mediante un reco-

nocimiento de patrones relativamente simple cadenas o subcadenas dentro de las distintas

290

entradas. Si encuentran una determinada cadena binaria, entonces es que se ha detectado

un ataque.

Basada en probabilidades condicionales: El reconocimiento estático de patrones de-

tecta una intrusión cuando cuando encuentra una determinada �rma (característica), pero

esto no es del todo correcto, algunas �rmas no re�eje siempre un ataque. La aproximación

basada en probabilidad condicional trata de determinar la probabilidad condicional de que

una intrusión ocurra dada una cierta �rma, para calcular esta probabilidad necesita datos

de intrusiones anteriores, por ejemplo, de logs de auditoría, eventos etc...

Basadas en análisis de transición de estados: Esta aproximación representa las intru-

siones como una secuencia de transición de estados del sistema objetivo [PORRAS01]. Los

estados sucesivos se conectan mediante arcos que representan los eventos necesarios para

el cambio de estado. Cualquiera de los estados por separado no tiene por que constituir un

ataque en sí mismo, sin embargo la transición de un estado a otro sí puede constituirlo.

Detección basada en modelos: Esta técnica combina modelos usos indebidos con el

razonamiento en base a evidencias. En este modelo, existe una base de datos con escenarios

de intrusiones formados por una secuencia de acciones que re�ejan el comportamiento de

una intrusión. En un momento dado un subconjunto de escenarios de ataque se considera

como escenario parecido. El IDS trata entonces de argumentar o rebatir los escenarios

dados en un �chero de auditoría. El cálculo del razonamiento evidencial construido en el

sistema permite actualizar la probabilidad de la ocurrencia de los escenarios de ataque en

una lista de modelos activos.

Figura 3.41: Esquema de funcionamiento; Modelo de usos indebidos

291

Conclusiones reconocimiento de patrones de uso indebido

Los patrones de uso indebido son sencillos de implementar y de usar, tienen un índice de error

muy bajo, pero están limitados por su escasa �exibilidad ante nuevos ataques. A continuación

se detallan sus principales ventajas e inconvenientes.

Es un sistema sencillo y de probada solvencia.

Al no requerir muchos cálculos los sistemas resultantes suelen tener un buen

rendimiento.

Están limitados en el sentido en que únicamente pueden detectar ataques conocidos

de previamente.

Detección de anomalías Como respuesta a las carencias del sistema anterior surge una nueva

�losofía de detección, fundamentándose ésta en una transgresora de�nición de ataque.

Una intrusión es una anomalía. Conozco lo que es 'normal' en mi sistema, para poder detectarlo que no lo es (anomalías)

Figura 3.42: Ataque según la �losofía de detección de anomalías

Tal y como puede verse en la De�nición 2: Ataque según la �losofía de detección de anomalías,

la base del funcionamiento de estos sistemas se basa en la suposición de que el per�l de actividades

desarrollado durante una intrusión se desvía sensiblemente con respecto al per�l de uso que un

usuario normal hace del sistema [CHEUK01]. De modo que el proceso de detección pasa por ser

capaz de modelar un per�l del comportamiento normal del sistema para poder así identi�car

cualquier desviación excesiva de ese per�l como anómala y por tanto subversiva. A la hora de

determinar lo que es normal en el sistema, existen dos grandes aproximaciones [ROLAND01].

Por un lado están los sistemas capaces de aprender por sí mismos lo que es normal y lo que no,

para ello emplean técnicas estadísticas97 sobre variables como por ejemplo el número de procesos

en ejecución o el trá�co de la red en un determinado instante y por otro los sistemas que en lugar

de aprender por sí mismos emplean conocimiento experto codi�cado en forma de reglas estáticas.

El primero de los problemas a los que deberá enfrentarse este modelo consiste en determinar

cuales son las variables más relevantes a la hora de de�nir un comportamiento normal. En

[HAROLD01] se proponer diferentes tipos de datos que pueden resultar útiles a la hora de

realizar la selección:

Variables de intensidad de actividad: El sistema mide los valores numéricos asociado

a una actividad98 a lo largo del pequeños intervalos de tiempo, de este modo obtiene de

97Estas técnicas pueden variar desde lo más sencillo (medias, desviaciones, varianzas) hasta técnicas extrema-damente so�sticadas de aprendizaje automático (redes neuronales, redes bayesianas etc...)

98Entendemos por actividad a cualquier proceso cuya ejecución pueda ser cuanti�cada numéricamente. Porejemplo el número de usuarios en el sistema o el número de Kbytes/segundo en una transferencia.

292

un modo muy preciso cual ha sido la evolución de esa actividad a lo largo de intervalos de

tiempo mayores.99

Variables Numéricas: Algunas veces no tiene sentido analizar la evolución cronológica

de la variable, simplemente basta con conocer su valor100.

Categóricas: Aquellas cuyo resultado es una categoría individual, y miden la frecuencia

relativa o la distribución de una actividad determinada con respecto a otras actividades o

categorías101 [VILLALÓN01].

Registros de auditoría: Esta medida analiza la distribución de las actividades generadas

en un pasado reciente basándose en los logs102 generados por las mismas; dicho análisis se

realiza de forma ponderada, teniendo más peso las actividades más recientes, y es compara-

do con un per�l de actividades `habituales' previamente almacenado, de forma que permite

detectar si en un pasado reciente se han generado eventos inusuales[VILLALÓN01]

A día de hoy este es sin duda uno de los campos en la detección de intrusiones con una línea

de investigación más activa103, no en vano existen cientos de aproximaciones104, sin embargo, la

gran mayoría de ellas chocan con los mismos problemas [NATO01].

En primer lugar el sistema deberá ser capaz de describir de un modo efectivo el comporta-

miento del sistema, algo de por sí muy complicado105, a esta di�cultad se le añade el problema

de la comparación y es que dado un patrón de comportamiento almacenado y un patrón de

comportamiento actual ¾cual es la desviación mínima que marca la diferencia entre normal y

anómalo106?. Por si todo esto fuera poco, estos sistemas deben hacer frente a un problema más

y es que dependiendo en la técnica de aprendizaje que emplee el sistema, un atacante con los

conocimientos necesarios podría entrenar poco a poco el sistema con pequeñas variaciones de

comportamiento no lo su�cientemente grandes como para ser consideradas en sí mismas como

una anomalía, pero si como para ir poco a poco cambiando el concepto de normalidad en el

sistema hasta adecuarlo a sus propositos.

99Las mediciones se hacen cada breves periodos de tiempo para que un pico de actividad al comienzo del periodono pueda ser compensado con un descenso de actividad al �nal del mismo.100Por ejemplo la variable número de procesos en ejecución.101Un ejemplo podría ser la comparación entre el número de intentos de entrada al sistema entre el usuario A y

el usuario B.102Un log es un registro de auditoría (generalmente un �chero de texto) en el cual las aplicaciones vuelcan

información de algún tipo.103Esto es la más estudiada, pero no por ello la más extendida en entornos productivos.104El sólo hecho de que existan tantas técnicas debería ponernos sobre la pista de que algo no funciona bien ya

que si al menos una funcionase correctamente no habría sitio para muchas más. Esto pone de mani�esto una vezmás el estado incipiente en el que se encuentran a día de hoy el conjunto de estas técnicas.105A pesar de que pueda parecer sencillo extraer las variables más relevantes incluso del sistema más sencillo

puede resultar extraordinariamente complicado.106Existen técnicas matemáticas que tratan de solucionar este problemas calculando el umbral óptimo, sin

embargo en la práctica el umbral suele ajustarse de un modo bastante ad-hoc

293

A pesar de los inconvenientes que presenta este método no debemos olvidarnos de sus ventajas

y es que teóricamente sería capaz de detectar los denominados Zero days attacks 107. Debemos

por tanto dar un voto de con�anza a un modelo aún en las primeras etapas de su desarrollo, pero

que promete revolucionar el futuro de los sistemas de detección de intrusiones.

Figura 3.43: Esquema de funcionamiento de un modelo de detección de anomalías

107Ataques nuevos aún no contemplados en las bases de datos, para los que evidentemente no existe ningunaregla especí�ca.

294

Conclusiones detección de anomalías

A pesar de los inconvenientes presentados este es uno de los modelos más prometedores y sin

duda marcará el futuro de los sistemas de detección de intrusiones. A continuación se resumen

sus principales ventajas e inconvenientes:Capacidad teórica de detectar ataques desconocidos por los expertos de seguridad.

Aprendizaje automático, menor necesidad de intervención por parte del administrador

de sistemas.

Tradicionalmente tanto su rendimiento como su efectividad ha sido baja comparada

con los sistemas basados en detección de usos indebidos.

Dado que el sistema evoluciona con el tiempo y la experiencia, cabe la posibilidad de

que un intruso pueda llegar a entrenarlo con el tiempo.

Taxonomía en base a la respuesta

Una vez detectado el ataque ha terminado gran parte de la labor del sistema de detección,

pero no toda, aún queda por decidir cual debe ser la respuesta ante dicho ataque. Existen dos

enfoques a la hora de tomar esta decisión:

Respuesta Pasiva Este enfoque se caracteriza por una cesión de responsabilidad del sistema

hacia el administrador, el sistema simplemente noti�cará la ocurrencia de un determinado evento

y deberá ser el administrador quien tome las medidas oportunas para paliar en la medida de lo

posible los efectos del recién detectado ataque ente los métodos de noti�cación más comunes se

encuentran los siguientes:

Ficheros de registro108: Una de las alternativas más comunes y de mayor tradición con-

siste en que el programa escriba109 en un �chero predeterminado cualquier evento o noti�-

cación que desee comunicar al administrador, será tarea de éste el analizar periódicamente

los �cheros de registro en busca de información relevante.

Correo Electrónico: Otra las alternativas más populares es el empleo del correo electró-

nico, de modo que la aplicación envía en un correo a la cuenta del administrador todas

aquellas incidencias que crea necesario reportar.

SMS110: Para noti�caciones más importantes el sistema puede enviar un mensaje de texto

al administrador del sistema, indicándole brevemente el tipo y la hora de la incidencia que

se haya producido.108También llamados �cheros de log109Para referirse a la acción de escribir en un �chero de registro suele emplearse una mala adaptación del verbo

inglés to log : loguear110Acrónimo de Short Message Service, es un servicio disponible en los teléfonos móviles que permite el envión

de mensajes cortos entre teléfonos móviles, �jos y otros dispositivos de mano [WIKI01].

295

En cualquiera de los métodos antes descritos se produce una diferencia de tiempo considerable

entre la detección del ataque por parte del sistema y la consiguiente acción del administrador. Es

precisamente este intervalo de tiempo el que hace incompatible el modelo de respuesta pasiva con

lo que más adelante describiremos como IPS o sistema de prevención de intrusiones. Podríamos

decir de un modo un tanto metafórico que un modelo de respuesta pasiva relega las funciones

del sistema de detección a las de un simple observador, es decir, puede presenciar un crimen y

llamar a la policía, pero nunca intervenir directamente a pesar de que una intervención temprana

resultaría casi siempre más efectiva.

Conclusiones respuesta pasiva

A pesar de ser un modelo muy conservador resulta ser una solución extremadamente útil

y la práctica totalidad de los sistemas de detección lo integran en sus soluciones, si no como

alternativa principal sí como complemento a una respuesta activa e�caz.

trusiones. A continuación se resumen sus principales ventajas e inconvenientes:

El sistema no podrá equivocarse tomando una decisión equivocada por cuenta propia.

Es más sencillo de instalar y con�gurar que un sistema de respuesta activa.

El sistema no podrá acertar tomando una decisión acertada por cuenta propia.

Requiere de una mayor intervención por parte del administrador de sistemas.

Respuesta Activa Un sistema que implemente respuesta activa tiene la capacidad de res-

ponder ante un ataque una vez detectado. Este enfoque que a priori parece el más lógico111, debe

con mucha prudencia, ya que a día de hoy no existe112 ningún sistema infalible113. Deberá por

tanto tenerse en cuenta antes de introducir este tipo de modelos en sistemas productivos el hecho

de que en el caso de un falso positivo,el sistema estará respondiendo ante un estado legítimo.

Cualquier administrador de red sabe, que si la seguridad es importante, aún lo es más el asegurar

un buen servicio.

A continuación se describen las respuestas activas más comunes clasi�cadas en base el origen

de la captura de los datos:

Respuestas para sistemas de tipo Máquina

111Quien mejor para intentar paliar los efectos de un ataque que aquel que viendo como sucede.112Podrá mejorarse la tasa de acierto pero probablemente no existirá nunca un sistema infalible.113Cuando un sistema falla puede hacerlo de dos formas: Bien con un falso positivo, es decir catalogar un

estado como subversivo cuando en realidad no lo es, o con un falso negativo que es justo todo lo contrario, nocatalogar como ataque un estado que en realidad si que lo es.

296

Envío de señales: Si el sistema detecta que uno de los procesos en ejecución tiene un

comportamiento sospechosos puede enviarle una señal114 para �nalizarlo.

Manipulación de los runlevels115: Para evitar males mayores, una vez detectado el

ataque, el sistema puede cambiar el runlevel, bien para apagar la máquina o para desactivar

las funciones de red. De este modo y como medida cautelar, el sistema quedaría en modo

de cuarentena hasta que el administrador del sistema decida cómo solucionar el problema.

Sistemas de decepción116: Una vez detectado el ataque, el sistema puede redireccionar el

proceso sospechoso a un honeypot, de este modo el proceso o la sesión del usuario seguiría

en ejecución pero en un contexto inocuo. El objetivo perseguido con esta técnica es ganar

tiempo para decidir si realmente es una ataque o en caso de que se con�rme que sí lo es,

disponer del tiempo su�ciente para poder trazar la conexión e identi�car al atacante.

Respuestas para sistemas de tipo Red

Interrupción de sesión: Suponiendo que el protocolo en el que se encuentre el ataque

sea orientado a la conexión, sería posible que el sistema de detección cerrase esa conexión

remotamente. En el caso de TCP esto se consigue inyectando117 un paquete con el �ag

RST activo. El éxito de esta técnica radica en inyectar el paquete antes de que el atacante,

de lo contrario no tendrá efecto pues los números de secuencia TCP no coincidirán.

Manipulación del Filtrado: Esta opción permite la modi�cación de las reglas de un

�rewall para así denegar el acceso118 a la IP del atacante durante un cierto tiempo.

DoS119 y DDoS120: Hay autores que consideran la opción de contraatacar frente a una

agresión. Para ello coordinarían una o varias máquinas para lanzar una denegación de

servicio al atacante.

114En sistemas Unix like la señal que enviaría es la 9 (SIGKILL) de�nida en /usr/include/signal.h115En entornos Unix like, existen diferentes runlevels (niveles de ejecución), estos son los encargados de de�nir

que servicios están disponibles en el sistema. Para este caso en concreto son interesantes los runlevels 0 (paradadel sistema) 1 (modo monousuario) 2 (modo multiusuario sin red)116También llamados honeypots (tarros de miel)117Para inyectar un paquete dentro de una conexión de tipo TCP, necesitamos saber cuales son las IP origen

y destino de los dos extremos y el número de secuencia del segmento inmediatamente anterior al que queremosinyectar. Toda esta información podemos conseguirla esnifando la conexión en curso.118En inglés se emplea el verbo to ban119Un ataque de denegación del servicio, también llamado ataque DoS (Denial of Service), es un ataque a un

sistema de ordenadores o red que causa una pérdida en el servicio a los usuarios. Normalmente provoca la pérdidade la conectividad de la red por el consumo del ancho de banda de la red de la víctima o sobrecarga de los recursoscomputacionales del sistema de la víctima. [WIKI02]120DDoS ( Distributed Denial of Service )es una ampliación del ataque DoS, se efectúa con la instalación de

varios agentes remotos en muchas computadoras que pueden estar localizadas en diferentes puntos. [WIKI02]

297

Conclusiones respuesta activa

La respuesta activa es el primer paso hacia la prevención de intrusiones (IPS121). A día de

hoy pocos son los expertos en la materia que no vean en esta técnica a la alternativa dominante

en un futuro no muy lejano.

trusiones. A continuación se resumen sus principales ventajas e inconvenientes:El sistema podrá acertar tomando una decisión por cuenta propia.

Requiere de una menor intervención por parte del administrador de sistemas.

El sistema podría equivocarse tomando una decisión equivocada por cuenta propia.

Dado que hay que integrar el sistema de detección con el resto del hardware de la red,

la con�guración suele ser más compleja.

IPS Intrusion Prevention Systems

Una de las últimas tendencias en el desarrollo de sistemas de detección de intrusiones son

los IPS o sistemas de prevención de intrusiones. Estos sistemas son una evolución lógica hacia la

hibridación entre los �rewalls122 y los NIDS (véase Figura 3.44: IPS integrado en una red).

Figura 3.44: IPS integrado en una red

121IPS (Intrusion prevention systems) técnica que se explica más adelante.122Conjunto de hardware y/o software montados sobre un sistema que controla el trá�co entre dos redes aplicando

una serie de reglas especi�cas.

298

¾Por qué detectar a nivel de Firewall?

El �rewall es un elemento crítico en cualquier cualquier red.

Nexo de unión con el mundo exterior.

Punto medio por el que pasa todo el trá�co.

Modi�cación sencilla.

Alta efectividad (bajos falsos positivos)

En un sistema de estas características el trá�co es analizando antes de entrar en la propia red,

luego si detectamos un ataque, este no tiene por que llegar a su destino, basta con que el IPS

ordene al �rewall que haga un drop del paquete en cuestión, para que el ataque nunca llegue a

su destino. Atendiendo a las características expuestas en [SANS01] un IPS debe:

Deben analizar el trá�co y responder en tiempo real para detener el ataque que se es-

te realizando, ya que si la respuesta es muy lenta o tardía los host pueden haber sido

comprometidos y la intrusión no haberse evitado.

Debe tener un ratio muy bajo de falsos negativos y ser capaz de detectar un numero elevado

de ataques que no solo buscan la intrusión sino también la evasión123. Al tiempo que no

deben provocar la denegación de servicio a usuarios legítimos.

Deben detectar e informar de actividades, internas y externas, anómalas así como del mal

uso de los recursos de los sistemas.

Alertar al personal de seguridad y responder a los intentos de intrusión modi�cando el

�rewall o bloqueando el ataque el curso.

Deben ser capaces de procesar todo el trá�co que se produce en las redes de alta veloci-

dad124.

123Es decir pasar el control del IPS, típicamente con campos de la cabecera ttl muy bajos.124De lo contrario no serían de procesar todo el tra�co y sólo les quedaría dos alternativas descartar el paquete

o dejar pasar el trá�co sin analizarlo. Cualquiera de las dos alternativas es seguramente una mala idea.

299

3.3.4. Introducción a DFSU

A lo largo del Capítulo 1 hemos pasado revista en mayor o menor medida a los distintos

modelos que históricamente han sido empleados para tratar de detectar de un modo lo más

efectivo posible, cualquier intrusión o intento de intrusión. En el segundo capítulo, emplearemos

estos conocimientos para describir y clasi�car DFSU tratando en la medida de los posible justi�car

nuestras decisiones. Tras la lectura de este capítulo el lector deberá comprender cuál la estructura

básica de DFSU y ser capaz de describir comparativamente DFSU con respecto a las técnicas

descritas en el Capítulo 1.

¾Por qué desarrollar otro IDS?

A día de hoy existen en el mercado in�nidad de alternativas capaces de implementar la

práctica totalidad de las técnicas de detección descritas a lo largo del primer capítulo, parece por

tanto lógico hacerse las siguientes preguntas ¾tiene sentido crear otro IDS?, ¾aporta DFSU algo

nuevo al panorama tecnológico actual o es una simple prueba de concepto?

Para contestar a estas dos preguntas, lo mejor sería empezar por explicar lo qué no es DFSU.

A pesar del contexto puramente académico en el que se localiza el presente trabajo, DFSU

no es ni un desarrollo formal ni una prueba de concepto sino más bien todo lo contrario. DFSU

pretende ser una alternativa real a los problemas125 de seguridad a los que el conjunto de nuestros

sistemas de información deben hacer frente cada día, problemas que por otra parte ninguno de las

innumerables alternativas existentes en el mercado ha sido capaz de erradicar. Con la esperanza

de triunfar donde otros fallaron surge DFSU, un nuevo enfoque en los sistemas de detección de

intrusiones.

¾Qué es DFSU?

Si nos remontamos al comienzo de esta memoria, concretamente al Capítulo 1, capítulo en el

que se describe el estado del arte de los sistemas de detección de intrusiones, veremos que éste

se encuentra dividido en tres secciones principales. En cada una de estas secciones se describe

una taxonomía o clasi�cación126: �Los IDS's pueden estar basados en host o basados en red,

basados en anomalías o basados en reglas�. Cada una de estas clasi�caciones tiene sus ventajas e

inconvenientes, mientras que los sistemas basados en reglas son poco �exibles pero muy �ables,

los sistemas basados en anomalías son justo todo lo contrario, muy �exibles pero poco �ables.

La inmensa mayoría127 de los sistemas existentes siguen muy de cerca esta clasi�cación,

es decir, crean sistemas basados en máquina o en red, basados en anomalías o reglas, algunos

empiezan ahora a incorporar respuesta activa y respuesta pasiva pero son los menos128. Nosotros125Problemas por otra parte no menos reales126Véase Figura 3.45127A excepción de DIDS (Distributed Intrusion Detection System) prototipo desarrollado por la universidad de

California, no se continua desarrollando.128Algunos plugins de snort permiten recon�gurar iptables y snort inline por su puesto

300

creemos que este tipo de clasi�caciones están obsoletas129, puede que tuviese sentido hace años

cuando la seguridad de la información era un problema virgen y tan gigantesco que tratar de

abarcarlo todo a la vez era impracticable. Hoy cada uno de los campos de especialización en los

que se dividió el problema para hacerlo más asequible, está lo su�cientemente maduro como para

retomarlo y emplearlo como base solida desde la que lanzar el ataque �nal hacia la uni�cación.

El futuro pasa por correlacionar el trá�co sospechoso en un segmento de red con la actividad

anómala en el ordenador que lo generó y esto es precisamente lo que es DFSU; Un framework

capaz de analizar de un modo centralizado tanto la información de cualquier tipo de dispositivo

físico (PC's, PDA's, teléfonos móviles) como máquina de sus comunicaciones (trá�co de red).

Figura 3.45: Taxonomía de los sistemas de detección de intrusiones

129Al menos en la práctica, desde un punto de vista académico la clasi�cación seguirá siendo por supuesto válida.

301

DFSU, una visión arquitectónica

Para lograr la integración tan deseada, DFSU se fundamenta en un modelo multicapa de

agentes distribuidos. Cada uno de los agentes distribuidos será un punto de recogida de informa-

ción heterogéneo que podrá estar instalado bien en una máquina, recogiendo la información que

procesaría un HIDS o bien en un segmento de red recogiendo la información que procesaría un

NIDS. Es importante recalcar que los agentes distribuidos a diferencia de los HIDS o NIDS no

realizan ningún tipo de procesamiento sobre la captura sino que simplemente lo empaquetan y

lo envían a través de la red hasta la infraestructura centralizada de procesado.

Dado que el procesado no tiene lugar en el punto de captura, los agentes serán procesos ligeros

que podrán instalarse en prácticamente cualquier dispositivo hardware130 sin una degradación

perceptible en su rendimiento131. Evidentemente esto tiene su contrapartida, la infraestructura

centralizada a la que se reporta toda la información desde los agentes, deberá ser capaz de

procesar grandes volúmenes de información132. DFSU consigue este objetivo introduciendo una

capa de procesamiento sobre la que el administrador podrá añadir o retirar unidades133 hasta

ajustarlo a las necesidades de su entorno productivo.

130A día de hoy tenemos programados agentes de este tipo no sólo para segmentos de red u ordenadores perso-nales, también para teléfonos móviles y PDAs131No degradando de un modo perceptible el rendimiento de la máquina sobre la que se ejecuta, solventamos

uno de los grandes inconvenientes presentados por los HIDS.132El volumen de información dependerá lógicamente del número de agentes y de la cantidad de información que

recojan.133Nos referimos por unidades a cualquier dispositivo capaz de procesar información, generalmente serán PCs

302

DFSU se fundamenta por tanto en una arquitectura cliente/servidor de 3 capas134: la capa

de captura, capa de distribución y capa de procesamiento. La idea fundamental de la �losofía

cliente/servidor es la distribución de las tareas que debe realizar el sistema. Cada capa se encarga

de proveer ciertos servicios:

Capa de captura: Constituida por el conjunto de los agentes distribuidos, su misión será

recoger información heterogénea, empaquetarla y enviarla a la capa de distribución.

Capa de distribución: Esta capa tiene la misión de centralizar tanto las entradas del

sistema (fuentes de información e interfaces de administración) como las repuestas 135 tras

la detección de un ataque.

Capa de procesamiento: Una vez que la información llega hasta la capa de distribución,

esta se encarga de redistribuirla entre los distintas unidades que componen la capa de

procesamiento, estas en caso de detectar algún ataque le retornarán un aviso.

Una arquitectura multicapa cliente/servidor como lo que aquí se presenta, con�ere al sistema las

siguientes características:

1. Escalabilidad: Permite la adición de nuevos equipos en cualquiera de sus 3 niveles para

acomodarse a los requerimientos dinámicos del sistema.

2. Portabilidad: El software continua en vigencia más tiempo que el hardware que lo soporta,

es por ello que el software de DFSU se caracteriza por su portabilidad a través de distintos

tipos de hardware136 y sistemas operativos.

3. Apertura: Todos los datos están almacenados en �cheros de formato abierto137 manipu-

lables desde de un simple editor de textos.

4. Flexibilidad: Una arquitectura de este tipo permite ajustar la topología del sistema a un

gran número de entornos productivos.

3.3.5. Estructura básica de DFSU

Hoy en día la reducción de costes es un factor muy a tener en cuenta por toda empresa

que desee ser competitiva en el mercado, en este sentido, la adquisición de grandes máquinas

de procesamiento comienza a no ser justi�cable ante soluciones más económicas como son los

sistemas de procesamiento distribuido. En este capítulo se expondrán con nombre propio los

elementos que componen el sistema distribuido de DFSU ya explicados durante el Capítulo 2 así

como las topologías en que puede con�gurarse un sistema productivo.134Véase Figura 3.43[UINDEB01]135Véase el apartado 3.3.3136Hasta la fecha ha sido probado satisfactoriamente en arquitectura de 32 y 64 bits y en LittleEndian y BigEn-

dian137Formato XML �Extensible Markup Language�

303

Figura 3.46: Arquitectura de tres capas

Elementos estructurales y de�niciones preliminares

Dentro de la estructura de DFSU se distinguen 3 elementos básicos: Masters, Heads y Tails,

la función de estos es implementar cada una de las capas en las que se divide DFSU:

1. Capa de Captura → Masters

2. Capa de Distribución → Heads

3. Capa de Procesamiento → Tails

Masters o agentes distribuidos

Los Masters son agentes heterogéneos y distribuidos cuya función es capturar, etiquetar y

encapsular en eventos la información que se desea analizar. Se encuentran dispersos a lo largo de

la red138.

Además de enviar la información capturada a la unidad central (Head), estos agentes pueden

ser capaces de recibir y procesar comandos enviados por él. Estos comandos pueden ser de

con�guración ya que DFSU se gestiona de un modo centralizado desde el Head o de respuesta

activa, en caso de que el sistema esté funcionando en modo IPS.

Dado que contamos con Masters especializados en diferentes campos (HIDS y NIDS), el

sistema dispone de una visión global de todo el entorno, pudiendo incluso llegar a correlacionar

eventos de máquina con eventos de red. Imaginemos por ejemplo una red en la que se dispone

de un master de red (Master2) y de un master de host (Master1)139 , ambos reportando la

información capturada a la infraestructura de DFSU. Supongamos ahora que el Master2 detecta138Normalmente los monitores de red suelen ubicarse en cada uno de los dominios de colisión de la red y los

Monitores de host en cada una de las máquinas que se quiera auditar.139Véase Figura 3.47

304

una anomalía en el trá�co de red de la Subnet1, DFSU podría correlacionar esa anomalía con

el comportamiento de la aplicación que lo ha generado en el Host1, aprendiendo así cual es el

comportamiento a nivel de syscalls que tiene un efecto pernicioso para el sistema a nivel de red.

Fíjese el lector que DFSU desborda a los sistemas tradicionales ya que tiene acceso tanto

a los efectos del problema140 como a las causas que lo originaron141, pudiendo así analizar el

problema desde los dos puntos de vista. Por si ésto fuera poco, DFSU puede llevar la respuesta

activa hasta cotas nunca antes soñadas y es que teniendo acceso directo tanto a las causas como a

los efectos puede intervenir sobre ambos. En el ejemplo propuesto, podría intervenir activamente

y recon�gurar un Firewall para que no deje pasar más trá�co desde el Host1 (actuando sobre los

efectos) o podría cerrar la aplicación que esta creando problemas (actuando sobre las causas).

Como puede verse un modelo de este tipo permite un campo de acción prácticamente ilimi-

tado.

Figura 3.47: Correlacionando HIDS y NIDS

Masters implementados hasta la fecha A día de hoy DFSU cuenta con tres tipos de

masters completamente funcionales. Estos masters son tanto para la monitorización del trá�co

de red como para la auditoría de máquinas. En el caso de los sistemas de red empleamos un

versión modi�cada de snort y en el caso de las auditorías hemos desarrollado una aplicación

nueva para la captura de syscalls como se explicará más adelante.

Monitor de red Al comienzo del proyecto se planteó la opción de crear un monitor de

red empleando para ello la librería libpcap142, llegando incluso a desarrollar versiones funcionales

de éste. Poco tiempo después nos dimos cuenta de que en realidad no tenía demasiado sentido

reprogramar desde cero algo sobre lo que habían estado trabajando programadores muy cuali�-

cados durante mucho tiempo. Decidimos por tanto adaptar Snort a nuestras necesidades. Ésta

elección tubo por dos motivos:140En este caso un ataque de red141Un conjunto de syscalls determinado.142Libpcap es una librería para la captura de datos desde zona usuario. http://www.tcpdump.org . [LOPEZ01]

305

1. Snort es a día de hoy el estándar de facto en los sistemas de detección de intrusiones basados

en red.

2. Snort está licenciado bajo GPL, gracias a esto podemos tomar su código modi�carlo y

redistribuirlo143.

Modi�cando Snort hemos conseguido no sólo las ventajas del mejor sni�er sino también un

veredicto con el que entrenar nuestros plugins basados en inteligencia arti�cial de un modo

automático y no supervisado.

Monitor de Host De todas las técnicas existentes a la hora de implementar un HIDS

hemos elegido la auditoría de syscalls por considerarla la más difícil de burlar144 siendo a la vez

la que puede suministrarnos una información más completa y detallada sobre la ejecución de los

programas en la zona usuario. No descartamos sin embargo integrar en el futuro esta solución

con otras ya existentes como por ejemplo Tripwire145.

Actualmente en desarrollo Existen a día de hoy varios proyectos del tecnológico de

Deusto que emplean la infraestructura de DFSU y en los cuales se están implementando nuevos

Masters, concretamente versiones para Windows Mobile lo que permitiría emplear DFSU en más

del 50% del mercado de PDA's [EROSKI01], también para Symbian lo que cubriría el 57% del

mercado de teléfonos de última generación146[QUES01]. Finalmente existe también un proyecto

de crear una versión para Windows.

Head o unidad central

El Head es el elemento principal de la arquitectura e implementa la capa de distribución. Su

misión principal es la de recibir los eventos provenientes de los Masters y distribuirlos entre los

Tails pudiendo antes hacer ligeras147 modi�caciones sobre esta información e incluso añadir nue-

vos datos. Se encarga también de centralizar todas las labores administrativas ya que implementa

las interfaces de usuario.

La distribución de la información o balanceo depende de la política de forwarding con la

que este con�gurado el sistema148, el objetivo perseguido al balancear la información es dividir

el número de eventos entre varias unidades de procesamiento (Tails), logrando de este modo

aumentar el rendimiento y permitiendo una escalabilidad sin precedentes.

143Por supuesto esto nos obliga a mantener la licencia original es decir GPL144Recordemos que está implementada a nivel de Kernel y no de usuario que es desde donde llegan los posibles

ataques.145Tripwire http://sourceforge.net/projects/tripwire146También llamados SmartPhones147Las modi�caciones deben ser computacionalmente sencillas, ya que si sobrecargamos el head toda la infraes-

tructura se resentirá notablemente.148Véase 3.3.7

306

Para simpli�car las labores de administración, el Head centraliza además el conjunto de

alertas generadas por los Tails y toma la iniciativa de la respuesta activa enviando ordenes de

recon�guración tanto a masters de red como a masters host.

El Head es una pieza clave del sistema, si el Head falla el sistema al completo dejaría de

funcionar, de ahí que en entornos reales existe la posibilidad de con�gurar Heads de respaldo los

cuales en circunstancias normales estarían inactivos pero que si ocurriera un fallo grave o una

labor de mantenimiento del sistema principal, podrían activarse y continuar con el trabajo.

Tails o unidades de procesamiento

Los Tails reciben y procesan tanto los eventos como los comandos que el Head les reenvía. Una

vez han recibido esta información se pone en marcha la infraestructura de eventos; Un paquete

de información es un evento de tipo red (nEvent) o de tipo host (hEvent) de modo que todos

los plugins suscritos al evento en curso serán llamados para que desarrollen la labor para la que

fueron creados.

Si el plugin en cuestión es un ExpertPlugin149, éste deberá establecer si el paquete es o no

un ataque. En caso de que lo sea, la infraestructura generará un evento de tipo alerta (Alert)

que será enviado de vuelta al Head. Éste llamará a los plugins suscritos a eventos de tipo alerta

(OutputPlugins) y serán ellos quienes tomarán las medidas de respuesta oportuna.

Podríamos decir que los Tails son en núcleo de proceso de DFSU, pues en ellos se llevan a

cabo las labores de detección. Dado que la arquitectura permite escalar su capacidad simplemente

añadiendo maquinas, sería posible reducir el gasto en hardware empleando muchos ordenadores

lentos para igualar la prestaciones que daría uno más rápido o unir varios rápidos para manejar

un volumen de datos muy grande.

Con�guraciones topológicas soportadas por DFSU

Uno de los principales problemas a los que deben hacer frente los sistemas de detección de

intrusiones es sin duda ser capaz de procesar un volumen de datos ingente y hacerlo además en

un lapso lo su�cientemente pequeño como para poder dar una respuesta en tiempo real. Se hace

por tanto necesario, aumentar las capacidades de proceso de éstos sistemas.

Existen al menos dos alternativas para llevar a cabo ésta tarea; Por un lado nos encontramos

con la escalabilidad vertical. Esta consiste en de�nitiva en aumentar la potencia del hardware150

bien mejorando sus componentes151, bien adquiriendo uno nuevo más potente. La otra alternativa

es la escalabilidad horizontal que consiste en emplear de un modo combinado la potencia de

equipos más pequeños, para lograr así un potencial de cálculo superior al que podrían desarrollar

cada uno de ellos por separado.

149Véase 3.3.7150Esto puede conseguirse mediante el uso de mainframes y demás ordenadores de gama alta.151En inglés to upgrade

307

En las fases iniciales de este proyecto descartamos la escalabilidad vertical. La principal ra-

zón para tomar esta decisión, fue que ésta lleva asociada una inversión económica que no está

al alcance de muchas pequeñas y medianas empresas, ni por supuesto al de usuarios domésticos.

Decidimos por tanto apostar por un sistema de capas que permitiera ajustar de una manera �e-

xible y sencilla la capacidad de cómputo del sistema a cada escenario productivo. A continuación

se describen las principales

Estructura mono-capa

Esta es la con�guración topológica más sencilla de todas y consiste en arrancar todas las capas

en la misma máquina. Es decir, tener en una sola máquina arrancados los Master y el Head con

los plugins de detección activos. Este modelo está totalmente desaconsejado para un sistema

productivo, sin embargo puede resultar muy socorrido en entornos académicos o de desarrollo en

los que el rendimiento no es un factor a tener en muy cuenta.

Estructura de dos capas

Únicamente desglosamos dos capas, una de captura y una en la que fusionamos distribución

y procesado. Activamos de este modo los plugins de detección en el Head prescindiendo de los

Tails pero aprovechando la potencialidad que nos dan los Masters distribuidos.

A la hora de montar este modelo, deberá tenerse en cuenta que la capacidad de procesamiento

de DFSU estará limitada por la máquina en la que se monte el Head, debiendo en cualquier caso

controlar el número de Masters distribuidos para no llegar a un escenario en el que el sistema se

vea sobrepasado por una carga de información excesiva.

En este tipo de con�guración la escalabilidad en caso de sobrecarga está muy limitada, por eso

creemos que está puede resultar útil para sistemas no críticos quedando claramente descartada

para proteger redes de importancia crítica o que puedan generar un gran volumen de datos.

Figura 3.48: Estructura de dos capas

308

Estructura de tres capas

Esta es la con�guración en donde DFSU explota plenamente el potencial de las tres capas152.

En este esquema los plugins de detección se localizan en los Tails siendo éstos quienes envían las

alertas de vuelta hacia el Head para ser tratadas.

Como puede en Figura 2: Estructura de tres capas el número de Tails es variable, pudiendo

el administrador adaptar su número hasta adecuarlo a las necesidades de la red.

Figura 3.49: Estructura de tres capas

Se recomienda que la información que circula entre Heads, Tails y Masters vaya por una red

separada, de este modo no degradaremos el rendimiento de la red que pretendemos monitorizar153

sobre la que está montada el sistema productivo de la empresa y además proteger al propio

sistema de detección de potenciales ataques.

152Véase Figura 3.43153De lo contrario un master de red el trá�co de paquetes puesto que todo lo que circulo lo encapsula y reenvía

al head.

309

Estructura con plugins distribuidos

Los plugins de detección son los encargados del proceso de análisis de la información recogida

y pueden basarse bien en reglas cuya ejecución es poco costosa y por lo tanto suponen una

sobrecarga leve en el sistema o bien en redes con gran capacidad de análisis (Redes Bayesianas154)

las cuales suponen una sobrecarga muy alta en la máquina donde están ejecutándose. Es en este

segundo caso donde los plugins distribuidos ayudan a evitar la sobrecarga del Tail que aloja los

expertos.

Figura 3.50: Estructura con plugins distribuidos

En caso de que dispongamos de un plugin muy pesado, podremos preparar una máquina, que

deberá estar conectada al Tail, donde se ejecutará el experto evitando así la posible sobrecarga.

154Modelo probabilístico que relaciona un conjunto de variables indicandoexplicitamente mediante un grafo dirigido in�uencia causal.

310

Estructura con Heads jerárquicos

Si bien es cierto que el balanceo de carga existente en el Head alivia la carga que soportan los

Tails para que no se saturen, en sistemas con grandes volúmenes de información para analizar,

es el Head quien podría llegar a saturarse.

Para solucionar este posible aunque improbable problema, se puede establecer una jerarquía

de Heads que funcionarían de la siguiente manera:

1. En un primer nivel, el head únicamente actuaría como balanceador distribuyendo los even-

tos recibidos, sin realizar ningún cálculo ni procesado, de forma homogénea entre los Heads

de nivel 2.

2. En el segundo nivel, los Heads coordinados entre sí como si de uno solo se trataran, balan-

cearían los eventos entre los Tails.

Figura 3.51: Estructura de Heads jerárquicos

Como puede verse en la Figura 3.51 podemos tener tantos Heads funcionando en paralelo

como se desee.

Conclusión

Sin duda contar con una arquitectura multicapa es una de las mayores virtudes DFSU, gracias

a ella podemos crear topologías tan diversas como las que se han presentado a lo largo de este

capítulo y que con�eren a DFSU una escalabilidad y �exibilidad sin precedentes en este campo

de estudio.

311

3.3.6. DFSU un programa polifacético

DFSU puede verse desde varias perspectivas según quién y cómo vaya a utilizarlo. Es por

ello que este apartado se desglosa en tres puntos; Perspectiva del usuario �nal, perspectiva del

administrador de sistemas y perspectiva del desarrollador.

En cada apartado se explicará lo que cada usuario debería conocer para la correcta utilización

de DFSU y la repercusión que la implantación tendría en cada uno de ellos. Tras la lectura de

este apartado se deberán conocer las diferencias entre las tres perspectivas existentes.

DFSU desde la perspectiva del usuario �nal

¾Quién puede ser un usuario �nal de DFSU?

La respuesta a esta pregunta es fácil; cualquiera. Existen dos maneras a través de las cuales

DFSU puede estar recopilando nuestra información:

1. A través de la Red: Se da este caso cuando se está conectado a una red donde agentes

de DFSU están monitorizando el trá�co que circula . La adquisición de datos por parte de

los agentes es completamente transparente para estos usuarios.

2. A través de Host: En este caso el agente debe estar instalado en la máquina del usuario.

Ésto genera un trá�co añadido a la red que aún no siendo muy elevado, debe estar calculado

por los administradores de la misma con el �n de que no repercuta en la percepción que el

usuario tiene de la calidad del servicio.

Problemática en materia de seguridad a la que se enfrentan los usuarios �nales

Actualmente los usuarios que desean tener protegido su terminal, tanto PC's como PDA's y

terminales móviles, utilizan una serie de herramientas como antivirus, �rewalls, HIDS, etc., que

repercuten de forma negativa en el rendimiento del sistema que utilizan. Además, deben soportar

las constantes actualizaciones a las que se ven sometidas diariamente estas aplicaciones con el

�n de hacer frente a los nuevas herramientas de ataque.

La utilización de estos sistemas, en donde el cálculo se realiza en el cliente, comienza a no

estar justi�cada pues día a día se dispone de: Redes de mayor capacidad para el envío de la

información y Arquitecturas con mayor potencia de cálculo para el procesado de la misma.

¾En qué medida DFSU puede resolver estos problemas?

Al igual que en la tecnología web, donde los nuevos sistemas tienden a servidores que se

encargan de la mayoría de los cálculos y el usuario únicamente necesita un cliente muy ligero

para visualizar la información, DFSU propone agentes muy ligeros. Masters donde solamente

se captura y se envía la información que se desea procesar a través de la red. Esto supone una

312

mejora palpable en el rendimiento de los ordenadores, mucho más en terminales móviles, y por

tanto una transparencia casi total para el usuario cuando hablamos de auditoría de Hosts. La

transparencia total se ve re�ejada en el ámbito de las Redes y la monitorización de su trá�co,

donde el usuario �nal no necesita tener instalado en su terminal ningún tipo de agente. En

este caso son los propios administradores, (ISP's155 y demás operadores de telecomunicaciones,

bancos, multinacionales, etc.), quienes los instalan a lo largo de sus redes.

155Internet Service Provider, (Proveedor de servicios de Internet)

313

DFSU desde la perspectiva del administrador

Un administrador debe ser capaz de con�gurar la infraestructura del modo que desee. En

esta sección se detallarán pues, los elementos con�gurables así como los diferentes modos de

funcionamiento y se hará una descripción exhaustiva sobre el sistema de plugins y su correcta

utilización.

¾Quién puede ser un administrador de DFSU?

Ya que entre las tareas más importantes que debe llevar a cabo un administrador de DFSU

tocan el ámbito de las redes y el sistema operativo GNU/Linux, lo más recomendable sería

disponer de un profesional con un nivel alto de conocimientos en estos campos.

Problemática a la que se enfrentan los administradores de sistemas

Los administradores de sistemas han de lidiar diariamente con ataques dirigidos contra las

redes que están administrando. Para ello instalan y mantienen sistemas de seguridad de diferentes

tipos por lo que deben conocer un amplio número de con�guraciones posibles por cada sistema

instalado además de las interfaces y comandos que oferta cada uno de ellos.

¾En qué medida DFSU puede resolver estos problemas?

DFSU trata de solucionar en la mayor medida posible estas complicaciones, uni�cando los

diferentes sistemas de detección de intrusiones existentes y centralizando la con�guración de todo

el sistema desde la unidad central (Head) que proporciona una interfaz intuitiva y potente.

Conjunto de tareas asociadas a un administrador de DFSU

El administrador de sistemas se deberá encargar de con�gurar y poner a punto el sistema,

así como de tomar las decisiones sobre:

1. Qué estructura es la más adecuada.

2. Cuántas y dónde se han de situar las sondas.

3. Los plugins que estarán cargados.

4. Las políticas de enrutado y de respuesta ante alertas.

Las sondas se han de colocar en aquellos sitios de la red donde se quiera monitorizar la información

que circula por ella y en aquellas máquinas en los que se quiera realizar una auditoría sobre su

funcionamiento.

314

Lo más habitual es cargar los mismos plugins de detección en todos los Tails, pero si se

dispone de una cantidad muy elevada de éstos, puede ser recomendable no cargarlos todos dejando

únicamente los más actuales.

De haber un plugin muy pesado, la mejor opción es que sea cargado en el sistema como

distribuido.

315

DFSU desde la perspectiva del desarrollador

DFSU es un proyecto vivo que debe seguir creciendo y adaptándose a las nuevas ideas y

requerimientos. Actualmente existen desarrolladores que se encargan de estas tareas y aquellos

programadores que deseen unirse al proyecto y aportar sus ideas y conocimientos, deben tener

una base y experiencia con el �n de que lo realizado sea robusto y �able.

¾Quién puede ser un desarrollador de DFSU?

La estructura principal de DFSU ha sido desarrollada en c++ bajo la plataforma GNU/Linux.

Es por esto por lo que un desarrollador que quiera ayudar en la mejora y ampliación de la

infraestructura interna, debe tener experiencia en los siguientes campos:

1. Diseño de aplicaciones con idiomas de programación orientados a objetos

2. Programación en c++ sobre el sistema operativo GNU/Linux

3. Programación en redes.

Si se desea desarrollar un agente distribuido, basta con conocer el sistema para el que se quiera

desarrollar el agente y tener conocimientos sobre programación en redes.

Como último apunte mencionar que es preferible que los desarrolladores utilicen la mayor

parte de código estándar posible.

316

3.3.7. Componentes de DFSU

Arquitectura de plugins

Los plugins son una parte fundamental de DFSU pues la captura de datos y el procesado

existente en la infraestructura, está destinado ha hacerles llegar la información que necesitan

debidamente formateada y de la forma más transparente posible.

Todos los plugins a excepción de los propios del sistema, �System Plugins�, se compilan

fuera de la infraestructura como librerías dinámicas. Ésto quiere decir, que se puede desarrollar

un plugin y probarlo sin necesidad de compilar una y otra vez la infraestructura, ahorrando

un tiempo considerable. Además da la posibilidad de cargar solamente aquellos plugins que

deseemos en cada momento de forma dinámica, sin necesidad de modi�car, recompilar o reiniciar

la infraestructura.

Otra de las ventajas de que los plugins sean independientes es que pueden estar licenciados

bajo una licencia diferente a la que lleva la estructura de DFSU, esto es; la GPL. Aquellos

desarrolladores que deseen colaborar añadiendo funcionalidades podrán escoger entre un gran

abanico de posibilidades a la hora de licenciar sus plugins.

Para desarrollar un plugin, basta con elegir la plantilla correspondiente según su función.

Todo plugin hereda de la clase �plugskel� Figura 1: Estructura de herencia de los plugins a

través de la propia al tipo, la cual aporta atributos particulares a cada plugin, como se muestra

en la �gura:

Figura 3.52: Estructura de herencia de los plugins

Existen pues tres funciones comunes a modo de api que deben implementarse ya que están

preparadas para que la infraestructura se comunique y envíe información al plugin:

1. void callBack(Evento* evnt): Esta función se ejecutará cuando se de el evento a los

que está suscrito el plugin.

2. doThis(string cmd): Si se quieren interpretar los comandos recibidos por consola se

deberá implementar esta función.

317

3. onExit(): Esta función se ejecutará cuando se destruya el plugin y deberemos colocar en

ella la liberación de la memoria reservada.

Figura 3.53: Clase PlugSkel

318

Tipos de plugins

Como se puede observar en la Figura 1: Estructura de herencia de los plugins existen cinco

tipos de plugins; Utility Plugin, Expert Plugin, System Plugin, Output Plugin y Distributed

Plugin.

Cada plugin cumple una función determinada, por lo que hay que escoger adecuadamente la

plantilla cuando se vaya a desarrollar un plugin:

1. Utility Plugin: Este tipo de plugins suele tener una preferencia alta pues su función

debería ser la de transformar, �ltrar o modi�car de alguna manera la información referente

a los eventos para otros.

Entre estos plugins podemos encontrar al llamado �conntrack� del que más adelante se

hablará en detalle.

La plantilla de estos plugins se encuentra en �src/uplugins/templateU�.

2. Expert Plugin: Los expert plugins o plugins expertos tienen la misión de analizar los

eventos recibidos aplicando algoritmos y técnicas de detección de anomalías, intrusiones

y/o ataques.

Figura 3.54: Clase ExpertSkel

Todo experto hereda de la clase �ExpertSkel� Figura 3: Clase ExpertSkel y debe hacer uso

de la función especial setVeredict que se encuentra sobrecargada posibilitando las siguientes

opciones:

a) setVeredict(int veredicto): Esta función únicamente especi�ca el tipo de ataque.

b) setVeredict(int veredicto, string descripción): Aquí se nos da la posibilidad de

añadir una descripción en caso de que el veredicto para ataque sea positivo pudiendo

dar más información sobre el ataque.

319

c) setVeredict(int veredicto, string descripción, int tipoAtaque): Por último

se puede indicar además del veredicto y de la descripción el tipo de ataque con las

siguientes opciones:

1) INFORMATIVE: El evento recibido no es peligroso, pero se desea reportar su

entrada en el sistema.

2) PONTENTIALLY_DANGEROUS: Indica que de por si el evento no es

dañino y que probablemente depende de la evaluación de próximos eventos y/u

otros parámetros para poder determinar la forma en que afectará su entrada en

el sistema.

3) DANGEROUS: El evento recibido debe tratarse ya que es maligno para el

sistema contra el que va dirigido.

4) EXTREMELLY_DANGEROUS: Indica que el evento es extremadamente

peligroso para el sistema al que va dirigido.

5) TESTING: Es un identi�car para pruebas en el sistema.

Por otro lado los valores posibles para los veredictos están de�nidos en la cabecera

de la clase �ExpertSkel� y pueden ser los siguientes:

a ′ NO: El evento recibido no es un ataque.

b′ YES: El evento recibido es un ataque.

c′ NSNC156: No se debe tener en cuenta el veredicto del plugin para este evento.

La plantilla de estos plugins se encuentra en �src/eplugins/templateE�.

3. System Plugins: Los system plugins o plugins del sistema son imprescindibles, desempe-

ñan funcionen críticas del sistema y se compilan junto con este no siendo posible descargar-

los. Algunos ejemplos de las tareas que puede desarrollar un system plugin son por ejemplo

la interpretación de los eventos de comandos, decidir sobre el enrutado de paquetes etc...

La plantilla para la creación de estos plugins puede encontrarse en la ruta �src/splugins/-

tempalteS�.

4. Output Plugins: Los Output plugins o plugins de salida, son plugins especializados en el

tratamiento de alertas. Una de las características más destacadas de este tipo de plugins es

que se ejecutan en un thread distinto al del resto de plugins, con esto pretendemos evitar

que una operación de entrada salida como por ejemplo la escritura a una base de datos

paralice la ejecución del resto de plugins.

La plantilla para la creación de estos plugins puede encontrarse en la ruta �src/splugins/-

tempalteO�.

156NSNC es el acrónimo de No Sabe No Contesta

320

Plugins con nombre propio

La mayor parte de los plugins con nombre propio son system plugins que desempeñan tareas

fundamentales para DFSU, es por tanto necesario comprender cómo actúan para de este modo

ser capaz de con�gurarlos adecuándolos a nuestras necesidades.

Del�n En la sección anterior hemos descrito a los Expert plugins como los encargados de

determinar si un determinado evento de tipo red o de tipo host es o no un ataque, dado que

en un sistema pueden convivir varios plugins expertos ¾que sucedería si varios expertos diesen

respuestas contradictorias sobre un mismo evento? aquí es donde entra Del�n.

Del�n debe su nombre a ser siempre el último plugin en ejecutarse, de este modo puede

recoger los veredictos del resto de plugins expertos que se han ejecutado antes que él y decidir

en base a su modo de funcionamiento que acción tomar, a continuación describiremos los modos

de funcionamiento distintos modos de funcionamiento de Del�n, resolviendo en cada caso el

siguiente ejemplo:

1. OR_MODE: Cuando este modo está activo basta con que uno de los expertos a�rme que

el evento en cuestión es un ataque para que delfín genere un evento de tipo alerta. Si este

modo fuese el modo activo en el momento en que se da la situación descrita en el Ejemplo

2: , Del�n generaría una única alerta con una descripción genérica.

2. FOREACH_MODE: En este caso, se generarán tantas alertas como plugins hayan a�r-

mado que el evento es un ataque. En el ejemplo propuesto Del�n generaría 3 alertas, cada

una de ellas con la descripción establecida por cada uno de los plugins expertos.

3. NAIVE_BAYES_MODE: Este es el modo más so�sticado de todos los implementa-

dos, su funcionamiento se basa en el empleo de una red Bayesiana de tipo Naïve, sin entrar

demasiado en detalle en el funcionamiento de una red Naïve, esta se fundamenta en proba-

bilidades condicionales, de cada uno de los expertos que han dado el veredicto con respecto

a la variable ataque157, por lo tanto ya no dependerá tanto del número de nodos que digan

que es un ataque sino de la �abilidad158 de estos. Se introduce de este modo un factor muy

interesante que es el de puntuación de los expertos o scoring, aquellos con una probabilidad

condicionada alta serán más �ables y por lo tanto mejores que otros que expliquen peor la

variable ataque.

157Empleamos la variable ataque que nos viene del agente de red para entrenar Del�n y obtener así unasprobabilidades condicionales lo más realistas posibles, para el caso de los agentes de syscalls el entrenamientodebería hacerse manualemente ya que no contamos con una variable ataque asociada a cada una de las traza desyscalls analizadas.158Fiabilidad en el mundo de las redes Naïve podría describirse como una probabilidad condicionada alta de que

dado el veredicto a�rmativo de un experto el evento en cuestión

321

Ejemplos de con�guración práctica Para con�gurar los modos antes explicados desde

la consola emplearemos el comando �cmd� tal y como se detalla a continuación:

En esta imagen pueden verse las opciones que nos da Del�n a través del comando cmd.

Figura 3.55: Del�n opciones de con�guración

Podemos modi�car el modo de funcionamiento mediante el comando mostrado en la �gura

sustituyendo el indicado por el que deseamos.

Para conocer el modo en el que está funcionando Del�n basta con ejecutar el comando de la

�gura.

Figura 3.56: Del�n cambiando el modo de funcionamiento

322

Figura 3.57: Del�n mostrando el modo de funcionamiento actual

Figura 3.58: Listado de modos de funcionamiento de Del�n

Este es el listado de modos con los que podemos con�gurar Del�n.

En esta imagen podemos ver la salida del plugin cmdOut mostrando en pantalla una alerta

generada por Del�n.

Conntrack Una de las secciones más importantes de DFSU es Conntrack, este plugin159 se

encarga de llevar un seguimiento a nivel de sesión, una sesión es en el caso de un monitor de

red cada una de las conexiones160 sobre las que está capturando datos, una conexión de red

se identi�ca por una clave privada compuesta por la dirección IP origen + puerto origen + IP

destino + puerto destino. En el caso de los monitores de host una sesión se identi�ca por la

máquina origen y el identi�cativo de proceso al que pertenecen las syscalls auditadas.

Conntrack implementa un algoritmo LRU161 con las últimas X sesiones 162 ordenadas en base

al número de eventos pertenecientes cada una de las sesiones y el timestamp del último evento

perteneciente a dicha sesión.

159Es un utility plugin, calcula datos para otros plugins160Nos referimos a conexiones lógicas no físicas, de ahí que conntrack también funciona con protocolos no

orientados a la conexión como UDP.161Least Frequently Used162Dentro de esta sesión Conntrack permite además guardar información de estado asociada a esta sesión como

por ejemplo el número de bytes transmitidos o el número de syscalls procesadas.

Figura 3.59: Del�n ejemplo de una alerta

323

En el siguiente apartado se explicará por qué esta información es tan importante para DFSU.

eforwarder Su función radica en escoger a que Tail al que hay que enviar la información

recogida desde el master, si conntrack es tan importante para DFSU es por que muchos expert

plugins tienen estado163 y si enviásemos por ejemplo la traza de syscalls de un determinado host

cada vez a un Tail distinto este sería incapaz de correlacionar la información de las primeras

syscalls con la de las siguientes pues estas nunca le llegaron. La información de conntrack nos

sirve para poder enviar la información de una misma sesión siempre al mismo tail.

163statefull expert plugins

324

Figura 3.60: eForwarder opciones de con�guración

Figura 3.61: eForwarder listado de modos

eForwarder al igual que Del�n dispone de varios modos de funcionamiento, a continuación se

describen brevemente:

1. MODE_ROUND_ROBIN: En este modo los eventos se envían de modo equitativo a

los Tails conectados. Si hubiera 2 Tails conectados, el primer evento se enviará al primer

Tail, el segundo al segundo Tail, el tercero al primer Tail otra vez, etc...

Es el modo óptimo desde el punto de vista del balanceo de carga ya que la diferencia de

eventos recibidos entre Tails será como máximo de uno.

2. MODE_BY_ORIGIN: Este modo envía todos los evento recibidos por un mismo mas-

ter al mismo Tail.

3. MODE_BY_PROCESS: Este modo envía todas las syscalls generadas por un mismo

proceso siempre al mismo Tail.

4. MODE_BY_USER: Este modo envía todas las syscalls generadas por un mismo usuario

siempre al mismo Tail.

5. MODE_BROADCAST: Duplica la información recibida desde los Masters a todos y

cada uno de los Tails suscritos.

Ejemplos de con�guración práctica Para con�gurar los modos antes explicados desde

la consola emplearemos el comando �cmd� tal y como se detalla a continuación:

Estos son los comandos con los que podemos comunicarnos con el plugin eForwarder.

Estos son los modos de con�guración posibles para eForwarder.

Este es el modo que está funcionando actualmente.

325

Figura 3.62: eForwarer mostrando el modo de funcionamiento actual

Figura 3.63: eForwarder cambiando el modo de funcionamiento

Esta es la forma de cambiar el modo de funcionamiento de eForwarder.

Stats Para controlar el rendimiento de la infraestructura DFSU cuenta con este System plugin,

su labor es llevar una estadística de las variables más relevantes, por ejemplo el número de eventos

recibidos y su tipo, el número de ataques, si se están produciendo drops etc...164, en la imagen

Figura 13: Stats, ejemplo de salida por pantalla podemos ver un ejemplo de la salida del comando

cmd Stats.

164Un drop consiste en descartar un paquete y tiene lugar cuando llega un evento para el que no hay sitio en lascolas.

326

Figura 3.64: Stats, ejemplo de estadisticas de sistema.

Servidor Web Integrado

Uno de los mayores aciertos de DFSU fue integrar un servidor web dentro de la propia

infraestructura, gracias a este servidor al que bautizamos WebOs DFSU cuenta con las siguientes

ventajas:

1. Fácil diseño de interfaces: Al haber programado WebOs desde 0 pudimos adecuar su

diseño perfectamente a nuestras necesidades, una de las ventajas que obtuvimos fue poder

controlar cuando comienza y cuando acaba una petición web de manera que podemos

recoger ordenes desde los CGI165 y así permitir que una interfaz escrita en HTML tenga

acceso directo a una API166 en XML desde la que ejecutar comandos dentro de DFSU

(carga de plugins, descarga etc...). Además al permitir programar en perl, un lenguaje que

conocen muchos administradores de sistemas, permitimos que la gente pueda desarrollar

sus propias interfaces grá�cas sin tener que recompilar DFSU y sin tener que meter una

sola línea de C++.

2. Arquitectura C/S: Al ser una arquitectura cliente/servidor el administrador puede con-

�gurar la arquitectura de DFSU desde cualquier terminal conectado a la red.

3. Independencia de plataforma: La tecnología web es una tecnología estandarizada que

permite a cualquier sistema que tenga programado un navegador compatible acceder a

cualquier web. Algo que no puede decirse de las interfaces web convencionales.

165Common Gateway Interface166Application programming interface

327

3.3.8. DFSU primeros pasos

¾Cómo conseguir el código?

DFSU es software libre y como todo programa de software libre tiene su sitio en sourceforge167,

concretamente en la siguiente url: http://dfsu.sourceforge.net

Además puede visitar la web de DFSU en www.dfsu.net donde además de informarse sobre

las últimos cambios puede unirse a las distintas listas de distribución:

Usuarios: [email protected]

Administradores: [email protected]

Developers: [email protected]

Licencia

Como ya se ha mencionado con anterioridad DFSU se enmarca dentro del gran proyecto que

es el software libre y como es lógico empleamos licencias libres. El código de DFSU está licenciado

bajo GPL y la memoria que ahora está leyendo está licenciada bajo Creative Commons.

DFSU sigue una política parecida a la del Kernel de Linux en materia de licencias y es que

DFSU usa y apoya explícitamente licencias sin embargo no las forzamos, si un programador o

empresa desea desarrollar plugins para DFSU, no sólo puede hacerlo sino que además puede

elegir la licencia que más le convenza, lo que lógicamente incluye licencias privativas y/o de

código cerrado.

Estructura de directorios

Lo primero que se debería conocer perfectamente es la estructura de directorios en que se

compone el proyecto con el �n de poder localizar y con�gurar lo más e�cientemente posible la

opciones necesarias.

Los tres elementos de la infraestructura comparten una jerarquía de directorios muy similar

con la que cualquier administrador de sistemas Unix like se sentirá muy familiarizado. En el

directorio raíz de esta jerarquía se distinguen las carpetas �src� para los �cheros fuente, �doc�

para los �cheros de documentación, �etc� para los �cheros de con�guración, �lib� para las librerías

y �bin� para los binarios.

A continuación expandiremos uno por uno los directorios expuestos anteriormente:

Estructura de la raíz del proyecto

dfsu: Esta es la rama principal de donde cuelgan la estructura de directorios del Head,

Tail y Masters.

167http://www.sourceforge.net

328

• dfsu/Head: Contiene todos los �cheros fuentes de este elemento de la estructura.

• dfsu/Tail: Contiene los mismos �cheros y estructura que la carpeta anterior estando

la diferencia en los datos de los �cheros de con�guración.

• dfsu/Masters: Es la raíz de donde parten los Masters implementados.

◦ Masters/snortMaster

◦ Masters/syshooker

329

Estructura de directorios en el Head y en el Tail

Head/src: Agrupa todos los �cheros fuentes de la infraestructura proyecto.

• src/includes: Contiene las cabeceras de los fuentes que se encuentran en �src�.

• src/eplugins: Carpeta para almacenar los plugins expertos.

• src/oplugins: Carpeta para guardar los plugins de respuesta.

• src/splugins: Carpeta con los plugins del sistema.

• src/uplugins: Carpeta que contiene los plugins de utilidad.

• src/webos: Aquí se encuentran todos los �cheros que conciernen al servidor web

WebOs.

◦ src/webos/src: Aglutina todos los �cheros fuente que forman el servidor web.

◦ src/webos/etc: Contiene el �chero de con�guración del servidor web �webos.xml�.

◦ src/webos/htdocs: Contiene los documentos que utiliza el servidor web para

presentar la página inicial además de una estructura propia de directorios con

todo lo necesario para la edición de la interfaz web.

� htdocs/cgi-bin: Carpeta que contiene los scripts ejecutables en perl.

� htdocs/xml: Contiene el �chero �hirearchy.xml� donde se especi�ca la jerar-

quía que se visualizará en el menú que aparece en la izquierda en la interfaz

web.

� htdocs/images: Carpeta donde se encuentran las imágenes que se muestran

en la interfaz.

� htdocs/inc: Contiene los �cheros que forman la cabecera, en pie de página

y el menú a incluir en las páginas que se quieran desarrollar.

� htdocs/static: Contiene los �cheros html �jos que forman la página web que

se muestra.

� htdocs/stylesheet: Ficheros .css que contienen los estilos a utilizar.

� htdocs/vars: Ficheros variables que se generan en cada sesión.

◦ src/webos/logs: Carpeta donde el servidor web deja los logs generados.

Head/etc: Contiene los �cheros de con�guración más importantes slaveconf.xml y oa-

conf.xml.

Head/bin: Contiene los ejecutables, tanto del programa como el compilador de plugins

que más adelante se detallará.

Head/doc: Contiene la documentación al completo de DFSU.

330

Head/lib: Contiene la librería estática en la que se compilan todos los objetos que se

encuentran en la carpeta �src�.

Head/logs: Carpeta donde se guardan los logs del sistema.

Head/sessions: Carpeta donde se guarda un xml con un resumen de la sesión con infor-

mación proporcionada por los plugins del sistema, como el número de ataques detectado.

331

Estructura de directorios en el Master Syshooker

Dado que este Master se compone, como ya se ha explicado, de dos aplicaciones existen dos

directorios base para cada una de ellas:

dfsu/syshooker: Es el nombre del directorio raíz, y de aquí parte la estructura de las dos

aplicaciones.

• syshooker/hookermaster: Este es el módulo que se encarga de capturar las syscalls

del sistema para que las recoja la aplicación cliente. No tiene una estructura interna

de directorios por el reducido número de �cheros que lo componen.

• syshooker/hookerclient: La aplicación cliente se encuentra a partir de este directo-

rio. Además aquí podemos encontrar los �cheros para compilar y ejecutar la aplicación.

◦ hookerclient/bin: En esta carpeta es donde se encuentra el archivo ejecutable.

◦ hookerclient/etc: Contiene el �chero de con�guración �mastercon�g.xml�, donde

se han de con�gurar los parámetros para la conexión como más adelante veremos.

◦ hookerclient/lib: Contiene la librería estática donde compilan todos los objetos

del programa.

◦ hookerclient/src: En esta carpeta se encuentran los �cheros fuentes de la apli-

cación.

� src/includes: Contiene las cabeceras de los �cheros fuentes arriba mencio-

nados.

Estructura de directorios en el Master Snort modi�cado

Dado que la gran mayoría de esta aplicación es externa al proyecto DFSU, únicamente ex-

plicaremos dónde y que se encuentra en las modi�caciones añadidas.

snortMaster/src/dfsu: En esta carpeta es donde se encuentran los �cheros fuentes de la

aplicación.

Compilación e Instalación de una instancia de DFSU

Para realizar la instalación y la compilación de DFSU han de seguirse unos pasos y se necesitan

ciertos paquetes de los que se depende los cuales vienen detallados en esta sección.

Se ha intentado que el número de dependencias sea el menor posible para facilitar al máximo

este proceso.

332

Compilación e Instalación

Este apartado se encuentra dividido en tantas partes como de ellas se compone DFSU. Al

principio de cada una de ellas se hará un repaso de los paquetes que se necesitan tener instalados

para poder compilar el programa.

Ya que DFSU está escrito en c++ y la compilación se lleva a cabo mediante el comando

make, necesitaremos tener instalado una versión de g++-3.3 o superior así como una versión de

automake.

Compilación e instalación del Head y el Tail En el �chero �INSTALL� que encontraremos

en la raíz de la estructura de directorios se nos indican las dependencias de los paquetes necesarios

para poder realizar una compilación satisfactoria. Los paquetes en cuestión son los siguientes:

1. LibXML2: http://xmlsoft.org/

2. ReadLine: http://cnswww.cns.cwru.edu/�chet/readline/rltop.html

3. Libncurses5-dev:

4. Perl: libxml-simple-perl

Una vez instalados estos paquetes, bien en su forma binaria, bien desde las fuentes tenemos todo

lo necesario para poder construir DFSU, a continuación se explica cómo:

Abriremos una consola y nos posicionaremos en la raíz del árbol de directorios de DFSU, una

vez ahí entraremos en la carpeta �dfsu/Head�, donde ejecutaremos el siguiente comando:

$ make

Una vez que el comando haya terminado, podremos entrar dentro de la carpeta �dfsu/Head/bin�

y comprobar que existe el ejecutable �dfsu/Head/bin/slave�.

Compilación e instalación del Snort Modi�cado Para compilar este agente debemos tener

instalada la librería Libpcap. Una vez la tengamos instalada nos situaremos en la carpeta raíz

�snortMaster/� y ejecutar los siguientes comandos:

1. $ ./con�gure

2. $ make

Finalmente para llevar a cabo la instalación se ejecutara el comando:

3. $ make install

333

echo trivialExpert

1 sh p++.sh ../src/eplugins/trivialexpert/ trivialexpert

echo cmdOut

2 sh p++.sh ../src/oplugins/cmdout/ cmdout

Cuadro 3.10: Fichero de compilación compileAll.sh

Compilación e Instalación del Syshooker Para compilar el módulo del kernel Syshooker

necesitará tener un kernel compilado a mano que puede conseguir en http://www.kernel.org.

Una vez descargado y recompilado con las opciones básicas entre en la carpeta donde se

encuentra el syshooker y ejecute las siguientes instrucciones:

1. $ make

Tras la ejecución de este comando se construirá el módulo del kernel, �chero .ko, el cual

podrá insertar dentro del núcleo con el siguiente comando:

2. $ insmod syshooker.ko

Compilación e Instalación de los Plugins Para la compilación de los plugins tenemos dos

herramientas disponibles en la carpeta �bin/� que se encuentra en la raíz de Head y del Tail.

Estas herramientas son scripts de consola; el �p++.sh� y el �compileAll.sh�.

Cuando se dispone de un número bajo de plugins lo mejor es editar el segundo �chero que

contiene lo siguiente:

Vemos como este script básicamente lo único que utiliza es el �p++.sh� pues es el que se

encarga realmente de compilar los plugins.

En caso de no querer utilizar este �chero lo único que necesitaremos hacer es copiar la linea

marcada con un 1 o la linea marcada con el 2 y cambiar la ruta y el nombre del plugin que

deseamos compilar.

Una vez compilados, solamente necesitaremos incluirlos en el �chero �oaconf.xml� para que

sean cargados en el sistema.

3.3.9. DFSU con�guración y puesta en marcha de una instancia

Comprendiendo los �cheros de con�guración

La mayoría de los elementos con�gurables en el sistema disponen de un �chero en el cual

se indica la con�guración elegida. Éstos están en formato xml por ser el estándar de facto por

excelencia para el intercambio de información y se encuentran validados mediante un DTD, por

lo que es importante no modi�car su estructura.

334

Hay que tener en cuenta, que si bien el Master y los plugins son aplicaciones cada una

independiente de la otra, el programa que ejecutado en el Head y en el Tail es el mismo estando

con�gurado de modo diferente. Ésto puede ser indicador de la gran importancia de conocer a

fondo las funciones y posibilidades de cada �chero.

Ficheros del Head y de los Tails

Son tres los �cheros con�gurables en el Head y el Tail: �slaveconf.xml� , �oaconf.xml� y

�webos.xml�. A continuación se explica su descripción interna y la ruta donde se encuentran:

slaveconf.xml Es el �chero de con�guración maestro tanto para los Head como para los Tail.

Todos los puntos comentados aquí sirven tanto para el Head como para el Tail, a no ser que se

especi�que explícitamente lo contrario.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE dfsu_slave SYSTEM "slaveconf.dtd">

<dfsu_slave>

1 <workAsHead value="no"/>

2 <name value="Tail1"/>

3 <verbose value="no"/>

4 <debug value="no"/>

5 <logPath value="etc/"/>

6 <webosPath2Con�g value="src/webos/etc/webos.xml"/>

7 <oaPath2Con�g value="etc/oaconf.xml"/>

8 <queuesSize value="500"/>

9 <tentacleTimeOut value="15"/>

10 <maxMasters value="15"/>

11 <maxTails value="15"/>

12 <headIp value="192.168.0.1"/>

13 <headBeaconPort value="4320"/>

14 <localBeaconPort value="4320"/>

15 <localTCPPort value="4320"/>

</dfsu_slave>

Cuadro 3.11: Fichero slaveconf.xml del Head y del Tail

335

workAsHead: La primera etiqueta es posiblemente la más importante de todas, ya que

de�ne el comportamiento interno de la aplicación, variando de Head a Tail según pongamos

�yes� o �no� respectivamente

En el caso de escoger �yes� las etiquetas 2, 12 y 13 carecen de sentido. El Head siempre

tiene como nombre �Head�.

name: La etiqueta name se utilizará para identi�car a los diferentes Tails que se conecten y

la única restricción en este campo es que no puede tener el valor �Head�. En caso contrario

no podrá conectarse

En el caso de escoger �no� da igual lo que se ponga en la etiqueta 6 y 11.

verbose: Muestra por la consola existente, más información sobre lo que está ocurriendo

en la infraestructura.

debug: Muestra información útil únicamente para desarrolladores del sistema.

logPath: Ruta donde se guardarán los �cheros de log.

webosPath2Con�g: Es la ruta donde se encuentra el �chero de con�guración del servidor

web integrado WebOs, que más adelante se detallará.

oaPath2Con�g: Especi�ca la rula a uno de los �cheros de con�guración más importantes.

En él se almacena toda la información referente a los plugins que deben ser cargados en el

sistema.

queuesSize: Indica cual es el número máximo de eventos que puede haber dentro de una

cola del sistema. Es importante no dar un valor reducido pues la infraestructura necesita

un margen para poder funcionar correctamente.

tentacleTimeOut: Es el tiempo que se esperará antes de desconectar desde la ultima

recepción o envío satisfactorio al Head en el caso del Tail o de los Masters y Tails en el

caso del Head.

maxMasters: Es el número máximo de masters que se pueden conectar.

maxTails: Es el número máximo de Tails que se pueden conectar.

headIp: Cuando funcionamos como Tail, es esta la ip a la que nos intentaremos conectar

cuando se arranque la aplicación.

headBeaconPort: Operando como Tails, este será el puerto al que se envíe la información

de control.

localBeaconPort: Puerto por el que se escuchará la información de control.

336


<!DOCTYPE plugins SYSTEM "oaconf.dtd">

<plugins>

1 <plugin>

2 <loadOnBoot value="yes" />

3 <name value="CmdOut" />

4 <precedence value="1" />

5 <absPath value="src/oplugins/cmdout/cmdout.so"/>

6 <subscriptionList>

7 <EID value="5"/>

8 <EID value="0"/></subscriptionList>

9 <path2con�g value=""/>

10 <enabledOnBoot value="yes"/>

</plugin>

</plugins>

Cuadro 3.12: Fichero oaconf.xml del head y del tail

localTCPPort: Puerto por el que se esperarán conexiones entrantes provenientes del Head

si funcionamos como Tail o de Masters si funcionamos como Head.

oaconf.xml

loadOnBoot: Especi�ca si el plugin se cargará en memoria al inicio del programa.

plugin: Los datos de carga de cada plugin vienen indicados dentro de esta etiqueta, por

lo que en caso de querer añadir nuevos plugins bastará con repetir el bloque <plugin>,

(como en el ejemplo), entre la etiqueta <plugins>.

name: Es el nombre con el que aparecerá el plugin en los listados una vez se esté ejecutando

la aplicación.

precedence: Indica cual será el orden en el que se llamará a el plugin pero existen unos

límites en el valor de la precedencia para asegurar que ciertos plugins del sistema se ejecutan

los primeros y los últimos. Puede haber plugins con la misma precedencia.

La máxima precedencia es 1, y la mínima 1000.

absPath: Ruta absoluta hasta el �chero compilado como librería.

337


<!DOCTYPE weboscon�g SYSTEM "weboscon�g.dtd">

<weboscon�g>

1 <ip>127.0.0.1</ip>

2 <index_page>index.pl</index_page>

3 <htdocs_dir>src/webos/htdocs/</htdocs_dir>

4 <max_requests>100 </max_requests>

5 <port>81 </port>

6 <user>www-data </user>

7 <perl_executable>/usr/bin/perl</perl_executable>

8 <log�le>src/webos/logs/access.log </log�le>

9 <cgi_pattern>.pl </cgi_pattern>

10 <hostname>titania </hostname>

11 <max_age>3</max_age>

</weboscon�g>

Cuadro 3.13: Fichero webos.xml del Head y del Tail

subsCriptionList: Es el listado de eventos a los que se desea que se suscriba el plugin

para que se le llame cuando se den. El listado de eventos y su valor lo podemos consultar

en el �chero: �src/includes/eid_table.h�.

EID: Indica un evento al que se suscribirá el plugin. Para suscribir el plugin a más de un

evento basta con repetir esta etiqueta cambiando el valor del atributo �valor�.

path2con�g: En caso de que el plugin tenga un �chero de con�guración propio será aquí

donde indiquemos la ruta hasta su �chero.

enabledOnBoot: A pesar de estar cargado, un plugin puede estar deshabilitado por lo

que no se le llamará cuando se de uno de los eventos a los que se ha suscrito.

webos.xml

ip: En el caso de existir varias interfaces, se le puede indicar al servidor por cual de ellas

queremos que quede a la escucha.

index_page: En caso de no indicarle en el navegador el �chero al que queremos acceder,

buscará el �chero que pongamos aquí para mostrar su información.

htdocs_dir: Es la ruta donde encontrará todos los documentos necesarios para la visua-

lización correcta de las páginas.

338

1 make

2 rmmod syshooker

3 insmod syshooker.ko sysCallTable=322395980

8

Cuadro 3.14: Fichero reload.sh del Syshooker

max_requests: Para evitar en lo posible una ataque de denegación de servicio, es posible

indicar el número máximo de peticiones que se pueden atender simultáneamente.

port: Puerto por el que quedará a la escucha el servidor web.

perl_executable: Ruta hasta el interprete de perl que deseamos utilizar.

log�le: Ruta del �chero donde se dejarán los mensajes de log.

cgi_pattern: Es la extensión que tendrán los �cheros que deseamos que sean ejecutados.

hostname: Es el nombre de nuestra máquina.

max_age: Para evitar que el servidor web se quede bloqueado debido a la ejecución de

un script que consuma muchos recursos debido a bucles in�nitos podemos especi�car el

tiempo máximo de ejecución que tiene un script.

Ficheros de los Masters

Al igual que el Head y los Tails, los Masters disponen de sus propios �cheros de con�guración

con los que les indicaremos los datos necesarios para su funcionamiento.

Syshooker Este Master se compone de dos aplicaciones, un LKM que se encarga de capturar las

syscalls generada por los procesos en ejecución, y un programa cliente que recibe esa información,

la procesa y la transmite al Head.

Existen pues dos �cheros que deberemos con�gurar, �reload.sh� y �mastercon�g.xml�.

339


<!DOCTYPE dfsu_master SYSTEM "mastercon�g.dtd">

<dfsu_master>

1 <name value="Master1"/>

2 <tentacleTimeOut value="3"/>

3 <headIp value="172.26.0.2"/>

4 <headTCPPort value="4320"/>

</dfsu_master>

Cuadro 3.15: Fichero mastercon�g.xml del Syshooker

Este primer �chero no es más que un script para cargar el módulo que recoge las syscalls

en el sistema operativo de la máquina. El parámetro que se debe modi�car se encuentra en la

línea tres, y es el número que aparece después de �sysCallTable=�. Para obtener dicho número

deberemos ejecutar el comando:

$ cat /boot/System.map |grep sys_call_table

que retornará un valor similar al siguiente:

C0484700 D sys_call_table Este valor es la dirección de memoria en hexadecimal

donde el kernel ubica la tabla de syscalls, deberemos por tanto convertirla a decimal.

El �chero �mastercon�g.cfg� tiene las líneas de con�guración que se explican a continuación:

name: Es el nombre con el que se identi�cará al Master.

tentacleTimeOut: Este valor indica cuanto tiempo pasará antes de desconectarse y volver

a conectarse al Head desde la ultima recepción o el último envío de datos.

headIp: Como su propio nombre indica, aquí se especi�ca la dirección de Red de la máquina

en la que se está ejecutando el Head.

headTCPPort: Es el campo donde hay que poner el puerto de escucha del Head para que

la conexión sea posible.

Snort Modi�cado Este Master dispone de dos �cheros de con�guración, �dfsumcon�g.cfg� y

�run.sh�. En el primer de ellos especi�caremos los datos necesarios para que el Master pueda

encontrar el Head y establecer la conexión:

340

1[SLAVE]

2 IP=127.0.0.1

3 PORT=4320

4 BUFFERSIZE=500

5 NAME=Master2

Cuadro 3.16: Fichero dfsumcon�.cfg del Snort Modi�cado

src/snort -i eth2 -l /tmp/ -c etc/snort.conf -j dfsumcon�g.cfg -A console

Cuadro 3.17: Fichero run.sh del Snort Modi�cado

Su funcionamiento es muy simple ya que únicamente hay que editar las lineas 2 y 3 e indicar la

dirección de red y el puerto de la máquina que contiene el Head.

En el segundo �chero solamente lo modi�caremos para especi�car la interfaz por la que se

monitorizará el trá�co de red.

Escogiendo la estructura óptima

Es muy importante escoger bien la estructura que mejor se adapte a nuestras necesidades

en pos de obtener el mínimo coste. En caso de no estar seguros sobre cual es la más adecuada,

empezar por una estructura de tres capas con uno o dos Tails es lo más recomendable.

Mediante los indicadores de sobrecarga del sistema visibles en la interfaz web determinaremos

si necesitamos más capacidad de cálculo o no. En caso a�rmativo el procedimiento a seguir

para solucionar el problema será el de ir añadiendo Tails de forma progresiva hasta lograr un

rendimiento adecuado.

Con�gurando el Master, el Head y el Tail

Una vez escogida la estructura que deseamos implementar en nuestra red, deberemos con�-

gurar el Head y los Tails correctamente. A continuación se explicarán con detalle todos los pasos

que se han de llevar a cabo para poner en funcionamiento la estructura de DFSU.

Ejemplo de conexión paso a paso

Al igual que en la hostelería, qué mejor método para explicar cómo llevar a cabo una tarea que

un ejemplo. Es por ello que en los siguientes pasos se creará una estructura completa, compuesta

de los siguientes ingredientes:

Un master de Host

Un master de Red

341

Un Head

Un Tail

Para este ejemplo se han utilizado tres máquinas, siendo cada una de ellas uno de los elementos

de la estructura, (Master, Head y Tail).

Así pues en la primera máquina hemos colocado tanto el Master de Red como el de Host, en

la segunda el Head y en la Tercera el Tail.

342

Editando los �cheros de con�guración

Como ya aprendimos en la sección de con�guración, los primeros �cheros que hemos de editar

son �slaveconf.xml� para el Head y el Tail, �dfsumcon�g.cfg�, �run.sh� para el Master de Snort

modi�cado y �mastercon�g.xml� para el Master de Host.

Lo primero que se debe saber, para poder entender las con�guraciones elegidas en los �cheros

de ejemplo, son los datos de red que tienen las máquinas que albergan los diferentes elementos:

Con�guración de la máquina que contiene los MastersDirección de Red: 192.168.0.1

Máscara de Subred: 255.255.255.0

Dirección de Red eth2: 192.27.0.15

Máscara de Subred eth2: 255.255.255.0

Con�guración máquina que contiene el HeadDireccion de Red: 192.168.0.2


Con�guración de la máquina que contiene los TailsDirección de Red: 192.168.0.3


En caso de existir alguna duda sobre los datos que se han con�gurado en los �cheros, es

recomendable volver a la sección Comprendiendo los �cheros de con�guración.

Los campos más importantes que han sido modi�cados para poder realizar la conexión se

encuentran en negrita y los campos que no tienen sentido según se funcione como Head o como

Tail carecen de contenido.

Con�guración del Master

1. Fichero �dfsumcon�g.cfg�:

Los parámetros más importantes que debemos indicar son la dirección de red y el puerto

de la máquina en la que se encuentra escuchando el Head.

2. Fichero �run.sh�:

En este �chero hemos con�gurado el Snort modi�cado de manera que capture el trá�co

que llega por la interfaz 2. La conexión hacia el Head se está lanzando por la interfaz de

red eth1.

343

[SLAVE]

IP=127.0.0.1

PORT=4320

BUFFERSIZE=500

NAME=Master2

Cuadro 3.18: Ejemplo de con�guración del �chero dfsumcon�g.cfg del Snort Modi�cado

src/snort -i eth2 -l /tmp/ -c etc/snort.conf -j dfsumcon�g.cfg -A console

Cuadro 3.19: Ejemplo de con�guración del �chero run.sh en el Snort Modi�cado

Con�guración del �chero �mastercon�g.xml� Vemos que este master se identi�cará

como �Master1� y se intentará conectar a la ip y puertos que hemos con�gurado en la máquina

donde se está ejecutando el Head.


<!DOCTYPE dfsu_master SYSTEM "mastercon�g.dtd">

<dfsu_master>

<name value="Master1"/>

<tentacleTimeOut value="3"/>

<headIp value="192.168.0.2"/>

<headTCPPort value="4320"/>

</dfsu_master>

Cuadro 3.20: Ejemplo de con�guración del �chero mastercon�g.xml en el Syshooker

Con�guración del �chero �slaveconf.xml� del Head

En el Head, lo más importante a de�nir en su �chero de con�guración es el primer campo, donde

se especi�ca que funcionará como tal, y los campos de los puertos. A pesar de que en el ejemplo

los puertos BeaconPort y TCPPort son iguales, no es obligatorio que sea de ésta manera.

Con�guración del �chero �slaveconf.xml� del Tail Además del primer campo que

de�ne su funcionamiento como Tail, es muy importante el campo del nombre y los campos de

conexión. Existe una restricción en los nombres que se asignan a los Tails y por el cual el Head

puede prohibir la conexión: El Head no dejará conectarse a un Tail si ya existe una conexión con

otro que tenga el mismo nombre con�gurado o si por nombre lleva la palabra �Head�.

En este punto ya tenemos correctamente con�gurados todos los elementos del sistema para

que la conexión sea posible. Los �cheros de con�guración de los plugins aún no los hemos con�-

344



<dfsu_slave>

<workAsHead value="yes"/>

<name value=""/>

<verbose value="no"/>

<debug value="no"/>

<logPath value="logs/"/>

<webosPath2Con�g value="src/webos/etc/webos.xml"/>

<oaPath2Con�g value="etc/oaconf.xml"/>

<queuesSize value="500"/>


<maxMasters value="15"/>

<maxTails value="15"/>

<headIp value=""/>

<headBeaconPort value=""/>

<localBeaconPort value="4320"/>

<localTCPPort value="4320"/>

</dfsu_slave>

Cuadro 3.21: Ejemplo de con�guración del archivo slaveconf.xml en el Head

345



<dfsu_slave>

<workAsHead value="no"/>

<name value="Tail_1"/>

<verbose value="no"/>

<debug value="no"/>

<logPath value="logs/"/>

<webosPath2Con�g value=""/>

<oaPath2Con�g value="etc/oaconf.xml"/>

<queuesSize value="500"/>


<maxMasters value="15"/>

<maxTails value="15"/>

<headIp value="192.168.0.2"/>

<headBeaconPort value="4320"/>

<localBeaconPort value="8000"/>

<localTCPPort value="8000"/>

</dfsu_slave>

Cuadro 3.22: Ejemplo de con�guración del �chero slaveconf.xml en el Tail

346

gurado pues lo primero es asegurarnos de que la estructura está operativa. Más adelante veremos

como con�gurar y detectar un ataque de manera detallada.

Lanzando las aplicaciones Pasemos ahora a lanzar las aplicaciones una a una:

Lanzando el Head La Figura 3.65 muestra el resultado que deberemos obtener una vez que

hayamos lanzado las aplicaciones en el siguiente orden:

1. Lanzamos el Head: Para esto utilizamos el comando �$ sh run.sh� en la carpeta �Head/�.

2. Lanzamos los Masters: En la máquina donde hemos colocado los Masters ejecutamos

sin importar cual de ellos se lance primero los siguientes comandos:

a) �snortMaster/�: �$ sh run.sh�

b) �syshooker/�: �$ sh run.sh�

3. Lanzamos el Tail: En la máquina donde tenemos el Tail, en el directorio raiz �Head/�

ejecutamos el comando �$ sh run.sh�.

Figura 3.65: Head con un tail y dos masters conectados

347

Figura 3.66: Plugins cargados en el Head

Figura 3.67: Plugins cargados en el Tail

Comprobando que todo funciona bien Lo primero que comprobaremos es que la carga de

los plugins cmdOut y TrivialExpert ha sido realizada en el Head y en el Tail respectivamente.

Para ésto ejecutaremos el comando �ls -all� en las dos aplicaciones:

Aquí vemos como efectivamente en el Head el plugin cargado es el cmdOut y cómo el Trivia-

lExpert se encuentra descargado.

No debe confundirnos el hecho de que el valor de �ENABLED� sea �YES� pues sólo se tiene

en cuenta una vez que el plugin se encuentra cargado.

En el Tail deberá aparecernos los contrario a lo que hemos visto en la imagen Figura 3.66:

Plugins cargados en el Head, encontrándose cargado el TrivialExpert y el cmdOut descargado.

348

Figura 3.68: Visualización de las alertas en el Head

Si ésto es correcto, entonces en la terminal de consola donde hemos ejecutado el Head deberían

estar apareciendo alertas como las de la siguiente �gura:

Resumiendo Hasta ahora hemos con�gurado y conectado dos Masters, un Head, un Tail

y se han generado alertas por los eventos recibidos desde los Masters.

Por si queda alguna duda se dará ahora una breve explicación de lo que ha pasado en el

sistema, empezando por recordar algunos aspectos del funcionamiento de cada elemento de la

estructura:

1. En el momento en el que los Masters se conectan al Head, éstos empiezan a enviarle datos

que están capturando.

2. Por defecto en el �chero �oaconf.xml� del Head viene activo el plugin cmdOut que se encarga

de mostrar las alertas que llegan desde los Tails.

3. Por otra parte en el Tail el plugin TrivialExpert, que está activo de forma predeterminada,

trata a todo evento recibido como si fuese maligno.

Por lo tanto, en el momento en el que hemos conectado los Tails y los Masters al Head se han

empezado a generar alertas.

349

3.3.10. DFSU descripción de las interfaces

Habitualmente se utilizan dos tipos de interfaces, las grá�cas y los interpretes de comando.

Por lo general las interfaces grá�cas son más intuitivas y visuales pero carecen de la potencia

que proporciona un interprete de comandos.

Para no perder ninguna de las ventajas que cada interfaz aporta decidimos implementar en

DFSU los dos tipos. La interfaz grá�ca, que es opcional, es proporcionada por el servidor web

WebOs y el interprete de comandos se ejecuta de forma nativa cuando se arranca el sistema.

En este capítulo se explicarán las posibilidades que nos brindan éstas interfaces y como llevar

a cabo las tareas de mantenimiento y supervisión con su ayuda.

Interfaz Web: Servidor web integrado WebOs

El servidor WebOs solamente es posible activarla cuando se funciona en modo Head ya que

es aquí donde se concentra toda la información mostrada.

Presenta el siguiente aspecto:

Figura 3.69: Pantalla principal servidor WebOs

En la imagen Figura 1: Pantalla principal servidor WebOs se nos muestran de forma rápida

los elementos conectados al Head en cada momento (Masters y Tails) junto con su nombre, de

modo que podamos diferenciarlos.

En los grá�cos inferiores se muestra la carga que están soportando el Head y los Tails que

tiene conectado en la parte inferior mediante un grá�co que varía en tamaño y color.

350

En el menú de la izquierda se nos ofrece la posibilidad de navegar por las opciones que

incluyen tanto la documentación y manual de usuario como la información referente al proyecto.

351

Existe la posibilidad de hacer click sobre las burbujas del Head y los Tails con lo que se nos

mostrara la siguiente información:

Figura 3.70: Gra�co del sysload

Desde esta pantalla se visualiza toda la información necesaria para poder administrar remo-

tamente el Tail. Además de ver los plugins que aparecen en el �chero oaconf.xml del Tail en

cuestión, se sabrá el estado en el que se encuentran con la posibilidad de modi�carlo activando/-

desactivando, cargando y descargando.

Las estadísticas nos muestran el número y tipo de los paquetes recibidos y procesados por

el Tail, además de la carga del sistema. En el caso de que un Tail esté sobrecargado siempre se

puede desactivar el plugin más pesado hasta que se solucione el problema.

Figura 3.71: Pantalla de información grá�ca sobre el Tail

Por último se pueden modi�car algunos de los parámetros del �chero slaveconf.xml remota-

352

mente para que la próxima vez que se inicie el Tail se ejecute con la nueva con�guración.

Interfaz de comandos: La consola

La consola se encuentra activa tanto en el Head como en los Tails y desde ella podemos eje-

cutar todos los comandos implementados en la interfaz grá�ca además de otros que se detallarán

ahora.

Cuando se arranca la aplicación se nos muestra la pantalla de bienvenida Figura 4: Pantalla

de inicio de la consola y se nos da la posibilidad de empezar a ejecutar comandos.

En este ejemplo se nos informa de que se han arrancado los plugins TrivialExpert y cmdOut,

además de que estamos funcionando como Head y que el servidor Web esta funcionando en el

puerto 81.

Figura 3.72: Pantalla de inicio de la consola

Como toda consola, disponemos del comando �help� que nos ayudará en la tarea de admi-

nistración informándonos de cuales son nuestras posibilidades Figura 1: Panta de ayuda de la

consola.

Comandos sobre plugins: Al igual que en la interfaz web donde podemos ejecutar coman-

dos para administrar los plugins locales y remotos, según donde hiciéramos click, sobre el Head

(local) o sobre algún Tail (remoto), disponemos de los comandos �load�, �unload�, �enable� y �di-

sable� para administración local y �rload�, �runload�, �renable� y �rdisable� para control remoto.

La sintaxis es común para cada uno de los grupos, local o remoto, siendo la siguiente :

1. Locales: <comando><nombre-plugin>

353

2. Remotos: <comando><nombre-Tail><nombre-plugin>

Para conocer los plugins que hay en el sistema deberemos ejecutar el comando �ls -all�.

Además de éstos, disponemos de la posibilidad de enviar órdenes directamente a los plugins

utilizando el comando �cmd�.

Su sintaxis es: cmd <nombre-plugin><orden-para-el-plugin>

/newpage

Comando para el servidor WebOs:

Existe un comando dedicado a la gestión del servidor web:

Figura 3.73: Comandos de consola para webOs

webos <opción>:

• status: Muestra el estado en el que se encuentra el servidor , en ejecución o detenido.

• start: Inicia la ejecución del servidor web.

• stop: Detiene la ejecución del servidor web.

• restart: Detiene el servidor web si está en ejecución y vuelve a iniciarlo.

Comandos sobre Tails: Podemos controlar que Tails tenemos conectados mediante el

comando �ls -tails�, pudiendo además prohibir la conexión y listar quienes la tienen prohibida,

expulsar y readmitir mediante los comandos �ban�, �ls -banned �, �kick� y �unban� respectivamente.

El comando �kickban� ejecuta esas dos acciones consecutivamente.

354

Figura 3.74: Pantalla de ayuda de la consola

Como se muestra en la imagen, la sintaxis es común para las órdenes �ban�, �kick�, �unban�

y �kickban�: <comando><nombre-Tail>

Siempre que ejecutemos el comando �ls -banned� veremos por lo menos una entrada con el

nombre �Head�, pues como ya se ha comentado no se permite que ningún Tail se conecte con ese

nombre. No es posible ejecutar con éxito el comando �unban� sobre ese nombre.

Figura 3.75: Comandos de consola ls

Comandos de información general:

ls <opción>: Lista información útil que varía según el parámetro introducido

• ls -sall: Muestra el listado de plugins de sistema.

355

• ls -uall: Muestra el listado de plugins de utilidad.

• ls -oall: Muestra el listado de plugins de salida.

• ls -eall: Muestra el listado de plugins expertos.

• ls -all: Muestra un listado con todos los plugins que conoce el sistema.

• ls -masters: Muestra un listado con los Master conectados.

• ls -tails: Muestra un listado con los Tails conectados.

• ls -banned: Muestra un listado con los Tails que han sido baneados del sistema.

set [verbose|debug] [on|o�]: Con este comando podemos activar y desactivar el modo

verbose y debug que nos mostrarán más información de lo que ocurre por la consola.

mode: Muestra la información con la que está con�gurada el sistema Figura 1: Pantalla

de consola comando Mode. Puede variar de la que contiene el �chero �slaveconf.xml� si se

ha modi�cado alguno de los parámetros mediante comandos.

sys <comando shell>: Da la posibilidad de ejecutar un comando de una terminal como

sobre la que se ha lanzado la propia aplicación.

exit, quit: Finaliza la ejecución de la aplicación. También es posible �nalizar mediante la

combinación de teclas ctrl+c.

3.4. Análisis

Una vez determinada la relación de parámetros de detección que deberán formar parte del

análisis, y desarrollada la solución de recogida de información pertinente, dichos parámetros están

listos para ser introducidos en la fase de Análisis.

Como se enuncia en el capítulo 1, el objetivo primordial del presente estudio consiste en el

desarrollo de un método de análisis basado en Detección de Anomalías que reporte su conoci-

miento a motores de Detección de Firmas, de modo que el tiempo de procesado y comprobación

requerido sea el más óptimo posible para los terminales en los que se implante el sistema. A este

respecto, y dado que las Redes Bayesianas han sido utilizadas en proyectos semejantes para Sis-

temas de Detección de Intrusiones basados en Host[95], se va a plantear y desarrollar un modelo

que englobe, sustituya y mejore a las técnicas existentes [399, 305, 13, 215, 47, 207, 331, 244].

3.4.1. Modelo General Operativo

Como se desprende del enunciado de los objetivos operacionales descritos en el capítulo 1,

la consecución del �n último de la presente memoria pasa, en primer lugar, por la obtención de

un Modelo de Representación de Conocimiento. Éste, tomando en consideración el conjunto de

parámetros de detección enumerados en el apartados anteriores, hará uso de toda la potencia de

356

modelado e inferencia de las Redes Bayesianas. El objetivo principal es determinar la probabilidad

con la que pertenece al modelo de comportamiento del sistema operativo en estudio.

Para obtener la valoración �nal del comportamiento correcto o anómalo de una determinada

aplicación se va a hacer uso de las técnicas de Redes Bayesianas Dinámicas para evaluación de

cadenas o secuencias de llamadas al sistema junto con un análisis ponderado de los parámetros

asociados a cada llamada en particular haciendo uso del algoritmo Bayesian Merging [308].

El aprendizaje de estructura de la Red Bayesiana Dinámica como tal no es necesario, dado

que está claramente �jado en los papers revisados durante toda la memoria. Al �n y al cabo el

objetivo en esta parte es validar que la secuencia de syscalls, que se están produciendo, pertenece

a un modelo aprendido de comportamiento correcto o no. Posteriormente ese �experto�, entendido

como la parte que se encarga de dotar a la infraestructura de Inteligencia Arti�cial, generará una

regla procesable por la clase Cerebelum. Finalmente antes de acometerse una nueva investigación

mediante Inteligencia Arti�cial en la secuencia de llamadas, si se descubre una coincidencia dentro

de las reglas inferidas y aprendidas por la infraestructura de una situación marcada anteriormente

como anómala, será indicado directamente. De esta forma se consigue aglutinar la rapidez de los

Sistemas de Detección de Intrusiones basados en �rmas junto con la efectividad demostrada por

los Sistemas de Detección de Anomalías.

El administrador de la infraestructura podrá estudiar las reglas generadas por el motor de

Inteligencia Arti�cial y cambiarlas o ampliarlas acorde a su conocimiento experto, pudiendo in-

cluso obligar a la parte de IA a aprender esa regla como válida dentro del modelo de conocimiento

que tiene para una determinada aplicación.

3.4.2. Obtención de la Muestra Evidencial.

Se han desarrollado una serie de entidades software que se ocupan de la recogida en el

Sistema Operativo correspondiente de las llamadas al Sistema. Esta recogida se produce en la

forma comentada anteriormente y esos datos son enviados a la infraestructura DFSU desarrollada

para esta solución que se plantea. Una vez los paquetes llegan a la infraestructura son redirigidos

internamente hacia las entidades denominadas �tails�. Los Tails serán los encargados de trabajar

con el �ujo de información entrante que llega desde los Masters. En ellos es donde se despliegan

los expertos basados en IA o en reglas que se encargan de comprobar los �ujos de información

recibidos.

La infraestructura como se ha comentado tiene diferentes modos de funcionamiento, entre

ellos cabe destacar para la entrega de los mismos a los expertos los siguientes:

Modo BroadCast: Toda la información que entre en el sistema se distribuye por todos los

Tails.

Imaginando que se tiene un conjunto de terminales móviles de diferentes sistemas operativos,

la información que se obtenga será pasada en bloque a los diferentes Tails. Dentro de ellos

357

la información se repartirá acorde al tipo de evento al que estén suscritos estos expertos. El

comportamiento de la infraestructura en este caso sirve para poder tener diferentes expertos

repartidos por los tails que se encuentren disponibles, pero no es el más óptimo para la resolución

de la problemática planteada. Hay modos de funcionamiento mucho más precisos para la forma

de recogida de la información que se requiere.

Se indica que este modo no es el más óptimo dado que puede darse el caso de que existan

expertos suscritos a los Eventos de Host a los que llegaría la misma información y o bien se

encargan ellos de discernirlos para generar los diferentes modelos de conocimiento mediante

Redes Bayesianas Dinámicas o bien se procesarían los eventos recibidos varias veces.

Modo Usuario, modo origen, modo proceso y máquina.

Estos modos son los más adecuados a la funcionalidad deseada, dado que la infraestructura ha

sido diseñada para balancear carga y distribuir el procesado de los eventos que se introduzcan

al sistema. El bloque de información entra en el sistema y se va a distribuir acorde al modo de

funcionamiento en el que se encuentre. De esta forma se va a conseguir que cada Tail pueda

encargarse de lo acaecido en una máquina determinada, con un usuario concreto o de un origen

absoluto (denotar que la infraestructura no tiene intención de quedarse exclusivamente en la

Detección de Intrusiones basada en Host, si no que puede aceptar información de Red a la vez).

Esta forma de funcionamiento ha permitido el desarrollo e integración con la infraestructura

desarrollada en años anteriores por este equipo de investigación ESIDE-DEPIAN[42] encargada

del tratamiento de los eventos acaecidos en la red. El funcionar de esta manera permitirá la

correlación de eventos mediante clasi�caciones bayesianas entre Host y Red como se detallará el

Capítulo 4 de Conclusiones y Retos Futuros.

Continuando con el proyecto que ilustra esta memoria, el funcionamiento en esta serie de

modos hace posible que un sistema de análisis no se sobrecargue con la información de varios

Host's. Los eventos llegarán acorde a su origen, al usuario que haya efectuado los mismos (o sus

aplicaciones) incluso de diferentes sistemas operativos, o desde una máquina en concreto. Una

vez obtenido el �ujo de la forma deseada se discriminará basándose en la aplicación que haya

realizado una u otra llamada, de forma que los expertos inteligentes puedan aprender de la forma

correcta el modelo de comportamiento de la misma.

Las evidencias de host mantienen en su interior información sobre los siguientes campos:

Listing 3.23: De�nición de la clase hEvent

#define TOH_LINUX 0

2 #define TOH_WINDOWS 1

#define TOH_WINMOV 2

#define TOH_SYMBIAN 3

typedef struct MHEventHeader_

{

358

7 uint8_t toh ;

uint32_t numArgs ;

time_t etStamp ;

}MHEventHeader ;

12 typedef class hEvent

{

MHEventHeader mheh ;

bool e r r o r ;

char∗ data ;

17 int dataS ize ;

Argument∗ args ;

public :

void i n i t (char∗ data , int dataSize_ ) ;

22 bool i sE r r o r ( ) ;

char∗ getData ( ) ;

int getDataSize ( ) ;

void setDataNul l ( ) ;

int getNumArgumens ( ) ;

27 Argument∗ getArgument ( int numArg) ;

uint8_t getTypeOfHost ( ) ;

time_t getArrivalTimeStamp ( ) ;

char∗ marsha l l ( int∗ t S i z e ) ;

32 hEvent (char∗ data , int dataSize_ ) ;

~hEvent ( ) ;

} ;

En la de�nición anterior se observa la información a la que van a tener acceso los diferentes

plugins o �expertos� dentro de la infraestructura. Básicamente se divide por el tipo de sistema

operativo sobre el que está puesto el interceptor de las llamadas (syscalls):

Linux

Windows

Windows Mobile

Symbian

359

Posteriormente se de�ne el número de argumentos. Esta parte es importante para poder dimen-

sionar el experto basado en IA (Redes Bayesianas Dinámicas junto con Bayesian Merging) y

empezar a crear el posible modelo que va a dar cabida a este tipo de información. Por cada

argumento se deberá crear un objeto Bayesian Merging que se encargará del modelado de cada

parámetro que acompañe a la llamada al sistema. Finalmente se tiene el �timestamp�, el momento

temporal de la captura, para poder relacionar en la línea de tiempos cuándo se han producido

las diferentes llamadas al sistema.

Fuera de la parte de cabecera que ayuda y simpli�ca a la creación y mantenimiento de los

modelos se tiene el resto de parámetros de la clase Evento de Host, como pueden ser el valor de

retorno, el valor del error producido y la sucesión de argumentos propiamente dicha.

3.4.3. Aprendizaje e Inferencia de Expertos Mendizale

Una vez obtenidos los datos se procederá a realizar el estudio que permita adecuarse de la

manera más plausible posible a los requerimientos especi�cados. La primera fase es el aprendizaje

de los argumentos y su escalado para introducirse dentro del Modelo de Comportamiento general.

Se va a partir de un ejemplo de captura de un terminal Windows Mobile 2005 y en base al

mismo se va a desarrollar la forma en la que se manipula la información en el presente proyecto.

En este ejemplo en cuestión se han interceptado las siguientes librerías:

(1) API0119, número de veces llamada en la sesión: 890, número de argumentos: 11


(3) API0177, número de veces llamada en la sesión: 0











360







El procesos implicados tienen los siguientes PID (Identi�cativo de Proceso)168:

2d82b0aa: 1(1), 2(1), 10(7)

2dfe8262: 4(6920), 16(338)

4da96fd6: 4(6), 11(29)

4dc1d0f2: 1(7), 2(3), 4(225), 9(4)

6d696f6a: 1(114), 2(3), 4(2), 5(7), 8(2), 10(17), 11(94)

6da3cfb6: 1(8), 2(1), 10(7)

8dd76a22: 1(142), 2(4), 4(197), 5(5), 8(2), 9(14), 10(9), 11(121)

8dd76eea: 4(1)

ad6ba0da: 1(39), 2(2), 5(5), 8(2), 10(9), 11(21)

adde1b92: 11(11)

cdb96c92: 1(129), 2(4), 5(8), 8(2), 10(4), 11(118)

cdc13e46: 1(65), 2(3), 4(17), 5(8), 7(3), 8(5), 10(11), 11(32)

dfaa4ca: 4(23)

La primera escisión en el estudio es la unidad máquina:proceso. Esta unidad es para identi�car

de forma única el modelo correspondiente tanto para aprendizaje como para cálculos posteriores

de validez. Esta unidad se re�eja mediante la ip del host correspondiente y el PID del proceso a

modelar. Tomando por ejemplo el primer PID (Identi�cador de Proceso) que se ha puesto en la

lista y extrayendo de la captura un trozo de la misma tenemos la siguiente evolución:

168Se indica el número interno de las librerías a las que llaman y entre paréntesis el número de veces que hasucedido en la sesión

361

PID2d82b0aaAPI10(2�10cc:,0,2,f000fdb0,��c894,f000fe3c,0,1,2�1904,8dd7c6b0,1)PID2d82b0aaAPI10(2�10b0:,0,2,f000fdb0,1eb8668,f000fe3c,0,1,2�191c,8dd7c6b0,1)PID2d82b0aaAPI10(2f91174:,0,2,f000fdb0,8dd7cea4,f000fe3c,0,1,2f94dd0,��c894,f000�fc)PID2d82b0aaAPI10(2002fc90:,0,2,f000fdb0,0,f000fe3c,0,1,2fa265c,730074,720068)PID2d82b0aaAPI10(2fc10b0:,0,2,f000fdb0,8dd61744,1eb6610,0,1,2fc3028,��c894,f000fe3c)PID2d82b0aaAPI10(2df101c:,0,2,f000fdb0,8da7c440,1e9d580,0,1,2df3634,��c894,f000fe3c)PID2d82b0aaAPI10(2002fc8c:,0,2,f000fdb0,0,1e9d580,0,1,2fa265c,720062,77006f)PID2d82b0aaAPI1(2df16a0:,f000�e0,2df16a0,2df17f8,2df17f8,1e9d6f0,1e9d71c,2df5608,1e9d71c,0,10)PID2d82b0aaAPI2(8dd33cbc:,f000�dc,8dd33cbc,0,1e9d604,0,0,2df6468,8da7c440,f000fe3c,2df3660)

Cuadro 3.23: Listado de llamadas al sistema por el PID 2d82b0aa

Recordando, dentro del listado anterior se tiene primero el identi�cativo PID, la librería o

función o llamada al sistema que realiza, los parámetros entre paréntesis y para �nalizar se tiene

el valor de retorno (un entero de 32 bits) y el valor del error indicado por el sistema (si es que

se ha producido). Como se ha indicado anteriormente todas las llamadas llevan capturados 11

parámetros, no tiene por qué ser así en todos los sistemas operativos.

Aprendizaje y semejanza de parámetros de las llamadas al sistema.

Lo primero que debe realizarse es establecer dentro del modelo de parámetros es establecer

el orden correcto y la posición adecuada de los parámetros, así como traducir si son punteros a

cadenas de texto o arrays, para poder observar los valores convenientemente.

El orden de parámetros se �ja dinámicamente dado que en la creación conforme se van leyendo

los parámetros se añaden al modelo general los modelos Bayesian Mergin que contendrán la

información correspondiente para ese parámetro en concreto. Si se plantea una solución como

por ejemplo en sistemas operativos GNU/Linux para realizar una escritura por pantalla, se le

debe pasar a la llamada que se encarga del mismo un descriptor (puntero único que hace referencia

a un �chero del disco duro), el puntero a la cadena que se va a escribir y el tamaño de la cadena.

Así mismo para este caso si tenemos el siguiente código en ensamblador (en nomenclatura AT&T

para el ensamblador de GNU/Linux, GNU/Assembler).

Listing 3.24: Ejemplo para obtener el Identi�cativo de la CPU en ensamblador sobre sistemas

GNU/Linux en nomenclatura AT&T

. s e c t i o n .data

output :

. a s c i i " El ID d e l vendedo r e s ' xxxxxxxxxxxx '\ n"

5 . s e c t i o n . t e x t

. g l o b l _start

_start :

362

nop

10 movl $0 , %eax

cpuid

movl $output , %edi

movl %ebx , 23(%edi )

movl %edx , 27(%edi )

15 movl %ecx , 31(%edi )

movl $4 , %eax

movl $1 , %ebx

movl $output , %ecx

20 movl $37 , %edx

int $0x80

movl $1 , %eax

movl $0 , %ebx

25 int $0x80

En el código de la �gura superior se escribe por pantalla el modelo de la CPU que se tiene,

haciendo uso de la instrucción de los procesadores compatibles IA-32: cpuid. Se tomarán los

valores que devuelva esta llamada y se introducirán dentro de un bu�er de texto creado a tal

efecto. Finalmente llega la parte que realmente interesaba mostrar, en la que se van introduciendo

los valores para realizar la llamada al sistema de escritura. Se introduce en el registro EAX el

valor de la llamada que se va a realizar, en este caso el valor entero de 32 bits 4. Igualmente se

introduce en el registro EBX el valor del descriptor de �chero donde se va a realizar la escritura,

para esta ocasión el valor es 1 que indica que será escrito por la pantalla de usuario. Los dos

últimos valores, si bien también indican literales de 32 bits, uno de ellos lleva asociada una cadena

de texto dado que es un puntero a la misma. Estos valores son los que se tendrán que interceptar

de forma correcta y así mismo representar en los modelos que corresponda:

Número de Parámetro Valor de Dicho Parámetro

Parámetro 2 1Parámetro 3 �El ID del vendedor es 'GenuineIntel'\n�Parámetro 4 37

Cuadro 3.24: Listado de parámetros para realizar una llamada write en GNU/Linux

Acorde a la tabla anterior el modelo que se iría generando es el siguiente:

363

Figura 3.76: Aprendizaje de Parámetros de las llamadas al Sistema

Como se puede ver en la �gura anterior, los parámetros obligan al Experto Mendizale a

crear nuevos objetivos Bayesian Merging conforme se van leyendo nuevos. El parámetro 1 crea el

Objeto Modelo Bayesian Merging 1, el segundo el segundo modelo y así sucesivamente. De esta

forma se tienen modelados los parámetro de esa syscall y de ese proceso que se esta analizando.

Estos modelos se realizan por cada llamada al sistema que se produzca, de forma que todas

las llamadas tendrán una representación para sus parámetros. Conforme vayan llegando nuevos

parámetros para esa syscall y ese proceso seguirán el método de funcionamiento de las técnicas

Bayesian Merging desarrolladas por este equipo en el proyecto ESIDE-DEPIAN[42]. Esta técnica

innovadora en su momento para el análisis de los protocolos basados en texto se aplica de forma

pionera también en estos Sistemas de Inteligencia Arti�cial, de forma que con los parámetros se

pueda precisar según la posición que ocupen (modelo de parámetro 1, modelo de parámetro 2...)

si realmente pertenecen al modelo o no.

Aparte se ha introducido una modi�cación importante, se parte siempre de un estado inicial

y se cierra siempre en una posición �nal, de forma que se pueda controlar más especí�camente

la progresión que puede soportar el parámetro correspondiente.

Como se puede ver un parámetro queda cuanti�cado probabilísticamente como Cadena de

Markov Oculta (HMM) indicando la probabilidad con la que se pasa de uno de sus caracteres (si

es un bu�er) al siguiente y se actualiza esta información con el modo de aprendizaje activo. Los

modelos autoaprenden cuando se le indica actualizando las tablas de probabilidades iniciales así

como las tablas de transición entre estados. Así mismo el cómputo de semejanza global para los

parámetros queda de la siguiente forma:

Likelihood(param1) = p(Estado1 → Estado2) · p(Emision_Simbolo1) · p(Estado2 →Estado3)...

Y siguiendo en la misma línea, la probabilidad de semejanza y de ajuste de los parámetros

de esa llamada al sistema en concreto sería la siguiente.

Likelihood_TOTAL = Likelihood(param1) · Likelihood(param2) · Likelihood(param3)...

Hasta este punto se tiene una gramática que modeliza convenientemente las llamadas al

364

sistema, ésta permite que se sepa de antemano si hay alguna anomalía a nivel paramétrico en

las secuencias de syscalls.

Generalmente los sistemas de detección de Intrusiones no hacen uso de los parámetros pero

resultan muy signi�cativos en el estudio efectuado de los posibles ataques, sobre todo para

impedir sucesos como los detectados y creados con los ataques Mimicry.

El veredicto completo de este subsistema se integrará en el apartado completo del Modelo

Mendizale en el siguiente apartado.

Aprendizaje de secuencia de syscalls.

Muchos autores intentan �jar una ventana para cada proceso en estudio y con ello poder

re�ejar una anomalía en la secuencia de syscalls que se van produciendo. Esta técnica ha tratado

siempre de ser modi�cada, mejorada y reestimada desde el documento que trató por primera vez

este secuenciamiento[134].

A este respecto en este documento se recurre a otra técnica: Las Redes Bayesianas Dinámicas.

No va a ser necesario estimar la ventana correspondiente para deslizarse sobre las secuencias de

llamadas al sistema como se ha realizado tradicionalmente. Tomando el ejemplo anterior de un

determinado proceso, se tenía la siguiente información del mismo:

PID2d82b0aaAPI10(2�10cc:,0,2,f000fdb0,��c894,f000fe3c,0,1,2�1904,8dd7c6b0,1)PID2d82b0aaAPI10(2�10b0:,0,2,f000fdb0,1eb8668,f000fe3c,0,1,2�191c,8dd7c6b0,1)PID2d82b0aaAPI10(2f91174:,0,2,f000fdb0,8dd7cea4,f000fe3c,0,1,2f94dd0,��c894,f000�fc)PID2d82b0aaAPI10(2002fc90:,0,2,f000fdb0,0,f000fe3c,0,1,2fa265c,730074,720068)PID2d82b0aaAPI10(2fc10b0:,0,2,f000fdb0,8dd61744,1eb6610,0,1,2fc3028,��c894,f000fe3c)PID2d82b0aaAPI10(2df101c:,0,2,f000fdb0,8da7c440,1e9d580,0,1,2df3634,��c894,f000fe3c)PID2d82b0aaAPI10(2002fc8c:,0,2,f000fdb0,0,1e9d580,0,1,2fa265c,720062,77006f)PID2d82b0aaAPI1(2df16a0:,f000�e0,2df16a0,2df17f8,2df17f8,1e9d6f0,1e9d71c,2df5608,1e9d71c,0,10)PID2d82b0aaAPI2(8dd33cbc:,f000�dc,8dd33cbc,0,1e9d604,0,0,2df6468,8da7c440,f000fe3c,2df3660)

Cuadro 3.25: Listado de llamadas al sistema por el PID 2d82b0aa (recordatorio)

Si traducimos la evolución de este proceso de llamadas tendría el siguiente aspecto:


Para poder ilustrar el resto del comportamiento se va a usar una cadena más larga, como

podría ser: 10, 1, 2, 7, 15, 3, 10, 10, 10, 5, 15, 3, 10. Los trabajos tradicionales que se tienen

realizarían su función mediante una ventana deslizante por las mismas teniendo problema de

365

establecer el tamaño de la misma. La gran diferencia del método desarrollado en el presente

documento es que no requiere del conocimiento del número de la ventana deslizante de antemano.

Las evidencias se introducen en el modelo bayesiano dinámico de dos en dos para realizar el

aprendizaje paramétrico de las tablas de probabilidad internas, lo que no implicará más adelante

tener que seguir con una ventana de dimensión dos.

Una vez actualizado el sistema queda con�gurado de la siguiente forma:


El modelo en modo aprendizaje ha actualizado las tablas de probabilidad internas conforme

a los datos de secuencias que se han ido introduciendo. Estas secuencias se introducen en el

modelo en una ventana deslizante de tamaño 2. Con esta evolución que parece sin memoria

más que del estado anterior como si fuera una cadena de Markov tradicional se consigue que el

366

modelo represente la realidad completamente del proceso en cuestión. La forma que tiene esta

red inicial DBN sigue las leyes de los HMM Autoregresivos, en los que las variables denominadas

�Likelihood Parámetro N� ayudan signi�cativamente a establecer a veracidad de resultados del

modelo.

La red DBN presentada se compone de un nodo padre con tantos estados como número de

librerías o de llamadas al sistema que se quiera modelar. Como hijo tiene el resultado de la

operación anterior de semejanza paramétrica de los parámetros que acompañen a esa llamada. Y

para completar la funcionalidad de DBN esto se repite enlazando tantas veces como sea necesario

esta estructura, conectando los padres entre sí y los hijos correspondientemente. Esta forma de

trabajo en DBN's se conoce como �Unrollling�.

Realizado el aprendizaje y el �jado de la estructura que contendrá el modelo debidamente,

el siguiente paso es ajustar el número de etapas que va a tener el modelo a la hora de �nalizar

el aprendizaje. Para ello se ha desarrollado una fase en la que se determina este valor, haciendo

uso de algoritmos EM y de la librería que subyace por debajo del sistema: PNL de Intel. Se

comienza con una ventana de dos nodos y se pide que se prediga el posible valor que tendría

acorde al modelo la syscall siguiente. Acorde a la secuencia planteada, se introducirían los valores

de llamada al sistema 10 y 1 observando si el siguiente valor que se ofrece es el 2. Caso de acertar

se desplazaría la ventana sobre los datos de aprendizaje para �predecir� (método Predict de la

librería de Intel) el siguiente estado, en esta caso se introduce 1 y 2, para ver si es 7. Si con este

tamaño de ventana se consiguen resultados apropiados este modelo sería con�gurado para un

tamaño de 2. En cambio si se produce un fallo en el diagnostico predictivo de la siguiente etapa,

en vez de introducir solo 2 valores de la secuencia se pasaría a introducir 3 valores y predecir

el 4o. De esta manera se consigue establecer el tamaño necesario para la inferencia de forma

adecuada y de manera automática.

Finalmente cuando se tiene el modelo completamente aprendido y actualizado se procede a

la puesta en ejecución y análisis del mismo, sobre el que se usan las metodologías de cálculo de

Semejanza. Es decir, establecido el modelo se introducen las nuevas evidencias sobre el tamaño

de ventana �jado y se le indica al experto que re�eje la probabilidad con la que esa secuencia

pertenece al modelo aprendido previamente. Este resultado por debajo de un umbral con�gurable

por el administrador será el índice sobre el que lanzarán las alertas correspondientes de Detección

de Anomalía.

3.4.4. Proceso de Razonamiento en la Red Naive de Uni�cación de Conclu-

siones

Por último, como se describe en el apartado anteriores, una vez obtenido el conjunto de

conclusiones parciales acondicionadas, resultado de cada uno de los diferentes procesos de razo-

namiento de los Motores Inteligente Mendizale para tratamiento de llamadas al sistema, puede

construirse una evidencia de alto nivel que presentar al motor de razonamiento correspondiente

367

al modelo de Red Naive de uni�cación de conclusiones parciales.

De este modo, dicho modelo podrá efectuar, en un segundo nivel jerárquico, el mismo ciclo

de inferencia y adaptación de sus homólogos especializados, con el objetivo de obtener una única

conclusión global �nal que represente el valor de probabilidad a posteriori de la maldad inherente

a cada una de las evidencias recogidas en el sistema protegido, e introducidas al motor de análisis.

Debe denotarse que actualmente los ataques no solo involucran a una parte en concreto, si no que

generalmente llegan y se reproducen por la red, por lo que el sistema se integra con los expertos

bayesianos que se tenían de proyectos anteriores, con la �nalidad de uni�car y pre-detectar

los posibles ataques que se introduzcan. Por otro lado, es importante prestar especial atención

al hecho de que, dada la especialización presente en los diferentes modelos de Red Bayesiana

responsables de la representación de los diferentes tipos de parámetros, es posible la aparición de

situaciones en la que un determinado modelo no se encuentre en disposición de inferir conclusión

parcial alguna, por lo que el componente de inferencia del mencionado modelo de Red Naive debe

contemplar dicha posibilidad en su objetivo de obtención de la conclusión global. Asimismo, dicha

cuestión introduce idéntica consideración en el componente de adaptación.

Así, una vez construida la evidencia de�nitiva, puede procederse a la presentación de la mis-

ma al método de propagación de evidencia de Pearl. De esta manera, se obtiene �nalmente un

valor continuo que representa la probabilidad de que una determinada evidencia sea maliciosa,

subversiva y anómala. Así, �nalmente, dicho valor de probabilidad puede ser utilizado para efec-

tuar la priorización de las noti�caciones de alarma que se envían al operador humano encargado

de la administración y supervisión del sistema de detección. No obstante, una vez efectuada

dicha noti�cación, es necesario que el mencionado valor de probabilidad sea introducido en el

componente de adaptación, encargado de adaptar el conocimiento almacenado en el modelo de

Red Naive a las variaciones de conocimiento introducidas por dicha evidencia, por lo que se

precisa nuevamente de una etapa de acondicionamiento de la conclusión global. Así, en este caso,

la función de acondicionamiento aplicada al presente modelo de Red Bayesiana, se de�ne como

un valor umbral relativo169.

De esta manera, los in�nitos valores que puede adoptar la mencionada probabilidad, una vez

acondicionada, quedan representados mediante los habituales dos posibles valores de normalidad

y legitimidad, o anomalía y subversión. Por su parte, a continuación, el componente de adaptación

no presenta ninguna diferencia con respecto a sus homólogos especializados, por lo que, una

vez inferida la probabilidad a posteriori de una determinada evidencia, puede procederse a la

aplicación de la variante secuencial del método de estimación de máxima verosimilitud utilizado

anteriormente, con el objetivo de adaptar el conocimiento almacenado en el modelo de Red

Bayesiana correspondiente a las variaciones de conocimiento introducidas por dicha evidencia.

169El modelo de Red Naíve de uni�cación de conclusiones conlleva un proceso de inferencia de conclusionesbasado en la selección del estado �nal más probable de la variable que representa la categoría, en este caso laconclusión global. Por ello, el resultado �nal obtenido por el componente de inferencia no es sino la probabilidada posteriori del estado más probable.

368

Una vez efectuada esta operación, el motor de razonamiento queda nuevamente dispuesto para

recibir la siguiente evidencia.

Finalmente el sistema automáticamente entrega las causas en forma de regla al administrador

correspondiente para que si lo desea sea introducida dentro del sistema. De esta forma se tiene

controlado en el propio �ujo de la infraestructura si se ha producido, de forma que se realice

una captura temprana basada en aprendizajes anteriores. Esta captura indica al sistema no que

es requerido que vuelva a procesar esos mismos datos dado que ya se sabe el resultado que han

tenido con anterioridad. Queda a merced del administrador el hacer uso de esta funcionalidad y

de los periodos que se requieren de aprendizaje, así como de los niveles de umbrales que desea

en el sistema para indicar las posibles anomalías. Dependiendo de las necesidades concretas de

algún proceso o host, se pueden �jar umbrales diferentes para la reacción de la infraestructura.

3.5. Respuesta

Los resultados obtenidos de la fase de análisis, se utilizan para tomar las decisiones que

conducirán a una respuesta. El conjunto de acciones y mecanismos que se pueden efectuar en esta

etapa es amplio. A continuación se describirán los requisitos y tipos de respuesta más comunes.

Una de las consideraciones a tener en cuenta al diseñar un mecanismo de respuesta es el

entorno operacional en el que se va a utilizar. Un sistema de detección que deba coordinar la

información de múltiples agentes, distribuidos a lo largo de una red de producción, no tiene

las mismas necesidades de alarma y noti�cación que un sistema no distribuido, instalado en un

ordenador personal. El elemento monitorizado juega, también, un papel importante en el modelo

de respuesta. Una de las razones por las que se proporcionan respuestas activas, como el bloqueo

de las conexiones del atacante, paralización de los procesos sospechosos de ser ataques, se debe

a la existencia de sistemas que proporcionan funciones o servicios críticos a los usuarios.

Por otra parte, las alarmas y avisos proporcionados por un mecanismo de respuesta deberían

presentar su�ciente información adicional para indicar las acciones a tomar en cada situación. Al-

gunos productos de seguridad sólo indican el identi�cador del error mediante un simple mensaje,

siendo más útil añadir el posible origen del problema y cómo solucionarlo.

3.5.1. Tipos de respuestas

Las respuestas de un sistema de detección de intrusiones pueden ser de dos tipos: pasivas o

activas. Se pueden dar ambos tipos de respuestas en un sistema de detección, por lo que no son

excluyentes, más bien, son complementarias. Es posible que, en determinadas anomalías, sólo sea

necesario registrar la actividad ocurrida para su posterior examen, mientras que en intrusiones a

sistemas críticos haga falta una actuación más activa y urgente. Todo depende de las necesidades

de cada caso[85].

369

Respuestas pasivas

Son aquellas respuestas que consisten en el envío de información al responsable correspon-

diente, dejando recaer en él la toma de decisiones. En los primeros detectores de intrusiones,

todas las respuestas eran pasivas. Aunque la tecnología ha evolucionado mucho desde entonces,

las respuestas pasivas siguen existiendo. Y es que, por muy a�nados que sean los mecanismos

de respuesta automática, hay ocasiones en que un sistema no tiene la responsabilidad su�ciente

para tomar una decisión.

El mecanismo más común son las alarmas por pantalla, en los que un mensaje en una ventana

indica al usuario que se ha cometido una posible intrusión, acompañando a veces el mensaje con

información adicional, como la dirección del posible atacante, el protocolo usado, etc. El contenido

de estas alarmas se puede con�gurar en muchas ocasiones.

Otra forma de recibir respuestas pasivas es a través del correo electrónico o mensajes a un

teléfono móvil ?SMS, WAP push, etc-. La ventaja del segundo caso sobre el primero, es que se

puede recibir en cualquier lugar, cualidad muy apreciada entre administradores. No obstante, un

correo electrónico puede contener más información, proporcionando un mensaje más extenso, y

menos ambiguo, sobre la incidencia. El modelo presentado en este punto implementa el segundo

tipo de respuesta, a continuación se muestran algunas pantallas de los mensajes enviados ante

un ataque.

Figura 3.79: Ejemplo de envío de alerta de ataque al telefono móvil (Respuesta pasiva).

370

Por otra parte, algunos sistemas de detección de intrusiones están integrados con mecanismos

de gestión de redes. En estos casos se suele hacer uso de mensajes SNMP170. La integración con

este sistema de comunicación permite utilizar canales ya existentes para el envío de incidencias.

No obstante, un uso excesivo por parte de detectores de intrusiones de estos canales, puede

perjudicar a otros sistemas que también hagan uso de ellos.

Respuestas activas

Este tipo de respuestas implican alguna acción en particular, como el bloqueo de un proceso,

el cierre inmediato de una cuenta, o la prohibición de ejecución de determinados comandos. Estas

acciones que pueden ser de diversa naturaleza se pueden clasi�car básicamente en tres categorías

principales: Ejecución de acciones contra el intruso, Corrección del entorno y Recopilación de

información que se resumen a continuación.

La forma más directa de �Ejecución de acciones contra el intruso� consiste en identi�car

el origen del ataque e impedirle el acceso al sistema, por ejemplo, en el caso de un sistema

de detección de intrusiones basado en red, la ejecución de acciones contra el usuario puede ser

desactivar una conexión de red o bloquear la máquina comprometida-, acciones menos drásticas

pueden ser, terminar la sesión TCP problemática o bloquear durante un intervalo de tiempo el

origen de las intrusiones. En cuanto a los sistemas HIDS, las acciones a tomar contra el usuario

pueden ser, por ejemplo impedimiento al proceso sospechoso de ejecutar más syscalls, eliminar los

procesos sospechosos, o incluso impedir al usuario involucrado en el evento sospechoso ejecutar

ningún programa más.

Como su nombre indica la �Corrección del entorno� consiste en efectuar las acciones perti-

nentes para restaurar el sistema y corregir los posibles problemas de seguridad existentes. En

muchas ocasiones, esta respuesta activa suele ser la acción más acertada. Aquellos sistemas que

cuentan con métodos de de auto-curación son capaces de identi�car el problema y proporcio-

nar los métodos adecuados para corregirlo. A menudo, este tipo de respuestas puede provocar

cambios en el motor de análisis o en los sistemas expertos, generalmente aumentando su sensibi-

lidad e incrementando el nivel de sospecha ante posibles intrusiones, o ante usuarios o procesos

concretos.

La �Recopilación de más información� se utiliza en ocasiones para cumplir los requisitos de

información necesarios para poder tomar acciones legales contra posibles criminales. Normalmen-

te se aplica en sistemas que proporcionan servicios críticos. Otra de las situaciones en las que se

puede dar este tipo de respuesta, es en máquinas o redes que imitan comportamientos y servicios

reales, para engañar a los intrusos. Tal es el caso de servidores trampa y honeypots por citar

algunos.

170Simple Network Management Protocol

371

Prevención

Las respuestas activas, tienen varios problemas para con algunos tipos de ataque, en los cuales

la acción de la respuesta activa queda eliminada o minimizada.

Incapacidad de interactuar con ataque spoofeados171, si un intruso lograse hacer pasar un

proceso con un nombre (por ejemplo apache), la respuesta activa puede encontrar a el

proceso apache legítimo como un proceso sospechoso y tomas acciones para con él, como

puede ser pararlo, o suspenderlo, cuando se trata de un proceso legítimo.

Incapacidad de mantener �Listas blancas� de procesos, dado que los procesos son vulnerables

a ataques de over�ow, por lo que en los sistemas de host es imposible mantener este tipo

de listas.

Imposibilidad de bloquear el evento que ha disparado la alerta. Este es el mayor problema

del que adolecen los sistemas de respuesta activa, dado que hay ataques que únicamente

ejecutan una acción que puede ser sensible de ser localizada172.

Figura 3.80: Problemática de la respuesta activa en sistemas NIDS

Por lo tanto, la prevención añade una solución a los problemas de la respuesta activa, aparte

de eliminar otro problema de la mísma que es dotar de la inteligencia necesaria al sistema de de

repuesta activa como para que tome acciones correctas contra los atacantes, dado que en este

tipo de sistemas [243, 342], sólamente atajan las syscalls173, o los paquetes de red174.

171Ataques de suplantación172Como pueden ser por ejemplo los ataques ICMP en red, o un bu�er over�ow sobre un argumento de una

syscall.173En el caso de los sistemas HIDS (Sistemas de intrusión de host) como el que estamos tratando ahora mísmo174en el caso de los sistemas NIDS (Sistema de detección de intrusiones basado en red).

372

3.5.2. Respuesta implementada en ESIDE-Mendizale.

En el sistema de respuesta activa de ESIDE-Mendizale se encuentran implementados varios

tipos de respuesta activa explicados en el punto anterior, por una parte un sistema de respuesta

pasiva implementada dentro de la infraestrucutra del sistema, que permite realizar diferentes

alertas.

Por otra parte el sistema ofrece también la posibilidad de implementar respuesta activa, con

diferentes puntos de vista en la aplicación de la mísma.

Respuesta pasiva implementada en ESIDE-Mendizale

La respuesta pasiva implementada en el presente proyecto, se encuentra soportada por el sis-

tema de respueta que está explícitamente implementado para el presente proyecto. Esta respuesta

pasiva, realiza un aviso, sobre el ataque o anomalía que se ha detectado.

Este tipo de respuesta es la más implementada en los sistemas convencionales, tanto por su

sencillez como por no tener que implementar una lógica de respuesta, la cuál se deja a manos de

el agente humano o administrador de sistemas que tome la acción necesaria para el evento que

se ha recogido.

La respuesta pasiva se implementa en varias versiones, mediante un mensaje SMS, que permite

informar al administrador de sistemas allí donde se encuentre, y tomar las acciones necesarias

al momento. Otra de las opciones implementadas es generar la salida mediante XML, para

un posíble data mining o procesado por parte de otros procesos este �chero, que simpli�ca y

estandariza el acceso a datos.

Respuesta activa implementada en ESIDE-Mendizale

La respuesta activa implementada en ESIDE-Mendizale, se encuentra dividida en dos grandes

partes: por una parte la respuesta activa implementada a nivel de proceso, y por otra parte la

respuesta activa implementada a nivel de usuario o usuario efectivo.

La respuesta activa a nivel de proceso, implica que una vez que se ha detectado que un

proceso es anómalo 175, dicho proceso no pueda ejecutar ninguna llamada al sistemas más, es

decir, puede llamar a las librerías del sistema, pero éstas no pueden ejecutar ningúna llamada al

kernel de dicho proceso. Este sistema, permite �congelar� los procesos para que una aprobación

del administrador del sistema permita liberar dicho proceso. Este proceso se puede dar porque

el sistema de recolección de datos inserta una función tranpolín entre las llamadas legítimas y

las de nuestro sistema. Este sistema de recogida de datos posee absolutamente todo el control

sobre dichas llamadas, incluso si se ejecutan, si no se ejecutan o no se responden hasta que el

administrador de sistemas de un aviso de que el proceso puede seguir, en caso contrario puede

matar dicho proceso.

175Alguna de sus systems calls ha generado una anomalía en algún experto del sistema.

373

Otra opción barajada para la respuesta activa a nivel de proceso, se trata de suspender a nivel

de kernel el proceso involucrado, cambiando el estado del proceso a suspendido, este sistema, al

�nal no ha sido utilizado por la necesidad de estudiar el plani�cador de procesos de cada sistema

operativo, el cuál es conocido para GNU/Linux, pero no para el resto de sistema para los que se

ha implementado el sistema.

La otra opción dentro de la respuesta activa, es realizarla a nivel de usuario, es decir, que

si algún proceso de algún usuario realiza una acción que es detectada como una anomalía todos

los procesos de dicho usuario se mantienen bloqueados sin realizar ninguna syscall hasta que el

administrador de sistemas da el visto bueno a dicha anomalía, o en su defecto hace que dichos

procesos mueran. En cuanto a este tipo de respuesta activa, es en los sitemas GNU/Linux, existe

una opción que se ha barajado, que es extender este tipo de acciones no sólamente a los usuarios,

sino también a los usuarios efectivos176, este tipo de usuario, existe en los sistemas GNU/Linux,

por el bit SUID177, que permite que el �chero que contiene dicho bit activo se ejecute con los

provilegios del creador. Por ejemplo el comando ping necesita acceder a dispositivos reales para

ejecutar mediante raw sockets su cometido, que es mandar mensajes ICMP. Por lo tanto en un

sistema sin SUID, ningún usuario, excepto el superusuario o root, podría ejecutar el comando ping

y que enviase mensajes ICMP al exterior, dado que para acceder para escritura a dispositivos

hace falta generalmente ser superusuario. Para solucionar este problema, existe el SUID, que

permite ejecutar el programa ping con los privilegios de su creador, en su caso, root. De esta

manera, se permite bloquear un usuario permanentemente en todos los niveles, incluso cuando

es otro usuario cuando ejecuta sus �cheros.

Esta opción es justi�cada porque si un código vírico es ejecutado bajo un usuario, éste código

vírico puede infectar todos los �cheros en los que puede escribir dicho usurio. Por lo tanto, si un

usuario queda infectado, todos sus �cheros con el bit SUID también podrían quedar infectados

y ser ejecutados por otros usurios, de ahí que se limite la utilización del EUID.

Prevención implementada en ESIDE-Mendizale

La prevención no ha sido implementada en ESIDE-Mendizale, dado que no era uno de los

objetivos principales e implica grandes problemas técnicos en comparación con sistemas NIDS, de

todas maneras, se va a realizar una pequeña aproximación a cómo se implementaría la prevención

en sistemas HIDS, estudio que se llevó a cabo para descartar la implementación de la prevención.

La prevención en este tipo de sistemas, implicaría realizar un estudio de cada una de las

syscalls que se recolectan ántes de que se ejecuten. Esto requeríria ver si cada una de las syscalls

se ajusta al modelo realizado según el apartado análisis, y si éste se ajusta, dejar que la syscall

siga su camino.

Este sistema, debería de ser lo su�cientemente rápido como para que la ejecución de el pro-

176También conocidos como EUID, o E�ective User IDen�cation.177Bit especial contemplado dentro de los bits de permisos del sistema GNU/Linux.

374

grama no se ralentize en exceso, dado que estamos haciendo que cada instrucción del programa

pase una ver�cación. Esta necesidad, haría necesario que el modelo de ver�cación de cada ins-

trucción se ejecutase en el kernel a modo de LKM178, para evitar la lentitud ocasionada por la

comunicadión de las zonas de usuario y de kernel.

3.6. Fortaleza

Los sistemas de deteccion de intrusiones son, desde el primer momento en que son implanta-

dos, el blanco de los ataques de los intrusos[117], por ello, el sistema de deteccion de intrusiones

debe de ser lo su�cientemente �able y seguro como para que este tipo de ataques no lleguen a

buen puerto y den una falsa sensacin de seguridad.

Dos de las partes de los sistemas de detección de intrusiones son particularmente sensibles a

este tipo de ataques, en concreto la parte de recogida de información y de almacenamiento de

los resultados obtenidos del proceso de análisis. De otra forma, la información de partida puede

ser objeto de subversión y el sistema de detección estaría proporcionando una falsa sensación de

seguridad.

Este aspecto de la seguridad de la fortaleza que el sistema IDS implementado en ESIDE-

Mendizale, ha sido desarrollado mejorando la seguridad, transparencia y escalabilidad del sistema.

Por una parte, en cuanto a la transparencia de los sistemas, se ha realizado una ocultación de

los procesos y los módulos involucrados en el sistema. Esta solución es dependiente de cada uno

de los sistemas en los que se ha realizado el sistema de recolección de datos, y se ha utilizado el

control que otorga el lugar en el que se encuentra emplazado el sistema de recolección de datos

para esconder la existencia de los procesos y módulos involucrados en el sistema, sensibles a un

atacante externo. Esto se realiza, haciendo que el atacante no pueda ver los procesos existentes,

para ello se utilizan técnicas esencialmente víricas que sobreescriben las llamadas al sistema que

iplementan la escritura y la lectura (Dependiendo del sistema sobre el que se implemente se

modi�cará el funcionamiento de una o de otra). Estas llamadas se encuentran ya capturadas

mediante funciones �trampolín�, que implementan la recolección de datos, por lo tanto para

esconder la existencia de dichos procesos, se elimina del bu�er del resultado los nombres de los

procesos y de los módulos implicados.

Con este sistema, conseguimos que los atacantes sean incapaces de conocer si en ese sistema

existe un sistema de auditoría, porque sencillamente, son incapaces de verlo.

Por otro lado, el uso de una superestructura paralelizable, como la explicada anteriormente,

permite evitar ataques de denegación de servicio basados en complejidad algorítmica. Según [25]

estos ataques se basan en explotar vulnerabilidades algorítmicas de muchos de los algoritmos

empleados en el software a atacar. La idea clave del ataque es que muchas de las estructuras

de datos y algoritmos empleados habitualmente, tienen un buen comportamiento en los casos

178Loadable Kernel Module

375

normales, pero pueden degenerar a casos críticos -en consumo de memoria o de CPU- ante

situaciones patológicas. De esta forma, sí la superestructura se paraleliza para que se ejecute,

de forma distribuida, cada una en un equipo este ataque pasa a ser inocuo porque se podrá

sobrecargar uno o varios sistemas pero el resto siguen funcionando a pleno rendimiento.

Añadido a lo anterior el uso de una superestructura orientada a la poda de expertos, ya

comentado anteriormente, hace que se eviten ataques de denegación de servicio basados en com-

plejidad algorítmica. Sí un experto se satura el propio modelo es capaz de "podar" esa rama,

que lo esta ralentizando, hasta que su situación vuelva a la normalidad.

Otra forma de dotar de fortaleza al sistema de detección es mediante la protección de la

recogida de información en base a la ubicación de los elementos de etiquetado y análisis en una

red privada virtual paralela a la infraestructura de comunicaciones a proteger. Un ejemplo de

esto puede verse en la siguiente �gura:

Figura 3.81: Ejemplo de arquitectura del sistema, que asegura la fortaleza del sistema medianteVPN�s.

En esta �gura se puede apreciar como los sistema de recolección de datos se comunican con

el resto de agentes, es aquí donde la comunicación se puede hacer cifrada mediante una VPN

-representadas por el candado-. Gracias a este cifrado que proporciona la VPN se consiguen tres

de los cuatro pilares básicos de la seguridad de la informacion, a saber: Autenti�cación -el que

envía la información es realmente quien dice ser-, Con�dencialidad - nadie en el punto intermedio

entre el sni�er y el analizador es capaz de ver la información que se esta transmitiendo- y por

último Integridad -los datos que se envían no sufren alteración ninguna en su camino-.

De esta manera, se ha conseguido un sistema que presenta una gran fortaleza contra todo

376

tipo de agresiones, tanto de ataques de denegación como de servicio (mediante la distribución

del cálculo y la posibilidad de poda de elementos sobrecargados), la transparencia de los agentes

de recolección de datos que se autoocultan para no aparecer a los ojos de los atacantes, y la

utilización de redes privadas virtuales (VPN) para la comunicación entre los diferentes elementos

de la red.

3.7. Cuestiones Operacionales

Este apartado, tal y como se ha descrito anteriormente trata sobre cuestiones como la escalabi-

lidad, portabilidad, extensibilidad, así como otros aspectos como pueden ser la interoperabilidad

entre los diferentes componentes o incluso entre diferentes sistemas de detección de intrusiones.

Este tipo de cuestiones son de las más importantes para los usuarios de los sistemas de

detección de intrusiones, la facilidad de mantenimiento, reto establecido en el punto, se supera

ampliamente gracias a que el sistema genera sus salidas comparandolo con la normalidad lo que

dota al modelo de la capacidad de auto-adaptación a la realidad cambiante de la red reduciendo

al mínimo las labores administrativas, no como en otro tipo de sistemas expertos que necesitan

de un operado les inserte el conocimiento.

La portabilidad, entendida desde distintos sistemas operativos, máquinas y redes. Es decir, el

ids debe ser capaz de ejecutarse en distintos sistemas operativos, en distintas arquitecturas y dis-

tintas redes, este punto queda ámpliamente superado por la infraestructura de ESIDE-Mendizale,

dado que se ejecuta tanto en sistemas GNU/Linux como en Windows bajo la plataforma Cy-

gWin179, y se adapta a todo tipo de con�guraciones y de arquitecturas, gracias a su con�guración

en tres capas, dando como lugar un sistema totalmente adapatable a la con�guración del entorno

o a las necesidades del sistema a implantar.

La cuestion de la extensibilidad, muy ligada a la esclabilidad, queda de nuevo solventada por

la la estructura del sistema que permite conectar y desconectar nodos de computación (Tails) en

caliente,y cargar y /o descargar dinámicamente plugins en los Tails y Heads.

Cuestiones secundarias como el conocimiento requerido para su con�guración y la inter-

operatibilidad con otros IDS no se han tenido en cuenta a la hora de desarrollar el sistema

ESIDE-Mendizale.

3.8. Aspectos sociales

Los aspectos sociales de un sistema de detección de intrusiones tiene dos vertientes bastante

diferencias, una relativa a los usuarios del entorno que protege y otro relativa a las acciones a

realizar contra los atacantes.

179Cygwin se trata de la implementación del API de GNU/Linux bajo windows, se trata de una herraminetatlibre disponible en : http://www.cygwin.com/

377

En los aspectos relativos a los usuarios cabe hacerse preguntas del estilo a ¾Cómo afecta el ids

a la comunidad de usuarios que protege?, ¾Realmente evitará la consecución de intrusiones?, ¾Los

usuarios sentirán que sus datos se encuentran más protegidos?, ¾Verán los usuarios al sistema

como el ?gran hermano? que todo lo observa?. La respuesta a todas estas preguntas dependen

de que tipo de ids escoja la organización y que información/formación se les de a los usuarios.

Por tanto, como dependen totalmente del tipo de organización, su respuesta queda totalmente

fuera del ámbito de este proyecto y desde aquí solo se ha querido introducir estas cuestiones.

Por otro lado, la implementación de un sistema de detección de intrusiones implica, en muchas

ocasiones, el cumplimiento de una serie de requisitos impuestos por la ley. Cumplir con estas

obligaciones permite perseguir a los culpables mediante procesos legales o judiciales. Los registros

e informes proporcionados por el detector de intrusiones pueden constituir pruebas que ayuden

a localizar y condenar a los responsables. Sin embargo estos registros e informes pueden incluir

información considerada personal. Johnston establece, en su documento [286],que partes de la

información usada por un IDS se pueden considerar personal y por tanto entran dentro de

las leyes de privacidad. Por todo esto, aunque anteriormente se han presentado las respuestas

activas/reactivas, en el modelo no se hace una utilización, agresiva, de esta capacidad tan solo

se contempla la realización de un sistema de aviso de anomalías.

378

Capítulo 4

Conclusiones y líneas de investigación

futuras

Finalmente, una vez concluido el desarrollo de las diferentes tareas de investigación que

componen el presente estudio, y a la vista de los resultados obtenidos durante la fase de desarrollo

análisis de los resultados, es necesario determinar el grado de innovación con el que se alcanzan en

ESIDE- Depian las hipótesis fundamentales, planteadas en el capítulo 1. Además, por otro lado,

el desarrollo de las investigaciones conducentes a los objetivos marcados en la presente memoria

sirve asimismo para señalar las futuras líneas de trabajo a través de las cuales buscar solución a

ciertas cuestiones que aún permanecen por resolver y los nuevos retos que se plantean a raíz de

los estudios realizados. De este modo, se exponen a continuación tanto las conclusiones obtenidas

a lo largo de las diferentes partes que componen el presente trabajo de investigación, como las

futuras líneas de investigación que son susceptibles de abordarse a corto plazo, con el objetivo

de dar nuevos pasos en el desarrollo del área de conocimiento de la Detección de Intrusiones.

4.1. Conclusiones

Se ha desarrollado una infraestructura con la vista puesta en el futuro y en las siguientes

líneas de investigación. Esta infraestructura va a permitir alcanzar una integridad y unicidad,

aparte de la homogeinización de los resultados. Así mismo se han mezclado y unido las líneas de

investigación basadas en detección de �rmas y detección de anomalías por medio de la infraes-

tructura desarrollada: Heptopus. Se ha dedicado un gran esfuerzo en el desarrollo de la misma

para optimizar la rapidez de respuesta y la distribución de carga computacional de forma que se

permitan numerosas con�guraciones e implantaciones acorde a los requisitos que sean requeridos.

Así mismo se ha dedicado un gran esfuerzo de trabajo en el desarrollo de una metodología de

trabajo para análisis de trazas de sistema que se espera dé resultados a corto plazo y se materialice

en diferentes proyectos comerciales. Las técnicas de inteligencia arti�cial desarrolladas componen

un avance signi�cativo en el campo de detección de intrusiones automatizadas para entornos host.

379

El dinamismo y la automatización, así como la conclusión de reglas en base a los mismos hacen

de este proyecto un conjunto único y una nueva visión de desarrollo para las técnicas actuales

existentes en el campo hasta la fecha.

No queda más que indicar que todos estos objetivos no hubieran sido cubiertos sin la existencia

de una librería mantenida por la comunidad del software libre: PNL (subvencionada por Intel).

Sobre la misma se ha desarrollado un sistema software de adaptación, para facilitar el trabajo

con la librería anterior que ha llevado más de la mitad del tiempo de desarrollo del proyecto.

Esta adaptación permite acometer las formas de trabajo con la librería de Intel de forma sencilla

y automática, simpli�cando el uso de la misma y los requisitos de conocimiento necesarios para

realizar las mismas operaciones directamente con ella.

El equipo de investigación espera grandes resultados del trabajo de este periodo, con�ando en

la acogida de la comunidad investigadora con entusiasmo a esta nueva visión de la seguridad en

entornos de detección de intrusiones basados en red, en host e incluyendo los terminales móviles

y sus comunicaciones. Si bien el proyecto originariamente se desarrollo en vías a solventar las

problemáticas de este tipo de terminales, los dispositivos móviles, acorde a las hipótesis estas

técnicas pueden usarse indistintamente tanto en terminales móviles como en unidades cableadas.

En primer lugar, el objetivo operacional de desarrollo de un modelo de detección de intru-

siones basado en anomalías para terminales móviles ha sido cubierto con creces. Dado que la

metodología de trabajo necesaria para acometer este trabajo en terminales móviles era paralela

a la desarrollada para sistemas informáticos cableados (mainframes, servidores, ordenadores de

sobremesa, portátiles, etc), el proyecto se amplió, introduciendo interceptores para los diferentes

sistemas operativos: Windows y Linux, así como para los sistemas operativos móviles: Symbian

OS, Linux para terminales móviles (Nokia N770 y derivados) y Windows Mobile. El sistema,

ampliado de miras ya, en las pruebas que se han realizado durante el desarrollo del software im-

plementado en este periodo de trabajo ha dado resultados muy esperanzadores sobre el proyecto

desarrollado. La infraestructura ha demostrado acoger las líneas de trabajo anteriores de forma

válida y ha permitido la introducción de una distribución de carga necesaria y requerida para no

saturar los sistemas de detección.

Uno de los principales retos que se presentaron en la parte de retos era el modelado de

per�les de usuario no supervisados, con objetivo directo en la detección de ataques noveles (z-

day attacks). Este objetivo ha sido estudiado en base a las áreas actuales de investigación a

nivel mundial y se ha conseguido mejorar las técnicas existentes para la tecnología actual. Este

modelo basado en Redes Bayesianas puede arrojar una llamada preventiva, dado que al generar

una regla se puede detectar prematuramente e incluso introducir este tipo de regla estáticas

dentro de los terminales móviles, evitando la necesidad de enviar información sobre patrones ya

conocidos como anómalos.

Fruto de un aprendizaje prematuro y una creación de un modelo incompleto se pueden

presentar tasas altas de falsos positivos, esta tasa se puede ajustar por medio de conocimiento

380

experto o volviendo a entrar en modo aprendizaje para los expertos basados en Redes Bayesianas.

Es conveniente observar la tasa de alertas que se van generando para poder garantizar la �abilidad

del sistema, dado que puede tener un conocimiento incompleto sobre la aplicación en estudio.

Toda la base de conocimiento del sistema puede ser estudiada dado que sigue un formato

estandarizado en �cheros XML que permiten creación, modi�cación o logeo de características

dentro de la infraestructura y de los propios expertos bayesianos. Además esta parte se aplica

incluyendo a las reglas de detección estática y los veredictos que entregan los expertos, pudiendo

realizarse integraciones con otras aplicaciones. Esta escalabilidad posibilita a los futuros usuarios

o administradores de esta infraestructura gestionarla en la forma que estimen más conveniente.

Un objetivo fundamental es la simpli�cación del trabajo de las personas dedicadas al trata-

miento integral de la seguridad en organizaciones especí�cas. El prototipo que se ha desarrollado

si bien no esta en un estadio de madurez su�ciente como para realizar un producto comercial, no

dista mucho de un proyecto de estas características. El objetivo futuro que se plantea por el equi-

po de investigación es la conclusión de productos comerciales que permitan a los futuros usuarios

una forma sencilla de uso de la infraestructura. Además se les dota de medidas estudiadas y

contrastadas para la detección temprana y corrección de las anomalías que acaezcan.

4.2. Líneas de investigación futuras

Las líneas futuras en las que se esta trabajando actualmente para dar el prototipo por con-

cluido es la medición de tasas de errores, tiempos de aprendizaje y �jación de umbrales para

poder dar una visión menos subjetiva a los usuarios de con�guración de la plataforma. Si bien es

ajustable en todos sus parámetros, conviene entregar una serie de datos y pruebas más extensa

que la que se dispone actualmente. En plazo corto se dispondrá de estos datos para poder dar el

prototipo por acabado.

Otra línea de investigación es la integración completa con los sistemas de detección de red,

para ello el despliegue de esta plataforma deberá realizarse del lado del operador de telefonía

móvil. Este operador será quien pueda tener acceso a las comunicaciones de los terminales vía

internet (llamadas de datos GSM/GPRS/UMTS) y podrá incorporan los sistemas desarrollados,

tanto para análisis del trá�co de red, como para análisis de llamadas al sistema. Esta integración

homogénea y uni�cada de los datos corre a cargo de una parte fundamental de la plataforma, la

red bayesiana naive de uni�cación de resultados. Esta red permitirá sacar futuras conclusiones

sobre la concurrencia de que se produzca un ataque de red y se encuentren modi�caciones en

el comportamiento de las aplicaciones en estudio y viceversa. Este paso futuro es la integración

fundamental, según la visión de la seguridad de este equipo de investigación, que deberá tenerse

instaurada en todo entorno informatizado para dotarlo de la seguridad requerida.

Líneas de investigación más rompedoras conllevan una modi�cación en la forma de trabajo

de los terminales móviles, como son la instrumentación de software y aplicaciones instaladas de

forma virtual. Este tipo de sistemas operativos virtualizados, llevados a terminales móviles, dotan

381

a los mismos de entornos seguros de aplicación y comportamiento estanco entre unas aplicaciones

y otras, si bien será necesario instrumentalizar y comprobar el comportamiento anómalo que se

produzcan incluso en el interior de este tipo de entornos.

El desarrollo de sistemas que permitan la instrumentación codi�cada de métodos implicaría

un fuerte incremento en el consumo de recursos del sistema, pero puede ser un paso adelante en

la instalación de aplicaciones. Esta medida se viene aplicando de forma reducida dentro de los

instaladores, veri�cando números de serie, funciones resumen criptográ�ca (hash) o �cheros de

con�guración de permisos. Esto puede ser sobrepasado con la instalación de un sistema de segu-

ridad, mediante una instrumentalización binaria criptográ�ca, en la que se realice la instalación

controlada y la inclusión de los códigos necesarios en el sistema para que cuando se requiera una

funcionalidad del mismo se veri�que que todo siga bajo la normalidad.

Más puntos interesantes puede ser el estudio de ataques mimicry contra sistemas de detección

criptográ�cos existentes, un proyecto aparte puede llegar a ser el realizar un proyecto fuera de las

líneas de desarrollo habituales. Siguiendo la línea en la que un auditor de sistemas no desarrolla un

trabajo adecuado si no ha estado desarrollando al otro lado de la barrera, se considera necesario

dedicar un tiempo para desarrollar ataques e infecciones posibles contra los sistemas móviles

y la seguridad que conllevan. Este tipo de desarrollo puede ayudar con conocimiento experto

para los sistemas de detección de intrusiones como el que se ha realizado, introduciendo nuevas

conclusiones en el mismo o nuevas tesituras a tener en cuenta.

382

Bibliografía

[1] Wikipedia, http://es.wikipedia.org/wiki/Ficherobinario.

[2] Wikipedia, http://es.wikipedia.org/wiki/Exploit.

[3] R. e. neapolitan. probabilistic reasoning in expert systems: Theory and algorithms. Wiley-

Interscience, New York, 1990.

[4] The bayesian information criterion (bic). Disponible en département de mathématiques

de Besançon. http://www-math.univ-fcomte.fr/mixmod/statdoc/node21.html, Septiembre

2005.

[5] Databases and arti�cial intelligence. arti�cial intelligence segment. hill-climbing . Disponi-

ble en: http://www.cee.hw.ac.uk/ alison/, 2005.

[6] Hypertext transfer protocol � http/1.1. 2005. Disponible en

http://www.ietf.org/rfc/rfc2616.txt.

[7] Internet control message protocol. darpa internet program. protocol speci�cation. 2005.


[8] Internet protocol. darpa internet program. protocol speci�cation. 2005. Disponible en


[9] Multiple imputation for missing data. Disponible en

http://support.sas.com/rnd/app/da/new/dami.html, Octubre 2005.

[10] Transport control protocol. darpa internet program. protocol speci�cation. 2005. Disponi-

ble en http://www.ietf.org/rfc/rfc793.txt.

[11] User datagram protocol. darpa internet program. protocol speci�cation. 2005. Disponible

en : http://www.ietf.org/rfc/rfc768.txt.

[12] Raftery A. Bayesian model selection in social research. In Marsden, P., editor, Sociological

Methodology. Blackwells, Cambridge, MA, 1995.

383

[13] N. Abouzakhar, A. Gani, and Abuitbel M. y King D Manson G. Bayesian learning networks

approach to cybercrime detection. Post Graduate Symposium, John Moore University,

Liverpool, UK, Junio 2003.

[14] M. Schatz A.K. Ghosh, A. Schwartzbard. Using program behavior pro�les for intrusion

detection. 3rd SANS Workshop on Intrusion Detection and Response, 1999.

[15] J. Allen, A. Christie, Fithen W., McHugh J., Pickel J., and Stoner E. State of the prac-

tice of intrusion detection technologies. Carnegie Mellon University Software Engineering

Institute, Technical Report, 2000.

[16] Intersect Alliance. Guide to snare epilog for unix, snareapache and snaresquid. 2006.

[17] P. Alípio, P. Carvalho, and J. Neves. Using clips to detect network intrusion. Lecture

Notes in Computer Science, Vol. 2902/2003, Pag. 341-354, ISBN 0302-9743, Springer-

Verlag, Diciembre 2003.

[18] K. Anagnostakis, S. Antonatos, E. Markatos, and M. Polychronakis. E2xb: A domain-

speci�c string matching algorithm for intrusion detection. Proceeding of the 18th IFIP

International Information Security Conference, Mayo 2003.

[19] D. Anderson, T. Frivold, A. Tamaru, and A. Valdés. Next generation intrusion detection

expert system (nides), software users manual. Computer Science Laboratory, SRI Interna-

tional, Mayo 1994.

[20] J. Anderson. Computer security threat monitoring and surveillance. Technical Report, Fort

Washington, Pennsylvania, Abril 1980.

[21] J. P. Anderson. Computer security threat monitoring and surveillance. 1980.

[22] Kamal Nigam Andrew McCallum. A comparison of event models for naive bayes text

classi�cation. School of Computer Science Carnegie Mellon University, 1998.

[23] Alerta Antivirus. Centro de alerta temprana sobre virus y seguridad informática. Disponible

en http://alerta-antivirus.red.es/portada/, 2006.

[24] W. A. Arbaugh, W. L. Fithen, and J. McHugh. Windows of vulnerability: A case study

analysis. IEEE Computer, December 2000.

[25] J. Avión. Denegación de servicio a través de ataques de complejidad algorítmica. Disponible

http://www.computeridea.net/Actualidad/Noticias/Seguridad/Vulnerabilidades/20030729002,

2005.

[26] S. Axelsson. Intrusion detection systems: A survey and taxonomy. Technical report 99-15,

Department of Computer Engineering, Chalmers University. Goteborg, Suecia, 2000.

384

[27] S. Axelsson. Visualization for intrusion detection: Hooking the worm. Proceedings of the

8th European Symposium on Research in Computer Security, Vol. 2808 of Lecture Notes

in Computer Science, Springer-Verlag, Noruega, Octubre 2003.

[28] R. Bace and P. Mell. Intrusion detection systems. NIST Special Publication on Intrusion

Detection Systems. Disponible en http://csrc.nist.gov/publications/nistpubs/, 2001.

[29] Z. Baker and V. Prasanna. Automatic synthesis of e�cient intrusion detection systems on

fpgas. Proceedings of the International Conference on Field-Programmable Logic and its

Applications, Bélgica, Septiembre 2004.

[30] J. Balasubramaniyan, J. Omar, D. Isaco�, G. Spa�ord, and D. Zamboni. An architecture for

intrusion detection using autonomous agents. Technical Report 98/05, COAST Laboratory,

Purdue University, West Lafayette, IN 47907-1398, USA, Junio 1998.

[31] P. Bania. Windows syscall shellcode. SecurityFocus, 2005.

[32] D. Barbará, N. Wu, and S. Jajodia. Detecting novel network intrusion using bayes estima-

tors. First SIAM International Conference on Data Mining, 2001.

[33] J. Barrus. A distributed autonomous-agent network-intrusion detection and response sys-

tem. Proceedings of the 1998 Command and Control Research and Technology Symposium,

Monterey, Canadá, Julio 1998.

[34] E. Bauer, D. Koller, and Y. Singer. Udpate rules for parameter estimation in bayesian

networks. Stanford University, AT&T Labs, 1996.

[35] S. Beattie, S. Arnold, C. Cowan, P. Wagle, C. Wright, and A. Shostack. Timing the

application of security patches for optimal uptime. In Proceedings of the 2002. USENIX

Systems Administration Conference (LISA)., November 2002.

[36] M. Bernaschi, E. Gabrielli, , and L. V. Mancini. Remus: a security-enhanced operating

system. ACM Transactions on Information and System Security 5, 36 (Feb.), 2002.

[37] Massimo Bernaschi, Emanuele Gabrielli, and Luigi V. Mancini. Operating system enhan-

cements to prevent the misuse of system calls. IAC-CNR. Viale del Policlinico, 137. 00161

Rome, Italy, 2000.

[38] BlindView. Strace for windows. 2005.

[39] Charles S. Bos. Markov chain monte carlo methods: Implementation and comparison.

Tinbergen Institute & Vrije Universiteit Amsterdam. In Progress., Agosto 2004.

[40] S. Bridges and R. Vaughn. Fuzzy data mining and genetic algorithms applied to intru-

sion detection. Proceedings of the 2000 National Information Systems Security Conference

(NISSC), Baltimore, USA, Octubre 2000.

385

[41] S. Bridges and R. Vaughn. Intrusion detection via fuzzy data mining. Proceedings of the

12th Annual Canadian Information Technology Security Symposium, Junio 2000.

[42] P. García Bringas and J.L. Val Román. Eside-depian: Entorno de seguridad inteligen-

te para la detección y prevención de intrusiones de red basado en anomalías. Bizkaiko

Foru Aldundia - Diputación Foral de Bizkaia, Berrikuntza eta Ekonomi Sustapen Saila -

Departamento de Innovación y Promoción Económica. Informe-Solicitud aprobado por el

programa Bizkaitek, 2004.

[43] H. K. Browne, W. A. Arbaugh, J. McHugh, and W. L. Fithen. A trend analysis of ex-

ploitations. In Proceedings of the 2001 IEEE Symposium on Security and Privacy, May

2001.

[44] D. L. Bruening. E�cient, transparent, and comprehensive runtime code manipulation.

Ph.D., M.I.T. http://www.cag.lcs.mit.edu/dynamorio/, 2004.

[45] B. Buck and J. K. Hollingsworth. An api for runtime code patching. The International

Journal of High Performance Computing Applications, 14(4):317 to 329., 2000.

[46] W. Buntine. Learning classi�cation trees. In Articial Intelligence Frontiers in Statistics:

AI and statistics III. Chapman and Hall, New York, 1994.

[47] D. Burroughs, L. Wilson, and G. Cybenko. Analysis of distributed intrusion detection

systems using bayesian methods analysis of distributed intrusion detection systems using

bayesian methods. Proceedings of the 21th International Performance Computing and Com-

munications Conference, Abril 2002.

[48] M. Bykova and S. Ostermann. Staistical analisys of malformed packets and their origins

in the modern internet. School of Electrical Engineering and Computer Science, Ohio

University, 2002.

[49] Kruegel C. Network alertness, towards an adaptative collaborating intrusion detection

system. 2002.

[50] Krügel C. Network alertness, towards an adaptative, collaborating intrusion detection

system. Dissertation for the degree of Doctor of Philosophy, University of Wien, Austria,

2002.

[51] Siddhartha C. The gibbs sampling algorithm. Disponible en

http://www.quantlet.com/mdstat/scripts/csa/html/node28.html, Septiembre 2005.

[52] A. Ghosh C. Michael. Using �nite automata to mine execution data for intrusion detection:

A preliminary report. RAID 2000, LNCS 1907, pp.66-79, 2000.

386

[53] CAIDA. Dynamic graphs of the nimda worm. Disponible en

http://www.caida.org/dynamic/analysis/security/nimda/, 2001.

[54] J. Cannady and J. Maha�ey. The application of arti�cial intelligence to misuse detection.

Proceedings of the First Recent Advances in Intrusion Detection (RAID) Conference, 1998.

[55] Shapiro M.W. Cantrill, B. M. and A. H. Leventhal. Dynamic instrumentation of production

systems. 6th Symposium on Operating Systems Design and Implementation,pp. 15?28.,

2004.

[56] Jannette Cardoso and Heloisa Camargo. Fuzziness in Petri Nets, Physica-Verlag. 98.

[57] E. Castillo, J.M. Gutiérrez, and A. Hadi. Sistemas expertos y modelos de redes probabilí-

sticas. Monografías de la Academia de Ingeniería, ISBN 8460093956, 1998.

[58] CERT Computer Emergency Response Team Coordination Center. Cert/cc overview in-

cident and vulnerability trends. Disponible en http://www.cert.org/present/cert-overview-

trends/, 2003.

[59] CERT Computer Emergency Response Team Coordination Center. Cert/cc statistics 1988-

2005. Disponible en http://www.cert.org/stats/certstats.html, 2005.

[60] CERT Coordination Center. Computer emergency response team coordination center home

page. http://www.cert.org/, 2006. Disponible en http://www.cert.org/.

[61] Jesús Cerquides and Ramón López de Mantaras. Tractable bayesian learning of tree aug-

mented naive bayes classi�ers. Instituto de Investigación en Inteligencia Arti�cial, CSIC,

2003.

[62] S. N. Chari and P.-C. Cheng. Bluebox: A policy-driven, host-based intrusion detection

system. In Proceedings of the 2002 ISOC Symposium on Network and Distributed System

Security (NDSS'02). San Diego, CA., 2002.

[63] E. Charniak. Statistical languaje learning. MIT Press, Cambridge, Massachusetts, 1993.

[64] S. Chavan, K. Shah, N. Dave, S. Mukherjee, A. Abraham, and S. Sanyal. Adaptative

neuro-fuzzy intrusion detection systems. Proceedings of the 2004 International Conference

on Information Technology: Coding and Computing (ITCC), Vol. 1, Pag. 70, 2004.

[65] S. Chebrolu, A. Abraham, and J. Thomas. Feature deduction and ensemble design of

intrusion detection systems. Computers and Security Journal, Vol. 24/4, Pag. 295-307,

Elsevier Science, 2005.

[66] P. Cheeseman and J. Stutz. Bayesian classi�cation (autoclass): Theory and results. Com-

puters and Security Journal, Vol. 24/4, Pag. 295-307, Elsevier Science, 1995.

387

[67] Jie Cheng and Russell Greiner. Learning bayesian belief network classi�ers: Algorithms and

systems. Canadian Imperial Bank of Commerce, Toronto, Ontario, Canada. Department

of Computing Science, University of Alberta Edmonton, Alberta, Canada, 2000.

[68] Fredrik Valeur Giovanny Vigna Christopher Kruegel, Darren Mutz. On the Detection of

Anomalous System Call Arguments. Springer Berlin / Heidelberg, 2003.

[69] CISCO. Cisco intrusion detection home page. Disponible en

http://www.cisco.com/warp/public/cc/pd/sqsw/sqidsz/, 2006.

[70] CMU. Carnegie mellon university home page. Disponible en http://www.cmu.edu/, 2006.

[71] J. Conesa, M. Contero, and P. Company. Comportamiento de los algoritmos de optimi-

zación en la reconstrucción geométrica de sólidos. Univerisidad Politecnica de Cartagena.

Universitat Jaume I, 2001.

[72] Cordis. Community research and development information service home page. Disponible

en http://www.cordis.lu/en/home.html, 2006.

[73] Intel Corporation. Probabilistic network library: User guide and referente manual. Systems

Technology Laboratories, Intel Corporation, 2004.

[74] Symantec Corporation. Ensuring your information is secure and available. Disponible en

http://www.symantec.com/, 2006.

[75] E. Cox. The fuzzy systems handbook: A practitioner's guide to building, using, and main-

taining fuzzy systems. AP Professional, Primera edició, ISBN 0121942708, Febrero 1994.

[76] M. Crosbie and G. Sa�ord. Applying genetic programming to intrusion detection. Working

Notes for the AAAI Symposium on Genetic Programming, Pag. 1-8, MIT, Cambridge,

USA, Diciembre 1995.

[77] M. Crosbie and G. Spa�ord. Active defense of a computer system using autonomous agents.

Technical Report 95-008, COAST Group, Department of Computer Sciences, Purdue Uni-

versity, West Lafayette, Indiana, USA, Febrero 1995.

[78] T. Crothers. Implementing intrusion detection systems: A hands-on guide for securing the

network. John Whiley and Sons, Incorporated. ISBN 0764549499, Diciembre 2002.

[79] CSI. Computer security institute home page. Disponible en http://www.gocsi.com/, 2006.

[80] CSO. Computer security o�cer: The resource for security executives. Disponible en

http://www.csoonline.com/, 2006.

[81] T. W. Curry. Pro�ling and tracing dynamic library usage via interposition. In USENIX

Summer 1994 Technical Conference, pages 267 to 278, Boston, MA., 1994.

388

[82] Goldberg D. The design of innovation: Lessons from and for competent genetic algorithms.

Addison-Wesley, Primera edición, ISBN 1402070985, Junio 2002.

[83] González D. Receive-only utp cables and network taps. Disponible en

http://www.dgonzalez.net/pub/roc/, 2003.

[84] González D. Sistemas de deteccion de intrusiones. Version 1.01, Disponible en

http://www.dgonzalez.net/pub/ids/, Julio 2003.

[85] Gonzalez D. Modelo de funcionamiento. 2005. Disponible

en:http://www.dgonzalez.net/pub/ids/html/cap03.htm.

[86] Heckerman D. A tutorial on learning with bayesian networks. Marzo 1995.

[87] Lowd D. Naive bayes models for probability estimation. Department of Computer Science

and Engineering. University of Washington, 2005.

[88] Shannon C. Y Moore D. The spread of the witty worm. IEEE Security and Privacy, Vol

2, N. 4, Julio Y Agosto 2004.

[89] Spa�ord E. Y Zamboni D. Intrusion detection using autonomous agents. Computer Ne-

tworks, 34(4):547-570, Octubre 2000.

[90] Upper D. Theory and algorithms for hidden markov models and generalized hidden markov

models. Dissertation for the degree of Doctor of Philosophy, Mathematics Department,

University of California, Berkeley, USA, Febrero 1997.

[91] Weakliem D. A critique of the bayesian information criterion for model selection. University

of Connecticut. Sociological Methods & Research, Vol. 27, No. 3, 359-397, 1999.

[92] Zamboni D. Using internal sensor for computer intrusion detection. Center for Education

and Research in Information Assurance and Security. Thesis submitted to the Faculty of

Purdue University, 2001.

[93] DARPA. Darpa intrusion detection evaluation. Disponible en

http://www.ll.mit.edu/IST/ideval/, Julio 2001.

[94] DARPA. Defense advanced research projects agency home page. Disponible en

http://www.darpa.mil/, 2006.

[95] GIOVANNI VIGNA CHRISTOPHER KRUEGEL DARREN MUTZ, FREDRIK VA-

LEUR. Anomalous system call detection. University of California, Santa Barbara - Tech-

nical University of Vienna, February.

389

[96] D. Dasgupta and F. González. An immunity-based technique to characterize intrusions

in computer networks. Transactions of the IEEE Evolutionary Computing, Vol. 6, No. 3,

Pag. 1081-1088, Junio 2002.

[97] A.P. Dawid. Prequential data analysis. In M. Ghosh and P. K. Pathak, editors, Current

Issues in Statistical Inference: Essays in Honor of D. Basu, IMS Lecture Notes�Monographs

Series 17, pages 113�126. Institute of Mathematical Statistics, Hayward, California, 1992.

[98] Red Iris: Red Española de Investigacion y Desarrollo. Servicio de seguridad iris-cert.

http://www.rediris.es/cert/, 2006. Disponible en http://www.rediris.es/cert/.

[99] Tatum Consultoría Comercial Y de Marketing. Informe de e-commerce (b2c). Disponible

en http://www.tatum.es/, 2004.

[100] H. Debar, M. Dacier, and A. Wespi. Towards a taxonomy of intrusion-detection systems.

Computer Networks, Vol. 31, No. 8, Pag. 805-822, Abril 1999.

[101] H. Debar, M. Dacier, and A. Wespi. A revised taxonomy for intrusion-detection systems.

Annales des Télécommunications, Vol. 55, Pag. 361-378, 2000.

[102] H. Debar, M. Huang, and D. Donahoo. Intrusion detection exchange format data mo-

del. Disponible en http://www.ietf.org/internet-drafts/draft-ietf-idwg-datamodel-03.txt, Ju-

nio 2000.

[103] Comision del Mercado de las Telecomunicaciones. Informe sobre el comercio electronico

en españa a través de entidades de medios de pago (4âo trimestre 2004). Disponible en

http://www.cmt.es/cmt/centroinfo/publicaciones/index.htm, 2005.

[104] A. Dempster, N. Laird, and D. Rubin. Maximum likelihood from incomplete data via the

em algorithm. Journal of the Royal Statistical Society, Series B, 39(1):1�38, 1977.

[105] D. Denning. An intrusion detection model. IEEE Transactions on Software Engineering

13, 2 (Feb.), 222-232, 1987.

[106] J.E. Dickerson and J.A. Dickerson. Fuzzy network pro�ling for intrusion detection. Pro-

ceedings of the NAFIPS 19th International Conference of the North American Fuzzy In-

formation Processing Society, Pag. 301-206, Atlanta, USA, Julio 2000.

[107] J.E. Dickerson, J. Juslin, O. Koukousoula, and J.A. Dickerson. Fuzzy intrusion detection.

Proceedings of the IFSA World Congress and NAFIPS 20th International Conference of the

North American Fuzzy Information Processing Society, Vol. 3, Pag. 1506-1510, Vancouver,

Canada, Julio 2001.

[108] Full Disclosure. An unmoderated mailing list for the discussion of security issues. Disponible

en https://lists.grok.org.uk/mailman/listinfo/full-disclosure, 2006.

390

[109] DoD. United states department of defense home page. Disponible en

http://www.defenselink.mil/, 2006.

[110] P. Dokas, L. Ertoz, V. Kumar, A. Lazarevic, J. Srivastava, and P. Tan. Data mining for

network intrusion detection. Proceedings of the NSF Workshop on Next Generation Data

Mining, Baltimore, USA, Noviembre 2002.

[111] P. Domingos and M. Pazzani. On the optimality of the simple bayesian classi�er under

zero-one loss. Machine Learning, 29:103-130, 1997.

[112] J. Doyle, I. Kohane, W. Long, H. Shrobe, and P. Szolovits. Event recognition beyond

signature and anomaly. Proceedings of the 2001 IEEE Workshop on Information Assurance

and Security United States Military Academy, West Point, New York, USA, Junio 2001.

[113] M. Druzdzel and H. Simon. Causality in bayesian belief networks. Proceedings of the

9th Conference on Uncertainty in Arti�cial Intelligence, Pag. 3-11, Washington, Morgan

Kaufmann, San Mateo, California, USA, 1993.

[114] F.J. Díez. Local conditioning in bayesian networks. Arti�cial Intelligence, 87:1�20, 1996.

[115] F.J. Díez. Introducción al razonamiento aproximado. Departamento de Inteligencia Arti-

�cial, Universidad de Educación a Distancia, 1998.

[116] Lundin E. Logging for intrusion and fraud detection. Thesis for the degree of Doctor of

Philosophy, Department of Computer Engineering, Chalmers University, Göteborg, Suecia,

2004.

[117] Lunding E. Logging for intrusion and fraud detection. Thesis for the degree of Doctor of

Philosophy Department of Computer Engineering, 2004.

[118] Spa�ord E. The internet worm: Crisis and aftermath. Communications of the ACM,

32(6):678-687, Junio 1989.

[119] S. Eckmann. Translating snort rules to statl scenarios. Fourth International Symposium

on Recent Advances in Intrusion Detection, University of California Davis, Lecture Notes

in Computer Science 2212, Pag. 69-84, Octubre 2001.

[120] S. Eckmann, G. Vigna, and R. Kemmerer. Statl: An attack languaje for state-based intru-

sion detection. Technical Report, Department of Computer Science, University of Califor-

nia, Santa Barbara, USA, 2000.

[121] A. Eiben and J. Smith. Introduction to evolutionary computing. Springer, Primera edición,

ISBN 3540401849, Noviembre 2003.

391

[122] D. Endler. Intrusion detection. applying machine learning to solaris audit data. Proceedings

of the 14th Annual Computer Security Applications Conference (ACSAC), Pag. 268, 1998.

[123] esCERT. Equipo de seguridad para la coordinacipn de emergencias en redes te-

lematicas. http://www.escert.org/index.php/web/es/index.html, 2006. Disponible en

http://www.escert.org/index.php/web/es/index.html.

[124] E. Eskin. Anomaly detection over noisy data using learned probability distributions. In

Proceedings of ICML 2000, Menlo Park, CA, 2000. AAAI Press., 2000.

[125] E. Eskin, W. N. Grundy, and Y. Singer. Protein family classi�cation using sparse markov

transducers. In Proceedings of the Eighth International Conference on Intelligent Systems

for Molecular Biology, Menlo Park, CA. AAAI Press., 2000.

[126] Eleazar Eskin, Wenke Lee, J. Salvatore, and Stolfo. Modeling system calls for instrusion

detecction with dynamic window sizes. 2001.

[127] The Common Criteria Evaluation and Validation Scheme. Common criteria for information

technology security evaluation. Version 3.0, Junio 2005.

[128] FBI. Federal bureau of investigation home page. Disponible en http://www.fbi.gov, 2006.

[129] FBI/CSI. 2005 fbi/csi computer crime and security survey. Disponible en

http://www.gocsi.com/, 2005.

[130] P. Felgaer, P. Britos, J. Sucre, A. Servetto, R. García-Martínez, and G. Perichinsky. Op-

timización de redes bayesianas basado en técnicas de aprendizaje por inducción. 1995.

[131] H. Feng, O. Kolesnikov, P. Fogla, and W. Lee. Anomaly detection using call stack infor-

mation. In Proceedings of the 2003 IEEE Symposium on Security and Privacy., 2003.

[132] Security Focus. Bugtraq mailing list. Disponible en

http://www.securityfocus.com/archive/1, 2006.

[133] B. Fonseca. The ips question. InfoWorld Magazine. Disponible en

http://www.infoworld.com/article/03/04/04/14ips1.html?security, Abril 2003.

[134] S. Forrest, S. A. Hofmeyr, A. Somayaji, and T. A. Longsta�. A sense of self for unix

processes. In Proceedings of the 1996 IEEE Symposium on Security and Privacy, pages ,

Los Alamitos, CA. IEEE Computer Society Press., 1996.

[135] Friedman, Geiger, and Goldszmidt. Bayesian network classi�ers. University of California.

AT&T Labs, 1997.

[136] N. Friedman and M. Goldszmidt. Sequential update of bayesian network structure. Uni-

versity of California, Computer Science Division. SRI International, 1995.

392

[137] N. Friedman and Y. Singer. E�cient bayesian parameter estimation in large discrete

domains. Computer Science Division University of California. AT&T Labs, 1997.

[138] Fyodor. The art of port scanning. Disponible en http://www.insecure.org/nmap/, 1997.

[139] Wolf D. G. Statement before the house committee on government reform, subcommittee

on government e�ciency, �nancial management and intergovernmental relations, and the

subcommittee for technology and procurement policy. Federal Information Security Reform

Act, 2002.

[140] D.B. G. Hunt. Detours: Binary interception of win32 functions. Microsoft Research, 1999.

[141] Debin Gao, Michael K. Reiter, and Dawn Song. Gray-box extraction of execution graphs

for anomaly detection. Proceedings of the 11th ACM conference on Computer and commu-

nications security, October 2004.

[142] T. Gar�nkel and M. Rosenblum. A virtual machine introspection based architecture for

intrusion detection. In Proceedings of the 2003 Network and Distributed System Security

Symposium (NDSS), February, 2003.

[143] A.E. Gelfand and A.F.M. Smith. Sampling-based approaches to calculating marginal den-

sities. Journal of the American Statistical Association, 85: 398-409, 1990.

[144] S. Geman and D. Geman. Stochastic relaxation, gibbs distributions and the bayesian

restoration of images. IEEE Transactions on Pattern Analysis and Machine Intelligence,

12: 609-628, 1984.

[145] Zhihai Wang Geof Webb, Janice Boughton. Not so naive bayesian classi�cation. Monash

University, Melbourne, Australia.

[146] Wanken J. Ghosh, A. and F. Charron. Detecting anomalous and unknown intrusions

against programs. In Proceedings of the Annual Computer Security Application Conference

(ACSAC'98). Scottsdale, AZ. 259-267, 1998.

[147] Golomb03. Intrusion detection methodologies demysti�ed. Enterasys Networks Incorpora-

ted Technical Whitepaper, Diciembre 2003.

[148] Schwartzbard A. y Schatz M. Gosh A. Learning program behavior pro�les for intrusion

detection. Proceedings of the �rst USENIX Workshop on Intrusion Detection and Network

Monitoring, Santa Clara, California, USA, Abril 1999.

[149] Ledesma B. y Brotons F. Grediaga A., Ibarra F. Utilización de redes neuronales para la de-

tección de intrusos. Departamento de Tecnología Informática y Computación, Universidad

de Alicante, 2002.

393

[150] Abraham A. y Han S. Grocan C. Mepids: Multi-expression programming for intrusion de-

tection system. International Work-Conference on the Interplay between Natural and Arti-

�cial Computation (IWINAC), Lecture Notes in Computer Science, LNCS 3562, Springer-

Verlag, Pag. 163-172, España, 2005.

[151] Oulu University Secure Programming Group. Glossary of vulnerability testing terminology.

Disponible en http://www.ee.oulu.�/research/ouspg/sage/glossary/, 2004.

[152] John Gulbrandsen. System call optimization with the sysenter instruction. codeguru, 2004.

[153] Kim J. H. Convince: A conversational inference consolidation engine. Tesis doctoral, Dept.

Computer Science, University of California, Los Angeles, 1983.

[154] Kvarnstram H. A survey of commercial tools for intrusion detection. Technical Report

TR99-8, Department of Computer Engineering, Chalmers University of Technology, Gote-

borg, Suecia, 1999.

[155] Tijms H. Understanding probability: Chance rules in everyday life. Cambrigde University

Press, ISBN 0521540364, Agosto 2004.

[156] Zhang Z. Y Shen H. Online training of SVMs for real-time intrusion detection. Proceedings

of the International Conference on Advanced Information Networking and Applications

(AINA), Vol. 1, Pag. 568, 2004.

[157] D. R. Simon H. J. Wang, C. Guo and A. Zugenmaier. Shield: Vulnerability-driven ne-

twork �lters for preventing known vulnerability exploits. In Proceedings of the 2004 ACM

SIGCOMM Conference, August, 2004.

[158] Mannila H. y Smyth P. Hand D. Principles of data mining. MIT Press, ISBN 026208290X,

Cambridge, Massachusetts, USA, 2001.

[159] R. Hastings and B. Joyce. Purify: Fast detection of memory leaks and access errors. In

Procedings of the Winter USENIX Technical Conference, San Francisco, CA., January

1992.

[160] Maccabe A. y Servilla M. Heady R., Luger G. The architecture of a network level intrusion

detection system. Technical Report, Department of Computer Science, University of New

Mexico, USA, Agosto 1990.

[161] Levitt K. N. Mukherjee B. Wood J. y Wolber D. Heberlein L.T., Dias G.V. A network

security monitor. Proceeding of the IEEE Symposium on Research in Security and Privacy,

Pag. 296-304, Mayo 1990.

394

[162] Keromytis A. y Stolfo S. Heller K., Svore K. One class support vector machines for detecting

anomalous windows registry accesses. Proceedings of the ICDM Workshop on Data Mining

for Computer Security (SMSEC), Melbourne, Florida, USA, Noviembre 2003.

[163] Honavar V. Miller L. y Wang Y. Helmer G., Wong J. Lightweight agents for intrusion

detection. Elsevier Journal of Systems and Software, No. 67, Pag. 109-122, 2003.

[164] S. Y. Ho. Intrusion detection systems for today and tomorrow. SANS Institute. Information

Security Reading Room, 2001.

[165] Meier M. y König H. Holz T. High-e�cient intrusion detection infraestructure. Infrastruc-

ture. DFN-Arbeitstagung über Kommunikationsnetze, 217-232, 2003.

[166] R.A. Howard and J. Matheson. Readings on the principles and applications of decision

analysis. Strategic Decisions Group, Menlo Park, 1981.

[167] Liao Y. y Vemuri R. Hu W. Robust support vector machines for anomaly detection in

computer security. Proceedings of the 2003 International Conference on Machine Learning

and Applications (ICMLA), Los Angeles, California, USA, Junio 2003.

[168] G. Hunt and D. Brubacher. Detours: Binary interception of win32 functions. USENIX

Windows NT Symposium, 1999.

[169] IETF. Internet engineering task force home page. Disponible en http://www.ietf.org/, 2006.

[170] Kemmerer R. y Porras P. Ilgun K. State transition analysis: A rule-based intrusion detec-

tion approach. IEEE Transactions on Software Engineering, Vol. 21, No. 3, Pag. 181-199,

1995.

[171] Enterasys Networks Incorporated. Enterasys dragon intrusion defense. Disponible en

http://www.enterasys.com/products/ids/, 2006.

[172] Forrester Incorporated. Forrester research: Technology research and advice home page.

Disponible en http://www.forrester.com/, 2006.

[173] Gartner Incorporated. Gartner group: It research and analysis home page. Disponible en

http://www.gartner.com/, 2006.

[174] Tripwire Incorporated. Tripwire change auditing solutions home page. Disponible en

http://www.tripwire.com/, 2006.

[175] INOUE, Hiroaki Akihisa Ikeno, Masaki Kondo, Junji Sakai, and Masato Edahiro. Virtus:

A new processor virtualization architecture for security-oriented next-generation mobile

terminals. System Devices Research Laboratories, NEC Corporation, 1120, Shimokuzawa,

Sagamihara, Kanagawa, 229-1198 Japan. - NEC Informatec Systems, Ltd. 3-2-1, Sakado,

Takatsu-ku, Kawasaki, Kanagawa, 213-0012 Japan, July, 2006.

395

[176] Ulrich Ultes-Nitsche. Inseon Yoo. Adaptative detection of worm/viruses in �rewalls. De-

partament of Informatics, University of Fribourg, Switzerland, 2002.

[177] SANS Institute. SANS glossary of terms used in security and intrusion detection. Disponible

en http://www.sans.org/resources/glossary.php, 2005.

[178] Red Iris. Red española de investigación y desarrollo. Disponible en http://www.rediris.es/,

2006.

[179] IWS. Top 20 countries with the highest number of internet users. Disponible en

http://www.internetworldstats.com/top20.htm, 2005.

[180] IWS. World internet users and population stats. Disponible en

http://www.internetworldstats.com/stats.htm, 2005.

[181] IWS. Internet world stats home page. Disponible en http://www.internetworldstats.com/,

2006.

[182] Giron F. J. Regresión logística y análisis discriminante robustos: un enfoque bayesiano.

Universidad de Málaga, 2005.

[183] Luo J. Integrating fuzzy logic with data mining methods for intrusion detection. Technical

Report, Mississippi State University, 1999.

[184] McHugh J. The 1998 licoln laboratory ids evaluation: A critique. Proceedings of the 3th

International Workshop on Recent Advances in Intrusion Detection, Vol. 1907 of Lecture

Notes in Computer Science, Springer-Verlag, Tolouse, Francia, Octubre 2000.

[185] Pearl J. Reverend bayes on inference engines: A distributed hierarchical approach. Pro-

ceedings of the AAAI National Conference on AI, Pag. 133-136, Pittsburgh, PA, Agosto

1982.

[186] Pearl J. Fusion, propagation and structuring in belief networks. Arti�cial Intelligence,

29:241 288, 1986.

[187] Pearl J. Probabilistic reasoning in intelligent systems: Networks of plausible inference.

Morgan Kaufmann, ISBN 1558604790, Septiembre 1988.

[188] Pearl J. From conditional oughts to qualitative decision theory. Proceedings of the 9th Con-

ference on Uncertainty in Arti�cial Intelligence, Pag. 12-20, Washington, Morgan Kauf-

mann, San Mateo, California, USA, 1993.

[189] Pearl J. Causal diagrams for empirical research. Biometrika, 82:669-710, 1995.

[190] Robins J. A new approach to causal inference in mortality studies with sustained exposure

results. mathematical modelling. 7:1393-1512, 1986.

396

[191] Schenier B. Y Kelsey J. Secure audit logs to support computer forensics. ACM Transactions

on Information and System Security, 2(2), Mayo 1999.

[192] B. Ravichandran J. B. D. Cabrera and R. K. Mehra. Statistical tra�c modeling for network

intrusion detection. In Proceedings of the Eighth International Symposium on Modeling,

Analysis, and Simulation of Computer and Telecommunications Systems, pages 466-473,

San Francisco, CA. IEEE Computer Society., August, 2000.

[193] B. Karp J. Newsome and D. Song. Ploygraph: Automatically generating signatures for

polymorphic worms. In Proceedings of the IEEE Symposium on Security and Privacy,

May, 2005.

[194] S. Jha J. T. Gi�n and B. P. Miller. Detecting manipulated remote call streams. USENIX

Security Symposium., August 2002.

[195] S. Jha J. T. Gi�n and B. P. Miller. E�cient context-sensitive intrusion detection. 11th

Annual Network and Distributed System Security Symposium., February 2004.

[196] Karygiannis T. y Marks D. Jansen W., Mell P. Mobile agents in intrusion detection

and response. Proceedings of the 12th Annual Canadian Information Technology Security

Symposium, Ottawa, Canadá, 2000.

[197] S. L. Lauritzen Jensen F. V. and K. G. Olesen. Bayesian updating in causal probabilistic

networks by local computations. Computational Statistics Quarterly 4, 269�282, 1990.

[198] Scott M. Lewandowski Robert K. Cunningham Jesse C. Rabek, Roger I. Khazan. Detection

of injected, dynamically generated, and obfuscated malicious code. Massachusetts Institute

of Technology, Lincoln Laboratory, 244 Wood Street, Lexington., October 2003.

[199] Lundy Lewis Joao B. D. Cabrera and Raman K. Mehra. Detection and classi�cation of

intrusions and faults using sequences of system calls. Scienti�c Systems Company, 500

West Cummings Park, Suite 3000. Woburn MA 01801 USA, December, 2001.

[200] M. B. Jones. Interposition agents: Transparently interposing user code at the system

interface. In Proceedings of the Symposium on Operating Systems Principles, pages 80 to

93, Asheville, NC., 1993.

[201] Chongkyung Kil Yan Zhai Chris Bookholt Jun Xu, Peng Ning. Automatic diagnosis and

response to memory corruption vulnerabilities. Cyber Defense Laboratory. Department of

Computer Science. North Carolina, State University, November, 2005.

[202] Gubbels K. Hands in the honeypot. SANS Institute Information Security Reading Room.

GIAC Security Essentials Certi�cation (GSEC), Practical Assignment, Version 1.4b, 2002.

397

[203] Ilgun K. Ustat: A real-time intrusion detection system for unix. Proceedings of the IEEE

Symposium on Research on Security and Privacy, Oakland, USA, Mayo 1993.

[204] Jackson K. Intrusion detection system product survey. Technical Report LA-UR-99-3883.

Distributed Knowledge Systems Team, Computer Research and Applications Group, Los

Alamos National Laboratory, New Mexico, Junio 1999.

[205] Julisch K. Using root cause analysis to handle intrusion detection alarms. IBM Zurich

Research Laboratory. Dissertation for the degree of Doctor of Philosophy, University of

Dortmund, Alemania, 2003.

[206] Murphy K. An introduction to graphical models. TechnicalReport, Intel Research, Intel

Corporation, Mayo 2001.

[207] Valdés A. Y Skiner K. Probabilistic alert correlation. Proceedings of the 4th International

Symposium on Recent Advances in Intrusion Detection, Pag. 54-68, 2001.

[208] Staniford-Chen S. y Tung B. Kahn C., Porras P. A common intrusion detection framework.

Journal of Computer Security, Julio 1998.

[209] Tierney L. Kass, R. and J. Kadane. Asymptotics in bayesian computation. In Bernardo,

J., DeGroot, M., Lindley, D., and Smith, A., editors, Bayesian Statistics 3, pages 261-278.

Oxford University Press, 1988.

[210] H. A. Kim and B. Karp. Autograph: Toward automated, distributed worm signature

detection. In Proceedings of the 13th Usenix Security Symposium, August, 2004.

[211] Nguyen H. y Park J. Kim D. Genetic algorithm to improve svm based network intrusion de-

tection system. Proceedings of the 19th International Conference on Advanced Information

Networking and Applications (AINA), Vol. 2, Pag. 155-158, 2005.

[212] Samuel T. King and Peter M. Chen. Backtracking intrusions. Department of Electrical

Engineering and Computer Science. University of Michigan, February, 2005.

[213] Ruschitzka M. y Levitt K. Ko C. Execution monitoring of security-critical programs in

distributed systems: A speci�cation-based approach. Proceedings of the 1997 IEEE Sym-

posium on Security and Privacy, Oakland, USA, 1997.

[214] C. Kreibich and J. Crowcroft. Honeycomb - creating intrusion detection signatures using

honeypots. In Proceedings of the Second Workshop on Hot Topics in Networks (HotNets-II),

November, 2003.

[215] Robertson W. y Valeur F. Krügel C., Mutz D. Bayesian event classi�cation for intrusion

detection. Proceedings of the 19th Annual Computer Security Applications Conference, Las

Vegas, Diciembre 2003.

398

[216] Vigna G. y Kemmerer R. Krügel C., Valeur F. Stateful intrusion detection for high-speed

networks. Proceedings of the IEEE Symposium on Security and Privacy, IEEE Press, Pag.

285-293, Oakland, USA, Mayo 2002.

[217] G. Krügel. C, Vigna. Anomaly detection of web-based attacks. Reliable Software Group,

University of California, Santa Barbara, 2003.

[218] R. Kuster. Three ways to inject your code into another process. 2003.

[219] Me L. Gassata, a genetic algorithm as an alternative tool for security audit trails analysis.

First International Workshop on the Recent Advances in Intrusion Detection, Louvain-la-

Neuve, Belgica, Septiembre 1998.

[220] Skoudis E. Y Zeltser L. Malware: Fighting malicious code. Prentice Hall, Primera Edición,

ISBN 0131014056, Noviembre 2003.

[221] Spitzner L. Honeypots: Tracking hackers. Addison-Wesley Professional, ISBN 0321108957,

2002.

[222] Kaspersky Lab. Premier protection against viruses, hackers and spam. Disponible en

http://www.kaspersky.com/, 2006.

[223] L. C. Lam and T. Chiueh. Automatic extraction of highly accurate application-speci�c

sandboxing policy. In Seventh International Symposium on Recent Advances in Intrusion

Detection, Sophia Antipolis, French Riviera, France., September 2004.

[224] Lap-Chung Lam, Wei Li, and Tzi cker Chiueh. Accurate and automated system call policy-

based intrusion prevention. 2006 International Conference on Dependable Systems and Ne-

tworks (DSN 2006), 25-28 June 2006, Philadelphia, Pennsylvania,USA, Proceedings .IEEE

Computer Society, 2006.

[225] J. Larus and E. Schnarr. Eel: Machine-independent executable editing. In Proceedings of the

ACM SIGPLAN '95 Conference on Programming Language Design and Implementation,

La Jolla, CA., June 1995.

[226] Dawson R. Lavori P.W. and Shera D. A multiple imputation strategy for clinical trials

with truncation of patient data. Statistics in Medicine, 14, 1913�1925, 1995.

[227] Kumar V. Ozgur A. y Srivastava J. Lazarevic A., Ertoz L. A comparative study of anomaly

detection schemes in network intrusion detection. SIAM International Conference on Data

Mining, Mayo 2003.

[228] Chan P. Eskin E. Fan W. Miller M. Hershkop S. y Zhang J. Lee W., Stolfo S. Real time

data mining-based intrusion detection. Proceedings of the second DARPA Information

Survivability Conference and Exposition, 2001.

399

[229] Stolfo S. y Mok K. Lee W. A data mining framework for building intrusion detection

models. Proceedings of the IEEE Symposium on Security and Privacy, Pag. 120-132, 1999.

[230] Tseng S. y Lin S. Lin Y. An intrusion detection model based upon intrusion detection

markup languaje (idml). Department of Computer and Information Science, National

Chiao Tung University, Taiwan, Agosto 2001.

[231] U. Lindqvist and P. Porras. Detecting computer and network misuse with the produc-

tion based expert system toolset (p-best). In IEEE Symposium on Security and Privacy.

Oakland, CA. 146-161., 1999.

[232] Fried D. Korba J. y Das K. Lippmann R., Haines J. The 1999 darpa o�-line intrusion

detection evaluation. Computer Networks, Vol. 34(4):579-595, Elsevier Science, Octubre

2000.

[233] Zhen Liu and Susan M. Bridges. Dynamic learning of automata from the call stack log for

anomaly detection. Department of Computer Science and Engineering. Mississippi State

University, April, 2005.

[234] Cohn R. Muth R. Patil H. Klauser A. Lowney G. Wallace S. Reddi V. J. Luk, C. and

K. Hazelwoo. Pin: Building customized program analysis tools with dynamic instrumenta-

tion. ACM SIGPLAN Conference on Programming Language Design and Implementation

(PLDI), Chicago, IL, USA, pp. 190?200., 2005.

[235] T. F. Lunt. Detecting intruders in computer systems. In Proceedings of the Sixth Annual

Symposium and Technical Displays on Physical and Electronic Security,, 1993.

[236] Teresa F. Lunt and R. Jagannathan. A prototipe real-time intrusion-detection expert

system. IEEE Symposium on Security and Privacy,, 1988.

[237] Gilham F. Jagannathan R. Newumann P. y Jalali C. Lunt T., Tamaru A. Ides: A progress

report. Proceedings of the 6th Annual Computer Security Applications Conference, 1990.

[238] Llorens M. Redes recon�gurables. modelizacion y veri�cacion. Tesis Doctoral, Depar-

tamento de Sistemas Informaticos y Computacion, Universidad Politecnica de Valencia,

2003.

[239] Olmsted Scott M. On representing and solving decision problems. Ph.D. thesis, Stanford

University, Department of Engineering-Economic Systems, Stanford, CA, Diciembre 1983.

[240] Ranum M. Coverage in intrusion detection systems. Technical Publication. NFR Security

Incorporated Technical Publication, Junio 2001.

[241] Ranum M. Experiences benchmarking intrusion detection systems. NFR Security Incor-

porated Technical Publication, Diciembre 2001.

400

[242] Roesch M. Snort: Lightweight intrusion detection for networks. Proceedings of LISA'99:

13th Systems Administration Conference, Pag. 229-238, Noviembre 1999.

[243] Roesch M. Next-generation intrusion prevention: The pre-attack period. 2005. Disponible

en http://searchsecurity.techtarget.com/tip/1289483sid14gci112130700.html.

[244] Ye N. Y Xu M. Probabilistic networks with undirected links for anomaly detection. Works-

hop on Information Assurance and Security, Proceedings of the IEEE, Pag. 175-179, 2000.

[245] N. Fakotakis G. Kokkinakis M. Maragoudakis, E. Kavallieratou. How conditional indepen-

dence assumption a�ects handwritten character segmentation. Department of Electrical

and Computer Engineering, University of Patras, Greece, 2000.

[246] Carla Marceau. Characterizing the behavior of a program using multiple-length n-grams.

Odyssey Research Associates. Ithaca, NY 14850, February, 2001.

[247] Jose Ignacio Sánchez Martín. Técnicas de modelado de llamadas al sistema como aproxi-

mación a la detección de intrusiones en sistemas gnu/linux, microsoft windows 2000/xp y

microsoft windows mobile. 2006.

[248] Wes Masri and Andy Podgurski. Using dynamic information �ow analysis to detect atta-

cks against applications. Computer Science Department. American University of Beirut.

Beirut, Lebanon 1107 2020 - Electrical Engineering and Computer Science Department.

Case Western Reserve University. Cleveland, OH 44106, May, 2005.

[249] Lippmann R. Haines J. y Zissman M. Mell P., Hu V. An overview of issues in testing intru-

sion detection systems. Technical report, National Institute of Standards and Technology,

Massachusetts Institute of Techonology Lincoln Laboratory, USA, Junio 2003.

[250] M. Miller. Understanding windows shellcode. nologin, 2003.

[251] MIT. Massachusetts institute of technology home page. Disponible en http://www.mit.edu/,

2006.

[252] Trevor Jim Richard Schlichting Mohan Rajagopalan, Matti Hiltunen. Authenticated sys-

tem calls. Department of Computer Science, The University of Arizona. AT and T Labs-

Research, 180 Park Avenue, July, 2006.

[253] Savage S. Shannon C. Staniford-Chen S. y Weaver N. Moore D., Paxson V. The spread of

the sapphire/slammer worm. IEEE Security and Privacy, Vol 1, N. 4, Julio-Agosto 2003.

[254] Shannon C y Brown J. Moore D. Code-red: A case study on the spread and victims of an

internet worm. Internet Measurement Workshop (IMW), 2002.

401

[255] Heberlein T. y Levitt K. Mukherjee B. Network intrusion detection. IEEE Network,

8(3):26-41, Junio 2004.

[256] Sung A. y Abraham A. Mukkamala S. Intrusion detection using an ensemble of intelligent

paradigms. Journal of Network and Computer Applications, No. 28, Pag. 167-182, Elsevier

Science, 2005.

[257] N. Nethercote and J. Seward. Valgrind: A program supervision framework. In 3rd Workshop

on Runtime Veri�cation, 2003.

[258] P. G. Neumann and P. A. Porras. Experience with emerald to date. In Proceedings of the

Usenix Workshop on Intrusion Detection, 1999.

[259] James Newsome and Dawn Song. Dynamic taint analysis for automatic detection, analysis,

and signature generation of exploits on commodity software. In Proceedings of the 12th

Annual Network and Distributed System Security Symposium (NDSS), 2005.

[260] NIST. National institute of standards and technology home page. Disponible en

http://www.nist.gov/, 2006.

[261] Novell. Linux audit-subsystem design documentation for kernel 2.6. 2004.

[262] NSA. National security agency home page. Disponible en http://www.nsa.gov/, 2006.

[263] University of California. Lawrence livermore national laboratory home page. Disponible

en http://www.llnl.gov/, 2006.

[264] University of California Davis. University of california davis home page. Disponible en

http://www.ucdavis.edu/, 2006.

[265] CSO. Computer Security O�cer. 2005 e-crime watch survey. Disponible en

http://www.csoonline.com, 2005.

[266] Lauritzen S. y Jensen F. Olesen K. ahugin: A system creating adaptive causal probabilistic

networks. Dubois et al. Eds, Pag. 223-229, 1992.

[267] United Nations. United Nations Conference on Trade and Development. E-commerce and

development report 2002. 2002.

[268] United Nations. United Nations Conference on Trade and Development. E-commerce and

development report 2004. 2004.

[269] A. One. Smashing the stack for fun and pro�t. Phrack, 7(49):14, 1996.

[270] William Osser. Auditing in the solaris8 operating environment. Sun BluePrints, 2002.

402

[271] Inella P. The evolution of intrusion detection systems. 2001. Security Focus. Disponible en

http://www.securityfocus.com/infocus/1514, 2001.

[272] Proctor P. Computer misuse detection system (cmds) concepts. Science Applications

International Corporation (SAIC), Technical Paper, 1996.

[273] Wellman M. P. Fundamental concepts of qualitative probabilistic networks. Arti�cial

Intelligence, 44:257 303, 1990.

[274] Wellman M. P. Graphical inference in qualitative probabilistic networks. Networks, 20:687

701, 1990.

[275] Winston P. Arti�cial intelligence. Addison Wesley, Reading, Massachusetts, Tercera Edi-

ción, ISBN 0201533774, Enero 1992.

[276] K. Fraser S. Hand T. Harris A. Ho R. Neugebauer I. Pratt P. Barham, B. Dragovic and

A. War�eld. Xen and the art of virtualization. In Proceedings of the 2003 Symposium on

Operating Systems Principles, October, 2003.

[277] V. Paxson. Bro: A system for detecting network intruders in real-time. In Proceedings of

7th USENIX Security Symposium. San Antonio, TX, 1998.

[278] Shachter R. D. Peot M.A. Fusion and propagation with multiple observations in belief

networks. Arti�cial Intelligence, 48:299�318, 1991.

[279] J. Picciotto. The desing of an e�ective auditing subsystem. The MITRE Corporation,

Bedford, Massachusetts, 1978.

[280] Elo� J. y Venter H. Pillai M. An approach to implement a network intrusion detection

system using genetic algorithms. Proceedings of the 2004 annual research conference of the

South African institute of computer scientists and information technologists on IT research

in developing countries, ACM International Conference Proceedings Series, Vol. 75, 2004.

[281] Uday Joshi Prem Uppuluri and Arnab Ray. Preventing race condition attacks on �le-

systems. Dept. of Computer Science University of Missouri at Kansas City, MO, 641 10 -

Dept. of Computer Science State University of New York Stony Brook, NY, 11790, 2005.

[282] The Honeynet Project. Know your enemy: Trend analysis. Disponible en

http://honeynet.org/papers/kye.html, 2004.

[283] The Honeynet Project. To learn tools, tactics and motives involved in computer and

network attacks, and share the lessons learned. Disponible en http://project.honeynet.org/,

2006.

403

[284] Je�erson Provost. Naive bayes vs rule-learning in classi�cation of email. Departmen of

Computer Sciences, University of Texas, Austin, 1999.

[285] Xueyao Li Qingbo yin, Rubo Zhang. An new intrusion detection method based on linear

prediction. 2002 Symposium on Applications and the Internet, 2002.

[286] Johnston. S. R. The impact of privacy and data protection legislation on the sharing of

intrusion detection information. In Proceedings of the 4th International Symposium on

Recent Advances in Intrusión Detection, Lecture Notes in Computer Science, 2212, 2001.

[287] Shachter R. Probabilistic inference and in�uence diagrams. Operations Research, No. 36,

Pag. 589-604, 1988.

[288] Shirey R. Internet security glossary. Internet RFC 2828. The Internet Society, Ne-

twork Working Group, GTE/BBN Technologies. Disponible en http://www.ietf.org/rfc/

/rfc2828.txt, Mayo 2000.

[289] J. Gagnon R. K. Mukkamala and S. Jajodia. Integrating data mining techniques with

intrusion detection. In V. Atluri and J. Hale, editors, Research Advances in Database and

Information Systems Security, pages 33-46. Kluwer Publishers, 2000.

[290] L. R. Rabiner. A tutorial on hidden markov models and selected applications in speech

recognition. Proceedings of the IEEE, 77(2)., 1989.

[291] L. R. Rabiner and B. H. Juang. An introduction to hidden markov models. IEEE ASSP

Magazine, pages 4 to 16, Jannuary., 1986.

[292] RaiSe. Lkm rootkits en linux x86 v2.6. enye-sec, 2005.

[293] Jan Vitek Rajeev Gopalakrishna, Eugene H. Spa�ord. E�cient intrusion detection using

automaton inlining. Center for Education and Research in Information Assurance and

Security. Department of Computer Sciences. Purdue University, May, 2005.

[294] Stolarchuk M. Sienkiewicz M. Lambeth A. y Wall E. RanumM., Land�eld K. Implementing

a generalized tool for network monitoring. Proceedings of the 11th Systems Administration

Conference, San Diego, California, USA, Octubre 1997.

[295] Red.es. Entidad pública empresarial red.es. Disponible en http://red.es/, 2006.

[296] Cordis. Community Research and Development Information Service. Information society

technologies. Disponible en http://www.cordis.lu/fp6/ist.htm, 2006.

[297] NATO Research and Technology Organisation. Intrusion detection: Generics and state-of-

the-art. Technical Report 49, 2002.

404

[298] John Muray Reuter. Inside Windows CE. Microsoft Press, 1998.

[299] Culbert C. Donell B. Ly B. Ortiz C. Giarrantano J. y López F. Riley G., Savely R. Clips:

A tool for building expert systems. Disponible en http://www.ghg.net/clips/CLIPS.html,

2005.

[300] Little R.J.A. and Rubin D.B. Statistical analysis with missing data. J. Wiley & Sons, New

York, 1987.

[301] D.B. Rubin. Multiple imputation for nonresponse in surveys. New York: John Wiley &

Sons, Inc., 1987.

[302] Koller D. y Kanazawa K. Russellm S., Binder J. Local learning in probabilistic networks

with hidden variables. In Proceedings of the Fourteenth International Joint Conference

on Arti�cial Intelligence, Montreal, QU, pages 1146-1152. Morgan Kaufmann, San Mateo,

CA, 1995.

[303] Gould S. The structure of evolutionary theory. Belknap Press, Primera edición, ISBN

0674006135, Marzo 2002.

[304] Kumar S. Classi�cation and detection of computer intrusions. Thesis submitted for the

degree of Doctor of Philosophy, Purdue University, USA, Agosto 1995.

[305] Scott S. A bayesian paradigm for designing intrusion detection systems. Computational

Statistics and Data Analysis, Elsevier Science, Vol. 45, Issue. 1, Pag. 69-83, Febrero 2004.

[306] Smaha S. Haystack: An intrusion detection system. Proceedings of the 4th Aerospace

Computer Security Applications Conference, Orlando, FL, Diciembre 1988.

[307] Smaha S. Y Snapp S. Method and system for detecting intrusion into and misuse of a data

processing system. US 555742, US Patent O�ce, Septiembre 1996.

[308] Stolcke A. Y Omohundro S. Inducing probabilistic grammars by bayesian model merging.

Proceedings of the 1994 International Conference on Grammatical Inference, Pag. 999,

1994.

[309] S. Forrest S. A. Hofmeyr and A. Somayaji. Intrusion detecction using sequences of system

calls. Journal of Computer Security, 6:151 to 180., 1998.

[310] L. Allen R. Cherukuri S. Forrest, A.S. Perelson. Self-nonself discrimination in a computer.

IEEE Symposium on Security and Privacy, 1994.

[311] S.W. Boyd S. Sidiroglou, M.E. Locasto and A.D. Keromytis. Building a reactive immune

system for software services. In Proceedings of USENIX Annual Technical Conference,

pages 149 - 161, April, 2005.

405

[312] G. Varghese S. Singh, C.Estan and S. Savage. Automated worm �ngerprinting. In Procee-

dings of the 6th ACM/USENIX Symposium on Operating System Design and Implementa-

tion (OSDI), December, 2004.

[313] Pablo Garaizar Sagarminaga. Linux 2.6 kernel hacking. hackAndalus, 2004.

[314] Barbery F. Salido M.A. Stochastic local search for distributed constraint satisfaction

problems. Universidad de Alicante, Universidad de Valencia, 2003.

[315] Querty Sandman. Pe infection under w32. 29a ezine, 1996.

[316] J.L. Schafer. Analysis of incomplete multivariate data. New York: Chapman and Hall,

1997.

[317] Hanna M. Y Whitehurst R. Sebring M., Shellhouse E. Expert systems in intrusion de-

tection, a case study. Proceedings of the 11th National Computer Security Conference,

Baltimore, USA, 1988.

[318] Abdallah Abbey Sebyala, Temitope Olukemi, and Dr. Lionel Sacks. Active platform se-

curity through intrusion detection using naïve bayesian network for anomaly detection.

Departament of Electronic and Electrical Engineering, University Colleage London, To-

rrington Place, England, UK., 2002.

[319] R. Sekar, M. Bendre, P. Bollineni, and D. Dhurjati. A fast automaton-based method for

detecting anomalous program behaviors. IEEE Symposium on Security and Privacy, pages

144 to 155., 2001.

[320] Pierce L. Y Matzner S. Sinclair C. An application of machine learning to network intrusion.

Proccedings of the 15th Annual Computer Security Applications Conference (ACSAC), Pag.

371, 1999.

[321] A. Smirnov and T. Chiueh. Dira: Automatic detection, identi�cation, and repair of control-

hijacking attacks. In Proceedings of The 12th Annual Network and Distributed System

Security Symposium (NDSS '05), February, 2005.

[322] Dias G. Goan T. Heberlein T. Ho C. Levitt K. Mukherjee B. Smaha S. Grance T. Teal D.

Y Mansur D. Snapp S., Brentano J. DIDS (distributed intrusion detection system) - mo-

tivation, architecture, and an early prototype. Proceedings of the 14th National Computer

Security Conference, Washington, DC, Octubre 1991.

[323] Snort. Snort: The facto standard for intrusion Detection/Prevention home page. Disponible

en http://www.snort.org/, 2006.

[324] Panda Software. Protection against viruses, spyware, hackers, spam and other internet

threats. Disponible en http://www.pandasoftware.com/, 2006.

406

[325] Hofmeyr S. Y Forrest S. Somayaji A. Principles of a computer immune system. Proceedings

of the 1997 Meeting on New Security Paradigms, Pag. 75-82, Langdale, UK, Septiembre

1997.

[326] Glymour C. Y Scheines R. Spirtes P. Causation, prediction and search. MIT Press,

Adaptative Computation and Machine Learning, Segunda Edición, ISBN 0262194406, 2000.

[327] SRI. Stanford research institute home page. Disponible en http://ww.sri.com/, 2006.

[328] A. Srivastava and A. Eustace. Atom - a system for building customized program analysis

tools. In Proceesings of the Symposium on Programming Language Design and Implemen-

tation, pages 196 to 205, Orlando, FL., 1994.

[329] R. Stallman. The free software foundation home page. Disponible en http://www.fsf.org/,

2006.

[330] Cheung R. Crawford R. Dilger M. Frank J. Hoagland J. Levitt K. Wee C. Yip R. Y Zerkle D.

Staniford-Chen S., Chen S. GrIDS - a graph-based intrusion detection system for large

networks. Proceedings of the 19th National Information Systems Security Conference, 1996.

[331] Hoagland J. Y Mc Alerney J. Staniford-Chen S. Practical automated detection of stealthy

portscans. Proceedings of the 7th ACM Conference on Computer and Communications

Security, Atenas, Grecia, 2000.

[332] Paxson V. Y Weaver N. Staniford-Chen S., Moore D. The top speed of �ash worms.

Proceedings of the ACM Workshop on Rapid Malcode (WORM), 2004.

[333] European Statistical Data Support. Internet usage by individuals and enterprises 2004.

Disponible en http://www.europa.eu.int/comm/eurostat/, 2005.

[334] Internet Security Systems. The evolution of intrusion detection technology. ISS Technical

White Paper, Agosto 2001.

[335] Internet Security Systems. Real secure server sensor home page. Disponible en

http://www.iss.net/, 2006.

[336] Goeldenitz T. Ids today and tomorrow. SANS Institute Information Security Reading

Room, Enero 2002.

[337] Holland T. Understanding ips and ids: Using ips and ids together for defense in depth.

SANS Institute Information Security Reading Room, Febrero 2004.

[338] Kohonen T. Self-organizing maps. Springer-Verlag, Berlin, 1997.

407

[339] Lane T. Machine learning techniques for the computer security domain of anomaly detec-

tion. Thesis submitted for the degree of Doctor of Philosophy, Purdue University, USA,

Agosto 2000.

[340] Toth T. Improving intrusion detection systems. Dissertation submitted for the degree of

Doctor of Philosophy, University of Vienna, Austria, 2003.

[341] Wickham T. Intrusion detection is dead. long live to intrusion prevention! SANS Institute

Information Security GIAC Certi�cation Practical, version GSEC 1.4b, Abril 2003.

[342] Wickman T. Intrusion detection is dead. long live to intrusion prevention! SANS Institute

Information Security GIAC Certi�cation Practical, 2003.

[343] C.E. Brodley T. Lane. Sequence matching and learning in anomaly detection for computer

security. AAAI Workshop: AI Approaches to Fraud Detection and Risk Management, pp.49-

49, 1997.

[344] C.E. Brodley T. Lane. Temporal sequence learning and data reduction for anomaly detec-

tion. ACM Trans. Information and System Security, vol. 2, no. 3, pp. 295-331, 1999.

[345] D. Lee A. Wolman W. Wong H. Levy T. Romer, G. Voelker and B. Bershad. Instrumen-

tation and optimization of win32/intel executables using etch. In USENIX Windows NT

Workshop, Seattle, WA., 1997.

[346] K. Tan and R. Maxion. Why 6?? de�ning the operational limits of stide, an anomaly

based intrusion detector. In Proceedings of the IEEE Symposium on Security and Privacy.

Oakland, CA. 188-202, 2002.

[347] K. Tan and R. Maxion. Determining the operational limits of an anomaly-based intrusion

detector. IEEE Journal on selected areas in communications, 21(1):96?110., Jan. 2003.

[348] K. Tan, J. Mchugh, and K. Killourhy. Hiding intrusions: From the abnormal to the normal

and beyond. In Proceedings of Information Hiding, pages 1�17, 2002.

[349] Steinbach M. Y Kumar V. Tan P. Introduction to data mining. Addison Wesley, Primera

Edición, ISBN 0321321367, Mayo 2005.

[350] M.A. Tanner and W.H. Wong. The calculation of posterior distributions by data augmen-

tation. Journal of the American Statistical Association, 82: 528-549, 1987.

[351] CERT/In Indian Computer Emergency Response Team. Ids - intrusion detection system.

CERT/In Security Guideline CISG-2003-06, 2003.

[352] Security Telecommunications and Information Systems Security Committee. National in-

formation systems security glossary. 2000.

408

[353] Chen K. Y Lu S. Teng H. Adaptative real-time anomaly detection using inductively genera-

ted sequential patterns. Proceedings of the 1990 IEEE Symposium on Research in Security

and Privacy, Oakland, USA, Mayo 1990.

[354] D. Thain and M. Livny. Multiple bypass: Interposition agents for distributed computing.

Journal of Cluster Computing, 4(1):39 to 47., March 2001.

[355] B Thiesson. Accelerated quanti�cation of bayesian networks with incomplete data. In

Proceedings of First International Conference on Knowledge Discovery and Data Mining,

Montreal, QU, pages 306-311. Morgan Kaufmann, 1995.

[356] T.Hurman. Exploring windows ce shellcode. Pentest, 2005.

[357] Open Source Tripwire. Open source tripwire home page. Disponible en

http://sourceforge.net/projects/tripwire/, 2006.

[358] Lindqvist U. On the fundamentals of analysis and detection of computer misuse. Thesis for

the degree of Doctor of Philosophy, Chalmers University of Technology. Göteborg, Suecia,

1999.

[359] International Telecommunication Union. Internet indicators: Hosts, users and number of

pcs. Disponible en http://www.itu.int/ITU-D/ict/statistics/, 2005.

[360] Stanford University. Stanford encyclopedia of philosophy. Consulta del término "Bayes'

Theorem". Disponible en http://plato.stanford.edu/entries/bayes-theorem/, 2006.

[361] Stanford University. Stanford encyclopedia of philosophy. Consulta del término "Boolean

Algebra". Disponible en http://plato.stanford.edu/entries/boolalg-math/, 2006.

[362] USAF. United states air force home page. Disponible en http://www.af.mil/, 2006.

[363] USSS. United states secret service home page. Disponible en http://www.secretservice.gov/,

2006.

[364] Mahoney M. V. and Chan P.K. Learning rules for anomaly detection of hostile network

tra�c. 2001.

[365] Vapnik V. The nature of statistical learning theory. Springer-Verlag, ISBN 0387945598,

1995.

[366] Amit Vasudevan and Ramesh Yerraballi. Spike: Engineering malware analysis tools using

unobtrusive binary-instrumentation. Department of Computer Science and Engineering.

University of Texas at Arlington, Box 19015, 416 Yates St., 300 Nedderman Hall, Arling-

ton, TX 76019-0015, USA. Box 19015, 416 Yates St., 300 Nedderman Hall, Arlington, TX

76019-0015, USA., January, 2006.

409

[367] Eckman S. Y Kemmerer R. Vigna G. The STAT tool suite. Proceedings of DISCEX 2000,

IEEE Press, Hilton Head, South Carolina, Enero 2000.

[368] Li W. Using genetic algorithm for network intrusion detection. Proceedings of the United

States Department of Energy Cyber Security Group 2004 Training Conference, Kansas

City, USA, Mayo 2004.

[369] K. Mok W. Lee, S.J. Stolfo. A data mining framework for building intrusion detection

models. IEEE Symposium on Security and Privacy, 1999.

[370] S. Stolfo W. Lee and K. Mok. Adaptive intrusion detection: A data mining approach.

Arti�cial Intelligence Review, December, 2000.

[371] D. Wagner and D. Dean. Intrusion detection via static analysis. In Proceedings of the

IEEE Symposium on Security and Privacy. IEEE Press, Oakland, CA., 2001.

[372] D. Wagner and P. Soto. Mimicry attacks on host-based intrusion detection systems. In

Proceedings of the 9th ACM Conference on Computer and Communications Security. Wa-

shington DC. 255-264, 2002.

[373] Wagner T. Y Wolstenholme P. Wagner F., Schmuki R. Modelling software with �nite state

machines: A practical approach. Auerbach Publications, ISBN 0849380863, Mayo 2006.

[374] Forrest S. Warrender, C. and B. Pearlmutter. Detecting intrusions using system calls:

Alternative data models. In Proceedings of the IEEE Symposium on Security and Privacy.,

1999.

[375] Stephanie Forrest Warrender, Christina and Barak Pearlmutter. Detecting intrusions using

system calls: Alternative data models. IEEE Synposium on security and privacy, 1999.

[376] Mahoney M. y Chan P. Phad: Packet header anomaly detection for identifying hostile

network tra�c. Florida Tech. Techical Report, Abril 2001.

[377] Gómez J. y Dasgupta D. Evolving fuzzy classi�ers for intrusion detection. Proceedings

of the 2002 IEEE Workshop on Information Assurance, United States Military Academy,

West Point, Ney York, USA, Junio 2001.

[378] Hou H. y Dozier G. Immunity-based intrusion detection system design, vulnerability analy-

sis, and genertia's genetic arms race. Proceedings of the 2005 ACM Symposium on Applied

Computing, Pag. 952-956, Santa Fe, New Mexico, USA, 2005.

[379] Lundin E. y Jonsson E. Setting the scene for intrusion detection. Technical Report 04-

05. Department of Computer Engineering, Chalmers University of Technology. Göteborg,

Suecia, Agosto 2004.

410

[380] Kantzavelou I. y Katsikas S. An attack detection system for secure computer systems -

outline of the solution. Proceedings of the IFIP TC11 13th International Conference on

Information Security, Copenhagen, Dinamarca, Mayo 1997.

[381] Porras P. y Kemmerer R. Penetration state transition analysis - a rule-based intrusion

detection approach. Eighth Annual Computer Security Applications Conference, Pag. 220-

229, IEEE Computer Society Press, Diciembre 1992.

[382] Ryan J. y Lin M. Intrusion detection with neural networks. Advances in Neural Information

Processing Systems, No. 10, MIT Press, Cambridge, Massachusetts, USA, 1998.

[383] Garvey T. y Lunt T. Model based intrusion detection. Proceedings of the 14th National

Computer Security Conference, Pag. 372-385, Octubre 1991.

[384] Porras P. y Neumann P. Emerald: Event monitoring enabling responses to anomalous live

disturbances. Proceddings of the 20th NIST-NCSC National Information Systems Security

Conference, Pag. 353-365, 1997.

[385] Ptacek T. y Newsham T. Insertion, evasion and denial of service: Eluding intrusion detec-

tion. Technical Report, Secure Networks Incorporated, Enero 1998.

[386] Russell S. y Norvig P. Arti�cial intelligence: A modern approach. Second Edition, Prentice

Hall, ISBN 0137903952, Diciembre 2002.

[387] Giarratano J. y Riley G. Expert systems: Principles and programming. Course Technology,

Cuarta Edicion, ISBN 0534384471, Octubre 2005.

[388] Jones A. y Sielken R. Computer system intrusion detection: A survey. Technical Report,

Computer Science Department, University of Virginia, 2000.

[389] Kim G. y Spa�ord E. The design and implementation of tripwire: A �le system integrity

checker. ACM Conference on Computer and Communications Security, Pag. 18-29, 1994.

[390] Kumar S. y Spa�ord E. An application of pattern matching in intrusion detection. Technical

Report 94-013, Department of Computer Science, Purdue University, Marzo 1994.

[391] Kumar S. y Spa�ord E. A pattern matching model for misuse intrusion detection. Procee-

dings of the 7th National Computer Security Conference, Baltimore, USA, Octubre 1994.

[392] Lauritzen S. y Spiegelhalter D. Local computations with probabilities on graphical structu-

res and their application to expert systems. Journal of the Royal Statistical Society, Series

B (Methodological), No. 50, Vol. 2, Pag. 157-224, 1988.

[393] Lee W. y Stolfo S. Data mining approaches for intrusion detection. Proceedings of the 7th

USENIX security symposium, Pag. 79-93, San Antonio, USA, Enero 1998.

411

[394] Mukkamala S. y Sung A. A comparative study of techniques for intrusion detection.

Proceedings of the 15th IEEE International Conference on Tools with Arti�cial Intelligence

(ICTAI), Pag. 570, 2003.

[395] Liepins G. y Vaccaro H. Intrusion detection: Its role and validation. Computers and

Security, Vol. 11, Pag. 347-355, Elsevier Science Publishers Limited, Oxford, UK, 1992.

[396] Javitz H. y Valdés A. The sri ides statistical anomaly detector. Proceedings of the 1991

IEEE Symposium on Research in Security and Privacy, Mayo 1991.

[397] Pearl J. y Verma T. A statistical semantics for causation. Statistics and Computing, Vol.

2, Pag. 91-95, 1992.

[398] Kemmerer R. y Vigna G. Intrusion detection: A brief history and overview. Reliable

Software Group, Computer Science Department, University of California Santa Barbara,

2002.

[399] Meyer T. y Whateley B. Spambayes: E�ective open-source, bayesian based, email clas-

si�cation system. Proceedings of the 2004 Conference on Email and Anti-Spam (CEAS),

Mountain View, California, USA, Julio 2004.

[400] Yang C. Yuan. Multiple imputation for missing data: Concepts and new development. SAS

Institute Inc., Rockville, MD, 1997.

[401] Jingyu Zhou and Giovanni Vigna. Detecting attacks that exploit application-logic errors

through application-level auditing. University of California Santa Barbara, USA, 2004.

[402] Amitabha Das Zhuowei Li. Visualizing and identifying intrusion context from system

calls trace. Proceedings of the 20th Annual Computer Security Applications Conference

(ACSAC'04), IEEE Computer Society, December 2004.

412

· resumen ante la creciente magnitud del problema del aseguramiento de la seguridad de la...

Documents