Organigramme du processus de réponse aux incidents de phishing (e-mail signalé)
Modèle de diagramme de réponse aux incidents de phishing : rapport utilisateur, verdict de triage SOC, recherche de courrier à l'échelle du locataire, purge et blocage des indicateurs, réinitialisation des informations d'identification…
Qu'est-ce que le processus organigramme du processus de réponse aux incidents de phishing (e-mail signalé) ?
La réponse à un incident de phishing se produit lorsqu’une personne transmet un e-mail. Le déclencheur est un rapport plutôt qu'une alerte : quelqu'un appuie sur le bouton de rapport de son client de messagerie ou appelle le centre de services au sujet d'un message qui ne semble pas correct. À partir de là, le travail est une boucle courte et répétable. Triez l'échantillon jusqu'à un verdict, trouvez toutes les autres copies parvenues à l'organisation, supprimez ces copies et bloquez ce qu'elles ont indiqué, annulez ce que les destinataires ont déjà fait et dites aux gens ce qui s'est passé. Le tableau ci-dessous suit un rapport de bout en bout en six phases, de l'admission au tri, en passant par la cadrage, le confinement et la récupération, jusqu'aux mesures et au travail de sensibilisation qui déterminent le nombre de rapports que vous recevrez le mois prochain.
Il s'agit du cas du courrier postal et uniquement du cas du courrier postal. Il ne s'agit pas du cycle de vie général de réponse aux incidents de cybersécurité qu'un centre d'opérations de sécurité exécute à partir d'une alerte de détection : ce processus démarre à partir de la télémétrie plutôt qu'à partir d'une personne, et ce tableau lui est transmis sous la rubrique « Signes de compromission de compte ? » lorsqu'une boîte aux lettres s'avère être sous le contrôle de quelqu'un d'autre. Il ne s’agit pas de l’échelle de gravité d’un processus d’escalade d’incident de sécurité, ni d’une réinitialisation de mot de passe de routine, car la réinitialisation ici consiste à contenir un identifiant qu’un attaquant détient déjà et elle est accompagnée d’une révocation de session. Il ne s'agit pas non plus d'une notification de violation : si des données personnelles sont parvenues à un attaquant, l'évaluation, l'horloge légale et la conversation avec un régulateur appartiennent au service juridique et au délégué à la protection des données et se déroulent à côté de ce tableau plutôt qu'à l'intérieur de celui-ci. Considérez le diagramme comme un point de départ pédagogique à adapter en fonction de vos propres procédures de réponse aux incidents, des réglementations qui s'appliquent à vous et de l'examen de votre responsable de la sécurité.
Quatre décisions portent le processus. « Le message signalé est-il malveillant ? » C'est le verdict qui sépare une nuisance d'un incident, et il revient à l'analyste SOC plutôt qu'au centre de services, car un domaine similaire et un échec de vérification d'authentification de l'expéditeur ne constituent pas un jugement de première ligne. « Est-ce que quelqu'un a cliqué ou répondu ? » transforme un travail d'hygiène du courrier en un travail d'identité, et tout ce qui est coûteux sur le graphique y est suspendu. « Qu'a fait l'utilisateur concerné ? » est dessiné comme une branche à trois voies plutôt que comme une file de questions par oui et par non, car la saisie des informations d'identification, une pièce jointe exécutée et un quasi-accident nécessitent que différentes équipes travaillent à des horloges différentes. « Un avertissement à l'échelle du personnel est-il nécessaire ? » se trouve volontairement dans le couloir de gestion de la sécurité : un message adressé à chaque employé est une décision de communication qui a un coût, et l'analyste qui a trouvé la campagne ne devrait pas être la seule personne à la prendre.
Ce que couvre cet organigramme
Dans ce modèle
- Cinq couloirs (employé/journaliste, centre de service, analyste SOC, équipe informatique/identité et gestion de la sécurité) répartis en six phases : rapport et réception, triage et verdict, portée de la campagne, confinement et éradication, récupération et communication, clôture et amélioration.
- Deux itinéraires d'admission alimentant une file d'attente : une pression sur un bouton de rapport qui envoie l'échantillon directement à l'équipe de sécurité, et un ticket du centre de services pour la personne qui appelle à la place, enregistré avec le message d'origine joint plutôt que décrit.
- Une décision de verdict : "Le message signalé est-il **malveillant** ?", dont la branche inoffensive répond au journaliste, ajuste le filtre de courrier et ferme le rapport comme étant non malveillant plutôt que de le laisser tomber en silence, car c'est la réponse qui incite les gens à signaler
- Portée avant suppression avec « Rechercher d'autres copies dans le locataire » et « Quelqu'un a-t-il cliqué ou répondu ? », puis un balayage de confinement qui purge chaque copie, bloque l'expéditeur, les URL et les hachages de fichiers, et boucle sur « D'autres copies arrivent-elles encore ? pendant que la campagne est encore en train d'atterrir
- Une réponse à trois questions « Qu'a fait l'utilisateur concerné ? » branche : l'entrée des informations d'identification va à « Réinitialiser le mot de passe et révoquer les sessions » dans la voie des identités, une pièce jointe ouverte va à l'isolation de l'hôte et à une analyse complète, et « Signes de compromission du compte ? » dégénère au lieu de fermer
- Communication et clôture : « Un avertissement à l'échelle du personnel est-il nécessaire ? est approuvé dans le couloir de gestion de la sécurité, les destinataires sont informés des éléments à surveiller et le rapport se ferme seulement après que les indicateurs, la chronologie, le taux de rapport et le taux de clics, ainsi qu'un suivi de sensibilisation soient enregistrés
Quand utiliser ce modèle
- Vous avez un bouton de rapport dans Outlook ou Gmail et aucun playbook convenu derrière celui-ci, donc ce qui arrive à un e-mail signalé dépend de l'analyste qui le récupère.
- Les utilisateurs transfèrent les courriers suspects vers une boîte de réception partagée que personne ne possède réellement, et vous avez besoin que la réception, le verdict et la réponse au journaliste soient tracés comme un seul chemin.
- Une campagne de phishing d'informations d'identification vient d'atterrir et vous souhaitez que la purge, la réinitialisation, la révocation de session et la vérification des règles de la boîte aux lettres soient ordonnées avant l'arrivée de la suivante.
- Vous rédigez la section phishing d'un plan de réponse aux incidents et vous en avez besoin pour la transmettre proprement au processus d'incident de sécurité plus large plutôt que de la dupliquer.
- Un auditeur a demandé comment le personnel signale un événement de sécurité suspecté et ce qui se passe ensuite. Il s'agit du mécanisme de reporting demandé par le contrôle 6.8 de l'Annexe A de la norme ISO/IEC 27001 :2022.
Comment cela fonctionne
Renommez les voies selon vos rôles
Remplacez l'employé/rapporteur, le Service Desk, l'analyste SOC, l'équipe informatique/identité et la gestion de la sécurité par les rôles que vous avez réellement. De nombreuses organisations ne disposent d'aucune voie de service d'assistance car le bouton de rapport va directement à la sécurité et beaucoup effectuent le travail d'identité au sein du SOC. Supprimez une voie plutôt que de la laisser sans personnel et divisez-en une si un fournisseur de services gérés en possède une partie.
Notez chaque canal d'admission
Répertoriez toutes les manières par lesquelles un rapport de phishing peut arriver : le bouton de rapport, une boîte aux lettres partagée, le téléphone du centre de service, un responsable qui transmet au nom de quelqu'un, un client vous informant que sa facture a été redirigée. Marquez ensuite lesquels d’entre eux atterrissent automatiquement dans la file d’attente de tri et lesquels dépendent du fait qu’une personne se souvienne de le transmettre, car c’est dans cet espace que les rapports sont discrètement perdus.
Définir les critères de verdict de triage
Ouvrez « Le message signalé est-il malveillant ? » et notez les contrôles réellement effectués par vos analystes : alignement de l'authentification de l'expéditeur, domaines similaires et nouvellement enregistrés, détonation d'URL, sandboxing des pièces jointes et si le message demande des informations d'identification, un paiement ou une urgence. Dites également ce qui arrive à un message importun, afin que le spam soit une décision plutôt qu'un haussement d'épaules.
Correction de la recherche de cadrage avant la purge
La purge est aussi bonne que la recherche devant elle. Enregistrez ce sur quoi vous recherchez, qui doit inclure l'adresse de l'expéditeur, le nom d'affichage, le sujet, l'URL et le hachage de la pièce jointe, ainsi que la distance parcourue par vos outils, qui est généralement une courte fenêtre rétroactive sur les boîtes aux lettres cloud uniquement. Notez séparément comment vous trouvez des copies dans les boîtes aux lettres sur site, les archives et tout ce qui a déjà été transféré à l'extérieur.
Convenez de la réponse d'identité et de qui la commande
Décidez à quoi vous engage « Réinitialiser le mot de passe et révoquer les sessions » et qui peut le commander à trois heures du matin. Une réinitialisation à elle seule laisse fonctionner un jeton de session volé, donc la révocation et la vérification des méthodes MFA, des règles de boîte aux lettres et des applications autorisées appartiennent à la même étape. Indiquez comment les nouveaux identifiants parviennent à l'utilisateur via un canal que l'attaquant ne contrôle pas.
Décidez qui autorise un avertissement à l’échelle du personnel
Mettez un nom à côté de « Un avertissement à l'échelle du personnel est-il nécessaire ? » et un seuil en dessous : combien de destinataires, quelles marques ou dirigeants sont usurpés, si quelqu'un a déjà payé ou saisi des informations d'identification. Rédigez l'avis à l'avance, car la version rédigée sous pression est celle qui demande au personnel de surveiller une ligne d'objet que l'attaquant a modifiée il y a une heure.
Comparez-le à un véritable e-mail signalé
Prenez deux rapports récents, l'un qui s'est avéré être du spam et l'autre qui est devenu un véritable incident, et tracez chacun d'entre eux dans le graphique avec les personnes qui les ont traités. Les étapes pour lesquelles personne ne peut nommer un propriétaire, et les étapes qui se sont clairement produites mais qui ne sont pas dessinées, sont des résultats qui méritent d'être corrigés avant de publier le playbook et de l'appliquer.
Questions fréquentes
Quelles sont les étapes du processus de réponse à un incident de phishing ?
Un employé repère un e-mail suspect et le signale, via le bouton de son client de messagerie ou en déposant un ticket au service desk avec le message d'origine en pièce jointe. Un analyste examine les en-têtes, les liens et les pièces jointes et parvient à un verdict. Un message importun entraîne une réponse au journaliste, un changement de filtre et un rapport clôturé. Une copie malveillante est ciblée : recherchez d'autres copies dans le locataire et déterminez si quelqu'un a cliqué ou répondu. Le confinement purge ensuite chaque copie, bloque l'expéditeur, les URL et les hachages de fichiers, et se répète pendant que les copies continuent d'arriver. Ce que l’utilisateur concerné a fait décide du reste. La saisie des informations d'identification signifie une réinitialisation du mot de passe avec révocation de session et une vérification des méthodes MFA, des règles de la boîte aux lettres et des applications autorisées ; une pièce jointe ouverte signifie une isolation de l'hôte et une analyse ; les signes de compromission de compte se transforment en réponse à l'incident. Sinon, l'équipe évalue un avertissement à l'échelle du personnel, indique aux destinataires ce qu'il faut surveiller, enregistre les indicateurs et les mesures, et conclut avec le journaliste.
En quoi la réponse au phishing diffère-t-elle de la réponse aux incidents de cybersécurité ?
Portée et déclencheur. La réponse au phishing est un processus volumineux et largement reproductible qui commence lorsqu'une personne signale un message et qui se termine dans la plupart des cas sans qu'un incident ne soit déclaré : le courrier est purgé, les indicateurs sont bloqués et le signaleur reçoit une réponse. Un processus de réponse aux incidents de cybersécurité commence à partir d'une détection ou d'une compromission confirmée et comprend la déclaration, la gravité, un commandant d'incident, l'investigation, l'éradication et la récupération. Les deux se rencontrent à un moment donné sur ce graphique. Lorsque les contrôles d'identité montrent qu'une boîte aux lettres n'est plus sous le contrôle de son propriétaire, la réponse au phishing a fait son travail et passe le relais. Les garder séparés est une question dans les deux sens : exécuter chaque e-mail signalé tout au long du cycle de vie complet de l'incident épuise l'équipe, et traiter une prise de contrôle de compte en direct comme un nettoyage de boîte aux lettres perd l'attaquant.
Une réinitialisation du mot de passe est-elle suffisante après que quelqu'un a saisi ses informations d'identification sur une page de phishing ?
Généralement non. Les kits modernes de phishing d'informations d'identification fonctionnent comme un adversaire intermédiaire : la fausse page remplace la véritable connexion, de sorte que le mot de passe et l'invite multifactorielle sont tous deux relayés vers le véritable service et l'attaquant capture la session et actualise les jetons qui reviennent. Ces jetons continuent de fonctionner après le changement de mot de passe, c'est pourquoi ce tableau associe la réinitialisation à la révocation de session dans la même étape et le suit avec une vérification des méthodes MFA inscrites, des règles de transfert de boîte aux lettres et des applications OAuth autorisées, les trois endroits où les attaquants laissent généralement un chemin de retour. À plus long terme, le contrôle qui supprime l'attaque plutôt que de nettoyer après son authentification résistante au phishing. Les directives CISA nomment les authentificateurs FIDO/WebAuthn et les méthodes basées sur PKI telles que les cartes à puce comme formes résistantes au phishing, car elles lient la connexion au domaine réel et échouent sur un proxy.
Pouvez-vous supprimer un e-mail de phishing de chaque boîte aux lettres après son envoi ?
En partie, et cela vaut la peine de connaître les limites avant de le promettre. Les plateformes de messagerie cloud permettent la suppression rétroactive des messages qui s'avèrent malveillants après leur livraison. La purge automatique zéro heure de Microsoft, par exemple, agit sur le courrier déjà livré dans les boîtes aux lettres cloud, sa recherche couvre les dernières 48 heures de courrier électronique livré et elle ne fonctionne pas dans les boîtes aux lettres sur site protégées par Microsoft 365. La recherche et la purge pilotées par les analystes à partir du portail de sécurité vous offrent un réseau plus large, mais toujours uniquement sur les boîtes aux lettres détenues par la plateforme. Ce qu'aucune purge n'atteint, c'est une copie que le destinataire a déjà transférée à l'extérieur, un message extrait d'une archive locale ou une capture d'écran dans un fil de discussion. C'est pourquoi le graphique boucle sur « D'autres exemplaires arrivent-ils encore ? » plutôt que de traiter la purge comme un événement unique, et pourquoi dire aux destinataires ce qu'il faut surveiller reste sur le chemin critique.
Un incident de phishing doit-il être signalé à un régulateur ?
Cela dépend de ce que l’attaquant a obtenu, et ce n’est pas la décision de l’analyste à prendre seul. En vertu du RGPD du Royaume-Uni et de l'UE, un responsable du traitement doit informer son autorité de contrôle d'une violation de données personnelles sans délai injustifié et, si possible, au plus tard 72 heures après en avoir pris connaissance, à moins qu'il soit peu probable que la violation entraîne un risque pour les droits et libertés des individus ; une notification tardive doit comporter les raisons du retard. Les régimes sectoriels, les contrats et les polices de cyber-assurance règlent en outre leur propre horloge. La règle pratique est que dès que ce tableau présente des signes de compromission du compte, les services juridiques et le délégué à la protection des données interviennent en parallèle pendant que le travail technique se poursuit. Par ailleurs, plusieurs autorités nationales prélèvent elles-mêmes l'échantillon : au Royaume-Uni, le NCSC Suspicious Email Reporting Service accepte les messages transmis à report@phishing.gov.uk.
Où ce processus s'inscrit
Dans la plupart des opérations, ce processus passe le relais à Organigramme du processus de réponse aux incidents de cybersécurité (SOC).
C'est une étape de Réponse aux incidents de sécurité.
Étape 1: Organigramme du processus de réponse aux incidents de phishing (e-mail signalé) Vous êtes ici
Modèle de diagramme de réponse aux incidents de phishing : rapport utilisateur, verdict de triage SOC, recherche de courrier à l'échelle du locataire, purge et blocage des indicateurs, réinitialisation des informations d'identification…
Étape 2: Organigramme de classification de la gravité des incidents
Un organigramme de classification de la gravité des incidents : un arbre de décision prenant en compte les tests de disponibilité, de portée, d'impact commercial et d'exposition jusqu'à P1, P2, P3 ou P4.
Étape 3: Organigramme du processus de réponse aux incidents de cybersécurité (SOC)
Étape 4: Organigramme du processus de remontée des incidents de sécurité (SOC à RSSI)
Étape 5: Organigramme du processus de réponse aux incidents de sécurité
Étape 6: Organigramme du processus de réponse aux violations de données (horloge RGPD…