Safe Links dans Microsoft 365 : réécrire les liens est-il vraiment judicieux ?

Une mesure de sécurité doit aider les personnes à évaluer un risque, et ne doit pas masquer les informations dont elles ont besoin pour le faire.

Microsoft Defender pour Office 365 peut vérifier les liens des e-mails avec Safe Links. Lorsqu'un destinataire clique sur un lien suspect, Microsoft peut bloquer l'accès au site web. C'est une couche de protection supplémentaire utile contre le phishing.

Beaucoup d'organisations activent en plus la réécriture des liens. L'URL d'origine est alors remplacée par une longue adresse sur safelinks.protection.outlook.com. Microsoft peut ainsi vérifier à nouveau le lien au moment où quelqu'un clique dessus.

Le problème est que le destinataire voit alors moins bien où mène réellement le lien. Au moment même où l'on apprend aux collaborateurs à vérifier l'adresse avant de cliquer, la mesure technique de sécurité rend cette adresse plus difficile à lire.

Le débat ne porte donc pas sur l'utilité de Safe Links. La vraie question est de savoir si cette protection exige de réécrire chaque lien.

Que fait exactement Safe Links ?

Safe Links fait partie de Microsoft Defender pour Office 365. Bien que la fonction soit souvent présentée comme une fonction Exchange, elle se configure dans le portail Microsoft Defender ou via Exchange Online PowerShell. Safe Links peut effectuer plusieurs vérifications :

• Les liens sont examinés avant la remise de l'e-mail.
• Les liens suspects et les liens vers des fichiers peuvent être examinés plus en profondeur.
• Microsoft peut retenir la remise du message jusqu'à la fin de la vérification.
• Le lien peut être vérifié à nouveau lorsque le destinataire clique dessus.
• Un site malveillant connu peut être bloqué avant son ouverture.

La vérification avant remise a lieu que le lien soit réécrit ou non. La réécriture n'est donc pas nécessaire pour cette première vérification.

Que se passe-t-il lors de la réécriture ?

Un lien d'origine peut ressembler à ceci : https://www.example.com/connexion. Safe Links peut le transformer en une adresse commençant par https://eur01.safelinks.protection.outlook.com/. La destination d'origine est alors encodée dans une longue série de paramètres derrière l'adresse Microsoft. Lorsque le destinataire clique sur le lien, la requête passe d'abord par Microsoft, qui vérifie si la destination est entre-temps connue comme malveillante.

Cette vérification au moment du clic est précieuse. Un site web peut encore être inoffensif à la réception de l'e-mail et n'être modifié que quelques heures plus tard. On parle aussi d'attaque de phishing différée. Grâce à la vérification au moment du clic, Microsoft peut tout de même bloquer un site modifié après coup.

Pourquoi la destination devient moins reconnaissable

Une URL contient des informations. Le domaine montre quelle organisation se trouve derrière le site web. Un collaborateur peut par exemple voir la différence entre https://login.microsoftonline.com et https://microsoft.controle-connexion.example. Dans le second exemple, le visiteur n'arrive pas chez Microsoft. Le vrai domaine est controle-connexion.example. Le mot Microsoft n'est là que pour inspirer confiance.

Les autorités de cybersécurité conseillent donc aux destinataires de survoler un lien avant de cliquer et de vérifier quelle adresse apparaît. Repérer les petites anomalies dans les noms de domaine est aussi un élément important pour reconnaître le phishing.

Safe Links peut compliquer cela. Lors de la copie d'un lien, dans certaines notifications, en texte brut et dans certaines autres applications, le destinataire voit surtout la longue adresse Microsoft. La vraie destination n'est alors plus directement reconnaissable.

Microsoft indique que les versions prises en charge d'Outlook peuvent afficher l'URL d'origine dans une fenêtre lors du survol d'un lien réécrit. Dans l'affichage normal d'Outlook, la destination n'est donc pas toujours totalement masquée. L'expérience peut toutefois varier selon la version d'Outlook, l'appareil, le format du message et l'application dans laquelle l'e-mail est ouvert.

L'objection à la réécriture n'est donc pas que la destination d'origine soit invisible en toutes circonstances. L'objection est qu'un lien simple et reconnaissable est remplacé par une construction technique complexe dont la lisibilité dépend de l'application utilisée.

La mesure de sécurité contredit la formation

Beaucoup d'organisations apprennent à leurs collaborateurs à :

