风险评估管理程序

《风险评估管理程序》由会员分享，可在线阅读，更多相关《风险评估管理程序（36页珍藏版）》请在金锄头文库上搜索。

1、 风险评估管理程序 历史修订记录 序号 更改单号 更改说明 修订人 生效日期 现行版次 目 录 1 概述 . 5 2 术语与定义 . 5 2.1 风险管理 . 5 2.1.1 风险评估 . 5 2.2 其他 . 6 3 风险评估框架及流程. 7 3.1 风险要素关系 . 7 3.2 风险分析原理 . 9 3.3 实施流程 . 9 4 风险评估准备过程 . 10 4.1 确定范围 . 10 4.2 确定目标 . 11 4.3 确定组织结构 . 11 4.4 确定风险评估方法 . 11 4.5 获得最高管理者批准 . 11 5 风险评估实施过程 . 11 5.1 资产赋值 . 13 5.1.1 资

2、产分类 . 14 5.1.2 资产价值属性 . 17 5.1.3 资产价值属性赋值标准 . 19 5.2 威胁评估 . 23 5.2.1 威胁分类 . 23 5.2.2 威胁赋值 . 26 5.3 脆弱性评估 . 27 5.4 确定现有控制 . 30 5.5 风险评估 . 30 5.5.1 风险值计算 . 30 5.5.2 风险等级划分 . 31 5.5.3 风险评估结果纪录. 31 6 风险管理过程 . 32 6.1 安全控制的识别与选择 . 33 6.2 降低风险 . 34 6.3 接受风险 . 35 6.4 风险管理要求 . 35 7 相关文件 . 36 1 概述 目前信息安全管理的发展

3、趋势是将风险管理与信息安全管理紧密结合在一起，将风险概念作为信息安全管理实践的对象和出发点，信息安全管理的控制点以风险出现的可能性作为对象而展开的。ISO27001标准对信息安全管理体系(ISMS)的要求即通过对信息资产的风险管理,确定重要信息资产清单以及风险等级,从而采取相应的控制措施来实现信息资产的安全。 信息安全管理是风险管理的过程，风险评估是风险管理的基础。风险管理是指导和控制组织风险的过程。风险管理遵循管理的一般循环模式计划 (Plan)、执行 (Do)、检查 (Check)、行动 (Action)的持续改进模式。ISO27001 标准要求企业设计、实施、维护信息安全管理体系都要依据

4、PDCA 循环模式。 2 术语与定义 2.1 风险管理 风险管理是以可接受成本识别、评估、控制、降低可能影响信息系统风险的过程，通过风险评估识别风险，通过制定信息安全方针，采取适当的控制目标与控制方式对风险进行控制，使风险被避免、转移或降低到一个可以被接受的水平，同时考虑控制费用与风险之间的平衡。 风险管理的核心是信息的保护。信息对于组织是一种具有重要价值的资产。建立信息安全管理体系(ISMS)的目的是在最大范围内保护信息资产，确保信息的机密性、完整性和可用性，将风险管理自始至终的贯穿于整个信息安全管理体系中，这种体系并不能完全消除信息安全的风险，只是尽量减少风险，尽量将攻击造成的损失降低到最

5、低限度。 2.1.1 风险评估 风险评估指风险分析和风险评价的整个过程，其中风险分析是指系统化地识别风险来源和风险类型，风险评价是指按组织制定的风险标准估算风险水平，确定风险严重性。 风险评估的出发点是对与风险有关的各因素的确认和分析，与信息安全风险有关的因素可以包括四大类：资产、威胁、脆弱性、安全控制措施。 风险评估是对信息和信息处理设施的威胁、脆弱性和风险的评估，它包含以下元素： 风险是被特定威胁利用的资产的一种或一组脆弱性，导致资产丢失或损害的潜在可能性，即特定威胁事件发生的可能性与后果的结合。 资产是对组织具有价值的信息资源，是安全控制措施保护的对象。 威胁是可能对资产或组织造成损害的

6、事故的潜在原因。 脆弱性是资产或资产组中能被威胁利用的弱点。 安全控制措施是降低风险的措施、程序或机制。 2.2 其他 1. 资产Asset：对组织具有价值的信息或资源，是安全策略保护的对象。 2. 资产价值Asset Value：资产的重要程度或敏感程度的表征。资产价值是资产的属性，也是进行资产识别的主要内容。 3. 机密性confidentiality：数据所具有的特性，即表示数据所达到的未提供或未泄露给未授权的个人、过程或其他实体的程度。 4. 完整性integrity：保证信息及信息系统不会被非授权更改或破坏的特性。包括数据完整性和系统完整性。 5. 可用性availability：

7、数据或资源的特性，被授权实体按要求能访问和使用数据或资源。 6. 数据完整性data integrity ：数据所具有的特性，即无论数据形式作何变化，数据的准确性和一致性均保持不变。 7. 系统完整性system integrity ：在防止非授权用户修改或使用资源和防止授权用户不正确地修改或使用资源的情况下，信息系统能履行其操作目的的品质。 8. 信息安全风险information security risk ：人为或自然的威胁利用信息系统及其管理体系中存在的脆弱性导致安全事件的发生及其对组织造成的影响。 9. 信息安全风险评估information security risk assess

8、ment：依据有关信息安全技术与管理标准，对信息系统及由其处理、传输和存储的信息的机密性、完整性和可用性等安全属性进行评价的过程。它要评估资产面临的威胁以及威胁利用脆弱性导致安全事件的可能性，并结合安全事件所涉及的资产价值来判断安全事件一旦发生对组织造成的影响。 10.信息系统information system ：由计算机及其相关的和配套的设备、设施 (含网络)构成的，按照一定的应用目标和规则对信息进行采集、加工、存储、传输、检索等处理的人机系统。典型的信息系统由三部分组成：硬件系统（计算机硬件系统和网络硬件系统）；系统软件（计算机系统软件和网络系统软件）；应用软件（包括由其处理、存储的信息

