银行信息系统研发风险分析与模型应用_金融安全

信息系统研发风险已成为商业银行信息科技风险的主要方面之一。针对这个课题，本文在业界主流商用软件安全开发生命周期模型以及商业银行最佳实践及理论研究成果的基础上，提出了基于信息系统研发生命周期6个阶段12个安全活动的安全研发模型。

随着商业银行信息化水平的逐步提高，以业务信息系统为核心的科技部门越来越有力地发挥着基础支撑作用；与此同时，随着网络互联开放程度的逐步加深和互联网金融时代的日趋临近，商业银行信息系统面临的信息安全风险也日益加剧。本文针对当前商业银行信息系统研发风险进行了综合分析，并通过对国内外几种典型软件安全开发模型的对比与分析，结合商业银行信息系统风险特征，提出了一种基于安全活动的商业银行信息系统安全研发模型。

一、商业银行信息系统研发风险分析

根据Gartner统计，互联网上75%的攻击行为已经由网络层转移到了应用层；另据NIST报告，在目前已发现的漏洞中有92%源自信息系统自身，由此可见，信息系统自身安全性已成为商业银行整体风险控制的关键环节。而对于一般用户而言，系统是否安全已逐渐成为他们面临选择金融服务时最为关注的方面，尤其是商业银行业务系统往往承载着大量的用户数据、金融信息、交易数据等敏感信息，安全需求更为突出。如何有效解决信息系统安全问题，从系统研发过程着手做好信息系统风险管控，努力打造安全可靠的业务应用，已成为商业银行信息科技工作的重要课题。

传统的软件开发生命周期主要是从软件功能实现角度出发，合理地组织开发流程以高效地完成软件的各项功能，通常只注重软件功能的定义与实现，而安全性没有得到充分的考虑，即使在测试环节考虑信息系统安全性，也往往是在编码完成后进行，而未能将软件安全的思想贯穿至整个软件开发过程。当前商业银行信息系统开发基本仍是沿用传统软件开发生命周期，系统安全面临巨大挑战。

1．商业银行信息系统研发现状

（1）研发安全组织不完善
研发风险管理工作的开展需要相关的组织和角色作为支撑。目前，各商业银行的整体信息科技风险管理组织在企业一级较为完善，但较少能够深入到研发风险管理环节，主要表现在项目组中缺少研发风险管理角色等方面。

（2）研发安全目标不明确
由于业务需求部门和开发部门对于信息系统安全性理解的偏差与不足，可能导致信息系统安全需求考虑不足甚至完全缺失，往往只能通过事后整改的方式解决问题，成本高但效率低。

（3）研发安全依据待完善
当前商业银行的信息系统面临着多方面的监管要求，既有行内的，也有行外的；既有管理要求，也有技术要求。这些要求的来源不同，侧重点不同，粗细颗粒度不同，给研发人员造成一定困扰，亟待统筹规范。

（4）研发安全过程不通畅
大多数商业银行缺少完整的研发安全全流程管控，不能从信息系统研发全生命周期出发落实安全目标，往往事倍功半。

（5）研发安全技术支撑不够
研发风险管控工作不但包括管理方面，还包括技术方面，信息系统安全性的保障必须以相应的安全技术手段作为支撑。但现有商业银行研发团队往往缺少系统化的安全技术支持和服务，影响了信息系统安全研发水平。

（6）研发安全意识普遍偏低
为了提高商业银行金融服务水平，各行均不断加快信息系统研发速度。由于技术人员安全意识不强和安全技能参差不齐，在市场需求和研发工作量的双重压力下，系统安全设计存在不足。

2．商业银行信息系统研发风险分析

通过对商业银行信息系统研发现状进行分析发现，主要存在以下几类风险。

（1）组织风险
研发安全组织和研发安全角色设置不到位，导致相关制度标准贯彻无法到位，相关安全活动无法开展，可能最终导致信息系统安全目标缺失或者无法实现。

（2）制度风险
研发安全制度或标准建设不足，使得安全研发工作无章可循，可能造成安全研发的无序开展。

（3）技术风险
研发安全技术支撑不够，直接影响信息系统安全研发的效率和成本。

（4）成本风险
由于组织、制度、技术及人员意识的问题，造成安全管控工作的效率降低，成本增加。

（5）业务风险
上述现状的存在，势必会导致信息系统安全性的不足，一旦上线，将产生不可预估的业务风险。

