商业银行信息系统建设面临的安全威胁及应对措施

◆刘凯强 吕远阳

商业银行信息系统建设面临的安全威胁及应对措施

◆刘凯强 吕远阳

(山东省农村信用社联合社 山东 250000)

随着商业银行网上业务的不断发展，电子信息系统安全风险管理策略成为理论与实践中必须重视的课题。本文从现阶段信息系统安全的薄弱点出发，对比商业银行信息系统的建设过程，提出了商业银行信息系统安全开发的策略。策略建议在项目整体的设计规划中采用软件安全开发生命周期，在开发过程中通过威胁建模覆盖潜在的风险点，并在开发完成后进行漏洞挖掘和代码审计，将开发中的不确定性降到最低，保证银行信息系统的安全与稳定。

商业银行；OwaspTop 10；威胁建模；代码审计；漏洞挖掘

0 引言

商业银行的信息安全一直是各方关注的焦点，随着银行网上业务的不断发展，越来越多的业务由信息系统承载，银行系统的稳定与安全也越来越受到各方的关注。对商业银行而言，在信息系统建设阶段，跟踪安全科技前沿，采用先进、周密的安全策略，保证信息系统不出现较大安全漏洞，不仅是商业银行自身资金安全的诉求，也是为银行广大客户群体负责。

1 商业银行信息系统常见的安全威胁

过去的几年中，应用程序的基础技术和结构发生了重大变化，信息系统面临的安全威胁也随之发生了变化。开源Web应用安全项目（OWASP，the Open Web Application Security Project）在2017年末发布了最新版本的OwaspTop 10，如2.1所示，将2013年以来Web系统常见的安全威胁项进行了调整，并详细分析了每一种安全威胁的特点与表现形式。对于商业银行科技员工，深入了解这十种常见的安全漏洞，并能够在建设信息系统时采取针对性的防范措施至关重要。

图1 十项最严重的Web 应用程序安全风险列表（OwaspTop 10）

上图1所示的安全威胁在商业银行的信息系统中也存在着具体的表现形式。例如：SQL注入漏洞、失效的身份认证和访问控制、暴力破解、金额篡改、跨站脚本攻击、越权漏洞、路径遍历漏洞及业务逻辑缺陷等。

虽然漏洞的表现形式五花八门，甚至可以说是无穷无尽，致使发现及控制这些缺陷困难重重，但是商业银行为保证资金安全和系统稳定，必须严格把控信息系统的各类安全风险。针对部分常见漏洞，商业银行可以依赖于开发和设计人员的经验，但由于商业银行科技系统的复杂性与高集成性等特性，仅仅依赖个人经验是远远不够的。安全开发是一项系统性工作，需要设计人员、开发人员、测试人员、审计人员等各阶段人员的共同参与，并以科学严谨的安全开发策略作支撑。

2 商业银行信息系统安全开发的策略

2.1软件安全开发生命周期—安全开发方法论

图2 软件安全开发生命周期

如图2，软件开发安全生命周期（SDL，Security Development Lifecycle）相比传统的安全建设方式，能够将软件安全的考虑集成在开发的每一个阶段，利用威胁模型改进安全流程。这是一种方法论，旨在提前、主动的发现问题，并希望能够全面的覆盖问题点。SDL的核心思想在于全流程的参与到软件开发的流程中，对威胁进行识别、分级，在需求、设计、编码和测试阶段缓和威胁[1]。若项目上线、运行阶段再进行需求、威胁的修正将会面临较大的风险和难度。商业银行在信息系统建设时要改变以往“先上线，再加固”的传统安全建设方式，采用国际先进的软件开发生命周期安全模式，进行整体安全规划与设计，确保项目安全、按时建设完成。

2.2威胁建模—开发风险全覆盖

面对信息系统中的威胁点，主动发现优于被动响应，早分析早处置优于上线时再评估，通过结构化的覆盖优于简单的罗列风险点。威胁建模在一个结构化的过程来考虑、记录、讨论威胁项，通过结构化和可操作的过程全面覆盖风险点。从多个角度对每个交易绘制数据流图、划分区域边界，让产品经理、开发人员和测试人员都参与到威胁建模工作中，从而覆盖软件中的缺陷和体系漏洞[2]。STRIDE是一种常见的威胁建模模型，使用该模型，能够判断数据流图中的各个节点是否存在相应的漏洞，最终生成一个威胁矩阵，并根据重要度进行合理的威胁评估。通过该方法能够全面地覆盖项目风险点，但其缺点也显而易见，占用较多人力和时间，各项目可以在开发过程中，根据实际寻求上线速度与系统安全的平衡点。

