GB∕T 18336.1-2015标准规范下载简介

GB∕T 18336.1-2015 信息技术安全技术信息技术安全评估准则 第1部分：简介和一般模型

对抗一个威胁不一定意味着要消除那个威胁，也可以意味着充分的减少该威胁或者充分的缓解该 胁。 消除威胁示例： 消除威胁主体执行敌对行为的能力； · 移动、改变或保护资产以便敌对行为不再适用于它； · 消除威胁主体（如，从网络中移除频繁使该网络崩溃的设备）。 减少威胁示例： 限制威胁主体完成敌对行为的能力； 限制威胁主体执行敌对行为的机会； · 减少成功执行敌对行为的可能性； 通过威手段减少威胁主体执行敌对行为的动机； · 增大威胁主体需要的技能或资源。 缓解威胁的作用示例： ·频繁作资产备份； 获取资产的多余拷贝； 给资产上保险； 确保及时检测到成功的敌对行为，以便采取逅当行动。

A.7.4 安全目的,结束语

A8扩展的维件定义（ASE ECD

GB／T 23901.2-2019 无损检测 射线照相检测图像质量 第2部分：阶梯孔型像质计像质值的测定A.9安全要求（ASEREQ）

安全要求由两组要求构成： a）安全功能要求（SFR）：将TOE安全目的转化为标准语言； b）安全保障要求(SAR）：TOE满足SFR所要获得的保障描述。 这两组要求在A.9.1和A.9.2中讨论

A.9.1安全功能要求(SFRs)

SFR是TOE安全目的的转化。他们通常是以一个较详细且抽象的形式表述，但他们必须

完全的转化（安全目的必须被完全对应)并且独立于任何特定的技术解决方案（实现）。ISO/IEC15408 要求其转化为一个标准化语言有几个理由： . 提供要评估什么的精确描述。因为TOE的安全目的一般用自然语言描述，转化为标准化语言 使得TOE的功能性描述更加精确； . 允许两个ST之间比较。不同的ST作者可能使用不同的术语描述他们的安全目的，标准化的 语言使用了相同的术语和概念。这使得容易进行比较。 ISO/IEC15408中没有要求对运行环境安全目的进行转化，因为不会评估运行环境，因此不需要针 对其评估进行描述。与运行系统安全评估相关的条款见参考书目。 可能出现部分运行环境在另外的评估中被评估的情况，但这超出了当前评估的范围。如：操作系统 TOE可能要求一款防火墙在其运行环境中。另一个评估可能随后评估该防火墙，但该评估没有做操作 系统TOE的任何评估。

A.9.1.1ISO/IEC15408如何支持转化

A.9.1.2SFR和安全目的之间的关系

ST也可以包含一个安全要求基本原理，由与SFR相关的两条内容组成： ·追溯即是表明SFR与TOE安全目的的对应关系； ·论证所有TOE安全目的都已由SFR做了有效对应

A.9.1.2.1SFR和TOE安全目的之间的追溯

说明SFR如何追溯到TOE安全目的的映射如下： a）没有伪造的SFR：每个SFR至少追溯到一个安全目的； b）完全覆盖TOE安全目的：每个TOE安全目的至少有一个SFR追溯。 多个SFR可以追溯到相同的TOE安全目的，表明那些安全要求共同满足TOE的该安全目的。

A.9.1.2.2对追溯提供论证

安全要求基本原理证实追溯是有效的：如果追溯到TOE的特定安全目的的所有SFR被满足，那 E的安全目的就达到了。 该证实应该分析满足实现TOE安全目的的相关SFR的有效性，并且得出情况确实如此的结论 存在SFR与TOE安全目的表述十分接近的情况，此时证实可以很简单

A.9.2安全保障要求(SARs）

SAR是对如何评估TOE的描述。该描述使用标准语言有两个理由

A.9.3SARs和安全要求基本原理

ST也包含了一个安全要求基本原理，解释为什么该SAR特定集合是合适的。对该解释没有 求。解释的目的是使ST的读者理解选择该特定集合的理由。 不一致的例子是安全问题描述中提到威胁代理的能力很强，而SAR中包含了低（或无）脆弱性分 VAVAN)

A.9.4安全要求：结束语

图A3安全问题定义、安全目的和安全要求之间的关系

A.10TOE概要规范（ASETSS)

A.11ST可解答的问题

