Microsoft Defender for Cloud Apps, ou comment sécuriser l’utilisation des applications cloud 

La migration des données et des espaces collaboratifs sur le cloud a donné naissance à de nouveaux canaux de fuite de données et a notablement étendu la surface d’attaque pour les entreprises. Par ailleurs, l’utilisation en hausse des applications cloud et les nouveaux modes de travail ont considérablement accru l’usage, volontaire ou non, du Shadow IT, soit l’usage d’applications cloud non validées par l’organisation, donc non gérées par les équipes IT ni validées par la sécurité. 

L’une des solutions proposées à ces nouveaux cas d’usage est la mise en place d’un Cloud Access Security Broker (CASB) tel que Microsoft Defender for Cloud Apps (MDCA). Mais qu’apportent réellement ces solutions ? La première partie de l’article présentera les caractéristiques générales des CASB puis la suite de l’article s’orientera plus particulièrement sur la solution de Microsoft, MDCA. 

 

Les Cloud Access Security Broker (CASB), un moyen de réduire les risques liés aux applications cloud 

Une solution sécurisant l’environnement cloud 

Un Cloud Access Security Broker (CASB) est un point de contrôle de sécurité entre les utilisateurs du SI d’entreprise et les applications cloud. Il analyse les flux internet en direction et depuis les services cloud. Le CASB permet à l’organisation d’étendre la portée de sa sécurité au-delà de sa propre infrastructure. 

Les CASB ont plusieurs fonctions clés :  

• Appliquer des politiques de sécurité lors de l’usage des applications cloud (politique d’accès granulaires, activités autorisées…) ; 
• Détecter le Shadow IT, ainsi que catégoriser et identifier le niveau de risque associé aux applications « Shadow » utilisées ; 
• Contrôler l’usage du Bring Your Own Device (BYOD), soit l’utilisation d’appareils (ordinateurs ou mobiles) personnels des collaborateurs. 

 

Une solution construite autour de 4 piliers 

Afin de fournir ces services clés, un CASB se construit autour de 4 piliers majeurs : 

 

Figure 1 : Les piliers d’un CASB 

• La visibilité : pour contrôler les applications cloud non gérées par les outils IT d’une organisation, les CASB offrent de la visibilité sur les activités cloud des collaborateurs. Cela  permet d’identifier les usages non autorisés, la volumétrie associée, et de potentiels besoins métiers à couvrir autrement ; 
• La conformité : parmi les applications cloud, de nombreuses ne sont pas conformes ou peu sécurisées. C’est aussi le travail d’un CASB d’informer sur la conformité et la sécurité de ces applications afin d’aider à évaluer les risques et prendre des décisions éclairées (ajout de l’application au catalogue, blocage de l’application et communication aux utilisateurs…) ; 
• La sécurité des données : des stratégies DLP avancées (Data Loss Prevention) au travers des CASB peuvent apporter un contrôle plus robuste sur les fuites de données sensibles depuis les canaux cloud. Cela permet de sécuriser les usages autorisés par l’entreprise ; 
• La protection contre les menaces : un CASB peut également défendre contre la menace de malware provenant des services de stockage cloud et ainsi éviter la propagation des menaces des environnements cloud vers le réseau d’entreprise. 

 

La solution CASB de Microsoft : Microsoft Defender for Cloud Apps (MDCA) 

Microsoft Defender for Cloud Apps, un outil qui s’inscrit dans un riche écosystème sécurité 

Conscients des enjeux cyber, Microsoft investit massivement dans ses services de sécurité afin d’en améliorer les fonctionnalités et la gestion, ce qui se traduit notamment avec l’arrivée du portail unifié Microsoft Defender XDR (anciennement Microsoft 365 Defender). Ce portail répond à une problématique de dispersion des informations qui touchait les équipes SSI des entreprises en regroupant les fonctions de 4 outils principaux. En effet, ces outils disposaient auparavant chacun de leur propre portail. 

