Telemetry endpoint : quels signaux remonter sans noyer le SOC

Trop de données tuent la détection

Un poste Windows 11 23H2 avec l'audit complet activé génère entre 5 000 et 15 000 événements par heure selon sa charge applicative. Multipliez par 80 endpoints, ajoutez les logs macOS Sonoma et quelques terminaux Android gérés en MDM : votre SIEM ingère plusieurs gigaoctets par jour, vos analystes passent plus de temps à trier des faux positifs qu'à investiguer des incidents réels. Le problème n'est pas la collecte, c'est la sélection.

Cadre de référence : ce que prescrivent CIS et NIST

Avant de câbler quoi que ce soit, ancrez votre stratégie de télémétrie dans deux référentiels complémentaires.

CIS Benchmarks — niveau 1 vs niveau 2

Les CIS Benchmarks distinguent le niveau 1 (configuration minimale sûre, applicable à tout parc) du niveau 2 (environnement à haute sensibilité, coût opérationnel plus élevé). En matière d'audit Windows, le niveau 1 active la journalisation de :

• Connexions/déconnexions de session (Event ID 4624, 4634, 4647)
• Échecs d'authentification (Event ID 4625) avec seuil d'alerte à 5 échecs en 10 minutes
• Modifications de comptes privilégiés (Event ID 4728, 4732, 4756)
• Démarrage/arrêt du service (Event ID 7035, 7036)
• Exécution de processus si Sysmon est déployé (Event ID 1, 3, 11)

Le niveau 2 ajoute l'audit de l'accès aux objets (Event ID 4663), des modifications de stratégie (Event ID 4719) et l'intégralité de la journalisation PowerShell (Event ID 4103, 4104). Sur un parc mixte PME, commencer au niveau 1 strict réduit le volume de logs d'un facteur 6 à 10 par rapport à un audit « tout activer ».

NIST CSF — Identify, Detect, Respond

Le NIST Cybersecurity Framework structure la télémétrie autour de trois fonctions opérationnelles : identifier les actifs et leurs états, détecter les anomalies, répondre aux incidents. Chaque signal collecté doit servir au moins une de ces trois fonctions. Un log qui n'alimente ni un tableau de bord d'inventaire, ni une règle de détection, ni un playbook de réponse, est du bruit à éliminer.

Signaux à fort rapport signal/bruit par type d'endpoint

Windows 11 — Autopilot et Intune

Dans un déploiement Windows Autopilot, l'état de conformité MDM est lui-même un signal de premier niveau : un device qui quitte l'état Compliant (chiffrement BitLocker désactivé, version OS dépassée, certificat SCEP expiré) doit remonter en priorité P2 vers le SOC, indépendamment des logs système. Au-delà de l'état MDM, les signaux Windows les plus discriminants pour détecter une compromission réelle sont :

• Lateral movement : connexion réseau sortante sur le port TCP 445 (SMB) depuis un poste non-serveur
• Persistence : modification de clé de registre HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run (Sysmon Event ID 13)
• Credential access : accès à lsass.exe avec droits PROCESS_VM_READ (Sysmon Event ID 10)
• Execution : processus enfant de winword.exe, excel.exe ou outlook.exe (Event ID 1, parent image filtré)
• Defense evasion : désactivation de Windows Defender via PowerShell (Event ID 4104 + cmdlet Set-MpPreference)

Ces cinq catégories couvrent les techniques MITRE ATT&CK les plus fréquemment observées sur les PME selon les rapports NCSC. Elles représentent moins de 0,5 % du volume d'événements bruts, mais plus de 80 % de la valeur détective réelle.

macOS Sonoma — Apple Business Manager

Sur les flottes Apple gérées via Apple Business Manager (ABM) et un MDM compatible, la télémétrie native passe par les Unified Logs (log stream / log collect) et les rapports MDM. Les signaux prioritaires :

• Activation/désactivation de FileVault (clé de récupération escrow MDM)
• Installation d'un profil de configuration non signé par ABM
• Tentative d'accès à Keychain depuis un processus non Apple (securityd logs)
• Changement de statut Gatekeeper (spctl --status passant à disabled)
• Connexion SSH entrante sur le port TCP 22 si le service est désactivé par politique

