资源目录

翻译：陈海燕，CISSP（phrackchen@hotmail.com）

(《计算机安全介绍：NIST手册》第九章)

英文版PDF 中文版PDF

注：以下内容因排版原因有所省略，完全信息请查阅中文版PDF。

计算机安全保证是对技术和运行安全措施、保护系统的工作及其所处理信息的信任程度。但是，保证不是对措施能起作用的绝对担保。同与其紧密相关的可靠性和质量领域一样，保证分析起来可能比较困难，但是它却是人们所期待和获得的（经常是在没有意识到的情况下）。例如，人们可能经常性地得到同事的产品建议但可能没有考虑到这种建议提供了保证。

保证是一种信任程度，而不是如何实际保护系统的真实措施。这种区分是重要的，因为确切了解系统的实际安全状况是非常困难的，很多情况下是不可能的。

保证并不是一件容易的事情，它难以描述更难量化。因此，很多人将保证称为对控制能够正常工作的“模糊而温暖的感觉”。但是，有两件事可能使其成为更严格的方法：（1）谁需要得到确定？以及（2）可以获得什么类型的保证。需要得到确定的人是对系统安全负有最终责任的管理官员。在联邦政府中，此人是授权和审批官员。

有许多获得保证的方法。出于讨论的目的，本章按照常见的系统生命周期对保证进行分类。本章首先讨论保证的计划，然后提供两类保证的方法和工具：（1）设计和实施保证，以及（2）运行保证。运行保证又被分为审计和监视。

设计和实施保证与运行保证的界线可能比较模糊。像配置管理或审计这样的问题在运行保证中讨论，而它们在系统开发中也可能是很重要的。讨论倾向于关注设计和实施保证的技术问题，要注意的是其分类在一定程度上是人为的，实际上存在交叉内容。

9.1 审批和保证
审批是管理官员对系统安全适当性的正式接受。看待计算机安全审批的最好方式是将其视为质量控制的一种形式。它强迫管理者和技术人员一起工作，以发现在给定安全需要、技术约束、运行约束和使命或业务需求条件下可行的、具有成本效益的解决方案。审批过程迫使管理者作出能够提供适当安全防范措施的关键决定，从而体现和执行其在保护系统方面的角色。为了作出良好的决定，他们需要基于技术和非技术防范措施的可靠信息。这些信息包括：

• 技术特性（它们如预期的那样运行吗？）
• 运行措施（系统是根据发布的规程操作的吗？）
• 整体安全（有技术特性和运行措施没有解决的威胁吗？）
• 剩余风险（它们是可接受的吗？）

计算机系统应该在投入运行前得到批准，并且在系统重大更改或一定时间间隔后定期进行重新审批。即使系统一开始没有得到审批，审批过程还是可以从任意时刻开始。第8章更深入讨论了审批。

9.1.1 审批和保证
保证虽然极其重要，但并不是审批的唯一内容。如图所示，保证涉及到技术措施以及（1）按照一系列安全需求和规格说明或者（2）按照一般的质量原则进行操作的规程。审批也涉及到系统安全需求是否正确和得到很好实施，质量水准是否足够高这样的问题。这些活动在第7和8章论述。

9.1.2 选择保证方法
审批官员对系统需要多少以及何种保证作出最后决定。为了作出明智的决定，它应源于审批官员认为适当的安全检查，如风险评估或其它研究项目（如认证）。审批官员需要设身处地地分析保证花费的利弊、控制的成本和对机构的风险。在审批过程后期，审批官员将是接受剩余风险的人。所以应该与审批官员协调保证方法的选择。

在选择保证方法时，应该权衡保证的需要及其花费。保证可能会非常昂贵，特别是在进行广泛的测试时。每种方法在花费和能够实际提供何种保证方面都存在优势和劣势。方法的组合经常可以提供很好的保证，因为没有一种方法是完美的，而且这样能够比广泛测试花费更少的成本。

