Règles de cyberrésilience de la NRB : évaluez votre application bancaire mobile à chaque version.

1. 01

   Lignes directrices informatiques de la NRB 2012, sécurité de l'information 2.6 et 2.7

   Évaluer la sécurité et tester les intrusions périodiquement

   Ce que dit le texte

   La sécurité de l'information n'étant pas une activité ponctuelle, les banques devraient institutionnaliser des processus pour évaluer régulièrement la santé de la sécurité de l'organisation et détecter et corriger les vulnérabilités. Il est recommandé de réaliser périodiquement des tests d'intrusion du système. Les banques devraient durcir leurs systèmes avec le niveau de sécurité le plus élevé dans les systèmes d'exploitation, les pare-feu et les logiciels système, changer immédiatement les mots de passe par défaut et installer les mises à jour et correctifs des fournisseurs. (Lignes directrices informatiques, sécurité de l'information 2.6 et 2.7)

   Source :Lignes directrices informatiques de la NRB 2012, sécurité de l'information 2.6 et 2.7

   Ce que cela implique pour votre application mobile

   L'évaluation périodique est une attente de base, pas un projet ponctuel. L'application mobile et les API qui la sous-tendent font partie de ce cycle.

   Comment Ostorlab vous aide

   Mobile SAST analyse le binaire, y compris les SDK intégrés, et Mobile DAST teste l'application en cours d'exécution ; les deux peuvent s'exécuter dans la CI/CD. Le pentest par agents IA teste l'application et ses API derrière la connexion, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA.

   Ce qui reste de votre ressort

   La fixation de la fréquence et du périmètre, les évaluations de plateforme des serveurs et équipements réseau, l'application des correctifs et le reporting.

