Évaluer les résultats et les rapports de Sophos Phish Threat

Sophos Phish Threat fournit des résultats à trois niveaux : le Dashboard montre les tendances à l’échelle de l’organisation, la vue de la campagne explique une simulation individuelle et Reports suivent le comportement ou le statut de formation à travers les campagnes. Ce n’est que la combinaison de ces niveaux qui répond à la question de savoir si les messages ont été délivrés, comment les utilisateurs ont réagi et quelle mesure de suivi est appropriée.

Cette procédure s’adresse aux administrateurs autorisés dans le tenant Sophos Fusion (anciennement Sophos Central) approprié. Elle traite les données de rapport comme des données personnelles liées à la sécurité : le fait qu’un utilisateur soit piégé par une simulation est un signal de formation et de risque, et non une attribution de responsabilité ni la preuve d’une compromission réelle.

Préparer le périmètre de l’évaluation

Avant l’analyse, le locataire, la campagne, le groupe cible, le type de campagne, la date de début et de fin, la question et la base de comparaison souhaitée sont documentés. Dans le cas d’une comparaison de tendances, le type de campagne, le niveau de difficulté et le groupe cible doivent être suffisamment similaires. Sinon, des taux différents ne peuvent pas être comparés de manière significative.

Pour une évaluation fiable, cet ordre s’applique :

1. Vérifier la situation générale et les campagnes en cours sur le Phish Threat Dashboard.
2. Dans la campagne, contrôler la livraison, les événements et le déroulement temporel.
3. Évaluer le comportement des utilisateurs ou la formation inter-campagnes sous Reports.
4. Suivre les anomalies jusqu’à l’événement utilisateur et le statut de livraison.
5. Ce n’est qu’ensuite qu’il faut définir les groupes cibles pour la formation, une campagne de suivi ou les corrections de livraison.

Lire correctement les indicateurs du tableau de bord

L’accès se fait via My Products > Phish Threat. Active campaigns montre les campagnes actives et à venir. Le tableau de bord affiche, en cas de plus de deux campagnes actives, uniquement les deux campagnes dont la fin est la plus proche ; See all mène à la vue complète. Une campagne manquante n’est donc pas automatiquement supprimée ou terminée.

Organization summary montre les valeurs moyennes des cinq dernières campagnes : le pourcentage moyen d’utilisateurs piégés et le pourcentage moyen d’utilisateurs ayant effectué un signalement.

• Caught-to-open ratio indique combien d’utilisateurs ont été pris en relation avec les utilisateurs qui ont ouvert l’e-mail de phishing. Caught ratio représente cette valeur graphiquement.
• Report-to-open ratio indique combien d’utilisateurs ont signalé par rapport aux utilisateurs qui ont ouvert l’e-mail de phishing. Threat reported ratio représente cette valeur graphiquement.
• Caught users priorise les utilisateurs qui ont été trompés le plus souvent par des simulations.
• Threat reporters montre les utilisateurs qui ont signalé des e-mails de phishing.

Le dénominateur des deux taux est les ouvertures, pas tous les messages adressés ou délivrés. Un Caught-to-open ratio élevé doit donc être évalué différemment qu’un nombre absolu élevé d’utilisateurs interceptés. De même, un faible nombre d’ouvertures ne prouve pas automatiquement un bon comportement en matière de sécurité : les erreurs de livraison ou le suivi des images/ouvertures peuvent influencer la base. Comment différencier les images manquantes, les pixels de suivi et les événements d’ouverture ajoutés après un clic est expliqué dans Vérifier les images manquantes et le suivi des ouvertures.

Awareness factors complète quatre indicateurs de programme :

• Users tested : Part de la base d’utilisateurs ayant été exposée à une simulation.
• Last campaign : indique à quand remonte la dernière campagne.
• Users caught : taux d’erreur agrégé provenant des simulations d’attaque.
• Passed training : Taux d’achèvement des formations de sensibilisation assignées.

Sophos recommande à titre d’orientation de tester tous les utilisateurs au moins une fois tous les trois mois. Cela ne remplace pas la planification propre du risque, de la protection des données et de la formation. Export to PDF exporte les données du tableau de bord et les rapports de campagne au format PDF. La fonction utilisée ne donne aucune indication sur la durée de conservation des fichiers ou des données de rapport générés par Sophos.

