GBT18336.3-2015 信息技术 安全技术 信息技术安全评估准则 第3部分：安全保障组件.pdf

保障是信任一个IT产品满足其安全目的的基础。保障可从诸如未经证实的声明、先前相关经验 或者特定经验等中导出。然而，IS)/IEC15408通过主动调查来提供保障。主动调查就是以确定IT产 品安全特性为目的对IT产品进行评估

5.2.4通过评估获得保障

评估是获取保障的传统手段，并且是 评估技不包括但不限于次 这些： a) 分析并检查过程和程序； b) 检查过程和程序是否正在被使用； c) 分析T)E各设计表示之间的一致性； d) 对照要求，分析TOE的设计表示； e) 验证证据； f) 分析指导性文档； g) 分析所开发的功能测试和所提供的结果； h) 独立的功能测试： i) 脆弱性分析（包括缺陷假设）； i) 穿透性测试

53ISO/IEC15408评估保障尺度

IS()/1EC15408的基本原则确信基坑支护标准规范范本，更高的保障级别源于 来获得必要的保障级。努力程度的增长基于： a） 范围 努力越多表明该IT产品被纳入了评估范围的部分越多； b）深度一 努力越多表明对该IT产品的设计和实现细节评估得越细； C）严格性 努力越多表明对该IT产品的评估采用了越具结构性和形式化的方法

6.1安全保障类、族和组件结构

以下内容描述了用于表示保障类、族和组件的结构。 图1图示说明了本部分所定义的安全保障要求（SAR）。需注意的是保障要求中最抽象的集合称作 类。每一一类包含多个保障族，每一族又包含多个保障组件，每一组件同样义包含多个保障元素。类和族 用于提供对保障要求进行分类的分类法.而组件用来详细定义PP/ST中的安全保障要求。

[6.1.1保障类结构

保障类的结构如图1所示

每一保障类被分配了一个唯一的类名。类名表明该保障类所涵盖的主题。 还提供了保障类名对应的唯一缩写形式，这是引用该保障类的主要方式。采用“A”后跟两 有关的字母来表示。

6. 1.1.2 类介绍

海个保障类至少包含一个保障族。保障族的结构将在以下内容中进行介绍

保障族的结构如图1所示。

图1保障类/族/组件/元素的层次

个保障族被分配了一个唯一的族名 与保障族所涵盖主题相关的描述性信息。

保障族名也有一个唯一的缩写形式，这是引用该保障族的主要方式。其表示方法是所在类名 紧跟着一个下划线，然后再加上与族名有关的三个字母

保障族的自的内容说明了保障族的意图， 描述了该保障族所要满足的目的，特别是那些与IS()/1EC15408保障范型有关的目的。保障族的 这部分描述是一般性描述。任何目的的细节措述都包含在特定的保障组件中

6.1.2.3组件分级

每个保障族包含一个或多个保障组件。保障族部分描述可供使用的组件并且解释各组件之间的差 异。一且确定该保障族对PP/ST保障要求而言是必需或是有用的，就要区分这些保障组件，这是组件 分级的主要目的。 含有超过一个组件的保障族将被分级，并提供组件是如何分级的原理性解释。原理是按照范围、深 度和/或严格性三方面来界定的

6.1.2.4 应用注释

如果有保障族应用注释.应包含该保障族的一些附加信息。这些信息应该是保障族用户（例如PF 和ST的作者、TOE的设计者、评估者)特别感兴趣的。这部分描述是非正式的，常包括关于使用限制 的一些警告和特别需要注意的地方。

6.1.2.5 保障组件

每个保障族至少包括一个保障组件 保障组件的结构将在6.1.3中进行描述。

6.1.3保障组件结构

保障组件的结构如图2所示。

保障族内组件之间的关系用粗体突出表示。新的、增强的或在同一类已有组件之上修订的要求，用 粗体突出表示。

