Comment concevoir des politiques de rétention intelligentes dans OpenCTI
Les politiques de rétention dans OpenCTI ne servent pas seulement à économiser de l'espace disque. Elles constituent un élément essentiel pour maintenir votre base de connaissances en threat intelligence efficace et pertinente. Sans elles, les analystes se noient dans des indicateurs obsolètes, des rapports non pertinents et des données de test qui créent du bruit et perturbent l'analyse.
Dans cet article, nous allons parcourir des idées pratiques pour concevoir des politiques de rétention dans OpenCTI, expliquer quand supprimer les données en toute sécurité, et mettre en évidence ce qui doit presque toujours être préservé, en particulier les connaissances liées aux incidents et les PIR (Priority Intelligence Requirements).
TL;DR
- Les politiques de rétention maintiennent votre plateforme de threat intelligence rapide et pertinente – sans elles, les analystes se noient dans des indicateurs obsolètes, des rapports périmés et des données de test qui ralentissent la recherche, la corrélation et la prise de décision.
- Six modèles de politiques prêts à l'emploi couvrent les besoins de nettoyage les plus courants : indicateurs de faible confiance, observables temporaires, threat intelligence publique obsolète, fichiers d'importation, workbenches abandonnés et rapports fermés non liés aux PIR.
- Excluez toujours les données liées aux incidents et aux PIR – ces connaissances ont un poids juridique, réglementaire et forensique et doivent être préservées indépendamment de leur âge ou de leur source.
- Commencez de manière conservative et utilisez le bouton « Vérifier » avant d'activer toute politique pour prévisualiser l'impact et vous aligner avec les équipes CTI, SOC, IR et juridiques avant toute suppression de données.
- OpenCTI n'est pas votre archive – pour le stockage à long terme ou réglementaire, déchargez les données plus anciennes vers un data lake et ne conservez que les connaissances opérationnellement pertinentes dans la plateforme.
Pourquoi les politiques de rétention sont importantes en threat intelligence
Les plateformes de threat intelligence ont tendance à croître rapidement. De nouveaux connecteurs, flux et rapports internes ajoutent constamment des millions d'observables et d'indicateurs, ainsi que des profils d'acteurs de menaces, d'intrusion sets et de campagnes potentiellement redondants. Si rien n'est jamais supprimé, les conséquences s'accumulent rapidement : la recherche et la corrélation ralentissent, les analystes passent plus de temps à filtrer le bruit qu'à trouver des signaux exploitables, et les coûts de stockage augmentent, particulièrement pour les déploiements on-premises de grande envergure.
Une stratégie de rétention bien structurée traite tous ces aspects à la fois. Elle préserve ce qui compte le plus (les renseignements liés aux incidents et de haute valeur), supprime ce qui est temporaire, de faible confiance ou qui n'est plus pertinent, et maintient la plateforme réactive et utilisable pour les analystes comme pour les dirigeants.
Ce qu'il faut considérer lors de la définition des politiques de rétention
Avant de se lancer dans les règles techniques, alignez-vous sur ce qui a vraiment de la valeur pour votre organisation. Les candidats les plus courants au nettoyage sont les observables ou indicateurs avec une faible confiance ou sans labels significatifs, les indicateurs qui comportent un faible risque ou qui ont été révoqués par des règles de decay, les rapports non liés aux Priority Intelligence Requirements ou aux principaux acteurs de menaces, et les intrusion sets ou acteurs de menaces non pertinents pour votre secteur, vos clients ou votre région.
À partir de là, vous pouvez implémenter des politiques de rétention concrètes dans OpenCTI.
Voici six exemples que vous pouvez adapter :
1. Nettoyage des indicateurs de faible confiance
Portée : Knowledge | Rétention : 365 jours | Filtres : Type d'entité : Indicator – Niveau de confiance : moins de 50 – Score : moins de 20
Tous les indicateurs n'ont pas la même valeur. Les indicateurs de faible confiance et de faible score sont souvent bruités et éphémères. S'ils ne sont pas mis à jour ou renforcés par de nouvelles preuves, ils deviennent rapidement encombrants. Une fenêtre de 365 jours vous donne suffisamment de temps pour observer leur utilité ; après cela, s'ils n'ont pas été enrichis ou référencés, ils peuvent être supprimés en toute sécurité. Cette politique aide à garantir que les analystes restent concentrés sur des signaux de meilleure qualité et mieux validés.
Note : Le nombre de jours de rétention dans tous les exemples peut varier selon les réglementations et processus internes de votre organisation.


