01MDR, MSSP, SOC-as-a-Service : ce qui distingue ces notions
Le Managed Detection & Response désigne des fonctions SOC fournies à distance et pilotées par des analystes : surveillance continue, investigation et confinement actif des menaces – c'est aussi ainsi que des cabinets d'analystes comme Gartner le décrivent dans leurs Market Guides. Les Managed Security Service Providers (MSSP) classiques, en revanche, exploitent avant tout l'infrastructure de sécurité, surveillent les événements et transmettent les alertes à l'équipe interne ; la réaction proprement dite reste en règle générale à la charge du client. « SOC-as-a-Service » est employé de manière hétérogène sur le marché et désigne le plus souvent un Security Operations Center externe par abonnement, plateforme et personnel compris – dans la pratique, cela recoupe largement le MDR. L'essentiel n'est donc pas l'étiquette, mais la capacité garantie contractuellement : qui détecte, qui investigue – et qui est autorisé à intervenir ?
02Briques de service : monitoring, triage, response, threat hunting
Le cœur de tout service MDR est la surveillance 24/7 de la télémétrie issue des terminaux (EDR), des identités, du réseau et du cloud, souvent sur une pile technologique prédéfinie par le prestataire. Lors du triage, les analystes – appuyés par l'automatisation – distinguent les incidents réels des faux positifs, priorisent selon la gravité et enrichissent les alertes avec du contexte et de la threat intelligence. La réponse active distingue le MDR de la simple remontée d'alertes : dans le cadre convenu, le prestataire peut confiner lui-même les menaces, par exemple isoler des hôtes compromis, bloquer des comptes ou arrêter des processus malveillants. Le threat hunting complète la détection par alertes par une recherche, fondée sur des hypothèses, d'activités d'attaquants que les règles de détection existantes ne couvrent pas encore.
03MTTD, MTTR et ce que ces indicateurs disent vraiment
Le Mean Time to Detect (MTTD) mesure le délai entre le début d'une activité d'attaque et sa détection, le Mean Time to Respond (MTTR) le délai jusqu'à la réaction ou au confinement ; on utilise en complément le Mean Time to Acknowledge (MTTA) et le Mean Time to Contain (MTTC). Ces valeurs ne deviennent parlantes que par classe de gravité et dans la durée – des chiffres moyennés sur l'ensemble des incidents masquent les valeurs aberrantes et les différences de priorité. Point important pour les contrats : un MTTD garanti peut difficilement être promis sérieusement, car le point de départ d'une attaque est par nature inconnu ; les SLA définissent donc habituellement des délais de réaction et de notification à compter de la réception de l'alerte. Exigez du prestataire des indicateurs définis de manière transparente, précisant quand le chronomètre démarre et quand il s'arrête.
04Onboarding : raccordement des logs, cas d'usage, runbooks
La qualité d'un service MDR se joue pour l'essentiel lors de l'onboarding. Tout commence par le raccordement des sources de télémétrie et de logs, priorisées selon leur valeur de détection – typiquement les services d'identité, les terminaux, les composants réseau et les services cloud ; le standard minimal du BSI relatif à la journalisation et à la détection des cyberattaques (version 2.1, 2024) s'adresse certes à l'administration fédérale allemande, mais offre aussi aux autres organisations une orientation solide sur les événements à journaliser. Sur cette base, un catalogue de cas d'usage est défini, souvent structuré selon les tactiques et techniques de MITRE ATT&CK, puis ajusté à l'environnement lors d'une phase de tuning. Enfin, les runbooks fixent pour chaque scénario qui a le droit de faire quoi : quelles mesures de confinement le prestataire exécute de façon autonome, quand il y a escalade et qui doit être joignable côté client.
05Critères de SLA et de sélection
Les points centraux d'un SLA sont les délais de réaction et de notification par niveau de gravité, une disponibilité permanente, des voies d'escalade définies et un reporting avec des indicateurs traçables. Vérifiez également le lieu de traitement des données et sa qualification au regard de la protection des données, la compatibilité avec votre pile technologique existante ainsi que la portabilité des contenus de détection, des données de logs et de l'historique des dossiers en cas de sortie. Pour les entités relevant du champ d'application de NIS2 s'ajoute l'assistance aux obligations de notification : l'article 23 de la directive (UE) 2022/2555 exige une alerte précoce dans les 24 heures et une notification dans les 72 heures après la prise de connaissance d'un incident de sécurité important, ainsi qu'un rapport final au plus tard un mois après la notification. Le prestataire doit préparer ses constats de manière suffisamment rapide et structurée pour que ces délais soient tenables – l'obligation de notification elle-même reste à la charge de l'entité concernée.
06Make or buy : SOC interne, MDR ou modèle co-managé
Un SOC interne 24/7 exige un fonctionnement en équipes continu, un detection engineering permanent et une montée en compétences constante – des efforts que, compte tenu de la pénurie de spécialistes, seule une partie des organisations peut supporter durablement. Le MDR apporte en revanche un saut de maturité rapide à coûts prévisibles, mais réduit le contrôle direct sur la logique de détection et la priorisation. Les modèles co-managés se sont imposés comme voie intermédiaire : l'organisation conserve la maîtrise du SIEM ou de la plateforme de données, tandis que le prestataire assure l'analyse et la réponse 24/7. Quel que soit le modèle : NIST SP 800-61 Rev. 3 (2025) ancre la réponse aux incidents dans la gestion globale du cyber-risque – la gouvernance, la communication de crise et la reprise d'activité restent des tâches internes, même avec un MDR.
