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

导致安全问题的软件缺陷主要有两种：部署中的漏洞和设计中的缺陷。现在软件安全市场中的大部分重点都放在发现和修复漏洞上，这主要是因为自动代码审查工具让这个过程变得很简单。但其实软件设计和架构中的缺陷问题也占据很大比率，它占所有安全问题的50%。

简单地说，如果我们想要解决软件安全问题，我们就需要把更多注意力放在缺陷上。

使用ARA寻找软件缺陷

多年来，我们都在致力于软件风险分析和设计审查。当我们在1997年第一次开始审查系统的安全性时，我们采用了专业的方法--三个专业人士在房间里使用一块白板来审查。而现在，当我们深入检查软件架构中的缺陷时，我们采用的是被称为架构风险分析（ARA）的方法。

ARA包括四个步骤。步骤0（我们通常是从0开始的，因为我们是奇客）是获取一个架构图。这可能听起来很愚蠢，但不管你信不信，从开发团队获取相关的最新的架构图比听起来更困难。例如，一些开发团队指出“代码就是设计”，对此，我们不敢苟同。

这个步骤的最终目标是创建软件系统的单页总览视图。单页总览视图非常重要，因为我们想要“森林级”的软件视图，避免“只见树林不见森林”。我们都知道，漏洞出现在树木级，而缺陷则在森林级。我们不想要看到大堆代码，我们不想要UML，也不想要防火墙配置网络地图。在很多情况下，我们可以通过询问软件架构师、开发人员和测试人员自己绘制一页纸的总览图。

你的图表需要包含一些重要元素，其中包括，但不限于，DAO/持久层、业务逻辑/业务规则、安全功能、工具包（WSE、WCF、Ajax）、中间件、web服务、云计算API、缓存和分发。

当你得到架构图后，你需要进行三个专门的分析步骤：1）已知攻击分析，2）系统特定攻击分析，以及3）相关性分析。（我们重新命名了ARA的这三个步骤以便用户更容易理解）。

1）已知攻击分析很容易理解，正如其字面意思。获取与你的架构相关的已知攻击列表，并逐一进行检查。微软的STRIDE方法（有人将其误叫成威胁建模）就是一个很好的例子。STRIDE是欺骗、篡改、否认、信息泄漏、拒绝服务和特权提升的缩写。这就是微软已知攻击清单。

已知攻击分析的关键是要知道一些已有的攻击。如果你能制定一份设计层面的攻击的列表，这就已经成功了一半。STRIDE可能适用于操作系统供应商，而你需 要根据自己的市场和自己面对的独特的攻击者建立自己的列表。创建这种列表的方法之一是询问你的漏洞管理团队，看看哪些攻击最常见。

当你发现列表中的某个攻击具有相关性，计算其影响力，并思考你该如何修复架构来降低风险。请注意我们这里使用的是“降低”。有时候缺陷并不需要完全解决或者完全根除，我们只需要根据特定情况将风险降低到可接受的水平即可。

如果能够找出根本性的缺陷，对于企业来说，真的很有价值。发现一个有缺陷的设计，通过正确部署安全控制，降低数十或数百个漏洞带来的风险，这难道不是好事吗？我们可以通过输出编码来实现这一过程。

2）系统特定攻击分析侧 重于根据系统的运作情况来揭露无根据的假设、深挖歧义内容以及寻找新攻击。这个步骤需要最丰富的经验和天赋，因为安全本身是软件的新兴的属性。你知道，有时候软件自己运行时很正常，但当它被添加到更大的生态系统时，它就完全脱离轨道了。这就是我们的意思。预见自然发生的后果可能是非常棘手的工作。

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

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

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

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

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

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

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

轻量级设计审查

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

修复你的缺陷

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