GB/T 20274.2-2008 信息安全技术 信息系统安全保障评估框架 第2部分：技术保障

ICS35.040

L80

中华人民共和国国家标准

GB/T20274.2—2008

信息安全技术

信息系统安全保障评估框架

第2部分：技术保障

Informationsecuritytechnology—

Evaluationframeworkforinformationsystemssecurityassurance—

Part2:Technicalassurance

2008-07-18发布2008-12-01实施

发布

GB/T20274.2—2008

目次

前言V

1范围1

2规范性引用文件1

3术语和定义1

4本部分的结构1

5信息安全技术保障2

5.1安全技术保障概述2

5.2安全技术体系架构能力级2

5.3安全技术保障控制要求范例2

6信息安全技术保障控制结构5

6.1综述5

6.2组件分类9

7FAU类：安全审计10

7.1安全审计自动响应(FAU.ARP)11

7.2安全审计数据产生(FAU_GEN)11

7.3安全审计分析(FAU.SAA)12

7.4安全审计查阅(FAU_SAR)14

7.5安全审计事件选择(FAU.SEL)15

7.6安全审计事件存储(FAU.STG)15

8FCO类:通信17

&1原发抗抵赖(FC()_NRO)17

&2接收抗抵赖(FC()_NRR)18

9FCS类：密码支持19

9.1密钥管理(FCS_CKM)20

9.2密码运算(FCS_C()P)21

10FDP类：用户数据保护22

10.1访问控制策略(FDP_ACC)24

10.2访问控制功能(FDP.ACF)24

10.3数据鉴别(FDP.DAU)25

10.4输出到TSF控制之外(FDP_ETC)26

10.5信息流控制策略(FDP_IFC)27

10.6信息流控制功能(FDP_IFF)28

10.7从TSF控制之外输入(FDP_ITC)30

10.8TOE内部传输(FDP_ITT)32

10.9残余信息保护(FDP_RIP)33

10.10反转(FDP_R()L)34

10.11存储数据的完整性(FDP_SDI)35

10.12TSF间用户数据传输的保密性保护(FDP.UCT)35

T

GB/T20274.2—2008

10.13TSF间用户数据传输的完整性保护(FDP.UIT)36

11FIA类：标识和鉴别38

11.1鉴别失败(FIA_AFL)39

11.2用户属性定义(FIA.ATD)39

11.3秘密的规范(FIA_S()S)40

11.4用户鉴别(FIA_UAU)40

11.5用户标识(FIA_UID)43

11.6用户—主体绑定(FIA_USB)44

12FMT类：安全管理44

12.1TSF中功能的管理(FMT_M()F)45

12.2安全属性的管理(FMT.MSA)46

12.3TSF数据的管理(FMT.MTD)47

12.4撤消(FMT_REV)48

12.5安全属性到期(FMT.SAE)49

12.6安全管理角色(FMT.SMR)50

13FPR类：隐秘51

13.1匿名(FPR_ANO)51

13.2假名(FPR_PSE)52

13.3不可关联性(FPR.UNL)53

13.4不可观察性(FPR_UNO)54

14FPT类：TSF保护55

14.1根本抽象机测试(FPT.AMT)57

14.2失败保护(FPTFLS)57

14.3输出TSF数据的可用性(FPT.ITA)57

14.4输出TSF数据的保密性(FPT-ITC)58

14.5输出TSF数据的完整性(FPT_ITI)58

14.6TOE内TSF数据的传输(FPT_ITT)59

14.7TSF物理保护(FPT_PHP)61

14.8可信恢复(FPT_RCV)62

14.9重放检测(FPT.RPL)64

14.10参照仲裁(FPT.RVM)64

14.11域分离(FPT_SEP)65

14.12状态同步协议(FPT.SSP)66

14.13吋间戳(FPT_STM)67

14.14TSF间TSF数据的一致性(FPT.TDC)67

14.15TOE内TSF数据复制的一致性(FPT.TRC)68

14.15TSF自检(FPT.TST)68

15FRU类：资源利用69

15.1容错(FRU_FLT)70

15.2服务优先级(FRU.PRS)70

15.3资源分配(FRU.RSA)71

16FTA类：TOE访问72

16.1可选属性范围限定(FTA.LSA)72

n

GB/T20274.2—2008

16.2多重并发会话限定(FTA.MCS)73

16.3会话锁定(FTA.SSL)74

16.4TOE访问旗标75

