通过

可信赖计算安全开发生命周期

  • 项目

Steve Lipner
Michael Howard
安全工程及通信
安全业务及技术部
Microsoft Corporation

摘要： 本文介绍可信赖计算安全开发生命周期（或 SDL），即 Microsoft 在开发需要抵御恶意攻击的软件时采用的一套流程。 该流程在 Microsoft 软件开发流程的每个阶段添加了一系列关注安全性的活动和交付结果。 这些活动和交付结果包括在软件设计过程中开发威胁模型、在实施过程中使用静态分析代码扫描工具以及在集中进行的“安全推动”过程中进行代码审核和安全测试。 应用 SDL 的软件在发布之前，必须由独立于开发小组的另一个小组执行最终安全审核。 与未应用 SDL 的软件相比，应用了 SDL 的软件从外部发现其安全漏洞的机率显著降低。 本文介绍 SDL 并讨论了在 Microsoft 软件开发过程中实施该流程的经验。

注意 本文是 2004 计算机安全应用年会上发表的”可信赖计算安全开发生命周期“一文的更新版本，这次大会由 IEEE 主办，已于 2004 年 12 月在亚利桑那州图森市举行。

本页内容
  1. 简介
  2. 安全开发生命周期流程
  3. Microsoft 实施安全开发生命周期的情况
  4. Microsoft 实施安全开发生命周期的成果
  5. 应用安全开发生命周期的观察
  6. 结论
  7. 感谢
  8. 参考文献
  9. 注意事项

1. 简介

所有软件供应商都有必要解决安全威胁方面的问题。 对软件供应商来说，安全性是其核心要求，这是由市场力量所驱动，也是由保护关键基础结构及建立和保持计算的广泛信任的需要所决定的。 所有软件供应商面对的一个主要挑战就是创建更加安全的软件，使其不需要频繁地通过修补程序进行更新，且需要进行的安全管理工作也更少。

对于软件行业来说，要满足当今提升安全性的需要，关键在于实施可重复的流程，通过这些流程可靠地实现可测量的安全性提升。 因此，软件供应商必须转为采用一种更严格的、更加关注安全性的软件开发流程。 这种流程旨在尽量减少设计、编码和文档编写过程中存在的漏洞，并在开发生命周期中尽可能早地检测到并消除这些漏洞。 用于处理来自 Internet 的输入、控制可能被攻击的关键系统或处理个人身份信息的企业和消费者软件最需要实施这种流程。

构建更安全的软件可从三个方面着手：可重复的流程、工程师教育以及度量标准和可测量性。 本文档重点介绍 SDL 的可重复流程方面，虽然也讨论了工程师教育并提供了反映目前部分应用 SDL 的影响的一些总体指标。

如果参照 Microsoft 的经验，其他组织采用 SDL 应该不会为软件开发增加不合理的成本。 根据 Microsoft 的经验，提供更安全的软件的益处（例如，更少的补丁和更加满意的用户）超过付出的代价。

SDL 会集成一些有助于提升软件安全性的措施，在此过程中可能需要对软件开发组织的流程进行调整。 本文档概述了这些措施，并说明了将其集成到典型的软件开发生命周期中的方法。 进行这些调整的目的不是要完全改变开发流程，而是在开发流程中加入一些精心定义的安全检查点和安全性交付结果。

本文假定公司（或软件开发组织）中存在一个中央小组，该小组致力于推动最佳安全做法的制订与改进和流程优化，为整个组织提供专家意见，并在软件发布前对其进行审核（最终安全审核或 FSR）。 根据 Microsoft 的经验，设立这样一个组织对成功实施 SDL 和提升软件安全性十分重要。 可能有些组织会考虑由承包商或顾问担任“中央安全小组”角色。 本文介绍如何将旨在提升软件安全性的一系列步骤集成到大型软件开发组织通常使用的软件开发流程中。 Microsoft 设计并实施了这些步骤，作为其可信赖计算计划的一部分。 这些流程改进的目标是减少用户使用的软件中安全漏洞的数量并降低安全漏洞的严重程度。 在本文中，这种经过调整的软件开发流程，即当前在 Microsoft 实施的流程被称为可信赖计算软件开发生命周期（或简称为 SDL）。

Microsoft 的经验是在软件设计和开发过程中必须经常与安全小组进行互动，并必须与其共享敏感的技术和商业信息。 由于以上原因，最好的解决方案是在软件开发组织内部建立一个安全小组（虽然可能有必要请顾问人员帮助建立小组和培训小组的成员）。

1.1 基本流程

在 Microsoft 普遍采用的软件开发流程大致如图 1 所示。 从更高层面上看，这也是行业内的典型流程。

