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

评估授权机构evaluationauthority

为特定群体中的团体开展评估工作进行标准 管的组织，该组织依据评估 ISO/IEC15408

评估体制evaluationscher

彻底的exhaustive

三层标准规范范本外部实体external entity

兔兔wwbzfxwcor

反复iteration

保护轮廊Protectionprofile;PI

针对一类TOE的、与实现无关的安全需求陈述。

保护轮廊评估protectionprofileevaluation 依据已定义的准则，对一个PP进行的评价。 3.1.53 证明prove 通过数学意义上的形式化分析来说明对应关系。 注：本术语在各个方面都是非常严格的。通常情况下，当期望以一种高度严格的方式说明两个TOE安全项 （TSF)表示之间的对应关系时，才使用“证明”这一术语。 3.1.54 细化refinement 为组件添加细节。 3.1.55 角色role 为了规定在一个用户和该TOE之间所允许的交互行为而预定义的规则集。 3.1.56 秘密secret 为了执行一个特定的安全功能策略（SFP)，必须仅由授权用户和/或TSF才可知晓的信息。 3.1.57 安全状态 securestate 一种状态，在该状态下，TSF数据一致，且TSF能继续正确执行SFR。 3.1.58 安全属性 securityattribute 主体、用户（包括外部IT产品）、客体、信息、会话和/或资源的特征，它用于定义SFR，且其值在 行SFR时使用。 3.1.59 安全功能策略 各securityfunctionpolicy;SFP 描述由TSF执行的特定安全行为的规则集，可表示为SFR的集合。 3.1.60 安全目的 securityobjective 意在对抗特定的威胁、和/或满足特定的组织安全策略和/或假设的一种陈述。 3.1.61 安全问题securityproblem 以一种正式的方式，定义TOE要处理的安全基本特征和范围的陈述。 注：该陈述由以下部分组成： ·要由TOE对抗的威胁； ·要由TOE实施的组织安全策略(OSP)； ·支撑TOE及其运行环境的假设。 3.1.62 安全要求securityrequirement 用标准化的语言陈述的要求，旨在达到TOE的安全目的。 3.1.63 安全目标securitytarget;ST 针对一个特定的已标识TOE，日与实现相关的安全需录陈述

目标securitytargetS

选择selection 从组件内列表中指定一项或多项。 3.1.65 半形式化 semiformal 采用具有确定语义并有严格语法的语言表达。 3.1.66 详细说明 specify 以严格精确的方式给出实体的特定细节。 3.1.67 严格符合性 strictconformance 一个PP和一个ST之间的一种层次关系，其中该PP中的所有要求也存在于该ST中。 注：这种关系可以粗略地定义为“ST应包含PP中所有的陈述，但也可以包含更多的内容”。严格符合性预期 描述那些需要以单一方式遵守的严格要求。 3.1.68 ST评信STevaluation 依据已定义的准则，对一个ST进行的评价。 3.1.69 主体subject TOE中对客体执行操作的主动实体。 3.1.70 评估对象 targetofevaluation;TOE 软件、固件和/或硬件的集合，可能陷带指南。 3.1.71 威慰主体threatagent 可以对资产施加不利行为的实体。 3.1.72 TOE评估 TOEevaluation 依据已定义的准则，对一个TOE进行的评价。 3.1.73 TOE资源 TOEresource TOE中任何可用或可消耗的事物。 3.1.74 TOE安全功能 TOEsecurityfunctionality 正确执行SFR所依赖的TOE的所有硬件、软件和固件的组合功能。 3.1.75 追溯trace 在两个实体之间，执行一种最低严格程度的非形式化对应分析。 3.1.76 TOE的外部传送 transfersoutsideoftheTOE 由TSF促成的、与不受TSF控制的实体的数据通信。 3.1.77 桂业trandation

选择selection

转化translation

用标准化语言描述安全要求的过程。

