Azure Sentinel et Monitoring Office 365, un cas concret!
Introduction
Bonjour à tous, récemment j’ai eu la chance de manipuler Azure Sentinel.
Azure Sentinel est ce que nous appelons un « SIEM » dans le jargon de la sécurité.
En Anglais : Security Information and Event Management.
Un SIEM nous permet de :
- Collecter des données sur l’ensemble des utilisateurs, appareils, applications, infrastructures… Que les données soient locales ou dans des clouds différents. Un SIEM à vocation à être agnostique,
- Détecter des menaces tout en réduisant les faux positifs, grâce à des règles d’analyses personnalisées ou produites directement par l’éditeur (Dans notre cas Microsoft),
- Investiguer sur les menaces en s’appuyant sur de l’ « IA », très utile pour trouver la cause racine d’une menace par exemple,
Azure Sentinel n’est pas qu’un SIEM. C’est également un SOAR. En Anglais : Security Orchestrated Automated Response.
Un SOAR nous permet d’ :
- Orchestrer et répondre automatiquement à une ou des menaces.
Quel rapport avec les outils collaboratifs ?
Pour expliquer le rapport avec les outils collaboratifs, un exemple :
- Nous collectons les données issues de SharePoint Online,
- Nous détectons une menace. Grâce à une règle d’analyse qui stipule que lorsque plus de 50 fichiers sont téléchargés ou chargés depuis une adresse IP jamais utilisée, nous considérons cela comme un incident,
- Nous investiguons sur la menace si besoin, par exemple, nous visualisons le nombre d’utilisateurs associés à cette IP, la géolocalisation de l’IP, les autres actions effectuées depuis cette IP, etc…,
- Nous répondons automatiquement à l’incident. Pour cela, nous nous appuyons sur un flux demandant à l’utilisateur (aux utilisateurs) si il est (ils sont) à l’origine du téléchargement ou du chargement. En fonction de la réponse, l’incident est automatiquement clos comme faux positif ou il est assigné à un membre de l’équipe sécurité si la menace est avérée.
Intégration d’Azure Sentinel
Activation
J’ai envie de dire : Facile.
Il faudra :
- Une souscription Azure,
- Une autorisation de « contributeur » sur la souscription,
- Une autorisation de contributeur sur le groupe de ressource dont dépendra Azure Sentinel,
- Un espace de travail Log Analytics si on ne souhaite pas en utiliser un nouveau lors de la création d’Azure Sentinel.
Du SaaS comme on aime. Moins de 30 minutes sont nécessaires pour intégrer Azure Sentinel à un tenant.
Quelques avertissements tout de même :
- A l’heure actuelle, un espace de travail Azure Sentinel ne peut être déplacé vers un autre groupe de ressource ou une autre souscription.
- Les espaces de travail Log Analytics créés pour Azure Security Center ne peuvent pas être utilisés pour installer Azure Sentinel.
Connection des sources de données
Une fois installé, Azure Sentinel (et n’importe quel SIEM d’ailleurs), doit collecter des données.
Plus de 100 connecteurs sont déjà disponible. Certains sont natifs et ne demande rien de plus que les bonnes autorisations et licences, c’est le cas du connecteur Office 365. D’autres comme les pares-feux et proxys nécessiteront l’utilisation d’un serveur Syslog Linux.
Dans notre exemple, nous souhaitons collecter les données provenant de SharePoint Online. C’est donc le connecteur Office 365 que nous allons utiliser.
Il faut respecter quelques prérequis :
- Avoir les permissions d’écriture/lecture sur l’espace de travail Log Analytics qui supporte Azure Sentinel,
- Avoir le rôle « Administrateur Global » ou « Administrateur de la sécurité » sur le tenant Office 365.
Nous en profiterons pour collecter les données provenant d’Exchange Online et Microsoft Teams car le connecteur permet une granularité dans les données collectées.
7 clics et 3 minutes plus tard, les données Office 365 sont connectées à Azure Sentinel. Il faut cependant un certain temps pour les voir arriver (24h maximum).
Règles d’analyses
Collecter les données, c’est bien. Les analyser pour lever de potentielles menaces, c’est mieux.
Il est donc possible d’analyser les données grâce à ce que nous appelons des règles d’analyses.
Certaines sont fournies par Microsoft (plus de 280). Elles peuvent être utilisées comme tel ou bien modifiées pour s’aligner à nos besoins. D’autres règles peuvent être définies à partir d’une page blanche. Seul prérequis :
- Connaitre ou se former au langage de requête Kusto (KQL).
Pour notre exemple nous utilisons une règle native produite par Microsoft et nous l’activons.
Cette règle d’analyse stipule que nous considérons qu’il y a incident si un téléchargement ou chargement de plus de 50 fichiers est effectué à partir d’une adresse IP depuis laquelle personne ne s’ait connecté jusque-là.
Je passe sur les détails mais les paramétrages de ces règles sont primordiales notamment pour utiliser la toute puissante fonctionnalité « UEBA » pour « Users and Entities Behavior Analytics ».
Si vous rêvez de limiter la charge de vos analystes SOC, c’est par ici qu’il faut regarder. J’espère pouvoir vous en parler dans un prochain billet. Pour faire simple : Il s’agit « d’analyse comportementale basée sur l’intelligence artificielle ».
Automatisation de la réponse à incident
En l’état :
- Nous collectons les données concernant SharePoint Online,
- Nous sommes en mesures d’identifier un comportement que nous considérons comme étant une alerte.
Maintenant nous souhaitons automatiser la réponse à incident. Nous allons donc créer un flux qui demande automatiquement à l’utilisateur si il est à l’origine de l’action.
Pour ce faire, nous utilisons la fonctionnalité « Automation » d’Azure Sentinel. Elle se base sur « Azure Logic Apps », outil bien connu dans le monde Office 365 et Azure, c’est le pendant « Industriel » de Power Automate.
En pratique
Maintenant que notre scénario est techniquement implémenté, comment se déroule-t-il en pratique ?
Déclenchement de l’alerte
L’alerte se déclenche si je télécharge ou si je charge plus de 50 fichiers à partir d’une IP que personne au sein de mon organisation n’a encore utilisé.
Je charge donc une centaine de fichier sur mon OneDrive depuis l’adresse IP de mon téléphone en 4G.
Détection de l’incident
L’incident est détecté dans Azure Sentinel.
Réponse automatique à l’incident
L’utilisateur reçoit un mail lui demandant si il est à l’origine de l’incident.
Si l’utilisateur répond que oui, l’incident est automatiquement clos. La raison de la clôture est également automatiquement remplie.
Si l’utilisateur répond que non, le statut de l’incident passe en « Actif ». L’incident est également automatiquement assigné à la bonne personne.
Conclusion
Voilà pour un cas concret Azure Sentinel appliqué à Microsoft 365. Personnellement je suis assez bluffé par ce SIEM+SOAR. Facilité « d’installation », nombre de connecteurs, puissance des règles d’analyses… UEBA me parait être extrêmement prometteur. La partie SOAR qui s’appuie sur Logic App agrandi le champs des possibles jusqu’à l’infinie pour une réponse à incident automatisé.
Une chose est sure, Microsoft est désormais un acteur incontournable de la Sécurité !
Date de publication : 22 avril 2021