ms995349.sdl_01_thumb(zh-cn,MSDN.10).gif

图 1. 标准的 Microsoft 开发流程

尽管图 1 显示了五个里程碑，看起来开发流程好像是“瀑布式”的，实际上该流程是螺旋形的。 为了对市场需求的变化和软件实施中遇到的实际情况做出反应，在实施阶段可能经常需要重新考虑需求和设计问题。 并且，该开发流程强调在几乎每个点都要提供运行代码，这样每个主要里程碑实际上分解为交付一系列构件，从而可以不断向前地测试和操作使用这些构件（由开发小组进行）。

1.2 安全开发生命周期概述

现实世界中的软件安全性方面的经验已经为构建更安全的软件建立了一套高标准的原则。 Microsoft 将这些原则称作 SD3+C – 设计安全、默认安全、部署安全和通信。 这些原则的简要定义如下：

  • 设计安全：在架构、设计和实现软件时，应使它在运行时能保护自身及其处理的信息，并能抵御攻击。

  • 默认安全：在现实世界中，软件达不到绝对安全，所以设计者应假定其存在安全缺陷。 为了使攻击者针对这些缺陷发起攻击时造成的损失最小，软件在默认状态下应具有较高的安全性。 例如，软件应在最低的必要权限下运行，非广泛需要的服务和功能在默认情况下应被禁用或仅可由少数用户访问。

  • 部署安全：软件应该随附工具和指导以帮助最终用户和/或管理员安全地使用它。 此外，更新应该易于部署。

  • 通信：软件开发者应为产品漏洞的发现做好准备并坦诚负责地与最终用户和/或管理员进行通信，以帮助他们采取保护措施（如打补丁或部署变通办法）。

尽管 SD3+C 的每个要素均对开发流程提出了要求，但前两个要素（设计安全和默认安全）对提升安全性的作用最大。 设计安全改进流程以防止在第一阶段引入漏洞，默认安全则要求软件默认状态下暴露的地方，即“攻击面”达到最小。

在现有开发流程中引入旨在集成 SD3+C 方法的安全措施后形成的总体流程结构如图 2 所示。

ms995349.sdl_02_thumb(zh-cn,MSDN.10).gif

图 2. SDL 对 Microsoft 开发流程的改进

本文的第 2 节从更高层面介绍了 SDL 的各个组件。 第 3 节简要概述了 Microsoft 实施 SDL 的特定情况。 本文第 4 节提供了一些说明性的数据，展示了在 Microsoft Windows Server 2003 和其他软件开发过程中对 SDL 的早期应用在减少安全漏洞数和严重性等级方面（与之前的软件版本相比）起到的作用。 第 5 节根据 Microsoft 应用 SDL 的经验对流程各要素进行了定性讨论。 最后，第 6 节进行了总结。

2. 安全开发生命周期流程

如前所述，工程师教育已超出本文的讨论范围。 但是必须认识到教育计划对 SDL 的成功实施至关重要。 计算机科学和相关专业的大学应届毕业生一般缺乏必要的培训，不能立即加入工作队伍从事安全软件的设计、开发或测试工作。 即使是学了安全课程的人员，他们可能对加密算法或访问控制模型接触较多，但是对缓冲区溢出或规范化缺陷可能了解不多。 一般情况下，行业内的软件设计者、工程师和测试人员也缺乏适当的安全技术知识。

在这些情况下，准备开发安全软件的组织必须负责对其工程人员进行适当教育。 根据组织的规模和可用的资源，应付这种挑战的方法可能会有所不同。 拥有大批工程人员的组织可建立一个内部计划对其工程师进行在职安全培训，而小型组织则可能需要依赖外部培训。 在 Microsoft，所有从事软件开发的人员必须参加一年一次的“安全进修课程”培训。

2.1 需求阶段

安全系统开发的一个基本原则就是需要“自下而上”地考虑安全问题。 尽管很多开发项目开发出的“后续版本”是建立在先前发布的版本基础上，但是新的发行版或版本的需求阶段和初始规划仍然为构建安全软件提供了极好的机会。

在需求阶段中，产品小组与中央安全小组联系，请求指派安全顾问（在 Microsoft 实施 SDL 时称为“安全员”），该安全顾问在进行规划时充当联络点，并提供资源和指导。 安全顾问通过审核计划、提出建议和确保安全小组规划适当的资源来支持产品小组的日程，为产品小组提供协助。 安全顾问在安全里程碑和出口标准方面向产品小组提出建议，这些安全里程碑和出口标准是由项目的规模、复杂程度和风险决定的。 从项目开始到完成最终安全审核和软件发布，安全顾问始终充当产品小组与安全小组之间的联系点。 安全顾问还充当安全小组和产品小组管理人员之间的联系人，向小组管理人员提供关于项目的安全要素是否正常工作的意见，以避免在流程的晚期出现安全方面的问题。

