进化安全修复流程：从火灾扑灭到可扩展模式

重点内容

• 优先级与风险发现 ：在处理安全风险时，优先级和风险发现应该并行考虑，而不是仅依赖火灾扑灭模式。
• 重修复过程 ：修复一个漏洞不仅仅是应用补丁，而是一个需要管理的整个项目。
• 资源优化 ：我们需要通过改进项目管理，降低修复成本，从而释放安全与修复团队的时间。
• 平行工作流程 ：设想使用不同的团队平行处理不同的风险发现，以提高效率。

在初步看来，“优先级”和“风险发现”似乎总是要一起进行。我们必须对发现的内容进行优先级排序，因为不这样我们就永远无法应对它们，对吗？进一步思考，我们总是谈论优先级的重要性，因为我们几乎总处于火灾扑灭模式中，努力在资源有限和效率低下的过程中保持有效性。事实证明，在不断的火灾扑灭模式下操作，会妨碍我们的流程扩展。

我们每天的安全测试工具仪表板都会给我们提供一长串新的发现，增加到之前的发现中。意识到这个列表控制不住后，我们自然而然地得出结论，必须开始优先级排序。可悲的是，当涉及到网络安全风险修复时，往往在我们需要优先排序之前，事情已经为时已晚。例如，如果某个发现已经被黑客利用，我们就会将其优先于其他发现。然而，如果这个漏洞已经被武器化，那我们修复的过程就太晚了。这正是“火灾扑灭”的完美例子。我们更希望有一个可扩展的流程，使我们的组织更加韧性。这样，下次在野外发现漏洞时，我们就已经做好准备。

我们怎么会陷入这种疯狂呢？这归根结底是资源有限的结果。修复单个发现甚至代价不菲。我们需要分析发现，做出需要修复的筛选决策，打开工单，从发现工具复制粘贴到工单中，并找到负责人执行修复。修复过程所需的费用越高，我们就越需要进行优先级排序。安全管理工作的高成本使我们不得不只专注于极为关键的发现，从而阻碍了我们在修复过程中的主动性。

只有当我们停止并拆解修复流程的每个组成部分时，我们才会更全面地意识到，修复一个发现不仅仅是应用一个补丁，而是一个我们需要管理的完整项目：从漏洞分析，到有关其相关性的决策，再到修复准备、执行修复过程以及验证修复效果。

如果我们能专注于改善低效和无效的项目管理方面，并降低每项工作的成本，那么我们就能够为安全和修复团队腾出时间，从而为可扩展的过程奠定基础。

我们需要减少行政开销，但在完全扩展我们的流程之前，我们需要进行另一种思维转变。考虑一下团队在面对两个关键任务时的情况。总是需要在这两者之间进行优先级排序，以便团队知道首先要做什么。但如果它们能并行完成呢？如果安全团队可以通过两个不同的工作流程，两个不同的团队来解决这两个问题？

考虑这两个工具，每个工具都会提供自己的发现并按优先级排列：

工具 | 描述
—|—
外部攻击面管理（EASM） | 工具发现了暴露在互联网上的未修补资源。它还显示公司的网站使用了过时版本的WordPress。
静态应用安全测试（SAST） | 工具发现公司的Web应用存在SQL注入漏洞。此外，公司另外一款Web应用使用了容易导致数据泄露的API。

在这些例子中，更好的优先级排序方式未必能帮助我们。EASM和SAST工具各自提供基于其方法论的发现优先级排序，考虑了成千上万的数据点和最佳实践。

正如这些情况所示，问题在于，讽刺的是，安全团队成为了修复的