Portfolio analyste CTI : construire un laboratoire hors ligne

Un portfolio d'analyste CTI doit permettre à une autre personne de vérifier comment vous passez d'informations imparfaites à une conclusion utile. Une capture d'écran d'outil ou une collection d'indicateurs montre peu de ce raisonnement. Un dossier limité, reproductible et correctement expliqué en montre davantage.

La question revient dans les parcours de reconversion. Dans un échange du 26 août 2026 sur r/threatintel, une personne issue de l'appsec cherche à constituer des travaux d'analyse. Les réponses suggèrent notamment de rendre visibles les compétences d'ingénierie et de rédaction. Ce sont des retours individuels, pas une garantie de recrutement.

Le laboratoire proposé ici fonctionne hors ligne, sur un corpus entièrement fictif. Vous n'avez besoin ni de malware actif, ni de compte sur un forum clandestin, ni de collecte sur des victimes. Vous allez produire des pièces qu'un lecteur peut examiner, contester et rejouer.

Choisir une compétence observable

« Apprendre la threat intelligence » est trop large pour un premier projet. Choisissez une capacité que le résultat permettra d'évaluer : formuler une question, préserver la provenance, distinguer deux hypothèses, relier plusieurs observations ou écrire une recommandation adaptée à un destinataire.

Le NICE Framework du NIST fournit un vocabulaire pour décrire tâches, connaissances et compétences en cybersécurité. Vous pouvez l'utiliser pour nommer ce que démontre un exercice, sans prétendre qu'un projet personnel valide à lui seul un rôle professionnel complet.

Notre objectif sera le suivant : à partir de trois flux fictifs et de journaux synthétiques, déterminer quelles alertes méritent une vérification supplémentaire. Le résultat attendu n'est pas « trouver toutes les attaques ». Il est de produire des décisions justifiées et d'identifier les cas que les données ne permettent pas de trancher.

La différence entre renseignement stratégique, tactique et opérationnel aide à choisir un destinataire cohérent avec cet objectif.

Construire un corpus pédagogique sans données de victimes

Créez une société imaginaire, deux postes fictifs et une petite période d'observation. Les noms ne doivent pas reprendre une véritable enquête de votre employeur. Une simple modification des noms laisserait parfois reconnaissables les dates, les relations ou les chemins de fichiers.

Pour les exemples de domaines, utilisez les noms réservés par la RFC 2606, notamment .example. Pour les adresses figurant dans vos documents, utilisez les blocs de documentation de la RFC 5737. Ces adresses sont des valeurs de jeu de données, pas des cibles à contacter ou un plan d'adressage pour votre réseau.

Le corpus initial peut comporter douze observations : quelques doublons, une date manquante, une contradiction entre deux sources et un indicateur historique. Un jeu aussi petit suffit à révéler des erreurs importantes dans une chaîne d'analyse.

Conservez une fiche de conception expliquant pourquoi chaque anomalie existe. Elle sera masquée pendant une revue à l'aveugle, puis utilisée pour comparer le résultat attendu et le raisonnement réellement produit.

Définir une arborescence qui raconte le travail

Un lecteur ne devrait pas deviner quel fichier ouvrir. Une structure courte et stable suffit :

portfolio-cti/
  README.md
  donnees/source-a.csv
  donnees/source-b.csv
  donnees/source-c.csv
  donnees/journaux-synthetiques.csv
  methode/question-et-perimetre.md
  methode/dictionnaire-champs.md
  analyse/registre-preuves.csv
  analyse/hypotheses.md
  resultats/brief-soc.md
  resultats/note-direction.md
  revue/corrections.md

Le README précise d'emblée le caractère fictif du dossier, la compétence visée et l'absence de connexion réseau nécessaire. Il donne ensuite l'ordre de lecture : question, preuves, conclusions, limites, reproduction.

Le dictionnaire explique chaque champ, son type et le sens d'une valeur vide. « Date inconnue » ne signifie pas « aujourd'hui ». « Aucun résultat » ne signifie pas « indicateur inoffensif ». Ces choix seront visibles dans les conclusions finales.

Si vous ajoutez un script, documentez sa version minimale et sa commande locale. La présence d'un outil ne doit pas obliger le lecteur à fournir une clé API ou des permissions sensibles pour comprendre le projet.

Projet 1 : préserver la provenance pendant la normalisation

