SOC et SIEM : construire une détection d’incidents utile
Un SIEM reçoit et met en relation des événements ; un SOC est l’organisation humaine qui examine les signaux, décide de leur gravité et coordonne la réponse. Les deux termes ne garantissent ni une surveillance permanente ni la découverte de toutes les intrusions. Une petite organisation peut commencer par quelques sources de logs bien choisies et une astreinte claire ; une grande organisation peut disposer d’un SIEM coûteux sans personne capable d’enquêter la nuit. L’objectif est de détecter assez tôt les incidents qui comptent pour les services et les personnes concernées.
Ce guide propose une méthode de dimensionnement et de vérification. Il distingue les recommandations de l’ANSSI, les exigences générales de sécurité comme l’article 32 du RGPD, et la directive européenne NIS 2. Au 27 septembre 2026, l’ANSSI présente toujours la transposition française comme un processus en cours et le ReCyF comme un document de travail. Il serait donc inexact de déduire de NIS 2 un SOC français obligatoire 24 heures sur 24 pour toutes les organisations ou un outil SIEM nommé par la loi.
1. Définir la mission avant l’outil
La première question est : quels événements doivent provoquer quelle décision ? Une tentative de connexion isolée, une prise de contrôle d’un compte d’administration, une extraction massive de dossiers et une panne de sauvegarde ne demandent pas la même réaction. Classez les services par impact avec la cartographie SI et l’analyse EBIOS Risk Manager si le contexte le justifie. Associez aux scénarios un délai acceptable de détection et une personne habilitée à agir. Sans ce lien, une liste de « 20 cas d’usage SIEM » devient un catalogue sans priorité.
Exemple hypothétique : une PME dépend d’un annuaire Microsoft et d’une plateforme client. Elle choisit d’abord les créations de comptes privilégiés, les connexions d’administration inhabituelles et les modifications de sauvegarde. Une université traitant des dossiers étudiants pourrait ajouter les exports massifs et l’usage anormal de comptes de service. Dans les deux cas, le responsable de chaque alerte sait qui contacter et quelles actions sont autorisées. Cette préparation vaut davantage que le simple achat d’une licence.
Décrivez le périmètre : postes, annuaires, services cloud, pare-feu, applications métier, sauvegardes et prestataires. Un équipement non journalisé est un angle mort connu, pas une preuve que rien ne s’y produit. Consignez aussi les systèmes où la collecte est impossible, les raisons et les contrôles de remplacement. Revoyez ce périmètre après chaque projet technique et changement de fournisseur.
2. Collecter des journaux fiables
Le guide de journalisation situe les choix de collecte dans une architecture plus large. L’ANSSI explique la journalisation Windows et AD : choix des événements locaux, collecte centralisée et protection de l’infrastructure de collecte. La valeur d’un journal dépend de l’heure, de l’identifiant, du contexte et de son intégrité. Synchronisez les horloges, documentez les fuseaux et vérifiez que les événements attendus arrivent réellement. Une règle de détection ne fonctionne pas si la machine ne transmet plus ses logs depuis trois semaines.
Les journaux peuvent eux-mêmes contenir des données personnelles : identifiants, adresses IP, activités professionnelles, parfois URL ou contenus sensibles. Limitez les champs à ce qui sert l’enquête, restreignez l’accès des analystes, définissez une conservation motivée et protégez les exportations vers un prestataire. Le SIEM ne doit pas devenir une archive indéfinie de l’activité individuelle. Reliez les durées à la menace et aux besoins de preuve, sans transformer une pratique technique en durée légale universelle.
La collecte doit résister à la compromission du système surveillé. Un attaquant doté de privilèges peut effacer des journaux locaux ; centralisation, droits séparés et surveillance de l’arrêt des agents réduisent ce risque. Vérifiez la possibilité de restaurer les traces et de les exploiter après une attaque. Une piste d’audit n’est probante que si ses accès et modifications sont eux-mêmes maîtrisés.
3. Concevoir quelques détections vérifiables
Une bonne règle précise le comportement recherché, les données nécessaires, les exceptions légitimes, le seuil de déclenchement et l’action attendue. Par exemple, la création d’un administrateur de domaine hors procédure peut produire une alerte prioritaire ; elle doit distinguer une intervention planifiée d’un compte inconnu. Une « connexion depuis deux pays » n’est qu’un indice, car les VPN et proxys changent l’emplacement apparent. Les alertes efficaces combinent identité, actif, heure, provenance et historique.
Pour un système de fichiers, une lecture inhabituelle de nombreux dossiers n’est pas automatiquement une fuite : sauvegarde et migration peuvent produire le même motif. Le SOC doit disposer de la liste des opérations planifiées et d’un moyen d’interroger le propriétaire métier. Le scénario d’exfiltration exige une chaîne de preuves plus large : accès, volume, destination, identité et éventuel canal externe. Conservez un exemple de cas positif et un exemple de faux positif pour régler la règle.
MITRE ATT&CK peut servir à décrire les techniques que l’on veut observer et à repérer des lacunes. Il n’impose pas de couvrir un pourcentage universel de techniques : toutes ne concernent pas un environnement donné, et une règle « présente » peut être inefficace. Testez les comportements pertinents avec des simulations contrôlées et mesurez si l’alerte a été reçue, comprise et traitée. L’audit RGPD peut relier cette vérification à la protection des données personnelles.
4. Organiser triage, enquête et escalade
Le SOC doit distinguer événement, alerte, incident de sécurité et violation de données personnelles. Le premier peut être banal ; le dernier exige une analyse juridique et une procédure de notification. Écrivez les critères de gravité et les seuils d’escalade avec RSSI, DPO, exploitation et métiers. Les analystes doivent pouvoir préserver des preuves sans couper un service vital par erreur. Précisez à l’avance les actions qu’ils peuvent faire seuls et celles qui nécessitent une approbation.
Les étiquettes L1, L2 ou L3 ne décrivent pas à elles seules une qualité de service. Une organisation de petite taille peut avoir un analyste polyvalent et un spécialiste mobilisable. Pour une couverture hors horaires, déterminez qui lit les alertes, sous quel délai, avec quel accès et quelle astreinte métier. Un fournisseur qui surveille « 24/7 » mais n’a pas le droit d’isoler un poste ni de joindre la personne de garde offre une couverture limitée. Testez un appel de nuit, la disponibilité des coordonnées et la prise de décision.
Exemple hypothétique : une alerte signale une désactivation de l’EDR sur un serveur de facturation. Le premier analyste vérifie l’identité du serveur et l’existence d’une maintenance. Sans justification, il préserve les logs, prévient l’astreinte et demande la décision d’isolement. Le DPO n’est saisi pour une violation de données que si des faits suggèrent une atteinte à leur confidentialité, intégrité ou disponibilité. Un playbook doit permettre cette distinction, pas notifier automatiquement chaque alerte à la CNIL.
5. Comparer une exploitation interne et un prestataire
Un SOC interne offre une proximité avec les applications et les métiers ; il demande recrutement, permanence, expertise et maintenance de la plateforme. Un prestataire de détection peut accélérer la mise en place, mais dépend de la qualité des données qui lui sont fournies et des pouvoirs d’action contractuels. Comparez le périmètre des sources, les heures de surveillance, les délais de qualification, l’accès aux preuves, l’escalade, la localisation des données et les conditions de sortie. Un prix par poste ou par gigaoctet ne décrit pas le coût complet de l’enquête ni de la conservation.
L’ANSSI distingue les prestataires de détection d’incidents de sécurité et les prestataires de réponse aux incidents. Une qualification PDIS porte sur un service et un périmètre définis ; elle ne rend pas automatiquement qualifiées toutes les offres d’une société. Vérifiez la liste et le champ du certificat en vigueur pour le service acheté. Une obligation d’utiliser un prestataire qualifié doit provenir d’un régime applicable ou d’un contrat précis ; il serait trompeur de l’imputer à toutes les entités visées potentiellement par NIS 2.
Dans le contrat, précisez la propriété des journaux, les accès du fournisseur, les sous-traitants, le temps de mise à disposition des preuves, les conditions de suspension et la réversibilité. Le client conserve le besoin de décider pour ses systèmes et ses notifications. Testez l’extraction d’un dossier d’incident et la migration des règles avant d’être captif d’une plateforme.
6. Automatiser prudemment
Un outil SOAR peut enrichir une alerte, ouvrir un ticket ou demander une validation. L’isolement automatique d’un poste ou la désactivation d’un compte est plus risqué lorsqu’il s’agit d’un poste de soins, d’une identité de service ou d’un système de production. Classez les actions par réversibilité et impact. Commencez par l’enrichissement et les actions à faible risque, puis autorisez l’automatisation technique à partir de simulations et de droits limités.
Le fournisseur de renseignement sur les menaces peut aider à contextualiser une adresse ou une vulnérabilité, mais une correspondance avec un indicateur ancien n’est pas une preuve d’attaque. Vérifiez la source, la date et la pertinence dans votre environnement. Une règle qui génère trop de faux positifs épuise l’équipe ; une règle trop restrictive laisse passer l’événement. Suivez ces deux défauts séparément.
7. Mesurer ce qui améliore la réaction
Mesurez la couverture des actifs critiques, la fraîcheur des journaux, les alertes examinées, le délai entre événement et prise en charge, et les incidents où la procédure a effectivement fonctionné. Les valeurs cibles dépendent de l’activité ; annoncer « une heure pour tout incident critique » sans permanence et sans définition d’incident ne sert à rien. Pour chaque incident réel ou exercice, reconstituez la chronologie : source d’alerte, analyste, escalade, décision, confinement et restauration.
Le durcissement Windows et Linux réduit certaines possibilités d’attaque, tandis que les sauvegardes soutiennent la reprise. Le SOC relie les signes d’une attaque à une décision. Aucun de ces trois travaux ne compense entièrement l’absence des autres. Dans une revue de gestion de crise cyber, vérifiez que les rôles et les preuves passent bien de la détection à la réponse, puis aux obligations de communication.
8. Tester la chaîne par un exercice
Un exercice de détection donne une preuve plus forte qu’un tableau de règles activées. Définissez un scénario autorisé avec l’équipe d’exploitation : création d’un compte privilégié de test, connexion depuis un poste d’administration inhabituel ou arrêt volontaire d’un agent de collecte. Annoncez les limites de l’exercice à un petit cercle pour éviter une interruption accidentelle, puis observez si le signal atteint la bonne personne sans aide extérieure. Notez l’heure de l’action, celle de l’alerte, la qualification et les décisions prises.
Répétez ensuite l’exercice avec une défaillance : collecteur indisponible, compte d’astreinte absent ou journaux retardés. La question devient « comment sait-on que l’on ne voit plus ? ». Un contrôle de santé de la collecte et un canal d’escalade de secours peuvent révéler le problème avant l’attaque réelle. Documentez les écarts et le responsable de correction. Le résultat ne doit pas servir à blâmer un analyste ; il sert à rendre la procédure praticable.
Pour une organisation ayant plusieurs filiales, testez le transfert de contexte entre les équipes locales et le prestataire central. Un identifiant d’actif qui n’existe que dans un pays ou un fuseau horaire mal interprété peut retarder l’enquête. Le contrat doit permettre l’accès rapide aux journaux et l’usage des coordonnées à jour. Cet exercice vérifie ensemble architecture, responsabilités et disponibilité humaine.
9. Faire évoluer les cas d’usage
Après une nouvelle application, un changement d’annuaire ou une migration cloud, réévaluez les signaux disponibles et les alertes. Un prestataire doit annoncer les sources devenues muettes et les règles qu’il a modifiées. L’organisation doit répondre aux écarts, pas seulement recevoir un tableau de bord. Une revue courte et régulière avec exploitation, sécurité et DPO permet de retirer les règles inutiles, d’ajouter les scénarios nouveaux et de réduire la collecte excessive.
La preuve d’une détection utile est une enquête reproductible : le signal existe, sa cause peut être vérifiée, une personne responsable agit et les décisions sont conservées. Un outil peut faciliter cette chaîne ; il ne la crée pas à lui seul.