FFIEC y NYDFS: pruebe su app de banca móvil antes de cada lanzamiento y cada cambio.

1. 01

   FFIEC Information Security booklet, II.C.17

   Pruebe las apps expuestas al exterior antes de su lanzamiento y de los cambios significativos

   Qué dice el texto

   Entre las aplicaciones que utilizan las instituciones y sus clientes figuran las aplicaciones instalables, como las aplicaciones móviles descargables. Para verificar los controles, la dirección debería realizar pruebas adecuadas, como pruebas de penetración, evaluaciones de vulnerabilidades y pruebas de seguridad de las aplicaciones, antes de lanzar aplicaciones expuestas al exterior o de introducir en ellas cambios significativos. Los problemas detectados en las pruebas deberían corregirse antes del lanzamiento o antes de que los cambios pasen a producción, y los terceros que desarrollan aplicaciones deberían cumplir los mismos controles.

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

   Qué supone para su app móvil

   Una nueva versión de su app móvil es un cambio en una aplicación expuesta al exterior. Las pruebas forman parte del proceso de publicación, y los hallazgos deberían corregirse antes de que la compilación llegue a la tienda, también en las apps desarrolladas por proveedores.

   Cómo ayuda Ostorlab

   Mobile SAST analiza directamente el APK, AAB o IPA, sin necesidad de código fuente, incluido el análisis de propagación (taint) en los SDK integrados. Mobile DAST ejecuta la app, mantiene las sesiones autenticadas y captura el tráfico, las trazas de pila y capturas de pantalla. SCA identifica mediante huellas las bibliotecas compiladas estáticamente que los escáneres basados en manifiestos pueden pasar por alto.

   Qué sigue en sus manos

   La decisión de puesta en producción, las pruebas de la infraestructura de servidores y los requisitos de seguridad que fija a los proveedores.

2. 02

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

   Fije la frecuencia y la independencia de las pruebas en función del riesgo

   Qué dice el texto

   El proceso de gestión del riesgo de TI de la institución debería determinar la frecuencia de las pruebas independientes. Los cambios o las incorporaciones de sistemas y aplicaciones y los cambios en las técnicas de los atacantes pueden aumentarla, con pruebas durante el desarrollo, antes de que un sistema nuevo o modificado pase a producción y periódicamente en producción. Existen muchos tipos de pruebas de penetración, entre ellas las pruebas del lado del cliente y de aplicaciones web, y la dirección debería determinar el nivel de independencia necesario.

   Fuente:FFIEC Information Security booklet, IV.A.1 y IV.A.2(b)

   Qué supone para su app móvil

   No existe una cadencia federal fija. Las versiones frecuentes son un motivo para probar más a menudo, y una app de banca móvil necesita tanto pruebas del lado del cliente como pruebas de tipo aplicación web de las API a las que llama.

   Cómo ayuda Ostorlab

   Los escaneos rápidos suelen terminar en 1 a 5 minutos y los completos en 15 a 45 minutos, por lo que encajan en cada versión. Un pentest con agentes de IA profundiza más, normalmente en unas horas, con un exploit funcional que puede reproducir para cada hallazgo de un agente de IA, para los cambios críticos y sus pruebas en profundidad periódicas.

   Qué sigue en sus manos

   La evaluación de riesgos que fija la frecuencia y el alcance, y la decisión sobre quién se considera independiente.

3. 03

   Interagency Guidelines Establishing Information Security Standards, III.C

   Pruebe periódicamente los controles clave

   Qué dice el texto

   Cada institución debe probar periódicamente los controles, sistemas y procedimientos clave de su programa de seguridad de la información. La frecuencia y la naturaleza de las pruebas deberían determinarse mediante la evaluación de riesgos de la institución, y las pruebas deberían realizarlas o revisarlas terceros independientes o personal independiente de quienes desarrollan o mantienen los programas de seguridad. Los controles de acceso a los sistemas de información de los clientes, incluida la autenticación, figuran entre las medidas que deben considerarse.

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

   Qué supone para su app móvil

   El inicio de sesión, la autorización y la protección de los datos en la app y sus API son controles clave de los sistemas de información de los clientes, por lo que forman parte del plan de pruebas, con resultados revisados por alguien ajeno al equipo que los desarrolla.

   Cómo ayuda Ostorlab

   Su equipo de seguridad o de segunda línea ejecuta las pruebas y es el titular de los resultados. Cada hallazgo incluye una calificación de riesgo, los pasos de reproducción, los registros de solicitudes y respuestas y capturas de pantalla, y una nueva prueba confirma si el problema de fondo está resuelto.

   Qué sigue en sus manos

   El programa escrito de seguridad de la información, la evaluación de riesgos y el informe anual al consejo.

