← Tous les articles

13 min de lecture

Construire une chronologie d'incident de sécurité vérifiable sans la rendre publique

Comment une équipe de sécurité peut horodater et sceller les pièces d'un incident au fur et à mesure de leur collecte — une chronologie durable et vérifiable de façon indépendante, qui prouve ce qui existait à quel moment, sans divulguer de détails sensibles.

Une équipe de sécurité peut construire une chronologie d'incident démontrable sans rendre l'incident public avant d'être prête. À mesure que les pièces sont collectées, vous hachez chaque artefact important et publiez le condensé sur Cardano sous Label 309. Toute personne de votre choix pourra ensuite confirmer que ces octets exacts existaient à une date de bloc publique, ou avant — sans avoir à faire confiance à vos serveurs, à votre domaine ni à votre parole. Les éléments sensibles peuvent être scellés : le texte en clair reste chiffré et seul l'engagement est public.

Concrètement, vous hachez rapports, journaux, exports forensiques, captures d'écran, notifications aux clients, brouillons destinés aux régulateurs et manifestes de pièces à mesure que l'incident se déroule. Chaque publication ancre un engagement à une date publique. Le texte en clair peut être scellé à l'intention de destinataires nommés : la chaîne prouve quand sans révéler quoi.

Il s'agit d'une couche de preuve, et non d'un substitut à la réponse à incident, au conseil juridique, aux décisions de divulgation ou à la déclaration réglementaire. Elle donne à la chronologie qui sous-tend ces décisions un ancrage externe et inviolable.

Pourquoi la chronologie devient-elle une preuve pendant un incident ?

Pendant un incident, le temps lui-même est une preuve.

Par la suite, une équipe doit souvent répondre à des questions comme celles-ci :

  • quand une activité suspecte a été observée pour la première fois ;
  • quand l'incident a été escaladé ;
  • quand le conseil juridique a été informé ;
  • quand le confinement a commencé ;
  • quels journaux existaient avant la reconstruction des systèmes ;
  • quels dossiers clients étaient considérés comme touchés à chaque étape ;
  • quelle version d'un rapport a été transmise au conseil d'administration ;
  • quelle notification réglementaire a été rédigée ou déposée ;
  • ce qui a changé entre la première évaluation et le rapport final.

Le problème, c'est que les pièces d'un incident évoluent vite. Les journaux sont écrasés par rotation. Les tickets sont modifiés. Les rapports sont révisés. Les captures d'écran sont collées dans des présentations. Les exports sont relancés. Une séquence d'événements qui paraissait évidente le premier jour peut devenir difficile à prouver six mois plus tard.

Un engagement horodaté donne à chaque artefact important un ancrage externe que personne — vous y compris — ne peut antidater.

Que doit horodater une équipe de sécurité ?

Horodatez les artefacts qui compteraient si la chronologie venait à être contestée.

Pour un incident de sécurité, cela inclut souvent :

  • les premières notes de détection ;
  • les exports d'alertes ;
  • les recherches issues de votre outil SIEM (security information and event management) ;
  • les exports de votre outil EDR (endpoint detection and response) ;
  • les journaux de pare-feu et d'accès ;
  • les journaux du fournisseur d'identité ;
  • les journaux d'audit du cloud ;
  • les échantillons de malware ou leurs empreintes ;
  • les manifestes d'images disque ou mémoire forensiques ;
  • les listes de comptes touchés ;
  • les estimations de clients touchés ;
  • les notes de confinement et d'éradication ;
  • les tickets d'incident ;
  • les rapports d'état internes ;
  • les points pour le conseil d'administration ;
  • les brouillons destinés aux régulateurs ;
  • les brouillons de notification aux clients ;
  • les rapports d'incident finaux.

Ne publiez pas de secrets en clair. Une empreinte, une racine de Merkle ou un texte chiffré scellé est presque toujours plus sûr qu'un texte public — et tout aussi démontrable.

Comment Label 309 s'intègre-t-il à la réponse à incident ?

Utilisez-le comme une couche de preuve à côté des outils que vous exploitez déjà.