9、）。 11.检查评估inspection assessment：由被评估组织的上级主管机关或业务主管机关发起的，依据国家有关法规与标准，对信息系统及其管理进行的具有强制性的检查活动。 12.组织organization：由作用不同的个体为实施共同的业务目标而建立的结构。组织的特性在于为完成目标而分工、合作；一个单位是一个组织，某个业务部门也可以是一个组织。 13.残余风险residual risk：采取了安全措施后，仍然可能存在的风险。 14.自评估self-assessment：由组织自身发起，参照国家有关法规与标准，对信息系统及其管理进行的风险评估活动。 15.安全事件security e

10、vent ：指系统、服务或网络的一种可识别状态的发生，它可能是对信息安全策略的违反或防护措施的失效，或未预知的不安全状况。 16.安全措施security measure：保护资产、抵御威胁、减少脆弱性、降低安全事件的影响，以及打击信息犯罪而实施的各种实践、规程和机制的总称。 17.安全需求security requirement：为保证组织业务战略的正常运作而在安全措施方面提出的要求。 18.威胁threat：可能导致对系统或组织危害的不希望事故潜在原因。 19. 脆弱性vulnerability：可能被威胁所利用的资产或若干资产的弱点。 3 风险评估框架及流程 本章提出了风险评估的要素关系

11、、分析原理及实施流程。 3.1 风险要素关系 资产所有者应对信息资产进行保护，通过分析信息资产的脆弱性来确定威胁可能利用哪些弱点来破坏其安全性。风险评估要识别资产相关要素的关系，从而判断资产面临的风险大小。 风险评估中各要素的关系如图3-1 所示： 脆弱性资产价值威胁资产风险安全需求业务战略安全事件残余风险安全措施利用暴露具有成本被满足未控制可能诱发演变增加导出依赖增加降低抵御未被满足 图 3-1 风险要素关系图 图3-1 中方框部分的内容为风险评估的基本要素，椭圆部分的内容是与这些要素相关的属性。风险评估围绕着这些基本要素展开，在对这些要素的评估过程中，需要充分考虑业务战略、资产价值、安全需

12、求、安全事件、残余风险等与这些基本要素相关的各类属性。 图 3-1 中的风险要素及属性之间存在着以下关系： 1. 业务战略的实现对资产具有依赖性，依赖程度越高，要求其风险越小； 2. 资产是有价值的，组织的业务战略对资产的依赖程度越高，资产价值就越大； 3. 资产价值越大，原则上则其面临的风险越大； 4. 风险是由威胁引发的，资产面临的威胁越多则风险越大，并可能导致安全事件； 5. 弱点越多，威胁利用脆弱性导致安全事件的可能性越大； 6. 脆弱性是未被满足的安全需求，威胁利用脆弱性危害资产，从而形成风险； 7. 风险的存在及对风险的认识导出安全需求； 8. 安全需求可通过安全措施得以满足，需要

13、结合资产价值考虑实施成本； 9. 安全措施可抵御威胁，降低安全事件发生的可能性，并减少影响； 10.风险不可能也没有必要降为零，在实施了安全措施后还可能有残余风险。有些残余风险的原因可能是安全措施不当或无效,需要继续控制；而有些残余风险则是在综合考虑了安全成本与效益后未去控制的风险，是可以接受的； 11.残余风险应受到密切监视，它可能会在将来诱发新的安全事件。 3.2 风险分析原理 风险分析原理如图3-2 所示： 威胁出现的频率脆弱性的严重程度资产价值安全事件的可能性安全事件的损失风险值威胁识别脆弱性识别资产识别 图 3-2 风险分析原理图 风险分析中要涉及资产、威胁、脆弱性等基本要素。每个要

14、素有各自的属性，资产的属性是资产价值；威胁的属性可以是威胁主体、影响对象、出现频率、动机等；脆弱性的属性是资产弱点的严重程度。风险分析的主要内容为： 1. 对资产进行识别，并对资产的价值进行赋值； 2. 对威胁进行识别，描述威胁的属性，并对威胁出现的频率赋值； 3. 对资产的脆弱性进行识别，并对具体资产的脆弱性的严重程度赋值； 4. 根据威胁及威胁利用弱点的难易程度判断安全事件发生的可能性； 5. 根据脆弱性的严重程度及安全事件所作用资产的价值计算安全事件的损失； 6. 根据安全事件发生的可能性以及安全事件的损失，计算安全事件一旦发生对组织的影响，即风险值。 3.3 实施流程 图3-3 给出风

15、险评估的实施流程，第4 章将围绕风险评估流程阐述风险评估各具体实施步骤。 图 3-3 风险评估实施流程图 4 风险评估准备过程 风险评估的准备过程是运维中心进行风险评估的基础，是整个风险评估过程有效性的保证。运维中心对信息及信息系统进行风险评估是一种战略性的考虑，其结果将受到运维中心业务需求及战略目标、文化、业务流程、安全要求、规模和结构的影响。因此在风险评估实施前，应： 1. 确定风险评估的范围； 2. 确定风险评估的目标； 3. 建立适当的组织结构； 4. 建立系统化的风险评估方法； 5. 获得最高管理者对风险评估策划的批准。 4.1 确定范围 进行风险评估是基于运维中心自身商业要求及战略

