ES2577143T3 - Método y sistema para detectar software malintencionado - Google Patents

Método y sistema para detectar software malintencionado Download PDF

Info

Publication number
ES2577143T3
ES2577143T3 ES11805856.9T ES11805856T ES2577143T3 ES 2577143 T3 ES2577143 T3 ES 2577143T3 ES 11805856 T ES11805856 T ES 11805856T ES 2577143 T3 ES2577143 T3 ES 2577143T3
Authority
ES
Spain
Prior art keywords
flows
detection
network
module
traffic
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES11805856.9T
Other languages
English (en)
Inventor
Francisco Romero Bueno
Antonio Manuel Amaya Calvo
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonica SA
Original Assignee
Telefonica SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonica SA filed Critical Telefonica SA
Application granted granted Critical
Publication of ES2577143T3 publication Critical patent/ES2577143T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/145—Countermeasures against malicious traffic the attack involving the propagation of malware through the network, e.g. viruses, trojans or worms

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Metodo para detectar software malintencionado, realizandose dicha deteccion en un sistema de deteccion de anomalias, o ADS, analizando el comportamiento de una red y buscando desviaciones con respecto a una normalidad, indicando dicha normalidad el comportamiento comun de usuarios de dicha red y definiendose antes de dicha deteccion, comprendiendo dicho metodo: - construir una pluralidad de modelos de deteccion para cada una de una pluralidad de diferentes entidades de dicha red, cada uno de dicha pluralidad de modelos de deteccion adaptado a dichas diferentes entidades de dicha red y a diferentes algoritmos, implementando dichos diferentes algoritmos diferentes estrategias de deteccion y representando dicha pluralidad de modelos de deteccion dicha normalidad, y - representando dicha pluralidad de modelos de deteccion en una matriz bidimensional, correspondiendo una dimension de dicha matriz a un numero de dichas diferentes entidades de dicha red y correspondiendo la otra dimension de dicha matriz a un numero de dichos diferentes algoritmos empleados.

Description

