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

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. 审查结果是安全审查员对设计安全性的评估
  

1. >  3.2.5.1.1. 要考虑的潜在设计更改，以及对设计安全性的分析
3. >  3.2.5.1.2. 应该在显著位置对设计师已经同意的更改进行标识，并在以后进行验证

复制代码

• 3.2.5.2. 围绕着解决安全风险的特定设计变动来组织报告
  
• 3.2.5.3. 将大部分精力和笔墨花费在优先级最高的问题上，而在较低优先级的问题上少着笔墨
  

1. >  3.2.5.3.1. 必须(must)的排名最高，表示对于这一点来说，应该没有其他选择，并且通常还包含紧迫性
3. >  3.2.5.3.2. 需要(ought)排名中间，我用它来表示倾向于“必须”​，但我们可以进行讨论的更改
5. >  3.2.5.3.3. 应该(should)在可选的推荐更改中排名最低

复制代码

• 3.2.5.4. 提出替代方案和策略，而不要实验做该由设计师做的工作
  
• 3.2.5.5. 对审查的发现和建议举行优先级排序
  
• 3.2.5.6. 关注安全性，但也可以提供单独的评论以供设计师参考
  

1. >  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可以快速识别出问题和机会，或者至少可以或许为如今值得考虑的权衡决策提出建议
  

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

复制代码

• 4.1.4.3. 总结
  

1. >  4.1.4.3.1. 认为设计是安全的，没有需要更改的地方
3. >  4.1.4.3.2. 设计是安全的，但建议进行一些更改，以增强其安全性
5. >  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. 产生严重分歧的另一个主要原因是设计师没有意识到数据机密性或完整性的告急性，这通常是因为他们没有站在最终用户的视角，或者没有考虑所有可能的用例
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。