Ces 4 outils sont : 

• Microsoft Defender for Office 365 : pour sécuriser la messagerie et les outils collaboratifs (ex : analyse des mails entrant dans le SI notamment les expéditeurs, le contenu, les pièces jointes, etc.) ; 
• Microsoft Defender for Endpoint (EDR Microsoft) : pour contrôler les terminaux et les protéger des potentielles attaques, appliquer des politiques de sécurité, et également bloquer des programmes potentiellement malveillants ; 

• Microsoft Defender for Identity : pour le contrôle des accès aux identités, et des tentatives de mouvement latéral vers un compte à privilèges ; 
• Microsoft Defender for Cloud Apps : pour gagner de la visibilité et du contrôle sur les données qui vont et viennent du SI et des applications cloud. 

 

Outre la facilitation de l’accès aux informations pour l’administrateur de sécurité, Microsoft renforce également la corrélation entre les informations des différents outils. Cette corrélation entre les outils apporte deux avantages principaux :  

• Une augmentation du nombre de points de détection de potentielles attaques, permettant d’accroître la probabilité de détecter une attaque rapidement, plusieurs outils étant à contourner ; 
• Une corrélation entre les outils et signaux, permettant non seulement de faciliter la reconstitution de la chaine de compromission d’une attaque (kill chain), mais aussi de fournir une meilleure contextualisation des incidents et un tri plus simple des nombreuses alertes provenant des 4 différents outils. Nous pouvons constater figure 1 l’intervention des différents outils de sécurité de Microsoft en fonction des étapes de l’attaque : 

Figure 2 : Plusieurs points de détection d’une attaque grâce à la suite Microsoft Defender 

Maintenant que l’écosystème dans lequel MDCA s’inscrit est plus clair, focalisons-nous sur l’outil lui-même dans la suite. 

 

Microsoft Defender for Cloud Apps, un ensemble de stratégies complémentaires à configurer afin de protéger les applications cloud et leurs usages 

Microsoft Defender for Cloud Apps fonctionne avec la notion de politiques de protection et de détection également appelées stratégies (ou « policies » en anglais). Elles permettent la remontée des alertes lorsqu’un évènement spécifique se produit afin de détecter de potentielles activités suspectes, mais aussi d’effectuer des actions spécifiques conditionnées par cet évènement. Un espace dédié dans MDCA est disponible pour la gestion de ces politiques et de leurs alertes. Les stratégies de sécurité de MDCA sont nombreuses et se répartissent en différentes catégories : 

• Threat Detection : 

• • Activity policy : la collecte des journaux d’activité pour les applications embarquées, via le contrôle de session permettant d’alerter quand un utilisateur effectue une activité suspecte, et de détecter une compromission ou une activité malveillante d’un utilisateur interne ; 
  • OAuth app1 policy : le contrôle des permissions des applications sur les environnements ainsi que le contrôle des permissions données par les utilisateurs permettent d’alerter à propos des applications OAuth à risques ou à permissions élevées afin d’aider à l’application du principe du moindre privilège et de renforcer la détection sur les applications les plus à risques ; 

• Information Protection : 

• • File policy : la revue et le tri des fichiers selon des critères spécifiques (date de création, date de modification, contributeurs, etc.) permettent de protéger les données dans le Cloud en alertant lorsqu’un fichier est partagé dangereusement (domaines non autorisés par exemple) ou lors de la présence de données sensibles dans le Cloud ; 

• Conditional Access : 

• • Access policy : supervision en temps réel de l’accès aux différentes applications cloud par les différents utilisateurs, localisations et/ou un type d’appareil spécifique, renforçant les capacités de l’accès conditionnel de Entra ID en apportant des capacités de filtrage plus granulaires ; 

• • Session policy : contrôle en temps réel des activités des utilisateurs afin de réagir immédiatement à certaines activités malveillantes ou non autorisées par l’organisation telles que le téléchargement de fichiers malicieux, le téléchargement de fichiers sensibles stockés sur des espaces à risque… ; 

