Un SOC crédible : ce qui se cache derrière la promesse de visibilité

Beaucoup d’offres de SOC promettent une visibilité totale. Dans les faits, trois leviers déterminent la capacité réelle à détecter une intrusion : la façon dont les logs sont collectés et filtrés, le nombre et la qualité des cas d’usage de détection, et la manière dont l’IA vient amplifier le travail des analystes. Décryptage.

Introduction

Le métier d’un SOC (Security Operations Center) tient en un mot : voir. Voir ce qui se passe sur le système d’information, en temps quasi réel, et distinguer le bruit normal d’un signal d’attaque. Mais entre la promesse commerciale et la réalité opérationnelle, l’écart peut être considérable.

Un SOC peut ingérer des téraoctets de logs et rester aveugle sur l’essentiel. Il peut afficher un tableau de bord impressionnant tout en laissant passer une intrusion pendant des semaines. La différence ne se joue pas sur le volume affiché, mais sur trois fondations qui se renforcent mutuellement. C’est ce que nous détaillons ici.

1. Collecter, centraliser, filtrer : le nerf de la guerre

Pourquoi tout centraliser

La raison d’être d’un SOC, c’est la centralisation des événements. En rassemblant les logs de l’ensemble du SI dans un point unique (le SIEM, ou une plateforme de type data lake de sécurité), on peut corréler des événements qui, pris isolément, ne disent rien. Une authentification échouée sur un serveur n’est qu’une ligne de log. Cinquante échecs suivis d’un succès, puis d’une connexion depuis un pays inhabituel, puis d’un accès à un partage sensible : c’est une chaîne d’attaque. Seule la centralisation permet de la reconstituer.

L’objectif final n’est pas d’accumuler des logs, mais de produire des cas d’usage de détection les plus fins possible. Et un cas d’usage fin a besoin de la bonne donnée, correctement structurée.

La contrainte que personne ne peut ignorer : le volume

C’est là que le réel reprend ses droits. La plupart des SIEM se facturent au volume :

• en Go/jour ingérés (modèle de Microsoft Sentinel, de Splunk en volume indexé, etc.),
• ou en EPS (events per second).

Conséquence directe : chaque log coûte de l’argent, en licence comme en stockage et en performance. L’approche naïve « on collecte tout » se heurte vite à un mur, une explosion budgétaire, un ralentissement des recherches, et surtout la noyade des analystes sous le bruit.

L’approche mature consiste à collecter la bonne donnée, pas toute la donnée.

Filtrer intelligemment, sans créer de zones d’ombre

Quelques pratiques qui font la différence :

• Prioriser les sources à forte valeur de détection : identité (Active Directory, IAM, fournisseur d’identité), endpoints/EDR, firewalls, proxy/DNS, plan de contrôle cloud, applications critiques. Ce sont elles qui portent l’essentiel des cas d’usage.
• Filtrer à la source : retirer le bruit verbeux et sans valeur de détection (certains événements purement informatifs, health checks, flux internes connus et massifs). Mais attention : ce filtrage doit être une décision de risque documentée et réversible, jamais un réflexe d’économie.
• Normaliser vers un schéma commun (ECS, ASIM, OCSF). Une donnée normalisée rend les règles de détection portables et la corrélation possible entre sources hétérogènes.
• Enrichir : géolocalisation IP, threat intelligence, criticité des actifs, contexte d’identité. Un log enrichi vaut dix logs bruts.
• Étager le stockage : un tier « chaud » interrogeable pour la détection, un tier « froid » / archive peu coûteux pour la conformité et le forensic. On garde ainsi la donnée brute pour le retro-hunting sans la payer au prix fort.

⚠️ Le piège du sur-filtrage. Filtrer pour réduire la facture est légitime, mais chaque source coupée est une fenêtre fermée. Une exfiltration via DNS, par exemple, sera invisible si les logs DNS ont été supprimés « parce qu’ils faisaient du volume ». La règle d’or : on documente ce que l’on jette et pourquoi, et on conserve si possible le brut en stockage économique.

Quand le modèle de la plateforme change la donne

