Protéger les endpoints avec les Honeytokens

La protection par Honeytoken place un identifiant AWS leurre sur chaque machine de développeur. Cet identifiant ne donne accès à rien, donc personne n'a de raison légitime de l'utiliser. Dès que quelqu'un le fait, GitGuardian déclenche une alerte qui vous indique quelle machine a été compromise.

Pourquoi déployer des honeytokens sur les machines des développeurs

Le scan des endpoints répertorie les identifiants déjà présents sur une machine. La protection par Honeytoken ajoute la détection d'intrusion à ce même déploiement, de sorte que vous apprenez aussi dès que quelqu'un tente de les voler.

Les collecteurs d'identifiants sont des programmes qui recherchent les identifiants enregistrés sur une machine et les envoient à un attaquant. Ils atteignent les machines des développeurs via des paquets malveillants, des outils trojanisés et des extensions de navigateur malveillantes. Leur comportement est prévisible : lire les emplacements d'identifiants bien connus (.env, .gitconfig, .npmrc, etc.), et exfiltrer tout ce qui s'y trouve. Placer un leurre exactement à ces emplacements signifie que le premier geste de l'attaquant est ce qui le trahit.

Cela vous apporte quelques éléments difficiles à obtenir par toute autre couche de détection :

• Un signal sans ambiguïté. Le leurre n'a aucun usage légitime, donc toute utilisation de celui-ci est non autorisée par définition. Il n'y a pas de référence à apprendre, pas de réglage, et pas de liste de signatures à maintenir à jour.
• Une dernière ligne de défense. Si un malware a déjà réussi à passer votre EDR et vos autres contrôles d'endpoint, l'utilisation du leurre l'expose tout de même.
• Une machine nommée à examiner. L'événement porte l'adresse IP, le user agent et l'horodatage, et le honeytoken se résout en un endpoint spécifique et son propriétaire, ce qui est là où une investigation commence réellement.
• Une couverture que vous pouvez mesurer. Le dashboard rapporte la part de votre parc qui est protégée et liste les endpoints qui ne le sont pas, de sorte qu'il s'agit d'un programme que vous pouvez mener à terme plutôt qu'un effort au mieux. Voir Surveiller la couverture.
• Aucun agent supplémentaire à déployer. Le déploiement réutilise le binaire ggshield que vous installez déjà pour le scan et écrit un fichier plutôt que d'exécuter un processus résident, de sorte qu'il n'y a rien de nouveau à certifier et aucun coût continu sur la machine.

Pour les développeurs, le déploiement est discret. Il ne touche jamais que son propre profil et laisse tous les autres profils AWS de la machine intacts.

Fonctionnement du déploiement

La commande ggshield honeytoken plant réconcilie la machine avec GitGuardian à chaque exécution. Elle demande à GitGuardian quel est l'état souhaité pour cet endpoint, puis l'applique sur le disque :

• Pour un honeytoken actif, elle écrit ou rafraîchit le profil d'identifiant AWS leurre.
• Pour un honeytoken que vous avez révoqué dans GitGuardian, elle supprime ce profil de la machine.
• Tout autre profil présent dans le fichier est préservé.

ggshield ne révoque jamais un honeytoken de lui-même. Il applique l'état souhaité et rend compte de l'endroit où le honeytoken a atterri. La révocation reste une action délibérée que vous effectuez dans GitGuardian, ce qui signifie qu'un nettoyage sur une machine ne peut jamais désactiver un fil-piège dont vous dépendez encore.

Comme la commande réconcilie plutôt qu'elle n'ajoute, l'exécuter de manière répétée est sûr. Une machine qui a déjà été plantée reste telle quelle.

remarque

Le déploiement nécessite le scope honeytokens:write sur le token que ggshield utilise. Ce n'est pas la même chose que honeytokens:check, qui existe pour que le scan des endpoints ne déclenche pas vos propres honeytokens lorsqu'il les rencontre. Un parc effectuant les deux a besoin des deux scopes.

