GB_T 18336.2-2015 信息技术 安全技术 信息技术安全评估准则 第2部分_安全功能组件.docx

《GB_T 18336.2-2015 信息技术 安全技术 信息技术安全评估准则 第2部分_安全功能组件.docx》由会员分享，可在线阅读，更多相关《GB_T 18336.2-2015 信息技术 安全技术 信息技术安全评估准则 第2部分_安全功能组件.docx（410页珍藏版）》请在三一办公上搜索。

1、ICS 35.040L 80中华人民共和家标准OBGB/T18336.22015/ISO/IEC15408-2:2008代替GB/T18336.22008信息技术安全技术信息技术安全评估准则第2部分：安全功能组件Informationtechnology-Securitytechniques一EvaluationcriteriaforITsecurityPart2:Securityfunctionalcomponents(ISO1EC15408-2:2008,IDT)2015-05-15发布2016-01-01实施中华人民共和国国家质量监督检验检疫总局发布中国国家标准化管理委员会目次前言V引言

2、V1范围12规范性引用文件13术语、定义和缩略语14概述14.1本部分的结构15功能要求范型26安全功能组件46. 1概述46.2组件分类87FAU类：安全审计87. 1安全审计自动响应（FAUARP）97. 2安全审计数据产生（FAUGEN）107. 3安全审计分析（FAUSAA）117. 4安全审计查阅（FAUSAR）137. 5安全审计事件选择（FAUSEL）147. 6安全审计事件存储（FAUSTG）158FCO类：通信178. 1原发抗抵赖（FCoNRO）179. 2接收抗抵赖（FCoNRR）189FCS类：密码支持2010. 1密钥管理（FCSCKM）2011. 2密码运算（FCS

3、COP）2210FDP类：用户数据保护2210. 1访问控制策略（FDPACO2510. 2访间控制功能（FDPACF）2610 .3数据鉴别（FDPDAU）2711 .4从TOE输出（FDPETC）2810. 5信息流控制策略（FDPIFC）2910. 6信息流控制功能（FDPIFF）3010. 7从TOE之外输入（FDPITO3310. 8TOE内部传送（FDPITT）3510. 9残余信息保护（FDPRlP）3710.10回退（FDPROL）3810. 11存储数据的完整性（FDPSDl）3910. 12TSF间用户数据机密性传送保护（FDPUCT）4012. 13TSF间用户数据完整性

4、传送保护（FDPUIT）41HFIA类：标识和鉴别4213. 1鉴别失败（FlAAFL）4311. 2用户属性定义（FIAATD）4412. 3秘密的规范（FIASOS）4413. 4用户鉴别（FlAUAU）4514. 5用户标识（FIAUID）4815. 6用户-主体绑定（FIAUSB）4912FMT类：安全管理5012. 1TSF中功能的管理（FMTMOF）5112. 2安全属性的管理（FMTMSA）5212 .3TSF数据的管理（FMTMTD）5413 .4撤消（FMTREV）5512. 5安全属性到期（FMTSAE）5612. 6管理功能规范（FMTSMF）5716. 7安全管理角色（

5、FMTSMR）5713FPR类：隐私5913. 1匿名（FPRANO）5913. 2假名（FPRPSE）6013. 3不可关联性（FPRUND6217. 4不可观察性（FPRUNO）6214FPT类：TSF保护6414. 1失效保护（FPTFLS）6614. 2输出TSF数据的可用性（FPTITA）6614. 3输出TSF数据的机密性（FPTITC）6714. 4输出TSF数据的完整性（FPTITI）6714. 5ToE内TSF数据的传送（FPTITT）6914. 6TSF物理保护（FPTPHP）7014. 7可信恢复（FPTRCV）7214. 8重放检测（FPTRPD7414. 9状态同步协

6、议（FPTSSP）7518. 10时间戳（FPTSTM）7619. 11TSF间TSF数据的一致性（FPTTDC）7620. 12外部实体测试（FPTTEE）7721. 13ToE内TSF数据复制的一致性（FPTTRO7822. 14TSF自检（FPTTST）7815FRU类：资源利用7915. 1容错（FRUFLT）8015. 2服务优先级（FRUPRS）8123. 3资源分配（FRURSA）8216FTA类：TOE访间8316. 1可选属性范围限定（FTALSA）8316. 2多重并发会话限定（FTAMCS）8416. 3会话锁定和终止（FTASSL）8524. 4TOE访问旗标（FTAT

