Threat Intelligence — Protection de la marque en ligne
Couche de gouvernance de la protection de marque. C’est ici que l’organisation déclare ce qui doit être surveillé et par quels canaux — sept fronts indépendants, chacun avec ses sources enregistrées — et c’est ce référentiel qui oriente la collecte réalisée par les modules de détection.
Vue d’ensemble
Les sept fronts sont Domain Intelligence, Network Intelligence, Phishing Monitor, Brand Monitor, Fake Apps, Social Network et Fraud Intelligence. Ils peuvent être souscrits ensemble ou séparément et partagent le même modèle : chaque enregistrement est une source ou une cible de surveillance, avec un nom, une URL, un type, un secteur, un responsable, une description et, lorsque la source exige une authentification, les identifiants d’accès.
La séparation en sept n’est pas cosmétique. Elle existe parce que les fronts ont des propriétaires différents chez le client — la personne qui traite les fausses applications sur les stores est rarement celle qui gère les plages d’IP — et parce que la licence se souscrit par front, ce qui permet de commencer par un seul et d’étendre ensuite.
Le fonctionnement interne
Les identifiants de source ne sont jamais en clair. URL, adresse e-mail, mot de passe et description de chaque enregistrement sont stockés dans des champs chiffrés. Le mot de passe de la source est la donnée la plus sensible du module : c’est lui qui ouvre l’accès à un forum fermé, à la console d’un marketplace ou à un compte de surveillance. Il est écrit chiffré et lu chiffré.
Cloisonnement multi-tenant fail-closed. Les sept fronts s’appuient sur une clé primaire séquentielle, ce qui invite à l’énumération par l’URL. Toute lecture par identifiant passe par le même filtre d’organisation, y compris sur les écrans de détail, de modification et de suppression — pas seulement sur la liste. Si l’organisation de l’utilisateur ne peut pas être résolue, la requête renvoie vide, jamais la totalité. Le filtre exclut également les enregistrements déjà supprimés, afin qu’un ancien identifiant ne ressuscite rien par l’URL.
La suppression est réversible et auditée. Supprimer marque l’enregistrement comme retiré ; il disparaît de l’interface mais reste en base pour l’audit. Quatre signaux sont émis et consommés par la piste d’audit : création, activation ou désactivation, suppression logique et suppression physique — cette dernière est rare et existe pour être remarquée.
Des décomptes en une seule requête. L’écran d’accueil de chaque front affiche le total, les actifs, les inactifs et les créations des sept derniers jours au moyen d’une agrégation unique, au lieu de quatre décomptes successifs.
Le dictionnaire des actifs de la marque
Rattaché à ce module, un registre recense tout ce que l’organisation entend protéger : 41 catégories réparties en dix groupes.
| Groupe | Exemples de catégorie |
|---|---|
| Identité et marque | mots-clés, noms de marque, termes déposés, noms de produit, liste blanche |
| Infrastructure numérique | domaines, sous-domaines, URL, IP, plages réseau, ASN |
| Mobile | noms de paquet, identifiants de store, bundle IDs iOS |
| Financier | BIN, motifs de carte, motifs de compte, prestataires de paiement |
| Personnes (VIP) | dirigeants, collaborateurs, administrateurs, fonctions |
| Contact | adresses e-mail, domaines de messagerie, téléphones, formulaires |
| Réseaux sociaux | pseudonymes, URL, identifiants, chaînes YouTube, identifiants d’entreprise LinkedIn |
| Documents | empreintes MD5 et SHA256, titres de document, certificats SSL |
| Juridique | CNPJ et équivalents, numéros d’immatriculation, licences |
| Géolocalisation | adresses, bureaux, régions |
Chaque catégorie a sa propre limite par organisation, fixée au contrat. C’est ce dictionnaire qui alimente les termes des moniteurs et la définition des périmètres EASM — plutôt que chaque module tienne sa liste maison de « ce qui est à nous », il n’y a qu’une seule liste.
Le même référentiel conserve le quota de takedown de l’organisation : volume mensuel, mode de décompte, report limité du solde inutilisé, priorité et option d’approbation automatique.
Cas d’usage
- Centraliser en un seul endroit ce que l’organisation considère comme sien : marques, domaines, dirigeants, BIN, paquets applicatifs
- Enregistrer les sources de surveillance de chaque front sans disséminer d’identifiants dans des tableurs
- Répartir la responsabilité par front, avec un secteur et un responsable nommés sur chaque enregistrement
- Prouver en audit qui a créé, activé, désactivé ou retiré chaque front de surveillance, et quand
Ce que le module ne fait pas
Ce module relève du référentiel et de la gouvernance, ce n’est pas un moteur de détection. Plus précisément :
- Il n’enrichit pas automatiquement les indicateurs. WHOIS, DNS, SSL, ASN et contact d’abus sont collectés dans le flux de takedown, au sein de Legal & Takedown.
- Il n’attribue pas de score de risque de 0 à 100. La notation d’exposition relève du module EASM, où elle correspond à la somme des constats ouverts.
- Il ne réalise pas de corrélation automatique entre les sept fronts.
- Il n’interroge ni MISP, ni OpenCTI, ni VirusTotal, ni Google Safe Browsing depuis ce module. La synchronisation avec MISP fait l’objet d’un module dédié (MISP Sync) ; les requêtes de réputation figurent parmi les sources de Threat Monitoring.
- L’export PDF par front n’est pas encore implémenté et renvoie un avertissement, pas un fichier.
- Il ne tient pas d’inventaire de TLD et ne parcourt pas les registres de domaines de sa propre initiative — le typosquatting est détecté dans l’EASM.
Intégrations
- Chiffrement de champ au repos et piste d’audit de la plateforme (OODA Audit)
- OODA Threat Monitoring (qui consomme le dictionnaire des actifs), OODA EASM (périmètres) et Legal & Takedown (quota et déclenchement)
SLA et garanties
Identifiants de source chiffrés au repos · cloisonnement par organisation fail-closed · suppression réversible et auditée