评估之后，ST指明“评估什么”。在这个任务中，ST作为TOE开发者或销售者和TOE潜在消费 者之间达成一致协议的基础。ST因此可以回答下述问题（或更多）： a）我如何能够在给出的多个已存在的ST/TOE中找出我需要的ST/TOE？该问题由TOE概 述阐述，在那里给出了TOE的简要（几个段落）描述。 b) TOE适合我现有的IT基础设施吗？该问题由TOE概述阐述，在那里标识出了运行TOE所 需要的硬件/固件/软件元素。 c) TOE适合我现有的运行环境吗？这个问题由运行环境安全目的阐述，在那里标识了TOE为 发挥作用所受到的运行环境所有限制。 d）TOE做什么（感兴趣的读者）？该问题由TOE概述阐述，在那里给出了TOE的简要（几个段 落）描述。 e) TOE做什么（潜在消费者）？该问题由TOE描述处理，在那里给出了TOE的简要（几页） 描述。 D TOE做什么（偏技术）？该问题由TOE概要规范阐述，在那里提供了TOE使用机制的深层 次的描述。 g) TOE做什么（专家)？该问题由提供了抽象的高级技术描述的SFR以及由提供了附加细节的 TOE概要规范阐述。 h) TOE处理政府/组织定义的问题吗？如果政府/组织已经定义了该解决方案的已定义的包或 PP，那么答案可以在ST的符合性声明一条中找到，在那里列出了ST符合的所有包和PP。 TOE处理我的安全问题了吗（专家)？什么是TOE对抗的威胁？它实施的组织安全策略是什 么？做了哪些有关运行环境的假设？这些问题由安全问题定义阐述。 ) 我可以信任TOE到什么程度？这能够在安全要求一条的SAR中找到，那里提供了评估TOE 使用的保障级别，因此是相关评估提供了对TOE正确性的信任

A.12低保障安全且标

写ST不是一件简单的事情，特别是在整个低保障级别的评估中，开发者和评估者的大部分努力都 可能要花在这个方面。出于这种原因，也可写一个适用于低保障级别的ST。 ISO/IEC15408允许使用低保障ST作EAL1评估，EAL2及以上不可以。低保障ST只能声明符 合一个低保障PP(参见附录B)。一个常规的ST(如，有全部内容)可以声明与一个低保障的PP符合。 低保障ST与常规ST相比明显减少了一些内容.如：

写ST不是一件简单的事情，特别是在整个低保障级别的评估中，开发者和评估者的大部分努力都 可能要花在这个方面。出于这种原因，也可写一个适用于低保障级别的ST。 ISO/IEC15408允许使用低保障ST作EAL1评估，EAL2及以上不可以。低保障ST只能声明符 合一个低保障PP(参见附录B)。一个常规的ST(如，有全部内容)可以声明与一个低保障的PP符合。 低保障ST与常规ST相比明显减少了一些内容.如：

V 不用描述安全问题定义； 不用描述TOE安全目的，但运行环境安全目的仍然必须描述； ·由于ST中没有安全问题定义，所以不用描述安全目的基本原理； ·由于ST中没有TOE安全目的，所以安全要求基本原理只需要论证未被满足的依赖关系。 其余内容包括： a）TOE和 ST参照号。 b）符合性声明。 各种叙述性描述： 1）TOE概述； 2）TOE描述； 3）TOE概要规范。 d）运行环境安全目的。 e）SFR和SAR（包括扩展组件定义），以及安全要求基本原理（只要求未满足的依赖关系）。 低保意ST中削减后的内容如图A.4所示

A.13在ST中引用其他标准

图A4低保障安全目标内容

在某些情况下，ST作者可能希望引用外部标准，如特定的密码标准或协议。为此，ISO/IEC15408 提供了3种方法： a）作为组织安全策略（或者组织安全策略的一部分）： 例如：如果有一个国标定义如何选择口令，可以将它在ST中作为组织安全策略声明。这可能会产生一个环 境目的（如，如果TOE用户需要因此选择口令），或者如果TOE生成口令，可能产生TOE安全目的，进而产 生适当的SFR(可能是FIA类)。在这两种情况下，开发者需要为TOE安全目的和适于实现组织安全策略的

在某些情况下，ST作者可能希望引用外部标准 供了3种方法： a）作为组织安全策略（或者组织安全策略的一部分）： 例如：如果有一个国标定义如何选择口令，可以将它在ST中作为组织安全策略声明。这可能会产生一个环 境目的（如，如果TOE用户需要因此选择口令），或者如果TOE生成口令，可能产生TOE安全目的，进而产 生适当的SFR(可能是FIA类）。在这两种情况下，开发者需要为TOE安全目的和适于实现组织安全策略的

SFR作出合理的基本原理。评估者需要检查其事实上是否合理（可能决定因此而查看标准），是否像在下面 解释的那样，组织安全策略由SFR实现。 b) 作为技术标准（如某密码标准)用于细化SFR： 在这种情况下，与标准的符合性是TOE的SFR实现的一部分，标准的全文被看作SFR的 部分。随后确定符合性，就像与SFR的任何其他符合性一样：通过在ADV和ATE评估活动 中进行设计分析和测试，来确定SFR在TOE中已被完全实现。如果仅仅引用了标准中的特 定部分，该部分应该明确地在SFR的细化过程中说明。 作为技术标准（如某密码标准）在TOE概要规范中提及： 只能把TOE概要规范看作是如何细化SFR的一个解释，并不像SFR或ADV交付文档那样 被完全用于规范严格的实现要求。因此，若TOE概要规范引用了一个技术标准，而在ADV 相关的证据文件中又没有反映它，评估者可能会发现其中存在着不一致，但又无法通过例行活 动测试与该标准的一致性。

