安全开发生命周期详解（SDL：SecurityDevelopmentLifecycle）.pdf

安全开发⽣命周期详解 （SDL ： SecurityDevelopmentLifecycle） SDL ：Security Development Lifecycle 安全开发⽣命周期 训 要求 设计 实施 验证 发布 响应 确定安全要求 确定设计要求 使⽤批准的⼯具 动态分析 事件响应计划 核⼼安全 训 创建质量门/错误标尺 分析攻击⾯ 弃⽤不安全的函数 模糊测试 最终安全评析 执⾏事件响应计划 安全和隐私风险评估 威胁建模 静态分析 攻击⾯评析 发布存档 1、 训 训对象 ：开发⼈员、测试⼈员、项 ⽬经理、产品经理 训内容 ：安全设计、威胁建模、安全编码、安全测试、隐私等 2、安全要求 项 ⽬确⽴前与项 ⽬经理或产品所有者进⾏沟通，确定安全的要求。 3、质量门/bug 栏 质量门和 bug 栏⽤于确定安全和隐私质量的最低可接受级别。项 ⽬团队必须协商确定每个开发阶段的质量门。bug 栏是应⽤于整个软件开 发项 ⽬的质量门，⽤于定义安全漏洞的严重性阈值。 4、安全和隐私风险评估 安全风险评估 （SRA）和隐私风险评估 （PRA）⽤于确定软件中需要深⼊评析的功能环节。包括 ① 项 ⽬的哪些部分在发布前需要建⽴威胁 模型？② 哪些部分在发布前需要进⾏安全设计评析？③ 哪些部分需要由不属于项 ⽬团队且双⽅认可的⼩组进⾏渗透测试？④ 是否存在安全 顾问认为有必要增加的测试或分析？⑤ 模糊测试的具体范围？⑥ 隐私对评级的影响。 5、设计要求 在设计阶段仔细考虑安全和隐私问题。 6、减⼩攻击⾯ 减⼩攻击⾯与威胁建模紧密相关。它通过减少攻击者利⽤潜在弱点或漏洞的机会来降低风险，包括关闭或限制对系统服务的访问，应⽤ “最 ⼩权限原则”，尽可能分层防御。 7、威胁建模 微软的 STRIDE 模型 8、使⽤指定的⼯具 开发团队使⽤的编译器、链接器等⼯具及其版本应由安全团队确定安全性。 9、弃⽤不安全的函数 禁⽤不安全的函数或 API 10、静态分析 可以由⼯具辅助完成 11、动态分析 在测试环节验证程序安全性 12、模糊测试 模糊测试是⼀种特定的动态分析⽅法，通过故意向应⽤程序引⼊不 良格式或随机数据诱发程序故障。测试策略的制定以应⽤程序的预期⽤ 途、功能、设计规范为基础。 13、威胁模型和攻击⾯评析 项 ⽬因需求变更等因素导致最终产出偏离原定⽬标，为此项 ⽬后期有必要对威胁模型和攻击⾯进⾏重新评析。 14、事件响应计划 每个软件在发布时都必须包含事件响应计划。尤其如果产品中包含第三⽅的代码，要求留下第三⽅的联系⽅式并加⼊事件响应计划。 15、最终安全评析 在产品发布之前对软件执⾏的安全活动。 16、发布/存档 在通过最终安全评析后可以完成产品的发布。同时，对各类问题和⽂档进⾏存档，为紧急响应和产品升级提供帮助。 SAMM：Software Assurance Maturity Model，OWASP 推出的软件认证成熟模型 SDL 适⽤于软件开发商，他们以贩售软件为主要业务 ；SAMM 适⽤于⾃主研发软件的组织，如银⾏、在线服务提供商。软件开发商的软件 ⼯程⽐较成熟，有严格的质量控制 ；⽽ ⾃主开发软件的企业组织更强调效率。 敏捷 SDL 对于使⽤敏捷开发的团队，需求和功能⼀直在变化，代码也在发⽣变化，这要求在实施 SDL 的过程中在每个阶段更新威胁模型和隐私策 略，在必要的缓解迭代模糊测试、代码安全分析等⼯作。 互联⽹公司 SDL 实践经验 准则⼀、与项 ⽬经理进⾏充分沟通，排出⾜够时间 准则⼆、规范公司的⽴项流程，确保所有项 ⽬都能通知到安全团队，避免遗漏 准则三、树⽴安全部门的权威，项 ⽬必须由安全部门审核完成后才能发布 准则四、将技术⽅案写⼊开发、测试的⼯作⼿册中 准则五、给⼯程师 训安全⽅案 准则六、记录所有的安全 bug，激励程序员编写安全的代码 产品研发阶段的安全 需求分析与设计阶段 需求分析阶段可以对项 ⽬经理，产品经理或架构师进⾏访谈，了解产品背景和技术架构，并给出相应的建议。 应该了解项 ⽬中是否包含了第三⽅软件，认真评估第三⽅软件是否存在安全问题。规避第三⽅软件带来的安全风险。 开发阶段 提供安全的函数 OWASP 的开源项 ⽬