Achats de threat intelligence : guide du secteur public

Un achat de threat intelligence dans le secteur public doit décrire un service que l’institution pourra tester, exploiter et quitter. Un catalogue de millions d’indicateurs ne démontre pas qu’un analyste pourra expliquer un résultat, qu’un SOC mutualisé aura le droit de le redistribuer ou qu’une correction atteindra les systèmes qui utilisent une appréciation erronée.

Ce guide propose des critères d’évaluation technique pour les institutions britanniques et européennes. Il ne constitue pas un ensemble de clauses obligatoires. Les exemples sont fictifs. Les responsables achats, sécurité, gouvernance de l’information et affaires juridiques doivent adapter ces critères à leur institution et à sa procédure.

Les recommandations de base de l’ENISA pour les achats numériques, publiées en 2017, abordent la sécurité pendant le cycle de vie du service acheté. Elles fournissent un contexte technique, pas un état du droit actuel. Les fiches et tests CTI ci-dessous constituent notre méthode proposée.

Définir le service avant de demander des offres

Précisez qui consommera le renseignement et quels traitements seront autorisés. Une collectivité examinant les signalements de phishing de ses agents n’a pas les mêmes besoins qu’un service mutualisé distribuant des listes de blocage à plusieurs institutions. Un besoin unique et vague masque des différences de droits, de délais et de responsabilité.

Dans notre exemple fictif, un SOC mutualisé enrichit des alertes sur des domaines et adresses IP pour trois organismes publics. Les analystes examinent les résultats avant tout changement réseau. Le fournisseur reçoit des indicateurs autorisés par API. Il ne reçoit pas les dossiers d’incident complets et ne décide pas quelle connexion interrompre.

Nommez chaque organisme participant, son opérateur et les systèmes consommateurs. Un SOC externalisé, une collectivité voisine et un prestataire temporaire de réponse à incident constituent des destinataires différents. Leur inclusion doit être explicite, sans être déduite du seul mot partenariat.

Utilisez le cahier de PIR et de plan de collecte pour clarifier une décision encore floue. Conservez ensuite les usages, les données autorisées, les horaires d’exploitation et le responsable du service. Ils déterminent quelles promesses commerciales méritent une vérification.

Rédiger des exigences qui permettent de trancher

Remplacez les adjectifs comme exploitable ou complet par un comportement attendu et une preuve. Demandez la signification du verdict, ses observations justificatives, ses dates et son mécanisme de correction. Deux notes sur cent ne deviennent pas comparables si leurs méthodes restent différentes ou inconnues.

Une fiche d’exigence proposée peut prendre cette forme :

Référence : CTI-07
Besoin : identifier une modification d’appréciation sur un domaine
Comportement attendu : identifiant stable, date d’appréciation,
statut courant et mécanisme de correction
Preuves fournisseur : schéma, exemples, procédure de correction
Recette : récupérer un enregistrement de test avant et après correction
Résultat attendu : le consommateur détecte et consigne la modification
Responsable : équipe d’intégration SOC
Réserve : limite, conséquence, propriétaire et date de réexamen

Cet exemple n’impose pas une architecture d’API. Un enregistrement de remplacement, un point de mise à jour ou un événement de retrait peuvent répondre au besoin si le consommateur sait les traiter. Décrivez le résultat nécessaire et demandez au candidat d’expliquer son mécanisme.

Séparez absence de preuve et contradiction. Une date d’observation manquante doit rester identifiable. Elle ne doit pas être remplacée discrètement par l’heure de récupération. Le guide sur l’évaluation des sources de threat intelligence développe les questions de provenance et de portée des conclusions.

Cartographier les données envoyées et reçues

Dessinez le parcours des données avant de qualifier l’intégration de peu risquée : client, connecteur, API, enrichissement amont, assistance, journaux, sauvegardes et rapports exportés. Une recherche peut révéler un intérêt d’investigation, même si l’indicateur interrogé est déjà visible publiquement.

Demandez si les valeurs soumises sont conservées, transmises, rendues consultables, utilisées pour améliorer les jeux de données ou intégrées aux résultats d’autres clients. Distinguez fonctionnement normal et dépannage. Un ticket d’assistance peut contenir bien plus d’informations que la requête API dont il traite.

Consignez où chaque catégorie est traitée et stockée, quelles organisations peuvent y accéder et quels changements nécessitent une information ou un accord selon le dispositif retenu. Une région d’hébergement ne répond pas seule aux questions sur l’assistance, les sous-traitants, les sauvegardes et les traitements secondaires.

