为进一步提升信息科技风险管理水平,通过信息化手段规范执行信息科技风险的监测、检查、评估、处置和报告等工作,开展对信息科技风险管理体系中现有流程进行评估和优化,同时对现有信息科技风险管理系统进行优化,进一步提升信息科技风险管理水平和成熟度。
目标
依据银行客户信息科技风险管理制度和规范、监管机构要求、内部审计要求、国内外最佳实践和同行业的先进经验等要求收集、设计信息科技风险管理系统的需求,并执行已开发需求的系统功能测试。信息科技风险管理系统需求涵盖信息科技风险识别、风险检查、风险评估、风险处置、风险监测、风险报告、公文处理、突发事件处理、制度管理、报表管理等领域。
范围
工作的范围包括:信息科技风险管理体系评估、信息科技风险管理系统的设计和测试。
思路
统一的监管合规
目前国内很多银行在IT风险管理合规方面的工作比较单一化,单纯从银监会的《指引》要求出发去考虑问题,而忽略了国家层面、人民银行等其他相关的监管部门的要求,导致了这些银行在IT风险管理体系不能很好地与等级保护等要求相融合。客户需要综合这些标准规范的要求,以银监会《指引》为主,一次性识别出自身与众多监管部门的主要要求中的差距,来进行全面的改进。
风险管理方法论
商业银行的信息安全风险管理是一件异常复杂的事情,如何识别、分析、处理风险,如何组织这项活动,组织规模越大,业务越依赖信息系统,情况就越复杂。根据ISO/IEC 27005,从管理标准及理论方面,将信息安全风险管理划分为如下几个阶段:
-
风险识别;
-
风险分析;
-
风险处置;
-
风险跟踪;
-
风险管理全生命周期的沟通与文档化。
其中,风险识别、风险分析、风险处置、风险跟踪是四个明确的任务阶段,而风险管理全生命周期的沟通与文档化贯穿整个风险管理的各个阶段。
具体落实到可操作层面,可以将风险管理做如下展示:风险管理分为范畴确定、风险评估、风险处置、以及最终对识别的所有风险的接受监控几个过程;整个过程中,针对风险的沟通和监视评审贯穿整个风险管理的全过程。
风险管理过程示意图
风险识别
风险识别的目的是确定可能发生什么将导致潜在的损失, 并且洞察可能发生的损失将怎样发生、在哪里发生、为什么发生。
-
资产识别
资产是对组织有价值的任何东西,因此需要加以保护。资产识别应该在适合的细节层面进行,为风险评估提供充分的信息。资产识别的细节层面将影响风险评估中所收集的信息总量。细节层面可以在后续的信息安全评估循环中优化。应该为每一资产所有者安排职责和责任,资产所有者可能并不拥有资产的所有权,但承担资产的产生、开发、维护、使用以及合适的安全保护的责任。资产所有者通常是确定资产对组织价值的最合适人选。
-
威胁识别
威胁对如信息、过程、系统等资产构成潜在损害,并由此给组织带来损害。威胁可能是自然的或人为的,可能是意外或故意的。意外的或故意的威胁都应该得到识别。威胁可能来自组织内部和外部。应该整体并按类型(如非授权行为、物理损坏、技术失效)识别威胁,从而已识别的通用类别中的单个威胁得到识别。
有些威胁可能影响多个资产。在这种情形,因受影响的资产不同,威胁可能造成不同的影响。
可以从资产所有者或使用者、人力资源员工、设备管理者、信息安全专员、物理安全专家、法律部门以及包括法律机构、气象部门、保险和政府机构等获得识别威胁和估算发生可能性所需的输入。在处理威胁时,必须考虑环境和文化因素。 当前进行的评估,应该考虑从事件得到的内部经验和过去进行的威胁评估。在适当时,参考其他的威胁清单(可能是针对某个组织或业务)以完善通用威胁清单。可以从行业机构、政府部门、法律机构和保险单位获得威胁清单和统计资料。在使用威胁清单或前期的威胁评估成果时,应该注意到的一点是,相关威胁是持续变化的,特别当业务环境或信息系统发生变化时。
-
脆弱性识别
脆弱性的存在本身不会形成损害,它需要被某个威胁所利用。如果脆弱性没有对应的威胁,则可以不需要实施控制措施,但应该注意并监视所发生的变化。应该注意到控制措施实施的不合理、控制措施故障或控制措施的错误使用本身也是一个脆弱点。控制措施因其运行的环境,可能有效或无效。相反,一个威胁如果没有对应的脆弱点,也不会导致风险的发生。 脆弱点可能与资产的使用方式、目的等属性有关,而不论资产购买和构建时的意图。需要考虑不同来源的脆弱点,内在的或外来的。
可以从以下领域识别脆弱点: 组织架构、过程和程序、管理惯例、人员、物理环境、信息系统配置、硬件、软件或通讯设备、对外部的依赖。
-
已有控制措施
应该识别现有控制措施,以避免不必要的工作和成本,如重复的控制措施。另外,在识别现有控制措施时,应该进行检查以确保控制措施在有效工作。如果控制措施没有按预期进行工作,将会形成脆弱点。应该关注已选择的控制措施(或策略)的运行失效,并因此需要补充控制措施以有效处理风险。
现有或计划的控制措施可能被识别为无效的、不充分的或不合理的。应该检查不充分或不合理的控制措施,以确定是否应该取消、由其他更有效的控制措施替代或继续保持(如,因为成本控制因素)。
风险分析
风险分析根据资产的重要性、已知脆弱点的范围以及以前与组织相关的事件,而进行到不同的具体深度。估算办法根据条件,可以是定性的、定量的或者是两者的组合。实际上,通常首先采用定性估算以获得一般性的风险级别指示和发现重大风险。随后可能需要对重大风险进行更明确的或定量分析,因为通常定性分析比定量分析要简单,而且花费要少。
分析的形式应该与作为确定范畴的一部分而制定的风险估算准则相一致。估算办法更具体的内容描述如下:
1、定性估算
定性估算采用尺度分级属性(如低、中、高)来描述潜在后果的严重性和潜在后果发生的可能性。定性估算的优点是易于所有相关人员的理解,同时其弱点是尺度选择对主观判断的依赖。
可以对尺度进行修订或调整,以适应当时的情况,并为不同的风险采用不同的描述。定性分析可以用于:
作为最初的筛选活动,以识别需要进一步具体分析的风险
当定性分析对决策来说是合适时
当量化数据不足以进行定量估算时
定量分析应该使用可用的真实的信息和数据。
2、定量估算
定量估算通过不同来源的数据,使用数字化的尺度来描述后果和可能性(而不是定性评估中所使用的描述性尺度)。分析的质量依赖于量化数字的准确性和完整性,以及所使用模型的有效性。在很多情况下,定量估算使用历史的事件数据,优势是其直接与信息安全目标和组织所关心的问题相关。不足是缺乏新的风险或信息安全弱点的数据。当无法获得真实和可审计数据时,将显示定量估算的不足,因为这将导致风险评估准确性和价值的假象。
后果和可能性的表达方式,以及其组合形成的风险等级的表达方式,将随着风险的类型和风险评估输出的使用目的不同而变化。在进行有效分析和沟通时,应该考虑后果和可能性的不确定性和可变性。
将风险分析结果根据其风险值大小,在风险矩阵中做分布描述。如上图所示:从风险的发生频率及风险影响后果两个坐标形成风险矩阵,图中绿色部分为风险发生频率和后果都较小的低风险;黄色部分为风险发生频率和后果都适中的中等风险;红色部分为风险发生频率和后果都较大的高风险。
通过上图的分布实例,可以很快梳理排列出风险值,为后续的风险处置提供依据:即首先处置高风险、对部分低风险可以暂时接受。
风险处置
风险处置有四个选项:风险降低,风险接受,风险规避和风险转移。
-
风险规避
风险规避是组织对超出风险承受度的风险,通过放弃或者停止与该风险相关的业务活动以避免和减轻损失的策略。
规避方式:比如,在没有足够安全保障的信息系统中,不处理特别敏感的信息,从而防止敏感信息的泄漏。再如,对于只处理内部业务的信息系统,不使用互联网,从而避免外部的有害入侵和不良攻击。
-
风险降低
风险降低是组织在权衡成本效益之后,准备采取适当的控制措施降低风险或者减轻损失,将风险控制在风险承受度之内的策略。
风险降低是风险控制措施中最常使用的方式。风险降低主要从降低风险发生可能性(频率)以及减少事件影响后果两个方面进行。如下图所示:通过降低可能性以及影响,都可以将原来红色部分的高风险降低为绿色部分的低风险。
降低风险控制策略示意图
通过对面临风险的资产采取保护措施来降低风险。保护措施可以从构成风险的五个方面(即威胁源、威胁行为、脆弱性、资产和影响)来降低风险。比如,采用法律及行政手段制裁计算机犯罪(包括窃取机密信息,攻击关键的信息系统基础设施,传播病毒、不健康信息和垃圾邮件等),发挥法律的威慑作用,从而有效遏制威胁源的动机;采取身份认证措施,从而抵制身份假冒这种威胁行为的能力;及时给系统打补丁(特别是针对安全漏洞的补丁),关闭无用的网络服务端口,从而减少系统的脆弱性,降低被利用的可能性;采用各种防护措施,建立资产的安全域,从而保证资产不受侵犯,其价值得到保持;采取容灾备份、应急响应和业务连续计划等措施,从而减少安全事件造成的影响程度。
-
风险接受
风险接受是组织对风险承受度之内的风险,在权衡成本效益之后,不准备采取控制措施降低风险或者减轻损失的策略。
接受风险是选择对风险不采取进一步的处理措施,接受风险可能带来的结果。采取不对风险进行处理的前提是:确定了信息系统的风险等级,评估了风险发生的可能性以及带来的潜在破坏,分析了使用每种处理措施的可行性,并进行了较全面的成本效益分析,认定某些功能、服务、信息或资产不需要进一步保护。
-
风险转移
风险转移是组织准备借助他人力量,采取业务分包、购买保险等方式和适当的控制措施,将风险控制在风险承受度之内的策略。
转移方式:比如,在本机构不具备足够的安全保障的技术能力时,将信息系统的技术体系(即信息载体部分)外包给满足安全保障要求的第三方机构,从而避免技术风险。再如,通过给昂贵的设备上保险,将设备损失的风险转移给保险我行,从而降低资产价值的损失。
风险跟踪
风险跟踪的目的主要是针对接受的风险以及采用了风险处置后的风险进行情况跟踪以及有效性的验证,保证风险变化情况能够得到有效掌控以及对于风险处置效果的监督和审核。
跟踪实施计划的实现情况,评估计划行动以及附加需要实施的行动的有效性 ;
监控并评估风险图的变化(采用关键风险指示和临界风险点) ;
通过监督和内控检查策略符合度 。
风险管理生命周期的沟通与文档化
风险沟通是通过在决策者或其他相关利益方之间交换和/或共享风险信息以达成协议的活动。这些信息包括但不限于:风险的存在、性质、形式、可能性、严重性、处置和可接受性等。
各方之间有效沟通是重要的,因为这将对必须作出的决策有很大的影响。沟通将确保实施风险管理的责任人以及重大利益相关方理解决策出台的基础和为什么需要特定的活动。沟通应是双向的。
风险管理还应进行文档化统一管理。例如规定必要的阶段性报告产出;文档输入、输出数据内容及格式要求;文档命名规则;文档归档管理规定;文档保密管理规定等。
-
-
参考标准和文献
-
-
《国务院关于大力推进信息化发展和切实保障信息安全的若干意见》
-
等级保护相关标准规范
-
GB/T 20984-2007信息安全风险评测规范
-
《商业银行信息科技风险管理指引》
-
《商业银行数据中心监管指引》
-
《商业银行外包风险管理指引》
-
《电子银行业务管理办法》
-
《网上银行系统信息安全保障评估准则》
-
《商业银行操作风险管理指引》
-
《商业银行内部控制指引》
-
COSO内部控制整体框架
-
CoBIT信息及相关技术的控制目标
-
ISO27000系列标准
-
ISO/IEC 13335信息安全管理标准
-
SSE-CMM 安全系统工程能力成熟度模型
如果您需要了解更多内容,可以
加入QQ群:570982169
直接询问:010-68438880