Test de phishing par SMS pour les employés : liste de contrôle pour

Un test de hameçonnage par SMS destiné aux employés doit permettre de vérifier s’ils sont capables de reconnaître, de valider et de signaler des SMS suspects sans collecter de mots de passe, de codes d’authentification multifactorielle (MFA), de données de paiement ou d’informations personnelles. Sur les téléphones gérés par l’entreprise, le test doit également valider l’enregistrement de l’appareil, l’utilisation des numéros de téléphone approuvés, la livraison par l’opérateur, les rapports mobiles et la précision des événements. Les acheteurs devraient comparer ces contrôles opérationnels avant de comparer les bibliothèques de modèles.

Les appareils gérés simplifient certaines choses, mais ils ne rendent pas pour autant une simulation de smishing automatiquement autorisée, confidentielle ou utile. Un numéro de téléphone professionnel peut être enregistré dans plusieurs systèmes, les outils de sécurité mobile peuvent analyser automatiquement les liens, et les employés peuvent tout de même utiliser l’appareil pour une utilisation personnelle limitée. Un programme sûr doit avoir un objectif documenté, une source de destinataires contrôlée, un processus de signalement efficace et des limites claires sur les données collectées.

Ce guide est axé sur la prévention. Il ne fournit pas de modèles de SMS trompeurs, de techniques d’usurpation d’identité de l’expéditeur, d’instructions pour contourner la livraison, de méthodes de collecte d’identifiants, ni de conseils pour des tests non autorisés.

Définis ce que le test par SMS doit démontrer

Commence par un comportement que l’entreprise souhaite améliorer. « Mesurer qui clique » est trop vague, car un clic peut être accidentel, généré par un scanner de sécurité ou sans rapport avec le fait que l’employé savait ou non comment réagir en toute sécurité.

Un objectif utile pourrait être de vérifier si les employés :

prennent le temps de réfléchir avant de donner suite à une demande inattendue sur leur mobile ;
vérifient la demande via un canal professionnel approuvé ;
signalent un SMS suspect via la procédure documentée ;
évitent de traiter une autorisation sensible par SMS ; ou
savent quoi faire après avoir interagi avec un message suspect.

Choisis un objectif principal pour le projet pilote et définis les éléments qui prouveront que c’est une réussite. Par exemple, pour le signalement, il faut un destinataire connu, un accusé de réception, un compte-rendu de triage et une mention dans le rapport de formation. C’est un test d’acceptation plus pertinent que de simplement vérifier si un opérateur SMS a renvoyé un statut de livraison.

Si les tests sur mobile s’inscrivent dans un programme plus large, utilise le guide d’achat pour la formation à la sensibilisation au phishing pour harmoniser les simulations, la formation, le renforcement et la gouvernance.

Vérifie l’autorisation et la propriété des numéros de téléphone

Le fait qu’un téléphone appartienne à l’entreprise ne répond pas à toutes les questions d’autorisation. Les services de sécurité, informatiques, de protection de la vie privée, des ressources humaines, juridiques et les représentants du personnel devront peut-être se mettre d’accord sur qui est concerné, comment les employés sont informés et quels résultats sont visibles par les responsables. Les exigences varient selon l’organisation et la juridiction.

Avant l’achat ou le lancement d’un projet pilote, précise par écrit :

quels groupes d’appareils gérés sont éligibles ;
quel système fait autorité pour les numéros de téléphone professionnels ;
qui approuve le test et la liste des destinataires ;
quels rôles, régions, statuts de congé ou groupes sensibles sont exclus ;
si les prestataires et le personnel temporaire sont soumis à des conditions distinctes ;
comment les employés peuvent corriger un numéro obsolète ou réattribué ; et
dans quel délai un numéro est supprimé après la restitution d’un appareil ou le départ d’un employé.

N’utilise pas les numéros de contact d’urgence ou les numéros personnels issus des dossiers des RH. La plateforme ne doit importer que les coordonnées professionnelles approuvées et conserver une trace claire des décisions d’inclusion et d’exclusion.

Compare l'intégration des appareils gérés sans collecter trop de données

Une plateforme de phishing par SMS a rarement besoin d'un accès étendu à l'appareil mobile. Elle a besoin d'un numéro approuvé, de suffisamment de données d'identité pour attribuer l'événement de formation, et d'un ensemble limité d'événements d'envoi et de réponse. La gestion des appareils mobiles doit rester l’autorité en matière d’inventaire et de conformité des appareils, plutôt que de servir de prétexte pour collecter des données comportementales supplémentaires.