• vérifier le domaine avant de cliquer ;
• survoler un lien pour voir la destination ;
• repérer les orthographes inhabituelles ;
• vérifier si l'adresse correspond à l'expéditeur ;
• en cas de doute, aller soi-même sur le site connu.

Ce sont des conseils judicieux. Ils aident les collaborateurs à évaluer un risque de façon autonome. Mais lorsque tous les liens sont réécrits vers une adresse Microsoft, un message contradictoire apparaît. L'organisation dit que les collaborateurs doivent vérifier un lien, alors que la configuration technique rend cette vérification plus difficile.

Une longue URL Safe Links peut aussi inspirer une confiance involontaire. Le destinataire voit en effet une adresse de Microsoft. Il peut en tirer la conclusion erronée que le site final doit être sûr.

Safe Links vérifie un lien, mais ne garantit pas qu'un site web soit fiable. De nouveaux sites de phishing peuvent encore être inconnus. Un site légitime peut avoir été compromis, et les attaquants peuvent utiliser des techniques pour montrer aux contrôles automatisés un contenu différent de celui présenté aux visiteurs ordinaires. La vérification technique reste donc une couche de protection supplémentaire et ne doit pas remplacer le jugement du destinataire.

Microsoft peut aussi vérifier sans réécrire

Dans une stratégie Safe Links personnalisée, Microsoft propose le réglage Do not rewrite URLs, do checks via Safe Links API only (ne pas réécrire les URL, effectuer les vérifications uniquement via l'API Safe Links). Lorsque ce réglage est utilisé :

• l'URL d'origine reste dans le message ;
• le lien est toujours vérifié avant la remise ;
• Microsoft peut vérifier à nouveau au moment du clic dans les versions prises en charge d'Outlook ;
• le contenu de l'e-mail n'a pas besoin d'être modifié.

La vérification au moment du clic s'effectue alors via une fonction d'Outlook plutôt que par une redirection dans l'URL. Microsoft la prend en charge dans Outlook pour Windows, Outlook pour Mac et Outlook sur le web. Cela montre que l'analyse et la réécriture sont deux choix de conception distincts. On peut utiliser Safe Links sans modifier automatiquement chaque URL.

La limite de la vérification via l'API Safe Links

La variante API a aussi un inconvénient important. La vérification au moment du clic ne fonctionne que dans les applications qui prennent en charge cette fonction. Si quelqu'un ouvre le message dans un autre client de messagerie, la vérification avant remise subsiste, mais la vérification supplémentaire au clic peut manquer. Un lien qui était sûr à la réception et rendu malveillant plus tard pourrait alors quand même être ouvert.

Microsoft cite lui-même l'exemple d'un utilisateur qui clique sur un tel lien modifié après coup dans un client de messagerie alternatif. Comme ce client ne prend pas en charge l'API Safe Links, la modification n'est pas détectée au moment du clic. Le choix de ne pas réécrire doit donc reposer sur l'environnement de travail réel :

• Presque tous les collaborateurs utilisent-ils une version prise en charge d'Outlook ?
• Les e-mails professionnels sont-ils aussi ouverts dans d'autres clients de messagerie ?
• Les messages sont-ils souvent transférés automatiquement vers des adresses externes ?
• Les collaborateurs utilisent-ils des appareils partagés ou des versions obsolètes d'Outlook ?
• Quelle importance accorde-t-on à la protection contre les liens qui ne deviennent malveillants que plus tard ?
• Quel poids donne-t-on à la reconnaissabilité de la destination d'origine ?

Il n'existe donc pas de réglage qui soit automatiquement le meilleur dans chaque organisation.

Microsoft utilise lui-même les deux modèles

Les configurations par défaut de Microsoft montrent qu'il n'y a pas de choix univoque. Dans la protection de base intégrée, Microsoft utilise Safe Links sans réécriture d'URL. Dans les niveaux de sécurité prédéfinis Standard et Strict, les liens sont au contraire réécrits.

Lorsqu'une nouvelle stratégie personnalisée est créée via le portail Microsoft Defender, l'option de ne pas réécrire est activée par défaut. Si la stratégie est créée via PowerShell, la réécriture n'est pas désactivée par défaut.

Dans Microsoft Teams et les applications Office prises en charge, Microsoft peut également vérifier les liens au moment du clic sans les réécrire. Cela confirme que la réécriture d'URL n'est pas une condition technique pour toute forme de protection Safe Links.

Quelle configuration est judicieuse pour la plupart des organisations ?

Pour une organisation qui travaille principalement avec des versions actuelles et prises en charge d'Outlook, la configuration suivante mérite d'être envisagée :

• Activez Safe Links pour l'e-mail.
• Activez l'analyse en temps réel des liens suspects et des liens de téléchargement.
• Laissez Microsoft retenir la remise jusqu'à la fin de la vérification.
• Appliquez Safe Links aussi aux messages internes lorsque le risque de comptes internes compromis pèse suffisamment lourd.
• Activez « ne pas réécrire les URL, effectuer les vérifications uniquement via l'API Safe Links ».
• N'autorisez pas les utilisateurs à passer outre un avertissement Safe Links sérieux.
• Testez le fonctionnement dans toutes les versions d'Outlook utilisées et sur tous les appareils concernés.

Ainsi, la destination d'origine reste lisible, la vérification avant remise est conservée et les versions prises en charge d'Outlook vérifient également à nouveau au moment du clic.

Pour les organisations avec de nombreux clients de messagerie différents, la réécriture peut être un choix défendable. La redirection via Microsoft garantit alors que la vérification au moment du clic ne dépend pas d'Outlook. La réécriture n'est donc pas mauvaise par définition. Elle est surtout mauvaise lorsqu'elle est activée sans réflexion, puis présentée comme un pur gain de sécurité.

Considérez aussi les inconvénients pour l'e-mail et les investigations

La réécriture des liens n'a pas seulement des conséquences pour la sensibilisation. Elle modifie aussi le contenu du message. Cela peut se remarquer lors :

• de la copie d'un lien dans un document ou un signalement ;
• du transfert d'un message ;
• de l'archivage des e-mails ;
• de la comparaison d'un message avec l'original ;
• d'une investigation numérique après un incident ;
• du traitement par d'autres systèmes de messagerie ou de tickets ;
• de l'affichage des liens sur les appareils mobiles ;
• de l'accessibilité et de l'utilisation de technologies d'assistance.

Microsoft réécrit en outre une URL par destinataire. Lorsqu'un message est transféré ou reçoit une réponse manuellement, des liens déjà réécrits peuvent rester réécrits.

Pour l'investigation d'un incident, la destination d'origine peut généralement encore être extraite de l'URL Safe Links, mais pour un destinataire ordinaire, ce n'est pas praticable. Une mesure de sécurité déchiffrable pour l'investigation technique n'en est pas pour autant conviviale.

La vérification humaine reste nécessaire

Aucune vérification technique ne connaît tous les sites malveillants. Surtout dans le cas du phishing ciblé, un domaine peut n'exister que depuis peu ou n'être utilisé que contre un petit groupe de victimes. Les collaborateurs doivent donc continuer à regarder le contexte :

• Est-ce que j'attends ce message ?
• La demande correspond-elle à l'expéditeur ?
• Y a-t-il une urgence inhabituelle ?
• Dois-je me reconnecter alors que ce n'est normalement pas nécessaire ?
• Demande-t-on de l'argent, des données personnelles ou une modification de coordonnées de paiement ?
• La destination correspond-elle à l'organisation mentionnée dans le message ?

Une URL reconnaissable aide à cette évaluation, mais ne suffit pas. Même un domaine d'apparence correcte peut avoir été compromis. La vérification des URL doit donc être combinée avec des accords de procédure, une authentification multifacteur résistante au phishing et un moyen simple de signaler.

Comment intégrer Safe Links dans un programme de sensibilisation ?

Expliquez aux collaborateurs ce que Safe Links fait et ne fait pas. Se contenter de dire que la fonction existe ne suffit pas. Le message principal est :

Safe Links peut bloquer des sites malveillants connus, mais un lien qui n'est pas bloqué n'est pas automatiquement sûr.

Montrez en formation :

• comment une adresse web normale est construite ;
• où se trouve le vrai domaine dans une longue URL ;
• comment les sous-domaines peuvent être détournés ;
• que l'adresse Microsoft de Safe Links n'est pas la destination finale ;
• comment les collaborateurs signalent un e-mail suspect ;
• quand vérifier l'expéditeur par un autre canal.

Utilisez les simulations de phishing pour mesurer plus que le seul taux de clic. Mesurez aussi combien de collaborateurs signalent un e-mail suspect et à quelle vitesse le premier signalement arrive. Un collaborateur qui fait un bon signalement peut éviter que des dizaines de collègues cliquent sur le même lien. En pratique, cela vaut souvent plus que la poursuite d'un taux de clic irréaliste de zéro.

La conclusion

Safe Links est une mesure de sécurité précieuse. L'analyse des liens avant la remise et au moment du clic peut prévenir de nombreuses attaques de phishing. La réécriture automatique de chaque lien a toutefois un prix. Elle rend la destination moins transparente, modifie le contenu de l'e-mail et peut saper le conseil de sécurité de vérifier soi-même les liens.

Comme Microsoft prend aussi en charge la vérification via l'API Safe Links, les organisations n'ont pas à choisir d'office entre protection technique et lisibilité. Pour les organisations qui utilisent presque exclusivement des versions prises en charge d'Outlook, la vérification via l'API Safe Links sans réécriture d'URL s'impose. Dans un environnement avec de nombreux clients de messagerie différents, la réécriture peut rester justifiée.

Le bon choix ne commence donc pas par la question de savoir quel bouton Microsoft recommande, mais par la question de savoir quelle configuration offre, dans votre environnement de travail, la meilleure combinaison de protection technique, de transparence et de comportement sûr.

Articles associés

• Avertissement expéditeur externe dans Exchange: efficacité du bandeau?
• Reconnaître le phishing: les signaux importants
• Pourquoi les simulations de phishing fonctionnent
• Comment reconnaître et prévenir la fraude au président
• Sécurité des e-mails et ingénierie sociale : ce que les collaborateurs doivent savoir

Sources

• Microsoft Learn : Safe Links dans Microsoft Defender pour Office 365
• Microsoft Learn : Configurer les stratégies Safe Links
• Microsoft Learn : Paramètres de sécurité recommandés pour Microsoft 365
• NCSC (Pays-Bas) : Comment reconnaître un e-mail de phishing ?
• NCSC (Pays-Bas) : Passer à l'action contre le phishing

FAQ

Safe Links est-il la même chose qu'Exchange Online Protection ?

Non. Safe Links est une fonction de Microsoft Defender pour Office 365. La fonction travaille avec la protection habituelle contre les e-mails indésirables et les fichiers malveillants, mais nécessite une licence Defender pour Office 365 adaptée.

Les liens sont-ils encore vérifiés quand la réécriture est désactivée ?

Oui. Microsoft vérifie les liens avant la remise même quand la réécriture d'URL est désactivée. Dans les versions prises en charge d'Outlook, une vérification supplémentaire via l'API Safe Links peut en plus avoir lieu au moment du clic.

Pourquoi Microsoft réécrit-il les liens ?

En faisant passer le clic par Microsoft, la destination peut être vérifiée à nouveau juste avant l'ouverture. Cela protège notamment contre les sites web rendus malveillants seulement après la remise de l'e-mail.

La réécriture d'URL est-elle une mauvaise mesure de sécurité ?

Pas en toutes circonstances. Dans un environnement avec des clients de messagerie variés ou non pris en charge, la réécriture peut offrir une protection précieuse au moment du clic. L'inconvénient est que la destination d'origine devient moins lisible et que le contenu de l'e-mail est modifié.

Quel est l'avantage de l'API Safe Links ?

Le lien d'origine reste intact. L'e-mail est plus lisible et le destinataire peut évaluer plus facilement le domaine de destination. Dans les versions prises en charge d'Outlook, une vérification supplémentaire au moment du clic reste possible.

Quel est l'inconvénient de l'API Safe Links ?

La vérification supplémentaire au clic dépend de la prise en charge par le client de messagerie. Dans un client alternatif, seule la vérification effectuée avant la remise offre une protection.

Un collaborateur peut-il partir du principe qu'un lien non bloqué est sûr ?

Non. Safe Links réduit le risque, mais ne peut pas donner de garantie totale. Des sites de phishing nouveaux, ciblés ou techniquement dissimulés peuvent encore être inconnus. Le destinataire doit donc continuer à évaluer l'expéditeur, le contexte et la destination.

Quel réglage faut-il privilégier ?

Pour les organisations qui utilisent presque exclusivement des versions actuelles et prises en charge d'Outlook, l'analyse via l'API Safe Links sans réécriture d'URL est à privilégier. Dans un environnement de messagerie mixte, l'avantage d'une vérification universelle au moment du clic doit être mis en balance avec la lisibilité réduite.