第5章安全目标及其编制方法 本章阐述TOE开发者如何使用CC标准化语言来编制ST文档，以论述实现IT产品安全需求的解决方案。本章内容将继续按照ISO/IEC TR 15446：2009技术报告的结构进行编排，并逐节讨论CC第1部分附录A规定的ST文档结构和内容编制方法和技巧，以及如何去阅读和解释其中的各部分内容。 本章包括以下内容。 (1) ST概述： 概述如何通过编制ST来响应用户对IT产品的安全需求，包括安全架构设计的基本概念、PP与ST之间的关系、ST的用途等。 (2) ST结构： 解释ST所提供的安全方案结构及内容，概述ST各部分之间的关系(安全原理编制)。 (3) ST编制： 按照ST结构，分别概述引言、符合性声明、安全问题定义、安全目的、扩展组件定义、安全要求和TOE概要规范的编制方法。 5.1安全目标概述 ST是IT产品开发者提供的一个响应客户安全需求(PP)的、与实现相关的安全方案，是体现某个具体IT产品安全规范的文档。换句话说，PP是从IT产品消费者角度规定某类IT产品的安全功能和安全保障要求，而ST是IT产品提供者从实现的角度明确IT产品安全功能的实现技术与机制。这样TOE开发者就可依据IT产品生命周期的安全保障措施进行详细设计和实现，以便满足IT产品用户通过PP表达的安全需求。正如第4章所讨论的，PP独立于TOE安全功能的具体实现，所以不同的TOE开发者可以编写与他们实现机制相关的，但是具备同等安全功能的ST来有效地响应同一个PP。因此，在ST的符合性评估方面，ST评估者将聚焦在如何验证它是PP所提需求的充分、完整、正确和一致的解释。 一些CC用户会参与ST的编制与使用，例如某个TOE开发者编制ST，以响应用户在PP中表达的安全需求，由潜在TOE消费者阅读和确认IT产品开发者的ST是否满足其定义的PP。当然TOE开发者编制的ST必须符合CC第1部分附录A定义的结构，并按照CEM中的ST评估保障要求(ASE)进行审核和评估。所以，ST需要承担两个典型的角色。 (1) TOE评估之前及评估期间： ST指出 “要评估什么”。在这个任务中，ST是作为TOE开发者和评估者之间在TOE安全功能和评估范围上达成一致的基础。TOE实现安全技术正确性和安全功能完备性是这个任务的主要挑战。 (2) TOE测试评估后： ST指出“被评估了什么”。在这个任务中，ST也是作为TOE开发者或销售者和TOE潜在消费者之间达成一致的基础。ST描述了TOE确切的安全功能，潜在消费者能够信赖这个描述，因为TOE已经过CC测试实验室的安全评估，证实了TOE实现满足ST定义的安全要求。 ST的易用和易理解特性是TOE开发者在编制ST时需要考虑解决的主要问题，但是ST不应承担以下两个角色。 (1) 详细规范： ST中的TOE概要规范(TSS)是较高抽象级别的安全功能及其实现机制的描述。ST一般不包含TOE协议规范、算法或实现机制的详细描述，如冗长的TOE具体操作描述等。 (2) 完整规范： ST只给出了TOE的安全规范，而没有包括TOE的通用功能规范。除非与TOE安全相关，否则TOE的兼容性、物理大小和重量、要求的电压等通用功能不应该成为ST概要规范的组成部分。也就是说ST中的概要规范通常是TOE完整规范的一部分，并非TOE的完整规范。 TOE开发者编制的ST一旦被TOE评估者认可，就将被用作描述TOE安全功能及其实现的基础。被认可的ST一般也会发布在国家级认证产品公告栏和已评估IT产品列表中。注意公开发布的ST通常已被简化，以去除公司专有的或敏感的安全信息。因此，这些已发布的ST文档可能并不是“完整的”。 不同于第4章的PP结构，CC第1部分附录A定义的ST文档结构中增加了TOE概要规范，以准确地描述TOE的安全功能和安全保障要求是如何被实现的。 在IT产品安全功能的描述方面，TOE开发者编写的ST文档应当是自包含的，不应要求读者为理解ST去翻阅大量其他文件。ST并非一次即可编辑成型，这是一个动态修订的过程，一旦产品还没有被最终实现，ST的修改过程极可能被下列事件触发。 (1) 识别和应对新的威胁，例如TOE运行环境的变化导致TOE需处理新的安全攻击。 (2) 组织安全策略的改变，例如TOE运行环境基础设施变化需要对TOE的组织安全策略进行调整。 (3) IT产品安全功能行为或预期用途的改变，例如由于TOE安全机制概念改变导致安全策略配置或TSF管理的改变。 (4) 成本或进度计划改变，例如TOE研发人员或研发环境的变化导致TOE开发成本或开发计划的变化。 (5) 出现开发成本高于预期的情况，例如使用第三方服务组件升级或使用未在预算计划中的支持工具。 (6) 在TOE及其运行环境之间的安全要求分配的变化，例如由于时间和资金的限制，希望由TOE 担负与希望由TOE 环境担负的责任划分可能发生变化。 (7) 新的IT技术出现，例如大数据技术、人工智能技术的采用。 (8) 出现TOE评估或操作过程中未覆盖的缺陷。 (9) 认证规范或活动(认证认可［C&A］)要求发生变化。 正如第4章所述，CC第3部分的生命周期保障族(ALC_LCD)定义了两个组件来评估TOE开发者使用的生命周期模型的恰当性、规范性及TOE可测试性。PP编制、ST编制、TOE安全评估等涉及CC评估过程的相关概念可映射到软件生命周期的某阶段。ST相当于软件生命周期的设计阶段，即开发者为响应客户在PP中声明安全要求生成的设计文档，并且设计的安全要求实现措施应通过CC第3部分的ST保障评估(ASE)活动的评估验证。 ST是组成IT产品采购活动授权前所进行的招标过程的一部分，ST应包括在潜在投标客户提交的招标响应文件中，采购方应选择合适的专家小组对其安全功能和安全保障要求进行评估。表5.1列出了ST和通用系统生命周期阶段以及通用采购阶段相关活动的映射关系。 表5.1通用评估准则活动与通用系统生命周期和采购阶段的映射关系 通用评估准则活动通用系统生命周期阶段系统采购通用流程 无概念概念定义、可行性研究、需求分析、成本预算等 保护轮廓编制 PP安全评估活动： APE需求分析和规范说明招标书中发布的安全要求文件 安全目标编制 ST安全评估活动： ASE系统设计需求： 由供应商提交技术评估和成本建议 由中标供应商开发TOE TOE安全评估活动： ALC_DVS、ADV系统开发采购招标与合同签订 TOE评估活动： ATE、AVA系统验证验收交货订单物，发现不满足需求的设计或开发缺陷 TOE评估活动： ALC、ADV、AGD确认、安装和检验系统安装部署和试运行 TOE评估活动： AGD、ALC_FLR、AVA运行和维护系统运行，并过渡到维护合同 无停止合同期满 5.2安全目标结构 作为响应客户PP的安全方案文档，ST是TOE开发和评估的依据。CC实施这一约束是为了确保TOE开发者编制的ST是准确的，并且能被CC所有用户充分、完整、正确和一致地理解和解释。 编写ST的前提是TOE开发者获取了一系列描述客户安全需求的资料。所以TOE开发者在编写ST之前通常需要与CC专家和安全评估人员一起分析客户认可的PP或可参考的IT产品安全需求。图5.1描绘了CC第1部分给出的ST文档结构及其内容，包括相关的格式要求。它可用作TOE开发者编制ST的结构性框架。但该结构也是允许变化的，例如，如果安全要求基本原理内容特别多，可以放在ST最后作为一个章节单独描述，而不放在图5.1所示的安全目的和安全要求章节。ST文档的每一部分内容和应用都将在本章的5.3节~5.9节中详细讨论。ST文档包含的7部分内容如下。 图5.1ST文档结构和内容 (1) ST引言： ST第1部分在3个抽象层面上对TOE进行叙述性描述。为ST及其相关的TOE提供标识信息； 通过定义ST功能、范围和状态来简要描述TOE功能； 从系统类型、安全架构、逻辑及物理安全边界等来对TOE安全功能进行更加详细的描述。 (2) 符合性声明： 表明ST是否声明与某些PP或包符合(且与哪些PP或包符合)。这部分阐明ST是用来响应哪一个PP(如果有)、包(如果有)以及是否在CC第2部分和第3部分组件的基础上增加了扩展组件来响应特定的安全要求。 (3) 安全问题定义： 第3部分声明了TOE安全假设，分析了TOE面临的安全威胁并且列出了适用于TOE安全运行的组织安全策略。 (4) 安全目的： 第4部分描述了TOE安全目的和运行环境安全目的，这些安全目的来自对第3部分的假设、威胁和组织安全策略的分析。因此，该部分还包括安全目的的基本原理说明。安全目的划分为TOE安全目的和运行环境安全目的。 (5) 扩展组件定义(可选)： 第5部分用于描述在ST中TOE特定的安全要求没有采用CC第2部分和第3部分标准组件来定义，而是通过新定义组件来表达这些特殊的扩展功能要求和扩展保障要求。 (6) 安全要求： 第6部分分别通过安全功能要求(SFR)和安全保障要求(SAR)来回答第4部分中描述的TOE安全目的是如何实施的，这些SFR和SAR来自对第1部分中讨论的安全架构、安全边界以及第3部分中描述的威胁和组织安全策略的分析。 (7) TOE概要规范： 第7部分描述用来实现第6部分所陈述的安全要求具体的功能行为及其实现技术与机制，表明安全功能要求(SFR)在TOE中是如何被实现的。 如果安全目的、安全要求或概要规范的基本原理内容特别多，可以放在ST文档的最后一并陈述。总之，ST编制者在ST中陈述的基本原理包括以下几点。 (1) 第4部分中声明的安全目的支持所有的假设，应对所有威胁，执行第3部分定义的所有组织安全策略。 (2) 第6部分定义的安全要求满足第4部分声明的TOE所有安全目的。 (3) 第7部分描述的TOE概要规范实现了第6部分声明的TOE所有安全要求。 (4) 第2部分关于PP合规性的声明是有效的。 ST不同章节内容之间的完整性与一致性证明来自对上面所列部分的关联分析和一致性与完整性检验。表5.2总结了ST各部分内容之间的依赖关系。 表5.2ST各部分内容之间的依赖关系 章节目标源 引言确定ST的性质、范围和状态，描述需要保护的TOE的系统类型、安全架构、通用功能，保护资产、逻辑与物理安全边界来自CC第1部分的PP结构要求 PP符合性声明识别出可应用于ST的PP，指明相关的裁剪和扩充要求由PP/ST第3节至第6节内容的比较导出 安全问题定义陈述TOE保护的资产，相关的假设、面临的安全威胁，并引用适用于TSF的组织安全策略来自参考PP 安全目的 描述TOE和TOE运行环境的安全目的来自第3节的假设、威胁和安全策略的分析 扩展组件定义提供TOE附加的安全要求来自TOE的安全问题陈述及TOE的安全目的 安全要求 通过安全功能要求SFR和SAR的组合实现ST，并用证据证实TOE的安全要求是完整而紧密的来自系统安全架构和安全边界分析(第2节)和面对的安全问题风险分析(第3节) TOE概要规范向TOE的潜在消费者提供TOE如何满足安全功能要求和安全保障要求的描述,使潜在消费者能够充分理解TOE的一般形态和实现通过对第6节的安全要求、当前IT技术和工业界最佳实践分析得出 理解PP/ST之间的关系是很重要的。不同于PP，第7部分定义的TOE概要规范是ST特有的。相对地，ST的前6个部分与PP结构基本相同。如果一个ST声明了PP的完全符合性要求，则相应PP的第3到第6部分在本ST中可能是被引用而不是被复制。在CC网站上已经发布的ST中，通常的做法是在ST相应部分中提供附加的具体实现细节。表5.3说明了ST和相符合的PP各部分之间的 相似与不同。 表5.3PP中各部分和ST中各部分之间的相似与不同 保护轮廓结构交互安全目标结构 1. 引言 PP/ST标识部分基本相同 在TOE概述部分，PP聚焦于系统资产所有者和TOE安全边界，而ST关注TOE的安全架构、物理和逻辑安全边界 在ST中多一个比TOE概述更详细的TOE描述小节，这样评估者和潜在消费者对TOE安全能力能有更清楚理解1. 引言 2. 符合性声明 PP与ST基本相同 PP不一定有PP符合性声明，ST一般有PP符合性声明2. 符合性声明 3. 安全问题定义 PP与ST基本相同 ST进一步区分是TOE应对威胁还是由其运行支持环境应对威胁3. 安全问题定义 4. 安全目的 PP与ST基本相同 ST安全原理部分可能增加ST概要规范原理性解释4. 安全目的 续表 保护轮廓结构交互安全目标结构 5. 扩展组件定义 PP与ST基本相同5. 扩展组件定义 6. 安全要求 PP与ST基本相同 ST可能对PP中未完成的组件元素进一步操作 ST可能对PP中未解决的依赖关系进一步分析 ST可能增加新的安全要求 ST安全原理部分可能增加ST概要规范原理性解释6. 安全要求 在PP中没有对应内容 提供TOE用于该目的的一般性技术机制7. TOE概要规范 图5.2是2014年发布在CC官方网站上的IBM数据库产品DB2在z/OS平台上的ST(DB2 11 for z/OS Security Target)结构。从目录结构(注意省去了该ST的三级目录)可以 1引言 1.1ST 参考 1.2TOE 参考 1.3TOE 概述 1.4TOE 描述 2符合性声明 3安全问题定义 3.1介绍 3.2威胁 3.3组织安全策略 3.4假设 4安全目的 4.1TOE 安全目的 4.2运行环境安全目的 4.3安全目的原理 5扩展组件定义 6安全要求 6.1TOE 安全功能要求 6.2安全功能要求原理 6.3TOE安全保障要求 6.4安全保障要求原理 6.5TOE 概要规范原理 7TOE概要规范 7.1TOE体系结构概述 7.2标识与鉴别 7.3访问控制 7.4z/OS通信安全 7.5安全管理 7.6审计 7.7对象重用 7.8TOE自保护 8缩写、术语和参考文献 图5.2DB2 ST结构样例 看出，IBM的DB2数据库基本遵循了ISO/IEC TR 15446 技术报告结构要求，只在最后添加了一个缩略语、术语和参考文献。 关于组合TOE，应对每个TOE部件都编写一个独立的ST，被引用的PP都应当反映到组合TOE。注意区分包含在PP里的假设、威胁、组织安全策略、安全目的、SFR、SAR等，明确哪些部分将应用于组合TOE的所有TOE部件，哪些将应用于某一个TOE部件。另外注意对于不同的TOE部件，安全组件上的元素操作执行上可能有所不同。不论哪种情况，对TOE部件适用的假设、威胁、组织安全策略(OSP)、安全目的、安全功能要求(SFR)和安全保障要求都将成为ST的一部分内容。图5.3阐明了组合TOE 与PP/ST之间的关系。 图5.3组合TOE与ST和PP之间的关系 在GB/T 18336—2015版本中允许低保障级ST用于作EAL1评估(注EAL2及以上评估保障级不可以)。低保障级ST只能声明符合一个低保障级PP(见4.9节讨论)。一个常规的ST(即有ST规范要求的全部内容)可以声明与一个低保障级的PP符合。 低保障级ST包括常规ST的部分内容，但与常规ST相比也明显减少了一些内容，如下。 (1) 不用描述安全问题定义。 (2) 不用描述TOE安全目的，但运行环境安全目的仍然必须描述。 (3) 由于ST中没有安全问题定义，所以不用描述安全目的基本原理。 (4) 由于ST中没有TOE安全目的，所以安全要求基本原理只需要证明未被满足的组件依赖关系。 5.3安全目标引言 ST引言在3个抽象层面上对TOE进行描述。 (1) ST标识： 为ST及其相关的TOE提供标识信息。 (2) TOE功能概述： 简要描述TOE通用功能及其运行环境。 (3) TOE安全描述： 对TOE安全架构及其主要安全功能进行更加详细的描述。 5.3.1ST标识 ST标识用于正确地登记、索引和交叉引用由各国评估机构和CCRA参与者维护的ST相关信息。ST标识一般由标题、版本、作者、出版日期等信息组成。因此，ST标识部分里的第1个字段简单地描述ST名称； 而第2部分陈述ST版本、发布日期、作者等字段信息； 第3部分字段列出与ST相关的关键词，例如产品分类、开发或用户组织和商标名称； 第4个字段引证编制TOE时参考的CC版本信息； 最后字段指出ST当前评估状态。图5.4给出了CC官方网站上两个ST标识部分的例子和我国推荐使用的ST标识样例，第一个样例没有给出ST标识，只给出了ST的版本和发布日期，第二个有完整的注册信息，并包括评估认证等字段。最后一个样例是我国GB/Z 20283指导性文件推荐使用的ST和TOE相关标识信息。 总体来说，TOE标识需包括TOE名称、开发者名称和TOE版本号。TOE标识的例子： “某数据库 v2.11”。由于真实的IT产品处于不断发展中(如Oracle数据库已经有14个大版本)，同一个IT产品可能因版本升级需要多次评估。因此某个IT产品会有多个ST(TOE)。即使是同一版本的IT产品，由于安全选件不同，或满足不同消费者的需求，同一版本IT产品可能有多个ST(TOE)。因此，面向不同消费者进行评估的IT产品会有多个ST，TOE标识不必是唯一的。例如Oracle数据库分标准版和企业版，企业版 又分为基础版、标签版和数据库仓库版，表5.4给出了Oracle公司Oracle 11g不同数据库版本的认证情况(https://www.oracle.com/technetwork/topics/security/securityevaluations099357.html)，从表中的Oracle不同安全选件看出，Oracle针对不同功能的版本发布了相应的ST。 样例1： TOE for IBM DB2 11 for z/OS Version 1 Release 13 1.1ST标识 标题： IBM z/OS平台DB2 11安全目标 版本： 1.9 状态： 最终版本 发布日期： 20140328 发起人： IBM 公司 开发者:： IBM 公司 关键字： IBM DB2 for z/OS; 关系数据库管理系统(DBMS) 样例2： TOE for Mobile PayPass 1.0.13vA.2.4 on Orange NFC V2 G1 1.1ST标识 标题： Mobile PayPass 1.0.13vA.2.4 on Orange NFC V2 G1 参考文献： D1321203 版本： 1.0p 发表日期： October 20th,2014 作者： Gemalto 安全评估机构： THALES CEACI 认证主体： ANSSI CC 版本： CC v3.1 r3 状态： 发布 样例3： 基于GB/T的评估对象技术要求标识 ST标识信息 ST标题： ×××安全目标 ST文档编号： ××× ST文档版本： ××× 发行时间： ××× 作者： ×××公司 TOE标识信息 TOE名称： ××××××芯片（以下简称×××） TOE版本： ××× 发布： ×××公司 图5.4ST标识样例 表5.4Oracle 11g 数据库不同版本、不同组合选件的ST列表样例 安 全 目 标保障级别认 证 日 期 Oracle Database 11g Release 2 Enterprise Edition,version 11.2.0.2,with all critical patch updates up to and including July 2011 via the July 2011 PSU as well as the October 2011 CPUEAL 4+ ALC_FLR.320120117 Oracle Database 11g Release 2 Standard Edition and Standard Edition 1,version 11.2.0.2,with all critical patch updates up to and including July 2011 via the July 2011 PSU as well as the October 2011 CPUEAL 4+ ALC_FLR.320120117 Oracle Database 11g Enterprise Edition,Release 11.1.0.7 with Critical Patch Updates up to and including July 2009EAL 4+ ALC_FLR.320090916 续表 安 全 目 标保障级别认证日期 Oracle Database 11g Enterprise Edition with Oracle Label Security,Release 11.1.0.7 with Critical Patch Updates up to and including July 2009EAL 4+ ALC_FLR.320090916 Oracle Database 11g Standard Edition and Standard Edition One Release 11.1.0.7 with Critical Patch Updates up to and including July 2009EAL 4+ ALC_FLR.320091012 Oracle Database 11g Enterprise Edition with Oracle Database Vault Release 11.1.0.7 with Critical Patch Updates up to and including July 2009EAL 4+ ALC_FLR.320091012 对于组合TOE来说，如果它是由一个或多个已评估IT产品(TOE部件)构成，那么允许在TOE标识中引用已评估的TOE部件名称，但TOE标识信息不应该用来误导组合TOE消费者： 不允许在标识中出现TOE部件评估中没有考虑的重要部件或安全功能，同样也不允许在TOE标识中出现没有反映出组合TOE的安全功能要求的情况。 前面提到，ST标识和TOE标识便于在已评估的TOE或产品列表中检索和标识ST和TOE。因此，ST作者在标识ST和TOE时可参照国家评估体制或IT厂商产品名称等标识规范。 5.3.2TOE功能概述 TOE功能概述的目的是帮助TOE潜在消费者通过阅读已评估TOE功能概述信息，以找到可能满足他们功能需求的IT产品，且是他们的硬件、软件和固件等TOE运行环境支持的IT产品。 如果ST是符合某个PP的，则相应PP引言的第2部分已经包含用作开发TOE功能概述的输入信息，如： TOE通用功能描述、TOE资源类型和敏感资源列表、TOE资源的访问控制权限和特权、TOE安全边界定义等。 TOE开发者可能在ST中简单地重申PP中的这些TOE功能概述信息。然而，最好的方式是通过分析TOE实现技术与机制对PP中的TOE功能概述提供一些增量的说明，尤其是当ST是为一个组合TOE编写时。重述PP中的信息只是告知TOE消费者和评估者PP信息的准确适用。相反，在ST中进行增量分析表示PP中TOE功能概述信息已经被开发者分析和评估，并且已经被ST编制人员理解。 TOE功能概述一般包括三部分内容。 (1) TOE用途： 简单描述TOE的使用场景和它的重要功能。 (2) TOE类型： 标识TOE类型。 (3) TOE运行环境： 标识TOE运行所依赖的硬件、软件和固件。 TOE功能概述为ST文档其余部分设置了评估语境。因此，TOE功能概述通常需要用几个段落对上述3部分内容进行描述。TOE功能概述部分可能列出与这一部分或任一在ST中引用的文档相关的PP/ST。相关的ST可能包含同一TOE部件部分的其他安全组件，引用的文档可能包含组织安全规范和安全策略、国家法律法规和CC出版物。当然TOE功能概述部分应阐述ST的内容和结构，包括在ST中使用的缩略词、术语等。 1. TOE用途 ST编制者需要定义TOE的预期用途，包括与外部IT实体的依赖关系。这些信息的有些部分可能来自对PP里的通用功能描述的分析和TOE特定功能行为的组合。 TOE用途是为TOE潜在的消费者编写的，所以ST编制人员应依据消费者业务功能需求，使用消费者理解的语言描述TOE的用途和重要安全功能。 例如： “某数据库 v12.01是一个用于网络环境的多用户数据库，它允许百万用户同时并发操作数据库中的数据，提供口令、令牌和生物识别等数据库用户认证方式，提供系统宕机、磁盘介质故障等意外故障的数据库恢复功能，提供细粒度访问控制以支持基于标签策略的授权控制，其数据库审计特征可支持一般的数据库安全审计及细粒度安全审计，以便允许对某些用户和事务执行详细审计，同时保护其他用户和事务的隐私”。 2. TOE类型 TOE类型一般通过TOE的信息技术来区分不同的TOE。对于单一的TOE或商用现货产品(COTS)产品，业界已经建立了TOE类型列表，例如应用级别防火墙、流量过滤防火墙、入侵检测系统、数据库管理系统等。对于组合TOE以及TOE部件应提供更多的实现机制及相关技术细节，例如TOE部件中的技术类型和组合TOE框架中执行的具体技术。 有关TOE类型可参照CC官方网站和各国安全认证体系对IT产品的分类进行标识。例如我国针对IT产品和信息服务分别发布了GB/T 25066—2010 《信息安全技术 信息安全产品类别与代码》和GB/T 30283—2013 《信息安全技术 信息安全服务 分类》。当然如果不易确定TOE所说的类型，此时也可在ST中不明确指定TOE类型。 在某些情况下，TOE类型可能误导消费者，示例如下。 (1) 某些TOE因为其类型而被预期认为具备某种功能，但是TOE却不具有该功能，例如： ① ATM卡类型的TOE，但该TOE却不支持任何标识和鉴别功能； ② 防火墙类型的TOE，但该TOE却不支持用户使用的各种网络协议； ③ 公钥基础设施(PKI)类型的TOE，但该TOE却没有证书撤销功能。 (2) TOE因为其类型而被预期运行在某些运行环境中，但该TOE达不到这样的要求，例如： ① 个人计算机操作系统型TOE，该TOE要求除非PC没有网络连接、软盘驱动器和CD/DVD播放器，否则就不能安全工作； ② 防火墙类型的TOE，该TOE要求除非所有能够连接防火墙的用户都是善意的，否则防火墙不能认为是安全工作的。 图5.5给出了两个TOE类型定义示例： 一个是SQL Server数据库的，另一个是面向商用现货产品(COTS)的。注意TOE类型描述一般不会超过几个段落。 样例1： SQL Server 2012 1.3.1 产品类型(Product Type) The product type of the TOE described in this ST is a database management system (DBMS) with the capability to limit TOE access to authorized users,enforce Discretionary Access Controls on objects under the control of the database management system based on user and/or role authorizations,and to provide user accountability via audit of users’ actions. The TOE,which is described in this ST,is the database engine and therefore part of SQL Server 2012. It provides a relational database engine providing mechanisms for Access Control,Identification and Authentication and Security Audit. 样例2： COTS Security Product 2.1.5 系统类型(System Type) The XYZ Guard is a network security device that uses the National Security Agencys (NSA) cards to provide multilevel secure(MLS) services to legacy networks，i.e. Internet Protocol (lP) networks that operate in system high mode. XYZ Guard protects enclaves or individual hosts. With in a network，XYZ Guard is inline between the host and the network. XYZ Guard operates on standard IP datagrams. The XYZ Guard can also serve as a firewall or an inline encryptor. 图5.5TOE类型定义样例 3. TOE运行环境 某些TOE可能不会依赖其他IT系统，但常见的IT产品(特别是软件产品)的安全运行需依赖TOE外部的硬件、软件或固件。在此情况中，ST编制者需要在TOE功能概述中标识出TOE运行环境相关的IT硬件、软件或固件。尽管CC不要求ST编制者完整地，且充分详细地标识出IT运行环境信息，但是CC还是建议在ST中应完整并尽量详细地描述这些信息，以便TOE潜在消费者能确定他们使用该TOE需要的硬件、软件或固件。 TOE运行环境所需的硬件、软件、固件等标识示例如下。 (1) 标准PC，处理器1GHz以上，内存8G以上，某操作系统运行版本10.0，更新版本10b、10c或10d，或者版本11.0。 (2) 标准PC，处理器1GHz以上，内存512MB以上，某操作系统运行版本7.0，更新版本7d，带1.0 WM驱动套件的某图形卡1.0 。 (3) 智能卡SB2067集成电路。 (4) 智能卡SB2067集成电路，运行某智能卡操作系统v2.0。 (5) 某办公室局域网等。 5.3.3TOE描述 TOE描述包括TOE安全架构及其相关的安全功能行为叙述。TOE描述是为使评估者和消费者理解TOE的安全能力的，它应比第1部分引言中的TOE功能概述的描述更详细，且TOE描述需要说明TOE在未来部署中可适用的各种应用环境。CC建议TOE描述需包含体系架构、安全边界与接口、安全功能概述等内容。 1. 体系架构 体系架构代表了TOE的组织结构、组成构件和构件间的相互关系，以及构件与外部环境间的交互关系。TOE通过对其体系架构的描述，界定各组成部分之间的连接、确定它们不同组件之间的交互机制，并且为后续的TOE设计和开发提供指南类的原则。图5.6示例了一个关系数据库管理系统体系架构图，它包括一组内存结构组件、后台进程组件以及各组件之间的交互关系，将数据库管理系统的不同功能单元通过这些组件之间定义良好的接口和契约联系起来，对外提供高效的数据组织、存储和检索服务。 图5.6TOE体系架构样例 不同于TOE安全架构(ADV_ARC.1)，TOE体系架构主要是帮助用户理解资产在TOE中的位置及其数据流向。TOE安全架构定义TOE安全功能(TSF)正常运转的语境，是TSF展示自保护、域分离、不可旁路等安全属性的集合。 (1) 自保护是TSF用于保护自身的能力，以抵御外部实体可能导致TSF改变的操作。没有这些属性，TSF可能无法执行安全服务。常常有这种情况，TOE使用其他IT实体提供的服务或资源来实现它的功能(例如数据库管理系统的存储依赖它的下层操作系统)。在这些情况中，TSF不完全凭借自身保护自己，因为它依赖于其他IT实体保护其使用的服务。 (2) 域分离是指TSF为每个操作其资源的不可信主动实体创建各自的安全域，并维持域之间彼此分离的机制，防止某个域中的实体在其他实体域中运行。例如，操作系统TOE为每个与不可信实体相关的过程提供一个域(地址空间、进程环境变量)。对有些TOE来说这样的域是不存在的，因为所有不可信实体的行为都由TSF来代理。包过滤防火墙就是此类TOE的一个例子，TSF只维护相关的数据结构，没有不可信实体域这个概念。TOE安全域依赖于TOE类型以及TOE的安全功能要求。TOE若提供针对不可信实体的域，本族要求拥有不可信实体的域要与其他域隔离，以免受其他不可信实体域的干扰(不受TSF控制的影响)。 (3) 不可旁路性是TSF安全功能经常调用的一个属性，要求TOE特定机制不能被绕过。例如，如果对文件的访问控制被安全功能要求规定为TSF的一种功能，那么TOE不能存在可直接访问文件的接口(例如原始磁盘访问文件这样的接口）。TSF自保护使有些TOE很自然地依赖它们所处的环境，在TSF的不可旁路性中发挥作用。例如，某安全应用TOE要求它仅被底层操作系统调用。类似地，防火墙的安全性依赖于这样一个事实，即不存在内部网络和外部网络的直接连接通路，所有它们之间的通信必须通过防火墙。 对TOE安全架构的描述解释了TSF如何展示以上描述的这些属性。具体地说，它描述安全域如何定义，TSF之间如何保持隔离，怎么阻止不可信进程获得TSF并修改它，怎样确保TSF控制之下的所有资源得到充分的保护，以及TSF所要满足的安全功能要求相关的所有行为都表现正常。它还会解释所有情况下(例如，假定它的底层环境调用正确，它的安全功能如何被调用？)环境应扮演的角色等。 TOE安全架构定义了由TOE体系架构约束下的TSF特性、PP/ST定义的资源类型和敏感性。如果ST是为一个特定安全商业化产品编写，则TOE体系架构和安全架构可能是相同的。相对地，如果ST是为某个系统的TOE部件编写的，则TOE体系架构和安全架构之间可能存在区别。 描述ST中的系统架构应包括主要硬件和软件(系统和应用)平台、其中的组件和模块及其之间层次结构依赖关系。系统架构应列出这些组件具体的版本号和配置，并且在补充的图表中阐明这些关系。例如在安全目标SQL Server架构最后，给出了表5.5所示的软硬件配置需求。 表5.5软件与硬件配置需求 项目配 置 需 求 中央处理器AMD Opteron,AMD Athlon 64,Intel Xeon with Intel EM64T support,Intel Pentium IV with EM64T support at 1.4 GHz or faster 内存1GB 硬盘Approx. 1500 MB of free space 其他DVD ROM drive,display at Super VGA resolution,Microsoft mouse compatible pointing device,keyboard 操作系统Windows Server 2008 R2 Enterprise Edition(English)or Windows Server 2012 Standard Edition(English) 支撑软件.NET Framework 3.5.1SP1/4 2. 安全边界 TOE安全边界包括TOE逻辑和物理两个层面的安全边界描述。评估者使用这一部分信息来决定TOE安全配置的范围和边界。因此，需要保证有哪些内容包含在或不包含在TOE边界里的精确而简洁的边界描述。 物理安全边界表示应该将构成TOE的所有硬件、固件、软件及指南部分在ST中进行列表展示。该列表应该在一定程度上使读者对TOE物理安全边界有一般性理解： 边界内的IT实体是在TSF控制范围(TSC)内，并且以指定的方式在一定程度上被保护； 边界外的IT实体则不在TSC里，即不在TOE安全评估范围。换句话说物理安全边界是通过确切地声明哪些硬件、固件、软件平台、组件和模块包含与TSF实现独立的实例来定义的。版本号、配置选项、交互接口、系统应用、初始化参数、应用程序模块等都应该通过列表方式给出。另外，应描述TSF接口(TSFI)——通过什么接口［人机界面或应用程序接口(API)］访问TOE保护的各种资源或者以什么方式获取相关的信息。实质上，TOE安全描述中的物理安全边界定义附加了在TOE体系架构部分里提供信息的其他层次的交互细节。 逻辑安全边界的定义与TOE安全服务或安全功能相关。通过对TOE提供的安全功能描述，使读者获得对TOE安全服务的一般性理解。该描述应该比TOE功能概述中描述的重要安全功能更加详细。通常包含以下内容。 (1) 讨论哪些安全服务会被物理安全边界内的IT实现提供。 (2) 按照与功能类名相同的标准给这些功能或服务分组，例如安全审计、用户数据保护、鉴别与认证、安全管理等。 TOE物理边界和逻辑边界需要以一种无歧义的方式描述TOE安全功能，明确哪些组成部件或安全功能在TOE之内，哪些部件或功能在TOE之外。当TOE与非TOE实体联系在一起并且不能轻易将它们分离时这显得尤其重要。 界定TOE与非TOE实体的特殊示例如下。 （1） TOE是智能卡IC的密码协处理器，而不是整个IC。 （2） TOE是除了密码处理器之外的智能卡IC。 （3） TOE是某防火墙v18.5的网络地址转换部件。 本部分的最后，一般会给出哪些内容不包含在TOE安全边界里的一个声明。例如： 在TSF定义范围外的软件和硬件安全功能不会被评估，包括： ［由开发者提供的列表］。 表5.6举例说明了物理和逻辑安全边界的部分定义。 表5.6TOE安全边界定义 例1： 物理安全边界 2.3安全边界 2.3.1物理边界 表1里描述的条目是在TOE物理安全边界内。 表1： TOE物理安全边界定义 TOE组件/模块 工作站 英特尔I7处理器 8GB RAM 2T硬盘 CDRW驱动器 键盘 鼠标 串行端口 2个USB端口 续表 TOE组件/模块 工作站 15英寸，高分辨率平板彩色监视器 电源线 2个1000Mb/s以太网接口 微软Windows Server操作系统专业版 文件系统 安全子系统 事件日志服务 注册表服务 Office 2017 例2： 逻辑安全边界 2.3安全边界 2.3.2逻辑边界 2.3.2.1用户数据保护 FTP和Telenet安全服务器向不正确的服务请求提供认证和保护，而HTTP和SMTP安全服务器提供应用级别保护。模块A确保一旦会话完成，前一会话里的数据包包含的信息不再可以访问。管理数据包存储和处理来确保没有残留信息会被传入之后的会话。模块B通过应用TSP规则执行检验过程。模块C作出关于每个包是否应当被接受、拒绝或放弃的决定。 3. 安全功能 TOE描述的第3部分是安全功能概述，概述的目的是向TOE的潜在消费者提供TOE预期的安全行为描述。本部分应该提供TOE安全功能实现技术与机制，描述的详细程度应该使潜在消费者能够充分理解TOE安全功能的一般行为及其运行机制。 5.4符合性声明 符合性声明编制的基本要求是保证ST内容是完整的、清晰的和无歧义的，以使ST的评估符合CC相关要求。ST是支撑TOE评估的基础材料，对ST中任一指定的符合性声明其追溯过程应该清楚。 符合性声明包括： ■CC版本； ■PP(如果有)； ■包(如果有)。 ST与CC符合性描述由两项组成： 使用的CC版本以及ST是否包含扩展安全要求。在包含扩展安全组件情况下，新组件(扩展组件)必须在ST的第5部分明确定义，必须使用类似于CC第2部分和第3部分标准组件结构的方式定义扩展组件： 保证其清晰、明确和可以评估。 PP和包符合性声明应说明和解释一个ST和被引用的PP和包之间的符合程度，可以是无，也可以是完全符合。所有的PP和包符合性声明必须通过充分解释，说明并论证其原理。 ST读者，不管是TOE消费者还是TOE评估者，都需要在ST的第3部分之前先对引用的PP和包有一定认识才能正确地理解和解析ST所包含的全部内容。因此，把PP和包符合性声明作为ST的第2部分是合理的。表5.7是两种主流商业化数据库管理系统安全目标的符合性声明示例。 表5.7ST符合性声明样例 样例1： SQL Server 2012 2符合性声明 2.1CC 符合性声明 本安全目标符合 CC标准第2部分(版本3.1,修订3)扩展，原因是使用了FAU_STG_EXP.5扩展组件。 CC标准第3部分(版本3.1,修订3)EAL 4+，原因是增强了ALC_FLR.2保障组件。 2.2PP 符合性声明 本保护轮廓符合严格符合： 美国政府数据库管理系统保护轮廓(BRDBMSPP),版本1.3，2010年12月24日。 样例2： DB2 2符合性声明 本安全目标符合CC标准第2部分(版本3.1,修订4)扩展和CC标准第3部分(版本3.1,修订4)EAL 4++，增加了ALC_FLR.3保障组件。 本安全目标符合下列保护轮廓和扩展包： ［OSPP］: 操作系统保护轮廓，版本2.0，2010年6月1日； 严格符合。 ［OSPPEIA］: OSPP标识和鉴别扩展包，版本2.0，2010年5月28日。 ［OSPPLS］: OSPP标签安全扩展包，版本2.0，2010年5月28日。 这些保护轮廓及其扩展包可从BSI Web站点下载 (认证标识 ID BSICCPP00672010)。 对PP符合性声明一般包含4个子部分： PP引用、PP裁剪、PP增加和符合性说明。 5.4.1PP引用 PP引用部分列出了ST参考的PP信息，包括PP全称、版本号、发布日期等信息。ST中的PP符合性声明可能有5种场景。 (1) 无参考PP： 没有声明PP符合性。ST编制者必须在ST的第3到第6部分明确定义安全问题、安全目的和安全要求； 相应地，有关PP符合性声明的PP裁剪(5.4.2节)和PP增加部分(5.4.3节)将在本部分省略掉。 (2) 完全符合： 也称为严格符合。ST编制者应列出安全符合的PP，并在ST的第3到第6部分仅引用符合性声明PP中的部分安全问题、安全目的和安全要求，而不一定需要在ST中重新定义这些内容。对于完全符合的PP，有关PP符合性声明的该引用PP裁剪(5.4.2节)和该PP增加部分(5.4.3节)将在本部分省略掉。 (3) 仅对PP进行裁剪： 列出符合的PP，并对引用PP的安全问题、安全目的或安全要求进行部分裁剪。ST编制者应重点突出对PP引用第3到第6部分的裁剪内容。PP符合性声明的5.4.2子部分被包含并用来阐述和证明裁剪合理性。 (4) 仅对PP进行增加： 列出符合的PP，并列出增加的安全问题、安全目的或安全要求。ST编制者应重点突出对PP引用第3到第6部分增加的内容。PP符合性声明的5.4.3子部分被包含来阐述和证明增加内容的合理性。 （5) 部分操作： 列出符合的PP，并对PP组件元素操作的符合性进行说明。这一场景仅在PP是针对某个组合TOE和ST反映的某个TOE部件时有效。为组合TOE的个体或TOE部件声明部分符合性是无效的。注意，部分操作中对PP所有裁剪和增加都应当被重点突出概述，PP符合性声明的5.4.2和5.4.3子部分应当被包含来阐述和证明裁剪或增加的合理性。 “无参考PP”和“完全符合”的PP引用场景互相排斥，但“仅对PP进行裁剪”和“仅对PP进行增加”这两个场景不互相排斥。“部分”场景也可能不包含“仅对PP进行裁剪”和“仅对PP进行增加”。例如SQL Server 2012 EAL 2+安全目标没有引用任何PP，而SQL Server 2012 EAL 4+明确指出它严格符合U.S.Government Protection Profile for Database Management,Version 1.3(BRDBMSPP)。 5.4.2PP裁剪 这一部分指明引用PP第3部分的安全问题，第4部分的安全目的或第6部分的安全要求在ST中被裁剪或客户化定制的情况，包括第5部分扩展组件定义裁剪或自定义情况。ST中安全要求的有效裁剪选项主要是对PP里安全组件元素没有执行过元素操作的进行操作，例如“赋值”“选择”“细化”“反复”。ST编制者应在这部分提供执行了哪些组件元素的裁剪以及为什么执行这些裁剪的说明。 5.4.3PP增加 这一部分指明了ST里包含但不在引用PP里所包含的安全问题、安全目的或安全要求。ST编制者应在这部分解释考虑了PP中未包括的哪些安全问题，衍生出了哪些新的安全目的，并增加了什么要求以及为什么做这些增加。表5.8介绍了一个PP符合性声明示例。 表5.8PP符合性声明示例 2.2PP符合性声明 这一部分介绍了PP符合性声明 2.2.1PP引用 这一安全目的符合以下的PP： 针对低风险环境，U.S.DoD，版本1.d.1（草案）9，1999的应用级别防火墙PP。 声明的符合性程度： 部分操作 2.2.2PP裁剪 下表所列的SFR和SAR从引用的PP裁剪而来。 续表 裁剪的项裁剪动作证明 FAU_GEN.1细化需要指明（1）审计需求是最小、基本、详细还是未指明； （2）审计里包含的项 FAU_SAR.3+1 FAU_SAR.3+2细化和反复需要阐明TOE应当能够： （1）进行用户身份、推测对象、日期范围、时间范围和IP地址范围的检索； （2）基于时间顺序或发生排序审计数据 AVA_VAN.1细化需要指明必须进行分析的被评估TOE的最小已识别漏洞 7.3 PP增加 以下所列的SFR被添加到引用的PP里进行声明。 增加的项证明 FIA_UAU.5引用的PP指明了两个验证机制（重用和单用）需求的一些特殊性，这两个验证机制可能通过FIA_UAU.1和FIA_UAU.4 SFR来要求。然而，不能仅提供一个SFR来指明可能被使用的验证机制的类型，或者需要使用它们的条件 5.4.4符合性原理 符合性声明列出了ST声称符合的CC组件包(如PP)。这方面的解释见CC第1部分的符合性要求。因此，在ST符合性声明 的最后应陈述ST符合性声明的论据，并应通过第三方机构按照CEM对ST声明的有效性进行评估。ST和引用的PP之间的符合性通过以下列表来证明。 (1) 所有的PP安全目的都包含在ST里。 (2) 所有的PP安全目的的细化和增加都是有效的。 (3) 所有的PP安全要求都包含在ST里。 (4) 所有的安全功能和安全保障组件元素的“赋值”“选择”“细化”“反复”操作都是有效的。 如果ST中第8部分的TOE概要规范(TSS)对PP声明是“无参考PP”， PP符合性声明的5.4.4这一部分被标记为“不适用”(即ST中没有这一节)。如果TSS对PP声明是“完全符合”，PP原理应是准确的并且TOE开发者在ST中响应了第1和第3项。如果TSS的PP声明是“仅对PP进行裁剪”、“仅对PP进行增加”或“部分操作”，那么需要更多细节进行说明，并且TOE开发者在TSS中要对上述4项要求进行解释。 5.5安全问题定义 安全问题定义描述TOE安全功能和安全控制范围。ST安全问题定义应反映其所引用的PP所提及的安全应用环境。PP与ST这两个文件之间的安全问题内容差异来自于这样的事实： 一般来讲TOE消费者主导编制的PP是独立于IT产品的具体实现； 而TOE开发者主导编制的ST却是依赖于TOE实现技术与机制的。 和PP安全问题定义结构一样，ST中安全问题定义包括假设、威胁和组织安全策略。注意，按照CC第1部分附录A的ST结构，并不是PP中所列的所有安全问题均需再次陈述。对于物理上是分布式部署的TOE，ST作者最好是针对TOE运行环境的不同TOE部件，分开讨论相关威胁、组织安全策略和假设。 如同第4章PP中的安全问题定义一样，涉及TOE安全问题的定义是领域相关的，也就是说面向TOE安全问题定义的推理过程超出了CC的范围。所以安全问题的定义应该借助领域专家在TOE威胁分析方法与技术的经验，基于5.3.3节TOE描述的安全架构和安全边界定位资产面临的安全风险进行分析。当然我们应该注意到，安全评估结果的有效性对ST依赖性很强，且ST的有效性对安全问题定义的依赖性也很强。因此，ST作者应花费有效资源并使用良好定义的过程分析推导出TOE安全问题。 安全问题开头部分应解释TOE管理的资产。表5.9是数据库领域两个ST引言部分的样例，SQL Server数据库直接以威胁主体和数据资产介绍数据库面临的安全问题，而DB2数据库则概括了ST及其所引用的PP第3部分之间的相互关系。 表5.9ST安全问题定义引言部分样例 样例1： SQL Server 2012 3.1资产 与TOE交互的下列外部实体： 管理员： 管理员被授权来完成管理操作和使用管理功能。 用户： 使用TOE的人员。 攻击者： 攻击者是任何试图破坏TOE操作，以便非法获得受TOE保护的资产访问权限的人员。 TOE维护两种类型的数据资产： 用户数据和TSF数据。作为主要资产的用户数据包括以下几部分： 作为数据对象存储的用户数据； 由DBMS维护的用户开发的查询（各种视图）和存储过程/函数。 次要资产包括TSF数据和TOE自身运行所需维护和使用的数据。这种类型的数据称为元数据，具体包括： 用户数据库和数据库对象定义； DBMS配置参数； 用户安全属性； 安全审计指令和记录等。 样例2： DB2 3.1引言 安全问题定义描述TOE预期使用和部署方式的安全环境。为此，TOE安全环境需标识包括物理和程序性规范、产品预期使用方法等假设，定义产品设计面临的威胁和组织计划采用的安全策略。 本安全目标符合基本操作系统保护轮廓［OSPP］，包括其标识和鉴别扩展包［OSPPEIA］和标签安全扩展包［OSPPLS］。这个保护轮廓资产、假设、威胁和组织安全策略被假设适用于本安全目标，包括z/OS安全目标［ZOSST］在3.1节至3.4节定义的扩展部分。 在下列章节，只有不同于上述这些章节的扩展被列出。引用没有扩展的章节也是为了保证本安全目标的完整性。 5.5.1假设 在一个ST里，开发者需要向TOE消费者和评估者证实ST符合性声明里的PP假设(或它们的一个变种)。一般来讲，假设是关于TOE预期用途、运行环境和TOE连通性，包括预定义的角色和责任等方面的内容。所有与TOE运行环境约束和操作限制相关的内容都应通过假设被指明。因此，假设一般通过IT环境因素来保证。 像PP一样，ST中的假设不能被用来减轻TOE威胁。ST编制者有4个关于使用PP中假设的选项。 （1） PP中假设可能只是简单地被逐字重申。 （2） PP中假设可能被修改或裁剪来反映TOE实现细节。 （3） 新的假设可能被添加至ST。 （4） 如果PP中假设不合适或不适用，那么它们可能不被采用。 表5.10展示了SQL Server数据库和Oracle数据库示例ST假设。SQL Server数据库直接引用PP中的假设； 但Oracle数据库示例ST在引用PP的假设的基础上，只是明确了添加的几个特定假设。 表5.10ST假设 样例1： SQL Server 2012 3.2假设 下表列出了TOE环境的所有假设。这些假设直接采用参考的PP，而没有做任何修改。 假设描述 A.NO_EVIL管理员是诚实的、经过培训的，并且遵循所有管理指南 A. NO_GENERAL_PURPOSE在数据库服务器上没有安装其他获得通用的计算或存储能力的程序或服务(例如： 编译器、编辑器或应用程序) A. PHYSICAL数据库服务器运行环境应提供与其所管理的数据价值相一致的物理安全。例如存储在数据库之外的评估对象相关数据(如配置参数、归档日志等)以一种安全的方式存储和管理 样例2： Oracle 11g r2 3.2假设 除了［BRDBMSPP］第3.3节假设，本ST增加了下列假设，以反映TOE体系结构： A.MIDTIER 在多层应用环境中为了确保评估对象的安全问责制，任意中间层次的评估对象运行环境组件服务都应将原始的授权用户标识发送给TSF(ST作者应根据数据库管理系统针对的具体应用解决方案解释“多层应用问责”的具体含义)。 A.DIR_PROTTOE所使用的目录服务器(如LDAP)提供保护机制，防御针对存储在目录中的TSF数据的非授权访问，包括存储在目录中的TSF数据受访问控制机制保护，存储在目录中的TSF数据被管理人员合理地管理，并且目录服务器及其网络连接从物理和逻辑上都免于非授权人员的访问和干扰。 A.DIR_MGMT企业授权用户应正确地管理存储在目录服务器中的企业用户信息(口令验证码、口令策略、角色和权限)。 A.COM_PROT 假定数据库服务器和应用终端之间、分布式数据库不同节点间的通信信道是安全可靠的(如满足私密性和完整性)。实现方式可通过共享密钥、公/私钥对，或者利用存储的其他密钥来产生会话密钥。 A.CLIENT_AP客户端应用应依照Oracle应用开发文档正确地开发和部署，不使用未文档化的TOE客户端编程接口。 注意，在CC测试实验室的TOE评估期间，这些假设均被认为是真实的，即它们不会以任何方式被TOE评估者测试和验证。出于这些理由，我们只能对TOE的这些运行环境安全做假设。由于TOE评估的目的是检验TOE本身安全行为的正确性和防护措施的充分性，不是通过TOE假设断言是否真实来完成的，所以PP/ST编制者不应对TOE本身的安全行为做假设。 5.5.2威胁 第4章第4.5.2节定义了TOE的潜在威胁，确定了它们发生的可能性和后果的严重程度。ST编制者可以简单地重申PP中的这些信息。然而，最好是结合TOE实现技术与机制等对TOE潜在的威胁执行一些增量分析，特别是针对组合TOE的ST，应该对组成TOE的每个TOE部分标识出潜在的安全威胁。 第4章表4.12详细列举了PP中一个组合TOE里分层的潜在威胁列表。该表可作为ST编制者进行安全威胁分析的输入，以决定哪些威胁是由ST里定义的TOE安全架构考虑。哪些由ST里定义的TOE安全问题考虑。 表4.12列出的PP里每个威胁都属于这两个分类里的一个。第一种威胁的合理性在PP/ST的安全要求原理中详细解释。除此之外，ST编制者也可能识别PP中没有列出的新的潜在威胁。表5.11使用第4章的表4.12作为输入举例说明了这一过程。 表5.11TOE和TOE环境面临的威胁(参考Herrmann 2002) 编号威胁TOETOE环境 T1未检测出的资产威胁可能来自于以下事件 T1a授权用户执行了他未被授权的操作X T1b攻击者(内部或外部人)伪装成一个授权用户尝试执行未被授权的操作X T1c攻击者(内部或外部人)通过冒充授权用户访问未经授权的资源和信息XX T1d授权或未经授权用户无意或故意阻止组织员工访问TOE XX T1e未经授权的用户获得了TOE控制权XX T1f未经授权的用户将TOE设置为不可操作XX T1g未经授权的用户试图绕过TOE的安全控制X T1h未经授权的用户试图猜测身份标识及其验证数据X T1i未经授权的用户通过欺骗等手段获得和使用有效的身份标识及其验证数据X T1j未经授权的用户或外部IT实体查看、修改和删除传输到远程授权用户或管理员的安全相关信息X T2授权用户在未获得 管理员许可情况下访问该信息或资源XX T3攻击者可以窃听或用其他方式获取通过网络传播的数据 T3a未经授权的用户进行流量分析X T3b授权或未经授权的用户使用之前信息流的残余信息X T4授权或未授权用户通过消耗全局资源方式以阻止其他授权用户访问或使用这些资源 T4a借助网络/线路阻塞 (声音或数据)X T4b借助服务拒绝(DoS)和分布式服务拒绝(DDoS)攻击(声音或数据)XX T4c盗窃资源服务X T5用户可能有意或无意地传输敏感信息给不允许看到它的用户X 续表 编号威胁TOETOE环境 T6用户可能或者以发送者或者以接收者的身份参与到信息传输,随后否认这样的行为X T7授权用户可能以软复制或者硬复制的方式导出信息，随后接受者以不符合指定安全敏感的方式处理这些信息XX T8信息的完整性和可用性可能由于以下原因被削弱 T8a用户错误、固件错误、硬件错误或传播错误XX T8b由攻击者的未经授权的修改或破坏的信息XX T8c人为错误或软件、固件、硬件或电力供应故障造成突然中断操作,导致关键数据的损失或损坏XX T8d存储介质老化或不当储存或不当处理存储介质X T8e一个授权用户无意中将病毒引入系统XX T8f一个授权用户能将未经授权的软件引入到系统中X T8g授权或未经授权用户插入恶意代码或使用后门XX T8h一个未经授权的人浏览、修改或破坏安全关键配置信息X T8i未能执行足够的系统冗余或数据备份X T8j偶然或者蓄意删除XX T8k插入伪造数据XX T8l对数据进行未经授权的修改XX T9攻击者可能在某用户希望其对资源或服务的合法使用保密的情况下，观察该用户对资源或服务的使用情况 XX T10一个授权用户可能有意或无意地观察存储用户未授权的信息X T11安全关键组件可能受到物理攻击和（或）运行环境故障的影响,从而危及安全X T12已授权的内部用户或未经授权的局外用户可能会无意或故意导致安全相关的事件不被记录或可追溯 T12a丢失或覆盖合理的审计记录X T12b审计记录不能与发生时间关联X T12c审计记录不能与实际活动关联X T12d人们可能因为审计记录不被审阅而不会为自己的行为负责X T12e对用户或系统资源的危害可能在很长一段时间内未被发现XX T13体系架构、设计、实现、操作或维护中的脆弱性可能导致安全机制失效XX T14已授权的内部用户或未经授权的局外用户可能会导致不当重启和（或）从失败的硬件、软件或固件的不当恢复，而导致安全危害XX T15运行环境的变化可能会引入或暴露漏洞X T16一个知识渊博的攻击者可能绕过应对策略和缓解策略中意想不到的局限性或潜在缺陷XX T17访问控制权和访问特权的定义、实现和强制访问可能以破坏安全性的方式完成X T18自然灾害、战争行为或恐怖主义可能导致关键操作被中断或停止X T19资产的危害可能由管理员或其他特权用户的粗心,故意忽视或恶意执行导致 T19a硬件、软件和固件的操作不当XX 续表 编号威胁TOETOE环境 T19b网络或语音电路故障X T19c过早关闭永久虚拟电路(PVC) 或虚拟专用网络(VPN)X T19d操作安全(OPSEC)程序规程不足X T19e操作安全(OPSEC)程序规程写得不严谨X T19f用户和管理员不熟悉安全操作(OPSEC)程序规程X 第4章的表4.12已经为每个威胁分配了一个减轻风险的优先级。ST编制者可以表4.12作为识别ST威胁的输入，分析TOE安全架构设计方案(技术、操作或规范)部署后的每个威胁潜在的安全风险。本质上，这种安全风险分析是对TOE开发者给出的安全架构鲁棒性、可恢复性等设计解决方案的评估。从CEM看，只有做出了这样的评估，ST的概要规范原理解释部分才会基于这些评估说明其安全要求的合理性。表5.12使用第4章的表4.12作为输入举例说明了这一过程。表中有关风险程度说明参见第4章的4.5.2节内容。 表5.12ST威胁残余风险评估(参考Herrmann 2002) 编号威胁后果 严重性发生 可能性风险减低 优先级残留 风险 T1未检测出的资产威胁可能来自于以下事件 T1a授权用户执行了他未被授权的操作一般~关键偶尔高低 T1b攻击者（内部或外部人）伪装成一个授权用户尝试执行未被授权的操作一般~关键偶尔高低 T1c攻击者（内部或外部人）通过冒充授权用户访问未经授权的资源和信息一般~关键偶尔高低 T1d授权或未经授权用户无意或故意阻止组织员工访问TOE 一般~关键偶尔高低 T1e未经授权的用户获得了TOE控制权一般~关键很少中至高低 T1f未经授权的用户将TOE设置为不可操作一般~关键很少中至高低 T1g未经授权的用户试图绕过TOE的安全控制一般~关键频繁中至高低 T1h未经授权的用户试图猜测身份标识及其验证数据一般~关键频繁中至高中 T1i未经授权的用户通过欺骗等手段获得和使用有效的身份标识及其验证数据一般~关键很有可能中至高低 T1j未经授权的用户或外部IT实体查看、修改和删除传输到远程授权用户或管理员的安全相关信息一般~关键偶尔中至高低 T2授权用户在未获得 管理员许可情况下即访问该信息或资源一般~关键很少中低 T3攻击者可以窃听或用其他方式获取通过网络传播的数据 T3a未经授权的用户进行流量分析一般很少低低 T3b授权或未经授权的用户使用之前信息流的残余信息一般很少低低 续表 编号威胁后果 严重性发生 可能性风险减低 优先级残留 风险 T4授权或未授权用户通过消耗全局资源方式以阻止其他授权用户访问或使用这些资源 T4a借助网络/线路阻塞 （声音或数据）一般~灾难很少高低 T4b借助服务拒绝（DoS）和分布式服务拒绝（DDoS）攻击（声音或数据）一般~灾难很少高低 T4c盗窃资源服务一般~灾难很少高低 T5用户可能有意或无意地传输敏感信息给不允许看到它的用户一般~关键很少中低 T6用户可能或者以发送者或者以接收者的身份参与信息传输,随后否认这样的行为一般很少低低 T7授权用户可能以软复制或硬复制的方式导出信息，随后接受者不符合指定安全方式处理这些信息一般~关键偶尔高低 T8信息的完整性和可用性可能由于以下原因被削弱 T8a用户错误、固件错误、硬件错误或传播错误一般~灾难偶尔高低 T8b由攻击者的未经授权的修改或破坏的信息一般~灾难很少中低 T8c人为错误或软件、固件、硬件或电力供应故障造成突然中断操作,导致关键数据的损失或损坏一般~灾难很少中低 T8d存储介质老化或不当储存或不当处理存储介质一般~灾难很少中低 T8e一个授权用户无意中将病毒引入系统一般~灾难频繁高中 T8f一个授权用户能将未经授权的软件引入到系统中一般~灾难频繁高中 T8g授权或未经授权用户插入恶意代码或使用后门一般~灾难偶尔中低 T8h一个未经授权的人浏览、修改或破坏安全关键配置信息一般~灾难偶尔中至高低 T8i未能执行足够的系统冗余或数据备份一般偶尔中低 T8j偶然或者蓄意删除一般~关键偶尔中至高低 T8k插入伪造数据一般~关键偶尔中至高低 T8l对数据进行未经授权的修改一般~关键偶尔中至高低 T9攻击者可能在某用户希望其对资源或服务的合法使用保密的情况下，观察该用户对资源或服务的使用情况 一般~关键偶尔高低 T10一个授权用户可能有意或无意地观察存储用户未授权的信息一般~关键偶尔中低 T11安全关键组件可能受到物理攻击和(或)运行环境故障的影响,从而危及安全不重要 ~灾难几乎 不可能低低 T12已授权的内部用户或未经授权的局外用户可能会无意或故意导致安全相关的事件不被记录或可追溯一般~灾难很少中 T12a丢失或覆盖合理的审计记录一般~灾难很少中低 续表 编号威胁后果 严重性发生 可能性风险减低 优先级残留 风险 T12b审计记录不能与发生时间关联一般~灾难很少中低 T12c审计记录不能与实际活动关联一般~灾难很少中低 T12d人们可能因为审计记录不被审阅而不会为自己的行为负责一般~灾难很少中低 T12e对用户或系统资源的危害可能在很长一段时间内未被发现一般~灾难很少中低 T13体系架构、设计、实现、操作或维护中的脆弱性可能导致安全机制失效一般~关键很少中低 T14已授权的内部用户或未经授权的局外用户可能会导致不当重启和(或)从失败的硬件、软件或固件的不当恢复，而导致安全危害一般~关键很少中低 T15运行环境的变化可能会引入或暴露漏洞一般~关键很少低低 T16一个知识渊博的攻击者可能绕过应对策略和缓解策略中意想不到的局限性或潜在缺陷一般~关键很少中低 T17访问控制权和访问特权的定义、实现和强制访问可能以破坏安全性的方式完成一般~关键很少中低 T18自然灾害、战争行为或恐怖主义可能导致关键操作被中断或停止一般~灾难几乎 不可能低低 T19资产的危害可能由管理员或其他特权用户的粗心,故意忽视或恶意执行导致 T19a硬件、软件和固件的操作不当一般~灾难很少中中 T19b网络或语音电路故障一般~灾难很少中低 T19c过早关闭永久虚拟电路（PVC）或虚拟专用网络（VPN）一般~灾难很少中低 T19d操作安全（OPSEC）程序规程不足一般~灾难很少中低 T19e操作安全（OPSEC）程序规程写得不严谨一般~灾难很少中低 T19f用户和管理员不熟悉操作安全（OPSEC）程序规程一般~灾难很少中中 5.5.3组织安全策略 本部分引用4.5.3节PP定义的组织安全策略(OSP)。OSP包括TOE安全操作相关的规则、规范，以及一个机构为了保护其资产而推行的一系列TOE安全操作指南。依据行业、国家或是国际相关的法律法规都可推导出新的OSP。为了遵循这样的法律法规的正确版本，给出OSP引用的出处对于IT产品消费者和评估者理解是很有用的。 OSP对每个组织的使命和资产来说都是相当重要的。TOE消费者是这些OSP的拥有者。因此，ST编制者只能在PP规定的OSP基础上执行规定的操作。 (1) OSP可能简单地只是逐字重申PP中相应的规则、规范或指南。 (2) 只要原始意图不变，ST中的OSP可以为了贴近TOE的实现细节而进行定制。 引用PP中的OSP在ST中是不能够随意增加或是删除的。为了能够更加清晰，ST中的OSP是可以被指定给TOE或是TOE环境。如果ST是描述一个组件TOE，那么只有适用于这个TOE部件的OSP才是必须进行明确说明的。 5.6安 全 目 的 ISO/IEC TR 15446 技术报告并不建议ST编制者盲目地重复叙述PP中已经描述的安全目的，TOE开发者应当结合其具体的IT产品体系架构、安全架构和安全功能实现技术与机制，充分地分析PP中的每个安全目的以做出以下决定。 (1) 确认PP描述的每个安全目的在ST第4部分是否仍有效。如果是，安全目的应当被一字不差地复制到ST中。如果不是，这一安全目的应当被删除、修改、重新分配或重新分类。 (2) 是否应当添加一个新的安全目的？ 通常，PP文档中TOE安全目的一般应在ST相应结构部分重复出现，但ST编制者需要结合TOE具体实现技术与机制对PP中的安全目的进行必要的修改，以保持与ST中TOE描述部分相关细化内容一致。但是，如果PP中定义的一些安全目的不再合适或与TOE开发者在ST中建议的安全方案不兼容，那么这些安全目的在ST中应被删除或需结合ST安全架构的具体细节进行重写。相对于ST所引用的PP，如果在ST的第3部分有添加或裁剪的假设、威胁或组织安全策略，也可能需在ST中添加一些新的安全目的。另外，按照TOE安全目的是为了对抗潜在的威胁或满足TOE使用者的组织安全策略，ST中的安全目的也细分为预防、检测或纠正等类型。因此，其他为适用于TOE或TOE环境而定义的安全目的，也应该依据需要细分为预防、检测或纠正安全目的。 ST安全目的的作用有三方面。 (1) 为TOE安全问题提供高层的、以自然语言描述的安全方案： 安全目的使用自然语言描述，这一抽象层次对于知识丰富的TOE潜在消费者而言将会是清晰和可理解的。 (2) 将安全方案分为两类，分别称为TOE安全目的和TOE运行环境安全目的，以反映出这个解决方案是由TOE本身实现、TOE运行环境提供还是由TOE和TOE运行环境一起提供。 (3) ST中的安全目的的原理说明证实上述两种安全方案构成了一个对PP/ST中TOE所有安全问题的完整解决方案。 5.6.1TOE安全目的 TOE安全目的是解决ST文档中第3部分定义的TOE相关威胁和组织安全策略，由TOE本身应该实现的安全目标陈述组成。 TOE安全目的示例如下。 (1) TOE应保证在它和网络服务器或其他IT系统之间所传输数据或文件内容的保密性和完整性。 (2) 在允许TOE用户访问TOE提供的传输服务之前，TOE应该标识和鉴别这个用户。 (3) TOE应该根据ST附录3中描述的数据访问策略，通过它的数据访问引擎限制鉴别用户对相关数据资源的访问。 如果TOE在部署上是物理分布的，最好将ST中的TOE安全目的按照部署拓扑结构将TOE安全目的和部署划分对应起来，并以子章节方式对相关的安全目的进行描述。 5.6.2运行环境安全目的 TOE运行环境应提供一些非TOE本身的IT技术和操作规程方面的措施，以帮助TOE正确提供(由TOE安全目的定义的)安全功能。该局部的安全目的解决方案被称为TOE的运行环境安全目的，是由一组TOE的运行环境IT技术应该达到的安全目标陈述组成。 运行环境安全目的示例如下。 (1) TOE运行环境应提供安装了版本为13.01b的某操作系统的工作站来运行TOE。 (2) 在允许操作TOE之前，TOE运行环境应确保所有TOE用户接受适当培训。 (3) TOE运行环境应限制管理人员和由管理人员陪同的维护人员对TOE的物理访问。 (4) 在将TOE审计日志发送给中央审计服务器之前，TOE运行环境应保证这些TOE运行日志文件内容的保密性。 如果TOE的运行环境由多个场所组成，每个场所可能都有不同的安全特性，ST编制者最好将运行环境安全目的的ST章节划分为几个子章节来反映这种场所分布情况。 5.6.3安全目的原理 安全目的原理是为了证实ST第4部分里声明的TOE安全目的和运行环境安全目的已经响应了ST第3部分里描述的TOE安全问题。换句话说，ST第4部分应说明安全目的与安全问题定义之间的依赖关系，它分为两部分。 (1) 追溯部分： 用于描述每个安全目的分别处理哪些威胁、组织安全策略和假设。 (2) 证明部分： 用于论述所有的威胁、组织安全策略和假设都可以被相应的TOE安全目的或运行环境安全目的有效处理。 追溯部分说明了安全目的如何映射到安全问题定义中描述的威胁、组织安全策略和假设，包括但不限于以下几个方面。 (1) 没有无效的安全目的： 每个安全目的至少追溯到一个威胁、组织安全策略和假设。 (2) 完全覆盖了安全问题定义： 每个威胁、组织安全策略和假设至少可由一个安全目的覆盖到(即全部安全问题都有了解决方案)。 (3) 正确追溯： 由于假设总是围绕着TOE运行环境中的TOE，所以TOE安全目的不能追溯到假设。CC允许的追溯关系 如图5.7中所描述。 图5.7安全目的和安全问题定义间的追溯 多个安全目的可以追溯到相同的威胁，表明这些安全目的共同对抗该威胁。对组织安全策略和假设也是如此。 安全目的基本原理也应证实追溯是有效的： 如果所有安全目的对特定的威胁、组织安全策略和假设的追溯都已完成，那么所有给定的威胁、组织安全策略和假设均被处理(如，分别被对抗、被实施、被支持)。 该证实分析实现对抗威胁、实施组织安全策略和支持假设的相关安全目的的效果，并且得出确实如此的结论。 在某些情况下，部分安全问题定义与某些安全目的很相似，此时证实可以很简单，如： 威胁“T17： 威胁主体读取了A和B之间的机密信息”，TOE的一个安全目的“OT12： TOE应确保A和B之间所有传输信息保持保密性”，证实“T17直接由OT12与之对抗”。 表5.13给出了安全目的追溯原理。 表5.13安全目的追溯原理 例1： TOE安全目的原理 O1这一安全目的对抗威胁T1(重演)。O1需要TOE来防止验证数据的重用——即使取得了有效的验证数据，也不能用来发动攻击。 O2这一安全目的对抗威胁T2和T3(欺骗和残留信息)。O2需要： (a)所有的TOE信息流被先行协调； (b)没有残留信息被TOE内部或外部发送。 O3这一安全目的对抗威胁T4(TSF攻击)。O3需要TOE来保护自己不受绕开、停用或TOE安全攻击篡改的尝试。 例2： 安全目的到威胁的追溯 安全目的 威胁 T1T2T3T4 O1X O2XX O3X 例3： 运行环境安全目的原理 O4这一非IT安全目的对抗威胁T5(使用)。O4需要TOE在一个安全的方式下被交付、安装、管理。 O5这一非IT安全目的对抗威胁T5(使用)。O5需要认证管理员和用户定期接受合适的训练： (a)TOE的安全使用； (b)任一残留风险。 残余的安全目的是一个TOE安全环境假设的重申。 例4： 环境安全目的到假设的映射 安全目的 威胁假设 T5A17A18A21 O4X O5X O6X O7X O8X 例5： 假设的合理性论据 TOE 3个安全假设(A15、A19、A20)在这一ST里被修改。由于特殊的TOE硬件和软件平台，所以更详细的假设是必须的。然而，修改后的假设应维持PP中原始意图。 PP里的安全目的O23和威胁T17不再适用于这一ST，因为只有TOE的个人用户才能是认证系统管理员。不存在终端用户。 表5.13中，例1给出了每个TOE安全目的为什么能对抗相关威胁的充分和必要说明。一个安全目的可能映射到一个或多个威胁； 同样地，可能不止一个安全目的会映射到相同的威胁。这一讨论反映到例2的安全目的到威胁的追溯汇总表，从该表描述的安全目的和安全问题映射可以确保所有的假设、威胁和组织安全策略都被考虑到了。例3讨论了为什么每个运行环境安全目的能充分地对抗相关威胁。在这一示例中，两个安全目的映射到同样的威胁，几个假设被用来证明提出的安全目的是合理的。这一讨论反映到例4的运行环境安全目的到威胁和假设的追溯汇总表。 安全目的原理论据也必须解释和证明为什么PP里包含的某些假设、威胁、组织安全策略和安全目的，要么被裁剪，要么不包含在ST里。ST编制者必须提供关于修改或排除PP中安全问题或安全目的的有效技术或操作原因。当然ST中所有新的假设、威胁或安全目的的合理性也必须被证明。例5举例说明了两个可能的应用场景。 根据安全目的和安全目的基本原理，可以得出下列结论： 如果所有安全目的都可实现，那么就解决了在ASE_SPD(安全问题定义)中定义的所有安全问题，因为所有的威胁都被应对了，所有的组织安全策略都将得到TOE组织的实施，而所有的假设也都得到了TOE运行环境安全目的的支持。 5.7扩展组件定义 一般情况下ST中的安全要求都可用源自于CC第2部分和第3部分的标准安全功能和安全保障组件来描述，并按照CC允许的组件元素操作，依照TOE实现相关的技术和机制，对选择的安全组件进行定制，从而给出满足TOE安全目的的解决方案。然而，在某些情况下，ST中的某些安全要求可能不能通过对CC第2部分和第3部分的组件元素进行操作而得到。因此，PP/ST编制者可通过新组件(扩展组件)定义来描述TOE特定的安全要求。ISO/IEC TR 15446 技术报告建议这些特定的安全要求应该在PP/ST的第5部分“扩展组件”一节集中进行定义，这样在PP/ST第6节的“安全要求”中引用这些扩展组件就可描述TOE特定的安全要求。有关扩展组件定义可参见第4章PP中扩展组件定义的相关说明，扩展组件定义结构要求与CC预定义的安全组件结构相同。 是否要在CC安全功能组件、安全保障要求或预定义评估保障级别中对IT产品安全进行增强或扩展也由TOE消费者决定，TOE开发者提供的TSF增强与扩展只能为采用CC/CEM评估的消费者提供IT产品选择或合同采购的依据。但TOE开发者和TOE评估者在增强与扩展安全功能和保障组件的元素操作上应遵循CC组件元素定制相关操作要求。 5.8安 全 要 求 CC第1部分的附录A规定在ST第6部分描述TOE安全要求，并对TOE安全要求进行原理性解释。TOE安全功能应针对安全功能要求和安全保障要求分开描述。 5.8.1安全功能要求 TOE安全功能要求是由ST第4部分的TOE安全目的导出的一个详细但抽象的安全功能行为描述，并且以CC安全功能组件形式表述TOE用户对TSF行为的期待。CC要求ST编制者在这部分概述满足所有TOE安全目的的安全功能要求(TOE安全目的必须被TOE安全功能组件完全对应)。因此，安全功能组件的选择应参照ST定义的TOE安全目的，参照CC第2部分安全功能族设想的安全目的，通过与TOE安全目的对应关系确定TOE应具备的安全功能组件。对于一个组合TOE，ST编制者需指明适用于TOE安全目的的相关TOE部件的安全功能组件。CC要求PP/ST编制者使用组件这个术语，且由TOE安全目的导出TOE安全要求有两个理由。 (1) 提供比较准确的规范化评估内容描述： 因为TOE的安全目的一般用自然语言描述，转化为规范化的CC安全功能组件使得TOE安全功能行为描述更加准确。 (2) 允许用户比较不同的ST安全方案： 不同的PP/ST作者可能使用不同的术语描述他们的安全目的，但他们都得使用CC标准化的安全组件术语和概念来表达他们TOE的安全功能要求。这使得我们容易比较不同TOE开发者提供的IT产品安全功能。 ST编制者需要响应符合性声明中描述的引用PP的安全要求，ST编制者可能需要做到以下几点。 (1) 简单地逐字重申PP中的SFR(如果ST是针对一个TOE部件的，选择适用的SFR)。 （2） 完成PP中安全功能组件未执行的元素操作。 （3） 解决PP中未解决的组件依赖关系。 （4） 细化或反复功能组件操作来反映ST所建议的安全方案。 （5） 明确PP中未提供的审计要求。 （6） 添加由于ST的实现依赖特性而必须添加的新SFR。 （7） 忽略非必要的、冗余的或冲突的SFR。 上述的后6项给ST编制者提供进一步分解PP安全功能要求的机会，包括添加TOE实现细节相关的新的安全模型、安全技术、安全机制等TOE特殊安全功能要求的机会。 5.8.2安全保障要求 TOE消费者通过PP确定了合适的评估保障级别和相应的安全保障要求组件后，ST编制者可简单地重申PP中的安全保障要求，即按照CC第3部分安全保障组件格式陈述TOE开发者的行为要求、证据内容与格式要求以及评估者行为要求，以表示他们理解TOE需要执行的安全保障要求的特性和范围。(如果由于某些原因，TOE开发者得出结论认为PP指定的EAL是难以达到的、过分的或过弱的，这将在ST的第2节的符合性声明原理部分讨论。) ST编制者有两种方法增强TOE的安全保障要求。 (1) 通过组件元素操作： 该机制允许ST作者定义个性化的安全保障要求。CC第1部分文档中定义了4种组件元素操作，赋值、选择、反复、细化，其中在SAR中可运用反复和细化两种操作对安全保障组件元素进行增强。 (2) 通过组件间依赖关系： 该机制支持ST编制者对SAR进行更全面的分析和挖掘，找出潜在的安全保障组件。在CC第3部分中，某个SAR可以有对其他SAR的依赖关系，这表示如果ST使用了该SAR，那么，它一般也需要使用另外一些依赖的SAR。对于ST作者来说需要更大的努力以便在TOE中包含PP中未能明确的必要的SAR，从而提高ST安全保障要求的全面性。 另外，选择CC第3部分的预定义评估保障级别应注意以下两点。首先，预定义评估保障级别仅适用于CC推荐的评估配置； 用户可在PP/ST中通过扩展组件增加TOE可选安全功能或增强保障级别以满足自己的特殊安全要求。其次，TOE开发者是依照ST设计和开发IT产品的，而不是依据TOE消费者编制的PP构建，所以CC测试实验室对TOE安全评估的依据是ST，而不是ST参考的PP。 5.8.3安全要求原理 ST编制者在安全要求原理部分证明TOE安全要求响应并满足了ST第4节的所有TOE安全目的。特别是，以下安全要求基本原理必须被证实。 (1) 安全要求组合是必要的、充分的和互相支持的。 (2) TOE安全功能和安全保障组件集合满足ST里声明的所有TOE安全目的。 (3) TOE特定的SFR和SAR的选择原理必须证明是合理的，特别地： ①扩展组件(TOE特定安全要求)的使用； ②预定义评估保障级别增强和扩展； ③TOE中未满足组件依赖关系的解释。 安全要求原理就是通过必要性、充分性和相互支持性3个方面对5.8.1节安全功能要求和5.8.2节安全保障要求进行说明。换句话说，安全原理部分必须证明ST中的所有安全要求是必要的、充分的和相互支持的。ST编制者一定要关注TOE安全目的或安全要求之间的不匹配应当在这部分的安全要求原理中描述，例如相对于PP定义新的安全目的或安全要求或对其进行裁剪操作，都需要从必要性、充分性和相互支持性这3个方面进行讨论。 1. 必要性说明 为了证明TOE安全要求是必要的，TOE开发者必须证实ST中每个安全要求(SFR和SAR)是必需的，并且不包含冗余的和额外的安全要求，即所有的TOE安全要求都必须与TOE安全目的相一致。一个简单的安全要求必要性证实方法是通过一个TOE安全目的到安全要求需求的交叉引用表来检查TOE安全目的和安全要求之间的映射关系。 2. 充分性说明 充分性说明是指通过构建形式化论据来解释为什么安全要求能充分满足TOE安全目的。所有的安全要求都应被检查： 标准的SFR和SAR、扩展的SFR和SAR。ST编制者要特别关注ST中对安全组件元素的相关操作： 如何以及为什么要对安全组件执行这些元素操作。充分性分析也可以通过验证特定级别的审计事件是否已经达到(查看表5.14和表5.15)来完成。 表5.14安全要求原理必要性原理论据 4.6.1安全要求原理 4.6.1.1SFR必要性 下面的文本叙述和表格描述了ST满足PP里指明的SFR。 FDP_IFC.1+1.子集信息流控制 这一组件定义了信息流控制TSP中非身份验证机制涉及的实体，使用除了HTPP、SMTP、FPT和远程登录之外的所有网络服务。这一组件可追溯到安全目的O21，并辅助安全目的O21的实现。 FDP_IFC.1+2.信息流控制子集 这一组件定义了信息流控制TSP中身份验证机制涉及的实体。这一组件可追溯到安全目的O21，并辅助安全目的O21的实现。 FDP_IFF.1+1.简单安全属性 这一组件定义在非用户身份认证TSP中发送和接收信息的用户属性，包括信息自身的属性。该策略规定了FDP_IFC.1+1组件功能必须执行的一些规则，并描述该功能如何得到安全属性。这一组件可追溯到安全目的O22，并辅助安全目的O22的实现。 FDP_IFF.1+2.简单安全属性 这一组件定义在认证TSP中发送和接收信息的用户的属性，还有信息自身的属性。通过允许或限制信息流来实施这一策略。这一组件可追溯到安全目的O22，并辅助安全目的O22的实现。 下表总结了SFR和安全目的之间的映射。 SFR映射到安全目的 SFR安全目的O21安全目的O22 FDP_IFC.1+1X FDP_IFC.1+2X FDP_IFF.1+1X FDP+IFF.1+2X 表5.15安全要求： 审计事件原理说明 4.6.1.x审计事件原理 ABC提供的审计事件被按照审计事件最低或基础审计级别功能需求检查。ABC在所有领域的应用功能提供可审计事件，只去除了导出、导入、保密性和完整性。这是因为对ABC来说上述四类审计活动是不合适的，因为在两个ABCs之间发送的所有用户数据消息： (a)使用了一个完整性检验； (b)被加密以确保保密性； (c)只从两个ABCs导入或导出。对于ABC这些是日常活动，因为涉及大量数据，没有必要对其审计。因此，“未指定”被审计级别选择并且所有审计事件被列举。 SAR的充分性评估是以确定CC预定义评估保障级是否是适合以及任一增强和扩展是否进行了恰当的说明。某个具体EAL的充分性论据证明包括： ①EAL既不过强也不过弱； ②考虑到TOE实现细节和技术的当前状态在技术上是可行的。表5.16举例说明了EAL 2的一个安全保障必要性和充分性论据。 表5.16安全要求： SAR必要性与充分性 4.6.2保障要求原理 该安全目标满足保护轮廓中定义的SAR。该文档的4.6.2节给出了满足EAL 2的系统开发过程、指南文档、生命周期支持、测试和脆弱性评定保障措施要求。 选择EAL 2是为了提供一个低到中等级别的安全性保障。这个保障级别与下列假设的安全威胁模型一致： 恶意攻击是中等的，且产品经过了一个详细的缺陷搜索。 3. 相互支持性说明 安全原理第3部分也需要证实安全要求之间是相互支持的，目的是证实IT安全要求的完整性和一致性。这种相互支持性一般通过以下3步骤完成。 (1) 分析组件的依赖关系是满足的。 (2) 分析安全要求内容是内部一致性。 (3) 分析SFR对攻击的积极抵抗能力。 组件依赖分析检验所有3个可能的依赖组合： SFR与SFR、SFR与SAR和SAR与SAR之间的依赖是否满足。组件依赖关系的描述可通过参考CC第2部分和第3部分的组件定义来确定。为了保证TOE安全要求的完整性，当基于具有依赖关系的组件的要求被合并到PP/ST中时，它们之间的依赖关系应该被满足。构造组件包时，包编辑者也应该对这些组件依赖关系进行分析。 ST编制者必须依照CC对各个SFR/SAR的每个依赖关系进行分析研究，证明哪些组件依赖关系被考虑，并指出哪些组件依赖关系未满足。对所有未满足的依赖关系必须提供一个理由，解释了在PP/ST中为什么没必要包含这些依赖组件支持的需求。潜在的原因可能是ST中包含的实现细节使得需求不必要，或者支持的需求功能被TOE运行环境需求满足(如数据库产品的时间戳安全功能组件一般由支撑其运行的操作系统支持)。组件依赖分析的结果可通过一个表格总结来补充说明，如表5.17所示。 内部一致性分析证实ST中没有重叠的、冲突的或有歧义的安全需求。组件结构中的审计需求、管理需求、组件反复和元素操作等因素都在内部一致性分析的范围内。如果ST是某个组合TOE的一个TOE部件，那么与这些ST相关的TOE部件对象也应当被作为内部一致性分析的一部分进行评估。这些内部一致性分析的结果应通过相关表格总结以补充相关的文本信息。 SFR对攻击的积极抵抗能力分析可关注下列关键因数。 (1) 不可旁路性(如内存管理机制)。 (2) 抗篡改(实施自我保护)。 (3) 安全攻击检测能力。 (4) 安全攻击可探测性等。 首先针对前两个因数，在CC/CEM v2.X中定义了不可旁路性(FPT_RVM.1)和安全功能域的隔离(FPT_SEP.1)两个安全功能组件，包括TSF物理保护(FTP_PHP)和安全属性的管理(FMT_MSA.1)组件来一起积极地抵抗各种安全攻击。但由于它们仅描述了TSF 最低安全保障相关的一些属性，所以这两个因数在CC v3.1中由ADV(开发)类的ADV_ARC(安全架构)保障要求族负责处理。ADV_ARC 族要求充分描述TSF 的安全架构，并且充分说明TSF是如何保证不被旁路和如何保护它本身的。CC将这两个功能要求修改成保障要求的原因是由于在过去的TOE安全评估中缺乏一种可以理解的方法去阐述不可旁路性(FPT_RVM.1)和安全功能域的隔离(FPT_SEP.1)评估原则。因而在CC v3.1中，ADV_ARC 族要求TOE开发者必须提供TOE安全架构描述信息，必须提供相应的TOE设计和功能规范等评估证据以供TOE评估者进行安全性分析(注： 表5.17未标注SFR与SAR之间的依赖关系)。 表5.17安全要求原理： 组件依赖分析 8.2.3组件依赖性分析 为完整起见，表8.1列出了ST中所有SFR组件，而不管他们是否具有 相关性。从表中看出，除了 FMT_MSA.3外，所有组件依赖关系都满足通用评估准则，这是由于静态属性初始化功能是由IT环境安全需求提供的： 用户属性设置(ITENV.1)和TSF数据修改(ITENV.2)。表中有两种依赖是由组件层次关系导出的： FDP_IFF.2对FDP_IFF.1有依赖和FIA_UID.2对FIA_UID.1有依赖。这两个基于组件层次的安全要求在表中依赖关系以H表示。 表8.1SFR和SFR组件依赖关系分析 序号组件标识组件名称依赖关系解决方案 1FAU_GEN.l审计数据产生FPT_STM.119 2FAU_SEL.1选择性审计FAU_GEN.1 FMT_MTD.l1 14 3FDP_ACC.1子集访问控制FDP_ACF.14 4FDP_ACF.l基于安全属性的访问控制FDP_ACC.l FMT_MSA.33 ITENV.l ITENV.2 5FDP_ETC.1不带安全属性的用户数据输出FDP_ACC.1或 FDP_IFC.l3 — 6FDP_IFC.1子集信息流控制FDP_IFF.17H 7FDP_IFF.2分级安全属性FDP_IFC.1 FMT_MSA.3— ITENV.l ITENV.2 8FDP_ITC.l不带安全属性的用户数据输入FDP_ACC.1或 FDP_IFC.1 FMT_MSA.3— 6 ITENV.l ITENV.2 9FDP_UCT.1基本的数据交换机密性FTP_ITC.1或 FTP_TRP.l FDP_ACC.1或 FDP_IFC.l21 — 3 — 10FDP_UIT.1数据交换的完整性FDP_ACC.1或 FDP_IFC.l FTP_ITC.13 — 21 11FIA_ATD.1用户属性定义无— 12FIA_UAU.2任何动作前的用户鉴别无— 13FIA_UID.2任何动作前的用户标识无— 14FMT_MTD.1TSF数据的管理FMT_SMR.117 15FMT_REV.1撤销FMT_SMR.117 16FMT_SAE.1时限授权FMT_SMR.l FPT_ STM.117 19 17FMT_SMR.1安全角色FIA_UID.113H 18FPT_ITI.1TSF间修改的检测无— 19FPT_STM.1可靠的时间戳无— 20FPT_TDC.1TSF间基本的TSF数据一致性无— 21FTP_ITC.1TSF间可信信道无— 5.9TOE概要规范 TOE概要规范(TSS)是TOE开发者用来描述为满足ST里声明的安全要求所采用的设计方法及其实现技术与机制。TSS描述的详细程度应该使潜在TOE消费者能够充分理解TOE安全功能行为及其实现技术与机制。 例如，如果TOE是一个互联网服务，其SFR包含的FIA_UAU.1指出用户身份鉴别需求，那么TSS就应该说明这个鉴别如何实现，如采用口令、令牌或人脸识别等不同的用户身份标识和鉴别方式。相对于ST第1部分的TOE安全描述，TSS会给出TOE更多开发和实现方法与技术机制有关信息，如TOE用于满足SFR的可适用标准，或者也可以提供更多安全功能要求实现的技术细节描述。 TOE概要规范一般通过跟踪矩阵来保证PP/ST安全要求实现的完整性和一致性。 (1) 满足ST第6部分中每个SFR的具体IT安全功能。 (2) 用于实现上述每个安全功能的准确的安全机制或技术。 (3) 满足ST第6部分里定义的SAR的准确的安全保障措施。 通过跟踪矩阵执行这一映射是为了确保以下两点。 (1) 所有的安全要求(SFR和SAR)都被TSS设计方法考虑到。 (2) ST没有引入新的非规范化安全功能说明。 ST第6部分的每个SFR都必须映射到TOE至少一个IT安全功能(TSF)； 同样地，每个IT安全功能都必须映射到至少一个SFR(参见图5.8)。 图5.8TOE概要规范映射 依据ST文档结构，TSS的一个安全功能可能对应于PP/ST中的一组安全功能组件。 之后安全功能被映射到TOE具体的安全技术或实现机制，安全保障措施被映射到具体的CC安全保障组件或组件集合(如预定义的EAL)。 ST的TOE概要规范描述一般包含3部分内容： TOE安全功能、TOE安全保障措施和TOE概要规范原理。 5.9.1TOE安全功能 TOE安全功能详细描述实现时IT厂商采用的具体安全技术与机制，以及由TOE执行的安全功能行为表现。在对TOE安全功能描述时，CC建议按照评估对象功能接口(TFI)类型情况来区分SFR执行、SFR支撑或SFR无关子系统或模块，然后再按照这些子系统或模块所完成的安全功能行为进行测试和评估。评估对象的3种功能接口类型的定义如下。 (1) SFR执行： 一个可以直接追溯到安全功能要求(SFR)的接口。如果通过一个接口可获得的安全服务能够被追溯到TSF的一个安全功能要求，则该接口被称为SFR执行。注意该接口可能有多种服务和反馈结果，其中一些可能用于SFR执行，另一些可能用于调用其他模块或服务，例如自主访问控制、用户身份鉴别等子系统或模块。 (2) SFR支撑： 一个支持TOE安全策略调用的接口。如果是SFR执行功能所依赖的，且只需正确运行以保持TOE安全策略的那些服务接口(或通过接口相关的服务)，则称其为SFR支撑，例如操作系统中的设备驱动、内存管理等子系统或模块。 (3) SFR无关： 一个没有SFR执行功能依赖的接口。即SFR执行功能不依赖的服务接口称为SFR无关。 应注意SFR支撑和SFR无关必须不依赖SFR执行服务或者SFR执行的结果。相反，SFR执行可能需要有SFR支撑服务(例如，设置系统时钟的能力可能是一个接口的SFR执行服务，但是如果同一个接口用作显示系统日期，那么该服务可能只是SFR支撑)。纯SFR支撑接口的例子是既被用户使用又为了用户利益而运行的一部分TSF使用的系统调用接口。例如在Linux操作系统中，通常仅部分内核实现安全执行机制(如自主访问控制、安全审计等)，而在内核域的设备驱动程序虽然不直接实现安全功能，但它们可能会导致产品的安全功能失效。因而，贡献于安全执行的设备驱动程序为SFR支撑，内核中也存在没有实现SFR的其他功能(例如，具备优化调度策略的负载管理器)，也没有安全功能依赖于它，因而这些机制是SFR无关的。针对应用程序也是相同的，Linux操作系统的passwd命令实现了更新用户口令的安全执行机制，这个应用包含了解析文件“/etc/passwd”的逻辑接口，它应属于SFR支撑，当这种解析逻辑任务失败时，更新用户口令的安全执行功能也会失败。 在ST中以类、族和组件的标准化形式组织这些TOE安全功能实现技术与机制，提高了TOE概要规范的可读性和可理解性。TOE和TSF之间有清晰的区别，需要与ST第1部分中定义的逻辑和物理边界一致。然而，如果TOE是一个只能执行安全功能的产品，TOE和TSF可能是完全相同的。另外，TSF控制范围(TSC)和TOE安全功能接口(TSFI)应被清楚地描绘。TSC是那些伴随或在TOE里发生的，受TOE安全策略定义的规则约束的各种交互接口(TSFI)集合。用户通过这些TSFI接口既可访问到受TOE保护的资源，又可从TSFI获取到TSF相关信息。因此，在TSS中需要详细阐述所有TSFI的目的与方法，描述每个TSFI的调用参数，并且要对每个TSFI依据其所完成的功能来划分为SFR执行TSFI、SFR支撑TSFI或SFR无关TSFI。例如在操作系统中，相关的TSFI可以是以下几种。 (1) SFR执行TSFI： 系统调用(open、msgctl)，应用的命令行(passwd、login)，配置文件(/etc/passwd,/etc/shadow)。 (2) SFR支撑TSFI： 非SFR执行TSFI的系统调用。 （3） SFR无关TSFI： 应用的命令行(ls、rm)，配置文件(vimrc)。 在TSS中阐明TOE安全功能可遵循以下5个步骤，每一步都应提供更详细的TOE安全技术或实现机制细节。所有这样的信息都必须满足ST保障评估(ASE)的完整性、一致性、连贯性、准确性和确定性要求。相应的文本描述都应当尽可能以图表形式来补充。 (1) TOE安全功能到CC的SFR的映射。 (2) 定义TOE安全功能之间的关系。 (3) 定义TOE安全功能的具体实现技术与机制。 (4) 说明TOE安全功能的安全审计需求的获取方法。 (5) 描述TOE安全功能的管理需求的实现方法。 表5.18举例说明了第一步。从安全技术层面，TOE包含6大类安全功能，按照它们的标识和名称被列入表格的前两个列。来自PP/ST的标准化SFR被映射到TOE相关的安全功能。ST第6部分的TOE所有SFR都必须映射到这部分的TOE安全功能： 来自PP的，由ST添加或修改的，针对TOE的SFR。如前所述，每个SFR都必须映射到至少一个TOE安全功能，同样地，每个TOE安全功能都必须映射到至少一个SFR。在该例中我们发现有3个SFR(表最后3个组件)没有与TOE安全功能对应起来，其他的SFR都映射到了一个且仅有一个TOE安全功能。因此，为了使某个IT产品的ST被TOE开发者认可，ST编制者必须完成以下3件工作。 (1) 在ST第7部分，即TOE概要规范，必须做一个声明来解释为什么这3个SFR中的安全组件没有被整合到TOE设计的安全功能中。 (2) 在ST第2部分，即PP声明，声明被引用的PP只能提供部分一致性。 (3) 在ST第7部分后面，即TOE概要规范最后解释排除这3个SFR的理由。 表5.18TOE安全功能说明第1步： TSF映射举例 标识名称来自PP/ST的SFR组 件 名 称 GRD_ADM安全管理 FMT_SMR.1安全角色管理 FMT_MOF.1安全功能行为的管理 FIA_ATD.1用户属性定义 GRD_INA鉴别与认证 FIA_UID.2任何动作前的用户标识 FIA_UAU.1鉴别的时机 GRD_FLO信息流控制 FDP_IFC.1子集信息流控制策略 FDP_IFF.1子集信息流控制 FDP_RIP.2完全残余信息保护 续表 标识名称来自PP/ST的SFR组 件 名 称 GRD_DFL默认配置 FMT_MSA.3静态属性初始化 ADV_ARC.1安全架构 FPT_STM.1可靠的时间戳 GRD_AUD安全审计 FAU_GEN.1安全审计数据生成 FAU_SAR.1审计查阅 FAU_SAR.3可选审计查阅 FAU_STG.1受保护的审计迹存储 FAU_STG.4防止审计数据丢失 无无 FIA_AFL.1鉴别失败处理 FIA_UAU.4一次性鉴别机制 FCS_COP.1密码运算 表5.19举例说明了TOE安全功能说明的第2步，它描述了TOE安全功能之间的层次关系，且列出了每个TOE安全功能的主要行为描述内容。在该例中，TSF包含5个功能组件： 安全管理、鉴别和认证、信息流控制、默认配置和安全审计。所有这5个TSF包都在同一层次，它们执行的功能独立。安全管理类包含7个功能，而信息流控制类只包含2个功能。 表5.19TOE安全功能说明第2步： TSF结构示例 1. TSF 1.1安全管理 1.1.1启动、关闭 1.1.2创建、写、编辑、删除、读信息流控制规则 1.1.3创建、写、编辑、删除、读用户属性 1.1.4设置日期和时间 1.1.5创建、删除、读、归档审计跟踪数据 1.1.6创建系统备份 1.1.7启动系统恢复 1.2鉴别与认证 1.2.1操作系统层次 1.2.2应用系统层次 1.2.3人员 1.2.4内部IT实体和过程 1.2.5外部IT实体 1.3信息流控制 1.3.1外部资源访问控制 1.3.2内部资源访问控制 1.4默认配置 1.4.1安全、生成和启动过程中流量阻塞 1.4.2安全、生成和启动过程中事务阻塞 1.4.3维护独立逻辑域的每个会话 1.5安全审计 1.5.1生成审计数据 1.5.2可选择审计数据检查 1.5.3保护审计存储 1.5.4预防审计数据丢失 表5.20举例说明了TOE安全功能说明的第3步，描述了实现每个安全功能的安全技术与机制，以及默认设置、约束、操作参数和算法细节。在该例中，实现TSF安全审计的安全技术与机制被指明。(注意在一个ST中，每个1.6.×.×条项可以包含几段到几页的具体实现技术与机制细节。) 表5.20TOE安全功能说明第3步： 映射安全技术与机制到TSF 1.6安全审计 1.6.1生成审计数据 1.6.1.1模块A生成监控信息，例如审计跟踪、安全事件日志和警告SNMP陷阱。 1.6.1.2模块B送模块A生成的审计跟踪、安全事件日志和警告给后台组件以进一步处理。 1.6.1.3为以下事件生成审计记录： TOE和TSF的启动和关闭； 对认证管理员角色的部分的群组用户的修改； 所有用户认证机制的使用，包含提供的用户身份； 所有认证机制的使用； 所有信息流请求的决定； 对允许或拒绝信息流的信息流安全策略规则的创建、写、删除、编辑和读； 创建、写、删除、编辑和读取用户属性； 设置和修改系统时间和日期； 归档、创建、删除、读和清理审计跟踪； 事务备份和恢复。 1.6.2可选择的审计数据检查 1.6.2.1XYZ工具有一个GUI，该GUI允许认证的系统管理员读取、检索和基于事件类型、日期与时间、IP地址范围排序审计记录。 1.6.3保护审计存储 1.6.3.1审计文件被安全文件系统（NTFS）保护。 1.6.3.2只有认证用户可以访问审计文件。 1.6.3.3NTFS检测对审计文件的尝试修改。 1.6.3.4NTFS记录成功和不成功的创建、读、写、编辑、删除、修改权限和（或）获得审计文件所有权的尝试。 1.6.4预防审计数据丢失 1.6.4.1如果系统不能够获取或记录审计数据，TOE和TSF操作停止。 1.6.4.2直到以上情形被纠正，只有认证系统管理员可能执行功能。 表5.21举例说明了TOE安全功能说明第4步，指明了安全审计需求层次和对每个适用的SFR可被审计和获取的审计事件细节。 表5.21TOE安全功能说明第4步： 审计需求示例 安全功能组件审 计 层 次审 计 事 件 FMT_SMR.1最小 对认证管理员角色的部分群组用户的修改 执行以上修改的认证管理员的身份 与认证管理员角色相关的用户身份 FIA_UID.2基本 所有对用户机制的使用 提供给TOE安全功能(TEF)的用户身份 FIA_UAU.1基本 所有对认证机制的使用 提供给TOE安全功能(TSF)的用户证书 续表 安全功能组件审 计 层 次审 计 事 件 FIA_AFL.1最小 未成功认证尝试阈值 认证管理员的用户认证能力的随后恢复 违规用户身份 执行恢复的认证系统管理员的身份 FDP_IFF.1基本 信息流请求的决定 源和目的体的推测地址 FPT_STM.1最小 系统时间的修改 修改系统时间的认证系统管理员的身份 TOE安全功能说明第5步是描述管理需求的实现方法。在CC第2部分中，安全管理类(FMT)组件定义了管理要求，TOE开发者可以从这个类中选择合适的那些管理要求，也可以开发新的管理需求。例如，针对FMT_REV.1包括以下管理行为： 管理： FMT_REV.1 FMT中的管理功能可考虑下列行为： (1) 管理能够调用安全属性撤销这一功能的角色组； (2) 管理可能发生撤销的用户、主体、客体和其他资源列表； (3) 管理撤销规则。 换句话说，CC第2部分建议管理①谁可以执行撤销功能； ②哪些实体是能作为撤销的主体； ③如何决定执行撤销的阈值。这3项与FMT_REV.1组件元素定义直接相关： FMT_REV.1.1TSF应仅限于 ［赋值： 已标识的授权角色］能够撤销在TSF控制下的与［选择： 用户、主体、客体、［赋值： 其他额外资源］］相关联的安全属性［赋值： 安全属性列表］。 FMT_REV.1.2TSF应执行规则［赋值： 撤销规则的详细说明］。 选择操作与管理行为条项(2)管理需求相关，而赋值操作与管理行为条项(1)和条项(3)管理需求相关。 如果考虑到撤销时间范围的管理需求，则ST编制者可能想要添加第4条管理行为： (4) 管理执行日常基础撤销的频率和执行一次应急基础撤销的时间。 为了这样做，就要在ST第5部分增加一个扩展组件，显式的定义下列元素要求： FMT_REV.1.3 TSF应当在5秒内执行需求撤销和完成事务。 TSS描述了TOE管理功能如何被实现。对于这里的例子，提供了以下关于固件/软件模块如何做到的细节。 (1) 撤销安全属性和什么属性会被撤销。 (2) 限制授权用户执行这一操作的能力。 (3) 在指定时间范围内执行撤销功能。 在CC第2部分的FMT类管理功能之间的交互也要被描述，尤其是所有的依赖关系。不选择管理需求的原理应该在ST的5.8.3部分里进行解释。 需要指出的是，管理需求可能在一个PP里被指明，尤其是如果客户有特殊的操作需求； 然而，考虑到管理要求与ST的实现依赖关系，最好是将管理需求的指定延迟到ST编制阶段。 5.9.2TOE安全保障措施 TSS描述用来满足ST里指明的每个SAR的具体安全保障措施，包括所有EAL增强和扩展相关的保障措施都需要在这一部分被重述。然后，组成EAL的每个保障类和族相关的安全保障措施应详细讨论。为了增强可理解性，图表相关的文本材料应尽可能都提供。特别地，应当提供一个矩阵来映射 SAR到具体的安全保障措施。此外，每个SAR都必须映射到至少一个安全保障措施，而每个安全保障措施都必须映射到至少一个SAR。 TOE开发者负责解释安全保障组件的开发者行为元素和内容与形式元素是如何满足每个SAR。TOE开发者没有责任考虑评估者行为元素的安全保障措施。然而，TOE开发者必须确保定义在评估者行为元素里的所有要求都应被满足，这是CC测试实验室用来确定ST是否通过评估验证的前提。对于EAL 2和以下保障级别的ST，安全保障措施可以引用现有的项目文档，例如配置管理过程，而不是重复CC里的信息。需要指出的是： ①必须在ST被提交正式评估前编制好这些项目文档； ②项目成员确实知道并且遵守评估相关文档的归档过程。 表5.22举例说明了在EAL 2和EAL 3两种场景下如何针对ADV_FSP.1保障组件来编写安全保障措施的文本描述。在第一个例子里，引用了现有的项目文档来满足需求； 在第二个例子里，开发者行为元素和内容与形式元素被反映。“应当”被替换为“将要”，也有其他一些必要的小的编辑修改，以告知TOE开发者需提供的安全保障方法。 表5.22示例TSS安全保障措施 例1： EAL 2(参照项目现有文档) 7.2.3AVD_FSP.1基本功能规范 下面列出的ABC功能规范，实现了AVD_FSP.1的安全保障要求： ABC功能规范，版本3.0,2015年3月31日。 例2： EAL 3 7.2.3ADV_FSP.1基本功能规范 下面列出的ABC功能规范，实现了AVD_FSP.1的安全保障要求： ADV_FSP.1.1D 开发者将要提供一个功能规范。 ADV_FSP.1.2D 开发者将要提供功能规范到安全功能要求的追溯关系。 ADV_FSP.1.1C 功能规范应描述每个SFR执行和SFR支撑的TSFI的目的和使用方法。 ADV_FSP.1.2C 功能规范应识别每个SFR执行和SFR支撑 的TSFI相关的所有参数。 ADV_FSP.1.3C 功能规范应提供暗含的SFR无关 的接口分类的基本原理。 ADV_FSP.1.4C 功能规范应证实安全功能要求到TSFI的追溯。 表5.23介绍了一个SAR到安全保障措施的示例映射矩阵。因为这一示例是针对EAL 2的，所以引用了现有的项目文件提供的功能和接口规范、指导性文档和TOE安全架构的基本描述，通过分析一个完整的ST中的安全功能要求来提供保障，以理解TOE安全行为。这种分析由对TSF的独立测试、TOE开发者基于功能规范自测试、对TOE开发者测试结果的选择性确认、证实可抵御具有基本攻击潜力攻击者攻击的脆弱性分析(基于功能规范、TOE设计、安全架构描述和提供的指南类证据)等证据来支持。 表5.23TSS安全保障要求与保障措施映射表 安全保障要求安全保障措施 ADV_ARC.1 提供TSF安全架构的描述文档 ADV_FSP.2 提供一个功能规范文档 提供功能规范到安全功能要求的追溯关系 ADV_TDS.1 提供TOE的设计文档 提供从功能规范的TSFI到TOE设计中最底层分解的映射 AGD_OPE.1 提供操作用户指南 AGD_PRE.1 提供TOE，包括它的准备程序文档 ALC_CMC.2 提供TOE及其标识 提供CM文档 ALC_CMS.2 提供TOE配置项列表： TOE本身、安全保障要求的评估证据和TOE的组成部分 提供对于每个TSF相关的配置项，配置项列表应简要说明该配置项的开发者 ALC_DEL.1 提供把TOE或其部分交付给消费者的程序文档化 提供应使用交付程序 ATE_COV.1 提供如何与功能规范中的TSF接口对应的测试文档 提供测试覆盖分析报告 ATE_FUN.1 提供应测试TSF，并文档化测试结果和测试规范 提供测试文档 ATE IND.2 提供用于有效地重现开发者的测试的必须材料，包括机器可读的测试文档、测试程序等 提供一组与开发者TSF功能测试中同等的一系列资源 AVA_VAN.2 提供公共领域的调查以标识TOE的潜在脆弱性 提供分析过程中使用的指导性文档、功能规范、TOE设计和安全架构描述 5.9.3TOE概要规范原理 TOE概要规范原理部分是说明TOE安全功能及其实现技术与机制和安全保障措施适合于满足TOE安全要求。特别地，必须证明以下3项要求。 (1) 给出的安全要求解决方案满足ST中的所有SFR。 (2) TOE开发者对TOE脆弱性分析声明是有效的。 (3) 给出的安全保障措施满足ST里的所有SAR。 TSS原理说明应覆盖ST前面所有的SFR，既包括从PP继承来的那些SFR，也涵盖由ST增加或裁剪的那些SFR，但不包括由ST删除的那些PP中的SFR。同样地，所有的SAR也都在TSS原理论证范围内，包含增强和扩展的SAR。相互支持性应采用同样的准则，以便用来生成必要的、充分的和互相支持的TSS论据。 5.6.3部分论证了TOE安全目的和假设、威胁和组织安全策略之间的一致性、准确性、完整性和相关性； 5.8.3部分论证了TOE安全目的和安全要求之间、安全要求之间的一致性、准确性、完整性和相关性。本节主要通 图5.9TOE概要规范原理论证 过提供缺失的安全问题、安全目的、安全要求和安全技术与机制这个链接完成图5.9所示的映射关系证明： ①安全技术与机制和安全要求之间的； ②安全技术与机制之间的一致性、完备性、完整性和相关性。 安全要求与安全技术与机制，以及安全技术与机制之间的相关性证明可使用CC/CEM推荐使用的用于证明安全目的和安全要求之间的相关性的相同过程来证明(参见5.6.3和5.8.3节内容)。ST第6部分的每个SFR都被映射到TSS部分TOE实现特定功能的具体安全技术与机制。所有的SFR必须映射到至少一个安全技术与机制，而每个安全技术与机制都必须映射到至少一个SFR。不应该存在任何没被映射的SFR或安全技术与机制。通过构建这样的映射关系(如图表方式)来确保以下几点。 (1) 没有SFR未对应的安全技术与机制，以避免造成潜在的安全脆弱性/缺陷。 (2) TOE实现安全技术与机制中没有遗漏ST中的SFR。 (3) 不会因为TOE实现细节需要而导致安全要求分解时引入可能的脆弱性/缺陷。 (4) 给出的TOE安全要求设计与实现解决方案充分、稳定且有一定灵活性。 TSS必要性准则也是采用安全目的和安全要求那样的方式，通过表格映射形式来证实。充分性和相互支持性准则一般通过文本方式描述。相关表达方法可参照安全目的和安全要求原理部分编制： 通过表格形式描述映射关系，以论证必要性，通过自然语言陈述来论证充分性和相互支持性。 总之，本节的目标是ST编制者通过组合TOE的各种安全技术与实现机制,来论证前面给出TOE安全目的导出的相关安全要求可以得到满足，以便在ST中给出TOE安全功能实现解决方案和相关的安全保障控制措施是有效的结论。 5.10本 章 小 结 TOE开发者主导编制的ST文档是响应IT产品消费者安全需求(PP)，与实现相关的某个具体IT产品的安全方案，它也是某个IT产品厂商针对具体IT产品安全规范的描述文档。因此，TOE评估发起者在启动该IT产品的CC认证前，会按照ISO/IEC TR 15446 技术报告编制IT产品相应的ST。 ST包括引言、符合性声明、安全问题定义、安全目的、扩展组件定义、功能和保障要求和TOE概要规范这些内容。ST是被IT产品开发者用作TOE开发和评估的基础。换句话说，PP从TOE消费者角度指明了IT产品安全功能和保障要求，而ST从TOE开发者角度提供了IT产品安全功能具体实现技术与机制，包括安全保障措施的详细解决方案，以给TOE消费者提供可能的IT产品选择方案。因此，ST可以回答以下问题(或更多)。 (1) 如何能够在多个已评估的ST/TOE中找出IT产品用户所需的ST/TOE？该问题由ST引言部分的TOE功能概述和TOE安全描述两部分内容组成，其中ST编制人员给出了目标IT产品的通用功能和安全功能的简要描述。 (2) TOE是否适合IT产品用户现有的IT运行基础设施环境？该问题由ST引言部分的TOE功能概述阐述，其中标识出了运行TOE所需要的硬件/固件/软件元素。 (3) TOE是否适合IT产品用户现有的运行环境？这个问题由ST第3部分的运行环境安全目的进行阐述，其中标识了TOE为发挥安全功能作用所需的运行环境相关约束条件。 (4) TOE能做什么?该问题由ST安全目的部分阐述，其中ST编制人员给出了TOE安全目的和运行环境安全目的，ST编制人员以简明抽象的方式对TOE安全问题定义中所定义的威胁、组织安全策略和假设的预期解决方案进行了陈述。 (5) TOE能提供什么(潜在TOE消费者)? 该问题由ST第6部分的安全要求处理，其中给出了TOE的安全功能和安全保障要求。 (6) TOE具体做了什么(采用的技术和机制)?该问题由ST第7部分的TOE概要规范阐述，其中提供了TOE安全功能实现技术与机制的深层次的描述。 (7) TOE将会做什么(专家)?该问题由ST第6部分描述的SFR以及由提供了附加细节的TOE概要规范阐述。 (8) TOE处理政府/组织定义的问题了吗? 如果政府/组织等TOE消费者已经定义了PP，答案可以在ST的符合性声明中找到，ST编制人员从中列出了ST符合的所有PP。 (9) TOE处理IT产品用户的安全问题了吗?什么是TOE对抗的威胁？它实施的组织安全策略是什么？做了哪些有关运行环境的假设？这些问题由ST的安全问题定义阐述。 (10) CC用户可以信任TOE到什么程度?这能够在ST第6部分的安全要求的SAR中找到，ST编制人员在其中提供了评估TOE的评估保障级别，因而提供了对TOE正确性的信任程度。 TOE利益相关人可能参与ST编制： TOE开发者编写的ST文档由潜在的IT产品用户阅读，由评估者按照CEM中定义的ASE对ST进行检查和评估。通过评估后的ST被TOE开发者用作构建一个TOE的基础。当然ST并不是固定不变的，而是随着用户需求、信息技术、应用环境等的发展而不断修订的一份IT产品安全规范文档。基于CC/CEM的TOE生命周期活动及其相关文件都可映射到IT产品的软件生命周期和采购流程的某个阶段。在软件工程生命周期中，一个ST相当于设计阶段文档——由TOE开发者响应客户在一个PP里声明的安全要求而生成的一个设计文档，且这一设计的质量需要通过ASE类安全保障活动来验证。在IT产品采购流程中，一个ST相当于合同认可前采购活动需要TOE开发者提交的一部分技术文档； 换句话说ST应包含在潜在应标人提交的合同提案文档中，并且由合同招标源选择团队对其可行性进行评估。 CC强制TOE开发者使用ST文档结构描述IT产品安全方案，是为了规范IT产品安全需求及其规范说明的编制，确保ST是IT产品所有不同用户能准确地一致地进行解读的规范化文档。ST各部分内容是一个联系紧密的有机整体，ST文档中的各部分内容之间的依赖及其一致性需遵循ISO/IEC TR 15446 技术报告要求。 ST第1部分通过定义ST范围和状态、TOE类型、安全架构、逻辑和物理边界等来概述一个ST。TOE类型是试图通过定义TOE实现技术与机制来分类TOE。TOE安全描述部分的一个主要目标是区分TOE和TOE安全架构。TOE安全架构定义了TOE安全功能(TSF)必须的语境。TSF包含正确执行TOE安全策略所需的所有TOE硬件、软件和固件。TOE安全架构定义了由TOE架构约束下的TSF实现的相关内容。如果ST是为了描述一个特定安全的商业化产品套件，TOE和安全架构可能相同。相对地，如果ST是为了描述一个IT系统中的TOE部件，TOE和安全架构之间 可能存在区别。物理安全边界表示了TOE安全功能对什么边界有效。这一边界里的IT实体在TSF控制范围里(TSC)，并且以指定的方式在一定程度上被保护。在这一边界外的IT实体则不在TSC中，不一定被信任。TSC表示可能出现于TOE以及可能受TOE安全策略约束的IT实体集合。物理安全边界是通过明确声明哪些硬件、固件、软件平台、组件和模块包含与TSF实现独立的实例来定义的。 ST第2部分描述ST是否声明与某些PP或包符合，具体与哪些PP或包符合。阐明ST是用来响应哪一个PP，并解释该ST和被引用的PP之间的符合度。ST符合性声明可以是PP符合性声明的无、完全、裁剪、增加和部分符合。该部分是一个ST和被引用的PP和包之间的符合度说明和解释。所有的PP和包符合性声明必须通过充分解释，其理由和凭据应被证实。 ST第3部分声明了TOE运行安全相关的假设，分析了TOE面临的威胁，并且列出了适用于TSF的组织安全策略。ST安全问题定义部分反映了PP适用的安全环境。PP和ST这部分之间的差异性来自于这样的事实，PP是实现独立的，而ST是实现依赖的。 ST第4部分描述了TOE安全目的和运行环境安全目的。这些安全目的来自对第3部分假设、威胁和安全策略的分析。TOE开发者应响应PP里合适的安全目的，决定： ①PP里的安全目的是否是有效的； ②是否必须增加新的安全目的。 ST第5部分是TOE扩展组件定义，通过CC组件格式描述IT产品特定的安全功能或安全保障要求。 ST第6部分通过选择和定义TOE安全功能要求(SFR)和安全保障要求来实现第4部分中描述的TOE安全目的。这些SFR和SAR来自对第2部分对安全架构和边界的讨论，以及第3部分中描述的安全风险分析。TOE开发者响应PP中的需求，PP中的安全需求在ST中可能被简单地重申，ST编制者也可能添加如下与TOE实现相关细节。 (1) 完成PP中安全组件未执行的元素操作。 (2) 解决PP中未解决的组件依赖。 (3) 通过细化或反复操作功能组件来反映ST编制者的TOE安全方案。 (4) 指定PP中未提供的审计需求。 (5) 增加由于ST的实现依赖特性而必须增加的SFR。 (6) 为IT环境重分配SFR。 (7) 忽略非必要的、冗余的或冲突的SFR。 ST第7部分，TOE概要规范(TSS)，定义了以下内容。 (1) 满足ST第6部分中定义的每个SFR的具体的IT安全功能(TSF)。 (2) 用于实现每个安全功能的准确的安全机制或技术。 (3) 用于满足第6部分定义的SAR的准确的安全保障措施。 如果ST基本原理比较多，可以添加第8部分，以证明以下几点。 (1) 第4部分安全目的响应了第3部分TOE安全问题定义。 (2) 第6部分安全要求实现了第4部分的所有安全目的。 (3) 第7部分的TOE概要规范实现了第6部分的所有安全要求。 (4) PP合规性和安全功能强度声明是有效的。 上述4种安全原理说明论据证明了ST是完整的、正确的、一致和连贯的。ST编制者证明了安全目的、安全要求和安全概要规范是必要的、充分的和相互支持的。 5.11问 题 讨 论 1. 简述ST在IT产品生命周期和安全评估中的角色和作用，包括ST在IT产品生命周期中不应承担的角色。 2. 比较PP和ST文档结构，分析二者之间的差异，以及各部分之间的联系和依赖关系。 3. 简述安全目标引言内容，描述TOE功能概述和TOE安全描述的主要内容。 4. 简述组合TOE与引用ST和PP之间的关系。 5. 阐述组合TOE安全目的和单体、组件和组合TOE之间的关系。 6. 在PP中只要讨论TOE边界，但在ST中需要区分TOE物理边界和逻辑边界。简述为何在ST里要区分这两种边界类型，并概述ST中逻辑和物理安全边界作用。 7. 简述TOE消费者和评估者在未来IT产品使用或评估中如何使用ST中安全问题定义的一个假设声明。 8. 如何分类ST安全问题定义部分声明的威胁？这与它引用的PP中的威胁分类有什么不同？ 9. 与软件工程其他详细的安全设计规范相比，解释使用ST文档结构描述TOE概要规范的优缺点。 10. 阐述TOE、TSF、TSC和针对(a)TOE部件、(b)组合TOE、(c)商用现货产品(COTS)和(d)系统的TSFI之间的关系。 11. 讨论延迟解决PP中组件依赖关系到一个ST编制期间的正反两方面的优缺点。 12. 描述TOE体系架构和安全架构之间的相似性和不同。 13. TOE概要规范中描述安全审计和管理需求的目的是什么？ 14. 使用什么准则来证明安全要求是： (a)必要的、(b)充分的、(c)互相支持的？ 15. 简述TOE概要规范主要内容，简述如何通过跟踪矩阵来保证PP/ST安全要求完整性和一致性。 16. 简述SFR执行(SFRenforcing)、SFR支撑(SFRsupporting)与SFR无关(SFRnoninterfering)3种模块及其接口异同及其在TOE安全评估中的作用。 17. 简述TOE概要规范原理部分内容，通过讨论TSS和TSS原理之间的关系，解释为何说ST是实现相关的IT产品安全规范说明。 18. 组件依赖分析证明了什么？在组件依赖分析范围里有什么组件? 19. (a)SFR和SFR、(b)SFR和安全技术与机制、(c)SFR和安全保障措施、(d)SAR和EAL之间的关系是什么？ 20. 面向TOE消费者和评估者，ST可以回答他们即将采购或评估IT产品的哪些问题？