牛之间的关系用粗体突出表示。新的、增强的或在同一类已有组件之上修订的要求，用

6.1.3.1组件标识

组件标识内容提供了识别、分类、注册和引用某一组件所必要的描述信息。 每个保障组件被分配了一个唯一的组件名。该组件名提供关于该保障组件所涵盖主题的描述性信 息。每个保障组件均被放置在与其具有相同安全目的的保障族之内。 也提供了保障组件名字的一个唯一缩写形式，这是引用保障组件的主要手段。其形式为族名的缩 写，后面加一个点，然后是一个数字，这个数字是根据组件在族内的顺序从1开始编号的。

如果有保障组件目的，应包含该特定保障组件的特定目的以及该组件的特定意图和目 解释。

6.1.3.3应用注释

6.1.3.4 依赖关系

当一个组件无法自我满足而依赖于另一个组件的存在时，依赖关系就出现在这些保障组件中。 每一个保障组件提供了对其他保障组件的依赖关系的一个完整列表。某些组件可能列出“无依赖 关系”，这表明没有确定的依赖关系。被依赖的组件也可能依赖于其他组件。 依赖关系列表标识了所依赖的保障组件的最小集合。在依赖关系列表中，等级比该组件低的那些 组件也可以要满足该依赖关系。 在特殊情况下，所指示的依赖关系可能并不适用。PP/ST作者在提供为什么给定的依赖关系不适 用的理由后，可以选择不满足该依赖关系。

6.1.3.5保障元素

每一个保障组件包含一组保障元素。一个保障元素就是一个安全要求，如果再进一步细分的话，将 不会产生有意义的评估结果。它是IS()/IEC15408认可的最小的安全要求。 每一个保障元素都被确定为属于以下3组保障元素中的一组： a）开发者行为元素：应由开发者实施的行为。这组行为靠随后的一组元素中所引用的证据材料 来进一步限制。开发者行为要求用元素号后附加一个字母“D"来标识。 b 证据的内容和形式元素：所需证据，证据应证实的内容和证据应表达哪些信息。证据的内容和 形式要求用元素号后附加字母“C"来标识。 评估者行为元素：应由评估者实施的行为。这组行为明确包含确认在“证据的内容利形式”元 素中规定的要求是否都已满足，也包含开发者除已完成的动作之外还需实施的明确行为和分 析。隐藏的评估者行为作为开发者行为元素的结果，虽然没有被“证据的内容和形式"元素覆 盖，也应当被实施。评估者行为要求用元素号后附加字母“E”来标识。 “开发者行为”和“证据的内容和形式”元素定义了一组保障要求来表示开发者的职责，以便于论证 OE满足PP或ST中安全功能要求的保障程度。 “评估者行为”从评估的两个方面定义评估者的职责。一方面是依据第9章APE“保护轮廊评估” 美和第10章ASE"安全目标评估”类对PP/ST的验证；另一方面是验证TOE与其功能要求和保障要 交的符合性。通过证实PP/ST是有效的并且T(E满足这些要求，评估者可以确信TOE在运行环境 口能够解决已定义的安全问题。 开发者行为元素、证据的内容和形式元素以及显式的评估者行为元素，确定了在验证T()E的ST 斤作安全声明时评估者应耗费的精力

每个元素代表一个需要满足的要求。这些要求的陈述应当清晰、简洁且无歧义。因此，不能出现复 杂句式，即每一可分离的要求将作为单独的元素来说明

本部分包含一些族和组件，以相关保障为基础进行分类。在每一个类的开始是一个图表，指出该类

族和族中的组件， 图3中所示的类只包含一个族。这个族包含3个按线性层次关系排列的组件（即组件2在特定 寺定证据、行为或证据的严格性等方面上比组件1要求得更多）。在本部分中保障族都是按线性 系组织的，尽管“线性"关系对以后可能增加的保障族而言，不是一个强制性标准，

在本部分中定义的评估保障级（EAL)和相应的结构如图4所示。注意，图中显示出保障 容.意图是通过引用ISO/IEC15408中定义的实际组件把这些信息包含到一个EAL中