Une équipe de réponse à incident n'a pas besoin de remplacer son SIEM, son outil de gestion de cas, son système de tickets, sa plateforme forensique ou son dépôt documentaire. Vous exportez ou figez les artefacts importants, vous en calculez l'empreinte et vous publiez des records à des moments définis de la réponse.

Un flux type :

  1. L'équipe de détection exporte le premier lot d'alertes.
  2. Le responsable de l'incident construit un manifeste des fichiers.
  3. Le manifeste est haché.
  4. Un record Label 309 ancre l'empreinte, ou une racine de Merkle sur le lot.
  5. Les fichiers sensibles sont scellés à l'intention du conseil juridique et de la direction de la sécurité.
  6. La référence de transaction est rattachée au dossier d'incident.

Plus tard, toute personne disposant de cette référence de transaction peut confirmer qu'un fichier ou un manifeste donné correspond aux octets engagés à l'horodatage public — à l'aide du vérificateur, de l'outil en ligne de commande open source, ou de toute implémentation tierce du standard. Le code de publication et de vérification est open source à github.com/cardanowall.

Pourquoi sceller des records d'incident plutôt que publier les octets ?

Les détails d'un incident sont souvent dangereux à publier.

Ils peuvent contenir des vulnérabilités non corrigées, des identifiants, des adresses IP, des données clients, des données employés, des informations sur l'auteur de la menace, des faits sensibles pour les forces de l'ordre, ou des plans de remédiation commercialement sensibles.

Un record scellé vous permet de publier un engagement tout en gardant le fichier chiffré. Le record sur la chaîne porte l'empreinte du texte en clair — la preuve de la datation — ainsi qu'une clé encapsulée que seuls les destinataires choisis peuvent ouvrir. Le texte chiffré réside à une URI de stockage adressé par le contenu, pas sur la chaîne, et les clés publiques des destinataires n'y apparaissent jamais non plus. Un observateur apprend seulement qu'un record scellé existe, sa date de bloc et le nombre de destinataires auxquels il a été scellé — jamais leur identité ni ce qui a été scellé.

Vous pouvez ainsi préserver les pièces originales sans divulguer l'incident par le record de preuve lui-même. Pour en savoir plus sur le scellement de fichiers à l'intention de personnes précises sans en exposer le contenu, voir la divulgation confidentielle sans fichiers publics.

En quoi cela aide-t-il pour les délais réglementaires ?

De nombreux régimes d'incident reposent sur la datation, et un record inviolable indiquant à quel moment vous saviez quoi peut étayer ces appréciations.

  • Aux États-Unis, les règles de la SEC imposent aux émetteurs domestiques de déposer un formulaire 8-K au titre de l'Item 1.05 pour un incident de cybersécurité significatif dans les quatre jours ouvrés suivant la détermination de son caractère significatif — le décompte court à partir de l'appréciation de la matérialité, et non de la découverte. La SEC a également souligné que cette appréciation doit être effectuée sans retard déraisonnable.
  • Dans l'Union européenne, la directive NIS2 fixe un décompte en trois temps pour un incident important : une alerte précoce dans les 24 heures suivant la prise de connaissance de l'incident, une notification d'incident dans les 72 heures, et un rapport final dans un délai d'un mois.
  • Pour les entités financières de l'UE, le règlement sur la résilience opérationnelle numérique (DORA) a introduit des obligations harmonisées de gestion des incidents liés aux TIC et de déclaration des incidents majeurs, applicables depuis le 17 janvier 2025.

Les obligations exactes dépendent de l'entreprise, du secteur, de la juridiction et de l'incident, et elles évoluent dans le temps — il s'agit ici d'un contexte général, non d'un avis juridique. Une preuve ne décide pas si un rapport est requis, et elle ne prouve pas que vous avez respecté un délai. Ce qu'elle peut faire, c'est préserver un record inviolable des artefacts et des appréciations qui sous-tendent ces décisions, afin que la chronologie sur laquelle vous vous êtes appuyé puisse être présentée ultérieurement. Considérez-la comme une preuve susceptible d'étayer un dossier ; elle ne remplace pas un conseil juridique.

À quoi ressemble un flux de preuve concret ?

Définissez un petit ensemble de moments de preuve avant même d'en avoir besoin.

