Lorsqu'il s'agit de surveiller la sécurité d'un réseau interne d'entreprise ou départemental, beaucoup sont associés au contrôle des fuites d'informations et à la mise en œuvre de solutions DLP. Et si vous essayez de clarifier la question et demandez comment vous détectez les attaques sur le réseau interne, la réponse sera généralement la mention des systèmes de détection d'intrusion (IDS). Et quelle était la seule option il y a 10 à 20 ans, est aujourd'hui en train de devenir un anachronisme. Il existe une option plus efficace et, à certains endroits, la seule possible pour surveiller le réseau interne - utiliser des protocoles de flux, initialement conçus pour rechercher des problèmes de réseau (dépannage), mais finalement transformés en un outil de sécurité très intéressant. Nous parlerons de ce que sont les protocoles de flux et de ceux qui aident à mieux détecter les attaques réseau, où il est préférable de mettre en œuvre la surveillance des flux, ce qu'il faut rechercher lors du déploiement d'un tel schéma et même comment «le récupérer» sur les équipements domestiques. dans le cadre de cet article.
Je ne m'attarderai pas sur la question «Pourquoi devons-nous surveiller la sécurité des infrastructures internes?» La réponse semble claire. Mais si, néanmoins, vous souhaitez vous assurer une fois de plus qu'il n'y a rien sans,
regardez une courte vidéo avec une histoire sur la façon dont vous pouvez entrer dans le réseau d'entreprise protégé par un pare-feu de 17 façons. Par conséquent, nous supposerons que nous comprenons que le suivi interne est une chose nécessaire et qu'il ne reste plus qu'à comprendre comment il peut être organisé.
Je citerais trois sources de données clés pour surveiller l'infrastructure au niveau du réseau:
- Trafic «brut», que nous capturons et soumettons à l'analyse pour certains systèmes d'analyse,
- les événements des périphériques réseau à travers lesquels le trafic passe,
- informations de trafic reçues à l'aide de l'un des protocoles de flux.
La capture du trafic brut est l'option la plus populaire parmi les agents de sécurité, car elle est apparue historiquement la toute première. Les systèmes conventionnels de détection d'attaque basés sur le réseau (le tout premier système commercial de détection d'attaque était le NetRanger de WheelR, acheté en 1998 par Cisco) se contentaient de capturer des paquets (et des sessions ultérieures) qui recherchaient des signatures spécifiques («règles décisives» dans la terminologie FSTEC), signalisation des attaques. Bien sûr, vous pouvez analyser le trafic brut non seulement à l'aide d'IDS, mais également à l'aide d'autres outils (par exemple, la fonctionnalité Wireshark, tcpdum ou NBAR2 dans Cisco IOS), mais ils manquent généralement d'une base de connaissances qui distingue un outil de sécurité des informations d'un outil informatique classique.
Donc, les systèmes de détection d'attaque. La méthode la plus ancienne et la plus populaire de détection des attaques de réseau, qui remplit bien sa tâche sur le périmètre (peu importe l'entreprise, le centre de données, le segment, etc.), mais qui passe dans les réseaux modernes d'accès à distance et définis par logiciel. Dans le cas d'un réseau construit sur la base de commutateurs classiques, l'infrastructure des capteurs de détection d'attaque devient trop grande - vous devrez mettre un capteur sur chaque connexion avec l'hôte dont vous souhaitez surveiller les attaques. Tout fabricant, bien sûr, sera heureux de vous vendre des centaines et des milliers de capteurs, mais je pense que votre budget ne peut pas supporter de tels coûts. Je peux dire que même chez Cisco (et nous sommes les développeurs de NGIPS), nous n'avons pas pu le faire, bien qu'il semble que le problème de prix soit devant nous. ne devrait pas rester - c'est notre propre décision. De plus, la question se pose, mais comment connecter le capteur dans ce mode de réalisation? À l'écart? Et si le capteur lui-même est désactivé? Besoin d'un module de dérivation dans le capteur? Utilisez des séparateurs de prises? Tout cela rend la solution plus chère et la rend insupportable pour une entreprise de toute taille.
Vous pouvez essayer de «suspendre» le capteur sur le port SPAN / RSPAN / ERSPAN et de diriger le trafic vers celui-ci à partir des ports nécessaires sur le commutateur. Cette option supprime partiellement le problème décrit dans le paragraphe précédent, mais en pose un autre - le port SPAN ne peut accepter absolument tout le trafic qui lui sera envoyé - il n'aura pas assez de bande passante. Blottissez-vous quelque chose à sacrifier. Soit laisser une partie des nœuds sans surveillance (alors vous devez d'abord les hiérarchiser), soit acheminer tout le trafic à partir du nœud, mais uniquement un certain type. Dans tous les cas, nous pouvons ignorer certaines attaques. De plus, le port SPAN peut être occupé pour d'autres besoins. Par conséquent, nous devrons réviser la topologie de réseau existante et éventuellement y apporter des ajustements pour couvrir votre réseau au maximum avec le nombre de capteurs dont vous disposez (et coordonner cela avec le service informatique).
Et si votre réseau utilise des routes asymétriques? Et si vous avez mis en œuvre ou prévoyez d'introduire SDN? Et si vous devez surveiller des machines ou conteneurs virtualisés dont le trafic n'atteint pas du tout le commutateur physique? Les fabricants d'IDS traditionnels n'aiment pas ces questions car ils ne savent pas comment y répondre. Peut-être qu'ils vous inclineront au fait que toutes ces technologies à la mode sont hype et que vous n'en avez pas besoin. Peut-être parleront-ils de la nécessité de commencer petit. Ou peut-être qu'ils diront que vous devez placer une batteuse puissante au centre du réseau et y diriger tout le trafic à l'aide d'équilibreurs. Quelle que soit l'option qui vous est proposée, vous devez comprendre clairement par vous-même à quel point elle vous convient. Et ce n'est qu'après cela que vous déciderez de choisir une approche pour surveiller la sécurité des informations de l'infrastructure réseau. Revenant à la capture de paquets, je tiens à dire que cette méthode continue d'être très populaire et importante, mais son objectif 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 l'ICS et le segment d'entreprise. Dans ces endroits, les IDS / IPS classiques ont toujours le droit d'exister et de bien s'acquitter de leurs tâches.
Passons à la deuxième option. Une analyse des événements des périphériques réseau peut également être utilisée pour détecter les attaques, mais pas comme mécanisme principal, car elle vous permet de détecter uniquement une petite classe d'intrusions. De plus, une certaine réactivité lui est inhérente - une attaque doit d'abord se produire, puis elle doit être corrigée par un périphérique réseau, qui d'une manière ou d'une autre signalera un problème de sécurité de l'information. Il y a plusieurs façons. Il peut s'agir de syslog, RMON ou SNMP. Les deux derniers protocoles de surveillance du réseau dans le contexte de la sécurité des informations ne sont utilisés que si nous devons détecter une attaque DoS sur l'équipement réseau lui-même, car en utilisant RMON et SNMP, par exemple, nous pouvons surveiller la charge du processeur central de l'appareil ou de ses interfaces. C'est l'une des «moins chères» (tout le monde a Syslog ou SNMP), mais aussi la plus inefficace de toutes les façons de surveiller la sécurité des informations de l'infrastructure interne - de nombreuses attaques lui sont tout simplement cachées. Bien sûr, ils ne doivent pas être négligés et la même analyse syslog vous aide à identifier les changements dans la configuration de l'appareil en temps opportun, c'est un compromis, mais il n'est pas très approprié pour détecter des attaques sur l'ensemble du réseau.
La troisième option consiste à analyser les informations sur le trafic passant par un périphérique prenant en charge l'un des protocoles de flux. Dans ce cas, quel que soit le protocole, l'infrastructure de flux se compose nécessairement de trois composants:
- Générez ou exportez le flux. Ce rôle est généralement attribué à un routeur, un commutateur ou un autre périphérique réseau qui, en passant le trafic réseau à travers lui-même, vous permet d'en extraire les paramètres clés, qui sont ensuite transférés vers le module de collecte. Par exemple, le protocole Cisco Netflow est pris en charge non seulement sur les routeurs et commutateurs, y compris virtuels et industriels, mais également sur les contrôleurs sans fil, les pare-feu et même les serveurs.
- Flux de collecte. Étant donné que dans un réseau moderne il y a généralement plus d'un périphérique réseau, la tâche de collecte et de consolidation des flux se pose, qui est résolue à l'aide des soi-disant collecteurs, qui traitent les flux reçus et les transmettent ensuite pour analyse.
- Analyse de flux. L'analyseur assume la principale tâche intellectuelle et, en appliquant divers algorithmes aux flux, tire certaines conclusions. Par exemple, dans le cadre de la fonction informatique, un tel analyseur peut identifier les goulots d'étranglement du réseau ou analyser le profil de charge de trafic pour optimiser davantage le réseau. Et pour la sécurité de l'information, un tel analyseur peut détecter les fuites de données, la propagation de code malveillant ou les attaques DoS.
Vous ne devriez pas penser qu'une telle architecture à trois niveaux est trop compliquée - toutes les autres options (sauf, peut-être, les systèmes de surveillance de réseau qui fonctionnent avec SNMP et RMON) fonctionnent également en fonction de cela. Nous avons un générateur de données pour l'analyse, qui est un périphérique réseau ou un capteur autonome. Nous avons un système de collecte d'alarmes et nous avons un système de gestion pour l'ensemble de l'infrastructure de surveillance. Les deux derniers composants peuvent être combinés au sein d'un même nœud, mais dans des réseaux plus ou moins grands, ils sont généralement séparés par au moins deux appareils afin de garantir l'évolutivité et la fiabilité.
Contrairement à l'analyse de paquets, basée sur l'étude de l'en-tête et du corps de données de chaque paquet et des sessions qui les composent, l'analyse de flux repose sur la collecte de métadonnées sur le trafic réseau. Quand, combien, où et où, comment ... ce sont les questions auxquelles répond l'analyse de la télémétrie réseau à l'aide de différents protocoles de flux. Initialement, ils ont été utilisés pour analyser les statistiques et rechercher les problèmes informatiques dans le réseau, mais avec le développement de mécanismes analytiques, il est devenu possible de les appliquer à la même télémétrie et à des fins de sécurité. Il convient de mentionner ici encore que l'analyse de flux ne remplace ni n'annule la capture de paquets. Chacune de ces méthodes a son propre champ d'application. Mais dans le contexte de cet article, c'est l'analyse de flux qui convient le mieux pour surveiller l'infrastructure interne. Vous avez des périphériques réseau (et peu importe s'ils fonctionnent dans un paradigme défini par logiciel ou selon des règles statiques) que l'attaque ne peut pas passer. Il peut contourner le capteur IDS classique, mais aucun périphérique réseau ne prend en charge le protocole de flux. C'est l'avantage de cette méthode.
D'un autre côté, si vous avez besoin de preuves pour l'application de la loi ou de votre propre équipe d'enquête sur les incidents, vous ne pouvez pas vous passer de la capture de paquets - la télémétrie réseau n'est pas une copie du trafic qui peut être utilisée pour collecter des preuves; il est nécessaire pour la détection opérationnelle et la prise de décision dans le domaine de la sécurité de l'information. D'un autre côté, en utilisant l'analyse de télémétrie, vous pouvez «écrire» non pas tout le trafic réseau (le cas échéant, alors Cisco est impliqué dans les centres de données :-), mais uniquement celui qui est impliqué dans l'attaque. À cet égard, les outils d'analyse de télémétrie compléteront bien les mécanismes traditionnels de capture de paquets, en donnant la commande de capture et de stockage sélectifs. Sinon, vous devez disposer d'une infrastructure de stockage colossale.
Imaginez un réseau fonctionnant à une vitesse de 250 Mbps. Si vous souhaitez enregistrer tout ce volume, vous aurez besoin de 31 Mo de stockage pour une seconde de transfert de trafic, 1,8 Go pour une minute, 108 Go pour une heure et 2,6 To pour une journée. Pour stocker des données quotidiennes à partir d'un réseau avec une bande passante de 10 Gbit / s, vous avez besoin de 108 To de stockage. Mais certains régulateurs vous obligent à stocker des données de sécurité pendant des années ... L'enregistrement «à la demande», qui vous aide à mettre en œuvre l'analyse de flux, permet de réduire ces valeurs par ordre de grandeur. Soit dit en passant, si nous parlons du rapport entre le volume enregistré de données de télémétrie réseau et la capture totale de données, alors il est d'environ 1 à 500. Pour les mêmes valeurs ci-dessus, le stockage du déchiffrement complet de tout le trafic quotidien sera respectivement de 5 et 216 Go (vous pouvez même écrire sur une clé USB standard )
Si les outils d'analyse des données réseau brutes ont une méthode de capture qui est presque la même que celle du fournisseur au fournisseur, la situation est différente avec l'analyse des flux. Il existe plusieurs options pour les protocoles de flux, les différences que vous devez connaître dans le contexte de sécurité. Le plus populaire est le protocole Netflow développé par Cisco. Il existe plusieurs versions de ce protocole qui diffèrent par leurs capacités et la quantité d'informations enregistrées sur le trafic. La version actuelle est la neuvième (Netflow v9), sur la base de laquelle la norme industrielle Netflow v10, également connue sous le nom d'IPFIX, a été développée. Aujourd'hui, la plupart des fournisseurs de réseau prennent en charge exactement Netflow ou IPFIX dans leur équipement. Mais il existe diverses autres options pour les protocoles de flux - sFlow, jFlow, cFlow, rFlow, NetStream, etc., dont sFlow est plus populaire. C'est lui qui est le plus souvent soutenu par les fabricants nationaux d'équipements de réseau en raison de la facilité de mise en œuvre. Quelles sont les principales différences entre Netflow, en tant que norme de facto, et sFlow? J'en citerais quelques-uns clés. Premièrement, Netflow a des champs définis par l'utilisateur par opposition aux champs fixes dans sFlow. Et deuxièmement, et c'est la chose la plus importante dans notre cas, sFlow collecte la soi-disant télémétrie échantillonnée; contrairement à non échantillonné dans Netflow et IPFIX. Quelle est la différence entre eux?
Imaginez que vous ayez décidé de lire le livre «
Security Operations Center: Building, Operating, and Maintaining your SOC » de mes collègues - Gary MacIntyre, Joseph Muniz et Nadef Alfardan (vous pouvez télécharger une partie du livre à partir du lien). Vous avez trois options pour atteindre votre objectif: lire l'intégralité du livre, le parcourir avec les yeux, vous arrêter sur chaque 10e ou 20e page, ou essayer de trouver une nouvelle version des concepts clés dans un blog ou un service tel que SmartReading. La télémétrie non échantillonnée lit donc chaque «page» du trafic réseau, c'est-à -dire analyse les métadonnées de chaque paquet. La télémétrie d'échantillonnage est une étude sélective du trafic dans l'espoir que les échantillons sélectionnés auront ce dont vous avez besoin. Selon la vitesse du canal, la télémétrie échantillonnée enverra pour analyse tous les 64e, 200e, 500e, 1000e, 2000e ou même 10000e paquets.
Dans le contexte de la surveillance de la sécurité des informations, cela signifie que la télémétrie échantillonnée est bien adaptée pour détecter les attaques DDoS, l'analyse et la diffusion de code malveillant, mais elle peut ignorer les attaques atomiques ou multi-paquets qui ne tombent pas dans l'échantillon envoyé pour analyse. La télémétrie non échantillonnée ne présente pas de telles lacunes. L'utilisation de la gamme d'attaques détectables est beaucoup plus large. Voici une courte liste d'événements qui peuvent être détectés à l'aide des outils d'analyse de télémétrie réseau.
Bien sûr, certains analyseurs Netflow open source ne vous permettront pas de le faire, car sa tâche principale est de collecter la télémétrie et d'effectuer une analyse de base à ce sujet d'un point de vue informatique. Pour identifier les menaces de sécurité des informations en fonction du flux, il est nécessaire d'équiper l'analyseur de différents moteurs et algorithmes, qui identifieront les problèmes de cybersécurité sur la base de champs Netflow standard ou personnalisés, enrichiront les données standard avec des données externes provenant de diverses sources de Threat Intelligence, etc.
Par conséquent, si vous avez le choix, arrêtez-le sur Netflow ou IPFIX. Mais même si votre équipement ne fonctionne qu'avec sFlow, comme les fabricants nationaux, même dans ce cas, vous pouvez en bénéficier dans le contexte de la sécurité.
Au cours de l'été 2019, j'ai analysé les opportunités qu'offrent les fabricants russes de matériel en réseau, et tous, à l'exception de NSG, Polygon et Craftway, ont déclaré la prise en charge de sFlow (au moins Zelax, Natex, Eltex, QTech, Rusteletech).
La prochaine question à laquelle vous serez confronté est de savoir où implémenter le support de flux à des fins de sécurité? En fait, la question n'est pas entièrement correcte. Sur les équipements modernes, la prise en charge des protocoles de flux est presque toujours présente. Par conséquent, je reformulerais la question différemment: quel est le moyen le plus efficace de collecter la télémétrie d'un point de vue de la sécurité? La réponse sera assez évidente - au niveau de l'accès, où vous verrez 100% de tout le trafic, où vous aurez des informations détaillées sur les hôtes (MAC, VLAN, ID d'interface), où vous pourrez même suivre le trafic P2P entre les hôtes, ce qui est essentiel pour détecter les analyses et et la propagation de code malveillant. Au niveau du noyau, vous pouvez ne pas voir une partie du trafic, mais au niveau du périmètre, vous verrez bien si un quart de tout votre trafic réseau. Mais si, pour une raison quelconque, des périphériques étrangers sont bloqués sur votre réseau qui permettent aux attaquants «d'entrer et de sortir», en contournant le périmètre, l'analyse de la télémétrie à partir de celui-ci ne vous donnera rien. Par conséquent, pour une couverture maximale, il est recommandé d'inclure la collecte de télémétrie au niveau d'accès. Dans le même temps, il convient de noter que même si nous parlons de virtualisation ou de conteneurs, dans les commutateurs virtuels modernes, la prise en charge du flux est également souvent trouvée, ce qui vous permet de contrôler le trafic là -bas.
Mais depuis que j'ai soulevé le sujet, je dois répondre à la question, mais que se passe-t-il si, après tout, l'équipement, physique ou virtuel, ne prend pas en charge les protocoles de flux? Ou son inclusion est-elle interdite (par exemple, dans les segments industriels pour garantir la fiabilité)? Ou son inclusion conduit à une utilisation élevée du processeur (cela se produit sur des équipements obsolètes)? Pour résoudre ce problème, il existe des capteurs virtuels spécialisés (capteur de débit), qui sont essentiellement des répartiteurs ordinaires qui transitent par eux-mêmes et le transmettent sous forme de flux au module de collecte. Certes, dans ce cas, nous obtenons tout un tas de problèmes dont nous avons parlé ci-dessus en ce qui concerne les outils de capture de paquets. Autrement dit, vous devez comprendre non seulement les avantages de la technologie d'analyse de flux, mais également ses limites.
Un autre point important à retenir lorsque l'on parle d'outils d'analyse de flux. Si nous appliquons la métrique EPS (événement par seconde, événements par seconde) aux moyens conventionnels de générer des événements de sécurité, alors cet indicateur ne s'applique pas à l'analyse de télémétrie; il est remplacé par FPS (débit par seconde). Comme dans le cas de l'EPS, il ne peut pas être calculé à l'avance, mais vous pouvez estimer le nombre approximatif de flux qu'un appareil particulier génère en fonction de sa tâche. Sur Internet, vous pouvez trouver des tableaux avec des valeurs approximatives pour différents types d'appareils et conditions d'entreprise, qui vous permettront de déterminer de quelles licences vous avez besoin pour les outils d'analyse et quelle sera leur architecture? Le fait est que le capteur IDS est limité par une certaine bande passante, qu'il "tirera", et le collecteur de flux a ses propres limites, qui doivent être comprises. Par conséquent, dans les grands réseaux géographiquement distribués, il y a généralement plusieurs réservoirs. Lorsque j'ai décrit
comment le réseau à l'intérieur de Cisco est surveillé , j'ai déjà cité le nombre de nos collecteurs - il y en a 21. Et cela se trouve sur un réseau dispersé sur les cinq continents et comptant environ un demi-million d'appareils actifs).
En tant que système de surveillance Netflow, nous utilisons notre propre
solution Cisco Stealthwatch , qui se concentre spécifiquement sur la résolution des problèmes de sécurité. Il dispose de nombreux moteurs intégrés pour détecter les activités anormales, suspectes et évidemment malveillantes, ce qui permet de détecter un large éventail de menaces diverses - du cryptage à la fuite d'informations, de la propagation de code malveillant à la fraude. 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 un certain nombre de fonctionnalités intéressantes qui sont importantes dans le contexte du matériau considéré. Tout d'abord, il s'intègre aux solutions de capture de paquets (telles que Cisco Security Packet Analyzer), ce qui vous permet d'enregistrer des sessions réseau sélectionnées pour une enquête et une analyse plus approfondies. Deuxièmement, en particulier pour étendre les tâches de sécurité, nous avons développé un protocole spécial nvzFlow, qui vous permet de "traduire" l'activité des applications sur les nœuds d'extrémité (serveurs, postes de travail, etc.) en télémétrie et de la transmettre au collecteur pour une analyse plus approfondie. Si, dans sa version d'origine, Stealthwatch fonctionne avec n'importe quel protocole de flux (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) au niveau du réseau, la prise en charge de nvzFlow permet également la corrélation des données au niveau de l'hôte. augmenter l'efficacité de l'ensemble du système et voir plus d'attaques que les analyseurs de flux de réseau conventionnels.
Il est clair qu'en parlant de systèmes d'analyse de sécurité Netflow, le marché ne se limite pas à une seule solution de Cisco. Vous pouvez utiliser à la fois des solutions commerciales et freeware ou shareware. Curieusement, si j'utilise le blog Cisco comme exemple de solutions concurrentes, je dirai quelques mots sur la façon dont la télémétrie réseau peut être analysée à l'aide de deux outils populaires, de nom similaire, mais toujours différents - SiLK et ELK.
SiLK est un ensemble d'outils (le System for Internet-Level Knowledge) pour l'analyse du trafic, développé par l'américain CERT / CC et qui prend en charge, dans le cadre de l'article d'aujourd'hui, Netflow (5e et 9e, les versions les plus populaires), IPFIX et sFlow et l'utilisation de divers utilitaires (rwfilter, rwcount, rwflowpack, etc.) pour effectuer diverses opérations sur la télémétrie réseau afin de détecter des signes d'actions non autorisées. Mais il y a quelques points importants à noter. SiLK est un outil en ligne de commande et effectue une analyse opérationnelle, tout le temps que vous entrez une commande du formulaire (détection des paquets ICMP supérieurs à 200 octets):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15pas très pratique. Vous pouvez utiliser l'interface graphique iSiLK, mais cela ne vous facilitera pas la vie en résolvant uniquement la fonction de visualisation, pas le remplacement de l'analyste. Et c'est le deuxième point. Contrairement aux solutions commerciales, qui ont déjà une base analytique solide, des algorithmes de détection d'anomalies, des algorithmes liés au workflow, etc., dans le cas de SiLK, vous devrez faire tout cela vous-même, ce qui vous obligera à utiliser des compétences légèrement différentes de celles que vous utilisez déjà des outils prêts à l'emploi. C'est mauvais et pas mal - c'est une caractéristique de presque n'importe quel outil gratuit qui vient du fait que vous savez quoi faire, et cela ne vous aidera que dans ce sens (les outils commerciaux dépendent moins des compétences de ses utilisateurs, bien qu'il suppose également que les analystes comprennent au moins bases des investigations et de la surveillance du réseau). Mais revenons à SiLK. Le cycle de travail de l'analyste avec lui est le suivant:
- Formulation d'une hypothèse. Nous devons comprendre ce que nous rechercherons dans la télémétrie réseau, pour connaître les attributs uniques par lesquels nous identifierons certaines anomalies ou menaces.
- Construire un modèle. Après avoir formulé une hypothèse, nous la programmons en utilisant le même Python, shell ou d'autres outils non inclus dans SiLK.
- Test. C'est au tour de tester la validité de notre hypothèse, qui est confirmée ou infirmée à l'aide des utilitaires SiLK commençant par «rw», «set», «bag».
- Analyse de données réelles. En exploitation industrielle, SiLK nous aide à identifier quelque chose et l'analyste doit répondre aux questions «Avons-nous trouvé ce que nous attendions?», «Est-ce que cela correspond à notre hypothèse?», «Comment réduire le nombre de faux positifs?», «Comment améliorer le niveau de reconnaissance? " etc.
- Amélioration. Au stade final, nous améliorons ce qui a été fait précédemment - créer des modèles, améliorer et optimiser le code, reformuler et affiner l'hypothèse, etc.
Ce cycle sera applicable à la même Cisco Stealthwatch, seules les cinq dernières étapes seront automatisées au maximum, réduisant le nombre d'erreurs d'analyste et augmentant la vitesse de détection des incidents. Par exemple, dans SiLK, vous pouvez enrichir les statistiques du réseau avec des données externes sur une IP malveillante à l'aide de vos propres scripts, et dans Cisco Stealthwatch, il s'agit d'une fonction intégrée qui affiche immédiatement une alarme en cas d'interaction avec des adresses IP de la liste noire dans le trafic réseau.
Si nous montons plus haut dans la pyramide «payante» pour les logiciels d'analyse de flux, alors SiLK absolument gratuit sera suivi par le shareware ELK, composé de trois composants clés - Elasticsearch (indexation, recherche et analyse de données), Logstash (entrée / sortie de données) et Kibana ( visualisation). Contrairement à SiLK, où vous devez tout écrire vous-même, ELK dispose déjà de nombreuses bibliothèques / modules prêts à l'emploi (certains sont payants, d'autres non) qui automatisent l'analyse de la télémétrie réseau. Par exemple, le filtre GeoIP dans Logstash vous permet de lier les adresses IP observées à leur emplacement géographique (pour Stealthwatch, il s'agit d'une fonction intégrée).
ELK possède également une communauté assez importante qui complète les composants manquants pour cette solution de surveillance. Par exemple, pour travailler avec Netflow, IPFIX et sFlow, vous pouvez utiliser le module
elastiflow si vous n'ĂŞtes pas Ă l'aise avec le module Logstash Netflow, qui ne prend en charge que Netflow.
Donnant plus d'efficacité dans la collecte de flux et la recherche dans celui-ci, ELK ne dispose pas actuellement de riches analyses intégrées pour détecter les anomalies et les menaces dans la télémétrie réseau. Autrement dit, en suivant le cycle de vie décrit ci-dessus, vous devrez décrire indépendamment le modèle des violations et ensuite l'utiliser dans le système de combat (il n'y a pas de modèles intégrés là -bas).
Bien sûr, il existe des extensions plus sophistiquées pour ELK qui contiennent déjà certains modèles pour détecter les anomalies dans la télémétrie réseau, mais ces extensions coûtent de l'argent et la question est de savoir si le jeu en vaut la chandelle - écrivez le même modèle vous-même, achetez son implémentation pour votre outil de surveillance ou achetez solution clé en main pour la classe Network Traffic Analysis.
En général, je ne veux pas entrer dans le débat qu'il vaut mieux dépenser de l'argent et acheter une solution clé en main pour surveiller les anomalies et les menaces dans la télémétrie réseau (par exemple, Cisco Stealthwatch) ou le comprendre par vous-même et faire tourner les mêmes outils de flux SiLK, ELK ou nfdump ou OSU (pour chaque nouvelle menace) ( J'ai parlé des deux derniers la dernière fois)? Chacun choisit pour lui-même et chacun a ses propres motivations pour choisir l'une des deux options. Je voulais juste montrer que la télémétrie réseau est un outil très important pour assurer la sécurité du réseau de votre infrastructure interne et vous ne devez pas la négliger pour ne pas reconstituer la liste de la société dont le nom est mentionné dans les médias ainsi que les épithètes «piratées», «qui ne respectaient pas les exigences de sécurité de l'information "," Ne pas penser à la sécurité de ses données et des données clients. "
Pour résumer, je voudrais énumérer les conseils clés que vous devez suivre lors de la création de la surveillance de la sécurité des informations de votre infrastructure interne:- Ne vous limitez pas seulement au périmètre! Utilisez (et choisissez) votre infrastructure réseau non seulement pour transférer le trafic d'un point A à un point B, mais aussi pour résoudre les problèmes de cybersécurité.
- Explorez les mécanismes de surveillance de la sécurité existants dans votre équipement réseau et déployez-les.
- Pour la surveillance interne, privilégiez l'analyse de télémétrie - elle vous permet de détecter jusqu'à 80 à 90% de tous les incidents de sécurité des informations, tout en faisant ce qui est impossible lors de la capture des paquets réseau et en économisant de l'espace pour stocker tous les événements de sécurité des informations.
- Pour surveiller les flux, utilisez Netflow v9 ou IPFIX - ils fournissent plus d'informations dans le contexte de sécurité et vous permettent de surveiller non seulement IPv4, mais aussi IPv6, MPLS, etc.
- flow- – . , Netflow IPFIX.
- – flow-. Netflow Generation Appliance.
- – 100% .
- , , flow- SPAN/RSPAN-.
- / / ( ).
Quant à la dernière astuce, je voudrais donner une illustration, que j'ai déjà citée plus tôt. Vous voyez que si auparavant le service Cisco IS avait presque entièrement construit son système de surveillance IS basé sur des systèmes de détection d'intrusion et des méthodes de signature, ils ne représentent désormais que 20% des incidents. Un autre 20% est représenté par les systèmes d'analyse de flux, ce qui suggère que ces solutions ne sont pas un caprice, mais un véritable outil dans l'activité des services de sécurité de l'information d'une entreprise moderne. De plus, vous avez la chose la plus importante pour leur mise en œuvre - l'infrastructure réseau, dont les investissements peuvent être protégés en plus en affectant également des fonctions de surveillance des SI au réseau.
Je n'ai pas délibérément abordé le sujet de la réponse aux anomalies ou menaces identifiées dans les flux réseau, mais je pense qu'il est déjà clair que la surveillance ne doit pas être complétée uniquement par la détection d'une menace. Elle doit être suivie d'une réponse et de préférence en mode automatique ou automatisé. Mais c'est le sujet d'un matériau séparé.Information complémentaire:Menace.
S'il vous est plus facile d'écouter tout ce qui a été écrit ci-dessus, vous pouvez regarder la présentation d'une heure qui a servi de base à cette note.