Cadre de cybersécurité et de résilience de la CBO : évaluez votre application bancaire mobile avant et après chaque version.

1. 01

   Cyber Security & Resilience Framework (CS&RF), 3.3.11, mesures de contrôle 1 à 5

   Réaliser des évaluations de vulnérabilité et des tests d'intrusion des systèmes critiques

   Ce que dit le texte

   Chaque institution agréée devrait mener périodiquement des évaluations de vulnérabilité pour identifier les vulnérabilités de sécurité de ses actifs informationnels, à une fréquence fondée sur la criticité de ces actifs. Des tests d'intrusion devraient également être réalisés, à une fréquence fondée sur la criticité des systèmes et l'exposition de l'institution au risque cyber. Pour les systèmes exposés à Internet, les tests d'intrusion devraient être menés au moins une fois par an, ou à chaque changement important ou mise à jour des systèmes. Les institutions devraient établir des processus de remédiation des vulnérabilités identifiées et valider cette remédiation pour s'assurer que les écarts sont entièrement traités, et devraient signaler les vulnérabilités identifiées au comité IT et gestion des risques. Des exercices de simulation cyber réguliers devraient aussi être menés.

   Source :Cyber Security & Resilience Framework (CS&RF), 3.3.11, mesures de contrôle 1 à 5

   Ce que cela implique pour votre application mobile

   L'application bancaire mobile et les API qui la sous-tendent sont des systèmes exposés à Internet. Le cadre attend une cadence définie, un processus de correction validé et un reporting au comité, pas un test ponctuel.

   Comment Ostorlab vous aide

   Ostorlab mène des tests d'intrusion par agents IA de l'application et de ses API derrière la connexion, sur la version que vous livrez, ainsi que Mobile SAST et DAST dans la CI/CD. Chaque résultat d'un agent IA s'accompagne d'un exploit fonctionnel à rejouer, et des retests confirment la correction.

   Ce qui reste de votre ressort

   La fixation de la fréquence, les tests des serveurs, des équipements VPN et d'autres plateformes, la conduite des exercices de simulation et le reporting au comité IT et gestion des risques.

2. 02

   Regulatory Framework for Digital Banks, décision 25/2025, 6.1(o), 6.1(s), 11.1 et 11.3

   Répondre aux attentes de sécurité du cadre des banques numériques

   Ce que dit le texte

   Les candidats et les banques numériques agréées doivent démontrer leur conformité à la loi bancaire et à la loi sur les systèmes de paiement nationaux, au cadre de cybersécurité et de résilience, aux instructions sur l'onboarding numérique et le e-KYC, au dispositif anti-blanchiment, au dispositif antifraude et aux règles sur l'externalisation et les services cloud. Leur plan d'affaires doit montrer une préparation technologique ex ante, comme une architecture zéro confiance, des certifications reconnues telles que PCI DSS, et des mesures pour identifier, protéger, détecter, répondre et se relever face aux menaces cyber. La Banque centrale peut exiger du candidat qu'il désigne un évaluateur tiers qualifié pour réaliser des évaluations de vulnérabilité et des tests d'intrusion à ses frais, à différentes étapes de ses activités.

   Source :Regulatory Framework for Digital Banks, décision 25/2025, 6.1(o), 6.1(s), 11.1 et 11.3

   Ce que cela implique pour votre application mobile

   Si vous construisez ou exploitez une banque numérique, la couche applicative et API est le point de rencontre des exigences de cybersécurité, de e-KYC et d'antifraude du cadre.

   Comment Ostorlab vous aide

   Ostorlab fournit les tests techniques côté application et API : pentests par agents IA, tests authentifiés et tests d'API, avec des preuves pour chaque résultat. Il n'est pas l'évaluateur d'agrément et ne certifie pas PCI DSS.

   Ce qui reste de votre ressort

   La demande d'agrément et le plan d'affaires, le choix de l'évaluateur, et les programmes plus larges de zéro confiance, d'antifraude et de gouvernance cloud.

