GB/T 20274.4-2008 信息安全技术 信息系统安全保障评估框架 第4部分：工程保障

　　ICS 35 . 040 L 80

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 20274 . 4—2008

　　信息安全技术

　　信息系统安全保障评估框架

　　第 4 部分：工程保障

　　Information securitytechnology—

　　Evaluation framework forinformation systemssecurity assurance—

　　part4：Engineering assurance

　　2008-07-18 发布 2008-12-01 实施

　　中华人民共和国国家质量监督检验检疫总局中 国 国 家 标 准 化 管 理 委 员 会

　　

　　发

　　

　　布

　　GB/T 20274 . 4—2008

　　目 次

　　前言 Ⅲ

　　1 范围 1

　　2 规范性引用文件 1

　　3 术语和定义 1

　　4 本部分的结构 1

　　5 信息系统安全工程保障框架 2

　　5 . 1 信息系统安全工程保障概述 2

　　5 . 2 信息系统安全工程保障控制 2

　　5 . 3 信息系统安全工程能力成熟度级别 4

　　6 信息安全工程保障控制类结构 4

　　6 . 1 概述 4

　　6 . 2 安全工程保障控制类结构 4

　　6 . 3 安全工程保障控制子类结构 5

　　6 . 4 安全工程保障控制组件结构 5

　　7 PRM 安全工程保障控制类：风险过程 6

　　7 . 1 风险过程安全工程保障控制类介绍 6

　　7 . 2 系统定义(PRM_SDF) 7

　　7 . 3 评估威胁(PRM_ATT) 7

　　7(7).. 5(4) 评估影响(评估脆弱)性(PMAI(_)M(AV))L ) …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… 1(1)2(0)

　　8(7). 6 P EN(评)安(估)全(安)工(全)程(风)保(险)(障控制(PRM)_ 类(AS)：程…过…程… … … … … … … … … … … … … … … … … … … … … … … … … … 15

　　1 7

　　8 . 1 工程过程安全工程保障控制类介绍 17

　　8(8).. 3(2) 高层安全设计(确定安全要求)(( PEN(PEN)_HS(ISR)D)) 2(1)1(8)

　　8(8).. 5(4) 安全工程实施(详细安全设计)(( PEN(PEN)_SEE(DSD))) 2(2)3(2)

　　8(8).. 7(6) 监视安全态势(提供安全输入)(( PEN(PEN)_MS(PSI)P) ) 2(2)9(6)

　　8(8).. 9(8) 协调安全(管理安全)控(PE(制)N(PCOS(EN_))(M)S ) …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… 3(3)5(2)

　　9 PAS安全工程保障控制类：保障过程 36

　　9 . 1 保障过程安全工程保障控制类介绍 36

　　9(9).. 3(2) 建立保证证据(验证和确认安)全(P_EAE(S_VV))S) 3(3)9(7)

　　10 安全工程保障控制类能力级 41

　　1(1)0(0).. 2(1) 安全(概述)工 程…能…力…级…别…说…明… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… 4(4)1(1)

　　Ⅰ

　　GB/T 20274 . 4—2008

　　10 . 3 信息系统安全工程能力级别要求 44

　　参考文献 45

　　图 1 安全工程过程生命周期 3

　　图 2 安全工程保障控制类结构 4

　　图 3 安全工程保障控制子类结构 5

　　图 4 安全工程保障控制组件结构 6

　　图 5 风险过程说明 7

　　图 6 系统定义(PRM_SDF)安全工程保障控制子类分解 7

　　图 7 评估威胁(PRM_ATT)安全工程保障控制子类分解 8

　　图 8 评估脆弱性(PRM_AVL)安全工程保障控制子类分解 10

　　图 9 评估影响(PRM_AIM)安全工程保障控制子类分解 13

　　图 10 评估安全风险(PRM_ASR)安全工程保障控制子类分解 15

　　图 11 工程过程安全工程保障控制类介绍 18

　　图 12 确定安全要求(PEN_ISR)安全工程保障控制子类分解 18

　　图 13 高层安全设计(PEN_ HSD)安全工程保障控制子类分解 21

　　图 14 详细安全设计(PEN_DSD)安全工程保障控制子类分解 22

　　图 15 安全工程实施(PEN_SEE)安全工程保障控制子类分解 24

　　图 16 提供安全输入(PEN_PSI)安全工程保障控制子类分解 26

　　图 17 监视安全态势(PEN_MSP)安全工程保障控制子类分解 29

　　图 18 管理安全控制(PEN_MSC)安全工程保障控制子类分解 32

　　图 19 协调安全(PEN_COS)安全工程保障控制子类分解 35

　　图 20 保障过程安全工程保障控制类说明 37

　　图 21 验证和确认安全(PAS_VVS)安全工程保障控制子类分解 37

　　图 22 建立保证证据(PAS_EAE)安全工程保障控制子类分解 39

　　图 23 信息系统安全工程能力要求级别图 44

　　表 1 安全工程生命周期和过程域对应表 3

　　Ⅱ

　　GB/T 20274 . 4—2008

　　前 言

