TL;DR Executive

  • Les métadonnées réseau sont puissantes pour établir des séquences factuelles (qui a communiqué avec qui, quand, combien, via quel protocole), mais elles ne prouvent pas à elles seules l’intention ni le contenu applicatif complet.[1][4][5][6]
  • En litige civil, la recevabilité dépend surtout de l’authentification (preuve que l’artefact est bien ce qu’il prétend être) et de la fiabilité méthodologique de l’expert.[7][8]
  • Le standard technique des flux (NetFlow v9/IPFIX) repose sur des templates et des choix de collecte; ces choix influencent directement l’interprétation probatoire.[4][5]
  • Les techniques d’échantillonnage/filtrage réduisent la charge mais introduisent des biais mesurables qui doivent être explicités dans le rapport expert.[11]
  • Zeek structure l’observation en journaux analytiques (p. ex. conn.log) utiles pour la reconstruction de timeline, avec des limites connues (champs optionnels, visibilité partielle, asymétries).[6][12]
  • La chaîne de possession et l’ordre de volatilité restent déterminants: une collecte techniquement correcte mais mal documentée perd de la valeur en cour.[2][7]
  • En découverte civile (e-discovery), la proportionnalité et la forme de production des ESI conditionnent la stratégie de collecte réseau.[9][10]
  • Niveau de confiance global: élevé sur les principes, moyen sur la transposition uniforme entre juridictions (variations locales).

Problématique et objectifs

Question de recherche. Dans quelle mesure les métadonnées réseau (PCAP, NetFlow/IPFIX, Zeek) peuvent-elles être utilisées de façon robuste en litige civil pour soutenir une preuve technique?

Objectifs.

  1. Définir le périmètre probatoire réel de chaque type d’artefact.
  2. Identifier les conditions minimales d’admissibilité méthodologique.
  3. Dégager une méthode de production expert-compatible (collecte → conservation → analyse → rapport).

Méthodologie

  • Stratégie de recherche: revue croisée de normes techniques (IETF), guides institutionnels (NIST), documentation outillage (Zeek/tcpdump/Wireshark) et règles de preuve/procédure civile (FRE/FRCP).
  • Critères d’inclusion: sources normatives/officielles, documentation primaire, texte juridique de référence, pertinence directe PCAP/flow logs/forensics réseau.
  • Critères d’exclusion: billets marketing, contenu non traçable, sources bloquées/inaccessibles ou non vérifiables.
  • Nombre d’URL analysées: 13 (12 retenues, 1 exclue pour accès/brouillage anti-bot).
  • Limites méthodologiques: corpus majoritairement orienté US/international technique; la pratique québécoise/canadienne doit être arrimée localement par jurisprudence et règles de preuve applicables.

Cadre conceptuel / technique / juridique

  • PCAP: capture paquet par paquet, forte granularité temporelle et protocolaire; peut inclure données de contenu selon capture.[6]
  • NetFlow/IPFIX: métadonnées agrégées de flux (5-tuple, volumes, durées, timestamps), moins intrusif que PCAP complet, mais dépendant des templates/exporteurs.[4][5]
  • Zeek: moteur d’observabilité qui transforme trafic/PCAP en logs analytiques structurés (ex. conn.log) pour investigation et corrélation.[6][12]
  • Admissibilité (US de référence): authenticité de l’artefact (FRE 901) et fiabilité de l’expertise (FRE 702).[7][8]
  • Procédure civile (ESI): étendue et forme de production cadrées par FRCP 26/34 (proportionnalité, forme raisonnablement exploitable).[9][10]

Analyse critique des résultats

1) Valeur probatoire intrinsèque: haute pour la chronologie, limitée pour l’attribution humaine

Les guides NIST situent explicitement le réseau comme source forensique clé, mais rappellent qu’il faut l’intégrer à d’autres artefacts (hôtes, applications, contexte organisationnel).[1][3] Les définitions NetFlow/IPFIX confirment que la donnée est d’abord une description de flux, pas une preuve complète de contenu/intention.[4][5]

« …providing practical guidance on performing computer and network forensics… » — NIST SP 800-86 [1]

Conséquence civile: utile pour démontrer des faits techniques (exfiltration probable, latéralisation, synchronisation d’événements), insuffisant seul pour établir l’auteur humain sans corroboration (identité, contrôle poste, journalisation IAM, etc.).[1][3][6]

2) Qualité de la collecte: déterminante et souvent sous-documentée

RFC 3227 demeure centrale: ordre de volatilité, journal de collecte, chaîne de possession et minimisation de la contamination.[2] Côté pratique, tcpdump et Wireshark documentent des paramètres qui affectent la fidélité (buffer, drops noyau, snaplen, mode capture), donc la force de la preuve.[6][13]

« If evidence collection is done correctly … [it] stands a much greater chance of being admissible … » — RFC 3227 [2]

En litige civil, un PCAP non accompagné de logs d’acquisition (horloge, interface, perte de paquets, hash, opérateur) sera vulnérable à contestation méthodologique.[2][7][8][13]

3) NetFlow/IPFIX/PSAMP: efficacité opérationnelle vs biais statistiques

IPFIX (RFC 7011) normalise l’export de flux via templates; NetFlow v9 est plus ancien et informatif (non standard IETF complet), à contextualiser.[4][5] Les techniques PSAMP de sampling/filtering, bien qu’indispensables à l’échelle, modifient la représentativité de la preuve.[11]

