学术堂首页 | 文献求助论文范文 | 论文题目 | 参考文献 | 开题报告 | 论文格式 | 摘要提纲 | 论文致谢 | 论文查重 | 论文答辩 | 论文发表 | 期刊杂志 | 论文写作 | 论文PPT
学术堂专业论文学习平台您当前的位置:学术堂 > 毕业论文 > mba论文 > mba毕业论文

吉林银行信息系统运行过程中风险分析

来源:学术堂 作者:周老师
发布于:2015-08-27 共9113字

  第三章 吉林银行信息系统运行过程中风险分析

  根据《商业银行信息科技风险管理指引》办法第十六条和《商业银行操作风险管理指引》第二章第五条“商业银行应制定持续的风险识别和评估流程,确定信息科技中存在隐患的区域,评价风险对其业务的潜在影响,对风险进行排序,并确定风险防范措施及所需资源的优先级别(包括外包供应商、产品供应商和服务商)”;“商业银行应当按照本指引要求,建立与本行的业务性质、规模和复杂程度相适应的操作风险管理体系,有效地识别、评估、监测和控制/缓释操作风险。”

  适时准确地对商业银行信息系统运行过程进行识别、估计、评价是 IT 风险管理的基础,同时也是风险治理的基本步骤。信息系统风险主要存在以下特点:复杂程度高,专业性强,隐蔽不易查找原因,影响范围广,损害性强,应急突发处理难度大且较为频繁。由上文对我行信息系统暴露出的问题分析可以发现我行对信息系统风险管理主要缺乏有效的、系统的和全面的 IT 风险识别、估计和评价体系。

  信息系统风险管理首先应对所有的信息资产进行列表识别。信息资产包括业务过程、文档、数据、软件、系统、硬件、设施、人力资源、服务、无形资产等。本文根据信息资产列表将所有的信息资产列表大致进行归类整理为技术类资产,管理类资产,服务类资产,无形资产,以及其他资产五类从而为识别信息资产在管理的过程中所产生的可能风险奠定基础。

  3.1 风险识别的方法和范围

  对风险的准确定位,无遗漏地识别是掌控 IT 风险,将风险防范在萌芽状态的基础。风险是多种多样的、错综复杂的,无论是潜在的还是实际存在的,静态的还是动态的,内部相关的还是外部相关的,风险是否客观存在等,都要做系统的分析与归类。结合我行的实际情况,首先,在风险识别实施前,需要按业务需求、文化、业务流程、风险监管、信息规模和结构确定风险识别的范围和目标,建立适当的组织结构和系统化的风险识别方法。

  综合我行情况主要采用头脑风暴法,对于风险识别初期使用头脑风暴法取得一份风险清单。由信息科技部的负责人主持,同时邀请会计结算部、社区银行部、公司银行部、风险管理部和审计部的业务部门高级经理配合业务人员来实施。与会人员就目前信息系统存在的和潜在的风险进行集思广益。经过初期的风险清单进入中期时使用德尔菲法,主要由风险管理人员对风险清单上罗列出的风险逐一核对,同时征询业务部门的意见和监管要求,并根据不同的标准进行分类。然后根据信息资产类别进行分门别类,对定义加以进一步明确,使其具有一定的代表性。最后可以通过风险矩阵定性风险发生等级程度以及预期后果以便制定风险应对策略。我行的信息系统风险识别范围主要涉及信息系统在规划、研发、建设、运行、维护、监控以及更新产品的过程中由于技术和管理缺陷所产生的风险。

  3.2 信息系统风险管理识别归类

  信息系统运行过程中风险的识别是风险管理的第一步,也是风险管理的基础。只有在正确识别出自身所面临的风险基础上,才能够主动选择适当有效的方法进行处理应对。我行信息系统风险识别需要确定风险源、风险事件,然后对其评价发生概率、发生时所表现的症状、严重性等级和后果。

  3.2.1 技术风险

  从技术风险角度识别,我行采用的 oracle 公司的框架结构存在一定的优势,通过大前置的通讯分支和控制,实现了对核心系统的梳理和剥离,减轻核心系统运行负担。

  新的信息系统在很大程度上降低了核心系统的复杂性,减少了系统的负载,增加了系统的可移植性,从而提高运行的效率,减小数据移植的风险。其次,新信息系统的应用引入了产品的概念,弱化了前台柜员对于会计核算科目的识别,将银行的存贷款业务种类以产品的形式进行管理分类,利于竞争和营销。第三,新核心的应用为后续的业务开展提供了简易平台,即每开发出一个新品种业务都只需以产品的形式直接加挂在外围系统,减少了核心系统运行的不稳定性。

  我行所采用的先进技术框架虽然适应了日后的业务多样化发展需求但也带来一定的技术风险隐患:(1)系统设计复杂:现有新系统主要分为两大模块:ORACLE 技术公司提供的核心系统和外围柜面操作系统,核心系统的技术由于是国外研发的技术产品,因此框架复杂且通讯接口多,一旦发生问题不易被察觉。其次,外围系统连接到核心的外挂系统共有 56 个,数量较多,导致服务设备和技术的兼容性差。

  (2)软件设计与预期结果存在差异:由于系统开发过程中技术不成熟或开发人员会计知识了解不足,导致设计思路的错误或不确定性,从而影响整个系统的运行。我行虽然采用了国外先进的 oracle 技术作为核心系统处理账务,但国外的信息系统设计框架与国内人民银行的监管方式、角度和重点都有相对的差异和不同之处。导致在运行过程中发现的系统缺陷因为固定的软件架构难以更改和修复。尽管此类问题均可以通过其他思路优化改进,但系统在上线后运行至今仍有百分之五左右的缺陷是由于程序设计框架而无法配合改造的。

  (3)硬件平台风险:硬件平台一般由中心机房、服务器、网络设备和线路等组成。我行的系统设计决定了在系统的运行过程中各个系统通讯环节薄弱,主要由于系统间接口频多,设计开发团队过多,设计思路风格迥异,硬件设施不够强大,导致通讯链接超时,处理的业务速度较慢,导致系统异常情况时有发生,需要人工或者后台维护。另外,接口的增多还会影响报表取数的正确性和及时性,使得操作风险增加。

  (4)数据传输风险:我国采用数据加密技术标准。数据加密以加密算法为基础,通过秘钥解密来获取数据的一种方法,几乎是目前保证数据机密性有效手段。但我行由于新旧系统衔接的需要,数据移植过程中产生很多数据存储出错和丢失以及不兼容性,使得对数据的保护性不高,加剧银行数据在传输过程中的风险。[43]保证各种需要保密的资料(包括电子文档、磁带等)不被泄密,确保绝密、机密信息不泄漏给非授权人员以及信息泄密次数为 0 次/年。

  (5)系统受攻击风险:主要来自对银行系统漏洞的内部威胁和外部威胁攻击上。我行主要存在内部威胁,例如未经授权改变数据:后台维护人员经常未经过审批手续而更改数据。更改后的数据造成行内账务不平、运行系统崩溃、以及数据缺乏准确性等风险后果。外部威胁攻击几乎不发生,且行内对外部威胁一般采取提高防火墙等级、更新杀毒软件、更新秘钥、加载安全控件等方式进行防御。

  (6)柜面系统技术压力大:柜面系统主要用于前台柜员业务操作,其开发思路是将防控操作风险结合在计算机程序中,即柜面系统采用的程序结合人行等部门的监管要求,当柜员进行业务操作时由程序控制大部分的操作风险,将人为操作风险降到最低,这势必导致柜面系统的技术要求高、复杂、压力过大,甚至造成柜面所编写的命令与核心的框架相冲突。由此原因引起的风险占大约百分之十五左右,而由于系统程序与业务规定相结合致使技术压力大的风险占技术风险百分之八十左右。

  (7)产品的维护性风险和与测试结果不一致风险:银行 IT 人员对业务部门提出的需求从测试到上线常常出现与测试结果不一致现象。由于测试时使用的软硬件条件限制有很多非预期的后果,常常导致系统在维护,变更和推新产品的过程中所发布的运行脚本与其他已存在的代码有冲突以至于产生运行不畅风险。此类风险占到百分之五十左右,频率较高,事件较多发,一般发生时间通常在我行变更日后第一日日始,由于新业务的上线或者传统业务的更新常常导致运行不畅,业务操作不通,甚至全行营业时间晚点的现象。有时还会发生在系统跑批处理时,由于各个通讯系统的交互频繁,因此第三方记账失败,导致业务处理状态不正确的风险加剧。

  3.2.2 管理风险

  从管理风险角度分析,结合我行的实际情况运用 SWOT 分析法得出:目前,我行的优势(strength)在于信息科技部门根据监管要求制定了风险管理相关的制度、法规指引,也设置了相对应的部门,岗位以及从业人员去完成正常的信息科技日常运行管理,基本具备了清晰的制度框架,同时也建立的相应的信息安全管理规范,并在具体岗位设置和实施中都有相应的配套流程。这些优势都是搭建并完善信息系统风险管理平台的基础建设。尽管对信息系统的风险管理框架通过努力已经逐渐完善,但在执行管理的过程中同时暴露出来的劣势(weakness)和威胁(threat)也日益凸显。

  (1)决策延误性:我行目前对于信息系统运行过程中出现的运行错误和操作人员上报的日常维护均采用纸质形式传递。当业务人员发现信息系统出现问题或人为操作失误时首先要拨打行内的 400 运营维护电话说明问题,一旦问题被确定需要填写纸质维护单,再通过业务运营部门的审核、主管行长的签字,传递到信息科技部,由科技部的主管人签字确认,然后再统一修改。这中间需要多个部门的互相沟通和反复确认,且修复时间不明确。导致最后的决策在处理时间上有很大的滞后性,并且大部分时候需要对私客户一等再等,一般为T+2日而对公客户因为问题的严重性或者技术的复杂度耗时更长。

  (2)授权级别不充分:科技部负责运营维护的操作人员和权限不相符,没有对操作进行分权管理,造成运维人员对生产环境的操作权限过大。有随意篡改数据的风险,容易对数据准确性造成人为损害。

  (3)外包人员变动风险:系统架构和一部分核心研发的产品是通过外包开发商的方式获得,获得后的产品因为技术保护等原因无法掌握其源代码进行改动。一旦外包商的人员进行更换则不能立即掌握核心技术而导致无法准确定位系统产生的漏洞和满足提出的各类业务新需求。另外,外包人员由于存在合同制,同时处于自我保护技术等原因曾进入我行运维中心将技术“源代码”删除现象。

  (4)人员能力不足问题:一方面,因为我行长期的外包形式,加上信息化科技的飞速发展,使一部分人员出现技能上的脱节,培训的力度不大,不能再次从工作中获得新的知识技能使得很多行内 IT 人员大多缺乏系统研发能力,因此无法掌握核心源代码,导致核心技术和柜面操作系统技术为他人所有,自身不易发现系统漏洞,更不能及时根据生产需求和安全需要对源代码进行修改,只能受制于人。其通常表现为不能积极主动地提高自己技能,更无法提供建设性的合理化意见甚至不能胜任本职工作,也就是俗称的“尸位素餐”.另一方面,道德风险日益突出,信息化系统说到底是由人开发的管理工具,同样存在缺陷和无法制约的操作风险。部分银行职员长期缺乏职业道德培训,在市场经济开放的情况下丧失了基本的道德观而出现大案要案的发生。我行曾经在 2013年初时出现过一次因基层人员利用信息系统操作漏洞监守自盗导致我行巨额库存现金被转移的案例。在银行经营过程中,一些职员的道德风险日益突出,常常因为缺少道德约束而做一些与职业道德不符的事,如利用银行信息化手段泄露客户信息,故意错误操作银行系统等,从而给银行带来巨大的安全风险。由于多数员工基本遵守职业道德,因此道德风险的发生占比就目前来看还是比较低的。但是根据二八黄金法则,通常都是最低比率的风险发生概率带来百分之百的不可逆转损失。道德风险的发生大部分来源于基层员工,往往也是最被忽视的一个群体,利用熟悉的业务知识和发现的信息系统漏洞而给银行带来经济损失。

  (5)部门之间缺乏必要联系:在信息系统运行中产生的系统问题通常涉及的部门有业务部门,基层营业室和信息科技部门,但通常因为沟通不及时,或是找不到分管的人员而延误处理问题的时间。其次,待处理的问题没有反馈机制,上报的缺陷业务有时同时有几个人一起跟踪,而对于另一些问题业务却无人问津。除了分工不明确外还存在缺乏沟通和联系的问题。

  (6)缺乏定量的风险管理工具,风险管理效率偏低:目前缺乏识别信息系统风险计量工具,在信息系统运行过程中难以在识别环节上通过数据积累做定量分析。信息系统运行过程中产生的风险不能预警提示,大多以事后维护作为弥补。其结果难免出现重复检查,亡羊补牢,增加人力却没有取得相应的良好效果。

  管理风险的发生概率不可单纯的从统计角度全面客观的计算,但管理类风险为信息系统风险管理提供一种软实力环境,软实力环境的提高能够有效遏制因为管理不善而出现的工作失误,能够提供一种更为规范的行为准则而降低风险发生概率。

相关标签:
  • 报警平台
  • 网络监察
  • 备案信息
  • 举报中心
  • 传播文明
  • 诚信网站