🥇Les protocoles Flow comme outil de surveillance de la sécurité du réseau interne

Lorsqu'il s'agit de surveiller la sécurité d'un réseau d'entreprise ou d'administration interne, beaucoup font immédiatement le lien avec le contrôle des fuites d'informations et l'implémentation de solutions DLP. Mais si l'on précise la question en demandant comment vous détectez les attaques dans votre réseau interne, la réponse fait généralement référence aux systèmes de détection d'intrusions (IDS). Ce qui était le seul choix il y a 10 à 20 ans est aujourd'hui devenu un anachronisme. Il existe un moyen plus efficace, et parfois le seul viable, de surveiller un réseau interne : utiliser des protocoles de flux, initialement conçus pour détecter des problèmes de réseau (troubleshooting), mais qui se sont au fil du temps transformés en un outil de sécurité très intéressant. Dans cet article, nous aborderons les différents types de protocoles de flux, ceux qui sont les meilleurs pour détecter des attaques réseau, les meilleurs endroits pour mettre en place une surveillance par flux, les aspects à considérer lors du déploiement d'un tel système, et même comment tout cela peut être mis en œuvre sur du matériel local.

Je ne vais pas m'arrêter sur la question « Pourquoi a-t-on besoin de surveiller la sécurité de l'infrastructure interne ? » La réponse semble évidente. Mais si vous souhaitez vous en assurer une fois de plus, sachez qu'aujourd'hui, cela est indispensable. regardez une petite vidéo expliquant comment il est possible de pénétrer dans un réseau d'entreprise protégé par un pare-feu de 17 manières différentes. Nous considérerons donc que nous comprenons que la surveillance interne est nécessaire et qu'il ne reste plus qu'à comprendre comment l'organiser.

Je mettrais en avant trois sources de données clés pour surveiller l'infrastructure au niveau réseau :

le trafic « brut » que nous capturons et soumettons à des systèmes d'analyse pour analyse,
les événements des équipements réseau par lesquels passe le trafic,
les informations sur le trafic obtenues via l'un des protocoles de flux.

La capture de trafic brut est l'option la plus populaire parmi les spécialistes de la sécurité, car elle a historiquement été la première. Les systèmes de détection d'intrusions réseau (le tout premier système commercial de détection d'intrusions était NetRanger de la société Wheel Group, acquis par Cisco en 1998) se consacraient justement à la capture de paquets (et plus tard de sessions), dans lesquels étaient recherchées des signatures spécifiques (“règles décisives” dans la terminologie de la FSTEK), signalant des attaques. Bien sûr, il est possible d'analyser le trafic brut non seulement à l'aide d'un IDS, mais aussi d'autres moyens (par exemple, Wireshark, tcpdump ou la fonctionnalité NBAR2 dans Cisco IOS), mais ces outils manquent généralement d'une base de connaissances qui distingue un outil de cybersécurité d'un outil informatique classique.

Ainsi, les systèmes de détection d'intrusions. La méthode de détection d'attaques réseau la plus ancienne et la plus populaire, qui s'en sort plutôt bien à la périphérie (peu importe laquelle — d'entreprise, de centre de données, de segment, etc.), mais qui faiblit dans les réseaux commutés modernes et définis par logiciel. Dans le cas d'un réseau construit sur des commutateurs ordinaires, l'infrastructure des capteurs de détection d'intrusions devient trop importante — vous devrez installer un capteur pour chaque connexion vers un nœud dont vous souhaitez surveiller les attaques. Tout fabricant sera bien sûr heureux de vous vendre des centaines et des milliers de capteurs, mais je pense que votre budget ne supportera pas de telles dépenses. Je peux dire qu même chez Cisco (où nous développons le NGIPS), nous n'avons pas pu le faire, bien que, a priori, la question du prix ne devrait pas se poser — c'est notre propre solution. De plus, se pose la question de la façon de connecter le capteur dans ce cas ? En rupture ? Et si le capteur lui-même est hors service ? Exiger la présence d'un module bypass dans le capteur ? Utiliser des diviseurs (tap) ? Tout cela augmente le coût de la solution et la rend inabordable pour une entreprise de toute taille.

