SOC hybride : architecture et opérations

Un SOC hybride est un centre opérationnel de sécurité qui combine des capacités internes à l'organisation avec des services externalisés auprès d'un ou plusieurs prestataires MSSP ou MDR. Le SOC hybride repose sur un partage explicite des responsabilités : les analystes internes conservent la maîtrise du contexte métier et des actifs critiques, tandis que le prestataire externe assure la couverture horaire étendue, la corrélation de threat intelligence et le traitement volumétrique des alertes de bas niveau. Cette architecture répond à une contrainte réelle : les équipes SOC internes manquent souvent de ressources pour couvrir un périmètre 24h/24, 7j/7. Le modèle hybride introduit en revanche une complexité opérationnelle propre. Il exige une définition précise des runbooks partagés, des niveaux de triage (L1/L2/L3) attribués à chaque entité, des SLA d'escalade contractualisés, et une visibilité symétrique sur le SIEM. La segmentation des droits d'accès au SIEM entre équipe interne et MSSP constitue un point d'attention majeur : un accès trop large au prestataire expose des données métier sensibles. Le SOC hybride est particulièrement pertinent dans les secteurs régulés où la souveraineté des données impose de garder certains flux de logs en interne, tout en bénéficiant d'une capacité de détection mutualisée.

La détection dans un SOC hybride soulève des défis spécifiques liés à la dualité des équipes. Le premier risque est le trou de couverture entre le transfert de shift interne et l'équipe MSSP : une alerte ouverte sans prise en charge claire peut rester sans réponse. Pour l'éviter, chaque ticket d'incident doit porter un propriétaire horodaté et une trace d'escalade lisible dans l'outil ITSM ou XDR partagé. Côté télémétrie, les événements Windows critiques à surveiller incluent les ID 4625 (échec d'authentification), 4720 (création de compte), 4688 (création de processus avec ligne de commande), et 7045 (installation de service). Ces événements doivent être ingérés dans le SIEM commun avec une normalisation identique côté interne et côté MSSP, sous peine de règles de corrélation incohérentes. Les indicateurs de compromission (IOC) partagés via STIX/TAXII doivent être synchronisés entre la plateforme de threat intelligence interne et celle du prestataire. Un delta de synchronisation supérieur à quelques heures annule l'avantage de la mutualisation. La couverture des assets cloud (AWS CloudTrail, Azure Activity Logs) doit être contractuellement assignée à l'une des deux entités pour éviter les angles morts.

Du point de vue Red Team, le SOC hybride présente une surface d'attaque élargie par rapport à un SOC purement interne. La frontière entre le réseau de l'organisation et les accès du MSSP constitue un vecteur privilégié. Un attaquant ayant compromis un compte de service utilisé par le prestataire pour ingérer les logs peut potentiellement accéder au SIEM et manipuler la visibilité défensive, en supprimant des règles de détection ou en injectant de faux positifs pour noyer les analystes. Les tests de Red Team sur un SOC hybride doivent valider explicitement la détection cross-entité : une activité simulée de mouvement latéral doit générer une alerte chez l'équipe interne ET chez le MSSP dans les délais SLA définis. Côté durcissement, les accès du prestataire au SIEM doivent être limités en lecture seule sur les logs bruts, sans droit de modification des règles de corrélation. Les connexions VPN ou API du MSSP doivent passer par une zone démilitarisée dédiée. Le principe du moindre privilège s'applique aux comptes de service MSSP avec rotation régulière des secrets. Enfin, un exercice de table-top trimestriel impliquant les deux équipes est indispensable pour tester les procédures d'escalade et identifier les dépendances opérationnelles non documentées.