Des événements isolés à une image unique de l'attaque
Les signaux de sécurité vivent dans des flux séparés — une anomalie sur un serveur ici, une alerte de sécurité sur un appareil là, une déviation dans l'ADN comportemental d'un appareil, et un événement d'attaque capturé dans un piège. Pris isolément, chacun paraît marginal. Mais une vraie compromission n'est aucun d'eux pris séparément — c'est l'histoire qui se déroule à travers tous. Le moteur de corrélation de Doogree lit cette histoire.
Le problème : quatre flux, aucun ne parle aux autres
Doogree dispose déjà de quatre sources de vérité distinctes : les anomalies serveur, les alertes de sécurité des appareils, les anomalies dans l'ADN comportemental d'un appareil et les événements d'attaque — honeytokens, force brute, contact avec un C2. Le problème, c'est que chaque flux est surveillé isolément : un administrateur voit six alertes de faible gravité et les classe comme du bruit. Mais ces mêmes six alertes, enchaînées les unes aux autres, sont un balayage qui a mené à un accès qui a mené à un déplacement latéral. Le bruit était l'attaque.
La solution : corrélation par entité et par temps
Le moteur de corrélation s'exécute toutes les 5 minutes et fait trois choses. 1. Regrouper par entité. Tous les signaux des quatre flux sont regroupés autour d'une entité partagée — un appareil, un serveur ou l'adresse IP d'un attaquant. 2. Regrouper par temps. Dans une fenêtre de deux heures, afin que des signaux espacés mais proches se relient dans la même histoire. 3. Projeter sur la kill-chain. Chaque signal est projeté sur une étape grossière de la chaîne d'attaque MITRE ATT&CK : reconnaissance → accès → exécution → évasion → déplacement latéral → C2 → impact. Le résultat : un seul incident en cours par entité, au lieu d'un déluge d'alertes.
Escalade : une chaîne pire que n'importe quelle alerte isolée
C'est ici que réside la vraie valeur. Lorsque plusieurs étapes différentes de la kill-chain s'accumulent sur la même entité, le moteur escalade automatiquement la gravité — une chaîne reconnaissance → accès → latéral est bien plus grave que chacun de ses maillons pris à part. Et lorsqu'un incident atteint le niveau élevé ou critique, le système pousse une alerte vers les administrateurs de l'espace de travail et propose un bouton de confinement qui agit avec consentement — une correction avec consentement, pas une action aveugle.
Cycle de vie : de l'alerte à la clôture
Un incident n'est pas un éclair ponctuel mais un enregistrement doté d'un état : ouvert, pris en compte, résolu. Vous pouvez le prendre en compte, l'investiguer et le clôturer — et tout est conservé pour la traçabilité. Au-dessus de tout cela s'exécute un résumé SOC quotidien par e-mail qui synthétise les incidents ouverts de gravité élevée/critique, afin qu'aucune chaîne ouverte ne passe entre les mailles du filet.