B.3.1如何使用PP

图B.1保护轮廊内容

一个典型的PP一般是对需求的陈述，由用户群体、管理实体、开发组织定义的通用的安全要求集 合。PP给消费者提供了一种引用该集合的参考，以便于以后针对这些需求的评估。 因此，一个PP一般用于： ·特定消费者或消费者群体的部分要求规范，这些消费者只考虑购买符合该PP的IT类型的 产品； · 特定管理实体的部分规章制度，他们只允许使用符合该PP的特定类型的IT产品； ·IT开发者对IT产品定义的基线，他们达成协议生产的所有该类IT产品将满足该基线要求。 当然不排除其他的使用情景

B.3.2不应使用PP的情况

PP不适用的三个角色是： 详细规范：PP是较高抽象级别的安全规范。一般PP不应该包含详细的协议规范、详细的算法 或机制的描述、具体操作的穴长描述等。 完整规范：PP是安全规范而不是通用规范。除非与安全相关，如互联性、物理大小和重量、要 求的电压等属性不应该成为PP的构成部分。一般来说PP可以是一个完整规范的一部分，而 其本身不是一个完整规范。 单一产品的规范：与ST不同，PP是描述特定类型的IT，而不是某单一产品。仅仅描述单一产 品时，最好使用ST。

B.4PP引言（APEINT）

PP引言以两种抽象的叙述性方式描述TOE： a）PP标识：为PP提供标识信息； b)TOE 概述:简单描述 TOE。

PP中包含了一个识别特定PP的清晰的PP标识。 典型的PP标识由标题、本、相出 日期组成。PP标识的例子：“某加密器PP，版本2b，某机构，2003年4月7日”。这个标识必须是唯一 的，以便可以区分不同PP和相同PP的不同版本。 PP标识利干编目和PP引用及其在PP列表中的内容。

TOE概述的目的是帮助潜在消费者从通过被评估的产品列表中我到满足他们安全 件、软件和固件得到支持的TOE。 TOE概述也适用于通过使用PP设计TOE的开发者或改进现有已生产的产品。 通常用几个段落的篇长对TOE进行概述性描述。 最后，TOE概述简单描述了TOE的用途和它的重要安全持征，标识TOE类型，标识TOE可用的 主要的非TOE硬件、软件和面件

B.4.2.1TOE的用途和至要安全特征

B4.2.2 TOE 类型

TOE概述识别了TOE的一般类型，如防火墙、VPN防火墙、智能卡、加密调制解调器、企业 EB服务器、数据库、WEB服务器和数据库、LAN、包含WEB服务器和数据库的LAN等。

B.4.2.3可用的非TOE的硬件/软件/固件

件，在后一种情况中，要求TOE概述标识出这样的TOE硬件、软件或固件。 由于保护轮廊不是为一款特定产品而编写，许多情况下只能给出可用硬件/软件/固件的一般情况， 在另一些情况中，可以提供更多特定信息，如，已知平台的特定消费者的要求规范。 硬件/软件/固件标识示例： ·无（单机TOE)； ·运行在普通PC上的某操作系统3.0； ·智能卡SB2067集成电路：

运行某智能卡操作系统V2.0的智能卡SB2067集成电路； 某局域网。

B.5符合性声明（APECCL）

PP的本章条描述PP如何与其他PP和包符合，除符合性陈述之外，与ST的符合性声明章条相同 （见A.5）。 PP中的符合性陈述说明ST或其他PP必须如何符合该PP。PP作者需要选择“严格的”或者“可 论证的”符合性方式，相关细节参见附录D

B.6安全问题定义（APESPD）

B.7安全直的（APEOB

8扩展的组件定义（AP

3.9安全要求（APERE

本条与ST的安全要求一条相同，解释见A.9。值得注意的是，完成PP中的操作与完成ST中操作 的规则略有不同，详细的解释见7.1

本条与ST的安全要求一条相同，解释见A.9。值得注意的是，完成PP中的操作与完成ST中按 规则略有不同，详细的解释见7.1。