6.2.1评估保障级名称

每个评估保障级被分配了一个唯一的名称。该名称提供关于该评估保障级意图的描述性信息。 也提供了评估保障级名称的一个唯一缩写形式，这是引用评估保障级的主要手段。

本条表示的是评估保障级的意图

如果有评估保障级的应用注释条，其中应包含评估保障级的使用者（如PP和ST作者，以该评个 为目标的T)E设计者、评估者）特别感兴趣的信息。这部分描述是非正式的，常包括关于使月 为一此警告和特别需要注意的地方。

每一个评估保障级均选择了一组保障组件。 可以用以下方法，得到一个比给定的EAIL更高的保障级别： a）包含来自其他保障族的额外的保障组件；或 b）从相同的保障族中用更高级别的保障组件替换保障组件

6.2.5保障和保障级之间的关系

图5说明了ISO/IEC15408定义的保障要求和保障级之间的关系。当保障组件进一步分解为保 障元素时，保障元素不能被保障级单独引用。需要注意的是，图中的箭头表示评估保障级（EAI）与保 障类中组件的引用关系。

图5保障和保障级的关系

组合保障包的结构和评估保障级的结构类似。这两种类型包的主要不同之处是他作

的结构和评估保障级的结构类似。这两种类型包的主要不同之处是他们所应用的

类型不同，评估保障级适用于组件TOE.组合保障包适用于组合T()E。 在本部分中定义的组合保障包（CAP)和相应的结构如图6所示。需要注意的是.该图中显示出 件的内容，目的是通过引用IS()/IEC15408中定义的实际组件把这些信息包含到一个组合保

6.3.1组合保障包名称

母组合保障包被分配唯： 供关于该组合保障包目的的描述性信息。每个组 合保障包还有唯一的缩写形式，这是引 主要方法

本条是对组合保障包目的的描述

包为目标的组合T(E的集成者、评估者）特别感兴趣的信息。这部分描述是非正式化的，常包括诸如 使用限制的一些警告和特别需要注意的地方

为每一个组合保障包选择了一组保障组件。 一些依赖关系标识了对组合T()E活动所依赖组件的评估过程中所完成的活动。在未明确指明与 依赖组件活动存在依赖关系时，依赖关系存在于组合TE其他的评估活动中。 比给定的组合保障包更高的保障级别可通过以下方式获得： a）包含来自于其他保障族的额外保障组件；或 b）用来自于同一保障族中的更高级别的保障组件替换保障组件

ACO类：在CAP保障包中的组合组件不能用于提升组件TOE的评估级别，因为这无法给 OE的评估提供任何有意义的保障

6.3.5保障和组合保障包之间的关系

图7描述了ISO/IEC15408定义的安全保障要求和组合保障包之间的关系。当保障组件进一步 分解为保障元素时，保障元素不能被保障包单独引用。注意，图中的箭头表示组合保障包与保障类组件 的引用关系，

图7保障和组合保障包的关系

评估保障级（EAL)提供了一种递增的尺度，以保障度的获取开销和可行性来权衡保障的级 )/IEC15408使用的方法分离了评估结束时对一个TOE建立的保障概念，以及在运行使用该 维护该保障的概念。 需要特别注意的是并非本部分中的所有族和组件都包含在这些评估保障级中。这并不是说没

平估保障级中的这些族和组件不提供有意义的和所需要的保障。相反，期望能把这些族和组件 效用作为PP和ST中的评估保障级的增强

Z.1评估保障级（EAL)概述

