1. Introduction
Nous voici déjà dans le troisième volet de cette série autour de la collecte de logs. Après avoir établi les bases de la collecte, à savoir :
- Mettre en place l’outil de collecte et les premières configurations sur cet outil
- Mettre en place la collecte sur les équipements informatiques usuels : Windows, Linux
Nous allons voir comment il est possible de collecter des équipements non standards. Avant d’aller plus dans les détails il faut parler rapidement de ce qu’est un DSM pour « Device Support Module« , c’est un bout de code qui va analyser les événements reçus pour en extraire les champs standards en fonction du type d’équipement qui envoie les logs.
Il existe un DSM pour chaque type d’équipement collecté, par exemple il en existe un pour Linux OS, un autre pour Apache2… Malheureusement, il n’existe pas de DSM pour tout, et c’est là qu’il faut se mettre au travail et en faire un personnalisé.
Nous allons, non seulement, récupérer les logs correctement (le parsing), mais également leur attribuer des événements associés en fonction de plusieurs paramètres (le mapping).
Ce sont ces deux points névralgique de la collecte que nous allons aborder dans cet article, en effet, nous allons prendre pour acquis la bonne réception des logs de l’équipement que l’on souhaite superviser.
Dans tous les cas pour effectuer une collecte personnalisée, je suis toujours les étapes suivantes avant de passer au vif du sujet :
- Valider une méthode de collecte des événements : syslog, API, autre
- Valider les événements que vous souhaitez récupérer. En effet, si je ne veux surveiller que les actions sur les fichiers, je n’ai pas envie d’avoir les logs d’authentification
- Tester la bonne réception des logs ainsi que leur complétude via une comparaison entre ce qui est enregistré sur la machine source et ce qui arrive sur l’appliance QRadar
- Télécharger un échantillon des logs bruts réceptionnés
- S’assurer que dans les logs, il y a bien une valeur permettant d’identifier la catégorie du log et une autre valeur pour différencier les logs d’une même catégorie (un ID)
Une fois ces étapes validées je passe à la partie technique : le parsing et le mapping.
2. Le Parsing
Nous voici donc dans la première étape qui va permettre, « grossièrement », de dire à QRadar :
- le username est situé à tel endroit dans le log
- la catégorie de l’événement est situé après la valeur « category=«
- …
Vous avez compris l’idée 😊
Pour arriver à nos fins il faut ouvrir le « DSM Editor » via l’onglet « Admin » et on crée notre DSM avec « Create New »
On choisit un nom et on clique sur « Save« . Ensuite, on le sélectionne et on met nos logs de tests dans le workspace avec le bouton d’édition comme ci-dessous :
On récupère les 3 champs importants à un bon parsing d’événements :
- Event ID
- Event Category
- Log source time
Pour l' »Event Category », je souhaite ici que la catégorie soit le champ « openvpn » car cela va être une log source du VPN dédié. De plus les logs arrivent d’une gateway pour laquelle le champ qui diffère en fonction de l’application est celui-là.
En appliquant la bonne Regex on obtient le résultat suivant :
Pour trouver les bonnes Regex, je vous conseille d’utiliser ce site pour effectuer quelques tests et notamment trouver l’expression la plus optimale, qui va donc demander moins de ressources à QRadar : https://regex101.com/
Pour l' »Event ID« , nous allons procéder différemment car les logs sont très peu homogènes, j’ai donc effectué un travail de filtrage au préalable (cf Introduction) pour avoir seulement les quelques événements qui m’intéresse. Ensuite, en dernière condition pour l' »Event ID » je vais rajouter un « Event ID » commun à tous les logs (typiquement le hostname ici) pour mettre tous les autres logs dans une catégorie « Unwanted« .
Enfin, pour le parsing de la « Log source time« , il est majoritairement bon (ce qui est le cas ici), je n’ai donc pas besoin de la réécrire.
J’update mes colonnes dans l’aperçu avec ce que je souhaite comme informations et je constate qu’il me manque quelques champs, à savoir :
- Username
- Source IP
Une fois que les différentes colonnes que l’on souhaite sont bien parsées, on peut passer au mapping des événements :
3. Le Mapping
Pour l’event mapping cela se passe dans le deuxième onglet :
Pour les valeurs il faut mettre les valeurs que l’on souhaite pour un événement précis. Par exemple, pour les initiations de connexion je sais que l' »Event ID » est « TLS: Initial packet from » donc je vais mettre celui-là. Pour le champ « Event Category« , nous savons que c’est toujours la même catégorie.
Ensuite, il faut faire « Choose a QID« , puis en créer un avec le bouton adéquat. Il est toujours conseillé pour les DSM personnalisé de faire ses propres QID car QRadar réserve, dans la base de données, des QID spécifiquement pour le DSM que vous venez de créer. De plus, même si cela n’arrive pas régulièrement, les QID peuvent modifiées par IBM et donc faire dysfonctionner le travail que vous venez de faire.
4. Validation
Enfin, pour vérifier que tout fonctionne parfaitement, nous allons modifier les paramètres d’auto-détection des log sources pour ce type (cela ne s’appliquera pas aux autres types de log sources). Ainsi, il faut activer l’auto-détection des log sources pour que cette dernière soir correctement détectées, cela se trouve dans le dernier onglet comme vous pouvez le voir ci-dessous :
Une fois que les paramètres vous conviennent, vous cliquez sur « Save » dans la fenêtre du « DSM Editor« . En fonction de l’auto-détection que vous avez configuré, la log source va être créée plus ou moins rapidement. Pour facilement déboguer la situation, je vous conseille de vous mettre une vue dans « Log Activity » en direct et en filtrant sur la « Source IP » avec l’IP de l’équipement qui vous envoie les logs. Si tout se passe bien la log source passera de « SIM Generic » vers une nouvellement créée.
Et on obtient le résultat suivant :
5. Conclusion
En conclusion, la création de DSM personnalisé n’est pas si compliquée et elle permet en théorie de pouvoir collecter tout ce que vous souhaitez tant que le protocole de communication entre l’équipement et QRadar est fonctionnel.
Néanmoins c’est un travail minutieux et qui demande une grande rigueur pour ne pas avoir à retravailler vos mappings régulièrement ou même pire que vos logs soient mal catégorisés et que des erreurs dans les règles de détection en découlent.
Ainsi, comme dit dans l’introduction c’est un travail qui demande une mise à plat de :
- Ce que vous souhaitez collecter comme logs
- Comment est la syntaxe des logs
- Ce que vous souhaitez y récupérer comme informations en plus des standards nécessaires
Une fois que tous ces points sont clairement identifiés et définis cela devrait se dérouler sans accrocs pour peu que l’extraction des propriétés dans les logs soit usuelle.
Tout est bon, vous avez désormais sous votre surveillance (quasiment 🙄) tous les équipements informatiques. Nous verrons pas la suite comme effectuer des recherches dans cette mine d’informations que nous avons maintenant.
6. Bibliographie
Documentation généraliste sur QRadar : Slide 20 pour le DSM : https://info.techdata.com/rs/946-OMQ-360/images/Section 2 – Technical Sales Foundations for IBM QRadar for Cloud (QRoC)V1 P10000-017.pdf
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.