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

Le bruit comme première vulnérabilité

Un Windows 11 23H2 correctement configuré génère entre 80 000 et 120 000 événements par jour dans le journal natif — avant tout durcissement. Multipliez par 80 postes, ajoutez les terminaux macOS 14 Sonoma et les smartphones Android 13/14 gérés via MDM, et vous atteignez rapidement 8 à 10 millions d'événements quotidiens dans votre SIEM. Un analyste SOC peut traiter 20 à 40 alertes qualifiées par jour. Le fossé entre la collecte brute et la capacité humaine est structurel, pas conjoncturel.

La solution n'est pas d'ingérer moins aveuglément, mais de définir une taxonomie d'événements fondée sur le risque métier, les exigences légales suisses et l'architecture réelle du parc. Ce qui suit est une méthode applicable à une PME romande disposant d'un parc de 20 à 150 endpoints, avec ou sans SOC externalisé.

Cadre légal et obligations de traçabilité en Suisse

La nouvelle loi fédérale sur la protection des données (nLPD), en vigueur depuis le 01.09.2023, impose une obligation de documentation des violations de données et, sous conditions, leur notification au Préposé fédéral à la protection des données (PFPDT). Pour satisfaire à cette obligation de manière réaliste, vous devez être en mesure de reconstituer une chronologie d'incident sur au minimum 30 jours — ce qui implique une rétention minimale des logs d'authentification, d'exécution de processus et d'accès aux données sensibles.

Pour les entreprises soumises à la FINMA (banques cantonales, gérants de fortune, assurances), la circulaire FINMA 2023/1 durcit les exigences : journalisation des accès privilégiés, intégrité des logs et délai de notification de 24 heures pour les incidents critiques. Ces obligations définissent un plancher de collecte, pas un plafond.

Le Centre national pour la cybersécurité (NCSC) recommande dans ses conseils aux PME de conserver les journaux d'événements de sécurité pendant au moins 6 mois, avec une accessibilité immédiate sur les 30 premiers jours. C'est un minimum raisonnable pour une PME sans contrainte sectorielle.

Taxonomie des signaux : ce qui compte vraiment

Niveau 1 — Signaux critiques, toujours collecter

Ces événements ont un ratio signal/bruit élevé et une valeur forensique immédiate. Leur absence dans un SIEM est une lacune défensive caractérisée.

• Authentifications : échecs répétés (seuil : 5 échecs en 2 minutes sur Windows = EventID 4625 ; sur macOS = entrée dans /var/log/system.log avec pam_unix), élévations de privilèges (sudo, UAC), connexions hors horaires business.
• Exécution de processus suspects : processus lancés depuis %TEMP%, /tmp, ou des répertoires utilisateur non standards ; binaires signés par des certificats inconnus ; script PowerShell avec ExecutionPolicy Bypass ou encodage Base64 détecté dans la ligne de commande.
• Modifications de configuration système : changements de GPO ou de profil MDM non initiés par le canal officiel (Autopilot, Apple Business Manager, Intune), ajout de compte administrateur local, désactivation du pare-feu ou de l'agent EDR.
• Transferts de données inhabituels : upload vers des destinations cloud non whitelistées au-delà de 50 Mo en session unique, exfiltration sur ports non standards (ex. DNS sur port 53 avec payload > 512 octets = signe de DNS tunneling).
• État de conformité MDM : device non-compliant, certificat SCEP expiré, profil de configuration effacé manuellement.

Niveau 2 — Signaux contextuels, collecter avec agrégation

Ces événements ont une valeur uniquement en corrélation. Les remonter bruts sature le SIEM ; les agréger côté agent avant envoi réduit le volume de 60 à 80 %.