Une entreprise pourrait définir des points de contrôle de preuve d'incident comme suit :

  • T0 : premier signal détecté ou premier lot d'alertes ;
  • T1 : incident déclaré ;
  • T2 : évaluation initiale du périmètre ;
  • T3 : action de confinement lancée ;
  • T4 : brouillon d'appréciation de la matérialité ou du caractère déclarable ;
  • T5 : point pour le conseil d'administration ou la direction ;
  • T6 : brouillon de notification au régulateur ou aux clients ;
  • T7 : rapport d'incident final ;
  • T8 : revue post-incident et plan de remédiation.

Chaque point de contrôle produit un manifeste. Le manifeste peut être haché directement, ou inclus comme feuille Merkle dans une racine d'incident plus large.

Le résultat est une chronologie facile à expliquer par la suite : voici les points de contrôle, voici les artefacts, voici les horodatages publics, et voici comment vérifier que les fichiers correspondent.

Quand engager une racine de Merkle plutôt qu'un record par fichier ?

Recourez à une racine de Merkle lorsque l'ensemble de pièces est volumineux.

Un incident sérieux peut concerner des milliers, voire des millions de lignes de journaux, d'alertes, de paquets, d'empreintes de fichiers, d'événements d'endpoints et de mises à jour de tickets. Publier un record par artefact est coûteux et difficile à gérer.

À la place, construisez un manifeste déterministe, hachez chaque entrée en une feuille, construisez un arbre de Merkle et publiez une seule racine de 32 octets pour le point de contrôle. Vous pourrez ensuite prouver qu'un export de journaux, un événement ou une empreinte de fichier précis figurait dans ce point de contrôle — au moyen d'une courte preuve d'inclusion — sans révéler le reste de l'ensemble de pièces.

Cela convient naturellement pour :

  • les lots quotidiens de pièces d'incident ;
  • les journaux cloud à fort volume ;
  • les listes d'impact sur les clients ;
  • les inventaires d'artefacts d'endpoints ;
  • les manifestes de collecte forensique ;
  • les instantanés d'analyse de vulnérabilités ;
  • les pièces de correctifs et de remédiation.

Une réserve : une racine n'est utile que si vous conservez le manifeste, la liste ordonnée de feuilles et les preuves d'inclusion. La chaîne stocke la racine ; vous stockez tout ce qui est nécessaire pour prouver qu'une feuille relève d'elle. Le même schéma — un seul record représentant un ensemble immense — est traité dans un seul record pour des milliers de fichiers.

Comment fonctionnent les corrections lorsque les faits évoluent ?

Les rapports d'incident changent parce que les faits s'affinent, et le standard permet de rendre cela visible.

Les premières estimations sont souvent fausses. Une équipe peut d'abord croire que 200 comptes sont touchés, puis en découvrir 2 000, puis écarter 150 faux positifs. Ces changements ne devraient pas être dissimulés — ils devraient être explicables.

Un record peut porter un pointeur de remplacement : l'empreinte de transaction de 32 octets d'un record antérieur qu'il remplace. Le record antérieur reste sur la chaîne et demeure vérifiable de façon indépendante ; la chaîne est en ajout-seul, de sorte que le remplacement ne supprime ni n'invalide quoi que ce soit. Le pointeur dit simplement, en somme, ceci est la version ultérieure. Il ne porte aucun champ de motif — tout sens humain appartient au nouveau contenu, non au pointeur.

Cette distinction compte : elle préserve la différence entre une révision honnête et une réécriture discrète. L'historique est visible, ordonné et démontrable.

Qui devrait recevoir les records d'incident scellés ?

Gardez la liste des destinataires courte et réfléchie. Chaque destinataire supplémentaire est une partie de plus qui peut déchiffrer — et, une fois le déchiffrement effectué, divulguer — le texte en clair.

Parmi les destinataires courants :

  • le conseil juridique externe ;
  • le service juridique interne ;
  • le responsable de l'incident ;
  • le RSSI ou la direction de la sécurité ;
  • un partenaire forensique ;
  • un contact au sein d'un régulateur, le cas échéant ;
  • le conseil juridique de l'assurance cyber ou un prestataire référencé ;
  • un comité de sécurité du conseil d'administration ;
  • une identité d'archive de confiance contrôlée par l'entreprise.

