Déploiement de la prévention des erreurs d’e-mail en mode rapport uniquement
Activer un contrôle qui s’applique à chaque expéditeur nécessite une stratégie qui ne gêne personne. Un avertissement trop fréquent finit par être ignoré, et un contrôle ignoré ne protège plus rien. La réussite de la prévention des erreurs e-mail dépend de la façon dont elle est introduite.
Kiteworks Agent and Human Error Prevention (AHEP) offre aux administrateurs une méthode claire pour y parvenir. Les règles peuvent fonctionner en mode Reporting uniquement, ce qui permet d’évaluer et de consigner chaque message sans afficher la moindre alerte. Le risque, c’est de sauter cette étape, car une nouvelle règle est activée par défaut et s’applique dès son enregistrement.
Cet article détaille le déploiement étape par étape : préparation de la plateforme, création des règles, analyse du référentiel, puis passage du mode Suggestion à Avertissement, preuves à l’appui.
Résumé Exécutif
Un déploiement AHEP efficace se déroule en cinq étapes. Vérifiez les prérequis de la plateforme, créez les règles en mode Reporting uniquement, analysez le référentiel pendant quelques semaines, testez le mode Suggestion auprès d’un groupe à fort enjeu, puis activez le mode Avertissement pour les règles justifiées par les données. Les clients Kiteworks n’ont pas besoin d’un fournisseur supplémentaire, car AHEP fait partie du Data Policy Engine déjà présent sur leur plateforme. À la clé : des règles adaptées à vos propres e-mails, un groupe pilote exposé aux alertes dans leur contexte, et une piste d’audit pour vos responsables sécurité et conformité.
Points Clés à Retenir
- Vérifiez les prérequis de la plateforme avant toute configuration. AHEP nécessite la version 9.5 et le Validation Service sur la couche de services conteneurisés, activé par le support technique Kiteworks sur demande.
- Définissez le statut sur Reporting uniquement avant d’enregistrer. Une nouvelle règle est activée par défaut et appliquée immédiatement, il faut donc commencer par le statut, pas par le seuil.
- Le mode Reporting uniquement fournit un référentiel sans impact utilisateur. Chaque message est évalué et chaque détection consignée, ce qui permet d’identifier les risques après quelques semaines de données.
- Commencez par Suggestion, passez à Avertissement si les données le justifient. Suggestion informe l’expéditeur sans le bloquer, tandis qu’Avertissement exige une décision consciente dès que vos chiffres le permettent.
- Vérifiez la couverture des clients avant de vous engager auprès d’un service. Les alertes fonctionnent dans l’application Web Kiteworks et Outlook Classic, pensez donc aux utilisateurs d’autres clients.
Préparer la Plateforme pour AHEP
Avant toute création de règle, la plateforme doit être prête. AHEP est disponible à partir de la version 9.5, les clients sur une version antérieure doivent donc d’abord planifier la mise à jour et organiser la suite en fonction de cette échéance. Le Validation Service qui évalue les messages fonctionne sur la couche de services conteneurisés Kiteworks (RKE2), sur au moins un nœud applicatif, et doit être activé par le support technique Kiteworks.
Soumettre la Demande
Ouvrez la demande via le portail communautaire Kiteworks avant toute configuration. Des règles créées sans service actif ne fonctionneront pas, et s’en rendre compte après avoir annoncé un pilote à un service serait embarrassant et évitable.
Rôles Nécessaires
La création de règles dans l’application Data Policies requiert le rôle System, Application, Compliance ou Policy Manager, ou un rôle personnalisé avec accès à Data Policies. Identifiez rapidement les détenteurs de ces rôles dans votre organisation, car le responsable du projet n’est pas toujours celui qui crée la règle.
Créer des Règles et Démarrer en Mode Reporting Uniquement
Dans l’application Data Policies, sélectionnez Nouvelle règle puis Agent and Human Error Prevention, ou partez du modèle AHEP qui pré-sélectionne la recommandation BCC. Modifiez le statut sur Reporting uniquement avant d’enregistrer, car la valeur par défaut est Activé. Pour la règle BCC, définissez également le seuil de destinataires externes.
Analyser le Référentiel
Laissez tourner les règles pendant quelques semaines. Chaque message est évalué, chaque détection consignée, et aucun expéditeur ne voit d’alerte. Analysez les détections par règle, les faux positifs, les expéditeurs et les équipes concernées. Comparez ces chiffres à votre journal d’incidents et à ce que votre DLP a signalé sur la même période. Le référentiel vous indique quelle règle doit être priorisée et quel seuil doit être ajusté.
Deux Détails Qui Font Gagner du Temps
La détection fonctionne mieux lorsque les noms de profils utilisateurs suivent un format standard, comme Prénom Nom ou Nom, Prénom, et que les adresses professionnelles ressemblent à prenom.nom@entreprise. C’est particulièrement important pour la règle sur les adresses personnelles, qui compare le destinataire à l’identité de l’expéditeur.
Passer de Suggestion à Avertissement
Prenez la règle la plus critique et activez-la en mode Suggestion pour un groupe pilote. Les services juridiques et financiers sont des points de départ judicieux, car une erreur d’envoi y coûte plus cher. Suggestion informe l’expéditeur sans l’entraver, ce qui permet d’observer les réactions sans ajouter de friction.
Quand Activer le Mode Avertissement
Le mode Avertissement oblige l’expéditeur à traiter ou ignorer l’alerte avant l’envoi. Passez certaines règles en mode Avertissement lorsque les données le justifient. Les rejets sont consignés, ce qui permet d’identifier les seuils ou formations à revoir. Un service qui ignore toutes les alertes BCC vous indique que le seuil n’est pas adapté.
Présenter les Résultats à vos Responsables Sécurité et Conformité
Les règles AHEP apparaissent dans la liste Report by Policy de l’application Audit Log and Reports. Vos RSSI et DPO disposent ainsi d’un historique des détections, directives et décisions, basé sur vos propres e-mails et non sur des estimations d’un fournisseur.
Activer la Prévention des Erreurs sur l’Ensemble du Data Control Plane Kiteworks
Le déploiement d’AHEP n’est pas un projet à part avec son propre fournisseur, console et journal. Il s’agit d’une extension du Data Control Plane Kiteworks que vous exploitez déjà. Le Data Policy Engine régit la messagerie électronique, le partage et le transfert de fichiers, SFTP, MFT et les formulaires, et AHEP ajoute des contrôles de destinataires pour les données en mouvement, là où humains et IA choisissent leur destination. Les événements sont consignés dans un journal d’audit inviolable, pouvant alimenter vos outils SIEM, et ce dispositif complète vos outils DLP et IAM existants.
Si vous êtes déjà client Kiteworks, planifiez une session d’activation avec notre équipe. Nous organiserons ensemble la mise à niveau vers la version 9.5, la demande d’activation du Validation Service et la création de votre référentiel Reporting uniquement, pour que la première alerte affichée à un expéditeur soit déjà parfaitement ajustée.
Foire Aux Questions
Définissez le statut de la règle sur Reporting uniquement avant de l’enregistrer, car une nouvelle règle est activée par défaut et appliquée immédiatement.
AHEP nécessite la version 9.5 de Kiteworks et le Validation Service activé sur la couche de services conteneurisés par le support technique Kiteworks.
Le mode Reporting uniquement évalue et consigne chaque message sans afficher d’alerte, ce qui permet d’obtenir un référentiel des détections, des faux positifs et des zones à risque sans impacter les utilisateurs.
Après analyse du référentiel, testez le mode Suggestion auprès de groupes à fort enjeu comme le juridique ou la finance, puis activez le mode Avertissement uniquement pour les règles justifiées par les données et dont les taux d’ignorance peuvent être suivis.