5
10
15
20
25
30
35
40
45
50
55
60
Metodo y sistema para detectar software malintencionado DESCRIPCION
Campo de la tecnica
La presente invencion se refiere, en general, en un primer aspecto, a un metodo para detectar software malintencionado, realizandose dicha deteccion en un sistema de deteccion de anomalfas, o ADS, analizando el comportamiento de una red y buscando desviaciones con respecto a una normalidad, indicando dicha normalidad el comportamiento comun de usuarios de dicha red y definiendose antes de dicha deteccion, y mas particularmente a un metodo que comprende construir una pluralidad de modelos de deteccion, estando adaptado cada uno de dicha pluralidad de modelos de deteccion a diferentes entidades de dicha red y a diferentes algoritmos, implementando dichos diferentes algoritmos diferentes estrategias de deteccion y representando dicha pluralidad de modelos de deteccion dicha normalidad.
Un segundo aspecto de la invencion se refiere a un sistema dispuesto para implementar el metodo del primer aspecto.
Estado de la tecnica anterior
La deteccion de software malintencionado (malware) puede clasificarse de muchas maneras. Una de ellas es la categorizacion clasica que distingue entre la deteccion basada en host y basada en red. El primer tipo intenta encontrar evidencias de la existencia de virus, troyanos, etc. por medio de procesos, memoria ffsica y varios otros analisis en host, mientras que el segundo se centra en las comunicaciones realizadas por tales virus o troyanos.
Surgieron varias estrategias en los comienzos de la deteccion basada en red. La mas basica era bloquear determinadas comunicaciones que atraviesan un nodo de red especial, un cortafuego. Esta solucion fue util hasta que el malware, con el fin de ocultarse, empezo a usar protocolos usados ampliamente tales como HTTP, SMTP que no pueden bloquearse sin detener el negocio de los ISP y operadores.
Entonces, era obvio que no era suficiente analizar unos pocos campos de los paquetes de TCP/IP (protocolo, puertos de origen y destino y direcciones IP), y era necesario extender el proceso de monitorizacion a la cabecera de TCP/IP completa e incluso la carga util de los paquetes. Es asf como nacen los sistemas de deteccion de intrusion de red (NIDS o IDS) [15]. Los IDS se basan en firmas de trafico, es decir, cadenas especiales que, cuando aparecen dentro de los paquetes de red, indican la presencia de un malware espedfico. Los IDS conocidos ampliamente son Snort [1] y Bro [2].
Aunque actualmente los IDS continuan desempenando un papel importante en los procesos de monitorizacion de todos los operadores alrededor del mundo, puesto que tratan un porcentaje importante de deteccion de malware, los investigadores encontraron que algun malware permaneda indetectable a los cortafuegos e IDS. Estos virus, gusanos, etc. indetectables usaban tanto protocolos populares como contenido normal a priori dentro de la carga util de paquetes. Algunos ejemplos son: spammers [3], bots orientados a la denegacion de servicio (DoS) [4] o scanners [5]. Entonces, se observo que la unica manera para detectar estas amenazas era analizar el comportamiento de la red con el fin de encontrar desviaciones con respecto a la normalidad, es decir, anomalfas. La normalidad se define a traves de una representacion matematica de la realidad comun, es decir, un modelo, que se construye en una etapa previa a la deteccion. Los sistemas de deteccion de anomalfas de red (NADS) [14] o simplemente sistemas de deteccion de anomalfas (ADS) tal como Proventia [6] demostraron rapidamente ser utiles para cubrir la laguna mencionada en el campo de monitorizacion. Y tambien en muchos otros escenarios, tales como deteccion de malware de dfa cero (nuevo malware existente para el que los IDS no tienen una firma valida) o trafico cifrado (las firmas no son importantes cuando no puede verse la carga util).
La deteccion de anomalfas es todavfa un area de investigacion interesante que puede dar bastantes soluciones para los administradores de seguridad. Estan apareciendo algoritmos innovadores de inteligencia artificial (AI), y el objetivo del modelado, que algunas veces es mas importante que el propio algoritmo de deteccion, vana entre la granularidad mas general, la totalidad de la red, hasta la minima, el usuario final individual.
Ejemplos de sistemas de deteccion de anomalfas pueden encontrarse en los documentos US2007/289013 y US8015133.
Pueden distinguirse dos tipos de problemas cuando se habla acerca de los ADS existentes, los relacionados con la eficacia y los relacionados con la eficiencia.
Los problemas de eficacia son evidentes en el dfa a dfa de todas las comparuas. Sus sistemas ya implementados no lo detectan todo, y las cosas que deben detectar no se encuentran apropiadamente debido a estrategias y
5
10
15
20
25
30
35
40
45
50
55
60
mecanismos obsoletos.
- Modelado de comportamiento basado en red
Los modelos con respecto al comportamiento de redes monitorizadas siempre se basan en la agregacion, contando el numero de paquetes/flujos/bytes por unidad de tiempo y definiendo por tanto una referencia. Aunque es verdad que este enfoque es suficiente para afrontar amenazas importantes tales como ataques DoS [4], en los que se genera una gran cantidad de datos, no tiene nada que hacer con ataques mas discretos y sofisticados basados en variaciones muy bajas de determinadas caractensticas de trafico que solo pueden apreciarse al nivel de entidad individual.
- Algoritmos de deteccion rudimentarios
Las reglas de condicion-consecuencia y volumenes/umbrales son casi todas las tecnologfas implementadas en la mayona de los NADS exitosos. Se trata de algoritmos muy basicos diftciles de mantener (deben considerarse nuevas condiciones cuando una amenaza evoluciona), mostrando muy baja flexibilidad (un umbral de 1000000 bytes superandose cuando se alcanzan 1000001 bytes) y una pobre auto-adaptacion.
La mayona de los problemas relacionados con la eficiencia con respecto a las soluciones existentes son debido a la falta de un marco comun para fines de monitorizacion. Cada solucion es propietaria y esta muy cerrada a terceras partes, lo que hace que las organizaciones instalen una nueva batena de soluciones cada vez que surge una nueva amenaza.
- Nivel de integracion nula entre proveedores
Excepto SIEM [9], una clase especial de sistemas no encargados de monitorizacion de red directa, pero encargados de la agregacion y correlacion de eventos de las diferentes fuentes, no se permite la integracion entre sistemas de monitorizacion actuales (incluyendo los ADS), y no solo sistemas de monitorizacion: herramientas de husmeado (sniffing), aplicaciones de registro, etc. Por ejemplo, es muy comun que los IDS/IPS/ADS husmeen ellos mismos el trafico de red, mientras que muchos sistemas de husmeado realizan la misma tarea.
- Bajo nivel de personalizacion/extension
Uno de los principales problemas que tienen en particular los sistemas de monitorizacion y ADS con respecto a su arquitectura es la falta de flexibilidad. Las soluciones de deteccion de anomaftas en investigacion y comerciales actuales estan muy cerradas y son propietarias, lo que hace casi imposible cualquier clase de personalizacion/extension. Este bajo nivel de personalizacion puede parecer normal en cualquier otra clase de sistema de software, pero no en el campo de la monitorizacion, en el que los operadores de seguridad necesitan afrontar la evolucion continua del malware por medio de nuevos algoritmos, estrategias, fuentes de datos, etc.
- Multiples puntos de monitorizacion
Ademas, si una organizacion espera usar varios NADS (porque cada uno de estos tiene como objetivo una amenaza diferente) entonces cada NADS individual requerira un punto de monitorizacion exclusivo desde el que obtener el trafico sin procesar. Esto puede parecer un problema insignificante si proporcionar los puntos de monitorizacion no fuera costoso. Por un lado, las soluciones de derivacion ffsica deben cortar el cable durante unos pocos segundos, pero suficiente para detener aplicaciones crfticas, y la division de la potencia optica debe realizarse muy cuidadosamente con el fin de permitir que los nodos de extremo continuen negociando el enlace. Por otro lado, las derivaciones logicas tales como la duplicacion de puertos consumen una alta cantidad de capacidades de procesamiento en los nodos de red; adicionalmente, cada aplicacion de monitorizacion necesita un puerto exclusivo en el nodo.
- Aplicaciones monolfticas
Finalmente, las soluciones existentes estan disenadas para ejecutarse en un unico equipo, evitando una caractenstica de distribucion de procesamiento deseable. Las aplicaciones monolfticas habitualmente requieren grandes cantidades de recursos tales como CPU, memoria RAM y disco para afrontar redes de alta velocidad.
Descripcion de la invencion
Es necesario ofrecer una alternativa al estado de la tecnica que cubra las lagunas encontradas en la misma, particularmente con relacion a la falta de propuestas que en realidad permitan detectar todo el software malintencionado posible e implantar un marco comun con fines de monitorizacion de manera que las organizaciones no necesiten instalar una nueva batena de soluciones cada vez que surge una nueva amenaza.
5
10
15
20
25
30
35
40
45
50
55
60
Para ello, la presente invencion proporciona, en un primer aspecto, un metodo para detectar software malintencionado, realizandose dicha deteccion en un sistema de deteccion de anomaKas, o ADS, analizando el comportamiento de una red y buscando desviaciones con respecto a una normalidad, indicando dicha normalidad el comportamiento comun de los usuarios de dicha red y definiendose antes de dicha deteccion.
A diferencia de las propuestas conocidas, el metodo de la invencion, de una manera caractenstica, comprende ademas construir una pluralidad de modelos de deteccion, estando adaptado cada uno de dicha pluralidad de modelos de deteccion a diferentes entidades de dicha red y a diferentes algoritmos, implementando dichos diferentes algoritmos diferentes estrategias de deteccion y representando dicha pluralidad de modelos de deteccion dicha normalidad.
Otras realizaciones del metodo del primer aspecto de la invencion se describen segun las reivindicaciones adjuntas 1 a 15, y en una seccion posterior relativa a la descripcion detallada de varias realizaciones.
Un segundo aspecto de la presente invencion se refiere a un sistema para detectar software malintencionado, realizandose dicha deteccion en un sistema de deteccion de anomalfas, o ADS, analizando el comportamiento de una red y buscando desviaciones con respecto a una normalidad, indicando dicha normalidad la realidad comun de dicha red y definiendose antes de dicha deteccion.
En el sistema del segundo aspecto de la invencion, a diferencia de los sistemas conocidos mencionados en la seccion de estado de la tecnica anterior, y de una manera caractenstica, este comprende un modulo de sonda para la monitorizacion de trafico de dicha red conectada a un modulo controlador encargado de realizar dicha deteccion, en el que dicho modulo controlador esta dotado de una pluralidad de modelos de deteccion construidos por medio de un modulo compilador, estando adaptado cada uno de dicha pluralidad de modelos de deteccion a diferentes entidades de dicha red y a diferentes algoritmos, implementando dichos diferentes algoritmos diferentes estrategias de deteccion y representando dicha pluralidad de modelos de deteccion dicha normalidad.
El sistema del segundo aspecto de la invencion esta adaptado para implementar el metodo del primer aspecto.
Otras realizaciones del sistema del segundo aspecto de la invencion se describen segun las reivindicaciones adjuntas 16 a 22, y en una seccion posterior relativa a la descripcion detallada de varias realizaciones.
Breve descripcion de los dibujos
Las anteriores y otras ventajas y caractensticas se entenderan de manera mas completa a partir de la siguiente descripcion detallada de realizaciones, con referencia a los dibujos adjuntos, que deben considerarse de una manera ilustrativa y no limitativa, en los que:
La figura 1 muestra los componentes y la interaccion entre estos, definiendo dichos componentes e interacciones una posible arquitectura del sistema propuesto, segun una realizacion de la presente invencion.
La figura 2 muestra el modulo de sonda, segun una realizacion de la presente invencion.
La figura 3 muestra el modulo de monitorizacion y la biblioteca de detectores, segun una realizacion de la presente invencion.
La figura 4 muestra el modulo compilador y la biblioteca de compiladores, segun una realizacion de la presente invencion.
La figura 5 muestra el modulo registrador y la biblioteca de registradores, segun una realizacion de la presente invencion.
La figura 6 muestra un posible diagrama de secuencia entre el modulo de monitorizacion y el modulo compilador, en el que el modulo de monitorizacion y el modulo compilador hacen uso de la interfaz compilador-monitorizador, segun una realizacion de la presente invencion.
La figura 7 muestra el diagrama de flujo para el detector de flujo de dominios basado en DNS, segun una realizacion de la presente invencion.
La figura 8 muestra una representacion grafica de agrupamientos cuando usan el agrupamiento de trafico sospechoso, en el que se representan los vectores normales mediante “0”, las anomalfas mediante “x” y los agrupamientos mediante drculos, segun una realizacion de la presente invencion.
La figura 9 muestra una representacion grafica de 2 caractensticas del algoritmo rapido de pertenencia al agrupamiento, segun una realizacion de la presente invencion.
La figura 10 muestra un ejemplo de implantacion ffsica distribuida de los componentes del sistema, segun una realizacion de la presente invencion.
Descripcion detallada de varias realizaciones
La invencion propuesta se refiere a un equipo de hardware y software (o conjunto de equipos si sus componentes se
5
10
15
20
25
30
35
40
45
50
55
60
distribuyen finalmente) que actua como plataforma que permite mucha mas eficacia y eficiencia en el campo de deteccion de anomaffas de red.
La ganancia de eficacia se obtiene gracias a la combinacion de dos enfoques innovadores:
- El uso de modelos de deteccion en un modo por usuario. En lugar de crear un unico modelo para la totalidad de la red, cada entidad dentro de esta se modela.
- El uso de modelos de deteccion en un modo por algoritmo. En lugar de tener una estrategia de deteccion unica, multiples ejemplos de detector se ejecutan en paralelo.
Los dos enfoques anteriores pueden verse como una matriz de modelo en la que se consideran N entidades (Ei...En) y M algoritmos (Ai...Am), obteniendo NxM modelos diferentes (Mii...Mnm).
El modelo y sus respectivos detectores pueden ser o bien ADS del estado de la tecnica (pueden considerarse matrices sencillas de 1x1, puesto que se usan una unica entidad modelada y solo un algoritmo) o bien algoritmos de deteccion innovadores, como los dos explicados mas adelante basados en inteligencia artificial.
Ademas, otras caractensticas de arquitectura disponibles en la invencion propuesta permiten mucha mas eficiencia en terminos de:
- La distribucion del esfuerzo de procesamiento entre varios nodos ffsicos.
- Facil integracion de software relacionado con monitorizacion existente, tal como procesadores de trafico de red, mediante el diseno de arquitectura.
- Un unico punto de monitorizacion en la red.
• Componentes de la arquitectura
Los componentes del sistema y la interaccion entre ellos se muestran en la figura 1. Los recuadros gris claro representan componentes SoA, el gris oscuro representa la SoA modificada y los recuadros blancos, que incluyen las bibliotecas de detectores y compiladores, son componentes innovadores dentro de la arquitectura. A continuacion, se detallaran los componentes del sistema:
-SONDA
Es el unico punto de monitorizacion que proporciona rastros de trafico de red al resto de los componentes del sistema.
La deteccion de anomaffas realizada por las aplicaciones de ADS de multiples algoritmos se basa en el trafico de red, espedficamente buscando desviaciones respecto de la normalidad en los paquetes de TCP/IP que atraviesan la red monitorizada. Para realizar esto es necesario (1) capturar los paquetes de los medios ffsicos y (2) preparar los paquetes capturados para los algoritmos de deteccion, que habitualmente funcionan con flujos agregados (un flujo se define, al menos, por el protocolo de transporte, TCP o UDP, las direcciones IP de origen y destino y los puertos de origen y destino). La SONDA es el componente encargado de la captura de paquetes y del procesamiento en flujos, tal como se muestra en la figura 2.
Las SONDAS tambien pueden ser heredadas, para lo que es necesario simplemente implantar un adaptador con el fin de conseguir la interfaz entre las SONDAS y el MONITORIZADOR.
- MONITORIZADOR y BIBLIOTECA DE DETECTORES
El MONITORIZADOR es el controlador principal del sistema, recibe rastros de red desde la SONDA y es responsable (1) del almacenamiento de rastros si funciona en modo de entrenamiento y (2) la invocacion de DETECTORES, pasandoles una copia de los rastros, si funciona en modo de deteccion. La BIBLIOTECA DE DETECTORES es una recopilacion de DETECTORES que implementan cada uno un algoritmo de NADS.
Una vez que el trafico de red se agrega en flujos esta listo para analizarse usando una amplia diversidad de algoritmos de deteccion de anomaffas. Sin embargo, debe recordarse que el trafico puede o bien almacenarse (con el fin de construir los modelos normales) o bien usarse por los algoritmos de deteccion. Asf, alguna entidad debe (1) conocer si el sistema esta funcionando actualmente en modo de deteccion o de almacenamiento y (2) reenviar el trafico al componente de almacenamiento o a las entidades de deteccion dependiendo del modo de funcionamiento. La invencion propuesta implementa esto por medio del MONITORIZADOR.
Con respecto a la deteccion, puesto que la carpeta de algoritmos no puede estar completa (imposibilidad de implementar todos los algoritmos existentes, algoritmos que no se han descubierto todavfa) sena muy conveniente
5
10
15
20
25
30
35
40
45
50
55
60
tener un mecanismo para ajustar el sistema de deteccion (anadir, eliminar o modificar algoritmos). La arquitectura del sistema proporciona un mecanismo acoplable de este tipo por medio de la BIBLIOTECA DE DETECTORES. La BIBLIOTECA DE DETECTORES es una recopilacion discreta de algoritmos de deteccion, la recopilacion actual, que tiene una interfaz definida con el MONITORIZADOR. Un nuevo algoritmo de deteccion, anteriormente un DETECTOR, puede incluirse en la recopilacion si tal DETECTOR respeta la interfaz definida con el MONITORIZADOR. Todos los DETECTORES dentro de la biblioteca no tienen que usarse siempre, y si existe la posibilidad de enumerar el subconjunto deseado de algoritmos para el MONITORIZADOR. Esto puede realizarse, por ejemplo, por medio de archivos de configuracion.
El MONITORIZADOR entonces reenvfa simplemente tal como se dijo previamente, a traves de la interfaz definida, los flujos recibidos a todos los DETECTORES dentro de la BIBLIOTECA DE DETECTORES. Finalmente, los DETECTORES comparan los flujos entrantes con los modelos de comportamiento normal almacenados.
La BIBLIOTECA DE DETECTORES esta concebida originalmente, precisamente, como una biblioteca que se incorpora de manera nativa al software de MONITORIZADOR (bibliotecas estaticas o dinamicas en C/C++, archivos JAR en Java, etc.). El fin de esta decision es mejorar la entrega de flujos a los DETECTORES, pero el desarrollador puede implementar la biblioteca como un conjunto de procesos que se ejecutan independientemente del MONITORIZADOR, por ejemplo; incluso, los DETECTORES pueden colocarse en dispositivos ffsicos separados.
- COMPILADOR y BIBLIOTECA DE COMPILADORES
El COMPILADOR es responsable de la invocacion de COMPILADORES cuando el sistema funciona en modo de entrenamiento. Se ejecuta una vez que la fase de almacenamiento de rastros termina. La BIBLIOTECA DE COMPILADORES es una recopilacion de COMPILADORES que implementan cada uno un mecanismo de modelado de comportamiento.
El COMPILADOR es el modulo de la arquitectura de ADS de multiples algoritmos implicada en la generacion de modelos de comportamiento normal y, por tanto, es el componente central de la invencion propuesta. Tal como se conoce, los algoritmos de deteccion de anomalfas generalmente comparan el trafico observado con un modelo normal, buscando desviaciones entre uno y otro. Puesto que los algoritmos de deteccion pueden ser muy diferentes, entonces sus modelos de referencia tambien seran muy diferentes a pesar de que los datos usados para generarlos son los mismos (el trafico capturado y agregado). El COMPILADOR es responsable de generar esta generacion de modelos diferenciados a traves de la BIBLIOTECA DE COMPILADORES, que contiene un generador de modelos, anteriormente un COMPILADOR, por algoritmo de deteccion en el sistema. Los COMPILADORES dentro de la biblioteca pueden habilitarse o deshabilitarse.
Sin embargo, el COMPILADOR es un componente opcional puesto que algunos DETECTORES podnan no necesitar un modelo personalizado (un modelo por defecto se usa siempre independientemente del comportamiento espedfico de los usuarios); o los modelos pueden haberse generado por otros medios; o incluso el DETECTOR no necesita un modelo.
- REGISTRADOR y BIBLIOTECA DE REGISTRADORES
El REGISTRADOR recibe alertas desde el MONITORIZADOR e invoca a los REGISTRADORES. La BIBLIOTECA DE REGISTRADORES es una recopilacion de REGISTRADORES implementando cada uno una facilidad de registro.
Finalmente, las alarmas colaborativas generadas pueden registrarse, tarea para la cual el componente de REGISTRADOR se introduce en la arquitectura (una vez mas, una carpeta de registro exhaustiva es inviable, por lo que se usa una BIBLIOTECA DE REGISTRADORES para anadir o eliminar dinamicamente facilidades de registro: archivos, bases de datos, syslog, etc.). Los REGISTRADORES existentes pueden habilitarse o deshabilitarse en la configuracion.
• Interfaces de arquitectura
A continuacion, se describiran las interfaces entre los componentes del sistema:
- SONDA - MONITORIZADOR
Esta interfaz define como los flujos generados en el componente SONDA se envfan al componente MONITORIZADOR. Las comunicaciones, basicamente, pueden implementar dos esquemas diferentes dependiendo de manera proactiva de la SONDA:
1. Intercambio proactivo: la SONDA envfa los flujos en el momento en que estan listos para compartirse.
5
10
15
20
25
30
35
40
45
50
55
60
2. Intercambio a peticion: los flujos se env^an cuando el MONITORIZADOR los solicita.
El uso de uno u otro esquema tiene un importante impacto en el rendimiento en tiempo real. Por un lado, es obvio que el intercambio a peticion no es compatible con el tiempo real puesto que el reenvfo de datos depende de la disponibilidad del MONITORIZADOR. Por otro lado, puede pensarse que el intercambio proactivo es siempre compatible con el tiempo real; pero esto puede no ser cierto si el componente MONITORIZADOR realiza de nuevo un almacenamiento en memoria intermedia de los datos recibidos proactivamente.
En cualquier caso, debe establecerse el formato de los flujos intercambiados con el fin de garantizar la correcta interaccion entre las SONDAS y el MONITORIZADOR. Si se usan fuentes de datos heredadas entonces debe implementarse un adaptador con el fin de garantizar su disponibilidad. Una lista no exhaustiva de campos que pueden intercambiarse entre las SONDAS y el MONITORIZADOR es la siguiente:
- Protocolo de capa 4 (TCP, UDP, etc.).
- Sellos de fecha y hora del primer y ultimo paquete.
- Direcciones IP de origen y destino en el flujo.
- Puertos de TCP o UDP de origen y destino en el flujo.
- Numero de paquetes enviados y recibidos.
- Numero de bytes enviados y recibidos.
- Estado de TCP o, al menos, banderas de TCP implicadas en el flujo.
- Determinados datos de cabecera de aplicacion, tales como DNS, HTTP, SMTP, SIP y otros.
- MONITORIZADOR - COMPILADOR
Como se indico en las secciones de MONITORIZADOR y COMPILADOR espedficas, la comunicacion entre estos dos componentes de la arquitectura de la invencion propuesta se realiza por medio de bases de datos. Dos son los motivos para esto:
1. La alta cantidad de flujos capturados no permite un almacenamiento en memoria intermedia sencillo.
2. La mayona de los algoritmos de deteccion de anomalfas necesitan amplias ventanas de tiempo para realizar sus modelos de comportamiento normal. Naturalmente, es posible una construccion de modelos en tiempo real en algunos algoritmos de deteccion de anomalfas, pero, puesto que esta tarea no es cntica, siempre se realizara en un modo no en tiempo real.
La base de datos implementada debe permitir al MONITORIZADOR almacenar los flujos construidos en el formato de intercambio acordado entre la SONDa y el MONITORIZADOR (vease seccion anterior). Estos flujos almacenados pueden consultarse por el COMPILADOR tambien, que generara los modelos y los almacenara en otra base de datos.
- MONITORIZADOR - REGISTRADOR
Las alarmas generadas por el MONITORIZADOR se envfan al componente REGISTRADOR en un formato espedfico, para el que los campos candidatos podnan ser los siguientes:
- Identificador del atacante.
- Identificador del host atacado.
- Protocolo implicado.
- Sello de fecha y hora para la alerta.
- Tipo de ataque/tipo de anomalfa.
- Identificador de DETECTOR.
- Informacion de realimentacion tal como datos originales que provocan que se establezca la alarma en el DETECTOR, lista de objetivos extendida (si no hay uno solo), etc.
• Detectores
El sistema preve el uso de algoritmos avanzados para mejorar la eficacia de los sistemas de deteccion de anomalfas. Estos algoritmos avanzados proceden del campo de inteligencia artificial, siendo las redes neuronales y los algoritmos de agrupamiento los candidatos principales para usarse.
Las redes neuronales y otros algoritmos de aprendizaje de maquina supervisados [10] han demostrado varias veces su potencia en problemas de clasificacion, debido a su capacidad para generalizar soluciones por medio de unos pocos ejemplos de entrenamiento; su adaptabilidad; y su baja tasa de falsos positivos.
Sin embargo, no siempre es posible usar algoritmos supervisados, especialmente cuando no hay un experto que
5
10
15
20
25
30
35
40
45
50
55
pueda etiquetar o clasificar previamente los ejemplos de entrenamiento. Cuando esto se produce, se necesitan los algoritmos no supervisados [11] tal como de agrupamiento. El agrupamiento es muy util en auto-generacion de clases de trafico, comportamientos, etc.
En este caso se detallan un par de DETECTORES que forman parte de la BIBLIOTECA DE DETECTORES. Estos DETECTORES son ejemplos de los algoritmos de deteccion avanzados contemplados para el ADS de multiples algoritmos propuesto. Otros algoritmos sencillos tales como monitorizacion de trafico volumetrico, recuentos absolutos de paquetes o flujos entre nodos, y la deteccion periodica de flujos no se describen puesto que no son algoritmos innovadores aunque pueden desarrollarse perfectamente sobre la invencion propuesta.
DETECTORES adicionales no documentados en el presente documento pueden anadirse al ADS de multiples algoritmos en forma de extensiones de la patente actual.
- Detector de flujo de dominios basado en DNS
Este DETECTOR intenta detectar actividades de flujo de dominios [12] en el trafico de DNS monitorizado, que puede indicar la presencia de un bot [7].
Los bots dentro de una botnet habitualmente implementan consultas de DNS con el fin de descubrir su servidor de mando y control (C&C); esto permite a los duenos de bots cambiar la ubicacion real (la direccion IP) del servidor sin reconfigurar sus bots. Mientras que los FQDN fijos son faciles de detectar y filtrar, los bots implementan la tecnica de flujo de dominios, que genera dinamicamente una alta cantidad de FQDN para el servidor C&C con el fin de sincronizarse con el dueno. Estos FQDN dinamicamente generados pueden basarse en el sello de fecha y hora actual, o pueden ser un conjunto generado de manera pseudoaleatoria, siendo solo una de las posibilidades la valida. En cualquier caso, esta tecnica genera muchas respuestas de NX_DOMAIN (y otras) cuando se consulta el servidor DNS. Este detector analiza estas respuestas anomalas.
Por tanto, se analizan las respuestas de DNS y se extrae un conjunto de caractensticas dentro de un intervalo de tiempo, siendo lo siguiente un ejemplo de conjunto de caractensticas:
- Numero de respuestas de NX_DOMAIN.
- Numero de respuestas de FORMAT_ERROR.
- Numero de respuestas de REFUSED.
- Numero de respuestas de SERVER_FAILURE.
- Numero de diferentes FQDN consultados.
- Numero de FQDN de una capa
- Numero de FQDN de dos capas.
- Numero de FQDN de tres capas o mas.
- Numero de dominios de nivel superior sospechosos (TLD).
- Numero de dominios de capa dos con longitud inferior a 6.
- Numero de dominios de capa dos con longitud superior a 5 e inferior a 21.
- Numero de dominios de capa dos con longitud superior a 20.
- Numero de dominios de capa dos con numero de vocales inferior al 0,3%
- Numero de dominios de capa dos con numero de d^gitos superior al 0,5%
Estas caractensticas componen un vector de caractensticas que se evalua usando una red neuronal. Esta red neuronal se entrena (supervisa) previamente usando ejemplos de vectores que contienen valores para todas las caractensticas anteriores y proporcionando un campo adicional, una etiqueta. Esta etiqueta proporcionara informacion con respecto a la conveniencia de establecer una alarma o no cuando se encuentre un vector parecido en el trafico.
El DETECTOR usa, por tanto, un modelo unico por defecto, construido previamente, la configuracion de red neuronal espedfica que resulta tras la fase de entrenamiento.
Se proporciono en la figura 7 un diagrama de flujo para ilustrar el DETECTOR propuesto, en el que se describen algunas variables en la siguiente tabla:
Nombre de variable
Descripcion
f
Flujo
sid
Identificador de abonado
m
Modelo para el identificador de abonado (actualmente uno por defecto)
td
^Esta el flujo actual relacionado con un dominio superior?
5
10
15
20
25
30
35
40
45
50
ts
Sello de fecha y hora para el flujo actual
tw
Sello de fecha y hora de inicio de la ventana de tiempo actual
tw'
tw actualizado
s
Tamano de la ventana de tiempo
ctw
^Esta el flujo actual en la ventana de tiempo actual?
a
Alerta
v
Vector de caractensticas que se obtiene del flujo actual
gv
Vector acumulado global con respecto a la ventana de tiempo actual
gv'
gv actualizado
• Agrupamiento de trafico sospechoso
Los fundamentos de este DETECTOR se basan en la construccion de un modelo personalizado con respecto a los valores de determinadas caractensticas dentro de un periodo de intervalo. A diferencia del DETECTOR anterior, no se usa ningun experto para entrenarlo, es decir, se va a utilizar un algoritmo no supervisado. Espedficamente, un algoritmo de agrupamiento de maximizacion de la esperanza (EM) [13] definira las clases de trafico en las que cada usuario esta comunmente implicado. Entonces, en una segunda etapa, se detectaran las anomalfas si aparece un patron de trafico diferente del normal. Graficamente, este proceso se muestra en la imagen simplificada de 2 caractensticas de la figura 8, en la que los drculos representan agrupamientos de datos, la “o” representa un vector normal y una “x” es una anomalfa.
Sin embargo, el punto clave no es el algoritmo sino las caractensticas de los vectores que alimentaran la implementacion de EM. Caractensticas tales como el numero de paquetes/bytes/flujos enviados y recibidos parecen ser candidatos validos, pero estas caractensticas no son estadfsticamente estables a lo largo del tiempo. Por el contrario, se necesitan caractensticas estables; son mejores aquellas relacionadas, precisamente, con comportamientos anormales. Este DETECTOR considera al menos las siguientes (recuentos con respecto a un intervalo de tiempo):
- Numero de flujos que tienen el destino ubicado en un pafs inusual.
- Numero de flujos que tienen el destino incluido en una lista negra.
- Numero de flujos que usan un protocolo inusual.
- Numero de flujos de TCP sospechosos (solo flujos SYN, flujos solo SYN+ACK, flujos solo FIN, flujos solo FIN+ACK).
- Numero de flujos de mas de 10 KB de longitud.
- Numero de flujos de mas de 50 KB de longitud.
- Numero de flujos muy pequenos (menos de la mitad de MTU).
- Numero de flujos no generados por la entidad modelada.
La mayona de las caractensticas anteriores deben tener valores diferentes de cero, pero muy proximos a cero, en el caso normal. Esto no es relevante puesto que un usuario puede acceder a uno o dos servidores legttimos ubicados en un pafs inusual, por ejemplo; lo importante es encontrar valores anormales.
Los pafses inusuales y protocolos inusuales se definen realizando una estadfstica previa con respecto a pafses a los que se accede mas y protocolos mas usados durante un determinado intervalo de tiempo.
El diagrama de flujo para el DETECTOR de agrupamiento de trafico sospechoso es el mismo que en el DETECTOR de flujo de dominios basado en DNS, pero siendo la funcion de evaluacion una diferente. En este caso la funcion de evaluacion verifica si el vector acumulado se correlaciona con algun agrupamiento dentro del modelo (es comportamiento normal) o no (es una anomalfa). En este sentido se propone un algoritmo rapido de pertenencia al agrupamiento.
Las funciones de pertenencia al agrupamiento pueden ser complejas, especialmente cuando se usan grandes vectores de caractensticas. En este caso se presenta una rapida funcion de evaluacion, basandose en una simplificacion de los agrupamientos obtenidos: para cada agrupamiento y para cada dimension o caractenstica se calculan sus lfmites, es decir, los valores mmimo y maximo que puede adoptar la caractenstica con respecto al agrupamiento actual. Entonces, la funcion de pertenencia al agrupamiento es tan sencilla como verificar si cada caractenstica dentro del vector evaluado esta dentro de los lfmites de la misma caractenstica del agrupamiento. La idea puede observarse facilmente en un espacio de 2 caractensticas, tal como se muestra en la figura 9.
■ Ventajas de la invencion
1. Ventajas de eficacia
5
10
15
20
25
30
35
40
45
50
55
60
- Modelado del comportamiento basandose en entidad y basandose en algoritmo
La invencion propuesta permite el modelado del comportamiento basandose en entidad y basandose en algoritmo, abordando estadfsticamente pocos y sofisticados ataques que no se detectanan basandose en red. Sin embargo, este ADS de multiples algoritmos permite tambien la definicion de modelos de comportamiento global.
- Algoritmos de deteccion avanzada
Los algoritmos detallados antes se basan en algoritmos de inteligencia artificial compleja y de aprendizaje de maquina que proporcionan mecanismos flexibles, de auto-adaptacion, de autoaprendizaje y de precision para detectar tanto anomalfas generales como comportamientos anomalos espedficos de trafico, tales como flujo de dominios.
2. Ventajas de eficiencia
- Un marco comun para el desarrollo de aplicaciones de monitorizacion
La arquitectura mostrada en este documento tiene como objetivo ser un modelo de referencia a la hora de implementar sistemas de deteccion colaborativa, espedficamente aplicaciones de deteccion de anomalfas colaborativas. Tal como puede verse en la seccion de estado de la tecnica anterior, muchos intentos para definir tal clase de aplicaciones han conducido a una confusion de conceptos que no ayuda a conocer si una arquitectura ha emergido de un algoritmo o viceversa, y lo peor, hace diffcil integrar tanto nuevos algoritmos como nuevos requisitos de arquitectura. El sistema propuesto da a los desarrolladores un marco comun para disenar nuevas aplicaciones de deteccion de anomalfas, pero tambien anade esas nuevas aplicaciones a las existentes en un modo aseptico. Esto es claramente una ventaja para los administradores de red (principalmente operadores de telecomunicaciones) que desean incluir en su portafolio de sistemas de deteccion una nueva estrategia o algoritmo de deteccion sin que interfiera con los existentes.
- Distribucion de procesamiento
Todos los componentes de esta arquitectura pueden distribuirse facilmente entre varios dispositivos ffsicos; el unico requisito es que el desarrollador de los NADS implemente las interfaces entre los modulos usando una de las muchas tecnologfas de comunicaciones tales como sockets, servicios web, RPC, RMI, etc. La figura 10 muestra un ejemplo de tal implantacion distribuida en de cuatro servidores diferentes.
La distribucion de procesamiento tambien ayuda en la escalabilidad del sistema desarrollado, puesto que la inclusion de un algoritmo de procesamiento intenso puede resolverse, por ejemplo, incluyendo un servidor especializado para ese algoritmo de deteccion e implementando una interfaz basada en TCP/IP con el MONITORIZADOR.
- Un solo punto de monitorizacion para una amplia diversidad de aplicaciones
El lector debe tener en cuenta que los puntos de monitorizacion estan limitados debido a las restricciones tecnicas (las derivaciones de fibra hacen mas debil la senal optica cuando se divide; la duplicacion de puertos en encaminadores o conmutadores consume bastantes recursos que pueden restarse del procesamiento de trafico; o directamente el negocio no puede detenerse cortando la lmea, al fin y al cabo, debe realizarse o bien una derivacion ffsica o bien una duplicacion logica). Tal como puede observarse, el ADS de multiples algoritmos solo necesita un unico punto de monitorizacion comun a todas las aplicaciones implantadas.
- Integracion de sondas heredadas
El componente SONDA no necesita desarrollarse desde cero. Pueden usarse muchos otros sistemas de generacion de flujo ampliamente conocidos tales como Netflow [8]. El unico requisito para realizar tal integracion es incluir una etapa de normalizacion.
Un experto en la tecnica puede introducir cambios y modificaciones en las realizaciones descritas sin apartarse del alcance de la invencion tal como se define en las reivindicaciones adjuntas.
Siglas
ADS Anomaly Detection System; sistema de deteccion de anomalfas
AI Artificial Intelligence; inteligencia artificial
CPU Central Processing Unit; unidad central de procesamiento
C&C Command and Control; mando y control
5
10
15
20
25
30
35
40
45
50
DNS Domain Name System; sistema de nombres de dominio
DoS Denial of Service; denegacion de servicio
EM Expectation-Maximization; maximizacion de la esperanza
FQDN Fully Qualified Domain Name; nombre de dominio completamente calificado
HTTP Hyper-Text Transfer Protocol; protocolo de transferencia de hipertexto
IP Internet Protocol; protocolo de Internet
IDS Intrusion Detection System; sistema de deteccion de intrusion
ISP Internet Service Provider; proveedor de servicio de Internet
KB Kilo Bytes; kilobytes
MTU Maximum Transfer Unit; unidad de transferencia maxima
NADS Network Anomaly Detection System; sistema de deteccion de anomalfas de red
NIDS Network Intrusion Detection System; sistema de deteccion de intrusion de red
RAM Random Access Memory; memoria de acceso aleatorio
SIEM Security Information and Events Management; gestion de eventos e informacion de seguridad
SMTP Simple Mail Transfer Protocol; protocolo simple de transferencia de correo
SOA Service Oriented Architecture; arquitectura orientada a servicio
TCP Transport Control Protocol; protocolo de control de transporte
TLD Top Layer Domain; dominio de capa superior
UDP User Datagram Protocol; protocolo de datagramas de usuario
Bibliograffa
[1] Snort IDS.
http://www.snort.org/
[2] Bro IDS.
http://bro-ids.org/
[3] “Spambot” en Wikipedia.
http://en.wikipedia.org/wiki/Spambot
[4] “Denial-of-service attack” en Wikipedia.
http://en.wikipedia.org/wiki/Denial-of-service_attack
[5] “Port scanner” en Wikipedia.
http://en.wikipedia.org/wiki/Port_scanner
[6] Proventia ADS por IBM.