回译为安全目的。 3.1.78 可信信道trustedchannel 一种通信手段，通过该手段，TSF同另一个可信IT产品能够在必要的信任基础上进行通信。 3.1.79 可信IT产品trustedITproduct 不是该TOE的其他IT产品，它有与该TOE协调管理的安全功能要求，且假定其可正确执行自已 的安全功能要求。 注：一个可信IT产品例子，如一个经过独立评估后的产品。 3.1.80 可信路径trustedpath 一种通信手段，通过该手段，用户和TSF能够在必要的信任基础上进行通信。 3.1.81 TSF数据TSFdata TOE执行其SFR所依赖的数据。 3.1.82 TSF接口TSFinterface 外部实体（或在TOE中但在TSF之外的主体)向TSF提供数据、从TSF接收数据、并调用TSF服 务的方法。 3.1.83 用户数据userdata 属于用户的、不影响TSF运行的数据。 3.1.84 验证verify 通过严格细致地审查，独立地确定充分性。 注：参见术语“确认”，本术语有更严格的含义。这个术语用于描述评估者行为的语境中，其中要求评估者独立工作。 3.2与开发（ADV)类相关的术语和定义 注：下列术语用于软件内部结构化要求。其中一些来自IEEEStd610.12—1990IEEEStd610.12—1990,Standard glossary of software engineering terminology,Institute of Electrical and Electronics Engineers

3.2与开发（ADV)类相关的术语和定义

注：下列术语用于软件内部结构化要求。其中一些来自IEEEStd610.12一1990IEEEStd610.12一1990,Standard glossary of software engineering terminology,Institute of Electrical and Electronics Engineers。 3.2.1 管理员 administrator 就遵守由TSF实现的所有策略而言，在一定程度上可信的实体。 注：并非所有PP或ST都对管理员设定相同的可信程度。通常假定管理员始终遵循TOE的ST中描述的策略。 其中，有些策略可能与TOE的功能有关，另一些可能与运行环境有关。 3.2.2 调用树calltree 以图表形式标识系统中的模块，并表明模块之间的相互调用关系。 注：采自IEEEStd610.12—1990。 3.2.3 内聚cohesion 模块强度 单个软件模块所执行的诸任务之间的关联方式和程度，

调用耦合（控制）callcoupling（control） 两个模块之间的一种关系，其中一个模块传输信息给另一个模块，意于影响其内部逻辑。 注：见“调用耦合”（3.2.8）。

内容耦合contentcouplin

两个模块之间的一种关系，其中一个模块直接引用另一个模块的内部。 注：例子包括修改其他模块的代码或者引用其他模块内部的标签。结果是一个模块的部分或所有内容有效的包含 在另一个模块中。可将内容耦合理解为使用了未公开模块接口，而在调用耦合中，仅仅使用了公开的模块 接口。

域分离domainseparation

安全结构属性，TSF由此为每个用户和TSF定义了分离的安全域，保证没有用户进程可以影响其 他用户或TSF的安全域的内容。

功能内聚functionalcohesion 执行与单一目的相关活动的模块的功能属性。 [IEEEStd610.12—1990] 注：功能内聚模块将一种类型的输人转换为一种类型的输出，如堆栈管理器或队列管理器。见“内聚”(3.2.3)。 3.2.16 交互interaction 实体间一般性的通信活动。 3.2.17 接口interface 组件或模块交互的方式。 3.2.18 分层layering 设计技术，将各组模块分层组织，使其职责分离，以便在层级中的某层仅仅依赖于其下层的服务，且 仅向其上层提供服务。 注：严格分层增加了限制，每层只能从其邻接下层接收服务，只能向其邻接上层提供服务。 3.2.19 逻辑内聚 logicalcohesion 程序内聚 proceduralcohesion 表示模块对不同数据结构执行类似活动的特征。 注：当模块功能对于不同的输人执行相关的、但又不同的操作，表现为逻辑内聚。见“内聚”(3.2.3)。

TSF不能被非TSF代码或实体破坏的安全缩构

3.3与指导性文档(AGD)类相关的术语和定义

安装installation 由人类用户将TOE嵌入其运行环境中，并使其进入运行状态的规程。 注：这个操作一般在接收和确认TOE后仅执行一次，预期使TOE进人到ST允许的配置。如果必须由开发者执行 相似的过程，则在ALC：生命周期支持中注明为“生成”，如果TOE不需要定期重复执行初始启动，则这个过程 妇为安装，

运行operation

TOE的使用阶段，包括TOE交付和准备之后的正常使用”、管理和维护

准备preparation 产品生命周期阶段中的活动，由所交付的TOE的客户确认及TOE安装组成，可能包括 化、启动TOE并使其进人到准备运行的状态。

准备preparation

