Introduction et rappel(s)
Comme nous l’avons vu dans mon précédent article, Azure Sentinel est le SIEM de Microsoft qui se positionne comme concurrent et alternative à des solutions telles que Splunk, QRadar et d’autres.
Il y a toutefois une différence importante puisque sur Azure Sentinel ne se déploie pas « localement » sur des serveurs mais se présente comme une solution SaaS (as-a-service) que vous pouvez utiliser directement depuis le portail web de Azure.
Objectif
L’objectif de cet article va être de voir comment nous pouvons intégrer dans Azure Sentinel des informations qui proviennent des serveurs/VM qui ne seraient pas hébergées dans Azure (et donc dans votre datacenter en propre ou même chez un autre fournisseur Cloud). Et vous allez voir que c’est très simple. 🙂
Interconnexion de vos serveurs avec Azure Sentinel
Pour le contexte : je dispose d’un serveur physique chez Online.net qui me permet de réaliser certains Labs/Tests avec un petit nombre de VM.
Nous allons donc voir comment il est possible de récupérer les évènements de sécurité qui seraient disponibles dans les Event Viewers de ces serveurs directement dans Azure Sentinel.
Connectez-vous à votre espace Azure Sentinel. Dans la partie Configuration, puis Data Connectors, cherchez vers le bas Security Events. C’est le connecteur que nous allons utiliser pour récupérer les évènements de Sécurité de nos Event Viewers. 😉
Cliquez sur Open connector page pour voir les étapes de mise en place. Vous allez voir que nous allons être guidé tout au long de la mise en place.
Sélectionnez le volume d’évènements que vous souhaitez récupérer. Dans mon cas, je choisi All Events (je ne paye pas le stockage mais peut-être devrez-vous adapter ce choix en fonction du nombre de VM dont vous disposez et du volume de Logs qui peut être généré). Cliquez ensuite sur le lien bleu « Download & Install agent for non-azure windows machines« .
Pour l’instant, on voit que je dispose de 0 Windows computers connected. Téléchargez l’agent qui correspond au système dont vous voulez récupérer les évènements (à priori le plus probable sera la version 64 bit). Notez les informations affichées en dessous car nous allons en avoir besoin plus loin lors du déploiement de l’agent (ou gardez la page à portée de clic) :
- Workspace ID
- Primary Key
- Secondary Key
Installation de l’agent Microsoft Monitoring Agent (MMA)
Récupérez l’exécutable précédemment téléchargé et envoyez-le sur tous les serveurs que vous souhaitez connecter à votre Azure Sentinel. L’installation sera la même partout (si je ne dis rien, considérez que vous pouvez conserver les réglages par défaut ou simplement faire Next).
Vous avez peut-être déjà rencontré cet agent Microsoft si vous travaillez avec des produits comme SCCM ou bien que vous ayez eu l’occasion de travailler avec des PFE pour réaliser des Audits de votre infrastructure (c’est le même outil). Dans notre cas, nous souhaitons bien l’intégrer à un notre espace Azure Log Analytics (anciennement OMS) – sur lequel notre Azure Sentinel s’appuie. Cochez donc la case du milieu. 🙂
Il ne vous reste plus qu’à recopier les informations que nous avions précédemment mis de côté : Workspace ID et Primary Key.
Pour toute le reste, cliquez simplement sur Suivant puis Installer.
Après quelques instants, l’agent est déployé. J’ai pour habitude de redémarrer le serveur à chaque fois mais ce n’est pas une obligation.
NB : Dans le cas où vos serveurs n’ont pas accès à Internet (ce qui serait tout à fait logique), vous pouvez utiliser le composant que l’on appelle Log Analytics Gateway. Il s’agit d’un composant qui se déploie en supplément, en générale sur un serveur indépendant en DMZ et qui jouera le rôle de relai pour tous les agents MMA déployés au sein de votre infrastructure. Plus d’infos en consultant ce lien.
Vérifier les remontées dans Azure Sentinel
Retournez sur votre portail Azure Sentinel. Si vous cliquez à nouveau sur le connecteur Security Events, vous devriez voir le nombre de serveurs qui a été ajouté à votre Sentinel et pour lesquels on récupère le contenu des évènements de Sécurité.
Si vous cliquez sur le lien Go to logs, vous exécuterez alors automatiquement une query en KUSTO qui vous donne la liste et le nom des serveurs que vous venez de rattacher à Azure Sentinel.
Heartbeat | where OSType == 'Windows' | summarize arg_max(TimeGenerated, *) by SourceComputerId
Comme vous pouvez le voir, j’ai activé les remontées d’évènements pour 3 serveurs : 1 AAD Connect et 2 Domain Controllers.
On peut regarder en détails quelles sont les remontées en exécutant la query suivante :
SecurityEvent
Notez que pour l’instant je n’ai fait aucun filtre. J’affiche simplement toutes les informations qui sont contenues dans « SecurityEvent » mais je pourrais bien évidemment effectuer un filtrage plus précis pour rechercher une information particulière : nom de serveur, nom de compte utilisateur, etc.
Notez également que l’on retrouve les évènements tels qu’ils sont générés dans les Event Viewers avec les mêmes numéros Event ID – ce qui vous permettra de faire des recherches plus fines voir même d’associer une alerte particulière avec Azure Monitor ou directement déclencher un incident dans Azure Sentinel lorsqu’un évènement particulier apparaît ! 🙂
Nous aurons l’occasion de revenir là-dessus dans un prochain article. 🙂
