新闻链接：http://netsecurity.51cto.com/art/201411/456784.htm
新闻时间： 2014-11-13
新闻正文
      目前仍然处于早期发展阶段的软件安全面临着两个挑战。首先是确保从业人员修复他们发现的安全缺陷，无论缺陷属于什么类别。第二是扩展到涵盖整个企业范围的产品组合(全部，当然，也许是以基于风险的方式)。幸运的是，在这两方面，我们一直在取得进展。

软件安全：为什么DAST和RASP不是企业级方法?

修复你所发现的问题

应用安全技术专家和行业分析师一直不断地探讨用于检测软件安全缺陷的方法。SAST、DAST、IAST和RASP都是Gartner公司认可的漏洞检查方法，它们都被扔到这场战斗中。可悲的是，从技术上来讲，并没有最终的胜利者。这是因为每种方法都有自己的优缺点，并且这些方法往往相得益彰。

自Cigital公司在1999年推出其ITS4以来，SAST(即静态应用安全测试)已经走过了漫长的发展道路。扩展SAST是一个挑战，在两种情况下会遇到这个挑战。第一种是通过围绕一种工业级强度工具(例如Coverity、IBM Appscan Source或者HP/Fortify)建立一个工厂。第二种是部署基于IDE的桌面工具，例如Cigital SecureAssist。Aetna首席信息安全官Jim Routh和笔者在其他文章中也讨论了SAST以及可扩展性。(顺便说一句，SAST和技术转移是很好的议题)。

从局外人来看，DAST(即动态应用安全测试)是关于动态黑盒测试。一般来说，DAST工具只适用于使用简单通信协议(例如HTTP)的软件。它对Web应用的动态测试很有意义，但DAST在其设计中只有有限的目标。这意味着DAST很适合Web应用，但并不适用于大多数其他类型的软件。

IAST(即交互式应用安全测试)整合了动态和静态方法到交互式解决方案中。很明显的是，早期IAST方法(与DAST一样)限制为Web应用。如果你的产品组合中只有Web应用，IAST是很好的方法。

RAST(即运行时应用自我保护)是一种新方法，它主要是重写软件让软件可以在运行时被监控。这是有着悠久历史的想法，同时它有着一个很大的缺陷：如果你在最后一刻重写软件，当你因为软件故障而受到指责时不要感到惊讶，即使你的重写与故障没有关系。笔者总是会说，“不要成为最后一个摸山芋的人”，这个建议也适用于RASP。从记录来看，RASP还会带来效率影响，1%到10%的范围，这也需要考虑在内。最后，如果你允许RASP来阻止代码在主动攻击期间在生产环境运行，你等于创建了一个很好的拒绝服务引擎。总之，这是很新的方法。

事实证明，探讨这些技术方法是非常愚蠢的行为，特别是当涉及SAST、DAST和IAST时。多年以来，在该领域的从业人员通过各种方式整合这些技术来解决软件安全中的重要问题。单靠一种方法几乎永远不是正确的答案。

人的因素

软件安全的肮脏小秘密解释了这其中的原因：工具本身并不能解决软件安全问题，特别是单纯寻找漏洞的简单工具。这是因为如果你不真正解决你发现的安全缺陷，你并不能在安全方面带来改进。如果没有聪明的工作人员的参与，这些工具都无法修复缺陷。它们在发现漏洞的方式略有不同(我们甚至不会提涉及缺陷)。并且，这个真理适用于所有web应用安全子域。

如果我们退后一步考虑这些技术，可以很容易看到SAST提供的优势超过DAST或其他任何动态测试方法。当涉及修复软件时，如果你知道代码中哪里存在问题，则更容易修复这个问题。在另一方面，如果你只知道哪个运行时glob在运行时测试过程中存在问题，修复这个缺陷则是一个挑战。正如在物理学中，白盒实验总是优于黑盒实验。

由于开发者最终要负责创建尽可能少缺陷的软件，任何能够尽可能直接地帮助开发者的工具都是最有用的。在开发领域的这一点上，只有少数简单漏洞可以完全自动化处理掉。这个测试仍将需要开发人员的参与来解决问题。

总之，在你设计巧妙的新方法来检测漏洞时，确保你考虑了实际软件修复。如果你的工具供应商没有谈论问题如何得到修复，这里可能有原因。

扩展到企业产品组合

说了这么多，对于软件安全，各种类型的工具都是必不可少的。在这里，扩展很重要。为了涵盖大多数公司的整个产品组合(即所有软件应用)，自动化是真正唯一的出路。从其价值来看，设计分析和漏洞查找工具都是这样，虽然在设计中我们有些工作会消除。

很长时间以来，风险管理被滥用为仅关注少数“高风险”应用，而最终减去和忽略了其余的绝大多数应用。虽然从效率来看这似乎是个好主意，但事实证明，攻击者通常会瞄准一切的事情。在现在的攻击情况中，你产品组合中的每个软件都应该进行一定水平的测试。攻击者会瞄准任何薄弱环节(包括暖通空调供应商和其他小型供应商)。目前新的薄弱环节是被忽略的应用安全。

现在是时候利用整个产品组合中的工具和服务来不遗余力地寻找基本的漏洞了。

当然，这些类型的解决方案仍然可以是基于风险的。你有高风险面向互联网的应用?请进行一次彻底的架构风险分析;使用强大的静态分析工具来审查其代码;培训开发人员来保持其安全性;执行渗透测试以及进行完整的she-bang，但不要将低风险应用转盘转动至零。使用自动化测试来寻找和解决简单漏洞。为开发人员配备基于IDE的静态工具，并对他们进行培训。

在你规划和执行你的软件安全举措(以及使用BSIMM进行衡量)时，请确保这种可扩展性发挥重要作用。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！