FFIEC et NYDFS : testez votre application bancaire mobile avant chaque lancement et chaque changement.

1. 01

   FFIEC Information Security booklet, II.C.17

   Tester les applications exposées à l'extérieur avant leur lancement et avant tout changement significatif

   Ce que dit le texte

   Les applications utilisées par les institutions et leurs clients comprennent des applications installables comme les applications mobiles téléchargeables. Pour vérifier les contrôles, la direction devrait réaliser des tests appropriés, comme des tests d'intrusion, des évaluations de vulnérabilité et des tests de sécurité applicative, avant le lancement ou toute modification significative des applications exposées à l'extérieur. Les problèmes relevés par les tests devraient être corrigés avant le lancement ou avant le passage des changements en production, et les tiers qui développent des applications devraient respecter les mêmes contrôles.

   Source :FFIEC Information Security booklet, II.C.17

   Ce que cela implique pour votre application mobile

   Une nouvelle version de votre application mobile est une modification d'une application exposée à l'extérieur. Les tests ont leur place dans le processus de mise en production, et les résultats devraient être corrigés avant que le build n'arrive sur le store, y compris pour les applications développées par des prestataires.

   Comment Ostorlab vous aide

   Mobile SAST analyse directement l'APK, l'AAB ou l'IPA, sans besoin du code source, y compris par une analyse de propagation (taint) à travers les SDK intégrés. Mobile DAST exécute l'application, maintient les sessions authentifiées et capture le trafic, les traces d'appels et les captures d'écran. SCA identifie par empreinte les bibliothèques compilées statiquement que les scanners basés sur les manifestes peuvent manquer.

   Ce qui reste de votre ressort

   La décision de mise en service, les tests de l'infrastructure serveur et les exigences de sécurité que vous fixez aux prestataires.

2. 02

   FFIEC Information Security booklet, IV.A.1 et IV.A.2(b)

   Fixer la fréquence et l'indépendance des tests selon les risques

   Ce que dit le texte

   Le processus de gestion des risques informatiques de l'institution devrait déterminer la fréquence des tests indépendants. Les modifications ou ajouts de systèmes et d'applications et l'évolution des techniques des attaquants peuvent l'accroître, avec des tests pendant le développement, avant qu'un système nouveau ou modifié ne passe en production, et périodiquement en production. Il existe de nombreux types de tests d'intrusion, dont les tests côté client et les tests d'applications web, et la direction devrait déterminer le niveau d'indépendance requis.

   Source :FFIEC Information Security booklet, IV.A.1 et IV.A.2(b)

   Ce que cela implique pour votre application mobile

   Il n'existe pas de fréquence fédérale fixe. Des versions fréquentes justifient des tests plus fréquents, et une application bancaire mobile exige à la fois des tests côté client et des tests de type application web des API qu'elle appelle.

   Comment Ostorlab vous aide

   Les scans rapides se terminent généralement en 1 à 5 minutes et les scans complets en 15 à 45 minutes : ils s'intègrent donc à chaque version. Un pentest par agents IA va plus loin, généralement en quelques heures, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA, pour les changements critiques et vos tests approfondis périodiques.

   Ce qui reste de votre ressort

   L'évaluation des risques qui fixe la fréquence et le périmètre, et la décision sur qui est considéré comme indépendant.

3. 03

   Interagency Guidelines Establishing Information Security Standards, III.C

   Tester régulièrement les contrôles clés

   Ce que dit le texte

   Chaque institution doit tester régulièrement les contrôles, systèmes et procédures clés de son programme de sécurité de l'information. La fréquence et la nature des tests devraient être déterminées par l'évaluation des risques de l'institution, et les tests devraient être réalisés ou revus par des tiers indépendants ou par du personnel indépendant de celui qui développe ou maintient les programmes de sécurité. Les contrôles d'accès aux systèmes d'information clients, y compris l'authentification, font partie des mesures à envisager.

   Source :Interagency Guidelines Establishing Information Security Standards, III.C

   Ce que cela implique pour votre application mobile

   La connexion, les autorisations et la protection des données dans l'application et ses API sont des contrôles clés des systèmes d'information clients : ils ont donc leur place dans le plan de test, avec des résultats revus par une personne extérieure à l'équipe qui les développe.

   Comment Ostorlab vous aide

   Votre équipe sécurité ou de deuxième ligne exécute les tests et détient les résultats. Chaque résultat s'accompagne d'un niveau de risque, d'étapes de reproduction, des journaux de requêtes et de réponses et de captures d'écran, et le retest confirme si le problème sous-jacent est résolu.

   Ce qui reste de votre ressort

   Le programme écrit de sécurité de l'information, l'évaluation des risques et le rapport annuel au conseil d'administration.

