Lorsqu'il s'agit de surveiller la sécurité d'un réseau interne d'entreprise ou de service, beaucoup l'associent au contrôle des fuites d'informations et à la mise en œuvre de solutions DLP. Et si vous essayez de clarifier la question et de demander comment détecter les attaques sur le réseau interne, la réponse sera, en règle générale, une mention des systèmes de détection d'intrusion (IDS). Et ce qui était la seule option il y a 10 ou 20 ans devient aujourd’hui un anachronisme. Il existe une option plus efficace, et à certains endroits, la seule possible pour surveiller un réseau interne : l'utilisation de protocoles de flux, conçus à l'origine pour rechercher des problèmes de réseau (dépannage), mais transformés au fil du temps en un outil de sécurité très intéressant. Nous parlerons des protocoles de flux existants et de ceux qui sont les plus efficaces pour détecter les attaques de réseau, où il est préférable de mettre en œuvre la surveillance des flux, de ce qu'il faut rechercher lors du déploiement d'un tel système, et même de la manière de « lever » tout cela sur les équipements domestiques. dans le cadre de cet article.
Je ne m’attarderai pas sur la question « Pourquoi une surveillance de la sécurité des infrastructures internes est-elle nécessaire ? » La réponse semble claire. Mais si vous souhaitez néanmoins vous assurer une fois de plus qu’aujourd’hui vous ne pouvez plus vous en passer, une courte vidéo expliquant comment pénétrer de 17 manières dans un réseau d'entreprise protégé par un pare-feu. Par conséquent, nous supposerons que nous comprenons que le contrôle interne est une chose nécessaire et qu'il ne reste plus qu'à comprendre comment il peut être organisé.
Je voudrais souligner trois sources de données clés pour surveiller l'infrastructure au niveau du réseau :
- le trafic « brut » que nous captons et soumettons pour analyse à certains systèmes d'analyse,
- les événements provenant des périphériques réseau par lesquels passe le trafic,
- informations routières reçues via l'un des protocoles de flux.
La capture du trafic brut est l’option la plus populaire parmi les spécialistes de la sécurité, car elle est apparue historiquement et a été la toute première. Les systèmes conventionnels de détection d'intrusion sur les réseaux (le tout premier système de détection d'intrusion commercial était NetRanger du groupe Wheel, acheté en 1998 par Cisco) étaient précisément chargés de capturer des paquets (et des sessions ultérieures) dans lesquels certaines signatures étaient recherchées (« règles décisives » en anglais). 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, Wireshark, tcpdum ou la fonctionnalité NBAR2 dans Cisco IOS), mais ils manquent généralement de la base de connaissances qui distingue un outil de sécurité des informations d'un outil classique. Outil informatique.
Donc, les systèmes de détection d’attaques. La méthode la plus ancienne et la plus populaire de détection des attaques réseau, qui fait du bon travail au niveau du périmètre (quoi qu'il s'agisse d'une entreprise, d'un centre de données, d'un segment, etc.), mais échoue dans les réseaux modernes commutés et définis par logiciel. Dans le cas d'un réseau construit sur la base de commutateurs conventionnels, l'infrastructure de capteurs de détection d'attaques devient trop grande - vous devrez installer un capteur sur chaque connexion au nœud sur lequel vous souhaitez surveiller les attaques. Bien entendu, n'importe quel fabricant sera heureux de vous vendre des centaines et des milliers de capteurs, mais je pense que votre budget ne peut pas supporter de telles dépenses. Je peux dire que même chez Cisco (et nous sommes les développeurs de NGIPS), nous ne pourrions pas faire cela, même s'il semblerait que la question du prix soit devant nous. Je ne devrais pas rester debout, c'est notre propre décision. De plus, la question se pose, comment connecter le capteur dans cette version ? Dans la brèche ? Que se passe-t-il si le capteur lui-même tombe en panne ? Besoin d'un module de dérivation dans le capteur ? Utiliser des séparateurs (tapoter) ? Tout cela rend la solution plus coûteuse et inabordable pour une entreprise, quelle que soit sa taille.
Vous pouvez essayer de « suspendre » le capteur sur un port SPAN/RSPAN/ERSPAN et y diriger le trafic des ports de commutateur requis. Cette option supprime 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 absolument tout le trafic qui lui sera envoyé - il n'aura pas assez de bande passante. Vous devrez sacrifier quelque chose. Soit laissez certains nœuds sans surveillance (vous devez alors d'abord les prioriser), soit n'envoyez pas tout le trafic du nœud, mais seulement un certain type. Dans tous les cas, nous risquons de rater certaines attaques. De plus, le port SPAN peut être utilisé pour d'autres besoins. De ce fait, nous devrons revoir la topologie du réseau existante et éventuellement y apporter des ajustements afin de couvrir au maximum votre réseau avec le nombre de capteurs dont vous disposez (et coordonner cela avec l'IT).
Que se passe-t-il si votre réseau utilise des routes asymétriques ? Que se passe-t-il si vous avez mis en œuvre ou envisagez de mettre en œuvre le SDN ? Que se passe-t-il si vous devez surveiller des machines ou des conteneurs virtualisés dont le trafic n’atteint pas du tout le commutateur physique ? Ce sont des questions que les fournisseurs d'IDS traditionnels n'aiment pas parce qu'ils ne savent pas comment y répondre. Peut-être vous persuaderont-ils que toutes ces technologies à la mode sont à la mode et que vous n’en avez pas besoin. Peut-être parleront-ils de la nécessité de commencer modestement. Ou peut-être diront-ils que vous devez placer un puissant batteur 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 clairement comprendre en quoi elle vous convient. Et seulement après cela, prenez la décision 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 ; frontières entre votre organisation et Internet, frontières entre le centre de données et le reste du réseau, frontières entre le système de contrôle des processus et le segment de l'entreprise. Dans ces lieux, les IDS/IPS classiques ont toujours le droit d’exister et de bien s’acquitter de leurs tâches.
Passons à la deuxième option. L'analyse des événements provenant des périphériques 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, il est inhérent à une certaine réactivité - l'attaque doit d'abord se produire, puis elle doit être enregistrée par un périphérique réseau, ce qui, d'une manière ou d'une autre, signalera un problème de sécurité des informations. Il existe plusieurs méthodes de ce type. Cela peut être syslog, RMON ou SNMP. Les deux derniers protocoles de surveillance du réseau dans le cadre de la sécurité de l'information 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, il est possible, par exemple, de surveiller la charge sur le système central de l'appareil. processeur ou ses interfaces. C'est l'une des méthodes les moins chères (tout le monde possède Syslog ou SNMP), mais aussi la plus inefficace de toutes les méthodes de surveillance de la sécurité des informations de l'infrastructure interne - de nombreuses attaques lui sont simplement cachées. Bien sûr, ils ne doivent pas être négligés, et la même analyse Syslog vous aide à identifier en temps opportun les changements dans la configuration de l'appareil lui-même, sa compromission, mais elle n'est pas très adaptée pour détecter des attaques sur l'ensemble du réseau.
La troisième option consiste à analyser les informations sur le trafic transitant par un appareil prenant en charge l'un des nombreux protocoles de flux. Dans ce cas, quel que soit le protocole, l’infrastructure de threading se compose nécessairement de trois composants :
- Génération ou export de flux. Ce rôle est généralement attribué à un routeur, un commutateur ou un autre périphérique réseau qui, en faisant passer le trafic réseau par lui-même, vous permet d'en extraire des paramètres clés, qui sont ensuite transmis au module de collecte. Par exemple, Cisco prend en charge le protocole Netflow non seulement sur les routeurs et les 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é qu'un réseau moderne dispose généralement de plusieurs périphériques réseau, le problème de la collecte et de la consolidation des flux se pose, qui est résolu à l'aide de ce que l'on appelle des collecteurs, qui traitent les flux reçus puis les transmettent pour analyse.
- Analyse des flux L'analyseur assume la tâche intellectuelle principale et, en appliquant divers algorithmes aux flux, tire certaines conclusions. Par exemple, dans le cadre d'une fonction informatique, un tel analyseur peut identifier les goulots d'étranglement du réseau ou analyser le profil de charge du trafic pour une optimisation plus poussée du réseau. Et pour la sécurité des informations, un tel analyseur peut détecter les fuites de données, la propagation de codes malveillants ou les attaques DoS.
Ne pensez pas que cette architecture à trois niveaux est trop compliquée - toutes les autres options (sauf peut-être les systèmes de surveillance de réseau fonctionnant avec SNMP et RMON) fonctionnent également selon elle. Nous disposons d'un générateur de données pour l'analyse, qui peut être un périphérique réseau ou un capteur autonome. Nous disposons d'un système de collecte d'alarmes et d'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 seul nœud, mais dans les réseaux plus ou moins grands, ils sont généralement répartis sur au moins deux appareils afin de garantir évolutivité et fiabilité.
Contrairement à l'analyse des paquets, qui repose sur l'étude des données d'en-tête et du corps de chaque paquet et des sessions qui le composent, l'analyse des flux repose sur la collecte de métadonnées sur le trafic réseau. Quand, combien, d'où et où, comment... telles sont les questions auxquelles répond l'analyse de la télémétrie des réseaux à l'aide de différents protocoles de flux. Initialement, ils étaient utilisés pour analyser des statistiques et détecter des problèmes informatiques sur le réseau, mais ensuite, à mesure que les mécanismes analytiques se développaient, il est devenu possible de les appliquer à la même télémétrie à des fins de sécurité. Il convient de noter encore une fois que l'analyse de flux ne remplace ni ne remplace la capture de paquets. Chacune de ces méthodes a son propre domaine d'application. Mais dans le cadre de cet article, c’est l’analyse des flux qui est la mieux adaptée pour surveiller l’infrastructure interne. Vous disposez de périphériques réseau (qu’ils fonctionnent selon un paradigme défini par logiciel ou selon des règles statiques) qu’une attaque ne peut pas contourner. Il peut contourner un capteur IDS classique, mais un périphérique réseau prenant en charge le protocole de flux ne le peut pas. C'est l'avantage de cette méthode.
D'un autre côté, si vous avez besoin de preuves pour les forces de l'ordre ou pour 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 une détection et une prise de décision rapides dans le domaine de la sécurité de l'information. D'un autre côté, grâce à l'analyse télémétrique, vous ne pouvez pas « écrire » tout le trafic réseau (au contraire, Cisco s'occupe des 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 des commandes pour la capture et le stockage sélectifs. Dans le cas contraire, il vous faudra disposer d’une infrastructure de stockage colossale.
Imaginons un réseau fonctionnant à une vitesse de 250 Mbit/s. Si vous souhaitez stocker tout ce volume, vous aurez besoin de 31 Mo de stockage pour une seconde de transmission de trafic, de 1,8 Go pour une minute, de 108 Go pour une heure et de 2,6 To pour une journée. Pour stocker quotidiennement les données d'un réseau doté d'une bande passante de 10 Gbit/s, vous aurez besoin de 108 To de stockage. Mais certains régulateurs exigent que les données de sécurité soient conservées pendant des années… L’enregistrement à la demande, que l’analyse des flux vous aide à mettre en œuvre, permet de réduire ces valeurs de plusieurs ordres de grandeur. À propos, si nous parlons du rapport entre le volume de données de télémétrie réseau enregistrées et la capture complète des données, il est alors d'environ 1 à 500. Pour les mêmes valeursdonnées ci-dessus, stocker une transcription complète de tout le trafic quotidien sera respectivement de 5 et 216 Go (vous pouvez même l'enregistrer sur un lecteur flash ordinaire ).
Si pour les outils d'analyse des données brutes du réseau, la méthode de capture est quasiment la même d'un fournisseur à l'autre, alors dans le cas de l'analyse des flux, la situation est différente. Il existe plusieurs options pour les protocoles de flux, dont vous devez connaître les différences dans le contexte de la 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 routières enregistrées. La version actuelle est la neuvième (Netflow v9), sur la base de laquelle le standard industriel Netflow v10, également connu sous le nom d'IPFIX, a été développé. Aujourd'hui, la plupart des fournisseurs de réseaux prennent en charge Netflow ou IPFIX dans leurs équipements. Mais il existe diverses autres options pour les protocoles de flux : sFlow, jFlow, cFlow, rFlow, NetStream, etc., dont sFlow est le plus populaire. C'est ce type qui est le plus souvent soutenu par les fabricants nationaux d'équipements de réseau en raison de sa facilité de mise en œuvre. Quelles sont les principales différences entre Netflow, devenu un standard de facto, et sFlow ? J’en soulignerais plusieurs principaux. Premièrement, Netflow propose des champs personnalisables par l'utilisateur, par opposition aux champs fixes de sFlow. Et deuxièmement, et c'est la chose la plus importante dans notre cas, sFlow collecte ce qu'on appelle la télémétrie échantillonnée ; contrairement à celui non échantillonné pour Netflow et IPFIX. Quelle est la différence entre eux?
Imaginez que vous décidez de lire le livre «» de mes collègues - Gary McIntyre, Joseph Munitz et Nadem Alfardan (vous pouvez télécharger une partie du livre à partir du lien). Vous disposez de trois options pour atteindre votre objectif : lire le livre en entier, le parcourir en vous arrêtant à chaque 10e ou 20e page, ou essayer de trouver un récit des concepts clés sur un blog ou un service comme SmartReading. Ainsi, la télémétrie non échantillonnée lit chaque « page » du trafic réseau, c’est-à-dire analyse les métadonnées de chaque paquet. La télémétrie échantillonnée est l'étude sélective du trafic dans l'espoir que les échantillons sélectionnés contiendront ce dont vous avez besoin. En fonction de la vitesse du canal, la télémétrie échantillonnée sera envoyée pour analyse tous les 64, 200, 500, 1000 2000, 10000 XNUMX ou même XNUMX XNUMX 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 à la détection des attaques DDoS, à l'analyse et à la propagation de codes malveillants, mais peut manquer des attaques atomiques ou multi-paquets qui n'étaient pas incluses dans l'échantillon envoyé pour analyse. La télémétrie non échantillonnée ne présente pas de tels inconvénients. Ainsi, la gamme d’attaques détectées 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 entendu, 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'en effectuer une analyse de base d'un point de vue informatique. Pour identifier les menaces à la sécurité de l'information 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 standards ou personnalisés, enrichiront les données standards avec des données externes provenant de diverses sources de Threat Intelligence, etc.
Par conséquent, si vous avez le choix, choisissez Netflow ou IPFIX. Mais même si votre équipement ne fonctionne qu'avec sFlow, comme les fabricants nationaux, alors même dans ce cas, vous pouvez en bénéficier dans un contexte 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, Polygon et Craftway, ont annoncé la prise en charge de sFlow (au moins Zelax, Natex, Eltex, QTech, Rusteleteh).
La prochaine question à laquelle vous serez confronté est de savoir où implémenter la prise en charge des flux à des fins de sécurité ? En fait, la question n’est pas tout à fait correctement posée. Les équipements modernes prennent presque toujours en charge les protocoles de flux. Par conséquent, je reformulerais la question différemment : où est-il le plus efficace de collecter des données télémétriques d'un point de vue de 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 surveiller le trafic P2P entre les hôtes, ce qui est essentiel pour analyser la détection et la distribution de codes malveillants. Au niveau central, vous ne verrez peut-être tout simplement pas une partie du trafic, mais au niveau du périmètre, vous verrez un quart de tout votre trafic réseau. Mais si, pour une raison quelconque, vous avez des appareils étrangers sur votre réseau qui permettent aux attaquants « d'entrer et de sortir » sans contourner le périmètre, alors l'analyse de la télémétrie de ceux-ci ne vous donnera rien. Par conséquent, pour une couverture maximale, il est recommandé d’activer la collecte de télémétrie au niveau de l’accès. Dans le même temps, il convient de noter que même si nous parlons de virtualisation ou de conteneurs, la prise en charge des flux se retrouve également souvent dans les commutateurs virtuels modernes, ce qui vous permet également de contrôler le trafic.
Mais puisque j’ai abordé le sujet, je dois répondre à la question : que se passe-t-il si 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 est-ce que son activation entraîne une charge élevée du processeur (cela se produit sur du matériel plus ancien) ? Pour résoudre ce problème, il existe des capteurs virtuels spécialisés (capteurs de débit), qui sont essentiellement des séparateurs ordinaires qui transmettent le trafic à travers eux et le diffusent sous forme de flux vers le module de collecte. Certes, dans ce cas, nous rencontrons tous les problèmes dont nous avons parlé ci-dessus concernant les outils de capture de paquets. Autrement dit, vous devez comprendre non seulement les avantages de la technologie d’analyse des flux, mais également ses limites.
Autre point important à retenir lorsqu’on parle d’outils d’analyse de flux. Si par rapport aux moyens conventionnels de génération d'événements de sécurité nous utilisons la métrique EPS (événement par seconde), alors cet indicateur n'est pas applicable à l'analyse télémétrique ; il est remplacé par le 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 threads générés par un appareil particulier en fonction de sa tâche. Vous pouvez trouver sur Internet des tableaux avec des valeurs approximatives pour différents types d'appareils et conditions d'entreprise, qui vous permettront d'estimer 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 peut « tirer », et le collecteur de flux a ses propres limites qu'il faut comprendre. Par conséquent, dans les grands réseaux géographiquement répartis, il existe généralement plusieurs collecteurs. Quand j'ai décrit , j'ai déjà donné le nombre de nos collectionneurs - ils sont au nombre de 21. Et ceci pour un réseau dispersé sur cinq continents et comptant environ un demi-million d'appareils actifs).
Nous utilisons notre propre solution comme système de surveillance Netflow , 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 clairement malveillantes, ce qui vous permet de détecter un large éventail de menaces différentes - du cryptomining aux fuites d'informations, de la propagation de codes malveillants à 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 et importantes dans le contexte du matériau considéré. Premièrement, il s'intègre aux solutions de capture de paquets (telles que Cisco Security Packet Analyzer), qui vous permettent d'enregistrer des sessions réseau sélectionnées pour une enquête et une analyse approfondies ultérieures. Deuxièmement, spécifiquement pour étendre les tâches de sécurité, nous avons développé un protocole nvzFlow spécial, qui vous permet de « diffuser » l'activité des applications sur les nœuds finaux (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 originale, Stealthwatch fonctionne avec n'importe quel protocole de flux (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) au niveau du réseau, alors la prise en charge de nvzFlow permet ainsi la corrélation des données également au niveau des nœuds. augmentant l'efficacité de l'ensemble du système et détectant plus d'attaques que les analyseurs de flux réseau conventionnels.
Il est clair que lorsqu'on parle des systèmes d'analyse Netflow du point de vue de la sécurité, le marché ne se limite pas à une seule solution de Cisco. Vous pouvez utiliser des solutions commerciales et gratuites ou shareware. C'est assez étrange si je cite les solutions des concurrents comme exemples sur le blog Cisco, je vais donc dire 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) d'analyse de trafic, développé par l'américain CERT/CC et qui supporte, dans le cadre de l'article d'aujourd'hui, Netflow (5ème et 9ème, les versions les plus populaires), IPFIX et sFlow et en utilisant divers utilitaires (rwfilter, rwcount, rwflowpack, etc.) pour effectuer diverses opérations sur la télémétrie du réseau afin d'y détecter les signes d'actions non autorisées. Mais il y a quelques points importants à noter. SiLK est un outil en ligne de commande qui effectue une analyse en ligne en saisissant des commandes comme celle-ci (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
pas très confortable. Vous pouvez utiliser l'interface graphique iSiLK, mais cela ne vous facilitera pas la vie, résolvant uniquement la fonction de visualisation et ne remplaçant pas l'analyste. Et c'est le deuxième point. Contrairement aux solutions commerciales, qui disposent déjà d'une base analytique solide, d'algorithmes de détection d'anomalies, d'un flux de travail correspondant, etc., dans le cas de SiLK, vous devrez faire tout cela vous-même, ce qui nécessitera de votre part des compétences légèrement différentes de celles d'une utilisation déjà prête. utiliser des outils. Ce n'est ni bon ni mauvais - c'est une fonctionnalité de presque tous les outils gratuits qui supposent que vous savez quoi faire, et cela ne fera que vous aider (les outils commerciaux dépendent moins des compétences de leurs utilisateurs, bien qu'ils supposent également que les analystes comprennent au moins les bases des enquêtes et de la surveillance des réseaux). Mais revenons à SiLK. Le cycle de travail de l’analyste avec cela ressemble à ceci :
- Formuler une hypothèse. Nous devons comprendre ce que nous rechercherons dans la télémétrie du réseau, 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.
- Essai. Vient maintenant le tour de vérifier l'exactitude 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 pour améliorer le niveau de reconnaissance ? » et ainsi de suite.
- Amélioration. Au stade final, nous améliorons ce qui a été fait précédemment - nous créons des modèles, améliorons et optimisons le code, reformulons et clarifions l'hypothèse, etc.
Ce cycle sera également applicable à Cisco Stealthwatch, seul le dernier automatise au maximum ces cinq étapes, réduisant ainsi le nombre d'erreurs d'analyste et augmentant l'efficacité de la détection des incidents. Par exemple, dans SiLK, vous pouvez enrichir les statistiques du réseau avec des données externes sur des adresses IP malveillantes à l'aide de scripts manuscrits, et dans Cisco Stealthwatch, il s'agit d'une fonction intégrée qui affiche immédiatement une alarme si le trafic réseau contient des interactions avec des adresses IP de la liste noire.
Si vous montez plus haut dans la pyramide « payante » des logiciels d'analyse de flux, alors après SiLK absolument gratuit, il y aura un 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 payants, d'autres non) qui automatisent l'analyse de la télémétrie réseau. Par exemple, le filtre GeoIP de Logstash vous permet d'associer les adresses IP surveillées à leur emplacement géographique (Stealthwatch possède cette fonctionnalité intégrée).
ELK dispose également d'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 , si vous n'êtes pas satisfait du module Logstash Netflow, qui prend uniquement en charge Netflow.
Tout en offrant plus d'efficacité dans la collecte des flux et la recherche dans ceux-ci, ELK manque actuellement d'analyses intégrées riches 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 les modèles de violation, puis les utiliser dans le système de combat (il n'y a pas de modèles intégrés).
Il existe bien sûr 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 de telles extensions coûtent de l'argent et ici la question est de savoir si le jeu en vaut la chandelle - écrivez vous-même un modèle similaire, achetez-le. implémentation pour votre outil de surveillance, ou achetez une solution prête à l'emploi de la classe Analyse du trafic réseau.
En général, je ne veux pas entrer dans le débat selon lequel il vaut mieux dépenser de l'argent et acheter une solution toute faite pour surveiller les anomalies et les menaces dans la télémétrie réseau (par exemple, Cisco Stealthwatch) ou la découvrir vous-même et personnaliser la même chose. SiLK, ELK ou nfdump ou OSU Flow Tools pour chaque nouvelle menace (je parle des deux dernières d'entre elles 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é réseau de votre infrastructure interne et qu'il ne faut pas la négliger, pour ne pas rejoindre la liste des entreprises dont le nom est cité dans les médias avec les épithètes " piratés », « non conformes aux exigences de sécurité des informations », « ne pensant pas à la sécurité de leurs données et des données de leurs clients ».
Pour résumer, je voudrais énumérer les conseils clés que vous devez suivre lors de la mise en place d'une surveillance de la sécurité des informations de votre infrastructure interne :
- Ne vous limitez pas au périmètre ! Utilisez (et choisissez) l’infrastructure réseau non seulement pour déplacer le trafic d’un point A vers un point B, mais également pour résoudre les problèmes de cybersécurité.
- Étudiez les mécanismes de surveillance de la sécurité des informations existants dans votre équipement réseau et utilisez-les.
- Pour la surveillance interne, privilégiez l'analyse télémétrique - elle vous permet de détecter jusqu'à 80 à 90 % de tous les incidents de sécurité des informations réseau, tout en faisant ce qui est impossible lors de la capture de 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 un contexte de sécurité et permettent de surveiller non seulement IPv4, mais aussi IPv6, MPLS, etc.
- Utilisez un protocole de flux non échantillonné : il fournit plus d'informations pour détecter les menaces. Par exemple, Netflow ou IPFIX.
- Vérifiez la charge de votre équipement réseau : il se peut qu'il ne soit pas également en mesure de gérer le protocole de flux. Pensez ensuite à utiliser des capteurs virtuels ou Netflow Generation Appliance.
- Mettez en œuvre le contrôle d'abord au niveau de l'accès - cela vous donnera la possibilité de voir 100 % de tout le trafic.
- Si vous n'avez pas le choix et que vous utilisez un équipement réseau russe, choisissez-en un qui prend en charge les protocoles de flux ou qui possède des ports SPAN/RSPAN.
- Combiner des systèmes de détection/prévention des intrusions/attaques en périphérie et des systèmes d’analyse des flux dans le réseau interne (y compris dans les cloud).
Concernant le dernier conseil, je voudrais donner une illustration que j'ai déjà donnée auparavant. Vous voyez que si auparavant le service de sécurité de l'information de Cisco construisait presque entièrement son système de surveillance de la sécurité de l'information sur la base de systèmes de détection d'intrusion et de méthodes de signature, ils ne représentent désormais que 20 % des incidents. 20 % supplémentaires reviennent aux systèmes d'analyse de flux, ce qui suggère que ces solutions ne sont pas un caprice, mais un véritable outil dans les activités des services de sécurité de l'information d'une entreprise moderne. De plus, vous disposez de l'élément le plus important pour leur mise en œuvre : l'infrastructure réseau, dans laquelle les investissements peuvent être davantage protégés en attribuant des fonctions de surveillance de la sécurité des informations au réseau.
Je n'ai pas spécifiquement 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 se terminer 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 un sujet pour un article séparé.
Renseignements supplémentaires:
PS. S'il vous est plus facile d'entendre tout ce qui a été écrit ci-dessus, vous pouvez alors regarder la présentation d'une heure qui constitue la base de cette note.
Source: habr.com