Demande aux fournisseurs de démontrer :

une synchronisation ou une importation contrôlée des numéros de téléphone éligibles ;
la séparation des numéros professionnels des fiches de contact personnelles ;
la validation des changements de numéro, des réattributions et des doublons ;
un accès basé sur les rôles aux identifiants mobiles et aux résultats ;
des règles de conservation et de suppression configurables ;
des journaux d'audit pour les importations, les validations de campagnes, les exportations et les modifications administratives ; et
un moyen d'exécuter le programme sans lire le contenu des SMS des employés, leurs contacts, les données des applications ou les données de télémétrie de l'appareil qui ne sont pas liées à l'exercice.

L’intégration la plus sûre est ciblée et transparente. Un fournisseur doit pouvoir préciser quels champs de données il reçoit, pourquoi chaque champ est nécessaire, où les données sont traitées, combien de temps elles sont conservées et comment leur suppression est vérifiée.

Tester la livraison comme une dépendance opérationnelle

La livraison des SMS diffère de celle des e-mails d’entreprise. Les opérateurs, les pays, les types d’expéditeurs, les filtres, les paramètres des téléphones, l’itinérance et les changements de numéro peuvent tous influencer l’arrivée d’un message et la façon dont il s’affiche. Les résultats de livraison doivent donc faire l’objet d’une validation spécifique avant de pouvoir interpréter le comportement des employés.

Lors d’un test technique limité, vérifie :

les pays, opérateurs et formats d’expéditeur pris en charge ;
comment l’identité de l’expéditeur s’affiche sur les configurations iOS et Android gérées concernées ;
comment les messages retardés, bloqués, dupliqués ou ayant échoué sont représentés ;
si les exigences des opérateurs ou des télécoms ajoutent du texte obligatoire ou un mécanisme de désabonnement ;
si la plateforme peut interrompre un test rapidement ;
comment les scanners de sécurité, les aperçus de liens et les outils de protection mobile affectent les événements ; et
si les enregistrements de livraison peuvent être rapprochés sans exposer les numéros de téléphone complets dans les rapports de routine.

Ne demande pas à un fournisseur de contourner les protections des opérateurs ou de dissimuler le trafic. Si un test repose sur le contournement des mesures de sécurité, ce n’est pas un exercice de sensibilisation adapté.

Exige un canal de signalement mobile que les employés peuvent utiliser

Les boutons de signalement par e-mail ne suffisent pas pour le signalement par SMS. On peut demander aux employés de transférer un message, de faire une capture d’écran, d’ouvrir un portail de service, d’appeler un service d’assistance ou d’utiliser une application de sécurité mobile. Chaque méthode présente des compromis différents en matière de facilité d’utilisation et de confidentialité.

Avant d’envoyer une simulation, définis un canal de signalement principal et un canal de secours. Teste ensuite le parcours complet :

Un employé signale le SMS suspect depuis un téléphone géré pris en charge.
Le signalement parvient au SOC ou à la file d’attente du service d’assistance approprié.
Les analystes peuvent distinguer un signalement de simulation d’un véritable incident sans ignorer l’un ou l’autre.
L’employé reçoit un accusé de réception et des conseils pour la suite des opérations en toute sécurité.
La plateforme de formation enregistre le signalement avec précision.
L’entreprise peut remonter une véritable menace mobile découverte pendant l’exercice.

Les captures d’écran et les messages transférés peuvent contenir des notifications sans rapport, des noms de contacts ou d’autres éléments de contexte. Le processus de signalement doit indiquer aux employés comment limiter au maximum les données superflues et ne doit pas les obliger à envoyer du contenu professionnel via un compte personnel.

Mettre en place des contrôles de sécurité stricts pour chaque simulation

Un téléphone géré reste un appareil destiné aux employés, et les SMS peuvent paraître plus personnels et urgents que les e-mails. La gestion des scénarios doit donc être clairement intégrée au produit, et non pas se limiter à une simple promesse informelle.

Exige des contrôles qui empêchent :

