Détecter l’exfiltration : méthode SOC et mesure du délai de détection

Détecter l’exfiltration, pour un SOC, c’est repérer qu’une donnée quitte le périmètre de l’entreprise par un canal non autorisé, puis lever une alerte exploitable assez tôt pour limiter la fuite. La qualité de cette détection se mesure surtout par un indicateur : le délai entre le début de la sortie de données et l’alerte qualifiée. Ce délai ne se devine pas. Il se mesure en rejouant des scénarios d’attaque avec des données factices.

La plupart des SOC disposent de règles de détection d’exfiltration. Bien moins savent dire, preuve à l’appui, lesquelles se déclenchent réellement, et en combien de temps. Cet article propose une méthode pour passer de la règle écrite à la règle validée.

Partir des cas d’usage, pas des outils

Une erreur fréquente consiste à empiler des règles fournies par l’éditeur du SIEM sans les relier à un risque précis. Commencez plutôt par une liste courte de cas d’usage, formulés du point de vue de l’attaquant et de la donnée visée. Le cadre MITRE ATT&CK et sa tactique Exfiltration aide à structurer cette liste, sans dispenser de l’adapter à votre contexte.

Quelques cas d’usage qui méritent presque toujours une règle dédiée :

• Volume anormal vers l’extérieur : un poste ou un serveur qui envoie nettement plus que sa ligne de base habituelle.
• Envoi vers un stockage cloud personnel : téléversement vers un service non référencé par l’entreprise (voir les fuites par cloud personnel et outils collaboratifs).
• Canaux détournés : requêtes DNS inhabituellement longues ou nombreuses, trafic chiffré vers des destinations jeunes ou rares.
• Préparation des données : compression ou chiffrement massif de fichiers juste avant un transfert, signal typique de la double extorsion.
• Comportement d’un utilisateur de confiance : téléchargement massif depuis un référentiel métier par un compte légitime, en dehors de ses habitudes.

Les sources de données indispensables

Une règle n’est jamais meilleure que les journaux qui l’alimentent. Avant de juger une détection, vérifiez que la télémétrie arrive, qu’elle est complète et qu’elle est horodatée correctement.

Faites défiler le tableau →

Le dernier point est souvent sous-estimé. Certains journaux cloud arrivent avec un retard propre au fournisseur, parfois significatif. Votre délai de détection ne pourra jamais être inférieur à ce retard. Mieux vaut le connaître que le découvrir pendant un incident. Les angles morts de l’inspection chiffrée sont détaillés dans notre article sur l’exfiltration en HTTPS.

Mesurer le délai de détection

Définir les bons horodatages

Parler de « délai de détection » sans le décomposer ne sert à rien. Distinguez au moins quatre instants :

1. T0 : début réel de la sortie de données.
2. T1 : arrivée de l’événement dans le SIEM.
3. T2 : déclenchement de la règle et création de l’alerte.
4. T3 : qualification par un analyste (vrai positif confirmé).

T1 moins T0 mesure votre chaîne de collecte. T2 moins T1 mesure la logique de corrélation, notamment les fenêtres temporelles des règles. T3 moins T2 mesure l’organisation humaine : priorité de l’alerte, charge de l’équipe, clarté du contexte fourni. Un délai global long peut venir d’un seul de ces segments, et le correctif n’est pas le même.

Le problème du T0

En situation réelle, T0 est presque toujours reconstitué après coup, et de façon approximative. C’est précisément pourquoi la mesure fiable passe par le rejeu : quand vous déclenchez vous-même le scénario, vous connaissez T0 à la seconde. Vous obtenez alors un chiffre comparable d’un mois à l’autre, ce qui transforme une impression en indicateur de posture.

Valider les règles avec des scénarios rejoués

Une règle qui ne s’est jamais déclenchée peut être silencieuse pour deux raisons : aucune attaque n’a eu lieu, ou la règle ne fonctionne pas. Seul un test actif permet de trancher. Le principe est simple : rejouer, en production, des techniques d’exfiltration réalistes avec des données factices qui ressemblent à vos données sensibles, puis vérifier ce que le SOC voit.

Exemple de scénario

Un mardi à 10 h, un poste de test de la direction financière dépose sur un service de stockage personnel un fichier factice imitant un export de paie. Trois questions guident l’analyse :

• L’événement est-il arrivé dans le SIEM, et en combien de temps ?
• La règle « téléversement de données sensibles vers un cloud non référencé » s’est-elle déclenchée ?
• L’alerte contenait-elle assez de contexte (utilisateur, fichier, destination) pour être qualifiée sans investigation longue ?

Points de validation

• Chaque cas d’usage possède au moins un scénario rejouable.
• Les scénarios utilisent uniquement des leurres, jamais de données réelles.
• Le rejeu est annoncé à un cercle restreint, pour mesurer aussi la réaction humaine sans perturber l’équipe.
• Les résultats sont notés par segment : collecte, corrélation, qualification.
• Les scénarios sont rejoués après chaque changement notable : migration, nouvelle version d’agent, refonte de politique.
• Les écarts constatés alimentent une liste d’actions hiérarchisées, avec un responsable et une échéance.

Ce qu’il faut corriger en premier

Face à une série de constats, ne commencez pas par réécrire les règles. Vérifiez d’abord la collecte : une règle parfaite sur un journal absent ne détecte rien. Corrigez ensuite les règles qui ne se déclenchent pas sur les cas d’usage les plus critiques. Traitez enfin le délai de qualification, souvent amélioré par un meilleur enrichissement des alertes plutôt que par des effectifs supplémentaires. La logique de tri est développée dans notre article sur la hiérarchisation de la remédiation.

Pour situer cette démarche dans l’ensemble de la discipline, la page de référence sur le test d’exfiltration de données présente la méthode complète.

FAQ