[CSO]安全威胁建模分析中7个可能犯的错误

[CSO]安全威胁建模分析中7个可能犯的错误

相对缺乏成熟度的威胁建模分析可能给那些依赖此举确保其网络和服务安全的机构带来大麻烦。

【By Jaikumar Vijayanfrom:www.csoonline.com译：nonono7731】

 

OWASP(开源Web应用安全项目)把威胁建模分析描述成为一个结构化方法，用以识别、量化和定位一个应用的安全风险。它实质上要求对威胁有着战略思考，特别是当构建或部署一个系统时，应该在其生命周期的早期通过适当的控制以阻止或减轻潜在的威胁。

威胁建模分析并不是一个新观念，但只有很少机构能够做好。ThreatModeler的创始人兼CEO Archie Agarwal认为，威胁建模分析的最佳实践才刚出现，最大的问题是缺乏对威胁建模分析整体的认识，威胁建模分析有很多种路径，公司经常会陷入麻烦，不知道如何去搞明白如何将其流程化，也不知道如何去度量，这些事情的路径仍不明晰。

根据Agarwal和其他专家的意见，下面是可能在威胁建模分析中可能正在犯的7个错误：

1.过度以应用为中心

Agarwal认为，机构最容易犯的错误是只针对应用程序本身创建威胁模型，通过威胁建模分析应该努力理解应用的整体框架而不只是一个孤立的应用系统。应该考虑基础设施、数据库、共享组件、第三方交互和部署环境。应用是本地部署或运行在云端，或是否能够被移动终端和其他计算终端访问，基于部署位置和访问模式不同，威胁是可能发生变化的。

如果已经迁上了云端，那就需要为云端进行威胁建模。你愿意将应用和数据运行在一个专用基础设施还是共享服务数据库中？至关重要的是必须记住，当你建模时，不能只看到应用本身，而是应该看到所有与之相关的内容。系统开发人员构建系统的时候需要考虑一些应急措施，部署的时候也需要考虑可控的操作。

2.只关注脆弱点而不是威胁本身

IDC的分析师PeteLindstrom认为，机构可能犯的一个错误是过于关注脆弱点而对威胁关注不够。检查数据流、控制流，查找应用中可能存在的脆弱性相当重要，此外，还需要更明确的审视威胁并识别可能存在风险的输入和输出。要考虑攻击者所有可能的机会，那些让你丧失控制权，进而影响机密性、完整性、可用性、生产率和数据的所有权属。

“现在，我们正在讨论Meltdown和Spetre漏洞（Intel芯片中的漏洞）影响了机密性。但完整性和可用性呢？攻击者有办法操作这些内容表或插入数据嘛？仅仅控制特定的漏洞并不意味着攻击者不能找到利用这些漏洞的新方法。”。

3.过分关注特定的威胁

SANS学院的最新安全追踪主管JohnPescatore认为，在威胁建模分析过程中，不要过度追逐最新的威胁或过度关注特定威胁或几种类型的威胁。勒索软件和挖矿软件可能是对安全最现实的威胁。不要只对这些威胁建模分析，更应该专注于采取控制措施减少对系统机密性、完整性和可用性的威胁。

同样，也不要过分在意来自中国、俄罗斯或塞尔维亚的攻击。关注归因、国家支持的黑客和犯罪团队这些事件并不重要，更重要的是知道如何在这些威胁中保护自己。知道来自中国的攻击者正在攻击你，不如知道该如何处理此类事件。

应该专注于建立可重复的流程，以确保情况变化时仍然有备无患。关键是要有一个标准的流程和方法论每次都能以相同的方法处理，无论是不是有新的威胁。应该知道这种流程是什么并努力以此为起点来加强保护。

4.将威胁建模分析误认为威胁映射

如果你认为威胁建模分析就是建立一个威胁列表看看你的应用里有哪能对应上，你所做的就是威胁映射。Agarwal说，“假设你有一个在线的银行应用系统，你问了一系列问题，如，‘你使用了Flash嘛？你使用了Java嘛？你做认证嘛？’等等”，那么你所做的事情不是威胁建模分析，因为你对威胁的背景一无所知。你也不知道如何用Flash或在什么地方使用Flash。

同样，仅仅因为使用了数据库并不意味着你自动需要担心SQL注入这一攻击途径，只有当使用Web应用从外部来源中接收输入数据时，SQL注入攻击才成一个潜在的关注项。这种细微差别在使用检查列表方法评估威胁的时候很容易被忽略。

构建一个适当的威胁模型，体系结构图相当重要。这些图应当显示数据库、Web服务、操作系统层以及运行和访问应用的信息化基础架构。应当显示所有的数据和通讯流向何方，入口点在哪里，从这些入口点输入的数据是什么类型。体系结构图可以提供全景图，也会提供边界信息。

5.未把用户加入威胁模型

存在过度关注对手如何攻击其代码，但不够关注他们通过其他方式接近应用和数据的情况。Pescator认为，“威胁建模分析坏人如何攻击代码是一个好办法，但防止假冒攻击不是能够内置到应用程序之中的事情。必须把用户纳入到威胁建模之中来，并考虑可能影响安全的用户操作方式。需要审视权限管理和基于角色的访问中的问题，需要考虑用户访问云端应用和通过电子商务计划重要组成部分‘移动端’中的潜在威胁。“

6.企图一劳永逸的威胁建模分析

威胁建模分析不是静止的。Agarwal警告说，“千万不能对关键应用进行一次威胁建设后就万事大吉”。如果你的机构象大多数一样，连续的开发活动持续不断。当你的应用改变时，它的威胁轮廓也发生了改变。这就意味着你当前的威胁模式三个月之内就过时了。“你的威胁模式应该是一个活动文档，不能建立了一个威胁模型就丢在一边，你的应用程序是活动的。”

7.未考虑系统的外部影响

通过威胁建模检测数据系统的可信度是一个好办法。但是，当你已经充分考虑了面临的威胁，并且找出了控制和减轻的措施时，那就必须考虑下你的系统如何潜在影响与之相关的其他各方。“你的系统输出可能影响他人的安全态势“，Lindstrom认为，“比如，服务一个黑市站点或域名被侵占或者向IOT（物联网）试探的DDOS数据包。”你也许并不赞同屏蔽广告，但是，如果你站点的恶意广告感染了客户系统怎么办？当你上线一个系统时，你就有责任保证其安全，并确保下游用户不会因用你的系统而受到影响。无论是从数字信用还是从责任立场，这种尽职需求都应该成为威胁建模的组成部分，。

作为威胁建模练习的一部分，必须确保理解与开源软件和第三方插件相关的风险，不光是你的机构，而且包括你服务的下游用户。如果你提供一种实时的聚合服务，你就需要考虑你的数据和服务对其他人的影响。Lindstrom说，”如果有人依靠你的GPS数据，那你必须考虑数据的完整性和可靠性“。