Installation et configuration de Azure Sentinel

Introduction

Aujourd’hui je vous propose une courte présentation de Azure Sentinel au travers d’un cas d’utilisation très simple. Mais avant d’aller plus loin : Azure Sentinel qu’est-ce que c’est ? 😉

Azure Sentinel est la solution SIEM proposée par Microsoft. Pour rappel, SIEM signifie Security Information and Event Management. Concrètement, il s’agit d’une solution qui a pour objectif à regrouper en un seul et même endroit l’ensemble des logs de votre infrastructure. Ce volume de données peut ensuite être analysé pour alimenter des alertes, graphiques, dashboards et autres formats de données qui vous permettent de mesurer la bonne santé de votre infrastructure et d’en assurer la sécurité de manière pro-active.

Si vous n’avez jamais entendu parlé de Sentinel, peut-être avez-vous déjà entendu parlé de Splunk ou QRadar qui sont des solutions concurrentes alternatives mais qui ont le même objectif. 🙂

L’une des différences fondamentales de Azure Sentinel par rapport à ses concurrents est que Microsoft a fait le choix d’une solution SaaS. C’est-à-dire que vous n’aurez pas besoin de déployer et maintenir une infrastructure composée de plusieurs dizaines de serveurs à faire évoluer dans le temps. Il vous suffit d’interconnecter les ressources que vous souhaiter superviser avec Azure Sentinel et Microsoft s’occupera d’aligner les ressources dont vous aurez besoin en fonction de la quantité de logs et de l’utilisation que vous ferez de Azure Sentinel. C’est un point assez notable sachant que dans la plupart des déploiement de SIEM, on commence d’abord par monter une infrastructure composée de plusieurs serveurs (et bien souvent pas des petites machines) ! 😉

Dans cet article, je vous propose de voir comment utiliser Azure Sentinel en mettant en place l’ensemble des composants qui seront nécessaire pour auditer Azure Active Directory et également mettre sur écoute un compte en particulier (le miens) – avec une règle personnalisée. 🙂

Création d’un espace Log Analytics Workspace

Avant toute chose, il est important de comprendre que lorsqu’il s’agit de gérer des Logs dans Azure, vous aurez besoin d’un espace Log Analytics Workspace. Azure Sentinel ne fait pas exception et aura besoin de ce composant également.

Cherchez ce composant dans votre portail Azure et créez un nouvel objet Log Analytics Workspace. Je vous laisse choisir votre organisation : Resource Group, choix du Datacenter Microsoft, … (dans mon cas j’ai choisi France Central).

Choisissez également votre mode de facturation. Dans mon cas, je dispose d’un souscription Test donc je n’ai pas trop le choix. Mais il est important de garder en tête que le coût d’un espace Log Analytics Workspace sera nettement moins cher si vous basculez sur un usage au GB / mois (par exemple 100GB, 200GB, etc.) plutôt qu’à l’usage – voir cette page.

Dans le jargon, nous avons créé notre « puit de Logs » dans lequel Azure Sentinel trouvera l’ensemble des Logs à analyser… 🙂

Création de notre espace Azure Sentinel

Nous allons maintenant pouvoir créer notre espace Azure Sentinel. Cherchez le termes « Sentinel » dans la barre de recherches du portail Azure et créez un nouveau workspace.

Sélectionnez l’espace Log Analytics Workspace sur lequel Azure Sentinel devra s’appuyer (évidemment celui que l’on a créé à l’étape précédente).

Une fois que c’est fait, vous devriez pouvoir accéder à votre espace Azure Sentinel.

Je ne vais pas passer dans toutes les options et menus disponibles. Je vous laisse le soin de les découvrir mais retenez les options suivantes que nous allons utiliser plus loin dans cet article :

• Logs : pour chercher dans les Logs de manière « brute » avec le language KUSTO (j’y reviens un peu plus tard) ;
• Incidents : là où vous pouvez visualiser l’ensemble des alertes qui ont été remontées par Sentinel ;
• Data Connectors : pour ajouter de nouvelles sources de données à votre Azure Sentinel (et c’est cette partie qui va nous intéresser tout de suite après) !

Supervision d’Azure Active Directory

Rendez-vous dans les options Data Connectors. Nous allons mettre sous monitoring Azure Active Directory.

Cherchez le connecteur appelé Azure Active Directory (proposé par Microsoft). Cliquez ensuite le bouton Open connector page.

