SASE, SIEM, XDR, SOC, VOC, MDR : qui fait quoi en cybersécurité ?

SASE, SIEM, XDR, SOC, VOC, MDR… La cyber ressemble parfois à une partie de Scrabble réservée aux initiés. Ces acronymes correspondent à différentes technologies de détection, des services managés, des équipes opérationnelles ou encore à des modèles d’architecture. Ils peuvent couvrir des besoins différents, se compléter et, parfois, se chevaucher.

Alors, qui fait quoi ? Voyons ce qui se cache derrière chaque acronyme, comment ces différentes briques fonctionnent ensemble et lesquelles correspondent réellement aux besoins de votre organisation.

🔍 SASE, SIEM, XDR, SOC, VOC et MDR : quelles différences ?

SIEM : centraliser et analyser les événements de sécurité

Le SIEM, pour Security Information and Event Management, est un outil de centralisation des journaux et événements générés par les différents composants de votre SI : firewalls, serveurs, postes de travail, annuaires, applications, équipements réseau ou services Cloud.

Sans SIEM, reconstituer une attaque peut rapidement ressembler à une enquête menée avec des pièces de puzzle rangées dans plusieurs bâtiments. Le SIEM collecte ces données, les normalise et les met en relation afin d’identifier des enchaînements suspects. Une succession d’échecs de connexion, suivie d’une authentification inhabituelle puis d’une modification de privilèges pourrait, par exemple, déclencher une alerte.

Il remplit principalement quatre fonctions :

• centraliser et conserver les événements de sécurité,
• corréler les données pour détecter des comportements suspects,
• faciliter les recherches et les investigations
• produire des tableaux de bord et des rapports (qui permettent notamment de répondre à certaines exigences de conformité).

Le SIEM constitue l’un des outils centraux d’un SOC. Il permet aux analystes de disposer d’une vision globale du système d’information et de remonter le fil des événements lorsqu’une alerte survient. Pour autant, « juste » installer un SIEM ne suffit pas pour assurer une supervision efficace. Vous allez devoir choisir les bonnes sources de données, définir des scénarios de détection pertinents, ajuster les règles et traiter les alertes produites. Sans ce travail, votre SIEM ne sera qu’un générateur d’une quantité monstrueuse d’alertes à décourager le plus solide de vos analystes.

Souvent à l’event par seconde

XDR : détecter et répondre aux menaces sur plusieurs couches

Le XDR, pour Extended Detection and Response, c’est un Endpoint Detection and Response (EDR)… mais Extended. Bon, OK, soyons plus précis. Le  XDR, donc, étend la logique de l’EDR au-delà des postes de travail et serveurs. Il rassemble et met en relation des données provenant de plusieurs couches du SI : endpoints, identités, messagerie, applications cloud ou encore réseau. Là encore, l’objectif est de reconstituer une attaque dans son ensemble, plutôt que de traiter séparément chaque signal. Un message de phishing, suivi d’une connexion inhabituelle puis de l’exécution d’un programme malveillant sur un poste pourra ainsi être regroupé au sein d’un même incident.

Le XDR aide les équipes de sécurité à :

• détecter les menaces à partir de plusieurs sources,
• regrouper les alertes liées à une même attaque,
• comprendre le chemin suivi par l’attaquant,
• prioriser les incidents selon leur niveau de risque,
• déclencher ou automatiser certaines actions de réponse.

Selon les outils connectés, il peut par exemple isoler un poste du réseau, bloquer un compte compromis, supprimer un message malveillant ou empêcher l’exécution d’un fichier. Le XDR ne peut toutefois pas remplacer complètement l’analyse humaine. Les actions automatisées doivent être définies, contrôlées et adaptées. Une réaction trop large peut certes arrêter une attaque… mais également quelques utilisateurs qui n’avaient rien demandé.

MDR : externaliser la détection et la réponse