审批官员不是唯一的仲裁者。也应该咨询使用系统的其它官员。（例如，依赖于供应系统的生产经理应该提供供应系统方面的意见。）另外，可能会有审批官员控制范围以外并对方法选择产生影响的约束。例如，一些方法可能过度限制联邦信息处理资源采购方面的竞争，或可能违背机构的隐私政策。某些保证方法是机构政策或指令要求的。

9.2 计划和保证
无论对于新系统还是系统升级，保证计划都应该始于系统生命周期的计划阶段。保证计划为系统其它计划的制定提供帮助。如果系统要接受广泛测试，系统就应以协助这种测试进行的方式构建。

保证计划帮助管理者在何种保证具有成本效益方面做出决策。如果管理者等到系统建成或购买回来后再考虑保证，获得保证的方式就可能比管理者早期就进行计划要少很多，而且余下的保证选项可能更昂贵。

9.3 设计和实施保证
设计和实施保证与系统、应用或组件特性是否满足安全需求和规格说明以及其设计和构建是否良好有关。第8章论述了安全需求和规格说明的来源。设计和实施保证考察系统的设计、开发和安装。虽然设计和实施保证通常与系统生命周期的开发/采购和实施阶段相关；但是在整个生命周期中发生系统更改的情况下也都应该对此加以考虑。

如前所述，保证可以涉及到产品或系统是否满足一系列安全规格说明，或是否能提供其它质量方面的证据。本节概述获得设计和实施保证的主要方法。

9.3.1 测试和认证
测试可能涉及到所构建、实施或运行系统的质量。因此，可以在开发周期、系统安装后以及整个运行阶段进行。一些常见的测试技术包括功能测试（考察某功能是否按照其需求运作）或渗透测试（考察是否能够绕过安全限制）。这些技术手段可以从一般的尝试性测试到使用计量装置、自动工具或多种精密测试工具的深入研究。

认证是依据特定安全需求序列测试组件或系统的正式过程。认证一般由独立检查人员执行，而不是与构建系统有关的人。认证对于复杂或高风险系统经常具有更高的成本效益。。不太正式的测试可以用于低风险系统。可以在系统设计和实施过程的多个阶段进行认证，可以在实验室、运行环境或分别在两个环境中进行。

9.3.2 NIST符合性测试和验证套件
NIST创建了验证套件和符合性测试来确定产品（软件、硬件、固件）是否满足特定的标准。这些测试套件是为特定标准开发的并使用了很多方法。对标准的符合之所以重要是由很多原因造成的，包括互操作性或所提供安全的强度。NIST每季度都发表一个已验证产品清单。

9.3.3 使用先进的和可信的开发
无论是在商业成品或是更加客户化的系统开发过程中，使用先进的或可信的系统体系、开发方法或软件工程技术都可以提供保证。例子包括安全设计和开发检查、形式化模型、数学验证、ISO9000质量技术或使用安全体系概念，如受信计算基或参考监视器。

9.3.4 使用可靠的体系
一些系统结构具有更加高的内在稳定性，如使用容错、冗余、映像或廉价磁盘冗余阵列（RAID）特性。这些例子主要与系统的可用性相关。

9.3.5 使用可靠的安全
可靠安全的一个因素是安全使用的简便性概念，它提出容易保护的系统更可能是安全的。当系统的初始默认设置是“最安全”选项时，安全特性最可能被使用。另外，如果系统不使用未经“真实”使用环境测试的非常新的技术（经常被称为“未成熟”技术），那么它可能被认为是更可靠的。相反的，使用旧的、经过良好测试软件的系统包含的错误可能会更少。

9.3.6 评价
产品评价一般包括测试。评价可以由各种类型的机构进行，包括国内和国外的政府机构；独立机构如贸易和专业机构；其它供应商或商业组织；个人用户或用户公会。商业文献的产品评论是一种评价形式，更正式的检查是依据特定标准进行的。使用评价的重要考虑因素包括评价组织的独立性程度、评价标准是否反映了所需的安全特性、测试的严格性、测试环境、评价的使用期、评价机构的能力以及评价组织为评价设置的限制条件（如关于威胁或运行环境的假设）。

