Un prestataire gère la supervision de votre système d’information depuis son SVC Center. Ses analystes utilisent des outils dopés à l’intelligence artificielle pour trier les alertes et orchestrer les réponses. Que se passe-t-il si c’est ce centre de supervision lui-même qui est compromis ?
Avec l’entrée en application de NIS2 et la publication du référentiel ReCyF par l’ANSSI le 17 mars 2026, la question n’est plus théorique : on doit traiter le SOC externalisé comme une surface d’attaque à part entière.
Quand le SVC Center externalisé devient une cible directe
On confie à un SVC Center la visibilité sur l’ensemble de nos flux réseau, nos journaux d’événements, parfois nos comptes à privilèges. Ce niveau d’accès en fait une cible de choix pour un attaquant qui cherche à remonter la chaîne d’approvisionnement.
Le scénario concret : un opérateur du centre utilise un poste mal segmenté. L’attaquant compromet ce poste, accède à la console de supervision, puis désactive ou modifie les règles de détection. L’entreprise cliente ne voit plus rien, et l’attaquant opère librement sur son périmètre.
Un SOC compromis ne génère pas d’alerte, il les supprime. C’est la raison pour laquelle les obligations NIS2 portent désormais explicitement sur la sécurité de la chaîne d’approvisionnement et des tiers. Le SOC externalisé entre dans cette catégorie, et son encadrement contractuel et technique doit suivre.
Obligations NIS2 et référentiel ReCyF : ce que le SOC doit prouver
NIS2 ne se contente pas de demander aux organisations de surveiller leurs systèmes. La directive impose de documenter la gestion des risques liés aux prestataires de services de sécurité, y compris les centres de supervision externalisés.
Le référentiel ReCyF de l’ANSSI, publié comme déclinaison opérationnelle de NIS2 pour les entités françaises, précise les objectifs de sécurité que le SOC doit mettre en place. On parle de traçabilité des actions des analystes, de cloisonnement des environnements, de protection des données collectées.
Points de contrôle à exiger de votre prestataire SVC Center
- Isolation réseau stricte entre les environnements clients : chaque périmètre supervisé doit être segmenté pour éviter qu’une compromission ne se propage d’un client à l’autre
- Journalisation des actions des opérateurs du SOC eux-mêmes, avec envoi des logs vers un système que le prestataire ne contrôle pas seul (co-détention ou copie chez le client)
- Revue régulière des comptes à privilèges utilisés par le centre, avec rotation des secrets et authentification multifacteur sur chaque accès aux consoles de supervision
- Clause contractuelle de notification en cas d’incident affectant l’infrastructure du SOC, avec un délai aligné sur les exigences NIS2
Si votre prestataire ne peut pas répondre précisément à ces points, le risque ne diminue pas en externalisant, il se déplace.
Intelligence artificielle dans le SOC : isoler l’outil pour ne pas créer de faille
Les approches SOC récentes intègrent massivement l’IA pour le tri des alertes, la corrélation d’événements et la suggestion de réponses. Sur le terrain, on constate que cette automatisation accélère le traitement, mais elle introduit un risque spécifique que peu de prestataires documentent.
Le problème identifié : une IA qui ingère des journaux ou des tickets peut être manipulée par injection. Un attaquant insère une instruction malveillante dans un champ de log. L’IA la traite comme une donnée légitime et exécute ou suggère une action qui affaiblit la posture de sécurité.
Précautions opérationnelles face à l’IA dans un SVC Center
Les recommandations documentées sur ce sujet convergent vers trois mesures concrètes. L’environnement d’exécution de l’IA doit être isolé du reste de l’infrastructure de supervision. Aucune action privilégiée (blocage d’un compte, modification d’une règle firewall) ne doit être déclenchée directement par l’IA sans validation humaine. Les données injectées dans le modèle doivent être filtrées et normalisées avant traitement.
On ne demande pas à un SVC Center de renoncer à l’IA. On lui demande de traiter l’IA comme un outil non fiable par défaut, ce qui est la posture standard pour tout composant exposé à des entrées externes.
Cybersécurité du SVC Center : construire un plan de contrôle côté client
Externaliser la supervision ne signifie pas externaliser la responsabilité. Les retours varient sur la profondeur de contrôle réellement exercée par les entreprises clientes, mais un socle minimal existe.
La première action consiste à cartographier les accès du SVC Center à votre système d’information. Quels comptes sont utilisés ? Quels segments réseau sont visibles ? Quelles données sortent de votre périmètre pour alimenter la plateforme de supervision ?
Ensuite, on met en place un mécanisme de vérification indépendant. Un test d’intrusion annuel incluant le périmètre du prestataire SOC permet de valider que les mesures de cloisonnement fonctionnent réellement. Certains organismes recommandent aussi des exercices de type red team ciblant spécifiquement la chaîne de supervision.
- Exiger un rapport mensuel détaillant les incidents traités, les faux positifs écartés et les modifications apportées aux règles de détection
- Vérifier que le prestataire dispose d’un plan de continuité propre : si son infrastructure tombe, votre capacité de détection ne doit pas disparaître avec elle
- Intégrer dans le contrat une clause d’audit permettant d’inspecter les pratiques de gestion des données et la configuration des outils de protection du centre
Le référentiel ReCyF fournit un cadre pour structurer ces exigences. L’utiliser comme grille de lecture lors du renouvellement de contrat avec un prestataire SVC Center évite de partir d’une page blanche.
La tendance à empiler les couches de protection logicielle dans un SOC masque parfois l’absence de contrôles organisationnels simples. Un centre de supervision qui surveille vos systèmes informatiques mais dont personne ne surveille les pratiques internes reste un point de défaillance unique déguisé en solution de sécurité. Documenter, auditer, cloisonner : ces trois verbes résument l’approche qui tient face aux contraintes réglementaires actuelles et aux risques concrets que pose un SOC externalisé.