16.5TOE访问历史(FTA.TAH)76

16.6TOE会话建立(FTA_TSE)76

17TP类：可信路径/信道77

17.1TSF间可信信道(FTP_ITC)77

17.2可信路径(FTP.TRP)78

18安全技术架构能力成熟度级78

18.1概述78

18.2安全技术架构能力成熟度级说明79

附录A(资料性附录)安全技术要求应用注释81

A.1注释的结构81

A.1.1类结构81

A.1.2子类结构81

A.1.3组件结构82

A.2依赖关系表82

附录B(资料性附录)分层多点信息系统安全体系结构89

B.1概述89

B.2信息技术系统TOE的分析模型89

B.3分层多点安全技术体系架构介绍90

参考文献92

图1安全技术保障控制要求范例(单个TOE)2

图2分布式TOE内的安全功能图3

图3用户数据和TSF数据的关系5

图4"鉴别数据”和“秘密”的关系5

图5安全技术保障控制类结构6

图6安全技术保障控制子类结构6

图7安全技术保障控制组件结构7

图8示范类分解图9

图9安全审计类分解10

图10通信类分解17

图11密码支持类分解19

图12用户数据保护类分解23

图13标识和鉴别类分解38

图14安全管理类分解45

图15隐秘类分解51

图16TSF保护类分解56

图17资源利用类分解69

图18TOE访问类分解72

图19可信路径/信道类分解图77

ni

GB/T20274.2—2008

图A.1安全技术保障控制类结构81

图A.2安全技术保障控制子类结构81

图A.3安全技术保障控制组件结构82

图B.1信息技术系统分析模型90

图B.2分层多点安全技术体系结构91

表A.1安全技术保障控制组件依赖关系表83

GB/T20274.2—2008

-1.Z-—1—

刖弓

GB/T20274《信息安全技术信息系统安全保障评估框架》分为以下四个部分：

——第1部分:简介和一般模型

——第2部分:技术保障

——第3部分:管理保障

——第4部分:工程保障

本部分是GB/T20274的第2部分。

本部分的附录A和附录B为资料性附录.

本部分由全国信息安全标准化技术委员会提出并归口。

本部分起草单位：中国信息安全产品测评认证中心。

本部分主要起草人:吴世忠、王海生、陈晓桦、王贵驷、李守鹏、江常青、彭勇、张利、姚轶崭、邹琪、

钱伟明、陆丽、班晓芳、李静、王庆、江典盛、孙成昊、门雪松、杜宇鸽、杨再山。

GB/T20274.2—2008

信息安全技术

信息系统安全保障评估框架

第2部分：技术保障

1范围

GB/T20274的本部分建立了信息系统安全技术保障的框架，确立了组织机构内启动、实施、维护、

评估和改进信息安全技术体系的指南和通用原则。GB/T20274的本部分定义和说明了信息系统安全

技术体系建设和评估中反映组织机构信息安全的技术体系架构能力级，以及组织机构信息系统安全的

技术要求。

GB/T20274的本部分适用于启动、实施、维护、评估和改进信息安全技术体系的组织机构和涉及

信息系统安全技术工作的所有用户、开发人员和评估人员。

2规范性引用文件

下列文件中的条款通过GB/T20274的本部分的引用而成为本部分的条款。凡是注日期的引用文

件,其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成

协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本

部分。

GB/T20274.1信息安全技术信息系统安全保障评估框架第1部分：简介和一般模型

3术语和定义

GB/T20274.1确定的术语和定义适用于GB/T20274的本部分。

4本部分的结构

GB/T20274的本部分的组织结构如下：

a）第1章介绍了GB/T20274的本部分的范围；

b）第2章介绍了GB/T20274的本部分所规范引用的标准；

O第3章描述了适用于GB/T20274的本部分的术语和定义；

d）第4章描述了GB/T20274的本部分的组织结构；

e）第5章描述了信息系统安全技术保障框架，并进一步概述了信息系统安全技术保障控制类域

和安全技术体系架构能力级；

f）第6章描述了信息安全技术保障控制类的规范描述结构和要求；

g）第7章到第17章详述了提供信息安全技术保障控制类的11个信息安全技术保障控制类的详

细要求；

h）第18章描述了安全技术体系架构能力成熟度模型；

i）附录A是资料性附录，进一步解释了安全技术要求；

J）附录E是资料性附录，描述了分层多点的信息系统安全技术体系架构；

