3.1 概述：七个极好的接触点

第3章  软件安全接触点简介 

接触点，作为一个通用的概念，是指在任何新生事物——原动的、认知的或者情绪的——快速增长的浪潮刚要涌现之前出现的那些可以预见的时机。…
——T. BERRY BRAZELTON

本书的一个主要目标就是探索和描述一组软件安全的最优方法，我把它们叫做接触点。实施软件安全要求机构对建造软件的方式做一些修改。好消息是，这些修改并不是根本性的、翻天覆地的或者费用高得难以承受。实际上，我们所有要做的常常只不过是采用一组简单明了的最优工程方法，这些方法可以结合到现有的开发过程中。在软件开发生命周期中集成软件安全最优方法，是软件安全的三根支柱的核心。
我所建议的软件安全最优方法具有坚实的软件工程基础，并且在整个软件生命周期中都明确地考虑到了安全情形。这意味着认识和理解一般风险、基于安全的设计，以及对所有的软件工件进行完整客观的风险分析和测试。在这些活动的过程中，应该根据第2章介绍的RMF来追踪和监视软件风险。本章简明地介绍了软件安全接触点（实际上是一种从5万英尺高处得到的俯视图），并提出了它们的采纳次序。

图3-1详细说明了软件安全接触点，并指出了在软件开发过程中软件工作人员应该如何将这些接触点应用到不同软件工件中。这个图也用来装饰本书封底。这样就意味着理解如何在需求、体系结构、设计、编码、测试、确认、测量和维护中采用安全工程方法。

图3-1  轻量级软件安全最优方法，称为接触点，被应用于不同的软件工件中。这些最优方法是根据效率和重要性来编号的。注意，在此仅仅引用软件工件，以避免针对任何特定过程的争论。

虽然在图中这些工件是根据类似于传统的瀑布模型的方式来摆放的，大多数机构现在都遵循某种迭代方法，因此，随着软件的发展，接触点将不止一次地被循环使用。无论如何，集中讨论工件，我们就能避免扩大的过程问题的争论（包括曾经出现的关于哪种软件过程是实用的和轻量型的激烈争论）。
我在第1章中讨论过，应该把软件安全接触点设计成与过程无关的。即不论你使用何种软件过程来建造你的软件，都可以应用接触点。哪怕你只是生成一组最小规模软件工件（至少每一个项目都应该产生代码吧！），你也能应用接触点。
过去我常常以从左至右的次序来介绍软件安全接触点。虽然这样做并无不妥之处，但是，一种更好的讲解方法是，根据软件安全接触点的自然功用来对它们进行排序，并依序进行介绍。有的接触点的威力比其他的更强大，并且你应该首先采用威力最强大的接触点。

下面按照有效性列出了所有的接触点：
1．代码审核
2．体系结构风险分析
3．渗透测试
4．基于风险的安全测试
5．滥用案例
6．安全需求
7．安全操作

我列出的次序并不一定适用于每一个机构。实际上，这种次序反映出以代码为中心的机构多年来在应用这些方法时的偏见。因为这个原因，代码审核出现在体系结构风险分析的前面。但是，实际上这两种排在最前面的接触点都是非常重要的。如果进行代码审核而略过体系结构风险分析，你将不能完全地解决软件安全问题。再回到我在第1章中的定义，导致安全问题的软件缺点可以分成两类：缺陷和瑕疵。
代码审核的目的是找出缺陷。体系结构风险分析的目的是找出瑕疵。如果你略过其中的任何一个，你都极可能仅仅解决一半的问题（牢记缺陷/瑕疵各占一半的事实）。在任何情况中，排在最前的这两种接触点的位置都可以交换，而且不失一般性。

