现有的”银行某业务安全评估”，大多是业务系统的安全评估，而非业务本身的安全评估。在《2014绿盟科技互联网金融安全报告》也中提到，“业务设计缺陷造成的风险最高”。此次绿盟科技博客与绿盟科技技术刊物合作，推出《手机银行业务安全评估》系列文章。本文以实际手机银行业务安全评估为例，介绍了一种简明的业务安全评估方法。 大致内容包括业务流程梳理、两种业务风险分析方法及其对比等。
狭义与广义的业务安全
本文仅讨论狭义的业务安全。
首先我们对业务安全的范围进行一下说明，狭义的业务只是指业务本身：为了实现业务目标而设计的一系列操作和流程。用户按照流程，通过执行这些操作来达到自己的目的。如”到银行取现金”这项业务是我们都熟知的，而在不同的业务场景有其不同的业务操作：
- 银行前身的”山西票号”，使用银票作为大额银两的汇兑凭据。取银者将银票交到票号柜台，票号核对银票的真伪、签章、密押等，无误后将等额银两交给取银者。
- 使用存折的取款人，在银行柜台与柜员交互，凭存折和取款密码支取现金。
- 使用银行卡的用户，在ATM机自助操作，凭借记卡和取款密码支取现金。
同样是取现金，无论哪种业务场景，均需凭借某种物品、某种信息来证明自己的身份，并证明自己合法地拥有对这笔钱的所有权，才能成功办理业务。”证明身份”、”证明所有权”、”提出要求并取得现金”，这些是业务功能设计，而银票、签章、密押、存折、银行卡、取款密码、银行柜员、ATM机等，是业务逻辑实现中的必要条件，也是狭义业务安全的一部分。
狭义业务安全和广义业务安全
对于手机银行来说，本文把这些业务操作和流程本身、业务逻辑实现的必要条件（应用软件）作为评估对象。至于手机银行系统运行所需的基础环境，包括Web服务器、中间件和数据、主机、网络、物理机房等，当然它们的安全性也会影响到手机银行业务的安全性，不过这属于广义的业务安全，就不在本文讨论了。
现在银行业机构和安全厂商，对手机银行一类基于互联网的金融业务形式，安全工作重点还较多停留在应用软件的安全上，而没有对业务功能、流程本身进行合理的安全设计。至今，很多银行还把安全设计称为”非功能性设计”，其实安全功能也应该成为业务的一部分，与业务功能紧密配合，这样才能有效保证业务安全。
本文介绍了一种简明的手机银行业务安全评估方法。
梳理业务流程
首先应对照业务需求说明书将手机银行各业务流程进行分解，将每个步骤整理成可供分析的列表。
需要注意的是，如果针对已经上线的手机银行，其真实业务流程很可能与原来的业务需求说明书中有所不同，这是由于大部分银行项目开发时间短，很多需求没有充分讨论就已经开始软件编写，或者在测试过程中追加一些新功能，都会导致业务实现与设计书中不同。所以已经上线的系统还应通过业务操作来核实设计书的内容，使流程分析表单与实际业务流程一致。
业务流程示例：手机银行登录
将手机银行登录的每一步骤分解，说明用户操作、输入内容和服务端处理工作等。如上表，手机银行登录的4个步骤中，包含下列要素：
- 交互方，包括手机和服务器，分别代表了用户和银行业务系统。
- 操作（处理过程），包括用户的输入、选择、确认等操作，服务器对用户发来的指令进行处理，读取数据库记录等。
- 信息流，信息在交互方之间传输的过程，信息流中包含了重要程度不等的信息。
- 数据存储，手机和服务器中都会保存数据，包括用户信息、cookie、日志等。
以上这些业务流程中包含的要素都面临着威胁与风险，下一步可以进行风险的分析与识别，以便设计相应的安全防护措施。
业务流程风险分析方法一：STRIDE分析方法
STRIDE威胁与业务要素对应表
借用应用开发安全的SDL理论，业务行为也面临着下列威胁：
- 假冒(Spoofing)。假冒交互方即手机用户或服务端，假冒某个业务操作。
- 篡改(Tampering)。篡改信息流的内容、数据存储内容、操作指令内容等。
- 抵赖（Repudiation）。恶意否认自己做过的操作，如用户否认自己进行过转账操作。
- 信息泄露（Information disclosure）。信息流、数据存储、操作过程中泄露用户名、口令、身份证号、银行卡号等敏感信息。
- 拒绝服务（DoS）。使某项业务功能不能正常运行。
- 提升权限（EoP）。在业务中越权操作，如非法查看其他人的账号交易记录。
这些威胁手段作用在4类业务要素上，形成了风险矩阵，类似SDL中应用开发安全的分析方法，我们对业务要素也可以进行风险分析，识别每一个业务流程乃至业务环节的风险。
业务流程风险分析方法二：已知风险对照方法
这个分析方法，事先要进行充分的准备，准备工作包括：
- 搜集和整理以往的业务风险事件，这里主要是手机银行相关的攻击或漏洞暴露事件。
- 分析这些事件，将这些攻击事件中存在脆弱点的业务要素梳理出来，并进行明确的说明。如手机银行登录的第2个步骤中，在我们渗透测试的案例中，发现很多银行服务器不但传回验证码图片，还会同时把验证码内容包含到手机APP的页面文件内一起发回客户端，以方便客户端进行校验。虽然验证码内容不显示在手机APP中，但有可能被有心者利用查看工具直接从页面文件中读取，验证码机制就被绕过了。因此，”发送验证码图片”这一处理过程，容易出现”同时发送验证码内容”的问题，这会导致攻击者更方便地进行口令猜测攻击。
- 汇总这些问题的说明，形成风险说明的清单。在事件来源充分的情况下，所有出现过问题的业务流程都已经在清单里包含，每一个业务流程被攻击或威胁的方式也已经梳理清楚，准备工作就完成了。
然后可以将分解后的现有手机银行业务流程与准备好的清单进行对照，直接识别出每一个业务流程可能存在的风险，并填写在”可能风险”这一列中。
两种分析方法的对比
两种业务风险分析方法对比
两种分析方法各有利弊。STRIDE方法由于是在分解的业务流程基础上进行每个要素的单独风险分析，理论上完全覆盖了业务流程中所面临的风险，因此不会有遗漏，可以有效发现业务风险。但其分析过程复杂，耗时多，在传统的瀑布式开发模式下还能比较好地适应。瀑布式开发是典型的预见性开发方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等，如果用此模式开发一个手机银行应用软件可能需要三、四个月甚至更长时间，显然已经无法适应互联网金融发展速度。
现在很多手机银行业务，从决策到上线可能只有两个月的时间，通常采用敏捷开发或迭代开发模式，这种情况下想进行充分的STRIDE分析是不可行的。而在准备充分的提前下（已知问题的清单完善），已知风险对照方法能快速地从业务功能推导出相对应的风险与应对措施，能较好地适应敏捷开发或迭代开发的节奏。
比较好的方法是二者结合，对成熟的业务功能与流程，采用已知风险对照法分析；对新的业务功能与流程，采用STRIDE方法分析。由于现在大多数手机银行的业务功能大同小异，因此客观上形成了以已知风险法为主，STRIDE分析为辅的情况。