http://www-935.ibm.com/services/uk/index.wss/offering/iss/y1026942
[7] “Botnets” en Wikipedia.
http://en.wikipedia.org/wiki/Botnets
[8] Cisco IOS NetFlow.
http://www.cisco.com/en/US/products/ps6601/products_ios_protocol_group_home.html
[9] “SEM” en Wikipedia.
http://en.wikipedia.org/wiki/Security_event_manager
[10] “Supervised learning” en Wikipedia.
http://en.wikipedia.org/wiki/Supervised_learning
[11] “Unsupervised learning” en Wikipedia.
http://en.wikipedia.org/wiki/Unsupervised_learning
[12] “Fast-flux” en Wikipedia.
http://en.wikipedia.org/wiki/Fast_flux
[13] “Expectation-maximization algorithm” en Wikipedia
http://en.wikipedia.org/wiki/Expectation- maximization_algorithm
[14] “Anomaly detection” en Wikipedia
http://en.wikipedia.org/wiki/Anomaly_detection
[15] “Intrusion detection system” en Wikipedia
http://en.wikipedia.org/wiki/Intrusion-detection_system

Claims (21)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    REIVINDICACIONES
    1. Metodo para detectar software malintencionado, realizandose dicha deteccion en un sistema de deteccion de anomaUas, o ADS, analizando el comportamiento de una red y buscando desviaciones con respecto a una normalidad, indicando dicha normalidad el comportamiento comun de usuarios de dicha red y definiendose antes de dicha deteccion, comprendiendo dicho metodo:
    - construir una pluralidad de modelos de deteccion para cada una de una pluralidad de diferentes entidades de dicha red, cada uno de dicha pluralidad de modelos de deteccion adaptado a dichas diferentes entidades de dicha red y a diferentes algoritmos, implementando dichos diferentes algoritmos diferentes estrategias de deteccion y representando dicha pluralidad de modelos de deteccion dicha normalidad, y
    - representando dicha pluralidad de modelos de deteccion en una matriz bidimensional, correspondiendo una dimension de dicha matriz a un numero de dichas diferentes entidades de dicha red y correspondiendo la otra dimension de dicha matriz a un numero de dichos diferentes algoritmos empleados.
  2. 2. Metodo segun la reivindicacion 1, que comprende monitorizar el trafico de dicha red, comprendiendo dicho trafico paquetes que atraviesan dicha red, y preparar dichos paquetes para dichos diferentes algoritmos, o para dichas diferentes estrategias de deteccion, agregando dichos paquetes en flujos.
  3. 3. Metodo segun la reivindicacion 2, que comprende almacenar dicho trafico con el fin de construir dicha pluralidad de modelos de deteccion cuando dicho ADS esta operando en modo de almacenamiento.
  4. 4. Metodo segun la reivindicacion 2 o 3, que comprende:
    - procesar dichos flujos segun al menos parte de dichos diferentes algoritmos cuando dicho ADS esta operando en modo de deteccion, definiendose dichos diferentes algoritmos en una biblioteca de detectores, permitiendo dicha biblioteca de detectores al menos anadir, eliminar o modificar algoritmos; y
    - comparar dichos flujos procesados con al menos parte de dicha pluralidad de modelos de deteccion.
  5. 5. Metodo segun la reivindicacion 4 cuando depende de la reivindicacion 3, que comprende construir dicha pluralidad de modelos de deteccion segun una biblioteca de compiladores que contiene un generador de modelos por algoritmo, definiendo cada generador de modelos un compilador que va a usarse con dicho trafico almacenado cuando se opera en dicho modo de almacenamiento.
  6. 6. Metodo segun la reivindicacion 5, que comprende tener un generador de modelos por defecto contenido en dicha biblioteca de compiladores para construir al menos parte de dicha pluralidad de modelos de deteccion.
  7. 7. Metodo segun la reivindicacion 4, 5 o 6, que comprende registrar alarmas generadas cuando se detecta dicho software malintencionado segun dicha comparacion entre dichos flujos procesados con dicha al menos parte de dichos diferentes algoritmos y dicha al menos parte de dicha pluralidad de modelos de deteccion.
  8. 8. Metodo segun la reivindicacion 7, en el que dichas alarmas contienen al menos parte de la informacion de la siguiente lista no cerrada: identificador del atacante, identificador del host atacado, protocolo implicado, sello de fecha y hora para la alerta, tipo de ataque o tipo de anomalfa, identificador de algoritmo e informacion de realimentacion.
  9. 9. Metodo segun la reivindicacion 8, en el que se definen dichos diferentes algoritmos segun redes neuronales, algoritmos de aprendizaje de maquina supervisados, algoritmos de agrupamiento y/o algoritmos sencillos de la siguiente lista no cerrada: monitorizacion de trafico volumetrico, recuentos absolutos de paquetes o flujos entre nodos y deteccion periodica de flujos.
  10. 10. Metodo segun la reivindicacion 9, que comprende implementar un algoritmo dado segun un detector de flujo de dominios basado en el sistema de nombres de dominio, o DNS, detectando dicho algoritmo dado actividades de flujo de dominios en un trafico de DNS monitorizado analizando las respuestas de DNS, comprendiendo dicho analisis de respuestas de DNS:
    - extraer una pluralidad de caractensticas a partir de dichas respuestas de DNS;
    - construir un vector de caractensticas con dicha pluralidad de caractensticas;
    - evaluar dicho vector de caractensticas usando una red neuronal, entrenandose previamente dicha red neuronal con ejemplos de vectores; y
    - proporcionar, mediante dicha red neuronal, una etiqueta que indica la conveniencia de establecer una alarma segun dicha evaluacion.
  11. 11. Metodo segun la reivindicacion 10, en el que al menos parte de dicha pluralidad de caractensticas estan
    5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    contenidas en la siguiente lista no cerrada: numero de respuestas de NX_DOMAIN, numero de respuestas de FORMAT_ERROR, numero de respuestas de REFUSED, numero de respuestas de SERVER_FAILUrEs, numero de diferentes FQDN consultados, numero de FQDN de una capa, numero de FQDN de dos capas, numero de FQDN de tres capas o mas, numero de dominios de nivel superior sospechosos, numero de dominios de capa dos con longitud inferior a 6, numero de dominios de capa dos con longitud superior a 5 e inferior a 21, numero de dominios de capa dos con longitud superior a 20, numero de dominios de capa dos con numero de vocales inferior al 0,3 % y numero de dominios de capa dos con numero de dfgitos superior al 0,5 %.
  12. 12. Metodo segun la reivindicacion 8, que comprende implementar un algoritmo concreto segun un algoritmo de agrupamiento de maximizacion de esperanza, en el que dicho algoritmo concreto identifica las clases de trafico, agrupa dichas clases de trafico en agrupamientos y detecta una anomalfa si aparece un patron de trafico que no pertenece a uno de dichos agrupamientos.
  13. 13. Metodo segun la reivindicacion 12, que comprende realimentar dicho algoritmo concreto con un vector de caractensticas de dichos flujos, siendo dichas caractensticas estables a lo largo del tiempo y estando contenidas en la siguiente lista no cerrada: numero de flujos que tienen destino ubicado en un pafs inusual, numero de flujos que tienen destino en una lista negra, numero de flujos que usan un protocolo inusual, numero de flujos de TCP sospechosos, numero de flujos de mas de 10 KB de longitud, numero de flujos de mas de 50 KB de longitud, numero de flujos inferior a la mitad de la unidad de transmision maxima y numero de flujos no generados por una entidad modelada, en el que dichos flujos de TCP sospechosos comprenden flujos solo SYN, flujos solo SYN+ACK, flujos solo FIN y flujos solo FIN+ACK.
  14. 14. Metodo segun la reivindicacion 13, que comprende calcular los lfmites de cada uno de dichos agrupamientos o de cada caractenstica de dicho vector de caractensticas, y detectar una anomalfa si un valor de una caractenstica de cada vector de caractensticas esta fuera de los lfmites del agrupamiento correspondiente o caractenstica correspondiente de dicho vector de caractensticas.
  15. 15. Sistema para detectar software malintencionado, realizandose dicha deteccion en un sistema de deteccion de anomalfas, o ADS, analizando el comportamiento de una red y buscando desviaciones con respecto a una normalidad, indicando dicha normalidad el comportamiento comun de los usuarios de dicha red y definiendose antes de dicha deteccion, comprendiendo dicho sistema un modulo de sonda para la monitorizacion de trafico de dicha red conectada a un modulo controlador encargado de realizar dicha deteccion, en el que dicho modulo controlador esta dotado de una pluralidad de modelos de deteccion construidos por medio de un modulo compilador para cada una de una pluralidad de diferentes entidades de dicha red, cada uno de dicha pluralidad de modelos de deteccion adaptado a dichas diferentes entidades de dicha red y a diferentes algoritmos, implementando dichos diferentes algoritmos diferentes estrategias de deteccion y representando dicha pluralidad de modelos de deteccion dicha normalidad.
  16. 16. Sistema segun la reivindicacion 15, en el que una primera interfaz entre dicho modulo de sonda y dicho modulo controlador permite enviar rastros de trafico en forma de flujos desde dicho monitorizador de sonda a dicho modulo controlador cada vez que dichos flujos estan listos para compartirse o cuando dicho modulo controlador solicita dichos flujos.
  17. 17. Sistema segun la reivindicacion 16, en el que dicho modulo de sonda adapta dichos rastros de trafico a los flujos y permite la disponibilidad en dichos flujos de al menos parte de los siguientes campos: protocolo de capa 4, sellos de fecha y hora del primer y ultimo paquete, direcciones IP de origen y destino en el flujo, numero de paquetes enviados y recibidos, numero de bytes enviados y recibidos, banderas de TCP implicadas en el flujo y datos de cabecera de aplicacion.
  18. 18. Sistema segun la reivindicacion 16 o 17 en el que dicho modulo controlador esta dotado de una base de datos de flujos en la que se almacenan al menos dichos flujos y dicho modulo compilador esta dotado de una base de datos de modelos en la que se almacenan al menos dicha pluralidad de modelos de detecciones.
  19. 19. Sistema segun la reivindicacion 18, en el que se implanta una segunda interfaz entre dicho modulo controlador y dicho modulo compilador con el fin de permitir la comunicacion entre dicho modulo controlador y dicha base de datos de flujos, entre dicha base de datos de flujos y dicho modulo compilador y entre dicho modulo compilador y dicha base de datos de modelos.
  20. 20. Sistema segun cualquiera de las reivindicaciones anteriores 15 a 19, en el que un modulo registrador conectado a dicho modulo controlador se proporciona para registrar alarmas generadas por dicho modulo controlador cuando se detecta dicho software malintencionado, comunicandose dicho modulo controlador y dicho modulo registrador por medio de una tercera interfaz.
  21. 21. Sistema segun la reivindicacion 20, en el que dicho modulo de sonda, dicho modulo controlador, dicho modulo
    compilador y/o dicho modulo registrador estan distribuidos en diferentes servidores o dispositivos ffsicos, usando dicha primera interfaz, dicha segunda interfaz y/o dicha tercera interfaz al menos una de las tecnologfas de comunicacion de la siguiente lista no cerrada: sockets, servicios web, comandos RPC e invocacion de metodo remoto.
    5