　　GB/T 20274《信息安全技术 信息系统安全保障评估框架》分为以下四个部分：

　　— 第 1 部分：简介和一般模型

　　— 第 2 部分：技术保障

　　— 第 3 部分：管理保障

　　— 第 4 部分：工程保障

　　本部分是 GB/T 20274 的第 4 部分 。

　　本部分由全国信息安全标准化技术委员会提出并归 口 。

　　本部分起草单位：中国信息安全产品测评认证中心 。

　　本部分主要起草人：吴世忠 、王海生 、陈晓桦 、王贵驷 、李守鹏 、江常青 、彭勇 、张利 、姚轶崭 、班晓芳 、李静 、王庆 、邹琪 、钱伟明 、江典盛 、陆丽 、孙成昊 、门雪松 、杜宇鸽 、杨再山 。

　　Ⅲ

　　GB/T 20274 . 4—2008

　　信息安全技术

　　信息系统安全保障评估框架

　　第 4 部分：工程保障

　　1 范围

　　GB/T 20274 的本部分建立了信息系统安全工程保障的框架，确立了组织机构启动 、实施 、维护 、评估和改进信息安全工程的指南和通用原则 。GB/T 20274 的本部分定义和说明了信息系统安全工程保障工作中反映组织机构信息安全工程保障能力的安全工程能力级，以及提供组织机构信息安全工程保障内容的安全工程保障控制类要求 。

　　GB/T 20274 的本部分适用于启动 、实施 、维护 、评估和改进信息安全工程的组织机构和涉及信息系统安全工程工作的所有用户 、开发人员和评估人员 。

　　2 规范性引用文件

　　下列文件中的条款通过 GB/T 20274 的本部分的引用而成为本部分的条款 。凡是注 日期的引用文件，其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否 可 使 用 这 些 文 件 的 最 新 版 本 。 凡 是 不 注 日 期 的 引 用 文 件，其 最 新 版 本 适 用 于 本部分 。

　　GB/T 20274 . 1 信息安全技术 信息系统安全保障评估框架 第 1 部分：简介和一般模型

　　3 术语和定义

　　GB/T 20274 . 1 确定的以及以下术语和定义适用于 GB/T 20274 的本部分 。

　　3 . 1 . 1

　　确认 validation

　　解决方案满足用户的运行安全需求 。

　　3 . 1 . 2

　　验证 verification

　　解决方案满足安全要求 。

　　4 本部分的结构

　　GB/T 20274 的本部分的组织结构如下：

　　a) 第 1 章介绍了 GB/T 20274 的本部分的范围;

　　b) 第 2 章介绍了 GB/T 20274 的本部分所规范引用的标准;

　　c) 第 3 章描述了适用于 GB/T 20274 的本部分的术语和定义;

　　d) 第 4 章描述了 GB/T 20274 的本部分的组织结构;

　　e) 第 5 章描述了信息系统安全工程保障框架，并进一步概述了工程保障控制类和工程能力级;

　　f) 第 6 章描述了信息安全工程保障控制类的规范描述结构和要求;

　　g) 第 7 章到第 9 章详述了提供信息安全工程保障内容的 3 个信息安全工程类的详细要求;

　　1

　　GB/T 20274 . 4—2008

　　h) 第 10 章详述了反应组织机构信息安全工程保障能力的安全工程能力级;

　　i) 参考文献给出了 GB/T 20274 的本部分的参考文献 。

　　5 信息系统安全工程保障框架

　　5 . 1 信息系统安全工程保障概述

　　本标准第 1 部分中提出了信息安全保障模型(参见本标准第 1 部分图 3) ,在模型中，描述了信息系统安全中保障要素(技术 、工程 、管理和人员)、安全特征和生命周期三者的关系 。

　　信息安全工程保障框架是信息系统安全保障框架的一个重要组成部分，信息安全工程保障主要涉及同信息系统安全工程建设实施相关的工程保障内容和要求，信息系统安全工程保障结合了信息安全工程保障建设的特殊内容和要求，建立了信息安全管理保障的能力成熟度模型 。

　　信息安全工程保障能力成熟度模型包含了两个相互依赖的维度，即 “安全工程保障控制维 ”和 “安全工程保障能力成熟度级维 ”，它反映了信息安全工程保障在控制措施和能力成熟度这两个方面的要求 。

　　a) “安全工程保障控制维 ”由信息安全工程保障控制组成，它建立了组织机构信息安全工程保障框架的内容和工作范围 。信息安全工程保障控制使用类—子类—组件的层次化结构，每个信息安全工程保障控制类反映了信息安全工程保障特定领域工作的范围和内容，是信息安全工程保障特定领域工作最佳实践的总结 。在本部分中，共包含了 3 个信息安全工程保障控制类，它们给出了信息安全工程保障中 “做什么 ”这个关于内容和范围的答复;

　　b) “安全工程保障能力成熟度级维 ”由六级能力成熟度级别组成，它代表了组织机构实施信息安全工程保障控制的能力 。安全工程保障能力成熟度级同特定的安全工程保障控制类相结合，给出了信息安全工程保障中 “做得如何好 ”这个关于能力的答复，同时能力成熟度方法也为组织机构提供了可以持续改进的长效机制 。