16、目标的要求，国家法律法规和行业监管要求，根据上述要求确定风险评估范围，每次评估范围可以是全公司的信息和信息系统，可以是单独的信息系统，可以是关键业务流程。此项工作需要在资产识别和分类工作基础上进行。 4.2 确定目标 运维中心的信息、信息系统、应用软件和网络是运维中心重要的资产，信息资产的机密性，完整性和可用性对于维持竞争优势，提高安全管理水平，符合法律法规要求和运维中心的形象是必要的。运维中心要面对来自四面八方日益增长的安全威胁，信息、信息系统、应用软件和网络可能是严重威胁的目标，同时由于运维中心信息化程度不断提高，对信息系统和技术的依赖日益增加，则可能出现更多的脆弱性。运维中心风险评估的目

17、标来源于业务持续发展的需要、满足国家法律法规和行业监管的要求等方面。 4.3 确定组织结构 在风险评估过程中，应建立适合的组织结构，以推进评估过程，成立由管理层、相关业务骨干、IT 技术人员等组成的风险评估小组，以保证能够满足风险评估的范围、目标。 4.4 确定风险评估方法 风险评估方法应考虑评估的范围、目的、时间、效果、组织文化、人员素质以及具体开展的程度等因素来确定，使之能够与运维中心的环境和安全要求相适应。 4.5 获得最高管理者批准 上述所有内容应得到运维中心管理层批准，并对相关部门和员工进行传达，就风险评估相关内容进行培训，以明确各有关人员在风险评估中的任务。 5 风险评估实施过程

18、信息安全各组成因素：资产的价值、对资产的威胁和威胁发生的可能性、资产脆弱性、现有的安全控制提供的保护，风险评估过程是综合以上因素而导出风险的过程，如图5-1 所示： 图 5-1 风险评估的过程 详细的风险评估方法描述 详细的风险评估是对资产、威胁和脆弱点进行详细的识别和估价，评估结果被用于评估风险和安全控制的识别和选择。通过识别资产的风险并将风险降低到可接受水平，来证明管理者所采用的安全控制是适当的。 详细的风险评估，需要仔细地制定被评估的信息系统范围内的业务环境、业务运营、信息和资产的边界，是一个需要管理者持续关注的方法，如下表： 风险评估 评估活动 资产赋值 识别和列出信息安全管理范围内被

19、评估的业务环境、业务运营和信息相关的所有的资产，定义一个价值尺度并为每一项资产分配价值（机密性、完整性和可用性的价值） 。 威胁评估 识别与资产相关的所有威胁，并根据它们发生的可能性为它们赋值。 脆弱性评估 识别与资产相关的所有的脆弱点，并根据它们被威胁利用的程度和严重性来赋值。 确定现有控制 识别与记录所有与资产相关联的、现有的控制。 风险评估 利用上述对资产、威胁、脆弱点的评价结果，进行风险评估，风险为资产的相对价值、威胁发生的可能性与脆弱点被利用的可能性的函数，采用适当的风险测量工具进行风险计算。 资产赋值 脆弱性评估 威胁评估 确定现有控制 风险评估 表 5-1 详细风险评估内容 详细

20、风险评估方法将安全风险作为资产、威胁及脆弱点的函数来进行识别与评估，具体程序包括： 1. 对资产（说明它们的价值、业务相关性）、威胁（说明它们发生的可能性）和脆弱性（说明有关它们的弱点和敏感性的程度）进行测量与赋值。 2. 使用预定义风险计算函数完成风险测量。 5.1 资产赋值 资产赋值就是要识别影响信息系统的信息资产（以下简称资产），并评估其价值，包括资产识别与资产赋值两部分。 1. 资产识别 资产是影响信息系统运行而需要保护的有用资源，资产以多种形式存在。运维中心资产分为：硬件类、系统服务类、支撑服务类、信息类、人员、无形资产等，每类资产具有不同价值属性和存在特点，固有的弱点、面临的威胁、

21、需要实施的保护和安全控制各不相同。 为了对资产进行有效的保护，组织需要在各个管理层对资产落实责任，进行恰当的管理。 在信息安全体系范围内识别资产并为资产编制清单是一项重要工作，每项资产都应该清晰地定义，在组织中明确资产所有权关系，进行安全分类，并以文件方式详细记录在案。 2. 资产赋值 为了明确对资产的保护，有必要对资产进行估价，其价值大小不仅仅是考虑其自身的价值，还要考虑其业务的相关性和一定条件下的潜在价值。资产价值常常是以安全事件发生时所产生的潜在业务影响来衡量，安全事件会导致资产机密性、完整性和可用性的损失，从而导致企业资金、市场份额、企业形象的损失。为了资产评估的一致性与准确性，组织应

22、当建立一个资产的价值评估标准，对每一种资产和每一种可能的损失，例如机密性、完整性和可用性的损失，都可以赋予一个价值。但采用精确的方式给资产赋值是较困难的一件事，一般采用定性的方式，按照事前建立的资产的价值评估标准将资产的价值划分为不同等级。经过资产的识别与估价后，组织应根据资产价值大小，进一步确定要保护的关键资产。 资产分别具有不同的安全属性，机密性、完整性和可用性分别反映了资产在三个不同方面的特性。安全属性的不同通常也意味着安全控制、保护功能需求的不同。通过考察三种不同安全属性，可以得出一个能够基本反映资产价值的数值。对信息资产进行估价赋值的目的是为了更好地反映资产的价值，以便于进一步考察资

