Préservation des preuves numériques : les 24 premières heures

Résumé exécutif

Les 24 premières heures après un incident numérique déterminent souvent 80% de la valeur probatoire finale d’un dossier. Dans cette fenêtre, les traces les plus utiles sont soit volatiles, soit menacées par des mécanismes automatiques de rotation, purge ou synchronisation. L’objectif n’est pas de “tout collecter”, mais de protéger vite les sources critiques, documenter chaque geste et maintenir une chaîne de possession explicite du premier contact jusqu’à l’analyse. [1] [2] [3] [4] [5]

Nos recherches internes sur les environnements cloud, M365 et timelines multi-sources montrent une constante: ce qui fragilise les dossiers n’est pas l’absence absolue de données, mais l’absence de méthode reproductible (qui a fait quoi, quand, pourquoi, avec quel outil, et sur quelle copie). Sans cette discipline, la contestation adverse porte moins sur le fond que sur la crédibilité technique du parcours de preuve. [6] [7] [8] [9] [10] [11] [15] [16]

Pourquoi la fenêtre 0–24h est décisive

Trois phénomènes se superposent dans les premières heures: (1) volatilité technique (sessions, mémoire, états transitoires), (2) destruction logique (politiques de rétention, écrasement d’événements, housekeeping applicatif), et (3) contamination humaine (actions improvisées, comptes partagés, captures partielles sans contexte). Une stratégie défendable consiste à stabiliser ces trois axes avant toute analyse “curieuse”. [1] [2] [4] [5]

Le principe directeur reste simple: protéger d’abord l’intégrité et la traçabilité, puis seulement accélérer l’investigation. En litige, une preuve imparfaite mais proprement préservée vaut mieux qu’un corpus plus volumineux collecté sans gouvernance documentaire. [3] [12] [13] [14]

Décisions à prendre dans la première heure

• Nommer un responsable preuve unique (et un remplaçant) avec mandat explicite de journalisation.
• Émettre un avis de conservation (legal hold) aux équipes TI et métiers concernées.
• Bloquer les purges à haut risque (boîtes courriel ciblées, logs critiques, journaux SaaS, snapshots éphémères).
• Segmenter les rôles: équipe opérationnelle (containment) vs équipe preuve (acquisition/traçabilité).
• Décider des sources prioritaires selon l’hypothèse d’incident (compte compromis, exfiltration, sabotage, fraude interne).

Cette gouvernance initiale réduit l’ambiguïté temporelle et protège le dossier contre les contestations classiques (“vous avez modifié l’état de la preuve en investiguant”). [1] [4] [9] [14]

Matrice de priorisation des sources (0–6h)

Identité et accès (Entra sign-ins, changements de rôles/applications), messagerie (audit, règles, délégations), documents collaboratifs (partages, téléchargements, liens externes), cloud infrastructure (actions control-plane, snapshots, logs d’API) et endpoint (artefacts locaux, USB, scripts). L’ordre exact dépend du scénario, mais la règle est d’acquérir d’abord ce qui se dégrade vite ou s’écrase vite. [2] [5] [6] [7] [8] [9] [10] [11]

Exemple pratique: en soupçon d’exfiltration via compte M365, les journaux d’authentification et activités d’audit doivent être capturés avant l’extraction massive des fichiers locaux, car leur valeur temporelle est immédiatement exploitable pour établir la séquence de faits. [9] [10] [11]

Protocole opérationnel 0–2h

1) Stabilisation et périmètre

Définir le périmètre initial (personnes, comptes, appareils, espaces cloud, période suspecte). Éviter d’élargir trop vite: un périmètre instable crée de la dette probatoire et multiplie les copies non maîtrisées. Utiliser un journal maître daté avec identifiant d’incident unique. [1] [4]

2) Préservation prioritaire

Capturer les artefacts à forte valeur de corrélation: événements de connexion, modifications de droits, règles de boîte aux lettres, activités de partage/téléchargement, actions administratives cloud. Conserver les exports bruts et hashés; travailler sur copies de travail séparées. [3] [5] [6] [7] [9] [10]