二、安全开发模型分析

1．安全工程

安全工程是一门研究事物安全与风险矛盾运动规律的学科，其通过研究安全与风险的发生发展过程，揭示事物安全与风险的原因和后果，以及它们之间特有的相互关系。

2．软件安全工程

软件安全工程是安全工程在软件研发领域的具体应用，它期望通过将安全考虑集成到软件开发过程中的每一个阶段来达到避免安全缺陷的目的，通过将一系列安全设计原则、安全开发方法和最佳实践及专家经验组合起来，形成软件安全开发生命周期。

3．软件安全开发生命周期

软件安全开发生命周期从根本上来说，是将安全原则渗透至整个软件开发的生命周期中，即在每个开发阶段均考虑安全性，通过软件开发的各个步骤来确保软件的安全性。目前业界最有影响力的软件安全开发生命周期模型主要有微软的SDL（Security Development Lifecycle）方法，OWASP的CLASP（Comprehensive Lightweight Application Security Process）方法和McGraw的安全接触点（Touchpoints）方法。

（1）微软的SDL方法
微软的安全开发生命周期SDL模型是一种业界领先的软件安全保障过程，微软公司从2004年起开始实施，在保障软件产品安全方面起了巨大作用，很大程度上影响了微软公司的各类产品和企业文化。通过与实际的开发方法相结合，SDL很早就将安全因素集成到开发中，并贯穿整个开发过程。SDL目前已发展为一个有着良好定义的相对成熟的开发方法，它引导微软开发出了安全性有较大提升的产品如Windows Vista和Microsoft SQL Server。SDL方法将安全活动按研发阶段进行分组，因此很容易将它们映射到标准的软件开发过程中。

（2）OWASP的CLASP方法
CLASP生命周期模型是一个由一系列安全活动驱动、基于角色组织的安全推进实践过程模型。它通过安全最佳实践将安全属性以一种结构化、可重复和可测量的方式，整合到现有或者新启动的软件开发生命周期中。CLASP模型采用“视图→活动→过程组件”的自上而下的组织形式，定义了一系列需要被整合开发过程和操作环境的安全活动，开发组织可以对该模型进行裁剪以适应待开发产品的实际情况。同时，它还定义了一些对软件产品安全有影响的角色，并为这些角色分配了相应的任务，由各个角色对任务的完成和结构的质量负责。

（3）McGraw的安全接触点方法
安全接触点模型强调使用工程化方法来实施软件安全，即在整个软件开发生命周期中都确保将安全作为软件的一个有机组成部分。该模型重点关注三个方面——风险管理、软件安全接触点和安全知识。其中，风险管理贯穿整个生命周期，用来追踪和减轻风险；接触点即进行安全开发的最佳实践；安全知识的收集、组织和传播对安全教育和接触点实施极为重要，知识类型包括原则、方针、规则、弱点、攻击程序、攻击模式和历史风险等。

4．模型对比与分析

安全接触点方法认为软件安全处理方法应该简单、易用且可裁剪，因此它将7个安全接触点进行了安全贡献优先级排序，在实际应用过程中如果无法全部采用7个安全接触点，也应首选安全贡献大的接触点。CLASP方法也允许软件组织对其提供的24个安全活动进行裁剪，它提供了12～14个影响力高或者非常高的安全活动，如果采取这些安全活动，将在耗费较少时间和人力的情况下仍能取得较好的安全收益。微软为采用SDL的软件组织定义了四个成熟度等级共13个安全活动，分别是基本级别、标准级别、高等级别和动态级别，软件组织可以逐步地改变自己的软件开发方式。

以上三种软件安全开发生命周期模型都提供了涵盖整个开发生命周期的一系列活动，这些模型也都经过了实践的检验，它们既有共性也有区别，软件组织根据自身实际，可对现有的软件开发过程依据这些典型安全开发生命周期模型，制定改进计划和衡量方法，持续不断地提升开发和管理水平，以保障软件产品具有足够高的安全性。

三、商业银行信息系统安全研发模型

1．模型设计

通过以上对比分析可以得出，一个优秀的软件安全开发生命周期模型具备如下共同特点：重视安全培训与意识教育；建立安全团队，明确安全责任分工；将最佳安全实践整合并应用至研发过程；建立有序的安全开发流程；重视安全工具与技术的使用。

1 2 下一页尾页