3. 03

   CS&RF, 3.3.2, mesures de contrôle 1 à 4

   Sécuriser la couche applicative et ce avec quoi vous la construisez

   Ce que dit le texte

   Les configurations applicatives devraient être conformes aux politiques et procédures de sécurité de l'information applicables, et les pistes d'audit des applications critiques doivent être conservées et examinées en cas d'incident. Une analyse de risque doit être documentée pour chaque application nécessitant un accès réseau. Les institutions devraient disposer de politiques et procédures sur l'usage de code tiers et open source, et réaliser des revues de code source et des tests des applications développées en interne ou sur mesure pour détecter les vulnérabilités issues de problèmes de codage, de mauvaises pratiques ou de tentatives malveillantes.

   Source :CS&RF, 3.3.2, mesures de contrôle 1 à 4

   Ce que cela implique pour votre application mobile

   Une application bancaire mobile, c'est du code maison plus des SDK tiers. Le cadre attend que les deux soient gouvernés et testés, pas seulement le backend.

   Comment Ostorlab vous aide

   Mobile SAST fonctionne sur l'APK, l'AAB ou l'IPA sans code source, avec une analyse de propagation (taint) sur l'application et ses SDK intégrés. SCA et SBOM recensent les composants tiers et natifs de chaque version et les rapprochent des vulnérabilités connues.

   Ce qui reste de votre ressort

   Les normes de développement sécurisé, les revues de code manuelles, les bases de configuration et la politique d'usage de l'open source.

4. 04

   CS&RF, 3.5.2, mesures de contrôle 1 et 2 ; BM 1153, annexe, 6(xxi) et 6(xxii)

   Imposer la MFA et les contrôles de session pour la banque électronique

   Ce que dit le texte

   Les institutions devraient concevoir des méthodes d'authentification multifacteur comparativement fortes et fiables, et envisager de mettre en œuvre la MFA pour l'inscription, la connexion, la réinitialisation des mots de passe, l'ajout ou la modification de bénéficiaires, les transactions de montant élevé dépassant des plafonds prédéfinis, et l'ajout de services de paiement publics et de services publics. Les sessions en ligne devraient être terminées automatiquement après une période fixe, sauf ré-authentification, et des procédures de confirmation par second canal, comme le SMS ou l'e-mail, devraient être utilisées pour les transactions au-dessus de valeurs prédéfinies, l'enregistrement de bénéficiaires tiers, la modification des données de compte et la révision des plafonds de virement.

   Source :CS&RF, 3.5.2, mesures de contrôle 1 et 2 ; BM 1153, annexe, 6(xxi) et 6(xxii)

   Ce que cela implique pour votre application mobile

   La MFA doit être imposée par le serveur à chacune de ces opérations, y compris lorsque l'application saute une étape, et l'expiration des sessions et la confirmation par second canal sont des comportements que vous pouvez tester.

   Comment Ostorlab vous aide

   Les tests authentifiés couvrent la connexion et la déconnexion, les codes à usage unique, les parcours d'authentification renforcée, le renouvellement des jetons, les délais d'expiration et l'invalidation des sessions, ainsi que les appels d'API derrière les inscriptions et les modifications de bénéficiaires.

   Ce qui reste de votre ressort

   Le choix et le déploiement des méthodes MFA et du second canal, et la communication aux clients.

5. 05

   CS&RF, 3.5.2, mesures de contrôle 8 et 12 ; BM 1153, annexe, 6(xxv) et 6(xxxi)(f)

   Garder la banque mobile sur les canaux officiels, avec des débits à deux facteurs

   Ce que dit le texte

   Les institutions devraient rendre la banque en ligne et mobile disponible uniquement via les stores d'applications officiels ou d'autres canaux de distribution sécurisés, et mettre en place une protection de marque pour leurs services en ligne, y compris les réseaux sociaux, avec une mesure de détection permettant de faire retirer les sites et applications malveillants. Les services de banque mobile devraient prévoir des mesures d'atténuation appropriées, comme des plafonds de transaction, des limites de vélocité et des contrôles antifraude et anti-blanchiment. Toutes les transactions de banque mobile débitant le compte ne devraient être autorisées que via une authentification à deux facteurs, et une sécurité appropriée doit être assurée à toutes les étapes du traitement. Lorsque des tiers sont associés aux activités de banque électronique, les institutions devraient les lier par des clauses de responsabilité sur les menaces de sécurité émanant de leurs systèmes.

   Source :CS&RF, 3.5.2, mesures de contrôle 8 et 12 ; BM 1153, annexe, 6(xxv) et 6(xxxi)(f)

   Ce que cela implique pour votre application mobile

   La version publiée sur le store est votre canal client. Les clones et les builds altérés, les débits qui contournent le second facteur et les plafonds qui n'existent que dans l'interface sont autant de points que le cadre attend que vous maîtrisiez.

   Comment Ostorlab vous aide

   Ostorlab scanne la version publiée sur le store à chaque release et teste à l'exécution la détection du root et du jailbreak, l'anti-altération et le TLS pinning, pour voir quelles protections ont tenu et lesquelles ont été contournées. Il teste aussi si les contrôles à deux facteurs et les plafonds tiennent côté serveur.

   Ce qui reste de votre ressort

   La surveillance des stores et le processus de retrait des clones, les plafonds de transaction et de vélocité eux-mêmes, et les clauses de responsabilité des fournisseurs.