Testez la minimisation avec un cas fictif. Pour rechercher la réputation d’un domaine, envoyer une URL complète avec référence de dossier et jeton d’accès peut exposer des données inutiles. Définissez ce que le connecteur retire, ce qu’il conserve pour l’enquête et où reste l’original. Le guide OPSEC et confidentialité des scans d’URL explique cette décision de soumission.

Prévoyez une voie distincte pour les éléments qui ne peuvent pas entrer dans le service. La commodité d’une API ne doit pas élargir silencieusement le périmètre de données approuvé.

Obtenir des réponses écrites sur les droits d’usage

Un jeu de données techniquement accessible n’est pas automatiquement autorisé pour tous les usages. Présentez au fournisseur des scénarios précis de traitement et de diffusion. Demandez une réponse rattachée à l’accord applicable. Les droits non résolus doivent rester visibles pendant l’évaluation.

Pour notre SOC mutualisé fictif, la fiche de droits doit notamment couvrir :

• l’ingestion automatisée et le cache local par l’opérateur ;
• l’affichage des preuves dans les dossiers de chaque organisme ;
• les alertes ou listes dérivées transmises aux organismes participants ;
• le partage de résultats avec un prestataire de réponse autorisé ;
• la conservation de pièces pertinentes après la fin de l’abonnement ;
• le retrait ou la séparation des données lorsqu’un membre quitte le dispositif.

Distinguez l’appréciation produite par le fournisseur des éléments issus de sources amont. Demandez quels droits il peut accorder, quelles restrictions sont transmises et comment une limite propre à une source apparaît dans les exports. Une formule générale sur la plateforme peut masquer plusieurs licences différentes.

Faites également expliquer comment le fournisseur établit son autorisation à collecter et fournir les données proposées. Visibilité publique, possibilité technique d’accès et droit de redistribution sont des questions distinctes. Une origine juridique incertaine doit devenir un sujet d’achat attribué à un responsable, sans être laissée à l’interprétation du développeur du connecteur.

Les consignes de diffusion doivent suivre les exports. Le guide du partage TLP traite ces périmètres ; les droits contractuels du service nécessitent leur propre suivi. Vérifiez comment les instructions sont conservées lorsqu’un analyste copie un résultat dans un ticket.

Relier les preuves fournisseur au service acheté

Le guide d’évaluation de la chaîne d’approvisionnement du NCSC s’adresse aux équipes achats, risques et sécurité. Il propose une démarche d’assurance dans la durée, au-delà du questionnaire initial.

Construisez les demandes de preuve autour du service prévu. Elles peuvent porter sur l’architecture, les accès administratifs, la gestion d’incident, le périmètre d’évaluation, les corrections en attente et la séparation des clients. Rattachez chaque document à une affirmation. Une politique décrit un processus attendu ; un test récent et délimité apporte une autre preuve de sa mise en œuvre. Pour les interventions de support, la procédure d’accès distant des prestataires précise personne, tâche, périmètre et durée.

Pour une certification ou un rapport d’évaluation, vérifiez organisation, service, date, périmètre et exclusions. Si l’API achetée se trouve hors du système évalué, la preuve ne s’y étend pas automatiquement. Demandez comment les constats importants sont suivis et qui accepte les risques restants.

Identifiez les dépendances pouvant interrompre ou modifier le service : hébergeur, plateforme d’identité, source essentielle ou équipe d’assistance externalisée. Le but est d’en comprendre les conséquences et l’escalade, sans exiger une description illimitée de toutes les relations commerciales.

Classez les affirmations comme étayées, partiellement étayées ou non étayées. Une réponse commerciale assurée ne remplace pas une pièce absente. Chaque point ouvert doit conduire à une suite explicite : preuve complémentaire, condition avant recette, réduction du périmètre ou rejet selon la procédure annoncée par l’acheteur.

Préparer une recette incluant les cas de panne

Utilisez un consommateur de test isolé et des données approuvées. Convenez des résultats attendus avant la démonstration et maintenez les protections de production. Les exemples fournis par le candidat vérifient des mécanismes ; ils ne démontrent pas une couverture réelle des attaques.

Commencez par une récupération ordinaire. Vérifiez authentification, pagination, identifiants et interprétation des champs. Interrompez une collecte sur plusieurs pages, puis contrôlez sa reprise sans perte silencieuse ni multiplication des mêmes preuves. Conservez la configuration du test pour permettre sa reproduction.

