Utilisateur:Crashdown59/BrouillonArchitectureDetection2

Une page de Wikipédia, l'encyclopédie libre.

Les principes et architecture des système de détection d'intrusion (IDS) désigne les choix définis lors de la conception de l'IDS.

On peut distinguer 3 composantes nécessaires pour un IDS :

  • la surveillance du système d'information
  • le scan des sources d'informations (Probing)
  • les décisions prises lors de l'évaluation positive d'une intrusion

Selon les choix effectués lors de la conception d'un IDS, certains composantes de l'architecture peuvent changer.

En effet, les Systèmes de détection d'intrusion distribués (DIDS) hérite des contraintes des systèmes distribués et les peuvent éventuellement empêcher des intrusions.

La technique d'analyse des données peuvent éventuellement modifier l'architecture en ajoutant la couche de traitement des données propres à la technologie utilisée.

On peut ensuite considérer que le cloud computing pose de nouvelles contraintes sur l'architecture d'un IDS, notamment par la détection d'intrusion pour les machines virtuelles.

On utilise alors des Hypervisor-Based IDS afin de pouvoir détecter les intrusions sur ces machines virtuelles.

Couches d'un IDS[modifier | modifier le code]

Les IDS ont 3 couches nécessaires, qui sont :

  • la couche de surveillance du système d'information (Probing)
  • la couche de surveillance
  • la couche de décision [1]

Dans ces couches, on ne considère pas l'interface utilisateur, qui ne constitue pas une fonctionnalité nécessaire au bon fonctionnement d'un IDS, mais pourtant recommandé.

Probing[modifier | modifier le code]

La couche de probing est en charge d'enregistrer toutes les actions. [2]

Dans le cadre des Systèmes de détection d'intrusion réseaux (NIDS) , ces actions viennent du trafic réseau.

Dans le cadre des Host-based intrusion detection system (HIDS) , les actions viennent directement du système d'exploitation.

Ces actions peuvent être de différentes sortes (lectures, écriture de fichiers, authentification...) et sont ensuite enregistrés en audits records, qui sont envoyés à la couche surveillance afin d'être analysé [3].

Surveillance[modifier | modifier le code]

La couche de surveillance contient tout le code de traitement des audits records. Elle est responsable d'évaluer la menace de notre système à partir des différents audit records.

les audits records sont alors analysés afin de trouver les événements notables.

pour les HIDS, les événements notables peuvent être :

  • authentification ratée
  • accès à /etc/passwd [4]

pour les NIDS, les événements notables peuvent être :

  • rlogin
  • connexions telnet [5]

Après avoir identifié la menace de notre Système d'Information, il va alors indiquer son jugement sur la sécurité du réseau ou des systèmes et les transmettre sa décision à la couche décision. [6]

Decisions[modifier | modifier le code]

Si la couche surveillance décide que quelqu'un s'est introduit le système, l'IDS peut prendre plusieurs décisions  :

  • La première est de prévenir l'administrateur du SI afin qu'il puisse prendre les décisions qui s'impose
  • la deuxième est d'effectuer une action définie a l'avance par l'administrateur système afin d’empêcher l'intrusion (ou la ralentir) .

Types d'IDS et changements sur l'architecture des IDS[modifier | modifier le code]

Certains types d'IDS possède des particularités bien a elles, capable de modifier l'architecture du système.

NIDS et IDS Hybride[modifier | modifier le code]

Dans le cas des deux IDS suivant, une couche supplémentaire peut être ajoutée, une couche de prévention. Elle est située avant la couche probing et permet d’empêcher certaines menaces.

Afin de limiter l'intrusion du réseau, l'IDS peut refuser de prendre certains paquets qu'il considère comme néfaste. [7]

Pour cela, elle utilise des techniques de détection à base de signature.

IDS distribués, oui ou non?[modifier | modifier le code]

Les IDS distribués sont des IDS qui couvre un système entier composant plusieurs Ordinateurs.

Ce système a une différence majeure, le système doit capter plus d'informations. De plus chaque partie est distribuable.

Dans ce soucis, une couche de communication pour chaque module doit être rajoutée afin que le système puisse fonctionner correctement. [8]

De plus, le flot de données étant trop important, il est nécessaire de diviser la couche monitoring en 2 parties.[9]

La première partie monitoring est situé sur la même machine que la couche Probing, qui va d'abord traiter les audits records pour en tirer tout de suite les événements notables.

Ces événements sont alors envoyés a la couche monitoring qui reçoit tout les événements notables, et va en tirer des conclusions sur :

  • l'état du système local
  • l'état du système global

Les IDS non-distribués n'ont eux aucun surcoût de communication ou des autres contraintes d'un système distribué , et profite donc de performances plus grande que les IDS distribués.

Architecture a base d'agents[modifier | modifier le code]

Dans les architecture présentes ci-dessus, si un module est perdu, le système est compromis. dans un système a base d'agents, chaque agents sont indépendant [10].

