Tester les banques avant qu'un attaquant ne le fasse

Le contexte#

Les systèmes d'une banque sont attaqués en permanence, et un régulateur attend d'elle qu'elle sache comment ils céderaient avant que quelqu'un d'autre ne le découvre. Pendant deux ans, c'est ce que j'ai cherché chez EY, dans une équipe de cybersécurité dont les clients étaient surtout des institutions financières belges. Les missions étaient confidentielles : c'est pourquoi aucun client n'est nommé ici.

Ce que j'ai fait#

L'essentiel était le test d'intrusion : plus de vingt tests, chacun une tentative convenue de pénétrer une application ou un réseau, rendue sous forme de constats et de moyens de les corriger.

Certaines missions allaient plus loin. En red team, la cible était l'organisation entière plutôt qu'un seul système, approchée comme le ferait un vrai attaquant. En blue team, j'étais de l'autre côté, à aider les défenseurs à voir et à arrêter ce type d'attaque.

Le reste relevait de la conformité : auditer la façon dont une institution respectait les règles auxquelles elle est soumise, dont le RGPD et la DSP2, et rédiger les recommandations qui combleraient les écarts.

Ce que ça change pour un audit aujourd'hui#

Un audit d'avanserv part du côté de l'attaquant, parce que c'est là que j'ai appris à regarder. Un constat dit comment il serait exploité et ce que ça coûte de le laisser en place, pour que les corrections se classent par risque plutôt que par longueur de liste.