• Shadow IT :  

• • Cloud Discovery anomaly detection policy : envoi d’alertes lors de la détection de comportements inhabituels aux usages sur les applications cloud monitorées. Cette détection se base sur l’apprentissage de modèles d’intelligence artificielle ; 
  • App Discovery policy : analyse des flux applicatifs et tri des données (par utilisateur, par ressource, etc.) permettant d’attribuer un score de sécurité et de conformité aux applications utilisées et envoi d’alertes lors de l’utilisation d’une nouvelle application populaire, dangereuse, ou spécifique à un certain type de collaborateur. 

 

Quels sont les mécanismes permettant de fournir ces différentes politiques ? 

MDCA se décompose en 3 briques majeures afin de s’intégrer au mieux au SI des organisations. Comme visible en figure 3, la brique « Cloud discovery » sert d’interface entre MDCA et le pare-feu de l’entreprise pour réaliser l’analyse de flux des applications utilisées au sein de l’organisation. Le « Cloud discovery » permet également la configuration de scripts pour limiter certains usages. La brique « Reverse proxy », permet de placer MDCA entre le SI et les applications cloud pour permettre l’analyse des connexions et les politiques de contrôle (de session, d’accès, etc.) en temps réel. Enfin, la brique « App connectors » permet de lier directement MDCA aux applications cloud pour permettre leur analyse. 

Figure 3 : Mécanismes de contrôle de l’utilisation des applications cloud 

Cloud discovery : 

La découverte cloud fonctionne sur la base du collecteur de logs du firewall d’entreprise, du proxy d’entreprise ou de Microsoft Defender for Endpoint, qui doit alors être installé sur tous les appareils. A partir des logs d’utilisation du réseau, MDCA peut analyser les applications cloud utilisées et le trafic vers ces dernières. Ensuite, l’outil donne des notes à ces applications sur la base de ses connaissances sur plusieurs dizaines de milliers d’applications selon près de 100 critères de sécurité et de conformité. Les fonctionnalités associées sont donc la découverte cloud et le catalogue d’applications cloud. 

Reverse Proxy : 

Le contrôle de session se base sur la fédération d’authentification. Une fois le gestionnaire d’identité lié via Entra ID et l’application connectée à l’environnement, quand un utilisateur se connecte via son compte lié au gestionnaire d’identité, la session est capturée par MDCA, et le trafic est routé par un reverse proxy. Ainsi, certaines manipulations spécifiques peuvent être effectuées : bloquer un téléchargement, la copie de texte, ou demander une confirmation multi-facteur avant d’effectuer une action par exemple. Les fonctionnalités associées sont le journal d’activités et les stratégies de contrôle de session. 

App connectors : 

Ce sont des APIs qui se connectent aux applications les plus utilisées (notamment les services de stockage cloud : AWS, Azure, GCP). Grâce à ces connexions, MDCA peut effectuer des scans réguliers des fichiers stockés dans le Cloud, mais aussi des utilisateurs qui s’y connectent. Les services ainsi fournis peuvent être de l’information sur le compte, en passant par la gouvernance des comptes, l’autorisation des applications et l’analyse de données. 

 

Un ensemble de cas d’usage de sécurité & conformité couverts par MDCA 

De nombreux cas d’usage de détection d’un comportement suspect sont possibles à travers les différents types de stratégies de MDCA. Ces détections peuvent engendrer seulement une alerte ou bien entrainer une remédiation immédiate (ex : blocage) en fonction de la gravité de l’événement. Ci-dessous quelques exemples de cas d’usage d’alerting et de remédiations immédiates possibles grâce à MDCA :  

• Génération d’une alerte : 
  • Lors d’une connexion à partir d’une adresse IP anonyme (via Activity policy) ; 
  • Lors du téléchargement d’une grande quantité de données qui s’écartent du comportement habituel d’un utilisateur (via Cloud Discovery anomaly detection policy) ; 
  • Lors du téléchargement d’un fichier contenant des informations sensibles (ex. numéro de carte de crédit, numéro de passeport, etc.) (via File policy) ; 
  • Lors d’un nombre inhabituellement élevé de connexions à une application métier (via App Discovery policy). 