Une partie de cet arbitrage coût/visibilité vient du modèle de facturation lui-même. C’est précisément ce que nous avons cherché à lever dans le choix de notre plateforme, Sekoia. Plutôt qu’une facturation au volume ou à l’EPS, Sekoia s’appuie sur un modèle de tarification fondé sur le nombre d’actifs protégés, et non sur le volume de données. Conséquence concrète : on n’est plus pénalisé financièrement à chaque source supplémentaire branchée, et la question « est-ce que ce log vaut son coût d’ingestion ? » se pose beaucoup moins souvent.

Au-delà du modèle économique, plusieurs caractéristiques servent directement la finesse de détection :

• Une CTI native et intégrée aux règles. Les règles de détection incorporent la threat intelligence, ce qui permet de repérer des signaux faibles et d’anticiper les menaces plutôt que de réagir après coup.
• Une approche open XDR avec un large catalogue d’intégrations — plus de 200 outils tiers intégrables et plusieurs centaines de règles vérifiées et maintenues — qui réduit drastiquement le temps d’embarquement des sources et le travail de normalisation.
• Un format de règles ouvert : le format ouvert des règles permet de savoir exactement pourquoi une règle a sonné et comment effectuer la levée de doute. C’est un atout majeur pour le réglage fin et la réduction des faux positifs.
• Une solution souveraine européenne, un argument loin d’être anecdotique dans un contexte réglementaire NIS2 / DORA et pour les organisations soumises à des exigences de confiance fortes.

(Note : nous citons ici notre propre outillage à titre d’exemple concret ; les principes décrits valent quel que soit le SIEM/XDR retenu.)

2. Les cas d’usage : la vraie mesure d’un SOC

Le problème des offres « vitrine »

Beaucoup de SOC, notamment certains MSSP, vendent un nombre restreint et figé de cas d’usage, souvent quelques dizaines de règles de corrélation génériques. C’est séduisant sur le papier, mais cela produit mécaniquement de larges angles morts sur la surface d’attaque. Concrètement : des familles entières de techniques d’attaque ne déclenchent aucune alerte. L’intrusion passe, non pas parce qu’elle est sophistiquée, mais parce que personne ne regardait dans cette direction.

La bonne grille de lecture n’est pas le nombre brut de règles, mais la couverture mesurée face à MITRE ATT&CK : quelles tactiques et techniques sont effectivement détectées, et où sont les trous.

Des exemples de cas d’usage essentiels, par technologie

Réseau / Firewall

• Scans de ports et balayage réseau
• Trafic vers des IP/domaines malveillants (threat intel) et beaconing C2 (communications périodiques régulières)
• Pic anormal de connexions refusées (deny)
• Exfiltration : volume sortant anormal, DNS tunneling
• Connexions depuis des zones géographiques non attendues
• Mouvement latéral est-ouest inhabituel (SMB, RDP entre postes)

Système / Endpoint (Windows & Linux)

• Brute force et password spray sur l’authentification
• Élévation de privilèges et ajout à des groupes privilégiés
• Persistance : tâches planifiées, services, clés Run, cron
• Dump de credentials (accès au processus LSASS)
• Exécution suspecte : PowerShell encodé/obfusqué, LOLBins (mshta, rundll32, certutil…)
• Désactivation de l’EDR/antivirus, effacement des journaux d’événements

Identité / Active Directory / IAM

• Kerberoasting et AS-REP roasting
• DCSync / réplication anormale depuis un compte non-DC
• Anomalies Kerberos (golden/silver ticket)
• Connexions hors horaires, depuis des comptes dormants

Cloud (AWS / Azure / GCP / M365)

• Impossible travel et connexion depuis une IP/géo nouvelle
• Désactivation du MFA ou modification des politiques de sécurité
• Création de rôle ou de compte à privilèges élevés
• Clés d’accès créées ou utilisées anormalement
• Stockage exposé publiquement (bucket S3 / Blob public)
• Consentement OAuth à une application suspecte, règles de transfert d’e-mails (signal classique de Business Email Compromise)
• Téléchargement massif de données

Web / Proxy / Messagerie

• Accès à des domaines nouvellement enregistrés
• Beaconing applicatif
• URL et pièces jointes malveillantes (phishing)

Combien de cas d’usage pour un SOC crédible ?

