Cybelius consacre une série d’articles à la http://das-musikhaus.com/?kanavka=tipps-flirten-f%C3%BCr-m%C3%A4nner&7d7=89 convergence pare-feux – sondes, à l’occasion de la sortie de son produit vétraz-monthoux rencontrer des femmes CyFRONT « Frontal de Sécurité ».
Dans ce premier article, nous rappelons les définitions, positionnements respectifs et environnements des pare-feux, IDs et ISP.
Pare-feu, IDS, IPS
Les pare-feux sont maintenant présents dans les architectures OT, mais les IDS et IPS sont encore rares. Leur complémentarité est cependant très efficace. Dans ce papier, nous allons présenter les IDS et IPS en relation avec la fonction pare-feu, puis présenter le produit CyFRONT qui incorpore les trois (IDS et IPS sont découplés) en une seule appliance. Des cas d’usage seront présentés.
Définitions
Rappelons les définitions :
- IDS : paginas conocer gente baiona Intrusion Detection System
- IPS : Intrusion Prevention System
Ces produits sont dans les deux cas constitués de sondes analysant un trafic réseau.
L’IDS effectue des traitements ayant pour but de détecter une intrusion, même furtive, selon des critères différents des filtrages effectués par les pare-feux. Ces détections sont remontées à un centre de niveau supérieur, en général un SOC (Security Information Center), ou simplement un logiciel SIEM (Security Inforomation Event Management), qui peut initialiser la réaction de plusieurs manières : investigations, corrélations, initialisation de la chaîne d’alerte, etc.
L’IPS est un IDS dont la réaction est locale et consiste, dans la majorité des cas, à bloquer le trafic suspect. Autrement, dit, l’IPS ne dépend pas d’une analyse supérieure pour réagir et peut le faire automatiquement.
Cette caractéristique montre bien la difficulté de déployer des IPS dans le monde industriel : le risque de blocage sur une détection bénigne, voire un faux positif, n’est pas tolérable au regard des enjeux de continuité d’activité.
Positionnement
Les IDS par leur nature ne sont jamais en coupure du réseau. Le trafic à analyser leur est fourni via un port mirroring sur un switch, avec éventuellement plusieurs points de capture. Les IPS par contre doivent être en capacité de bloquer le trafic, ce qui signifie que la partie agissante est bien en coupure sur le réseau.
Enfin il n’est pas intéressant de faire travailler les IDS et IPS sur le trafic avant filtrage réseau. Les algorithmes d’analyse du réseau, identiques pour les IDS et IPS, ont pour objet de détecter essentiellement des attaques ciblées, complexes. Il s’agit d’une approche différente des patterns que les règles de pare-feux savent parfaitement détecter et arrêter. Les analyses temps réel des sondes sont consommatrices de ressources et il est donc intéressant de les positionner sur les parties déjà filtrées, et sensibles.
On arrive donc à ce type de positionnement :
Cependant, tous les pare-feux ont aujourd’hui une fonction IDS embarquée. Par exemple notre produit CyFRONT a dans sa fonction pare-feu la possibilité d’activer Suricata ou Snort. Est-ce judicieux ?
La réponse est oui sur une topologie simple pour laquelle le trafic à analyser est celui qui traverse le pare-feu. Comme indiqué, il est dans ce cas préférable d’activer la sonde sur l’aval du pare-feu, cependant l’analyse amont avant filtrage peut être préférée si l’on veut également caractériser les requêtes entrantes (par exemple pour détecter des tentatives d’attaque, même filtrées par le pare-feu). Il faut juste être conscient que les ressources nécessaires peuvent devenir très importantes.
Dans les deux cas, la compromission de la machine entraîne cependant la compromission du pare-feu et de la protection apportée par la sonde, sauf à avoir des Machines Virtuelles (VM) absolument distinctes ou des cartes CPU indépendantes (et si possible des Systèmes d’Exploitation (OS) différents) : c’est-à-dire qu’on tend vers des applications ou équipements séparés.
Un pare-feu peut également (et c’est recommandé pour les systèmes industriels) servir pour la ségrégation des réseaux et avoir plusieurs réseaux différents à ses interfaces, comme on le verra dans les cas d’application présentés ci-dessous. Dans ce cas, le regroupement avec la sonde est délicat, d’autant que des fonctions de routage sont mises en œuvre dans l’équipement en plus des fonctions strictes de pare-feu.
Environnement
L’IDS comme l’IPS ont une fonction d’analyse du trafic qui est à la base de leur fonction. Ces analyses sont faites en temps réel, et génèrent des alertes à plusieurs niveaux. Les alertes ne sont pas corrélées dans l’équipement avec la vie du site industriel, les interventions, les pannes, les évolutions fonctionnelles, etc. et ne doivent pas l’être car, étant des détecteurs d’attaque, ces équipements doivent avoir une surface d’attaque aussi faible que possible.
La performance globale de détection et de réaction dépend donc pour beaucoup d’une contextualisation et de corrélation avec des informations externes que l’on ne peut pas trouver sur le réseau industriel. C’est pour cela qu’un SIEM doit non seulement recevoir les alertes des sondes, mais les traiter « à façon ». En particulier, il faut pouvoir effectuer une forme de « levée de doutes » sur les évènements graves avant d’initialiser une gestion de crise.
Cependant, la connexion à un SIEM qui est hors zone industrielle augmente la surface d’attaque des sondes, qui doit pourtant être la plus petite possible – en fait, un attaquant ne devrait jamais savoir si une sonde est positionnée sur le réseau ou pas. Pour minimiser les risques, ce canal de communication devrait être très spécifique et très protégé.
Concernant les SIEMs, il faut noter que ces derniers sont tous capables de traiter directement et de manière automatisée les alertes des sondes par signature, puisqu’ils bénéficient des mêmes investigations sur les attaques. Ce n’est pas le cas pour les alertes des sondes comportementales, pour lesquelles les règles de corrélation doivent être déterminées selon le type de comportement anormal que remonte la sonde.
A Cybelius, nous avons, par exemple, expérimenté avec un partenaire pour le SIEM la corrélation, dans une salle où pourtant personne n’était présent selon le contrôle d’accès, entre l’émission d’une commande depuis le superviseur et l’absence d’une personne dans la pièce où se trouve le superviseur.. Cet exemple est illustratif des capacités uniques d’une sonde comportementale associée à un SIEM.
Également, comme tout logiciel, l’IDS ou l’IPS font l’objet de mises à jour, soit liées aux évolutions fonctionnelles poussées par l’éditeur, soit ou motivées par des découvertes de vulnérabilités les affectant. Si un malware est introduit à l’occasion de telles mises à jour, la sonde peut devenir manipulée et inopérante. Le scénario le pire étant que le canal de communication avec le SIEM soit détournée pour un serveur Command and Control de l’attaquant. Et cela d’autant que la sonde voit un nombre d’informations considérable : tout le trafic du réseau surveillé.
Pour les sondes basées sur un principe de signature (voir article suivant), ce point est encore plus crucial car l’efficacité de la sonde dépend d’une mise à jour régulière de sa base de pattern : ce qui signifie que les échanges avec l’extérieur sont plus réguliers, augmentant de fait la surface d’exposition au moins dans sa temporalité.
On voit donc l’intérêt et même la nécessité de soigner l’environnement de déploiement de la sonde et l’ensemble des outils, accès et procédures liées à son utilisation, sa maintenance et son évolution tout au long de sa vie.
Prochains articles
Dans un second article, nous regarderons plus précisément les IDS / IPS, les approches signature / comportementales, et leur mise en œuvre.
Dans un troisième article nous présenterons le produit CyFRONT ainsi qu’une déclinaison du modèle Purdue. Sur cette base, nous présentons différents cas d’usage dans les deux derniers articles.
