Logo Synapsys Azure Sentinel et Monitoring Office 365, un cas concret!
7 mins de lecture

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 :SecurityInformation andEventManagement.

Un SIEMnouspermet de :

  • Collecter des donnéessur l’ensemble des utilisateurs, appareils, applications, infrastructures… Que les données soient locales ou dans descloudsdifférents.Un SIEMà vocation à être agnostique,
  • Détecter des menacestout en réduisant les faux positifs, grâce à des règles d’analyses personnalisées ou produites directement parl’éditeur (Dans notre cas Microsoft),
  • Investiguer sur les menacesen s’appuyant sur de l’ « IA », très utile pour trouver la cause racine d’une menacepar exemple,

Azure Sentinel n’est pas qu’un SIEM.C’est également un SOAR.En Anglais :SecurityOrchestratedAutomatedResponse.

Un SOAR nous permetd’ :

  • 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 :

  • Nouscollectons les donnéesissues de SharePoint Online,
  • Nousdétectons une menace.Grâce à une règle d’analyse qui stipule que lorsqueplus de 50 fichierssonttéléchargésou chargésdepuis une adresseIPjamais utilisée, nous considérons celacomme un incident,
  • Nousinvestiguons sur la menacesi besoin, par exemple, nous visualisonsle nombre d’utilisateurs associés à cette IP,la géolocalisation de l’IP, les autres actions effectuées depuis cette IP, etc…,
  • Nousré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 dela 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 de30 minutessont nécessaires pour intégrer Azure Sentinel à un tenant.

Quelques avertissements tout de même :

  • Al’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ééspour Azure Security Center ne peuvent pas être utilisés pour installer Azure Sentinel.
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), doitcollecterdes données.

Plus de 100 connecteurssont déjà disponible. Certainssont 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-feuxet proxys nécessiteront l’utilisation d’un serveurSyslogLinux.

Dans notre exemple, nous souhaitonscollecter lesdonnéesprovenant deSharePoint Online. C’est donc le connecteurOffice 365que 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 permetune 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 :

  • Connaitre ou se former aulangagede requêteKusto(KQL).

Pour notre exemple nous utilisons une règle native produite par Microsoftet 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 primordialesnotammentpour utiliser la toute puissante fonctionnalité « UEBA » pour « UsersandEntitiesBehaviorAnalytics ».

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éesconcernant SharePoint Online,
  • Nous sommes en mesures d’identifier un comportementque nous considérons comme étant une alerte.

Maintenant nous souhaitons automatiserla 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 quepersonne au sein de mon organisationn’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 Appagrandi 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

Vous avez aimé lire cet article ?
Partagez le !