Afin d’éviter les écueils liés aux problèmes inhérents à la détec-tion d’intrusion, l’intégradétec-tion de ce type de composants au sein d’un système d’information existant nécessite la prise en compte de plusieurs facteurs de type techniques, organisationnels ou procéduraux :
• Une maîtrise parfaite de l’environnement et des flux qui tran-sitent au sein de ce système d’information afin de permettre un paramétrage particulier (ou tuning) des sondes,
• Une organisation qui permette la supervision des alertes remontées et, de manière sous-jacente, la réaction à des aler-tes réelles,
En complément à ces fonctionnalités de détection, les fonction-nalités de prévention reposent principalement sur des mesures de sécurité déjà existantes telles que le pare-feu personnel. L’in-térêt d’un HI(D/P)S par rapport à ce type de mesures réside dans l’automatisation de la réponse à une intrusion donnée : la règle de filtrage mise en œuvre au niveau du HI(D/P)S sera implémentée automatiquement alors que, dans le cas du firewall personnel, l’intervention d’un utilisateur sera nécessaire.
Etant donné ces deux types de sondes, il est possible d’envisa-ger sur un réseau particulier l’implémentation de ces deux types de sondes : un NID/PS pour surveiller le trafic réseau et un HID/PS pour surveiller l’activité des systèmes.
Vers l’analyse comportementale et la corrélation d’alertes
Les évolutions actuelles des I(D/P)S ont pour objectif principal d’améliorer les systèmes actuels en réduisant leurs inconvénients d’utilisation majeurs, dont notamment la quantité de fausses aler-tes ainsi que la qualité des aleraler-tes remontées.
L’IDS/IPS joue-t-il en NBA ?
Parmi ces nouvelles évolutions, nous pouvons notamment citer les systèmes NBA (Network Behavior Analysis) qui ont pour fonction principale l’analyse du trafic réseau afin d’identifier du trafic inhabi-tuel. A ce niveau, la différence entre NBA et I(D/P)S reste infime et on peut même être amené à considérer ces nouveaux équipements comme des I(D/P)S basés sur de l’analyse comportementale. A y regarder de plus près, les composants de ces systèmes corres-pondent effectivement aux mêmes composants des I(D/P)S, c’est-à-dire une sonde, une console de gestion et un serveur de centralisation. La différence principale avec leurs aînés repose sur la source d’émission des informations : en effet, les sondes NBA peu-vent, soit agir comme une sonde I(D/P)S, soit récupérer les informa-tions des équipements réseau présents au sein de l’environnement à surveiller, comme par exemple des routeurs.
Par ailleurs, la fonctionnalité complémentaire des NBA corres-pond à leurs capacités de consolidation automatique d’informa-tion liée aux équipements surveillés. Les principaux NBA sont en effet capables de récupérer et de mettre à jour automatique-ment les informations suivantes, notamautomatique-ment au travers des tech-niques de passive fingerprinting :
• Liste d’hôtes présents et communiquant sur le réseau à surveiller,
• Informations concernant ces hôtes, dont notamment leur sys-tème d’exploitation leur adresse IP ou les services TCP/UDP ouverts.
Etant donné qu’ils fonctionnent en détectant des déviations de trafics normaux, ces équipements ne sont pas optimisés pour détecter des attaques ciblées sur des ports normalement utilisés à bon escient ou sur des attaques ciblées à un nombre réduit de machines.
Le principal avantage de ces systèmes repose sur sa capacité à connaître l’environnement qu’il doit surveiller. Les inconvénients
24 IT-expert n°70 - novembre/décembre 2007
• Une politique de sécurité définie et appliquée qui permet d’avoir un niveau de maturité suffisant du processus lié à la sécurité du système d’information.
Vers une maîtrise parfaite des flux et de l’environnement IT
La connaissance détaillée du système d’information de l’organi-sation est un élément primordial à toute implémentation de sys-tème de détection/prévention d’intrusion. Etant donné que la problématique principale de ces systèmes réside dans le nombre trop important d’alertes émises, il est important de savoir réduire ce nombre d’alertes.
Afin d’atteindre cet objectif, les systèmes de détection/prévention d’intrusion doivent s’adapter à l’environnement dans lequel ils sont implémentés : en effet, les sondes de détection doivent être configurées de manière à remonter des alertes uniquement per-tinentes pour l’environnement surveillé.
La pertinence de cette configuration, qui consiste à sélectionner au travers d’une démarche de tuning les bases de signatures adéquates, repose donc sur une connaissance détaillée de l’en-vironnement à surveiller et des flux qui y transitent. A titre d’exem-ple, la configuration d’une sonde située dans une DMZ frontal à Internet hébergeant des serveurs Web Windows ne doit pas être
identique à celle d’une sonde située dans une zone back-end d’un datacenter hébergeant les serveurs qui supportent des bases de données Oracle critiques à une activité métier d’une organisation. En effet, pour ces deux exemples, les signatures à activer seront :
• Pour notre DMZ, des signatures relatives à des attaques Web sur des équipements Windows,
• Pour notre zone back-end, des signatures relatives à des atta-ques Oracle.
Le schéma ci-dessous représente cet exemple.
Cette étape de tuning se base bien sûr, au préalable, sur une connaissance détaillée de l’environnement à surveiller, qui repose sur la cartographie réseau de l’organisation ainsi que sur l’inven-taire des équipements présents dans cet environnement ainsi que sur les flux qui transitent au sein de l’organisation, formalisés au travers d’une cartographie des flux (applicatifs, d’administra-tion, etc.).
Les deux éléments mentionnés précédemment ne sont pas associés uniquement à un processus d’implémentation de sys-tèmes de détection/prévention d’intrusion. En effet, ces éléments font normalement partie intégrante des processus déjà mis en place au sein d’une DSI, notamment au travers du processus de gestion des configurations et de l’urbanisation des systèmes.
DMZ Serveurs
Réseau d'administration
Réseau utilisateurs
Sonde configurée avec des signatures spécifiques Bases de Données Sonde configurée avec des signatures spécifiques Serveurss Web
Web
DMZ Back End
DMZ Serveurs Web
Une politique de sécurité déclinée au niveau du réseau
Une politique de sécurité définit l’ensemble des exigences qui doivent être mises en œuvre afin d’assurer la sécurité de l’infor-mation de l’organisation, notamment en termes de confidentia-lité, de disponibiconfidentia-lité, d’intégrité et de traçabilité. Cette politique se base notamment sur les exigences réglementaires, légales et sur la stratégie de l’entreprise.
En pratique, l’application d’une politique de sécurité s’effectue en déclinant celle-ci en différents domaines concernés : à partir des exigences générales définies dans la politique de sécurité, des exigences spécifiques à chaque environnement technique et/ou organisationnel seront identifiées. Dans ce cadre, une politique d’accès réseau peut être définie afin de décliner ces exigences en termes d’accès au réseau, de filtrage d’accès, de règles de rou-tage et aussi de détection d’intrusion.
Au sein de cette politique déclinée, les orientations concernant la détection d’intrusion peuvent permettre d’identifier les mesures techniques à mettre en œuvre afin de couvrir les risques identifiés précédemment. Des exemples d’exigences associées à ce domaine spécifique pourraient être les suivantes :
• L’ensemble des flux circulant de et vers les DMZ critiques de l’organisation doivent être contrôlés afin de détecter, et si pos-sible, prévenir les attaques,
• L’ensemble des flux sur le réseau des utilisateurs de l’organi-sation doit être surveillé afin d’identifier les possibles attaques internes,
De fait, la formalisation de ces exigences peut et doit permettre aux opérationnels de mettre en place des systèmes de détection et de prévention qui ont des objectifs définis et clairs. L’absence de formalisation de politique de sécurité déclinée dans le domaine des réseaux peut entraîner la mise en place de systè-mes de détection/prévention sans réels objectifs.
Une organisation adaptée à la supervision et à la réaction
La mise en place d’un système de détection/prévention d’intru-sion est inutile si l’organisation en charge de ce système ne per-met pas une supervision régulière ainsi qu’une réaction rapide à toute intrusion identifiée.
L’utilisation de ce type de systèmes repose tout d’abord sur l’im-plémentation de ces systèmes au sein d’un environnement à sur-veiller (en mode projet) et ensuite, sur l’exploitation de ces systèmes et la surveillance des alertes remontées.
La première étape correspondant au projet de mise en œuvre nécessite une quantité de ressources à un instant donné, mais ne nécessite pas de réutiliser ces ressources de manière régulière : une fois installée, le système est en exploitation.
La deuxième étape nécessite, de la même manière que pour le processus d’exploitation d’un système d’information, la présence et l’utilisation régulière de ressources. Cette exigence est liée à la gestion des incidents : en cas d’incident, des ressources techni-ques (outil de gestion d’incident et/ou monitoring) et
organisa-Stratégies Métiers
Exigences Métiers Menaces et Vulnérabilité Exigences Légales
Exigences de Sécurité
Exigences Accès Réseau Exigences Ecran de Veille Exigences Mot de Passe
Implications Implications
Implications
Implémenter les mesures de sécurité Métiers
Niveau Stratégique
Niveau Opérationnel
26 IT-expert n°70 - novembre/décembre 2007
Thomas ROETYNCK
Senior Consultant, effectue des missions liées à la sécurité des systèmes d’information dans le cadre de l’activité « Security
& Privacy Services » au sein du Cabinet Deloitte.
tionnelles (équipe d’exploitation, service desk) sont mises en œuvre pour gérer et résoudre l’incident. De la même manière, l’utilisation régulière de ressources techniques (sondes, serveur de corrélation d’alertes) et humaines (équipe sécurité, RSSI) pour la détection d’intrusion est nécessaire : en cas d’intrusion, ces ressources doivent être utilisées pour détecter cette intrusion et pour répondre de manière efficace à cette intrusion.
Le processus est similaire pour le domaine de la sécurité physi-que : imaginons un instant physi-que des systèmes de détection d’in-trusion physique sophistiqués soient mis en œuvre au sein des locaux d’une entreprise afin de repérer toute intrusion. Que diraient ses dirigeants si les alertes remontées par ces systèmes n’étaient pas contrôlées par les gardes de sécurité ? Que diraient-ils en plus si ces systèmes prenaient l’initiative de fermer et de verrouiller l’ensemble des portes de ces locaux ? En bref, l’absence de ressources pour la gestion des I(D/P)S peut entraî-ner une utilisation inefficace et/ou inutile de ces systèmes.