Ce que sont les tests cachés
Les tests cachés sont un exercice de sécurité où une attaque ou une violation de politique est simulée sans prévenir la plupart des personnes qui y seront confrontées. Un petit groupe, en général le commanditaire et le responsable du test, connaît le plan. Tous les autres, y compris l'équipe de sécurité et les employés ordinaires, réagissent comme ils le feraient face à un événement réel.
Le but est de mesurer ce que l'organisation fait réellement, et non ce qu'elle dit faire. Les politiques, les registres de formation et les tableaux de bord des outils décrivent le comportement voulu, alors qu'un test caché montre l'écart entre l'intention et un mardi chargé. Dans un programme de menaces internes, c'est la vérification pratique que les contrôles et les personnes qui les entourent fonctionnent.
C'est toute la chaîne qui est visée : si un employé signale un message suspect, si un contrôle bloque un transfert, si la détection des menaces internes déclenche une alerte et si quelqu'un la prend en charge et agit dans un délai raisonnable.
Comment se déroule un test caché
Un test caché n'est caché que vis-à-vis des personnes testées. Vis-à-vis de la direction de l'organisation, c'est l'inverse : il est planifié, autorisé et documenté. L'ordre habituel :
- 1
Autoriser par écrit
La direction et le service juridique approuvent le périmètre, les limites et les conditions d'arrêt avant que quoi que ce soit commence.
- 2
Concevoir le scénario
Choisissez une histoire réaliste, comme une campagne de phishing simulé ou le transfert de données factices, et gardez-la inoffensive.
- 3
Exécuter sans prévenir
Le testeur agit pendant que le reste de l'organisation travaille normalement, et une personne de confiance peut arrêter le test immédiatement.
- 4
Consigner la réponse
Notez ce qui a été bloqué, ce qui a été détecté, qui l'a remarqué et combien de temps chaque étape a pris.
- 5
Débriefer et corriger
Partagez les résultats avec toutes les personnes concernées, comblez les failles trouvées et rejouez le scénario plus tard.
Formes de tests cachés
Le test caché est une méthode, pas une technique unique. Le scénario dépend du contrôle vérifié, et la même idée va de la boîte de réception à la porte d'entrée. Le phishing simulé est la forme la plus connue et peut imiter des variantes ciblées, comme le phishing par clonage.
| Forme | Ce qui est simulé | Ce qu'elle montre |
|---|---|---|
| Phishing simulé | Des courriels trompeurs envoyés aux employés | Combien de personnes signalent le message au lieu d'y donner suite |
| Exercice de red team | Une attaque complète contre les systèmes et les personnes par une équipe externe ou interne | Si l'équipe de sécurité la détecte et la contient |
| Scénario d'abus interne | Un transfert mis en scène de fausses données sensibles vers une destination interdite | Si les contrôles de données bloquent ou signalent le transfert |
| Tests physiques et d'appareils | Entrer à la suite d'un autre employé ou une clé USB laissée sur place | Si le personnel interpelle les inconnus et signale les appareils inconnus |
| Ingénierie sociale par téléphone | Un appelant qui se fait passer pour le support informatique et demande un accès | Si le personnel vérifie l'appelant avant d'agir |
À quoi ressemble un test dans Anexet
Quand le scénario est un transfert de données, la preuve se trouve dans la couche de détection. Un fichier factice qui correspond à une règle de contenu dans un système DLP doit apparaître comme un incident avec un niveau de risque, et le responsable du test peut l'ouvrir dans l'investigation d'incidents pour suivre la suite. Dans Anexet, l'onglet Rules liste chaque règle de sécurité avec son nombre d'incidents et son niveau de risque, de sorte que le compteur de la règle que le test devait déclencher indique s'il a été détecté.
Qui sait quoi
La partie la plus difficile d'un test caché n'est pas technique. Décider qui est informé et qui ne l'est pas détermine si l'exercice est sûr et équitable. Moins il y a de personnes au courant, plus le résultat est honnête, et plus la traçabilité écrite compte.
| Rôle | Informé à l'avance | Rôle dans le test |
|---|---|---|
| Commanditaire de la directionApprouve l'exercice | Oui | Signe le périmètre et les conditions d'arrêt |
| Responsable du testPlanifie et conduit le scénario | Oui | Conçoit le scénario et consigne les résultats |
| RH et juridiqueVeillent à l'équité et au droit | Oui | Vérifient le plan au regard du droit du travail et de la vie privée |
| Équipe de sécuritéDétecte et réagit | En général non | Traite l'événement comme réel jusqu'à preuve du contraire |
| EmployésCible du scénario | Non | Réagissent comme ils le feraient normalement |
Test caché n'est pas surveillance cachée
On confond facilement les deux, car dans les deux cas quelqu'un n'est pas informé de quelque chose. Ils diffèrent pourtant par nature. Le test caché est un exercice planifié, limité dans le temps, qui vérifie les défenses, approuvé d'avance par la direction et clos par un débriefing. La surveillance cachée consiste à observer en secret les employés dans la durée, et de nombreux pays ne l'admettent que dans des exceptions étroites.
La surveillance ordinaire des employés se pratique mieux à découvert, avec une politique écrite et une information claire, par exemple un bandeau de consentement à la connexion. Un test caché n'y change rien. Les testeurs ne doivent pas lire de messages personnels ni collecter de vraies données d'employés, et le débriefing doit dire clairement ce qui a été fait.
Erreurs fréquentes
La plupart des tests cachés échouent pour des raisons d'organisation plutôt que techniques :
N'effectuez jamais un test caché sans autorisation écrite : sans elle, l'exercice peut être traité comme une véritable attaque.
- Traiter un échec comme un verdict sur une personne : un clic sur un lien de phishing simulé est un signal sur le processus, et le blâme apprend aux gens à cacher leurs erreurs.
- Aucune condition d'arrêt : un scénario qu'on ne peut pas stopper peut perturber le travail réel ou déclencher une vraie réponse d'urgence.
- De vraies données dans le scénario : utilisez des fichiers factices et des comptes de test, jamais de données de clients ou d'employés.
- Des appareils laissés sur place sans registre : un test avec des supports amovibles exige un journal de chaque appareil déposé et récupéré.
- Ne le faire qu'une fois : un résultat isolé vieillit vite, car les personnes, les outils et les règles changent.
Par où commencer
Commencez petit et simple : un scénario, un contrôle, une mesure claire. Choisissez le scénario qui vous inquiète le plus, convenez de la mesure d'avance, par exemple le temps avant que la première personne le remarque, et rejouez le test après les corrections. Une série de petits tests en dit plus avec le temps qu'un seul exercice spectaculaire.
Présentez les résultats comme une propriété du système : délai de détection, délai de réaction et endroit où la chaîne s'est rompue, jamais une liste de noms.
Un contrôle jamais testé n'est qu'une hypothèse. Un test caché la transforme en mesure.
Anexet TeamComment Anexet traite ce sujet
Anexet ne réalise pas de tests cachés et n'attaque personne : c'est la couche de détection que ce type de test vérifie. Les éléments de console ci-dessous montrent si un scénario a été remarqué.
Règles et incidents
Une règle de sécurité enregistre un incident quand un transfert remplit sa condition, et l'onglet Rules affiche le nombre d'incidents et le niveau de risque de chaque règle.
Statut et catégorie
Chaque incident porte un statut, comme False alert ou Important incident, et peut recevoir une catégorie, de sorte que les incidents de test peuvent être étiquetés et examinés à part des incidents réels.
De l'incident à l'activité
La commande Open user activity sur un incident montre ce que l'utilisateur a fait autour de ce moment, ce qui aide à retracer tout le parcours d'une action de test.
Anexet DLP
En savoir plus