在需求阶段中，产品小组应考虑如何在开发流程中集成安全性，找出关键的安全性对象，以及在尽量提升软件安全性的同时尽量减少对计划和日程的影响。 在此过程中，产品小组需要考虑如何使软件的安全功能和保证措施与其他可能与该软件配合使用的软件相互集成。 （要满足用户将各个产品集成到安全系统的需要，考虑与其他软件的接口非常关键。）产品小组关于安全目标、挑战和计划的整体构想必须反映到需求阶段中制作的规划文档中。 虽然计划可能会随着项目的进行而变化，但是较早地明确制订这些计划将有助于确保不会忽视任何需求或不会直到最后一刻才发现它们。

每个产品小组都应将安全性要求视为此阶段的重要组成部分。 尽管有些安全性要求将在威胁建模过程中确定，但是用户需求可能要求根据客户的要求来考虑一些安全性。 符合行业标准或认证过程（如通用标准）的需要也可能提出一些安全性要求。 作为正常规划流程的一部分，产品小组应认识到并反映这些要求。

2.2 设计阶段

设计阶段确定软件的总体需求和结构。 从安全性的角度来看，设计阶段的关键要素包括：

  • 定义安全体系结构和设计指导原则：从安全性角度定义软件的总体结构，并确定对安全性起关键作用的组件（“可信赖计算基础”）。 确定将在软件中全面应用的设计技巧，如分层、使用强类型语言、应用最低权限和使攻击面最小化。 （分层 指的是将软件组织成精心定义的组件以避免组件之间出现循环依赖关系 — 将组件组织为层，高级层可以依赖低级层的服务，且禁止低级层依赖高级层的服务。）体系结构中各要素的特点将在各自的设计规范中详细说明，而安全体系结构只是确定安全设计的总体构想。

  • 记录软件攻击面的要素。 由于软件不可能绝对的安全，所以必须重视的是：默认情况下应仅将大多数用户需要使用的功能对所有用户开放，且可以用尽可能最低的权限安装那些功能。 对攻击面要素进行度量可为产品小组提供默认安全性的现行度量标准，使产品小组可以检测到令软件易受攻击的情况。 尽管有些增加攻击面的情况可能是因为增加了产品功能或可用性导致的，但是在设计和实施过程中还是需要对每种这样的情况进行认真检测和研究，以确保软件交付时在默认配置下具有最好的安全性。

  • 对威胁进行建模。 产品小组逐个组件地对威胁进行建模。 组件小组使用结构化的方法，确定软件必须管理的模块以及访问那些模块时所使用的接口。 威胁建模过程确定可能对每个模块造成损害的威胁以及导致损害的可能性（风险评估）。 组件小组然后确定降低风险的对策 — 通过安全功能（如加密）或通过正确使用保护模块免受损害的软件。 这样，威胁建模可以帮助产品小组确定安全性需求，以及需要特别仔细地审核代码和进行安全测试的领域。 应使用工具来支持威胁建模过程，该工具应可以处理机器可读格式的威胁模型，并可以对其进行存储和更新。

  • 定义补充性交付标准。 尽管应定义组织的基本安全交付标准，但是各个产品小组或软件版本也可以设立发布软件前必须符合的特定标准。 例如，正在开发一个准备交付用户使用并可能面临高强度攻击的软件更新版本的产品小组可以建立这样的标准：在一段时间内外部没有发现新版本漏洞时才认为它已做好发布的准备。 （也就是说，开发过程应在漏洞被报告之前找到并消除这些漏洞，而不是在产品小组接到报告之后不得不“修复”这些漏洞。）

2.3 实施阶段

在实施阶段，产品小组对软件进行编码、测试和集成。 在此阶段将采取措施消除安全缺陷或防止引入安全缺陷的作用很大 — 这些措施将大大减少安全漏洞遗留到发布给用户的软件最终版本中的可能性。

威胁建模的成果为实施阶段提供特别重要的指导。 开发者应特别注意确保代码的正确性以消除高优先级威胁，测试者可集中对这些威胁进行测试以确保将其拦截或消除。

