Introduction générale

1. Pourquoi la technologie seule ne suffit pas

Le SOC est souvent perçu, à tort, comme un ensemble d’outils technologiques sophistiqués capables de détecter, corréler, et neutraliser des menaces informatiques. SIEM, EDR, SOAR, sondes, sandbox, TIP (Threat Intelligence Platform)… ces acronymes prennent une place prépondérante dans les représentations mentales des responsables sécurité, des RSSI et même du grand public informé. Pourtant, au cœur de toute cette architecture numérique, réside un facteur essentiel, souvent sous-estimé : l’humain.

a. Les machines ne remplacent pas la prise de décision

Même les outils de sécurité les plus avancés nécessitent un pilotage stratégique et tactique. Les décisions critiques (escalade d’un incident, acceptation d’un risque, déclenchement d’une réponse automatique ou investigation plus poussée) ne peuvent être prises que par des humains, formés, compétents, capables d’interpréter des signaux faibles dans un contexte métier.

L’intelligence artificielle, aussi performante soit-elle dans certaines tâches, reste dépendante de l’humain pour la supervision, la validation, le paramétrage, l’ajustement et la compréhension des dynamiques d’attaque complexes. Un analyste chevronné remarquera parfois en quelques minutes un détail qu’aucun moteur d’analyse automatisée n’aurait su corréler, tout simplement parce que ce détail sort du cadre des règles établies.

b. L’humain, moteur d’adaptation face à l’imprévu

Les attaques informatiques évoluent sans cesse. De nouvelles vulnérabilités apparaissent chaque semaine, des campagnes malveillantes émergent sans prévenir, et des techniques d’évasion toujours plus sophistiquées sont déployées par les groupes APT (Advanced Persistent Threats). Dans ce contexte, l’humain reste le seul capable de s’adapter à des situations inédites, de créer des contournements tactiques, d’explorer des pistes non conventionnelles.

Un SOC peut disposer...

Les analystes SOC : L1, L2, L3

Le fonctionnement opérationnel quotidien d’un SOC repose avant tout sur le travail des analystes de sécurité. Ces professionnels constituent la première ligne de défense face aux menaces informatiques. Leur rôle ne se limite pas à traiter des alertes : ils analysent, décident, escaladent, documentent, et peuvent jouer un rôle pédagogique auprès des métiers ou d’autres équipes internes.

Traditionnellement, les analystes SOC sont organisés selon une logique de niveau - L1, L2, L3 (du terme anglais « Level » 1, 2, 3, parfois traduits en français par N1, N2, N3 pour « Niveau ») - reflétant la montée en expertise et en responsabilité. Toutefois, cette hiérarchie n’est pas une vérité universelle : certaines structures ont volontairement fait le choix d’un modèle plat, sans segmentation explicite. Nous explorerons dans cette section ces différents modèles, leurs avantages et leurs défis, tout en mettant en lumière les tâches et les parcours de ces analystes qui font vivre la supervision au quotidien.

1. Définition des rôles, tâches quotidiennes, périmètre

Le découpage L1, L2, L3 est inspiré de l’organisation en niveaux d’escalade que l’on retrouve aussi dans les centres de support informatique. Appliqué au SOC, il permet une répartition des tâches selon la complexité, l’urgence et la spécialisation requise.

a. Analyste L1 - la première ligne de supervision

L’analyste de niveau 1 est le guetteur en permanence sur les lignes du front. Il surveille les alertes générées par les outils de sécurité (SIEM, EDR, IDS, etc.), filtre le bruit et identifie les signaux pertinents.

Ses principales missions incluent :

la surveillance en temps réel des flux d’alertes ;
le tri initial des événements : faux positifs vs alertes légitimes ou potentielles ;
l’ouverture de tickets d’incident lorsque nécessaire ;
le renseignement initial de l’incident dans les outils de ticketing ;
l’escalade vers le niveau 2 en cas de doute...

Le CSIRT

