Préparer les journaux de sécurité pour une détection utile

Renseignement cyber : de l’indicateur à une détection justifiable

Un flux de renseignement cyber peut fournir un domaine, un motif de détection et une appréciation de confiance. Pour l’utiliser dans un SOC, il faut encore établir sa provenance, sa période d’utilité, les journaux capables de le reconnaître et la procédure de retrait. Cette fiche aide à préparer cette décision et à expliquer ses limites au destinataire.

Les propriétés et objets décrits ici se rapportent au standard OASIS STIX 2.1 du 10 juin 2021. Les contrôles de déploiement, les échéances de revue et les décisions des cas sont des propositions éditoriales locales. Ils ne constituent ni un moteur de validation STIX, ni une règle de blocage, ni une évaluation d’un flux réel.

Repère de version : l’URL OASIS « latest stage » renvoie, lors de cette vérification, à un document du 2 avril 2025 intitulé STIX 2.1 Errata 01, qui incorpore Draft 01. Son statut de projet d’errata est conservé dans la citation ; il n’est pas présenté comme une nouvelle version finale approuvée. L’encodage d’un marquage doit être convenu avec le destinataire et vérifié dans l’édition effectivement utilisée.

12 points de lecture avant l’import d’un indicateur

Quatre objets, quatre questions différentes

Lire un objet fictif sans le transformer en alerte

Exemple pédagogique autonome, rédigé pour cette page ; aucun renseignement de menace réel. Le suffixe .example est réservé à la documentation par RFC 2606. Les dates et la confiance 60 sont fictives. Le créateur et le marquage sont volontairement absents : ces absences ne signifient ni source vérifiée ni publication autorisée. L’objet n’est ni un bundle complet ni une validation de conformité par un outil OASIS.

{
    "type": "indicator",
    "spec_version": "2.1",
    "id": "indicator--643d2844-11ca-4f63-8d5d-e5d938db1854",
    "created": "2026-10-22T09:00:00.000Z",
    "modified": "2026-10-22T09:00:00.000Z",
    "lang": "en",
    "name": "Fictional training indicator",
    "description": "Documentation only. Never deploy this example as a detection or blocking rule.",
    "pattern": "[domain-name:value = 'training-beacon.example']",
    "pattern_type": "stix",
    "pattern_version": "2.1",
    "valid_from": "2026-10-22T09:00:00Z",
    "valid_until": "2026-10-23T09:00:00Z",
    "confidence": 60
}

À 10:00 UTC le 22 octobre 2026, la date se situe dans la fenêtre indiquée. Cela ne démontre ni présence dans les journaux ni caractère malveillant. Avant d’en dériver une détection, il resterait à connaître le producteur, le contexte, les restrictions, la télémétrie, les exceptions et le responsable du retrait.

Huit cas fictifs de qualification et de partage

Chaque cas isole une difficulté. Les décisions proposées relèvent d’une méthode de travail locale et ne sont pas des verdicts automatiques tirés du seul format STIX. Le filtre masque uniquement des exemples déjà présents dans la page ; aucune donnée n’est envoyée.

TLP 2.0 : destinataires, besoin d’en connaître et restrictions

FIRST définit quatre labels ; AMBER+STRICT est une restriction d’AMBER, pas une cinquième couleur. Les libellés restent identiques dans toutes les langues. La matrice ci-dessous résume le périmètre TLP et ne remplace pas les restrictions supplémentaires de la source ni les règles applicables au document.

TLP décrit un périmètre de partage ; il ne certifie ni l’exactitude, ni une classification officielle, ni une licence d’utilisation. Les règles de chiffrement et de conservation doivent être définies séparément. Pour élargir le périmètre reçu, demander l’autorisation explicite de la source.

Attention à l’interopérabilité : les définitions TLP prédéfinies de STIX 2.1 dans l’édition 2021 incluent TLP:WHITE. Le vocabulaire TLP 2.0 de FIRST emploie TLP:CLEAR et précise AMBER+STRICT. Ne pas créer un encodage improvisé « tlp=clear » ou renommer silencieusement un marquage historique : documenter la version et le profil d’échange réellement pris en charge par les outils.

Six éléments à transmettre avec la décision

• Identifiant et version de l’objet, producteur déclaré et provenance de collecte.
• Horodatages UTC : réception, fenêtre de validité et date locale de réexamen clairement distinguées.
• Hypothèse de détection, journaux requis, champs exploités et couverture connue des capteurs.
• Résultats de recherche et limites : absence, correspondance, ambiguïté ou justification d’un faux positif.
• Destinataires, marquages, restrictions supplémentaires et autorisation d’élargissement s’il y a lieu.
• Responsable, règle ou ticket dérivé, décision, retrait prévu et vérification de la propagation.

Références et périmètre de vérification

• OASIS · STIX 2.1 · OASIS Standard · 2021-06-10
  §3.2, §3.6, §4.7, §4.14, §5.2, §7.2
• OASIS · STIX 2.1 Errata 01 · Draft 01 · 2025-04-02 · OASIS Standard incorporating Draft 01 of Errata 01
  Status / Citation format · draft status identified separately
• FIRST · Traffic Light Protocol 2.0 · TLP 2.0 · 2022-08
  §1, §2, §3 · TLP:AMBER+STRICT
• IETF · RFC 2606 · BCP 32 · 1999-06
  §2 · .example reserved for documentation

Sources vérifiées le 2026-10-22