在实施阶段中应用的 SDL 要素为：

  • 应用编码和测试标准。 编码标准帮助开发者避免引入导致安全漏洞的缺陷。 例如，使用更安全和更一致的字符串处理和缓冲区操纵结构有助于避免引入缓冲区溢出漏洞。 测试标准和最佳做法有助于确保将测试重点放在检测潜在的安全漏洞上，而不仅仅是专注于测试软件功能的正确运行。

  • 应用包括模糊化工具在内的安全测试工具。 “模糊化”为软件应用程序编程接口 (API) 和网络接口提供结构化但无效的输入，以使检测到可能导致软件漏洞的错误的可能性最大化。

  • 应用静态分析代码扫描工具。 这些工具可检测出某些类型的可能导致漏洞的编码缺陷，包括缓冲区溢出、整数溢出和未初始化变量。 Microsoft 在开发这类工具上已进行了大量的投资（长期使用的两个工具为 PREfix 和 PREfast），随着新的编码缺陷和软件漏洞的发现，Microsoft 将继续对这些工具进行改进。

  • 进行代码审核。 作为自动化工具和测试的补充，将由接受过培训的开发人员进行代码审核，他们将检查源代码并检测和消除潜在的安全漏洞。 这是开发流程中从软件中消除安全漏洞的关键步骤。

2.4 验证阶段

验证阶段是指软件已具备所有功能并进入用户试用版测试的阶段。 在此阶段中，在对软件进行试用版测试时，产品小组进行“安全推进”，包括进行安全代码审核（超出实施阶段中进行的审核范围）和集中式安全测试。

早在 2002 年，Microsoft 已在 Windows Server 2003 及其他软件版本验证阶段引入了安全推进。 在流程中引入安全推进有两个原因：

  • 有问题的软件版本已进入生命周期的验证阶段，此阶段最适合进行所需的集中式代码审核和测试。

  • 在验证阶段进行安全推进可确保代码审核和测试针对的是软件的完成版本，并提供了对实施阶段开发或更新的代码以及未修改的“遗留代码”进行全部审核的机会。

其中第一个原因反映了历史上的巧合：在验证阶段进行安全推进的决定。 但是 Microsoft 已证实在验证阶段进行安全推进确实是非常好的做法，既可以确保最终的软件符合要求又可以对先前软件版本的旧代码进行更深入的审核。

特别要注意的是对高优先级代码（成为软件“攻击面”一部分的代码）进行代码审核和测试对 SDL 其他部分十分关键。 例如，在实施阶段需要进行这类审核和测试，以便尽早矫正任何问题，并确定和矫正这类问题的来源。 在验证阶段由于产品已接近完成，所以进行这类审核和测试也十分重要。

2.5 发布阶段

在发布阶段中，应对软件进行最终安全审核 (FSR)。 FSR 的目标是要回答下面这个问题。 “从安全的角度看，此软件是否已准备好交付给客户？”一般在软件完成之前 2 到 6 个月进行 FSR，具体时间根据软件的规模决定。 在进行 FSR 之前，软件必须已处于稳定状态，且只剩一些很小的非安全性更改需要在发布前完成。

FSR 是由组织的中央安全小组对软件进行的独立审核。 在进行 FSR 之前，来自安全小组的安全顾问向产品小组建议软件所需进行 FSR 的范围，并为产品小组提供资源需求列表。 产品小组为安全小组提供完成 FSR 所需的资源和信息。 FSR 开始时，产品小组需要填写一份问卷并与派来进行 FSR 的安全小组成员进行面谈。 所有 FSR 将要求对最初标识为安全漏洞，但后来经过深入分析确定为对安全性没有影响的缺陷进行审核，以确保分析的正确性。 FSR 还包括审核软件是否能抵御最新报告的影响类似软件的漏洞。 对主软件版本进行 FSR 时需要进行渗透测试，可能还需要利用外面的安全审核承包商来协助安全小组。

FSR 不是简单的通过/失败测试，FSR 的目标也不是找出软件中所有剩余漏洞，因为这显然不太可行。 实际上，FSR 是为产品小组和组织的高层管理人员提供：软件的安全水平以及软件发布给用户后抵御攻击的能力的总体状况。 如果 FSR 发现某类剩余漏洞，正确的反应是不仅要修复发现的漏洞，还要回到之前的阶段并采取其他针对性的措施解决根本原因（例如，提高培训质量和改进工具）。

2.6 支持和服务阶段

尽管在开发过程中应用了 SDL，最先进的开发方法还是无法保证发布的软件完全没有漏洞，而且有充分的理由证明永远都做不到。 即使开发流程可以在交付之前从软件中消除所有漏洞，还是可能会发现新的攻击方式，这样过去“安全”的软件也就不再安全。 因此，产品小组必须准备好对交付给用户的软件中新发现的漏洞作出响应。