• Connexions réseau sortantes (agréger par destination IP/domaine + volume toutes les 15 minutes, pas événement par événement).
• Inventaire logiciel et versions : collecter à J+1, pas en temps réel. Un script FleetDM ou un profil Intune Compliance Policy suffit pour détecter les applications non conformes aux CIS Benchmarks.
• Mises à jour OS manquantes : delta entre version déployée et version cible (macOS 14.x, Windows 11 23H2/24H2) — signal quotidien, pas horaire.
• Performances système anormales : CPU > 90 % pendant > 10 minutes peut indiquer un cryptomineur ; à corréler avec le processus consommateur.

Niveau 3 — Signaux à désactiver ou filtrer à la source

Ces événements représentent 70 à 80 % du volume brut pour moins de 5 % de la valeur opérationnelle.

• EventID 4634 (logoff réussi) et 4624 (logon réussi) non filtrés — remplacez par une règle d'agrégation sur les sessions anormales uniquement.
• Logs DNS complets non filtrés sur les domaines Microsoft/Apple CDN (akamaitechnologies.com, akamaiedge.net, etc.) : générez une whitelist et excluez-les côté collecteur.
• Heartbeats MDM toutes les 15 minutes : consolidez en un rapport de compliance quotidien.
• Logs antivirus pour détections sur fichiers temporaires navigateur (cookies, cache) : créez une règle de suppression côté SIEM pour les chemins %LocalAppData%\Google\Chrome\User Data\*.

Architecture de collecte pour un parc de 20 à 150 endpoints

Réduire le volume avant le réseau

L'erreur classique est de tout envoyer vers le SIEM et de filtrer ensuite. Le coût de stockage SIEM (en Suisse, les offres vont de CHF 0.15 à CHF 0.50 par Go ingéré selon le provider) et la latence d'analyse rendent cette approche intenable dès 50 endpoints actifs.

La bonne architecture : un agent léger sur chaque endpoint (Sysmon sur Windows avec une configuration basée sur le NIST Cybersecurity Framework, ou osquery/FleetDM sur macOS/Linux) qui pré-filtre selon une politique de collecte versionnée, puis transmet uniquement les événements des niveaux 1 et 2 agrégés. Le volume typique passe de 10 millions à 80 000–150 000 événements/jour pour 80 endpoints.

Séparation des canaux MDM et télémétrie sécurité

Le canal MDM (Apple Business Manager / Windows Autopilot / Android Enterprise) et le canal de télémétrie sécurité doivent rester logiquement séparés. Le MDM gère la configuration, la conformité et le déploiement applicatif. La télémétrie sécurité capte les comportements runtime. Mélanger les deux dans le même pipeline crée des angles morts : un endpoint peut apparaître « compliant » en MDM tout en exécutant un processus malveillant que seul un agent EDR ou osquery détecterait.

Architecture recommandée pour une PME de 50 à 100 endpoints :

