Exigences SAMA en matière de tests d'intrusion
Si la Banque centrale saoudienne vous supervise, le test d'intrusion est une obligation annuelle récurrente et non un projet. Le référentiel est précis sur deux points qui déterminent si vos preuves survivent à la revue : les tests doivent être indépendants, et le périmètre doit atteindre les systèmes que vos clients peuvent toucher.
L'exigence, énoncée simplement
Les établissements supervisés par la Banque centrale saoudienne sont tenus de réaliser des tests d'intrusion externes indépendants au minimum annuels, avec un périmètre couvrant les systèmes exposés vers l'extérieur, les applications web et l'infrastructure réseau.
Trois mots de cette phrase portent tout le poids, et chacun est un point où les preuves échouent couramment à la revue :
- Indépendants — non réalisés par l'équipe qui construit ou exploite les systèmes testés.
- Annuels, au minimum — le cycle annuel est un plancher, et un changement matériel sur les systèmes exposés sur internet est un déclencheur distinct.
- Test d'intrusion — pas un scan de vulnérabilités sous une autre couverture. Les évaluateurs sont devenus bons pour les distinguer.
Où les preuves SAMA échouent réellement
Quatre modes de défaillance expliquent l'essentiel de ce qui est contesté, et tous les quatre coûtent moins cher à éviter qu'à corriger.
Un scan présenté comme un test d'intrusion
Le signe est structurel : chaque constat est un CVE avec une description fournie par l'éditeur, rien n'est enchaîné, et aucun récit n'explique ce qu'un attaquant pourrait accomplir. Un test d'intrusion démontre l'impact : ce service exposé livre un identifiant, cet identifiant atteint ce système interne, qui contient ces données. Si votre rapport est une liste triée de versions, c'est un scan. La distinction en détail.
Une indépendance qui ne tient pas
Des tests réalisés par l'équipe d'ingénierie, par l'infogéreur qui exploite aussi l'infrastructure, ou par un éditeur évaluant son propre produit. Chacun de ces cas échoue à l'exigence d'indépendance, quelle qu'ait été la compétence des tests.
Un périmètre qui oublie la couche client
Backends de banque mobile, API partenaires, la nouvelle intégration fintech lancée après la signature du périmètre. Les systèmes exposés sur internet et les applications web sont explicitement nommés dans le référentiel : une lacune ici est donc un manquement direct et non une question d'appréciation.
Pas de retest
Un rapport comptant douze constats de gravité élevée sans aucune preuve qu'un seul ait été clos est, du point de vue d'un relecteur, la documentation d'un problème non résolu. Le cycle de remédiation et de retest est ce qui convertit un test en preuve de conformité.
Ce que couvre la mission
Le socle réglementaire, chaque année :
- Tests de réseau externe — tout le parc exposé sur internet : banque en ligne, interfaces de paiement, VPN et accès distant, infrastructure de messagerie, et les hôtes publiés pour un projet et jamais retirés.
- Tests d'applications web et d'API — authentification et gestion de session, autorisation et contrôle d'accès entre clients, logique métier dans les flux de transaction, injection, et les API derrière les applications mobiles. Dans un établissement financier, les constats de logique métier sont généralement ceux qui comptent le plus et ceux que l'automatisation ne trouve jamais.
Recommandé en complément, et inclus par la plupart des établissements sur un cycle annuel ou alterné :
- Tests de réseau interne — jusqu'où mène réellement un point d'appui, et si la segmentation entre l'environnement bureautique et l'environnement de paiement tient.
- Active Directory — abus d'ADCS, Kerberoasting, délégation et chemins d'ACL vers Domain Admin. C'est ainsi qu'un point d'appui modeste devient une compromission à l'échelle de la banque, et c'est invisible depuis l'extérieur.
- Cloud — escalade Entra ID et Azure RBAC, stockage exposé et mauvaise configuration des identités, là où les charges de travail ont migré.
- Compromission présumée — partir d'un point d'appui plutôt que du périmètre, ce qui répond à la question qu'un conseil pose réellement : jusqu'où quelqu'un pourrait-il aller ?
Lorsque vous traitez aussi des données de carte, l'exigence 11.4 de PCI DSS s'applique en parallèle et se recoupe largement — cadrées ensemble, c'est une seule mission et non deux.
Le livrable
Un rapport conçu pour la façon dont les établissements financiers le consomment réellement : une synthèse que votre conseil et votre régulateur peuvent lire sans traduction, un corps technique avec étapes de reproduction, preuves et notations CVSS pour vos ingénieurs, et un rattachement explicite de chaque constat au contrôle du référentiel concerné, pour que votre équipe conformité n'ait pas à construire ce mapping elle-même.
Puis les éléments qui transforment un rapport en preuve : un accompagnement à la remédiation pendant que vous corrigez, un retest des constats clos, et une lettre d'attestation déclarant que le test a été réalisé, par qui, sur quel périmètre et à quelles dates. Tout est inclus. Un rapport d'exemple montre le format.
Qui le réalise
Vous traitez directement avec le testeur — pas de chargé de compte, pas de junior exécutant l'outillage sous le nom d'un senior sur la facture, pas de trois semaines d'attente entre les tests et le rapport. Pour une échéance réglementaire, c'est généralement cette immédiateté qui permet de tenir la date.
Certifications, puisque la question revient systématiquement dans les achats du secteur financier : OSCP+, eCPPT, eWPT, eCIR, plus AZ-500, SC-200 et SC-300 pour la partie Microsoft et Azure — toutes vérifiables via le credential wallet OffSec. Avant de passer à plein temps à l'offensif, j'étais ingénieur détection et analyste CTI, un parcours utile dans ce secteur en particulier : le rapport vous dit non seulement comment fonctionne un chemin d'attaque, mais à quoi il aurait ressemblé dans votre SIEM, et si votre supervision l'aurait détecté.
Je travaille à distance depuis Amman en GMT+3, mêmes horaires et même semaine de travail que Riyad, en arabe ou en anglais.
Pour commencer
Indiquez-moi votre type de licence, ce qui est dans le périmètre et pour quand le test doit être terminé. Vous recevrez un devis à prix ferme et une date de démarrage. Si votre cycle annuel approche et que vous voulez d'abord voir votre exposition externe actuelle, le scan de périmètre gratuit prend quelques minutes.
Sur le même thème : les tests d'intrusion en Arabie saoudite pour la façon dont SAMA s'articule avec NCA ECC, le contrôle 2-11 de l'ECC si vous portez aussi une obligation publique, et la vue d'ensemble conformité pour tout le reste. Prenez contact — l'arabe est bienvenu.
Questions sur SAMA
Les organisations membres supervisées par la Banque centrale saoudienne : banques, compagnies d'assurance et de réassurance, sociétés de financement, bureaux de crédit et prestataires de services de paiement, y compris les fintechs opérant sous licence SAMA ou dans son bac à sable réglementaire. Si votre licence vient de la SAMA, le référentiel s'applique à vous. Les fintechs en sont fréquemment surprises : l'obligation arrive avec la licence, à un stade où le programme de sécurité est souvent encore en construction.
Des tests d'intrusion externes indépendants, au minimum annuels. Le « au minimum » travaille vraiment dans cette phrase : un changement matériel sur les systèmes exposés sur internet est généralement censé déclencher un test quel que soit le point du cycle annuel, et un établissement ayant lancé une nouvelle plateforme client six mois après son test annuel sans la tester aura une conversation difficile. Traitez le test annuel comme un plancher et le changement significatif comme un déclencheur distinct.
Que les tests ne peuvent pas être réalisés par les personnes qui construisent ou exploitent les systèmes testés. Une fonction sécurité interne rattachée séparément de l'ingénierie s'en approche, mais la réponse la plus nette et la plus communément acceptée est un tiers externe sans aucun rôle dans la construction ou l'exploitation de l'environnement. C'est l'exigence que les établissements manquent le plus souvent, et ils le découvrent à la revue plutôt qu'au cadrage — ce qui est l'ordre coûteux.
Le périmètre explicitement nommé est : systèmes exposés sur internet, applications web et infrastructure réseau. La plupart des établissements vont plus loin, et à raison : un test qui prouve qu'un attaquant peut atteindre le périmètre mais ne demande jamais ce qui se passe ensuite répond à la moitié de la question. Le schéma qui fonctionne bien est une évaluation externe et applicative complète chaque année comme socle réglementaire, en intégrant les tests de réseau interne et d'Active Directory au moins une année sur deux ou dès que le parc change matériellement.
Oui, et c'est le cas habituel. Vous disposez généralement déjà du mapping du référentiel, d'une fonction GRC et d'une relation avec l'audit interne ; ce qu'il vous faut, ce sont les tests et les preuves qui s'y insèrent. Je cadre en fonction du contrôle que vous devez satisfaire, je rattache les constats à ce contrôle dans le rapport, et je livre le retest et l'attestation dont votre équipe conformité a besoin pour son dossier. Je ne suis pas un cabinet GRC et je n'essaierai pas de vous vendre un programme de référentiel : les tests, c'est la partie que je fais.
Test SAMA annuel à échéance ?
Indépendant, cadré sur le référentiel, avec le retest et l'attestation que votre équipe conformité verse au dossier.