　　通过设置这两个相互依赖的维，信息安全工程保障框架在各个能力级别上覆盖了整个安全工程活动范围 。

　　5 . 2 信息系统安全工程保障控制

　　5 . 2 . 1 信息系统安全工程保障控制类

　　本部分中将信息系统安全工程划分为三个基本的过程域(即信息系统安全工程保障控制类)：风险 、工程和保障 。虽然这些域决不是互相独立的，但可以分开考虑它们 。在最简单的级别中，风险过程识别并优先级排序对开发出的产品或系统的内在危险 。安全工程过程与其他工程学科共同作用来决定和实施危险引起的问题的解决方案 。最后，保障过程建立对安全解决方案的信心并将这种信心传递给用户 。

　　5 . 2 . 2 信息系统安全工程生命周期

　　信息系统安全更强调在整个生命周期中融入安全并强调动态可持续改进的能力发展，在信息系统安全工程过程中，主要是基于信息系统安全工程的生命周期思想有效地提炼出信息系统安全工程的生命周期中的一些关键的过程域，通过对这些过程域的基本实施的要求，覆盖信息系统安全工程的整个生命周期，再通过每个过程域中执行通用实践的能力实践 、改进每个过程域的执行能力 。这样才能真正有效 、科学 、可重复 、可不断改进地 、动态发展地实现信息系统安全保障的 目标 。

　　安全工程过程生命周期包含以下根据信息流向划分的安全工程阶段：挖掘安全需求 、定义安全要求 、设计体系结构 、详细安全设计 、实现系统安全和有效性评估 。有效性评估贯穿整个信息系统工程过程的所有阶段，以确保系统能够满足用户需求 。 图 1 反映工程过程中各活动之间的关系，箭头表明各活动之间的信息流向，而不是活动的顺序或时限 。

　　2

　　GB/T 20274 . 4—2008

　　图 1 安全工程过程生命周期

　　5 . 2 . 3 安全工程生命周期和过程域对应关系安全工程生命周期同过程域关系如表 1 :

　　表 1 安全工程生命周期和过程域对应表

　　生命周期

　　描 述

　　相关安全工程保障控制子类

　　挖掘安全需求

　　本阶段建立项 目 组 织，了 解 系 统 的 上 下 文 环 境，决 定开始进行安全工程，制定初步计划和预算等 。

　　本阶段帮助用 户 挖 掘 并 理 解 完 成 系 统 的 任 务 和 业 务所需的信息保 护 需 求 。 信 息 保 护 需 求 的 确 定 建 立 在 对系统的安全风险分析的基础上 。

　　风险过程(PRM)

　　系统定义(PRM_SDF)

　　评估威胁(PRM_ATT)

　　评估脆弱性(PRM_AVL)

　　评估影响(PRM_AIM)

　　评估安全风险(PRM_ASR)

　　定义安全要求

　　本阶段将已识 别 出 来 的 信 息 保 护 需 求 落 实 到 各 子 系统中，包括开发 系 统 安 全 上 下 文，初 步 的 系 统 安 全 运 行设想和安全要求基线等 。

　　工程过程(PEN)

　　确定安全要求(PEN_ISR)

　　设计体系结构

　　本阶段进行分析候选体系结 构 、分 配 安 全 服 务 和 选 择安全机制，从而完成安全功 能 分 析 和 落 实 。选 择 适 用 的组件或元件并把安全功能分配 给 这 些 元 件，同 时 描 述 这些元件之间的关系 。

　　提供安全输入(PEN_PSI)

　　高层安全设计(PEN_ HSD)

　　详细安全设计

　　本阶段分析设 计 的 约 束 条 件，分 析 折 衷 办 法，进 行 详细的系统和安 全 设 计 并 考 虑 生 命 周 期 支 持 。 检 查 所 有系统安全需求 落 实 到 了 组 件 。 最 终 的 详 细 安 全 设 计 结果为实现系统提供充分的组件和接口描述信息 。

　　详细安全设计(PEN_DSD)

　　3

　　GB/T 20274 . 4—2008

　　表 1(续)

　　生命周期

　　描 述

　　相关安全工程保障控制子类

　　实现系统安全

　　本阶段把系统设计转移到运 行，参 与 对 所 有 系 统 问 题的多学科综合分析，并为认 证 认 可 活 动 提 供 输 入 。例 如验证系统已经实现了对抗威胁 评 估 中 识 别 出 的 威 胁;追踪与系统实现和测试活动相关 的 信 息 保 护 保 障 机 制;为系统生命周期支 持 计 划 、运 行 规 程 、培 训 材 料 维 护 提 供输入 。本阶段信息系统已到 位 并 开 始 运 行，通 过 定 期 的评估和不断监视系统的安全状 况，确 定 如 何 获 得 更 高 的安全性能和效率等来满足用户 变 化 的 安 全 需 求，进 行 软硬件升级和修改并进行相应的测试 。

　　工程过程(PEN)

　　安全工程实施(PEN_SEE)

