新建系统威胁建模（STRIDE）终极技术指南：从理论到实践的全面深度剖析与实施

一、前言：金融行业威胁建模的必要性与紧迫性

金融行业作为国家关键基础设施和经济命脉，其信息系统的安全性直接关系到金融稳定、客户资产安全和社会信任。根据 2024 年行业安全报告显示，金融机构平均每起安全事件造成的损失达 470 万美元，较 2023 年增长 12%，其中内部威胁导致的安全事件平均损失高达 890 万美元，较外部攻击高出近一倍。

随着金融科技的快速发展，新建系统（如数字银行、移动支付、区块链交易平台等）不断涌现，这些系统面临的威胁呈现专业化、隐蔽化、链条化特点。2024 年曝光的多起银行 “内鬼” 案件显示，金融机构内部人员与外部中介勾结，通过伪造材料、放松审核等方式违规放贷已形成成熟模式，仅某股份制银行上海分行客户经理一案就涉及受贿 130 余万元，暴露了传统风控机制的重大缺陷。

威胁建模作为一种前瞻性安全实践，能够在系统设计阶段识别风险，是金融机构构建 “左移安全” 体系的核心技术手段。尤其在当前监管力度不断加强的背景下，国家金融监督管理总局会同公安部联合制定的《关于加强银行业保险业涉嫌犯罪案件移送工作的规定》已于 2025 年正式施行，对金融机构的内部风险防控提出了更高要求。

二、金融行业威胁建模理论基础

2.1 核心概念与价值定位

威胁建模是通过抽象系统模型，识别潜在攻击路径、评估风险等级并制定缓解措施的系统化过程。在金融领域，其核心价值体现在：

• 成本效益最大化：据统计，系统上线后修复漏洞的成本是设计阶段的 8-10 倍，通过威胁建模可提前规避高风险设计缺陷

• 合规达标：满足《网络安全法》《银行业金融机构信息科技风险管理指引》等监管要求，特别是《网络安全法》第三十一条对关键信息基础设施的重点保护要求

• 客户资产保护：有效防护客户敏感金融数据（如账户信息、交易记录、身份信息）

• 业务连续性保障：确保交易系统、支付通道等高可用性核心服务的稳定运行

• 品牌声誉维护：减少安全事件对金融机构公信力的损害，2024 年贵阳银行安顺分行因内部控制薄弱致员工职务侵占被罚款 20 万元，相关柜员遭终身禁业，对银行声誉造成严重影响

2.2 金融行业威胁的特殊性分析

与其他行业相比，金融系统面临的威胁具有显著差异：

• 目标价值极高：直接关联资金和金融资产，成为攻击者首要目标。2024 年曝光的葫芦岛银行原董事长、行长虚构资管计划挪用资金案，涉案金额高达 26 亿元，其中 18 亿元被非法汇兑至境外

• 攻击动机明确：以经济利益为核心，攻击手段更具针对性，特别是针对信贷审批、资金清算等关键环节

• 合规敏感性强：安全事件可能引发严厉监管处罚（如罚款、业务暂停），根据《网络安全法》第五十四条，监管部门可在风险增大时采取监测、评估、预警等措施

• 影响范围广泛：单一系统漏洞可能引发连锁反应（如挤兑风险、市场波动），金融系统的关联性使其风险具有强传导性

• 内部威胁突出：据行业报告，金融行业 30% 以上的重大安全事件与内部人员相关，且隐蔽性强、危害大。2024 年萍乡市公安局打掉的贷款诈骗团伙就实现了对 “背债人”、贷款中介、金融机构 “内鬼” 的全链条打击，涉案金额近千万元

2.3 金融威胁分类框架（基于 STRIDE 扩展）

在经典 STRIDE 模型基础上，结合金融业务特点扩展为以下威胁类型：

欺骗（Spoofing）

• 账户盗用：通过钓鱼、暴力破解等手段获取客户账户控制权

• 交易对手伪造：虚构交易方进行资金转移，如贷款中介伪造企业身份

• 柜员身份冒用：非法使用柜员账号登录系统操作业务

• 系统接口仿冒：伪造银行 API 接口骗取客户信息，如仿冒网银登录页面

篡改（Tampering）

• 交易金额修改：在交易过程中篡改转账金额或收款账户

• 账户余额篡改：直接修改数据库中的账户余额信息

• 清算数据伪造：在资金清算环节伪造交易记录

• 风控规则绕过：通过技术手段规避反欺诈系统检测

否认（Repudiation）

• 转账交易抵赖：客户否认发起某笔转账交易

• 理财产品购买否认：客户否认购买某理财产品

• 违规操作行为否认：员工否认执行过某违规操作

• 贷款合同签署否认：借款人否认签署贷款合同

信息泄露（Information Disclosure）

• 客户征信数据泄露：非法获取或泄露客户信用报告

• 交易流水外泄：客户账户交易记录被未授权获取

• 风控模型参数泄露：核心反欺诈规则和模型参数泄露

• 信贷审批信息泄露：贷款申请人的敏感信息被泄露给第三方

拒绝服务（Denial of Service）

• 交易系统瘫痪：关键交易服务无法正常提供

• 支付通道中断：移动支付、网银支付等渠道不可用

• 行情服务不可用：股票、外汇等金融行情数据无法获取

• 登录服务中断：客户无法登录网上银行或手机银行

权限提升（Elevation of Privilege）

• 柜员越权查询：访问非职责范围内的客户账户信息

• 运维人员非法访问：超越权限访问核心数据库

• 普通用户获取管理员功能：通过漏洞获取系统管理权限