Modifiez ensuite une appréciation de test. Son état précédent doit rester explicable et le nouvel état doit atteindre le consommateur. Si un retrait exige une resynchronisation complète, documentez cette dépendance et mesurez son exécution. Une correction visible dans le portail, mais absente du flux opérationnel, n’achève pas le parcours attendu.

Testez séparément un indicateur inconnu et une requête en échec. L’application locale doit distinguer absence de résultat, service indisponible et appréciation de faible risque. Une réponse HTTP positive ne prouve pas à elle seule que le renseignement demandé existe.

Examinez les droits d’accès avec des comptes de test autorisés. Si le service héberge des dossiers privés, vérifiez qu’un utilisateur d’un organisme ne peut pas consulter ceux d’un autre. Si cette donnée n’est jamais stockée, consignez cette limite plutôt que d’inventer un besoin d’isolement pour un jeu public commun aux abonnés.

Terminez par une notification de correction ou de panne. Elle doit atteindre le destinataire opérationnel réel et identifier la fonction concernée. Conservez résultat observé, défauts restants et décision de recette. Une capture du tableau de bord fournisseur ne prouve pas que le système consommateur a réagi comme convenu.

Organiser les interruptions et les changements

Précisez séparément disponibilité, fraîcheur et délai d’assistance. Une API peut répondre avec des données anciennes. Un prestataire peut accuser réception d’un ticket sans rétablir le service. Définissez le début et la fin de chaque mesure, ainsi que la partie capable de l’observer.

Convenez du comportement lorsque la fraîcheur dépasse la limite acceptée : garder des preuves datées pour l’enquête, suspendre de nouvelles importations ou imposer une revue humaine. La réponse dépend de l’usage. Remplacer automatiquement une politique de protection par une liste vide peut créer une autre défaillance.

Demandez comment sont annoncés les changements de champs, d’authentification, de quotas et de couverture amont. Prévoyez les changements urgents et les tests des évolutions planifiées. Nommez le responsable interne des connecteurs : un avis fournisseur ne réalise pas une mise à jour.

Les coûts et la valeur opérationnelle relèvent du benchmark de ROI des flux CTI. La recette vérifie que le service convenu fonctionne. Elle ne démontre pas que l’achat apporte une valeur suffisante.

Répéter la sortie pendant que le fournisseur est disponible

Le guide ANSSI sur l’externalisation, publié en 2010, propose d’exprimer les attentes de sécurité selon le contexte dans une démarche d’assurance. Il apporte une méthode, pas un modèle juridique actuel. L’exercice suivant est une proposition propre aux services CTI.

Choisissez un dossier représentatif et exportez les éléments que l’institution a le droit de conserver. Un autre analyste doit encore distinguer observation initiale, appréciation fournisseur, corrections, annotations locales et restrictions. Un fichier ne contenant que la dernière note de risque peut être lisible tout en étant insuffisant pour expliquer une décision passée.

Consignez les éléments impossibles à exporter ou à garder. Convenez du traitement des caches, identifiants de connecteur, tâches programmées, copies d’assistance et données détenues par les sous-traitants. Une suppression générale peut contredire un besoin convenu de conservation de preuve. Faites résoudre ce point par les responsables compétents avant la résiliation.

Nommez responsable de migration, dépendances, assistance nécessaire et coûts prévus. Répétez la révocation des accès après validation du chemin de remplacement. Demandez les preuves de clôture convenues. Consignez toute conservation résiduelle avec sa justification et sa condition de fin. Identifiez les copies avant l’exercice, pendant que leurs propriétaires peuvent répondre.

Remettre un dossier d’achat traçable

Présentez ensemble service proposé, exigences vérifiées, réserves et responsabilités d’exploitation. Reliez chaque résultat de recette à son exigence. Adéquation de sécurité, valeur économique et validation procédurale restent des décisions distinctes, avec les responsables appropriés.

Une note CTI orientée décision pour la direction permet d’exposer les arbitrages sans reproduire le dossier technique. Une réserve doit préciser l’inconnue, la personne acceptant sa conséquence et la date de réexamen.

Un rapport de réputation IsMalicious peut fournir une consultation d’indicateur pendant une évaluation autorisée. Appliquez les mêmes exigences de preuve, de traitement et de recette qu’aux autres candidats. Le dossier final doit permettre d’expliquer ce qui a été acheté, ce qui a été vérifié et comment l’institution réagira lorsque le service changera.