跳转至

微软SDL

写在前面

本文基于《Simplified Implementation of the Microsoft SDL》和微软SDL官方文档 2018/6/1对微软SDL的学习总结，某些点加入了自身的解读，对于不理解的地方，也收集了相关的材料，相关引用都进行了说明，希望尽可能对SDL有个全面的认识。
但SDL是一个庞大的工程，涉及到软件开发的各个阶段，对于部分的理解如果存在错误，还请各位给予指正。

概述

SDL是一套管理方法论，采用工程化的方法，确保软件的安全。
微软SDL( Security Development Lifecycle)是第一个将理论和实践相结合的安全开发框架，在2002年提出(标志性事件Bill Gates' TwC memo)，到2004年在微软全世界100多个国家和地区的微软团队，成百上千微软产品的开发流程中实施落地，并且对新的场景如云、IoT、AI等在持续的补充和完善，在微软sdl官方网站，经常能看到微软发布的新的SDL流程中需要的安全工具。可以说微软SDL是安全开发框架，是任何做软件开发安全团队学习的宝典，其中很多思想和实践奠定了整个软件安全开发的基石。

概括起来，微软的SDL，就是:
一个目标: 安全和隐私 -> 降低开发成本
三个核心: 教育、持续过程改善和责任
五功能: 培训、政策和组织功能;要求和设计;实施;验证;发布和响应
十六过程: 确定安全要求、创建质量门/Bug栏、安全和隐私风险评估、确定设计要求、分析攻击面、威胁建模、使用批准的工具、弃用不安全的函数、静态分析、动态分析、模糊测试、攻击面评析、事件响应计划、最终安全评析、发布存档、执行事件响应计划
四度量: 基本(几乎或完全没有任何过程、培训和工具)、标准化、高级、动态(高效的过程、训练有素的人员、专用工具以及组织内部和外 部各方的强烈责任感)
分层实施: 现状调研-(软件开发成熟度:组织、资源、高管支持),制定可行的执行路径(必选活动和可选活动),分阶段实施落地

注:微软强调的安全与隐私具体指什么?可以参见比尔盖茨 在2002年（9.11之后的第一年）写的TwC memo
可用性：我们的产品应在客户需要时随时可用。由于支持冗余和自动恢复的软件体系结构，系统中断应该成为过去。自我管理应允许在几乎所有情况下在无需用户干预的情况下恢复服务。
安全性：我们的软件和服务代表我们的客户存储的数据应受到保护，不受损害，并仅以适当的方式使用或修改。安全模型应该易于开发人员理解并构建到他们的应用程序中。
隐私：用户应控制其数据的使用方式。信息使用策略应该对用户明确。用户应控制何时以及是否接收信息，以充分利用其时间。用户应易于指定其信息的适当用途，包括控制其发送的电子邮件的使用。

微软SDL介绍

SDL背景

业务飞速发展，安全问题层出不穷
业务飞速发展: 当时windows已经处于垄断地位，在操作系统基础上推出了Office办公软件、IE浏览器、IIS、SQL server等软件，随着微软开发软件的大规模普及，世界各地的黑客也把注意力集中到了微软开发的软件身上。
安全问题层出不穷:当时由于软件普及度极高，因此微软面临着空前的安全压力。这种压力促使微软开始关注自身软件的安全性，而且从技术层面已经无法完全杜绝安全问题。
最有代表性的是2003年爆发的冲击波病毒(病毒运行时会不停地利用IP扫描技术寻找网络上系统为Win2000或XP的计算机，找到后就利用DCOM/RPC缓冲区漏洞攻击该系统，一旦攻击成功，病毒体将会被传送到对方计算机中进行感染，使系统操作异常、不停重启、甚至导致系统奔溃)

因此,微软开始从流程和管理上关注安全问题，探索能否借鉴软件工程的经验，在软件开发的各个环节中加入安全的流程，在每个软据开发环节对安全风险进行把控，确保每个环节交付到下一环节的交付物都是安全可控的，于是在微软产生了软件安全开发周期(Security Development Lifecycle) 概念。

SDL核心概念

安全开发生命周期(SDL)是侧重于软件开发的安全保证过程。在微软，自2004起，SDL做为全公司(全世界100多个国家/地区的微软团队)的计划和强制政策，在将安全和隐私植入软件和企业文化方面发挥了重要作用，已应用于成百上千的微软产品。SDL主要目标减少软件中漏洞的数量和缓解漏洞影响(注:通过SDL安全左移了，让开发边写代码，边发现漏洞，边修复漏洞，自然漏洞就少了，在架构设或系统上线部署等环节的安全防御机制，让利用更难了，原来写了一个SQL没有waf，可能直接就被脱裤了。有了waf就不是随便的攻击者都能攻击成功了，从某种意义上，缓解了漏洞影响)。SDL是在开发过程的所有阶段中均引入了安全和隐私

微软SDL基于三个核心概念 - 教育、持续过程改善和责任。 安全是每个人的工作，每个人都背负着安全的职责是SDL基本前提，需要通过培训教育不断的传达给项目组所有人。安全风险是动态变化的需要研究分析安全漏洞的原因，定期评估SDL过程并随着新技术的发展和新威胁引入应对措施。

SDL优化模型

SDL的成功还是失败取决于组织规模、资源(时间、人才和预算)以及高层支持等因素。需要根据开发团队的成熟度水平确定实施优先级。

SDL优化模型围绕五个功能领域构建:

  • 培训、政策和组织功能
  • 要求和设计
  • 实施
  • 验证
  • 发布和响应

SDL优化模型还定义了四个成熟度水平 - 基本、标准化、高级和动态
SDL优化模型从基本成熟度水平(几乎或完全没有任何过程、培训和工具)开始，发展到动态水平(整个组织完全遵循SDL)。完全遵循SDL包括高效的过程、训练有素的人员、专用工具及组织内部和外部各方的强烈责任感。

SDL适用性

按照官方文档，微软SDL可以适用于任何企业组织。在具体使用过程中，可以根据企业实际情况进行拆解，尝试，最终探索出，适合企业自身的安全开发流程，目标是一致的。 组织各个相同，开发团队应以适合与可用的人才和资源的方式实施SDL, 但是不能危害组织的安全目标。

SDL角色分工

没有找到特别详细的SDL角色分工，只看到安全顾问和安全负责人角色，安全顾问有决策权，可以通过或拒绝项目上线，而安全负责人更像是安全审计员，负责跟进每个项目，进行具体的测试工作，发现每个项目中的安全漏洞，反馈给研发团队或者项目负责人。 更加具体SDL角色分工大家可以参考美团分享的SDL实践 RASCI 美团:实践之后，我们来谈谈如何做好威胁建模
最核心内容是"Two-Pizza Teams"(团队应该以2个披萨就能吃饱的人数为最佳，一般是在10人左右 - 亚马逊理论), 保持沟通是构建安全产品的诀窍，实施威胁建模的效果。

简化的SDL安全活动

SDL最核心的目标是解决安全与隐私，给出的手段是微软的探索实践，所以企业在做SDL时，最核心的关注每个阶段产生的输出质量和完整性，不要过于强调过程，比如威胁建模,通过与开发团队进行白板会议产生威胁模型，在Word文档中以叙述形式描述威胁模型，或者使用专用工具(如SDL威胁建模工具)生成威胁模型。投资于高效的工具和自动化，的确会使SDL过程受益，但其实际价值在于可以获得全面而准确的结果。

必需的安全活动

培训

Security is everyone's job. 第一句是多么的简单的英文，相信任何人都能看懂，"安全是每个人的工作"。而在国内的现实，几乎所有人(甚至包括安全自己人)都认为安全是安全部门的工作，其后的工作阻力，无法落地，就可想而知了。 应该从全局的角度去思考，项目的团队每个成员的共同目标是开发安全、高效、可维护的系统。
这更像是一种企业文化，需要自上而下和自下而上的去推动。上到下是要确定规范，写入制度，是整个事件的前提，在实施的过程中，安全也需要能够真正为业务服务，帮助业务发现问题，给出合理的解决方案，体现自身价值。
整体的目标: 也充分体现了分级的思想，并不是每个人都想成为安全专家或渗透测试专家，所以培训课程应该是分层次的
基础意识:让大家都知道攻击者的观点、目标、可能使用的攻击方法等
技能培训: 针对研发人员，的技能培训
专家培训: 有很多优秀的人，希望学习更多
微软强调培训应覆盖:安全设计(减小攻击面、深度防御、最小权限、安全默认设置)、威胁建模(概述、设计及编码约束) 、安全编码(缓冲区、整数算法、SQL注入)、弱加密安全测试(安全测试与功能测试区别、风险评估、安全测试方法)、隐私(隐私敏感数据的类型、隐私设计最佳实践、隐私测试最佳实践)

要求

  • 定义安全需求
    意义:"预先"考虑安全与隐私，给项目预留足够的时间，确定关键里程碑和交付成果，不影响整体排期。
    安全需求与隐私:法律法规、行业要求、内部标准、编码实践、以前出现过的安全事件、已知威胁
    在这个阶段给了相对比较明确的方向，需要在开发之前就将安全需求在团队普及，这个是最佳宣传时间，成本与阻力最小。
    业务开始之前就要考虑业务的法律风险，信息数据是一个容易违法的功能。比如近几年频发的因使用网络爬虫获取数据而获刑的案件，网络爬虫业务已经是一个违法的业务，应该及时遏制,和个人违规收集遭到通报等
    我国相继出台了<网安法><数安法><个人信息保护法><关基条例>及<等级保护>，已经比较明确了相关保护要求。如果一个系统在开发初，就计划通过等保3级或就可能是关基系统，那在业务开始前，就要对照等保和关基进行建设。以便最终测评时，返工整改，浪费时间。
    外采服务是法律和安全的集合体，优选国产、规定安全义务是必备
    企业自身制定的安全需求，上线红线制度

  • 定义度量和合规报告 （质量门/Bug栏)
    bug栏，应该就是我们日常说的红线(最低可接受级别)，有严重漏洞不允许上线这些，并且给了一个隐私参考文档，具体位置查看官方，防止链接失效
    有高危漏洞禁止上线
    代码符合编码规范(代码质量报警要修复)

  • 安全与隐私风险评估
    安全风险评估(SRA)和隐私风险评估(PRA)是必需的过程，主要内容:
    哪些部分需要威胁建模?
    哪些部分需要进行渗透测试?
    隐私影响评级如何?

