SWORN : j'ai bâti une passerelle DFIR qui signe cryptographiquement chaque finding

La DFIR est la discipline où il faut prouver ce qu'on a fait, pas juste raconter ce qu'on a trouvé. SANS a livré Protocol SIFT début 2026 comme réponse explicite à la DFIR assistée par IA : le LLM dirige le flux de travail, les utilitaires forensiques déterministes restent la seule source de production analytique. Le brief du hackathon le cadre net.

Parce que les utilitaires DFIR déterministes restent la seule source de production analytique, la validation, l'interprétation et le rapport d'analyse sont toujours effectués par l'enquêteur, pas par l'IA. — Rob T. Lee, SANS, à propos de Protocol SIFT

SWORN prend ce vocabulaire au pied de la lettre. C'est un serveur MCP personnalisé, la deuxième des quatre approches architecturales acceptées par les règles du hackathon Find Evil!. Il s'installe entre l'agent et le toolset SIFT et impose la contrainte d'inférence comme du code, pas comme un prompt système.

Les cinq fossés

Voici les verrous qu'aucune autre soumission seule de Find Evil! n'était attendue à combiner. Chacun est imposé dans le code et vérifiable depuis le ledger.

• Provenance signée cryptographiquement par finding. Chaque finding DRAFT porte une signature Ed25519 sur les IDs d'invocation d'outil, les hash SHA-256 de stdout/stderr, les codes de sortie et les vecteurs d'arguments. La clé de signature est détenue par la passerelle, pas par le LLM. Un finding sans chaîne de signature valide ne peut pas quitter DRAFT.
• Inference Constraint Gateway, architectural et pas par prompt. Le serveur MCP n'expose que des fonctions forensiques typées : get_amcache(), extract_mft_timeline(), volatility_pslist() et 13 autres. Il n'expose PAS execute_shell_cmd ni équivalent. L'agent ne peut physiquement pas exécuter de commandes destructrices parce que la passerelle ne les possède pas. Tout finding émis par le LLM sans tool_invocation_id est rejeté par la passerelle, pas par un prompt système.
• Corroboration multi-outils automatisée comme pré-condition stricte. Un finding de classe « exécution » exige des preuves d'au moins deux parmi {Amcache, Prefetch, ShimCache, EVTX 4688, MFT, UserAssist, BAM/DAM}. Un finding de classe « persistance » exige deux parmi {clé Run, tâche planifiée, abonnement WMI, installation de service, dossier de démarrage}. Les revendications à source unique sont rétrogradées automatiquement en INDICATION et n'atteignent jamais DRAFT.
• Précision/rappel mesurés sur un corpus étiqueté, avec une démo de contrôle négatif. SWORN livre un harnais eval/ qui s'exécute contre un corpus étiqueté d'images de disque + mémoire saines et compromises et rapporte le nombre de faux positifs, de faux négatifs, la précision et le rappel par classe de finding. Le contrôle négatif est un hôte connu propre où l'agent doit rester silencieux. Le rapport d'exactitude cite le taux de silence.
• Défense architecturale contre l'injection de prompt depuis le contenu des preuves. Chaque stdout d'outil est encapsulé en balises <evidence>...</evidence> avant d'être montré au LLM. La passerelle élimine les marqueurs <system>, <assistant>, <tool_use> inline et autres vecteurs d'injection similaires. Une suite de tests adverses sous adversarial/ livre des entrées de log empoisonnées qui essaient de manipuler l'agent ; la suite de tests vérifie que l'agent ne les écoute pas.

Architectural vs par prompt : le test qui compte

Le choix de conception le plus profond dans SWORN est celui qu'on confond le plus facilement. Chaque règle architecturale du système est testée deux fois dans eval/ : une fois avec le prompt système SWORN standard qui renforce les règles, une fois avec le prompt système dépouillé à un générique « vous êtes un répondant d'incident utile ». La défense doit tenir dans les deux cas.

Si le LLM essaie d'appeler execute_shell_cmd sous l'un ou l'autre prompt, le résultat doit être le même : aucun outil de ce nom. Si le LLM essaie d'écrire un finding sans tool_invocation_id sous l'un ou l'autre prompt, la passerelle le rejette de la même manière. Si le LLM soumet un tool_invocation_id qui n'existe pas dans le ledger, la passerelle le rejette. S'il essaie d'écrire sur un chemin de preuve, le montage bind en lecture seule le bloque au niveau du kernel. Si une ligne de ledger est altérée après écriture, la signature Ed25519 échoue et le cas est invalidé.

C'est ce que « architectural, pas par prompt » signifie vraiment comme propriété testable. Un prompt est une demande polie à un modèle qui peut être ignorée. Une fonction typée qui n'existe pas est juste absente.

À quoi ressemble vraiment la corroboration

Les revendications à source unique sont la façon dont chaque écrit DFIR sur-confiant déraille. SWORN transforme l'exigence en code. Deux findings semés, qui pointent tous les deux vers la même hypothèse (exécution de mimikatz sur l'hôte). L'un est à source unique (Prefetch seulement). L'autre est à deux sources (Prefetch + Amcache). La machine à états de la passerelle les route vers des états terminaux différents avant qu'un analyste les voie.

