军用计算机安全评估准则

军用计算机安全评估准则GJB2646－96Militarycomputersecurityevaluationcriteria（国防科学技术工业委员会1996年6月4日发布1996年12月1日实施）一范围1.1主题内容本标准规定了评估计算机安全的准则，等级划分及每个等级的安全要求。1.2适用范围本标准适用于军用计算机安全评估，主要面向操作系统，也适用于其他需要进行安全评估的计算机。二引用文件GJB2255-95军用计算机安全术语三定义3.1术语本章未列入的术语,见GJB2255。3.1.1自主保护discretionaryprotection辨识用户身份和他们的需求,限制用户使用信息的访问控制的方法。3.1.2强制访问控制mandatoryaccesscontrol根据客体所包含信息的敏感性以及主体访问此类敏感信息的权限,限制主体访问客体的方法。3.1.3安全等级securitylevel为表示信息的不同敏感度,按保密程度不同对信息进行层次划分的组合或集合。3.1.4审计audit对影响系统安全的各种活动进行记录并为系统安全员提供安全管理依据的程序。3.1.5隔离isolation为防止其他用户或程序的非授权访问,把操作系统、用户程序、数据文件加以彼此独立存储的行为。3.1.6可信计算基(TCB)trustedcomputingbase计算机系统内保护装置的总体,包括硬件、固体、软件和负责执行安全策略的组合体。它建立了一个基本的保护环境并提供一个可信计算系统所要求的附加用户服务。3.1.7敏感标号sensitivitylabel表示客体安全级别并描述客体数据敏感性的一组信息,可信计算基中把敏感标号作为强制访问控制决策的依据。3.1.8系统完整性systemintegrity系统不能以非授权手段被破坏或修改的性质。3.1.9描述性顶层规格说明(DTLS)descriptivetop-levelspecification用自然语言、形式化程序设计符号,或两者结合写在的一种最高层的设计规格说明书。3.1.10形式化顶层规格说明(FILS)formaltop-levelspecification用形式化数学语言写成的一种高层规格说明书。使用这种规格,可以从理论上证明假定的形式化要求与系统规格的一致性。3.1.11最小特权原则principleofleastprivilege为完成特定任务,授予主体所需要的最小访问特权的过程、策略。3.1.12分层密级hierarchicalclassification用层次结构的方式将主体和客体分成不同的保密等级。3.1.13粒度granularity一次访问操作所涉及到的访问对象的大小。四一般要求计算机系统安全将通过使用特定的安全特性控制对信息的访问,只有被授权的人或为人服务的操作过程可以对信息进行访问。在本准则中提出了以下六条要求。4.1安全策略必须有一种由系统实施的、明确的和定义好的安全策略。对于主体和客体,必须有一个由系统使用的规则集合。利用这个规则合来决定是否允许一个给定的主体对一特定客体访问。对于处理敏感信息的计算机系统必须施加一种强制安全策略来有效地实现访问规则。这些规则要求包括:任何人如果缺少适当的安全许可证都不能获得对敏感信息的访问;同时也要求有自主的安全控制,以保证只有指定的用户或用户组才可以获得对数据的访问。4.4.2标号客体应当按敏感程度加以标号,访问控制标号必须与客体联系起来。为了控制对存储在计算机内的信息进行访问,根据强制安全策略规则,每个客体必须有一个标号,这个标号表示客体的敏感级别并记录哪些主体可以对特定的客体进行访问的方式。4.3标识每个主体都必须在验明身份(身份标识)后才能对客体进行访问。每次对信息的访问都应标识谁在要求访问,他有权访问什么信息？标识和授权信息必须由计算机系统在秘密情况下进行维护并与完成某些与安全有关动作的每个活动元素结合起来。4.4责任对审计信息应有选择地保存并妥善加以保护,以便以后对影响安全的动作进行跟踪,查清责任。一个可信系统应将与安全有关的事件记录在一个审计日志中,为了降低审计费用并提高分析效率,必须具有选择审计事件的能力。审计信息必须很好地保护,以防修改和未经授权的毁坏。4.5保证计算机系统应包括能使上述各条要求实现所必须的硬件和软件机制,必须有一批硬件和软件控制,这些机制可嵌入操作系统内,并用秘密方法执行指定的任务。这些机制应在文件中写清楚并能独立检验其结果,以便能独立地考评它们是否充分。4.6连续保护对实现上述基本要求的可信机制必须能连续地提供保护,以对抗未授权的篡改。如果实现上述策略的硬件和软件机制本身遭到未授权的修改或破坏,那么这个计算机系统是做不到真正安全的。连续保护要求与计算机系统的整个生存周期有着直接的关系。五详细要求本准则根据上述六条要求,按处理的信息等级和采取的相应措施,将计算机系统的安全分为四等八级别。D为最低等级,随着等级的提高,系统可信度也随之增加,风险逐渐减少。注:在本标准中,凡是使用黑体字的部分均表示在较低等级中不包含那些要求,或表示对已定义要求的变动和增加;凡是不使用黑体字的部分均表示这些要求与较低等级的那些对应要求相同。5.1D等:最小保护本等只含一级,它是为那些已作评估,但不能满足较高评估等级要求的系统而准备的。5.2C等:自主保护本等分为C1和C1两个级别,它主要提供自主访问控制保护,并具有对主体责任和他们的初始动作审计的能力。5.2.1C1级:自主安全保护C1级的可信计算基(TCB)通过提供用户与数据的分离来标称满足无条件安全要求。它包括某种形式的可信控制,以便能在个体基础上执行访问限制,即外表上允许用户保护项目和保护私有数据,并阻止其他用户意外地读取或破坏他们的数据。C1级环境是在同一敏感等级上处理数据的那些协同用户所要求的。下述是C1级的最低要求。5.2.1.1安全策略5.2.1.1.1自主访问控制TCB应在计算机系统已命名的用户和已命名的客体(如文件和程序)之间进行定义和控制访问。实施机制(如自身/组/公共控制,访问控制表)应允许用户通过已命名的单个用户或已定义的组或两者来规定和控制这些客体的共享。5.2.1.2责任5.2.1.2.1标识和鉴别在开始执行TCB仲裁的任何其他动作之前,TCB要求用户自己向TCB作出标识。因此,TCB应使用一种受保护的机制(如口令)来鉴别用户的身份。TCB应保护鉴别数据,以使它不能被任何未授权用户访问。5.2.1.3保证5.2.1.3.1操作保证5.2.1.3.1.1系统体系结构TCB应维持它自己执行的区域,以保护它免受外部干预或篡改(如对它代码或数据结构的修改)。由TCB控制的资源可以是计算机系统中已定义的主体和客体的子集。5.2.1.3.1.2系统完整性应提供硬件特性或软件特性或同时提供两者,用于定期地验证TCB硬件和固件单元的运行正确性。5.2.1.3.2生存周期保证5.2.1.3.2.1安全测试应对计算机系统的安全机制进行测试,并按系统文档的要求工作。测试应当保证:没有明显的让未授权用户旁越的途径,或没有其他击败TCB安全保护机制的方法,见附录C(补充件)。5.2.1.4文档5.2.1.4.1安全特性的用户指南用户文档中的摘要、章节或手册应描述由TCB提供的保护机制,有关它们使用的指南以及它们如何相互作用。5.2.1.4.2可信设施手册向计算机系统管理员提供的手册应提出有关功能和特权的警告,这种特权在一个安全设施运行时应受到控制。5.2.1.4.3测试文档系统开发者应向评估者提供一个文档,该文档描述测试计划,怎样测试安全机制的测试过程,以及安全机制的功能测试结果。5.2.1.4.4设计文档设计文档应当具有描述制造厂家的保护宗旨以及怎样把这种宗旨转换成TCB的解释。如果TCB是由不同的模块组成,则应描述这些模块之间的接口。5.2.2C2级:可控制访问保护这一级实施一种比C1级粒度更细的自主访问控制。可通过注册过程、与安全相关事件的审计以及资源隔离等措施,使用户对它们的活动分别负责。下述是C2级的最低要求。5.2.2.1安全策略5.2.2.1.1自主访问控制TCB应在计算机系统已命名的用户和已命名的客体(如文件和程序)之间进行定义和控制访问。实施机制(如自身/组/公共控制,访问控制表)应允许用户通过已命名的单个用户或已定义的单个用户组或两者来规定和控制这些客体的共享,同时应提供控制,以限制访问权利的扩散。自主访问控制机制应当按明确的用户动作或按默认值向客体提供保护,避免无授权的访问。这些访问控制应既能包括或又能排除单用户粒度的访问。如已不具有访问许可的用户要得到对一个客体的访问许可,只应当由授权用户分配。5.2.2.1.2客体重用在向一个主体初始转让、分配或重分配TCB的未使用存储器客体池之前,应废除所有包含在存储器客体内的信息授权。对已释放回系统的客体,有访问权的任何主体都不能使用任何先前主体动作产生的信息,包括已加密表示的信息。5.2.2.2责任5.2.2.2.1标识和鉴别在开始执行TCB仲裁的任何其他动作之前,TCB要求用户自己向TCB作出标识。因此,TCB应使用一种受保护的机制(如口令)来鉴别用户的身份,TCB应保护鉴别数据,以使它不能被任何未授权用户访问。TCB应通过提供极好的保护计算机系统各个单个用户的能力来实现其责任。TCB还应当提供把这种身份与该单个用户发生的所有可审计动作相联系的能力。5.2.2.2.2审计TCB应能建立、维持和保护对它所保护的客体访问的审计跟踪,防止修改、未授权访问或破坏。审计数据应受TCB保护,以便对它的读访问被限制在对审计数据已授权的那些用户上。TCB应能记录下述类型的事件:标识和鉴别机制的使用;把客体引入到一个用户的地址空间(如打开文件,起动程序);删除客体;计算机操作员、系统管理员或系统安全员或后两者同时所发生的动作;以及其他有关的安全事件。对每个已记录的事件,审计记录应标出:事件发生的日期和时间;用户、事件的类型;事件的成功或失败。对于标识和鉴别事件,请求源(如终端ID)也应包括在审计记录中。对于把客体引入用户地址空间的事件和客体删除事件,审计记录也应包括客体名。计算机系统管理员应能基于单个用户身份有选择地审计任一或多个用户的活动。5.2.2.3保证5.2.2.3.1操作保证5.2.2.3.1.1系统体系结构TCB应维持它自己执行的区域,以保护它免受外部干预或篡改(如对它的代码或数据结构进行修改)。由TCB控制的资源可以是计算机系统中已定义的主体和客体的子集。TCB应隔离被保护的资源,以使它们易受访问控制,并达到审计要求。5.2.2.3.1.2系统完整性应提供硬件特性或软件特性或同时提供两者,用于定期地验证TCB硬件和固件单元的运行正确性。5.2.2.3.2生存周期保证5.2.2.3.2.1安全测试应对计算机系统的安全机制进行测试,并按系统文档的要求工作,测试应当保证;没有明显的让未授权用户旁越的途径,或没有其他击败TCB安全保护机制的方法。测试还应包括搜索明显的缺陷,这些缺陷会使资源隔离破坏或会允许对审计或鉴别数据的未授权访问,见附录C(补充件)。5.2.2.4文档5.2.2.4.1安全特性的用户指南用户文档中的摘要,章节或手册应描述由TCB提供的保护机制,有关它们使用的指南以及它们如何相互作用。5.2.2.4.2可信设施手册向计算机系统管理员提供的手册应提出有关功能和特权的警告,这种特权在一个安全设施运行时应受到控制。对各类审计事件,应给出供检查和维护审计文件以及详细审计记录结构用的规程。5.2.2.4.3测试文档系统开发者应向评估者提供一个文档,该文档描述测试计划、如何测试安全机制的测试过程以及安全机制的功能测试结果。5.2.2.4.4设计文档设计文档应当具有描述制造厂家的保护宗旨以及怎样把这种宗旨转换成TCB的解释。如果TCB是由不同的模块组成,则应描述这些模块之间的接口。5.3B等:强制保护本等分为B1,B2和B3三个级别,它主要要求客体必须保留敏感标号,TCB利用它去施加强制访问控制保护。