风险评估过程中的风险

    [阴 March 3, 2009 09:43 | by !4p47hy ]
出处:比特网

刚开始看到这个题目可能可能很多人都会产生不解,究竟这个风险评估过程中的“风险”指的是什么呢?是评估出来的风险结果还是评估过程中遇到的实施风险呢?所以首先我要解释一下下面到要谈的究竟是什么内容。
  做信息安全的人都知道风险评估,而我在这里不谈那些技术评估、应用评估、流程评估等评估过程中的问题,只谈我们作为乙方在做咨询项目中通常都要做到的信息资产的风险评估,而这个风险评估过程中的“风险”也是指的在评估过程中遇到的实施风险。在下面的文章中我不谈如何做信息资产风险评估的方法,也不谈什么方法好,什么方法不好,因为风险评估工作各家有各家的做法,各人有个人的理解,不同的项目、不同的客户也存在不同的情况,所以针对具体情况选择合适的风险评估方法,化解在评估过程中可能遇到的问题和风险才是我这次要谈的内容。

1、风险评估的第一的误区

  同一套方法,这在很多人看来是没什么奇怪的,我们在项目中做风险评估最关注的几个问题是,一方面,要尽量有效全面的评估出风险,并根据风险制定有效的控制,这是从评估的实用性和为客户带来效果的角度(即项目质量)来说的;另一方面我们还要保证项目的进度,常做评估的人都知道风险评估在资产识别阶段不能做的太细,避免做成CMDB,就是为了控制项目的进度。

  每家公司或每个人可能都会有一套做信息资产风险评估的最佳放法论,这套方法论通常是多年实践积累、改进而来或从哪里直接借鉴过来的,而通常去给客户做风险的评估的时候也都是拿着这套所谓的最佳实践去做的(尤其是新手居多)。但这就忽略了一个问题,每个客户的实际情况是不同的,项目范围也是不同的,其信息资产的分布和管理方式、以及客户实际的配合力度以及客户是否需要通过认证的情况都是不一样的。在实际实施过程中可能会遇到,客户原本的资产管理就很混乱,缺少集中或统一了解和管理资产的人,人员对资产的熟悉情况太分散,评估的结果是否要与等保和安全域结合,客户是否有充分的人员和时间配合你工作等等情况。

  因此如果不能够很好的根据客户选择评估的方法有时是会影响项目实施的。所以我们需要根据客户的具体情况适当调整我们评估的方法和实施方式,比如,我们是选择按部门划分评估,还是按资产分类评估,还是按系统分组来评估,资产分类的粒度要到什么程度。也就是说我们可能同时要掌握不只一套风险评估的操作方法,或者说同样的方法不能一成不变的应用到每个项目。当然如果大家不接受我的这个观点恐怕看接下来的内容也意义不大了。

2、前期沟通的重要性

  这个问题关系到项目售前和项目经理之间的交流,以及最初项目计划的制定工作阶段。

  我们都知道做风险评估的首要工作就是要明确风险评估的范围,即不能做小了(不全面,反应不了整体情况),也不能做大了(做了不该做的,影响实施进度)。因此在项目洽谈的初期涉及到制定项目计划的时候就要考虑到这个问题了。首先应当与客户沟通清楚究竟哪些人员、部门或哪些公司要做评估,同时要更详细的了解或预估出在这个范围内可能个会涉及到多少的信息资产,大约需要多大的工作量和多少工时,然后再制定实施计划。千万不能只是初略的约定了哪个哪个部门或哪个哪个公司,就根据自己以往的经验制定计划了,不同客户的人员数量和资产范围那都是不一样的,切戒范经验主义错误。如果等到人员进场之后再去和客户确定这个问题,这时候一旦实际情况超出预计,你的实施计划已经制定好了,再去修改改就比较麻烦了。

  所以前期的沟通交流一定要做的细致,千万不能马虎,售前与项目经理之间也要做好沟通和交流,尽量不要一味的为了打单子而忽略的后期实施过程中的风险。当然这个问题不单针对风险评估,所有与项目实施相关的工作在前期都应做好工作量的预估。

3、注意与其他标准的结合

  有的时候在某些项目中我们做完信息资产的风险评估之后可能还要做等级保护实施、信息安全规划或安全域划分等工作,这时候在选择或制定风险评估方法就要注意与这些工作的对应或关联。以结合等级保护或安全域为例,通常这种情况我们使用以资产类别进行划分资产,按照一类资产进行风险评估的方法就不是很适用,因问它不能很好的反映出系统层面的重要性。这时我们可以考虑使用按系统进行资产分组,对系统资产组进行风险评估的方法,这样的操作也能为我们后期进行等级保护或安全域的划分提供帮助。

  但在采用这种按系统评估的方法时需要注意一些问题。1、系统资产组价值与等保系统级别之间的对应关系,比如我们资产价值打分从1-5或1-3,那么如何对应到等级保护的1-4级别,可能就需要做一些映射关系。2、由于按系统评估评估的方法中对资产的识别粒度相对较细,因此切忌不要陷入CMDB的风险中,只要把系统相关的每个资产需要参与评估的信息识别出来就可以了,千万不要搞的太细了,把什么IP地址或系统间访问关系都搞出来了。(当然不是说这些东西没有用,如果后期做安全域划分还是有用的)但一定牢记根据项目的要求调整评估的方法,否则将影响项目进度。

