安全简报

将安全遵从性作为一项工程原则

Brad Hill

随着新的方案和要求（如支付卡行业数据安全标准 (PCI-DSS)）的出现，许多公司第一次面临构建综合应用程序安全计划的任务。因此，很多公司都在关注 Microsoft 安全开发生命周期 (SDL) 取得的公认的成功。这是非常明智的业务行动，但您必须了解 SDL 具备的以工程为侧重点的特性使其如何有别于典型的安全遵从性工作。本月，我将介绍一些方法来协调侧重于遵从性的计划和安全工程，从而改进您的软件开发实践。

SDL 将安全工程实践集成到整个软件生命周期中，因而可以使用整体方法保障应用程序的安全。该过程要求软件开发人员和测试人员直接参与，与典型遵从性计划不同，这是增量迭代过程，应针对每个公司进行自定义。

本文将重点介绍部署 SDL 并将其与安全遵从性机制集成起来的一些策略和最佳做法。

遵从性与 SDL

从头开始构建软件安全计划是件令人生畏的工作。极少数组织有专门的计划或团队负责保障应用程序开发的安全。典型安全组的组合包括网络和防火墙、策略和身份管理、系统配置以及常规操作和监控。自定义生成的关键任务应用程序集不断增大，除了上述职责之外，确保安全是具有挑战性的新任务。

尽管成熟的软件安全实践可以促进遵从性工作（如 PCI 和信息技术安全评估通用标准），如果只将 SDL 视为一件遵从性工作，就无法最大限度地发挥计划的作用。遵从性计划在外部定义目标和活动，与此不同，SDL 认为业务目标和攻击者的能力是不断变化的。很多公司实现遵从性的方法是预先开展大量工作，之后只进行较少维护。与此相反，SDL 以增量方式开始，注重通过持续性工作不断进行改进。此外，遵从性通常容易导致实现与执行的职责相分离。而 SDL 是由开发人员和测试人员通过紧密协调构建的。基于上述差异，如果您只有管理遵从性工作的经验，应如何处理 SDL 实现？

首先，考虑您的组织在过去 10 年间是如何应对其他主要软件行业变化的，如从过程开发转变为面向对象开发、从客户端-服务器转变为基于 Web 的软件，或从瀑布式开发方法转变为敏捷开发方法。所有这些变化都不是在整个公司内一蹴而就的，而是逐步、有机发展起来的。SDL 也最适合采用同样的方法（如下所列）。

• 从一或两个试验项目的小规模开始。
• 即使要通过能干的团队引入新的工作方式，也要在需要时引入外部帮助。
• 项目结束时，对结果进行研究，并从中总结经验。调整标准做法，使其适用于您的特定组织。去除不起作用的内容。
• 以组织可以控制且不干扰业务的步伐，有组织地扩展涵盖范围，培养内部专家并传播企业文化的变化。

其次要认识到，符合遵从性只是计划的一个目标，是第一步，而不是终点。更安全、质量更好的软件可为自身赢得业务和竞争价值。衡量计划的标准是，交付更可靠产品的最终成功度以及对企业盈利的贡献度。

通过安全工程增加价值

因为项目处于早期阶段，实现人员需要指导和鼓励，所以团队通常需要获得相关帮助，以优化其软件安全计划。但有时候，即使是成熟的计划也无法成功施行。尽管组织可能已认识到安全的价值，实施了各种活动和最佳做法（培训、设计审阅、静态分析、动态扫描、代码审阅和手动渗透测试），结果却是投资巨大，收效甚微。

传统 IT 安全所采用的面向遵从性的方法固有一些偏差，使得这些计划在提高软件质量方面无法取得真正的成功。通常，通过重新定位计划来避免一些常见遵从性问题、将开发组织包括进来、继而将工程方法集成到遵从性工作中，组织可以找出有助于安全工作发挥最大潜力的简单更改。

在下面几节中，将重点介绍四个最常见的问题，并说明如何避免或解决这些问题。

不要事事抓 – 重点突破

遵从性工作及其结果有明确的定义。各个要求是各自独立的，有标准的指标，整体遵从性状态事关是否符合足够多的要求。从实现遵从性的抽象目标来看，正确的管理策略是使用可用资源涵盖尽可能多的领域，用尽量少的必要花费遵从任何独立的要求。