• 管理层绕过安全控制：滥用职权绕过正常审批流程

三、金融系统威胁建模实施流程

3.1 准备阶段：明确金融业务上下文

业务场景定义

需详细梳理系统涉及的金融业务、交易流程、参与角色：

核心业务类型：

• 零售银行业务：储蓄、转账、信用卡、个人贷款

• 公司银行业务：企业贷款、贸易融资、现金管理

• 资管业务：理财产品、基金代销、资产托管

• 支付结算：网上支付、移动支付、跨境支付

典型交易流程：

以企业贷款业务为例：

1. 客户申请：企业提交贷款申请及相关材料

2. 贷前调查：客户经理实地调查企业经营情况

3. 风险评估：风控部门评估贷款风险等级

4. 审批流程：各级审批人员审批贷款申请

5. 合同签署：签署贷款合同及相关文件

6. 贷款发放：将贷款资金划入企业账户

7. 贷后管理：定期检查企业还款情况

参与角色分析：

• 内部角色：客户经理、风险专员、审批人员、柜员、系统管理员、运维人员

• 外部角色：个人客户、企业客户、第三方支付机构、征信机构、监管机构

• 潜在攻击者：黑客组织、恶意内部人员、诈骗团伙、竞争对手

资产识别与分级

金融机构核心资产及分级标准：

一级资产（极高价值）：

• 客户资金：账户余额、在途资金、准备金

• 核心交易系统：支撑日常交易的核心业务系统

• 支付清算系统：资金结算与清算平台

• 身份认证系统：客户身份识别与验证系统

二级资产（高价值）：

• 账户信息：客户账户基本信息、联系方式

• 交易数据：历史交易记录、流水信息

• 信贷审批系统：贷款申请与审批平台

• 反欺诈系统：实时风险监测与控制平台

三级资产（中等价值）：

• 客户反馈数据：投诉记录、服务评价

• 营销系统：客户营销与管理平台

• 报表系统：业务统计与分析平台

• 客服系统：客户服务与支持平台

四级资产（低价值）：

• 公开信息发布系统：公开产品信息展示平台

• 员工培训系统：内部员工学习平台

• 办公自动化系统：内部办公与协作平台

• 非核心管理系统：如固定资产管理系统

合规要求映射

需明确适用的监管规则，并将合规要求转化为具体安全目标：

主要合规框架：

1. 国内监管要求：

• 《网络安全法》：关键信息基础设施保护、数据安全与个人信息保护

• 《数据安全法》：数据分类分级、风险评估、安全管理

• 《个人信息保护法》：个人信息收集、使用、传输规则

• 《银行业金融机构信息科技风险管理指引》：信息科技风险管理要求

1. 国际标准：

• PCI DSS：支付卡行业数据安全标准

• ISO 27001：信息安全管理体系标准

• NIST Cybersecurity Framework：网络安全框架

合规要求转化示例：

合规要求	安全目标	威胁建模关注点
《网络安全法》第 31 条：关键信息基础设施重点保护	确保核心交易系统安全性	交易数据篡改、系统可用性威胁
《个人信息保护法》第 28 条：敏感个人信息加强保护	防止客户敏感信息泄露	信息泄露威胁、未授权访问
PCI DSS 要求：卡信息传输加密	保障支付卡数据传输安全	数据传输篡改、中间人攻击

3.2 系统建模：构建金融系统抽象视图

3.2.1 核心交易系统数据流图

参与角色：

• 个人客户：通过网银 / 手机银行办理业务的个人用户

• 企业客户：通过企业网银办理业务的企业用户

• 银行柜员：在柜台或后台办理业务的银行员工

• 系统管理员：负责系统配置与维护的技术人员

核心组件：

• 客户终端：网银客户端、手机银行 APP、ATM 终端

• 前端应用服务器：处理客户请求的 Web/APP 服务器

• API 网关：统一接口管理与安全控制

• 账户管理服务：处理账户查询、开户、销户等业务

• 交易处理服务：处理转账、支付等交易类业务

• 认证授权服务：负责用户身份验证与权限管理

• 风控引擎：实时交易风险评估与控制

• 账户数据库：存储客户账户信息

• 客户信息库：存储客户基本资料

• 交易数据库：存储历史交易记录

• 审计日志系统：记录所有操作行为与系统事件

详细数据流向：

1. 客户通过终端（网银 / APP）发起操作请求（查询 / 转账 / 支付）→ 前端应用服务器接收请求并进行初步处理

2. 前端应用服务器将标准化后的请求通过 API 网关转发至对应业务服务（查询请求到账户管理服务，转账请求到交易处理服务）

3. 业务服务在处理请求前，调用认证授权服务验证客户身份（验证 token 有效性 / 密码正确性 / 生物信息匹配度）

4. 认证通过后，账户管理服务根据请求类型读取或写入账户数据库（如查询余额时读取，存款时写入）

5. 交易处理服务处理转账等交易时，先读取客户信息库验证客户状态（如是否冻结），交易完成后写入交易数据库记录明细

6. 交易处理服务在执行转账、支付等关键操作前，会调用风控引擎进行风险评估（如判断是否为异常交易、是否超出客户预设限额）

7. 风控引擎返回风险评估结果，高风险交易可能被拒绝或要求额外验证

8. 所有操作（登录、查询、交易、权限变更）都会实时写入审计日志系统，记录操作人、操作时间、操作内容、操作结果等信息

关键安全节点：

• API 网关：防范请求篡改、SQL 注入、DoS 攻击

• 认证授权服务：防范身份欺骗、会话劫持

• 交易处理服务：防范交易数据篡改、重放攻击

