NRB 网络韧性规则：每次发布都评估您的移动银行应用。

1. 01

   NRB《信息技术指南》2012，信息安全 2.6 和 2.7

   定期评估安全并开展入侵测试

   文本的内容

   信息安全不是一次性活动，银行应建立制度化流程，定期评估组织的安全状况，发现并修复漏洞。建议定期对系统开展渗透测试。银行应以操作系统、防火墙和系统软件的最高安全设置加固系统，安装后立即更改默认密码，并安装供应商提供的更新和补丁。（《信息技术指南》信息安全 2.6 和 2.7）

   来源：NRB《信息技术指南》2012，信息安全 2.6 和 2.7

   对您的移动应用意味着什么

   定期评估是基本期望，不是一次性项目。移动应用及其背后的 API 都属于这一循环。

   Ostorlab 如何提供帮助

   Mobile SAST 分析二进制文件，包括嵌入的 SDK；Mobile DAST 测试运行中的应用；两者都可在 CI/CD 中运行。AI 智能体渗透测试对应用及其 API 进行登录后的测试，AI 智能体的每个发现都附有可重放的有效漏洞利用。

   仍由您负责的部分

   确定频率和范围、服务器和网络设备的平台评估、打补丁和报告。

2. 02

   NRB《信息技术指南》2012，信息安全 2.9 和 2.28

   保护移动设备存储和发送的信息

   文本的内容

   银行在提供移动设备银行服务时，应考虑移动设备可能存储的信息的安全，并对从移动设备发送至银行系统的交易信息以及 PIN 或密码进行加密。为转账功能设定每日和单笔交易限额等额外控制措施。银行应部署强加密和端到端加密，保护网络中和存储中的客户 PIN、用户密码和其他敏感数据。（信息安全 2.9 和 2.28）

   来源：NRB《信息技术指南》2012，信息安全 2.9 和 2.28

   对您的移动应用意味着什么

   应用写入手机的内容和发送到后端的内容都在范围内，从令牌和个人数据到交易明细。

   Ostorlab 如何提供帮助

   Ostorlab 在本地存储、缓存、日志和截图中查找会话令牌和个人数据，检查传输保护，并测试限额和检查是否由后端而非仅由应用强制执行。

   仍由您负责的部分

   选择加密技术和密钥管理、设定限额，以及针对已被入侵设备的策略。

3. 03

   NRB《信息技术指南》2012，信息安全 2.27 和 2.29

   关键操作使用多种因素

   文本的内容

   银行应对网上银行转账等关键活动采用多种因素进行身份验证，验证方法应与网上银行的风险相匹配。银行卡在线支付应使用第二因素验证，并通过电子邮件、短信或自动语音电话向客户提供即时提醒。（信息安全 2.27 和 2.29）

   来源：NRB《信息技术指南》2012，信息安全 2.27 和 2.29

   对您的移动应用意味着什么

   第二因素必须由服务器在每次关键操作中强制执行，包括应用或攻击者跳过某一步骤的情况。

   Ostorlab 如何提供帮助

   认证测试覆盖登录和注销、令牌刷新、超时、会话失效和 MFA 强制执行，包括增强验证流程，以及其背后的 API 调用。

   仍由您负责的部分

   选择身份验证方式和提醒渠道，并在核心银行系统中落实。

4. 04

   NRB《信息技术指南》2012，信息安全 2.30

   保护 Web 应用及其加密

   文本的内容

   银行应实施充分的安全措施，保护其 Web 应用免受传统和新兴网络威胁与攻击，关键应用应采用最新的 SSL 加密。（信息安全 2.30）

   来源：NRB《信息技术指南》2012，信息安全 2.30

   对您的移动应用意味着什么

   您的应用调用的 API 就是 Web 应用。它们需要针对同类攻击的测试，以及最新的传输加密。

   Ostorlab 如何提供帮助

   Ostorlab 即使在启用 TLS 证书固定的情况下也能拦截应用流量，并测试 API 的授权缺陷（BOLA、BFLA、IDOR）、令牌滥用以及枚举和重放等滥用行为，同时检查削弱传输保护的配置错误。

   仍由您负责的部分

   TLS 配置和证书、网络控制以及应用的业务逻辑。