　　协调安全(PEN_COS)

　　监视安全态势(PEN_MSP)

　　管理安全控制(PEN_MSC)

　　有效性评估

　　本阶段关 注 信 息 保 护 的 有 效 性 — 系 统 是 否 能 够 保证其处理的信息的保密性 、完 整 性 、可 用 性 、鉴 别 和 不 可否认性，确保成功完成使命 。

　　保障过程(PAS)

　　验 证 和 确 认 安 全 ( PAS _ VVS)

　　建立保障论据(PAS_EAE)

　　5 . 3 信息系统安全工程能力成熟度级别

　　在工程过程组件中，给出了信息安全工程过程所涉及的过程域，它是信息安全工程过程中提炼出来的实践的最佳反映 。工程过程能力是遵循一个工程过程所能达到的可量化范围，通过对组织机构执行安全工程每个过程域能力反映了组织机构在执行信息安全工程达到预定的成本 、功能和质量 目标上的度量 。

　　在工程保障中，安全工程过程能力模型将列出并描述安全工程过程的各个能力级别，这样通过对安全工程过程域的执行范围和每个相应安全工程过程域的执行能力的综合，就可以更完善地对组织机构信息安全工程过程进行科学 、公正 、可度量 、分级的评估 。

　　6 信息安全工程保障控制类结构

　　6 . 1 概述

　　本章定义了本部分所使用的信息安全工程保障控制类的结构 。信息安全工程保障控制类以安全工程保障控制类 、安全工程保障控制子类 、安全工程保障控制组件来表达 。

　　6 . 2 安全工程保障控制类结构

　　每个安全工程保障控制类包括一个安全工程保障控制类名 、安全工程保障控制类介绍以及一个或多个安全工程保障控制子类 。 图 2 描述了本部分中所使用的安全工程保障控制类的结构 。

　　图 2 安全工程保障控制类结构

　　4

　　GB/T 20274 . 4—2008

　　安全工程保障控制类结构的详细描述如下：

　　a) 安全工程保障控制类名：安全工程保障控制类名提供了标识和划分安全工程保障控制类所必需的信息，每个安全工程保障控制类都有一个唯一的名称 。安全工程保障控制类的分类信息由三个英文字符的简名组成，此简名将用于该安全工程保障控制类的子类的简名规范中;

　　b) 安全工程保障控 制 类 介 绍：安 全 工 程 保 障 控 制 类 介 绍 部 分 提 供 了 该 安 全 工 程 保 障 控 制 类 定义 、要求和 目 的等的整体描述 。安全工程保障控制类介绍中用图来具体描述此域中的子类 、组件组成结构;

　　c) 安全工程保障控制子类：安全工程保障控制子类部分对该安全工程保障控制类所包含的子类进行了详细描述 。一个安全工程保障控制类包含了一个或多个安全工程保障控制子类 。

　　6 . 3 安全工程保障控制子类结构

　　一个安全工程保障控制类包含了一个或多个安全工程保障控制子类 。每个安全工程保障控制子类包含一个安全工程保障控制子类名 、一个安全保障工程 目 的和一个或多个实现此安全工程保障 目 的的安全工程保障控制组件(控制措施)。 图 3 描述了安全工程保障控制子类的描述结构 。

　　图 3 安全工程保障控制子类结构

　　安全工程保障控制子类结构的详细描述如下：

　　a) 安全工程保障控制子类名：安全工程保障控制子类名部分提供了标识和划分安全工程保障控制子类所必需的分类和描述信息，每个安全工程保障控制子类有一个唯一的名称 。安全工程保障控制子类的分类信息由七个英文字符的简名组成，前三个英文字符与其所属的安全工程保障控制类名相同，第四个字符是下划线用于连接安全工程保障控制类名和安全工程保障控制子类名，最后三个英文字符是安全工程保障控制子类名，例如 XXX_ YYY 。 唯一的简名安全工程保障控制子类名为安全工程保障控制组件提供了引用名;

　　b) 安全保障工程目的：安全工程保障目的描述了此安全工程保障控制子类所要达到的 目 的;

　　c) 安全工程保障控制组件：一个安全工程保障控制子类包含了一个或多个安全工程保障控制组件 。安全工程保障控制组件就是实现安全工程保障目的的信息安全保障工程控制措施 。

　　6 . 4 安全工程保障控制组件结构

　　安全工程保障控制组件是实现安全工程保障目的的信息安全保障工程控制措施 。每个安全工程保障控制组件包括一个安全工程保障控制组件名 、一个安全工程保障控制组件控制和一个可选的安全工程保障控制组件注解 。 图 4 描述了安全工程保障控制组件的描述结构 。

　　5

　　GB/T 20274 . 4—2008

　　图 4 安全工程保障控制组件结构

　　安全工程保障控制组件结构的详细描述如下：

　　a) 安全工程保障控制组件名：安全工程保障控制组件名用于标识安全工程保障控制组件 。安全工程保障控制组件的简名是由安全工程保障控制组件名，后面使用句点作为连接符，在句点连接符后用阿拉伯数字按顺序标明不同的组件构成的 。