k）参考文献给出了GB/T20274的本部分的参考文献。

1

GB/T20274.2—2008

5信息安全技术保障

5.1安全技术保障概述

信息系统安全保障评估框架-安全技术保障主要用于评估信息系统中系统级的安全技术体系框架

和安全技术解决方案，即对信息技术系统（信息技术系统：作为信息系统一部分的执行组织机构信息功

能的用于采集、创建、通信、计算、分发、处理、存储和/或控制数据或信息的计算机硬件、软件和/或固件

的任何组合）进行安全评估。在信息系统安全保障评估框架的技术、管理和工程保障中，安全技术保障

同GB/T18336《信息技术安全性评估准则》间有着最直接和紧密的关系；信息系统安全保障评估准的

安全技术体系框架和安全技术解决方案直接建立在经过GB/T18336准则评估认可的产品和产品系统

之上。

在信息系统安全保障评估框架安全技术保障中，它的评估对象（TOE）是构成信息系统的所有计算

机硬件、软件和/或固件的任何组合。信息系统安全保障评佔框架安全技术保障，首先要求信息系统的

用户为其评估对象（即信息技术系统）建立和完善其安全技术体系架构；在完成其信息技术系统安全技

术体系架构后，基于此安全技术体系架构，对信息技术系统进行高层分析、确定相关安全目的；最后用规

范化的安全技术保障控制组件类进行描述。

5.2安全技术体系架构能力级

安全技术体系架构构建过程，是组织机构根据其系统安全风险评估的结果和系统安全策略的要求，

并参考相关安全技术体系架构的标准和最佳实践，结合组织机构信息技术系统的具体现状和需求，建立

的符合组织机构信息技术系统安全战略发展规划的整体安全技术体系框架；它是组织机构信息技术系

统安全战略管理的具体体现。安全技术体系架构能力是组织机构执行系统安全技术能力的整体反映，

是组织机构在进行信息安全技术体系框架管理并达到预定成本、功能和质量目标的度量的体现。

5.3安全技术保障控制要求范例

本条描述木部分中安全技术保障控制要求所使用的范例。图1和图2描述了范例的一些关键概

念。本条为这些图和图中没有的其他关键概念提供文字描述。所讨论的关键概念以粗斜体突出表示。

叶対*CTOE）lOKtc全功l&ftM)<IMI)

r—

安全功龍

远尿11产肚（T5F）

主体执行TOE安令徳略

（TSP）

卜休

卜休I

[||L豆JI

主侔

TSF押制纸IB(TSC)

图1安全技术保障控制要求范例（单个TOE）

本部分是一个可为评估对象（"疋）规定安全功能要求的目录。T（）E是包含电子存储媒体（如磁

盘）、外设（如打印机）和计算能力（如CPU时间）等资源的IT产品或系统（同吋带有用户和管理员指南

文档），可用于处理和存储信息，是被评估的对象。

TOE评估主要关系到：确保对TOE资源执行了规定的TOE安全策略（TSP）。TSP定义了一些规

2

GB/T20274.2—2008

则，通过这些规则T()E支配对其资源的访问，这样TOE就控制了其所有信息和服务。

而TSP又由多个安全功能策略(SFP)所构成。每一SFP有其控制范围，定义了该SFP控制下的

为正确执行TSP而必须依赖的TOE中的那些部分，统称为TOE安全功能(TSF)。TSF包括实施

安全所直接或间接依赖的TOE中的所有软件、硬件和固件。

参照腔视器是实施TOE的访问控制策略的抽象机。参照确认机制是参照监视器概念的实现，它

具有以下特性：防篡改、一直运行、简单到能对其进行彻底的分析和测试。TSF可能包括一个参照确认

机制或TOE运行所需要的其他安全功能。

TOE可能是一个包含硬件、固件和软件的单个产品，也可能是一个分布式产品，内部包括多个单独

的部分，每一部分都为T()E提供一个特别的服务，并且通过一个内部通侍涪道与TOE其他部分相连

接。该信道可以与处理器总线一样小，也可能是包含在T()E中的一个内部网络。

当TOE由多个部分组成时，TOE的每一部分可拥有自己的TSF部分，此部分通过内部通信信道

与TSF的其他部分交换用户数据和TSF数据。这种交互称为TOE内部传输。在这种情况下，这些

TSF的分离部分抽象地形成一个复合的TSF来实施TSPO

TOE接口可能限于特定的TOE使用，也可能允许通过外部通信信道与其他IT产品交互。这些与

其他IT产品的外部交互可以采取两种形式：

a)“远程可信IT产品”的安全策略和本地T()E的TSP已在管理上进行了协调和评估。这种情