Analyser une campagne en détail

La campagne est ouverte sous My Products > Phish Threat > Campaigns. Le résumé contient la date de début et de fin ainsi que des diagrammes en anneau sur la livraison des e-mails, les événements des utilisateurs et les actions dans l’e-mail.

Les domaines suivants répondent à différentes questions :

• Campaign response timeline montre pour les premières heures et jours quand les e-mails ont été envoyés, quand les utilisateurs ont été pris et quand les e-mails ont été signalés. Cela permet d’évaluer la rapidité de réaction.
• Device breakdown montre les types d’appareils sur lesquels les e-mails ont été ouverts ou sur lesquels des utilisateurs ont été surpris. Il s’agit d’un indice d’enquête, pas d’une preuve d’un appareil non sécurisé.
• User Behavior montre les réactions aux e-mails de campagne.
• Email affiche des e-mails d’attaque, d’inscription à la formation et de rappel selon le type de campagne.
• Training montre le cours choisi pour cette campagne.
• Paused affiche des données de pause et de reprise en fonction du statut. En cas de plusieurs pauses, seules les dernières données de pause et de reprise sont visibles.

Avec Export, il est possible d’exporter les données de campagne au format PDF ou CSV. L’exportation n’est générée qu’après que la campagne et la vue souhaitée ont été vérifiées. La documentation disponible ne mentionne ni une durée de conservation générale, ni un envoi automatique, ni un calendrier pour ces exportations ; de telles caractéristiques ne doivent pas être supposées.

Vérifier les résultats de la campagne et les événements

Les résultats de la campagne peuvent être consultés avec By User, By Group ou By Attack. By Attack liste tous les modèles qui faisaient ou font partie de la campagne. Dans By User, des horodatages apparaissent ; dans By Group, le nombre d’utilisateurs est indiqué pour chaque événement. Les valeurs de groupe et les horodatages des utilisateurs ne correspondent donc pas directement au même mode de présentation.

Pour Failed ou Blocklisted, la cause de la non-livraison est d’abord résolue. Ensuite, les lignes concernées sont sélectionnées et l’e-mail de la campagne est renvoyé. Une nouvelle livraison réussie supprime automatiquement l’ID e-mail du destinataire de Bounced Mailboxes. Sans correction de l’erreur, les campagnes ultérieures pour cet utilisateur peuvent également échouer.

Important : Pending n’est pas une preuve de livraison. Un faible taux d’interaction ne doit pas être évalué tant que les destinataires pertinents sont Failed, Blocklisted ou encore Pending.

Étudier le comportement des utilisateurs à travers les campagnes

Les filtres suivants sont disponibles sous My Products > Phish Threat > Reports > User Behavior :

• All users : tous les utilisateurs enregistrés pour des campagnes d’attaque simulées,
• Caught users : utilisateurs piégés au moins une fois,
• Repeat users : utilisateurs attrapés plusieurs fois,
• Reported threats : Utilisateurs ayant signalé des menaces simulées,
• Failed to report threats : Utilisateurs ayant ouvert un e-mail d’attaque simulée, mais ne l’ayant pas signalé,
• Entered credentials : utilisateurs ayant saisi des identifiants dans une simulation,
• Opened attachments : Utilisateurs ayant ouvert une pièce jointe simulée.

Le champ de date limite le rapport ; la période choisie est appliquée avec Apply. Pour un contrôle répétable, les filtres, la plage de dates et le moment de l’évaluation sont documentés ensemble. Export to CSV exporte la vue actuelle. Avant de la transmettre, on vérifie si le fichier contient réellement uniquement la période et le groupe de personnes prévus.

Caught users, Repeat users et Entered credentials servent à la priorisation basée sur le risque. Des étapes suivantes appropriées sont une formation adaptée, une campagne de suivi contrôlée et, en cas de schémas répétitifs, une discussion dans le processus organisationnel prévu à cet effet. Reported threats est un comportement positif ; Failed to report threats signifie simplement « ouvert, mais non signalé » et ne doit pas être assimilé à « attrapé » ou « données d’accès saisies ».