Vous pouvez essayer de "brancher" le capteur sur un port SPAN/RSPAN/ERSPAN et rediriger le trafic des ports nécessaires du commutateur vers celui-ci. Cette approche soulage en partie le problème décrit dans le paragraphe précédent, mais en pose un autre : le port SPAN ne peut pas accepter tout le trafic qui lui sera dirigé, sa bande passante ne suffira pas. Vous devrez faire des compromis. Soit vous laissez certains nœuds sans surveillance (vous devrez alors les prioriser au préalable), soit vous ne dirigez pas tout le trafic d'un nœud, mais seulement un certain type. Dans tous les cas, nous risquons de manquer certaines attaques. De plus, le port SPAN peut être utilisé à d'autres fins. En fin de compte, nous devrons réexaminer la topologie réseau existante et peut-être apporter des modifications pour couvrir au maximum votre réseau avec le nombre de capteurs dont vous disposez (et coordonner cela avec l'IT).

Et si votre réseau utilise des chemins asymétriques ? Et si vous avez implémenté ou envisagez de mettre en œuvre une SDN ? Et si vous devez surveiller des machines virtualisées ou des conteneurs dont le trafic ne parvient même pas au commutateur physique ? Ces questions ne sont pas appréciées par les fabricants d'IDS traditionnels, car ils ne savent pas comment y répondre. Ils pourraient vous inciter à penser que toutes ces technologies à la mode ne sont qu'un battage médiatique et que vous n'en avez pas besoin. Ils pourraient parler de la nécessité de commencer petit. Ou peut-être diront-ils que vous devez installer un puissant moulin au centre du réseau et rediriger tout le trafic vers lui à l'aide de répartiteurs de charge. Quelle que soit l'option qui vous est proposée, vous devez d'abord comprendre clairement dans quelle mesure elle vous convient. Et ce n'est qu'après cela que vous pourrez prendre une décision sur l'approche à adopter pour la surveillance de la sécurité de l'infrastructure réseau. En revenant à la capture de paquets, je tiens à dire que cette méthode reste très populaire et importante, mais son but principal est le contrôle des frontières : les frontières entre votre organisation et Internet, les frontières entre le centre de données et le reste du réseau, les frontières entre le système de contrôle et le segment corporate. À ces endroits, les IDS/IPS classiques ont toujours leur place et s'acquittent bien des tâches qui leur sont assignées.

Passons à la deuxième option. L'analyse des événements provenant des dispositifs réseau peut également être utilisée à des fins de détection d'attaques, mais pas comme mécanisme principal, car elle ne permet de détecter qu'une petite classe d'intrusions. De plus, elle présente une certaine réactivité : une attaque doit d'abord se produire, puis elle doit être enregistrée par le dispositif réseau, qui signalera ensuite le problème de sécurité d'une manière ou d'une autre. Il existe plusieurs moyens à cet égard. Cela peut être un syslog, RMON ou SNMP. Les deux derniers protocoles pour la surveillance réseau dans le contexte de la sécurité sont utilisés uniquement si nous devons détecter une attaque DoS sur le matériel réseau lui-même, car avec RMON et SNMP, on peut, par exemple, surveiller l'utilisation du processeur central de l'appareil ou de ses interfaces. C'est l'une des méthodes les plus “économiques” (le syslog ou SNMP est disponible pour tous), mais aussi la moins efficace parmi toutes les méthodes de surveillance de la sécurité de l'infrastructure interne - de nombreuses attaques lui échappent. Bien sûr, elles ne doivent pas être négligées et la même analyse des syslogs vous aide à identifier à temps les changements dans la configuration de l'appareil lui-même, la compromission de celui-ci, mais elle n'est pas très adaptée pour détecter des attaques sur l'ensemble du réseau.

La troisième option est l'analyse des informations sur le trafic passant par un appareil supportant l'un des plusieurs protocoles de flux. Dans ce cas, quel que soit le protocole, l'infrastructure de gestion des flux se compose nécessairement de trois composants :

Génération ou exportation de flux. Ce rôle est généralement confié à un routeur, un commutateur ou un autre dispositif réseau qui, en laissant passer le trafic réseau, permet d'extraire des paramètres clés qui sont ensuite transmis au module de collecte. Par exemple, chez Cisco, le protocole Netflow est pris en charge non seulement sur les routeurs et commutateurs, y compris virtuels et industriels, mais aussi sur les contrôleurs sans fil, les pare-feu et même les serveurs.
Collecte de flux. Étant donné qu'il y a généralement plus d'un dispositif réseau dans un réseau moderne, la tâche de collecte et de consolidation des flux se pose, et elle est résolue par ce que l'on appelle des collecteurs, qui traitent les flux reçus et les transmettent ensuite pour analyse.
Analyse des flux. L'analyseur assume la tâche intellectuelle principale et, en appliquant divers algorithmes aux flux, tire différentes conclusions. Par exemple, dans le cadre de la fonction informatique, un tel analyseur peut identifier les goulets d'étranglement du réseau ou analyser le profil de charge du trafic pour une optimisation ultérieure du réseau. Pour la sécurité de l'information, cet analyseur peut détecter les fuites de données, la propagation de logiciels malveillants ou des attaques par déni de service (DoS).

Il ne faut pas penser que cette architecture à trois niveaux est trop complexe : tous les autres choix (sauf peut-être les systèmes de surveillance des réseaux utilisant SNMP et RMON) fonctionnent également selon ce principe. Nous avons un générateur de données pour l'analyse, qui peut être un appareil réseau ou un capteur autonome. Nous avons un système de collecte des alertes et un système de gestion de toute l'infrastructure de surveillance. Les deux derniers composants peuvent être regroupés au sein d'un même nœud, mais dans des réseaux de taille plus ou moins importante, ils sont généralement répartis sur au moins deux appareils afin d'assurer la scalabilité et la fiabilité.

Contrairement à l'analyse des paquets, qui repose sur l'examen des en-têtes et des corps de données de chaque paquet et des sessions qui en découlent, l'analyse des flux s'appuie sur la collecte de métadonnées sur le trafic réseau. Quand, combien, d'où et vers où, comment... voici les questions que l'analyse de la télémétrie réseau à l'aide des différents protocoles de flux tente de répondre. Initialement, ils étaient utilisés pour analyser des statistiques et identifier des problèmes informatiques dans le réseau, mais au fil du temps, avec le développement des mécanismes analytiques, il a été possible de les appliquer à la même télémétrie à des fins de sécurité. Il est important de noter que l'analyse des flux ne remplace pas la capture de paquets. Chacune de ces méthodes a son domaine d'application. Cependant, dans le contexte de cet article, c'est l'analyse des flux qui convient le mieux pour surveiller l'infrastructure interne. Vous avez des appareils réseau (et peu importe s'ils fonctionnent selon un paradigme défini par logiciel ou selon des règles statiques) que l'attaquant ne peut pas contourner. Un capteur IDS classique peut être contourné, mais un appareil réseau prenant en charge le protocole flow ne le peut pas. C'est là que réside l'avantage de cette méthode.

D'une autre part, si vous avez besoin de preuves pour les forces de l'ordre ou votre propre équipe d'enquête d'incidents, il vous faudra nécessairement procéder à la capture de paquets — la télémétrie réseau n'est pas une copie du trafic pouvant être utilisée pour la collecte de preuves ; elle est nécessaire pour la détection rapide et la prise de décisions en matière de cybersécurité. Cela dit, en utilisant l'analyse de la télémétrie, vous pouvez "écrire" non pas tout le trafic réseau (pour information, Cisco et les centres de données s'en occupent :-), mais seulement celui impliqué dans l'attaque. Les outils d'analyse de télémétrie complètent efficacement les mécanismes traditionnels de capture de paquets en permettant une capture et un stockage sélectifs. Dans le cas contraire, vous devrez disposer d'une infrastructure de stockage colossale.

Imaginons un réseau fonctionnant à 250 Mbit/s. Si vous souhaitez conserver tout ce volume, vous aurez besoin de 31 Mo de stockage pour une seconde de transmission de trafic, 1,8 Go pour une minute, 108 Go pour une heure, et 2,6 To pour un jour complet. Pour stocker les données journalières d'un réseau avec une bande passante de 10 Gbit/s, vous aurez besoin de 108 To de stockage. Et certains régulateurs exigent que les données de sécurité soient conservées pendant des années... L'enregistrement « à la demande », que vous permet de réaliser l'analyse des flux, aide à réduire ces valeurs de plusieurs ordres de grandeur. Soit dit en passant, en ce qui concerne le rapport entre le volume des données enregistrées par la télémétrie réseau et la capture complète des données, il est d'environ 1 à 500. Pour les valeurs susmentionnées, le stockage de l'intégralité de la décodage du trafic journalier serait respectivement de 5 et 216 Go (ce qui peut même être enregistré sur une simple clé USB).

Si la méthode de collecte des données réseau brutes ne diffère guère d'un fournisseur à l'autre pour les outils d'analyse, la situation est différente avec l'analyse des flux. Il existe plusieurs variantes de protocoles de flux, dont il est nécessaire de connaître les différences, notamment dans le contexte de la sécurité. Le protocole le plus populaire est le Netflow, développé par Cisco. Il existe plusieurs versions de ce protocole, qui varient par leurs fonctionnalités et le volume d'informations sur le trafic enregistrées. La version actuelle est la neuvième (Netflow v9), sur laquelle le standard industriel Netflow v10, également connu sous le nom de IPFIX, a été développé. Aujourd'hui, la majorité des fournisseurs réseau supporte précisément Netflow ou IPFIX dans leur matériel. Mais il existe également d'autres variantes de protocoles de flux — sFlow, jFlow, cFlow, rFlow, NetStream, etc., parmi lesquels sFlow est le plus populaire. Ce dernier est souvent pris en charge par les fabricants nationaux de matériel réseau en raison de sa simplicité d'implémentation. Quels sont les principales différences entre Netflow, devenu de facto un standard, et sFlow ? Je voudrais en souligner quelques-unes. Tout d'abord, Netflow propose des champs configurables par l'utilisateur, contrairement aux champs fixes dans sFlow. Deuxièmement, et c'est le plus important dans notre cas, sFlow collecte une télémétrie dite échantillonnée, contrairement à la télémétrie non échantillonnée de Netflow et IPFIX. Quelle est donc la différence entre eux ?

Imaginez que vous avez décidé de lire le livre “Security Operations Center: Building, Operating, and Maintaining your SOC” de mes collègues — Gary McIntyre, Joseph Muniz et Nadeem AlFardan (vous pouvez télécharger un extrait du livre en suivant ce lien). Vous avez trois options pour atteindre cet objectif : lire le livre dans son intégralité, le parcourir rapidement en s'arrêtant à chaque 10ème ou 20ème page, ou essayer de trouver un résumé des concepts clés sur un blog ou un service comme SmartReading. Ainsi, la télémétrie non échantillonnée correspond à la lecture de chaque “page” du trafic réseau, c'est-à-dire l'analyse des métadonnées pour chaque paquet. La télémétrie échantillonnée consiste à étudier de manière sélective le trafic dans l'espoir que les échantillons choisis contiennent ce dont vous avez besoin. En fonction de la vitesse de la connexion, la télémétrie échantillonnée renvoie pour analyse chaque 64ème, 200ème, 500ème, 1000ème, 2000ème ou même 10000ème paquet.

Dans le contexte de la surveillance de la cybersécurité, cela signifie que la télémétrie échantillonnée est bien adaptée pour détecter les attaques DDoS, les scans, la propagation de malwares, mais peut manquer des attaques atomiques ou multipartites qui n'ont pas été incluses dans l'échantillon envoyé pour analyse. La télémétrie non échantillonnée n'a pas de telles limitations et permet une détection d'un plus large éventail d'attaques. Voici une petite liste d'événements pouvant être détectés à l'aide des outils d'analyse de télémétrie réseau.

Bien sûr, un analyseur Netflow open source ne vous le permettra pas, car sa tâche principale est de collecter la télémétrie et d'effectuer une analyse de base du point de vue informatique. Pour détecter des menaces en matière de cybersécurité à partir des flux, il est nécessaire d'équiper l'analyseur de divers moteurs et algorithmes qui identifieront les problèmes de cybersécurité en se basant sur des champs standards ou personnalisés de Netflow, en enrichissant les données standards avec des informations provenant de diverses sources de Threat Intelligence, etc.

Par conséquent, si vous avez le choix, privilégiez Netflow ou IPFIX. Mais même si votre équipement ne fonctionne qu'avec sFlow, comme c'est le cas pour certains fabricants nationaux, vous pouvez tout de même en tirer un avantage en matière de sécurité.

L'été 2019, j'ai analysé les capacités des fabricants russes de matériel réseau, et tous, à l'exception de NSG, Poligon et Kraftway, ont déclaré prendre en charge sFlow (au minimum, Zelax, Natex, Eltex, QTech, Rusteletech).

La question suivante qui se posera à vous est : où intégrer la prise en charge des flux pour des raisons de sécurité ? En réalité, la question est mal posée. Sur les équipements modernes, la prise en charge des protocoles de flux est presque toujours présente. Donc, je reformulerais la question : où est-il le plus efficace de collecter la télémétrie du point de vue de la sécurité ? La réponse est assez évidente : au niveau des points d'accès, où vous verrez 100 % de tout le trafic, où vous aurez des informations détaillées sur les hôtes (adresse MAC, VLAN, ID d'interface), où vous pourrez suivre même le trafic P2P entre les hôtes, ce qui est critique pour la détection de l'exploration de réseau et de la propagation de logiciels malveillants. Au niveau du noyau, une partie du trafic peut ne pas être visible, et au niveau de la périmètre, vous ne verrez sans doute qu'un quart de tout votre trafic réseau. Mais si, pour une raison quelconque, des appareils non autorisés se sont installés sur votre réseau, permettant aux attaquants de « entrer et sortir », en contournant le périmètre, l'analyse de la télémétrie de ceux-ci ne vous sera d'aucune utilité. Par conséquent, pour une couverture maximale, il est recommandé d'activer la collecte de télémétrie précisément au niveau des points d'accès. Il convient également de noter que, même si nous parlons de virtualisation ou de conteneurs, les commutateurs virtuels modernes prennent également souvent en charge les flux, ce qui permet de contrôler le trafic là-bas.

Mais puisque j'ai lancé le sujet, il faut répondre à la question : que faire si l'équipement, physique ou virtuel, ne prend pas en charge les protocoles de flux ? Ou si son activation est interdite (par exemple, dans des segments industriels pour assurer la fiabilité) ? Ou si son activation entraîne une forte charge sur le processeur central (ce qui arrive sur du matériel obsolète) ? Pour répondre à ce besoin, il existe des capteurs virtuels spécialisés (flow sensor), qui sont en réalité des commutateurs ordinaires, laissant passer le trafic et le transposant sous forme de flux vers le module de collecte. Cependant, dans ce cas, nous nous heurtons à toute une série de problèmes que nous avons évoqués ci-dessus en ce qui concerne les outils de capture de paquets. Autrement dit, il faut comprendre non seulement les avantages de la technologie d'analyse des flux, mais aussi ses limitations.

Un autre point important à retenir lorsqu'on parle des outils d'analyse des flux. Si pour les outils classiques de génération d'événements de sécurité, nous appliquons la métrique EPS (événements par seconde), pour l'analyse de la télémétrie, cette métrique n'est pas applicable ; elle est remplacée par le FPS (flux par seconde). Comme pour l'EPS, il n'est pas possible de calculer à l'avance ce chiffre, mais on peut estimer le nombre approximatif de flux générés par un appareil en fonction de sa tâche. Sur Internet, vous pouvez trouver des tableaux avec des valeurs approximatives pour différents types d'appareils d'entreprise et de conditions, ce qui vous permettra d'estimer les licences dont vous avez besoin pour les outils d'analyse et quelle sera leur architecture. En effet, le capteur IDS est limité par une certaine capacité de bande passante qu'il peut exploiter, j'ai déjà mentionné le nombre de nos collecteurs - ils sont 21. Et cela pour un réseau réparti sur cinq continents et comptant environ un demi-million d'appareils actifs.

Comme système de surveillance Netflow, nous utilisons notre propre solution Cisco Stealthwatch, qui est spécialement orienté vers la résolution des problèmes de sécurité. Il dispose de nombreux moteurs intégrés de détection d'activités anormales, suspectes et clairement malveillantes, permettant de détecter un large éventail de menaces différentes — du cryptominage aux fuites d'informations, de la propagation de logiciels malveillants aux fraudes. Comme la plupart des analyseurs de flux, Stealthwatch est construit selon un schéma à trois niveaux (générateur — collecteur — analyseur), mais il est complété par plusieurs caractéristiques intéressantes qui sont importantes dans le contexte considéré. Premièrement, il s'intègre à des solutions de capture de paquets (comme le Cisco Security Packet Analyzer), ce qui permet d'enregistrer des sessions réseau sélectionnées pour une enquête et une analyse approfondies. Deuxièmement, spécialement pour étendre les tâches de sécurité, nous avons développé un protocole spécial nvzFlow, qui permet de

Il est évident qu’en parlant des systèmes d’analyse Netflow sous l’angle de la sécurité, le marché n’est pas limité à une seule solution de Cisco. Vous pouvez utiliser des solutions tant commerciales que gratuites ou semi-gratuites. Il est un peu étrange que je mentionne les solutions de la concurrence dans le blog de Cisco, donc je vais dire quelques mots sur la manière dont la télémétrie réseau peut être analysée à l’aide de deux outils populaires, dont les noms sont similaires, mais qui restent néanmoins différents — SiLK et ELK.

SiLK est un ensemble d'outils (le Système pour la Connaissance au Niveau d'Internet) pour analyser le trafic, développé par le CERT/CC américain. Dans le contexte de cet article, il prend en charge Netflow (versions 5 et 9, les plus populaires), IPFIX et sFlow, et utilise divers utilitaires (rwfilter, rwcount, rwflowpack, etc.) pour effectuer diverses opérations sur la télémétrie réseau afin de détecter des anomalies. Cependant, il est important de noter quelques points clés. SiLK est un outil en ligne de commande, et pour l'analyse opérationnelle, il faut sans cesse entrer des commandes, comme (détection des paquets ICMP de plus de 200 octets) :

rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15

ce qui n'est pas très pratique. Vous pouvez utiliser l'interface graphique iSiLK, mais cela ne va pas vraiment faciliter votre travail, ne remplissant que la fonction de visualisation, et non celle de substitution à l'analyste. C'est un second point. Contrairement aux solutions commerciales qui intègrent déjà une solide base analytique, des algorithmes de détection d'anomalies, des workflows adaptés, etc., avec SiLK, vous devrez tout faire vous-même, ce qui nécessitera des compétences différentes de celles attendues d'un outil déjà prêt à l'emploi. Ce n'est ni bon ni mauvais — c'est une caractéristique de pratiquement tout outil gratuit qui suppose que vous savez ce que vous faites, et qu'il vous aide dans cette tâche (les outils commerciaux dépendent moins des compétences de leurs utilisateurs, tout en supposant que les analystes comprennent au moins les bases des enquêtes réseau et du monitoring). Mais revenons à SiLK. Le cycle de travail d'un analyste avec cet outil se décompose comme suit :

Formulation de l'hypothèse. Nous devons comprendre ce que nous allons chercher dans la télémétrie réseau, connaître les attributs uniques par lesquels nous allons détecter certaines anomalies ou menaces.
Construction du modèle. Après avoir formulé l'hypothèse, nous la programmons à l'aide de Python, Shell ou d'autres outils non inclus dans SiLK.
Test. Vient le moment de vérifier la validité de notre hypothèse, qui sera confirmée ou infirmée à l'aide des utilitaires SiLK, tels que ceux commençant par 'rw', 'set', 'bag'.
Analyse des données réelles. En exploitation industrielle, SiLK nous aide à identifier des éléments, et l'analyste doit répondre aux questions suivantes : « Avons-nous trouvé ce que nous attendions ? », « Cela correspond-il à notre hypothèse ? », « Comment réduire le nombre de faux positifs ? », « Comment améliorer le taux de reconnaissance ? », etc.
Amélioration. À la dernière étape, nous améliorons le travail effectué précédemment : nous créons des modèles, optimisons le code, reformulons et clarifions l'hypothèse, et plus encore.

Ce cycle s'appliquera également à Cisco Stealthwatch, mais ce dernier maximise l'automatisation de ces cinq étapes, réduisant ainsi les erreurs de l'analyste et améliorant la rapidité de détection des incidents. Par exemple, dans SiLK, vous pouvez enrichir les statistiques réseau avec des données externes sur les IP malveillantes à l'aide de scripts que vous avez écrits vous-même, tandis que dans Cisco Stealthwatch, il s'agit d'une fonction intégrée qui vous alerte immédiatement en cas d'interaction dans le trafic réseau avec des adresses IP figurant sur une liste noire.

Si l'on monte dans la pyramide « des coûts » des logiciels d'analyse de flux, le SiLK totalement gratuit est suivi de l'ELK conditionnellement gratuit, qui se compose de trois composants clés : Elasticsearch (indexation, recherche et analyse des données), Logstash (entrées/sorties de données) et Kibana (visualisation). Contrairement à SiLK, où tout doit être écrit manuellement, l'ELK dispose déjà de nombreuses bibliothèques/modules prêts à l'emploi (certains payants, d'autres non) qui automatisent l'analyse de la télémétrie réseau. Par exemple, le filtre GeoIP dans Logstash permet d'associer les adresses IP observées à leur emplacement géographique (c'est une fonction intégrée dans Stealthwatch).

L'ELK dispose également d'une grande communauté qui développe des composants manquants pour cette solution de surveillance. Par exemple, pour travailler avec Netflow, IPFIX et sFlow, vous pouvez utiliser le module elastiflow, si le module Logstash Netflow ne vous convient pas, car il ne prend en charge que Netflow.

Bien qu'il offre plus de rapidité pour la collecte et la recherche de flux, l'ELK ne dispose actuellement pas d'une richesse d'analytique intégrée pour la détection d'anomalies et de menaces dans la télémétrie réseau. En suivant le cycle de vie décrit ci-dessus, vous devrez donc décrire vous-même des modèles de déviations et les utiliser dans le système de production (il n'existe pas de modèles intégrés).