4. 04

   FFIEC Development, Acquisition, and Maintenance booklet, IV.D et V.C.2

   Intégrer les tests de sécurité au développement

   Ce que dit le texte

   Les tests d'assurance qualité comme le fuzzing et les tests d'intrusion, les revues de code sécurisé et les analyseurs de sécurité du code source aident à identifier les failles de sécurité à corriger. Le scan de vulnérabilités dans les environnements de développement détecte les vulnérabilités avant que les utilisateurs n'y soient exposés, et le scan se poursuit après le déploiement. En DevSecOps, les pipelines CI/CD utilisent des outils de test comme les tests statiques et dynamiques de sécurité applicative et l'analyse de la composition logicielle, et interrompent les tâches suivantes du pipeline en cas d'échec d'un build ou d'un test.

   Source :FFIEC Development, Acquisition, and Maintenance booklet, IV.D et V.C.2

   Ce que cela implique pour votre application mobile

   Des tests de sécurité automatisés dans le pipeline, avec des builds qui échouent sur les résultats graves : c'est ce que les examinateurs chercheront, et cela s'applique à l'application mobile autant qu'au code serveur.

   Comment Ostorlab vous aide

   Lancez des scans automatisés depuis votre pipeline CI/CD à chaque build et surveillez les versions publiées sur les stores sans déclenchement manuel. Des exécutions planifiées de votre pipeline maintiennent une fréquence hebdomadaire entre deux versions. Les résultats reçoivent un niveau critique, élevé, moyen ou faible, sont suivis sous forme de tickets dans la plateforme ou dans Jira et ServiceNow, et sont retestés une fois le correctif livré.

   Ce qui reste de votre ressort

   La conception du pipeline, les règles d'échec d'un build et les revues de votre code côté serveur.

5. 05

   FFIEC Development, Acquisition, and Maintenance booklet, IV.I.2 ; Architecture, Infrastructure, and Operations booklet, V.C.2(c)

   Atténuer les risques courants des API

   Ce que dit le texte

   Les stratégies d'atténuation des risques courants des API comprennent les contrôles d'autorisation au niveau des objets, la validation de l'authentification des utilisateurs et l'examen de la MFA, l'absence d'exposition excessive de données dans les réponses, la limitation du débit, l'autorisation au niveau des fonctions avec refus d'accès par défaut, la protection contre l'assignation de masse et les injections, et un inventaire à jour des API. Les API publiques devraient être testées pour vérifier l'adéquation des contrôles de sécurité avant et après leur ouverture au public.

   Source :FFIEC Development, Acquisition, and Maintenance booklet, IV.I.2 ; Architecture, Infrastructure, and Operations booklet, V.C.2(c)

   Ce que cela implique pour votre application mobile

   Les API derrière votre application font circuler l'argent et les données. Un client qui modifie un identifiant de compte dans une requête devrait recevoir une erreur, et non le solde d'un autre.

   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 des sessions, et d'abus comme l'énumération, le rejeu et l'automatisation, avec les requêtes et réponses à l'appui de chaque résultat.

   Ce qui reste de votre ressort

   L'inventaire des API, la configuration de la passerelle et du pare-feu, et la journalisation et la surveillance de l'activité des API.

6. 06

   FFIEC Authentication and Access guidance (2021), sections 3 à 5 ; Information Security booklet, II.C.16 ; 23 NYCRR 500.12

   Sécurité multicouche et MFA pour la banque numérique

   Ce que dit le texte

   Lorsqu'une évaluation des risques montre que l'authentification à facteur unique avec une sécurité multicouche est insuffisante, la MFA ou des contrôles de force équivalente, associés à d'autres contrôles multicouches, peuvent atténuer le risque plus efficacement. Les contrôles multicouches comprennent la MFA, l'expiration des sessions utilisateur et les plafonds de transaction, et la conception et l'efficacité des contrôles d'authentification devraient être évaluées initialement puis périodiquement. Pour la banque à distance, les contrôles peuvent inclure des délais d'expiration de l'application avec nouvelle authentification obligatoire, une vérification hors bande et l'authentification de l'appareil. À New York, la section 500.12 impose la MFA pour toute personne accédant à l'un des systèmes d'information d'une entité couverte.

   Source :FFIEC Authentication and Access guidance (2021), sections 3 à 5 ; Information Security booklet, II.C.16 ; 23 NYCRR 500.12

   Ce que cela implique pour votre application mobile

   Les paiements et les modifications de compte sont des transactions à haut risque. Le serveur devrait imposer le second facteur, l'authentification renforcée et l'expiration, et vous devez pouvoir prouver qu'il le fait. La manière dont la section 500.12 s'applique aux connexions des clients est une question pour votre équipe conformité.

   Comment Ostorlab vous aide

   Ostorlab se connecte avec vos comptes de test, saisit les codes à usage unique reçus par SMS, e-mail ou TOTP, et teste 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.

   Ce qui reste de votre ressort

   L'évaluation des risques liés à l'authentification, le choix des facteurs, la surveillance de la fraude et la sensibilisation des clients.