1. MDM (Intune / Jamf / FleetDM) → rapport de compliance quotidien vers SIEM (volume : quelques centaines d'événements/jour).
2. Agent de collecte sécurité (Sysmon + WEF sur Windows, osquery sur macOS) → collecteur intermédiaire (ex. Elastic Agent ou Cribl) → SIEM.
3. Règles de suppression configurées dans le collecteur intermédiaire, pas dans le SIEM, pour réduire les coûts d'ingestion.
4. Rétention hot (requêtes immédiates) : 30 jours. Rétention cold (archive chiffrée, Suisse) : 6 mois minimum selon recommandations NCSC.

Cas pratique : fiduciaire genevoise, 65 endpoints

Une fiduciaire genevoise de 42 collaborateurs gère 65 endpoints (45 Windows 11 23H2, 12 MacBook Pro macOS 14 Sonoma, 8 smartphones Android 13 sous Android Enterprise). Leur SIEM externalisé facture CHF 0.28/Go ingéré. Avant optimisation, le volume mensuel atteignait 2.4 To, soit une facture d'ingestion de CHF 672/mois, sans compter les 3 heures/jour que l'analyste du SOC partenaire consacrait au tri d'alertes sans valeur.

Étape 1 — Audit du volume : le DSI extrait les statistiques d'ingestion du SIEM sur 30 jours. Résultat : 68 % du volume provient des EventID 4624/4634 non filtrés et des logs DNS complets des sessions Microsoft 365.

Étape 2 — Déploiement d'une configuration Sysmon durcissante : la politique Sysmon est adaptée du profil CIS Windows 11 Benchmark v1.0. Elle capture les EventID Sysmon 1 (création de processus), 3 (connexion réseau avec filtrage whitelist), 7 (chargement de driver), 11 (création de fichier dans chemins sensibles) et 22 (requêtes DNS hors whitelist). Les EventID Windows natifs 4624/4634 sont désactivés dans la GPO de collecte.

Étape 3 — Collecteur intermédiaire avec règles de suppression : un collecteur Cribl est déployé on-premises (VM 2 vCPU, 4 Go RAM sur l'infrastructure existante). Les règles de suppression excluent : DNS vers *.microsoft.com, *.apple.com, *.office365.com ; logs antivirus sur chemins cache navigateur ; heartbeats MDM Intune.

Étape 4 — Validation de la couverture : le RSSI externe simule 3 scénarios de test (exécution PowerShell encodé, ajout d'un compte admin local, connexion RDP hors horaires). Les 3 déclenchent des alertes dans les 90 secondes.

Résultat après 30 jours : volume réduit de 2.4 To à 310 Go/mois (-87 %), facture SIEM de CHF 672 à CHF 87/mois. Le SOC partenaire passe de 3 heures à 35 minutes de tri quotidien. Le DSI estime le ROI à moins de 2 mois.

Récapitulatif opérationnel

1. Auditer le volume actuel : extraire les 10 sources d'événements les plus volumineuses du SIEM sur 30 jours. Calculer leur ratio volume/alertes actionnables.
2. Définir la politique de collecte par niveau (1/2/3) : documenter dans un registre versionné (Git ou équivalent). Associer chaque source à une exigence légale (nLPD, FINMA) ou à un cas d'usage de détection concret.
3. Déployer un collecteur intermédiaire : ne jamais filtrer uniquement dans le SIEM. Réduire le bruit avant l'ingestion pour maîtriser les coûts et la latence.
4. Séparer les pipelines MDM et sécurité : compliance MDM = rapport quotidien agrégé ; télémétrie runtime = événements filtrés en quasi-temps réel.
5. Valider la couverture par simulation : au moins 3 scénarios d'attaque (élévation de privilège, exécution de script, exfiltration DNS) chaque trimestre. Un signal non testé est un signal dont on ignore s'il fonctionne.
6. Fixer la rétention : 30 jours hot, 6 mois cold chiffré, hébergement en Suisse pour les données couvertes par la nLPD.
7. Revoir la politique semestriellement : les tactiques ATT&CK évoluent, les versions OS changent (Windows 11 24H2, macOS 15), et les seuils de la politique de collecte doivent suivre.
8. Documenter les exclusions : chaque règle de suppression doit être justifiée par écrit. En cas d'incident, l'auditeur voudra savoir pourquoi tel événement n'a pas été collecté.

SynGuard accompagne les équipes IT de PME romandes dans la mise en place de ces pipelines de collecte, de l'audit initial à l'intégration MDM/EDR, sans générer de dette technique invisible.

Sources

• Fedlex — Loi fédérale sur la protection des données (nLPD) — Texte consolidé de la nLPD en vigueur depuis le 01.09.2023.
• NCSC — Centre national pour la cybersécurité — Recommandations et alertes pour les PME suisses, conseils de journalisation et de gestion des incidents.
• PFPDT — Préposé fédéral à la protection des données et à la transparence — Directives sur la notification des violations de données et les obligations documentaires.
• CIS Benchmarks — Center for Internet Security — Profils de durcissement pour Windows 11, macOS 14 et Android, référence pour la politique de collecte Sysmon.
• NIST Cybersecurity Framework — Cadre de référence pour la catégorisation des contrôles de détection et la gestion des risques endpoints.