• 风控引擎：防范欺诈交易、洗钱行为

• 审计日志系统：防范交易抵赖、责任追溯困难

3.2.2 信任边界定义与安全控制

外部网络 → DMZ 区域（前端服务）

• 边界定义：互联网与金融机构网络之间的安全边界

• 包含组件：Web 服务器、APP 服务器、负载均衡器

• 控制措施：

  • 防火墙：精确控制出入站流量

  • Web 应用防火墙 (WAF)：防护 Web 应用攻击

  • 入侵检测系统 (IDS)：监测异常网络行为

  • DDoS 防护：抵御分布式拒绝服务攻击

DMZ 区域 → 应用服务区（业务逻辑）

• 边界定义：前端服务与核心业务逻辑之间的安全边界

• 包含组件：账户管理服务、交易处理服务、信贷审批服务

• 控制措施：

  • 应用防火墙：针对应用层协议进行检测和控制

  • API 网关：统一接口管理，实现认证授权

  • 数据加密：服务间通信采用 TLS 1.3 加密

  • 访问控制：基于最小权限原则的服务访问控制

应用服务区 → 数据存储区（数据库）

• 边界定义：业务服务与数据存储之间的安全边界

• 包含组件：账户数据库、交易数据库、客户信息库

• 控制措施：

  • 数据库防火墙：针对数据库协议的访问控制与审计

  • 数据加密：敏感字段存储加密（AES-256）

  • 访问控制：基于角色的数据库访问控制 (RBAC)

  • 数据脱敏：非生产环境数据脱敏处理

数据存储区 → 管理区（运维）

• 边界定义：核心数据与运维管理之间的安全边界

• 包含组件：运维管理平台、监控系统、日志分析平台

• 控制措施：

  • 堡垒机：集中管控运维操作

  • 双因素认证：运维人员强身份验证

  • 操作审计：全程记录运维操作

  • 权限最小化：严格限制运维人员权限范围

3.3 威胁识别：金融场景化攻击路径分析

3.3.1 信贷审批系统威胁点分析

以企业贷款审批流程为例，关键威胁点及攻击路径：

客户申请阶段：

• 威胁点 1：虚假材料提交

  攻击路径：中介机构协助客户伪造企业财务报表、购销合同等申请材料

  案例：2024 年上海某银行客户经理张某案中，中介通过伪造资产负债表、虚构购销合同包装客户资质

• 威胁点 2：身份冒用

  攻击路径：使用他人企业信息申请贷款，或伪造企业法定代表人授权

  案例：贷款中介获取他人企业信息后，伪造公章和授权文件申请贷款

贷前调查阶段：

• 威胁点 3：调查流于形式

  攻击路径：客户经理未实地核查，直接采用中介提供的虚假信息

  案例：九江某银行信贷经理张某未落实贷款调查规定，对中介提供的材料未核实

• 威胁点 4：内部人员勾结

  攻击路径：客户经理与中介勾结，明知材料虚假仍通过审核并收受好处

  攻击路径：中介按贷款金额 1%-3% 向客户经理支付好处费，形成长期利益链条

风险评估阶段：

• 威胁点 5：风控模型绕过

  攻击路径：了解风控规则后针对性包装客户资质，规避风险规则

  案例：中介根据银行风控偏好调整客户材料，使其符合自动审批条件

• 威胁点 6：风险等级篡改

  攻击路径：内部人员修改风险评估结果，降低客户风险等级

  案例：风险专员接受贿赂，将高风险客户评估为中等风险

审批阶段：

• 威胁点 7：审批流程绕过

  攻击路径：通过系统漏洞或权限滥用绕过部分审批环节

  案例：审批人员直接将贷款申请标记为 “已审批” 状态，跳过上级审批

• 威胁点 8：审批权限滥用

  攻击路径：审批人员超越权限审批超出自身审批额度的贷款

  案例：支行行长违规审批超过自身权限的大额贷款

放款与贷后阶段：

• 威胁点 9：放款账户篡改

  攻击路径：修改贷款发放账户为中介控制账户

  案例：中介将贷款发放账户填写为公司员工个人账户，扣取高额利息后再转给客户

• 威胁点 10：贷后监控缺失

  攻击路径：贷款资金用途监控不足，导致资金被挪用

  案例：企业将经营贷款违规用于房地产投资，未被及时发现

3.3.2 网上银行系统威胁点分析

登录环节：

• 威胁点 1：凭证窃取

  攻击路径：通过钓鱼网站、键盘记录器获取用户名密码

  典型手段：仿冒银行官网发送钓鱼邮件，诱导客户输入账号密码

• 威胁点 2：会话劫持

  攻击路径：窃取用户会话 Cookie 或 Token 后接管会话

  技术手段：利用 WiFi 监听、XSS 漏洞获取用户会话标识

操作环节：

• 威胁点 3：交易信息篡改

  攻击路径：在客户端修改交易信息后提交

  典型案例：恶意软件拦截转账请求，修改收款账户后重发

• 威胁点 4：越权操作

  攻击路径：通过参数篡改访问其他客户账户或未授权功能

  技术手段：修改请求中的客户 ID 参数，访问他人账户信息

数据传输环节：

• 威胁点 5：中间人攻击

  攻击路径：拦截并修改客户端与服务器之间的通信

  技术手段：伪造 SSL 证书，实施 SSL 剥离攻击

• 威胁点 6：数据泄露

  攻击路径：未加密传输敏感信息，导致信息泄露

  典型场景：在公共 WiFi 环境下进行网银操作，数据被监听

3.4 风险评估：金融风险量化方法