Posons-le clairement : opposer quantité et qualité est une fausse piste. Mieux vaut déployer large et nettoyer pendant l’enrôlement que démarrer avec trop peu. La raison tient à une asymétrie des coûts : une règle absente est un angle mort garanti et silencieux, vous ne saurez jamais ce que vous ratez, tandis qu’une règle trop bruyante reste un signal que l’on peut affiner, suspendre ou supprimer. Désactiver est réversible et bon marché ; un raté de détection est, lui, irréversible.

La bonne doctrine est donc d’activer une couverture large dès le départ, puis de la régler en continu, la phase d’enrôlement étant la fenêtre idéale pour apprendre la baseline de l’environnement et calibrer les seuils. Une seule condition pour que cela ne se retourne pas contre les analystes : disposer de la capacité de tuning pour faire réellement ce nettoyage. La parade éprouvée consiste à déployer largement en mode audit / observation (ou avec un gating par sévérité), puis à promouvoir les règles en alerte à mesure qu’elles sont réglées. Le piège n’est jamais le nombre de règles : c’est le « set and forget ».

Ce qui compte n’est donc pas un chiffre brut, mais une couverture large, pilotée et affinée. À titre indicatif, voici les ordres de grandeur visés une fois le réglage stabilisé :

Plutôt qu’un chiffre magique, fixez un plancher de couverture : viser les 20 à 30 techniques ATT&CK les plus répandues (selon votre secteur et les rapports de menace), réparties sur l’ensemble des tactiques — accès initial, exécution, persistance, élévation de privilèges, évasion, accès aux identifiants, découverte, mouvement latéral, collecte, C2, exfiltration, impact. En pratique, cela se traduit par 50 à 100 cas d’usage réglés au minimum.

Pour rendre ce plancher actionnable, voici une répartition indicative par catégorie — des fourchettes, pas des dogmes, à pondérer selon votre exposition :

Le total tombe naturellement dans la fourchette des 50 à 100 cas d’usage réglés. À noter : la catégorie identité est volontairement la plus dotée, c’est aujourd’hui le principal vecteur de compromission, et le point de passage obligé de la plupart des attaques.

La CTI sectorielle : passer du générique au pertinent

Un cas d’usage générique détecte une technique « dans l’absolu ». Une CTI (Cyber Threat Intelligence) spécifique à votre secteur le transforme en détection ciblée sur les menaces qui vous visent réellement. La différence est loin d’être cosmétique :

• Priorisation du risque réel. Un acteur bancaire n’affronte pas les mêmes groupes qu’un hôpital ou qu’un industriel. La finance est surexposée aux trojans bancaires, à la fraude au virement et aux groupes de rançongiciels spécialisés ; la santé, au vol de données et au ransomware ; l’industrie, aux menaces visant l’OT/ICS ; le secteur public, à l’espionnage étatique. Une CTI sectorielle concentre l’effort de détection et de chasse sur ces TTP-là.
• Détection des signaux faibles et anticipation. Des IOC et TTP qualifiés avant qu’ils ne vous frappent permettent de détecter en amont, voire de bloquer proactivement.
• Réduction du bruit. En contextualisant les alertes (cet IOC est-il lié à un acteur actif dans mon secteur ?), on diminue les faux positifs et on accélère la levée de doute.
• Contextualisation pour la décision. Une CTI verifiée et enrichie aide aussi le RSSI à prioriser les correctifs, à arbitrer les budgets et à sensibiliser la direction.

C’est précisément l’intérêt d’une CTI native intégrée à la plateforme (cf. partie 1) : les règles ne se contentent pas de matcher un motif, elles savent à qui ce motif est associé et à quel point c’est pertinent pour vous.

La vraie métrique d’un SOC n’est pas le nombre de règles, mais : le pourcentage de couverture ATT&CK, le taux de faux positifs, et la capacité à détecter un exercice red team / purple team. Un SOC qui ne sait pas dire ce qu’il ne couvre pas n’est pas un SOC mature.

3. IA et agents dans le SOC : que résolvent-ils vraiment ?

Les maux du SOC classique

Avant de parler de solution, rappelons les problèmes structurels :

• Fatigue d’alerte : des milliers d’alertes par jour, dont une majorité de faux positifs.
• Pénurie d’analystes et turnover élevé, avec une perte de connaissance à chaque départ.
• Triage et investigation lents : des temps de détection (MTTD) et de réponse (MTTR) qui se comptent parfois en jours.

Ce que l’IA apporte

