Cybersécurité pour les services financiers

Quelles sont vos trois contraintes structurantes ?

La preuve opposable à un régulateur, la disponibilité des systèmes de paiement, et la traçabilité des accès entre zones de confiance. Ces trois contraintes se cumulent et se contredisent parfois : la plus forte détermine la méthode de déploiement.

La tension la plus fréquente se situe entre les deux premières. Renforcer les contrôles impose des changements; la disponibilité interdit de les faire brutalement. La réponse n'est pas de choisir, mais de découper.

• Le régulateur et la preuve d'audit. Les régimes de surveillance diffèrent selon que vous êtes une institution sous charte fédérale, un assureur ou un courtier encadré au Québec. L'attente de fond est constante : démontrer la maîtrise du risque technologique par des contrôles documentés, testés et traçables. Une mesure efficace mais non documentée ne compte pas.
• La disponibilité des systèmes de paiement. Elle interdit la bascule unique. Chaque modification doit être réversible dans une fenêtre validée, et le plan de retour arrière doit avoir été testé avant d'être nécessaire.
• La traçabilité des accès inter-zones. Savoir qui a accédé à quoi, quand, et sous quelle autorisation. C'est ce qui permet de qualifier un incident et de répondre à une demande d'explication, y compris des mois plus tard.

Comment segmente-t-on un cœur de réseau bancaire existant ?

En trois temps, sans fenêtre d'arrêt. Cartographier exhaustivement les flux réels, définir les zones de confiance cibles, puis basculer par vagues réversibles avec un retour arrière validé à chaque étape. La cartographie est l'étape la plus longue et la plus décisive.

La difficulté propre à ces environnements est l'histoire qu'ils portent. Un cœur de réseau qui a accompagné vingt ans de croissance contient des flux que plus personne ne documente, des règles créées pour un besoin oublié, et des dépendances qu'aucun schéma ne montre. Couper un de ces flux se paie immédiatement en interruption de service.

• Cartographier avant de toucher. Nous relevons ce qui communique réellement avec quoi, à partir du trafic observé et non de la documentation. C'est cette étape qui révèle les dépendances non documentées, et c'est aussi celle qui rassure le comité qui doit autoriser les travaux.
• Définir les zones de confiance. Selon les principes du modèle Zero Trust, dont la définition de référence est le NIST SP 800-207 : aucun accès accordé sur la seule base de la position réseau, vérification de l'identité et du droit d'accéder à chaque ressource.
• Basculer par vagues. Chaque vague isole un périmètre limité, s'applique hors heures de service quand le contexte l'exige, et se valide avant la suivante. L'objectif explicite est qu'aucune vague ne puisse laisser l'environnement dans un état intermédiaire non maîtrisé.

Comment le dossier d'audit se constitue-t-il ?

Pendant les travaux, à mesure. Chaque décision d'architecture, chaque exception accordée et chaque validation de vague produit une trace datée et attribuée. Reconstituer un dossier après un projet est un exercice que les auditeurs reconnaissent immédiatement.

C'est la différence la plus visible entre un mandat mené pour un environnement réglementé et un mandat ordinaire. Le livrable n'est pas seulement l'architecture : c'est l'architecture plus la démonstration de la façon dont elle a été décidée et vérifiée.

• Les décisions et leurs alternatives. Ce qui a été retenu, ce qui a été écarté, et sur quel critère. Cette trace évite qu'un auditeur, ou un successeur, suppose une négligence là où il y avait un arbitrage.
• Les exceptions. Tout écart au standard cible, sa justification, sa date d'expiration et la personne qui l'a autorisée. Les exceptions sans date de fin sont la première source de dérive que nous constatons.
• Les preuves de contrôle. Résultats de tests, relevés de configuration, journaux de validation des bascules. Cartographiés sur les référentiels applicables, généralement ISO 27001 et le NIST CSF, pour que le même effort serve plusieurs exigences.

Quelles architectures redondantes multi-sites déployons-nous ?

Des architectures où la perte d'un site ne dégrade pas le service, avec une supervision déployée avant la bascule plutôt qu'après. Le principe est simple à énoncer et coûteux à respecter : aucun composant unique ne doit pouvoir arrêter une fonction critique.

La supervision déployée en amont est un point de méthode que nous ne négocions pas. Migrer d'abord et superviser ensuite revient à réaliser la bascule en aveugle : si un flux se dégrade, personne ne le sait avant que les utilisateurs se plaignent. Nous installons donc la visibilité sur l'état initial, ce qui produit au passage la mesure de référence à laquelle comparer les résultats.

Nous avons appliqué cette méthode sur un cœur de réseau bancaire national, où un poste compromis pouvait atteindre les systèmes de paiement, et sur une supervision assistée par IA où les incidents étaient signalés par les utilisateurs avant les équipes techniques. Les deux mandats sont détaillés sur nos réalisations, avec la réserve qui s'impose : ce sont nos propres mesures, vérifiables auprès des clients concernés sous confidentialité.

Questions fréquentes