CORF del Banco Central de Kuwait: pruebe la app de banca móvil que usan sus clientes.
El Banco Central de Kuwait publicó su Cyber and Operational Resilience Framework (CORF) el 3 de diciembre de 2025, a partir del Cybersecurity Framework de 2020. Sus requisitos básicos de seguridad de pagos fijan normas concretas para las apps de banca móvil: bloquear los dispositivos con root y jailbreak, cerrar las sesiones a los cinco minutos, limitar la validez de las contraseñas de un solo uso a dos minutos como máximo y probar las apps y las API mediante evaluaciones de vulnerabilidades y pruebas de penetración. Ostorlab le da soporte en sus obligaciones de pruebas de la app y de las API que la sustentan, en cada versión.
- Comprueba si la detección de root y jailbreak resiste, y qué hace la app cuando se activa
- Prueba el inicio de sesión, los códigos de un solo uso, las verificaciones reforzadas y los tiempos de espera de sesión con sus cuentas de prueba
- Sigue a la app hasta sus API, incluso con TLS pinning, para probar la autorización y los abusos
- Hace el seguimiento de los hallazgos hasta su cierre y vuelve a probar cada corrección, con evidencia que usted conserva
- A quién se aplica
- Todas las entidades reguladas bajo la supervisión del Banco Central de Kuwait
- Publicación
- CORF versión 1.0, 3 de diciembre de 2025
- Objeto
- Resiliencia cibernética y operativa, incluida la seguridad de la banca en línea y móvil
- Referencia
- CORF, capítulo 4, Cyber Resilience Baselines, dominios 5 y 8
Los textos del CBK que rigen el canal móvil
El CORF es el último paso de una serie de textos del CBK sobre ciberseguridad y pagos electrónicos. Las fechas siguientes corresponden a los textos citados en esta página.
- 23 de diciembre de 2018
Instrucciones sobre pagos electrónicos
La circular n.º (2/BS, BS, IBS/415/2018) dicta las Instructions for Regulation of the Electronic Payment of Funds para los bancos locales y otras instituciones.
- Enero de 2020
Cybersecurity Framework
La versión 1.0 del Cybersecurity Framework para el sector bancario kuwaití establece la primera base de ciberseguridad común a todo el sector.
- 18 de septiembre de 2023
Medidas contra el fraude electrónico
La circular n.º (2/BS, IBS/534/2023) fija normas sobre el alta de beneficiarios, los nuevos dispositivos y las apps de control remoto en la banca por internet y móvil.
- 3 de diciembre de 2025
CORF versión 1.0
Se publica el Cyber and Operational Resilience Framework, que pasa del marco de 2020 a un modelo centrado en la resiliencia y orientado a la madurez.
- Cada año
Perfil de riesgo, autoevaluación y revisión del CBK
Las entidades actualizan el perfil de riesgo inherente y presentan una autoevaluación cada año. El CBK evalúa a las entidades de nivel 1 cada año, a las de nivel 2 cada dieciocho meses y a las de nivel 3 cada dos años.
- Cada trimestre
Información sobre vulnerabilidades al Consejo
La función de seguridad de la información informa al Consejo y a la alta dirección sobre la eficacia de la gestión de vulnerabilidades, con periodicidad trimestral o superior.
Los requisitos básicos del CORF, aplicados a su app móvil
Los requisitos básicos de seguridad tecnológica y de pagos del CORF, junto con la circular del CBK sobre fraude electrónico. Para cada norma: qué dice el texto, qué supone para una app de banca móvil, cómo ayuda Ostorlab y qué sigue en manos de su equipo.
- CBK CORF, capítulo 4, 5.8.2.2 y 8.3.1.14
Pruebe sus apps con evaluaciones de vulnerabilidades y pruebas de penetración
Qué dice el texto
Todas las aplicaciones, sea cual sea su tipo, deben someterse periódicamente a evaluaciones de seguridad exhaustivas, incluidas evaluaciones de vulnerabilidades y pruebas de penetración. Las entidades también deben realizar evaluaciones de seguridad periódicas para identificar y corregir vulnerabilidades en sus plataformas de banca en línea y sus aplicaciones de banca móvil.
Qué supone para su app móvil
La app de banca móvil se menciona expresamente. Necesita evaluaciones de vulnerabilidades y pruebas de penetración periódicas, y las brechas que detecten deben corregirse.
Cómo ayuda Ostorlab
Mobile SAST analiza el binario, incluidos los SDK integrados, y Mobile DAST prueba la app en ejecución; ambos se ejecutan en CI/CD. El pentest con agentes de IA profundiza tras el inicio de sesión, con un exploit funcional que puede reproducir para cada hallazgo de los agentes de IA.
Qué sigue en sus manos
La fijación de la periodicidad de las pruebas, la definición del alcance de las pruebas manuales y la aprobación de las correcciones.
- CBK CORF, capítulo 4, 8.3.1.7, 8.1.3.3 y 8.3.3.3
Bloquee los dispositivos con root y jailbreak
Qué dice el texto
Las entidades deben implantar controles para impedir la instalación y bloquear el uso de las aplicaciones de banca móvil en dispositivos con jailbreak o root. Los dispositivos utilizados para la banca digital deben verificarse de forma continua frente a las políticas de seguridad, incluidas la versión del sistema operativo, el nivel de parches y la integridad del dispositivo, y a los dispositivos que no las cumplan se les debe restringir o revocar el acceso. Los monederos digitales también deben bloquear su uso en dispositivos con jailbreak o root.
Qué supone para su app móvil
La detección de root y jailbreak es un requisito, no una opción. Tiene que activarse y la app tiene que reaccionar, incluso cuando un atacante intenta ocultar el estado del dispositivo.
Cómo ayuda Ostorlab
Mobile Shielding Scan ejecuta la app en entornos con root y jailbreak, intenta eludir la detección de root y jailbreak, la protección contra manipulación, la anti-instrumentación y el TLS pinning, y muestra si la app bloquea el flujo, se niega a iniciarse o sigue funcionando. Obtiene una puntuación de endurecimiento y evidencia de elusión.
Qué sigue en sus manos
La elección y la configuración de su producto de blindaje o de protección en tiempo de ejecución, y la política de conformidad de los dispositivos.
- CBK CORF, capítulo 4, 8.3.1.3 y 8.1.3.5
Utilice una MFA robusta para las acciones críticas
Qué dice el texto
Las entidades deben implantar una autenticación multifactor robusta y una verificación fuera de banda para autorizar acciones críticas como la activación de cuentas, las transferencias de fondos, el pago de facturas y el alta de beneficiarios, mediante OTP de apps de autenticación de terceros, notificaciones push en la app con aprobación biométrica o por PIN, o autorización basada en el dispositivo como FIDO2. Los cambios en la información sensible del cliente, como el número de móvil y la dirección de correo electrónico, requieren MFA.
Qué supone para su app móvil
Cada acción crítica de la app necesita su propia verificación robusta, y esa verificación tiene que mantenerse en el servidor, envíe lo que envíe la app.
Cómo ayuda Ostorlab
Ostorlab completa los códigos de un solo uso por SMS, correo electrónico o TOTP con sus cuentas de prueba y prueba la aplicación de la MFA y los flujos de autenticación reforzada, incluido cómo intentan manipularlos los atacantes, junto con las llamadas a la API que hay detrás de los cambios en la cuenta.
Qué sigue en sus manos
La elección de los métodos de autenticación y la obtención del consentimiento del cliente para el método de envío de las OTP.
- CBK CORF, capítulo 4, 8.3.1.1, 8.3.1.2 y 8.1.3.1
Limite las sesiones, las contraseñas de un solo uso y los intentos fallidos
Qué dice el texto
Las sesiones de banca móvil deben finalizar automáticamente tras un máximo de cinco minutos de inactividad, y no se permiten sesiones simultáneas. Las contraseñas de un solo uso tienen una validez máxima de dos minutos, y las sesiones deben revalidarse a intervalos fijados o cuando cambie el contexto de la sesión. El acceso debe bloquearse tras un máximo de tres intentos fallidos de inicio de sesión o de autenticación.
Qué supone para su app móvil
Son parámetros concretos y comprobables: el tiempo de espera por inactividad, la prohibición de sesiones paralelas, la vida útil de las OTP y el umbral de bloqueo.
Cómo ayuda Ostorlab
Las pruebas autenticadas cubren 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, y el análisis del tráfico muestra cómo viajan las credenciales desde la app hasta el backend.
Qué sigue en sus manos
El procedimiento de reactivación de los usuarios bloqueados y los desencadenantes de revalidación que elija.
- CBK CORF, capítulo 4, 8.3.1.8 a 8.3.1.10
Cifre los datos locales y vincule la app a los dispositivos
Qué dice el texto
La aplicación de banca móvil debe cifrar todos los datos que almacena localmente en el dispositivo del cliente. Debe verificar el número de móvil del cliente y utilizar la autenticación del dispositivo, como la huella digital del dispositivo o la autenticación basada en certificados, en el primer uso. Los clientes pueden utilizar la app desde un máximo de tres dispositivos validados, o de seis con controles robustos de mitigación del riesgo.
Qué supone para su app móvil
Tanto lo que la app escribe en el dispositivo como la forma en que reconoce un dispositivo nuevo entran en el alcance.
Cómo ayuda Ostorlab
Ostorlab busca tokens de sesión y datos personales en el almacenamiento local, las cachés, los registros y las capturas de pantalla, y detecta errores de configuración que debilitan las protecciones del transporte y de las sesiones. Las pruebas autenticadas cubren los flujos de inicio de sesión y de dispositivos con sus cuentas de prueba.
Qué sigue en sus manos
Los límites de registro de dispositivos, la revalidación de los dispositivos registrados y las notificaciones a los clientes.
- CBK CORF, capítulo 4, 5.8.3.1 a 5.8.3.8 y 8.3.2.7
Proteja sus API y evalúelas tras los cambios importantes
Qué dice el texto
Las API deben seguir prácticas de codificación segura como el OWASP API Security Top 10, aplicar una autenticación robusta y un control de acceso basado en roles, validar todas las entradas, aplicar limitación de tasa y regulación del tráfico, y cifrar el tráfico. Las API deben someterse a evaluaciones de seguridad periódicamente y tras los cambios importantes, como pruebas de penetración, fuzzing, DAST/SAST, pruebas en tiempo de ejecución y pruebas de errores de configuración. Las API de open banking deben evaluarse periódicamente mediante pruebas de penetración y evaluaciones de vulnerabilidades.
Qué supone para su app móvil
Las API que hay detrás de la app necesitan el mismo escrutinio que la app, con una cadencia regular y de nuevo tras cada cambio importante.
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
Las pasarelas de API, el inventario de API, el registro y la monitorización, y la gestión del ciclo de vida de las API.
- CBK CORF, capítulo 4, 5.8.1.3, 5.8.1.6, 5.8.1.7 y 5.9.1.6
Integre la seguridad en el desarrollo y las versiones
Qué dice el texto
Las entidades deben seguir un enfoque DevSecOps, adoptar prácticas de codificación segura como OWASP para abordar debilidades comunes como el CWE Top 25, y mantener una lista de materiales de software (SBOM) actualizada de todo el software, incluido el de proveedores externos. Las pruebas previas a que un cambio llegue a producción deben incluir pruebas de seguridad, revisiones del código fuente cuando proceda, pruebas de penetración y evaluación de vulnerabilidades.
Fuente:CBK CORF, capítulo 4, 5.8.1.3, 5.8.1.6, 5.8.1.7 y 5.9.1.6
Qué supone para su app móvil
Cada versión de la app debería superar pruebas de seguridad antes de llegar a la tienda, y usted debería saber qué componentes de terceros incluye.
Cómo ayuda Ostorlab
Los escaneos automatizados se ejecutan desde su pipeline de CI/CD en cada compilación. SCA enumera los SDK y las bibliotecas nativas de cada versión con sus versiones, los asocia a vulnerabilidades conocidas y hace el seguimiento de su cierre de una versión a otra.
Qué sigue en sus manos
Las revisiones de diseño seguro, las revisiones manuales de código, la segregación de funciones y la aprobación de cambios, incluida la aprobación del CBK para los cambios importantes.
- CBK CORF, capítulo 4, 5.13.1.2, 5.13.1.5 a 5.13.1.7
Haga el seguimiento de las vulnerabilidades hasta su cierre y valide la corrección
Qué dice el texto
Las evaluaciones de vulnerabilidades de redes, sistemas y aplicaciones deben realizarse periódicamente o siempre que se produzcan cambios significativos. Los hallazgos deben documentarse y seguirse hasta su cierre, y las entidades deben validar la corrección para confirmar que las brechas se han subsanado. Las entidades deben utilizar la gestión de la superficie de ataque externa para los activos expuestos al público.
Qué supone para su app móvil
Encontrar los problemas no basta. Necesita un registro de que cada uno se corrigió y se volvió a probar, y una visión de las apps que expone.
Cómo ayuda Ostorlab
Los hallazgos se clasifican como críticos, altos, medios o bajos, se gestionan como tickets en la plataforma o en Jira y ServiceNow, y se vuelven a probar una vez publicada la corrección. El descubrimiento de la superficie de ataque le ayuda a encontrar las apps y los activos que expone.
Qué sigue en sus manos
Los plazos de corrección, la gestión de parches y el informe trimestral al Consejo.
- Circular del CBK n.º (2/BS, IBS/534/2023)
Proteja a los clientes frente al fraude electrónico
Qué dice el texto
Cuando un cliente añade un nuevo beneficiario a través de la banca por internet o móvil, debe enviarse una OTP por SMS, debe notificarse al cliente y el beneficiario no debe activarse durante al menos 12 horas, salvo que el cliente lo confirme. Los dispositivos no reconocidos deben verificarse por teléfono antes de cualquier transacción. Los bancos deben impedir el uso de la app cuando haya instaladas apps de control remoto como AnyDesk, y generar códigos de seguridad para que no puedan realizarse transacciones desde otro dispositivo.
Qué supone para su app móvil
El plazo de espera de los beneficiarios, las verificaciones de nuevos dispositivos y los códigos de seguridad vinculados al dispositivo son lógica de negocio. Tienen que mantenerse en el servidor, no solo en las pantallas de la app.
Cómo ayuda Ostorlab
Ostorlab prueba los controles relevantes para el fraude dentro de la app y de sus API: la autenticación, las verificaciones reforzadas, la gestión de sesiones, las protecciones del dispositivo y la lógica de negocio que hay detrás de los pagos.
Qué sigue en sus manos
La detección de apps de control remoto, la verificación telefónica, la monitorización de transacciones y la concienciación de los clientes.
Resumen de los textos públicos del CBK, consultados el 27 de septiembre de 2026. Las circulares sobre pagos electrónicos son traducciones al inglés publicadas por el CBK a título informativo; el texto en árabe es la versión jurídicamente vinculante. Esta página no constituye asesoramiento jurídico.
CBK CORF, control por control
Los controles móviles y de API del CORF, cómo los prueba Ostorlab en su app y en sus API, y la evidencia que conserva.
| Control | Cómo ayuda Ostorlab | Evidencia que conserva |
|---|---|---|
| Evaluaciones de vulnerabilidades y pruebas de penetración de la app móvilCORF 5.8.2.2, 8.3.1.14 | Pentest con agentes de IA de la app y de sus API, detrás del inicio de sesión, sobre la versión que publica. Detalles | Un exploit funcional que puede reproducir para cada hallazgo de un agente de IA, y un mapa de calor de cobertura |
| Bloqueo de dispositivos con root y jailbreakCORF 8.3.1.7, 8.1.3.3 | Ejecuta la app en entornos con root y jailbreak e intenta eludir la detección de root y jailbreak. Detalles | Puntuación de endurecimiento y evidencia de elusión de cada protección que falló |
| MFA para las acciones críticas y los cambios en los datos de contactoCORF 8.3.1.3, 8.1.3.5 | Inicia sesión con códigos de un solo uso y prueba la aplicación de la MFA y los flujos de autenticación reforzada, así como las llamadas a la API que hay detrás. Detalles | Hallazgos sobre los flujos de inicio de sesión y de autenticación reforzada, con los pasos de reproducción |
| Cierre de sesión a los cinco minutos, OTP de dos minutos, tres intentos fallidosCORF 8.3.1.1, 8.3.1.2, 8.1.3.1 | Prueba el inicio y el cierre de sesión, la renovación de tokens, los tiempos de espera y la invalidación de sesiones. Detalles | Hallazgos sobre sesiones y tokens, con registros de solicitudes y respuestas |
| Cifrado de los datos almacenados en el dispositivoCORF 8.3.1.8 | Busca tokens y datos personales en el almacenamiento, las cachés, los registros y las capturas de pantalla, y comprueba las protecciones del transporte. Detalles | Evidencia del sistema de archivos que muestra qué se escribió, dónde y cuándo |
| Autenticación, control de acceso, limitación de tasa y pruebas de las APICORF 5.8.3.1 a 5.8.3.8, 8.3.2.7 | Intercepta el tráfico incluso con TLS pinning y prueba la autorización, el uso indebido de tokens y abusos como la enumeración y la repetición. Detalles | Evidencia de solicitudes y respuestas para cada hallazgo de API |
| Pruebas de seguridad antes de cada versiónCORF 5.8.1.6, 5.9.1.6 | Mobile SAST sobre el binario y Mobile DAST sobre la app en ejecución, antes de la publicación. Detalles | Hallazgos con el contexto del código descompilado, el tráfico, las trazas de pila y capturas de pantalla |
| Lista de materiales de software (SBOM) de cada versiónCORF 5.8.1.3 | Enumera los SDK y las bibliotecas nativas de cada versión con sus números de versión, y muestra con qué backends se comunican la app y sus SDK. Detalles | Identidad, versión y ubicación de cada componente en el paquete de la app, por versión de la app |
| Seguimiento de los hallazgos hasta su cierre y validación de la correcciónCORF 5.13.1.5, 5.13.1.7 | Agrupa los hallazgos en tickets en la plataforma o en Jira y ServiceNow, y vuelve a probar tras la corrección. | Historial de tickets y resultado de la nueva prueba de cada hallazgo |
| Credenciales codificadas en la appCORF 8.1.3.2 | Detecta claves de API, tokens y credenciales en el paquete de la app y valida si funcionan. Detalles | Secretos validados, con los permisos y servicios que exponen |
Ostorlab prueba los controles de la app y de sus API. La gobernanza, los perfiles de riesgo y las autoevaluaciones, la monitorización del SOC, las operaciones antifraude, la continuidad de negocio, la gestión del riesgo de terceros y de la nube, y la notificación al CBK siguen en manos de sus equipos.
Controles móviles del CORF que probar en su app
Una lista práctica para los equipos de seguridad y de cumplimiento que preparan una evaluación del CORF.
Dispositivos con root y jailbreak
Ejecute la app en dispositivos con root y jailbreak, intente ocultar el estado del dispositivo y confirme que la app bloquea la instalación o el uso.
Parámetros de sesión y de OTP
Verifique el tiempo de espera por inactividad de cinco minutos, la prohibición de sesiones simultáneas, la vida útil de dos minutos de las OTP y el bloqueo tras tres intentos.
MFA en las acciones críticas
Compruebe que la activación de cuentas, las transferencias, el pago de facturas, los nuevos beneficiarios y los cambios en los datos de contacto requieren una MFA robusta, aplicada por el servidor.
Nuevos beneficiarios y nuevos dispositivos
Confirme que el plazo de 12 horas para los beneficiarios y las verificaciones de nuevos dispositivos de la circular 534/2023 no pueden eludirse a través de la API.
Las API que hay detrás de la app
Pruebe la autorización, la validación de entradas y la limitación de tasa en todas las API de cuentas y de pagos, y de nuevo tras cada cambio importante.
Datos que quedan en el dispositivo
Busque tokens y datos personales sin cifrar en el almacenamiento, las cachés, los registros y las capturas de pantalla, así como credenciales codificadas en la app.
SBOM de cada versión
Mantenga una lista actualizada de los SDK y las bibliotecas nativas que incluye cada versión, con sus vulnerabilidades conocidas y su cierre.
Evidencia para la evaluación
Conserve los resultados, los tickets y las nuevas pruebas de cada versión, para demostrar que las vulnerabilidades se siguieron hasta su cierre y que la corrección se validó.
Una lista sugerida, no una plantilla del CBK. Esto no constituye asesoramiento jurídico.
Las capacidades detrás de esta página
Cada una tiene su propia página con los detalles.
- Mobile Agentic Deep ScanLos agentes de IA realizan el pentest de la versión publicada en cada release, con un exploit funcional que puede reproducir para cada hallazgo de un agente de IA.Más información
- Mobile Shielding ScanPruebe en tiempo de ejecución la detección de root y jailbreak, la protección contra manipulación y el pinning, y vea qué protecciones resistieron y cuáles se evadieron.Más información
- Pruebas autenticadasPruebe el inicio de sesión, los códigos de un solo uso y la autenticación reforzada con sus cuentas de prueba.Más información
- Pruebas de API y backendIntercepte el tráfico de la app incluso con TLS pinning y pruebe las API y los backends detrás de cuentas y pagos.Más información
- Mobile SASTAnálisis estático basado en el binario de archivos APK, AAB e IPA, con análisis de propagación (taint) en toda la app y sus SDK integrados.Más información
- SCA y SBOMDetecte dependencias vulnerables, incluidas las bibliotecas nativas compiladas estáticamente, y haga un seguimiento de su cierre versión tras versión.Más información
- Su propia clave de IAEjecute los escaneos con agentes de IA con la clave de su proveedor de IA y un límite de gasto por escaneo, según sus políticas internas.Más información
- Escaneo on-premisesEscanee apps de preproducción, API y repositorios detrás de su firewall o VPN, en una infraestructura que usted controla.Más información
Bancos y fintechs confían en nosotros, entre ellos
Fuentes
Los textos oficiales en los que se basa esta página, consultados el 27 de septiembre de 2026.
- Cyber and Operational Resilience Framework for All Local Banks and Financial Institutions (CORF)Banco Central de Kuwait, versión 1.0, primera publicación el 3 de diciembre de 2025. Se aplica a todas las entidades reguladas por el CBK; el capítulo 4 recoge los requisitos básicos de ciberresiliencia sobre aplicaciones, API, gestión de vulnerabilidades y seguridad de pagos
- CBK Launches the Cyber & Operational Resilience Framework for Local Banks and Financial InstitutionsNota de prensa del Banco Central de Kuwait, 3 de diciembre de 2025
- Cybersecurity Framework for Kuwaiti Banking SectorBanco Central de Kuwait, versión 1.0, enero de 2020. El marco anterior sobre el que se basa el CORF
- Circular No. (2/BS, BS, IBS/415/2018): Instructions for Regulation of the Electronic Payment of FundsBanco Central de Kuwait, 23 de diciembre de 2018, dictada en virtud de la Resolución n.º 44/430 de 2018. Traducción al inglés a título informativo; el texto en árabe es la versión jurídicamente vinculante
- Circulars for Regulating the Electronic Payment of Funds, including Circular No. (2/BS, IBS/534/2023) on Measures for Protection of Customers from Electronic FraudBanco Central de Kuwait, capítulo segundo de las instrucciones sobre pagos electrónicos. La circular 534/2023 tiene fecha de 18 de septiembre de 2023 y trata los beneficiarios, los nuevos dispositivos y las apps de control remoto. Traducción al inglés a título informativo
Preguntas frecuentes
Respuestas claras sobre cobertura, configuración y cómo llegan los resultados a su equipo.
¿No encuentra su respuesta? Reserve una demo o contáctenos.
Pruebe su app de banca móvil frente a los requisitos básicos del CORF
Empiece con un escaneo gratuito de su app desde la tienda, o reserve una demo para realizar con nuestro equipo pruebas de blindaje y con sesión iniciada.