Découvrez l’Entreprise

La Banque Postale du Congo est une institution financière publique dont le siège se trouve à Brazzaville, en République du Congo. Fondée sur l’héritage de la banque postale du pays, la BPC fournit des services bancaires aux particuliers, aux entreprises et aux organisations à travers la République du Congo.

Pour une institution répondant aux besoins bancaires du secteur public, des entreprises et de la clientèle, une communication par courriel digne de confiance est essentielle. La protection au niveau du domaine contribue à réduire le risque d’usurpation d’identité et à préserver la confiance dans les communications officielles de BPC.

Défi

Pour une banque, la sécurité des emails ne se limite pas au filtrage du spam ou à la protection des boîtes de messagerie. Les attaquants tentent souvent d’exploiter la confiance accordée aux marques financières en usurpant l’identité de dirigeants, d’équipes du service client, d’équipes de paiement, d’alertes, de relevés ou de communications bancaires numériques. La Banque Postale du Congo devait réduire ce risque d’usurpation au niveau du domaine sur son infrastructure de domaine principal et de sous-domaines, tout en maintenant le contrôle sur les flux d’emails à volume élevé et la sécurité MX on-premise existante.

Pourquoi Skysnag

La Banque Postale du Congo disposait déjà de contrôles de sécurité de messagerie en place, notamment une protection MX robuste et une sécurité au niveau MTA. La lacune restante concernait la confiance du domaine : s’assurer que seuls les systèmes autorisés pouvaient envoyer au nom de la banque, et que les sources non autorisées ou suspectes pouvaient être identifiées, surveillées et contrôlées.

Modèle de déploiement

Le déploiement a été conçu autour de la continuité bancaire. Plutôt que de perturber l’infrastructure de messagerie existante de la banque, Skysnag fonctionnerait comme une couche d’authentification de domaine et de confiance, aidant l’équipe à cartographier les expéditeurs légitimes, examiner la posture d’authentification et progresser vers une protection renforcée sans interrompre les flux d’emails critiques.

Étapes de déploiement

1. Cartographier les expéditeurs légitimes – Identifier les systèmes envoyant des e-mails pour le domaine principal et les sous-domaines, y compris l’infrastructure interne et les plateformes tierces.
2. Combler les lacunes d’authentification – Examinez votre posture SPF, DKIM, DMARC, MTA-STS et les rapports TLS pour détecter les points faibles et les sources non autorisées.
3. Progresser vers l’application – Renforcer progressivement les politiques afin que la banque puisse réduire le risque d’usurpation d’identité sans interrompre les communications bancaires légitimes.

Résultats et signaux de preuve

La valeur du projet se mesure en termes de réduction des risques, de contrôle et de visibilité opérationnelle. Pour une banque, l’objectif n’est pas seulement d’améliorer la délivrabilité, mais de rendre plus difficile pour les attaquants l’exploitation abusive des domaines de confiance de l’établissement dans le cadre de campagnes de phishing, de fraude ou d’usurpation d’identité de marque.

Statistiques des résultats

Ce que cela signifie pour les institutions financières publiques et privées

Les banques investissent souvent massivement dans la sécurité périmétrique, des boîtes aux lettres et de la couche transport, mais les attaquants peuvent toujours exploiter une authentification de domaine faible pour usurper l’identité de la marque. Ce cas démontre pourquoi les institutions financières ont besoin d’une couche de confiance de domaine dédiée qui complète la sécurité MX et MTA existante, protège la confiance des clients et donne aux équipes de sécurité un contrôle plus clair sur les entités autorisées à envoyer des messages au nom de la banque.