中国标准英文版 数据库收录: 159759 更新: 2024-05-26

[PDF] GB/T 18336.2-2015 - 自动发货. 英文版

标准搜索结果: 'GB/T 18336.2-2015'
标准号码内文价格美元第2步(购买)交付天数标准名称状态
GB/T 18336.2-2015 英文版 500 GB/T 18336.2-2015 3分钟内自动发货[PDF],有增值税发票。 信息技术 安全技术 信息技术安全评估准则 第2部分:安全功能组件 有效

基本信息
标准编号 GB/T 18336.2-2015 (GB/T18336.2-2015)
中文名称 信息技术 安全技术 信息技术安全评估准则 第2部分:安全功能组件
英文名称 Information technology -- Security techniques -- Evaluation criteria for IT security -- Part 2: Security functional components
行业 国家标准 (推荐)
中标分类 L80
国际标准分类 35.040
字数估计 275,273
发布日期 2015-05-15
实施日期 2016-01-01
旧标准 (被替代) GB/T 18336.2-2008
引用标准 ISO/IEC 15408-1
采用标准 ISO/IEC 15408-2-2008, IDT
起草单位 中国信息安全测评中心
归口单位 全国信息安全标准化技术委员会
标准依据 国家标准公告2015年第15号
提出机构 全国信息安全标准化技术委员会(SAC/TC 260)
发布机构 中华人民共和国国家质量监督检验检疫总局、中国国家标准化管理委员会
范围 为了安全评估的意图, GB/T 18336的本部分定义了安全功能组件所需要的结构和内容。本部分包含一个安全组件的分类目录, 将满足许多IT产品的通用安全功能要求。

