Onboarding SOC : les critères qui prouvent qu’une source est prête
Une source connectée doit aussi être exploitable. Voici comment définir une réception SOC fondée sur les événements, le contexte et les tests.
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.
L’installation d’un connecteur constitue une étape d’intégration. Pour décider qu’une source peut contribuer à la surveillance, il faut aussi vérifier ce qu’elle transmet et ce que l’équipe peut en faire.
Un onboarding SOC gagne donc à se terminer par une réception documentée.
Le fait documenté : Microsoft propose pour Sentinel des fonctions de suivi de la santé des connecteurs, notamment un classeur de supervision et la table SentinelHealth. La documentation précise que cette table concerne certains connecteurs pris en charge.
Elle ne permet donc pas de supposer une couverture identique pour toutes les sources. Source : Microsoft Learn
Décrire ce qui doit arriver
Notre recommandation : préparer une fiche par source avec son propriétaire, son environnement, les catégories d’événements attendues et leur usage. Pour un fournisseur d’identité, on pourra rechercher des traces d’authentification et de modification de privilèges.
Pour une application métier, les besoins pourront porter sur les opérations administratives.
Ajoutez les champs indispensables à l’interprétation : heure, identité, objet concerné, résultat et origine lorsque ces informations existent. Une donnée absente ne doit pas être remplacée par une supposition. Notez la limite et les scénarios qu’elle affecte.
Tester toute la chaîne
Choisissez une action bénigne, autorisée et identifiable. Vérifiez successivement sa présence dans la source, sa réception dans la plateforme, son interprétation et sa disponibilité pour les recherches prévues. Notez les horaires observés plutôt que de déclarer un délai théorique.
Lorsque la source alimente une détection, testez aussi la création de l’alerte et son acheminement vers le bon destinataire. Un test d’ingestion réussi ne valide pas à lui seul une notification, une règle ou une procédure d’escalade.
Préparer les situations dégradées
L’onboarding doit préciser comment détecter une interruption de collecte. Le mécanisme pourra utiliser un indicateur de santé, le dernier événement reçu ou une autre méthode adaptée au fonctionnement de la source.
Un système peu actif exige une interprétation différente d’un service qui émet continuellement.
Documentez enfin les dépendances : permissions, certificat, compte technique, quotas, réseau et interlocuteur chargé de la maintenance. Associez les exceptions restantes à un responsable et à une prochaine décision.
La réception peut prendre la forme d’une page concise : tests passés, limites connues, éléments manquants et périmètre accepté. Pour cadrer un onboarding avec Seculogik, cette page sert de support commun.
Elle rend visible ce qui fonctionne déjà et ce qui doit encore être vérifié avant de s’appuyer sur la source.