7、AB）8725. 5TOE访问历史（FTATAH）8726. 6TOE会话建立（FTATSE）8817FTP类：可信路径/信道8817. 1TSF间可信信道（FTPITC）8917. 2可信路径（FTPTRP）90附录A（规范性附录）安全功能要求应用注释91附录B（规范性附录）功能类、族和组件99附录C（规范性附录）FAU类：安全审计100附录D（规范性附录）FCo类：通信Ill附录E（规范性附录）FCS类：密码支持115附录F（规范性附录）FDP类：用户数据保护119附录G（规范性附录）FIA类：标识和鉴别140附录H（规范性附录）FMT类：安全管理148附录1（规范性附录）FPR类：隐私1

8、56附录J（规范性附录）FPT类：TSF保护165附录K（规范性附录）FRU类：资源利用179附录L（规范性附录）FTA类：ToE访问183附录M（规范性附录）FTP类：可信路径/信道188GB/T18336信息技术安全技术信息技术安全评估准则分为以下三部分：第1部分：简介和i般模型；-第2部分：安全功能组件；一第3部分：安全保障组件。本部分是GB/T18336的第2部分。本部分按照GB/T1.12009给出的规则编写。本部分代替GB/T18336.22008信息技术安全技术信息技术安全评估准则第2部分：安全功能要求。本部分与GB/T18336.22008的主要差异如下：一将“保证(assur

9、ance)改为“保障”；将“10.4输出到TSF控制之外(FDP_ETC)”改为10.4从TOE输出(FDP_ETC)”;将“10.7从TSF控制之外输入(FDPITC)”改为10.7从ToE之外输入(FDP_ITC)”;删除了“14FPT类：TSF保护”中的14.1底层抽象机测试(FPT_AMT)、14.10引用仲裁(FPT_RVM)”、“14.11域分离(FPT_SEP)”；在“14FPT类：TSF保护”中增加了“14.12外部实体测试(FPLTEE)”；将“16.3会话锁定(FTA_SSL)改为16.3会话锁定和终止(FTA.SSL);将门限值”改为“临界值”；一将“介导”改为“促成”O

10、本部分使用翻译法等同采用国际标准ISO/IEC15408-2:2008信息技术安全技术信息技术安全评估准则第2部分：安全功能组件。与本部分中规范性引用的国际文件有一致性对应关系的我国文件如下：-GB/T18336.1信息技术安全技术信息技术安全评估准则第1部分：简介和一般模型(GB/T18336.12015,ISO/IEC15408-1:2009,IDT)本部分做了下列编辑性修改:第4.1条标准原文有编辑性错误，现已更正为对于有关结构、规则和指南，编写PP或ST的人员应参见ISO/IEC15408T第3章和相关附录”。本部分由全国信息安全标准化技术委员会(SAC/TC260)提出和归口。本部分

11、起草单位：中国信息安全测评中心、信息产业信息安全测评中心、公安部第三研究所、吉林信息安全测评中心。本部分主要起草人：张种斌、郭颖、石婉松、毕海英、张宝峰、高金萍、王峰、杨永生、李国俊、董晶晶、谢蒂、王鸿娴、张冶、顾健、邱梓华、宋好好、陈妍、杨元原、李凤娟、庞博、张骁、刘昱函、王书毅、周博扬、唐喜庆、蒋显岚、张双双。本部分所代替标准的历次版本发布情况为：GB/T18336.22001;GB/T18336.22008o本部分定义的安全功能组件为在保护轮廓（PP）或安全目标（ST）中表述的安全功能要求提供了基础。这些要求描述了评估对象（TOE）所期望的安全行为，并旨在满足在PP或ST中所提出的安全目

12、的。这些要求描述那些用户能直接通过IT交互（即输入、输出）或TT激励响应过程探测到的安全特性。安全功能组件表达了安全要求，这些要求试图对抗针对假定的TOE运行环境中的威胁，并/或涵盖了所有已标识的组织安全策略和假设。本部分的目标读者主要包括安全的IT产品的消费者、开发者、评估者。ISO/IEC15408-1第5章提供了关于IS0/IEC15408的目标读者和目标读者群体如何使用IS0/IEC15408的附加信息。这些群体可以按如下方式使用本部分：a）消费者，为满足PP或ST中提出的安全目的，通过选取本部分的组件来表述功能要求。ISO/IEC15408-1提供了更多关于安全目的和安全要求之间的关

