L’enjeu lors de la mise en place d’un SOC est de disposer d’un maximum de sources pour pouvoir collecter les évènements, mais surtout permettre leurs corrélations.
En effet, une connexion valide au SI n’est seul pas en soit un évènement marquant, mais si ce même identifiant est utilisé dans la foulée depuis une IP provenant d’un autre pays, alors le cas est différent et nécessite investigation pour s’assurer que l’identifiant en question n’a pas été compromis.
Cet exemple sur l’authentification est à généraliser sur l’ensemble du SI pour dé siloter la sécurisation des infrastructures et services afin de disposer d’une vue à 360°.
Claranet Cyber Security en tant qu'expert MSSP vous accompagne dans la sécurisation de vos infrastructures et services. Dans cet article, nous allons montrer notre capacité et expertise à ajouter des sources de logs non native de Microsoft Sentinel qui est le SIEM / SOAR cloud natif de Microsoft hébergé dans Microsoft Azure.
Voici donc un exemple d'intégration d’une source de logs Sysmon dans Microsoft Sentinel via le nouvel agent AMA qui vient remplacement de l’agent MMA. Pas d’inquiétude pour les profils moins technique, nous réalisons cette intégration pour vous dans le cadre de notre offre SOC Managé.
Quand on parle détection d'évènements anormaux ou malicieux sur les machines Windows - et même plus récemment Linux - le nom qui ressort le plus souvent : Sysmon.
Année après année, Sysmon reste l’un des meilleurs outils pour détecter des incidents de sécurité grâce à ses capacités d’ajouter des logs pour y créer des règles de détection personnalisées. Il est le compagnon idéal des EDR (Endpoint Detect & Response) afin de coupler et corréler les différentes alertes.
Alors pourquoi autant de succès ? L’outil est facilement déployable et configurable dans un SI, en constante amélioration en ajoutant des fonctionnalités de détection (requêtes DNS, New content in the clipboard, etc.), et surtout… il est gratuit !
Cet article n’a pas pour but de montrer comment installer Sysmon, la page officielle de Microsoft l’explique très bien : Sysmon Sysinternals
Pour les fichiers de configuration, deux exemples :
- Par SwiftOnSecurity (compte twitter) : GitHub - SwiftOnSecurity/sysmon-config: Sysmon configuration file template with default high-quality event tracing
- Par olafhartong (Compte Twitter) : GitHub - olafhartong/sysmon-modular: A repository of sysmon configuration modules
1. L’agent AMA
Le nouvel agent AMA (Azure Monitor Agent) va remplacer l’ancien agent MMA (Microsoft Monitoring agent, also named Log Analytic Agent or Operations Management Suite (OMS)) qui sera déprécié en 2024.
L’agent AMA ajoute de nombreuses fonctionnalités intéressantes :
L’outil est capable de filtrer les logs que nous voulons récupérer et possède une capacité d’EPS (Event Per Seconde) plus élevée, ces deux fonctionnalités sont appréciables dans le cadre d’un SIEM (réduction de cout et meilleure pertinence dans la collecte des logs du fait du tri des logs en amont).
Cette récupération des logs se fait par une ressource appelée “Data Collection Rules”. Cette dernière permet de définir :
- Quel log nous voulons collecter
- Sur quelle machine la collecte doit être faite
- Dans quel Log Analytics les logs devront être envoyés
Toutes les différences sont détaillées ici : Migrate from legacy agents to Azure Monitor Agent - Azure Monitor
On premise environment
Si vous souhaitez installer l’agent AMA sur un environnement autre qu’Azure (On-premise, AWS, etc.) il vous faut au préalable installer le connecteur “Azure Arc Connected Machine agent” afin de pouvoir embarquer la machine dans Azure. Azure Arc permet notamment de manager des serveurs on premise ou d'un autre cloud provider au sein d’Azure, ce qui a pour avantage d’avoir une configuration iso entre ces environnements.
Les différentes manières d’installer cet agent : Azure Connected Machine agent deployment options - Azure Arc
2. Récupération des logs dans Microsoft Sentinel
L’installation de l’agent AMA peut être faite de manière indépendante ou en même temps que la configuration des sources de log à collecter. Nous allons choisir cette dernière option pour cet article.
Pour commencer, il suffit de :
- Chercher “Monitor” dans la barre de recherche
- Choisir “Data Collection Rules” sous “Settings” dans le bandeau latéral
- Cliquer sur “Create” pour commencer la création d’une DCR
- Ajouter les machines dont vous voulez collecter les logs en cliquant sur “Add resources”.
- Il est possible de choisir les machines une par une ou choisir un resource group ou même une subscription.
- Cliquer sur “Add data source” pour configurer la collecte des logs Sysmon
- Choisir “Windows event logs” dans “Data source type”
- Choisir “Custom”
- Remplir en mettant le XPath des logs Sysmon : Microsoft-Windows-Sysmon/Operational!*
- Dans l’onglet “Destination”, sélectionner le Log Analytics où votre Sentinel est connecté dessus
- Finaliser en cliquant sur “Review + create”
Vérification de l’envoi des logs
L’ingestion des premiers logs peut mettre jusqu'à 1h, plusieurs tasses de café ou une bonne séance de sport, patientez à votre manière !
Depuis votre Sentinel, effectuer cette query :
Vous devriez voir les logs Sysmon remonter des machines dont vous avez configuré la collecte.
3. Exploitation des logs
Pour pouvoir utiliser efficacement les logs Sysmon afin de créer des règles de détection ainsi que des Workbooks, il est nécessaire de parser ces logs. En effet, toutes les informations importantes sont contenues dans le champ “ParameterXml“ au format XML.
Microsoft Sentinel propose une fonctionnalité nommée “Function” permettant de sauvegarder des requêtes KQL intégrant le parsing des logs.
Pour mettre en place cette fonctionnalité :
- Dans votre Sentinel, cliquer sur “Logs” situé sous “General”
- Récupérer la query KQL suivante créée par Cyb3rWard0g (Compte Twitter):SysmonKQLParserV13.22.txt
- Cliquer sur la flèche à côté de “Save” puis “Save as function”
- Choisissez le nom que vous utiliserez pendant vos futures recherches
Dorénavant, vous pouvez simplement faire des recherches en filtrant avec les champs disponibles dans cette nouvelle fonction “Sysmon” :
Conclusion
Comme nous avons pu le voir dans cet article, l’intégration des logs Sysmon dans le SIEM Microsoft Sentinel via ce nouvel agent se fait de manière très simpliste et sommaire.
Avec cette nouvelle source de log, vous pouvez commencer à exploiter pleinement la puissance du SIEM :
- Création de nouvelles règles de détection ;
- Visualisation des données avec les Workbooks ;
- Etablir et lancer vos modèles de Threat Hunting dans l’espace dédiée ;
- etc…