况下的信息交换称为TSF间传输，如同它们是在不同可信产品的TSF之间。

b)远程IT产品可能没有被评估，因此它的安全策略是未知的，如图1.2中所示的“不可信IT产

品”。这种情况下的信息交换称为TSF控制外传输，如同在远程IT产品中没有TSF(或它的

策略特性未知)。

可与TOE或在TOE中发生的、并服从TSP规则的交互集合称为TSF控制范围(TSC)。TSC包

括一组根据主体、客体和TOE内的操作定义的交互集，但不必包括TOE的所有资源。

一组交互式(人机接口)或编程(应用编程接口)接口，通过它，TSF访问、调配TOE资源，或者从

3

GB/T20274.2—2008

TSF中获取信息，称为TSF接口（TSFI）oTSFI定义了为执行TSP而提供的TOE功能的边界。

用户在TOE的外部，因此也在TSC的外部。但为请求TOE执行服务，用户要通过TSFI和TOE

交互。本标准安全功能要求关心两种用户:人类用户和外部/T实体。人类用户进一步分为本地人类

用户，他们通过TOE设备（如工作站）直接与TOE交互，或远程人类用户，他们通过其他IT产品间接

与TOE交互。

用户和TSF间的一段交互期称为用户会话。可以根据各种考虑来控制用户会话的建立，如：用户

鉴别、时段、访问TOE的方法和每个用户允许的并发会话数。

本标准使用术语“已授权”来表示用户具有执行某种操作所必需的权力或特权。因此术语“授权用

户”表示允许用户执行TSP定义的操作。

为表达需要管理员责任分离的要求，本标准相关的安全功能组件（来自子类FMT.SMR）明确说明

要求管理性角色。角色是预先定义的一组规则，这些规则建立起用户和T（）E间所允许的交互。TOE

可以支持定义任意数日的角色。例如，与T（）E安全运行相关的角色可能包括“审计管理员”和“用户账

号管理员”。

T（）E包括可用于处理和存储信息的资源。TSF的主要目标是完全并正确地对TOE所控制的资

源和信息执行TSP。

T（）E资源能以多种方式结构化和利用。但是，本标准作出了特殊区分，以允许规定所期望的安全

特性。所有由资源产生的实体能以两种方式中的一种来表征：实体可能是主动的，意指他们是TOE内

部行为发生的原因，并导致对信息执行操作；实体也可能是被动的，意指它们是发出信息或存入信息的

容器。

主动的实体称为主体。TOE内可能存在以下几种类型的主体：

a）代表授权用户，遵从TSP所有规则的那些实体（例如：UNIX进程）；

b）作为特定功能进程，可以轮流代表多个用户的那些实体（例如：在客户/服务器结构中可能找

到的功能）；

O作为TOE自身一部分的那些实体（例如：可信进程）。

本部分所述的安全功能针对上述列出的各种主体执行TSP。

被动实体（即信息存储器）在本部分中被称作“客体”。客体是可以由主体执行操作的对象。在一个

主体（主动实体）是某个操作的对象（例如进程间通信）的情况下，该主体也可以作为客体。

客体可以包含侍息。在FDP类中说明信息流控制策略时，需要这个概念。

用户、主体、信息和客体具有确定的属性，这些属性包括使T（）E正确运转的信息。有些属性，可能

只是提示性信息（即，增加T（）E的用户友好性），如文件名，而另一些属性，可能专为执行TSP而存在，

如访问控制信息，后面这些属性通常称为“安全属性”。在本部分中，属性一词将用作“安全属性”的简

称，除非另有说明。但正如TSP规定的那样，无论属性信息的预期目的如何，对属性加以控制还是必

要的。

TOE中的数据分为用户数据和TSF数据，图3表明了这种关系。用户数据是存储在TOE资源中

的信息，用户可以根据TSP对其进行操作，而TSF对它们并不附加任何特殊的意义。例如，电子邮件

消息的内容是用户数据。TSF数据是在进行TSP决策时TSF使用的信息。如果TSP允许的话，TSF

数据可以受用户的影响。安全属性、鉴别数据以及访问控制表都是TSF数据的例子。

有几个用于数据保护的SFP,诸如访问控制SFP和信息流控制SFP。实现访问控制SFP的机制，