图3 STRIDE模型威胁要素

如图3，STRIDE模型威胁要素有以下六项：

（1）仿冒（Spofing），是指试图通过使用假身份访问系统。可以通过使用偷取获得的用户凭据或者假IP地址进行欺骗实现。当攻击者以合法用户或者主机身份成功访问系统后，即可实现提高特权或者滥用授权。其表现形式有凭证泄露、认证管理漏洞及身份劫持等。

（2）篡改（Tampering），是指未经授权就对数据进行更改，例如银行不同系统间报文传递时被第三方篡改金额、交易对象，甚至加密破解等。

（3）否认（Repudiation），用户（合法的或者非法的）否认他们曾经执行过特定操作或者事务的能力。签名就是一种简单的防否认的措施，U盾就是银行系统采用的数字签名技术的实现方式之一。其体现形式有无数字签名技术、日志缺陷、记录不全等。

（4）信息泄露（Information Disclosure），不必要地暴露私有数据。某些看似非隐私的数据对攻击者来说是非常有用的。例如密码泄露、未授权内容展示、网络中出现明文、异常信息泄露带出系统细节、数据库连接细节等。

（5）拒绝服务（Denial of Service），使系统或者应用程序不可使用的过程。攻击者可以通过大量恶意请求耗尽系统资源，或者通过异常输入使系统崩溃。作为银行的应用系统有必要严格控制系统输入，过滤异常、意图不明的输入，也有必要在系统整体架构设计时加入抗拒绝服务设计，同时考虑到各系统间的依赖关系，将拒绝服务的影响降到最低。

（6）权限提升（Elevation of Privilege）是指具有有限特权的用户假冒特权用户的身份来对应用程序进行特权访问。表现形式有XSS脚本攻击、远程代码执行、假冒管理员操作等。

要使用这些模型要素覆盖开发中的风险点，对开发人员提出了一定的要求。首先，开发人员要进行安全开发的学习，能够识别常见的软件漏洞及交易中的潜在风险点，将其划分至具体的威胁模型要素，并体现在数据流图中；其次，要求开发人员使用规范编码、代码审计等策略减少软件缺陷的出现。当软件系统的建设能够通过威胁建模来监控风险点时，就能在很大程度上减少因为编码不规范、逻辑漏洞等因素造成的软件缺陷。

2.3漏洞挖掘与代码审计—开发完成后寻找漏洞

银行信息系统开发完成后的漏洞挖掘与代码审计同样重要。由于交易系统的复杂性，难免会存在隐蔽的软件缺陷和漏洞，如果不进行严格的代码审计，这些遗漏的风险点犹如定时炸弹，随时可能会将系统防护、资金安全、社会声誉等方面撕出一个口子。

代码审计的思路一般分为业务逻辑正向审计和关键代码逆向审计[3]。正向审计通常跟踪交易请求在系统中的流转，审计业务逻辑路线的代码；逆向审计针对特定漏洞比较有效，比如SQL注入、命令执行、线程安全等安全问题，其他特点是有特定代码写法，进而全局搜索并排除非风险项。根据系统的实际情况，也可以结合审计工具找出的威胁点，并在重要功能点（如身份鉴别、数据库连接、关键业务流等）进行人工审计、专家审计。另外，在项目测试过程中充分进行白盒测试进行源代码脆弱性和缺陷检查，上线前通过黑盒测试进行模拟渗透测试。在功能性测试之外，程序的健壮性也需要在压力测试中进行充分的测试与审计。

3 结语

本文从OwaspTop 10出发，介绍了当前常见的十项信息系统安全风险类型，以此为参考，讨论了商业银行信息系统建设中防范安全风险的策略措施。本文提出从信息系统建设的三个阶段做好安全工作，即采用安全开发方法论，开发过程中全覆盖开发风险，开发完成后寻找漏洞。安全工作是一项系统性工作，绝非在一个阶段就能实现安全目标，尤其是对商业银行来说，更需要从整体上、全流程地把控安全风险。

[1]丛晓颖.计算机网络信息系统安全问题的分析与对策[J].信息安全与技术，2016.

[2]张涛，王玥，黄道丽.信息系统安全治理框架:欧盟的经验与启示——基于网络攻击的视角[J].情报杂志，2016.

[3]王培培.网络会计信息系统安全对策研究[D].山西财经大学，2014.