Si on perd un agent, l'IDS n'est pas compromis [11].

Chaque module est alors transformé en type d'agent :

  • un type d'agent s'occupe du monitoring
  • un type d'agent s'occupe des décisions
  • un type d'agent s'occupe de la détection des événements

Cela permet au système d'être plus tolérant aux pannes et ainsi de garantir une plus grande disponibilité de l'IDS.



Détection d'intrusion, quoi choisir?[modifier | modifier le code]

En général, il y a 3 techniques d'analyses des données reçues par le module de détection des événements :

  • misuse (signature-based) detection [12]
  • anomaly (behavior-based) detection [13]

Les deux techniques de détection peuvent être utilisé simultanément dans un IDS . [14]

Anomaly detection[modifier | modifier le code]

La technique d'anomaly detection considère qu'un événement qui est différent du fonctionnement normal du système qu'on a enregistré précédemment signifie que le système a été introduit.

Afin de pouvoir dire qu'un système est normal ou pas, il faut donc l'avoir entraîné précédemment en lui faisant comprendre ce qu'est un système normal.

Après cette phase d’entraînement, le système informera n'importe quel activité suspicieuse [15].

Afin de réaliser cela, plusieurs techniques sont possibles :

  • Apprentissage automatique ( Réseau neuronique...)
  • [Data Mining]

Pour réaliser ces techniques, il faut donc ajouter un module de communication et de traitement des informations compatible avec la technique.

Par exemple, pour un [Réseau neuronique], il faut traduire les audits records en données compatible avec un réseau de neurones a l'entrée et la sortie du réseau [16].

Signature-based detection[modifier | modifier le code]

La technique de détection basé sur les signatures essaye d'associer l'activité de l'ordinateur avec des signatures d'attaques connus. [17]

Cette techniques utilise donc une connaissance des différentes attaques existantes.

Cette signature sont des règles défini statiquement qui caractérise le comportement d'un utilisateur .[18]