13、系的详细信息：b）开发者，在构造TOE时响应实际的或预测的消费者安全要求，可以在本部分中找到一一种标准的方法去理解这些要求。也可以以本部分的内容为基础，进一步定义TOE的安全功能和机制来满足那些要求；c）评估者，使用本部分所定义的功能要求检验在PP或ST中表述的TOE功能要求是否满足IT安全目的，以及所有的依赖关系是否都已解释清楚并得到满足。评估者也宜使用本部分去帮助确定指定的TOE是否满足规定的要求。信息技术安全技术信息技术安全评估准则第2部分：安全功能组件1范围为了安全评估的意图，GB/T18336的本部分定义了安全功能组件所需要的结构和内容。本部分包含个安全组件的分类目录，将满足许多IT

14、产品的通用安全功能要求。2规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修订版）适用于本文件。IS0/IEC15408-1信息技术安全技术信息技术安全评估准则第1部分：简介和一般模型(Informationtechnology-Securitytechniques-EvaluationcriteriaforITsecurity-Part1introductionandgeneralmodel)ISO/IEC15408-1中给出的术语、定义、符号和缩略语适用于本文件。TS0/TEC15408和本

15、部分在此描述的相关安全功能要求，并不意味着是对所有IT安全问题的最终回答。相反，本标准提供一组广为认同的安全功能要求，以用于制造反映市场需求的可信产品。这些安全功能要求的给出，体现了当前对产品的要求规范和评估的技术发展水平。本部分并不计划包括所有可能的安全功能要求，而是尽量包含那些在本部分发布时作者已知的并认为是有价值的那些要求。由于消费者的认知和需求可能会发生变化，因此本部分中的功能要求需要维护。可预见的是，某些PP/ST作者可能还有一些安全要求未包含在本部分提出的功能要求组件中。此时，PP/ST的作者可考虑使用ISO/IEC15408之外的功能要求（称之为可扩展性），有关内容参见ISO/I

16、EC15408T的附录A和附录Bo4.1本部分的结构第5章是本部分安全功能要求使用的范型。第6章介绍本部分功能组件的分类，第7章第17章描述这些功能类。附录A为功能组件的潜在用户提供了解释性信息，其中包括功能组件间依赖关系的一个完整的交叉引用表。附录B附录M提供了功能类的解释性信息。在如何运用相关操作和选择恰当的审计或文档信息时，这些材料必须被看作是规范性说明。使用助动词“应”表示该说明是首要推荐的，但是其他的只是可选的。这里只给出了不同的选项，具体的选择留给了PP/ST作者。对于有关结构、规则和指南，编写PP或ST的人员应参见IS0/IEC15408T第3章和相关附录：a) IS0/IEC1

17、5408-1第3章定义了ISO/IECI5408中使用的术语。b) IS0IEC15408T附录A定义了ST的结构。c) IS0/IEC15408-1附录B定义了PP的结构。5功能要求范型本章描述了本部分安全功能要求中所使用的范型。讨论中所涉及的关键概念均以粗体/斜体突出表示。本章并不打算替换或取代TS0IEC15408T第3章中所给出的任何术语。本部分是一个有关安全功能组件的目录，可用于规约一一个评估对象(ToE)的安全功能要求。TOE可以是软件、固件和/或硬件的集合，并可能配有用户和管理员的指导性文档。TOE可包含用于处理和存储信息的资源，诸如电子存储媒介(如主存、磁盘空间)、外设(如打印

18、机)以及计算能力(如CPU时间)等，并且是评估的对象。TOE评估主要关注的是，确保对TOE资源执行了所定义的安全功能要求(SFR)集。这些SFR定义了一些规则，TOE通过这些规则来管制对其资源的访问和使用，从而实现对信息和服务的管控。这些SFR可定义多个安全功能策略(SFP),以表达ToE必须执行的规则。每一个这样的SFP必须通过定义主体、客体、资源或信息及其适用的操作，来明确说明该安全功能策略的控制范围。所有SFP均由TSF(见下文)实现，其机制执行SFR中定义的规则并提供必要的能力。TOE中为正确执行SFR而必须依赖的部分统称为ToE安全功能(TSF)。TSF由TOE中为了安全执行而直接或