Avec Create campaign with these users, une nouvelle campagne préremplie peut être lancée à partir du groupe cible de rapport actuellement filtré. Avant de continuer, les destinataires, l’objet, la base juridique ou l’approbation interne, la formation et l’heure d’envoi sont vérifiés. Un filtre de rapport n’est pas une autorisation automatique d’envoi.

Suivre l’état d’avancement de l’entraînement

Sous My Products > Phish Threat > Reports > Training, le rapport affiche l’état d’inscription et de conformité. Sont disponibles :

• Enrolled in Trainings pour les utilisateurs avec enregistrement de formation,
• Incomplete Trainings pour les utilisateurs qui n’ont pas terminé au moins un cours.

Ici aussi, une plage de dates est choisie et appliquée avec Apply. Export to CSV exporte la vue actuelle ; Create campaign with these users transfère les utilisateurs filtrés vers une nouvelle campagne.

Une formation incomplète n’est pas automatiquement un refus. Avant toute escalade, la fin de la campagne, le moment de l’inscription, l’e-mail de rappel, la livraison et les éventuelles absences sont vérifiés. Pour le contrôle du succès, Finished training est comparé dans la campagne avec le rapport de formation couvrant l’ensemble des campagnes.

Effectuer les actions de suivi de manière contrôlée

De l’analyse émerge une liste de mesures compréhensible :

1. Résoudre les problèmes de livraison avant l’évaluation du comportement.
2. Prioriser Entered credentials, les incidents répétés et les formations non terminées selon le modèle de risque interne.
3. Reconnaître un comportement de signalement positif et surveiller le taux de signalement comme objectif du programme.
4. Pour la campagne suivante, choisir des groupes cibles et des modèles comparables.
5. Après le démarrage, valider à nouveau la livraison, les événements et la formation.

Le cycle de vie de la campagne influence ce qui peut être modifié : Active Campaign et Upcoming Campaign peuvent être édités, supprimés et clonés ; Past Campaigns ne peut pas être modifié. Delete ne peut pas être annulé. Clone crée une entrée sous Campaign Drafts, reprend les détails de l’original et ajoute la date de création dans le nom. Avant toute réutilisation, les destinataires, le modèle, la formation et le calendrier doivent néanmoins être revus.

Valider les résultats

Au moins, ces vérifications sont effectuées avant publication ou escalade :

• Le tableau de bord mentionne la même campagne pertinente que Campaigns ; si plus de deux campagnes sont actives, See all a été vérifié.
• Les taux liés à l’ouverture ne sont pas décrits comme une part de tous les destinataires.
• Dans la campagne, les destinataires, le modèle et la période correspondent à la tâche d’évaluation.
• Le total ou l’échantillon dans By Group est vérifié par rapport aux entrées dans By User.
• Pending, Failed et Blocklisted sont présentés séparément de Delivered.
• Le CSV ou le PDF est ouvert après l’exportation ; le titre, la campagne, la période, les filtres et les colonnes sont vérifiés.
• Un échantillon d’utilisateurs remarquables est examiné en fonction des horodatages des événements et non seulement en fonction d’une liste du tableau de bord.
• Les mesures de suivi sont documentées avec la personne responsable, la date et le critère de réussite.

Les écarts entre le tableau de bord et la vue détaillée sont d’abord dus à des références différentes : Organization summary affiche des valeurs moyennes des cinq dernières campagnes, tandis que la page de la campagne analyse un objet unique et Reports évalue une période de dates choisie.

Protection des données, suppression et audit

Les rapports et les exports contiennent des noms, des adresses e-mail, des réactions, le statut de formation et des données comportementales potentiellement pertinentes pour les risques. L’accès et le partage sont limités aux personnes nécessaires. Les exports sont stockés dans un espace de stockage approuvé, supprimés selon la règle de conservation interne et ne sont pas envoyés par e-mail sans protection. Les rôles, la limitation de l’objectif, la conservation et les autorisations sont régis dans le Runbook sur la protection des données et la gouvernance. Les fonctions décrites ici par Sophos ne constituent pas une durée générale de conservation du produit ; celle-ci n’est pas déduite du comportement d’exportation.

