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.

Cet article Microsoft Defender for Cloud Apps, ou comment sécuriser l’utilisation des applications cloud  est apparu en premier sur RiskInsight.

Dans un contexte où l’on assiste à une véritable pénurie de compétences cybersécurités, ces problématiques ne peuvent être adressées uniquement par le renforcement des effectifs du SOC. L’utilisation de nouveaux outils, basée sur 4 axes stratégiques, est indispensable pour permettre au SOC d’avoir de l’avance sur les nouvelles menaces.

Ainsi, l’extension de la détection à de nouveaux périmètres permet de protéger de nouvelles parties du SI, aujourd’hui insuffisamment sécurisées (Cloud) ; et des ressources de plus en plus prises pour cibles (attaques ransomware sur les terminaux, attaques ciblées utilisant les AD…).

Dans le même temps, l’adoption de nouvelles approches devient une nécessité pour détecter les attaques ciblées (0days, « low signal » …), dont la subtilité croissante met à mal les dispositifs de sécurité existants.

En complément de nouveaux outils de détection, une connaissance avancée des menaces et des attaquants peut venir améliorer les capacités de détection existantes, aider à la priorisation des incidents à traiter et faire gagner en efficacité lors de la réaction.

Mais les équipes SOC éprouvent déjà des difficultés à traiter les évènements générés par les outils existants. Il est donc primordial d’industrialiser et d’automatiser les interactions entre équipes et systèmes, et, lorsque c’est possible, les étapes d’analyse et de réaction !

Pendant l’été, suivez les épisodes de notre saga pour découvrir les moyens d’outiller ces 4 axes stratégiques !

Étendre la détection à de nouveaux périmètres

Une solution unique pour sécuriser tous les Cloud : CASB

Les CASB (pour Cloud Access Security Broker) adressent un périmètre du SI aujourd’hui mal desservi par les mesures de sécurité classiques : le Cloud. Par sa nature, sa protection nécessite en effet des adaptations par rapport aux SI classiques : pas ou peu de maîtrise des ressources (infrastructures, OS ou applications, selon le type d’offre), localisation à l’extérieur du SI…

Les CASB visent à centraliser et à faire appliquer les politiques de sécurité aux services situés dans le Cloud. Certains fournisseurs Cloud proposent leurs propres services de sécurisation CASB (par exemple Microsoft avec Microsoft Cloud App Security) ; mais, selon les besoins, il est parfois préférable d’utiliser des solutions tierces, même si l’ajout d’un acteur supplémentaire a un coût. En effet, le CASB visant à s’assurer du niveau de sécurité du Cloud, confier ce rôle aux fournisseurs du service à surveiller peut être contre-productif, et l’utilisation d’un « tiers de confiance » est à privilégier.

Dans tous les cas, les CASB sont des solutions variées, pouvant regrouper de très nombreux services, leurs maturités variant selon les éditeurs de solution, les fournisseurs Cloud et le type d’hébergement (IaaS, PaaS, SaaS…).

D’une part, les solutions CASB permettent d’adresser les enjeux spécifiques aux Cloud, en palliant le manque de visibilité sur ces environnements (détection du Shadow IT, statistiques d’utilisation…), et en s’assurant de leur conformité (vérification des configurations…).

D’autre part, elles participent au déploiement des mesures de sécurités classiques sur ce périmètre. En particulier, les enjeux de sécurité de la donnée (DLP et mesures de chiffrement, particulièrement appréciées par les régulateurs) et de détection des menaces (centralisation des logs Cloud pour transmission au SIEM, détection de comportements anormaux -UEBA !, voir partie dédiée-…) font parties des capacités classiques proposées par les éditeurs. En complément, certaines problématiques d’IAM peuvent aussi être adressées par ces solutions (SSO, contextualisation des accès…).

Il existe deux principaux modes de déploiement pour la mise en place de ces fonctionnalités, chacun possédant ses avantages (et inconvénients). Les solutions types proxy sont placées en coupure entre les utilisateurs et le service Cloud.

A l’opposé, dans le cas des solutions de type API, parfois appelées out-of-band, les consommateurs du service Cloud communiquent directement avec celui-ci. Pour chaque accès, le service interroge les API du CASB afin de d’évaluer les risques, et d’autoriser ou non la consommation du service. Les solutions API s’appuient cependant sur les interfaces proposées par le fournisseur Cloud pour fonctionner, ce qui peut limiter certaines possibilités.

