从B站数据遭竞品批量爬取,到华住集团信息泄露;从东海航空遭遇大规模恶意占座,到马蜂窝旅游网站事件;从接码平台日赚百万到双十一电商风险爆发.....顶象2018年第三季度业务风险监测数据显示,恶意爬取是第三季度所有业务风险中占比最高,排在第二位的是虚假注册,其次是账号盗用,推广作弊及其他,薅羊毛等。
薅羊毛,盗号冒用,虚假注册,恶意爬取,推广作弊等等各种业务不仅给业务平台带来巨大经济损失,损害了用户合法权益,更破坏了商业秩序。
,,其实,这些风险可以通过模型来防控,例如,在日常生活中,我们会关注每天的天气和气温变化,如果气温骤降,就会做出添衣的决策,如果第二天下雨的概率很大,就会做出带把伞出门的决策,从而达到降低患上感冒的可能性。让我们拥有这种潜意识的就是威胁模型。
所谓威胁建模,就是使用抽象的概念来分析可能存在或出现的风险,并减轻或降低风险的对策过程。通过威胁建模,可以防范上面提到的互联网业务风险;通过威胁建模更可以防范信用欺诈,虚假注册,钓鱼诈骗,信用恶化,贷款逾期等金融欺诈。
绝大部分的开发团队都使用系统需求分析文档,软件系统设计文档以及功能模块详细设计文档来规范系统的开发和测试过程,整个开发周期中,只在测试阶段引入渗透测试或者安全代码审计来提高交付的系统的安全性。但是,因为设计阶段就缺少安全部分的分析设计工作,往往导致渗透测试和安全代码审计工作事倍功半,收效甚微。测试人员无法根据缺乏安全设计的设计文档来估算安全测试用例的覆盖度;研发人员也无法针对发现的威胁快速并高效的提供解决威胁的开发修复途径和安全产品采购需求。
安全代码审计和渗透测试是两种最为常见的发现威胁以提高系统安全性的方式。但是这两种方式都具备类似的缺点:很难系统化和量化系统的安全性。威胁模型更关注哪些方面可能出现安全问题,通过建模的方式将威胁抽象化和结构化,以图表帮助确定威胁的范围,并利用表格和列表的方式来追踪和更新威胁,实现在开发过程或者运维过程中识别和管理威胁。
我们使用软件测试来对软件产品和阶段性的开发结果来进行质量检验,力求发现其中的各种缺陷,并督促缺陷得到修复,从而控制软件产品的质量。作为软件测试中的一个环节,安全测试的关注点是安全缺陷,保障的是软件产品的安全性质量。
软件测试可以使用软件的需求分析和定义,软件系统设计,模块详细功能设计甚至具体编码实现来指导测试的设计和执行。同样,通过威胁建模,可以在安全测试的设计和执行中获得以下指导:软件系统可能会面临哪些方面的安全威胁;系统正在遭遇哪些方面的威胁;以及系统现状能够抵御哪些方面的威胁。
威胁建模是为了交付安全性更高的软件,服务或者技术,因此,在找到和定位威胁之后,如何处理和管理威胁也是威胁建模不可或缺的一个部分。威胁建模能够权衡解决威胁的策略,并指导系统的开发者使用哪些技术和系统配置方式来处理发现的各类威胁。与功能测试报告相似,表格和列表也可以应用于整体威胁建模漏洞的跟踪。
威胁建模是由微软首先提出,建设过程主要分为三步。
首先,在预设场景中要考虑具体的业务特征,真实用例以及场景中所用的产品,图表化能够帮助我们理解业务场景和系统,以及定位威胁的攻击面,然后,借助特定的模型和方法来发现威胁并对发现的威胁进行评级,优先处理攻击难度高并且危害程度的威胁。最后,需要测试是否已经对相关威胁进行有效的处理,达到威胁建模的结果收敛,系统的安全性有效提高。
威胁建模通常从三个维度来建立:以资产为核心,以攻击者为核心,以业务为核心。在实践中使用哪种建模方式往往根据系统构建者的关注点来决定的。比如,风控或者业务部门关注的可能更多的是资产或者有价值的东西,安全部门关注的更多的是攻击者,通过利用攻击库列表来寻找系统威胁;而研发部门关注的更多的是正在构建的软件或者部署的系统,将威胁模型作为常用的软件开发模型的补充,来提高软件系统的安全性。