响应过程包括评估漏洞报告并在适当的时候发布安全建议和更新。 响应过程还包括对已报告的漏洞进行事后检查以及采取必要的措施。 对漏洞采取的措施的范围很广：从为孤立的错误发布更新到更新代码扫描工具以重新对主要的子系统进行代码审核。 响应阶段的目标是从错误中吸取教训，并使用漏洞报告中提供的信息帮助在软件投入使用前检测和消除深层漏洞，以免这些漏洞给用户带来危害。 响应过程还有助于产品小组和安全小组对流程进行改造，以免将来犯类似错误。

3. Microsoft 实施安全开发生命周期的情况

自 2002 年初进行“安全推进”以来，Microsoft 的 SDL 实施不断发展。 为了启动该流程并对已进入开发后期的产品产生影响，安全推进将本应分布在 SDL 多个阶段的活动压缩为相对短期的活动。 安全推进对产品小组的计划、资源和日程产生了重大影响，如果没有 Microsoft 高层管理人员的积极支持，实施起来就会困难得多。 安全推进将重点放在威胁建模、代码审核和安全测试（包括渗透测试）上。 在 2002 年末和 2003 年初，在 Windows Server 2003 发布之前引入了最终安全审核 (FSR)，而 FSR 对 Windows Server 2003 交付时的默认配置产生了重大影响。

在进行初步的安全推进和 FSR 之后，Microsoft 启动了一个项目来使 SDL 流程正式化。 此项目有四个特殊成果值得特别注意：

  • SDL 的强制应用策略

  • 工程人员的强制教育

  • 产品小组的度量标准

  • 中央安全小组的角色

以下各节将分别介绍上述领域

3.1 SDL 的强制应用

由于 SDL 产生了显著的效果（请参阅第 5 节），Microsoft 决定正式要求对广泛领域内的软件应用 SDL。 在撰写本文的时候，SDL 正在成为必须对以下类别的所有软件强制应用的流程：

  • 将用于处理个人或敏感信息的软件

  • 将在企业或其他组织（包括学术机构、政府或非赢利机构）使用的软件

  • 将连接至 Internet 或在网络环境中使用的软件

未强制 应用 SDL 的 软件包括不符合以上标准的独立应用程序（例如儿童游戏，像“魔法学校巴士”系列）。 但是，SDL 可以显著地避免这种软件影响运行该软件的平台（操作系统或其他软件）的安全性。

3.2 强制教育

2002 年初的安全推进的一个关键方面就是培训了产品小组的全部人员，包括所有开发人员、测试人员、程序经理和文档管理人员。 Microsoft 已正式要求对其软件必须实施 SDL 流程的部门的工程师进行一年一次的安全教育。 每年需要进行知识更新是因为安全性事实上不是一个静态的范畴：威胁、攻击和防御都在不断的演变。 因此，即使工程师已完全掌握影响其软件的安全性方面的知识，在威胁发生变化时也必须接受新的培训。 例如，在过去四年中，整数溢出漏洞的重要性大大增加了，而且最近发现一些加密算法存在以前未知的漏洞。

Microsoft 已开发出一套通用的面向工程师的安全知识简介和更新教程，以“现场培训”和数字媒体两种形式提供。 Microsoft 以该教程作为基础，然后再按软件技术和工程师角色进行专门的培训。 Microsoft 正在编写一套安全教育课程，这套教程将根据技术、角色和学员的经验水平进行专业化的细分。

很多 Microsoft 合作伙伴和客户已经在询问何时能为他们提供 Microsoft 安全教育和流程。 Microsoft Press 已根据 Microsoft 在安全性设计、编码和威胁建模方面的内部实践出版了书籍，Microsoft Learning 也根据 Microsoft 的内部实践提供了课程。

3.3 产品小组的度量标准

作为一个公司，Microsoft 相信一句名言“您无法管理无法测量的事物。”尽管设计一套能够可靠测量软件安全性的度量标准十分困难，还是有一些明显可视为软件安全性代表特征的度量标准。 这些度量标准包括工程人员的培训覆盖面（在开发生命周期的开始阶段）到在已向用户发布的软件中发现的漏洞数。

Microsoft 已设计出一套安全性度量标准，产品小组可将其用于监控 SDL 的实施情况。 这些度量标准监控 SDL 在小组内的实施，从威胁建模到代码审核和安全测试，再到提交 FSR 时软件需具备的安全性。 随着这些度量标准的持续实施，既允许小组追踪自身的表现（提高、不变或下降），也允许将其表现与其他小组进行对比。 这些度量标准将定期报告给高级产品小组管理人员和 Microsoft 主管人员。

3.4 中央安全小组