• Demande de confirmation MFA lorsqu’un utilisateur tente de télécharger un fichier hautement confidentiel et est connecté via Azure AD (via Session policy) ; 
• Obligation d’étiquetage avant d’autoriser l’utilisateur à déposer sur le Cloud un document contenant des informations sensibles qui n’est pas étiqueté (via Session policy) ; 
• Blocage de l’envoi d’un message d’un utilisateur tentant d’envoyer des informations sensibles à un autre utilisateur (ex. numéro de compte bancaire) via une messagerie instantanée (via Session policy) ; 
• Blocage du téléchargement depuis une application cloud de stockage d’un fichier confidentiel si l’utilisateur est connecté à son ordinateur personnel (via Session policy). 

Figure 4 : Exemple de Session policy permettant de contrôler l’usage d’une application 

 

MDCA, une solution pouvant être complexe à mettre en place 

Comme vu précédemment, MDCA est un outil qui propose de nombreuses fonctionnalités complémentaires aux autres outils de sécurité Microsoft tels que le DLP Purview ou Microsoft Defender, nécessitant donc une priorisation des fonctionnalités à activer et à utiliser. Ces différentes fonctionnalités et l’organisation en « policies » induisent une complexité de configuration qu’il est important de prendre en compte. Il est donc indispensable de bien cibler les cas d’usage à couvrir et de tester l’efficacité des politiques définies afin de s’assurer d’une part que la couverture des risques soit effective et d’autre part d’éviter la génération de trop nombreux faux positifs, comme il est possible de le voir lors de la mise en place de certaines règles de DLP.  

Enfin, la mise en place de MDCA nécessite certains prérequis non triviaux tels que :  

• L’interconnexion de MDCA avec les différents applications Cloud utilisées ;  
• La mise en place de mécanismes afin de forcer le passage par le CASB (blocage des navigateurs non compatibles notamment) ; 
• La formation des modèles d’apprentissage et l’affinage des règles de détection, qu’elles soient fournies par Microsoft ou personnalisées par l’organisation afin de réduire les faux positifs. 

 

En conclusion, MDCA, comme tout CASB, est un outil prometteur nécessitant un niveau avancé de maturité 

En somme, Microsoft Defender for Cloud Apps s’intègre naturellement aux services et outils de sécurité de Microsoft, dispose de stratégies de détection d’activités suspectes par défaut et permet d’obtenir une première vue globale, incluant une première évaluation des risques, sur les interconnexions entre le SI de l’organisation et les applications cloud (y compris Microsoft 365).  

Cependant, son apparente facilité de mise en place initiale ne doit pas occulter non seulement le besoin de mettre en place certains prérequis tels que l’affinage des règles ou la gestion des interconnexions entre le SI et les environnements Cloud (gestion des navigateurs, interconnexions des applications tierces…), ni les efforts nécessaires pour la mise en place de stratégies de détection pertinentes pour l’organisation (création des règles, tests et corrections des faux positifs / faux négatifs). Sa mise en place doit être réalisée dans le cadre d’un projet et la création de nouvelles stratégies doit faire l’objet d’une attention particulière et d’une approche itérative.  

En synthèse, il est nécessaire d’envisager MDCA comme un outil de sécurité puissant, qu’il faudra prendre le temps de configurer, fine-tuner et intégrer aux autres services complémentaires tels que la classification des données ou les règles d’accès conditionnels. Cela nécessitera donc un temps non négligeable de configuration, qui ne sera possible qu’après avoir mis en place un premier niveau de sécurité et acquis une maturité certaines sur les cas d’usages des applications cloud et des CASB. 

 

 

Merci à Mathias COULAIS pour sa contribution à cet article.