产品生命周期阶段中的活动，由所交付的TOE的客户确认及TOE安装组成，可能包括引导、初始 化、启动TOE并使其进人到准备运行的状态。 3.4与生命周期支持(ALC)类相关的术语和定义 3.4.1 接受准则acceptancecriteria 执行接受规程时使用的准则（如对软件、固件或硬件的成功的文档审查，或成功的测试）。 3.4.2 接受规程acceptanceprocedures 为了接受新建、修改过的作为TOE组成部分的配置项，或者将其转到生命周期的下一阶段应遵循 的规程。 注：这些规程明确了负责接受的角色或个人，以及为了做出接受决定所采用的准则。 下面是几种接受情形，其中一些可能有交叉： a）某个配置项第一次被配置管理系统接受，特别是接受来自于其他厂商的包含软件、周件和硬件的部件进入 TOE(“集成")； b）在构造TOE的每个阶段，配置项转人下一个生命周期阶段（例如模块、子系统、完成的TOE的质量控制）； c）不同开发地点的配置项后续传递（例如TOE的各部分或初始产品）； d）面向消费者的TOE后期交付。

3.4与生命周期支持（ALC)类相关的术语和定

配置管理configurationmanagement；CM

配置管理输出configurationmanagementoatpat 配置管理系统产生或实施的、与配置管理相关的结果。 注：这些配置管理相关结果可能表现为文档形式（如，填写的纸质表格、配置管理系统记录、日志数据、纸质和电子 输出数据)和行为（如执行配置管理规定的人工措施）。这样的配置管理输出的例子是配置清单、配置管理计划 和/或产品生命周期中的行为。 3.4.9 配置管理计划configurationmanagementplan 配置管理系统如何服务于TOE的描述。 注：发布配置管理计划的目的是使员工能够清楚的明白他们的职责。从整个配置管理系统的角度，配置管理计划 可以看做是一个输出文档（因为它可能作为配置管理系统的应用的部分而产生）。从具体项目的角度，可以将 它看成是使用文档，因为项目组成员使用它，以更理解在项目期间必须执行的步骤。配置管理计划为特定产品 定义了系统的使用方法，对于其他产品，同一系统演用看度可能不尽相同。这意殊着配置管理计划定义并描述 了公司在TOE开发期间使用的配置管理系统的输出。 3.4.10 配置管理系统configurationmanageaentsystem 开发者在产品生命周期期间，用于开发并维护产品配的规程和工具（包搭说文档）的集合。 注：配置管理系统可能具有不同的严格醒度和改能，高設别的配营理系筑可能是自动化的、具有缺陷修复、变更 控制、以及其他跟踪机制。 3.4.11 配置警理系统记录configurationmaaagementrscor2s 配置管理系统对重要的配置管理活动运行文裆化期同产生的输出。 法；配置雪理系统记录的例子是配置管理项变定应案意书，或者配置雪理项访问许可表， 3.4.12 配置管理工具configurationmanagertenttools 实现或支持配置管理系统的手动操作或音自款化的工具， 注：例如，TOE组成部分的版本管理工具， 3.4.13 配置管理使用文档 configuration maaagemer: usage documentation 配置管理系统的组成部分，描述了配置管系统是如何定义和使用的，例如使用手册、规则、工具和 规程文档。 3.4.14

配置管理输出configurationmanagementoatput 配置管理系统产生或实施的、与配置管理相关的结果。 注：这些配置管理相关结果可能表现为文档形式（如，填写的纸质表格、配置管理系统记录、日志数据、纸质和电子 输出数据)和行为（如执行配置管理规定的人工措施）。这样的配置管理输出的例子是配置清单、配置管理计划 和/或产品生命周期中的行为。 3.4.9 配置管理计划configurationmanagementplan 配置管理系统如何服务于TOE的描述。 注：发布配置管理计划的目的是使员工能够清楚的明白他们的职责。从整个配置管理系统的角度，配置管理计划 可以看做是一个输出文档（因为它可能作为配置管理系统的应用的部分而产生）。从具体项目的角度，可以将 它看成是使用文档，因为项目组成员使用它，以更理解在项目期间必须执行的步骤。配置管理计划为特定产品 定义了系统的使用方法，对于其他产品，同一系统演用看度可能不尽相同。这意殊着配置管理计划定义并描述 了公司在TOE开发期间使用的配置管理系统的输出。 3.4.10 配置管理系统configurationmanageaentsystem 开发者在产品生命周期期间，用于开发并维护产品配的规程和工具（包搭说文档）的集合： 注：配置管理系统可能具有不同的严格醒度和改能，高設别的配置营理系筑可能是自动化的、具有缺陷修复、变更 控制、以及其他跟踪机制。 3.4.11 配置警理系统记录configurationmaaagemenatrscor2s 配置管理系统对重要的配置管理后动运行文裆化期同产生的输出。 法；配置雪理系统记录的例子是配置管理项变定应案意书，或者配置雪理项访问许可表， 3.4.12 配置管理工具configurationmanagertenttools 实现或支持配置管理系统的手动操作或音自款化的工具， 注：例如，TOE组成部分的版本管理工具， 3.4.13 配置管理使用文档 configuration maaagemen: usage documentation 配置管理系统的组成部分，描述了配置管理系统是如何定义和使用的，例如使用手册、规则、工具和 诚业

