Partager le renseignement sur la menace avec ISAC, MISP et STIX

Partager le renseignement sur la menace avec ISAC, MISP et STIX

Partager le renseignement sur la menace, c’est transmettre à d’autres défenseurs ce qu’une attaque a laissé voir : infrastructure, outils, techniques. La question n’est pas de savoir si c’est vertueux (ça l’est), mais avec qui, par quel canal, sous quelle règle de diffusion, et surtout ce qu’on retire d’un événement avant de l’envoyer. Cette page prend le point de vue de qui émet et de qui rejoint une communauté, pas de qui se contente de consommer.

Explication de la marmotte

Dans un quartier, quand un cambrioleur rôde, les voisins qui se préviennent se protègent tous : chacun sait quelle camionnette surveiller. Encore faut-il prévenir sans afficher sur le palier le plan de sa maison ni l’endroit où dort la clé. Raconter aux autres ce qu’on sait d’une attaque informatique pose exactement cette question.

→ Lire l’explication complète de la marmotte

Partage de renseignement sur la menace : temps de détection contre exposition

Le gain est collectif et mesurable en temps. Un indicateur de compromission, ou IoC (Indicator of Compromise), observé chez un membre d’une communauté permet aux autres de chercher la même trace avant que l’attaquant ait fini son tour du secteur. Une technique documentée, au sens des TTP (Tactics, Techniques and Procedures), leur permet d’écrire une règle de détection qui survivra au prochain changement de serveur. Le débat entre les deux est traité sur la page IoC ou TTP pour détecter une compromission ; ici, seule compte la question de l’émission.

Le prix se paie en exposition, sous quatre formes distinctes :

• révéler qu’on a été touché : un événement signé du nom de l’organisation est un aveu d’incident, lisible par tous les membres du cercle ;
• révéler sa capacité de détection : dire ce qui a été vu, c’est dire aussi ce qui peut l’être, et par déduction ce qui ne l’est pas ;
• fuir des données personnelles ou de la cartographie interne : noms d’hôtes, plan d’adressage, comptes, adresses de messagerie des destinataires d’un hameçonnage ;
• alerter l’attaquant : un indicateur rendu public pendant que l’intrus est encore dans le réseau lui indique qu’il est temps de changer d’outillage, ou d’accélérer.

La position défendue ici : partager tôt des éléments peu sensibles et bien qualifiés vaut mieux que partager tard un rapport parfait. Trois condensats de fichiers, deux domaines, une date d’observation et un niveau de confiance, envoyés pendant que la campagne tourne encore, servent davantage qu’un document de quarante pages relu par six personnes et diffusé quand l’infrastructure adverse a déjà été démontée. Cette recommandation tient à une condition : que le tri avant envoi soit une routine outillée, pas une réunion.

Reste la maladie chronique des communautés : le passager clandestin, qui consomme tout et ne contribue jamais. Vingt ans de listes de diffusion apprennent que la proportion de lecteurs silencieux y est d’une stabilité remarquable, quelle que soit la charte signée à l’adhésion. Un cercle où tout le monde attend que les autres commencent ne produit rien, et un cercle qui ne produit rien se vide de ses contributeurs en premier.

ISAC, CERT sectoriels, communautés MISP et bilatéral : les cercles de partage

Un ISAC (Information Sharing and Analysis Center) est une structure de partage propre à un secteur d’activité. Le modèle est américain : la directive présidentielle PDD-63 (Presidential Decision Directive 63) de 1998 a demandé aux opérateurs d’infrastructures critiques de s’organiser par secteur, et le FS-ISAC (Financial Services ISAC) de la finance a été créé en 1999. En Europe, l’ENISA (European Union Agency for Cybersecurity, l’agence de l’Union européenne pour la cybersécurité) soutient la constitution d’ISAC sectoriels. Aux Pays-Bas, le NCSC-NL anime ce partage avec les opérateurs privés, ports en tête, rappel utile qu’un conteneur bloqué à quai se moque de savoir qui devait prévenir qui.

