Mémo de soutenance

Fiche de révision synthétique pour la soutenance : le pitch, l'architecture à savoir expliquer, le pipeline de détection, les scripts de démo, les pièges techniques et les réponses aux questions probables du jury.

1. Le pitch (30 secondes)

ExfilGuardian est un système de détection d'exfiltration de données en temps réel, en architecture distribuée et multi-plateforme. Un driver kernel intercepte le trafic et le contexte (processus, fichiers, DNS) sur chaque machine, un agent local transmet la télémétrie à un serveur central d'analyse via gRPC/mTLS, et un dashboard desktop présente les alertes corrélées.

Par sa conception — capteur endpoint en Ring 0, contexte processus/fichier, analyse et corrélation centralisées — la solution se rapproche d'un EDR. La différence est le périmètre : on cible l'exfiltration, pas tout le cycle de réponse d'un EDR généraliste.

Sa thèse : aucune technique de détection prise isolément ne suffit contre l'exfiltration (qui ressemble à du trafic légitime). La réponse est une défense en profondeur — plusieurs couches d'analyse indépendantes qui se renforcent, avec un contexte endpoint qu'un capteur réseau seul n'a pas.

2. Le problème (pourquoi c'est dur)

L'exfiltration se cache dans des protocoles légitimes : une requête DNS peut transporter des données encodées, un flux HTTPS peut sortir une base entière. Les NIDS classiques (Suricata/Zeek/Snort) échouent pour 3 raisons :

• Chiffrement (TLS 1.3) → le contenu est masqué.
• Pas de contexte processus → impossible d'attribuer un flux à un binaire.
• Détection post-fait sur le réseau → trop tard.

3. Architecture (à savoir dessiner)

Quatre composants, communication gRPC/Protobuf sécurisée par mTLS :

Endpoint (Windows · Linux · macOS)          Serveur central
  Driver / capture kernel                     Réception gRPC (Tonic :50051, mTLS)
    Windows : WFP (Ring 0)                        │
    Linux   : eBPF / aya                          ▼
    macOS   : libpcap (passif)                Pipeline d'analyse (1 instance)
        │  (IRP inversé / ring buffer)          FlowRecord → DPI ‖ Signatures ‖
        ▼                                                    Comportemental → Corrélation
  Agent local (collecteur fin)  ── gRPC/mTLS ──►    │
    4 flux : paquets/process/fichiers/DNS          ▼
                                               API REST (Axum :8080) ──► Dashboard (Electron + Next.js)

Points clés à expliquer :

• Découplage total : le serveur fonctionne sans modification quel que soit l'OS de l'endpoint. Preuve : Linux et macOS ont été ajoutés sans toucher au serveur, grâce au contrat Protobuf partagé (proto/exfil.proto, 1 service ExfilService, 4 RPC client-streaming).
• Agent = collecteur fin : aucune analyse côté agent (surface d'attaque minimale). Toute l'intelligence est centralisée sur le serveur, où la corrélation a le contexte inter-flux.
• Backend 100 % Rust (memory safety sur des données réseau hostiles) ; dashboard en TypeScript/Electron/Next.

4. Le pipeline de détection (le cœur)

Chaque FlowRecord passe par 3 couches en parallèle (tokio::join!) puis la corrélation :

La corrélation (à maîtriser) :

• Scoring bayésien : P(A∪B) = 1 − (1−P(A))·(1−P(B)) — deux signaux faibles se renforcent.
• Décroissance temporelle : demi-vie 5 min (les vieux signaux comptent moins).
• Bonus de diversité : +10 % par détecteur distinct (plafond +30 %).
• Escalade : confiance > 0,9 → sévérité +1 cran.
• Seuil d'alerte : 0,6 — et il faut ≥ 2 détections corrélées pour lever une alerte (évite les faux positifs sur un signal isolé).

Types clés : PacketMetadata (ce que l'agent envoie) → FlowRecord (flux agrégé, 5-tuple + agent_id) → Detection (un signal) → Alert (corrélée, avec une Confidence 0.0–1.0).

5. Couverture multi-OS (être honnête)

Sur Windows, deux sources ETW (indépendantes du driver WFP) enrichissent le contexte : DNS-Client (requêtes DNS) et Kernel-File (accès fichiers sensibles). Point crucial : ETW est fiable même quand la capture paquets du driver est en défaut.

6. Sécurité & cryptographie

• mTLS activé par défaut : au démarrage, le serveur auto-génère une CA + un certificat serveur (SAN exfil.server.local). À chaque enrollment, un certificat client unique est émis, signé par la CA. Un agent sans certificat signé est rejeté au handshake.
• Enrollment zero-touch « Teleport-style » : POST /api/v1/agent/tokens → un one-liner PowerShell/bash installe tout (certs inline, binaires depuis /static, driver, service). Token à usage unique.
• Auto-défense du driver (Windows) : anti-kill (ObRegisterCallbacks), protection registre (CmRegisterCallbackEx), DKOM Force-Integrity (dev).

7. Déploiement

Déploiement complet en docker-compose sur Dokploy (qui gère Traefik) :

• api (serveur Rust, :8080 REST + :50051 gRPC),
• app (dashboard Next.js en mode serveur standalone → l'auth tourne en prod),
• postgres + un conteneur d'init (schéma Drizzle + compte de démo).

mTLS activé, sous-domaines dédiés (app / api), gRPC exposé pour les agents. Les binaires agent/driver sont poussés sur /static via POST /api/v1/artifacts (protégé par EXFIL_DEPLOY_TOKEN).

8. Les scripts de démo (demo/Run-Demo.ps1)

Menu one-click, 9 axes, en deux tiers honnêtes :

Déroulé conseillé (10 min) : 1 (DGA, Critical + attribution) → 2 (tunnel) → 4 (masquerade svch0st.exe) → 8 (fichiers) → 9 (arbre de processus imbriqué). Ça couvre réseau + endpoint — l'argument fort vs un NIDS.

9. Pièges techniques à connaître (questions vicieuses)

• nslookup est invisible à ETW : il contourne le service DNS Client de Windows. Utiliser Resolve-DnsName / curl (résolveur système) pour que les requêtes soient captées. Les NXDOMAIN sont normaux (la requête part quand même).
• Identité d'agent : dérivée du machine_id stable (posé à l'enrollment), repli sur l'IP — jamais du token partagé (sinon tout un parc fusionnerait en une identité).
• Preuves persistantes (blue team) : la vue processus affiche les processus terminés par défaut — les preuves ne doivent pas disparaître quand un processus malveillant s'arrête.
• Attribution processus : l'alerte DGA dit « powershell.exe a émis ce domaine » — le contexte endpoint qu'un NIDS n'a pas. C'est le différenciateur n°1.

10. Limites assumées (l'honnêteté = une force)

• Capture paquets WFP : bug de longévité (les paquets finissent par ne plus être délivrés). Récup = recréer le driver. ETW (DNS/process/fichiers) reste fiable → c'est le chemin de démonstration solide.
• Détecteurs écrits mais non branchés : empreintes JA3, anomalies de certificat TLS, CUSUM (il manque l'extraction d'un TlsMetadata du handshake jusqu'au pipeline).
• macOS : agent passif (pas de contexte processus) — parité complète = évolution.
• Télémétrie en mémoire côté serveur (perdue au redémarrage) ; tokens d'enrollment en mémoire ; backoff de reconnexion fixe (pas exponentiel).

11. Questions probables du jury + réponses

« En quoi c'est différent d'un IDS/IPS classique ? » On ajoute le contexte endpoint : on relie un flux au processus qui l'a généré (attribution), et on croise 4 sources (réseau, process, fichiers, DNS). Un NIDS ne voit que le réseau, chiffré, sans savoir quel binaire est responsable.

« Comment gérez-vous le TLS 1.3 chiffré ? » On ne déchiffre pas (ce n'est pas un DLP). On analyse des métadonnées et des caractéristiques statistiques : entropie d'un domaine, volume sortant réel, régularité d'un canal (beaconing), TLS vers IP brute sans DNS préalable.

« Pourquoi centraliser l'analyse sur le serveur ? » Agent minimal = surface d'attaque et empreinte réduites. La corrélation a besoin du contexte inter-flux (par destination, par agent, fenêtre temporelle) qu'un agent isolé n'a pas.

« Comment évitez-vous les faux positifs ? » Corrélation bayésienne qui exige ≥ 2 signaux au-dessus d'un seuil (0,6), avec décroissance temporelle. Un signal isolé ne lève pas d'alerte. Une analyse IA (Claude) peut en plus trier les faux positifs probables sur un rapport.

« Le driver n'est pas signé, c'est un problème ? » En développement il est test-signé (Test Signing mode). En production il serait signé par un certificat EV — c'est un point de packaging, pas d'architecture.

« Sécurité de la communication agent↔serveur ? » mTLS bidirectionnel : chaque agent présente un certificat unique émis à l'enrollment et signé par la CA du serveur. Un agent non enrôlé est rejeté au handshake.

« Passage à l'échelle ? » Un seul pipeline partagé, streaming gRPC, sérialisation binaire compacte. Le découplage permet d'ajouter des OS sans toucher au serveur. Limite actuelle : télémétrie en mémoire (une persistance disque/DB serait la prochaine étape).

12. Chiffres à retenir

• 4 composants · 4 flux gRPC · 3 couches d'analyse + corrélation.
• 16 règles de signatures · 9 catégories de détection.
• Seuil d'alerte 0,6 · ≥ 2 détections · fenêtre 5 min · demi-vie 5 min.
• Ports : gRPC 50051, REST 8080, dashboard 3000.
• 3 OS (Windows/Linux complets, macOS passif) · 9 axes de démo.