3.4.1 风险评估维度与权重

金融行业风险评估需综合考虑以下维度，并赋予相应权重：

1. 财务影响（权重 2.0）

• 直接资金损失：预计发生的资金流失金额

• 赔偿成本：对客户或第三方的赔偿费用

• 监管罚款：可能面临的监管处罚金额

• 业务损失：业务中断导致的收入损失

1. 运营影响（权重 1.0）

• 服务中断时长：系统不可用的预计时间

• 业务处理能力：业务处理效率下降程度

• 恢复成本：恢复系统正常运行的成本

• 人力投入：处理安全事件所需的人力资源

1. 声誉影响（权重 1.5）

• 客户流失率：预计流失的客户比例

• 品牌损害程度：对机构品牌形象的负面影响

• 媒体曝光度：事件引发的媒体报道和社会关注程度

• 市场信任度：市场对机构的信任度下降程度

1. 合规影响（权重 3.0）

• 监管处罚等级：可能面临的处罚严重程度

• 整改成本：满足合规要求所需的整改投入

• 业务限制：可能面临的业务暂停或限制

• 法律责任：可能面临的法律诉讼和责任

3.4.2 风险值计算方法

风险值 = 可能性 × (财务影响 ×2 + 运营影响 + 声誉影响 ×1.5 + 合规影响 ×3)

可能性分级标准：

• 高（3 分）：近 1 年内行业内发生过类似事件，技术实现难度低

• 中（2 分）：技术上可行，有潜在攻击动机，但未频繁发生

• 低（1 分）：技术难度大，攻击收益有限，发生概率低

影响程度评分标准：

• 严重（3 分）：造成重大损失，影响范围广，难以恢复

• 中等（2 分）：造成一定损失，影响范围有限，可恢复

• 轻微（1 分）：损失较小，影响范围小，容易恢复

风险等级划分：

• 极高风险：风险值 > 100（如交易数据篡改、账户接管），需立即解决，必要时暂停相关功能

• 高风险：60 < 风险值≤100（如客户信息泄露、权限提升），需 48 小时内制定方案

• 中风险：30 < 风险值≤60（如非核心功能 DoS、低敏感信息泄露），需 2 周内解决

• 低风险：风险值≤30（如边缘功能小漏洞），可纳入常规迭代

3.4.3 风险评估示例

以 “客户经理与中介勾结违规放贷” 为例：

• 可能性评估：高（3 分）- 行业内频繁发生类似案件

• 财务影响：严重（3 分）- 预计贷款损失 500 万元

• 运营影响：中等（2 分）- 需投入大量人力处理不良贷款

• 声誉影响：严重（3 分）- 媒体曝光导致客户信任度下降

• 合规影响：严重（3 分）- 可能面临监管处罚和业务限制

风险值计算：

3 × (3×2 + 2 + 3×1.5 + 的影响 ×3)

= 3 × (6 + 2 + 4.5 + 9)

= 3 × 21.5

= 64.5 → 属于高风险，需 48 小时内制定解决方案

3.5 威胁缓解：金融级安全控制措施

3.5.1 身份欺骗防护措施

1. 多因素认证体系

• 客户层面：密码 + 动态口令（如短信验证码、硬件令牌）+ 生物识别（指纹 / 人脸）

• 员工层面：用户名密码 + USBKey + 生物识别

• 管理员层面：多因素认证 + 操作审批

1. 设备绑定与异常检测

• 实现客户常用设备绑定，新设备登录需额外验证

• 异常登录检测：监测异地登录、IP 地址异常、登录时间异常等

• 示例：长沙农商银行零信任系统实现了持续验证用户身份，根据安全态势变化动态调整访问权限

1. 交易签名与验证机制

• 关键交易采用数字签名确保完整性和真实性

• 交易指令需经客户二次确认，如大额转账需手机验证码确认

• 重要操作需留痕，如柜员操作需双人复核

1. 会话安全管理

• 会话 ID 定期轮换（建议每 10 分钟）

• 敏感操作重新验证身份

• 闲置超时自动登出（最长不超过 15 分钟）

• 会话锁定功能：离开时手动锁定会话

3.5.2 交易篡改防护措施

1. 端到端数据加密

• 采用 TLS 1.3 加密传输所有敏感数据

• 关键交易数据采用应用层加密，加密密钥动态管理

• 敏感字段存储加密（AES-256 算法）

1. 交易数据完整性保障

• 交易信息生成数字签名，接收方验证签名有效性

• 关键数据采用区块链技术确保不可篡改，如交易记录

• 数据库采用事务日志和校验机制，防止数据篡改

1. 防重放攻击机制

• 所有交易请求包含唯一随机数 (nonce) 和时间戳

• 服务器验证请求时效性，拒绝过期请求

• 已处理请求记录到防重放列表，防止重复处理

1. 交易监控与异常检测

• 实时监控交易模式，检测异常交易行为

• 交易金额、频率、时间、地点等多维分析

• 建立客户交易画像，识别偏离正常模式的交易

3.5.3 内部威胁防护措施

针对金融行业突出的内部威胁问题，需实施专项防护：

1. 权限精细化管理

• 基于最小权限原则分配权限

• 实现职责分离，如信贷审批与执行分离

• 权限动态调整：根据岗位变动及时调整权限

• 示例：长沙农商银行零信任系统实现了细颗粒度授权，权限细化至每一个主体

1. 操作监控与审计

• 全面记录员工操作行为，特别是敏感操作

• 实现操作行为分析，识别异常操作模式

• 重点监控高风险岗位：信贷审批、资金清算、客户经理等