　　b) 安全工程保障控制组件控制：安全工程保障控制组件控制部分定义了满足其安全工程保障控制子类安全工程保障目的特定的控制措施 。

　　c) 安全工程保障控制组件注解：可选的安全工程保障控制组件注解部分为该安全工程保障控制组件提供了进一步描述性的解释说明，以及实施该控制措施的最佳实践的建议等 。安全工程保障控制组件注解中所提供的最佳实践等内容可能不一定适合所有的情况，本部分的使用者也可以根据其自身信息安全工程保障的特殊需求和要求使用其他更合适的实施方法 。

　　7 PRM 安全工程保障控制类：风险过程

　　7 . 1 风险过程安全工程保障控制类介绍

　　安全工程的一个主要目标是降低风险 。风险评估是识别尚未发生的问题的过程 。风险的评估是通过检查威胁的可能性 、脆弱性并考虑意外事件的潜在影响 。可能性是不确定的因素，所以它会因特定的环境而不同 。这意味着可能性只能在一定的限制下进行预测 。另外，评估特定风险的影响也具有不确定性，因为意外事件可能不像所预料的那样出现 。这些因素可能有很大的不确定性影响到预测的正确性，所以安全的规划和评定就会很难 。这个问题的一个不完全解决方法是用技术手段来检测意外事件的发生 。

　　意外事件由三项构成：威胁 、脆弱性和影响 。脆弱性是资产可能被威胁利用的属性，也包括弱点 。如果威胁或脆弱性其一不存在，就不会有意外事件，也就没有风险 。风险管理是评估和量化风险并设定组织的风险可接受程度的过程 。管理风险是安全管理的重要部分 。

　　通过保护措施的实施降低风险，风险可以描述威胁 、脆弱性 、影响，或者风险本身 。然而，降低所有风险或完全根除任一特定风险都是不可能的 。 这主要是因为风险降低的成本，以及相关的不确定性 。因此，总是必须接受一些残余风险 。在不确定性很高的情况下，由于不能精确地描述风险，接受风险会有很大问题 。信息安全工程的过程域包括确保服务提供方组织进行分析威胁 、脆弱性 、影响，并综合这些活动所得到的威胁 、脆弱性和影响信息进行风险分析，然后得到风险信息 。

　　6

　　GB/T 20274 . 4—2008

　　风险过程说明见图 5 。

　　图 5 风险过程说明

　　7 . 2 系统定义(PRM_SDF)

　　7 . 2 . 1 安全工程保障目的

　　系统定义安全工程保障控制子类的目的是识别信息系统的任务和使命，即系统的任务要求和它所要达到的能力，这些能力包括系统应执行的功能 、所需的接口及这些接口相关的能力 、所要处理的信息 、所支持的运行结构以及运行的威胁等 。

　　图 6 描述了系统定义(PRM_SDF)安全工程保障控制子类组成结构 。

　　图 6 系统定义(PRM_SDF)安全工程保障控制子类分解

　　7 . 2 . 2 PRM_SDF.1 详细系统描述

　　7 . 2 . 2 . 1 安全工程保障控制组件控制

　　描述信息系统的 目的 、任务和使命;信息系统的信息类划分 、边界 、信息流;信息系统的业务体系 、技术体系和管理体系等 。

　　7 . 2 . 2 . 2 安全工程保障控制组件注解

　　详细系统描述实际上就是确定 STOE 的过程，这是非常重要的一个步骤，是后续各个步骤的基础 。因为只有明确定义和描述系统的范围等性质，对系统的分析才有意义，才能准确和有效 。

　　应按照 GB/T 20274 第 1 部分附录 C 的图 C. 1 信息系统安全保障评估信息系统描述规范中的要求，描述信息系统的使命，信息系统的环境 、评估边界和接 口 、安全域;再分别从信息系统的管理体系 、技术体系 、业务体系等角度对信息系统进行详细描述 。

　　7 . 3 评估威胁(PRM_ATT)

　　7 . 3 . 1 安全工程保障目的

　　评估威胁安全工程保障控制子类的 目标是对系统安全的威胁进行标识和特征化 。

　　评估威胁安全工程保障控制子类的目的在于标识安全威胁及其性质和特征 。

　　本安全工程保障控制子类产生的威胁信息将与评估脆弱性得到的脆弱性信息以及评估影响得到的

　　7

　　GB/T 20274 . 4—2008

　　影响信息一起用于评估安全风险中 。虽然收集威胁 、脆弱性和影响信息的活动被分组为几个单独的过程域，但它们是互相依赖的 。其目标是要得到足以用作判定的威胁 、脆弱性和影响的组合 。 因此，确定威胁调查的范围应结合相应的脆弱性和影响 。

　　威胁容易变化，所以必须定期监视威胁，以确保一直维持理解本过程域产生的结果 。

　　图 7 描述了评估威胁(PRM_ATT)安全工程保障控制子类组成结构 。

　　图 7 评估威胁(PRM_ATT)安全工程保障控制子类分解

　　7 . 3 . 2 PRM_ATT.1 标识自然威胁

