风险识别方法论：供应商分类、关键节点分析、威胁建模
做供应链安全，第一步不是买工具，也不是堆流程。你得先搞清楚：你的供应商到底是谁？风险在哪？
我见过不少团队，上来就照着 NIST 框架硬套，结果发现根本跑不通。为什么？因为连供应商清单都没理清楚，更别提什么威胁建模了。这一章，我就把这三步走的方法论掰开揉碎讲给你听。
一、供应商分类：别一锅炖
供应商不是铁板一块。你想想看，一个卖办公用品的，和一个给你做核心身份认证系统的，风险能一样吗？
我个人习惯，先把供应商分成三类：
| 类别 | 定义 | 典型例子 | 风险等级 |
|---|---|---|---|
| 关键型 | 直接影响核心业务，或能接触到敏感数据 | 云服务商、身份认证平台、支付网关 | 高 |
| 支撑型 | 支撑业务运行，但非核心 | 办公系统、HR 系统、物流平台 | 中 |
| 通用型 | 不接触核心数据，可替代性强 | 文具供应商、保洁服务、绿植租赁 | 低 |
分类之后，你就能把有限的精力放在关键型供应商上。剩下的，走标准流程就行。
二、关键节点分析：找到那个「一碰就碎」的地方
供应商分类完了，然后呢？你得画图。
我建议你画一张供应链数据流图。别怕麻烦，这张图能救你的命。图上要标清楚：
- 数据从哪里来，到哪里去
- 谁在处理数据
- 数据在哪些环节会「落地」（比如存到数据库、写到日志）
- 哪些环节有外部接口
画完之后，你就能找到那些关键节点。什么叫关键节点？说白了，就是一旦它出问题，整个链条就断了。
关键节点的三个特征：
- 单点依赖：只有这一个供应商能做，换不了
- 数据汇聚：所有敏感数据都经过它
- 权限过高：它拥有你系统里的高权限账号
举个例子。我之前审计一家金融科技公司，发现他们的风控模型数据，全部经过一个第三方数据清洗服务。这个服务商只有 3 个人，连个像样的安全团队都没有。这就是典型的关键节点——一旦它被攻破，整个风控模型的数据都能被篡改。
三、威胁建模：STRIDE 和 LINDDUN 怎么用
找到关键节点之后，就该做威胁建模了。这里我重点讲两个框架：STRIDE 和 LINDDUN。
3.1 STRIDE：微软的经典框架
STRIDE 是微软提出的，用来分析系统安全威胁。每个字母代表一类威胁：
| 字母 | 威胁类型 | 通俗解释 | 供应链场景举例 |
|---|---|---|---|
| S | Spoofing（假冒） | 别人冒充你 | 供应商的 API 密钥被窃取，攻击者伪装成供应商调用你的接口 |
| T | Tampering（篡改） | 数据被改了 | 供应商在软件更新包中植入恶意代码 |
| R | Repudiation（抵赖） | 做了不承认 | 供应商声称没有收到你的安全补丁通知，日志却显示已送达 |
| I | Information Disclosure（信息泄露） | 秘密被看到了 | 供应商的运维人员能看到你的数据库备份文件 |
| D | Denial of Service（拒绝服务） | 服务用不了 | 供应商的 DNS 服务被 DDoS，你的网站打不开 |
| E | Elevation of Privilege（权限提升） | 小兵变将军 | 供应商的普通账号通过漏洞获取了管理员权限 |
3.2 LINDDUN：隐私威胁建模
LINDDUN 是专门针对隐私威胁的框架。它和 STRIDE 类似，但关注点不同：
| 字母 | 威胁类型 | 供应链场景举例 |
|---|---|---|
| L | Linkability（链接性） | 供应商通过你的订单数据，关联出你的用户画像 |
| I | Identifiability（可识别性） | 供应商能从匿名数据中反推出具体用户身份 |
| N | Non-repudiation（不可抵赖） | 供应商记录了用户的所有操作，用户无法否认 |
| D | Detectability（可检测性） | 供应商能检测到用户是否使用了隐私保护工具 |
| D | Disclosure of Information（信息泄露） | 供应商无意中把用户数据暴露在公开存储桶中 |
| U | Unawareness（无意识） | 供应商员工不知道哪些数据是敏感数据，随意分享 |
| N | Non-compliance（不合规） | 供应商的数据处理方式不符合 GDPR 要求 |
我个人建议：技术安全用 STRIDE，隐私合规用 LINDDUN。两个框架不冲突，可以结合着用。
四、实战：一张图看懂整个方法论
说了这么多，不如一张图来得直观。下面是我自己画的风险识别流程，你照着这个思路走，基本不会漏。
五、避坑指南：我踩过的那些坑
最后，分享几个我亲身经历过的教训，希望能帮你少走弯路。
坑一：只分类，不分析
我曾经帮一家电商公司做审计。他们把所有供应商分成了三类，看起来很专业。但当我问「你们的关键节点在哪？」的时候，没人答得上来。因为他们只做了分类，没做数据流分析。结果呢？一个做数据分析的第三方供应商，手里握着所有用户的购买记录，连个加密都没有。
坑二：威胁建模只做一次
威胁建模不是一次性工作。供应商会换版本，会更新 API，会调整架构。你去年做的威胁建模，今年可能就失效了。我建议每季度至少 review 一次，或者在供应商有重大变更时重新做。
坑三：忽略「人」的因素
STRIDE 和 LINDDUN 都是分析「系统」的。但供应链安全里，人往往是最薄弱的环节。比如供应商的员工把密码贴在显示器上，或者用个人邮箱传文件。这些威胁，框架是分析不出来的。所以，别忘了做人员安全意识评估。
好了，这一章的内容就到这。方法论是死的，人是活的。你拿着这三步走，结合自己的业务场景去调整，一定能找到适合你的风险识别方式。