在 2002 年实施安全推进之前，Microsoft 已建立了 Secure Windows Initiative (SWI) 小组，该小组的任务是提升软件安全性并减少 Windows 的漏洞，并为负责开发 Windows 以外产品的产品小组提供安全支持。 SWI 小组在组织和管理 Windows Server 2003 安全推进活动中起中心作用，并为自 2002 年开始进行的所有安全推进活动提供了培训和咨询支持。 SWI 小组还对 Windows Server 2003 进行了 FSR，开创了 FSR 流程。

在 Microsoft，随着 SDL 的正式推行，SWI 小组已取代中央安全小组的作用。 SWI 小组的责任包括：

  • SDL 的开发、维护和改进，包括定义流程的强制部分。

  • 工程师教育课程的开发、改进和推行。

  • 指派“安全顾问”，这些顾问在流程中对产品小组进行指导，为产品小组执行审核并确保产品小组的问题得到及时、准确和权威性的解答。

  • 担任广泛的安全主题事务方面的专家，确保提交给安全顾问或通过其提交的问题得到及时、准确的解答。

  • 在软件发布之前执行最终安全审核。

  • 对已发布给用户的软件中报告的漏洞进行技术调查，以确保找到问题的根本原因并作出适当的响应。

在 Microsoft，SWI 小组的存在及其有效性已证实它是实施 SDL 过程中的关键因素。 Microsoft 的目标是建立一个开发更安全软件的可伸缩流程，要实现此目标就需要在所有产品小组内广泛实施安全性要求。 然而，拥有一个高水平的中央安全小组还是对以下工作非常关键：提高公司内产品小组的工作效率，并在其创建更安全的软件方面提供支持。 中央安全小组还可以确保由产品小组之外的人员执行 FSR。

4. Microsoft 实施安全开发生命周期的成果

现在 Microsoft 就得出结论宣布 SDL 提升了 Microsoft 软件的安全性还为时过早，但是到目前为止所取得的成果令人鼓舞。

Windows Server 2003 是 Microsoft 实施 SDL 大部分流程的第一个操作系统。 图 3 显示了两个最新的 Microsoft 服务器操作系统（Windows 2000 和 Windows Server 2003）发布后一年内颁布的安全公告数。 （在发布 Windows 2000 的时候，Microsoft 还没有正式的安全公告严重性分级系统。 Microsoft 已参照当前的严重性分级系统对应用于 Windows 2000 的每个安全公告进行了评估。）正如本文前面所述，Windows Server 2003 开发时实施了大部分（但不是全部）SDL 流程，Windows 2000 开发时还没有实施这些流程。

ms995349.sdl_03(zh-cn,MSDN.10).gif

图 3. Windows 实施 SDL 之前和之后的严重和重要安全公告数

有关严重性类别的定义，请参阅 https://www.microsoft.com/technet/security/bulletin/rating.mspx。

其他 Microsoft 软件发行版也应用了 SDL 的一些要素。 SQL Server 和 Exchange Server 产品小组在发布 Service Pack（一种聚合安全性漏洞和其他问题的修复程序的软件发行版）之前分别进行了安全推进（包括威胁建模、代码审核和安全测试）。 SQL Server 安全推进的成果主要体现在 SQL Server 2000 Service Pack 3 中，Exchange Server 安全推进的成果主要体现在 Exchange 2000 Server Service Pack 3 中。 图 4 和 5 显示了发布各自的 Service Pack 之前和之后相同期限内颁布的安全公告数（SQL Server 2000 的期限为 24 个月；Exchange 2000 Server 的期限为 18 个月）。

ms995349.sdl_04(zh-cn,MSDN.10).gif

图 4. SQL Server 2000 实施 SDL 之前和之后的安全公告数

ms995349.sdl_05(zh-cn,MSDN.10).gif

图 5. Exchange Server 2000 实施 SDL 之前和之后的安全公告数

另一个鼓舞人心的例子是 Windows Server 2003 的 Internet 信息服务器组件 (IIS 6)，在发布之后两年内，Microsoft 只颁布了一个影响 Web 服务器的安全公告，并且这个公告所针对的还是在默认情况下不会安装的组件 (WebDAV)。

尽管安全性漏洞的例子比较少而且研究的时间段也有限，但是这些结果还是为 SDL 的有效性提供了有力的证据。 Microsoft 将继续监控 Windows Server 2003 以及 Exchange Server 和 SQL Server Service Pack 中出现的漏洞数，以观察这种早期的趋势是否会继续下去。 Microsoft 还将分析其他在全面实施了 SDL 之后交付了新版本的 Microsoft 软件，以确定安全漏洞的数量和严重性是否继续下降

