读软件开发安全之道：概念、设计与实施10安全设计审查

最新推荐文章于 2024-08-27 13:48:21 发布

躺柒

最新推荐文章于 2024-08-27 13:48:21 发布

阅读量511

点赞数 3

分类专栏：读软件开发安全之道：概率、设计与实施文章标签：安全网络网络安全信息安全软件安全

本文链接：https://blog.csdn.net/lyingSeven/article/details/141555694

版权

读软件开发安全之道：概率、设计与实施专栏收录该内容

11 篇文章 0 订阅

订阅专栏

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. 对当前的设计有疑虑，并提供了一些建议，以增强其安全性