19、间接依赖的所有软件、硬件和固件组成。TOE可以是一个包含硬件、固件和软件的整体合一式的产品。TOE也可以是一个分布式产品，内部由多个不同的部分组成，每一部分都为TOE提供持定的服务，并且通过内部通信信道与TOE其他部分相连接。该信道可以小到为一个处理器总线，也可以是TOE之内的一个网络。当TOE由多个部分组成时，TOE的每一部分可拥有自己的那部分TSF,该部分通过内部通信信道与TSF的其他部分交换用户数据和TSF数据，这种交互称为TOE内部传送。在这种情况下，这些TSF的不同部分抽象地形成了执行SFR的组合型TSF。TOE接口可能只局限在特定的ToE内部使用，或者也可允许通过外部通信信道与其他

20、IT产品交互。与其他IT产品的外部交互可以采取以下两种形式：a)其他“可信IT产品”的安全功能要求和TOE的安全功能要求已进行了管理方面的协调，并假设这些其他可信IT产品已正确执行了其安全功能要求(例如：通过独立的评估)。在这种情况下，信息交换被称为TSF间传送，因为它们存在于不同可信产品的TSF之间b）其他IT产品可能是不可信的，被称为“不可信IT产品”。因此，它的SFR或是未知的，或这些SFR的实现被视为是不可信赖的。在这种情况下，TSF促成的信息交换被称为ToE的外部传送，因为在其他IT产品上没有TSF（或它的策略特征是未知的）一个接口集合，不管是交互式的（人机接口），还是可编程的（应用

21、编程接口），通过这些接口，由TSF协调对资源的访问，或者从TSF中获取信息，这一接口集合被称为TSF接口（TSFI）TS11定义了为执行SFR而提供的ToE功能边界。用户在TOE的外部。但为了请求由TOE执行且由SFR中定义的规则所控制的服务，用户要通过TSFI和TOE交互。本部分关注两种类型用户：人类用户和外部IT实体。人类用户可进一步分为本地用户和远程用户，本地用户通过TOE设备（如工作站）直接与ToE交互，远程用户通过其他IT产品间接与TOE交互。用户和TSF之间的一段交互期称为用户会话。可以根据各种因素来控制用户会话的建立，例如：用户鉴别、时段、访问TOE的方法以及允许的（每个用户的或

22、总的）并发会话数。本部分使用术语“授权的”来表示一个用户持有执行某项操作的权力或特权。因此术语“授权用户”表明用户允许执行由SFR定义的特定操作或一组操作。为了表达分离管理责任的要求，相关的安全功能组件（来自FMT_SMR族）明确指出了所要求的管理性角色。角色是预定义的一组规则，用于建立用户按此角色操作时所允许的与TOE之间的交互。一个ToE可以支持任意多个角色的定义。例如，与TOE安全运行相关的角色可以包括“审计管理员”和“用户账号管理员”.TOE包含可用于处理和存储信息的资源。TSF的主要目标是对ToE所控制的资源和信息完整而正确地执行SFRoTOE资源能以多种方式组织并加以利用。但是，本

23、部分作出了一个明确的区分，以便允许规范所期望的安全特性。所有可通过资源来创建的实体，可用以下两种方式中的一种来刻画：实体可以是主动的，意指它们是促使在TOE内部出现动作并导致信息操作的原因：或者，实体也可以是被动的，意指它们或是产生信息的载体，或是存储信息的载体。TOE中对客体执行操作的主动实体，被称为主体。TOE内可存在以下类型的主体：a）代表一个授权用户的那些实体（如UNIX进程）；b）作为一个特殊功能进程，可依次代表多个用户的那些实体（如在客户/服务器结构中可能找到的某些功能）；c）作为TOE自身一部分的那些实体（如不代表某个用户的进程）。本部分用于解决在上述各类主体上实施SFR的问题。

24、TOE中包含和接收信息，且主体得以在这些信息上执行操作的被动实体，称作客体。在一个主体（主动实体）是某个操作的对象（例如进程间通信）的情况下，该主体也可以作为一个客体。客体可以包含信息。引入这一概念是为了详细说明在FDP类中描述的信息流控制策略。由SFR中各规则所控制的用户、主体、信息、客体、会话和资源，可具有某种属性。属性包含TOE为了正确运行而使用的信息,某些属性，如文件名，可能只是提示性的，或者可用来标识单个资源，而另一些属性，如访问控制信息，可能是专为执行SFR而存在的。后面这些属性通常称为“安全属性”。在本部分的某些地方中，“属性”一词将用作“安全属性”的简称。另一方面，无论属性信息

