灾难恢复中的风险分析（下）


1.3 风险分析的过程

为了能全面、有效的分析单位信息资产所存在的风险，又没有安全因素的遗漏，我们有必要按照一定的流程和步骤进行风险分析。我们在风险分析时必须注意的是用于灾难恢复建设的风险分析过程不等同于常规的信息安全风险评估，它主要是从与灾难恢复相关的方面来进行分析的，比如数据中心基础设施、用户相应的管理制度、应急计划等方面来考虑。


1.3.1. 风险分析的路线图

对于要建立灾难恢复系统的单位来说，如何进行风险分析呢？我们可以按照《信息安全风险评估指南》中所定义的路线图来进行分析，如下：

灾难恢复风险分析的路线图


1.3.2. 确定风险分析范围

在风险分析项目启动后，应清晰地确定风险分析的范围。单位中存在着业务系统、财务系统、邮件系统等各种系统，风险评估者需要确定对哪些系统进行分析，或是对IT系统分析还是需要对非IT系统及部门进行分析；对于一个指定要分析的系统，需要明确对哪些部分进行分析，比如对于系统所处的基础设施分析还是分析系统本身具有哪些补丁的缺损，这些都需要风险分析者和用户协商一致。

在整个流程期间，应经常在全体风险承担者会议上讨论并了解范围，在分析团队成员和用户之间达成一致，避免相关人员理解不一致而引起的障碍，便于项目的健康进展而不致偏离方向。最重要的是风险分析范围必须得到用户高层的认同和批准。


1.3.3. 确定风险分析目标

风险分析阶段应先明确分析的目标，即风险分析所要实现的功能，同时设置合理的期望值，为风险分析的过程提供导向。一般说来，风险分析的目标有如下几种：


1.3.4. 确定风险分析团队

为了完成风险分析的工作，有必要组建一个分析实施团队，团队成员中应包括资深的咨询分析顾问，单位信息系统相关人员及各业务部门精通业务的骨干等。用户IT人员和业务人员的参与可以便于分析团队熟悉单位架构，清楚单位业务流程，了解单位的IT系统等，用户相关人员的参与也是公司高层支持风险分析的一个实际措施。


1.3.5. 确定风险分析方法

从上文可以得知风险分析的方法，那么在项目开展前，分析团队应明确采用哪种或哪几种风险分析方法。选择方法时要结合当前风险分析的目标、时间、资源和效果等方面来考虑。


1.3.6. 获取用户高层的支持

为了确保项目的顺利进展，成功消除项目进展过程中可能受到的干扰和障碍，风险分析团队应在实施之前和用户管理层进行有效的交流沟通，确保管理层理解评估的重要性、他们的角色，并向管理层明确单位可接受的风险水平和等级、提交项目实施的范围、目标、方法、日程安排等，确保获得管理层对此的理解和支持。


1.3.7. 资产分析

资产是具有价值的信息或资源，是单位风险分析所要保护的对象。它能够以多种形式存在，有无形的、有形的，有硬件、软件，有文档、代码，也有服务、形象等。机密性、完整性和可用性是评价资产的三个安全属性。

通过准备阶段的工作，分析团队可以列出一份风险分析的资产清单，详细记录分析范围和边界内所有相关的资产，要竭力防止遗漏。实际操作时，单位可以根据业务流程来分析资产，例如要分析财务系统，那么就需要分析财务系统本身的服务器、系统、财务数据，以及和财务系统相连的网络，打印机等等。一般说来，单位常见的资产包括如下几种：

经过分析，得到单位相关的资产清单后，有必要对资产进行分类以区分不同资产的重要性，为下面制定灾难备份策略提供依据。为确保资产赋值时的一致性和准确性，团队应建立一个资产价值评价尺度，以指导资产赋值，使分析结果更具有客观性。下面我们分别对资产的机密性、完整性和可用性进行赋值，并在此基础上得到一个综合的资产价值。因为对资产的这三个属性的赋值比较困难，所以一般采用定性的方法。

单位应根据自身的情况，选择对资产机密性、完整性和可用性最为重要的属性的赋值等级作为资产的最终赋值结果，或者根据资产机密性、完整性和可用性的不同重要程度对其赋值进行加权计算而得到资产的最终赋值。


1.3.8. 威胁识别

造成威胁的因素可分为人为因素和环境因素。根据威胁的动机，人为因素又可分为恶意和无意两种，环境因素包括自然界不可抗的因素和其它物理因素。