是基于控制范围内的主体属性、客体属性和操作来决定建立它们的策略，这些属性用于控制主体可以对

客体执行的操作的规则集中。

实现信息流控制SFP的机制，是基于控制范围内的主体和信息的属性以及制约主体对信息操作的

一组规则来决定它们的策略。信息的属性，可能与容器属性相关联（也可能没有关联，如多级数据库），

在信息移动吋与其相随。

4

GB/T20274.2—2008

roi敏锹

用户散瓠

图3用户数据和TSF数据的关系

本部分涉及的两种特殊TSF数据，鉴别数据和秘密，可以是但不必一定是相同的。

鉴别数据用于验证向TOE请求服务的用户声明的身份。最通用的鉴别数据形式是口令。口令要

成为有效的安全机制，依赖于对其进行保密。但是，不是所有形式的鉴别数据都需要保密，生物测定学

鉴别设备（例如，指纹阅读器、视网膜扫描仪）就不依赖于数据保密，因为这些数据只有一个用户拥有，其

他人不能伪造。

本部分功能要求中用到的术语“秘密”，对鉴别数据适用，对其他为执行一特定SFP而必须保密的

数据也同样适用。例如，依靠密码功能保护在信道中传输信息的保密性的可信信道机制，其强度应与用

来保持密钥的秘密以防止未授权泄露的方法的强度相当。

因此，不是所有的鉴别数据都需要保密；也不是所有的秘密都被用作鉴别数据。图4说明了秘密和

鉴别数据间的关系，指出了常见的鉴别数据和秘密的数据类型。

鉴别数据

祚症kI

'僅円变ht

图4“鉴别数据”和“秘密”的关系

6信息安全技术保障控制结构

6.1综述

本章定义了本部分的技术要求的内容和形式，并为需要向ISST中添加新组件的组织提供指南。

技术要求以类、子类和组件来表达。

6.1.1信息安全技术保障控制类结构

图5以图表的形式阐明了安全技术保障控制类的结构。每个安全技术保障控制类包括一个类名、

类介绍及一个或多个安全技术保障控制子类。

5

GB/T20274.2—2008

FLjEJ

八包括I）和咅十个《•丿

图5安全技术保障控制类结构

6.1.1.1类名

类名提供标识和划分安全技术保障控制类所必需的信息。每个安全技术保障控制类都有一个唯一

的名称，类的分类信息由三个字符的简名组成。类的简名用于该类中的子类的简名规范中。

6.1.1.2类介绍

类介绍描述这些子类满足安全目标的通用意图或方法。安全技术保障控制类的定义不反映要求规

范中的任何正式分类法。

类介绍用图来描述类中的子类和每个子类中组件的层次结构，见6.1.1的解释。

6.1.2信息安全技术保障控制子类结构

图6以框图形式说明安全技术保障控制子类的结构。

图6安全技术保障控制子类结构

6.1.2.1子类名

子类名部分提供标识和划分安全技术保障控制子类所必需的分类和描述信息。每个安全技术保障

控制子类有一个唯一的名称。子类的分类信息由七个字符的简名组成，开头三个字符与类名相同，后跟

一个下划线和子类名，例如XXX-YYY。唯一的简短子类名为组件提供主要的引用名。

6.1.2.2子类行为

子类行为是对安全技术保障控制子类的行为的叙述性描述，陈述其安全目的，以及对技术要求的一

6

GB/T20274.2—2008

般描述。以下是更详细的描述：

a）子类的安全目的阐述在包含该子类的一个组件的T（）E的帮助下，可以解决的安全问题；

b）技术要求的描述总结组件中包含的所有安全要求。该描述针对PP、ST和技术包的作者，他们

希望评价该子类是否与他们的特定需求相关。

6.1.2.3组件层次

安全技术保障控制子类包含一个或多个组件，任何一个组件都可被选择包含在PP、ST和技术包

中。本条的目的是，一旦子类被认为是用户安全要求的一个必要或有用的部分时，就应向用户提供选择

恰当的安全技术保障控制组件的信息。

安全技术保障控制子类描述部分描述所用组件和它们的基本原理。组件的更多细节包含在每个组

件中。

安全技术保障控制子类内组件间的关系可能是也可能不是层次化的。如果一个组件相对另一个组

件提供更多的安全，那么该组件对另一个组件来说是有层次的。