表1概括性地描述了评估保障级。其中列表示的是一组按级排序的评估保障级，行表示的是保降 族。在表格矩阵中的每一个数字标识出了此处适宜的具体保障组件。 正如在下一条里所总结的那样，在IS0)/IEC15408中对T()E的保障等级定义了七个级别。它们 按级别排序，因为每一个评估保障级比其较低的评估保障级表达更多的保障。从评估保障级到评估保 章级的保障增加，靠替换成同一保障族中的个更高级别的保障组件（即增加严格性、范围和/或深度） 和添加另外一个保障族的保障组件（即添加新的要求）来实现。 正如在本部分第6章所阐述的那样，这些评估保障级由保障组件的一个适当组合组成。更确切地 说，每个评估保障级最多包含每个保障族中的一个组件，以及每个组件的所有保障依赖关系。 虽然这些评估保障级是在IS0/IEC15408中定义的，但还是可以用保障的其他组合来表示。特别 是“增强”这个概念允许（从没有包括在评估保障级中的保障族）向评估保障级中增加保障组件，或允许 替换评估保障级中的（用同一个保障族的其他更高级别的保障组件）组件。在IS()/IEC15408中定义 的保障结构中，只有评估保障级可以增强。“评估保障级减去一个组成保障组件”这样的想法在本部分 中不认为是一个有效的主张。要求“增强”者有义务论证对评估保障级添加保障组件的实际意义和额外 价值。一个评估保障级也可以用扩展的保障要求来增强

以下各条提供这些评估保障级的定义，用粗体字强调了各级特定要求之间的区别和这出要求 特征。

Z.3评估保障级1(EAL1)功能测试

EAL1适用于对（产品的）正确运行需要一定信心，但安全威胁义并不太被看重的场合。对于需要 进行独立的保障评估来支持个人信息或类似信息已经得到适当保护的情况，EAL1具有一定的价值。 EAI.1仅要求一个简化的ST。该ST只需简单地陈述TOE满足的安全功能要求，而不用通过从 假设、威胁和组织安全策略，进而从安全目的来推导安全功能要求。 EAI1提供了一个对客户可用的TE的评估，包括依据独立测试和对所提供的指导性文档的检 查。意图是在没有TOE开发者的帮助下，EAI1评估也能成功地进行，而且评估所需费用最少。 在这个级别.上的评估应当提供这样的证据，即T()E的功能与其文档是一致的

EAL1提供广种基本的保障级别来理解安全行为，该保障级别是在利用功能和接口规范以及指 导性文档的基础上，通过分析一个部分ST中的安全功能要求而建立的。 这种分析是通过从公开领域搜索潜在脆弱性并开展TSF的独立测试（功能测试和穿透性测试）来 美得支持的。 EAL1还通过TOE和相关评估文档的唯··标识来提供保障。表2列出EAL1级的保障组件。 与未经评估的IT产品相比，本EAL在保障方面提供了有意义的增强，

7.4评估保障级2(EAL2)结构测试

EAL2需要开发者在交付设计信息和测试结果方面提供配合.除广要求其与良好的商业习惯一到 外，不应要求开发方付出更多的努力。这样，就不需要增加过多的费用或时间投人。 EAL2适用于以下情况：在缺乏现成可用的完整的开发记录时，开发者或用户需要一种低到中等级 别的安全性保障。这种情况可能出现在对遗留系统进行安全保护、或者不易联系到开发者的时候

EAL2在利用功能和接口规范、指导性文档和TOE结构的基本描述的基础上，通过分析一个完整 的ST中的安全功能要求来提供保障，以理解安全行为。 这种分析由对TSF的独立测试、开发者基于功能规范进行测试的证据、对开发者测试结果的选择 性独立确认、证实可抵御具有基本攻击潜力攻击者攻击的脆弱性分析（基于功能规范、TOE设计、安全 构描述和提供的指导性证据）等证据来支持。 EAL2还通过配置管理系统的使用和安全交付程序的证据来提供保障。表3列出EA2级的保障 组件， 与EAL1相比，本EAI.通过增加开发者测试、脆弱性分析（除了公开领域的搜索外）和基于史详细 的TOE规范进行独立测试等内容，在保障方面提供了有意义的增强