• 案例：长沙农商银行零信任系统提供细颗粒度访问记录和详细日志分析，精准追踪用户活动轨迹

1. 敏感操作控制

• 敏感操作需双人复核或审批

• 关键岗位轮岗制度，定期轮换降低长期风险

• 柜员操作实行 “四眼原则”，重要操作需他人授权

• 异常操作实时告警，如批量查询客户信息

1. 内部威胁检测

• 建立员工异常行为模型，检测潜在风险

• 监测员工与外部中介的异常资金往来

• 定期开展内部安全审计和风险评估

• 实施离岗权限冻结：员工离岗时立即冻结系统权限

3.5.4 零信任架构在金融威胁缓解中的应用

长沙农商银行的零信任实践为金融行业提供了参考：

1. 动态访问控制

• 取消传统网络信任边界，所有访问请求均视为不可信

• 基于身份、设备、环境等多因素动态授权

• 实现 “永不信任，始终验证” 的安全理念

1. 应用隐藏与端口收缩

• 采用软件定义边界 (SDP) 隐藏应用资源，不直接暴露服务端口

• 业务系统全部收敛到应用层零信任系统，减少攻击面

• 即使终端被伪造，也难以攻击后端应用系统

1. 全面终端准入控制

• 对终端设备进行全面安全评估，合规设备才能接入

• 终端健康状态持续监测，发现异常立即隔离

• 支持移动设备管理，确保 BYOD 设备安全

1. 增强审计与追溯能力

• 所有访问行为详细记录，支持全面审计

• 实现操作全程可追溯，便于事后调查

• 针对异常行为进行分析，及时发现潜在风险

3.6 验证与迭代：持续安全机制

3.6.1 验证方法与工具

1. 红队演练

• 模拟真实攻击场景，测试防御体系有效性

• 重点测试高风险威胁点，如身份认证、权限控制

• 定期开展针对性演练，如针对信贷审批系统的专项演练

1. 渗透测试

• 由第三方安全团队进行全面渗透测试

• 覆盖网络层、应用层、数据层等各层面

• 重点测试核心业务系统：交易系统、支付系统、信贷系统

1. 代码审计

• 采用静态代码分析工具检测潜在漏洞

• 重点审查核心交易逻辑：金额计算、权限判断、数据验证

• 实现代码提交前的安全扫描，将漏洞扼杀在萌芽阶段

1. 自动化威胁建模验证

• 采用基于 LLM 的威胁建模系统，如比瓴科技 TMA 系统

• 上传业务需求文档即可自动化开展安全需求分析

• 实现威胁建模的自动化验证和持续优化

3.6.2 迭代机制与触发条件

1. 定期更新

• 每季度进行一次全面威胁模型审查

• 每年开展一次完整的威胁建模更新

• 结合年度安全评估结果调整威胁模型

1. 事件触发更新

• 新业务上线前：如推出新的理财产品或支付方式

• 系统架构变更时：如核心系统升级、云迁移

• 重大安全事件后：内部发生安全事件或行业内出现重大安全事件

• 新威胁情报出现时：发现针对金融行业的新型攻击手段

• 监管要求更新后：如监管机构发布新的安全要求或指引

1. 文档管理与版本控制

• 建立威胁模型文档版本控制机制

• 记录每次更新的原因、内容和负责人

• 保存历史版本，便于追溯和对比分析

• 定期备份威胁模型文档，确保可用性

四、金融行业典型系统威胁建模案例

4.1 网上银行系统威胁建模

系统概述

• 核心功能：账户查询、转账汇款、投资理财、账单支付

• 技术架构：微服务架构，混合云部署

• 用户规模：约 500 万个人用户，2 万企业用户

• 交易峰值：每秒 300 笔转账，每日峰值 100 万笔

• 关键资产：客户账户信息、交易数据、支付凭证

关键威胁场景与缓解措施

场景 1：会话劫持导致账户接管

• 威胁描述：攻击者通过窃取会话 ID 控制已登录账户，进行未授权操作

• 攻击路径：利用 XSS 漏洞获取会话 Cookie → 使用会话 Cookie 登录系统 → 执行转账等操作

• 风险等级：极高（风险值 120）

• 潜在影响：资金被盗，单笔最高 50 万元，影响客户信任

• 缓解措施：

  • 会话 ID 定期轮换（每 10 分钟）

  • 敏感操作前重新验证身份

  • 实施 HTTPOnly 和 Secure 属性保护 Cookie

  • 异常行为检测：如短时间内异地操作、频繁转账

  • 会话超时控制：闲置 5 分钟自动锁定

场景 2：转账信息中间人篡改

• 威胁描述：攻击者在传输过程中修改收款账户或交易金额

• 攻击路径：伪造 WiFi 热点 → 拦截用户转账请求 → 修改收款账户 → 转发修改后的请求

• 风险等级：极高（风险值 110）

• 潜在影响：资金转入错误账户，引发纠纷和损失

• 缓解措施：

  • 采用端到端加密传输所有交易数据

  • 交易信息二次确认：展示收款人姓名关键字

  • 实施证书 pinning，防止 SSL 剥离攻击

  • 大额交易人工审核：超过 50 万元需电话确认

  • 转账到新账户需额外验证：如向非常用账户转账需短信验证

场景 3：内部人员越权查询客户信息

• 威胁描述：银行员工超越权限查询或泄露客户账户信息

• 攻击路径：柜员使用自身账号登录 → 通过参数篡改访问其他客户信息 → 截图或记录客户敏感信息

• 风险等级：高（风险值 75）

• 潜在影响：客户信息泄露，可能被用于诈骗或贩卖