如6.1.2条所述，子类的描述中提供了关于子类内组件层次结构的图示。

6.1.2.4管理

管理要求包含PP/ST作者应考虑的作为给定组件的管理活动的信息。管理要求在管理类（FMT）

的组件里详述。

PP/ST作者可以选择已指出的管理要求或者可以包括其他没有列出的管理要求，因而这些信息应

认为是提示性的。

6.1.2.5审计

如果PP/ST中包含来自类FAU（安全审计）中的要求，则甫廿要求包含供PP/ST作者选择的可审

计的事件。这些要求包括按FAU_GEN（安全审计数据产生）子类的组件所支持的以各种不同详细级

别表示的安全相关事件。例如，一个审计记录可能包括下述行动：最小级——安全机制的成功使用；基

本级一一安仝机制的成功使用以及所涉及到的安仝属性的相关信息；详细级一一所有对机制配置的改

变，包括改变前后的实际配置值。

显然可审计事件的分类是层次化的。例如，当期望“基本级审计产生”时，所有标识为最小级和基本

级的可审计事件都应通过适当的赋值操作包括在PP/ST内，只是高级事件仅仅比低级事件提供更多的

细节。当期望“详细级审计产生”吋，所有标识为最小级、基本级和详细级的可审计事件都应包括在PP/

ST内。

FAU类更详尽地解释了管理审计的规则。

6.1.3信息安全技术保障控制组件结构

图7描绘安全技术保障控制组件的结构。

图7安全技术保障控制组件结构

7

GB/T20274.2—2008

6.1.3.1组件标识

组件标识提供标识、分类、注册和交叉引用组件时所必需的描述性信息。下列各项作为每个安全技

术保障控制组件的部分：

a）一个唯一的名？，该名字反映了组件的目的。

b）一个简名，即安全技术保障控制组件名的唯一简写形式。简名作为分类、注册和交叉引用组

件的主要引用名。简名反映出组件所属的类和子类以及在子类中组件的编号。

c）一个从属于表。这个组件所从属于的其他组件列表，以及该组件可用来满足与所列组件间的

依赖关系。

6.1.3.2技术元素

为每一组件提供了一组元素。每个元素都分别定义并且是相互独立的。

技术元素是一个安全技术要求，如果进一步划分将不会产生有意义的评估结果。它是GB20274.2

中标识和认同的最小安全技术要求。

当建立包、PP或ST时，不允许从一个组件中只选择一个或几个元素，必须选择组件的全部元素。

每个技术元素名都有一个唯一的简化形式。例如，元素名FDP_IFF.4.2意义如下：F——技术要

求，DP——“用户数据保护”类,_IFF——“信息流控制技术”子类，.4——第四个组件，名为“部分消除非

法信息流”,.2-该组件的第2个元素。

6.1.3.3依赖关系

当一个组件本身不充分而要依赖于其他组件的技术，或依赖于与其他组件的交互才能正确发挥其

技术时，就产生了安全技术保障控制组件间的依赖关系。

每个安全技术保障控制组件都提供一个对其他技术和保证组件的完整的依赖关系表。有些组件可

能列出“无依赖关系”。所依赖的组件又可能依赖其他组件，组件中提供的列表是直接的依赖关系。这

只是为该技术要求能正确完成其技术提供参考。间接依赖关系，也就是由所依赖组件产生的依赖关系，

见本标准附录A.值得注意的是，在某些情况下依赖关系可在提供的多个技术要求中选择，这些技术要

求中的每一个都足以满足依赖关系（例如FDP_UIT.1）0

依赖关系列表标识出，为满足与已标识组件相关的安全要求所必需的最少技术或保证组件。从属

于已标识组件的那些组件也可用来满足依赖关系。

本部分指明的依赖关系是规范的，在PP/ST中它们必须得到满足。在特定的情况下这种依赖关系

可能不适用，只要PP/ST作者在基本原理中说清不适用的理由，就可以在包、PP和ST中不考虑依赖

的组件。

6.1.4允许的安全技术保障控制组件操作

用于在PP、ST或技术包内定义要求的安全技术保障控制组件可以与本部分第5章〜第17章中说

明的完全一样，也可以经裁剪以满足特定的安全目的。但是，选择和裁剪这些安全技术保障控制组件是

复杂的，因为必须考虑所标识组件依赖关系。因此这种裁剪只限于一组允许的操作。

每个安全技术保障控制组件都包括一个允许的操作列表。对所有安全技术保障控制组件，并非一