Le MDR, pour Managed Detection and Response, est un service managé de détection et de réponse aux incidents. Contrairement au SIEM ou au XDR, il ne désigne donc pas une technologie précise, mais une prestation assurée par une équipe de spécialistes. Un prestataire MDR va surveiller les événements de sécurité, analyser les alertes, rechercher les menaces et vous accompagner dans leur traitement. Selon le service souscrit, il peut également intervenir directement pour contenir une attaque : isoler un poste, bloquer un compte ou neutraliser un élément malveillant.

Selon le modèle du prestataire, le MDR peut s’appuyer sur une plateforme qu’il opère lui-même, sur certaines technologies déjà déployées chez vous ou sur une combinaison des deux.

Ce type de service répond particulièrement aux besoins des organisations qui ne disposent pas des ressources nécessaires pour exploiter seules ces outils, maintenir les règles de détection et surveiller les alertes en continu. Car recevoir une alerte à trois heures du matin est une chose. Disposer de quelqu’un pour l’analyser et agir en est une autre. Le MDR est donc un service qui permet d’externaliser une partie de la détection et de la réponse, mais pas l’ensemble de la responsabilité cyber. Vous devrez toujours définir vos règles, vos contacts, vos procédures de crise et le niveau d’autonomie que vous accordez au prestataire.

SOC : l’équipe qui supervise la sécurité

Le SOC, pour Security Operations Center, désigne la fonction opérationnelle chargée de surveiller la sécurité du système d’information. Il ne s’agit donc pas d’un logiciel, mais d’une équipe organisée autour de processus et d’outils de détection et de réponse. Concrètement, les analystes du SOC recueillent et examinent les alertes, distinguent les incidents réels des faux positifs, mènent les premières investigations et coordonnent les actions nécessaires pour contenir la menace. Leurs missions comprennent notamment :

• la surveillance des événements et alertes de sécurité,
• la qualification et la priorisation des incidents,
• l’analyse du déroulement d’une attaque,
• la coordination des actions de confinement et de remédiation
• l’amélioration continue des règles de détection,
• le suivi des incidents et la production de rapports.

Pour réaliser ce travail, le SOC s’appuie sur différentes technologies, dont certaines vues précédemment : SIEM, EDR, XDR, SOAR, outils de renseignement sur les menaces ou encore solutions de supervision du réseau. Ces outils collectent, analysent ou enrichissent les données, mais ce sont les analystes qui les interprètent et décident des actions à mener. Le SOC représente ainsi la couche humaine et opérationnelle de la supervision de sécurité. Il ne suffit pas d’installer un SIEM et quelques écrans sur un mur pour en créer un (même si les écrans contribuent indéniablement à l’ambiance !).

SASE : sécuriser les accès et le réseau

Le SASE, pour Secure Access Service Edge, est une architecture qui réunit des fonctions de réseau et de sécurité au sein d’un même environnement, généralement fourni depuis le Cloud. L’idée est de ne plus faire transiter systématiquement les connexions par le réseau de l’entreprise pour les contrôler. Les règles de sécurité sont appliquées au plus près des utilisateurs, qu’ils travaillent depuis les locaux, leur domicile, une agence ou directement dans une application Cloud.
Une architecture SASE associe généralement le SD-WAN à plusieurs services de sécurité :

• le ZTNA, pour contrôler les accès aux applications selon l’identité et le contexte ;
• le SWG, pour sécuriser la navigation web ;
• le CASB, pour encadrer l’utilisation des services cloud ;
• le FWaaS, qui fournit des fonctions de pare-feu depuis le cloud.

Le SASE ne remplit donc pas le même rôle qu’un SIEM ou un XDR. Son objectif principal est de sécuriser les connexions, les flux réseau et les accès aux ressources. Il peut bloquer certaines activités suspectes et produire des alertes, mais il n’a pas vocation à centraliser l’ensemble des événements de sécurité ou à piloter les investigations.