配置管理输出configurationmanagementoatpat 配置管理系统产生或实施的、与配置管理相关的结果。 注：这些配置管理相关结果可能表现为文档形式（如，填写的纸质表格、配置管理系统记录、日志数据、纸质和电 输出数据)和行为（如执行配置管理规定的人工措施）。这样的配置管理输出的例子是配置清单、配置管理计 和/或产品生命周期中的行为。

配置管理系统configurationmanagementsysten

配置管理使用文档configurationmaaagemer：usagedocumentatior 配置管理系统的组成部分，描述了配置管理系统是如何定义和使用的，例如使用手册、规则 现程文档。

已完成的TOE从生产环境传送到客户手中。 注：产品生命周期的这个阶段可能包括开发场所的包装和存储，但是不包括未完成的TOE或部分TOE在不同开 发者或不同开发场所之间的传递。

开发者developer

负责TOE研发的组织。

开发development

与生成TOE实现表示有关的产品生命同期阶段。 注：在整个生命周期支持要求中，开发及其相关术语（开发者、开发)，包括更一般意义上的开发和生产。

3.5与脆弱性评定（AVA)类相关的术语和定义

图1CM和产品生命周期术语

可以在TOE运行环境中用来违反SFR的

可以在TOE运行环境中用来违反SFR的TOE

潜在脆弱性potentialvuinerability 可疑的，但尚未确认的弱点。 注，怀疑的过程是借助于一个假设的违反 SFR的攻击路径来进行的

残余脆弱性residual vulnerability

在TOE运行环境中不能被利用的弱点，但是可能被TOE运行环境中具有比预期更大攻 攻击者用于违反SFR。

脆弱性vulnerabinity

下列缩略语适用于本文件。

本章介绍ISO/IEC15408的主要概念，明确“TOE”的概念、目标读者，以及论述ISO/IEC15408其 余部分内容将采取的方法。

SO/IEC15408的主要概念，明确“TOE”的概念、目标读者，以及论述ISO/IEC15408其 取的方法，

ISO/IEC15408使用术语“TOE”。 TOE被定义为一组可能包含指南的软件、固件和/或硬件的集合。 尽管TOE在某些情况下由一个IT产品组成，但也不总是这样。TOE可以是一个IT产品、一 IT产品的一部分、一组IT产品、一种不可能形成产品的独特技术，或者以上这些情况的组合。

ISO/IEC15408在评估的对象上定义较灵活，未局限于公共理解的IT产品范围 O/IEC15408使用术语“TOE”。 TOE被定义为一组可能包含指南的软件、固件和/或硬件的集合。 尽管TOE在某些情况下由一个IT产品组成，但也不总是这样。TOE可以是一个IT产品、 产品的一部分、一组 IT产品、一种不可能形成产品的独特技术,或者以上这些情况的组合。

对于ISO/IEC15408而言，TOE和所有IT产品之间的确切关系在以下方面非常重要：对TOE 包含IT产品某部分的评估不应该与对整个IT产品的评估相混淆。 TOE的例子包括： ·： 软件应用； · 操作系统； 与操作系统组合在一起的软件应用； 与操作系统和工作站组合在一起的软件应用； ? 与工作站组合在一起的操作系统； 智能卡集成电路； 智能卡集成电路的密码协处理器； 包括所有终端、服务器、网络设备和软件的局域网； 数据库应用，但不包括与数据库应用正常关联的远程客户端软件

5.2.1TOE的不同表示

在ISO/IEC15408中，TOE可以以几种形式出现，如（对软件TOE来说）： 配置管理系统中的文件列表； 编译过的单一主拷贝； ·准备交付给客户的光盘和手册； ·已经安装和运行的版本。 所有这些都可看作是一个TOE：无论术语“TOE”用在ISO/IEC15408其余部分的何处，可根据上 下文来确定其含义，

5.2.2TOE的不同配置