切操作都是允许的。

允许的操作选自：

a）反复：采用不同的操作多次使用同一组件；

b）赋值:对指定参数的说明；

c）选择:对列表中的一个或多个元素的说明；

d）细化:增加细节。

6.1.4.1反复

当需要覆盖同一要求的不同方面时（如，标识一个以上类型的用户），允许重复使用本标准的同一组

件来覆盖每个方面。

8

GB/T20274.2—2008

6.1.4.2赋值

某些安全技术保障控制元素包含一些参数和变量，这些参数和变量使PP/ST作者可以指定PP或

ST中包含的一个策略或一组值，以满足特定的安全目的。这些元素清楚地标识出每个参数及其可以

分配给该参数的值。

元素任一方面的可接受值如能无歧义地描述和列举，就可用一个参数来表述。该参数可能是一个

属性或规则，它把要求限定为一个确定的值或值的范围。例如，根据指定的安全目的，安全技术保障控

制元素可以规定一给定的操作应执行数次。在这种情况下，赋值应提供用于该参数的次数或次数范围。

6.1.4.3选择

这是为缩小一个组件元素的范围，从列表中选取一个或多个项目的操作。

6.1.4.4细化

对所有安全技术保障控制元素来说，为满足安全目的，允许PP/ST作者通过增加细节来限定可接

受的实现集。元素的细化由这些增加的技术细节来组成。

在ST中，可能需要就T()E对术语“主体”和“客体”的含义作出有意义的解释，因此需要细化。

像其他操作一样，细化不增加任何完全新的要求。根据安全目的，它对要求、规则、常量和条件施以

详细阐述、解释或特别的含义。细化应只是进一步限定实现要求所可能接受的技术或机制集，而不是增

加要求。细化不允许建立新要求，因此不会增加与组件相关的依赖关系列表。PP/ST作者必须注意，

其他要求对该要求的依赖关系仍应得到满足。

6.2组件分类

本部分中组件的分类不代表任何正式的分类法。

本部分包括子类和组件的分类，它们是基于相关的技术和目的的粗略分类，按字母顺序给出。每个

类的开头是一个提示性框图，指出该类的分类法、类中的子类和子类中的组件。这个图对指示可能存在

于组件间的层次关系是有用的。

在安全技术保障控制组件的描述中，有一段指出该组件和任何其他组件之间的依赖关系。

在每个类中，都有一个与图6类似的描述子类层次关系的图。在图8中，第1个子类(子类1)包括

了三个有从属关系的组件，其中组件2和组件3都可以用来满足对组件1的依赖关系。组件3从属于

组件2,并且可以用来满足对组件2的依赖关系。

1mill|—|姐件2|—Sift3

仙11

了恐

血件2［纽件3

y绘件2、

子灵2—组件1〈〉纽件，

爼件3

图8示范类分解图

在子类2中有三个组件，这三个组件不全都有从属关系。组件1和组件2不从属于其他组件。组

件3从属于组件2,可以用来满足对组件2的依赖关系，但不能满足对组件1的依赖关系。

在子类3中，组件2、3、4从属于组件1。组件2和3也都从属于组件1,但无可比性。组件4从属

于组件2和3O

9

GB/T20274.2—2008

这些图的目的是补充子类中的文字说明，使关系的识别更容易。它们并不取代每个组件中的“从属

于：”注释，这些注释是对每个组件从属关系的强制声明。

6.2.1突出组件变化

子类中组件的关系约定以粗体字突出表示。粗体字约定所有新的要求用粗体表示。对于有从属关

系的组件，当要求或依赖关系被增强或修改而超出前一组件的要求吋，要用粗体字表示。另外，超出前

一组件的任何新的或增强的允许操作，也使用粗体字突出表示。

7FAU类：安全审计

安全审计包括识别、记录、存储和分析那些与安全相关活动（即由TSP控制的活动）有关的信息。

检查审计记录结果可用来判断发生了哪些安全相关活动以及哪个用户要对这些活动负责。

安全审计类分解见图9。

安全W计

1

FADSAR左金1"计件阀2

d

审计W件选择

立令审审件存镐

图9安全审计类分解

10

GB/T20274.2—2008

7.1安全审计自动响应（FAU.ARP）

子类行为

本子类定义在检测到的事件表明可能有安全侵害发生时作出的应答。

组件层次

对于FAU_ARP.1安全警告，当检测到可能的安全侵害时TSF应采取行动。