识别信息资产面临的威胁后，还应该评估威胁发生的可能性。风险分析团队应该根据经验或者相关的统计数据来判断威胁发生的频率或概率。通常来讲，威胁源的能力和动机用“高”、“中”、“低”这三级来衡量。


1.3.9. 脆弱性识别

脆弱性识别也称为弱点识别，弱点是信息资产本身存在的，如果没有相应的威胁发生，单纯的弱点本身不会对资产造成损害。所以，单位应该针对每一项需要保护的信息资产，找到可被威胁利用的弱点。脆弱性识别主要以单位资产为核心，从技术和管理两个方面进行,所采用的方法主要有：问卷调查、工具检测、人工核查、文档查阅、渗透性测试等。

脆弱性识别之后，可以根据它们对资产损害程度、技术实现的难易程度、弱点流行程度，可采用等级方式对已识别的脆弱性的严重程度进行赋值。


1.3.10. 己有安全措施的确认

对于己经采取一定安全措施的单位来说，有必要对己采取的安全措施的有效性进行确认，继续保持有效的安全措施，以避免不必要的工作和费用，防止安全措施的重复实施。对于确认为不适当的安全措施应核实并判断是否应被取消，或者用更合适的安全措施替代。


1.3.11. 风险计算

经过前面的风险分析步骤，分析团队己经对单位的资产、威胁、脆弱性进行了识别及赋值，下面考虑如何计算风险。对于如何计算风险，不同的标准制定了不同的计算方法，我们可以参照《信息安全分析评估指南》的风险计算原理，公式如下：

风险值=R（A，T，V）= R(L(T，V)，F(Ia，Va ))

其中，R 表示安全风险计算函数；A 表示资产，T 表示威胁，V 表示脆弱性，Ia 表示安全事件所作用的资产重要程度，Va

表示脆弱性严重程度，L 表示威胁利用资产的脆弱性导致安全事件发生的可能性，F 表示安全事件发生后产生的损失。

根据风险计算得到的风险值，单位应制定相应级别的防范措施以有效削减或降低风险。


1.3.12. 残余风险的确认

经过分析确定所存在的风险，且采取了一定的安全措施削减风险后，并不能绝对消除风险，仍然可能存在的风险称之为残余风险。有些风险虽然存在，但是外来威胁利用它并对单位造成损失的可能性极小或是成本极大，所以这类风险可以接受；另外有一些风险，可能是安全措施不当或无效，需要继续控制。因此，单位的风险通常不可能完全消除。针对不可接受的风险，按照灾难恢复资源的成本与风险可能造成的损失之间取得平衡的原则（“成本风险平衡原则”），评估风险防范的安全措施的可行性和效率，确定风险防范的安全措施。风险分析团队需要对这些残余风险进行记录，并经用户确认。

单位要对这些残余风险进行有效的监控并定期评审，应充分考虑残余风险导致的灾难事件发生在最不利的时间和地点，可能对单位造成较大损失，以及影响范围的广泛性。

1.3.13. 风险分析文件记录

风险分析文件包括在整个风险分析过程中产生的过程文档和结果文档，对于这些风险分析过程中形成的各相关文件，应规定其标识、储存、保护、检索、保存期限以及处置所需的控制等，以备后来的风险消减规避或为再次分析提供相关背景资料。


3.4 风险分析的结论要求

风险分析报告的主要内容应包括：


风险分析完成后，风险分析团队需要向用户提交一份正式的风险分析报告，报告内容包括对用户风险分析的概要、结论及建议等，报告还包括每一次调查及会见的记录和收集资料的汇总。风险分析报告的主要内容包括：


风险分析是业务影响分析和制定灾难恢复策略和预案的前期准备条件，以便在策略制定和预案制订时更具有针对性，考虑因素更为全面，规划的实施成本会更合理，从而有效的保护投资，获得更大的投资回报率。


3.5 风险分析有关标准和规范

经过多年的研究，国内外在风险管理、风险分析领域得到了长足的发展，制定了一些相关的标准和规范。国际上的文献主要有：BS7799&ISO17799、ISO13335、AS/NZS 4360、NIST SP 800-26&800-30 等；九十年代后期开始，国内也参考国际标准制定了一些符合中国实际的有关标准，主要有：GB/T 18336《信息技术安全性评估准则》、GB 17859-1999 《计算机信息系统安全保护等级划分准则》、国家信息安全测评认证中心《信息系统安全保障等级评估准则》、公安部《信息系统安全等级保护评估指南》、国务院信息化工作办公室《信息安全风险评估指南》等，这些标准和规范是我们进行信息系统灾难恢复需求分析所必须遵循的规定和向导。