En revanche, les journaux et alertes générés par le SASE peuvent alimenter un SIEM, un XDR ou les équipes du SOC. Il constitue alors l’une des briques de l’architecture de sécurité (et non pas, malgré ce que certaines présentations commerciales pourraient laisser penser, la réponse universelle à tous les problèmes cyber 😉).

📖 Découvrez notre livre blanc pour tout comprendre sur le SASE

VOC : quel rôle dans la cybersécurité ?

Moins connu que le SOC, l’équipe du VOC, pour Vulnerability Operations Center, organise la détection, la priorisation et le traitement continu des vulnérabilités présentes dans le système d’information. Il ne se limite pas à lancer des scans et à transmettre une liste de failles aux équipes techniques. Son rôle consiste surtout à transformer ces résultats en actions réellement exploitables. Ses principales missions sont :

• recenser les actifs à surveiller,
• détecter régulièrement les vulnérabilités,
• analyser et qualifier les résultats,
• prioriser les corrections selon l’exposition, l’exploitabilité et la criticité des équipements,
• accompagner les équipes chargées de la remédiation,
• vérifier que les vulnérabilités ont bien été corrigées,
• suivre l’évolution du niveau de risque dans le temps.

Cette priorisation est essentielle. Une vulnérabilité affichant un score élevé n’est pas nécessairement la plus urgente si elle concerne un équipement isolé et peu critique. À l’inverse, une faille moins spectaculaire, mais activement exploitée sur un serveur exposé à Internet, mérite probablement de remonter de quelques lignes dans la liste.

Le VOC ne remplit donc pas le même rôle qu’un SOC. Son travail porte principalement sur les faiblesses qui pourraient être exploitées, là où celui du SOC est de surveiller les signaux pouvant révéler une attaque en cours ou passée.

📊 SIEM vs XDR vs MDR vs SOC : tableau comparatif

Acronyme	Nature	Objectif principal	Périmètre	Capacité d’action	Modèle de tarification courant
SASE	Architecture réseau et sécurité	Sécuriser les connexions et les accès aux ressources	Utilisateurs, sites distants, applications cloud et flux réseau	Applique les politiques d’accès, filtre les flux et bloque certaines activités	Généralement par utilisateur et par mois ; parfois par site, équipement, bande passante ou module activé
SIEM	Plateforme technologique	Centraliser, corréler et analyser les événements de sécurité	Journaux des serveurs, postes, équipements réseau, applications, identités et services cloud	Génère des alertes et facilite les investigations ; les réponses nécessitent généralement des intégrations complémentaires	Généralement au volume de données ingérées en Go ou au nombre d’événements par seconde. La conservation peut être facturée séparément
XDR	Technologie de détection et de réponse	Détecter et traiter les attaques sur plusieurs couches	Endpoints, identités, messagerie, cloud et réseau, selon les intégrations disponibles	Peut isoler un poste, bloquer un compte ou neutraliser un élément malveillant	Généralement par utilisateur, endpoint, serveur ou workload, parfois inclus dans une suite de sécurité
SOC	Équipe ou fonction opérationnelle	Superviser la sécurité et piloter le traitement des incidents	Ensemble des sources et outils placés sous sa supervision	Analyse, qualifie et coordonne les actions de réponse	Pour un SOC interne, cumul des coûts humains et technologiques Pour un SOC externe, peut être facturé par actif, source supervisée, volume de données ou forfait de service
MDR	Service managé	Externaliser la détection et la réponse aux incidents	Périmètre défini dans le contrat et technologies prises en charge	Le prestataire analyse les alertes et peut intervenir directement selon les autorisations accordées	Le plus souvent par endpoint, utilisateur, serveur ou actif supervisé, avec un prix variant selon la couverture et le niveau de service
VOC	Équipe ou fonction opérationnelle	Détecter, prioriser et suivre la correction des vulnérabilités	Équipements, systèmes, applications et ressources cloud intégrés au programme	Pilote la remédiation et vérifie les corrections, mais ne traite pas directement les attaques en cours	Pour un VOC interne, cumul des coûts humains et des outils, généralement par actif, adresse IP, application ou ressource Cloud Pour un VOC externe, forfait ou abonnement selon le nombre d’actifs et le niveau d’accompagnement