23、产相关的弱点、威胁和风险属性，并进行量化。 在评估过程，为了保证没有资产被忽略和遗漏，应该先确定信息安全管理体系 (ISMS)范围，建立资产的评审边界。评估资产最简单的方式是列出组织业务过程中、安全管理体系范围内所有具有价值的资产，然后对资产赋予一定的价值，这种价值应该反映资产对组织业务运营的重要性，并以对业务的潜在影响程度表现出来。例如，资产价值越大，由于泄露、修改、损害、不可用等安全事件对组织业务的潜在影响就越大。基于组织业务需要的资产的识别与估价，是建立信息安全体系，确定风险的重要一步。 资产的价值应当由资产的所有者和相关用户来确定，只有他们才最清楚资产对组织业务的重要性，才能较准确地评

24、估出资产的实际价值。为确保资产赋值时的一致性和准确性，组织应建立一个资产价值评价尺度，以指导资产赋值。 在对资产赋予价值时，一方面要考虑资产购买成本及维护成本，另一方面主要考虑当这种资产的机密性、完整性、可用性受到损害时，对业务运营的负面影响程度。在信息安全管理中，并不是直接采用资产的账面价值，在运维中心风险评估中采用以定性分级的方式建立资产的相对价值，以相对价值来作为确定重要资产的依据和为这种资产的保护投入多大资源的依据。 5.1.1 资产分类 运维中心资产分类见下表： 大类 小类 名称 硬件类 H010 大型机 H020 小型机 H030 PC 服务器 H040 PC 台式机 H050 P

25、C 移动电脑 H060 业务终端 H070 通讯设施 大类 小类 名称 H080 网络交换机 H090 网络路由器 H100 负载均衡器 H110 网络安全设备 H120 数据存储设备 H130 移动存储设备 H140 存储介质 H150 纸质文档 H160 智能卡设备 H170 UPS 设备 H180 发电机 H190 设备管理间 H200 电线电缆 H210 显示设备 H220 监控设备 H230 传真机/传真系统 H240 照明设施 H250 供电设施 H260 供水设施 H270 暖通空调 H280 消防设施 H290 门禁系统 H300 打印机 H310 复印机 H320 扫描仪 H

26、330 投影机 H340 机架 系统服务类 S010 核心业务应用系统 大类 小类 名称 S020 辅助业务应用系统 S030 网络基础应用系统 S040 网络安全系统 S050 操作系统 S060 数据库 S070 中间件 S080 软件开发工具 S090 软件测试工具 S100 其他系统或服务 信息类 I010 软件 I020 开发文档及源代码 I030 用户文档 I040 系统业务数据 I050 系统支撑数据 I060 密码数据 I070 其他 支撑服务类 F010 通讯服务 F020 系统运行 F030 系统维护 F040 软件开发 F050 软件维护 F060 安全保卫 F070 人

27、力资源服务 F080 财务服务 F090 供电 F100 供暖 F110 消防 F120 照明 大类 小类 名称 F130 空调 F140 咨询服务 F150 培训服务 F160 审计服务 人员类 R010 管理层人员 R020 网络管理人员 R030 系统管理人员 R040 安全管理人员 R050 软件开发人员 R060 软件测试人员 R070 通讯管理人员 R080 文档管理人员 R090 系统用户 R100 企业客户 R110 签约供应商 R120 第三方人员 R130 临时人员 无形资产类 W010 公信力 W020 组织形象与声誉 W030 商标 W040 产品名称 W050 知识产

28、权 表 5-2 资产分类表 5.1.2 资产价值属性 除了机密性、完整性和可用性外，在运维中心风险评估中引入系统对业务的重要程度、资产对系统的重要程度，资产花费等资产价值属性，各价值属性图示如下： 系统对业务的重要程度系统服务范围业务对系统的依赖程度信息保密性信息完整性信息可用性资 产 信息重要性资产对业务的重要程度资产对系统的重要程度资产业务价值花费资产价值 图 5-2 资产价值属性 1. 系统服务范围：说明当前业务系统应用或服务的范围，评估人员可以人工分析并选择系统服务范围值。 2. 业务对系统的依赖程度：用于衡量部门业务对当前业务系统的依赖程度，评估人员可以人工分析并选择业务对系统的依赖

29、程度值。 3. 系统对业务的重要程度：用于衡量业务系统对业务的重要性，其值由系统服务范围和业务对系统的依赖程度确定。 4. 信息保密性：说明信息资产本身或硬件、系统服务类资产所包含信息的保密性价值，评估人员可以人工分析并选择信息保密性值。 5. 信息完整性：说明信息资产本身或硬件、系统服务类资产所包含信息的完整性价值，评估人员可以人工分析并选择信息完整性值。 6. 信息可用性：说明信息资产本身或硬件、系统服务类资产所包含信息的可用性价值，评估人员可以人工分析并选择信息可用性值。 7. 资产信息重要性：用于衡量信息资产本身或硬件、系统服务类资产所包含信息的信息价值，其值由信息保密性、信息完整性和

30、信息可用性确定。 8. 资产对系统的重要程度：用于衡量硬件、系统服务类资产对业务系统的可用性价值，评估人员可以人工分析并选择对系统的重要程度值。 9. 资产对业务的重要程度：用于衡量硬件、系统服务类资产对业务的重要性，其值由系统对业务的重要程度和资产对系统的重要程度确定。 10.资产业务价值：用于衡量硬件、系统服务、人员及其它类资产对业务的价值，对于人员及无形类资产，其值由对业务的重要程度确定，对于硬件、系统服务类资产，其值由对业务的重要程度和资产信息重要性确定。 11.花费：用于衡量购买或恢复被破坏的资产所需要的花消，评估人员可以人工分析并选择花费值。 12.资产价值：用于表示资产的重要性，