Déployer la protection par Honeytoken

La protection par Honeytoken se déploie de la même manière que le scan, via votre MDM, et les deux sont indépendantes. Un endpoint peut être scanné sans être planté, et le dashboard rapporte chacun séparément.

Vous avez deux options pour la planification, et les deux sont valides :

• Ajoutez la commande de déploiement au job qui exécute déjà votre scan d'inventaire quotidien.
• Exécutez-la comme son propre job MDM à une fréquence plus basse, puisque l'état souhaité change bien moins souvent que les résultats de scan.

Pour la configuration du token, les modèles de job MDM et le détail de la planification, suivez Déployer ggshield à grande échelle avec un token de compte de service.

Pour déployer sur une seule machine :

export GITGUARDIAN_API_KEY="<SAT_FROM_SECRET_STORE>"
export GITGUARDIAN_INSTANCE="<GITGUARDIAN_INSTANCE_URL>"

ggshield honeytoken plant

Pour voir quelles cibles seraient écrites sans contacter GitGuardian ni toucher au disque, utilisez d'abord une exécution à blanc :

ggshield honeytoken plant --list-targets

Pour la liste complète des options, y compris comment surcharger le nom du profil et cibler un utilisateur spécifique, voir la référence ggshield honeytoken plant.

Vérifier qu'une machine est protégée

Ouvrez l'endpoint dans Endpoint protection > Endpoints et vérifiez la carte Honeytoken protection, qui affiche la dernière synchronisation, le nombre de honeytokens déployés et depuis combien de temps la machine est protégée. L'onglet Honeytokens liste chacun d'eux avec sa méthode de placement, son statut, et quand il a été planté et synchronisé pour la dernière fois.

Une machine qui n'affiche aucune synchronisation récente est une machine dont le job de déploiement ne s'exécute pas. Comme la commande réconcilie à chaque exécution, une synchronisation obsolète signifie aussi qu'un honeytoken que vous avez révoqué peut toujours se trouver sur ce disque.

Auditer vos honeytokens d'endpoint à grande échelle

Pour passer en revue chaque honeytoken planté à travers le parc, allez dans Honeytoken > Honeytokens et filtrez sur Source type is Endpoints.

En ouvrir un montre où il se trouve. La carte Sources résout le honeytoken en une machine et son propriétaire, nomme le profil sur disque dans lequel il a été écrit, et le marque comme Planted.

Pour tout le reste de ce que vous pouvez faire depuis cette vue, comme le marquage et le filtrage, voir Gérer votre population de honeytokens.

Supprimer un honeytoken d'une machine

La suppression est un processus en deux étapes, par conception :

1. Révoquez le honeytoken dans GitGuardian, ce qui l'empêche d'être un fil-piège actif. Voir Répondre à un honeytoken déclenché.
2. Laissez la prochaine exécution de déploiement le supprimer du disque. Pour exécuter une passe de nettoyage qui applique uniquement les suppressions et n'écrit rien de nouveau, utilisez ggshield honeytoken plant --remove-only.

C'est aussi le chemin de retour arrière. Désactiver le job de déploiement arrête les nouveaux placements, et une passe --remove-only efface ce qui est déjà présent.

Quand un honeytoken est déclenché

Un honeytoken déclenché sur un endpoint signifie que quelqu'un a utilisé un identifiant qui n'existe sur cette machine qu'en tant que leurre. Considérez la machine comme compromise et menez votre investigation à partir de là.

L'alerte et la réponse aux honeytokens fonctionnent de la même manière quel que soit l'endroit où le honeytoken a été planté :

• Configurez vos alertes pour router les événements vers l'e-mail, Slack, Microsoft Teams, ou un webhook.
• Comprendre les événements de honeytoken et le mécanisme de déclenchement pour ce que chaque événement vous indique.
• Répondre à un honeytoken déclenché pour le workflow de réinitialisation et de révocation.