　　7 . 3 . 2 . 1 安全工程保障控制组件控制

　　标识由 自然原因引起的威胁 。

　　由 自然原因引起的威胁，包括地震 、海啸和台风 。不过，并非有威胁的所有 自然灾害都会在所有地方发生 。例如，在大量内陆中心地带就不可能出现台风 。 因此，重要的是标识出在特定地方到底会发生哪一种具有威胁的 自然灾害 。

　　7 . 3 . 2 . 2 安全工程保障控制组件注解

　　评估所需的大量信息可以从实际清单和自然现象数据库中获得 。这些信息是具有价值的，它们也可能很通用而要谨慎使用这些信息 — 可能需要根据特定环境来描述 。

　　标识自然威胁的工作产品示例如下：

　　a) 适用的 自然威胁表 — 文档化自然威胁的特征和可能性的表格 。

　　7 . 3 . 3 PRM_ATT.2 标识人为威胁

　　7 . 3 . 3 . 1 安全工程保障控制组件控制

　　标识出无意的或有意的人为原因所引起的威胁 。

　　人为原因引起的威胁基本上有两种：一是由意外原因引起的威胁;二是由有意行为引起的威胁 。某些人为威胁在目标环境中并不适用，应在进一步分析后予以取消 。

　　标识人为威胁的工作产品示例如下：

　　a) 威胁情景描述 — 描述威胁是如何工作的 。

　　b) 威胁严重性估计 — 衡量威胁的可能性 。

　　8

　　GB/T 20274 . 4—2008

　　7 . 3 . 3 . 2 安全工程保障控制组件注解

　　有时，描绘威胁将会如何发生的情景，有助于理解故意威胁 。一般人为威胁数据库的使用，应考虑它们的完整性和关联性 。

　　7 . 3 . 4 PRM_ATT.3 标识威胁的测量块

　　7 . 3 . 4 . 1 安全工程保障控制组件控制

　　标识特定环境中合适的测量块和适用范围 。

　　大多数的 自然威胁和许多人为威胁都有其与之相关的测量块 。 大多数情况下，整个的测量块并不适用于特定情况 。 因此，在特定情况下，有时需要最大化事件发生概率，有时需要最小化事件发生的概率，这样考虑才恰当 。

　　7 . 3 . 4 . 2 安全工程保障控制组件注解

　　在对某一特定威胁没有可接受的度量标准单位时，应生成针对该位置的度量标准单位 。恰当的话，应该在测试表关系中对相关范围和度量标准单位进行描述 。

　　标识威胁的测量块的工作产品示例如下：

　　a) 威胁表，包括测量块和所在位置范围 。

　　7 . 3 . 5 PRM_ATT.4 评估威胁源能力

　　7 . 3 . 5 . 1 安全工程保障控制组件控制

　　评估人为威胁的威胁源的能力和动机 。

　　本安全工程保障控制组件集确定成功对系统进行攻击的潜在的人类敌对势力的才能和能力 。才能指的是敌对者的攻击知识(例如，他们是否拥有知识 、经过训练)。能力则衡量一个有才能的敌手能够进行攻击的可能性(例如，他们是否拥有资源)。

　　7 . 3 . 5 . 2 安全工程保障控制组件注解

　　人为的故意威胁在很大程度上取决于威胁源的能力以及供威胁支配的资源 。 因此，经验欠缺的黑客如果获得了经验丰富 、能力高的黑客的工具，将会造成更危险的威胁，但话说回来，还是不如经验丰富的黑客自己来使用更危险 。但是，缺乏经验的黑客又可能造成非故意的伤害，经验丰富的黑客则不会 。除威胁源的能力之外，对威胁源所拥有资源的评估，应该与威胁源的攻击动机一起考虑，因为攻击的动机大小往往与 目标资产的吸引力有关 。

　　威胁可能按顺序或并发地多次进行攻击来达到其预期 目标 。应考虑顺序或并发的多次攻击的影响，威胁场景研究有助于此 。

　　评估威胁源能力的工作产品示例如下：

　　a) 威胁源描述 — 能力评估和描述 。

　　7 . 3 . 6 PRM_ATT.5 评估威胁的可能性

　　评估威胁事件发生的可能性 。

　　7 . 3 . 6 . 1 安全工程保障控制组件控制

　　评估威胁事件发生的可能性是怎样的 。对自然事件发生的机会以及故意行为或个别意外事件的评估中，需要考虑多种因素 。考虑的诸多因素并不一定要进行计算或衡量，只需要报告中有一致的度量标准 。

　　7 . 3 . 6 . 2 安全工程保障控制组件注解

　　这是一件复杂的概率计算，因为许多因素的概率都是变化的 。就评估的准确性和有效性而言，任何可能性的估计都是不确定的因素 。应分别报告各个可能性评估的不确定性以避免混淆 。无论如何，度量和可能性都将存在不确定性 。通常，保持各个不确定因素分别描述则会更有效，这也是一种混合的表示法，分开处理以便进一步分析数据的时候，能够分辨出是对工作数据本身还是对数据的不确定性的处理 。