至于其余的接触点，我所提供的评级标准是以在许多不同类型的机构中应用接触点的多年经验为基础的，这些机构包括从大型的独立软件供应商到巨型的信用卡财团。这些接触点的次序并不是绝对的。但是，任何改变这种次序的企图，比如，在进行代码审核之前进行渗透测试，就很可能不会像我建议的方式一样取得成功。具有讽刺意味的是，现在可以在大多数处理软件安全的机构中发现他们是“首先进行渗透测试”，特别是在那些由安全部门推行软件和应用程序安全的机构中。这种次序反映了对待安全的被动反应方法，也是我一直都在反对的方法，我主张将安全作为一种必需的部分，并且让真正的建造人员参与安全过程，。
在有些情形中，大型机构可以同时采用多种接触点。关于在大型企业中采用接触点的更多信息，参见第10章。

3.1  概述：七个极好的接触点

3.1.1  代码审核（工具）

工件：代码
发现的风险的例子：在代码的第42行中发现缓冲区溢出
所有的软件都会至少产生一种工件——代码。这个事实使得代码审核成为我们的清单的第一个条目。在代码级中，关注的焦点是实现缺陷，特别是那些静态分析工具就更是如此，它们通过扫描源代码能发现一般的弱点。在第12章中可以找到这些缺陷的一种分类法。现在有多个工具供应商涉足这个领域。代码审核是一种实现安全的软件的必要而不充分的方法。安全缺陷（特别是在C和C++中的安全缺陷）是显而易见的，而体系结构瑕疵则是真正棘手的问题。在第4章中，你将学习如何用静态分析工具来进行代码审核。
单独进行代码审核是一种特别有用的方法，但是，由于这种类型的审核只能确定缺陷，因此，即使是最好的代码审核也只能发现大约50%的安全问题。仅仅盯着代码是很难（并且几乎是不可能）发现体系结构问题的。现代的系统都由数百万行代码构成，这种方法就更不能奏效了。实现软件安全的完整方法是包括代码审核和体系结构分析的有机组合。

3.1.2  体系结构风险分析
工件：设计和说明书
发现的风险的例子：对关键数据的区分和保护很糟糕；Web服务未能验证调用代码及其用户，并且没有基于正确的上下文来作出访问控制决定
在设计和体系结构级中，系统必须是连贯一致的，并提供统一的安全防线。设计人员、架构人员和分析人员应该用文档清晰地记录各种前提假设，并确定可能的攻击。在基于说明书的体系结构阶段和类层次的设计阶段，体系结构风险分析都是必需的。此时，安全分析人员揭示体系结构瑕疵，对它们评级，并开始进行降低风险的活动。忽视这个级别的风险分析会在日后引起严重的问题。
注意，在软件生命周期的所有阶段中都可能出现风险，因此，我强烈地建议采用持续的风险管理方法，并不断地进行追踪和监视风险的活动。第2章描述了RMF过程和应用它的方法。第5章讲授体系结构风险分析，将帮助你从软件体系结构中找出瑕疵。

3.1.3  渗透测试
工件：处于环境中的系统
发现的风险的例子：在Web接口中处理程序状态的糟糕方法
渗透测试非常有用，如果根据体系结构风险分析来设计测试，效果就更好。渗透测试的优点是，它给出了对处于真实运行环境中的实际部署的软件的很好的理解。但是，没有考虑软件体系结构的任何这类测试，或许都不能揭示关于软件风险的任何有用的信息。不能通过预构的应用程序安全测试工具所实施的封闭黑箱测试的软件肯定是非常糟糕的。因此，通过低层次的渗透测试，只能揭示出一点点软件的真实安全状况的信息，但是未能通过封闭的渗透测试，则说明你确实处于很糟糕的状况中（参见第1章）。
渗透测试与进行测试的人员有关，这是它的一个缺陷。应该特别小心那些“改过自新的黑客”，他们改过自新的唯一证明只有一些自我描述 。还要小心，网络渗透测试与应用程序或者软件所面临的渗透测试并不相同。如果你想正确地进行渗透测试，请参见第6章。

