← Blog Corrélation

Pourquoi le moteur de corrélation est notre joyau

Un moteur de corrélation vous doit quatre choses — un dossier qui s'explique tout seul, une déduplication qui encaisse une rafale sans perdre une alerte, une file de triage qui classe sur ce qu'un dossier est devenu et non sur ce à quoi il ressemblait au départ, et, si vous servez plusieurs clients, un mur entre eux que rien ne franchit. Ce que chacune veut dire pour votre SOC, quelle que soit la stack de détection déjà en place.

Ce qui manque à un SOC, ce ne sont pas des données supplémentaires. C'est une couche de décision, et c'est exactement ce que construit ce moteur. En 2025, CardinalOps a analysé des configurations SIEM réellement en production : les SIEM d'entreprise ne disposaient de détections que pour 21 % des techniques MITRE ATT&CK alors que les données déjà collectées permettaient d'en couvrir 90 %, et 13 % des règles en place étaient cassées sans que personne s'en aperçoive.

Les données sont là. Presque rien n'en sort sur quoi un humain puisse trancher. La couverture de détection est un vrai problème, et ce n'est pas celui que traite ce moteur : comblez cet écart et vous aurez plus d'alertes à qualifier, pas moins. Collecter n'a jamais été le plus dur ; transformer ce qui se déclenche en un dossier qui mérite d'être ouvert, si.

Le moteur de corrélation de Seculogik travaille dans cet écart. Donnez-lui une semaine d'alertes, prises sur la stack de détection que vous exploitez déjà : il vous rend une poignée de dossiers qui s'expliquent tout seuls, qui tiennent pendant les cinq minutes les plus chargées du mois, et qui arrivent aux analystes dans l'ordre qui compte. Alertes → dossier → décisions. C'est pour cela que nous en parlons comme d'un joyau et pas comme d'une fonctionnalité de plus.

Il se pose au-dessus de la stack que vous avez déjà. Côté open source, les SIEM et les bases sur lesquelles ils reposent : ClickHouse, Elastic / ELK, OpenSearch, Wazuh. Côté marché : Splunk, Microsoft Sentinel, CrowdStrike, Microsoft Defender, SentinelOne, Cortex XDR, Fortinet, Okta, Entra ID, AWS, Azure. Et tout le reste par un connecteur dédié que nous développons à la demande, ou par un webhook générique que vous mappez une seule fois dans notre data map universelle.

Rien de ce que vous avez déjà ne bouge, et rien de ce que vous avez déjà ne s'arrête si vous nous retirez : c'est le seul test honnête de l'enfermement fournisseur. Il ne remplace ni votre stockage de logs ni vos sondes : il décide de ce qu'ils vous disent.

Il doit une explication à l'analyste

La plupart des corrélations tiennent en une règle et un seuil, et le dossier qui en sort dit « la règle X s'est déclenchée ». C'est une étiquette, pas une explication : elle nomme la règle qui s'est déclenchée, pas l'impact métier de ce qu'elle a attrapé. Et personne ne défend une étiquette devant un COMEX, un auditeur ou un régulateur.

Seculogik soumet chaque alerte à neuf contrôles indépendants, puis les laisse voter. Sept des questions posées ressemblent à ceci.

  • Cet hôte, cet utilisateur, cette IP participent-ils déjà à quelque chose en cours ?
  • L'attaque progresse-t-elle vraiment ?
  • Deux outils différents rapportent-ils la même chose, chacun de son côté ?
  • Un utilisateur discret accumule-t-il du risque, semaine après semaine ?
  • Reconnaît-on là un scénario connu — phishing puis prise de contrôle du compte, exécution sur un endpoint puis ransomware ?
  • Le même attaquant ressort-il ailleurs dans le parc ?
  • Est-ce un pattern bénin connu, que l'on peut nommer et écarter ?

Un contrôle isolé se laisse tromper. Neuf contrôles qui posent chacun une question différente à la même alerte, beaucoup plus difficilement — et quand ils divergent, l'analyste voit le désaccord, pas un niveau de confiance derrière lequel il n'y a rien.

Le verdict est consigné avec le dossier : quels signaux ont pesé, comment on y est arrivé, et ce qui aurait dû changer pour que le verdict soit différent. La relève reprend le dossier sans passation orale, et un RSSI le rouvre un an plus tard et lit pourquoi il a existé. Le moteur se règle sur votre parc au lieu d'arriver avec une opinion figée. C'est ce que nous appelons un moteur qui montre son raisonnement.

Si vous servez plusieurs clients, il doit à chacun un mur — édition MSSP

Cette section ne vaut que pour l'édition MSSP. En Free et en Client, il n'y a qu'une seule organisation — la vôtre —, donc rien à cloisonner et rien à payer ici. Lisez la suite si vous exploitez un SOC managé, ou un groupe qui doit séparer ses filiales.

