3. Elastic stack : analyse des logs de sécurité. Tableaux de bord

Dans les articles précédents, nous avons abordé brièvement la pile ELK et la configuration du fichier de configuration Logstash pour le parseur de journaux. Dans cet article, nous allons nous concentrer sur ce qui est le plus important du point de vue de l'analyse, ce que vous souhaitez voir de la part du système et la raison pour laquelle tout cela a été créé : ce sont des graphiques et des tableaux réunis dans des tableaux de bord. Aujourd'hui, nous allons nous familiariser davantage avec le système de visualisation Kibana, nous verrons comment créer des graphiques, des tableaux, et, au final, nous construirons un tableau de bord simple basé sur les journaux du pare-feu Check Point.

La première étape du travail avec Kibana consiste à créer un modèle d'index, qui est fondamentalement une base d'indices unifiée selon un principe spécifique. Bien entendu, cela est principalement une configuration pour que Kibana puisse rechercher plus facilement des informations dans tous les indices simultanément. Cela se fait par le biais de la correspondance d'une chaîne, par exemple « checkpoint-* » et du nom de l'indice. Par exemple, « checkpoint-2019.12.05 » correspond au modèle, tandis que « checkpoint » tout seul ne correspond pas. Il est également à noter qu'il n'est pas possible de rechercher des informations selon différents modèles d'indices simultanément. Dans les articles suivants, nous verrons que les requêtes API sont faites soit par le nom de l'indice, soit selon un seul modèle de ligne, l'image est cliquable :

Après cela, vérifions dans le menu Discover que tous les journaux sont indexés et que le bon parseur est configuré. Si des incohérences sont découvertes, par exemple, changer le type de données d'une chaîne à un nombre entier, il est nécessaire de modifier le fichier de configuration Logstash, afin que les nouveaux journaux soient correctement enregistrés. Pour que les anciens journaux prennent le bon format suite à la modification, seul le processus de réindexation peut aider. Dans les articles suivants, cette opération sera examinée plus en détail. Assurons-nous que tout est en ordre, l'image est cliquable :

Les journaux sont à leur place, il est donc temps de commencer à construire des tableaux de bord. Sur la base des analyses des tableaux de bord des produits de sécurité, on peut comprendre l'état de la cybersécurité dans l'organisation, voir clairement les points vulnérables de la politique actuelle et, par la suite, développer des moyens de les corriger. Construisons un petit tableau de bord en utilisant plusieurs outils de visualisation. Le tableau de bord sera composé de 5 éléments :

1. un tableau pour compter le nombre total de journaux par blade
2. un tableau pour les signatures critiques IPS
3. un diagramme circulaire des événements de prévention des menaces
4. diagramme des sites les plus visités
5. diagramme de l'utilisation des applications les plus dangereuses

Pour créer des figures de visualisation, il faut se rendre dans le menu Visualiser, et choisir la figure souhaitée que nous voulons construire ! Allons par étapes.

Tableau pour compter le nombre total de logs par blades

Pour cela, choisissons la figure Tableau de données, nous plongeons dans l'outil de création de graphiques, à gauche se trouvent les paramètres de la figure, à droite l'apparence selon les paramètres actuels. Je vais d'abord montrer à quoi ressemblera le tableau final, puis nous passerons en revue les réglages, l'image est cliquable :

Paramètres plus détaillés de la figure, l'image est cliquable :

Analisons les paramètres.

Initialement, nous configurons métrique, c'est la valeur selon laquelle tous les champs seront agrégés. Les métriques sont calculées sur la base des valeurs extraites d'une manière ou d'une autre des documents. Les valeurs sont généralement extraites des champs du document, mais peuvent également être générées à l'aide de scripts. Dans ce cas, nous définissons Agrégation : Compte (nombre total de logs).

Après cela, nous divisons le tableau par segments (champs) selon lesquels la métrique sera calculée. Cette fonction est assurée par le paramètre Buckets, qui se compose à son tour de 2 types de réglages :

1. split rows — ajout de colonnes et ensuite division du tableau en lignes
2. split table — division en plusieurs tableaux selon les valeurs d'un champ spécifique.

Dans buckets il est possible d'ajouter plusieurs divisions pour créer plusieurs colonnes ou tableaux, les limitations sont davantage logiques. Dans l'agrégation, on peut choisir comment la division en segments se fera : ipv4 range, date range, Terms, etc. Le choix le plus intéressant est précisément Terms et Significant Terms, la division en segments se fait selon les valeurs d'un champ d'index donné, la différence entre eux réside dans le nombre de valeurs retournées et leur affichage. Comme nous souhaitons diviser le tableau par le nom des blades, nous choisissons le champ — product.keyword et définissons la taille à 25 valeurs retournées.

Au lieu de lignes, dans elasticsearch, il existe 2 types de données — text et keyword. Si vous souhaitez effectuer une recherche en texte intégral, vous devez utiliser le type text, ce qui est très pratique lors de l'écriture de votre service de recherche, par exemple, vous recherchez une mention d'un mot dans une signification spécifique d'un champ (texte). Si vous souhaitez uniquement une correspondance exacte, vous devez utiliser le type keyword. Le type de données keyword doit également être utilisé pour des champs nécessitant un tri ou une agrégation, c'est-à-dire, dans notre cas.