Chaque destinataire doit fournir une adresse de réception que vous avez réellement vérifiée hors bande — en confirmant que la clé appartient bien à cette personne, et non à quelqu'un qui se fait passer pour elle. Sceller vers la mauvaise clé revient à sceller pour le mauvais lecteur, et la chaîne ne rattrapera pas cette erreur à votre place ; vérifier un destinataire avant de sceller un fichier explique la marche à suivre. Pour des pièces sensibles à longue durée de vie, préférez l'adresse de réception hybride post-quantique optionnelle là où le flux le permet. Elle est conçue pour résister à une attaque de type « harvest now, decrypt later » (« moissonner maintenant, déchiffrer plus tard »), où un adversaire stocke le texte chiffré aujourd'hui et attend un futur ordinateur quantique pour le casser.

Que ne faut-il jamais inscrire dans les métadonnées publiques ?

Gardez les secrets de l'incident entièrement hors du record public.

Ne publiez pas :

  • de détails d'exploitation en clair ;
  • d'identifiants ;
  • de clés privées ;
  • de données personnelles de clients ;
  • de noms d'hôtes ou d'adresses IP internes sensibles ;
  • de détails d'infrastructure de l'attaquant qui doivent rester confidentiels ;
  • d'analyses juridiques couvertes par le secret professionnel ;
  • d'accusations non étayées ;
  • d'informations réservées au régulateur qui ne devraient pas être publiques.

La chaîne publique doit porter des engagements — empreintes, racines, enveloppes scellées — et non le récit de l'incident. Le récit reste dans vos systèmes et, au besoin, à l'intérieur d'un texte chiffré scellé.

Une preuve montre-t-elle que l'entreprise a bien géré l'incident ?

Non. C'est plus restreint que cela, à dessein.

Une preuve peut montrer que certains fichiers ou manifestes existaient à une date publique. Elle peut montrer qu'une clé de signature donnée s'est portée garante d'un record, lorsque la signature d'auteur optionnelle est présente. Elle peut montrer qu'un artefact ultérieur correspond à un engagement antérieur.

Elle ne prouve pas que l'investigation était complète, que l'entreprise a fait les bons choix, que les délais légaux ont été respectés, que les contrôles étaient efficaces, ou que les clients ont été notifiés correctement. C'est une preuve relative à la datation et à l'intégrité, non à la véracité, au jugement ou à la conformité. Pour la version générale de cette limite, voir ce qu'une preuve ne prouve pas.

Qu'est-ce qui peut mal tourner ?

Les défaillances les plus fréquentes sont opérationnelles, et non cryptographiques.

Vous pouvez horodater les mauvais fichiers. Vous pouvez perdre les pièces originales. Vous pouvez omettre de conserver les feuilles Merkle dont dépend une racine. Vous pouvez glisser un fait sensible dans un champ public. Vous pouvez sceller vers une adresse de réception que personne n'a vérifiée. Vous pouvez laisser trop de personnes déchiffrer. Vous pouvez vous mettre à traiter la couche de preuve comme votre système de déclaration au lieu d'une couche de preuve qui le sous-tend.

La meilleure défense est procédurale : définissez vos points de contrôle de preuve avant un incident, automatisez les tâches fastidieuses et associez le conseil juridique partout où une exposition légale est possible.

En résumé

Les incidents de sécurité ont besoin d'une chronologie qui résiste à la pression.

Label 309 ancre les artefacts, rapports et manifestes d'incident à une date publique. Les records scellés gardent les pièces sensibles chiffrées à l'intention de destinataires choisis. Les racines de Merkle engagent de vastes ensembles de pièces avec un seul record. Les pointeurs de remplacement rendent les corrections visibles plutôt que silencieuses — sans faire confiance à un quelconque serveur ou fournisseur unique.

Utilisez-le pour prouver ce qui existait à quel moment. Ne l'utilisez pas pour remplacer la réponse à incident ou la déclaration légale — et n'attendez pas qu'il prouve quoi que ce soit au-delà de la datation et de l'intégrité.

Pour aller plus loin

securityincident-responseproof-of-existence