Un client, un espace de dossier. Toujours. Pour un prestataire, c'est ce qui sépare une plateforme multi-clients d'une boîte mail partagée. Pour un groupe, c'est le même mur entre filiales, business units, régions, ou entre un site OT et les dossiers du siège, qu'il ne doit jamais voir. Le même hash de fichier, le même nom d'hôte, la même IP publique et la même technique observés chez deux clients donnent deux dossiers, preuves identiques ou non : l'alternative, c'est un produit de sécurité qui parle au client A de l'incident du client B.

Cette frontière est appliquée à plusieurs niveaux indépendants, et chacun tiendrait seul : depuis l'arrivée de l'alerte, à chaque question que le moteur pose aux données, jusqu'au verdict qu'il consigne. Une alerte qu'il ne peut pas rattacher avec certitude part en file de quarantaine, où un humain tranche, plutôt que d'être attribuée à l'aveugle et versée dans le parc de quelqu'un. Les dossiers d'un client ne sont pas seulement verrouillés vis-à-vis des utilisateurs des autres : ils sont invisibles, si bien que même leur existence ne fuit pas.

Le moteur se règle parc par parc. Cette frontière, jamais : c'est la seule chose que nous ne rendons pas configurable. Et c'est elle qui vous permet d'y apposer votre propre marque.

Il doit encaisser une rafale sans perdre une alerte

Tous les SOC connaissent la scène : une règle, une source, des centaines de déclenchements en quelques minutes — une campagne de brute force, un agent mal configuré, le passage d'un scanner. C'est la fatigue des alertes qui arrive d'un coup, et c'est là que la déduplication naïve lâche : le dossier qui en sort sous-estime l'attaque, et personne ne sait de combien.

Seculogik encaisse la rafale à sa place. Des centaines d'alertes de faible sévérité deviennent un seul dossier, scoré pour ce que le volume veut dire, chaque occurrence comptée — y compris celles qui tombent pendant le redémarrage d'un composant. Rien ne se perd. Une suppression du bruit qui emporte les preuves avec le bruit, c'est de la perte de données sous un autre nom.

Cela vaut quelle que soit la source — une stack open source, une plateforme du marché, ou une source pour laquelle nous avons écrit le connecteur parce que vous l'avez demandé — et quel que soit le chemin qu'elle emprunte : poussée par une plateforme endpoint, récupérée par un connecteur sur un service cloud, ou lue en continu dans le SIEM que vous exploitez déjà. Une rafale ne vous coûte jamais une alerte.

Il doit à la file le sens des proportions

La sévérité ne fait pas l'urgence à elle seule ; le volume y compte tout autant, et un triage qui ne regarde que la sévérité passe à côté. Des centaines d'échecs d'authentification sont, pris un par un, de faible sévérité, et une file qui range le dossier en « faible » parce que ses composants l'étaient vient de cacher une attaque par brute force sous les yeux de tous.

Le curseur est entre vos mains. Vous décidez à partir de quel volume un dossier devient plus grave, et le dossier emporte cette raison avec lui : le N1 qui travaille la file voit pourquoi un signal de faible sévérité est remonté en tête. La position dans la kill chain avance elle aussi avec les preuves : un dossier entré par un accès initial et arrivé jusqu'à l'impact est classé en impact, pas là où il a commencé. Votre backlog est ordonné sur ce que les dossiers sont devenus, pas sur ce à quoi ils ressemblaient au départ.

Ce que nous affirmons, et ce que nous n'affirmons pas

Nous affirmons ce que nous avons annoncé en ouverture : une semaine de vos alertes donne une poignée de dossiers qui s'expliquent tout seuls, qui tiennent pendant vos cinq minutes les plus chargées, et qui se classent sur ce qu'ils sont devenus. Nous affirmons que ces verdicts restent lisibles longtemps après le départ de l'analyste qui les a rendus. Et si vous le décidez, le moteur tient compte des verdicts de vos analystes pour établir ce qui compte le plus dans votre parc — jamais tant que vous ne l'avez pas activé.

Nous ne publions aucun chiffre de précision ni de réduction des faux positifs qui nous soit propre : il n'existe pas encore de comparatif crédible entre éditeurs, et un chiffre que personne ne peut vérifier vaut moins que pas de chiffre du tout. Nous sommes en pré-GA : aucun client à ce jour, aucune qualification, aucun rapport de test d'intrusion tiers, aucun SLA. C'est pour cela que ce que nous proposons en ouverture, c'est une semaine de vos propres alertes et pas un chiffre de notre part.

Nous ne vendons pas un SOC autonome : le moteur classe et explique, la décision reste humaine. La supervision humaine est le principe, pas une étape transitoire que nous cherchons à supprimer.

Neuf contrôles, un verdict, aucune rafale perdue, une file qui a le sens des proportions. Le moteur de corrélation et The Verdict Layer sont l'édition Client elle-même, pas un module à ajouter par-dessus : c'est ce qui s'allume le jour où vous passez de Free à Client. Alertes → dossier → décisions.

La suite, c'est ce que vos analystes trouvent après le verdict : un analyste IA qui pose ses hypothèses et ses preuves avant de trancher, et dont chaque affirmation est recoupée avec les alertes du dossier, devant l'équipe. C'est SIROC, notre module Advanced AI. Voir comment SIROC raisonne.