25、的预期目的如何，均有必要按SFR的规定对属性施加控制。TOE中的数据可分为用户数据和TSF数据，图1示意了它们之间的关系。用户数据是存储在TOE资源中的信息，用户可以根据SFR对其进行操作，而TSF对用户数据并不赋予任何特殊的含义。例如，电子邮件消息的内容是用户数据。TSF数据足TSF在按SFR的要求做决策时使用的信息。如果SFR允许，TSF数据可以受用户的影响。安全属性、鉴别数据、由SFR中定义的规则，或为了保护TSF及访问控制列表条目所使用的TSF内部状态变量都是TSF数据的例子。有几个用于数据保护的SFP,诸如访问控制SFP和信息流控制SFP。实现访问控制SFP的机制依据受控范围内的用户

26、、资源、主体、客体、会话、TSF状态数据以及操作等的属性来建立策略决策。这些属性用于管控主体操作客体的规则集中，实现信息流控制SFP的机制依据受控范围内的主体和信息的属性以及管控主体操作信息的规则来建立策略决策。信息的属性与信息一起由TSF予以处理，这些属性可能与载体属性相关联，或可能是来源于载体中的数据。图1用户数据和TSF数据的关系在本部分中处理的两种特殊类型的TSF数据-鉴别数据和秘密可以相同，也可以不同。鉴别数据用于验证用户请求ToE服务时所声称的身份。最常用的鉴别数据形式是口令，为了使安全机制有效，这一形式的鉴别数据需要保密。但是，并非所有形式的鉴别数据都需要保密，生物特征鉴别设备（

27、例如，指纹识别器、视网膜扫描仪）就不依赖于数据保密，而依赖于这些数据只能被一个用户拥有，且不能被伪造。本部分中使用的术语“秘密”，尽管可用于鉴别数据，也同样适用于其他为了执行某特定SFP而必须保密的数据。例如，在强度方面，依靠密码技术保护信道信息机密性的可信信道机制，仅与防止密钥未授权泄露机制是一样的。因此，不是所有的鉴别数据都需要保密，也不是所有的秘密都可用做鉴别数据。图2给出了秘密和鉴别数据间的关系。在该图中，指出了常见的鉴别数据和秘密的数据类型。阳弛u图2”鉴别故据，和，秘密n的关系6安全功能组件本章定义了IS0/IEC15408功能要求的内容和形式，并提供了一个组织方法，以便对ST中添

28、加的新组件的安全功能要求进行描述。功能要求用类、族和组件来表达。6.1.1类结构图3以框图形式示意了功能类的结构。每个功能类包括类名、类介绍和一个或多个功能族。A包含B和若干个C图3功能类结构61.1.1 蟒类名提供标识和划分功能类所必需的信息。每个功能类都有一个唯一的名称，分类信息由三个字符的简名组成。类的简名也用于该类中族的简名规范中。61.1.2 类介绍类介绍描述了这些族满足安全目的的通用意图或方法。功能类的定义不反映要求规范中的任何正式分类法。类介绍用图的形式来描述类中的族以及每个族中组件的层次结构，见6.2的解释。61.2Sft图4以框图形式示意了功能族的结构。审计组件图4功能族结构

29、41.21jg族名部分提供了标识和划分功能族所必需的分类和描述信息。每个功能族有一个唯一的名称。族的分类信息由7个字符的简名组成，前三个字符与类名相同，后跟一个下划线和族名，形如XXX_YYY.唯的简短族名为组件提供了主要的引用名称。61.22族行为是对功能族的叙述性描述，陈述其安全目的，并且是功能要求的概括描述。以下是更详细的描述：a)族的安全目的描述了一个安全问题，该问题可通过TOE利用该族中的一个组件予以解决；b)功能要求的描述概述了组件中包含的所有要求。该描述是面向PP、ST和功能包的作者的，他们希望评价该族是否与他们的特定要求相关。&1.23组件殷功能族包含一个或多个组件，任何一个组