Côté français, le maillage passe plutôt par des CERT (Computer Emergency Response Team) ou CSIRT (Computer Security Incident Response Team) sectoriels, dans des domaines comme le maritime ou l’aérien, et par l’InterCERT France, association qui réunit des équipes de réponse à incident publiques et privées. Le CERT-FR tient le rôle de CSIRT national. Pour savoir ce que doit être l’équipe qui parle au nom de l’organisation dans ces cercles, voir Monter un CSIRT interne.

À ces structures s’ajoutent deux cercles moins formels. Les communautés MISP (Malware Information Sharing Platform, nom d’origine d’un projet qui se présente aujourd’hui comme une plateforme de partage de renseignement sur la menace) regroupent des organisations autour d’une instance commune ou d’instances synchronisées. Le bilatéral de confiance, enfin : deux personnes qui se connaissent, un canal chiffré, et les informations les plus sensibles, celles qu’aucune plateforme ne verra jamais.

Ce qui fait qu’un cercle fonctionne tient en trois points, et aucun n’est technique :

1. la confiance entre personnes, pas entre logos : on partage avec quelqu’un dont on connaît le sérieux, ce qui suppose des rencontres et une stabilité des interlocuteurs ;
2. des règles d’adhésion : qui entre, sur quel parrainage, avec quel engagement de confidentialité, et comment on sort un membre ;
3. la réciprocité, mesurée et rappelée, sans quoi le passager clandestin devient la norme.

Le schéma suivant montre les cercles et ce qui circule sur chaque canal ; le point à y lire est que la notification à l’autorité et le partage entre pairs sont deux flux séparés, avec des règles différentes.

Prérequis avant de rejoindre un ISAC ou une communauté MISP

Rejoindre un cercle sans rien avoir à y verser ni personne pour lire ce qui en sort revient à s’abonner à un flux de plus. Avant l’adhésion, il faut :

• une équipe ou une fonction de réponse à incident identifiée, avec un point de contact nominatif et joignable ;
• une capacité à produire des observations : journaux centralisés, télémétrie des terminaux, et quelqu’un qui qualifie ;
• une capacité à consommer : un SIEM (Security Information and Event Management) ou un outil de détection qui sait ingérer des indicateurs, et une recherche rétroactive dans l’historique ;
• une politique interne écrite : qui a le droit de publier, sous quel marquage par défaut, avec quelle validation pour les niveaux restreints ;
• un avis du délégué à la protection des données et du juridique sur les catégories de données partagées, obtenu une fois pour toutes plutôt qu’à chaque événement ;
• une instance MISP maintenue à jour, ou un accès à celle de la communauté. Héberger sa propre instance donne un espace de tri interne avant synchronisation, ce qui change tout pour la suite.

MISP côté émetteur : événement, distribution et synchronisation

MISP est un logiciel libre, aujourd’hui porté principalement par le CIRCL (Computer Incident Response Center Luxembourg). Son modèle de données, vu depuis l’émission :

• l’événement est le conteneur : une campagne, un incident, une analyse ;
• les attributs sont les éléments atomiques (adresse IP, pour Internet Protocol, domaine, condensat, règle de détection), chacun typé et catégorisé ;
• les objets regroupent des attributs liés (un fichier avec son nom, sa taille et ses condensats) pour éviter la soupe d’indicateurs sans lien ;
• les galaxies rattachent l’événement à des connaissances structurées (groupe d’attaquants, famille de maliciel, techniques du référentiel ATT&CK, pour Adversarial Tactics, Techniques, and Common Knowledge, maintenu par MITRE) ;
• les taxonomies fournissent les étiquettes normalisées, dont tlp: et PAP: ;
• le drapeau to_ids dit si un attribut est destiné à alimenter un IDS (Intrusion Detection System, système de détection d’intrusion) ou tout autre outil de blocage et de détection. Un attribut sans ce drapeau est du contexte, pas une règle ;
• les sightings permettent à un membre de signaler qu’il a observé un attribut, ou qu’il le tient pour un faux positif : c’est la contribution minimale, et le meilleur remède au passager clandestin ;
• les listes d’avertissement (warninglists) signalent les attributs qui correspondent à des valeurs connues pour produire des faux positifs : résolveurs publics, plages d’hébergeurs massifs, domaines très fréquentés.