Dans l’écosystème de la cybersécurité moderne, le CSIRT (Computer Security Incident Response Team - équipe d’intervention en cas d’incident de sécurité informatique) occupe une place singulière. Bien que le CSIRT et le SOC partagent souvent des responsabilités communes dans la gestion opérationnelle des incidents, la position exacte du CSIRT peut varier d’une organisation à l’autre. Dans certains cas, le CSIRT est une équipe dédiée au sein du SOC, chargée des incidents complexes ou sensibles. Dans d’autres contextes, le CSIRT existe comme une entité distincte, centrée sur une mission plus stratégique, avec une expertise spécialisée et une implication directe dans la gestion de crise organisationnelle. Son rôle dépasse alors la simple réaction technique à un incident : il structure la réponse, coordonne les différents acteurs internes et externes, analyse en profondeur les causes, et garantit le retour à la normale dans les meilleures conditions.

Comprendre la relation entre le SOC et le CSIRT nécessite donc d’analyser précisément leur positionnement respectif dans l’organigramme, leurs rôles selon les contextes organisationnels, ainsi que leurs modalités d’interaction.

1. Positionnement dans l’organigramme

Le positionnement du CSIRT dans l’organisation est un indicateur fort de la maturité cybersécurité d’une entreprise. Selon les structures, son rattachement, son périmètre et ses liens hiérarchiques peuvent différer considérablement, influençant ainsi son autonomie, son efficacité et sa capacité d’influence.

a. Une équipe transverse par essence

Par nature, le CSIRT intervient à la jonction de multiples départements : sécurité, systèmes d’information, direction générale, ressources humaines, juridiques, communication, etc. Cette transversalité est cruciale pour gérer efficacement les incidents complexes dépassant les seuls aspects techniques. Ainsi, le CSIRT ne doit pas être considéré comme une simple extension du SOC ou des équipes...

SOC Manager et Head of SOC

Le bon fonctionnement d’un SOC ne repose pas uniquement sur les analystes ou les outils technologiques. La gouvernance humaine joue un rôle fondamental dans la cohérence de l’ensemble. C’est ici qu’interviennent deux figures clés : le SOC Manager et le Head of SOC (ou directeur SOC). Bien que leurs responsabilités puissent se recouper dans certaines structures, il s’agit bien de deux rôles distincts, chacun avec ses priorités, son périmètre décisionnel et son niveau d’interaction avec les différentes parties prenantes.

1. Différences entre les deux rôles

a. Vision opérationnelle vs vision stratégique

Le SOC Manager est généralement la figure de référence pour tout ce qui concerne l’opérationnel quotidien du SOC. Il est responsable du bon déroulement des activités de supervision, du respect des procédures, de l’organisation des équipes d’analystes, du planning et de la performance du service. Il fait le lien entre les analystes et la direction, s’assure de la qualité de service rendue, de la gestion des escalades, et du suivi des incidents majeurs. C’est un rôle de terrain, tourné vers la réactivité, la rigueur et la gestion humaine.

Le Head of SOC, quant à lui, incarne une vision plus globale et stratégique du SOC. Il ou elle participe à la définition de la trajectoire à long terme du centre de supervision, en phase avec les orientations de la direction cybersécurité, voire de la direction générale dans certaines entreprises. Il intervient dans les décisions structurantes : budget, organisation cible, modèle de sourcing (interne vs externalisation), définition des indicateurs de pilotage, relations avec les autres entités (IT, métiers, RSSI, etc.). Il est aussi souvent impliqué dans des comités exécutifs ou dans des projets de transformation majeurs.

b. Position dans l’organigramme

Dans les grandes structures, le SOC Manager rapporte généralement au Head of SOC, qui lui-même dépend de la direction cybersécurité ou du RSSI. Le Head of SOC peut parfois superviser plusieurs entités : SOC, CSIRT...

Les équipes d’architecture

1. Choix technologiques

Derrière chaque brique technologique qui compose un SOC se cache un ensemble de décisions structurantes. Ces choix, souvent pris en amont de la mise en production des plateformes ou lors d’évolutions majeures, relèvent du travail des équipes d’architecture. Si le rôle d’un architecte est parfois perçu comme abstrait ou éloigné des opérations quotidiennes, il est pourtant central : c’est lui qui trace les lignes directrices sur lesquelles s’appuieront ensuite le reste du SOC.

