Résumé exécutif

Ce protocole avocat est conçu pour être utilisé sous pression, sans perdre la rigueur probatoire. Il traduit les standards techniques (NIST/ISO/RFC), les réalités cloud/M365 et les exigences juridiques de preuve technologique en une séquence d’actions concrètes: qui contacter, quoi geler, quoi documenter, quoi déléguer et quand escalader vers un expert externe. [1] [2] [3] [4] [6] [7] [8] [9] [10] [11] [12] [13]

Le format est volontairement “opérationnel” et peut être utilisé tel quel comme checklist de dossier. Chaque bloc inclut un objectif, des actions obligatoires, des erreurs à éviter et un résultat attendu. [14]

Phase A — Pré-incident (à préparer maintenant)

Objectif

Réduire le temps de réaction et éviter les décisions improvisées qui endommagent la preuve.

Checklist

  • Nommer un responsable preuve et un remplaçant.
  • Valider un modèle de registre de chaîne de possession.
  • Préparer un modèle d’avis de conservation (legal hold).
  • Documenter la carte des sources (M365, cloud, endpoint, mobile, sauvegardes).
  • Définir les seuils d’escalade expert (enjeu, volume, sensibilité, urgence).

Résultat attendu: le cabinet peut déclencher un protocole cohérent en moins de 30 minutes. [1] [3] [4] [14]

Phase B — Déclenchement (0–60 minutes)

Objectif

Stabiliser la preuve avant toute exploration intrusive.

Checklist

  1. Créer l’ID incident et ouvrir le journal maître.
  2. Émettre l’avis de conservation aux équipes concernées.
  3. Suspendre les purges/rétentions critiques identifiées.
  4. Geler les accès administratifs non essentiels.
  5. Confirmer la séparation des rôles (containment vs preuve).

Erreur typique à éviter: “on regarde d’abord, on documentera après”. C’est l’inverse qui tient en litige. [1] [2] [3]

Phase C — Fenêtre 1–6 heures

Objectif

Préserver les artefacts à forte valeur temporelle et décisionnelle.

Checklist priorisée

  • Identité: sign-ins, changements de rôles, applications consenties. [10]
  • Audit transversal: recherches Purview ciblées par période et comptes. [9]
  • M365 API: confirmer disponibilité/latence des activités. [11]
  • Cloud infra: actions control-plane, snapshots, logs d’accès API. [6] [7] [8]
  • Contexte local: périphériques, traces endpoint, exports critiques.

Résultat attendu: un paquet d’artefacts bruts, horodatés, avec provenance et hash. [3]

Phase D — Fenêtre 6–24 heures

Objectif

Produire un premier récit chronologique défendable, avec incertitudes explicites.

Checklist

  • Normaliser tous les temps en UTC (conserver l’original).
  • Créer la timeline multi-sources (brut / normalisé / assertions).
  • Classer chaque assertion par niveau de confiance.
  • Identifier les trous de preuve et les actions correctives 24–72h.
  • Décider de l’escalade vers expertise externe si seuil atteint.

Résultat attendu: une note de situation exploitable juridiquement, pas seulement un lot de fichiers techniques. [1] [2] [15] [16]

Checklist d’escalade expert (go / no-go)

CritèreSeuil d’alerteDécision recommandée
Enjeu financier/réputationÉlevé ou systémiqueGo expert externe
Multiples plateformes (M365 + cloud + endpoint)OuiGo expert externe
Incertitude temporelle majeureOuiGo expert externe
Suspicion d’effacement/anti-forensicsOuiGo expert externe
Dossier simple et bien bornéOuiTriage interne possible

Questions à poser immédiatement à l’équipe TI

  1. Quelles politiques de rétention/purge s’appliquent aux comptes et logs concernés?
  2. Quels changements administratifs ont été faits depuis la détection?
  3. Quels comptes ont accédé aux artefacts depuis l’ouverture de l’incident?
  4. Quelles exportations ont déjà été réalisées et comment sont-elles stockées?
  5. Dispose-t-on des journaux d’authentification et d’audit sur la période suspecte?
  6. Quelles sources sont manquantes ou partiellement disponibles?

Questions à poser à l’expert forensique pressenti

  1. Quelle méthodologie utilisez-vous pour préserver la chaîne de possession de bout en bout?
  2. Comment gérez-vous la normalisation temporelle et les incertitudes de timeline?
  3. Quels artefacts considérez-vous prioritaires dans notre scénario précis?
  4. Comment documentez-vous les limites et les hypothèses de travail?
  5. Quels livrables intermédiaires peut-on attendre dans les 48 premières heures?

Gabarit prêt à copier — Journal d’actions (extrait)

Incident ID: ________
Date/heure ouverture: ________ (locale + UTC)
Responsable preuve: ________
Action #1: ________ (qui / quoi / quand / pourquoi / résultat)
Artefact associé: ________ (source / format / hash / emplacement)
Transfert: remise ________ / réception ________ / heure ________
Limite constatée: ________
Décision suivante: ________

Avant production au tribunal (ou à la partie adverse)

  • Vérifier cohérence entre registre, exports et timeline.
  • S’assurer que toutes les citations techniques pointent vers artefacts identifiables.
  • Séparer clairement faits observés, inférences et opinions.
  • Déclarer explicitement les limites (rétention, latence, angle mort).
  • Conserver les versions de travail avec trace de modifications.

Incertitudes et limites

Ce protocole n’est pas un avis juridique et doit être adapté au dossier, à la juridiction et au niveau de contestation anticipé. Sa force vient de son exécution disciplinée: sans journal d’actions, sans corrélation multi-sources et sans déclaration des limites, même un bon constat technique peut perdre de sa portée probatoire. [1] [3] [4] [9] [10] [11] [12] [13] [14]

Usage recommandé: imprimer cette checklist et l’utiliser comme feuille de route au moment où l’incident est signalé. Les 60 premières minutes sont les plus rentables pour protéger la preuve.

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/

Articles qui pourraient vous intéresser