Honeypots & Deception

Les honeypots sont des systèmes sans finalité productive dont la seule mission est d'être attaqués – chaque interaction est donc par définition au moins suspecte. Les honeypots à faible interaction n'émulent des services ou protocoles isolés que de manière superficielle ; ils sont économes en ressources, rapides à déployer et peu risqués, mais offrent des enseignements limités et sont plus facilement identifiables comme leurres par les attaquants. Les honeypots à forte interaction mettent à disposition de véritables systèmes d'exploitation et applications et permettent une analyse approfondie des outils et des modes opératoires – au prix d'une charge d'exploitation et de sécurisation nettement plus élevée. Dans son étude de référence, l'ENISA a évalué 30 solutions de honeypots selon exactement cette taxonomie, en couvrant les variantes côté serveur comme côté client.

Les honeytokens transposent le principe du leurre des systèmes vers les données et les identifiants : clés API piégées, documents, enregistrements de base de données, noms DNS ou adresses e-mail que personne n'utilise en exploitation normale. Si un tel objet est ouvert ou si une clé piégée est utilisée, il s'agit d'un indicateur de compromission quasi univoque – y compris là où les capteurs classiques font défaut, par exemple dans les services SaaS ou en cas d'exfiltration de données. Des services librement accessibles comme Canarytokens de Thinkst proposent plus de 30 types de tokens, des clés AWS aux fichiers kubeconfig en passant par les documents Office, et permettent de démarrer avec un effort minimal. Le NIST décrit cette démarche (« tainting »), aux côtés du détournement des attaquants (« misdirection »), comme une approche de la technique de cyber-résilience appelée deception.

La détection classique via SIEM, EDR ou NDR doit extraire les attaques de volumes massifs d'événements légitimes – avec le bruit de fond et l'effort de réglage correspondants. La deception inverse cette logique : comme les utilisateurs légitimes ne touchent jamais aux leurres et aux honeytokens, pratiquement chaque alerte est pertinente. Les plateformes de deception orchestrent les leurres de manière centralisée, injectent les alertes dans le SIEM ou le SOC et fournissent une télémétrie riche en contexte pour la réponse à incident. Depuis 2022, MITRE Engage offre en outre un framework dédié qui structure les activités de denial, de deception et d'adversary engagement et les aligne sur des comportements d'attaquants réellement observés. Pour les opérateurs d'installations critiques, la deception peut compléter les systèmes de détection d'attaques exigés par le § 31 BSIG – mais elle ne saurait les remplacer.

La deception est efficace là où les attaquants se déplacent après l'accès initial : dans les segments de réseau internes, dans l'Active Directory, sur les systèmes de fichiers et de sauvegarde, dans les environnements cloud et, de plus en plus, dans les réseaux OT. Les bonnes pratiques consistent à déployer des systèmes leurres dans chaque segment pertinent et des honeytokens dans les dépôts de code, les fichiers de configuration et les magasins d'identifiants – c'est-à-dire le long des chemins qu'empruntent typiquement les mouvements latéraux et l'élévation de privilèges. Un honeypot exposé publiquement sur Internet ne génère en revanche essentiellement que du bruit de fond issu des scans de masse et contribue peu à la détection d'attaques ciblées contre votre propre réseau. La crédibilité est déterminante : les conventions de nommage, les niveaux de correctifs et les métadonnées des leurres doivent correspondre à l'environnement réel, et l'infrastructure de deception doit être strictement séparée du réseau de production.

L'exploitation de honeypots sur sa propre infrastructure est licite en tant que pure mesure de détection – l'attaquant accède de son propre chef aux systèmes de l'exploitant, ce qui ne constitue pas une « incitation » pénalement répréhensible. Il faut clairement distinguer cela du « hack back » : les accès actifs à des systèmes tiers ne sont pas autorisés pour les entreprises en Allemagne et restent punissables faute de base légale d'autorisation (notamment §§ 202a et suivants StGB) ; la deception s'arrête à la frontière de son propre réseau. Sur le plan de la protection des données, le traitement des données ainsi générées (par exemple des adresses IP) peut régulièrement se fonder sur l'intérêt légitime au sens de l'art. 6, par. 1, point f) du RGPD – le considérant 49 mentionne expressément la garantie de la sécurité des réseaux et de l'information, dans la mesure où le traitement est strictement nécessaire et proportionné à cette fin. Une vigilance particulière s'impose dans le cas où un honeypot à forte interaction compromis serait détourné comme tremplin pour des attaques contre des tiers : la doctrine pénale évoque ici des risques de complicité pour les exploitants, raison pour laquelle le trafic sortant doit être strictement limité au niveau technique.

La deception ne détecte que les attaquants qui interagissent effectivement avec les leurres – elle ne remplace ni la prévention ni la détection généralisée, mais complète les deux par une source de signal supplémentaire d'une grande précision. Les attaquants expérimentés tentent de démasquer les honeypots par fingerprinting ; des artefacts d'émulation, des systèmes invraisemblables ou l'absence de traces d'utilisation détruisent l'illusion et dévalorisent la mesure. L'exploitation exige donc un entretien continu : mise à jour des leurres, adaptation aux évolutions de l'environnement, playbooks définis pour les alertes et responsabilités claires au sein du SOC. L'étude de l'ENISA identifiait déjà l'ergonomie, la documentation et les besoins en personnel comme des obstacles majeurs à l'utilisation des honeypots – les plateformes modernes et les services de honeytokens abaissent nettement ce seuil, sans toutefois éliminer complètement l'effort de maintenance.