Niveaux de distribution et groupes de partage

Chaque événement porte un niveau de distribution, et chaque attribut le sien (par défaut, celui de l’événement) :

• organisation seule : ne quitte pas l’organisation émettrice ;
• cette communauté : visible des organisations de la communauté locale, sans propagation au-delà ;
• communautés connectées : un saut de synchronisation plus loin, où l’événement est rétrogradé pour ne pas repartir ;
• toutes les communautés : propagation d’instance en instance sans limite de sauts ;
• groupe de partage : liste explicite d’organisations et d’instances, définie et administrée à part.

Un attribut peut être plus restreint que son événement. C’est le mécanisme qui autorise à garder dans le même événement le contexte interne (organisation seule) et les éléments partageables.

Le piège : distribution et TLP sont deux mécanismes distincts

L’étiquette tlp:red posée sur un événement n’empêche techniquement rien. C’est une consigne adressée à des humains. Ce qui décide de ce qui part à la synchronisation, c’est le niveau de distribution et l’état de publication. Un événement étiqueté rouge avec une distribution « toutes les communautés » fera le tour des instances connectées, étiquette rouge bien visible, comme une lettre marquée confidentiel glissée dans la boîte de tout l’immeuble.

Des règles de filtrage par étiquette peuvent s’ajouter sur un lien de synchronisation. C’est un filet de sécurité, pas le mécanisme de contrôle : le réglage qui fait foi reste la distribution.

Synchronisation push et pull

Deux instances se synchronisent par un compte dédié et sa clé d’API (Application Programming Interface). En push, l’instance émettrice pousse les événements publiés dont la distribution l’autorise. En pull, l’instance réceptrice vient chercher ce que le compte de synchronisation a le droit de voir. Deux conséquences d’architecture : publier un événement, c’est déclencher son départ, donc le tri se fait avant ; et la portée réelle d’un niveau dépend de la topologie des liens, qu’on ne maîtrise que sur sa propre instance. Avant de rejoindre une communauté, un événement de test sans contenu, suivi de bout en bout, vaut mieux que toutes les suppositions.

STIX 2.1 et TAXII 2.1 : le format d’objets et le transport

STIX (Structured Threat Information Expression) et TAXII (Trusted Automated Exchange of Intelligence Information) sont deux standards de l’OASIS (Organization for the Advancement of Structured Information Standards), tous deux en version 2.1 depuis 2021.

STIX est un format d’objets en JSON (JavaScript Object Notation), rangés en familles :

• les SDO (STIX Domain Objects) décrivent les concepts du renseignement : indicator, malware, attack-pattern, campaign, entre autres ;
• les SRO (STIX Relationship Objects) relient le tout : relationship (tel indicateur indique tel maliciel) et sighting (tel indicateur a été vu) ;
• les SCO (STIX Cyber-observable Objects) décrivent les faits techniques observés : fichier, adresse, domaine ;
• les marquages de données, objets marking-definition, portent les règles de diffusion, dont le TLP, et sont référencés par les objets qu’ils couvrent.

Deux points d’attention côté émetteur. Un indicator porte une date de début de validité obligatoire et une date de fin facultative, et les objets de domaine et de relation peuvent porter un niveau de confiance : laisser vides la fin de validité et la confiance, c’est transmettre un indicateur immortel et de fiabilité inconnue. Et la spécification 2.1 prédéfinit les marquages du TLP d’origine (WHITE compris) ; les marquages du TLP 2.0, dont AMBER+STRICT, n’y figurent pas nativement, donc vérifier que l’émetteur et le récepteur s’entendent sur leur représentation avant de s’y fier.

TAXII est le transport, en HTTPS (HyperText Transfer Protocol Secure) : un point de découverte annonce des racines d’API, chaque racine expose des collections, et un client lit ou écrit des objets STIX dans une collection selon ses droits.