设计

  • 设计要求
    安全功能实现有时是非常复杂的，因此需要建立统一的标准，比如身份、认证、加密基础要求 安全的功能为在安全方面进行了完善设计的功能，比如在处理之前对所有数据进行严格验证或通过加密方式可靠地实现加密服务库。 安全功能描述具有安全影响的程序功能，如Kerberos身份验证或防火墙。

  • 减小攻击面
    减小攻击面通过减少攻击者利用潜在弱点或漏洞的机会来降低风险。减小攻击面包括关闭或限制对系统服务的访问、应用最小权限原则以及尽可能进行分层防御。

  • 威胁建模
    "应在存在重大安全风险的环境中使用威胁建模 ", 就是威胁建模应该有个前提，并不能所有项目都进行威胁建模，或者说不需要威胁建模。威胁建模是SDL的核心。
    5个核心步骤:定义安全需求、创建服务交互图、识别风险、缓解风险、验证所有威胁已经备处理。
    4部分:数据流图、威胁识别、缓解措施、安全验证

实施

  • 使用批准的工具
    保持开发环境比如编译器/连接器的更新，开启最新安全防护机制等

  • 弃用不安全的函数(定义和使用加密标准)
    加密非常的重要，安全专家应该建立组织能够使用的加密标准，优选选择被认证过的加密算法

  • SAST
    对源代码进行扫描，确保安全。需要根据组织特性选择最佳的SAST检测点，可以是IDE插件，实时提醒研发使用不安全函数，给出替代方案，或者在提交代码到仓库时，进行代码增量扫描，或者上线前统一进行代码全量扫描。没有最好只有最适合。静态代码分析本身通常不足以替代人工代码评析。

  • 管理第三方组件安全风险(笔者添加的)
    重要性不言而喻，微软官方还给了一些参考，比如分析组件、保持更新，建立应急计划