GB/T 18336.2-2015: 信息技术 安全技术 信息技术安全评估准则 第2部分:安全功能组件
GB/T 18336.2-2015 英文名称: Information technology -- Security techniques -- Evaluation criteria for IT security -- Part 2: Security functional components
ICS 35.040
L80
中华人民共和国国家标准
代替 GB/T 18336.2-2008
信息技术 安全技术
信息技术安全评估准则
第2部分:安全功能组件
1 范围
为了安全评估的意图,GB/T 18336的本部分定义了安全功能组件所需要的结构和内容。本部分
包含一个安全组件的分类目录,将满足许多IT产品的通用安全功能要求。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文
件。凡是不注日期的引用文件,其最新版本(包括所有的修订版)适用于本文件。
ISO/IEC 15408-1 信息技术 安全技术 信息技术安全评估准则 第1部分:简介和一般模型(In-
andgeneralmodel)
4 概述
ISO/IEC 15408和本部分在此描述的相关安全功能要求,并不意味着是对所有IT安全问题的最终
回答。相反,本标准提供一组广为认同的安全功能要求,以用于制造反映市场需求的可信产品。这些安
全功能要求的给出,体现了当前对产品的要求规范和评估的技术发展水平。
本部分并不计划包括所有可能的安全功能要求,而是尽量包含那些在本部分发布时作者已知的并
认为是有价值的那些要求。
由于消费者的认知和需求可能会发生变化,因此本部分中的功能要求需要维护。可预见的是,某些
PP/ST作者可能还有一些安全要求未包含在本部分提出的功能要求组件中。此时,PP/ST的作者可考
虑使用ISO/IEC 15408之外的功能要求(称之为可扩展性),有关内容参见ISO/IEC 15408-1的附录A
和附录B。
4.1 本部分的结构
第5章是本部分安全功能要求使用的范型。
第6章介绍本部分功能组件的分类,第7章~第17章描述这些功能类。
附录A为功能组件的潜在用户提供了解释性信息,其中包括功能组件间依赖关系的一个完整的交
叉引用表。
附录B~附录 M提供了功能类的解释性信息。在如何运用相关操作和选择恰当的审计或文档信
息时,这些材料必须被看作是规范性说明。使用助动词“应”表示该说明是首要推荐的,但是其他的只是
可选的。这里只给出了不同的选项,具体的选择留给了PP/ST作者。
对于有关结构、规则和指南,编写PP或ST的人员应参见ISO/IEC 15408-1第3章和相关附录:
5 功能要求范型
本章描述了本部分安全功能要求中所使用的范型。讨论中所涉及的关键概念均以粗体/斜体突出
表示。本章并不打算替换或取代ISO/IEC 15408-1第3章中所给出的任何术语。
本部分是一个有关安全功能组件的目录,可用于规约一个评估对象(TOE)的安全功能要求。TOE
可以是软件、固件和/或硬件的集合,并可能配有用户和管理员的指导性文档。TOE可包含用于处理和
存储信息的资源,诸如电子存储媒介(如主存、磁盘空间)、外设(如打印机)以及计算能力(如CPU时
间)等,并且是评估的对象。
TOE评估主要关注的是,确保对TOE资源执行了所定义的安全功能要求(SFR)集。这些SFR定
义了一些规则,TOE通过这些规则来管制对其资源的访问和使用,从而实现对信息和服务的管控。
这些SFR可定义多个安全功能策略(SFP),以表达TOE必须执行的规则。每一个这样的SFP必
须通过定义主体、客体、资源或信息及其适用的操作,来明确说明该安全功能策略的控制范围。所有
SFP均由TSF(见下文)实现,其机制执行SFR中定义的规则并提供必要的能力。
TOE中为正确执行SFR而必须依赖的部分统称为TOE安全功能(TSF)。TSF由TOE中为了安
全执行而直接或间接依赖的所有软件、硬件和固件组成。
TOE可以是一个包含硬件、固件和软件的整体合一式的产品。
TOE也可以是一个分布式产品,内部由多个不同的部分组成,每一部分都为TOE提供特定的服
务,并且通过内部通信信道与TOE其他部分相连接。该信道可以小到为一个处理器总线,也可以是
TOE之内的一个网络。
当TOE由多个部分组成时,TOE的每一部分可拥有自己的那部分TSF,该部分通过内部通信信
道与TSF的其他部分交换用户数据和TSF数据,这种交互称为TOE内部传送。在这种情况下,这些
TSF的不同部分抽象地形成了执行SFR的组合型TSF。
TOE接口可能只局限在特定的TOE内部使用,或者也可允许通过外部通信信道与其他IT产品
交互。与其他IT产品的外部交互可以采取以下两种形式:
a) 其他“可信IT产品”的安全功能要求和TOE的安全功能要求已进行了管理方面的协调,并假
设这些其他可信IT产品已正确执行了其安全功能要求(例如:通过独立的评估)。在这种情况
下,信息交换被称为TSF间传送,因为它们存在于不同可信产品的TSF之间。
b) 其他IT产品可能是不可信的,被称为“不可信IT产品”。因此,它的SFR或是未知的,或这些
SFR的实现被视为是不可信赖的。在这种情况下,TSF促成的信息交换被称为TOE的外部
传送,因为在其他IT产品上没有TSF(或它的策略特征是未知的)。
一个接口集合,不管是交互式的(人机接口),还是可编程的(应用编程接口),通过这些接口,由
TSF协调对资源的访问,或者从TSF中获取信息,这一接口集合被称为TSF接口(TSFI)。TSFI定义
了为执行SFR而提供的TOE功能边界。
用户在TOE的外部。但为了请求由TOE执行且由SFR中定义的规则所控制的服务,用户要通
过TSFI和TOE交互。本部分关注两种类型用户:人类用户和外部IT实体。人类用户可进一步分为
本地用户和远程用户,本地用户通过TOE设备(如工作站)直接与TOE交互,远程用户通过其他IT产
品间接与TOE交互。
用户和TSF之间的一段交互期称为用户会话。可以根据各种因素来控制用户会话的建立,例如:
用户鉴别、时段、访问TOE的方法以及允许的(每个用户的或总的)并发会话数。
本部分使用术语“授权的”来表示一个用户持有执行某项操作的权力或特权。因此术语“授权用户”
表明用户允许执行由SFR定义的特定操作或一组操作。
为了表达分离管理责任的要求,相关的安全功能组件(来自FMT_SMR族)明确指出了所要求的管
理性角色。角色是预定义的一组规则,用于建立用户按此角色操作时所允许的与TOE之间的交互。
一个TOE可以支持任意多个角色的定义。例如,与TOE安全运行相关的角色可以包括“审计管理员”
和“用户账号管理员”。
TOE包含可用于处理和存储信息的资源。TSF的主要目标是对TOE所控制的资源和信息完整
而正确地执行SFR。
TOE资源能以多种方式组织并加以利用。但是,本部分作出了一个明确的区分,以便允许规范所
期望的安全特性。所有可通过资源来创建的实体,可用以下两种方式中的一种来刻画:实体可以是主动
的,意指它们是促使在TOE内部出现动作并导致信息操作的原因;或者,实体也可以是被动的,意指它
们或是产生信息的载体,或是存储信息的载体。
TOE中对客体执行操作的主动实体,被称为主体。TOE内可存在以下类型的主体:
a) 代表一个授权用户的那些实体(如UNIX进程);
b) 作为一个特殊功能进程,可依次代表多个用户的那些实体(如在客户/服务器结构中可能找到
的某些功能);
c) 作为TOE自身一部分的那些实体(如不代表某个用户的进程)。
本部分用于解决在上述各类主体上实施SFR的问题。
TOE中包含和接收信息,且主体得以在这些信息上执行操作的被动实体,称作客体。在一个主体
(主动实体)是某个操作的对象(例如进程间通信)的情况下,该主体也可以作为一个客体。
客体可以包含信息。引入这一概念是为了详细说明在FDP类中描述的信息流控制策略。
由SFR中各规则所控制的用户、主体、信息、客体、会话和资源,可具有某种属性。属性包含TOE
为了正确运行而使用的信息。某些属性,如文件名,可能只是提示性的,或者可用来标识单个资源,而另
一些属性,如访问控制信息,可能是专为执行SFR而存在的。后面这些属性通常称为“安全属性”。在
本部分的某些地方中,“属性”一词将用作“安全属性”的简称。另一方面,无论属性信息的预期目的如
何,均有必要按SFR的规定对属性施加控制。
TOE中的数据可分为用户数据和TSF数据,图1示意了它们之间的关系。用户数据是存储在
TOE资源中的信息,用户可以根据SFR对其进行操作,而TSF对用户数据并不赋予任何特殊的含义。
例如,电子邮件消息的内容是用户数据。TSF数据是TSF在按SFR的要求做决策时使用的信息。如
果SFR允许,TSF数据可以受用户的影响。安全属性、鉴别数据、由SFR中定义的规则,或为了保护
TSF及访问控制列表条目所使用的TSF内部状态变量都是TSF数据的例子。
有几个用于数据保护的SFP,诸如访问控制SFP和信息流控制SFP。实现访问控制SFP的机制依
据受控范围内的用户、资源、主体、客体、会话、TSF状态数据以及操作等的属性来建立策略决策。这些
属性用于管控主体操作客体的规则集中。
实现信息流控制SFP的机制依据受控范围内的主体和信息的属性以及管控主体操作信息的规则
来建立策略决策。信息的属性与信息一起由TSF予以处理,这些属性可能与载体属性相关联,或可能
是来源于载体中的数据。
图1 用户数据和TSF数据的关系
在本部分中处理的两种特殊类型的TSF数据-鉴别数据和秘密可以相同,也可以不同。
鉴别数据用于验证用户请求TOE服务时所声称的身份。最常用的鉴别数据形式是口令,为了使
安全机制有效,这一形式的鉴别数据需要保密。但是,并非所有形式的鉴别数据都需要保密,生物特征
鉴别设备(例如,指纹识别器、视网膜扫描仪)就不依赖于数据保密,而依赖于这些数据只能被一个用户
拥有,且不能被伪造。
本部分中使用的术语“秘密”,尽管可用于鉴别数据,也同样适用于其他为了执行某特定SFP而必
须保密的数据。例如,在强度方面,依靠密码技术保护信道信息机密性的可信信道机制,仅与防止密钥
未授权泄露机制是一样的。
6.1.2.5 审计
如果PP/ST中包含来自FAU类“安全审计”中的要求,审计要求要包含可供PP/ST作者选择的
可审计事件。这些由FAU_GEN“安全审计数据产生”族的组件支持的要求包括各种按不同详细级别
描述的安全相关事件。例如,一个审计记录可能包括下述动作:最小级---安全机制的成功使用;基本
级---对安全机制的使用以及涉及安全属性的信息;详细级---任何机制的配置变化,包括改变前后的
实际配置值。
显然可审计事件的分类是分级的。例如,当期望的审计数据产生级别满足基本级时,除非高级事件
仅仅比低级事件提供更多的细节,所有已标识为最小级和基本级的可审计事件都应通过适当的赋值操
作包括在PP/ST内。当期望的审计数据产生级别满足详细级时,所有标识为最小级、基本级和详细级
的可审计事件都应包括在PP/ST内。
在FAU类“安全审计”中,更详尽地解释了一些控制审计的规则。
6.1.3.2 功能元素
为每一组件提供了一组元素。每个元素都分别定义并且是自包含的。
功能元素是一个安全功能要求,该要求如果再进一步划分将不会产生有意义的评估结果。它是
ISO/IEC 15408中标识和认可的最小安全功能要求。
当构建包、PP或ST时,不允许从一个组件中只选择一个或几个元素,必须将组件的整套元素包含
在PP、ST或包中。
6.1.3.3 依赖关系
当一个组件不是自我充分的而需要依赖于其他组件的功能,或与其他组件交互才能正确发挥其功
能时,就产生了功能组件间的依赖关系。
每个功能组件都提供了一个对其他功能和保障组件依赖关系的完整列表。有些组件可能列出“无
依赖关系”。所依赖的组件又可能依赖其他组件。组件中提供的列表是直接的依赖关系。这只是为该
功能要求能正确实现其功能提供参考。间接依赖关系,也就是由所依赖组件产生的依赖关系,见本部分
附录A。值得注意的是,在某些情况下,依赖关系所提供的多个功能要求是可自由选择的,这些功能要
求中的任一个都足以满足依赖关系(例如FDP_UIT.1“数据交换完整性”)。
依赖关系列表标识出了为满足一个既定组件相关的安全要求,所必需的最少功能或保障组件。从
属于既定组件的那些组件也可用来满足依赖关系。
本部分指明的依赖关系是规范性的,在PP/ST中它们必须得到满足。在特定的情况下,这种依赖
关系可能不适用。只要在基本原理中说清不适用的理由,PP/ST作者就可以在包、PP或ST中舍弃该
依赖组件。
6.2 组件分类
本部分中组件的分组不代表任何正式的分类法。
本部分包含了族和组件的分类,它们是基于相关功能和目的进行的粗略分组,并且按字母顺序给
出。每个类的开始部分都有一个提示性框图,指出该类的分类法、类中的族和族中的组件。这个图对于
指明可能会存在于组件间的层次关系是有用的。
在功能组件的描述中,有一段文字指出了该组件和任何其他组件之间的依赖关系。
在每个类中,都有一个与图6类似的描述族层次关系的图。在图6中,第1个族(族1)包括了三个
有从属关系的组件,其中组件2和组件3都可以用来满足对组件1的依赖关系。组件3从属于组件2,
并且可以用来满足对组件2的依赖关系。
图6 示范类分解图
在族2中有三个组件,这三个组件不全都有从属关系。组件1和组件2不从属于其他组件。组件
3从属于组件2,可以用来满足对组件2的依赖关系,但不能满足对组件1的依赖关系。
在族3中,组件2、3、4都从属于组件1。组件2和组件3也都从属于组件1,但无可比性。组件4
从属于组件2和组件3。
这些图的目的是补充族中的文字说明,使关系的识别更容易。它们并不能取代每个组件中的 “从
属于:”的注释,这些注释是......
   
       隐私   ·  优质产品   ·  退款政策   ·  公平交易   ·  关于我们
宁德梧三商贸有限公司 (营业执照期限:2019-2049年. 纳税人识别号:91350900MA32WE2Q2X)
对公账号开户银行:中国建设银行 | 账户名称:宁德梧三商贸有限公司 | 账户号码:35050168730700000955
本公司专职于中国国家标准行业标准英文版