Ces règles qui peuvent être statiques (basée sur un choix de sécurité) ou dynamique (basé sur des techniques d'apprentissages temporelles).[19]

Afin de réaliser ces règles, on peut utiliser des techniques probabilistes, des techniques a base d'état, de règles ... [20]

Avantages et Inconvénient des techniques[modifier | modifier le code]

Les techniques a base de signature ont pour avantage de pouvoir fonctionner assez rapidement, leur initialisation étant très courte. [21]

Par contre, il est nécessaire, pour chaque nouvelle attaque, de pouvoir développer des règles qui permettent de stopper l'attaque.

De plus, il est possible que les attaques évolue, ce qui doit faire qu'on doit modifier des règles, ce qui est pénible a mettre à jour.

Dans les cas de l'Anomaly detection, cela est très chronophage en temps afin de détecter les attaques mais après initialisation le système peut potentiellement détecter des attaques inconnues ce qui peut permettre d'avancer la connaissance en matière d'attaques. [22]

Cloud, un nouveau type d'IDS?[modifier | modifier le code]

L'apparition du cloud a développé de nouvelles problématiques.

En effet, le cloud se base a l'aide de machines virtuelles qui sont changé constamment d'endroit où de propriétaire.

Afin de surveiller ces machines virtuelles, un nouveau type d'IDS est apparu, les IDS basé sur les hyperviseurs.

Ces IDS se base eux sur les différentes métriques récupérés sur les différentes machines virtuelles comme le nombre de paquets transmis/recus, les appel de lecture ou d'écriture des block ou l'utilisation du CPU, permettent de détecter les intrusions [23].

Historique[modifier | modifier le code]

L'apparition des premiers IDS remonte à 1987 avec l'IDS nommé IDES développé par Dorothy Denning[24].

Cet IDS apparaissant avant l'usage d'internet où de réseaux développés, il s'agissait d'un HIDS.

à la suite apparait les NIDS, qui remonte aux début des années 1990.

Jusque pendant les années 90, les systèmes n'utilisait que des détections a base de signature. Avec le progrès des techniques de détection (découverte de patterns dans les communication réseaux), les IDS à base d'Anomaly detection commence a apparaître.

On note aussi l'apparition des DIDS en 1994 qui permet alors de gérer un parc de machines.

Les IDS explosent a l'arrivée du cloud computing, on note alors l'apparition de nouvelles contraintes (apparition des IDS pour hyperviseur, multiplication du parc de machine à surveiller...).

Cela entraîne donc l'apparition des Hypervisor-based IDS.

Quotes[modifier | modifier le code]

Références[modifier | modifier le code]

Bibliographie[modifier | modifier le code]

  • (en) Vigna et Kemmerer, « NetSTAT: A Network-based Intrusion Detection System », Journal of computer security, vol. 7, no 1,‎ , p. 3-7
  • (en) Sundaram et Aurobindo, « An Introduction to Intrusion Detection », Crossroads, vol. 2, no 4,‎ , p. 3-7 (ISSN 1528-4972, DOI 10.1145/332159.332161)
  • (en) Mukherjee, Aurobindo et Levitt, « Network intrusion detection », IEEE Network, vol. 8, no 3,‎ , p. 26-41 (ISSN 0890-8044, DOI 10.1109/65.283931)
  • (en) Warrender, Forrest et Pearlmutter, « Detecting intrusions using system calls: alternative data models », IEEE Xplore,‎ , p. 133-145 (DOI 10.1109/SECPRI.1999.766910)
  • (en) Zhang, Wang, Sun, Green et Alam, « Distributed Intrusion Detection System in a Multi-Layer Network Architecture of Smart Grids », IEEE Transactions on Smart Grid, vol. 2, no 4,‎ , p. 796-808 (ISSN 1949-3053, DOI 10.1109/TSG.2011.2159818)
  • (en) Roschke, Cheng et Meinel, « Intrusion Detection in the Cloud », IEEE Xplore,‎ , p. 729-734 (DOI 10.1109/DASC.2009.94)
  • (en) Depren, Topallar, Anarim et Ciliz, « An intelligent intrusion detection system (IDS) for anomaly and misuse detection in computer networks », Expert Systems with Applications, vol. 29, no 4,‎ , p. 713-722 (ISSN 0957-4174, DOI 10.1016/j.eswa.2005.05.002)
  • (en) Rashida et Seyedeh, « Hybrid architecture for distributed intrusion detection system in wireless network », International Journal of Network Security & Its Applications, vol. 5, no 3,‎ , p. 45 (DOI 10.5121/ijnsa.2013.5305)
  • (en) Steven R. Snapp, James Brentano, Gihan V. Dias, Terrance L. Goan, L. Todd Heberlein, Che-Lin Ho, Karl N. Levitt, Biswanath Mukherjee, Stephen E. Smaha, Tim Grance, Daniel M. Teal et Doug Mansur, Internet Besieged, New York, NY, USA, ACM Press/Addison-Wesley Publishing Co., , 211-227 p. (ISBN 978-0-201-30820-4), « DIDS (distributed intrusion detection system)—motivation, architecture, and an early prototype »
  • (en) J. Gómez, C. Gil, N. Padilla, R. Baños et C. Jiménez, Distributed Computing, Artificial Intelligence, Bioinformatics, Soft Computing, and Ambient Assisted Living, Springer Berlin Heidelberg, coll. « Lecture Notes in Computer Science », , 515–522 p. (ISBN 978-3-642-02481-8, DOI 10.1007/978-3-642-02481-8_75), « Design of a Snort-Based Hybrid Intrusion Detection System »
  • (en) M. Ali Aydın, A. Halim Zaim et K. Gökhan Ceylan, « A hybrid intrusion detection system design for computer network security », Computers & Electrical Engineering, vol. 35, no 3,‎ , p. 517–526 (ISSN 0045-7906, DOI 10.1016/j.compeleceng.2008.12.005, lire en ligne, consulté le )
  • (en) J.S. Balasubramaniyan, J.O. Garcia-Fernandez, D. Isacoff, E. Spafford et D. Zamboni, « An architecture for intrusion detection using autonomous agents », Proceedings of 14th Annual Computer Security Applications Conference.,‎ , p. 13–24 (DOI 10.1109/CSAC.1998.738563)
  • (en) H. Debar, M. Becker et D. Siboni, « A neural network component for an intrusion detection system », Proceedings of the 1992 IEEE Computer Society Symposium on Research in Security and Privacy,‎ , p. 240–250 (DOI 10.1109/RISP.1992.213257)
  • (en) Chirag Modi, Dhiren Patel, Bhavesh Borisaniya, Hiren Patel, Avi Patel et Muttukrishnan Rajarajan, « A survey of intrusion detection techniques in Cloud », Journal of Network and Computer Applications, vol. 36, no 1,‎ , p. 42–57 (ISSN 1084-8045, DOI 10.1016/j.jnca.2012.05.003, lire en ligne, consulté le )
  • (en) Hung-Jen Liao, Chun-Hung Richard Lin, Ying-Chih Lin et Kuang-Yuan Tung, « Intrusion detection system: A comprehensive review », Journal of Network and Computer Applications, vol. 36, no 1,‎ , p. 16–24 (ISSN 1084-8045, DOI 10.1016/j.jnca.2012.09.004, lire en ligne, consulté le )
  • (en) J. Nikolai et Yong Wang, « Hypervisor-based cloud intrusion detection system », IEEE Explore,‎ , p. 989–993 (DOI 10.1109/ICCNC.2014.6785472)
  • (en) Chi-Ho Tsang et Sam Kwong, « Multi-agent intrusion detection system in industrial network using ant colony clustering approach and unsupervised feature extraction », IEEE International Conference on Industrial Technology, 2005. ICIT 2005,‎ , p. 51–56 (DOI 10.1109/ICIT.2005.1600609)