Le choix dépend d’une question : les destinataires vont-ils enrichir ou seulement ingérer ? Entre pairs qui corrigent, complètent, signalent des observations et discutent un événement, MISP est l’outil : son modèle de distribution et ses sightings sont faits pour ça. Pour distribuer un flux vers des outils (SIEM, pare-feu, plateformes de détection) ou vers des consommateurs qui n’écriront jamais rien en retour, une collection TAXII servant du STIX est le dénominateur commun. Les deux se combinent : MISP comme atelier, TAXII comme guichet.

TLP, PAP et règle de Chatham House : les règles de diffusion

Le TLP (Traffic Light Protocol), en version 2.0 depuis août 2022, dit à qui une information peut être transmise, avec quatre marquages : RED, AMBER (et sa variante restreinte AMBER+STRICT), GREEN et CLEAR (qui a remplacé WHITE). Le détail des couleurs est sur la page Rôle de FIRST et mise en œuvre du TLP ; inutile de le recopier.

Le PAP (Permissible Actions Protocol) répond à une autre question : ce qu’on a le droit de faire d’une information.

• PAP:RED : aucune action que l’adversaire pourrait détecter. Recherche dans les journaux déjà collectés, analyse hors ligne, rien d’autre.
• PAP:AMBER : vérifications passives autorisées (interroger une base de résolutions historiques, chercher un condensat sans téléverser le fichier), aucun contact direct avec l’infrastructure adverse.
• PAP:GREEN : actions actives autorisées, y compris bloquer ou interroger l’infrastructure.
• PAP:CLEAR : aucune restriction.

Les deux marquages sont indépendants et les confondre coûte cher. Un indicateur TLP:GREEN et PAP:RED peut circuler dans toute la communauté, mais personne ne doit le bloquer sur un proxy : un blocage visible prévient l’attaquant plus sûrement qu’un communiqué.

Pour les réunions, la règle de Chatham House complète le dispositif : les participants peuvent réutiliser ce qui a été dit, sans révéler ni l’identité ni l’affiliation de qui l’a dit. Elle couvre l’oral ; elle ne dit rien des documents distribués, qui gardent leur propre marquage.

Tri avant envoi : séparer l’attaquant de la victime dans un événement MISP

La méthode tient en une question posée à chaque élément : décrit-il l’attaquant ou décrit-il la victime ?

Ce qui décrit l’attaquant se partage : adresses et domaines de son infrastructure, condensats de ses fichiers, techniques rattachées à ATT&CK, règles de détection écrites pendant l’analyse. C’est ce dont les pairs ont besoin, et cela ne dit presque rien de l’organisation émettrice.

Ce qui décrit la victime reste à la maison : noms d’hôtes internes, adressage privé, noms de comptes, adresses de messagerie des destinataires, chemins de fichiers contenant un nom d’utilisateur, objets de courriel ciblés, documents leurres fabriqués pour l’organisation. Ces éléments n’aident personne à détecter quoi que ce soit ailleurs ; ils aident en revanche à cartographier l’émetteur.

La frontière passe parfois au milieu d’un même élément. Un chemin d’exécution se généralise en remplaçant le nom d’utilisateur par un joker ; un objet de courriel se réduit à son motif ; une règle de détection se relit pour vérifier qu’elle ne cite ni serveur interne ni nom de projet. Les règles de détection sont les fuites les plus fréquentes : écrites dans l’urgence, testées sur les journaux maison, elles embarquent volontiers un morceau du décor.

Données personnelles

Une adresse IP ou une adresse de messagerie est, le plus souvent, une donnée à caractère personnel au sens du RGPD (Règlement général sur la protection des données). Le considérant 49 du règlement reconnaît que le traitement nécessaire à la sécurité des réseaux et de l’information relève de l’intérêt légitime. Cela fonde le partage ; cela ne dispense ni de minimiser (ne transmettre que ce qui sert la détection) ni de documenter le traitement. L’adresse de l’expéditeur d’un hameçonnage sert la détection ; la liste des destinataires internes, non. Les conséquences d’architecture du règlement sont développées sur la page RGPD : exigences d’architecture et contrôles techniques.

Sécurité opérationnelle

Deux règles :

