Déduplication
Comment Stealed évite de créer des événements en double depuis le même monitor, et pourquoi vos alertes ne signalent que des fuites véritablement nouvelles.
Quand plusieurs fuites de credentials correspondent au même monitor, Stealed ne crée pas un événement par fuite. À la place, la déduplication garantit un seul événement ouvert par monitor, et trace les nouvelles fuites sur l'événement existant jusqu'à ce que vous le clôturiez.
Cette page explique la règle et pourquoi elle produit des alertes plus propres.
La règle
La logique de déduplication a deux cas.
Cas 1 : un événement est déjà ouvert pour ce monitor
Quand une nouvelle fuite matche un monitor qui a déjà un événement ouvert :
- La fuite est ajoutée à l'événement existant.
- Le
matched_countde l'événement est incrémenté. - Aucun nouvel événement n'est créé.
- Une re-notification peut se déclencher si le threshold volumique est atteint.
En pratique : vous avez un événement par monitor à la fois, et cet événement grossit à mesure que de nouvelles fuites correspondantes arrivent.
Cas 2 : l'événement précédent est clôturé
Quand une nouvelle fuite matche un monitor dont l'événement précédent a été clôturé :
- Un nouvel événement est ouvert.
- Le nouvel événement ne compte que les nouveaux credentials : les fuites dont le hash faisait déjà partie de l'événement clôturé NE sont PAS recomptées.
- Les notifications se déclenchent sur les canaux configurés.
En pratique : clôturer un événement remet le compteur à zéro pour "ce qui est nouveau", mais les credentials historiques ne génèrent pas de bruit frais.
Pourquoi ce design
Sans déduplication, un monitor surveillant un domaine à fort volume produirait des dizaines d'événements par jour, tous sur le même problème sous-jacent. Votre équipe passerait plus de temps à trier des doublons qu'à agir dessus.
Avec la déduplication :
- Un événement par monitor à la fois : la timeline d'activité de cet événement est la source unique de vérité pour cet incident
- Clôturer un événement signale "j'ai géré l'ensemble actuel" : seuls les credentials véritablement nouveaux déclenchent une notification fraîche par la suite
- Intégrité de la piste d'audit : chaque événement couvre une population définie de fuites, identifiée par leurs hashes ; la chronologie est reproductible
Exemple de timeline
Considérons un monitor surveillant acme.com avec un threshold de 5.
| Heure | Événement | Ce qui se passe |
|---|---|---|
| Jour 1, 10:00 | 5 nouvelles fuites arrivent matchant acme.com | Threshold atteint, événement #1 ouvert avec 5 fuites. Notification déclenchée. |
| Jour 1, 14:00 | 2 fuites supplémentaires arrivent | Événement #1 ouvert, 2 fuites ajoutées. matched_count = 7. Pas de nouvel événement. |
| Jour 1, 15:00 | 23 fuites supplémentaires arrivent | Événement #1 ouvert, fuites ajoutées. matched_count = 30. Re-notification volumique déclenchée (threshold par défaut de 10 depuis la dernière notif). |
| Jour 2, 09:00 | Votre équipe clôture l'événement #1 | Événement #1 figé à 30 fuites. Piste d'audit capturée. |
| Jour 2, 11:00 | 4 nouvelles fuites arrivent (3 nouveaux hashes, 1 déjà dans l'événement #1) | Nouvelles fuites, événement #2 ouvert avec 3 (l'unique 1 est ignoré). La notification se déclenche uniquement parce que 3 nouveaux hashes suffisent à compter comme "nouvelle activité". |
Comment "nouveau" est déterminé
Un credential est identifié par son hash (une empreinte cryptographique opaque calculée à partir de username + mot de passe + URL cible).
Quand une fuite arrive :
- Stealed calcule son hash.
- Le hash est confronté à :
- Le plancher anti-replay de chaque monitor susceptible de matcher
- Les hashes déjà comptés dans tout événement ouvert de ces monitors
- Si le hash n'a pas encore été vu par le monitor, le credential compte.
Le plancher anti-replay est le timestamp last_seen le plus élevé
parmi les fuites déjà comptées par le monitor. Il avance à mesure que
les fuites sont tracées, garantissant qu'une vieille fuite ré-ingérée
ne soit pas recomptée.
Cas particuliers
Édition des filtres d'un monitor
Si vous changez les filtres d'un monitor qui a un événement ouvert, Stealed avance correctement le plancher anti-replay pour que l'événement existant continue de tracker le nouveau périmètre à partir de ce point. L'événement n'est pas clôturé automatiquement. Si le nouveau périmètre n'a aucun lien avec l'ancien, vous pouvez préférer clôturer l'événement existant d'abord et repartir à zéro.
Activer / désactiver un monitor
Basculer le monitor off puis on remet last_resolved_at à zéro. Cela
signifie qu'un monitor réactivé compte chaque fuite correspondante
comme nouvelle, même si elle était déjà connue de l'instance
précédente.
C'est différent de la mise en sourdine, qui préserve l'état.
Détection de doublons entre organisations
Les hashes sont scopés par organisation. Si deux organisations surveillent le même domaine, les deux voient les mêmes credentials, mais les compteurs de hash sont indépendants. Il n'y a pas de déduplication cross-tenant.
La suite
- Re-notification : le threshold de volume qui contrôle les rappels à l'intérieur d'un événement ouvert.
- Gestion d'incident : comment clôturer un événement proprement pour réinitialiser le compteur des nouvelles alertes.