高效软件安全实践:工具与专家的最佳结合

本文探讨了在软件安全开发周期中如何有效结合自动化工具与专家分析,包括静态代码审查工具、功能测试工具的应用场景及其局限性,以及专家在识别设计级漏洞和验证工具结果中的关键作用。

高效软件安全:充分利用工具

大家好!我是 Vinnie Liu,BlueHat 演讲者,也是 Stach & Liu 安全咨询公司的董事总经理。我们主要帮助组织建立有效的应用程序安全计划。每个应用程序安全计划的关键组成部分是使用工具和专家。在本文中,我们讨论了工具和专家之间的相对优势和劣势,通过这样做,我们也了解了这些软件安全资源如何最好地应用于希望在其安全软件开发生命周期中变得更加主动的组织。

当组织构建其软件安全计划时,他们不可避免地会问自己:“我是聘请顾问还是购买工具?”不幸的是,提出这个问题的简单行为是有限的——它提出了一个错误的困境,因为这两个选项不必相互排斥。我们的建议,以及我们从最聪明的客户那里看到的,是同时使用工具和专家。为了理解原因,我们需要看看我们面临的是什么,以及我们拥有什么。

让我们从一个假设开始:我们想要评估一个(神奇地)知道包含三个漏洞的应用程序。在我们的例子中,我们为应用程序设置了以下漏洞:

  1. 目录索引已启用。
  2. 密码重置工作流程中存在 SQL 注入。
  3. 存在密码重置设计问题。

这里还需要一些额外信息。首先,最后两个漏洞出现在同一页面上,并且该页面只有在先通过一系列先前的页面后才能访问。其次,密码重置页面存在几个设计问题,我们将把识别密码重置设计问题作为读者的练习。

在检查可用资源时,我们可以将第一类工具分为两种类型——检查工具和功能测试工具。检查工具在源代码级别执行软件检查,例如 Ounce 和 Fortify,而功能测试工具针对实时生产站点执行应用程序审查,例如 WebInspect 和 AppScan。我们的第二类是人脑,本文不会对其进行细分。那么这三种工具在尝试识别我们的三个安全问题时表现如何?

应用程序功能测试工具——功能测试工具将快速可靠地识别目录索引问题。然而,由于 SQL 注入漏洞要求应用程序状态处于某个特定点才能使问题暴露出来,扫描器可能难以自行识别此问题。功能测试工具永远不会检测到密码重置设计问题。

软件检查工具——我们的静态分析工具将能够快速识别 SQL 注入漏洞从源到汇的数据流路径,尽管它嵌入在应用程序的多个页面深处。然而,它永远不会检测到目录索引或设计问题。

专家软件分析——专家分析师将能够检测所有这三个问题,并且她应该在看到软件设计问题时立即检测到。不幸的是,分析师可靠识别目录索引问题所需的时间将比功能测试工具所需的时间多几倍。同样的问题也适用于我们的 SQL 注入问题。尽管手动跟踪代码从源到汇是可能的,但这将非常耗时——对于专家分析来说,时间就是金钱,因此这种方法在财务上不可行。

如果我们看看这些漏洞如何在我们的软件开发生命周期中出现,我们会发现它们出现在三个不同的领域——基本上是在构建或创建某些东西时。将我们对问题表现位置的知识与最适合识别它的工具结合起来,我们注意到以下内容:

总的来说,我们可以得出结论,功能测试工具最适合用于识别配置错误问题并执行暴力任务,如测试目录索引、不必要的文件等。这些工具可以通过处理繁琐但必要的迭代任务来减少执行评估所需的时间。检查工具最适合用于构建软件的数据流表示并识别某些漏洞,这些漏洞往往是诸如 SQL 注入和 XSS 等问题,其根本原因是输入验证。专家分析非常适合识别设计级别的问题。此外,专家分析对于验证功能测试和检查工具的结果是必须的。这是因为自动化工具可能产生错误——误报和漏报,并且设计上这些工具永远无法完全避免错误(这是一个比本文更长的讨论)。

我们的专家也是必要的,因为她可以综合软件的预期功能和上下文信息——这是当前工具无法执行的过程。然而,尽管专家是必要的,但纯粹使用专家方法是不可行的,因为专家在许多任务上比自动化工具花费的时间更长。就像用牙签挖井一样,你不应该付钱给顾问来猜测浏览器窗口中的文件名或手动重新创建应用程序的数据流图。相反,应该使用工具来自动化这些重复性任务。

通过分析工具和专家的相对优势和劣势,我们得出了一个简单的认识:是的,你应该同时使用这两种工具以及专家分析,以开发一个“有效”的软件安全计划。你需要一个功能测试工具,但不要期望它能找到它设计范围之外的问题。你还需要一个检查工具。你需要在循环中有一个专家,但应在需要时应用,而不是过度使用。

正确的工具,正确的方式,在正确的时间。

干杯, Vinnie

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计