Le premier exercice traite un problème discret : réunir plusieurs flux sans effacer ce qui les distingue. source-a.csv contient une observation sur portail-compta.example. source-b.csv reprend cette même observation en citant A. source-c.csv décrit une activité différente sur le même domaine.

La sortie doit conserver l'origine initiale, le diffuseur actuel, l'heure d'observation, l'heure de collecte et l'assertion exacte. Ne réduisez pas ces trois lignes à « trois sources confirment une menace ». B est un relais de A; C doit être examiné pour comprendre ce qu'il affirme réellement.

Ajoutez une ligne dans laquelle une date est invalide. L'exercice est réussi si cette ligne devient un cas à traiter, avec une raison lisible. Il échoue si le parseur invente une date pour pouvoir continuer silencieusement.

Le livrable comprend les entrées, le résultat normalisé et un court journal des transformations. Une personne doit pouvoir retrouver, à partir d'une conclusion, les lignes originales qui la soutiennent. Le guide sur les pipelines d'IOC donne le contexte opérationnel; votre portfolio montre ici une propriété précise de cette chaîne.

Projet 2 : produire une analyse avec une réponse inconnue

Dans le deuxième exercice, les journaux synthétiques montrent qu'un poste a demandé un domaine signalé. Ils ne contiennent pas l'URL complète ni le processus à l'origine de la connexion. Une lecture trop rapide conclurait à une compromission.

Écrivez deux explications compatibles avec les données : navigation vers une page hostile, ou requête provenant d'un mécanisme automatisé. Pour chacune, indiquez ce qui la soutient, ce qui manque et quelle observation permettrait de progresser.

Votre résultat attendu peut être « exposition réseau établie, interaction humaine indéterminée ». Ce n'est pas un échec. C'est une conclusion plus fidèle qu'un verdict assuré sans base suffisante.

Le cas pratique du Diamond Model montre comment séparer événements, preuves et pivots écartés. Vous pouvez adapter cette structure en conservant votre propre corpus et son corrigé explicite.

La revue doit vérifier que la recommandation respecte cette limite. Demander une vérification ciblée est cohérent. Affirmer que le compte a été volé ne l'est pas. Une simulation de changement de mot de passe ou de blocage n'est utile que si vous expliquez la politique fictive qui la justifierait.

Les recommandations officielles britanniques sur la communication de l'incertitude distinguent probabilité et confiance analytique. Pour ce projet, appliquez surtout cette exigence simple : expliquer pourquoi une conclusion peut changer.

Projet 3 : livrer deux documents à partir des mêmes preuves

Le troisième exercice demande deux restitutions. Le brief SOC contient les objets à vérifier, la période, les systèmes concernés et les limites de visibilité. La note destinée à la direction décrit la décision, les conséquences possibles, les options et le responsable de l'action suivante.

Les deux documents doivent rester compatibles. La note de direction ne peut pas annoncer une attaque confirmée si le brief technique parle seulement d'une exposition. Le changement de destinataire modifie le vocabulaire et la sélection d'informations, pas le degré de certitude.

Fixez une contrainte de longueur au document court, par exemple une page. Justifiez les informations retirées : détail technique inutile pour cette décision, élément non vérifié ou annexe disponible sur demande. Le lecteur voit ainsi comment vous hiérarchisez.

Ajoutez une question de contrôle à chaque restitution : « Quelle décision ce document permet-il de prendre ? » Si aucune réponse précise n'apparaît, révisez le mandat ou la recommandation avant d'ajouter davantage de données.

Rendre la reproduction indépendante de votre ordinateur

Rejouer l'exercice ne doit pas dépendre de fichiers personnels, d'un chemin absolu caché ou d'un service qui change ses résultats. Placez toutes les entrées nécessaires dans le dossier et séparez les données originales des sorties produites.

Décrivez les étapes de traitement dans un ordre déterministe : vérifier les champs, conserver les lignes invalides à part, normaliser les valeurs autorisées, rattacher les relais à leur origine, puis générer le registre des preuves. Le même corpus doit produire les mêmes sorties.

Conservez une empreinte des fichiers d'entrée si vous voulez démontrer qu'ils n'ont pas changé. Expliquez sa fonction : détecter une modification des octets. Une empreinte correcte ne certifie pas que le contenu est vrai.