7. 07

   23 NYCRR 500.5 ; FFIEC Architecture, Infrastructure, and Operations booklet, VI.B.3(a)

   Réaliser un test d'intrusion annuel et des scans selon les risques

   Ce que dit le texte

   Les entités couvertes doivent disposer de procédures écrites de gestion des vulnérabilités garantissant, au minimum, des tests d'intrusion de leurs systèmes d'information depuis l'intérieur et l'extérieur du périmètre par une partie interne ou externe qualifiée au moins une fois par an, et des scans automatisés, avec une revue manuelle des systèmes que les scans ne couvrent pas, à une fréquence déterminée par l'évaluation des risques et rapidement après tout changement important des systèmes. Les vulnérabilités doivent être corrigées en temps utile, par ordre de priorité selon le risque. La FFIEC attend une méthode de suivi et de reporting de l'avancement de la remédiation de toutes les vulnérabilités identifiées.

   Source :23 NYCRR 500.5 ; FFIEC Architecture, Infrastructure, and Operations booklet, VI.B.3(a)

   Ce que cela implique pour votre application mobile

   Une version de l'application mobile constitue souvent un changement important des systèmes auxquels accèdent les clients. Le pentest annuel couvre l'application et ses API depuis l'extérieur, et les scans automatisés comblent l'intervalle entre les tests.

   Comment Ostorlab vous aide

   Des scans automatisés depuis votre pipeline CI/CD à chaque build, y compris par exécutions planifiées, et une surveillance des versions publiées sur les stores. Le pentest par agents IA teste l'application et ses API derrière la connexion, et les résultats confirmés sont suivis sous forme de tickets et retestés après correction.

   Ce qui reste de votre ressort

   Le choix d'une partie qualifiée pour le pentest annuel, les tests internes à l'intérieur du périmètre et vos délais de remédiation.

8. 08

   23 NYCRR 500.8

   Développement sécurisé et tests des applications externes

   Ce que dit le texte

   Le programme de cybersécurité doit inclure des procédures, lignes directrices et normes écrites de développement sécurisé pour les applications développées en interne, et des procédures d'évaluation ou de test de la sécurité des applications développées à l'extérieur et utilisées par l'entité couverte. Le CISO, ou une personne qualifiée qu'il désigne, les revoit et les met à jour au moins une fois par an.

   Source :23 NYCRR 500.8

   Ce que cela implique pour votre application mobile

   Votre propre application comme les SDK ou applications en marque blanche que vous achetez ont besoin d'une étape définie de tests de sécurité, et la procédure doit être revue chaque année.

   Comment Ostorlab vous aide

   Mobile SAST fonctionne sur l'application compilée : il couvre donc les applications développées par des prestataires et les SDK intégrés dont vous n'avez pas les sources. SCA montre quels composants tiers chaque version embarque, les rapproche des vulnérabilités connues et suit leur résolution version après version.

   Ce qui reste de votre ressort

   Les procédures écrites et la revue annuelle par le CISO.

9. 09

   Interagency Guidance on Third-Party Relationships (2023) ; FFIEC Information Security booklet, II.C.20 ; 23 NYCRR 500.11

   Superviser les tiers, y compris les prestataires de tests

   Ce que dit le texte

   Le recours à des tiers ne diminue ni ne supprime la responsabilité d'une organisation bancaire d'exercer ses activités de manière sûre et saine et conformément aux lois applicables. Les vérifications préalables en matière de sécurité de l'information peuvent inclure l'évaluation du programme de sécurité applicative du tiers, de son cycle de vie de développement logiciel et des résultats de ses évaluations de vulnérabilité et tests d'intrusion, ainsi que de contrôles comme l'authentification multifacteur et le chiffrement. Les entités couvertes à New York doivent disposer de politiques de sécurité relatives aux prestataires de services tiers, y compris des vérifications préalables et des protections contractuelles.

   Source :Interagency Guidance on Third-Party Relationships (2023) ; FFIEC Information Security booklet, II.C.20 ; 23 NYCRR 500.11

   Ce que cela implique pour votre application mobile

   Les prestataires qui développent votre application ou en exploitent une partie devraient vous montrer leurs résultats de tests. Une plateforme de test SaaS qui reçoit les binaires de votre application et vos identifiants de test est elle-même un prestataire que votre processus examinera.

   Comment Ostorlab vous aide

   Ostorlab a fait l'objet d'un audit SOC 2 Type II. Avec l'offre Enterprise, vous pouvez choisir la résidence des données aux États-Unis ou lancer les scans on-premises, et avec BYOK, l'IA s'exécute sur votre propre compte auprès de votre fournisseur, avec un plafond de dépense par scan. SSO/SAML, le contrôle d'accès basé sur les rôles et les journaux d'audit sont disponibles en option et inclus dans l'offre Enterprise.

   Ce qui reste de votre ressort

   Vos vérifications préalables, les clauses contractuelles et le suivi continu de chaque prestataire.

Synthèse du FFIEC IT Examination Handbook, des recommandations de la FFIEC sur l'authentification, des Interagency Guidelines Establishing Information Security Standards, des recommandations de 2023 sur les tiers et du 23 NYCRR Part 500, vérifiés le 27 septembre 2026. Les booklets de la FFIEC et les recommandations interagences sont des orientations de supervision ; la Part 500 s'applique aux entités régulées par le NYDFS. Cette page ne constitue pas un avis juridique.