CONTRIBUCIÓN A LA AUTOMATIZACIÓN DE …oa.upm.es/21885/1/VERONICA_MATEOS_LANCHAS.pdf · momentos...

UNIVERSIDAD POLITÉCNICA DE MADRID

ESCUELA TÉCNICA SUPERIOR DE INGENIEROS DE TELECOMUNICACIÓN

TESIS DOCTORAL

CONTRIBUCIÓN A LA AUTOMATIZACIÓN DE

SISTEMAS DE RESPUESTA FRENTE A

INTRUSIONES MEDIANTE ONTOLOGÍAS

VERÓNICA MATEOS LANCHAS

INGENIERO DE TELECOMUNICACIÓN

2013

Departamento de Ingeniería de Sistemas Telemáticos

ESCUELA TÉCNICA SUPERIOR DE INGENIEROS DE TELECOMUNICACIÓN

UNIVERSIDAD POLITÉCNICA DE MADRID

TESIS DOCTORAL

CONTRIBUCIÓN A LA AUTOMATIZACIÓN DE

SISTEMAS DE RESPUESTA FRENTE A

INTRUSIONES MEDIANTE ONTOLOGÍAS

Autor

Verónica Mateos Lanchas

Ingeniero de Telecomunicación

Director

Víctor A. Villagrá González

Doctor Ingeniero de Telecomunicación

Madrid, Noviembre 2013

Título: Contribución a la Automatización de Sistemas de Respuesta frente a

Intrusiones mediante Ontologías

Departamento: Departamento de Ingeniería de Sistemas Telemáticos.

Autor: Veronica Mateos Lanchas

Director: Víctor A. Villagrá González

TRIBUNAL CALIFICADOR

Presidente: D. Julio Berrocal Colmenarejo Doctor Ingeniero de Telecomunicación

Catedrático de Universidad

Universidad Politécnica de Madrid

Vocales: D. Gregorio Martínez Pérez Doctor en Informática

Profesor Titular de Universidad

Universidad de Murcia

D. Jorge E. López de Vergara Méndez Doctor Ingeniero de Telecomunicación


Universidad Autónoma de Madrid

D. Francisco Jordán Fernández Doctor Ingeniero de Telecomunicación


Universidad Politécnica de Cataluña

Secretario: Dña. Carmen Sánchez Ávila Doctor en Ciencias Matemáticas

Catedrática de Universidad

Universidad Politécnica de Madrid

Suplentes: D. Jose Ignacio Moreno Novella Doctor Ingeniero de Telecomunicación


Universidad Carlos III de Madrid

D. Jaime M. Delgado Mercé Doctor Ingeniero de Telecomunicación

Catedrático de Universidad

Universidad Politécnica de Cataluña

Realizado el acto de defensa y lectura de la Tesis Doctoral en Madrid, el día 13 de

Noviembre de 2013.

AGRADECIMIENTOS

Son muchas las personas que han estado a mi lado a lo largo de estos años, y que han hecho posible

que pueda estar escribiendo estas líneas en este momento. Entre todos vosotros habéis conseguido

que llegue al final del camino. Gracias!!

En primer lugar debo dar las gracias muy especialmente a mi director de Tesis, Víctor Villagrá. Su

trabajo, apoyo y valiosa orientación han hecho posible la finalización de este trabajo.

También quisiera expresar mi gratitud a Julio Berrocal por la confianza y el apoyo demostrados, así

como al resto de personal del Departamento de Ingeniería de Sistemas Telemáticos, por su cercanía

y apoyo durante mis estudios de doctorado. Gracias a David, Luis, Paco, Carlos, Pilar, Mario,

Joaquín, Pedro, Alberto, Vicente y todos los compañeros con los que he compartido todos estos años

en el B-203.

Gracias también a Chema y Ruth, por esas comidas, charlas y sobremesas, que han hecho que los

momentos duros no lo parecieran tanto.

Quisiera dar las gracias a mis padres y hermano, por su apoyo incondicional a lo largo de toda mi

vida. Sé que a veces ha sido difícil y que en muchos momentos ni yo misma me hubiera aguantado,

pero vosotros siempre habéis estado ahí, haciendo que todo pareciera mucho más fácil. Gracias por

vuestra paciencia y comprensión y por sacarme una sonrisa en todo momento.

Gracias Abraham por el apoyo, la comprensión y el cariño que me has demostrado durante el

prolongado y en ocasiones difícil periodo de tiempo que he estado dedicada a la realización de esta

Tesis, en especial en estos últimos meses. Gracias por ser esa persona que me aporta ese punto de

alegría, optimismo y tranquilidad que a veces me falta, y por hacer que aprenda a ver la vida de otra

forma.

Y por último, quisiera agradecer de todo corazón, a mi amiga Marta… siempre!!!! He tenido la gran

suerte de recorrer este camino contigo desde el principio, y si he llegado al final ha sido

especialmente gracias a ti. Gracias por aportar calma en momentos tremendistas, optimismo en

momentos de tristeza y negatividad, y realismo en momentos en los que era necesario. GRACIAS por

hacer que esto, hoy, sea posible. Y como dicen en una de mis películas favoritas… “Nunca dejes que

nadie te diga que no puedes hacer algo. Si tienes un sueño, tienes que protegerlo… Las personas

que no son capaces de hacer algo te dirán que tú tampoco puedes…Si quieres algo, ve por ello y

punto” [En busca de la felicidad]

Resumen

La seguridad en redes informáticas es un área que ha sido ampliamente estudiada y objeto de una

extensa investigación en los últimos años. Debido al continuo incremento en la complejidad y

sofisticación de los ataques informáticos, el aumento de su velocidad de difusión, y la lentitud de

reacción frente a las intrusiones existente en la actualidad, se hace patente la necesidad de

mecanismos de detección y respuesta a intrusiones, que detecten y además sean capaces de

bloquear el ataque, y mitiguen su impacto en la medida de lo posible.

Los Sistemas de Detección de Intrusiones o IDSs son tecnologías bastante maduras cuyo objetivo es

detectar cualquier comportamiento malicioso que ocurra en las redes. Estos sistemas han

evolucionado rápidamente en los últimos años convirtiéndose en herramientas muy maduras basadas

en diferentes paradigmas, que mejoran su capacidad de detección y le otorgan un alto nivel de

fiabilidad.

Por otra parte, un Sistema de Respuesta a Intrusiones (IRS) es un componente de seguridad que

puede estar presente en la arquitectura de una red informática, capaz de reaccionar frente a los

incidentes detectados por un Sistema de Detección de Intrusiones (IDS). Por desgracia, esta

tecnología no ha evolucionado al mismo ritmo que los IDSs, y la reacción contra los ataques

detectados es lenta y básica, y los sistemas presentan problemas para ejecutar respuestas de forma

automática.

Esta tesis doctoral trata de hacer frente al problema existente en la reacción automática frente a

intrusiones, mediante el uso de ontologías, lenguajes formales de especificación de comportamiento y

razonadores semánticos como base de la arquitectura del sistema de un sistema de respuesta

automática frente a intrusiones o AIRS.

El objetivo de la aproximación es aprovechar las ventajas de las ontologías en entornos

heterogéneos, además de su capacidad para especificar comportamiento sobre los objetos que

representan los elementos del dominio modelado. Esta capacidad para especificar comportamiento

será de gran utilidad para que el AIRS infiera la respuesta óptima frente a una intrusión en el menor

tiempo posible.

Palabras clave: Ontología, Sistema de Respuesta Automática frente a Intrusiones (AIRS),

Métricas de Respuesta a Intrusiones, Reglas de Comportamiento

Abstract

Security in networks is an area that has been widely studied and has been the focus of extensive

research over the past few years. The number of security events is increasing, and they are each time

more sophisticated, and quickly spread, and slow reaction against intrusions, there is a need for

intrusion detection and response systems to dynamically adapt so as to better detect and respond to

attacks in order to mitigate them or reduce their impact.

Intrusion Detection Systems (IDSs) are mature technologies whose aim is detecting malicious

behavior in the networks. These systems have quickly evolved and there are now very mature tools

based on different paradigms (statistic anomaly-based, signature-based and hybrids) with a high level

of reliability.

On the other hand, Intrusion Response System (IRS) is a security technology able to react against the

intrusions detected by IDS. Unfortunately, the state of the art in IRSs is not as mature as with IDSs.

The reaction against intrusions is slow and simple, and these systems have difficulty detecting

intrusions in real time and triggering automated responses.

This dissertation is to address the existing problem in automated reactions against intrusions using

ontologies, formal behaviour languages and semantic reasoners as the basis of the architecture of an

automated intrusion response systems or AIRS.

The aim is to take advantage of ontologies in heterogeneous environments, in addition to its ability to

specify behavior of objects representing the elements of the modeling domain. This ability to specify

behavior will be useful for the AIRS in the inference process of the optimum response against an

intrusion, as quickly as possible.

Keywords: Ontology, Automated Intrusion Response System (AIRS), Intrusion Response

Metrics, Behaviour rules

Esta parte de mi vida, esta pequeña parte,

se llama FELICIDAD

I

ÍNDICE

INTRODUCCIÓN ....................................................................................... 1 CAPÍTULO 1

1.1 INTRODUCCIÓN Y MOTIVACIÓN ................................................................................................ 1

1.2 OBJETIVOS DE LA TESIS DOCTORAL ......................................................................................... 3

1.3 ESTRUCTURA DE LA MEMORIA .................................................................................................. 4

SEGURIDAD EN REDES DE TELECOMUNICACIÓN: SISTEMAS CAPÍTULO 2

DE RESPUESTA AUTOMÁTICA FRENTE A INTRUSIONES (AIRS)7

2.1 INTRODUCCIÓN ............................................................................................................................... 7

2.2 MARCO: SEGURIDAD EN REDES DE TELECOMUNICACIÓN ................................................. 7

2.2.1 Cortafuegos .................................................................................................................................... 10 2.2.2 Sistemas de Detección de Intrusiones: IDS ................................................................................... 11

2.2.3 Sistemas de Prevención de Intrusiones: IPS .................................................................................. 12 2.2.4 Sistemas de Respuesta a Intrusiones: IRS ...................................................................................... 13

2.3 SISTEMAS DE RESPUESTA FRENTE A INTRUSIONES PROPUESTOS ................................. 14

2.3.1 CSM ............................................................................................................................................. 17

2.3.2 EMERALD ..................................................................................................................................... 20 2.3.3 AAIRS ............................................................................................................................................. 21 2.3.4 SARA ............................................................................................................................................. 24

2.3.5 ADEPTS ......................................................................................................................................... 27

2.3.6 MAIRF ........................................................................................................................................... 33 2.3.7 FAIR ............................................................................................................................................. 35 2.3.8 IDAM & IRS .................................................................................................................................. 38

2.3.9 Otras aproximaciones propuestas ................................................................................................. 40

2.3.10 Análisis general de las soluciones ................................................................................................. 42

2.4 MÉTRICAS DE RESPUESTA A INTRUSIONES .......................................................................... 42

2.4.1 Parámetros que influyen en el proceso de inferencia de la respuesta óptima ............................... 43 2.4.2 Métricas utilizadas en los AIRSs .................................................................................................... 45 2.4.3 Otras métricas propuestas ............................................................................................................. 61

2.4.4 Análisis general de las soluciones ................................................................................................. 67

2.5 MECANISMOS DE EVALUACIÓN DE LA RESPUESTA ........................................................... 69

2.5.1 Mecanismos de evaluación utilizados en los AIRSs ....................................................................... 69 2.5.2 Otros mecanismos propuestos ....................................................................................................... 71 2.5.3 Análisis general de las soluciones ................................................................................................. 72

2.6 CONCLUSIONES ............................................................................................................................. 73

LAS ONTOLOGÍAS COMO TÉCNICAS DE REPRESENTACIÓN CAPÍTULO 3

DEL CONOCIMIENTO ........................................................................... 75

3.1 INTRODUCCIÓN ............................................................................................................................. 75

3.2 LENGUAJES DE DEFINICIÓN DE ONTOLOGÍAS...................................................................... 76

Contribución a la Automatización de Sistemas de Respuesta frente a Intrusiones mediante Ontologías

II

3.2.1 SHOE ............................................................................................................................................. 78

3.2.2 RDF y RDF-Schema ...................................................................................................................... 78 3.2.3 OIL y DAML+OIL ......................................................................................................................... 79 3.2.4 OWL ............................................................................................................................................. 80 3.2.5 OWL2 ............................................................................................................................................. 82

3.2.6 Resumen comparativo y conclusiones ............................................................................................ 84

3.3 LENGUAJES DE ESPECIFICACIÓN DEL COMPORTAMIENTO .............................................. 85

3.3.1 RuleML .......................................................................................................................................... 86 3.3.2 SWRL ............................................................................................................................................. 87 3.3.3 OWL-Services ................................................................................................................................ 91

3.3.4 KAoS ............................................................................................................................................. 92 3.3.5 REI ............................................................................................................................................. 95 3.3.6 Otros lenguajes de especificación del comportamiento ................................................................. 96

3.3.7 Resumen comparativo y conclusiones ............................................................................................ 98

3.4 RAZONADORES SEMÁNTICOS ................................................................................................. 100

3.4.1 Bossam ......................................................................................................................................... 103 3.4.2 PELLET ....................................................................................................................................... 104

3.4.3 KAON2 ......................................................................................................................................... 108 3.4.4 RACER Pro .................................................................................................................................. 109

3.4.5 Otros razonadores semánticos ..................................................................................................... 112 3.4.6 Análisis y validación de razonadores semánticos con soporte de SWRL .................................... 113

3.4.7 Resumen comparativo y conclusiones .......................................................................................... 116

3.5 CONCLUSIONES ........................................................................................................................... 118

PROPUESTA DE ARQUITECTURA DE UN SISTEMA DE CAPÍTULO 4

RESPUESTA A INTRUSIONES BASADO EN ONTOLOGÍAS ....... 121

4.1 INTRODUCCIÓN ........................................................................................................................... 121

4.1.1 Antecedentes y motivación ........................................................................................................... 121

4.2 METODOLOGÍA ........................................................................................................................... 122

4.3 EVALUACIÓN DE ALTERNATIVAS ......................................................................................... 123

4.4 PROPUESTA DE ARQUITECTURA DE UN AIRS BASADO EN ONTOLOGÍAS ................... 125

4.4.1 Definición de la arquitectura de AIRS basado en ontologías ...................................................... 125 4.4.2 Módulo de contexto ...................................................................................................................... 134

4.4.3 “Policies”: Especificación del comportamiento mediante ontologías y lenguajes de reglas ...... 143 4.4.4 Response Toolkit o Catálogo de Acciones de respuesta .............................................................. 145 4.4.5 Módulo de ejecución de acciones de respuesta ........................................................................... 151 4.4.6 Análisis de la propuesta ............................................................................................................... 158

4.5 CONCLUSIONES ........................................................................................................................... 159

PROPUESTA DE ONTOLOGÍA DE RESPUESTA A INTRUSIONES161 CAPÍTULO 5

5.1 INTRODUCCIÓN ........................................................................................................................... 161

5.2 METODOLOGÍA ........................................................................................................................... 162

5.3 LAS ONTOLOGÍAS Y SU APLICACIÓN EN LA SEGURIDAD DE REDES DE

TELECOMUNICACIÓN ................................................................................................................ 162

III

5.4 ONTOLOGÍA DE RESPUESTA A INTRUSIONES ..................................................................... 166

5.4.1 Metodología usada para la especificación de la ontología de respuesta a intrusiones ............... 166 5.4.2 Herramientas utilizadas en la definición de la ontología de respuesta a intrusiones ................. 169 5.4.3 Especificación de la ontología de respuesta a intrusiones .......................................................... 171

5.5 CONCLUSIONES ........................................................................................................................... 192

PROPUESTA DE MÉTRICAS DE SEGURIDAD Y SU CAPÍTULO 6

ESPECIFICACIÓN MEDIANTE SWRL ............................................. 195

6.1 INTRODUCCIÓN ........................................................................................................................... 195

6.2 METODOLOGÍA ........................................................................................................................... 196

6.3 EVALUACIÓN DE ALTERNATIVAS ......................................................................................... 197

6.3.1 Especificación de métricas de seguridad mediante lenguajes de políticas y reglas .................... 198

6.4 PROPUESTA DE MÉTRICAS DE SEGURIDAD EN UN AIRS Y SU ESPECIFICACIÓN

MEDIANTE SWRL ........................................................................................................................ 199

6.4.1 Definición de métricas de seguridad para su uso en el AIRS basado en ontologías ................... 200

6.4.2 Definición de métricas de inferencia de la respuesta óptima ...................................................... 208

6.4.3 Especificación de métricas de seguridad mediante reglas SWRL ............................................... 211 6.4.4 Análisis de la propuesta ............................................................................................................... 214

6.5 CONCLUSIONES ........................................................................................................................... 216

PROPUESTA DE UNA METODOLOGÍA PARA LA EVALUACIÓN CAPÍTULO 7

DEL ÉXITO DE UNA ACCIÓN DE RESPUESTA ............................. 217

7.1 INTRODUCCIÓN ........................................................................................................................... 217

7.2 METODOLOGÍA ........................................................................................................................... 218

7.3 ANÁLISIS Y EVALUACIÓN DE ALTERNATIVAS .................................................................. 218

7.4 PROPUESTA DE METODOLOGÍA DE EVALUACIÓN DE LA EFICACIA DE UNA ACCIÓN

DE RESPUESTA FRENTE A INTRUSIONES MEDIANTE ENTROPÍA Y VARIACIÓN DEL

CONTEXTO ................................................................................................................................... 222

7.4.1 Definición de la metodología propuesta ...................................................................................... 222

7.4.2 Diseño e implementación de un sistema que desarrolla la metodología propuesta .................... 230 7.4.3 Análisis de la propuesta ............................................................................................................... 241

7.5 CONCLUSIONES ........................................................................................................................... 241

VALIDACIÓN DE LAS PROPUESTAS .............................................. 243 CAPÍTULO 8

8.1 INTRODUCCIÓN ........................................................................................................................... 243

8.2 PROYECTOS SEGUR@ Y RECLAMO ........................................................................................ 243

8.3 IMPLEMENTACIÓN DEL PROTOTIPO DE AIRS BASADO EN ONTOLOGÍAS ................... 244

8.1.1 IDSs ........................................................................................................................................... 245 8.1.2 Receptor de Alertas ...................................................................................................................... 246

8.1.3 Contexto de Sistemas, Contexto de Red y Receptor de Contexto ................................................. 247 8.1.4 Ontología de respuesta a intrusiones ........................................................................................... 256 8.1.5 Políticas ....................................................................................................................................... 257

8.1.6 Razonador .................................................................................................................................... 257


IV

8.1.7 Catálogo de acciones de respuesta .............................................................................................. 258

8.1.8 Ejecutor de acciones de respuesta ............................................................................................... 260 8.1.9 Sistema de evaluación del éxito de la respuesta .......................................................................... 263

8.4 VALIDACIÓN DEL AIRS BASADO EN ONTOLOGÍAS EN UNA ARQUITECTURA DE RED

......................................................................................................................................................... 265

8.4.1 Escenario de Validación .............................................................................................................. 265 8.4.2 Herramientas Utilizadas .............................................................................................................. 268 8.4.3 Validación del AIRS basado en ontologías ante un escaneo de puertos contra un servidor de la

DMZ ........................................................................................................................................... 271 8.4.4 Rendimiento del AIRS basado en ontologías ............................................................................... 276

8.4.5 Tasa de éxito del AIRS basado en ontologías .............................................................................. 279

8.5 ANÁLISIS DE RESULTADOS ...................................................................................................... 280

CONCLUSIONES Y TRABAJOS FUTUROS ..................................... 281 CAPÍTULO 9

9.1 ANÁLISIS DE LOS OBJETIVOS .................................................................................................. 281

9.2 DIFUSIÓN DE RESULTADOS ..................................................................................................... 283

9.3 LÍNEAS FUTURAS DE INVESTIGACIÓN ................................................................................. 284

INTERFAZ DE ADMINISTRACIÓN DEL AIRS BASADO EN APÉNDICE I

ONTOLOGÍAS ........................................................................................ 287

DEFINICIÓN DE REGLAS SWRL ESPECIFICADAS EN EL AIRS APÉNDICE II

BASADO EN ONTOLOGÍAS ................................................................ 293

TIPOS DE ATAQUES INFORMÁTICOS Y ACCIONES DE APÉNDICE III

RESPUESTA ASOCIADAS ................................................................... 301

REFERENCIAS ................................................................................................................... 321

ABREVIATURAS Y ACRÓNIMOS .................................................................................. 331

V

Índice de figuras

FIGURA 2.1 CICLO DE SEGURIDAD DEL PROCESO DE PLANIFICACIÓN DE SEGURIDAD. ................................................................... 9 FIGURA 2.2 SEGURIDAD EN REDES DE TELECOMUNICACIÓN. ............................................................................................... 10 FIGURA 2.3 RELACIÓN ENTRE RESPUESTAS PROACTIVAS Y REACTIVAS SOBRE EL MARCO TEMPORAL DE UN ATAQUE [ANUAR10]. ...... 15 FIGURA 2.4 TAXONOMÍA DE SISTEMAS DE RESPUESTA A INTRUSIONES. ................................................................................ 17 FIGURA 2.5 ARQUITECTURA DE CSM............................................................................................................................. 18 FIGURA 2.6 ARQUITECTURA DE EMERALD. ................................................................................................................... 20 FIGURA 2.7 ARQUITECTURA DE AAIRS. ......................................................................................................................... 22 FIGURA 2.8 ARQUITECTURA DE SARA. .......................................................................................................................... 25 FIGURA 2.9 ARQUITECTURA DE ADEPTS. ...................................................................................................................... 28 FIGURA 2.10 EJEMPLO DE ESTRUCTURA I-GRAPH USADA EN UN SISTEMA E-COMMERCE DISTRIBUIDO [FOO05]. ......................... 29 FIGURA 2.11 ARQUITECTURA DE MAIRF [WANG06]. ...................................................................................................... 33 FIGURA 2.12 ARQUITECTURA DE FAIR. .......................................................................................................................... 36 FIGURA 2.13 ARQUITECTURA DE IDAM&IRS [MU10A]. .................................................................................................. 39 FIGURA 3.1 EVOLUCIÓN DE LENGUAJES DE ONTOLOGÍAS DE LA WEB SEMÁNTICA. ................................................................... 78 FIGURA 3.2 TRIPLETE REPRESENTADO EN FORMATO ESTÁNDAR RDF/XML ........................................................................... 79 FIGURA 3.3 JERARQUÍA DE CAPAS DEL LENGUAJE DE ONTOLOGÍAS OIL [FENSEL01]................................................................. 80 FIGURA 3.4 ESTRUCTURA DE OWL2 [OWL2W3C12] ..................................................................................................... 82 FIGURA 3.5 REGLA SWRL EXPRESADA EN SINTAXIS XML CONCRETE SYNTAX. ....................................................................... 88 FIGURA 3.6 ARQUITECTURA DEL ENTORNO KAOS [GUERRERO07] ...................................................................................... 94 FIGURA 4.1 ARQUITECTURA DEL AIRS BASADO EN ONTOLOGÍAS [MATEOS10] .................................................................... 128 FIGURA 4.2 CONTEXTO DE SISTEMAS. DIAGRAMA FUNCIONAL. ......................................................................................... 137 FIGURA 4.3 ARQUITECTURA DEL MÓDULO DE CONTEXTO DE SISTEMAS. .............................................................................. 138 FIGURA 4.4 CONTEXTO DE RED. DIAGRAMA FUNCIONAL ................................................................................................. 141 FIGURA 4.5 ARQUITECTURA DEL MÓDULO DE CONTEXTO DE RED. ...................................................................................... 142 FIGURA 4.6 DIAGRAMA DE PROCESO DE LA INFERENCIA DE LA RESPUESTA ÓPTIMA DEL AIRS BASADO EN ONTOLOGÍAS. [MATEOS12]

................................................................................................................................................................... 144 FIGURA 4.7 ARQUITECTURA DEL MÓDULO DE EJECUCIÓN DE ACCIONES DE RESPUESTA. [GUAMAN13] ...................................... 154 FIGURA 4.8 INTERFACES DEL GESTOR DE PLUGINS DEL MÓDULO DE EJECUCIÓN DE ACCIONES DE RESPUESTA [GUAMAN13] ........... 157 FIGURA 5.1 METHONTOLOGY. .............................................................................................................................. 168 FIGURA 5.2 CLASE NETWORK DE LA ONTOLOGÍA DE RESPUESTA A INTRUSIONES. .................................................................. 174 FIGURA 5.3 ONTOLOGÍA DE RESPUESTA A INTRUSIONES [MATEOS13]. .............................................................................. 175 FIGURA 5.4 CLASE CONTEXT DE LA ONTOLOGÍA DE RESPUESTA A INTRUSIONES. .................................................................... 176 FIGURA 5.5 CLASE ASSET DE LA ONTOLOGÍA DE RESPUESTA A INTRUSIONES. ........................................................................ 178 FIGURA 5.6 CLASE ADDRESS DE LA ONTOLOGÍA DE RESPUESTA A INTRUSIONES. .................................................................... 179 FIGURA 5.7 CLASE VULNERABILITY DE LA ONTOLOGÍA DE RESPUESTA A INTRUSIONES. ............................................................ 180 FIGURA 5.8 CLASE INTRUSIONDETECTIONSYSTEM DE LA ONTOLOGÍA DE RESPUESTA A INTRUSIONES. ........................................ 181 FIGURA 5.9 CLASE AUTOMATEDINTRUSIONRESPONSESYSTEM DE LA ONTOLOGÍA DE RESPUESTA A INTRUSIONES. ........................ 182 FIGURA 5.10 CLASE FORMATTEDINTRUSION DE LA ONTOLOGÍA DE RESPUESTA A INTRUSIONES. ............................................... 183 FIGURA 5.11 ONTOLOGÍA DE RESPUESTA A INTRUSIONES. RELACIONES DE CLASE FORMATTEDINTRUSION. ................................ 185 FIGURA 5.12 PROPIEDADES DE LA CLASE THREAT. .......................................................................................................... 185 FIGURA 5.13 CLASE THREAT DE LA ONTOLOGÍA DE RESPUESTA A INTRUSIONES. .................................................................... 186 FIGURA 5.14 CLASE SECURITYGOAL DE LA ONTOLOGÍA DE RESPUESTA A INTRUSIONES. .......................................................... 186 FIGURA 5.15 CLASE RESPONSE DE LA ONTOLOGÍA DE RESPUESTA A INTRUSIONES. ................................................................ 187 FIGURA 5.16 ONTOLOGÍA DE RESPUESTA A INTRUSIONES. RELACIONES DE CLASE RESPONSE. ................................................. 189 FIGURA 5.17 CLASE RESPONSESYSTEMCOMPONENTS DE LA ONTOLOGÍA DE RESPUESTA A INTRUSIONES. ................................... 189 FIGURA 7.1 FASES DE LA METODOLOGÍA DE EVALUACIÓN DEL ÉXITO DE LA RESPUESTA PROPUESTA. .......................................... 223 FIGURA 7.2 DIAGRAMA DE CASOS DE USO DEL MÓDULO DE EVALUACIÓN DEL ÉXITO DE UNA ACCIÓN DE RESPUESTA FUNCIONANDO EN

MODO EJECUCIÓN. .......................................................................................................................................... 231 FIGURA 7.3 DIAGRAMA DE CASOS DE USO DEL MÓDULO DE EVALUACIÓN DEL ÉXITO DE UNA ACCIÓN DE RESPUESTA FUNCIONANDO EN

MODO ENTRENAMIENTO. ................................................................................................................................. 232 FIGURA 7.4 ARQUITECTURA DEL SISTEMA DE EVALUACIÓN DEL ÉXITO DE UNA RESPUESTA. ...................................................... 235


VI

FIGURA 7.5 SISTEMA DE EVALUACIÓN DEL ÉXITO DE UNA ACCIÓN DE RESPUESTA: DIAGRAMA DE ACTIVIDAD. ............................. 237 FIGURA 8.1 USO DE DAEMONLOGGER COMO TÉCNICA DE PORT MIRRORING DESDE LA INTERFAZ NETATT HACIA IDSNET1. .......... 246 FIGURA 8.2 ESQUEMA DE FUNCIONAMIENTO DEL CONTEXTO DE SISTEMAS. ......................................................................... 248 FIGURA 8.3 MÓDULO DE CONTEXTO DE SISTEMAS: SYSTEMCONTEXTDB. ........................................................................... 251 FIGURA 8.4 MÓDULO DE CONTEXTO DE SISTEMAS: NETCONTEXTDB. ................................................................................ 255 FIGURA 8.5 CATÁLOGO DE ACCIONES DE RESPUESTA IMPLEMENTADAS COMO PLUGINS PARA LA VALIDACIÓN DEL AIRS [GUAMAN13]

................................................................................................................................................................... 259 FIGURA 8.6 FORMATO DE PAQUETE DE SOLICITUD DEL MÓDULO DE EJECUCIÓN DE RESPUESTAS. [GUAMÁN13] .......................... 261 FIGURA 8.7 ESCENARIO DE RED DE VALIDACIÓN DEL AIRS BASADO EN ONTOLOGÍAS. ............................................................. 267 FIGURA 8.8 SALIDA DEL SISTEMA DE EVALUACIÓN DEL ÉXITO DE RESPUESTAS EN EL ESCENARIO DE VALIDACIÓN 1. ...................... 276 FIGURA 8.9 RENDIMIENTO DEL AIRS. TIEMPO DE DESPLIEGUE DE UNA ACCIÓN DE RESPUESTA EN FUNCIÓN DEL NÚMERO DE ALERTAS

CONCURRENTES. NÚMERO DE HEBRAS DEL RAZONADOR =1. ................................................................................... 277 FIGURA 8.10 RENDIMIENTO DEL AIRS. TIEMPO DE DESPLIEGUE DE UNA ACCIÓN DE RESPUESTA EN FUNCIÓN DEL NÚMERO DE ALERTAS

CONCURRENTES. NÚMERO DE HEBRAS DEL RAZONADOR =4. ................................................................................... 278 FIGURA 8.11 TASA DE ÉXITO DEL AIRS BASADO EN ONTOLOGÍAS EN FUNCIÓN DEL TIPO DE INTRUSIÓN Y DE LA IMPORTANCIA DEL

ACTIVO COMPROMETIDO. ................................................................................................................................. 279 FIGURA 8.12 TASA DE ÉXITO DEL AIRS BASADO EN ONTOLOGÍAS EN FUNCIÓN DEL NÚMERO DE EJECUCIONES DEL PROCESO DE

INFERENCIA. .................................................................................................................................................. 280 FIGURA 9.1 INTERFAZ DE ADMINISTRACIÓN DEL AIRS BASADO EN ONTOLOGÍAS ................................................................... 288 FIGURA 9.2 INTERFAZ DE ADMINISTRACIÓN DEL AIRS. CAMPOS OBLIGATORIOS AL AÑADIR UN NUEVO COMPONENTE. ................. 289 FIGURA 9.3 INTERFAZ DE ADMINISTRACIÓN DEL AIRS BASADO EN ONTOLOGÍAS. GESTIÓN DEL RAZONADOR .............................. 290 FIGURA 9.4 INTERFAZ DE ADMINISTRACIÓN DEL AIRS BASADO EN ONTOLOGÍAS. DIAGRAMA DE COMPONENTES. ........................ 291

VII

Índice de tablas

TABLA 2.1 EXPRESIONES DEL PARÁMETRO CCI DEL SISTEMA ADEPTS. ................................................................................. 30 TABLA 2.2 FACTORES A TENER EN CUENTA EN EL CÁLCULO DE LA RAPIDEZ DE REACCIÓN DEL SISTEMA ADEPTS. ........................... 32 TABLA 2.3 CLASIFICACIÓN DE LOS AIRSS EXISTENTES. ....................................................................................................... 42 TABLA 2.4 MÉTRICA DE IDENTIFICADOR DE SESIÓN. AAIRS [CARVER01B]. ........................................................................... 47 TABLA 2.5 TABLA DE DECISIÓN. MÉTRICA DE IDENTIFICACIÓN DE ATAQUES. AAIRS [CARVER01B]. ............................................ 47 TABLA 2.6 ESTIMACIÓN DE IMPACTO MEDIANTE TABLAS. [MAGERIT-III12]. ....................................................................... 63 TABLA 2.7 MÉTRICAS DE RESPUESTA A INTRUSIONES. RESUMEN COMPARATIVO. .................................................................... 68 TABLA 2.8 MECANISMOS DE EVALUACIÓN DE LA RESPUESTA. RESUMEN COMPARATIVO. .......................................................... 72 TABLA 3.1 SINTAXIS DE INTERCAMBIO DE OWL2. ............................................................................................................ 83 TABLA 3.2 ANÁLISIS COMPARATIVO ENTRE SWRL, REI Y KAOS. ....................................................................................... 100 TABLA 3.3 RESULTADOS DE VALIDACIÓN DE RAZONADORES SEMÁNTICOS. ........................................................................... 115 TABLA 3.4 RAZONADORES SEMÁNTICOS. RESUMEN COMPARATIVO. .................................................................................. 116 TABLA 3.5 ANÁLISIS COMPARATIVO ENTRE LENGUAJES SEMÁNTICOS Y NO SEMÁNTICOS DE POLÍTICAS [GUERRERO07]. ................ 119 TABLA 4.1 REQUISITOS FUNCIONALES DEL AIRS BASADO EN ONTOLOGÍAS. .......................................................................... 125 TABLA 4.2 REQUISITOS DE ENTRADA DEL AIRS BASADO EN ONTOLOGÍAS. ........................................................................... 127 TABLA 4.3 REQUISITOS DE SALIDA DEL AIRS BASADO EN ONTOLOGÍAS. .............................................................................. 127 TABLA 4.4 LISTADO DE ACCIONES DE RESPUESTA CLASIFICADAS SEGÚN EL TIPO DE ACCIÓN. ..................................................... 147 TABLA 4.5 LISTADO DE ACCIONES DE RESPUESTA CLASIFICADAS SEGÚN EL TIPO DE INTRUSIÓN. ................................................ 150 TABLA 4.6 REQUISITOS FUNCIONALES DEL MÓDULO DE EJECUCIÓN DE ACCIONES DE RESPUESTA [GUAMAN13] .......................... 152 TABLA 6.1 EVALUACIÓN DE MÉTRICAS EXISTENTES. ......................................................................................................... 198 TABLA 6.2 MÉTRICA (CUALITATIVA) DE CONFIANZA EN EL IDS. ......................................................................................... 201 TABLA 6.3 MÉTRICA DE FIABILIDAD DEL INFORME DE INTRUSIÓN. ...................................................................................... 203 TABLA 6.4 MÉTRICA DE CONTINUIDAD DE ATAQUE. ........................................................................................................ 204 TABLA 6.5 ESCALA DE VALOR PARA LA MÉTRICA DE IMPORTANCIA DE UN ACTIVO. ................................................................. 205 TABLA 6.6 ENFOQUE UTILIZADO EN LA MÉTRICA DE INFERENCIA DE RESPUESTA ÓPTIMA POR LOS AIRSS. ................................... 208 TABLA 6.7 RESULTADOS DE LA PROPUESTA DE MÉTRICAS DE SEGURIDAD Y SU ESPECIFICACIÓN MEDIANTE SWRL. ....................... 215 TABLA 7.1 REQUISITOS FUNCIONALES DEL SISTEMA DE EVALUACIÓN DEL ÉXITO DE LA RESPUESTA. ............................................ 233 TABLA 7.2 TABLA DE MÓDULOS DE LA ARQUITECTURA IMPLICADOS EN CADA MODO DE FUNCIONAMIENTO DEL SISTEMA DE

EVALUACIÓN DE ÉXITO ..................................................................................................................................... 240 TABLA 8.1 REQUISITOS NO FUNCIONALES DEL AIRS BASADO EN ONTOLOGÍAS. .................................................................... 244 TABLA 8.2 DETALLE DE LOS COMPONENTES DEL ESCENARIO DE LA RED DE VALIDACIÓN. ......................................................... 267 TABLA 8.3 METASPLOITABLE: CREDENCIALES DE LOS USUARIOS. ........................................................................................ 271 TABLA 8.4 METASPLOITABLE: SERVICIOS VULNERABLES. .................................................................................................. 271 TABLA 8.5 VARIACIÓN DEL NÚMERO DE ALERTAS DE INTRUSIÓN RECIBIDAS Y ANALIZADAS EN FUNCIÓN DEL NÚMERO DE ALERTAS

CONCURRENTES. ............................................................................................................................................. 278

Capítulo 1: Introducción

1

INTRODUCCIÓN Capítulo 1

1.1 Introducción y Motivación

La seguridad en las redes informáticas es un área objeto de muchas investigaciones y estudios en los

últimos años. El incremento de la complejidad y sofisticación de los ataques e intrusiones, la

velocidad de difusión de los mismos en los sistemas de información y comunicación, la lentitud de

reacción frente al ataque y la dificultad de lanzar contraataques automatizados para bloquear los

ataques detectados, entre otras muchas causas, ha impulsado el diseño y desarrollo de diferentes

tecnologías especializadas en la seguridad en redes de telecomunicación destinadas a proteger a los

sistemas frente a diversos tipos de ataques. La tecnología ha madurado en cuanto a la sensibilidad

sobre la seguridad informática, y el ritmo de aparición de vulnerabilidades ha decrecido en los últimos

años. No obstante, se trata de un entorno muy dinámico en el que los ataques se modifican

constantemente, tanto en la forma como en fondo.

Actualmente, hay dos tecnologías principales involucradas en la seguridad informática [Villagra09]:

- Seguridad de acceso a la red: servicios de control de acceso que se encargan de proteger la

infraestructura local de la organización, los activos situados dentro del dominio de la

organización.

- Seguridad en las comunicaciones, protección de la información en tránsito: servicios y

arquitecturas destinadas a proteger la información mientras se está transmitiendo a través de

redes externas a la organización, sobre las que no se tiene capacidad de actuación para

restringir el acceso a dicha información.

Esta Tesis Doctoral se centra en los servicios y tecnologías del control de acceso a las redes de

telecomunicación, más concretamente, en los sistemas de defensa perimetral, cuyo objetivo es

restringir el intento de accesos externos no permitidos a los servicios internos de la organización

protegida.

Una intrusión ocurre cuando se explota una determinada vulnerabilidad de una red de

comunicaciones. Ante la imposibilidad de prever todas las vulnerabilidades que una red presenta, se

hace necesario detectar los usos maliciosos que de estas se hacen, siendo este el cometido de los

Sistemas de Detección de Intrusiones (IDS) y, recientemente, de los Sistemas Integrales de Gestión

de la Seguridad (SIM/SIEM).

Además de detectar un ataque de forma rápida y eficaz, es importante conocer cómo es más

apropiado reaccionar ante ese comportamiento intrusivo, en qué momento, quiénes son los actores

responsables de esta respuesta, qué acciones podrían llevarse a cabo para prevenir las

consecuencias de futuras intrusiones,… Los Sistemas de Respuesta frente a Intrusiones (IRS) son

los que dan respuesta a estas cuestiones. Según el tipo de respuesta proporcionado, los IRSs se

clasifican en tres grupos:


2

- Sistemas de notificación: grupo al que pertenecen la mayoría de los sistemas de respuesta

existentes en la actualidad, que se caracterizan porque la respuesta generada al detectar una

intrusión consiste exclusivamente en informes y alarmas, por lo que proporcionan únicamente

información al administrador del sistema indicando que ha ocurrido un ataque y se debe

responder a él.

- Sistemas de respuesta manual: grupo al que pertenecen los sistemas de respuesta que

además de informar al administrador del sistema de la existencia de una intrusión,

proporcionan un conjunto de respuestas que pueden ser útiles para contrarrestar al ataque

detectado. La elección de una respuesta u otra y la ejecución de la misma es tarea del

administrador.

- Sistemas de respuesta automática: grupo al que pertenecen los sistemas de respuesta que

responden inmediatamente a la intrusión sin necesidad de intervención del administrador del

sistema; es el propio sistema el que selecciona y ejecuta la respuesta más adecuada,

reduciendo en gran medida el tiempo de respuesta.

Tanto en los sistemas de notificación como en los sistemas de respuesta manual es necesaria la

intervención humana para llevar a cabo cualquier tipo de respuesta, lo que provoca que exista una

elevada latencia entre el instante en que se produce la detección y el momento en que se hace

efectiva la respuesta, latencia que puede llegar a ser inadmisible para ciertos servicios, sistemas o

máquinas comprometidas. De esta forma queda patente la necesidad de automatizar el proceso a

través de una entidad no humana, siendo una óptima solución los Sistemas de Respuesta Automática

frente a Intrusiones (AIRS).

El objetivo de un AIRS es inferir la(s) respuesta(s) óptima(s) frente a una intrusión detectada,

minimizando el impacto del ataque en el funcionamiento habitual de la organización atacada. Para

ello, hace uso de diferentes parámetros relacionados con la intrusión detectada, con el activo

comprometido, con el contexto de red o sistemas y con la propia respuesta. Estos parámetros

necesitan ser medidos por el sistema de forma automática mediante el uso de ciertas métricas, tarea

que en ocasiones se torna compleja. En la actualidad existen gran cantidad de métricas que permiten

medir parámetros relativos a la seguridad de los sistemas, pero que podrían no ser suficientes para

su uso en un AIRS. Por ello, es necesario especificar un conjunto de métricas de respuesta cuyo

objetivo es la inferencia de la respuesta óptima.

Por otra parte, un AIRS además de reaccionar de forma automática y en el menor tiempo posible

frente a una intrusión, es deseable [Stakhanova07] que posea una serie de características que a

continuación se enumeran:

- Adaptabilidad: por adaptabilidad se entiende la capacidad del AIRS de modificar y adaptar

automáticamente la elección de la respuesta en función de determinados factores, como por

ejemplo, la tasa de efectividad de la respuesta en anteriores ejecuciones, o cambios

producidos en el entorno. Es muy importante, por tanto, poder medir de forma automática el

éxito o eficacia de una acción de respuesta en anteriores ejecuciones, para que de esta

forma, el sistema tenga en cuenta su valor para posteriores inferencias.

- Sensibilidad al coste de las respuestas: el sistema debe considerar el coste y complejidad de

las respuestas, frente al impacto que supone el ataque a la organización, puesto que si el

coste de lanzar una determinada respuesta es superior al impacto de la intrusión, es

preferible no responder a la intrusión. Esta característica está orientada a la optimización de

recursos de la organización.

- Proactividad: uno de los grandes retos de la gestión de intrusiones también es la prevención,

es decir, cómo hacer para evitar ataques o al menos paliar en cierta medida ataques

inminentes. La proactividad en los AIRS es, por tanto, deseable. Es decir, el sistema debe

tener la capacidad de reaccionar frente a una intrusión antes de que está comprometa al

recurso objetivo, la capacidad de prever la ocurrencia de la intrusión y actuar en


3

consecuencia intentando controlarlo y prevenirlo mediante la ejecución de una acción de

respuesta.

- Coherencia semántica en la representación de la información: característica muy importante

en entornos de detección y reacción frente a intrusiones heterogéneos, entendiendo por

coherencia semántica la capacidad del sistema de ser capaz de entender y procesar las

alertas de intrusión no sólo desde un punto de vista sintáctico sino también semántico, con

independencia de la fuente de intrusión. Es decir, es la capacidad de que el sistema procese

alertas de intrusión procedentes de distintos IDSs, y que por tanto tienen formatos distintos, y

sea capaz de determinar si las alertas se refieren a la misma intrusión o a diferentes.

El problema de la coherencia semántica

En entornos heterogéneos como es el de la detección y respuesta a intrusiones, suelen emplearse

diferentes formatos y clasificaciones para representar la variedad de alertas y ataques existentes.

Ante esa situación, el AIRS puede recibir dos formatos sintácticamente diferentes pero

semánticamente iguales, y tratarlos como alertas de intrusión independientes, a pesar de ser alertas

asociadas a la misma intrusión. El sistema es incapaz de reconocer ambas alertas como

correspondientes a un mismo ataque porque no les atribuye el mismo significado.

Ante esta problemática es necesario dotar al AIRS de un mecanismo que tenga en cuenta la

semántica de las alertas y no sólo su sintaxis.

Una tecnología, que constituye una viable y consistente solución para abordar el problema de la

coherencia semántica en los AIRSs, son las ontologías y los mecanismos de razonamiento, muy

utilizados en la Web Semántica.

Por ello, a lo largo de esta memoria, se propone el uso de ontologías y herramientas de la Web

Semántica como son los lenguajes de especificación del comportamiento y los razonadores

semánticos como base de la arquitectura de un sistema de respuesta automática frentes a

intrusiones.

Además, de resolver el problema de la coherencia semántica en la representación, como se verá a lo

largo de la memoria, las ontologías presentan otra serie de ventajas, como por ejemplo su capacidad

de especificar comportamiento sobre un modelo de datos representado o la capacidad de inferir

nuevo conocimiento a partir de un conjunto de hechos, características de gran utilidad para la

inferencia de la respuesta óptima, objetivo de todo AIRS.

A continuación se presentan en mayor profundidad los objetivos que se plantean para esta tesis

doctoral.

1.2 Objetivos de la Tesis Doctoral

El objetivo principal de la tesis doctoral es diseñar, desarrollar e implementar un AIRS que sea capaz

de inferir la respuesta óptima ante una intrusión detectada que comprometa cualquier activo de una

red, en el menor tiempo posible. Además, el AIRS deberá satisfacer los requisitos mencionados en la

introducción. Para ello, es necesario analizar los parámetros involucrados en el proceso de elección

de la respuesta óptima e identificar las métricas que permiten medirlos.

Uno de los requisitos deseable en un AIRS es que se adaptativo, para lo que es necesario calcular la

eficacia o éxito de las respuestas en ejecuciones anteriores. Este parámetro forma parte, a su vez,

del proceso de inferencia de la respuesta óptima, y por tanto requiere ser medido.

Por otra parte, como solución al problema de la incoherencia semántica planteado, se propone el uso

de ontologías, lenguajes de reglas y motores de inferencia como base del AIRS.

Teniendo en cuenta lo especificado, es necesario realizar los siguientes estudios o análisis:


4

- Estudio y análisis de los distintos AIRSs existentes, identificando los componentes de su

arquitectura así como su mecanismo de funcionamiento. En dicho análisis se debe prestar

especial atención al hecho de si el sistema de respuesta bajo análisis satisface los requisitos

anteriormente enumerados.

- Estudio y análisis de distintas métricas de seguridad que permitan medir los parámetros

involucrados en el proceso de inferencia de la respuesta óptima.

- Estudio y análisis de las metodologías o métricas existentes que permitan obtener de forma

automática el éxito asociado a una acción de respuesta.

- Análisis de técnicas de representación de conocimiento y comportamiento, así como

razonadores semánticos existentes. Se estudiarán algunos lenguajes de ontologías

ampliamente difundidos cuyo objetivo es definir un dominio específico, así como lenguajes de

reglas cuyo objetivo es definir el comportamiento de los recursos representados en dicho

dominio.

Una vez analizados estos sistemas, métricas o técnicas, la tesis presenta las siguientes

contribuciones:

1. Propuesta de arquitectura de un sistema de respuesta a intrusiones basado en

ontologías. Se analizarán las ventajas de utilizar ontologías y lenguajes de

comportamiento en un sistema de respuesta automática frente a intrusiones, y se

propondrá una arquitectura de AIRS que además de inferir la respuesta óptima,

satisfaga el mayor número de requisitos deseables posible.

2. Propuesta de ontología de respuesta a intrusiones. Uno de los componentes

principales de la arquitectura del AIRS es la ontología. Por ello, tras analizar otras

ontologías de seguridad existentes, se propondrá una ontología que modele el

proceso de inferencia de la acción de respuesta, desde que la intrusión es detectada

hasta que se ha evaluado el éxito de la acción inferida.

3. Propuesta de métricas de seguridad y su especificación mediante SWRL. Cómo

medir los parámetros involucrados en la elección de la respuesta óptima es una tarea

crítica, por lo que una de las contribuciones de la presente tesis es la propuesta de

métricas de seguridad que permitan medir los parámetros críticos. Además, aquellas

métricas que determinen el comportamiento global del sistema deberán ser

especificadas mediante el lenguaje SWRL.

4. Propuesta de una metodología para la evaluación del éxito de una acción de

respuesta. Tan importante es inferir la mejor respuesta ante una intrusión como

evaluar si ésta ha tenido éxito mitigando la intrusión o no ha tenido ningún efecto.

Antes la dificultad de medir este parámetro de forma automática, esta propuesta

pretende definir una metodología automática que permita evaluar el éxito de una

acción de respuesta.

1.3 Estructura de la memoria

La memoria se encuentra estructurada en capítulos de la siguiente forma:

Capítulo 2: En este capítulo se aborda de forma breve el tema de la seguridad en redes de

telecomunicación, especificando los principales componentes encargados de llevarla a cabo.

Además, se presenta el estado del arte de los sistemas de respuesta automática frente a

intrusiones existentes, métricas de seguridad utilizadas por los AIRSs y metodologías o

sistemas de evaluación del éxito de una acción de respuesta, describiendo los aspectos más

relevantes en cada caso.


5

Capítulo 3: Capítulo que versa sobre el concepto de ontología y la inferencia de conocimiento

a través de mecanismos de razonamiento. Incluye un estudio de lenguajes formales de

definición de ontologías, lenguajes de especificación de comportamiento y motores de

inferencia semántica.

Capítulo 4: Capítulo que presenta la primera contribución de esta tesis: uso de ontologías,

lenguajes de reglas y razonadores semánticas como núcleo de la arquitectura de un AIRS. En

este capítulo se abordan las ventajas del uso de lenguajes formales para su uso en entornos

heterogéneos.

Capítulo 5: Capítulo que incluye la segunda contribución de esta tesis, que consiste en la

definición y especificación de una ontología de respuesta a intrusiones. En el capítulo se

describe detalladamente la metodología de desarrollo de la ontología, así como sus

principales clases y propiedades.

Capítulo 6: Capítulo que presenta la tercera contribución de la tesis doctoral: definición de

métricas de seguridad y su especificación mediante lenguajes de reglas. En el proceso de

inferencia de la acción de respuesta, es necesario medir ciertos parámetros. Este capítulo

aborda cómo medir dichos parámetros.

Capítulo 7: Capítulo que desarrolla la cuarta contribución de la tesis: diseño y desarrollo de

una metodología para evaluar de forma automática el éxito de una acción de respuesta

previamente ejecutada por el AIRS basado en ontologías.

Capítulo 8: Capítulo que muestra la validación de las propuestas de la tesis, mediante el

desarrollo de un conjunto de experimentos.

Capítulo 9: Capítulo en el que se presenta un análisis de la consecución de los objetivos

propuestos, así como las principales conclusiones extraídas al realizar el proyecto. Por último,

se proponen líneas futuras de investigación relacionadas.

Apéndice I: incluye una descripción de la interfaz de administración presente en la

arquitectura del AIRS basado en ontologías. Este componente permite configurar el AIRS, ya

sea mediante un GUI o por comandos, y visualizar los resultados que se han ido produciendo

a lo largo del tiempo.

Apéndice II: contiene el conjunto de reglas SWRL que especifican el comportamiento del

sistema de respuesta.

Apéndice III: define de forma breve los principales tipos de ataques de red, indicando

técnicas de detección y posibles mecanismos de respuesta.

Cap. 2: Seguridad en Redes de Telecomunicación. Sistemas de Respuesta Automática frente a Intrusiones: AIRS

7

Seguridad en Redes de Telecomunicación: Capítulo 2

Sistemas de Respuesta Automática frente a

Intrusiones (AIRS)

2.1 Introducción

Una vez se ha presentado la motivación y objetivos de la tesis doctoral, este capítulo recoge un

análisis del estado del arte de los Sistemas de Respuesta Automática frente a Intrusiones existentes,

explicando las diferentes arquitecturas propuestas y sus mecanismos de inferencia de la respuesta(s)

óptima(s). Además, se presenta una panorámica del estado del arte de las métricas de seguridad

utilizadas en cada uno de los AIRSs descritos, desde el punto de vista de su utilidad e importancia en

el proceso de inferencia.

Por otra parte, como se verá más adelante en este documento, el éxito o fracaso de respuestas

previas inferidas por el sistema es un parámetro esencial para su correcto funcionamiento, por lo que

este capítulo también incluye un estudio del estado del arte de los mecanismos de evaluación del

éxito de la respuesta existentes.

A modo de marco introductorio y con el fin de poner en contexto el trabajo realizado, en primer lugar

se define el concepto de seguridad en redes de telecomunicación, y la relevancia que ha ido

adquiriendo en los últimos años, explicando la importancia de los sistemas de defensa perimetral

como son los cortafuegos, IDSs (Intrusion Detection System), IPSs (Intrusion Prevention System), o

IRSs (Intrusion Response System).

2.2 Marco: seguridad en redes de telecomunicación

La seguridad informática es un conjunto de actuaciones que permiten proteger un entorno,

asegurando de esta manera que los recursos del sistema de información de una institución sean

utilizados de la forma acordada según las bases y políticas de la organización, así como que el

acceso y modificación de la información contenida sólo esté permitido a personas acreditadas y

dentro de unos límites establecidos. Las actuaciones más importantes son [Villagrá09]:

- Defensa: permite disminuir la probabilidad de incidentes lesivos, es decir, intenta evitar la

llegada de ataques a la organización protegida.

- Seguro: actuación cuyo fin es disminuir el impacto de un incidente lesivo por si se produce la

intrusión. Un ejemplo de seguro sería hacer copias de seguridad de la información.

Por otra parte, se puede entender la seguridad informática como un estado del sistema informático

que indica que dicho sistema está libre de peligro, daño o riesgo. Si bien es cierto que para la

mayoría de los expertos en el dominio de la seguridad informática, es utópico pensar que se pueda


8

tener un sistema seguro 100%, puesto que día a día surgen nuevas amenazas más sofisticadas y

para las que los mecanismos de seguridad aún no están preparados. Para que un sistema de

información pueda definirse como seguro debe tener una serie de características:

- Integridad: La información sólo puede ser modificada por personas autorizadas.

- Confidencialidad: La información sólo debe ser legible para los autorizados.

- Disponibilidad: Debe estar disponible cuando se necesita.

- Autenticidad: el emisor de la información es quien dice ser, no se puede negar su autoría.

Al abordar el tema de la seguridad informática es necesario definir una serie de conceptos

imprescindibles:

- Activo: Todo lo que posee una organización susceptible de ser atacado. Ejemplo: recursos

físicos, información almacenada, utilización de los servicios/recursos, personal, información

en tránsito, imagen, etc.

- Amenaza: evento que puede desencadenar un incidente en la organización, produciendo

daños en sus activos. Se clasifican según distintos criterios, (a) según su origen (entorno o

personal); (b) según el objetivo de la amenaza (ataque a recurso físico, ataques a utilización

de los recursos, ataques a la información almacenada, ataques a información en tránsito,

ataques a personas o ataques a la imagen o reputación).

- Vulnerabilidad: posibilidad de que una amenaza se materialice sobre un activo. Según las

medidas de seguridad que posea una organización y su plan de seguridad, se es más o

menos vulnerable.

- Impacto: Consecuencia de la materialización de una amenaza sobre un activo. Se utilizan

distintas métricas para medir el impacto, económicas o subjetivas.

- Riesgo: combinación de un cierto impacto y una vulnerabilidad. Es la posibilidad de que se

produzca un impacto en un activo. El mayor riesgo es aquel al que la organización es muy

vulnerable y además tiene mucho impacto para ella.

- Salvaguarda: Medidas destinadas a mitigar la importancia de los riesgos. Son sistemas de

prevención de ataques. Hay dos tipos, de Seguro que son medidas curativas, o de Defensa,

que son medidas preventivas.

- Ataque: evento, exitoso o no, que atenta sobre el buen funcionamiento del sistema.

Si se quiere dotar de gran seguridad a una organización es necesario llevar a cabo un proceso de

planificación de seguridad, completa y ordenada. Esta planificación consiste en indicar de qué y cómo

se quiere proteger una organización y cuánto cuesta, para lo que es necesario llevar a cabo un

análisis de riesgos y de costes exhaustivo y establecer unas políticas de seguridad adecuadas. La

planificación de la seguridad se basa en el Ciclo de seguridad, que se presenta a continuación:


9

Figura 2.1 Ciclo de seguridad del proceso de planificación de seguridad.

Existen diversas tecnologías o técnicas de seguridad que hacen posible implantar una política de

seguridad informática en una organización. Estas tecnologías indican cómo proteger los activos de la

red, llevando a cabo tareas de lucha o mitigación contras las amenazas. Actualmente, hay dos

grandes áreas involucradas en la seguridad informática [Villagrá09]:

- Seguridad de Acceso: servicios de control de acceso que se encargan de proteger la

infraestructura local de la organización, los activos situados dentro del dominio de la

organización. Su objetivo es limitar el acceso a los recursos de la red.

- Seguridad en las comunicaciones, protección de la información en tránsito: servicios y

arquitecturas destinadas a proteger la información mientras se está transmitiendo a través de

redes externas a la organización, sobre las que no se tiene capacidad de actuación para

restringir el acceso a dicha información.

El trabajo de investigación que ha dado lugar a esta tesis doctoral se centra en los servicios y

tecnologías del control de acceso lógico a las redes de telecomunicación, donde distinguimos dos

grupos de tecnologías:

- Sistemas de autenticación y autorización, que permiten un control de acceso lógico a los

servicios proporcionados por la organización a usuarios autorizados, tanto externos como

internos. Su filosofía de funcionamiento es demostrar que cada uno es quien dice ser. En la

actualidad, existen tres grandes grupos de sistemas de autenticación y autorización: sistemas

de autenticación biométrica, sistemas de autenticación por contraseña y sistemas de

autenticación dinámica.

- Sistemas de defensa perimetral, cuyo objetivo es restringir el intento de accesos externos no

permitidos a los servicios internos de la organización protegida. Se puede actuar en la

entrada de cada sistema vulnerable (defensa de sistema, para lo que se usan cortafuegos

personales) o en la entrada de la red (defensa de red).

Este trabajo se enmarca dentro de los sistemas de defensa perimetral (Ver Figura 2.2). .A

continuación se definen brevemente los conceptos de cortafuegos, IDS, IPS, e IRS, tecnologías

básicas e imprescindibles en este tipo de protección, prestando especial interés a los IRSs.


10

Figura 2.2 Seguridad en redes de Telecomunicación.

2.2.1 Cortafuegos

Los cortafuegos son los sistemas de defensa perimetral más conocidos y típicos, diseñados para

prevenir acceso no autorizado desde o hacia los equipos de una red, haciendo una función de filtrado.

Los cortafuegos pueden ser implementados mediante software, hardware o una combinación de

ambos. Existen dos tipos principales de cortafuegos:

- Cortafuegos personales: su objetivo es la defensa perimetral del sistema donde se instalan,

es decir, protegen a un sistema individual de los intentos de ataque que le llegan por la red,

filtrando todas las peticiones entrantes y salientes del host. Este tipo de cortafuegos tiene

utilidad en entornos pequeños, compuesto por uno o varios sistemas, en los que se puede

configurar y administrar individualmente la protección perimetral de cada uno, pero en

entornos grandes, con muchos sistemas, se hace imposible su administración.

- Cortafuegos de red: equipo que se sitúa en un punto de interconexión de subredes de una

organización y que filtra todos los mensajes entrantes y salientes de las máquinas de dichas

redes que pasan a través de él, los analiza y examina y bloquea o rechaza aquellos que no

reúnen las políticas de seguridad establecidas.

Los cortafuegos de red son los más comunes. En función del nivel de la torre de protocolos en el que

se produzca el filtrado de tráfico se distinguen cuatro tipos de cortafuegos:

- Cortafuegos transparente: cortafuegos a nivel de enlace, actuando como bridge entre

distintos segmentos de la red.

- Cortafuegos de filtro de paquetes: cortafuegos a nivel de red, que actúa como encaminador

de datagramas IP entre distintas subredes.

- Cortafuegos de circuitos: su funcionalidad está a nivel de transporte, conectando o

desconectando distintas conexiones TCP o UDP entre sí.

- Pasarela de aplicación: cortafuegos a nivel de aplicación que impone una configuración de

seguridad al conjunto de servicios de la red.

El cortafuegos más simple y utilizado es de filtro de paquetes, debido a la transparencia y nulo

impacto que supone para el resto de infraestructura de red. Este tipo de cortafuegos examina los

paquetes que llegan por cualquiera de sus interfaces y los contrasta con las configuraciones de

seguridad para determinar si el paquete debe seguir su camino hasta su destino, según la tabla de


11

encaminamiento, o debe ser bloqueado o tratado de alguna otra manera. La configuración de

seguridad es impuesta por el administrador del sistema en forma de un conjunto de reglas. Cada

regla contiene un conjunto de parámetros (origen, destino, servicio, interfaz…) y una acción asociada

(aceptar, rechazar o tirar). Cuando un paquete llega al cortafuegos, se contrastan los parámetros de

dicho paquete con los parámetros de las reglas secuencialmente, hasta encontrar una regla cuyo

conjunto de parámetros coincida con los del paquete bajo análisis. En ese instante, se ejecuta la

acción asociada a la regla, se pasa al siguiente paquete y se realiza el mismo proceso.

Además del filtrado de conexiones o paquetes en base a una política de seguridad, el cortafuegos

puede realizar otro tipo de funciones relacionadas con la seguridad, como cifrado de datos en tránsito

útil para el establecimiento de VPNs (Virtual Private Network), traducción automática de direcciones

(Network Address Translation, NAT), proxy transparente, balanceo de carga y seguridad en los

contenidos para distintas aplicaciones (Web, FTP y SMTP).

2.2.2 Sistemas de Detección de Intrusiones: IDS

En la defensa perimetral, además de los cortafuegos, hay un gran número de componentes que

ayudan en la detección, filtrado y mitigación de ataques remotos, como los Sistemas de Detección de

Intrusiones (IDSs), que se encargan de monitorizar eventos en busca de signos de comportamiento

malicioso o inesperado. Su función es detectar accesos no autorizados a una red informática. Existen

varios tipos de IDS [Amoroso99]:

- Según el tipo de fuentes de información que monitoricen:

HIDS (Host-based IDS): IDS que recopila información de un sistema (información de

actividades de usuario, información del sistema operativo, ficheros de sistema, etc.)

en busca de comportamiento anómalo o cualquier otro signo de intrusión. Monitoriza

un único ordenador por lo que la carga procesada es mucho menor, pero su gestión

en redes con muchos sistemas se vuelve muy compleja. Además, son susceptibles

de ser atacados.

NIDS (Network-based IDS): IDS basado en red que recopila información del tráfico de

la red. Son aquellos sistemas que están escuchando en la línea todo el tráfico de la

red en modo promiscuo, intentando identificar patrones de tráfico que se caractericen

como comportamientos anómalos o intrusiones. Este tipo de IDS es transparente a la

red e invisible para los atacantes, por lo que son sistemas muy seguros, pero tienen

problemas procesando el tráfico en redes con mucha carga o tráfico intenso.

NNIDS (Network-Node-IDS): IDS que monitoriza información de tráfico local, dirigido

hacia o generado por un único nodo.

AIDS (Application-based IDS): IDS que monitoriza la información de una aplicación

concreta dentro de un sistema. Su objetivo es detectar intrusiones específicas de

aplicación, como por ejemplo, intrusiones en servidores Web, bases de datos, etc.

- Según los principios de detección:

IDSs de detección de firmas (por patrones): se basa en buscar analogías entre lo que

ocurre en la red o sistema en un momento concreto y los patrones predefinidos que

describen un ataque conocido, su firma. Este tipo de IDSs no detecta nuevos ataques

si no se realiza la actualización de firmas constantemente. Hay pocos falsos positivos

(se detecta como anómalo algo que no lo es) pero muchos faltos negativos (se

considera normal comportamiento anómalo).

IDSs de detección de anomalías: se basa en la identificación de comportamiento

inusual en las fuentes de información. Para ello, se instala el IDS en un entorno

concreto carente de intrusiones para que aprenda (construye perfiles de actividad


12

normal de usuarios, hosts y conexiones de red). Al cabo de un cierto tiempo de

aprendizaje, se introducen intrusiones en el entorno y todo el comportamiento del

entorno distinto del aprendido, del normal, lo detecta como anómalo. El principal

problema de este tipo de IDS es que hay muchos falsos positivos.

- Según el tiempo que existe entre evento y análisis:

IDSs que realizan análisis periódico (Modo Batch). Este tipo de análisis no es el más

usual.

IDSs que realizan monitorización continua. La captura del evento y su análisis se

hace a la vez. Este es el tipo de IDS más común.

- Según la estrategia de control seguida:

IDSs con estrategia de control centralizada: cada IDS es un punto de detección de

eventos que se envían a un centro de análisis común, que se encarga de analizar los

eventos enviados por todos los IDSs de la red. De esta forma, se detectan intrusiones

casi simultáneamente. Todos los IDSs monitorizan datos, pero uno solo los analiza.

IDSs con estrategia de control distribuida: cada IDS de la red es independiente, es

decir, se encarga de monitorizar, recoger información y analizarla.

Los IDSs son dispositivos pasivos, encargados de la detección de intrusiones, y que en algunos

casos pueden llevar a cabo acciones de respuesta pasivas (alarmas, registros, notificaciones,

eventos, etc.) o raramente colaborar con el cortafuegos para crear reglas dinámicas de duración

limitada.

2.2.3 Sistemas de Prevención de Intrusiones: IPS

Los IPSs (Intrusion Prevention Systems) son sistemas que además de analizar la red en busca de

actividad maliciosa y registrar dicha actividad, intentan bloquear o detener la intrusión con acciones

de respuesta de protección básicas (terminación de conexiones, procesos y accesos asociados a la

intrusión, restablecimiento de conexión, bloqueo de tráfico de la IP atacante, etc.). Los IPSs son una

evolución de los IDSs, ya que por un lado realizan las funciones de detección de un IDS, y por otro

son capaces de prevenir las intrusiones detectadas mediante el bloqueo de las mismas.

Además de respuesta de bloqueo, un IPS puede responder a una amenaza detectada ejecutando

respuestas básicas: reconfigurar otros controles de seguridad, como un cortafuegos o un router, para

bloquear un ataque, aplicar parches de seguridad si el host tiene vulnerabilidades particulares, o

eliminar contenidos nocivos de un ataque, como por ejemplo un archivo adjunto infectado de un

correo electrónico antes de enviar el correo electrónico al usuario.

Los IPSs se pueden clasificar en cuatro tipos:

- NIPS (Network-based Intrusion Prevention System): monitoriza toda la red en busca de tráfico

sospechoso.

- WIPS (Wireless Intrusion Prevention System): monitoriza una red inalámbrica en busca de

tráfico sospechoso mediante el análisis de protocolos de redes inalámbricas.

- NBA (Network Behavior Analysis): analiza el tráfico de red para identificar las amenazas que

generan los flujos de tráfico inusuales, como ataques de DDoS (Distributed Denial of Service),

ciertas formas de malware y violaciones de política.

- HIPS (Host-based Intrusion Prevention System): este tipo de IPS es una aplicación software

instalada en un host que monitoriza su actividad para detectar actividades sospechosas

mediante el análisis de los acontecimientos que ocurren dentro de ese host.


13

Un IPS debe estar ubicado en línea con el flujo de transacciones que incluyen a la intrusión. Por

ejemplo: un IPS que responde a intrusiones generadas por un NIDS debe estar ubicado sobre un

cortafuegos a través del cual fluye el tráfico de la intrusión potencial [Desai03]; de la misma manera,

un IPS que responde a intrusiones generadas por un HIDS que monitoriza las llamadas al sistema,

debe estar ubicado necesariamente en el kernel del sistema operativo subyacente de tal forma que

pueda bloquear las llamadas al sistema asociadas a una intrusión [Rash05].

2.2.4 Sistemas de Respuesta a Intrusiones: IRS

Los Sistemas de Respuesta a Intrusiones (Intrusion Response Systems, IRSs) son dispositivos de

seguridad responsables de inferir y ejecutar una acción de respuesta frente a intrusiones detectadas

por otros dispositivos de seguridad como los IDSs. Un IRS no se limita a acciones de bloqueo sobre

dispositivos en línea, sino que generaliza las capacidades básicas de respuesta de un IDS,

disponiendo de un amplio catálogo de acciones de respuesta que se pueden ejecutar sobre otros

componentes de seguridad. De forma general, un IRS tiene tres componentes principales: el conjunto

de entradas (compuesto por un conjunto de eventos, tales como informes de intrusión procedentes de

los IDSs u otras fuentes de detección, información de seguridad, etc.), un proceso de razonamiento

que infiere la respuesta más adecuada en función de las entradas, y un conjunto de acciones de

respuesta que pueden ser elegidas para mitigar el ataque.

Según el tipo de respuesta proporcionado, los IRS se clasifican en tres grupos:

- Sistemas de notificación: grupo al que pertenecen la mayoría de los sistemas de respuesta

existentes en la actualidad, que se caracterizan porque la respuesta generada al detectar una

intrusión consiste exclusivamente en informes y alarmas, por lo que proporcionan únicamente

información al administrador del sistema indicando que ha ocurrido un ataque y se debe

responder a él.

- Sistemas de respuesta manual: grupo al que pertenecen los sistemas de respuesta que

además de informar al administrador del sistema de la existencia de una intrusión,

proporcionan un conjunto de respuestas que pueden ser útiles para contrarrestar al ataque

detectado. La elección de una respuesta u otra y la ejecución de la misma es tarea del

administrador.

- Sistemas de respuesta automática: grupo al que pertenecen los sistemas de respuesta que

responden inmediatamente a la intrusión sin necesidad de intervención del administrador del

sistema; es el propio sistema el que selecciona y ejecuta la respuesta más adecuada,

reduciendo en gran medida el tiempo de respuesta.

Además de los cortafuegos, IDSs, IPSs o IRSs, existen otras tecnologías de defensa perimetral como

pueden ser los inspectores de contenido, los sistemas de detección de sondas o los

honeypots/honeynets. Cada una de ellas tiene una función muy importante en la defensa del

perímetro de una red tanto de atacantes externos como internos, y la unión de todos ellos puede

proporcionar un elevado nivel de seguridad a la organización en la que se instalen.

El objetivo de este trabajo de investigación, como se ha indicado previamente, es la propuesta de

especificación de un AIRS, capaz de inferir la(s) respuesta(s) óptima(s) frente a una intrusión

detectada, minimizando el impacto del ataque en el funcionamiento habitual de la organización

atacada. La necesidad de un trabajo de investigación acerca de los AIRSs se debe a:

- Los IRSs son una de las tecnologías menos madura dentro de los sistemas de defensa

perimetral: los cortafuegos son tecnologías estables cuyo nivel de madurez es muy alto,

existiendo muchas soluciones comerciales. Por otra parte, en los últimos años la mayor parte

de las investigaciones y logros en el campo de la seguridad informática se han centrado en

desarrollar y mejorar los Sistemas de Detección de Intrusiones (IDS) y los sistemas de


14

prevención (IPSs), prestando mucha menos atención a los sistemas de respuesta. Por ello,

hay bastante trabajo que realizar dentro de esta área de la seguridad.

- Necesidad de respuestas automáticas, rápidas y eficaces: debido al aumento de los ataques

a los sistemas informáticos, tanto en número como en sofisticación, y a que la velocidad de

propagación de los mismos es cada vez mayor, es necesario reducir el slot de tiempo entre

detección y reacción, y mejorar la precisión y eficacia de las reacciones de respuesta

implementadas, además de una automatización de las mismas. Por ello, dentro de los IRSs

los sistemas de respuesta automática (Automated Intrusion Response Systems, AIRS) son en

la actualidad un área de interés en investigación y desarrollo dentro del ámbito de la

seguridad informática.

A pesar de su bajo nivel de madurez, existen propuestas de AIRSs realizadas por distintos

investigadores en la última década. La siguiente sección recoge un análisis del estado del arte de los

Sistemas de Respuesta Automática frente a Intrusiones existentes, explicando las diferentes

arquitecturas propuestas y sus mecanismos de inferencia de la respuesta(s) óptima(s).

2.3 Sistemas de respuesta frente a intrusiones propuestos

En los últimos seis años se han propuesto varias taxonomías de sistemas de respuesta automática

frente a intrusiones, de las que las más relevantes son las propuestas por Stakhanova

[Stakhanova07b] y Shameli-Sendi [Shameli-Sendi12 ]. De acuerdo con estas taxonomías, los AIRSs

se pueden clasificar en función de cuatro dimensiones.

Según el tiempo de respuesta.

En base a esta dimensión de la taxonomía los AIRSs se clasifican en reactivos o proactivos:

- Reactivo: aquel que ejecuta una acción de respuesta una vez que la intrusión ha sido

detectada y confirmada. Dicha confirmación puede basarse en métricas de confianza del IDS

o en una coincidencia completa del vector de ataque con la firma definida en la BDD de un

IDS [Stakhanova07b]. Por lo general un IRS reactivo intenta minimizar el daño causado por

una intrusión o restaurar el estado del sistema.

- Proactivo: aquel que tiene la capacidad de reaccionar frente a una intrusión antes de que está

comprometa al recurso objetivo. Tiene la capacidad de prever la ocurrencia de la intrusión y

actuar en consecuencia intentando controlarlo y prevenirlo mediante la ejecución de una

acción de respuesta. En la actualidad varias técnicas son empleadas para prever una

intrusión, algunas se basan aproximaciones probabilísticas, análisis del comportamiento del

usuario, o utilización de modelos dinámicos de Markov para predecir ataques multipaso.

En la Figura 2.3 se observa la relación existente entre una respuesta pasiva y activa (reactiva y

proactiva) representadas sobre el marco temporal de un ataque. En el instante t(n)-t el sistema se

encuentra en estado normal; en t(n) se detecta una intrusión y el IDS envía una alerta al AIRS; y en

t(n)+t se ejecuta la acción de respuesta reactiva. En función de estos tiempos sobre el marco

temporal del ataque, se tienen tres intervalos [Anuar10]:

- Tiempo tr antes de la alerta de intrusión (t(n)-t < tr < t(n)): En este intervalo de tiempo la

ejecución de una respuesta proactiva juega un rol importante previniendo un ataque sobre un

sistema de la red. Acciones de bloqueo y ajustes de configuración de sistemas de seguridad

pueden ser desplegadas en esta fase de ejecución proactiva.

- Tiempo tr después de la alerta de intrusión (t(n) < tr < t(n)+t): En este intervalo de tiempo se

ejecuta una respuesta reactiva cuyo objetivo es minimizar el impacto causado por la intrusión.

Acciones de bloqueo de tráfico, terminación de procesos, deshabilitación de usuarios, etc.,

pueden ser ejecutados. Para el despliegue de estas respuestas puede ser necesario


15

interactuar con otros componentes de seguridad como: cortafuegos, routers, aplicaciones

sobre hosts, entre otros. Esta fase de ejecución reactiva termina en el instante t(n)+t.

- Tiempo tr después de la ejecución de la respuesta reactiva (t(n)+t < tr): Este intervalo no tiene

tiempo de finalización, ya que se trata de una fase de investigación. En esta fase el IRS

evalúa y aprende de lo ocurrido en el incidente antes y después de la ejecución de la

respuesta, el resultado sirve como retroalimentación para futuras respuestas.

Figura 2.3 Relación entre respuestas proactivas y reactivas sobre el marco temporal de un ataque [Anuar10].

Según la capacidad de adaptación

Una vez que el AIRS ha seleccionado una respuesta, este puede evaluar o no el éxito de la misma

con el fin de obtener un factor de efectividad, factor puede ser utilizado a su vez para autoajustar o

adaptar el mecanismo de inferencia en posteriores ejecuciones.

En base a esta dimensión de la taxonomía los AIRSs se clasifican en estáticos o adaptativos:

- Estático: aquel cuyo mecanismo de selección de respuesta permanece invariante a lo largo

del tiempo, ya que no existe un seguimiento de la respuesta desplegada.

- Adaptativo: aquel que tiene la capacidad de ajustarse dinámicamente. Esta capacidad de

adaptación puede ser llevada a cabo de varias formas. La adaptabilidad es una característica

potente de los AIRSs que permite al sistema modificar y adaptar automáticamente la elección

de la respuesta en función de determinados factores, como por ejemplo, la tasa de efectividad

de la respuesta en anteriores ejecuciones, o cambios producidos en el entorno.

Según mecanismo de selección de la respuesta

En base a esta dimensión de la taxonomía, un AIRS se clasifica en:

- Estático: aquel en el que existe una correspondencia estática entre una intrusión y una acción

de respuesta. Siempre que se detecte la intrusión de un tipo determinado el sistema inferirá la

misma acción de respuesta. Estos sistemas son fáciles de construir y mantener pero son

predecibles (lo que los hace vulnerables) y no tienen en cuenta otros factores importantes

como el coste de la respuesta, el impacto de la intrusión, etc.

- Dinámico: aquel que realiza un mapeo dinámico, es decir, asocia una alerta de intrusión a un

conjunto de posibles respuestas. La selección de la mejor respuesta de entre este conjunto

puede estar basada en múltiples factores, como el estado actual del sistema, métricas de la

alerta de intrusión, o una política de red.

- Sensible al coste de las respuestas: aquel cuyo objetivo es seleccionar la respuesta óptima

pero sin sacrificar el funcionamiento normal del sistema comprometido. Es decir, tiene en

cuenta el coste y la complejidad de la respuesta además del coste del daño causado por una


16

intrusión. En cuanto a la forma de evaluar el coste de las respuestas se proponen a su vez

tres modelos, como se ve a continuación.

Según el modelo de evaluación del coste de la respuesta

En base al mecanismo utilizado para evaluar el coste de la respuesta en términos del impacto que

causa su aplicación en el sistema comprometido o atacado, un AIRS se clasifica en:

- Modelo estático: aquel AIRS en el que el coste de ejecutar una respuesta es obtenido

mediante la asignación de un valor estático basado en la opinión de un experto.

- Modelo de evaluación estática: aquel en el que el coste de ejecutar una respuesta es

obtenido estadísticamente evaluando los efectos positivos y negativos de ejecutarla. Los

aspectos positivos están basados en métricas de disponibilidad, confidencialidad, integridad y

rendimiento de cada respuesta. Mientras que los aspectos negativos pueden basarse en la

disponibilidad y rendimiento de otros recursos como consecuencia de su ejecución.

- Modelo de evaluación dinámica: aquel sistema que evalúa el coste de ejecutar una respuesta

de forma dinámica, en función del contexto subyacente de ese momento, como por ejemplo,

el número de usuarios conectados en un momento concreto. El sistema evalúa el coste de la

respuesta en función del contexto actual y cada vez que ejecuta el proceso de inferencia de

una acción de respuesta.

Es importante que al evaluar el coste de ejecutar una respuesta se considere el contexto sobre el que

se ejecuta, por ejemplo, tipo de ataque, importancia del host, localización del host, número de

usuarios actuales en el sistema, disponibilidad de otras aplicaciones, etc.

A la taxonomía presentada por Stakhanova y completada por Shameli-Sendi, se cree conveniente

añadir dos dimensiones más:

- Rapidez de reacción: un sistema de respuesta a intrusiones automático debe ser lo más

rápido posible, con el fin de reducir la ventana de ataque entre el momento de detección y el

de respuesta. En base a esta categoría los AIRSs se clasifican entre lentos y rápidos.

- Coherencia semántica: característica muy importante en entornos de detección y reacción

frente a intrusiones heterogéneos, entendiendo por coherencia semántica la capacidad del

sistema de ser capaz de entender y procesar las alertas de intrusión no sólo desde un punto

sintáctico sino también semántico, con independencia de la fuente de intrusión. Es decir, es la

capacidad de que el sistema procese alertas de intrusión procedentes de distintos IDSs, y

que por tanto tienen formatos distintos, y sea capaz de determinar si las alertas se refieren a

la misma intrusión o a diferentes.

Teniendo en cuenta las seis dimensiones en función de las cuales se puede clasificar un AIRS, lo

ideal sería que este fuera proactivo, adaptativo, sensible al coste de las respuestas y con un modelo

de evaluación dinámica, rápido y semánticamente coherente.


17

Figura 2.4 Taxonomía de Sistemas de Respuesta a Intrusiones.

En esta sección se describen los AIRS existentes más relevantes, destacando sus principales

características funcionales y no funcionales, su filosofía de funcionamiento y arquitectura. También se

hará un análisis para clasificar al AIRS en función de las 6 dimensiones de la taxonomía presentada.

2.3.1 CSM

Cooperating Security Managers (CSM, [White96]), es un sistema de detección y respuesta a

intrusiones basado en hosts y distribuido. El principal objetivo de CSM es detectar intrusiones en una

red de forma distribuida, sin necesidad de depender de un sistema o host que tenga la función de

director centralizado. Pero además de detectar e informar de los ataques detectados al gestor de la

red, este sistema fue diseñado para llevar a cabo respuestas básicas frente a actividad intrusiva. La

detección se realiza de forma cooperativa, mientras que la respuesta es a nivel local.

Este sistema se puede usar, por tanto, como detector de intrusiones (IDS) y como elemento de

respuesta automática (AIRS). Para la elaboración del presente trabajo de tesis, se ha considerado

exclusivamente su funcionamiento como sistema de respuesta, ignorando por tanto, su arquitectura,

filosofía de funcionamiento y características en cuanto a detección.

La arquitectura de componentes de CSM se observa en la siguiente figura.


18

Figura 2.5 Arquitectura de CSM.

Cuando una instancia de CSM instalada en cualquier host conectado a la red detecta una intrusión,

notifica inmediatamente al administrador del sistema del evento ocurrido. A continuación, se notifica a

todos los CSMs instalados en los hosts relacionados directamente con el host del usuario afectado.

Por otra parte, la instancia de CSM que detectó inicialmente la intrusión, selecciona y ejecuta la

acción más apropiada en respuesta al ataque (la acción elegida no sigue un patrón concreto; pueden

ser acciones de contención del ataque independientemente de las repercusiones que traiga para la

actividad de los usuarios de la red, acciones de respuesta que mitiguen el daño causado por el

ataque, etc.).

En la selección y ejecución de la respuesta a la intrusión, CSM utiliza tres componentes:

- Command Auditor: componente que examina el flujo de instrucciones del usuario y descarta

automáticamente las instrucciones que identifica como actividad sospechosa. Además

intercepta los comandos ejecutados por el usuario en estos casos y los envía al CSM - IDS

correspondiente para su análisis.

- Damage Control Processor (DCP): componente encargado de responder a la intrusión de una

forma reactiva. Para ello utiliza la taxonomía Fisch DC&A, que clasifica los respuestas en

función de las características del ataque detectado, y en base a esta clasificación obtiene

información necesaria para elegir una acción de respuesta adecuada. Para la elección de su

acción de respuesta además de esta taxonomía de respuestas, usa una métrica de confianza

de los IDS denominada nivel de sospecha (nivel de sospecha asignado al usuario por el IDS).

En función del valor de la métrica de nivel de sospecha, el DCP selecciona uno de los ocho

conjuntos de respuestas, cada uno de los cuales contiene de uno a catorce acciones de

respuesta diferentes. De este conjunto, asociado a un único par tipo de ataque-nivel de

sospecha, elige la acción de respuesta que estima más adecuada. Una vez que el intruso ha

abandonado el sistema defendido, las acciones de respuesta cesarán y el nivel de sospecha

del intruso es vuelto a poner a cero.

Por tanto, la taxonomía de ataques y el nivel de sospecha son los principales parámetros

sobre los que CSM basa su razonamiento a la hora de elegir una acción de respuesta.

Cuanto mayor es el nivel de sospecha, mayor es la probabilidad de que un ataque sea

detectado de forma correcta, reduciéndose el número de falsos positivos.

- Damage Assessment Processor (DAP): su función es restaurar el sistema al estado en que

se encontraba antes del ataque, en la medida de lo posible, una vez que el intruso ha

abandonado el sistema o ha cesado la causa del ataque.


19

La única información que posee y utiliza CSM de una intrusión es su nivel de sospecha, lo que limita

la efectividad del sistema, ya que cuando el intruso ha abandonado el sistema este parámetro se

pone a cero perdiendo así cualquier información relacionada con el atacante. Esto da lugar a que un

intruso que ataque al sistema y lo abandone una vez concluida su misión, tenga la oportunidad de

comenzar su ataque de nuevo en cualquier momento, sin que el sistema detecte que se trata de un

ataque antiguo, ya que no almacena ninguna información anterior. No presenta ningún mecanismo

para determinar si una alarma de intrusión detectada forma parte de un ataque antiguo o se trata de

un nuevo ataque.

Por otra parte, CSM no presenta métodos para evaluar o tener en cuenta la tasa de falsos positivos

de los IDS. Además, tampoco posee formas de medir el éxito de una respuesta anterior o la precisión

del IDS. El único mecanismo que posee para contrarrestar el ataque no es otro que una simple acción

pre-programada asociada con un nivel de sospecha concreto.

A continuación se analiza el sistema descrito, CSM, desde el punto de vista de las características

deseables de un AIRS (rapidez de reacción, adaptabilidad, proactividad, consideración de costes de

las respuestas y coherencia semántica) indicando cuáles de estas características posee el AIRS en

estudio.

Rapidez de reacción

No se dispone de datos suficientes para poder hacer un análisis de esta propiedad.

Proactividad

CSM es un IRS que no ha sido diseñado específicamente para tener un comportamiento proactivo,

pero puede proporcionar una reacción proactiva a un comportamiento intrusivo en algunos casos.

Para ello se dispone de una aproximación distribuida que combina varios hosts individuales

equipados con CSM. Cada host lleva a cabo una detección de intrusiones local, pero también se

encarga de notificar a otros sistemas CSM sobre actividades sospechosas que detecte. La

comunicación entre CSMs se implementa usando TCP. Cada uno de los host que ha sido notificado,

despliega una respuesta proactiva con el fin de prevenir el ataque, en lugar de esperar a que la

intrusión cumpla su cometido.

Adaptabilidad

Como se ha indicado previamente, CSM no ejecuta métodos para medir el éxito de una respuesta, ni

tampoco tiene un concepto dinámico de las operaciones que se están llevando a cabo en la red y el

estado de las mismas, o de las dependencias entre los distintos servicios. Por ese motivo, no puede

adaptar sus respuestas en el tiempo de ataque. Es un sistema estático, no adaptativo.

Consideración del impacto de las respuestas

El sistema no utiliza un mecanismo de selección de respuesta sensible a costes, por lo que, en

principio no proporciona la propiedad de considerar el impacto de las respuestas. La selección de la

estrategia de respuesta se basa en la técnica dynamic-mapping, según la cual en función de las

características del ataque, así es la respuesta (una intrusión se corresponde con uno y solo un

conjunto de acciones-respuesta). La elección de la respuesta es competencia del componente

Damage Control Processor (DCP).

Coherencia semántica

No se han encontrado referencias para poder hacer un análisis exhaustivo de esta propiedad, pero ni

siquiera plantea el problema de la coherencia semántica en la representación de las alertas, ni cómo

tratar alertas de intrusión duplicadas.


20

2.3.2 EMERALD

Event Monitoring Enabling Responses to Anomalous Live Disturbances (EMERALD, [Porras97]), es

un sistema de detección y respuesta a intrusiones distribuido. Como se observa en Figura 2.6, la

arquitectura de EMERALD consiste en una colección jerárquica de controladores (observadores),

cada uno de los cuales emplea un sistema experto que invoca tratamientos de respuesta basados en

el análisis de los informes de ataques recibidos de los IDSs. Cada controlador consta, a su vez, de

cuatro componentes principales:

- Profile Engine: componente de detección estadístico de anomalías del sistema.

- Signature Engine: componente de inferencia (deducción) basado en la firma de las

intrusiones o atacantes del sistema.

- Resource Object: librería configurable que proporciona a los otros tres componentes del

controlador la información y datos que necesiten. En este componente, además, se produce

la definición de las posibles respuestas. Para determinar una respuesta apropiada se hace

uso de dos métricas asociadas: una métrica de umbral y una métrica de gravedad. La primera

representa la confianza que tiene el sistema en que la intrusión detectada por los IDS es real

(es un verdadero positivo). La segunda es una medida o tasa del posible efecto negativo de

las respuestas sobre el funcionamiento normal de las operaciones de la red. Las respuestas

que tengan una tasa de gravedad alta solo son elegidas como estrategia de respuesta frente

al ataque en el caso de que la confianza depositada en que un ataque es real sea bastante

alta, asumiendo que respuestas de menor gravedad no están presentes o no han tenido

efecto.

- Resolver: componente de respuesta y responsable del análisis de los informes de los

ataques, de coordinar los esfuerzos de respuesta y de elegir la respuesta adecuada teniendo

en cuenta las políticas de seguridad vigentes. Este componente es un sistema experto que

recibe informes procedentes de los componentes de análisis y posteriormente invoca a los

elementos adecuados para el tratamiento de las respuestas concretas. Las posibles

respuestas se definen en el Resource Object.

Figura 2.6 Arquitectura de EMERALD.

EMERALD es un sistema de respuesta cooperativo, es decir, la respuesta no se deduce de forma

local en cada controlador independientemente del resto de controladores; cada controlador tiene

habilidad o capacidad para dar respuesta a una intrusión. La distribución jerárquica permite el

despliegue de controladores independientes a través de las diferentes capas abstractas de la red.

Cada controlador contiene un componente denominado Resolver, (como se ha indicado en el párrafo

anterior) que además de ser responsable de la elección de la estrategia de respuesta en su nivel


21

local, también es capaz de comunicarse con Resolvers de otras capas de EMERALD, participando en

una selección de respuesta global.

Al igual que CSM, este IRS no presenta métodos para evaluar o tener en cuenta la tasa de falsos

positivos de los IDS. Además, tampoco posee formas de medir el éxito de una respuesta o de

determinar si una alarma de intrusión detectada forma parte de un ataque antiguo o se trata de un

nuevo ataque.

De la misma manera que se hizo al describir el sistema CSM, se procede al análisis de las

características que presenta EMERALD.


No se dispone de datos suficientes para poder hacer un análisis de esta propiedad.

Proactividad

EMERALD no dispone de ningún módulo específico que permita cumplir esta propiedad. Tampoco

presenta la posibilidad de distinguir entre ataques nuevos y ataques ya tratados, y ninguno de los

componentes tiene la capacidad de detectar la intrusión antes de que el ataque se produzca.

Adaptabilidad

EMERALD no tiene métodos para medir el éxito de una respuesta, ni tampoco tiene un concepto

dinámico de las operaciones que se están llevando a cabo en la red y el estado de las mismas, o de

las dependencias entre los distintos servicios. Por ese motivo, no puede adaptar sus respuestas en el

tiempo de ataque. Es un sistema estático, no adaptativo.


El sistema no utiliza un mecanismo de selección de respuesta sensible a costes, por lo que, en

principio, no proporciona la propiedad de considerar el impacto de las respuestas. La selección de la

estrategia de respuesta se basa en la técnica dynamic-mapping, según la cual en función de las

características del ataque, así es la respuesta (una intrusión se corresponde con uno y solo un

conjunto de acciones-respuesta).

En cambio, a la hora de determinar la respuesta que mejor se adapta a las características de la

intrusión, de entre las pertenecientes al conjunto de respuesta asociado a una intrusión, se usa una

métrica de gravedad, esto es, una medida o tasa del posible efecto negativo de las respuestas sobre

el funcionamiento normal de las operaciones de la red. Por tanto, podríamos considerar que este

sistema sí tiene en cuenta el impacto de las respuestas de una manera local, es decir, de un conjunto

de respuestas reducido asociado a una intrusión en particular.



siquiera se plantea el problema de la coherencia semántica en la representación de las alertas, ni

cómo tratar alertas de intrusión duplicadas.

2.3.3 AAIRS

Adaptive Agent-based Intrusion Response System (AAIRS [Carver01a]), es un sistema automático de

respuesta frente a intrusiones adaptativo, basado en agentes inteligentes y orientado a sistemas de

intrusiones basados en host (HIDS), cuyo principal objetivo es responder de la forma más rápida y

eficaz posible a los ataques detectados en el sistema para minimizar su impacto. En la elección de la

respuesta óptima tiene en cuenta principalmente tres factores: la tasa de falsos positivos de cada IDS

que genera la alerta de intrusión, los resultados de las respuestas lanzadas, y el tipo de ataque al que

es necesario responder. Además, posee la capacidad de adaptar el plan de respuesta desarrollado

en función de los resultados de las métricas.


22

El diseño del sistema propuesto incluye una taxonomía de respuesta a intrusiones y una arquitectura

de funcionamiento del sistema AAIRS propiamente dicha. La taxonomía proporciona una clasificación

teórica de las respuestas que puede llevar a cabo el sistema, y la arquitectura describe el modelo

conceptual del sistema, como se muestra en la siguiente figura:

Nube

PolicySpecification

ResponseTaxonomy

TacticsMaster Analysis

System AdminTool

IntrusionDetection

System

Interface

Analysis

ResponseToolkit

Response

Figura 2.7 Arquitectura de AAIRS.

Cada uno de los componentes de la arquitectura tiene una función concreta y específica:

Interface: traduce las alertas que llegan de cada IDS a un formato genérico común,

generando un documento resultante llamado incident report (informe de incidencia). Además,

este componente actualiza una métrica de confianza en el IDS que generó la alerta de

intrusión procesada, en función del número de falsos positivos y falsos negativos que genere

dicho IDS. Después de cada incidente, el administrador del sistema indica si el incidente era

un ataque real o una falsa alarma; esta información se la envía al Interface que actualiza la

métrica de confianza en el IDS. En la arquitectura propuesta hay un Interface agent por cada

IDS. Una vez generado el informe y actualizada la métrica de confianza, se envían al Master

Analysis.

- Master Analysis: recibe el informe de incidencia generado en el módulo Interface, y determina

si se trata de un nuevo ataque o de una continuación de un ataque existente, para lo que se

basa en tres métricas internas: tiempo (tiempo transcurrido entre el último incident report

recibido para cada Analysis agent y el informe actual), identificador de sesión (dirección IP y

nombre de usuario) y tipo de ataque. En función del resultado de una combinación de los

valores de estos tres parámetros, decide si se trata de un nuevo ataque o es una

continuación de uno antiguo. En el primer caso, crea un nuevo módulo Analysis agent que

será el encargado de elaborar un plan de respuesta para el nuevo ataque. Si el informe de

incidencia pertenece a un ataque ya monitorizado, remite el incident report al módulo Specific

Analysis agent correspondiente a ese ataque en concreto. En ambos casos, envía el informe

de incidencia y la métrica de confianza correspondiente.

- Analysis: cada uno de estos agentes se encarga del análisis de un incidente concreto y de

generar un plan de respuesta adecuado, teniendo en cuenta la métrica de confianza en el

IDS, el informe de incidencia, la meta de las respuestas, el histórico de planes ejecutados y

éxito de los mismos, y las políticas especificadas. Para generar el plan, involucra a tres

componentes de la arquitectura: System Admin Tool que proporciona información sobre las

metas de las respuestas disponibles, así como la definición de las políticas que luego aplicará

el agente Policy Specification, Response Taxonomy agent que clasifica el ataque, y Policy

Specification agent que aplica restricciones al plan de respuesta en base a limitaciones


23

legales, éticas, institucionales o limitaciones de los propios recursos. Este componente

adapta el plan de respuesta en función de los cambios que se producen en el entorno (por

ejemplo, un nuevo informe de incidencia recibido o indicios de que las acciones

seleccionadas previamente no están proporcionando el resultado esperado), ante lo que

puede continuar con el mismo plan, adaptar el plan o inferir un nuevo plan de respuesta

completamente nuevo.

Un plan de respuesta está compuesto por uno o más plan steps, y cada uno de ellos tiene

asociado un conjunto de tácticas o acciones específicas que ejecutan el plan step.

- Tactics: componente encargado de descomponer cada táctica o acción específica en

diferentes implementaciones. Cada táctica se ejecuta invocando al componente adecuado del

Response Toolkit (colección de ejecutables y scripts que llevan a cabo la respuesta a la

intrusión) para su implementación. Tanto el Analysis agent como el Tactics agent emplean

mecanismos de toma de decisiones adaptativos basados en el éxito de previas respuestas.

Este componente aparece en versiones iniciales de la arquitectura, pero fue incluido en el

componente Analysis en versiones posteriores.

- Response Taxonomy: se encarga de la clasificación del ataque en base a varios factores,

tiempo del ataque, tipo de ataque, tipo de atacante, grado de sospecha, implicaciones del

ataque (importancia del activo atacado). Estos 5 factores constituyen las dimensiones de la

taxonomía del sistema de respuesta. Una vez clasificado el ataque, se genera un plan de

respuesta específico para él.

- Policy Specification: limita el plan de respuesta generado por el Analysis. Estas restricciones

son impuestas en el System Admin Tool.

- Response Toolkit: es una colección de ejecutables y scripts que implementan la respuesta.

Además, mide el éxito o fallo de la ejecución de estos scripts. Proporciona al sistema de

respuesta y proporciona el resultado como feedback para posteriores decisiones.

- System Administrator Interface: proporciona una interfaz para el administrador del sistema

que le permite realizar diferentes funciones: monitorizar y revisar incidentes y respuestas

asociadas, suspender la función del AIRS, proporcionar feedback al sistema, establecer el

conjunto de políticas que debe cumplir el sistema, y añadir nuevos IDSs y su Interface

asociado.

En cuanto a las características requeridas en un AIRS, las principales conclusiones extraídas del

análisis de AAIRS se resumen a continuación.


No se han encontrado datos para poder hacer un análisis de esta propiedad. Se podría considerar

que el módulo Master Analysis contribuye a acelerar el proceso de respuesta, debido a que es capaz

de distinguir entre ataques nuevos o ya monitorizados, lo que provoca que en este segundo caso no

se genere un nuevo módulo Analysis, sino que se compruebe para el agente ya existente los planes

de respuesta generados previamente y si tuvieron o no éxito. En caso de haber sido exitoso no

genera un nuevo plan sino que utiliza el mismo o lo adapta haciendo mínimas modificaciones.

Proactividad

No dispone de ningún módulo específico que permita cumplir esta propiedad. Presenta la posibilidad

de distinguir entre ataques nuevos y ataques ya tratados, pero ninguno de los componentes tiene la

capacidad de detectar la intrusión antes de que el ataque se produzca.

Adaptabilidad

El sistema es adaptativo. Los componentes de la arquitectura involucrados son:


24

- Interface: modifica la métrica de confianza asociada a cada IDS. Después de cada incidente

el administrador indica si el incidente es un ataque real o un falso positivo; este componente

utiliza el resultado para modificar la métrica de confianza, que será tenida en cuenta por el

sistema para ajustar el plan de respuesta.

- Analysis agent: ajusta el plan de respuesta determinado en el caso de que se produzcan

cambios en el entorno durante el tiempo del ataque, además de tener en cuenta el éxito de

anteriores planes ejecutados.

- Response Toolkit: proporciona retroalimentación del éxito o fracaso de la ejecución de la

respuesta, lo que permite actualizar los pesos en el conjunto de posibles respuestas frente a

una intrusión en función de los resultados experimentados.


En cuanto al mecanismo de selección de respuesta el sistema usa principalmente la técnica dynamic

mapping (mapea una intrusión con un conjunto de respuestas), que consiste en clasificar el ataque y

en base a su clasificación seleccionar una respuesta del conjunto de respuestas.

Del análisis realizado, se podría interpretar que en función de las políticas incluidas en el Policy

Specification agent el sistema utiliza un mecanismo de selección de respuesta sensible a costes, en

el cuál se toma en cuenta el impacto de las respuestas. Es decir, si se incluye una restricción basada

en la condición de que el impacto y coste de las respuestas no superen un determinado umbral, y en

caso de que dicho umbral se supere, la respuesta será filtrada y no podrá ser incluida en el plan de

respuesta generado, se podría considerar que el sistema usa un mecanismo de selección de

respuesta sensible a costes.


La especificación de la arquitectura de AAIRS no plantea el problema de la coherencia semántica en

la representación de las alertas, ni cómo tratar alertas de intrusión duplicadas. El componente

Interface traduce las alertas que llegan de cada IDS a un formato genérico común, pero con el único

fin de facilitar la inferencia de la respuesta óptima, no para distinguir diferentes alertas con diferente

sintaxis pero semánticamente iguales.

2.3.4 SARA

Survivable Autonomic Response Architecture (SARA [Lewandowski01]), es un sistema de respuestas

automáticas coordinadas que fue desarrollado en un principio para defender sistemas de información,

pero que también puede ser usado en una gran variedad de sistemas de comunicación fuera del

dominio de protección de información. El principal objetivo de SARA consiste en la resolución de dos

hipótesis previas:

- Una reacción efectiva contra ataques de información distribuidos, rápidos y actuales, requiere

respuestas rápidas y automáticas.

- Las respuestas coordinadas son más eficaces que las respuestas reactivas locales.

El IRS SARA es un claro ejemplo de sistema de respuesta que confirma las dos afirmaciones

anteriores, ya que su principio de funcionamiento es desplegar respuestas automáticas y

coordinadas.

Antes de describir la arquitectura del sistema, es necesario hacer una breve referencia a los

conceptos de respuesta automática y respuesta automática coordinada.

Un sistema de respuesta automática perfecto debería ser capaz de tomar decisiones racionales

consistentes con metas introducidas por humanos. Dicho sistema debería tomar las decisiones para

encontrar las metas mucho más rápido y con mayor precisión de lo que un humano lo podría hacer.


25

Un sistema de respuesta automática coordinada debería cumplir el requisito definido para el sistema

de respuesta automática pero además dicha respuesta se toma mediante la colaboración de todos los

elementos que forman el sistema, basándose en el conocimiento global del sistema defendido, y no

en simple información local del lugar concreto en el que se produce el ataque. Construir un sistema

de componentes coordinados requiere una arquitectura unificada para proporcionar un marco común

en el que los componentes puedan operar, para proporcionar comunicación entre los componentes

de cooperación, para que estos sean integrados unos con otros para formar un sistema de defensa

cohesivo.

Se necesita, por tanto, una arquitectura eficaz capaz de soportar respuesta automática y coordinada

para lo que debe cumplir los siguientes requisitos: rapidez y eficacia, flexibilidad y extensibilidad,

introspectividad, seguridad, tolerancia a fallos y no vulnerabilidad, y escalabilidad.

SARA es una arquitectura que reúne todos los requisitos anteriores. Es capaz de soportar la toma de

decisiones necesarias para garantizar la seguridad en un sistema de forma rápida. Está compuesta

por un conjunto de componentes que proporcionan habilidades importantes al sistema y un conjunto

de interfaces que permiten la comunicación entre los componentes. La siguiente figura muestra los

componentes e interfaces incluidos en la arquitectura de SARA.

Figura 2.8 Arquitectura de SARA.

Componentes:

- SDAR: conjunto de componentes que proporcionan información para coordinar y efectuar la

respuesta tomada. Se comunican unos con otros mediante un lenguaje de comunicación

concreto que expresa ideas sobre el sistema defendido. Según su función se clasifican en:

Sensores: recogen datos sobre el sistema defendido y ponen dicha información a

disposición de otros componentes. Genera informes con los datos recibidos que se

componen de eventos y estado del sistema.

Detectores: determinan si la salida del sensor (evento y estado) indica la existencia

de una amenaza para el sistema defendido o puede constituir una actividad maliciosa

o sospechosa, analizando la respuesta del sensor en el contexto propio del sistema.

Convierten la información del sensor en información que puede ser usada por

motores para la toma de decisiones.

Decisores: eligen las respuestas apropiadas para mantener la calidad del servicio.

Hay dos tipos, los decisores más simples que proporcionan respuestas pre-

programadas, y los decisores más complejos a los que les llegan entradas que


26

disparan una toma de decisiones de forma razonada e base a la estructura de

defensa del sistema global. Estos componentes pueden organizarse de diferentes

maneras. La manera más sencilla es que cada uno de ellos actúe de forma

independiente. También puede existir una jerarquía de decisores, lo que dota al

sistema de abstracción y escalabilidad. Otra organización es una coordinación

centralizada por host, cada uno con su propio decisor; esta organización aumenta la

tolerancia a fallos del sistema.

Efectores: efectúan cambios en el sistema. Llevan a cabo las acciones sugeridas por

los decisores o intermediarios.

- RTI (Run-Time Infrastructure): componente que proporciona servicios de comunicación y

coordinación a los SDAR a través de la interfaz de servicios RTI. Envuelve varios servicios

estándar tales como IP, PKI, cifrado, autenticación, acceso persistente y tiempo de

sincronización. Proporciona una interfaz de servicios de alto nivel adaptada a la seguridad de

la información. Dicha interfaz puede variar y es lo que define la funcionalidad del RTI. Toda

comunicación entre los SDAR debería producirse vía RTI, aunque alguna herencia de

software necesite emplear canales de comunicación privados.

- System Model: es un componente importante pero complejo de la arquitectura. Es un modelo

de sistema común facilitado por SARA para realizar la toma de decisiones de una manera

más eficaz. Este modelo captura el contexto del sistema defendido y describe características

del mismo, tales como el hardware y el software usado. Un elemento muy importante de este

modelo es la relación que existe entre componentes. Estas relaciones incluyen: topología de

red, programas y aplicaciones que se están ejecutando en los ordenadores del sistema, el

estado actual de la misión en curso, etc. La información que contiene el modelo puede ser

usada por los componentes de coordinación con el fin de incrementar la calidad de las

decisiones. Para que tenga una mayor eficacia y sea coherente, todas las entidades en un

sistema deben tener el mismo modelo común, para evitar interpretaciones diferentes de la

información y evitar que las respuestas decididas sean incompatibles. Un System Model se

compone de una plantilla de modelo de sistema (contiene las definiciones de datos para las

entidades y relaciones capturadas por el modelo, mostrando el conjunto de todos los

sistemas que SARA es capaz de defender) y un caso o ejemplo de modelo de sistema

(plantilla aplicada a un sistema concreto).

- Manager: componente encargado del control y la monitorización. Se encarga de controlar el

sistema a través de interfaces de gestión. Proporciona funciones tales como estado de

monitorización, informes de estado, configuración del sistema actual, etc. Esta información

ayuda a los operadores humanos a configurar y mejorar el sistema SARA, con el fin de

aumentar su eficacia. Es un elemento de realimentación.

Interfaces:

- Lenguaje de comunicación: permite que los SDAR entiendan la información contenida en el

System Model e intercambien información entre ellos. El lenguaje se basa en una jerarquía de

clases, que ayuda a organizar la información para ser usada más eficazmente. Además

aporta extensibilidad al sistema. Las características de este lenguaje influye en la cantidad y

tipo de conocimiento que debe ser distribuido en el sistema.

- Interfaz de Servicios RTI (API): proporciona un soporte general para la comunicación entre

los SDAR, el RTI y servicios básicos que son relevantes para todos los SDAR (creación y

destrucción de SDAR, conexión y abandono del sistema SARA, comunicación cliente/RTI,

etc.). El API de SARA abstrae los servicios del RTI en una colección de clases que dan a los

componentes poder desarrollador y flexibilidad de desarrollo robusto.

- Interfaz de Servicios Standard: la plataforma del host proporciona al RTI acceso a los

servicios estándar. Algunos de estos servicios incluyen servicios proporcionados por sistemas


27

operativos modernos, seguridad y librería de open source. En función del diseño del RTI

usado en la arquitectura, estos servicios específicos serán unos u otros.

- Interfaz de gestión: proporciona funciones de control y monitorización. Ayuda al operador a

configurar y mejorar el sistema SARA.

De igual forma que se hizo al estudiar los sistemas de respuesta anteriores, se procede al análisis de

las características que presenta SARA.


Este sistema es más lento a la hora de reaccionar ante un ataque que los sistemas reactivos locales,

puesto que es un sistema de respuestas coordinada, lo cual ralentiza la respuesta. Un factor

importante que contribuye a mejorar esta característica es la buena definición del System Model,

teniendo un modelo de sistema común para todos los elementos y componentes del sistema.

Además, la organización de los SDAR es un factor a tener en cuenta en el análisis de la rapidez de

reacción.

Proactividad

El sistema descrito no posee la propiedad de proactividad, debido a que no tiene la capacidad de

prever la intrusión antes de que el ataque se produzca. Cuando el ataque se detecta, es cuando se

desencadena la respuesta. También es cierto que la respuesta es una respuesta global a todo el

sistema, por lo que de algún modo estaría previniendo que ese mismo ataque se produjera en otro

punto de la red o sistema defendido.

Adaptabilidad

El sistema descrito es un sistema estático, por lo que no posee la característica de adaptabilidad. No

posee ningún componente que permita informar acerca de cambios que se están produciendo

durante el tiempo de ataque, con el fin de modificar la respuesta tomada en base a estos cambios. La

realimentación la hacen a posteriori, a través del componente Manager, que informa al usuario del

resultado del ataque y el estado del sistema, para que este pueda mejorar la eficacia del sistema.


No se han encontrado referencias para poder hacer un análisis de esta propiedad. En caso de

tomarse alguna medida que considerase el impacto de las respuestas, se realizará en los decisores.




cómo tratar alertas duplicadas.

System Model mantiene un modelo común de sistema usado por todos los componentes, de forma

que todas las entidades interpreten de la misma forma la información y evitar que las respuestas

decididas sean incompatibles. Pero el modelo común es sobre los componentes de la red y las

relaciones entre ellos, no sobre los informes de intrusión.

2.3.5 ADEPTS

Adaptive Intrusion Tolerant Systems (ADEPTS [Foo05], [Wu07]), es un AIRS basado en grafos cuyo

objetivo es monitorizar y rastrear intrusiones detectadas en un sistema distribuido de servicios

relacionados, en especial sistemas de comercio electrónico, y desplegar una respuesta adecuada

capaz de contener los ataques y evitar su propagación a otras secciones del sistema. Tiene la

capacidad de reconocer los ataques lo más rápido posible y estimar el daño producido por los

mismos, y de adaptarse a cambios producidos en el entorno o en el contexto de la intrusión. Además,

a la hora de desplegar la respuesta adecuada tiene en cuenta resultados de respuestas anteriores


28

reduciendo así la efectividad de futuros ataques. En la siguiente figura se observa la arquitectura de

ADEPTS.

CCI Computation

AlgorithmI-GRAPH

Response Set Computation

Algorithm

Response Control Center

Feedback System

Response Repository

IDSAlertas

(1)

Nodos (2)

Actualizar nodos (3) Etiquetar

nodos (5)Nodos

(4)

Nodos

Conjunto de nodos (6)

Respuestas (7)

Respuestas a desplegar (8)

RI, EI

Feedback

Figura 2.9 Arquitectura de ADEPTS.

ADEPTS considera una taxonomía de ataques propietaria, I-GRAPH, que consiste en una estructura

en forma de grafo dirigido donde cada nodo representa a un ataque. A partir de esta estructura y de

los informes de intrusión procedentes de los IDS, ADEPTS estima la trayectoria más probable de

propagación del ataque dentro del sistema. En la estructura I-GRAPH hay tres formas de propagación

de los ataques:

Nodos OR: para alcanzar el nodo/ataque padre, al menos uno de los nodos/ataques hijo ha

de ser alcanzado.

Nodo AND: para alcanzar el nodo/ataque padre, todos los nodos/ataques hijo han de ser

alcanzados.

Nodos QUORUM: para alcanzar al nodo/ataque padre, han de ser alcanzados como mínimo

los nodos/ataques hijos especificados por el quórum

Una sección de un ejemplo de utilización de I-GRAPH en un sistema de comercio electrónico

distribuido se muestra a continuación.


29

Figura 2.10 Ejemplo de estructura I-GRAPH usada en un sistema e-commerce distribuido [Foo05].

En la figura anterior se distinguen 13 nodos que se corresponden con 13 objetivos de ataque

diferentes. Para la consecución del ataque número 13, MySQL information leak, se tienen que haber

alcanzado previamente los nodos 12, 9, 2, 1 ó 6, y en este último caso, los nodos 4 y 5. El sistema

ADEPTS realizará el seguimiento de la propagación de los ataques con el fin de estimar sus

trayectorias a seguir, y poder evitarlos, desplegando respuestas de contención.

El elemento principal de la arquitectura de ADEPTS es la taxonomía I-GRAPH. Tomando esta como

base, ADEPTS, en respuesta a informes de intrusiones procedentes de los IDSs o de cualquier otro

mecanismo de detección de intrusiones, ejecuta algoritmos que determinan por un lado la

propagación del ataque y por otro la respuesta a desplegar más adecuada. Un mecanismo de

realimentación evalúa el éxito o fracaso de una respuesta desplegada previamente y tiene en cuenta

este resultado para elecciones posteriores.

Con el fin de facilitar la comprensión del funcionamiento del sistema ADEPTS se presenta una

descripción de alto nivel del proceso seguido desde que el mecanismo de detección de intrusiones

genera los informes de alerta hasta que se actualizan los datos tras la ejecución de la respuesta.

Detección de alertas: los mecanismos de detección de intrusiones del sistema generan

alertas de ataques cuando detectan cualquier anomalía en el funcionamiento habitual del

sistema. Estas alertas se almacenan en la cola de alertas del sistema/s de respuesta a

intrusiones. Cada alerta corresponde a un ataque, que tendrá un objetivo concreto. Cada

ataque detectado se corresponde, a su vez, con un nodo del I-GRAPH. Cuando llegan

nuevas alertas, los nodos correspondientes a ellas se reordenan y se da paso a la siguiente

fase.

Cálculo de Probabilidades: una de las ventajas de este sistema es la facilidad de creación y

actualización del I-GRAPH. En esta fase el sistema realiza el cálculo de las probabilidades de

las posibles trayectorias de propagación que pueden seguir los ataques, que consta de dos

partes: actualización del I-GRAPH y cálculo de probabilidades.

Para actualizar el I-GRAPH, el sistema ejecuta el algoritmo “CCI Computation Algorithm”,

cuyo objetivo es determinar qué nodos del I-GRAPH han sido probablemente alcanzados,

para lo que hace uso del grado de certeza de la alerta correspondiente a cada nodo, y el CCI

(Compromised Confidence Index) de sus nodos hijos inmediatos. Por una parte, cada

detector proporciona un grado de certeza para cada alerta generada por él, que repercute

directamente en el cálculo del CCI. Por otra, el CCI es un parámetro propio de cada nodo que

indica la medida de la probabilidad de que un nodo haya sido alcanzado. El cálculo y

actualización de este parámetro en cada uno de los nodos es el resultado final del algoritmo.

El parámetro CCI se obtiene según lo especificado en la siguiente tabla:


30

Tabla 2.1 Expresiones del parámetro CCI del sistema ADEPTS.

Parámetro Valor Condiciones

CCI

certeza_alerta si el nodo no tiene hijos

f’(CCIi) si no hay alerta previa y se produce

actualización del nodo

f(f’(CCIi, certeza_alerta)) en otro caso

Donde, la función f’ está determinada por la siguiente expresión:

{

( ) ( )

( )

(2.1)

Y la función f es la media del resultado obtenido tras aplicar la función f’, y el parámetro

certeza_alerta.

Una vez actualizado el valor del CCI en cada nodo, se ejecuta el algoritmo “Response Set

Computation Algorithm”, para determinar en qué nodos hay mayor probabilidad de que se

propague el ataque actual. Esto permitirá al algoritmo de respuesta desplegar las respuestas

adecuadas en los puntos del sistema apropiados. Como resultado de este algoritmo se

produce un etiquetado de cada nodo, siguiendo el siguiente criterio:

Nodo “Strong Candidate” (SC) si CCI > threshold.

Nodo “Weak Candidate” (WC) si CCI ≤ threshold y se puede llegar a un nodo SC solo

a través de nodos AND.

Nodo “Very Weak Candidate” (VWC) si CCI ≤ threshold y se puede llegar a un nodo

SC a través de cualquier tipo de nodo.

Nodo “Not Candidate” (NC) en otro caso.

Un nodo etiquetado como SC indica que ese nodo ha sido ya alcanzado, mientras que las

etiquetas WC y VWC indican que existe una probabilidad muy baja de que la trayectoria de

propagación del ataque sea a través de ese nodo.

Los componentes de la arquitectura involucrados en este paso del proceso son CCI

Computation Algorithm, I-GRAHP, Response Set Computation Algorithm.

- Generación de un conjunto de respuestas: en esta fase el sistema selecciona los nodos a

los que se va a responder (Response Set), en función de la política del AIRS:

Política “Aggresive”: al Response Set pertenecen todos los nodos SC, y los WC y

VWC que tengan al menos un padre NC.

Política “Moderate”: al Response Set pertenecen todos los nodos SC y los WC que

tengan al menos un padre NC.

Política “Conservative”: al Response Set pertenecen todos los nodos SC que tengan

al menos un padre NC.

- Elección y Despliegue de la respuesta: en esta fase, para cada nodo contenido en el

Response Set, el módulo Response Control Center elabora una lista de posibles respuestas

(respuesta = opcode + operand (uno o varios)) de entre las almacenadas en el Response

Repository (que contiene todas las respuestas disponibles). Para cada respuesta

seleccionada, el Response Control Center calcula un parámetro característico denominado

Response Index (RI). En función del valor de este parámetro se elige la respuesta más


31

apropiada, para posteriormente ejecutarla. La respuesta con mayor valor de RI es la

respuesta seleccionada. Matemáticamente, el parámetro RI se calcula de la siguiente

manera:

RI = a * EI – b * DI (2.2)

donde EI (Effectiveness Index) es un parámetro que indica la efectividad de una respuesta

desplegada ante un determinado ataque, y DI (Disruptiveness Index) es un parámetro que

indica cómo de negativa o perjudicial es la respuesta para los usuarios del sistema, es decir,

en qué grado afecta la ejecución de la respuesta a los usuarios del sistema atacado. a y b

son parámetros configurables.

- Realimentación: una vez ejecutada la respuesta elegida, un módulo del sistema denominado

Feedback System, toma nota de los resultados obtenidos, los analiza y extrae conclusiones

acerca de los mismos, indicando si los resultados obtenidos son los esperados o no. Para

ello, comprueba que en un plazo de tiempo establecido (Time To Live) posterior al momento

de despliegue y ejecución de la respuesta, no se detectan nuevos ataques del mismo tipo que

el respondido, o una evolución de los mismos. La realimentación se produce gracias a la

variación del parámetro EI, que aumenta o disminuye según se detecten o no ataques

objetivo de la respuesta ejecutada en un tiempo inferior al TTL establecido.

Si no se detectan ataques durante el TTL se incrementa el valor de EI correspondiente a la

respuesta evaluada en una cantidad fija configurable. Si por el contrario, se detectan nuevos

ataques (del mismo tipo o una evolución), se disminuye el valor de EI de la siguiente manera:

EI = EI – cantidad_fija * factor_por_nodo (2.3)

donde factor_por_nodo tiene la siguiente expresión,

factor_por_nodo = CCI_nodo / (∑ CCI_hijos_nodo) (2.4)

- Fallo de detección: fase independiente de las demás. En ella se estima el porcentaje de

falsos positivos de cada uno de los detectores de intrusiones y se modifica el nivel de

confianza del sistema en el detector correspondiente según sea conveniente (a mayor

número de falsos positivos, menor confianza). Este nivel de confianza será de utilidad para la

elección de una política de funcionamiento del AIRS u otra (“Aggresive”, “Moderate” y

“Conservative”).

Como se ha llevado a cabo en la descripción de los AIRS analizados, se procede al análisis de las

características que presenta ADEPTS.


Computacionalmente son varias las estructuras de datos a las que hay que acceder, lo que

repercutirá en el tiempo total de ejecución del algoritmo que permite seleccionar la respuesta óptima.

Suponiendo que:

N = número de nodos.

A = número de nodos atacados.

R = número de nodos en el “Response Set”.

C = número de ataques en una cola.

H = número de hijos de un nodo.

P = número de padres de un hijo.


32

D = distancia entre un par de nodos.

Entonces:

Tiempo = N*(selección_alerta + actualización_CCI)+A*(etiquetado_nodo +

selección_response_set)+R*(cálculo_EI + actualización_EI) (2.5)

donde los valores de los factores que influyen en el cálculo del coste aparecen recogidos en la

siguiente tabla:

Tabla 2.2 Factores a tener en cuenta en el cálculo de la rapidez de reacción del sistema ADEPTS.

Parámetro Valor Condición

selección_alerta

0 “Conservative”

C “Moderate”

C “Aggresive”

actualización_CCI

0 Nodo sin hijos

N Actualización de nodo sin alerta previa

H En otro caso

etiquetado_nodo

0 CCI > threshold

D CCI ≤ threshold y se puede llegar a un nodo SC

solo a través de nodos AND

D CCI ≤ threshold y se puede llegar a un nodo SC a

través de cualquier nodo

D En otro caso

selección_response_set P En todos los casos

cálculo_EI R +R*N

actualización_EI D*H

En el peor de los casos, cuando A = N, R = N, D = N, la política es “Aggresive”, los nodos tienen

todos hijos excepto uno y el CCI de los nodos no supera el threshold, el coste total es:

Coste = N3 + N2 (1 + H) + N(D + P + C + H) – H (2.6)

Proactividad

Gracias a su árbol de caminos de intrusiones evita que los ataques evolucionen, por lo que se puede

considerar que es un AIRS proactivo. Como se observa en el diagrama de flujo, el segundo paso en

ADEPTS es calcular la probabilidad del siguiente nodo dentro del grafo de ataques. De esta forma, el

sistema se “adelanta” al ataque, pudiendo actuar en consecuencia.

Adaptabilidad

Cada nodo del árbol tiene un peso función del grado variable de confianza en las alertas.

Además, el conjunto de posibles respuestas frente a una intrusión se actualiza en función de los

resultados experimentados.

Por otra parte, al finalizar la ejecución de la respuesta elegida, el componente Feedback System,

evalúa si la respuesta ha sido exitosa o por el contrario no ha tenido efecto, reflejando el resultado en

la actualización del parámetro EI (Effectiveness Index).


33


Las respuestas se eligen en función del EI y el DI, teniendo en cuenta por tanto el coste de la

respuesta, ya que DI es un parámetro que indica cómo de negativa o perjudicial es la respuesta para

los usuarios del sistema.


No se han encontrado referencias para poder hacer un análisis exhaustivo de esta propiedad, pero no

se plantea el problema de la coherencia semántica en la representación de las alertas.

2.3.6 MAIRF

Mobile Agents-based Intrusion Response Frame (MAIRF [Wang06]), es un sistema de respuesta

automática frente a intrusiones efectivo para usuarios de redes basado en agentes móviles cuyo

objetivo es reconocer y conocer el dominio (o parte del entorno) que es más vulnerable y por tanto, es

propenso a ser atacado, así como rastrear a los atacantes.

MAIRF se concentra en la esencia de los atacantes: la fuente de los atacantes, su origen. Tan pronto

como un IDS detecte una intrusión, se informará a MAIRF de que debe rastrear y localizar la intrusión

de forma automática. Gracias a este rastreo prematuro se pueden iniciar las acciones de respuestas

frente a la intrusión antes de que ésta llegue a nuestro sistema. Por otra parte, además de proteger

las infraestructuras de red de forma efectiva, este sistema detecta gran número de unidades

principales invadidas o atacadas en el pasado, lo que permite analizar y aprender del tipo de

respuesta que se dio en ese momento y del resultado obtenido.

Permite integrar las tecnologías de seguridad de red existente (cortafuegos, routers de seguridad…),

para formar un sistema de protección y de seguridad, multinivel y de gran alcance, y dada la claridad

de la estructura del sistema, posee una buena capacidad de expansión y de resistencia a la

destrucción de alta eficiencia.

Uno de los inconvenientes que posee MAIRF es la necesidad de desarrollar y diseñar las tácticas de

respuesta, y establecer un mecanismo de comunicación segura entre los agentes móviles.

La Figura 2.11 muestra la arquitectura del sistema, donde se observan sus componentes:

Figura 2.11 Arquitectura de MAIRF [Wang06].

A continuación se describen brevemente cada uno de los componentes presentes en dicha

arquitectura:


34

- Detector: es el componente base de la operación sistemática y el primer paso de todo el

proceso. Tiene la habilidad de detectar ataques contra un host individual. Está presente en

cada objeto del sistema y busca los datos sospechosos monitorizando las fuentes de datos

del sistema. Si encuentra algo sospechoso, graba los datos, y arranca el IRA en el host para

responder a la intrusión a tiempo. Además, envía los mensajes grabados donde se indica que

se ha detectado algo anómalo al MB y RC. Por tanto, este componente tiene una función

rastreadora, de agente de detección de intrusiones.

- Response Controller (RC): analiza mensajes proporcionados por los agentes móviles según

el modelo de estrategia de la respuesta elegida. Controla y dirige al agente móvil y el

Message Board (MB). Además, proporciona una interfaz de usuario para que se pueda

producir el diálogo entre el administrador y el sistema. Hay un RC por cada segmento de red.

- Tracing Agent (TA): tras recibir la información del detector, el RC lanza un TA en el sistema

objetivo, define la trayectoria de la intrusión e identifica sus puntos de origen. A continuación,

el TA desplegado migrará a otro sistema objetivo (a través del camino trazado previamente

por el RC), según la necesidad, y una vez allí activará el detector local para poder seguir

coleccionando más mensajes relacionados con actividades sospechosas. Si el TA alcanza el

punto origen de la intrusión o no puede continuar la trayectoria iniciada, vuelve a RC.

- Learning Agent (LA): módulo basado en agentes móviles que divaga al azar en todos los host

del sistema. El LA realiza acciones de minería de datos en registros correlativos para

encontrar nuevos focos de intrusión y enviarlos al RC, de manera que pueda realizar su

función de forma eficaz, mejorando así la capacidad de aprendizaje del sistema.

- Message Board (MB): módulo general accesible por agentes móviles, que proporciona

intercambio de información entre los distintos módulos del sistema. Es un módulo con función

de información. Hay un MB en cada segmento de la red (al igual que los RC). Al MB llegan

mensajes de muy diversas fuentes cuando se producen los siguientes eventos:

Siempre que el RC lance un TA en cualquier host, envía un mensaje que incluye el

identificador del TA lanzado y el identificador del host objetivo.

Si el TA alcanza el host objetivo, éste lanza un mensaje de éxito de llegada al MB.

Este mensaje será utilizado por el RC para preguntar por la posición y condiciones de

trabajo del TA (el RC deberá preguntar al MB que es el componente que posee la

información).

Los diferentes TAs intercambian información a través del MB. Éstos utilizan dicha

información para obtener datos que indican si el sistema que están controlando fue

controlado por otro TA en un instante anterior, y usar esta información para decidir

qué acciones emprender en cada momento y circunstancia con el fin de optimizar la

respuesta.

RC puede llevar a cabo análisis de datos de más alto nivel gracias a la función de

información del MB.

MB reúne los datos enviados por el Detector.

- IRA: módulo basado en agentes móviles. Este módulo es lanzado cada vez que se detecta

una intrusión por el detector, y también al inicio del sistema por el RC. En este último caso, el

RC lanza el IRA apropiado al host que necesita ser alojado, lo que supone una primera

acción de respuesta. Esta respuesta previene que el host objetivo sea destruido

posteriormente.

- DA: en caso de que un sistema sea atacado, es importante que los usuarios de la red sepan

cómo reanudarlo. Este módulo proporciona un método de evaluación efectivo que permite

reanudar el sistema.


35

- SA: migra al MB regularmente, y explora el contenido del mismo. Coordina y distribuye

ataques en el MB. Una vez que el MB ha reunido los datos enviados por el Detector, el SA lo

chequea y lo actualiza, lo que permite que el MB devuelva los datos del sospechoso

actualizados al RC mejorando así la capacidad de aprendizaje del sistema.

- Communicator: responsable de la comunicación entre agentes o entre agente y plataforma.

A continuación se procede al análisis de las características de MAIRF.


No se han encontrado datos para poder hacer un análisis de esta propiedad.

Proactividad

El principio de funcionamiento de MAIRF es detectar el origen o fuente de la intrusión desde un host

cualquiera del sistema una vez que se ha producido el ataque de un activo de la red, con el fin de

evitar que se propague la intrusión a otros puntos del sistema. Esta capacidad de prevención pone de

manifiesto el comportamiento proactivo del AIRS. Por tanto, MAIRF tiene la capacidad de prever la

intrusión antes de que el ataque tenga lugar.

Adaptabilidad

El sistema es adaptativo. El proceso de adaptación se produce de la siguiente forma: el LA y el SA

obtienen nuevos focos de intrusión, actualizan los ya detectados y envían los resultados al RC. El RC

analiza los mensajes proporcionados por estos agentes móviles para modificar y actualizar la

estrategia de respuesta elegida, y para mejorar la capacidad de aprendizaje del sistema.


Este sistema no tiene ningún componente que utilice un mecanismo de selección de respuesta

sensible a costes por lo que no proporciona la propiedad de considerar el impacto de las respuestas.



siquiera se plantea el problema de la coherencia semántica en la representación de las alertas.

2.3.7 FAIR

Flexible Automated Intelligent Responder (FAIR [Papadaki06]), es un sistema de respuesta

automática frente a intrusiones, que además de reaccionar frente a incidentes sospechosos que se

producen en los sistemas de una red, posee un módulo de detección de ataques a nivel de host, que

trata de solucionar el problema de la elevada tasa de falsas alarmas generadas por los IDSs actuales.

Por tanto, FAIR es un sistema de detección y de respuesta a nivel de host, cuya motivación es reducir

la tasa de falsas alarmas generada por los IDSs en la detección de intrusiones, debido a que las

redes son cada vez más grandes y complejas.

La función de detección se basa en el análisis de actividad a nivel de host. En cada uno de los

sistemas conectados a la red, hay un agente colector de información que monitoriza la actividad que

se está produciendo en cada momento en dicho sistema, y la envía al motor de detección de FAIR,

que se encarga de procesarla y generar una alerta de intrusión en caso de actividad anómala o

sospechosa. A continuación, el núcleo de FAIR selecciona la respuesta más adecuada frente a la

intrusión detectada, partiendo de la alerta generada, del perfil del sistema atacado, del conjunto de

respuestas disponibles, de actividad de contexto de sistema, y de una política de respuesta específica

para cada escenario de intrusión.

La Figura 2.12 muestra los principales elementos de la arquitectura de FAIR.


36

Figura 2.12 Arquitectura de FAIR.

La arquitectura consta de dos sistemas: sistema cliente (cualquier sistema o host conectado a la red

que se quiere proteger con FAIR) y sistema FAIR (máquina o host donde se ejecuta el AIRS). En una

organización que utilice FAIR, habrá un único sistema FAIR, y tantos sistemas clientes como

máquinas haya en la arquitectura de red. Cada uno de los elementos incluidos en ambos sistemas

tiene una función crucial para el correcto funcionamiento de FAIR:

- Collector: elemento de los sistemas clientes encargado de recolectar información relacionada

con la actividad actual en el sistema objetivo (aplicaciones y procesos en ejecución,

conexiones de red activas, carga del procesador y usuario(s) activo(s) en el sistema), y

proporcionar dicha información al Detection Engine. Esta información de contexto será

utilizada para detectar incidentes o ataques, y en el proceso de elección de la respuesta

óptima.

- Detection Engine: se encarga de analizar la información sobre la actividad en el sistema que

le envía el Collector, y genera alertas en caso de indicios de intrusión. Esta alerta incluye,

entre otra información, el tipo de intrusión, el número de sistemas afectados o información

sobre el atacante, en caso de que sea posible.

- Intrusion Specifications: contiene información sobre tipos de intrusiones específicas y sus

principales características: la severidad y amenaza, el impacto (en la confidencialidad,

integridad y disponibilidad), la velocidad con la que el ataque se propaga, y la vulnerabilidad

explotada. Esta información la fija el administrador previamente.

- Profiles: contiene información sobre las características de los sistemas y usuarios dentro de la

organización (tipo de sistema, nivel de importancia, dependencias con otros sistemas,

sistema operativo, usuarios, aplicaciones críticas, y otras aplicaciones). Esta información se

almacena en una base de datos local de perfiles, y FAIR la utiliza en el proceso de elección

de la mejor respuesta. El no acceder directamente a los sistemas para obtener dicha

información en tiempo de intrusión supone una ventaja, ya que asegura que aunque el

sistema no esté disponible debido al ataque, FAIR tiene acceso a toda la información.


37

- Response Actions: contiene las acciones de respuesta disponibles, especificando sus

características más relevantes: tipo de acción, fase, transparencia, eficiencia, etc. Estos

parámetros serán tenidos en cuenta en el proceso de elección de la respuesta óptima.

- Response Policy: componente del sistema que usa tecnologías de sistemas expertos para

indicar qué características “ideales” deben tener las acciones de respuestas a ejecutar (fase

de la respuesta idónea, máxima severidad permitida, y eficiencia mínima exigida), en función

del contexto de intrusión proporcionados por los otros módulos del sistema (contexto de

intrusión, perfil del sistema comprometido, amenaza total, confianza en la alarma, etc.). Estas

características “ideales” y un conjunto de reglas, constituyen la política de respuesta a cumplir

por el sistema en un escenario de intrusión concreto.

- Responder: núcleo del sistema encargado de inferir la acción de respuesta apropiada frente a

una intrusión dada, y de enviar dicha decisión al agente de respuesta de la máquina

comprometida para su ejecución. Este componente, analiza la información de contexto

enviada por el Collector, la alerta de intrusión que genera Detection Engine, el perfil del

sistema comprometido, la información específica relativa al tipo de intrusión, las acciones de

respuesta disponibles y la política de respuesta generada por Response Policy. De ese

análisis obtiene como resultado dos conjuntos de respuestas: las respuestas candidatas, que

requieren autorización del administrador para ejecutarse, y las respuestas aceptadas, que se

ejecutan automáticamente.

- Responder Agent: componente situado en el sistema cliente encargado de ejecutar las

acciones de respuesta en el sistema comprometido.

El proceso de selección de la(s) respuesta(s) adecuada(s) en sí mismo, se divide en dos fases:

- Fase Inicial: en esta fase, el Responder selecciona un conjunto de respuestas candidatas del

total de acciones de respuesta disponibles, en función del tipo de intrusión. Además, el

componente Response Policy determina las características “ideales” de la respuesta en

función del contexto de ataque. Estas características (Response Phase más adecuada,

máximo nivel de Stopping Power permitido, o importancia de Response Efficiency en

comparación con la transparencia e impacto negativo de la respuesta en el sistema) se

incluyen en un conjunto de reglas que constituyen la política de respuesta a aplicar.

- Fase final: en esta fase, Responder aplica la política de respuesta al conjunto de respuestas

candidatas para obtener las respuestas aptas, o apropiadas. El sistema las ejecuta

automáticamente sin intervención del administrador.


análisis de FAIR se resumen a continuación.


FAIR utiliza dos parámetros que influyen en la rapidez de reacción:

Urgency to Respond: este parámetro calculado por el componente Responder, depende de si

el ataque es nuevo o una continuación de uno anterior. Para ello, se calcula el número de

alertas generadas para el mismo incidente, y en función del resultado obtenido, el sistema

responderá con mayor o menor urgencia ante un informe de intrusión.

Información y aplicaciones críticas: información incluida en los perfiles de cada sistema de la

organización que especifica donde está la información crítica. En caso de que dicha máquina

se vea comprometida, FAIR responderá con mayor rapidez.

No obstante, no se dispone de datos cuantitativos suficientes para poder hacer un análisis de esta

propiedad.


38

Proactividad

FAIR es un sistema de respuesta reactivo, y no dispone de ningún componente específico que

permita cumplir esta propiedad. Distingue entre ataques nuevos y ataques continuación de otro ya

existente, pero sólo para calcular el parámetro Urgency to Respond, no para responder frente al

ataque antes de que se produzca.

Adaptabilidad

Utiliza el éxito o efectividad de una respuesta para elegir la respuesta óptima, pero es el

administrador quien determina el valor de dicho parámetro y proporciona feedback al sistema.


El sistema utiliza un mecanismo de selección de respuesta sensible a costes, por lo que, en principio,

tiene en cuenta el coste e impacto de las respuestas en el proceso de inferencia de la estrategia de

respuesta.




cómo tratar alertas de intrusión duplicadas.

2.3.8 IDAM & IRS

Intrusion Detection Alert Management and Intrusion Response System (IDAM&IRS [Mu10a]) es un

sistema de respuesta automática frente a intrusiones que se basa en el algoritmo HTN (Hierarchical

Task Network) para la inferencia de la acción de respuesta para cada escenario de intrusión. Este

algoritmo consiste en crear un plan de respuesta por descomposición de tareas en subtareas hasta

lograr primitivas que pueden ser ejecutadas directamente. La dependencia entre las acciones se

proporciona en forma de red, y el plan de respuesta permite alcanzar una meta impuesta por el

administrador del sistema. El objetivo de IDAM & IRS es conseguir la siguiente tupla:

Donde k representa el escenario de intrusión particular, Ψ es la meta de respuesta impuesta por el

administrador, ζ es la estrategia de respuesta asociada a esa meta y KP son los puntos de acciones

de respuesta dentro de dicha estrategia.

IDAM&IRS incluye ocho metas de respuesta que el administrador puede seleccionar en función del

escenario de intrusión: analizar el ataque, “capturar” el ataque, enmascararlo, maximizar la

confidencialidad, maximizar la integridad de los datos, minimizar el coste, recuperar los servicios o

sistemas de forma satisfactoria, y mantener el servicio. Ante un escenario de intrusión, el

administrador fija una meta de respuesta, para lo que el sistema genera un plan de respuesta

adecuado compuesto por una secuencia de acciones o subtareas. IDAM&IRS tiene definidas 13

posibles subtareas, que combinadas de distintas formas dan lugar a los diferentes planes de

respuesta.

La característica principal de IDAM&IRS, que lo distingue de AIRS existentes, consiste en que

además de seleccionar las acciones de respuesta más adecuadas a cada escenario de intrusión

(primitivas), toma decisiones también en cuanto al momento de ejecución de cada subtarea incluida

en HTN. La arquitectura de IDAM&IRS se muestra en Figura 2.13.


39

Figura 2.13 Arquitectura de IDAM&IRS [Mu10a].

Es una arquitectura distribuida y la función principal de sus componentes es la siguiente:

Communication Module: componente encargado de recibir alertas desde las diferentes

fuentes de detección de la red, y enviar instrucciones de respuesta a los activos protegidos,

una vez inferidas las acciones de respuesta.

Alert Filter: filtra las alertas procedentes del Communication Module en función de la

confianza en la fuente de detección. Sólo las alertas cuyo valor de confianza supere un

umbral son enviadas a Alert Verification. Los autores proponen además un método de

aprendizaje supervisado para obtener el nivel de confianza, efectivo en filtrar alertas falsas.

Alert Verification: compara la información contenida en una alerta con la información real del

host comprometido (la IP destino contenida en la alerta), con el fin de reducir alertas falsas o

irrelevantes, y proporcionar una clasificación de la relevancia de la alerta que representa la

probabilidad de éxito de los ataques.

Alert Correlation: componente encargado de agregar alertas relacionas entre sí y que se

corresponden con un mismo escenario de intrusión. Esto reduce alertas duplicadas o falsos

positivos.

Online Risk Assessment: modulo que evalúa el riesgo causado en tiempo real por cada

escenario de intrusión.

Intrusion Response Decision-making: componente que determina las acciones de respuesta a

ejecutar para un escenario de intrusión y meta de respuesta dados, y el momento en que es

recomendable ejecutar cada una de las subtareas incluidas en el plan de respuesta. Para ello

utiliza, entre otros parámetros, el riesgo calculado en la fase anterior. Además, escribe las

instrucciones de respuesta en la cola de acciones.

Console: permite al administrado gestionar y ver las alertas, gestionar IDAM&IRS y configurar

sus parámetros.

Cuando el sistema recibe una alerta procedente de cualquiera de los IDSs de la red, dicha alerta se

filtra y correla. A continuación, en caso de ser una alerta fiable y no duplicada, el administrador

selecciona una meta u objetivo a cumplir para ese escenario de intrusión, que lleva asociada una


40

estrategia o plan de respuesta (conjunto de subtareas); el administrador también fija un rango de

riesgo máximo asumible. Para cada subtarea del plan, comprueba si es el momento adecuado para

ejecutarla comparando si el riesgo de intrusión en ese momento específico es superior al fijado por el

administrador. En caso afirmativo, selecciona y ejecuta las instrucciones de respuesta o primitivas

óptimas relacionadas con la subtarea en análisis. Para realizar esta última inferencia, utiliza

parámetros como el éxito de la acción de respuesta, el impacto de la misma, su severidad o su

efectividad. En caso de que el riesgo sea asumible, no continúa ejecutando las subtareas incluidas en

el plan.


análisis de IDAM&IRS se resumen a continuación.


No se dispone de datos cuantitativos suficientes para poder hacer un análisis del tiempo de reacción,

ya que no se han encontrado tiempos de inferencia ni ejecución de las respuestas para el sistema en

estudio. Pero el mecanismo de agregación de alertas duplicadas propuesto por los autores e incluido

en IDAM&IRS, tiene un tiempo medio de detección de alertas duplicadas de entre 15 y 30 segundos

[Mu10b], lo que retrasa el tiempo de reacción del AIRS, considerando este como el tiempo desde la

detección de una intrusión hasta que el sistema ejecuta la reacción adecuada.

Proactividad

IDAM&IRS es un sistema de respuesta reactivo, y no dispone de ningún componente específico que

permita cumplir esta propiedad. Tiene la capacidad de correlar alertas de intrusión para detectar

falsos positivos o duplicados pero no responde frente a ataques antes de que se produzcan.

Adaptabilidad

Utiliza el éxito o efectividad de una respuesta para elegir la respuesta óptima (EI), pero no especifica

ningún método o algoritmo para calcular el valor de ese parámetro.


El sistema utiliza un mecanismo de selección de respuesta sensible a costes, por lo que tiene en

cuenta el coste e impacto de las respuestas en el proceso de inferencia de la acción o medida de

respuesta a ejecutar para cada subtarea incluida en el plan.


IDAM&IRS posee un módulo que permite correlar las alertas recibidas con el fin de descartar

duplicados o falsas alarmas, por lo que se podría considerar que este sistema tiene en cuenta la

semántica de las alertas, independientemente de que su origen sea una fuente de detección

diferente, y la sintaxis de las mismas sea distinta. Cuando un IDS detecta una intrusión, antes de

agregar y correlarla el sistema transforma esta alerta a un formato de datos uniforme, como por

ejemplo IDMEF (Intrusion Detection Message Exchange Format, [IDMEF]) tal como se recoge en

[Mu12].

2.3.9 Otras aproximaciones propuestas

Además de los sistemas de respuesta automática frente a intrusiones cuyo análisis se presenta en los

apartados anteriores, existen otras aproximaciones y trabajos de investigación que abordan el

problema de la reacción automática frente a ataques. Los más representativos se citan a

continuación:

En [Stakhanova07a], Stakhanova et al. proponen un IRS automático, sensible a costes,

adaptativo y preventivo. Su modelo propuesto se basa en detectar comportamientos

anómalos en los sistemas mediante la monitorización de su comportamiento en términos de

llamadas del sistema, y en responder automáticamente cuando corresponda. Para ello, utiliza


41

un mapeo entre recursos del sistema, acciones de respuesta y patrones de intrusión o

anomalía (proponen el uso de un grafo de comportamiento normal y anómalo), que debe ser

definido previamente por el administrador. Si una secuencia de llamadas del sistema coincide

con un prefijo en el grafo de comportamiento anómalo, el sistema lleva a cabo los siguientes

pasos:

Decide si reaccionar o no: si la confianza en que la intrusión es real supera un

determinado umbral el sistema ejecuta el siguiente paso. En caso contrario, espera a

que se produzcan más evidencias.

Infiere un conjunto de respuestas posibles (de entre las asociadas al patrón de

anomalía detectado) en función del coste de la respuesta, la confianza en la alerta y

el daño de la intrusión.

Selecciona la respuesta óptima del conjunto de respuestas posibles, en función de

éxito de la respuesta (SF) y del factor de riesgos (RF). El sistema infiere la respuesta

con menor efecto negativo en el funcionamiento del sistema. La efectividad de cada

respuesta se mide y actualiza para posteriores inferencias.

Toth and Kruegel [Toth02] proponen un sistema de respuesta a nivel de red que da prioridad

a las relaciones entre usuarios y recursos, desde el punto de vista de que los usuarios llevan

a cabo sus actividades utilizando los recursos disponibles. Por ese motivo, el objetivo

principal del sistema de respuesta es mantener la disponibilidad de los servicios tanto como

sea posible. Cuando un IDS detecta un ataque, el AIRS ejecuta un algoritmo de selección de

la respuesta óptima en función del daño que las respuestas causan al sistema. Para ello, el

algoritmo compara la severidad de la intrusión con el impacto de las respuestas en los

recursos de la red. Este impacto se calcula en función de la topología de red y las

dependencias entre componentes. El sistema ejecutará la respuesta con menor impacto. El

sistema propuesto por Toth and Kruegel es un sistema reactivo, no adaptativo, que utiliza un

modelo sensible a costes para la selección de la respuesta.

In [Tanachaiwiwat02] Tanachaiwiwat et al. presentan un sistema de detección y respuesta a

intrusiones cuyo objetivo es minimizar el riesgo frente a ataques de red. En función de la

eficiencia del IDS, la frecuencia de intrusión y el daño provocado por la intrusión, el sistema

selecciona una estrategia de respuesta de las 4 posibles que proponen. Cada estrategia de

respuesta incluye un conjunto de mecanismos de respuesta (bloquear IP, matar proceso,

ejecutar el antivirus, etc.) que se pueden ejecutar automáticamente o de forma manual, en

función del coste de cada uno de ellos y del riesgo calculado previamente. Este sistema

utiliza un modelo sensible a costes para la elección de la respuesta adecuada, pero no tiene

en cuenta la efectividad de las respuestas en ejecuciones anteriores. Por otra parte, es un

AIRS reactivo y no proactivo.

Jahnke et al. [Jahnke07] proponen un AIRS basado en conceptos de la teoría de grafos que

modela los efectos de los ataques en los recursos del sistema (en términos de

confidencialidad, disponibilidad e integridad) y los efectos que las acciones de respuesta

tendrían como reacción a dichos ataques. El sistema propuesto amplia y mejora la idea

propuesta por Toth and Kruegel en [Toth02]. Es decir, para cada dimensión de seguridad, el

grafo de dependencias refleja la interdependencia entre los recursos del sistema (servicios y

usuarios). Este grafo se utiliza para cuantificar los efectos de las acciones de respuesta en

cuanto a éxito, coste de aplicación, impacto en los recursos y duración de la respuesta.

Cuando se detecta un ataque, un algoritmo calcula el efecto directo o indirecto en todos los

recursos, y en función del impacto de la intrusión y de los parámetros de las acciones de

respuesta cuantificados previamente, el sistema seleccionará una respuesta óptima para

mitigar la intrusión.


42

2.3.10 Análisis general de las soluciones

En esta sección se ha presentado el concepto de sistema de respuesta automática frente a

intrusiones y se han analizado los distintos AIRSs existentes, con el objetivo de plantear una serie de

conceptos e ideas que se utilizarán a lo largo de este trabajo:

Objetivo de un AIRS y características que debería poseer: rapidez de reacción, proactividad,

adaptabilidad, consideración del impacto y éxito de las respuestas, y coherencia semántica.

Componentes típicos de una arquitectura de AIRS: taxonomía de respuestas, métricas de

respuesta, agente de inferencia de la respuesta óptima y fuentes de detección (ya sean

externas o propias).

Importancia de las métricas utilizadas por el sistema en la elección de la respuesta óptima, en

especial en aquellos que implementan alguna variante de consideración de costes.

Cada uno de los AIRSs estudiados posee una arquitectura, un mecanismo de inferencia de la

respuesta(s) óptima(s) y unas métricas diferentes, aunque el objetivo a alcanzar sea un objetivo

común: mitigar el ataque o reducir su impacto. En función de su arquitectura y principio de

funcionamiento cumplen en mayor o menor medida las características deseables, pero ninguno

aborda todas a la vez, como se observa en la siguiente tabla:

Tabla 2.3 Clasificación de los AIRSs existentes.

Rapidez

de

reacción

Adaptativo Proactivo

Consideración

del coste de

las respuestas

Modelo de

evaluación

del coste

Coherencia

semántica

CSM -- NO, salvo

excepción NO NO Estático NO

EMERALD -- NO NO NO Estático NO

AAIRS -- SI NO NO Ev. Estática NO

SARA Lento NO NO -- Estático NO

Network IRS -- NO NO SI Ev. Dinámica NO

Tanachaiwiwat’

s IRS -- NO NO SI Estático NO

ADEPTS SI SI SI SI Estático NO

MAIRF -- SI SI NO Estático NO

FAIR -- NO NO SI Ev. Estática NO

Stakhanova’s

IRS -- SI SI SI Ev. Estática NO

Jahnke -- NO NO SI Ev. Dinámica NO

IDAM&IRS Lento NO NO SI Ev. Estática SI

Este análisis ayuda a comprender más adelante la propuesta del uso de ontologías y lenguajes de

representación del conocimiento para el diseño, desarrollo e implementación de la arquitectura

propuesta.

2.4 Métricas de respuesta a intrusiones

En el proceso de respuesta frente a una intrusión influyen diferentes parámetros susceptibles de

medida, lo que hace necesario la definición de varias métricas cuyo objetivo es dar valor a cada uno

de estos parámetros. La elección de la respuesta óptima depende de la calidad y precisión en la

definición de estas métricas, lo que lo convierte en una parte importante del proceso de especificación

e implementación del AIRS. El objetivo de este apartado es por un lado, especificar el conjunto de

parámetros que influyen en el proceso de inferencia de la respuesta óptima y que por tanto es


43

necesario medir, y por otro, analizar las métricas de seguridad utilizadas en los AIRSs y en otro tipo

de sistemas que permiten medir dichos parámetros.

En este punto de la memoria, se cree conveniente definir el concepto de métrica. Una métrica podría

definirse como una forma de medir y una escala, definidas para realizar mediciones de uno o varios

atributos. Siempre que se hable de métricas debe hacerse un apunte en la diferencia que existe entre

medir, métrica y medida, conceptos íntimamente relacionados, que se usan en ocasiones de manera

indiscriminada. Medir es el proceso de comparar la cantidad desconocida que queremos determinar y

una cantidad conocida de la misma magnitud, que elegimos como unidad de referencia; es el proceso

por el cual se asignan números o símbolos a atributos o entidades en el mundo real tal como son

descritos de acuerdo a reglas claramente definidas. Al resultado de ese proceso comparativo lo

llamamos medida. La medida es objetiva y proporciona una indicación cuantitativa. Una métrica se

deriva de la comparación de dos o más medidas tomadas en el tiempo con un predeterminado valor

de referencia.

El IEEE “Standard Glosary of Software Engering Terms” define métrica como “una medida cuantitativa

del grado en que un sistema, componente o proceso posee un atributo dado.

Existen gran cantidad de métricas relacionadas con los sistemas informáticos, las tecnologías de la

información y las telecomunicaciones:

Métricas de complejidad o calidad del SW: conjunto de métricas destinada a conocer o

estimar el tamaño u otra característica de un programa o sistema.

Métricas de seguridad genéricas: conjunto de herramientas diseñadas para facilitar la toma

de decisiones y mejorar resultados mediante la recogida, análisis y elaboración de

información sobre datos relevantes relacionados con los procesos de seguridad y sus

resultados. Estas métricas permiten cumplir las metas y objetivos de una organización, en lo

referente a protección y seguridad, mejorando las prácticas de seguridad existentes y

contribuyendo a la integración de la seguridad de la información dentro del proceso de

negocio. Las métricas de seguridad se centran en obtener datos que pongan de manifiesto o

indiquen en qué medida se cumplen los objetivos de seguridad establecidos en la

organización, qué eficacia tienen las herramientas de seguridad instaladas, etc.

Métricas de seguridad específicas: conjunto de métricas que se encargan de medir y evaluar

parámetros concretos relacionados con la seguridad, como tasa de falsos positivos de un IDS

concreto.

Las métricas a las que se hace referencia en esta memoria se corresponden con el último tipo de

métricas, métricas de seguridad específicas.

2.4.1 Parámetros que influyen en el proceso de inferencia de la

respuesta óptima

Como se ha indicado previamente, uno de los objetivos de este apartado es especificar los

parámetros a tener en cuenta en la elección de la respuesta óptima frente a una intrusión. Del análisis

del estado del arte realizado en el apartado anterior, se extraen los siguientes parámetros:

- Confianza en el IDS: parámetro que representa la tasa de alertas reales detectadas por el

IDS. Asociados a cada IDS hay una tasa de falsos positivos (detectar como anómalo algo que

no lo es) y una tasa de falsos negativos (se considera normal comportamiento anómalo y no

se genera informe de intrusión). Ambos fallos en la detección de ataques provocan un

impacto en la red o los sistemas que es importante tener en cuenta a la hora de que el AIRS

seleccione la respuesta óptima. Un IDS con una tasa de falsas alarmas baja es más confiable

que otro con la tasa más alta.


44

- Fiabilidad del informe de intrusión: parámetro que representa el grado de confianza que se

tiene en que el tipo de intrusión detectado por el IDS está realmente ocurriendo. Este

parámetro es importante puesto que el sistema de respuesta tiene en cuenta el tipo de ataque

frente al que es necesario responder en el proceso de inferencia de la respuesta óptima,

como se verá a lo largo de la memoria. Por ello, la respuesta desplegada depende en gran

medida del tipo de ataque, por lo que se hace necesario comprobar su veracidad.

- Continuidad de un ataque: parámetro que clasifica una alerta de intrusión como parte de un

ataque ya existente o como un ataque nuevo. Un AIRS puede recibir alertas de intrusión

procedentes de la misma o distinta fuente en instantes muy cercanos en el tiempo, situación

ante la que es muy útil que el AIRS pueda determinar si la última alerta de intrusión recibida

se refiere a un ataque que es continuación de otro existente ya detectado y tratado, o si por el

contrario, la alerta está relacionada con un ataque diferente, y por tanto hay que procesar y

ejecutar el proceso de inferencia de la respuesta óptima.

- Importancia de los activos de la red que pueden ser comprometidos: parámetro que

representa cuánto de crítico es un activo para el correcto funcionamiento de una institución,

en términos del impacto que causaría su pérdida total o parcial en la arquitectura de red. La

elección de la respuesta óptima frente a una intrusión está muy ligada a dicho nivel de

importancia y a cómo la intrusión afecta a su disponibilidad, integridad, confidencialidad y

autenticidad. Así pues es muy importante hacer una valoración de activos como paso previo a

la elección de la respuesta, ya que el AIRS responderá de una forma más severa ante un

ataque contra activos críticos que ante un ataque cuyo objetivo sea un activo de poca

importancia.

- Impacto y severidad de la intrusión: el impacto es el parámetro que representa el daño

potencial que causa una amenaza en una red o sistema, que hay que tener en cuenta a la

hora de seleccionar la respuesta óptima. Por su parte, la severidad es el grado de amenaza

asociada a cada tipo específico de intrusión.

- Coste de una acción de respuesta: parámetro que representa el coste asociado al despliegue

y ejecución de una acción de respuesta. Como se indica en este capítulo, uno de los

requisitos deseables en un AIRS es que utilice un mecanismo sensible a costes para la

elección de la respuesta óptima, por lo que en el proceso de inferencia se debe tener en

cuenta, entre otros factores, el coste asociado a la ejecución de la respuesta.

- Impacto de una acción de respuesta: parámetro que indica el daño o efecto negativo que

causa el despliegue de una acción de respuesta en los activos del sistema. El impacto de una

acción de respuesta es uno de los factores que influyen en el coste total de la misma, por lo

que es un parámetro crítico en el proceso de inferencia de la respuesta óptima de un AIRS

sensible a costes.

- Eficacia de una acción de respuesta: parámetro que representa el éxito previo de una acción

de respuesta, factor relevante para satisfacer los requisitos de adaptabilidad y consideración

del impacto de la respuesta. La importancia de este parámetro radica en que el AIRS tendrá

en cuenta los aciertos o fallos de la respuesta inferida en ejecuciones anteriores, lo que le

permite corregir posibles errores y aumentar su efectividad.

Además, de los parámetros especificados se cree conveniente añadir el siguiente:

- Nivel de actividad de la red: cualquier comportamiento anómalo causado por una intrusión

produce una variación en los indicadores de actividad habitual de la red y los sistemas

presentes en la misma. Por ello, se puede utilizar esta variación como un indicio de que se

está produciendo un ataque contra uno de los activos de la red. Este parámetro toma especial

relevancia en el caso de que la confianza en los IDSs sea baja.


45

Estos parámetros son susceptibles de medida, lo que hace necesario la definición y especificación de

métricas que permitan darles valor. En el siguiente apartado se presenta un análisis de las métricas

utilizadas por los AIRSs estudiados, prestando especial atención a aquellas que permiten medir

alguno de los citados parámetros, así como un análisis de métricas especificadas para su uso en

áreas distintas a la respuesta frente a intrusiones, pero que pueden ser utilizados para medir los

parámetros de interés para este trabajo de investigación.

2.4.2 Métricas utilizadas en los AIRSs

Los AIRS estudiados y evaluados en la sección anterior utilizan una serie de métricas relacionadas

con la detección y/o la respuesta de intrusiones, que contribuyen al correcto funcionamiento del

sistema. Estas métricas se enumeran a continuación.

CSM 2.4.2.1

CSM utiliza una métrica en el proceso de inferencia de la respuesta: métrica de nivel de sospecha.

Métrica de nivel de sospecha

La respuesta es elegida en función del nivel de sospecha asignado al usuario por el IDS. Para

calcular el nivel de sospecha (LOS) se pueden usar dos tipos de métodos:

Analizar el perfil de los usuarios: las métricas usadas para medir parámetros usados en los

perfiles son:

Número de veces que un comando específico se usa en una sesión.

Cantidad de un recurso específico usado.

Tiempo entre eventos relacionados.

Sistemas expertos o aproximaciones basadas en reglas para buscar actividades conocidas

que sean indicativo de comportamiento intrusivo.

Una vez que el IDS ha calculado el LOS para cada usuario del sistema, se compara este parámetro

con un umbral, y en función de dicha comparación se genera un mensaje de alerta, que recibe el

sistema de respuesta incorporado en el CSM, que se encargará de seleccionar y desplegar la

respuesta. Por tanto:

(2.7)

En función del valor de la métrica de nivel de sospecha, el DCP selecciona uno de los ocho conjuntos

de respuestas, cada uno de los cuales contiene de uno a catorce acciones de respuesta diferentes.

De este conjunto, asociado a un único par tipo de ataque-nivel de sospecha, elige la acción de

respuesta que estima más adecuada. Una vez que el intruso ha abandonado el sistema defendido,

las acciones de respuesta cesarán y el nivel de sospecha del intruso es vuelto a poner a cero.

Existe una relación: LOS – Conjunto de respuestas.

EMERALD 2.4.2.2

Este AIRS utiliza dos métricas a la hora de obtener la mejor respuesta: métrica de umbral y métrica

de severidad o gravedad.

Métrica de umbral

Métrica que representa la confianza que el sistema tiene en que la intrusión detectada por los IDSs es

real (es un verdadero positivo), cuyo objetivo es evaluar las evidencias de la existencia de la intrusión.

Tanto los valores como los resultados son medidos por el motor (componente principal de la


46

arquitectura del sistema), y cuanto mayor sea el valor obtenido, mayor evidencia existe que el sistema

está bajo ataque y más severas son las acciones de respuestas desplegadas.

Métrica de severidad o gravedad

Es una medida o tasa del posible efecto negativo de las respuestas sobre el funcionamiento normal

de las operaciones de la red. Las respuestas que tengan una tasa de gravedad alta solo son elegidas

como estrategia de respuesta frente al ataque en el caso de que la confianza depositada en que un

ataque es real sea bastante alta, asumiendo que respuestas de menor gravedad no están presentes

o no han tenido efecto.

Para la definición de la métrica se utiliza el subconjunto de secuencias de ataques asociadas

definidas dentro del objeto recurso.

AAIRS 2.4.2.3

En la elección de la respuesta óptima tiene en cuenta cinco factores:

Tasa de falsos positivos de cada IDS (métrica de confianza en el IDS).

Tipo de ataque al que es necesario responder (métrica de identificación de ataques).

Resultados de las respuestas lanzadas: tasa de éxito de los planes de respuesta (métrica de

éxito de la respuesta).

Grado de sospecha de que la intrusión es real (métrica de grado de sospecha).

Tipo de atacante (métrica de tipo de atacante).

Métricas de confianza en el IDS

Usa la tasa de falsos positivos y falsos negativos del IDS para determinar si el sistema está realmente

bajo ataque. Es utilizada por el componente Interface de la arquitectura del sistema y viene definida

por la siguiente expresión:

(2.8)

Proporciona una medida de tasa de falsas alarmas del IDS. Un IDS con una tasa de falsas alarmas

baja es más confiable que otro con la tasa más alta; la respuesta desplegada depende de esta

confianza. El número de falsos positivos se genera a través de un bucle de realimentación entre el

Interface Agent y el System Admin Tool. Después de cada incidente el administrador del sistema

indica si el incidente fue un ataque real o una falsa alarma. Esto se traduce en una actualización de la

métrica de confianza. El administrador del sistema debe ajustar la métrica de confianza del IDS

después de examinar cada ataque y determinar si éste era una falsa alarma o un ataque real.

AAIRS usa la métrica de confianza como un componente para construir el plan de respuesta.

Métrica de identificación de ataques

El componente Master Analysis clasifica los informes de intrusión recibidos en función de si forma

parte de un ataque antiguo o se trata de un nuevo ataque. Para ello, este componente almacena un

histórico de eventos para cada Analysis Agent, y usa tres métricas internas para determinar si el

informe recibido es continuación de un evento almacenado en el histórico o es parte de un nuevo

ataque:

- Métrica de tiempo: evalúa la cantidad de tiempo transcurrido entre el último informe de

intrusión recibido en cada Analysis Agent y el informe actual. La definición de la métrica es la

siguiente:


47

{

( ) ( ) ( )

(2.9)

Siendo,

TLRIR: momento de detección del último informe de intrusión recibido.

TCIR: momento de detección del informe de intrusión actual.

- Métrica de identificador de sesión: comprueba la dirección IP y el nombre de usuario para

determinar si los parámetros de la sesión correspondiente al ataque detectado coinciden con

los de alguna sesión de un ataque antiguo. Esta métrica es una combinación de las métricas

de dirección IP y nombre de usuario.

{

(2.10)

{

(2.11)

La tabla de decisión para la métrica de identificador de sesión es la siguiente:

Tabla 2.4 Métrica de identificador de sesión. AAIRS [Carver01b].

Dirección IP Usuario Identificador de sesión

High High High

High Low Medium

Medium High High

Medium Low Medium

Low High Medium

Low Low Low

- Métrica de tipo de ataque: métrica que evalúa el proceso de iniciación del ataque, y

devuelve high si el proceso del ataque es el mismo en los dos informes de intrusión o low si

no lo es.

Haciendo uso de las tres métricas definidas previamente el Master Analysis clasifica el ataque como

parte de un antiguo ataque o como nuevo ataque. La tabla de decisión usada se muestra a

continuación:

Tabla 2.5 Tabla de decisión. Métrica de identificación de ataques. AAIRS [Carver01b].

Tiempo Identificador

de sesión Tipo de ataque

Resultado de la

métrica

Short High High Mismo ataque

Short High Low Mismo ataque

Short Medium High Mismo ataque

Short Medium Low Mismo ataque

Short Low High Mismo ataque

Short Low Low Diferente ataque

Medium High High Mismo ataque

Medium High Low Mismo ataque

Medium Medium High Mismo ataque

Medium Medium Low Mismo ataque


48

Medium Low High Mismo ataque

Medium Low Low Diferente ataque

Long High High Mismo ataque

Long High Low Diferente ataque

Long Medium High Mismo ataque

Long Medium Low Diferente ataque

Long Low High Diferente ataque

Long Low Low Diferente ataque

Métrica de éxito de las respuestas

El éxito o fallo de una respuesta no es un parámetro fácil de medir de forma objetiva por un

administrador, por lo que es importante que el propio sistema de respuesta se adapte en tiempo real y

mida el éxito de sus respuestas una vez finalizada su ejecución.

El plan de respuesta del AAIRS se compone de plan steps, tácticas e implementación de esas

tácticas. Cada uno de estos componentes tiene un factor de éxito, que representa la tasa del número

de veces que el plan step, la táctica o la implementación han sido desplegadas con éxito con respecto

al número de veces que han sido desplegadas. El valor de este factor de éxito determina que plan,

táctica o implementación son más exitosos, y por tanto se usan con más frecuencia que los que han

tienen un factor de éxito más bajo. Para cada plan step, táctica e implementación, se calcula lo

siguiente [Carver01b]:

[ ] [( [ ] [ ]

) [ ]](2.12)

Donde,

- ResponseTaxonomyWeight, indica el peso que el agente ResponseTaxonomy asocia a cada

plan step, táctica o implementación para cada escenario específico de ataque. Es decir, en

función del tipo de ataque, tipo de atacante, grado de sospecha e impacto del ataque, el

componente ResponseTaxonomy asigna un peso a cada plan step, táctica o implementación.

Clasifica el ataque y asigna pesos a cada componente de la respuesta en función de dicha

clasificación.

- SystemResponseWeights, representa los pesos que asigna el AIRS a cada plan step, táctica

o implementación en función de su influencia en el alcance de la meta u objetivo impuesta por

el AIRS para cada escenario de intrusión.

- factorExito, representa la tasa del número de veces que el plan step, táctica o implementación

ha sido ejecutada con éxito respecto al número total de veces que ha sido desplegada.

Esta expresión genera un número entre 0 y 1 para cada plan step, táctica e implementación. Por otra

parte se asigna un número aleatorio a cada componente, y si dicho número es más bajo que el

TestPlan[i] del plan step, táctica o implementación evaluada, éste se considera viable para esa

situación de intrusión.

La métrica utilizada por AAIRS para evaluar el factor de éxito de cada plan steps y de cada táctica es

la siguiente:

(2.13)


49

Métricas de grado de sospecha

Métrica que proporciona el nivel de sospecha que se tiene de que un incidente es real. Esta métrica

es utilizada por Response Taxonomy Agent para clasificar un incidente, para a continuación generar

un plan de respuesta específico para él. Esta métrica a su vez se divide en dos:

Métrica de número de incidentes (Incident count metric): número de incidentes recibido

por un Analysis Agent específico.

Métrica de tipo de incidente (incident type count metric): mide el número de tipos de

ataque distintos contra un mismo sistema. Cuánto más tipos de ataque haya, mayor será el

grado de sospecha.

Ambas métricas proporcionan un número entre 0 y 1 y la expresión utilizada por AAIRS es la misma

en ambos casos:

(

) (2.14)

Donde, count se corresponde con el número de incidentes recibido por el Analysis Agent o el número

de tipos de ataque distintos, según se aplique una métrica u otra.

La métrica de grado de sospecha es una combinación de las dos métricas anteriores y su resultado

es un número entre 0 y 1. Si el resultado de cualquiera de las dos métricas es 1, el resultado de la

métrica de grado de sospecha será 1. En otro caso, la ecuación utilizada por AAIRS para obtener el

grado de sospecha es la siguiente:

( )/ (2.15)

Donde, incidentcount es el resultado de la métrica de número de incidentes y typecount es el

resultado de la métrica de tipo de incidente. Sobre la función confidence los autores no proporcionan

ninguna expresión.

Métrica de tipo de atacante

Mediante esta métrica se clasifica el atacante como manual o automático por una parte, y como

novato o experto por otra. Al igual que la métrica anterior, es utilizada por Response Taxonomy Agent

para clasificar un incidente, y así generar un plan de respuesta adecuado. Para ello utiliza los

siguientes parámetros y criterios:

- Número de ataques: si el número de ataques supera los 6 incidentes por minuto, el atacante

se clasifica como automático. En caso contrario, estamos ante un atacante manual.

- Patrones de ataque. Los autores no proporcionan información acerca del algoritmo utilizado

para clasificar los patrones de ataque.

- Diversidad en los ataques realizados y complejidad de los mismos: en función del número de

ataques diferentes y de su nivel de complejidad, el sistema clasifica al atacante como novato

o experto.

De las 5 métricas especificadas, las tres primeras son las más importantes para el proceso de

selección de la respuesta óptima de AAIRS.

SARA 2.4.2.4

Survivable Autonomic Response Architecture, SARA, establece que en el proceso de respuesta frente

a una intrusión detectada, un sistema de selección de respuesta debe tener en cuenta la manera en

la que los recursos se verán afectados por la respuesta, y cuál será el impacto de la misma. No

obstante, no se han encontrado datos del conjunto de métricas utilizadas por SARA para la elección

de la respuesta.


50

ADEPTS 2.4.2.5

Como se indicó en la sección anterior, la base del funcionamiento de ADEPTS [Foo05] es un grafo de

nodos que representan objetivos de ataques creado a partir de las metas o submetas de las

intrusiones. Este grafo permite observar y predecir la propagación de la intrusión en el sistema,

facilitando así la elección de las respuestas adecuadas para evitar la propagación de la intrusión

hacia nodos situados en niveles superiores del grafo.

Para la construcción del grafo se utilizan las vulnerabilidades (4 parámetros) y una descripción de los

servicios del sistema y sus interconexiones. Una vez construido el grafo inicial, cada vez que se

recibe un informe de alerta de intrusión, se mapea a los nodos en el I-GRAPH correspondientes y se

comprueba a qué nodos afecta la intrusión detectada. En ese momento, el sistema estará en

condiciones para seleccionar la(s) respuesta(s) adecuada(s) mediante la ejecución del algoritmo.

Para la elección de la respuesta ADEPTS tiene en cuenta los siguientes parámetros:

- Efectividad de la respuesta asociada a un ataque concreto en ejecuciones pasadas.

- Impacto de la respuesta para usuarios legítimos.

- Probabilidad de veracidad de la intrusión (que no sea un falso positivo).

- Degradación de los servicios del sistema.

- Nivel de política configurado: aggressive, moderate y conservative.

Estos parámetros son la base para la especificación de las métricas de seguridad incluidas en

ADEPTS.

Métrica de probabilidad de que un nodo sea alcanzado

Cuando se detecta una intrusión, el sistema la mapea a los nodos correspondientes. A continuación y

en función de la estructura del grafo de nodos, el sistema debe determinar qué nodos del I-GRAPH se

verán afectados por la intrusión detectada y con cuánta probabilidad. Para ello el sistema utiliza el

algoritmo denominado CCI Computation algorithm.

La métrica se define utilizando el parámetro CCI, que representa la medida de la probabilidad de que

un nodo ha sido alcanzado. El algoritmo utilizado para su cálculo es el siguiente [Foo05]:

{

( )

( ( ) (2.16)

(2.17)

El valor de certeza_alerta, depende de la política configurada, y la función f es la media aritmética en

cualquier caso.

Métrica de evaluación del camino más probable de propagación de la

intrusión

Una vez que se ha determinado el CCI para cada nodo del I-GRAPH, el sistema determina el camino

más probable de propagación del ataque en el sistema para desplegar las respuestas apropiadas en

estas localizaciones. Para ello ejecuta el algoritmo Response Set Computation.

La métrica hace uso de dos parámetros para determinar el camino:


51

- CCI: probabilidad de alcance de los nodos.

- τ: umbral por nodo.

En función de los dos parámetros anteriores, el algoritmo etiqueta los nodos con los valores, SC, WC,

VWC, o NC, tal como se muestra a continuación:

- Nodo “Strong Candidate” (SC) si CCI > τ.

- Nodo “Weak Candidate” (WC) si CCI ≤ τ y se puede llegar a un nodo SC solo a través de

nodos AND.

- Nodo “Very Weak Candidate” (VWC) si CCI ≤ τ y se puede llegar a un nodo SC a través de

cualquier tipo de nodo.

- Nodo “Not Candidate” (NC) en otro caso.

Una vez etiquetados los nodos y en función del nivel de política configurado, se seleccionan los

nodos etiquetados y se añaden al conjunto de respuestas, que contiene los nodos que requieren de

una respuesta inmediata.

Métrica de selección de la respuesta óptima

En principio se seleccionan un conjunto de respuestas candidatas para cada nodo en función del

valor del código de operación (una respuesta se compone de un código de operación y varios

operandos). De las respuestas seleccionadas se usa un parámetro RI para elegir la más adecuada,

según la siguiente expresión [Foo05]:

(2.18)

Donde:

- EI: efectividad estimada de la respuesta al ataque concreto.

- DI: parámetro que mide cómo de perjudicial es la respuesta para los usuarios legítimos del

sistema.

La métrica establece que se selecciona la respuesta con mayor valor de RI, entre las respuestas

candidatas asociadas a un nodo. Como se observa, la métrica usa una aproximación sensible a

costes, y elige la respuesta con mayor efectividad y menos negatividad en la actividad normal del

sistema, sin tener en cuenta el daño del ataque ni el coste de la respuesta.

Métrica utilizada para evaluar el éxito de una respuesta desplegada

Si tras aplicar la respuesta a un nodo, se tiene indicios de que un nodo posterior al tratado ha sido

alcanzado, se puede deducir que la acción de respuesta ha fallado y por tanto, es necesario disminuir

su EI, haciendo uso de la siguiente expresión [Foo05]:

_

∑ _ _ (2.19)

En caso de que el TTL de la respuesta expire sin tener datos de detección de la misma intrusión o de

variaciones de ella, se aumenta el EI de la respuesta ejecutada en una cantidad fija.

Métrica de supervivencia

ADEPTS utiliza una métrica de supervivencia, denominada survivability para evaluar el propio sistema

tolerante a intrusiones como es ADEPTS.

Esta métrica se define como el conjunto de transacciones del sistema de alto nivel que pueden ser

alcanzadas en relación al conjunto de metas del sistema de alto nivel que no son violadas en el

transcurso de la intrusión [Foo05].


52

∑ ∑ (2.20)

MAIRF 2.4.2.6

MAIRF es un sistema de respuesta basado en agentes móviles, que además de proporcionar un

método de respuesta automática frente a intrusiones efectivo para usuarios de redes, permite

reconocer y conocer el dominio o parte del entorno que se tiene descuidado, así como rastrear a los

atacantes. No obstante, no se han encontrado datos del conjunto de métricas utilizadas por MAIRF

para la elección de la respuesta.

FAIR 2.4.2.7

Para la elección del conjunto de respuestas candidatas y apropiadas, FAIR utiliza varias métricas de

seguridad. Los resultados de las métricas determinarán las características “ideales” que deben tener

las acciones de respuestas, como se indicó al describir la arquitectura del sistema. A continuación, se

describen brevemente las métricas más relevantes.

Métrica de detección de alertas iguales

Esta métrica establece que dos alertas son idénticas si poseen el mismo origen, mismo sistema

objetivo, mismas cuentas de usuario y un patrón de actividad idéntico.

Métrica de eficiencia de detección

El objetivo de esta métrica es determinar el porcentaje de alarmas detectadas por el sistema que se

corresponden con intrusiones reales, con el fin de reducir la tasa de falsas alarmas (Falsos positivos)

y el porcentaje de falsos negativos. La métrica se rige por la siguiente ecuación:

∑ (2.21)

Métrica de estado de alerta

Métrica cuyo objetivo es medir el nivel de amenaza del sistema en un periodo de tiempo establecido.

Se calcula mediante la combinación de niveles de amenaza individuales asociados a los incidentes

detectados dentro de una franja de tiempo determinada. La ecuación que rige la métrica es la

siguiente [Papadaki06]:

∑

(2.22)

Donde, AS es Alert Status, OThr representa la amenaza total de cada evento y n se corresponde con

el número de eventos dentro de la franja de tiempo especificada.

Métrica de confianza en la alarma

Métrica que refleja la confianza en que una alarma detectada es realmente un ataque, en función de

la confianza de intrusión y la eficiencia de detección del sistema [Papadaki06].

(2.23)

Donde, Cintrusion es la confianza en la intrusión y DE, la eficiencia de detección del sistema.

Métrica de amenaza de un incidente

El objetivo de esta métrica es dar valor al parámetro Overall Threat (OThr), que representa el peligro

que conlleva un incidente de seguridad concreto. Para el cálculo de este valor, el sistema tiene en

cuenta:


53

- Amenaza asociada al propio incidente: severidad de la intrusión, amenaza de la intrusión.

- Amenaza asociada al recurso objetivo del ataque: tipo de recurso, impacto de la intrusión,

privilegios de usuario, recurso con información crítica, recurso crítico, confianza en la alarma,

recurso con SW vulnerable, número de sistemas afectado

- Amenaza asociada al atacante.

En función del valor que tengan cada uno de los parámetros indicados, el nivel de amenaza asociada

a un incidente incrementará o disminuirá. Es decir, en el caso del parámetro “Tipo de recurso”, si el

objetivo del ataque es un servidor interno o un componente de red, el grado de amenaza aumenta; en

cambio, si el incidente afecta a un host de usuario, el nivel de amenaza se verá disminuido.

Métrica de evaluación de la urgencia de respuesta

FAIR utiliza esta métrica para determinar cuál es el nivel de urgencia con el que es necesario

responder ante un incidente detectado. Para ello, calcula el número de alertas generadas por el

sistema para el mismo ataque o incidente. Cuánto más alto sea este número, mayor será la urgencia

de respuesta.

Métrica de eficiencia del Responder

Refleja la capacidad del componente Responder para inferir la respuesta correcta frente a las alertas

de intrusión detectadas. Cuanto más elevada es la eficiencia, más autonomía tendrá el Responder.

Su valor se calcula de acuerdo a la siguiente ecuación [Papadaki06]:

(2.24)

Donde, μPos es el número de decisiones correctas, y μTotal es el número total de inferencias.

IDAM & IRS 2.4.2.8

Como se ha indicado en la descripción de la arquitectura de IDAM & IRS, el objetivo del sistema es

establecer una estrategia de respuesta compuesta por subtareas que permita alcanzar la meta

impuesta por el administrador para un escenario de ataque particular. Una vez establecida la

estrategia, el sistema decide el orden de ejecución de cada subtarea dentro de la estrategia, el

momento en que es adecuado ejecutar cada una de ellas, y el rango de aplicación de la respuesta.

Para ello, utiliza tres métricas de seguridad y un conjunto de factores relacionados con el ataque, con

la respuesta y con el recurso atacado, como por ejemplo la confianza en la alerta, el tipo de ataque, o

la importancia del recurso atacado.

A continuación se describen en detalle cada una de las tres métricas.

Métrica de decisión de KP

IDAM & IRS incluye 13 Pi (cada Pi es una subtarea que puede formar parte de la estrategia de

respuesta utilizada por el AIRS para alcanzar la meta impuesta por el administrador para un

escenario de ataque específico) dentro de la especificación de su arquitectura. El objetivo de esta

métrica es decidir qué Pi o subtareas forman parte de la estrategia de respuesta incluida en el plan de

respuesta, así como su orden de ejecución. Al conjunto resultado se le denomina KP.

Métrica de selección del tiempo de respuesta

La métrica de selección del tiempo de respuesta determina el tiempo de ejecución de cada subtarea

Pi en KP, y el momento de finalización de la misma.

Esta métrica utiliza tres parámetros que a su vez son susceptibles de ser medidos: el RI (Risk Index),

que representa el riesgo causado por una intrusión determinada, y el RIH y RIN (Risk Index Host, y

Risk Index Network) que representan el umbral de riesgo asumible por el sistema y por la red

respectivamente.


54

RI depende de cinco parámetros relativos al ataque y al recurso atacado (Confianza en la alerta (Alert

Confidence), número total de alertas recibidas por el sistema en un slot de tiempo (Alert Amount),

número de alertas del mismo tipo recibidas por el sistema en un slot de tiempo (Alert Type Amount),

grado de vulnerabilidad el sistema atacado (Vulnerability Exposure), y severidad del ataque (Attack

Severity).

Del mismo modo, RIH y RIN son función de la meta u objetivo de la respuesta (Response Goal) y de

la importancia del recurso (Target Value).

Asumiendo que las 13 subtareas o Pi incluidas, se dividen en 4 bloques: subtareas de notificación,

alarma o recogida de evidencias y subtareas de backup (Pi, donde i є {1,2,3,4,5,6}); subtareas de

bloqueo o contraataque (Pi, donde i є {7,8,9,10,11}); subtarea de comprobación (P12); subtarea de

eliminación o parada de respuesta (P13), la métrica se rige por las siguientes expresiones [Mu10a]:

(2.25)

Donde:

- es el índice de riesgo de la intrusión k en el host H.

- indica el índice de riesgo de la intrusión k en la red LAN.

- RIHPi se corresponde con riesgo máximo asumible a nivel de host para la subtarea Pi, el

umbral de riesgo.

- RINPi es el riego máximo asumible a nivel de red para la subtarea Pi.

- TPi es el tiempo de inicio de la subtarea Pi.

- Teff se corresponde con el tiempo de efecto de una subtarea de bloqueo.

Por ejemplo, en el caso de una subtarea de bloqueo, como por ejemplo la P7, la métrica establece el

momento de inicio de la tarea el instante en el que el índice de riesgo del ataque k a nivel de host o

de red sea superior o igual al máximo riesgo asumible para dicha subtarea. De igual forma, si dicho

riesgo se encuentra por debajo del umbral de riesgo asumible, la acción de respuesta dejaría de

ejecutarse.

Métrica de selección de la acción de respuesta

Cada subtarea Pi incluida dentro del plan de respuesta, puede ser llevada a cabo por diferentes

acciones de respuesta. La elección de una u otra depende de la aplicación de esta métrica, que

selecciona aquellas acciones cuyo ratio beneficio/impacto sea superior, siempre que se encuentren

dentro de la ventana de efectividad permitida por el sistema, como se explica a continuación.

La métrica de selección de la acción de respuesta utiliza dos características de la respuesta que a su

vez son susceptibles de ser medidas: el EI (Effective Index), que representa el efecto positivo o

efectividad de la acción de respuesta, y el DI (Disruptive Index) que indica su impacto negativo.

Ambos dependen de factores asociados a la propia respuesta (como por ejemplo, impacto de

respuesta, efectividad, intensidad de la respuesta o meta de la respuesta) y asociados con el ataque

(tipo de ataque, severidad del ataque, etc.).

Previo a la aplicación de la métrica el sistema fija una efectividad máxima y mínima, representadas

por EImax e EImin, respectivamente. Las medidas de respuesta cuya efectividad no se encuentre dentro


55

de esta ventana se descartan, bien porque no son capaces de cumplir la meta de respuesta impuesta

por el administrador, o porque su impacto negativo sobre el sistema o red es demasiado alto. Del

resto de acciones que no son filtradas, y por tanto se encuentran dentro de la ventana de efectividad

del sistema para esa subtarea, el sistema selecciona aquellas con mayor ratio beneficio/impacto. La

expresión que gobierna la métrica es la siguiente:

{

} (2.26)

Donde:

- es el ratio beneficio/impacto de cada acción o medida de respuesta.

- EIrmi indica el grado de efectividad de la medida de respuesta rmi.

- DIrmi se corresponde con el impacto de la medida de respuesta rmi en el host o red.

- EImin es el umbral mínimo de efectividad permitido.

- EImax representa el máximo umbral de efectividad permitido.

El objetivo de la métrica es cumplir la segunda condición y maximizar la ecuación del ratio de

efectividad.

Stakhanova’ s IRS 2.4.2.9

Como se indicó en la sección anterior, el algoritmo de selección de la respuesta del IRS propuesto

por Stakhanova consta de tres fases. Para cada una de ellas, el sistema define y utiliza una métrica

de seguridad: métrica de probabilidad de ocurrencia, métrica de reducción de daño y métrica del

máximo beneficio al menor riesgo.

Métrica de probabilidad de ocurrencia

Métrica utilizada por el sistema en la primera fase de su algoritmo de despliegue que permite

determinar en qué momento es necesario reaccionar frente a una intrusión. Para ello, el sistema

evalúa si hay indicios suficientes para afirmar que el comportamiento anómalo detectado se

corresponde con la actividad de un atacante. Una respuesta puede ser lanzada tan pronto como una

secuencia sea reconocida como prefijo potencial de una secuencia de ataque conocida, aumentando

el riesgo de cometer falsos positivos; o puede lanzarse después de la confirmación de la intrusión,

aumentando el daño provocado en el sistema.

El objetivo de esta métrica es determinar el momento justo en el que se debe reaccionar, porque tan

dañino es responder antes de tiempo como una vez que la intrusión ha comprometido mi sistema. La

ecuación que rige la métrica es la siguiente [Stakhanova07a]:

(2.27)

Donde,

- probabilityThreshold es el nivel de confianza suficiente como para asegurar que un ataque

está en progreso y por tanto, una acción de respuesta debería ser lanzada. Este parámetro

se fija previamente por el administrador.

- Confidence level, indica la probabilidad de ocurrencia de una intrusión, el nivel de confianza

de que un patrón de intrusión está ocurriendo. Cuanto más tiempo pase, más indicios habrá

de que hay intrusión, y por tanto, mayor será este parámetro. A su vez, el nivel de confianza

viene determinado por la siguiente expresión:

(2.28)


56

Una respuesta “temprana” mejora la prevención pero aumenta la probabilidad de cometer errores. En

cambio, una respuesta “perezosa” favorece la selección de respuestas exactas certeras, pero

aumenta el riesgo en cuanto a que aumenta el tiempo de explotación de las vulnerabilidades.

Métrica de reducción de daño

La selección de las respuestas candidatas se basa en la evaluación del coste del daño y del coste de

la respuesta, para lo que se define la siguiente ecuación [Stakhanova07a]:

(2.29)

Donde,

responseCost (RC) representa el impacto de una acción de respuesta en el sistema.

damageCost (DC) cuantifica el impacto de la intrusión, en términos del número de recursos

que el ataque deja inutilizables. Cada patrón de ataque incluido en el sistema tiene un

damageCost asociado.

confidence level es el resultado de la métrica definida en la sección anterior, que indica la

confianza de ocurrencia del ataque.

Las respuestas que cumplen dicha condición son seleccionadas como candidatas. En el caso de que

el nivel de confianza en que se está produciendo un ataque sea del 100 %, hay que evitar seleccionar

respuestas cuyo coste para el sistema sea superior al daño causado por la intrusión.

Métrica de máximo beneficio al menor riesgo

Métrica utilizada en la última fase del algoritmo, cuyo objetivo es seleccionar la respuesta óptima.

Para ello, se tienen en cuenta dos factores:

Success Factor (SF): número de veces que una respuesta ha tenido éxito en ejecuciones

pasadas, expresado en %.

Risk Factor (RF): expresa la severidad de la respuesta, es decir el efecto de la respuesta en

los recursos y los usuarios legítimos. Representa el responseCost definido en la métrica

anterior.

La respuesta óptima debería proporcionar el máximo beneficio al menor riesgo. La estrategia de

respuesta se calcula usando la teoría de la utilidad donde el valor esperado, expected value (EV), de

la respuesta rs a la intrusión S puede ser definida con la siguiente ecuación [Stakhanova07a]:

( ) ( ( ) ) ( ( ) ( )) (2.30)

Donde, Prsucc (S) es la probabilidad de que una intrusión ocurra y Prrisk(S) = 1 – Prsucc (S).

La respuesta óptima elegida es la que mayor valor de EV posea tras aplicar la métrica definida.

Tras desplegar la respuesta, el parámetro SF se incrementa automáticamente en uno si la respuesta

bloquea a la intrusión; en caso contrario, el SF se disminuye en una unidad.

Network IRS 2.4.2.10

Los autores de Network IRS afirman que para la elección de la respuesta óptima contra una intrusión

detectada, el parámetro más importante a considerar es el daño que la respuesta inferida podría

causar en el sistema. El objetivo es prevenir una situación donde una acción de respuesta cause más

daño que el impacto causado por ataque al que se quiere responder. Para ello se precisa de un

mecanismo que compare la severidad del ataque con los efectos de un posible mecanismo de

respuesta. Con este fin, los autores definen una única métrica: métrica de mínimo impacto.


57

Métrica de mínimo impacto

Métrica cuyo objetivo es seleccionar la respuesta que menor daño o impacto suponga para los

sistemas de la red comprometida. Para calcular este daño, los autores proponen un algoritmo que

evalúa el impacto de la respuesta en los recursos de red de acuerdo con la topología de la red y las

dependencias entre los componentes. Este impacto se mide en términos del coste que supone que

los recursos afectados por la respuesta no estén disponibles. La ecuación que rige la métrica es la

siguiente [Toth02]:

( ) ∑ ( ) ( ) ( ) (2.31)

Donde,

- Penalty es una constante que refleja la importancia del recurso atacado.

- cr(r), número real del 0 al 1 que indica la reducción de la capacidad de un recurso para llevar

a cabo su trabajo debido al impacto de la respuesta. Si este parámetro toma un valor de 0

significa que la ejecución de una respuesta no afecta al servicio que proporciona dicho

recurso. Para el cálculo de este parámetro se tienen en cuenta las dependencias existentes

entre los recursos.

- p(r), o penalty cost, representa el coste que supone que el recurso r no esté disponible o vea

reducida su disponibilidad debido a la ejecución de una respuesta.

- n, es el número total de recursos de la organización.

- P(R)overall es la suma total del coste que supone la ejecución de una respuesta R calculada

como el daño que causa en el funcionamiento habitual de todos los recursos de la

organización.

Se calcula el daño total en el sistema para todas las acciones de respuesta y mediante la aplicación

de la métrica se selecciona la acción con el efecto negativo global más bajo. El objetivo es minimizar

la ecuación anterior.

Tanachaiwiwat’s IRS 2.4.2.11

RADAR, el sistema propuesto en [Tanachaiwiwat02], tiene 3 bloques bien diferenciados: un IDS, un

RAS (Risk Assessment System) y un IRS. En cada uno de ellos, se utilizan diferentes métricas para

cumplir su objetivo. Este apartado define brevemente las métricas utilizadas por RADAR, sin entrar en

detalles del funcionamiento de cada uno de los bloques y cómo las métricas se usan en el proceso de

detección, evaluación del riesgo o selección de la respuesta.

Métricas de rendimiento del IDS

Para medir el rendimiento del IDS, RADAR utiliza 5 métricas: detection hit rate, detection miss rate,

alarm confidence, false-alarm rate y IDS efficiency. Todas ellas se basan en una matriz de alarma

definida en [Tanachaiwiwat02], generada por el IDS después de monitorizar la red durante un periodo

fijo de tiempo, y su objetivo es calcular la eficiencia del IDS.

La métrica que mide la eficiencia del IDS utiliza los resultados obtenidos de tres de las otras cuatro

métricas, y su ecuación es la siguiente [Tanachaiwiwat02]:

(2.32)

Donde,

- Q es el resultado de la métrica que mide la confianza en la alarma (Alarm confidence). Q es

un indicador de calidad que indica el porcentaje de alarmas detectadas correctamente.


58

- H indica la probabilidad de detectar un ataque de forma correcta. Es el resultado de la métrica

Detection Hit Rate.

- M, representa la probabilidad de que el IDS no detecte un ataque cuando este sí se está

produciendo. Se corresponde con la tasa de falsos negativos, y su resultado viene

determinado por la ecuación de la métrica Detection Miss Rate.

Métricas de rendimiento del RAS

Para la selección de la estrategia de respuesta, además de la eficiencia del IDS, el sistema tiene en

cuenta la relación coste-efectividad de cada uno de los mecanismos de respuesta, así como el nivel

de riesgo del sistema ante determinados ataques. RAS es el componente encargado de evaluar este

nivel de riesgo en función del daño potencial causado por la intrusión, para después analizar y

evaluar el coste y eficiencia asociados a las medidas de respuesta, útiles para reducir el riesgo al

mínimo nivel. Una vez ejecutados los mecanismos de respuesta seleccionados, RAS calcula el riesgo

residual que determina si la respuesta ha tenido el efecto deseado en el sistema o no, y la eficiencia

del IRS.

Son de especial interés las tres métricas que miden el riesgo máximo del sistema (riesgo antes de

aplicar ninguna acción de respuesta), riesgo residual (nivel de riesgo que permanece tras aplicar los

mecanismos de respuesta adecuados) y la eficiencia del IRS.

El riesgo máximo viene determinado por la siguiente expresión:

(2.33)

Donde, D es el daño total causado en el sistema en el periodo de observación, y F es la frecuencia de

ataque.

La ecuación que rige el cálculo del riesgo residual es la siguiente [Tanachaiwiwat02]:

(

) (2.34)

Donde,

- Rresidue, es el riesgo residual que permanece después de aplicar un mecanismo de respuesta

específico.

- Tave, indica el tiempo que tarda el IRS en reaccionar frente a un ataque detectado. Cuanto

más rápido sea el IRS más oportunidades habrá de suprimir la amenaza.

- I, se corresponde con el intervalo de alarmas medio, calculado como la división del periodo

total de observación entre el total de alarmas generadas por el IDS en dicho periodo.

- Dhit, indica el daño real correspondiente a los ataques detectados correctamente por el IDS.

No incluye el daño de los falsos negativos, ni falsos positivos.

- Dconfused, es el daño correspondiente a los falsos positivos. RADAR distingue entre dos tipos

de falsos positivos, aquellas alarmas generadas cuando no hay ataque, y aquellas alarmas

incorrectas, es decir, el IDS detecta que se está produciendo un ataque y genera una alarma

pero la detección es incorrecta (el tipo de intrusión es distinto) por lo que genera una alarma

que no se corresponde con el ataque real. Los falsos positivos cuando no hay ataque no

causan ningún daño.

- Dmiss, daño correspondiente a los falsos negativos.

Como se observa en la ecuación, los mecanismos de respuesta no actúan frente a los falsos

negativos ni positivos, en el primer caso porque no son detectados como actividad anómala y por

tanto el sistema no reacciona ante ellos, y en el segundo porque reacciona de forma errónea y la

respuesta no tiene ningún efecto sobre el verdadero ataque.


59

Por otra parte, la métrica encargada de medir la eficacia del IRS es la siguiente:

(

) (2.35)

Donde EIRS indica la eficiencia o calidad del IRS, Rresidue es el riesgo residual explicado previamente, y

Rmax se corresponde con el daño total causado en el sistema por diferentes ataques multiplicado por

la frecuencia de ataque.

Métricas de rendimiento del IRS

Por último, RADAR selecciona la mejor estrategia de respuesta en función de las condiciones de la

red y los resultados del análisis de riesgos llevado a cabo por RAS. El proceso de selección de

respuesta consiste en elegir una de las cuatro estrategias que proponen, como se indicó en la

sección anterior. Para ello, el IRS utiliza tres parámetros (eficiencia del IDS, frecuencia de alarma, y

nivel de riesgo máximo), y un conjunto de métricas:

(2.36)

Donde,

- EIDS es la eficiencia del IDS.

- G, es la frecuencia de alarma.

- Rmax indica el riesgo máximo calculado por RAS en el análisis.

- α, β y γ son umbrales de rendimiento fijados por el IRS o por el administrador de seguridad de

la organización.

- Estrategia D (frecuencia de alarma baja y riesgo bajo): estrategia donde ninguna respuesta se

ejecuta de forma automática. El administrador de seguridad es el responsable de ejecutar el

100% de las acciones de respuestas. El coste que implica esta estrategia es muy bajo, pero

el tiempo de respuesta es muy elevado.

- Estrategia C (frecuencia de alarma baja y riesgo alto): estrategia donde el 40% de las

acciones de respuesta disponibles en el catálogo se ejecutan de forman automática y el 60%

restante, de forma manual. Estrategia con un coste medio-bajo, y un tiempo de respuesta

aceptable.

- Estrategia B (frecuencia de alarma alta y riesgo bajo): estrategia donde el 60% de las

acciones de respuesta disponibles en el catálogo se ejecutan de forman automática y el 40%

restante, de forma manual. Estrategia con tiempo de respuesta aceptable y con un coste

medio-alto.

- Estrategia A (frecuencia de alarma alta y riesgo alto): estrategia donde la mayoría (80%) de

las acciones de respuesta disponibles se ejecutan de forma automática. Su coste es muy

elevado pero el tiempo de respuesta del sistema es mínimo, responde rápidamente. Un

escenario de aplicación de esta estrategia es cuando hay necesidad de responder a varios

ataques de forma simultánea y efectiva.


60

Jahnke’s IRS 2.4.2.12

Para la elección de la respuesta óptima este IRS utiliza el efecto o daño que causan tanto la intrusión

como las acciones de respuesta en la disponibilidad de los recursos y servicios del sistema. Para ello,

los autores proponen dos métricas de disponibilidad (una relativa a un único recurso y otra de

disponibilidad global). Además, también proponen una métrica de éxito de la respuesta y una métrica

de coste.

Métrica de disponibilidad de un recurso

Métrica cuyo objetivo es calcular la disponibilidad de un recurso tras una intrusión o tras la ejecución

de una acción de respuesta. Este parámetro indica el coste que supone que los recursos afectados

por la respuesta no estén disponibles. La ecuación que rige la métrica es la siguiente [Jahnke07]:

( ) ( ) ( ) ( ) [ ] ( ) [ ] (2.37)

( ) ∑ ( ) ( ) ( )

| ( )|

Donde,

- AI (r), es la disponibilidad intrínseca del recurso r, es decir, la disponibilidad de las funciones o

servicios propios del recurso.

- AP(r), es la disponibilidad propagada del recurso r, que expresa la disponibilidad de los

recursos de los que éste depende. Es decir, si r depende de otros recursos, y estos no están

disponibles, la disponibilidad de r se verá afectada por este hecho.

- A(s), indica la disponibilidad intrínseca de cada nodo, servicio o recurso, de los que depende

r.

- R(r), es el conjunto de nodos, servicios o recursos de los que depende r.

- w(r,s), valor entre 0 y 1 que expresa el peso o importancia de s para r.

Cuanto menor sea el valor de A (r) más impacto tiene una intrusión o acción de respuesta en el

sistema. Por lo que la hora de seleccionar una acción de respuesta el objetivo es maximizar la

métrica, es decir, las respuestas óptimas serán aquellas cuyo A (r) sea próximo a 1.

Métrica de disponibilidad total

Métrica cuyo objetivo es cuantificar la disponibilidad total de la red en términos de, la disponibilidad de

las instancias de un servicio que necesitan de forma inmediata cada uno de los usuarios implicados

en una determinada operación o misión. La ecuación que rige la métrica es la siguiente [Jahnke07]:

( ) ∑ ( ) ( )

∑ ( ) = (2.38)

Donde,

- A (G), es la disponibilidad total de las instancias de un servicio necesarias por los usuarios

implicados en una operación concreta.

- u, es un usuario concreto del conjunto total de usuarios implicados U.

- A(u), es la disponibilidad percibida por cada uno de los usuarios.

- m(u), es un valor entre 0 y 1 que representa la importancia relativa del usuario u en la misión

común.


61

Un valor próximo a 0 refleja que estamos ante un ataque con mucho impacto, puesto que la

disponibilidad de la red y de las instancias de aplicación necesarias para llevar a cabo una operación

es muy baja.

Métrica de éxito de una acción de respuesta

Métrica cuyo objetivo es calcular el éxito de una acción de respuesta, para lo que evalúa el grafo de

accesibilidad del sistema antes y después de la ejecución de la reacción y define el éxito de la misma

como la diferencia entre ambos. La ecuación propuesta es la siguiente [Jahnke07]:

( ) (

) ( ) (2.39)

Siendo, A(G’) la disponibilidad total después de aplicar la acción de respuesta frente a una intrusión, y

A(G) la disponibilidad total después de que se produzca la intrusión pero antes de aplicar la reacción.

Al igual que se evalúa la disponibilidad, se definen métricas equivalentes para evaluar la variación de

la integridad y la confidencialidad.

Métrica de esfuerzo de una acción de respuesta

Métrica cuyo objetivo es medir el esfuerzo necesario para implementar la acción, como el número de

recursos (instancias de servicio) normalizado que es necesario modificar para implementar la

reacción. La ecuación propuesta es la siguiente [Jahnke07]:

( )

| | (2.40)

El objetivo es que el valor resultante de la ecuación sea lo más pequeño posible.

2.4.3 Otras métricas propuestas

Además de las métricas que utilizan los AIRSs analizadas, existen otras aproximaciones y trabajos de

investigación que definen, especifican o proponen métricas de seguridad específicas. A continuación

se citan aquellos trabajos relacionados con la definición de métricas relacionadas con el proceso de

elección de la respuesta óptima frente a una intrusión.

Métricas de impacto de una intrusión 2.4.3.1

El impacto de una intrusión se define como el daño potencial que causa una amenaza en un sistema.

Este daño puede ser expresado en términos cuantitativos o cualitativos. Además de las métricas de

impacto de intrusión de los AIRSs analizadas, existen otras ecuaciones, algoritmos o metodologías

propuestas con el mismo fin.

Evaluación del impacto de una intrusión mediante POMDP (Partially

Observable Markov Decision Process)

Zonghua Zhang, Xiaodong Lin and Pin Ho [Zhang07] evalúan la seguridad de un sistema en función

del impacto de la intrusión en el mismo y del efecto negativo que tienen las acciones de respuestas

en la organización. El objetivo de su investigación es medir el impacto de la intrusión y el coste total

de las acciones de respuesta para llevar a cabo una defensa racional, es decir, no ejecutar aquellas

respuestas que supongan un gran coste para la organización y cuyos beneficios sean bajos. Se trata

de maximizar la relación coste-beneficio de las respuestas.

Para ello, proponen el uso de procesos de decisión de Markov (POMDP- Partially Observable Markov

Decision Process) y teorema de Bayes. La base de la aproximación propuesta son los POMDP

(Partially Observable Markov Decisión Process), que permiten integrar la detección de intrusiones

llevada a cabo por los IDSs, la tolerancia del sistema y las respuestas. Usa una aproximación basada

en estados caracterizando en términos de impactos de intrusión las transiciones de estado


62

provocadas por un ataque. En función del valor de los impactos asociados a cada cambio de estado

se elegirá una respuesta u otra.

La métrica que cuantifica el impacto que causa (o podría causar) una intrusión en un sistema, es la

siguiente [Zhang07]:

(2.41)

Donde,

- Ds es la importancia de los servicios o componentes del sistema.

- Da es el grado de amenaza asociado a una intrusión.

Así, el impacto de una intrusión en el sistema puede ser cuantificado indirectamente sumando el

coste del daño individual de cada activo (calculado utilizando la expresión anterior) de todos los

activos afectados.

MAGERIT: evaluación del impacto de una intrusión como parte del análisis de

riesgos

MAGERIT (Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información) es una

metodología que implementa el proceso de gestión de riesgos dentro de un marco de trabajo para

tomar decisiones en base a los riesgos derivados del uso de tecnologías de la información.

Según MAGERIT, en el análisis y gestión de riesgos intervienen seis elementos principales: Activos,

Amenazas, Vulnerabilidades, Impactos, Riesgo y Salvaguardas. Con el fin de poder identificar estos

elementos en cada dominio y realizar un buen análisis de riesgos, es imprescindible identificar y

valorar los aspectos de la seguridad de los activos, conocer las vulnerabilidades de cada uno de ellos

(posibilidad de ataque de cada Amenaza) y valorar el impacto en caso de que se produzca un ataque

sobre cada uno de los activos.

Este apartado está relacionado con métricas para medir el impacto de una intrusión, por lo que sólo

tendremos en cuenta este aspecto de MAGERIT.

MAGERIT establece que conociendo el valor de los activos y la degradación que causan las

amenazas es directo derivar el impacto que estas tendrían sobre el sistema. La única consideración

que es necesario hacer es la forma en la que la metodología tiene en cuenta las dependencias entre

activos. En base a esto, MAGERIT especifica dos tipos de impacto:

- Impacto acumulado: impacto que se calcula para cada activo, por cada amenaza y en cada

dimensión de valoración, en función de su valor acumulado (su valor propio más el

acumulado de los activos que dependen de él) y las amenazas a las que está expuesto el

activo. Este tipo de impacto es tanto mayor cuanto mayor es el valor propio o acumulado de

un activo o cuanto mayor sea la degradación del activo bajo análisis.

- Impacto repercutido: impacto que se calcula para cada activo, por cada amenaza y en cada

dimensión de valoración, en función de su valor propio y las amenazas a que están expuestos

los activos de los que depende. Este tipo de impacto es tanto mayor cuanto mayor es el valor

propio de un activo, cuanto mayor sea la degradación del activo bajo análisis, o cuanto mayor

sea la dependencia del activo atacado.

MAGERIT incluye una guía de técnicas utilizadas para el cálculo de ambos tipos de impacto, entre las

que destacan:

- Análisis mediante tablas: técnica, que sin ser muy precisa, es muy utilizada para la obtención

sencilla de resultados. Consiste en analizar y separar los múltiples elementos que hay dentro

de un sistema y ordenarlos por importancia en orden descendente o ascendente. El cálculo

del impacto mediante una tabla sencilla de doble entrada se puede observar a continuación:


63

Tabla 2.6 Estimación de impacto mediante tablas. [MAGERIT-III12].

Impacto Degradación

1% 10% 100%

Valor

MA M A MA

A B M A

M MB B M

B MB MB B

MB MB MB MB

Siendo la escala utilizada: MB (Muy Bajo), B (Bajo), M (Medio), A (Alto) y MA (Muy Alto).

- Análisis algorítmico: se distinguen dos enfoques algorítmicos, uno cualitativo que busca una

valoración relativa del impacto y el riesgo que corren los activos, y un modelo cuantitativo

cuyo objetivo es determinar la cantidad exacta, cuánto más y cuánto menos.

Modelo cualitativo: se posicionan los activos en una escala de valor relativo,

definiendo arbitrariamente un valor “v0” como frontera entre valores a tener en cuenta

y despreciables. Sobre esta escala de valor se mide el impacto, entre otras cosas.

o Impacto acumulado de una amenaza sobre un activo: mide la pérdida de

valor acumulado de un activo. Sea un activo con valor acumulado “v” que se

degrada un porcentaje “d”, el valor del impacto se calcula con una función

que cumple las siguientes condiciones de contorno [MAGERIT-III12]:

(2.42)

Si el impacto queda reducido a “v0”, se considera despreciable.

o Impacto repercutido de una amenaza sobre un activo: si el activo A depende

del activo B, y B sufre una degradación “d” debido a una amenaza, eso

mismo le ocurre a A, siendo el impacto sobre A la pérdida de su valor propio.

En este caso el impacto sobre A y B sería:

Impacto sobre A = impacto (vA, d)

Impacto sobre B = impacto (vB, d)

Modelo cuantitativo: el objetivo es saber qué y cuánto hay. Este modelo no trabaja

una escala discreta de valores, sino números reales positivos.

o Impacto acumulado de una amenaza sobre un activo: mide la pérdida de

valor acumulado de un activo. Sea un activo con valor acumulado “v” que se

degrada un porcentaje “d”, el valor del impacto viene determinado por la

siguiente ecuación:

(2.43)

o Impacto repercutido de una amenaza sobre un activo: si el activo A depende

del activo B, las amenazas sobre B repercuten sobre A. Si B sufre una


64

degradación “d”, A pierde en la proporción que dependa de B. Si el activo A

tiene un valor propio de “v”, el impacto es:

( ) (2.44)

Donde, grado (AB), indica el grado de dependencia entre ambos activos.

Otras técnicas específicas incluidas en MAGERIT que podrían utilizarse para el cálculo del impacto,

una vez conocidos el valor y la degradación, son un modelo escalonado dentro del análisis

logarítmico, o la técnica de árboles de ataque. Pero la descripción detallada de todas las técnicas no

es el objetivo de esta memoria.

Métricas de evaluación del impacto de deficiencias en los 2.4.3.2

IDSs: confianza en los IDSs

Asociados a cada IDS hay una tasa de falsos positivos (detectar como anómalo algo que no lo es) y

una tasa de falsos negativos (se considera normal comportamiento anómalo y no se genera informe

de intrusión), cuyo impacto hay que tener en cuenta en el proceso de selección de la respuesta

óptima. Es importante medir con precisión dicho impacto, y analizar cómo afectan los fallos en la

detección de intrusiones en el funcionamiento normal de los activos del sistema.

Hai Wang, Peng Liu y Lunqun Li [Wang04], se centran en evaluar de forma cuantitativa el impacto

que tienen las deficiencias en la detección de intrusiones (tasa de falsas alarmas, latencia de

detección, etc.) en el rendimiento y efectividad de un sistema de bases de datos tolerantes a fallos

(ITDB, Intrusion Tolerant Database).

En su artículo definen y especifican parámetros y métricas que pueden ser de gran utilidad para medir

y evaluar la fiabilidad del informe de intrusión generado por el IDS así como la confianza en el IDS,

como se verá más adelante. Los conceptos más relevantes son:

- Tasa de falsas alarmas (FAR): indica la exactitud del IDS.

- Tasa de detección (DR): indica el porcentaje de transacciones maliciosas que el IDS puede

detectar.

- Latencia de detección (DL): indica el tiempo que el IDS necesita para detectar una intrusión.

- Damage Rate (DMR): métrica principal para representar el nivel de integridad de la base de

datos. Se define como:

( )

(2.45)

Las transacciones dañadas incluyen tanto las maliciosas como las afectadas.

- Tasa de transacciones maliciosas (MTR) : métrica que representa la intensidad de llegada de

transacciones maliciosas que se define como

( )

(2.46)

Por otra parte, Pérez et al. [Pérez13] proponen una red colaborativa de detección de intrusiones

(CIDN, Collaborative Intrusion Detection Network) capaz de construir y compartir alertas aisladas con

el fin de detectar de forma precisa y eficiente ataques distribuidos. La arquitectura propuesta se basa

en un modelo de reputación y confianza, destinado a reducir la tasa de falsos positivos y falsos

negativos asociado a IDSs maliciosos (un IDS como cualquier tipo de software puede ser

comprometido por un atacante lo que provoca un comportamiento anómalo del mismo) o mal

configurados presentes en la arquitectura de red. El modelo de reputación y confianza propuesto para


65

entornos multi-dominio permite por tanto, evaluar el comportamiento de los IDSs que generan alertas

de intrusión y aceptar o rechazar las mismas en función del nivel de confianza asociado al IDS que

genera la alerta. En [Pérez13] se incluyen detalles del algoritmo matemático propuesto por los

autores.

Métricas de elección de la respuesta óptima 2.4.3.3

El principal objetivo de un sistema de respuesta frente a intrusiones es seleccionar la respuesta más

adecuada del conjunto de respuestas posibles, teniendo en cuenta el contexto particular en cada

momento. Además de las utilizadas por los AIRSs ya definidas, existen otros trabajos de investigación

con el mismo objetivo.

Determinación de la respuesta óptima mediante POMDP (Partially Observable

Markov Decision Process)

En [Zhang07] proponen el uso de procesos de decisión de Markov y teorema de Bayes para medir el

impacto que tiene una intrusión en los recursos de una organización y el coste total de las acciones

de respuesta para llevar a cabo una defensa racional, como se ha indicado previamente. Una vez que

el IDS ha generado una alerta de intrusión, y el estimador de estados ha determinado los estados

actuales de todos los activos del sistema, y se ha evaluado el impacto correspondiente a la intrusión

detectada según la métrica definida (Ver 2.4.3.1, Ecuación 2.41), el sistema debe elegir una

respuesta racional. La aproximación propone realizar este proceso mediante un método sensible a

costes, es decir, la elección de la respuesta se basa en un balance coste-beneficio.

Para ello, en primer lugar se define el coste de mantenimiento debido a defensa y recuperación como

[Zhang07]:

(2.47)

Siendo:

- Ds, importancia de los servicios o componentes del sistema.

- Dd, la eficiencia de la medida de seguridad (respuesta).

Para determinar una respuesta racional, se debe comparar el coste de mantenimiento (Costm) y el

coste de fallo (Costf, ya definido) y alcanzar el mejor trade-off entre ellos.

Además, de los costes de mantenimiento y de fallo, tienen en cuenta el coste por falsas alarmas

(coste de penalización, Costp) y el coste de mantenimiento debido a detección incorrecta de variantes

de ataques (Cost’m). De esta forma, la suma total de costes del escenario del ataque completo puede

ser calculada como la suma de los costes independientes de los estados de los activos del sistema

bajo ataque, aplicando la siguiente ecuación (función de costes) [Zhang07]:

∑ {[ ( ) ( ) ( )]

[ ( ) ( )] [ ( ) ( )] }

(2.48)

Con ∑

Donde,

- αi, α’i Є [0,1], son pesos que indican el grado de amenaza de un ataque en curso.

- βi Є [0,1], se usa para balancear el tradeoff entre coste de fallo y coste de mantenimiento.

- γi = 1 si se selecciona el caso correspondiente. Si no γi = 0.

- So….Sn Є S’, es un conjunto de estados del sistema en el escenario del ataque.


66

- S’ es un estado mal diagnosticado como estado del sistema s.

El objetivo es minimizar el coste de la respuesta total, Costs. De esta forma puede seleccionarse la

respuesta óptima para cada situación de ataque en función de los costes implicados en el escenario

concreto.

La última fase de la aproximación propuesta consiste en la construcción del modelo basado en

POMDP. El objetivo es desarrollar un modo de incorporar las métricas de seguridad, los factores

humanos y la función de costes definida en las tres fases anteriores, con el fin de ayudar a elegir una

respuesta automática que posea un compromiso racional entre integridad del sistema, disponibilidad,

latencia e impacto de la intrusión. Para ello se usa POMDP y su estimación basada en estados.

Haciendo uso de un espacio de estados finitos S, un espacio de control U de m acciones distintas (de

respuestas), un espacio de observación Z de q observaciones distintas (informes del IDS) y un factor

de compensación (posiblemente estocástico) r(i) real para cada estado si de S; teniendo en cuenta

que en cada escenario un defensor sólo ve las observaciones zi y el factor r(i); y no tiene

conocimiento ninguno acerca del espacio de estados del sistema ni de cómo las respuestas afectan a

la evolución de estados, se generan las cadenas de Markov para transición de estados si y sj.

Utilizando la cadena de Markov definida, de los cuatro conjuntos que caracterizan estructuralmente

un modelo POMDP, y teniendo en cuenta que el objetivo es minimizar el coste total Costs, se estima

mediante el teorema de Bayes un parámetro denominado creencia de estado, que será clave para

inferir la respuesta racional.

El proceso matemático completo seguido utilizando el modelo de POMDP se encuentra en [Zhang07].

El objetivo final es minimizar la función de costes descrita previamente (que depende de varios

parámetros, entre los que se encuentra el impacto de la intrusión), utilizando cadenas de Markov y el

teorema de Bayes.

Determinación de la respuesta óptima mediante un modelo coste-beneficio

Strasburg et al. [Strasburg09], proponen un conjunto de métricas de evaluación del coste y beneficio

de una respuesta basado en los siguientes parámetros:

- Parámetros asociados con el daño de la intrusión, tales como la probabilidad y severidad de

una intrusión.

- Parámetros relacionados con el coste de la respuesta.

La respuesta óptima será aquella que minimice la siguiente ecuación:

(2.49)

Donde,

- OC, es el coste de despliegue de la respuesta.

- RSI, indica el impacto de la respuesta en el sistema.

- RG, representa el beneficio de la respuesta, que depende del número de posibles intrusiones

que la respuesta puede potencialmente mitigar y la cantidad de recursos que la respuesta

puede proteger.

Métricas de eficacia de la respuesta 2.4.3.4

La eficacia es la capacidad que tiene una respuesta desplegada para erradicar la intrusión detectada,

reducir en la mayor medida posible el daño provocado por la misma, o en caso de que sea posible,

evitar que la intrusión se produzca o cause el menor daño posible. Esta eficacia, también denominada

éxito o eficiencia, puede ser expresada en términos cuantitativos o cualitativos.

Strasburg et al. [Strasburg09], proponen una métrica para evaluar la eficacia de una acción de

respuesta, mediante una variable denominada Success Factor (SF), cuya ecuación es la siguiente:


67

( ) (2.50)

Donde,

- SFr,i indica el rendimiento de la respuesta ante una determinada intrusión i, el éxito de esta

respuesta en el pasado.

- Prsuccess(r,i), representa el porcentaje de veces que el despliegue de la respuesta r ha sido

exitoso frente a la intrusión i.

- Slevel, variable binaria que tiene valor 0 en caso de que la respuesta falle y 1 en caso de que

mitigue el ataque.

El valor de SF obtenido en cada iteración, será utilizado por el sistema como indicador para inferir la

respuesta más apropiada.

Además de las métricas de éxito incluidas en los AIRS, existen otras ecuaciones, algoritmos o

metodologías propuestas con el mismo fin, en otras áreas como puede ser la epidemiología o la

medicina, que pueden ser aplicables al campo de la respuesta frente a intrusiones informáticas. Un

ejemplo de ello es la siguiente ecuación que mide la eficacia de una acción preventiva:

(

) ( ) (2.51)

Donde,

- Io es la tasa de ataque en individuos a los que no se ha aplicado la acción preventiva.

- Ie es la tasa de ataque en individuos a los que se ha aplicado la acción preventiva.

- RR = Ie/Io

La métrica anterior se utiliza en el área de epidemiología, para medir la eficacia de una campaña de

vacunación, [UAH]. En el caso de las respuestas frente a intrusiones podríamos utilizar una métrica

equivalente a la anterior para obtener conocimiento de los resultados de aplicación de las respuestas

inferidas para responder frente a una intrusión.


Esta sección incluye un análisis del estado del arte referente a métricas de seguridad involucradas en

el proceso de respuesta frente a una intrusión. Del análisis se desprende el gran esfuerzo y trabajo

dedicado al estudio, definición y especificación de métricas, ya sean métricas utilizadas por los AIRSs

descritos en la sección anterior o métricas propuestas en otros ámbitos que se aplican a la evaluación

de los parámetros a tener en cuenta en el proceso de inferencia de la respuesta óptima, como son: la

confianza en el IDS, la fiabilidad del informe de intrusión, la continuidad de un ataque existente, la

importancia de los activos de la red, el impacto de una intrusión, el impacto, coste o beneficio de una

acción de respuesta o el nivel de actividad de la red o los sistemas.

En la Tabla 2.7 se recogen las métricas utilizadas y propuestas en los AIRSs analizados o en otros

sistemas, que son de utilidad para medir alguno de los parámetros de interés. Para cada parámetro

especificado en 2.4.1 se indica el AIRS o sistema que proporciona una métrica relacionada, así como

el nombre de la métrica. Además, como se observa en la tabla, algunos sistemas hacen uso de

ciertos parámetros, pero no indican ninguna ecuación o expresión para calcularlo, como es el caso de

la confianza en la alerta de ADEPTS.


68

Tabla 2.7 Métricas de respuesta a intrusiones. Resumen comparativo.

Confianza en

IDS

Fiabilidad de

informe de intrusión

Continuidad de

ataque

Importancia de

activos Impacto de intrusión

Coste de

respuesta Impacto de respuesta

Efectividad de

respuesta

Nivel de

actividad

CSM ------ ------ ------ ------ ------ ------ ------ ------ ------

EMERALD Métrica de

umbral ------ ------ ------ ------ ------

Métrica de severidad o gravedad

------ ------

AAIRS Métrica de

confianza en el IDS

Métrica de grado de sospecha

Métrica de identificación de

ataques ------ ------ ------ ------

Métrica de éxito de las respuestas

------

SARA ------ ------ ------ ------ ------ ------ ------ ------ ------

ADEPTS ------ alert confidence (*) ------ Disruptive Index (*) Métrica de éxito de la respuesta

desplegada ------

MAIRF ------ ------ ------ ------ ------ ------ ------ ------ ------

FAIR Métrica de

eficiencia de detección

Métrica de confianza en la alarma

Métrica de detección de

alertas iguales

Target importance (*)

Intrusion impact (*) ------ Counter-effects (*) Response

efficiency (*) ------

IDAM&IRS ------ Alert confidence (*) ------ Target value (*) Risk Index (*) ------ Disruptive index (*) Effective Index (*) ------

Stakhanova’s IRS

------ Métrica de

probabilidad de ocurrencia

------ ------ Damage cost (*) ------ Response Cost (*) Métrica de

máximo beneficio al menor riesgo

------

Network IRS ------ ------ ------ Penalty (*) ------ ------ Métrica de mínimo

impacto ------ ------

Tanachaiwiwat’s IRS

Métricas de rendimiento

del IDS ------ ------ ------ Damage (*) ------ ------ ------ ------

Jahnke ------ ------ ------ ------ Métrica de

disponibilidad de un recurso

Métrica de esfuerzo de

una respuesta

Métrica de disponibilidad de un

recurso

Métrica de éxito de una acción de

respuesta ------

OTRAS MÉTRICAS DE SEGURIDAD

POMDP ------ ------ ------ Ds (*) Evaluación de impacto

de una intrusión

Métrica de coste total de

respuesta ------ ------ ------

MAGERIT ------ ------ ------ Valoración de

activos

Evaluación del impacto de una intrusión

(Análisis de riesgos) ------

Evaluación del impacto de una respuesta

(Análisis de riesgos) ------ ------

Wang et al. Métrica de

confianza en IDS

------ ------ ------ ------ ------ ------ ------ ------

CIDN Modelo de

reputación y confianza

------ ------ ------ ------ ------ ------ ------ ------

Strasburg DFalseAlarm,

DFalseNegative (*) DMislabeledAlarm (*) ------ W(srj) (*)

Métrica de impacto de intrusión en recursos del

sistema

Operational Cost (OC)

Response Impact on the System (RSI)

Métrica de eficacia de la

respuesta (SF) ------

(*) Utilizan el parámetro pero no especifican ninguna ecuación o métrica para calcularlo


69

Del análisis realizado se puede extraer como conclusión que existen métricas propuestas en otros

trabajos de investigación que permiten medir casi todos los parámetros requeridos. En el Capítulo 6

se valora la posibilidad de utilizar alguna de estas métricas en el AIRS basado en ontologías, y se

especifican nuevas métricas que permitan medir aquellos parámetros no cubiertos por las métricas

existentes.

2.5 Mecanismos de evaluación de la respuesta

Como se indica previamente en esta memoria, la adaptabilidad es uno de los requisitos deseables en

un AIRS, entendiendo por adaptabilidad la capacidad del sistema para adaptar automáticamente la

selección de la respuesta en función de factores externos, tales como la eficacia o eficiencia de las

acciones de respuesta ejecutadas previamente o cambios que se produzcan en el entorno.

Por otra parte, otro requisito deseable es que el sistema siga un modelo sensible a costes en la

elección de la respuesta óptima, cuyo objetivo es elegir la respuesta adecuada para mitigar la

intrusión pero con impacto mínimo o nulo en la funcionalidad normal del sistema. Este modelo trata

de hacer un balance entre el daño de la intrusión y el coste e impacto de la respuesta. Uno de los

factores clave en este modelo es el nivel de éxito o eficacia de las respuestas ejecutadas

previamente.

Tanto para satisfacer el requisito de adaptabilidad como el de consideración del impacto de la

respuesta, el cálculo de la eficacia o éxito de las respuestas en sus anteriores ejecuciones es un

factor relevante, por lo que queda patente la necesidad de métricas y mecanismos consistentes que

evalúen dicha tasa de éxito o fracaso.

En la actualidad, muchos trabajos de investigación centran sus esfuerzos en la especificación de una

metodología de evaluación de la respuesta, cuya síntesis y análisis se recoge en esta sección.

2.5.1 Mecanismos de evaluación utilizados en los AIRSs

Los AIRSs analizados en este capítulo se dividen en tres bloques en lo que a mecanismos de

evaluación del éxito o eficacia se refiere:

- Aquellos que no tienen en cuenta la eficacia de la respuesta en la elección de la respuesta

óptima, y por tanto no proponen mecanismos de evaluación. A este grupo pertenecen: CSM,

EMERALD, SARA, MAIRF, Tanachaiwiwat’s IRS y Network IRS.

- Aquellos que tienen en cuenta la eficacia de la respuesta en la elección de la respuesta

óptima, pero o no especifican ninguna métrica o metodología para medir dicho parámetro, o

lo mide el administrador de la red de forma manual. A este grupo pertenecen: FAIR e IDAM &

IRS.

- Aquellos que además de tener la eficacia de la respuesta en la elección de la respuesta

óptima, especifican una métrica o proponen e implementan un método para evaluarla, cuyo

resultado es incluido posteriormente como parámetro en el proceso de inferencia. A este

grupo pertenecen: AAIRS, ADEPTS, Stakhanova’s IRS y Jahnke’s IRS.

Las métricas o metodologías utilizadas por los sistemas pertenecientes al tercer grupo se definen

brevemente a continuación.

AAIRS 2.5.1.1

En el análisis realizado de las métricas utilizadas por los sistemas de respuesta (Ver 2.4.2.3), se

observa que AAIRS especifica una métrica de éxito de las respuestas, cuya ecuación se presentó en

la sección anterior (Ver ecuación 2.12):


70

s n[i] [( s ono i h [i] s s os i h [i]

) o i o[i]]

Esta métrica se interpreta de la siguiente forma: cada plan step, táctica o implementación que

componen un determinado plan de respuesta, tiene asociado un factor de éxito (número entre 0 y 1),

que representa la tasa del número de veces que dicho componente ha sido desplegado con éxito con

respecto al total de veces que ha sido desplegados. Este factor de éxito junto con los pesos

asociados a dicho plan step, táctica o implementación, determinan el plan de respuesta a ejecutar

ante una intrusión determinada.

El sistema, por tanto, dispone de un mecanismo que ajusta dinámicamente el plan de respuesta

(conjunto de plan steps, y tácticas) en función de los resultados obtenidos tras aplicar la métrica de

éxito de las respuestas, donde un factor determinante es el factor de éxito asociado a cada plan

steps, táctica o implementación. No obstante, el factor de éxito en sí es establecido y actualizado por

el administrador del sistema de forma manual después de cada ataque, lo que depende de la

experiencia del administrador en el manejo de intrusiones.

ADEPTS 2.5.1.2

En el proceso de selección de la respuesta óptima, ADEPTS utiliza algoritmos que se basan

esencialmente en el impacto de la respuesta sobre actividades legítimas, la confianza en qué se está

produciendo una intrusión real, y la tasa de éxito de la respuesta en anteriores ejecuciones. Como ya

se especificó, el objetivo de estos algoritmos es estimar el camino de propagación de las intrusiones e

inferir la respuesta más apropiada para reducir la probabilidad de propagación de la intrusión tanto

como sea posible.

Relativo a la tasa de éxito de la respuesta, ADEPTS propone e implementa un mecanismo de

retroalimentación o feedback que permite evaluar el éxito de la respuesta desplegada. La métrica

utilizada en este mecanismo viene dada por la siguiente expresión:

In Io d CCI_nodo

∑CCI_hijos_nodo

Este mecanismo establece que, si tras aplicar la respuesta a un nodo, se tiene indicios de que un

nodo posterior al tratado ha sido alcanzado, se puede deducir que la acción de respuesta ha fallado y

por tanto, es necesario disminuir su EI (Effectiveness Index) o tasa de éxito. En caso de que el TTL

de la respuesta expire sin tener datos de detección de la misma intrusión o de variaciones de ella, se

aumenta el EI de la respuesta ejecutada en una cantidad fija.

En posteriores inferencias, el sistema tendrá en cuenta el valor de EI asociado a cada respuesta

mediante la aplicación de la denominada métrica de selección de la respuesta óptima (Ver 2.4.2.5).

Stakhanova’s IRS 2.5.1.3

Stakhanova propone un factor de éxito asociado a cada respuesta, cuyo valor tiene en cuenta a la

hora de inferir la respuesta apropiada frente a una intrusión. A este factor de éxito lo denomina

Success Factor (SF) y es un indicador de cuantas veces la respuesta ha tenido éxito y ha conseguido

mitigar la intrusión o reducir su impacto.

En los primeros trabajos de investigación de Stakhanova relacionados con la forma de valorar dicho

factor de éxito, proponían lo siguiente: partiendo de un valor fijo inicial de SF igual para todas las

respuestas, este se incrementa en 1 si tras desplegar la respuesta frente a un comportamiento

intrusivo el ataque es bloqueado; por el contrario, SF se disminuye en 1 si tras la respuesta sigue

habiendo signos de la intrusión tratada.

Años después, Stakhanova y Strasburg continuaron investigando sobre este tema y propusieron una

métrica para el cálculo de SF, ya analizada en esta memoria [Strasburg09]:

( )


71

No obstante, no especifican el mecanismo mediante el que asignan valor 0 o 1 a la variable Slevel.

Jahnke’s IRS 2.5.1.4

Jahnke [Jahnke07] propone una métrica de éxito de la respuesta, para lo que evalúa el grafo de

accesibilidad del sistema comprometido en términos de disponibilidad, integridad y confidencialidad,

antes y después de la ejecución de la reacción, y define el éxito de la misma como la diferencia entre

ambos. La ecuación propuesta se presenta en la sección correspondiente a métricas de esta

memoria (Ver 2.4.2.12).

2.5.2 Otros mecanismos propuestos

Además de las métricas o mecanismos utilizados en los AIRSs para evaluar el éxito de una reacción

de respuesta, existen otros trabajos de investigación que proponen mecanismos de evaluación en

otras áreas pero que pueden ser aplicables a la reacción frente a intrusiones.

En [Kanoun09], los autores establecen que en un sistema de detección y respuesta a intrusiones que

combinan el análisis de riesgos y el proceso de detección y respuesta, este riesgo tiene

principalmente dos dimensiones: la probabilidad de éxito de los ataques, y el impacto de ataques y

contramedidas. En este paper, los autores presentan un modelo para evaluar la probabilidad de éxito

de los ataques, es decir, la probabilidad de que el atacante cumpla su objetivo, para lo que adoptan

un punto de vista defensivo, y especifican una métrica denominada Success Likelihood (SL), como

indicador de cuánto de cerca está un atacante de alcanzar su objetivo. Este modelo consta de tres

fases: en la primera los autores generan un grafo de ataque a partir de los informes recibidos por el

IDS; a continuación transforman dicho grafo en modelos dinámicos de Markov que tienen en cuenta

la evolución de los ataques en curso y la evolución del estado del sistema objetivo; por último,

ejecutan la métrica de probabilidad de éxito y priorizan en la activación de respuestas candidatas

frente al ataque tratado. Esta métrica se basa en una fórmula logarítmica empírica derivada del

tiempo, similar a la utilizada para expresar de forma cuantitativa una magnitud física (Potencia,

tensión, corriente, etc.) que transforma la métrica temporal MTIO en una métrica logarítmica relativa

de probabilidad de éxito. La métrica que proponen se rige por la siguiente ecuación:

(

) (2.52)

El modelo utilizado por los autores de este trabajo de investigación para el cálculo de la probabilidad

de éxito de un ataque, puede ser aplicable al cálculo de la probabilidad de éxito de una respuesta.

En [Shameli-Sendi13], se presenta un mecanismo de evaluación de la eficacia de la respuesta

ejecutada mediante la evaluación del índice de riesgo en la red y en el componente afectado tras la

aplicación de la respuesta. De forma breve, el proceso sería el siguiente: el sistema de respuesta

infiere varios conjuntos de respuestas capaces de mitigar la intrusión detectada, que se ejecutan de

forma consecutiva en caso de que sea necesario. Cada conjunto de respuestas presentes en la cola

de ejecución puede contener una o varias acciones de respuesta, y la severidad de las respuestas

por lo general va en orden creciente, es decir, el primer conjunto contiene respuestas con severidad

baja pero óptimas para la intrusión, el segundo conjunto está compuesto por respuestas cuya

severidad es mayor, y así sucesivamente. Una vez inferidos los conjuntos de respuestas, se procede

a aplicar las respuestas del primer conjunto. Tras finalizar la aplicación de cada una de ellas, el

sistema evalúa si el riesgo existente en el componente ha disminuido como consecuencia de la

aplicación de las respuestas. En caso afirmativo, se considera que el conjunto de reacciones ha sido

eficaz; si por el contrario, el riesgo permanece invariable o incluso aumenta, las respuestas se

consideran no eficaces y se procede a la ejecución del siguiente conjunto de respuestas de la lista.

Para representar la tasa de éxito o fallo de cada una de las respuestas en función del tipo de host,

definen un parámetro al que denominan Goodness.


72

Por otra parte, la siguiente ecuación mide la eficacia de una acción preventiva como se vio en el

apartado anterior (Ver 2.4.3.4):

(

) ( )

Donde, Io es la tasa de ataque en individuos a los que no se ha aplicado la acción preventiva, Ie es la

tasa de ataque en individuos a los que se ha aplicado la acción preventiva, y RR = Ie/Io.

La métrica anterior se utiliza en el área de epidemiología, para medir la eficacia de una campaña de

vacunación, por ejemplo. En el caso de las respuestas frente a intrusiones podríamos utilizar una

métrica equivalente a la anterior para obtener conocimiento de los resultados de aplicación de las

respuestas inferidas para responder frente a una intrusión.


El éxito o fallo de una respuesta no es un parámetro fácil de medir, ya que debe ser lo más preciso y

objetivo posible. Por ello, es importante que sea el propio sistema de respuesta el que se adapte en

tiempo real y mida el éxito de sus respuestas una vez finalizada su ejecución de forma automática.

Como se resume en este apartado, muchos de los AIRSs analizados no tienen ni siquiera en cuenta

la eficacia de la respuesta en la elección de la respuesta óptima, y en algunos que sí la tienen en

cuenta, o no especifican ninguna métrica o metodología para medir dicho parámetro, o lo mide el

administrador de la red de forma manual.

La siguiente tabla presenta un análisis comparativo entre los 4 sistemas de respuesta analizados que

sí proponen una métrica o mecanismo para evaluar el éxito de la respuesta:

Tabla 2.8 Mecanismos de evaluación de la respuesta. Resumen comparativo.

AAIRS ADEPTS Stakhanova’s

IRS

Jahnke’s IRS

Parámetro de

éxito factorExito EI (Effectiveness Index) Slevel SF

Métrica de

cálculo del

factor de éxito

No especificada

Basado en % de alcance

de un nodo del I-GRAPH:

In

Io d

CCI_nodo

∑CCI_hijos_nodo

No especificada

Basado en grafo

de accesibilidad

del sistema antes y

después de la

respuesta:

( )

( ) ( )

Como se observa tanto AAIRS como el AIRS propuesto por Stakhanova disponen de un mecanismo

que ajusta la selección de la respuesta óptima a los resultados obtenidos tras aplicar la métrica de

éxito de las respuestas, donde un factor determinante es el factor de éxito, pero no indican cómo se

calcula o mide dicho factor de éxito. En el caso del AAIRS este parámetro es establecido y

actualizado por el administrador del sistema de forma manual.

Los mecanismos o métricas propuestas por ADEPTS y Jahnke’s IRS son mecanismos adaptados a

su modelo de grafos.

Además, existen otras propuestas en el área de detección y respuesta a intrusiones o en otros

campos de investigación, relacionadas con la evaluación del éxito o fracaso de una acción, que

pueden servir de referencia para su utilización en un AIRS. Algunos de los métodos propuestos


73

consisten en utilizar modelos dinámicos de Markov para evaluar la evolución de un ataque y calcular

su probabilidad de éxito, o comparar el riesgo antes y después de la ejecución de una acción de

respuesta para determinar su éxito o fracaso, o aplicar los mecanismos propuestos en el área de la

medicina y la epidemiología para evaluar la eficacia de una acción preventiva al área de la respuesta

a intrusiones.

Como conclusión de esta sección se extrae que hay bastantes trabajos de investigación centrados en

definir y especificar mecanismos de evaluación del éxito de las respuestas, pero no se ha alcanzado

un grado de madurez suficiente por lo que aún queda mucho trabajo por hacer en este campo de

investigación. Todos los investigadores coinciden en que es importante evaluar automáticamente los

factores involucrados en el modelado de costes y beneficios de un sistema de respuesta a

intrusiones, pero también coinciden en que cuantificar todos estos factores es un proceso complicado

que suele entrañar resultados engañosos y poco precisos ya que entre otras dificultades, no todos los

factores se pueden reducir a valores discretos posibles de medir.

2.6 Conclusiones

Este capítulo recoge un análisis del estado del arte de los Sistemas de Respuesta Automática frente

a Intrusiones existentes, explicando las diferentes arquitecturas propuestas y sus mecanismos de

inferencia de la respuesta(s) óptima(s). Además, se presenta una panorámica del estado del arte de

las métricas de seguridad utilizadas en cada uno de los AIRSs descritos, desde el punto de vista de

su utilidad e importancia en el proceso de inferencia.

Por otra parte, como se verá más adelante en este documento, el éxito o fracaso de las respuestas

inferidas por el sistema es un parámetro esencial para su correcto funcionamiento, por lo que este

capítulo también incluye un estudio del estado del arte de los mecanismos de evaluación del éxito de

la respuesta existentes.

Como principales resultados o conclusiones del estudio y análisis realizado se obtiene que:

- Cada uno de los AIRSs estudiados posee una arquitectura, un mecanismo de inferencia de la

respuesta(s) óptima(s) y unas métricas diferentes, aunque el objetivo a alcanzar sea un

objetivo común: mitigar el ataque o reducir su impacto. En función de su arquitectura y

principio de funcionamiento cumplen en mayor o menor medida las características deseables,

pero ninguno aborda todas a la vez. Recalcar, que ninguno excepto IDAM&IRS tiene en

cuenta el tema de la coherencia semántica en la representación de alertas, requisito muy

relevante en entornos heterogéneos.

- Existen gran esfuerzo y trabajo dedicado al estudio, definición y especificación de métricas de

seguridad, ya sean métricas utilizadas por los AIRSs existentes o métricas propuestas en

otros ámbitos que se aplican a la evaluación de parámetros como el impacto de una intrusión,

el coste de una respuesta o el beneficio de la misma. En lo relativo a los sistemas de

respuesta se observa que estos aplican siempre las mismas métricas, es decir, las métricas

no pueden ser elegidas de forma dinámica en función del escenario de intrusión específico de

cada momento. Esta problemática se aborda en Capítulo 6.

- El éxito o fallo de una respuesta no es un parámetro fácil de medir, ya que debe ser lo más

preciso y objetivo posible. Por ello, es importante que sea el propio sistema de respuesta el

que se adapte en tiempo real y mida el éxito de sus respuestas una vez finalizada su

ejecución de forma automática. Como conclusión del análisis de sistemas de evaluación, se

extrae que hay ciertos trabajos de investigación centrados en definir y especificar

mecanismos de evaluación del éxito de las respuestas, pero no se ha alcanzado un grado de

madurez suficiente por lo que aún queda mucho trabajo por hacer en este campo de

investigación. Todos los investigadores coinciden en que es importante evaluar

automáticamente los factores involucrados en el modelado de costes y beneficios de un


74

sistema de respuesta a intrusiones, pero también coinciden en que cuantificar todos estos

factores es un proceso complicado que suele entrañar resultados engañosos y poco precisos

ya que entre otras dificultades, no todos los factores se pueden reducir a valores discretos

posibles de medir

En este capítulo se ha realizado un extenso estudio del estado del arte en tres ámbitos bien

diferenciados: AIRSs, métricas de seguridad y metodologías o sistemas de evaluación del éxito de

una acción de respuesta. Estos tres ámbitos, son el ámbito de tres de las cuatro propuestas de la

presenta tesis doctoral.

Capítulo 3: Las Ontologías como Técnicas de Representación del Conocimiento

75

LAS ONTOLOGÍAS COMO TÉCNICAS DE Capítulo 3

REPRESENTACIÓN DEL CONOCIMIENTO

3.1 Introducción

Las ontologías son una técnica utilizada en informática en el mundo de la gestión del conocimiento e

inteligencia artificial como modo de representar formalmente conceptos, su significado y relaciones

entre ellos. Una de las definiciones más aceptadas del concepto de ontología y la que la describe de

manera más completa es la contenida en [Studer98], donde se define como “una especificación

explícita y formal de una conceptualización compartida”:

- Es explícita porque define expresamente los conceptos, propiedades, relaciones, funciones,

taxonomías, axiomas y restricciones o reglas que la componen.

- Es formal porque se especifica mediante un lenguaje interpretable por máquinas.

- Es una conceptualización porque es un modelo abstracto que supone una vista simplificada

del dominio que se quiere representar, tanto de su estructura como de lo que acontece en él.

- Es compartida porque la información ha sido consensuada previamente entre distintos grupos

de expertos.

Si dos agentes, ya sean personas o agentes software, deciden comunicarse mediante una ontología

común, estos agentes “se comprometen” con ella. La ontología compartida por ambos agentes debe

ser exactamente la misma, ya que de lo contrario se puede dar lugar a los llamados desajustes

ontológicos, que no son más que malentendidos provocados por el uso de diferentes ontologías. Para

minimizar la aparición de estos desajustes es imprescindible la representación de la ontología en un

lenguaje formal, además del hecho de que la ontología debe ser compartida y por tanto, su desarrollo

debe ser un proceso en el que colaboren distintas personas bajo consenso.

De esta forma, mediante ontologías distintos agentes inteligentes podrían compartir y reutilizar

conocimiento, tratando de resolver problemas de heterogeneidad que se plantean entre los diferentes

lenguajes de especificación y a distintos niveles: uso de diferentes paradigmas o formalismos, uso de

diferentes dialectos de un mismo paradigma, ausencia de normalización en los protocolos de

intercambio de conocimiento y desemparejamiento a nivel semántico en las bases de conocimiento

[Guerrero07].

La utilización de la representación mediante ontologías ha ganado enorme relevancia con la aparición

de la Web Semántica, cuyo objetivo principal es organizar la información Web y formalizarla, de modo

que ésta sea interpretable de forma inteligente por aplicaciones capaces de extraer su significado.

Las ontologías más típicas para su uso en la Web, están formadas por dos elementos, una taxonomía

y un conjunto de reglas de inferencia:


76

- La taxonomía define clases y subclases de objetos y relaciones existentes entre dichos

objetos. También se encarga de la asignación de propiedades a las clases.

- Las reglas de inferencia añaden una capacidad adicional útil para el usuario humano que

hace uso de la ontología. Estas reglas permiten expresar restricciones y condiciones sobre

los objetos de las clases definidas mediante la taxonomía. La forma de expresar restricciones

y reglas en un lenguaje de ontologías es mediante axiomas. Los axiomas pueden ser de

varias clases, por ejemplo, axiomas de subclase, axiomas de equivalencia de clases,

restricciones sobre propiedades, etc.

En el caso concreto de la utilización de ontologías como base de representación de conocimiento

para un sistema de respuesta a intrusiones, como el propuesto en este trabajo, tiene el gran valor

añadido de que es capaz de integrar semánticamente las distintas fuentes de información de las que

se parte para producir una respuesta (información sobre detección de intrusiones, información de

contexto, etc.). Para ello se utilizan los lenguajes de representación de conocimiento o lenguajes de

definición de ontologías, que se analizarán más adelante en este capítulo.

Además de la capacidad de representar conocimiento, para un sistema de respuesta es esencial

asimismo la capacidad de representar reacciones frente a eventos, por lo que se necesitan lenguajes

de especificación del comportamiento que puedan ser interpretados en conjunción con los conceptos

representados en las ontologías. Una revisión de los lenguajes de representación del comportamiento

o de definición de políticas de seguridad más relevantes se llevará a cabo en este capítulo de la

memoria.

3.2 Lenguajes de definición de ontologías

Existen numerosos lenguajes orientados a la definición de ontologías, que se clasifican en diferentes

paradigmas según sus patrones de especificación de información y la terminología empleada en cada

uno de ellos. La diferencia entre unos y otros radica en los elementos que incorporan y el uso que se

hace de ellos.

Los elementos más comunes son los conceptos o clases, los ejemplares de estas clases y sus

propiedades, las facetas de las propiedades (cardinalidad, cuantificación universal, existencia, etc.),

las relaciones que se pueden establecer entre las clases (herencia, asociación, etc.) y los axiomas. A

continuación se recoge una breve definición de cada uno de estos elementos:

- Concepto (clase): se refiere a las ideas que queremos formalizar con la ontología. Un

concepto puede ser cualquier cosa, desde un objeto, como una mesa, hasta algo abstracto

como un proceso de razonamiento complejo. La formalización del concepto tendrá en cuenta

el dominio de aplicación en donde usaremos la ontología. Los conceptos se formalizan

mediante el uso de clases.

- Ejemplar (individuo): instancia concreta de una clase que modela a un determinado concepto.

También recibe el nombre de individuo. Cada ejemplar se caracteriza por un conjunto de

propiedades. La diversidad de valores posibles para cada una de las propiedades permite

distinguir un ejemplar de una clase de otros de la misma clase. Así mismo, estas propiedades

poseen unas facetas que permiten dotar de distintos grados a la propiedad como pueden ser,

la cardinalidad, cuantificación universal, existencia, etc.

- Relación: elemento que representa las interacciones que se producen entre dos conceptos o

clases del dominio. Las relaciones pueden ser de diversa naturaleza (herencia, asociación,

etc.). Las relaciones son muy importantes ya que permiten la deducción de nuevo

conocimiento. Un tipo de relación especial es aquella que se utiliza para identificar elementos

concretos de la ontología mediante su aplicación sobre todos o parte de los elementos de la

misma. A este tipo de relación se le denomina función.


77

- Axiomas: son verdades que no necesitan demostración y que en el mundo de las ontologías

se aplican sobre las relaciones que cumplen los elementos de una ontología.

Los lenguajes de definición de ontologías se clasifican en tres grandes bloques [LopezDeVergara03]:

- Lenguajes tradicionales: lenguajes previos al desarrollo de la Web Semántica basados en

lógica de primer orden y frames, entre los que destacan: KIF (Knowledge Interchange

Format), Ontolingua, Loom, OKBC (Open Knowledge Base Connectivity), OCML (Operational

Conceptual Modeling Language) y F-Logic (Frame Logic).

- UML (Unified Modeling Language) y OCL (Object Constraint Language). El primero normaliza

una notación y un conjunto de diagramas para los procesos de modelado en ingeniería del

SW, y debido a su gran difusión se ha convertido casi en un estándar en este campo. El

interés de utilizar UML como lenguaje de ontologías se deriva de su amplia difusión y

madurez. Para especificar restricciones sobre la información definida mediante UML se

propuso el lenguaje OCL, que se trata de un lenguaje en toda regla, caracterizado por una

sintaxis propia.

- Lenguajes de la Web Semántica: lenguajes basados en lenguajes de marcado (XML) entre

los que se encuentran RDF, RDFS, DAML+OIL, OWL, OWL2, etc.

Debido a las ventajas de utilizar lenguajes que tengan no sólo una sintaxis formal sino también una

semántica formal interpretable por las máquinas, y debido a su relación con el trabajo de

investigación desarrollado, a continuación se describen en mayor profundidad los lenguajes de

ontologías pertenecientes a la Web Semántica, prestando especial atención al lenguaje OWL y

OWL2.

Se considera que la base de todos los lenguajes de la Web Semántica es el lenguaje XML (Extensible

Markup Language). XML proporciona la sintaxis para construir documentos estructurados, pero no

impone ninguna restricción semántica, por lo que no podemos considerarlo un lenguaje de ontologías

como tal. No obstante, XML es un lenguaje de estructuración sintáctico que permite identificar

unívocamente los elementos de los documentos mediante XML namespaces (URI única y referencia

relativa única), lo que permite reutilizar los elementos de los documentos a lo largo de toda la Web, y

posibilita la creación de documentos únicos (incluyendo las ontologías definidas por los lenguajes que

veremos) con ubicación distribuida.

Los primeros lenguajes de ontologías en este entorno aparecieron con el objetivo de proporcionar

metainformación para los distintos elementos de información de los documentos web (información

referente al idioma empleado, autor, documentos relacionados, etc.). A día de hoy, existe un gran

camino recorrido en materia de lenguajes de ontologías en la Web Semántica, resultando en

diferentes propuestas y estándares por parte del W3C.

En la siguiente figura se muestra la evolución cronológica de los principales lenguajes de definición

de ontologías de la Web Semántica desde su aparición hasta la actualidad.


78

Figura 3.1 Evolución de lenguajes de ontologías de la Web Semántica.

A continuación se describen brevemente algunos de los lenguajes más utilizados para la definición de

ontologías.

3.2.1 SHOE

Simple HTML Ontology Extensions (SHOE) [SHOE] es un lenguaje de ontologías que define

extensiones para incluir anotaciones en HTML. Aunque se basa en HTML, también existe una

serialización en XML. Fue el primer lenguaje de etiquetado para diseñar ontologías en la web. SHOE

combina las características de los lenguajes de marcado, de la representación del conocimiento, de

datalog y de las ontologías en un intento de abordar de forma única los problemas de la semántica en

la Web. El lenguaje soporta adquisición del conocimiento aumentando la web con etiquetas que

suministran semántica. La estructura básica de SHOE son las ontologías, que definen las reglas que

nos dicen que tipo de aserciones pueden hacerse y que clase de conclusiones pueden derivarse de

esas aserciones, y las instancias, que realizan las aserciones basándose en esas reglas.

Este lenguaje permite definir clases y reglas de inferencia pero no negaciones o disyunciones, y a su

albur se desarrollaron muchos editores, buscadores, APIS, etc. A pesar de ello, este proyecto fue

abandonado con el desarrollo de OIL y DAML (lenguajes de definición de ontologías más completos

basados en XML).

3.2.2 RDF y RDF-Schema

Resource Description Framework (RDF) es un lenguaje de especificación de ontologías ligero

utilizado para describir e intercambiar metadatos en la World Wide Web desarrollado por el W3C.

Gran parte del cuerpo de conocimiento de la Web Semántica se basa en este lenguaje, ya que es el

primer lenguaje que incorpora una semántica formal, que puede ser comprendida por máquinas. Su

uso se describe en [Manola04], su sintaxis abstracta en [Klyne04], en [Hayes04] su semántica y en

[Beckett04] su sintaxis de intercambio de información más utilizada, basada en XML.

La semántica de RDF es muy simple, se basa en tripletes (sujeto-predicado-objeto). Mediante el

triplete se especifica una relación entre un sujeto y un objeto a través de una propiedad. El sujeto es

aquello que se está describiendo, el predicado es la propiedad o relación que se desea establecer

acerca del sujeto, y el objeto es el valor de la propiedad. Sujeto, propiedad y objeto se identifican por

medio de una URI (Uniform Resource Identifier). Los objetos, además de elementos identificados por

URIs, pueden ser literales, es decir, valores con su tipo de dato asociado. Recurso es cualquier

elemento que pueda ser identificado por una URI, por ejemplo, páginas web, elementos de un

documento XML, etc. Un mismo recurso puede utilizarse en unos tripletes como sujeto, en otros como

objeto, y en otros incluso como propiedad. La conjunción de tripletes referidos a un conjunto concreto

de recursos forma un grafo RDF, que puede entenderse como ontología RDF.


79

A modo de ejemplo, supongamos la sentencia “New York has the postal abbreviation NY”. En ella,

“New York” sería el sujeto, “has the postal abbreviation” el predicado y “NY” el objeto. Si se codifica la

sentencia anterior como un triplete RDF, el sujeto y el predicado tendrían que ser recursos

identificado mediante URIs, mientras que el objeto podría ser un recurso identificado por una URI o

un literal. Hay diferentes formatos para representar tripletes RDF.

La sentencia anterior codificada bajo el formato Notation 3 de RDF (serialización de RDF no basada

en XML) tendría la siguiente forma:

<urn:states:New%20York> <http://purl.org/dc/terms/alternative> “NY” .

Mientras que si se representa utilizando el formato estándar RDF/XML, sería:

Figura 3.2 Triplete representado en formato estándar RDF/XML

En ambos casos, “urn:states:New%20York” es la URI para el recurso sujeto que representa a la

ciudad americana de Nueva York, “http://purl.org/dc/terms/alternative” es la URI correspondiente al

predicado (ver [DublinCore] para obtener su definición completa y comprensible por humanos), y “NY”

es un literal que representa el objeto.

El hecho de incorporar una semántica formal permite razonar con el lenguaje para inferir información.

No obstante, la semántica simple de RDF limita este razonamiento, por lo que en el caso concreto de

RDF el razonamiento tiene poca aplicabilidad. Además, la estructura de triplete que utiliza este

lenguaje no es lo suficientemente expresiva.

Resource Description Framework Schema, RDFS, es un lenguaje de definición de ontologías que

surge como una extensión de RDF. La primera versión fue publicada en Abril de 1998 por la W3C,

publicándose la versión actual en Febrero de 2004.

Un archivo RDFS posee una sintaxis muy similar (basada en XML) y la misma estructura que un

archivo RDF, por lo que en principio podría considerarse como un modelo RDF más. Sin embargo, la

semántica definida para este nuevo modelo RDF es totalmente diferente, lo que convierte a RDFS en

un nuevo lenguaje para especificar otros dominios de conocimiento. La peculiaridad de este nuevo

lenguaje es que los modelos de información basados en él también pueden hacer uso de RDF, es

decir, ambos lenguajes pueden convivir al mismo nivel. Esto se debe a que la semántica de RDFS

extiende la de RDF.

RDFS permite definir restricciones adicionales sobre los recursos y propiedades de RDF. Por

ejemplo, se definen el recurso class y la propiedad type, que permiten definir ejemplares y las clases

a las que pertenecen. También se crean las propiedades subclassOf, para especificar herencia de

clases; range y domain para especificar clases como rango y dominio de una propiedad;

subpropertyOf para definir especialización de propiedades, etc. Utilizando estos nuevos elementos

del lenguaje RDFS se construyen los vocabularios RDF, que sí podemos considerarlos como

ontologías.

3.2.3 OIL y DAML+OIL

Ontology Inference Layer u Ontology Interchange Language [Fensel01] es un lenguaje de definición

de ontologías perteneciente a la Web Semántica, que fue impulsado por el proyecto On-To-

http://purl.org/dc/terms/alternative

http://purl.org/dc/terms/alternative


80

Knowledge de la Unión Europea. Como la mayoría de los lenguajes de la Web Semántica, utiliza la

sintaxis del lenguaje XML. Está definido como una extensión de RDFS, por lo que es compatible con

él. Se basa tanto en la lógica descriptiva (declaración de axiomas) como en los sistemas basados en

frames (taxonomías de clases y atributos). Incluye una semántica minuciosa y precisa para describir

el significado de términos (por lo que permite describir también información implícita).

OIL está estructurado en varias capas de sub-lenguajes, entre las que destaca la capa base, RDFS.

Cada capa adicional añade funcionalidad y complejidad a la capa anterior. De este modo, agentes

(humanos o máquinas) que sólo poseen la capacidad de procesar expresiones de una capa de nivel

inferior, pueden entender parcialmente ontologías expresadas en cualquiera de las capas superiores.

Este modelo de capas se observa en la siguiente figura:

Figura 3.3 Jerarquía de capas del lenguaje de ontologías OIL [Fensel01]

El principal inconveniente de OIL es la falta de expresividad para declarar axiomas, razón por la que

surgió DAML+OIL como resultado de la cooperación entre OIL y DARPA, responsable de la definición

del lenguaje DAML (DARPA’s Agent Markup Language) que se desarrolló a mediados del año 2000

con el fin de extender el nivel de expresividad de RDF-Schema.

DAML+OIL es un lenguaje que se basa en estándares del W3C, que unifica ambos lenguajes

combinando los rasgos más importantes de cada uno de ellos. DAML+OIL hereda muchas de las

características de OIL pero se aleja del modelo basado en frames, centrándose y potenciando la

lógica descriptiva, DL (Description Logic). Es un lenguaje más potente que RDF-Schema para

expresar ontologías. En la última revisión del lenguaje [Connolly01], este ya posee un valioso

conjunto de elementos que permiten crear ontologías y marcar la información para que sea legible y

comprensible por las máquinas. También funciona como formato de intercambio de información y

cuenta con una mayor capacidad de expresión e inferencia que sus predecesores.

Pero DAML+OIL presenta una serie de carencias debido a su gran complejidad tanto conceptual

como de uso. Con el fin de solventar esta complejidad se desarrolló el lenguaje OWL.

3.2.4 OWL

Ontology Web Language (OWL, [Bechhofer04a]) es el lenguaje de la Web Semántica más utilizado

en la actualidad junto con OWL2 para representar ontologías de forma explícita, es decir, permite

definir el significado de términos en vocabularios y las relaciones entre aquellos términos. OWL ha

sustituido a DAML+OIL como estándar del W3C para la representación de ontologías. Ambos

lenguajes son muy parecidos tanto sintáctica como semánticamente, pero OWL es mucho más

completo.

OWL es un lenguaje de ontologías orientado a objetos, de semántica formal y sintaxis abstracta. La

sintaxis abstracta define qué puede y qué no puede tener cada elemento de información contenido en

la ontología, pero de una forma no apta para la lectura humana. Por ello, se proponen dos sintaxis

para intercambio de información que permiten que las ontologías puedan ser interpretadas e

intercambiadas entre diferentes herramientas y aplicaciones: RDF/XML (la más utilizada que se basa


81

en la sintaxis de XML de RDF y RDFS), y OWL/XML (basada directamente en XML). En cuanto a la

semántica, se proponen dos semánticas formales diferentes, una basada en la teoría del modelo, y

otra semántica extensión de vocabulario de la semántica RDF, que proporciona significado a las

ontologías OWL en forma de grafos RDF. Ambas, obligan al soporte de los tipos de datos definidos

en XML Schema.

La sintaxis de OWL define clases, propiedades de las clases y ejemplares o individuos de dichas

clases, que constituyen los elementos de información del lenguaje. Cada individuo posee unos

valores determinados de las propiedades de la clase a la que pertenecen. Además, OWL permite

definir axiomas que se aplican sobre dichos elementos para relacionarlos entre sí, así como modificar

o restringir su significado extensivo (aunque los axiomas no pueden modificar el significado intensivo,

es decir, el concepto que representan).

Al igual que OIL, OWL se estructura en capas que difieren en la complejidad y puede ser adaptado a

las necesidades de cada usuario, al nivel de expresividad que se precise y a los distintos tipos de

aplicaciones existentes (motores de búsqueda, agentes, etc.). En relación a ello, se han desarrollado

tres versiones de OWL [McGuinness04]:

- OWL Lite: versión más reducida, no compatible con todos los documentos RDF/RDFS. Se

define como un subconjunto de las construcciones totales existentes para OWL, y además

establece restricciones en su uso. Está pensado para principiantes o aquellos que buscan

sobre todo la sencillez. Formalmente, su semántica puede considerarse como una extensión

de un subconjunto de RDFS.

- OWL DL (OWL Description Logic): destinado a aquellos usuarios que quieren máxima

expresividad pero garantizando completitud computacional (posibilidad de llegar a

conclusiones basadas en la información existente) e inferencia en tiempo finito. Incluye todas

las construcciones definidas para OWL, pero se deben utilizar con ciertas restricciones para

alcanzar las propiedades mencionadas. Esto hace que no sea compatible con documentos

que utilizan la máxima expresividad de RDF/RDFS, ya que su semántica es también una

extensión de un subconjunto de la de éste.

- OWL Full: versión más amplia, destinada a aquellos usuarios que quieren máxima

expresividad y la libertad sintáctica de RDF. Es compatible con RDF/RDFS, pudiendo

concebirse su semántica como una extensión de la de éste, es decir, sigue el mismo

procedimiento de construcción sobre RDF y RDFS que RDFS en relación a RDF. Por tanto,

los modelos basados en OWL Full pueden utilizar libremente construcciones propias de RDF,

RDFS y OWL. A cambio de ello, no existen garantías sobre la completitud y el tiempo finito en

el razonamiento. Ello se debe a que las propias construcciones que definen el metamodelo

pueden utilizarse en los modelos, lo cual significa mucha flexibilidad pero también demasiada

libertad.

Con respecto a la expresividad del lenguaje, tanto la sintaxis RDF/XML, como la sintaxis OWL/XML

se basan en la teoría del modelo [RDFMT01]. Dicha teoría se trata de una técnica para especificar

formalmente la semántica de un lenguaje formal, con ciertas características comunes a la teoría de

conjuntos. Asume que el lenguaje se refiere a un mundo, y describe las condiciones mínimas que un

mundo debe satisfacer para asignar un significado apropiado a cada expresión del lenguaje. Cada

mundo concreto al que se puede referir dicho lenguaje se llama interpretación [Fernandez04]. Una

interpretación es la concepción de un mundo con diferentes elementos de distinto tipo y distinto

significado (vocabulario), entre los cuales se incluyen los datatypes (tipos de datos utilizados), y esta

interpretación puede satisfacer o no una ontología determinada. Además, la interpretación debe

satisfacer unas condiciones mínimas relativas a los elementos del metamodelo para ser considerada

una interpretación OWL. La idea fundamental de la teoría del modelo y que debe ser tenida en cuenta

para el diseño de aplicaciones basadas en ontologías OWL es que su planteamiento es totalmente

descriptivo: las sentencias de las ontologías no determinan la existencia o no existencia de los

elementos, simplemente los describen. Es decir, se debe asumir que existe un mundo (interpretación)


82

y nuestra ontología simplemente habla sobre él. Se trata de un planteamiento de tipo open-world, en

el que cualquier documento puede importar otra ontología e incorporar nuevas sentencias que

completan la descripción sobre ese mundo (coherente con el principio de reutilización y distribución

de recursos en la Web).

En resumen, una ontología no determina cómo es el mundo, sino que ese mundo o interpretación

podrá satisfacer o no la ontología, es decir, podrá ser coherente con ella o no. Dada una ontología

OWL, puede haber numerosas interpretaciones (distintos posibles mundos supuestos) que la

satisfagan, para lo cual deberán cumplir una serie de restricciones.

3.2.5 OWL2

OWL2 ([OWL2W3C12], [Hitzler12]) es una extensión y revisión del OWL desarrollada por el Web

Ontology Working Group del W3C cuya primera versión fue publicada en 2004. Al igual que OWL, su

objetivo es facilitar el desarrollo de ontologías y el intercambio de información a través de la Web,

para hacer el contenido web más accesible e interpretable por las máquinas. La siguiente figura

muestra los principales componentes de la estructura de OWL2 y la relación entre ellos.

Figura 3.4 Estructura de OWL2 [OWL2W3C12]

La elipse del centro representa la ontología en sí misma, ya sea una estructura abstracta o un grafo

RDF. En la parte superior se observan los diferentes formatos de sintaxis para el intercambio de

información con la ontología. Y en la parta inferior, se observan los dos modelos de semántica formal

soportados, que definen el significado de las ontologías en OWL2.

OWL2 extiende a OWL tanto en la semántica como la sintaxis, y su grado de expresividad es mucho

mayor. En cuanto a la sintaxis, OWL2 utiliza principalmente RDF/XML como sintaxis de intercambio

de información, al igual que OWL, y ésta debe ser soportada por todas las herramientas que manejen

ontologías OWL2. Además de RDF/XML, soporta otros formatos como por ejemplo OWL2

Manchester, como se ve en la siguiente tabla:


83

Tabla 3.1 Sintaxis de intercambio de OWL2.

Sintaxis Estado Objetivo/Características

RDF/XML Obligatorio

Útil para intercambio de

información.

Compatible con todo el SW de

soporte de OWL2.

OWL/XML Opcional Fácil procesamiento y manejo

mediante herramientas de XML

Sintaxis Funcional Opcional Facilita la visión de la estructura

formal de las ontologías.

Sintaxis Manchester Opcional Facilidad de lectura/escritura de

ontologías DL.

Turtle

Opcional.

No desde

OWL-WG

Facilidad de lectura/escritura de

tripletes RDF.

En cuanto a la semántica, se definen dos modelos: la semántica directa y la semántica basada en

RDF. Ambas proporcionan dos formas alternativas de dotar de significado a las ontologías y son

utilizadas por los razonadores y otras herramientas, para entre otras cosas, comprobar la

consistencia de clases, la subsunción o para realizar consultas sobre individuos. Existe un teorema

que permite relacionar ambas semánticas estableciendo relaciones y equivalencias entre ellas.

OWL2 cuenta con tres perfiles diferentes, también llamados fragmentos o sublenguajes. Cada perfil

es una versión reducida de OWL2 cuyo objetivo es mejorar la eficiencia de razonamiento en

diferentes escenarios de aplicación. Los perfiles son independientes entre sí, y la elección de uno u

otro, o de OWL2 con semántica directa o OWL2 con semántica basada en RDF, depende de la

estructura de la ontología y las tareas de razonamiento que se quieran conseguir. Los perfiles son:

- OWL2 EL (Existencial Language): perfil muy utilizado en ontologías con gran cantidad de

propiedades y clases. Este perfil es un subconjunto de OWL2 que permite tareas de

razonamiento básicas utilizando algoritmos de tiempo polinómico sin perder la expresividad.

El tiempo de razonamiento es proporcional de forma polinómica al tamaño de la ontología. La

escalabilidad de estos algoritmos dedicados ha sido probada con ontologías de muchas

clases y propiedades.

- OWL2 QL (Query Language): perfil dirigido a ontologías que utilizan grandes cantidades de

instancias o individuos, donde responder a consultas sobre datos de dichas instancias de una

forma eficiente es lo más importante de las tareas de razonamiento. Además, se pueden

utilizar algoritmos de tiempo polinómico para comprobar la consistencia de la ontología y la

subsunción de clases. Las consultas pueden ser formuladas utilizando el lenguaje estándar

Query Language. Como contrapartida, la fuerza expresiva de este perfil es más limitada que

la del perfil anterior.

- OWL2 RL (Rule Language): perfil dirigido a aplicaciones que requieren razonamiento

escalable pero sin sacrificar demasiado la potencia expresiva. Este perfil está orientado a

aplicaciones que necesitan un balance entre expresividad completa y eficiencia, así como

aplicaciones RFS(S) que necesitan algo más de expresividad. El razonamiento puede ser

implementado mediante motores de razonamiento basados en reglas. La consistencia de la

ontología, la subsunción y satisfabilidad de las clases, la comprobación de instancias, y la

resolución de resolver consultas conjuntas se resuelve utilizando algoritmos de razonamiento

de tiempo polinómico respecto al tamaño de la ontología.

Como se ha indicado previamente, OWL2 extiende a OWL por lo que tiene una estructura muy similar

(el uso de RDF/XML como sintaxis principal, las semánticas utilizadas, el teorema que relacionada

ambas semánticas, etc.). Además, existe una compatibilidad total entre OWL y OWL2, por lo que


84

todas las ontologías OWL siguen siendo válidas en OWL2. No obstante existen ciertas diferencias

entre ambos lenguajes:

- OWL2 añade nuevas funcionalidades que permiten aumentar el grado de expresividad, como

por ejemplo, incluye claves, soporte de mayor número de tipos de datos, rangos de datos

más ricos, restricciones de cardinalidad, propiedades de asimetría, reflexividad y disyunción,

y mejora la capacidad de notación.

- OWL2 define nuevas sintaxis de intercambio y hay mayor número de razonadores que lo

soportan.

- Ambos lenguajes se basan en lógica descriptiva (DL), que permite describir elementos y sus

relaciones, y cuyo objetivo es dotar al lenguaje de la mayor expresividad posible sin perder

decidibilidad. Pero mientras OWL se basa en SHOIN (D), OWL2 se basa en DL SROIQ (D),

con mayor poder expresivo.

3.2.6 Resumen comparativo y conclusiones

Los lenguajes de definición de ontologías permiten la representación uniforme de dominios

conceptuales. Con estos lenguajes se obtiene la expresividad y facilidad para la representación de los

conceptos de las que carecen las taxonomías. Además, favorecen la reusabilidad de las ontologías,

ya que cualquier ontología creada anteriormente puede ser referenciada y reutilizada desde otra

ontología, reduciendo así el tiempo de desarrollo de nuevas ontologías. En esta sección, se han

analizado los principales lenguajes de ontologías existentes, prestando especial interés a aquellos

pertenecientes a la Web Semántica.

La elección de uno u otro lenguaje para la formalización de los recursos del presente trabajo de

investigación es una tarea compleja que hay que realizar de forma precisa, puesto que la eficacia del

sistema de respuesta dependerá en cierta medida del lenguaje elegido. En la elección de un lenguaje

se deben tener en cuenta 4 rasgos del mismo: nivel de expresividad que se alcanza con el lenguaje,

mecanismos de inferencias asociados al mismo, herramientas que lo soportan e intercambio entre

aplicaciones. Del análisis realizado se han extraído las siguientes conclusiones, teniendo en cuenta

que OWL incluye en principio tanto OWL como OWL2:

Debido al gran impulso e importancia de la Web Semántica se cree conveniente elegir un

lenguaje de los denominados “Lenguajes de la Web Semántica”, por lo que SHOE quedaría,

en un principio, descartado, por ser un lenguaje anterior a ella.

OWL y RDFS son los lenguajes más extendidos para describir ontologías.

OIL y DAML+OIL han evolucionado para dar lugar a OWL, por lo que podríamos

considerarlos como lenguajes en desuso en sustitución de OWL. Por ello, quedarían

descartados.

RDF es el lenguaje sobre el que se construyen el resto (RDFS, OIL, DAML+OIL, OWL).

Además su semántica tiene poca estructura obligando a introducir gran cantidad de

aserciones para capturar información similar a la que ya capturan RDFS o OWL.

OWL posee mayor poder expresivo que RDF.

La sintaxis de OWL es RDF/XML, lo que permite la incorporación automática de vocabularios

para la descripción de datos como RDFS o Dublin Core.

OWL está diseñado para usarse cuando la información contenida en los documentos necesita

ser procesada por programas o aplicaciones, y no solamente ser presentado a seres

humanos.


85

OWL posee más funcionalidades para expresar el significado y semántica que XML, RDF y

RDFS, además de permitir representar contenido de la Web interpretable por máquina, a

diferencia de los demás.

OWL tiene asociados lenguajes de razonamiento suficientemente contrastados como KAON2

o SWRL.

La mayoría de las herramientas y aplicaciones de la Web Semántica soportan OWL.

A partir de las conclusiones extraídas, se considera que OWL y OWL2 son la mejor opción como

lenguajes de especificación de recursos para su uso en este trabajo de investigación. A pesar de que

la estructura de ambos lenguajes es muy similar, hay una serie de ventajas de OWL2 sobre OWL,

como se ha indicado previamente: OWL2 permite alcanzar mayor nivel de expresividad que OWL

(proporciona mayor soporte de tipos de datos, tiene mayor número de axiomas, incluye restricciones

de cardinalidad y propiedades de asimetría, reflexividad y disyunción, etc.) y el número de

razonadores semánticos que lo soportan es mayor. Dentro de las versiones de OWL2, la elección

dependerá del tipo de razonamiento requerido y el nivel de expresividad.

No obstante, las ontologías definidas en OWL son totalmente compatibles con OWL2 por lo que el

uso de OWL también es válido para especificar la ontología propuesta.

3.3 Lenguajes de especificación del comportamiento

En el apartado anterior dedicado a los lenguajes de especificación de ontologías se ha llevado a cabo

un breve estudio sobre los lenguajes de ontologías más relevantes y sus características principales.

La utilización de estos lenguajes como lenguajes formales para la representación de conocimiento y

especificación de información en los sistemas de respuestas a intrusiones, aporta ventajas como la

orientación a objetos, la reutilización de información, la disponibilidad de herramientas, la fácil

extensibilidad, etc. No obstante, ya se indicó en la introducción correspondiente a este capítulo que

para un sistema de respuesta es esencial además de la capacidad de poder representar

conocimiento, la capacidad de representar reacciones frente a eventos, por lo que se necesitan

lenguajes de especificación del comportamiento que puedan ser interpretados en conjunción con los

conceptos representados en las ontologías.

Por ello, se ha valorado la posibilidad de ir más allá de la representación del conocimiento e incluir en

las ontologías de respuestas a intrusiones la definición de restricciones, reglas y políticas de

seguridad, que permitan la definición del comportamiento de los agentes implicados. De esta forma,

el comportamiento de los agentes podría ser expresado de una manera formal mediante ontologías,

lo que implica que se podría trabajar y razonar con ellas.

La forma de expresar restricciones sobre la información modelada o reglas en un lenguaje de

ontologías es mediante axiomas. Los axiomas pueden ser de varias clases, por ejemplo, axiomas de

subclase, axiomas de equivalencia de clases, axiomas de igualdad o desigualdad de ejemplares,

intersección o unión de clases, restricciones sobre propiedades, etc. En el ámbito de la Web

Semántica, el lenguaje OWL2 incorpora muchos de estos tipos de axiomas, pero la necesidad de

representar lo más fielmente posible los modelos abstractos sobre los que se definen estos lenguajes,

hace que surjan nuevas necesidades de axiomas que permitan aportar mayor información sobre la

información modelada. Por ello, se propone la integración de lenguajes de especificación de

restricciones lógicas, para cumplir los siguientes requisitos [Guerrero07]:

Crear un nivel de reglas por encima de las ontologías y que se integre semánticamente de

forma coherente y potente. Este nivel permite crear reglas que se refieren a los elementos de

información de las ontologías y razonar con ellos.

Mejorar la capacidad de las ontologías para realizar consultas sobre ejemplares (solicitar

ejemplares que cumplan determinadas condiciones).


86

Integración de datos. La mayoría de los datos residen en bases de datos relacionales. Existen

muchos programas lógicos, escritos en lenguajes de reglas que permiten inferir condiciones a

partir de una información dada, que interaccionan bien con los elementos de dichas bases de

datos, pero sin embargo las ontologías no, ya que necesitan replicar la información en el

lenguaje de ontologías. Por tanto, una implementación de un lenguaje de ontologías basada

en un programa lógico puede permitir una interacción más cercana con los elementos de las

bases de datos.

Creación de los Servicios de la Web Semántica: mientras que las ontologías son útiles para

representar clasificaciones jerárquicas de los servicios, sus entradas y sus salidas, las reglas

son útiles para representar políticas o relaciones entre precondiciones y post-condiciones.

OWL2 permite expresar ciertas restricciones incluyendo relaciones usando cadenas de propiedad,

funcionalidad que no está soportada en OWL, pero todavía no puede expresar relaciones entre

individuos referenciados por propiedades, entre otras restricciones. Por ello, se requiere el uso de

lenguajes de reglas o políticas basados en lógica de primer orden (FOL, First Order Logic), que

permitan expresar más restricciones lógicas que los lenguajes de definición de ontologías. Estos

lenguajes además de especificar comportamiento, permiten la definición de políticas o reglas de

seguridad.

Algunos de estos lenguajes de especificación de restricciones lógicas de la Web Semántica son

SWRL, KaOS, REI y OWL-Services. Estos lenguajes tienen en común que se basan en OWL como

lenguaje de especificación de ontologías, por lo que han heredado una serie de características de

OWL, como la orientación de objetos o la posibilidad de distribución de las ontologías.

En este apartado se pretende realizar un análisis de diferentes lenguajes de definición de reglas,

restricciones y comportamiento, destacando sus principales características y objetivos.

3.3.1 RuleML

RuleML [RuleML] es un lenguaje de etiquetas estándar para la definición, publicación e intercambio

de reglas en la Web Semántica. Está basado en XML/RDF, y su núcleo es el sublenguaje Datalog

(intersección de SQL y Prolog). RuleML utiliza la sintaxis XML para la definición de reglas.

RuleML permite la representación del conocimiento, combinando hechos y reglas. Las reglas que se

pueden definir con RuleML son de varios tipos:

Reglas de producción: implicaciones (if – then).

Reglas reactivas: reglas que realizan acciones cuando se cumple un evento o se dan unas

determinadas circunstancias (evento-condición –acción).

Reglas de integridad: afirmaciones que se deben cumplir en cualquier estado del sistema.

Reglas de derivación: reglas para definir conceptos derivados a partir de otros (implicación-

inferencia).

Reglas de transformación: reglas creadas a partir de un llamador, una condición y una

transformación.

Las principales ventajas de RuleML son las siguientes:

- Permite definir diferentes tipos de reglas.

- Está soportado por gran parte de los motores de inferencia y aplicaciones que manejan

reglas, independientemente del mecanismo de inferencia utilizado por estas.

- Permite el intercambio de reglas entre aplicaciones.


87

Pero en contrapartida presenta un gran inconveniente, y es que no está pensado para su uso

combinado con OWL ni OWL2, además de que tiene limitaciones a la hora de representar una base

de conocimiento porque no soporta bindings de variables.

3.3.2 SWRL

Semantic Web Rule Language, SWRL [Horrocks04], es un lenguaje de especificación de reglas de la

Web Semántica, basado en OWL y RuleML, cuyo objetivo es incrementar la expresividad de los

axiomas de OWL y OWL2 en cuanto a la especificación de restricciones y reglas. SWRL surge como

una integración de OWL DL y OWL Lite con los sublenguajes Unary/Binary Datalog de RuleML.

SWRL extiende el conjunto de axiomas de OWL, permitiendo así definir reglas de mayor

expresividad. Permite incluir axiomas de reglas, también llamados cláusulas de Horn. Usa Datalog,

sublenguaje de RuleML, para elaborar cláusulas de Horn en una base de conocimiento OWL. Aporta

un modelo teórico-semántico para incluir reglas en ontologías OWL/OWL2. Además, como sintaxis de

intercambio de información, se puede emplear una extensión de la sintaxis de OWL basada en XML

directamente, o una extensión de la sintaxis OWL-RDF/XML. Para profundizar más en la definición de

su sintaxis así como en su expresividad y otros rasgos, es aconsejable la lectura de su especificación

completa, [Horrocks04].

3.3.2.1 Elementos del Lenguaje

La semántica formal de SWRL es una extensión de la de OWL DL independiente de RDF/RDFS.

Básicamente, SWRL introduce un nuevo tipo de axiomas llamado regla. Cada regla está formada por

un antecedente (body) y un consecuente (head), y cada uno de ellos está formado por la conjunción

de diferentes átomos. A continuación se definen los principales elementos.

Axioma de Regla

Un axioma de regla consiste en un antecedente (cuerpo) y un consecuente (cabeza), cada uno de los

cuales está compuesto por un conjunto (puede ser vacío) de átomos. En la sintaxis de notación lógica

clásica de SWRL, una regla tiene la siguiente forma:

antecedente consecuente

De manera informal, una regla puede interpretar de la siguiente forma: siempre que las condiciones

especificadas en el antecedente se verifiquen, entonces se deben verificar también las condiciones

especificadas en el consecuente.

Supongamos que queremos definir una regla que afirme que las propiedades hasParent y hasBrother

implican hasUncle, es decir, se quiere definir la propiedad hasUncle. La regla se especificaría de la

siguiente forma, si se utiliza una sintaxis que sea comprensible por humanos:

hasParent(?x1,?x2) ∧ hasBrother(?x2,?x3) ⇒ hasUncle(?x1,?x3)

En la siguiente regla el antecedente establece que hay dos ejemplares (?x1 y ?x2) que están

relacionadas a través de la propiedad hasParent (?x1 tiene un padre que es ?x2), y además el

ejemplar ?x2 tiene un hermano ?x3, relacionados mediante la propiedad hasBrother. La regla

especifica que siempre que se cumpla el antecedente, se cumple el consecuente, que implica que

?x3 es tío de ?x1 (propiedad hasUncle). Por tanto, si un ejemplar “Padre” tiene un ejemplar “Hijo” y

otro ejemplar “Hermano”, implica que el ejemplar “Hermano” es tío del ejemplar “Hijo” (están

relacionados a través de la propiedad hasUncle).

Una regla SWRL tiene por tanto la forma de una relación de implicación entre la cabeza y el cuerpo.

En el consecuente sólo pueden aparecer variables que han aparecido en el antecedente. Esta

condición, llamada condición de seguridad, es muy importante, ya que obliga a que sólo se puedan

extraer conclusiones sobre información ya presente.


88

La especificación de SWRL ofrece una sintaxis abstracta que extiende la sintaxis abstracta de OWL

para incluir esta nueva relación en el lenguaje de ontologías. Las marcas XML que permiten describir

estas reglas incluyen:

<ruleml:imp>: Es el elemento que permite relacionar el cuerpo de la regla con la cabeza.

<ruleml:_body>: Es el elemento que lista los átomos del cuerpo de la regla.

<ruleml:_head>: Es el elemento que lista los átomos de la cabeza de la regla.

<ruleml:var>: Permite definir las variables sobre las que evaluar las reglas.

<swrlx:individualPropertyAtom>: Permite definir átomos referidos a propiedades concretas.

También es posible definir átomos referidos a clases, rangos de datos, propiedades valuadas,

o funciones propias de tipo matemático, cadenas de caracteres o fechas.

Como se ve, muchas de estas marcas no están definidas dentro del espacio de nombres de SWRL,

sino de RuleML, un lenguaje de reglas definido con anterioridad que se ha tomado como base en la

definición de SWRL. La regla del ejemplo anterior, expresada en la sintaxis XML Concrete Syntax

(combinación de la sintaxis XML de OWL y la sintaxis XML de RuleML) se muestra en la siguiente

figura:

Figura 3.5 Regla SWRL expresada en sintaxis XML Concrete Syntax.

SWRL aporta sobre todo la definición de los átomos y su integración dentro de una ontología escrita

en OWL/OWL2. De esta manera, en el caso concreto de los sistemas de respuesta, estos pueden

contener una representación conceptual del conocimiento necesario en OWL, y unas reglas de

comportamiento asociadas en SWRL, que son interpretadas y validadas por un sistema experto en

tiempo de ejecución.

Átomos

Los átomos son predicados con la forma C(x), P(x,y), sameAs(x,y), differentFrom(x,y), o builtIn(r,x,...)

donde C es una clase o tipo de datos en OWL/OWL2, P es una propiedad en OWL/OWL2, r es una

relación built-in (pre-programada), y x e y pueden ser tanto variables, como ejemplares en

OWL/OWL2, como valores de tipos de datos. Por lo tanto para construir átomos se pueden emplear

variables. Estas equivalen al cuantificador universal, pudiendo sustituirse por ejemplares.

En SWRL existen diferentes tipos de átomos, que pueden expresar entre otras cosas: pertenencia de

un ejemplar (puede emplearse una variable en su lugar) a una extensión de clase, pertenencia de un

literal a un datatype enumerado de OWL DL, relación entre dos ejemplares de tipo objeto a través de

una propiedad de tipo ObjectProperty, relación entre un ejemplar de tipo objeto (en la posición de


89

sujeto) y un literal (en la posición de objeto) a través de una propiedad de tipo DatatypeProperty, o

igualdad y desigualdad entre dos ejemplares.

Built-Ins

Un elemento muy importante del lenguaje SWRL son los denominados built- ins, que no son más que

elementos de SWRL que permiten realizar diferentes operaciones sobre diferentes tipos de datos de

XML Schema:

- Comparación: igualdad, desigualdad, mayor que, menor que … El átomo se satisface si la

comparación también lo hace.

- Operaciones matemáticas: suma, resta, producto, división, seno, coseno, etc. El átomo se

satisface si los elementos de la operación (todos, incluyendo el resultado) la satisfacen.

- Negación lógica: se satisface si un argumento es igual a la negación lógica de otro.

- Operaciones con cadenas de caracteres: concatenación, longitud de cadena, etc.

- Operaciones con fechas, tiempo y duraciones temporales.

- Operaciones con URIs.

- Operaciones con listas.

Los elementos de los átomos sobre los que se aplican las operaciones deben ser variables,

ejemplares o literales.

3.3.2.2 Interpretación formal de la semántica de SWRL

La interpretación formal de la semántica de SWRL es la siguiente:

- Una interpretación satisface una ontología OWL/OWL2+SWRL si satisface la ontología

OWL/OWL2 según la semántica formal de éste y además satisface las reglas SWRL.

- Una interpretación satisface una regla SWRL si para todo enlace que satisface el antecedente

se satisface también el consecuente. Dada una interpretación OWL/OWL2, un enlace es una

extensión de ésta que se construye sustituyendo una variable por un ejemplar.

- Las definiciones de consistencia e inferencia son coherentes con las de OWL/OWL2.

- Si el antecedente está vacío, se interpreta como trivialmente cierto: el consecuente debe

cumplirse siempre (hechos incondicionales). Muchos de estos hechos es mejor expresarlos

mediante hechos en OWL/OWL2, ya que son explícitos.

- Si el consecuente está vacío, se interpreta como trivialmente falso, es decir, que el

antecedente no debe cumplirse nunca.

Dada una ontología consistente con una serie de axiomas. Si añadimos reglas SWRL sobre esta

ontología, se está añadiendo nueva información de forma implícita, de tal forma que:

Si esta información implícita entra en conflicto con la información de la interpretación de

interés, la ontología resultante de la combinación de OWL con SWRL ya no es consistente.

Si esta nueva información no entra en conflicto con la preexistente, la nueva ontología

satisface la interpretación de interés y es consistente. Además, pueden pasar dos cosas:

Que esta nueva información realmente no sea nueva, coincidiendo con otra

información definida mediante OWL explícitamente. En este caso, SWRL sirve para

comprobar que ciertos axiomas o restricciones se cumplen.

Que esta nueva información no coincida con información explícita de OWL, sino que

nos esté diciendo cosas adicionales. Esta nueva información no está representada de

forma explícita en la ontología, no se plasma en axiomas de ontologías como tales,


90

sino que se expresa de forma implícita: la interpretación debe satisfacer estas

restricciones implícitas, aunque luego la ontología no las refleje de forma explícita. La

única forma de que esta información implícita capaz de terminar con la consistencia

de una ontología o de expresar nuevos axiomas se especifique de forma explícita es

que se cree una nueva ontología que añada explícitamente (axiomas OWL) esta

información, de tal forma que esta nueva ontología se ha inferido de la anterior.

Como conclusión, podemos decir que OWL/OWL2 permiten expresar información de forma explícita,

mientras que SWRL lo hace de forma implícita, y la única forma de explicitarla es mediante consultas

e inferencias.

3.3.2.3 Expresividad y otras características

Algunas de las reglas que pueden construirse con SWRL también pueden crearse con OWL, pero el

ámbito de expresividad de SWRL es mucho mayor, ya que permite definir restricciones que no es

posible con OWL o RDF. Algunas de las características más importantes de SWRL son:

- SWRL permite definir condiciones complejas a cumplir en el antecedente mediante el uso de

built-ins, el operador AND, y los átomos referidos a propiedades concretas, a clases y

relaciones entre ellas, a rangos de datos, a propiedades, a funciones matemáticas, cadenas

de caracteres o fechas. El uso de variables en los átomos permite definir restricciones que no

son posibles en RDF o OWL.

- Fórmulas lógicas de primer orden: en lógica de primer orden, una cláusula de implicación

puede incluir el uso de operadores básicos tanto en el antecedente como en el consecuente:

OR, AND, NOT, y otros derivados como XOR, etc. Ello permite la definición de fórmulas

arbitrarias con cualquier composición de expresiones (p.e.: A OR (B AND NOT C) AND (D

OR C)). Sin embargo, SWRL no incluye los operadores NOT ni OR para la definición de los

átomos, lo que limita su expresividad. En el seno del W3C existe una propuesta de extender

SWRL para poder definir este tipo de fórmulas lógicas de primer orden llamada SWRL-FOL

[Patel-Schneider05], pero por el momento no es una propuesta muy difundida.

De todas formas, mediante determinadas transformaciones, es posible conseguir un grado de

expresividad casi tan alto como el de las reglas lógicas de primer orden. En el caso de la

condición de la regla SWRL, existe la posibilidad de conseguir expresar una regla con una

fórmula lógica de primer orden en el antecedente mediante varias reglas SWRL siguiendo

ciertas pautas recogidas en [Prieto06].

Las principales ventajas del lenguaje SWRL son:

- Nivel de abstracción alto.

- Lenguaje de reglas recomendado por la comunidad Web Semántica.

- Compatibilidad siguiendo la sintaxis OWL XML y RDF.

- Aumenta la capacidad de expresión de OWL para definir reglas y restricciones. Reglas

condicionales (cláusulas de Horn). SWRL permite definir condiciones complejas a cumplir en

el antecedente de las reglas, mediante los built-ins, el operador AND y la utilización de

átomos. El uso de variables en los átomos permite definir restricciones que no son posibles

en RDF o en OWL.

- Fácilmente integrable en editores de ontologías como Protégé. Existen herramientas, como

un plugin de Protégé que permiten introducir los sistemas de reglas y reflejarlos en

información que se puede recuperar, utilizar y almacenar, además de definir la propia

ontología.

- Permite definir reglas más complejas y expresivas que otros lenguajes.


91

- Nivel de integración alto con ontologías definidas en OWL. No requiere la traducción entre los

elementos representados en la ontología y los conceptos manejados por el lenguaje. Puede

definir reglas directamente sobre elementos del modelo de información representado

mediante ontologías en OWL.

- No está limitado a lógica deóntica (políticas relacionadas con el deber y las normas), permite

la definición de todo tipo de reglas.

No obstante, también presenta ciertos inconvenientes:

- Limitado a clases OWL y predicados binarios.

- No incluye los operadores NOT ni OR para la definición de los átomos, lo que limita la

expresividad del lenguaje. Sí permite AND. No obstante, mediante algunas transformaciones,

es posible conseguir un grado de expresividad casi tan alto como el de las reglas lógicas de

primer orden, dividiendo la regla con una fórmula lógica de primer orden en el antecedente

mediante varias reglas SWRL.

- No permite especificar metainformación sobre las reglas (prioridades, ámbito de aplicación,

etc.), útil para gestionar las reglas remotamente y para el análisis de políticas y resolución de

conflictos.

- No permite representar eventos de forma explícita.

Debido a sus limitaciones en cuanto a la expresividad para especificar políticas de seguridad, surgen

otras aproximaciones basadas en ontologías para definir políticas de seguridad.

3.3.3 OWL-Services

OWL-Services [Martin04], es una ontología de servicios cuyo objetivo es describir formalmente

servicios web. Se pretende que los usuarios y los agentes software sean capaces de descubrir,

invocar, componer y monitorizar recursos web que ofrezcan servicios particulares con una serie de

propiedades determinadas. Además, permite que lo hagan con un grado de automatización alto.

Gracias a esta formalización es posible lograr esa deseada automatización en los distintos procesos

de interacción entre agentes de usuario y proveedores de servicios. OWL-S proporciona un

vocabulario en OWL apto para estas descripciones, y este vocabulario puede ser utilizado

conjuntamente con los mecanismos de OWL. OWL-Services constituye un lenguaje de especificación

de servicios web, con una sintaxis formal y una semántica construida sobre la semántica formal de

OWL.

Los objetivos que se pretenden alcanzar con el desarrollo y uso de OWL-Services son los siguientes

[Martin04]:

- Descubrimiento automático de servicios web: localización automática de servicios que,

gracias a sus capacidades, permitan satisfacer una serie de necesidades. Para ello, es

necesaria la descripción formal de los servicios ofrecidos y sus capacidades, de modo que los

agentes puedan interpretarla y valorar si responden o no a las necesidades del usuario. OWL-

Services permite dicha descripción.

- Invocación automática de servicios web: la invocación automática exige una descripción

formal de cómo debe llevarse a cabo ésta, que podría ser mediante llamadas a

procedimientos remotos. OWL-Services permite describir las primitivas de invocación,

además de permitir al agente de usuario leer automáticamente la descripción de las entradas

y salidas de los servicios web e invocar al servicio.

- Composición y operación conjunta automática de servicios web: En una web donde están

disponibles varios servicios, sería interesante realizar tareas complejas que impliquen la

invocación coordinada de varios servicios web. Esto exige describir los prerrequisitos y


92

consecuencias de la aplicación de servicios. OWL-Services proporciona vocabulario apto

para ello.


La ontología OWL-Services define tres clases de nivel superior: ServiceProfile (describe el perfil del

servicio, qué proporciona el servicio a los clientes), ServiceModel (describe el modelo del proceso,

cómo se utiliza el servicio, qué debe hacer un cliente para solicitar y usar el servicio) y

ServiceGrounding (describe cómo se interacciona con el servicio, describiendo por ejemplo, el

formato de los mensajes, detalles protocolos de comunicación y transporte, número de puertos,

primitivas de servicio…). Cada una de las clases se desglosa en una serie de componentes.

El perfil del servicio se describe en términos de parámetros de entrada y de salida, precondiciones,

resultados y categoría de servicio. Los procesos concretos de cada servicio lo hacen mediante

parámetros de entrada y de salida, precondiciones, resultados y participantes. Para representar

parámetros se pueden utilizar variables, empleándose una extensión de las variables de SWRL, y

para describir precondiciones y resultados se utilizan fórmulas lógicas o expresiones que utilizan

como parámetros las variables de entrada y de salida. Dichas expresiones pueden representarse de

forma integrada en la ontología mediante algún lenguaje o formato estándar como KIF, pero también

es posible utilizar simplemente literales RDF, de modo que el contenido de las mismas es

transparente para los intérpretes de OWL. Existen numerosas propuestas para representar fórmulas,

pero hay que destacar que realmente OWL no se adapta demasiado bien a este propósito, ya que su

objetivo es describir de una forma más estática conceptos y relaciones, no fórmulas que detallan

procesos.

Los procesos, una vez definidos, se componen para formar servicios compuestos mediante diferentes

mecanismos: secuencia, concurrencia, concurrencia con barrido sincronizado, alternativas choice,

estructuras if-then-else, y bucles.


En el mundo de la Web Semántica se persigue el objetivo de logar un acceso más amplio no sólo a

los contenidos, sino también a los servicios web. El objetivo de OWL-S es automatizar este acceso a

los servicios o recursos web, mediante la definición formal tanto de los servicios como de los

procesos que los componen. OWL-S constituye un metamodelo o lenguaje de especificación de

servicios web, con una sintaxis formal y una semántica construida sobre la semántica formal de OWL.

OWL-Services permite describir servicios atómicos o simples y servicios complejos. La capacidad

descriptiva de OWL-Services permite describir procesos y flujos tan complejos como los descritos por

lenguajes procedimentales. No obstante, se trata de descripciones de los servicios, no de código

ejecutable.

En [LopezDeVergara05] se mencionan las ventajas de aplicar las ideas de la ontología OWL-S a un

entorno de gestión de redes y servicios. Mediante la integración de condiciones en SWRL como

precondiciones y postcondiciones, OWL-S permite realizar una potente descripción semántica de

políticas.

3.3.4 KAoS

Knowledge-able Agent-oriented System, KAoS, es una propuesta del IHMC (Institute for Human and

Machine Cognition) de la Universidad de Florida Oeste, que surge como marco de modelado de

servicios basados en políticas [Bradshaw03]. El principal objetivo y propósito de KAoS es controlar de

una forma flexible el comportamiento de los distintos agentes que intervienen en entornos distribuidos

y abiertos, y en plataformas multiagente, como puede ser la utilización de servicios web de la Web

Semántica. Además, KAoS pretende dar una respuesta a los desafíos planteados por los requisitos


93

emergentes de aplicaciones semánticas para las infraestructuras, especialmente en el área de la

seguridad y gestión de confianza.

Tal y como se señala en [Guerrero07], KAoS propone un entorno completo para definir e implantar

políticas que especifican cómo pueden y deben actuar los diferentes agentes que participan en las

aplicaciones indicadas y en otro tipo de sistemas distribuidos.

La filosofía y los conceptos generales que caracterizan a KAoS encajan en el paradigma de gestión

basada en políticas. El entorno propuesto por esta propuesta incluye una serie de elementos que a

continuación se enumeran:

Ontología de políticas KAoS o KAoS Policy Ontology (KPO): ontología que define una serie

de elementos para describir políticas, en principio aplicables a cualquier dominio descrito

mediante ontologías, que pueden ser tanto de obligación como de autorización. Esta

ontología es un lenguaje de especificación de políticas, primero basado en DAML y

posteriormente en OWL.

Arquitectura de ejecución de políticas: entorno compuesto por una serie de sistemas y

protocolos cuya función es ejecutar las políticas especificadas. Los componentes de esta

arquitectura son:

Gestor de Políticas, KPAT (KAoS Policy Administration Tool): herramienta de

administración de políticas que permite la carga de ontologías que describen el

dominio, la edición de políticas (mediante una GUI), el análisis de conflictos, la

distribución de las políticas, etc.

Directorio de servicio KAoS (KAoS Directory Service): repositorio de políticas donde

se albergan las políticas de forma centralizada.

Puntos de ejecución de las políticas (PEPs): los enforcers o forzadores de políticas

en los recursos gestionados.

Puntos de Decisión (PDPs): los Guards reciben las políticas que a un nivel superior

se decide que le conciernen, y pueden limitarse a distribuir estas políticas a los

distintos agentes o pueden participar en dicho proceso.

En la Figura 3.6 se observa el esquema de entorno propuesto por KAoS.


94

Figura 3.6 Arquitectura del entorno KAoS [Guerrero07]


La KPO es una ontología OWL DL que define un metamodelo de especificación de políticas y una

serie de conceptos comunes para los distintos modelos de información posibles. El metamodelo

define cómo deben especificarse las reglas de comportamiento y los elementos del dominio sobre los

que se aplican dichas reglas. De esta manera, es posible especificar políticas importando la KPO y

las ontologías que definen el dominio concreto, con lo que el lenguaje de especificación de políticas

debe considerarse constituido por OWL y la KPO.

Las políticas de obligación son de tipo if <condición> then <accion>, y pueden ser tanto positivas (qué

hay que hacer) como negativas (qué no hay que hacer). Es posible definir restricciones con respecto

a estas políticas. Dichas restricciones se caracterizan por un intervalo de aplicación relativo a la

ejecución de la acción, y pueden ser de diversos tipos, según cuándo empiecen a aplicarse y cuándo

terminen: precondiciones (se aplican antes de la ejecución de la acción), postcondiciones (se aplican

después) u otras combinaciones. Además de políticas de obligación, la KPO permite expresar

políticas de autorización.

Dentro de la ontología KPO, se distinguen dos tipos de ontologías: ontologías que modelan el dominio

y conceptos generales del metamodelo (definen entidades, tipos de entidades, sus características, los

actores que participan en una política, etc.), y ontologías que definen elementos más concretos de las

políticas (situación y condición de aplicación de las políticas, acciones y características de dichas

acciones como tipos, estado e historia de las mismas, y elementos de las reglas).


KAoS explota las características de OWL, es decir, la lógica descriptiva, para describir y especificar

políticas y condiciones de contexto, que se expresan mediante ontologías, por lo que es capaz de

clasificar y razonar tanto sobre los agentes del entorno como sobre la ontología de políticas, y de

detectar conflictos de forma estática en cuanto se definen las políticas. Aunque el hecho de utilizar

OWL dificulta la definición de ciertos tipos de políticas, especialmente aquellas que requieren de la

definición de variables.

Es un lenguaje rico en elementos auxiliares, como las marcas de tiempo y los estados de condición y

acción (que se utilizan para controlar la implantación de las políticas), los actores, los sitios de forzado


95

de políticas y las prioridades (útiles para controlar la aplicabilidad de las políticas, necesario para

distribuir las políticas a los guardas y útil para el análisis de conflictos), etc. Estos elementos permiten

especificar metainformación sobre las reglas útil para gestionarlas remotamente.

KAoS distingue entre restricciones de obligación y condiciones. Entre las restricciones destacan las

precondiciones, que se distinguen de las condiciones en que están íntimamente asociadas a las

acciones y sus detalles, mientras que las condiciones tratan de describir la situación de aplicación de

las políticas de manera más general. Es decir, las condiciones pueden expresarse sin necesidad de

conocerse las acciones, mientras que las precondiciones dependen de estas últimas.

Entre las desventajas de KAoS en cuanto a expresividad, se encuentra, por ejemplo, el hecho de que

este lenguaje no permite expresar eventos de forma explícita. Tampoco incluye elementos para

especificar restricciones y potenciar la inferencia de información.

Además, su expresividad es algo limitada en la definición de políticas, ya que al estar basado en

restricciones de OWL, está restringido a políticas que no requieran el uso de parámetros variables.

KAoS tiene la capacidad de importar ontologías de cualquier tipo de dominio en OWL, pero requiere

de su traducción a los conceptos manejados por KAoS, lo que supone reducir su capacidad de

integración. Además, se limita a políticas con lógica deóntica, es decir a políticas relacionadas con el

deber y las normas: autorizaciones, denegaciones, etc., y requiere un motor de inferencias particular

(Motor de inferencia KAoS).

3.3.5 REI

El lenguaje de definición de políticas REI ([Kagal02], [Kagal04]) surge en la Universidad de Maryland

con un propósito similar a KAoS, controlar de forma flexible el comportamiento de los distintos

agentes que intervienen en entornos distribuidos y abiertos, sobre todo la seguridad.

El marco de especificación de políticas REI proporciona [Tonti03]:

- Un modelo de especificación de políticas independiente del dominio, que puede concretarse

en predicados Prolog o en una ontología. Dicho modelo permite además de expresar

políticas, expresar también metainformación sobre éstas (cómo se gestionan remotamente) e

información útil para el análisis de políticas y resolución de conflictos, mediante la gestión de

casos de uso y el análisis what-if.

Un motor de inferencias que permite razonar con las políticas, determinando su aplicabilidad

y realizando análisis de conflictos y consultas.


La ontología REI se basa en OWL Lite, y permite definir políticas de autorización positiva, negativa y

de obligación con respecto a dominios modelados mediante RDF, DAML+OIL y OWL. Dichas políticas

se caracterizan por tres elementos: un contexto o dominio de aplicación, un objeto deontológico que

define una prohibición, autorización, obligación o dispensación, y un conjunto de elementos de

metainformación, como pueden ser la especificación de un comportamiento por defecto, una

modalidad por defecto, o la prioridad relativa entre objetos deontológicos.

Los objetos deontológicos agrupan los principales elementos de las políticas. La existencia de estos

objetos tiene como fin separar lo que es en sí la regla pura (el propio objeto deontológico

caracterizado por una acción, un actor y un conjunto de restricciones) del dominio de aplicación y otra

metainformación que aparece en la política. Sin embargo, un objeto deontológico no se considerará

una regla activa hasta que no se asocie a alguna política.

Al igual que KAoS, se distribuye en una serie de ontologías: ReiPolicy (definición de las políticas),

ReiMetaPolicy (metapolíticas que gobiernan cómo se fuerzan las políticas, orientadas a la resolución

de conflictos), ReiEntity (representación de entidades), ReiDeontic (representación de objetos

deontológicos: permisos, prohibiciones, obligaciones y dispensaciones), ReiAction (tipos de


96

acciones), ReiConstraint (restricciones) y ReiAnalysis (análisis de políticas en gestión de casos de

uso y análisis what-if.


REI es un lenguaje orientado a la realización de inferencias y automatización de reglas. Es un

lenguaje rico en la posibilidad de expresar y reutilizar restricciones asociadas a la acción, al actor, a la

regla, etc. Pero el uso de OWL Lite y el mecanismo propuesto basado tan sólo en expresiones lógicas

AND y OR hace que su expresividad esté bastante limitada.

REI no permite representar eventos de forma explícita, salvo aquellos que indican la hora de

aplicación de las acciones, ya que el lenguaje tiene un alto nivel de abstracción.

Existen diversas metapolíticas que permiten realizar análisis sobre las propias políticas, útiles para la

resolución de conflictos y para la anticipación del resultado ante otras situaciones, y existen también

acciones para la gestión de las propias políticas. Las inferencias se realizan a nivel de REI, gracias a

la semántica formal de las políticas, definidas sobre OWL.

Otras metapolíticas permiten describir aspectos como el comportamiento por defecto, la modalidad

por defecto, la precedencia de una u otra de las anteriores y las reglas que establecen prioridades

relativas entre políticas. Otras serían las reglas que establecen prioridad entre las propias

metapolíticas.

3.3.6 Otros lenguajes de especificación del comportamiento

Además de los lenguajes de especificación del comportamiento analizados, existen otros lenguajes

de reglas que es necesario nombrar:

- SWSL (Semantic Web Services Language, [Battle05] y [Garbajosa07]): lenguaje basado en

lógica cuyo objetivo es especificar caracterizaciones formales de conceptos y descripciones

de servicios web. No es un simple lenguaje de definición de reglas. Está formado por dos

sublenguajes:

SWSL-FOL: lenguaje de lógica de primer orden, usado para definir la especificación

formal de la ontología del servicio. Se estructura en varios niveles independientes,

cada uno de los cuales aporta nuevas características que aumentan la potencia del

lenguaje. Los niveles no se organizan en base al poder expresivo y a la complejidad

computacional, como en OWL.

SWSL-Rule: lenguaje basado en reglas, que se puede usar como lenguaje de

especificación y como lenguaje de implementación. Este lenguaje está dividido en

varios niveles independientes organizados como SWSL-FOL, y se basa en cláusulas

de Horn, de la forma “cabeza :- cuerpo”. Las capas o niveles en los que se divide el

sublenguaje son: Mon LT (permite disyunción en el cuerpo y conjunción e implicación

en la cabeza de las reglas), NAF (permite negación en el cuerpo), Nommon LT

(permite cuantificación e implicación en el cuerpo), Corteous (introduce negación

clásica y priorización de reglas), HiLog (añade cierto grado de metaprogramación,

permitiendo variables que extienden de símbolos de predicados, fórmulas o

funciones), Frame (introduce orientación a objetos) y Equality (introduce el predicado

de igualdad).

SWSL-FOL y SWSL-Rule no pueden usarse conjuntamente, por lo que SWSL sirve como

puente entre ellos. SWSL-Rule contiene sintácticamente toda la conectividad con la lógica de

primer orden que proporciona SWSL-FOL, aunque semánticamente son incompatibles.

Este lenguaje tiene la ventaja de que permite la creación y procesamiento de servicios Web

utilizando semántica basada en ontologías y es similar a otros sistemas de reglas e inferencia

como por ejemplo Prolog, en cuanto a la definición de reglas. Por el contrario, es un lenguaje


97

en fase de desarrollo (se espera su extensión mediante la incorporación de sentencias if-

then-else, restricciones, etc.) y muy complejo para usuarios noveles.

- WSML (Web Service Modeling Language, [Bruijn05]): lenguaje de representación de reglas

con forma “cabeza :- cuerpo”, enfocado a los servicios web semánticos, y compatible con

ontologías escritas en OWL. Está formado por varios sublenguajes que se diferencian

principalmente en el formalismo lógico en el que se basan: lógica descriptiva, lógica de primer

orden o lenguajes de programación basados en lógica. Estos sublenguajes son:

WSMLCore: corresponde con la intersección entre lógica descriptiva y cláusulas de

Horn, sin símbolos de funciones y predicado de igualdad, cubriendo sólo una parte de

OWL.

WSMLDL: extiende el anterior, ampliando la compatibilidad con OWL.

WSMLFlight: extiende WSMLCore, añadiendo funcionalidades para la programación

lógica, como restricciones, etc. Además incorpora un lenguaje de reglas (incluyendo

predicados de igualdad y negación), permitiendo llevar a cabo razonamiento sobre

las reglas definidas.

WSMLRule: extiende el anterior, mejorando la capacidad de definición de reglas.

WSMLFull: agrupa todas las variantes anteriores.

WSML es compatible con el lenguaje OWL, permite el intercambio de reglas con

implementaciones de reglas ya existentes, su sintaxis XML se basa en RuleML y solventa

ciertas limitaciones de SWRL. El gran inconveniente es que está limitado al campo de los

servicios Web.

- JESS [Jess]: motor de reglas y lenguaje de script escrito totalmente en Java. Se trata de un

motor de reglas pequeño, ligero y uno de los más rápidos. Inicialmente, Jess fue creado como

una copia Java de CLIPS, pero actualmente posee muchas características que los

diferencian.

Jess puede usarse como un lenguaje de descripción de reglas, que permite tanto la definición

de las reglas como la inferencia a partir de ellas, pero también admite su uso como un

lenguaje de programación de propósito general. Entre sus principales características como

lenguaje de reglas destacan que es un lenguaje de script poderoso, lo que da al usuario

acceso a todas las APIs de Java, y que se caracteriza por ser un lenguaje cuya filosofía de

funcionamiento es actuar en respuesta a entradas.

Presenta una serie de ventajas: es multiplataforma, con capacidad de funcionar como un

motor de reglas en combinación con la herramienta Prrotégé mediante el plugin JessTab, es

ampliamente utilizado en el desarrollo de sistemas expertos y es fácil de integrar en cualquier

aplicación. No obstante, presenta dos grandes inconvenientes: es un lenguaje lento, y no

adaptado a lenguajes como OWL, SWRL, etc.

- R2ML [Kaviani07]: lenguaje de reglas basado en XML con soporte para la definición de reglas

de integridad, reactivas, de producción y de derivación, cuyo objetivo es facilitar el

intercambio de reglas entre diferentes lenguajes y herramientas. Además del intercambio de

reglas entre diferentes lenguajes y herramientas, proporciona la capacidad de publicar reglas,

y obtener resultados a través de inferencia a cualquier sistema.

Básicamente, R2ML supone la integración de OCL, OWL, SWRL y RuleML. Actualmente, se

pueden traducir reglas R2ML automáticamente a un conjunto de lenguajes: F-Logic, Jess,

RuleML, Jena, Drools, SWRL, XMI, OCL.


98


En ciertos sistemas basados en ontologías, como por ejemplo un sistema de respuesta frente a

intrusiones, además de la capacidad de poder representar conocimiento es muy importante la

capacidad de representar reacciones frente a eventos, para lo que se necesitan lenguajes de

especificación del comportamiento que puedan ser interpretados en conjunción con los conceptos

representados en las ontologías.

Mediante el uso de estos lenguajes se da solución, entre otras cosas, al problema de la expresividad

de los lenguajes de ontologías como OWL, ya que permiten definir axiomas que aportan mayor

información sobre el dominio modelado y facilitan las labores de inferencia.

En esta sección se han definido y analizado de forma breve los lenguajes de reglas y políticas más

relevantes, resaltando sus principales características. Un lenguaje de definición de comportamiento

debe cumplir los siguientes requisitos [Garcia05]:

- Debe ser compatible con los lenguajes y formatos utilizados en el entorno de aplicación. En el

caso que nos ocupa, en la sección anterior se indicó la elección de OWL2 como el lenguaje

de definición de ontologías utilizado en esta tesis doctoral, por lo que el lenguaje de reglas

utilizado debe ser totalmente compatible con ontologías escritas en OWL2.

- Debe ser expresivo.

- Debe ser flexible, es decir, debe permitir introducir nuevos conceptos y definir nuevas reglas

de comportamiento.

- Debe permitir la especificación formal (comprensible por máquinas) de las reglas a pesar de

la complejidad o alto nivel de abstracción que puedan entrañar.

- Debe permitir su implantación, es decir, debe permitir que se reflejen en el comportamiento

del sistema de respuesta la aplicación de las reglas.

- Debe poseer interfaces bien definidas, sin ambigüedades que queden abiertas a la

implementación, y ser escalable.

Del análisis realizado, en cuanto al nivel de satisfacción de los requisitos anteriores, se pueden

extraer las siguientes conclusiones:

- RuleML no es un lenguaje pensado para su combinación con OWL por lo que se descarta

como lenguaje de definición de reglas. Además, es la base de SWRL, por lo que éste último

amplía sus principales características y funcionalidades.

- Los lenguajes SWSL, WSML y OWL-Services son lenguajes orientados a los servicios web

semánticos, por lo que no se adaptan por completo a las necesidades que requiere la

definición de reglas del sistema de respuesta definido.

- Jess es muy potente como motor de reglas. Como lenguaje de descripción de reglas no está

adaptado a OWL ni a OWL2, por lo que este lenguaje quedaría descartado. No obstante,

existe un plug-in para Protégé 3.3.1 que permite integrar el motor de reglas de Jess con una

ontología definida en OWL DL.

- R2ML es un lenguaje que permite intercambiar reglas entre diferentes lenguajes y

herramientas. Se podría considerar como un “traductor” de reglas definidas en distintos

lenguajes. No obstante, no se puede considerar como un lenguaje de reglas como tal, ya que

ninguna de los motores de reglas o razonadores semánticos utilizan este lenguaje.

El resto de lenguajes analizados, SWRL, KAoS y REI, satisfacen por completo los requisitos

especificados, por lo que cualquiera de ellos es totalmente válido para la representación de

comportamiento de un sistema de respuesta a intrusiones. Estos lenguajes presentan diferencias

relevantes, como se desprende de su análisis, tanto en la definición de los elementos propios del


99

lenguaje como a nivel de expresividad. Estas diferencias hacen posible su comparación en base a las

siguientes características:

- Nivel de interoperabilidad y nivel de integración con ontologías, entendiendo como integración

la capacidad del lenguaje para definir reglas o políticas directamente sobre los dominios de

ontologías.

- Nivel de expresividad: es deseable que tengan la expresividad suficiente para expresar

restricciones y relaciones lógicas sobre los datos y objetos de los modelos de información.

- Nivel de usabilidad, considerando esta como la existencia de herramientas para la

especificación de políticas o reglas, la existencia de motores de razonamiento compatibles

con los lenguajes, etc.

- Facilidad de uso.

En términos de nivel de integración con las ontologías OWL, SWRL surge con el objetivo de

extender la semántica de OWL, pero no se concibe como un simple parche de OWL, sino que en su

definición uno de los requisitos principales ha sido la integración completa con dicho lenguaje.

Además, ambos permiten manejar un modelo de información integrado semánticamente, por lo que

las reglas SWRL se pueden definir directamente sobre elementos del modelo de información

representados en ontologías OWL/OWL2.

Por su parte, KaOS y REI también pueden trabajar importando ontologías de cualquier tipo de

dominio en OWL, pero para ello, requieren de su traducción a los conceptos manejados por estos

lenguajes, como actores, entidades, etc., lo que implica un mayor grado de indirección en la

integración, y presenta mayores dificultades para la representación de políticas de bajo nivel en

dominios muy específicos.

Por tanto, en cuanto a nivel de integración, el lenguaje SWRL tiene una integración directa con

OWL/OWL2, a diferencia de REI y KAoS que requieren de un mapeo previo a los conceptos

manejados por el lenguaje (entidades, actores, roles, etc.). Además, SWRL no está limitado a

políticas con lógica deóntica como REI y KAoS (políticas relacionadas con el deber y las normas:

autorizaciones, denegaciones, delegaciones, etc.), y permite expresar otro tipo de condiciones y

relaciones sobre los elementos representados en la ontología.

En cuanto al nivel de expresividad, los lenguajes deberán tener expresividad suficiente como para

expresar restricciones de valor de los atributos (pertenecientes a un rango o a un conjunto discreto de

valores), relaciones entre los valores de los diferentes atributos cualitativas principalmente y

cuantitativas también, y precondiciones y postcondiciones de los métodos en caso de que existan.

En el caso del lenguaje SWRL, en este capítulo se indica que SWRL supera las limitaciones de OWL

en lo que a definición de restricciones se refiere. SWRL permite expresar restricciones en forma de

axiomas de regla gracias al uso de variables, restricciones que no son posibles mediante

características de OWL ni de OWL2. Pero SWRL posee algunas limitaciones en cuanto a su

expresividad aplicada a políticas de seguridad, como por ejemplo, SWRL no permite especificar

metainformación sobre las reglas ni elementos auxiliares, como pueden ser, prioridades, ámbito de

aplicación, estados de acción, etc., información útil para la gestión y análisis de políticas.

KAoS es un lenguaje basado en OWL que explota sus características. Desde el punto de vista de la

expresividad esto hace que tenga limitaciones a la hora de definir ciertos tipos de políticas, en

especial aquellas que requieren de la definición de variables, o aquellas que contienen restricciones

paramétricas. En contrapartida, KAoS es un lenguaje rico en elementos auxiliares (prioridades,

estados de condición y acción, marcas de tiempo, etc.), y distingue entre restricciones de obligación y

condiciones.

Por su parte, REI es un lenguaje que al igual que SWRL permite especificar restricciones que

requieran la definición de variables, característica no posible en OWL. Además REI también permite

especificar elementos auxiliares en la definición de las políticas.


100

En términos de nivel de usabilidad, SWRL tiene un mayor ámbito de aplicación en el entorno de la

Web Semántica que REI y KAoS, lo que hace que esté soportado por muchos entornos y

herramientas. A pesar de no ofrecer un modelo de forzado de políticas ni un motor de políticas propio,

el lenguaje SWRL está soportado por la mayoría de los razonadores semánticos existentes, como se

verá en la sección posterior.

El entorno REI incluye un motor de políticas que razona sobre las definiciones de políticas, que

acepta definiciones tanto en lenguaje REI como en RDF-S, consistentes con la ontología REI, pero al

igual que SWRL, no ofrece un modelo de forzado de políticas. El motor de inferencia se limita a

razonar sobre las políticas y responder a consultas.

KAoS tiene un entorno de políticas más completo, que incluye una interfaz gráfica que permite editar

políticas (KPAT), un repositorio de políticas con resolución de conflictos y consulta, y un mecanismo

de forzado de políticas.

En cuanto a la facilidad de uso, SWRL es un lenguaje de definición de reglas y no uno de políticas

como REI o KAoS. Los lenguajes de reglas son mucho más sencillos que los utilizados para

representar políticas, debido a que en estos últimos son necesarios mucho más elementos.

Como se observa, no se ha tenido en cuenta el lenguaje OWL-Services en el análisis comparativo

realizado. La razón es que es un lenguaje orientado a la especificación de servicios web, y no se

considera adecuado para especificar el comportamiento de un sistema de respuesta frente a

intrusiones. La siguiente tabla recoge los resultados más relevantes del análisis de una forma más

clara y esquemática:

Tabla 3.2 Análisis comparativo entre SWRL, REI y KAoS.

SWRL REI KAoS

Integración con OWL/OWL2 Directa Indirecta Indirecta

Restricciones con Variables Sí Sí No

Elementos auxiliares No Sí Sí

Herramientas que lo soportan Muchas (Web

Semántica) ------ ------

Motor de razonamiento

Razonadores

semánticos (Ver

3.4).13.4

Motor inferencia tipo

Prolog u otros Motor inferencia propio

Forzado de políticas Externo Externo Propio

Facilidad de uso Alta Media Media

De cara al sistema de respuesta propuesto, hay que tener en cuenta si es más conveniente la

sencillez y limitaciones (no utilización de elementos auxiliares en las reglas o no disposición de un

motor de forzado de políticas propio) de SWRL o la complejidad y potencia de REI y KAoS.

Además, como se ha indicado y se verá en el apartado posterior, el lenguaje SWRL está soportado

por la mayoría de los razonadores semánticos existentes.

3.4 Razonadores semánticos

Los lenguajes de representación de conocimiento permiten formalizar conceptos y representar la

ontología de un dominio de aplicación. Por su parte, los lenguajes de reglas basados en lógica de

primer orden permiten definir axiomas que expresan restricciones sobre la información modelada.

Ambos constituyen las llamadas bases de conocimiento. Una base de conocimiento está formada por

dos componentes:

- TBox: incluye toda la terminología y/o el vocabulario mediante el que se representa un

dominio de aplicación, es decir, los conceptos que denotan clases o conjuntos de individuos,


101

los roles que denotan relaciones binarias entre individuos y un conjunto de descripciones

complejas sobre este vocabulario.

- ABox: contiene aserciones acerca de individuos nombrados en términos de vocabulario.

Una base de conocimiento (TBox y ABox) es equivalente a un conjunto de axiomas de la lógica de

primer orden, y por tanto se puede definir un cálculo o sistema de inferencia que permite derivar

conocimiento implícito a partir del explícito de la base de conocimiento.

En un AIRS basado en ontologías es muy importante que, además de modelar el dominio de la

respuesta a intrusiones y definir un conjunto de reglas o políticas que se apliquen sobre dicho

dominio, se pueda razonar sobre él e inferir nueva información. Para ello, es necesario un mecanismo

que permita inferir información a partir del conocimiento almacenado en la base de conocimiento.

Este mecanismo son los razonadores semánticos.

Un razonador semántico también conocido como motor de razonamiento, motor de reglas o

simplemente razonador, es un componente software capaz de inferir consecuencias lógicas a partir

de un conjunto de hechos o axiomas en una base de conocimiento. El concepto de razonador

semántico engloba al de motor de inferencia, ya que proporciona un conjunto de mecanismos con los

que trabajar. Las reglas de inferencia son especificadas mediante lenguajes de definición de políticas,

como se vio en el apartado anterior.

En el ámbito de la Web Semántica existen diferentes razonadores capaces de inferir conocimiento

adicional. La principal diferencia entre ellos es el lenguaje de reglas que soportan y el mecanismo de

razonamiento utilizado, además de otras características funcionales, que determinan el rendimiento y

la eficiencia de cada razonador. Algunos de ellos utilizan predicados de la lógica de primer orden para

inferir nuevos hechos, otros son razonadores probabilísticos, como por ejemplo, el sistema de

razonamiento no axiomático de Pei Wang [Wang95], la red de lógica probabilística de Novamente

[Novamente] o el razonador de lógica de descripciones probabilístico Pronto [Klinov08].

Los razonadores utilizan principalmente uno de los siguientes tipos de razonamiento:

- Razonamiento deductivo, progresivo o forward chaining (FC): razonamiento también

denominado encadenamiento dirigido por hechos, basado en el modus ponens (evidencias,

síntomas, datos conclusiones, hipótesis), cuya entrada son las base de hechos, base de

reglas o los objetivos. En este método, se parte de un dato disponible en la base de hechos, y

a partir de él se extraen más datos usando reglas de inferencia hasta alcanzar una meta. Un

motor de inferencia que use forward chaining buscas las reglas de inferencia hasta que

encuentre una en la que se cumpla el antecedente (usando los datos de partida); ejecuta la

regla e infiere el consecuente. Consiste en aplicar reglas al conocimiento de la base de

hechos para obtener nuevos resultados. Dicho algoritmo de razonamiento podría entenderse

de la siguiente forma:

Este tipo de razonamientos se caracteriza porque es una deducción intuitiva, además de que

facilita la formalización del conocimiento al hacer un uso natural del mismo, por lo que puede

ser usado de manera exploratoria. Por el contrario, presenta una serie de problemas: la


102

búsqueda no está localizada en el objetivo, y se produce una explosión combinatoria, es

decir, se deducen hechos no relacionados con la solución. Maneja pocos datos y muchas

posibles conclusiones lo que lo hace poco específico (dispara “todas” las reglas posibles).

Los motores de inferencia que utilizan este tipo de razonamiento, suelen utilizar el algoritmo

RETE ([Forgy82], [Berstel02]), un algoritmo de reconocimiento de patrones utilizado para

inferir conocimiento a partir de una base de hechos, que sacrifica memoria para incrementar

la velocidad de procesamiento lo que incrementa la rapidez de los motores de reglas que lo

usan.

- Razonamiento inductivo, regresivo o backward chaining (BC): razonamiento también

denominado encadenamiento dirigido por objetivos, basado en un método inductivo en el que

a partir de la hipótesis inicial se reconstruye la cadena de razonamiento en orden inverso a

los hechos (conclusiones, hipótesis datos, evidencias, síntomas), cuya entrada son la base

de hechos, la base de reglas y los objetivos. Este tipo de razonamiento se caracteriza en que

cada paso implica nuevos subobjetivos o hipótesis a validar, y su algoritmo de funcionamiento

podría entenderse de la siguiente forma:

Como se extrae de la anterior secuencia, en este tipo de razonamiento se parte de una lista

de metas o hipótesis y va desde el consecuente hasta el antecedente comprobando si hay

datos disponibles en la base de hechos que soporten algún consecuente. Un motor de

inferencia que use este método va analizando reglas de inferencia hasta que encuentra una

que tiene un consecuente que se corresponde con una meta deseada. Si el antecedente de la

regla se cumple, se añade a la lista de metas. Se debe confirmar con datos que dicho

antecedente se cumple. Parte de una hipótesis inicial, que intenta demostrar con la

información que se tiene.

La principal ventaja de este tipo de razonamiento es que sólo se considera lo necesario para

la resolución del problema pero, como contrapartida se ha de conocer la solución del

problema a priori. Maneja mucha información pero poca es relevante, y al conocer la solución

es más específico que el forward chaining.

- Mixto, encadenamiento híbrido: mecanismo en el que partes de la cadena de razonamiento

que conduce de los hechos a los objetivos se construyen deductivamente y otras

inductivamente. El cambio de estrategia se lleva a cabo a través de meta-reglas. Este tipo de

razonamiento evita la explosión combinatoria del razonamiento deductivo por una parte, y por

otra, mejora la eficiencia del razonamiento inductivo cuando no existen objetivos claros.

En este punto cabe aclarar que la dirección de encadenamiento está relacionada exclusivamente con

el proceso de búsqueda y selección de reglas, no con la dirección en que estas se ejecutan. Es decir,

las reglas siempre se ejecutan “hacia delante”, si el antecedente es cierto, se ejecuta el consecuente.


103

Este apartado incluye una revisión de los principales razonadores semánticos desarrollados indicando

sus principales características funcionales, prestando especial atención a aquellos que soportan

SWRL, por ser el lenguaje de reglas utilizado para la especificación de políticas de este trabajo de

investigación. Con el fin de validar de una forma práctica el rendimiento de cada razonador y de

analizar cuál de los existentes es el más adecuado para el AIRS basado en ontologías propuesto, se

ha llevado a cabo una batería de pruebas, cuyos resultados más relevantes se incluyen al final de

este apartado.

3.4.1 Bossam

Bossam ([Jang04], [Bossam]] es un motor de inferencia utilizado en la Web Semántica, basado en el

algoritmo RETE y que utiliza forward-chaining como algoritmo de razonamiento. En la última década

se han desarrollado diversas versiones de Bossam, cada una mejor y más funcional que su

predecesora. La última versión estable de Bossam, la 0.9b45 con fecha Febrero de 2007.

A continuación se describen las principales características y funcionalidades de Bossam.

3.4.1.1 Servicios de razonamiento estándar

Bossam soporta inferencia de razonamiento sobre diferentes tipos de datos utilizando el algoritmo de

razonamiento forward chaining.

Tiene la capacidad de añadir expresividad adicional, independientemente de la expresividad propia

del lenguaje de especificación de políticas usado para definir las reglas y del lenguaje en que esté

definida la ontología, ya que soporta los siguientes servicios de razonamiento estándar:

Capacidad para referenciar URIs como símbolos.

Sintaxis de lógica de segundo orden.

Disyunciones en el antecedente y conjunciones en el consecuente.

Soporte para negación de fallos y negación clásica.

3.4.1.2 Formatos y lenguajes soportados

Bossam soporta inferencia sobre diferentes tipos de datos y lenguajes:

RDF/RDFS (sintaxis RDF/XML o N3): Bossam puede leer y llevar a cabo razonamiento sobre

ontologías escritas en RDF/XML o N3. El soporte en N3 es limitado al vocabulario OWL y

RDFS, ya que Bossam no entiende la fórmula N3.

OWL (sintaxis RDF/XML o N3): Bossam soporta razonamiento sobre documentos escritos en

OWL.

Reglas Buchingae: Bossam incluye un lenguaje de reglas de no marcado, llamado

Buchingae.

SWRL y RuleML: Bossam soporta razonamiento sobre reglas escritas en SWRL y RuleML. El

nivel de soporte de cada uno de estos lenguajes es el siguiente:

RuleML: Soporta fragmentos correspondientes a URCDATALOG + <Naf> + <Or> -

<Slot>

SWRL/XML: Bossam soporta reglas definidas en SWRL/XML excepto aquellas con

descripciones de clases arbitrarias que contengan Atoms. Se soportan algunos built-

ins de SWRL [Horrocks04].

SWRL/RDF: Bossam soporta razonamiento con la mayoría de los documentos que

contengan reglas SWRL en su formato RDF, incluyendo aquellos con clases


104

arbitrarias que contengan Atoms. Al igual que en el caso anterior, soporta algunos

built-ins de SWRL, como por ejemplo built-ins de String, de Comparación y de Math.

3.4.1.3 Interfaces de acceso al razonador

Bossam proporciona muchas formas diferentes de interacción con el razonador:

Acceso a través de una interfaz de línea de comandos.

Un API programable para aplicaciones Java independientes.

A través de una interfaz Web.

3.4.1.4 Otras características

Además de las funciones principales descritas en los puntos anteriores, Bossam presenta una serie

de características adicionales:

Soporte de respuesta a preguntas, a querys definidas en un lenguaje específico. Se pueden

usar reglas para preguntar por datos incluidos en la base de hechos del razonador y

conseguir un conjunto de bindings que contienen los resultados de la consulta realizada.

Es posible llamar a objetos Java desde el antecedente o el consecuente de las reglas

utilizando el método de java basado en URI. Esto permite mezclar objetos Java con las reglas

y ontologías utilizadas para la inferencia.

Resolución de conflictos basada en prioridades: es posible asignar prioridades a las reglas y

poder resolver conflictos en caso de que se produzcan en función de dicha prioridad.

Incrustación total de Bossam en aplicaciones Java: creación de razonador, carga de

documentos en OWL y SWRL, inferencia…

Es posible añadir nuevo conocimiento adicional a la base de hechos del razonador que no

esté inicialmente en la ontología cargada.

Es posible realizar preguntas sobre los resultados de la inferencia.

Permite realizar razonamiento incremental.

Permite definir namespaces adicionales.

3.4.2 PELLET

Pellet ([Sirin07], [Pellet]) es un razonador semántico de código abierto de OWL DL basado en Java,

desarrollado y soportado comercialmente por Clark & Parsia LLC. Originalmente se desarrolló en el

Laboratorio Mindswap de Maryland.

Pellet está basado en algoritmos de la lógica descriptiva (Description Logic, DL), lo que le permite

soportar la expresividad de OWL DL en su totalidad, incluyendo razonamiento de nominales (clases

numeradas). Además, proporciona servicios de razonamiento estándares y avanzados para

ontologías OWL, e incorpora varias técnicas de optimización descritas en la literatura DL, además de

novedosas optimizaciones de nominales, respuesta a preguntas compuestas, y razonamiento

incremental. Pellet puede ser usado conjuntamente con bibliotecas de Jena o con la biblioteca OWL-

API. Entre las principales funciones de Pellet se encuentran:

Validar ontologías.

Comprobar consistencia de las ontologías.

Clasificación de clases.

Responder a cuestiones SPARQL.


105

Las aplicaciones de Pellet son numerosas, dado el gran abanico de funcionalidades que proporciona.

Pellet es el razonador por defecto de Swoop, un editor de ontologías. Además, es muy utilizado en

descubrimiento y composición de servicios web.

Pellet se encuentra en un estado de desarrollo continuo, por lo que día a día se desarrollan e

implementan nuevas versiones. La última versión de Pellet estable es la 2.3.1 con fecha, Mayo de

2013.

Las principales características y funcionales de la última versión estable de este razonador se

presentan a continuación.


Razonador que soporta inferencia de razonamiento sobre diferentes tipos de datos utilizando tanto

algoritmo de razonamiento forward chaining como backward chaining, que proporciona los servicios

de inferencia básicos que permiten los razonadores de DL:

Comprobación de consistencia: servicio que permite asegurar que una ontología no contienen

hechos contradictorios.

Concepto de satisfacibilidad: determina si es posible que una clase tenga instancias, es decir,

si una clase es insatisfiable, y se define una instancia de esta clase, esto provocará que la

ontología se vuelva inconsistente.

Clasificación: permite crear la jerarquía de clases completa, mediante la evaluación de las

relaciones entre subclases. Esta jerarquía puede ser utilizada para formular queries como:

todas las subclases de un concepto, inferir nuevas subclases de un concepto, etc.

Realización o instanciación de los conceptos de la jerarquía: permite encontrar las clases más

específicas a las que un individuo pertenece. La realización sólo puede ser llevada a cabo

después de la clasificación, ya que los tipos se definen en función de la jerarquía.

Depuración (Debug) de ontologías: Pellet soporta tanto detección de conceptos

insatisfactibles en una ontología, como diagnosis y resolución de errores (por ejemplo, indicar

por qué se produce el error o cómo influyen las dependencias entre clases en la propagación

del error). Para ello, Pellet tiene mecanismos que localizan con exactitud los axiomas que

causan las inconsistencias y la relación entre los conceptos insatisfactibles. La primera de las

tareas es una tarea fácil, pero la segunda no suele proporcionarse con frecuencia.

Además de estos servicios, Pellet soporta razonamiento teniendo en cuenta la total expresividad de

OWL-DL, y además, permite razonar teniendo en cuenta algunos rasgos de OWL-Full.


Pellet permite razonar sobre diferentes tipos de datos y lenguajes:

OWL-DL: Pellet está basado en algoritmos “tableaux” (algoritmos de lógica descriptiva, DL), lo

que le permite soportar la expresividad de la lógica descriptiva de OWL-DL en su totalidad,

incluyendo razonamiento de nominales (clases enumeradas). Pellet soporta todas las

características propuestas en OWL 1.1, a excepción de tipos de datos n-arios.

OWL-Full: Pellet soporta razonamiento sobre las propiedades de funcionalidad inversa de los

tipos de datos de OWL-Full.

OWL 2: todas las versiones posteriores a Pellet 1.5.2 tienen soporte de OWL2, lenguaje que

incluye restricciones de cardinalidad limitadas, axiomas de subpropiedades complejos,

restricciones de reflexividad local, propiedades reflexivas, irreflexivas, simétricas y anti-

simétricas, propiedades disyuntivas, aserciones de propiedades negativas, compartir

vocabulario entre individuos, clases y propiedades, y rangos de datos definidos por el usuario.

El soporte para razonamiento sobre construcciones OWL2 ha ido mejorando tanto en


106

compatibilidad con OWL2 como en robustez, a medida que se desarrollaban nuevas

versiones de Pellet 2.

XML-S: soporta el razonamiento sobre todos los tipos de datos internos de XML Schema

(tipos numéricos, strings, y tipos date-time), además de cualquier tipo de datos definido por el

usuario que extienda los tipos numéricos o el tipo date/time.

SPARQL/SPARQL-DL: desde las primeras versiones de Pellet, este razonador incluye un

motor de preguntas ABox, que soporta respuestas a una conjunción de preguntas. En Pellet

1.x se usaba SPARQL para la formulación de este tipo de preguntas que permitía consultas

de tipo SELECT, CONSTRUCT y ASK pero no DESCRIBE, OPTIONAL o FILTER. Para

responder a este tipo de preguntas se podía usar el motor de queries SPARQL de Jena en un

modelo de inferencia de Pellet. No obstante, el motor interno de Pellet en versiones inferiores

a la 2.0 sólo soportaba “queries” ABox que no usasen el predicado owl:sameAs o

owl:differentFrom.

Desde la versión 2.0, se ha incorporado un nuevo motor que puede responder queries

expresadas en SPARQL-DL. Este motor permite responder preguntas de ABox/TBox

mezcladas, y soporta predicados especiales. El motor de SPARQL-DL está integrado en el

motor Jena ARQ, por lo que gracias a ello trata construcciones complejas del álgebra

SPARQL, como OPTIONAL, UNION y FILTER. Además, response con BGP (Basic Graph

Patterns).

SWRL: Pellet proporciona una implementación que permite extender reglas DL-safe a OWL-

DL. Incluye un “parser” de reglas en SWRL que permite cargar y razonar reglas DL-safe

cifradas en SWRL. En versiones iniciales de Pellet, la integración del razonador (mediante el

parser indicado) con reglas SWRL DL-safe era muy básico, soportando tan sólo las funciones

built-ins de comparación de SWRL. Esta integración mejoró significativamente de la versión

1.5.2 a la 2.0, versión a partir de la cual Pellet soporta todas las funciones built-ins de la

especificación de SWRL incluyendo los built-ins para URIs, excepto las relacionados con

rdf:List.

Por su parte, la implementación DL-safe es útil para ontologías de pequeño o mediano

tamaño. Gracias al parser, se pueden cargar directamente los archivos SWRL en Pellet y las

reglas serán analizadas y procesadas sin problema. Para tratar reglas SWRL también se

pueden usar las interfaces OWLAPI o Jena.

Por otra parte, para la lógica de primer orden se necesita un comprobador de teoremas para

especificar axiomas. Con FOL se aporta expresividad pero se pierde razonamiento, por lo que el

manejo de una gran base de conocimiento y axiomas no es tratable computacionalmente. Debido a

esta circunstancia su uso en un entorno de grandes dimensiones no es recomendable.


Pellet proporciona muchas formas diferentes de acceder a las habilidades del razonador:

Acceso desde línea de comandos a través de CLI (Command Line Interface), incluido en el

paquete de distribución del razonador. La interface CLI permite a los usuarios acceder de

forma sencilla e intuitiva a todas las características de Pellet (nuevas o ya existentes). La

interfaz uniforme GNU-Style proporciona un conjunto de subcomandos que pueden ser

usados para control de consistencia, clasificación, realización, preguntas/respuestas,

extracción de inferencias realizadas, y extracción de módulos. Además, la interfaz CLI acepta

múltiples ontologías como entrada, por lo que no es necesario unirlas manualmente o crear

una ontología nueva que las importe todas, como ocurría en versiones anteriores de dicha

interfaz.

Un API programable que puede ser usado en una aplicación aislada.


107

A través de las interfaces de Jena y Manchester OWL-API, que permiten conectar Pellet con

ellas.

A través de integración directa con el editor de ontologías SWOOP.

A través del protocolo DIG, que permite a diferentes clientes, como por ejemplo Protégé

3.3.1, utilizar Pellet.

A través de integración directa con el editor de ontologías Protégé 4.0.


Además de las funciones principales descritas en los puntos anteriores, Pellet presenta una serie de

características adicionales, que han ido evolucionando y mejorando a lo largo de todas sus versiones:

Análisis y reparación de ontologías: Pellet incorpora un conjunto de heurísticos que permiten

detectar ontologías OWL Full que pueden ser expresadas como ontologías OWL DL, y puede

repararlas adecuadamente.

Integración de Pellint: Pellint es una herramienta de “hilar” ontologías integrada en Pellet que

puede ser ejecutada directamente desde la interfaz de línea de comandos de Pellet (CLI).

Pellint detecta estilos de modelado en ontologías OWL que degradan el rendimiento del

razonador. Proporciona funcionalidad tanto a nivel de RDF como a nivel de OWL.

Clasificador optimizado para OWL2-EL: Pellet cuenta con un clasificador optimizado para

OWL2-EL. Pellet automáticamente detecta si una ontología se corresponde con la

expresividad de OWL2-EL y en caso afirmativo usa el clasificador optimizado. Ésta

funcionalidad aumenta la velocidad y mejora el uso de memoria en la tarea de clasificación.

Módulo extractor: Pellet incorpora un módulo extractor, que permite extraer un subconjunto de

una ontología para un conjunto de condiciones dadas. Este módulo extraído de la ontología

será mucho más pequeño, por lo tanto, será más comprensible por humanos y más

manejable y procesable por herramientas.

Razonamiento y clasificación incremental: Pellet permite actualizar los resultados de

clasificación en función de los cambios que se produzcan en la ontología. El clasificador

incremental utiliza Pellet para calcular la jerarquía de clases inicial de la ontología, pero una

vez hecho esto, cuando la ontología se actualiza sólo las partes involucradas son

recalculadas utilizando el clasificador directamente. Esta característica es muy importante, ya

que hace posible que Pellet razone sobre bases de conocimiento que cambian, que se

actualizan de forma continua. Pellet soporta clasificación incremental y control de

consistencia incremental.

Motor de inferencias personalizable: Pellet proporciona un motor de inferencias

personalizable que puede ser usado para exportar inferencias desde el razonador

rápidamente. Este extractor puede configurarse para seleccionar qué tipo de inferencias

deberían ser extraídas, lo que proporciona a los usuarios más control en el proceso de

inferencia.

El API de tiempo de Pellet y sus usos internos permite que los usuarios interrumpan el

proceso de razonamiento definiendo timeouts propios. Los usuarios pueden definir un timeout

para servicios de razonamiento básico y Pellet parará el proceso de razonamiento cuando

este tiempo haya finalizado.

Además, los desarrolladores de Pellet trabajan constantemente en mejorar el rendimiento del

razonador, tanto en tiempo de razonamiento como en uso de memoria. Para lo primero, uno de los

cambios más significativos fue la mejora de la eficiencia del control de consistencias, principal servicio

en el proceso de razonamiento, especialmente significativo en el manejo de ontologías con un

elevado número de instancias. En el caso de la memoria, el objetivo es reducir los requisitos de


108

memoria impuestos por Pellet, para lo que se ha ido modificando la estructura interna de Pellet, tanto

para los razonamientos sobre ABox como sobre TBox.

3.4.3 KAON2

KAON2 [KAON2], es un razonador semántico y gestor de ontologías dirigido a aplicaciones de

negocio, que soporta OWL DL, parte de SWRL y F-Logic. Está desarrollado conjuntamente por las

siguientes instituciones: el IPE (Information Process Engineering), el instituto AIFB (Applied

Informatics and Formal Description Methods) de la universidad de Karlsruhe y el grupo de gestión de

la información (IMG) de la universidad de Manchester.

KAON2 es un sucesor del proyecto KAON [Bozsak02], del que se diferencia principalmente en el

lenguaje de definición de ontologías que soporta: KAON se usa como una extensión propietaria de

RDFS, mientras que KAON2 está basado en OWL-DL y F-Logic. A pesar de ser una continuación de

KAON, KAON2 es un nuevo sistema no compatible con KAON.

La última versión de KAON2 estable data de Junio de 2008. Esta versión es de libre distribución para

universitarios y para uso académico no comercial (laboratorios de investigación que no se consideren

universidades). No obstante, existe otra versión comercial de KAON2, denominada OntoBroker OWL.

En este apartado se describen las principales características y funcionalidades de KAON2.


KAON2 tiene la capacidad de manipular ontologías OWL-DL. En cuanto al razonamiento, KAON2

soporta SHIQ(D), subconjunto de OWL-DL. Este subconjunto de OWL-DL incluye todas las

características de OWL-DL excepto los nominales o clases enumeradas.

Al soportar casi la totalidad de OWL-DL, proporciona los servicios de inferencia básicos que permiten

los razonadores de DL:

Comprobación de consistencia: servicio que permite asegurar que una ontología no contienen

hechos contradictorios.

Concepto de satisfacibilidad: determina si es posible que una clase tenga instancias, es decir,

si una clase es insatisfiable, y se define una instancia de esta clase, esto provocará que la

ontología se vuelva inconsistente.

Clasificación: permite crear la jerarquía de clases completa, mediante la evaluación de las

relaciones entre subclases. Esta jerarquía puede ser utilizada para formular queries como:

todas las subclases de un concepto, inferir nuevas subclases de un concepto, etc.

A diferencia del resto de razonadores como RACER o Pellet, KAON2 no implementa el algoritmo de

cálculo tableau, sino que el razonamiento en KAON2 se implementa a través de nuevos algoritmos

que se reducen a trabajar e inferir sobre base de conocimiento SHIQ(D). El tipo de razonamiento

utilizado es el denominado backward chaining.


KAON2 soporta razonamiento sobre los siguientes tipos de datos:

OWL-DL: soporta razonamiento sobre un subconjunto de OWL-DL denominado SHIQ(D), que

posee todas las características de OWL-DL excepto las clases enumeradas. La API puede

leer además tanto la sintaxis OWL/XML como la OWL/RDF.

OWL-Lite: soporta la totalidad de OWL-Lite debido a que tiene definición de nominales.

SWRL: KAON2 soporta razonamiento sobre un conjunto de SWRL llamado DL-safe.

F-Logis: este razonador soporta el lenguaje F-Logic.


109


KAON2 proporciona 2 interfaces de interacción con el razonador:


A través del protocolo DIG, que permite a diferentes clientes, como por ejemplo Protégé

3.3.1, utilizar KAON2.


Además de las funciones principales descritas en los puntos anteriores, KAON2 presenta una serie


Un servidor autónomo que proporciona acceso distribuido a las ontologías a través de RMI.

Un motor de inferencia que se encarga de responder a preguntas compuestas (las preguntas

se expresan mediante la sintaxis SPARQL). No obstante, no todas las especificaciones de

SPARQL están soportadas; concretamente, solo soporta aquellas preguntas que equivalen a

preguntas conjuntivas. Alternativamente, las preguntas pueden ser formuladas en F-Logic.

Un módulo para extraer las instancias de la ontología de las bases de datos relacionales.

3.4.4 RACER Pro

RACER (Renamed Abox and Concept Expression Reasoner) ([Haarslev12], [RacerPro]) es un

razonador web semántico y almacén de información, basado en algoritmos sólidos y completos

optimizados. RacerPro es el nombre del software comercial.

RacerPro tiene sus orígenes en el área de la lógica de descripciones. Desde el momento en que la

lógica de descripciones proporciona una base en la estandarización de los lenguajes de ontologías en

el contexto de la web semántica, RacerPro puede usarse también como un sistema para gestionar

ontologías de la web semántica basadas en OWL y como motor de razonamiento para la inferencia

de conocimiento a partir de las mismas.

RacerPro está implementado por Common Lisp y está disponible como programa servidor para

realizar búsquedas o con fines investigadores, en Linux, Windows y Mac OS X. Los programas

clientes de RacerPro pueden conectarse fácilmente al servidor RacerPro a través de interface TCP/IP

basada en sockets. Está disponible una interface cliente para Java.

RacerPro tiene muchas aplicaciones, entre las que se encuentra su uso en aplicaciones que

requieran consultas a grandes bases de datos. Al trabajar con gran cantidad de información y

consulta, no se pueden obviar los resultados obtenidos, por lo que es necesario desarrollar sistemas

de almacenamiento que proporcionen persistencia a las ontologías y lenguajes de consulta, que sean

eficientes y escalables. Además, debido a su escalabilidad, su uso se extiende en diversos campos:

Web Semántica, Electronic Business, medicina y biomedicina, Visión basada en conocimiento y

procesamiento de lenguaje natural, ingeniería del conocimiento, ingeniería de procesos o ingeniería

del software.

Al igual que el resto de razonadores semánticos, RacerPro se encuentra en un estado de desarrollo

continuo, por lo que día a día se desarrollan e implementan nuevas versiones. La última versión de

RacerPro estable es la 1.9.0. La última versión de RacerPro desarrollada es RacerPro 2.0 beta,

disponible desde principios de 2013.

A continuación se describen las principales características y funcionalidades de las versiones de

RacerPro nombradas (RacerPro 1.9.0 y RacerPro 2.0).


110


Racer Pro 1.9.0, última versión estable de RacerPro, es un sistema basado en lógica de

descripciones muy representativo y completo, que utiliza un algoritmo forward chaining como

mecanismo de inferencia. Entre sus principales características de razonamiento se pueden destacar:

Implementa mecanismos de razonamiento sobre la TBox y ABox.

Proporciona un lenguaje de consultas, el nRQL, que permite realizar consultas conjuntivas, e

implementa mecanismos de razonamiento sobre la ABox.

Los mecanismos de razonamiento se implementan mediante complejas técnicas de

reducción.

Control de consistencia de ontologías OWL y conjunto de descripciones de datos.

No ofrece persistencia.

Permite encontrar sinónimos para los recursos, lo que facilita el razonamiento.

Por su parte, RacerPro 2.0, incorpora algunas mejoras en lo que a servicios de razonamiento se

refiere, con respecto a la versión 1.9.0. Al que igual que versiones anteriores, presenta una

arquitectura de tipo cebolla, en cuyo centro se encuentra el núcleo de razonamiento, que implementa

un algoritmo de cálculo tableaux altamente optimizado para la resolución del problema de la

consistencia ABox de la lógica de descripción SRIQ (D-). A continuación se enumeran las mejoras

más significativas:

Mejora de la gestión para ciertas bases de conocimiento como SNOMED o LUBM.

Optimización del motor de inferencia, lo que proporciona mayor velocidad en el razonamiento

sobre la TBox y la ABox.

Mejora de la escalabilidad del razonador, soportando el manejo de ontologías de gran

envergadura.

Incorpora el servicio de persistencia gracias a AllegroGraph 3.0.

Razonamiento abductivo en respuesta a un conjunto de reglas de tipo cláusulas de Horn no

recursivas.

Soporte de razonamiento y consulta con representaciones de propósito especial, como por

ejemplo, razonamiento con representaciones espaciales cualitativas como RCC (Region

Connection Calculus).

Incluye un nuevo servicio de reconocimiento de eventos, llamado TimeNet.

Incluye un servicio de depuración (Debug) de ontologías, con el objetivo de detectar

inconsistencias en las ontologías. Una vez finalizado el proceso de depuración, genera una

informe que describe la fuente de cada inconsistencia.


RacerPro 1.9.0 soporta los siguientes formatos y lenguajes:

RDF/RDFS.

OWL-DL: soporta este lenguaje aunque con ciertas limitaciones.

Sintaxis nativa de RacerPro, que es un formato extendido de KRSS.

SWRL: soporta cierto razonamiento sobre SWRL. No soporta los built-ins de SWRL.

nQRL: RacerPro proporciona un lenguaje de consultas y reglas denominado nRQL. Este

lenguaje no se ha quedado en unas bases teóricas, sino que está implementado. nRQL

obliga a ligar todas las variables en la consulta, a diferencia de los lenguajes de


111

representación del conocimiento, que tan solo pueden deducir la existencia de una respuesta

para una consulta pero no una ligadura para cada variable de la misma.

La versión 2.0 incluye soporte para más formatos y mejora el soporte de los anteriores:

- Mejora el soporte para RDF, como por ejemplo, tratamiento correcto de nodos blancos.

- Mejora el soporte de OWL, incluyendo funcionalidades como soporte de individuos anónimos,

tipos de datos XSD, etc.

- Mejora del soporte de SWRL. La nueva versión soporte algunos de los built-ins más comunes

de SWRL. Las reglas SWRL son mapeadas a reglas nRQL para su interpretación y posterior

ejecución.

- Incluye nuevas extensiones de nRQL, como nuevos tipos de queries que incluyen operadores

de agregación estándar en sus cabeceras (cuenta y suma), así como combinación de las

mismas con consultas a la ABox y TBox. Además, las reglas nRQL pueden añadir ítems a la

ontología o base de conocimiento, mediante la utilización de unos nuevos átomos

denominados expresiones MiniLisp en las conclusiones de las reglas. Estos átomos son

definidos por los usuarios.

- Mejora los prefijos de espacios de nombres XML.

- Incluye soporte de OWL2 RDF/XML y OWL2 XML. Sin embargo, en la práctica, el sistema

ignora ciertos tipos de axiomas nuevos de OWL2, o los incluye de forma aproximada en el

razonamiento. En futuras versiones, esperan soportar totalmente la semántica de OWL2.

- Incluye soporte de formatos externos de datos, como por ejemplo, conjuntos de caracteres

asiáticos y UTF8.

- Soporte de sintaxis SPARQL, gracias a la integración del motor de consulta AllegroGraph

RDFS++ (interfaz de SPARQL).


La versión estable de RacerPro proporciona 3 interfaces que permiten acceder y utilizar el razonador:

RacerPorter: interfaz gráfica, a través de la cual se pueden cargar ontologías, inferir cierto

conocimiento adicional, consultar los hechos de la TBox, la ABox, etc. Dicha interfaz es un

ejecutable descargable al instalar RacerPro.

A través del protocolo DIG en sus versiones 1.1 y 2.0, que permite a diferentes clientes, como

por ejemplo Protégé, utilizar RacerPro.


La versión 2.0 además, incorpora nuevas interfaces:

- NOSA API, una nueva API desarrollada para soportar el marco OWLAPI, que permite

manejar bases de conocimiento en OWL en programas JAVA. Para poder utilizar OWLAPI

con el razonador RacerPro, es necesario la instalación de un adaptador en el lado del código

JAVA.

- A través de integración con el editor de ontologías Protégé 4.0, mediante un adaptador de

RacerPro 2.0 que explota la nombrada NOSA-API.

- OWLLink, sucesor del protocolo DIG 1.1. OWLLink se basa en HTTP, y cuenta con una

sintaxis de mensajes basado en OWL2 XML, por lo que permite la escritura de los clientes del

razonador en todos los lenguajes de programación que ofrecen marcos de procesamiento de

HTTP / XML, y no sólo JAVA.

- Soporte de consultas en SPARQL gracias a la interfaz AllegroGraph RDFS++.


112


Además de las funciones principales descritas en los puntos anteriores, RacerPro presenta una serie


Proporciona un cliente HTTP para importar recursos desde la web en la ontología.

Razonamiento incremental.

3.4.5 Otros razonadores semánticos

Además de los razonadores semánticos analizados, existentes otros desarrollos realizados que a

continuación se enumeran.

Hoolet

Hoolet ([Bechhofer04b], [Hoolet]): razonador semántico que maneja reglas SWRL y ontologías

definidas en OWL-DL, cuyo principio de funcionamiento es la lógica de primer orden. La ontología es

traducida a una colección de axiomas de una forma obvia basándose en la semántica de OWL. Esta

colección de axiomas se pasa a continuación a un componente que se encarga de probar la lógica de

primer orden para comprobar la consistencia de los axiomas. No se puede afirmar que Hoolet sea un

razonador eficaz, ya que por muy simple que sea la propuesta es muy poco probable hacer viable y

factible su escalabilidad. Sin embargo, Hoolet proporciona una herramienta útil para usarla en

pequeños ejemplos ilustrativos.

Hoolet es implementado usando el API de OWL para analizar sintácticamente (“parsing”) y procesar

OWL, y el motor de prueba Vampire para tareas de razonamiento. Está disponible una

implementación de un prototipo de Hoolet, compuesta por una interfaz gráfica de usuario que permite

cargar ontologías y conjuntos de reglas, junto con el razonador, cuya última versión data de 2004.

Este prototipo es muy simple y sólo está desarrollado para el sistema operativo Linux.

FaCT/FaCT++

Fast Classification of Terminologies, FaCT [FaCT], es un clasificador basado en lógica de

descripciones (DL) utilizado para probar la satisfacción de los modelos lógicos. Incluye dos

razonadores, uno para la lógica SHF y otro para la lógica SHIQ. Ambos razonadores usan algoritmos

sólidos.

Las características generales a destacar de FaCT son:

- Su lógica expresiva (en particular, el razonador SHIQ): SHIQ es suficientemente expresivo

como para ser usado como razonador de lógica DLR, y por lo tanto, para razonar con bases

de datos.

- Su capacidad para razonar con bases de conocimiento arbitrarias: por ejemplo, las bases de

conocimiento que contienen conceptos generales de inclusión de axiomas.

- Su implementación optimizada de tablas: esta implementación se va a convertir en estándar

para sistemas de lógica de descripciones.

- Su arquitectura cliente-servidor basada en CORBA (arquitectura estándar para sistemas de

objetos distribuidos).

En cuanto a su implementación y requisitos del sistema, FaCT está escrito en Common Lisp (lenguaje

de programación usado en el mundo de la inteligencia artificial), y ha sido ejecutado con éxito en

varios entornos comerciales de código libre, como GNU. El código fuente está disponible bajo la

licencia pública GNU, por lo que FaCT puede ser ejecutado en cualquier sistema en el que Lisp esté

disponible. El código ejecutable también está disponible para los SO Linux y Windows. Además, un

servidor FaCT ejecutándose en un host puede ser usado en cualquier sistema que tenga red de

acceso al servidor, vía su interfaz CORBA.


113

Por otra parte, FaCT++ ([Tsarkov06], [FaCT++]) es la nueva generación del razonador FaCT OWL-

DL, descrito en los párrafos anteriores. FaCT++ usa los algoritmos sólidos de FaCT, pero con una

arquitectura interna diferente. Además, para la implementación de FaCT++ se ha usado C++, con el

fin de crear una herramienta software más eficiente y maximizar la portabilidad. Además de las

diferencias señaladas, se han introducido nuevas optimizaciones y algunas características añadidas.

FaCT++ se ha hecho público bajo la licencia GNU y se puede descargar tanto el archivo binario como

el código fuente. El código fuente y el binario precompilado de FaCT++ están disponibles en

[FaCT++b].

No soporta el lenguaje de reglas SWRL, lo que supone un gran inconveniente para su posible

utilización como motor de razonamiento del AIRS basado en ontologías, objeto de este trabajo de

investigación.

3.4.6 Análisis y validación de razonadores semánticos con soporte

de SWRL

Como se ha descrito en esta sección, en el ámbito de la Web Semántica existen varios razonadores

semánticos capaces de inferir conocimiento adicional. No obstante, este ámbito de investigación se

encuentra en fase de desarrollo por lo que aún no ha alcanzado un estado de madurez ni estabilidad,

ya que la mayoría de los razonadores se encuentran en fase de ampliación y desarrollo, añadiendo

nuevas funciones y mejorando sus fallos.

Cada uno de estos razonadores soporta un tipo de lenguaje de reglas y posee características

funcionales diferentes, por lo que la elección de uno u otro dependerá de los requisitos del sistema en

el que se utilice dicho razonador.

El lenguaje de reglas más utilizado por la web semántica es SWRL por lo que para el desarrollo del

AIRS propuesto se propone el uso de dicho lenguaje. Por ello queda patente la necesidad de un

motor de reglas que soporte las reglas SWRL definidas.

Con el fin de elegir el razonador semántico más apropiado al sistema propuesto en este trabajo de

investigación, y cuyo rendimiento sea óptimo, se ha llevado a cabo una validación práctica de cada

uno de los razonadores que soportan SWRL descritos en la sección anterior, motivo por el cual se ha

descartado FaCT/FaCT++. En dicha validación se han tenido en cuenta tres factores:

- Nivel de soporte de SWRL: soporte de built-ins de SWRL. No todos los razonadores soportan

SWRL en su totalidad. Algunos razonadores únicamente soportan razonamiento simple con

SWRL, es decir, reglas expresadas en SWRL sin built-ins.

- Rapidez: el tiempo en que el razonador infiere las respuestas óptimas partiendo de la

ontología y las reglas definidas debe ser el menor posible. La velocidad de los razonadores

es función del algoritmo de razonamiento utilizado por cada uno de ellos.

- Capacidad de introducir conocimiento externo a la base de hechos del razonador, es decir

conocimiento no definido en la ontología: ciertos atributos definidos como propiedades de

tipos de datos de las clases de la ontología no poseen un valor fijo para cada individuo de

dicha clase en el momento en que se crea dicho individuo, sino que su valor depende del

resultado del razonamiento previo realizado por el razonador. En ese caso, es necesario

poder introducir el valor adecuado de dichos parámetros a la base de hechos del razonador

sin necesidad de actualizar la ontología. El valor introducido en la base de hechos se tomará

como dato para el siguiente razonamiento del razonador, pero el cambio no se reflejará en la

ontología.

En este apartado se definen brevemente las pruebas realizadas, la metodología utilizada para la

validación de cada uno de los razonadores y los principales resultados obtenidos


114

3.4.6.1 Pruebas

Para la validación de cada razonador se ha seguido un proceso que consta de varias pruebas:

1. Definición de ontologías y reglas SWRL:

- Definición de una pequeña ontología compuesta de una única clase, 3 individuos

pertenecientes a la misma, y propiedades de tipos de datos (DataTypeProperties) y

de relaciones entre objetos (ObjectProperties), que representan rasgos y

características identificativas de los ejemplares o individuos de la clase. Esta

ontología base no contiene, en principio, reglas SWRL.

- A la ontología base, se han ido añadiendo reglas SWRL simples con y sin built-ins,

para probar el nivel de alcance de soporte de SWRL del razonador. Cada prueba ha

dado lugar a pequeñas ontologías derivadas de la primera.

- Utilización de la ontología propuesta (Ver Capítulo 5) y el conjunto de reglas SWRL

(Ver Capítulo 6) especificadas durante la presente tesis doctoral.

2. Carga de la ontología base definida, sin reglas SWRL, con objeto de comprobar el nivel de

soporte de OWL2:

- Comprobación de soporte de propiedades de tipos de datos (dataTypeProperty).

- Comprobación de soporte de propiedades de objetos (objectProperty).

3. Carga y razonamiento de la ontología base definida, con reglas SWRL:

- Comprobación de inferencia de resultados de reglas sin built-ins.

- Comprobación de soporte de los 7 tipos de built-ins de SWRL.

4. Carga e inferencia de la ontología OntAIRS.owl propuesta en el Capítulo 5 de esta memoria,

utilizada en el AIRS definido:

- Comprobación de capacidad de introducir conocimiento externo a la base de hechos

del razonador no definido previamente en la ontología.

- Medida de tiempos:

Tiempo de carga de la ontología.

Tiempo de inferencia.

Tiempo total de la validación.

3.4.6.2 Metodología utilizada

La validación de los diferentes razonadores se ha llevado a cabo a través de dos métodos,

dependiendo del razonador:

- API disponible para Java de que dispone el razonador: Bossam, Pellet 2.3.1, KAON2.

La prueba consiste en un programa ejecutable de Java que permite cargar la ontología y las

reglas SWRL, inferir razonamiento sobre ella (a través de la API) e interactuar con lo

ontología para actualizar los resultados obtenidos a través de Jena.

Entorno de programación utilizado: NetBeans y línea de comandos.

- Interfaz gráfica: RacerPro 1.9.0 y RacerPro 2.0.

La validación de ambas versiones de RacerPro se ha llevado a cabo a través de la interfaz

gráfica RacerPorter que permite cargar la ontología, inferir razonamiento sobre ella.

En los razonadores con soporte del protocolo DIG, se ha utilizado la interfaz a través del protocolo

DIG para la integración del razonador con Protégé. De esta forma se ha validado el control de


115

consistencia, la clasificación de la ontología y la inferencia de nuevos individuos con resultados

satisfactorios. Por ser irrelevantes para este estudio no se hará más referencia acerca de ellos.

3.4.6.3 Resultados obtenidos

En la Tabla 3.3 se muestran los principales resultados obtenidos en la validación de los razonadores.

Tabla 3.3 Resultados de validación de razonadores semánticos.

Valor Bossam Pellet

2.3.1 KAON2

RacerPro

1.9.0

RacerPro

2.0

Carga

Ontología OWL Sí Sí Sí Sí Sí

DataTypePrope

rties

name, numeroTio, …

Sí Sí Sí Sí Sí

ObjectProperti

es

tieneTio, tieneHermano

… Sí Sí Sí Sí Sí

Carga

Ontologías con

reglas SWRL

Sí Sí

No carga la

Ontología.

Exception in

thread “main”

org.semanticweb.k

aon2.api.KAON2E

xception: Cannot

parse the

descriptor.

No carga la

Ontología.

Exception:

DatavaluedP

ropertyAtom

is not yet

supported.

Sí

SWRL Math

Built-Ins swrlb:add Parcial Sí ------ No Parcial

SWRL String

Built-Ins

swrlb:stringLength

Parcial Sí Parcial No Parcial

SWRL

Comparison

Built-Ins

swrlb:greaterThanOrEqual

Sí Sí ------ No Sí

SWRL Boolean

Built-Ins

swrlb:booleanNot

No Sí ------ No No

SWRL Date,

Time and

Duration Built-

Ins

swrlb:date No Sí ------ No No

SWRL URI

Built-Ins ------ No Sí ------ No No

SWRL Lists

Built-Ins ------

No. OWL-

DL no

soporta

listas

No.

OWL-DL

no

soporta

listas

No. OWL-DL no

soporta listas

No. OWL-

DL no

soporta

listas

No. OWL-

DL no

soporta

listas

Capacidad

conocimiento

externo

Sí Sí ------ ------ ------

Tiempo de

Carga (seg) 32,049 0,991 Fallo Fallo 4,032

Tiempo de

Inferencia 1,780 0,240 ------ ------ 1,245

Tiempo Total 35, 294 1,231 ------ ------ 5,277


116

Como se observa en la tabla, en función del tipo de función built-in que el programador desee utilizar

en la definición de la regla SWRL será conveniente elegir un razonador u otro.

No obstante, cabe decir, que la validación de los razonadores se ha hecho tomando SWRL como

lenguaje de definición de reglas, pero ciertos razonadores soportan otros lenguajes de reglas para los

que han sido específicamente diseñados. Así por ejemplo, Bossam tiene un lenguaje de reglas

específico llamado Buchingae, KAON2 utiliza su propio lenguaje para la definición de reglas y

RacerPro utiliza nRQL


En esta sección se han presentado y analizado algunos de los razonadores semánticos más

utilizados en la actualidad, componentes software que permiten inferir conocimiento adicional

partiendo de un conjunto de hechos en la ABox y la TBox. El lenguaje OWL2 tiene la capacidad de

poder inferir cierta información adicional que no esté contenida explícitamente en la definición de la

ontología, pero esta inferencia de conocimiento nuevo sigue siendo limitada. Por ese motivo, los

razonadores semánticos permiten aumentar dicha capacidad de razonamiento, más allá de la

capacidad intrínseca de OWL2.

A la hora de comparar y clasificar razonadores semánticos se deben analizar sus principales

características, agrupando estas en tres dimensiones:

- Características de razonamiento: algoritmo de razonamiento utilizado, expresividad,

capacidad de clasificación incremental, capacidad de conocimiento externo, control de

consistencia, soporte de reglas, nivel de soporte de SWRL y capacidad de razonamiento

sobre ABox.

- Usabilidad: interfaz OWL API, soporte de la API de Jena, plugin de Protégé, lenguaje de

implementación, plataformas de uso, licencia de uso y si hay documentación disponible.

- Rendimiento y eficiencia: para aquellos que soportan SWRL, es importante comparar el

tiempo de carga de la ontología y tiempo total de inferencia.

A partir de los resultados obtenidos en la validación práctica realizada y del análisis de las principales

características de cada razonador presentado previamente, se ha elaborado la siguiente tabla

comparativa:

Tabla 3.4 Razonadores semánticos. Resumen comparativo.

Bossam Pellet

2.3.1 KAON2

RacerPro

1.9.0

RacerPro

2.0 Hoolet FaCT++

Características de razonamiento

Algoritmo de

razonamiento /

Metodología

Forward

chaining /

Basado en

reglas,

RETE

Forward y

backward

chaining /

Tableau

Backward

chaining /

Datalog

Forward

chaining /

Tableau

Forward

chaining /

Tableau

Demostr

ador FOL

N/A /

Tableau

Expresividad N/A SROIQ(D)

/SHOIN(D) SHIQ(D) SHIQ(D-) SHIQ(D-) N/A SROIQ(D)

Clasificación

incremental Sí Sí N/A No Sí N/A No

Capacidad

conocimiento

externo

Sí Sí No N/A N/A No N/A

Control de

consistencia N/A Sí Sí Sí Sí SÍ Sí

Soporte de SWRL y SWRL DL SWRL DL SWRL SWRL, SWRL No


117

reglas Buchingae Safe Safe (*) (Parcial),

nRQL (*)

nRQL

SWRL Math

Built-Ins Parcial Sí No No Parcial No No

SWRL String

Built-Ins Parcial Sí Parcial No Parcial No No

SWRL

Comparison

Built-Ins

Sí Sí No No Sí No No

SWRL Boolean

Built-Ins No Sí No No No No No

SWRL Date,

Time and

Duration Built-

Ins

No Sí No No No No No

SWRL URI Built-

Ins No Sí No No No No No

SWRL Lists

Built-Ins No No No No No No No

Razonamiento

ABox N/A

Sí.

SPARQL

Sí.

SPARQL

Sí.

SPARQL,

nRQL

Sí.

SPARQL,

nRQL

N/A Sí

Usabilidad

OWL API N/A Sí N/A Sí Sí Sí Sí

Jena Sí Sí N/A No No N/A No

Plugin Protégé No Sí Sí No Sí No Sí

Lenguaje Java Java Java Lisp Lisp C++

Plataformas Todas Todas Todas Todas Todas Linux Todas

Documentación

disponible Sí Sí No Sí Sí No No

Licencia Free/closed-

source

Free/open-

source

Free/close

d-source

Non-

free/closed

-source

Non-

free/closed

-source

Free/

open-

source

Free/

open-

source

Rendimiento y eficiencia

Tiempo de

Carga (seg) 32,049 0,991 ------ ------ 4,032 ------ ------

Tiempo de

Inferencia (seg) 1,780 0,240 ------ ------ 1,245 ------ ------

Tiempo Total

(seg) 35, 294 1,231 ------ ------ 5,277 ------ ------

(*) Soporte de SWRL teórico. En la validación práctica se produce un fallo al cargar la ontología.

La elección de un razonador o u otro depende de los requisitos específicos de cada programador, que

elegirá aquel que mejor se adapte a las necesidades del sistema, teniendo en cuenta las

características de razonamiento, la usabilidad y el rendimiento de cada uno, cuyo análisis se

proporciona.

En el caso concreto del AIRS basado en ontologías propuesto, el razonador debe satisfacer tres

requisitos fundamentales, indicados previamente: soporte de SWRL y de built-ins de SWRL en

especial Comparison built-ins y Date, Time and Duration Built-ins; capacidad de introducir

conocimiento externo a la base de hechos del razonador y clasificación incremental, y velocidad de

inferencia y carga óptimas. Además, es deseable que el razonador tenga tantas interfaces como sea

posible (OWL API, Jena, etc.), y cuya licencia de uso sea pública y de código libre.


118

Como se observa en la tabla comparativa, FaCT++ no soporta el lenguaje SWRL, por lo que se

descarta su uso. Por otra parte, Hoolet tiene soporte de SWRL pero no permite la utilización de built-

ins en reglas SWRL, ni tiene capacidad de introducir conocimiento externo ni realiza clasificación

incremental, además de que no se dispone de una implementación desarrollada y probada de este

razonador, sino tan sólo de un prototipo sencillo disponible para Linux, cuya última versión data del

año 2004. Por ello, también se descartaría su uso en el AIRS propuesto.

Por su parte, KAON2 y RacerPro 1.9.0 no soportan los built-ins de SWRL y presentan problemas a la

hora de cargar ontologías con reglas SWRL, por lo que quedarían descartados.

Bossam, Pellet 2.3.1 y RacerPro 2.0, realizan clasificación incremental, y soportan SWRL y sus built-

ins más comunes. Realizando una comparación entre los tres, se podría concluir que Pellet 2.3.1 es

la mejor opción para el AIRS basado en ontologías, puesto que posee un mayor nivel de soporte de

los built-ins de SWRL que Bossam y RacerPro 2.0, presenta capacidad de introducir conocimiento

externo, tiene una mayor usabilidad (OWL API, Jena, plugin directo en Protégé, utilizable en todas las

plataformas (Windows, Linux, MAC OS X)…), y está desarrollado en Java, lenguaje usado en el

desarrollo e implementación del código del sistema de respuesta propuesto. Además, sus tiempos de

inferencia y carga son mucho menores que los de Bossam, y tiene licencia libre de código abierto, a

diferencia de RacerPro.

3.5 Conclusiones

En el entorno de la Web Semántica [Berners-Lee01] existen numerosos grupos de investigación

estudiando las ventajas de trabajar con lenguajes de ontologías, su aplicabilidad, limitaciones,

problemas, etc. A día de hoy, se han desarrollado numerosas herramientas para la edición de

ontologías, validación (comprobación de integridad sintáctica y semántica), inferencia de

conocimiento, realización de consultas, etc. Existe un gran camino recorrido en materia de ontologías

en la Web Semántica, resultando en diferentes propuestas y estándares por parte del W3C.

En este capítulo se describen diferentes lenguajes formales de representación de ontologías (OWL,

RDF, DAML+OIL, etc.), varios lenguajes de especificación de políticas o reglas en el ámbito de la

Web Semántica (SWRL, REI, KAoS, SWSL, etc.) y los razonadores semánticos existentes que

permiten obtener nueva información en base a hechos y condiciones.

A la hora de especificar conocimiento o información, se pueden utilizar lenguajes formales, como los

descritos en el capítulo, o lenguajes normales. Los beneficios de utilizar una semántica formal son:

- Definición y clarificación precisa de la semántica del lenguaje.

- Posibilidad de razonar computacionalmente con los elementos de información y extraer

conclusiones, lo que permite:

Inferir nueva información no establecida explícitamente.

Comprobar la consistencia de los modelos de conocimiento definidos, es decir, que

los elementos de información son coherentes con las restricciones.

Verificar la corrección de los modelos de información, es decir, que el uso que se

hace del lenguaje es coherente con su semántica.

Y todo ello, con el apoyo de herramientas que pueden interpretar de forma rigurosa el

significado de los modelos de información definidos.

En relación con los requisitos para la definición de comportamiento, los lenguajes formales de

ontologías presentan algunas ventajas que se detallan a continuación [Guerrero07].

- Como consecuencia de la flexibilidad y extensibilidad inherente a los lenguajes de la Web

Semántica, todos estos lenguajes de descripción de comportamiento aportan una gran

flexibilidad en cuanto a que permiten trabajar con abstracciones de diferentes dominios, y son


119

muy expresivos. Las definiciones del comportamiento de un sistema de respuesta automática

mediante ontologías permiten que un sistema inteligente pueda razonar sobre dichas

definiciones. Además, permite calcular dinámicamente la relación entre distintos

componentes del dominio modelado y es posible acceder a la información mediante consultas

al modelo de ontologías, en lugar de ofrecer consultas predefinidas como los lenguajes

tradicionales.

- La utilización de ontologías está orientada al intercambio de información semántica entre

dominios independientes, lo que permite una mayor integración e interoperabilidad entre los

AIRSs o elementos de diferentes dominios en entornos de respuesta colaborativos. Estos

lenguajes de definición del comportamiento basados en ontologías aportan un alto grado de

expresividad semántica, una gran flexibilidad de desarrollo e implantación, y permitirán el

diseño de nuevas automatizaciones más inteligentes.

La siguiente tabla elaborada por Guerrero [Guerrero07] muestra una comparativa entre lenguajes

semánticos y no semánticos de definición de reglas.

Tabla 3.5 Análisis comparativo entre lenguajes semánticos y no semánticos de políticas [Guerrero07].

Lenguajes Semánticos Lenguajes No

Semánticos

Abstracción Múltiples niveles,

simultáneamente Niveles medio y bajo

Extensibilidad Fácil y en tiempo de ejecución Complejo y necesario

recompilar

Expresividad Alta Media o baja

Interoperabilidad Mediante ontología común Mediante interfaces

Aplicación del resultado Compleja Fácil

Ámbito de aplicación Entornos heterogéneos Entornos específicos

Las ventajas que se espera obtener para la especificación del comportamiento de un AIRS mediante

la aplicación de las técnicas de representación de comportamiento mediante ontologías son:

- Facilidad de aplicación, ya que las políticas estarán definidas en un mismo lenguaje de

ontologías, interpretable por un mismo gestor semántico con un motor de inferencias y de

reglas

- Mejoras de expresividad para la especificación de los diferentes tipos de políticas: obligación,

autorización, etc.

- Ventajas en cuanto a la flexibilidad y extensibilidad de las definiciones y posibilidad de

introducir cambios de políticas de forma dinámica

- Posibilidades de razonamiento sobre las especificaciones de comportamiento que mejoren el

tratamiento actual de políticas: detección de conflictos, inconsistencias de información, etc.

- Posibilidad de trabajar desde un mismo sistema de gestión con ontologías de diferentes

niveles de abstracción: nivel de gestión de red y sistemas, nivel de gestión de servicios, nivel

de gestión de negocio

Por tanto, las ontologías son un mecanismo que provee de una comprensión compartida y

consensuada del conocimiento dentro de un dominio. Esta comprensión puede ser comunicada entre

personas o entre sistemas heterogéneos, como es el caso de diferentes sistemas de detección de

intrusiones tanto a nivel de host como de red que generan y envían alertas a un AIRS.

Capítulo 4: Propuesta de Arquitectura de un Sistema de Respuesta a Intrusiones basado en Ontologías

121

PROPUESTA DE ARQUITECTURA DE UN Capítulo 4

SISTEMA DE RESPUESTA A INTRUSIONES

BASADO EN ONTOLOGÍAS

4.1 Introducción

Los Sistemas de Respuesta a Intrusiones (Intrusion Response Systems, IRSs) son dispositivos de

seguridad responsables de inferir y ejecutar una acción de respuesta frente a intrusiones detectadas

por otros dispositivos de seguridad como los IDSs. Un IRS no se limita a acciones de bloqueo sobre

dispositivos en línea, sino que dispone de un amplio catálogo de acciones de respuesta que se

pueden ejecutar sobre otros componentes de seguridad. De forma general, un IRS tiene tres

componentes principales: el conjunto de entradas (compuesto por un conjunto de eventos, tales como

informes de intrusión procedentes de los IDSs u otras fuentes de detección, información de

seguridad, etc.), un proceso de razonamiento que infiere la respuesta más adecuada en función de

las entradas, y un conjunto de acciones de respuesta que pueden ser elegidas para mitigar el ataque.

Dentro de los IRSs, los AIRSs, son aquellos sistemas de respuesta cuya reacción es automática, es

decir, responden al ataque de forma inmediata sin necesidad de intervención del administrador del

sistema. En este tipo de tecnologías de defensa perimetral es el propio sistema el que selecciona y

ejecuta la respuesta más adecuada, reduciendo en gran medida la ventana de tiempo de reacción

Debido al gran aumento acaecido en los últimos años del número y sofisticación de ataques

informáticos, y a que la velocidad de propagación de los mismos es cada vez mayor, es necesario

reducir el tiempo entre detección y reacción, y mejorar la precisión y eficacia de las reacciones de

respuesta implementadas, además de una automatización de las mismas. Por ello, dentro de las

tecnologías de defensa perimetral los sistemas de respuesta automática frente a intrusiones o

también llamados AIRSs (Automated Intrusion Response Systems) junto con los IPSs son en la

actualidad un área de gran interés en investigación y desarrollo dentro del ámbito de la seguridad

informática.

4.1.1 Antecedentes y motivación

En los últimos años se han propuestos varias arquitecturas de AIRSs, así como diferentes

taxonomías de sistemas de respuesta automática frente a intrusiones, como por ejemplo las

propuestas por Stakhanova [Stakhanova07b] y Shameli-Sendi [Shameli-Sendi12 ]. Como se indica

previamente, de acuerdo con estas taxonomías, los AIRSs se pueden clasificar en función de cuatro

dimensiones, a los que se ha creído conveniente añadir otras dos:

- Tiempo de respuesta: estático o proactivo.

- Según capacidad de adaptación: estático y adaptativo.


122

- Según mecanismos de selección de la respuesta: estático, dinámico, sensible al coste de las

respuestas.

- Según el modelo de evaluación del coste de la respuesta: modelo estático, modelo de

evaluación estática y modelo de evaluación dinámica.

- Rapidez de reacción: lento y rápido.

- Capacidad de coherencia semántica.

Teniendo en cuenta las seis dimensiones en función de las cuales se puede clasificar un AIRS, lo

ideal sería que este fuera proactivo, adaptativo, sensible al coste de las respuestas y con un modelo

de evaluación dinámica, rápido y semánticamente coherente.

Del análisis comparativo realizado previamente, se extrae que cada uno de los AIRSs estudiados

posee una arquitectura, un mecanismo de inferencia de la respuesta(s) óptima(s) y unas métricas

diferentes, aunque el objetivo a alcanzar sea un objetivo común: mitigar el ataque o reducir su

impacto. En función de su arquitectura y principio de funcionamiento cumplen en mayor o menor

medida las características deseables, pero ninguno aborda todas a la vez, como se observa en la

Tabla 2.3.

En especial, se observa que ninguno de los AIRSs excepto IDAM&IRS aborda el problema de la

coherencia semántica en la representación de alertas, rasgo especialmente relevante y crítico a

cumplir por un AIRS.

IDAM&IRS posee un módulo que permite correlar las alertas recibidas con el fin de descartar

duplicados o falsas alarmas. Cuando un IDS detecta una intrusión, antes de agregar y correlarla el

sistema transforma esta alerta a un formato de datos uniforme, como por ejemplo IDMEF, por lo que

se podría considerar que este sistema tiene en cuenta la semántica de las alertas,

independientemente de que su origen sea una fuente de detección diferente, y la sintaxis de las

mismas sea distinta. No obstante, se limita a parsear las alertas al formato IDMEF, y no utiliza

lenguajes formales de representación del conocimiento, lo que limita la expresividad. Además, este

sistema es lento, no adaptativo y estático (no proactivo).

Debido a que ninguno de los AIRSs existentes satisface las seis características ideales en un AIRS, y

que ninguno de ellos aborda por completo la representación formal de la información relativa al

proceso de reacción frente a una intrusión, se propone como contribución original de esta tesis

doctoral una arquitectura de AIRS basado en ontologías y en herramientas de la Web Semántica,

como son los lenguajes de representación de comportamiento o los razonadores semánticos.

Además, de satisfacer la propiedad de coherencia semántica, la arquitectura propuesta cumple el

resto de requisitos a excepción de la proactividad, que se plantea como línea futura a esta tesis.

4.2 Metodología

La propuesta se abordará siguiendo la siguiente metodología:

Propuesta: definición e implementación de una arquitectura de un AIRS basada en

ontologías, lenguajes de definición del comportamiento y razonadores semánticos. La

introducción y motivación de esta propuesta se encuentra en la Sección 4.1.

Evaluación de alternativas: se analizan las ventajas de utilizar ontologías y lenguajes de

reglas como base de un sistema de respuesta automática frente a intrusiones. Este análisis

se encuentra en la Sección 4.3.

Formalización: Descripción detallada de la arquitectura propuesta, describiendo los aspectos

más relevantes del diseño e implementación de cada uno de los componentes de la

arquitectura. La ontología se presenta en la Sección 4.4.


123

Verificación y Validación: Validación de la arquitectura propuesta desde el punto de vista de

escalabilidad y rendimiento. Esta validación se presenta en el Capítulo 8.

4.3 Evaluación de alternativas

En este capítulo se propone el uso de ontologías y lenguajes formales de reglas como base de un

AIRS. Las ventajas principales de las ontologías son:

- Permiten la compartición de la información sin ambigüedades entre distintas personas, o

entre aplicaciones, lo que facilita las interacciones entre distintas aplicaciones.

- Permiten reutilizar el conocimiento, debido a que las ontologías se pueden construir a partir

de otras, o incluso en el caso de ontologías grandes se pueden integrar directamente partes

más pequeñas ya implementadas.

- Formalizan el conocimiento sobre un dominio, de una manera que sea fácilmente entendible

por todos.

- Separan el conocimiento del dominio del conocimiento operacional.

- Permiten la inferencia automática de información.

- Permiten analizar el conocimiento que se tiene del dominio mediante métodos formales.

Debido a estas ventajas y a su gran expresividad, actualmente, se utilizan en muchas áreas de

investigación, como por ejemplo en la seguridad en redes informáticas.

Como se ha indicado, una de las principales ventajas de utilizar ontologías para modelar información

es que su semántica ha sido formalizada. Este rasgo es muy relevante en entornos donde diferentes

modelos de información son utilizados y algunos elementos del entorno tienen que manejar

definiciones expresadas en diferentes formatos o modelos de información. En esa situación, ese

elemento podría no ser capaz de reconocer el mismo concepto definido en diferentes modelos de

información, tratándolo como conceptos diferentes. Una posible solución sería mantener una gran

cantidad de código de comportamiento uno por cada modelo de información en el que se expresan

los conceptos, pero esta es una solución poco escalable de abordar el problema. El uso de ontologías

proporciona una manera sencilla de simplificar ese problema, el de la heterogeneidad: una ontología

formaliza los aspectos de la semántica dentro de la propia definición de los conceptos, por lo que es

posible encontrar algún método automático o semiautomático que parsee conceptos definidos en

modelos de información heterogéneos a conceptos definidos en la ontología, como por ejemplo el

método M&M (Merge and Map), propuesto en [LopezDeVergara04]. Este método se basa en el

método detallado por Noy y Musen, pero los autores lo han adaptado el caso de la gestión de red y

sistemas. En el trabajo referenciado, el método M&M es adaptado al área de reacción frente a

intrusiones.

Dentro del ámbito de la presente tesis doctoral, el uso de ontologías ayuda a soportar la inclusión de

diferentes IDSs con formatos heterogéneos, cada uno con formatos y sintaxis de intrusión diferentes.

De esta forma, el AIRS podría comprender alertas heterogéneas y saber si estas alertas se refieren a

la misma intrusión o no. Hoy en día existen algunos estándares de formato de datos para la

representación de alertas, cuyo objetivo es resolver este problema, como IDMEF [IDMEF]. Este

formato se define un modelo de datos en el lenguaje de marcado extensible (XML), que permite la

representación, el intercambio y la difusión de información relativa de la detección de intrusiones.

Pero IDMEF sólo proporciona un formato de intercambio, sin ninguna representación adicional de

conocimiento que podría ser útil para el AIRS con el fin de correlar esta información con la

información adicional, tal como contexto de la red, reglas, etc.

Otra gran ventaja del uso de ontologías para el modelado de información es la posibilidad de definir

también en el mismo marco integrado con la información del objeto, el comportamiento de los objetos

definidos. Esta definición de comportamiento se puede expresar con una variedad de restricciones


124

(reglas, lógica, etc.) dependiendo de la ontología y el lenguaje específico elegido, pudiéndose integrar

con la definición de la información. Como se indicó en el Capítulo 3, el principal lenguaje de

especificación de ontologías es OWL2, y es el lenguaje elegido a utilizar en la definición de la

ontología que forma parte de la arquitectura del AIRS propuesto.

Para un sistema de respuesta es esencial además de la capacidad de poder representar

conocimiento, la capacidad de representar reacciones frente a eventos, por lo que se necesitan

lenguajes de especificación del comportamiento que puedan ser interpretados en conjunción con los

conceptos representados en las ontologías. Para definir comportamiento es muy útil la definición de

reglas, restricciones y políticas de seguridad. En el Capítulo 3 se incluye un análisis de los diferentes

lenguajes de reglas y políticas existentes. Para la especificación del comportamiento del AIRS basado

en ontologías se utilizarán reglas expresadas mediante SWRL. La elección de SWRL se debe a las

siguientes razones, algunas de las cuales fueron indicadas en el Capítulo 3 (Ver 3.3.7):

- Mayor nivel de integración con OWL/OWL2: el lenguaje SWRL tiene una integración directa

con OWL/OWL2, a diferencia de KAoS y REI que requieren de la importación de los objetos y

entidades del modelo de información sobre el modelo de definición de políticas, indicando los

actores, roles, y demás conceptos, lo cual incurre en cierta indirección a la hora de definir el

comportamiento.

- Representación de comportamiento más general: la representación de comportamiento

mediante axiomas OWL está limitada a la representación de ciertas restricciones

predefinidas, mientras que los lenguajes de reglas y políticas son aplicables de manera más

general. No obstante KAoS y REI están orientados a la representación de políticas con lógica

deóntica (políticas relacionadas con el deber y las normas: autorizaciones, denegaciones,

delegaciones, etc.), mientras que SWRL permite la definición de todo tipo de reglas,

permitiendo así abarcar definiciones de comportamiento más generales.

- Mayor nivel de expresividad: una ventaja de REI y de SWRL con respecto a KAoS es que

permiten el uso de parámetros variables entre el antecedente y el consecuente de la regla, lo

que permite que la regla se aplique sobre todos aquellos ejemplares que cumplan

determinada condición. SWRL permite mayor expresividad para la composición de

condiciones en el antecedente de las reglas que KAoS o REI.

- Entorno de Ejecución: SWRL y REI no requieren de un motor de inferencias particular como

en el caso de KAoS. Además, el lenguaje SWRL está soportado por la mayoría de los

razonadores semánticos existentes.

- Mayor nivel de usabilidad: el utilizar un lenguaje como SWRL, de amplia difusión y en

constante evolución en el ámbito de la Web Semántica, permite reaprovechar las técnicas y

herramientas existentes y futuras en ese ámbito, sin la necesidad de diseñar editores,

validadores, motores de ejecución, etc., específicos para nuestro propósito, además de

garantizar una máxima integración con el lenguaje OWL y sus sucesivas versiones. Las

mejoras que la investigación vaya ofreciendo sobre estos lenguajes serán así directamente

aprovechables en el campo de la definición del comportamiento del AIRS así como de

métricas de seguridad.

- Mayor facilidad de uso: SWRL es un lenguaje de definición de reglas y no uno de políticas

como REI o KAoS. Los lenguajes de reglas son mucho más sencillos que los utilizados para

representar políticas, debido a que en estos últimos son necesarios mucho más elementos.

Por las razones expuestas, en esta Tesis Doctoral se utilizará el lenguaje OWL2 como lenguaje de

especificación de conocimiento y el lenguaje de reglas SWRL como lenguaje para la representación

de comportamiento del sistema de respuesta automática frente a intrusiones.


125

4.4 Propuesta de arquitectura de un AIRS basado en

ontologías

En esta sección se propone una arquitectura de un sistema de respuesta automática frente a

intrusiones, cuyo núcleo son las ontologías, y otras herramientas de la Web Semántica, como los

lenguajes de reglas y los razonadores semánticos.

4.4.1 Definición de la arquitectura de AIRS basado en ontologías

4.4.1.1 Requisitos

Previa a la definición y especificación de la arquitectura del AIRS basado en ontologías, se cree

conveniente enumerar los requisitos del sistema, cuyo objetivo es describir el comportamiento externo

del sistema que se va a desarrollar y sus restricciones operativas. Se distinguen varios tipos de

requisitos software:

- Requisitos funcionales: aquellos que definen las funciones del sistema o de sus

componentes. Pueden ser frases muy generales que definen acciones fundamentales que

debe realizar el sistema, y cómo debe reaccionar ante situaciones particulares.

- Requisitos no funcionales: aquellos que especifican restricciones que afectan a los servicios o

funciones del sistema, como por ejemplo, requisitos de rendimiento, seguridad, accesibilidad,

usabilidad, estabilidad, interoperabilidad, escalabilidad, etc.

- Requisitos de entrada: aquellos que especifican las entradas soportadas por el sistema.

- Requisitos de salida: aquellos que definen la(s) salida(s) proporcionada(s) por el sistema.

Para cada una de las categorías (funcionales, no funcionales, entrada y salida), en este apartado se

enumeran los requisitos a modo de referencia. Estas referencias son usadas para comentar por qué

han sido propuestos, esto es, qué objetivo cumplen. Es importante destacar que mediante estos

requisitos se listan las funcionalidades que el sistema debe cumplir. El cómo se consiga, a través de

unos componentes u otros, o funcionalidades secundarias, no se refleja en este análisis de requisitos.

Otra consideración a realizar, es que los requisitos están asociados al AIRS como sistema global, es

decir, al conjunto de todos los módulos que componen su arquitectura. Los requisitos de algunos de

los módulos específicos, como por ejemplo, el módulo de ejecución de acciones de respuesta y el

módulo de evaluación del éxito de la acción de respuesta, se incluyen en capítulos o secciones

posteriores donde se definen y especifican.

Requisitos funcionales y no funcionales

Los requisitos funcionales del AIRS basado en ontologías son los que aparecen recogidos en la

siguiente tabla:

Tabla 4.1 Requisitos funcionales del AIRS basado en ontologías.

Ref. Requisito

REQF01 El sistema responderá a ataques de red

REQF02 El sistema responderá a ataques de host

REQF03 El sistema prevendrá ataques futuros (es proactivo)

REQF04 El sistema tendrá en cuenta la efectividad o éxito de las respuestas en el pasado (es


126

adaptable)

REQF05 El sistema será lo más rápido posible

REQF06 El sistema tendrá en cuenta el impacto del ataque (su coste)

REQF07 El sistema tendrá en cuenta el coste o impacto causado por el despliegue de una

respuesta

REQF08 El sistema comprenderá la semántica de las alertas

REQF09 El sistema tendrá en cuenta la relevancia del activo comprometido

REQF10 El sistema tendrá en cuenta el contexto asociado a cada escenario de intrusión

REQF11 El sistema considerará las alertas en función de la confianza o fiabilidad de los IDSs

que las generan

REQF12

El sistema proporcionará los resultados un histórico de alertas y respuestas para su

uso en escenarios colaborativos. Este histórico contendrá información sobre el tipo de

amenaza, tipo de activo atacado, respuesta ejecutada y eficacia de la respuesta

REQF01 y REQF02 responden a la necesidad de un AIRS que actúe contra todo tipo de intrusiones,

ya que las alertas provendrán tanto de NIDS (IDS de red) como de HIDS (IDS de host).

Los requisitos REQF03 a REQF07 abarcan cuatro de las características deseables de todo AIRS,

esto es, proactividad, adaptabilidad, rapidez y consideración de impacto de las respuestas, que son

objetivos prioritarios de este estudio. La necesidad de dotar al razonador del sistema de respuesta

frente a intrusiones de cierta capacidad para entender la semántica de las alertas y poder responder

así de igual forma a diferentes manifestaciones de un mismo ataque es también un objetivo prioritario.

Esto se refleja en el REQF08.

Un requisito imprescindible (REQF09) es el hecho de que el sistema valore la importancia que tiene

cada activo para la organización (en sus 4 dimensiones de seguridad: confidencialidad, integridad,

disponibilidad y autenticidad), y tenga en cuenta dicha relevancia en el proceso de inferencia de la

respuesta óptima, ya que no es lo mismo responder a ataques que comprometan un host de usuario

sin información relevante, a que comprometan la base de datos de la organización que contiene

información confidencial.

REQF10 y REQF11 ponen de manifiesto el hecho de que para la elección de la respuesta se tiene en

cuenta el contexto del sistema en el momento de la detección y el grado de confianza y criticidad del

IDS que genera las alertas.

Finalmente, REQF12 está asociado al posible funcionamiento del AIRS en un entorno colaborativo,

para lo que debe proporcionar un histórico con información relacionada a cada alerta de intrusión

recibida por el AIRS.

Los requisitos no funcionales del sistema de respuesta se recogen en el apartado correspondiente a

la implementación del prototipo del AIRS basado en ontologías, situado en el Capítulo 8 (Ver Tabla

8.1).

Requisitos de entrada

Los requisitos de entrada del AIRS basado en ontologías son los que se recogen en la siguiente

tabla.


127

Tabla 4.2 Requisitos de entrada del AIRS basado en ontologías.

Ref. Requisito

REQE01 El sistema aceptará entradas en diversos formatos sintácticos

REQE02 El sistema aceptará entradas de otros AIRSs y SIEMs para un futuro funcionamiento

colaborativo

REQE03 Las entradas pueden incorporar contenidos que proporcionen semántica

En lo que a la entrada se refiere, esta podrá venir de diferentes fuentes de IDS para las que el

formato o sintaxis de sus mensajes de alerta diferirá unos de otros. Se debe poder atender a todos

ellos (REQE01).

El REQE02, por su parte, viene a decir que no solo los IDS podrán generar información de entrada al

AIRS, y que sistemas integrales de gestión de la seguridad, por ejemplo, podrán enviar alertas de

naturaleza mucho más compleja para que se les dé una respuesta. Además, los AIRSs también

podrán enviarse información entre ellos de manera que puedan comunicarse cambios en sus políticas

de respuesta o inferencias a las que hayan podido llegar.

Por último, un requisito (REQE03) necesario para que el razonador del AIRS pueda dar solución al

problema de la incoherencia semántica, es que las alertas dispongan de campos cuyo contenido

pueda proporcionar directamente semántica acerca del ataque o al menos sirvan para poder

modelarla.

Requisitos de salida

Por último, los requisitos de salida se recogen en la Tabla 4.3.

Tabla 4.3 Requisitos de salida del AIRS basado en ontologías.

Ref. Requisito

REQS01 El sistema podrá generar múltiples tipos de respuesta en base a un catálogo de

respuestas

REQS02 Las respuestas serán reactivas (activas o pasivas) o proactivas

REQS03 El sistema generará registros históricos de ataques y respuestas

REQS04 El sistema enviará eventos a otros AIRSs para un futuro funcionamiento colaborativo

Los requisitos REQS01 y REQS02 hacen referencia a las respuestas propiamente dichas del AIRS.

Con el primero se quiere dar a entender que habrá un catálogo o taxonomía de respuestas del que se

escogerá la más apropiada. El segundo, hace mención a una de las características de estas

respuestas, esto es, la naturaleza de la misma: activa quiere decir que se responderá al ataque de

manera automatizada, en tiempo real y con medios concretos; pasiva, que como mucho se notificará

la respuesta que se habría de tomar, pero sin ejecutarla; mientras que una respuesta proactiva es

aquella que se toma para evitar posibles futuros ataques.

En cuanto a generar registros de históricos tanto de alertas recibidas como de las respuestas

generadas (REQS03), decir que son necesarias para poder trazar la actividad del AIRS y analizar su

correcto funcionamiento. Además, estos históricos podrán ser utilizados en un entorno de respuesta

colaborativa, en el que otros AIRSs tendrán acceso al histórico generado por el resto de AIRS en la


128

red de colaboración. De esta manera se facilita y posibilita la intercomunicación entre diferentes

AIRSs para compartir información (REQS04)

4.4.1.2 Diseño e implementación de la arquitectura

Una vez definidos los requisitos funcionales, de entrada y de salida del sistema de respuesta

automática frente a intrusiones, el objetivo de este punto es presentar los aspectos más relevantes

del diseño de su arquitectura.

La arquitectura propuesta [Mateos10] cumple todos los requisitos previamente definidos, a excepción

del REQF03 relativo a característica de proactividad del AIRS (sobre esto se propone una nueva línea

de investigación, como se verá en el Capítulo 9). En la Figura 4.1, se observa que la arquitectura

consta de 12 componentes, 1 componente externo (los IDSs presentes en la arquitectura de red de la

organización que proporcionan las entradas al sistema de respuesta) y 11 componentes principales

de la arquitectura: Receptor de Alertas (Alerts Receiver), Contexto de Red (Network Context),

Contexto de Sistemas (System Context), Receptor de información de Contexto (Context Receiver),

Ontología de Respuesta a Intrusiones (Intrusion Response Ontology), Políticas (Policies), Razonador

(Reasoner), Catálogo de Acciones de Respuesta (Response Toolkit), Ejecutor de Acciones de

Respuesta (Responses Executor), Evaluador del éxito de Acciones de Respuesta (Intrusion

Response Evaluation. Success Indicators) e Interfaz de Administración (Admin Interface). Cada uno

de los módulos funciona de manera independiente y para su comunicación basta con conocer las

interfaces de entrada y salida respectivas.

Figura 4.1 Arquitectura del AIRS basado en ontologías [Mateos10]

La arquitectura propuesta es una arquitectura modular donde se pueden identificar cuatro módulos

bien diferenciados: módulo de recopilación de información (IDSs, Contexto de Red, Contexto de

Sistemas, Receptor de Alertas, Receptor de Información de Contexto, y Ontología de Respuesta a

Intrusiones), módulo de razonamiento (Políticas y Razonador), módulo de ejecución de respuestas

(Catálogo de Acciones de Respuesta y Ejecutor de Acciones de Respuesta) y módulo de evaluación

(Evaluador del éxito de Acciones de Respuesta).

El objetivo de esta arquitectura es inferir la respuesta óptima de entre un conjunto de respuestas

disponibles en la organización, frente a intrusiones detectadas en cualquier lugar de la misma. A

rasgos generales y con el objetivo de dar una visión global del funcionamiento del sistema, el proceso

seguido es el siguiente: El administrador del sistema define un conjunto de respuestas especificando

la acción que desempeña, su coste, severidad, impacto, eficacia etc. Esta información acerca de las

respuestas predefinidas se incluye en la ontología de respuesta a intrusiones. Cuando un IDS de los

existentes en la red detecta una intrusión, envía una alerta de intrusión al AIRS, evento que


129

desencadena el proceso de inferencia. En dicho proceso, el Razonador ejecuta las Políticas o reglas

que especifican el comportamiento del sistema e infiere una de las respuestas previamente definidas,

teniendo en cuenta para ello la información contenida en la ontología de respuesta a intrusiones

relativa a la alerta de intrusión recibida, al contexto de la red y los sistemas en el momento de la

intrusión, al activo comprometido y a las acciones de respuesta. Los resultados inferidos son

enviados al Ejecutor de Acciones de Respuesta, que se encarga de ejecutarla. Finalmente, el

Evaluador del éxito calcula si la acción desplegada ha conseguido mitigar la intrusión o si, por el

contrario, no ha tenido ningún efecto sobre ella, realimentando esta información en la ontología de

respuesta a intrusiones para futuras ejecuciones.

Para el desarrollo e implementación de la arquitectura del sistema se han definido tres grandes

etapas:

- Fase 1: Desarrollo y especificación de la ontología de respuesta a intrusiones. Esta fase se

explica con detalle en el Capítulo 5.

- Fase 2: Definición de métricas de seguridad y políticas o reglas. Esta fase se divide en dos

partes:

Definición de métricas de seguridad y su especificación mediante SWRL (Ver

Capítulo 6).

Especificación de reglas o políticas que determinen el comportamiento del AIRS, es

decir, que rijan el proceso de inferencia. Estas políticas son modeladas mediante

reglas SWRL. (Ver 4.4.3).

- Fase 3: Implementación de los componentes de la arquitectura. Como resultado de esta fase

se obtiene un prototipo de sistema implementado principalmente en Java. A lo largo de la

memoria se incluyen los detalles más relevantes del diseño de los principales componentes

de la arquitectura del AIRS basado en ontologías. La implementación del prototipo del AIRS

se aborda en el Capítulo 8, correspondiente a la validación de las propuestas.

A continuación se describe cada componente presente en la arquitectura y la función que desempeña

en el proceso de inferencia.

IDSs

Los IDSs son sistemas de detección de intrusiones que se encuentran distribuidos en la red de la

organización, cuyo objetivo es detectar comportamiento anómalo y enviar el informe de intrusión

correspondiente al AIRS basado en ontologías, concretamente al Receptor de Alertas. Este informe

contiene parámetros relativos al ataque detectado, entre los que se encuentran el tipo de intrusión o

la dirección IP a la que va dirigida el ataque, parámetros necesarios para el correcto funcionamiento

del sistema de respuesta. La arquitectura soporta cualquier tipo de IDS (Ver sección 2.2.2), pero en la

validación de la misma se han usado NIDSs y HIDSs. Detalles acerca de la integración de distintos

IDSs específicos con la arquitectura así como del formato de alerta de intrusión utilizado, se

proporcionan en el capítulo correspondiente a la validación de la propuesta (Ver Capítulo 8).

Cabe también indicar que los IDSs son componentes externos a la arquitectura del sistema de

respuesta que pueden estar localizados en hosts distintos al host donde reside el AIRS o en el mismo

host. A pesar de ser externos, son una pieza fundamental para el funcionamiento del sistema de

respuesta, ya que su función es desencadenar el proceso de inferencia de la respuesta cada vez que

detectan comportamiento anómalo en la red de la organización.

Receptor de Alertas (RA)

Este componente de la arquitectura recibe las alertas de intrusión procedentes de diferentes IDSs o

fuentes de alertas con diferentes formatos y sintaxis, y mapea los conceptos incluidos en estas

alertas de intrusión a los conceptos equivalentes definidos en la ontología. De esta manera,

conceptos semánticamente equivalentes pero sintácticamente diferentes se mapean a un mismo


130

concepto en la ontología, en el caso en que el AIRS reciba dos informes de intrusión relativos a la

misma intrusión de diferentes fuentes con sintaxis diferente.

Este componente se encarga, pues, de recibir y mapear cualquier alerta de intrusión enviada por

cualquier fuente de detección con formato diferente a un formato de alerta común, comprensible por

el razonador del AIRS propuesto.

Entre los requisitos del RA se resalta que debe ser capaz de recibir alertas de intrusión procedentes

de distintos tipos de IDSs, como por ejemplo de NIDSs y de HIDSs.

Detales sobre la implementación de este componente se proporcionan en el capítulo de validación

(Ver Capítulo 8).

Contexto de Red y Contexto de Sistemas

Estos componentes de la arquitectura tienen como función capturar y analizar información del

contexto en tiempo real, cada vez que una nueva intrusión ha sido detectada y el AIRS ha recibido

una alerta de intrusión. La diferencia entre ambos componentes es el tipo de información que

capturan.

El Contexto de Red captura el tráfico en la red de la organización y para cada paquete analiza

diferentes parámetros tales como fecha, tipo de protocolo, dirección IP origen, puerto origen,

dirección IP destino, puerto destino, y número de bytes recibidos y transmitidos. Una vez obtenidos

estos parámetros en tiempo de intrusión, calcula un parámetro denominado Anomalía de Red

(Network Anomaly) que indica el grado de anomalía o anormalidad de la red respecto a un estado de

funcionamiento habitual. Para ello, compara los indicadores obtenidos en el momento del ataque con

un perfil o patrón del tráfico de la red previamente generado.

Por su parte, el Contexto de Sistemas compara el valor de varios indicadores del sistema

comprometido antes y después de la intrusión, como pueden ser el número de procesos activos en el

sistema, el uso de la CPU, el número de procesos zombies, el espacio libre en disco, el número de

usuarios logueados, el estado del sistema, el número de intentos fallidos de conexión por SSH o la

latencia del sistema. Al igual que en el contexto de red, es necesario generar un perfil o patrón del

contexto relativo a cada sistema en tiempo normal de operación, previamente. En el momento de

intrusión, este componente se encarga de comparar el valor de cada indicador con su valor en el

perfil y obtener el grado de anomalía existente.

Ambos componentes son invocados por el Razonador del sistema, cuando este ha recibido una alerta

de intrusión mapeada al formato común, y ha comprobado que es necesario inferir una acción de

respuesta frente a la intrusión detectada. El Razonador, antes de invocar a los módulos de contexto,

comprueba que la alerta recibida no es una alerta repetida ni es continuación de un ataque existente,

para lo que utiliza métricas de seguridad (Ver Capítulo 6) y reglas o políticas especificadas mediante

SWRL. Como ya se indica en varias ocasiones a lo largo de la memoria, una de las ventajas de

utilizar ontologías y lenguajes de definición de comportamiento formales, radica en que permiten

solventar el problema de la coherencia semántica que poseen otros AIRSs estudiados, de tal forma

que alertas recibidas por el AIRS con diferentes sintaxis y formatos pero referidas a la misma

intrusión, sean consideradas como una única alerta.

Estos componentes se describen más detalladamente en el apartado 4.4.2 del presente capítulo.

Receptor de Contexto

Componente de la arquitectura que recibe la información relativa a la anomalía en el contexto de red

y de sistemas procedentes de los módulos encargados de obtenerla, y mapea dicha información a los

conceptos equivalentes definidos en la ontología. Una vez que la información ha sido convertida a

lenguaje OWL2, este componente devuelve el control al Razonador para que comience el proceso de

inferencia propiamente dicho.


131

Ontología de Respuesta a Intrusiones

Componente fundamental en la arquitectura del AIRS basado en ontologías, cuya función es definir y

especificar formalmente toda la información necesaria en el proceso de inferencia de la respuesta

óptima frente a una intrusión llevado a cabo por el AIRS. Así pues, la ontología define formalmente

conceptos como alerta de intrusión, tipo de amenaza, acción de respuesta, contexto de red y

sistemas, etc.

La especificación de la ontología constituye una de las contribuciones principales de esta tesis

doctoral, y es abordada en detalle en el Capítulo 5.

Como se deriva de las conclusiones del capítulo anterior, el lenguaje utilizado para especificar la

ontología es el lenguaje estándar de la Web Semántica OWL2.

La definición y especificación de la ontología es primordial para el correcto funcionamiento del AIRS

ya que en ella reside toda la información utilizada por el Razonador para inferir la respuesta óptima.

Se puede considerar, que junto con las Políticas o reglas y el propio Razonador, es el principal

componente del sistema.

Políticas o Reglas

Las políticas o reglas tienen el objetivo de especificar el comportamiento del AIRS, es decir, de

gobernar el proceso de inferencia de la respuesta óptima llevado a cabo por el Razonador.

En el Capítulo 3, se incluye un análisis comparativo de los diferentes lenguajes formales de

especificación del comportamiento existentes. Como se indica en la Evaluación de Alternativas

incluida en este capítulo, se ha elegido el lenguaje SWRL [Horrocks04] como lenguaje para la

especificación de las políticas y reglas de la arquitectura propuesta.

Las reglas constituyen las pautas en función de las cuales y partiendo de un conjunto de

conocimientos previos, el Razonador infiere la respuesta más conveniente para una determinada

intrusión, en un determinado lugar, y en un determinado momento. La contribución de este

componente al funcionamiento del sistema es, por tanto, crucial.

Añadir además que estas reglas SWRL permiten modelar y especificar aquellas métricas de

seguridad propuestas que impongan pautas al comportamiento del AIRS. En un AIRS hay muchos

parámetros susceptibles de ser medidos, como por ejemplo, la confianza en el IDS, el impacto de la

intrusión, el coste, el impacto y la eficacia de la respuesta, la elección de la respuesta óptima, la

fiabilidad de la alerta de intrusión, etc. Para obtener el valor de estos parámetros es necesario utilizar

métricas. Uno de los pasos importantes en la definición e implementación de la arquitectura del

sistema de respuesta propuesta, es la definición de las métricas de seguridad necesarias para

obtener aquellos parámetros involucrados en el proceso de inferencia de la respuesta óptima que

requieren ser medidos. La definición y especificación de estas métricas constituye otra de las

contribuciones principales de la presente tesis doctoral, y es abordada con más detalle en el Capítulo

6. Como se indica en dicho capítulo, se distingue entre dos tipos de métricas:

- Aquellas que se ejecutan de manera independiente al proceso de inferencia de la respuesta

óptima. Este tipo de métricas pueden ser ejecutadas por el propio sistema de forma

automática o por el administrador de forma manual, y no requieren de su especificación

mediante reglas SWRL porque no forman parte del conjunto de políticas de la arquitectura del

sistema. Ejemplo de estas métricas es la métrica utilizada para obtener el impacto de la

intrusión en el sistema.

- Aquellas que se ejecutan como parte del proceso de inferencia de la respuesta óptima, y que

determinan el comportamiento del AIRS. Este tipo de métrica siempre es ejecutada de forma

automática por el Razonador del sistema en tiempo de inferencia, y es necesario

especificarlas mediante el lenguaje de reglas SWRL. Estas métricas dan lugar a un conjunto

de reglas o políticas que utiliza el Razonador para inferir la respuesta óptima. Ejemplo de

estas métricas es la métrica utilizada para la elección de la respuesta óptima.


132

Además de las reglas que permiten especificar métricas de seguridad, se incluyen otro conjunto de

políticas que imponen condiciones o restricciones al AIRS, y que son parte fundamental del proceso

de inferencia.

Estas políticas permiten además, la consecución de los objetivos a cumplir por un AIRS ideal:

coherencia semántica, adaptación, proactividad, sensibilidad al coste de las respuestas y rapidez.

Debido a su gran relevancia para el sistema, este componente se describe más detalladamente en el

apartado 4.4.3 del presente capítulo.

Razonador

Es el componente principal de la arquitectura, cuya función es inferir la respuesta óptima ante una

intrusión detectada por alguno de los IDSs existentes en la red de la organización. Teniendo en

cuenta las políticas definidas previamente por el administrador del sistema y los ejemplares de la

ontología que representan la información acerca de las respuestas, la información de contexto,

alertas de intrusiones, etc., el razonador ejecuta el proceso de inferencia para determinar la respuesta

óptima a una intrusión específica en un lugar y tiempo específicos.

Como se indica en el Capítulo 3, además de definir formalmente los conceptos que modelan un

dominio mediante lenguajes de definición del conocimiento, y definir un conjunto de reglas o políticas

que se apliquen sobre dicho dominio mediante lenguajes de especificación del comportamiento, es un

requisito imprescindible que se pueda razonar sobre dicho dominio e inferir nueva información. Para

ello, es necesario un mecanismo que permita inferir información a partir del conocimiento almacenado

en la base de conocimiento, como son los razonadores semánticos. Hoy en día, existen diferentes

razonadores semánticos que pueden ser utilizados como el núcleo del AIRS. Tras el análisis

comparativo realizado en el Capítulo 3 (Ver 3.4.7), se elige Pellet como razonador semántico a

utilizar en la arquitectura de AIRS propuesta, como se verá en el Capítulo 8.

En este punto es necesario aclarar que el componente Razonador presente en la arquitectura del

sistema, no es solamente el razonador semántico Pellet. Es decir, el término Razonador incluye al

propio Razonador semántico Pellet, además de código escrito Java que permite realizar una serie de

funciones entre las que destacan:

- Comprobar la similitud o continuación de una alerta de intrusión: cuando recibe una alerta de

intrusión en formato común procedente del Receptor de Alertas, comprueba si la nueva alerta

recibida se corresponde con una alerta ya recibida por el sistema, o si se corresponde con

una alerta de un ataque ya existente. Para ello, se utiliza el lenguaje SPARQL que permite

realizar consultas sobre la información almacenada en la ontología, como se detalla en la

implementación del prototipo del sistema.

- Invocar a los módulos de contexto de red y de sistemas para obtener el grado de anomalía en

un determinado momento.

- Inferir las respuestas recomendadas y la respuesta óptima: esta función es su función

principal, y es en este punto donde se hace uso del razonador semántico Pellet para razonar

sobre el domino modelado en la ontología utilizando las reglas y políticas definidas, y de esta

forma inferir nueva información.

- Extraer el nuevo conocimiento inferido. Para ello, se hace uso de Jena, un API de Java

soportado por Pellet, que permite extraer datos de grafos RDF.

- Invocar al Ejecutor de Acciones de Respuesta una vez que la respuesta óptima ha sido

inferida, proporcionándole los parámetros requeridos para desplegarla.

- Invocar al Evaluador del éxito de Acciones de Respuesta para evaluar el éxito de la acción

una vez finalizada su ejecución, proporcionándole los parámetros requeridos por dicho

componente.

- Obtener información de la ontología de respuesta a intrusiones mediante Jena.


133

- Actualizar la información inferida (respuesta óptima, éxito de la respuesta…) en el fichero owl

correspondiente a la ontología de respuesta a intrusiones, de forma que esta nueva

información se tenga en cuenta en posteriores inferencias. Para escribir en el fichero owl se

utiliza Jena.

- Actualizar el nuevo resultado obtenido en el histórico de intrusiones y respuestas

correspondiente, de cara a un posible funcionamiento en entornos colaborativos.

Como se observa en la arquitectura, este componente es el centro de la misma, es el núcleo del AIRS

basado en ontologías. El resto de componentes de la arquitectura interaccionan con él, bien

proporcionándole entradas, bien haciendo uso de los resultados inferidos por el Razonador.

Catálogo de Acciones de Respuesta

Componente también denominado Response Toolkit, cuya función es proporcionar a los

componentes de la arquitectura que lo requieran el conjunto o listado de acciones de respuesta

específicas, que están disponibles para reaccionar frente a una intrusión con el fin de mitigarla o

reducir el daño causado. Estas respuestas se ejecutan a través de diferentes componentes de

seguridad (routers, cortafuegos, IDSs, etc.) o a través de aplicaciones del sistema operativo

subyacente (tcpwrapper, cortafuegos local, comandos locales, etc.).

Más información sobre este componente se detalla en el apartado 4.4.4.

Ejecutor de Acciones de Respuesta

Componente de la arquitectura encargado de poner en marcha mecanismos reales para ejecutar la

respuesta inferida por el Razonador, proporcionando los argumentos e instrucciones necesarias a los

dispositivos de seguridad del sistema encargados de hacer efectiva la respuesta. Para ello, consulta

el catálogo de respuestas disponible, denominado en la arquitectura como Response Toolkit o

Catálogo de Acciones de Respuesta.

Una vez inferida la respuesta óptima, el Razonador, invoca a este componente, proporcionándole los

parámetros necesarios para la ejecución de la respuesta específica.

Una descripción más detallada de este componente se incluye en 4.4.5

Evaluador del éxito de Acciones de Respuesta

Componente denominado en la arquitectura como Intrusion Response Evaluation. Success Indicator,

cuyo objetivo es evaluar de forma automática si la respuesta ejecutada ha conseguido el objetivo de

mitigar la intrusión o reducir al mínimo su impacto, o por el contrario, no ha tenido efecto sobre el

ataque.

El Razonador es el responsable de invocar a este componente una vez que ha recibido un código de

que la respuesta ha finalizado su ejecución, código enviado por el Ejecutor de Acciones de

Respuesta. Como se indica en el Capítulo 2, en el apartado correspondiente al estudio y análisis de

mecanismos de evaluación del éxito existentes (Ver 2.5), no es tarea sencilla medir de forma

automática el éxito o eficacia de una respuesta. La metodología utilizada en la arquitectura de AIRS

basado en ontologías propuesto, consiste en comparar el grado de anomalía existente en el contexto

de la red y del sistema comprometido, antes y después de la ejecución de la respuesta, para lo que

se propone el uso de técnicas de la teoría de la información, como es el concepto de entropía. La

definición y especificación de una metodología de evaluación del éxito de una acción de respuesta,

así como el diseño e implementación de una arquitectura que aplique dicha metodología, es otra de

las contribuciones originales de esta tesis doctoral. La propuesta es abordada en detalle en el

Capítulo 7.


134

Interfaz de Administración

Componente que permite configurar el AIRS, ya sea mediante un GUI o por comandos, y visualizar

los resultados que se han ido produciendo a lo largo del tiempo. Una descripción más detallada de

este componente se incluye en Apéndice I.

Para que el AIRS basado en ontologías funcione correctamente, cada uno de los módulos debe ser

controlado de forma que sus funciones se ejecuten siguiendo una secuencia de acción.

Detalles de la implementación de los componentes que forman la arquitectura del AIRS basado en

ontologías propuesto se incluyen en el Capítulo 8, correspondiente a la validación de las propuestas.

De los 12 componentes que constituyen la arquitectura propuesta, la definición y especificación de

tres de ellos da lugar a diferentes propuestas de la presente tesis doctoral (Ontología de Respuesta a

Intrusiones, Políticas o métricas y Evaluador del éxito de Acciones de Respuesta), por lo que son

tratados en otros capítulos de la memoria de forma independiente. La definición de la Interfaz de

Administración se incluye como anexo (Apéndice I), y el Razonador ha sido ampliamente definido y

analizado en los Capítulos 3 y 4. Del resto de componentes, por su entidad propia e importancia para

el funcionamiento de la arquitectura del sistema de respuesta, a continuación se describen más en

profundidad cuatro de ellos: Contexto de Red, Contexto de Sistemas, Catálogo de Acciones de

Respuesta y Ejecutor de Acciones de Respuesta.

4.4.2 Módulo de contexto

Observando el contexto se puede llegar a determinar si la red se encuentra en un estado de

funcionamiento normal, ya que los parámetros de funcionamiento tienen unos niveles apropiados

para un conjunto de condiciones (número de usuarios, franja horaria…), o si por el contrario el

comportamiento de la red es anómalo (indicativo de que se puede estar produciendo un ataque), ya

que los niveles de los parámetros de la red han variado con respecto a lo que se considera normal.

De igual forma, es posible mejorar la certidumbre sobre la existencia de una intrusión en un sistema,

mediante la variación de los indicadores que indican el funcionamiento habitual de dicho sistema,

como por ejemplo, latencia del sistema, consumo de memoria, etc.

El objetivo de los módulos de contexto presentes en la arquitectura del AIRS basado en ontologías es

capturar y analizar esta información del contexto en tiempo real, cada vez que una nueva intrusión ha

sido detectada y el AIRS ha recibido una alerta de intrusión. En base a la variación producida, los

módulos obtienen un valor de anomalía asociado. Cuanta mayor variación se produzca, mayor será el

valor del grado de anomalía existente. Cabe indicar que por cada indicador se obtendrá un grado de

anomalía independiente, para dotar de mayor precisión a la medida.

Estos valores de anomalía son utilizados por dos componentes de la arquitectura:

- Razonador. El razonador utiliza la información relativa a la anomalía con dos objetivos bien

diferenciados:

Estimar una confianza en la detección: complementar la información incluida en las

alertas de intrusión recibidas, relativa al tipo de ataque o amenaza detectada,

llegando incluso a desautorizar a las fuentes de detección en caso de una gran

disparidad de opinión. Esto es, supongamos un escenario en el que el AIRS recibe

gran cantidad de alertas procedentes de los IDSs que indican que un determinado

tipo de amenaza está comprometiendo la red; pero al solicitar la anomalía presente

en la red y en el sistema comprometido en ese instante, los módulos de contexto

establecen que en la ventana de tiempo actual los indicadores de contexto no han

variado y la anomalía es próxima a cero. En esta situación, y dependiendo del nivel

de confianza que el sistema tiene en los IDSs que originaron la amenaza, el AIRS

asigna un valor a la fiabilidad del informe de intrusión, parámetro que es tenido en

cuenta en el proceso de inferencia de la respuesta. Como utiliza el Razonador la


135

información de contexto para obtener la fiabilidad de la alerta de intrusión se detalle

en el apartado correspondiente a las métricas de seguridad del Capítulo 6 de la

presente memoria (Ver 6.4.1.3).

Inferir las respuestas recomendadas. Mediante la variación de ciertos indicadores del

contexto de la red y los sistemas, se puede asegurar no sólo la existencia de

comportamiento anómalo en la red, sino también el tipo de amenaza específica que

está comprometiendo algún activo. Esta información, unida al tipo de amenaza

indicada en la alerta de intrusión, se utiliza para inferir las respuestas recomendadas

frente a la intrusión detectada.

- Evaluador del éxito de Acciones de Respuesta: como se indica en la metodología de

evaluación propuesta en el Capítulo 7 de la presente memoria, la información de la anomalía

en los parámetros de red y de sistemas, se utiliza para obtener el éxito o eficacia de una

acción de respuesta. Para ello, se compara el valor de dicha anomalía antes y después de la

ejecución de la respuesta.

El objetivo de este apartado es especificar de forma breve los aspectos más relevantes del diseño de

cada uno de los módulos de contexto presentes en la arquitectura.

4.4.2.1 Contexto de Sistemas

El contexto de sistemas proporciona información sobre parámetros internos de los sistemas que

ayudan a distinguir la gravedad de los ataques desde un punto de vista de detección de anomalías.

Algunos parámetros típicos de estos sistemas son la evaluación de la carga de la CPU o el espacio

en el disco duro. Para la obtención de esta serie de parámetros será necesario el uso de un sistema

de monitorización, que nos permita obtenerlos de forma remota.

Antes de pasar a definir los detalles más relevantes del diseño del módulo de contexto, es necesario

enumerar los parámetros o indicadores seleccionados, objeto de monitorización.

Elección de parámetros de contexto de sistemas

Una de las fases más importantes del diseño y desarrollo del módulo de contexto es definir el

conjunto de parámetros de los sistemas que se utilizarán para monitorizar su estado y determinar así

comportamientos anómalos. Teniendo en cuenta las limitaciones en la obtención de ciertos

parámetros por los sistemas de monitorización, los parámetros seleccionados son:

- Estado del sistema. Muestra si el equipo está activo, no responde o inactivo. Es el parámetro

más básico y elemental, para el cual en determinadas situaciones no haría falta la utilización

de un sistema de monitorización estrictamente, pero es una información muy importante a

tener en cuenta por el AIRS basado en ontologías. Este parámetro puede indicar que el

sistema atacado ha caído como consecuencia del ataque y será necesario reanudarlo o

replicar sus funciones en otro dispositivo similar.

- Latencia del sistema. Representa el tiempo que tarda en responder el equipo al sistema de

monitorización. Un aumento inusual en este valor cuando el AIRS ha recibido una alerta de

intrusión procedente de cualquiera de las fuentes de alerta presentes en la arquitectura de la

red, puede significar que el sistema está bajo una carga de trabajo superior a lo normal,

probablemente a consecuencia del ataque detectado. Hay que destacar que un ataque

común como el escaneo de puertos eleva significativamente este valor en el momento de la

intrusión, por lo que sería un parámetro relevante ante este tipo de ataques.

- Uso de la CPU. Una anomalía en este parámetro es debida a una sobrecarga del sistema,

que unida a la detección de la intrusión puede representar una gravedad del ataque elevada,

debido a que significa que la intrusión está teniendo un alto impacto al utilizar muchos

recursos. Ante una situación como esta, habría que elevar la prioridad y contundencia de la


136

respuesta, para lo que habría que analizar además otros parámetros para ver qué tipo de

respuesta sería la más adecuada.

- Espacio en disco. Muchas intrusiones y virus se caracterizan por modificar los contenidos de

los discos duros. En este punto hay que destacar que su varianza es muy distinta

dependiendo del tipo de dispositivo, por ejemplo, existen servidores Web que no modifican

prácticamente nunca su contenido. Por tanto, si en el momento de detección de una alerta se

observa que disminuye el espacio libre en disco es posible que se haya insertado algún tipo

de software malicioso en el servidor, por lo que las respuestas deberían ir dirigidas en este

sentido. Por otra parte, si el espacio libre en disco aumenta es muy probable que se hayan

borrado archivos de importancia, por lo que se debería considerar realizar una copia de

seguridad con la mayor brevedad posible y reprogramar el servidor. Por lo tanto, éste es un

parámetro de gran utilidad a la hora de seleccionar las respuestas pero su efectividad variará

según el tipo de sistema que se esté monitorizando, ya que contra más estable sea el espacio

libre del disco duro las posibilidades de detectar este tipo de ataques aumentarán muy

significativamente.

- Número de procesos activos. La gran mayoría de intrusiones llevan consigo la realización de

una serie de procesos que no existían hasta ese momento, por lo que el análisis y

comparación del número de procesos activos es importante para la determinación de

anomalías. Si durante un ataque se dispara el número de procesos en un sistema, es un

indicador más de que una intrusión ha comprometido dicho sistema.

- Número de usuarios. Existe un gran número de ataques que consiste en conseguir penetrar

en el sistema utilizando un usuario sin privilegios, y a través de varias técnicas realizar un

escalado de privilegios y conseguir acceso al sistema como usuario root o administrador.

Ante esta problemática, si en el momento en el que el AIRS recibe una alerta de intrusión, el

módulo de contexto de sistemas detecta un alto grado de anomalía en el número de usuarios

en el dispositivo, las respuestas a desplegar por el AIRS deberían ir orientadas a un control

más exhaustivo de las cuentas de usuario utilizadas en dicho sistema.

- Número de procesos zombies. Los dispositivos, especialmente los servidores, pueden sufrir

una cierta degradación en su comportamiento a lo largo del tiempo, que entre otras cosas se

puede traducir en un incremento del número de procesos zombies. Este número de procesos

se incrementa mucho más rápidamente al existir intrusiones, por lo que será un parámetro a

tener en cuenta en el proceso de inferencia de la respuesta óptima, No obstante, este

parámetro no tendrá tanta relevancia como el resto de parámetros especificados

anteriormente.

- Número de intentos fallidos mediante SSH. Cada vez que un usuario intenta acceder a un

sistema mediante SSH y falla, se registra un log debido a ese fallo en la autenticación del

usuario. De esta forma, este parámetro es un buen indicador de los ataques de contraseñas

que puedan producirse contra el sistema de autenticación de un sistema.

Diseño e implementación del módulo de contexto de sistemas

Una vez especificados los 8 parámetros que el módulo de contexto de sistemas monitoriza y analiza

con el objetivo de calcular la anomalía en cada uno de ellos en tiempo de intrusión, en este apartado

se aborda el diseño de dicho módulo. El módulo de contexto de sistemas presenta dos fases de

funcionamiento:

- Fase de aprendizaje: durante esta fase el módulo de contexto de sistemas recopila

información acerca de los nueve parámetros especificados en todos los sistemas presentes

en la arquitectura de red, de forma periódica y en un entorno controlado, donde no se

producen ningún tipo de ataque. De esta forma el sistema es capaz de determinar el

comportamiento normal de cada uno de los sistemas en ausencia de intrusión. En esta fase,

el módulo de contexto genera y almacena una serie de perfiles con los que se podrá correlar


137

la información obtenida durante la fase de detección de anomalías. Hay que destacar que la

duración de esta etapa es variable, y depende de la precisión que se requiera en el AIRS

basado en ontologías, aumentando la precisión del mismo cuanto más datos o información se

recoja para la generación de los perfiles.

- Fase de detección de anomalías: fase en la que el módulo de contexto de sistemas captura

los valores de cada uno de los ocho parámetros del sistema comprometido en el momento en

el que el AIRS basado en ontologías recibe una alerta de intrusión procedente de un IDS de

la arquitectura de red, y correla dichos valores con los perfiles generados en la fase de

aprendizaje. En función del resultado de la correlación, el módulo de contexto devuelve el

grado de anomalía existente para cada uno de los parámetros analizados, que serán

utilizados por el Razonador del AIRS basado en ontologías en el proceso de inferencia de la

respuesta óptima.

En la fase de detección de anomalías, el esquema general de funcionamiento del módulo de contexto

de sistemas es el siguiente:

Detección

IDS

Sistema de RespuestaContexto de sistemas

Sistema de

monitorización

1

2

3

Figura 4.2 Contexto de Sistemas. Diagrama funcional.

Como se observa en la figura, la secuencia de ejecución comienza con los IDSs, que tras detectar

una intrusión, generan una alerta que envían al AIRS basado en ontologías que será el encargado de

invocar al módulo de contexto de sistemas. El módulo de contexto de sistemas, a través del uso del

sistema de monitorización elegido, obtiene la información relativa al estado de funcionamiento del

sistema(s) comprometido(s) por la intrusión detectada en ese instante concreto, para a continuación

procesar la información obtenida y devolver como resultado al Razonador una serie de parámetros

que representan el grado de anomalía encontrado en los sistema(s) monitorizado(s).

El módulo de contexto de sistemas (al igual que el contexto de red) durante su fase de detección de

anomalías, se utiliza en el instante en el que el IDS detecta una intrusión y envía la alerta

correspondiente al AIRS basado en ontologías, por lo que su respuesta debe ser lo más rápida

posible para no ralentizar la toma de decisiones del razonador del sistema de respuesta. Al mismo

tiempo, se pretende no sobrecargar la red, por lo que la obtención de la información de los

parámetros de los sistemas en esta fase se realiza únicamente en los instantes en los que cualquiera

de los IDSs detecta una intrusión. Por este motivo, durante la fase de detección de anomalías se ha

optado por un proceso basado en eventos para su funcionamiento. Por el contrario, la obtención de

información del comportamiento normal de los sistemas de la red se realiza en un entorno controlado

mediante monitorización continua.

En ambas fases, tanto en la fase de aprendizaje como en la de detección de anomalías, el módulo de

contexto de sistemas consta de dos compontes principales, como se observa en la arquitectura del

sistema en la Figura 4.3: (1) un sistema de monitorización que proporciona el valor de los indicadores


138

previamente configurados y cuyo funcionamiento es el mismo en ambas fases (Monitoring Server y

Monitoring Agent), y (2) un módulo encargado de procesar la información obtenida, cuyo

funcionamiento difiere para cada una de las fases (Information Processing Module).

Figura 4.3 Arquitectura del módulo de contexto de sistemas.

A continuación se definen de forma breve cada uno de estos componentes.

Sistemas de monitorización

El sistema de monitorización, compuesto por los módulos Monitoring Server y Monitoring Agent, es un

componente de la arquitectura utilizado en ambas fases de funcionamiento del sistema, cuyo objetivo

es capturar los valores de los parámetros especificados de los sistemas a monitorizar. Una de las

principales dificultades en la fase de diseño del contexto de sistemas ha sido la necesidad de acceder

a parámetros internos de los sistemas, ya que no son accesibles de forma remota sin ningún tipo de

software adicional. Ante esta problemática se ha optado por la utilización de un sistema de

monitorización. Los sistemas de monitorización permiten comprobar el estado de funcionamiento de

los sistemas de red como pueden ser los servidores, cortafuegos, routers, o proxies. Estos sistemas

funcionan mediante una arquitectura de cliente – servidor, por lo que por un lado se tiene un sistema

que actúa como servidor de monitorización, que en el caso concreto del módulo de contexto de

sistemas está situado en el mismo host que el módulo de procesado de la información, y por otro lado

existen un número de clientes o agentes que residen en cada uno de los sistemas que se desea

monitorizar.

Actualmente, hay varios software de sistemas de monitorización disponibles, por lo que no ha sido

necesario diseñar e implementar un sistema de monitorización específico para el módulo de contexto

de sistemas. Para la elección del sistema de monitorización a utilizar, se ha realizado un análisis de

los distintos sistemas de monitorización existentes según las prestaciones que se adecuaban mejor al

perfil de la funcionalidad de este módulo. Las principales características a tener en cuenta en el

análisis son:

- Funciones: el sistema debe cumplir todos los requisitos impuestos al módulo de contexto de

sistemas, prestando especial atención a la posibilidad de recolección de la información por

medio de una aplicación externa y su capacidad para obtener parámetros de relevancia para

esta parte del módulo de contexto.

- Ligereza: se pretende que el sistema de monitorización consuma el menor número de

recursos posible, pero especialmente en los clientes, ya que deberá instalarse en todos los

sistemas de la red que se deseen controlar.

- Precio: el hecho de que el sistema sea open source o propietario también se debe tener en

cuenta.


139

- Facilidad de uso: dado que el sistema de monitorización hay que instalarlo en todos los

sistemas que se deseen monitorizar, la velocidad y facilidad de instalación son aspectos a

tener en cuenta.

- Soporte: es conveniente tener en cuenta el grado de estabilidad y soporte del sistema de

monitorización bajo análisis.

En función de estas características, el sistema de monitorización elegido para su uso en la

arquitectura del módulo de contexto de sistemas es Nagios. Detalles de la integración de Nagios y del

agente de monitorización asociado se proporcionan en el Capítulo 8, en la sección correspondiente a

la implementación del prototipo del AIRS basado en ontologías (Ver 8.3).

Mediante el servidor de monitorización, el módulo de contexto de sistemas es capaz de solicitar y

obtener el valor de cada uno de los 8 parámetros de interés de cada uno de los sistemas

monitorizados, en ambas fases de funcionamiento. En el caso de la fase de aprendizaje, el sistema

de monitorización será invocado de forma periódica cada cierto tiempo indicado por el administrador

del sistema; por el contrario, en la fase de detección de anomalías, el sistema de monitorización será

invocado cada vez que un IDS detecte una intrusión y envíe el informe correspondiente al AIRS.

Módulo de procesado de la información

Este módulo ha sido diseñado e implementado por completo para su uso en el sistema de contexto

de sistemas de la arquitectura del AIRS basado en ontologías propuesto. Como se ha indicado

anteriormente, este módulo ejecuta una serie de pasos u otros en función de la fase de

funcionamiento en la que se ejecute: fase de entrenamiento o fase de detección de anomalías.

Como se observa en la arquitectura del módulo de contexto de sistemas, el módulo de procesado de

la información está formado por 3 componentes:

- SystemsContextModeSelector: componente encargado de extraer el modo de funcionamiento

del módulo de contexto de sistemas y comprobar que los parámetros proporcionados en la

invocación, por el razonador o por el administrador del sistema, son los requeridos por dicha

fase. En caso de que los parámetros de entrada sean correctos, este componente invoca al

módulo correspondiente: SystemsContextLearning, en caso de que se desee ejecutar la fase

de aprendizaje, y SystemsContextAnomalyDetector, si se ha recibido una alerta de intrusión y

la fase invocada es la de detección de anomalías.

- SystemsContextLearning: componente principal de la fase de aprendizaje cuyo objetivo es

capturar la información recibida por el sistema de monitorización relativa a los ocho

parámetros de cada sistema de la red, y almacenar dicha información en la base de datos

correspondiente, denominada en la arquitectura como SystemsProfiles. Es el encargado de

generar los perfiles con los que se comparará la información obtenida en la fase de detección

de anomalías para el cálculo del grado de anomalía existente.

- SystemsContextAnomalyDetector: componente principal de la fase de detección de

anomalías cuyo objetivo es invocar al sistema de monitorización en el momento de detección

de una intrusión, y comparar la información recibida de dicho sistema con la almacenada en

la base de datos SystemsProfiles, para lo que utiliza funciones y métodos estadísticos. Como

resultado de esta correlación, se obtienen ocho parámetros que representan, con un número

del 0 al 10, la anomalía existente en cada uno de los ocho indicadores monitorizados en el

sistema comprometido. Por último, este componente envía estos ocho valores al módulo

Context Receiver, presente en la arquitectura del AIRS que se encargará de mapear la

información del contexto de sistemas a la ontología de respuesta a intrusiones, para su

posterior utilización por parte del Razonador en el proceso de inferencia de la respuesta

óptima.


140

SystemsProfiles

Base de datos del módulo de contexto de sistemas donde se almacenan los perfiles de

comportamiento normal de los sistemas de la red monitorizados durante la fase de aprendizaje. Estos

perfiles son utilizados durante la fase de detección de anomalías para correlar la información

almacenada con la obtenida en momento de intrusión, con el fin de calcular el nivel de anomalía

existente, objetivo principal del módulo de contexto de sistemas.

4.4.2.2 Contexto de Red

El contexto de red es un módulo de la arquitectura del AIRS basado en ontologías cuyo objetivo es

definir un grado de anomalía en el estado de la red, basado en parámetros como el número de

conexiones abiertas y la carga de la red, en el momento en el que el IDS detecta un posible ataque,

para determinar la gravedad del mismo e influir con dicha información en el tipo e intensidad de la

respuesta que elegirá nuestro sistema de respuesta automática. Se basa en un capturador de tráfico

para la obtención de su información útil.

Elección de parámetros de contexto de red

El módulo de contexto de red captura y analiza el tráfico existente en una red o subred de la

arquitectura de una institución, siendo esta información capturada el nivel de actividad habitual de

dicha red. En el caso del módulo de contexto de red propuesto esta información está compuesta por

los siguientes parámetros:

- IP origen: parámetro que indica la dirección IP origen incluida en cada paquete o datagrama

enviado por la red bajo monitorización.

- IP destino: parámetro que indica la dirección IP al que va dirigido cada paquete o datagrama

que atraviesa la red bajo monitorización.

- Puerto origen: parámetro que representa el puerto origen de cada paquete que atraviesa la

red o subred bajo monitorización.

- Puerto destino: parámetro que representa el puerto destino al que va dirigido cada paquete o

datagrama que atraviesa la red bajo monitorización.

- Tamaño o longitud del paquete: parámetro que indica el tamaño de cada paquete que

atraviesa la red o subred bajo monitorización, en número de octetos.

- Franja horaria: parámetro que representa la franja horaria en el que se ha enviado o recibido

cada paquete que atraviesa la red bajo monitorización. Este parámetro es relevante puesto

que en función de la franja horaria, el nivel de actividad de la red de una organización es uno

u otro, ya que el tráfico es completamente diferente a las 9:00 que a las 23:30.

Esta información relativa al tráfico que atraviesa una red o subred permite generar un perfil de tráfico

asociado. En caso de intrusión, este perfil de tráfico es comparado con el nivel de actividad de la red

en el momento de intrusión, tras lo que el módulo de contexto de red proporciona un único parámetro

que representa el nivel de anomalía existente en el tráfico de la red con respecto a su estado de

funcionamiento habitual. A pesar de que el módulo de contexto de red tan sólo calcula y proporciona

un parámetro de anomalía, para el cálculo de dicha anomalía correla la información relativa a los 6

parámetros especificados anteriormente.

Diseño e implementación del módulo de contexto de red

De igual forma que en el caso del contexto de sistemas, este módulo presenta dos fases de

funcionamiento, que a continuación se detallan [Fan04]:

- Fase de aprendizaje: durante esta fase se utiliza una herramienta de captura de tráfico

(SANCP como se verá más adelante, en el capítulo correspondiente a validación) para la

captura de información de la red. El módulo va recolectando información en forma de logs. Al


141

igual que en el caso de los sistemas, esta fase se lleva a cabo en un entorno controlado, lo

que implica que hay que asegurar que no se produzcan ataques de red. Los logs obtenidos

se vuelcan a una base de datos mediante un algoritmo diseñado para ello, de forma que se

generen los perfiles de tráfico de red de la forma más eficiente posible.

- Fase de detección de anomalías: durante esta fase el módulo se encarga de correlar los

perfiles obtenidos en la fase de aprendizaje con los logs que se obtienen en el momento de la

detección de la intrusión, relacionados al tráfico de la red.

El proceso seguido es muy similar al explicado en el contexto de sistemas pero su implementación

difiere en gran medida. Este módulo se basa principalmente en el uso de un capturador de tráfico,

cuya función es la recolección de información del tráfico de la red. Esto permite comparar el estado

de la red en el momento de la intrusión con el perfil de tráfico habitual generado, resultando en un

grado de anomalía que será el valor proporcionado al Razonador. El esquema de funcionamiento se

observa en la siguiente figura:

Detección

IDS

Sistema de RespuestaContexto de red

Tráfico capturado

1

2

3

Figura 4.4 Contexto de Red. Diagrama funcional

Se observa que el esquema de funcionamiento es prácticamente igual que al especificado para el

contexto de sistemas, pero en este caso la información procesada es de distinta índole, ya que se

basa en el análisis del tráfico de la red, en vez de en los parámetros internos de los sistemas. La

ejecución de los dos módulos de contexto para la generación de los grados de anomalía será

prácticamente simultánea, ya que al detectarse una intrusión, el AIRS basado en ontologías debe

invocar al módulo de contexto de red y al de sistemas para obtener tanto los datos relativos a la

anomalía del contexto de red existente como los relativos al contexto de sistemas. Ambos sistemas

de contexto operan en paralelo.

Siguiendo el mismo razonamiento que el indicado para el contexto de sistemas, durante la fase de

detección de anomalías se ha optado por un proceso basado en eventos para su funcionamiento. Por

el contrario, la obtención de información del nivel de actividad habitual de la red se realiza en un

entorno controlado mediante monitorización continua.

En la Figura 4.5 se observa, que para el funcionamiento de este módulo en cualquiera de sus dos

fases, se distinguen dos componentes principales: un capturador de tráfico (Network Traffic Profiler) y

un módulo de procesado de la información (Information Processing Module).


142

Figura 4.5 Arquitectura del módulo de contexto de red.

A continuación se definen de forma breve cada uno de estos componentes.

Capturador de tráfico

El capturador de tráfico (Network Traffic Profiler) es el componente de la arquitectura utilizado en

ambas fases de funcionamiento del sistema, cuyo objetivo es capturar el tráfico que atraviesa la red o

subred a monitorizar.

Actualmente, hay varios sistemas que permiten capturar tráfico, por lo que no ha sido necesario

diseñar e implementar un sistema específico para el módulo de contexto de red. Tras una revisión y

análisis de los distintos sistemas de captura de tráfico existentes, el sistema elegido para su uso en la

arquitectura del módulo de contexto de red es SANCP, cuya descripción y funcionamiento se detallan

en el Capítulo 8, en la sección correspondiente a la implementación del prototipo del AIRS basado en

ontologías (Ver 8.3).

Este componente tiene la capacidad de obtener el tráfico de la red monitorizada, en ambas fases de

funcionamiento. En el caso de la fase de aprendizaje, será invocado de forma periódica cada cierto

tiempo indicado por el administrador del sistema; por el contrario, en la fase de detección de

anomalías, este componente será invocado cada vez que un IDS detecte una intrusión y envíe el

informe correspondiente al AIRS.


Este módulo ha sido diseñado e implementado por completo para su uso en el sistema de contexto

de red de la arquitectura del AIRS basado en ontologías propuesto. A diferencia del capturador de

tráfico, este módulo ejecuta una serie de pasos u otros en función de la fase de funcionamiento en la

que se ejecute: fase de entrenamiento o fase de detección de anomalías.

Como se observa en la arquitectura, el módulo de procesado de la información está formado por 3

componentes:

- NetworkContextModeSelector: componente encargado de extraer el modo de funcionamiento

del módulo de contexto de red y comprobar que los parámetros proporcionados en la

invocación, por el razonador o por el administrador del sistema, son los requeridos por dicha

fase. En caso de que los parámetros de entrada sean correctos, este componente invoca al

módulo correspondiente: NetworkContextLearning, en caso de que se desee ejecutar la fase

de aprendizaje, y NetworkContextAnomalyDetector, si se ha recibido una alerta de intrusión y

la fase invocada es la de detección de anomalías.

- NetworkContextLearning: componente principal de la fase de aprendizaje cuyo objetivo es

recibir la información capturada por el capturador de tráfico relativa al nivel de actividad de la

red, distinguiendo entre los seis parámetros especificados previamente (IP origen, IP destino,


143

puerto origen, puerto destino, longitud del paquete y franja horaria) y almacenar dicha

información en la base de datos correspondiente, denominada en la arquitectura como

NetworkProfiles. Es el encargado de generar el perfil de tráfico con el que se comparará la

información obtenida en la fase de detección de anomalías para el cálculo del grado de

anomalía existente.

- NetworkContextAnomalyDetector: componente principal de la fase de detección de anomalías

cuyo objetivo es invocar al capturador de tráfico en el momento de detección de una intrusión

y procesar la información del tráfico de red obtenida en tiempo de intrusión, comparándola

con la información almacenada en la base de datos que contiene los perfiles de tráfico normal

de la red. Como resultado de esta correlación, se obtiene un parámetro que representa, con

un número del 0 al 10, la anomalía existente en el nivel de actividad de la red. Por último, este

componente envía esta anomalía al módulo Context Receiver, presente en la arquitectura del

AIRS que se encargará de mapear la información del contexto de red a la ontología de

respuesta a intrusiones, para su posterior utilización por parte del Razonador en el proceso

de inferencia de la respuesta óptima.

NetworkProfiles

Base de datos del módulo de contexto de red donde se almacenan el perfil de tráfico habitual de la

red monitorizada durante la fase de aprendizaje. Este perfil es utilizado durante la fase de detección

de anomalías para correlar la información almacenada con la obtenida en momento de intrusión, con

el fin de calcular el nivel de anomalía existente, objetivo principal del módulo de contexto de red.

Detalles del proceso de correlación utilizado para el cálculo de la anomalía del nivel de actividad de la

red se proporcionan en el capítulo de validación (Ver 8.3).

4.4.3 “Policies”: Especificación del comportamiento mediante

ontologías y lenguajes de reglas


gobernar el proceso de inferencia de la respuesta óptima llevado a cabo por el Razonador. Las

políticas se expresan mediante reglas SWRL, ya que este ha sido elegido como lenguaje de

representación de comportamiento más adecuado a los requisitos del sistema propuesto.

A partir de dichas reglas y el conocimiento incluido en la ontología, el razonador infiere la respuesta

más adecuada frente a una intrusión. En la Figura 4.6 se observa el proceso de inferencia de la

respuesta óptima ejecutado por el Razonador, que está completamente gobernado por el conjunto de

reglas o políticas presentes en la arquitectura del AIRS basado en ontologías. Este proceso consta de

4 fases:

- Generación de un ejemplar de la clase correspondiente de la ontología, de forma que la alerta

de intrusión recibida por el AIRS basado en ontologías procedente de uno de los IDSs del

sistema, quede modelada por su concepto equivalente en la ontología de respuesta a

intrusiones. Cada vez que el Receptor de Alertas recibe una nueva alerta procedente de

algún IDS, esta alerta se modela como un ejemplar de la ontología. Este componente, como

ya se ha especificado, es el encargado de convertir el formato específico de la alerta (syslog

o formato de alerta propio de cada IDS) al lenguaje OWL, por medio de la API de Jena.

- Obtención de información del contexto de la red y los sistemas en el momento de intrusión, y

representación de dicha información en la ontología. Cuando se detecta una nueva intrusión,

el Razonador invoca a los módulos de contexto que proporcionan el grado de anomalía de los

siguientes nueve parámetros: número de procesos activos, uso de CPU, espacio libre en

disco, latencia del sistema, estado del sistema, número de usuarios, número de procesos

zombies, tráfico de red, y número de conexiones SSH fallidas. Esta información es


144

representada en la ontología en forma de ejemplares o instancias de la clase correspondiente

(Ver 5.4).

- Inferencia de respuestas recomendadas en función de las reglas adecuadas e información

relacionada con la intrusión detectada y con el contexto, principalmente.

Previo a la inferencia de las respuestas recomendadas, el sistema comprueba si se ha

recibido alguna alerta de intrusión antes, o si esta es la primera vez que el AIRS ejecuta el

proceso de inferencia (Este paso es necesario debido a la sintaxis de OWL y SWRL). Si esta

es la primera alerta de intrusión recibida, no hay resultados anteriores almacenados por lo

que el sistema infiere el conjunto de respuestas recomendadas mediante la aplicación de las

reglas SWRL que posteriormente se detallan. De lo contrario, el sistema comprueba si hay

resultados para la misma intrusión o una similar. En caso de que haya un resultado anterior

para una intrusión similar y la respuesta fue ejecutada con éxito, el sistema seleccionará la

misma reacción. De lo contrario, se debe inferir el conjunto de respuestas recomendadas.

- Elección de la respuesta óptima del conjunto de las recomendadas. Para ello, se utilizan el

conjunto de reglas apropiado, e información relacionada principalmente con la intrusión

detectada (impacto), las acciones de respuesta (coste, impacto y eficiencia) y el activo

comprometido.

Figura 4.6 Diagrama de proceso de la inferencia de la respuesta óptima del AIRS basado en ontologías. [Mateos12]

En la arquitectura del sistema se proponen 4 conjuntos de reglas:

- Reglas que determinan la amenaza indicada por la información de contexto: reglas cuyo

objetivo es determinar la amenaza indicada por la variación de la anomalía producida en los

parámetros del contexto. El resultado de estas reglas, será utilizado por el siguiente conjunto

para obtener la fiabilidad del informe de intrusión y las respuestas recomendadas.


145

- Reglas que determinan la fiabilidad del informe de intrusión: conjunto de reglas cuyo objetivo

es dar valor a la propiedad intrusionAlertReliability de la clase FormattedIntrusion. Para ello,

comparan la amenaza indicada por la información de contexto y el tipo de ataque indicado en

la alerta de intrusión. Este conjunto de reglas tiene la función de especificar la métrica de

fiabilidad del informe de intrusión especificada en el Capítulo 6, cuya tabla de decisión se

observa en Tabla 6.3. Un ejemplo de la especificación de esta métrica mediante SWRL puede

verse en 6.4.3.1.

- Reglas que permiten inferir las respuestas recomendadas, para lo que utilizan información

relativa al contexto, a la amenaza y la propiedad protects de la clase Response.

- Reglas que permiten inferir la respuesta óptima. Conjunto de reglas cuyo objetivo es inferir la

respuesta óptima frente a una intrusión. Parten de los resultados obtenidos en la aplicación

del conjunto de reglas anterior. Este conjunto de reglas tiene la función de especificar la

métrica de inferencia de la respuesta óptima especificada en el Capítulo 6. La especificación

de esta métrica mediante SWRL puede verse en 6.4.3.2.

En el Apéndice II se incluyen todas las reglas SWRL utilizadas en la arquitectura del AIRS basado en

ontologías.

4.4.4 Response Toolkit o Catálogo de Acciones de respuesta

Es el conjunto o listado de acciones de respuesta específicas disponibles para ejecutar por el AIRS

basado en ontologías para reaccionar frente a una intrusión con el fin de mitigarla o reducir el daño

causado. Estas respuestas se ejecutan a través de diferentes componentes de seguridad (routers,

cortafuegos, IDSs, etc.) o a través de aplicaciones del sistema operativo subyacente (tcpwrapper,

cortafuegos local, comandos locales, etc.).

La tarea de definir un listado de acciones de respuesta completo es una tarea muy compleja, puesto

que para ello hay que tener en cuenta la arquitectura de la organización en la que van a ser

desplegadas, entre otras cosas.

Una buena práctica para elaborar la lista de reacciones incluidas en el Response Toolkit es realizar

un análisis de riesgos, que proporcionaría una buena aproximación de los recursos que se deben

proteger y por tanto, qué acciones de respuestas concretas se deben implementar como

contramedida.

Por otra parte, hay varias propuestas de listados de acciones de respuesta que no dependen de la

topología o arquitectura de red de una organización concreta o específica. El más significativo es el

listado propuesto por Stakhanova et al. [Stakhanova07], que incluye las acciones de respuestas más

comunes que son implementadas por los AIRSs. Así mismo, Rash et al. [Rash05] propone un listado

de acciones de respuesta clasificándolas en dos tipos: respuestas basadas en red, que son aquellas

que tienen la capacidad de interactuar de forma directa con el tráfico de red, y respuestas basadas en

hosts, que tienen la capacidad de interactuar sobre los procesos, servicios, conexiones y usuarios

que se ejecutan sobre el mismo host.

No obstante, toda acción de respuesta a incluir en el Catálogo de Acciones de Respuesta, se clasifica

en base a tres dimensiones:

- Tipo de acción de respuesta: las respuestas se pueden clasificar en dos grandes bloques,

respuestas reactivas (aquellas destinadas a mitigar la intrusión o reducir su impacto una vez

que la intrusión ha sido detectada) y respuestas proactivas (aquellas destinadas a intentar

evitar que el ataque ocurra).

- Tipo de intrusión: en función del tipo de intrusión específica hay un conjunto de respuestas

asociadas, ya que no todas las acciones son válidas ni eficaces para todos los tipos de

ataques.


146

- Tipo de dispositivo de seguridad: no todos los dispositivos de seguridad pueden desplegar ni

hacer efectivas todas las acciones de respuesta. Una clasificación de respuestas en función

del tipo de componente encargado de ejecutarla es especialmente relevante y de utilidad para

el módulo de ejecución de acciones de respuesta (Ver 4.4.5), en especial para los

componentes Agente de Ejecución y Gestor de Plugins. Como se verá más adelante, cada

acción de respuesta incluida en el Response Toolkit se implementa mediante plugins. Cuando

se registra un plugin es necesario indicar parámetros relativos a la configuración del

dispositivo o dispositivos de seguridad que pueden ejecutar dicha acción de respuesta.

A continuación, en este apartado se describe brevemente la clasificación realizada de las acciones de

respuesta en cada una de las tres dimensiones. Cabe recalcar que cada vez que una acción de

respuesta se añade al catálogo de acciones del AIRS basado en ontologías, es necesario indicar su

tipo en cada una de las dimensiones.

4.4.4.1 Respuestas en función del tipo de acción

Las acciones de respuesta se pueden clasificar en respuestas Reactivas y Proactivas. A su vez,

dentro de las respuestas Reactivas, existen dos tipos de posibles respuestas: Pasivas, y Activas. A

continuación se definen brevemente los tres tipos de respuestas y se listan ejemplos de acciones

pertenecientes a cada uno de ellos.

Dichas respuestas se clasifican en respuestas pasivas, respuestas activas o respuestas proactivas:

- Respuestas pasivas: respuesta de notificación o registro. Su objetivo es que una vez

detectado el ataque, avisan o informan de la ocurrencia de intrusión. Este tipo de respuestas

son ejecutadas por los IDSs. Acciones pertenecientes a este conjunto son por ejemplo:

registros normales / registros seguros (canal de registro seguro), notificación a la consola

central local y/o remota sobre posibles intrusiones detectadas, notificación de la intrusión al

administrador mediante el envío de un correo electrónico o mensaje de texto, envío de una

trap SNMP hacia una consola de gestión, registro de las incidencias detectadas en una base

de datos de incidencias o en un fichero de logs como evidencia de que algo no ha ido bien en

el funcionamiento normal del sistema protegido, etc.

- Respuestas activas: aquellas que intentan mitigar el ataque o reducir su impacto. A este

grupo pertenecen acciones de bloqueo de tráfico, terminación de procesos, deshabilitación de

usuarios, etc. Las respuestas activas se agrupan a su vez en cuatro categorías [Villagrá09]:

Respuestas de protección: aquellas que intentan anular cualquier tipo de interacción

entre el atacante y la máquina víctima. Algunos ejemplos de este tipo de respuestas

son: bloquear un puerto, una sesión o una dirección IP; cortar conexión TCP

establecida por el atacante; reconfigurar cortafuegos (agregando nuevas políticas de

seguridad que bloqueen intentos de conexión), o router (agregando reglas a las ACL);

terminar el proceso sospechoso; deshabilitar al usuario dañino; terminar un servicio;

reiniciar conexiones de routers, cortafuegos, etc.

Respuestas de recuperación: aquellas cuyo objetivo es restaurar el activo atacado a

un estado anterior. Algunos ejemplos de estas respuestas son: restauración de los

ficheros de un sitio web, restauración de una BDD en caso de que se hayan realizado

cambios no autorizados, restauración de un host a un estado previo, etc. Dentro de

este grupo también se incluyen aquellas acciones que ajustan la configuración de los

equipos de detección, como por ejemplo, incrementar el nivel de sensibilidad de los

sensores, IDSs, etc.

Respuestas de engaño: aquellas cuyo objetivo es engañar al atacante y atraerlo, con

el fin de mitigar el ataque detectado por un lado, y analizar al atacante y su modo de

actuación, por otro. De esta forma es posible obtener información sobre el vector de

ataque, las técnicas empleadas por el atacante, etc., y aprender de ello para tenerlo


147

en cuenta en posteriores detecciones del mismo tipo de ataque. Ejemplos de este

tipo de respuesta son: uso de honeypot [Peter11] y honeynets [Spitzner05],

aislamiento del intruso o “fishbowl”, sacrificio de un activo de backup como honeypot,

etc.

Respuestas de reacción: aquellas cuyo objetivo es llevar a cabo un contraataque. No

obstante, existen condiciones legales a tener en cuenta antes de aplicar este tipo de

respuestas, más aun cuando un ataque puede ser efectuado desde una jurisdicción

diferente al del host atacado [Hoskins05]. Además de lanzar un contraataque, las

respuestas análogas al sistema nervioso autónomo son ejemplo de respuestas de

reacción.

- Respuestas proactivas: aquellas que intentan evitar que ocurra el ataque, es decir, implantan

medidas de seguridad antes de que el ataque cumpla su objetivo, de forma que previenen

que se produzca. Un ejemplo de ello sería, interrogar activamente a todos los procesos de

usuario existentes utilizando identidades falsas y terminar aquellos procesos que no se

originaron de usuarios genuinos con los permisos adecuados. Las respuestas proactivas

suelen ser acciones de bloqueo y ajustes de configuración de sistemas de seguridad.

La siguiente tabla muestra un listado de acciones de respuesta clasificadas en función de los tipos de

acciones de respuesta especificados en este punto. La lista incluye:

- Acciones de respuesta incluidas en los listados propuestos por los trabajos mencionados

anteriormente (el listado propuesto por Stakhanova et al. [Stakhanova07] y la clasificación

propuesta por Rash et al. [Rash05]).

- Los ejemplos de respuestas proporcionados en la definición de cada tipo de acción, que no

estén incluidos en ambos listados.

- Acciones de respuesta específicos para cada tipo de intrusión obtenidos tras un estudio y

análisis de las acciones de respuesta en función del tipo de ataque. Esta dimensión de

clasificación se aborda en el siguiente punto del capítulo, pero se ha creído conveniente

incluir las acciones de respuesta resultantes en el listado.

Tabla 4.4 Listado de acciones de respuesta clasificadas según el tipo de acción.

Acción de Respuesta ID

Act.

Pro

tecció

n

Act.

Recupera

ció

n

Act. E

nga

ño

Act. R

eacció

n

/Contr

aata

que

Pasiv

a

Pro

activa

GENERALES

Notificar al administrador (SMS, Mail,etc) R1 X

Registro (normal o seguro) en bases de datos de

incidencias o fichero de logs R2 X

Notificar a la consola central local y/o remota R3 X

Enviar una trap SNMP hacia una consola de gestión R4 X

Generar informes o logs R5 X

Habilitar herramientas de análisis adicionales R6 X X X

Rastrear la conexión del atacante para recopilar

información R7 X

Aislamiento del atacante o fishbowl R8 X

BASADAS EN HOST

Hacer Backups de archivos R9 X


148

Denegar el acceso de forma selectiva o completa a un

archivo R10 X X

Eliminar un archivo creado por un usuario no legítimo R11 X

Permitir la manipulación de un archivo falso R12 X X

Restaurar un archivo manipulado con un archivo de

backup R13 X

Restringir la actividad de un usuario R14 X X

Deshabilitar una cuenta de usuario R15 X X

Apagar el host comprometido R16 X

Reiniciar el host comprometido R17 X X

Formatear o restaurar el host comprometido R18 X

Terminar el servicio comprometido R19 X

Reiniciar el servicio comprometido R20 X X

Desinstalar servicios innecesarios R21 X

Terminar el proceso sospechoso R22 X

Reiniciar el proceso sospechoso R23 X X

Bloquear peticiones al sistema sospechosas R24 X X

Retardar peticiones al sistema sospechosas R25 X X

Agregar o borrar reglas de filtrado sobre un

cortafuegos personal R26 X X

Agregar o borrar reglas de filtrado sobre un WAF (Web

Application Firewall) a nivel de host R27 X X

BASADAS EN RED

Agregar o borrar reglas de filtrado sobre un

cortafuegos R28 X X

Agregar o borrar reglas de filtrado sobre un WAF (Web

Application Firewall) R29 X X

Agregar reglas a las ACL de los routers R30 X X

Bloquear puertos o direcciones IP R31 X X

Modificar o cambiar el número de puerto R32 X X

Bloquear conexiones de red entrantes y salientes

sospechosas R33 X X

Terminar conexión TCP establecida por el atacante. R34 X

Reiniciar conexiones de routers, cortafuegos, etc. R35 X X

Desplegar un honeypot o una honeynet R36 X X

Suplantar mensajes TCP RST o ICMP Unreachable

para terminar conexiones TCP y UDP respectivamente R37 X X X

Monitorizar la red en busca de paquetes SYN a

puertos restringidos R38 X X

En puntos posteriores de la presente memoria haremos referencia a cada acción de respuesta

específica incluida en este listado, para lo que se hará uso de un identificador (ID).

Como se observa en la tabla, las respuestas activas de protección que impliquen bloqueo o ajustes

de configuración de sistemas de seguridad, y las de engaño, se clasifican como respuestas

proactivas. La gran diferencia entre ambas es el momento en que se aplican o despliegan cada una

de ellas.

4.4.4.2 Respuestas en función del tipo de intrusión

Como se indica al comienzo del apartado, las acciones de respuesta también pueden ser clasificadas

en función del tipo de intrusión para el cual son efectivas, ya que no todas las acciones son válidas ni

eficaces para todos los tipos de ataques.

Para ello, es necesario elaborar primero una clasificación de los diferentes tipos de ataque. Para

realizar esta clasificación se han analizado de forma exhaustiva las taxonomías de ataque existentes,


149

en especial su dimensión de Vector de Ataque, además de las ontologías de seguridad, las

clasificaciones de amenazas y ataques informáticos realizadas por expertos, y los informes sobre

tendencias de ataques como los elaborados por Symantec [Symantec13]. Sobre este análisis se

proporcionan más detalles en el Capítulo 5. Como resultado del mismo se ha obtenido una

clasificación de los distintos tipos de ataque o amenazas, que constituyen las subclases de la clase

Threat de la ontología de respuesta a intrusiones (Ver Figura 5.13).

Como se observa en la Figura 5.13, se distinguen 10 clases principales de ataque según su vector de

ataque, que se dividen a su vez en subclases con el fin de proporcionar un nivel de especificidad

mayor. Este apartado tiene dos objetivos:

- Describir de forma breve los 10 tipos de ataque principales y enumerar sus subclases. En el

Apéndice I se incluye una definición más extensa de cada tipo de ataque y subclases en las

que cada uno se divide, indicando además las vulnerabilidades que explota, y algunas

técnicas de detección. Además, se incluyen las posibles acciones de respuesta indicando

entre paréntesis el identificador asignado a cada una en la Tabla 4.4 así como el tipo de

respuesta.

- Clasificar cada una de las respuestas del listado obtenido en el punto anterior en función de

cada tipo de ataques. Para esta clasificación sólo se tendrá en cuenta las categorías del

primer nivel de la taxonomía de ataques.

Los tipos de ataque o amenaza son:

- Information Gathering Attack: ataque pasivo cuyo objetivo es recopilar información sensible

de un recurso, que puede ser una puerta de acceso a la red. Su mecanismo de

funcionamiento se basa en recopilar información que les indique qué puertos están

escuchando en la red para acceder posteriormente a los recursos de la misma a través de

ellos. Normalmente es preludio a un ataque posterior.

Subclases: Scanning, Sniffing, Mapping.

- Network attacks (Ataques de red): ataques cuyo objetivo es introducirse en un sistema

suplantando la identidad de un usuario o del propio administrador, mediante la manipulación

de protocolos de la torre de protocolos TCP/IP, aprovechando una sesión establecida por el

usuario víctima, o utilizando los datos obtenidos mediante ataques de escaneo (nombre de

usuario y password).

Subclases: Spoofing, Hijacking, Web Application Attacks, Wireless Attacks.

- BackDoors: una puerta trasera (backDoor) en sí es un programa que permite remotamente

acceder a un sistema con libertad de movimientos, que constituye un acceso a un sistema o

programa de forma transparente al usuario.

- Password Attacks (Ataques a contraseñas): ataques cuyo objetivo es descubrir contraseñas

de acceso de usuarios para el acceso a determinados recursos. Se utilizan básicamente dos

técnicas, por fuerza bruta o un ataque de diccionario.

Subclases: Brute Force, Dictionary Attack.

- Exploits: Ataque que consiste en utilizar un trozo de código, fragmento de datos o secuencia

de comandos y/o acciones llamado exploit, para explotar los agujeros o vulnerabilidades de

seguridad existentes en un sistema de información, con el objetivo de conseguir un acceso no

autorizado a la máquina objetivo o provocar un comportamiento no deseado de dicho sistema

o de alguno de los servicios que éste presta.

- Virus: programa que se replica a sí mismo y que se propaga a través de archivos infectados.

Una vez cargado en memoria cumple las instrucciones programadas por su creador, que

pueden ser: destruir ficheros, modificar ficheros, sobrecargar recursos, entre otros.


150

- Worms (Gusanos): programa que se replica a sí mismo y que no requiere de un fichero

infectado para propagarse, sino que se propaga a través de servicios de red o a través del

correo electrónico.

- Trojans (Troyanos): tipo de ataque que consiste en un programa oculto dentro de otro de

apariencia normal. El objetivo de esta técnica de ataque suele ser permitir una conexión

remota con la máquina víctima desde la máquina atacante para lo que establece una

Backdoor, en el sistema comprometido.

- Buffer Overflow (Desbordamiento de pila): procedimiento mediante el cual los datos que se

escriben sobre un buffer corrompen aquellos datos en direcciones adyacentes de memoria,

ganando el control de un proceso determinado.

- Denial of Service (Denegación de Servicio): ataque cuyo objetivo es saturar los recursos de la

máquina víctima de tal forma que se inhabilitan los servicios prestados por la misma durante

un periodo de tiempo indefinido, evitando que los usuarios legítimos puedan hacer uso de los

recursos. Estos recursos pueden ser: memoria, espacio en disco, uso de la CPU, ancho de

banda, etc. Se distinguen dos tipos de DoS, basado en host (consumo de recursos o bloqueo)

y basado en red (Inundación TCP, UDP o ICMP).

La siguiente tabla incluye una clasificación de las acciones de respuesta en función del tipo de

ataque, es decir, asigna qué acción de respuesta se puede ejecutar ante cada uno de los tipos de

intrusión. No obstante, el grado de precisión es insuficiente y podría dar lugar a la ejecución de una

acción de respuesta que no neutralice el ataque. El objetivo de esta clasificación es seleccionar

aquellas acciones de respuesta que puedan neutralizar un ataque.

Tabla 4.5 Listado de acciones de respuesta clasificadas según el tipo de intrusión.

ID

Info

rmation

Gath

eri

ng A

ttack

Netw

ork

Attacks

BackD

oors

Passw

ord

Attacks

Explo

its

Virus

Worm

s

Tro

yan

Buff

er

Overf

low

Denia

l of

Serv

ice

GENERALES

R1 X X X X X X X X X X






R7 X X X X X X X


BASADAS EN HOST

R9 X X X X

R10 X X X

R11 X X X

R12 X X

R13 X X X X X X

R14 X X X

R15 X

R16

R17

R18 X X X

R19 X X


151

R20 X X

R21 X

R22 X X X

R23 X X

R24 X X

R25 X

R26 X X X X

R27 X

BASADAS EN RED

R28 X X X

R29 X

R30 X

R31 X X X X X

R32 X

R33 X X X X

R34 X X

R35 X


R37

R38 X

4.4.4.3 Respuestas en función del tipo de dispositivo de seguridad

La tercera dimensión de clasificación es el tipo de dispositivo de seguridad requerido para ejecutar

cada acción de respuesta, ya que no todos los dispositivos de seguridad pueden desplegar ni hacer

efectivas todas las acciones de respuesta.

Como se explica en el apartado correspondiente al módulo de ejecución de acciones de respuesta,

cada acción de respuesta se implementa mediante plugins. Cuando se registra un plugin se indican el

o los dispositivos de seguridad que pueden ejecutar dicha acción de respuesta.

En este apartado se ha elaborado una lista de acciones de respuesta que puede ejecutar el AIRS

basado en ontologías de forma automática. En el Capítulo 8 se muestra el listado de acciones de

respuesta implementadas para la validación del AIRS basado en ontologías propuesto, indicando

para cada una de ellas, su ID, su tipo, los ataques frente a los cuales son efectivas y los dispositivos

de seguridad encargados de hacerlas efectivas.

4.4.5 Módulo de ejecución de acciones de respuesta

El módulo de ejecución de acciones de respuesta es el componente de la arquitectura encargado de

poner en marcha mecanismos reales para ejecutar la respuesta inferida por el Razonador,

proporcionando los argumentos e instrucciones necesarias a los dispositivos de seguridad del

sistema encargados de hacer efectiva la respuesta. Para ello, consulta el catálogo de respuestas

disponible, denominado en la arquitectura como Response Toolkit o Catálogo de Acciones de

Respuesta.

Este módulo es un módulo distribuido, seguro, confiable y escalable, que posee las siguientes

características principales:

- Permite ejecutar acciones de respuesta de forma local (en la misma máquina en la que se

ejecuta el AIRS) y remota. El AIRS tiene capacidad para ejecutar acciones de respuesta

interactuando con otros dispositivos de seguridad, como cortafuegos (agregar reglas de

filtrado que bloquean al atacante), routers (agregar listas de control de acceso para bloquear

determinado flujo de tráfico) o hosts (terminar un proceso o servicio, terminar conexiones,

deshabilitar un usuario, etc.). Estas acciones de respuesta se llevan a cabo de forma remota.


152

- Evalúa los parámetros requeridos para ejecutar cada acción de respuesta, antes de llevarla a

cabo, como por ejemplo, la dirección IP del dispositivo de seguridad encargado de hacer

efectiva la respuesta, o la dirección IP a bloquear.

La arquitectura del módulo de ejecución de respuestas consta de cuatro componentes principales:

Módulo Central de Ejecución (MCE), Módulo de Comunicación (MC), Agente de Ejecución (AE) y

Gestor de plugins, y Dispositivo de Seguridad (DS). Previa a la especificación de la función de cada

uno de estos componentes en la arquitectura, se cree conveniente presentar los requisitos

funcionales y no funcionales que pretende cubrir.

4.4.5.1 Requisitos del módulo de ejecución de acciones de

respuesta

En la Tabla 4.6 se detallan los requisitos funcionales asociados a cada componente. Además se

incluyen requisitos que debe cumplir el propio AIRS, ya que a pesar de ser un componente externo a

la arquitectura del módulo de ejecución, impone ciertos requisitos al ejecutor de respuestas que hay

que tener en cuenta.

Tabla 4.6 Requisitos funcionales del módulo de ejecución de acciones de respuesta [Guaman13]

Componente Ref. Requisito

Razonador

(Reasoner) de

AIRS basado

en ontologías

REQF01 Debe receptar las alertas provenientes del IDS a través del receptor de alertas del AIRS

basado en ontologías y parsear a la ontología correspondiente.

REQF02 Debe inferir la respuesta óptima a la alerta de intrusión recibida.

REQF03 Debe invocar la acción de respuesta usando el valor de la propiedad responseAction de la

ontología del AIRS.

REQF04

Debe proporcionarle al módulo central de ejecución, los siguientes parámetros: 1) Dirección IP

origen (atacante), 2) Dirección IP destino (víctima), 3) Puerto destino, 4) Protocolo, 5) SID

(signature ID), 6) protocolo; cuando se trata de una intrusión detectada por un NIDS.

REQF05

Debe proporcionar al módulo central de ejecución, al menos los siguientes parámetros: 1)

Dirección IP origen (atacante), 2) Dirección IP del host atacado, y 3) Nombre de usuario con el

que se efectúa la intrusión; cuando se trata de una intrusión detectada por un HIDS.

MCE

REQF06 Debe obtener la información de localización de los agentes de ejecución.

REQF07 Debe tener la capacidad de formar grupos de agentes de ejecución sobre los que se ejecutará

una acción de respuesta

REQF08

Debe obtener los parámetros fijos asociados a cada respuesta, en donde el nombre que

identifica a cada respuesta coincide con el parámetro responseAction de la ontología del

AIRS.

REQF09 Debe tener la capacidad de agrupar varias acciones de respuesta y manejarla como si se

tratara de una sola.

REQF10 Debe construir el paquete de solicitud de acción de respuesta.

REQF11 Debe emitir la solicitud al módulo de comunicaciones, proporcionándole la información

necesaria para saber a dónde enviar.

MC REQF12

Debe establecer una conexión con el o los agentes de ejecución definidos previamente por el

MCE.

REQF13 Debe cifrar la solicitud de acción de respuesta a emitirse hacia el agente de ejecución.

AE

REQF14 Debe obtener los parámetros necesarios de cada componente de seguridad con los que

requiera interactuar.

REQF15 Debe escuchar las solicitudes de respuesta emitidas por el módulo central de ejecución.

REQF16 Debe recibir el paquete de solicitud de acción de respuesta.

REQF17 Debe obtener el conjunto de comandos a ejecutar sobre el componente de seguridad.


153

REQF18 Debe acceder a la interfaz de línea de comandos del componente de seguridad respectivo y

ejecutarlos.

REQF19 Debe tener la capacidad de ejecutar una acción de respuesta por un tiempo definido por el

administrador, luego del cual la acción no tendrá efecto.

REQF20 Si las solicitudes de acción de respuesta son similares y una respuesta ya se encuentra

activa, entonces debe tener la capacidad de extender una acción de respuesta.

REQF21 Debe verificar la identidad del Módulo central de ejecución.

REQF22 Debe obtener la lista blanca de entidades sobre las que no se ejecuta una acción de

respuesta.

REQF23 Debe verificar que la solicitud de acción de respuesta no incluya a una entidad incluida en la

lista blanca.

DS REQF24 Debe proporcionar un medio de acceso a la interfaz de línea de comandos.

4.4.5.2 Arquitectura del módulo o sistema de ejecución de acciones

de respuesta

Una vez especificados los requisitos del ejecutor de respuestas, en este punto se muestran los

aspectos más relevantes del diseño de su arquitectura y se proporciona una definición de cada uno

de sus módulos.

Previo al diseño e implementación del módulo de ejecución de respuestas se evaluaron y revisaron

tres herramientas Open Source, con el fin de identificar aquellos componentes que pudieran ser

reutilizados en la arquitectura y posterior implementación del ejecutor de respuestas: SnortSam1,

FwSnort2 y Snort_Inline

3. Los criterios principales de evaluación fueron (1) la capacidad de ejecutar

respuestas activas de los cuatro tipos especificados (protección, reacción, recuperación y engaño) y

respuestas basadas en red, (2) la capacidad de respuesta ante alertas procedentes de un NIDS y (3)

la capacidad para ejecutar una acción de respuesta de forma distribuida, es decir, la capacidad de

interactuar con varios componentes de seguridad.

Como conclusiones del análisis se extrajo que:

- Las tres herramientas tienen capacidad de ejecutar respuestas basadas en red.

- FWSnort y Snort_Inline son IPSs por lo que sólo tienen capacidad de ejecutar respuestas

activas de protección. Además, debido a su ubicación no interactúan con otros componentes

de seguridad dada su naturaleza de IPS, es decir, no tienen la capacidad de ejecutar una

acción de respuesta de forma distribuida con otros componentes de seguridad.

- SnortSam, tampoco tiene la capacidad de ejecutar acciones de respuestas distintas a

respuestas activas de protección, pero presenta una arquitectura distribuida y basada en

plugins, por lo que tienen la capacidad de ejecutar acciones de respuesta de forma

distribuida.

Por ello, SnortSam es de las tres, la herramienta que cumple con mayor número de criterios, y ha sido

de gran utilidad en el diseño y la implementación del ejecutor de respuestas. Tras una evaluación

más exhaustiva de SnortSam, se ha considerado reutilizar su módulo de comunicación, su agente

ejecutor y su gestor de plugins en la arquitectura del sistema de ejecución de respuestas del AIRS

basado en ontologías. No obstante, varias modificaciones han sido realizadas sobre dichos

componentes para adaptarlos a la arquitectura del sistema de ejecución de respuestas.

1 http://www.snortsam.net

2 http://www.cipherdyne.org/fwsnort

3 http://snort-inline.sourceforge.net/oldhome.html


154

En base a los requisitos especificados, se ha definido una arquitectura compuesta por 5 módulos,

como se observa en la Figura 4.7: Módulo Central de Ejecución (MCE), Módulo de Comunicación

(MC), Agente de Ejecución (AE), Gestor de plugins y Dispositivos o componentes de Seguridad (DS).

Figura 4.7 Arquitectura del módulo de ejecución de acciones de respuesta. [Guaman13]

Esta arquitectura satisface todos los requisitos funcionales y no funcionales indicados en el punto

anterior. La característica más relevante de la arquitectura es su naturaleza distribuida, que es por

otra parte, un requisito inherente del ejecutor de respuestas, dada la necesidad de contar con

múltiples agentes distribuidos a los que se les pueda solicitar la ejecución de una determinada acción

de respuesta.

El Razonador del AIRS basado en ontologías y los IDSs, tanto NIDSs como HIDSs, son componentes

externos al sistema de ejecución, pero proporcionan las entradas necesarias para que este funcione

correctamente. Así mismo, es importante recalcar que el módulo de comunicaciones, el agente de

ejecución y el gestor de plugins, son componentes propios de SnortSam, que se han utilizado en la

implementación y el desarrollo del ejecutor de respuestas, como se indica anteriormente en este

apartado. No obstante, varias modificaciones han sido realizadas sobre dichos componentes para

adaptarlos a la arquitectura del sistema de ejecución de respuestas.

Cada uno de los componentes presentes en la arquitectura tiene una función clara e independiente

del resto, y para su comunicación basta con conocer las interfaces de entrada y salida respectivas.

Cada uno de ellos procesa los datos de entrada y proporciona los datos de salida respectivos.

De forma breve, a continuación se describe la función de cada componente.

IDSs y Razonador del AIRS

Los IDSs y el Razonador del AIRS basado en ontologías ya han sido especificados en puntos

anteriores de este capítulo. Dentro de la arquitectura del sistema de ejecución, actúan como sistemas

externos y son quienes inician el proceso de inferencia de la respuesta óptima, como se indica en

varias ocasiones a lo largo de la memoria. Algunos de los parámetros incluidos en las alertas de

intrusión generadas por los IDSs son proporcionados al sistema de ejecución por el Razonador para

que el dispositivo de seguridad pueda desplegar la respuesta inferida.

Por su parte, el Razonador actúa también como un sistema externo y está situado en el mismo lugar

que el MCE.

Como se indica en este capítulo, cada vez que uno de los IDSs detecta una intrusión, genera una

alerta que envía al AIRS basado en ontologías, encargado de inferir la respuesta óptima utilizando

unas políticas o reglas predefinidas. Una vez que el razonador infiere la respuesta óptima, invoca al

MCE del módulo de ejecución de acciones de respuesta proporcionándole como parámetros de


155

entrada el valor de la propiedad responseAction de la clase Response de la ontología del AIRS (Ver

5.4.3.5), y parámetros incluidos en la alerta de intrusión, como la dirección IP origen y destino, el

puerto origen y destino, o el protocolo utilizado. Estos parámetros son necesarios para desplegar una

determinada acción de respuesta específica.

Es importante señalar que el Razonador es quien debe garantizar y proporcionar los parámetros

necesarios relacionados al ataque que permitan ejecutar una acción de respuesta. Por ejemplo:

Una acción de respuesta con nombre DenegarConexion, que bloquea el tráfico asociado a

una conexión específica sobre un cortafuegos, debe invocar la acción de respuesta

proporcionando las direcciones IP origen y destino, puertos y protocolo empleado en la

conexión.

Por su parte, una acción de respuesta con nombre DeshabilitarUsuario, que deshabilita a un

usuario que intenta ejecutar un ataque, debe invocar la acción de respuesta proporcionando

la dirección IP del host atacado y el nombre de usuario.

La manera en la que estos parámetros son obtenidos es ajena al módulo de ejecución de respuestas.

El MCE asume que todos los parámetros requeridos relacionados con la intrusión son suministrados

por el Razonador.

Módulo Central de Ejecución de Respuesta (MCE)

El módulo central de ejecución de respuesta se encarga principalmente de dos tareas: construir una

solicitud de respuesta e identificar el o los agentes de ejecución a donde se enviará la solicitud de

respuesta.

Para construir una solicitud de acción de respuesta, el MCE recibe los parámetros de dos fuentes

[Guaman13]:

- Desde el Razonador, que proporciona los parámetros necesarios para ejecutar la acción de

respuesta, entre ellos, la acción de respuestas y parámetros relacionados con la intrusión,

como la dirección IP origen o el puerto.

- De un fichero de configuración que contiene información fija proporcionada por el

administrador relacionada con los agentes de ejecución y los plugins de respuesta. Más

información acerca de este fichero de configuración y de la implementación del MCE se

proporciona en 8.3.

Este módulo en primer lugar construye una solicitud de ejecución de una acción de respuesta, para a

continuación enviar dicha solicitud al agente de ejecución correspondiente, utilizando el protocolo de

transporte TCP. El MCE conoce las direcciones IP de los agentes de ejecución gracias al fichero de

configuración.

Módulo de Comunicación (MC)

El objetivo principal de este módulo es proveer un marco común de comunicación entre el MCE y los

agentes de ejecución. Independientemente del tipo de acción de respuesta a ejecutar sobre el agente

de ejecución, éste módulo debe proveer servicios de entrega confiable y segura de las solicitudes de

acción de respuestas activas y pasivas inferidas por el Razonador y construidas por el MCE. El marco

de comunicación debe ser confiable y seguro (cifrado):

- Confiable: para ello, el establecimiento de conexión entre el MCE y el agente de ejecución se

efectúa mediante el protocolo de transporte TCP. El puerto de escucha del agente de

ejecución debe ser proporcionado al MCE previamente.

- Cifrada: las solicitudes de acción de respuesta que viajan a través de la red se cifran

utilizando el algoritmo de cifrado en bloques simétrico TwoFish. El tamaño del bloque en

TwoFish es de 128 bits y el tamaño de la clave puede alcanzar los 256 bits. Éste algoritmo de

cifrado es muy robusto y se propuso como reemplazo del algoritmo DES.


156

El marco común de comunicación permite el despliegue de varias acciones de respuesta sobre

componentes de seguridad remotos en los cuales se ha instalado un agente de ejecución. Cabe

recalcar que éste módulo reutiliza lo implementado por la herramienta SnortSam, pero para su

utilización en el sistema de ejecución de respuestas del AIRS basado en ontologías ha sido necesario

hacer algunos cambios y adaptaciones en el protocolo de comunicación utilizado, en especial en el

formato de paquete de solicitud utilizado, como se recoge en 8.3.

Agente de Ejecución (AE)

El agente de ejecución actúa como un servicio que siempre se está ejecutando a la espera de la

llegada de nuevos paquetes de solicitud de respuesta. Ante la llegada de un paquete de solicitud,

selecciona el plugin adecuado y ejecuta el conjunto de comandos asociados a una respuesta activa o

pasiva sobre el dispositivo de seguridad pertinente.

La primera tarea que lleva a cabo el agente de ejecución es la inicialización de plugins, los mismos

que han sido registrados por el gestor de plugins, como se verá en el siguiente punto.

A continuación, el agente de ejecución se queda a la espera de paquetes de solicitud de respuesta.

Cuando el agente de ejecución recibe un paquete de solicitud de respuesta a través del módulo de

comunicación, primero verifica la autenticidad del emisor de la solicitud de acción de respuesta. Si el

emisor es auténtico, entonces descifra el mensaje y verifica que la solicitud no está dirigida hacia uno

de los componentes que se encuentra en lista blanca.

Por último, el agente de ejecución selecciona el plugin especificado en el paquete de solicitud e

invoca a la rutina correspondiente para la ejecución de la acción de respuesta sobre el componente

de seguridad respectivo. Cuando finaliza la ejecución, el agente envía como respuesta un resultado

que es almacenado en un archivo de logs del MCE.

Su principal función es, por tanto, seleccionar el plugin adecuado y ejecutar el conjunto de comandos

asociados a una respuesta activa o pasiva sobre el dispositivo de seguridad pertinente cada vez que

recibe un paquete de solicitud procedente del MCE.

Otra de las tareas que lleva a cabo el agente de ejecución es el control del tiempo durante el cual

tendrá efecto una acción de respuesta, tal como se mencionó anteriormente. Este parámetro es

definido por MCE, y es almacenado por el agente de ejecución y su función es determinar el

momento en el que deshacer una acción de respuesta.

Por último, es necesario indicar que el agente de ejecución puede interactuar con el dispositivo de

seguridad de dos formas, en función del tipo de este último:

- Forma local: cuando el componente o dispositivo de seguridad y el agente de ejecución se

despliegan en el mismo equipo.

- Forma remota: cuando el agente de ejecución no puede ser instalado sobre el dispositivo que

contiene el componente de seguridad, al tratarse de un dispositivo dedicado. Por ejemplo, si

el dispositivo de seguridad es un router Cisco, el agente de ejecución debe establecer

previamente una conexión telnet o ssh con el dispositivo remoto para acceder a la interfaz de

línea de comandos y posteriormente ejecutar la acción de respuesta.

Gestor de Plugins

El gestor de plugins es un componente de gran relevancia dentro de la arquitectura del ejecutor de

respuestas ya que permite resolver el problema de la heterogeneidad de los componentes de

seguridad con los que tiene que interactuar el agente de ejecución. Una solicitud de respuesta

siempre tiene la misma estructura, independientemente del componente de seguridad. Pero por el

contrario, cada componente de seguridad tiene su propia sintaxis e interfaz de línea de comandos y

requiere parámetros específicos para su ejecución. Mediante el encapsulamiento de la lógica de

control de una acción de respuesta en un plugin, el ejecutor de respuestas puede ser utilizado como


157

una plataforma escalable para desplegar nuevas acciones de respuesta sobre diversos componentes

de seguridad sin tener la necesidad de modificar otros módulos del ejecutor de respuestas.

El gestor de plugins permite el manejo de varios componentes de seguridad a través del despliegue

de plugins, con el objetivo de resolver algunos problemas que incluyen básicamente 3 aspectos:

- Cada dispositivo de seguridad requiere de diferentes parámetros de configuración. Así, por

ejemplo: iptables, requiere de la interfaz de red sobre la que se aplicará una regla; el

despliegue de una honeynet virtual mediante VNX, requiere el nombre de usuario y la ruta del

archivo VNX; router cisco, requiere dirección IP y contraseña, etc.. Esto provoca que el plugin

correspondiente tenga que separar cualquier dependencia de la dotación de los parámetros

del agente de ejecución.

- Cada dispositivo de seguridad tiene sus propios comandos de configuración y requiere una

lógica de control específica de dicho componente. Por consiguiente, el plugin tiene que

encapsular dicha lógica de control.

- Cada componente de seguridad tiene diferentes capacidades en cuanto a la posibilidad de

deshacer una acción, soportar múltiples hilos de ejecución, requerir una función de keepalive,

etc. Esta información es requerida por el agente de ejecución y por tanto debe ser

proporcionada en el registro del plugin en el gestor.

En la Figura 4.8, se observa que el gestor posee dos interfaces, una interfaz de registro y una interfaz

de consulta de plugins.

Figura 4.8 Interfaces del gestor de plugins del módulo de ejecución de acciones de respuesta [Guaman13]

Cada vez que se quiere registrar un nuevo plugin en el gestor, se debe hacer mediante la interfaz de

registro, para lo que el plugin ha de proporcionar cinco interfaces y ciertos indicadores necesarios

para la operación del agente de ejecución. Un breve resumen de cada interfaz es el siguiente:

- Interfaz de inicialización: interfaz utilizado para ejecutar una rutina de inicio que verifique

ciertas precondiciones requeridas para ejecutar una respuesta. Si la rutina de inicio no se

ejecuta correctamente, entonces el plugin es deshabilitado.

- Interfaz de parsing: interfaz utilizado para ejecutar una rutina de parsing de los parámetros de

configuración requeridos para ejecutar una respuesta sobre un componente de seguridad.

Mediante este interfaz se indican qué parámetros son necesarios para ejecutar una

determinada acción de respuesta (por ejemplo, dirección IP del dispositivo de seguridad,

contraseña pertinente, etc.).

- Interfaz de ejecución: interfaz utilizado para hacer referencia a la rutina que contiene la lógica

de control que lleva a cabo la acción de respuesta. Mediante esta interfaz se indican los

comandos necesarios para ejecutar o desplegar la acción de respuesta asociada al plugin.

- Interfaz de finalización: interfaz utilizado para ejecutar una rutina de salida en el momento en

que el ejecutor de respuestas se cierra. Esto le otorga al plugin la posibilidad de limpiar o

ejecutar acciones a conveniencia.


158

- Interfaz de keepalive: interfaz utilizado para ejecutar una rutina de keep-alive, cuya función es

mantener conexiones persistentes con componentes de seguridad que así lo requieran.

Además de las cinco interfaces, varios indicadores pueden ser requeridos durante la fase de registro

del plugin y pueden ser añadidos conforme a las necesidades del agente de ejecución. Por ejemplo

una función del agente de ejecución es deshacer una acción de respuesta después de un tiempo

determinado; no obstante, algunas respuestas como por ejemplo la restauración de ficheros, no

requieren esta función; por lo tanto a través de un indicador se dice al agente de ejecución que dicho

plugin no requiere esa funcionalidad.

Dispositivos o componentes de seguridad

Representa el dispositivo que lleva a cabo la acción de respuesta real utilizando su interfaz de línea

de comandos. Un dispositivo de seguridad puede ser: un router, cortafuegos, servidor web, servidor

FTP, gestor de usuarios, gestor de procesos, etc.

El módulo de ejecución de acciones de respuesta es de vital importancia para el correcto

funcionamiento del AIRS basado en ontologías propuesto, puesto que es el componente encargado

de desplegar la acción inferida, de hacerla efectiva. Una vez que la respuesta ha finalizado su

ejecución, el módulo enviará un mensaje al Razonador del AIRS, que contiene un código de éxito o

error. En caso de éxito, el Razonador invocará al sistema de evaluación del éxito de la respuesta, que

se encargará de evaluar si la respuesta ha sido ejecutada con éxito, es decir, ha conseguido mitigar

el ataque, o por el contrario, no ha tenido efecto sobre él.

Más detalles sobre la implementación de cada uno de los componentes presentes en la arquitectura

del módulo de ejecución de acciones de respuesta incluido en el AIRS basado en ontologías pueden

ser encontrados en [Guaman13].

4.4.6 Análisis de la propuesta

En esta sección se propone el uso de ontologías, lenguajes formales de reglas y razonadores

semánticos como núcleo la arquitectura de un AIRS. En la evaluación de alternativas, se presentan

una serie de ventajas derivadas de la utilización de ontologías en entornos heterogéneos, lo que las

convierte en tecnologías apropiadas y viables para resolver el problema de la coherencia semántica

en la representación de alertas, existente en otros AIRSs analizados.

Como resultado de la evaluación de alternativas se elige OWL2 como lenguaje de representación del

conocimiento, SWRL como lenguaje de reglas que permite especificar el comportamiento del

razonador y Pellet como razonador semántico utilizado en la arquitectura propuesta.

Además, esta arquitectura se compone de otros módulos como son: Receptor de Alertas (Alerts

Receiver), Contexto de Red (Network Context), Contexto de Sistemas (System Context), Receptor de

información de Contexto (Context Receiver), Ontología de Respuesta a Intrusiones (Intrusion

Response Ontology), Políticas (Policies), Razonador (Reasoner), Catálogo de Acciones de Respuesta

(Response Toolkit), Ejecutor de Acciones de Respuesta (Responses Ejecutor), Evaluador del éxito de

Acciones de Respuesta (Intrusion Response Evaluation) e Interfaz de Administración (Admin

Interface). Cada uno de los módulos funciona de manera independiente y para su comunicación basta

con conocer las interfaces de entrada y salida respectivas.

El funcionamiento de todos ellos permite dotar al sistema en mayor o menor medida de los requisitos

de un AIRS ideal: proactividad, adaptabilidad, coherencia semántica, rapidez, sensibilidad al coste de

las respuestas, y evaluación dinámica del coste.


159

4.5 Conclusiones

Queda patente la necesidad de un sistema de respuesta automático frente a intrusiones que sea

capaz de responder de forma inmediata frente a cualquier intrusión detectada en la red o sistemas de

una organización sin necesidad de intervención del administrador del sistema, con el fin de reducir la

ventana de tiempo entre que se produce la detección del ataque y el administrador ejecuta una

medida de respuesta.

Tras el análisis de los sistemas de respuesta existentes se concluye que ninguno de ellos cumple

todos los requisitos deseados, además de que no abordan el tema de la coherencia semántica en la

representación de alertas, para entre otras cosas evitar duplicados en entornos heterogéneos.

Con el fin de solventar este problema, en este capítulo se propone el uso de ontologías y

herramientas de la Web Semántica, útiles en entornos heterogéneos, como núcleo de la arquitectura

de un AIRS.

Además, se proponen otros módulos interesantes como el módulo de evaluación de la anomalía del

contexto de red y de sistemas, y el módulo de ejecución de acciones de respuesta.

Capítulo 5: Propuesta de Ontología de Respuesta a Intrusiones

161

PROPUESTA DE ONTOLOGÍA DE Capítulo 5

RESPUESTA A INTRUSIONES

5.1 Introducción

En el capítulo anterior se propone una arquitectura de un sistema de respuesta automática frente a

intrusiones, donde cada uno de los módulos que la componen contribuye en mayor o menor medida

al correcto funcionamiento del AIRS. Uno de los elementos más importantes de dicha arquitectura, y

clave para que el AIRS alcance su principal objetivo de inferir la respuesta óptima frente a intrusiones,

es la ontología de respuesta a intrusiones.

De la especificación de la ontología, así como de su claridad, objetividad, completitud, coherencia y

consistencia dependerá en gran medida la eficacia y precisión del sistema de respuesta propuesto.

Como se define en el Capítulo 3, una ontología es una especificación explícita y formal de una

conceptualización compartida. Es decir, una ontología es una herramienta que permite definir y

especificar en lenguaje formal una realidad o dominio, para lo que hace uso de una jerarquía de

clases con atributos y relaciones, un conjunto de instancias interrelacionadas y un conjunto de

axiomas o reglas que imponen ciertas restricciones o condiciones sobre las clases y/o instancias.

Desde un punto de vista de ingeniería, una ontología se constituye por un vocabulario específico

utilizado para describir una cierta realidad, además de un conjunto de suposiciones que tienen en

cuenta el significado del vocabulario.

Aunque ya se ha hecho referencia en varias ocasiones a las ventajas del uso de ontologías en la

seguridad de las redes informáticas, a lo largo del presente capítulo, se quiere reseñar que las

ontologías solucionan el problema de la heterogeneidad semántica de las diferentes fuentes de

alertas (mapean la información recibida a un modelo integrado semánticamente asegurando de esta

forma que la información es gestionada y procesada adecuadamente por el AIRS) y permiten

especificar el comportamiento del AIRS e integrarlo con la información definida de tal forma que el

comportamiento del sistema no da lugar a inconsistencias. Además, actualmente se cuenta con un

numeroso conjunto de lenguajes y herramientas para la definición formal de información (Ver 3.2) y

comportamiento (Ver 3.3), así como para la inferencia de nuevo conocimiento (Ver 3.4).

Por otra parte, el uso de taxonomías y ontologías en seguridad informática no es algo novedoso, y en

los últimos años se han propuesto muchos trabajos relacionados con la clasificación y modelado de

información de seguridad. No obstante, el objetivo de una ontología es describir una cierta realidad,

modelar un dominio específico, y es realmente difícil encontrar una ontología ya existente que cubra

todos los aspectos relacionados con el área de interés de esta tesis doctoral ya que ninguna de las

ontologías analizadas modela completamente el proceso de respuesta a una intrusión.

Ante esta problemática, en este capítulo se propone una ontología de respuesta a intrusiones que

define formalmente los conceptos implicados en el proceso de respuesta frente a una intrusión


162

llevado a cabo por un AIRS. Para ello, esta contribución original de la presente tesis doctoral se basa

en:

- Análisis de las taxonomías y ontologías de seguridad existentes desde el punto de vista de su

posible reutilización para modelar la realidad de interés.

- Análisis de las metodologías de creación y desarrollo de ontologías existentes y elección de

la más adecuada para la especificación de la ontología de respuesta a intrusiones.

- Propuesta de una ontología de respuesta a intrusiones, detallando cada paso de la

metodología y los productos generados. Para ello, se especifica el dominio a modelar y se

definen las clases, propiedades, relaciones y axiomas que componen la ontología.

5.2 Metodología

La propuesta se abordará siguiendo la siguiente metodología:

Propuesta: definición y especificación de una ontología de respuesta a intrusiones que

modele el proceso de respuesta a un ataque llevado a cabo por el AIRS. La descripción de

esta propuesta se encuentra en la Sección 5.1.

Análisis de ontologías en seguridad informática: se analizan las distintas ontologías

existentes y su aplicación en la seguridad de redes de telecomunicación. Además, se

presenta una revisión de las taxonomías de vulnerabilidades, ataques y respuestas

existentes, debido a su importancia a la hora de definir la ontología de respuesta a

intrusiones. Este análisis se encuentra en la Sección 5.3.

Formalización: Descripción detallada de la ontología propuesta, así como de la metodología

de desarrollo y creación utilizada. La ontología se presenta en la Sección 5.4.

Verificación y Validación: Comprobación de que la ontología y su integración en el sistema

son técnicamente viables, y validación de la misma desde el punto de vista de escalabilidad y

rendimiento. Esta validación se presenta en el Capítulo 8.

5.3 Las ontologías y su aplicación en la seguridad de redes de

telecomunicación

El uso de taxonomías y ontologías en seguridad informática no es algo novedoso. En los últimos

años, se han propuesto muchos trabajos relacionados con la clasificación y modelado de información

de seguridad.

Las taxonomías son sistemas de clasificación. En el campo de las respuestas frente a intrusiones,

permiten clasificar y modelar un ataque y una acción de respuesta en función de varias

características que constituyen las dimensiones de la taxonomía. Mediante las taxonomías se

clasificarán tanto los ataques como las respuestas a esos ataques, proporcionando el marco teórico

necesario para responder coherentemente a los ataques, puesto que de las normas y políticas

seguidas en la clasificación de los ejemplares y de la estructura de la propia taxonomía, depende la

eficacia y precisión de un AIRS, como veremos más adelante. En relación a la respuesta frente a

intrusiones, son interesantes tres tipos de taxonomías: taxonomías de vulnerabilidades, de ataques y

de respuestas.

Las investigaciones y publicaciones más antiguas dentro de este campo versan sobre las taxonomías

de vulnerabilidades de seguridad (Protection Analysis taxonomy [Bisbey78], la taxonomía propuesta

por Landwehr [Landwehr94], la taxonomía de Bisho [Bishop96] o la taxonomía de Islam [Aslam95]).

Además, existe una lista pública de vulnerabilidades denominada CVE (Common Vulnerabilities and


163

Exposures) que contiene más de 2500 vulnerabilidades conocidas, que se ha convertido en un

estándar de facto para clasificación e identificación de vulnerabilidades.

En cuanto a las taxonomías de ataques existentes cabe destacar la taxonomía propuesta por

Hansman y Hunt [Hansman05], que categoriza un ataque en base a cuatro dimensiones: vector de

ataque (virus, gusanos, troyanos, BufferOverflow, denegación de servicio, ataques de red, ataques

físicos, ataques de contraseña y ataques de recolección de información), objetivo del ataque

(componente hardware (host, equipo de red o periféricos), software (sistema operativo o aplicación) o

red (protocolo al que va dirigido el ataque), vulnerabilidad explotada (utiliza el identificador CVE para

su clasificación) y extensión de alcance o payload. Las dos primeras dimensiones pueden contener

niveles adicionales dependiendo del grado de especialización requerido. Por ejemplo, la dimensión de

vector de ataque, en el caso de ataques de red, se divide a nivel 2 en spoofing, hijacking, wireless o

ataques web.

En relación a las taxonomías de respuesta existentes, se destaca la propuesta por Wang et al.

[Wang-H06], denominada 5W2H, que clasifica una acción de respuesta en base a siete dimensiones:

momento de respuesta - when (antes, durante o después del ataque), impacto o coste de la

respuesta – how serious (bajo, medio o alto), localización del atacante – where (respuesta destinada

a atacantes internos o externos), tipo de ataque – how to (ataque contra la confidencialidad,

integridad, disponibilidad, reconocimiento o negación), objetivo del ataque – what (cortafuegos,

servidor, Workstation, etc.), tipo de atacante - who (organizaciones militares, ciberdelincuentes, etc.),

y plan de ataque – why (respuestas ante ataques de robo, vandalismo, etc.).

Si bien estas taxonomías permiten clasificar de una forma exhaustiva y precisa tanto un ataque como

una acción de respuesta, carecen de las construcciones necesarias y suficientes para razonar con las

instancias del dominio modelado. Además, como se indica en la introducción del Capítulo 3, las

ontologías están formadas por dos elementos, una taxonomía y un conjunto de reglas de inferencia,

que permiten expresar restricciones y condiciones sobre los objetos de las clases definidas mediante

la taxonomía.

En el área de la seguridad informática, varias ontologías han sido propuestas.

En [Souag12], los autores revisan, analizan, seleccionan y clasifican ontologías de seguridad,

proporcionando como resultado una visión general de los trabajos existentes en el área de ontologías

de seguridad. Clasifican las ontologías en varias familias: ontologías de seguridad básicas (las

primeras ontologías existentes relacionadas con la seguridad informática), taxonomías de seguridad,

ontologías de seguridad genéricas (aquellas ontologías que pretenden cubrir todos o casi todos los

aspectos de la seguridad), ontologías específicas de seguridad (ontologías dedicadas a un dominio

concreto y específico, como puede ser la seguridad en servicios de VoIP), ontologías de seguridad en

aplicaciones web, ontologías de seguridad desde el punto de vista del análisis de riesgos y ontologías

de requisitos de seguridad.

Undercoffer et al. ([Undercoffer03] y [Undercoffer04]) analizan la transición de utilizar taxonomías y

lenguajes utilizados por las taxonomías a utilizar ontologías y lenguajes de representación de

ontologías, en sistemas de detección de intrusiones. Además, proponen una ontología de seguridad

específica cuyo objetivo es modelar el dominio de la detección de intrusiones, para lo que los autores

analizan alrededor de 4000 clases de intrusiones y sus estrategias de ataque correspondientes.

Como consecuencia del análisis realizado clasifican la intrusión en base a cuatro dimensiones:

componente objetivo del ataque (pila de protocolos, sistema operativo o aplicaciones), vector de

ataque, consecuencia del ataque (negación de servicio, acceso no autorizado, pérdida de

confidencialidad y robo de información) y ubicación del ataque (remoto, local o remoto/local). Esta

clasificación o taxonomía es la base de la ontología de seguridad propuesta, cuyo objetivo es modelar

los conceptos relacionados con la detección de intrusiones, conceptos de los que derivan las distintas

clases que forman la ontología: Host, State (Network, System y Process son sus subclases),

Intrusion, Consequence (tiene 5 subclases: Denial of Service, Remote to Local, User to Root, Loss of

Confidentiality y Probe), Input, System Component (Protocol Stack, Kernel, Application y Other son


164

sus subclases), Location (Local y Remote son sus subclases) y Means (posee 2 subclases: Input

Validation Error y Logic Exploit). La ontología está definida utilizando el lenguaje DAML+OIL.

En [Vorobiev06], los autores proponen una ontología de ataques a servicios Web, fácil de

implementar y desplegar, que puede ser utilizada por distintos IDSs o cortafuegos para proteger a los

sistemas basados en aplicaciones y servicios Web de diferentes tipos de ataque, incluyendo ataques

distribuidos y multi-paso. La ontología propuesta incluye la definición de distintos tipos de ataques

Web, como por ejemplo, ataques de denegación de servicio (clase WS DoS General Attacks),

ataques a aplicaciones web (clase Application Attacks de la ontología) o ataques a ficheros XML

(clase XML Attacks). Para la definición de la ontología los autores han utilizado los lenguajes OWL y

OWL-S.

Tsoumas et al. [Tsoumas06] definen una ontología que modela requisitos de seguridad. La ontología

extiende el modelo DMTF CIM (Common Information Model) enriqueciéndolo con la semántica

ontológica. El hecho de utilizar ontologías proporciona el valor añadido de que se fomenta el

intercambio de información así como la reutilización de otras ontologías ya definidas. Para el

modelado de los conceptos y relaciones de la ontología se utilizan estándares como la ISO-IED

17799, el Australian Standard Handbook of Information Security Risk Management (AS/NZS 4360), o

el método CRAMM (CCTA Risk Analysis and Management Method). La ontología propuesta está

definida en OWL-DL y modela los conceptos involucrados en la gestión de la información de

seguridad y el análisis de riesgos. Está formada por doce clases: Threat Agent, Threat, Attack, Asset,

Risk, Vulnerability, Unwanted Incident, Impact, Countermeasure, Stakeholder, SecurityPolicy y

Controls. Además de la propuesta de ontología, los autores presentan una arquitectura de sistema de

gestión de la seguridad de la información donde utilizan la ontología definida.

Abdoli y Kahani [Abdoli09] proponen una ontología de ataques a la que denominan Ontology based

Distributed Intrusion Detection System (ODIDS) para su aplicación en sistemas de detección de

intrusiones distribuidos. Para construir la ontología, los autores utilizan la taxonomía propuesta por

Hansman et al. [Hansman05] como base, que clasifica los ataques en función de cuatro dimensiones:

el vector de ataque (los ataques se clasifican en varios grupos: virus, gusanos, ataques de red, buffer

overflow, ataques de negación de servicio, ataques a claves, etc.), el objetivo del ataque (HW o SW),

la vulnerabilidad explotada y el payload. La taxonomía da lugar a una ontología que tiene como clase

principal la clase Attack, que alberga todo tipo de ataques informáticos. Cada ataque informático

concreto es una subclase de Attack. En los experimentos realizados por los autores muestran que la

aplicación de la ontología en un sistema de detección de intrusiones permite reducir de forma

considerable la tasa de falsos positivos y falsos negativos de los IDSs.

Herzog et al. [Herzog07] definen una ontología de seguridad genérica que trata de abarcar todos los

aspectos de la seguridad, proporcionando una visión general del dominio de la seguridad de la

información. Esta ontología proporciona un detallado vocabulario del dominio modelado y es capaz de

responder cualquier consulta específica de índole técnica sobre problemas y soluciones relativas a la

seguridad, además de soportar razonamiento sobre la información contenida en la ontología. La

ontología está especificada en OWL y su construcción se basa en los componentes clásicos del

análisis de riesgos: activos (clase Asset de la ontología), amenazas (clase Threat de la ontología),

vulnerabilidades (clase Vulnerability), contramedidas (clase Countermeasure), objetivos de seguridad

(clase Security Goal de la ontología) y estrategia de defensa (clase Defence Strategy). Los autores

proporcionan además, una descomposición de cada una de las clases en subclases, detallando

especialmente las clases Countermeasure, Asset y Threat; y especifican las relaciones existentes

entre todas las clases que conforman la ontología. El trabajo presentado es muy interesante para su

aplicación en el análisis de riesgos.

Además de la definición y especificación de ontologías de seguridad y su aplicación a diferentes

áreas de la seguridad en redes de telecomunicación como puede ser la detección de intrusiones,

existen trabajos de investigación cuyo objetivo es definir formalmente el comportamiento de sistemas


165

de detección, correlación y respuesta a intrusiones. Algunos de los trabajos más relevantes, se

resumen a continuación.

Wan Li y Tian Sheng Feng [Li08] proponen un sistema de correlación de alertas de intrusión basado

en ontologías. Los autores proponen una ontología de correlación de alertas y una arquitectura multi-

agente que utiliza la ontología definida para correlar alertas e información del estado de los sistemas

y la red, de una forma precisa y óptima. La arquitectura está compuesta por un conjunto de sensores

y agentes, donde los sensores recopilan información de seguridad relevante y los agentes procesan

dicha información. La arquitectura consta de dos sensores, State Sensor y Attack Sensor que

recogen información relativa al estado de la seguridad de los recursos de la red y de alertas de

intrusión, respectivamente. Ambos sensores envían la información recolectada a los agentes

correspondientes del centro de correlación de alertas (Local State Agent y Center State Agent en el

caso de información de estado, y Local Alert Agent y Center Alert Agent en el caso de alertas de

intrusión) cuya función es procesar la información recibida y almacenarla en la ontología. Este

proceso es distinto en ambos casos, y en el caso de las alertas de intrusión, el agente convierte la

alerta recibida a formato IDMEF para a continuación mapear la alerta IDMEF a sus conceptos

equivalentes en la ontología, definida en lenguaje OWL. Una vez los agentes han mapeado la

información relativa al estado y a las alertas de intrusión y dicha información está almacenada en la

ontología, el componente XSWRL Reasoner del módulo Attack Correlator, se encarga de razonar con

dicha información e inferir el ataque resultante de la correlación de alertas, que será utilizado para un

análisis de riesgos posterior. La ontología propuesta modela conceptos como Attack, Attacker, Asset,

System State, etc.

Por su parte, López de Vergara et al. [LópezDeVergara09] proponen una arquitectura basada en

ontologías para la instanciación de nuevas políticas de seguridad como respuesta a ataques de red

detectados. Su filosofía de funcionamiento es “Reaction after Detection”. La metodología propuesta

consiste en mapear las alertas de intrusión detectadas en contextos de ataque, que son utilizados

para identificar e inferir la política más adecuada a aplicar para mitigar la amenaza detectada. Para

ello, los autores especifican dos ontologías y tres conjuntos de reglas. Las ontologías modelan alertas

en formato IDMEF y políticas OrBAC (Organization Based Access Control). Los tres conjuntos de

reglas definidos son: reglas para inferir información de la jerarquía al modelo OrBAC, reglas para

gestionar el mapeo de alertas IDMEF a OrBAC, y reglas para inferir las políticas óptimas.

Por último, Azevedo et al. [Azevedo10] proponen un modelo autonómico para la detección de

intrusiones al que denominan AutoCore, constituido por un sistema multi-agente, una interfaz

inteligente y una ontología formal (CoreSec). El objetivo del modelo propuesto es hacer frente al

problema de la protección de los recursos informáticos, mediante la gestión de la seguridad

informática en entornos corporativos. El sistema propuesto asegura una comunicación segura entre

los distintos elementos del sistema, y el uso de ontologías hace posible la inferencia de medidas de

protección adecuadas frente a distintos tipos de eventos que pueden poner en riesgo la seguridad de

los sistemas de información.

Como se pone de manifiesto en la revisión del estado del arte, se concluye que hay gran cantidad de

trabajos de investigación interesantes relacionados con la definición y especificación de ontologías de

seguridad, así como propuestas de definición de comportamiento formal de diversos sistemas como

son los IDSs, sistemas de correlación de alertas, etc. No obstante, cada ontología modela un dominio

específico y es realmente difícil encontrar una ontología ya existente que cubra todos los aspectos

relacionados con el área de interés de esta tesis doctoral. Por ello, en este capítulo se propone una

nueva ontología de seguridad, que constituye un elemento clave del AIRS propuesto para el alcance

de su objetivo: inferir la respuesta óptima para reaccionar automáticamente frente a una intrusión

detectada en una red específica. Ninguna de las ontologías analizadas modela completamente el

proceso de respuesta a una intrusión, pero para la construcción de la ontología propuesta, es posible

reutilizar parcialmente algunos de los trabajos analizados, como se verá más adelante en este

capítulo.


166

En la siguiente sección se describe la ontología de respuesta a intrusiones detallando sus clases y

conceptos más relevantes.

5.4 Ontología de respuesta a intrusiones

Uno de los componentes principales de la arquitectura del AIRS propuesto en el capítulo anterior es

sin duda la ontología de respuesta a intrusiones. Esta ontología pretende modelar el proceso de

respuesta frente a una intrusión llevado a cabo por el AIRS instalado en una red informática, desde el

momento en que recibe una alerta de intrusión de cualquiera de las fuentes de detección presentes

en la red, principalmente IDSs, hasta que se actualiza el resultado de la acción de respuesta óptima

inferida.

Perfeccionar el modelado y clasificación de los ataques detectados así como de las respuestas a

desplegar en cada caso, contribuye a la mejora y optimización del sistema de respuesta, ya que

algunos AIRSs emplean muchas y variadas respuestas de forma aleatoria sin tener en cuenta que no

todas las respuestas son apropiadas para todas las intrusiones, reduciendo la eficacia del sistema.

Por ello, la eficacia y precisión del sistema propuesto depende de la calidad e integridad de la

ontología.

5.4.1 Metodología usada para la especificación de la ontología de

respuesta a intrusiones

No existe una metodología estándar que se deba seguir para el desarrollo de una ontología, ya que

depende del dominio a modelar y contexto en el que se construye, del comportamiento a especificar y

del enfoque del propio autor de la ontología. Como se indica en [GarciaPeñalvo05] y [Ohgren05]

existen multitud de propuestas de metodologías utilizadas para diseñar y construir ontologías. A

continuación se enumeran las más relevantes:

- Metodología utilizada para construir la ontología EO (Enterprise Ontology) ([Uschold95] y

[Uschold96a]): esta metodología es un esquema constituido por cuatro pasos, (1) Identificar el

propósito y el alcance de la ontología, (2) Construir la ontología (Capturar el conocimiento,

Codificar el conocimiento e Integrar el conocimiento), (3) Evaluar la ontología y (4)

Documentar la ontología. En cada uno de los pasos se consideran un conjunto de guías o

recomendaciones de diseño que se deber tener en cuenta en cada paso del método. Esta

metodología es la base de muchos de los métodos propuestos y usados en la actualidad.

- Metodología usada en el desarrollo de la ontología TOVE (TOronto Virtual Enterprise)

([Grüninger95] y [Grüninger96]): metodología utilizada para construir la ontología sobre

procesos de modelado de empresas, que consta de siete pasos, (1) Capturar escenarios

motivadores, (2) Formular preguntas de competencia informales, (3) Especificar la

terminología de la ontología, (4) Formular la lista de preguntas de competencia formalmente,

(5) Especificar axiomas y definiciones para los términos, (6) Evaluar la ontología y (7) Definir

las condiciones bajo las que las soluciones a las preguntas son completas.

- Metodología unificada propuesta por Uschold [Uschold96b]: método unificado que combina

los mejores pasos de las metodologías EO y TOVE. Consta de cuatro pasos, (1) Definir el

propósito u objetivo de la ontología, (2) Decidir el nivel de formalismo de la ontología, (3)

Definir conceptos y relaciones entre ellos y (4) Identificar términos formales del conjunto de

términos informales. En esta última fase, se evalúa o revisa el ciclo de diseño de la ontología,

donde la ontología se compara con los requisitos de los usuarios o empresas.

- Metodología propuesta por Sugumaran y Storey [Sugumaran02]: los autores proponen un

método basado en heurísticos para el desarrollo y la creación de ontologías. En primer lugar,

hay que (1) Identificar los términos básicos. A continuación, (2) Identificar las relaciones entre


167

los términos identificados, fase en la que los autores de la metodología especifican tres tipos

de relaciones, generalización (relación “is-a”), sinónimos y asociación. Además, en este

segundo paso, también se tienen en cuenta y analizan las relaciones entre ontologías, con el

fin de mejorar y enriquecer la ontología. El tercer paso consiste en (3) Identificar las

restricciones básicas, es decir, la relación entre términos y relaciones, como por ejemplo, “un

término o relación depende de otra”, “un término o relación debe ocurrir antes que otra”, etc.

Por último, (4) Definir restricciones de alto nivel, como restricciones de domino y

dependencias entre dominios.

- METHONTOLOGY ([Fernández-López97], [Fernández-López99] y [Gómez-Pérez96]):

metodología desarrollada por la UPM (Universidad Politécnica de Madrid), que permite la

construcción de ontologías a nivel de conocimiento, compuesta por siete pasos: (1)

Especificación del objetivo (especificar el dominio y alcance de la ontología y construir un

glosario de términos), (2) Conceptualización (construir taxonomías de conceptos y especificar

diagramas de relación), (3) Adquisición de conocimiento, (4) Integración (analizar otras

ontologías para su posible integración), (5) Implementación (construir la ontología en lenguaje

formal), (6) Evaluación y (7) Documentación.

- Metodología de la universidad de Stanford [Noy01]: guía para crear ontologías. Se compone

de siete pasos: (1) Determinar el dominio y alcance o ámbito de la ontología, (2) Considerar

reutilizar ontologías existentes, (3) Enumerar los términos importantes en la ontología, (4)

Definir las clases y la jerarquía de clases, (5) Definir las propiedades de las clases, (6) Definir

las características de las propiedades como cardinalidad, dominio y rango, y por último, (7)

Crear instancias de cada clase y rellenar sus propiedades.

- Metodología para el desarrollo de gestión de conocimiento basado en ontologías [Staab01]:

los autores proponen una metodología que consta de cinco fases, (1) Estudio de la viabilidad,

(2) Desarrollo preliminar de la ontología (especificación de requisitos, definición del objetivo

de la ontología, identificación de usuarios, aplicaciones que podrían utilizar la ontología, etc.),

(3) Refinamiento y desarrollo formal, (4) Evaluación, y (5) Mantenimiento y evolución.

En [Ohgren05], [Fernández-López99], [Jones98] y [Annamalai03] describen cada metodología con

mayor nivel de detalle.

Independientemente de la metodología utilizada, toda ontología debe cumplir una serie de requisitos y

propiedades [Gruber95]:

Debe ser clara y objetiva: se debe especificar de forma objetiva el significado del dominio que

representa.

Debe ser coherente y consistente: las inferencias generadas deben ser consistentes con las

definiciones propias de la ontología. Además, las definiciones de los axiomas deben ser

lógicamente consistentes.

Debe ser completa: la ontología debe contener las condiciones necesarias y suficientes para

su completa especificación, y no sólo las condiciones necesarias.

Debe ser extensible, es decir, soportar el uso de vocabulario compartido: debe permitir poder

añadir nuevos usos o axiomas a la ontología, sin que para ello haya que revisar las

definiciones existentes.

Debe cumplir el principio de distinción ontológica, es decir, sus clases deben ser disjuntas.

Debe tener modularidad: debe ser fácilmente separable en módulos independientes.

Debe seguir una estandarización en los atributos y propiedades en la medida de lo posible.

En el análisis y evaluación realizado por Ohgren [Ohgren05], concluyen que METHONTOLOGY es

una de las metodologías más maduras, ya que entre otras características, se describe con detalle

cada una de sus fases para su correcta comprensión y aplicación, cubre por completo el ciclo de vida


168

de desarrollo del SW (muy similar al de desarrollo de ontologías) y tienen en cuenta la posible

integración o reutilización de otras ontologías existentes.

Figura 5.1 METHONTOLOGY.

Por ello, en la construcción de la ontología de respuesta a intrusiones propuesta en este capítulo se

ha utilizado la metodología METHONTOLOGY, que como se especifica en esta sección, consta de

siete pasos (Figura 5.1):

1) Especificación del objetivo: en este primer paso se especifica el dominio a modelar, además

de la identificación del objetivo, alcance o propósito. Una vez identificado el domino, se

construye un glosario de términos, para lo que se identifican todos los conceptos incluidos en

el dominio modelado y que deben ser representados y sus características principales. En este

paso se obtienen los pares, (Object-Property).

2) Conceptualización: en este paso se construyen las jerarquías o taxonomías de conceptos,

mediante la organización y agrupación del conjunto de términos que comparten las mismas

propiedades. En el caso concreto de la ontología de respuestas a intrusiones, se construyen

dos taxonomías principales: una taxonomía de ataques y una taxonomía de respuestas, que

serán la base de la las clases principales de la ontología, como se verá más adelante.

Además, en este paso se especifican diagramas de relaciones entre los distintos objetos y

sus propiedades incluidos en el glosario de términos. Al final de esta fase, se obtienen las

tuplas (Objetc–Relation-Object)

3) Adquisición de conocimiento: este paso se lleva a cabo de forma independiente en la

metodología. Su ejecución puede coincidir con otros pasos. Por lo general la adquisición de

conocimiento se realiza en tres etapas: reuniones preliminares con los expertos, análisis y

revisión de la bibliografía asociada al dominio y, una vez que se tiene un conocimiento base,

se refina y detalla el conocimiento hasta completar la ontología.

4) Integración: en este paso se identifican las ontologías existentes para su posible reutilización

en la ontología en construcción, incorporando aquellas partes de conocimiento que sean de

utilidad.

5) Implementación: este paso es la construcción de la ontología en sí, es decir, la especificación

del modelo conceptual (objetos, relaciones indicando dominio y rango, propiedades indicando

cardinalidad y tipo de datos, jerarquía de clases, etc.) en lenguaje formal.

6) Evaluación: en este paso se realiza un juicio técnico de la ontología, evaluando si cumple los

siete requisitos especificados previamente, como por ejemplo, completitud, coherencia y

consistencia.

7) Documentación: paso final que consiste en detallar clara y exhaustivamente cada paso

completado y los productos generados.

En la sección 5.4.3 del presente capítulo se detallan cada uno de los pasos.


169

5.4.2 Herramientas utilizadas en la definición de la ontología de

respuesta a intrusiones

Como se indica en el Capítulo 3, existen gran diversidad de herramientas, aplicaciones y lenguajes

para la construcción y especificación de ontologías. Muchas de ellas son meramente académicas y

aún no gozan de suficiente madurez. En este apartado se definen de forma breve las utilizadas en

esta tesis doctoral.

OWL2

Tras el análisis realizado en 3.2, se concluye que los lenguajes más expresivos y utilizados en la Web

Semántica para describir formalmente conocimiento son OWL [Bechhofer04a] y OWL2

[OWL2W3C12]. A pesar de que la estructura de ambos lenguajes es muy similar, hay una serie de

ventajas de OWL2 sobre OWL, como se ha indicado previamente: OWL2 permite alcanzar mayor

nivel de expresividad que OWL (proporciona mayor soporte de tipos de datos, tiene mayor número de

axiomas, incluye restricciones de cardinalidad y propiedades de asimetría, reflexividad y disyunción,

etc.) y el número de razonadores semánticos que lo soportan es mayor.

Por ello, en la fase de implantación de la metodología (especificación formal de la jerarquía de clases,

propiedades, instancias, relaciones…) se ha utilizado OWL2, y la sintaxis RDF/XML.

No obstante, las ontologías definidas en OWL son totalmente compatibles con OWL2 por lo que el

uso de OWL también es válido para especificar la ontología propuesta.

Protégé

Protégé [Protégé] es un editor de ontologías libre y de código abierto, que proporciona herramientas

para la construcción de modelos de dominios y aplicaciones basadas en conocimiento mediante

ontologías. Protégé consta de un conjunto de estructuras que permiten crear, visualizar y manipular

ontologías definidas en varios formatos de representación, entre los que se encuentran RDFS, OWL y

OWL2 (soportado desde su versión 4.0).

Para modelar ontologías Protégé presenta dos opciones:

Editor Protégé-Frames: utilizado para construir ontologías que estén basadas en frames,

según lo establecido en el protocolo OKBC (Open Knowledge Base Connectivity). De acuerdo

a este modelo, una ontología consiste en un conjunto de clases organizadas jerárquicamente

que representan los conceptos más destacados de un dominio, un conjunto de parámetros

que describen las propiedades y relaciones de las clases y un conjunto de ejemplares o

instancias de las clases.

Editor Protégé-OWL: utilizado para desarrollar ontologías en OWL para la Web Semántica.

Una ontología definida en OWL debe incluir descripciones de clases, propiedades e

instancias. Este editor permite, entre otras funcionalidades, cargar y salvar ontologías OWL2,

OWL y RDF, editar y visualizar clases, propiedades y reglas SWRL gracias a la utilización de

plugins adicionales, definir características lógicas de clases como expresiones OWL, y

ejecutar razonadores como clasificadores de lógica descriptiva para evaluar la consistencia

de la ontología.

Protégé presenta una arquitectura flexible lo que facilita la configuración y extensión de la

herramienta mediante plugins que amplían su funcionalidad, como por ejemplo Jess, plugin de Pellet

para soportar la inferencia de SWRL, y plugins de visualización de ontologías como Ontograf y

Ontoviz.

Para la creación de la ontología propuesta se han utilizado las versiones 3.1 (en un principio) y 4.2 de

Protégé, además de plugins adicionales: OntoViz y Jess en la versión 3.1 y plugin de Pellet y

Ontograf en la versión 4.2.


170

Jess es un plugin que permite crear y ejecutar reglas SWRL soportado en versiones de Protégé

anteriores a la 4.0. La versión 4.2 incorpora un editor de reglas denominado SWRLRules, y no tiene

soporte del plugin de Jess. Por ello, en este último caso, se ha utilizado SWRLRules para la creación

de reglas y el plugin de Pellet para su ejecución e inferencia.

Jess 7.1

Jess [Jess] es un motor de reglas escrito en Java, soportado por Protégé en versiones anteriores a la

4.0 para definir y ejecutar reglas SWRL. Jess deriva del lenguaje de programación CLIPS, por lo que

es muy rápido y ligero. Además:

Permite acceder a todas las APIs de Java gracias a su potente lenguaje de definición de

scripts.

Es muy útil para desarrollar software Java con la capacidad de razonar usando conocimiento

expresado en forma de reglas.

Usa una versión del algoritmo Rete para procesar y evaluar reglas.

Puede manipular y razonar sobre objetos Java directamente. Además, Jess es un entorno

potente desde el que se pueden crear objetos Java, llamar a métodos Java e implementar

interfaces Java sin necesidad de compilar ningún código implementado en Java, además de

construir servlets u otras aplicaciones que usen conocimiento en forma de reglas declarativas

para extraer conclusiones o inferir conocimiento.

Jess ha sido utilizado para definir las políticas de especificación del comportamiento del sistema de

respuesta en SWRL y evaluar la ontología, probando la consistencia de la información definida y las

reglas. Mediante este plugin se ha comprobado que el sistema de respuesta a intrusiones basado en

ontologías propuesto infiere los resultados esperados.

Como se indica previamente, versiones de Protégé posteriores a la 4.0 no soportan el plugin Jess.

OntoViz

OntoViz [OntoViz] es un plugin para la visualización de ontologías en Protégé con la ayuda de un

sofisticado software de visualización gráfica llamado Graphviz [Graphviz].

Incluye distintas opciones de visualización, que el desarrollador podrá seleccionar en función de su

interés:

Visualización de clases e instancias que proporciona una visión parcial o total de la ontología.

Permite seleccionar las subclases de cada una de las clases.

Representación de las propiedades que caracterizan a las instancias o ejemplares de las

clases (slots).

Visualización de las relaciones entre clases.

Representación gráfica de los individuos o instancias de una clase.

Este plugin se ha utilizado para representar gráficamente las clases, propiedades y relaciones de la

ontología desarrollada. En el apartado correspondiente a la definición de clases y propiedades, dentro

de este capítulo, se incluye la jerarquía de clases, relaciones y propiedades de la ontología de

respuesta a intrusiones propuesta (Ver Figura 5.3 Ontología de Respuesta a Intrusiones).

OntoGraf

OntoGraf [OntoGraf] es un software de visualización y representación gráfica de ontologías OWL. A

partir de la versión 4.1 se incluye en la instalación por defecto de Protégé, por lo que no es necesario

instalar el plugin por separado.


171

Permite visualizar las clases y subclases de la ontología, y las relaciones existentes entre ellas, así

como una navegación interactiva. Pero no es posible visualizar las propiedades que caracterizan a las

instancias o ejemplares de las clases.

5.4.3 Especificación de la ontología de respuesta a intrusiones

Según METHONTOLOGY, metodología usada para la creación y desarrollo de la ontología, el

proceso de creación de una ontología consta de siete pasos, que a continuación se detallan.

5.4.3.1 Especificación del objetivo

El primer paso en el proceso de creación de la ontología es especificar el dominio en el que va a

aplicarse, identificando los elementos específicos del mismo, así como su alcance. En esta fase es

importante tener claro qué se quiere representar con la ontología, para qué se va a usar y quién la

usará y mantendrá.

En este caso, el dominio a modelar es la reacción automática frente a intrusiones detectadas en la

red de una organización o institución, siguiendo el proceso detallado en el Capítulo 4 de la presente

memoria. A grandes rasgos, el proceso es el siguiente:

Un atacante situado fuera o dentro de los dominios de la red de la institución, detecta la existencia

de una vulnerabilidad en un activo de la red. Aprovecha este hecho para explotar dicha

vulnerabilidad y lanzar un ataque que tiene como objetivo el componente cuya vulnerabilidad ha sido

detectada. Instantes después, uno de los IDSs de la red detecta que se ha producido un ataque en un

componente de la red, tras lo cual genera una alerta de intrusión donde se recogen las

características principales del ataque detectado y el estadío del mismo. Esta alerta es recibida por el

AIRS del sistema, que actuará en consecuencia lo más rápido posible para contrarrestar el impacto

que haya podido causar la intrusión, infiriendo la respuesta óptima para cada escenario de ataque.

Para ello, utiliza información acerca del estado del contexto del sistema y de la red en el instante de

intrusión, información contenida en la alerta de intrusión, e información relativa a las respuestas

existentes en el catálogo de respuestas del sistema, al que tiene acceso el AIRS. Una vez inferida

la respuesta óptima, el AIRS llamará a los componentes de la red encargados de ejecutarla,

denominados agentes ejecutores. Tras finalizar la ejecución de la respuesta, el AIRS evaluará el

éxito de la misma, tras lo que actualizará el nivel de eficiencia asociado a cada respuesta. Además,

se almacenará el resultado de la misma en el histórico de respuestas indicando la alerta de

intrusión a la que se ha hecho frente, la respuesta ejecutada, el tipo de respuesta y el resultado de la

misma.

Estos resultados y estadísticas de las respuestas ejecutadas son usados por el AIRS como

realimentación en acciones futuras, con el fin de optimizar el proceso de elección de la respuesta

adecuada tanto en tiempo como en recursos utilizados, o en entornos de respuesta colaborativos,

donde varios AIRSs utilizan información proporcionada por el resto para una detección y reacción

temprana.

De dicho proceso se extrae un conjunto de actores que derivan en términos clave del dominio

representado:

- Red: objeto que representa a la arquitectura de red de la organización.

- Activos de la arquitectura de red de una organización: los activos son aquellos elementos o

recursos presentes en la arquitectura de red susceptibles de ser atacados o comprometidos.

Se dividen a su vez en varios tipos: componentes del sistema o nodos, procesos, servicios,

ficheros y usuarios. Cada tipo de activo se caracteriza por un conjunto de propiedades, como

puede ser su dirección IP en el caso de un nodo, un identificador de usuario, un identificador

de proceso, etc. Una propiedad a destacar de los nodos, es su localización, o dirección.


172

- Vulnerabilidades: son los agujeros de seguridad presentes en los activos de red, que son

explotados por los atacantes para comprometer el activo.

- IDSs: los sistemas de detección de intrusiones son los encargados de detectar cualquier

comportamiento anómalo y enviar el informe de intrusión correspondiente al sistema de

respuesta. En el dominio modelado, la arquitectura consta de varios IDSs tanto a nivel de red

(NIDS) como de host (HIDS). Cada IDS se caracteriza por un identificador único, un modelo,

una versión, un tipo, etc.

- AIRS: el propio sistemas de respuesta a intrusiones basado en ontologías, es un actor clave

en el dominio. Por ello, debe ser representado en la ontología. En el dominio modelado, la

arquitectura consta únicamente de un AIRS, a diferencia del número ilimitado de IDSs. El

AIRS se caracteriza por un conjunto de propiedades, como por ejemplo, un identificador del

sistema, un modelo o el tipo de sistema operativo que utiliza.

- Contexto de red o de sistemas: toda arquitectura de red así como los sistemas presentes en

ella tienen un determinado contexto, útil para detectar comportamiento anómalo respecto a su

modo de funcionamiento habitual. Este contexto se caracteriza mediante distintos

indicadores, como por ejemplo, el número de procesos activos, número de procesos zombies,

latencia del sistema, carga de la red, etc. Esta información debe ser representada en la

ontología de respuesta a intrusiones.

- Alerta de intrusión: junto con el concepto de respuesta, la alerta que caracteriza a la intrusión

detectada es uno de los términos más relevantes del dominio modelado, puesto que de la

información contenida en cada alerta de intrusión dependerá la inferencia de la respuesta.

Cada alerta de intrusión enviada por uno de los IDSs al AIRS se caracteriza por un conjunto

de propiedades, como pueden ser: información sobre el activo atacado, el impacto y

severidad de la intrusión, el tipo de intrusión, la confianza en la veracidad de la alerta,

información sobre el origen de la alerta, etc.

- Acciones de respuesta: otro de los actores principales en el dominio modelado son las

propias acciones de respuesta que el AIRS llevará a cabo para mitigar la intrusión detectada.

Por ello, este concepto debe representarse en la ontología. Cada acción de respuesta se

caracteriza, entre otras cosas, por un tipo de respuesta (pasiva, proactiva, activa de

protección, activa de engaño, activa de recuperación o activa de reacción), un identificador,

una complejidad, un coste, una eficiencia y un impacto. Además, es importante tener

información sobre el agente de ejecutor encargado de desplegar la acción de respuesta, y si

está disponible en la arquitectura.

- Agente ejecutor: son los componentes o dispositivos encargados de ejecutar las acciones de

respuesta. Son así mismo activos de la red por lo que pueden ser comprometidos o atacados.

- Resultados: término empleado para representar cada inferencia del sistema, es decir, una vez

finalizada la ejecución de la respuesta y evaluado su éxito, se genera un log que incluye

información sobre la alerta de intrusión detectada, la respuesta inferida, el resultado de la

respuesta, y el momento de comienzo y fin de la inferencia. Esta información se almacena,

como se ha especificado previamente, en otra ontología denominada OntAIRSResults, cuyo

análisis no es el objetivo de este capítulo.

Como resultado de esta primera fase, se extrae un glosario de términos (alerta de intrusión,

respuesta, impacto de intrusión, contexto de sistemas, IDS, AIRS, servicio, proceso, activo, coste de

respuesta, red, etc.) y los pares Object-Property (Alerta de intrusión-Impacto, Alerta de intrusión-Tipo

de intrusión, Alerta intrusión-Identificador, Respuesta-Tipo de respuesta, Respuesta-Coste,

Respuesta-Severidad, etc.).


173

5.4.3.2 Conceptualización

La segunda fase consiste en la construcción de taxonomías de conceptos, para lo que se organizan y

agrupan los términos del glosario que comparten las mismas propiedades. Como principal resultado

de esta fase se construyen una taxonomía de ataques y una taxonomía de respuestas, que son la

base de las clases FormattedIntrusion y Response de la ontología de respuesta a intrusiones

respectivamente. Para la construcción de la taxonomía de respuestas se han tenido en cuenta las

taxonomías existentes previamente analizadas y estudiadas, y en el caso de la taxonomía de

ataques, esta se basa en IDMEF [IDMEF], un formato estándar para la representación e intercambio

de información de alertas de intrusión. El objetivo de IDMEF es definir el formato de datos y

mensajes, así como los procedimientos de intercambio para permitir la representación de alertas de

intrusión, y facilitar de esta forma el intercambio de los mismos entre diferentes sistemas de detección

y respuesta a intrusiones. Las recomendaciones del IETF sobre IDMEF aparecen recogidas en la

RFC 4765.

Además, en este paso se establecen las relaciones existentes entre los actores u objetos

identificados en la primera fase y como consecuencia se construyen las tuplas Object-Relation-

Object. A modo de ejemplo, en este paso del proceso de creación de la ontología de respuesta a

intrusiones, se obtienen las siguientes tuplas: Activo-tieneVulnerabilidad-Vulnerabilidad, Nodo-

tieneDirección-DireccionIP, Respuesta-protege-DimensiónSeguridad, IDS-genera-AlertaIntrusión,

AIRS-recibe-AlertaIntrusión, AlertaIntrusion-respuestaRecomendada-Respuesta, AlertaIntrusion-

respuestaÓptima-Respuesta, etc.

5.4.3.3 Adquisición de conocimiento

Este paso se ha llevado a cabo con anterioridad o en paralelo con los anteriores, ya que antes de

identificar los actores principales del dominio a modelar, realizar un glosario de términos y objetos, y

establecer propiedades y relaciones, se ha analizado y revisado la bibliografía pertinente en cuanto a

taxonomías de vulnerabilidades, ataques y respuestas existentes, clasificación de amenazas y

ataques informáticos, informes sobre tendencias de ataques como los elaborados por Symantec

[Symantec13], clasificación y tipos de acciones de respuesta, clasificación de recursos y activos

presentes en una arquitectura de red, etc.

Una vez analizada la información, se ha refinado, organizado y completado para poder desarrollar

una ontología completa, consistente y clara.

5.4.3.4 Integración

En este paso, tras analizar las ontologías existentes presentadas en este capítulo para su posible

reutilización en la ontología de respuesta a intrusiones, se tiene:

- Las clases Threat y SecurityGoal de la ontología propuesta por Herzog et al. [Herzog07], se

han reutilizado parcialmente.

- De la ontología IDMEF propuesta por López de Vergara et al. [LopezDeVergara09], se han

reutilizado las clases Target así como sus subclases, la clase Address, y la clase Analyzer a

la que se le han hecho pequeñas modificaciones. Esta ontología se basa en el formato

IDMEF y para su construcción se han seguido las siguientes reglas [DeFrutos09]:

Cada clase del mensaje IDMEF se corresponde con una clase de la ontología

IDMEF.

Cada atributo de una clase IDMEF se traduce en una propiedad de tipo DataType de

esa clase.

En general, las clases que representan información de otra clase se traducen en

propiedades de tipo Objecttype de esa clase. No obstante, en la RFC aparecen


174

descritas clases agregadas, que añaden contenido en formato texto, y que se han

traducido en la ontología como propiedades de tipo Datatype.

Una subclase de otra clase IDMEF se representa mediante subclases de la ontología,

heredando todas las propiedades de la superclase.

Las restricciones impuestas en IDMEF (cardinalidad, rango de valores permitidos,

tipo de datos…) se traducen en restricciones de OWL.

5.4.3.5 Implementación

Una vez identificados los principales objetos, propiedades y relaciones del dominio modelado y

especificados en lenguaje natural, el siguiente paso es la representación de este modelo conceptual

en lenguaje formal, OWL2 en este caso. Por tanto en esta fase se definen las clases, las subclases,

las propiedades de las clases especificando su cardinalidad y tipo de datos, y las relaciones indicando

su dominio y rango, en lenguaje OWL2.

Como se indicó en el Capítulo 3, una ontología contiene cinco elementos básicos: conceptos o

clases, ejemplares o individuos, propiedades, relaciones y axiomas. Para especificar el modelo

conceptual en lenguaje formal, tan sólo hay que establecer una equivalencia entre ambos modelos.

Para facilitar el proceso, se ha utilizado el editor de ontologías Protégé. La ontología de respuesta a

intrusiones propuesta se observa en la Figura 5.3 [Mateos13].

La ontología está formada por 12 clases principales que se corresponden con cada una de las

entidades independientes presentes en el dominio modelado. Las flechas azules de interconexión

indican la relación existente entre las diferentes clases. Las clases Asset, Context, Response,

SecurityGoal y Threat tienen subclases que no son representadas en la figura por motivos de

visualización. Por otra parte, cada una de las clases posee una serie de propiedades que caracterizan

y definen a los individuos o instancias de dichas clases.

En este apartado se incluye una breve descripción de cada una de las clases.

Network

Clase que representa la arquitectura de red de la institución u organización. La red está gestionada

por uno o varios administradores, compuesta por un número indefinido de componentes, entre los

que destacan los IDS y protegida por un IRS. Además tiene un contexto asociado al funcionamiento

de la misma en cada momento. Estas características se ponen de manifiesto en la ontología mediante

las propiedades de la clase Network.

Figura 5.2 Clase Network de la ontología de respuesta a intrusiones.

Todo ejemplar de la clase Network está caracterizado por las siguientes propiedades (DataType

Properties):

- installedNumberOfComponentes: Exactamente Uno. Número natural que representa el

número de componentes que forman parte de la arquitectura de la organización. Hay una

restricción de cardinalidad impuesta sobre esta propiedad (exactly 1), por lo que cada

instancia de la clase Network sólo puede tener un valor de esta propiedad.


175

Figura 5.3 Ontología de Respuesta a Intrusiones [Mateos13].


176

La clase tiene 5 relaciones con otras clases (Object Properties):

- hasAsset: Uno o más. Relación múltiple cuyo dominio es la clase Network y su rango

cualquier ejemplar de la clase Asset. Toda red puede tener uno o varios activos

pertenecientes a ella.

- hasContext: Cero o más. Relación múltiple de dominio Network y rango Context que indica

que toda red tiene un contexto asociado en un momento determinado.

- installedIDS: Uno o más. Relación múltiple que representa que una arquitectura de red cuenta

con uno o varios IDSs. Se impone una restricción sobre esta propiedad que indica que debe

haber al menos un IDS instalado en la red.

- managedBy: Cero o más. Usuario administrador de la red. Normalmente puede haber más de

un usuario con derechos de administración, por lo que no se impone restricción de

cardinalidad sobre esta propiedad.

- protectedBy: Exactamente Uno. Relación que representa que la red está protegida por un

único AIRS. El dominio de esta propiedad es la clase Network y su rango

AutomatedIntrusionResponseSystem.

Esta clase no presenta ninguna subclase.

Context

Clase utilizada para modelar los principales indicadores que describen el contexto en tiempo de

intrusión. Es posible distinguir entre dos tipos de contexto: el contexto de la red y el contexto del

sistema. El primero se refiere a los parámetros de tráfico, como la dirección IP de origen o el

protocolo. El segundo tipo de contexto está relacionado con los indicadores del nodo comprometido,

tales como, el número de procesos activos, uso de la CPU, etc. En la Figura 5.4 se observa la clase

Context, sus dos subclases y las propiedades y relaciones de cada una de ellas.

Figura 5.4 Clase Context de la ontología de respuesta a intrusiones.

Cada ejemplar de la clase correspondiente se caracteriza por las siguientes propiedades:

- contextInformationDate: Exactamente Uno. Atributo que especifica el momento en el que la

anomalía del contexto de red y de sistemas fue calculada. Todo ejemplar de la clase requiere

la especificación del instante en el que fue calculado.


177

- indicates: Cero o más. Relación múltiple cuyo dominio es la clase Context y su rango

cualquier instancia de la clase Threat, que representa la amenaza o tipo de ataque que refleja

la anomalía detectada en el contexto. Ciertos tipos de ataque producen variaciones drásticas

en el valor de los indicadores de los sistemas y la red con respecto a su valor cuando el

sistema se encuentra en un estado de funcionamiento normal. Esta variación se refleja

mediante el nivel de anomalía, en función del cual se puede determinar el tipo de amenaza.

En el caso de que el ataque producido no modifique los indicadores de contexto, esta

propiedad no tendrá ningún valor asignado.

- networkAnomaly: Cero o Uno. Atributo de tipo Integer que especifica la anomalía en el

contexto de red en un instante concreto.

- systemStatus: Cero o Uno. Atributo de tipo Integer que representa la anomalía en el estado

del componente comprometido en un instante concreto.

- systemActiveProcesses: Cero o Uno. Atributo de tipo Integer que representa la anomalía en

el número de procesos activos del componente comprometido en un instante concreto.

- systemZombieProcesses: Cero o uno. Atributo de tipo Integer que representa la anomalía en

el número de procesos zombies del componente comprometido en un instante concreto.

- systemNumberOfUsersLogged: Cero o Uno. Atributo de tipo Integer que representa la

anomalía en el número de usuarios del componente comprometido en un instante concreto.

- systemFreeSpace: Cero o Uno. Atributo de tipo Integer que representa la anomalía en el

espacio libre en disco del componente comprometido en un instante concreto.

- systemLatency: Cero o Uno. Atributo de tipo Integer que representa la anomalía en la latencia

del componente comprometido en un instante concreto.

- systemCPUUsage: Cero o Uno. Atributo de tipo Integer que representa la anomalía en el uso

de la CPU del componente comprometido en un instante concreto.

- systemSSHFailed: Cero o Uno. Atributo de tipo Integer que representa el número de intentos

de conexión mediante SSH fallidos en el componente comprometido en un instante concreto.

Asset

Clase que modela todos los activos o recursos presentes en la red (usuarios, equipos, ficheros,

servicios, etc.), que son necesarios para que la organización funcione correctamente. Los activos son

aquellos objetos susceptibles de ser atacados o comprometidos, y cuya integridad, confidencialidad,

disponibilidad y autenticidad hay que proteger.

La clase Asset tiene cinco subclases como se observan en la Figura 5.5: SystemComponent (o

Node), User, File, Service y Process. Como se indicó en la fase de integración, esta clase es

equivalente a la clase Target de la ontología IDMEF propuesta por López de Vergara et al.

[LopezDeVergara09], aunque se han realizado algunas modificaciones.

La clase Asset tiene cuatro propiedades:

- assetID: Exactamente Uno. Atributo de tipo String que define a un identificador único del

activo.

- assetLevelOfImportance: Exactamente Uno. Atributo que representa la importancia total del

activo para la organización, su criticidad. Esta propiedad puede ser un valor numérico de tipo

Integer o un valor de tipo String, caso en el que sólo puede adquirir uno de los siguientes

valores: Low, Medium o High.

- assetLevelOfImportance_authenticity: Exactamente Uno. Atributo que representa la

importancia del activo para la organización en su dimensión de autenticidad. Esta propiedad


178

puede ser un valor numérico de tipo Integer o un valor de tipo String, caso en el que sólo

puede adquirir uno de los siguientes valores: Low, Medium o High.

- assetLevelOfImportance_confidentiality: Exactamente Uno. Atributo que representa la

importancia del activo para la organización en su dimensión de confidencialidad. Esta

propiedad puede ser un valor numérico de tipo Integer o un valor de tipo String, caso en el

que sólo puede adquirir uno de los siguientes valores: Low, Medium o High.

- assetLevelOfImportance_availability: Exactamente Uno. Atributo que representa la

importancia del activo para la organización en su dimensión de disponibilidad. Esta propiedad

puede ser un valor numérico de tipo Integer o un valor de tipo String, caso en el que sólo

puede adquirir uno de los siguientes valores: Low, Medium o High.

- assetLevelOfImportante_integrity: Exactamente Uno. Atributo que representa la importancia

del activo para la organización en su dimensión de integridad. Esta propiedad puede ser un

valor numérico de tipo Integer o un valor de tipo String, caso en el que sólo puede adquirir

uno de los siguientes valores: Low, Medium o High.

- assetDescription: Cero o más. Atributo que especifica una descripción del activo. El

desarrollador puede proporcionar o no una descripción de cada activo.

- hasVulnerability: Cero o más. Relación de dominio Asset y rango Vulnerability, que

representa que todo activo puede contener ninguna, una o varias vulnerabilidades, que

pueden ser explotadas por distintas amenazas.

Figura 5.5 Clase Asset de la ontología de respuesta a intrusiones.

De las cinco clases en las que se clasifican los activos, se ha creído conveniente mostrar las

propiedades y relaciones de la clase SystemComponent (variación de la clase Node del formato

IDMEF que identifica a los hosts y otros dispositivos de la red como por ejemplo, routers o switches),

debido a su relevancia, puesto que tanto ficheros, como servicios y procesos residen en componentes

del sistema o equipos de la red. La mayoría de los equipos o componentes presentes en la

arquitectura de la red tienen una o varias direcciones, relación que se representa mediante la

propiedad hasAddress. Además de esta relación, cada instancia o ejemplar de la clase

SystemComponent queda definido por un identificador, un tipo, un nombre y una localización.


179

La clase Asset y sus subclases se basan en el formato IDMEF para la representación de alertas, en lo

referente a la clase Target.

Address

Clase que representa la dirección de red de un componente del sistema o la dirección mac. Cada

componente del sistema o nodo puede tener más de una dirección.

Figura 5.6 Clase Address de la ontología de respuesta a intrusiones.

Cada ejemplar de la clase se caracteriza por las siguientes propiedades:

- addressIP: Exactamente Uno. Atributo de tipo String que especifica la dirección (IP, MAC o

ATM) del componente o equipo. El formato de la dirección depende del tipo de dirección

especificado, en caso de que éste sea indicado. No obstante, la mayoría de las veces la

dirección se corresponde con la dirección IP del componente, de ahí el nombre de la

propiedad.

- addressNetmask: Cero o Uno. Atributo de tipo String que permite especificar la máscara de

red cuando proceda, es decir, cuando la dirección sea de tipo IP.

- addressID: Cero o Uno. Atributo de tipo String que representa un identificador único para la

dirección.

- addressType: Cero o Uno. Atributo de tipo String que representa el tipo de dirección. Una

dirección puede ser de tipo ATM, MAC, IPV4 en notación decimal, IPV4 en notación

hexadecimal, IPV6 en notación hexadecimal, etc. En caso de no proporcionar valor para esta

propiedad, el valor por defecto es IPV4 en notación decimal.

- addressVlanName: Cero o más. Atributo de tipo String que identifica el nombre de la VLAN a

la que pertenece la dirección.

- addressVlanNumber: Cero o más. Atributo de tipo Integer que identifica el número de la VLAN

a la que pertenece la dirección.

La clase Address y sus propiedades se basan en la clase Address del formato IDMEF para la

representación de alertas. Es equivalente a la clase Address de la ontología IDMEF propuesta en

[LopezDeVergara09].

Vulnerability

Clase que define cada vulnerabilidad presente en un activo de la red. Los atacantes explotan estas

vulnerabilidades para comprometer al activo. Un activo puede tener diferentes vulnerabilidades, así

como una misma vulnerabilidad puede estar presente en activos diferentes.


180

Figura 5.7 Clase Vulnerability de la ontología de respuesta a intrusiones.

La clase vulnerabilidad está definida mediante las siguientes propiedades:

- existsOnAsset: Cero o más. Relación que indica los activos que presentan una vulnerabilidad

específica. La vulnerabilidad puede no estar presente en ninguno de los activos o en todos.

- vulnerabilityName. Exactamente Uno. Atributo de tipo String que representa el nombre único

que identifica a la vulnerabilidad, proporcionado por la fuente de donde se extrae dicha

vulnerabilidad (cve o osvdb). Es equivalente a la propiedad referenceName de la clase

Reference.

- vulnerabilityID: Exactamente Uno. Atributo de tipo String que identifica a la vulnerabilidad en

la arquitectura de red de la organización.

- vulnerabilityDescription: Cero o más. Atributo de tipo String que proporciona una descripción

de la vulnerabilidad.

- hasReference: Cero o más. Relación que proporciona información sobre la vulnerabilidad,

como la fuente de donde se ha extraído, una url, etc. Cada vulnerabilidad puede tener varias

referencias.

Como se observa en la figura, la clase Vulnerability está relacionada con otra clase denominada

Reference, que modela cada una de las referencias asociadas a una vulnerabilidad. Cada ejemplar

de la clase Reference se caracteriza por:

- referenceOrigin: Cero o Uno. Atributo de tipo String que especifica el origen o fuente de la

vulnerabilidad. En el caso concreto del dominio modelado, el rango de esta propiedad se ha

restringido a dos valores: cve y osvdb.

- referenceURL: Exactamente Uno. Atributo de tipo String que representa la url donde se

puede encontrar información adicional sobre la vulnerabilidad.

- referenceName: Exactamente Uno. Atributo de tipo String que representa el nombre único

que identifica a la vulnerabilidad. Es equivalente a la propiedad vulnerabilityName de la clase

Vulnerability.

Las clases Vulnerability y Reference se basan en el estándar CVE (Common Vulnerability and

Exposures) [CVE] y en OSVDB (Open Sourced Vulnerability DataBase) [OSVDB]. Ambos

proporcionan listas de vulnerabilidades, siendo CVE un estándar para especificar vulnerabilidades de

seguridad en general, y OSVDB un listado de vulnerabilidades en bases de datos.


181

IntrusionDetectionSystem

Clase que modela a cada uno de los IDSs presentes en la arquitectura de red. Puede haber uno o

varios. Esta clase es similar a la clase Analyzer de la ontología IDMEF propuesta por

[LopezDeVergara09], que a su vez se basa en la clase Analyzer de IDMEF. Las propiedades de la

clase también son equivalentes a los atributos descritos en la RFC, a excepción de IDSconfidence,

que ha sido añadido en la ontología de respuesta a intrusiones.

Figura 5.8 Clase IntrusionDetectionSystem de la ontología de respuesta a intrusiones.

Como se observa en la figura, estas propiedades son:

- IDSID: Exactamente Uno. Atributo de tipo String que indica el identificador único del IDS.

- IDSname: Cero o Uno. Atributo de tipo String que indica el nombre con el que se identifica al

IDS en la arquitectura.

- IDSconfidence: Cero o Uno. Atributo de tipo Double que representa la confianza expresada

en % que se tiene en la fuente de detección, para lo que se analiza su tasa de falsos positivos

y negativos.

- IDSclass: Cero o Uno. Atributo de tipo String que indica el tipo de IDS (NIDS o HIDS).

- IDSmanufacturer: Cero o Uno. Atributo de tipo String que indica el nombre del fabricante o

desarrollador del IDS.

- IDSmodel: Cero o Uno. Atributo de tipo String que representa el modelo del IDS.

- IDSversion: Cero o Uno. Atributo de tipo String que indica la versión del IDS.

- IDSOSversion: Cero o más. Atributo de tipo String que representa la versión del sistema

operativo que soporta esa versión del IDS.

- IDSOStype: Cero o más. Atributo de tipo String que representa el tipo de SO que soporta la

versión del IDS.

- hasNodeLocation: Cero o Uno. Relación que indica que toda instancia de la clase

IntrusionDetectionSystem debe estar alojado en un nodo o componente del sistema.

- generates: Cero o más. Relación de domino InstrusionDetectionSystem y rango

FormattedIntrusion, que representa que un IDS puede generar una, ninguna o muchas alertas

de intrusión, que son enviadas al AIRS.


182

AutomatedIntrusionResponseSystem

Clase que modela el AIRS que protege la red. Como se indicó anteriormente, la red consta de un

único AIRS que recibe alertas de intrusión (representado mediante la relación

receivedFormattedIntrusion) e infiere respuestas óptimas y recomendadas.

Figura 5.9 Clase AutomatedIntrusionResponseSystem de la ontología de respuesta a intrusiones.

Como se observa en la figura, las propiedades y relaciones que definen formalmente a la clase son:

- AIRSID: Exactamente Uno. Atributo de tipo String que indica el identificador único del AIRS.

- AIRSname: Cero o Uno. Atributo de tipo String que indica el nombre con el que se identifica al

AIRS en la arquitectura.

- AIRSclass: Cero o Uno. Atributo de tipo String que indica el tipo de AIRS.

- AIRSmanufacturer: Cero o Uno. Atributo de tipo String que indica el nombre del fabricante o

desarrollador del AIRS.

- AIRSmodel: Cero o Uno. Atributo de tipo String que representa el modelo del AIRS.

- AIRSversion: Cero o Uno. Atributo de tipo String que indica la versión del AIRS.

- AIRSOSversion: Cero o más. Atributo de tipo String que representa la versión del sistema

operativo que soporta esa versión del AIRS.

- AIRSOStype: Cero o más. Atributo de tipo String que representa el tipo de SO que soporta la

versión del AIRS.

- AIRSnumberOfResponses: Exactamente Uno. Atributo de tipo Integer que indica el número

de respuestas que ha ejecutado el sistema de respuesta.

- maximumResponseComplexity: Cero o más. Atributo de tipo Integer que indica la complejidad

máxima permitida en una respuesta para ser ejecutada por el sistema de respuesta. El AIRS

descartará cualquier respuesta cuya complejidad supere este valor.

- numberOfGeneratedResult: Cero o más. Atributo de tipo Integer que representa el número de

respuestas que ha ejecutado el sistema y su resultado ha sido almacenado.


183

- hasNodeLocation: Cero o Uno. Relación que indica que toda instancia de la clase

AutomatedIntrusionResponseSystem debe estar alojado en un nodo o componente del

sistema.

- receivedFormattedIntrusion: Cero o más. Relación de domino

AutomatedInstrusionResponseSystem y rango FormattedIntrusion, que representa que un

AIRS puede recibir una, ninguna o muchas alertas de intrusión, que son generadas por uno

de los IDSs de la red.

FormattedIntrusion

Clase utilizada para representar las alertas de intrusión generadas por los IDSs y recibidas por el

AIRS. Es la clase principal de la ontología junto con las clases Threat y Response. Cada ejemplar de

la clase incluye información sobre el tipo de intrusión detectada, origen del ataque, impacto de la

intrusión, consecuencia, activo objetivo del ataque, etc.

Esta clase se basa en la clase Alert de IDMEF, que pretende estandarizar el formato en la

representación de alertas de intrusión, y en la que se basa la ontología IDMEF presentada en

[LopezDeVergara09]. No obstante, la clase FormattedIntrusion no es totalmente equivalente a la

clase Alert, sino que se han eliminado o modificado ciertas clases y propiedades, y añadido otras

propiedades y relaciones nuevas, con el fin de adaptar la ontología de respuesta a intrusiones al

dominio modelado.

Figura 5.10 Clase FormattedIntrusion de la ontología de respuesta a intrusiones.

En Figura 5.10 se observan los principales atributos o DatatypeProperties y relaciones o

ObjectProperties de la clase:

- intrusionAlertReliability: Exactamente Uno. Atributo de tipo String que indica la confianza en la

alerta de intrusión, es decir, cuánta de certeza existe en que el tipo de intrusión detectada es

real. Esta propiedad tiene una restricción de valor, ya que sólo puede ser high, medium o low.


184

- intrusionImpact: Exactamente Uno. Atributo de tipo Integer cuyo valor representa el impacto

causado por la intrusión en la organización.

- intrusionSeverity: Exactamente Uno. Atributo de tipo Integer cuyo valor representa la

severidad asociada al ataque detectado. Este valor es impuesto por la fuente de detección.

- portSrc: Cero o más. Atributo de tipo Integer que indica el puerto o puertos origen del ataque.

- portDest: Cero o más. Atributo de tipo Integer que representa el puerto o puertos destino del

ataque.

- intrusionID: Exactamente Uno. Atributo de tipo String que identifica a la alerta de intrusión.

- numberOfRecommendedResponses: Cero o Uno. Atributo de tipo Integer que representa el

número de respuestas recomendadas por el AIRS para mitigar la intrusión. Cada alerta de

intrusión tiene solamente un valor asociado a esta propiedad.

- isARepeatedFormattedIntrusion: Atributo de tipo Boolean que indica si la alerta de intrusión

es la misma que otra ya almacenada. Esta propiedad es útil para distinguir entre alertas

iguales procedentes de diferentes IDSs con diferentes formatos. Si es true significa que la

alerta es igual que otra ya detectada (en un tiempo inferior a t) y por tanto no es necesario

inferir respuesta puesto que la intrusión detectada es la misma.

- responseStatus: Cero o Uno. Atributo de tipo String cuyo valor indica si la alerta de intrusión

ya ha sido procesada y mitigada o es una alerta nueva.

- realIntrusionImpact: Exactamente Uno. Atributo de tipo Double o Float cuyo valor representa

el impacto real de la intrusión calculado como el producto de su impacto y la confianza en el

IDS y la propia alerta.

- intrusionDescription: Cero o más. Atributo de tipo String que describe la alerta de intrusión.

- hasTarget: Uno o más. Relación de rango Asset, que representa el activo o activos que son

objetivo del ataque.

- recommendedResponses: Cero o más. Relación de rango Response que representa las

respuestas recomendadas asociadas a una instancia de alerta de intrusión.

- continuatedBy: Cero o más. Relación de rango FormattedIntrusion que representa la intrusión

que sigue a la instancia tratada, en caso de existir. El objetivo de esta relación es la respuesta

temprana ante ataques, y poder reaccionar de forma proactiva.

- recommendedProactiveResponses: Cero o más. Relación de rango Proactive que representa

las respuestas recomendadas proactivas asociadas a una instancia de alerta de intrusión.

- exploits: Cero o más. Relación de rango Vulnerability que representa la vulnerabilidad o

vulnerabilidad que explota la intrusión detectada.

- optimumProactiveResponse: Cero o más. Relación de rango Response que representa las

respuestas óptimas asociadas a un ejemplar de alerta de intrusión.

- optimumResponse: Cero o más. Relación de rango Proactive que representa las respuestas

óptimas proactivas asociadas a un ejemplar de alerta de intrusión.

- isGeneratedBy: Exactamente Uno. Relación de rango IntrusionDetectionSystem que asocia

cada ejemplar de alerta intrusión con un IDS, que fue el que detecta la intrusión. Cada alerta

de intrusión individual es generada por una única fuente.

- hasIntrusionType: Exactamente Uno. Relación de rango Threat que indica la amenaza o tipo

de ataque asociado a la intrusión. Un ejemplar de FormattedIntrusion posee sólo un tipo de

amenaza asociado.


185

Por su relevancia, en la Figura 5.11 se muestran las relaciones que tiene la clase FormattedIntrusion

con el resto de clases de la ontología.

Figura 5.11 Ontología de Respuesta a Intrusiones. Relaciones de clase FormattedIntrusion.

Threat

Clase que modela el tipo de intrusión o de amenaza. Cada ejemplar de la clase FormattedIntrusion

tiene asociado un tipo específico de intrusión, que como se vio en la clase anterior se representa

mediante la relación hasIntrusionType. Como se observa en la Figura 5.12, la clase Threat sólo posee

una propiedad, threatens, que especifica la meta o dimensión de seguridad a la que amenaza la

intrusión.

Figura 5.12 Propiedades de la clase Threat.

En la figura también se puede observar que la subclase SomeThreat se caracteriza por dos

propiedades:

- successThresholdLow: Cero o Uno. Atributo de tipo Float o Double cuyo dominio es cualquier

subclase de la clase SomeThreat y cuyo rango es un número decimal (float o double)

comprendido entre -1.00 y 1.00. Este atributo representa el umbral de éxito bajo para un tipo

de intrusión determinado obtenido durante la fase de entrenamiento del sistema de

evaluación, como se explicará en el Capítulo 7 de la presente memoria (Ver 7.4.1.2).

- successThresholdHigh: Cero o Uno. Atributo de tipo Float o Double cuyo dominio es cualquier

subclase de la clase SomeThreat y cuyo rango es un número decimal (float o double)

comprendido entre -1.00 y 1.00. Este atributo representa el umbral de éxito superior para un

tipo de intrusión determinado obtenido durante la fase de entrenamiento del sistema de

evaluación, como se explicará en el Capítulo 7 de la presente memoria (Ver 7.4.1.2).

En contrapartida a la escasez de propiedades, la clase Threat se descompone en muchas subclases.

Para la creación y definición de la clase y la clasificación de las distintas amenazas en subclases, se

han analizado de forma exhaustiva las taxonomías de ataque existentes, en especial su dimensión de

Vector de Ataque, además de las ontologías de seguridad, las clasificaciones de amenazas y ataques

informáticos realizadas por expertos, y los informes sobre tendencias de ataques como los

elaborados por Symantec [Symantec13]. Tras el análisis, se ha decidido reutilizar la clase Threat de

la ontología propuesta por Herzog et al. [Herzog07], sobre la que se han realizado pequeñas

modificaciones. La Figura 5.13 muestra las subclases de la clase Threat, a la que ha dado lugar una

clasificación o taxonomía de amenazas previa.


186

Figura 5.13 Clase Threat de la ontología de respuesta a intrusiones.

SecurityGoal

Clase que especifica la política o dimensión de seguridad de un activo afectada por la intrusión:

confidencialidad, integridad, disponibilidad o autenticidad.

Figura 5.14 Clase SecurityGoal de la ontología de respuesta a intrusiones.

Para la creación de la clase se ha reutilizado la clase SecurityGoal de la ontología propuesta por

Herzog et al. [Herzog07], a la que se ha añadido la dimensión de autenticidad.


187

Como se observa en la figura, la relación de esta clase con otras entidades de la ontología consiste

en que cualquier ejemplar de la clase Threat amenaza una o varias dimensiones de seguridad, y todo

ejemplar de la clase Response tiene como objetivo entre otras cosas, proteger uno o varios requisitos

de seguridad.

Response

Clase que modela las acciones de respuesta que el AIRS puede inferir y ejecutar, es decir, las

reacciones incluidas en el catálogo de respuestas del sistema. Es una de las clases más relevantes

de la ontología, y sus propiedades tienen el objetivo de definir completamente cualquier acción de

respuestas, sin olvidar rasgos como: coste de la respuesta, complejidad, severidad, etc. El valor de

estas propiedades es crucial en el proceso de elección de la respuesta óptima.

Esta clase se basa en la taxonomía de respuestas diseñada en la fase de conceptualización, para lo

que como ya se indicó, se han analizado y evaluado las taxonomías de respuesta existentes, en

especial la 5W2H [Wang-H06].

Figura 5.15 Clase Response de la ontología de respuesta a intrusiones.

Las propiedades y relaciones que definen la clase son:

- responseSeverity: Exactamente Uno. Atributo de tipo Integer que representa la severidad

asociada a la respuesta.

- responseDescription: Cero o más. Atributo de tipo String que describe la acción de respuesta.

- responseAction: Exactamente Uno. Atributo de tipo String que india la acción de respuesta en

sí. Es un identificador de la respuesta utilizado entre otros sistemas por el ejecutor de

respuesta.

- responsePriority: Cero o más. Atributo de tipo Integer que representa la prioridad de la

respuesta en caso de respuesta múltiple.


188

- responseID: Exactamente Uno. Atributo de tipo String que identifica a la respuesta en el

catálogo de acciones.

- responseName: Cero o más. Atributo de tipo String que representa el nombre con el que se

conoce a la respuesta en el catálogo. No es un identificador de la respuesta.

- responseImpact: Exactamente Uno. Atributo de tipo Integer cuyo valor representa el impacto

de la respuesta en los activos del sistema, el efecto negativo de la acción de respuesta.

- responseComplexity: Exactamente Uno. Atributo de tipo Integer cuyo valor indica la

complejidad de desplegar la respuesta.

- responseCost: Exactamente Uno. Atributo de tipo Integer que representa el coste total

relacionado con el despliegue de la respuesta. El coste asociado al despliegue de una

respuesta se mide en términos de recursos consumidos y del impacto de la respuesta en los

activos de la red.

- responseDeploymentCost: Exactamente Uno. Atributo de tipo Integer que representa el coste

total relacionado con el despliegue de la respuesta, en términos del consumo de recursos.

- responseEfficiency: Exactamente Uno. Atributo de tipo Double cuyo valor se corresponde con

la eficiencia o éxito de la respuesta en anteriores ejecuciones.

- numExecutions: Exactamente Uno. Atributo de tipo Integer que indica el número de veces

que la respuesta ha sido ejecutada desde el principio de funcionamiento del AIRS.

- availableRangeOfComponents: Cero o Uno. Atributo de tipo Integer que representa el número

de componentes o dispositivos de seguridad necesarios para ejecutar la respuesta que están

disponibles. Si una respuesta no necesita ningún dispositivo de seguridad para hacerse

efectiva, esta propiedad no tendrá valor asociado.

- neededRangeOfComponents: Cero o Uno. Atributo de tipo Integer que representa el número

de componentes necesarios para ejecutar la respuesta. Si una respuesta no necesita ningún

dispositivo de seguridad para hacerse efectiva, esta propiedad no tendrá valor asociado.

- hasResponseDependency: Cero o más. Relación cuyo dominio y rango es la clase Response,

que refleja la posible dependencia de una respuesta con otras, es decir, si una respuesta no

puede ser ejecutada si se ejecuta otra, o si otra no ha sido ejecutada previamente.

- neededSystemComponents: Cero o más. Relación cuyo dominio es la clase Response y su

rango la clase ResponseSystemComponents, que representa los dispositivos de seguridad

necesarios para que la respuesta pueda ejecutarse.

- protects: Cero o más. Relación que indica qué dimensión (Integridad, disponibilidad,

confidencialidad o autenticidad) de seguridad de un activo protege la respuesta. Una reacción

puede proteger, una, ninguna o varios requisitos de seguridad.

- orientedTo: Cero o más. Relación que representa la amenaza o amenazas sobre las que la

acción de respuesta está orientada, es decir, aquellas amenazas que puede mitigar la acción

de respuesta.

Por otra parte, en el Capítulo 4 (Ver 4.4.4) se especifican los tipos en los que se puede clasificar una

acción de respuesta: Pasiva, Proactiva y Activa, y dentro de esta última categoría, una respuesta

puede ser de Engaño, de Protección, de Reacción o de Recuperación. Esta clasificación o taxonomía

de las acciones de respuesta da lugar a las diferentes subclases de la clase Response en la

ontología. En la siguiente figura se observan dichas subclases y las relaciones que asocian la clase

Response con el resto de clases de la ontología.


189

Figura 5.16 Ontología de Respuesta a Intrusiones. Relaciones de clase Response.

ResponseSystemComponents o SecurityDevice

Clase también denominada SecurityDevice que permite representar los componentes de respuesta o

dispositivos de seguridad responsables de desplegar las respuestas. Si los componentes que

necesita una respuesta no están disponibles, tanto en tipo de dispositivo como en número, el AIRS no

ejecutará la respuesta.

Figura 5.17 Clase ResponseSystemComponents de la ontología de respuesta a intrusiones.

Cada ejemplar de esta clase se caracteriza por las siguientes propiedades y relaciones:

- componentType: Exactamente 1. Atributo de tipo String que indica el tipo de dispositivo de

seguridad (router, cortafuego, servidor web, servidor FTP, gestor de usuarios, etc.).

- securityDeviceDescription: Cero o más. Atributo de tipo String que describe al tipo de

componente de respuesta.

- isSecurityDeviceAvailable: Exactamente 1. Atributo de tipo Boolean que indica si el dispositivo

se encuentra disponible o no.

- hasNodeLocation: Cero o Uno. Relación de dominio ResponseSystemComponents y rango

SystemComponent, que indica la localización del componente de respuesta.

5.4.3.6 Evaluación

Una vez especificado el modelo conceptual en lenguaje formal, la siguiente fase consiste en evaluar

si la ontología cumple los requisitos definidos en 5.4.1, como son consistencia y coherencia. Para

evaluar ambas propiedades se han utilizado los plug-ins disponibles en Protégé, como por ejemplo, el

plugin de Pellet que comprueba la consistencia de la ontología o la insatisfiabilidad de las clases y

propiedades. Los resultados obtenidos han sido satisfactorios.


190

5.4.3.7 Documentación

El paso final consiste en detallar de forma clara y exhaustiva cada paso en la creación y desarrollo de

la ontología.

5.4.4 Especificación de restricciones y condiciones en la

ontología de respuesta a intrusiones mediante axiomas de

OWL2

Los axiomas permiten expresar restricciones o reglas sobre la información modelada. Estos pueden

ser de varias clases: axiomas de subclases, axiomas de equivalencia de clases, axiomas de igualdad

o desigualdad de ejemplares, intersección o unión de clases, restricciones sobre propiedades,

axiomas de cardinalidad, etc.

Como se pone de manifiesto en la descripción de la fase de implementación de la ontología de

respuesta a intrusiones, para la especificación de la misma se han utilizado diferentes tipos de

axiomas: axiomas de subclases, axiomas de restricciones sobre propiedades, axiomas de

cardinalidad, axiomas de equivalencia de clases y axiomas de disyunción de clases. En este apartado

se presentan, a modo de ejemplo, algunos de los axiomas utilizados expresados en sintaxis RDF.

Axiomas de subclase:

Tipo de axioma que permite expresar que la clase C1 es subclase de C2. En el ejemplo se indica que

la clase BackDoors es subclase de SpecificThreat. Todas las subclases incluidas en la ontología se

expresan de la misma forma.

<owl:Class rdf:resource="http://www.org.com/ontAIRS.owl#BackDoors">

<rdfs:subClassOf

rdf:resource="http://www.org.com/ontAIRS.owl#SpecificThreat"/>

</owl:Class>

Axiomas de equivalencia de clases:

Tipo de axioma que permite expresar la equivalencia entre clases. En el caso de la ontología de

respuesta a intrusiones, un ejemplo de clase equivalente es HighReliabilityFI, clase que es

equivalente a la intersección de la clase FormattedIntrusion y a que la propiedad

intrusionAlertReliability tenga como valor asociado “high”. Es decir, todo ejemplar de la clase

FormattedIntrusion cuyo valor de intrusionAlertReliability sea “high”, es un ejemplar de la clase

HighReliabilityFi.

<owl:Class

rdf:about="http://www.org.com/ontAIRS.owl#HighReliabilityFI">

<owl:equivalentClass>

<owl:Class>

<owl:intersectionOf rdf:parseType="Collection">

<rdf:Description

rdf:about="http://www.org.com/ontAIRS.owl#FormattedIntrusion"/>

<owl:Restriction>

<owl:onProperty

rdf:resource="http://www.org.com/ontAIRS.owl#intrusionAlertReliability"/>

<owl:hasValue>high</owl:hasValue>

</owl:Restriction>

</owl:intersectionOf>

</owl:Class>

</owl:equivalentClass>

<rdfs:subClassOf

rdf:resource="http://www.org.com/ontAIRS.owl#FormattedIntrusion"/>

</owl:Class>


191

Axiomas de disyunción de clases:

Tipo de axioma que permite expresar la disyunción entre clases. En el caso de la ontología de

respuesta a intrusiones, un ejemplo de clases disjuntas son NotThreat y SomeThreat. Es decir, un

ejemplar de la clase NotThreat no puede ser ejemplar de la clase SomeThreat, o pertenece a una

clase o a la otra. El axioma de disyunción expresado en sintaxis RDF es de la siguiente forma:

<owl:Class rdf:about="http://www.org.com/ontAIRS.owl#NotThreat">

<rdfs:subClassOf

rdf:resource="http://www.org.com/ontAIRS.owl#Threat"/>

<owl:disjointWith

rdf:resource="http://www.org.com/ontAIRS.owl#SomeThreat"/>

</owl:Class>

Axiomas de cardinalidad:

El axioma que a continuación se incluye impone una restricción de cardinalidad a la propiedad

assetLevelOfImportance, indicando que cada instancia de la clase que posea esta propiedad, debe

tener un único valor asociado a la propiedad. Esta condición se indica mediante la restricción

qualifiedCardinality. Además, se impone otra restricción respecto al tipo de datos permitido en el

rango de la propiedad, en este caso, xsd:string.

<owl:Restriction>

<owl:onProperty

rdf:resource="http://www.org.com/ontAIRS.owl#assetLevelOfImportance"/>

<owl:qualifiedCardinality

rdf:datatype="&xsd;nonNegativeInteger">1</owl:qualifiedCardinality>

<owl:onDataRange rdf:resource="&xsd;string"/>

</owl:Restriction>

OWL2 incluye bastantes restricciones de cardinalidad: universal (allValuesFrom), existencial

(someValulesFrom), valor concreto (hasValue), cardinalidad exacta (cardinality), cardinalidad exacta

cualificada (qualifiedCardinality), cardinalidad máxima (maxCardinality), cardinalidad máxima

cualificada (maxQualifiedCardinality), cardinalidad mínima (minCardinality) y cardinalidad mínima

cualificada (minQualifiedCardinality). Estas restricciones permiten dotar de mayor expresividad al

lenguaje.

En la ontología de respuesta a intrusiones están presentes la mayoría de los tipos de restricciones de

cardinalidad, como se indica al definir cada una de las clases de la ontología en el apartado anterior.

Axiomas de restricciones sobre relaciones entre clases (Object Properties):

Tipos de axiomas que imponen restricciones a las propiedades, como por ejemplo, de simetría, de

asimetría, de reflexividad etc. Una relación entre clases puede tener las siguientes características:

Functional, Inverse Functional, Transitive, Symmetric, Asymmetric, Reflexive e Irreflexive. Estas

características se expresan por medio de axiomas, como por ejemplo:

<owl:ObjectProperty

rdf:about="http://www.org.com/ontAIRS.owl#hasIntrusionType">

<rdf:type rdf:resource="&owl;FunctionalProperty"/>

<rdfs:domain

rdf:resource="http://www.org.com/ontAIRS.owl#FormattedIntrusion"/>

<rdfs:range rdf:resource="http://www.org.com/ontAIRS.owl#Threat"/>

</owl:ObjectProperty>

Mediante la expresión anterior se indica que la propiedad hasIntrusionType tiene la característica de

ser Funcional, es decir, todo ejemplar perteneciente al dominio de la propiedad sólo puede tener

asociado un ejemplar perteneciente al rango de la misma, y si posee más de uno implica que ambos

individuos o ejemplares son el mismo. En este caso, cualquier alerta de intrusión tiene sólo una

amenaza asociada, y en caso de haber dos la amenaza es la misma.

De igual forma se especifican el resto de características de las propiedades.


192

Además de los ejemplos mostrados, el dominio y rango de todas las propiedades (tanto relaciones

entre clases como atributos de clase) se especifica mediante axiomas (P rdfs:domain D o P rdfs:range

R).

El lenguaje OWL2 es rico en axiomas [OWL2W3C09] y amplía el conjunto de axiomas y restricciones

de OWL, lo que permiten expresar ciertas reglas o restricciones. Pero la expresividad del lenguaje

sigue siendo insuficiente, por lo que se hace necesario el uso de lenguajes de reglas o políticas como

SWRL.


Esta sección ha tratado de describir y especificar una ontología de respuesta a intrusiones para su

inclusión en la arquitectura del AIRS basado en ontologías propuesto en el Capítulo 4.

Para ello, en primer lugar se han analizado las diferentes metodologías existentes para desarrollar y

crear ontologías, ya que no existe una metodología estándar, sino que el uso de una u otra depende

del dominio a modelar y contexto en el que se construyen, del comportamiento a especificar y del

enfoque del propio autor de la ontología. La metodología elegida y utilizada para desarrollar la

ontología ha sido METHONTOLOGY ([Fernández-López97], [Fernández-López99] y [Gómez-

Pérez96]), compuesta por siete pasos: (1) Especificación del objetivo (especificar el dominio y

alcance de la ontología y construir un glosario de términos), (2) Conceptualización (construir

taxonomías de conceptos y especificar diagramas de relación), (3) Adquisición de conocimiento, (4)

Integración (analizar otras ontologías para su posible integración), (5) Implementación (construir la

ontología en lenguaje formal), (6) Evaluación y (7) Documentación.

Además, como se indica en el Capítulo 3, existen gran diversidad de herramientas, aplicaciones y

lenguajes para la construcción y especificación de ontologías. Muchas de ellas son meramente

académicas y aún no gozan de suficiente madurez. En esta sección se incluyen las utilizadas para la

creación de la ontología propuesta en esta tesis doctoral: OWL2, Protégé, Jess 7.1, OntoViz y

Ontograf.

Por último, la sección detalla de forma exhaustiva cada paso de la metodología en la creación de la

ontología de respuesta a intrusiones, especificando las clases, las propiedades y las relaciones que la

componen. Además, se presentan algunos de los axiomas utilizados en la ontología expresados en

sintaxis RDF, que permiten especificar restricciones y condiciones.

5.5 Conclusiones

El presente capítulo ha presentado una propuesta de ontología de respuesta a intrusiones para su

integración en la arquitectura del AIRS como parte principal de la misma. Para ello, se ha expuesto

una primera sección que estudia y analiza algunas de las taxonomías y ontologías de seguridad

existentes para su posible utilización como ontología de respuesta a intrusiones en el AIRS. Tras el

análisis, ha quedado patente la necesidad de especificar una nueva ontología, ya que ninguna de las

evaluadas modela completamente el dominio de interés. Por ello, en la segunda sección se incluye la

especificación de la ontología de respuesta a intrusiones propuesta.

La ontología modela el proceso de respuesta frente a una intrusión llevado a cabo por el AIRS

instalado en una red informática, desde el momento en que recibe una alerta de intrusión de

cualquiera de las fuentes de detección, principalmente IDSs, presentes en la red, hasta que se

actualiza el resultado de la acción de respuesta óptima inferida. Del dominio modelado, se extraen los

conceptos y términos que forman parte de la ontología, así como las propiedades que permiten definir

cada concepto y las relaciones existentes entre ellos.

La ontología resultante cumple una serie de requisitos y propiedades:

Claridad y objetividad. La ontología especifica de forma objetiva el significado del dominio que

representa.


193

Coherencia y consistencia.

Completa. La ontología contiene las condiciones necesarias y suficientes para su completa

especificación.

Extensibilidad. Permite añadir nuevos conceptos o axiomas a la ontología, sin que para ello

se tengan que revisar las definiciones existentes.

Sus clases son disjuntas.

Es posible separarla en módulos independientes, sin afectar al resto de la ontología.

Utiliza ciertos estándares para la definición de atributos y propiedades, como el estándar CVE

o IDMEF.

Además, como conclusiones del capítulo también se extrae que, a pesar de que el lenguaje OWL2 es

rico en axiomas que permiten expresar ciertas reglas o restricciones, la expresividad del lenguaje

sigue siendo insuficiente, por lo que se hace necesario el uso de lenguajes de reglas o políticas como

SWRL.

Capítulo 6: Propuesta de Métricas de Seguridad y su Especificación mediante SWRL

195

PROPUESTA DE MÉTRICAS DE Capítulo 6

SEGURIDAD Y SU ESPECIFICACIÓN

MEDIANTE SWRL

6.1 Introducción

En el proceso seguido desde que uno de los IDSs de la arquitectura de la red detecta una intrusión

hasta que se evalúa el éxito o eficacia de la acción de respuesta tras haber finalizado su ejecución,

hay diferentes parámetros susceptibles de ser medidos, como se indica previamente en esta memoria

(Ver 2.4.1):

Confianza en el IDS.

Nivel de actividad de la red (anomalía de la red y los sistemas en estado de intrusión).

Fiabilidad del informe de intrusión.

Continuidad de un ataque existente.

Nivel de importancia de los activos de la red que pueden ser comprometidos.

Impacto de la intrusión.

Coste/ Impacto de una acción de respuesta.

Efectividad de una acción de respuesta.

Estos parámetros se corresponden con atributos (Datatype Properties) de las diferentes clases de la

ontología propuesta, y se incluyen en las reglas de inferencia que utiliza el AIRS para inferir las

respuestas recomendadas y la respuesta óptima. Así, por ejemplo, el nivel de confianza en el IDS es

representado en la ontología mediante la propiedad IDSconfidence de la clase

IntrusionDetectionSystem. Por ello, debido a su relevancia en el funcionamiento del sistema, es

necesario especificar diferentes métricas que permitan medir y dar peso a cada uno de estos

parámetros. La elección de la respuesta óptima depende de la calidad y precisión en la definición de

estas métricas de seguridad.

En el Capítulo 2 de la presente memoria se incluye un análisis detallado del estado del arte en cuanto

a métricas de seguridad específicas utilizadas por los AIRSs, así como otras métricas de interés

propuestas cuyo objetivo sea medir alguno de los parámetros enumerados. Del análisis realizado, se

extrae que ciertos parámetros necesarios en el proceso de inferencia de la respuesta óptima llevado

a cabo por el AIRS basado en ontologías propuesto, se pueden medir utilizando algunas de las

métricas existentes. Por el contrario, hay otros parámetros, como el grado de anomalía de la red y de

los sistemas o la efectividad o éxito previo de una respuesta, que requieren de la definición y


196

especificación de nuevas métricas. En este capítulo se proponen métricas para medir los parámetros

no cubiertos.

Por otra parte, además de la especificación de métricas cuyo objetivo sea dar valor a los parámetros

que influyen en la elección de la respuesta óptima, es necesario especificar un conjunto de métricas

cuyo objetivo sea la elección de la respuesta óptima en sí; son las denominadas métricas de

respuesta. Todos los AIRSs analizados especifican una o varias métricas de respuesta, cuyo fin es la

inferencia de la respuesta óptima a desplegar frente a una intrusión determinada en un instante

concreto. El enfoque utilizado por cada AIRS para la definición de estas métricas es distinto, como se

verá más adelante en este capítulo, pero tras el análisis realizado se observa que estos aplican

siempre la misma métrica, es decir, las métricas no pueden ser elegidas de forma dinámica en

función del escenario de intrusión específico en cada momento. Este capítulo trata de abordar este

problema.

Por otra parte, se distingue entre dos tipos de métricas:

- Métricas que son ejecutadas de forma externa o independiente por el propio AIRS de forma

automática o por el administrador del sistema de forma manual, cuyo resultado es un valor

que se incluye en la ontología y en las reglas o políticas utilizadas por el Razonador del

sistema. Ejemplos de estas métricas son las utilizadas para medir parámetros como la

confianza en el IDS, el impacto de la intrusión o el coste/impacto/éxito de una acción de

respuesta. Las reglas utilizan el valor de los parámetros.

- Métricas que determinan directamente el comportamiento del razonador. Es decir, métricas

que no son meros parámetros usados en las reglas, sino que constituyen una parte de las

reglas que rigen el comportamiento del sistema. Ejemplos de estas métricas son las utilizadas

para calcular la fiabilidad del informe de intrusión o las métricas de respuesta.

En los capítulos 3 y 4, se establece que el comportamiento del sistema se modela mediante

reglas o políticas especificadas en el lenguaje SWRL. Por ello, las métricas pertenecientes a

este grupo, deben ser especificadas mediante reglas SWRL.

Los objetivos de este capítulo son:

- Propuesta de métricas de seguridad que permiten medir parámetros involucrados en la

elección de la respuesta óptima frente a una intrusión, para los que no se han propuesto

métricas o éstas son insuficientes.

- Propuesta de métricas para la inferencia de la respuesta óptima frente a una intrusión, que

son ejecutadas por el AIRS de forma dinámica en función del escenario de intrusión

específico en cada momento.

- Especificación de aquellas métricas de seguridad que determinan el comportamiento del

razonador, como son las métricas de respuesta, mediante reglas SWRL.

Además, en el capítulo se indican aquellas métricas propuestas por otros sistemas de respuesta

frente a intrusiones, que son utilizadas en el AIRS basado en ontologías.

6.2 Metodología

Una vez presentada la problemática a afrontar, se abordará la propuesta siguiendo la siguiente

metodología:

Propuesta: Definición y especificación de métricas de seguridad que permitan medir

parámetros involucrados en el proceso de selección de la respuesta óptima ante una

intrusión. Las métricas que constituyan reglas que rijan el comportamiento del sistema, como

son las métricas de respuesta, serán especificadas mediante reglas SWRL. La descripción

detallada de esta propuesta se encuentra en la Sección 6.1.


197

Análisis y evaluación de alternativas: se analizan las métricas de seguridad presentadas y

analizadas en el Capítulo 2, para su posible utilización e integración en el AIRS basado en

ontologías. Además, se evalúa la utilización de lenguajes de políticas y reglas para

especificar métricas de seguridad. Esta evaluación de alternativas se encuentra en la Sección

6.3.

Formalización: Especificación de las métricas de seguridad propuestas, y su especificación

mediante reglas SWRL. Estas métricas se incluyen como políticas en la arquitectura del AIRS

basado en ontologías. La metodología se detalla en la Sección 6.4

Verificación y Validación: Comprobación de que las métricas propuestas permiten medir de

forma eficaz los parámetros para los que han sido diseñadas, y que las reglas SWRL

permiten especificar fielmente las métricas. Esta validación se presenta en el Capítulo 8.

6.3 Evaluación de alternativas

Como se indica en la introducción del capítulo, en el proceso de inferencia de la respuesta óptima y

en la posterior evaluación de su éxito o eficacia tras haber finalizado su ejecución, hay diferentes

parámetros que necesitan ser medidos. En el caso concreto del AIRS basado en ontologías, estos

parámetros son:

Confianza en el IDS.

Nivel de actividad de la red (anomalía de la red y los sistemas en estado de intrusión).

Fiabilidad del informe de intrusión.

Continuidad de un ataque existente.

Nivel de importancia de los activos de la red que pueden ser comprometidos.

Impacto de la intrusión.

Coste/ Impacto de una acción de respuesta.

Efectividad de una acción de respuesta.

En el Capítulo 2 se incluye un extenso análisis del estado del arte en cuanto a métricas de seguridad

utilizadas por los AIRSs existentes, así como otras métricas de seguridad que permiten medir

parámetros como el impacto de la intrusión, la confianza en la fuente de detección o el éxito de la

acción de respuesta.

La Tabla 6.1 evalúa si los AIRSs analizados u otras aproximaciones relacionadas, proponen métricas

que permiten medir alguno de los nueve parámetros críticos para el funcionamiento del AIRS basado

en ontologías.

La escala de colores utilizada en la tabla es la siguiente:

- El color rojo indica que el sistema no propone ni utiliza ninguna métrica que permita medir el

valor de un determinado parámetro. Además, el sistema tampoco tiene en cuenta este

parámetro en ninguna de sus métricas.

- El color amarillo refleja que el sistema de respuesta utiliza un parámetro determinado en

alguna de sus métricas, pero no propone ni especifica cómo calcularlo, cómo medirlo.

- El color verde representa que el AIRS o aproximación, propone y utiliza una métrica de

seguridad que permite medir el valor de un determinado parámetro, es decir, propone un

método o ecuación para calcular su valor.


198

Tabla 6.1 Evaluación de métricas existentes.

Co

nfi

an

za e

n ID

S

An

om

alía d

e R

ed

y s

iste

mas

Fia

bilid

ad

de

in

form

e d

e i

ntr

usió

n

Co

nti

nu

idad

o s

imilit

ud

de a

taq

ue

Imp

ort

an

cia

de lo

s a

cti

vo

s

Imp

acto

de in

tru

sió

n

Co

ste

de r

esp

ue

sta

Imp

acto

de r

esp

ue

sta

Efe

cti

vid

ad

de r

esp

ue

sta

CSM

EMERALD

AAIRS

SARA

ADEPTS

MAIRF

FAIR

IDAM & IRS

Stakhanova’s IRS

Network IRS

Tanachaiwiwat’s IRS

Jahnke’s IRS

POMDP

MAGERIT

Wang et al.

CIDN

Strasburg

Analizando la tabla, se puede extraer como conclusión que existen métricas propuestas por otros

sistemas de respuesta automática frente a intrusiones que permiten medir casi todos los parámetros

requeridos. De hecho, el único indicador para el que no existe ninguna métrica es la anomalía de red

y sistemas.

En la sección 6.4, se valora la posibilidad de utilizar alguna de las métricas propuestas en otros

sistemas en el AIRS basado en ontologías. En caso de que para un determinado parámetro no

resulte apropiada la reutilización de métricas ya existentes, se propone una nueva métrica que

permite obtener el valor del parámetro.

6.3.1 Especificación de métricas de seguridad mediante lenguajes

de políticas y reglas

El objetivo de este apartado es evaluar la utilización de lenguajes de reglas para especificar métricas

de seguridad. Como se ha indicado previamente, los lenguajes de reglas y políticas sirven para

especificar comportamiento. Por otra parte, en esta especificación de comportamiento, juegan un

papel importante las métricas de respuestas. Por ello, en esta sección se evalúa la viabilidad de


199

utilizar el lenguaje de reglas elegido (SWRL) para especificar métricas de seguridad, y no sólo para

modelar comportamiento.

Las razones por las que se ha elegido SWRL como lenguaje para la representación de reglas de

comportamiento, detalladas en apartados anteriores, son:

- Permite la definición de reglas de una forma más general: los lenguajes de políticas y reglas

permiten representar comportamiento de una forma más general que mediante los axiomas

OWL2, que está limitada a la representación de ciertas restricciones predefinidas. La ventaja

de SWRL respecto a los lenguajes de políticas, es que permite la definición de todo tipo de

reglas, permitiendo así abarcar definiciones de métricas de seguridad que especifiquen

comportamiento.

- Presenta facilidad de integración: a diferencia de los lenguajes de políticas que requieren

importar objetos y entidades del modelo de información sobre el modelo de definición de

políticas, SWRL presenta una gran facilidad de integración. Este rasgo lo hace idóneo para

representar métricas de seguridad.

- Entorno de ejecución: OWL, SWRL, y REI no requieren de un motor de inferencias particular

como en el caso de KAoS, lo que facilita su integración con gran cantidad de razonadores

semánticos.

- Permite el uso de parámetros variables entre el antecedente y el consecuente de la regla, lo

que permite que la regla se aplique sobre todos aquellos ejemplares que cumplan

determinada condición. SWRL permite mayor expresividad para la composición de

condiciones en el antecedente de las reglas que KAoS, REI, u owl-restriction.

- Presenta facilidad de uso y adopción: el utilizar un lenguaje como SWRL, de amplia difusión y

en constante evolución en el ámbito de la Web Semántica, permite reaprovechar las técnicas

y herramientas existentes y futuras en ese ámbito, sin la necesidad de diseñar editores,

validadores, motores de ejecución, etc., específicos para nuestro propósito, además de

garantizar una máxima integración con el lenguaje OWL y sus sucesivas versiones

Debido a su gran expresividad, a su facilidad de uso, adopción e integración y a su capacidad de

definición y especificación de todo tipo de reglas, y no sólo de políticas con lógica deóntica (políticas

relacionadas con el deber y las normas: autorizaciones, denegaciones, delegaciones, etc.), se

considera que el lenguaje SWRL es viable para especificar diferentes métricas de seguridad. En la

sección 6.4.3 se incluyen las reglas SWRL utilizadas para especificar métricas de inferencia de

respuesta óptima utilizadas por el AIRS basado en ontologías.

6.4 Propuesta de métricas de seguridad en un AIRS y su

especificación mediante SWRL

El objetivo de esta propuesta es definir métricas de seguridad que permitan medir los parámetros

involucrados en la elección de la respuesta óptima frente a una intrusión. El AIRS basado en

ontologías utilizará estas métricas para obtener los valores de los parámetros necesarios en el

proceso de inferencia. Además, existe un subconjunto de métricas que dan lugar a reglas o políticas

utilizadas por el Razonador en la inferencia, que serán especificadas mediante el lenguaje SWRL. De

este subconjunto se destacan las métricas de elección de la respuesta óptima.

Como se indica en la introducción del capítulo, algunas de las métricas propuestas en otros sistemas

de respuesta son utilizadas en el AIRS basado en ontologías.


200

6.4.1 Definición de métricas de seguridad para su uso en el AIRS

basado en ontologías

La primera fase de la metodología de desarrollo de la ontología de respuesta a intrusiones propuesta

en el capítulo anterior consiste en la especificación del dominio que pretende modelar la ontología, y

en la identificación de los elementos específicos del mismo. Como resultado de esta fase, se extrae

un glosario de términos (alerta de intrusión, respuesta, impacto de intrusión, contexto de sistemas,

IDS, AIRS, servicio, proceso, activo, coste de respuesta, red, etc.) y los pares Object-Property. Del

mismo modo, en la segunda fase se agrupan los términos que comparten las mismas propiedades

para obtener taxonomías y establecer relaciones entre los diferentes objetos identificados en la fase

anterior. Como resultado se obtienen tuplas Object-Relation-Object. La especificación formal de los

conceptos representados mediante estos objetos, propiedades y relaciones da lugar a las clases,

atributos (Datatype properties) y relaciones (Objetc properties) que componen la ontología.

Cuando se crea un ejemplar de una clase de la ontología, es necesario darle valor a las propiedades

que lo caracterizan, o al menos a aquellas que son marcadas como requeridas mediante restricciones

de cardinalidad. Se distinguen dos formas de asignar valor a estas propiedades:

- Forma simple: método que no requiere de lógica adicional ni realizar operaciones

matemáticas para asignar valor a una propiedad. En este caso, tanto el administrador del

sistema como el propio AIRS pueden asignar el valor a las propiedades sin mucha

complicación. En el caso del administrador del sistema, cuando crea nuevos ejemplares de

una clase a través de la interfaz de administración especificará el valor correspondiente de

ciertas propiedades, como por ejemplo, el nombre de la acción de respuesta o la dirección IP

asociada a un servidor presente en la arquitectura de la red. En el caso del AIRS y los

módulos que lo forman, pueden asignan valor a propiedades de forma automática y simple,

como en el caso del identificador del IDS que genera la alerta de intrusión, el tipo de amenaza

asociada a una intrusión, o la dirección IP asociada al activo atacado.

- Forma compleja: método que requiere realizar operaciones matemáticas o aplicar lógica

adicional para obtener el valor de una propiedad. Estas operaciones o lógica adicional

pueden ser ejecutada por el administrador (un mínimo de ocasiones), o por el propio AIRS de

forma automática (la mayoría de los casos). Ambos, deben medir el parámetro

correspondiente utilizando una métrica o mecanismo adecuado.

Aquellos parámetros y atributos especificados en la ontología susceptibles de ser medidos y que por

tanto, requieren de la especificación de métricas, son:

Confianza en el IDS, especificado en la ontología mediante la propiedad IDSconfidence de la

clase IntrusionDetectionSystem.

Anomalía de la red y de los sistemas en estado de intrusión. Parámetros especificados

en la ontología mediante las propiedades, networkAnomaly, systemStatus,

systemActiveProcesses, systemZombieProcesses, systemNumberOfUsersLogged,

systemFreeSpace, systemLatency, systemCPUUsage y systemSSHFailed de la clase

Network.

Fiabilidad del informe de intrusión, especificado en la ontología mediante la propiedad

intrusionAlertReliability de la clase FormattedIntrusion.

Continuidad de ataque, es decir si el ataque es una continuación de uno ya detectado o se

trata de un nuevo ataque. Este parámetro se representa en la ontología mediante la

propiedad isContinuationOf de la clase FormattedIntrusion.

Nivel de importancia de los activos del sistema que pueden ser comprometidos,

especificado en la ontología mediante la propiedad assetLevelOfImportance de la clase

Asset.


201

Impacto de la intrusión, especificado en la ontología mediante la propiedad intrusionImpact

de la clase FormattedIntrusion.

Coste/ Impacto de una acción de respuesta, especificados en la ontología mediante las

propiedades, responseDeploymentCost y responseImpact de la clase Response.

Efectividad de una acción de respuesta, especificado en la ontología mediante la

propiedad responseEfficiency de la clase Response.

A continuación se especifican las métricas utilizadas en el AIRS basado en ontologías para calcular

cada una de los 9 parámetros.

6.4.1.1 Métrica de confianza en el IDS

Debido a la variedad de factores que influyen en la detección de una intrusión, y de la sofisticación de

los atacantes y los ataques actuales, no siempre un IDS lleva a cabo la detección de una forma

correcta. Asociados a cada IDS hay una tasa de falsos positivos (detectar como anómalo algo que no

lo es) y una tasa de falsos negativos (se considera normal comportamiento anómalo y no se genera

informe de intrusión). Ambos fallos en la detección de ataques provocan un impacto en el sistema

protegido que hay que tener en cuenta a la hora de que el AIRS seleccione la respuesta. Un IDS con

una tasa de falsas alarmas baja es más confiable que otro con la tasa más alta.

Tomando como referencia las métricas definidas en AAIRS [Carver01b] y FAIR [Papadaki06] se

define la métrica de confianza en el IDS del AIRS basado en ontologías propuesto haciendo uso del

número de falsos positivos y negativos.

Esta métrica se define tanto cuantitativamente como cualitativamente. La expresión propuesta para el

cálculo cuantitativo de la métrica es:

( ) (

) (6.1)

Donde,

- NTIR es el número total de intrusiones reales.

- FP representa el número de falsos positivos.

- FN es el número de falsos negativos.

Esta métrica difiere de la utilizada en AAIRS y FAIR en que además de tener en cuenta los falsos

positivos, tiene en cuenta también el número de falsos negativos generados por el IDS.

El valor obtenido mediante la ecuación anterior sirve de base para expresar la métrica de forma

cualitativa, en función de la siguiente tabla:

Tabla 6.2 Métrica (cualitativa) de confianza en el IDS.

IDSconfidence

ConfianzaIDS (%) < 35 % Bajo

35 % < ConfianzaIDS (%)

< 75% Medio

ConfianzaIDS (%) > 75 % Alto

Esta métrica es aplicada por el administrador del sistema de forma manual o por el AIRS de forma

automática, y su resultado se representa en la ontología de respuesta a intrusiones mediante la

propiedad IDSconfidence perteneciente a las instancias de la clase IntrusionDetectionSystem. En la

ontología se utilizan los resultados cuantitativos de la métrica.


202

6.4.1.2 Métrica de nivel de anomalía de red y de sistemas

Un indicador de que se está produciendo comportamiento anómalo en la red o en un sistema, es la

variación de los parámetros del contexto asociado respecto a un perfil de actividad normal o habitual.

Esta variación se mide como el grado de anomalía detectado en cada uno de los parámetros

analizados, y constituye un parámetro importante en el proceso de selección de la respuesta óptima

así como en la evaluación del éxito de la misma (Ver Capítulo 7). En la sección 4.4.2, se describe el

módulo de contexto de red y de sistemas propuesto como parte de la arquitectura del AIRS,

encargado de obtener dicha anomalía respecto a 9 parámetros de contexto: anomalía en el tráfico de

la red, anomalía en el estado del sistema, en el número de procesos activos, número de procesos

zombie, número de usuarios autenticados, espacio libre en disco, latencia del sistema, uso de la CPU

y número de autenticaciones fallidas utilizando SSH.

Para el cálculo del nivel de anomalía se utilizan métodos probabilísticos que calculan entre otros

parámetros la media y la varianza asociada en cada caso. Estas métricas y la metodología propuesta

para el cálculo de la anomalía de la red y los sistemas en momento de intrusión, se definen

detalladamente en 4.4.2.

Las métricas de nivel de anomalía son aplicadas por el AIRS de forma automática y su resultado se

representa en la ontología mediante las propiedades, networkAnomaly, systemStatus,

systemActiveProcesses, systemZombieProcesses, systemNumberOfUsersLogged,

systemFreeSpace, systemLatency, systemCPUUsage y systemSSHFailed de las clases

NetworkContext y SystemContext.

Como se indica en la sección anterior, ninguno de los AIRSs analizados utiliza una métrica de nivel

de anomalía.

6.4.1.3 Métrica de fiabilidad del informe de intrusión

La fiabilidad del informe de intrusión es un parámetro que representa el nivel de sospecha que se

tiene de que el tipo de intrusión incluido en la alerta es real, es decir, el grado de confianza de que la

intrusión detectada por el IDS está ocurriendo.

De las métricas propuestas, tan sólo tres de ellas proporcionan una métrica que mide la fiabilidad de

la alerta:

- Métrica de grado de sospecha utilizada en AAIRS (Ver 2.4.2.3): métrica que utiliza el número

de incidentes recibido por un Analysis Agent específico y el número de incidentes referidos a

un mismo ataque contra un mismo sistema. Cuánto más incidentes relativos al mismo ataque

haya, mayor será el grado de sospecha. Esta métrica presenta el inconveniente de que no se

tiene en cuenta la tasa de detección o eficiencia de la fuente que genera los incidentes. Es

decir, para evaluar la fiabilidad de una intrusión, sólo se utiliza una fuente de información, los

incidentes recibidos por el AIRS.

- Métrica de confianza en la alarma utilizada en FAIR (Ver 2.4.2.7): métrica que refleja la

confianza en que una alarma detectada es realmente un ataque, en función de la confianza

de intrusión y la eficiencia de detección del IDS. No obstante, los autores no especifican cómo

obtienen la confianza de intrusión.

- Métrica de probabilidad de ocurrencia propuesta por Stakhanova (Ver 2.4.2.9): métrica que

indica el nivel de confianza de que un patrón de intrusión está ocurriendo, para lo que utiliza

el número de secuencias-ocurrencias. Métrica orientada a la prevención de los ataques, a la

respuesta temprana, por lo que no es aplicable en el sistema de respuesta propuesto.

Por los motivos señalados en cada una de las métricas, no se considera adecuado utilizar ninguna de

ellas para medir la fiabilidad de un informe de intrusión en el AIRS basado en ontologías, y por ello,

se propone una nueva métrica.


203

Como se indica en la métrica anterior, un buen indicador de que se está produciendo comportamiento

anómalo en la red o en un sistema, es la variación de los parámetros del contexto asociado en un

momento concreto respecto a un perfil de actividad normal o habitual. Además, mediante el análisis

de qué indicadores son los que varían se puede determinar el vector de ataque utilizado. Por poner

un ejemplo, un ataque de DoS provoca un aumento drástico en la latencia del sistema.

Por ello, se propone una métrica de fiabilidad de informe de intrusión basada en tres parámetros:

- Amenaza o tipo de ataque incluido en la alerta de intrusión enviada por el IDS. El informe de

intrusión, siempre incluye un único tipo de ataque o amenaza específico (Threatx).

- Amenaza indicada por la variación de los parámetros de contexto de la red y de los sistemas,

en caso de que sea posible. La anomalía del contexto de red y del sistema comprometido

puede indicar: un tipo de amenaza específico e idéntico al incluido en la alerta de intrusión

(Threatx), un tipo de amenaza específico pero distinto al incluido en la alerta de intrusión

(Threaty), no indicar amenaza (No Threat) o indicar la existencia de comportamiento anómalo

en la red o en el sistema, pero no tener datos suficientes para especificar el tipo de amenaza

específico.

- Confianza en el IDS que genera la alerta de intrusión. Resultado de la métrica de confianza

en el IDS.

La tabla de decisión para la métrica de fiabilidad de intrusión es la siguiente:

Tabla 6.3 Métrica de fiabilidad del informe de intrusión.

ThreatFormattedIntrusion ThreatContexto IDSconfidence Fiabilidad del

informe de intrusión

Threatx Threatx Alto Alto

Threatx Threatx Medio Alto

Threatx Threatx Bajo Alto

Threatx Threaty Alto Medio

Threatx Threaty Medio Medio

Threatx Threaty Bajo Bajo

Threatx No Threat Alto Medio

Threatx No Threat Medio Bajo

Threatx No Threat Bajo Bajo

Threatx Threat No específica Alto Alto

Threatx Threat No específica Medio Medio

Threatx Threat No específica Bajo Bajo

Según la clasificación de métricas establecida en la introducción del capítulo, esta métrica pertenece

al conjunto de métricas que determinan directamente el comportamiento del razonador. Es decir, la

métrica da lugar a un conjunto de reglas o políticas utilizadas por el razonador del sistema en el

proceso de inferencia. En la sección 6.4.3 se incluye su especificación mediante reglas SWRL.

El resultado de la métrica se corresponde con la propiedad intrusionAlertReliability de la clase

FormattedIntrusion de la ontología. El valor de la propiedad puede ser: high, medium o low.

6.4.1.4 Métrica de continuidad o similitud de ataque

Un AIRS puede recibir alertas de intrusión procedentes del mismo o de distintos IDSs en instantes

muy cercanos en el tiempo. Ante esta situación es muy importante establecer una métrica que

permita al AIRS determinar si la última alerta de intrusión recibida pertenece a un ataque que es

continuación de otro existente ya detectado y tratado, o si por el contrario, se trata de un nuevo

ataque diferente, y que por tanto hay que procesar y ejecutar el proceso de inferencia de la respuesta

óptima. Cabe aclarar que la métrica no determina si dos alertas de intrusión recibidas son idénticas,


204

sino que el objetivo es clasificar un informe de intrusión como parte de un ataque antiguo o como un

ataque nuevo.

Como se observa en la Tabla 6.1 el sistema de respuesta AAIRS especifica una métrica que

determina si un informe de intrusión recibido es parte de un ataque antiguo o se trata de un nuevo

ataque. La métrica propuesta por AAIRS se toma como referencia para la especificación de la métrica

de continuidad de ataque utilizada por el AIRS basado en ontologías. La métrica definida tiene en

cuenta cuatro parámetros: el tipo de ataque o amenaza asociado a la alerta, la dirección IP del activo

comprometido, la dirección IP origen, si esta se proporciona, y el tiempo transcurrido entre ambas

alertas. La tabla de decisión de la métrica se muestra a continuación:

Tabla 6.4 Métrica de continuidad de ataque.

Tipo de ataque IP destino o IP origen Tt1 ≥ Tt2 - 10000 Resultado

Igual Igual Sí Continuación de ataque

antiguo

Igual Igual No Ataque Nuevo

Igual Distinto Sí Continuación de ataque

antiguo

Igual Distinto No Ataque Nuevo

Distinto Igual Sí Ataque Nuevo

Distinto Igual No Ataque Nuevo

Distinto Distinto Sí Ataque Nuevo

Distinto Distinto No Ataque Nuevo

La métrica establece que un ataque es continuación de otro existente si el tipo de ataque es el mismo

y el tiempo transcurrido entre ambos es menor que un tiempo fijado por el administrador medido en

milisegundos, independientemente de que la dirección IP origen o destino sea igual o diferente.

En el caso de que una alerta sea continuación de otra pero la dirección IP del activo objetivo sea

diferente, el sistema debe asociar el nuevo activo objetivo a la propiedad hasTarget de la instancia de

FormattedIntrusion correspondiente. Además, la alerta recibida que es continuación de un ataque

antiguo, será almacenada en la ontología pero el AIRS la marcará como no pendiente de respuesta.

Además, tras aplicar esta métrica, el sistema representará el resultado en la ontología mediante la

propiedad isContinuationOf de la clase FormattedIntrusion, que relaciona ambas alertas de intrusión.

6.4.1.5 Métrica de importancia del activo atacado

La elección de una respuesta frente a una intrusión está muy ligada al nivel de importancia del activo

atacado, y a cómo la intrusión afecta a su disponibilidad, integridad, confidencialidad y autenticidad,

en especial a las tres primeras consideradas como dimensiones de seguridad básicas. Así pues, es

muy importante hacer una valoración de los activos presentes en la organización como paso previo a

la elección de la respuesta. Valorar un activo consiste en determinar la importancia de dicho activo

para la organización, teniendo en cuenta qué coste supondría para la organización la pérdida parcial

o total de dicho activo.

Algunos de los AIRSs analizados incorporan el nivel de importancia del activo comprometido en las

métricas utilizadas para la elección de la respuesta óptima, pero no indican cómo calculan dicho

valor. Es el caso de IDAM & IRS, Network IRS o POMDP.

Por otra parte, la metodología MAGERIT [MAGERIT-I12] propone como primera fase de un análisis

de riesgos, la determinación de los activos relevantes para la organización, su interrelación y el valor

que estos poseen, en el sentido del perjuicio o coste que supondría su pérdida o degradación.

MAGERIT establece que la valoración de un activo puede ser cuantitativa o cualitativa, y en ambos

casos el objetivo es identificar en qué dimensión de seguridad el activo es valioso para, a

continuación determinar el coste que para la organización supondría la destrucción total o parcial de

dicho activo. Para ello, proponen varias técnicas y prácticas [MAGERIT-III12] entre las que se


205

encuentra realizar entrevistas a diferentes colectivos dentro de la organización, como por ejemplo,

dirección o gerencia (que conocen las consecuencias para la misión de la Organización),

responsables de los datos (que conocen las consecuencias de sus fallos de seguridad), responsables

de los servicios (que conocen las consecuencias de la no prestación del servicio o de su prestación

degradada) o responsables de sistemas de información y responsables de operación (que conocen

las consecuencias de un incidente). Otra técnica propuesta es aplicar la metodología Delphi a la

valoración de activos.

En el caso del AIRS basado en ontologías se utiliza una métrica donde se utiliza la siguiente escala

de valores:

Tabla 6.5 Escala de valor para la métrica de importancia de un activo.

Valor Criterio

8-10 Alto Daño grave o muy grave

4-7 Medio Daño importante

0-3 Bajo Daño menor o irrelevante

Utilizando la escala anterior, para cada valoración de cada activo presente en la organización se debe

proporcionar la siguiente información:

- Dimensiones en las que el activo es relevante.

- Estimación de la valoración en cada dimensión.

- Valoración global del activo.

Para asignar los valores a la importancia de cada activo en las cuatro dimensiones de seguridad, se

utilizan las técnicas y prácticas propuestas en la metodología MAGERIT.

La métrica de importancia del activo atacado es aplicada por el administrador del sistema de forma

manual, y su resultado se representa en la ontología utilizada en el AIRS propuesto mediante las

propiedades assetLevelOfImportance_confidentiality, assetLevelOfImportance_integrity,

assetLevelOfImportance_availability, assetLevelOfImportance_authenticity y assetLevelOfImportance

perteneciente a las instancias de la clase Asset.

6.4.1.6 Métrica de impacto de una intrusión

Tal como se indica en capítulos anteriores de la memoria, el impacto de una intrusión se define como

el daño potencial que causa una amenaza en un activo. Este daño puede ser expresado en términos

cuantitativos o cualitativos.

Como se observa en la tabla presente en la evaluación de alternativas de este capítulo, varios

autores proponen métricas para calcular el impacto de una intrusión. De ellos, IDAM & IRS,

Stakhanova’s IRS y Tanachaiwiwat’s IRS, utilizan el valor del impacto de la intrusión en sus métricas

pero no indican la ecuación o metodología que utilizan para obtener dicho valor. Las otras métricas

propuestas son las siguientes:

- Métrica de impacto utilizada por el IRS propuesto por Jahnke [Jahnke07]: calcula el impacto

en términos de la disponibilidad de un recurso tras una intrusión. Cuanto menor sea la

disponibilidad, mayor será el impacto de una intrusión en el sistema.

- Métrica de impacto de una intrusión mediante POMDP [Zhang07]: calcula el impacto causado

por una intrusión en un sistema como la suma del impacto en cada activo afectado. El

impacto en un activo es el producto de la importancia de dicho activo en el sistema y el grado

de amenaza asociado a una intrusión.

- Métrica de impacto de una intrusión de MAGERIT [MAGERIT-I12]: la metodología establece

el impacto de una intrusión en un activo como el producto del valor acumulado de dicho activo

y la degradación sufrida como consecuencia de la intrusión.


206

- Métrica de impacto propuesta por Strasburg [Strasburg09]: calcula el impacto de una intrusión

en el sistema como la suma del impacto en cada activo afectado. El impacto de un activo es

el producto del efecto de la intrusión en dicho activo en las tres dimensiones de seguridad y el

nivel de importancia de dicho activo en el sistema global.

La métrica utilizada por el AIRS basado en ontologías para calcular el impacto de una intrusión, se

basa en tres de las cuatro métricas propuestas (métrica basada en POMDP, la propuesta en

MAGERIT y la propuesta por Strasburg), y su expresión es la siguiente:

∑ ( ) ( ) (6.2)

( ) ( ) ( ) ( )

( ) ( ) ( ) ( )

( )

Donde,

- Severity (ik), es el grado de amenaza asociado a la intrusión ik.

- I (ik,aj), es el efecto que tiene la intrusión ik en el activo comprometido, aj. Depende de la

importancia del activo en cada una de las cuatro dimensiones de seguridad y de cómo afecta

el ataque a dicha dimensión de seguridad.

- ik(C), ik (A), ik (I), e ik (Aut), son parámetros que representan el efecto que tiene la intrusión en

cada una de las cuatro dimensiones de seguridad: C (confidentiality o confidencialidad), A

(Availability o Disponibilidad), I (Integrity o Integridad) y Aut (Authenticity o Autenticidad). Su

valor puede ser 0 ó 1, 0 si la intrusión no amenaza a la dimensión de seguridad, y 1 si tiene

efecto sobre ella. Estos valores se representan en la ontología mediante la propiedad

threatens de la clase Threats.

- ajvalue (C), ajvalue (A), ajvalue(I) y ajvalue(Aut), se corresponden con el nivel de importancia del

activo aj en cada una de las dimensiones de seguridad.

- n, es el número de activos afectados por la intrusión.

En caso de que sea posible calcularlo, hay un factor más a tener en cuenta en la determinación del

impacto de una intrusión: el factor de exposición. El factor de exposición se refiere al tiempo que el

activo está bajo amenaza. Por ejemplo, en caso de que la amenaza suponga una pérdida de

disponibilidad de un servicio, hay que tener en cuenta si esta disponibilidad es temporal o permanente

y cuánto tiempo. La expresión de la métrica teniendo en cuenta el factor de exposición sería de la

siguiente forma:

∑ ( ) ( ) (6.3)

Donde, FEj representa el factor de exposición correspondiente al activo j.

Esta métrica mide el impacto que causa (o que podría causar) una intrusión al irrumpir en un sistema.

La métrica definida es una métrica cuantitativa, y el resultado de la misma se representa en la

ontología mediante la propiedad intrusionImpact de la clase FormattedIntrusion. El AIRS es el

encargado de aplicar esta métrica de forma automática.

6.4.1.7 Métrica de coste de despliegue de una acción de respuesta

En el Capítulo 2 se especifica que uno de los requisitos deseables en un sistema de respuesta

automática frente a intrusiones es que sea sensible al coste de las respuestas, es decir, que además

de tener en cuenta el impacto de la intrusión y el beneficio de la acción de respuesta, considere el

coste asociado a la ejecución de esta última a la hora de inferir la respuesta óptima. El coste total de

una acción de respuesta se divide en dos factores:


207

- Coste de despliegue: coste que supone el despliegue de la acción de respuesta a la

organización, en términos de consumo de recursos, como por ejemplo el número de routers

necesarios.

- Impacto de la respuesta: coste asociado a la ejecución de la acción de respuesta, en términos

del daño que esta causa en los activos de la organización.

La métrica especificada en este apartado se refiere al primer factor del coste, el coste de despliegue,

y la ecuación utilizada es la propuesta por [Zhang07] siendo su expresión de la siguiente forma:

∑ (6.4)

Donde,

- Cur, es el coste de utilización del recurso.

- Fur, es el factor de utilización del recurso, tiempo de utilización del recurso.

- n, es el número de recursos empleados en el despliegue de la respuesta.

Esta métrica es aplicada por el administrador del sistema de forma manual, y su resultado se

representa en la ontología mediante la propiedad responseDeploymentCost que caracteriza a las

instancias de la clase Response.

6.4.1.8 Métrica de impacto de una acción de respuesta

El impacto de una respuesta es el daño que causa en los activos del sistema, es decir, el perjuicio o

efecto negativo que implica desplegar una determinada acción de respuesta. Como se ha indicado en

el apartado anterior, el coste total de una acción de respuesta es la suma de su coste de despliegue y

el impacto de la respuesta.

Muchos de los AIRSs analizados tienen en cuenta el impacto de la respuesta en el proceso de

elección de la respuesta óptima, y algunos proponen métricas para calcular dicho impacto, como es el

caso del Network IRS, Jahnke’s IRS o Strasburg.

No obstante, la métrica utiliza por el AIRS basado en ontologías para calcular el impacto de una

acción de respuesta, es equivalente a la métrica de impacto de una intrusión especificada. Por ello, la

ecuación que rige la métrica tiene la siguiente forma:

∑ ( ) ( ) (6.5)

( ) ( ) ( ) ( )

( ) ( ) ( ) ( )

( )

Donde,

- Severity (respk), es el grado de amenaza asociado a la respuesta desplegada respk.

- I (respk,aj), es el efecto que tiene la respuesta respk en cada uno de los activos afectados por

su despliegue. Depende de la importancia del activo en las cuatro dimensiones de seguridad

y de cómo afecta la acción de respuesta a dicha dimensión de seguridad.

- respk(C), respk (A), respk (I), e respk (Aut), son parámetros que representan el efecto que

tiene la respuesta en cada una de las cuatro dimensiones de seguridad: C (confidentiality o

confidencialidad), A (Availability o Disponibilidad), I (Integrity o Integridad) y Aut (Authenticity

o Autenticidad). Su valor puede ser 0 ó 1, 0 si la respuesta no tiene efecto sobre la dimensión

de seguridad, y 1 si tiene efecto sobre ella.

- ajvalue (C), ajvalue (A), ajvalue(I) y ajvalue(Aut), se corresponden con el nivel de importancia del

activo aj en cada una de las dimensiones de seguridad.


208

- n, es el número de activos afectados por la ejecución de la respuesta.

De igual forma que en el impacto de la intrusión, en el cálculo del impacto de la respuesta se tiene en

cuenta el factor de exposición de cada activo a la respuesta, en caso de que sea posible obtenerlo.

La forma en la que este factor modifica la ecuación anterior es equivalente al caso de la métrica de

impacto de una intrusión (Ver Ecuación 6.3).

Por tanto, el impacto de la respuesta representa el coste que supone la ejecución de la respuesta,

desde el punto de vista del número de activos afectados. La métrica definida es una métrica

cuantitativa, y el resultado de la misma se representa en la ontología mediante la propiedad

responseImpact de la clase Response. El AIRS basado en ontologías es el encargado de aplicar esta

métrica.

6.4.1.9 Métrica de éxito o eficiencia de una acción de respuesta

Una vez que una respuesta ha sido inferida y ejecutada por el dispositivo de seguridad

correspondiente, es necesario evaluar si la respuesta ha conseguido mitigar la intrusión o por el

contrario, no ha tenido éxito.

La ecuación que rige la métrica que permite calcular este parámetro es la siguiente:

responseEfficiency (%) =

∑

(6.6)

Donde,

- j es el número de veces que una respuesta determinada ha sido inferida como respuesta

óptima y por tanto ejecutada.

- RPEi (Response Partial Efficiency) es la eficiencia parcial de la respuesta asociada a la

ejecución “i” de la misma.

El Capítulo 7 propone una metodología para la evaluación del éxito de la respuesta. Este capítulo

incluye un análisis de las métricas de eficiencia propuestas por otros AIRSs, y propone una

metodología para calcular el valor de RPE y responseEfficiency tras la ejecución de una respuesta.

Esta métrica es aplicada por el AIRS basado en ontologías de forma automática, y su resultado se

corresponde con la propiedad responseEfficiency que caracteriza a los ejemplares de la clase

Response de la ontología.

6.4.2 Definición de métricas de inferencia de la respuesta óptima

El principal objetivo de un AIRS es seleccionar la respuesta óptima frente a una intrusión detectada

teniendo en cuenta el contexto particular de ataque en cada momento. Una vez que el sistema ha

detectado la intrusión y se ha determinado su impacto, es necesario que el sistema infiera qué acción

de respuesta es más conveniente desplegar en cada caso.

Para la elección de la respuesta óptima es necesario especificar un conjunto de métricas, que son

especialmente relevantes para el correcto funcionamiento del AIRS. La gran mayoría de los AIRSs

estudiados y analizados en el Capítulo 2, especifican métricas que permiten inferir la acción más

adecuada para reaccionar frente a una intrusión detectada en el sistema. El enfoque utilizado por

cada sistema es distinto, como se resume en la siguiente tabla:

Tabla 6.6 Enfoque utilizado en la métrica de inferencia de respuesta óptima por los AIRSs.

AIRS Enfoque utilizado en métrica de respuesta

CSM Nivel de sospecha

EMERALD Mínimo impacto

AAIRS Máxima eficiencia


209

SARA ----

ADEPTS Máxima eficiencia al menor riesgo (Maximizar relación Beneficio/Impacto)

MAIRF ----

FAIR

Dos enfoques:

- Mínimo impacto

- Máxima eficiencia

IDAM & IRS Maximizar relación Beneficio/Impacto

Stakhanova’s IRS Máxima eficiencia al menor riesgo (Maximizar relación Beneficio/Impacto)

Network IRS Mínimo impacto

Tanachaiwiwat’s IRS ----

Jahnke’s IRS Mínimo impacto

Aproximación POMDP Mínimo coste

Aproximación de Strasburg Mínimo coste

Cada enfoque utilizado tiene sus ventajas e inconvenientes, y el objetivo de este apartado no es

valorar cada uno de ellos. Pero hay un inconveniente común a todos ellos, el sistema de respuesta

aplica siempre la misma métrica (excepto FAIR), es decir, el sistema no tiene en cuenta el escenario

de intrusión específico en cada momento para inferir la respuesta óptima.

En este apartado, se propone un enfoque más flexible, adaptado al escenario de intrusión concreto,

en el que el AIRS puede seleccionar de forma dinámica la métrica de respuesta a aplicar en función

de ciertos parámetros, como por ejemplo, el nivel de importancia del activo atacado o el impacto de la

intrusión.

En el caso de FAIR, los autores proponen un enfoque similar, en el que el AIRS elige una métrica que

minimiza el impacto o una que maximiza el beneficio en función de la urgencia de respuesta y la

amenaza global bajo la que se encuentra el sistema. Pero, no tienen en cuenta el nivel del activo

comprometido ni el impacto causado por la intrusión (parámetros a priori relevantes), en ninguna de

las métricas.

Por todo ello, el enfoque utilizado por el AIRS basado en ontologías para la elección de la respuesta

óptima, es un enfoque dinámico en el que el AIRS puede utilizar tres métricas distintas. La aplicación

de una u otra depende de la relevancia del activo atacado. Por ejemplo, si el recurso afectado es un

host de usuario, el coste de la respuesta tendrá prioridad sobre su tasa de éxito, sin embargo, si el

recurso atacado es el servidor principal de bases de datos, el sistema le dará más importancia a la

severidad y eficacia de la respuesta que al coste ocasionado al ejecutarla.

Las tres métricas propuestas son las siguientes [Mateos12].

6.4.2.1 Métrica de reducción de daño

En primer lugar, se propone una métrica de reducción de daño o impacto que no depende de la

importancia del activo. Es decir, el sistema debe aplicar esta métrica siempre.

El objetivo de la métrica es establecer un balance entre el coste que supone la consecución del

ataque detectado (su impacto), y el coste que supone el despliegue de la respuesta para la

organización en términos del efecto negativo que tiene el desplegar la respuesta en los activos del

sistema, como por ejemplo posibles pérdidas de disponibilidad de ciertos recursos (el impacto de la

respuesta).

La ecuación que satisface la métrica es la siguiente:

(6.7)

Esta métrica es equivalente a la métrica de reducción de daño propuesta por Stakhanova et al

[Stakhanova07a], pero además de tener en cuenta el nivel de confianza en la alerta se incluye en

nivel de confianza en el IDS.


210

El AIRS tras la aplicación de la métrica, descarta aquellas respuestas incluidas en el conjunto de

respuestas recomendadas cuyo impacto en el sistema sea mayor que el producto del impacto de la

intrusión detectada y la confianza en el IDS y en la intrusión. Si la confianza en el IDS y la fiabilidad

de la alerta son del 100%, no se inferirán como óptimas aquellas respuestas cuyo impacto en los

activos del sistema sea superior al daño causado por la intrusión.

La métrica depende de cuatro parámetros, que a su vez, son objeto de medida: el impacto de la

intrusión, la confianza en el IDS, la fiabilidad del informe de intrusión y el impacto de la respuesta. El

valor de cada uno de los cuatro parámetros se obtiene mediante la aplicación de las métricas

correspondientes, especificadas en puntos anteriores de este capítulo.

El producto del impacto de la intrusión por la confianza del IDS y la fiabilidad de la intrusión, da lugar

a un resultado que se representa en la ontología mediante la propiedad realIntrusionImpact de la

clase FormattedIntrusion.

6.4.2.2 Métrica de mínimo coste

El AIRS aplica la métrica de mínimo coste si el activo comprometido no es muy relevante para la

organización, es decir su nivel de importancia es bajo (utilizando la métrica cualitativa) o inferior a 3

(si se utiliza la métrica cuantitativa). En cualquier otra situación, el sistema no debería usar esta

métrica para inferir la respuesta óptima.

El objetivo de la métrica es minimizar el coste total asociado a la ejecución y despliegue de la acción

de respuesta. Cada vez que el AIRS aplica esta métrica, inferirá como óptima aquella respuesta del

conjunto de respuestas recomendadas cuyo coste sea menor.

La métrica de mínimo coste propuesta satisface una ecuación de la forma:

CosteT respuesta = Impactorespuesta + Costed respuesta (6.8)

Como se observa, la métrica no depende del éxito de la respuesta ni del daño causado por la

intrusión en el activo. El objetivo de la métrica es minimizar la ecuación anterior. El coste total

asociado a una acción de respuesta, representado como CosteTrespuesta, y es la suma del daño

causado por la aplicación de la respuesta y del coste asociado a su despliegue. El primer factor,

Impactorespuesta representa el coste derivado de ejecutar la respuesta en términos del daño que la

acción causa en los recursos de la organización. El segundo factor, Costed respuesta, hace referencia

al coste que el despliegue de la reacción supone para la organización, en términos de recursos

necesarios (número de routers necesarios, backups realizados, etc.).

Por otro lado, las respuestas de menor coste son, por lo general, las respuestas de menor

complejidad, por lo que, si varias respuestas tienen el mismo coste, el AIRS seleccionará la respuesta

de menor complejidad.

La métrica depende dos parámetros: el impacto de la respuesta y el coste de despliegue de la misma.

Para el cálculo de ambos parámetros se aplican las métricas definidas previamente en este capítulo.

Cabe recordar, que el impacto de la respuesta lo mide el AIRS de forma automática, y el coste de

despliegue es calculado por el administrador del sistema. El valor de ambos parámetros se introduce

en la ontología, y su suma será utilizada por el razonador en el proceso de inferencia de la respuesta

óptima cuando corresponda.

6.4.2.3 Métrica de máxima severidad o máxima eficiencia

Si el recurso comprometido es muy relevante o crítico para el funcionamiento de la organización, el

sistema de respuesta utiliza la métrica de máxima gravedad o máxima eficiencia. El objetivo de la

métrica es maximizar la severidad y éxito de la acción de respuesta, es decir, el sistema inferirá como

óptima aquella respuesta incluida en el conjunto de respuestas recomendadas cuya eficacia sea

mayor.


211

Esta métrica depende del resultado de las ejecuciones anteriores de la respuesta ante una intrusión

(eficacia o tasa de éxito asociada a la acción de respuesta), de la severidad asociada a la intrusión y

de la severidad de la propia respuesta.

Al igual que la métrica anterior, la aplicación de esta métrica no excluye de la aplicación de la métrica

de reducción de daño o impacto. Si la importancia del activo comprometida es alta, el AIRS primero

aplica la métrica de reducción de daño, y a continuación, aplicará la métrica de máxima eficacia sobre

el conjunto de respuestas resultantes.

La métrica de máxima eficiencia propuesta satisface las siguientes ecuaciones:

(6.9)

(6.10)

El objetivo de la métrica es satisfacer la primera condición y maximizar la segunda ecuación.

La métrica depende de tres parámetros que, a su vez, deben ser medidos:

- Severidad de la intrusión: el IDS incluye el tipo de intrusión en el informe. Este tipo de

intrusión o amenaza tiene asociado un valor de severidad. Este valor es fijado por el

formateador de alertas presente en la arquitectura del AIRS, y su resultado se representa en

la ontología mediante la propiedad intrusionSeverity de la clase FormattedIntrusion.

- Severidad absoluta de acción de respuesta: parámetro asociado a una acción de respuesta

fijado previamente por el administrador del sistema de forma manual. Se representa en la

ontología mediante la propiedad responseSeverity de la clase Response.

- Eficiencia de la respuesta (RTE, Response Total Efficiency): parámetro que representa la

tasa de éxito de una acción de respuesta. El valor de este parámetro se obtiene utilizando la

métrica de éxito de una acción de respuesta propuesta en este capítulo. Se representa

mediante la propiedad responseEfficiency en la ontología.

Para la inferencia de la respuesta óptima frente a una intrusión, se propone una métrica de respuesta

que utiliza un enfoque dinámico, es decir, el AIRS no ejecuta siempre la misma métrica para obtener

la respuesta óptima frente a una intrusión, sino que en función del escenario de intrusión, en especial

del nivel de importancia del activo atacado, el sistema de respuesta aplica una de las tres métricas

propuestas. De hecho, el AIRS siempre aplica la métrica de reducción de daño que tiene en cuenta el

impacto de la intrusión y de la respuesta, y en función de la relevancia del activo, aplica la métrica de

mínimo coste o la de máxima eficiencia.

Al igual que ocurre con la métrica de fiabilidad del informe de intrusión, esta métrica pertenece al

conjunto de métricas que determinan directamente el comportamiento del razonador. Es decir, la

métrica da lugar a un conjunto de reglas o políticas utilizadas por el razonador del sistema en el

proceso de inferencia. En la sección 6.4.3 se incluye su especificación mediante reglas SWRL.

El resultado de la métrica se corresponde con la propiedad (relación) optimumResponse de la clase

FormattedIntrusion de la ontología.

6.4.3 Especificación de métricas de seguridad mediante reglas

SWRL

A lo largo del documento, se ha enumerado en varias ocasiones las ventajas de utilizar tecnologías

de la Web Semántica, como son las ontologías, los lenguajes de especificación del comportamiento y

los mecanismos de razonamiento, como núcleo del AIRS propuesto. El razonador es el componente

principal de la arquitectura del sistema y es el responsable de inferir la respuesta más adecuada

frente a una determinada intrusión. Para ello, aplica las métricas de inferencia de la respuesta óptima


212

propuestas en el apartado anterior (Ver 6.4.2). Estas métricas, por tanto, determinan el

comportamiento del sistema ya que constituyen una regla o política a seguir por el AIRS para

seleccionar la respuesta más adecuada en cada escenario de ataque. Por otra parte, en los Capítulos

3 y 4, se establece que el comportamiento del sistema se modela mediante reglas o políticas

especificadas en el lenguaje SWRL. Por ello, para que el razonador interprete las métricas de

respuesta que determinan la elección de la respuesta óptima, es necesario especificar dichas

métricas mediante reglas SWRL.

Además de las métricas de respuesta, la métrica que calcula la fiabilidad del informe de intrusión

también debe ser especificada mediante un conjunto de reglas SWRL.

Esta sección detalla la especificación de la métrica de fiabilidad del informe de la intrusión y de las

métricas de respuesta propuestas mediante reglas SWRL.

6.4.3.1 Métricas de fiabilidad del informe de intrusión

Para especificar la métrica de fiabilidad del informe de intrusión mediante SWRL, es necesario definir

un conjunto de reglas. Concretamente, la ontología incluye 8 reglas. A modo de ejemplo, se incluyen

las partes relacionadas con la métrica de dos de ellas:

ontAIRS:Context(?context),

ontAIRS:hasIntrusionType(?intrusion, ?threat),

ontAIRS:indicates(?context, ?threatCont),

ontAIRS:contextInformationDate(?syscontext, ?sysdate),

ontAIRS:intrusionDetectionTime(?intrusion, ?intdate),

equal(?sysdate, ?intdate),

SameAs (?threat, ?threatCont) ->

ontAIRS:intrusionAlertReliability(?intrusion, "high")

La regla establece que si el tipo de amenaza que incluye la alerta de intrusión (línea 2 de la métrica)

es igual al tipo de amenaza indicado por la variación de los indicadores del contexto de la red y de los

sistemas (línea 3), la fiabilidad del informe de intrusión es alta (línea 8). La condición de igualdad se

comprueba en la línea 7 de la regla, mediante el builtin SameAs incluido en la biblioteca de built-ins

de la TBox de SWRL.

Esta regla cubre las tres primeras filas de la métrica de fiabilidad propuesta (Ver 6.4.1.3) donde se

establece que si la amenaza indicada tanto por la anomalía en el contexto como en el informe de

intrusión es la misma, la confianza en la alerta es alta, independientemente de la confianza en el IDS.

Otro ejemplo, sería:

ontAIRS:NotThreat(?threatcon),

ontAIRS:SystemContext(?syscontext),


ontAIRS:indicates(?syscontext, ?threatcon),

ontAIRS:isGeneratedBy(?intrusion, ?ids),

ontAIRS:IDSconfidence(?ids, ?idsconf),



equal(?idsconf, "high"),

equal(?sysdate, ?intdate) ->


213

ontAIRS:intrusionAlertReliability(?intrusion, "medium")

Esta regla establece que si la alerta de intrusión incluye un tipo de amenaza o ataque específico

(línea 3 de la métrica), pero la anomalía del contexto no sufre variaciones y por tanto indica que no

existen síntomas de comportamiento anómalo en la red (líneas 1 y 4 de la métrica), la fiabilidad de la

alerta de intrusión será media (línea 11), siempre que la confianza en el IDS sea alta (líneas 5, 6 y 9

de la métrica).

La amenaza relacionada con la alerta de intrusión se denomina threat en la regla, la amenaza

indicada por el contexto es threatcon y la confianza en el IDS es referida como idsconf. La condición

de igualdad que compara el valor de la confianza en el IDS con el valor “high” se realiza mediante el

built-in de comparación de SWRL equal.

Esta regla cubre la fila 7 de la métrica de fiabilidad propuesta (Ver 6.4.1.3) donde se establece que si

la anomalía en el contexto no refleja ninguna amenaza y la confianza en el IDS es alta, la fiabilidad

del informe de intrusión será media.

De la misma forma, se han especificado las otras seis reglas SWRL que cumplen la métrica de

fiabilidad propuesta.

6.4.3.2 Métricas de inferencia de respuesta óptima

De las métricas de seguridad especificadas en este capítulo, las métricas de respuesta son

especialmente relevantes en el proceso de inferencia, como se observa en el diagrama de decisión.

Por tanto, el objetivo de este apartado es especificar las tres métricas de respuesta propuestas

mediante reglas SWRL [Mateos12].

Métrica de reducción de daño

La métrica de reducción de daño se ha especificado mediante SWRL de la siguiente forma:

ontAIRS:realintrusionImpact(?intrusion, ?intimpact),

ontAIRS:responseImpact(?respon1, ?resimpact1),

lessThanOrEqual(?resimpact1, ?intimpact)

La regla establece que si el impacto de la acción de respuesta es menor o igual que el impacto real

de la intrusión detectada, la respuesta cumple lo establecido por la métrica de reducción de daño y

por tanto, puede ser inferida por el sistema como respuesta óptima. Para ello se utilizan las

propiedades realintrusionImpact de la clase FormattedIntrusion y responseImpact de la clase

Response de la ontología y el built-in lessThanOrEqual.

Esta métrica no depende del nivel de importancia del recurso comprometido, y el valor de la

propiedad realintrusionImpact es el resultado de multiplicar el impacto de la intrusión por el grado de

confianza en el IDS que generó la alerta, y la fiabilidad del informe de intrusión. No obstante, en la

ontología se almacena tanto el valor total del impacto de la intrusión en cada escenario de ataque,

como el valor del impacto.

Métrica de mínimo coste

De la misma manera, la expresión de la métrica de mínimo coste especificada mediante SWRL es:

ontAIRS:hasTarget (?intrusion, ?target),

ontAIRS:assetLevelOfImportance(?target, ?cloi),

equal(?cloi, “low”),

ontAIRS:responseCost(?respon1, ?respcost1),

ontAIRS:responseCost(?respon2, ?respcost2),

lessThanOrEqual(?respcost1, ?respcost2),


214

→ ontAIRS:optimumResponse(?intrusion, ?respon1)

En la definición de la métrica se indicó que el AIRS basado en ontologías sólo aplica esta métrica

bajo una condición: que el recurso comprometido sea de nivel de importancia bajo para la

organización. Esta condición se comprueba en las primeras tres líneas de la regla SWRL, donde se

impone la restricción de que el valor de la propiedad assetLevelOfImportance debe ser “low”.

Las líneas 4, 5 y 6 tienen como objetivo la especificación de la propia métrica, es decir, inferir como

óptima aquella respuesta que minimice el coste derivado de su ejecución, tal como se explica en

6.4.2.2. Para ello se comparan los valores de la propiedad responseCost de dos individuos de la

clase Response.

Como resultado, el AIRS infiere la respuesta con coste más bajo del conjunto de recomendadas,

como respuesta óptima (línea 7 de la regla).

Métrica de máxima severidad y máxima eficiencia

La regla SWRL que especifica esta métrica es la siguiente:

ontAIRS:hasTarget(?intrusion, ?target),

ontAIRS:assetLevelOfImportance(?target, ?cloi),

equal(?cloi, “high”),

ontAIRS:intrusionSeverity(?intrusion, ?intseverity),

ontAIRS:responseSeverity(?respon1, ?respabsseverity1),

ontAIRS:responseSeverity(?respon2, ?respabsseverity2),

greaterThanOrEqual(?respabsseverity1, ?intseverity),

greaterThanOrEqual(?respabsseverity2, ?intseverity),

ontAIRS:responseRelSeverity(?respon1, ?rrsev1),

ontAIRS:responseRelSeverity(?respon2, ?rrsev2),

greaterThan(?rrsev1, ?rrsev2)

→ ontAIRS:optimumResponse(?intrusion, ?respon1)

La condición de aplicación de esta métrica es que el recurso atacado debe ser muy relevante para la

organización, es decir, el valor de la propiedad assetLevelOfImportance debe ser “high”. Esta

condición se comprueba en las primeras tres líneas de la regla. De la línea 4 a la 8, se comprueba

que la severidad de la respuesta es superior o igual a la severidad de la intrusión. Para ello, se

utilizan las propiedades intrusionSeverity y responseSeverity de las clases FormattedIntrusion y

Response de la ontología, y la restricción numérica de SWRL, greaterThanOrEqual.

El objetivo de las líneas 9 a la 11 es maximizar la ecuación de la métrica de máxima severidad y

máxima eficacia. Para ello, se obtiene el valor de la tasa de éxito de cada respuesta incluida en el

conjunto de respuestas recomendadas, que se representa en la ontología con la propiedad

responseEfficiency. El valor de la eficiencia se multiplica por la severidad absoluta y se obtiene un

parámetro denominado severidad relativa, representado como responseRelSeverity. Es este

parámetro el que se compara.

En el Apéndice II se incluyen todas las reglas SWRL utilizadas por el AIRS basado en ontologías en

el proceso de inferencia de la respuesta óptima.


Esta sección ha tratado de definir y especificar un conjunto de métricas de seguridad que permiten

medir los parámetros críticos involucrados en el proceso seguido desde que uno de los IDSs de la


215

arquitectura de la red detecta una intrusión hasta que se evalúa el éxito o eficacia de la acción de

respuesta tras haber finalizado su ejecución. Estos parámetros son: confianza en el IDS, anomalía de

la red y de los sistemas en estado de intrusión, fiabilidad del informe de intrusión, nivel de importancia

de los activos del sistema, impacto de la intrusión, coste/ Impacto de una acción de respuesta,

efectividad de una acción de respuesta, respuesta óptima frente a una intrusión y continuidad del

ataque. Estos parámetros se corresponden con atributos (Datatype Properties) de las diferentes

clases de la ontología propuesta, y se incluyen en las reglas de inferencia que utiliza el AIRS para

inferir las respuestas recomendadas y la respuesta óptima.

Para la definición de estas métricas, en primer lugar, se han analizado las métricas propuestas en

otros AIRSs existentes para su posible utilización en el AIRS basado en ontologías. Del análisis

realizado, se extrae que ciertos parámetros involucrados en el proceso de inferencia de la respuesta

óptima, se pueden medir utilizando algunas de las métricas existentes. Por el contrario, hay otros

parámetros, como el grado de anomalía de la red y de los sistemas o la efectividad o éxito de una

respuesta, que requieren de la definición y especificación de nuevas métricas.

Por otra parte, se hace distinción entre dos tipos de métricas: aquellas que son ejecutadas de forma

externa o independiente por el propio AIRS de forma automática o por el administrador del sistema de

forma manual, cuyo resultado es un valor que se incluye en la ontología y en las reglas o políticas

utilizadas por el Razonador del sistema; y aquellas cuyo objetivo es determinar, en parte, el

comportamiento del AIRS. Las métricas pertenecientes a este último tipo, se han especificado

mediante reglas SWRL para lo que se ha evaluado la viabilidad de utilizar lenguajes de políticas y

reglas para especificar métricas de seguridad.

Como resultado del capítulo se obtienen 10 métricas de seguridad que permiten medir parámetros

como la confianza en el IDS, la eficiencia de la respuesta, etc., además de un conjunto de reglas

SWRL que especifican aquellas métricas de seguridad que determinan el comportamiento del

razonador. Especial relevancia cobran las métricas de inferencia de la respuesta óptima o

simplemente, métricas de respuesta.

En la Tabla 6.7, se resumen los resultados obtenidos, resaltando qué métricas se han reutilizado de

otros AIRSs, cuáles son resultado de una combinación o pequeña modificación de métricas ya

existentes, y cuáles son contribución original de la presente tesis. Además, se indica si la métrica se

especifica mediante reglas SWRL, quién es el encargado de ejecutarla y el resultado obtenido desde

el punto de vista de la propiedad equivalente de la ontología (entre paréntesis se indica el nombre de

la clase que constituye el dominio de la propiedad).

Tabla 6.7 Resultados de la propuesta de métricas de seguridad y su especificación mediante SWRL.

Procedencia Regla

SWRL Aplicación Resultado obtenido

Métrica de confianza en

el IDS

Métrica usada en

AAIRS y FAIR No

Administrador

/ AIRS

IDSconfidence

(IntrusionDetectionSystem)

Métrica de nivel de

anomalía de red y de

sistemas

Contribución

original No AIRS

networkAnomaly

systemStatus

systemActiveProcesses

systemZombieProcesses

systemNumberOfUsersLogged

systemFreeSpace

systemLatency

systemCPUUsage

systemSSHFailed

(NetworkContext y

SystemContext)

Métrica de fiabilidad

del informe de

Contribución

original Sí AIRS

intrusionAlertReliability

(FormattedIntrusion)


216

intrusión

Métrica de importancia

del active atacado MAGERIT No Administrador

assetLevelOfImportance

(Asset)

Métrica de impacto de

intrusión

Combinación:

MAGERIT,

POMDP y

Strasburg

No AIRS intrusionImpact


Métrica de coste de

despliegue de una

respuesta

POMDP No Administrador responseDeploymentCost

(Response)

Métrica de impacto de

acción de respuesta

Combinación:

MAGERIT,

POMDP y

Strasburg

No AIRS responseImpact (Response)

Métrica de éxito de

una acción de

respuesta

Contribución

original No AIRS responseEfficiency (Response)

Métrica de inferencia

de la respuesta

óptima

Contribución

original Sí AIRS

optimumResponse


Métrica de continuidad

o similitud de ataque

Modificación de

AAIRS No AIRS

isContinuationOf


La elección de la respuesta óptima depende de la calidad y precisión en la definición de estas

métricas de seguridad.

6.5 Conclusiones

Los objetivos de este capítulo son:

- Propuesta de métricas de seguridad que permiten medir parámetros involucrados en la

elección de la respuesta óptima frente a una intrusión, para los que no se han propuesto

métricas o estas son insuficientes.

- Propuesta de métricas para la inferencia de la respuesta óptima frente a una intrusión, que

son ejecutadas por el AIRS de forma dinámica en función del escenario de intrusión

específico en cada momento.

- Especificación de aquellas métricas de seguridad que determinan el comportamiento del

razonador, como son las métricas de respuesta, mediante reglas SWRL.

Además, en el capítulo se indican aquellas métricas propuestas por otros sistemas de respuesta

frente a intrusiones, que son utilizadas en el AIRS basado en ontologías. Un análisis de las métricas

existentes se incluye en el Capítulo 2. Este análisis nos ha permitido la reutilización de algunas de las

métricas propuestos en estos sistemas para medir parámetros involucrados en el proceso de

inferencia de la respuesta del AIRS basado en ontologías.

La Tabla 6.7 incluye los resultados de la propuesta de métricas de seguridad y su especificación

mediante SWRL.

Capítulo 7: Propuesta de una Metodología para la Evaluación del éxito de una Acción de Respuesta

217

PROPUESTA DE UNA METODOLOGÍA Capítulo 7

PARA LA EVALUACIÓN DEL ÉXITO DE UNA

ACCIÓN DE RESPUESTA

7.1 Introducción

En el Capítulo 2 se establece la adaptabilidad como uno de los requisitos deseables en un AIRS,

entendiendo por adaptabilidad la capacidad del sistema para adaptar automáticamente la selección

de la respuesta en función de factores externos, tales como la eficacia o eficiencia de las acciones de

respuesta ejecutadas previamente o cambios que se produzcan en el entorno.

Por otra parte, otro requisito deseable es que el sistema de respuesta utilice el modelo sensible a

costes en la elección de la respuesta óptima, cuyo objetivo es asegurarse de inferir una respuesta

capaz de mitigar la intrusión pero sin sacrificar el funcionamiento habitual del sistema comprometido.

Este modelo trata de hacer un balance entre el coste, impacto y beneficio de la respuesta y el coste

de la intrusión, y uno de los factores a tener en cuenta es el nivel de éxito o eficacia de las respuestas

ejecutadas previamente.

Tanto para satisfacer el requisito de adaptabilidad como el de consideración del impacto de la

respuesta, la eficacia o éxito de las respuestas en sus anteriores ejecuciones es un factor relevante,

por lo que queda patente la necesidad de métricas y mecanismos consistentes y estandarizados que

evalúen dicha tasa de éxito o fracaso de una forma automática y precisa.

En el Capítulo 2 sección 2.5, se muestra un análisis comparativo de los mecanismos o metodologías

utilizados en los distintos AIRSs existentes para evaluar el éxito de una acción de respuesta

previamente inferida y ejecutada por el sistema de respuesta. Como conclusión se extrae que la

mayoría de los sistemas de respuesta evaluados o no tienen en cuenta la eficacia de la respuesta en

la elección de la respuesta óptima (el 50% de los sistemas) o la tienen en cuenta pero o no

especifican ninguna métrica o metodología para medirla o su valor lo fija el administrador de la red de

forma manual (el 33% de los sistemas analizados).

Ante esta problemática, el presente capítulo propone una metodología que permite medir de forma

automática y cuantitativa el éxito de una acción de respuesta previamente inferida y ejecutada por un

sistema de respuesta a intrusiones automático, y tener en cuenta el valor obtenido en posteriores

inferencias. Por tanto, como contribuciones originales de esta tesis doctoral:

- Se propone una metodología de evaluación del éxito de una acción de respuesta que

cuantifique dicho valor de una forma automática y sin intervención del administrado del

sistema.


218

- Se propone un diseño de arquitectura para un sistema de evaluación que implemente y

ejecute la metodología propuesta. Este sistema será integrado en la arquitectura del AIRS

basado en ontologías, lo que dotará al sistema de respuesta del requisito de adaptabilidad.

7.2 Metodología

Una vez presentada la problemática a afrontar, se abordará la propuesta siguiendo la siguiente

metodología:

Propuesta: Definición y especificación de una metodología de evaluación del éxito de una

acción de respuesta ejecutada por un sistema de respuesta automático frente a intrusiones.

El valor de éxito o eficacia obtenido es utilizado por las métricas de respuesta del AIRS

basado en ontologías, lo que lo convierte en un parámetro relevante y de gran importancia en

el proceso de inferencia de la respuesta óptima frente a una intrusión. A lo largo del capítulo

se propondrá el uso del concepto de entropía cruzada de Renyi utilizado en teoría de la

información, para evaluar la variación de la anomalía del estado de la red y los sistemas. La

descripción detallada de esta propuesta se encuentra en la Sección 7.1.

Análisis y evaluación de alternativas: se analizan las ventajas y desventajas de los

distintos mecanismos de evaluación automática del éxito de las acciones de respuesta

presentados y analizados en el Capítulo 2, así como otras aproximaciones propuestas en

ámbitos distintos al analizado, para su posible utilización e integración en el AIRS basado en

ontologías, como metodología de evaluación automática, precisa y eficaz. Además, se

evalúan métodos y algoritmos matemáticos, útiles para resolver la problemática presentada

en la introducción de la propuesta. Como resultado se selecciona la alternativa que se

considere más apropiada para desarrollar la presente propuesta. Esta evaluación de

alternativas se encuentra en la Sección 7.3

Formalización: Diseño detallado de la metodología propuesta y diseño de una arquitectura

de sistema de evaluación del éxito de una acción de respuesta que utiliza dicha metodología.

Este sistema de evaluación se integrará en la arquitectura del AIRS basado en ontologías. La

metodología se detalla en la Sección 7.4.

Verificación y Validación: Comprobación de que la metodología y su integración en el

sistema son técnicamente viables y validación de los resultados que producen, mediante

casos de aplicación. Esta validación se presenta en el Capítulo 8.

7.3 Análisis y evaluación de alternativas

Como se indica en la introducción del capítulo, en el Capítulo 2, apartado 2.5 de esta memoria de

tesis, se presenta un análisis del estado del arte en cuanto a los mecanismos de evaluación del éxito

de la respuesta que utilizan los AIRSs existentes. Del análisis realizado se concluye que la mayoría

de los sistemas de respuesta evaluados o no tienen en cuenta la eficacia de la respuesta en la

elección de la respuesta óptima (el 50% de los sistemas) o la tienen en cuenta pero o no especifican

ninguna métrica o metodología para medirla o su valor lo fija el administrador de la red de forma

manual (el 33% de los sistemas analizados).

Tan sólo dos sistemas de respuesta (ADEPTS y el AIRS propuesto por Jahnke) de los doce

analizados proponen un mecanismo para evaluar la eficacia de la acción de respuesta elegida por el

sistema para mitigar la intrusión. En el caso de ADEPTs se basa en calcular la probabilidad de que el

ataque alcance el siguiente nodo en su grafo I-GRAPH; cuanto más alta sea la probabilidad, significa

que el ataque no ha sido mitigado y por tanto la respuesta no ha tenido éxito. La metodología

propuesta por Jahnke se basa en analizar los grafos de accesibilidad, de confidencialidad y de

integridad del sistema comprometido antes y después de la respuesta, de forma que si la variación es

positiva se considera que la respuesta ha sido exitosa. Ambas metodologías son propuestas muy


219

interesantes que podrían integrarse en el AIRS basado en ontologías como mecanismo de evaluación

del éxito de la respuesta. Sin embargo, presentan estos inconvenientes:

- El mecanismo utilizado por ADEPTS está totalmente adaptado al modelo de grafos en el que

se basa el propio sistema de respuesta, y su uso es exclusivo para sistemas de respuesta

con la misma arquitectura, lo que limita y dificulta su integración en el sistema de respuesta

basado en ontologías propuesto. Una adaptación de esta metodología para su utilización en

el AIRS propuesto tampoco sería viable puesto que habría que modificar la arquitectura del

sistema casi por completo.

- El mecanismo propuesto por Jahnke, podría adaptarse sin problema al AIRS basado en

ontologías, pero en su trabajo los autores describen un método para evaluar la disponibilidad

de un sistema (dando como resultado un valor entre 0 y 1), pero no hacen referencia al

método utilizado para obtener el grado de confidencialidad ni de integridad. Ambos son

parámetros difíciles de cuantificar de forma automática e instantánea por un sistema, lo que

dificulta la tarea de obtener el nivel de éxito de una acción de respuesta mediante la

comparación de la confidencialidad e integridad del componente comprometido antes y

después de su aplicación. Por ello, se descarta la utilización de esta metodología en el

sistema de respuesta propuesto.

Además de los mecanismos de evaluación integrados en los AIRSs analizados, existen otras

propuestas de metodologías, métricas o algoritmos cuyo objetivo es evaluar el éxito o fracaso de una

determinada “acción”, ya sea en el área de la seguridad informática o en áreas muy dispares como la

medicina o la epidemiología. En el Capítulo 2 se describieron algunas de las propuestas existentes

hasta la fecha. A continuación se analizan brevemente cada una de ellas para estudiar la posibilidad

de adaptarlas o de aplicar los conceptos clave de su funcionamiento para la definición de una

metodología de evaluación automática del éxito de una acción de respuesta frente a intrusiones.

En [Kanoun09], se propone un método que consiste en utilizar modelos dinámicos de Markov para

evaluar la evolución de un ataque y calcular su probabilidad de éxito. Podría extrapolarse el método

utilizado y adaptar el mecanismo propuesto para calcular la probabilidad de éxito de una reacción de

respuesta. Pero al analizar en profundidad la metodología se ponen de manifiesto varias diferencias

importantes que hacen inviable su adaptación para calcular la probabilidad de éxito de una acción de

respuesta. En la primera fase se genera un grafo de ataque construido a partir de la descomposición

del ataque en objetivos más pequeños, en hitos a cumplir, que posteriormente se transforma en

modelos dinámicos de Markov que tienen en cuenta la evolución de los ataques y la evolución del

estado; por último, se ejecuta una métrica de probabilidad de éxito que determina cual es el estado

más probable en el que estará el ataque en el instante inmediatamente posterior. Desde su definición,

esta metodología está orientada a la predicción de ataques, a la detección temprana, para mitigarlos

lo antes posible, y su funcionamiento se basa en detectar la probabilidad de pasar de un estado a

otro, cuando el ataque aún no ha finalizado. En el caso de la reacción de respuesta, en primer lugar el

objetivo no es predecir la reacción de respuesta, ni evaluar cuál será su siguiente estado más

probable; el objetivo es calcular la probabilidad de éxito de la respuesta pero cuando esta ya ha

finalizado. Por ello, no es posible adaptar el trabajo presentado por Kanoun para definir la

metodología de evaluación propuesta.

En [Shameli-Sendi13], proponen un mecanismo de análisis de riesgos dinámico para determinar el

éxito de una acción de respuesta, que consiste en comparar el riesgo del sistema antes y después de

su ejecución. Uno de los inconvenientes de esta metodología es que en la reducción del riesgo de un

activo incluyen más factores que la aplicación de una acción de respuesta, por lo que los resultados

obtenidos pueden resultar erróneos.

En medicina o epidemiología existen una gran cantidad de métricas para evaluar la eficacia de una

acción preventiva, como puede ser una campaña de vacunación. Los mecanismos descritos se

podrían aplicar a la evaluación de la eficacia de una acción de respuesta a intrusiones, pero debido a

la magnitud y diversidad de trabajos, se propone como trabajo futuro a este trabajo de investigación el


220

estudio, análisis y evaluación de mecanismos utilizados en el ámbito de la medicina o existentes en la

naturaleza y la biología para evaluar el éxito de una acción o reacción, y estudiar su aplicación al área

de las respuestas automáticas frentes a intrusiones.

Tras el análisis recogido en los párrafos anteriores, se concluye que existen bastantes trabajos de

investigación centrados en definir y especificar mecanismos de evaluación del éxito de las

respuestas, pero no es adecuado usar ninguno de ellos como mecanismo de evaluación de la eficacia

de la respuesta del AIRS basado en ontologías. Por tanto, queda patente la necesidad de definir e

implementar una metodología de evaluación, objetivo de este capítulo.

Por otra parte, como se ha indicado en varias ocasiones a lo largo de la memoria, la información

proporcionada por indicadores del contexto tanto de la red como de cada uno de los sistemas que

forman parte de la arquitectura de la red, tiene especial importancia en el funcionamiento del AIRS

basado en ontologías. En el Capítulo 4 se discute cómo se utiliza la variación del estado de la red y

de los sistemas en un determinado momento con respecto a su estado de funcionamiento habitual,

para determinar que se está produciendo un comportamiento anómalo, que por lo general es

consecuencia de una actividad maliciosa intencionada. Esta variación del estado se traduce en un

grado de sospecha y anormalidad, que es utilizado por el sistema para por un lado corroborar el tipo

de intrusión proporcionado por el IDS, y por otro, inferir las respuestas recomendadas para hacer

frente a la intrusión detectada.

Si la presencia de una intrusión en una organización se traduce en una variación del estado de la red

y del sistema atacado respecto a su estado de funcionamiento normal (el grado de anomalía

aumenta), se puede afirmar que la aplicación de una acción de respuesta que mitigue la intrusión se

traducirá en otra variación del estado de la red, que devolverá al sistema o la red a un estado similar

al de su funcionamiento habitual (grado de anomalía respecto al estado de intrusión disminuye),

siempre que la respuesta consiga mitigar por completo el ataque. Si sigue habiendo indicios de

actividad maliciosa, la respuesta no es eficaz contra la intrusión y el estado de la red respecto a la

situación de ataque no variará.

Por ello, se propone utilizar la variación entre el grado de anomalía existente en presencia de

intrusión, y el grado de anomalía existente tras aplicar la acción de respuesta, como indicador del

éxito o eficacia de la reacción. Cuánto más se acerque el grado de anomalía tras finalizar la

respuesta a 0, más seguridad hay de que la respuesta ha sido eficaz, y por tanto el ataque ha

remitido.

Cabe aclarar que no todos los indicadores de contexto varían de la misma forma ante la presencia de

una intrusión, es decir, en función del tipo de intrusión, hay parámetros que varían mucho, otros

sufren pequeñas variaciones e incluso otros no se ven alterados.

Para modelar esta variación se podrían utilizar funciones lineales simples, como por ejemplo la

diferencia de la anomalía total antes y después de ejecutar la respuesta. Esta anomalía total sería

calculada como la suma de las anomalías parciales de cada uno de los indicadores del contexto,

cuyos valores oscilan entre 0 y 10. Por ello, la variación de la anomalía total tendría como valor un

número natural entre -90 y 90. Este resultado calculado de esta forma no proporciona ninguna

información relevante, por lo que el uso de métodos lineales sencillos no es suficiente para modelar

los cambios en la anomalía del contexto de la red.

Una alternativa es la utilización del concepto de entropía, ampliamente usado para analizar los datos

y detectar anomalías en seguridad de la información. En teoría de la información, la entropía es un

término ampliamente utilizado para describir la incertidumbre asociada a una variable aleatoria.

Desde que fue presentada por primera vez por Claude Shannon en su artículo, “A Mathematical

Theory of Communication” [Shannon48] en 1948, la entropía ha ganado importancia y su uso es cada

vez más común en sistemas de comunicaciones y en tecnologías de la información. En su trabajo,

Shannon introduce el famoso término de entropía H tal y como se conoce en la teoría de la


221

información. Sea una variable aleatoria discreta X con valores posibles {x1, x2, …, xn},y la función de

probabilidad p(X), Shannon define la entropía de la variable X como:

( ) ∑ (7.1)

[ ]

donde pi es la probabilidad de xi en X.

La entropía de Renyi es una generalización de la entropía de Shannon, cuyo objetivo es cuantificar la

diversidad o incertidumbre de un sistema, y evaluar la similitud entre diferentes distribuciones. La

entropía de Renyi de orden α se define como:

( )

∑

(7.2)

Donde 0 < α < 1, P es una variable aleatoria discreta y pr es la función de distribución de P,

[Pfister04]. Cuanto más se acerca α a 1, más determinada estará la entropía de Renyi por los eventos

cuya probabilidad es más alta. En caso contrario, cuanto más se acerca α a 0, la entropía resultante

tendrá en cuenta los pesos de todos los eventos posibles de una forma equitativa, con independencia

de sus probabilidades. La entropía de Shannon es un caso especial, en el que α 1.

Partiendo de la expresión anterior, se define la entropía cruzada de Renyi de orden α como:

( )

∑

(7.3)

Donde p y q son dos variables discretas, y pr y qr son sus funciones de distribución. Si α = 0.5, la

entropía cruzada de Renyi es simétrica, y por tanto Iα (p,q) = Iα (q,p). La entropía de Renyi en el caso

simétrico, tiene la siguiente expresión:

( ) ∑ √ (7.4)

El uso de la entropía cruzada de Renyi para evaluar el cambio producido en una variable aleatoria

discreta en un instante t con respecto a instantes anterior t-i está bastante extendido. Así por ejemplo,

en [Liu12] se utiliza la entropía cruzada de Renyi para evaluar los cambios producidos en el estado de

la red entre un instante t y un instante en el que no hay signos de intrusión, para detectar ataques de

red de una forma eficaz y reducir el número de alertas falsas que tienen otros IDSs. Lakhina et al.

[Lakhina05] exponen que el uso de la entropía de Shannon como herramienta para analizar el tráfico

de dos redes troncales, permite detectar la presencia de una gran cantidad de anomalías. En [Yan09]

los autores utilizan la entropía cruzada de Renyi para analizar una matriz de tráfico que representa el

estado de la red y detectar anomalías. En concreto, concluyen que el uso de la entropía cruzada de

Renyi para la detección de ataques DDoS proporciona una mayor tasa de detección y menores falsos

positivos que la entropía de Shannon.

En este capítulo de la presente Tesis Doctoral se propone una metodología de evaluación de la

eficacia de una acción de respuesta que se basa en analizar la variación del grado de anomalía del

contexto de la red y del sistema comprometido antes y después de ejecutar la respuesta. Se propone

el uso de la entropía cruzada de Renyi para modelar estos cambios de contexto producidos tanto a

nivel de red como de sistemas. Si definimos cada uno de los nueve parámetros de contexto

mencionados como una variable aleatoria discreta y observamos su evolución en el tiempo, la

variación entre la entropía cruzada de Renyi de cada uno de los parámetros antes y después de la

ejecución de la respuesta con respecto al instante de no intrusión, será un perfecto indicador del éxito

o fracaso de la respuesta. En la siguiente sección se describe con detalle la metodología propuesta,


222

la arquitectura del sistema de evaluación que deriva de la metodología, así como su integración en el

AIRS basado en ontologías propuesto en capítulos anteriores.

7.4 Propuesta de metodología de evaluación de la eficacia de

una acción de respuesta frente a intrusiones mediante

entropía y variación del contexto

En este capítulo se propone una metodología basada en el concepto de entropía cruzada de Renyi

para la evaluación del éxito de las acciones de respuestas inferidas y posteriormente ejecutadas por

el AIRS basado en ontologías propuesto. El objetivo es diseñar e implementar un método de

evaluación capaz de mantener una matriz de éxito que contiene la tasa de éxito de cada respuesta

ejecuta por el sistema, y actualizar automáticamente dicha matriz cada vez que finalice el despliegue

de una acción de respuesta. La información de la matriz de éxito es utilizada en el mecanismo de

selección de la respuesta óptima presentado en capítulos anteriores. Con el fin de evitar

ambigüedades, el término “evaluación” utilizado en este capítulo se refiere exclusivamente a la

evaluación de la tasa de éxito o eficacia de las acciones de respuesta.

7.4.1 Definición de la metodología propuesta

La metodología propuesta se basa en analizar la variación de la anomalía producida en el contexto de

la red y del sistema comprometido antes y después de la aplicación de la acción de respuesta, cuyo

éxito o eficacia se pretende calcular. Para modelar los cambios producidos en el contexto se propone

el término “Context Entropy Variance”.

Este enfoque cuantitativo propuesto consta de 4 fases:

- Cálculo de la varianza de la entropía cruzada de Renyi: en primer lugar se compara la

anomalía existente en el contexto de la red y del sistema comprometido, antes y después de

la ejecución de la respuesta mediante una metodología basada en el concepto de la entropía

cruzada de Renyi utilizado en teoría de la información. En esta fase se propone el término

Context Entropy Variance para modelar los cambios producidos.

- Establecimiento de umbrales: el objetivo de esta fase es determinar unos valores máximo y

mínimo de varianza de entropía del contexto para reducir al mínimo errores producidos por

cambios en el contexto, relacionados con otros posibles eventos que son independientes de

la intrusión detectada. Al reducir la tasa de error, se aumenta la precisión y fiabilidad del

sistema de evaluación. Estos umbrales, como se verá más adelante en este capítulo, se fijan

antes de integrar el sistema de evaluación en el AIRS, en la denominada fase de

entrenamiento. Para ello, se definen dos conjuntos de entrenamiento compuestos por

diferentes respuestas para cada tipo de intrusión. Una vez tomados datos suficientes y

establecidos un umbral máximo y mínimo, en la fase de ejecución del AIRS, se compara la

varianza de la entropía calculada en la fase anterior con los umbrales fijados.

- Cálculo del nivel de éxito: en esta fase, el sistema utiliza una función a trozos que mapea la

varianza de la entropía de contexto obtenida después de la ejecución de una respuesta a un

nivel de éxito, con el fin de reducir la incertidumbre en el proceso de evaluación. En esta fase

se determina si la respuesta ha sido exitosa o no en el momento actual, en esta iteración del

proceso.

- Obtención de la tasa de éxito o eficacia de la respuesta: por último, utilizando el nivel de éxito

obtenido en la fase anterior, se actualiza la tasa de éxito de la respuesta, que indica el

número de veces que ha sido exitosa con respecto al total de veces que ha sido ejecutada.


223

En la siguiente figura se muestran las 4 fases en las que se divide la metodología propuesta para

evaluar el éxito de una acción de respuesta:

Figura 7.1 Fases de la metodología de evaluación del éxito de la respuesta propuesta.

A continuación se detalla cada una de las fases de la metodología.

7.4.1.1 Varianza de la entropía del contexto: “Context Entropy

Variance”

Este paso consiste en la comparación de la anomalía del contexto de la red y del sistema en dos

momentos relevantes, definidos como T1 y T2, donde T1 es el momento en el que el AIRS recibe un

nuevo informe de intrusión procedente del IDS y comienza el proceso de inferencia, y T2 es el

momento en el que la respuesta inferida termina su ejecución. Para ello se propone el uso de una

función no lineal que proporciona como resultado la varianza de la entropía cruzada de Renyi del

contexto (Context Entropy Variance), parámetro al que se hará referencia en ecuaciones posteriores

como ∆Ioverall. Este parámetro indica cuánto ha variado la anomalía total del contexto entre ambos

instantes y dependerá de la variación de la anomalía en cada uno de los nueve indicadores de

contexto especificados: Status (representa la anomalía en el estado del sistema comprometido),

Latency (se corresponde con la anomalía en la latencia del sistema), CPU (anomalía producida en el

uso de la CPU con respecto a un funcionamiento normal del sistema), Disk (representa la anomalía

en el espacio libre en disco del sistema comprometido), Process (anomalía en el número de

procesos activos), Zombie (representa el grado de anomalía con respecto al número de procesos

Zombie en estado normal de funcionamiento), User (número de usuarios que están usando el

sistema), SSHFailed (anomalía en la conexión por SSH), y Network (representa el grado de

anomalía en el contexto de red. El valor de estos parámetros es un número entero comprendido entre

0 y 10 que es proporcionado por los módulos de contexto de la arquitectura del AIRS siguiendo el

procedimiento descrito en el Capítulo 4.

En primer lugar, se representa cada uno de los nueve indicadores de anomalía como una variable

aleatoria discreta. Así por ejemplo, para la anomalía en la latencia del sistema, se define la variable

Alatency como:


224

Sea Alatency (t) la anomalía en la latencia de un sistema en el instante t. De esta forma, esta

anomalía puede ser vista como una serie temporal Alatency(T0), Alatency (T0+1)…, Alatency(T1),

….Alatency(T2),…Alatency(T0+n).

El objetivo de esta fase es determinar la variación producida en la anomalía de la red y del

funcionamiento de los sistemas entre T2 y T1. Para ello, se calcula el cambio existente en cada uno de

los indicadores de anomalía entre el tiempo T1 y el tiempo T0, por un lado, y entre T2 y T0 por otro,

para lo que se aplica la ecuación de la entropía cruzada de Renyi. T0 es un momento en el que la red

y los sistemas están funcionando de forma normal, sin ser objeto de ningún ataque o intrusión, por lo

que en T0 el grado de anomalía en cada uno de los indicadores es nulo.

Siguiendo con la anomalía en la latencia como ejemplo, la entropía cruzada de Renyi de Alatency (T1)

y Alatency (T0) es:

( ( ) ( )) ∑ √ ( ) ( ) (7.5)

De la misma forma, se calcula el cambio producido en la anomalía de la latencia entre T2 y T0:

( ( ) ( )) ∑ √ ( ) ( ) (7.6)

Como se observa, se utiliza la expresión de la entropía cruzada de Renyi cuando esta es simétrica,

ya que Iα (Alantency(T0),Alatency(T1)) = Iα (Alantency(T1),Alatency(T0)), por lo que α = 0.5.

El siguiente paso es calcular la variación entre ambos valores de entropía obtenidos, lo que nos

servirá para determinar el cambio en el contexto de la red y del sistema entre T2 y T1. Para facilitar su

manejo, se normalizan ambos resultados respecto a I0.5(Alatency(T0), Alatency(t))MAX. Por tanto,

( ( ) ( )) ( ( ) ( )) (7.7)

De la misma forma, se obtiene la varianza de la entropía cruzada de Renyi de los otros ocho

indicadores: IStatus, ICPU, IDisk, IProcess, IUser, IZombie, ISSH y HNetwork.

Por último, se obtiene la varianza de la entropía global, Ioverall:

∑ (7.8)

donde, wi es el peso asociado a cada indicador, es decir, el peso que tiene la variación de cada

indicador en la variación de la anomalía global. Estos pesos están relacionados con el tipo de

intrusión, ya que en función de la intrusión hay indicadores cuya fluctuación es elevada e indicadores

que no se ven afectados. En un escenario en el que todas las variaciones influyen de una forma

equitativa en el resultado final, los pesos serían, WStatus = WLatency = WCPU = WDisk = WProcess =

WUser = WZombie = WSSH = WNetwork =

El valor de I es un valor entre -1 y 1 que indica el cambio producido en el estado de la red y

del sistema como consecuencia de la ejecución de una determinada acción de respuesta.

En lugar de calcular la entropía cruzada de Renyi de cada uno de los indicadores de forma

independiente y obtener la variación de la entropía global como la suma de las variaciones parciales,

se podría haber definido un vector de anomalía formado por nueve variables aleatorias (una por cada

indicador) y haber calculado la variación de la entropía global como la variación de la entropía

cruzada de Renyi de dicho vector entre T2 y T1. Pero en este caso, la contribución de cada variable al


225

cambio global del estado del sistema sería uniforme, es decir, todos los indicadores influirían de la

misma manera al resultado final, lo que introduciría cierto error en algunos escenarios de intrusión.

7.4.1.2 Establecimiento de umbrales: “Setting thresholds”

Una vez calculada la variación de la entropía cruzada de Renyi del contexto, el siguiente paso tiene

como objetivo relacionar este valor con el nivel de efectividad, es decir, el objetivo es cómo usar el

valor obtenido. Para ello, se propone establecer dos umbrales óptimos (uno superior y otro inferior), y

comparar en tiempo real la variación de la entropía de contexto obtenida con los umbrales

establecidos. De esta forma el sistema de evaluación determinaría si una respuesta ha sido exitosa,

no ha tenido efecto o, en caso extremo, ha sido perjudicial para el sistema.

Esta fase se encarga de establecer los umbrales óptimos superior e inferior que se utilizarán como

referencia en el siguiente paso. Para ello, se entrena el sistema de evaluación antes de su integración

y ejecución en el AIRS basado en ontologías. El primer paso de esta fase de entrenamiento consiste

en definir dos conjuntos de entrenamiento para cada tipo de intrusión:

- Conjunto de entrenamiento exitoso: conjunto compuesto por todas las acciones de

respuestas incluidas en el catálogo del AIRS que pueden mitigar con éxito el tipo de intrusión

determinado. Este conjunto de entrenamiento se utiliza para la obtención del umbral alto.

- Conjunto de entrenamiento fallido: conjunto compuesto por aquellas acciones de respuesta

incluidas en el catálogo del AIRS que no tienen ningún efecto en la intrusión o este es

mínimo, y por tanto, no la mitigan ni reducen su impacto. Este conjunto de respuestas se

utiliza para fijar el umbral bajo.

Sea un tipo de intrusión conocido por el sistema (Ver clase SpecificThreat de la ontología, Capitulo 5),

al que se denomina Threat1, y sea {R1, R2 •••Rn} el conjunto de entrenamiento exitoso compuesto por

n acciones de respuesta. Para cada respuesta del conjunto se simula la intrusión en un escenario de

prueba controlado y aislado para evitar la interferencia de posibles ataques externos en los

resultados, m veces. En cada simulación se calcula el valor de I siguiendo el procedimiento

descrito en la fase anterior, dando como resultado m*n valores de I , denominados como

Ios1 Ios2 ••• Iosm*n. Este conjunto se denominara a partir de ahora

I ( ).

( ) (7.9)

Sea un Ih específico del conjunto anterior, si la probabilidad de que cualquier Ii, i [1, m*n] sea

mayor o igual que Ih es superior a , [0,1], entonces se establece Ih como umbral de éxito

superior para la intrusión Threat1. En el escenario de pruebas utilizado para validar el sistema de

evaluación se ha fijado α a 0.8. La descripción matemática es la siguiente:

(7.10)

[ ] ( ) [ ]

De la misma forma, pero utilizando las respuestas incluidas en el conjunto de entrenamiento fallido,

se calcula el umbral inferior ThresholdLow :

(7.11)

[ ] ( ) ; [ ]


226

Si se lleva a cabo el procedimiento anterior para cada uno de los tipos de intrusión se obtendrán

tantos ThresholdHigh y ThresholdLow como tipos de intrusiones distintas maneje el sistema.

El establecimiento de los umbrales se lleva a cabo en un escenario de red experimental, que podría

diferir del escenario de red real en el que se aplicará la metodología de evaluación propuesta en este

apartado. Ambos escenarios están compuestos por diferentes sistemas y equipos que podrían tener

políticas de seguridad y requisitos de seguridad diferentes (por ejemplo, un sistema que aloja un

servidor de bases de datos muy sensibles para la organización requiere más seguridad que un host

de usuario cuya relevancia es menor factor). Este factor hay que tenerlo en cuenta a la hora de usar

los umbrales de éxito en la fase de producción o ejecución. Con ese propósito, se definen dos

parámetros denominados ModifyLow y ModifyHigh, que son establecidos por el administrador del

sistema, y cuyo objetivo es representar las diferencias existentes entre el escenario experimental

usado en la fase de entrenamiento para fijar los umbrales y los escenarios reales, en términos de la

diferencia que existe entre las políticas de seguridad de los sistemas o componentes que forman

parte de dichos escenarios. ModifyLow y ModifyHigh son factores de corrección que aumentan o

disminuyen los umbrales establecidos, proporcionando más precisión a la metodología de evaluación

de una respuesta.

Para cada escenario específico, el umbral final superior o Threshold2 y el umbral inferior o Threshold1

quedan determinados por las siguientes expresiones:

(7.12)

Threshold2 y Threshold1 son indicadores cuyo valor oscila entre -1 y 1 que ayudan al sistema de

evaluación a decidir por encima de qué valor de variación en el contexto se puede asegurar el éxito

de una respuesta, y por debajo de qué valor de variación se puede asegurar su fracaso. Esto es, si

tras ejecutar una acción de respuesta la variación producida en el contexto es mayor que Threshold2

se puede asegurar que la probabilidad de que la respuesta mitigue la intrusión es muy alta; por el

contrario, si esta variación es menor que Threshold1, la respuesta ha sido un fracaso.

Consideraciones adicionales

Como se indica en este apartado, el objetivo de esta fase es calcular un umbral de éxito superior o

inferior para cada tipo de intrusión conocida por el sistema de respuesta. Los tipos de intrusión

conocidos se representan en la ontología de respuesta a intrusiones como subclases de la clase

OWL SpecificThreat.

Pero puede darse el caso de que sea difícil determinar el tipo de intrusión de una alerta recibida, es

decir, el AIRS podría recibir alertas que indican que se está produciendo un comportamiento anómalo

en la red pero el tipo de intrusión no se corresponder con ninguno de los incluidos en la ontología, y

por tanto se clasificaría como indefinido. Ante esta situación, en la que se desconoce el tipo de

intrusión o es indefinido, resulta complicado clasificar las acciones de respuesta como parte del

conjunto de entrenamiento exitoso o fallido. Por ello, se define un único conjunto de entrenamiento

formado por todas las acciones de respuesta disponibles en el AIRS basado en ontologías. Este

único conjunto será utilizado para extraer tanto el umbral superior como el inferior, siguiendo el mismo

procedimiento que el explicado para un tipo de intrusión concreta.

7.4.1.3 Nivel de éxito: “Level of success”

En esta fase, se propone utilizar una función a trozos que mapea el valor de I obtenido en la

primera fase de la metodología al nivel de éxito. Se define el término RPE (Response Partial

Efficiency) como un indicador de la eficacia o el éxito de la respuesta tras finalizar cada una de sus

ejecuciones. La función que determina el valor de RPE es la siguiente:


227

{

( ) ( )

( ) ( ( ) ) [ ] (7.13)

{ ( ( ) )

(7.14)

Esto es, sea una acción de respuesta Respuestax que finaliza su ejecución en el instante T2 y cuyo

objetivo es mitigar la intrusión de tipo Threaty que se detecta en el instante T1. La función del nivel de

éxito especificada establece que:

- Si la variación de la entropía cruzada de Renyi de la anomalía del contexto entre T2

(momento después de ejecutar la respuesta) y T1 (momento de comienzo de inferencia) es

mayor o igual que el umbral de éxito superior establecido para Threaty, Threshold2, se puede

asegurar que la respuesta ha sido exitosa, asignando un 1 al valor de RPE. Esto indica que la

respuesta ha reducido de forma considerable el grado de anomalía de la red existente en el

momento de la intrusión.

- Si por el contrario, la variación de entropía de la anomalía del contexto entre T2 y T1 es menor

o igual que el umbral de éxito inferior Threshold1, indica que o bien la respuesta no tiene

efecto sobre la intrusión (variación de la anomalía nula) o incluso, es perjudicial para el

funcionamiento del sistema comprometido (en caso de que el grado de anomalía aumente y

sea mayor en T2 que en T1). En este caso se asegura que la respuesta ha fallado y no ha

cumplido su objetivo, asignándole a RPE el valor de 0.

No obstante, como se observa en la expresión que define la función, hay una segunda

condición para que se asegure el fallo de la acción de respuesta: la variación de la anomalía

entre el instante T2 y la anomalía existente en un estado de funcionamiento normal de la red

T0, debe ser mayor que un determinado número β, fijado previamente. Esta condición tiene

sentido en situaciones en las a pesar de que la variación en el grado de anomalía antes y

después de aplicar la respuesta es mínimo o nulo, la anomalía en el estado de la red y del

sistema comprometido tras aplicar la respuesta es muy similar a su estado de funcionamiento

normal, y por ello sería un error clasificar la respuesta como no exitosa.

Por tanto, la reacción de respuesta será considerada como un fracaso si su aplicación no

disminuye el grado de anomalía de contexto de forma considerable y además, esta anomalía

sigue siendo elevada con respecto al estado de funcionamiento normal de los sistemas.

- Si I tiene un valor comprendido entre los dos umbrales, resulta difícil determinar con

precisión si la variación producida es consecuencia de la aplicación de la respuesta o si se

debe a otros factores externos, por lo que no se puede asegurar con exactitud si la reacción

Respuestax es efectiva o no. Para estos casos en los que no hay indicios suficientes para

evaluar el éxito mediante la variación de la entropía de la anomalía de contexto entre T2 y T1,

se distinguen dos situaciones:

En caso de que la anomalía en el estado del contexto tras aplicar la respuesta sea

mínima respecto a su estado de funcionamiento normal, se puede asegurar que la

respuesta ha tenido éxito, y por tanto A=1, y en consecuencia RPE=1.

En cualquier otro caso, no es posible determinar con precisión si la respuesta ha sido

suficiente para mitigar la intrusión, en función de la variación de anomalía. Por ello,

A=RPE=1/2.

El valor absoluto de I calculado en la primera fase no es suficientemente preciso para indicar

por sí solo el nivel de éxito de una respuesta, debido a la incertidumbre que conlleva. Pero el uso de

la función a trozos definida en este apartado que combina dicho valor con los umbrales fijados en la


228

segunda fase permiten disminuir el nivel de incertidumbre y determinar con mayor precisión el

rendimiento de una respuesta.

Como resultado de esta fase se obtiene el valor específico de RPE asociado a la respuesta

Respuestax en un instante concreto. Este valor puede ser 1 (respuesta eficaz), 0 (respuesta ineficaz)

o ½ (nivel de éxito indeterminado), y es obtenido de forma independiente tras cada ejecución de la

respuesta, por lo que su valor también es independiente del valor de RPE en ejecuciones anteriores.

RPE indica el éxito de una respuesta en un instante, en una iteración del proceso de inferencia, pero

no refleja el comportamiento de la respuesta a lo largo del tiempo. Para ello, se define un nuevo

parámetro responseEfficiency o RTE (Response Total Efficiency) que representa la eficacia de una

determinada acción de respuesta desde que el AIRS se puso en funcionamiento hasta el momento

actual. La obtención de RTE es el objetivo de la cuarta y última fase de la metodología.

7.4.1.4 Tasa de éxito o efectividad de la respuesta

La última fase de esta metodología tiene como objetivo calcular la tasa de éxito de una acción de

respuesta, cuyo valor refleja el comportamiento de dicha acción de respuesta desde la primera vez

que fue ejecutada hasta el instante actual. Esta tasa de éxito será actualizada automáticamente por el

sistema de evaluación en esta última fase de la metodología, añadiendo el valor de RPE obtenido en

el paso anterior.

El parámetro responseEfficieny o RTE (Response Total Efficiency) es la variable propuesta para

representar la evolución en el tiempo del éxito de una respuesta y su expresión es la siguiente:

responseEfficiency (%) =

∑

(7.15)

donde, j es el número de veces que la respuesta evaluada ha sido inferida como respuesta óptima y

por tanto ejecutada; y RPEi es el valor de RPE asociado a la ejecución “i” de la respuesta.

Sea responseEffieciencyj la tasa de éxito de la respuesta Responsex tras j ejecuciones. Cuando el

AIRS infiere y ejecuta la misma respuesta la j+1 vez, calcula su valor de RPEj+1 correspondiente. A

continuación, el sistema debe actualizar la tasa de éxito incorporando el nuevo valor, de forma que:

( )

(7.16)

El objetivo de esta última fase así como el objetivo global de la metodología es obtener la tasa de

eficiencia o de éxito de cada acción de respuesta. Como se ha indicado esta tasa de éxito se

denomina responseEfficiency o RTE y es uno de los parámetros clave en el proceso de inferencia de

la respuesta óptima propuesto, por lo que en la integración del sistema de evaluación con el AIRS

basado en ontologías, tomará especial relevancia cómo se representa este parámetro en la ontología

de respuesta a intrusiones, cómo se actualiza su valor tras cada ejecución de una respuesta, etc. Las

interfaces entre el sistema de evaluación y el AIRS son claras y están bien definidas, como se explica

en secciones posteriores de este capítulo, lo que aumenta el rendimiento y precisión del sistema de

respuesta.

7.4.1.5 Consideraciones adicionales

En esta sección se propone una metodología que evalúa la eficacia de una acción de respuesta. Esta

metodología se basa en analizar la variación de la anomalía del contexto utilizando la entropía

cruzada de Renyi y otras funciones no lineales, como se ha explicado en este capítulo.

Pero en este punto de la memoria, es necesario tener en cuenta dos consideraciones para el óptimo

funcionamiento del sistema.


229

Consideración I: Intrusiones que no se reflejan en el contexto

Un perfecto indicador de que una intrusión o comportamiento anómalo está comprometiendo la

seguridad de una red o un sistema, es la variación que se produce en parámetros como la latencia, el

número de espacio libre en disco, el porcentaje de uso de la CPU, el número de paquetes IP

recibidos con la misma IP origen, etc. respecto al valor de estos parámetros en un estado de

funcionamiento habitual de la red o sistema. Por ello, la metodología de evaluación propuesta se basa

en este hecho.

Pero hay ciertos vectores de ataque, como por ejemplo, sniffing, cuya actividad maliciosa no se refleja

en los parámetros del contexto de la red o del sistema al que comprometen, y como consecuencia la

anomalía en el instante de detección de intrusión y tras la respuesta será similar y muy cercana a la

situación de funcionamiento normal del sistema. En este caso, la metodología propuesta sufre

pequeñas variaciones en cada una de sus fases:

- Fase 1 – Cálculo de la varianza de entropía del contexto: en esta fase, el grado de anomalía

en el contexto antes y después de ejecutar la respuesta será nulo porque los parámetros de

contexto no varían como consecuencia ni de la intrusión ni de la respuesta (en caso de variar,

se debe a factores externos. Por tanto, la variación de la entropía cruzada de Renyi de la

anomalía entre T1 (instante de detección de la intrusión y de comienzo de la inferencia) y T2

(momento tras finalizar la ejecución de la respuesta) será 0.

El método propuesto para calcular ∆Ioverall es el mismo que el explicado en 7.4.1.1, pero el

valor obtenido será siempre 0, independientemente de la reacción de la respuesta evaluada.

Por ello, carece de sentido obtener el valor de ∆Ioverall .

- Fase 2 – Establecimiento de umbrales: mismo caso que la fase anterior. El método propuesto

para el establecimiento de los umbrales es aplicable a este caso particular, pero el valor de

y para una intrusión que no modifica el contexto sería siempre

0. Por ello, no tiene sentido entrenar el sistema para fijar los umbrales de éxito superior e

inferior asociados a una intrusión de este tipo.

No tiene sentido

establecer umbrales.

- Fase 3 – Nivel de éxito: en esta fase se compara el valor de I obtenido en la primera

fase de la metodología con los umbrales de la fase 2, y como resultado se determina si la

respuesta ha sido exitosa (RPE = 1), no exitosa (RPE = 0) o no se puede determinar su

eficacia con precisión (RPE = ½).

Si la intrusión no modifica los indicadores del contexto y por tanto, carecen de sentido las dos

primeras fases de esta metodología, la función por trozos propuesta para obtener RPE no es

válida para este caso particular. Se propone una función que tiene en cuenta la existencia o

no de alertas relativas a la misma intrusión en instantes inmediatamente posteriores a la

aplicación de la respuesta:

{

( ( ) )

( ( ) )

(7.17)

- Fase 4 – Tasa de éxito o efectividad de la respuesta: esta fase no sufre variaciones respecto

a la explicada en 7.4.1.4. Una vez obtenido el valor de RPE, la forma en la que se calcula y

actualiza la tasa de éxito total de la acción de respuesta es la misma.

Como conclusión de esta consideración se extrae que en el caso de que la intrusión detectada no se

refleje en la variación de los parámetros del contexto, la metodología utilizada para evaluar el éxito de


230

la acción de respuesta se ve reducida a dos fases: cálculo del nivel de éxito en función de las alertas

recibidas, y obtención de la tasa de éxito.

Consideración II: inestabilidad de la tasa de éxito en estados iniciales

En la fase 4 de la metodología se define un valor que indica la tasa de éxito de cada acción de

respuesta, calculado como la media aritmética de los valores de RPE obtenidos tras cada ejecución

de la reacción. A este valor se le ha denominado como responseEfficiency o RTE.

Una vez integrado el sistema de evaluación en el AIRS basado en ontologías, el valor de RTE

obtenido en las primeras inferencias y ejecuciones de cada respuesta es inestable. Tras varias

ejecuciones, el sistema alcanza un estadio de estabilidad, y a partir de dicho momento una respuesta

es más eficiente cuanto más alto sea su valor de responseEfficiency asociado.

Se recomienda tener en cuenta esta consideración a la hora de utilizar el AIRS.

7.4.2 Diseño e implementación de un sistema que desarrolla la

metodología propuesta

Una vez definidas en profundidad las cuatro fases de la metodología de evaluación, el objetivo de

este apartado es presentar los aspectos más relevantes del diseño de la arquitectura de un módulo o

sistema de evaluación que la utiliza. Detalles sobre la implementación de cada componente presente

en la arquitectura, así como de su integración en el AIRS basado en ontologías se proporcionan en el

capítulo de validación (Ver 8.3).

7.4.2.1 Especificación de requisitos

En primer lugar se definen los requisitos del sistema de evaluación, teniendo en cuenta que éste tiene

dos modos de funcionamiento: modo de ejecución y modo de entrenamiento. Para facilitar la

comprensión e identificación de requisitos se han elaborado dos diagramas de casos de uso, uno por

cada modo de funcionamiento. Como se observa en la Figura 7.2 el diagrama del modo de ejecución

consta de cinco actores: IDS, Razonador, Evaluador de éxito de respuesta, Analizador de contexto y

Ontología de Respuesta a Intrusiones.


231

Figura 7.2 Diagrama de casos de uso del módulo de evaluación del éxito de una acción de respuesta funcionando en modo ejecución.

La implementación de los actores IDS, Razonador, Analizador de contexto y Ontología de Respuesta

a Intrusiones no es el objetivo de este capítulo pero se incluyen en el escenario puesto que imponen

ciertos requisitos a tener en cuenta en el diseño del sistema de evaluación. Además, estos actores

han sido ampliamente definidos y explicados en capítulos anteriores de la memoria. El cuarto actor,

es el denominado Evaluador de éxito de respuesta, actor principal que tras ser invocado por el

razonador (CU05), se encarga de aplicar la metodología de evaluación propuesta y obtener un nivel

de éxito asociado a una acción de respuesta (CU09), para posteriormente actualizar él mismo la tasa

de éxito y guardar el nuevo valor en la ontología de respuesta a intrusiones (CU11), para que el AIRS

lo tenga en consideración en posteriores inferencias.

Cuando el Razonador infiere la respuesta óptima (CU03), y la ejecución de la respuesta seleccionada

ha finalizado (CU04), éste actor invoca al Evaluador de éxito de respuestas, proporcionándole el

modo de funcionamiento deseado junto con los parámetros de entrada necesarios para el correcto

funcionamiento del sistema en el modo seleccionado (tipo de intrusión, anomalía del contexto en

tiempo de intrusión, identificador de la respuesta, etc.). A continuación, el Evaluador selecciona el

modo de funcionamiento del sistema de evaluación invocado (CU06). Una vez seleccionado, el actor

implementa la primera fase de la metodología de evaluación, que consiste en calcular la variación de

la entropía cruzada de Renyi de la anomalía del contexto según lo explicado en el apartado 7.4.1.1

(CU07), para lo que necesita obtener la anomalía en el estado de la red y el sistema después de

aplicar la respuesta (CU08). A continuación el Evaluador compara la variación en la anomalía con los

umbrales de éxito superior e inferior asociados a la intrusión que son proporcionados por la Ontología

de Respuesta a Intrusiones (CU10), para determinar si la respuesta ha sido exitosa o no según lo

especificado en la tercera fase de la metodología (CU09). Por último, se obtiene la nueva tasa de

éxito de la acción de respuesta y se actualiza el valor correspondiente en la Ontología de Respuesta

a Intrusiones (CU11).


232

De la misma forma, el diagrama de casos de uso asociado al modo de entrenamiento se observa en

Figura 7.3.

Figura 7.3 Diagrama de casos de uso del módulo de evaluación del éxito de una acción de respuesta funcionando en modo entrenamiento.

El proceso de entrenamiento del sistema de evaluación de éxito es más complejo que su uso en

ejecución. En este caso, el escenario consta de cinco actores: Administrador, Simulador de intrusión,

Ejecutor de respuestas, Analizador de contexto y Evaluador de éxito de respuesta. A continuación se

describen de forma breve cada uno de los actores, así como los casos de uso de los que son

responsables:

- Administrador: actor principal que inicia el proceso de entrenamiento del sistema. Tiene dos

funciones principales. La primera consiste en invocar al sistema de evaluación del éxito de la

respuesta indicándole entre otros parámetros el modo de funcionamiento del sistema, el tipo

de intrusión para la que se quiere entrenar el sistema, la IP del sistema a atacar, y el número

de veces que se va a ejecutar el proceso para cada una de las respuestas (CU12). Cuanto

mayor sea el número de muestras obtenidas, más precisos serán los umbrales asociados. La

segunda función es proporcionar los conjuntos de entrenamiento (conjunto con acciones de

respuesta exitosas y conjunto con acciones de respuesta fallidas) (CU17).

- Simulador de intrusión: actor secundario encargado de simular la intrusión especificada por el

administrador con los parámetros indicados (CU16). Cada intrusión será emulada n*m veces,

siendo n el número de respuestas del conjunto de entrenamiento, y m el número de veces

que se ejecuta cada una de ellas.

- Ejecutor de respuestas: actor que se encarga de ejecutar una acción de respuesta sobre un

componente de seguridad que está localizado local o remotamente (CU19). Además, permite

desactivar una acción de respuesta previamente desplegada (CU22), lo que resulta

especialmente interesante en la fase de entrenamiento del sistema, donde para intrusión se

debe ejecutar cada acción de respuesta m veces, y para ello es necesario desactivar la

respuesta antes de simular de nuevo la intrusión.


233

- Analizador de contexto: actor cuya función es analizar el estado de la red en un instante

específico y obtener el grado de anomalía existente respecto a un estado de funcionamiento

habitual (CU20). Esta anomalía es un parámetro clave para calcular la variación de la

entropía del contexto y por tanto establecer los umbrales de éxito, como se describe en

apartados anteriores de este capítulo.

- Evaluador de éxito de respuesta: cuando el administrador invoca el sistema de evaluación

este último debe seleccionar el modo de funcionamiento deseado y comprobar que la petición

realizada también incluye los parámetros obligatorios para que el modo elegido funcione

correctamente (CU13). Una vez seleccionado el modo de funcionamiento (entrenamiento en

este caso), el agente deberá establecer un umbral de éxito superior y otro inferior (CU14).

Para ello, el actor debe ser capaz de invocar al Simulador de intrusión, proporcionándoles los

parámetros necesarios (tipo de intrusión, IP destino del ataque, payload, etc.) (CU15); debe

invocar al Ejecutor de respuestas para que el actor involucrado ejecute todas las respuestas

incluidas en los conjuntos de entrenamiento tantas veces como indique el administrador

(CU18); y debe calcular la variación de la entropía cruzada de Renyi del contexto antes y

después de ejecutar la acción de respuesta (CU21). Para realizar las invocaciones es

necesario establecer interfaces claras y bien definidas entre el Evaluador de éxito de

respuesta, y los otros actores implicados.

A partir de los dos diagramas de casos de uso presentados se pueden extraer los requisitos tanto

funcionales como no funcionales (Ver Capítulo 8) que debe cumplir el sistema de evaluación de éxito

propuesto. Los requisitos del resto de actores ya fueron analizados en el Capítulo 4 de la presente

memoria, por ello no se incluyen, a excepción de los requisitos del razonador del AIRS y de la

ontología de respuesta a intrusiones que deriven de la integración del sistema de evaluación en el

AIRS basado en ontologías.

La Tabla 7.1 recoge los requisitos funcionales, indicando los casos de uso implicados, así como el

componente.

Tabla 7.1 Requisitos funcionales del sistema de evaluación del éxito de la respuesta.

Comp. Caso

de uso Ref. Requisito

Razo

na

do

r

CU04 REQF01 Debe evaluar el resultado de la ejecución de la respuesta.

CU05 REQF02 Debe invocar al sistema de evaluación de éxito de la respuesta indicando el modo de

funcionamiento execution, si el resultado de ejecución es “Ok (status=4)”.

REQF03 Debe proporcionar al sistema de evaluación los siguientes parámetros: 1)el valor de la

propiedad responseID de la ontología de respuesta frente a intrusiones (respuesta a

evaluar), 2) el tipo de respuesta y la acción, 3)el tipo de intrusión, 4)IP del sistema y

5)el vector de anomalía obtenido tras detectar la intrusión; en caso de que el modo

seleccionado sea “execution”.

CU11 REQF04 Debe actualizar la nueva tasa de éxito en la ontología de respuesta a intrusiones.

Sis

tem

a d

e E

valu

ació

n d

el

éxit

o

de

la r

esp

ue

sta

: m

od

o d

e

eje

cu

ció

n y

de

en

tren

am

ien

to

CU06 /

CU13

REQF05 Debe proporcionar dos modos de funcionamiento: execution y training.

REQF06 Debe tener la capacidad de seleccionar el modo de funcionamiento especificado por el

razonador o por el administrador del sistema.

REQF07 Debe comprobar que se le proporcionan los parámetros requeridos en cada modo de

funcionamiento.

CU07 /

CU20

REQF08 Debe invocar al módulo de contexto para obtener el vector de anomalía compuesto

por nueve indicadores (Status, CPU, Latency, Disk, Process, Zombie, User,

SSHFailed y Network).

REQF09 Debe obtener la entropía cruzada de Renyi para cada componente de anomalía del

vector en T1 (momento de detección de intrusión) respecto a T0 (tiempo de


234

funcionamiento normal).

Sis

tem

a d

e E

valu

ació

n d

el

éxit

o d

e la r

esp

ue

sta

: m

od

o d

e e

jecu

ció

n y

de

en

tren

am

ien

to

REQF10 Debe obtener la entropía cruzada de Renyi para cada componente de anomalía del

vector en T2 (momento tras ejecutar acción de respuesta) respecto a T0 (estado de

funcionamiento normal).

REQF11 Debe tener la capacidad de extraer información de la ontología de respuesta a

intrusiones.

REQF12 Debe obtener los pesos de cada indicador del contexto asociados a un tipo de

amenaza.

REQF13 Debe calcular la variación global de la entropía cruzada de Renyi entre T2 y T1.

CU10 REQF14 Debe obtener los umbrales de éxito superior e inferior asociados a cada tipo de

intrusión, donde el nombre que identifica a cada umbral en la ontología es Threshold1

y Threshold2 respectivamente.

CU09 REQF15 Debe comparar la variación de la entropía de la anomalía del contexto con los

umbrales Threshold1 y Threshold2.

REQF16 Debe comprobar la existencia o no de alertas relativas a la misma intrusión en

instantes inmediatamente posteriores a la aplicación de la respuesta, en caso de que

la intrusión no se traduzca en una variación en la anomalía del contexto.

REQF17 Debe determinar si la respuesta ha sido exitosa, ha fallado o no se puede determinar y

actualizar el resultado en la ontología.

CU11 REQF18 Debe extraer la última tasa de éxito asociada a la acción de respuesta cuyo

identificador coincide con el parámetro responseID de la ontología. Esta tasa se

representa en la ontología con el nombre de responseEfficiency o RTE.

REQF19 Debe calcular el nuevo de RTE.

CU15 REQF20 Debe invocar al simulador de intrusión proporcionándole los siguientes parámetros:

1)Tipo de intrusión, 2)IP destino (host comprometido), y 3) parámetros específicos del

tipo de intrusión.

CU18 REQF21 Debe recibir los conjuntos de entrenamiento exitoso y fallido.

REQF22 Debe invocar al ejecutor de respuestas usando el valor de la propiedad

responseAction de la ontología.

REQF23 Debe proporcionar al módulo central de ejecución del ejecutor de respuestas los

siguientes parámetros: 1)IP origen, 2)IP destino, 3)puerto destino, 4)protocolo, y 5)SID

(signature ID).

CU14 REQF24 Debe establecer el umbral de éxito superior e inferior asociado a cada tipo de

intrusión.

REQF25 Debe escribir en la ontología los umbrales de éxito superior e inferior asociados a

cada tipo de intrusión, donde el nombre que identifica a cada umbral en la ontología

es Threshold1 y Threshold2 respectivamente.

7.4.2.2 Diseño de la arquitectura

Una vez definidos los requisitos funcionales del sistema de evaluación del éxito de una acción de

respuestas, el objetivo de este apartado es presentar los aspectos más relevantes del diseño de su

arquitectura, mostrando una visión general del sistema de evaluación estableciendo un marco de

control y comunicación entre los módulos que forman dicha arquitectura.

La arquitectura propuesta cumple todos los requisitos previamente definidos y permite aplicar y

ejecutar todos los pasos de la metodología de evaluación. Como se observa en Figura 7.4, consta de

8 módulos, 4 módulos externos que se representan en gris en la figura y que ya han sido definidos y

explicados en capítulos anteriores de esta memoria (IDSs y Reasoner, IntrusionResponseOntology,

ContextModule y NRPE Agent, y Responses Executor) y 4 módulos principales de la arquitectura, que


235

están representados en azul (EvaluationSystemModeSelector, EvaluationSystemExecutor,

EvaluationSystemTrainer y ContextEntropyVarianceAgent). Cada uno de los módulos funciona de

manera independiente y para su comunicación basta con conocer las interfaces de entrada y salida

respectivas. Es preciso aclarar que en la fase de entrenamiento también está involucrado un módulo

de simulación de intrusiones, que no se incluye en la arquitectura.

Figura 7.4 Arquitectura del sistema de evaluación del éxito de una respuesta.

Los cuatro módulos que componen el sistema de evaluación residen en el mismo equipo que el

Reasoner. A continuación se especifican de forma breve la funcionalidad de cada uno de los

módulos, prestando especial atención a los que forman el sistema de evaluación.

IDSs y Reasoner

Como se indica previamente los IDSs son sistemas que se encuentran distribuidos en la red de la

organización, cuyo objetivo es detectar comportamiento anómalo y enviar el informe de intrusión

correspondiente al AIRS basado en ontologías. Este informe contiene parámetros relativos al ataque

detectado, entre los que se encuentra el tipo de intrusión, parámetro necesario para el correcto

funcionamiento del sistema de evaluación. De los distintos tipos de IDSs existentes (Ver sección

2.2.2), la arquitectura soporta NIDS y HIDS.

Por su parte, el Reasoner es el núcleo del sistema de respuesta propuesto descrito detalladamente

en el capítulo 4. Su función principal es inferir la respuesta óptima frente a la intrusión detectada por

uno de los IDSs en base a métricas de respuesta especificadas mediante reglas SWRL. Una vez

inferida la respuesta, el razonador invoca al módulo ejecutor de respuestas que se encarga si es

posible, de desplegar la respuesta.

El razonador recibe el resultado de ejecución de la respuesta, es decir, si la respuesta ha finalizado

su despliegue o si por el contrario ha habido algún error en la ejecución de la misma. En caso de que

el resultado sea positivo, invoca al sistema de evaluación del éxito de la respuesta que se encarga de

determinar si la acción desplegada ha mitigado la intrusión por completo, de forma parcial, o su efecto

ha sido nulo. En esta invocación, el Reasoner debe proporcionar el modo de funcionamiento en el

que quiere ejecutar el sistema, que en su caso será siempre “execution”. Además, debe proporcionar

los parámetros requeridos para evaluar la respuesta como el identificador de la propia respuesta

(responseID) o la anomalía en el instante de intrusión.


236

Es importante que el Razonador del AIRS basado en ontologías proporcione los parámetros

necesarios, de lo contrario, el sistema de evaluación del éxito devolverá un error y la respuesta no

será evaluada.

EvaluationSystemModeSelector

El módulo denominado EvaluationSystemModeSelector tiene como objetivo extraer el modo de

funcionamiento solicitado y comprobar que los parámetros enviados por el razonador o el

administrador del sistema son los requeridos por dicho modo. En caso de que sean correctos, invoca

al módulo correspondiente: EvaluationSystemExecutor si el modo es “execution” y

EvaluationSystemTrainer si el modo es “training”. En caso contrario, se desestima la petición de

evaluación devolviendo un código de error.

Además, si los parámetros son correctos, este componente es el encargado de proporcionar al

agente invocador el resultado obtenido, esto es, la tasa de éxito de la respuesta con identificador

responseID o los umbrales superior e inferior asociados a un tipo de intrusión determinada.

Parámetros de entrada: modo de funcionamiento del sistema y parámetros requeridos en cada modo:

- Modo ejecución: identificador de la respuesta a evaluar (responseID), la acción de respuesta

(responseAction), tipo de respuesta (responseType), tipo de intrusión (hasIntrusionType),

dirección IP del host comprometido (addressIP), y mapa de anomalía en momento de

detección.

- Modo entrenamiento: tipo de intrusión (hasIntrusionType), dirección IP del host comprometido

(addressIP), tipo de conjunto de entrenamiento (exitoso, fallido o indefinido), conjunto de

entrenamiento con acciones de respuesta y número de veces que se debe ejecutar cada

respuesta.

Parámetros de salida: código de éxito o error en la ejecución del sistema de evaluación, y en caso de

éxito:

- Modo ejecución: tasa de éxito de la respuesta evaluada y número de ejecuciones hasta el

momento actual.

- Modo entrenamiento: umbrales de éxito superior e inferior asociados al tipo de intrusión

hasIntrusionType.

EvaluationSystemExecutor

Módulo principal cuando el sistema se ejecuta en modo “execution”. Este módulo se encarga de

aplicar las fases 3 y 4 de la metodología de evaluación propuesta, por lo que su función principal es

calcular el nivel de éxito de la respuesta responseID que indica si esta ha conseguido mitigar la

intrusión, y actualizar la tasa de éxito de la respuesta incorporando el nuevo valor obtenido.

Como se observa en el diagrama de actividad (Ver Figura 7.5), este módulo lleva a cabo las

siguientes actividades:

- Solicitar contexto: el módulo invoca a ContextModule pasándole como parámetro la dirección

IP del host atacado (parámetro definido como addressIP en la ontología). Como resultado,

recibe un mapa del estado de la red en el instante inmediatamente posterior a la finalización

del despliegue de la respuesta (denominado como T2 en la descripción de la metodología).

Este mapa de estado contiene la anomalía existente tanto en la red como en el host

comprometido respecto a su perfil de funcionamiento normal, en base a 9 indicadores:

anomalía en la red, estado del sistema, uso de la CPU, espacio libre en disco, número de


237

Figura 7.5 Sistema de Evaluación del éxito de una acción de respuesta: Diagrama de actividad.


238

usuarios, número de procesos zombie, número de procesos activos, número de intentos de

conexión por SSH fallidos, y latencia del sistema.

- Solicitar la variación de la entropía cruzada de Renyi: una vez que se ha obtenido el mapa de

la anomalía de la red tras ejecutar la respuesta, se invoca a ContextEntropyVariance Agent

pasándole como parámetros dos listas que contienen la anomalía del contexto antes y

después de la aplicación de la acción de respuesta. Cada lista está formada por un conjunto

de indicadores de anomalía, 9 en este caso. Como resultado, recibe un número decimal entre

-1 y 1, que se corresponde con la variación global de la entropía cruzada de Renyi del

contexto entre el momento de detección y el momento tras finalizar la ejecución de la

respuesta.

- Obtener umbrales de éxito superior e inferior: el siguiente paso es obtener los umbrales de

éxito asociados al tipo de intrusión detectada almacenados en la ontología de respuesta a

intrusiones, IntrusionResponseOntology. Estos umbrales son calculados y guardados en la

ontología en la fase de entrenamiento del sistema.

- Calcular nivel de éxito: el módulo compara el valor de la variación de la entropía cruzada de

Renyi con los umbrales de éxito. Como resultado asocia un valor (1, ½ o 0) al nivel de éxito

de la respuesta en esta ejecución específica.

- Calcular tasa de éxito: actualiza la tasa de éxito asociada a la acción de respuesta

incorporando el nuevo valor de nivel de éxito obtenido, según lo explicado en la fase 4 de la

metodología (Ver “7.4.1.4 Tasa de éxito o efectividad de la respuesta”). El valor de la tasa de

éxito a actualizar así como el número de ejecuciones anteriores de la respuesta se extraen de

la ontología IntrusionResponseOntology.

Los parámetros de entrada y salida de EvaluationSystemExecutor son:

- Parámetros de entrada: identificador de la respuesta a evaluar (responseID), la acción de

respuesta (responseAction), tipo de respuesta (responseType), tipo de intrusión

(hasIntrusionType), dirección IP del host comprometido (addressIP), y mapa de anomalía en

momento de detección.

- Parámetros de salida: código de éxito o error en la ejecución del sistema de evaluación, y en

caso de éxito, tasa de efectividad de la respuesta evaluada y número de ejecuciones hasta el

momento actual.

EvaluationSystemTrainer

Módulo principal cuando el sistema se ejecuta en modo “training”. Este módulo se encarga de aplicar

la fase 2 de la metodología de evaluación propuesta, por lo que su función principal es obtener los

umbrales de éxito superior e inferior asociados a cada tipo de intrusión.

Cuando el administrador invoca el sistema de evaluación en modo de entrenamiento y el

EvaluationSystemModeSelector comprueba que se proporcionan los parámetros requeridos, este

módulo es invocado.

Para cada acción de respuesta del conjunto de entrenamiento, el módulo EvaluationSystemTrainer

lleva a cabo el siguiente proceso tantas veces como indique el administrador en sus parámetros

(número de veces que se debe ejecutar cada respuesta referido como m):

1. Invocar al simulador de intrusiones que ejecuta el tipo de intrusión especificado.

2. Invocar a ContextModule pasándole como parámetro la dirección IP del host atacado

(parámetro definido como addressIP en la ontología). Como resultado, recibe un mapa del

estado de la red en el momento de intrusión (denominado como T1 en la descripción de la

metodología), que contiene la anomalía existente tanto en la red como en el host

comprometido respecto a su perfil de funcionamiento normal, en base a los 9 indicadores

especificados.


239

3. Invocar al ResponsesExecutor para que ejecute la acción de respuesta del conjunto de

entrenamiento.

4. Una vez finalizada la respuesta, solicitar el mapa de estado de la red en instante T2 (momento

después de finalizar el despliegue de la respuesta).

5. Solicitar la variación de la entropía cruzada de Renyi para lo que se invoca a

ContextEntropyVariance Agent siguiendo el mismo proceso que el explicado para el modo de

ejecución. Como resultado, recibe un número decimal entre -1 y 1, que se corresponde con la

variación global de la entropía cruzada de Renyi del contexto entre el momento de intrusión y

el momento tras finalizar la ejecución de la respuesta, denominado como I .

6. Por último, solicitar al ResponsesExecutor que desactive la respuesta.

Para cada acción de respuesta del conjunto de entrenamiento se obtienen m valores de I .

Cuando el módulo EvaluationSystemTrainer ha ejecutado todas las respuestas del conjunto de

entrenamiento m veces, calcula el umbral de éxito superior y/o inferior en función del tipo de conjunto

de entrenamiento especificado siguiendo los pasos de la fase 2 de la metodología. Por último,

almacena los valores correspondientes en la ontología.

Los parámetros de entrada y salida de este módulo son:

- Parámetros de entrada: tipo de intrusión (hasIntrusionType), dirección IP del host

comprometido (addressIP), tipo de conjunto de entrenamiento (exitoso, fallido o indefinido),

conjunto de entrenamiento con acciones de respuesta y número de veces que se debe

ejecutar cada respuesta (m).


caso de éxito, umbrales de éxito superior e inferior asociados al tipo de intrusión

hasIntrusionType.

ContextEntropyVariance Agent

Módulo que aplica la fase 1 de la metodología de evaluación propuesta, por lo que su función

principal es calcular la variación total de la entropía cruzada de Renyi en la anomalía del contexto

antes y después de la ejecución de una acción de respuesta.

Los parámetros de entrada y salida de este módulo son:

- Parámetros de entrada: dos listas que contienen la anomalía del contexto antes y después de

la aplicación de la acción de respuesta. Cada lista está formada por un conjunto de

indicadores de anomalía, 9 en este caso.


caso de éxito, número decimal entre -1 y 1.

ContextModule y NRPE Agent

Componente externo al sistema de evaluación del éxito de la respuesta cuya funcionalidad principal

es calcular el nivel de anomalía existente en 9 indicadores del estado de la red y los sistemas de la

red, entre un instante concreto y el estado que presenta la red y los sistemas en un modo de

funcionamiento normal sin comportamiento anómalo. Como se ha indicado en puntos anteriores del

documento, estos indicadores son: tráfico de red, estado del sistema, uso de la CPU, espacio libre en

disco, número de usuarios, número de procesos zombie, número de procesos activos, número de

intentos de conexión por SSH fallidos, y latencia del sistema.

Este componente a pesar de ser externo es especialmente relevante para el funcionamiento del

sistema de evaluación del éxito, puesto que la base de la metodología de evaluación propuesta es la

variación existente en la anomalía del contexto entre el momento de intrusión y el instante después

de aplicar la acción de respuesta. Por ello, es un componente clave en la arquitectura.


240

ResponsesExecutor

Componente externo cuya función es ejecutar las acciones de respuestas inferidas, hacerlas

efectivas. Este componente sólo está involucrado en el funcionamiento del sistema en modo de

entrenamiento.

IntrusionResponseOntology

La ontología de respuesta a intrusiones ha sido definida detalladamente en el Capítulo 5 de la

presente memoria. En relación al proceso de evaluación del éxito de una respuesta, tiene tres

funciones:

- Proporcionar el valor de la tasa de éxito de una acción de respuesta y el número de

ejecuciones anteriores de la respuesta, si el modo de funcionamiento es ejecución (fase 4 de

la metodología).

- Proporcionar los umbrales de éxito superior e inferior asociados a un tipo de intrusión, si el

modo de funcionamiento es ejecución (fase 3 de la metodología).

- Almacenar y guardar los valores de los umbrales de éxito asociados a un tipo de intrusión

obtenidos como resultado de la fase de entrenamiento (fase 2 de la metodología).

La siguiente tabla muestra los módulos implicados y el grado de implicación que tienen en los dos

modos de funcionamiento del sistema de evaluación:

Tabla 7.2 Tabla de módulos de la arquitectura implicados en cada modo de funcionamiento del sistema de evaluación de éxito

Modo “execution” Modo “training”

IDSs y Reasoner Sí (Alto) No

SystemEvaluationModeSelector Sí (Alto) Sí (Alto)

SystemEvaluationExecutor Sí (Alto) No

SystemEvaluationTrainer No Sí (Alto)

ContextEntropyVariance Agent Sí (Alto) Sí (Alto)

ContextModule y NRPE Agent Sí (Alto) Sí (Alto)

ResponsesExecutor No Sí (Alto)

IntrusionResponseOntology Sí (Medio) Sí (Medio)

Para que el sistema de evaluación de éxito funcione correctamente, cada uno de los módulos debe

ser controlado de forma que sus funciones se ejecuten siguiendo la secuencia de acciones

especificada en el diagrama de actividad (Ver Figura 7.5).

7.4.2.3 Implementación de la arquitectura y su integración en el

AIRS basado en ontologías

Como se verá en el Capítulo 8, todos los módulos del sistema de evaluación están implementados

utilizando el lenguaje de programación Java, para facilitar la integración con el AIRS basado en

ontologías que también está desarrollado en Java. Además, el sistema de evaluación reside en el

mismo host que el Reasoner, lo que facilita la comunicación entre ambos. Detalles de la

implementación de cada uno de los módulos del sistema, como son sus diagramas de clases y

diagramas de secuencia, se incluyen en el Capítulo 8 de esta memoria.

Por otra parte, en la arquitectura del sistema de evaluación del éxito de una acción de respuesta

presentada en la Figura 7.4 se observa la comunicación que se establece entre algunos módulos del

AIRS basado en ontologías y el sistema de evaluación, pero para su correcta integración, es

necesario definir de forma clara y precisa las interfaces entre todos los módulos, estableciendo los

parámetros necesarios. Entendiendo el sistema de evaluación como una caja negra, durante la fase

de integración del mismo con el AIRS basado en ontologías, es necesario modificar dos componentes

de la arquitectura del sistema de respuesta: Reasoner y la ontología de respuesta a intrusiones.


241

Detalles relacionados con los cambios realizados se proporcionan en el capítulo correspondiente a la

validación de las propuestas, 8.3.


Esta sección ha tratado de describir una metodología para la evaluación automática del éxito o

eficacia de una acción de respuesta. Además, se ha propuesto una arquitectura de sistema de

evaluación de éxito que desarrolla e implementa dicha metodología, presentando los detalles más

relevantes de su diseño e implementación.

La metodología propuesta pretende resolver la problemática existente en cómo determinar si una

respuesta ha conseguido mitigar la intrusión detectada o reducir su impacto, o por el contrario, el

sistema de respuesta ha inferido una reacción errónea incapaz de bloquear la intrusión. Para ello, se

propone analizar la variación producida en el valor de los indicadores del contexto de la red y del

propio sistema comprometido antes y después de la ejecución de la respuesta. Es decir, comparar el

mapa del estado de la red y los sistemas en el momento de la intrusión con el mapa tras la aplicación

de la respuesta.

Así mismo, se han estudiado los problemas de la metodología propuesta frente a intrusiones que no

modifican el tráfico de la red respecto a su perfil de funcionamiento habitual ni provocan la variación

de los indicadores del contexto del sistema, proponiendo una adaptación de la metodología para

estos escenarios de ataque.

7.5 Conclusiones

El objetivo de este capítulo es tratar de resolver la problemática existente en cuanto a cómo medir de

forma automática y cuantitativa el éxito de una acción de respuesta previamente inferida y ejecutada

por un sistema de respuesta a intrusiones automático, y tener en cuenta el valor obtenido en

posteriores inferencias.

La tasa de éxito o efectividad de una acción de respuesta es un parámetro de gran importancia para

que un sistema de respuesta a intrusiones posea uno de los requisitos deseados en un AIRS (Ver

2.3): la adaptabilidad. Para ello, el sistema necesita conocer el éxito de todas las acciones de

respuesta disponible en el catálogo de reacciones y tenerlo en cuenta en las métricas de respuesta

que utiliza el sistema para elegir la respuesta más adecuada frente a una intrusión.

Por otra parte, otro requisito a cumplir por un AIRS es que sea sensible al coste de las respuestas, es

decir, que haga un balance entre el coste de la intrusión y el coste y el beneficio de la reacción de

respuesta, y lo tenga en cuenta en el proceso de inferencia. En los últimos años se ha visto

incrementado el interés en el desarrollo e implementación de AIRS que utilizan mecanismos de

selección de la respuesta sensibles a costes (cost-sensitive). Su objetivo es asegurarse de inferir una

respuesta capaz de mitigar la intrusión pero sin sacrificar el funcionamiento habitual del sistema

comprometido, para lo que tienen en cuenta factores relacionados con el impacto y coste de las

respuestas pero también su nivel de éxito o efectividad de una respuesta en anteriores ejecuciones.

Queda patente por tanto la importancia de la efectividad de una acción de respuesta para el correcto

funcionamiento del sistema de respuesta a intrusiones. No obstante, como ya se indicó en la revisión

del estado del arte en sistemas de evaluación de éxito, es un parámetro de gran relevancia pero

resulta complicado de medir y evaluar de forma automática.

Del análisis realizado en la sección 7.3 del presente capítulo se concluye que la mayoría de los

sistemas de respuestas a intrusiones existentes o no lo tienen en cuenta o lo miden de forma manual.

Y aquellos que lo miden de forma automática resulta complicado integrar el mecanismo propuesto en

la arquitectura del AIRS basado en ontologías.


242

Por ello, en este capítulo se propone una metodología que permite evaluar de forma cuantitativa y

automática el éxito de una acción de respuesta contra una intrusión. Para ello se propone el uso de la

entropía cruzada de Renyi para calcular la variación producida en la anomalía de la red y el sistema

atacado entre el momento de detección de la intrusión y tras desplegar la acción de respuesta. El

utilizar cambios relativos en el contexto para determinar el nivel de éxito y no valores absolutos dota

al sistema de mayor precisión y reduce la tasa de error. Una descripción detallada de la metodología

propuesta se incluye en la sección 7.4.

El próximo capítulo introduce la validación de la metodología propuesta mediante integración en el

AIRS basada en ontologías y su aplicación a varios casos de prueba con diferentes escenarios de

intrusión.

Capítulo 8: Validación de las Propuestas

243

VALIDACIÓN DE LAS PROPUESTAS Capítulo 8

8.1 Introducción

En los capítulos anteriores se han presentado las siguientes propuestas:

- Propuesta de arquitectura de un sistema de respuesta a intrusiones basado en ontologías.

- Propuesta de ontología de respuesta a intrusiones.

- Propuesta de métricas de seguridad y su especificación mediante SWRL.

- Propuesta de una metodología para la evaluación del éxito de una acción de respuesta.

El objetivo del presente capítulo es la validación de las cuatro propuestas de forma que se muestre la

viabilidad de las mismas, en cuanto a que permiten alcanzar los objetivos especificados para cada

una de ellas. La fase de validación se divide en dos partes bien diferenciadas:

- Desarrollo e implementación de un prototipo de la arquitectura del AIRS basado en ontologías

propuesta. En este capítulo se proporcionan los detalles más relevantes de la implementación

de cada componente de la arquitectura, así como de la integración de estos respecto al

componente principal de la arquitectura, el Razonador.

- Validación del prototipo implementado mediante su integración y ejecución en un escenario

que pretende emular la topología de red de una organización típica. Durante esta fase se

ejecutan distintos ataques que comprometen diferentes tipos de activos de la red, y se

describe paso a paso el proceso de inferencia de la respuesta óptima llevado a cabo por el

sistema de respuesta a intrusiones basado en ontologías propuesto, en cada escenario de

ataque.

Además de la validación funcional de las propuestas, en esta sección se proporcionan

medidas del rendimiento del AIRS basado en ontologías en términos del tiempo de inferencia

y de la evaluación del éxito de las acciones de respuesta inferidas por el sistema.

8.2 Proyectos Segur@ y Reclamo

La validación de las propuestas incluidas en esta tesis doctoral se ha llevado a cabo en el marco de

los proyectos de investigación Segur@ y Reclamo.

Segur@

El proyecto CENIT Segur@ (Seguridad y Confianza en la Sociedad de la Información,) fue un

proyecto promovido por el Centro para el Desarrollo Tecnológico Industrial (CDTI), Organismo

dependiente del Ministerio de Ciencia e Innovación. Se inició en Julio de 2007 dentro la tercera

convocatoria del Programa CENIT (formando parte de la iniciativa INGENIO 2010).


244

El objetivo del proyecto SEGUR@ es generar un marco de confianza y seguridad para el uso de las

TIC en la e-Sociedad en España. Está liderado por Telefónica Investigación y Desarrollo (TID),

participando en él un total de 11 Empresas y 15 Universidades y Centros de Investigación, repartidos

por 6 comunidades del Estado. La validación de las propuestas se enmarcan dentro de la tarea

T3060 del paquete de trabajo AP3, en colaboración con Telefónica I+D (TiD). Esta tarea se denomina

“Estudio, desarrollo y simulación de modelos de respuesta automática”.

RECLAMO

El proyecto RECLAMO (Red de sistemas de Engaño virtuales y CoLaborativos basados en sistemas

Autónomos de respuesta a intrusiones y Modelos de cOnfianza), es un proyecto en curso de I + D

financiado por el Ministerio de Ciencia e Innovación español.

El objetivo del proyecto RECLAMO es la definición y el diseño de un marco avanzado de referencia

para mejorar las propuestas actuales de sistemas de detección y reacción frente a intrusiones.

Concretamente, el proyecto propone un sistema de respuesta autónoma capaz de inferir la respuesta

más apropiada para una intrusión dada, teniendo en cuenta no sólo la intrusión, sino también otros

parámetros relacionados con ella, como el contexto o la confianza y la reputación de la fuente de la

red, entre otros.

8.3 Implementación del prototipo de AIRS basado en

ontologías

En capítulos anteriores de la presente memoria se incluye la arquitectura del sistema de respuesta

automática frente a intrusiones basada en ontologías propuesta (Ver Figura 4.1), y la descripción de

cada uno de sus módulos desde un punto de vista arquitectural. El objetivo de esta sección es

proporcionar detalles de la implementación de cada uno de ellos como parte del desarrollo del

prototipo del AIRS basado en ontologías y de su integración en la arquitectura del sistema desde el

punto de vista de su interacción con el núcleo de la misma, es decir, con el Razonador.

Además, para cada uno de los módulos desarrollados se han realizado dos tipos de pruebas:

- Pruebas unitarias destinadas a evaluar cada uno de los componentes de la arquitectura antes

de su integración en el sistema.

- Pruebas de integración destinadas a verificar que el sistema completo se comporta según lo

esperado.

En primer lugar, es necesario especificar los requisitos no funcionales a tener en cuenta en el diseño

e implementación del AIRS basado en ontologías, que se muestran en la Tabla 8.1.

Tabla 8.1 Requisitos NO funcionales del AIRS basado en ontologías.

Ref. Requisito

REQNF01 Debe ser implementado en Java casi en su totalidad.

REQNF02 El sistema será configurable

REQNF03 Debe operar sobre el S.O. Linux y dejar abierta la posibilidad de extenderlos a otros

S.O. (Portabilidad)

REQNF04 Debe ser escalable de tal forma que sea posible añadir nuevos módulos en un futuro

de forma sencilla.

REQNF05 Debe tener la capacidad de almacenar los logs de operación.


245

Un requisito imprescindible (REQNF02) es el hecho de que el sistema pueda ser configurado por el

administrador. Como se indica previamente en esta memoria, el Apéndice III, incluye la descripción

de una interfaz de administración.

El hecho de que se utilice Java como lenguaje de implementación del AIRS basado en ontologías

debe ser tenido en la especificación de los requisitos así como la implementación del resto de

componentes presentes en la arquitectura.

8.1.1 IDSs

Desde el punto de vista de la implementación del prototipo del AIRS basado en ontologías, la

arquitectura propuesta soporta dos IDSs: Snort4 como NIDS y OSSEC

5 como HIDS.

En ambos casos, el informe de intrusión se genera en formato Syslog, y en el caso de Snort este

informe tiene la siguiente estructura:

<priority> month day time hostname process[pid]: [x:y:z] message

[Classification: classification] {protocol} source -> destination

Por otra parte, con el fin de dotar de transparencia al sistema y dificultar la detección de la existencia

de NIDSs en la red por parte de los atacantes, estos funcionan en modo promiscuo escuchando en

una interfaz de red el tráfico que desean analizar, y se utiliza un mecanismo denominado port

mirroring, que consiste en que el switch o router actúa como un espejo, duplicando todo el tráfico

entrante o saliente de una determinada interfaz y enviando la copia a la interfaz donde el NIDS (Snort

en la arquitectura propuesta) está escuchando. Hay varias técnicas que permiten implementar el

mecanismo de port mirroring, bien configurando de forma conveniente los switches y routers,

siguiendo las especificaciones proporcionadas por sus desarrolladores (por ejemplo: mediante los

comandos monitor sesion 1 source interface interface1 – monitor sesión 1 destination interface

interface2, en el caso del Cisco Catalyst 3750; port monitor interface1 en el Cisco Catalyst 3500XL; o

set mirror port source interface1 destination interface2 en el caso de Juniper/Netscreen Firewall), o

bien utilizando otras técnicas como daemonlogger. Esta última opción es la técnica utilizada en la

implementación del AIRS basado en ontologías. Daemonlogger6 actúa como sniffer sobre una interfaz

y envía un duplicado de todo el tráfico recibido hacia otra interfaz, en este caso en la que está

escuchando el NIDS Snort. Para ello, tan sólo es necesario indicar la interfaz cuyo tráfico va a ser

duplicado y la interfaz a la que va a ser enviado, para lo que es necesario ejecutar los siguientes

comandos:

daemonlogger –i NetATT –o IDSNet1

Con el uso del mecanismo port mirroring utilizando daemonlogger se consiguen dos objetivos:

- Ocultar en cierta medida la existencia de NIDSs.

- No contaminar o modificar el tráfico original enviado desde el atacante a la máquina víctima.

En la Figura 8.1 se observa como el daemonlogger instalado sobre el host R-FW copia los paquetes

que llegan por la interfaz NetATT y los envía hacia la interfaz IDSNet1, subred en la que se encuentra

conectado el IDS Snort. Como se observa, esto se hace de una forma transparente al atacante,

puesto que los paquetes además son enviados hacia su destino.

4 http://www.snort.org

5 http://www.ossec.net

6 http://sourceforge.net/projects/daemonlogger/


246

Figura 8.1 Uso de daemonlogger como técnica de port mirroring desde la interfaz NetATT hacia IDSNet1.

En el caso de los HIDSs no es necesario utilizar este mecanismo puesto que analizan todo el tráfico

entrante y saliente al host en el que residen.

En ambos casos, los IDSs monitorizan el tráfico ya sea a nivel de red o de host, y ante la detección

de una intrusión generan una alerta en formato Syslog, como se ha indicado previamente. Esto

requiere la configuración de los archivos de configuración de Snort y OSSEC:

- En el caso de Snort, para especificar Syslog como formato de salida, es necesario añadir la

siguiente línea en el fichero de configuración snort.conf: output alert_syslog: LOG_AUTH

LOG_ALERT.

- En el caso de OSSEC, es necesario añadir lo siguiente al fichero de configuración ossec.conf:

La dirección del servidor syslogd:

<syslog_output>

<server>10.0.1.1</server>

<port>514</port>

</syslog_output>

La habilitación del cliente syslog de OSSEC:

/var/ossec/bin/ossec-control enable client-syslog

Cada vez que uno de los IDSs presentes en la arquitectura de la institución detecta una intrusión,

genera una alerta que envía hacia el Receptor de Alertas, cuya configuración desde el punto de vista

de la implementación se especifica en el siguiente apartado.

La configuración de los IDSs va más allá de lo explicado en este apartado, es decir, además de lo

especificado es necesario definir las reglas de detección y filtrado, habilitar los preprocesadores

correspondientes, definir los archivos o sistemas a monitorizar, etc., dependiendo estas tareas de las

necesidades específicas de cada organización.

8.1.2 Receptor de Alertas

Este componente se encarga de recibir y mapear cualquier alerta de intrusión enviada por cualquier

fuente de detección con formato diferente a un formato de alerta común, comprensible por el

razonador del AIRS propuesto.

Desde el punto de vista de su implementación, este componente está diseñado para funcionar como

un servidor de alertas Syslog, que escucha a través del puerto UDP 512. De forma breve el proceso

seguido es el siguiente:


247

- Cuando se inicia el AIRS basado en ontologías, este componente es iniciado. Desde ese

momento, permanece a la espera de recibir alertas de intrusión escuchando en el puerto 512.

- Una vez que cualquiera de los IDSs del sistema detecta un ataque, genera y envía el informe

de intrusión correspondiente. Por defecto, esta alerta en formato syslog se envían al puerto

514 (puerto por defecto del servicio syslogd) del host donde reside el núcleo del AIRS basado

en ontologías.

- El siguiente paso es redirigir todo mensaje recibido en el puerto 514 hacia el puerto 512,

donde está escuchando el módulo de Receptor de Alertas del AIRS. Para ello, basta con

añadir la siguiente regla al cortafuegos IPTables:

iptables –A PREROUTING –t nat –p udp –dport 514 –j DNAT –to-destination

IP_AIRS:512

- A continuación, el Receptor de Alertas mapea la alerta recibida a un formato común de alerta

utilizado en la arquitectura del AIRS basado en ontologías.

- Una vez que la alerta ha sido mapeada, comienza el proceso de inferencia de la respuesta

óptima para lo que este componente invoca al Razonador del AIRS pasándole como

parámetro la alerta de intrusión mapeada, la máscara de la subred en la que se encuentra el

AIRS y una variable que representa el instante actual. Para ello, el Receptor de Alertas

ejecuta lo siguiente:

Runnable nuevaAlerta = new OntAIR(alertarecibida, netMask,

currentDate);

exec.execute(nuevaAlerta);

8.1.3 Contexto de Sistemas, Contexto de Red y Receptor de

Contexto

En el instante en el que el Razonador recibe un informe de intrusión, lo primero que hace es invocar a

los módulos de contexto de red y de sistemas para obtener el grado de anomalía de cada uno de los

nueve parámetros especificados en el Capítulo 4, para lo que indica, en primer lugar, la fase de

funcionamiento del sistema, que en este caso será siempre·Detección de anomalías. Una vez, ambos

módulos proporcionan los grados de anomalía calculados, el Receptor de Contexto se encarga de

mapear la información recibida a formato OWL2.

En el Capítulo 4 se definen ambos módulos desde un punto de vista arquitectural. En este apartado

se proporcionan los detalles más relevantes de los distintos componentes presentes en las

arquitecturas especificadas desde el punto de vista de su implementación.

8.1.3.1 Contexto de Sistemas

Como se indica previamente, el contexto de sistemas está formado por tres componentes principales:

un sistema de monitorización, un módulo de procesado de la información y la base de datos de

perfiles de parámetros de los sistemas.

Sistema de monitorización

En función de los requisitos y características indicados previamente (Ver 4.4.2.1) para la elección del

sistema de monitorización a utilizar, en la implementación del prototipo del AIRS basado en

ontologías se utiliza Nagios7, en su versión 3.0, desarrollado bajo licencia GNU General Public

License Version 2.

7 http://www.nagios.org


248

Nagios es un sistema de monitorización cuya arquitectura es del tipo cliente-servidor siendo su

funcionamiento el típico de este tipo de sistemas, donde el servidor recupera la información de los

distintos sistemas clientes para procesarla y generar estadísticos y perfiles, y los clientes son aquellos

sistemas que se desean monitorizar. Para monitorizar los sistemas es necesaria la instalación de

agentes que permitan recoger la información del dispositivo y enviarla al servidor cuando éste la

solicite. Cabe destacar que los agentes que utiliza Nagios pueden funcionar en prácticamente

cualquier sistema operativo y en muchos tipos de terminales, lo que aporta una gran flexibilidad a

este módulo de contexto. Para el correcto funcionamiento del sistema de monitorización, ha sido

necesario seguir una serie de pasos:

- Instalación del servidor Nagios en el mismo host en el que reside el AIRS basado en

ontologías. Este servidor se compone de una consola y de un servidor web que permite

visualizar el estado de los equipos.

- Instalación de los agentes en los distintos terminales o hosts cuya información de contexto se

quiera monitorizar, ya que sin los agentes únicamente se podría acceder a un tipo de

información muy básica como la latencia o si el host está caído, interesante pero insuficiente

para el propósito perseguido. Además, sería imposible obtener información de por ejemplo la

carga de CPU o el número de usuarios. Existen diferentes agentes disponibles para instalar

para todos los sistemas operativos. Como se indica en los requisitos no funcionales del AIRS

basado en ontologías, en concreto en el REQNF04, “El AIRS debe operar sobre el S.O. Linux

y dejar abierta la posibilidad de extenderlos a otros S.O.”, por lo que el agente instalado ha

sido el NRPE 8. NRPE es un addon diseñado para permitir que se ejecuten plugins de Nagios

en hosts remotos de forma segura. El esquema general que utiliza el servidor nagios y el

cliente NRPE es el mostrado en la siguiente figura:

Nagios Chequeo de NRPE NRPE

Recursos locales y

servicios

Chequeo de

disco duro

Chequeo de

uso de CPU

...

Servidor Nagios Sistema remoto

SSL

Figura 8.2 Esquema de funcionamiento del contexto de sistemas.

Siguiendo este funcionamiento el servidor Nagios es capaz de enviar peticiones de chequeo a

los terminales remotos, que reconocerán las solicitudes según los procedimientos definidos

en su agente NRPE. El protocolo SSL proporciona servicios de seguridad cifrando los datos

intercambiados entre el servidor y el cliente con un algoritmo de cifrado simétrico, por lo que

se asegura que la comunicación sea segura y los métodos sólo sean accesibles por el

servidor Nagios instalado en el host donde reside el AIRS.

- Una vez instalados los agentes de usuario hay que darlos de alta y configurarlos en el

servidor, de la forma apropiada, de forma que sea posible monitorizar los 8 parámetros de

sistemas especificados en 4.4.2.1.

Tras finalizar los tres pasos anteriores, se tiene un sistema de monitorización funcionando como un

sistema de monitorización estándar, pero no es suficiente para el módulo de contexto utilizado en la

arquitectura del AIRS basado en ontologías, ya que en este caso es necesario realizar chequeos

8 http://nagios.sourceforge.net/docs/nrpe/NRPE.pdf

http://nagios.sourceforge.net/docs/nrpe/NRPE.pdf


249

inmediatos, y leer la información capturada automáticamente, durante la fase de detección de

anomalías. Para ello, es necesario configurar de forma adecuada el archivo del servidor Nagios,

nagios.cfg, de forma que sea posible obtener la información de monitorización en un instante

específico (Nagios por defecto sólo realiza chequeos pasivos cada cierto tiempo), y devolver

automáticamente dicha información al módulo de procesado encargado de analizarla. Para ello, es

necesario habilitar la opción de que Nagios guarde la información en una serie de ficheros

instantáneamente en el momento de la captura. En este caso concreto, se definen dos nuevos

ficheros: Host Performance Data y Service Performance Data, cuyo contenido así como su formato de

visualización también es necesario especificar en el archivo de configuración de Nagios. En el

prototipo implementado el formato utilizado para dichos ficheros ha sido:

service_perfdata_file_template=$HOSTNAME$\t$SERVICEDESC$\t$SERVICEOU

TPUT$\t$SERVICEPERFDATA$

host_perfdata_file_template=$HOSTNAME$\t$HOSTOUTPUT$\t$HOSTPERFDAT

A$

De esta forma, el módulo de contexto de sistemas podrá solicitar el valor de cada uno de los 8

parámetros configurados en un instante concreto, sin más que la ejecución de un script de Linux

programado expresamente que ejecuta los comandos adecuados para realizar un chequeo inmediato

de los ocho servicios de los sistemas que queremos controlar. El módulo de procesado de la

información es el responsable de ejecutar dicho script.


El objetivo de este componente es la correlación de la información recibida del sistema de

monitorización en tiempo de detección con la información almacenada en la base de datos durante la

fase de aprendizaje. Desde el punto de vista de la implementación del mismo, este módulo es un

programa Java que se compone de un paquete principal denominado systemContext, que engloba

todo el módulo y una serie de paquetes secundarios que realizan una serie de subfunciones para

obtener el grado de anomalía del sistema atacado. Los subpaquetes más importantes son:

- SystemCorrelator: la función de este paquete es la obtención del grado de anomalía en los

parámetros del sistema atacado, para lo cual utilizará el perfil generado a partir de los datos

extraídos de la base de datos y del sistema de monitorización directamente en el momento

del ataque. El resultado se obtiene mediante la comparación de estos datos utilizando un

algoritmo que finalmente devolverá un objeto que contendrá los grados de anomalía de cada

uno de los parámetros del sistema monitorizados.

- InfoLoader: es el paquete encargado de obtener la información del sistema de monitorización.

Además tiene las funciones necesarias para realizar el proceso de aprendizaje mediante la

carga periódica de los parámetros de los sistemas. Este paquete utiliza el paquete DAO para

la inserción de la información extraída en la fase de aprendizaje en la base de datos.

- DAO: es el paquete que realiza las operaciones con la base de datos. Al haber utilizado

MySQL, el driver que se utiliza es el compatible con éste gestor. Este paquete contiene las

funciones tanto de inserción de nueva información en la base de datos como de extracción,

para la generación de perfiles con los que comparar el estado del sistema concreto en el

momento del ataque.

- Util: paquete que contiene una serie de clases que apoyan al resto de paquetes pero por su

tipo de funcionalidad de carácter más generalista no pertenecen directamente a ninguno de

los anteriores.

Para realizar la correlación entre el estado normal del sistema y el estado en el momento que se

detecta un posible ataque, es necesario generar un perfil que contenga el comportamiento habitual de

dicho sistema en un momento de la semana similar al momento en el que se ha producido la

intrusión, ya que parámetros como por ejemplo, la carga de la CPU, pueden variar en gran medida


250

desde la mañana hasta media noche según el día de la semana que sea. Dicho perfil se genera en la

fase de aprendizaje del módulo de contexto.

En tiempo de intrusión, el método correspondiente del módulo de procesado de la información obtiene

por un lado el perfil del comportamiento del sistema comprometido almacenado anteriormente en la

base de datos, y por otro lado el estado de cada uno de los parámetros del sistema en momento de

detección. A partir de los datos obtenidos de la base de datos crea un objeto que contiene las medias

y desviaciones cuadráticas de cada parámetro monitorizado, tras lo cual compara parámetro a

parámetro la información contenida en el objeto creado con el estado actual del sistema, para lo que

hace uso de una distribución de probabilidad. Esta función de distribución se realiza mediante un

estadístico que tiene en cuenta no sólo la media, sino también las diferentes varianzas, ya que no

representa el mismo grado de anomalía en el disco duro por ejemplo, una variación del 10 % en

memoria libre, en un servidor de descarga y subida de archivos, que en un servidor Web cuyo

contenido sea prácticamente constante, donde ésta variación sería mucho más sospechosa. La

probabilidad que se obtiene de esta distribución acumulativa proporciona la confianza del dato actual

respecto a su comportamiento típico, luego la anomalía será su complementario. Los números se han

ajustado en función de los porcentajes de confianza para que el resultado sea un número del cero al

diez para cada parámetro, representando dicho valor la anomalía de ese parámetro en el sistema

concreto.

Como resultado, el módulo de procesado de la información proporciona un objeto de tipo

SystemAnomaly que contiene el grado de anomalía existente en cada uno de los ocho parámetros

monitorizados.

Base de datos

Componente de la arquitectura del módulo de contexto de sistemas cuyo objetivo es almacenar la

información relativa a los parámetros de los sistemas monitorizados durante la fase de aprendizaje, y

proporcionar dicho perfil durante la fase de detección de anomalías.

En el prototipo desarrollado se utiliza MySQL para la creación de la base de datos, denominada

SystemContextDB. Como se observa a continuación, está compuesta por la tabla STATUS, que a su

vez se compone de una clave primaria autonumérica, el día de la semana, el momento dentro del día,

el nombre del sistema, el estado de funcionamiento, el número de usuarios, la carga de la CPU, el

número de procesos en ejecución, el espacio libre en el disco duro, la latencia, el número de

procesos zombies y el número de conexiones SSH fallidas. El día de la semana y el momento dentro

del día han sido incluidos como atributos para poder realizar las consultas teniendo en cuenta el

factor temporal de una forma sencilla y eficiente.

CREATE DATABASE SystemContextDB;

CREATE TABLE IF NOT EXISTS STATUS (

id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,

day_week INT,

time LONG,

name VARCHAR(32) NOT NULL DEFAULT '',

state VARCHAR(32) NOT NULL DEFAULT '',

users INT,

CPU FLOAT,

processes INT,

free_space LONG,

latency FLOAT,

zombies INT,

sshFailed INT

);


251

Durante la fase de aprendizaje el módulo de procesado de la información es el encargado de insertar

nueva información en la base de datos, para lo que hace uso de la directiva INSERT.

A modo de ejemplo, la siguiente figura muestra el aspecto de la base de datos una vez comenzada la

fase de aprendizaje, donde observan los distintos parámetros especificados que forman parte del

perfil de actividad almacenado.

Figura 8.3 Módulo de contexto de sistemas: SystemContextDB.

Por otra parte, durante la fase de detección de anomalías, el módulo de procesado de la información

consulta la base de datos para la obtención de información acerca del perfil del sistema

comprometido, para lo que ejecuta el comando SELECT. Como resultado de esta consulta, el módulo

de procesado de la información recibe aquellas filas de la base de datos cuyo sistema se corresponda

con el sistema comprometido, y la franja horaria sea equivalente a la franja horaria del momento de

detección de la intrusión.

8.1.3.2 Contexto de Red

Por su parte, el contexto de red también está formado por tres componentes principales: un

capturador de tráfico, un módulo de procesado de la información y la base de datos que contiene el

perfil de actividad de la red monitorizada.

Capturador de tráfico

Tras un análisis realizado, en el desarrollo del módulo de contexto de red implementado como parte

de la validación de la arquitectura del AIRS basado en ontologías, se utiliza SANCP como capturador

de tráfico. Una descripción más detallada de este sistema se proporciona más adelante en este

capítulo (Ver 8.4.2).


El objetivo de este componente es la correlación de la información recibida del capturador de tráfico

en tiempo de detección con la información almacenada en la base de datos durante la fase de


252

aprendizaje relativa al tráfico habitual en la red o subred bajo monitorización. Desde el punto de vista

de la implementación del mismo, este módulo es un programa Java que se compone de un paquete

principal llamado netContext que está compuesto por un interfaz y un conjunto de clases de carácter

general, además de por una serie de subpaquetes. A continuación se detalla la función de cada uno

de los subpaquetes de forma general:

- correlatorEngine: paquete encargado de realizar la correlación entre el perfil que genera con

la información que obtiene de DAO y la Snapshot (información instantánea capturada). Como

resultado devuelve un número que contiene el grado de anomalía de la red.

- DAO: paquete que se encarga del acceso a una base de datos que contiene toda la

información capturada durante la fase de aprendizaje comentada. Tendrá funciones tanto de

consulta como de inserción.

- Sancp: su principal función es conseguir generar la Snapshot comentada mediante la puesta

en funcionamiento del programa SANCP en modo realtime y realizar el procesado de dicha

información.

- Converter: el objetivo de este paquete es realizar la operación de parseo de una línea del log

de SANCP y procesarla. Para ello hay que destacar que el formato indicado en sancp.conf

debe coincidir con el utilizado en dicho paquete.

- infoLoader: este paquete es el encargado de procesar un archivo del log completo, por ello

también hará uso del paquete converter.

- util: este paquete ha sido desarrollado para aportar una serie de funciones que ayuden y

simplifiquen el resto de paquetes, sin pertenecer de forma natural a ninguno de ellos.

Como resultado de este módulo se obtiene un parámetro que se representa con un número del 0 al

10, y se corresponden con la anomalía detectadas por la función de correlación sobre el tráfico de

red. Además éste será el valor que devuelva este módulo como respuesta a la petición del

Razonador.

El proceso de correlación es bastante complejo, pero se intentará dar una idea del procedimiento

seguido para llegar al resultado. En primer lugar se genera un objeto de tipo Profile, a partir del

acceso a la información de la base de datos mediante el uso de la interfaz correspondiente, que

devuelve las conexiones que servirán para generar el perfil. Las conexiones que son seleccionadas

de la base de datos dependen fundamentalmente del momento del día en el que se produjeron y del

día de la semana, permitiendo así comparar periodos que teóricamente deberían tener unas

características muy similares. El rango de conexiones según el momento del día se ha establecido en

un margen de diez minutos centrado en el instante en el que se produce la detección de un posible

ataque para poder operar con más información y ser más eficaces a la hora de encontrar

coincidencias entre la Snapshot y el Profile.

Una vez obtenido el perfil se pasa a la fase de comparar las coincidencias de los parámetros entre las

distintas conexiones de la Snapshot y el Profile. A partir de esos resultados nos quedamos con las

coincidencias máximas de cada conexión de la Snapshot, de las cuales finalmente se obtendrá un

número del cero al treinta proveniente de la media y la desviación típica de dichas coincidencias

máximas, ya que lo que se pretende como un objetivo final es obtener la anomalía general de la red.

Por otro lado se calcula la anomalía de carga observando el tamaño de los paquetes y la velocidad

que está soportando la red en comparación con la información indicada en el perfil. Para comparar los

tamaños de los paquetes el perfil ofrece el número de paquetes y la información intercambiada en

toda la conexión en los dos sentidos, por lo que para compararlo con el paquete capturado en

realtime, el total de información intercambiada hay que dividirla entre el número de paquetes. En este

punto es importante distinguir entre los dos sentidos de la comunicación, que vendrá establecido por

el sentido que tenga algún dato en la conexión capturada por la Snapshot. Finalmente se establece el

grado de anomalía de cada paquete en función de una densidad de probabilidad definida por la media


253

y la varianza, y el grado de anomalía general de este punto será la media de las anomalías de los

distintos paquetes capturados, que tendrá un valor del cero al diez.

El cálculo de la anomalía en la velocidad soportada por la red también es algo compleja, ya que

también involucra el uso de una función de probabilidad para tener en cuenta tanto la media como la

varianza de la carga. Para establecer la función el procedimiento que se ha seguido ha sido la

división de las conexiones del perfil en grupos separados según los distintos minutos del día al que

perteneciesen. Dentro de cada grupo se calcula la carga media, basándose en la duración, tiempo y

bytes totales (incluyendo cabeceras) de cada conexión. Esto tiene como resultado un conjunto de

valores que representan la carga media de la red en cada uno de los minutos, que se usarán para

definir la función de probabilidad mediante el uso de su media y desviación. El resultado vendrá dado

por la comparación de la carga en el momento de la toma de la Snapshot mediante un método donde

se tiene en cuenta la duración total de la misma, y comparándola con la función mencionada del perfil

da como resultado un número del cero al diez representando la anomalía en la carga.

La clase encargada de las estadísticas, que realmente esa probabilidad será la confianza o

desconfianza en la Snapshot, es la clase LoadStatistics, con la cual no sólo definimos la función sino

que somos capaz de realizar una estimación de su integral mediante el uso de una tablas variables,

que para el propósito de este proyecto proporcionan un margen de error más que aceptable.

Para obtener el número final que representa la anomalía del contexto de red, simplemente es

necesario combinar de forma lineal estas tres anomalías parciales de tal forma que el resultado total

sea un número del 0 al 10, siendo 10 la máxima anomalía posible.

Base de datos

Componente de la arquitectura del módulo de contexto de red cuyo objetivo es almacenar la

información relativa al tráfico habitual de la red durante la fase de aprendizaje, y proporcionar dicho

perfil de tráfico durante la fase de detección de anomalías.

En el prototipo desarrollado se utiliza MySQL para la creación de la base de datos, denominada

NetContextDB. Como se observa a continuación, esta base de datos contiene únicamente una tabla

denominada CONNECTION, donde se almacena la información de las distintas conexiones en la fase

de aprendizaje. Los distintos atributos de la tabla CONNECTION corresponden a: clave de

identificación autonumérica, fecha, día de la semana, momento del día, duración de la conexión,

protocolo de Ethernet, protocolo de IP, puerto de origen, puerto de destino, IP de origen, IP de

destino, número de paquetes de origen, número de paquetes de destino, número de bytes recibidos

sin contar cabeceras, número de bytes enviados sin contar cabeceras, número de bytes totales

contando cabeceras. El día de la semana y el momento dentro del día han sido incluidos como

atributos para poder realizar las consultas teniendo en cuenta el factor temporal de una forma sencilla

y eficiente.


254

Durante la fase de aprendizaje el módulo de procesado de la información es el encargado de insertar

nueva información en la base de datos, de la forma mostrada a continuación:

A modo de ejemplo, la siguiente figura muestra el aspecto de la base de datos una vez comenzada la

fase de aprendizaje, donde observan los distintos parámetros especificados que forman parte del

perfil de tráfico almacenado, información obtenida de los logs de SANCP.

CREATE DATABASE NetContextDB;

CREATE TABLE IF NOT EXISTS CONNECTION (

id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,

date VARCHAR(32) NOT NULL DEFAULT '',

day_week INT,

time INT,

duration LONG,

eth_proto INT,

ip_proto INT,

portOr INT,

portDes INT,

ipOr VARCHAR(32) NOT NULL DEFAULT '',

ipDes VARCHAR(32) NOT NULL DEFAULT '',

src_pkts INT,

dst_pkts INT,

src_bytes INT,

dst_bytes INT,

total_bytes INT

);

insert into CONNECTION (date, day_week, time, duration, eth_proto, ip_proto, portOr, portDes,

ipOr, ipDes, src_pkts, dst_pkts, src_bytes, dst_bytes, total_bytes) VALUES ('2010-02-26

20:05:08',6,1205, 156,8, 6,33003,443, '192.168.172.136', '209.85.227.17' , 105, 146, 14177,

145988, 173840);


255

Figura 8.4 Módulo de contexto de sistemas: NetContextDB.

Por otra parte, durante la fase de detección de anomalías, el módulo de procesado de la información

consulta la base de datos para la obtención de información acerca del perfil de tráfico de la red,

ejecutando un comando de la siguiente forma:

En esta consulta se observa que aparte de solicitar todos los atributos (a excepción de la clave de

identificación primaria que no es interesante para este propósito) se restringen las conexiones

buscadas a las que se hubiesen obtenido en el mismo día de la semana que cuando se está

produciendo la posible intrusión y en el mismo momento del día. De esta forma nos aseguramos que

el perfil que se generará está compuesto por conexiones que son relevantes a la hora de realizar la

correlación y el grado de anomalía se ajuste al máximo a la realidad de la situación de nuestra red.

8.1.3.3 Receptor de Contexto

Componente de la arquitectura que recibe la información relativa a la anomalía en el contexto de red

y de sistemas procedentes de los módulos encargados de obtenerla, y mapea dicha información a los

conceptos equivalentes definidos en la ontología. Una vez que la información ha sido convertida a

lenguaje OWL2, este componente devuelve el control al Razonador para que comience el proceso de

inferencia propiamente dicho.

Desde el punto de vista de su implementación, este componente es un programa Java que utiliza el

API de Jena para su interacción con la ontología de respuesta a intrusiones. A modo de ejemplo, las

siguientes líneas de código muestran cómo el Receptor de Contexto crea un nuevo ejemplar de la

clase NetworkContext de la ontología y asigna el valor correspondiente a sus atributos, para lo que

utiliza la información de proporcionada por el contexto de red relativa al grado de anomalía presente

en la red en momento de intrusión.

String select = "SELECT C.`date`, C.`day_week`, C.`time`, C.`duration`, C.èth_proto`, C.ìp_proto`, C.`portOr`, C.`portDes`, C.ìpOr`, C.ìpDes`, C.`src_pkts`, C.`dst_pkts`, C.`src_bytes`, C.`dst_bytes`, C.`total_bytes` FROM CONNECTION C where day_week=" + day1 + " AND time >= " + time1 + " AND time <= " + time2;


256

OntClass class_NetworkContext = ontologyModel.getOntClass(PREFIXIND+

"NetworkContext");

String idnc = "network"+ide;

Individual resNuevo = ontologyModel.createIndividual(PREFIXIND + idnc,

class_NetworkContext);

Property prop;

ejemplarContextoRedNuevo = idnc;

if(Integer.toString(anomaly)!= null){

Literal netanomaly = ontologyModel.createTypedLiteral(anomaly);

prop = ontologyModel.getProperty(PREFIXIND + "networkAnomaly");

resNuevo.setPropertyValue(prop, netanomaly);

}

8.1.3.4 Integración en la arquitectura del AIRS basado en

ontologías

La integración de estos tres componentes (Contexto de Sistemas, Contexto de Red y Receptor de

Contexto) con la arquitectura del AIRS basado en ontologías, se lleva a cabo en dos fases:

- En primer lugar, el Razonador, cada vez que recibe una alerta de intrusión, invoca a los

módulos de contexto para obtener la anomalía existente en dicho instante. Para ello, ejecuta

las siguientes llamadas:

/*Invocamos al contexto de red para la obtención de la anomalía de

red*/

INetContext i=NetContextFactory.getInstance().getInterface();

Int networkAnomaly = i.obtainNetContext();

/*Invocamos al context de sistemas para la obtención de la

anomalía en el sistema en momento de intrusión */

ISystemContext

iSystem=SystemContextFactory.getInstance().getInterface();

SystemAnomaly an=iSystem.obtainSystemContext(targetIDValue);

an.printAnomaly();

- En segundo lugar, cuando los módulos de contexto han calculado los valores de anomalía

correspondientes, y el Receptor de Contexto ha mapeado la información a la ontología, éste

devuelve el control al Razonador, pasándole un código de éxito o error. El Razonador

comprueba si el contexto ha sido añadido en la ontología de respuesta a intrusiones con

éxito, tras lo que comienza la inferencia de la respuesta óptima.

8.1.4 Ontología de respuesta a intrusiones

Este componente ha sido explicado con detalle en el Capítulo 5 de la presente memoria.

Respecto a su integración en la arquitectura del AIRS basado en ontologías desde el punto de vista

de su interacción con el Razonador, cabe especificar que en el prototipo implementado el Razonador

utiliza el API de Jena para leer y escribir en la ontología de respuesta a intrusiones. Cuando el

Razonador se arranca, la primera acción que realiza es leer la ontología y guardar una copia de la

misma como un objeto de la clase OntModel, para lo que ejecuta lo siguiente:

System.out.println("Leyendo la ontología ...");

synchronized (ontologyindividuos) {

OntModel ontologyModel =

ModelFactory.createOntologyModel(OntModelSpec.OWL_MEM);

RDFReader inf_modelReader = ontologyModel.getReader();


257

inf_modelReader.setProperty("WARN_UNQUALIFIED_RDF_ATTRIBUTE",

"EM_IGNORE");

inf_modelReader.read(ontologyModel, ontologyindividuos);

}

Una vez finalizado el proceso de inferencia de la respuesta óptima y calculado el éxito de la acción de

respuesta, el Razonador actualiza la información obtenida en la ontología de respuesta a intrusiones,

para lo que utiliza la API de Jena.

8.1.5 Políticas


gobernar el proceso de inferencia de la respuesta óptima llevado a cabo por el Razonador. Las

políticas se expresan mediante reglas SWRL, lenguaje de representación de comportamiento

utilizado en el diseño e implementación del AIRS basado en ontologías.

En el Apéndice II se incluyen todas las reglas especificadas para el desarrollo del prototipo del

sistema de respuesta.

En cuanto a su integración con el Razonador, éste debe ejecutar todas las reglas durante el proceso

de inferencia para lo que utiliza el API de Jena.

8.1.6 Razonador

Componente principal de la arquitectura del AIRS. Desde el punto de vista de su implementación es

un programa Java multihebra, es decir, permite ejecutar varias inferencias en paralelo, lo que permite

aumentar su rendimiento como se verá más adelante en este capítulo. El valor del número de

inferencias puede ser configurado por el administrador, y puede ser tan alto como se desee. No

obstante, no se recomienda utilizar un número muy elevado de hebras puesto que podría dar lugar a

problemas de inconsistencias con la ontología. En el prototipo desarrollado se utilizan 4 hebras.

Sus funciones principales se han definido previamente (Ver 4.4.1.2) y su integración con el resto de

módulos de la arquitectura se define a lo largo de este capítulo.

Cada vez que el Receptor de Alertas recibe una intrusión procedente de un IDS, se crea una

instancia del Razonador (clase Java OntAIRS), tras lo que se inicializa dicha instancia mediante la

ejecución de las siguientes líneas de código:

OntModel inferedModel =

ModelFactory.createOntologyModel(PelletReasonerFactory.THE_SPEC,

null);

inferedModel.read(ontologyrules);

inferedModel.add(ontologyModel);

inferedModel.prepare();

En primer lugar se crea una instancia de la clase OntModel indicando que el razonador semántico

utilizado es Pellet, razonador seleccionado tras el análisis incluido en el Capítulo 3. A continuación, se

lee el fichero que contiene las reglas SWRL especificadas y se asocia al modelo creado, tras lo que

se añade otro modelo que contiene la información contenida en el momento específico en la ontología

de respuesta a intrusiones (variable ontologyModel). Como último paso de la fase de inicialización del

Razonador se ejecuta el método prepare(), que permite que el razonador semántico infiera nuevo

conocimiento a partir de la base de hechos y las reglas SWRL.

Una vez inicializado, el Razonador comprueba si la alerta de intrusión recibida se refiere a una

intrusión ya existente o es una alerta nueva, tras lo que invoca a los módulos de contexto. A


258

continuación, infiere el conjunto de respuestas recomendadas y óptimas para lo que utiliza la

información contenida en la ontología de respuesta a intrusiones y las reglas SWRL. Una vez inferida

la respuesta óptima, invoca al módulo de ejecución de respuestas y tras finalizar su ejecución, invoca

al sistema de evaluación del éxito de una acción de respuesta. Por último, actualiza el valor de RTE

asociado a la acción de respuesta desplegada en la ontología para que sea tenido en cuenta en

posteriores inferencias.

8.1.7 Catálogo de acciones de respuesta

Para la validación del sistema se ha utilizado el siguiente conjunto de acciones de respuesta, que se

implementan por medio de plugins. Estos plugins deben ser registrados previamente en el gestor de

plugins, como se ha indicado en la definición de la arquitectura propuesta.


259

Figura 8.5 Catálogo de Acciones de Respuesta implementadas como plugins para la validación del AIRS [Guaman13]


260

8.1.8 Ejecutor de acciones de respuesta

El módulo de ejecución de acciones de respuesta es el componente de la arquitectura encargado de

poner en marcha mecanismos reales para ejecutar la respuesta inferida por el Razonador,

proporcionando los argumentos e instrucciones necesarias a los dispositivos de seguridad del

sistema encargados de hacer efectiva la respuesta. Para ello, consulta el catálogo de respuestas

disponible, denominado en la arquitectura como Response Toolkit o Catálogo de Acciones de

Respuesta. Su arquitectura se describe en el Capítulo 4, donde se indica que este módulo se

compone de 5 módulos principales (Ver Figura 4.7): Módulo Central de Ejecución (MCE), Módulo de

Comunicación (MC), Agente de Ejecución (AE), Gestor de plugins y Dispositivos o componentes de

Seguridad (DS). En este apartado se proporcionan los detalles más relevantes de dichos módulos

desde el punto de vista de su implementación.

8.1.8.1 Módulo central de ejecución

Una vez que el Razonador infiere la respuesta óptima, este invoca al MCE (Módulo Central de

Ejecución) que recibe una cadena con el nombre de la respuesta inferida y los parámetros requeridos

para su ejecución, para lo que envía dichos parámetros dentro de un objeto de la clase

ResponseActionParams. La implementación de este módulo para el desarrollo del prototipo se divide

en dos partes:

- Definición y parseo de los parámetros fijos que deben ser provistos por el administrador, en

los ficheros de configuración (airsResponseExecutor.conf y plugin-numbers.conf). Estos

ficheros de configuración incluyen:

Grupo de agentes de ejecución hacia donde se envían las solicitudes de respuesta.

Cada agente de ejecución contiene información para su localización: dirección IP,

puerto y contraseña de cifrado.

Grupo de identificadores de alerta (Signatures ID), que determina ante qué

intrusiones, identificadas por su SID, es posible ejecutar una acción de respuesta.

Identificador de plugin. Este valor es, como su nombre indica, el identificador de cada

plugin utilizado para ejecutar una acción de respuesta. Mediante este parámetro se

asegura que sobre el otro extremo de la comunicación, es decir sobre el agente de

ejecución, se ejecute únicamente el plugin que coincida con este valor.

Duración de la respuesta (duration), que determina el intervalo de tiempo durante el

que tendrá efecto una acción de respuesta.

Modo de ejecución (mode), que determina el criterio en base al cual se ejecuta una

acción de respuesta basada en red. En función del tráfico de entrada (in), salida (out),

entrada y salida (inout) o de una conexión específica (conn). Esta opción se hereda

de SnortSam.

Identificación del atacante (who), que indica la dirección IP del atacante. De esta

forma, se pretende evitar ejecutar equivocadamente una acción de respuesta y

ocasionar un impacto mayor en la red de la organización que el ocasionado por el

atacante.

Identificación de respuesta compuesta (composed), que indica si la respuesta está

constituida por varias acciones.

Respuestas (responses), que indica las respuestas simples que conforman la

respuesta compuesta, en caso de que el campo anterior sea verdadero.

- Implementación de la lógica de control para seleccionar los parámetros necesarios para

ejecutar una respuesta y que serán enviados posteriormente al módulo de comunicaciones a

través de la interfaz MC-MCE.


261

8.1.8.2 Módulo de comunicación y Agente de ejecución

La funcionalidad requerida por el módulo de comunicación y el agente de ejecución, pueden ser

provistas en su mayoría por la herramienta SnortSam y por consiguiente como parte del proceso de

diseño de la arquitectura del módulo de ejecución de acciones de respuesta se decidió reutilizar

dichos componentes. Por esta razón la implementación de ambos componentes se aborda en una

sola sección, y el propósito es mencionar únicamente aquellos cambios relevantes realizados para

adaptarlos al AIRS basado en ontologías.

En el caso del MC (Módulo de Comunicación) es necesario definir una interfaz de comunicación entre

el MC y el MCE. SnortSam está conectado a Snort como un plugin de salida, por lo que la primera

tarea llevada a cabo en la implementación de este módulo es la modificación y adaptación del código

de tal forma que sea posible acoplarlo al MCE. Para ello, se ha adaptado SnortSam de tal forma que

los parámetros necesarios para emitir la solicitud y la información de los agentes de ejecución sobre

los que se ejecuta la respuesta sean provistos al módulo de comunicación como parámetros de

entrada al método main.

Por otra parte, es necesario especificar un protocolo de comunicación que permita comunicar el MCE

y los agentes de ejecución a través del módulo de comunicación. Para la especificación de dicho

protocolo se han tenido en cuenta las siguientes consideraciones:

- El formato de paquete de solicitud debe incluir todos los parámetros necesarios tanto para el

establecimiento y cifrado de la comunicación como para la ejecución de la respuesta. La

siguiente figura muestra el formato utilizado.

Figura 8.6 Formato de paquete de solicitud del módulo de ejecución de respuestas. [Guamán13]

Los campos SourceIP, DestinationIP, Duration, SrcPrt, DstPort, Protocol, SID Mode, Plugin y

User contienen la información que será usada por los agentes de ejecución y su respectivo

plugin para la ejecución de una acción de respuesta. Los campos agentSeqNo y airsSeqNo

son utilizados para intercambiar números de secuencia necesarios en el proceso de cifrado y

descifrado.

- Se define un conjunto de mensajes a intercambiar entre el MCE y los agentes de ejecución.

El tipo de mensaje está determinado por el campo Status del formato de paquete establecido

anteriormente. SnortSam define los siguientes tipos de mensajes:

Desde el MCER hacia el agente de ejecución:

Checkin (status=1): es el primer mensaje que envía el MCE hacia el agente

de ejecución y su objetivo es intercambiar el modificador de clave y números

de secuencia utilizados para cifrar la información.

Block (status=3): constituye la solicitud de acción de respuesta.

Unblock (status=4): es una solicitud para deshacer una acción de respuesta.

Checkout (status=2): es una solicitud de desconexión, además en el agente

de ejecución se eliminan todas las tablas asociadas al MCE que envió dicha

solicitud.

Desde el agente de ejecución hacia el MCE:


262

Ok (status=4): indica el éxito de la ejecución de una respuesta. Es

importante indicar, que este mensaje no indica que la respuesta haya tenido

efecto, únicamente valora que se pudo ejecutar la respuesta.

Error (status=5): es un mensaje que indica que la acción de respuesta no

pudo ser ejecutada.

NewKey (status=6): el agente de ejecución solicita al MCE la definición de

una nueva clave de cifrado.

Resynk (status=7): el agente de ejecución solicita una resincronización de

los números de secuencia y modificadores de contraseña.

Hold (status=8): el agente de ejecución solicita que el MCE no cierre la

conexión tras ejecutar una acción de respuesta.

Como se ha indicado en la descripción del MC, este código puede ser “Ok (status=4)”, en caso de

que la respuesta se haya podido ejecutar sin problemas, o “Error (status=5)” en caso de que la acción

de respuesta no haya podido ser ejecutada.

8.1.8.3 Gestor de plugins

Como se indica previamente en la presente memoria, el objetivo de este componente del módulo de

ejecución de acciones de respuesta es permitir el despliegue de nuevas acciones de respuesta de la

forma más simple posible. Para ello, se define una interfaz de registro a través del cual se deben

proveer un conjunto de parámetros necesarios para la ejecución de una respuesta sobre un

componente de seguridad determinado.

Desde el punto de vista de su implementación, se define un fichero denominado plugin.h que permite

el registro de un nuevo plugin a través de la estructura PLUGINREGISTRY:

Cada vez que se desea registrar un nuevo plugin en el agente de ejecución, es necesario

proporcionar un conjunto de parámetros, como por ejemplo, un puntero a la estructura que contiene

los componentes de seguridad asociados al plugin, el nombre del fichero agent.conf a parsear, un

identificador del plugin, o un indicador de si el plugin requiere una ejecución multihebra.

8.1.8.4 Dispositivos de seguridad

Representan los dispositivos que llevan a cabo la acción de respuesta real utilizando su interfaz de

línea de comandos. Un dispositivo de seguridad puede ser: un router, cortafuegos, servidor web,

servidor FTP, gestor de usuarios, gestor de procesos, etc. En la validación del AIRS basado en

ontologías se utilizan diferentes dispositivos de seguridad, como se observa en el escenario de

validación.


263


ontologías

La integración del módulo de ejecución de respuestas en la arquitectura del sistema de respuesta se

realiza mediante la comunicación entre el MCE y el Razonador. Ambos componentes están

desarrollados en Java y para permitir una comunicación entre ellos se ha definido una interfaz de

comunicación a la que se denomina Razonador-MCE. Cada vez que el razonador infiere una acción

de respuesta óptima, invoca al módulo central de comunicación de la siguiente manera:

CentralModuleExecution(String inferredResponseName,

ResponseActionParams paramsAlert)

La cadena inferedResponseName es el nombre de la respuesta inferida y se corresponde con el valor

de la propiedad responseAction de la ontología del AIRS. Además, en la llamada el Razonador debe

proporcionar una instancia de la clase ResponseActionParams que contiene los parámetros

relacionados a la intrusión y que serán utilizados por el MCE para ejecutar una respuesta.

Una vez que la respuesta ha finalizado su ejecución, el módulo enviará un mensaje al Razonador del

AIRS, que contiene un código de éxito o error. En caso de éxito, el Razonador invocará al sistema de

evaluación del éxito de la respuesta, que se encargará de evaluar si la respuesta ha sido ejecutada

con éxito, es decir, ha conseguido mitigar el ataque, o por el contrario, no ha tenido efecto sobre él.

8.1.9 Sistema de evaluación del éxito de la respuesta

En el Capítulo 7 se proporciona una descripción detallada de este componente desde el punto de

vista del diseño de su arquitectura. Respecto a su implementación, este módulo está desarrollado en

Java, al igual que la mayoría de los componentes presentes en la arquitectura del sistema de

respuesta.


ontologías

La arquitectura del sistema de evaluación presentada en la Figura 7.4 muestra la comunicación que

se establece entre algunos módulos del AIRS basado en ontologías y el sistema de evaluación. Para

una correcta integración del sistema de evaluación en el sistema de respuesta es muy importante

definir de forma clara y precisa las interfaces entre todos los módulos, estableciendo los parámetros

necesarios.

Entendiendo el sistema de evaluación como una caja negra, durante la fase de integración del mismo

con el AIRS basado en ontologías para su funcionamiento en modo “execution”, ha sido necesario

modificar dos componentes de la arquitectura del sistema de respuesta: Reasoner y la ontología de

respuesta a intrusiones.

En lo que se refiere a la ontología, se han añadido 2 propiedades a la clase Response de la

ontología: numExecutions y responseEfficiency. La primera representa cuantas veces se ha

ejecutado una respuesta específica, y la segunda el porcentaje de éxito de la respuesta desde que

fue ejecutada la primera vez hasta el momento actual. Para incluir estas propiedades en la ontología

tan sólo es necesario añadir dos “DataTypes properties” al fichero owl correspondiente especificando

su dominio y rango:

- numExecutions es una propiedad cuyo dominio es la clase Response y cuyo rango es un

número entero superior a 0.

- responseEfficiency es una propiedad cuyo dominio es la clase Response o Result, cuyo valor

es un número decimal (double) comprendido entre 0.00 y 100.00.


264

En el caso del razonador, los cambios han consistido en:

- Incluir en el Reasoner la llamada al sistema de evaluación, proporcionando en esa llamada

los parámetros necesarios para ejecutar el sistema en el modo de funcionamiento

“execution”.

- Utilizar la salida del sistema de evaluación de la forma adecuada.

Respecto al primer punto, cuando termina la ejecución de la respuesta inferida sin errores, el

razonador invocará al sistema de evaluación del éxito de la siguiente manera:

ExecutionModeParams ex_params = new ExecutionModeParams(responseID, responseType,

intrusioType, targetIP, intrusionAnomaly, additionalParams);

EvaluationSystemModeSelector sel = new EvaluationSystemModeSelector(“execution”, ex_params);

sel.start());

- En primer lugar se crea un objeto ExecutionModeParams que contiene todos los parámetros

que se van a pasar en la llamada al sistema de evaluación. Estos son:

String responseID, es el identificador de la respuesta ejecutada cuyo éxito se quiere

calcular.

String responseType, es el tipo de la respuesta.

String intrusionType, es el tipo de la intrusión obtenido de la alerta enviada por el IDS.

String targetIP, representa la dirección IP del sistema comprometido por el ataque.

HashMap intrusionAnomaly, contiene el nivel de anomalía de la red y de los sistemas

en el momento en el que la intrusión fue detectada y comenzó la inferencia de la

respuesta óptima.

String[] additionalParams, son parámetros adicionales opcionales que se pueden

pasar al sistema de evaluación.

- En segundo lugar se invoca al sistema indicando el modo de funcionamiento, “execution” en

este caso, y proporcionándole el objeto ExecutionModeParams.

- Por último se inicia la evaluación del éxito de la respuesta.

Una vez que el sistema de evaluación calcula la nueva tasa de éxito, devuelve al razonador un código

que indica que no ha habido ningún error en el proceso de evaluación del éxito de la respuesta. En

ese caso, el razonador solicita los parámetros obtenidos mediante la siguiente llamada:

ResponseTotalEfficiency resp = sel.getExecutionModeResult();

Como resultado recibe un objeto de la clase ResponseTotalEfficiency que contiene el identificador de

la respuesta (responseID), la tasa de éxito actualizada (responseEfficiency) y el número de veces que

se ha ejecutado la respuesta (numExecutions).

En este punto, es el razonador el responsable de almacenar estos resultados en la ontología de

respuesta a intrusiones, para que puedan ser utilizados en posteriores inferencias. Como se indicó en

los capítulos 4 y 6 de esta memoria, el razonador infiere la respuesta óptima en base a un conjunto

de métricas especificadas mediante reglas SWRL: métrica de reducción de daño, métrica de mínimo

coste y métrica de máxima severidad y máxima eficiencia (Ver 6.4). En esta última métrica, uno de los

parámetros más relevantes es la tasa de éxito de la respuesta en anteriores ejecuciones, parámetro

representado como RTE. El valor de este parámetro es la salida del sistema de evaluación del éxito

de la respuesta, que posteriormente ha sido actualizada en la ontología por el razonador del sistema.

No obstante, como se indicó en las consideraciones de la metodología de evaluación, una vez

integrado el sistema de evaluación en el AIRS basado en ontologías, el valor de RTE obtenido en las

primeras inferencias y ejecuciones de cada respuesta es inestable, provocando un cierto


265

comportamiento inestable en el sistema de respuesta. Por ello, si el número de ejecuciones de una

respuesta es bajo, se recomienda no utilizar el valor de RTE en la métrica de máxima severidad y

máxima eficiencia, infiriendo en este caso la respuesta cuya severidad es mayor (Ver 6.4.2).

En cuanto a la integración del sistema de evaluación desde el punto de vista del modo de

funcionamiento “training”, tan sólo ha sido necesario modificar la ontología de respuesta a intrusiones,

añadiendo 2 propiedades a la clase SomeThreat de la ontología: successThresholdHigh y

successThresholdLow. Estas propiedades representan el umbral de éxito superior e inferior asociado

a un tipo de amenaza específica. Para incluir estas propiedades en la ontología tan sólo es necesario

añadir dos “DataTypes properties” al fichero owl correspondiente especificando su dominio y rango:

- successThresholdHigh es una propiedad cuyo dominio es cualquier subclase de la clase

SomeThreat y cuyo rango es un número decimal (double) comprendido entre -1.00 y 1.00.

- successThresholdLow es una propiedad cuyo dominio es cualquier subclase de la clase

SomeThreat y cuyo rango es un número decimal (double) comprendido entre -1.00 y 1.00.

No es necesario modificar ninguno de los demás módulos de la arquitectura del sistema de

respuesta, puesto que el AIRS basado en ontologías no puede entrenar al sistema de evaluación, y

tampoco utiliza la salida proporcionada en ningún punto del proceso de inferencia de la respuesta

óptima. La ejecución del sistema de evaluación en modo entrenamiento es responsabilidad del

administrador del sistema, que será el encargado de proporcionarle los parámetros requeridos en su

llamada. Por otra parte, es el propio sistema de evaluación el encargado de almacenar los umbrales

de éxito superior e inferior correspondientes a un tipo de intrusión en la ontología.

Las pruebas unitarias realizadas con el fin de evaluar la funcionalidad de cada uno de los módulos

implementados, así como las destinadas a la evaluación de la integración han dado resultados

satisfactorios, validando de esta forma la viabilidad de la utilización de ontologías, lenguajes de reglas

y razonadores semánticos como núcleo de un sistema de respuesta automática frente a intrusiones.

8.4 Validación del AIRS basado en ontologías en una

arquitectura de red

Una vez desarrollado el prototipo de arquitectura del AIRS basado en ontologías incluyendo la

implementación de todos los módulos que lo componen, el objetivo de la segunda parte de la fase de

validación es la integración y ejecución de dicho prototipo en un escenario de red que pretende

emular la topología de red de una organización típica. Durante esta fase se ejecutan distintos tipos de

ataques que comprometen diferentes activos de la red, y se describe, a modo de ejemplo, el proceso

de inferencia de la respuesta óptima llevado a cabo por el sistema de respuesta a intrusiones basado

en ontologías propuesto para uno de los ataques ejecutados. Esta validación del prototipo implica la

validación de las cuatro propuestas de esta tesis doctoral.

Además, en esta sección se proporcionan los resultados obtenidos tras llevar a cabo una serie de

experimentos orientados a evaluar el rendimiento del AIRS basado en ontologías en términos del

tiempo de inferencia y a evaluar los resultados obtenidos por el sistema de evaluación del éxito de las

acciones de respuesta inferidas por el sistema.

8.4.1 Escenario de Validación

Para la validación del prototipo de arquitectura del sistema de respuesta automática frente a

intrusiones basado en ontologías desarrollado, se ha utilizado la red que se muestra en Figura 8.7.

Esta arquitectura de red intenta emular la topología de red que posee normalmente cualquier

organización, con diferentes subredes y tipos de equipos. Como se muestra en la figura, una gran

parte del escenario ha sido implementado utilizando la herramienta de virtualización VNX (Virtual

Network over X) [Galan10 ]. La red está formada por:


266

- Cuatro subredes:

Una subred DMZ (Zona Desmilitarizada): constituida por los servidores públicos de la

organización, como por ejemplo un servidor web, un servidor DNS y un servidor Linux

Metasploitable, un servidor Linux Ubuntu 8.04 con varias vulnerabilidades conocidas

para poder realizar distintos ataques.

Una subred en la que se encuentran los servidores más importantes para la

organización (INTNet3), en este caso cuenta con un servidor de BBDD y un servidor

Tomcat.

Dos subredes a las que están conectados ordenadores con S.O. Linux y Windows y

que corresponden a los empleados de la organización (INTNet1 e INTNet2).

Subred a la que perteneced el host donde reside el AIRS basado en ontologías

(IDSNet).

- 5 tipos de componentes:

4 IDSs instalados en la red, cuyo objetivo es detectar comportamiento anómalo en la

red o los sistemas y enviar la alerta de intrusión correspondiente al AIRS basado en

ontologías en formato syslog:

Tres NIDSs (Snort): IDS1, IDS2 e IDS3.

Un HIDS OSSEC: IDS4.

1 Firewall perimetral (IPTables) a través del cual atraviesa el tráfico de entrada y

salida que se intercambia entre ordenadores de la Intranet e Internet.

2 routers Cisco C3640.

1 AIRS basado en ontologías.

Varios hosts de usuario con S.O. Linux y Windows.


267

Figura 8.7 Escenario de red de validación del AIRS basado en ontologías.

En la siguiente tabla se muestra el detalle de cada uno de los componentes presentes en la red del

entorno de validación.

Tabla 8.2 Detalle de los componentes del escenario de la red de validación.

Componente Características

R1 y R2 Router Cisco C3640 Version 12.3(26)

ATT (Atacante) GNU/Linux Ubuntu 10.04.3 LTS con BackTrack 5 ó

Kali 1.0.5

INT1-1, INT2-1 GNU/Linux Ubuntu 9.10

INT1-2, INT2-5, INT3-1

GNU/Linux Ubuntu 11.04

INT1-3, GNU/Linux Ubuntu 10.04

INT1-4, INT2-4 Windows 7

INT2-2, INT2-6 GNU/Linux Ubuntu 12.04

INT2-3 Windows XP Service Pack 3

BBDD/IDS4 GNU/Linux Ubuntu 11.04 HIDS OSSEC versión 2.7

DMZ-1, DMZ-2 GNU/Linux Ubuntu 11.04

DMZ-3 GNU/Linux Ubuntu 8.0.4 con Metasploitable23

IDS1, IDS2, IDS3 GNU/Linux Ubuntu 10.04

NIDS Snort 2.9


GNU/Linux Ubuntu 12.10


268

8.4.2 Herramientas Utilizadas

En la validación de las propuestas se han utilizado una serie de herramientas que a continuación se

definen.

Snort

Snort es un NIDS open source que combina los beneficios de los dos métodos de detección

actualmente empleados: el método de detección basado en anomalías y el basado en usos

indebidos. La fuente de datos de Snort son los paquetes que circulan a través de una interfaz de red y

que pertenecen a los hosts que se requiere proteger. Un IDS, en la medida de lo posible, no debe

interferir con el funcionamiento normal de la red; es decir que su operación no debería introducir

retardos en la entrega de paquetes o consumir recursos computacionales y de memoria excesivos

OSSEC

OSSEC es un HIDS open source multiplataforma que básicamente cumple con tres tareas:

verificación de integridad de ficheros, monitorización y análisis de logs del sistema, y detección de

rootkits. La fuente de datos de OSSEC son los ficheros y logs que requieren ser monitorizados y que

han sido especificados por el administrador en el archivo de configuración.

En el escenario que nos ocupa, ante la detección de una intrusión, el servidor OSSEC envía una

alerta en formato syslog hacia el puerto 514 del servidor syslogd, en donde también se encuentra el

AIRS basado en ontologías que recibe las dichas alertas a través de su módulo receptor de alertas.

SANCP

SANCP (Security Analyst Network Connection Profiler) es un capturador de tráfico el tráfico

considerado como una gran herramienta de seguridad de red para Unix diseñada para crear logs de

conexiones y recoger el tráfico de red con el propósito de auditar, realizar análisis históricos

estadísticos y para el descubrimiento de actividad de red. En el caso del módulo de Contexto de Red,

se ha utilizado sobre todo para la recolección de información sobre el tráfico en la red, para generar

una serie de perfiles de comportamiento normal de la red, que serán comparados con el tráfico de red

existente en el momento de la intrusión. Hay que destacar que gracias a que engloba los paquetes

capturados en conexiones (siempre que se use el modo stat) se consigue optimizar el espacio de

disco duro que ocupa la captura, ya que hay que entender que el programa deberá estar funcionando

durante un largo periodo de tiempo para ser lo más exacto posible, y además se reducirá el tiempo de

procesado, lo que es de gran importancia ya que permite reducir el tiempo en el que se proporcionan

los resultados de la comparación al Razonador.

Su instalación y configuración son muy sencillas, únicamente cabe destacar la modificación realizada

sobre su archivo de configuración (concretamente sancp.conf), donde se especifican los datos y el

formato de los mismos que se desean capturar, de forma que se capture únicamente la información

útil para este propósito ya que la generación de perfiles supone unos requisitos de almacenamiento

en el disco duro no despreciables, y es necesario que la información se presente con el formato

utilizado en el parseo de la misma para que pueda ser procesada por la aplicación. Los modos de

captura de datos de SANCP que se han utilizado son:

- Modo stat, que permite representar los datos de cada conexión de forma conjunta, sin crear

una nueva línea en el log por cada paquete recibido. Este es el modo utilizado para la

creación de los perfiles.

- Modo realtime, para capturar los datos en el momento del ataque, ya que tiene un tiempo de

respuesta mucho menor.

NAGIOS / NRPE

Nagios es un sistema de monitorización con la arquitectura cliente-servidor cuyo funcionamiento es el

típico de este tipo de sistemas, el servidor recupera la información de los distintos sistemas clientes


269

para procesarla y generar estadísticos y perfiles, siendo los clientes son los sistemas que se desean

monitorizar. Para monitorizar los sistemas es necesaria la instalación de agentes que permitan

recoger la información del dispositivo y enviarla al servidor cuando éste la solicite. Cabe destacar que

los agentes que utiliza Nagios pueden funcionar en prácticamente cualquier sistema operativo y en

muchos tipos de terminales, lo que aporta una gran flexibilidad a este módulo de contexto

NRPE es un agente addon diseñado para permitir que se ejecuten plugins de Nagios en hosts

remotos de forma segura.

Estas herramientas son utilizadas por el módulo de contexto de sistemas para en primer lugar

generar los perfiles de actividad normal de dichos sistemas, almacenando dicha información en una

base de datos, y en segundo lugar, para capturar en tiempo de intrusión el valor de los mismos

parámetros monitorizados anteriormente con el fin de compararlos y obtener el grado de anomalía

existente.

Protégé

Protégé [Protégé] es un editor de ontologías libre y de código abierto, que proporciona herramientas

para la construcción de modelos de dominios y aplicaciones basadas en conocimiento mediante

ontologías. Protégé consta de un conjunto de estructuras que permiten crear, visualizar y manipular

ontologías definidas en varios formatos de representación, entre los que se encuentran RDFS, OWL y

OWL2 (soportado desde su versión 4.0).

Para modelar ontologías Protégé presenta dos opciones:

Editor Protégé-Frames: utilizado para construir ontologías que estén basadas en frames,

según lo establecido en el protocolo OKBC (Open Knowledge Base Connectivity). De acuerdo

a este modelo, una ontología consiste en un conjunto de clases organizadas jerárquicamente

que representan los conceptos más destacados de un dominio, un conjunto de parámetros

que describen las propiedades y relaciones de las clases y un conjunto de instancias de las

clases.

Editor Protégé-OWL: utilizado para desarrollar ontologías en OWL para la Web Semántica.

Una ontología definida en OWL debe incluir descripciones de clases, propiedades e

instancias. Este editor permite, entre otras funcionalidades, cargar y salvar ontologías OWL2,

OWL y RDF; editar y visualizar clases, propiedades y reglas SWRL gracias a la utilización de

plugins adicionales, definir características lógicas de clases como expresiones OWL, y

ejecutar razonadores como clasificadores de lógica descriptiva para evaluar la consistencia

de la ontología.

Protégé presenta una arquitectura flexible, lo que facilita la configuración y extensión de la

herramienta mediante plugins que amplían su funcionalidad, como por ejemplo Jess, plugin de Pellet

para soportar la inferencia de SWRL, y plugins de visualización de ontologías como Ontograf y

Ontoviz.

Para la creación de la ontología propuesta se han utilizado las versiones 3.1 (en un principio) y 4.2 de

Protégé, además de plugins adicionales: OntoViz y Jess en la versión 3.1 y plugin de Pellet y

Ontograf en la versión 4.2.

Jess es un plugin que permite crear y ejecutar reglas SWRL soportado en versiones de Protégé

anteriores a la 4.0. La versión 4.2 incorpora un editor de reglas denominado SWRLRules, y no tiene

soporte del plugin de Jess. Por ello, en este último caso, se ha utilizado SWRLRules para la creación

de reglas y el plugin de Pellet para su ejecución e inferencia.

Jess 7.1

Jess [Jess] es un motor de reglas escrito en Java, soportado por Protégé en versiones anteriores a la

4.0 para definir y ejecutar reglas SWRL. Jess deriva del lenguaje de programación CLIPS, por lo que

es muy rápido y ligero.


270

Jess ha sido utilizado para definir las políticas de especificación del comportamiento del sistema de

respuesta en SWRL y evaluar la ontología, probando la consistencia de la información definida y las

reglas. Mediante este plugin se ha comprobado que el sistema de respuesta a intrusiones basado en

ontologías propuesto infiere los resultados esperados.

Como se ha indicado previamente, versiones de Protégé posteriores a la 4.0 no soportan el plugin

Jess.

OntoViz

OntoViz [OntoViz] es un plugin para la visualización de ontologías en Protégé con la ayuda de un

sofisticado software de visualización gráfica llamado Graphviz [Graphviz].

Este plugin se ha utilizado para representar gráficamente las clases, propiedades y relaciones de la

ontología desarrollada. En el apartado correspondiente a la definición de clases y propiedades, dentro

de este capítulo, se incluye la jerarquía de clases, relaciones y propiedades de la ontología de

respuesta a intrusiones propuesta (Ver Figura 5.3 Ontología de Respuesta a Intrusiones).

OntoGraf

OntoGraf [OntoGraf] es un software de visualización y representación gráfica de ontologías OWL. A

partir de la versión 4.1 se incluye en la instalación por defecto de Protégé, por lo que no es necesario

instalar el plugin por separado.

Permite visualizar las clases y subclases de la ontología, y las relaciones existentes entre ellas, así

como una navegación interactiva. Pero no es posible visualizar las propiedades que caracterizan a las

instancias de las clases.

VNX

VNX [Galan10] es una herramienta de virtualización de código abierto de propósito general diseñada

para ayudar a la construcción de bancos de pruebas de redes virtuales de forma automática. Permite

la definición y la implementación automática de escenarios de redes compuestas por máquinas

virtuales de diferentes tipos (Linux , Windows , FreeBSD, oliva o routers Dynamips , etc.) conectados

entre sí siguiendo una topología definida por el usuario. El escenario virtual permite la conexión con

redes externas así como con host reales.

VNX es una herramienta útil para probar aplicaciones / servicios de red a través de bancos de

pruebas complejas compuestas de nodos y redes virtuales. Como otras herramientas similares

orientadas a crear escenarios de redes virtuales (como GNS3, Netkit, MLN o Marionnet), VNX ofrece

una forma de gestionar bancos de pruebas evitando la complejidad de inversión y de gestión

necesaria para crearlas utilizando un equipo real.

VNX se ha utilizado para la implementación de la red utilizada para la validación de las propuestas,

como se observa en la figura.

Kali Linux 1.0 / Backtrack 5R3

Back Track9 es una distribución de Linux utilizada para realizar auditorías de seguridad, que incluye

una larga lista de herramientas de seguridad listas para usar, entre las que destacan numerosos

scanners de puertos y vulnerabilidades (como por ejemplo Nmap o Nessus), archivos de exploits,

sniffers, herramientas para ataques de fuerza bruta (hydra, slowloris, john the ripper, etc.), etc. Esta

herramienta se ha utilizado para la validación del prototipo del AIRS desarrollado para ejecutar

diferentes tipos de ataque, desde la máquina atacante, con IP 10.1.100.22.

De entre todas las herramientas incluidas en la distribución cabe destacar Metasploit Framework, una

herramienta GNU escrita en Perl que cuenta con una gran cantidad de exploits para realizar

diferentes ataques a gran variedad de servicios utilizados en Internet.

9 http://www.backtrack-linux.org

http://www.backtrack-linux.org/


271

Kali Linux 1.010

, es otra distribución utilizada para la realización de auditorías de seguridad así como

de test de penetración, que surge a raíz de Backtrack, solventando algunos fallos presentados por

esta última. De la misma manera que Backtrack, la distribución Kali Linux se utiliza para la validación

de las propuestas de la presente tesis como entorno de ejecución de ataques o intrusiones.

Metasploitable

Distribución Linux preparada para realizar pruebas de seguridad en redes. Es un servidor Ubuntu

8.04 que implementa servicios que poseen configuraciones inseguras y vulnerabilidades alcanzables

desde Internet. Esta distribución se encuentra instalada en el servidor de la DMZ cuya IP es

192.168.100.132.

Para acceder al servidor será necesario utilizar una de las siguientes credenciales:

Tabla 8.3 Metasploitable: credenciales de los usuarios.

Usuario Contraseña

Msfadmin msfadmin

User user

Service service

Postgres postgres

Klog 123456789

Hay 12 servicios vulnerables incluidos en el servidor Metasploitable:

Tabla 8.4 Metasploitable: servicios vulnerables.

Servicio Puerto Tipo de conexión

ftp 21 TCP

SSH 22 TCP

TELNET 23 TCP

SMTP 25 TCP

DNS 53 TCP

DNS 53 UDP

HTTP 80 TCP

NETBIOS 137 UDP

SMB 139 TCP

SMB 445 TCP

MYSQL 3306 TCP

DISTCCD 3632 TCP

POSTGRES 5432 TCP

HTTP 8180 TCP

8.4.3 Validación del AIRS basado en ontologías ante un escaneo

de puertos contra un servidor de la DMZ

Este escenario de ataque consiste en ejecutar un escaneo de puertos desde la máquina atacante

hacia el servidor Metasploitable situado en la DMZ, con dirección IP 192.168.100.132. Para ello, el

atacante utiliza la herramienta NMAP de Kali Linux, dirigida hacia la víctima.

A continuación se detalla el proceso seguido desde la detección de la intrusión por parte del NIDS

hasta la evaluación del éxito de la respuesta llevada a cabo por el módulo de evaluación del éxito de

la respuesta del AIRS basado en ontologías.

10

http://www.kali.org/

http://www.kali.org/


272

Detección

El atacante (10.1.100.22), como “primera fase” de un ataque, intenta realizar un reconocimiento de

del objetivo, en este caso el servidor Metasploitable de la DMZ (192.168.100.132). Para ello, ejecuta

un escaneo de puertos utilizando la herramienta Nmap, de Kali Linux, con la IP destino la de la

víctima.

Todo el tráfico entrante a través de la interfaz NetATT, como especificó anteriormente es duplicado y

enviado hacia el NIDS Snort por medio de daemonlogger.

Como última fase de la detección, el NIDS Snort detecta la intrusión y genera una alerta de intrusión

en formato syslog que envía hacia el razonador AIRS.

El Receptor de Alertas de la arquitectura del AIRS, escucha a través del puerto 512 y recibe la alerta

en formato syslog.

Inferencia

Una vez la alerta ha sido recibida por el Receptor de Alertas presente en la arquitectura del AIRS, se

llevan a cabo las siguientes acciones:

- Mapeo de la alerta en formato syslog a un formato común, comprensible por el razonador. En

esta fase la alerta se expresa en lenguaje formal, para lo que se hace una equivalencia entre

los conceptos incluidos en la alerta de intrusión y su concepto equivalente en la ontología.

- Comprobación de si la alerta es una alerta repetida o es continuación de un ataque ya

existente. Para ello, el razonador realiza las siguientes consultas SPARQL para comprobar si

hay alguna alerta similar:

String sameAlert = "PREFIX individuos:

<file:///d://Tesis/Vero/ontologies/test/individuos.owl#>" +

"PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>"+

"PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>"+

"PREFIX owl: <http://www.w3.org/2002/07/owl#>"+

"PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>"+

" SELECT DISTINCT ?formattedintrusion" +

" WHERE {" +

"?threat a

individuos:"+map.get("intrusionType").toString()+ "."+

"?componente a individuos:SystemComponent ."+

"?componente individuos:hasAddress ?address ."+

"?address individuos:addressIP ?ip ."+

"FILTER (?ip =

\""+map.get("targetOfIntrusionID").toString()+"\")."+

"?formattedintrusion individuos:intrusionSeverity

?severity."+

"FILTER (?severity

="+Integer.parseInt(map.get("intrusionSeverity").toString())+") ."+

"?formattedintrusion individuos:portDest ?portd ."+

"FILTER (?portd =

"+Integer.parseInt(map.get("portDest").toString())+ " )."+

"?formattedintrusion individuos:portSrc ?ports ."+

"FILTER (?ports =

"+Integer.parseInt(map.get("portSrc").toString())+ ") ."+

"?formattedintrusion individuos:sourceOfIntrusionID ?source

."+

"FILTER (?source =

\""+map.get("sourceOfIntrusionID").toString()+"\") ."+

"?formattedintrusion individuos:intrusionDetectionTime ?idt

."+


273

"FILTER (xsd:dateTime(?idt) >=

\""+sameAlertDate+"\"^^xsd:dateTime) ."+

"?formattedintrusion individuos:hasIntrusionType ?threat;"+

"individuos:hasTarget ?componente ."+

" } ";

Y para comprobar que si es continuidad de otra existente, consulta mediante la siguiente query:

String existingIntrusion = "PREFIX individuos:

<file:///d://Tesis/Vero/ontologies/test/individuos.owl#>" +

" PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>"+

" SELECT DISTINCT ?formattedintrusion" +

" WHERE {" +

"?threat a

individuos:"+map.get("intrusionType").toString()+ "."+

"?componente a individuos:SystemComponent ."+

"?componente individuos:hasAddress ?address ."+

"?address individuos:addressIP ?ip ."+

"FILTER (?ip =

\""+map.get("targetOfIntrusionID").toString()+"\")."+

"?formattedintrusion

individuos:intrusionDetectionTime ?idt ."+

"FILTER (xsd:dateTime(?idt) >=

\""+existingIntrusionDate+"\"^^xsd:dateTime) ."+

"?formattedintrusion individuos:hasIntrusionType

?threat;"+

"individuos:hasTarget ?componente ."+

" } ";

System.out.println("COMPROBANDO INTRUSIONES EXISTENTES");

Query que = QueryFactory.create(existingIntrusion);

QueryExecution quex = QueryExecutionFactory.create(que,

inferedIndividuosModel);

ResultSet rsex = quex.execSelect();

- En caso de que sea repetida o continuación, el AIRS marca la alerta como “Complete” y no

ejecuta el proceso de inferencia. En caso de que sea una alerta referida a una nueva

intrusión, el siguiente paso es obtener la anomalía del contexto para lo que el Razonador

invoca a los módulos pertinentes.

- Como resultado de la correlación realizada, los módulos de contexto proporcionan 9

parámetros de anomalía de contexto, que son mapeados de forma adecuada al formato

común de la ontología. En esta intrusión en concreto, el parámetro que refleja mayor grado de

anomalía es el denominado networkAnomaly, que indica la variación en el tráfico de red

respecto a una situación de funcionamiento normal. Una vez que se han creado las instancias

de las clases de la ontología correspondiente, se devuelve el control al Razonador.

- El siguiente paso, consiste en la ejecución del conjunto de reglas encargado de obtener la

fiabilidad del informe de intrusión. En este caso concreto tanto la amenaza indicada por el

contexto como la amenaza incluida en el informe de intrusión es la misma, Network Attack.

Por ello, el valor inferido para la fiabilidad del informe de intrusión es high.

La regla SWRL utilizada, ha sido:

ontAIRS:Context(?context),


ontAIRS:indicates(?context, ?threatCont),



equal(?sysdate, ?intdate),


274

SameAs (?threat, ?threatCont) ->


La regla establece que si el tipo de amenaza que incluye la alerta de intrusión (línea 2 de la

métrica) es igual al tipo de amenaza indicado por la variación de los indicadores del contexto

de la red y de los sistemas (línea 3), la fiabilidad del informe de intrusión es alta (línea 8). La

condición de igualdad se comprueba en la línea 7 de la regla, mediante el builtin SameAs

incluido en la biblioteca de built-ins de la TBox de SWRL.

- A continuación, el Razonador infiere el conjunto de respuestas recomendadas, haciendo uso

de las reglas SWRL correspondientes, y la respuesta óptima, para lo que aplica las métricas

de respuesta especificadas en el Capítulo 6 (Propuesta tres de la tesis doctoral). En este

caso el razonador infiere una respuesta activa de protección, cuya acción consiste en

bloquear el tráfico de entrada del atacante a través del cortafuegos perimetral.

- Para la ejecución de la respuesta llama al módulo central de ejecución de respuestas

(MCER), a quien proporciona el nombre de respuesta inferida, en este caso blockInAttack, y

los parámetros requeridos: la dirección IP del atacante (10.1.100.22), la dirección IP del

objetivo del ataque (192.168.100.132) y el tipo de protocolo (ICMP).

Ejecución

En la fase de ejecución, el MCE recibe la solicitud de respuesta desde el Razonador y recupera toda

la información necesaria para ejecutar la respuesta blockInAttack, que ha sido parseada

adecuadamente en la fase de arranque del módulo de ejecución, que se inicia al arrancar el AIRS

basado en ontologías.

Dicha información indica varias cosas:

- La respuesta contiene una sola acción.

- Se ejecuta sobre el agente de ejecución ubicado en cortafuegos perimetral (10.0.20.1).

- El plugin que lo ejecuta es el ipt-block.

- La acción se ejecuta sobre el atacante.

- La acción tiene un efecto de 24 horas.

- La acción opera sobre el tráfico de entrada.

- Esta acción se ejecuta independiente del identificador de alerta.

A continuación, el MCE a través del módulo de comunicación se conecta con el agente de ejecución

(10.0.20.1) y envía un paquete de solicitud de respuesta, como se observa a continuación:


275

El siguiente paso consiste en que el agente de ejecución recibe la petición procedente desde el

MCER y verifica que fue originado en el MCE autorizado. En caso de una autenticación exitosa,

descifra el paquete y determina que plugin será utilizado para interactuar con el componente de

seguridad.

Una vez que se identifica el plugin (está contenido en el paquete de solicitud) se llama a la función

IPTBResponseAction, que interactúa con el componente de seguridad, en este caso ejecuta

comandos de IPTables para el bloqueo del tráfico de entrada del atacante (10.2.100.22) en la interfaz

att-e0.

Como resultado de la respuesta el cortafuegos perimetral bloquea todo el tráfico procedente del

atacante (10.1.200.22), para lo que agrega una regla de bloqueo a INPUT y FORWARD de la tabla

FILTER del cortafuegos IPTables.

Si el atacante intenta ejecutar de nuevo el ataque obtendrá lo siguiente:

Como se observa, el atacante no puede llevar a cabo el ataque, por lo que la respuesta ha sido

desplegada con éxito, como corroborará el sistema de evaluación del éxito.

Evaluación

Una vez finalizada la ejecución de la reacción de respuesta, el módulo de ejecución envía el código 4

correspondiente a éxito al Razonador, que indica que la respuesta ha finalizado su ejecución.

En ese momento el módulo de evaluación es invocado, cuyo objetivo es evaluar el éxito de la

respuesta. Considerando que esta es la primera vez que se ejecuta esta acción de respuesta, el

módulo proporciona la siguiente salida:


276

Figura 8.8 Salida del sistema de Evaluación del éxito de Respuestas en el escenario de validación 1.

8.4.4 Rendimiento del AIRS basado en ontologías

El principal objetivo de este experimento es la evaluación del rendimiento del sistema de respuesta,

en función del número de intrusiones concurrentes, para lo que se lanzado tres tipos de intrusión

distintas:

- Escaneo de puertos mediante la herramienta Nmap.

- UDP Flood attack (DoS) mediante la herramienta UDPFlood (una herramienta que envía

paquetes UDP de forma indiscriminada a una dirección IP y puerto destino especificados).

- Web application attack (SQL injection y escalado de privilegios).

Cada intrusión ha sido lanzada un número de veces suficiente como para que los datos sean

suficientemente representativos.

Este experimento tiene tres objetivos:

- Medir el tiempo que tarda en ejecutarse el proceso de inferencia de respuesta, desde el

instante en que el IDS detecta una intrusión y envía la alerta de la intrusión al AIRS, hasta el

momento en que el AIRS basado en ontologías ejecuta la respuesta óptima. Este tiempo se

ha calculado mediante la variación del número de alertas concurrentes referidas al mismo tipo

de intrusión o relativas a amenazas diferentes. Además, se han tomado los tiempos cuando el

número de hebras del Razonador es 1 (mínimo valor permitido) o 4 (máximo valor permitido).


277

- Comprobar cómo varios informes simultáneos sobre el mismo incidente se identifican por el

AIRS como el mismo ataque. En esa situación, el AIRS ejecuta el proceso de inferencia

respuesta una única vez.

- Medir el número de veces que el AIRS ejecuta el proceso de inferencia de respuesta, cuando

recibe varios informes sobre diferentes intrusiones, al mismo tiempo.

La Figura 8.9 muestra el tiempo parcial y total expresado en milisegundos cuando el número de

alertas concurrentes varía de dos maneras diferentes: alertas concurrentes del mismo ataque y

alertas simultáneas sobre diferentes intrusiones. Aclarar que en este caso sólo se tiene una hebra del

Razonador.

Figura 8.9 Rendimiento del AIRS. Tiempo de despliegue de una acción de respuesta en función del número de alertas concurrentes. Número de hebras del Razonador =1.

Los gráficos muestran el tiempo transcurrido en dos fases, la fase de carga de la ontología y la fase

de inferencia y razonamiento. El tiempo total es la suma de ambos. El tiempo en la fase 1 (tiempo de

carga de la ontología) no depende del número de informes recibidos por el AIRS en ambas

situaciones (misma intrusión o diferentes intrusiones), como se muestra en la Figura 8.9. El tiempo

para la fase 2 (el tiempo de la ejecución del proceso de inferencia) depende del número de alertas

recibidas pero sólo si las intrusiones detectadas son diferentes. Es decir, si la intrusión es la misma, el

IDS envía al AIRS tantos informes de intrusión como número de ataques simultáneos haya detectado

y, a continuación, si todos los informes recibidos se refieren a la misma intrusión, el AIRS ejecuta el

proceso de inferencia sólo una vez, descartando el resto de informes. En esta situación, el AIRS

muestra el siguiente mensaje para la primera alerta recibida

“Alert received

<38>snort: [1:1000852:1] UDP FLOOD. [Classification: Detection of a

Denial of Service Attack] [Priority: 2]: {UDP} 172.16.222.130:62736

-> 10.0.0.100:11 “

y este mensaje para los siguientes informes de intrusión relativos al mismo ataque:

“Alert received. <38>last message repeated x times”

Donde x es el número de alertas concurrentes repetidas.

Por otra parte, si el IDS detecta diferentes ataques, envía tantos informes de intrusión al AIRS como

número de ataques simultáneos detectados, pero en esa situación, el AIRS ejecuta el proceso de

inferencia tantas veces como número de informes ha recibido.

http://172.16.222.130:62736/

http://10.0.0.100:11/


278

Esa es la razón por la que el tiempo medido es una función lineal que depende del número de

intrusiones recibidas, en la segunda figura. Esto se debe a que sólo se ejecuta una hebra del

Razonador, por lo que no pueden ejecutarse varios procesos de inferencia en paralelo. Por esta

razón, el tiempo es muy alto cuando se detectan más de tres intrusiones diferentes al mismo tiempo.

Si configuramos el Razonador para soportar ejecución concurrente, con un número de hebras de 4

simultáneas, el tiempo de razonamiento e inferencia se ve reducido drásticamente, como se observa

en la siguiente figura.

Figura 8.10 Rendimiento del AIRS. Tiempo de despliegue de una acción de respuesta en función del número de alertas concurrentes. Número de hebras del Razonador =4.

Por otra parte, el número de intrusiones detectadas por el IDS y el número de veces que el AIRS

ejecuta el proceso de inferencia, en ambos escenarios, se muestran en la Tabla 8.5. Se puede

observar que el número de veces que el AIRS ejecuta el proceso de inferencia de respuesta depende

directamente del número de alertas concurrentes. Si las alertas de intrusión recibidas se refieren a la

misma intrusión, el sistema ejecuta el proceso sólo una vez.

Tabla 8.5 Variación del número de alertas de intrusión recibidas y analizadas en función del número de alertas concurrentes.

Num. de alertas

concurrentes

Alertas de intrusión IDS

(misma intrusión)

Ejecuciones del proceso de

inferencia (mima intrusión)

Alertas de intrusión IDS

(diferentes intrusiones)

Ejecuciones del proceso de inferencia (diferentes

intrusiones)

1 1 1 1 1 2 2 1 2 2 3 3 1 3 3 4 4 1 4 4 5 5 1 5 5 6 6 1 6 6 7 7 1 7 7 8 8 1 8 8 9 9 1 9 9

10 10 1 10 10

0

5000

10000

15000

20000

25000

1 2 3 4 5 6 7 8 9 10

Tim

e (m

sec)

Num of concurrent alerts

Response inferenceTime - same intrusion

Response inferenceAverage Time -different intrusion


279

8.4.5 Tasa de éxito del AIRS basado en ontologías

El objetivo de este experimento o prueba realizada es obtener la tasa de éxito del sistema de

respuesta en función del activo comprometido. Para ello, se han llevado a cabo los mismos tipos de

intrusión que en el experimento anterior:

- Escaneo de puertos mediante la herramienta Nmap.

- UDP Flood attack (DoS) mediante la herramienta UDPFlood (una herramienta que envía

paquetes UDP de forma indiscriminada a una dirección IP y puerto destino especificados).

- Web application attack (SQL injection y escalado de privilegios).

Cada intrusión ha sido lanzada un número de veces suficiente como para que los datos sean

suficientemente representativos.

Otro parámetro relevante de ser medido es la tasa de éxito del sistema, es decir, el éxito de la

ejecución del proceso de inferencia de la respuesta. El éxito de este proceso depende de la métrica

utilizada por el AIRS delas tres propuestas: métrica de reducción de daño, métrica de mínimo coste, y

métrica de máxima gravedad o máxima eficiencia. El sistema utiliza una métrica u otra en función del

tipo de activo comprometido por la intrusión, como se ha explicado previamente.

Por tanto, el objetivo de este experimento consiste en medir la tasa de éxito del sistema en función

del activo objetivo de la intrusión. Para llevar a cabo este experimento, se han utilizado los mismos

tres tipos de ataque indicados para el Experimento 1, que se utilizan para comprometer tres tipos de

activos con diferente nivel de importancia para la organización: el servidor de base de datos de gran

relevancia para la organización, el servidor Metasploitable de la DMZ, y, finalmente, un host de

usuario cuya importancia para el funcionamiento del sistema no es muy elevada.

La Figura 8.11 muestra la tasa de éxito expresada en tanto por ciento cuando el AIRS ejecuta el

proceso de inferencia para cada uno de los escenarios anteriores por primera vez. Se observa que la

tasa de éxito es siempre superior al 55% y el valor más alto se alcanza cuando el recurso

comprometido es el servidor de base de datos. La tasa de éxito depende de la métrica seleccionada,

y la métrica utilizada en esta situación es la métrica de máxima severidad y máxima eficiencia, es

decir, el AIRS infiere la respuesta con mayor severidad y eficacia, siendo esta la respuesta más eficaz

en los tres escenarios de intrusión, a excepción del ataque de escaneo de puertos. En ese caso, el

sistema descarta la respuesta más severa debido a que el impacto de la intrusión es menos

perjudicial que la propia respuesta, resultado de aplicar la métrica de reducción de daño.

Figura 8.11 Tasa de éxito del AIRS basado en ontologías en función del tipo de intrusión y de la importancia del activo comprometido.


280

Por otra parte, la Figura 8.12 muestra la tasa de éxito tras ejecutar el proceso de inferencia de la

respuesta óptima varias veces. La métrica utilizada ante recursos cuya relevancia es alta o media,

dependerá de la severidad total de la respuesta, cuyo valor cambia en función de la eficacia de la

respuesta (RTE) obtenida por el sistema de evaluación del éxito de una acción de respuesta, como se

puede observar en la ecuación de la métrica de máxima severidad o máxima eficacia. El valor de RTE

se actualiza después de cada ejecución del proceso de inferencia. Por esta razón, la tasa de éxito

global observada en los gráficos 1 y 2 varía con el número de ejecuciones. A partir de un número

suficiente de ejecuciones, el valor de la RTE se vuelve estable, y desde entonces, el sistema infiere la

misma respuesta siempre que el Catálogo de Acciones de Respuesta no se modifique. Por otra parte,

la métrica utilizada para los componentes de baja relevancia no depende de la RTE, lo que explica

que la tasa de éxito en la tercera gráfica tenga siempre el mismo valor.

Figura 8.12 Tasa de éxito del AIRS basado en ontologías en función del número de ejecuciones del proceso de inferencia.

8.5 Análisis de resultados

En este capítulo se pretenden presentar los detalles más relevantes de la implementación y desarrollo

de un prototipo de arquitectura del AIRS basado en ontologías presentado como propuesta de la

presente tesis doctoral, así como los principales resultados obtenidos de las pruebas y evaluaciones

ejecutadas con el objetivo de comprobar el correcto funcionamiento del prototipo desarrollado en un

escenario real de validación. De esta forma es posible comprobar la viabilidad de la utilización de los

lenguajes de definición de ontologías, lenguajes de especificación de comportamiento y razonadores

semánticos, como núcleo de la arquitectura de un AIRS.

En virtud de ello, y como se puede corroborar en la batería de pruebas realizada, la presente tesis

doctoral aborda la solución al problema planteado en la especificación de cada una de las cuatro

propuestas realizadas.

Capítulo 9: Conclusiones y Trabajos Futuros

281

CONCLUSIONES Y TRABAJOS FUTUROS Capítulo 9

En este capítulo se va a proceder al resumen de los resultados obtenidos en la investigación y

presentados en capítulos anteriores, mediante el análisis de los objetivos especificados en el Capítulo

1. Posteriormente se van a indicar contribuciones que ha realizado el doctorando en forma de

publicaciones que se encuentran relacionadas con el desarrollo de la presente Tesis. Por último se

definen las líneas de investigación futuras que se derivan del presente trabajo.

9.1 Análisis de los objetivos

1. Propuesta de arquitectura de un sistema de respuesta a intrusiones basado

en ontologías

El principal objetivo de esta tesis doctoral es la propuesta de una arquitectura de un sistema de

respuesta automática frente a intrusiones (AIRS) cuyo objetivo es inferir la reacción más adecuada

ante cualquier signo de comportamiento anómalo detectado en la red o los sistemas de una

organización. Mediante un análisis de las taxonomías de AIRSs existentes, se concluye que un AIRS

debe cumplir seis requisitos, proactividad, adaptabilidad, rapidez de respuesta, sensibilidad al coste

de la respuesta, utilizar un mecanismos de evaluación de costes dinámicos y coherencia semántica,

siendo este último de gran relevancia en entornos heterogéneos.

Por coherencia semántica se entiende la capacidad del sistema de entender y procesar las alertas de

intrusión no sólo desde un punto de vista sintáctico sino también semántico, con independencia de la

fuente de intrusión. Es decir, es la capacidad de que el sistema procese alertas de intrusión

procedentes de distintos IDSs, y que por tanto pueden utilizar formatos distintos, y sea capaz de

determinar si las alertas se refieren a la misma intrusión o dos distintas.

Tras un análisis de los aspectos más importantes del estado del arte en lo que se refieren a los AIRSs

existentes, se pone de manifiesto que la mayoría de los sistemas analizados no sólo no solucionan el

problema de la coherencia semántica sino que no lo tienen en cuenta. En entornos de red

heterogéneos, como es el la respuesta frente a una intrusión, cada uno de los IDSs utiliza un formato

distinto para representar las alertas, no sólo en la forma de presentar la información contenida en

cada alerta, sino en los parámetros que ésta incluye. Un AIRS presente en la red así como cualquier

otro componente de la misma, podría no ser capaza de distinguir que dos alertas aparentemente

diferentes, son en realidad la misma alerta. Ante esa situación el sistema las trataría por separado lo

que reduciría el rendimiento del sistema ya que aumenta su tiempo de ejecución.

Como solución a este problema de la coherencia semántica en la representación de alertas, esta tesis

propone el uso de ontologías, lenguajes de especificación de comportamiento y razonadores

semánticos como núcleo o base de la arquitectura del sistema de respuesta automática propuesto.

Además, como se desprende del análisis realizado de lenguajes de ontologías y lenguajes de reglas

existentes, estas tecnologías proporcionan más ventajas, como por ejemplo, su interoperabilidad o la


282

capacidad de inferir nuevo conocimiento en función de una base de hechos. Estas características de

las ontologías permiten al AIRS cumplir el resto de requisitos.

Así, en esta tesis se han empleado conceptos y principios de las ontologías para la definición de

información relativa con el proceso de respuesta frente a una intrusión. Esta aproximación ha

resultado ser muy útil en cada una de las contribuciones planteadas:

- Se han analizado y comparado exhaustivamente los lenguajes de definición de ontologías

existentes (OWL, RDF, DAML+OIL, OWL2,etc.). De este trabajo se extrae que el lenguaje

OWL2 es el lenguaje elegido.

- Se han analizado lenguajes de definición de comportamiento o lenguajes de reglas (KAoS,

REI, SWRL etc.), análisis tras el que se extrae el lenguaje SWRL como lenguaje elegido para

especificar el comportamiento del AIRS.

- Se han analizado y comparado los distintos razonadores semánticos. Del análisis realizado

se extrae Pellet como motor de inferencia elegido.

2. Propuesta de ontología de respuesta a intrusiones

El hecho de utilizar ontologías y lenguajes de reglas como núcleo de la arquitectura propuesta, da

lugar al siguiente objetivo de la tesis: el desarrollo y definición de una ontología de respuesta a

intrusiones utilizada por el AIRS. Esta ontología define formalmente todos los conceptos identificados

en el dominio que pretende modelar, como por ejemplo: respuesta, intrusión, activo, etc., así como

sus principales propiedades y las relaciones existentes entre los distintos componentes. La ontología

de respuesta a intrusiones ha sido definida utilizando el lenguaje OWL2. Para la consecución de este

objetivo:

- Se han analizado las diferentes ontologías de seguridad existentes con el fin de su posible

reutilización parcial o total en la ontología del AIRS. Del análisis se concluye que ninguna de

las ontologías existentes modela por completo el dominio de respuesta frente a una intrusión,

lo que deja clara la necesidad de la especificación de una nueva ontología. Como se indica,

esta ontología de respuesta a intrusiones utiliza parte de la ontología propuesta por Herzog et

al. [Herzog07] y de la ontología IDMEF propuesta por López de Vergara et al.

[LopezDeVergara09].

- Se han estudiado las metodologías para el desarrollo y construcción de una ontología. La

metodología Methontology ha sido la elegida para construir la ontología de respuesta a

intrusiones.

- Se ha especificado una ontología compuesta por 12 clases principales, así como propiedades

que caracterizan a los ejemplares de dichas clases y las relaciones existentes entre ellas.

3. Propuesta de métricas de seguridad y su especificación mediante SWRL

Otro de los objetivos de esta tesis doctoral es la propuesta de métricas de seguridad, en especial las

de respuestas, y su especificación mediante lenguajes de reglas. En el proceso de inferencia de una

respuesta óptima frente a una intrusión, se tienen en cuenta gran cantidad de parámetros: impacto de

intrusión, coste de respuesta, eficacia de respuesta, IP de la máquina víctima, información sobre el

contexto, etc. Para el correcto funcionamiento del sistema es necesario definir un conjunto de

métricas que permita medir con precisión cada uno de los parámetros críticos. Tras el estudio del

estado del arte de métricas de seguridad realizado, se corrobora la existencia de métricas útiles para

medir algunos de los parámetros requeridos, pero también se pone de manifiesto la no existencia de

métricas que midan de forma eficaz la confianza en un informe de intrusión, por ejemplo. Las métricas

definidas serán aplicadas por el administrador de forma manual o por el AIRS de forma automática.

Además, algunas de las métricas tienen como objetivo especificar comportamiento del sistema, por lo


283

que es necesario especificarlas por medio de reglas SWRL. Este es el caso de las métricas

encargadas de inferir la respuesta óptima y de obtener el nivel de fiabilidad asociado a una alerta de

intrusión. Como consecución de este objetivo se ha obtenido:

- Un conjunto de métricas de seguridad que permiten dar valor a parámetros relevantes en el

proceso de inferencia. En el capítulo correspondiente a esta propuesta se incluye una tabla

resumen donde se indica el parámetro que mide cada métrica, si es contribución original de

esta tesis o ya había sido propuesta por otros trabajos de investigación, y quién es el

encargado de ejecutar la métrica (el administrador o el AIRS).

4. Propuesta de una metodología para la evaluación del éxito de una acción de

respuesta.

El último objetivo de la presente tesis doctoral es la propuesta de una metodología que permita

evaluar el éxito de una acción de respuesta tras haber finalizado su ejecución. Entre los parámetros

susceptibles de medida analizados en la propuesta anterior, el éxito o eficacia asociado a una acción

de respuesta es quizás uno de los más importantes. El uso de la información de la tasa de éxito de

una acción de respuesta en anteriores ejecuciones permite dotar al AIRS del requisito de

adaptabilidad.

Tras el análisis realizado de los mecanismos de evaluación utilizados por los diferentes AIRSs, se

obtiene que es un parámetro muy difícil de medir de forma automática, y que la mayoría de los

sistemas de respuestas no especifica ningún mecanismo para obtener su valor, a pesar de que sí

hacen uso de la tasa de éxito en las métricas utilizadas por el sistemas.

La metodología propuesta se basa en comparar la información de la anomalía de la red y el contexto

antes y después del despliegue de la respuesta, mediante técnicas de la teoría de la información

como es la entropía cruzada de Renyi.

Como resultado de la consecución de los cuatro objetivos especificados a través de las propuestas,

se obtiene una arquitectura de un sistema de respuesta a intrusiones automático, que además

cumple la mayoría de los requisitos deseables en un AIRS:

- Coherencia semántica: gracias al uso de ontologías y lenguajes formales de reglas, el AIRS

basado en ontologías propuesto satisface esta propiedad.

- Adaptabilidad: la metodología de evaluación del éxito de una acción de respuesta permite

obtener la eficacia de la respuesta tras finalizar una acción de respuesta. Este valor es

utilizado por el AIRS en posteriores inferencias, mediante lo cual se cumple esta propiedad.

- Proactividad: la arquitectura propuesta no cumple este requisito. No obstante, se plantea

como línea de trabajo futuro a esta tesis doctoral.

- Sensible al coste de la respuesta: el AIRS propuesto tiene en cuenta el coste e impacto de las

respuestas en el proceso de inferencia de la respuesta óptima. La propia especificación de

las métricas permite alcanzar esta propiedad.

9.2 Difusión de resultados

Existen múltiples aspectos positivos relacionados con las contribuciones de la tesis, algunos de los

cuales han sido presentados en los siguientes artículos:

Verónica Mateos, Víctor A. Villagrá, Francisco Romero. Ontologies-based automated

intrusion response system. In: Proceedings of the 3rd international conference on


284

computational intelligence in security for information systems (CISIS ’10); November 11–12,

2010.

Este artículo presenta la arquitectura del sistema de respuesta automática frente a intrusiones

basado en ontologías, describiendo los componentes incluidos en dicha arquitectura. El

trabajo descrito se corresponde con la primera propuesta de la tesis doctoral.

Verónica Mateos, Víctor A. Villagrá, Francisco Romero, Julio Berrocal. Definition of

response metrics for an ontology-based Automated Intrusion Response Systems.

Computers & Electrical Engineering, Vol. 38 (5), pp. 1102-1114. 2012.

Este artículo incluye las métricas de respuesta propuestas como contribución original de esta

tesis doctoral así como su especificación mediante reglas SWRL. El trabajo presentado se

corresponde con la tercera propuesta de la tesis doctoral.

Verónica Mateos, Víctor A. Villagrá, Julio Berrocal. Application of Ontologies and Formal

Behavior Definition for Automated Intrusion Response Systems. Journal of Research and

Practice in Information Technology (JRPIT). Aceptado pendiente de publicación.

Artículo que presenta la ontología de respuesta a intrusiones propuesta en la tesis doctoral.

En el artículo se describen las clases que componen la ontología, y las principales relaciones

entre ellas.

Asímismo, las ideas aquí presentadas han sido de gran utilidad para el desarrollo de los proyectos

Segur@ y RECLAMO (Red de sistemas de Engaño virtuales y CoLaborativos basados en sistemas

Autónomos de respuesta a intrusiones y Modelos de cOnfianza). El proyecto CENIT Segur@

(Seguridad y Confianza en la Sociedad de la Información,) fue un proyecto promovido por el Centro

para el Desarrollo Tecnológico Industrial (CDTI), Organismo dependiente del Ministerio de Ciencia e

Innovación. Se inició en Julio de 2007 dentro la tercera convocatoria del Programa CENIT (formando

parte de la iniciativa INGENIO 2010).

Por su parte, el proyecto RECLAMO es un proyecto en curso de I + D financiado por el Ministerio de

Ciencia e Innovación español, cuyo objetivo es la definición y el diseño de un marco avanzado de

referencia para mejorar las propuestas actuales de sistemas de detección y reacción frente a

intrusiones. Concretamente, el proyecto propone un sistema de respuesta autónoma capaz de inferir

la respuesta más apropiada para una intrusión dada, teniendo en cuenta no sólo la intrusión, sino

también otros parámetros relacionados con ella, como el contexto o la confianza y la reputación de la

fuente de la red, entre otros.

9.3 Líneas futuras de investigación

El trabajo desarrollado en esta tesis doctoral deja una ventana abierta a nuevas líneas de

investigación futuras relacionadas con la detección, prevención y reacción frente a intrusiones.

Algunas de ellas están relacionadas con posibles mejores de las contribuciones propuestas en esta

tesis y otras identifican posibles nuevos campos de aplicación. Algunas de estas líneas son:

- Introducción de restricciones de ámbito legal en las Políticas definidas.

- Ampliación de la arquitectura propuesta con el fin de conseguir el requisito de proactividad.

Para ello es necesario implementar un algoritmo de predicción de ataques de tal forma que el

AIRS pueda ejecutar una acción de respuesta frente a una intrusión antes de que esta se

lleve a cabo. Una posible técnica a utilizar es el uso de Markov Model Hidden para predecir

ataques. Una vez que el tipo de ataque ha sido predicho con mayor o menor grado de

confianza, la inferencia de la respuesta óptima se realizaría siguiendo el mismo proceso de


285

inferencia propuesto en esta tesis doctoral. En cuanto a las métricas de seguridad

propuestas, se podrían utilizar algunas de ellas, pero sería necesario la definición de nuevas

métricas de seguridad que tuvieran en cuenta nuevos parámetros.

- Mejora de los módulos incluidos en la arquitectura propuesta.

- Estudio y análisis de sistemas de detección, prevención y respuesta inspirados en la biología

y la naturaleza, para su posible aplicación en la prevención y respuesta a intrusiones en redes

informáticas. Este tipo de técnica se conoce como biomimetics o simplemente mimetics.

- En la arquitectura propuesta, la información de contexto de red y sistemas tiene dos

funciones principales: por un lado permite estimar una confianza en la detección, es decir,

complementar la información incluida en las alertas de intrusión recibidas, relativa al tipo de

ataque o amenaza detectada, llegando incluso a desautorizar; por otro, actúan como entrada

del sistema de evaluación del éxito de una acción de respuesta.

Es posible utilizar esta información de contexto para prevenir ataques, y dotar al AIRS de un

comportamiento proactivo. Observando comportamientos anómalos en la red podemos

empezar a responder o preparar la respuesta a futuros ataques que se produzcan siempre de

manera genérica y preventiva. Esta función no ha sido implementada en la versión actual del

módulo de contexto desarrollado, y constituye una línea de investigación futura.

Apéndice I: Interfaz de administración del AIRS basado en ontologías

287

Interfaz de administración del AIRS Apéndice I

basado en ontologías

Con el fin de mejorar el proceso de gestión de la información contenida en la ontología, de forma que

el administrador de la red pueda añadir, eliminar o modificar los valores de los individuos de una

forma más amigable y de manera remota, se ha implementado una consola de administración que

permita gestionar el AIRS basado en ontologías. Esta consola permitirá, además, parar, arrancar y

reiniciar el Razonador del sistema, en caso de que sea necesario.

I.1 Objetivos de la Interfaz de administración del AIRS basado

en ontologías

El objetivo de este apéndice es definir la consola de administración desarrollada, especificando los

puntos relevantes de su diseño e implementación. Para el desarrollo de la interfaz de administración,

ha sido necesario llevar a cabo dos tareas íntimamente relacionadas entre sí:

- Diseño e implementación de la interfaz web de administración del AIRS, que permita al

administrador:

Agregar, modificar, eliminar y visualizar los activos presentes en la arquitectura de la

organización.

Agregar, modificar, eliminar y visualizar las respuestas incluidas en el Catálogo de

Acciones de Respuesta. El sistema puede inferir cualquiera de estas respuestas

como respuesta óptima ante una intrusión.

Cambiar el estado del sistema de respuesta (del Razonador): on y off. El

administrador puede iniciar, parar o reiniciar el razonador.

Visualizar estadísticas o registros de actividad del sistema. Una vez finalizada la

ejecución de la respuesta, el Evaluador del éxito de Acciones de Respuesta, obtiene

la eficacia o éxito de la misma, información que se almacena en la ontología de forma

automática. De la misma forma, el Razonador incluye el resultado correspondiente a

cada inferencia realizada en el histórico de intrusiones y respuestas, indicando para

ello, la alerta de intrusión asociada, la respuesta inferida y el resultado de la misma.

Mediante la interfaz es posible visualizar el contenido del histórico.

- Implementación de un “parser” en Java que permita:

Generar las instancias de las clases correspondientes de la ontología, a partir de los

campos y la información de la interfaz web. Para ello, se hace uso de Jena. Por

ejemplo, para cada respuesta añadida por el administrador al Catálogo de Acciones

de Respuesta, el parser genera la instancia correspondiente asociando los valores

introducidos por el administrador con las propiedades equivalentes de la ontología.

Añadir y/o eliminar estas instancias de la ontología de respuesta a intrusiones del

sistema.


288

Extraer la información contenida en la ontología de respuesta a intrusiones

relacionada con los componentes del sistema y las respuestas así como los

resultados incluidos en el histórico, y visualizar dicha información mediante la interfaz

web.

I.2 Diseño e implementación de la interfaz de administración

del AIRS basado en ontologías

El objetivo de la interfaz de administración es facilitar la gestión de la ontología al administrador, por

lo que se requiere que la interfaz web sea sencilla, fácil de manejar y práctica. Este requisito es

fundamental en la fase de diseño de la interfaz.

La consola de administración consta de una página divida en tres zonas claramente diferenciadas:

- Cabecera: incluye el nombre del sistema de respuesta a intrusiones y el logo.

- Menú lateral: se divide a su vez en tres bloques:

El primero permite al administrador seleccionar el objeto a modificar: componentes

del sistema o activos, respuestas o las estadísticas o resultados. Una vez elegido el

componente, el administrador selecciona la acción: añadir, borrar, modificar o

visualizar la información de la organización relativa al componente seleccionado.

El segundo bloque permite gestionar los ficheros .owl, aplicando los cambios o

cargando la configuración anterior.

Por último, el tercer bloque está relacionado con la gestión del razonador, ya que

permite parar, reiniciar o arrancar el razonador.

- Cuerpo: parte en la que se muestra la información solicitada por el administrador en el menú

lateral.

En la siguiente figura se observa la página inicial de la interfaz de administración. En ella, se

observan claramente las tres zonas descritas previamente.

Figura 9.1 Interfaz de administración del AIRS basado en ontologías


289

Como se ha indicado previamente, la principal funcionalidad de esta interfaz es gestionar de forma

sencilla parte de la información contenida en la ontología del respuesta a intrusiones. Además, de

esta funcionalidad la interfaz, permite hacer un backup de la ontología, aplicar los cambios realizados

o ignorarlos, y gestionar el estado del razonador.

Cuando el administrador desee añadir algún activo nuevo o especificar una nueva acción de

respuesta, deberá dar valor para al menos aquellas propiedades marcadas como requeridas en la

ontología. Es decir, en el proceso de desarrollo de la ontología, se indican mediante restricciones de

cardinalidad, qué propiedades asociadas con cada clase de la ontología deben tener al menos un

valor. Por ello, al crear una nueva instancia de la clase Response o Asset utilizando la interfaz de

administración se debe tener en cuenta restricción.

Así por ejemplo, si se desea añadir un nuevo componente a la red de la organización, será necesario

indicar al menos, un identificador (componentID), un tipo (componentType) y proporcionar una

valoración del activo para la organización (assetLevelOfImportance). Estos campos están marcados

como obligatorios en la interfaz, como se observan en la siguiente figura.

Figura 9.2 Interfaz de administración del AIRS. Campos obligatorios al añadir un nuevo componente.

De igual forma, se ha diseñado e implementado la interfaz para cumplir el resto de restricciones de

cardinalidad presentes en la ontología.

Además de crear, modificar, eliminar y visualizar ejemplares de las clases Response y Asset de la

ontología, la interfaz permite gestionar los ficheros .owl, aplicando los cambios o cargando la

configuración anterior, y parar, reiniciar o arrancar el razonador. A continuación se describen estas

dos funcionalidades un poco más en detalle.

I.2.1 Tratamiento de datos de fichero OWL

Toda acción realizada por el administrador a través de la interfaz web debe guardarse en la ontología.

Es decir, si el administrador añade, modifica o elimina algún activo o respuesta, debe actualizarse la

ontología del sistema para que estos cambios sean realmente tenidos en cuenta por el razonador en

futuras inferencias. De lo contrario, dicha información no estaría incluida en la base de hechos del

razonador.

A la hora de abordar esta tarea se planteó el hecho de que esta modificación de parámetros debía

hacerse con precisión y precaución puesto que tanto la interfaz web como el razonador utilizan el

mismo fichero de datos. Por ello surgió la idea de trabajar con dos ficheros .owl, uno temporal


290

(temp.owl) y otro el utilizado por el razonador (OntAIRS.owl). Inicialmente estos ficheros son idénticos

y contienen toda la información de la ontología del sistema.

Los cambios realizados por el administrador a través de la interfaz web se guardan en el fichero

temporal (temp.owl). Por lo tanto, supongamos que el administrador añade una nueva respuesta;

cuando pulsa el botón “Add a response”, se crea un individuo de la clase Response con los atributos

correspondientes cuyos valores ha indicado el administrador, y se guarda en el fichero temporal. Para

aplicar los cambios y que estas modificaciones se incluyan en el fichero utilizado por el razonador es

necesario pulsar, “Apply changes” en el menú lateral. En este caso, se crea una copia del fichero

temp.owl y se sustituye el antiguo fichero OntAIRS.owl por esta nueva copia.

Además, al interfaz permite cancelar los cambios, de tal forma, que si el administrador ha modificado

el valor de una propiedad pero en el último momento decide no modificarla puede deshacer el cambio

pulsando el botón “Reset changes”. En este caso, se reemplaza el archivo temporal por el utilizado

por el razonador, que no incluye ninguno de los cambios realizados desde la última vez que se

pulsase “Apply changes”.

I.2.2 Gestión del Razonador

Otra funcionalidad de la interfaz web es permitir al administrador cambiar el estado del razonador.

Éste puede arrancar, parar o reiniciar el razonador (start/stop/restart). Esta funcionalidad es

importante desde el punto de vista de la gestión remota del estado del razonador.

El Razonador es un programa Java, por lo que se puede ejecutar directamente desde una página

JSP. Cuando el administrador pone en marcha el razonador, se crea un proceso que se mantiene

activo en el sistema. Por tanto, cuando el administrador desea parar el razonador, lo único que se

hace es matar el proceso Java correspondiente.

Además, la interfaz permite visualizar el estado en que se encuentra el razonador mostrando una luz

verde cuando está arrancado o roja cuando está parado, como se observa en la siguiente figura.

Figura 9.3 Interfaz de administración del AIRS basado en ontologías. Gestión del Razonador

En la parte izquierda de la figura el razonador está parado, por lo que aparece una luz roja y la

posibilidad de arrancarlo. Por otra parte, en la parte derecha de la captura, se observa que el

razonador está arrancado y funcionando, mostrando además el identificador del proceso y la

posibilidad de pararlo o reiniciarlo.

I.3 Diseño del “parser” de la interfaz de administración del


El segundo objetivo del desarrollo de la interfaz es el diseño e implementación de un “parser” en Java

que permita generar las instancias de clases OWL correspondientes, a partir de los valores

introducidos por el administrador en la interfaz web, y añadir y/o eliminar estas instancias en la

ontología así como extraer la información de la ontología para mostrarla en la interfaz. En este

apartado se describe brevemente la solución propuesta.


291

El parser está compuesto de cuatro clases Java:

- AirsGeneric: contiene funciones generales que pueden ser utilizadas por otras clases más

específicas, como por ejemplo, crear individuo, añadir, eliminar…

- AirsComponents: clase que contiene métodos específicos para la gestión de los componentes

del sistema.

- AirsResults: clase que contiene métodos específicos para la gestión de los resultados, o

estadísticas.

- AirsResponse: clase que contiene métodos específicos para la gestión de las respuestas del

catálogo de acciones.

Las cuatro clases anteriores pertenecen al paquete AirsPck, y todas ellas utilizan Jena para la

interacción con el fichero .owl. La integración de la interfaz web con las clases del paquete AirsPck se

produce mediante clases JSP que llaman a los métodos de las diferentes clases.

En la siguiente figura se muestra un esquema general del “parser” diseñado, así como su integración

con la interfaz web.

Figura 9.4 Interfaz de administración del AIRS basado en ontologías. Diagrama de componentes.

Aunque, a primera vista, puede parecer que las páginas JSP manipulan la información de los ficheros

.owl, en realidad la creación, eliminación y modificación de la ontología se lleva a cabo

exclusivamente en las clases del paquete AirsPck. Estas clases devuelven los valores solicitados por

las páginas JSP, que se encargan de presentarlos a través de la interfaz.

Por ejemplo, supongamos que el administrador desea visualizar las respuestas que hay en el

catálogo de acciones del sistema. La página JSP ShowResp.jsp solicitará dicha información a la clase

AirsResponses. Esta clase, extraerá la información requerida de la ontología y devolverá los

resultados a la página JSP que realizó la petición. Por último, los resultados devueltos se presentan al

administrador.

En la implementación de la interfaz se han utilizado herramientas utilizadas en el diseño web como

Tomcat, y otras específicas de la Web Semántica como Jena, que permite extraer y escribir

información de / en un fichero .owl.

Esta interfaz es de gran ayuda para que el administrador pueda gestionar parte de la información

contenida en la ontología de una forma sencilla y remota.

Apéndice II: Definición de reglas SWRL especificadas en el AIRS basado en ontologías

293

Definición de reglas SWRL Apéndice II

especificadas en el AIRS basado en

ontologías

II.1 Introducción

En este apéndice se presentan las reglas SWRL especificadas para su inclusión en la arquitectura del

sistema de respuesta automática frente a intrusiones basado en ontologías propuesta. Dicha

arquitectura se muestra en la Figura 4.1, donde el conjunto de reglas está representado mediante el

componente denominado Policies. Como se indica varias veces a lo largo de la memoria, estas reglas

rigen el comportamiento del sistema de respuesta.

II.2 Definición de las reglas

En la arquitectura del sistema de respuesta se proponen 4 conjuntos de reglas:

- Reglas que determinan la amenaza indicada por la información de contexto: reglas cuyo

objetivo es determinar la amenaza indicada por la variación de la anomalía producida en los

parámetros del contexto. El resultado de estas reglas, será utilizado por el siguiente conjunto

para obtener la fiabilidad del informe de intrusión y las respuestas recomendadas.

- Reglas que determinan la fiabilidad del informe de intrusión: conjunto de reglas cuyo objetivo

es dar valor a la propiedad intrusionAlertReliability de la clase FormattedIntrusion. Para ello,

comparan la amenaza indicada por la información de contexto y el tipo de ataque indicado en

la alerta de intrusión. Este conjunto de reglas tiene la función de especificar la métrica de

fiabilidad del informe de intrusión especificada en el Capítulo 6, cuya tabla de decisión se

observa en Tabla 6.3.

- Reglas que permiten inferir las respuestas recomendadas, para lo que utilizan información

relativa al contexto, a la amenaza y la propiedad protects de la clase Response.

- Reglas que permiten inferir la respuesta óptima. Conjunto de reglas cuyo objetivo es inferir la

respuesta óptima frente a una intrusión. Parten de los resultados obtenidos en la aplicación

del conjunto de reglas anterior. Este conjunto de reglas tiene la función de especificar la

métrica de inferencia de la respuesta óptima especificada en el Capítulo 6. La especificación

de esta métrica mediante SWRL puede verse en 6.4.3.2.

A continuación se incluyen las reglas pertenecientes a cada uno de los cuatro conjuntos definidos,

teniendo en cuenta que algunas de las reglas que determinan la fiabilidad del informe de intrusión

también permiten inferir las respuestas recomendadas.


294

II.2.1 Reglas que determinan la amenaza indicada por la

información de contexto

1.1 Regla que indica que en caso de que la anomalía en el espacio libre en disco sea superior a 7,

existen indicios de intrusión en el sistema pero no es posible determinar con exactitud el tipo de

amenaza.

ontAIRS:IntrusionResponseSystem(?IRS), ontAIRS:receivedFormattedIntrusion(?IRS, ?intrusion),

ontAIRS:UndefinedThreat(?threatunde), ontAIRS:SystemContext(?syscontext),

ontAIRS:contextInformationDate(?syscontext, ?sysdate), ontAIRS:intrusionDetectionTime(?intrusion,

?intdate), equal(?sysdate, ?intdate), ontAIRS:systemFreeSpace(?syscontext, ?syshard),

greaterThan(?syshard, 7) -> ontAIRS:indicates(?syscontext, ?threatunde)

1.2 Regla que indica que en caso de que la anomalía en el estado del sistema sea superior a 7,

existen indicios de intrusión en el sistema pero no es posible determinar con exactitud el tipo de

amenaza.


ontAIRS:UndefinedThreat(?threatunde), ontAIRS:SystemContext(?syscontext),


?intdate), equal(?sysdate, ?intdate), ontAIRS:systemStatus(?syscontext, ? sysstatus),

greaterThan(?sysstatus, 7) -> ontAIRS:indicates(?syscontext, ?threatunde)

1.3 Regla que indica que si la anomalía existente en el número de usuarios logueados y la anomalía

del número de procesos activos es superior a 5, el contexto indica que hay indicios de intrusión

en el sistema y además el tipo de amenaza es BackDoors.


ontAIRS:BackDoors(?threatbackdoors), ontAIRS:SystemContext(?syscontext),


?intdate), equal(?sysdate, ?intdate), ontAIRS:systemNumberOfUsersLogged (?syscontext, ? sysUsers),

greaterThan(?sysUsers, 5), ontAIRS:systemActiveProcesses (?syscontext, ? sysprocesses),

greaterThan(?sysprocesses, 5), -> ontAIRS:indicates(?syscontext, ? threatbackdoors)

1.4 Regla que indica que si la anomalía existente en la actividad de la red y la anomalía de la latencia

del sistema es superior a 7, el contexto indica que hay indicios de intrusión en el sistema y

además el tipo de amenaza es DoS.


ontAIRS:DoS(?threatdos), ontAIRS:NetworkContext(?netcontext),

ontAIRS:SystemContext(?syscontext), ontAIRS:contextInformationDate(?syscontext, ?sysdate),

ontAIRS:contextInformationDate(?netcontext, ?netdate), ontAIRS:intrusionDetectionTime(?intrusion,

?intdate), equal(?sysdate, ?intdate), equal(?netdate, ?intdate), ontAIRS:networkAnomaly(?netcontext,

? netan), greaterThan(?netan, 7), ontAIRS:systemLatency (?syscontext, ? syslatency),

greaterThan(?syslatency, 7), -> ontAIRS:indicates(?syscontext, ? threatdos)

1.5 Regla que indica que si la anomalía existente en la latencia del sistema y en el uso de la CPU es

superior a 7, el contexto indica que hay indicios de intrusión en el sistema y además el tipo de

amenaza es PasswordAttacks.


ontAIRS:PasswordAttacks(?threatpassword), ontAIRS:SystemContext(?syscontext),



295

?intdate), equal(?sysdate, ?intdate), ontAIRS:systemLatency(?syscontext, ? syslatency),

greaterThan(?syslatency, 7), ontAIRS:systemCPUUsage (?syscontext, ? syscpu),

greaterThan(?syscpu, 7), -> ontAIRS:indicates(?syscontext, ? threatpassword)

1.6 Regla que indica que si la anomalía existente en el número de procesos activos es superior a 7,

el contexto indica que hay indicios de intrusión en el sistema y además el tipo de amenaza es

Trojan, Virus o Worms.


ontAIRS:Trojan(?threattrojan), ontAIRS:Virus(?threatvirus), ontAIRS:Worms(?threatworms),

ontAIRS:SystemContext(?syscontext), ontAIRS:contextInformationDate(?syscontext, ?sysdate),

ontAIRS:intrusionDetectionTime(?intrusion, ?intdate), equal(?sysdate, ?intdate),

ontAIRS:systemActiveProcesses(?syscontext, ? sysprocesses), greaterThan(?sysprocesses, 7), ->

ontAIRS:indicates(?syscontext, ? threattrojan), ontAIRS:indicates(?syscontext, ? threatvirus),

ontAIRS:indicates(?syscontext, ? threatworms)

II.2.2 Reglas que determinan la fiabilidad del informe de intrusión /

Reglas que permiten inferir las respuestas recomendadas

2.1 Regla que indica que si la anomalía del contexto refleja la existencia de amenaza aunque no

especifique el tipo, el sistema infiere como grado de confianza en la alerta de intrusión el valor de

“high” y como respuestas recomendadas todas aquellas respuestas activas que protejan la

dimensión de seguridad amenazada por la intrusión, independientemente del nivel de confianza

en el IDS que genera la alerta.

ontAIRS:Active(?response), ontAIRS:IntrusionResponseSystem(?IRS),

ontAIRS:SystemContext(?syscontext), ontAIRS:UndefinedThreat(?threatunde),

ontAIRS:hasIntrusionType(?intrusion, ?threat), ontAIRS:indicates(?syscontext, ?threatCont),

ontAIRS:protects(?response, ?sgres), ontAIRS:receivedFormattedIntrusion(?IRS, ?intrusion),

ontAIRS:threatens(?threat, ?sgint), ontAIRS:contextInformationDate(?syscontext, ?sysdate),


ontAIRS:neededRecommendedInference(?intrusion, ?nri), ontAIRS:responseStatus(?intrusion,

?status), booleanNot(?nri, false), equal(?status, "Pending"), equal(?sysdate, ?intdate), SameAs

(?sgres, ?sgint), SameAs (?threatunde, ?threatCont), DifferentFrom (?trheatCont, ?threat) ->

ontAIRS:recommendedResponses(?intrusion, ?response),


2.2 Regla que indica que si la anomalía del contexto refleja la existencia de una amenaza del mismo

tipo que la indicada en el informe de intrusión, el sistema infiere como grado de confianza en la

alerta de intrusión el valor de “high” y como respuestas recomendadas todas aquellas respuestas

activas que protejan la dimensión de seguridad amenazada por la intrusión, independientemente

del nivel de confianza en el IDS que genera la alerta.

ontAIRS:Active(?response), ontAIRS:IntrusionResponseSystem(?IRS),

ontAIRS:SystemContext(?syscontext), ontAIRS:hasIntrusionType(?intrusion, ?threat),

ontAIRS:indicates(?syscontext, ?threatCont), ontAIRS:protects(?response, ?sgres),

ontAIRS:receivedFormattedIntrusion(?IRS, ?intrusion), ontAIRS:threatens(?threat, ?sgint),


?intdate), ontAIRS:neededRecommendedInference(?intrusion, ?nri),

ontAIRS:responseStatus(?intrusion, ?status), booleanNot(?nri, false), equal(?status, "Pending"),

equal(?sysdate, ?intdate), SameAs (?sgres, ?sgint), SameAs (?threat, ?threatCont) ->


296

ontAIRS:recommendedResponses(?intrusion, ?response),


2.3 Regla que indica que si la anomalía del contexto refleja la existencia de una amenaza de distinto

tipo que la indicada en el informe de intrusión y el grado de confianza en el IDS que genera la

alerta de intrusión es high, el sistema infiere como grado de confianza en la alerta de intrusión el

valor de “medium” y como respuestas recomendadas todas aquellas respuestas activas que

protejan la dimensión de seguridad amenazada por la intrusión especificada en el informe de

intrusión.

ontAIRS:Active(?response), ontAIRS:SpecificThreat(?threatsp), ontAIRS:SystemContext(?syscontext),

ontAIRS:hasIntrusionType(?intrusion, ?threat), ontAIRS:indicates(?syscontext, ?threatCont),

ontAIRS:isGeneratedBy(?intrusion, ?ids), ontAIRS:protects(?response, ?sgres),


ontAIRS:IDSconfidence(?ids, ?idsconf), ontAIRS:contextInformationDate(?syscontext, ?sysdate),



?status), booleanNot(?nri, false), equal(?idsconf, "high"), equal(?status, "Pending"), equal(?sysdate,

?intdate), SameAs (?sgres, ?sgint), SameAs (?threatCont, ?threatsp), DifferentFrom (?threatCont,

?threat) -> ontAIRS:recommendedResponses(?intrusion, ?response),


2.4 Regla que indica que si no existe anomalía en el contexto o esta no es suficiente como para

asegurar la existencia de una amenaza, y el grado de confianza en el IDS que genera la alerta de

intrusión es low, el sistema infiere como grado de confianza en la alerta de intrusión el valor de

“low” y no infiere respuestas recomendadas.

ontAIRS:NotThreat(?threatcon), ontAIRS:SystemContext(?context), ontAIRS:indicates(?syscontext,

?threatcon), ontAIRS:isGeneratedBy(?intrusion, ?ids), ontAIRS:receivedFormattedIntrusion(?IRS,

?intrusion), ontAIRS:IDSconfidence(?ids, ?idsconf), ontAIRS:contextInformationDate(?syscontext,

?sysdate), ontAIRS:intrusionDetectionTime(?intrusion, ?intdate),


?status), booleanNot(?nri, false), equal(?idsconf, "low"), equal(?status, "Pending"), equal(?sysdate,

?intdate) -> ontAIRS:intrusionAlertReliability(?intrusion, "low")



intrusión es high, el sistema infiere como grado de confianza en la alerta de intrusión el valor de

“medium” y como respuestas recomendadas todas aquellas respuestas activas que protejan la

dimensión de seguridad amenazada por la intrusión especificada en el informe de intrusión.

ontAIRS:Active(?response), ontAIRS:NotThreat(?threatcon), ontAIRS:SystemContext(?syscontext),

ontAIRS:hasIntrusionType(?intrusion, ?threat), ontAIRS:indicates(?syscontext, ?threatcon),






?status), booleanNot(?nri, false), equal(?idsconf, "high"), equal(?status, "Pending"), equal(?sysdate,

?intdate), SameAs (?sgres, ?sgint) -> ontAIRS:recommendedResponses(?intrusion, ?response),



297



intrusión es medium, el sistema infiere como grado de confianza en la alerta de intrusión el valor de

“low” y como respuestas recomendadas todas aquellas respuestas activas que protejan la

dimensión de seguridad amenazada por la intrusión especificada en el informe de intrusión.

ontAIRS:Active(?response), ontAIRS:NotThreat(?threatcon), ontAIRS:SystemContext(?context),

ontAIRS:hasIntrusionType(?intrusion, ?threat), ontAIRS:indicates(?syscontext, ?threatcon),






?status), booleanNot(?nri, false), equal(?idsconf, "medium"), equal(?status, "Pending"),

equal(?sysdate, ?intdate), SameAs (?sgres, ?sgint) -> ontAIRS:recommendedResponses(?intrusion,

?response), ontAIRS:intrusionAlertReliability(?intrusion, "low")

2.7 Regla que indica que si la anomalía del contexto refleja la existencia de una amenaza de un

determinado tipo específico pero distinto al del indicado en el informe de intrusión y el grado de

confianza en el IDS que genera la alerta de intrusión es medium, el sistema infiere como grado de

confianza en la alerta de intrusión el valor de “medium” y como respuestas recomendadas todas

aquellas respuestas activas que protejan la dimensión de seguridad amenazada por la intrusión

especificada en el informe de intrusión y por la intrusión indicada por la anomalía del contexto.

ontAIRS:Active(?response1), ontAIRS:Active(?response2), ontAIRS:SpecificThreat(?threatsp),

ontAIRS:SystemContext(?syscontext), ontAIRS:hasIntrusionType(?intrusion, ?threat),

ontAIRS:indicates(?syscontext, ?threatCont), ontAIRS:isGeneratedBy(?intrusion, ?ids),

ontAIRS:protects(?response1, ?sgres1), ontAIRS:protects(?response2, ?sgres2),


ontAIRS:threatens(?threatCont, ?sgintCont), ontAIRS:IDSconfidence(?ids, ?idsconf),


?intdate), ontAIRS:neededRecommendedInference(?intrusion, ?nri),

ontAIRS:responseStatus(?intrusion, ?status), booleanNot(?nri, false), equal(?idsconf, "medium"),

equal(?status, "Pending"), equal(?sysdate, ?intdate), SameAs (?sgres1, ?sgint), SameAs (?sgres2,

?sgintCont), SameAs (?threatCont, ?threatsp), DifferentFrom (?threatCont, ?threat) ->

ontAIRS:recommendedResponses(?intrusion, ?response1),

ontAIRS:recommendedResponses(?intrusion, ?response2),


2.8 Regla que indica que el sistema infiere todas las respuestas pasivas como recomendadas.

ontAIRS:IntrusionResponseSystem(?IRS), ontAIRS:Passive(?response),

ontAIRS:receivedFormattedIntrusion(?IRS, ?intrus1) -> ontAIRS:recommendedResponses(?intrus1,

?response)

2.9 Regla que indica que independientemente del tipo de amenaza indicada en el informe de intrusión,

si la anomalía en el espacio libre en disco es superior a 7, el sistema infiere como respuestas

recomendadas todas aquellas respuestas activas de Recuperación.


ontAIRS:SystemContext(?syscontext), ontAIRS:Recovery(?response),


?intdate), equal(?sysdate, ?intdate), ontAIRS:systemFreeSpace(?syscontext, ?syshard),

greaterThan(?syshard, 7)


298

→ recommendedResponses(?intrusion, ?response)

II.2.3 Reglas que permiten inferir la respuesta óptima

3.1 Regla que permite inferir las respuestas activas óptimas potenciales que pueden ser inferidas

como respuestas óptimas. Esta regla aplica la métrica de reducción de daño especificada en

6.4.2.1.

ontAIRS:Active(?respactive), ontAIRS:FormattedIntrusion(?intrusion),

ontAIRS:receivedFormattedIntrusion(?irs, ?intrusion), ontAIRS:recommendedResponses(?intrusion,

?response), ontAIRS:maximumResponseComplexity(?irs, ?irscomplex),

ontAIRS:realIntrusionImpact(?intrusion, ?intimpact), ontAIRS:responseComplexity(?response,

?rescomplex), ontAIRS:responseImpact(?respon1, ?resimpact), lessThanOrEqual(?rescomplex,

?irscomplex), lessThanOrEqual(?resimpact, ?intimpact), SameAs (?response, ?respactive) ->

ontAIRS:potentialOptimumResponses(?intrusion, ?response)

3.2 Regla que infiere la respuesta óptima en caso de que haya una única respuesta recomendada.

ontAIRS:FormattedIntrusion(?intrusion), ontAIRS:potentialOptimumResponses(?intrusion,

?response), ontAIRS:receivedFormattedIntrusion(?irs, ?intrusion),

ontAIRS:numberOfPotentialOptimumResponses(?intrusion, ?numOpResp), equal(?numOpResp, 1) ->

ontAIRS:optimumResponse(?intrusion, ?response)

3.3 Regla que infiere todas aquellas respuestas pasivas recomendadas como respuesta óptima.

ontAIRS:FormattedIntrusion(?intrusion), ontAIRS:Passive(?passive),

ontAIRS:receivedFormattedIntrusion(?irs, ?intrusion), ontAIRS:recommendedResponses(?intrusion,

?response), ontAIRS:numberOfRecommendedResponses(?intrusion, ?numResp),

greaterThan(?numResp, 0), SameAs (?response, ?passive) -> ontAIRS:optimumResponse(?intrusion,

?response)

3.4 Regla que permite inferir la respuesta activa óptima en el caso de que la importancia del activo

comprometido sea low. Esta regla aplica la métrica de mínimo coste especificada en 6.4.2.2.

ontAIRS:FormattedIntrusion(?intrusion), ontAIRS:hasTarget(?intrusion, ?target),

ontAIRS:potentialOptimumResponses(?intrusion, ?respon1),


ontAIRS:receivedFormattedIntrusion(?irs, ?intrusion), ontAIRS:assetLevelOfImportance(?target,

?aloi), ontAIRS:numberOfPotentialOptimumResponses(?intrusion, ?numOpResp),

ontAIRS:responseCost(?respon1, ?respcost1), ontAIRS:responseCost(?respon2, ?respcost2),

equal(?aloi, "low"), greaterThan(?numOpResp, 1), lessThan(?respcost1, ?respcost2) ->

ontAIRS:optimumResponse(?intrusion, ?respon1)


comprometido sea low. Esta regla aplica la métrica de mínimo coste especificada en 6.4.2.2, pero

con la diferencia de que en caso de que el coste de dos respuestas sea el mismo, el sistema

inferirá la de menor complejidad.





?aloi), ontAIRS:numberOfPotentialOptimumResponses(?intrusion, ?numOpResp),

ontAIRS:realIntrusionImpact(?intrusion, ?intimpact), ontAIRS:responseComplexity(?respon1,


299

?respcomplex1), ontAIRS:responseComplexity(?respon2, ?respcomplex2),


equal(?aloi, "low"), equal(?respcost1, ?respcost2), greaterThan(?numOpResp, 1),

lessThan(?respcomplex1, ?respcomplex2) -> ontAIRS:optimumResponse(?intrusion, ?respon1)


comprometido sea medium. En este caso el sistema inferirá como respuesta óptima aquella cuya

complejidad sea menor a la máxima complejidad permitida y que en igualdad de costes posea

una severidad mayor.




ontAIRS:receivedFormattedIntrusion(?irs, ?intrusion), ontAIRS:assetLevelOfImportance(?component,

?aloi), ontAIRS:intrusionSeverity(?intrusion, ?intseverity),

ontAIRS:numberOfPotentialOptimumResponses(?intrusion, ?numOpResp),

ontAIRS:responseComplexity(?respon1, ?respcomplex1), ontAIRS:responseComplexity(?respon2,

?respcomplex2), ontAIRS:responseCost(?respon1, ?respcost1), ontAIRS:responseCost(?respon2,

?respcost2), ontAIRS:responseSeverity(?respon1, ?respseverity1),

ontAIRS:responseSeverity(?respon2, ?respseverity2), equal(?aloi, "medium"), equal(?respcost1,

?respcost2), greaterThan(?numOpResp, 1), greaterThan(?respseverity1, ?intseverity),

greaterThan(?respseverity2, ?intseverity), lessThan(?respcomplex1, ?respcomplex2) ->



comprometido sea medium. En este caso el sistema inferirá como respuesta óptima aquella de

menor coste siempre que su complejidad sea menor a la máxima complejidad permitida, y su

severidad sea superior a la severidad de la intrusión.




ontAIRS:receivedFormattedIntrusion(?irs, ?intrusion), ontAIRS:assetLevelOfImportance(?component,




ontAIRS:responseSeverity(?respon1, ?respseverity1), ontAIRS:responseSeverity(?respon2,

?respseverity2), equal(?aloi, "medium"), greaterThan(?numOpResp, 1), greaterThan(?respseverity1,

?intseverity), greaterThan(?respseverity2, ?intseverity), lessThan(?respcost1, ?respcost2) ->



comprometido sea high. Esta regla aplica la métrica de máxima severidad o máxima eficiencia

especificada en 6.4.2.3.








?respseverity2), equal(?aloi, "high"), greaterThan(?numOpResp, 1), greaterThan(?respseverity1,

?respseverity2), greaterThanOrEqual(?respseverity1, ?intseverity),


300

greaterThanOrEqual(?respseverity2, ?intseverity) -> ontAIRS:optimumResponse(?intrusion,

?respon1)


comprometido sea high. Esta regla aplica la métrica de máxima severidad o máxima eficiencia

especificada en 6.4.2.3, pero con la diferencia de que en caso de que la eficiencia de dos

respuestas sea la misma, el sistema inferirá la de menor coste.









?respseverity2), equal(?aloi, "high"), equal(?respseverity1, ?respseverity2),

greaterThan(?numOpResp, 1), greaterThanOrEqual(?respseverity1, ?intseverity),

greaterThanOrEqual(?respseverity2, ?intseverity), lessThanOrEqual(?respcost1, ?respcost2) ->


II.2.4 Otro conjunto de reglas

4.1 Regla que indica que si una intrusión tiene un resultado similar y este es satisfactorio no es

necesario que el sistema infiera respuestas recomendadas.

ontAIRS:hasSimilarResult(?intrusion, ?result), AIRSResult:Result(?result),

ontAIRS:responseStatus(?intrusion, ?respStatus), equal(?respStatus, "Pending"), equal(?result,

"Satisfactory") -> ontAIRS:neededRecommendedInference(?intrusion, false)

4.2 Regla que permite inferir si existe un resultado anterior para una alerta de intrusión recibida.

ontAIRS:FormattedIntrusion(?intrusion), AIRSResult:Result(?result),

ontAIRS:hasIntrusionType(?intrusion, ?threat), ontAIRS:hasIntrusionType(?intrusionres, ?threatres),

ontAIRS:hasTarget(?intrusion, ?target), ontAIRS:hasTarget(?intrusionres, ?targetres),

ontAIRS:receivedFormattedIntrusion(?irs, ?intrusion), AIRSResult:relatedIntrusion(?result,

?intrusionres), ontAIRS:assetLevelOfImportance(?target, ?targetimp),

ontAIRS:assetLevelOfImportance(?targetres, ?targetresimp),

ontAIRS:numberOfGeneratedResult(?irs, ?numRes), ontAIRS:responseStatus(?intrusion, ?intstatus),

equal(?intstatus, "Pending"), equal(?targetimp, ?targetresimp), SameAs (?threat, ?threatres) ->

ontAIRS:hasSimilarResult(?intrusion, ?result)

Apéndice III: Tipos de ataques informáticos y acciones de respuesta asociadas

301

Tipos de ataques informáticos y Apéndice III

acciones de respuesta asociadas

III.1 Introducción

En este apéndice se definen los principales tipos de ataques e intrusiones actuales, explicando

brevemente en qué consiste cada uno de ellos y qué vulnerabilidad o debilidades explota. Además,

se indican algunas técnicas para detectarlos y un conjunto de acciones de respuesta eficaces para

mitigar cada uno de los tipos de intrusión descritos. Entre paréntesis se indica el identificador

asignado a cada acción de respuesta incluida en la Tabla 4.4 así como el tipo de respuesta.

III.2 Information gathering attack

Los ataques de escaneo, más conocidos como Information Gathering Attack, tienen como objetivo

recopilar información sobre posibles puertas de acceso a la red. Su mecanismo de funcionamiento se

basa en recopilar información que les indique qué puertos están escuchando en la red para acceder

posteriormente a los recursos de la misma a través de ellos.

Dentro de los ataques de este tipo se distinguen diferentes subtipos, en función de la puerta de

acceso que se escanee.

III.2.1 Scanning

“El escaneo como método de descubrimiento de canales de comunicación susceptibles de ser

explotados, lleva en uso mucho tiempo. La idea es recorrer tantos puertos de escucha como sea

posible, y guardar información de aquellos que estén receptivos y constituyan un fácil acceso al

interior del sistema”.

En función de la técnica, los puertos y protocolos explotados, existen diferentes tipos de scanning. El

más conocido sin duda, es el TCP scanning, forma básica del escaneo de puertos TCP.

III.2.1.1 Definición. Mecanismo de funcionamiento

Este ataque aprovecha las vulnerabilidades del protocolo TCP/IP, que utiliza puertos para envío y

recepción de datos siguiendo el modelo cliente/servidor. Para establecer, mantener y terminar una

conexión se utilizan bits de control (SYN, ACK, FIN) que pasan desapercibidos, vulnerabilidad que es

aprovechada por los atacantes, ya que los filtros no pueden determinar con qué fin se lanzan los bits

de control.

Tipos:

- TCP SYN scanning: averigua puertos TCP abiertos. El atacante envía un paquete SYN y

espera la respuesta. Al recibir un SYN/ACK envía inmediatamente un RST para terminar la

conexión y registra ese puerto como abierto.


302

- TCP FIN scanning: averigua puertos TCP cerrados. El atacante envía un paquete de FIN y

espera respuesta. Si recibe un RST el puerto está cerrado; si no recibe respuesta, el puerteo

está abierto.

Por razones de implementación del protocolo en el sistema Windows es el único que responde

siempre a todas las peticiones, estén los puertos abiertos o cerrado, por lo cual no da pistas sobre

que puertos hay abiertos. Los sistemas vulnerables son UNIX LINUX NOVELL.

Las principales ventajas de esta técnica de ataque es que no necesita privilegios especiales y posee

una gran velocidad.

Su principal desventaja es la facilidad de detección.

III.2.1.2 Detección

Este tipo de ataques se detecta por el gran número de conexiones y mensajes de error que se

observan para los servicios a los que se ha conseguido conectar el atacante e inmediatamente se ha

desconectado, ya que el ataque TCP scanning nunca abre una sesión TCP completa.

III.2.1.3 Acciones de respuesta

Como acciones de respuesta se pueden llevar a cabo las siguientes:

- Monitorizar la red en busca de paquetes SYN a puertos restringidos (R38, Respuesta Pasiva

y Respuesta Proactiva).

- Bloqueo de mensajes salientes con origen el puerto X (puerto sobre el que se han detectado

las conexiones y mensajes de error) al puerto Y (el del atacante; el puerto origen de los

paquetes SYN). (R33, Respuesta Activa de Protección y Respuesta Proactiva).

- Desactivar/Desinstalar servicios innecesarios. (R21, Respuesta Proactiva).

- Cambiar el puerto a uno más alto, para evitar los escaneos (R32, Respuesta Activa de

Protección y Respuesta Proactiva).

- Rastrear la conexión del atacante para recopilar información (R7, Respuesta Activa de

Reacción).

Entre paréntesis se indica el tipo de respuesta en función de la clasificación descrita en el Capítulo 4.

III.2.2 Sniffing

Ataque pasivo cuyo objetivo es la interceptar tráfico de red de manera pasiva, sin modificación del

mismo.


Las herramientas utilizadas para llevar a cabo el ataque son los denominados Packet Sniffers,

programas que monitorizan los paquetes que circulan por la red, que pueden instalarse en cualquier

equipo de la red.

El ataque consiste en colocar la tarjeta de red en modo “promiscuo” que desactiva el filtro de

verificación de direcciones lo que provoca que todos los paquetes enviados a la red lleguen a esta

placa (y pueden ser analizados por el atacante).

Actualmente existen Sniffers que mediante el análisis del tráfico capturado pueden capturar todo tipo

de información específica, como passwords de un recurso compartido o de acceso a una cuenta,

números de tarjetas de crédito, direcciones de e-mails entrantes y salientes, relaciones entre

individuos, etc.


Para su detección, es recomendable realizar las siguientes acciones:


303

- Revisar la lista de programas en ejecución para detectar alguna anomalía.

- Mirar la lista de programas que se inician automáticamente al encender el PC o las tareas

programadas para buscar evidencias.

- Detectar tarjetas o adaptadores de red en modo promiscuo mediante el ipconfig. (el modo

promiscuo es el usado por los atacantes para instalar los sniffers).


Como acciones de respuesta se pueden llevar a cabo las siguientes:

- Cerrar el puerto X de la máquina atacada al que el atacante puede conectarse para recuperar

los datos que el sniffer ha capturado, es decir, interrumpir la conexión de red (R31, Respuesta

Activa de Protección y Respuesta Proactiva).

- Matar el proceso resultado de la ejecución del sniffer. (R22, Respuesta Activa de Protección).

- Eliminar el fichero donde se están grabando los datos, imposibilitando así su acceso por parte

del atacante (R11, Respuesta Activa de Restauración).

NOTA: estas tres respuestas se pueden llevar a cabo si el sniffer no se ha ocultado de forma

adecuada y es detectado por los IDSs del sistema, caso en el que las herramientas de monitorización

muestran el proceso que se está ejecutando, el fichero donde se están grabando los datos y la

conexión de red, lo que permitirá ejecutar la respuesta adecuada.

Un ataque muy similar a sniffing pero que además de interceptar el tráfico de red, el atacante se

descarga la información capturada a su propia máquina para analizarla de forma más exhaustiva, es

el conocido como Snooping. Las acciones de detección y respuesta ante este tipo de ataque son

idénticas a las indicadas para sniffing.

III.3 Network attacks (Ataques de red)

Ataque cuyo objetivo es introducirse en un sistema suplantando la identidad de un usuario o del

propio administrador, mediante la manipulación de protocolos de la torre de protocolos TCP/IP,

aprovechando una sesión establecida por el usuario víctima, o utilizando los datos obtenidos

mediante ataques de escaneo (nombre de usuario y password).

Este ataque a su vez se divide en 4 tipos: Hijacking, Spoofing, ataques Wireless y ataques a

aplicaciones Web o Web Application Attacks, que a continuación se describen. Este último tipo tiene

especial relevancia.

III.3.1 Spoofing

Ataque consistente en que el atacante intenta ganar acceso a un sistema haciéndose pasar un

usuario que dispone de los privilegios suficientes para realizar la conexión.


Para la realización de este ataque se utilizan técnicas de suplantación de identidad. Además, para

llevarlo a cabo se necesita poseer gran conocimiento del protocolo en el que se basa el ataque. En

función de la entidad objetivo de la suplantación y el protocolo, existen diferentes tipos:

- IP-Spoofing: suplantación de IP. Consiste en sustituir la dirección IP origen de un paquete

TCP/IP por la IP que se quiere suplantar; las respuestas irán dirigidas a la IP falsificada. El

atacante genera paquetes (TCP/IP) con una dirección IP de destino que no es la de la

máquina víctima, sino una de una maquina determinada que sostiene una "relación de

confianza" con el objetivo.


304

- DNS-Spoofing: suplantación de identidad por nombre de dominio. Consiste en suplantar el

DNS legítimo y falsificar la relación “nombre de dominio – IP”, de tal forma que cualquier

consulta de resolución de nombre se resuelva con una dirección IP falsa de un cierto dominio

DNS o viceversa. Esto se consigue falseando las entradas de la relación Nombre de dominio-

IP de un servidor DNS, mediante alguna vulnerabilidad del servidor en concreto o por su

confianza hacia servidores poco fiables. De esta manera, el atacante proporciona a los

servidores que realizan las consultas direcciones IP o nombres de dominio falsos con fines

maliciosos, redirigiéndoles hacia páginas incorrectas. Las entradas falseadas de un servidor

DNS son susceptibles de infectar (envenenar) el cache DNS de otro servidor diferente (DNS

Poisoning).

- Web- Spoofing: suplantación de una página web legítima. Consiste en redirigir la conexión de

la máquina víctima hacia otras páginas Web que suplantan a la original, con el objetivo de

obtener información acerca de la víctima. La página web falsa actúa a modo de proxy,

solicitando la información requerida por la víctima a cada servidor original. El atacante puede

modificar cualquier información desde y hacia cualquier servidor que la víctima visite. La

forma en la que la víctima accede a la página web suplantada, suele ser mediante ataques de

phising.

Este ataque se realiza mediante una implantación de código el cual nos robará la información,

y es difícilmente detectable.

- ARP- Spoofing: suplantación de identidad mediante falsificación de tablas ARP. El ataque

consiste en construir tramas de solicitud y respuesta ARP modificadas con el fin de falsear la

tabla ARP (relación IP-MAC) haciendo que la máquina víctima envíe los paquetes a un host

atacante en lugar de a su destino elegido. El protocolo ARP trabaja a nivel de enlace de datos

de la torre OSI, por lo que esta técnica sólo puede ser utilizada en redes LAN o en cualquier

caso en la parte de la red que queda antes del primer router.

- TCP-Spoofing: ataque spoofing más común, que consiste en falsificar una conexión TCP. Se

conoce como adivinación del número de secuencia, y se basa en la idea de que si un

atacante puede predecir el número inicial de secuencia de la conexión TCP generado por la

máquina destino, el atacante puede adoptar la identidad de máquina de confianza y

establecer una conexión con la máquina destino.

Los ataques de spoofing afectan a diario el funcionamiento de las redes TCP/IP. Estos son

empleados como parte de un ataque o individualmente. La sencillez de su explotación ha masificado

su uso. Todos los servicios TCP/IP sufren estas afectaciones.


Es un ataque difícil de detectar y de evitar.

En el caso de Web spoofing, quizá la mejor medida sea instalar algún plugin en el navegador que

muestre en todo momento la IP del servidor visitado: si la IP nunca cambia al visitar diferentes

páginas WEB significará que probablemente estemos sufriendo este tipo de ataque.

III.3.1.3 Acciones de respuestas

Como acciones de respuesta ante este tipo de ataques se pueden llevar a cabo:

- Configurar el router para que no admita el envío de paquetes con IP origen no perteneciente

a una de las redes que administra. Filtrado de paquetes por IP origen (R30, Respuesta Activa

de Protección y Respuesta Proactiva).

- Filtrar direcciones en el cortafuegos. (R26 y R28, Respuesta Activa de Protección y

Respuesta Proactiva).


305

- Realización de backup periódicos de la información sensible de los sistemas, que podrá ser

utilizada tras la consecución de un ataque como respuesta de recuperación. (R9 y R13,

Respuesta Activa de Recuperación y Respuesta Proactiva).

III.3.1.4 Estrategia antispoofing

Una buena estrategia antispoofing, es aquella que propone considerar todos los riesgos que

coexisten en la red TCP/IP para protegerla contra un ataque de spoofing, como respuesta de

prevención, teniendo en cuenta que todos los servicios esenciales son vulnerables al spoofing y que

la protección es similar para todos los casos.

Entre las acciones de prevención, protección y recuperación que constituyen la estrategia se

encuentran:

- Filtrado de paquetes en el router externo del cortafuegos. Es imposible eliminar todos los

paquetes que tengas direcciones falsas (spoofing IP), pero sí es posible reducir el número si

se filtran los paquetes y se restringe el flujo de entrada y salida de la red.

- Configuración segura de los servicios DNS, SMTP, etc.

- Protección de las conexiones y los datos, para mantener la confidencialidad, autenticidad e

integridad de la información. Por ejemplo, cifrar las conexiones o utilizar la firma digital.

- Utilizar barreras o filtros de red para registrar todas las conexiones a un servidor determinado.

- Utilizar sistemas proxies para la navegación. Con esto se pretende detectar los posibles

ataques de spoofing WWW.

- Instalar programas sniffers que permiten detectar la ocurrencia de algunos ataques.

- Explotar de forma adecuada los logs de los servicios y sistemas operativos. La configuración

de la generación de logs debe estar encaminada a almacenar la mayor cantidad de

información útil posible. Debe registrarse por ejemplo: dirección IP origen de las conexiones,

el nombre del usuario, horario, duración de la conexión y tamaño e identificación de la

transferencia efectuada.

- Educar a los usuarios, que representa una forma de defensa muy importante contra el

spoofing WWW.

- Segmentación del tráfico, con el objetivo de separar todo el tráfico de administración de los

sistemas del de los usuarios comunes y del de Internet.

- Utilizar herramientas de detección de vulnerabilidades.

- Actualizar los parches de los sistemas operativos.

- Ofrecer sólo los servicios imprescindibles y de manera segura.

III.3.2 Hijacking


Ataque que consiste en ocupar una identidad obteniendo acceso no autorizado a un sistema, cuenta,

etc., con el objetivo de poder falsificar la identidad del usuario atacado. Este tipo de ataque se

produce cuando el atacante consigue interceptar una sesión ya establecida. Es un ataque de

apropiación de identidad, que atenta contra la autenticación de los usuarios. El atacante roba una

conexión después de que el usuario ha superado con éxito el proceso de identificación ante el

sistema. El ordenador desde el que se lanza el ataque ha de estar en alguna de las dos redes

extremo de la conexión, o en la ruta entre ambas.


Es un ataque muy difícil de detectar.


306


Como acciones de respuesta que pueda desplegar el AIRS de forma automática no hay ninguna

efectiva. En cuanto a recomendaciones para evitar este tipo de ataques, se recomienda cifrar la

información. Es el método más seguro para protegerse contra este tipo de ataques.

III.3.3 Web application Attacks (Ataques a aplicaciones web)

Los ataques contra aplicaciones web se han convertido en una de las amenazas más serias para las

infraestructuras de seguridad informática, ya que ponen en peligro la información corporativa y los

datos confidenciales de los clientes. Las aplicaciones web desplegadas en la parte pública de internet

atraen ataques de hackers y gusanos, constituyendo a menudo el punto más vulnerable de las

infraestructuras de red. Por ello, es imprescindible implantar fuertes medidas de seguridad a nivel de

transacciones HTTP, HTTPS y FTP, ya que de lo contrario pueden convertirse en punto de entrada a

las redes corporativas, desde las cuales robar información confidencial o atacar otros servidores

internos.


Hay gran cantidad de ataques a aplicaciones web; a continuación se definen brevemente los más

comunes:

- Ejecución de código de forma remota: el atacante ejecuta código en el servidor vulnerable y

obtiene información almacenada en él. Este ataque explota las vulnerabilidades del sistema

debidas a errores de programación. Es un ataque simple pero eficaz.

- Inyección de código SQL o SQL Inyenction (ataques a bases de datos): ataque que afecta

directamente a las bases de datos de una aplicación. Este ataque consiste en insertar o

inyectar código SQL malicioso dentro de código SQL, para alterar el funcionamiento normal y

hacer que se ejecute el código “invasor” dentro del sistema atacado. Esta técnica de ataque

se usa para explotar sitios web que construyen sentencias SQL a partir de entradas

facilitadas por el usuario. Es muy común entre los atacantes y dependiendo de las medidas

de seguridad que tenga el sistema, el impacto del ataque puede variar desde revelación de

información básica a ejecución de código remoto y compromiso total del sistema, mediante la

alteración parcial o total de las bases de datos del sistema comprometido.

- Cross Site Scripting (XSS): ataque que consiste en explotar las vulnerabilidades del sistema

de validación de HTML incrustado, mediante la inyección en páginas web de código

JavaScript o en otro lenguaje script similar con fines maliciosos. Es posible encontrar una

vulnerabilidad XSS en aplicaciones que tenga entre sus funciones presentar la información en

un navegador web u otro contenedor de páginas web. Sin embargo, no se limita a sitios web

disponibles en Internet, ya que puede haber aplicaciones locales vulnerables a XSS, o incluso

el navegador en sí.

XSS es un vector de ataque que puede ser utilizado para robar información delicada,

secuestrar sesiones de usuario, y comprometer el navegador, subyugando la integridad del

sistema. El uso de AJAX para ataques de XSS no es tan conocido, pero sí peligroso. Se basa

en usar cualquier tipo de vulnerabilidad de XSS para introducir un objeto XMLHttp y usarlo

para enviar contenido POST, GET, sin conocimiento del usuario.

- Envenenamiento de cookies: ataque que consiste en la modificación del valor de las cookies

antes de enviarlas de vuelta al servidor. A día de hoy, la mayoría de los sitios web, sólo

almacenan un identificador de sesión (un número único generado aleatoriamente usado para

identificar la sesión de usuario) en la propia cookie, mientras que el resto de la información es

almacenada en el servidor, eliminando en gran medida el riesgo de sufrir este tipo de

ataques.


307

- Suplantación de contenido: técnica de ataque utilizada para engañar al usuario haciéndole

creer que cierto contenido que aparece en un sitio web es legítimo, cuando en realidad no lo

es.

- Otros ataques definidos en otras partes del documento: ataques de fuerza bruta,

desbordamiento de buffer, denegación de servicio, etc. Hay gran cantidad de ataques contra

aplicaciones Web.


Entre las acciones de respuesta que pueden llevarse a cabo ante este tipo de ataque se encuentran:

- Utilizar cortafuegos de aplicaciones web (WAF) ya que los cortafuegos tradicionales trabajan

en la capa de red y de transporte, y al dejar el puerto 80 abierto no ofrecen ninguna clase de

protección frente a los ataques contra aplicaciones web. Los WAF pueden ser a nivel de host

y a nivel de red (R27 y R29, Respuesta Activa de Protección y Respuesta Proactiva).

- Reconfigurar o restaurar el cortafuegos de aplicación (R35, Respuesta Activa de Protección y

Respuesta Activa de Recuperación).

- Evitar conexiones a bases de datos como un superusuario o como administrador de la base

de datos (R14, Respuesta Activa de Protección y Respuesta Proactiva).

- Cerrar el servicio o aplicación que proporciona el servidor afectado (R19, Respuesta Activa

de Protección).

- Reiniciar el servicio o aplicación que proporciona el servidor afectado (R20, Respuesta Activa

de Protección y Respuesta Activa de Recuperación).

- Restaurar el contenido de una página web en caso de que el servidor web sea el objetivo del

ataque (R13, Respuesta Activa de Recuperación).

III.4 BackDoors

Una puerta trasera (backDoor) en sí es un programa que permite remotamente acceder a un sistema

con libertad de movimientos, que constituye un acceso a un sistema o programa de forma

transparente al usuario.

III.4.1 Definición. Mecanismo de funcionamiento

Es una técnica de ataque que consiste en la utilización de trozos de código en un programa que

permite a quien las conoce saltarse los métodos usuales de autentificación para realizar ciertas

tareas.

Puede establecerse por dos tipos de usuarios: un programador que desarrolla una aplicación y

establece backdoors para acceder al programa más rápidamente en la fase de pruebas o por error;

un atacante que establece una backdoor mediante otras técnicas de ataque como exploits o troyanos

para tener acceso a la máquina víctima con fines maliciosos.

Una puerta trasera no es peligrosa si es utilizada por usuarios no malintencionados, pero es una

entrada al sistema no controlada, lo que la convierte en peligrosa para la seguridad e integridad del

sistema.

La mayoría de las puertas traseras se introducen en nuestro sistema en forma de troyanos cuya

finalidad es siempre malévola. Por otra parte, para poder utilizar las puertas traseras debe existir un

cliente y un servidor, pero los troyanos tienen la capacidad de instalar en el sistema un servidor para

posteriormente acceder a él como cliente y tener control remoto.


308

El hecho de tener una entrada no controlada al sistema, provoca un fallo de seguridad si se utiliza de

forma malintencionada, ya que cualquiera que conozca el agujero o lo encuentre en su código podrá

saltarse los mecanismos de control y autenticación habituales.

Para abrir una puerta trasera en un sistema Unix a veces basta añadir dos líneas de texto.

III.4.2 Detección

Para detectar una backDoor hay que tener en cuenta los efectos que produce la instalación de ésta

en el sistema. Por ejemplo, se puede saber que hay instalada una backdoor si se detecta la siguiente

actividad no autorizada por el usuario o administrador del sistema:

- Monitorización del sistema completo

- Descarga de virus.

- Desinstalación e instalación de programas.

- Borrado de información de usuario.

- Manipulación del registro del sistema.

III.4.3 Acciones de respuesta


- No aceptar peticiones ni llamadas que provengan de usuarios desconocidos o sospechosos

(R24 y R25, Respuesta Activa de Protección y Respuesta Proactiva).

- En el caso de borrado de información de usuario, restaurar el activo afectado a su versión

anterior previa al ataque. (R13, Respuesta Activa de Recuperación).

- Aumentar la sensibilidad del IDS para la detección de troyanos (R6, Respuesta Activa de

Recuperación, Respuesta Pasiva y Respuesta Proactiva).

- Restaurar el sistema a una versión correcta previa a la intrusión (R18, Respuesta Activa de

Recuperación).

- Identificar la backdoor y bloquearla, cerrarla (R31 y R33, Respuesta Activa de Protección y


III.5 Password Attacks (Ataques a contraseñas)

Un porcentaje elevado de intrusiones en un sistema se deben al fallo del sistema de autenticación.

Todo sistema depende en su mayoría del ingreso de un password o contraseña, técnica muy

vulnerable. La utilización de password como método de autenticación conlleva una serie de

problemas: se olvidan, se comparten con personas de confianza que luego podrían resultar no tan

confiables, se interceptan o escuchan por usuarios ajenos, etc. Existen otros mecanismos de

autenticación y autorización más seguros y robustos que la autenticación mediante contraseñas,

como por ejemplo, los mecanismos de autenticación biométrica (autenticación por huellas digitales,

iris, forma de la cara, etc.). Estos sistemas presentan una serie de inconvenientes, como es la

necesidad de disponer de periféricos adecuados en los sistemas informáticos remotos que permitan

capturar la información biométrica necesaria.

Además de los ataques de ingeniería social (ataques mediante engaño del usuario) existen dos

técnicas para ejecutar este tipo de ataque.


309

III.5.1 Guessing. Brute Force

Ataque que consiste en generar e ir probando con todas las combinaciones de caracteres (letras,

números, etc.) posibles hasta adivinar la contraseña (password). Es un proceso automatizado de

prueba y error.


Este tipo de técnica consiste en la obtención por "fuerza bruta" de aquellas claves que permiten

acceder a los sistemas, aplicaciones, cuentas, etc. objetivos del ataque. Esta técnica es altamente

eficaz ya que la mayoría de las contraseñas de acceso se pueden obtener fácilmente debido a la

mala concienciación de los usuarios, que suelen elegir contraseñas fáciles, cortas y no las cambian

con regularidad.

Un ataque de fuerza bruta "pura" teóricamente no puede ser resistido por ningún sistema, siempre y

cuando se disponga del tiempo suficiente y recursos suficientes. Será más complicado adivinar claves

largas, pero si no existe limitación de tiempo, el atacante conseguirá su objetivo. Estas limitaciones

físicas son dinámicas y van disminuyendo a medida que los ordenadores van alcanzando más

capacidad de procesamiento.

Como medida de protección, muchos sistemas niegan el acceso después de un determinado número

de fallos de autenticación, lo que dificulta la labor de los atacantes que usan esta técnica.

Por otra parte, esta técnica tiene la ventaja de que la mayoría de los ataques de fuerza bruta se

hacen offline, es decir, se obtiene el archivo que contiene la lista cifrada de passwords y se trabaja

desde la propia máquina del atacante, sin necesidad de mantener conexión con la máquina víctima.


Como técnicas de detección de ataques de adivinación por fuera bruta se tienen:

- Instalar en los sistemas de la organización alguna herramienta de detección de ataques de

fuerza bruta, como por ejemplo Denyhosts, blocksshd, fail2ban, Brute Force Detection, etc.,

que informan en cada momento de los intentos no autorizados y todo tipo de actividad de

autenticación sospechosa que se ejecute contra los servidores, en especial contra el servidor

SSH.

- Mirar los logs de autenticación del sistema.

- Ataque fácil de detectar por la mayoría de los cortafuegos (un gran número de intentos de

conexión desde una sola dirección IP). No obstante, desde la utilización de redes botnets

para la masificación de ataques, es más difícil su detección.



- Añadir una entrada que deniegue el acceso al usuario atacante detectado, (R14, Respuesta


- Añadir reglas a la configuración de las tablas IP de la máquina atacada que impidan cualquier

tipo de tráfico entre el atacante y la máquina atacada. Bloquear la IP o servicio implicado.

(R31, Respuesta Activa de Protección y Respuesta Proactiva).

- Hacer un whois de la IP y rastrear la conexión del atacante para recopilar información (R7,

Respuesta Activa de Reacción).

- No permitir acceso a root en sistemas Linux (R14, Respuesta Activa de Protección y


- Restaurar los activos afectados (modificados, eliminados, etc.) con motivo de la intrusión

(R13 y R11, Respuesta Activa de Recuperación).


310

III.5.2 Guessing. Dictionary attack

Ataque similar al anterior, que consiste en probar con todas (o la mayoría) de las palabras conocidas

en un idioma dado: un buen diccionario tiene entre 100 mil y 200 mil palabras y es un excelente punto

de partida. No es lo mismo que un ataque de pura fuerza bruta, que prueba todas las combinaciones

posibles.


Como se indica en, “Los diccionarios son archivos con millones de palabras, las cuales pueden ser

passwords utilizadas por los usuarios”. El atacante utiliza un programa que se encarga de probar

cada una de las palabras cifrando cada una de ellas (mediante el algoritmo utilizado por el sistema

atacado) y comparando la palabra cifrada contra el archivo de passwords del sistema atacado

(previamente obtenido). Si coinciden se ha encontrado la clave de acceso al sistema mediante el

usuario correspondiente a la clave hallada. Actualmente es posible encontrar diccionarios de gran

tamaño orientados, incluso, a un área específica de acuerdo al tipo de organización que se esté

atacando.

Los ataques de diccionario tienen pocas probabilidades de éxito con sistemas que utilizan

contraseñas fuertes con letras en mayúsculas y minúsculas mezcladas con números y con cualquier

otro tipo de símbolos. Sin embargo para la mayoría de usuarios recordar contraseñas tan complejas

resulta complicado, por lo que un ataque de diccionario suele ser más eficaz que uno de fuerza bruta.


Los mecanismos de detección de esta técnica de ataque de adivinación son similares a los

especificados para Guessin - Brute Force.


Las acciones de respuesta de esta técnica de ataque de adivinación son similares a los especificados

para Guessin - Brute Force

III.6 Exploits

Ataque que consiste en utilizar un trozo de código, fragmento de datos o secuencia de comandos y/o

acciones llamado exploit, para explotar los agujeros o vulnerabilidades de seguridad existentes en un

sistema de información, con el objetivo de conseguir un acceso no autorizado a la máquina objetivo o

provocar un comportamiento no deseado de dicho sistema o de alguno de los servicios que éste

presta. Los objetivos perseguidos por los atacantes mediante la explotación de exploits son muchos y

variados, como por ejemplo, conseguir acceso al sistema de forma no autorizada, obtener privilegios

no concedidos de forma lícita, realizar un ataque de denegación de servicio, etc.

Cabe aclarar que el término exploit hace referencia al trozo de código que el atacante ejecuta para

explotar la vulnerabilidad encontrada y conseguir su objetivo.


Para llevar a cabo esta técnica de ataque, los atacantes ejecutan programas que permiten explotar

estos “agujeros” de seguridad que reciben el nombre de Exploits. El funcionamiento es el siguiente: el

programa aprovecha la debilidad, fallo o error hallado en el sistema (hardware o software) para

conseguir acceso al mismo. Nuevos exploits (que explotan nuevas vulnerabilidades en los sistemas)

se publican cada día por lo que mantenerse informado de los mismos y de las herramientas para

combatirlos es esencial.

III.6.2 Detección

Como técnicas de detección de este tipo de ataques se distinguen:


311

- Los programas detectores de exploits se centran en la detección de malware existente en el

PC después de que la vulnerabilidad haya sido explotada, actualizándose a posteriori con

firmas o ficheros de datos para reconocer las cargas dañinas instaladas sobre el PC tras

explotar las brechas de seguridad existentes.

- Identificación del código de explotación, para lo que deben analizarse las versiones del

programa afectado por la vulnerabilidad antes y después de la aplicación del parche

correspondiente para averiguar cómo funciona tal código.

En máquinas Windows hay ciertos indicios que permiten detectar que un atacante ha explotado una

vulnerabilidad mediante un exploit:

- El tráfico de red de salida es sospechosamente alto, sobre todo cuando el ordenador está

inactivo o no necesariamente cargando datos.

- Reducción drástica del espacio libre en disco, o existencia de archivos de aspecto

sospechoso en los directorios raíces de cualquiera de los discos. Después de penetrar en el

sistema, muchos hackers realizan un escaneo masivo para encontrar documentos

interesantes o archivos que contengan contraseñas.

- Se produce un gran aumento en el número de paquetes que son bloqueados por un

cortafuegos personal, procedentes de una dirección simple.

De la misma forma, posibles indicios de exploits en máquinas Unix son:

- Existencia de archivos con nombres sospechosos en el archivo /tmp folder.

- Instalación de backdoors o modificación de utilidades estándar del sistema que se usan para

conectarse con otros sistemas.

- Alteración de los ficheros /etc/passwd, /etc/shadow, u otros archivos de sistemas en el

directorio /etc, por un usuario sin privilegios. A veces los atacantes pueden añadir un nuevo

usuario en el fichero /etc/passwd, para que este tenga acceso remoto al sistema de forma

lícita en una fecha posterior.

- Modificación del fichero /etc/services así como de /etc/ined.conf, para establecer una

backdoor en puerto sospechoso o no usado.


Entre las acciones de respuesta que puede llevar a cabo el AIRS ante este tipo de ataque se

encuentran:

- Agregar o borrar reglas de filtrado en los cortafuegos, (R26, Respuesta Activa de Protección y


- Bloquear la IP del atacante temporalmente hasta que cesen los intentos de conexión (R31,

Respuesta Activa de Protección y Respuesta Proactiva).

- Terminar conexión TCP establecida por el atacante (R34, Respuesta Activa de Protección y


- Bloquear conexiones de red entrantes y salientes sospechosas (R33, Respuesta Activa de


- Eliminar cualquier nombre de usuario sospechoso en el archivo de contraseñas (R15,

Respuesta Activa de Protección y Respuesta Proactiva).


312

III.7 Virus

Un virus es un programa que se replica a sí mismo y que se propaga a través de archivos infectados.

Una vez cargado en memoria cumple las instrucciones programadas por su creador, que pueden ser:

destruir ficheros, modificar ficheros, sobrecargar recursos, entre otros.


Un virus es un trozo de código incrustado en un programa que se replica a sí mismo y se propaga a

través de archivos infectados, cuyo objetivo es alterar el funcionamiento normal de la máquina

atacada, creando o modificando ficheros, sobrecargando los recursos del sistema, etc.

Un virus tiene las siguientes características:

- Se replican (propagan) y ejecutan por sí mismos.

- Reemplazan archivos ejecutables por otros infectados con el código de éste.

- Contienen una carga dañina (payload) con distintos objetivos: destruir datos dañando el

sistema; bloquear las redes informáticas generando tráfico inútil; ser “algo molestos”.

Su mecanismo de funcionamiento es el siguiente:

- Se ejecuta un programa infectado (por desconocimiento del usuario).

- El código del virus queda residente en RAM, aun cuando el programa que lo contenía haya

terminado.

- El virus toma el control de los servicios básicos del SO, infectando archivos ejecutables que

serán llamados posteriormente.

- Finalmente, se añade el código del virus al del programa infectado y se graba en disco, con lo

cual el proceso de replicación se completa.

Los efectos de un virus varían desde la simple visualización de una pelota de ping pong rebotando

por toda la pantalla de escritorio de la máquina víctima, hasta la eliminación de ficheros o

desinstalación de programas.

III.7.1.1 Tipos de virus

Los virus se clasifican según diferentes criterios. Se pueden clasificar, por ejemplo, según el tipo de

activo infectado (ref11):

- Archivos:

o Virus de acción directa: al ejecutarse, infectan otros programas.

o Virus residentes: al ejecutarse, se instalan en la RAM. Infectan a los demás

programas a medida que se accede a ellos.

- Sector de arranque (virus de boot). Estos virus residen en la memoria.

- Ambos: infectan archivos y al sector de arranque.

También se clasifican según su comportamiento:

- Kluggers: al entrar en otros sistemas se reproducen y cifran de manera que sólo se les puede

detectar con algún tipo de patrones.

- Viddbers: modifican los programas del sistema en el cual entran.

Así mismo, existen otras posibles clasificaciones:

- Virus uniformes: producen una replicación idéntica a sí mismos.


313

- Virus cifrados: cifran parte de su código para que sea más complicado su análisis.

- Virus oligomórficos: usan funciones de encriptación aleatorias. Requieren distintos patrones

para su detección.

- Virus polimórficos: en su replicación producen una rutina de encriptación variable, tanto en la

fórmula como en el algoritmo. Requiere técnicas antivirus avanzadas.

- Virus metamórficos: reconstruyen todo su cuerpo en cada generación, haciendo que varíe por

completo. De esta forma se llevan las técnicas avanzadas de detección al límite.

- Sobrescritura: el virus sobrescribe a los programas infectados con su propio cuerpo.

- Stealth o silencioso: el virus oculta síntomas de la infección.

III.7.2 Detección


- Uso de programas antivirus que analizan la firma del virus.

- Cambios producidos en la organización del sistema de ficheros o en la información del

sistema.

- Ejecución del método heurístico, que implica el análisis del comportamiento de las

aplicaciones para detectar una actividad similar a la de un virus conocido.

- Aumento del consumo de recursos del sistema que implican una pérdida de productividad,

cortes en los sistemas de información o daños a nivel de datos.



encuentran:

- Analizar las trazas que ha dejado un virus para eliminarlo una vez detectado (R7, Respuesta

Activa de Reacción).

- Generar filtros de ficheros dañinos, por ejemplo en el sistema de correo.

- Realizar copias de seguridad de todos los activos del sistema (R9, Respuesta Proactiva) con

el fin de futuras restauraciones (R13, Respuesta Activa de Recuperación).

- Restauración completa de la máquina o sistema comprometido (formateo) (R18, Respuesta

Activa de Recuperación).

- Denegar el acceso de forma selectiva o completa a un archivo (R10, Respuesta Activa de


III.8 Worms (Gusanos)

Un worm o gusano es un programa que se reproduce por sí mismo, que puede viajar a través de

redes utilizando los mecanismos de éstas y que no requiere respaldo de software o hardware (como

un disco duro, un programa host, un archivo, etc.) para difundirse.


Un gusano puede considerarse una técnica de ataque similar a los virus pero que no dependen de

archivos portadores para poder llegar e infectar otros sistemas.

Las principales características de los gusanos son:

- No altera los archivos del sistema sino que residen en la memoria y se duplica a sí mismo.


314

- Pueden modificar el SO con el fin de autoejecutarse como parte del proceso de inicialización

del sistema.

- Utilizan las partes automáticas de un SO que generalmente son invisibles al usuario.

Principalmente su mecanismo de funcionamiento es el siguiente: explotar vulnerabilidades de la

máquina objetivo o utilizar algún tipo de ingeniería social para engañar a los usuarios y poderse

ejecutar. Los gusanos actuales se propagan principalmente con clientes de correo electrónico (en

especial de Outlook) mediante el uso de adjuntos que contienen instrucciones para recolectar todas

las direcciones de correo electrónico de la libreta de direcciones y enviar copias de ellos mismos a

todos los destinatarios.

Generalmente, estos gusanos son scripts (típicamente en VBScript) o archivos ejecutables enviados

como un adjunto, que se activan cuando el destinatario hace clic en el adjunto.

III.8.2 Detección


- Aumento drástico del consumo de recursos de la máquina víctima. Tienen una incontrolada

replicación, por lo que consumen muchos recursos del sistema, hasta el punto de que los

procesos del sistema se ejecutan de forma excesivamente lenta o no pueden ejecutarse.

- Modificación de información del sistema de forma no autorizada.

- Ver Virus. Detección.



encuentran:

- Similar a los virus. Ver III.7.3.

III.9 Troyanos

La intrusión conocida bajo el nombre de Troyano, consiste en un programa oculto dentro de otro que

ejecuta comandos furtivamente y que, por lo general, abre el acceso al ordenador y abriendo una

backdoor.


Este ataque se basa en la utilización de un código malicioso que se encuentra en un programa sano

(por ejemplo, un comando falso para crear una lista de archivos que los destruye en lugar de mostrar

la lista).

El atacante introduce el trozo de código malicioso dentro de un programa útil del sistema. La

ejecución del programa origina la ejecución de la rutina, instalando así el troyano en el sistema al

ejecutar dicho archivo. El objetivo de este ataque no es reproducirse para infectar a otras máquinas,

sino abrir un puerto en la máquina víctima para que un atacante pueda establecer conexión con ella a

través del puerto o backdoor establecida, y tener control sobre la máquina comprometida. Para ello,

debe infectar la máquina obligando a abrir un archivo infectado que contiene el Troyano, y luego,

acceder a la máquina a través del puerto abierto. Hay una serie de puertos fijos utilizados

generalmente por los troyanos, como por ejemplo, el puerto 28678 utilizado por Exploiter, el puerto

29104 utilizado por NetTrojan, puerto 29369 utilizado por ovasOn, etc.

Una vez instalado, el troyano puede realizar las siguientes tareas:

- Espiar al usuario: obtención de contraseñas mediante captura de las pulsaciones del teclado,

etc.


315

- Realizar operaciones maliciosas dentro de la máquina como la instalación de programas.

- Creación de un agujero de seguridad en la red para que los usuarios externos puedan

acceder a áreas protegidas de esa red.

- Establecimiento de BackDoors, para que el atacante pueda acceder a la máquina

comprometida.

- Etc.

III.9.2 Detección

La infección es evidente por los siguientes síntomas:

- Actividad anormal de dispositivos de red o del propio sistema, como por ejemplo:

Reacciones extrañas de los dispositivos periféricos como el ratón o el teclado.

Programas que se abren en forma inesperada.

Bloqueos repetidos.



encuentran:

- Agregar o borrar reglas de filtrado sobre el cortafuegos (R26 y R28, Respuesta Activa de

Protección y Respuesta Proactiva), que bloqueen el establecimiento de conexiones salientes

por parte de programas cuyo origen se desconoce (R33, Respuesta Activa de Protección y


- Eliminar el troyano, mediante herramientas como The Cleaner (R11, Respuesta Activa de

Recuperación)

- Formatear la máquina afectada (R18, Respuesta Activa de Protección y Respuesta

Proactiva).

- Cerrar el puerto utilizado por el troyano para abrir una backdoor (R31 y R34, Respuesta


- Realizar copias de seguridad de todos los ficheros del sistema (R9, Respuesta Proactiva).


Reacción).

- Denegar el acceso de forma selectiva o completa a un archivo (R10, Respuesta Activa de


III.10 Buffer Overflow

Ataque que se basa en la ejecución de un código arbitrario en un programa al enviar un caudal de

datos mayor que el que puede recibir. Un programa que admite datos de entrada con parámetros, los

almacena temporalmente en una zona de la memoria denominada búfer. El problema es que algunas

funciones no admiten este tipo de desbordamiento y provocan el bloqueo de la aplicación, lo que

permite la ejecución del código arbitrario del atacante y permite el acceso al sistema.


Los pasos que rigen el comportamiento habitual de este ataque son los siguientes:


316

- El servidor reserva unas posiciones de memoria para almacenar los datos que le llegan por la

red. Para estimar el tamaño de la memoria a reservar, el programador comprueba cuál es el

tamaño máximo de los datos que le pueden llegar según el estándar del protocolo

implementado. En principio, se supone que no deberían llegar datos de tamaño superior al

máximo permitido por el estándar.

- Un atacante genera un paquete de datos malicioso con un tamaño superior al máximo

permitido.

- El servidor recibirá esos datos y los irá almacenando en la memoria reservada. Cuando el

servidor llena el espacio reservado se pueden dar dos situaciones:

El servidor comprueba la situación y advierte que el tamaño de los datos

enviados supera el máximo permitido, por lo que rechaza la petición por no ser

conforme al estándar. En este caso, no se da opción a la realización de un

ataque.

El servidor no comprueba la situación y sigue transfiriendo los datos a memoria,

sin darse cuenta de que los está enviando a posiciones de memoria que no han

sido reservadas y que, por lo tanto, está sobrescribiendo posiciones de memoria.

Es en este caso, cuando se puede intentar realizar el ataque.

- Si el servidor no comprueba el desbordamiento de buffer, el comportamiento más normal es

intentar sobrescribir posiciones de memoria protegidas por el sistema operativo, caso en que

el propio sistema operativo aborta la ejecución del servidor con un programa de error. No

obstante, existe un caso en el que se sobrescriben posiciones de memoria especiales, las

correspondientes a la pila del sistema operativo, que contienen las direcciones de las

instrucciones que el sistema operativo va a ejecutar.

- Si el atacante consigue que uno de los datos que se desborda del buffer sobrescriba la pila

del sistema operativo, puede forzar la escritura de la dirección del buffer de memoria donde el

servidor ha ido almacenando los datos que le ha enviado previamente el atacante.

- Por último, el sistema operativo intentará ejecutar el código apuntado desde la pila, es decir,

intentará ejecutar el contenido de los datos que el atacante ha enviado previamente. Si estos

datos contienen instrucciones que permiten al atacante hacerse con el control del sistema, el

sistema operativo lo ejecutará y el atacante habrá realizado con éxito un acceso remoto no

autorizado al sistema.

III.10.2 Detección


- El sistema ejecuta procesos o acciones no ordenadas por el administrador o el usuario del

sistema.

- Modificación de información del sistema.

- Aumento del consumo de disco en momentos no esperados.



encuentran:

- Eliminar el proceso que se está ejecutando con el trozo de código malicioso (R22 y R23,

Respuesta Activa de Protección y Respuesta Activa de Recuperación.

- Devolver los activos afectados a su estado previo al ataque (R13 y R18 Respuesta Activa de

Recuperación).


317

III.11 Denial of Service

Ataque cuyo objetivo es saturar los recursos de la máquina víctima de tal forma que se inhabilitan los

servicios prestados por la misma durante un periodo de tiempo indefinido. Hace inaccesible un

servicio o recurso a los usuarios legítimos, provocando normalmente, la pérdida de la conectividad de

la red por el consumo del ancho de banda de la red del sistema atacado o sobrecarga de los recursos

computacionales del mismo.


El ataque se puede dar de muchas formas, pero todas utilizan el protocolo TCP/IP para llevarse a

cabo. Se genera mediante la saturación de los puertos con flujo de información, haciendo que el

servidor se sobrecargue y no pueda seguir prestando servicios a los usuarios habituales, o el sistema

se vuelva inestable.

Como evolución del DoS, ha surgido el ataque DDoS (Distributed Denial of Service), una ampliación

del ataque DoS, que se lleva a cabo instalando varios agentes remotos en muchos ordenadores

localizados en diferentes puntos (o en el mismo). El invasor consigue coordinar los agentes para

incrementar de forma masiva la saturación de información, hasta el punto de conseguir lanzar un

ataque de cientos de máquinas dirigido a una máquina o sistema objetivo. Esta técnica se ha

revelado como una de las más eficaces y sencillas a la hora de colapsar servidores.

El objetivo de ambos ataques no reside en recuperar, modificar o destruir datos, sino que se trata de

un ataque a la imagen y reputación de las compañías afectadas. Puede ser que los atacantes

necesiten que un sistema caiga para que un administrador lo reinicie. Es muy fácil vulnerar un

sistema justo durante el reinicio, antes de que todos los servicios estén totalmente operativos.

No se trata de ataques muy complicados pero son ataques eficaces contra cualquier tipo de equipo o

sistema operativo.

III.11.1.1 Tipos de ataques DoS

Hay varias formas de expresión de un ataque de DoS (Basados en host, basados en red o

distribuidos):

- Jamming o Flooding: ataque que consiste en desactivar o saturar los recursos de un sistema.

El atacante satura el sistema con mensajes que requieren establecer conexión pero los

mensajes contienen falsas direcciones IP origen (en lugar de la dirección IP del emisor). El

sistema responde a esta falsa dirección y al no recibir respuesta acumula buffers que

contienen información de las conexiones abiertas. Al almacenarse muchas de estas

conexiones, no hay lugar para las peticiones de los usuarios legítimos. Ejemplos: el conocido

ping de la muerte o el hecho de que un atacante consuma toda la memoria o espacio en

disco disponible o envíe tal cantidad de tráfico a la red que esta quede inutilizada para el

resto de usuarios.

- Syn Flood: ataque de DoS más famoso que se basa en el modo de funcionamiento del

protocolo TCP. Consiste en que el atacante envía un paquete SYN a la máquina objetivo, que

le envía un ACK; el atacante no responde a dicho ACK lo que provoca que la máquina

destino (víctima del ataque) espere un cierto tiempo antes de cerrar la conexión. Si se crean

muchas peticiones incompletas de conexión, la máquina objetivo, normalmente un servidor,

estará inactivo mucho tiempo esperando respuesta lo que produce una negación de servicio

al resto de intentos de conexión. Además, muchos sistemas operativos tienen un límite muy

bajo del número de conexiones “semiabiertas" que pueden manejar en un momento

determinado. Si se supera ese límite, el servidor dejará de responder a las nuevas peticiones

de conexión que le vayan llegando. Este ataque suele combinarse con el IP Spoofing, para

ocultar el origen del ataque.


318

- Connection Flood: ataque que se basa en explotar la limitación en el número de conexiones

simultaneas que pueden sostener los ISP. Una vez alcanzado el máximo límite permitido, el

ISP no admitirá conexiones nuevas. El atacante inicia numerosas conexiones hasta que

supera el límite, impidiendo al resto de usuarios legítimos establecer conexiones con el ISP

víctima y dejando fuera de servicio al servidor.

- Net Flood: ataque que consiste en que el atacante envía tantos paquetes de solicitud de

conexión que las conexiones de usuarios legítimos no pueden ni siquiera intentar tener éxito.

La red atacada no puede hacer nada puesto que aunque filtre el tráfico en sus sistemas, sus

líneas estarán saturadas de tráfico malicioso, inhabilitándolas para cursar tráfico útil.

- Land Attack: ataque que se basa en explotar un error en la implementación de la pila TCP/IP

de las plataformas Windows. El ataque consiste en mandar a algún puerto abierto de un

servidor (generalmente al 113 o al 139) un paquete, maliciosamente construido, con la

dirección y puerto origen igual que la dirección y puerto destino. Una vez que ha pasado un

número considerable de mensajes enviados-recibidos la máquina termina colgándose.

- Supernuke o Winnuke: ataque característico de los equipos con Windows que hace que los

equipos que escuchan por el puerto UDP 137 a 139 (utilizados por los protocolos Netbios de

Wins), queden fuera de servicio o disminuyan su rendimiento al enviarle paquetes UDP

manipulados. Generalmente se envían fragmentos de paquetes, que la máquina víctima

detecta como inválidos pasando a un estado inestable.

- E-mail Bombing-Spamming: ataque que consiste en enviar muchas veces un mensaje

idéntico a una misma dirección, saturando así la cola de entrada de mail del destinatario. El

Spamming, en cambio se refiere a enviar el e-mail a miles de usuarios, hayan estos

solicitados el mensaje o no.

III.11.2 Detección

Como indicios para detectar este tipo de ataques se distinguen:

- Aumento del número de conexiones fallidas o semiabiertas.

- Consumo de disco no correspondiente a la actividad de un usuario legítimo.

- Caída inexplicable de un sistema conectado a la red.

- Fallo general del sistema o cuelgue de procesos por falta de CPU que está siendo utilizada

por el atacante.

- Redirección del tráfico de la máquina víctima hacia un agujero negro. (Ataques a los DNS y

de enrutamiento).



encuentran:

- Restringir la actividad de un usuario (R14, Respuesta Activa de Protección y Respuesta

Proactiva).

- Terminar o reiniciar el servicio comprometido (R19 y R20, Respuesta Activa de Protección y


- Terminar o reiniciar el proceso sospechoso (R22 y R23, Respuesta Activa de Protección y


- Bloquear peticiones al sistema sospechosas (R24, Respuesta Activa de Protección y



319

- Agregar o borrar reglas de filtrado sobre un cortafuegos (R26 y R28, Respuesta Activa de


- Bloquear puertos o direcciones IP (R31, Respuesta Activa de Protección y Respuesta

Proactiva).

- Terminar conexión TCP establecida por el atacante (R34, Respuesta Activa de Protección).


Reacción).

Además de los tipos de ataques descritos, también hay ataques de phising y ataques físicos, pero no

se incluyen porque el AIRS no puede ejecutar ninguna acción de respuesta automática frente a este

tipo de ataques.

Aclarar también, que TODAS las respuestas pasivas y la mayoría de las Activas de Engaño pueden

ser ejecutadas frente a cualquiera de los 10 tipos de ataque.

Referencias

321

Referencias

A

[Abdoli09] F. Abdoli, M. Kahani. Ontology-based Distributed Intrusion Detection System. Proceedings of the 14

th International CSI Computer Conference

(CSICC’09), 2009.

[Amoroso99] E. G. Amoroso. Intrusion Detection: An Introduction to Internet Surveillance, Correlation, Trace Back, Traps, and Response. Intrusion Net Books, 1999.

[Annamalai03] M. Annamalai, L. Sterling. Guidelines for Constructing Reusable Domain Ontologies. Proceedings in AAMAS03 Workshop on Ontologies in Agent Systems, pp. 71-74. 2003.

[Anuar10] N. B. Anuar, M. Papadaki, S. Furnell, N. Clarke. An investigation and survey of response options for Intrusion Response Systems (IRSs). Information Security for South Africa (ISSA), pp. 1-8. 2010.

[Aslam95] T. Aslam. A taxonomy of Security Faults in the Unix Operating System. M. S. Thesis, Purdue University. 1995.

[Azevedo10] R. B. Azevedo, E. Rommel, G. Dantas, F. Freitas, C. Rodrigues, M. J. Siqueira, C. Almeida, W. C. Veras, R. Santos. An Autonomic Ontology-based Multiagent System for Intrusion Detection. Computing Environments. International Journal for Infonomics (IJI), Vol. 3 (1), pp. 182-189. 2010.

B

[Battle05] S. Battle et. al. Semantic Web Services Language (SWSL). W3C Member Submission. 9 de Septiembre 2005. [http://www.w3.org/Submission/SWSF-SWSL/]

[Bechhofer04a] S. Bechhofer, F. van Harmelen, J. Hendler, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider, L. A. Stein. OWL Web Ontology Language Reference. W3C Recommendation. 10 de Febrero 2004. [http://www.w3.org/TR/owl-ref/]

[Bechhofer04b] S. Bechhofer, I. Horrocks. Hoolet: an OWL Reasoner with support for rules.

2004. [http://www.daml.org/meetings/2004/05/pi/pdf/Hoolet.pdf]

[Beckett04] D. Beckett. RDF/XML Syntax Specification (Revised). W3C Recommendation. 10 de Febrero 2004. [http://www.w3.org/TR/REC-rdf-

syntax/]

[Berners-Lee01] T. Berners-Lee, J. Hendler, O. Lassila. The Semantic Web. Scientific American. Mayo de 2001.

[Berstel02] B. Berstel. Extending the RETE Algorithm for Event Management. Proceedings of the Ninth International Symposium on Temporal Representation and Reasoning (TIME’02), pp. 49-51. 2002.

http://www.w3.org/Submission/SWSF-SWSL/

http://www.w3.org/Submission/SWSF-SWSL/

http://www.w3.org/TR/owl-ref/

http://www.daml.org/meetings/2004/05/pi/pdf/Hoolet.pdf

http://www.w3.org/TR/REC-rdf-syntax/

http://www.w3.org/TR/REC-rdf-syntax/


322

[Bisbey78] R. Bisbey, D. Hollingworth. Protection Analysis: Final Report. Technical report, University of Southern California. 1978.

[Bishop96] M. Bishop, D. Bailey. A Critical Analysis of Vulnerabilities Taxonomies. Technical Report CSE-96-11. 1996.

[Bossam] Bossam Rule/OWL Reasoner. [http://bossam.wordpress.com/about-bossam/]

[Bozsak02] E. Bozsak, M. Ehrig, S. Handschuh, S. H, A. Maedche, A. Hotho, E. Maedche, B. Motik, D. Oberle, C. Schmitz, N. Stojanovic, Rudi, S. Staab, L. Stojanovic, V. Zacharias. KAON – Towards a large scale Semantic Web. In: Bauknecht, K., Tjoa, A.M., Quirchmayr, G. (eds.) EC-Web 2002. LNCS, Vol. 2455, pp. 304–313. Springer, Heidelberg, 2002.

[Bradshaw03] J. M. Bradshaw, A. Uszok, R. Jeffers, N. Suri, P. Hayes, M. H. Burstein, A. Acquisti, B. Benyo, M. R. Breedy, M. Carvalho, D. Diller, M. Johnson, S. Kulkarni, J. Lott, M. Sierhuis, R. Van Hoof. Representation and reasoning for DAML-based policy and domain services in KAoS and Nomad. Proc. Autonomous Agents and Multi-Agent Systems Conference (AAMAS 2003), Melbourne, Australia. 2003.

[Bruijn05] J. de Bruijn, D. Fensel, U. Keller, M. Kifer, H. Lausen, R. Krummenacher, A. Polleres, L. Predoiu. Web Services Modeling Language (WSML). W3C Member Submission. 3 de Junio 2005. [http://www.w3.org/Submission/WSML/]

C

[Carver01a] C. A. Carver. Adaptive agent-based intrusion response. PhD thesis, Texas A&M University. 2001.

[Carver01b] C. A. Carver, J. M. D. Hill, U. W. Pooch Limiting Uncertainty in Intrusion Response. Proceedings of the 2001 IEE Workshop On Information Assurance and Security United States Military Academy. 2001.

[Connolly01] D. Connolly, F. van Harmelen, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider, L. A. Stein. DAML+OIL (March 2001) Reference. W3C Note. 18 de Diciembre 2001. [http://www.w3.org/TR/daml+oil-reference]

[CVE] Common Vulnerability and Exposures (CVE). The Standard for Information Security Vulnerability Names. [http://cve.mitre.org/index.html]

D

[DeFrutos09] E. de Frutos. Desarrollo de un motor de generación de políticas de seguridad basado en ontologías. Proyecto de fin de carrera ETSIT UPM. 2009.

[Desai03] N. Desai. Intrusion prevention systems: The next step in the evolution of IDS. 2003. [http://www.symantec.com/connect/articles/intrusion-prevention-

systems-next-step-evolution-ids]

[DublinCore] Dublin Core Metadata Initiative. [http://dublincore.org/documents/library-application-profile/index.shtml#Alternative]

F

[FaCT] The FaCT System. [http://owl.man.ac.uk/factplusplus/]

[FaCT++] FaCT++. [http://owl.man.ac.uk/factplusplus/]

[FaCT++b] FaCT++ Binary Code. [http://code.google.com/p/factplusplus/]

[Fan04] W. Fan, M. Miller, S. Stolfo, W. Lee, P. Chan. Using artificial anomalies to detect unknown and known network intrusions. Knowledge and Information Systems, Vol. 6 ( 5), pp. 507-527, April 2004.

[Fensel01] D. Fensel, F. van Harmelen, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider. OIL: An Ontology Infrastructure for the Semantic Web. IEEE Intelligent Systems Vol. 16 (2), pp. 38- 45, 2001.

http://bossam.wordpress.com/about-bossam/

http://www.w3.org/Submission/WSML/

http://www.w3.org/TR/daml+oil-reference

http://cve.mitre.org/index.html

http://www.symantec.com/connect/articles/intrusion-prevention-systems-next-step-evolution-ids

http://www.symantec.com/connect/articles/intrusion-prevention-systems-next-step-evolution-ids

http://dublincore.org/documents/library-application-profile/index.shtml#Alternative

http://dublincore.org/documents/library-application-profile/index.shtml#Alternative

http://owl.man.ac.uk/factplusplus/

http://owl.man.ac.uk/factplusplus/

http://code.google.com/p/factplusplus/

Referencias

323

[Fernández-López97] M. Fernández-López, A. Gómez-Pérez, N. Juristo. METHONTOLOGY: From Ontological Art Towards Ontological Engineering. Proceedings of the Spring Symposium Series, pp. 33-40. 1997.

[Fernández-López99] M. Fernández-López. Overview of Methodologies for Building Ontologies. In: IJCAI99 Workshop on Ontologies and Problem-Solving Methods: Lessons Learned and Future Trends, Stockholm. 1999.

[Fernández04] G. Fernández. Representación del conocimiento en sistemas inteligentes. Universidad Politécnica de Madrid. Noviembre de 2004. [http://www.gsi.dit.upm.es/~gfer/ssii/rcsi/index.html]

[Foo05] B. Foo, Y.-S. Wu, Y.-C. Mao, S. Bagchi, E. Spafford. ADEPTS: Adaptive Intrusion Response Using Attack Graphs in an E-Commerce Environment. International Conference on Dependable Systems and Networks (DSN’05), pp.508- 517, 2005.

[Forgy82] C. L. Forgy. RETE: A fast algorithm for the many pattern/many object pattern match problem. Artificial Intelligence Vol. 19 (1), pp. 17-37, 1982.

G

[Galan10] F. Galan, D. Fernandez, J. E. Lopez de Vergara, R. Casellas. Using a model-driven architecture for technology-independent scenario configuration in networking testbeds. IEEE Commun Mag 2010:132–141. 2010.

[Garbajosa07] J. Garbajosa, F. J. Soriano, J. J. Moreno. Tecnologías software para la explotación de aplicaciones basadas en servicios. Informe de Vigilancia Tecnológica. Círculo de Innovación en tecnologías de la información y las telecomunicaciones. 2007.

[García05] F. J. García, G. Martínez, J. A. Botía, A. F. Gómez Skarmeta. Representing Security Policies in Web Information Systems. Proc. Policy Management for the Web (PM4W), 14th Intl. WWW Conference, Chiba, Japan. 2005.

[GarcíaPeñalvo05] F. J. García Peñalvo. Web Semántica y Ontologías. Tendencias en el Desarrollo de Aplicaciones Web. 2005.

[Gómez-Pérez96] A. Gómez-Pérez. A Framework to Verify Knowledge Sharing Technology. Expert Systems with Application, Vol. 11 (4), pp. 519-529. 1996.

[Graphviz] Graphviz- Graph Visualization Software. [http://www.graphviz.org/]

[Gruber95] T. R. Gruber. Toward principles for the design of ontologies used for knowledge sharing. Padua workshop on Formal Ontology, 1993. International Journal of Human-Computer Studies, Vol. 43 (4-5), pp. 907-928. 1995.

[Grüninger95] M. Grüninger, M. S. Fox. Methodology for the Design and Evaluation of Ontologies. Proceedings of the Workshop on Basic Ontological Issues in Knowledge Sharing, IJCAI. 1995.

[Grüninger96] M. Grüninger. Designing and Evaluating Generic Ontologies. Proceedings of the 12th European Conference of Artificial Intelligence, pp. 53-65. 1996.

[Guaman13] D. S. Guamán. Propuesta de Arquitectura e Implementación de un Módulo de Ejecución de Acciones de Respuesta para un Sistema Autónomo de Respuesta a Intrusiones Basado en Ontologías. UPM. 2013.

[Guerrero07] A. Guerrero. Especificación del comportamiento de gestión de red mediante ontologías. Tesis doctoral (PhD Thesis), Departamento de Ingeniería de Sistemas Telemáticos, Universidad Politécnica de Madrid (UPM). 2007.

H

[Haarslev12] V. Haarslev, K. Hidde, R. Möller, M. Wessel. The RacerPro knowledge representation and reasoning system. Semantic Web, Vol. 3 (3), pp. 267-277, 2012.

http://www.gsi.dit.upm.es/~gfer/ssii/rcsi/index.html

http://www.graphviz.org/


324

[Hansman05] S. Hansman, R. Hunt. A taxonomy of network and computer attacks. Computer Security, Vol. 24, pp. 31-43, 2005.

[Hayes04] P. Hayes. RDF Semantics. W3C Recommendation. 10 de Febrero 2004. [http://www.w3.org/TR/rdf-mt/]

[Herzog07] A. Herzog, N. Shahmehri, C. Duma. An Ontology of Information Security. International Journal of Information Security and Privacy, Vol. 1 (4), pp. 1–23. 2007.

[Hitzler12] P. Hitzler, M. Krötzsch, B. Parsia, P. F. Patel-Schneider, S. Rudolph. OWL2 Web Ontology Language Primer (Second Edition). W3C Recommendation. 11 de Diciembre 2012. [http://www.w3.org/TR/owl2-primer/]

[Hoolet] Hoolet. [http://owl.man.ac.uk/hoolet/]

[Horrocks04] I. Horrocks, P. F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, M. Dean. SWRL: A Semantic Web Rule Language Combining OWL and RuleML. W3C Member Submission. 21 de Mayo 2004. [http://www.w3.org/Submission/SWRL/]

[Hoskins05] A. Hoskins, Y. Liu, A. Relkuntwar. Counter-Attacks for Cybersecurity Threats. 2005.

I

[IDMEF] Intrusion Detection Message Exchange Format (IDMEF). RFC4765. 2007. [http://www.ietf.org/rfc/rfc4765.txt]

J

[Jahnke07] M. Jahnke, C. Thul, P. Martini. Graph-based Metrics for Intrusion Response Measures in Computer Networks. In Proc. of the 3

rd LCN Workshop on

Network Security. Held in conjunction with the 32nd

IEEE Conference on Local Computer Networks (LCN), Ireland, 2007.

[Jang04] M. Jang, J-C Sohn. Bossam: An Extended Rule Engine for OWL Inferencing. Rules and Rule Markup Languages for the Semantic Web. LNCS Vol. 3323, pp. 128-138. 2004.

[Jess] Jess, the rule engine for the Java Platform. [http://www.jessrules.com]

[Jones98] D. M. Jones, T. J. M. Bench-Capon, P. R. S. Visser. Methodologies for Ontology Development. Proceedings of IT&KNOWS Conference, XV IFIP World Computer Congress. 1998.

K

[Kagal02] L. Kagal. Rei: A Policy Language for the Me-Centric Project. HP Labs Technical Report HPL-2002-070. 2002.

[Kagal04] L. Kagal. Rei Ontology Specifications. 2004. [http://www.csee.umbc.edu/~lkagal1/rei/]

[KAON2] KAON2. [http://kaon2.semanticweb.org/]

[Kanoun09] W. Kanoun, N. Cuppens-Boulahia, F. Cuppens, S. Dubus, A. Martin. Success Likelihood of Ongoing Attacks for Intrusion Detection and Response Systems. Proc. in 2009 International Conference on Computational Science and Engineering, pp. 83-91. 2009.

[Kaviani07] N. Kaviani, D. Gašević, M. Hatala, G. Wagner. Web Rule Languages to Carry Policies. Proceedings of the 8

th IEEE Workshop on Policies for Distributed

Systems and Networks, IEEE Computer Society (2007), pp. 188–192. 2007.

[Klinov08] P. Klinov. Pronto: A non-monotonic Probabilistic Description Logic Reasoner. The Semantic Web: Research and Applications. LNCS Vol. 5021, pp. 822-826. 2008.

http://www.w3.org/TR/rdf-mt/

http://www.w3.org/TR/owl2-primer/

http://owl.man.ac.uk/hoolet

http://www.w3.org/Submission/SWRL/

http://www.ietf.org/rfc/rfc4765.txt

http://www.jessrules.com/

http://www.csee.umbc.edu/~lkagal1/rei/

http://kaon2.semanticweb.org/

Referencias

325

[Klyne04] G. Klyne, J. J. Carroll. Resource Description Framework (RDF): Concepts and Abstract Syntax. W3C Recommendation. 10 de Febrero 2004. [http://www.w3.org/TR/rdf-concepts/]

L

[Lakhina05] A. Lakhina, M Crovella, C. Diot. Mining anomalies using traffic feature distributions. ACM SIGCOMM Computer Communication Review - Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications, Vol. 35 (4), pp. 217-228. 2005.

[Landwehr94] C. E. Landwehr, A. R. Bull, J. P. McDermott, W. S. Choi. A Taxonomy of Computer Program Security Flaws. ACM Computing Surveys (CSUR), Vol. 26 (3), pp. 211-254. 1994.

[Lewandowski01] S. M. Lewandowski, D. J. VanHook, G. C. O’Leary, J. W. Haines, L. M. Rossey. SARA: Survivable Autonomic Response Architecture. In DARPA Information Survivability Conference and Exposition, pp:77-78, CA. 2001.

[Li08] W. Li, S. TIan. XSWRL, an Extended Semantic Web Rule Language. Second International Symposium on Intelligent Information Technology Application, 2008.

[Liu12] T. Liu, Z. Wang, H. Wang, K. Lu. An Entropy-based Method for Attack Detection in Large Scale Network. International Journal of Computer Communications, Vol. 7 (3), pp. 509-517. 2012.

[LópezDeVergara03] J. E. López de Vergara. Especificación de Modelos de Información de Gestión de Red Integrada Mediante el Uso de Ontologías y Técnicas de Representación del Conocimiento. Tesis doctoral (PhD Thesis), Departamento de Ingeniería de Sistemas Telemáticos, Universidad Politécnica de Madrid (UPM). 2003.

[LópezDeVergara04] J.E. Lopez de Vergara, V. A. Villagrá, J. Berrocal. Benefits of Using Ontologies in the Management of High Speed Networks. Proceedings of 7th IEEE International Conference on High Speed Networks and Multimedia Communications (HSNMC’04). Toulouse, France, 30 June–2 July 2004. Lecture Notes in Computer Science, vol. 3079, pp. 1007–1018, Springer-Verlag 2004.

[LópezDeVergara05] J. E. López de Vergara, V. A. Villagrá, J. Berrocal. Application of OWL-S to define management interfaces based on Web Services. Proceedings of the 8

th IFIP/IEEE International Conference on Management of Multimedia

Networks and Services (MMNS 2005), Barcelona, Spain. LNCS Vol. 3754, pp. 242-253, Springer Verlag. 2005.

[LópezDeVergara09] J. E Lopez de Vergara, E. Vázquez, A. Martín, S. Dubus, M-H. Lepareux. Use of Ontologies for the Definition of Alerts and Policies in a Network Security Platform. Journal of Networks, Vol. 4 (8), pp. 720-733. 2009.

M

[MAGERIT-I12] M. A. Amutio, J. Candau, J. A. Mañas. MAGERIT-versión 3.0. Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información. Libro I – Método. Ed. Ministerio de Hacienda y Administraciones Públicas. 2012.

[MAGERIT-II12] M. A. Amutio, J. Candau, J. A. Mañas. MAGERIT-versión 3.0. Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información. Libro II – Catálogo de Elementos. Ed. Ministerio de Hacienda y Administraciones Públicas. 2012.

[MAGERIT-III12] M. A. Amutio, J. Candau, J. A. Mañas. MAGERIT-versión 3.0. Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información. Libro III – Guía de Técnicas. Ed. Ministerio de Hacienda y Administraciones Públicas. 2012.

http://www.w3.org/TR/rdf-concepts/


326

[Manola04] F. Manola, E. Miller. RDF Primer. W3C Recommendation. 10 de Febrero 2004. [http://www.w3.org/TR/rdf-primer/]

[Martín04] D. Martin et al. OWL-S: Semantic Markup for Web Services. W3C Member Submission. 22 de Noviembre 2004. [http://www.w3.org/Submission/OWL-S/]

[Mateos10] V. Mateos. VA. Villagrá, F. Romero. Ontologies-based automated intrusion response system. In: Proceedings of the 3rd international conference on computational intelligence in security for information systems (CISIS ’10); November 11–12, 2010.

[Mateos12] V. Mateos, VA. Villagra, F. Romero, J. Berrocal. Definition of response metrics for an ontology-based Automated Intrusion Response Systems. Computers & Electrical Engineering, Vol. 38 (5), pp. 1102-1114. 2012.

[Mateos13] V. Mateos, VA. Villagrá, J. Berrocal. Application of Ontologies and Formal Behavior Definition for Automated Intrusion Response Systems. Journal of Research and Practice in Information Technology (JRPIT). Aceptada Pendiente de publicación.

[McGuinness04] D. L. McGuinness, F. van Harmelen. OWL Web Ontology Language Overview. W3C Recommendation. 10 de Febrero 2004. [http://www.w3.org/TR/2004/REC-owl-features-20040210/#s1.3]

[Mu10a] C. Mu, Y. Li. An intrusion response decision-making model based on hierarchical task network planning. Expert Systems with Applications, Vol. 37 (3), pp. 2465-2472. 2010.

[Mu10b] C. Mu, B. Shuai, H. Liu. Analysis of Response Factors in Intrusion Response Decision-Making. 2010 Third International Joint Conference on Computational Science and Optimization, pp. 395-399. 2010.

[Mu12] C. Mu, B. Shuai. Research on Preprocessing Technique of Alert Aggregation. 2012 Fifth International Joint Conference on Computational Sciences and Optimization, pp. 597-600. 2012.

N

[Novamente] MindOntology: Novamente Cognition Engine. [http://wiki.opencog.org/w/MindOntology:Novamente_Cognition_Engine]

[Noy01] N. F. Noy, D. L. McGuinness. Ontology Development 101: A Guide to Creating Your First Ontology. Stanford Knowledge Systems Laboratory Technical Report KSL-01-05 and Stanford Medical Informatics Technical Report SMI-2001-0880. 2001.

O

[Òhgren05] A. Ohgren, K. Sandkuhl. Towards a Methodology for Ontology Development in Small and Medium-sized Enterprises. In IADIS Conference on Applied Computing. 2005.

[OntoGraf] OntoGraf. [http://protegewiki.stanford.edu/wiki/OntoGraf]

[OntoViz] OntoViz. [http://protegewiki.stanford.edu/wiki/OntoViz]

[OSVDB] Open Sourced Vulnerability DataBase. [http://osvdb.org/]

[OWL2W3C09] OWL 2 Web Ontology Language Quick Reference Guide. W3C Working Draft. 11 de Junio 2009. [http://www.w3.org/TR/2009/WD-owl2-quick-

reference-20090611/#Axioms]

[OWL2W3C12] OWL 2 Web Ontology Language Document Overview (Second Edition). W3C Recommendation. 11 de Diciembre 2012. [http://www.w3.org/TR/2012/REC-owl2-overview-20121211/]

http://www.w3.org/TR/rdf-primer/

http://www.w3.org/Submission/OWL-S/

http://wiki.opencog.org/w/MindOntology:Novamente_Cognition_Engine

http://protegewiki.stanford.edu/wiki/OntoGraf

http://protegewiki.stanford.edu/wiki/OntoViz

http://osvdb.org/

http://www.w3.org/TR/2009/WD-owl2-quick-reference-20090611/#Axioms

http://www.w3.org/TR/2009/WD-owl2-quick-reference-20090611/#Axioms

http://www.w3.org/TR/2012/REC-owl2-overview-20121211/

Referencias

327

P

[Papadaki06] M. Papadaki, S. M. Furnell. Achieving automated intrusion response: a prototype implementacion. Information Management and Computer Security, Vol. 14 (3), pp. 235-251. 2006.

[Patel-Schneider05] P. F. Patel-Schneider. A Proposal for a SWRL Extension towards First-Order Logic. W3C Member Submission. 11 de Abril 2005. [http://www.w3.org/Submission/SWRL-FOL/]

[Pellet] Pellet: OWL2 Reasoner for Java. [http://clarkparsia.com/pellet]

[Pérez13] M. Gil Pérez, F. Gómez Mármol, G. Martínez Pérez, A. F. Skarmeta Gómez. RepCIDN: A Reputation-based Collaborative Intrusion Detection Network to Lessen the Impact of Malicious Alarms. Journal of Network and Systems Management, Vol. 21 (1), pp. 128-167. 2013.

[Peter11] E. Peter, T. Schiller. A Practival Guide to Honeypots. Washington University. 2011.

[Pfister04] C. E. Pfister, W. G. Sullivan. Renyi entropy, guesswork moments, and large deviations. IEEE Transactions on Information Theory, Vol. 50, pp. 2794-2800. 2004.

[Porras97] P. A. Porras, P. G. Neuman. EMERALD: Event Monitoring Enabling Responses To Anomalous Live Disturbances. In Proceedings of the 20

th

National Information Systems Security Conference (NISSC) pp. 353-365, Baltimore, MD. 1997

[Prieto06] J. Prieto. Proyecto Fin de Carrera: Especificación de Comportamiento de Gestión de Red mediante Ontologías. Departamento de Ingeniería Telemática, Universidad Politécnica de Madrid. 2006.

[Protégé] Protégé. [http://protege.stanford.edu/]

R

[RacerPro] RacerPro. [http://www.racer-systems.com/]

[Rash05] M. B. Rash. Intrusion Prevention and Active Response: Deploying Network and Host IPS. Syngress Media Incorporated, 2005.

[RDFMT01] RDF Model Theory. W3C Working Draft, 25 de Septiembre 2001. [http://www.w3.org/TR/rdf-mt/]

[RuleML] The Rule Markup Initiative. [http://www.ruleml.org]

S

[Shameli-Sendi12] A. Shameli-Sendi, N. Ezzati-Jivan, M. Jabbarifar, M. Dagenais. Intrusion response systems: survey and taxonomy. Int J Computer Science Network Security (IJCSNS), Vol. 12, pp. 1-14. 2012.

[Shameli-Sendi13] A. Shameli-Sendi, J. Desfossez, M. Dagenais, M. Jabbarifar. A Retroactive-Burst Framework for Automated Intrusion Response System. Journal of Computer Networks and Communications, 2013.

[Shannon48] C. E. Shannon. A Mathematical Theory of Communication. Reprinted with corrections from The Bell System Technical Journal, Vol.27, pp. 379-423, 1948.

[SHOE] S. Luke, J. Heflin. SHOE 1.01. Proposed Specification, 28 Abril 2000, [http://www.cs.umd.edu/projects/plus/SHOE/spec.html].

[Sirin07] E. Sirin, B. Parsia, B. Cuenca Grau, A. Kalyanpur, Y. Katz. Pellet: A practical OWL-DL reasoner. Web Semantics: Science, Services and Agents on the World Wide Web, Vol. 5 (2), pp. 51-53, 2007.

http://www.w3.org/Submission/SWRL-FOL/

http://clarkparsia.com/pellet

http://protege.stanford.edu/

http://www.w3.org/TR/rdf-mt/

http://www.ruleml.org/

http://www.cs.umd.edu/projects/plus/SHOE/spec.html


328

[Souag12] A. Souag, C. Salinesi, I. Comyn-Wattiau. Ontologies for Security Requirements: A Literature Survey and Classification. CAiSE 2012 Workshops, LNBIP 112, pp. 61–69, 2012.

[Spitzner05] L. Spitzner. Know your enemy:Honeynets. Honeynet Project. 2005.

[Staab01] S. Staab, R. Studer, H. P. Schnurr, Y. Sure. Knowledge Processes and Ontologies. IEEE Intelligent Systems, Vol. 16 (1), pp. 26-34. 2001.

[Stakhanova07a] N. Stakhanova, S. Basu, J. Wong. A Cost-sensitive model for preemptive intrusion response systems. Proceedings of the 21

st International

Conference on Advanced Networking and Applications. AINA’ 07. IEEE Computer Society, Washington, DC, USA. pp. 428-435, 2007.

[Stakhanova07b] N. Stakhanova, S. Basu, J. Wong. A taxonomy of intrusion response systems. International Journal of Information and Computer Security, Vol 1, pp. 169-184. 2007.

[Strasburg09] C. Strasburg, N. Stakhanova, S. Basu, J. S. Wong. A Framework for Cost Sensitive Assessment of Intrusion Response Selection. Proceedings of IEEE Computer Software and Applications Conference. 2009.

[Studer98] R. Studer, V. R. Benjamins, D. Fensel. Knowledge Engineering: Principles and Methods. Data & Knowledge Engineering. Vol. 25, pp. 161- 197. 1998.

[Sugumaran02] V. Sugumaran, V. C. Storey. Ontologies for conceptual modeling: their creation, use, and management. In Data & Knowledge Engineering, Vol. 42 (3), pp. 251-271. 2002.

[Symantec13] Symantec Corporation. Internet Security Threat Report. 2012 Trends, Volume 18. 2013.

T

[Tanachaiwiwat02] S. Tanachaiwiwat, K. Hwang, Y. Chen. Adaptive Intrusion Response to Minimize Risk over Multiple Network Attacks. ACM Trans on Information and System Security, Vol. 19. 2002.

[Tonti03] G. Tonti, J. M. Bradshaw, R. Jeffers, R. Montanari, N. Suri, A. Uszok. Semantic Web Languages for Policy Representation and Reasoning: A Comparison of KAoS, Rei, and Ponder. Proc. 2nd Int. Semantic Web Conference, Sanibel Island, Florida, USA, LNCS 2870 pp. 419-437. 2003.

[Toth02] T. Toth, C. Kruegel. Evaluating the Impact of Automated Intrusion Response Mechanism. Proceedings of the 18

th Annual Computer Security

Applications Conference, 2002.

[Tsarkov06] D. Tsarkov, I. Horrocks. FaCT++ Description Logic Reasoner: System Description. Proc. of the International Joint Conference on Automated Reasoning (IJCAR 2006). LNCS Vol. 4130, pp. 292-297. 2006.

[Tsoumas06] B. Tsoumas, D, Gritzalis. Towards an ontology-based security management. Proceedings of the 20

th International Conference on Advanced

Information Networking and Applications (AINA), pp. 985–992. 2006.

U

[UAH] Medidas de Impacto. [https://portal.uah.es/portal/page/portal/GP_EPD/PG-MA-ASIG/PG-ASIG-32853/TAB42351/Tema%2015.Medidas%20de%20impacto.pdf]

[Undercoffer03] J. Undercoffer, A. Joshi, J. Pinkston. Modeling Computer Attacks: An Ontology for Intrusion Detection. LNCS RAID 2003, Vol. 2820, pp. 113–135. Springer, Heidelberg. 2003.

[Undercoffer04] J.L. Undercoffer, A. Joshi, T. Finin, J. Pinkston. A target-centric ontology for intrusion detection. In: The 18

th International Joint Conference on Artificial

Intelligence, 2003.

https://portal.uah.es/portal/page/portal/GP_EPD/PG-MA-ASIG/PG-ASIG-32853/TAB42351/Tema%2015.Medidas%20de%20impacto.pdf



Referencias

329

[Uschold95] M. Uschold, M. King. Towards a Methodology for Building Ontologies. Proceedings of the Workshop on Basic Ontological Issues in Knowledge Sharing held in conjunction with IJCAI. 1995.

[Uschold96a] M. Uschold, M. Grüninger. Ontologies: Principles, Methods and Applications. Knowledge Engineering Review, Vol. 11 (2), pp. 93-155. 1996.

[Uschold96b] M. Uschold. Building Ontologies: Towards a Unified Methodology. Proceedings of 16

th Annual Conference of the British Computer Society

Specialist Group on Expert Systems. 1996.

V

[Villagrá09] V. A. Villagrá Gónzalez. Seguridad en redes de telecomunicación. Ed. Fundación Rogelio Segovia para el Desarrollo de las Telecomunicaciones. 2009.

[Vorobiev06] A. Vorobiev, J. Han. Security Attack Ontology for Web Services. Proceedings of the Second International Conference on Semantics, Knowledge and Grid (SKG’06), IEEE. 2006.

W

[Wang95] P. Wang. Non-Axiomatic Reasoning System – Exploring the Essence of Intelligence. PhD. Thesis, Department of Computer Science of Indiana University. 1995.

[Wang04] H. Wang, P. Liu, L. Li. Evaluating the Impact of Intrusion Detection Deficiencies on the Cost-Effectiveness of Attack Recovery. Information Security. Lecture Notes in Computer Science. Vol. 3225, pp. 146-157. 2004.

[Wang06] Z. Q. Wang, Q. Zhao, H. Q. Wang, L. J. Yu. MAIRF: An Approach Mobile Agents based Intrusion Response System. In Proceedings of the 1

st IEEE

Conference on Industrial Electronics and Applications, pp. 1–4. 2006.

[Wang-H06] H. Wang, G. Wang, Y. Lan, K. Wang, D. Liu. A New Automatic Intrusion Response Taxonomy and Its Application. LNCS in Advanced Web and Network Technologies and Applications, Vol. 3842, pp. 999-1003. 2006.

[White96] G. B. White, E. Fisch, U. Pooch. Cooperating security managers: A peer-based intrusion detection system. IEEE Network, Vol. 10 (1), pp. 20-23. 1996

[Wu07] Y.-S. Wu, B. Foo, Y.-C. Mao, S. Bagchi, E. Spafford. Automated adaptive intrusion containment in systems of interacting services. Computer Networks, Vol. 51 (5), pp. 1334-1360. 2007.

Y

[Yan09] R. Yan, Q. Zheng. Using Renyi cross entropy to analyze traffic matrix and detect DDoS attacks. Information Technology Journal, Vol. 8, pp. 1180-1188. 2009.

Z

[Zhang07] Z. Zhang, X. Lin, P-H. Ho. Measuring intrusion impacts for rational response: a state-based approach. In Second International Conference on Communications and Networking, pp. 317–321. China. 2007.

Abreviaturas y acrónimos

331


A

AAIRS Adaptive Agent-based Intrusion Response System

ADEPTS Adaptive Intrusion Tolerant Systems

AIDS Application-based Intrusion Detection System

AIRS Automated Intrusion Response System

C

CSM Cooperating Security Managers

CVE Common Vulnerabilities and Exposures

D

DAML DARPA Agent Markup Language

DAML-L DAML Logic

DAML+OIL DARPA Agent Markup Language + Ontology Inference Layer

DES Data Encryption Standard

DL Description Logic

DDoS Distributed Denial of Service

E

EMERALD Event Monitoring Enabling Responses to Anomalous Live Disturbances

F

FaCT Fast Classification of Terminologies

FAIR Flexible Automated Intelligent Responder


332

FLIPS Feedback Learning Intrusion Prevention System

F-Logic Frame Logic

FOL First Order Logic

H

HIDS Host-based Intrusion Detection System

HIPS Hosb-based Intrusion Prevention System

HTML Hyper-TextMarkup Language

HTTP Hyper-Text Transfer Protocol

I

IDAM&IRS Intrusion Detection Alert Management and Intrusion Response System

IDMEF Intrusion Detection Message Exchange Format

IDS Intrusion Detection System

IPS Intrusion Prevention System

IPSEC Internet Protocol Security

IRS Intrusion Response System

K

KAoS Knowledge-able Agent-oriented System

KIF Knowledge Interchange Format

KPO KAoS Policy Ontology

M

MAGERIT Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información

MAIRF Mobile Agents-based Intrusion Response Frame

M&M Merge andMap

N

NAT Network Address Traslation

NBA Network Behavior Analysis

NIDS Network-based Intrusion Detection System


333

NIPS Network-based Intrusion Prevention System

NNIDS Network-Node Intrusion Detection System

O

OCML Operational Conceptual Modeling Language

OIL Ontology Inference Layer / Ontology Interchange Language

OKBC Open Knowledge Base Connectivity

OrBAC Organization Based Access Control

OSI Open System Interconnection

OSVDB Open Sourced Vulnerability DataBase

OWL Ontology Web Language

OWL-S OWL for Services

P

POMDP Partially Observable Markov Decision Process

R

RACER Renamed ABox and Concept Expression Reasoner

RDF Resource Description Framework

RDFS RDF Schema

RFC Request For Comments

Ru1eML Rule Markup Language

S

SANCP Security Analyst Network Connection Profiler

SARA Survivable Autonomic Response Architecture

SHOE Simple HTML Ontology Extensions

SWRL Semantic Web Rule Language

SWSL Semantic Web Services Language

T

TCP Transmission Control Protocol


334

U

UML Unified Modeling Language

URI Uniform Resource Identifier

URL Uniform Resource Locator

V

VPN Virtual Private Network

W

WIPS Wireless Intrusion Prevention System

WSWL Web Service Modeling Language

W3C World Wide Web Consortium

X

XML eXtensible Mark-up Language

XSD XML Schema Data types

CONTRIBUCIÓN A LA AUTOMATIZACIÓN DE …oa.upm.es/21885/1/VERONICA_MATEOS_LANCHAS.pdf · momentos...

Documents

Transcript of CONTRIBUCIÓN A LA AUTOMATIZACIÓN DE …oa.upm.es/21885/1/VERONICA_MATEOS_LANCHAS.pdf · momentos...