Il existe bien sûr des extensions plus avancées pour ELK, qui intègrent déjà certains modèles de détection des anomalies dans la télémétrie réseau, mais ces extensions sont payantes et la question se pose alors de savoir s'il vaut vraiment la peine de créer un modèle similaire soi-même, d'acheter sa mise en œuvre pour son outil de surveillance, ou d'opter pour une solution clé en main de type Analyse du Trafic Réseau.

Je ne veux pas vraiment entrer dans le débat sur ce qu'il est préférable de faire : dépenser de l'argent pour acheter une solution prête à l'emploi pour le suivi des anomalies et des menaces dans la télémétrie réseau (par exemple, Cisco Stealthwatch) ou se débrouiller seul et adapter des outils comme SiLK, ELK, nfdump ou OSU Flow Tools (je parle des deux derniers cités dans cette phrase). a raconté Chacun fait ses choix et a ses propres motivations pour opter pour l'une ou l'autre des deux options. Je voulais simplement montrer que la télémétrie réseau est un outil très important pour assurer la sécurité réseau de sa propre infrastructure et qu'il ne faut pas la négliger, afin de ne pas rejoindre la liste des entreprises dont le nom est mentionné dans les médias avec des épithètes telles que « piratée », « ne respectant pas les exigences en matière de sécurité de l'information », « ne se préoccupant pas de la sécurité de ses données et des données de ses clients ».