🤝 Comment SIEM, XDR, SOC, MDR, VOC et SASE fonctionnent-ils ensemble ?

Le SIEM et le XDR sont-ils concurrents ?

Le SIEM et le XDR occupent une partie du même terrain : tous deux collectent des données, rapprochent des événements et font remonter des alertes.

Le XDR apporte une détection intégrée sur les couches qu’il couvre. Il peut, par exemple, relier un message de phishing, une connexion inhabituelle et l’exécution d’un programme suspect sur un poste, puis permettre à l’analyste d’isoler ce poste ou de bloquer le compte concerné.

Le SIEM intervient lorsque le SOC a besoin d’une vision plus large. Il peut compléter les informations du XDR avec les journaux d’un firewall tiers, d’un serveur, d’une application métier ou d’un équipement réseau. Il peut également répondre à des besoins de conservation centralisée et de recherche historique qui dépassent le périmètre ou la durée de rétention de certains XDR

Dans une architecture combinant les deux solutions, le XDR peut transmettre ses alertes au SIEM. Le SOC les rapproche alors des autres événements du système d’information, puis utilise le XDR pour approfondir l’investigation ou déclencher une action de réponse. Cette complémentarité doit cependant répondre à un besoin réel. Si le SIEM et le XDR collectent les mêmes données, appliquent les mêmes règles et génèrent les mêmes alertes, la combinaison ne ferait qu’ajouter des coûts, des alertes et une nouvelle interface. Trois choses dont les analystes disposent généralement déjà en quantité suffisante.

Quel rôle joue le SOC ?

Le SOC ne constitue pas une brique technologique supplémentaire. Cette équipe peut s’appuyer sur le SIEM pour centraliser, le XDR pour analyser et réagir, et le SASE pour contextualiser. Il organise la manière dont l’ensemble du dispositif est exploité. C’est à lui de déterminer :

• quelles données doivent être collectées,
• quels événements seront analysés par le SIEM et/ou le XDR,
• depuis quelle interface les alertes seront traitées,
• quels scénarios doivent déclencher une investigation,
• quelles actions peuvent être automatisées,
• qui doit intervenir lorsqu’un incident est confirmé.

Son rôle consiste donc autant à analyser les menaces qu’à éviter les doublons, les angles morts et les alertes qui circulent d’un outil à l’autre sans que personne ne sache réellement qui doit les traiter.

Comment le VOC complète-t-il le SOC ?

Le SOC et le VOC ne se remplacent pas, ils interviennent sur deux temporalités différentes. Le SOC recherche les signes d’une attaque en cours ou déjà réalisée. Le VOC s’intéresse aux vulnérabilités qui pourraient permettre cette attaque.

Par exemple, le VOC peut signaler au SOC qu’un serveur exposé à Internet présente une vulnérabilité critique. Le SOC pourra alors renforcer sa surveillance, créer un scénario de détection spécifique ou traiter plus rapidement une alerte concernant cet équipement.

Exemple dans l’autre sens, le SOC peut informer le VOC qu’une vulnérabilité est activement exploitée, qu’un type d’équipement est ciblé ou qu’un incident a révélé une faiblesse jusque-là sous-estimée. Le VOC peut alors revoir ses priorités de correction.

Où intervient le MDR ?

Le MDR ne vient pas ajouter une nouvelle couche technologique entre le SIEM, le XDR et le SOC. Il répond à une autre question : qui va exploiter ces outils et intervenir lorsqu’une alerte survient ? Un prestataire MDR peut utiliser le XDR de l’entreprise, exploiter son SIEM ou fournir ses propres technologies. Il analyse les alertes, mène les premières investigations et, selon le contrat, réalise certaines actions de confinement.