la collecte de vrais mots de passe, de codes d’authentification multifactorielle (MFA), de détails de paiement, de jetons ou de données personnelles ;
les liens vers des sites tiers non contrôlés ;
les demandes d’installation d’applications ou d’affaiblissement de la sécurité de l’appareil ;
l’usurpation d’identité de vrais dirigeants ou collègues sans autorisation explicite ;
les thèmes très angoissants liés à la santé, aux licenciements, à l’immigration, aux urgences ou aux finances personnelles ;
les classements punitifs ou l’identification publique d’individus ; et
la modification ou le lancement non contrôlés par des administrateurs qui n’ont pas le pouvoir d’approbation.

La page de destination doit être une page HTTPS approuvée qui n’enregistre que l’événement minimum nécessaire à l’objectif pédagogique, puis fournit un retour pédagogique immédiat. Pour un aperçu des fonctionnalités de simulation sécurisées axées sur les appareils mobiles, consulte la plateforme AutoPhish smishing.

Évalue les retours d’information sur l’appareil que les employés utilisent réellement

Le moment de formation doit fonctionner sur le téléphone géré, pas seulement sur un tableau de bord sur ordinateur. Demande à voir l’expérience complète des employés sur les configurations iOS et Android prises en charge.

Un bon retour d’information doit :

expliquer les signes avant-coureurs pertinents pour le scénario ;
renforcer les procédures approuvées de vérification et de signalement ;
éviter tout langage humiliant ;
rester accessible sur un petit écran ;
prendre en charge les langues requises par le personnel ;
proposer une prochaine étape sécurisée après le signalement et après une interaction à risque ; et
éviter de collecter une nouvelle série d’informations personnelles.

La formation de suivi doit être adaptée au comportement observé. Un bref rappel peut suffire après une seule interaction, tandis que des actions à risque répétées peuvent justifier un accompagnement supplémentaire. Le système doit prendre en compte les exceptions, les congés, les besoins en matière d’accessibilité et les délais d’achèvement que les administrateurs peuvent expliquer.

Utilise des indicateurs qui résistent à un examen technique rigoureux

Le taux de clics brut est particulièrement peu fiable sur mobile. Les services de prévisualisation des liens, les outils de sécurité, les clics accidentels, les messages retardés et les numéros réutilisés peuvent tous fausser les résultats.

Utilise un ensemble équilibré d’indicateurs :

destinataires éligibles, tentatives de livraison, livraisons confirmées et échecs ;
le taux de signalement et le délai médian avant signalement ;
l’utilisation correcte de la procédure de signalement approuvée ;
le rapport entre les signalements et les actions à risque ;
la répétition des comportements lors d’exercices comparables ;
l’achèvement du suivi et le comportement ultérieur ; et
les événements exclus, comme les activités de scan, de prévisualisation, de test ou administratives.

Documente les définitions des événements avant la phase pilote. Les acheteurs devraient demander au fournisseur de montrer comment une livraison par SMS, le chargement d’une page, l’interaction d’un employé, une inspection automatisée, un signalement et la validation d’une formation apparaissent à la fois dans le tableau de bord et dans le fichier d’exportation.

Les recommandations du NIST pour la mise en place de programmes de formation à la cybersécurité et à la protection de la vie privée préconisent un programme de formation adapté aux rôles, mesurable et en amélioration continue. C’est un modèle plus solide que de considérer un simple graphique du taux de clics sur un smishing comme preuve du risque pour les employés.

Lance un projet pilote sur des téléphones gérés avant un déploiement à plus grande échelle

Un petit projet pilote doit tester le fonctionnement du système d’exploitation dans le cadre de la simulation, et pas seulement le message.

Sélectionne un groupe représentatif. Inclue un mélange restreint d’appareils iOS et Android gérés, d’opérateurs, de rôles et de régions.
Vérifie les destinataires. Assure-toi que chaque numéro professionnel est à jour, autorisé et attribué au bon employé.
Vérifie la livraison et les fausses alertes. Note les échecs, les retards, les prévisualisations et l’activité des outils de sécurité.
Teste le processus de signalement. Vérifie la confirmation de l’employé, la file d’attente du SOC ou du service d’assistance, la procédure d’escalade et l’événement sur le tableau de bord.
Opte pour un objectif sans prise de tête. Teste un seul comportement de vérification ou de rapport sans demander d’informations confidentielles ni reproduire un incident en cours.
Vérifie la confidentialité et les accès. Vérifie quels identifiants apparaissent dans les tableaux de bord, les exportations, les tickets et les dossiers de formation.
Fais le point sur les preuves finales. Compare l’éligibilité, la livraison, les actions des employés, les rapports, les événements automatisés exclus et les tâches de suivi.