3) Journal de décision

Documenter chaque arbitrage: pourquoi telle source a été priorisée, quels risques ont été acceptés, quelles limites subsistent. Cette transparence est déterminante en contre-expertise. [1] [3] [14]

Protocole 2–6h: acquisition structurée

À ce stade, l’objectif est de passer de “préserver” à “acquérir proprement”. On formalise un inventaire des artefacts: source, méthode d’extraction, plage temporelle, format, hash, opérateur, heure, destination de stockage. On introduit ensuite une normalisation temporelle unique (UTC) en conservant les timestamps d’origine pour éviter les erreurs d’interprétation. [2] [3] [5] [15] [16]

Pour les environnements cloud, privilégier des procédures répétables (scripts validés, comptes d’investigation dédiés, coffre de preuves immuable). L’automatisation est utile, mais ne remplace pas la justification méthodologique dans le rapport d’expertise. [6] [7] [8]

Protocole 6–12h: corrélation et hypothèses

Construire une timeline multi-sources en trois couches: événements bruts, événements normalisés, assertions analytiques. Cette séparation évite de confondre observation et interprétation. Les hypothèses (exfiltration, abus d’admin, pivot lateral, suppression ciblée) doivent pointer vers des éléments sources vérifiables. [1] [2] [15] [16]

Une bonne pratique consiste à qualifier chaque assertion par un niveau de confiance (élevé / moyen / faible) et une raison explicite (corroboration multi-source, source unique, horloge incertaine, latence d’ingestion). [5] [9] [11]

Protocole 12–24h: décision de suite et gel du dossier

À 24h, le dossier doit contenir: (1) inventaire des sources, (2) journal de chaîne de possession, (3) exports bruts hashés, (4) timeline initiale, (5) limites connues, (6) plan d’actions 24–72h. C’est à ce moment qu’on décide si l’affaire reste en triage interne ou passe en mandat expert approfondi. [1] [3] [4]

Cette discipline protège la capacité d’être contradictoire: vous pouvez expliquer ce qui a été fait, ce qui n’a pas pu être fait, et pourquoi. C’est exactement ce que cherchent juges et arbitres lorsqu’ils évaluent la fiabilité technique d’un récit. [12] [13] [14]

Erreurs fréquentes observées dans les premières 24h

1. Collecte opportuniste sans plan: multiplication des exports sans nomenclature.
2. Mélange des rôles: la même personne contient, collecte, analyse et décide.
3. Absence de hash et d’horodatage: impossibilité de prouver la non-altération.
4. Dépendance à une seule source: corrélation insuffisante en contre-interrogatoire.
5. Confusion fuseaux/UTC: séquence causale renversée.
6. Suppression ou modification “de bon sens”: contamination involontaire de preuve.

Chaque erreur est évitable avec une procédure courte mais stricte. La clé est la répétabilité: un protocole que l’équipe peut appliquer même sous stress. [1] [2] [3] [4] [5]

Checklist de validation avant fin de journée

• Un incident ID unique est attribué.
• Le registre de chaîne de possession contient au moins réception, transferts et stockage.
• Les exports critiques sont hashés et stockés en zone contrôlée.
• La timeline initiale inclut source + niveau de confiance.
• Les incertitudes sont écrites (et non implicites).
• La décision d’escalade expert est tracée.

Incertitudes et limites

Les recommandations ci-dessus s’appuient sur standards (NIST, RFC, ISO) et documentations éditeurs cloud/M365. La recevabilité finale dépend toutefois du contexte de litige, du droit applicable et de la qualité de la chaîne de documentation concrètement maintenue dans votre dossier. Une source officiellement “fiable” reste contestable si sa collecte locale a été mal gouvernée. [1] [3] [6] [7] [8] [12] [13] [14]

Besoin d’un regard expert? Si votre équipe hésite entre triage interne et mandat externe, fixez une revue de 45 minutes avec dossier de preuve préliminaire: inventaire des sources, journal d’actions et trois hypothèses techniques prioritaires.

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/