Surveiller les flux sortants : détecter l’exfiltration avant la demande de rançon

La double extorsion est devenue la norme : les données sont copiées avant d’être chiffrées, et la publication est menacée. Cela change la fenêtre de détection utile.

L’exfiltration précède le chiffrement de plusieurs heures à plusieurs jours. C’est la dernière occasion d’agir avant que l’incident ne devienne public.

Pourquoi le sortant est mal surveillé

Les architectures filtrent rigoureusement ce qui entre et laissent sortir librement. Trois raisons à cela.

La première est historique : le modèle de sécurité périmétrique s’est construit contre l’intrusion, pas contre la fuite.

La deuxième est pratique : restreindre le sortant casse des choses. Une application qui appelle une interface externe non documentée cesse de fonctionner, et personne ne sait pourquoi.

La troisième est technique : le trafic est chiffré, donc le contenu est invisible sans interception, avec les arbitrages juridiques que cela suppose.

Résultat : sur la plupart des parcs que nous auditons, un serveur applicatif peut joindre n’importe quelle adresse sur Internet, ce qui n’a aucune justification métier.

Ce qu’on peut détecter sans déchiffrer

Le volume

C’est le signal le plus simple et le plus robuste. Une machine qui envoie soudainement dix fois son volume habituel est une anomalie, quel que soit le contenu.

La difficulté n’est pas la mesure, c’est la référence : sans historique de ce qui est normal pour cette machine, on ne peut pas qualifier l’écart. D’où l’intérêt d’une base comportementale — voir ce que l’analyse comportementale apporte.

La destination

Une connexion vers un service de stockage grand public depuis un serveur de production n’a pas de raison d’être. Les attaquants privilégient précisément les destinations légitimes pour se fondre dans le trafic.

La journalisation DNS suffit à repérer ces résolutions, sans rien déchiffrer.

L’horaire

Un transfert important lancé un samedi à trois heures depuis une machine dont l’usage est diurne et ouvré est un signal fort, avec très peu de faux positifs.

La durée et la régularité

Une connexion maintenue plusieurs heures, ou des connexions courtes à intervalles réguliers vers la même destination, sont caractéristiques d’un canal de commande.

Les protocoles détournés

L’exfiltration par requêtes DNS reste utilisée parce que ce protocole est rarement filtré : requêtes anormalement longues, sous-domaines aléatoires, volume inhabituel vers un même domaine.

Restreindre plutôt que seulement observer

La détection vaut mieux que rien, mais la restriction est plus efficace.

Pour les serveurs, le principe devrait être l’interdiction par défaut du sortant vers Internet, avec des autorisations explicites : dépôts de mises à jour, interfaces partenaires identifiées, services de temps. Un serveur applicatif n’a en principe aucune raison d’initier une connexion arbitraire.

C’est la mesure la plus rentable du domaine, et l’une des moins appliquées. Elle transforme une compromission exploitable en compromission bloquée, et génère une alerte immédiate.

Pour les postes, la restriction est plus délicate, mais le filtrage par réputation et par catégorie reste applicable, avec un blocage explicite qui produit un signal.

La méthode qui évite de casser la production

Même séquence que pour la segmentation, et pour les mêmes raisons :

1. Journaliser les flux sortants sans bloquer, pendant une période couvrant un cycle métier complet.
2. Analyser ce qui sort réellement, par machine et par destination.
3. Construire les règles à partir de l’observation, pas de la documentation.
4. Basculer en blocage par zone, en commençant par les serveurs, avec un mécanisme de dérogation rapide.

Sauter la première étape garantit l’incident et l’abandon du projet.

Ce que la détection d’exfiltration change dans la chronologie

Reprenons les phases décrites dans la chronologie d’une attaque. L’exfiltration intervient après la neutralisation des sauvegardes et avant le chiffrement.

La détecter permet trois choses :

• Couper avant que la totalité des données ne soit sortie, ce qui change l’ampleur de la notification et de la publication éventuelle.
• Agir avant le chiffrement, donc éviter l’indisponibilité.
• Savoir quelles données sont concernées — information indispensable pour la notification à l’autorité dans les délais.

Ce dernier point est sous-estimé. Une organisation qui sait dire quelles données sont sorties notifie précisément. Celle qui l’ignore notifie au pire, avec les conséquences de réputation correspondantes.

Les canaux qu’on oublie

Les services de partage personnels utilisés par des salariés — voir le shadow IT.

La messagerie : pièces jointes volumineuses vers des adresses externes, transferts automatiques vers une boîte personnelle. Une règle de transfert créée discrètement est un classique de l’exfiltration interne.

Les supports amovibles, qui échappent totalement à la surveillance réseau.

Les assistants IA, où le contenu part par un canal parfaitement légitime.

Une surveillance qui ne couvre que le réseau rate l’essentiel de ces cas.

Le cadre juridique

Surveiller les flux sortants des postes revient à observer l’activité de salariés identifiés. Les obligations d’information, de proportionnalité, de durée de conservation et de restriction d’accès s’appliquent — voir l’article 32.

La surveillance des flux serveurs ne pose pas les mêmes questions et peut être mise en œuvre plus largement. C’est aussi là que le gain est le plus élevé : commencer par les serveurs est à la fois plus efficace et plus simple juridiquement.

Ce que demandent les référentiels

ISO/IEC 27002:2022 traite le sujet par les mesures 8.12 (prévention des fuites de données, nouveauté de la révision 2022), 8.16 (activités de surveillance), 8.20 et 8.22.

La mesure 8.12 est l’une des plus mal traitées en audit de transition, parce qu’elle suppose un dispositif réel et pas une procédure.

Les cinq questions

1. Un serveur de production peut-il joindre une adresse arbitraire sur Internet ?
2. Sait-on quel volume sortant est normal pour les machines critiques ?
3. Les résolutions DNS sont-elles journalisées et exploitées ?
4. Une alerte se déclenche-t-elle sur un transfert important hors horaires ?
5. Les règles de transfert automatique de messagerie sont-elles surveillées ?

Sources

• ISO/IEC 27002:2022, mesures 8.12, 8.16, 8.20 et 8.22
• MITRE ATT&CK — Exfiltration
• ANSSI — recommandations sur le cloisonnement et la journalisation
• CNIL — proportionnalité des dispositifs de surveillance

Aller plus loin

La restriction des flux relève de nos missions de sécurité réseau et d’orchestration des politiques. La détection et la qualification relèvent de l’infogérance SOC.