9.3.7 保证文档
描述安全需求以及其如何被满足的能力可以反映系统和产品设计者对相关安全问题的理解程度。没有对需求的良好理解，设计者就不大可能满足它们。

保证文档可以涉及到针对系统或是针对组件的安全。系统级文档应该描述系统的安全需求以及如何满足这些需求，包括应用、操作系统和网络之间的相互关系。系统级文档不仅涉及到操作系统、安全系统和应用，它还描述系统的集成和在特殊环境中的部署。组件文档通常是关于成品的，而通常系统设计者或实施者会制定系统文档。

9.3.8 运行于类似环境的产品审批
运行于类似环境的产品或系统的审批可以被用来提供一些保证。但是，重要的是要认识到审批是针对特定环境和系统的。因为审批对风险和利益作出平衡，所以相同的产品在一种环境中可能得到使用批准，而即使是相同的审批官员却可能不会批准其在另一个环境中的运行。

9.3.9 自我认证
供应商、集成商或系统开发商的自我认证在不依赖于公平或独立机构的条件下对系统进行技术评价以考察其满足相关安全需求的情况。虽然它并不能做到不偏不倚，但还是可以提供保证。自我认证者的信誉是可以了解到的，可以阅读认证结果报告来确定安全需求是否被定义以及是否进行了有意义的检查。

混合认证也是可能的，可以由独立机构通过分析结果报告、抽查或其它监督的形式对其工作进行协助或检查。这种方法可以结合自我认证的低成本和快速以及独立检查的公正性的优点。但是，这种检查可能没有独立评价或测试那么全面。

9.3.10 担保、完整性条款和责任
担保是另一种保证的来源。如果制造商、生产商、系统开发者或集成商想要在一定时间范围内或下一个版本中更正错误，这会给系统管理者一种对产品和产品质量有承诺的感觉。完整性条款是产品的正式声明或认证。它可以通过（a）修复部件（担保）或（b）赔偿因无法实现完整性条款而带来的损失（责任）的方式进行支持。

9.3.11 制造商发表的声明
制造商或开发商发表的声明或正式公告提供了基于本身信誉的程度较低的保证。

9.3.12 分配保证
了解到达的软件没有受到更改经常是很重要的，尤其是在通过电子方式分配时。在这种情况下，检查位或数字签名可以提供代码未被更改的高度保证。反病毒软件可以用于检查源于可靠性未知地点（如公告牌）的软件。

9.4 运行保证
设计和实施保证涉及到构建于系统中的安全特性的质量。运行保证涉及到系统的技术特性是否能够被绕过或有缺陷以及所需的规程是否被遵循。它不涉及因系统及其操作或威胁环境的更改引起的系统安全需求的更改。（第8章涉及到这些更改）。

在系统生命周期的运行阶段安全有降低的趋势。系统用户和操作员发现有意无意绕过或破坏安全的新方式（特别是在感觉到绕过安全会改善功能性时）。用户和管理员经常认为其系统和自身不会出问题而跨越安全。严格遵循规程的情况很少见，它们会变得过时，系统管理也经常会犯错误。

机构使用两种基本方法来维持运行保证：

• 系统审计 － 一次性或定期评价安全的事件。审计范围多种多样：它可能出于重新审批的目的检查整个系统，也可能调查一个异常事件。
• 监视 － 检查系统、其用户或环境的持续活动。

通常，越是“实时”的活动，越是被归于监视类型。这种区别会产生一些不必要的文字游戏，特别是与系统产生的审计跟踪有关时。每天或每周检查审计跟踪（非受权访问尝试）通常是监视，而对几个月的审计跟踪进行历史检查（追踪特定用户的行动）可能就是审计。

9.4.1 审计的方法和工具
用来支持运行保证的审计检查系统是否满足包括系统和机构政策在内的明确或暗示的安全需求。一些审计还检查安全需求是否适当，但是这超出了运行保证的范畴。（参见第8章）不太正式的审计经常被称作安全检查。