Aujourd’hui jeunes et peu matures, les CASB restent peu déployés. Au vu de la démocratisation (déjà bien avancée) des services Cloud, les CASB ont cependant un bel avenir devant eux, et permettront aux équipes SOC d’étendre leur surveillance sur ce périmètre, voué à représenter une partie importante du SI.

Exemples d’éditeurs CASB :

Détection et réaction, le nouveau couteau suisse pour sécuriser les terminaux : EDR (Endpoint Detection and Response)

Les solutions EDR (pour Endpoint Detection and Response) viennent compléter les capacités de détection et de réaction des SOC sur les terminaux (PC, serveurs…).

Comme leur nom l’indique, les EDR participent à la détection d’attaques. Ceux-ci viennent en effet combler les faiblesses des anti-virus (et autres HIPS) s’appuyant sur des signatures d’attaques précises, et donc inadaptées pour détecter certains types d’attaques, notamment les attaques avancées (APT). Les EDR se basent donc sur d’autres méthodes de détection, les éditeurs proposant généralement une combinaison de techniques habituellement utilisées sur d’autres périmètres.

Parmi ces techniques, la détection d’exploitation de vulnérabilités connues ou de patterns d’attaque (ouverture de port suspects vers des adresses douteuses…), l’analyse de fichiers par une sandbox (émulation locale, soumission dans le Cloud…), et des approches comportementales basées sur du Machine Learning (en particulier les solutions UEBA, cf. partie dédiée) sont utilisées par bon nombre de solutions. Selon les besoins du SOC, les alertes remontées peuvent être intégrées comme sources du SIEM, ou disponibles directement depuis la console de management de la solution.

En plus de ces capacités de détection avancées, les solutions EDR apportent aussi un important gain en visibilité sur les terminaux : liste des processus et services lancés, liste de fichiers dans certains répertoires systèmes… et toute autre information permettant de faciliter l’investigation en cas d’alerte. Certaines solutions ne se limitent pas à récupérer l’état du terminal au moment de la demande, mais permettent aussi de récupérer son historique : génération de logs, récupération de fichiers supprimés…

Mais les fonctionnalités des EDR ne s’arrêtent pas aux étapes de détection et d’analyse. En effet, ces solutions permettent d’effectuer des actions de remédiation à distance, dont la complexité dépend des éditeurs : suppression ou mise en quarantaine de fichiers, arrêt de processus, mise en quarantaine réseau de postes, modification de clés de registre…

Les EDR sont donc des solutions très complètes intervenant à toutes les étapes du processus : de la détection, à l’analyse, jusqu’à la réaction. Elles n’ont cependant pas vocation à remplacer les solutions anti-virus, toujours plus efficaces pour bloquer les attaques connues ; même si l’on observe de plus en plus d’éditeurs proposant des solutions unissant les deux types de fonctionnalités.

Pour plus de détails sur les solutions EDR, vous pouvez consulter notre article dédié au sujet ici !

Exemples d’éditeurs EDR :

Protection des clés du royaume : supervision Active Directory

Les annuaires comptent parmi les composants les plus critiques du SI. En effet, ceux-ci fournissent les fonctionnalités d’authentification et d’habilitation pour la quasi-totalité des ressources du SI, aussi bien techniques que métiers, y compris les plus critiques. Il n’est donc pas étonnant que la compromission d’AD figure parmi les méthodes d’attaque les plus utilisées, car ouvrant de nombreuses portes aux attaquants.

Malgré cette criticité, et bien que les architectures AD soient bien connues et aient peu évolué depuis plusieurs années, leur sécurisation reste perfectible. Cela est en particulier dû à leur mode de fonctionnement spécifique (OU, domaines, arbres, forêts, utilisateurs…), rendant les moyens de protection et de surveillance classiques peu efficaces, en particulier lorsque toute vulnérabilité peut représenter un risque majeur pour le reste du SI.

Les solutions de surveillance AD visent à pallier ce problème en supervisant (en temps réel, ou lors d’audit) les spécificités des annuaires (configuration, état des comptes…), et en y détectant des vulnérabilités susceptibles de causer leur compromission. Pour cela, les solutions de supervision AD possèdent une connaissance très pointue du fonctionnement des AD, et tout particulièrement des enjeux de sécurité liés.

