Azure Sentinel et Monitoring Office 365, un cas concret!

22 avril 2021
Temps de lecture : 9 mins
Description de l'image
Le Rhino

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 : 

Azure Sentinel n’est pas qu’un SIEM. C’est également un SOAR. En Anglais : Security Orchestrated Automated Response. 

Un SOAR nous permet d’ : 

Quel rapport avec les outils collaboratifs ? 

Pour expliquer le rapport avec les outils collaboratifs, un exemple : 

Intégration d’Azure Sentinel 

Activation 

J’ai envie de dire : Facile. 

Il faudra : 

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 : 

Azure Sentinel après son intégration
 

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 : 

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

Connecteur Office 365 pour Azure Sentinel

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 : 

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

Une règle d’analyse Azure Sentinel

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 : 

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. 

Logic App permettant l’automatisation de la réponse à incident

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

Articles Similaires

Exemples de méthodologies de migration cloud (7R)

Parmi toutes les méthodologies de migration cloud existants, comment choisir celle qui convient le mieux à vos objectifs et à...

​​Comment maîtriser l’architecture de vos données cloud​ ?

L'adoption d'une architecture de données cloud est essentielle. Cet article vous permet d'établir les fondations nécessaires au déploiement d'une stratégie...

Du FinOps au GreenOps : comment concevoir sa stratégie ?

Tracté par la croissance de l’intérêt pour le FinOps au sein de la communauté cloud, le GreenOps gagne du terrain...