StealthWatch : analyse et enquête sur les incidents. Partie 3

Cisco StealthWatch est une solution analytique dans le domaine de la cybersécurité, qui offre une surveillance complète des menaces dans un réseau distribué. Le fonctionnement de StealthWatch repose sur la collecte de NetFlow et d'IPFIX depuis les routeurs, commutateurs et autres appareils réseau. Par conséquent, le réseau devient un capteur sensible et permet à l'administrateur de voir là où les méthodes traditionnelles de protection du réseau, comme le pare-feu de nouvelle génération, ne peuvent pas accéder.

Dans des articles précédents, j'ai déjà parlé de StealthWatch : première présentation et fonctionnalités, ainsi que déploiement et configuration. À présent, je propose de discuter de la manière de traiter les alarmes et d'enquêter sur les incidents de sécurité générés par la solution. Six exemples seront donnés, qui, j'espère, fourniront une bonne idée de l'utilité du produit.

Il convient d'abord de dire que StealthWatch présente une certaine distribution des déclenchements entre les algorithmes et les flux. Les premiers sont des alarmes (notifications) de différents types, qui, lorsqu'elles se déclenchent, peuvent détecter des éléments suspects dans le réseau. Les seconds sont des incidents de sécurité. Cet article examinera 4 exemples de déclenchements d'algorithmes et 2 exemples de flux.

1. Analyse des interactions les plus volumineuses dans le réseau

La première étape de la configuration de StealthWatch est de définir les hôtes et les réseaux par groupes. Dans l'interface web, l'onglet Configurer > Gestion des groupes d'hôtes permet de classer les réseaux, hôtes, serveurs dans les groupes correspondants. Il est également possible de créer ses propres groupes. À propos, l'analyse des interactions entre hôtes dans Cisco StealthWatch est assez pratique, car il est possible non seulement d'enregistrer les filtres de recherche par flux, mais aussi les résultats eux-mêmes.

Pour commencer, il faut accéder à l'onglet de l'interface web Analyser > Recherche de flux. Ensuite, il faut définir les paramètres suivants :

• Type de recherche — Conversations principales (les interactions les plus populaires)
• Plage horaire — 24 heures (période de temps, une autre peut être utilisée)
• Nom de recherche — Conversations principales à l'intérieur (n'importe quel nom compréhensible)
• Sujets — Groupes d'hôtes → Hôtes internes (source — groupe d'hôtes internes)
• Connexion (il est possible d'indiquer les ports, applications)
• Pair — Groupes d'hôtes → Hôtes internes (destination — groupe d'hôtes internes)
• Dans les Options avancées, il est possible d'indiquer le collecteur à partir duquel les données sont consultées, le tri des sorties (par bytes, flux, etc.). Je laisserai les valeurs par défaut.

Après avoir cliqué sur le bouton Recherche une liste d'interactions classée par volume de données transférées est fournie.

Dans mon exemple, l'hôte 10.150.1.201 (serveur) a transmis 1.5 Go du trafic à l'hôte 10.150.1.200 (client) via le protocole mysql. Le bouton Gérer les colonnes permet d'ajouter plus de colonnes aux données affichées.

Ensuite, à la discrétion de l'administrateur, il est possible de créer une règle personnalisée qui sera déclenchée en permanence pour ce type d'interactions et notifiera par SNMP, email ou Syslog.

2. Analyse des interactions client-serveur les plus lentes sur le réseau pour détecter des retards.

Étiquettes SRT (Temps de Réponse du Serveur), RTT (Temps de Déplacement Aller-Retour) permettent d'identifier les retards des serveurs et les retards généraux sur le réseau. Cet outil est particulièrement utile pour trouver rapidement la cause des plaintes des utilisateurs concernant une application qui fonctionne lentement.

Remarque: presque tous les exportateurs Netflow ne savent pas envoient des balises SRT, RTT, donc souvent, pour voir de telles données sur FlowSensor, il faut configurer l'envoi d'une copie du trafic depuis les appareils réseau. FlowSensor en retour fournit un IPFIX étendu au FlowCollector.

Cette analyse est plus facilement réalisée dans l'application Java StealthWatch, qui s'installe sur l'ordinateur de l'administrateur.

Cliquez avec le bouton droit de la souris sur Hôtes Internes et allez à l'onglet Tableau de Flux.

Cliquez sur Filter et définissez les paramètres nécessaires. Par exemple :

• Date/Heure — Pour les 3 derniers jours
• Performance — Temps de Déplacement Aller-Retour moyen >=50ms

Après l'affichage des données, il convient d'ajouter les champs RTT, SRT qui nous intéressent. Pour ce faire, cliquez sur la colonne sur la capture d'écran et sélectionnez avec le bouton droit de la souris Gérer les colonnes. Ensuite, cochez les paramètres RTT, SRT.

Après le traitement de la demande, j'ai trié par RTT moyen et vu les interactions les plus lentes.

