1. 安全设计审查

1.1. Security Design Review，SDR

1.2. 将安全性融入软件设计的最佳方法之一是戴上“安全帽”进行单独的设计审查

1.3. 安全审查员是熟悉软件运行的系统和环境，以及知道如何使用它的人，但他们不参与设计工作，这能够给予他们距离感以保持客观性

1.4. 最好从一个中等大小的设计开始，这样你不会觉得太难上手，或者从一个大型系统中分出一个组件并只审查这一部分内容

2. SDR基本概念

2.1. SDR只会占用总设计时间的一小部分，却能够识别出重要的改进以增强安全性，或者为设计出适当的安全性解决方案提供有力的保证

2.2. 对于较大的设计，审查过程提供了一个有用的框架来识别和验证主要的热点

2.3. SDR可以带来有价值的新见解，从而促进与安全性无关的设计变更

2.4. 如果计划在设计（或设计迭代）完成且稳定时执行SDR，通常要选在功能审查之后但在设计最终确定之前，因为可能有需要更改的地方

• 2.4.1. 不要将安全性作为功能审查的一部分，因为两者的思维方式和关注领域完全不同

• 2.4.2. 关注安全性也很重要，但联合审查会倾向于更多地关注设计的运作，因此很难关注到安全性

2.5. 复杂的或安全性第一的设计，通常能够受益于额外的初步SDR，也就是在设计开始形成但仍未完全成形时执行SDR，以便能够获得有关重大威胁和整体策略的早期信息

• 2.5.1. 设计师永远不应忽视安全性，也不能依靠SDR为他们解决相关问题

• 2.5.2. 安全审查员扮演的是支持角色，其职责是帮助设计师并确保他们能够很好地完成工作

2.6. 文档是必不可少的

• 2.6.1. 有效的SDR依赖于及时更新的文档，以便参与的各方对审查中的设计有准确和一致的理解

3. SDR流程

3.1. 软件设计可以以无数不同的方式开展，你可以将相同的策略和分析应用于不是很正式的组织机构

• 3.1.1. 每个人都有不同的风格

3.2. 6个阶段

• 3.2.1. 研究设计文档和支持文档，对项目建立基本的了解

• 3.2.1.1. 阅读文档，从全局上理解设计

• 3.2.1.2. 戴上你的“安全帽”​，以威胁意识的心态重新审视它

• 3.2.1.3. 记笔记，记录你的想法和观察结果以供将来参考

• 3.2.1.4. 为未来标记潜在问题，但在此阶段进行大量安全分析还为时过早

• 3.2.2. 对设计进行询问，并就基本威胁提出澄清问题

• 3.2.2.1. 确保设计文件清晰完整

• 3.2.2.2. 如果有遗漏或需要更正之处，请在文档中修正它们

• 3.2.2.3. 对设计的理解要通透，但不一定要达到专家级

• 3.2.2.4. 询问团队成员他们最担心什么，如果他们没有安全性担忧，请追问其原因

• 3.2.2.5. 安全审查员提出的问题不必严格局限于设计文档中的内容

• 3.2.3. 识别出设计中最需要保障安全性的关键部分，以引起更密切的关注

• 3.2.3.1. 将其作为目标并进行仔细分析

• 3.2.3.2. 从CIA、黄金标准、资产、攻击面和信任边界的角度进行思考

• 3.2.3.3. 检查接口、存储和通信

• 3.2.3.4. 从外向内（从最易暴露的攻击面到最有价值的资产）审查，这也是态度坚决的攻击者会做出的尝试

• 3.2.3.5. 评估设计中明确的安全问题的解决程度

• 3.2.3.6. 如果需要，指出关键的保护措施，并在设计中将它们标注为重要特性

• 3.2.4. 与设计师合作，识别风险并讨论缓解措施

• 3.2.4.1. 审查员要针对风险及其缓解措施提供安全性见解

• 3.2.4.2. 勾画出一个场景，以说明安全更改能够获得的最终回报，从而帮助说服设计师在设计中添加缓解措施

• 3.2.4.3. 尽可能为问题提供多个解决方案，并帮助设计师了解这些替代方案的优势和劣势

• 3.2.4.4. 要接受设计师的决定，因为他们要对设计负最终责任

• 3.2.4.5. 记录交流的想法，包括设计中会涵盖或者不会涵盖的内容

• 3.2.5. 撰写一份审查结果和建议的评估报告

• 3.2.5.1. 审查结果是安全审查员对设计安全性的评估

>  3.2.5.1.1. 要考虑的潜在设计更改，以及对设计安全性的分析

>  3.2.5.1.2. 应该在显著位置对设计师已经同意的更改进行标识，并在以后进行验证

• 3.2.5.2. 围绕着解决安全风险的特定设计变更来组织报告

• 3.2.5.3. 将大部分精力和笔墨花费在优先级最高的问题上，而在较低优先级的问题上少着笔墨

>  3.2.5.3.1. 必须(must)的排名最高，表示对于这一点来说，应该没有其他选择，并且通常还包含紧迫性

>  3.2.5.3.2. 需要(ought)排名中间，我用它来表示倾向于“必须”​，但我们可以进行讨论的更改

>  3.2.5.3.3. 应该(should)在可选的推荐更改中排名最低

• 3.2.5.4. 提出替代方案和策略，而不要尝试做该由设计师做的工作

• 3.2.5.5. 对审查的发现和建议进行优先级排序

• 3.2.5.6. 关注安全性，但也可以提供单独的评论以供设计师参考

>  3.2.5.6.1. 要对SDR范围之外的设计更为尊重，不要吹毛求疵，避免淡化安全性信息