En résumé, j'aimerais énumérer les conseils clés à suivre lors de la mise en place d'une surveillance de la sécurité de votre infrastructure interne :

Ne vous limitez pas uniquement au périmètre ! Utilisez (et choisissez) votre infrastructure réseau non seulement pour transmettre le trafic d'un point A à un point B, mais aussi pour traiter les questions de cybersécurité.
Étudiez les mécanismes existants de surveillance de la sécurité de l'information dans votre matériel réseau et intégrez-les.
Pour la surveillance interne, privilégiez l'analyse de la télémétrie — elle permet de détecter jusqu'à 80-90 % de tous les incidents de sécurité réseau, tout en accomplissant ce qui est impossible lors de la capture des paquets réseau et en économisant de l'espace de stockage pour tous les événements de sécurité.
Pour la surveillance des flux, utilisez Netflow v9 ou IPFIX – ils fournissent plus d'informations dans le contexte de la sécurité et permettent de surveiller non seulement l'IPv4, mais aussi l'IPv6, MPLS, etc.
Utilisez un protocole de flux non échantillonné – il fournit plus d'informations pour la détection des menaces. Par exemple, Netflow ou IPFIX.
Vérifiez le chargement de votre équipement réseau : peut-être qu'il ne peut pas traiter le protocole de flux. Dans ce cas, envisagez d'utiliser des capteurs virtuels ou un dispositif de génération de Netflow.
Mettez en œuvre le contrôle principalement au niveau de l'accès – cela vous permettra de voir 100 % de tout le trafic.
Si vous n'avez pas le choix et que vous utilisez un équipement réseau russe, choisissez celui qui prend en charge les protocoles de flux ou qui dispose de ports SPAN/RSPAN.
Combinez les systèmes de détection/prévention d'intrusions en périphérie et les systèmes d'analyse de flux dans le réseau interne (y compris dans le cloud).