6. 06

   CS&RF, 3.3.8, mesures de gestion des correctifs ; BM 1153, annexe, 6(xx)

   Corriger à temps et suivre les composants

   Ce que dit le texte

   Les institutions devraient maintenir à jour et corriger les systèmes d'exploitation, les équipements réseau et d'infrastructure, les logiciels de sécurité et les ordinateurs d'accès à distance conformément à une politique de gestion des correctifs, après une évaluation des risques. Elles devraient surveiller en continu les correctifs publiés par les fournisseurs et s'assurer que les correctifs critiques sont testés en environnement de test avant la production ; si un correctif casse une application critique, elles devraient mettre en place d'autres mesures d'atténuation qui bloquent l'exploitation. Lorsque des applications sont achetées à des fournisseurs, les institutions devraient obtenir des déclarations d'intégrité écrites attestant que l'application est exempte de malware, de bugs et de canaux cachés, et une analyse de risque et une évaluation de vulnérabilité de l'application et du réseau devraient avoir lieu au moins une fois par an.

   Source :CS&RF, 3.3.8, mesures de gestion des correctifs ; BM 1153, annexe, 6(xx)

   Ce que cela implique pour votre application mobile

   Chaque bibliothèque, SDK et composant natif de l'application est un logiciel que vous livrez. Chacun a besoin d'une version connue, d'une gravité lorsqu'un problème apparaît et d'un délai de correction dont vous pouvez apporter la preuve.

   Comment Ostorlab vous aide

   SCA identifie les bibliothèques compilées statiquement et les rapproche des vulnérabilités connues, version après version. Les résultats sont classés critiques, élevés, moyens ou faibles, suivis sous forme de tickets dans la plateforme ou dans Jira et ServiceNow, et retestés une fois le correctif publié.

   Ce qui reste de votre ressort

   L'application des correctifs sur les serveurs et l'infrastructure, les contrats de maintenance des fournisseurs, les mesures compensatoires et les décisions d'acceptation des risques.

7. 07

   CS&RF, 3.3.5 et 3.5.1(7) ; loi sur la protection des données personnelles (décret royal 6/2022), articles 13, 14, 15 et 19, tels que modifiés par le décret royal 68/2026

   Protéger les données personnelles sur l'appareil et en transit

   Ce que dit le texte

   Les institutions devraient mettre en œuvre des solutions de prévention des fuites de données au niveau des postes, des périphériques et du réseau, et un chiffrement de bout en bout au repos et en transit pour protéger les informations sensibles comme les identifiants de connexion et les données de carte. En vertu de la loi sur la protection des données personnelles, le responsable du traitement et le sous-traitant doivent mettre en place les contrôles et procédures de traitement, y compris les risques auxquels la personne concernée est exposée et les mesures techniques garantissant l'application de la loi ; en cas de traitement automatisé, ils doivent protéger la vie privée et la confidentialité ; ils doivent effacer les données personnelles lorsque la finalité du traitement prend fin ; et ils doivent notifier au ministère et à la personne concernée toute violation de données personnelles. Les transferts de données personnelles hors d'Oman suivent les contrôles du règlement d'application.

   Source :CS&RF, 3.3.5 et 3.5.1(7) ; loi sur la protection des données personnelles (décret royal 6/2022), articles 13, 14, 15 et 19, tels que modifiés par le décret royal 68/2026

   Ce que cela implique pour votre application mobile

   Les mots de passe, jetons et données de carte ne devraient jamais être stockés en clair sur le téléphone ni transiter sans protection vers le backend, et les données personnelles collectées par l'application relèvent de la loi sur la protection des données.

   Comment Ostorlab vous aide

   Ostorlab recherche les jetons de session et les données personnelles dans le stockage local, les caches, les journaux et les captures d'écran, et détecte les erreurs de configuration qui affaiblissent la protection du transport et des sessions.

   Ce qui reste de votre ressort

   La classification des données, les mentions de consentement, les missions du délégué à la protection des données, la notification des violations au ministère et aux personnes concernées, et les évaluations de transfert.