31、其值由资产业务价值和花费确定。 不同类别资产赋值可能采用不同的价值属性。具体见下表： 资产类别 价值属性 硬件类 系统服务类 信息类 支撑服务 人员 无形资产 系统服务范围 业务对系统的依赖程度 系统对业务的重要程度 保密性 完整性 可用性 资产CIA 重要性 资产对系统的重要程度 资产对业务的重要程度 资产业务价值 花费 表 5-3 不同资产采用的价值属性 5.1.3 资产价值属性赋值标准 运维中心风险评估使用的资产属性赋值标准见下表： 系统服务范围赋值 系统服务范围赋值 描述 1 运维中心内部。 2 面向开发基地。 3 面向整个公司内部。 4 面向整个公司内部及客户、政府、组织等。 表 5

32、-4 系统服务范围赋值表 业务对系统的依赖程度赋值 业务对系统依赖程度赋值 描述 1 整个业务处理流程可以通过手工方式或其他方式完成，而且这些替代方式对组织业务的开展没有或极少影响。 2 整个业务处理流程可以通过手工方式或其他方式完成，但这些替代方式对组织业务的开展有较大的影响。 3 业务处理流程的部分环节可以通过手工方式或其他方式替代完成, 这些替代方式对组织业务的开展有较大的影响。 4 业务处理流程完全依赖信息系统，手工方式无法完成。 表 5-5 业务对系统的依赖程度赋值表 系统对业务的重要程度计算 系统重要程度权值（W）系统服务范围值+业务对系统依赖程度值 系统重要程度值T1（ W） T

33、1 是非线性函数，用于将计算出的权值W 映射到5 级，得到系统重要程度值，见下表： 系统对业务重要程度赋值 描述 1 W=2， 3 2 W=4 3 W=5 4 W=6 5 W=7， 8 表 5-6 系统对业务的重要程度计算表 信息保密性赋值 信息保密性赋值 描述 1 信息的未授权泄露对运维中心的业务以及利益基本不会受到影响或损害极小。 2 信息的未授权泄露对运维中心的业务以及利益带来信息保密性赋值 描述 一定的损失或破坏。 3 信息的未授权泄露对运维中心的业务、利益以及整个公司利益带来严重的损失或破坏。 4 信息的未授权泄露对运维中心的业务、利益以及整个公司利益带来极其严重的损失或破坏。 5

34、信息的未授权泄露会对运维中心的业务、利益以及整个公司利益带来灾难性的损失或破坏。 表 5-7 信息保密性赋值表 信息完整性赋值 信息完整性赋值 描述 1 信息的未授权的修改或破坏对运维中心的业务以及利益基本不会受到影响或损害极小。 2 信息的未授权的修改或破坏对运维中心的业务以及利益带来一定的损失或破坏。 3 信息的未授权的修改或破坏对运维中心的业务、利益以及整个公司利益带来严重的损失或破坏。 4 信息的未授权的修改或破坏会对运维中心的业务、利益以及整个公司利益带来极其严重的损失或破坏。 5 信息的未授权的修改或破坏会对运维中心的业务、利益以及整个公司利益带来灾难性的损失或破坏。 表 5-8

35、信息完整性赋值表 信息可用性赋值 信息可用性赋值 描述 1 可用性价值可以忽略，合法使用者对信息及信息系统的可用度在正常工作时间低于25% 2 可用性价值较低，合法使用者对信息及信息系统的可用度在正常工作时间达到25%以上 3 可用性价值中等，合法使用者对信息及信息系统的可用信息可用性赋值 描述 度在正常工作时间达到70%以上 4 可用性价值较高，合法使用者对信息及信息系统的可用度达到每天90%以上 5 可用性价值非常高，合法使用者对信息及信息系统的可用度达到年度99.9%以上 表 5-9 信息可用性赋值表 资产CIA 重要性计算 资产CIA 重要性值MAX（保密性值、完整性值、可用性值） 资

36、产对系统的重要程度赋值 对系统的重要程度赋值 描述 1 资产出现问题对整个业务系统的可用性影响极小或没有影响。 2 资产出现问题对整个业务系统的可用性有一定的影响。 3 资产出现问题对整个业务系统的可用性有较大的影响。 4 资产出现问题将导致整个业务系统丧失可用性。 表 5-10 资产对系统的重要程度赋值表 资产对业务的重要程度计算 资产对业务的重要程度权重(W)系统对业务的重要程度值资产对系统的重要程度值 资产对业务的重要程度值T2（ W） T2 是非线性函数，用于将计算出的权值W 映射到5 级，得到资产对业务重要程度值，见下表： 资产对业务重要程度赋值 描述 1 W=1， 2 2 W=3，

37、 4， 5 3 W=6， 8， 9 4 W=10， 12 资产对业务重要程度赋值 描述 5 W=15， 16， 20 表 5-11 资产对业务的重要程度计算表 资产业务价值计算 资产业务价值MAX（资产对业务的重要程度值、资产CIA 重要性值） 花费赋值 资产花费赋值 描述 1 购买或恢复资产花费=0.1 万元。 2 0.1 万元购买或恢复资产花费1 万元。 3 1 万元购买或恢复资产花费10 万元。 4 10 万元购买或恢复资产花费50 万元。 5 50 万元 1 次 /半年）；或在某种情况下可能会发生；或被证实曾经发生过。 2 低 出现的频率较小；或一般不太可能发生；或没有被证实发生过。