Pour une entreprise sans SOC interne, le MDR peut prendre en charge une grande partie des activités de détection et de réponse. Lorsqu’un SOC existe déjà, il peut compléter les équipes, assurer la surveillance en dehors des heures ouvrées ou prendre en charge un périmètre particulier. Dans ce dernier cas, il faut impérativement définir précisément qui surveille quoi, qui peut agir et à quel moment vous reprenez la main. Sans cette répartition, le risque est de découvrir au milieu d’un incident que chacun pensait que l’autre était chargé de répondre.

Où se place le SASE ?

Le SASE ne remplace ni le SIEM, ni le XDR, ni le SOC, mais se situe sur un autre plan : celui de la connectivité, du contrôle des accès et de la sécurisation des flux. Il applique les politiques de sécurité lorsque les utilisateurs se connectent aux applications, naviguent sur Internet ou accèdent aux ressources de l’entreprise.

Il peut bloquer une destination malveillante, refuser une connexion présentant un risque ou limiter l’accès à une application. Les événements qu’il génère sont ensuite transmis au SIEM ou au XDR afin d’être rapprochés des autres signaux de sécurité. Le SASE peut également devenir un moyen d’action. Après l’analyse d’une alerte, le SOC ou le prestataire MDR pourra, selon les intégrations disponibles, s’appuyer sur lui pour bloquer une session, restreindre un accès ou appliquer une règle plus stricte à un utilisateur.

Par exemple : une connexion inhabituelle est suivie d’une activité suspecte sur un poste. Le SASE fournit les informations concernant l’accès et peut appliquer un premier blocage. Le XDR rapproche cet événement de l’activité observée sur le poste et l’identité. Le SIEM complète l’analyse avec les autres journaux disponibles. Le SOC ou le MDR qualifie ensuite l’incident et coordonne la réponse.

🤔 SIEM, XDR, MDR ou SASE : quelle solution choisir ?

PME sans équipe cybersécurité dédiée

Si vous êtes une PME sans analystes dédiés, déployer un SIEM complexe que personne ne pourra réellement exploiter présente peu d’intérêt. Dans ce contexte, l’externalisation de tout ou partie de la supervision constitue souvent l’option la plus pragmatique.

Vous pouvez alors envisager de confier cette mission à un SOC. Il assure la supervision des événement de sécurité, analyse les alertes et coordonne les premières actions de réponse. Selon le périmètre retenu, il pourra s’appuyer sur un SIEM, un EDR, un XDR ou les outils que vous avez déjà en place.

Une prestation MDR peut aussi répondre à ce besoin lorsqu’elle porte principalement sur la détection et la réponse aux menaces. La frontière entre MDR et SOC externalisé varie selon les prestataires : vous devrez vérifier le périmètre réellement supervisé, les horaires de couverture, les délais d’intervention et les actions pouvant être réalisées directement.

Le VOC, quant à lui, intervient sur un autre volet. Il ne surveille pas les attaques en cours, mais aide à réduire les faiblesses exploitables.

Le choix dépend donc de vos besoins prioritaires :

• Si vous souhaitez détecter et traiter les incidents, orientez-vous vers un SOC externalisé ou un service MDR.
• Si vous devez mieux connaître et corriger vos vulnérabilités, envisagez un VOC.
• Si vous souhaitez agir à la fois sur les attaques et sur les faiblesses du système d’information, les deux approches sont complémentaires.

Un SIEM peut rester pertinent si vous êtes soumis à des exigences particulières de traçabilité, ou si votre SI est très hétérogène. Mais dans tous les cas, vous devrez confier son exploitation à une équipe compétente, qu’elle soit interne ou externe.

Entreprise équipée d’un SOC

Si vous disposez déjà d’un SOC, le choix entre SIEM et XDR dépend avant tout des sources que vos analystes doivent superviser.

Un XDR peut suffire lorsque les endpoints, les identités, la messagerie, le cloud et le réseau sont correctement couverts par une même solution. Il rapproche les signaux liés à une attaque, limite le nombre d’alertes isolées et permet aux analystes d’agir rapidement.