5. 05

   NRB《信息技术指南》2012，信息系统的获取、开发与实施 7.1、7.2 和 7.4

   在开发中内置安全并审查代码

   文本的内容

   在开发软件之前，应记录用户功能需求、安全需求、性能需求和技术规范，并由适当层级的管理层批准。信息安全需求应纳入软件开发生命周期的每个阶段，涵盖访问控制、身份验证、交易授权、系统活动日志、审计追踪和数据完整性。鼓励银行对应用进行源代码审查，以发现漏洞和缺陷，所有发现的漏洞都应在系统实施前修复。（《信息技术指南》信息系统的获取、开发与实施 7.1、7.2 和 7.4）

   来源：NRB《信息技术指南》2012，信息系统的获取、开发与实施 7.1、7.2 和 7.4

   对您的移动应用意味着什么

   安全需求应进入需求待办列表，版本不应带着代码审查本可发现的已知缺陷发布。

   Ostorlab 如何提供帮助

   Mobile SAST 对 APK、AAB 或 IPA 进行静态分析，对应用及其嵌入的 SDK 进行污点分析，并可在 CI/CD 中运行。发现的问题在平台内或 Jira 和 ServiceNow 中作为工单跟踪，修复发布后重新测试。

   仍由您负责的部分

   安全需求、安全编码标准、人工审查和发布审批。

6. 06

   NRB《信息技术指南》2012，外包管理 5.3、5.5 和 5.10；《网络韧性指南》2023，64

   管理外包和第三方

   文本的内容

   所有外包业务都应遵守银行的信息安全和隐私政策，银行应确保服务提供商实施充分的内部控制、逻辑访问控制和物理安全控制。银行应建立监控和管理外包活动的流程。将 IT 运营外包到境外时，银行应考虑国家风险，并在协议开始时明确数据管辖权和适用法规。《网络韧性指南》要求银行确认第三方供应商和服务提供商（包括 ICT 供应商）满足其网络韧性要求，并在合同中涵盖安全能力验证和供应链风险。（《信息技术指南》外包管理 5.3、5.5 和 5.10；《网络韧性指南》64）

   来源：NRB《信息技术指南》2012，外包管理 5.3、5.5 和 5.10；《网络韧性指南》2023，64

   对您的移动应用意味着什么

   应用捆绑的 SDK 是拥有各自后端的第三方。它们属于您的供应商风险视图和数据管辖权决策。

   Ostorlab 如何提供帮助

   Ostorlab 列出每个版本中的 SDK 和原生库及其版本和在应用包中的位置，显示应用及其 SDK 与哪些后端通信，并将存在漏洞的组件映射到已知漏洞。

   仍由您负责的部分

   合同、尽职调查、数据管辖权决策和供应商监控。

7. 07

   支付系统相关统一指令 2082，第 3 号（尼泊尔文文本）；《网络韧性指南》2023，第四部分

   保障电子支付系统的安全

   文本的内容

   支付系统相关统一指令 2082 是面向获准开展支付相关业务机构的合并规则，依据《支付与结算法》2075（2019 年）第 45 条发布。其第 3 号指令涉及电子支付系统的运营和安全，《网络韧性指南》则将相同的网络韧性标准适用于 A、B、C、D 类银行和金融机构、支付系统运营商和支付服务提供商。（支付系统相关统一指令 2082，第 3 号，尼泊尔文文本；《网络韧性指南》第四部分）

   来源：支付系统相关统一指令 2082，第 3 号（尼泊尔文文本）；《网络韧性指南》2023，第四部分

   对您的移动应用意味着什么

   钱包或支付应用及其 API 就是客户接触的电子支付系统。其运营安全是支付指令中明确列出的主题。

   Ostorlab 如何提供帮助

   Ostorlab 在您发布的版本上，对支付应用以及账户、支付和余额背后的 API 进行登录后的测试，并按版本留存证据。

   仍由您负责的部分

   牌照条件、运营规则，以及依据支付系统指令向 NRB 报告。