FleetDM permet d'interroger ces états via des requêtes osquery planifiées (intervalle recommandé : 300 secondes pour les états de sécurité, 3 600 secondes pour l'inventaire logiciel), sans générer le flux continu des Unified Logs complets.

Android — MDM et Android Enterprise

Les terminaux Android gérés en mode Work Profile génèrent peu de télémétrie native exploitable au niveau SOC. L'essentiel des signaux utiles vient du MDM lui-même :

• Statut de chiffrement du stockage (doit être encrypted en permanence)
• Version du patch de sécurité Android (seuil : pas plus de 90 jours de retard)
• Présence d'une application non approuvée dans le Work Profile
• Détection de root (SafetyNet Attestation / Play Integrity API)

Ces quatre états, interrogés toutes les 4 heures par le MDM, suffisent pour la grande majorité des PME. L'ajout d'un agent EDR sur Android est justifié uniquement pour les flottes manipulant des données sensibles (santé, données financières FINMA).

Architecture de collecte : éviter la pipeline obèse

Filtrage à la source, pas au SIEM

Le coût d'ingestion d'un SIEM cloud se calcule au gigaoctet ou à l'événement. Filtrer en amont — sur l'agent ou le forwarder — coûte moins cher et réduit la latence de détection. La règle pratique : tout événement filtrable par une condition booléenne simple (Event ID ≠ liste blanche, processus ≠ liste blanche) doit être filtré avant envoi. Les événements nécessitant une corrélation multi-source (4624 + 4648 sur deux machines différentes en moins de 60 secondes) ne peuvent être filtrés qu'au SIEM.

Niveaux de priorité et SLA de traitement

Définissez trois niveaux de signal avec des SLA d'investigation explicites :

1. P1 — Critique (SLA : 15 minutes) : accès à LSASS, désactivation EDR/AV, exfiltration DNS anormale, device MDM passant en Wiped hors procédure
2. P2 — Élevé (SLA : 2 heures) : 5+ échecs d'authentification en 10 minutes, modification de groupe privilégié, nouveau processus persistant détecté
3. P3 — Surveillance (SLA : 24 heures) : device hors conformité MDM, version OS dépassée de plus de 30 jours, certificat expirant dans moins de 14 jours

Sans SLA explicite, les P3 s'accumulent et noient les P1 dans les tableaux de bord. C'est la première cause d'alert fatigue observée sur les petits SOC.

Rétention et nLPD

La nouvelle loi sur la protection des données (nLPD), en vigueur depuis le 01.09.2023, impose de limiter la collecte de données personnelles au strict nécessaire (principe de minimisation, art. 6 al. 2). Les logs d'authentification contenant des identifiants nominatifs sont des données personnelles : leur rétention doit être définie dans votre registre des activités de traitement, avec une durée proportionnée à l'objectif de sécurité. Une rétention de 90 jours pour les logs P1/P2 et 30 jours pour les logs P3 est généralement défendable. Au-delà, documentez la justification dans votre registre.

Cas pratique : bureau d'ingénierie vaudois, 65 endpoints

Un bureau d'études en génie civil basé à Lausanne, 65 postes Windows 11 23H2 et 8 MacBook Pro sous macOS Sonoma 14, géré via Intune/Autopilot et Apple Business Manager. Pas de SOC interne : les alertes sont traitées par un MSP partenaire sous convention avec un SLA P1 de 30 minutes (heures ouvrables) et 2 heures (hors heures).

Situation initiale

Le MSP avait activé l'audit complet Windows sans filtrage. Volume ingéré : ~4,2 Go/jour (environ 11 millions d'événements). Coût SIEM mensuel : CHF 620. Nombre d'alertes générées par mois : 3 400, dont 97 % de faux positifs (principalement Event ID 4624 sur les comptes de service). Temps analyste consommé par les faux positifs : 18 heures/mois.

Mise en place du filtrage

Procédure déployée sur 3 semaines :