ES11805856.9T 2011-10-14 2011-12-23 Método y sistema para detectar software malintencionado Active ES2577143T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
ES201131650P 2011-10-14
ES201131650 2011-10-14
PCT/EP2011/073949 WO2013053407A1 (en) 2011-10-14 2011-12-23 A method and a system to detect malicious software

Publications (1)

Publication Number Publication Date
ES2577143T3 true ES2577143T3 (es) 2016-07-13

Family

ID=45464552

Family Applications (1)

Application Number Title Priority Date Filing Date
ES11805856.9T Active ES2577143T3 (es) 2011-10-14 2011-12-23 Método y sistema para detectar software malintencionado

Country Status (4)

Country Link
US (1) US20150052606A1 (es)
EP (1) EP2767056B1 (es)
ES (1) ES2577143T3 (es)
WO (1) WO2013053407A1 (es)

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014117406A1 (zh) * 2013-02-04 2014-08-07 华为技术有限公司 特征提取装置、网络流量识别方法、装置和系统
US9817742B2 (en) * 2013-06-25 2017-11-14 Dell International L.L.C. Detecting hardware and software problems in remote systems
US11159415B2 (en) * 2014-03-24 2021-10-26 Secureworks Corp. Method for determining normal sequences of events
CN103955645B (zh) * 2014-04-28 2017-03-08 百度在线网络技术（北京）有限公司 恶意进程行为的检测方法、装置及系统
KR101761737B1 (ko) * 2014-05-20 2017-07-26 한국전자통신연구원 제어 시스템의 이상행위 탐지 시스템 및 방법
GB2529150B (en) * 2014-08-04 2022-03-30 Darktrace Ltd Cyber security
CN105681250B (zh) * 2014-11-17 2019-04-02 中国信息安全测评中心 一种僵尸网络分布式实时检测方法和系统
US9964590B2 (en) 2015-02-27 2018-05-08 At&T Intellectual Property I, L.P. Configurable probe blocks for system monitoring
US9923912B2 (en) 2015-08-28 2018-03-20 Cisco Technology, Inc. Learning detector of malicious network traffic from weak labels
US10135862B1 (en) * 2015-12-04 2018-11-20 Amazon Technologies, Inc. Testing security incident response through automated injection of known indicators of compromise
CN105678157B (zh) * 2016-01-11 2018-09-21 迅鳐成都科技有限公司 一种基于应用环境识别的数据产权保护系统和方法
GB2547202B (en) 2016-02-09 2022-04-20 Darktrace Ltd An anomaly alert system for cyber threat detection
WO2018039792A1 (en) * 2016-08-31 2018-03-08 Wedge Networks Inc. Apparatus and methods for network-based line-rate detection of unknown malware
US10785247B2 (en) * 2017-01-24 2020-09-22 Cisco Technology, Inc. Service usage model for traffic analysis
US10511615B2 (en) * 2017-05-05 2019-12-17 Microsoft Technology Licensing, Llc Non-protocol specific system and method for classifying suspect IP addresses as sources of non-targeted attacks on cloud based machines
US10708284B2 (en) 2017-07-07 2020-07-07 Cisco Technology, Inc. Private-learned IDS
US11924238B2 (en) 2018-02-20 2024-03-05 Darktrace Holdings Limited Cyber threat defense system, components, and a method for using artificial intelligence models trained on a normal pattern of life for systems with unusual data sources
US11985142B2 (en) 2020-02-28 2024-05-14 Darktrace Holdings Limited Method and system for determining and acting on a structured document cyber threat risk
US11477222B2 (en) 2018-02-20 2022-10-18 Darktrace Holdings Limited Cyber threat defense system protecting email networks with machine learning models using a range of metadata from observed email communications
EP3800856B1 (en) 2018-02-20 2023-07-05 Darktrace Holdings Limited A cyber security appliance for a cloud infrastructure
US11962552B2 (en) 2018-02-20 2024-04-16 Darktrace Holdings Limited Endpoint agent extension of a machine learning cyber defense system for email
US11463457B2 (en) 2018-02-20 2022-10-04 Darktrace Holdings Limited Artificial intelligence (AI) based cyber threat analyst to support a cyber security appliance
US10534912B1 (en) * 2018-10-31 2020-01-14 Capital One Services, Llc Methods and systems for multi-tool orchestration
US10986121B2 (en) 2019-01-24 2021-04-20 Darktrace Limited Multivariate network structure anomaly detector
US11012414B2 (en) 2019-04-30 2021-05-18 Centripetal Networks, Inc. Methods and systems for prevention of attacks associated with the domain name system
EP3786827A1 (en) 2019-08-29 2021-03-03 Darktrace Limited Cyber attack adversary simulator
US11716338B2 (en) * 2019-11-26 2023-08-01 Tweenznet Ltd. System and method for determining a file-access pattern and detecting ransomware attacks in at least one computer network
WO2021149225A1 (ja) * 2020-01-23 2021-07-29 三菱電機株式会社 モデル生成装置、モデル生成方法及びモデル生成プログラム
US11973774B2 (en) 2020-02-28 2024-04-30 Darktrace Holdings Limited Multi-stage anomaly detection for process chains in multi-host environments
US11665180B2 (en) 2020-02-28 2023-05-30 International Business Machines Corporation Artificially intelligent security incident and event management
JP2023524619A (ja) 2020-02-28 2023-06-13 ダークトレース ホールディングス リミテッド 関心度に基づいてデータ・フローを異なって取り扱うこと
CN111581640A (zh) * 2020-04-02 2020-08-25 北京兰云科技有限公司 一种恶意软件检测方法、装置及设备、存储介质
CN116827694B (zh) * 2023-08-29 2023-11-24 北京安天网络安全技术有限公司 一种数据安全性检测方法及系统

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1235368C (zh) * 2002-08-21 2006-01-04 华为技术有限公司 在pat模式下同时支持一对一和多对多的地址转换方法
US7634808B1 (en) * 2004-08-20 2009-12-15 Symantec Corporation Method and apparatus to block fast-spreading computer worms that use DNS MX record queries
US20070289013A1 (en) * 2006-06-08 2007-12-13 Keng Leng Albert Lim Method and system for anomaly detection using a collective set of unsupervised machine-learning algorithms
US7882462B2 (en) * 2006-09-11 2011-02-01 The Mathworks, Inc. Hardware definition language generation for frame-based processing
US8098797B2 (en) * 2006-12-27 2012-01-17 Verizon Patent And Licensing Inc. Self-service circuit testing systems and methods
US8015133B1 (en) * 2007-02-20 2011-09-06 Sas Institute Inc. Computer-implemented modeling systems and methods for analyzing and predicting computer network intrusions
EP2222048A1 (en) * 2009-02-24 2010-08-25 BRITISH TELECOMMUNICATIONS public limited company Detecting malicious behaviour on a computer network

