信息安全技术信息系统安全保障评估框架第4部分：工程保障

信息安全技术信息系统安全保障评估框架第4部分：工程保障

国家标准 GB/T20274.4一2008 信息安全技术 信息系统安全保障评估框架 第4部分:工程保障 nformation.seeurityteehnology Evaluationframeworkforinformatonsystemssecurityassuranee Part4:Emngineeringasuramee 2008-07-18发布 2008-12-01实施 国家质量监督检验检疫总局 发布 国家标准化管蹬委员会国家标准

GB/T20274.4一2008 目 次 前言 范围 规范性引用文件 术语和定义 本部分的结构 信息系统安全工程保障框架 信息系统发全工程保障概达 5 信息系统安全工鞋保障控制 信息系统安全工程能力成熟度级别 信息安全工程保障控制类结构 概述 安全工程保障控制类结构 安全工程保障控制子类结构 安全工程保障控制组件结构 PRM安全工程保障控制类;风险过程 风险过程安全工程保障控制类介绍 系统定义(PRM_SDF) 评估威胁(PRM_ATT) 评估脆弱性(PRM_AVL) 评估影响(PFRM_AIM 评估安全风险(PRM_AsR PEN安全工程保障控制类:工程过程 8 工程过程安全工程保障控制类介绍 8 确定安全要求(PEN_ISR) 高层安全设计(PEN_HSD 8. 22 详细安全设计(PEN_DSD) 2: 安全工程实施(PEN_SEE 8 26 提供安全输人(PEN_PSI) 8. 2: 监视安全态势(PEN_MSP 32 管理安全控制(PEN_MSC) 8 35 协调安全(PEN_COS) 36 PAs安全工程保障控制类:保障过程 36 保障过程安全工程保障控制类介绍 37 验证和确认安全(PAs_VVS) 39 建立保证证据(PAs_EAE l0 安全工程保障控制类能力级 l0.1概述 10.2安全工程能力级别说明
GB/T20274.4一2008 10.3信息系统安全工程能力级别要求 44 45 参考文献 图1安全工程过程生命周期 图2安全工程保障控制类结构 图3安全工程保障控制子类结构 图4安全工程保障控制组件结构 图5风险过程说明 图 系统定义(PRMLsDF)安全工程保障控制子类分解 图" 评估威胁(PRM_ATT)安全工程保障控制子类分解 图8评估脆剥性(PRML_Av)安全工程保障控制子类分解 图9评估影响(PRML_AIMM)安全工程保障控制子类分解 13 图10评估安全风险(PRMLAsR)安全工程保障控制子类分解 15 因m 8 工程过程安全工程保障控制类介绍 图1z 8 确定安全要求(PEN_ISR)安全工程保障控制子类分解 图13高层安全设计(PEN_HSD)安全工程保障控制子类分解 21 图14 详细安全设计(PEN_DSD)安全工程保障控制子类分解 22 安全工程实施(PEN_sEE)安全工程保障控制子类分解 图15 24 图16提供安全输人(PEN_PsD)安全工程保障控制子类分解 26 监视安全态势(PEN_MSP)安全工程保障控制子类分解 图17 29 18管理安全控制(PEN_MSC)安全工程保障控制子类分解 图 32 图19协调安全(PEN_cOs)安全工程保降控制子类分解 35 3 图20保障过程安全工程保障控制类说明 图21验证和确认安全(PAs_VVS)安全工程保障控制子类分解 37 图22建立保证证据(PAs_EAE)安全工程保障控制子类分解 39 图23信息系统安全工程能力要求级别图 44 表1安全工程生命周期和过程域对应表
GB/T20274.4一2008 前 言 GB/T20274《信息安全技术信息系统安全保障评估框架》分为以下四个部分 第1部分:简介和一般模型 第2部分:技术保障 第3部分:管理保障 第4部分:工程保障 本部分是GB/T20274的第4部分 本部分由全国信息安全标准化技术委员会提出并归口 本部分起草单位;信息安全产品测评认证中心 本部分主要起草人;吴世忠,王海生、陈晓桦、,王贵猬、李守鹏、江常青、彭勇、张利、姚铁崭,班晓芳、 李静、王庆、邹琪,钱伟明、江典盛、陆丽、孙成昊、门雪松、杜宇鸽,杨再山 业

GB/T20274.4一2008 信息安全技术 信息系统安全保障评估框架 第4部分:工程保障 范围 GB/T20274的本部分建立了信息系统安全工程保障的框架,确立了组织机构启动、实施、维护、评 估和改进信息安全工程的指南和通用原则 GB/T20274的本部分定义和说明了信息系统安全工程保 障工作中反映组织机构信息安全工程保障能力的安全工程能力级,以及提供组织机构信息安全工程保 障内容的安全工程保障控制类要求 GB/T20274的本部分适用于启动、实施、维护、评估和改进信息安全工程的组织机构和涉及信息 系统安全工程工作的所有用户,开发人员和评估人员 规范性引用文件 下列文件中的条款通过GB/T20274的本部分的引用而成为本部分的条款 凡是注日期的引用文 件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本部分,然而,鼓励根据本部分达成 协议的各方研究是否可使用这些文件的最新版本 凡是不注日期的引用文件,其最新版本适用于本 部分 GB/T20274.1信息安全技术信息系统安全保障评估框架第1部分;简介和一般模型 术语和定义 GB/T20274.1确定的以及以下术语和定义适用于GB/T20274的本部分 3.1.1 alidation 确认 解决方案满足用户的运行安全需求 3.1.2 验证verifieatiom 解决方案满足安全要求 本部分的结构 GB/T20274的本部分的组织结构如下 a)第1章介绍了GB/T20274的本部分的范围; b 第2章介绍了GB/T20274的本部分所规范引用的标准; 第3章描述了适用于GB/T20274的本部分的术语和定义 D 第4章描述了GB/T20274的本部分的组织结构 第5章描述了信息系统安全工程保障框架,并进一步概述了工程保障控制类和工程能力级 第6章描述了信息安全工程保障控制类的规范描述结构和要求; g第7章到第9章详述了提供信息安全工程保障内容的3个信息安全工程类的详细要求
GB/T20274.4一2008 第10章详述了反应组织机构信息安全工程保障能力的安全工程能力级 h 参考文献给出了GB/T20274的本部分的参考文献 iD 信息系统安全工程保障框架 信息系统安全工程保障概述 本标准第1部分中提出了信息安全保障模型(参见本标准第1部分图3),在模型中,描述了信息系 统安全中保障要素(技术,工程、管理和人员,安全特征和生命周期三者的关系 信息安全工程保障框架是信息系统安全保障框架的一个重要组成部分,信息安全工程保障主要涉 及同信息系统安全工程建设实施相关的工程保障内容和要求,信息系统安全工程保障结合了信息安全 工程保障建设的特殊内容和要求,建立了信息安全管理保障的能力成熟度模型 信息安全工程保障能力成熟度模型包含了两个相互依赖的维度,即“安全工程保障控制维”和“安全 工程保障能力成熟度级维”,它反映了信息安全工程保障在控制措施和能力成熟度这两个方面的要求 “安全工程保障控制维”由信息安全工程保障控制组成,它建立了组织机构信息安全工程保障 a 框架的内容和工作范围 信息安全工程保障控制使用类一子类一组件的层次化结构,每个信 息安全工程保障控制类反映了信息安全工程保障特定领域工作的范围和内容,是信息安全 程保障特定领域工作最佳实践的总结 在本部分中,共包含了3个信息安全工程保障控制类 它们给出了信息安全工程保障中“做什么"这个关于内容和范围的答复 b “安全工程保障能力成熟度级维”由六级能力成熟度级别组成,它代表了组织机构实施信息安 全工程保障控制的能力 安全工程保障能力成熟度级同特定的安全工程保障控制类相结合， 给出了信息安全工程保障中“做得如何好”这个关于能力的答复,同时能力成熟度方法也为组 织机构提供了可以持续改进的长效机制 通过设置这两个相互依赖的维,信息安全工程保障框架在各个能力级别上覆盖了整个安全工程活 动范围 5.2信息系统安全工程保障控制 5.2.1信息系统安全工程保障控制类 本部分中将信息系统安全工程划分为三个基本的过程域(即信息系统安全工程保障控制类);风险 工程和保障 虽然这些域决不是互相独立的,但可以分开考虑它们 在最简单的级别中,风险过程识别 并优先级排序对开发出的产品或系统的内在危险 安全工程过程与其他工程学科共同作用来决定和实 施危险引起的问题的解决方案 最后,保障过程建立对安全解决方案的信心并将这种信心传递给用户 5.2.2信息系统安全工程生命周期 信息系统安全更强调在整个生命周期中融人安全并强调动态可持续改进的能力发展,在信息系统 安全工程过程中,主要是基于信息系统安全工程的生命周期思想有效地提炼出信息系统安全工程的生 命周期中的一些关键的过程域,通过对这些过程域的基本实施的要求,覆盖信息系统安全工程的整个生 命周期,再通过每个过程域中执行通用实践的能力实践、改进每个过程域的执行能力 这样才能真正有 效、科学,可重复、可不断改进地,动态发展地实现信息系统安全保障的目标 安全工程过程生命周期包含以下根据信息流向划分的安全工程阶段;挖掘安全需求,定义安全要 求,设计体系结构、详细安全设计,实现系统安全和有效性评估 有效性评估贯穿整个信息系统工程过 程的所有阶段,以确保系统能够满足用户需求 图1反映工程过程中各活动之间的关系,箭头表明各活 动之间的信息流向,而不是活动的顺序或时限
GB/T20274.4一2008 挖掘 安全求 有效性评估 定义 安全要求 设计 体系结构 详细 安全设计 用户/用户代表 实现 系统安全 图1安全工程过程生命周期 5.2.3安全工程生命周期和过程域对应关系 安全工程生命周期同过程域关系如表1. 表1安全工程生命周期和过程域对应表 生命周期 描 述 相关安全工程保障控制子类 系统定义PRM_SDF 本阶段建立项目组织了解系统的上下文环境,决定 评估威胁(PRM_ATT 开始进行安全工程,制定初步计划和预算等 风险过程 挖掘安全需求 本阶段帮助用户挖掘并理解完成系统的任务和业务 评估脆弱性(PRMLAvL PRM 所需的信息保护需求 信息保护需求的确定建立在对 评估影响(PRM_AIM) 系统的安全风险分析的基础上 评估安全风险(PRMLAsR 本阶段将已识别出来的信息保护需求落实到各子系 定义安全要求 确定安全要求(PEN_ISR 统中包括开发系统安全上下文初步的系统安全运行 设想和安全要求基线等 提供安全输人(PEN_PSI 本阶段进行分析候选体系结构、分配安全服务和选择 安全机制,从而完成安全功能分析和落实 选择适用的 设计体系结构 工程过程 组件或元件并把安全功能分配给这些元件,同时擂述这 高层安全设计(PEN_HSD PEN 些元件之间的关系 本阶段分析设计的约束条件,分析折衷办法,进行详 细的系统和安全设计并考虑生命周期支持 检查所有 详细安全设计 详细安全设计(PENLDsD) 系统安全需求落实到了组件 最终的详细安全设计结 果为实现系统提供充分的组件和接口描述信息
GB/T20274.4一2008 表1(续 述 生命周期 描 相关安全工程保障控制子类 安全工程实施(PEN_SEE 本阶段把系统设计转移到运行,参与对所有系统问题 协调安全(PEN_cos 的多学科综合分析,并为认证认可活动提供输人 例如 验证系统已经实现了对抗威胁评估中识别出的威胁;追 监视安全态势(PEN_MSPy s 踪与系统实现和测试活动相关的信息保护保障机制; 工程过程 系统生命周期支持计划、运行规程,培训材料维护提供 实现系统安全 PEN 输人 本阶段信息系统已到位并开始运行,通过定期的 评估和不断监视系统的安全状况,确定如何获得更高的 管理安全控制(PEN_MscC) 安全性能和效率等来满足用户变化的安全需求,进行软 硬件升级和修改并进行相应的测试 验证和确认安全PAs 本阶段关注信息保护的有效性系统是否能够保 保障过程 VVS 有效性评估 证其处理的信息的保密性,完整性、可用性、鉴别和不可 PAs) 否认性,确保成功完成使命 建立保障论据(PAS_EAE) 5 信息系统安全工程能力成熟度级别 在工程过程组件中,给出了信息安全工程过程所涉及的过程域,它是信息安全工程过程中提炼出来 的实践的最佳反映 工程过程能力是遵循一个工程过程所能达到的可量化范围,通过对组织机构执行 安全工程每个过程域能力反映了组织机构在执行信息安全工程达到预定的成本,功能和质量目标上的 度量 在工程保障中,安全工程过程能力模型将列出并描述安全工程过程的各个能力级别,这样通过对安 全工程过程域的执行范围和每个相应安全工程过程域的执行能力的综合,就可以更完善地对组织机构 信息安全工程过程进行科学、公正、可度量、分级的评估 信息安全工程保障控制类结构 6.1概述 本章定义了本部分所使用的信息安全工程保障控制类的结构 信息安全工程保障控制类以安全工 程保障控制类,安全工程保障控制子类,安全工程保障控制组件来表达 2 安全工程保障控制类结构 o 每个安全工程保障控制类包括一个安全工程保障控制类名、安全工程保障控制类介绍以及一个或 多个安全工程保障控制子类 图2描述了本部分中所使用的安全工程保障控制类的结构 工程保障控制类 工程保障控制类名 工程保障控制类介绍 图例 工程保障控制子类 A包括B和若干个c 图2安全工程保障控制类结构
GB/T20274.4一2008 安全工程保障控制类结构的详细描述如下 安全工程保障控制类名:安全工程保障控制类名提供了标识和划分安全工程保障控制类所必 a 需的信息,每个安全工程保障控制类都有一个唯一的名称 安全工程保障控制类的分类信息 由三个英文字符的简名组成,此简名将用于该安全工程保障控制类的子类的简名规范中; 安全工程保障控制类介绍;安全工程保障控制类介绍部分提供了该安全工程保障控制类定 b 义、要求和目的等的整体描述 安全工程保障控制类介绍中用图来具体描述此域中的子类、组 件组成结构; 安全工程保障控制子类:安全工程保障控制子类部分对该安全工程保障控制类所包含的子类 进行了详细描述 一个安全工程保障控制类包含了一个或多个安全工程保障控制子类 6.3安全工程保障控制子类结构 个安全工程保障控制类包含了一个或多个安全工程保障控制子类 每个安全工程保障控制子类 包含一个安全工程保障控制子类名、一个安全保障工程目的和一个或多个实现此安全工程保障目的的 安全工程保障控制组件(控制措施) 图3描述了安全工程保障控制子类的描述结构 工程保障控制子类 工程保障控制子类名 安全保障工程目的 图例 工程保障控制组件 A包括B和若干个c 图3安全工程保障控制子类结构 安全工程保障控制子类结构的详细描述如下 安全工程保障控制子类名;安全工程保障控制子类名部分提供了标识和划分安全工程保障控 制子类所必需的分类和描述信息,每个安全工程保障控制子类有一个唯一的名称 安全工程 保障控制子类的分类信息由七个英文字符的简名组成,前三个英文字符与其所属的安全工程 保障控制类名相同,第四个字符是下划线用于连接安全工程保障控制类名和安全工程保障控 制子类名,最后三个英文字符是安全工程保障控制子类名,例如XXX_YYY 唯一的简名安 全工程保障控制子类名为安全工程保障控制组件提供了引用名 安全保障工程目的安全工程保障目的描述了此安全工程保障控制子类所要达到的目的 b 安全工程保障控制组件:一个安全工程保障控制子类包含了一个或多个安全工程保障控制组 件 安全工程保障控制组件就是实现安全工程保障目的的信息安全保障工程控制措施 6. 4 安全工程保障控制组件结构 安全工程保障控制组件是实现安全工程保障目的的信息安全保障工程控制措施 每个安全工程保 障控制组件包括一个安全工程保障控制组件名、一个安全工程保障控制组件控制和一个可选的安全工 程保障控制组件注解 图4描述了安全工程保障控制组件的描述结构
GB/T20274.4一2008 工程保障控制组件 工程保障控制组件名 工程保障控制组件控制 图例 工程保障控制组件注解 可选项 A包括B和若干个C 图4安全工程保障控制组件结构 安全工程保障控制组件结构的详细描述如下 安全工程保障控制组件名:安全工程保障控制组件名用于标识安全工程保障控制组件 安全 a 工程保障控制组件的简名是由安全工程保障控制组件名,后面使用句点作为连接符,在句点连 接符后用阿拉伯数字按顺序标明不同的组件构成的 安全工程保障控制组件控制;安全工程保障控制组件控制部分定义了满足其安全工程保障控 制子类安全工程保障目的特定的控制措施 安全工程保障控制组件注解;可选的安全工程保障控制组件注解部分为该安全工程保障控制 组件提供了进一步描述性的解释说明,以及实施该控制措施的最佳实践的建议等 安全工程 保障控制组件注解中所提供的最佳实践等内容可能不一定适合所有的情况,本部分的使用者 也可以根据其自身信息安全工程保障的特殊需求和要求使用其他更合适的实施方法 PRM安全工程保障控制类:风险过程 风险过程安全工程保障控制类介绍 安全工程的一个主要目标是降低风险 风险评估是识别尚未发生的问题的过程 风险的评估是通 过检查威胁的可能性、脆弱性并考虑意外事件的潜在影响 可能性是不确定的因素,所以它会因特定的 环境而不同 这意味着可能性只能在一定的限制下进行预测 另外,评估特定风险的影响也具有不确 定性,因为意外事件可能不像所预料的那样出现 这些因素可能有很大的不确定性影响到预测的正确 性,所以安全的规划和评定就会很难 这个问题的一个不完全解决方法是用技术手段来检测意外事件 的发生 意外事件由三项构成;威胁、脆弱性和影响 脆弱性是资产可能被威胁利用的属性,也包括弱点 如果威胁或脆弱性其一不存在就不会有意外事件,也就没有风险 风险管理是评估和量化风险并设定 组织的风险可接受程度的过程 管理风险是安全管理的重要部分 通过保护措施的实施降低风险,风险可以描述威胁、脆弱性、影响,或者风险本身 然而,降低所有 风险或完全根除任一特定风险都是不可能的 这主要是因为风险降低的成本,以及相关的不确定性 因此,总是必须接受一些残余风险 在不确定性很高的情况下,由于不能精确地描述风险,接受风险会 有很大问题 信息安全工程的过程域包括确保服务提供方组织进行分析威胁、脆弱性、影响,并综合这 些活动所得到的威胁、脆弱性和影响信息进行风险分析,然后得到风险信息
GB/T20274.4一2008 风险过程说明见图5 评估威胁PRMATT 成胁信息 评估安全风险(PRM_ASR 评估脆弱性PRMAVI 风险信息 脆弱性信息 评估影响(PMAM 影响信息 图5风险过程说明 7.2系统定义(PRM_SDF) 7.2.1安全工程保障目的 系统定义安全工程保障控制子类的目的是识别信息系统的任务和使命,即系统的任务要求和它所 要达到的能力,这些能力包括系统应执行的功能、所需的接口及这些接口相关的能力、所要处理的信息、 所支持的运行结构以及运行的威胁等 图6描述了系统定义(PRMSDF)安全工程保障控制子类组成结构 PRM:风险过程 PRMsDF，系统定义 详细系统描述 系统定义(PRM_SDrF)安全工程保障控制子类分解 7.2.2PRM_sDr.1 详细系统描述 7.2.2.1安全工程保障控制组件控制 描述信息系统的目的、任务和使命;信息系统的信息类划分、边界、信息流;信息系统的业务体系、技 术体系和管理体系等 7.2.2.2安全工程保障控制组件注解 详细系统描述实际上就是确定ToE的过程,这是非常重要的一个步骤,是后续各个步骤的基础 因为只有明确定义和描述系统的范围等性质,对系统的分析才有意义,才能准确和有效 应按照GB/T20274第1部分附录C的图C.1信息系统安全保障评估信息系统描述规范中的要 求,描述信息系统的使命,信息系统的环境、评估边界和接口、安全域;再分别从信息系统的管理体系、技 术体系、业务体系等角度对信息系统进行详细描述 评估威胁(PRM_ATT 7.3.1安全工程保障目的 评估威胁安全工程保障控制子类的目标是对系统安全的威胁进行标识和特征化 评估威胁安全工程保障控制子类的目的在于标识安全威胁及其性质和特征 本安全工程保障控制子类产生的威胁信息将与评估脆弱性得到的脆弱性信息以及评估影响得到的
GB/T20274.4一2008 影响信息一起用于评估安全风险中 虽然收集威胁、脆弱性和影响信息的活动被分组为几个单独的过 程域,但它们是互相依赖的 其目标是要得到足以用作判定的威胁脆弱性和影响的组合 因此,确定 威胁调查的范围应结合相应的脆弱性和影响 威胁容易变化,所以必须定期监视威胁,以确保一直维持理解本过程域产生的结果 图7描述了评估威胁(PRM_ATT)安全工程保障控制子类组成结构 标识自然威胁 标识人为威胁 PRM:风险过程 标识威胁的测量块 PRMATT:评估威胁 评估威胁源能力 详估威胁的可能性 监视威胁及其特征 图7评估威胁(PRNM_ATT)安全工程保障控制子类分解 7.3.2PRM_ATT.1标识自然威胁 7.3.2.1安全工程保障控制组件控制 标识由自然原因引起的威胁 由自然原因引起的威胁,包括地震、海啸和台风 不过,并非有威胁的所有自然灾害都会在所有地 方发生 例如,在大量内陆中心地带就不可能出现台风 因此,重要的是标识出在特定地方到底会发生 哪一种具有威胁的自然灾害 7.3.2.2安全工程保障控制组件注解 评估所需的大量信息可以从实际清单和自然现象数据库中获得 这些信息是具有价值的,它们也 可能很通用而要谨慎使用这些信息 -可能需要根据特定环境来描述 标识自然威胁的工作产品示例如下 适用的自然威胁表 a 文档化自然威胁的特征和可能性的表格 7.3.3PRM_AIT.2标识人为威胁 7.3.3.1安全工程保障控制组件控制 标识出无意的或有意的人为原因所引起的威胁 人为原因引起的威胁基本上有两种;一是由意外原因引起的威胁;二是由有意行为引起的威胁 某 些人为威胁在目标环境中并不适用,应在进一步分析后予以取消 标识人为威胁的工作产品示例如下 描述威胁是如何工作的 a 威胁情景描述 b)威胁严重性估计 衡量威胁的可能性
GB/T20274.4一2008 7.3.3.2安全工程保障控制组件注解 有时,描绘威胁将会如何发生的情景,有助于理解故意威胁 一般人为威胁数据库的使用,应考虑 它们的完整性和关联性 7.3.4PRM_ATr.3标识威胁的测量块 7.3.4.1安全工程保障控制组件控制 标识特定环境中合适的测量块和适用范围 大多数的自然威胁和许多人为威胁都有其与之相关的测量块 大多数情况下,整个的测量块并不 适用于特定情况 因此,在特定情况下,有时需要最大化事件发生概率,有时需要最小化事件发生的概 率,这样考虑才恰当 7.3.4.2安全工程保障控制组件注解 在对某一特定威胁没有可接受的度量标准单位时,应生成针对该位置的度量标准单位 恰当的话、 应该在测试表关系中对相关范围和度量标准单位进行描述 标识威胁的测量块的工作产品示例如下 a)威胁表,包括测量块和所在位置范围 7.3.5PRM_AII.4评估威胁源能力 7.3.5.1安全工程保障控制组件控制 评估人为威胁的威胁源的能力和动机 本安全工程保障控制组件集确定成功对系统进行攻击的潜在的人类敌对势力的才能和能力 才能 指的是敌对者的攻击知识(例如,他们是否拥有知识,经过训练) 能力则衡量一个有才能的敌手能够进 行攻击的可能性(例如,他们是否拥有资源) 7.3.5.2安全工程保障控制组件注解 人为的故意威胁在很大程度上取决于威胁源的能力以及供威胁支配的资源 因此，经验欠缺的黑 客如果获得了经验丰富、能力高的黑客的工具,将会造成更危险的威胁,但话说回来,还是不如经验丰富 的黑客自己来使用更危险 但是,缺乏经验的黑客又可能造成非故意的伤害,经验丰富的黑客则不会 除威胁源的能力之外,对威胁源所拥有资源的评估,应该与威胁源的攻击动机一起考虑,因为攻击的动 机大小往往与目标资产的吸引力有关 威胁可能按顺序或并发地多次进行攻击来达到其预期目标 应考虑顺序或并发的多次攻击的影 响,威胁场景研究有助于此 评估威胁源能力的工作产品示例如下 a)威胁源描述 能力评估和描述 7.3.6PR_AIT.5评估威胁的可能性 评估威胁事件发生的可能性 7.3.6.1安全工程保障控制组件控制 评估威胁事件发生的可能性是怎样的 对自然事件发生的机会以及故意行为或个别意外事件的评 估中,需要考虑多种因素 考虑的诸多因素并不一定要进行计算或衡量,只需要报告中有一致的度量 标准 7 .3.6.2安全工程保障控制组件注解 这是一件复杂的概率计算,因为许多因素的概率都是变化的 就评估的准确性和有效性而言,任何 可能性的估计都是不确定的因素 应分别报告各个可能性评估的不确定性以避免混淆 无论如何,度 量和可能性都将存在不确定性 通常,保持各个不确定因素分别描述则会更有效,这也是一种混合的表 示法,分开处理以便进一步分析数据的时候,能够分辨出是对工作数据本身还是对数据的不确定性的 处理 威胁事件可能性评估 描述威胁的可能性的报告 a
GB/T20274.4一2008 7.3.7PRM_ATr.6监视威胁及其特征 监视威胁分布情况及威胁特征的不断变化 7.3.7.1安全工程保障控制组件控制 任何位置和状态下的威胁分布情况都是动态的 新的威胁可能变得相关,而现有威胁的特征也可 能发生变化 因此有规律地监视现有威胁及其特征并检查新的威胁很重要 本安全工程保障控制组件 与标识协调机制(PEN_ISR)中的“监视威胁、脆弱性、影响和环境变化"安全工程保障控制组件的一般 监视活动紧密相连 7.3.7.2安全工程保障控制组件注解 由于威胁可能发生变化,因此在特定环境中可能多次进行评估 但是重复进行威胁评估不能代替 对威胁的监视 描述威胁监控结果的文档 a)威胁监控报告 威胁变化报告 描述威胁分布情况变化的文档 b 7.4评估脆弱性(PRM_AVL 安全工程保障目的 标识和特征化系统的安全脆弱性 评估安全脆弱性的目标是获得对一给定环境中系统安全脆弱性的理解 评估安全脆弱性的目的在于标识和特征化系统的安全脆弱性 本安全工程保障控制组件包括分析 系统资产、定义具体的脆弱性,以及系统脆弱性的全面评估 与安全风险和脆弱性评估相关的术语因上 下文环境而不同 在本标准中,“脆弱性”除了传统所说的弱点、安全漏洞或可能被威胁攻击的系统中的 信息流外,还指系统可能被恶意利用的方面 这些脆弱性独立于任何特定的威胁或攻击 可以在系统 的生命周期中的任何时候执行这一系列脆弱性评估活动,来支持在已知环境中的对系统进行开发,维护 或运行等决策 图8描述了评估脆弱性(PRM_AVIL)安全工程保障控制子类组成结构 选择脆弱性分析方法 PRM风险过程 标识脆弱性 收集脆弱性数据 PRMA，评估脆弱性 合成系统脆弱性 监视脆弱性及其特征 图8评估脆弱性(PR_AVL)安全工程保障控制子类分解 7.4.2PRM_AVIL.1选择脆弱性分析方法 选择用于标识和特征化给定环境中安全系统脆弱性的方法、技术和标准 10
GB/T20274.4一2008 7.4.2.1安全工程保障控制组件控制 本组件包括定义系统建立安全脆弱性的方法,这种方法允许标识和特征化安全脆弱性,包括根据威 胁及其可能性、运行功能、安全要求或其他相关过程域对脆弱性进行分类和优先级排列 通过标识分析 的深度和广度,安全工程师和顾客可以确定评估范围是否包括目标系统以及分析的全面性 应在预先 安排和指定时间内,在一个已知的并记录有配置的框架内进行分析 分析的方法论应包括预期结果,应 清楚地描述分析的具体目标 7.4.2.2安全工程保障控制组件注解 脆弱性分析方法可以是现有的、经裁剪的,也可以是专门针对系统运行和给定环境定制的 分析方 法通常以PRM_ATT“评估安全风险”中的风险分析方法论为基础或相一致 要注意的是并不提供有 关威胁、能力和价值的理解,这时的方法论必须针对其范围或采用一系列可用假设条件 分析脆弱性的方法可以是定量的或定性的 通常的脆弱性分析反映可能性 攻击结果可以书面报 告的形式表达,攻击本身可以论述证明 至少有两种不同的方法来标识脆弱性 这两种方法为基于分析的方法或基于测试的方法 基于测 试的方法对于标识现存的脆弱性,且测试内容中含有已知威胁,是很好的方法 基于分析的方法,对于 标识新的脆弱性则是最好的方法,那些脆弱性并不会立即被利用但会随另一安全问题的出现而被利用 选择脆弱性分析方法论时还可考虑的其他选择包括基于定量或定性的方法,还应该考虑对分析和测量 的完整性的控制能力 工作产品示例 a) 脆弱性分析方法 发现和描述系统安全脆弱性的方法,包括分析、报告和跟踪过程 脆弱性分析格式 D) -为保证方法规范化,描述脆弱性分析结果的格式 e)攻击方法论和工作原理 包括执行攻击测试的目标和方法 执行攻击测试的详细步骤" d)攻击规程 包括资源、时间安排和攻击方法论的描述 攻击计划 f 穿透研究 -以标识未知脆弱性为目标的攻击场景的分析和实施 攻击场景 描述将要进行尝试的具体攻击 g 7.4.3PRNM_AVL.2标识脆弱性 标识系统安全脆弱性 7.4.3.1安全工程保障控制组件控制 系统的安全朋非安全的相关部分中都可能存在系统胞弱性 支持安全功能或与安全机制配合的非 安全机制中经常有可利用的脆弱性 应遵循选择脆弱性分析方法(PRM_AVL.l)中的攻击场景方法， 以便能确认脆弱性 应记录发现的所有系统脆弱性 7.4.3.2安全工程保障控制组件注解 在本实践中,脆弱性被看成是系统的固有问题,而不考虑任何威胁的可能性 可以参照威胁分析的 结果来对脆弱性进行优先级排列 攻击不可重现,使开发对策的难度较大 可根据PRM_ASR“评估安全风险”中优先级排列的功能、PEN_ISR“确定安全要求”中的业务优先 级和目标来标识脆弱性 此外,PRM_AIM“评估影响”中的资产也必须计算在内 工作产品示例 a)描述系统面临的各种攻击的脆弱性清单 包括攻击测试结果的穿透轮廓例如脆弱性) b 7.4.4PRM_AVL.3收集脆弱性数据 收集与脆弱性性质相关的数据 1l
GB/T20274.4一2008 7.4.4.1安全工程保障控制组件控制 脆弱性具有其自身的性质,本安全工程保障控制组件意在收集与这些性质相关的数据 脆弱性的 测量块可以与PRMATT.3“标识威胁的测量块”中的威胁的测量块相同 应标识并收集脆弱性被利 用的难易程度以及脆弱性出现的可能性的数据 7. 4.4.2安全工程保障控制组件注解 通过本活动收集起来的脆弱性数据以后将被用在PRM_AsR“评估安全风险” 因此,以一种易于 PRMLAsR使用的格式收集和存贮脆豺性数据显得非常重要 无论如何,度量和可能性都将存在不确 定性 通常,保持各个不确定因素分别描述则会更有效,分开处理以便进一步分析数据的时候,能够分 辨出是对工作数据本身还是对数据的不确定性的处理 工作产品示例 脆弱性性质表 记录系统或产品脆弱性特征的表 a 7.4.5PRM_AL.4合成系统脆弱性 评估系统脆弱性并将特定脆弱性及各种特定脆弱性的组合结果进行综合收集 7.4.5.1安全工程保障控制组件控制 分析脆弱性或脆弱性的组合会让系统产生的问题 应分析脆弱性的附加特征,例如脆弱性被利用 的可能性以及成功利用脆弱性的机会 分析结果也可包括处置合成的脆弱性的推荐方法 7.4.5.2安全工程保障控制组件注解 需要收集脆弱性分析和攻击的结果 应足够详细地标识和文件描述发现的所有脆弱性及其被利用 的潜在可能性,以便客户做出有关对策的决定 工作产品示例 a)脆弱性评估报告 包括定性或定量描述让系统产生问题的脆弱性,同时包括攻击的可能性、 成功的可能性及攻击产生的影响 攻击报告 记录攻击的结果及结果的分析的报告,其中包括已发现的脆弱性、被利用的潜 b 在可能性和推荐的处置方法等 7.4.6PRM_AVL.5监视脆弱性及其特征 监视脆弱性的不断变化及其特征的变化 7.4.6.1安全工程保障控制组件控制 任何位置和状态下的脆弱性分布情况都是动态的 新的脆弱性会变得有相互关系,现有脆弱性的 特征可能变化 因此,监视现有脆弱性及其特征并定期检查新的脆弱性很重要 本安全工程保障控制 组件与PEN_MSP2监视威胁,脆弱性、影响、风险和环境变化的一般监视活动紧密相连 7.4.6.2安全工程保障控制组件注解 由于脆弱性可能发生变化,在给定环境中可能多次进行评估活动 但是,重复的脆弱性评估不能代 替对脆弱性的监视 工作产品示例: a)脆弱性监视报告 描述脆弱性监视结果的文档 脆弱性变化报告 D) 描述新的或变化了的脆弱性的文档 7.5评估影响(PRM_AIMI) 7.5.1安全工程保障目的 评估影响的目的在于标识对系统的影响,并评估影响发生的可能性 影响可能是有形的,例如收人 的损失或经济惩罚;也可能是无形的,例如声誉和信誉的损失 本安全工程保障控制子类的目标是标识和特征化风险对系统的安全影响 图9描述了评估影响(PRM_AIMI)安全工程保障控制子类组成结构 12
GB/T20274.4一2008 对影响进行优先级排列 标识系统资产 2. PRM:风险过程 选择影响的度量 3 PRMAIM:评估影响 标识度量关系 标识和特征化影响 监视影响 图9评估影响(PRM_AIM)安全工程保障控制子类分解 7.5.2RM_AIM.1对影响进行优先级排列 标识,分析并优先级排列系统的运行,业务或任务能力 7.5.2.1安全工程保障控制组件控制 标识、分析并优先级排列系统的运行,业务或任务,也应考虑对业务战略的影响 这将可能改变和 缓解组织可能遭受的影响,进而会改变其他控制子类或组件得出的风险优先级排列次序 因此当计算 本组件与PEN_ISR“确定安全要求”的活动相关 潜在影响时把这些影响包括在内很重要 7.5.2.2安全工程保障控制组件注解 功能性和信息资产可理解为它们在给定环境中具有的价值和关键性 价值可以是运行的重要性、 密级、敏感度,或预期的运行及系统的使用反映出的资产的其他价值意义 关键性可理解为对系统运 行、人类生活、运行成本以及其他关键因素的影响,在运行环境中功能受到损害、修改或不可用 资产也 可根据合适的安全要求进行定义 例如,资产可定义为客户清单的保密性、办公室间通信的可用性或薪 资信息的完整性 许多资产是无形的或隐性的 所选风险评估方法应说明怎样评价能力和资产的值， 并进行优先级排列 工作产品示例: a)系统优先级清单和影响的修改者 D) 系统能力轮廓描述系统能力及其对系统目标的重要性 7.5.3PRM_AIM.2标识系统资产 标识和特征化支持系统的关键运行能力或安全目标的系统资产 7.5.3.1安全工程保障控制组件控制 标识支持系统的安全目标或关键能力(运行,业务或任务功能)所必需的系统资源和数据 通过评 估给定环境中每项资产提供支持的重要性,来定义每项资产 7.5.3.2安全工程保障控制组件注解 广义的资产包括系统中的人、环境、技术和基础设施,还包括数据和资源;不仅包括信息,面且也包 括各个子系统(例如,通信、数据恢复、应用,以及打印资源) 资产的重要性可理解为其在给定环境中的 支持能力的价值和关键性 资产不必一定是安全性机制;它们可以包括支持与安全性机制相关的安全 13
GB/T20274.4一2008 功能或工作的非安全机制 有时,本组件是对PEN_PSI“提供安全输人”和PAs_VVS“验证和确认安 全”中工作的复查 工作产品示例 a) 产品资产分析 -包括标识产品资产及对系统运行的重要性 b) 系统资产分析 包括标识系统资产及对系统运行的重要性 7.5.4PRM_AIM.3选择影响的度量 选择用于评估影响的度量 7.5.4.1安全工程保障控制组件控制 有许多度量标准可用来衡量事件的影响 最好预先确定哪种度量标准适用于当前的特定系统 7.5.4.2安全工程保障控制组件注解 数量有限但一致的度量标准比不一致的度量标准更易于处理 影响的定量或定性评估方法可从以 下几个方面考虑,例如 计算经济成本; a) b 根据经验划分严重程度等级例如从1到10. 或者使用形容词,例如低、中高 c 工作产品示例 a)选择影响的度量 7.5.5PRNM_AIM.4标识度量关系 标识所选评估影响的度量标准之间的关系以及所需度量标准转换因子 7.5.5.1安全工程保障控制组件控制 评估影响可能需要使用不同的度量标准 必须找出不同度量标准之间的关系,以保证在整个影响 评估中对所有暴露所使用方法的一致性 有时,有必要把各种度量标准方法组合起来,以便能够产生出 统一的结果 因此需要建立产生统一结果的方法 这通常因系统不同而不同 当使用定性的度量标准 时,在综合阶段也需要有定性因子合并的指南 7.5.5.2安全工程保障控制组件注解 例如,若某暴露是颐石推毁一栋房屋,那么潜在的影响便是要花费$100,000重建这栋房屋 另一 种影响可能是因6个月后才能重建好房屋而导致无处安身的损失 可以将这两种影响合并起来,如果 每月租房需要$250,此暴露总影响便是$101,500. 工作产品示例 a)影响度量标准关系表 描述度量标准之间的关系 影响度量标准合并规则 描述合并影响度量标准的规则 D) 7.5.6PRM_AIM.5标识和特征化影响 利用多重度量标准或统一度量标准标识和特征化意外事件的意外影响 7.5.6.1安全工程保障控制组件控制 从PRM_AIM.1(对影响进行优先级排列)和PRM_AIM.2(标识系统资产)中标识出的资产和能力 出发标识出产生损害的后果 对于每种资产,后果可能为损坏、泄密、不通或消失 对能力的影响可能 包括中断、延迟或削弱 创建了相对完整的度量关系表之后,可以使用在PRMAIM.3(选择影响的度量)和PRM_AIM.4 标识度量关系)中标识出的度量来特征化影响 这一步需要研究精算表、年鉴或其他资源,还应考虑每 种影响的度量的不确定性 7.5.6.2安全工程保障控制组件注解 评估影响以PRM_AIM.3(选择影响的度量)中确定的影响度量标准为依据,影响的组合以PRM AIM.4(标识度量关系)中建立的规则为依据 在大多数情况下,度量标准以及特定环境下具体影响发 14
GB/T20274.4一2008 生的可能性都存在一定的不确定性 通常,保持各个不确定因素分别描述则会更有效,分开处理以便进 -步分析数据的时候,能够分辨出是对工作数据本身还是对数据的不确定性的处理 工作产品示例: a)暴露影响列表 -潜在影响及相应度量的列表 7.5.7RM_AIM.6监视影响 监视影响的不断变化 7.5.7.1安全工程保障控制组件控制 任何位置和状态下,影响都是动态的 新的影响可能产生相互关系 因此,监视现有影响并定期检 查新的影响很重要 本安全工程保障控制组件与PEN_MSP.2监视威胁、脆弱性、影响、风险和环境变 化的一般监视活动紧密相连 7.5.7.2安全工程保障控制组件注解 由于影响会发生变化,因此在给定环境中可能反复、多次进行影响评估 但是,重复的影响评估不 能代替对影响的监视 工作产品示例 描述监视影响的结果 a)影响监视报告 b 影响变化报告 描述影响的变化情况 7.6评估安全风险(PRM_ASR) 7.6.1安全工程保障目的 评估安全风险的目标是获得对给定环境中的系统运行相关的安全风险的理解,并按照既定方法论 对风险进行优先级排列 评估安全风险的目的是标识给定环境中系统的安全风险 本安全保障控制子类着重要基于对能力 情况以及资产相对威胁的脆弱情况的理解来确定这些风险 本活动特别包括标识和评估暴露发生的可 “暴露"是指会造成重大损害的威静、脆弱性和影响的维合 可以在系统的生命周期中的任何时 能性 候执行这一系列风险评估活动,来支持在已知环境中的对系统进行开发、维护或运行等决策 图10描述了评估安全风险(PRM_AsR)安全工程保障控制子类组成结构 选择风险分析方法 标识暴露 2. PRM风险过程 评估暴露的风险 PRM_ASR:评估安全风险 评估总体不确定性 风险优先级排列 5. 监视风险及其特征 图10评估安全风险(PRM_ASR)安全工程保障控制子类分解 15
GB/T20274.4一2008 7.6.2PRM_ASR.1选择风险分析方法 选择在给定环境中分析、评估,比较和优先级排列系统的安全风险的方法、技术和标准 7.6.2.1安全工程保障控制组件控制 本组件定义用于标识给定环境中系统安全风险的方法,可以用这种方法分析、评估和比较安全风 险 应该依据威胁、运行功能、系统脆弱性、潜在损失、安全需求等相关问题,得到对风险进行分类和分 级的方案 7.6.2.2安全工程保障控制组件注解 这种方法可以是现有的,经裁剪的,或针对系统运行和给定环境的特定方法 风险评估的方法论应 与威胁、脆弱性和影响的评估方法论互相衔接 工作产品示例 a)风险评估方法 描述对标识和特征化风险的方法 b) 风险评估格式 描述归档和跟踪风险的格式,包括风险的描述,重要性和相关性 7.6.3PRM_ASR.2标识暴露 标识威胁/脆弱性/影响三元组(暴露). 7.6.3.1安全工程保障控制组件控制 标识暴露的目的在于找出威胁和脆弱性的组合中的相关项,进而标识出现威胁和脆弱性造成的影 响 在选择系统保护措施时必须考虑这些暴露 7.6.3.2安全工程保障控制组件注解 本组件取决于威胁、脆弱性和影响各个安全工程控制子类的输出 工作产品示例 a)系统暴露清单 描述该系统的暴露 7.6.4PRM_ASR.3评估暴露的风险 评估每项暴露的风险 7.6.4.1安全工程保障控制组件控制 标识暴露出现的可能性 7.6.4.2安全工程保障控制组件注解 暴露的可能性是威胁的可能性与脆弱性的可能性所产生的暴露的可能性的综合 大多数情况下 也必须将特定的、一定数量的或绝大多数影响的可能性计算在内 无论如何,度量标准都存在不确定 保持各个不确定因素分别描述则会更有效,分开处理以便进一步分析数据的时候,能够分辨出是对 性 工作数据本身还是对数据的不确定性的处理 这会影响到应对风险所采取的战略 本组件使用了从 PRM_ATT.5(评估威胁的可能性),PRM_AVL.3(收集脆弱性数据)和PRM_AIM.5(标识和特征化影 响)中通过多种度量或一种统一度量方法收集的可能性数据 工作产品示例 计算出的风险列表 暴露风险清单 a 暴露优先级表 计算出的风险的优先级列表 b) 7.6.5PRM_ASR.4评估总体不确定性 评估暴露的风险的总体不确定性 7.6.5.1安全工程保障控制组件控制 每项风险本身都具有不确定性 总体的风险不确定性是PRM_ATT.5(评估威胁的可能性、PRM _AVL.3(收集脆弱性数据),PRM_AIM.5(标识和特征化影响)中所标识的威胁、脆弱性、影响及其特征 的不确定性的总和 本组件与“PAs_EAE建立保证论据”中的作为保障可以改变和降低不确定性的活 动紧密相关 7.6.5.2安全工程保障控制组件注解 如果不确定性没有与暴露发生的可能性分开考虑,那么安全措施的实施将达不到效果,或者降低了 16
GB/T20274.4一2008 实际上没必要去降低的风险 工作产品示例 具有不确定性的暴露的风险 a 表明对风险的衡量具有不确定性的风险列表 7.6.6PRM_AS.5风险优先级排列 按优先级排列风险 7.6.6.1安全工程保障控制组件控制 应根据组织优先级、发生的可能性、所具有的不确定性和可用资金来对已标识的风险进行排序， 可 以降低、,避免、转移或接受风险 也可以组合使用这些风险处理方式 降低,可以针对威胁、脆弱性、影 响或风险本身 应根据PEN_MsC“确定安全要求”中标识的风险承担者的需求、业务优先级和整体系 统架构来选择处理方式 7.6.6.2安全工程保障控制组件注解 这一步骤极为复杂并常常需要多次重复 安全措施可能要对付多种风险或多种威胁、脆弱性和影 响 这方面的工作可能对改变需要对付的风险的顺序具有影响 因此,本安全工程保障控制组件与 PEN_ISR“确定安全要求”和PEN_PSI“提供安全输人”密切相关 工作产品示例 a)风险优先级清单 个按优先级排列的风险清单 b 安全措施需求清单 能够帮助减轻风险的潜在的安全措施的清单 优先顺序的关系 个优先级框架的描述文档 c 7.6.7PRM_ASR.6监视风险及其特征 监视风险分布情况的不断变化及其特征的变化 7.6.7.1安全工程保障控制组件控制 任何情形下风险的分布情况都是动态的 新的风险可能变得相互关联,同时现存风险的特征可能 变化 因此,监视现存风险及其特征、定期检查新的风险很重要 本组件与PEN_MSP.2“监视威胁、,脆 弱性、影响、风险和环境的变化”中的一般监视活动密切相关 7.6.7.2安全工程保障控制组件注解 因为风险会变化,可以在给定环境下多次进行风险评估活动 但是,反复的风险评估不能代替监视 风险 监视风险及其特征工作产品示例如下 a)风险监视报告 描述当前风险分布情况的报告 b 风险变化报告 描述系统的运行能力及其对系统目标的重要性 PEN安全工程保障控制类:工程过程 8 工程过程安全工程保障控制类介绍 安全工程和其他工程学科一样,是一个贯穿概念,设计,实施、测试,验收,运行,维护和废弃的过程 在整个过程中,安全工程师必须与系统工程组的其他部分密切工作 信息安全工程保障强调安全工程 师是大团队的一部分,而且需与其他学科的工程师协作他们的活动 这有助于确保安全是较大过程的 重要组成部分,而不是分离、独立的活动 使用从上述风险过程得到的信息,以及其他关于系统需求的信息、相关法律和策略,安全工程师与 客户一起识别安全需求 识别了需求后,安全工程师识别并跟踪具体的要求 制定安全问题的解决方案的过程一般包括识别可选方案,评价可选方案以决定哪个最好 将此活 动与其余工程过程相结合的难度在于,选择解决方案不能仅考虑安全 而是有很多其他必须要考虑的 因素,包括成本、性能、技术风险和使用简便 特别应该注意这些决策以免再返回 产生的分析结果也 是保障工作的重要基础 在生命周期的后期,安全工程师要确保产品和系统根据先前的风险被恰当地配置,以确保新的风险 17
GB/T20274.4一2008 不会使系统运行在不安全状态 工程过程安全工程保障控制类介绍见图l1 风险信息 确定安全要求 监视安全态势 PENISR PENMSP 需求、策略等 配置信息 协调安全 提供安全输入 管理安全控制 (PENCOs PENPSI PENMSC 实施、验收 安全需求、 安 文件等 全要求 解决方案、指导等 高层安全设讯 详细安全设计 安全工程实施 PENSEE PENHSD (PENDSD 高层设计文件 详细设计文件 图11工程过程安全工程保障控制类介绍 8.2确定安全要求(PEN_ISR) 8.2.1安全工程保障目的 确定安全要求的目的是要明确地标识系统的安全需求 确定安全要求涉及定义系统的安全基础 以满足所有法律、策略和组织的安全要求 这些需求根据预期的系统运行安全环境上下文,组织当前安 全性和系统环境、标识出的一系列安全目标进行裁剪 定义一系列系统安全要求作为批准系统安全的 基线 确定安全要求的目标是包括客户在内的各方对安全需求达成共同理解 图1描述了确定安全要求(PEN_sR)安全工程保障控制子类组成结构 获得对顾客安全需求的理解 标识可用的法律、策略和约束 PEN;工程过程 标识系统安全关联性 收集系统运行的安全思想 PENISR:确定安全要求 收集安全的高层目标 定义安全相关需求 达成安全协议 图12确定安全要求(PEN_ISR)安全工程保障控制子类分解 18
GB/T20274.4一2008 8.2.2PEN_ISR.1获得对客户安全需求的理解 8.2.2.1安全工程保障控制组件控制 应获得对客户安全需求的理解 本安全工程保障控制组件的目的是要收集全面理解客户的安全需求所需的所有信息 这些需求受 到安全风险对客户的重要性的影响 系统将要运行的预期环境也影响客户的安全需求 8.2.2.2安全工程保障控制组件注解 术语“客户”可以指产品、系统或服务的具体接受者,或者也可以指市场调查或产品目标的一般接受 者 可能需要标识和区分不同的用户群 例如,普通用户可能有与管理员不同的需求 工作产品示例 a)客户的安全需求的陈述 客户对安全要求的高层描述 8.2.3PEN_ISR.2标识可用的法律、策略和约束 8.2.3.1安全工程保障控制组件控制 应标识出管理系统的法律,策略、标准、外部影响和约束 本安全工程保障控制组件的目的是要收集所有影响到系统安全的所有外部影响 适用性的决定应 标识支配系统预期环境的法律,规章,策略和商业标准 应决定全局和本地策略之间优先权 必须标识 由系统客户设置于系统的安全要求,并提炼隐含的安全要求 8.2.3.2安全工程保障控制组件注解 当系统将穿越多个物理区域时需要仔细考虑 不同国家和不同类型的业务应用的法律和规章之间 可能发生冲突 作为标识过程的一部分,冲突应最小化,应标识并尽可能解决冲突 工作产品示例 a) 安全约束 -法律、策略、规章,以及其他影响系统安全的约束 b) 安全环境(威胁、组织策略),安全目标(例如,要对抗的威胁);安全功能和保除 安全轮廓 要求;按照满足目标的要求而进行系统开发的基本原理 8.2.4PEN_ISR.3标识系统安全关联性 8.2.4.1安全工程保障控制组件控制 标识系统的用途以便确定安全上下文环境 本安全工程保障控制组件的目的是要标识系统上下文如何影响安全 这涉及理解系统的用途(例 如,情报的、金融的、医药的) 为安全考虑描述所处理的任务和运行场景 本阶段需要对系统面临的或 可能遭受的威胁的高层理解 为可能对安全的影响而描述性能和功能要求 为隐含的安全要求而检查 运行约束条件 环境可能也包括与其他组织或系统的接口,以便定义系统的安全边界 确定接口的要素包括安全 边界的内部和外部 许多组织外部的因素也不同程度影响组织的安全需求 这些因素包括政治倾向以及政治焦点的变 化技术开发、经济影响、全球事件和信息战 由于这些因素都不是静态的,需要监视和定期评估变化带 来的潜在影响 8.2.4.2安全工程保障控制组件注解 系统的安全边界并不一定等同于系统边界 例如,安全边界可能包含系统所处的设备和运行系统 的人,而系统边界可能止于人机接口 扩展安全边界,就可以将物理方法作为除纯技术方法之外有效的 访问控制的安全措施 工作产品示例 a)预期的威胁环境 对需要保护的系统资产的所有已知或预测的威胁;包括威胁源(专业知 识,可用资源,动机),攻击(方法、所利用的脆弱性、时机),资产 b 评估对象 描述将要评估其安全特性的系统或产品类型、预期的应用、一般特性、使用 局限 19
GB/T20274.4一2008 8.2.5PEN_ISR.4收集系统运行的安全思想 8.2.5.1安全工程保障控制组件控制 收集系统运行的高层安全思想 本安全工程保障控制组件的目的是要开发整个企业的高层安全思想,包括角色、职责、信息流、资 产,资源、人员保护和物理保护 此描述应包括讨论如何在系统要求的约束下管理企业 特别在运行安 全概念中提供系统的这一思想,应包括系统架构、规程和环境的高层安全思想 系统开发环境的要求也 在本阶段获得 8.2.5.2安全工程保障控制组件注解 无 工作产品示例 a)运行安全概念 系统的高层安全思想(角色、职责、资产、信息流、规程) b 概念性的安全架构 概念性角度的安全架构,参见PEN_PsI.3中的安全架构 8.2.6PEN_ISR.5收集安全的高层目标 8.2.6.1安全工程保障控制组件控制 收集定义系统安全性的高层目标 本基本实践的目的是要标识应满足怎样的安全目标,以便为系统在其运行环境中提供足够的安全 性 在PAS_EAE“建立保证证据”中确定的系统的保障目标,可能影响安全目标 8.2.6.2安全工程保障控制组件注解 目标应尽可能与任何具体实现无关 如果由于必须面对的现存环境而出现特定的约束,应在PEN _PsI“提供安全输人”中得出成熟的工程可选方案的安全约束和考虑时确定 安全目标应作为系统和 信息的可用性、可追究性、真实性、保密性、完整性和可靠性要求的最小化描述 工作产品示例 如何在组织内外管理、保护和分发资产的规则、指示和实践 D运行的/环境的安全策略 系统安全策略 系统或产品如何管理、保护和分发资产的规则、指示和实践 b) 8.2.7PEN_ISR.6定义安全相关需求 8.2.7.1安全工程保障控制组件控制 定义一致的一系列定义了系统所执行的保护的说明 本安全工程保障控制组件的目的是要定义系统的安全要求 本实践应确保每项要求都与适用的策 略、法律、标准、安全要求和系统的约束相一致 这些要求应完整定义系统的安全需求,包括非技术性的 要求 通常需要定义或指定对象的逻辑或物理边界,以确保涵盖了所有方面 要求应与系统的目标影 射或关联 应清晰简明地规定安全要求且不应互相矛盾 只要可能,安全应最小化对系统功能和性能 的影响 安全要求应为评估系统在其预期环境中的安全性的提供基础 8.2.7.2安全工程保障控制组件注解 许多要求适用于多个学科,所以极少数要求专注安全 因此,本安全工程控制类要求与其他学科进 行大量协调以确切得出系统安全是怎样的 这些交互性的活动在PEN_COs“协调安全”中描述 工作产品示例: a)安全要求 直接影响系统安全运行或贯彻指定安全策略的要求 b 可追溯性矩阵 安全需求、到要求、到解决方案(例如,架构、涉及、实施)和到测试及测试结 果的影射 8.2.8PEN_ISsR.7达成安全协议 8.2.8.1安全工程保障控制组件控制 达成对具体安全要求符合客户需求的协议 本安全工程保障控制组件的目的是要在所有各方之间达成安全要求的共识 标识出一般客户群而 20
GB/T20274.4一2008 非特定客户时,要求应满足一系列目标 指定的安全要求应是管理策略、法律和用户需求的完整、一致 的反映 应标识出问题并再处理直到达成共识 8.2.8.2安全工程保障控制组件注解 确保所有相关方真正理解了所同意的安全要求并且有相同的理解,这很重要 需要非常小心地确 保过程中安全要求对所有相关方来说是一回事 工作产品示例 认可的安全目标--对抗标识出的威胁和/或与标识出的安全策略由客户认可)相一致的固 a 定意向 b)安全要求基线 所有各方(特别是客户)在特定里程弹处同意的一系列最小安全要求 8.3高层安全设计(PEN_IHSD 8.3.1安全工程保障目的 信息系统的高层安全设计包括系统的体系结构、设计和实现的需求,制定相应的设计原则和建议、 安全体系结构建议、保护的原则,得到安全模型,安全体系结构,进行可靠性分析;确定所有的安全机制 都能对应到高层安全设计,并且所有的高层安全设计都有具体的安全机制来保证 图13描述了高层安全设计(PEN_HSD)安全工程保障控制子类组成结构 PEN:工程过程 设计安全模型 PENIHISD:高层安全设计 设计安全体系结构 图13高层安全设计(PEN_HISsD)安全工程保障控制子类分解 8.3.2PEN_IHISsD.1设计安全模型 8.3.2.1安全工程保障控制组件控制 为当前特定的信息系统设计安全模型,描述系统的安全原理 8.3.2.2安全工程保障控制组件注解 分析信息系统业务及安全要求,分解安全功能要求,选择系统结构,系统组件.内部外部接口,信息 流方向、环境等,设计安全模型 通常要求来自信息模型,功能模型和行为模型 信息模型说明将要处理的信息的类型以及如何处 理 功能模型说明应用系统将要提供的任务和功能 行为模型说明状态转变时和转变后应用所处的状 态 系统设计描述用户的要求和系统内部的行为,然后将两者进行影射,说明系统内部行为如何满足用 户的要求 工作产品示例 a)安全设计文档 包括系统中的资产和信息流的详细资料,以及描述将会贯彻安全的或与安 全相关的系统功能 b)安全模型 系统贯彻安全策略的正式表述;必须标识控制系统如何管理、保护和分发信息 的一系列规则和实践;有时这些规则可以用精确的数学术语表示 8.3. 3 PEN_IHISD.2设计安全体系结构 8.3.3.1安全工程保障控制组件控制 为当前特定的信息系统设计安全体系结构 21
GB/T20274.4一2008 8.3.3.2安全工程保障控制组件注解 将信息系统进行安全功能分解、选择能够实现特定功能的组件形式,描述每个子系统所提供的安全 功能 安全体系结构着重于系统体系结构的安全方面,描述与系统安全有关的规则基本概念,功能和 服务 体系结构设计定义了主要结构和组件之间的相互关系 本安全工程保障控制子类涉及与安全相关的需要进行分解,分析和重组,直到标识出有效的可选体 系结构 工作产品示例 a)安全架构" -关注于系统架构的安全方面,描述与系统的安全相关的原则基本概念、功能和 服务 捕述安全服务和机制如何相互关联和互相依 依赖性分析(安全措施的关系和依存关系) b 赖来为整个系统产生有效的安全性;标识哪些方面还需要安全措施 详细安全设计(PEN_DsD) 安全工程保障目的 本安全工程保障控制类信息系统安全工程师分析设计的约束条件,分析折衷办法,进行详细的系统 和安全设计并考虑生命周期支持 信息系统安全工程师检查所有系统安全需求落实到了组件 最终的 详细安全设计结果为实现系统提供充分的组件和接口描述信息 图14描述了详细安全设计(PEN_DSD)安全工程保障控制子类组成结构 分围安全机制 PEN;工程过程 确定安全产品 2. PENDsD:详细安全设计 系统接口设计和优化 提供安全工程指南 图14详细安全设计(PEN_DSD)安全工程保障控制子类分解 8.4.2PEN_DSD.1分配安全机制 8.4.2.1安全工程保障控制组件控制 将高层设计中的思想具体落实为具体的安全机制 8.4.2.2安全工程保障控制组件注解 确定所有的安全机制都能对应到高层安全设计,并且所有的高层安全设计都有具体的安全机制来 保证 将安全机制细分到子系统、组件和元素 工作产品示例 a)安全设计标准 有关整个系统或产品设计做决策所需的安全约束和考虑 安全实施规则 D) -应用于系统或产品实施的安全约束和考虑(例如,具体机制的使用,编码的 标准). -标识支持安全要求所需的具体文档例如,管理员手册、用户手册、具体设计 文档要求 文档). 22
GB/T20274.4一2008 8.4.3PEN_DSD.2确定安全产品 8.4.3.1安全工程保障控制组件控制 根据高层设计和分配的安全机制等要求,从可选的安全产品中选择最适合的产品 8.4.3.2安全工程保障控制组件注解 根据系统的需求,按照一定的依据给出候选产品列表 根据系统的需求,确定需要定制的安全产品 列表和他们的技术指标和功能要求 工作产品示例: 安全产品选型要求 说明能够满足系统安全要求的产品或组件所应具有的最低安全功能和 a 安全保障要求 8.4.4PEN_DSD.3系统接口设计和优化 8.4.4.1安全工程保障控制组件控制 对系统设计中的接口进行设计和优化. 8.4.4.2安全工程保障控制组件注解 设计安全系统与其他系统之间,各个安全类之间的接口,并进行优化 工作产品示例 系统优化指南 描述系统优化的理由和具体方法 a 系统配置指导 b) 确保系统运行满足安全目标的系统配置指导 8.4.5PEN_DSD.4提供安全工程指南 8.4.5.1安全工程保障控制组件控制 为参与工程的各方提供安全工程指南 8.4.5.2安全工程保障控制组件注解 为工程实施者提供体系结构建议、设计建议、安全体系结构建议、保护原则和设计原则描述文档,为 系统工程实施提供指南 本安全工程保障控制组件的目的是要开发安全指南并提供给工程组 工程组 使用安全工程指南来做出选择架构、设计和实施的决定 所需指南的数量及其详细程度取决于知识、经验和其他工程学科对安全的熟悉程度 通常大多数 指南可能与开发环境相关更甚于开发中的系统 工作产品示例 a)架构建议 包括支持开发满足安全要求的系统架构的原则或约束 b 设计建议 包括指导系统设计的原则或约束 实施建议 包括指导系统实施的原则或约束 c d)安全架构建议 包括定义系统安全特征的原则或约束 保护原理 如何贯彻安全的高层描述,包括自动的、物理的、人员的和管理的机制 e 设计标准、原理和原则-如何设计系统的约束(例如,最小权限、安全隔离控制措施) g)编码的标准 如何实现系统的约束 8.5安全工程实施(PEN_SEE) 8.5.1安全工程保障目的 本安全工程保障控制类信息系统安全工程师把系统设计转移到运行,参与对所有系统问题的多学 科综合分析,并为认证认可活动提供输人 例如验证系统已经实现了对抗威胁评估中识别出的威胁;追 踪与系统实现和测试活动相关的信息保护保障机制;为系统生命周期支持计划、运行规程、培训材料维 护提供输人 图15描述了安全工程实施(PEN_SEE)安全工程保障控制子类组成结构 23
GB/T20274.4一2008 工程实施 系统的试运行 PEN;工程过程 系统的测试 PENSEE，安全工程实施 工程的交付 5. 安全培训 提供用户指南 图15安全工程实施(PEN_SEE)安全工程保障控制子类分解 8.5.2PEN_SEE.1工程的实施 8.5.2.1安全工程保障控制组件控制 按照项目计划和具体实施方案进行安全工程的实施 8.5.2.2安全工程保障控制组件注解 制定实施建议(包括指导系统实现的规则或约束),根据实施建议和系统的详细安全设计文档制定 工程实施计划,并按照预定的经用户和有关方同意后的计划进行工程实施,给出实施情况描述文档 工作产品示例 应用于系统或产品实施的安全约束和考虑(例如,具体机制的使用,编码的 安全实施规则" a 标准). b 项目计划 -项目管理所需的计划,包括质量保证计划、进度计划、成本控制计划、人力资源 管理计划项目风险管理计划等 8.5.3PEN_SEE.2系统的试运行 8.5.3.1安全工程保障控制组件控制 对完成的安全系统进行试运行 8.5.3.2安全工程保障控制组件注解 应对系统进行试运行,检查系统的稳定性和可靠性,并对试运行过程中出现的问题进行整改,给出 工程整改报告和试运行情况报告 工作产品示例 a)试运行记录和报告 系统在试运行期间的运行状态记录,如有必要,对发生的重大事件进行 报告 8.5.4PEN_SEE.3系统的测试 8.5.4.1安全工程保障控制组件控制 制定测试计划,对所完成的系统进行安全测试， 8.5.4.2安全工程保障控制组件注解 工程实施方实施的系统应经过相应的评估,以获得客户的认可,并由测试方给出测试报告 要计划 214