安全合规-软件安全开发过程规范_第1页
安全合规-软件安全开发过程规范_第2页
安全合规-软件安全开发过程规范_第3页
全文预览已结束

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

安全开发过程规范安全开发过程规范 一 SDL 简介 SDL security development lifecycle 安全开发生命周期 是微软提出的从安全角度指导软 件开发过程的管理模式 SDL 是一个安全保证的过程 起重点是软件开发 它在开发的所 有阶段都引入了安全和隐私的原则 自 2004 年起 SDL 一直都是微软在全公司实施的强制 性策略 二 SDL 步骤图 SDL 中的方法 试图从安全漏洞产生的根源上解决问题 通过对软件工程的控制 保证产 品的安全性 美国国家标准与技术研究所 NIST 估计 如果是在项目发布后在执行漏洞修复计划 其 修复成本相当于在设计阶段执行修复的 30 倍 三 SDL 的步骤包括 阶段 1 培训 开发团队的所有成员都必须接受适当的安全培训 了解相关的安全知识 培训对象包括开 发人员 测试人员 项目经理 产品经理等 阶段 2 安全要求 在项目确立之前 需要提前与项目经理或者产品 owner 进行沟通 确定安全的要求和需要 做的事情 确认项目计划和里程碑 尽量避免因为安全问题而导致项目延期发布 阶段 3 质量门 bug 栏 质量门和 bug 栏用于确定安全和隐私质量的最低可接受级别 Bug 栏是应用于整个开发项目的质量门 用于定义安全漏洞的严重性阈值 例如 应用程 序在发布时不得包含具有 关键 或 重要 评级的已知漏洞 Bug 栏一经设定 便绝不 能放松 阶段 4 安全和隐私风险评估 安全风险评估 SRA 和隐私风险评估 PRA 是一个必需的过程 必须包括以下信息 1 安全 项目的哪些部分在发布前需要威胁模型 2 安全 项目的哪些部分在发布前需要进行安全设计评析 3 安全 项目的哪些部分需要并不食欲项目团队且双方认可的小组进行渗透测试 4 安全 是否存在安全顾问认为有必要增加的测试或分析要求已缓解安全风险 5 安全 模糊测试要求的具体范围是什么 6 安全 隐私影响评级如何 阶段 5 设计要求 在设计阶段应仔细考虑安全和隐私问题 在项目初期确定好安全需求 尽可能避免安全引 起的需求变更 阶段 6 减小攻击面 减小攻击面与威胁建模紧密相关 不过它解决安全问题的角度稍有不同 减小攻击面通过 减小攻击者利用潜在弱点或漏洞的机会来降低风险 减小攻击面包括 关闭或限制对系统 服务的访问 应用 最小权限原则 以及尽可能进行分层防御 阶段 7 威胁建模 为项目或产品面临的威胁建立模型 明确可能来自的攻击有哪些方面 阶段 8 使用指定的工具 开发团队使用的编辑器 链接器等相关工具 可能会涉及一些安全相关的环节 因此在使 用工具的版本上 需要提前与安全团队进行沟通 阶段 9 弃用不安全函数 许多常用函数可能存在安全隐患 应当禁用不安全的函数和 API 使用安全团队推荐的函 数 阶段 10 静态分析 代码静态分析可以由相关工具辅助完成 其结果与人工分析相结合 阶段 11 动态程序分析 动态分析是静态分析的补充 用于测试环节验证程序的安全性 阶段 12 模糊测试 Fuzzing Test 模糊测试是一种专门形式的动态分析 它通过故意向应用程序引入不良格式或随机数据诱 发程序故障 模糊测试策略的制定 以应用程序的预期用途 以及应用程序的功能和设计 规范为基础 安全顾问可能要求进行额外的模糊测试 或者扩大模糊测试的范围和增加持 续时间 阶段 13 威胁模型和攻击面评析 项目经常会因为需求等因素导致最终的产出偏离原本设定的目标 因此在项目后期对威胁 模型和攻击面进行评析是有必要的 能够及时发现问题并修正 阶段 14 事件响应计划 受 SDL 要求约束的每个软件在发布时都必须包含事件响应计划 即使在发布时不包含任何 已知漏洞的产品 也可能在日后面临新出现的威胁 需要注意的是 如果产品中包含第三 方的代码 也需要留下第三方的联系方式并加入事件响应计划 以便在发生问题时能够找 到对应的人 阶段 15 最终安全评析 最终安全评析 FSR 是在发布之前仔细检查对软件执行的所有安全活动 通过 FSR 将得出 以下三种不同不同结果 1 通过 FSR 在 FSR 过程中确定所有安全和隐私问题都已得到修复或缓解 2 通过 FSR 但有异常 在 FSR 过程中确定所有安全和隐私问题都已得到修复或缓解 并 且 或者所有异常都已得到圆满解决 无法解决的问题将记录下来 在下次发布时更正 3 需上报问题的 FSR 如果团队未满足所有 SDL 要求 并且安全顾问和产品团队无法达 成可接受的折中 则安全顾问不能批准项目 项目不能发布 团队必须在发布之前解决所 有可解决的问题 或者上报高级管理层进行抉择 阶段 16 发布 存档 在通过 FSR 或者虽有问题但达成一致后 可以完成产品的发布 但发布的同时仍需对各种 问题和文档进行存档 为紧急响应和产品升级提供帮助 从以上的过程可以看出 微软的 SDL 的过程实施非常细致 微软这些年来也一直帮助公司 的所有产品团队 以及合作伙伴实施 SDL 效果相当显著 相对于微软的 SDL OWASP 推出了 SAMM Software Assurance Maturity Model 帮助开 发者在软件工程的过程中实施安全 SAMM 与 SDL 的主要区别在于 SDL 适用于软件开发商 他们以贩售软件为主要业务 而 SAMM 更适用于自主开发软件的使用者 如银行或在线服务提供商 软件开发商的软件工 程往往较为成熟 有着严格的质量控制 而自主开发软件的企业组织 则更强调高效 因 此在软件工程的做法上也存在差异 四 SDL 实战经验准则 准则一 与项目经理进行充分沟通 排除足够的时间 准则二 规范公司的立项

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论