3.1.4  基于风险的安全测试
工件：单元和系统
发现的风险的例子：由于处理数据保护风险而导致可能的大量数据泄漏
安全测试必须包含两种策略：（1）用标准功能测试技术来进行的安全功能性测试；（2）以攻击模式、风险分析结果和滥用案例为基础的基于风险的安全测试。一份好的安全测试计划包含这两种策略。即便你直接探测一个系统，安全问题也并不总是显而易见的，因此，标准的质量保障方法可能不能揭示所有严重的安全问题。QA是为了保证所有好的事情的发生。安全测试是为了保证坏的事情不会发生。像攻击者一样地考虑问题很重要。因此，用关于软件体系结构、一般性攻击和攻击者的心态的知识来指导安全测试是极为重要的。第7章介绍了对系统内部构造有一定了解后，如何进行安全测试。

3.1.5  滥用案例
工件：需求和使用案例
发现的风险的例子：易受广为人知的攻击——篡改攻击的影响
建造滥用案例是深入攻击者的心理的好办法。类似于使用案例，滥用案例描述了系统在受到攻击时的行为表现；建造滥用案例要求明确地说明应该保护什么、免受谁的攻击，以及保护多长时间。滥用和误用案例并未得到充分利用，但是很重要，它们是第8章的主题。想知道滥用案例对自己有什么用处的软件从业人员将从这章中学到许多知识。

3.1.6  安全需求
工件：需求
发现的风险的例子：没有明确描述数据保护要求
必须明确地在需求级中加入安全考量。好的安全需求包括明显的功能安全（比如说，使用实用的加密方法）和突然出现的特性（滥用案例和攻击模式可以很好地捕获它们）。确定和维护安全需求的方法是非常复杂的，应该灵活地处理。我鼓励对此有兴趣的读者查阅下页的“安全需求”文本框中提到的参考资料。第7 章和第8章中提到了一些简明的处理方法。

3.1.7  安全操作
工件：实际部署的软件
发现的风险的例子：没有足够的日志记录以追踪某个已知的攻击者
软件安全可以从网络安全中借鉴很多方法。经过有效组合的安全操作允许和鼓励网络安全专业人员积极应用接触点，提供开发团队可能缺乏的经验和安全智慧。在增强系统的安全状况的过程中，身经百战的操作人员认真地设置和监视实际部署的系统。不论设计和实现的力度如何，都会出现攻击，因此，理解导致攻击成功的软件的行为就是一种重要的防御技术。通过理解攻击和攻击程序而获得的知识应该再应用到软件开发中。

3.1.8  外部分析
这并不是一种真正的接触点，但是它很重要，需要重点指出来，因此我还是像对待接触点一样地特别介绍它。但谈到安全时，外部分析（即，由设计团队之外的人员来进行分析）经常是必需的。最好是由与系统的原始设计和实现无关的人员来应用所有的软件安全接触点。
对于为了修改一个缺陷而端坐几个小时的程序员，其实仅仅需要有一个哥们（过来拽着他去吃比萨饼）来到他的面前，并指出他的错误：“你怎么能够这样做？！”真是令人叹息。唉！这种现象可能出现在软件生命周期的所有阶段中——也是为什么需要外部分析的一个原因。

1安全需求
安全需求是非常新的研究领域，而且文献很缺乏。下面是两篇推荐的阅读材料：
Jonathan D. Moffett, Charles B. Haley, and Bashar Nuseibeh,
“Core Security Requirements Artifacts”，Technical Report 2004/23. Depa

rtment of Computing, The Open University, Milton Keynes, 
UK, June 2004.Nancy Mead, “Requirements Engineering for Survivable System

s”，Technical Report CMU/SEI-2003-TN-013. Pittsburgh,
PA: Software Engineering Institute, Carnegie Mellon University, 2003.

3.1.9  为什么只有七个接触点
有些处理软件安全的方法对于大多数机构来说都太庞杂而难以采用。将接触点限制为七种最优方法，我希望有效的最优方法更易于采用，而且仍然能够对软件安全产生巨大的影响。接触点不仅可以按照你编制软件的过程进行控制（你已经交付了软件，对吗？），而且也是轻量级和易于使用的。如果你应用了这里概括的七个很棒的接触点，你的软件就会安全得多。