军用计算机安全评估准则.docx
《军用计算机安全评估准则.docx》由会员分享，可在线阅读，更多相关《军用计算机安全评估准则.docx（38页珍藏版）》请在冰豆网上搜索。
军用计算机安全评估准则
军用计算机安全评估准则
GJB2646－96
Militarycomputersecurityevaluationcriteria
（国防科学技术工业委员会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责任
对审计信息应有选择地保存并妥善加以保护,以便以后对影响安全的动作进行跟踪,查清责任。
一个可信系统应将与安全有关的事件记录在一个审计日志中,为了降低审计费用并提高分析效率,必须具有选择审计事件的能力。
审计信息必须很好地保护,以防修改和XX的毁坏。
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利用它去施加强制访问控制保护。
在本等级中,对于计算机系统中大多数数据结构都必须带有敏感标号;系统开发者要提供安全策略模型,根据此模型生成TCB。
同时系统开发者也要提供TCB的技术规范说明并提供基准监控器概念已被实现的证据。
5.3.1B1级:
有标号的安全保护
B1级要求具有C2级的全部特征。
另外,必须提出安全策略模型的非形式化说明、数据标号以及已命名主体对客体的强制访问控制。
对输出信息必须有正确的标号能力;必须排除任何经测试而标识的缺陷。
下述是B1级的最低要求。
5.3.1.1安全策略
5.3.1.1.1自主访问控制
TCB应在计算机系统已命名的用户和已命名的客体（如文件和程序）之间进行定义和控制访问。
实施机制（如自身/组/公共控制,访问控制表）应允许用户通过已命名的单个用户或已定义的单个用户组或两者来规定和控制这些客体的共享,同时应提供控制,以限制访问权利的扩散。
自主访问控制应既能包括或又能排除单用户粒度的访问。
如已不具有访问许可的用户要得到对一个客体的访问许可,只应当由授权用户分配。
5.3.1.1.2客体重用
在向一个主体初始转让、分配或重分配TCB的未使用存储器客体池之前,应废除所有包含在存储器客体内的信息授权。
对已释放回系统的客体,有访问权的任何主体都不能使用任何先前主体动作产生的信息,包括已加密表示的信息。
5.3.1.1.3标号
与每个主体及在其控制下的存储器客体（如进程、文件、段、设备）有关的敏感标号应由TCB维护。
这些标号应被用作强制访问控制判断的依据。
为了输入无标号的数据,TCB应提出要求,并从授权用户那里接受该数据的安全等级,而且TCB应对主体的所有这类活动都能
进行审计。
5.3.1.1.3.1标号完整性
敏感标号应能准确地表示特定主体或客体的安全等级,主体和客体应以此发生关联。
当TCB输出时,敏感标号应能准确地和明确地表示内部标号,而且应与正在输出的信息发生联系。
5.3.1.1.3.2有标号信息的输出
TCB应对每个通信信道和I/O设备标明单级或多级。
这个标志的任何变化都应由人工实现,并可由TCB审计。
TCB应维持并且能够对安全等级的任何变化进行审定,或对与通信信道或I/O设备有关的等级进行审计。
5.3.1.1.3.2.1向多级设备的输出
当TCB将一客体输出到一个多级I/O设备时,与该客体有关的敏感标号也应输出。
应与输出信息相同的形式（如机器可读或人可读形式）驻留在同一物理媒体上。
当TCB在多级通信信道上输出或输入一客体时,该信道使用的协议应在敏感标号和被发送或被接收的有关信息之间提供明确的配对关系。
5.3.1.1.3.2.2向单级设备的输出
单级I/O设备和单级通信信道不需要维持其处理信息的敏感标号。
但是TCB应包含一种机制,TCB和一个授权用户按该机制可靠地与指定的单安全级的信息通信。
这种信息经由单级通信信道或I/O设备输入/输出。
5.3.1.1.3.2.3人可读标记的输出
计算机系统管理员应能规定与输出敏感标号有关的可打印标号名。
TCB应标记所有人可读的、编页的、具有人可读的敏感标号的硬拷贝输出（如行打印机输出）的开始和结束,它适当地1）表示输出敏感性。
TCB应按默认值标记人可读的、编页的、具有人可读的敏感标号的硬拷贝输出（如行打印机输出）每页的顶部和底部,它适当地1）表示该输出总的敏感性,或适当地1）表示该页信息的敏感性。
TCB应该按默认值，并以一种适当方法标记具有人可读的敏感标号的其他形式的人可读的输出（如图、图形）,它适当地1）表示该输出的敏感性。
这些标记默认值的任何滥用都应由TCB审计。
注:
1）人可读敏感标号的分层密级应等于与该标号输出有关的任何信息的最大分层密级;非分层等级应包括与该标号输出有关信息的全部非分层等级,但不包括其他非分层等级。
5.3.1.1.4强制访问控制
TCB应对全部主体及在其控制下的存储器客体（如进程、文件、段、设备）实施强制访问控制策略。
这些主体和客体,应给予敏感标号,这些标号是分层密级和非分层等级的结合,而且应作为强制访问控制判断的依据。
TCB应能支持两种或两种以上安全等级,见附录B（补充件）。
对于在受TCB控制的主体和客体之间的全部访问应遵循下列要求:
仅当主体安全级中的分层密级大于或等于客体安全级中的分层密级,而且主体安全级中非分层等级包括了客体安全级中全部非分层等级时,主体才能读一个客体。
仅当主体安全级中分层密级小于等于客体安全级中分层密级,而且主体安全级中非分层等级被包含在客体安全级中非分层等级时,主体才能写一个客体。
TCB应该用标识和鉴别数据来鉴别用户的身份,并用来保证那些相对于TCB外部的可代表单个用户建立动作的主体的安全等级和授权,并且受批准和授权的那个用户支配。
5.3.1.2责任
5.3.1.2.1标识和鉴别
在开始执行TCB仲裁的任何其他动作之前,TCB要求用户自己向TCB作出标识。
因此,TCB应维持鉴别数据,该数据包括用于验证单个用户身份的信息以及用于确定批准和授权单个用户的信息,这种数据应被TCB用来鉴别用户身份,以及保证那些相对于TCB外部的可代表单个用户建立动作的主体的安全等级和授权,并且受批准和授权那个用户支配.TCB应保护鉴别数据,以使它不能被任何未授权用户访问.TCB应通过提供极好的标识计算机系统各个单个用户的能力来实现其责任。
TCB还应具有把这种身份与该单个用户发生的所有可审计动作相联系的能力。
5.3.1.2.2审计
TCB应能建立、维持和保护对它所保护的客体访问的审计跟踪,防止修改、未授权访问或破坏。
审计数据应受TCB保护,以便对它的读访问被限制在对审计数据已授权的那些用户上。
TCB应能记录下述类型的事件:
标识和鉴别机制的作用;把客体引入到一个用户的地址空间（如打开文件,起动程序）;删除客体;计算机操作员、系统管理员或系统安全员或后两者同时所发生的动作;以及其他有关的安全事件。
TCB还应能审计人可读标记的输出的任何滥用。
对每个记录的事件,审计记录应标出:
事件发生的日期和时间;用户事件的类型;事件的成功或失败。
对于标识和鉴别事件,请求源（如终端ID）应包括在审计记录中。
对于把客体引入用户地址空间的事件和客体删除事件,审计记录应包括客体名和客体的安全等级。
计算机系统管理员应能基于每个用户身份或客体安全级或同时基于两者有选择地审计任一或多个用户的活动。
5.3.1.3保证
5.3.1.3.1操作保证
5.3.1.3.1.1系统体系结构
TCB应维持它自己执行的区域,以保护它免受外部干预或篡改（如对它的代码或数据结构进行修改）。
由TCB控制的资源可以是计算机系统中已定义的主体和客体的子集。
TCB应在其控制下通过提供不同的地址空间来维护进程隔离。
TCB应隔离被保护的资源,以使它们易受访问控制,并达到审计要求。
5.3.1.3.1.2系统完整性
应提供硬件特性或软件特性或同时提供两者,用于定期地验证TCB硬件和固件单元的运行正确性。
5.3.1.3.2生存周期保证
5.3.1.3.2.1安全测试
应对计算机系统的安全机制进行测试,并按系统文档的要求工作。
一个充分熟悉TCB特定实现的小组应详细分析和测试它的设计文档、源代码和目标代码。
他们的目标应是:
暴露全部设计和实现的缺陷,这些缺陷将允许一个TCB外的主体去读、更改或删除通常在TCB执行强制或自主安全策略时拒绝的数据,并且保证没有主体（尚未授权）能使TCB进入一种对其它用户发起的通信作出响应的状态。
所有已发现的缺陷应被纠正,或者其无效,而且TCB应重新测试,以验证已缺陷,并证明没有产生新的缺陷,见附录C（补充件）。
5.3.1.3.2.2设计规格说明和验证
应在计算机系统的整个生命周期内维持由TCB支撑的安全策略的非形式化或形式化模型,并应证实与它的原理相一致。
5.3.1.4文档
5.3.1.4.1安全特性的用户指南
用户文档中的摘要、章节或手册应描述由TCB提供的保护机制、有关它们使用的指南以及它们如何相互作用。
5.3.1.4.2可信设施手册
向计算机系统管理员提供的手册应提出有关功能和特权的警告,这种特权在一个安全设施运行时应受到控制。
对各类审计事件,应给出供检查和维护审计文件以及详细审计记录结构用的规程。
手册应描述操作员和管理员有关安全功能和用户安全特征的变化。
它应提供有关系统保护特性的一致和有效的用法。
如他们怎样互相作用,怎样安全地生成一个新的TCB;提供设施规程、警告和需要受控的特权,以便安全地操作该设施。
5.3.1.4.3测试文档
系统开发者应向评估者提供一个文档,该文档描述测试计划,如何测试安全机制的测试过程,以及安全机制的功能测试结果。
5.3.1.4.4设计文档
设计文档应当具有制造厂家的保护宗旨说明以及怎样把这种宗旨转换成TCB的解释。
如果TCB是由不同的模块组成,则应描述这些模块之间的接口。
由TCB实施的安全策略模型的非形式化或形式化描述应是可用的,而且提供一种解释来表示实施安全策略是足够的。
应当标识特定的TCB保护机制,而且给出一种解释表示它们满足该模型。
5.3.2B2级:
结构化保护
在B2级中,TCB是建立在对形式化安全策略模型清晰定义和提供文档的基础之上的。
该模型要求执行B1级所建立的自主和强制访问控制,并扩展到计算机系统的全部主体和客体。
另外,提出了隐蔽信道。
TCB必须是仔细地构成严格保护和非严格保护的单元。
TCB接口应定义恰当,而且TCB设计和实现能使它经受比较彻底的测试和比较安全的检查。
要加强鉴别机制,以支撑系统管理员和操作员功能的方式提供可信设施管理,而且要加强严格的配置管理控制。
该系统有相对的抗渗透能力。
下述是B2级的最低要求。
5.3.2.1安全策略
5.3.2.1.1自主访问控制
TCB应在计算机系统已命名的用户和已命名的客体（如文件和程序）之间进行定义和控制访问。
实施机制（如自身/组/公共控制,访问控制表）应允许用户通过已命名的单个用户或已定义的单个用户组或两者来规定和控制这些客体的共享,同时应提供控制,以限制访问权利的扩散。
自主访问控制机制应当按明确的用户动作或按默认值向客体提供保护,避免无授权的访问。
这些访问控制应既能包括或又能排除单用户粒度的访问。
如已不具有访问许可的用户要得到对一个客体的访问许可,只应当由授权用户分配。
5.3.2.1.2客体重用
在向一个主体初始转让、分配或重分配TCB的未使用存储器客体池之前,应废除所有包含在存储器客体内的信息授权。
对已释放回系统的客体,有访问权的任何主体都不能使用任何先前主体动作产生的信息,包括已加密表示的信息。
5.3.2.1.3
升级会员 