Que se passe-t-il lorsqu'un programme tente d'accéder à des données d'identité auxquelles il ne devrait pas avoir accès ?
Réponse courte : cela dépend du fait que le programme soit fiable et qu'il ait été compromis ou non. Une application légitime qui outrepasse simplement ses droits reçoit des données fictives ou se voit discrètement refuser l'accès. Une application inconnue ou compromise est rejetée ou suspendue. L'identifiant réel n'est jamais transmis dans aucun de ces cas.
Pourquoi une réponse unique serait erronée
La conception évidente consiste à « bloquer tout ce qui touche à un magasin d'identifiants ». Elle échoue immédiatement en pratique, car les logiciels légitimes touchent constamment ces magasins — navigateurs, gestionnaires de mots de passe, clients VPN, outils de synchronisation et agents de sauvegarde ont tous de bonnes raisons d'y accéder.
Tout bloquer casse la machine. Tout autoriser pour les éléments fiables signifie qu'un navigateur exploité obtiendra tout ce qu'il demande. La question pertinente est plus précise : ce programme se comporte-t-il comme il le devrait ?
Les quatre résultats possibles
1. Autorisé. Une application connue, non exploitée, accédant à ce dont elle a légitimement besoin. Rien ne change.
2. Données fictives renvoyées. Une application connue, non exploitée, dépassant son accès approprié. Les règles comportementales de confidentialité s'appliquent : le programme reçoit des données plausibles mais fausses. Il continue de fonctionner normalement, et l'identifiant réel ne quitte jamais le stockage. Du point de vue du programme, rien n'a échoué — ce qui explique précisément pourquoi cela fonctionne sans perturber les flux de travail.
3. Accès refusé. La même situation, où le renvoi de données fictives n'est pas approprié. La demande est refusée ; l'application continue de fonctionner.
4. Rejeté ou suspendu. Le programme est inconnu, ou un programme connu dont le processus ou les bibliothèques présentent des signes d'exploitation. Ici, la préoccupation n'est pas le dépassement de droits, mais le fait que le programme n'agit plus comme lui-même. Le fait qu'il soit rejeté ou suspendu dépend de l'évaluation du moteur comportemental et de vos paramètres configurés.
Pourquoi la tromperie plutôt que le blocage
Renvoyer des données fictives est un choix délibéré. Une demande bloquée indique à un attaquant qu'il a été détecté et l'incite à essayer une autre voie. Des données fictives d'apparence réelle ne le font pas — les outils poursuivent avec des identifiants qui ne débloquent rien, et l'opérateur peut ne pas se rendre compte du problème avant un certain temps.
C'est le même principe que celui des fichiers canari dans la défense contre les rançongiciels : donner à l'attaquant quelque chose de convaincant à saisir, sans aucun coût pour vous.
Configurabilité
La frontière entre rejet et suspension est ajustable. Les environnements ayant une faible tolérance aux interruptions — systèmes cliniques, chaînes de production — peuvent privilégier le refus et les données fictives plutôt que la suspension, tandis que les environnements à haute sécurité peuvent adopter une approche plus agressive.