4. 04

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

   Integre las pruebas de seguridad en el desarrollo

   Qué dice el texto

   Las pruebas de control de calidad, como el fuzzing y las pruebas de penetración, las revisiones de código seguro y los analizadores de seguridad del código fuente ayudan a identificar fallos de seguridad para su corrección. El escaneo de vulnerabilidades en los entornos de desarrollo detecta vulnerabilidades antes de que los usuarios queden expuestos, y el escaneo continúa tras el despliegue. En DevSecOps, los pipelines de CI/CD utilizan herramientas de prueba como las pruebas estáticas y dinámicas de seguridad de las aplicaciones y el análisis de composición del software, y detienen las tareas posteriores del pipeline cuando falla una compilación o una prueba.

   Fuente:FFIEC Development, Acquisition, and Maintenance booklet, IV.D y V.C.2

   Qué supone para su app móvil

   Las pruebas de seguridad automatizadas en el pipeline, con compilaciones que fallan ante hallazgos graves, son lo que buscarán los examinadores, y se aplican a la app móvil tanto como al código del servidor.

   Cómo ayuda Ostorlab

   Ejecute escaneos automatizados desde su pipeline de CI/CD en cada compilación y supervise las versiones publicadas en las tiendas sin activación manual. Las ejecuciones programadas de su pipeline mantienen una periodicidad semanal entre versiones. Los hallazgos se califican como críticos, altos, medios o bajos, se registran como tickets en la plataforma o en Jira y ServiceNow, y se vuelven a probar una vez publicada la corrección.

   Qué sigue en sus manos

   El diseño del pipeline, las reglas para hacer fallar una compilación y las revisiones del código del lado del servidor.

5. 05

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

   Mitigue los riesgos habituales de las API

   Qué dice el texto

   Las estrategias de mitigación de los riesgos habituales de las API incluyen los controles de autorización a nivel de objeto, la validación de la autenticación de los usuarios y la consideración de la MFA, evitar la exposición excesiva de datos en las respuestas, la limitación de la tasa de solicitudes, la autorización a nivel de función con acceso denegado por defecto, la protección frente a la asignación masiva y la inyección, y un inventario actualizado de las API. Las API públicas deberían probarse para verificar la adecuación de los controles de seguridad antes y después de hacerse públicas.

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

   Qué supone para su app móvil

   Las API que hay detrás de su app mueven el dinero y los datos. Un cliente que cambia un ID de cuenta en una solicitud debería recibir un error, no el saldo de otra persona.

   Cómo ayuda Ostorlab

   Ostorlab intercepta el tráfico de la app, incluso con TLS pinning, y prueba las API en busca de fallos de autorización (BOLA, BFLA, IDOR), usos indebidos de tokens y sesiones, y abusos como la enumeración, la repetición y la automatización, con evidencia de solicitudes y respuestas para cada hallazgo.

   Qué sigue en sus manos

   El inventario de las API, la configuración de la pasarela y del firewall, y el registro y la supervisión de la actividad de las API.

6. 06

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

   Seguridad por capas y MFA para la banca digital

   Qué dice el texto

   Cuando una evaluación de riesgos muestra que la autenticación de un solo factor con seguridad por capas es inadecuada, la MFA o controles de solidez equivalente, junto con otros controles por capas, pueden mitigar el riesgo con mayor eficacia. Los controles por capas incluyen la MFA, el tiempo de espera de la sesión del usuario y los límites de las transacciones, y el diseño y la eficacia de los controles de autenticación deberían evaluarse inicialmente y de forma periódica. En la banca a distancia, los controles pueden incluir tiempos de espera de la aplicación con nueva autenticación obligatoria, verificación fuera de banda y autenticación del dispositivo. En Nueva York, la sección 500.12 exige MFA para cualquier persona que acceda a cualquiera de los sistemas de información de una entidad cubierta.

   Fuente:FFIEC Authentication and Access guidance (2021), secciones 3 a 5; Information Security booklet, II.C.16; 23 NYCRR 500.12

   Qué supone para su app móvil

   Los pagos y los cambios en la cuenta son transacciones de alto riesgo. El servidor debería exigir el segundo factor, la autenticación reforzada y el tiempo de espera, y usted necesita evidencia de que lo hace. Cómo se aplica la sección 500.12 a los inicios de sesión de los clientes es una cuestión para su equipo de cumplimiento.

   Cómo ayuda Ostorlab

   Ostorlab inicia sesión con sus cuentas de prueba, completa los códigos de un solo uso por SMS, correo electrónico o TOTP, y prueba el inicio y el cierre de sesión, la renovación de tokens, los tiempos de espera, la invalidación de sesiones y la aplicación de la MFA, incluidos los flujos de autenticación reforzada.

   Qué sigue en sus manos

   La evaluación de riesgos de la autenticación, la elección de los factores, la monitorización del fraude y la concienciación de los clientes.