Terminez la reproduction par une vérification simple : nombre de lignes lues, nombre de lignes rejetées, nombre d'origines distinctes et nombre de cas indéterminés. La somme doit être explicable. Un objet perdu sans raison documentée mérite une correction avant publication.

Organiser une revue qui peut vous donner tort

Demandez à une autre personne de lire le dossier sans présentation préalable. Elle reçoit la question et les données; vous conservez temporairement vos conclusions. La difficulté qu'elle rencontre vous renseigne sur la clarté des livrables.

Voici une grille de revue proposée pour ce laboratoire, à adapter plutôt qu'à présenter comme une certification :

• Traçabilité : chaque conclusion importante renvoie à une pièce identifiable.
• Reproductibilité : les étapes documentées produisent le résultat annoncé.
• Raisonnement : les observations, hypothèses et conclusions restent distinctes.
• Pertinence : les recommandations répondent au mandat et au destinataire.
• Limites : les données absentes et les explications concurrentes sont visibles.
• Hygiène de publication : le dossier ne contient ni secret, ni donnée victime, ni lien malveillant actif.

Le commentaire le plus utile indique un endroit précis où le raisonnement saute une étape. « Cette conclusion suppose que le proxy représente un clic humain » vous donne une correction concrète. Une appréciation générale sur le style ne remplace pas cette revue.

Montrer une correction et ses conséquences

Un portfolio paraît plus crédible lorsque ses révisions sont visibles. Dans notre exercice, la première version comptait B comme source indépendante. La revue découvre que B cite A. La seconde version ramène le nombre d'origines de trois à deux et réexamine le jugement associé.

Le fichier de corrections explique l'erreur, la pièce qui l'a révélée, les sorties modifiées et ce qui reste inchangé. Ne réécrivez pas simplement le résultat pour donner l'impression qu'il a toujours été correct.

Ajoutez ensuite un cas qui empêcherait cette régression : une quatrième liste reprend A avec un nom différent. Le traitement doit conserver cette dépendance sans augmenter artificiellement la corroboration. Vous montrez une amélioration du procédé, pas seulement une correction manuelle.

L'article sur l'évaluation des sources explique pourquoi cette distinction compte. Dans le portfolio, la preuve de compétence est le changement observable entre les versions.

Publier seulement ce que le lecteur peut utiliser sans risque

Avant de rendre le dossier public, examinez les métadonnées des documents, les captures d'écran et les historiques de modifications. Un exemple fictif peut encore contenir le nom local d'un compte, un chemin personnel ou une ancienne clé copiée par erreur.

Les liens externes de référence doivent mener vers des normes, des documents officiels ou des recherches consultables. Les indicateurs de l'exercice restent du texte. Il n'est pas nécessaire de les rendre cliquables ni de les soumettre à un scanner public.

Si vous utilisez une partie d'un jeu de données public, documentez son origine, sa licence et vos transformations. « Disponible sur Internet » ne veut pas dire « redistribuable sans restriction ». Le guide OSINT pour analystes SOC complète la réflexion sur la collecte utile et documentée.

Indiquez enfin ce que vous avez réellement réalisé. Un script personnel n'est pas un déploiement SOC. Un cas synthétique n'est pas une opération de réponse à incident. Cette précision permet au lecteur d'évaluer votre travail sur sa vraie portée.

Présenter le dossier en entretien ou à un pair

Préparez une démonstration courte qui commence par la question et la décision obtenue. Ouvrez ensuite une conclusion et remontez jusqu'à sa pièce d'origine. Montrez une erreur corrigée, puis une limite que vous n'avez pas pu lever.

Vous devriez pouvoir expliquer pourquoi vous avez ignoré un pivot, conservé un résultat indéterminé ou demandé une information supplémentaire. Ces arbitrages rendent votre compréhension visible, même avec peu de lignes de données.

Un lecteur qui souhaite approfondir peut consulter les fichiers complets. Le principe de réutilisation des preuves dans l'historique des rapports s'applique aussi à ce dossier : une conclusion doit rester reliée à son état de connaissance initial.

Lors d'un futur exercice autorisé sur des indicateurs réels, vous pourrez comparer un résultat d'enrichissement isMalicious aux autres pièces du dossier, en conservant date et provenance. Le laboratoire proposé ici reste autonome. Vous pouvez déjà montrer une compétence essentielle de l'analyste CTI : produire une conclusion que quelqu'un d'autre peut vérifier et améliorer.