• Triage et priorisation automatisés : scoring, déduplication, regroupement d’alertes en incidents cohérents.
• Réduction des faux positifs : en s’appuyant sur le contexte et l’historique des décisions passées.
• Détection comportementale (UEBA) : établissement de lignes de base par utilisateur/entité pour repérer l’anomalie — utile contre les menaces inconnues, là où les règles statiques échouent.
• Accélération de l’investigation : enrichissement automatique, récupération du contexte, et résumé d’un incident en langage naturel.
• Interface en langage naturel : interroger les logs sans maîtriser le langage de requête du SIEM.

L’apport des agents (IA agentique)

C’est la rupture récente. Un agent ne se contente pas de classer une alerte, il mène l’enquête :

• il prend une alerte, collecte les preuves (enrichit les IOC, interroge l’EDR, croise les logs d’identité, remonte les événements liés),
• il reconstruit une chronologie, propose un verdict et des actions recommandées,
• il peut orchestrer la réponse (logique SOAR), isoler un poste, désactiver un compte, bloquer une IP, avec des points de validation humaine sur les actions sensibles,
• il assiste le detection engineering en suggérant de nouvelles règles et en pointant les écarts de couverture face à ATT&CK.

Les problèmes résolus

• Passer à l’échelle sans croissance linéaire des effectifs.
• Réduire le MTTD et le MTTR de façon significative.
• Libérer les analystes pour les menaces complexes, la chasse et l’ingénierie de détection.
• Apporter de la constance : un triage reproductible, qui ne dépend pas de la fatigue de l’analyste de garde.

Les limites à garder en tête

L’IA n’est pas une baguette magique, et le dire renforce la crédibilité d’une démarche :

• L’humain dans la boucle reste indispensable pour les actions de réponse à impact.
• Risque de hallucination et de sur-confiance : il faut de la vérification et de l’explicabilité.
• Gouvernance de la donnée et confidentialité : que transmet-on à un moteur d’IA, et avec quelles garanties ?
• Garbage in, garbage out : une IA branchée sur une télémétrie pauvre ou une couverture trouée (parties 1 et 2) ne fera qu’automatiser l’aveuglement.
• Surface d’attaque nouvelle : les adversaires utilisent aussi l’IA, et les workflows agentiques exposent au risque d’injection de prompt.

Le vrai juge de paix : la qualité de détection, pas le nombre

Voilà le point qui mérite d’être martelé. Un SOC ne se mesure ni au nombre d’analystes affichés à l’organigramme, ni au nombre d’agents IA déployés. Ces chiffres sont des moyens, pas des résultats. On peut empiler les analystes sur une détection médiocre et ne produire que de la levée de doute sur du bruit ; on peut multiplier les agents IA sur une couverture trouée et ne faire qu’industrialiser l’angle mort plus vite.

Ce qui compte, c’est la qualité de détection effectivement produite, et elle se mesure :

• la couverture ATT&CK réelle et ses trous assumés,
• le MTTD / MTTR (vitesse de détection et de réaction),
• le taux de vrais positifs et la maîtrise des faux positifs,
• le dwell time (durée pendant laquelle un attaquant reste non détecté),
• et la performance face à des exercices red team / purple team.

Un SOC de cinq personnes avec une détection bien pensée et une CTI pertinente surpassera un SOC de cinquante mal outillé. L’IA et les agents ne changent pas cette règle : ils l’amplifient, dans un sens comme dans l’autre.

Conclusion : trois piliers indissociables

Un SOC crédible ne se résume à aucun de ces trois éléments pris isolément. Une télémétrie riche et bien filtrée (partie 1) alimente des cas d’usage larges et cartographiés sur ATT&CK (partie 2), que l’IA et les agents viennent amplifier (partie 3).

La faiblesse de l’un plafonne les autres : collecter sans détecter ne sert à rien, détecter sans pouvoir traiter le volume épuise les équipes, et automatiser sur une base lacunaire ne fait qu’industrialiser les angles morts. Et aucun de ces piliers ne se juge à sa taille, ni au volume de logs, ni au nombre de règles, ni au nombre d’analystes ou d’agents IA, mais à la qualité de détection qu’il produit au bout de la chaîne. 

La vraie question à poser à un SOC n’est pas « combien ? », mais : « que ne voyez-vous pas, et comment le savez-vous ? »