4、分值与精确度的设计

  对于分值和精确度的选择我想有经验的顾问都有自己的看法,我这里的建议主要希望为刚接触风险评估的人提供一些帮助。

  现在主流的风险评估方法都会不同程度的使用数字打分的方式,有1-3的,也有1-5的,不管怎么打分其目的都是为了区分出资产价值的重要程度,明确资产风险的重要性,所以只要你的方法论合理,1-3还是1-5都没有什么区别,我认为都可以,只是1-3分级较粗可能更适合资产少、规模较小的客户,而1-5分级较细,适合资产多、规模较大的客户。

  当我们做完资产CIA打分和风险影响、概率打分之后通常都会使用公式计算出资产的价值或风险值,这里我要说明一点的就是对于这个计算出来的分值我们应当尽量保留1位小数(个人感觉保留2位用处不是很大),由于资产数量众多时,保留整数的分值可能会出现许多同分的情况,为了便于我们后期的分析和整理工作,建议最好先保留1位小数这样重复的概率会降低很多,有利于我们对于资产和风险排序,也让结果变得更加精细。

5、客户规模与评估方法的选择

  我们公司现在常用的风险评估方法主要有2种,一种是根据不同的部门,按资产分类进行识别,在资产类别层面进行风险评估;另一种是按系统或资产分组的方式划分,对资产组(或系统)进行分类识别,然后针对资产组(或系统)层面进行风险评估。这2种方法可以说是各有利弊。

  通过在多个项目中分别使用这2种不同的评估方法,我个人感觉第一种方法操作起来相对简单,实施过程较快,而且客户易于掌握和理解,花费时间较短,但最后评估出来的结果实用性较差,需要进行更加细致的风险汇总、归纳和风险分析。第二种方法操作相对复杂,对顾问和客户工作量大要求较大,实施起来较慢,而且客户较难快速掌握,但能够为后期工作提供更好的支撑和输入,同时评估的结果可用性较强。

  基于以上的区别在对待不同规模的客户时,根据项目的具体时间要求,我们就需要选择不同的方法,在项目计划时间相对紧张且客户资产数量庞大、系统数目众多的时候可以尽量选取第一种方法,相反则选择第二种方法。

6、认证与不认证客户的区别

  这里我把是否通过ISO27001认证客户的拿出来做比较主要是因为需要通过认证的客户在做风险评估的时候需要考虑的问题更多,而且评估结果需要做的更仔细一些,当然不是说不过认证的我们就糊弄了,不过认证的同样要做好的,只是在认证审核的过程中对评估结果的要求有些内容在实际中用处不是很大,实施过程中可以尽量不花费太多精力在这些工作上面。

  这里面的一个最常见区别的就是对于残余风险控制的处置识别工作,如果是不需要通过认证的客户那么这部分工作可以双方协商的情况下决定是客户日后自己做还是顾问指导客户来做,因为落实风险控制措施有时需要经过领导的审批、参与或者组织讨论,因此需要的时间可能会较多。但对于需要通过认证的客户那就一定要做完,因为这个在审核的时候时比较重要的审核内容之一,所以对于残余风险的控制措施制定,残余风险的分值预估甚至控制实施的有效程度等工作都需要在认证之前完成。

  另一个问题就是客户的配合力度问题,我们通常的做法是在做风险评估前从每个部门找出一个人全程参与我们的评估工作,但有时客户方的协调力度不够或其他原因会导致没有各部门接口人,这种情况对于不过认证的客户来说还好办,例如,经过双方沟通可以由顾问待做,由客户确认,或客户部分参与来做。但如果是需要过认证的客户就一定要强烈建议客户安排指定的接口人参与到风险评估工作的整个过程中来,因为在接受审核的过程中,这些人员也可能会接受审核公司的询问,如果他们不清楚风险评估的具体工作流程和理论方法,是会影响到审核结果的。

最后

  可能很多人在看完这篇文章之后会说“怎么写的乱糟糟的啊”,其实以上的内容都是我在项目实施过程中遇到的问题和想到的一些应对方法,都是有感而发,想到什么就写些什么,所以没有太考虑前后之间的逻辑问题,大家可以有选择的看看,如果能为大家在日后做风险评估的过程中提供一些帮助的话那就再好不过了。当然在实际的项目实施过程中可能遇到的问题也不只我上面提到的这些,例如,对于人员类、服务类、无形类资产的识别、赋值和评估等其他内容,在实施的时候也存在许多难点,尤其是新手也非常关心。但我这里只是把我现在的一些感受和想法写出来罢了,仅供大家参考。
InfoSecurity | Comments(0) | Trackbacks(0) | Reads(7540)
Add a comment
Emots
emotemotemotemotemot
emotemotemotemotemot
emotemotemotemotemot
emotemotemotemotemot
emotemotemotemotemot
Enable HTML
Enable UBB
Enable Emots
Hidden
Nickname   Password   Optional
Site URI   Email   [Register]
               

Security code Case insensitive