En ce qui concerne le dernier conseil, je voudrais donner une illustration que j'ai déjà utilisée auparavant. Vous voyez que si auparavant le service de sécurité Cisco construisait presque entièrement son système de surveillance de la sécurité basé sur des systèmes de détection d'intrusion et des méthodes par signature, maintenant cela ne représente plus que 20 % des incidents. Un autre 20 % est attribué aux systèmes d'analyse de flux, ce qui indique que ces solutions ne sont pas un luxe, mais un outil réel dans l'activité des services de sécurité des entreprises modernes. D'autant plus que vous avez ce qu'il faut pour leur mise en œuvre : l'infrastructure réseau, dont vous pouvez également protéger les investissements en lui confiant des fonctions de surveillance de la sécurité.

Je n'ai pas abordé le sujet de la réponse aux anomalies ou menaces détectées dans les flux réseau, mais je pense qu'il est clair que la surveillance ne doit pas s'arrêter à la seule détection de la menace. Il doit y avoir une réponse, de préférence de manière automatique ou automatisée. Mais c'est déjà le sujet d'un autre article.

Informations complémentaires :

PS. Si vous préférez entendre tout ce qui a été écrit ci-dessus, vous pouvez regarder une présentation d'une heure qui a servi de base à cet article.

Source : habr.com

Les protocoles de flux comme outil de surveillance de la sécurité du réseau interne