• pas de partage public d’un indicateur tant que l’éviction n’est pas faite. Pendant la réponse à incident, le partage se limite à un cercle restreint, sous PAP:RED ou PAP:AMBER. Un attaquant sérieux surveille les sources ouvertes pour y chercher ses propres traces ;
• pas de téléversement d’un échantillon propre à l’organisation sur un service public d’analyse. Un maliciel fabriqué pour une cible peut embarquer dans sa configuration des noms internes ou des identifiants, et son apparition sur un service public signale à son auteur qu’il a été trouvé. La recherche par condensat ne transmet pas le fichier ; le téléversement, si.

Qualité de ce qui part

Un indicateur nu est une corvée transférée aux destinataires. Chaque envoi porte : le contexte (quelle étape de l’attaque, quel rôle joue l’élément), la date d’observation, un niveau de confiance, une durée de vie (une adresse sur un hébergeur mutualisé périme en quelques jours, un condensat ne périme pas mais ne sert plus dès que l’outil est recompilé) et le drapeau de détection réglé avec honnêteté. Le marché regorge de flux qui confondent volume et valeur, travers examiné dans l’éditorial sur la threat intelligence et l’incitation alarmiste ; une communauté n’a aucune raison de l’imiter.

Exemple : arbre de décision de tri d’un événement MISP avant envoi

L’arbre suivant s’applique élément par élément, sur un événement créé en distribution « organisation seule ». Rien n’est publié avant que chaque attribut l’ait traversé.

Le premier tri élimine l’essentiel du risque : tout ce qui décrit la victime reste dans l’événement, mais au niveau « organisation seule », ce qui conserve le contexte pour l’équipe interne sans qu’il parte à la synchronisation. Le deuxième rattrape les éléments mixtes, qui reviennent dans la file une fois généralisés. Le troisième est celui de la sécurité opérationnelle : tant que l’intrus est dans les murs, le partage reste possible, et même souhaitable pour les pairs visés par la même campagne, mais dans un groupe fermé et sous PAP:RED.

Le quatrième tri répond à l’exposition de la capacité de détection : un outil ou une infrastructure vus nulle part ailleurs signent une attaque ciblée, et leur diffusion large apprend à l’attaquant ce qui a été trouvé chez qui. Le secteur d’abord, le reste plus tard. La dernière étape, le contrôle croisé, existe pour le piège décrit plus haut : vérifier que le niveau de distribution dit la même chose que l’étiquette, parce que c’est lui qui sera obéi.

NIS 2 articles 29 et 30, DORA article 45 : le cadre réglementaire du partage

Les textes européens ne se contentent pas de tolérer le partage, ils l’organisent. Ce qui suit cite les articles ; l’appréciation d’une situation particulière relève d’un conseil juridique, pas d’une page de documentation.

La directive NIS 2 (Network and Information Security, directive (UE) 2022/2555) consacre son article 29 aux accords de partage d’informations en matière de cybersécurité. Il prévoit que les entités relevant de la directive, et d’autres le cas échéant, puissent échanger volontairement des informations (menaces, incidents évités, vulnérabilités, techniques et procédures, indicateurs de compromission, alertes, recommandations de configuration) au sein de communautés, dans le cadre d’accords qui respectent le caractère sensible des informations. Il prévoit aussi que les entités essentielles et importantes notifient aux autorités compétentes leur participation à ces accords, et leur retrait. L’article 30 traite de la notification volontaire aux CSIRT ou aux autorités compétentes, et précise qu’elle ne doit pas entraîner pour l’entité notifiante d’obligations supplémentaires auxquelles elle n’aurait pas été soumise sans cette notification. Le périmètre de la directive est détaillé sur la page NIS 2 : entités essentielles, obligations, périmètre et sanctions.

Le règlement DORA (Digital Operational Resilience Act, règlement (UE) 2022/2554) fait de même pour la finance à son article 45 : les entités financières peuvent échanger entre elles des informations et du renseignement sur les cybermenaces, au sein de communautés de confiance, par des dispositifs qui protègent la nature sensible des informations et respectent le secret des affaires, la protection des données personnelles et le droit de la concurrence. Elles notifient aux autorités compétentes leur participation à ces dispositifs. Voir DORA et la résilience opérationnelle numérique.

