SOC managé : définir le service avant de choisir les outils
Périmètre, horaires, escalade et critères de réception : les questions à clarifier pour cadrer un service de SOC managé réellement exploitable.
Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.
Un projet de SOC managé commence souvent par une liste de technologies : collecte des journaux, détection, tableaux de bord, réponse automatisée.
Pourtant, une question mérite de précéder cette liste : que doit-il se passer lorsqu’un signal inquiétant apparaît sur un système important pour l’entreprise ?
Le fait documenté : le NIST SP 800-61 révision 3, publié en avril 2025, inscrit la réponse aux incidents dans la gestion globale du risque cyber. Cette approche fournit un cadre utile pour réfléchir au service.
Les propositions ci-dessous constituent notre méthode de cadrage, à adapter aux responsabilités et contraintes de chaque organisation. Source : NIST
Partir de situations concrètes
Prenez trois situations représentatives : une activité inhabituelle sur un compte privilégié, un équipement critique qui cesse d’émettre ses journaux et une suspicion de compromission pendant une période de faible présence interne.
Pour chacune, décrivez les données disponibles, le travail attendu du SOC et la décision qui reste à prendre côté client.
Cet exercice fait apparaître les limites du service plus clairement qu’une longue liste de fonctionnalités. Une détection peut être techniquement possible sans que les informations métier nécessaires à son interprétation soient accessibles.
Une équipe peut aussi être joignable sans disposer du mandat requis pour intervenir.
Définir des engagements observables
Nous recommandons de documenter le périmètre surveillé, les plages de fonctionnement, les niveaux de priorité et les canaux d’escalade. Chaque délai doit avoir un point de départ explicite : réception d’un événement, création d’une alerte, qualification ou notification.
Ces étapes ne mesurent pas la même chose.
Précisez également ce qui suspend ou limite le service : source indisponible, accès retiré, contact injoignable ou nouvel actif non intégré. Les exclusions doivent être compréhensibles pour les équipes opérationnelles, et visibles dans le suivi du service.
Organiser la réception et les changements
Avant le démarrage, choisissez quelques tests de réception autorisés : retrouver un événement attendu, vérifier son contexte, déclencher une notification de test et confirmer sa réception. Conservez le résultat et les éventuelles réserves.
Après le démarrage, toute évolution importante doit pouvoir modifier le périmètre : acquisition d’une filiale, migration cloud, nouvelle application ou changement de prestataire. Prévoyez qui signale ces changements et qui vérifie leur prise en compte.
Pour préparer un échange avec Seculogik, rassemblez vos actifs prioritaires, vos contacts d’escalade et les décisions que vous souhaitez déléguer. Ce socle permet de discuter d’un service mesurable sans présumer des capacités, horaires ou engagements qui seront effectivement convenus.