Télémétrie endpoint : quels signaux remonter sans noyer le SOC

Le bruit tue l'alerte

Un Windows 11 avec un agent EDR standard génère entre 5 000 et 15 000 événements par heure en usage bureautique normal. Multipliez par 80 postes, ajoutez des MacBook sous macOS 14 et une flotte de smartphones Android, et votre SIEM ingère potentiellement 30 à 50 millions d'événements par jour — avant tout filtrage. À ce volume, les analystes cessent de traiter les alertes : ils les ferment. C'est le paradoxe de la télémétrie non maîtrisée : plus vous collectez, moins vous détectez.

Comprendre la hiérarchie des signaux

Tous les événements endpoint ne se valent pas. Avant de configurer quoi que ce soit, il faut distinguer trois niveaux :

• Signal brut : événement système bas niveau (création de fichier, appel réseau DNS, écriture registre). Utile pour la forensique post-incident, inutile en temps réel sans corrélation.
• Signal qualifié : événement contextualisé par une règle ou une baseline (ce processus n'a jamais établi de connexion sortante sur ce port). Actionnable pour un analyste.
• Alerte : signal qualifié ayant franchi un seuil de sévérité défini. Doit déclencher une action humaine dans un délai SLA défini (ex. 15 minutes pour critique, 4 heures pour élevé).

La confusion entre ces trois niveaux est la première source de surcharge SOC. Un SIEM qui traite du signal brut comme des alertes est une erreur d'architecture, pas un problème de capacité.

Les catégories de signaux réellement utiles

Sur la base des contrôles définis par les CIS Benchmarks (contrôles 8 et 13 notamment) et du cadre NIST Cybersecurity Framework, les événements à valeur opérationnelle confirmée pour un parc de 20 à 150 endpoints sont :

• Authentification et sessions : échecs successifs (seuil : 5 en 2 minutes), connexions hors plages horaires définies, première connexion depuis un nouveau device non enrôlé.
• Intégrité des configurations MDM : sortie de conformité MDM (profil retiré, chiffrement désactivé, OS non patché au-delà de J+30), modification non autorisée des politiques locales.
• Exécution de processus suspects : processus lancé depuis %TEMP% ou /tmp, script PowerShell encodé, invocation de osascript sur macOS hors politique approuvée.
• Mouvement réseau anormal : connexion sortante vers IP non catégorisée sur ports TCP 4444, 8080, 443 (sans SNI valide), trafic DNS anormalement volumineux (>500 requêtes/min par endpoint).
• Privilèges et droits : élévation locale (sudo, runas), ajout d'un compte administrateur local, modification du groupe Administrateurs.
• Intégrité des données : copie massive de fichiers vers support amovible ou cloud non approuvé, accès à plus de 500 fichiers en moins de 60 secondes (pattern ransomware).

Architecture de collecte : ne pas tout remonter au SIEM

L'erreur classique consiste à brancher l'agent EDR directement sur le SIEM en mode « tout remonter ». Le volume sature les licences (facturation à l'ingestion pour la plupart des SIEM SaaS) et ralentit les requêtes de corrélation. L'architecture correcte repose sur un pipeline à trois étapes :

1. Filtrage à la source (agent)

Configurez l'agent pour ne pas transmettre les événements à faible valeur : lectures de registre sans modification, activité réseau DNS vers résolveurs connus, logs de mise à jour OS. Sur Windows, cela passe par la politique d'audit avancée (Advanced Audit Policy Configuration) — activez uniquement les catégories nécessaires plutôt que d'activer l'audit global. Sur macOS 14, l'endpoint security framework permet un filtrage fin par type d'événement ES_EVENT_TYPE.

2. Agrégation et enrichissement (collecteur intermédiaire)

Un collecteur local (Syslog-ng, Fluentd, ou la fonction de pre-processing d'un SIEM hybride) regroupe, déduplique et enrichit les événements avec le contexte MDM : utilisateur associé, niveau de conformité du device au moment de l'événement, version OS, statut chiffrement. Cet enrichissement contextuel transforme un signal brut en signal qualifié sans intervention manuelle de l'analyste.

3. Règles de corrélation, pas de volume

Ce qui atteint le SIEM doit être exclusivement des événements enrichis. Le nombre de règles de corrélation actives pour une PME de 80 endpoints devrait rester entre 30 et 60 règles — pas 400. Au-delà, le taux de faux positifs dépasse 70 % et les analystes développent une « alert fatigue » documentée dès 20 alertes journalières non actionnables.

Particularités par plateforme

Windows (Autopilot / Intune)

Windows Event Log propose plus de 1 000 canaux. Les canaux à activer en priorité : Security (IDs 4624, 4625, 4648, 4720, 4732, 4776), System (41 pour crash inattendu, 7045 pour installation de service), et Microsoft-Windows-Sysmon/Operational si Sysmon est déployé. Pour les PME sans Sysmon, le canal PowerShell Operational (ID 4103, 4104) reste le minimum pour détecter l'exécution de scripts malveillants. Windows 11 23H2 introduit des améliorations dans la journalisation des processus protégés (PPL) : exploitez-les.

macOS (Apple Business Manager)

Via Apple Business Manager et un MDM compatible, vous pouvez déployer des profils de configuration qui activent la journalisation unifiée (unified logging) et l'exportent vers votre collecteur. Les sous-systèmes à surveiller : com.apple.security.keychain, com.apple.login, com.apple.mdm. L'outil log en CLI permet de tester les filtres avant déploiement. Attention : la rotation des logs macOS est agressive (24 à 72 heures selon le volume) — un agent de collecte local est indispensable pour ne pas perdre d'événements.

Android (MDM / Android Enterprise)

Android Enterprise en mode Work Profile ne donne pas accès aux logs système du device. La télémétrie disponible passe par l'API du MDM : conformité de l'appareil, version du patch de sécurité (objectif : patch mensuel de moins de 60 jours), statut du chiffrement, présence d'applications non approuvées dans le profil professionnel. Pour aller plus loin, Android Enterprise Fully Managed (COBO) permet un accès plus large, mais implique des contraintes d'usage acceptables uniquement pour des devices dédiés.

Alignement nLPD et journalisation

La nouvelle loi fédérale sur la protection des données (nLPD), en vigueur depuis le 01.09.2023, impose que tout traitement de données personnelles soit documenté (art. 12 OPDo). Les logs d'authentification et d'activité endpoint contiennent des données personnelles (identifiants, comportements, localisations réseau). Cela implique : durée de rétention définie et documentée (12 mois est une pratique courante, justifiable), accès aux logs restreint à des rôles nominatifs, et mention dans le registre des activités de traitement. En cas d'incident, le Préposé fédéral à la protection des données (PFPDT) peut demander la production de ces logs — autant qu'ils soient exploitables.

Ce qu'il ne faut pas collecter

La liste des signaux à exclure est aussi importante que celle des signaux à inclure :

• Contenu des emails ou des fichiers (hors hash cryptographique) : risque juridique disproportionné, valeur forensique limitée.
• Frappes clavier (keylogging) : interdit sauf cadre légal très spécifique (art. 328b CO pour la surveillance des travailleurs), quasi inapplicable en pratique PME.
• Captures d'écran automatiques : même risque juridique, et volume ingérable.
• Logs DNS internes complets en continu : utiles ponctuellement pour investigation, inutiles en streaming permanent au SIEM.
• Événements Windows de type Information en masse : création de fichiers temporaires, lectures de registre read-only, heartbeats d'antivirus. Filtrez-les à la source.

Cas pratique : fiduciaire vaudoise, 55 endpoints

Contexte : fiduciaire à Lausanne, 45 collaborateurs, 55 endpoints (32 PC Windows 11 23H2, 18 MacBook sous macOS 14, 5 iPads en mode Shared iPad). Parc géré via MDM centralisé. Pas de SOC interne : un MSP partenaire assure la surveillance 5j/7, avec escalade sur astreinte le week-end. Données traitées : comptabilité, déclarations fiscales, données salariales — tout est sensible au sens de la nLPD.

Situation initiale

Avant optimisation, le MDM et les agents remontaient ~8 millions d'événements/jour. Le SIEM SaaS facturait à l'ingestion : coût mensuel CHF 1 400 pour 250 GB/mois. Le MSP recevait 180 alertes/semaine, dont 160 classées faux positifs après analyse. Temps de traitement estimé : 6 heures/semaine d'analyste, soit environ CHF 900/mois au tarif MSP.

Procédure d'optimisation appliquée

1. Inventaire des sources (DSI + MSP, J+0 à J+5) : cartographie de tous les agents actifs, canaux Windows ouverts, politiques d'audit macOS. Identification des 12 canaux générant 80 % du volume — dont 9 sans valeur SOC confirmée.
2. Définition du périmètre de collecte utile (DSI + RSSI MSP, J+5 à J+10) : sélection des 6 catégories de signaux listées plus haut. Exclusion explicite documentée pour les catégories écartées.
3. Déploiement d'un collecteur intermédiaire (MSP, J+10 à J+20) : VM légère (2 vCPU, 4 GB RAM) déployée on-premises pour pré-filtrage et enrichissement MDM. Réduction du flux brut de 8 millions à 420 000 événements/jour avant transmission SIEM.
4. Révision des règles de corrélation (MSP analyste, J+20 à J+30) : passage de 210 règles actives à 42 règles validées. Chaque règle documentée avec critère de déclenchement, faux positif connu, et SLA de traitement.
5. Mise à jour du registre de traitement nLPD (juriste externe + DSI, J+30) : documentation de la rétention (12 mois), des accès nominatifs, et des catégories de données traitées dans les logs.
6. Bilan à J+60 : volume SIEM 22 GB/mois (-91 %), coût ingestion CHF 160/mois, alertes MSP 28/semaine dont 4 faux positifs. Économie totale : CHF 2 000/mois entre réduction SIEM et temps analyste.

Le signal le plus utile découvert lors de l'optimisation : deux MacBook se connectaient régulièrement à un partage SMB externe non répertorié, hors plages horaires. Invisible dans le flux initial noyé de bruit, visible immédiatement après filtrage. L'investigation a révélé une synchronisation automatique configurée par un collaborateur — non malveillante, mais non conforme à la politique de données.

Des outils comme SynGuard permettent d'automatiser une partie de ce pipeline — enrichissement MDM, corrélation de conformité, remontée filtrée — sans nécessiter une infrastructure SIEM lourde pour des parcs de cette taille.

Récapitulatif opérationnel

1. Inventoriez toutes vos sources de télémétrie actuelles et quantifiez leur volume journalier avant de modifier quoi que ce soit.
2. Appliquez la hiérarchie signal brut / signal qualifié / alerte : ne faites jamais remonter du brut directement au SIEM.
3. Limitez les canaux Windows Event Log aux IDs critiques (4624, 4625, 4648, 4720, 4732, 4104 minimum). Désactivez l'audit global.
4. Sur macOS, déployez un agent de collecte locale — la rotation native des logs est trop rapide pour une collecte SIEM directe.
5. Déployez un collecteur intermédiaire pour enrichir les événements avec le contexte MDM (conformité, OS version, chiffrement) avant ingestion SIEM.
6. Ciblez 30 à 60 règles de corrélation actives maximum pour un parc de 20-150 endpoints. Documentez chaque règle avec son seuil et son SLA.
7. Excluez explicitement le contenu (emails, fichiers), le keylogging et les logs DNS complets en streaming — risque légal disproportionné.
8. Documentez la rétention des logs et les accès dans votre registre de traitement nLPD. Durée recommandée : 12 mois.
9. Mesurez votre taux de faux positifs hebdomadairement. Au-delà de 30 %, revisez vos règles avant d'ajouter de nouvelles sources.
10. Pour les signalements d'incidents touchant des données personnelles, référez-vous à la procédure de signalement du NCSC et au délai de 72 heures imposé par la nLPD pour notification au PFPDT.

Sources

• CIS Benchmarks — Center for Internet Security — Contrôles 8 (Audit Log Management) et 13 (Network Monitoring and Defense), référence pour la sélection des événements à collecter.
• NIST Cybersecurity Framework — Fonctions Detect et Respond : cadre structurant pour la télémétrie et la réponse aux incidents.
• Ordonnance sur la protection des données (OPDo) — fedlex.admin.ch — Base légale pour la documentation des traitements de logs contenant des données personnelles.
• NCSC — Signalement d'incidents cyber — Procédure officielle de signalement pour les entreprises suisses victimes d'incidents.
• Préposé fédéral à la protection des données et à la transparence (PFPDT) — Autorité de contrôle nLPD, interlocuteur pour les notifications d'incidents impliquant des données personnelles.