　　a) 威胁事件可能性评估 — 描述威胁的可能性的报告 。

　　9

　　GB/T 20274 . 4—2008

　　7 . 3 . 7 PRM_ATT.6 监视威胁及其特征

　　监视威胁分布情况及威胁特征的不断变化 。

　　7 . 3 . 7 . 1 安全工程保障控制组件控制

　　任何位置和状态下的威胁分布情况都是动态的 。新的威胁可能变得相关，而现有威胁的特征也可能发生变化 。 因此有规律地监视现有威胁及其特征并检查新的威胁很重要 。本安全工程保障控制组件与标识协调机制(PEN_ISR)中的 “监视威胁 、脆弱性 、影响和环境变化 ”安全工程保障控制组件的一般监视活动紧密相连 。

　　7 . 3 . 7 . 2 安全工程保障控制组件注解

　　由于威胁可能发生变化，因此在特定环境中可能多次进行评估 。但是，重复进行威胁评估不能代替对威胁的监视 。

　　a) 威胁监控报告 — 描述威胁监控结果的文档 。

　　b) 威胁变化报告 — 描述威胁分布情况变化的文档 。

　　7 . 4 评估脆弱性(PRM_AVL)

　　7 . 4 . 1 安全工程保障目的

　　标识和特征化系统的安全脆弱性 。

　　评估安全脆弱性的 目标是获得对一给定环境中系统安全脆弱性的理解 。

　　评估安全脆弱性的 目 的在于标识和特征化系统的安全脆弱性 。本安全工程保障控制组件包括分析系统资产 、定义具体的脆弱性，以及系统脆弱性的全面评估 。与安全风险和脆弱性评估相关的术语因上下文环境而不同 。在本标准中，“脆弱性 ”除了传统所说的弱点 、安全漏洞或可能被威胁攻击的系统中的信息流外，还指系统可能被恶意利用的方面 。这些脆弱性独立于任何特定的威胁或攻击 。 可以在系统的生命周期中的任何时候执行这一系列脆弱性评估活动，来支持在已知环境中的对系统进行开发 、维护或运行等决策 。

　　图 8 描述了评估脆弱性(PRM_AVL)安全工程保障控制子类组成结构 。

　　图 8 评估脆弱性(PRM_AVL)安全工程保障控制子类分解

　　7 . 4 . 2 PRM_AVL.1 选择脆弱性分析方法

　　选择用于标识和特征化给定环境中安全系统脆弱性的方法 、技术和标准 。

　　10

　　GB/T 20274 . 4—2008

　　7 . 4 . 2 . 1 安全工程保障控制组件控制

　　本组件包括定义系统建立安全脆弱性的方法，这种方法允许标识和特征化安全脆弱性，包括根据威胁及其可能性 、运行功能 、安全要求或其他相关过程域对脆弱性进行分类和优先级排列 。通过标识分析的深度和广度，安全工程师和顾客可以确定评估范围是否包括目标系统以及分析的全面性 。应在预先安排和指定时间内，在一个已知的并记录有配置的框架内进行分析 。分析的方法论应包括预期结果，应清楚地描述分析的具体目标 。

　　7 . 4 . 2 . 2 安全工程保障控制组件注解

　　脆弱性分析方法可以是现有的 、经裁剪的，也可以是专门针对系统运行和给定环境定制的 。分析方法通常以 PRM_ATT “评估安全风险 ”中的风险分析方法论为基础或相一致 。要注意的是并不提供有关威胁 、能力和价值的理解，这时的方法论必须针对其范围或采用一系列可用假设条件 。

　　分析脆弱性的方法可以是定量的或定性的 。通常的脆弱性分析反映可能性 。攻击结果可以书面报告的形式表达，攻击本身可以论述证明 。

　　至少有两种不同的方法来标识脆弱性 。这两种方法为基于分析的方法或基于测试的方法 。基于测试的方法对于标识现存的脆弱性，且测试内容中含有已知威胁，是很好的方法 。基于分析的方法，对于标识新的脆弱性则是最好的方法，那些脆弱性并不会立即被利用但会随另一安全问题的出现而被利用 。选择脆弱性分析方法论时还可考虑的其他选择包括基于定量或定性的方法，还应该考虑对分析和测量的完整性的控制能力 。

　　工作产品示例：

　　a) 脆弱性分析方法 — 发现和描述系统安全脆弱性的方法，包括分析 、报告和跟踪过程 。

　　b) 脆弱性分析格式 — 为保证方法规范化，描述脆弱性分析结果的格式 。

　　c) 攻击方法论和工作原理 — 包括执行攻击测试的 目标和方法 。

　　d) 攻击规程 — 执行攻击测试的详细步骤 。

　　e) 攻击计划 — 包括资源 、时间安排和攻击方法论的描述 。

　　f) 穿透研究 — 以标识未知脆弱性为 目标的攻击场景的分析和实施 。

　　g) 攻击场景 — 描述将要进行尝试的具体攻击 。

　　7 . 4 . 3 PRM_AVL.2 标识脆弱性

　　标识系统安全脆弱性 。