管理:FAU.ARP.1

在管理功能FMT中考虑以下行动：

a）对行动的管理（添加、移去、修改）。

审计:FAU.ARP.1

如果在PP/ST中包括FAU.GEN安全审计数据产生，那么以下行动应可审计：

a）最小级：当即将发生安全侵害吋采取的行动。

FAU.ARP.1安全警告

从属于：无其他组件。

依赖关系:FAU_SAA.1潜在侵害分析

FAU_ARP.1.1当检测到潜在的安全侵害时，TSF应进行［赋值:最小扰乱行动表］。

7.2安全审计数据产生（FAU_GEN）

子类行为

对于在TSF控制下发生的安全相关事件，本子类定义了记录其出现的要求。本子类确定审计的级

别，列举TSF可审计的事件类型，以及应在各审计记录内提供的审计相关信息的最小集合。

组件层次

FAU_GEN.1审计数据产生定义可审计事件的级别，并规定在每个记录中应记录的数据列表。

FAU_GEN.2用户身份关联,TSF应把可审计事件与单个用户身份相关联。

管理:FAU_GEN.1,FAU_GEN.2

尚无预见的管理活动。

审计:FAU_GEN.1,FAU_GEN.2

如果在PP/ST中包含FAU.GEN安全审计数据产生，此处不存在任何明确的可审计行动。

FAU_GEN.1审计数据产生

从属于：无其他组件。

依赖关系:FPT_STM.1可信时间戳

FAU_GEN.1.1TSF应能为下述可审计事件产生审计记录：

a）审计功能的启动和关闭；

b）在［选择:最小级.基本级.洋细级.荣规定］审计级别以内的所有可审计事件；

c）［赋值:其他专门定义的可审计事件］。

11

GB/T20274.2—2008

FAU-GEN.1.2TSF应在每个审计记录中至少记录如下信息：

a）事件的日期和时间，事件类型，主体身份，事件的结果（成功或失败）；

b）对每种审计事件类型，基于PP/ST中功能组件的可审计事件定义的［赋值:其他审计相关

信息］。

FAU_GEN.2用户身份关联

从属于:无其他组件。

依赖关系:FAU_GEN.1审计数据产生；

FIA_UID.1标识定时。

FAU_GEN.2.1TSF应能将每个可审计事件与引起该事件的用户身份相关联。

7.3安全审计分析（FAU.SAA）

了类行为

本子类定义，为寻找可能的或真正的安全侵害，用来分析系统活动和审计数据的自动化措施的要

求。这种分析可用入侵检测来支持,或对即将来临的安全侵害作岀自动应答。

基于检测结果，可采取FAU_ARP子类指定的行为。

组件层次

IAI7安个W计分桁

在FAU_SAA.1潜在侵害分析中，需要一个基于固定规则集的基本门限检测。

在FAU.SAA.2基于轮廓的异常检测中，TSF维护个人的系统使用轮廓，这里“轮廓”代表由轮廓

目标组成员完成的历史使用模式。轮廓目标组是指与TSF交互的一个或多个人（如单个用户、共享一

个身份或账号的用户、指定角色的用户、整个系统或网络节点的用户）。轮廓目标组的每个成员都被分

配给一个单独的置疑等级，表明成员当前的行动与轮廓中已建立的使用模式的一致程度如何。此分析

可在运行期间完成，或在信息采集后的批量分析阶段完成。

FAU.SAA.3简单攻击探测，TSF应能检测到那些表明对TSP实施将产生重大威胁的特征事件

的发生。对特征事件的搜索可以实时进行，也可以在信息采集后的批量分析阶段进行。

FAU.SAA.4复杂攻击探测，TSF应能描述并检测到多步骤入侵情景。TSF应能根据已知的事件

序列把系统事件（可能是由多个用户执行的）模拟成完整的入侵情景。TSF应能指出特征事件或事件

序列发生的吋间，指出对TSP的潜在侵害。

管理:FAU.SAA.1

在管理功能FMT中考虑以下行动：

a）通过（添加/修改/删除）规则集中的规则来维护规则。

管理:FAU.SAA.2

在管理功能FMT中考虑以下行动：

a）对轮廓目标组中的用户组进行维护（删除/修改/添加）。

管理:FAU.SAA.3

在管理功能FMT中考虑以下行动：

a）对系统事件的子集进行维护（删除/修改/添加）。

管理:FAU.SAA.