审计可以是自我管理或独立进行的（内部或外部）。两种方式都可以提供技术、规程、管理或其它安全方面的有效信息。自我审计和独立审计的重要区别是客观性。由系统管理人员进行的检查经常被称为自我审计/评估，它存在内在的利益冲突。系统管理人员可能不太愿意提出计算机系统设计低劣或者操作马虎之类的意见。而另一方面，他们可能很愿意改善系统的安全状况。另外，他们了解系统并可能发现隐藏的问题。

相反的，独立审计机构与系统没有特殊的利益关系。独立审计可以由专业审计人员根据普遍接受的审计标准进行。

有很多方法和工具可以被用于系统审计，下面描述一些方法和工具。其中有些内容有互相重叠的关系。

9.4.1.1 自动化工具
即使对于小的计算机系统，人工检查安全特性也是一项繁重工作。自动化工具甚至能够使检查大型计算机系统的各种安全问题成为可能。

有两种自动化工具：（1）主动工具，通过攻击找到缺陷，以及（2）被动测试，仅检查系统并通过系统的状态推断存在的问题。

自动化工具可以被用于帮助发现各种威胁和缺陷，如不恰当的访问控制或访问控制配置、脆弱的口令、系统软件缺乏完整性或者没有充分进行相关软件的升级和修补。这些工具经常在发现缺陷方面非常成功而且有时被黑客用来攻击系统。不充分利用这些工具会使系统管理员处于不利的地位。很多工具使用起来很简单，但是有些程序（如对于大型机系统的访问控制审计工具）需要特殊的技巧来使用和解释。

9.4.1.2 内部控制审计
审计员可以检查运行中的控制并确定其是否有效。审计员会经常分析基于计算机和不基于计算机的控制。其使用的技术包括询问、观察和测试（对控制本身和数据）。审计还探测非法活动、错误、异常或违背法律和法规的行为。还可能使用下面讲到的安全检查列表和渗透测试。

9.4.1.3 安全检查列表
在政府中，计算机安全计划提供了对系统进行审计的检查列表。第8章讨论的计划概述了系统的主要安全考虑，包括管理、运行和技术问题。使用计算机安全计划的一个优点是它反映系统的独特安全环境，而不是通用的控制清单。还可以制定包括国家或机构安全政策和措施（经常被称为基线）的其它检查列表。也可以使用“普遍接受的安全措施”（GSSP）。要注意的是，与列表不同也并不意味着错误，因为它们可能适合于系统的特殊环境或技术约束。

检查列表也被用于验证是否从安全角度检查了对系统的更改。审计一般要检查系统的配置以发现已发生但没有从安全角度分析的重大更改（如接入互联网）。

9.4.1.4 渗透测试
渗透测试可以使用许多方法来进行系统入侵尝试。除了如上所述使用主动的自动化工具以外，渗透测试还可以采用“人工”方式。大多数有价值的渗透测试类型都是使用可能真正用来攻击系统的方法。对于互联网上的主机，这肯定包括自动化工具。对于许多系统，松懈的规程或缺乏对应用的内部控制是渗透测试瞄准的常见缺陷。另一种方法是“社会工程”，这涉及到使用户或管理员泄漏系统信息，包括其口令。

9.4.2 监视方法和工具
安全监视是查找缺陷和安全问题的持续行为。许多方法与审计所使用的类似，但更频率更高，且自动化工具是在实时状态下使用的。

9.4.2.1 系统日志的检查
如第8章所述，对系统生成日志的定期检查可以探测安全问题，包括超越访问授权或在非正常时间获得系统访问的尝试。

9.4.2.2 自动化工具
多种类型的自动化工具监视系统的安全问题。下面是一些例子：

• 病毒扫描是检查病毒感染的常见方法。这些程序测试可执行程序文件中出现的病毒。