« …Sampling and Filtering techniques … provides the basis … for reporting the technique in use… » — RFC 5475 [11]

Donc, un rapport expert doit déclarer explicitement: taux d’échantillonnage, points d’observation, perte connue, et impact attendu sur faux négatifs/faux positifs analytiques.[4][5][11]

4) Zeek comme couche d’intelligibilité: très utile, mais pas magique

Zeek explicite que conn.log modélise TCP/UDP/ICMP en sémantique de flux, avec champs structurés (uid, id, duration, conn_state, etc.) adaptés à l’analyse de séquences.[12] Cette structuration améliore la reproductibilité analytique, mais ne supprime ni les zones aveugles réseau ni les limites de visibilité du capteur.[6][12]

5) Articulation juridique civile: authenticité + fiabilité + proportionnalité

FRE 901 exige une base suffisante d’authentification; FRE 702 exige des méthodes fiables appliquées correctement.[7][8] FRCP 26/34 encadrent la production ESI et la forme de remise.[9][10] En pratique, cela pousse vers des productions hybrides: extraits ciblés PCAP + exports Zeek/flow + documentation de méthode + annexes de validation.

Discussion

Les sources convergent vers un principe: la preuve réseau convainc lorsqu’elle est triangulée. PCAP apporte la granularité, NetFlow/IPFIX la couverture à grande échelle, Zeek la lisibilité forensique. La robustesse juridique vient moins d’un outil que de la discipline de preuve: capture contrôlée, conservation démontrable, analyse reproductible, et narration experte sobre (hypothèses vs faits établis).

En litige civil, la pression coûts-délais favorise les métadonnées de flux; toutefois, si la contestation porte sur un acte précis (ex. exfiltration d’un fichier déterminé), l’absence de capture contenu/contextuelle peut devenir une faiblesse. Une stratégie graduée est donc préférable: baseline par flows/logs, puis acquisition ciblée plus riche selon matérialité et proportionnalité.[9][10]

Limites et incertitudes

  • Variabilité inter-juridictionnelle (la grille FRE/FRCP n’est pas universelle).
  • Dépendance forte à la qualité de l’horodatage et à la synchronisation NTP (non toujours documentée dans les dossiers).
  • Les guides NIST cités sont solides mais certains sont anciens; leurs principes restent pertinents, les implémentations modernes évoluent rapidement.[1][3]
  • Les métadonnées réseau peuvent être ambiguës sur l’attribution individuelle (poste partagé, NAT, VPN, proxies).

Conclusion

Les métadonnées réseau (PCAP/NetFlow/Zeek) sont hautement utiles en litige civil pour reconstruire des faits techniques et tester des hypothèses causales, à condition d’être présentées dans une chaîne méthodologique complète (collecte, conservation, validation, interprétation). Elles sont rarement autosuffisantes pour l’attribution humaine ou l’intention, mais deviennent très probantes lorsqu’elles sont corroborées par des artefacts hôte/applicatifs et une expertise conforme aux exigences d’authentification et de fiabilité.[7][8]

Références

  1. NIST SP 800-86, *Guide to Integrating Forensic Techniques into Incident Response* — NIST, 2006 — https://csrc.nist.gov/pubs/sp/800/86/final
  2. RFC 3227, *Guidelines for Evidence Collection and Archiving* — IETF, 2002 — https://www.rfc-editor.org/rfc/rfc3227
  3. NIST SP 800-61 Rev.2, *Computer Security Incident Handling Guide* — NIST, 2012 — https://csrc.nist.gov/pubs/sp/800/61/r2/final
  4. RFC 7011, *Specification of the IPFIX Protocol* — IETF, 2013 — https://www.rfc-editor.org/rfc/rfc7011
  5. RFC 3954, *Cisco NetFlow Services Export Version 9* — IETF (Informational), 2004 — https://www.rfc-editor.org/rfc/rfc3954
  6. Wireshark User’s Guide, Chapter 1 — Wireshark Foundation, consulté 2026-02-13 — https://www.wireshark.org/docs/wsug_html_chunked/ChapterIntroduction.html
  7. Federal Rules of Evidence, Rule 901 — Legal Information Institute (Cornell), consulté 2026-02-13 — https://www.law.cornell.edu/rules/fre/rule_901
  8. Federal Rules of Evidence, Rule 702 — Legal Information Institute (Cornell), consulté 2026-02-13 — https://www.law.cornell.edu/rules/fre/rule_702
  9. Federal Rules of Civil Procedure, Rule 26 — Legal Information Institute (Cornell), consulté 2026-02-13 — https://www.law.cornell.edu/rules/frcp/rule_26
  10. Federal Rules of Civil Procedure, Rule 34 — Legal Information Institute (Cornell), consulté 2026-02-13 — https://www.law.cornell.edu/rules/frcp/rule_34
  11. RFC 5475, *Sampling and Filtering Techniques for IP Packet Selection* — IETF, 2009 — https://datatracker.ietf.org/doc/html/rfc5475
  12. Zeek Documentation, *conn.log* / `Conn::Info` — Zeek Project, mis à jour 2026, ; https://docs.zeek.org/en/current/scripts/base/protocols/conn/main.zeek.html#type-Conn::Info — https://docs.zeek.org/en/current/logs/conn.html
  13. tcpdump(8) manual page — man7.org, consulté 2026-02-13 — https://man7.org/linux/man-pages/man8/tcpdump.8.html

Articles qui pourraient vous intéresser