Deceptive security (technologie de déception)

Comment ça fonctionne

La déception inverse la logique habituelle de la détection. Les défenses traditionnelles cherchent à reconnaître le malveillant parmi un flux légitime : signatures d'antivirus, règles IDS, corrélation de logs, modèles comportementaux. La déception, elle, fabrique un environnement où le légitime n'a rien à faire. Elle dissémine sur le réseau des objets crédibles mais sans usage métier réel, et surveille tout contact avec eux. La détection se fait par interaction, et non par signature : peu importe que la technique d'attaque soit connue, inédite ou polymorphe, le simple fait d'authentifier, de scanner ou de se connecter à un leurre trahit l'intrus.

Concrètement, une stratégie de déception combine plusieurs familles d'artefacts qui se renforcent mutuellement :

• Le honeypot : un système entier (serveur, base de données, poste de travail, équipement industriel) simulé pour attirer et observer l'attaquant.
• Le leurre (decoy) : un faux actif placé sur le réseau (partage de fichiers, identifiant, service exposé) qui n'a d'autre fonction que de déclencher une alerte lorsqu'on y touche.
• Le breadcrumb : une miette d'information laissée sur de vrais postes (entrée de registre, fichier de configuration, identifiant mis en cache) qui guide discrètement l'intrus vers un leurre ou un honeypot.
• Le honeytoken et le canary token : une donnée piégée (compte, clé d'API, document, URL) dont la moindre utilisation envoie une alerte, y compris hors du périmètre où elle a été semée.

Une fois l'attaquant en contact avec ces artefacts, la plateforme capture ses actions : commandes exécutées, identifiants tentés, mouvements latéraux, outils déployés. Ces traces se cartographient naturellement sur le référentiel MITRE ATT&CK et nourrissent l'investigation comme la threat intelligence.

Pourquoi très peu de faux positifs

La force majeure de la déception est la qualité de ses alertes. Comme aucun processus métier ni aucun utilisateur autorisé ne devrait jamais accéder à un leurre, une alerte de déception est rarement bénigne. Là où un SIEM peut générer des milliers d'événements ambigus à trier, un déclenchement de honeytoken ou de honeypot pointe directement vers une activité suspecte, souvent déjà à l'intérieur du périmètre. Cette précision réduit drastiquement la fatigue d'alerte des analystes du SOC et raccourcit le temps de détection (MTTD). La déception ne remplace pas les contrôles existants : elle ajoute un signal à haute fidélité, particulièrement utile face aux menaces qui ont déjà franchi le pare-feu, comme les comptes compromis, les mouvements latéraux ou les attaques internes.

Plateforme de déception distribuée et place dans la défense en profondeur

À l'échelle d'une organisation, le déploiement manuel de leurres devient ingérable. C'est le rôle d'une plateforme de déception distribuée (DDP, Distributed Deception Platform) : générer, déployer et orchestrer de façon automatisée des leurres réalistes sur l'ensemble du réseau, des postes utilisateurs aux environnements cloud, tout en centralisant les alertes et les preuves. La DDP maintient la crédibilité des appâts, les renouvelle et les adapte au contexte pour résister à la reconnaissance de l'attaquant.

Dans une défense en profondeur, la déception se positionne comme une couche de détection interne, complémentaire de la prévention (pare-feu, EDR, segmentation) et de la détection classique (IDS, SIEM, NDR). Elle agit là où les autres couches sont aveugles : une fois l'attaquant à l'intérieur, en phase de découverte et de mouvement latéral. En semant le doute sur la fiabilité des informations qu'il collecte, elle ralentit l'adversaire, augmente son coût opérationnel et offre aux défenseurs un avantage rare : détecter tôt, observer en sécurité et reprendre l'initiative.