38、1 很低 威胁几乎不可能发生，仅可能在非常罕见和例外的情况下发生。 表 5-15 威胁赋值表 5.3 脆弱性评估 脆弱性评估也称为漏洞评估，是风险评估中重要内容。脆弱性是信息资产自身存在的，它可以被威胁利用、引起资产或商业目标的损害。脆弱性包括物理环境、组织、过程、人员、管理、配置、硬件、软件和信息等各种资产的弱点。 值得注意的是，脆弱性虽然是信息资产本身固有的，但它本身不会造成损失，它只是一种条件或环境、可能导致被威胁利用而造成资产损失。所以如果没有相应的威胁发生，单纯的脆弱性并不会对资产造成损害。那些没有安全威胁的脆弱性可以不需要实施安全保护措施，但它们必须记录下来以确保当环境、条件有所变

39、化时能随之加以改变安全保护，需要注意的是不正确的、起不到应有作用的或没有正确实施的安全保护措施本身就可能是一个安全脆弱性环节。 脆弱性评估将针对每一项需要保护的信息资产，找出每一种威胁所能利用的脆弱性，并对脆弱性的严重程度进行评估，即对脆弱性被威胁利用的可能性进行评估，最终为其赋值。在进行脆弱性评估时，提供的数据应该来自于这些资产的拥有者或使用者，来自于相关业务领域的专家以及软硬件信息系统方面的专业人员。脆弱性评估所采用的方法主要为：问卷调查、访谈、工具扫描、手动检查、文档审查、渗透测试等。 在运维中心风险评估中采用问卷调查、小组访谈、工具扫描和人工检查等方法。 脆弱性的识别以资产为核心，即根

40、据每个资产分别识别其存在的弱点，然后综合评价该资产的脆弱性。 脆弱性识别主要从技术和管理两个方面进行，技术脆弱性涉及物理层、网络层、系统层、应用层等各个层面的安全问题。管理脆弱性又可分为技术管理和组织管理两方面，前者与具体技术活动相关，后者与管理环境相关。 脆弱性识别内容如下表述： 类型 识别对象 识别内容 技 术 脆弱性 物理环境 从机房场地、机房防火、机房供配电、机房防静电、机房接地与防雷、电磁防护、通信线路的保护、机房区域防护、机房设备管理等方面进行识别。 服务器（含操作系统） 从物理保护、用户帐号、口令策略、资源共享、事件审计、访问控制、新系统配置（初始化）、注册表加固、网络安全、系统

41、管理等方面进行识别。 网络结构 从网络结构设计、边界保护、外部访问控制策略、内部访问控制策略、网络设备安全配置等方面进行识别。 数据库 从补丁安装、鉴别机制、口令机制、访问控制、网络和服务设置、备份恢复机制、审计机制等方面进行识别。 应用系统 审计机制、审计存储、访问控制策略、数据完整性、通信、鉴别机制、密码保护等方面进行识别。 管 理 脆弱性 技术管理 物理和环境安全、通信与操作管理、访问控制、系统开发与维护、业务连续性。 组织管理 安全策略、组织安全、资产分类与控制、人员安全、符合性 表 5-16 弱点分类表 安全控制措施的使用将减少脆弱性，考虑对现有安全控制措施的确认，采用等级方式对已识

42、别的脆弱性的严重程度进行赋值。 脆弱性严重程度的等级划分为五级，分别代表资产脆弱性严重程度的高低。等级数值越大，脆弱性严重程度越高。 运维中心风险评估对脆弱性采用以下赋值方法： 等级 影响 技术 攻击角度 管理 防范角度 等级 影响 技术 攻击角度 管理 防范角度 1(可忽略) 如 果 被 威胁利用，将对 资 产 造成 的 损 害可以忽略。 技术方面 存 在 着 低等级缺陷，从技 术 角 度 很难被利用 对于攻击者来说，该漏洞目前还不能够被直接或者间接利用，或者利用的难度极高 组织管理中没有相关的薄弱环节，很难被利用 有规定 ， 严 格审 核 、 记录、校验 2(低 ) 如 果 被 威胁利用，

43、将对 资 产 造成 较 小 损害。 技术方面 存 在 着 低等级缺陷，从技 术 角 度 难以被利用 对于攻击者来说，该漏洞无法被直接利用(需要 其 他 条 件 配合 )或者利用的难度较高 组织管理中没有相应的薄弱环节，难以被利用 有规定 ， 职 责明 确 ， 有专 人 负 责检 查 执 行落实情况 ， 有 记录 3(中 ) 如 果 被 威胁利用，将对 资 产 造成 一 般 损害。 技术方面 存 在 着 一般缺陷，从技术 角 度 可 以被利用 可以配合其他条件被攻击者加以直接利用，或者该漏洞的利用有一定的难度 组织管理中没有明显的薄弱环节，可以被利用 有规定 ， 定 期检查落实 ， 有 记录 4

44、(高 ) 如 果 被 威胁利用，将对 资 产 造成 重 大 损害。 技术方面 存 在 着 严重的缺陷，比较 容 易 被 利用 一 个 特 定 漏洞，可以配合其他条件被攻击者加以直接利用，或者该漏洞的利用有一定的难度 组织管理中存在着薄弱环节，比较容易被利用 有规定 执 行完 全 靠 人自觉 5(极高 ) 如 果 被 威胁利用，将对 资 产 造 技术方面 存 在 着 非常 严 重 的 缺 在没有任何保护 措 施 的 情 况下，暴露于低安 组织管理中存在着明显的薄弱环 无 人 负责 ， 无 人过问 等级 影响 技术 攻击角度 管理 防范角度 成 完 全 损害。 陷， 很容易被利用 全级别网络上 节

