Définir des PIR en threat intelligence : modèle et collecte

Un PIR, ou Priority Intelligence Requirement, transforme une attente de renseignement en question à résoudre pour une décision précise. « Suivre les ransomwares » donne un thème. « Quels accès de nos prestataires devons-nous revoir avant la prochaine période de maintenance ? » ouvre un travail dont on peut définir le destinataire, les preuves et la fin.

Dans une discussion Reddit du 11 septembre 2026, un analyste qui rejoint une fonction CTI demande ce que son nouveau travail recouvrira au quotidien. Les réponses évoquent notamment les besoins des équipes destinataires. Ce fil illustre une difficulté de cadrage ; il ne mesure pas les pratiques de toute la profession.

Le registre proposé ici sert à résoudre cette difficulté. Vous pouvez le tenir dans un document partagé ou dans votre outil de tickets. Sa qualité dépend surtout de ce qu’il permet de décider et de ce qu’il vous autorise à ne plus collecter.

Commencer par la décision que quelqu’un devra prendre

Organisez un entretien avec le destinataire avant d’ouvrir de nouvelles sources. Demandez-lui de raconter un arbitrage récent : une exception acceptée, un accès conservé, un contrôle retardé ou une recherche lancée trop tard. Relevez le moment où une information supplémentaire aurait changé son choix.

Cette approche rejoint le CTI-CMM, qui structure la progression d’une fonction CTI autour du soutien apporté à ses clients internes. Le modèle ne remplace pas vos entretiens : un responsable fraude, une équipe de détection et une direction juridique n’attendent pas les mêmes réponses.

Pour chaque entretien, notez quatre éléments dans les mots du demandeur : la décision, les options encore ouvertes, le dernier moment utile et les conséquences d’une erreur. Si la décision est déjà prise et irréversible, une étude de contexte peut rester intéressante, mais elle ne mérite pas automatiquement une place dans la file des PIR actifs.

Un responsable peut demander « une veille quotidienne sur les acteurs qui nous ciblent » sans pouvoir nommer une action associée. Reformulez avec lui : veut-il choisir des scénarios de chasse, réexaminer un fournisseur, préparer un exercice ou modifier une règle d’accès ? Cette précision rend ensuite le travail plus simple à déléguer.

Écrire une question assez étroite pour être résolue

Un PIR utile contient une cible, un horizon et un lien avec l’action. Évitez les questions qui supposent déjà leur réponse. « Comment démontrer que ce prestataire est dangereux ? » commande une confirmation. « Quels éléments justifient de modifier ses accès, et lesquels soutiennent leur maintien ? » permet un examen contradictoire.

Le curriculum PIR de FIRST insiste sur un nombre limité de besoins, leur évolution avec la situation et la participation des parties prenantes. Le modèle ci-dessous est une proposition pratique pour appliquer ces principes en entreprise, sans reproduire un dispositif militaire.

Comparez ces formulations :

• Trop large : quelles menaces concernent notre secteur ?
• Encore imprécise : quels groupes attaquent nos prestataires informatiques ?
• Exploitable : quelles pratiques d’accès distant de nos prestataires permettent les techniques observées dans les campagnes retenues, et quelles exceptions faut-il revoir avant la maintenance ?

La dernière question exige une observation extérieure et une vérification intérieure. Elle peut recevoir une réponse partielle honnête : les campagnes sont documentées, mais l’inventaire des accès ne permet pas encore de trancher. Le PIR fait alors apparaître un manque de données au lieu de le masquer derrière un rapport général.

Pour situer ce travail parmi les autres livrables, le guide des niveaux de threat intelligence décrit les destinataires. Le registre, lui, doit rester attaché à une décision réelle.

Utiliser une fiche PIR qui tient sur un écran

Voici un modèle original à adapter. Les champs « inconnues » et « critères d’arrêt » font partie du travail attendu, même lorsque le commanditaire préférerait une réponse immédiatement certaine.