Pour plonger dans les détails, il faut cliquer avec le bouton droit de la souris sur le flux et choisir Vue Rapide pour le Flux.

Cette information indique que l'hôte 10.201.3.59 du groupe Ventes et Marketing via le protocole NFS accesse à au serveur DNS pendant une minute et 23 secondes et présente un retard terrible. Dans l'onglet Interfaces vous pouvez découvrir de quel exportateur Netflow l'information a été obtenue. Dans l'onglet Table une information plus détaillée sur l'interaction est présentée.

Ensuite, il faut identifier quels appareils envoient le trafic à FlowSensor et le problème se trouve probablement là.

De plus, StealthWatch est unique en ce qu'il effectue une déduplication. données (qui unifie les mêmes flux). Par conséquent, il est possible de collecter pratiquement depuis tous les appareils Netflow sans craindre d'avoir trop de données redondantes. Au contraire, ce schéma aide à comprendre à quel saut se produisent les plus grands délais.

3. Audit des protocoles cryptographiques HTTPS

ETA (Encrypted Traffic Analytics) — une technologie développée par Cisco, permettant de détecter des connexions malveillantes dans le trafic chiffré sans le déchiffrer. De plus, cette technologie permet de « décomposer » HTTPS en versions TLS et en protocoles cryptographiques utilisés lors des connexions. Cette fonctionnalité est particulièrement utile lorsqu'il s'agit de détecter des nœuds réseau utilisant des standards cryptographiques faibles.

Remarque: il est d'abord nécessaire d'installer l'application réseau sur StealthWatch — Audit Cryptographique ETA.

Nous allons dans l'onglet Tableaux de bord → Audit Cryptographique ETA et nous choisissons le groupe d'hôtes que nous prévoyons d'analyser. Pour avoir une vue d'ensemble, sélectionnons Hôtes Internes.

On peut observer que la version TLS et le standard cryptographique correspondant sont affichés. Selon le schéma habituel dans la colonne Actions nous passons à Afficher les Flux et une recherche est lancée dans un nouvel onglet.

De la sortie, il apparaît que l'hôte 198.19.20.136 durant 12 heures a utilisé HTTPS avec TLS 1.2, où l'algorithme de chiffrement AES-256 et la fonction de hachage SHA-384. Ainsi, l'ETA permet de trouver des algorithmes faibles dans le réseau.

4. Analyse des anomalies dans le réseau

