在我的博客文章《威胁情报主导内容创作 - 第一部分》中，我写到威胁情报和狩猎是如何成为我们设计后续检测内容的根源，这导致了各种机器可读对象的产生，比如规则本身、威胁档案、剧本（及其响应行动），并与我们需要检测它们的数据源组件相联系。

在另一篇博客文章（安全价值金字塔）中，我也讨论过安全团队的真正价值应该用于寻找未知威胁，这受到底层实现方式的影响。

例如，你设计了一个OT子网络，但它有互联网连接，所以你决定用Snort规则进行监控——这些规则是针对已知威胁的，但如果一个规则触发，SOC必须确定这是否是未知威胁的一部分。这些较低层级也将对威胁模型和你的威胁狩猎方法产生主要影响。

在这篇文章中，我想讨论继续发展这些协作机会的必要性，我们需要就如何做到这一点达成共识，以及我们如何实现这一目标的一些想法。

协作的力量

上图可能笨拙地试图展示的是，面对你和你的组织的独特威胁（已知和未知）与甚至是你所在行业部门面临的威胁相比只是微小的一部分，更不用说世界其他地方了。

因此，协作的目标应该是让安全团队主要专注于那个小子部分中的威胁。成功的协作意味着面对每个人的威胁可以从众包的最佳实践中受益。做好这一点意味着团队中的才能和想象力专注于新的和创新的事物，这些事物会反馈到协作社区中。

当前协作

信息安全社区是广泛的——供应商、独立研究人员、庞大而沉默的大多数人只是继续工作——其中有我们其他人只能梦想的人才。我相信我们天生是利他的，当我们发现新事物时我们会兴奋，并喜欢与他人分享。

一些例子：

漏洞

国家漏洞数据库（NVD）和CVEDetails.com等网站多年来一直是审查产品漏洞状态的事实上的地方。通过在这里使用共同语言（CVE），我们能够以我们都理解的方式集体讨论和分享这些漏洞是什么。

攻击工具与技术

社区衍生的工具和技术多年来一直是对手模拟/（实际对手）的主要内容，漏洞研究也是如此。其中许多是利他共享的，尽管其中许多可能具有更邪恶的起源。

事件

最近的Log4Shell事件是（并且仍然是）对人们对其技术栈信心的最大冲击之一。随着大多数安全世界聚焦于此，包括我在内的许多人前往Twitter等社区跟踪最新进展和建议。整个社区能够从群体思维方法中受益，这是我第一次涉足Twitter空间，@GossiTheDog在这里运行了一个公开呼叫以提供帮助。

信息安全的Github化内容

这篇博客文章试图站在巨人及其思想的肩膀上，其中之一是John Lambert关于信息安全Github化的文章，它谈论了社区共享内容的不同方式以及当我们堆叠它们时可能带来的好处——比如Sigma规则、Mitre ATT&CK、Jupyter笔记本等。

Mitre ATT&CK 2022路线图继续了这一点，其中最相关的要点之一是检测对象的引入。我假设这将朝着类似sigma的格式发展，以共享检测逻辑。

所有人使用的共同语言

Mitre在ATT&CK框架中统一战术和威胁语言方面所做的工作是革命性的。例如，它几乎已成为衡量EDR响应能力、映射内部检测能力等的行业标准。尽管我对如果不正确使用这可能如何危险持有看法，例如“我们有一个覆盖那个的规则，因此我们有覆盖”，它给了一个喜欢自行其是的行业方向。

Mitre ATT&CK框架现在链接到检测这些威胁所需的数据源和特定元素，而OTRF OSSEM（https://github.com/OTRF/OSSEM）等项目正在努力将这些与设备生成的实际事件联系起来。最初，Atomic Threat Coverage（https://github.com/atc-project/atomic-threat-coverage）项目真正开始让我思考我们如何构建整个检测生命周期，并在我看来应该如何将所有内容缝合在一起。尽管有所有这些，它们目前不是行业中的共同语言，这仍然是一个挑战。

挑战

透露我们的手牌

安全有点两难——如果我们都共享我们的检测和预防方法，那么对手也会知道这些，并可以努力规避它们，但通过不共享，我们很可能在重复彼此的工作——这些时间本可以用于发现未知。

反论点是，通过在一段时间内以受控方式观察攻击展开，你可以更深入地理解对手，比如他们的基础设施或TTP。

最终，我认为需要 strike 一个平衡，但当我们决定共享我们的检测内容和控制时，安全团队可以继续专注于根除未知，然后生成新的内容，然后他们再共享回来。这创建了一个正反馈循环，并大大增加了对手的成本——他们的焦点必须转移到规避共享的检测规则，但即使那样，它们很可能只是非常暂时的规避。

神化与质量控制

虽然我认为安全社区是奇妙的，但我可以看到一些潜在问题。

神化

通常在社区中，我们信任我们学会信任的人——那些有良好洞察力的人，或者那些已经产生伟大内容的人，以及那些在受人尊敬的角色中的人。这些都没有错，然而它确实引入了一个偏见，即他们是有平台的人，因此他们的声音被更强烈地听到。

通常我不认为这是一个问题，但我感知的主要风险是他们是人。人们有生活，他们有意见（有时有争议），他们可能被公交车撞到。社区中有一些人，无论是通过他们维护的工具，还是他们穿透噪音并给出清晰信息的能力，对日常安全都有巨大影响，他们的缺席会被感受到。

因此，协作应该能够独立于一个人或一小群人存在，以试图从内容中去除任何偏见或议程。

质量控制

如果社区以社区方式生成新内容，我们如何验证它：

a) 具有合理的保真度/信噪比——内容的质量很重要，最终，如果我们要在自动化决策中 potentially 依赖共享内容，就存在以负面方式影响业务的风险。质量应该是这样的，即我们从一开始就理解噪声水平可能是什么。

b) 意图不是恶意的？——虽然许多人在我们共享的内容上是利他的，但会有其他人（包括对手自己）可能想要造成伤害或削弱我们的能力。

c) 提供足够的信息——在检测内容中，上下文是王道。仅仅提供一个“坏IP”列表，而没有任何关于它们为什么坏以及在什么条件下的上下文，在我看来是浪费每个人的时间。

解决方案与未来

我相信Mitre一直在做的几乎将整个安全周期吸收到可共享对象中的工作，我认为对网络防御是一个潜在的游戏改变者，不一定是因为它都是原创的——通常它们类似于许多其他项目的最佳部分，而是因为它们已经如此 established。我希望看到这一点增长，然后安全供应商与之对齐（例如，Splunk将其CIM映射到Mitre ATT&CK的数据源/数据组件）。

在我看来，我们都在独立创建相同的内容是没有意义的——虽然我理解Mitre ATT&CK只是已经知道的（和共享的），当我们本可以根除新的和有趣的威胁时，我们真的不应该都在为自己重写那里的内容。

我相信在10年内，IT将几乎完全驻留在云中，并且更常见的是作为SAAS运行。我们今天面临的许多威胁将演变成新的威胁，我们将不得不对服务提供商给予更多信任。这可能意味着安全团队的角色将转向更多的威胁狩猎能力，因为技术栈的标准化意味着安全内容几乎在他们不知情的情况下被应用。我不知道，但我认为未来10年可能会对我们如何看待安全产生重大影响。