SOC et responsabilités partagées : attribuer chaque décision avant l’incident
Client, SOC, infogérant et fournisseur cloud : clarifiez qui observe, décide, agit et vérifie pour limiter les zones grises pendant un incident.
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.
Une alerte peut mobiliser un SOC, une équipe informatique interne, un infogérant et un fournisseur cloud. Chacun dispose d’une partie des informations ou des moyens d’action.
Pour éviter qu’une décision reste sans propriétaire, leurs responsabilités doivent être décrites à partir de situations concrètes.
Le fait documenté : AWS présente la sécurité du cloud comme une responsabilité partagée entre le fournisseur et le client, avec une répartition qui dépend notamment des services utilisés.
Ce modèle ne définit pas automatiquement le rôle d’un SOC ou d’un infogérant ajouté au dispositif. Source : AWS
Partir d’un scénario complet
Notre recommandation : choisir un incident plausible, puis suivre son traitement depuis le premier signal jusqu’au retour à un fonctionnement acceptable. Pour chaque étape, identifiez qui reçoit l’information, qui peut la vérifier, qui prend la décision et qui réalise l’action.
Prenez le scénario d’un compte suspect. Le SOC peut contribuer à l’analyse, tandis qu’un administrateur possède les moyens de suspendre l’accès et qu’un responsable métier connaît les conséquences d’une interruption.
Cette répartition est illustrative : elle doit être confirmée selon votre organisation et les délégations convenues.
Rendre les dépendances visibles
Une matrice de responsabilités doit préciser les prérequis : accès, contacts, disponibilité et informations nécessaires. Attribuer une tâche à une équipe ne lui donne pas automatiquement les droits ou les données requis pour l’exécuter.
Documentez aussi les désaccords possibles. Qui arbitre lorsqu’une mesure de confinement menace un service essentiel ? Qui décide qu’un rétablissement peut commencer ? Les critères et les suppléants doivent être discutés avant qu’une situation urgente impose une réponse.
Vérifier la continuité et la clôture
Prévoyez le fonctionnement lorsque l’interlocuteur habituel est absent ou lorsqu’un prestataire devient indisponible. Testez les coordonnées et les chemins d’escalade dans un exercice annoncé. Conservez les blocages rencontrés et attribuez leur correction.
La responsabilité doit aller jusqu’à la vérification du résultat. Après une modification, indiquez qui contrôle son effet et qui confirme que la surveillance fonctionne encore.
La clôture d’un ticket peut laisser des travaux de fond ouverts ; ceux-ci doivent avoir un propriétaire distinct et un suivi visible.
Pour cadrer les responsabilités avec Seculogik, réunissez les acteurs capables d’autoriser et de réaliser les actions importantes. Une discussion centrée sur quelques scénarios produit une répartition utilisable.
Elle permettra ensuite de préciser les engagements du service, sans supposer qu’un outil ou un prestataire prend en charge toutes les décisions.