Les équipes d’architecture ont une double responsabilité. D’un côté, elles doivent s’assurer que les choix techniques répondent aux exigences de sécurité, de scalabilité et de résilience. De l’autre, elles doivent garantir que ces décisions sont en adéquation avec les contraintes du terrain, qu’il s’agisse de compatibilité avec l’existant, de coûts, ou encore de maintenabilité.

a. Cartographie des besoins et vision d’ensemble

Avant toute décision d’architecture, un état des lieux précis est nécessaire. Il s’agit de comprendre les besoins métiers, les risques à couvrir, les volumes de données, les interconnexions existantes et les objectifs de supervision à moyen et long terme. Cela peut inclure :

Une analyse des flux réseau critiques à surveiller.
L’identification des types de logs les plus utiles à collecter (firewall, endpoint, authentification…).
L’évaluation des exigences en termes de rétention, d’archivage ou de redondance.
La projection du nombre d’utilisateurs et de leur usage des outils SOC.

Cette cartographie permet de définir une vision d’ensemble cohérente, évitant les empilements désordonnés de solutions et assurant une ligne directrice dans les investissements technologiques.

b. Le choix des outils centraux

L’architecte SOC intervient dans la sélection, ou la validation, des outils majeurs : SIEM, SOAR, EDR, plateformes de Threat Intelligence, systèmes de ticketing… Chaque composant doit être choisi non seulement pour ses fonctionnalités...

Les équipes d’intégration

1. Onboarding des nouveaux équipements

L’intégration des nouvelles sources de logs et des équipements constitue le socle du travail des équipes d’intégration au sein du SOC. Ces équipes jouent un rôle clé pour garantir que le SOC dispose d’une vision complète et pertinente des événements de sécurité à surveiller. Leur mission dépasse le simple branchement technique : il s’agit de comprendre les besoins métiers, d’adapter les configurations et d’anticiper les contraintes de sécurité et de performance. Cette section détaille les principaux volets de cette activité.

a. Analyse des besoins et cadrage technique

Avant toute intégration, les équipes réalisent un travail préparatoire essentiel qui inclut notamment :

Identification des besoins métiers et des cas d’usage : quelles données doivent être collectées pour répondre efficacement aux objectifs de détection, d’investigation ou de conformité ?
Définition précise des logs à collecter : quels champs sélectionner, sous quels formats ?
Définition des types de détection à implémenter : quelles règles de corrélation ou quels playbooks seront nécessaires pour exploiter ces nouvelles données ?

À cela s’ajoute une adaptation pratique des prérequis techniques : les équipes d’intégration doivent ajuster et valider sur le terrain les choix techniques réalisés en amont par les architectes (protocoles, agents, API, etc.), afin de tenir compte des contraintes réelles, parfois imprévues, rencontrées en cours de déploiement.

Cette analyse préalable permet ainsi d’éviter des déploiements précipités, incomplets ou techniquement incompatibles, facilitant l’intégration fluide et opérationnelle des nouvelles sources au sein du SOC.

b. Configuration et raccordement des sources

Une fois le cadrage validé, les intégrateurs procèdent à la configuration technique. Cela implique :

Le paramétrage des équipements...

Les équipes d’administration

1. Rôles opérationnels

Le bon fonctionnement d’un SOC ne dépend pas uniquement de la pertinence des alertes ou de leurs traitements par des analystes. Il repose sur une base technique solide, maintenue et administrée quotidiennement par des équipes dédiées, parfois peu visibles, mais indispensables. Ces équipes d’administration constituent un maillon clé de la chaîne de cybersécurité. Elles assurent la continuité de service des outils de sécurité, mais aussi la santé de l’environnement technique global sur lequel repose le SOC : réseau, systèmes, Active Directory, endpoints, serveurs, bases de données, et bien plus encore.

Contrairement à l’image classique du SOC centrée uniquement sur le SIEM et les alertes, une vision complète intègre également des couches d’infrastructure traditionnelles. Car si un domaine Active Directory tombe, que des serveurs DNS ne répondent plus, ou que les agents EDR cessent de communiquer faute de connectivité réseau, c’est l’ensemble du dispositif de sécurité qui vacille. L’administrateur est donc un garant silencieux de la résilience du SOC.