Identifiant : PIR-ACCÈS-01
Question prioritaire :
Décision à soutenir :
Responsable de la décision :
Options encore possibles :
Périmètre inclus :
Périmètre exclu :
Dernière date utile :
Éléments nécessaires pour répondre :
Sources accessibles et propriétaires :
Principales inconnues :
Format de restitution :
Critères d’arrêt ou de suspension :
Conditions de réouverture :
Analyste responsable et prochaine revue :

Le périmètre exclu évite les extensions silencieuses. Une recherche sur les accès des prestataires n’inclut pas automatiquement tous leurs sous-traitants, toutes les filiales du groupe et l’ensemble des vulnérabilités de leurs produits. Chaque extension consomme du temps et peut changer les autorisations nécessaires.

La dernière date utile n’est pas une simple échéance administrative. Une conclusion livrée après le gel des changements n’aide plus à décider des modifications de la semaine. Elle peut encore soutenir la surveillance ou la prochaine fenêtre, à condition de renégocier explicitement le livrable.

Conservez aussi le nom du responsable de la décision. « La direction » ou « le SOC » ne suffit pas lorsque deux équipes ne s’accordent pas sur les conséquences d’une restriction. L’analyste produit le jugement ; un propriétaire identifié arbitre les options.

Décomposer le PIR en besoins de preuve

Une bonne question ne fournit pas directement une requête de recherche. Décomposez-la en éléments observables, puis associez chaque élément à une source qui a réellement la capacité de le connaître.

Pour notre exemple d’accès distant, la première branche concerne les campagnes : quelles techniques et quels prérequis sont décrits dans les rapports retenus ? La deuxième concerne l’exposition locale : quels comptes, passerelles et exceptions permettent ces prérequis ? La troisième concerne la décision : quels services dépendent de ces accès et quelles solutions de remplacement existent ?

Un rapport de menace peut informer la première branche. Il ne prouve pas qu’un compte interne dispose d’une permission. Inversement, un export de configuration décrit un accès sans montrer que la technique associée est actuellement utilisée par un adversaire. Ne faites pas remplir à une source le rôle d’une autre.

Avant d’ajouter un abonnement, examinez les sources de threat intelligence et leurs preuves. Le principe C1 du Cyber Assessment Framework du NCSC relie le choix des sources aux besoins métier et au secteur. Dans votre fiche, traduisez ce principe en une question vérifiable : quelle partie du PIR cette source peut-elle réellement éclairer ?

Construire le plan de collecte avant de lancer les requêtes

Le plan de collecte décrit une action, son produit attendu et son coût. « Consulter Internet » ne permet ni de suivre l’avancement ni d’expliquer pourquoi la recherche s’arrête. Préférez une fiche par besoin de preuve.

Besoin : identifier les conditions d’accès exploitées
Collecte : lire les rapports primaires sélectionnés
Sortie : technique, prérequis, date, source, limite
Responsable : analyste CTI
Budget initial : une session de recherche délimitée
Suite possible : demander une précision à la source
Arrêt : les prérequis nécessaires sont documentés

Dans une seconde fiche, l’équipe chargée des identités fournit un état daté des comptes de prestataires, de leur propriétaire et de leurs restrictions. Une troisième demande au responsable applicatif de préciser les contraintes d’exploitation. Le plan évite de laisser l’analyste découvrir au dernier moment qu’une information décisive n’était accessible qu’à une autre équipe.

Prévoyez les délais de réponse humaine. Une requête API prend peu de temps, mais l’approbation d’un accès aux journaux ou la validation d’un propriétaire peut immobiliser le dossier. Commencez tôt les demandes qui risquent de bloquer la conclusion, puis utilisez le temps restant pour les recherches indépendantes.

La collecte OSINT pour les analystes SOC fournit des familles de sources possibles. Le plan PIR sélectionne celles qui servent votre question et documente les angles qu’elles ne couvrent pas.

Exemple complet : examiner les accès d’un prestataire

Le cas suivant est fictif. Une entreprise prépare une maintenance de son système de commandes. Un prestataire intervient à distance. Le responsable d’exploitation doit choisir entre conserver les accès actuels, les restreindre à la fenêtre prévue ou reporter l’intervention.