8. 08

   CS&RF, 3.3.10, mesures de contrôle 1 à 4

   Verrouiller les accès et les identifiants

   Ce que dit le texte

   Les institutions devraient définir, approuver et surveiller une politique de gestion des accès, en appliquant la séparation des tâches, le besoin d'en connaître et le moindre privilège lors de l'attribution d'accès au personnel, aux contractants et aux fournisseurs tiers. Les traces des activités d'accès des utilisateurs devraient être journalisées et identifiées de manière unique à des fins d'audit et d'investigation, et des mécanismes d'authentification supplémentaires, comme l'authentification multifacteur, devraient être utilisés pour l'accès à distance et les accès privilégiés aux systèmes qui soutiennent des fonctions essentielles, sur la base d'une évaluation des risques.

   Source :CS&RF, 3.3.10, mesures de contrôle 1 à 4

   Ce que cela implique pour votre application mobile

   Les clés d'API, jetons et autres identifiants laissés dans le package de l'application sont un accès que quiconque télécharge l'application peut extraire ; l'autorisation entre l'application, le backend et les services externes doit tenir à chaque frontière.

   Comment Ostorlab vous aide

   Ostorlab détecte les clés d'API, jetons et identifiants dans le package de l'application et vérifie s'ils sont fonctionnels, et teste les API à la recherche de contrôles d'autorisation défaillants (BOLA, BFLA, IDOR) et d'usages abusifs des jetons et des sessions.

   Ce qui reste de votre ressort

   La gestion des comptes à privilèges, les revues d'accès, les processus d'entrée et de départ et le contrôle des accès des tiers.

9. 09

   CS&RF, 3.5.2, mesure de contrôle 14 (a) à (e)

   Tester la sécurité du e-KYC et de l'onboarding

   Ce que dit le texte

   Pour le e-KYC, qui permet aux institutions d'intégrer numériquement de nouveaux clients et de mettre à jour leurs données de connaissance client par voie électronique, les institutions devraient réaliser des évaluations de cybersécurité avant le lancement de la solution de e-KYC et évaluer périodiquement l'efficacité de la technologie face aux risques de menace cyber et de fraude. Le processus d'identification et de vérification devrait adopter une combinaison appropriée d'authentification multifacteur, l'application doit utiliser un chiffrement de bout en bout sécurisé en temps réel, et l'empreinte numérique et les journaux collectés pendant l'identification et la vérification devraient être conservés, y compris les données complémentaires telles que les adresses IP. Les enregistrements vidéo devraient être stockés en lieu sûr, avec les horodatages maintenus.

   Source :CS&RF, 3.5.2, mesure de contrôle 14 (a) à (e)

   Ce que cela implique pour votre application mobile

   L'onboarding passe par l'application mobile avant même qu'un compte existe. Le chiffrement, la combinaison MFA et la piste de preuve font partie du parcours application et API que vous pouvez tester.

   Comment Ostorlab vous aide

   Ostorlab parcourt les flux d'onboarding et de e-KYC avec vos comptes de test et vos documents d'identité et teste les appels d'API qui les sous-tendent, y compris l'application effective de la MFA, la gestion des sessions et la protection du transport.

   Ce qui reste de votre ressort

   Le produit de vérification d'identité, les contrôles de vivacité et de documents, le stockage vidéo et la politique de conservation des données d'onboarding.

Synthèse des textes publics de la CBO et de la loi sur la protection des données personnelles, vérifiés le 27 septembre 2026. Le cadre de cybersécurité et de résilience est annexé à la circulaire BM 1194, et les résumés de clauses suivent le texte du cadre. Cette page ne constitue pas un avis juridique.