B.10TOE概要规范

PP没有TOE概要规范

PP没有TOE概要规范

B.11低保障的保护轮扇

像低保障ST与常规ST的关系一样，低保障PP与常规PP（即有全部内容的PP)有同样的关系 就是说低保障PP由下述部分组成： a）PP引言，由PP标识和TOE概述组成； b）符合性声明； c）运行环境安全目的； d）SFR和SAR（包括扩展的组件定义）和安全要求基本原理（只有依赖关系不满足时需要）。 低保障PP只能声明与一个低保障PP符合（见B.5），常规PP可以声明与低保障PP符合。 被减少内容的低保障PP见图B.2

B.12在 PP 中引用其他标准

图B.2低保障保护轮廊内容

本条与A.13中描述的有关ST的标准相同，不同的是，PP没有TOE概要规范，第三个选择对PP 无效。 提醒PP作者，在SFR中引用一个标准可能会强加给开发TOE的开发者为满足该PP的重大负担 （与标准的大小和复杂度以及所需要的保障级别有关），因此这种情况可能更适合于要求二选一（非CC 相关）方法评估与该标准的符合性。

如ISO/IEC15408第一部分中的描述，保护轮廊和安全目标包含预先定义的安全要求，也提供给 PP和ST作者在某些环境中扩展组件列表的能力

7.1给出了4种类型的操作GB/T 42230-2022 钢板卷道路运输捆绑固定要求，4种操作示例描述如下

例子如.FIAUAU.3不可伪造的鉴别，该组件关

C.4.1如何定义扩展的组件

无论何时PP/ST作者定义一个扩展组件，必须使用类似于已存在ISO/IEC1 晰、明确、可以评估（可以系统地证实基于该组件的要求是否为TOE所保持）。扩展组件必须像已有组 件一样使用类似的标签、表达方法和详细级别。 PP/ST作者也必须确认，扩展组件的所有可用的依赖关系包含在该扩展组件的定义中，可能的依 赖关系的例子是：

一个PP准备用作ST的“模版”，就是说：PP描述了一组用户需求，而与该PP符合的ST描述了满 足那些需求的TOE。 注意，一个PP也可能用作另一个PP的模版，这时该PP可以声明与其他PP符合。这种情况完全 类似于ST与PP的关系。为了清晰，本附录只描述了ST/PP的情况，但它也适用于PP/PP的情况。 ISO/IEC15408不允许任何形式的部分符合，所以如果一个PP被声明，则PP或ST必须完全与所 引用的PP符合。然而有两种类型的符合（“严格的”和“可论证的”），所允许的符合性的类型由PP确 定。即PP符合性陈述（在PP符合性陈述中，见B.5)允许ST声明符合的符合性类型。“严格的”和“可 论证的”符合性之间的这种差别单独用于ST可以声明对每一个PP的符合性上。这可能意味着ST与 某些PP严格符合，与另外一些PP可论证的符合。一个ST只适用于当PP明确允许该ST以可论证的 方式与该PP符合的情况，否则ST总是应该与任何PP保持严格符合。 换句话重述一下，一个ST以可论证的方式与该PP符合的情况仅适用于该PP明确允许的情况下。 与一个PP符合，意着该PP或ST（如果ST是一个被评估产品的，该产品也同样）满足那个PP 的所有要求。 已发布的PP一般需要有PP符合性陈述，这意味着声明与PP符合的ST必须提供对PP中描述的 一般性安全问题的解决方案，但是可以以等同于PP或比PP更多限制的方式来进行描述。“等同于或 更多限制”的详细定义在ISO/IEC15408中进行了描述，原则上来讲，对所提供的ST针对TOE采用等 价或更多限制、对TOE运行环境采用等价或更少限制，那么PP和ST可以包含完全不同的陈述，使用 不同的概念等

严格符合性反映PP作者，PP作者要在PP中所提出的安全功能要求的证据，ST是PP的一个 例，尽管ST能够比PP更宽泛。本质上在TOE运行环境属于PP明确的范围内，ST定义的TOE至少 与PP相同。 严格符合性体现在典型的例子是：在选择购买产品的时候，期望所要实现的安全功能要严格与PP 中规定的安全功能要求符合。 与PP严格符合的实例化的ST仍然可以对PP引人附加的限制。

本参考文献包含着ISO/IEC15408读者可能发现有用的更多的参考资料和标准。对于未标明日 期的参考书目，建议读者查阅参考文献的最新版本

GB／T 51379-2019 岩棉工厂设计标准 ISO/IEC标准和指南

Institute of Electrical and Electronics Engineers,Standard aryofSoftwareEngineeringTerminology