30、件都可被选出来包含到PP、ST和功能包中。本条的目的是，当族一旦被确定为是表达用户安全要求的一个必须的或有用的部分时，为用户选取合适的功能组件提供信息。功能族描述部分的本条内容描述了可使用的组件以及它们的基本原理。组件的详细细节包含在每个组件中。功能族内组件间的关系可能是分级的。如果一个组件相对另一个组件提供更多的安全性，那么该组件对另一个组件来说是更高级的。如6.2所述，族的描述提供了族中组件间层次结构的一个图示。61.24 WS管理包含PP/ST作者认为是给定组件管理活动的一些信息。此条款参考管理类(FMT)的组件，并提供关于通过操作这些组件可能应用的潜在管理活动的指导。PP/ST作者可以

31、选择已明示的管理要求，也可以选择其他没有列出的管理要求以细化管理活动。因而这些信息是提示性的。61.25 W如果PP/ST中包含来自FAU类“安全审计”中的要求，审计要求要包含可供PP/ST作者选择的可审计事件。这些由FAlLGEN安全审计数据产生族的组件支持的要求包括各种按不同详细级别描述的安全相关事件。例疝一个审计记录可能包括下述动作：最小级安全机制的成功使用；基本级一对安全机制的使用以及涉及安全属性的信息；详细级任何机制的配置变化，包括改变前后的实际配置值。显然可审计事件的分类是分级的。例如I,当期望的审计数据产生级别满足基本级时，除非高级事件仅仅比低级事件提供更多的细节，所有已标识为最

32、小级和基本级的可审计事件都应通过适当的赋值操作包括在PP/ST内。当期望的审计数据产生级别满足详细级时，所有标识为最小级、基本级和详细级的可审计事件都应包括在PP/ST内。在FAU类“安全审计”中，更详尽地解释了一些控制审计的规则。6J.3组件结构图5示意了功能组件的结构。组件组件标;F,依姆关器1功能元素图5功能组件结构6.1.3.1组件标识组件标识部分提供识别、分类、注册和交叉引用组件所必需的描述性信息。下列各项作为每个功能组件的部分：个唯一的名称，该名字反映了组件的目的。个简名，即功能组件名的唯一简写形式。简名作为组件分类、注册和交叉引用的主要引用名。简名反映出组件所属的类和族以及在族中

33、组件的编号。个从属于列表。这个组件所从属于的其他组件列表，以及该组件能用于满足与所列组件间的依赖关系。41.12功能元素为每一组件提供了一组元素。每个元素都分别定义并且是自包含的。功能元素是一个安全功能要求，该要求如果再进一步划分将不会产生有意义的评估结果。它是ISO/IEC15408中标识和认可的最小安全功能要求。当构建包、PP或ST时，不允许从一个组件中只选择一个或几个元素，必须将组件的整套元素包含在PP、ST或包中每个功能元素名都有一个唯一的简化形式。例如，要求名FDPJFF.4.2意义如下：F功能要求，DF用户数据保护类，IFF信息流控制功能”族，.4第四个组件，名为“部分消除摘去信息

34、流.2该组件的第2个元素。6J.3.3当一个组件不是自我充分的而需要依赖于其他组件的功能，或与其他组件交互才能正确发挥其功能时，就产生了功能组件间的依赖关系。每个功能组件都提供了一个对其他功能和保障组件依赖关系的完整列表。有些组件可能列出“无依赖关系”。所依赖的组件又可能依赖其他组件。组件中提供的列表是直接的依赖关系。这只是为该功能要求能正确实现其功能提供参考。间接依赖关系，也就是由所依赖组件产生的依赖关系，见本部分附录A。值得注意的是，在某些情况下，依赖关系所提供的多个功能要求是可自由选择的，这些功能要求中的任一个都足以满足依赖关系（例如FDP_UIT.1”数据交换完整性”）依赖关系列表标识

35、出了为满足一个既定组件相关的安全要求，所必需的最少功能或保障组件。从属于既定组件的那些组件也可用来满足依赖关系，本部分指明的依赖关系是规范性的，在PP/ST中它们必须得到满足。在特定的情况下，这种依赖关系可能不适用。只要在基本原理中说清不适用的理由，PP/ST作者就可以在包、PP或ST中舍弃该依赖组件。6.2组件分类本部分中组件的分组不代表任何正式的分类法。本部分包含了族和组件的分类，它们是基于相关功能和目的进行的粗略分组，并且按字母顺序给出。每个类的开始部分都有一个提示性框图，指出该类的分类法、类中的族和族中的组件。这个图对于指明可能会存在于组件间的层次关系是有用的。在功能组件的描述中，有一