8. 08

   NRB《网络韧性指南》2023，135 至 148 和 160

   运行完整的测试计划

   文本的内容

   《网络韧性指南》期望建立完整的测试计划，以基于风险的方法制定，定期审查和更新，对问题进行优先级排序、解决和验证，并由内部或外部的独立方执行测试。计划应包括漏洞评估以及静态和动态代码审查。在部署或重新部署支撑关键功能的服务之前，以及定期对运行中的服务和应用开展漏洞评估。漏洞扫描应覆盖对外服务以及内部系统和网络，并在不同环境之间轮换。 （《网络韧性指南》135 至 148 和 160）

   来源：NRB《网络韧性指南》2023，135 至 148 和 160

   对您的移动应用意味着什么

   一次发布就是对面向互联网服务的变更。计划必须覆盖部署之前，并在之后持续覆盖。

   Ostorlab 如何提供帮助

   Ostorlab 从您的 CI/CD 流水线在每次构建时运行自动扫描，无需手动触发即可监控商店发布版本，并按构建和版本保存结果。发现的问题按严重、高、中、低评级。

   仍由您负责的部分

   计划本身、其基于风险的范围、内部系统和网络，以及审批人。

9. 09

   NRB《网络韧性指南》2023，142 和 155 至 164

   在全部应用组合中开展入侵测试

   文本的内容

   应开展渗透测试，通过模拟真实攻击，识别可能影响系统、网络、应用、人员或流程的漏洞。测试应定期进行，并在系统发生重大更新或部署时进行。银行应在系统开发生命周期的所有阶段，在业务、应用和技术各个层面，对包括移动应用在内的全部应用组合开展安全评估和测试。应借助最佳实践和自动化工具修复弱点，并确保符合已批准的策略和配置。基于威胁场景的红队测试也属于《网络韧性指南》的测试范围。（《网络韧性指南》142 和 155 至 164）

   来源：NRB《网络韧性指南》2023，142 和 155 至 164

   对您的移动应用意味着什么

   移动应用被明确列入应用组合，重大更新会触发测试。对于每隔几周就发布的渠道，一年一次的测试远远不够。

   Ostorlab 如何提供帮助

   AI 智能体渗透测试在客户下载的版本上运行，对应用及其 API 进行登录后的测试，为 AI 智能体的每个发现提供可重放的漏洞利用和覆盖热图。Ostorlab 不开展红队演练。

   仍由您负责的部分

   渗透测试和红队演练的排期与范围界定，以及处理非应用系统的发现。

10. 10

    NRB《网络韧性指南》2023，54(d)、54(e) 和 71(d)

    对关键系统要求 MFA 并加密数据

    文本的内容

    《网络韧性指南》要求关键系统、流程和角色在支持的情况下都应使用多因素身份验证。指南还要求采取强有力的数据与信息保护控制，包括与重要性、敏感性和风险评估相称的数据加密，以及符合公认标准和流程的加密，涵盖算法、密钥长度、密钥生成和密钥管理。（《网络韧性指南》54(d)、54(e) 和 71(d)）

    来源：NRB《网络韧性指南》2023，54(d)、54(e) 和 71(d)

    对您的移动应用意味着什么

    MFA 规则不仅针对客户登录：能够接触客户数据的管理后台和后台岗位也在范围内。应用在设备上存储的内容、发送的内容以及后端保留的内容，都需要可证明的保护。

    Ostorlab 如何提供帮助

    认证测试检查 MFA 强制执行和增强验证流程，静态和动态分析则在存储、缓存、日志和截图中查找令牌和个人数据，并在应用包中发现 API 密钥和凭据。

    仍由您负责的部分

    在内部和面向客户的系统中部署 MFA、加密技术选择、数据分类和密钥管理。

NRB 公开文本摘要，核对日期为 2026 年 9 月 27 日。支付系统指令和统一指令以尼泊尔文发布，本页对其概括而非引用。本页不构成法律意见。