a. Administration des outils SOC et des couches fondamentales

Les équipes d’administration sont en charge de nombreux volets :

Administration des outils de cybersécurité : SIEM, SOAR, EDR, outils de Threat Intelligence… Chaque solution a ses contraintes propres, ses logs, ses besoins en maintenance, ses limites de stockage ou de montée en charge. Ces plateformes doivent être surveillées, configurées, sauvegardées et mises à jour régulièrement.
Gestion de l’Active Directory (AD) : élément central d’authentification, de gestion des comptes et de délégation des droits, l’AD est un point névralgique de la sécurité. Une mauvaise configuration ou une saturation de contrôleurs de domaine peut paralyser toute une organisation. Les administrateurs en assurent la cohérence via des GPO (Group Policy Object), la réplication correcte, les politiques de mot de passe, la politique de la journalisation avancée...

Blue Team, Red Team, Purple Team

La sécurité défensive et offensive ne sont plus considérées comme des univers distincts. Dans certaines organisations, elles coexistent et se complètent pour améliorer la posture globale de cybersécurité. Le SOC, historiquement positionné sur la supervision, voit désormais cohabiter ou interagir plusieurs types d’équipes intégrant la défense et l’attaque : les Blue Teams, les Red Teams et les Purple Teams. Chacune a une approche, une méthodologie et des outils spécifiques, mais leur objectif ultime est commun : renforcer la sécurité de l’organisation.

1. Définition, méthodologie, outils

a. Blue Team : la défense active

La Blue Team est une fonction collective et multidisciplinaire au sein du SOC, dont le rôle principal est de surveiller, détecter, analyser et répondre aux cybermenaces en temps réel. Elle vise à renforcer les défenses de l’organisation contre les attaques internes et externes, et peut être composée de professionnels aux compétences variées (analyse, ingénierie, administration, réponse aux incidents). En pratique, cette équipe est très souvent assimilée au SOC classique, même si certaines Blue Teams peuvent avoir un périmètre plus étendu, incluant la configuration sécurisée des systèmes ou la validation des politiques de sécurité.

Ses principales responsabilités comprennent :

Protection proactive : identifier et corriger les vulnérabilités avant qu’elles ne soient exploitées. Cela inclut le renforcement des mesures de sécurité, le développement de politiques et de procédures robustes.
Surveillance continue : surveiller les systèmes en permanence pour détecter toute activité suspecte, anomalie ou signe d’intrusion.
Détection et réponse aux incidents : détecter rapidement les attaques, analyser leur fonctionnement et mettre en œuvre des mesures pour les contenir, les éradiquer et récupérer les systèmes affectés. L’objectif est de minimiser les dommages et le temps d’arrêt.
Analyse...

Interactions entre les équipes

1. Threat Hunting : un rôle transversal par excellence

Le Threat Hunting est une activité indispensable au sein d’un SOC. Il ne se limite pas à la détection classique et à la réponse aux incidents : il consiste à rechercher proactivement des signaux faibles, des anomalies ou des indices de compromission que les systèmes automatisés n’ont pas identifiés. Cette mission nécessite une collaboration constante entre plusieurs équipes du SOC et au-delà.

a. Une approche itérative et collaborative

Le Threat Hunting repose sur une méthodologie itérative : hypothèses, collecte de données, analyse, et itérations. Pour chaque cycle de chasse, la disponibilité et la qualité des données sont garanties par les équipes responsables de l’architecture, de l’intégration et de l’administration des plateformes du SOC.

Cette activité nécessite une collaboration étroite et transverse, impliquant différentes expertises :

Les analystes SOC (L2 et L3), qui exploitent leur connaissance fine des incidents passés, des patterns de compromission et des règles de détection existantes.
Les équipes d’intégration, chargées d’ajuster les connecteurs, les parsers et les Playbooks si de nouvelles sources d’information ou des correctifs sont nécessaires.
Les équipes CSIRT, qui consolident les investigations et valident les hypothèses, notamment lors de la transition vers la réponse à incident.