2. Nettoyage des observables temporaires
Portée : Knowledge | Rétention : 90 jours | Filtres : Type d'entité : Observable (IPv4, Domain, URL) – Labels : temporary ou test (exemple)
Pendant les investigations, les tests ou les activités de POC, les équipes créent souvent des observables qui servent à des fins de triage ou de validation mais qui n'étaient jamais destinés à faire partie de la base de connaissances à long terme. En les étiquetant de manière cohérente (par exemple comme temporary ou test) et en appliquant une règle de rétention de 90 jours, vous donnez aux analystes suffisamment de temps pour terminer leur travail tout en empêchant les données jetables de polluer la plateforme. C'est une habitude simple qui s'avère rapidement payante, à condition que l'utilisation des labels soit appliquée dès le départ.
3. Threat intelligence obsolète (non liée aux PIR/incidents)
Portée : Knowledge | Rétention : 365 jours (extensible à 3-5 ans selon les besoins de conformité) | Filtres : Type d'entité : Intrusion Set, Threat Actor, Campaign, Malware – Marquage : TLP:WHITEou TLP:CLEAR – Exclure : tout ce qui est lié aux Incidents ou aux PIR
Le renseignement d'origine publique sur des campagnes ou des familles de malwares est utile pour l'analyse de tendances mais devient moins opérationnel avec le temps. Pour de nombreuses organisations, conserver ce type d'informations de haut niveau au-delà des exigences de conformité offre une valeur limitée lorsqu'il n'est pas lié à un incident actif ou à un PIR. L'élément critique de cette politique est l'exclusion : toute entité liée à un incident ou à un PIR ne doit jamais être touchée, car ces données portent généralement un poids juridique, réglementaire et forensique et peuvent être nécessaires des années plus tard. Pour tout le reste, une valeur par défaut d'un an établit un équilibre raisonnable entre contexte historique, conformité réglementaire et évitement de l'accumulation sans fin de renseignements publics génériques que personne n'utilise activement.
4. Nettoyage des fichiers d'importation
Portée : File | Rétention : 365 jours (valeur par défaut OpenCTI) ou plus court (7-30 jours, selon vos besoins)
Les fichiers d'importation sont précieux pendant l'ingestion, le dépannage ou les audits — mais une fois importés et validés avec succès, les organisations ont rarement besoin de les conserver à long terme dans OpenCTI. Un nettoyage limité dans le temps libère de l'espace de stockage, réduit l'encombrement dans la section de gestion des fichiers et limite le risque de conserver des fichiers bruts sensibles plus longtemps que nécessaire. Si vous opérez sous des exigences d'audit strictes, alignez cette période avec ces attentes ou exportez les fichiers vers une archive contrôlée avant suppression.
5. Nettoyage des workbenches
Portée : Workbench | Rétention : 60 jours
Les workbenches sont des espaces collaboratifs puissants, mais beaucoup sont créés pour des tâches éphémères, valider des données nouvellement importées, trier une piste, puis simplement abandonnés. Une fenêtre de rétention de 60 jours pour les workbenches non touchés maintient l'interface propre et concentrée sur le travail actif, encourage les analystes à incorporer correctement les objets dans des cas, incidents ou rapports plutôt que de les laisser dans les limbes, et réduit la confusion dans les environnements partagés où plusieurs analystes travaillent en parallèle.


