Résumé exécutif

Une chronologie forensique exploitable en litige n’est pas une simple liste d’événements triés par date. C’est un modèle structuré qui sépare données brutes, transformations et inférences, avec traçabilité complète de chaque étape. [1] [2] [10]

Les causes d’échec les plus fréquentes sont connues: horodatages mélangés, corrélation par intuition, absence de niveau de confiance, et rapport qui mélange faits observés et interprétations. [1] [2] [6] [7] [8]

Architecture recommandée en 3 couches

Couche A — Événements bruts

Conserver les événements tels qu’exportés (logs, headers, traces système, API) sans altération de la source.

Couche B — Événements normalisés

Normaliser temps/format/champs (UTC, identifiants, types d’action), tout en conservant l’original pour auditabilité. [2]

Couche C — Assertions analytiques

Formuler les conclusions intermédiaires avec référence explicite aux événements sources et au degré de confiance.

Étapes pratiques

  1. Inventaire des sources (poste, cloud, messagerie, identité, réseau).
  2. Contrôle qualité temporel (UTC, fuseau, offsets, latence d’ingestion).
  3. Corrélation par identifiants stables (compte, ressource, session, Message-ID).
  4. Construction timeline avec outils adaptés (Plaso/Timesketch/Autopsy).
  5. Validation croisée des assertions critiques.
  6. Rédaction séparant faits et hypothèses.

La corrélation par identifiants est souvent plus fiable que la corrélation uniquement temporelle. [3] [4] [5] [9]

Ce qui rend une timeline défendable

  • Chaque événement clé pointe vers son artefact source.
  • Chaque transformation est décrite (parse, timezone, fusion).
  • Chaque assertion porte un niveau de confiance.
  • Chaque zone d’incertitude est explicitée.

Exemple de formulation robuste

Fait observé: compte X authentifié à 10:14:23Z depuis IP Y.
Fait observé: téléchargement document Z à 10:17:02Z.
Inférence: activité cohérente avec exfiltration ciblée (confiance moyenne-élevée), sous réserve de NAT partagé et d’absence d’artefacts endpoint contradictoires.

Erreurs qui cassent la crédibilité

  • “Time travel” involontaire causé par fusion locale/UTC non maîtrisée.
  • Événements agrégés lus comme événements instantanés.
  • Absence de distinction entre “absence de log” et “absence d’action”.
  • Rapport sans annexe méthodologique reproductible.

Règle simple: si un tiers ne peut pas reproduire votre chronologie à partir des sources listées, la timeline n’est pas encore prête pour un litige.

Incertitudes et limites

Toute timeline comporte des angles morts (rétention, échantillonnage, systèmes non journalisés). Une chronologie utile ne prétend pas à l’omniscience; elle documente précisément ce qu’elle couvre et ce qu’elle ne couvre pas. [1] [6] [7] [8] [10]

Références

  1. NIST SP 800-86 — https://csrc.nist.gov/pubs/sp/800/86/final
  2. RFC 3339 timestamps — https://www.rfc-editor.org/rfc/rfc3339
  3. Plaso log2timeline — https://plaso.readthedocs.io/en/latest/sources/user/Using-log2timeline.html
  4. Timesketch — https://timesketch.org/
  5. Autopsy timeline documentation — https://www.sleuthkit.org/autopsy/docs/user-docs/4.21.0/timeline_page.html
  6. Microsoft Purview audit search — https://learn.microsoft.com/en-us/purview/audit-search
  7. Cloud Audit Logs overview (GCP) — https://cloud.google.com/logging/docs/audit
  8. AWS CloudTrail user guide — https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html
  9. RFC 5322 Message-ID — https://www.rfc-editor.org/rfc/rfc5322
  10. NIST SP 800-92 — https://csrc.nist.gov/pubs/sp/800/92/final

Articles qui pourraient vous intéresser