Also Published As

Publication number Publication date
EP2767056B1 (en) 2016-04-06
US20150052606A1 (en) 2015-02-19
WO2013053407A1 (en) 2013-04-18
EP2767056A1 (en) 2014-08-20

Similar Documents

Publication Publication Date Title
ES2577143T3 (es) Método y sistema para detectar software malintencionado
Alaidaros et al. An overview of flow-based and packet-based intrusion detection performance in high speed networks
Cao et al. {CAUDIT}: Continuous Auditing of {SSH} Servers To Mitigate {Brute-Force} Attacks
Bhattasali et al. Study of security issues in pervasive environment of next generation internet of things
Beg et al. Feasibility of intrusion detection system with high performance computing: A survey
Haddadi et al. DoS-DDoS: taxonomies of attacks, countermeasures, and well-known defense mechanisms in cloud environment
Hussein et al. Software-Defined Networking (SDN): the security review
WO2016048962A1 (en) Collaborative deep packet inspection systems and methods
Tariq et al. A comprehensive categorization of DDoS attack and DDoS defense techniques
Somwanshi et al. Implementation of honeypots for server security
Saad et al. Rule-based detection technique for ICMPv6 anomalous behaviour
Adiwal et al. DNS Intrusion Detection (DID)—A SNORT-based solution to detect DNS amplification and DNS tunneling attacks
Cherian et al. Mitigation of DDOS and MiTM attacks using belief based secure correlation approach in SDN-based IoT networks
Siddiqui et al. Survey on Unified Threat Management (UTM) Systems for Home Networks
Lyu et al. PEDDA: Practical and Effective Detection of Distributed Attacks on enterprise networks via progressive multi-stage inference
Bahashwan et al. Propose a flow-based approach for detecting abnormal behavior in neighbor discovery protocol (NDP)
Le et al. Correlation-based load balancing for network intrusion detection and prevention systems
Kunhare et al. Network packet analysis in real time traffic and study of snort IDS during the variants of DoS attacks
Kumar et al. IPv6 network security using Snort
Zhou et al. Limiting self-propagating malware based on connection failure behavior
Grant Distributed detection and response for the mitigation of distributed denial of service attacks
Niemelä Traffic analysis for intrusion detection in telecommunications networks
WO2013053817A1 (en) A method and a system to detect malicious software
Yurcik et al. Toward trusted sharing of network packet traces using anonymization: Single-field privacy/analysis tradeoffs
Ahmed et al. A flow marking based anti-spoofing Mechanism (FMAS) using SDN approach