除非在最细粒度，否则质量软件工程非常不适合使用这类指标。资源分配过少是一个常见问题。有价值的工作就应该做好。粗略或水平低下的渗透测试会造成安全感错觉，如果过于相信代码扫描工具的功能，可能导致为手动代码审阅分配的资源不足，如果在加密等领域进行的培训不足，开发人员一知半解，反而会导致危险。最好是实实在在做好几件事，而不要只顾求全，事事都做不好。

以我公司针对安全工作所用的代码审阅过程提供的咨询服务为例。对于所有面向 Internet 的应用程序而言，由专职团队审阅安全代码都是开发过程中不可或缺的组成部分，这种少见的做法和能力通常意味着计划的阵容很强。

人工代码审阅可以高效查找难于发现但非常重要的安全缺陷类别，但这个组织的过程是什么样呢？因为这是必须完成的，审阅人员要做大量工作，几乎没有时间完成任务。在这个过程中，几乎没有为开发团队分配协作时间，所以代码审阅人员接触到的业务环境很少。此外，他们无法获得以前通过工具或手动测试生成的错误报告，也无法获得系统的实时实例来证明其发现。

结果如何？代码审阅中的发现是在计划发布日期之前几天提交给开发团队的，误报率高达 50%。在发现错误的这个发布周期中，即使是对这些错误进行分类也很难实现，更不用说修复错误了。此外，因为缺乏业务环境和协作，无法找出逻辑缺陷，丧失了手动分析最重要的优势。

更好的方法是，减少工作量，降低工作的频率，这也是在遵从性领域里很少听到的方法。不要在一个季度内对 10 个版本分别花两天时间进行代码审阅和黑箱渗透测试，不将代码审阅作为一项独立的活动。而是在每个季度对 5 个版本执行为期 8 天的源代码已知的白箱渗透测试。由于目标数量减少，环境更为广泛，在发布之前会有足够的时间查找并修复更多缺陷。

以项目而不是策略作为目标

通常，在执行遵从性计划时，整个组织都必须满足其要求，并且活动结构通常也很少具有依赖关系。通常，这意味着水平开展遵从性工作，也就是说新策略同时对组织中的所有人有效。尽管部分 SDL 活动适合此方法，以垂直实施方式选择几个团队或项目作为目标更为合理。

要理解这一点，可以考虑一下类似的情况，即许多软件组织最近在方法选择上的变化：使用敏捷开发方法。没有任何一个公司会通过以下方式使其所有团队采用敏捷方法：在 1 季度取消所有项目的正式规范，在 3 季度提高迭代速度，在下一年 2 季度开始编写单元测试。敏捷开发的实践可相互增强和支持，应同时展开，一次一个团队和一个项目。

以类似方式处理 SDL：在没有后续步骤（使用威胁模型、衡量资源成功度并反复改进）的情况下，不宜因全面强制实现威胁建模而耗尽难得的初始资源。任何 SDL 活动在彼此隔离的情况下都无法充分发挥其潜力，徒有一堆昂贵的安全文档而没有任何可操作的后续步骤，无疑最容易导致安全计划以失败告终。

这并不是说，您应该立即着手所有任务。选取几项活动作为开始，如威胁建模、代码审阅和自动扫描，将这些活动一起应用于有限的项目集。通过这种方法，可以收集有关代码扫描程序在减少漏洞方面的准确度和有用性方面的数据，还可以查看扫描程序漏掉、但手动测试可以发现或威胁建模能够预防的错误类型。这一重要信息能够帮助您精细调整每个过程、了解将实现的保证级别，还可以指导有效分配未来的资源。

始终衡量有效性

提到遵从性，往往会让人想起 Tennyson 的名言“Ours is not to reason why.Ours is but to do and die”（别问原因，尽管去做）。如果已列出要求，则不满足要求时，就不符合遵从性。因为具备如此牢不可破的强制性，所以没有任何理由衡量活动的优势。例如，大多数组织都采用密码轮换策略，但很少组织对此类准则所具备的安全优势进行量化。因为没有任何理由质疑标准，很少组织尝试通过成本收益分析来确定以 15 或 45 天为周期更改密码是否优于以 30 为周期。

如果质量是真正的目标，应避免出现这样的错误。典型的培训机制就是这种错误的极佳示例。我们通常看到，评估培训计划只有两个指标：是否所有人都参加了安全培训，培训是否提到了主要漏洞类别？如果业务目标是开发更安全的软件，那么，达到这两个不易达到（可能很昂贵）的指标真能提高软件质量吗？