36、段文字指出了该组件和任何其他组件之间的依赖关系。在每个类中，都有一个与图6类似的描述族层次关系的图。在图6中，第1个族（族1）包括了三个有从属关系的组件，其中组件2和组件3都可以用来满足对组件1的依赖关系。组件3从属于组件2,并且可以用来满足对组件2的依赖关系。族3图6示范类分解图在族2中有三个组件，这三个组件不全都有从属关系。组件1和组件2不从属于其他组件。组件3从属于组件2,可以用来满足对组件2的依赖关系，但不能满足对组件1的依赖关系。在族3中，组件2、3、4都从属于组件1。组件2和组件3也都从属于组件1,但无可比性。组件4从属于组件2和组件3。这些图的目的是补充族中的文字说明，使关系的识

37、别更容易。它们并不能取代每个组件中的“从属于：”的注释，这些注释是对每个组件从属关系的强制性声明。6. 2.1突出表示组件变化族中组件的关系约定以粗体字突出表示。在此约定所有新的要求用粗体表示。对于有从属关系的组件，当要求被增强或修改而超出前一组件的要求时，要用粗体字表示。另外，超出前一组件的任何新的或增强的允许操作，也使用粗体字突出表示。7FMJ类：安全审计安全审计包括识别、记录、存储和分析那些与安全相关活动（即由TSP控制的活动）有关的信息。可通过检查审计记录结果确定发生了哪些安全相关活动以及哪个用户要对这些活动负责。木类的组件构成分解如图7所示。安全审计查阅FAUSAR:3FAlLSEL

38、:安全审计事件选择J2FAU.STG:安全审计事件存储37.1 安全审计自动响应（FAU_ARP）7.1.1 族行为本族定义了在检测到潜在安全侵害事件时所作出的响应。7.1.2 组件层次FAU_ARP.1“安全告警”，当检测到潜在的安全侵害时TSF应采取动作。7.1.3 FMARP.1FMT中的管理功能可考虑下列行为：a）对行为的管理（添加、删除或修改）.7.1.4 FMLARP.1审计如果PP/ST中包含FAU,GEN“安全审计数据产生”，下列行为应是可审计的:a）最小级：由于潜在的安全侵害而采取的动作。7.1.5 FAU_ARP.1安从属于：无其他组件。依赖关系：FALSAA.1潜在侵害分

39、析。7.1.5.1 FAUARP.1.1当检漓到潜在的安全侵害时，TSF应采取的赋值：动作列表。7.2 安全审计数据产生（FAUGEN）7.21 族行为本族定义了一些在TSF控制下对安全相关事件的发生情况进行记录的要求。本族识别审计的级别，列举TSF可审计的事件类型，以及标识在各种审计记录内应提供的审计相关信息的最小集合。7.2.2 组件层次FAU_GEN.1审计数据产生”定义可审计事件的级别，并规定在每个记录中应记录的数据列表。FAlLGEN.2用户身份关联,TSF应把可审计事件与单个用户身份相关联。7.2.3 FALLGEN.1、FALLGEN.2管理尚无预见的管理活动。7.2.4 FAU

40、_GEN.KFAU_G0i,2审计尚无预见的可审计事件。7.2.5 FAU_GEN.1审计据产从属于：无其他组件。依赖关系：FPT_STM.1可信时间戳。7.2.5.1 FAUGEN.1.1TSF应能为下述可审计，件产生审计记录：a）审计功能的开启和关闭；b）有关选择，选取f：最小级、基本级、详细级、未规定审计级别的所有可审计事件；O赋值：其他专门定义的可审计事件。7.2.5.2 FAU（JEN.1.2TSF应在每个审计记录中至少记录下列信息：a）事件的日期和时间、事件类型、主体身份（如果适用）、事件的结果侬功或失效）；b）对每种审计事件类型，基于PP/ST中功能组件的可审计事件的定义，赋值：

41、其他审计相关信息。7.2.6FAUGBl2用户身份关联从属于：无其他组件。依赖关系：FAU_GEN.1FIAUlD,1审计数据产生；标识的时机。7.2.6.1 FAUGEN21对于已标识身份的用户的行为所产生的审计事件，TSF应能将每个可审计事件与引起该事件的用户身份相关联。7.3安全审计分析（FAiLSAA）7.3.1 族行为本族定义了一些采用自动化手段分析系统活动和审计数据以寻找可能的或真正的安全侵害的要求。这种分析通过入侵检测来实现，或对潜在的安全侵害作出自动响应。基于检测而采取的动作，可用FALARP“安全审计自动响应”族来规范。7.3.2 组件层次在FAU_SAA.l”潜在侵害分析”

