第3章安全功能组件和安全保障组件 由第2章可知，CC提供了一套描述IT产品安全评估的标准化技术术语及预定义的安全功能组件和安全保障组件列表，可用于规范性地描述IT产品的安全要求及安全方案，并规范TOE安全评估过程和方法，指导IT产品供应商的安全功能设计、开发、测试和产业化推广等。 为理解IT产品客户需求(即PP)和IT产品供应商解决方案(ST)的编制方法，便于按CEM对IT产品实施评估活动，有必要掌握CC中安全功能组件和安全保障组件结构，理解CEM中基于CC的IT产品安全评估模型及安全保障组件的评估活动内容。 本章将围绕GB/T 18336—2015第2部分和第3部分文档，对CC安全功能组件和安全保障组件进行解读，具体内容包括以下两个部分。 (1) GB/T 18336.2—2015(简称CC第2部分)： 解释安全功能要求范型、安全功能组件层次关系、11种安全功能类相关的族及其组件列表。 (2) GB/T 18336.3—2015(简称CC第3部分)： 解释安全保障概念、保障组件层次关系、PP、ST和TOE安全保障族及其组件列表，包括预定义的安全保障包（EAL）。 3.1安全功能组件 CC第2部分给出了描述IT产品安全功能要求(SFR)的一个标准化安全功能组件目录。这个标准化安全功能组件列表用于以下用途。 (1) 在PP/ST中描述TOE预期的安全行为。 (2) 满足PP/ST中所列TOE的安全目的。 (3) 规范用户通过TOE直接交付或促使TOE响应用户请求的可测试安全功能。 (4) 应对在TOE预期运行环境中的各种威胁。 (5) 覆盖在PP/ST中所有指定的组织安全策略。 3.1.1功能组件结构 CC第2部分的安全功能组件可用于规范TOE的安全功能要求(SFR)。这些SFR可定义多个安全功能策略(SFP)，以表达TOE必须执行的安全规则。每个这样的SFP必须通过定义主体、客体、资源或信息，及其适用的操作，来明确说明该安全功能策略的控制范围。IT产品的所有SFP均由TOE安全功能(TSF)实现，即TSF机制执行SFR中定义的规则并提供必要的TSF自身安全保护能力。 CC将IT产品的安全功能组织为一个分层功能结构(如图3.1所示)。 (1) 类： 由族组成。 (2) 族： 由组件组成。 (3) 组件： 由元素组成。 (4) 元素： 一个不可分割的基本功能要求。 GB/T 18336—2015第2部分共列出了11个类、65个族和136个安全功能组件。类、族、组件和元素间的层次关系如图3.1所示。组件由元素组成，构成了不能再分的最小安全要求集合，它是PP、ST、TOE或包安全功能要求选择的最小单位。在CC中，以“类_族.组件号”的方式标识组件，例如组件“FDP_DAU.1基本数据鉴别”，其中FDP指“用户数据保护”功能类，DAU指“数据鉴别”族。 图3.1安全功能类、族、组件和元素的层次关系 CC中的安全功能类是用来描述一组共享共同关注点的安全要求集合。换句话说，类中所有族成员及其安全功能组件关注共同的安全目的。CC中的功能类安全目的是可知的，并且有一个结构化表格来描述组成类的族成员。表3.1列出了CC中11个安全功能类及其安全目的，其中前7个安全功能类与IT产品用户紧密相关，而后4个安全功能类是为确保IT产品自身安全的安全功能模块设置的。因此后4个安全功能类用于对TOE安全功能(TSF)模块自身安全性进行保证。CC给每个功能类都赋予一个长名和一个以F开头的3个字母的助记符短名标识。 表3.1安全功能类 短名长名安 全 目 的 FAU安全审计监控、获取、记录、存储、分析和报告与安全事件有关的信息 FCO通信确认信息传送的原发者身份和接收者身份，并确保原发者不能否认发送过信息，接收者也不能否认收到过信息 FCS密码支持管理和控制密钥及密钥在运算过程中的使用安全 FDP用户数据保护保护在输入、输出和存储过程中的TOE内部的用户数据，以及与用户数据直接相关的安全属性数据 FIA标识和鉴别确保授权用户的无歧义标识以及安全属性与用户/主体的正确绑定 FMT安全管理管理安全属性、数据和安全功能，并定义安全角色及其相互作用，如权限分离原则 FPR隐私提供用户信息不被其他用户发现或滥用的保护 FPTTSF保护维护TSF管理功能及其数据的完整性 FRU资源利用通过容错和服务优先等机制确保所需资源的可用性 FTATOE访问控制建立用户会话 FTP可信路径/信道提供用户和TSF之间，以及TSF和其他可信IT产品之间的可信通信路径 图3.2展示了CC安全功能类的结构，每个类包括类名、类介绍和一个或多个族成员。 注意，11个安全功能类彼此之间是并列关系，类之间不存在层次关系。因此，在CC第2部分定义的功能类是按照类的助记符短名字母进行排序的。 从图3.2安全功能类结构示意图可看出，类的成员是功能族。族是用来陈述一组共享安全目的但是安全关注点或安全精确度不一样的安全功能组件。在CC第2部分中，每个功能族都在类名下面被分配了一个方便记忆的3个字母的助记符，它和类助记符共同构成一个功能族短名。CC的安全功能族结构提供了标识和划分功能族所必需的分类和描述信息。每个功能族有一个唯一的名称，其标识信息由7个字符组成： 前三个字符与类名助记符相同，后面跟一个下画线和3个字符组成的族名助记符。例如“FDP_DAU数据鉴别”，其中FDP指“用户数据保护”类，DAU指“数据鉴别”族。图3.3以框图形式展示了CC的功能族结构，其中族行为描述了功能族的安全目的，是对该族所有安全功能组件要求的概括描述。 图3.2安全功能类结构示意 图3.3安全功能族结构示意 图3.3族结构中的“族行为”部分描述可用的组件以及使用这些组件的基本原理(及组件满足的安全目的)。如果一个族成员 （组件）存在层次关系或顺序，换句话说如果一个组件相对另一个组件提供更多的安全功能或安全保障能力，那么“组件层次”部分描述这些组件之间的层次关系，即一个组件相对另一个组件来说包含了更高级别的安全功能。有关操作安全管理活动和会被审计的安全事件建议在“管理”部分描述。如果PP/ST中包含来自FAU类“安全审计”中的要求，功能族中的“审计”部分包含了可供PP/ST作者选择的有关该安全功能组件的可审计事件。 图3.3的“组件”是一组安全要求的特殊集合，它由一系列元素构建而成。组件中的元素是一个不可分割的安全要求，它可通过第6章介绍的CEM中某个安全评估工作单元来验证。 每个组件都有一个有意义的长名，用以识别和描述该组件安全要求。CC第2部分给每个安全功能组件分配了一个包含了类助记符、族助记符和一个唯一的数字组成的短名。组件短名的标记结构如图3.4所示，每个组件可由一个或多个元素组成，每个功能元素名都有一个唯一的简化形式。图3.4以FDP_IFF.4.2组件元素为例列出了CC中的安全功能类、族、组件和元素的符号记法，各项意义为： F——功能要求； DP——“用户数据保护”类； _IFF——“信息流控制功能”族； .4——第4个组件； 名为“部分消除非法信息流”； .2——该组件的第2个元素。如果一个组件有不止一个元素，那么在PP/ST编制中它们全部都要被使用，否则就必须为该PP/ST定义一个满足特定要求的扩展组件。 图3.5展示了CC第2部分的安全功能组件的结构。“组件标识”部分提供识别、分类、注册和交叉引用组件所必需的描述性信息。“依赖关系”列表提供了一个对其他功能和保障组件依赖关系的完整列表。所依赖的组件又可能依赖其他组件。组件依赖关系中提供的组件列表是直接的依赖关系，这只是为该功能要求能正确实现其功能提供参考。间接依赖关系，也就是由所依赖组件产生的依赖关系。功能组件依赖关系可参见CC第2部分的附录。注意有些组件可能列出“无依赖关系”。“功能元素”是该组件的一个安全功能要求，是一个再进一步划分将不会产生有意义评估结果的组件元素。因此组件元素是CC中标识和认可的最小安全功能要求，当构建包、PP/ST、TOE安全要求时，CC不允许TOE消费者和开发者从一个组件中只选择一个或几个组件元素，必须将组件的所有元素包含在PP、ST、TOE或包中。 图3.4功能类、族、组件和元素的标准符号记法 图3.5安全功能组件结构 用户可用CC第2部分的11个功能类描述IT产品常见的安全功能要求。当PP/ST编制人员选择安全功能组件去构建TOE的安全要求时，首先需确定合适的功能类。表3.2~表3.12按照功能类列出了CC第2部分定义的11种安全功能类相关的族及其组件列表。 3.1.2安全审计功能组件 CC第2部分讨论的第一个安全功能类是安全审计(FAU)。该类由定义如何选择审计事件、产生审计数据、查阅和分析审计数据、对安全事件自动响应以及存储和保护审计数据等方面要求的功能族组成(如表3.2所示)。FAU族和组件的多样化为TSF描述提供了全方位的安全审计要求，提供了识别、记录、存储和分析那些与TOE安全行为有关事件的信息。另外，FAU族和组件也给出可用来对抗针对安全审计功能攻击的一些方式——权限误用以及绕过审计功能来阻止审计事件的获取等安全要求。 表3.2FAU功能类： 安全审计 族标识族名称功 能 描 述包 含 组 件组 件 名 称 FAU_ARP安全审计自动响应定义在检测到潜在安全侵害事件时所作出的动作FAU_ARP.1安全告警 FAU_GEN安全审计数据产生定义需要记录的安全相关事件 FAU_GEN.1审计数据产生 FAU_GEN.2用户身份关联 FAU_SAA安全审计分析定义安全事件的自动化分析要求 FAU_SAA.1潜在侵害分析 FAU_SAA.2基于轮廓的异常检测 FAU_SAA.3简单攻击探测 FAU_SAA.4复杂攻击探测 续表 族标识族名称功 能 描 述包 含 组 件组 件 名 称 FAU_SAR安全审计查阅定义审计工具的相关要求 FAU_SAR.1审计查阅 FAU_SAR.2限制审计查阅 FAU_SAR.3可选审计查阅 FAU_SEL安全审计事件选择定义在TOE运行期间从所有审计事件集合中选取被审计事件的要求FAU_SEL.1选择性审计 FAU_STG安全审计事件存储定义一些TSF能够创建并维护一个安全审计迹的要求 FAU_STG.1受保护的审计迹存储 FAU_STG.2审计数据可用性保证 FAU_STG.3审计数据可能丢失时的行为 FAU_STG.4防止审计数据丢失 3.1.3通信功能组件 CC第2部分讨论的第二个安全功能类是通信(FCO)。如类名所示的那样，FCO安全功能从属于信息传输，特别关注如何确认在数据交换中参与方的身份、确认信息传输的原发者身份(原发证明)和信息传输的接收者身份(接收证明)。通信类有两个族用来确保原发者不能否认发送过信息，接收者也不能否认收到过信息。FCO安全功能类提供了两个族，原发抗抵赖(FCO_NRO)和接收抗抵赖(FCO_NRR)，相关组件如表3.3所示，FCO族尤其关注这些安全功能凭据的生成。 表3.3FCO功能类： 通信 族标识族名称功 能 描 述包 含 组 件组 件 名 称 FCO_NRO原发抗抵赖信息的发送者提供请求信息原发证据 FCO_NRO.1选择性原发证明 FCO_NRO.2强制性原发证明 FCO_NRR接收抗抵赖信息的接收者提供请求信息接收证据 FCO_NRR.1选择性接收证明 FCO_NRR.2强制性接收证明 3.1.4密码支持功能组件 密码支持(FCS)类是CC第2部分第三个被讨论的安全功能类。该类应用于IT产品的密码模块(硬件、软件和固件)的数据加密。如2.1节所说，CC并不声明哪些加密算法或密钥长度是可被接受的。取而代之的是，FCS类关注TOE的数据加解密操作和密钥管理——换句话说就是TOE加密功能的安全使用技术要求。每当需要使用生成或验证数字签名、加密或解密数据等安全功能时，就需要调用FCS组件和元素。同样地，FCS组件和元素也被调用来指定TOE整个生命周期内的密钥管理活动，如密钥生成、分发、存取、销毁和运算(如表3.4所示)。 表3.4FCS功能类： 密码支持 族标识族名称功 能 描 述包 含 组 件组 件 名 称 FCS_CKM密钥管理指定整个生命周期内的密钥管理活动 FCS_CKM.1密钥生成 FCS_CKM.2密钥分发 FCS_CKM.3密钥存取 FCS_CKM.4密钥销毁 FCS_COP密码运算按照特定的算法和规定长度的密钥来进行运算FCS_COP.1密码运算 3.1.5用户数据保护功能组件 用户数据保护(FDP)定义了TOE保护用户数据的各种安全要求。这些要求通过4组功能族(如表3.5所示)来描述在输入、输出和存储过程中的TOE内部用户数据保护，以及与用户数据保护直接相关的安全属性。 表3.5FDP功能类： 用户数据保护 族标识族名称功 能 描 述包 含 组 件组 件 名 称 FDP_ACC访问控制策略定义访问控制策略及每一策略的控制范围 FDP_ACC.1子集访问控制 FDP_ACC.2完全访问控制 FDP_ACF访问控制功能描述在FDP_ACC“访问控制策略”中所命名的访问控制实现FDP_ACF.1基于安全属性的访问控制 FDP_DAU数据鉴别提供保证特定数据有效性信息 FDP_DAU.1基本数据鉴别 FDP_DAU.2带担保者身份的数据鉴别 FDP_ETC从TOE输出定义从TOE输出用户数据或与所输出用户数据与安全属性之间的安全限制 FDP_ETC.1不带安全属性的用户数据输出 FDP_ETC.2带有安全属性的用户数据输出 FDP_IFC信息流控制策略定义信息流控制策略及每一策略的控制范围 FDP_IFC.1子集信息流控制 FDP_IFC.2完全信息流控制 FDP_IFF信息流控制功能描述实现已信息流控制SFP的特定功能的一些规则 FDP_IFF.1简单安全属性 FDP_IFF.2分级安全属性 FDP_IFF.3受限的非法信息流 FDP_IFF.4部分消除非法信息流 FDP_IFF.5无非法信息流 FDP_IFF.6非法信息流监视 FDP_ITC从TOE之外输入定义从TOE输入用户数据或与所输入用户数据与安全属性之间的安全限制 FDP_ITC.1不带安全属性的用户数据输入 FDP_ITC.2带安全属性的用户数据输入 FDP_ITTTOE内部传输定义用户数据通过内部信道在TOE各部分之间传输时的用户数据保护要求 FDP_ITT.1基本内部传输保护 FDP_ITT.2按属性分隔传输 FDP_ITT.3完整性监视 FDP_ITT.4基于属性的完整性监视 续表 族标识族名称功 能 描 述包 含 组 件组 件 名 称 FDP_RIP残余信息保护确保当资源从一个客体释放并重新分配给另一个客体时，其中的任何数据都不可用 FDP_RIP.1子集残余信息保护 FDP_RIP.2完全残余信息保护 FDP_ROL回退撤销最后一次或一系列操作，并返回到一个先前已知的状态 FDP_ROL.1基本回退 FDP_ROL.2高级回退 FDP_SDI存储数据的完整性对存储在由TSF控制的载体内的用户数据进行保护 FDP_SDI.1存储数据的完整性监视 FDP_SDI.2存储数据完整性监视和行动 FDP_UCTTSF间用户数据保密性传输保护确保用户数据通过外部信道在TOE和其他可信IT产品间传输时用户数据保密性FDP_UCT.1基本的数据交换保密性 FDP_UITTSF间用户数据完整性传输保护用户数据在TOE和其他可信IT产品间传输时提供完整性保护 FDP_UIT.1数据交换的完整性 FDP_UIT.2原发端数据交换恢复 FDP_UIT.3接收端数据交换恢复 本类中的4组功能族如下。 （1） 用户数据安全保护策略，包括访问控制策略（FDP_ACC）和信息流控制策略(FDP_IFC)功能组件，以允许PP/ST作者命名用户数据保护安全功能策略，并定义该安全策略的控制范围，这对于说明安全目的是必要的。 （2） 在不同类型的在线事务中保护用户数据完整性和一致性的安全功能，包括访问控制功能（FDP_ACF）、信息流控制功能（FDP_IFF）、TOE内部传送（FDP_ITT）、残余信息保护（FDP_RIP）、回退（FDP_ROL）和存储数据的完整性（FDP_SDI）等用户数据保护形式功能组件。 （3） 在脱机事务中的用户数据保护功能，如离线导入（FDP_ITC）、导出（FDP_ETC）、数据鉴别（FDP_DAU）等数据转储安全功能。 （4） 负责处理TSF与其他可信IT产品间的通信中的用户数据完整性和一致性的安全功能，如TSF间用户数据保密性传送保护（FDP_UCT）和TSF间用户数据完整性传送保护（FDP_UIT）。 3.1.6用户标识与鉴别功能组件 CC第2部分讨论的第五个安全功能类是用户标识与鉴别(FIA)。正如名称预期，该安全功能类定义了执行和管理用户身份鉴别和认证功能的要求。授权用户的明确标识以及安全属性与用户和主体的正确绑定是实施预定安全策略的关键。本类中的安全功能族负责确认和验证使用TOE的用户身份、确认他们与TOE交互的权限、以及每个授权用户安全属性的正确绑定。CC中的其他安全功能类(如FDP“用户数据保护”、FAU“安全审计”) 要求的有效性都是建立在对用户身份的正确标识和鉴别基础上的(如表3.6所示)。用户标识与鉴别确保潜在用户的正确身份都是确定的，无论是认证的或非认证的。用户认证确保用户的声明身份都是被验证的。相对于TOE，每个认证用户的访问控制能力及其授予的权限都应该是确定的。另外，用户认证都应该遵循一定的安全策略，例如在认证失败达到指定次数后TOE要采取的行为也应是定义的。 表3.6FIA功能类： 标识和鉴别 族标识族名称功 能 描 述包 含 组 件组 件 名 称 FIA_AFL鉴别失败定义不成功的鉴别尝试次数和鉴别尝试失败时TSF应采取的动作FIA_AFL.1鉴别失败处理 FIA_ATD用户属性定义定义用户相关的安全属性FIA_ATD.1用户属性定义 FIA_SOS秘密的规范定义生成和提供秘密应满足规定的质量度量及度量机制 FIA_SOS.1秘密的验证 FIA_SOS.2TSF生成秘密 FIA_UAU用户鉴别定义TSF所支持的用户鉴别机制的类型 FIA_UAU.1鉴别的时机 FIA_UAU.2任何动作前的用户鉴别 FIA_UAU.3不可伪造的鉴别 FIA_UAU.4一次性鉴别机制 FIA_UAU.5多重鉴别机制 FIA_UAU.6重鉴别 FIA_UAU.7受保护的鉴别反馈 FIA_UID用户标识定义用户标识其身份的条件 FIA_UID.1标识的时机 FIA_UID.2任何动作前的用户标识 FIA_USB用户主体绑定定义建立和维护用户安全属性与代表该用户主体间关联关系的要求FIA_USB.1用户主体绑定 3.1.7安全管理功能组件 安全管理(FMT)类指定了管理TOE安全功能和它们的属性和数据的要求，包括建立、撤销和终结安全属性的条件(如表3.7所示)。FMT要求TOE安全功能被调用以及被谁调用等管理规则应是确定的。安全管理人员职责分离和责任，以及安全管理人员与其他操作人员的职责和责任分享规则等也应是建立的。安全管理类主要有以下几个目的。 (1) 管理TSF数据。 (2) 管理安全属性。 (3) 管理TSF功能。 (4) 定义安全角色。 表3.7FMT功能类： 安全管理 族标识族名称功 能 描 述包 含 组 件组 件 名 称 FMT_MOFTSF中功能的管理允许授权用户控制对TSF中功能的管理FMT_MOF安全功能行为的管理 FMT_MSA安全属性的管理允许授权用户控制安全属性的管理 FMT_MSA.1安全属性的管理 FMT_MSA.2安全的安全属性 FMT_MSA.3静态属性初始化 FMT_MSA.4安全属性值的继承 FMT_MTDTSF数据管理允许授权用户(角色)控制TSF数据的管理 FMT_MTD.1TSF数据的管理 FMT_MTD.2TSF数据限值的管理 FMT_MTD.3安全的TSF数据 FMT_REV撤销撤销TOE内各种实体安全属性FMT_REV.1撤销 FMT_SAE安全属性到期对安全属性的有效性实施时间限制FMT_SAE.1时限授权 FMT_SMF管理功能规范定义TSF提供安全的管理功能FMT_SMF.1管理功能规范 FMT_SMR安全管理角色控制用户不同角色的分配 FMT_SMR.1安全角色 FMT_SMR.2安全角色限制 FMT_SMR.3承担角色 3.1.8隐私功能组件 隐私要求在CC第2部分的FPR类中指定。这些要求的目的是保护用户身份等个人信息不被泄露、误用或与TOE资源的使用相关联。如表3.8所示，隐私要求类由匿名、假名、不可关联性和不可观察性4个族组成。 表3.8FPR功能类： 隐私 族标识族名称功 能 描 述包 含 组 件组 件 名 称 FPR_ANO匿名确保用户在其使用资源或服务时，不暴露身份 FPR_ANO.1匿名 FPR_ANO.2无索求信息的匿名 FPR_PSE假名确保用户在不暴露其真实身份的情况下使用资源或服务，但仍能对该次使用负责 FPR_PSE.1假名 FPR_PSE.2可逆假名 FPR_PSE.3别名假名 FPR_UNL不可关联性一个用户可以多次使用资源和服务，但任何人都不能将这些使用联系在一起FPR_UNL.1不可关联性 FPR_UNO不可观察性用户在使用资源和服务时，其他人，特别是第三方不能观察到该资源和服务正在被使用 FPR_UNO.1不可观察性 FPR_UNO.2影响不可观察性的信息的分配 FPR_UNO.3无索求信息的不可观察性 FPR_UNO.4授权用户可观察性 3.1.9TSF保护功能组件 TSF保护(FPT)类包含了保护TOE安全功能(TSF)和TOE安全功能数据(安全元数据)的要求。TOE依靠的底层硬件和操作系统等IT运行环境必须如预期一样执行，以确保TOE安全功能的正确运行。因此，FPT类中定义了验证TSF正确运行的安全要求，例如自检测、重放检测、响应TOE物理攻击等。如表3.9所示，FPT定义了TOE安全功能输出数据的一致性、完整性和有效性的要求，同样也定义了内部数据传输或复制数据的一致性、完整性和有效性要求。TOE安全功能的可信启动与恢复条件在该类中声明。检测和重播消息、生成可信时间戳、同步重要安全功能时间的机制等也在该类中指定。其他族确保TOE安全策略的要求总是被调用并强制执行。 表3.9FPT功能类： TSF保护 族标识族名称功 能 描 述包 含 组 件组 件 名 称 FPT_FLS失效保护确保当确定的失效出现时，TOE总是保持一种安全状态FPT_FLS.1失效即保持安全状态 FPT_ITA输出TSF数据的可用性确保向另一个可信IT产品提供的TSF数据是可用的FPT_ITA.1TSF间可用性不超过既定可用性度量 FPT_ITC输出TSF数据的保密性确保在TSF与另一个可信IT产品间传输时，TSF数据不被泄露FPT_ITC.1传输过程中TSF间的保密性 FPT_ITI输出TSF数据的完整性确保在TSF与另一个可信IT产品之间传输时，TSF数据不会被未授权修改 FPT_ITI.1TSF间篡改的检测 FPT_ITI.2TSF间篡改的检测与纠正 FPT_ITTTOE内TSF数据的传输确保在TOE的不同部件间传输的TSF数据是安全和完整的 FPT_ITT.1内部TSF数据传输的基本保护 FPT_ITT.2TSF数据传输的分离 FPT_ITT.3TSF数据完整性监视 FPT_PHPTSF物理保护限制对TSF进行未授权的物理访问，以及阻止和抵抗对TSF进行未授权的物理修改或替换 FPT_PHP.1物理攻击的被动检测 FPT_PHP.2物理攻击报告 FPT_PHP.3物理攻击抵抗 FPT_RCV可信恢复确保TSF能确定TOE是在没有削弱保护能力的情况下启动的，并在运行中断后能在不削弱保护能力的情况下恢复 FPT_RCV.1手工恢复 FPT_RCV.2自动恢复 FPT_RCV.3无过度损失的自动恢复 FPT_RCV.4功能恢复 FPT_RPL重放检测要求TSF应能够检测出既定实体的重放FPT_RPL.1重放检测 FPT_SSP状态同步协议规定了关于TSF某些关键安全功能如何使用该可信协议的要求 FPT_SSP.1简单可信回执 FPT_SSP.2相互可信回执 FPT_STM时间戳要求TSF为TSF功能提供可靠的时间戳FPT_STM.1可靠的时间戳 续表 族标识族名称功 能 描 述包 含 组 件组 件 名 称 FPT_TDCTSF间TSF数据的一致性要求TSF提供确保TSF间属性的一致性FPT_TDC.1TSF间基本的TSF数据一致性 FPT_TEE外部实体测试规定了由TSF测试外部实体的要求FPT_TEE.1外部实体测试 FPT_TRCTOE内TSF数据复制的一致性要求TSF确保TSF数据在多处复制时的一致性FPT_TRC.1内部TSF的一致性 FPT_TSTTSF自检提供检测TSF是否正确运转的能力FPT_TST.1TSF检测 3.1.10资源利用功能组件 资源利用(FRU)类中的资源使用要求保证了TOE资源的有效性。本类提供3个族以支持所需资源的可用性，诸如处理能力或存储容量(如表3.10所示)。容错要求确保声明的TOE功能能够继续正确执行，即使是在经历了指定的失败状况下。FRU允许TOE安全功能被分配到与其他低优先级功能相关的资源使用优先级。另外，FRU要求允许资源在已知用户和主体间被分配，从而防止资源垄断和拒绝服务攻击。 表3.10FRU功能类： 资源利用 族标识族名称功 能 描 述包 含 组 件组 件 名 称 FRU_FLT容错确保即便发生了失效，TOE也将维持正常运转 FRU_FLT.1降级容错 FRU_FLT.2受限容错 FRU_PRS服务优先级确保TSF控制下高优先级活动均能完成，而不受低优先级活动造成的不当干扰或延迟影响 FRU_PRS.1有限服务优先级 FRU_PRS.2全部服务优先级 FRU_RSA资源分配提供配额机制的要求，确保用户和主体不因未授权地独占资源而出现拒绝服务 FRU_RSA.1最高配额 FRU_RSA.2最低和最高配额 3.1.11TOE访问功能组件 评估TOE访问控制功能的要求包含在FTA类中。该类定义了建立一个用户会话的6种类型的控制安全要求(如表3.11所示)。 (1) 在一个给定会话中限制用户访问的安全属性范围。 (2) 限制单独一个用户通过多个终端访问TOE的多个并行会话。 (3) 锁定和解锁用户会话以响应指定控制规则或参数值要求。 (4) 显示TOE资源使用的查询。 (5) 显示一个用户的TOE访问历史，包含成功的和不成功的尝试。 (6) 拒绝会话建立。 表3.11FTA功能类： TOE访问 族标识族名称功 能 描 述包 含 组 件组 件 名 称 FTA_LSA可选属性范围限定提供关于TOE在建立会话时限制会话安全属性范围定义能力FTA_LSA.1可选属性范围限定 FTA_MCS多重并发会话限定限制属于同一个用户的并发会话数 FTA_MCS.1多重并发会话的基本限定 FTA_MCS.2基于属性的单用户多重并发会话限定 FTA_SSL会话锁定和终止提供TSF原发和用户原发的交互式会话的锁定、解锁和终止能力 FTA_SSL.1TSF原发会话锁定 FTA_SSL.2用户原发会话锁定 FTA_SSL.3TSF原发会话终止 FTA_SSL.4用户原发会话终止 FTA_TABTOE访问旗标定义向用户显示有关适当使用TOE的一个可配置劝告性警示信息要求FTA_TAB.1默认的TOE访问旗标 FTA_TAHTOE访问历史提供了TOE显示与先前尝试建立一个会话相关的信息的要求FTA_TAH.1TOE访问历史 FTA_TSETOE会话建立提供了拒绝用户基于属性对TOE进行访问的要求FTA_TSE.1TOE会话建立 3.1.12可信路径/信道功能组件 可信路径/信道(FTP)类定义了可信路径和可信信道的要求。若要建立和维护一个TOE安全功能和其他可信IT产品之间的安全通信信道，就需要使用可信信道要求。在某个应用中，用户或TOE安全功能数据可能需要被交换以执行重要安全功能，这就需要在它们之间建立一个可信信道。相反地，若需建立和维护用户与TOE安全功能之间的安全通信，就需要用到可信路径要求。对于可信信道和可信路径，通信双方都在该类中被指定，数据将被保护以防止在传输中被未鉴别的非法用户进行有意或无意的修改与泄露。通信可在可信信道或可信路径的任一端被初始化。表3.12给出了FTP类族及其安全组件列表。 表3.12FTP功能类： 可信路径/信道 族标识族名称功 能 描 述包 含 组 件组 件 名 称 FTP_ITCTSF间可信信道在TSF和其他可信IT产品之间提供一个可信信道FTP_ITC.1TSF间可信信道 FTP_TRP可信路径在TSF和用户之间提供一条可信路径FTP_TRP.1可信路径 3.2安全保障组件 由第2章的讨论可知，CC评估模型包括两个基本原则： 一是要求PP/ST中TOE安全威胁和组织安全策略应描述清楚，并且基于CC所提出的安全功能要求和安全保障要求(安全控制措施)来论证足以达到所期望的安全目的； 二是通过使用CEM对IT产品进行安全评估(主动调查)来提供安全保障，以增强用户信任被评估过的IT产品是满足他们的安全需求的。 TOE安全保障一般通过采用软件工程、开发环境控制、交付运行控制、各种安全测试等安全保障措施使得TOE消费者、开发者和评估者对TOE的安全功能正确有效地实施产生信心。CC第3部分对这些安全控制措施相关的保障要求进行了规范化定义，给出了定义IT产品标准化安全保障要求的组件目录。 TOE安全保障要求划分是以保障类为依据的，每个保障类又细分为多个保障族，每个保障族都有相关的安全目的。保障族又由一个或多个保障组件组成。每个保障组件也有为完成保障族中安全目的而分隔出来的子安全目的，通过保障组件安全目的实现而支持此保障族所有的安全目的。保障组件是由一组保障元素组成，每个保障元素分别从TOE开发者、评估者和评估内容与证据的角度对保障组件所包含的内容和评估依据进行阐述。 CC第3部分包括以下几部分。 (1) 评估保障级(EAL)——为度量TOE的安全保障能力定义的一种尺度。 (2) 组合保障包(CAP)——为度量组合TOE的安全保障能力提供的一种尺度。 (3) 评估保障级和组合保障包的保障组件集合——为不同评估保障级和组合保障包尺度预定义的一组安全保障组件集合。 (4) PP/ST/TOE/ACO评估方法——评估PP、ST、TOE和组合保障包(ACO)以及TOE开发者和评估者活动及其工作单元。 通过第三方机构对TOE进行测试和评估是一种经典的提供IT产品安全保障的有效手段，并且也是CC提出前各个国家、区域等IT产品安全评估准则文档的基础。为了与这些业界公认的IT产品安全保障方法保持一致，CC采用了相同的理念，建议由专业的评估机构以递增TOE评估范围、评估深度和评估过程的严格程度这种方式来度量PP、ST、组合保障包(ACO)和对应IT产品安全功能实现(TOE)的有效性和可信度。CC测试实验室采用的TOE安全评估技术包括但不限于以下这些。 (1) 分析并检查TOE开发者定义的开发过程和程序。 (2) 检查TOE开发过程和程序是否正在被使用。 (3) 分析TOE各设计表示之间的一致性。 (4) 对照TOE安全架构，分析TOE的设计表示。 (5) 验证TOE开发者提供的各种评估证据。 (6) 分析TOE的各种指导性文档。 (7) 分析TOE开发者的功能测试和所提供的测试数据。 (8) 评估者独立地对TOE功能进行测试和分析。 (9) 评估者对TOE进行脆弱性分析。 (10) 评估者对TOE进行穿透性测试等。 CC不排斥也不评论其他获得TOE安全保障方法的相关优点。安全保障可从诸如未经证实的声明、评估者先前相关经验或者特定经验等相关文档中导出。然而，CEM建议通过主动调查来提供安全保障。主动调查就是以确定TOE安全功能(即ST)为目的，对IT产品按照通用评估准则的方法进行安全评估。 CC基本原则确信，更高的安全保障级别源于TOE开发者和评估者更多的开发和评估努力，其目的是运用最小的花销来获得必要的安全保障级。努力程度的增长基于以下几点。 (1) 评估范围——努力越多表明该IT产品被纳入了评估范围的部分越多。 (2) 评估深度——努力越多表明对该IT产品的设计和实现细节评估得越细。 (3) 严格程度——努力越多表明对该IT产品的评估采用了越具结构性和形式化的方法。 3.2.1保障组件结构 与CC第2部分结构一样，CC第3部分将安全保障要求中最抽象的集合称作类。每一类包含多个保障族，每一族又包含多个保障组件，每一组件同样又包含多个保障元素。CC第3部分按照安全保障类、族、组件和元素的层次结构来组织安全保障组件(如图3.6所示)。 图3.6保障类、族、组件、元素的层次结构 安全保障类和族用于对保障要求进行分类，而组件用来详细定义PP/ST中的安全保障要求，例如对TOE开发过程的严格程度约束以及要求查找并分析潜在安全脆弱性的影响。每个保障要求组件包含开发者行为、产生的证据以及评估者行为3方面的元素。 每个保障类都被指定了一个长名和一个以“A”开头的助记的3个字母的短名。每个保障类有一段介绍，描述保障类的组成，并且包含涉及该类意图的支持性文字。CC第3部分定义了3个类型的安全保障类： 用于PP/ST验证的； 用于TOE安全评估的和用于组合TOE安全评估的。 CC第3部分共列出了PP/ST评估这2个保障类和TOE以及组合TOE的6个评估保障类、38个族和89个安全保障组件。PP评估(APE)和ST评估(ASE)这两个类是分别来评估PP和ST的，其他6个评估保障类是验证一个TOE或组合TOE是否符合其PP/ST。表3.13按照字母序列出了CC第3部分所有8个安全保障类并给出了它们的安全目的。 表3.13安全保障类 短名长名应 用 类 型安 全 目 的 ACO组合TOE提供确信一个组合TOE依靠过去评估过的软件、固件或硬件等组成部分所提供的安全功能是能够安全运行的信心 APEPP评估PP/ST证实PP是完整的、内部一致的和技术合理的 ASEST评估PP/ST证实ST是完整的、内部一致的和技术合理的，且适合作为TOE评估的基础 ADV开发TOE提供TOE在不同级别和不同抽象形式上组织和表示TOE安全功能的相关信息。从这些信息中所获得的知识可作为执行TOE脆弱性分析和测试的基础 AGD指导性文档TOE确保TOE使用和所有安全操作都在用户和管理指南指导性文档中描述 ALC生命周期支持TOE确保TOE在开发和维护期间，建立规则和对TOE的细化过程进行控制，以确保TOE的完整性 ATE测试TOE确保有足够的测试覆盖率、测试深度，以及独立的功能测试 AVA脆弱性评定TOE处理在TOE开发或者运行过程中引入可被利用脆弱性的可能性 CC第3部分保障类之间是并列关系，它们之间没有层次关系。和功能类一样，保障类也是CC用户开始依照TOE安全目的选择安全保障要求的最高层次实体，类下面是保障族。保障族表示方法与前面介绍的安全功能族一样，短名是所在保障类名的缩写后紧跟着一个下画线，然后再加上与保障族名有关的3个字母，长名提供了与保障族所涵盖主题相关的描述性信息。每个保障族归属于一个保障类，这个保障类包括具有相同意图的多个保障族。每个保障族被分配了一个唯一的族名，这是引用该保障族的主要方式。 保障族的安全目的内容描述了该保障族在TOE中能满足的安全目的。保障族的这部分安全目的描述是通用性概述，TOE安全目的的细节都包含在特定的保障组件安全目的描述中。 保障组件是由若干元素组成的特殊安全要求集合。图3.7展示了保障组件的结构。组件标识提供了识别、分类、注册和引用某一组件所必要的描述信息。每个保障组件被分配了一个唯一的组件名。该组件名提供关于该保障组件所涵盖主题的描述性信息。每个保障组件均被放置在与其具有相同安全目的的保障族之内。CC也提供了保障组件名字的一个唯一缩写形式，这是引用保障组件的主要手段，其形式是保障族名缩写，后面加一个点，然后是一个数字。这个数字是根据保障组件在族内的顺序从1开始编号的。组件之间的层次关系通过这些序号被指定。此外，应用注释可能包含表达保障组件附加的背景信息和详情。 元素是保障组件中一个独立的安全要求，它是可被评估的最底层安全要求。如果再进一步细分的话，将不会产生有意义的评估结果。每个组件被逐个地声明了一个或多个元素。如果一个组件具有多个元素，那么每个组件的所有这些元素都必须在PP/ST中被全部使用。保障组件中保障元素分为以下3组。 (1) 开发者行为元素： 由TOE开发者实施的行为。这组行为靠随后的一组元素中所引用的证据材料来进一步限制。开发者行为要求用元素号后附加一个字母D来标识。 (2) 证据的内容和形式元素： 安全评估所需证据，包括应证实的内容和证据应表达哪些信息。证据的内容和形式要求用元素号后附加字母C来标识。 (3) 评估者行为元素： 由评估者实施的行为。这组行为明确包含确认在“证据的内容和形式”元素中规定的要求是否都已满足，也包含TOE开发者除已完成的动作之外还需实施的行为和分析要求。隐藏的TOE评估者行为作为IT产品开发者行为元素的结果，虽然没有被“证据的内容和形式”元素覆盖，也应当在TOE评估中被执行。评估者行为要求用元素号后附加字母E来标识。 “开发者行为”和“证据的内容和形式”元素定义的一组保障要求是用来表示TOE开发者的职责，以便于论证TOE满足PP/ST中安全功能要求的保障级别。 “评估者行为”从评估的两个方面定义评估者的职责。一方面是依据APE类和ASE类对PP/ST进行验证； 另一方面是验证TOE样品与其ST中描述的功能要求和保障要求的符合性。通过证实PP/ST文档是有效的，并且TOE样品满足ST中的这些要求，TOE用户可以确信TOE在未来运行环境中能够解决PP/ST已定义的安全问题。 开发者行为元素、证据的内容和形式元素以及显式的评估者行为元素，确定了在验证TOE的ST所作安全声明时TOE评估者在IT产品评估工作中应花费的精力。 图3.8描述了保障类、族、组件和元素的标准记法。 图3.7保障组件结构 图3.8保障类、族、组件和元素的标准记法 3.2.2PP评估保障组件 PP评估(APE)要求证实PP是技术合理和内部一致的，并且，如果PP是基于一个或多个PP或者包，那么PP必须是这些PP或包的一个正确的实例化。PP适于作为编写ST或其他PP的基础，上述这些评估要求是必需的。如果评估成功，PP是被认证的并且会注册到国际评估机构管理的PP注册列表中。CC第3部分给出的PP评估保障组件是为PP文档的相关章节内容评估而建立的(如表3.14所示)。 表3.14APE保障类： PP评估 族标识族名称功 能 描 述包 含 组 件组 件 名 称 APE_INTPP引言证实PP已被正确标识，并且PP参考和TOE概述是相互一致的APE_INT.1PP引言 APE_CCL符合性声明证实声明ST和其他PP是与本PP符合的APE_CCL.1符合性声明 APE_SPD安全问题定义证实TOE及其运行环境所负责处理的安全问题已明确定义APE_SPD.1安全问题定义 APE_OBJ安全目的证实安全目的充分而且完备地处理了安全问题，并证实TOE及其运行环境的安全问题已准确地区分和定义 APE_OBJ.1运行环境安全目的 APE_OBJ.2安全目的 APE_ECD扩展组件定义确定TOE的扩展组件定义是准确的、没有歧义的并且是必要的APE_ECD.1扩展组件定义 APE_REQ安全要求确保对TOE获得保障而采取的预期活动进行了清晰、无歧义且规范的描述 APE_REQ.1陈述的安全要求 APE_REQ.2推导出的安全要求 (1) APE_INT： PP标识信息是否是对PP的准确反映？TOE描述是否是连贯的、内部一致的以及与PP提示是否一致？ (2) APE_CCL： 是否指出本PP对应的CC版本？是否给出了ST和其他PP与本PP符合的声明？ (3) APE_SPD： TOE安全问题定义在被操作的安全环境下是否被合理理解？ (4) APE_OBJ： TOE的安全目的和运行环境安全目的是否能充分对抗已识别威胁、覆盖组织安全策略和安全假设？ (5) APE_ECD： 为PP描述的TOE特定安全要求定义的扩展组件是否准确、没有歧义并且是必要的？ (6) APE_REQ： TOE安全要求是否内部一致？它们是否会导致TOE开发符合声明的安全目的？安全要求是否是显式声明的、清楚的和无歧义的？ 3.2.3ST评估保障组件 ST评估(ASE)要求证实ST是合理和内在一致的，如果ST是基于一个或多个PP或者包，那么ST必须是PP或包的一个正确的实例化。ST作为TOE评估的基础，上述这些属性是必需的。一个ST可在TOE实现之前或与TOE开发并行地被交付评估。但是，如果ST的正式评估先于TOE开发，这将在成本和进度角度更有意义； 例如，错误和ST的理解误区会先于TOE开发而被纠正。CC第3部分给出的ST评估保障组件是为ST文档的相关章节内容建立的(如表3.15所示)。 表3.15ASE保障类： ST评估 族标识族名称功 能 描 述包 含 组 件组 件 名 称 ASE_INTST引言证实ST和TOE被正确标识，TOE的三层抽象方式描述正确，并且这三方面的描述相互一致ASE_INT.1ST引言 ASE_CCL符合性声明证实声明ST和PP是符合的ASE_CCL.1符合性声明 ASE_SPD安全问题定义证实TOE及其运行环境所负责处理的安全问题已准确地定义ASE_SPD.1安全问题定义 ASE_OBJ安全目的证实安全目的充分而且完备地处理了定义的安全问题，并证实TOE及其运行环境的安全问题已准确地区分和定义 ASE_OBJ.1运行环境安全目的 ASE_OBJ.2安全目的 ASE_ECD扩展组件定义证实TOE扩展组件定义是准确的、没有歧义的并且是必要的ASE_ECD.1扩展组件定义 ASE_REQ安全要求证实TOE安全要求是清晰的、无歧义的并且是准确定义的 ASE_REQ.1陈述的安全要求 ASE_REQ.2推导出的安全要求 ASE_TSSTOE概要规范证实TOE概要规范和ST中TOE的其他叙述性描述是一致的 ASE_TSS.1TOE概要规范 ASE_TSS.2具有结构设计概述的TOE概要规范 (1) ASE_INT： 标识信息是否是ST的精确反映？TOE描述是否是连贯的、内部一致的以及与ST提示一致？ (2) ASE_CCL： 是否指出本ST对应的CC版本？ST是否是指定PP 的一个正确实例化？是否给出了TOE是与本ST符合的声明？ (3) ASE_SPD： TOE安全问题定义在被操作在的安全环境下是否被理解？ (4) ASE_OBJ： TOE及运行环境的安全目的是否充分对抗已识别威胁、覆盖组织安全策略和安全假设？ (5) ASE_ECD： 为ST描述的TOE特定安全要求定义的扩展组件是否准确、没有歧义并且是必要的？ (6) ASE_REQ： 安全要求是否内部一致？它们会导致TOE开发满足已声明的安全目的吗？这些安全要求是否是显式声明的、清晰的和无歧义的？ (7) ASE_TSS： 是否所有的SFR都被TOE安全功能满足？是否所有的SAR都被TOE安全保障措施满足？ 3.2.4TOE评估保障组件 CC第3部分将TOE评估保障组件分为5类，分别是开发类(ADV)、指导性文档类(AGD)、生命周期支持类(ALC)、测试类(ATE)和脆弱性评定类(AVA)。 1. 开发类保障组件 开发类保障组件提供了TOE开发过程安全保障相关的要求信息。正如后面的TOE脆弱性评定(AVA)和TOE测试(ATE)类所描述的那样，从开发类中所获得的TOE开发知识可作为执行TOE脆弱性评定和TOE测试的基础。CC为开发类定义了6个保障族，这些族在不同安全保障级别和不同抽象层次上组织和表示TOE安全功能保障要求。这6个开发族分为以下4类安全要求。 (1) 安全功能要求设计和实现在不同抽象层次下的描述要求(ADV_FSP、ADV_TDS、ADV_IMP)。 (2) 域分离、TSF自保护和安全功能的不可旁路性等面向安全架构特征的描述要求(ADV_ARC)。 (3) 安全策略模型以及安全策略模型和TOE功能规范之间的对应性映射要求(ADV_SPM)。 (4) TSF内部结构的要求，包括诸如模块化、层次化以及复杂度最小化等要求方面(ADV_INT)。 表3.16列出了ADV类涉及的保障族及其保障组件。CC第3部分规定TOE开发者可用3种类型方式来描述他们的TOE开发文档： 非形式化、半形式化和形式化。TOE功能规范和TOE设计文档一般以非形式化或者半形式化方式进行描述。半形式化方式描述的文档与非形式化文档相比能降低文档的歧义性。除半形式化的描述之外，高保障级别的TOE开发类文档一般需要使用形式化方式对其进行描述。当然TOE开发者也可综合使用上述3种方式对TOE安全功能进行描述，以完全准确地描述TSF开发的安全保障要求。 表3.16ADV保障类： 开发 族标识族名称功 能 描 述包 含 组 件组 件 名 称 ADV_ARC安全架构提供对TSF安全架构的描述,并且提供这些描述TSF特性的证据ADV_ARC.1安全架构描述 ADV_FSP功能规范功能规范是用户可见接口和TSF行为的一个高层描述。它描述TSF，并且一定是TOE安全功能要求的一个完备和正确的实例化。功能规范也详细描述TOE的外部接口(TSFI)。TSFI包括所有的通过外部实体(或者位于TSF之外TOE内部的主体)向TSF提供数据、接收来自TSF的数据并且调用TSF的服务的方法 ADV_FSP.1基本功能规范 ADV_FSP.2安全执行功能规范 ADV_FSP.3带完整摘要的功能规范 ADV_FSP.4完备的功能规范 ADV_FSP.5附加错误信息的完备的半形式化功能规范 ADV_FSP.6附加形式化描述的完备的半形式化功能规范 ADV_IMP实现表示TSF的最低抽象表示，它根据可用的源代码、硬件图纸等，论述TSF详细的内部工作方式 ADV_IMP.1TSF实现表示 ADV_IMP.2TSF实现表示完全映射 ADV_INTTSF内部 负责处理TSF的内部结构，提出了有关模块化、层次化(抽象性分层和最少循环依赖)、策略实施机制的复杂性最小化、TSF中非TSP实施功能性的数目最小化等方面的要求 ADV_INT.1结构合理的TSF内部子集 ADV_INT.2内部结构合理 ADV_INT.3内部复杂度最小化 续表 族标识族名称功 能 描 述包 含 组 件组 件 名 称 ADV_SPM安全策略模型建立一个形式化的TSF安全策略模型，以及功能规范与安全策略模型之间的对应关系来提供额外的保障ADV_SPM.1形式化TOE安全策略模型 ADV_TDSTOE设计提供与TSF描述的上下文，以及对TSF的详尽描述,以便确定是否实现了安全功能要求。设计文档的目的是为确定TSF边界以及描述TSF如何实现安全功能要求提供充足的信息 ADV_TDS.1基础设计 ADV_TDS.2结构化设计 ADV_TDS.3基础模块设计 ADV_TDS.4半形式化模块设计 ADV_TDS.5完全半形式化模块设计 ADV_TDS.6带形式化高层设计表示的完全半形式化模块设计 2. 指导性文档类 指导性文档(AGD)类为TOE所有用户角色规范的指南文档要求(见表3.17)。为了安全地准备(安装配置)和操作(运营管控)被评估的IT产品，TOE开发者有必要描述TOE操作安全相关的所有操作指南内容。这个类同时也描述了TOE用户无意错误配置和错误操作TOE等安全问题的解决方案等内容。指导性文档类细分为两个族，分别是关于准备程序用户指南(使交付的TOE达到与ST中描述的一致的运行环境评估配置状态)和操作用户指南(在TOE处于评估配置状态下的操作)。 表3.17AGD保障类： 指导性文档 族标识族名称功 能 描 述包 含 组 件组 件 名 称 AGD_OPE操作用户指南描述TSF所提供的安全功能，提供说明和指南(包括警告)，以帮助理解TSF及其安全使用所必需的关键信息和动作AGD_OPE.1操作用户指南 AGD_PRE准备程序用于保证TOE以开发者预期的安全方式被接收和安装AGD_PRE.1准备程序 3. 生命周期支持类 生命周期支持类是由TOE开发者负责或者用户负责来区分IT产品生命周期阶段，而不是按照TOE所处的开发环境或用户环境区分的。将TOE移交给用户的时间点，也就是从ALC（“生命周期支持”类）到AGD（“指导性文档”类）的时间点。ALC 类由7个族组成(如表3.18所示)。 生命周期定义（ALC_LCD）族是TOE生命周期的高级描述， CM能力（ALC_CMC）族要求对TOE配置项的管理进行详细描述， CM范围(ALC_CMS)族要求以定义的方式管理一个最小的配置项集合。 开发安全(ALC_DVS)族与TOE开发者物理的、程序的、人员的以及其他的安全控制措施有关， 工具和技术(ALC_TAT)族关于TOE开发者使用的开发工具和实现技术与机制， 缺陷纠正(ALC_FLR)族负责TOE安全缺陷的处理。交付(ALC_DEL)族定义将TOE从TOE开发环境移交给TOE消费者使用环境的过程程序。注意在TOE开发过程中产生的交付过程不是由ALC_DEL处理，应该由本类其他族中定义的模块集成和接受程序来处理。 表3.18ALC保障类： 生命周期支持 族标识族名称功 能 描 述包 含 组 件组 件 名 称 ALC_CMCCM能力要求在TOE和相关信息的细化和修改过程中遵守一定的规章制度和采取一定的控制措施 ALC_CMC.1TOE标识 ALC_CMC.2CM系统的使用 ALC_CMC.3授权控制 ALC_CMC.4生产支持和接受程序及其自动化 ALC_CMC.5高级支持 ALC_CMSCM范围标识出纳入配置管理系统的配置项，并满足ALC_CMC“CM能力”族提出的CM要求 ALC_CMS.1TOE CM覆盖 ALC_CMS.2部分TOE CM覆盖 ALC_CMS.3实现表示CM覆盖 ALC_CMS.4问题跟踪CM覆盖 ALC_CMS.5开发工具CM覆盖 ALC_DEL交付阻止和检测在TOE交付过程中不恰当地对TOE进行修改ALC_DEL.1交付程序 ALC_DVS开发安全减少开发过程中潜在的物理、程序、人员以及其他对TOE的安全威胁 ALC_DVS.1安全控制措施标识 ALC_DVS.2充分的安全控制措施 ALC_FLR缺陷纠正确保开发者跟踪并纠正已发现的安全缺陷 ALC_FLR.1基本的缺陷纠正 ALC_FLR.2缺陷报告程序 ALC_FLR.3系统的缺陷纠正 ALC_LCD生命周期定义评估开发使用的生命周期模型的适当性、标准化和可测性 ALC_LCD.1开发者定义的生命周期模型 ALC_LCD.2可测量的生命周期模型 ALC_TAT工具和技术评价用于开发、分析和实现TOE安全功能工具和技术的适当性 ALC_TAT.1明确定义的开发工具 ALC_TAT.2遵从实现标准 ALC_TAT.3遵从实现标准（所有部分） 生命周期支持类是评估TOE开发者用来预防和探测被意外的或蓄意的安全漏洞利用的IT产品生命周期过程的有效性。 以下4个关键领域应被检查与检验。 (1) 生命周期过程是否降低了开发环境中的物理的、过程的和人员安全威胁的风险？ (2) TOE漏洞修复过程是否有效？ (3) 生命周期模型是否是良好定义的、适当的以及可度量的？生命周期模型是否在TOE开发过程中确实被遵循？ (4) 用于开发、分析和实现TOE安全功能的工具和技术是否恰当？ 4. 测试类 测试类包括4个“测试”相关的保障族(如表3.19所示)： 覆盖(ATE_COV)、深度(ATE_DPT)、独立测试(例如由评估者执行的功能测试)(ATE_IND)和功能测试(ATE_FUN)。对TOE进行各种测试能为TSF是否符合前面开发类所述功能规范、TOE设计及实现描述等提供保障。评估TOE测试覆盖率的充分性(如测试计划、测试过程和测试分析报告记录)是为了确定TOE安全功能是否已经被TOE开发者充分测试过，这是通过检查TOE开发者的相关测试证据来实现的。由TOE开发者执行的测试深度分析用于检验开发者做的测试所能达到的详细程度，目的是降低在TOE开发中存在某些错误的风险。由开发者执行的功能测试范围被分析以确认其充分性。另外，评估者可能要自主执行独立的功能测试。ATE将测试分为开发者测试和评估者测试。覆盖分析(ATE_COV)和深度测试(ATE_DPT)族涉及TOE开发者的所有测试数据及其相关的证据材料，前者说明功能规范已被严格测试，后者说明针对其他设计描述(安全结构、TOE设计、实现说明)的测试是否被满足。 表3.19ATE保障类： 测试 族标识族名称功 能 描 述包 含 组 件组 件 名 称 ATE_COV覆盖通过检查开发者的对应性证据确定测试覆盖充分性 ATE_COV.1覆盖证据 ATE_COV.2覆盖分析 ATE_COV.3严格覆盖分析 ATE_DPT深度通过检查开发者的对应性证据确定测试深度覆盖充分性 ATE_DPT.1测试： 基本设计 ATE_DPT.2测试： 安全执行模块 ATE_DPT.3测试： 模块设计 ATE_DPT.4测试： 实现表示 ATE_FUN功能测试确定由开发人员实施的功能测试的充分性 ATE_FUN.1功能测试 ATE_FUN.2顺序的功能测试 ATE_IND独立测试确定由评估人员实施的功能测试的充分性 ATE_IND.1独立测试（符合性） ATE_IND.2独立测试（抽样） ATE_IND.3独立测试（完全） 注意，本类不涉及评估TOE安全性的穿透性测试，穿透性测试是基于对TSF的分析专门查找并标识TSF设计与实现过程中的脆弱性，在AVA“脆弱性评定”类中将作为脆弱性评估的一个方面单独处理。 5. 脆弱性评定类 脆弱性评定类负责评估在TOE开发或者运行过程中引入可被利用的脆弱性的可能性(脆弱性利用)。通常，脆弱性评定活动涉及TOE开发和运行中的各种潜在的安全攻击。脆弱性利用的是在开发过程中引入的TOE的一些属性，例如通过篡改、直接攻击或绕过TSF等攻破TSF自我保护，或者通过绕过、直接攻击TSF等攻破TSF域分隔，或者通过绕过(旁路)TSF攻破不可旁路性。通过非技术措施中的脆弱性的利用去破坏TOE安全功能要求，例如误用或错误配置。“误用”考察的是在TOE的管理员或用户被认为是安全时，TOE是否会以一种不安全的方式被配置或使用。脆弱性评估是由表3.20中的脆弱性评定保障族AVA_VAN相关的保障组件来处理的。 表3.20AVA保障类： 脆弱性评定 族标识族名称功 能 描 述包 含 组 件组 件 名 称 AVA_VAN脆弱性分析确定在评估TOE开发和预期运行期间潜在的脆弱性是否已被标识 AVA_VAN.1脆弱性调查 AVA_VAN.2脆弱性分析 AVA_VAN.3关注点脆弱性分析 AVA_VAN.4系统的脆弱性分析 AVA_VAN.5高级的系统的脆弱性分析 3.2.5ACO评估保障组件 组合TOE的一个依赖部件可用一个先前已评估或认证过的基本部件来满足环境中的IT产品安全要求，但这种方式不提供任何关于部件之间的交互或组合是否会引入脆弱性的保障。组合TOE评估保障组件(ACO)在更高的保障级别中考虑了这些交互，将部件之间的接口纳入了测试范围。同时，通过对组合TOE进行脆弱性分析来考虑部件组合引入脆弱性的问题。 ACO类的“组合”为TOE集成者提供了一种可选的方法被用于CC中由两个或更多的成功评估过的TOE合成的组合TOE评估过程中获得信心，而不需要重新评估合成的TSF。(在整个ACO类中用组合TOE集成者指代“开发者”，任何与基本或依赖部件相关的开发者都这样阐述。) ACO“组合”类包括表3.21所示的5个族。它们是为了提供确信一个组合TOE依靠过去评估过的软件、固件或硬件等组成部分所提供的安全功能是能够安全运行的信心。 表3.21ACO保障类： 组合 族标识族名称功 能 描 述包 含 组 件组 件 名 称 ACO_COR组合基本原理证实基本部件能为组合产品提供有效合适的保障级ACO_COR.1组合基本原理 ACO_DEV开发证据确认提供安全功能支持依赖部件是合适的，且是相关要求所必需的(依赖信息中表示的) ACO_DEV.1功能描述 ACO_DEV.2基本的设计证据 ACO_DEV.3详细的设计证据 ACO_REL依赖部件的依赖性提供描述依赖基本部件的依赖性证据 ACO_REL.1基本的依赖信息 ACO_REL.2依赖信息 ACO_CTT组合TOE测试要求执行组合TOE测试以及组合TOE中用到的基本部件测试 ACO_CTT.1接口测试 ACO_CTT.2严格的接口测试 ACO_VUL组合脆弱性分析开发者应提供部件评估期间报告的任何残余脆弱性的详细资料 ACO_VUL.1组合脆弱性审查 ACO_VUL.2组合脆弱性分析 ACO_VUL.3增强的基本组合脆弱性分析 3.2.6PP配置评估保障组件 为了适应当前日益复杂的IT产品设计趋势，当前版本的CC/CEM标准修订过程加入了对模块化(Modularization)产品安全功能描述和评估技术的支持： 在2017年发行的CC v3.1 r5版本中扩展了评估模型，提出了PP模块(PP Module)、基本PP(Base PP)和PP配置(PP Configuration)等概念，并增加了相应的安全保障要求和评估方法，特别是增加了面向PP配置评估的安全保障类(ACE)，用来评估由一个或多个基本PP或PP模块组成的可配置的PP。这种支持有利于增强CC评估过程中的复用程度，节省评估开销(注： 读者可参见本书4.9节了解更多内容)。 ACE要求证实PP配置是技术合理和内部一致的。这些特性是未来保证PP配置可用于ST和其他PP或PP配置的编制依据。ACE类评估要求必须结合新版CC第1部分附录定义的PP配置概念及其样例使用。表3.22给出了PP配置保障族及其保障组件，这些族在不同级别和不同抽象形式上组织和表示PP配置评估要求(注： 目前颁布的GB/T 18336标准由于是针对CC v3.1 r3进行的转标处理，其中并没有给出新版CC中PP配置相关的概念)。 表3.22ACE保障类： PP配置评估 族标识族名称功 能 描 述包 含 组 件组 件 名 称 ACE_INTPP配置引言证实PP模块(PP Module)已被正确标识，并且PP模块和TOE概述是相互一致的ACE_INT.1PP配置引言 ACE_CCL符合性声明证实符合性声明有效性。不同于一般PP，PP模块不能说明符合其他PP或PP模块，也不能包括CC第3部分或保障组件包的符合性ACE_CCL.1符合性声明 ACE_SPD安全问题定义和APE_SPD一样，证实TOE及其运行环境所负责处理的安全问题被明确定义ACE_SPD.1安全问题定义 ACE_OBJ安全目的和APE_SPD一样，证实安全目的充分而且完备地处理了安全问题，并证实TOE及其运行环境的安全问题被准确地区分和定义ACE_OBJ.1安全目的 ACE_ECD扩展组件定义确定面向PP模块的扩展组件是准确的、没有歧义的并且是必要的ACE_ECD.1扩展组件定义 ACE_REQ安全要求确保对TOE获得保障而采取的预期活动进行了清晰、无歧义且规范的描述ACE_REQ.1 安全要求 3.2.7预定义评估保障级别 CC第3部分预定义了7个评估保障级(EAL)。每个EAL相应的结构如图3.9所示，其中“目的”项表示的是评估保障级的安全意图，“应用注释”项包含评估保障级的使用者(如PP/ST作者，以该评估保障级为目标的TOE设计者、评估者)特别感兴趣的信息，“保障组件”给出了该保障级别包含的保障组件信息。 图3.9评估保障级结构 PP/ST作者可以用以下方法，得到一个比CC预定义EAL更高级别的评估保障级别。 (1) 包含来自其他保障族的额外的保障组件。 (2) 从相同的保障族中用更高级别的保障组件替换保障组件。 图3.10说明了CC定义的保障要求和保障级之间的关系。当保障组件进一步分解为保障元素时，保障元素不能被保障级单独引用。需要注意的是，图中的箭头表示评估保障级(EAL)与保障类中组件的引用关系。 在CC第3部分中对TOE的安全保障预定义了如表3.23所示的7个级别。它们按保障能力进行排序，每个评估保障级比其较低的评估保障级表达了更多的安全保障要求，即高级别的EAL靠替换低级别EAL同一保障族中的一个更高级别的保障组件 (即增加严格性、范围和(或)深度)和添加另外一个保障族的保障组件(即添加新的要求) 来实现。 表3.23CC预定义EAL保障级别描述 预定义EAL保障要求描述 EAL 1 功能测试 EAL 1级依据一个规范的独立性测试和对所提供的指导性文档的检查来为用户评估TOE。在这个级上，没有TOE开发者的帮助也能成功地进行评估，并且所需费用也最少。通过该级的一个评估，可以确信TOE的功能与其文档在形式上是一致的，并且对己标识的威胁提供了有效的保护 EAL2 结构测试 EAL 2级要求评价时在设计信息和测试结果的提供方面得到TOE开发人员的配合，要求TOE开发者递交设计信息和测试结果。 EAL 2适用于在缺乏现成可用的完整的开发记录时，TOE开发者或用户需要一种低到中等级别的独立安全保障的安全性 EAL 3 系统测试EAL 3级要求在设计阶段实施积极的安全工程思想，提供中级的独立安全保障，EAL 3可使TOE开发者在设计阶段能从正确的安全工程中获得最大限度的安全保障。EAL 3适用于TOE开发者或用户需要一个中等级别的独立安全保障的安全性，并在不带来大量的再构建费用的情况下，对TOE及其开发过程进行彻底审查。开展该级的评估，需要分析基于“灰盒子”的测试结果、TOE开发者测试结果的选择性独立确认、TOE开发者搜索已知脆弱性的证据等。还要求使用开发环境控制措施、TOE的配置管理和安全交付程序 EAL 4 系统设计、测试和复查EAL 4级要求按照良好的商业化开发惯例实施积极的安全工程思想，提供中高级的独立安全保障。EAL 4级的评估，需要分析TOE模块的安全架构、底层设计和实现的子集。在测试方面将侧重于对已知的脆弱性进行独立搜索。开发控制方面涉及生命周期模型、开发工具标识与自动化配置管理等方面 续表 预定义EAL保障要求描述 EAL 5 半形式化设计和测试EAL 5级要求按照严格的商业化开发惯例，应用专业安全工程技术实施安全工程思想，提供高等级的独立安全保障。如果某个TOE要想达到EAL5要求，TOE开发者需要在设计和开发方面下一定工夫，应具备相关的一些专业技术。开展该级的评估，需要分析所有的实现。还需要额外分析功能规范和高层设计的形式化模型和半形式化表示，以及它们之间对应性的半形式化论证。对已知脆弱性的搜索方面，必须确保TOE可抵御中等攻击潜力的穿透性攻击者。还要求采取隐蔽信道分析和模块化的TOE设计 EAL 6 半形式化验证的设计和测试EAL 6级通过在严格的开发环境中应用安全工程技术来获取高 等级的安全保障，使产品能在高度危险的环境中使用。开展该级的评估，需要分析设计的模块和层次化方法以及实现的结构化表示。在对已知脆弱性的独立搜索方面，必须确保TOE可抵御高等攻击潜力的穿透性攻击者。对隐蔽信道的搜索必须是系统性的，且开发环境和配置管理的控制也应进一步增强 EAL 7 形式化验证的设计和测试EAL 7级的目标是使产品能在极端危险的环境中使用，目前，该级别的实际应用只限于其安全功能可以进行广泛的形式化分析的安全产品。开展该级的评估，需要分析TOE的形式化模型，包括功能规范和高层设计的形式化表示。要求TOE开发者提供基于“白盒”测试的证据，在评估时必须对这些测试结果全部进行独立确认，并且设计复杂程度必须是最小的 图3.10保障要求和保障级别之间的保障组件对应关系 虽然在CC中已经预定义这些评估保障级所包括的组件（表3.24所示），但PP/ST编制者还是可以依据用其他保障组件的组合来表示某类特殊的安全保障要求。特别是“增强”这个概念允许(从没有包括在评估保障级中的保障族)向评估保障级中增加保障组件，或允许替换评估保障级中的(用同一个保障族的其他更高级别的保障组件)组件。在CC中定义的保障结构中，只有评估保障级可以增强。“评估保障级减去一个组成保障组件”这样的想法在CC应用中不被认为是一个有效的主张。要求“增强”者有义务证明对评估保障级添加保障组件的实际意义和潜在的价值。一个评估保障级也可以用扩展的保障要求来增强。 表3.24评估保障级组件列表 保障类保障族 评估保障级依据的保障组件 EAL 1EAL 2EAL 3EAL 4EAL 5EAL 6EAL 7 开发 ADV_ARC安全架构 111111 ADV_FSP功能规范1234556 ADV_IMP实现表示 1122 ADV_INTTSF内部 233 ADV_SPM安全策略模型 11 ADV_TDSTOE设计 123456 指南类 文档 AGD_OPE操作用户指南1111111 AGD_PRE准备程序1111111 生命周期支持 ALC_CMCCM能力1234455 ALC_CMSCM范围1234555 ALC_DEL交付 111111 ALC_DVS开发安全 11122 ALC_FLR缺陷纠正 ALC_LCD生命周期定义 11112 ALC_TAT工具和技术 1233 ST评估 ASE_CCL符合性声明1111111 ASE_ECD扩展组件定义1111111 ASE_INTST引言1111111 ASE_OBJ安全目的1222222 ASE_REQ安全要求1222222 ASE_SPD安全问题定义 111111 ASE_TSSTOE概要规范1111111 测试 ATE_COV覆盖范围 122233 ATE_DPT深度 12334 ATE_FUN功能测试 111122 ATE_IND独立测试 1222223 脆弱性评定AVN_VAN脆弱性分析1223455 3.2.8预定义组合保障包 组合TOE由已经通过评估(或即将通过评估)的TOE部件组成。单个部件将被认证为满足某个EAL或在ST中说明的其他保障包。通过从公开渠道获取部件的信息进行 EAL 1评估，一个组合TOE预计可达到基本的保障级别(部件和组合 TOE的评估都可应用EAL 1)。通过应用高于EAL 1的EAL可以进行组合TOE的更高保障级的评估，而组合保障包(CAP)为此目的提供了另一种解决方法。 CAP在权衡所获得的保障级与达到该组合TOE保障程度所需的代价和可行性上提供了一个递增的尺度。组合保障包是建立在先前已评估的实体(基本部件和依赖部件)之上，因此仅有少部分族和组件被包含在组合保障包中。表3.25概括性地描述了CC第3部分对组合TOE的保障等级定义了3个组合保障包,表格中的每个数字标识出了此处适宜的具体保障组件。每个 CAP最多包含每个保障族中的一个组件，并满足每个组件的所有保障依赖关系。 表3.25组合保障级别组件列表 保障类保障族 组合保障包依赖的保障组件 CAPACAPBCAPC 组合 ACO_COR111 ACO_CTT122 ACO_DEV123 ACO_REL112 ACO_VUL123 指导文档 AGD_OPE111 AGD_PRE111 生命周期支持 ALC_CMC111 ALC_CMS222 ST评估 ASE_CCL111 ASE_ECD111 ASE_INT111 ASE_OBJ122 ASE_REQ122 ASE_SPD 11 ASE_TSS111 组合保障包按级别排序，因为高级别的CAP比所有较低的CAP表达更多的保障。从CAPA到CAPC，保障增加是通过替换成同一保障族中的一个更高级别的保障组件(即增加严格性、范围和/或深度)和添加另外几个保障族的保障组件(即添加新的要求)来实现。这些增加导致更多的综合分析来识别对单个TOE获得的评估结果的影响。 3类组合保障包的目的及其保障内容分别如下。 (1) 结构组合(CAPA)： 适于组合TOE是完整的，且需要对产生组合的正确安全操作具有信心的情况。该组合保障包通过分析组合TOE的ST提供保障。利用TOE组成部件的评估输出(如ST、指导性文档等)和TOE组成部件之间的接口规范对组合TOE的ST中的安全功能要求进行分析，以理解安全行为。例如以下内容可为该分析提供支持： 针对关联信息中描述的依赖部件与基本部件之间的接口进行的独立测试； 开发者基于关联信息、开发信息和组合原理进行测试的证据； 对开发者测试结果的选择性确认； 由评估者进行的组合 TOE 的脆弱性审查等。 (2) 系统组合(CAPB)： 可使组合 TOE 开发者在子系统层面上通过理解各组成部件之间的相互影响，获得最大程度的保障，同时还可使基本部件开发者的参与量最小。CAPB 通过全面分析组合TOE的ST提供保障。利用TOE组成部件的评估输出(如ST、指导性文档等)，TOE组成部件之间的接口规范，以及包含在组合开发过程中的TOE设计信息(描述TSF系统)，对组合TOE的ST中的安全功能要求进行分析，以理解安全行为。以下内容可为该分析提供支持： 对关联信息(包括TOE设计)中描述的依赖部件与基本部件之间的接口进行的独立测试、开发者基于关联信息、开发相关信息和组合原理而进行测试的证据，以及对开发者测试结果的选择性独立确认。对评估者为证实组合TOE可抵御基本攻击潜力攻击者的攻击而进行的脆弱性分析也可提供支持。 （3） 系统组合、测试和复查(CAPC)： 可使开发者从对组合TOE部件之间交互的正确分析获得最大限度的保障，虽然这种实践很严格，但不需要获得所有的对基本部件的评估证据。CAPC通过全面分析组合TOE的ST提供保障。利用TOE组成部件的评估输出(如ST、指导性文档等)，TOE组成部件之间的接口规范，以及包含在组合开发过程中的TOE设计信息(描述TSF模块)对组合TOE的ST中的安全功能要求进行分析，以理解安全行为。以下内容可为该分析提供支持： 对关联信息(包括TOE设计)中描述的依赖部件与基本部件之间的接口进行的独立测试、开发者基于关联信息、开发相关信息和组合原理而进行测试的证据、对开发者测试结果的选择性独立确认来进行。对评估者为证实组合TOE可抵御基本增强理攻击潜力攻击者的攻击而进行的脆弱性分析也可提供支持。 CAPA适用于在缺乏现成可用的完整的开发记录时，开发者或用户需要一种低到中等级别的独立保障的安全性的情况。与CAPA相比，CAPB通过要求更完备的安全功能测试，在保障方面提供了有意义的增强。因此CAPB适用于开发者或用户需要一个中等级别的独立保障的安全性，以及在没有对组合TOE进行实质性改造的情况下，要求对组合TOE及其开发过程进行彻底的调查。 与CAPB相比，CAPC通过要求更完备的设计描述和抵御更高的攻击潜力，在保障方面提供了有意义的增强。因此CAPC 适用于开发者或用户在传统的商品化TOE中需要一个中等到高等级别的独立保障的安全性，并准备负担额外的安全专用工程费用。 自从组合保障包CAP提出以来，国内外鲜见实际使用该概念的评估案例。实际上依据CAP的评估存在一些基本问题，这妨碍了其被实际应用，主要包括以下基本问题。 (1) CAP要求组合部件必须都进行过EAL评估，这不利于一个组合产品的实际评估状况，其中所有的部件或至少部分部件是没有被评估过的。 (2) 采用CAP方法进行评估后得到的CAP级别无法和EAL级别进行比较，因而无法论述一个CAP组合评估产品和一个按EAL进行整体评估的产品的安全保障程度。 (3) 由于前两点，无法对包含3个及以上依赖层次的组合产品进行CAP评估，因为虽然可以对下两层进行CAP评估，但却无法将第三层的EAL评估结果和下两层的CAP评估结果进行组合评估。 为了改善这种状况，正在编修的CC v4.0版本提出了新的组合评估概念，并给出了某些组合模型下的评估方法。在这种评估方法中，一个基础部件需要预先进行EAL评估，其上层依赖部件没有经过EAL评估，通过在现有的评估保障类中增加特定的保障族(主要包括ASE_COMP、ADV_COMP、ALC_COMP、ATE_COMP和AVA_COMP等)，可以最终输出一个体现EAL级别的组合评估结果，因此这个方法将与基本的EAL评估方法一致，并可以支持多于三层的组合产品评估需求。 3.3本 章 小 结 基于CC/CEM的安全评估为客户提供IT产品安全行为和安全保障的评估证据，而不是通过安全理论模型和系统仿真方法为IT产品客户提供安全功能证明。为此，我们需要使用CC定义的安全组件来描述IT产品的安全要求。本章重点是介绍用于规范某个IT产品安全功能要求表达的CC安全功能组件和安全保障组件的内容及其使用方法，即CC第2部分列出的11个类、65族和136个安全功能组件和CC第3部分列出的PP/ST评估这2个保障类和TOE以及组合TOE的6个评估保障类、38个族和89个安全保障组件。 CC第2部分定义的功能类描述了标准用户可能需要的各种潜在安全功能组件。当PP/ST编制者开始选择安全功能要求时，功能类是选择安全功能组件的出发点。CC第2部分的安全功能类彼此之间是并列关系，并没有层次关系。在CC文档中的功能类定义的助记符短名是按照其字母排序的。功能族是用来陈述一组共享安全目的，但是安全关注点或安全精确度上不一样的安全要求。在确定了功能类后，可依据PP/ST定义的安全目的，为TOE选择相应的功能族。组件是一个安全要求的特殊集合，它是由各种元素构成的。CC规定组件中的元素是一个不可分割的安全要求，它应可通过一个安全评估被验证。组件被分配了一个长名并且相关的要求在CC第2部分都被准确地描述了。一个组件和另一个组件之间的层次关系是在功能族中指定的，在此基础上，我们分别介绍了11个安全功能类相关的族及其组件。 CC第3部分给出了描述IT产品安全保障要求的标准化组件。在CC中TOE的安全保障级别划分是以保障类为依据的，而保障类由多个保障族组成，每个保障族都有一个保障安全目的，保障族又由一个或多个保障组件组成，每个保障组件也有一个安全目的，表明该组件的安全意图。保障组件又由一组保障元素组成，保障元素分别从TOE开发者、评估者和评估证据内容和格式的角度对保障组件所包含的内容和评估依据进行阐述。为便于理解，我们按照评估项目目标对象的不同，分别介绍了保护轮廓评估组件、安全目标评估组件、评估对象保障组件和组合评估对象保障组件，并在最后介绍了CC预定义的评估保障级别和组合保障包含义及相应的安全保障组件。 3.4问 题 讨 论 1. 简述安全功能组件结构、功能类和功能族的主要目的。 2. 安全审计类安全功能组件有哪些？简述它们的用途。 3. 通信功能类安全功能组件有哪些？简述它们的用途。 4. 密码支持类安全功能组件有哪些？简述它们的用途。 5. 用户数据保护类安全功能组件有哪些？简述它们的用途。 6. 用户标识和鉴别类安全功能组件有哪些？简述它们的用途。 7. 安全管理类安全功能组件有哪些？简述它们的用途。 8. 隐私要求类安全功能组件有哪些？简述它们的用途。 9. TSF保护类安全功能组件有哪些？简述它们的用途。 10. 资源利用类安全功能组件有哪些？简述它们的用途。 11. TOE访问类安全功能组件有哪些？简述它们的用途。 12. 可信路径/信道类安全功能组件有哪些？简述它们的用途。 13. 以某个操作系统、数据库管理系统或应用系统的访问控制安全功能为例，选择用户数据管理类某个相应的组件，描述该TOE的组件元素操作。 14. 以某个操作系统、数据库管理系统或应用系统为例，定义其需要记录的安全相关事件。 15. 以某个操作系统、数据库管理系统或应用系统为例，从CC用户鉴别组件列表中选择合适的组件，描述该TOE的组件元素操作。 16. 简述TSF间可信信道和可信路径的区别，并通过案例说明。 17. 简述安全保障要求组件结构、功能类和功能族的主要目的。 18. 简述安全保障评估努力有哪些要素。 19. 阐述功能和保障类、族和元素的标准记法。注意相似性和不同，如果存在的话。 20. CC给出预定义评估保障级别的目的是什么？为何要定义组合保障包？ 21. 保障组件元素分3类，简述它们各自的通途。 22. PP保障组件有哪些？简述它们的用途。 23. ST保障组件有哪些？简述它们的用途。 24. 开发类保障组件有哪些？简述它们的用途。 25. 指导文档类保障组件有哪些？简述它们的用途。 26. 生命周期类保障组件有哪些？简述它们的用途。 27. 测试类保障组件有哪些？简述它们的用途。 28. 脆弱性评定类保障组件有哪些？简述它们的用途。 29. 组合TOE保障组件有哪些？简述它们的用途。