独家供稿：移动Labs

上期说了业务安全的思路是三步走，第一步是分析威胁，本期就讨论如何分析威胁。

    要分析威胁其实是要考虑两个方面，一个方面是哪些是威胁，另一个方面是已经具备的安全机制能防护哪些威胁。也就是说先订一个安全威胁的大列表（攻击方），然后再制定一个防护内容的表（防御方）；然后进行对比，就能发现安全隐患。

这件事情也是说起来就一句话，做起来非常困难的一件事情。从目前的情况看，无论是制定安全威胁的全集（列表）、安全威胁分析、安全防护措施分析都是非常复杂的问题；如果有一天能把这个问题弄清楚了，估计离天下太平也就不远了。这里，我也没有绝对好的方法去克服上述3个问题，但能将我的一些经验告诉大家。

（1）      列出全部安全威胁

如何能将安全威胁很好的列出来呢？我们可以借助一些现有的安全威胁分析模型，例如传统的CIA模型、Stride模型都提供了一些安全威胁的分类方法。在此基础上，依据自身（企业或部门级）的业务特点，进行细化，可以比较好地列出安全威胁来。

在这里，我更推荐Stride模型一些，因为CIA模型比较抽象，难以与业务流程相结合；而Stride则比较细化一点。

在这里，我还给大家推荐一篇好文章（标准），对安全建模绝对有重要作用《NIST IR 7298 Glossary of Key Information Security Terms》，网上可以下。

一旦列出了所有的安全威胁，那么就存在了分析安全隐患的基础，即我们知道可能存在的敌人是谁。

（2）      依据场景分析安全威胁

也许有人说，安全威胁分析不是很容易吗，方案摆在那里你还找不到问题啊？其实这种思想是非常错误的，正如医生治病一样，好的医生能通过种种迹象找到病根，差的医生则只能看到表面现象或者诊断错误。

安全威胁分析也是一样，即使在同样的设计下，在不同场景中出现的安全问题也不一样。例如一个业务设计中存在明文传输信息的问题，那么这个设计安全吗？我们的回答是：虽然都是面临局域网内监听的问题，但是否安全则不一定。不妨我们举几个例子来进行分析。

例1：银行的卡号、密码传输。这种场景下最好不要通过明文进行传输。

例2：bbs的用户名、口令传输。这种场景下可能存在窃取，但由于用户访问的内容不是很敏感，因此明文传输也可以。

例3：通过短信传输。大家可能不一定知道，短信是明文传输的，但由于是空口传输，被窃取的难度极大，因此基本不可能被窃取。

通过上面3个例子，很容易知道安全威胁的分析是要依据场景来进行的。

（3）借助工具分析安全威胁

即使我们对安全威胁、场景了解都很透彻，但仍然存在问题。如果系统复杂，其中包含上百甚至上千个资源，形成极其复杂的交互的时候，我们的人脑就不够用了，或者说能勉强执行，但是效率非常低。还好，早有人想到了这个问题，并且开发了工具。

在这里，我郑重推荐微软开发的“Treat analysis and modeling tools”。这是一个免费的工具，在微软官网上可以下载。微软甚至已经帮你定义好了很多种攻击方式，不过威胁的建立还是要靠自己输入。还有另外一个问题，不提供中文版，我忽略不计了。

总之，做业务安全威胁分析一定要深入到流程，也需要不断的实践进行积累，这样才能有大量的威胁库和防护措施库。

好了，今天就先到这里，下期再见。

粟栗