42、中，要求在固定规则集的基础上进行基本的阈值检测。在FALSAA.2”基于轮廓的异常检测”中，TSF维护系统使用的单个轮廓。这里的“轮廓”表示由轮廓目标组成员所完成的历史模式的使用。轮廓目标组是指与TSF交互的一个或多个个体（如单个用户、共享一个组ID或账号的用户、分配了指定角色的用户、整个系统或网络节点的用户）.轮廓目标组的每个成员都被分配了一个单独的置疑等级，表明成员当前的行为与轮廓中已建立的使用模式的一致程度如何。此分析可实时进行，也可在信息采集后的批量分析阶段进行。FAlLSAA.3”简单攻击探测,TSF应能检测到那些对SFR实施将产生重大威胁的特征事件的发生。对需征事件的搜索可以实时进

43、行，也可以在信息采集后的批量分析阶段进行。FALSAA.4”复杂攻击探测”，TSF应能表示并检测到多步骤入侵情景。TSF应能对照已知事件序列来比较（可能是由多个用户执行的）系统事件以表示完整入侵情景。TSF应能在发现特征事件或事件序列时进行提示，该事件预示一个对SFR实施的潜在违反。7.3.3 FALSAAJ管理FMT中的管理功能可考虑采取下列行为：a）通过（添加、修改、删除）规则集中的规则来维护规则。7.3.4 FAUSAA.2FMT中的管理功能可考虑下列行为：a）对轮廓目标组中的用户组进行维护（删除、修改、添加）。7.3.5 FALSAA.3IraFMT中的管理功能可考虑下列行为：a）对系

44、统事件的子集进行维护（删除、修改、添加）。7.3.6 FAUSAA.4WSFMT中的管理功能可考虑下列行为：a）对系统事件的子集进行维护（删除、修改、添加）；b）对系统事件的序列集进行维护（删除、修改、添加）7.3.7 FAU_SAA.KFAU_SAA.2%FAU_SAA.3、FAU_SAA.4审计如果PP/ST中包含FALGEN“安全审计数据产生”，下列行为应是可审计的a）最小级：开启和关闭任何分析机制；b）最小级：通过工具软件实现自动响应。7.3.8 FAUSAA.1潜在侵害分析从属于：无其他组件。依赖关系：FAU_GEN.1审计数据产生。7.3.8.1 FAlTSAA.1.1TSF应能使

45、用一组规则去监测审计事件，并根据这些规则指示出对实施SFR的潜在侵害。7.3.8.2 FAUSAA.1.2TSF应执行下列规则监测审计事件：a)已知的用来指示潜在安全侵害的赋值：已定义的可审计事件的子集的累积或组合；b)赋值：任何其他规则。7.3.9 FAU_SAA.2基于轮廓的异常检渊从属于：无其他组件。依赖关系：FIAJID.1标识的时机。7.3.9.1 FAUSAA2.1TSF应能维护系统使用轮廓。在这里单个轮廓代表由赋值：轮廓目标组成员完成的历史使用模式。7.3.9.2 FAUSAA2.2TSF应维护一个与每个用户相对应的疑等级，这些用户的活动已记录在轮屏中。在这里，置疑等级代表用户当

46、前活动与轮廓中已建立的使用模式不一致的程度。7.3.9.3 FAUSAA.23当用户的置疑等级超过门限条件赋值：TSF报告异常活动的条件时，TSF应能指出对SFR实施的可能侵害即将发生。7.3.10 FMLSAA.3简单攻击探测从属于：无其他组件。依赖关系：无依赖关系。7.3.10.1 FAUSAA3.1对预示可能违反SFR实施的下列特征事件赋值：系统事件的一个子集LTSF应能维护一个内部表示。TSF应能对照特征事件比对系统活动记录，系统活动可以通过检查赋值：用来确定系统活动的信息而辨明.7.3.10.3 FAUSAA33当发现一个系统事件与一个预示可能潜在违反SFR实施的特征事件匹配时，TSF应能指出潜在违反SFR实施的事件即将发生。7.3.11 FAU_SAA.4鳗杂攻击探测从属于：FAU_SAA.3简单攻击探测。依赖关系：无依赖关系。7.3.11.1 FAUSAA.4.1对已知入侵情景的事件序列赋值：