1. Inventaire des sources : liste exhaustive des Event IDs collectés, classés par volume et par valeur détective estimée. Réalisé par le DSI du bureau + architecte MSP.
2. Définition de la liste blanche de processus : les 40 processus Microsoft et éditeurs connus (AutoCAD, Revit, Adobe) exemptés de la règle de détection « processus enfant Office ». Validation par le RSSI du MSP.
3. Déploiement Sysmon avec configuration filtrée : utilisation d'une configuration Sysmon basée sur le profil CIS niveau 1, suppression des Event ID 3 (connexions réseau) pour les processus de la liste blanche. Réduction du volume réseau Sysmon de 78 %.
4. Activation des rapports MDM Intune : rapport de conformité exporté toutes les 4 heures via Graph API vers le SIEM. Volume ajouté : négligeable (~2 Mo/jour).
5. Calibration des seuils d'alerte : seuil d'alerte 4625 ajusté à 8 échecs en 5 minutes (le seuil initial de 3 générait des faux positifs sur les comptes de service qui se reconnectent après rotation de mot de passe).
6. Test de détection : simulation d'un accès LSASS via un compte de test (outil Mimikatz en environnement isolé). Vérification que l'alerte P1 remonte en moins de 4 minutes au MSP.

Résultats après 60 jours

• Volume ingéré : ~480 Mo/jour (−88 %)
• Coût SIEM mensuel : CHF 95 (−85 %)
• Alertes par mois : 187, dont 12 % de faux positifs
• Temps analyste sur faux positifs : 2,5 heures/mois
• Deux vrais positifs détectés : un mouvement latéral avorté (SMB vers un poste non-serveur) et une tentative d'installation d'un profil macOS non signé sur un MacBook de stagiaire

L'économie annuelle sur le seul poste SIEM dépasse CHF 6 300, sans compter les heures analyste récupérées. Le NCSC recommande aux PME suisses de signaler tout incident de sécurité avéré, ce que le bureau a pu faire correctement lors du second incident grâce à des logs exploitables et complets sur la période concernée.

Récapitulatif opérationnel

• Appliquer le CIS Benchmark niveau 1 comme baseline d'audit avant d'activer quoi que ce soit de plus. Sur Windows, cela signifie activer 8 catégories d'audit, pas 43.
• Filtrer à la source (agent/forwarder), pas au SIEM. Les Event IDs à fort volume et faible valeur (4624 sur comptes de service, 7036 sur services stables) doivent être supprimés avant transmission.
• Définir trois niveaux de priorité (P1/P2/P3) avec des SLA écrits dans le contrat MSP ou la charte SOC interne. Sans SLA, tout est urgent, donc rien ne l'est.
• Intégrer l'état MDM comme signal de premier niveau : un device hors conformité est une anomalie de sécurité, pas seulement un problème IT. Il doit apparaître dans le tableau de bord SOC.
• Utiliser osquery/FleetDM pour les états macOS plutôt que le streaming des Unified Logs complets. Interrogations planifiées toutes les 300 à 3 600 secondes selon la criticité du signal.
• Documenter la rétention des logs dans le registre des activités de traitement (nLPD, art. 12). 90 jours P1/P2, 30 jours P3 : défendable et proportionné.
• Tester les règles de détection sur les vrais positifs attendus (simulation LSASS, désactivation AV) au moins une fois par trimestre. Une règle non testée est une règle non fonctionnelle.
• Revoir le périmètre de collecte à chaque changement de parc significatif (nouveau type de device, nouveau site, acquisition). La configuration de télémétrie d'il y a 18 mois n'est pas forcément adaptée au parc actuel.

La configuration de la télémétrie endpoint est un levier de performance SOC autant que de maîtrise des coûts. SynGuard accompagne les équipes IT romandes dans la mise en place de ces pipelines de collecte calibrés, de l'inventaire initial jusqu'aux règles de détection validées.

Sources

• CIS Benchmarks — Center for Internet Security — Référentiels de configuration sécurisée par OS et version, niveaux 1 et 2.
• NIST Cybersecurity Framework — NIST — Cadre de gestion du risque cyber structuré en cinq fonctions (Identify, Protect, Detect, Respond, Recover).
• Nouvelle loi fédérale sur la protection des données (nLPD) — Fedlex — Texte consolidé en vigueur depuis le 01.09.2023, notamment art. 6 (principes de traitement) et art. 12 (registre des activités).
• NCSC — Informations pour les entreprises — Recommandations officielles suisses pour la cybersécurité des PME, procédures de signalement d'incidents.