7. 07

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

   Realice pruebas de penetración anuales y escaneos según el riesgo

   Qué dice el texto

   Las entidades cubiertas deben disponer de procedimientos escritos de gestión de vulnerabilidades que garanticen, como mínimo, pruebas de penetración de sus sistemas de información desde dentro y desde fuera de sus límites, realizadas por una parte interna o externa cualificada al menos una vez al año, y escaneos automatizados, con revisión manual de los sistemas que los escaneos no cubren, con una frecuencia determinada por la evaluación de riesgos y sin demora tras cualquier cambio importante en los sistemas. Las vulnerabilidades deben corregirse de forma oportuna, priorizadas según el riesgo. El FFIEC espera un método para hacer el seguimiento de la corrección de todas las vulnerabilidades identificadas e informar sobre su avance.

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

   Qué supone para su app móvil

   Una nueva versión de la app móvil suele ser un cambio importante en los sistemas a los que acceden los clientes. El pentest anual cubre la app y sus API desde el exterior, y los escaneos automatizados cubren el intervalo entre pruebas.

   Cómo ayuda Ostorlab

   Escaneos automatizados desde su pipeline de CI/CD en cada compilación, incluidas ejecuciones programadas, y supervisión de las versiones publicadas en las tiendas. El pentest con agentes de IA prueba la app y sus API detrás del inicio de sesión, y los hallazgos confirmados se gestionan como tickets y se vuelven a probar tras la corrección.

   Qué sigue en sus manos

   La elección de una parte cualificada para el pentest anual, las pruebas internas dentro de los límites y sus plazos de corrección.

8. 08

   23 NYCRR 500.8

   Desarrollo seguro y pruebas de las apps externas

   Qué dice el texto

   El programa de ciberseguridad debe incluir procedimientos, directrices y normas escritos sobre prácticas de desarrollo seguro para las aplicaciones desarrolladas internamente, y procedimientos para evaluar o probar la seguridad de las aplicaciones desarrolladas externamente que utiliza la entidad cubierta. El CISO, o una persona cualificada que designe, los revisa y actualiza al menos una vez al año.

   Fuente:23 NYCRR 500.8

   Qué supone para su app móvil

   Tanto su propia app como los SDK o las apps de marca blanca que adquiere necesitan una fase definida de pruebas de seguridad, y el procedimiento necesita una revisión anual.

   Cómo ayuda Ostorlab

   Mobile SAST trabaja sobre la app compilada, por lo que cubre las apps desarrolladas por proveedores y los SDK integrados cuyo código fuente no tiene. SCA muestra qué componentes de terceros incluye cada versión, los asocia a vulnerabilidades conocidas y hace un seguimiento de su cierre de una versión a otra.

   Qué sigue en sus manos

   Los procedimientos escritos y la revisión anual del CISO.

9. 09

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

   Supervise a los terceros, incluidos los proveedores de pruebas

   Qué dice el texto

   El recurso a terceros no reduce ni elimina la responsabilidad de una organización bancaria de llevar a cabo sus actividades de forma segura y sólida y de conformidad con la legislación aplicable. La diligencia debida en materia de seguridad de la información puede incluir la evaluación del programa de seguridad de las aplicaciones del tercero, de su ciclo de vida de desarrollo de software y de los resultados de sus pruebas de vulnerabilidades y de penetración, así como de controles como la autenticación multifactor y el cifrado. Las entidades cubiertas de Nueva York deben disponer de políticas de seguridad para los proveedores de servicios externos, incluidas la diligencia debida y las protecciones contractuales.

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

   Qué supone para su app móvil

   Los proveedores que desarrollan su app o gestionan partes de ella deberían mostrarle los resultados de sus pruebas. Una plataforma de pruebas SaaS que recibe los binarios de su app y las credenciales de prueba es, a su vez, un proveedor que su proceso revisará.

   Cómo ayuda Ostorlab

   Ostorlab cuenta con una auditoría SOC 2 Tipo II. Con el plan Enterprise puede elegir la residencia de datos en Estados Unidos o ejecutar los escaneos on-premises, y con BYOK la IA se ejecuta en la cuenta de su propio proveedor con un límite de gasto por escaneo. SSO/SAML, el control de acceso basado en roles y los registros de auditoría están disponibles como complemento e incluidos en Enterprise.

   Qué sigue en sus manos

   Su diligencia debida, las cláusulas contractuales y la supervisión continua de cada proveedor.

Resumen del FFIEC IT Examination Handbook, las orientaciones del FFIEC sobre autenticación, las Interagency Guidelines Establishing Information Security Standards, las orientaciones sobre terceros de 2023 y la 23 NYCRR Part 500, consultados el 27 de septiembre de 2026. Los cuadernos del FFIEC y las orientaciones interinstitucionales son orientaciones de supervisión; la Part 500 se aplica a las entidades reguladas por el NYDFS. Esta página no constituye asesoramiento jurídico.