验证

  • DAST
    与SAST一样，寻找最佳扫描时间

  • 模糊测试
    一种专门形式的动态分析，它通过故意向应用程序引入不良格式或随机数据诱发程序故障。模糊测试策略的制定以应用程序的预期用途以及应用程序的功能和设计规范为基础。安全顾问可能要求进行额外的模糊测试或扩大模糊测试的范围和增加持续时间。

  • 威胁模型和攻击面评析
    应用程序经常会严重偏离在软件开发项目要求和设计阶段所制定的功能和设计规范。因此，在给定应用程序完成编码后重新评析其威胁模型和攻击面度量是非常重要的。此评析可确保考虑到对系统设计或实现方面所做的全部更改，并确保因这些更改而形成的所有新攻击平台得以评析和缓解(实现与设计是否一致)

发布

  • 事件响应计划
    受 SDL 要求约束的每个软件发布都必须包含事件响应计划。即使在发布时不包含任何已知漏洞的程序也可能面临日后新出现的威胁。
    事件响应计划应包括：
    单独指定的可持续工程 (SE) 团队；或者，如果团队太小以至于无法拥有 SE 资源，则应制定紧急响应计划 (ERP)，在该计划中确定相应的工程、市场营销、通信和管理人员充当发生安全紧急事件时的首要联系点。
    与决策机构的电话联系（7 x 24 随时可用）。
    针对从组织中其他小组继承的代码的安全维护计划。
    针对获得许可的第三方代码的安全维护计划，包括文件名、版本、源代码、第三方联系信息以及要更新的合同许可（如果适用）。

  • 最终安全评析(FSR)
    通常要根据以前确定的质量门或 Bug 栏检查威胁模型、异常请求、工具输出和性能。
    通过 FSR:在 FSR 过程中确定的所有安全和隐私问题都已得到修复或缓解。
    通过 FSR 但有异常:在 FSR 过程中确定的所有安全和隐私问题都已得到修复或缓解，并且/或者所有异常都已得到圆满解决。无法解决的问题（例如，由以往的“设计水平”问题导致的漏洞）将记录下来，在下次发布时更正。
    需上报问题的 FSR:如果团队未满足所有 SDL 要求，并且安全顾问和产品团队无法达成可接受的折衷，则安全顾问不能批准项目，项目不能发布。团队必须在发布之前解决所有可以解决的 SDL 要求问题，或是上报给高级管理层进行抉择。

  • 发布/存档
    必须对所有相关信息和数据进行存档，以便可以对软件进行发布后维护。这些信息和数据包括所有规范、源代码、二进制文件、专用符号、威胁模型、文档、紧急响应计划、任何第三方软件的许可证和服务条款以及执行发布后维护任务所需的任何其他数据。

