软件安全：使用ARA寻找软件缺陷

在很多情况下，分解问题可能会有所帮助。最起码，在这个步骤中，我们可以思考信任建模(明确确定信任边界)、数据敏感性建模(确定隐私和信任问题)以及威胁建模(确定攻击者，并从攻击者的角度考虑)。请注意，我们这里使用的威胁建模的术语与微软的有所不同。

在这里，我们想强调的一种方法是综合不同的观点。你能否试想，两个软件架构师，一个架构，在同一个房间，会发生什么事?提示：这里不存在世界和平。利用非常有经验的架构师对相同系统的不同观点，能够帮助你全面综合地解决问题。

在此步骤中，注意你所发现的攻击及其影响。想一想你该如何通过修改设计来降低这种风险。

3)相关性分析在于，确定你依赖的其他软件架构的运作情况。让我们面对现实吧，现在的软件几乎总是依赖于别人设计和构建的组件和框架的正常运作。它们的前提条件是什么?它们如何影响你的系统?如果框架“胡作非为”，你的设计会怎样?

请从你正在依赖的组件开始，确认这些问题：你依赖的组件中是否有已知漏洞?(无论是开源组件或者其它，答案通常是肯定的)。你是否在这些框架中构建了足够的安全控制?它们真的有用吗?(不幸的是，答案通常是否定的)还有其它功能或特性需要被禁用吗?(可能)。框架在默认情况下安全吗?(可能，如果你最近操作得当的话)。

写下你发现的事实，思考其影响，确定该怎么做。在完成ARA的四个步骤后，你会发现你面临很多风险，也会产生很多改进设计的想法。考虑这些风险，并明确对业务的影响。然后将你发现的风险进行优先排序，提出解决方案来解决你所发现的最重要的缺陷。

接下来有些棘手：搞清楚如何以及何时进行重大的架构变更。在某些情况下，解决方案需要几年时间才能展开，对此，请不要太绝望。

轻量级设计审查

ARA听起来很容易吗?但事实并非如此。由于这个过程很密集，并且涉及很多专业知识，深入的ARA并不会适用于所有你的应用。ARA是关键系统必备的架构，但对于非核心系统，这并没有必要。在以后的文章中，我们将探讨应该如何解决在这些“不太重要的”系统中的漏洞问题。

修复你的缺陷

无论你的架构审查过程是否会带来快速的重构或者使用多年的多个版本企业架构的变更，现在是时候让我们开始重视软件安全问题。我们不能放弃漏洞检测以及用来发现和修复漏洞的工具，但与此同时，鉴于缺陷也占据一半的问题，我们需要谨慎地解决这些问题。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友