• 缓解措施：

  • 基于最小权限原则分配查询权限：柜员仅能访问本网点客户

  • 敏感信息脱敏展示：如卡号显示为 “****1234”

  • 操作全程审计：记录所有查询行为，包括查询时间、查询内容

  • 异常查询检测：如短时间内查询大量客户信息

  • 数据访问水印：在查询结果中嵌入操作员标识，便于追溯

4.2 信贷审批系统威胁建模

系统概述

• 核心功能：贷款申请、材料审核、风险评估、审批流程、合同签署

• 技术架构：B/S 架构，工作流引擎驱动

• 用户规模：内部员工约 500 人，外部企业客户约 10 万家

• 业务特点：高风险操作集中，易发生内外勾结

• 关键资产：客户信贷信息、审批权限、风控模型

关键威胁场景与缓解措施

场景 1：客户经理与中介勾结违规放贷

• 威胁描述：客户经理接受中介贿赂，放松审核标准，使不符合条件的客户获得贷款

• 攻击路径：中介包装客户材料 → 客户经理不实地核查 → 伪造调查报告 → 贷款获批后收取好处费

• 风险案例：九江某银行信贷经理张某与中介勾结，导致大量不符合条件的贷款违法发放，涉及金额 1000 余万元

• 风险等级：极高（风险值 150）

• 缓解措施：

  • 贷前调查双人复核：客户经理与风险专员共同调查

  • 材料真实性自动核验：对接工商、税务等第三方数据验证

  • 随机抽查机制：抽取一定比例贷款申请进行独立复查

  • 利益冲突申报：客户经理需申报与中介的关系

  • 异常交易监测：监测客户经理与中介的资金往来

场景 2：风控模型绕过与参数泄露

• 威胁描述：内部人员泄露风控规则，中介据此包装客户材料规避审核

• 攻击路径：风控人员泄露模型参数 → 中介针对性包装客户 → 贷款申请规避风控规则 → 获得贷款审批

• 风险等级：高（风险值 85）

• 潜在影响：大量高风险贷款获批，形成不良资产

• 缓解措施：

  • 风控模型权限严格控制：按需授权，最小权限

  • 模型参数加密存储，访问全程审计

  • 模型定期更新，增加黑箱特性

  • 随机加入干扰规则，增加规避难度

  • 实施模型有效性验证，检测规避行为

场景 3：审批权限滥用

• 威胁描述：审批人员超越权限审批贷款，或绕过审批流程

• 攻击路径：审批人员修改贷款金额使其在自身审批权限内 → 或直接修改审批状态为 “已批准”

• 风险案例：葫芦岛银行原高层管理人员滥用职权，虚构资管计划挪用银行资金 26 亿元

• 风险等级：极高（风险值 130）

• 缓解措施：

  • 审批权限刚性控制，不可人为修改

  • 审批流程不可跳过，系统强制流转

  • 大额贷款实行集体审批制度

  • 审批操作全程录像，关键操作需双录（录音录像）

  • 定期审计审批记录，检测异常审批模式

4.3 移动支付系统威胁建模

系统概述

• 核心功能：扫码支付、快捷支付、转账、充值、账单查询

• 技术架构：移动端 + API 服务 + 支付核心 + 账务系统

• 交易特点：小额高频，7×24 小时服务，对可用性要求高

• 日均交易量：约 200 万笔，单笔平均金额 380 元

• 关键资产：支付令牌、账户余额、交易记录、设备信息

特有威胁场景与缓解措施

场景 1：移动设备丢失导致未授权支付

• 威胁描述：攻击者获取丢失的移动设备后绕过锁屏完成支付

• 攻击路径：设备丢失 → 绕过锁屏 → 打开支付 App → 完成小额免密支付

• 风险等级：高（风险值 70）

• 潜在影响：账户资金被盗，影响支付安全信任

• 缓解措施：

  • App 独立支付密码：与设备锁屏密码区分

  • 生物识别验证：指纹或人脸验证支付

  • 设备绑定与异常检测：检测异常设备使用

  • 远程锁定 / 擦除功能：支持远程冻结账户

  • 小额免密额度限制：默认≤1000 元，可由客户自主调整

场景 2：支付凭证被盗用

• 威胁描述：恶意 App 窃取支付令牌或验证码，伪造支付请求

• 攻击路径：诱导用户安装恶意 App → 窃取支付令牌或短信验证码 → 伪造支付请求

• 风险等级：高（风险值 80）

• 潜在影响：未经客户授权的支付交易，资金损失

• 缓解措施：

  • 动态支付令牌：每 30 秒刷新一次，一次有效

  • 设备指纹验证：结合设备特征识别异常交易

  • 交易场景验证：验证交易环境、商户信息等

  • 验证码安全保护：防止 App 读取短信验证码

  • 异常交易监控：检测非本人常用商户、交易金额异常

场景 3：支付通道拒绝服务

• 威胁描述：攻击者通过 DDoS 攻击使支付服务不可用

• 攻击路径：控制大量肉鸡 → 向支付 API 发起海量请求 → 系统资源耗尽 → 服务不可用

• 风险等级：中高（风险值 65）

• 潜在影响：支付服务中断，影响客户体验和业务收入

• 缓解措施：

  • 多层 DDoS 防护：云端清洗 + 本地防护

  • API 限流与熔断：防止单个 IP 过度请求

  • 服务弹性扩容：根据流量自动扩展资源

  • 核心服务冗余部署：多区域、多实例部署

  • 交易优先级控制：保障大额交易优先处理

五、金融行业威胁建模最佳实践

5.1 与开发流程深度整合

