SOC interne et SOC « as a Service »

1. SOC interne : si complet, réservé aux grosses structures

a. Définition et principe général

Le SOC interne est une organisation de cybersécurité totalement intégrée à l’entreprise. Il regroupe en son sein toutes les compétences, les outils et les infrastructures nécessaires à la supervision de la sécurité, à la détection des incidents et à la réponse aux menaces. Concrètement, il s’agit d’un ensemble d’équipes, de processus et de technologies qui travaillent main dans la main pour protéger le système d’information de l’organisation.

Contrairement à une solution externalisée, le SOC interne est généralement hébergé physiquement au sein des locaux de l’entreprise, dans un data center dédié, sous le contrôle exclusif de l’organisation. Ce modèle garantit une maîtrise totale des flux de données, des alertes de sécurité et des processus de remédiation.

b. Les principales caractéristiques

Un SOC interne complet se distingue par plusieurs éléments clés :

Une infrastructure propriétaire : l’entreprise investit dans des outils de sécurité tels que le SIEM, le SOAR, les EDR, les sondes IDS/IPS et autres solutions spécialisées. Elle est responsable de leur déploiement, de leur maintenance et de leur mise à jour régulière.
Des équipes internes spécialisées : analystes L1, L2 et L3, ingénieurs sécurité, administrateurs système et réseaux, architectes cybersécurité et experts forensic. Chacun contribue à la détection, à l’analyse, à la réponse et à l’amélioration continue des processus de sécurité.
Des processus personnalisés : le SOC interne définit ses propres workflows d’investigation, de gestion des incidents, de reporting et d’escalade. Il peut ainsi adapter la supervision à ses besoins spécifiques, à ses contraintes métier et à son contexte réglementaire....

Le SOC des années 2010

1. Une approche centrée sur le SIEM et des équipes polyvalentes

a. Le SIEM comme brique fondatrice du SOC des années 2010

Dans les années 2010, la plupart des SOC s’articulaient autour d’un SIEM. Celui-ci était souvent la première pièce posée pour assurer la supervision de la sécurité informatique. À l’époque, le SIEM servait à collecter et centraliser les logs des équipements critiques : pare-feu, serveurs, antivirus, équipements réseau, etc.

La collecte des logs passait principalement par des protocoles standards comme Syslog et Windows Event Forwarding, mais restait souvent limitée en termes d’enrichissement et de contextualisation.
Les règles de détection étaient créées manuellement, de façon souvent basique, à partir d’exigences de conformité ou de recommandations éditeur.
L’architecture technique était monolithique : une seule console de supervision, un stockage unique et une administration centralisée.

Le SIEM était alors perçu comme l’outil indispensable pour la détection des incidents et le respect des obligations réglementaires, notamment via la centralisation des logs. Il portait, à lui seul, la quasi-totalité de la charge de détection et de reporting.

b. Des personnes multitâches endossant le rôle d’analyste

Dans la plupart des structures, le SOC n’était pas encore une entité à part entière mais plutôt une extension des équipes infrastructure ou sécurité. On retrouvait donc souvent un administrateur ou un ingénieur système/réseau qui portait également la casquette d’analyste lorsqu’il en avait le temps.

Administration du SIEM : déploiement, configuration...

Le SOC des années 2020

1. Évolution du rôle du SIEM : de cœur du SOC à outil complémentaire

a. Un recentrage des priorités

Vers les années 2020, le paysage de la cybersécurité a connu une transformation rapide, et les SOC ont évolué en conséquence. Là où, une décennie plus tôt, le SIEM constituait souvent le cœur unique du dispositif de supervision, il devient progressivement un outil complémentaire.

Plusieurs facteurs expliquent ce changement :

La montée en puissance des EDR dans un contexte où la mise en place d’un SOC doit être rapide :

Ils sont faciles à déployer, via des agents installables sur des terminaux (postes de travail, serveurs Windows/Linux).
Ils remontent directement des alertes contextualisées, sans dépendre de logs formatés ou parsés.

Le SOAR devient alors la colonne vertébrale du SOC moderne, orchestrant les flux d’alertes, déclenchant les réponses automatiques, enrichissant les informations, et connectant l’ensemble de l’écosystème cyber.
Cette nouvelle architecture permet un démarrage rapide du SOC, un atout essentiel dans un contexte de forte demande, de tension commerciale, et d’exigence de retour sur investissement rapide.

Dans ce contexte, le SIEM conserve une utilité, mais il est de moins en moins au centre du dispositif.

b. Les limites du SIEM dans les déploiements rapides

Le SIEM présente plusieurs freins dans ce contexte :

Il nécessite des logs bien formatés, normalisés, parfois via des parsers spécifiques.
Pour chaque nouvelle source de logs, il faut implémenter, tester, maintenir un mapping conforme au modèle de données du SIEM.
Cette phase d’intégration peut prendre jusqu’à plusieurs mois, notamment dans les environnements hétérogènes ou mal documentés.

Dans un contexte de mise en place urgente de supervision (par exemple après une attaque, dans le cadre d’un appel d’offres concurrentiel ou d’un engagement de cybersécurité contractuel), ce délai est souvent inacceptable.

Chaque jour de retard est perçu comme un risque pour la sécurité et un coût...

L’apparition de SOC