Un point ne souffre aucune confusion : le partage volontaire ne remplace pas la notification obligatoire d’incident. Avoir prévenu ses pairs sur une plateforme ne vaut pas déclaration à l’autorité, et les délais de la seconde courent indépendamment du premier. Les obligations et leurs échéances sont sur la page Délais de notification d’incident NIS 2, RGPD et DORA.

Surface d’attaque d’une plateforme de partage MISP et conditions d’exploitation

Une plateforme de partage concentre ce que le secteur sait de ses adversaires et, en creux, de ses propres faiblesses. Elle mérite le même traitement qu’un système sensible, pas celui d’un outil d’équipe installé un vendredi.

Attaque	Effet	Contre-mesure
Compte ou clé d’API compromis	Lecture de tout ce que le compte voit, injection d’événements au nom de l’organisation	Clés par usage, droits minimaux, restriction par adresse source, rotation, authentification forte des comptes humains
Membre indiscret ou compromis	Fuite hors du cercle d’éléments restreints	Règles d’adhésion, groupes de partage étroits pour le sensible, bilatéral pour le très sensible
Empoisonnement par de faux indicateurs	Blocage de services légitimes chez les consommateurs, perte de confiance dans le flux	Listes d’avertissement, validation locale avant tout blocage, prise en compte de l’émetteur et des sightings
Synchronisation mal réglée	Événement interne qui part vers des instances tierces	Distribution par défaut restrictive, contrôle croisé avant publication, événement de test, journal des synchronisations
Surveillance des sources publiques par l’attaquant	L’attaquant apprend qu’il est repéré et change d’outillage	PAP, pas de diffusion publique avant éviction, pas de téléversement d’échantillon ciblé

L’empoisonnement mérite un mot de plus. Brancher un flux communautaire directement sur un équipement de blocage, sans étape intermédiaire, revient à confier la liste noire de son proxy à quiconque obtient un compte dans la communauté. La règle : un indicateur reçu alimente d’abord la détection ; le blocage vient après validation locale.

Conditions d’exploitation

• Clés d’API : une par usage (synchronisation, export vers la détection, automatisation), jamais celle d’un compte personnel, avec une rotation planifiée et une révocation immédiate au départ d’un administrateur.
• Journal des synchronisations : conservé, exporté hors de l’instance et relu. C’est la seule trace de ce qui est parti, vers qui et quand.
• Revue périodique des groupes de partage : les organisations changent, les personnes aussi. Un groupe jamais revu finit par contenir des membres dont plus personne ne sait qui les a invités.
• Expiration des indicateurs : retrait du drapeau de détection ou péremption à l’échéance de la durée de vie, faute de quoi la base de détection se remplit d’adresses réattribuées depuis longtemps à des services légitimes.
• Sauvegarde et reprise : base de données, configuration, clés de chiffrement et de signature de l’instance, avec un test de restauration. La sauvegarde hérite de la sensibilité de l’instance et se protège comme elle.
• Mises à jour : une instance exposée à des partenaires se corrige au rythme des publications de sécurité du projet.

Ce que le partage ne garantit pas

Le marquage ne garantit pas l’obéissance : TLP et PAP sont des conventions, respectées par discipline et par réputation, sans aucun contrôle technique chez le destinataire. Une fois l’événement parti, il ne se rappelle pas : supprimer un événement synchronisé ne l’efface pas des copies déjà faites ni des exports déjà ingérés. Recevoir des indicateurs ne garantit pas de détecter : sans télémétrie pour les confronter et sans recherche rétroactive, le flux reste une base de données bien rangée. Enfin, un indicateur partagé décrit une attaque passée ; la détection de la suivante doit venir des techniques, du SOC (Security Operations Center, centre des opérations de sécurité) et de la chasse par hypothèses.

🐝 Ce qui arrive si on s’en passe