Le projet pilote doit se terminer par une décision : prêt à être déployé à plus grande échelle, prêt après des corrections précises, ou inadapté au programme prévu. Une simple envoi réussi ne constitue pas à lui seul un critère d’acceptation.

Pose ces questions aux fournisseurs

Privilégie les démonstrations concrètes plutôt que les réponses sous forme de liste de fonctionnalités :

Comment les numéros de téléphone professionnels approuvés sont-ils importés, mis à jour, exclus et supprimés ?
Quels pays, opérateurs, formats d’expéditeur, versions iOS et versions Android sont pris en charge ?
Comment la plateforme distingue-t-elle les actions des employés des aperçus de liens et des scanners de sécurité ?
Les simulations peuvent-elles fonctionner sans collecter de mots de passe, de codes d’authentification multifactorielle (MFA), de données de paiement ou d’autres informations confidentielles ?
Quels canaux de signalement mobile sont pris en charge, et comment les rapports sont-ils intégrés dans notre centre d’opérations de sécurité (SOC) ou dans le workflow de notre service d’assistance ?
Que voit un employé après avoir signalé un incident ou interagi sur un téléphone géré ?
Quels identifiants individuels sont stockés, où, pendant combien de temps, et qui peut y accéder ?
Les administrateurs peuvent-ils imposer des autorisations, des exclusions, des rôles délimités, des limites de conservation et des journaux d’audit ?
Comment les messages échoués, retardés, dupliqués ou bloqués sont-ils représentés dans les rapports ?
Les exportations permettent-elles de concilier éligibilité, livraison, comportement, rapports et suivi sans exagérer l’efficacité ?

Une bonne plateforme doit mettre en évidence les exceptions et les erreurs. Une bibliothèque de modèles bien conçue ne peut pas compenser des données téléphoniques obsolètes, une autorisation insuffisante, des rapports inutilisables ou des indicateurs faussés par des outils automatisés.

Mettre en place un programme mobile géré auquel les employés peuvent faire confiance

Un test de hameçonnage par SMS efficace pour les employés doit réunir plusieurs éléments : des destinataires autorisés, une utilisation restreinte des données, une livraison transparente, des scénarios sécurisés, des rapports pratiques, un apprentissage immédiat et des mesures justifiables. Les téléphones gérés par l’entreprise peuvent faciliter le fonctionnement du programme, mais seulement si la plateforme prend explicitement en charge ces contrôles.

Si tu souhaites évaluer des simulations de smishing contrôlées et les processus de signalement des employés, inscris-toi pour intégrer AutoPhish à ton projet pilote de téléphonie gérée.

Foire aux questions

Un employeur peut-il réaliser un test de smishing sur un téléphone d'entreprise ?

Le simple fait d'être propriétaire de l'appareil ne suffit pas à justifier cette autorisation. L'organisation doit définir l'objectif, la population éligible, la source des données des destinataires, la transparence vis-à-vis des employés, l'accès aux résultats, la conservation des données, les exclusions et les autorisations des parties prenantes requises dans ses juridictions.

Un test de hameçonnage par SMS doit-il collecter des identifiants ?

Non. Un exercice de sensibilisation à la sécurité permet d’évaluer la sécurité des interactions, la vérification, le signalement et le suivi sans stocker de vrais mots de passe, codes d’authentification multifactorielle (MFA), données de paiement ou autres informations confidentielles.

Quel est le meilleur indicateur pour les tests de smishing auprès des employés ?

Aucun indicateur ne suffit à lui seul. Le taux de signalement, le délai de signalement, le bon canal de signalement, la répétition du comportement, la qualité de la diffusion et les résultats du suivi sont plus utiles pris ensemble que le simple taux de clics.

Les téléphones gérés sont-ils plus faciles à tester que les appareils BYOD ?

Ils permettent généralement de mieux cerner la propriété de l’appareil, sa configuration et les limites du support. Ils nécessitent tout de même une utilisation approuvée des numéros, des limites de confidentialité, la validation de l’opérateur, des scénarios sécurisés, un système de signalement fonctionnel et une gestion précise des événements.

Test de phishing par SMS pour les employés : liste de contrôle pour les téléphones gérés