Historique des rapports : revérifier, surveiller et réutiliser les preuves
Utilisez l’historique isMalicious pour retrouver les recherches précédentes, relancer une vérification, surveiller un indicateur, créer un dossier et exporter un index réutilisable.

Les preuves de menace évoluent. Un domaine peut changer d’infrastructure, une IP être réattribuée, une URL disparaître et un hash recevoir de nouvelles détections après la première recherche. La question utile n’est donc pas seulement « qu’avons-nous vu ? », mais aussi « qu’est-ce qui a changé et quelle décision suit ? »
L’espace Rapports d’isMalicious donne une suite opérationnelle aux recherches précédentes. Filtrez l’historique, relancez une vérification, ajoutez une entité compatible à la surveillance, créez un dossier ou exportez un index pour l’analyse et la conservation.
Le NIST SP 800-61 Rev. 3 relie l’efficacité de la détection, de la réponse et de la reprise à la gestion du risque cyber. Un historique interrogeable soutient ce lien en permettant de reprendre les preuves au lieu de reconstruire une enquête de mémoire.
Traiter l’historique comme un index d’enquête
Le tableau des Rapports conserve la cible, le type d’entité résolu et la date de recherche. Il faut le considérer comme un index de l’activité analyste, pas comme un remplacement du rapport complet ou un coffre de preuves forensiques.
Le filtre permet de répondre à des questions concrètes :
- Avons-nous déjà vérifié ce domaine ou cette IP ?
- Quand a eu lieu la dernière recherche ?
- Quel type d’entité le produit a-t-il résolu ?
- Existe-t-il déjà un chemin d’enquête associé ?
- Quels enregistrements faut-il revérifier ou exporter ?
C’est plus rapide et plus sûr que de parcourir l’historique du navigateur, des fils de discussion ou des notes personnelles. L’analyste suivant dispose aussi d’un point de départ partagé.
Utiliser Revérifier pour obtenir des preuves actuelles
L’action Revérifier ouvre une nouvelle recherche pour la cible choisie. La distinction est importante. La date d’origine indique le moment de la première enquête ; le nouveau rapport montre ce qui est visible maintenant.
Comparez notamment :
- l’évolution du verdict ou du niveau de risque ;
- l’apparition de nouvelles sources détectant l’entité ;
- les changements d’enregistrement, d’hébergement ou de résolution ;
- l’apparition d’infrastructures liées ;
- le recoupement actuel avec l’actif ou l’incident concerné.
Ne réinterprétez pas une ancienne décision avec de nouvelles preuves sans conserver la chronologie. Notez que la conclusion a changé et précisez l’observation responsable.
Pour un indicateur inconnu copié depuis un message ou une alerte, commencez par la Recherche intelligente. Si l’événement contient plusieurs indicateurs liés, gardez leur périmètre visible dans un rapport composite.
Surveiller uniquement lorsque le changement compte
L’action Surveiller permet d’ajouter une entité compatible à la surveillance. Utilisez-la lorsqu’une évolution future modifierait une décision réelle, par exemple :
- un domaine suspect lié à une enquête de phishing ouverte ;
- une IP qui communique avec un actif critique ;
- l’infrastructure d’un fournisseur en cours d’examen ;
- un indicateur associé à une campagne récurrente ;
- une entité encore inconnue mais à fort impact.
Évitez de surveiller chaque cible recherchée. Une liste d’éléments surveillés sans motif devient un nouveau flux bruyant. Définissez le déclencheur avant l’ajout : changement de verdict, nouvelle détection, nouvelle infrastructure ou échéance de réévaluation.
Examinez les entités surveillées dans les Alertes, puis priorisez les changements exploitables dans le Centre d’actions.
Créer un dossier lorsque le travail s’étend
L’action Dossier crée une enquête liée à l’entité du rapport et y ajoute une preuve issue du rapport. C’est le bon choix lorsqu’une recherche unique ne suffit plus.
Passez dans les Dossiers lorsque vous avez besoin :
- d’une enquête nommée avec une priorité ;
- de plusieurs preuves ;
- d’une chronologie des décisions ;
- d’un travail partagé entre plusieurs personnes ;
- d’un résultat qui doit survivre au changement d’équipe.
Posez une question précise. « Enquêter sur example.com » est un début. « Déterminer si example.com a diffusé la page de vol d’identifiants signalée au support et identifier les utilisateurs touchés » donne un périmètre et une condition de sortie.
Exporter un index réutilisable
Les offres compatibles peuvent exporter l’historique en CSV ou JSON depuis le tableau. L’export reste volontairement compact : identifiant du rapport, cible, type d’entité et horodatage de création.
Utilisez CSV lorsqu’un analyste doit trier, filtrer ou rapprocher l’index dans un tableur. Utilisez JSON lorsqu’un script, un notebook ou un workflow interne doit le lire. Comme l’export est un index et non le contenu complet du rapport, récupérez ou revérifiez le rapport avant toute décision actuelle sur la menace.
Le guide de l’API isMalicious explique comment automatiser les nouvelles recherches. Pour un ensemble plus large, suivez le guide de recherche en masse au lieu d’ouvrir manuellement chaque ligne historique.
Installer une revue hebdomadaire des preuves
Une revue courte maintient l’utilité de l’historique :
- Filtrez les indicateurs liés aux incidents actifs et fournisseurs prioritaires.
- Revérifiez les enregistrements dont les preuves changent vite.
- Ajoutez seulement les entités à forte valeur à la surveillance.
- Transformez les enquêtes qui grandissent en dossiers.
- Exportez l’index si une autre équipe ou un workflow en a besoin.
- Supprimez les enregistrements sans finalité opérationnelle selon votre politique de conservation.
Cette dernière étape est souvent oubliée. La conservation des preuves doit être intentionnelle. Gardez ce qui soutient une enquête, la conformité, un retour d’expérience ou un besoin de renseignement actif. Retirez ce qui n’a plus de finalité selon les règles de l’organisation.
Conserver les décisions, pas seulement des captures
Une capture d’écran fige une interface à un moment donné. Elle conserve rarement la requête, le type d’entité, le contexte des sources, la conclusion analyste et l’action ultérieure sous une forme réutilisable.
L’historique fournit le chemin de récupération. Un nouveau rapport apporte les preuves actuelles. La surveillance détecte les changements. Les dossiers conservent l’enquête durable. Ensemble, ces fonctions permettent de reprendre une cible sans perdre la raison de son importance initiale.
Questions fréquentes
- Que contient l’historique des rapports isMalicious ?
- Il liste les indicateurs vérifiés, leur type résolu et la date de recherche. Vous pouvez filtrer l’historique puis revérifier l’entité, la surveiller, créer un dossier ou supprimer l’entrée.
- Le bouton Revérifier renvoie-t-il l’ancien résultat ?
- Non. Il lance une recherche actuelle sur l’entité choisie. Conservez la date d’origine comme contexte historique et comparez les nouvelles preuves avant de modifier une décision.
- Puis-je exporter mon historique ?
- Les offres compatibles peuvent exporter l’index depuis le tableau en CSV ou JSON. L’export contient l’identifiant du rapport, la cible, le type d’entité et la date de création, pas tous les champs de chaque rapport complet.
- Quand ajouter un indicateur aux éléments surveillés ?
- Surveillez une entité lorsque ses changements futurs comptent pour une enquête, un actif exposé, un fournisseur ou un besoin de renseignement défini. Évitez de surveiller chaque recherche ponctuelle.
- Quand un rapport historique doit-il devenir un dossier ?
- Créez un dossier lorsque le résultat exige une enquête coordonnée, plusieurs artefacts, une chronologie durable ou une responsabilité qui dépasse une recherche analyste.
Related articles
Smart Lookup : vérifier tout indicateur depuis une rechercheCollez une IP, un domaine, une URL, un email, un téléphone, un wallet, un hash ou un message suspect complet. Smart Lookup ouvre le bon rapport de menace.
Alertes et Centre d’actions : construire un workflow de réponsePassez des indicateurs surveillés et alertes reçues à une file priorisée, une validation analyste et des actions attribuées avec les Alertes et le Centre d’actions isMalicious.
- CVE-2026-9198 : RCE non authentifiée sur les plans de contrôle d'agents IBM Langflow OSS
Un jeton SUPERUSER obtenu via /api/v1/auto_login s'enchaîne avec exec() Python dans /api/v1/validate/code. Langflow 1.10.1 corrige la faille — mais les instances exposées sur Internet exigent une recherche immédiate, pas après le prochain sprint.
Protégez votre infrastructure
Confrontez n’importe quelle IP ou n’importe quel domaine à notre base de renseignement et à ses enregistrements indexés.
Essayer le vérificateur d’IP et de domaines