Installation et configuration de Azure Sentinel

Bannière 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.

Création de votre Log Analytics Workspace
Création de votre Log Analytics Workspace

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).

Création de votre Log Analytics Workspace
Création de votre Log Analytics Workspace

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.

Création de votre Log Analytics Workspace
Création de votre Log Analytics Workspace
Création de votre Log Analytics Workspace
Création de votre Log Analytics Workspace

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.

Création de votre workspace Azure Sentinel
Création de votre workspace Azure Sentinel

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).

Création de votre workspace Azure Sentinel

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

Création de votre workspace 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.

Supervision de Azure Active Directory avec Azure Sentinel
Supervision de Azure Active Directory avec Azure Sentinel

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é… 🙂

Supervision de Azure Active Directory avec Azure Sentinel
Supervision de Azure Active Directory avec Azure Sentinel

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

Supervision de Azure Active Directory avec Azure Sentinel
Supervision de Azure Active Directory avec Azure Sentinel

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.

Vue Incidents dans Azure Sentinel
Vue Incidents dans Azure Sentinel

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

Création d'une nouvelle règle Azure Sentinel
Création d’une nouvelle règle Azure Sentinel

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).

Plus d’informations sur le language KUSTO en consultant le lien suivant (je ne peux malheureusement pas tout détailler dans cet article). Mais l’idée c’est que c’est un language permettant de requêter au sein de notre “puit de Logs(language qui se trouve être “assez” proche des languages de BDD).

Création d'une nouvelle règle Azure Sentinel
Création d’une nouvelle règle Azure Sentinel

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.

Création d'une nouvelle règle Azure Sentinel
Création d’une nouvelle règle Azure Sentinel
Création d'une nouvelle règle Azure Sentinel
Création d’une nouvelle règle Azure Sentinel

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).

Aperçu d'une alerte dans Azure Sentinel
Aperçu d’une alerte dans Azure Sentinel

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. 🙂

Exemple d'un query dans Log Analytics Workspace
Exemple d’un query dans Log Analytics Workspace

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.

Exemple d'un query dans Log Analytics Workspace
Exemple d’un query dans Log Analytics Workspace

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 ! 🙂