将威胁建模嵌入金融系统开发生命周期的各个阶段：

需求阶段

• 纳入安全需求：如 “转账需支持双因素认证”

• 明确合规要求：识别适用的监管法规和标准

• 定义安全目标：基于业务价值和风险承受能力

• 输出：安全需求文档、合规要求清单

设计阶段

• 完成初步威胁模型：识别关键资产和潜在威胁

• 进行架构安全评审：邀请安全专家参与

• 设计安全控制措施：将缓解措施融入系统设计

• 输出：威胁模型文档、安全架构设计文档

开发阶段

• 根据威胁点实施安全编码：如防 SQL 注入、XSS

• 安全代码审查：重点审查高风险模块

• 单元测试加入安全测试用例：验证安全控制有效性

• 输出：安全编码指南、代码审查报告

测试阶段

• 基于威胁模型设计安全测试用例

• 执行渗透测试：重点测试高风险威胁场景

• 开展安全功能测试：验证安全控制措施有效性

• 输出：安全测试报告、渗透测试报告

上线前

• 最终威胁模型验证：确认高风险项已缓解

• 安全合规检查：验证是否满足监管要求

• 应急响应预案演练：测试安全事件处理能力

• 输出：上线安全评估报告、应急预案

5.2 合规要求落地实践

建立合规要求与威胁建模的映射关系，确保安全措施满足监管要求：

合规映射方法

1. 合规要求拆解：将法规条款分解为具体安全控制点

• 例：《网络安全法》第 27 条禁止窃取网络数据 → 需实施数据加密和访问控制

1. 威胁模型标注：在威胁模型中标注相关合规条款

• 例：在 “客户信息泄露” 威胁点标注《个人信息保护法》第 28 条

1. 合规检查整合：将合规检查纳入威胁建模验证环节

• 例：PCI DSS 要求的卡信息保护措施验证

关键合规要求映射示例

合规要求	威胁建模关注点	安全控制措施
《网络安全法》第 31 条：关键信息基础设施重点保护	核心交易系统可用性、数据完整性	冗余部署、访问控制、入侵检测
《个人信息保护法》第 28 条：敏感个人信息加强保护	客户信息泄露威胁	加密存储、访问控制、脱敏展示
PCI DSS：支付卡数据保护	卡信息泄露、传输安全	数据加密、访问审计、安全传输
《银行业金融机构信息科技风险管理指引》	内部威胁、权限滥用	最小权限、操作审计、职责分离

5.3 自动化威胁建模实践

随着 AI 技术的发展，金融行业开始采用自动化工具提升威胁建模效率：

基于 LLM 的威胁建模系统

比瓴科技 TMA 系统展示了 LLM 在威胁建模中的应用：

1. 智能文档分析：上传业务需求文档后，系统自动解析核心功能和架构

2. 自动资产识别：AI 识别关键资产，如用户数据、交易信息

3. 全面威胁识别：结合金融行业特性，识别常见和新兴安全威胁

4. 智能风险评估：自动计算风险等级，考虑威胁的影响程度和可能性

5. 定制化缓解策略：针对每个高风险威胁提供具体可行的缓解建议

自动化工具优势

• 效率提升：几分钟内完成人工需数天的威胁建模工作

• 全面性：减少人为遗漏，覆盖更多威胁场景

• 一致性：保持评估标准的一致性，便于横向比较

• 知识沉淀：将专家知识固化到系统中，实现知识复用

实施建议

• 从非核心系统开始试点，逐步推广至核心系统

• 结合人工审核，确保自动化结果的准确性

• 定期更新模型和知识库，应对新型威胁

• 确保工具符合金融行业数据安全要求，优先选择私有化部署

5.4 内部威胁专项建模

针对金融行业内部威胁高发的特点，建立专项威胁建模机制：

内部威胁场景库

建立针对金融行业的内部威胁场景库，包括：

• 权限滥用场景：如柜员越权查询客户账户

• 数据泄露场景：如复制客户信息出售

• 欺诈勾结场景：如与中介合作违规放贷

• 报复破坏场景：如离职员工删除关键数据

防控措施

1. 权限管理优化

• 实施最小权限原则，定期权限审计

• 敏感操作需多人授权，如 “四眼原则”

• 关键岗位权限定期轮换，降低长期风险

1. 行为监控与分析

• 建立员工正常行为基线，监测异常行为

• 重点监控高风险操作：批量数据查询、夜间操作

• 分析员工与外部人员的异常联系，如频繁与贷款中介沟通

1. 技术防控手段

• 数据防泄漏 (DLP) 系统：防止敏感数据外泄

• 操作审计系统：记录所有关键操作，支持追溯

• 屏幕录像：对高风险岗位实施操作录像

• 数据水印：在敏感数据中嵌入操作员标识

1. 管理措施

• 背景调查：对关键岗位员工进行严格背景调查

• 轮岗制度：定期轮岗，及时发现潜在问题

• 离职审计：员工离职前进行全面安全审计

• 举报机制：建立匿名举报渠道，鼓励内部监督

六、金融行业威胁建模工具与资源

6.1 推荐工具与平台

建模工具

1. Microsoft Threat Modeling Tool

• 优势：支持 STRIDE 模型，易于使用，免费获取

• 适用：初步建模与教育训练，中小金融机构

• 特点：内置威胁库，自动生成威胁清单

1. OWASP Threat Dragon

• 优势：开源免费，支持自定义威胁库，跨平台

• 适用：有一定技术能力的团队，需要定制化的场景

• 特点：支持在线协作，可集成到 CI/CD 流程

1. IriusRisk

