📚 课程目录第2章安全需求分析

2. 安全需求分析：威胁建模方法（STRIDE）、安全需求导出、安全用例编写

好，咱们进入第二章。上一章聊了V模型和安全的关系，说白了就是「安全不能是事后补丁」。那怎么在项目一开始就把安全想清楚？靠拍脑袋肯定不行。

我个人习惯，在需求分析阶段必须做一件事——威胁建模。不做威胁建模，你根本不知道系统会挨什么打。

威胁建模是什么？简单说，就是站在攻击者的角度，把系统从头到尾「黑」一遍。在纸上黑，在脑子里黑，用结构化方法黑。

我见过太多团队，上来就写代码，写到一半发现「哎呀这个接口没鉴权」。嗯，那时候改起来就痛苦了。威胁建模就是帮你提前发现这些坑。

STRIDE 是微软提出的一套威胁分类方法。六个字母，代表六类威胁。我每次做威胁建模，都会拿这张表一个一个过。

你想想看，这六类几乎覆盖了所有常见的攻击面。我在项目中遇到过最典型的案例——一个物联网设备管理平台，开发团队只做了登录校验，没做接口级权限校验。结果普通用户直接调用管理员接口，把所有设备固件都升级了。这就是典型的 E（权限提升） 问题。

我的小技巧： 每次过STRIDE，我都拿不同颜色的笔在架构图上标。红色标S，蓝色标T……最后看哪个颜色最多，哪个方向就是最需要投入的。

做威胁建模之前，必须先画数据流图（DFD）。没有DFD，威胁建模就是空中楼阁。

DFD 要画清楚：

画完DFD，在每个数据流上问自己：这个流会不会被S？会不会被T？会不会被I？

核心原则： 每个数据流至少匹配一个STRIDE威胁。如果某个流你找不到威胁，说明你没想透，或者这个流根本不需要存在。

威胁清单有了，下一步就是把它变成可落地的安全需求。这一步很多人做不好——要么写得太虚（「系统要安全」），要么写得太技术（「用AES-256加密」）。

我建议用这个模板来写安全需求：

安全需求模板：

作为 [角色]，当 [场景] 时，系统应 [安全措施]，以防止 [威胁类型]。

举个例子：

你看，这样写出来，开发知道要做什么，测试知道要测什么，安全也知道要审什么。

威胁可能有一百个，但资源有限。怎么排优先级？我个人习惯用 DREAD 模型来打分：

总分越高，越要优先处理。我曾经在一个项目中，有个威胁DREAD总分高达48（满分50），但团队觉得「概率低」想推迟。我坚持要求必须当期修复——结果上线第三天就被白帽子打穿了。嗯，从那以后，我再也不信「概率低」这种话了。

注意： 安全需求不能只写在文档里。必须进入需求管理系统（Jira、Polarion等），和功能需求一样有优先级、有负责人、有验收标准。

安全需求写好了，但开发不一定知道怎么测。这时候就需要安全用例。

安全用例和普通用例的区别在哪？普通用例描述「正常流程」，安全用例描述「攻击流程」和「防御验证」。

我一般把安全用例分成三个场景：

举个例子，针对「登录接口防暴力破解」这个安全需求：

我的经验： 攻击场景的用例最难写，因为你要「像黑客一样思考」。我每次写攻击用例前，都会先搜一下这个功能有没有现成的CVE或公开漏洞报告——站在巨人的肩膀上，比自己瞎想靠谱得多。

安全用例写完了，怎么算「通过」？我定三个标准：

这三个标准缺一不可。我见过一个团队，安全用例全过了，但上线后发现日志没打——出了事根本查不了。你说这安全用例算过了吗？

来，咱们捋一下这章的核心：