7.5评估保障级3(EAL3)系统地测试和检查

7.5评估保障级3(EAL3)系统地测试和检查

EAL3可使负责任的开发者在设计阶段不需要对现有合理的开发实践作实质性变更，就能从正确 的安全工程中获得最大限度的保障 EAL3适用于以下情况：开发者或用户需要中等级别的安全性保障，同时要求在不进行大规模重建 的情况下，对TOE及其开发过程进行彻底调查

EAL3在利用功能和接口规范、指导性文档和TE的设计架构描述的基础上，通过分杆一个完整 的ST中的安全功能要求来提供保障计算机标准，以理解安全行为。 这种分析由对TSF的独立测试、开发者基于功能规范和TOE设计进行测试的证据、对汗发者测试 结果的选择性独立确认、证实可抵御具有基本攻击潜力攻击者攻击的脆弱性分析（基于功能规范、TOE 设计、安全架构描述和提供的指导性证据）等证据来支持。 EAL3还通过使用开发环境控制措施、TOE配置管理和安全交付程序的证据来提供保障：。4列 出EAL3级的保障组件

与EAL2相比，本EAL通过增加 功能的完备测试，以及提供在开发过程中T()E不会初 信任机制和/或程序等内容，在保障方面提供了有意义的增强

平估保障级4（EAL4）一一系统地设计、测试和复

EAIL4可使开发者基于良好的商业开发惯例，从正确的安全下.程中获得最大限度的保障，虽然这种 实践很严格，但并不需要天量的专业知识、技巧和其他资源。翻新~个已经存在的生产线很可能是经济 上切实可行的，此时EAI.4是所能达到的最高保障级别。 EAI.4适用于以下这些情况：开发者或用户在传统的商品化T()E中需要一个中等到高等级别的安 全性保障，并准备负担额外的安全专用的工程费用

上，通过分析一个完整的ST中的安全功能要求来提供保障，以理解安全行为。 这种分析由对TOE安全功能的独立测试、开发者基于功能规范和TOE设计进行测试的证据、对 开发者测试结果的选择性独立确认、证实可抵御具有增强型基本攻击潜力攻击者攻击的脆弱性分析（基 于功能规范、T（E设计、实现表示、结构性设计和提供的指导性证据）等证据来支持、 EAL4还通过使用开发环境控制措施、包括配置管理自动化在内的更多的TOE配置管理措施和安 全交付程序的证据来提供保障。表5列出EAL4级的保障组件。 与EAL3相比，本EAL通过增加更多的设计描述、所有安全功能的实现表示，以及为在开发过程中 T()E不会被算改提供一定信任的改进机制和/或程序，在保障方面提供了有意义的增强

7.7评估保障级5（EAL5)——半形式化设计和测试

EAI.5可使一个开发者从基于严格的商业开发实践的安全工程中获得最大限度的保障，而这种开 发实践是靠专业安全工程技术的适度应用来支持的。设计和开发能够达到EAL5保障要求的TOE。 相对于没有应用专业技术的严格开发而言.由EAI.5要求引起的额外的开销也许不会很大。 EAL5适用于以下这些情况：开发者或用户在一个有计划的开发过程中需要高级别独立的安全性 保障，以及开发者或用户在未由于专业安全工程技术而导致不合理开销的条件下路桥图纸，需要有严格的开发 手段。

评估保障级6（EAL6）一半形式化验证的设计

EAI6可使开发者通过把安全工程技术应用于严格的开发环境情况下，获得的高级别保障。目的 是为了生产一个质优价高的T(E来保护高价值的资产避免存在重大的风险。 EAL6适用于应用在高风险环境下T()E的开发，其中由于安全所需的额外开销与受保护资产的价 值是相当的，