• 检查校验和假设程序文件在更新之间不会更改。它们通过基于特定文件的内容生成算术值来实现。在检验文件的完整性时，生成当前文件的校验和并与以前生成的值进行比较。如果两个值相等，文件的完整性就得到了验证。检查校验和程序能够探测病毒、木马、由于硬件故障造成的对文件的意外更改以及对文件的其它更改。但是它们有可能被系统入侵者更换。还可以使用数字签名。

• 口令破解使用字典（可以是“常规”字典或者易于猜测口令的特殊字典）检查口令并且还检查口令是否是用户识别码的变换。特殊字典条目的例子可以是当地体育运动队和明星的名字；常见变换可以是用户识别码的反向拼写。

• 完整性校验程序可以被应用程序用来查找对数据的篡改、错误和遗漏。这些技术包括一致性和合理性检查以及数据录入和处理的验证。这些技术可以根据预期值或取值范围检查输入或处理的数据项；分析交易的正确流向、顺序和授权；或检查数据项预期的相互关系。这些程序组成了处理的重要一环，因为它们能够被用来确定人们是否无意或有意做了不应该做的，他们会被发现的。许多这样的程序依赖于对每个用户行为的记录。

• 入侵探测器分析系统的审计跟踪，特别是登录、连接、操作系统调用和各种命令参数，因为这些活动能够体现非受权行为。入侵探测的内容包含在第12和18章中。

• 系统性能监视实时分析系统性能日志以发现可用性问题，包括主动攻击（如1988年互联网蠕虫）以及网络缓慢和崩溃。

9.4.2.3 配置管理
从安全角度来看，配置管理为系统运行于正确版本（配置）以及对任何更改进行安全方面的检查提供保证。配置管理可以被用于帮助确保更改是在确定和受控环境下进行并且不会无意中损害到任何系统特性，包括安全。一些机构特别是拥有非常大型系统的机构使用配置控制委员会进行配置管理。当有委员会存在时，计算机安全专家参与其中是很有帮助的。在任何情况下，计算机安全官员参与到系统管理决策中都是有益的。

对系统的更改可能会牵涉到安全问题，因为它们可能引入或消除缺陷，并且重大更改可能需要更新应急计划、风险分析或审批。

9.4.2.4 商业文献/出版物/电子新闻
除了监视系统以外，监视外部资源的信息也是有用的。如书面和电子的商业文献会有关于安全缺陷、补丁和其它影响到安全的信息。事件响应组论坛（FIRST）有接收威胁、缺陷和补丁信息的邮件列表。

9.5 相互关系
保证是关系到本手册讨论的每个控制和防范措施的问题。用户识别码和访问特权是否保持更新状态？应急计划是否得到测试？审计跟踪是否会被篡改？这里要强调的重要一点是保证不仅是针对技术控制的，也同样针对运行控制。虽然本章关注的是信息系统的保证，但是对管理控制正常工作的保证也很重要。安全项目是否有效？政策是否被理解和遵循？如本章介绍中提到的，保证的需要比人们通常意识到的更广泛。

生命周期保证与系统生命周期的安全计划紧密相关。系统可以被设计为易于进行对特定安全需求的各种测试。通过在过程早期对这些测试的计划能够降低成本；在一些情况下，没有适当的计划，就无法获得某些类型的保证。

9.6 费用考虑
有许多获得安全特性正常工作保证的方法。由于保证方法有容易定性但不容易定量的趋势，所以需要对其进行评价。保证也可能很昂贵，尤其在进行广泛测试时。对付出的成本和获得的保证进行评价对于做出最合算的决策是有用的。通常，人员的费用驱动了保证成本的上升。自动化工具通常在处理特殊问题时作用有限，虽然它们可能比较便宜。

参考书目
Borsook, P. "Seeking Security." Byte. 18(6), 1993. pp. 119-128.

Dykman, Charlene A. ed., and Charles K. Davis, asc. ed. Control Objectives Controls in an Information Systems Environment: Objectives, Guidelines, and Audit Procedures. (fourth edition). Carol Stream, IL: The EDP Auditors Foundation, Inc., April 1992.

