1. Introduction
Dans ce dernier volet de la série axée autour de la construction d’un mini-SOC utilisant QRadar CE, nous allons voir comme détecter des attaques perpétrées sur vos équipements. Pour cela nous allons créer des règles de détection qui vont générer des alertes quand toutes les conditions définies sont réunies.
2. Création d’une règle de détection
a. Où créer des règles de détection ?
Pour la création des règles, vous pouvez passer par 2 endroits :
- La vue “Offenses”
- La vue “Use Case Manager”
Pour la première vue, il faut aller dans l’onglet “Offenses” puis dans le volet à gauche cliquer sur “Rules”. Vous allez avoir l’ensemble des règles qui sont en place (actives ou non) sur votre QRadar.
Dans la capture ci-dessus, voici-ci quelques endroits clés pour bien commencer avec cette vue :
- souligné en vert : filtrer pour voir les “Rules” ou les “Building Blocks” (nous verrons la distinction entre ces deux types d’objets dans la partie suivante)
- souligné en rouge : effectuer une recherche textuelle
- surligné en jaune : bouton pour effectuer les différentes actions comme l’ajout, la suppression d’objets
- l’encadré “Rule” qui va afficher l’assertion de l’objet choisi
D’un autre côté vous pouvez également effectuer toutes ces actions dans l’onglet “Use Case Manager”. Pour cela, il faut au préalable :
- ajouter l’extension en question disponible ici
- installer et configurer l’extension (nécessite un token)
Une fois que ces prérequis sont cochés, vous aurez un outil plus poussé pour la visualisation de vos règles mais également pour comprendre la couverture que vous apporte vos règle d’un point de vue sécurité (via le standard Mitre ATT&CK). Voici, comme pour la précédente vue, un rapide tour d’horizon de ce que vous pouvez faire :
- souligné en vert : filtrer pour voir les “Rules” ou les “Building Blocks” (nous verrons la distinction entre ces deux types d’objets dans la partie suivante)
- souligné en rouge : effectuer une recherche textuelle
- surligné en jaune : bouton pour effectuer les différentes actions comme l’ajout, la suppression d’objets
Remarque : j’ai déjà expérimenté des dysfonctionnements à utiliser les 2 vues en même temps pour modifier des règles, il est donc important de faire les modifications d’une règle sur un seul onglet et rien d’autre pour éviter les mauvaises surprises 😊
b. Les étapes de création d’une règle de détection
Il est maintenant temps de faire une pause un instant pour expliquer ce que sont les règles et les building blocks. En effet, maîtriser ces concepts est un point essentiel pour pouvoir arriver à vos fins le plus facilement possible, tout en respectant certains standards. Pour paraphraser la documentation, un building block se compose d’une ou plusieurs assertions simples, qui, lorsqu’elles sont validées, ne vont pas exécuter d’actions. En effet, elles vont permettre de construire des règles, souvent plus complexes, qui elles, peuvent si vous le souhaitez lancer des actions quand les assertions sont vraies.
S’il l’on résume :
- Un building block (que l’on appellera BB1) peut être une assertion comme par exemple “renvoie vrai quand l’IP source est 127.0.0.1”
- Un building block (que l’on appellera BB2) peut être une assertion comme par exemple “renvoie vrai quand la propriété username vaut toto”
- Une règle (que l’on appellera R1) peut être une assertion comme par exemple “renvoie vrai quand BB1 est vrai 5 fois en 10 minutes”
- BB1 ne peut pas générer d’offense ou faire une quelconque action si j’ai un événement avec l’IP source qui vaut “127.0.0.1”
- R1 peut effectuer une action quand son assertion est vraie, comme par exemple envoyer un mail
- Une règle (que l’on appellera R2) peut être une assertion se composant de BB1 et BB2
Si vous avez compris tout cela, alors vous êtes parés pour la suite. Si vous devez retenir une chose, c’est la suivante :
“Découpez votre problème complexe en une agglomération de solutions simples (les building blocks) pour avoir une solution complexe (la règle) qui résout votre problème.“
3. Exemples de règles
a. Détection de bruteforce htaccess
La première règle que nous allons réaliser va nous permettre de détecter quand une entité, souvent malveillante, effectue une attaque par bruteforce sur votre htaccess (Rendez-vous ici si vous ne savez pas ce que c’est et que vous souhaitez en mettre en place sur vos sites web).
Dans un premier temps nous allons identifier quel événement va nous permettre d’identifier que quelqu’un a échoué à se connecter. Pour cela, j’ai effectué quelques tests pour vous et j’ai trouvé le log suivant :
apache2-error [Thu Nov 24 15:57:33.319995 2022] [auth_basic:error] [pid 25639] [client 10.10.10.10:41200] AH01617: user test: authentication failure for "/wp-admin/js/user-profile.min.js": Password Mismatch, referer: https://**REDACTED**/wp-login.php
Ainsi, on peut se dire que si cet événement arrive X fois depuis la même source alors je lève une alerte. Comme allons nous faire ça ? Comme dit plus haut, il faut découper le problème en plus petit comme ceci :
- faire un building block BB1 qui va renvoyer vrai quand il y a un échec d’authentification sur le htaccess
- faire une règle qui renvoie vrai quand BB1 renvoie vrai X fois avec la même IP source en X minutes
Construction de BB1 :
and when the event(s) were detected by one or more of Linux OS
and when the event QID is one of the following (4750002) An authentication attempt was unsuccessful
On voit ici que j’ai choisi de spécifier la log source type “Linux OS” car les événements recherchés ne proviennent que de ce type de log sources et que je n’ai pas besoin de vérifier pour tous les types possibles (Windows par exemple).
Construction de R1 :
and when BB1 match at least 5 times with the same Source IP in 5 minutes
Vous avez maintenant l’assertion de votre première règle, nous allons rajouter les actions à effectuer quand elle est vraie. Pour cela, il faut avant dans le Rule Wizard jusqu’à la page similaire à celle ci-dessous :
Tout d’abord, surligné en vert, j’ai coché “Dispatch New Event” pour qu’un événement soit généré par la log source “Custom Rule Engine” lorsque l’assertion de R1 est vraie. J’ai choisi un nom à l’événement qui sera créé et j’ai également choisi de ne pas cocher “Ensure the dispatched event is part of an offense” pour ne pas avoir de génération d’offense tout de suite. Vous me direz pourquoi ? parce que si ma règle n’est pas bonne et qu’elle génère beaucoup trop de faux-positifs, cela ne va pas créer plein d’offense.
Si l’on continue, vous pouvez voir que j’ai choisi de cocher “Add to a Reference Set” qui va nous octroyer la possibilité d’ajouter des valeurs récupérées dans les événements dans des référentiels. Par exemple, dans notre cas j’ai choisi d’ajouter l’IP Source dans la liste suivante “Malicious IP” (IP malveillante), ainsi je récupèrerai dans cette liste les IP qui ont tenté de bruteforce mon htaccess. Je peux également utiliser cette liste pour d’autres règles comme celle que nous allons voir juste après.
Avant cela, ne pas oublier de cliquer sur “Finish” pour valider la création de la règle.
b. Connexion depuis des IPs malveillantes
La seconde règle que nous allons voir aujourd’hui est encore plus simple. En effet, je veux simplement lever une alerte quand j’ai une connexion réussie depuis une IP que j’ai catégorisé comme “malveillante”. Comme pour la règle précédente, je découpe mon problème :
- faire un building block BB1 qui renvoie vrai quand l’événement est un événement correspondant à une connexion réussie (Connexion SSH par exemple)
- faire un règle R1 qui renvoie vrai quand BB1 est vrai et que l’IP source fait partie de mon référentiel d’IP catégorisée comme “malveillante”
Construction de BB1 :
and when the event category for the event is one of the following Authentication.General Authentication Successful, Authentication.User Login Success, Authentication.SSH Login Succeeded
Construction de R1 :
and when an event matches any of the following BB1
and when any of Source IP are contained in any of Malicious IP - IP
Pour la partie réponse, j’ai choisi de simplement générer un événement.
4. Conclusion
Et voilà, vous avez vu comment se faisait la création d’alerte dans QRadar. Cet article clôture la première série d’article sur ce blog. Ne vous inquiétez pas je n’en ai pas fini avec QRadar, j’ai volontairement laissé place au suspens pour la partie vérification du bon fonctionnement de nos règles, puisque cela sera l’objet du prochain article.
En effet, nous verrons comment vérifier proprement que nos règles sont fonctionnelles sans avoir à effectuer des actions pouvant compromettre l’intégrité de votre serveur ou de votre poste de travail (de votre environnement). Nous parlerons également de la partie “Offense” plus en détail.
N’hésitez pas à commenter avec vos idées de règles de détection qui pourraient servir pour des petits périmètres comme ce que nous voyons ici ou vos questions 😊
5. Bibliographie
Qu’est-ce qu’un BB : https://www.ibm.com/docs/en/qsip/7.4?topic=phase-qradar-building-blocks
Merci d’avoir suivi ce petit tuto, en espérant que cela vous ait été utile. N’hésitez pas à me communiquer vos ressentis, tips…etc via le formulaire ci-dessous.