Avec Clear campaign events, il est possible de supprimer des événements d’un utilisateur des résultats de la campagne. Email sent reste conservé, et l’action est enregistrée dans Audit Log. Au préalable, la finalité, l’autorisation et la sécurisation des preuves doivent être clarifiées. La fonction n’est ni une suppression complète de l’utilisateur ni un substitut à un processus de protection des données réglementé.

Phish Threat signale les données d’utilisation tous les 30 jours à Sophos Fusion. Si un utilisateur est supprimé alors qu’il avait été inscrit à une campagne au cours des 30 derniers jours, Sophos Fusion peut le recréer en raison de cette activité. Avant une suppression définitive, la période est donc définie sur les 30 derniers jours sous Phish Threat > Reports > User Behavior > All enrolled > All users et vérifiée via Export to CSV vers Last Targeted ou Last Enrolled. La suppression définitive ne doit être effectuée qu’après 30 jours sans activité. Les autres sources d’identité et de répertoire sont également prises en compte conformément au processus Supprimer un utilisateur Sophos Fusion en toute sécurité.

Attribuer un lien de campagne à une opération

Lorsque plusieurs campagnes, formations ou rappels sont actifs en même temps, le jeton contenu dans un lien d’exemple peut aider à l’attribution. Un administrateur autorisé extrait le jeton à partir d’un modèle sécurisé après le premier signe égal et décode sa charge utile JWT. Le champ campaign_token est ensuite comparé à l’ID de la campagne, visible lorsqu’on survole un lien de campagne ou dans son URL.

Des limites strictes s’appliquent : un lien de production ou un jeton ne doit pas être transmis à n’importe quel décodeur public, ticket ou système de chat. Il peut contenir des données de suivi, de campagne et d’expiration. Une procédure locale approuvée en interne est utilisée ou une autorisation explicite en matière de confidentialité et de sécurité est obtenue. Décoder signifie uniquement lire la charge utile ; cela ne remplace pas la validation de la signature ou la vérification de confiance. Le lien complet ne sera publié ni dans le rapport ni dans le commentaire d’audit.

Résoudre les erreurs fréquentes

• Campagne manquante sur le tableau de bord : vérifier See all ou Campaigns ; le tableau de bord n’affiche que les deux campagnes avec la date de fin la plus proche si plus de deux campagnes sont actives.
• Le taux semble anormalement élevé ou faible : vérifier le dénominateur. Caught-to-open ratio et Report-to-open ratio se réfèrent aux ouvertures, pas à tous les destinataires.
• Aucun événement ou trop peu d’événements : vérifier Delivery Status, le public cible, le modèle et la période ; traiter Pending, Failed et Blocklisted séparément.
• D’autres campagnes n’atteignent pas un utilisateur : Corrigez l’erreur sous Settings > Bounced Mailboxes puis renvoyez ensuite.
• Rapport et campagne se distinguent : vérifier le filtre de date avec Apply, l’étendue de la campagne et les valeurs moyennes des cinq dernières campagnes affichées dans Organization summary.
• L’export contient des personnes inattendues : Avant utilisation, vérifier la vue actuelle, les filtres et la plage de dates ; Export to CSV reprend la vue actuelle.
• L’utilisateur réapparaît après suppression : vérifier l’activité des 30 derniers jours ainsi que Last Targeted et Last Enrolled, et contrôler les sources de répertoires/synchronisation.
• Le lien de la campagne ne peut pas être attribué : décoder localement le jeton complet sans le transmettre, puis comparer exactement campaign_token avec l’ID de la campagne.

Pour une escalade de support, l’ID du locataire, le nom et l’ID de la campagne, le type de campagne, la période avec fuseau horaire, le filtre sélectionné, le statut de livraison concerné, les utilisateurs exemples anonymisés, les horaires des événements et l’écart entre le nombre attendu et visible sont enregistrés. Les jetons, les identifiants et les liens de suivi complets ne sont pas copiés dans la documentation de cas normale.