Les exemples incluent des systèmes, services, identifiants, enregistrements, fichiers ou liens leurres dont les utilisateurs légitimes et les processus de production ne devraient pas avoir besoin. Une interaction peut exposer le comportement adverse ou des lacunes défensives.
Un programme de leurre part d'objectifs et d'une modélisation des menaces, pas d'une catégorie de produit. Les concepteurs décident qui peut le rencontrer, ce qu'il doit susciter, comment il est contenu, quelles preuves sont collectées et comment les intervenants agissent.
Points clés
ConceptionRendre les leurres plausibles, les distinguer de la production, restreindre leurs privilèges et leurs données, et les empêcher de devenir une infrastructure d'attaque.
OpérationsSurveiller l'interaction et la santé, protéger les chemins de gestion, documenter la propriété, tester les flux de réponse, faire tourner les artefacts et retirer sûrement les leurres périmés.
GouvernanceDéfinir l'autorisation, la finalité de la collecte, les règles de conservation et d'accès, la notification requise, la revue juridique, de vie privée et de sûreté, et les règles d'escalade avant le déploiement.
Limite importanteUne alerte de leurre n'est pas automatiquement la preuve d'un attaquant externe, et le silence ne prouve pas l'absence de compromission. Une mauvaise configuration, des scanners, des initiés ou une automatisation légitime peuvent déclencher les leurres ; des adversaires sophistiqués peuvent les reconnaître, les éviter ou en abuser.