Expiration des IOC : quand retirer une IP bloquée ?

Une IP a été bloquée pendant un incident. Plusieurs semaines plus tard, un service légitime devient inaccessible et personne ne sait pourquoi la règle existe encore. L’expiration des IOC doit répondre à cette situation : décider si la preuve justifie toujours une action, avec une date de révision et une trace de la décision.

La question utile est précise : quel élément nous autorise à maintenir ce blocage, pour ce service et à cette date ? Un flux récent, une observation ancienne et une règle active peuvent coexister. Le consommateur doit les distinguer.

Trois horloges à ne pas confondre

Le TTL DNS concerne la durée de cache d’un enregistrement de résolution. Il ne mesure pas l’âge d’une menace. La RFC 8767 prévoit même des conditions de service de données expirées lorsque le rafraîchissement échoue. Une valeur DNS encore visible ne constitue donc pas une preuve de contrôle actuel de l’infrastructure par un attaquant.

L’âge de la preuve répond à une autre question : quand l’activité qui justifie le signal a-t-elle été observée ? Enregistrez cette date lorsqu’elle est fournie, et signalez son absence. L’heure de téléchargement du fichier doit rester une colonne distincte. Télécharger aujourd’hui une observation ancienne ne la rend pas récente.

La validité déclarée par le producteur est une troisième information. Dans STIX 2.1, section Indicator, valid_from commence la fenêtre de validité ; valid_until, facultatif, la termine. Son omission n’impose aucune borne de fin. Une politique locale de réévaluation reste nécessaire pour décider des actions.

Schéma de décision proposé. Les états décrivent une politique à mettre en œuvre dans votre environnement, pas une automatisation fournie par tous les flux.

Donner une date de révision à chaque décision

Un indicateur peut rester intéressant pour une enquête rétrospective alors que son blocage n’est plus justifié. Séparez la conservation des preuves, la recherche de correspondances dans les journaux et la prévention active. Ces usages n’ont pas les mêmes conséquences en cas d’erreur.

Avant de promouvoir une IP en règle de pare-feu, consignez au minimum :

• l’observable exact et sa source ;
• la preuve retenue, sa date et ses limites ;
• le contrôle destinataire, sa portée et son propriétaire ;
• la date de révision et les conditions de maintien ou de retrait.

Une règle sur une destination partagée mérite notamment une vérification au niveau du domaine ou du service. Le guide sur les faux positifs d’IP blacklistées explique comment éviter de généraliser une observation à tous les usages d’une adresse.

Préférez des conditions explicites à une durée choisie par habitude. « Maintenir pendant la réponse à l’incident, puis revoir avec le responsable » est contrôlable. « Garder parce que le fichier l’a toujours contenu » ne permet aucun arbitrage.

Traiter une mise à jour sans rajeunir artificiellement la preuve

À l’import, conservez séparément la version du renseignement, son heure de réception et les observations qu’il décrit. Une modification de description ou d’étiquette ne constitue pas, à elle seule, une nouvelle activité sur le réseau. La documentation de versionnement de la bibliothèque STIX d’OASIS montre notamment que modified évolue lors de la création d’une nouvelle version.

Cette distinction évite un défaut de politique : repousser la révision de toutes les règles à chaque téléchargement, même si aucun fait nouveau n’a été reçu. La date d’ingestion sert à surveiller le fonctionnement du connecteur. Le renouvellement d’un blocage doit renvoyer à un motif documenté.

Une révocation demande aussi un traitement explicite. revoked: true signale le retrait de validité par le producteur ; ce retrait est permanent pour l’objet STIX concerné. La spécification STIX, versionnement définit ce mécanisme. Dans la politique proposée ici, suspendez l’utilisation de cet objet comme justification active et réévaluez les règles qui en dépendent. Une autre preuve indépendante peut encore justifier un contrôle distinct.

Une disparition du flux n’est pas un verdict

Considérez cet exemple fictif : l’indicateur 192.0.2.44 figure dans une liste validée lundi. Mardi, le connecteur reçoit une réponse vide. Il manque une information décisive : a-t-il terminé une synchronisation comparable ?

Un filtre changé, une page omise, une collection différente ou un droit perdu peut expliquer l’absence. En TAXII, les réponses paginées doivent être parcourues jusqu’à leur terme ; la spécification TAXII 2.1 décrit notamment les propriétés more et next. Une comparaison de deux listes n’a de sens que si chacune représente le périmètre attendu.

Traitez donc deux décisions séparément. Si la synchronisation échoue, appliquez votre politique d’incident de flux, avec alerte et durée maximale acceptable de données anciennes. Si elle réussit et qu’un retrait est confirmé selon le contrat du fournisseur, ouvrez la réévaluation correspondante. Ne transformez pas automatiquement une erreur technique en autorisation d’accès.

Le guide d’intégration TAXII continue détaille les points de reprise. Le présent cycle commence après cette étape : il décide de l’usage des données reçues.

Retirer une règle avec une preuve de résultat

Dans notre exemple, l’équipe confirme ensuite un retrait du signal initial. Elle recherche d’autres justifications actives, vérifie les journaux récents et identifie tous les équipements où la règle a été déployée. Si plus aucune justification ne tient, elle retire le blocage concerné et garde la décision dans le dossier.

Vérifiez le résultat sur le système qui applique réellement la règle. Une entrée supprimée du référentiel central peut rester chargée dans un pare-feu, un proxy ou un résolveur. Comparez les versions déployées et testez le service légitime affecté, sans lancer une navigation vers une destination encore suspecte pour « voir ce qui se passe ».

Conservez l’ancienne version pour comprendre l’incident, mais protégez les retours arrière : restaurer une vieille liste ne doit pas réactiver aveuglément des justifications révoquées. Réappliquez les décisions de retrait et les exceptions encore valides lors de la reconstruction. Le guide des listes de blocage opérationnelles couvre les contrôles de déploiement et de restauration.

Pour commencer, choisissez une règle ancienne et reconstituez ses trois dates : observation, ingestion, prochaine révision. Consultez la réputation actuelle de l’IP, rapprochez-la de vos preuves locales et consignez la décision. Ce premier cas donne un modèle concret pour les règles suivantes.