Le PIR devient : « Les conditions d’accès du prestataire permettent-elles les techniques d’abus décrites dans les rapports retenus, et quelle option réduit l’exposition sans empêcher la maintenance ? » La décision porte sur ces accès, pour cette intervention. Elle ne cherche pas à attribuer une campagne ni à noter globalement le prestataire.

L’analyste relève les prérequis techniques des rapports. L’équipe identité confirme que certains comptes disposent d’un accès permanent. L’exploitation explique qu’un compte nominatif temporaire peut assurer la même tâche. Le SOC vérifie quelles traces permettraient d’examiner l’usage de ce compte. Tous ces éléments sont hypothétiques et servent uniquement à montrer la démarche.

La conclusion peut alors recommander une option sans déclarer le prestataire compromis : les accès permanents exposent une possibilité d’abus documentée ; une alternative opérationnelle existe ; les données disponibles ne prouvent pas une intrusion. Le responsable peut réduire une exposition sans attendre une attribution d’attaquant.

Si l’équipe identité ne fournit pas l’inventaire, la conclusion change. L’analyste décrit le manque et propose une action de vérification avant la fenêtre. Il ne remplace pas la configuration inconnue par celle d’une entreprise citée dans un rapport public. Le registre conserve la question ouverte et son propriétaire.

Définir des règles d’arrêt et de réouverture

Le risque d’un PIR permanent est de devenir un abonnement à la recherche. Définissez plusieurs fins possibles dès son ouverture.

Une clôture avec réponse signifie que le destinataire dispose des éléments convenus pour arbitrer. Une clôture devenue sans objet suit un changement de projet ou de périmètre. Une suspension conserve un besoin utile mais bloqué par une information inaccessible. Ces états doivent rester distincts dans vos bilans.

Ajoutez une règle de rendement de la collecte : si les nouvelles recherches répètent les mêmes sources sans réduire l’inconnue décisive, soumettez le choix de poursuivre au commanditaire. Deux heures supplémentaires consacrées à des articles dérivés ne remplacent pas le journal d’accès manquant. Le budget n’est pas une mesure de vérité, mais une contrainte à expliquer.

La réouverture doit suivre un événement défini : nouvelle technique pertinente, modification d’accès, changement de prestataire ou preuve locale contradictoire. Une publication simplement plus récente ne justifie pas toujours de relancer le dossier. Notez ce qu’elle change dans la décision avant de mobiliser à nouveau la collecte.

Restituer une réponse qui conserve les limites

La restitution reprend la question exacte, la réponse, les preuves déterminantes et la conséquence pour chaque option. Placez les observations brutes dans une annexe accessible. Le destinataire doit pouvoir lire la conclusion sans traverser votre journal de navigation, et retrouver les sources s’il souhaite la contester.

Séparez une absence d’activité détectée d’une absence de données. « Aucun événement pertinent dans les journaux disponibles » n’équivaut pas à « aucun abus possible ». Précisez la période couverte, les systèmes interrogés et les journaux manquants. Le guide de réutilisation des preuves d’un rapport aide à garder des éléments datés plutôt qu’une conclusion isolée.

Pour un destinataire exécutif, le modèle de note CTI pour la direction aide à transformer la réponse en choix explicite, avec les preuves qui le soutiennent.

Après l’arbitrage, demandez quel élément a compté et lequel était inutile. Si la décision aurait été identique sans le rapport, cherchez pourquoi : question trop tardive, options déjà fermées ou preuve sans rapport avec l’incertitude réelle. Ce retour permet de modifier les prochains PIR.

Tester le registre avec un seul besoin réel

Pour démarrer, choisissez une décision prévue prochainement et remplissez la fiche avec son responsable. Faites relire le plan de collecte par les équipes qui doivent fournir les données. Retirez les recherches dont la sortie ne peut influencer aucune option. Fixez enfin une revue avant la date limite.

Lorsqu’un PIR nécessite de contextualiser une IP ou un domaine, le guide du premier lookup IOC avec l’API IsMalicious peut aider à ajouter cet enrichissement au dossier. Conservez son résultat comme une preuve datée parmi les autres. La réponse au PIR reste une analyse des éléments pertinents pour la décision, avec ses inconnues et son propriétaire.