Chaîne de possession numérique : méthode simple et défendable

Résumé exécutif

La chaîne de possession numérique n’est pas un formulaire administratif; c’est un mécanisme de confiance. Elle permet de démontrer, de manière continue, qui a eu accès à quel artefact, à quel moment, pour quelle finalité et sous quelles protections d’intégrité. Sans cette continuité documentaire, la force probatoire d’une preuve diminue rapidement, même lorsque la donnée semble techniquement pertinente. [1] [2] [3] [12] [13]

La méthode “simple et défendable” repose sur sept invariants: identification unique, réception documentée, gel de l’original, acquisition sur copie, hash, journal de transferts et contrôle d’accès. Cette base est compatible autant avec les dossiers PME que les incidents cloud complexes. [3] [4] [6] [7] [8]

Ce qu’on entend par chaîne de possession

Définition opérationnelle: ensemble de preuves documentaires qui relient l’état initial d’un artefact à son état au moment de sa production, sans zone grise sur les personnes, les manipulations, les copies et l’entreposage. Le cœur du sujet n’est pas la quantité d’entrées dans le registre, mais la cohérence entre le registre, les exports techniques et les décisions d’enquête. [2] [3] [14]

Les 7 règles minimales qui tiennent en audience

1) Identifiant unique dès la réception

Attribuer un code immuable à chaque pièce (ex: INC-2026-02-4300-E01). Éviter les noms flottants (“clé USB de Jean”). Cet identifiant doit apparaître partout: registre, exports, captures d’écran, dossier de stockage. [3]

2) État initial décrit immédiatement

Au moment de la prise en charge: support, état physique/logique, circonstances de remise, personnes présentes, heure locale et UTC. Plus la description initiale est précise, moins la contestation ultérieure peut attaquer la provenance. [1] [2] [3]

3) Original protégé, analyse sur copie

L’original doit être gelé (accès restreint), l’analyse se fait sur copie de travail identifiée. Dans le cloud, l’équivalent passe par snapshot/export immuable avec contrôles d’accès dédiés. [6] [7] [8]

4) Intégrité vérifiable

Calculer et conserver les empreintes (hash) des artefacts principaux au moment de l’acquisition et avant production. Toute différence doit être expliquée, jamais ignorée. [3]

5) Journal des transferts bilatéral

Chaque transfert contient remise/réception, identité des personnes, date/heure, objet transféré, motif et destination. Les “passages verbaux” sont la source de contestation la plus fréquente. [1] [3]

6) Séparation des rôles

La même personne ne devrait pas décider seule de l’orientation, collecter la preuve et valider sa propre conformité. Une séparation minimale réduit le risque d’erreur non détectée. [4] [14]

7) Limites déclarées noir sur blanc

Une chaîne “parfaite” n’existe pas. Ce qui est défendable, c’est une chaîne documentée avec limites explicites (rétention écoulée, source indisponible, accès tardif, horloge incertaine). [1] [5] [9] [11]

Modèle simple de registre (version cabinet)

Flux recommandé: de la réception à la production

1. Réception: identification, état initial, premier enregistrement de possession.
2. Gel: protection de l’original et des journaux critiques associés.
3. Acquisition: collecte méthodique, hash, stockage contrôlé.
4. Analyse: uniquement sur copie de travail, avec journal des manipulations.
5. Corrélation: timeline multi-sources avec niveau de confiance par assertion.
6. Production: dossier de preuve incluant chaîne, méthodes, limites, références.

Ce flux est compatible avec les pratiques IR modernes et les contraintes probatoires: il maintient la lisibilité technique sans alourdir inutilement les opérations. [1] [4] [15] [16]

Spécificités cloud et M365

Dans les environnements cloud/SaaS, la “pièce originale” est souvent logique (export/API/snapshot), non physique. La chaîne de possession doit alors porter davantage sur la méthode d’extraction, l’identité des comptes utilisés, la portée temporelle de la requête et les contrôles d’intégrité des exports produits. [6] [7] [8] [9] [10] [11]

