Threat Monitoring — Alertes par mot-clé // MODULES

Threat Monitoring — Alertes par mot-clé

Surveillance récurrente par termes sur le corpus que la plateforme collecte : Telegram, WhatsApp, forums, réseaux sociaux, sites .onion, paste sites, dépôts de code, flux d’IOC, bases d’identifiants et journaux d’infostealer. Un moniteur décrit ce qui intéresse l’organisation ; la collecte s’exécute selon son propre calendrier et toute correspondance devient une alerte à trier.

Vue d’ensemble

Chaque moniteur porte un nom unique au sein de l’organisation, une catégorie (douze options, de la détection de menaces à la protection des dirigeants), une équipe responsable (SOC, CSIRT, Threat Intelligence, DevSecOps, Conformité, Risque, Fraude, Protection des données), une priorité et un statut.

La fréquence va de 1 minute à 30 jours. Le délai maximal d’exécution atteint 2 heures et le nombre de nouvelles tentatives en cas d’échec est configurable jusqu’à dix. L’exécution est orchestrée par Airflow : un déclenchement manuel met le DAG en file d’attente, et l’historique conserve chaque exécution avec sa durée, son résultat et sa tendance.

Les termes sont chiffrés au repos. Mots-clés, liste de termes, commandes de recherche et description du moniteur sont enregistrés dans des champs chiffrés. Ce qu’une organisation surveille constitue en soi une information sensible : cela révèle l’actif, le dirigeant et la marque exposés au risque.

La construction de la requête

Les termes deviennent des clauses de phrase obligatoires portant sur quatre champs de l’alerte — titre, description, donnée brute et source. À ces termes s’ajoutent des opérateurs :

  • AND ajoute des termes obligatoires ;
  • OR forme un groupe dont au moins un terme doit apparaître ;
  • NOT exclut tout document contenant l’un des termes.

Après la requête intervient une seconde passe de filtrage sur ce qui est remonté. Elle traite un terme isolé avec une frontière de mot, et une expression comportant un espace comme une sous-chaîne — c’est ce qui empêche bin de correspondre à l’intérieur de binaire tout en permettant de retrouver « carte de crédit » comme expression. Ces deux étages existent parce que l’exclusion par la requête seule ne suffit pas pour une négation portant sur des champs imbriqués.

Un tri, pas un déluge

Une alerte naît en attente. L’analyste la marque valide ou ignorée, et cette décision est consignée avec son auteur, la date, la sévérité attribuée et le marquage éventuel de faux positif. Les trois files se parcourent séparément, avec des filtres par titre, sévérité, mot correspondant, famille de stealer et présence de données de carte bancaire.

En parallèle, une couche d’expressions régulières étiquette l’alerte selon dix catégories — identifiants, fraude, fuite de données, usurpation de marque, phishing, dark web, malware, dirigeants, infrastructure et réseaux sociaux. L’étiquette oriente la file ; elle ne décide de rien.

Le moniteur accepte également une configuration de tri déclarative : périmètre, entités surveillées, couches de mots-clés par criticité, mots négatifs, motifs de validation et de rejet automatique, sources bénignes connues, fenêtre de déduplication en heures et seuil de score. C’est la façon de dire « ignore une mention en contexte universitaire » sans réécrire la requête.

Fonctionnalités

  • 112 sources de collecte associées à des index dédiés
  • Résumé par IA en option pour chaque alerte, avec un schéma fermé de types de menace — et un filtre pour n’afficher que les alertes avec ou sans résumé
  • Recoupement avec le corpus de fuites (combolists) et avec les paquets d’infostealer, filtre par famille de stealer inclus
  • Conversion des alertes en éléments d’incident ou de rapport, à l’unité ou par lot
  • Export des alertes au format XLSX
  • Suppression logique avec auteur et date, versionnement de la configuration et historique de huit types de modification
  • Dictionnaire des actifs de l’organisation, avec 41 catégories réparties en dix groupes, qui alimente les termes du moniteur

Cas d’usage

  • Suivre les mentions de la marque et des dirigeants sur les forums et les canaux fermés
  • Détecter des identifiants d’entreprise dans des paquets d’infostealer, avec la famille identifiée
  • Surveiller la campagne d’un acteur précis en combinant termes positifs et négatifs
  • Alimenter la file du SOC avec des alertes déjà catégorisées et priorisées

Ce que le module ne fait pas

  • Les canaux d’alerte sont l’e-mail, Slack et le webhook. Il n’existe pas de livraison native vers Microsoft Teams ni vers Discord — pour ceux-là, passez par le webhook.
  • Le résumé par IA ne décide pas si l’alerte est valide. La validation appartient à l’analyste, et c’est elle qui est consignée.
  • La catégorisation automatique est lexicale, fondée sur des motifs de texte. Ce n’est pas un classifieur entraîné et aucun taux de précision n’est publié.
  • Il n’existe pas de retraitement rétroactif automatique de l’historique lorsqu’un nouveau terme est ajouté au moniteur.

Intégrations

  • Slack, e-mail et webhook personnalisé
  • Airflow (orchestration des exécutions) et OpenSearch (corpus de collecte)
  • OODA Leaks, OODA Incident, OODA Reports et l’API REST de la plateforme

SLA et garanties

Fréquence de 1 minute à 30 jours · termes chiffrés au repos · toute validation d’alerte est signée

Étapes suivantes