5. 应用安全开发生命周期的观察

前一节展示的数据提供了希望 SDL 达成的“目标”的概况。 本节将尝试回答一些关于该流程“如何”工作的问题。 前一节建立在强有力的数字基础上（Microsoft 在跟踪漏洞报告和安全公告方面非常严格），本节则建立在 SWI 小组人员所经历的事实基础上（根据他们的观察和意见）。

5.1 SDL 各要素的有效性

SDL 由 大量的子流程组成，这些子流程分布整个软件开发生命周期内。 已要求 SDL 小组按照有效性区分这些子流程的优先级 — 哪些子流程效果最显著，哪些子流程已试验过却效果不明显。

SWI 小组的共识是威胁建模是 SDL 中最高优先级的子流程。 显然，威胁建模不能孤立地应用：威胁建模促进设计、代码审核和测试，一个流程如果只实施威胁建模但对模型不采取任何响应措施（例如未对缓解措施的有效性进行测试），则将不会有任何效果。 缺陷数形式的统计数据不能很好地说明威胁建模的作用，因为威胁建模的主要作用在于确保不产生导致安全漏洞的缺陷。 然而，由于威胁建模在开发安全软件流程中的作用极其关键，因此它显然应该排在最前面。

SDL 在 Microsoft 还是一个相对较新的流程，还没有出现过删除该流程中的子流程的情况。 但是，对长期研究安全的人员来说，有一个发现不会令人感到惊讶，即渗透测试不是获得安全性的好方法。 渗透测试是对主软件发行版进行的最终安全审核 (FSR) 的要素之一，但是产品小组在整个生命周期中的活动主要集中在威胁建模、代码审核、自动化工具的使用以及模糊化测试，而不是渗透测试。 后面的这些措施在防止或消除安全缺陷方面比经典的特定渗透测试更加全面有效。 FSR 的渗透测试要素有助于判断软件是否已准备好可以发布，而不适合作为发现和修复安全缺陷的方法。 如果在 FSR 阶段进行的渗透测试发现了大量的安全缺陷，则是因为早期阶段不够有效，正确的处理方法是重新检查那些阶段中所谓已完成的活动，而不是仅仅修复渗透测试缺陷就发布软件。

5.2 工具、测试和代码审核

静态分析工具、模糊化测试和代码审核的作用是互补性的。 Microsoft 已在静态分析代码扫描工具方面进行了大量的投资，这些工具的使用已成为 SDL 必不可少的一部分。 这些工具在发现许多会导致安全漏洞的编码错误（特别是缓冲区溢出）方面很有效。 然而，当前最先进的工具也不能发现所有错误。 SDL 仍然需要进行手动代码审核，一方面是为了检测到工具未发现的错误，另一方面也是为了确定可以在哪些方面改进这些工具。 参考文献中引用的由 Michael Howard 发表的 Microsoft Developer Network (MSDN) 文章概述了 Microsoft 要求其工程师在进行代码安全审核时使用的常用方法。

高度重视模糊化测试是最近才对 SDL 进行的改进，但是到目前为止所取得的成果非常令人鼓舞。 与静态代码扫描工具不同，必须为要测试的每种文件格式和/或网络协议分别构建（或至少分别配置）模糊化测试工具；因此，它们通常可以发现静态分析工具遗漏的错误。 威胁模型有助于产品小组划分要测试的接口和格式的优先级。 模糊化测试的结果不是完全确定性的（这些工具只运行有限的循环次数，不保证能发现每个缺陷），但是经验表明进行适当级别的模糊化测试可以发现一些“感兴趣”的缺陷，这此缺陷可能作为安全漏洞处理。

5.3 投资

强制安全培训对 Microsoft 这样一个拥有大量工程人员的公司来说需要一笔巨额投资。 培训的推行结合了现场（导师引导）培训班和在线学习资料两种方法。 在线学习资料对工作地址远离 Microsoft 总部的小型工程小组来说是特别有价值的办法。 已证明现场培训在对准备进行安全推进或其他关键活动的小组进行全员培训时特别有效，在这些情况下，Microsoft 的经验表明小组培训的成果不仅可以在课堂培训上有所收获，还可以在安全推进的过程中得到体现。 每个工作组成员都要关注安全性这个事实使安全培训（通常为半天制）显得更加重要。

最近几年随着 Microsoft 越来越重视安全性，中央安全小组（SWI 小组）得到了迅速成长。 通过精心设计，该小组相对于 Microsoft 工程人员总数来说相当小，且重视“规模适当”的方法，以确保开发更安全软件的责任和资源植根于产品小组内部。 反映这种对规模适当的重视的一些策略包括：重视培训和工具，设置安全顾问帮助产品小组解决其自身问题（而不是代替其解决问题），以及通过进行审核（包括 FSR）为产品小组就软件是否已做好发布准备提供反馈。

