Splunk 在今年 4 月以 3.5 亿美元收购了安全协调、自动化和响应 (security orchestration, automation, and response , SOAR) 软件开发商 Phantom Cyber，进一步扩展了其安全功能。Splunk 表示，将把 Phantom 软件与 Splunk 平台整合在一起，创建一个全面的系统，让 SecOps 团队可以利用分析驱动的安全性来加速事件响应，推进网络防御并降低组织风险。Splunk 表示，这还将有助于更好的管理安全运营中心，减少所需人员数量。
由此可见，SOAR 可以帮助你的安全团队集成不同的安全工具，并自动化手动，时间密集的安全相关流程，从而帮助你团队最大限度的提高效率。这意味着，SOAR 方案可以打破安全业务中的各种障碍。
那么，在规划 SOAR 的同时，如何构建技术堆栈？rapid7 的研究者给出了以下 3 点建议：
评估你和你的团队的安全流程
首先，细想一下你和你的团队在执行安全流程中，花费在哪个环节的时间最多。这个问题可能会促使你细细的查看每个流程，期间你可能会问自己以下 4 方面的问题：
- 安全流程的首要目标是什么？
- 这些流程是否可以被明确定义且不断重复？
- 你当前的团队和工具集是否可以实现该流程？
- 安全流程会随着任务的改变而不断复杂化吗？
接下来要做的就是，深入研究这些流程，并将每一步都详细表达出来，比如是什么启动了这个流程？还需要执行哪些任务？还有其他团队参与吗？……
这个过程应该能让你了解到哪些流程要靠人来完成，哪些流程可以完全实现自动化，但在许多情况下，你需要在自动化执行过程中刻意增加一些人工复查点（human checkpoint）。
当你开始在你的运行环境中实现安全自动化和协调时，通过这些详细的流程设置，就可以快速获得构建成功的 SOAR 基础。
审核你当前的安全工具套件
通过刚刚评估的流程，你可以总结出使用了哪些相关工具，这些工具将是 SOAR 设计的重要组成部分。你当前的手动流程可能涉及到多种安全工具，同样，你的自动化流程也是如此。你需要详细列出这些工具，并了解它们是否适合你的自动化目标。
接下来要考虑的问题便是围绕安全工具开发商和其开放性。审核当前的技术堆栈时，需要问自己 6 个问题：
- 你所用的安全工具开发商和工具是否有开放的 API，如果有，是如何开放的？
- 开放的 API 是否有详细流程记录？
- 这些 API 多久会发生变化，这些变化是如何被使用人员得知的？
- 这些开发商是否乐意为利用其 API 的开发人员提供技术支持？
- 这些开发商是否与其他厂商建立了技术合作关系？
- 访问这些开发商的 API 的相关成本是否很多？
梳理好了这些关键点，就可以可帮助你确定 SOAR 所用工具之间进行协调所需的工作量。这样，你将能够更好的为安全协调和自动化堆栈选择正确的技术，最终帮助你从现有的工具套件中获得更多价值。
此时，你还可以根据技术堆栈的需求获得更过技术工具的细节。在某些情况下，有哪些操作不适合自动化流程，并且供应商有充分的理由不通过 API 公开它。如果你无法通过 API 获得所需的某些功能，就需要确定有哪些工具和操作能适应你的新自动化流程。
明确哪些流程可以完全实现自动化并慎重加入人工复查点（human checkpoint）
此时，你就可以确定有哪些流程是可以安全实现 SOAR 的，有哪些需要手动来辅助，更重要的是，并不是所有的流程都适合 SOAR，你需要考虑如何处理这些非自动化任务。
一般来说，你有以下 3 个选择：
- 与开发商合作，了解他们的技术原理，看看他们是否在向着能实现自动化的方向发展？
- 必要时施加压力，如果他们的技术路线图不符合你的自动化目标，你可以考虑其他替代解决方案。
- 不是每个流程都必须实现全自动化的，有些流程就是需要人为干预。无论你是与开发商合作，将某些操作添加到 API 中，还是某些流程自动化后风险太大，全部自动化流程时仍需谨慎考虑。
总结
使用 SOAR 时，最重要的是理性理解 SOAR，不能把人为干预某个流程理解为自动过程的失败。有一些任务你可能不喜欢也不适宜自动化，因此你就需要在这些场景中增加人工复查点（human checkpoint）。
这是 SOAR 解决方案的关键注意事项，与自定义的协调和自动化不同，像 Komand 这样的安全协调和自动化解决方案旨在通过为你的安全团队提供某些自动化构建模块，来补充现有的安全措施，并允许你在使用过程中将已经自动化的过程恢复到以前的状态，以便人们可以灵活多样的为所需的关键任务或流程自定义 SOAR，例如修补 Production Server 组件。
SOAR 解决方案还有一个好处，就是会形成一个集成库，你可以随时查看参与自动化的 API 和数据结构。这意味着你不需要花时间维护 API 或追查文档。