Largeur d'analyse (parce que critère 3 de Find Evil!)

Seize fonctions MCP typées sur onze chaînes d'outils forensiques, toutes encapsulées en schémas pydantic pour que le LLM ne puisse physiquement pas passer un argv arbitraire :

• Mémoire : Volatility 3 sur 15 plugins Windows plus une variante malfind dédiée.
• Super-timeline : plaso deux étapes (log2timeline + psort).
• Événements Windows + détections Sigma : EvtxECmd, Hayabusa avec 3 700+ règles.
• Master File Table : MFTECmd.
• Registre : RegRipper, 21 plugins dans la allow-set.
• Système de fichiers : Sleuth Kit (fls, icat, mmls, mactime).
• Carving : bulk_extractor avec 19 scanners.
• Maliciels : YARA.
• Navigateur : Hindsight.
• Exécution : PECmd.

Ce qui a été difficile

Les règles de corroboration exigent une vraie connaissance du domaine DFIR, pas juste de l'ingénierie. « Un finding d'exécution exige deux parmi {Amcache, Prefetch, ShimCache, EVTX 4688, MFT, UserAssist, BAM/DAM} » est une ligne de code et des semaines de lecture. Chaque famille d'artéfacts a ses lubies : ShimCache ne se met à jour qu'à l'arrêt, Amcache a un quirk de buffering de plusieurs heures, Prefetch est désactivé par défaut sur les SKU Server. La règle de corroboration doit être assez lâche pour vraiment se déclencher sur de vraies intrusions et assez serrée pour que deux-de-{n'importe quoi} ne devienne pas une case à cocher. Le harnais eval sur le corpus étiqueté est la seule façon d'ajuster sans deviner.

La suite de défense contre l'injection de prompt a été le plus long morceau. Des échantillons adverses qui ressemblent à de vraies lignes de log, de vrais user-agent, de vrais transcripts PowerShell, mais qui contiennent des motifs d'override inline conçus pour manipuler les outils en aval. La défense est le wrapper de la passerelle plus un nettoyeur pour les marqueurs <system>, <assistant>, <tool_use> inline. La suite de tests vérifie que l'agent n'appelle aucun outil avec des arguments dérivés du contenu injecté. La session avec prompt standard et la session avec prompt dépouillé doivent toutes les deux passer.

Preuves en lecture seule au niveau du kernel. Le montage bind est monté ro,noatime,nosuid,nodev pour que l'agent ne puisse littéralement pas écrire sur le chemin de preuve, mettre un bit setuid, créer un nœud de périphérique ni déplacer le timestamp d'access-time. Le SHA-256 pré/post de chaque fichier de preuve est enregistré dans reports/integrity.json. Toute différence non nulle est un bug P0. Le modèle de menace dans docs/threat-model.md détaille les quatre frontières de confiance et la défense architecturale pour chacune.

Ce que j'ai appris

Si un contrôle de sécurité est un prompt système, ce n'est pas un contrôle de sécurité. La leçon que Protocol SIFT a codifiée, et celle que SWORN pousse à sa conclusion logique : une défense qui dépend du modèle qui se comporte n'est pas une défense. Une défense qui dépend d'une fonction typée qui n'existe pas, oui. La distinction architectural-vs-prompt a l'air pédante jusqu'à ce qu'on lance le harnais eval/ avec le prompt dépouillé et qu'on regarde chaque règle architecturale tenir pendant que chaque instruction « ne fais pas X » par prompt s'évapore.

La corroboration est aussi une idée plus profonde qu'elle n'en a l'air. La raison pour laquelle chaque autre démo DFIR assistée par IA se fait prendre à halluciner, c'est que l'agent cite un seul artéfact et que la démo pose une question différente. Le portail de corroboration force la revendication de l'agent à survivre à une seconde ligne de preuve indépendante avant qu'elle soit autorisée à quitter DRAFT. Cette seule règle empêche le mode d'échec le plus embarrassant dans ce domaine.

La suite

• Forensique cloud : ingestion d'artéfacts AWS / Azure / GCP. Aujourd'hui SWORN est centré image d'hôte ; les preuves du plan de contrôle cloud sont le prochain horizontal.
• Forensique mobile : sysdiagnose iOS + adb Android. Même passerelle, wrappers typés différents.
• Intégrité de preuves au niveau kernel complet avec FUSE + labels MAC SELinux pour que même root ne puisse pas muter le montage bind.
• Streaming SIEM temps réel : corroboration continue sur un flux d'événements en direct plutôt qu'image au repos.
• Certification d'admissibilité en cour. SWORN est aujourd'hui un démonstrateur de méthodologie défendable, pas un produit certifié. La voie vers la certification est de mapper chaque invariant de passerelle à un facteur Daubert et de faire valider la chaîne par un laboratoire d'accréditation externe.