En pratique, on documente aussi les dépendances de rétention/licence et la latence de disponibilité des journaux pour éviter les interprétations erronées du type “absence de preuve = absence d’événement”. [9] [10] [11]

Objections fréquentes et réponses défendables

“On n’a pas le temps de tout documenter”

Réponse: documenter 8 champs minimaux prend quelques minutes et prévient des heures de contestation ultérieure. Le coût marginal est faible, la valeur probatoire gagnée est élevée.

“On a déjà les captures d’écran”

Réponse: une capture sans provenance, horodatage fiable et chaîne de possession est faible seule; elle doit être reliée à des journaux sources et à un contexte d’acquisition. [5] [12] [13]

“Le fournisseur cloud garde tout”

Réponse: la conservation dépend de la configuration et du tenant. Il faut vérifier la réalité de la rétention, pas l’assumer. [9] [10] [11]

Checklist de contrôle qualité avant remise à l’avocat

• Toutes les pièces ont un identifiant stable.
• Tous les transferts critiques sont signés/remis/reçus.
• Les hashes des artefacts principaux sont présents.
• Les méthodes d’extraction sont décrites (outil, version, compte).
• La timeline distingue faits observés et inférences.
• Les limites techniques sont listées explicitement.

Incertitudes et limites

La méthode proposée est conçue pour la robustesse opérationnelle et probatoire. Elle ne remplace pas un avis juridique adapté à la juridiction, ni l’analyse contradictoire d’un expert tiers lorsque les enjeux sont élevés. En présence de données chiffrées, d’infrastructures hybrides ou de forte contestation, il faut documenter davantage le contexte d’acquisition et la chaîne de transformations. [1] [3] [12] [13] [14]

Conseil pratique: si votre registre ne permet pas à une tierce personne de reconstituer le parcours complet d’une pièce en 10 minutes, il est encore trop implicite.

Références

1. NIST SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response — https://csrc.nist.gov/pubs/sp/800/86/final
2. RFC 3227 — Guidelines for Evidence Collection and Archiving — https://www.rfc-editor.org/rfc/rfc3227
3. ISO/IEC 27037:2012 — Identification, collection, acquisition and preservation of digital evidence — https://www.iso.org/standard/44381.html
4. NIST SP 800-61r2 — Computer Security Incident Handling Guide — https://www.nist.gov/privacy-framework/nist-sp-800-61
5. NIST SP 800-92 — Guide to Computer Security Log Management — https://csrc.nist.gov/pubs/sp/800/92/final
6. AWS — Collect and analyze forensic evidence — https://docs.aws.amazon.com/security-ir/latest/userguide/collect-analyze-forensic-evidence.html
7. Microsoft Azure — Computer Forensics Chain of Custody — https://learn.microsoft.com/en-us/azure/architecture/example-scenario/forensics/
8. Google Cloud — Collecting and analyzing cloud forensics — https://cloud.google.com/transform/how-google-does-it-collecting-and-analyzing-cloud-forensics
9. Microsoft Purview — Search the audit log — https://learn.microsoft.com/en-us/purview/audit-search
10. Microsoft Entra — Sign-in logs — https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins
11. Office 365 Management Activity API reference — https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-reference
12. LCCJTI (Québec) — https://www.legisquebec.gouv.qc.ca/fr/document/lc/C-1.1
13. Code civil du Québec — Preuve technologique (art. 2837 et suiv.) — https://www.legisquebec.gouv.qc.ca/fr/document/lc/CCQ-1991#se:2837
14. Sedona Canada Principles Addressing Electronic Discovery — https://thesedonaconference.org/publication/The%20Sedona%20Canada%20Principles%20Addressing%20Electronic%20Discovery
15. Plaso (log2timeline) Documentation — https://plaso.readthedocs.io/en/latest/sources/user/Using-log2timeline.html
16. Timesketch — Collaborative timeline analysis — https://timesketch.org/