• 优势：金融行业模板丰富，合规集成好，自动化程度高

• 适用：大型金融机构，复杂系统建模

• 特点：支持合规映射，与开发流程集成

1. 比瓴科技 TMA 系统

• 优势：基于 LLM 的自动化威胁建模，支持私有化部署

• 适用：各类金融机构，特别是有效率提升需求的团队

• 特点：智能文档分析，自动生成威胁和缓解措施

辅助工具

• 数据流图绘制：draw.io, Lucidchart

• 风险计算：定制 Excel 模板或 Python 脚本

• 知识库管理：Confluence (威胁库)

• 安全需求管理：Jira + 安全插件

• 零信任平台：如长沙农商银行采用的零信任接入系统

6.2 威胁情报资源

内部情报来源

• 安全事件记录：内部发生的安全事件分析

• 渗透测试报告：第三方安全评估结果

• 审计日志分析：内部操作审计数据

• 员工安全反馈：一线员工发现的安全问题

行业情报来源

• 金融安全联盟共享信息：行业协会安全信息共享

• 监管机构通报：银保监会、人民银行安全通报

• 同业交流信息：金融机构间的安全经验交流

• 行业报告：金融安全年度报告、威胁趋势报告

外部情报来源

• 国家网络安全应急中心 (CNCERT)：安全预警信息

• OWASP Top 10 (金融版)：针对金融行业的常见漏洞

• 金融行业 APT 报告：定向攻击分析报告

• 安全厂商威胁情报：专业安全公司的威胁数据

• 漏洞平台：CVE、CNVD 等漏洞信息平台

6.3 金融行业威胁建模模板

提供金融行业专用的威胁建模模板，包括：

资产识别模板

资产名称：客户账户信息

资产类型：数据资产

所在位置：账户数据库

负责人：数据安全专员

价值评估：高

敏感级别：极高

相关业务：所有零售银行业务

潜在影响：信息泄露可能导致账户被盗、诈骗等

防护措施：加密存储、访问控制、脱敏展示

威胁清单模板

威胁ID: FIN-TRADE-001

威胁类型: 交易数据篡改

受影响组件: 交易处理服务

攻击路径: 中间人攻击修改传输中的交易数据

潜在影响: 资金转入攻击者账户，造成直接经济损失

相关监管要求: 《商业银行信息科技风险管理指引》第X条

可能的攻击源: 外部黑客、恶意内部人员

现有控制措施: 传输加密、数据签名

建议缓解措施: 端到端加密、交易二次确认

风险等级: 极高

风险评估矩阵

可能性 \ 影响	轻微 (1)	中等 (2)	严重 (3)
低 (1)	低风险	低风险	中风险
中 (2)	低风险	中风险	高风险
高 (3)	中风险	高风险	极高风险

七、结语：构建金融安全防线

金融行业威胁建模是一项持续性工作，需要技术、流程和人员的有机结合。通过将威胁建模融入系统全生命周期，金融机构可以实现从 “被动防御” 到 “主动防控” 的转变。

有效的威胁建模不仅能降低安全事件发生率，还能提升客户信任度，满足监管要求，为金融创新提供安全保障。2024 年的多起银行 “内鬼” 案件警示我们，传统的边界防御已无法应对金融行业复杂的安全威胁，必须采用系统化的威胁建模方法，构建纵深防御体系。

在实施威胁建模过程中，金融机构应注重以下几点：一是高层重视与资源投入，将威胁建模纳入战略安全规划；二是技术与业务融合，确保威胁模型贴合实际业务场景；三是工具与人工结合，利用自动化工具提高效率同时保留专家判断；四是持续迭代与优化，使威胁模型能够适应不断变化的威胁环境。

零信任架构、AI 驱动的自动化威胁建模等新技术为金融行业威胁建模提供了新的可能，长沙农商银行等机构的实践已经证明了这些技术的价值。金融机构应积极探索这些新技术在威胁建模中的应用，提升安全防御能力。

威胁建模没有终点，随着金融业务的创新和攻击手段的演进，金融机构需要不断完善威胁建模方法，构建动态适应的安全防御体系，守护金融安全底线，为金融科技的健康发展保驾护航。

附录：金融威胁建模 checklist

准备阶段检查项

系统边界与范围已明确界定

核心资产已识别并完成分级

相关业务流程已详细梳理

参与人员已到位并明确职责分工

所需文档与工具已准备齐全

合规要求已识别并映射到安全目标

系统建模检查项

数据流图已绘制完整并审核通过

信任边界已清晰定义

外部接口已全部标识并评估风险

数据存储位置已明确并分类

关键功能点已标注并优先级排序

系统组件间的依赖关系已梳理

威胁识别检查项

已覆盖 STRIDE 所有威胁类型

金融特有威胁已识别并分析

攻击路径已完整描述

威胁清单已建立并分类

内部威胁已充分考虑并分析

威胁场景已结合实际案例验证

风险评估检查项

可能性评估已完成并有依据

影响分析已覆盖财务、运营、声誉、合规维度

风险等级已合理划分

高风险威胁已重点标注

评估结果已得到业务和安全团队确认

风险计算方法已文档化

缓解措施检查项

所有高风险威胁已有明确缓解措施

缓解措施考虑了成本效益平衡

安全控制符合相关监管要求

缓解措施可验证、可审计

应急方案已同步制定

缓解措施责任到人并有时限要求

验证与迭代检查项

已进行针对性安全测试

威胁模型已文档化存档并版本控制

迭代机制已建立并明确触发条件

相关人员已完成威胁建模培训

合规要求已满足并能证明

威胁模型已定期更新并记录变化