实用威胁建模指南 (一)

你写的Code安全吗? 如果有人问你这个问题, 你的答案是什么? “安全的, 因为我用xxx框架, 他可以抵御xxx攻击. ” “安全的, 因为我用了xxx云的xxx安全服务”. OK, 这些答案都不错, 但是如果我们仔细想想, 这些答案是不是又有些虚? 即使我用了xxx框架或者xxx云,我的系统安全就能大道100分了吗? 又或者说, 安全是安全工程师要考虑的事情, it’s not my cocern. 好吧, 就像质量是团队每一个人的职责, 安全同样也是.那有没有一种方法可以让整个团队都把安全跑以来? 有的, 那就是威胁建模, 一种实用的提高系软件系统安全的工具.

什么是威胁建模

威胁建模并不是一个新的名词, 它的历史和计算机的历史一样长. 早在上世纪60年代, 随着计算机技术的发展, 计算机攻击和防御就同步出现了, 威胁建模的概念也就随之产生.

1994年, Edward Amoroso 在他的著作《Fundamentals of Computer Security Technology》提出了“Threat Tree”的概念, 一种如何探测IT系统中漏洞的方法.

1999年, 微软的安全技术专家 Loren Kohnfelder 和 Praerit Garg 提出“STRIDE”威胁建模的方法用来分析windows 开发环境下的系统安全漏洞.

2003年, 一种OCTAVE的威胁建模的方法被提出用于进行组织中的风险管理.

2004, Frank Swiderski 和 Window Snyder 将威胁建模的方法用于构建安全的应用程序.

....

威胁建模是的历史和发展源远流长, 我们来看看维基百科上对于它的定义:

威胁模型分析 （threat modeling）是寻找系统潜在威胁以建立对抗的策略，以建立安全的系统。它属于资讯安全的议题，并将问题划分成“寻找针对特定技术的威胁模型”与“基于威胁模型建置更安全的系统”。

威胁模型分析的概念是基于值得保护的具有有价值资产之系统与组织。这些资产具有明确的弱点，而内部或外部的威胁能使之曝露出来并造成资产的损失。威胁模型分析亦能用来寻找合适的对抗方式，以降低可能的威胁。

看上去有些抽象, 那么威胁建模是不是仅仅是计算机科学家或者计算机安全专家的领域, 普通的开发者, 我们只有双手合十祈祷自己的系统没有任何问题, 或者按照网上开源的“checklist” 看看我们系统有没有中招? 有没有什么实用的威胁建模的方法可以为我们开发者所用帮助我们提高我们系统的安全呢? 当然是有的, 下边就是开始威胁建模的三条建议.

开启威胁建模的三条建议

如果一个团队没有进行过威胁建模, 想要将其落地, 那么下面的三条建议会是一个很好的开始:

建议1: 从技术威胁开始

对于一套软件系统来说, 威胁源是多方面的, 例如没有使用合适的加密或者鉴权方法, 人工错误, 不怀好意的“友商” 或者 “前员工”等等. 如果一开始就是要同时应对这些所有的威胁源头, 往往陷入老虎吃天的境地, 无处下手. 所以威胁建模应该先从“技术威胁” 开始. 因为这些威胁往往是比较明确和确定的, 作为开发者对于这些威胁我们也是相对熟悉, 所以从这些问题开始, 是一个很好的开始点.

建议2: 全民参与开启威胁建模Session

就像质量是整个团队的职责一样, 安全同样也是. 威胁建模的具体形式一般来说都是一个个session, 所以威胁建模的session一定是整个team都要全民参与的, 包括开发, 测试, PM, BA等等, 不同的Role对于同一个产品是有不同的认识和了解, 正是因为这样, 全民参与的威胁建模Session才是更加有效的方法.

建议3: Agile威胁建模

建议3我称之为Agile威胁建模, 就像Aglie之于瀑布开发模式的最大区别在于: 持续的迭代和改进. 我们不能寄希望于一次威胁建模就能解决所有的安全问题. 威胁建模应该是Agile的, 他可以是像Retro一样的定期的活动, 也可以是按需进行的, 但是每次的威胁建模都应该保持相对小的scope并且持续的review和迭代, 后一次的威胁建模应该全面的review上一次威胁建模的成果, 那些做到了, 那些没有. 那些做的好, 那些做的不好, 这样才能使得系统安全持续的提升并且维持到相对好的状态.



OK, 上边简单介绍了一威胁建模的历史和定义, 以及威胁建模的三个建议. Talk is cheap, show me the sample 后续文章会结合我们自己威胁建模的实践例子, 给大家提供一种实用的威胁建模方法.