45、，并且很容易被利用 表 5-17弱点赋值表 5.4 确定现有控制 在识别脆弱性的同时，评估人员应对已采取的安全措施的有效性进行确认。安全措施的确认应评估其有效性，即是否真正地降低了系统的脆弱性，抵御了威胁。对有效的安全措施继续保持，以避免不必要的工作和费用，防止安全措施的重复实施。对确认为不适当的安全措施应核实是否应被取消或对其进行修正，或用更合适的安全措施替代。 安全措施可以分为预防性安全措施和保护性安全措施两种。预防性安全措施可以降低威胁利用脆弱性导致安全事件发生的可能性，如入侵检测系统；保护性安全措施可以减少因安全事件发生后对组织或系统造成的影响，如业务持续性计划。 已有安全措施确认与脆

46、弱性识别存在一定的联系。一般来说，安全措施的使用将减少系统技术或管理上的弱点，但安全措施确认并不需要和脆弱性识别过程那样具体到每个资产、组件的弱点，而是一类具体措施的集合，为风险处理计划的制定提供依据和参考。 5.5 风险评估 完成资产评估、威胁评估、脆弱性评估后，并考虑已有安全措施的情况下，利用恰当的方法与工具确定威胁利用资产脆弱性发生安全事件的可能性，并结合资产的安全属性受到破坏后的影响得出信息资产的风险。 5.5.1 风险值计算 在完成了资产识别、威胁识别、脆弱性识别，以及对已有安全措施确认后，将采用适当的方法与工具确定威胁利用脆弱性导致安全事件发生的可能性。综合安全事件所作用的资产价值

47、及脆弱性的严重程度，判断安全事件造成的损失对组织的影响，即安全风险。使用本方法需要首先确定信息资产、威胁和脆弱性的赋值，要完成这些赋值，需要管理人员、技术人员的配合。 运维中心风险评估中风险值计算方式如下： 风险值(RW)资产价值威胁可能性值脆弱性严重程度值 5.5.2 风险等级划分 确定风险数值的大小不是风险评估的最终目的，重要的是明确不同威胁对资产所产生的风险的相对值，即要确定不同风险的优先次序或等级，对于风险级别高的资产应被优先分配资源进行保护。 风险等级在运维中心风险评估中采用分值计算表示。分值越大，风险越高。见下表。 风险等级 标识 风险值范围 描述 建议处置方式 1 很低 RW 5

48、 发生安全事件的可能性极小，即使发生对系统或组织也基本没影响。 A-接受 2 低 6 RW10 发生安全事件的可能性较小，安全事件发生后使系统受到的破坏较小或使组织利益受到的损失较少。 A-接受 3 中 11 RW30 发生安全事件的可能性一般，安全事件发生后将使系统受到一定的破坏或使组织利益受到一定的损失。 B-降低 4 高 31 RW40 发生安全事件的可能性较大，安全事件发生后将使系统受到较大的破坏或使组织利益受到较多的损失。 B-降低 5 极高 41 RW 发生安全事件的可能性很大，安全事件发生后将使系统受到很大的破坏或使组织利益受到很多的损失。 B-降低 表 5-20风险等级描述表

49、5.5.3 风险评估结果纪录 风险评估的过程需要形成相关的文件及记录，文档管理考虑以下控制： 1. 文件发布前得到批准，以确保文件是充分的； 2. 必要时对文件进行评审、更新并再次批准； 3. 确保文件的更改和现行修订状态得到识别； 4. 确保在使用时，可获得有关版本的适用文件； 5. 确保文件保持清晰、易于识别； 6. 确保外来文件得到识别； 7. 确保文件的分发得到适当的控制； 8. 防止作废文件的非预期使用，若因任何目的需保留作废文件时，应对这些文件进行适当的标识。 对于风险评估过程中形成的记录，还应规定记录的标识、储存、保护、检索、保存期限以及处置所需的控制。记录是否需要以及详略程度由

50、管理过程来决定。 风险评估过程应形成下列文件： 1. 风险评估过程计划：该计划中应阐述风险评估的范围、目标、组织机构、评估过程所需资源、形成的评估结果。 2. 风险评估程序：程序中应明确评估的目的、职责、过程、相关的文件要求，并且准备评估阶段需要的表格，如信息资产识别与评估表。 3. 信息资产识别清单：根据在风险评估程序文件中规定的资产分类方法进行资产的识别，并形成信息资产识别清单，清单中应明确各资产的负责人/部门。 4. 威胁参考列表：应根据评估对象、环境等因素，形成威胁的分类方法及具体的威胁列表，为风险评估提供支持。 5. 脆弱性参考列表：应针对不同分类的评估对象自身的弱点，形成脆弱性参考

51、列表，为风险评估提供支持。 6. 风险评估记录：根据组织的风险评估程序文件，记录对重要信息资产的风险评估过程，包括脆弱性、威胁的赋值，已有安全控制措施的确认，风险值的计算与等级划分。 7. 风险评估报告：风险评估报告应对整个风险评估过程进行总结，说明组织的风险状况及残余风险状况，通过管理层的评审，确定评估后的风险状况满足业务发展及其他相关方的要求。 上述文件均应由运维中心管理层批准。 6 风险管理过程 通过风险评估对风险进行识别与估价后，引入合适的控制措施，对风险实施管理，把风险降低到运维中心可以接受的程度，对风险的管理过程如下图所示： 安全控制措施的识别与选择接受风险降低风险风险评估过程 图

