Les 3 signaux faibles qu’un EDR ne voit pas sans SOC

Pourquoi un EDR seul n’est pas la réponse complète ?

Pour s’en tenir à un chiffre parlant : les analyses de tendances montrent que le temps médian des intrusions reste mesurable en jours (et parfois en semaines), ce qui laisse beaucoup de temps aux acteurs malveillants pour opérer si les signaux sont dispersés et peu bruyants. M‑Trends / Mandiant publie des données récentes sur ces durées d’intrusion.

Dans cet article nous décortiquons trois catégories de signaux faibles qu’un EDR seul peut manquer, et ce que fait un SOC managé pour combler ces angles morts.

Signal faible #1 – Corrélation contextuelle manquante : événements faibles dispersés

Qu’est‑ce que c’est ?

Il s’agit d’événements discrets et bénins pris isolément : tentatives d’authentification faibles, accès à un fichier anormal mais non bloquant, processus légitime lancé avec un paramètre rare, qui apparaissent sur plusieurs endpoints à intervalles espacés. Chacun de ces événements ne franchit pas le seuil d’alerte local, mais pris ensemble ils dessinent une séquence malveillante.

Pourquoi l’EDR peut les rater ?

Les EDR optimisent la détection d’anomalies marquées sur un hôte unique. Ils appliquent souvent des seuils, des signatures et des heuristiques hôte‑centric qui privilégient les incidents bruyants, tandis que les petites actions réparties (telles que des scans internes répartis) restent sous le radar.

Ce que fait un SOC

Un SOC centralise la télémétrie (endpoints, logs d’authentification, réseaux, proxies), corrèle événements cross‑endpoint et analyse la timeline. La corrélation transforme dix petites alertes « froides » en une alerte consolidée priorisée pour investigation.

Exemple concret

Sur 72 heures, dix postes différents reçoivent chacun 3 à 4 tentatives de connexion échouées depuis la même sous‑plage interne. Sur chaque poste isolé, l’EDR crée des alertes faibles ou des événements d’audit. Le SOC corrèle les identifiants, la source réseau et la chronologie et déclenche une investigation qui révèle un scan interne préparatoire à une intrusion.

Signal faible #2 – Méthode de type « évasion »

Qu’est‑ce que c’est ?

Les attaquants modernes privilégient souvent des déplacements latéraux progressifs et une exfiltration par petits paquets étalée sur des jours ou des semaines. Au total, le volume exfiltré peut être conséquent, mais chaque transfert est trop modeste pour déclencher des règles volumétriques classiques.

Pourquoi l’EDR peut les rater ?

Les EDR basés sur signatures et sur détection d’anomalies host‑level ont du mal à reconstituer une séquence longue mêlant accès légitimes détournés, tâches planifiées modifiées et communications chiffrées discrètes. Les règles focalisées sur « pics » d’activité laissent passer les transferts faibles et répétés.

Quel est le rôle du SOC ?

Le SOC suit les indicateurs temporels (dwell time), reconstruit la chaîne d’attaque en corrélant réseau + endpoint + DNS/API, et déclenche du threat hunting proactif. Les playbooks SOC permettent des réponses ciblées : quarantaine, blocage IP, rotation de credentials, collecte forensique et remédiation coordonnée.

KPI à surveiller

• MTTD (Mean Time to Detect) – objectif : le plus bas possible selon SLA
• MTTR / temps de containment – indicatif : Critical < 1h, High < 2-4h (à adapter par SLA)
• Dwell time moyen – réduire la « fenêtre » d’exposition

Des guides sur la détection de comportements off‑hour et d’exfiltration low‑and‑slow montrent pourquoi la corrélation et la conservation d’historique sont indispensables (voir exemples techniques cités par des éditeurs de monitoring réseau).

Signal faible #3 – Anomalies liées à l’identité, au cloud et à la configuration

Qu’est‑ce que c’est ?

Il s’agit des abus de comptes, des usages anormaux d’API cloud, des dérogations de permissions, ou des changements de configuration infra‑as‑code qui n’émettent pas forcément d’alerte sur un endpoint. Ces activités peuvent toucher directement des données SaaS (SharePoint, Exchange), des services managés ou la console cloud.

Limites de l’EDR

L’EDR limite sa visibilité à l’hôte. Il n’ingère pas nativement les logs Entra/Azure AD, les journaux d’API SaaS, CloudTrail, ou les événements de configuration du cloud. Ainsi, une extraction depuis SharePoint initiée via une API ou un compte de service compromis peut être invisible côté endpoint.

Microsoft documente la montée des attaques ciblant les identités et souligne l’importance d’ingérer la télémétrie cloud/IAM pour détecter ces attaques. Microsoft – Digital Defense.

Ce que fait un SOC

Un SOC ingère et corrèle logs cloud (IAM, APIs SaaS), identités et endpoints pour repérer des anomalies d’accès (géolocalisation, horaire, volume). Il réalise des audits de configuration, détecte les consent grants suspects et peut lier une session API anormale à un utilisateur ou à un endpoint donné.

Exemple concret

Un compte de service compromis télécharge des fichiers depuis SharePoint en utilisant l’API Graph. Les endpoints des utilisateurs ne montrent aucun exécutable malveillant : l’activité est côté cloud. Le SOC, ayant ingéré les logs M365 et Entra, détecte un pattern d’accès anormal et stoppe l’exfiltration.

Checklist rapide (contrôles IAM & cloud pour MSP)

• Activer MFA pour tous les comptes à privilèges et surveiller les tentatives de bypass/consent grants.
• Centraliser les logs cloud/IAM (Entra ID / CloudTrail / M365 audit) dans la plateforme SOC.
• Définir des baselines d’activité d’identité (géolocalisation, horaire, volume) et créer alertes sur déviations.

Guide pratique pour les MSP : détecter et remédier aux signaux faibles

Checklist opérationnelle pour détecter :

• Centraliser les logs : endpoints, AD/Entra, M365, cloud control plane, firewall/DNS/proxy.
• Conserver une rétention historique adaptée : 30-90 jours minimum pour baselines, 12+ mois utile pour hunting long terme.
• Mettre en place corrélations identité↔endpoint↔réseau et créer règles cross‑source.
• Planifier des campagnes régulières de threat hunting ciblées sur signaux faibles.

Checklist opérationnelle pour répondre :

• Élaborer playbooks IR simples (first-hour) : isoler host, collect forensic, changer credentials, bloquer accès réseau.
• Définir une procédure d’escalade vers un CERT (SLA 24/7) et canaux de communication client.
• Standardiser les rapports clients : impact, actions réalisées, recommandations court/moyen terme.
• Mesurer régulièrement MTTD, MTTR, dwell time et taux d’alertes corrélées.

Pour construire des playbooks basés sur des standards, référez‑vous aux guidelines NIST (SP 800‑61) et aux playbooks CISA. NIST SP 800‑61 fournit un cadre opérationnel utile pour l’IR.