可选的安全活动

可选的安全活动通常在软件应用程序可能用于重要环境或方案时执行。这些活动通常由安全顾问在附加商定要求集中指定，以确保对某些软件组件进行更高级别的安全分析。本节中的实践可作为可选安全任务的示例，但不应将其视为详尽列表。

  • 人工代码评析
    代码审计、敏感数据处理、功能检查(加密实现)

  • 渗透测试
    模拟黑客发现威胁，修复漏洞
    在 Internet 上可以找到许多声誉良好的有关软件漏洞的信息来源。在某些情况下，通过对在类似软件应用程序中发现的漏洞进行分析，可以为发现所开发软件中的潜在设计或实现问题获得一些启迪

  • 相似应用程序的漏洞分析

其他过程要求

  • 根本原因分析
    了解漏洞产生的根本原因，以防止不在出现同类错误

  • 过程定期更新
    软件威胁不是一成不变的。因此，用于保护软件安全的过程也不能一成不变。组织应从各种实践（如根本原因分析、策略更改以及技术和自动化改进）中汲取经验教训，并将其定期应用于 SDL。一般而言，更新按年度进行应该足矣。发现以前未知的新漏洞类型属于此规则的例外情况。如果出现此现象，则须立即对 SDL 进行非常规修订，以确保在继续进行时已应用缓解措施

应用程序安全验证过程

开发安全软件的组织自然会需要一种途径来验证是否遵循了 Microsoft SDL 所规定的过程。访问集中的开发和测试数据有助于在许多重要方案（如最终安全评析、SDL 要求异常处理和安全审核）中进行决策

结束语

本文是一个基本框架，开发团队应以本文为指导，实施SDL的时候结合考虑组织的时间、资源和业务运营方式。
也许有人会说，即使只对安全过程进行简单的综合，也可以在整体上改进安全和隐私，这些改进会超越独立执行的任务的价值。然而，当前计算环境中的威胁已从脚本小子以前对自我满足感的追求演进为大范围有组织的金融犯罪，最近甚至演化为国家战争的新战场。威胁所经历的这种演进强烈要求采用某种比典型零散方法可靠得多的方法实现软件安全。

参考资料

如需PPT原版 可加入官方微信群领取

微软SDL官网资源

微软安全开发生命周期的简化实施
微软SDL 软件安全设计初窥http://www.github5.com/view/439
NIST 软件开发安全框架SSDF v1.0 2020
visualstudio安全插件

Back to top