Cisco StealthWatch peut reconnaître les anomalies de trafic dans le réseau, en utilisant trois outils : Événements Principaux (événements de sécurité), Événements de Relation (événements d'interaction entre segments, nœuds du réseau) et analyse comportementale.

L'analyse comportementale, à son tour, permet de construire au fil du temps un modèle de comportement pour hôte ou groupe d'hôtes donné. Plus le trafic passe par StealthWatch, plus les déclenchements seront précis grâce à cette analyse. Au début, le système génère beaucoup de faux positifs, il est donc nécessaire d'ajuster les règles manuellement. Je recommande de ne pas prêter attention à ces événements pendant les premières semaines, car le système s'adaptera tout seul, ou d'ajouter à des exceptions.

Voici un exemple de règle préétablie Anomalie, qui indique que l'événement se déclenchera sans alarme si l'hôte dans le groupe Inside Hosts interagit avec le groupe Inside Hosts et que, dans les 24 heures, le trafic dépasse 10 mégaoctets..

Prenons comme exemple l'alarme Data Hoarding, ce qui signifie qu'un hôte source/destination a téléchargé/téléversé une quantité anormalement élevée de données à partir d'un groupe d'hôtes ou d'un hôte. Cliquez sur l'événement pour accéder au tableau où sont mentionnés les hôtes déclencheurs. Ensuite, sélectionnez l'hôte qui nous intéresse dans la colonne Data Hoarding.

Un événement est affiché, indiquant que 162k « points » ont été détectés, tandis que la politique autorise 100k « points » — ce sont des métriques internes de StealthWatch. Dans la colonne Actions cliquez sur Afficher les Flux.

Nous pouvons observer que cet hôte a interagi la nuit avec l'hôte 10.201.3.47 du département Ventes & Marketing via le protocole HTTPS et a téléchargé 1,4 Go. Ce cas est peut-être un peu mal choisi, mais la détection des interactions, même sur plusieurs centaines de gigaoctets, se fait de la même manière. Par conséquent, une enquête plus approfondie sur les anomalies peut conduire à des résultats intéressants.

Remarque: dans l'interface web SMC, les données dans les onglets Tableaux de bord sont affichées uniquement pour la dernière semaine et dans l'onglet Surveillance pour les 2 dernières semaines. Pour analyser des événements plus anciens et générer des rapports, il faut travailler avec la console java sur l'ordinateur de l'administrateur.

5. Identification des scans internes du réseau

Voyons maintenant quelques exemples de flux — incidents de sécurité. Cette fonctionnalité intéresse davantage les responsables de la sécurité.

Il existe plusieurs types d'événements de scan prédéfinis dans StealthWatch :

• Scan de port — la source scanne de nombreux ports de l'hôte de destination.
• Scan tcp Addr — la source scanne un réseau entier sur le même port TCP, en changeant l'adresse IP de destination. Dans ce cas, la source reçoit des paquets TCP Reset ou ne reçoit pas de réponses du tout.
• Scan udp Addr — la source scanne un réseau entier sur le même port UDP, en changeant l'adresse IP de destination. Dans ce cas, la source reçoit des paquets ICMP Port Unreachable ou ne reçoit pas de réponses du tout.
• Scan Ping — la source envoie des requêtes ICMP sur un réseau entier pour rechercher des réponses.
• Scan Stealth tcp/udp — la source utilise le même port pour se connecter à de nombreux ports de l'hôte de destination en même temps.

Pour localiser plus facilement tous les scanners internes, il existe une application réseau pour StealthWatch — Évaluation de la visibilité. En accédant à l'onglet Tableaux de bord → Évaluation de la visibilité → Scanners internes du réseau , vous verrez les incidents de sécurité liés aux scans des deux dernières semaines.

En cliquant sur le bouton Détails, on peut voir le début de l'analyse de chaque réseau, la tendance du trafic et les alarmes correspondantes.

Ensuite, on peut « plonger » dans l'hôte à partir de l'onglet de la capture d'écran précédente et voir les événements de sécurité ainsi que l'activité de la dernière semaine pour cet hôte.

Prenons comme exemple l'analyse de l'événement Scan de port depuis l'hôte 10.201.3.149 sur 10.201.0.72, en cliquant sur Actions > Flux associés. Une recherche sur les flux est lancée et les informations pertinentes sont affichées.

Comme nous le voyons, cet hôte a scanné un de ses ports 51508/TCP il y a 3 heures vers un hôte de destination sur les ports 22, 28, 42, 41, 36, 40 (TCP). Certains champs n'affichent pas d'informations soit parce que tous les champs Netflow ne sont pas pris en charge par l'exportateur Netflow.

6. Analyse des malwares téléchargés grâce à CTA

CTA (Cognitive Threat Analytics) est une analyse cloud de Cisco qui s'intègre parfaitement avec Cisco StealthWatch et permet de compléter l'analyse sans signature par une analyse par signature. Cela rend possible la détection de chevaux de Troie, de vers réseau, de malwares de jour zéro et d'autres malwares ainsi que leur propagation au sein du réseau. De plus, la technologie mentionnée précédemment, ETA, permet d'analyser ces communications malveillantes même dans le trafic chiffré.

Dès le premier onglet de l'interface Web, il y a un widget spécial Cognitive Threat Analytics. Un résumé bref indique les menaces détectées sur les hôtes utilisateurs : cheval de Troie, logiciel malveillant, adware. Le mot « Encrypted » souligne le fonctionnement de l'ETA. En cliquant sur l'hôte, toutes les informations, y compris les événements de sécurité, sont affichées avec les journaux de la CTA.

En passant la souris sur chaque étape de la CTA, des informations détaillées sur les interactions apparaissent. Pour une analyse complète, il vaut mieux cliquer sur Voir les détails de l'incident, et vous accéderez à une console séparée. Cognitive Threat Analytics.

En haut à droite, un filtre permet d'afficher les événements par niveau de criticité. En survolant une anomalie particulière, des journaux avec un chronologie correspondante apparaissent en bas de l'écran à droite. Ainsi, le spécialiste de la sécurité informatique comprend clairement quel hôte infecté a commencé à effectuer quelles actions après certaines opérations.

Ci-dessous est un autre exemple — un cheval de Troie bancaire qui a infecté l'hôte 198.19.30.36. Cet hôte a commencé à interagir avec des domaines malveillants, et les journaux affichent les informations sur les flux de ces interactions.

Ensuite, l'une des meilleures solutions qui existe est de mettre l'hôte en quarantaine grâce à un natif d'intégrer avec Cisco ISE pour des soins et une analyse ultérieurs.

Conclusion

La solution Cisco StealthWatch est l'un des leaders parmi les produits de surveillance réseau tant en matière d'analyse réseau que de sécurité de l'information. Grâce à elle, il est possible de détecter des interactions non légitimes au sein du réseau, des retards d'applications, les utilisateurs les plus actifs, des anomalies, des malwares et des APT. De plus, on peut identifier les scans, les pentesters, et effectuer des audits cryptographiques du trafic HTTPS. Vous pouvez trouver encore plus de cas d'utilisation sur le lien.

Si vous souhaitez vérifier à quel point votre réseau fonctionne sans accroc et efficacement, envoyez demande.
Dans un avenir proche, nous prévoyons encore plusieurs publications techniques sur divers produits de sécurité de l'information. Si vous êtes intéressé par ce sujet, suivez nos mises à jour sur nos canaux (Telegram, Facebook, VK, Blog de solutions TS)!

Source : habr.com