安全观察我刚获得一份安全公告。我该怎么做呢？
Christopher Budd
应客户的要求，Microsoft 于 2003 年 10 月建立了每月安全公告发布过程。客户的主要要求之一是提高安全公告发布计划的可预测性。我们现在已经能够利用这种规律性和可预测性改进和优化我们的这些过程。
Microsoft 安全公告网站是供您查找最新安全公告和搜索以前的公告的工具，如图 1 所示。例如，图 2 显示的是 2006 年 8 月的公告。
图 1** Microsoft 安全公告网站 **(单击该图像获得较大视图)
对于很多客户而言，Microsoft 每月安全公告已帮助形成了更加成熟的 Microsoft 安全更新部署过程。客户利用在可预测的日期发布安全公告的这种机会建立起了自己定期处理这些公告的过程。这些客户在自己的安全更新评估和部署过程中已建立起与可预测的 Microsoft 每月安全公告发布时间线一致的时间线和步骤。客户通过使用该过程来系统地分析、测试和部署更新，不仅改善了整体的安全形式，还减少了停机时间和中断次数。
图 2** 2006 年 8 月安全公告 **(单击该图像获得较大视图)
但是，某些客户在进行安全更新评估和部署时并未采用规定的过程。虽然不系统的部署更新不会产生任何问题，但它从根本上与我们所认为的最佳安全更新管理方法是相左的。
虽然我们提供了有关公告的发布方式和发布时间的有用信息，但我们并未进一步提供指导您应如何处理这些公告以及如何将它们集成到自己的过程中的指南。部分客户可能并不知道可以使之受益的过程，或者不知道构建这些过程的最佳方法。
因此，我将在本专栏中简要介绍我们为您推荐的用于对安全更新进行评估和部署的步骤和过程。任何规模的组织都可以遵循这些步骤。对于某些较大型的组织，最好基于组织的内部结构将这些步骤划分为不同的组。对于较小的组织，可以由一个组甚至是一个人来执行所有这些步骤。无论职责分工如何，都应在评估和部署过程中明确说明这些步骤。图 3 提供了这一过程的概览。
图 3** 安全公告评估和部署过程 **
1. 接收高级通知
在您的每月安全公告过程中，第一步应确保您能收到有关即将发布的安全更新的高级通知。Microsoft 会在每月标准发布（即每个月的第二个星期二）之前的三个工作日的太平洋时间 (GST -8) 上午 10 点左右在它的网站上发布信息；因此，高级通知信息将在该日期的上一个星期四发布。
高级通知的目的是在实际发布之前提供相关信息，帮助用户制订部署计划。出于保护客户的需要，通知中所包含信息的详细程度有所权衡，在安全更新发布之前不会泄露任何可能导致客户受到攻击的信息。高级通知按产品名称（不包括具体版本，例如，Microsoft® Windows® 或 Microsoft Office）来组织有关即将发布的更新信息。其中每个条目都会详细说明以下内容：将为该产品发布多少公告、这些公告的最高严重程度、是否有需要重新启动计算机的更新以及哪些检测工具适用于这些公告。
为确保不让用户感到突然和尽可能消除困惑，高级通知还提供有关将在同一日期发布但与安全公告没有任何关联的其他更新的信息。具体来讲，它会详细介绍以下信息：将通过 Microsoft Update (MU) 和 Windows Update (WU) 发布多少高优先级的非安全更新以及 Microsoft Windows Malicious Software Removal Tool 是否有任何更新。
最后，我们将提供与任何可能导致部署延迟的问题有关的信息，正如我们在 MS06-019 中更改“代理发送”权限时那样。
每个月都会发布新的高级通知，届时将通过 Security Notification Service Comprehensive Edition (SNSCE) 发送通知。您可以注册使用 SNSCE。
2. 评估潜在的影响
在收到高级通知后，第一步应是评估即将发布的版本在您的环境中的相关性。尽管高级通知仅包含有限的详细信息来介绍受影响的产品，但它提供的信息足以用来评估即将发布的公告是否与您的环境相关。
例如，假设高级通知介绍了两个具有最高严重程度级别（重要）并需要重新启动计算机的 Microsoft Exchange 公告。如果您没有运行 Exchange，便会立即知道这些公告不适合用于您的环境。与之相反，如果您运行有 Exchange Server 2003，您将知道到星期二最多可能会有两个级别为“重要”且需要重启计算机的公告。
为了进行计划，请记得使用高级通知，此工具可帮助您确定在以下方面对组织的最大影响：公告的数目、公告的严重程度及其在重新启动方面对部署的影响。在评估了更新的相关性和可能的最大影响后，您可以制订一份计划，其中应包括以下操作项：
- 进行风险评估、测试和部署的人员
- 测试计划和测试试验时间
- 部署计划和计划的重新启动（如果适当）
此时的所有计划都应是暂定的，因为高级通知中的信息还可能发生变化。另外，由于高级通知中信息的有限性，您可以在建立全部细节后再进行更改。
最后，如果存在任何其他信息（例如功能变化），则应利用高级通知和实际安全公告发布之间的时间来调研该问题并评估它可能对您的环境所造成的影响。您可能需要基于调研对暂定的计划进行修订。
3. 接收新的 Microsoft 安全公告
在每月的第二个星期二，Microsoft 将发布其安全公告。太平洋时间上午 10 点是发布时间，但是，由于该发布属于一个庞大而复杂且相互关联的过程，因此它可能会因各种原因而延迟。在此发布中，Microsoft 网站上将发布以下内容：安全公告、安全更新、检测和部署工具（例如 Microsoft Baseline Security Analyzer (MBSA) 和 Windows Server® Update Services (WSUS)）的更新以及新的检测工具（例如新版本的企业扫描工具 (EST)）等。
Microsoft 安全公告页已支持 RSS 源。当安全公告中包含更新时，我们的 RSS 源也会随之更新，而这又会更新 RSS 聚合器和查看器。此外，还将使用安全通知服务 (SNS) 和 SNSCE 发送通知。通知将通过电子邮件和 MSN® Alerts 发送。
要了解有关新安全公告的可用性的信息，必须注册开通我们提供的所有通知方式。您可以订阅 RSS 源以获得 SNS 和 SNSCE。
4. 评估安全公告的相关性
在审查新的安全公告并评估其与您的环境之间的相关性时，职责分配必须明确。在此评估过程中，您可以根据需要利用安全公告中完备的特定信息来对您暂定的计划进行修订和调整。回到前面的示例，如果您向 Exchange 管理小组通知了可能的重大安全更新，但发现 Exchange Server 并不受到影响，则可以调整对这些资源的计划。
在评估了安全公告与您的组织之间的相关性时，可以继续处理与您的过程相关的安全公告。
5. 执行风险评估并对公告评级
此时，您需要对相关公告进行风险评估。在权责分工明确的组织中，此步骤通常由安全组来执行。虽然每个 Microsoft 安全公告都包含一个最大严重程度级别，但该级别反映的是在所有受影响的产品中所有漏洞的最高严重程度。适用于您的组织的 Microsoft 严重程度级别可能不同于列出的最大严重程度级别，这取决于该问题对环境中所使用版本的影响的严重程度。请务必查看安全公告“概要”部分下完整的“安全评级和漏洞说明”表，并获取有关您的具体版本的具体漏洞信息。
之后，应查看其他技术信息（例如“缓和因素”）以及针对每个漏洞的常见问题中的技术详情，接着基于您的环境和策略对风险评估进行调整。您的策略可能还规定评估须说明非技术的环境因素，例如出现威胁的环境或特定应用程序对组织的关键程度。
在此过程的最后，应对每个公告及其关联的更新进行风险评级。继续使用前面的示例，Exchange 管理组可以基于安全公告中详细介绍的更改信息将安全更新评级为“中等风险”。您应当根据您的策略，对计划进行适当的更新和更改。例如，您的策略可能规定，对中等风险更新的测试时间需要比低风险更新的测试时间长一到两天。
在某些情况下，您的策略可能还规定，对于具有一定风险级别的公告，还需要考虑实施替代方法。例如，您组织的策略可能规定，对于评级为重要的所有安全更新，应尽快审查并部署替代方法。在此情况下，需要对替代方法执行额外的风险评估，以确定要实施的操作以及实施时间。
在此过程的最后，应列出要在环境中部署的更新以及与每项更新关联的风险评级。此外，还应列出要实施的替代方法，并使用它们更新您的测试和部署计划。对计划所做的更改应反映策略所指定的时间线。例如，您的策略可能规定，对于所有重要安全更新，必须在 24 小时内部署替代方法并在 7 个日历日内部署更新。
6. 确定安全更新和/或替代方法对组织的可能影响
了解安全更新或替代方法对组织的影响是评估过程中的一个关键步骤。在权责分工明确的组织中，此步骤通常由负责管理受安全更新或替代方法直接影响的系统的组来执行。
了解可能产生的影响有助于您了解并确定由安全更新或替代方法本身所带来的风险。有关信息，请参阅安全公告中的“与此安全更新相关的常见问题 (FAQ)”部分。有关安全更新如何消除漏洞的信息，请参阅“漏洞详细信息”下的“漏洞常见问题”。
此步骤的目的是确定更新和替代方法的风险评级。继续使用前面的示例，Exchange 管理组可以基于安全公告中详细介绍的更改信息将安全更新评级为“中等风险”。您应当根据您的策略对计划进行适当的修订。例如，您的策略可能规定，对“中等风险”更新的测试时间需要比“低风险”更新的测试时间多一天。
您可能还需要基于风险评级对计划的影响来重新审查有关部署替代方法的决策。例如，您可能发现需要将测试时间延长两天，但这会使系统失去保护的时间大于策略所允许的时间。在此情况下，需要重新审查替代方法的部署以便符合策略。
最后，应使用此步骤中的信息继续下一步工作 – 制订更新的测试计划。
7. 定义测试计划
为提高效率，测试必须系统地进行并且必须利用有意义的计划进行构建。测试应针对最可能显现环境问题的方面进行。由于每个环境都是不同的，因此我们无法提供一个标准模板来制订有效的测试计划。
对于权责分工明确的组织，测试计划通常由多个组进行设计。负责管理受安全更新或替代方法直接影响的技术或系统的组应能够提供特定的专业知识。而测试组应能够提供有关构建测试案例和测试工具选项的专业知识及其对实际时间线的理解。
在此阶段中，应注意测试计划如何影响您对安全更新或替代方法的风险评级以及它如何相应地更改您的测试和部署计划。例如，如果您确定无法制订一项测试计划来完全按照自己的意愿测试更新，就可以增加其风险评级、选择延迟部署或临时实施替代方法。
8. 制订部署计划
部署是实际实施安全更新或替代方法所提供的保护的过程。由于部署是实现这一过程的真正最终目标，因此了解可用的部署方法并将它们包括在评估之中与安全风险评估一样重要。在权责分工明确的组织中，确定可行的安全更新部署方法这一任务通常由负责管理软件更新的基础结构的组（例如，维护 Systems Management Server (SMS) 的组）来执行。监督配置管理技术（例如 Active Directory）的组可以参与确定可行的替代部署方法的决策过程。
在此步骤中，您的目标是了解可行的部署方法并根据这些方法构建一个要用于部署安全更新或替代方法的计划。此步骤中需要了解的一个重要问题是，可行的部署方法如何影响您的计划以及如何进行一些必要的更改。例如，如果 WSUS 不支持某安全更新，但它又是您的主要部署方法，则可以决定更新部署比原计划延长两天。进而可以确定实施替代方法，以便在此部署期间内提供必要的保护。
有关部署方法的信息，请参阅安全公告的“与此安全更新相关的常见问题”部分。有关实施替代方法的方式的信息与每个替代方法列在一起；每个替代方法都与各自的漏洞相关联。
设计阶段到此结束。此时，您应有一个与安全更新、替代方法、测试和部署的安全风险和风险评级有关的、反映所有评估要素的时间表和计划。从所有这些阶段中可以看出，它们错综复杂地交织在一起，因而并不一定是线性相关的。这些阶段在某些组织中同时发生，而在另外一些组织中则是顺序进行的。您应基于组织的策略、需求和资源来决定这些步骤的实施方式。对于这些步骤，最重要的事项并不是特定的结构和顺序，而是应确保这些不同的步骤能够相互交流。任何实施方式的关键都是要保持灵活性和适应性。
9. 测试更新和替代方法
在测试阶段，您将按照前面在测试环境中制订的测试计划对安全更新和替代方法进行测试。测试环境的用途是重现生产环境的重要元素。在对安全更新和替代方法进行测试的过程中，要在部署到运行环境之前努力查找任何可能出现的问题。
当在测试过程中发现出问题后，您应确定问题的严重程度以及解决问题所需要的步骤。您可能会发现影响处于可接受范围内的微小问题，但也可能发现需要在部署更新之前解决的其他问题。如果您选择接受该问题，则应将其备案，以供支持人员参考。
若要解决该问题，您可以通过 Microsoft 产品支持服务 (PSS) 新开一个案例，该服务为与安全更新相关的问题提供免费支持。有关如何联系 PSS 的信息，请访问 support.microsoft.com/security。由于解决问题会增加测试时间，进而会使部署延后，因此在选择解决问题之前，应考虑这一决策对计划的潜在影响。
在测试完成后（所有问题都已解决或备案），便可以确定在运行环境中部署安全更新还是替代方法了。
10. 部署更新和替代方法
在安全更新或替代方法通过测试后，接下来便可以进入部署过程了。在部署期间，应使用计划来指导您实际地对系统应用安全更新并进行配置更改。通常由参与制订该计划的组来负责执行实际的部署过程。
如果您在部署期间遇到问题（例如，安全更新无法通过您的更新管理基础结构正常安装），则需要仔细检查该问题。如果该问题造成延迟，则可能需要重新检查选项/或考虑使用替代方法来保护系统。
在理想状态下，测试过程将在部署之前识别所有可能在运行期间发生的问题。但是，如果您在将更新部署到运行环境中后遇到了问题，则应按照您在测试中遇到问题时那样执行相同的步骤。评估该问题，然后决定是要接受问题，还是要解决问题。
如果安全更新应用成功，则说明保护机制已就绪，从而实现了这些过程的最终目标。但是，如果安全更新未能成功应用，则说明您的系统依然存在漏洞。
由于某些系统可能无法成功更新，因此部署过程的最后一步非常重要 – 审核系统，确认是否已成功部署。在某些组织中，审核将由与安全团队相关的单独审核组来执行。可以使用 WSUS、MBSA 和 SMS 等 Microsoft 工具来审核安全更新的应用是否成功。另外，在安全公告的“安全更新信息”部分中还提供了相关信息来说明如何验证安全更新的应用是否成功。
总结
借助于 Microsoft 的每月安全公告发布，您可以实施更加有规律的计划和过程来管理安全更新。建立有规律的步骤和过程不仅有助于更好地保护系统，同时还可以在最大程度上减少中断次数和可能的停机时间。
虽然每个组织都应建立自己独特的安全更新管理过程，但您的组织的过程应包括本专栏推荐的步骤。您无需设立单独的安全和更新团队，但应当执行安全风险评估并制订部署计划。
这里的重要的一点是，计划至关重要。通过制订良好的计划，可以更加顺利地完成涉及实际活动的各个步骤（例如测试和部署阶段），而这又会为安全更新过程的成功完成扫清障碍。
Christopher Budd是 Microsoft 安全响应中心 (MSRC) 的一位负责安全的项目经理。专门负责与 IT 和安全专业人员及其他软件用户进行技术交流。
© 2008 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.