Cette approche collaborative fait du Threat Hunting un levier stratégique pour l’amélioration continue de la cybersécurité.

b. Les outils et les données au service de la chasse

La chasse aux menaces s’appuie sur une multitude d’outils : requêtes SIEM avancées, EDR, analyses de flux réseau, solutions UEBA (User and Entity Behavior Analytics), et parfois des scripts sur mesure. Les intégrateurs et administrateurs jouent un rôle clé pour garantir l’accessibilité et la fiabilité des données.

En parallèle, le threat intelligence vient alimenter les hypothèses. Les analystes utilisent...

Les autres rôles clés dans l’écosystème SOC

1. Experts forensic

Ces spécialistes interviennent à des moments critiques : soit lorsque les signaux faibles détectés par les analystes SOC indiquent une potentielle compromission, soit après un incident avéré, pour des investigations approfondies. Leur mission principale est de conduire des investigations numériques poussées pour reconstruire l’enchaînement des événements et identifier les failles exploitées par les attaquants.

a. Enjeux du forensic dans un SOC

Les experts forensic apportent une valeur ajoutée considérable dans le cycle de vie d’un incident, en intervenant principalement après la détection initiale. Leur objectif est de :

Reconstituer le déroulement de l’attaque : remonter la chronologie des actions malveillantes, cartographier les mouvements latéraux, identifier les comptes et systèmes compromis.
Identifier les artefacts laissés par l’attaquant : fichiers suspects, clés de registre, connexions réseau, processus inhabituels.
Mettre en évidence les vulnérabilités exploitées : souvent issues de mauvaises configurations, de failles connues ou de comportements à risque.
Préserver les preuves : capturer des images disque, des dumps mémoire ou des logs, de façon à garantir leur intégrité pour d’éventuelles procédures judiciaires.

Le forensic est donc à la croisée des chemins entre technique et juridique. Une erreur dans la manipulation des preuves peut rendre l’enquête invalide et compromettre toute action ultérieure.

b. Collaboration avec les équipes SOC et CSIRT

Si des analystes SOC de niveau 3 ou des membres d’équipes CSIRT peuvent posséder des compétences forensiques pour des premières analyses, l’expert forensic est souvent un rôle dédié et est sollicité pour les investigations complexes ou à portée légale. Il travaille ainsi en synergie avec :

Les analystes SOC : pour comprendre l’alerte initiale, identifier les systèmes et comptes touchés, et vérifier les hypothèses....

Conclusion du chapitre

1. Au-delà des outils : les compétences font la différence

Souvent, lorsqu’on évoque un SOC, la première image qui vient en tête est celle d’un plateau technique truffé d’outils : SIEM, SOAR, EDR, pare-feu nouvelle génération, IDS/IPS, sondes réseau et autres solutions dernier cri. C’est vrai, un SOC moderne s’appuie sur des technologies de plus en plus performantes et intégrées. Pourtant, réduire un SOC à un simple agrégat d’outils serait passer à côté de l’essentiel : un SOC est avant tout une aventure humaine et une histoire de compétences.

Un SOC performant se distingue non seulement par la qualité de ses solutions techniques, mais surtout par la capacité de ses équipes à les configurer, les interpréter, les utiliser, les enrichir et les faire évoluer. Les outils n’existent pas dans le vide : ils sont mis en place, supervisés et exploités par des analystes, des administrateurs, des ingénieurs, des architectes, des intégrateurs et des managers qui forment une chaîne de compétences indispensable à la détection et à la réponse aux incidents.

Cette dimension humaine est d’autant plus cruciale qu’aucun outil ne peut, à lui seul, identifier tous les signaux faibles, corréler des événements complexes ou comprendre les spécificités métier de l’organisation. Un SIEM pourra collecter et trier des milliards d’événements, mais il faudra des analystes curieux, méthodiques et rigoureux pour distinguer une alerte bénigne d’un début de compromission. Un SOAR pourra automatiser certaines actions, mais il faudra des ingénieurs compétents pour définir les playbooks, maintenir les connecteurs et assurer leur pertinence face à des attaques en constante évolution....

Les équipes du SOC