SOC : fonctionnement et rôle opérationnel

Un SOC, ou Security Operations Center, est une cellule opérationnelle chargée de surveiller, détecter et répondre aux incidents de sécurité sur un système d'information. Son fonctionnement repose sur un rôle permanent : les analystes opèrent en continu, généralement selon un modèle 24/7 organisé en niveaux de maturité (L1, L2, L3). Le SOC centralise les événements de sécurité issus de l'ensemble du parc informatique via un SIEM (Security Information and Event Management). Il corrèle les logs provenant des endpoints, des firewalls, des proxies et des annuaires. Chaque alerte est qualifiée, triée, puis escaladée selon sa criticité. Le SOC ne se limite pas à la réaction : il intègre progressivement des capacités proactives comme le threat hunting ou la CTI (Cyber Threat Intelligence). Sa couverture s'étend aux environnements cloud, OT et aux identités. L'efficacité d'un SOC dépend directement de la qualité des règles de détection, du tuning des alertes et de la réduction des faux positifs. Un SOC mature s'appuie sur des playbooks standardisés et des intégrations SOAR pour automatiser une partie des réponses de premier niveau.

Côté Blue Team, la détection au sein du SOC repose sur plusieurs couches complémentaires. Le SIEM agrège les logs Windows (Event ID 4624, 4625, 4688, 4698, 4720), les journaux réseau (NetFlow, DNS, proxy) et les alertes EDR. Les règles de corrélation permettent de détecter des chaînes d'attaque : par exemple, un Event ID 4688 lié à l'exécution de PowerShell encodé suivi d'un 4698 (création de tâche planifiée) constitue un signal fort. Les outils comme Elastic SIEM, Splunk, Microsoft Sentinel ou QRadar permettent de construire des tableaux de bord orientés MITRE ATT&CK. Les indicateurs de compromission (IoC) sont intégrés via des flux de threat intelligence (MISP, OpenCTI). Le triage L1 s'appuie sur des règles de priorité basées sur la criticité des assets touchés. La détection comportementale (UEBA) complète l'analyse signature en identifiant les anomalies sur les comptes et les mouvements latéraux. L'audit régulier de la couverture de détection via des Purple Team exercises permet de mesurer les angles morts. Les métriques clés suivies sont le MTTD (Mean Time To Detect) et le MTTR (Mean Time To Respond).

Du côté Red Team, comprendre le fonctionnement d'un SOC permet d'adapter les techniques d'évasion et de tester sa résilience. Les opérateurs offensifs cherchent à rester sous les seuils de détection : faible volume de requêtes DNS, utilisation de Living Off The Land Binaries (LOLBins) comme certutil ou mshta, timestomping des artefacts disque. Les frameworks C2 modernes (Cobalt Strike, Brute Ratel, Havoc) intègrent des profils Malleable destinés à imiter du trafic légitime pour contourner les règles SIEM. Côté contre-mesures et durcissement, le SOC doit réduire sa surface d'attaque interne : cloisonnement des consoles SIEM, MFA sur les accès aux outils d'analyse, journalisation des actions des analystes. Le tuning continu des règles est critique : une règle mal calibrée génère des faux positifs qui épuisent les équipes. Les Purple Team exercises (avec des outils comme Atomic Red Team ou Caldera) permettent de valider en conditions réelles la capacité de détection face à des TTPs issus du framework MITRE ATT&CK. Enfin, l'intégration d'un SOAR (Palo Alto XSOAR, Shuffle) automatise les réponses répétitives et réduit le délai de confinement lors d'incidents avérés.