风险评估管理程序教材

1 风险评估管理程序风险评估管理程序 历史修订记录历史修订记录 序号序号更改单号更改单号更改说明更改说明修订人修订人生效日期生效日期现行版次现行版次 2 目目 录录 1 概述 .5 2 术语与定义 .5 2.1 风险管理5 2.1.1 风险评估 .5 2.2 其他6 3 风险评估框架及流程 .7 3.1 风险要素关系7 3 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 资产分类 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 4 5 1 1 概述概述 目前信息安全管理的发展趋势是将风险管理与信息安全管理紧密结合在一起， 将风险概念作为信息安全管理实践的对象和出发点，信息安全管理的控制点以风 险出现的可能性作为对象而展开的。ISO27001 标准对信息安全管理体系(ISMS)的 要求即通过对信息资产的风险管理,确定重要信息资产清单以及风险等级,从而采 取相应的控制措施来实现信息资产的安全。 信息安全管理是风险管理的过程，风险评估是风险管理的基础。风险管理是 指导和控制组织风险的过程。风险管理遵循管理的一般循环模式计划 (Plan)、 执行 (Do)、检查 (Check)、行动 (Action)的持续改进模式。ISO27001 标准要求 企业设计、实施、维护信息安全管理体系都要依据 PDCA 循环模式。 2 2 术语与定义术语与定义 2.12.1风险管理风险管理 风险管理是以可接受成本识别、评估、控制、降低可能影响信息系统风险的 过程，通过风险评估识别风险，通过制定信息安全方针，采取适当的控制目标与 控制方式对风险进行控制，使风险被避免、转移或降低到一个可以被接受的水平， 同时考虑控制费用与风险之间的平衡。 风险管理的核心是信息的保护。信息对于组织是一种具有重要价值的资产。 建立信息安全管理体系(ISMS)的目的是在最大范围内保护信息资产，确保信息的 机密性、完整性和可用性，将风险管理自始至终的贯穿于整个信息安全管理体系 中，这种体系并不能完全消除信息安全的风险，只是尽量减少风险，尽量将攻击 造成的损失降低到最低限度。 2.1.12.1.1 风险评估风险评估 风险评估指风险分析和风险评价的整个过程，其中风险分析是指系统化地识 别风险来源和风险类型，风险评价是指按组织制定的风险标准估算风险水平，确 定风险严重性。 风险评估的出发点是对与风险有关的各因素的确认和分析，与信息安全风险 有关的因素可以包括四大类：资产、威胁、脆弱性、安全控制措施。 风险评估是对信息和信息处理设施的威胁、脆弱性和风险的评估，它包含以 下元素： 6 风险是被特定威胁利用的资产的一种或一组脆弱性，导致资产丢失或损害的 潜在可能性，即特定威胁事件发生的可能性与后果的结合。 资产是对组织具有价值的信息资源，是安全控制措施保护的对象。 威胁是可能对资产或组织造成损害的事故的潜在原因。 脆弱性是资产或资产组中能被威胁利用的弱点。 安全控制措施是降低风险的措施、程序或机制。 2.22.2其他其他 1. 资产 Asset：对组织具有价值的信息或资源，是安全策略保护的对象。 2. 资产价值 Asset Value：资产的重要程度或敏感程度的表征。资产价值是 资产的属性，也是进行资产识别的主要内容。 3. 机密性 confidentiality：数据所具有的特性，即表示数据所达到的未提 供或未泄露给未授权的个人、过程或其他实体的程度。 4. 完整性 integrity：保证信息及信息系统不会被非授权更改或破坏的特性。 包括数据完整性和系统完整性。 5. 可用性 availability：数据或资源的特性，被授权实体按要求能访问和 使用数据或资源。 6. 数据完整性 data integrity ：数据所具有的特性，即无论数据形式作何 变化，数据的准确性和一致性均保持不变。 7. 系统完整性 system integrity ：在防止非授权用户修改或使用资源和防 止授权用户不正确地修改或使用资源的情况下，信息系统能履行其操作目的的品 质。 8. 信息安全风险 information security risk：人为或自然的威胁利用信 息系统及其管理体系中存在的脆弱性导致安全事件的发生及其对组织造成的影响。 9. 信息安全风险评估 information security risk assessment：依据有关 信息安全技术与管理标准，对信息系统及由其处理、传输和存储的信息的机密性、 完整性和可用性等安全属性进行评价的过程。它要评估资产面临的威胁以及威胁 利用脆弱性导致安全事件的可能性，并结合安全事件所涉及的资产价值来判断安 全事件一旦发生对组织造成的影响。 10.信息系统 information system：由计算机及其相关的和配套的设备、 7 设施(含网络)构成的，按照一定的应用目标和规则对信息进行采集、加工、存储、 传输、检索等处理的人机系统。典型的信息系统由三部分组成：硬件系统（计算 机硬件系统和网络硬件系统） ；系统软件（计算机系统软件和网络系统软件） ；应 用软件（包括由其处理、存储的信息） 。 11.检查评估 inspection assessment：由被评估组织的上级主管机关或业 务主管机关发起的，依据国家有关法规与标准，对信息系统及其管理进行的具有 强制性的检查活动。 12.组织 organization：由作用不同的个体为实施共同的业务目标而建立 的结构。组织的特性在于为完成目标而分工、合作；一个单位是一个组织，某个 业务部门也可以是一个组织。 13.残余风险 residual risk：采取了安全措施后，仍然可能存在的风险。 14.自评估 self-assessment：由组织自身发起，参照国家有关法规与标准， 对信息系统及其管理进行的风险评估活动。 15.安全事件 security event ：指系统、服务或网络的一种可识别状态的 发生，它可能是对信息安全策略的违反或防护措施的失效，或未预知的不安全状 况。 16.安全措施 security measure：保护资产、抵御威胁、减少脆弱性、降 低安全事件的影响，以及打击信息犯罪而实施的各种实践、规程和机制的总称。 17.安全需求 security requirement：为保证组织业务战略的正常运作而 在安全措施方面提出的要求。 18.威胁 threat：可能导致对系统或组织危害的不希望事故潜在原因。 19.脆弱性 vulnerability：可能被威胁所利用的资产或若干资产的弱点。 3 3 风险评估框架及流程风险评估框架及流程 本章提出了风险评估的要素关系、分析原理及实施流程。 3.13.1风险要素关系风险要素关系 资产所有者应对信息资产进行保护，通过分析信息资产的脆弱性来确定威胁 可能利用哪些弱点来破坏其安全性。风险评估要识别资产相关要素的关系，从而 判断资产面临的风险大小。 风险评估中各要素的关系如图 3-1 所示： 8 脆弱性资产价值 威胁 资产 风险安全需求 业务战略 安全事件残余风险安全措施 利用 暴露具有 成本 被满足 未控制可能诱发 演变 增加导出 依赖 增加 降低 抵御 未被满足 图 3-1 风险要素关系图 图 3-1 中方框部分的内容为风险评估的基本要素，椭圆部分的内容是与这些 要素相关的属性。风险评估围绕着这些基本要素展开，在对这些要素的评估过程 中，需要充分考虑业务战略、资产价值、安全需求、安全事件、残余风险等与这 些基本要素相关的各类属性。 图 3-1 中的风险要素及属性之间存在着以下关系： 1. 业务战略的实现对资产具有依赖性，依赖程度越高，要求其风险越小； 2. 资产是有价值的，组织的业务战略对资产的依赖程度越高，资产价值就 越大； 3. 资产价值越大，原则上则其面临的风险越大； 4. 风险是由威胁引发的，资产面临的威胁越多则风险越大，并可能导致安 全事件； 5. 弱点越多，威胁利用脆弱性导致安全事件的可能性越大； 6. 脆弱性是未被满足的安全需求，威胁利用脆弱性危害资产，从而形成风 险； 7. 风险的存在及对风险的认识导出安全需求； 8. 安全需求可通过安全措施得以满足，需要结合资产价值考虑实施成本； 9. 安全措施可抵御威胁，降低安全事件发生的可能性，并减少影响； 9 10.风险不可能也没有必要降为零，在实施了安全措施后还可能有残余风险。 有些残余风险的原因可能是安全措施不当或无效,需要继续控制；而有些残余风 险则是在综合考虑了安全成本与效益后未去控制的风险，是可以接受的； 11.残余风险应受到密切监视，它可能会在将来诱发新的安全事件。 3.23.2风险分析原理风险分析原理 风险分析原理如图 3-2 所示： 威胁出现的频率 脆弱性的严重程度 资产价值 安全事件的可能性 安全事件的损失 风险值 威胁识别 脆弱性识别 资产识别 图 3-2 风险分析原理图 风险分析中要涉及资产、威胁、脆弱性等基本要素。每个要素有各自的属性， 资产的属性是资产价值；威胁的属性可以是威胁主体、影响对象、出现频率、动 机等；脆弱性的属性是资产弱点的严重程度。风险分析的主要内容为： 1. 对资产进行识别，并对资产的价值进行赋值； 2. 对威胁进行识别，描述威胁的属性，并对威胁出现的频率赋值； 3. 对资产的脆弱性进行识别，并对具体资产的脆弱性的严重程度赋值； 4. 根据威胁及威胁利用弱点的难易程度判断安全事件发生的可能性； 5. 根据脆弱性的严重程度及安全事件所作用资产的价值计算安全事件的损 失； 6. 根据安全事件发生的可能性以及安全事件的损失，计算安全事件一旦发 生对组织的影响，即风险值。 3.33.3实施流程实施流程 图 3-3 给出风险评估的实施流程，第 4 章将围绕风险评估流程阐述风险评估 各具体实施步骤。 10 图 3-3 风险评估实施流程图 4 4 风险评估准备过程风险评估准备过程 风险评估的准备过程是运维中心进行风险评估的基础，是整个风险评估过程 有效性的保证。运维中心对信息及信息系统进行风险评估是一种战略性的考虑， 其结果将受到运维中心业务需求及战略目标、文化、业务流程、安全要求、规模 和结构的影响。因此在风险评估实施前，应： 1. 确定风险评估的范围； 2. 确定风险评估的目标； 3. 建立适当的组织结构； 4. 建立系统化的风险评估方法； 5. 获得最高管理者对风险评估策划的批准。 4.14.1确定范围确定范围 进行风险评估是基于运维中心自身商业要求及战略目标的要求，国家法律法 规和行业监管要求，根据上述要求确定风险评估范围，每次评估范围可以是全公 司的信息和信息系统，可以是单独的信息系统，可以是关键业务流程。此项工作 11 需要在资产识别和分类工作基础上进行。 4.24.2确定目标确定目标 运维中心的信息、信息系统、应用软件和网络是运维中心重要的资产，信息 资产的机密性，完整性和可用性对于维持竞争优势，提高安全管理水平，符合法 律法规要求和运维中心的形象是必要的。运维中心要面对来自四面八方日益增长 的安全威胁，信息、信息系统、应用软件和网络可能是严重威胁的目标，同时由 于运维中心信息化程度不断提高，对信息系统和技术的依赖日益增加，则可能出 现更多的脆弱性。运维中心风险评估的目标来源于业务持续发展的需要、满足国 家法律法规和行业监管的要求等方面。 4.34.3确定组织结构确定组织结构 在风险评估过程中，应建立适合的组织结构，以推进评估过程，成立由管理 层、相关业务骨干、IT 技术人员等组成的风险评估小组，以保证能够满足风险评 估的范围、目标。 4.44.4确定风险评估方法确定风险评估方法 风险评估方法应考虑评估的范围、目的、时间、效果、组织文化、人员素质 以及具体开展的程度等因素来确定，使之能够与运维中心的环境和安全要求相适 应。 4.54.5获得最高管理者批准获得最高管理者批准 上述所有内容应得到运维中心管理层批准，并对相关部门和员工进行传达， 就风险评估相关内容进行培训，以明确各有关人员在风险评估中的任务。 5 5 风险评估实施过程风险评估实施过程 信息安全各组成因素：资产的价值、对资产的威胁和威胁发生的可能性、资 产脆弱性、现有的安全控制提供的保护，风险评估过程是综合以上因素而导出风 险的过程，如图 5-1 所示： 12 资产赋值资产赋值脆弱性评估脆弱性评估 威胁评估威胁评估确定现有控制确定现有控制 风险评估风险评估 图 5-1 风险评估的过程 详细的风险评估方法描述 详细的风险评估是对资产、威胁和脆弱点进行详细的识别和估价，评估结果 被用于评估风险和安全控制的识别和选择。通过识别资产的风险并将风险降低到 可接受水平，来证明管理者所采用的安全控制是适当的。 详细的风险评估，需要仔细地制定被评估的信息系统范围内的业务环境、业 务运营、信息和资产的边界，是一个需要管理者持续关注的方法，如下表： 风险评估风险评估评估活动评估活动 资产赋值识别和列出信息安全管理范围内被评估的业务环境、业 务运营和信息相关的所有的资产，定义一个价值尺度并 为每一项资产分配价值（机密性、完整性和可用性的价 值） 。 威胁评估识别与资产相关的所有威胁，并根据它们发生的可能性 为它们赋值。 脆弱性评估识别与资产相关的所有的脆弱点，并根据它们被威胁利 用的程度和严重性来赋值。 确定现有控制识别与记录所有与资产相关联的、现有的控制。 风险评估利用上述对资产、威胁、脆弱点的评价结果，进行风险 评估，风险为资产的相对价值、威胁发生的可能性与脆 弱点被利用的可能性的函数，采用适当的风险测量工具 进行风险计算。 13 表 5-1 详细风险评估内容 详细风险评估方法将安全风险作为资产、威胁及脆弱点的函数来进行识别与 评估，具体程序包括： 1. 对资产（说明它们的价值、业务相关性） 、威胁（说明它们发生的可能性） 和脆弱性（说明有关它们的弱点和敏感性的程度）进行测量与赋值。 2. 使用预定义风险计算函数完成风险测量。 5.15.1资产赋值资产赋值 资产赋值就是要识别影响信息系统的信息资产（以下简称资产） ，并评估其 价值，包括资产识别与资产赋值两部分。 1. 资产识别 资产是影响信息系统运行而需要保护的有用资源，资产以多种形式存在。运 维中心资产分为：硬件类、系统服务类、支撑服务类、信息类、人员、无形资产 等，每类资产具有不同价值属性和存在特点，固有的弱点、面临的威胁、需要实 施的保护和安全控制各不相同。 为了对资产进行有效的保护，组织需要在各个管理层对资产落实责任，进行 恰当的管理。 在信息安全体系范围内识别资产并为资产编制清单是一项重要工作，每项资 产都应该清晰地定义，在组织中明确资产所有权关系，进行安全分类，并以文件 方式详细记录在案。 2. 资产赋值 为了明确对资产的保护，有必要对资产进行估价，其价值大小不仅仅是考虑 其自身的价值，还要考虑其业务的相关性和一定条件下的潜在价值。资产价值常 常是以安全事件发生时所产生的潜在业务影响来衡量，安全事件会导致资产机密 性、完整性和可用性的损失，从而导致企业资金、市场份额、企业形象的损失。 为了资产评估的一致性与准确性，组织应当建立一个资产的价值评估标准，对每 一种资产和每一种可能的损失，例如机密性、完整性和可用性的损失，都可以赋 予一个价值。但采用精确的方式给资产赋值是较困难的一件事，一般采用定性的 方式，按照事前建立的资产的价值评估标准将资产的价值划分为不同等级。经过 资产的识别与估价后，组织应根据资产价值大小，进一步确定要保护的关键资产。 14 资产分别具有不同的安全属性，机密性、完整性和可用性分别反映了资产在 三个不同方面的特性。安全属性的不同通常也意味着安全控制、保护功能需求的 不同。通过考察三种不同安全属性，可以得出一个能够基本反映资产价值的数值。 对信息资产进行估价赋值的目的是为了更好地反映资产的价值，以便于进一步考 察资产相关的弱点、威胁和风险属性，并进行量化。 在评估过程，为了保证没有资产被忽略和遗漏，应该先确定信息安全管理体 系(ISMS)范围，建立资产的评审边界。评估资产最简单的方式是列出组织业务过 程中、安全管理体系范围内所有具有价值的资产，然后对资产赋予一定的价值， 这种价值应该反映资产对组织业务运营的重要性，并以对业务的潜在影响程度表 现出来。例如，资产价值越大，由于泄露、修改、损害、不可用等安全事件对组 织业务的潜在影响就越大。基于组织业务需要的资产的识别与估价，是建立信息 安全体系，确定风险的重要一步。 资产的价值应当由资产的所有者和相关用户来确定，只有他们才最清楚资产 对组织业务的重要性，才能较准确地评估出资产的实际价值。为确保资产赋值时 的一致性和准确性，组织应建立一个资产价值评价尺度，以指导资产赋值。 在对资产赋予价值时，一方面要考虑资产购买成本及维护成本，另一方面主 要考虑当这种资产的机密性、完整性、可用性受到损害时，对业务运营的负面影 响程度。在信息安全管理中，并不是直接采用资产的账面价值，在运维中心风险 评估中采用以定性分级的方式建立资产的相对价值，以相对价值来作为确定重要 资产的依据和为这种资产的保护投入多大资源的依据。 5.1.15.1.1 资产分类资产分类 运维中心资产分类见下表： 大类大类小类小类名称名称 H010 大型机 H020 小型机 H030 PC 服务器 H040 PC 台式机 H050 PC 移动电脑 硬件类硬件类 H060 业务终端 15 大类大类小类小类名称名称 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 扫描仪 H330 投影机 H340 机架 16 大类大类小类小类名称名称 S010 核心业务应用系统 S020 辅助业务应用系统 S030 网络基础应用系统 S040 网络安全系统 S050 操作系统 S060 数据库 S070 中间件 S080 软件开发工具 S090 软件测试工具 系统服务类系统服务类 S100 其他系统或服务 I010 软件 I020 开发文档及源代码 I030 用户文档 I040 系统业务数据 I050 系统支撑数据 I060 密码数据 信息类信息类 I070 其他 F010 通讯服务 F020 系统运行 F030 系统维护 F040 软件开发 F050 软件维护 F060 安全保卫 F070 人力资源服务 F080 财务服务 F090 供电 F100 供暖 支撑服务类支撑服务类 F110 消防 17 大类大类小类小类名称名称 F120 照明 F130 空调 F140 咨询服务 F150 培训服务 F160 审计服务 R010 管理层人员 R020 网络管理人员 R030 系统管理人员 R040 安全管理人员 R050 软件开发人员 R060 软件测试人员 R070 通讯管理人员 R080 文档管理人员 R090 系统用户 R100 企业客户 R110 签约供应商 R120 第三方人员 人员类人员类 R130 临时人员 W010 公信力 W020 组织形象与声誉 W030 商标 W040 产品名称 无形资产类无形资产类 W050 知识产权 表 5-2 资产分类表 5.1.25.1.2 资产价值属性资产价值属性 除了机密性、完整性和可用性外，在运维中心风险评估中引入系统对业务的 重要程度、资产对系统的重要程度，资产花费等资产价值属性，各价值属性图示 如下： 18 系系统统对对业业务务的的重重要要程程度度 系系统统服服务务范范围围 业业务务对对系系统统的的依依赖赖程程度度 信信息息保保密密性性 信信息息完完整整性性 信信息息可可用用性性 资资 产产 信信息息 重重要要性性 资资产产对对业业 务务的的重重要要 程程度度 资资产产对对系系统统的的重重要要程程度度 资资产产业业 务务价价值值 花花费费 资资产产价价值值 图 5-2 资产价值属性 1. 系统服务范围：说明当前业务系统应用或服务的范围，评估人员可以人 工分析并选择系统服务范围值。 2. 业务对系统的依赖程度：用于衡量部门业务对当前业务系统的依赖程度， 评估人员可以人工分析并选择业务对系统的依赖程度值。 3. 系统对业务的重要程度：用于衡量业务系统对业务的重要性，其值由系 统服务范围和业务对系统的依赖程度确定。 4. 信息保密性：说明信息资产本身或硬件、系统服务类资产所包含信息的 保密性价值，评估人员可以人工分析并选择信息保密性值。 5. 信息完整性：说明信息资产本身或硬件、系统服务类资产所包含信息的 完整性价值，评估人员可以人工分析并选择信息完整性值。 6. 信息可用性：说明信息资产本身或硬件、系统服务类资产所包含信息的 可用性价值，评估人员可以人工分析并选择信息可用性值。 7. 资产信息重要性：用于衡量信息资产本身或硬件、系统服务类资产所包 含信息的信息价值，其值由信息保密性、信息完整性和信息可用性确定。 8. 资产对系统的重要程度：用于衡量硬件、系统服务类资产对业务系统的 可用性价值，评估人员可以人工分析并选择对系统的重要程度值。 9. 资产对业务的重要程度：用于衡量硬件、系统服务类资产对业务的重要 性，其值由系统对业务的重要程度和资产对系统的重要程度确定。 10.资产业务价值：用于衡量硬件、系统服务、人员及其它类资产对业务的 价值，对于人员及无形类资产，其值由对业务的重要程度确定，对于硬件、系统 服务类资产，其值由对业务的重要程度和资产信息重要性确定。 11.花费：用于衡量购买或恢复被破坏的资产所需要的花消，评估人员可以 19 人工分析并选择花费值。 12.资产价值：用于表示资产的重要性，其值由资产业务价值和花费确定。 不同类别资产赋值可能采用不同的价值属性。具体见下表： 资产类别资产类别 价值属性价值属性 硬件类系统服务类信息类支撑服务人员无形资产 系统服务范围 业务对系统的依赖程度 系统对业务的重要程度 保密性 完整性 可用性 资产 CIA 重要性 资产对系统的重要程度 资产对业务的重要程度 资产业务价值 花费 表 5-3 不同资产采用的价值属性 5.1.35.1.3 资产价值属性赋值标准资产价值属性赋值标准 运维中心风险评估使用的资产属性赋值标准见下表： 系统服务范围赋值 系统服务范围赋值系统服务范围赋值描述描述 1 运维中心内部。 2 面向开发基地。 3 面向整个公司内部。 4 面向整个公司内部及客户、政府、组织等。 表 5-4 系统服务范围赋值表 20 业务对系统的依赖程度赋值 业务对系统依赖程度业务对系统依赖程度 赋值赋值 描述描述 1 整个业务处理流程可以通过手工方式或其他方式完成， 而且这些替代方式对组织业务的开展没有或极少影响。 2 整个业务处理流程可以通过手工方式或其他方式完成， 但这些替代方式对组织业务的开展有较大的影响。 3 业务处理流程的部分环节可以通过手工方式或其他方式 替代完成, 这些替代方式对组织业务的开展有较大的影 响。 4 业务处理流程完全依赖信息系统，手工方式无法完成。 表 5-5 业务对系统的依赖程度赋值表 系统对业务的重要程度计算 系统重要程度权值（W）系统服务范围值+业务对系统依赖程度值 系统重要程度值T1（W） T1 是非线性函数，用于将计算出的权值 W 映射到 5 级，得到系统重要程度值， 见下表： 系统对业务重要程度赋值系统对业务重要程度赋值描述描述 1 W=2，3 2W=4 3W=5 4W=6 5 W=7，8 表 5-6 系统对业务的重要程度计算表 信息保密性赋值 信息保密性赋值信息保密性赋值描述描述 1 信息的未授权泄露对运维中心的业务以及利益基本 不会受到影响或损害极小。 2 信息的未授权泄露对运维中心的业务以及利益带来 21 信息保密性赋值信息保密性赋值描述描述 一定的损失或破坏。 3 信息的未授权泄露对运维中心的业务、利益以及整 个公司利益带来严重的损失或破坏。 4 信息的未授权泄露对运维中心的业务、利益以及整 个公司利益带来极其严重的损失或破坏。 5 信息的未授权泄露会对运维中心的业务、利益以及 整个公司利益带来灾难性的损失或破坏。 表 5-7 信息保密性赋值表 信息完整性赋值 信息完整性赋值信息完整性赋值描述描述 1 信息的未授权的修改或破坏对运维中心的业务以及利益 基本不会受到影响或损害极小。 2 信息的未授权的修改或破坏对运维中心的业务以及利益 带来一定的损失或破坏。 3 信息的未授权的修改或破坏对运维中心的业务、利益以 及整个公司利益带来严重的损失或破坏。 4 信息的未授权的修改或破坏会对运维中心的业务、利益 以及整个公司利益带来极其严重的损失或破坏。 5 信息的未授权的修改或破坏会对运维中心的业务、利益 以及整个公司利益带来灾难性的损失或破坏。 表 5-8 信息完整性赋值表 信息可用性赋值 信息可用性赋值信息可用性赋值描述描述 1 可用性价值可以忽略，合法使用者对信息及信息系统的 可用度在正常工作时间低于 25% 2 可用性价值较低，合法使用者对信息及信息系统的可用 度在正常工作时间达到 25%以上 3 可用性价值中等，合法使用者对信息及信息系统的可用 22 信息可用性赋值信息可用性赋值描述描述 度在正常工作时间达到 70%以上 4 可用性价值较高，合法使用者对信息及信息系统的可用 度达到每天 90%以上 5 可用性价值非常高，合法使用者对信息及信息系统的可 用度达到年度 99.9%以上 表 5-9 信息可用性赋值表 资产 CIA 重要性计算 资产 CIA 重要性值MAX（保密性值、完整性值、可用性值） 资产对系统的重要程度赋值 对系统的重要程度赋对系统的重要程度赋 值值 描述描述 1 资产出现问题对整个业务系统的可用性影响极小或没有 影响。 2 资产出现问题对整个业务系统的可用性有一定的影响。 3 资产出现问题对整个业务系统的可用性有较大的影响。 4 资产出现问题将导致整个业务系统丧失可用性。 表 5-10 资产对系统的重要程度赋值表 资产对业务的重要程度计算 资产对业务的重要程度权重(W)系统对业务的重要程度值资产对系统的 重要程度值 资产对业务的重要程度值T2（W） T2 是非线性函数，用于将计算出的权值 W 映射到 5 级，得到资产对业务重要 程度值，见下表： 资产对业务重要程度资产对业务重要程度 赋值赋值 描述描述 1 W=1，2 2 W=3，4，5 3 W=6，8，9 4 W=10，12 23 资产对业务重要程度资产对业务重要程度 赋值赋值 描述描述 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 低 出现的频率较小；或一般不太可能发生；或没有被 证实发生过。 1 很低 威胁几乎不可能发生，仅可能在非常罕见和例外的 情况下发生。 表 5-15 威胁赋值表 5.35.3脆弱性评估脆弱性评估 脆弱性评估也称为漏洞评估，是风险评估中重要内容。脆弱性是信息资产自 身存在的，它可以被威胁利用、引起资产或商业目标的损害。脆弱性包括物理环 境、组织、过程、人员、管理、配置、硬件、软件和信息等各种资产的弱点。 值得注意的是，脆弱性虽然是信息资产本身固有的，但它本身不会造成损失， 它只是一种条件或环境、可能导致被威胁利用而造成资产损失。所以如果没有相 应的威胁发生，单纯的脆弱性并不会对资产造成损害。那些没有安全威胁的脆弱 性可以不需要实施安全保护措施，但它们必须记录下来以确保当环境、条件有所 变化时能随之加以改变安全保护，需要注意的是不正确的、起不到应有作用的或 没有正确实施的安全保护措施本身就可能是一个安全脆弱性环节。 脆弱性评估将针对每一项需要保护的信息资产，找出每一种威胁所能利用的 脆弱性，并对脆弱性的严重程度进行评估，即对脆弱性被威胁利用的可能性进行 评估，最终为其赋值。在进行脆弱性评估时，提供的数据应该来自于这些资产的 拥有者或使用者，来自于相关业务领域的专家以及软硬件信息系统方面的专业人 员。脆弱性评估所采用的方法主要为：问卷调查、访谈、工具扫描、手动检查、 文档审查、渗透测试等。 在运维中心风险评估中采用问卷调查、小组访谈、工具扫描和人工检查等方 法。 28 脆弱性的识别以资产为核心，即根据每个资产分别识别其存在的弱点，然后 综合评价该资产的脆弱性。 脆弱性识别主要从技术和管理两个方面进行，技术脆弱性涉及物理层、网络 层、系统层、应用层等各个层面的安全问题。管理脆弱性又可分为技术管理和组 织管理两方面，前者与具体技术活动相关，后者与管理环境相关。 脆弱性识别内容如下表述： 类型类型 识别对象识别对象识别内容识别内容 物理环境 从机房场地、机房防火、机房供配电、机房防静电、 机房接地与防雷、电磁防护、通信线路的保护、机房 区域防护、机房设备管理等方面进行识别。 服务器（含 操作系统） 从物理保护、用户帐号、口令策略、资源共享、事件 审计、访问控制、新系统配置（初始化） 、注册表加固、 网络安全、系统管理等方面进行识别。 网络结构 从网络结构设计、边界保护、外部访问控制策略、内 部访问控制策略、网络设备安全配置等方面进行识别。 数据库 从补丁安装、鉴别机制、口令机制、访问控制、网络 和服务设置、备份恢复机制、审计机制等方面进行识 别。 技术脆 弱性 应用系统 审计机制、审计存储、访问控制策略、数据完整性、 通信、鉴别机制、密码保护等方面进行识别。 技术管理 物理和环境安全、通信与操作管理、访问控制、系统 开发与维护、业务连续性。管理脆 弱性 组织管理 安全策略、组织安全、资产分类与控制、人员安全、 符合性 表 5-16 弱点分类表 安全控制措施的使用将减少脆弱性，考虑对现有安全控制措施的确认，采用 等级方式对已识别的脆弱性的严重程度进行赋值。 脆弱性严重程度的等级划分为五级，分别代表资产脆弱性严重程度的高低。 29 等级数值越大，脆弱性严重程度越高。 运维中心风险评估对脆弱性采用以下赋值方法： 等级等级影响影响 技术技术 攻击角度攻击角度 管理管理防范角度防范角度 1(可 忽略) 如果被威 胁利用， 将对资产 造成的损 害可以忽 略。 技术方 面存在着低 等级缺陷， 从技术角度 很难被利用 对于攻击者来 说，该漏洞目前 还不能够被直接 或者间接利用， 或者利用的难度 极高 组织管理 中没有相关 的薄弱环节， 很难被利用 有规定， 严格审核、 记录、校 验 2(低)如果被威 胁利用， 将对资产 造成较小 损害。 技术方 面存在着低 等级缺陷， 从技术角度 难以被利用 对于攻击者来 说，该漏洞无法 被直接利用(需 要其他条件配合) 或者利用的难度 较高 组织管理 中没有相应 的薄弱环节， 难以被利用 有规定， 职责明确， 有专人负 责检查执 行落实情 况，有记 录 3(中)如果被威 胁利用， 将对资产 造成一般 损害。 技术方 面存在着一 般缺陷，从 技术角度可 以被利用 可以配合其他 条件被攻击者加 以直接利用，或 者该漏洞的利用 有一定的难度 组织管理 中没有明显 的薄弱环节， 可以被利用 有规定， 定期检查 落实，有 记录 4(高)如果被威 胁利用， 将对资产 造成重大 损害。 技术方 面存在着严 重的缺陷， 比较容易被 利用 一个特定漏洞， 可以配合其他条 件被攻击者加以 直接利用，或者 该漏洞的利用有 一定的难度 组织管理 中存在着薄 弱环节，比 较容易被利 用 有规 定执行 完全靠人 自觉 30 等级等级影响影响 技术技术 攻击角度攻击角度 管理管理防范角度防范角度 5(极 高) 如果被威 胁利用， 将对资产 造成完全 损害。 技术方 面存在着非 常严重的缺 陷，很容易 被利用 在没有任何保 护措施的情况下， 暴露于低安全级 别网络上 组织管理 中存在着明 显的薄弱环 节，并且很 容易被利用 无人负 责，无人 过问 表 5-17 弱点赋值表 5.45.4确定现有控制确定现有控制 在识别脆弱性的同时，评估人员应对已采取的安全措施的有效性进行确认。 安全措施的确认应评估其有效性，即是否真正地降低了系统的脆弱性，抵御了威 胁。对有效的安全措施继续保持，以避免不必要的工作和费用，防止安全措施的 重复实施。对确认为不适当的安全措施应核实是否应被取消或对其进行修正，或 用更合适的安全措施替代。 安全措施可以分为预防性安全措施和保护性安全措施两种。预防性安全措施 可以降低威胁利用脆弱性导致安全事件发生的可能性，如入侵检测系统；保护性 安全措施可以减少因安全事件发生后对组织或系统造成的影响，如业务持续性计 划。 已有安全措施确认与脆弱性识别存在一定的联系。一般来说，安全措施的使 用将减少系统技术或管理上的弱点，但安全措施确认并不需要和脆弱性识别过程 那样具体到每个资产、组件的弱点，而是一类具体措施的集合，为风险处理计划 的制定提供依据和参考。 5.55.5风险评估风险评估 完成资产评估、威胁评估、脆弱性评估后，并考虑已有安全措施的情况下， 利用恰当的方法与工具确定威胁利用资产脆弱性发生安全事件的可能性，并结合 资产的安全属性受到破坏后的影响得出信息资产的风险。 5.5.15.5.1 风险值计算风险值计算 在完成了资产识别、威胁识别、脆弱性识别，以及对已有安全措施确认后， 将采用适当的方法与工具确定威胁利用脆弱性导致安全事件发生的可能性。综合 安全事件所作用的资产价值及脆弱性的严重程度，判断安全事件造成的损失对组 31 织的影响，即安全风险。使用本方法需要首先确定信息资产、威胁和脆弱性的赋 值，要完成这些赋值，需要管理人员、技术人员的配合。 运维中心风险评估中风险值计算方式如下： 风险值(RW)资产价值威胁可能性值脆弱性严重程度值 5.5.25.5.2 风险等级划分风险等级划分 确定风险数值的大小不是风险评估的最终目的，重要的是明确不同威胁对资 产所产生的风险的相对值，即要确定不同风险的优先次序或等级，对于风险级别 高的资产应被优先分配资源进行保护。 风险等级在运维中心风险评估中采用分值计算表示。分值越大，风险越高。 见下表。 风险风险 等级等级 标标 识识 风险值范风险值范 围围 描述描述 建议处建议处 置方式置方式 1 很 低 RW5 发生安全事件的可能性极小，即使发生对系 统或组织也基本没影响。 A-接受 2 低 6RW1 0 发生安全事件的可能性较小，安全事件发生 后使系统受到的破坏较小或使组织利益受到 的损失较少。 A-接受 3 中 11RW 30 发生安全事件的可能性一般，安全事件发生 后将使系统受到一定的破坏或使组织利益受 到一定的损失。 B-降低 4 高 31RW 40 发生安全事件的可能性较大，安全事件发生 后将使系统受到较大的破坏或使组织利益受 到较多的损失。 B-降低 5 极 高 41RW 发生安全事件的可能性很大，安全事件发生 后将使系统受到很大的破坏或使组织利益受 到很多的损失。 B-降低 表 5-20 风险等级描述表 5.5.35.5.3 风险评估结果纪录风险评估结果纪录 风险评估的过程需要形成相关的文件及记录，文档管理考虑以下控制： 32 1. 文件发布前得到批准，以确保文件是充分的； 2. 必要时对文件进行评审、更新并再次批准； 3. 确保文件的更改和现行修订状态得到识别； 4. 确保在使用时，可获得有关版本的适用文件； 5. 确保文件保持清晰、易于识别； 6. 确保外来文件得到识别； 7. 确保文件的分发得到适当的控制； 8. 防止作废文件的非预期使用，若因任何目的需保留作废文件时，应对这 些文件进行适当的标识。 对于风险评估过程中形成的记录，还应规定记录的标识、储存、保护、检索、 保存期限以及处置所需的控制。记录是否需要以及详略程度由管理过程来决定。 风险评估过程应形成下列文件： 1. 风险评估过程计划：该计划中应阐述风险评估的范围、目标、组织机构、 评估过程所需资源、形成的评估结果。 2. 风险评估程序：程序中应明确评估的目的、职责、过程、相关的文件要 求，并且准备评估阶段需要的表格，如信息资产识别与评估表。 3. 信息资产识别清单：根据在风险评估程序文件中规定的资产分类方法进 行资产的识别，并形成信息资产识别清单，清单中应明确各资产的负责人/部门。 4. 威胁参考列表：应根据评估对象、环境等因素，形成威胁的分类方法及 具体的威胁列表，为风险评估提供支持。 5. 脆弱性参考列表：应针对不同分类的评估对象自身的弱点，形成脆弱性 参考列表，为风险评估提供支持。 6. 风险评估记录：根据组织的风险评估程序文件，记录对重要信息资产的 风险评估过程，包括脆弱性、威胁的赋值，已有安全控制措施的确认，风险值的 计算与等级划分。 7. 风险评估报告：风险评估报告应对整个风险评估过程进行总结，说明组 织的风险状况及残余风险状况，通过管理层的评审，确定评估后的风险状况满足 业务发展及其他相关方的要求。 上述文件均应由运维中心管理层批准。 33 6 6 风险管理过程风险管理过程 通过风险评估对风险进行识别与估价后，引入合适的控制措施，对风险实施 管理，把风险降低到运维中心可以接受的程度，对风险的管理过程如下图所示： 安安全全控控制制措措施施的的识识别别与与选选择择 接接受受风风险险 降降低低风风险险 风风险险评评估估过过程程 图 6-1 风险管理过程 6.16.1安全控制的识别与选择安全控制的识别与选择 选择安全控制的另一个重要方面就是费用因素，如果实施与维护这些控制的 费用比资产遭受威胁所造成的损失的预期值还要高，那么所选择的控制是不适合 的；如果控制费用比组织计划的安全预算要高，也是不适当的。但如果由于预算 不足使控制的数据与质量下降，就会使系统产生不必要的风险，对此要特别注意。 安全控制预算应该作为一个限制性的因素加以考虑。同样，也可以对现有的控制 进行费用比较，如果现有控制不是充分有效，就要考虑取消或改进。 根据 ISO27001 的要求，运维中心在以下领域引入控制措施： 1. 安全政策 2. 信息安全的组织 3. 资产管理 4. 人力资源安全 5. 物理与环境安全 6. 通讯与操作管理 7. 访问控制 8. 信息系统获取、开发及维护 34 9. 信息安全事故管理 10.业务连续性管理 11.符合性 控制的选择要考虑非技术性的控制与技术性的控制之间的平衡，两种控制之 间是互相支持与互补的。运营管理包括物理、人员、行政管理等方面安全的控制。 当选择安全控制措施进行实施时的考虑因素： 1. 控制的易用性 2. 用户的透明度 3. 为用户提供帮助，以发挥他们的绩效 4. 控制的相对强度 5. 实现的功能类型预防、威