一般来说，IT产品可以用多种方法配置：以不同的方法安装、使用不同的启用或禁用选项，由于在 [SO/IEC15408评估期间，它将确定TOE是否满足特定的要求，这种配置上的灵活性可能会导致很多 可题，因为TOE所有可能的配置必须满足要求。出于这些原因，通常在TOE的指南部分对TOE可能 的配置进行严格限制；也就是说，TOE的指南可能会不同于IT产品的通用指南。 操作系统产品就是这样一个例子。这种产品可以用多种方法进行配置（如，用户类型、用户数、允 许/禁止的外部连接类型、启用/禁用的选项等）。 如果同一款IT产品要成为一个TOE，并且依据一组合理的要求评估，则配置应该受到更加严密的 控制，因为许多选项（如允许所有类型的外部连接或系统管理员不需要被鉴别）将导致TOE不满足 要求。 出于这种原因，IT产品指南（允许多种配置）和TOE的指南（仅允许一种配置或者在安全相关方面 没有不同的配置）通常有所不同。 注意，如果TOE指南仍然允许多种配置，这些配置统称为“TOE”，其中的每种配置必须满足TOE 的指定要求。

编制ISO/IEC15408是确保评估满足消费者的需求，因为这是评估过程的基本目的和理击。

消费者可以使用评估结果来帮助决定一个TOE是否满足他们的安全需求，这些安全需求通 险分析和策略指导的结果。消费者也可以用这些评估结果来比较不同的TOE。 ISO/IEC15408为消费者，尤其是消费者群体和行业团体，提供一个独立于实现的结构，即保 （PP）环保标准，在其中以一种明确的方式表达他们的安全要求，

ISO/IEC15408为开发者准备并协助对其TOE的评估，以及标识由TOE满足的安全要求提供支 持，这些安全要求包含在一个与实现相关的ST中。ST可以基于一个或多个PP，来说明ST符合消费 者在这些PP中制定的安全要求。 ISO/IEC15408其次用于确定责任和行为，以便于提供TOE满足安全要求的必要证据。它也定义 了证据的内容和形式，

/IEC15408包含了评估者用于评判TOE与其安全要求是否符合的准则。ISO/IEC15408描 由评估者执行的通用行为。值得注意的是ISO/IEC15408没有详细说明执行这些行动应遵 。这些规程的更多信息见5.4。

虽然ISO/IEC15408主要是为了规范和评估TOE的IT安全特性，但它也可以作为对IT安全有 趣或有责任的团体的参考资料。其他能够从ISO/IEC15408所包含的信息中获益的团体有： a) 系统管理者和系统安全管理者：负责确定和满足该组织的IT安全策略和要求。 内部和外部审计员：负责评定IT解决方案（可以包含或由一个TOE组成）的安全性是否 足够。 c) 安全规划和设计师：负责规范IT产品的安全特性。 d) 批准者：负责批准在特定环境中使用某IT解决方案。 e 评估发起者：负责申请和支持一个评估。 评估授权机构：负责管理和监督IT安全评估程序

表1IS0/IEC15408使用指南

为了使评后结果真有更好的可比性，评估应在权威的评估体制框架内执行，该体制框架负责制定标 准、监控评估质量、管理评估机构和评估者必须符合的规章制度。 ISO/IEC15408不对规章制度框架提出要求。但是，不同评估机构的这些框架有必要一致，以达到 相互认可评估结果的言标， 使评估编果具育更好的可比性的第二种方法是使用通用方法达到这些结果。对于ISO/IEC15408，该 方法在评信方法（CEVD中给出。 通用评常方层的使用主要是确保评估给票的重复性和客观性，但议靠评信方法本身是不充分的 许多评信准则需要使月专业的判断和背景知识，而这些更难达到一致。为了增强评估给结论的一致性，最 终的评信结果可能提交翁认证过琶来处理。 认证运是对评信果的独立审查，并产生最终的证书或正式批文，该证书通常是公开的。要说明 的是，认证过谨是使得IT安全准则的应用达到蔓加一致的一种手段， 求信然制和认诉过主运行评估体制和过益的评估机构负责，不属ISO/1EC15403的范围

安全与资产保护有关，资产是赋予了价值的实体建筑标准规范范本，资产的例子包括： 文件或服务器的内容；选举中投票的真实性； 电子商务程序的可用性； 使用昂贵打印机的能力； ·机密设施的访问

但是如果过于主观的估价，几乎任何事物都可以成为资产。 资产放置的环境称为运行环境。运行环境方面的例子有： · 银行机房； 连接到互联网的计算机网络； ·局域网； ·一般办公环境。 许多资产均以信息的形式由IT产品存储、处理和传送，以满足信息所有者的要求。信息所有者为 了信息的可用性，会严格控制信息的传播和修改，并且资产受到保护措施的保护以抵御威胁。图2说明 了这些概念和关系。