52、 6-1 风险管理过程 6.1 安全控制的识别与选择 选择安全控制的另一个重要方面就是费用因素，如果实施与维护这些控制的费用比资产遭受威胁所造成的损失的预期值还要高，那么所选择的控制是不适合的；如果控制费用比组织计划的安全预算要高，也是不适当的。但如果由于预算不足使控制的数据与质量下降，就会使系统产生不必要的风险，对此要特别注意。安全控制预算应该作为一个限制性的因素加以考虑。同样，也可以对现有的控制进行费用比较，如果现有控制不是充分有效，就要考虑取消或改进。 根据ISO27001的要求，运维中心在以下领域引入控制措施： 1. 安全政策 2. 信息安全的组织 3. 资产管理 4. 人力资源安全

53、5. 物理与环境安全 6. 通讯与操作管理 7. 访问控制 8. 信息系统获取、开发及维护 9. 信息安全事故管理 10.业务连续性管理 11.符合性 控制的选择要考虑非技术性的控制与技术性的控制之间的平衡，两种控制之间是互相支持与互补的。运营管理包括物理、人员、行政管理等方面安全的控制。 当选择安全控制措施进行实施时的考虑因素： 1. 控制的易用性 2. 用户的透明度 3. 为用户提供帮助，以发挥他们的绩效 4. 控制的相对强度 5. 实现的功能类型预防、威慑、探测、恢复、纠正、监控和安全意识教育 一般来说，一个控制可以实现多个功能，实现得越多越好。在考虑总体安全性或应用一系列控制的时候，应

54、尽可能保持各种功能之间的平衡，这有助于总体安全获得较好的效果与较高的效率。 为了实现组织的安全需求，有必要认清引起风险的原因：信息资产的脆弱性及面临的威胁，这些原因可以通过风险评估过程而确定。 6.2 降低风险 为了识别风险，要综合考虑威胁、脆弱性及其他风险评估的结果；一旦风险被识别出来后，下一步要做的工作就是选择控制措施减少风险，即通过以下途径达到降低风险的目的： 1. 避免风险：例如将重要的计算机系统与Internet 隔离，免受外部网络的攻击。 2. 转移风险：例如通过购买商业保险将风险进行转移，或将高风险的信息处理业务外包给第三方。 3. 减少威胁：例如通过安装防病毒软件，防止系统受病

55、毒感染。 4. 减少脆弱性：例如系统经常性地安装补丁包，修补系统漏洞，以防止系统脆弱性被利用。 5. 减少可能的影响：例如建立业务持续性计划，把灾难造成的损失降到最低。 6. 检测意外事件，响应，并恢复：例如使用网络管理系统，网络性能与故障进行监测，及时发现出现的问题。 选择哪一种减少风险的方式，要根据运营的具体业务环境与条件来决定，为减少风险所选的控制要与特定的业务要求相匹配，而且要对所选的控制进行充分的评估。 6.3 接受风险 运维中心在实施所选择的控制措施后，始终存在残留风险，这是因为信息系统不可能是绝对安全的，甚至有些残留风险是企业有意对某些资产没有进行保护而造成的，这是由于风险较低或

56、要实施安全控制的成本太高。 风险接受是一个对残留风险进行确认和评价的过程。在安全控制实施后，运维中心需要对己实施的安全控制进行评审，即对所选择的控制措施在多大程度上降低了风险做出判断，并根据残留风险的大小，将残留风险分为“可接受的”或“不可接受”的风险。对于无法接受的风险，不应该容忍，而应该考虑增加控制以降低风险。对于每一个无法接受的风险，必须做出业务决策以判断是否接受这个风险，或者增加控制费用将风险降到一个可以接受的水平。 运维中心针对评估结果中不可接受的风险制定风险处理计划，选择适当的控制目标及控制措施，明确责任、进度、资源，并通过对残余风险的评价确保所选择控制的有效。 运维中心在完成了风

57、险评估、降低风险与接受风险的风险管理过程后，可以将风险控制在一个可以接受的水平，但这并不意识着风险评估工作的结束。事实上，随着时间的推移，由于运维中心的业务环境在不断变化，新的威胁与脆弱性也在不断增加，组织由于业务要求可能要增加新的信息处理设施，有关信息的法律法规也在变化，所以，风险也是随时间而变化的，风险管理是动态的、持续改进的过程，组织需要进行动态的风险评估与风险管理。特别是在以下情况发生时，来进行临时的风险评估，以便及时识别风险并进行有效控制： 1. 当新增信息资产时； 2. 当信息系统发生重大变更时； 3. 发生严重信息安全事故时； 4. 企业认为有必要时。 6.4 风险管理要求 1.

58、 风险评估和管理要至少每年进行一次。 2. 信息安全主管要： 1) 指定具备风险评估和管理方法的知识的某一独立方(风险评估员)进行风险评估。 2) 与风险评估员合作确定需要参与风险评估的工作组。 3) 按照安全关切和对风险评估员的业务流程的重要程度商定风险评估的范围。 4) 与风险评估员商定风险可能性和风险影响程度并从有关的工作组获取输入。 3. 风险评估和风险管理会产生以下项目: 1) 风险评估报告： 记录评估过程中包括的资产、环境和组织 参与风险评估的各方 风险情形的优先顺序表 2) 对于风险评估报告中确定为极高或高类别(合称高风险)的风险类别，需要编定风险管理报告记录建议的风险化解措施，例如： 增加新的安全控制措施 变更现有的安全控制措施 增加新的控制目标、控制措施、过程和程序 资源的调配安排 4. 信息安全主管应在信息安全管理工作小组会议上出具风险评估报告。 5. 信息安全管理工作小组应： 1) 审议风险评估报告和建议的风险化解措施。 2) 决定采用哪种风险化解措施。 3) 发起ISMS 评审并将建议的变更记入信息安全体系审核表格。 6. 信息安全主管应适当执行变更并关闭信息安全体系审核表格。 7 相关文件 无。