Sans cercle de partage ni tri outillé, chaque organisation d’un secteur redécouvre seule la même campagne, l’une après l’autre, et l’attaquant amortit la même infrastructure sur toutes ses cibles. Les observations faites pendant un incident restent dans un rapport interne et périment avant d’avoir servi à quiconque. Le jour où il faut malgré tout prévenir un pair, l’envoi se fait dans l’urgence, par courriel, sans marquage : les noms d’hôtes, les comptes et les destinataires partent avec le reste, et personne ne sait ensuite qui détient quoi. Faute de consigne sur les actions permises, un destinataire bloque un indicateur pendant que l’intrus est encore présent, ce qui l’avertit. Et sans retour des pairs, rien ne permet de distinguer une attaque ciblée d’une campagne large, donc de régler l’ampleur de la réponse.

🦫 Explication de la marmotte 🍫

Quand une organisation subit une attaque informatique, elle récupère des traces : les adresses des machines de l’attaquant, l’empreinte de ses fichiers, sa façon de procéder. Transmises à d’autres organisations, ces traces leur permettent de vérifier si elles sont visées et de se protéger plus vite. Mais les mêmes notes contiennent aussi des informations sur la victime : le nom de ses ordinateurs, ses comptes, les adresses des employés qui ont reçu le message piégé. Avant d’envoyer quoi que ce soit, il faut donc trier : ce qui décrit l’attaquant part, ce qui décrit la victime reste. Ensuite, chaque élément reçoit deux consignes. La première dit à qui il peut être transmis. La seconde dit ce que les destinataires ont le droit d’en faire, parce que bloquer trop tôt une adresse prévient l’attaquant qu’il a été repéré. Tant qu’il n’a pas été chassé du réseau, le partage reste limité à un petit groupe de confiance. L’envoi passe par une plateforme où chaque organisation règle jusqu’où ses informations voyagent. Ce réglage est le seul qui compte vraiment : une consigne écrite n’arrête pas une copie automatique. Si le tri est oublié, des informations internes fuient. Si personne ne contribue, le groupe ne sert plus à rien. Et prévenir ses pairs ne remplace jamais la déclaration obligatoire aux autorités.

À lire aussi

• Comment attribuer techniquement une cyberattaqueL’attribution d’une cyberattaque repose sur des faisceaux d’indices probabilistes, distincts de la décision politique de désigner officiellement un État ou un groupe.
• Prioriser les vulnérabilités avec CVSS 4.0, EPSS, KEV et expositionCe que mesurent CVSS 4.0, EPSS et le catalogue KEV, ce qu'ils ne mesurent pas, et comment les croiser avec le contexte d'exposition pour décider quoi corriger en premier.
• CCCS Canada et ACSC Australie dans les Five EyesLe Centre canadien pour la cybersécurité et l’Australian Cyber Security Centre structurent, avec les Five Eyes, une part des alertes cyber coordonnées internationales.
• CERT-EU réponse aux incidents des institutions européennesCERT-EU est le service opérationnel de réponse aux incidents des institutions, organes et agences de l’Union européenne, distinct d’ENISA et d’Europol.

Pages voisines

Partager le renseignement sur la menace avec ISAC, MISP et STIX

Elle cite

• ⇄Lien dans les deux sens :Comment formuler une hypothèse de threat hunting
• ⇄Lien dans les deux sens :IoC ou TTP pour détecter une compromission
• ⇄Lien dans les deux sens :Monter un CSIRT interne, missions, services FIRST et rattachement
• ⇄Lien dans les deux sens :DORA et résilience opérationnelle numérique financière
• ⇄Lien dans les deux sens :NCSC-NL et coordination cyber portuaire néerlandaise
• ⇄Lien dans les deux sens :Pourquoi la threat intelligence commerciale alarme
• ⇄Lien dans les deux sens :Rôle de FIRST et mise en œuvre du TLP
• Comment calibrer les alertes d’un SIEM sans noyer le SOC
• SOC centre des opérations de sécurité : rôle, organisation, mesure
• CERT-FR alertes et avis de sécurité
• Comment minimiser les données collectées
• Délais de notification d’incident NIS2 RGPD DORA

⇄ : les deux pages se citent l’une l’autre.