1、ICS 35.040 L 80 GB 和国国家标准11: ./、中华人民GB/T 20274.4-2008 信息安全技术信息系统安全保障评估框架第4部分:工程保障Information security technology-Evaluation framework for information systems security assurance Part 4: Engineering assurance 2008-07-18发布中华人民共和国国家质量监督检验检疫总局中国国家标准化管理委员会2008-12-01实施发布GB/T 20274.4-2008 目次前言.m 1 范围2 规范性引用
2、文件3 术语和定义4 本部分的结构.5 信息系统安全工程保障框架.25. 1 信息系统安全工程保障惭述.2 5. 2 信息系统安全工程保障控制.2 5. 3 信息系统安全工程能力成熟度级别.46 信息安全工程保障控制类结构46. 1 概述46.2 安全工程保障控制类结构46.3 安全工程保障控制子类结构.6.4 安全工程保障控制组件结构7 PRM安全工程保障控制类:风险过程. 7.1 风险过程安全工程保障控制类介绍.6 7.2 系统定义CPRM_SDF). 7 7.3 评估威胁CPRM_ATT)77.4 评估脆弱性CPRM_AVL).10 7.5 评估影响CPRM_AIM)127.6 评估安全
3、风险CPRM_ASR)8 PEN安全工程保障控制类:工程过程.17 8. 1 工程过程安全工程保障控制类介绍.178.2 确定安全要求CPEN_ISR) 18 8.3 高层安全设计CPEN_HSD).218.4 详细安全设计CPEN_DSD)8.5 安全工程实施CPEN_SEE)238. 6 提供安全输人CPEN_PSD 26 8. 7 监视安全态势CPEN_MSP)298.8 管理安全控制CPEN_MSC)328.9 协调安全CPEN_COS). 9 PAS安全工程保障控制类:保障过程. 9. 1 保障过程安全工程保障控制类介绍.36 9.2 验证和确认安全CPAS_VVS) . 37 9.
4、 3 建立保证证据CPAS_EAE)3910 安全工程保障控制类能力级.U10.1 惭述.41 10.2 安全工程能力级别说明.41 GB/T 20274.4-2008 10.3 信息系统安全工程能力级别要求.44 参考文献.45 图l安全工程过程生命周期.3 图2安全工程保障控制类结构.4 图3安全工程保障控制子类结构. 图4安全工程保障控制组件结构.6 图5风险过程说明.7 图6系统定义(PRM_SDF)安全工程保障控制子类分解图7评估威胁CPRM_ATT)安全工程保障控制子类分解.8 图8评估脆弱性CPRM_AVL)安全工程保障控制子类分解. 10 图9评估影响CPRM_AIM)安全工程
5、保障控制子类分解. 13 图10评估安全风险(PRM_ASR)安全工程保障控制子类分解.图11工程过程安全工程保障控制类介绍.18 图12确定安全要求CPEN_ISR)安全工程保障控制子类分解.18 图13高层安全设计CPEN_HSD)安全工程保障控制子类分解21图14详细安全设计CPEN_DSD)安全工程保障控制子类分解.22 图15安全工程实施CPEN_SEE)安全工程保障控制子类分解. 24 图16提供安全输入CPEN_PSD安全工程保障控制子类分解26图17监视安全态势CPEN_MSP)安全工程保障控制子类分解.m图18管理安全控制CPEN_MSC)安全工程保障控制子类分解图19协调安
6、全CPEN_COS)安全工程保障控制子类分解图20保障过程安全工程保障控制类说明.37 图21验证和确认安全CPAS_VVS)安全工程保障控制子类分解37图22建立保证证据CPAS_EAE)安全工程保障控制子类分解.39 图23信息系统安全工程能力要求级别图.44 表1安全工程生命周期和过程域对应表E GB/T 20274.4-2008 前言GBjT 20274(信息安全技术信息系统安全保障评估框架分为以下四个部分:一第1部分:简介和一般模型第2部分:技术保障-第3部分:管理保障第4部分:工程保障本部分是GBjT20274的第4部分。本部分由全国信息安全标准化技术委员会提出并归口。本部分起草单
7、位:中国信息安全产品测评认证中心。本部分主要起草人:吴世忠、王海生、陈晓桦、王贵驷、李守鹏、江常青、彭勇、张利、姚轶崭、班晓芳、李静、玉庆、邹琪、钱伟明、江典盛、陆丽、孙成吴、门雪松、杜宇鸽、杨再山。而且GB/T 20274.4一20081 范围信息安全技术信息系统安全保障评估框架第4部分:工程保障GB/T 20274的本部分建立了信息系统安全工程保障的框架，确立了组织机构启动、实施、维护、评估和改进信息安全工程的指南和通用原则。GB/T20274的本部分定义和说明了信息系统安全工程保障工作中反映组织机构信息安全工程保障能力的安全工程能力级，以及提供组织机构信息安全工程保障内容的安全工程保障控
8、制类要求。GB/T 20274的本部分适用于启动、实施、维护、评估和改进信息安全工程的组织机构和涉及信息系统安全工程工作的所有用户、开发人员和评估人员。2 规范性引用文件下列文件中的条款通过GB/T20274的本部分的引用而成为本部分的条款。凡是注日期的引用文件，其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。GB/T 20274. 1 信息安全技术信息系统安全保障评估框架第1部分:简介和一般模型3 术语和定义GB/T 20274.1确定的以及以下术语和定义适用于
9、GB/T20274的本部分。3. 1. 1 确认validation 解决方案满足用户的运行安全需求。3. 1.2 验证verification 解决方案满足安全要求。4 本部分的结构GB/T 20274的本部分的组织结构如下za) 第1章介绍了GB/T20274的本部分的范围;b) 第2章介绍了GB/T20274的本部分所规范引用的标准zc) 第3章描述了适用于GB/T20274的本部分的术语和定义zd) 第4章描述了GB/T20274的本部分的组织结构;e) 第5章描述了信息系统安全工程保障框架，并进一步概述了工程保障控制类和工程能力级;f) 第6章描述了信息安全工程保障控制类的规范描述结
10、构和要求Fg) 第7章到第9章详述了提供信息安全工程保障内容的3个信息安全工程类的详细要求;1 GB/T 20274.4-2008 h) 第10章详述了反应组织机构信息安全工程保障能力的安全工程能力级;i) 参考文献给出了GB/T20274的本部分的参考文献。5 信息系统安全工程保障框架5. 1 信息系统安全工程保障概述本标准第1部分中提出了信息安全保障模型(参见本标准第1部分图3)，在模型中，描述了信息系统安全中保障要素(技术、工程、管理和人员)、安全特征和生命周期三者的关系。信息安全工程保障框架是信息系统安全保障框架的一个重要组成部分，信息安全工程保障主要涉及同信息系统安全工程建设实施相关
11、的工程保障内容和要求，信息系统安全工程保障结合了信息安全工程保障建设的特殊内容和要求，建立了信息安全管理保障的能力成熟度模型。信息安全工程保障能力成熟度模型包含了两个相互依赖的维度，即安全工程保障控制维和安全工程保障能力成熟度级维，它反映了信息安全工程保障在控制措施和能力成熟度这两个方面的要求。a) 安全工程保障控制维由信息安全工程保障控制组成，它建立了组织机构信息安全工程保障框架的内容和工作范围。信息安全工程保障控制使用类一子类一组件的层次化结构，每个信息安全工程保障控制类反映了信息安全工程保障特定领域工作的范围和内容，是信息安全工程保障特定领域工作最佳实践的总结。在本部分中，共包含了3个信
12、息安全工程保障控制类，它们给出了信息安全工程保障中做什么这个关于内容和范围的答复;b) 安全工程保障能力成熟度级维由六级能力成熟度级别组成，它代表了组织机构实施信息安全工程保障控制的能力。安全工程保障能力成熟度级同特定的安全工程保障控制类相结合，给出了信息安全工程保障中做得如何好这个关于能力的答复，同时能力成熟度方法也为组织机构提供了可以持续改进的长效机制。通过设置这两个相互依赖的维，信息安全工程保障框架在各个能力级别上覆盖了整个安全工程活动范围。5.2 信息系统安全工程保障控制5.2. 1 信息系统安全工程保障控制类本部分中将信息系统安全工程划分为三个基本的过程域(即信息系统安全工程保障控制
13、类):风险、工程和保障。虽然这些域决不是互相独立的，但可以分开考虑它们。在最简单的级别中，风险过程识别并优先级排序对开发出的产品或系统的内在危险。安全工程过程与其他工程学科共同作用来决定和实施危险引起的问题的解决方案。最后，保障过程建立对安全解决方案的信心并将这种信心传递给用户。5.2.2 信息系统安全工程生命周期信息系统安全更强调在整个生命周期中融入安全并强调动态可持续改进的能力发展，在信息系统安全工程过程中，主要是基于信息系统安全工程的生命周期思想有效地提炼出信息系统安全工程的生命周期中的一些关键的过程域，通过对这些过程域的基本实施的要求，覆盖信息系统安全工程的整个生命周期，再通过每个过程
14、域中执行通用实践的能力实践、改进每个过程域的执行能力。这样才能真正有效、科学、可重复、可不断改进地、动态发展地实现信息系统安全保障的目标。安全工程过程生命周期包含以下根据信息流向划分的安全工程阶段:挖掘安全需求、定义安全要求、设计体系结构、详细安全设计、实现系统安全和有效性评估。有效性评估贯穿整个信息系统工程过程的所有阶段，以确保系统能够满足用户需求。图1反映工程过程中各活动之间的关系，箭头表明各活动之间的信息流向，而不是活动的顺序或时限。图1安全工程过程生命周期5.2.3 安全工程生命周期和过程璋对应关系安全工程生命周期同过程域关系如表1: GB/T 20274.4一2008表1安全工程生命
15、周期和过程璋对应表生命周期拮述相关安全工程保障控制子类本阶段建立项目组织，了解系统的上下文环境，决定系统定义CPRM_SDF)开始进行安全工程，制定初步计划和预算等。评估威胁CPRM_ATT)挖掘安全需求本阶段帮助用户挖掘并理解完成系统的任务和业务风险过程评估脆弱性CPRM_AVL)CPRM) 所需的信息保护需求。信息保护需求的确定建立在对评估影响CPRM一AIM)系统的安全风险分析的基础上。评估安全风险CPRM_ASR)本阶段将已识别出来的信息保护需求落实到各子系定义安全要求统中，包括开发系统安全上下文，初步的系统安全运行确定安全要求CPEN_ISR)设想和安全要求基线等。本阶段进行分析候选
16、体系结构、分配安全服务和选择提供安全输入CPEN_PSD设计体系结构安全机制，从而完成安全功能分析和落实。选择适用的工程过程组件或元件并把安全功能分配给这些元件，同时描述这CPEN) 高层安全设计CPENHSD) 些元件之间的关系。本阶段分析设计的约束条件，分析折衷办法，进行详详细安全设计细的系统和安全设计并考虑生命周期支持。检查所有详细安全设计CPENDSD) 系统安全需求落实到了组件。最终的详细安全设计结果为实现系统提供充分的组件和接口描述信息。L一3 G/T 20274.4-2008 表1(续)生命周期描述相关安全工程保障控制子类本阶段把系统设计转移到运行，参与对所有系统问题安全工程实施
17、CPEN_SEE)的多学科综合分析，并为认证认可活动提供输入。例如协调安全CPEN_COS)验证系统已经实现了对抗威胁评估中识别出的威胁;追踪与系统实现和测试活动相关的信息保护保障机制z为监视安全态势CPEN_MSP)I 实现系统安全系统生命周期支持计划、运行规程、培训材料维护提供工程过程输入。本阶段信息系统已到位并开始运行，通过定期的CPEN) 评估和不断监视系统的安全状况，确定如何获得更高的管理安全控制CPEN_MSC)安全性能和效率等来满足用户变化的安全需求，进行软硬件升级和修改并进行相应的测试。验证和确认安全CPAS一本阶段关注信息保护的有效性一一系统是否能够保有效性评估证其处理的信息
18、的保密性、完整性、可用性、鉴别和不可保障过程CPAS) 否认性，确保成功完成使命。建立保障论据CPAS_EAE)5.3 信息系统安全工程能力成熟度级别在工程过程组件中，给出了信息安全工程过程所带及的过程域，它是信息安全工程过程中提炼出来的实践的最佳反映。工程过程能力是遵循一个工程过程所能达到的可量化范围，通过对组织机构执行安全工程每个过程域能力反映了组织机构在执行信息安全工程达到预定的成本、功能和质量目标上的度量。在工程保障中，安全工程过程能力模型将列出并描述安全工程过程的各个能力级别，这样通过对安全工程过程域的执行范围和每个相应安全工程过程域的执行能力的综合，就可以更完善地对组织机构信息安全
19、工程过程进行科学、公正、可度量、分级的评估。6 信息安全工程保障控制类结构6. 1 概述本章定义了本部分所使用的信息安全工程保障控制类的结构。信息安全工程保障控制类以安全工程保障控制类、安全工程保障控制子类、安全工程保障控制组件来表达。6.2 安全工程保障控制类结构每个安全工程保障控制类包括一个安全工程保障控制类名、安全工程保障控制类介绍以及一个或多个安全工程保障控制子类。图2描述了本部分中所使用的安全工程保障控制类的结构。工程保障控制类工程保障控制类名工程保障控制类介绍A包括B和若干个C工程保障控制于类圄2安全工程保障控制类结构4 GB/T 20274.4一2008安全工程保障控制类结构的详
20、细描述如下za) 安全工程保障控制类名:安全工程保障控制类名提供了标识和划分安全工程保障控制类所必需的信息，每个安全工程保障控制类都有一个唯一的名称。安全工程保障控制类的分类信息由三个英文字符的简名组成，此简名将用于该安全工程保障控制类的子类的简名规范中;b) 安全工程保障控制类介绍:安全工程保障控制类介绍部分提供了该安全工程保障控制类定义、要求和目的等的整体描述。安全工程保障控制类介绍中用图来具体描述此域中的子类、组件组成结构;c) 安全工程保障控制子类:安全工程保障控制子类部分对该安全工程保障控制类所包含的子类进行了详细描述。一个安全工程保障控制类包含了一个或多个安全工程保障控制子类。6.
21、3 安全工程保障控制子类结构一个安全工程保障控制类包含了一个或多个安全工程保障控制子类。每个安全工程保障控制子类包含一个安全工程保障控制子类名、一个安全保障工程目的和一个或多个实现此安全工程保障目的的安全工程保障控制组件(控制措施)。图3描述了安全工程保障控制子类的描述结构。工程保障控制子类工程保障控制子类名安全保障工程目的A包括B和若干个c工程保障控制组件圄3安全工程保障控制子类结构安全工程保障控制子类结构的详细描述如下:a) 安全工程保障控制子类名:安全工程保障控制子类名部分提供了标识和划分安全工程保障控制子类所必需的分类和描述信息，每个安全工程保障控制子类有一个唯一的名称。安全工程保障控
22、制子类的分类信息由七个英文字符的简名组成，前三个英文字符与其所属的安全工程保障控制类名相同，第四个字符是下划线用于连接安全工程保障控制类名和安全工程保障控制子类名，最后三个英文字符是安全工程保障控制子类名，例如XXX_YYYo唯一的简名安全工程保障控制子类名为安全工程保障控制组件提供了引用名;b) 安全保障工程目的:安全工程保障目的描述了此安全工程保障控制子类所要达到的目的;c) 安全工程保障控制组件z一个安全工程保障控制子类包含了一个或多个安全工程保障控制组件。安全工程保障控制组件就是实现安全工程保障目的的信息安全保障工程控制措施。6.4 安全工程保障控制组件结构安全工程保障控制组件是实现安
23、全工程保障目的的信息安全保障工程控制措施。每个安全工程保障控制组件包括一个安全工程保障控制组件名、一个安全工程保障控制组件控制和一个可选的安全工程保障控制组件注解。图4描述了安全工程保障控制组件的描述结构。5 GB/T 20274.4-2008 工程保障控制组件A包括B和若干个C工程保障控制组件名工程保障控制组件控制工程保障控制组件注解(可选项)圄4安全工程保障控制组件结构安全工程保障控制组件结构的详细描述如下:a) 安全工程保障控制组件名:安全工程保障控制组件名用于标识安全工程保障控制组件。安全工程保障控制组件的简名是由安全工程保障控制组件名，后面使用句点作为连接符，在句点连接符后用阿拉伯数
24、字按顺序标明不同的组件构成的。b) 安全工程保障控制组件控制:安全工程保障控制组件控制部分定义了满足其安全工程保障控制子类安全工程保障目的特定的控制措施。c) 安全工程保障控制组件注解:可选的安全工程保障控制组件注解部分为该安全工程保障控制组件提供了进一步描述性的解释说明，以及实施诙控制措施的最佳实践的建议等。安全工程保障控制组件注解中所提供的最佳实践等内容可能不一定适合所有的情况，本部分的使用者也可以根据其自身信息安全工程保障的特殊需求和要求使用其他更合适的实施方法。7 PRM安全工程保障控制类:风险过程7. 1 凤险过程安全工程保障控制类介绍安全工程的一个主要目标是降低风险。风险评估是识别
25、尚未发生的问题的过程。风险的评估是通过检查威胁的可能性、脆弱性并考虑意外事件的潜在影响。可能性是不确定的因素，所以它会因特定的环境而不同。这意味着可能性只能在一定的限制下进行预测。另外，评估特定风险的影响也具有不确定性，因为意外事件可能不像所预料的那样出现。这些因素可能有很大的不确定性影响到预测的正确性，所以安全的规划和评定就会很难。这个问题的一个不完全解决方法是用技术手段来检测意外事件的发生。意外事件由三项构成:威胁、脆弱性和影响。脆弱性是资产可能被威胁利用的属性，也包括弱点。如果威胁或脆弱性其一不存在，就不会有意外事件，也就没有风险。风险管理是评估和量化风险并设定组织的风险可接受程度的过程
26、。管理风险是安全管理的重要部分。通过保护措施的实施降低风险，风险可以描述威胁、脆弱性、影响，或者风险本身。然而，降低所有风险或完全根除任一特定风险都是不可能的。这主要是因为风险降低的戚本，以及相关的不确定性。因此，总是必须接受一些残余风险。在不确定性很高的情况下，由于不能精确地描述风险，接受风险会有很大问题。信息安全工程的过程域包括确保服务提供方组织进行分析威胁、脆弱性、影响，并综合这些活动所得到的威胁、脆弱性和影响信息进行风险分析，然后得到风险信息。GB/T 20274.4-2008 风险过程说明见图50评估威胁(PRMATT) 评估脆弱性(PRMAVL) 评估影响(PRMAIM) 7.2
27、系统定义(PRM_SDF)7.2. 1 安全工程保障目的评估安全风险(PRMASR) 风险信息影响信息图5凤险过程说明系统定义安全工程保障控制子类的目的是识别信息系统的任务和使命，即系统的任务要求和它所要达到的能力，这些能力包括系统应执行的功能、所需的接口及这些接口相关的能力、所要处理的信息、所支持的运行结构以及运行的威胁等。图6描述了系统定义(PRM_SDF)安全工程保障控制子类组成结构。PRM:风险过程PRM SDF:系统定义1.详细系统描述图6系统定义(PRM_SDF)安全工程保障控制子类分解7.2.2 PRM_SDF.l 详细系统描述7.2.2.1 安全工程保障控制组件控制描述信息系统
28、的目的、任务和使命;信息系统的信息类划分、边界、信息流E信息系统的业务体系、技术体系和管理体系等。7.2.2.2 安全工程保障控制组件注解详细系统描述实际上就是确定STOE的过程，这是非常重要的一个步骤，是后续各个步骤的基础。因为只有明确定义和描述系统的范围等性质，对系统的分析才有意义，才能准确和有效。应按照GB/T20274第1部分附录C的图C.l信息系统安全保障评估信息系统描述规范中的要求，描述信息系统的使命，信息系统的环境、评估边界和接口、安全域;再分别从信息系统的管理体系、技术体系、业务体系等角度对信息系统进行详细描述。7.3 评估威胁(PRM_ATT)7.3. 1 安全工程保障目的评
29、估威胁安全工程保障控制子类的目标是对系统安全的威胁进行标识和特征化。评估威胁安全工程保障控制子类的目的在于标识安全威胁及其性质和特征。本安全工程保障控制子类产生的威胁信息将与评估脆弱性得到的脆弱性信息以及评估影响得到的GB/T 20274.4-2008 影响信息一起用于评估安全风险中。虽然收集威胁、脆弱性和影响信息的活动被分组为几个单独的过程域，但它们是互相依赖的。其目标是要得到足以用作判定的威胁、脆弱性和影响的组合。因此，确定威胁调查的范围应结合相应的脆弱性和影响。威胁容易变化，所以必须定期监视威胁，以确保一直维持理解本过程域产生的结果。图7描述了评估威胁CPRM_ATT)安全工程保障控制子
30、类组成结构。1.标识自然威胁2.标识人为威胁3.标识威胁的测量块PRM ATT:评估威胁4.评估威胁源能力5.评估威胁的可能性6.监视威胁及其特征圄7评估威胁(PRM_AIT)安全工程保障控制子类分解7.3.2 PRM_ATT.l 标识自然威胁7.3.2. 1 安全工程保障控制组件控制标识由自然原因引起的威胁。由自然原因引起的威胁，包括地震、海啸和台风。不过，并非有威胁的所有自然灾害都会在所有地方发生。例如，在大量内陆中心地带就不可能出现台风。因此，重要的是标识出在特定地方到底会发生哪一种具有威胁的自然灾害。7.3.2.2 安全工程保障控制组件注解评估所需的大量信息可以从实际清单和自然现象数据
31、库中获得。这些信息是具有价值的，它们也可能很通用而要谨慎使用这些信息可能需要根据特定环境来描述。标识自然威胁的工作产品示例如下za) 适用的自然威胁表一一一文档化自然威胁的特征和可能性的表格。7.3.3 PRM_AIT.2 标识人为威胁7.3.3. 1 安全工程保障控制组件控制标识出无意的或有意的人为原因所引起的威胁。人为原因引起的威胁基本上有两种z一是由意外原因引起的威胁;二是由有意行为引起的威胁。某些人为威胁在目标环境中并不适用，应在进一步分析后予以取消。标识人为威胁的工作产品示例如下za) 威胁情景描述一一描述威胁是如何工作的。b) 威胁严重性估计一一衡量威胁的可能性。8 GB/T 20
32、274 .4-2008 7.3.3.2 安全工程保障控制组件注解有时，描绘威胁将会如何发生的情景，有助于理解故意威胁。一般人为威胁数据库的使用，应考虑它们的完整性和关联性。7.3.4 PRM_ATT.3 标识威胁的测量块7.3.4.1 安全工程保障控制组件控制标识特定环境中合适的测量块和适用范围。大多数的自然威胁和许多人为威胁都有其与之相关的测量块。大多数情况r.整个的测量块并不适用于特定情况。因此，在特定情况下，有时需要最大化事件发生概率，有时需要最小化事件发生的概率，这样考虑才恰当。7.3.4.2 安全工程保障控制组件注解在对某一特定威胁没有可接受的度量标准单位时，应生成针对该位置的度量标
33、准单位。恰当的话，应该在测试表关系中对相关范围和度量标准单位进行描述。标识威胁的测量块的工作产品示例如r:a) 威胁表，包括测量块和所在位置范围。7.3.5 PRM_ATT.4 评估威胁源能力7.3.5.1 安全工程保障控制组件控制评估人为威胁的威胁掘的能力和动机。本安全工程保障控制组件集确定成功对系统进行攻击的潜在的人类敌对势力的才能和能力。才能指的是敌对者的攻击知识(例如，他们是否拥有知识、经过训练)。能力则衡量一个有才能的敌手能够进行攻击的可能性(例如，他们是否拥有资源)。7.3.5.2 安全工程保障控制组件注解人为的故意威胁在很大程度上取决于威胁源的能力以及供威胁支配的资源。因此，经验
34、欠缺的黑客如果获得了经验丰富、能力高的黑客的工具，将会造成更危险的威胁，但话说回来，还是不如经验丰富的黑客自己来使用更危险。但是，缺乏经验的黑客又可能造成非故意的伤害，经验丰富的黑客则不会。除威胁源的能力之外，对威胁源所拥有资源的评估，应该与威胁源的攻击动机一起考虑，因为攻击的动机大小往往与目标资产的吸引力有关。威胁可能按顺序或并发地多次进行攻击来达到其预期目标。应考虑顺序或并发的多次攻击的影响，威胁场景研究有助于此。评估威胁源能力的工作产品示例如r:d威胁源描述能力评估和描述。7.3.6 PRM_ATT.5 评估威胁的可能性评估威胁事件发生的可能性。7.3.6. 1 安全工程保障控制组件控制
35、评估威胁事件发生的可能性是怎样的。对自然事件发生的机会以及故意行为或个别意外事件的评估中，需要考虑多种因素。考虑的诸多因素并不一定要进行计算或衡量，只需要报告中有一致的度量标准。7.3.6.2 安全工程保障控制组件注解这是一件复杂的概率计算，因为许多因素的概率都是变化的。就评估的准确性和有效性而言，任何可能性的估计都是不确定的因素。应分别报告各个可能性评估的不确定性以避免混淆。无论如何，度量和可能性都将存在不确定性。通常，保持各个不确定因素分别描述则会更有效，这也是一种混合的表示法，分开处理以便进一步分析数据的时候，能够分辨出是对工作数据本身还是对数据的不确定性的处理。a) 威胁事件可能性评估
36、描述威胁的可能性的报告。9 GB/T 20274.4一20087.3.7 PRM_ATT.6 监视威胁及其特征监视威胁分布情况及威胁特征的不断变化。7.3.7.1 安全工程保障控制组件控制任何位置和状态下的威胁分布情况都是动态的。新的威胁可能变得相关，而现有威胁的特征也可能发生变化。因此有规律地监视现有威胁及其特征并检查新的威胁很重要。本安全工程保障控制组件与标识协调机制(PEN_ISR)中的监视威胁、脆弱性、影响和环境变化安全工程保障控制组件的一般监视活动紧密相连。7.3.7.2 安全工程保障控制组件注解由于威胁可能发生变化，因此在特定环境中可能多次进行评估。但是，重复进行威胁评估不能代替对
37、威胁的监视。a) 威胁监控报告-一描述威胁监控结果的文档。b) 威胁变化报告-_描述威胁分布情况变化的文档。7.4 评估脆弱性(PRM_AVL)7.4. 1 安全工程保障目的标识和特征化系统的安全脆弱性。评估安全脆弱性的目标是获得对一给定环境中系统安全脆弱性的理解。评估安全脆弱性的目的在于标识和特征化系统的安全脆弱性。本安全工程保障控制组件包括分析系统资产、定义具体的脆弱性，以及系统脆弱性的全面评估。与安全风险和脆弱性评估相关的术语因上下文环境而不同。在本标准中，脆弱性除了传统所说的弱点、安全漏洞或可能被威胁攻击的系统中的信息流外，还指系统可能被恶意利用的方面。这些脆弱性独立于任何特定的威胁或
38、攻击。可以在系统的生命周期中的任何时候执行这一系列脆弱性评估活动，来支持在已知环境中的对系统进行开发、维护或运行等决策。图8描述了评估脆弱性(PRM_AVU安全工程保障控制子类组成结构。1.选择脆弱性分析方法PRM:风险过程2.标识脆弱性PRM A叽z评估脆弱性3.收集脆弱性数据4.合成系统脆弱性5.监视脆弱性及其特征圄8评估脆弱性(PRM_AVL)安全工程保障控制子类分解7.4.2 PRM_AVL.l 选择脆弱性分析方法选择用于标识和特征化给定环境中安全系统脆弱性的方法、技术和标准。10 GB/T 20274.4一20087.4.2. 1 安全工程保障控制组件控制本组件包括定义系统建立安全脆
39、弱性的方法，这种方法允许标识和特征化安全脆弱性，包括根据威胁及其可能性、运行功能、安全要求或其他相关过程域对脆弱性进行分类和优先级排列。通过标识分析的深度和广度，安全工程师和顾客可以确定评估范围是否包括日标系统以及分析的全面性。应在预先安排和指定时间内，在一个已知的并记录有配置的框架内进行分析。分析的方法论应包括预期结果，应清楚地描述分析的具体目标。7.4.2.2 安全工程保障控制组件注解脆弱性分析方法可以是现有的、经裁剪的，也可以是专门针对系统运行和给定环境定制的。分析方法通常以PRM_ATT评估安全风险中的风险分析方法论为基础或相一致。要注意的是并不提供有关威胁、能力和价值的理解，这时的方
40、法论必须针对其范围或采用一系列可用假设条件。分析脆弱性的方法可以是定量的或定性的。通常的脆弱性分析反映可能性。攻击结果可以书面报告的形式表达，攻击本身可以论述证明。至少有两种不同的方法来标识脆弱性。这两种方法为基于分析的方法或基于测试的方法。基于测试的方法对于标识现存的脆弱性，且测试内容中含有已知威胁，是很好的方法。基于分析的方法，对于标识新的脆弱性则是最好的方法，那些脆弱性并不会立即被利用但会随另一安全问题的出现而被利用。选择脆弱性分析方法论时还可考虑的其他选择包括基于定量或定性的方法，还应该考虑对分析和测量的完整性的控制能力。工作产品示例:a) 脆弱性分析方法发现和描述系统安全脆弱性的方法
41、，包括分析、报告和跟踪过程。b) 脆弱性分析格式为保证方法规范化，描述脆弱性分析结果的格式。c) 攻击方法论和工作原理一一包括执行攻击测试的日标和方法。d) 攻击规程执行攻击测试的详细步骤。e) 攻击计划包括资源、时间安排和攻击方法论的描述。f) 穿透研究以标识未知脆弱性为目标的攻击场景的分析和实施。g) 攻击场景描述将要进行尝试的具体攻击。7.4.3 PRM_AVL.2 标识脆弱性标识系统安全脆弱性。7.4.3. 1 安全工程保障控制组件控制系统的安全和非安全的相关部分中都可能存在系统脆弱性。支持安全功能或与安全机制配合的非安全机制中经常有可利用的脆弱性。应遵循选择脆弱性分析方法(PRM_A
42、VL.1)中的攻击场景方法，以便能确认脆弱性。应记录发现的所有系统脆弱性。7.4.3.2 安全工程保障控制组件注解在本实践中，脆弱性被看成是系统的固有问题，而不考虑任何威胁的可能性。可以参照威胁分析的结果来对脆弱性进行优先级排列。攻击不可重现，使开发对策的难度较大。可根据PRM_ASR评估安全风险中优先级排列的功能、PEN_ISR确定安全要求中的业务优先级和目标来标识脆弱性。此外.PRM_AIM评估影响中的资产也必须计算在内。工作产品示例za) 描述系统面临的各种攻击的脆弱性清单。b) 包括攻击测试结果的穿透轮廓(例如脆弱性)。7.4.4 PRM_AVL. 3 收集脆弱性数据收集与脆弱性性质相
43、关的数据。11 GB/T 20274.4-2008 7.4.4. 1 安全工程保障控制组件控制脆弱性具有其自身的性质，本安全工程保障控制组件意在收集与这些性质相关的数据。脆弱性的测量块可以与PRM_ATT.3标识威胁的测量块中的威胁的测量块相同。应标识并收集脆弱性被利用的难易程度以及脆弱性出现的可能性的数据。7.4.4.2 安全工程保障控制组件注解通过本活动收集起来的脆弱性数据以后将被用在PRM_ASR评估安全风险。因此，以一种易于PRM_ASR使用的格式收集和存贮脆弱性数据显得非常重要。元论如何，度量和可能性都将存在不确定性。通常，保持各个不确定因素分别描述则会更有效，分开处理以便进一步分析
44、数据的时候，能够分辨出是对工作数据本身还是对数据的不确定性的处理。工作产品示例:a) 脆弱性性质表一记录系统或产品脆弱性特征的表。7.4.5 PRM_AVL.4 合成系统脆弱性评估系统脆弱性并将特定脆弱性及各种特定脆弱性的组合结果进行综合收集。7.4.5. 1 安全工程保障控制组件控制分析脆弱性或脆弱性的组合会让系统产生的问题。应分析脆弱性的附加特征，例如脆弱性被利用的可能性以及成功利用脆弱性的机会。分析结果也可包括处置合成的脆弱性的推荐方法。7.4.5.2 安全工程保障控制组件注解需要收集脆弱性分析和攻击的结果。应足够详细地标识和文件描述发现的所有脆弱性及其被利用的潜在可能性，以便客户做出有关对策