Je vous invite également à prendre le temps de regarder la liste des connecteurs actuellement disponible. Elle augmente régulièrement mais je trouve amusant de constater que l’on peut intégrer les logs par exemple de AWS Cloud Trail ou d’autres appliances réseaux du marché… 🙂

Sélectionnez tous les types de Logs et validez avec Apply changes. Notez que vous devez disposer de licences Azure AD Premium. 😉

Après quelques instants, vous verrez que votre connecteur est désormais actif (c’est le seul à avoir un petit rectangle en « vert » devant).

Création d’une règle personnalisée dans Azure Sentinel

Retournez dans votre espace Azure Sentinel, puis dans le noeud Configuration et Analytics, localisez le bouton en haut à gauche Scheduled query rule. C’est là que nous allons pouvoir créer une nouvelle règle personnalisée.

Dans la nouvelle page qui s’ouvre nous allons pouvoir configurer l’ensemble des paramètres de notre règle.

Choisissez un nom pour votre règle, une description, une catégorie et un niveau d’importance (avec le code couleur associé). Dans mon cas, j’ai choisi un niveau d’alerte Medium – associé à la catégorie Initial Access (mais peu importe). Activez bien entendu votre règle avec l’option Status : Enabled. 😉

L’étape suivant consiste à définir la requête KUSTO qui permettra de tracer l’activité de connexion du compte Global Administrateur que nous souhaitons surveiller (dans mon cas, simplement mon compte personnel Global Administrator).

Dans la fenêtre ci-dessus, je choisi le requête suivante (c’est un exemple volontairement simple mais vous l’aurez compris la force de l’outil est de pouvoir faire à peu prés tout ce qu’on veut) :

SigninLogs
| where Identity == 'Firstname Lastname'

A vous de personnaliser la requête en fonction de vos besoins et bien évidemment on pourrait faire plus compliqué en prenant par exemple l’Object Id de l’objet dans Azure Active Directory. 🙂

Vous pouvez également utiliser le graphique en cliquant sur le lien à droite pour voir les derniers évènements qui correspondent à votre requête (ce qui accessoirement vous permet de vérifier qu’elle est correcte).

Pour la suite des réglages, vous pouvez conserver les options par défaut.

Tester notre règle

Après quelques instants et si vous utilisez le même compte Global Admin pour vous connecter à votre portail Azure, vous devriez (déjà) voir que l’alerte a été remontée par Sentinel.

Rendez-vous dans la partie Incidents voir les détails. On retrouve bien la présence de notre Alerte qui a été générée (et répétée à 3 reprises dans mon cas).

Vous pouvez cliquer sur View full details pour éventuellement obtenir davantage d’informations. On retrouve bien tous les éléments de notre alerte ainsi que le moment où elle s’est produite (Catégorie : Initial access, Importance : Medium, etc.).

Pour aller plus loin

Il s’agit d’un cas très simple. Mais cela vous permettra de bien comprendre la démarche. Pour toutes les informations stockées dans votre « puit de Logs » vous pourrez créer des alertes de la même façon en utilisant le language KUSTO pour extraire l’information qui vous semble pertinente.

Pour mieux appréhender le fonctionnement de ces requêtes, je vous encourage à tester l’option Logs depuis votre interface Sentinel (dans le menu à gauche). Entraînez-vous à faire des requêtes. Au début, vous n’allez pas savoir par quel bout le prendre mais vous verrez rapidement que les possibilités sont infinies. 🙂

Ci-dessus j’effectue une sélection plus fine pour ne lister les connexions que d’un Object Id particulier au sein de notre Azure Active Directory (l’object Id qui correspond à mon compte). Avec les indications supplémentaires « take 10 » je limite aux 10 résultats les plus récents et j’ordonne le tout en fonction de l’attribut TimeGenerated.

Dans l’exemple ci-dessus, je m’intéresse à d’autres Logs disponibles dans mon workspace, il s’agit de tous les évènements de Securité que j’ai pu récupérer sur 3 serveurs et avec l’option « render timechart » je peux créer à la volée un graphique qui me donne l’évolution et le nombre d’évènements de sécurité sur ces VM au cours du temps… 😉

Prochain article sur Sentinel, nous verrons donc comment déployer un agent localement sur des VM ou composant on-prem – ou simplement lorsqu’il n’existe pas un connecteur prêt à l’emploi ! 🙂