• 3.2.5.7. 将设计师和审查员的角色分离至关重要，但在实践中，实现这一点的做法会有很大的不同，这取决于每个人的职责和他们的协作能力

• 3.2.5.8. 很有可能你或其他从事该软件工作的人员在日后会希望有详细记录的信息以供参考

• 3.2.5.9. 作为审查员，当你与软件设计师密切合作时，你可能可以将所需的更改直接合并到设计文档中，而不是在报告中列举需要更改的问题

• 3.2.6. 跟进后续的设计变更，在签署前确认解决方案

• 3.2.6.1. 对安全审查做出的设计变更结果进行跟进，以确认这些问题已被正确地解决

• 3.2.6.2. 对于重大的安全设计更改，你可能希望与设计师协作以确保正确地进行更改

• 3.2.6.3. 如果意见不同，审查员应该书写一份声明，说明双方的立场和未遵循的具体建议，并将其标记为未解决的问题

• 3.2.6.4. 在最好的情况下，设计师会将审查员视为安全辅助资源，并使其随着时间的推移继续参与到项目中

4. 评估设计的安全性

4.1. 4个问题

• 4.1.1. 我们的工作是什么？

• 4.1.1.1. 审查员应该了解设计的整体目标，并将其作为审查的背景，即思考实现这个目标最安全的方法是什么

• 4.1.1.2. 可以自信地建议割舍那些会带来风险且实际上并不必要的部分

• 4.1.2. 哪里有可能出错？

• 4.1.2.1. “安全帽”思想的用武之地，也是应用威胁建模的地方，即思考这个设计是否未能预见或低估了关键威胁

• 4.1.2.2. 设计师仅仅意识到这些威胁是不够的，他们必须已经确实创造了一种能够承受这些威胁的设计

• 4.1.3. 我们打算怎么办？

• 4.1.3.1. 审查你在设计中发现的保护机制和缓解措施，即思考我们能否以更好的方式应对重要威胁

• 4.1.3.2. 随着审查员的研究，设计中的安全保护机制和缓解措施应该变得清晰

• 4.1.3.3. 如果在减小安全风险方面设计做得不够，那么你应该逐项列出设计中缺少的内容

• 4.1.3.4. 当设计中确实为给定的威胁提供了缓解措施时，审查员需要评估缓解措施的有效性，并考虑是否有更好的替代方案

• 4.1.4. 我们干得怎么样？

• 4.1.4.1. 评估设计中的缓解措施是否足够，是否需要更多工作，或者是否缺少了一些缓解措施，即思考设计的安全性如何，如果缺乏安全性，我们如何才能使其达到安全标准

• 4.1.4.2. SDR可以快速识别出问题和机会，或者至少能够为现在值得考虑的权衡决策提出建议

>  4.1.4.2.1. 以后你将无法如此轻松地进行更改

• 4.1.4.3. 总结

>  4.1.4.3.1. 认为设计是安全的，没有需要更改的地方

>  4.1.4.3.2. 设计是安全的，但建议进行一些更改，以增强其安全性

>  4.1.4.3.3. 对当前的设计有疑虑，并提供了一些建议，以增强其安全性

4.2. 针对大型设计的每个角落都进行深入研究是不切实际的，因此审查员需要尽快关注那些对安全至关重要的领域

• 4.2.1. 审查员要留意攻击面，并给予其应有的重视

• 4.2.2. 攻击面越容易访问，就越有可能成为潜在的攻击源，典型的最坏情况就是匿名的互联网暴露

4.3. 根据你的技能和组织机构职责，你可能希望在SDR范围内处理信息隐私，或单独处理

4.4. 软件一旦发布，似乎就有了自己的生命，随着时间的推移，变化是不可避免的

• 4.4.1. 设计文档应该是一个能够跟踪软件架构形式演变的动态文档

• 4.4.2. 版本化的文档提供了设计成熟度的重要记录，或者在设计变得复杂时提供了重要记录

5. 处理分歧

5.1. 良好的人际沟通对于成功执行SDR至关重要

5.2. SDR在本质上具有对抗性，因为审查员通常会在人们投入了巨资的设计中指出其风险和潜在的缺陷

5.3. 一旦设计师理解了问题，他们通常会开始讨论那些审查员可能错过的其他领域

5.4. 有人指出自己设计中的漏洞，是了解安全性的最佳方式

5.5. 在SDR过程中，我们无法通过单方面的演讲来强调安全是所有事务中的重中之重

5.6. 准备SDR会议是一种平衡行为

• 5.6.1. 事先准备的问题，以便会面时你能够深挖安全问题

• 5.6.2. 你可以自己找到答案的问题

• 5.6.3. 最好在会议中探讨的主题

• 5.6.4. 你将在评估报告中包含的观察结果，但不需要对其进行讨论

5.7. 一个好的经验法则是，如果缺失的信息对许多人都有用，则值得记录这个信息，但如果它仅与你的特定需求相关，那么你应该不那么正式地提出这个问题

• 5.7.1. 如有必要，你可以在评估报告中包含这些问题的详细信息

5.8. 在完成这次SDR后，产品团队对安全性有了更好的理解，进而对他们自己的产品也有了更深入的了解

5.9. 当设计师和审查员未能达成共识时，他们应该对分歧达成共识

• 5.9.1. 强烈的分歧几乎总是源于基本假设的南辕北辙，一旦确定了基本假设，分歧通常会被解决

• 5.9.2. 产生严重分歧的另一个主要原因是设计师没有意识到数据机密性或完整性的重要性，这通常是因为他们没有站在最终用户的视角，或者没有考虑所有可能的用例