2. 02

   Lignes directrices informatiques de la NRB 2012, sécurité de l'information 2.9 et 2.28

   Protéger ce que les appareils mobiles stockent et envoient

   Ce que dit le texte

   Les banques devraient prendre en compte la sécurité des informations pouvant être stockées sur les appareils mobiles et chiffrer les informations de transaction ainsi que le PIN ou le mot de passe transmis des appareils mobiles au système de la banque, dans le cadre des services bancaires sur appareil mobile. Des contrôles supplémentaires, comme des limites journalières et par transaction, devraient être définis pour les transferts de fonds. Les banques devraient déployer une cryptographie forte et un chiffrement de bout en bout pour protéger les codes PIN, les mots de passe et les autres données sensibles des clients dans les réseaux et en stockage. (Sécurité de l'information 2.9 et 2.28)

   Source :Lignes directrices informatiques de la NRB 2012, sécurité de l'information 2.9 et 2.28

   Ce que cela implique pour votre application mobile

   Ce que l'application écrit sur le téléphone et ce qu'elle envoie au backend sont tous deux concernés, des jetons et données personnelles aux détails de transaction.

   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, vérifie la protection du transport et teste si les limites et contrôles sont appliqués par le backend, et pas seulement par l'application.

   Ce qui reste de votre ressort

   Le choix de la cryptographie et de la gestion des clés, la fixation des limites et la politique applicable aux appareils compromis.

3. 03

   Lignes directrices informatiques de la NRB 2012, sécurité de l'information 2.27 et 2.29

   Utiliser plus d'un facteur pour les actions critiques

   Ce que dit le texte

   Les banques devraient mettre en œuvre plus d'un facteur pour authentifier les activités critiques comme les transferts de fonds via la banque en ligne, avec une méthode d'authentification adaptée au risque de la banque en ligne. Les paiements en ligne par carte devraient être authentifiés par un second facteur, avec des alertes instantanées aux clients par e-mail, SMS ou appel vocal automatisé. (Sécurité de l'information 2.27 et 2.29)

   Source :Lignes directrices informatiques de la NRB 2012, sécurité de l'information 2.27 et 2.29

   Ce que cela implique pour votre application mobile

   Le second facteur doit être imposé par le serveur à chaque opération critique, y compris lorsque l'application ou un attaquant saute une étape.

   Comment Ostorlab vous aide

   Les tests authentifiés couvrent la connexion et la déconnexion, le renouvellement des jetons, les délais d'expiration, l'invalidation des sessions et l'application effective de la MFA, y compris les parcours d'authentification renforcée, ainsi que les appels d'API qui les sous-tendent.

   Ce qui reste de votre ressort

   Le choix des méthodes d'authentification et des canaux d'alerte, et leur application dans vos systèmes bancaires centraux.

4. 04

   Lignes directrices informatiques de la NRB 2012, sécurité de l'information 2.30

   Sécuriser les applications web et leur chiffrement

   Ce que dit le texte

   Les banques devraient mettre en œuvre des mesures de sécurité adéquates pour protéger leurs applications web contre les cybermenaces et attaques traditionnelles et émergentes, et les applications critiques devraient utiliser le chiffrement SSL le plus récent. (Sécurité de l'information 2.30)

   Source :Lignes directrices informatiques de la NRB 2012, sécurité de l'information 2.30

   Ce que cela implique pour votre application mobile

   Les API que votre application appelle sont des applications web. Elles doivent être testées contre les mêmes classes d'attaques, avec un chiffrement de transport à jour.

   Comment Ostorlab vous aide

   Ostorlab intercepte le trafic de l'application, même avec TLS pinning, et teste les API à la recherche de contrôles d'autorisation défaillants (BOLA, BFLA, IDOR), d'usages abusifs des jetons et d'abus comme l'énumération et le rejeu, et détecte les erreurs de configuration qui affaiblissent la protection du transport.

   Ce qui reste de votre ressort

   La configuration TLS et les certificats, les contrôles réseau et la logique métier de l'application.

5. 05

   Lignes directrices informatiques de la NRB 2012, acquisition, développement et mise en œuvre des systèmes d'information 7.1, 7.2 et 7.4

   Intégrer la sécurité au développement et relire le code

   Ce que dit le texte

   Les exigences fonctionnelles des utilisateurs, les exigences de sécurité, les exigences de performance et les spécifications techniques devraient être documentées et approuvées par le niveau de direction approprié avant le développement du logiciel. Les exigences de sécurité de l'information devraient être intégrées à chaque étape du cycle de vie du développement logiciel, couvrant le contrôle d'accès, l'authentification, l'autorisation des transactions, la journalisation de l'activité du système, la piste d'audit et l'intégrité des données. Les banques sont encouragées à réaliser une revue du code source de l'application pour trouver les failles et les défauts, et toutes les vulnérabilités trouvées devraient être corrigées avant la mise en œuvre du système. (Lignes directrices informatiques, acquisition, développement et mise en œuvre des systèmes d'information 7.1, 7.2 et 7.4)

   Source :Lignes directrices informatiques de la NRB 2012, acquisition, développement et mise en œuvre des systèmes d'information 7.1, 7.2 et 7.4

   Ce que cela implique pour votre application mobile

   Les exigences de sécurité ont leur place dans le backlog, et une version ne devrait pas être livrée avec des défauts connus qu'une revue de code aurait détectés.

   Comment Ostorlab vous aide

   Mobile SAST fonctionne sur l'APK, l'AAB ou l'IPA avec analyse de propagation (taint) sur l'application et ses SDK intégrés, et s'exécute dans la CI/CD. Les résultats sont 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

   Les exigences de sécurité, les normes de développement sécurisé, les revues manuelles et l'approbation des mises en production.

6. 06

   Lignes directrices informatiques de la NRB 2012, gestion de l'externalisation 5.3, 5.5 et 5.10 ; lignes directrices de cyberrésilience 2023, 64

   Gérer l'externalisation et les tiers

   Ce que dit le texte

   Toutes les opérations externalisées devraient être soumises à la politique de sécurité de l'information et de confidentialité de la banque, et la banque devrait s'assurer que le prestataire met en œuvre des contrôles internes, des contrôles d'accès logique et des contrôles de sécurité physique adéquats. Les banques devraient établir un processus de suivi et de contrôle des activités externalisées. Lorsque des opérations informatiques sont externalisées à l'étranger, les banques devraient tenir compte du risque pays et clarifier la juridiction applicable à leurs données et à la réglementation au début de l'accord. Les lignes directrices de cyberrésilience demandent aux banques d'obtenir la confirmation que leurs fournisseurs et prestataires tiers, y compris les fournisseurs de TIC, satisfont à leurs exigences de cyberrésilience, avec des contrats couvrant la validation des capacités de sécurité et les risques de la chaîne d'approvisionnement. (Lignes directrices informatiques, gestion de l'externalisation 5.3, 5.5 et 5.10 ; LD cyberrésilience 64)

   Source :Lignes directrices informatiques de la NRB 2012, gestion de l'externalisation 5.3, 5.5 et 5.10 ; lignes directrices de cyberrésilience 2023, 64

   Ce que cela implique pour votre application mobile

   Les SDK intégrés à votre application sont des tiers avec leurs propres backends. Ils ont leur place dans votre vision du risque fournisseurs et dans vos décisions de juridiction des données.

   Comment Ostorlab vous aide

   Ostorlab recense les SDK et bibliothèques natives de chaque version avec leurs versions et leur emplacement dans le bundle de l'application, montre les backends avec lesquels l'application et ses SDK communiquent, et associe les composants vulnérables aux vulnérabilités connues.

   Ce qui reste de votre ressort

   Les contrats, les vérifications préalables, les décisions de juridiction des données et le suivi des fournisseurs.

7. 07

   Directives unifiées relatives aux systèmes de paiement, 2082, directive 3 (texte népalais) ; lignes directrices de cyberrésilience 2023, section IV

   Sécuriser le système de paiement électronique

   Ce que dit le texte

   Les directives unifiées relatives aux systèmes de paiement, 2082, sont les règles consolidées applicables aux institutions agréées pour exercer des activités liées aux paiements, prises en application de l'article 45 de la loi sur les paiements et le règlement, 2075 (2019). Leur directive numéro 3 couvre l'exploitation et la sécurité du système de paiement électronique, et les lignes directrices de cyberrésilience appliquent les mêmes exigences de cyberrésilience aux banques et institutions financières de classes A, B, C et D, aux opérateurs de systèmes de paiement et aux fournisseurs de services de paiement. (Directives unifiées relatives aux systèmes de paiement, 2082, directive 3, texte népalais ; LD cyberrésilience, section IV)

   Source :Directives unifiées relatives aux systèmes de paiement, 2082, directive 3 (texte népalais) ; lignes directrices de cyberrésilience 2023, section IV

   Ce que cela implique pour votre application mobile

   Une application de portefeuille ou de paiement et ses API sont le système de paiement électronique que les clients utilisent. La sécurité de cette exploitation est un sujet explicitement traité par les directives sur les paiements.

   Comment Ostorlab vous aide

   Ostorlab teste l'application de paiement et les API derrière les comptes, les paiements et les soldes, derrière la connexion, sur la version que vous livrez, et conserve les preuves version par version.

   Ce qui reste de votre ressort

   Les conditions d'agrément, les règles d'exploitation et le reporting à la NRB au titre des directives sur les systèmes de paiement.

8. 08

   Lignes directrices de cyberrésilience de la NRB 2023, 135 à 148 et 160

   Mettre en place un programme de tests complet

   Ce que dit le texte

   Les lignes directrices de cyberrésilience attendent un programme de tests complet, élaboré selon une approche fondée sur le risque, revu et mis à jour régulièrement, avec des problèmes hiérarchisés, résolus et validés, et des tests réalisés par des parties indépendantes, internes ou externes. Il devrait inclure des évaluations de vulnérabilité et des revues de code statiques et dynamiques. Les évaluations de vulnérabilité devraient être menées avant le déploiement ou le redéploiement des services qui soutiennent des fonctions critiques, et régulièrement sur les services et applications en exploitation. La recherche de vulnérabilités devrait couvrir les services exposés à l'extérieur ainsi que les systèmes et réseaux internes, en alternant entre les environnements. (LD cyberrésilience 135 à 148 et 160)

   Source :Lignes directrices de cyberrésilience de la NRB 2023, 135 à 148 et 160

   Ce que cela implique pour votre application mobile

   Une version est une modification d'un service exposé à Internet. Le programme doit la couvrir avant le déploiement et continuer à la couvrir ensuite.

   Comment Ostorlab vous aide

   Ostorlab lance des scans automatisés depuis votre pipeline CI/CD à chaque build, surveille les versions publiées sur les stores sans déclenchement manuel, et conserve les résultats par build et par version publiée. Les résultats sont classés critiques, élevés, moyens ou faibles.

   Ce qui reste de votre ressort

   Le programme lui-même, son périmètre fondé sur le risque, les systèmes et réseaux internes, et sa validation.

9. 09

   Lignes directrices de cyberrésilience de la NRB 2023, 142 et 155 à 164

   Tester les intrusions sur l'ensemble du portefeuille d'applications

   Ce que dit le texte

   Des tests d'intrusion devraient être réalisés pour identifier les vulnérabilités pouvant affecter les systèmes, réseaux, applications, personnes ou processus, en simulant de véritables attaques. Ils devraient être menés régulièrement et à chaque mise à jour majeure ou déploiement de systèmes. Les banques devraient réaliser des évaluations et des tests de sécurité à toutes les étapes du cycle de vie du développement des systèmes et à tous les niveaux, métier, application et technologie, pour l'ensemble du portefeuille d'applications, y compris les applications mobiles. Les bonnes pratiques et des outils automatisés devraient soutenir la correction des faiblesses et le respect des politiques et configurations approuvées. Les tests d'équipe rouge, fondés sur des scénarios de menace, font aussi partie du périmètre de tests des lignes directrices de cyberrésilience. (LD cyberrésilience 142 et 155 à 164)

   Source :Lignes directrices de cyberrésilience de la NRB 2023, 142 et 155 à 164

   Ce que cela implique pour votre application mobile

   Les applications mobiles sont explicitement citées dans le portefeuille, et les mises à jour majeures déclenchent des tests. Un test annuel ne suffit pas pour un canal qui évolue toutes les quelques semaines.

   Comment Ostorlab vous aide

   Le pentest par agents IA s'exécute sur la version que téléchargent vos clients, teste l'application et ses API derrière la connexion, et fournit un exploit rejouable pour chaque résultat d'un agent IA ainsi qu'une heatmap de couverture. Ostorlab ne réalise pas d'exercices d'équipe rouge.

   Ce qui reste de votre ressort

   La planification et le cadrage des tests d'intrusion et des exercices d'équipe rouge, et le traitement des résultats sur les systèmes hors application.

10. 10

    Lignes directrices de cyberrésilience de la NRB 2023, 54(d), 54(e) et 71(d)

    Exiger la MFA pour les systèmes critiques et chiffrer les données

    Ce que dit le texte

    Les lignes directrices de cyberrésilience indiquent que les systèmes, processus et rôles critiques devraient tous exiger une authentification multifacteur, lorsqu'elle est prise en charge. Elles demandent aussi des contrôles solides de protection des données et informations, notamment un chiffrement proportionné à la criticité, à la sensibilité et à l'évaluation des risques, et un chiffrement conforme aux normes et processus reconnus, couvrant l'algorithme, la longueur des clés, la génération des clés et la gestion des clés. (LD cyberrésilience 54(d), 54(e) et 71(d))

    Source :Lignes directrices de cyberrésilience de la NRB 2023, 54(d), 54(e) et 71(d)

    Ce que cela implique pour votre application mobile

    La règle de MFA ne concerne pas seulement la connexion des clients : les panneaux d'administration et les rôles de back-office qui accèdent aux données des clients sont aussi concernés. Ce que l'application stocke sur l'appareil, ce qu'elle envoie et ce que le backend conserve doivent tous être protégés de manière démontrable.

    Comment Ostorlab vous aide

    Les tests authentifiés vérifient l'application effective de la MFA et les parcours d'authentification renforcée, tandis que les analyses statiques et dynamiques recherchent les jetons et données personnelles dans le stockage, les caches, les journaux et les captures d'écran, et détectent les clés d'API et identifiants dans le package de l'application.

    Ce qui reste de votre ressort

    Le déploiement de la MFA sur les systèmes internes et clients, les choix cryptographiques, la classification des données et la gestion des clés.

Synthèse des textes publics de la NRB, vérifiés le 27 septembre 2026. Les directives sur les systèmes de paiement et les directives unifiées sont publiées en népalais et sont résumées, et non citées, sur cette page. Cette page ne constitue pas un avis juridique.