Farmer, Dan and Wietse Venema. "Improving the Security of Your Site by Breaking Into It." Available from FTP.WIN.TUE.NL. 1993.

Guttman, Barbara. Computer Security Considerations in Federal Procurements: A Guide for Procurement Initiators, Contracting Officers, and Computer Security Officials. Special Publication 800-4. Gaithersburg, MD: National Institute of Standards and Technology, March 1992.

Howe, D. "Information System Security Engineering: Cornerstone to the Future." Proceedings of the 15th National Computer Security Conference, Vol 1. (Baltimore, MD) Gaithersburg, MD: National Institute of Standards and Technology, 1992. pp. 244-251.

Levine, M. "Audit Serve Security Evaluation Criteria." Audit Vision. 2(2). 1992, pp. 29-40. National Bureau of Standards. Guideline for Computer Security Certification and Accreditation. Federal Information Processing Standard Publication 102. September 1983.

National Bureau of Standards. Guideline for Lifecycle Validation, Verification, and Testing of Computer Software. Federal Information Processing Standard Publication 101. June 1983.

National Bureau of Standards. Guideline for Software Verification and Validation Plans. Federal Information Processing Standard Publication 132. November 1987.

Nuegent, W., J. Gilligan, L. Hoffman, and Z. Ruthberg. Technology Assessment: Methods for Measuring the Level of Computer Security. Special Publication 500-133. Gaithersburg, MD: National Bureau of Standards, 1985.

Peng, Wendy W., and Dolores R. Wallace. Software Error Analysis. Special Publication 500-209. Gaithersburg, MD: National Institute of Standards and Technology, 1993.

Peterson, P. "Infosecurity and Shrinking Media." ISSA Access. 5(2), 1992. pp. 19-22. Pfleeger, C., S. Pfleeger, and M. Theofanos, "A Methodology for Penetration Testing." Computers and Security. 8(7), 1989. pp. 613-620.

Polk, W. Timothy, and Lawrence Bassham. A Guide to the Selection of Anti-Virus Tools and Techniques. Special Publication 800-5. Gaithersburg, MD: National Institute of Standards and Technology, December 1992.

Polk, W. Timothy. Automated Tools for Testing Computer System Vulnerability. Special Publication 800-6. Gaithersburg, MD: National Institute of Standards and Technology, December 1992.

President's Council on Integrity and Efficiency. Review of General Controls in Federal Computer Systems. Washington, DC: President's Council on Integrity and Efficiency, October 1988.

President's Council on Management Improvement and the President's Council on Integrity and Efficiency. Model Framework for Management Control Over Automated Information System. Washington, DC: President's Council on Management Improvement, January 1988.

Ruthberg, Zella G, Bonnie T. Fisher and John W. Lainhart IV. System Development Auditor. Oxford, England: Elsevier Advanced Technology, 1991.

Ruthburg, Zella, et al. Guide to Auditing for Controls and Security: A System Development Life Cycle Approach. Special Publication 500-153. Gaithersburg, MD: National Bureau of Standards, April 1988.

Strategic Defense Initiation Organization. Trusted Software Methodology. Vols. 1 and II. SDI-SSD- 91-000007. June 17, 1992.

Wallace, Dolores, and J.C. Cherniasvsky. Guide to Software Acceptance. Special Publication 500- 180. Gaithersburg, MD: National Institute of Standards and Technology, April 1990.

Wallace, Dolores, and Roger Fugi. Software Verification and Validation: Its Role in Computer Assurance and Its Relationship with Software Product Management Standards. Special Publication 500-165. Gaithersburg, MD: National Institute of Standards and Technology, September 1989.

Wallace, Dolores R., Laura M. Ippolito, and D. Richard Kuhn. High Integrity Software Standards and Guidelines. Special Publication 500-204. Gaithersburg, MD: National Institute of Standards and Technology, 1992.

Wood, C., et al. Computer Security: A Comprehensive Controls Checklist. New York, NY: John Wiley & Sons, 1987.