5.4 收益

SDL 的最终检验标准是在消除和减少 Microsoft 软件中的漏洞方面的有效程度。 第 4 节中总结的经验表明 SDL 达到了这个检验标准。 Microsoft 还会评估外部报告的漏洞对正在开发的软件版本的影响。 最近的经验表明，在新版本中规划或实施的安全措施成功地阻止过去对旧版本有效的攻击的情况越来越多。 最近发布的 Windows XP Service Pack 2 就通过了这样的审核，并发现已规划但尚未实施或公开讨论的安全更改消除了大量过去对 Windows 先前版本报告的漏洞（由外部安全研究人员向 Microsoft 报告的）。

6. 结论

Microsoft 的经验表明 SDL 在减少安全漏洞出现方面十分有效。 SDL 的初步实施（在 Windows Server 2003、SQL Server 2000 Service Pack 3 和 Exchange 2000 Server Service Pack 3 中）使软件安全性得到了显著提升，而且后续的软件版本，更显示出对 SDL 进行改进后，软件安全性得到进一步提升。

实施组成 SDL 的要素越多，对安全性的提升也就越多，这也是视为有效流程的一个特征。 该流程尚不完美，还在发展之中，而且在可以预见的将来也不会达到完美或停止发展。

安全开发生命周期的开发和实施对 Microsoft 来说意味着一笔重大投资，也是对软件设计、开发和测试方法的重大变革。 软件对社会的重要性在不断增加，对 Microsoft 和整个软件行业提升软件安全性的要求也在不断提高；因此发表这篇关于 SDL 的文章和有关特定技术的书籍（请参阅参考文献）就是为了让整个软件行业分享 Microsoft 的经验。

7. 感谢

本文最初由现有作者从 2002 年末共同努力开始撰写。 本文草稿随着 SDL 的发展不断进行更新，当前的版本在 2004 年夏季和秋季完成。 作者向在定义和改进 SDL 方面做出贡献的 Matt Thomlinson、Matt Lyons、Jamil Villani 和 Eric Bidstrup（Microsoft Secure Windows Initiative 小组全体成员）表示衷心的感谢。 除了上述对本文做出贡献的人士，Microsoft 的 Scott Charney 和 Phil Reitinger 以及卡耐基梅隆大学的 Jeannette Wing 也对草稿提出了特别有帮助的意见。 作者还要感谢 Martin Abadi、Virgil Gligor、Dick Kemmerer、Chris Mitchell、Fred Schneider、Neeraj Suri 和 James Whittaker 为本文提出宝贵的意见和建议。

8. 参考文献

Mundie, Craig, Trustworthy Computing White Paper

Howard, Michael, Attack Surface: Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users, MSDN Magazine, November 2004

Howard, Michael, Expert Tips for Finding Security Defects in Your Code, MSDN Magazine, November 2004

Howard, Michael and David LeBlanc, Writing Secure Code, Second Edition, Microsoft Press, Redmond, Washington, 2003

Swiderski, Frank and Window Snyder, Threat Modeling, Second Edition, Microsoft Press, Redmond, Washington, 2004

9. 注意事项

本文档包含的信息代表 Microsoft Corporation 截至发布日期就所讨论的问题发表的最新观点。 由于 Microsoft 必须对不断变化的市场状况作出反应，因此这些观点不应被解释为 Microsoft 的承诺，并且 Microsoft 不保证所示任何信息在发布日期之后仍准确。

本白皮书仅供参考。 对本文档中的信息，MICROSOFT 不做任何明示、默示或法定保证。

遵守所有适用的版权法是每个用户的责任。 在不限制版权法所规定的权利的情况下，未经 Microsoft Corporation 明确的书面许可，不得出于任何目的、以任何形式或手段（电子的、机械的、影印、录制等等）复制、传播本文档的任何部分，也不得将其存储或引入到检索系统中。

Microsoft 可能具有涉及本文档中主题的专利、专利申请、商标、版权或其他知识产权。 除非 Microsoft 的书面许可协议明确规定，否则提供本文档并不意味着赋予您这些专利、商标、版权或其他知识产权的任何许可。

© 2005 Microsoft Corporation. 保留所有权利。 本白皮书部分内容为电气与电子工程师协会 2004 年版权所有。 保留所有权利。

Microsoft、MSDN、Windows 和 Windows Server 是 Microsoft Corporation 在美国和/或其他国家或地区的注册商标或商标。

转到原英文页面