En conséquence, Elasticsearch compte le nombre de journaux sur une certaine période en agrégant par valeur dans le champ produit. Dans le Custom Label, nous définissons le nom de la colonne qui sera affiché dans le tableau, nous définissons la période pendant laquelle nous rassemblons les journaux, nous lançons le rendu - Kibana envoie une requête à Elasticsearch, attend la réponse et visualise ensuite les données obtenues. Le tableau est prêt !

Diagramme circulaire des événements de prévention des menaces

L'information sur le pourcentage de réactions suscite un intérêt particulier detect et prevent sur les incidents de sécurité de l'information dans la politique de sécurité actuelle. Pour ce cas, un diagramme circulaire est bien adapté. Nous choisissons dans Visualize - Pie chart. De plus, dans la métrique, nous définissons l'agrégation par le nombre de journaux. Dans les buckets, nous réglons Terms => action.

Tout semble correct, mais les valeurs affichées concernent tous les bléds, il est donc nécessaire de filtrer uniquement ceux qui fonctionnent dans le cadre de la prévention des menaces. Par conséquent, nous configurons absolument filter pour rechercher des informations uniquement sur les bléds responsables des incidents de sécurité de l'information - product: («Anti-Bot» OR «New Anti-Virus» OR «DDoS Protector» OR «SmartDefense» OR «Threat Emulation»). L'image est cliquable :

Et des réglages plus détaillés, l'image est cliquable :

Tableau des événements IPS

Ensuite, il est très important du point de vue de la sécurité de l'information de passer en revue et de vérifier les événements par bléd IPS et Émulation des menaces, qui ne sont pas bloqués par la politique actuelle, afin de pouvoir ensuite soit passer la signature en prevent, soit si le trafic est valide - ne pas vérifier la signature. Nous créons le tableau de la même manière que dans le premier exemple, seulement avec la différence que nous créons plusieurs colonnes : protections.keyword, severity.keyword, product.keyword, originsicname.keyword. Nous configurons absolument un filtre pour rechercher des informations uniquement sur les bléds responsables des incidents de sécurité de l'information - product: ( «SmartDefense» OR «Threat Emulation»). L'image est cliquable :

Des réglages plus détaillés, l'image est cliquable :

Diagrammes des sites les plus visités

Pour cela, créons une figure — Barre verticale. Nous utilisons également la métrique count (axe Y), et sur l'axe X, nous utiliserons comme valeurs le nom des sites visités — “appi_name”. Il y a une petite astuce, si nous lançons les paramètres dans la version actuelle, tous les sites seront marqués sur le graphique d'une seule couleur. Pour les rendre multicolores, nous utilisons un paramètre supplémentaire — “split series”, qui permet de diviser une colonne déjà créée en plusieurs valeurs, en fonction du champ choisi bien sûr ! Cette division peut être utilisée soit comme une colonne multicolore par valeurs en mode empilé, soit en mode normal pour créer plusieurs colonnes selon une valeur de l'axe X. Dans ce cas, nous utilisons la même valeur que sur l'axe X, ce qui permet de rendre toutes les colonnes multicolores, elles seront codées par couleur en haut à droite. Dans le filtre, nous définissons — product:«URL Filtering» afin de voir les informations uniquement sur les sites visités, l'image est cliquable :

Paramètres :

Diagramme d'utilisation des applications les plus dangereuses

Pour cela, créons une figure — Bar Verticale. Nous utilisons également la métrique count (axe Y), et sur l'axe X, nous utiliserons comme valeurs le nom des applications utilisées - “appi_name”. Le plus important est de définir le filtre — product: «Application Control» AND app_risk: (4 OR 5 OR 3 ) AND action:«accept». Nous filtrons les journaux par le blade Application Control, ne prenant que les sites classés comme sites à risque Critique, Élevé, Moyen et uniquement si l'accès à ces sites est autorisé. L'image est cliquable :

Paramètres, cliquables :

Tableau de bord

La visualisation et la création de tableaux de bord se trouvent dans un menu séparé — Tableau de bord. Ici, tout est simple, un nouveau tableau de bord est créé, une visualisation est ajoutée, disposée à des emplacements de choix et c'est tout !

Nous créons un tableau de bord, à partir duquel nous pourrons comprendre la situation de base concernant la sécurité des informations dans l'organisation, bien sûr, uniquement au niveau de Check Point, l'image est cliquable :

Sur la base de ces graphiques, nous pouvons comprendre quelles signatures critiques ne sont pas bloquées sur le pare-feu, où se rendent les utilisateurs et quelles sont les applications les plus dangereuses qu'ils utilisent.

Conclusion

Nous avons exploré les possibilités de visualisation de base dans Kibana et créé un tableau de bord, mais cela n'est qu'une petite partie. Par la suite, nous examinerons séparément la configuration des cartes, le travail avec le système Elasticsearch, nous nous familiariserons avec les requêtes API, l'automatisation et bien d'autres choses encore !

Alors restez à l'écoute pour les mises à jour (Telegram, Facebook, VK, Blog de solutions TS), Yandex.Zen.

Source : habr.com