6. Rapports non liés aux incidents/PIR
Portée : Knowledge | Rétention : 2-3 ans | Filtres : Type d'entité : Report – Type de rapport : News – Statut : Closed – Exclure : rapports liés aux Incidents, Cases ou PIR
Les rapports de type actualités sont des instantanés d'un moment donné. Ils soutiennent la conscience situationnelle et la communication, mais leur pertinence opérationnelle s'estompe à mesure que le paysage des menaces évolue. Conserver les rapports d'actualités fermés et non liés aux incidents pendant deux à trois ans établit un équilibre raisonnable : suffisamment long pour soutenir l'analyse des tendances et la référence historique, suffisamment court pour empêcher le contenu périmé de s'accumuler indéfiniment. Comme pour les autres politiques, les rapports liés aux incidents doivent être préservés au-delà de cette fenêtre chaque fois que les politiques internes ou les obligations légales l'exigent.
Étapes critiques lors de l'implémentation des politiques de rétention
Commencez de manière conservative et utilisez « Vérifier »
Lors de la définition de politiques de rétention dans OpenCTI, commencez toujours par des périodes conservatrices. Utilisez le bouton « Vérifier » avant l'activation pour voir exactement quelles données seraient affectées. Cela vous donne l'opportunité de valider vos hypothèses avec les équipes CTI, SOC, IR et juridiques, d'éviter les suppressions accidentelles de données précieuses ou réglementées avant qu'elles ne se produisent, et d'affiner les filtres et les périodes de rétention de manière sûre et réversible.
Décharger vers un data lake pour le stockage à long terme
La rétention dans OpenCTI doit privilégier la pertinence opérationnelle et la performance, elle n'a pas besoin d'être votre archive éternelle. Pour le stockage à long terme ou réglementaire, envisagez d'exporter les données plus anciennes vers un data lake ou un système d'archivage séparé, de ne conserver que les connaissances essentielles et actives dans OpenCTI, et de vous assurer que les équipes de conformité et d'audit savent exactement où se trouvent les données historiques complètes. Cette approche vous permet de satisfaire les exigences de rétention strictes sans dégrader la convivialité de la plateforme.
Préserver les connaissances liées aux incidents et de haute valeur
Un principe devrait guider chaque politique que vous concevez : protéger les données liées aux incidents et le renseignement de haute valeur. Lors de la construction de filtres, prenez toujours en compte les incidents et toutes les entités qui leur sont liées, le renseignement lié aux PIR, et les données conservées pour des obligations juridiques, réglementaires ou contractuelles. Votre stratégie de rétention doit être agressive pour nettoyer le bruit tout en restant très prudente concernant tout ce qui est lié à des compromissions réelles, des enquêtes actives, des PIR ou des décisions critiques pour l'entreprise.
Conclusion et prochaines étapes
Des politiques de rétention bien conçues dans OpenCTI vous aident à maintenir votre environnement propre, performant et concentré sur ce qui compte vraiment : du renseignement sur les menaces de haute qualité et exploitable qui soutient vos opérations et besoins de conformité. Dans cet article, nous avons couvert comment nettoyer les indicateurs de faible confiance et les observables temporaires, gérer le renseignement public sur les menaces obsolète, traiter les fichiers d'importation et les workbenches périmés, et contrôler la durée de vie des rapports non liés aux incidents et aux PIR.
J'espère que cela vous aidera à structurer ou affiner votre propre stratégie de rétention. Si vous voulez aller plus loin, rejoignez notre communauté Slack pour échanger avec d'autres utilisateurs OpenCTI sur la façon dont ils gèrent la rétention et le cycle de vie des données, et explorez notre documentation et articles de blog connexes sur la modélisation des données OpenCTI, la gestion des incidents et les stratégies de connecteurs pour construire une pratique CTI durable de bout en bout.
Profitez-en et n'hésitez pas à poser des questions à ce sujet sur notre channel Slack communautaire !
Lire la suite
Explorez des sujets et analyses associés
Votre SOC n'a pas de problème de données. Il a un problème de coordination.

Workflows d'approbation de l'intelligence : garantir la qualité des données et rationaliser les processus