Lorsqu’une vulnérabilité est détectée, une alerte est remontée (par le biais du SIEM, ou directement dans la solution) et des conseils de remédiation peuvent être fournis afin de faciliter le travail des équipes en charge de la correction.

Les outils de supervision AD permettent par ailleurs au SOC de détecter toute modification de configuration (légitime, accidentelle ou malveillante) et de s’assurer en continu du niveau de sécurité de ces composants critiques, compliquant d’autant la tâche de nombreux attaquants.

En complément du renforcement direct du niveau de sécurité de l’AD, ces solutions peuvent aussi être utilisés pour s’assurer de la compliance vis-à-vis de normes ou de contraintes réglementaires (LPM, PCI DSS…).

Ces solutions restent assez peu répandues aujourd’hui, et leur utilisation généralement limitée à des audits ponctuels. Cependant, au vu des importants gains de sécurité associés (détection et conseils de remédiation) et de leur simplicité d’utilisation, ces solutions sont prometteuses et devraient réussir à se faire une place parmi les outils du SOC.

Exemples d’éditeurs de supervision AD :

Pour retrouver notre second article de la saga, c’est par ici.

Cet article SOAR, UEBA, CASB, EDR et autres acronymes… suivez la saga de l’été pour comprendre et choisir parmi les nouveaux outils du SOC (1/3) est apparu en premier sur RiskInsight.

À quelles difficultés font face ces équipes au quotidien ? Comment rester efficace alors que les attaques des cybercriminels deviennent extrêmement élaborées ?

Le SIEM : un pilier du SOC… à condition d’être bien implémenté !

L’apparition d’outils comme le SIEM (Security Information and Event Management), il y a environ 10 ans, a permis aux équipes de sécurité opérationnelle d’industrialiser la surveillance en simplifiant l’analyse de multiples sources d’événements de sécurité (console antivirus, proxy, Web Application Firewall…). Cet outil a également rendu possible la corrélation de nombreux événements provenant d’équipements ou d’applications hétérogènes pour détecter des scenarii de menace avancés.

Cependant, la mise en place d’un SIEM doit être le résultat d’un projet ayant un investissement proportionnel à la complexité du système d’information surveillé. En effet, la pertinence d’un SIEM repose à la fois sur :

• La présence de contrôles contextualisés au système d’information (notamment au travers de l’exploitation de la sensibilité des assets surveillés).
• L’étude et l’implémentation de scénarii de menaces avancés et adaptés aux enjeux du métier de l’entreprise.

Concernant le périmètre de surveillance, les premiers équipements habituellement intégrés sont les équipements de sécurité car ils sont nativement configurés pour laisser des traces exploitables pour les équipes opérationnelles. Il est néanmoins souvent constaté que leur intégration se limite à une simple retranscription des contrôles déjà existants ; ce qui ne permet pas de tirer parti de la corrélation d’évènements proposé par un SIEM.

En revanche, l’intégration d’applications métiers est plus délicate en raison notamment des besoins différents entre les équipes métiers et sécurité : la principale préoccupation pour le métier se résume généralement à l’indisponibilité de son application (ou de certaines de ses fonctionnalités), alors que la sécurité adresse un éventail de risques plus complet, que ce soit de l’indisponibilité, de la compromission de l’intégrité de données ou encore de la fuite d’informations confidentielles.

Il s’avère donc primordial de sensibiliser les métiers aux enjeux sécurité dans leur ensemble pour pouvoir déterminer des scenarii de menace réalistes et propres à chaque périmètre. De plus, ces applications n’ont traditionnellement pas de fonctionnalités avancées en termes de sécurité. Par conséquent, il est difficile de disposer d’un système de surveillance efficace (configuration d’envoi de logs complexe, fichiers de logs très peu verbeux…).

De manière générale, l’implémentation trop simpliste de contrôles dans un SIEM rend l’activité du SOC inefficace. Les équipes de surveillance se voient alors noyées de « faux positifs » et les évènements de sécurité sont traités unitairement au lieu d’être analysés dans leur ensemble afin de détecter de réels scenarii de menace (par exemple : une authentification non autorisée sur un serveur puis la désactivation de son antivirus devra être traité comme un seul incident à investiguer).

Des équipes pas assez intégrées dans l’organisation de la sécurité

Outre les problématiques liées à une mauvaise implémentation du SIEM évoquées ci-dessus, on constate également des problématiques d’ordre organisationnel.