　　7 . 4 . 3 . 1 安全工程保障控制组件控制

　　系统的安全和非安全的相关部分中都可能存在系统脆弱性 。支持安全功能或与安全机制配合的非安全机制中经常有可利用的脆弱性 。应遵循选择脆弱性分析方法(PRM_ AVL. 1) 中的攻击场景方法，以便能确认脆弱性 。应记录发现的所有系统脆弱性 。

　　7 . 4 . 3 . 2 安全工程保障控制组件注解

　　在本实践中，脆弱性被看成是系统的固有问题，而不考虑任何威胁的可能性 。可以参照威胁分析的结果来对脆弱性进行优先级排列 。攻击不可重现，使开发对策的难度较大 。

　　可根据 PRM_ASR“评估安全风险 ”中优先级排列的功能 、PEN_ ISR “确定安全要求 ”中的业务优先级和 目标来标识脆弱性 。此外，PRM_AIM“评估影响 ”中的资产也必须计算在内 。

　　工作产品示例：

　　a) 描述系统面临的各种攻击的脆弱性清单 。

　　b) 包括攻击测试结果的穿透轮廓(例如脆弱性)。

　　7 . 4 . 4 PRM_AVL.3 收集脆弱性数据

　　收集与脆弱性性质相关的数据 。

　　11

　　GB/T 20274 . 4—2008

　　7 . 4 . 4 . 1 安全工程保障控制组件控制

　　脆弱性具有其自身的性质，本安全工程保障控制组件意在收集与这些性质相关的数据 。脆弱性的测量块可以与 PRM_ATT. 3 “标识威胁的测量块 ”中的威胁的测量块相同 。应标识并收集脆弱性被利用的难易程度以及脆弱性出现的可能性的数据 。

　　7 . 4 . 4 . 2 安全工程保障控制组件注解

　　通过本活动收集起来的脆弱性数据以后将被用在 PRM__ASR “评估安全风险 ”。因此，以一种易于PRM_ASR使用的格式收集和存贮脆弱性数据显得非常重要 。无论如何，度量和可能性都将存在不确定性 。通常，保持各个不确定因素分别描述则会更有效，分开处理以便进一步分析数据的时候，能够分辨出是对工作数据本身还是对数据的不确定性的处理 。

　　工作产品示例：

　　a) 脆弱性性质表 — 记录系统或产品脆弱性特征的表 。

　　7 . 4 . 5 PRM_AVL.4 合成系统脆弱性

　　评估系统脆弱性并将特定脆弱性及各种特定脆弱性的组合结果进行综合收集 。

　　7 . 4 . 5 . 1 安全工程保障控制组件控制

　　分析脆弱性或脆弱性的组合会让系统产生的问题 。应分析脆弱性的附加特征，例如脆弱性被利用的可能性以及成功利用脆弱性的机会 。分析结果也可包括处置合成的脆弱性的推荐方法 。

　　7 . 4 . 5 . 2 安全工程保障控制组件注解

　　需要收集脆弱性分析和攻击的结果 。应足够详细地标识和文件描述发现的所有脆弱性及其被利用的潜在可能性，以便客户做出有关对策的决定 。

　　工作产品示例：

　　a) 脆弱性评估报告 — 包括定性或定量描述让系统产生问题的脆弱性，同时包括攻击的可能性 、成功的可能性及攻击产生的影响 。

　　b) 攻击报告 — 记录攻击的结果及结果的分析的报告，其中包括已发现的脆弱性 、被利用的潜在可能性和推荐的处置方法等 。

　　7 . 4 . 6 PRM_AVL.5 监视脆弱性及其特征监视脆弱性的不断变化及其特征的变化 。

　　7 . 4 . 6 . 1 安全工程保障控制组件控制

　　任何位置和状态下的脆弱性分布情况都是动态的 。新的脆弱性会变得有相互关系，现有脆弱性的特征可能变化 。 因此，监视现有脆弱性及其特征并定期检查新的脆弱性很重要 。本安全工程保障控制组件与 PEN_MSP. 2 监视威胁 、脆弱性 、影响 、风险和环境变化的一般监视活动紧密相连 。

　　7 . 4 . 6 . 2 安全工程保障控制组件注解

　　由于脆弱性可能发生变化，在给定环境中可能多次进行评估活动 。但是，重复的脆弱性评估不能代替对脆弱性的监视 。

　　工作产品示例：

　　a) 脆弱性监视报告 — 描述脆弱性监视结果的文档 。

　　b) 脆弱性变化报告 — 描述新的或变化了的脆弱性的文档 。

　　7 . 5 评估影响(PRM_AIM)

　　7 . 5 . 1 安全工程保障目的

　　评估影响的 目 的在于标识对系统的影响，并评估影响发生的可能性 。影响可能是有形的，例如收入的损失或经济惩罚;也可能是无形的，例如声誉和信誉的损失 。

　　本安全工程保障控制子类的 目标是标识和特征化风险对系统的安全影响 。

　　图 9 描述了评估影响(PRM_AIM)安全工程保障控制子类组成结构 。

　　12

　　GB/T 20274 . 4—2008