Le SIEM devient pertinent lorsque cette couverture ne suffit pas. Il permet d’intégrer des journaux provenant d’équipements, d’applications ou de technologies que le XDR ne prend pas en charge. Il offre également davantage de possibilités pour créer des scénarios de détection personnalisés, conserver les événements ou répondre à certaines exigences de traçabilité.

Vous pouvez combiner les 2 solutions, mais attention à ne pas juste créer un doublon. Le XDR prend en charge la détection et la réponse sur les couches qu’il couvre, tandis que le SIEM élargit la visibilité aux autres composants du système d’information. Ce sera le rôle de votre SOC de déterminer si cette vision supplémentaire est réellement nécessaire.

Organisation très distribuée ou orientée Cloud

Si vous avez de nombreux sites, des collaborateurs en télétravail et un usage important des applications Cloud, vous pouvez envisager une architecture SASE. Le SASE permet d’appliquer des politiques de sécurité cohérentes, quel que soit l’endroit depuis lequel l’utilisateur se connecte. Il permet notamment de :

• contrôler les accès selon l’identité, l’appareil utilisé, la ressource demandée et le contexte de la connexion,
• sécuriser la navigation web, les flux réseau et l’utilisation des services Cloud,
• éviter de faire transiter toutes les connexions par le siège de l’entreprise avant d’accéder à Internet ou aux applications Cloud,
• apporter une meilleure visibilité sur les usages réalisés en dehors du réseau local.

Attention, le SASE ne remplace ni le SIEM, ni le XDR, ni les équipes chargées de superviser la sécurité. Ses journaux et alertes peuvent alimenter les outils de détection, puis être analysés par un SOC ou un prestataire MDR. Il répond à un besoin différent : sécuriser les connexions et les accès d’une organisation distribuée. Si votre problème principal concerne la détection et le traitement des incidents, le SASE ne suffira pas à lui seul.

Entreprise devant structurer la gestion de ses vulnérabilités

Votre organisation peut disposer de capacités solides de détection et de réponse aux incidents, tout en manquant de visibilité sur les vulnérabilités de son système d’information ou de suivi sur leur remédiation. Et pour ça, acquérir un scanner de vulnérabilités ne suffit pas. Produire régulièrement une liste de plusieurs milliers de failles sans responsable, sans échéance et sans suivi n’est pas une stratégie de remédiation.

Dans ce cas, un VOC devient pertinent. Il permet d’organiser une démarche continue : recensement des actifs, détection des vulnérabilités, qualification, définition des priorités, accompagnement à la correction puis vérification de leur résolution. Le VOC apporte le pilotage qui manque souvent entre la découverte d’une faille et sa correction effective. C’est donc un complément intéressant au SOC et au MDR.

📝 SASE, SIEM, XDR, SOC, VOC et MDR : que retenir ?

En conclusion, SASE, SIEM, XDR, SOC, VOC et MDR sont des éléments bien distincts qui ne répondent pas tous au même besoin. J’espère que cet article vous a donné une meilleure vue d’ensemble de leurs fonctions et leurs interactions. Pour résumer, on pourrait dire :

• Le SASE sécurise les connexions et les accès,
• le SIEM centralise et corrèle les événements,
• le XDR facilite la détection et la réponse,
• le SOC organise la supervision opérationnelle,
• le MDR permet d’externaliser une partie de cette détection et de cette réponse,
• le VOC structure la gestion des vulnérabilités.

Comme souvent, la solution n’est pas d’empiler les acronymes, mais de vous poser les bonnes questions : quels actifs devez-vous protéger ? Quelles menaces devez-vous détecter ? Disposez-vous des équipes capables d’exploiter les outils ? Avez-vous besoin d’une surveillance continue ou d’un accompagnement pour réduire vos vulnérabilités ? Avec pour objectif de construire un dispositif cohérent, dans lequel chaque outil, chaque service et chaque équipe a un rôle clairement défini.

On en discute ensemble ?