Collecte de logs Synology #3 : Création de règles de détection

---

1. Introduction
2. Création de la règle
3. Test de la règle
4. Conclusion

---

1. Introduction

Nous voici dans le dernier article de cette série sur la supervision des logs de votre NAS Synology. Nous avons vu précédemment comment mettre en place la collecte côté NAS et ensuite comment parser et mapper correctement les événements côté QRadar. Dans ce dernier article, nous allons créer une règle de détection maintenant que nous avons tout en main pour le faire.

Nous allons voir ici comment superviser les cas d’accès excessifs aux fichiers, ce sont des scenarii qu’il est très important de superviser pour détecter les exfiltrations de fichiers.

2. Création de la règle

Pour créer une règle, il existe 2 manières de faire :

• Via la page Offense
• Via le Use Case Manager

Premièrement, via la vue “Offense” il faut faire comme ceci :

1. Cliquez sur “Offense” dans le panel des onglets QRadar
2. Cliquez sur “Rules” dans les menus
3. Dans le menu des actions en haut, cliquez sur “Actions” puis “New Event Rule”
4. Une nouvelle fenêtre va s’ouvrir et vous allez ensuite entrer dans le wizard de création de règle de détection

L’autre possibilité de création de règles est via le “Use Case Manager”, il faut alors faire comme cela :

1. Cliquez sur “Use Case Manager” dans le panel des onglets QRadar
2. Dans le menu des actions, cliquez sur “+”
3. Une nouvelle fenêtre va s’ouvrir et vous allez ensuite entrer dans le wizard de création de règle de détection

La deuxième méthode va vous permettre un affichage plus “friendly” mais nécessite l’installation de l’extension “Use Case Manager”, donc pour les instances Community Edition avec peu de ressources vous pouvez garder la première méthode.

3. Test de la règle

Maintenant que nous avons vu comment créer une règle de détection, nous allons nous pencher sur la création de notre règle. Comme dit dans l’introduction, nous souhaitons superviser les accès excessifs aux fichiers de notre NAS. Il faut donc dans un premier temps que nous fabriquions ce premier bloc “Accès à un fichier”. C’est cette méthode, expliquée plus en détail dans cet article : https://staze.fr/comment-surveiller-vos-equipements-partie-5/ de la segmentation, qui est essentielle pour que vos règles soient plus facilement :

• compréhensibles : en effet, comme dans du code ou dans une phrase, il est plus facile de faire passer un message via des petites phrases simples mises bout à bout qu’un gros bloc de texte sans virgules, ni points.
• scalables : si l’on souhaite étendre cette règle à plusieurs clients facilement avec des cas particuliers pour chacun.
• réutilisables : cette segmentation a un effet bénéfique à long terme sur votre système puisque pour les prochaines de détection, vous pouvez réutiliser certains blocs d’une règle.

En appliquant ce principe à notre cas d’usage, on souhaite créer un premier bloc pour la détection d’un simple accès à un fichier.

1. Sélectionnez l’assertion “when the event category for the event is one of the following categories” en filtrant via la barre de recherche puis en cliquant sur “+” pour l’ajouter dans l’algorithme de règle.
2. Cliquez sur le mot “categories” de l’assertion que vous venez de rajouter (il doit être cliquable comme sur la capture ci-dessus).
3. Dans la nouvelle fenêtre qui vient de s’ouvrir, il faut sélectionner la “High Level Category” : “Audit” ainsi que les “Low Level Category” comme présentées dans la capture en jaune. Pour chacune, il faut cliquer sur “Add +” pour l’ajouter dans l’encadré “Selected items”.
4. Une fois que toutes les “Low Level Category” correspondant à de l’accès fichier ont été sélectionnées, vous pouvez cliquer sur “Submit”

Nous avons notre premier bloc de détection fonctionnel, il faut maintenant l’exporter en tant que “Building Block” en cliquant sur le bouton associé (présent au dessus de l’encadré comportant les assertions de règles dans la capture ci-dessus).

Maintenant, nous pouvons passer à la création de la règle de détection utilisant le bloc de détection créé juste avant. Pour ce faire, il faut reproduire le processus précédemment énoncé mais les assertions choisies vont être différentes. Il va falloir utiliser :

• “when these rules (1) match at least this many (2) times with the same event properties (3) and different event properties (4) in this many (5) minutes (6)”

En choisissant ensuite les valeurs suivantes :

1. Le nom du bloc fait plus haut, par exemple “BB:GlobalFileAccess”.
2. Le nombre de fois par unité de temps à partir duquel on va considérer que ce n’est pas normal. Pour cette partie là, je vous laisse choisir.
3. La ou les propriété(s) que l’on souhaite avoir en commun parmi tous les événements, cela peut être le nom d’utilisateur si l’on souhaite superviser des accès de fichiers par utilisateur. Cela peut être également via l’IP pour détecter des sources accédant aux fichiers.
4. La ou les propriété(s) que l’on ne souhaite pas avoir en commun parmi tous les événements, dans notre cas cela va être le nom du fichier. Dans des cas particuliers cela peut être le nom du dossier par exemple.
5. Le nombre d’unité de temps. Pour cette partie là, je vous laisse choisir.
6. L’unité de temps parmi “minutes”, “hours” ou encore “days”. Pour cette partie là, je vous laisse choisir.

Une fois que vous avez choisi tous les champs, il faut mettre un nom à notre règle de détection et cliquer sur “Next>>”. Dans la page suivante du wizard nous allons configurer la réponse apportée quand les assertions de notre règle renvoient “Vrai”. Dans notre cas, nous allons seulement “Dispatch New Event” comme ceci :

Cela va permettre d’avoir un événement qui va être généré par le Custom Rule Engine (la boîte qui processe tous les événements pour voir si cela correspond à certains blocs de détection ou règles). Il est intéressant de passer par cette étape avant de passer en production pour évaluer le nombre de fois où la règle se déclenche. Enfin, avant de cliquer sur “Next>>” il faut s’assurer que la case d’activation de la règle est bien cochée, après vous pouvez finaliser le wizard en cliquant sur “Next>>” jusqu’à la fin puis “Finish”.

Avant de passer à la conclusion, nous allons valider que notre règle fonctionne correctement. Pour ce faire, appliquez les filtres dans le Log Activity comme ceci :

puis mettez l’affichage en temps réel et effectuez des actions sur les fichiers en prenant soin de dépasser le seuil fixé dans votre règle. Si le seuil est dépassé, vous allez avoir l’événement similaire à celui présent dans la capture ci-dessus venant du Custom Rule Engine. En ouvrant l’événement, on constate, en descendant dans la page de l’événement, les blocs et les règles de détection qui matchent avec cet événement.

4. Conclusion

Nous voici à la conclusion de cette série d’articles. J’espère qu’elle vous a permis de mettre en place une supervision plus poussée de vos NAS Synology et que cela vous a permis d’en apprendre encore plus sur les différents aspects d’une collecte non standard dans QRadar.

N’hésitez pas à me faire un retour sur des aspects qui pourraient être creusés sur cette technologie ou sur d’autres technologies qui ne sont pas comprises par QRadar. Vous pouvez également me faire des retours plus globaux sur l’article pour que les prochains soient encore meilleurs 🤗