衡量有效性使得相关软件安全性的核心理念直接回到业务目标上来。在开始任何活动之前，先了解要实现的目标并找到衡量活动是否有效的方法。开发人员和测试人员是否掌握了所学内容？他们是否能够学以致用？与未经培训的团队相比，经过培训的团队所生产的软件是否错误更少，或者是否能在生命周期的早期消除错误？

收集指标不一定要多少成本，简单调查就可能足以优化培训课程，前提是必须有这些指标。开发人员完全可以辨别能达到目的的有意义活动与应省去的无意义活动。成功的安全计划和失败的安全计划之间的差别常常在于，后者将无意义的活动误当作结果。

设置原则性目标、针对目标度量计划的进度并在每一步中改进过程，这样有助于激励开发人员，也有助于改善内部质量文化。通过有意义的指标显示进度还有助于对工作进行可靠判断，为采购更多资源以满足计划的维护和增长提供支持。

大家怎么做，我们也怎么做 ...

与常规软件开发过程一样，安全软件的开发也没有万能妙方。如果有人声称有可以解决所有安全问题的万能解决方案，请务必谨慎。从小规模开始、采用适合您的组织的做法，并向有相似安全需要和资源的其他组织学习经验。

但是您如何知道从哪里开始呢？要做的事情似乎千头万绪。

对全球最佳软件安全计划的最新调查表明，所有这些计划基本上都执行相同的九种活动。最后：最佳做法！难道您不该将世界 10 大计划公认的过程设置为目标？

放眼海军世界 10 强，可以看到，它们都配备航空母舰和潜艇，它们的司令官会毫不犹豫地告诉您，这些技术是显示海上力量的最有效方法。当然，如果仔细观察，您会发现除了 这 10 强海军外，其他海军都没有潜艇和航空母舰。这样的海军需要庞大的军费开支、支持结构和强大的技术能力，而这只有大国才可能提供。对于很多小国而言，具备这样的资源用处不大，要是试图购置和维护这样的系统，很可能会走向破产。

同样，小型软件开发组织如果遵循最佳做法，试图管理目的是将安全工程扩展至成千上万开发人员（负责管理数百万代码）的工具，也很可能走向破产。

耗资巨大的万能安全遵从性解决方案通常更适合吞噬预算和可靠性而不是消除错误，除非组织已对引入此类产品做好了充分准备。最成功的不是那些追求大而无当计划的组织，而是从小规模开始，不断完善与业务目标密切相关的可持续和可管理的安全计划的组织。

在购买昂贵的软件包之前，通过主要企业软件平台中提供的免费和内置安全工具的巨大宝库提升您的专业技能。在花钱开展更复杂的任务之前，您可以随意对 FxCop 和 C++ /analyze（或者 FindBugs，如果贵公司使用 Java）能够发现的所有错误进行分类和修复，还可针对 SDL 禁止的 API 列表按规则编译代码。

习惯使用这些工具按规则进行管理和运行后，就有很大把握成功完成更复杂的任务。您可能会发现，这些免费工具正是您所需要的，使用了它们，您也可能希望使用规模更大、更好的工具。以免费产品作为开始，您不会有任何损失。

协调质量与遵从性

尽管看起来 SDL 与遵从性是互相对立的，实际上绝非如此。两者以相同的基本需要为目标，对它们进行协调和集成可以显著节省成本。在扩展遵从性计划以通过 SDL 改进质量时，借助我们讨论过的四种策略可以避免常见问题，最大程度地获得成功。

不要试图同时做所有事情。从能做好的事情开始。按项目而非按策略增进工作。始终度量工作对业务盈利的有效性。发展计划，而不是购买计划。

最重要的是，立即行动！质量提高，积少成多。首先利用 Microsoft SDL 网站 (https://www.microsoft.com/security/sdl/default.aspx) 中的免费工具和指导。下载并尝试 SDL 优化模型，以评估组织功能的最新状态，然后使用通过 Microsoft SDL Pro Network (https://www.microsoft.com/security/sdl/getstarted/pronetwork.aspx) 提供的专业服务和培训，在满足审核和遵从性目标的情况下改进质量并交付更安全的软件。

Brad Hill 是 iSEC Partners 的 SDL 服务总监，该公司是一家提供全面安全咨询服务的公司，提供的服务包括渗透测试、安全系统开发、安全教育和软件设计验证。有关详细信息，请访问 isecpartners.com。

衷心感谢以下技术专家审阅本文：Michael Howard