En effet, le SIEM est souvent perçu comme une « boîte noire » par les analystes de niveau 1 et 2 au sein des équipes du SOC. Cela est généralement dû à la méconnaissance des problématiques réelles de production (identification des assets critiques, des interactions entre les différents systèmes…). Les incidents détectés par le SIEM se retrouvent alors tous traités au même niveau sans aucune priorisation et identification en amont des éléments les plus sensibles.

Pour maintenir un niveau de compétence suffisant au sein des équipes de sécurité opérationnelle, de la veille technologique doit être réalisée par les investigateurs niveau 3 pour ensuite être communiquée aux analystes niveau 1 et 2. Des sujets tels que la présentation de nouveaux IOC (Indicator Of Compromise) venant compléter des règles de détection permettront aux équipes de gagner en efficacité dans leur manière d’appréhender les incidents. Ces types d’initiatives contribueront à l’amélioration continue du service en évitant sa dégradation dans le temps.

De plus, les équipes doivent participer en continu aux nombreuses initiatives sécurités initiées par la DSI tels que des projets de sécurisation des infrastructures ou applications. Par ailleurs, des exercices de gestion de crises doivent être organisés afin d’éprouver les différents processus et outils mis en place et de permettre aux interlocuteurs métiers et sécurité de pouvoir échanger sur leurs rôles respectifs en cas de crise.

Dans un contexte où la cybercriminalité ne cesse de se réinventer (comme le démontre l’attaque sur les systèmes Swift récente), les équipes opérationnelles sont de plus en plus sollicitées pour intégrer de nouveaux périmètres. Cette pression constante exercée notamment par les décideurs accentue les phénomènes de mauvaise implémentation des contrôles et de méconnaissance des scénarii de menace réels. Une bonne surveillance nécessite plus qu’un simple envoi de logs dans un SIEM ; les équipes projet doivent s’efforcer de respecter et faire respecter le processus complet d’intégration de nouveaux périmètres : identification des scénarii d’attaques, mise en place des mécanismes de collecte, création des règles de détection, tests et mise en production. L’oubli d’une de ces étapes risque de rendre la collecte des logs du périmètre inutile.

Quel avenir pour les SOC ?

De nombreux facteurs vont venir bouleverser l’écosystème des prestataires de la sécurité opérationnelle.

En effet, la LPM (Loi de Programmation Militaire) va exiger de tous les OIV (Opérateur d’Importance Vitale) de choisir des prestataires certifiés PDIS (Prestataires de Détection des Incidents de Sécurité), pour ceux qui font appel à de telles prestations externes. De nombreux prérequis seront nécessaires afin de pouvoir être certifié, tels que le cloisonnement des données des clients ou la mise en place de zones d’administrations (enclaves), uniquement accessible par le prestataire, par lesquelles les logs seront récupérés pour ensuite être transmis au SIEM. Ces facteurs vont entraîner de nombreux changements au sein des organisations et infrastructures mises en place actuellement.

Par ailleurs, la part grandissante du cloud dans les systèmes d’information des entreprises amène une nouvelle complexité : celle de la collecte des logs auprès des fournisseurs. De nouveaux acteurs sont donc apparus dans le marché de la sécurité : les CASB (Cloud Access Security Brokers). Leur promesse : répondre aux problématiques de sécurité pour le cloud. Ces entités se situent entre les utilisateurs et les divers services cloud et proposent de nouvelles briques de sécurité telles que l’utilisation d’API pour détecter directement des scenarii de menaces (création de fichiers de journalisation des accès aux applications, implémentation de ces données dans un SIEM…).

L’objectif de demain : gagner en maturité

La sécurité opérationnelle a encore de nombreux défis à relever. La plupart des entités assurent actuellement l’hygiène minimum du système d’information et la maturité des équipes leur permet de se prémunir des menaces diffuses (virus, spam…). Cependant, le dispositif actuel doit se renouveler afin de répondre aux nouveaux enjeux liés à la cybersécurité pour pouvoir lutter contre les menaces opportunistes (hacker isolé) et ciblées (cyber-mafia, gouvernement), plus complexes à détecter.

Dans ce contexte et face aux obligations légales, les SOC ont (et auront) un rôle très important à jouer nécessitant une expertise technique approfondie ainsi qu’une intégration avec la sécurité dans les projets.

Cet article Cybersécurité : l’heure du bilan pour les SOC est apparu en premier sur RiskInsight.