Surveiller la réputation d’un domaine : quelles alertes ?

Surveiller la réputation d’un domaine consiste à comparer des observations datées pour décider si son usage reste acceptable. Une vérification ponctuelle répond à « que savons-nous maintenant ? ». La surveillance doit répondre à « qu’est-ce qui a changé depuis notre dernière décision ? ».

Cette distinction compte pour un portail fournisseur, un service de connexion ou un domaine rencontré dans une enquête. Une adresse IP différente peut correspondre à une maintenance. Un signal de phishing nouveau peut justifier de revoir les accès. La disparition d’un signal demande, elle aussi, une validation.

Commencer par une référence exploitable

Choisissez le nom d’hôte exact. connexion.example et support.connexion.example désignent deux périmètres distincts. Si le signal porte sur une URL précise, gardez également son chemin : élargir directement à tout le domaine peut affecter des usages sans rapport.

Pour chaque élément surveillé, consignez dans votre outil de suivi :

• Nom d’hôte et usage : quel service serait touché par une restriction ?
• Responsable métier : qui peut confirmer une migration ou un incident fournisseur ?
• Source et motif du signal : que reproche-t-on exactement au domaine ?
• Date de consultation : quand votre équipe a-t-elle obtenu ce résultat ?
• Date d’observation publiée : à quelle période la preuve se rapporte-t-elle ?
• Décision et prochaine revue : pourquoi l’usage est-il autorisé, restreint ou en enquête ?

Séparez ces deux dates. Une information récupérée ce matin peut décrire une activité ancienne. Une source sans date d’observation reste utilisable, mais cette limite doit accompagner la décision. L’historique des rapports permet de retrouver les indicateurs consultés. Conservez les preuves datées et vos motifs métier dans votre dossier de suivi.

Comparer le même signal, dans le même périmètre

Un changement de réputation peut venir d’une nouvelle observation, d’une correction par une source ou d’une différence de couverture entre deux consultations. Avant de parler de dégradation, vérifiez que vous comparez le même nom, le même type d’indicateur et la même source.

« Aucune détection disponible » et « analyse rassurante » sont deux constats différents. De même, une source absente du second résultat n’est pas nécessairement une source ayant retiré son signal. Recherchez un statut explicite ou une nouvelle consultation réussie.

Lorsque le renseignement est fourni en STIX, les champs valid_from, valid_until et revoked aident à interpréter sa période de validité et son retrait par le producteur. Ils ne prouvent pas l’état actuel d’un site. Ces distinctions sont définies dans la spécification STIX 2.1 d’OASIS.

Séparer évolution DNS et signal de menace

Une réponse DNS différente mérite d’abord une question technique. Le service a-t-il migré ? Utilise-t-il plusieurs adresses ? Le résolveur et l’heure de consultation sont-ils comparables ? Le TTL encadre la durée pendant laquelle un enregistrement peut être mis en cache, ce qui contribue aux écarts entre observations. Voir la définition des enregistrements DNS dans la RFC 1035.

L’adresse obtenue n’identifie pas toujours le serveur d’origine. Par exemple, les enregistrements proxifiés de Cloudflare renvoient des adresses anycast partagées de son réseau. Ce fonctionnement est décrit dans la documentation sur le statut proxy. Une mauvaise réputation associée à une telle IP demande donc de vérifier le nom d’hôte concerné et la preuve disponible.

Gardez une trace des changements approuvés : intervalle de maintenance, fournisseur attendu et personne ayant confirmé. Cette information permet de classer une évolution sans créer une exception permanente. Une maintenance validée mardi ne justifie pas tous les changements futurs du domaine.

Cette tâche diffère aussi de la découverte de nouveaux domaines ressemblant à votre marque. Si c’est votre objectif, le guide de surveillance de l’usurpation de marque détaille la recherche de candidats et leur validation.

Une chronologie qui conduit à des actions différentes

Prenons portail-fournisseur.example, utilisé pour consulter des factures. Les observations suivantes sont fictives et décrivent une méthode d’équipe, pas une mesure ni une promesse de détection automatique.

Exemple fictif. Chaque observation appelle une vérification adaptée ; la chronologie ne représente aucun score mesuré.

J0 : établir la référence. L’équipe conserve le renseignement disponible, les réponses DNS et l’heure. L’usage métier et le responsable du fournisseur sont connus. Aucun signal présent dans les sources consultées ne justifie une restriction à cette date.

J1 : une nouvelle IP apparaît. Le fournisseur confirme une migration correspondant à la plage de maintenance prévue. L’analyste joint cette confirmation et actualise la référence DNS. Il conserve la surveillance, sans qualifier la migration d’incident.

J3 : un nouveau signal de phishing est publié. L’analyste vérifie s’il concerne ce portail, une URL particulière ou un autre hôte du domaine. Il recherche les accès dans les journaux de son organisation et contacte le fournisseur par un canal déjà connu. Les résultats déterminent le périmètre et l’urgence d’une éventuelle restriction.

J4 : le signal est retiré. L’équipe vérifie le retrait et les autres observations avant de revenir sur une restriction. Une correction de source, une remédiation du site et une erreur de collecte peuvent produire des résultats différents, même si la ligne rouge a disparu de l’écran.

Écrire les critères avant la prochaine alerte

Une règle utile associe un changement, une preuve à obtenir et une action. « Surveiller les changements » ne suffit pas à guider la personne qui prend le relais.

• Nouveau signal de phishing sur un hôte utilisé : vérifiez la source, l’URL concernée et les accès internes pour déterminer le périmètre à restreindre et l’enquête à ouvrir.
• Nouvelle IP sans autre signal : vérifiez la maintenance et l’infrastructure attendue, puis actualisez la référence ou demandez une explication.
• Source inaccessible : contrôlez l’état de la collecte. Marquez l’observation incomplète et recontrôlez-la.
• Retrait explicite d’un signal : examinez le motif du retrait et les preuves restantes avant de réévaluer une restriction existante.

Fixez la fréquence de revue selon l’usage et la capacité de réponse. Un service essentiel utilisé chaque jour et un domaine conservé pour une enquête ancienne n’ont pas le même besoin. Désignez aussi un remplaçant : une alerte reçue pendant une absence reste une action sans responsable si personne ne reprend la surveillance.

Utiliser la surveillance sans lui attribuer toutes les preuves

isMalicious permet de suivre des domaines et de consulter les évolutions du renseignement disponible parmi les éléments surveillés. Les confirmations de maintenance, journaux d’accès et comparaisons DNS décrits ici constituent les pièces complémentaires de votre enquête. Le workflow Alertes et Centre d’actions explique comment organiser le traitement.

Pour appliquer cette méthode, ouvrez un rapport de domaine, examinez les preuves puis ajoutez le domaine à la surveillance lorsque l’option est proposée. Notez dès cet instant quel changement vous ferait agir, qui le vérifierait et sur quelles preuves la décision reposerait.